draft-ietf-cdni-footprint-capabilities-semantics-16.txt   draft-ietf-cdni-footprint-capabilities-semantics-17.txt 
CDNI J. Seedorf CDNI J. Seedorf
Internet-Draft NEC Internet-Draft NEC
Intended status: Informational J. Peterson Intended status: Standards Track J. Peterson
Expires: October 15, 2016 Neustar Expires: October 24, 2016 Neustar
S. Previdi S. Previdi
Cisco Cisco
R. van Brandenburg R. van Brandenburg
TNO TNO
K. Ma K. Ma
Ericsson Ericsson
April 13, 2016 April 22, 2016
CDNI Request Routing: Footprint and Capabilities Semantics CDNI Request Routing: Footprint and Capabilities Semantics
draft-ietf-cdni-footprint-capabilities-semantics-16 draft-ietf-cdni-footprint-capabilities-semantics-17
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
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 October 15, 2016. This Internet-Draft will expire on October 24, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction and Scope . . . . . . . . . . . . . . . . . . . 3 1. Introduction and Scope . . . . . . . . . . . . . . . . . . . 3
2. Design Decisions for Footprint and Capabilities . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Advertising Limited Coverage . . . . . . . . . . . . . . 4 2. Design Decisions for Footprint and Capabilities . . . . . . . 5
2.2. Capabilities and Dynamic Data . . . . . . . . . . . . . . 5 2.1. Advertising Limited Coverage . . . . . . . . . . . . . . 5
2.3. Advertisement versus Queries . . . . . . . . . . . . . . 6 2.2. Capabilities and Dynamic Data . . . . . . . . . . . . . . 6
2.3. Advertisement versus Queries . . . . . . . . . . . . . . 7
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 Capabilities with Footprint Restrictions . . 8
3. Main Use Case to Consider . . . . . . . . . . . . . . . . . . 8 3. Footprint and Capabilities Extension . . . . . . . . . . . . 8
4. Semantics for Footprint Advertisement . . . . . . . . . . . . 8 4. Capability Advertisement Object . . . . . . . . . . . . . . . 10
5. Semantics for Capabilities Advertisement . . . . . . . . . . 11 4.1. Base Advertisement Object . . . . . . . . . . . . . . . . 10
6. Negotiation of Support for Optional Types of 4.2. Delivery Protocol Capability Object . . . . . . . . . . . 11
Footprint/Capabilities . . . . . . . . . . . . . . . . . . . 14 4.2.1. Delivery Protocol Capability Object Serialization . . 11
7. Capability Advertisement Object . . . . . . . . . . . . . . . 14 4.3. Acquisition Protocol Capability Object . . . . . . . . . 12
7.1. Base Advertisement Object . . . . . . . . . . . . . . . . 14 4.3.1. Acquisition Protocol Capability Object Serialization 12
7.2. Delivery Protocol Capability Object . . . . . . . . . . . 15 4.4. Redirection Mode Capability Object . . . . . . . . . . . 13
7.3. Acquisition Protocol Capability Object . . . . . . . . . 15 4.4.1. Redirection Mode Capability Object Serialization . . 13
7.4. Redirection Mode Capability Object . . . . . . . . . . . 16 4.5. CDNI Logging Capability Object . . . . . . . . . . . . . 14
7.5. Capability Advertisement Object Serialization . . . . . . 16 4.5.1. CDNI Logging Capability Object Serialization . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 4.6. CDNI Metadata Capability Object . . . . . . . . . . . . . 15
8.1. CDNI Payload Types . . . . . . . . . . . . . . . . . . . 17 4.6.1. CDNI Metadata Capability Object Serialization . . . . 16
8.1.1. CDNI FCI DeliveryProtocol Payload Type . . . . . . . 18 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8.1.2. CDNI FCI AcquisitionProtocol Payload Type . . . . . . 18 5.1. CDNI Payload Types . . . . . . . . . . . . . . . . . . . 17
8.1.3. CDNI FCI RedirectionMode Payload Type . . . . . . . . 18 5.1.1. CDNI FCI DeliveryProtocol Payload Type . . . . . . . 17
8.2. Redirection Mode Registry . . . . . . . . . . . . . . . . 18 5.1.2. CDNI FCI AcquisitionProtocol Payload Type . . . . . . 18
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 5.1.3. CDNI FCI RedirectionMode Payload Type . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 5.1.4. CDNI FCI Logging Payload Type . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . 20 5.1.5. CDNI FCI Metadata Payload Type . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . 21 5.2. Redirection Mode Registry . . . . . . . . . . . . . . . . 18
Appendix A. Acknowledgment . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.1. Normative References . . . . . . . . . . . . . . . . . . 20
7.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. Main Use Case to Consider . . . . . . . . . . . . . 21
Appendix B. Semantics for Footprint Advertisement . . . . . . . 22
Appendix C. Semantics for Capabilities Advertisement . . . . . . 24
Appendix D. Acknowledgment . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
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. This CDN interconnection (CDNI) interconnection of multiple CDNs. This CDN interconnection (CDNI)
can serve multiple purposes, as discussed in [RFC6770], for instance, can serve multiple purposes, as discussed in [RFC6770], for instance,
to extend the reach of a given CDN to areas in the network which are to extend the reach of a given CDN to areas in the 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 (dCDN) FCI), in particular the type of information a downstream CDN (dCDN)
'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 needs to 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 CDNI.
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 interconnected CDN 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
skipping to change at page 4, line 18 skipping to change at page 4, line 25
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 details 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.
1.1. Terminology
This document reuses the terminology defined in [RFC6707].
Additionally, the following terms are used throughout this document
and are defined as follows:
o Footprint: a description of a CDN's coverage area, i.e., the area
from which client requests may originate for, and to which the CDN
is willing to deliver, content. Note: There are many ways to
describe a footprint, for example, by address range (e.g., IPv4/
IPv6 CIDR), by network ID (e.g., ASN), by nation boundaries (e.g.,
country code), by GPS coordinates, etc. This document does not
define or endorse the quality or suitability of any particular
footprint description method; this document only defines a method
for transporting known footprint descriptions in Footprint and
Capabilities Advertisement messages.
o Capability: a feature of a dCDN, upon which a uCDN relies on the
dCDN supporting, when making delegation decisions. Support for a
given feature can change over time and can be restricted to a
limited portion of a dCDN's footprint. Note: There are many
possible dCDN features that could be of interest to a uCDN. This
document does not presume to define them all; this document
describes a scheme for defining new capabilities and how to
transport them in Footprint and Capabilities Advertisement
messages.
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; we refer to these as Some CDNs aspire to cover the entire world; we refer to these as
skipping to change at page 4, line 41 skipping to change at page 5, line 28
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 interconnect 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.
Furthermore, not all capabilities need to be footprint restricted. Furthermore, 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 understanding why a dCDN would advertise a
coverage area, and how a uCDN would use such advertisements to decide limited coverage area, and how a uCDN would use such advertisements
among one of several dCDNs. The following section will discuss some to decide among one of several dCDNs. The following section will
of the trade-offs and design decisions that need to be decided upon discuss some of the trade-offs and design decisions that need to be
for the CDNI FCI. decided upon for the CDNI FCI.
2.1. Advertising Limited Coverage 2.1. Advertising Limited Coverage
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
skipping to change at page 7, line 31 skipping to change at page 8, line 17
Overall, the information a dCDN advertises (in the long run) needs to 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 might 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 Capabilities with Footprint Restrictions
To narrow down semantics for "footprint" and "capabilities" in the
CDNI context, it can be useful to initially focus on key use cases to
be addressed by the CDNI WG that are to be envisioned in the main
deployments in the foreseeable future. In this regard, a main
realistic use case is the existence of ISP-owned CDNs, which
essentially cover a certain operator's network. At the same time,
however, the possibility of overlapping footprints cannot be
excluded, i.e., the scenario where more than one dCDN claims it can
serve a given end user request. The ISPs can also choose to
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 can 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 Further understanding that in most cases contractual agreements will
define the basic coverage used in delegation decisions, the primary
Focusing on a main use case that contains a simple (yet somewhat focus of FCI is on providing updates to the basic capabilities and
challenging), realistic, and generally imaginable scenario can help coverage by the dCDNs. As such, FCI has choosen the semantics of
in narrowing down the requirements for the CDNI FCI. To this end, "capabilities with footprint restrictions".
the following (simplified) use case can help in clarifying the
semantics of footprint and capabilities for CDNI. In particular, the
intention of the use case is to clarify what information needs to be
exchanged on the CDNI FCI, what types of information need to be
supported in a mandatory fashion (and which can be considered
optional), and what types of information need to be updated with
respect to a priori established CDNI contracts.
Use case: A given uCDN has several dCDNs. It selects one dCDN for
delivery protocol A and footprint 1 and another dCDN for delivery
protocol B and footprint 1. The dCDN that serves delivery protocol B
has a further, transitive (level-2) dCDN, that serves delivery
protocol B in a subset of footprint 1 where the first-level dCDN
cannot serve delivery protocol B itself. What happens if
capabilities change in the transitive level-2 dCDN that might affect
how the uCDN selects a level-1 dCDN (e.g., in case the level-2 dCDN
cannot serve delivery protocol B anymore)? How will these changes be
conveyed to the uCDN? In particular, what information does the uCDN
need to be able to select a new first-level dCDN, either for all of
footprint 1 or only for the subset of footprint 1 that the transitive
level-2 dCDN served on behalf of the first-level dCDN?
4. Semantics for Footprint Advertisement
Roughly speaking, "footprint" can be defined as "ability and
willingness to serve" by a dCDN. However, in addition to simple
"ability and willingness to serve", the uCDN could want additional
information to make a dCDN selection decision, e.g., "how well" a
given dCDN can actually serve a given end user request. The "ability
and willingness" to serve SHOULD be distinguished from the subjective
qualitative measurement of "how well" it was served. One can imagine
that such additional information is implicitly associated with a
given footprint, due to contractual agreements, SLAs, business
relationships, or past perceptions of dCDN quality. As an
alternative, such additional information could also be explicitly
tagged along with the footprint.
It is reasonable to assume that a significant part of the actual
footprint advertisement will happen in contractual agreements between
participating CDNs, prior to the advertisement phase using the CDNI
FCI. The reason for this assumption is that any contractual
agreement is likely to contain specifics about the dCDN coverage
(footprint) to which the contractual agreement applies. In
particular, additional information to judge the delivery quality
associated with a given dCDN footprint might be defined in
contractual agreements, outside of the CDNI FCI. Further, one can
assume that dCDN contractual agreements about the delivery quality
associated with a given footprint will probably be based on high-
level aggregated statistics and not too detailed.
Given that a large part of footprint advertisement will actually
happen in contractual agreements, the semantics of CDNI footprint
advertisement refer to answering the following question: what exactly
still needs to be advertised by the CDNI FCI? For instance, updates
about temporal failures of part of a footprint can be useful
information to convey via the CDNI request routing interface. Such
information would provide updates on information previously agreed in
contracts between the participating CDNs. In other words, the CDNI
FCI is a means for a dCDN to provide changes/updates regarding a
footprint it has prior agreed to serve in a contract with a uCDN.
Generally speaking, one can imagine two categories of footprint to be
advertised by a dCDN:
o Footprint could be defined based on "coverage/reachability", where
coverage/reachability refers to a set of prefixes, a geographic
region, or similar boundary. The dCDN claims that it can cover/
reach 'end user requests coming from this footprint'.
o Footprint could be defined based on "resources", where resources
refers to surrogates/caches a dCDN claims to have (e.g., the
location of surrogates/resources). The dCDN claims that 'from
this footprint' it can serve incoming end user requests.
For each of these footprint types, there are capabilities associated
with a given footprint:
o capabilities such as delivery protocol, redirection mode, and
metadata, which are supported in the coverage area for a
"coverage/reachability" defined footprint, or
o capabilities of resources, such as delivery protocol, redirection
mode, and metadata, which apply to a "resource" defined footprint.
It seems clear that "coverage/reachability" types of footprint MUST
be supported within CDNI. The following such types of footprint are
mandatory and MUST be supported by the CDNI FCI:
o List of ISO Country Codes
o List of AS numbers
o Set of IP-prefixes
A 'set of IP-prefixes' MUST be able to contain full IP addresses,
i.e., a /32 for IPv4 and a /128 for IPv6, as well as IP prefixes with
an arbitrary prefix length. There also MUST be support for multiple
IP address versions, i.e., IPv4 and IPv6, in such a footprint.
"Resource" types of footprints are more specific than "coverage/
reachability" types of footprints, where the actual coverage/
reachability are extrapolated from the resource location (e.g.,
netmask applied to resource IP address to derive IP-prefix). The
specific methods for extrapolating coverage/reachability from
resource location are beyond the scope of this document. In the
degenerate case, the resource address could be specified as a
coverage/reachability type of footprint, in which case no
extrapolation is necessary. Resource types of footprints could
expose the internal structure of a CDN network which could be
undesirable. As such, the resource types of footprints are not
considered mandatory to support for CDNI.
For all of these mandatory-to-implement footprint types, the 3. Footprint and Capabilities Extension
footprints can be viewed as constraints for delegating requests to a
dCDN: A dCDN footprint advertisement tells the uCDN the limitations
for delegating a request to the dCDN. For IP prefixes or ASN(s), the
footprint signals to the uCDN that it SHOULD consider the dCDN a
candidate only if the IP address of the request routing source falls
within the prefix set (or ASN, respectively). The CDNI
specifications do not define how a given uCDN determines what address
ranges are in a particular ASN. Similarly, for country codes a uCDN
SHOULD only consider the dCDN a candidate if it covers the country of
the request routing source. The CDNI specifications do not define
how a given uCDN determines the country of the request routing
source. Multiple footprint constraints are additive: the
advertisement of different types of footprint narrows the dCDN
candidacy cumulatively.
In addition to these mandatory "coverage/reachability" types of Other optional "coverage/reachability" types of footprint or
footprint, other optional "coverage/reachability" types of footprint "resource" types of footprint may be 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 This document also registers CDNI Payload Types [RFC7736] for the
include the connectivity of a given dCDN to other CDNs that are able initial capability types (see Section 5):
to serve content to users on behalf of that dCDN, to cover cases with
cascaded CDNs. Further, the dCDN needs to be able to express its
footprint to an interested uCDN in a comprehensive form, e.g., as a
data set containing the complete footprint. Making incremental
updates, however, to express dynamic changes in state is also
desirable.
5. Semantics for Capabilities Advertisement
In general, the dCDN MUST be able to express its general capabilities
to the uCDN. These general capabilities could express if the dCDN
supports a given service, for instance, HTTP vs HTTPS delivery.
Furthermore, the dCDN MUST be able to express particular capabilities
for the delivery in a particular footprint area. For example, the
dCDN might in general offer HTTPS but not in some specific areas,
either for maintenance reasons or because the caches covering this
particular area cannot deliver this type of service. Hence, in
certain cases footprint and capabilities are tied together and cannot
be interpreted independently from each other. In such cases, i.e.,
where capabilities need to be expressed on a per footprint basis, it
could be beneficial to combine footprint and capabilities
advertisement.
A high-level and very rough semantic for capabilities is thus the
following: Capabilities are types of information that allow a uCDN to
determine if a dCDN is able (and willing) to accept (and properly
handle) a delegated content request. In addition, Capabilities are
characterized by the fact that this information can change over time
based on the state of the network or caches.
At a first glance, several broad categories of capabilities seem
useful to convey via an advertisement interface, however, advertising
capabilities that change highly dynamically (e.g., real-time delivery
performance metrics, CDN resource load, or other highly dynamically
changing QoS information) is beyond the scope for CDNI FCI. First,
out of the multitude of possible metrics and capabilities, it is hard
to agree on a subset and the precise metrics to be used. Second, it
seems infeasible to specify such highly dynamically changing
capabilities and the corresponding metrics within a reasonable time-
frame.
Useful capabilities refer to information that does not change highly
dynamically and which in many cases is absolutely necessary to decide
on a particular dCDN for a given end user request. For instance, if
an end user request concerns the delivery of a video file with a
certain protocol, the uCDN needs to know if a given dCDN has the
capability of supporting this delivery protocol.
Similar to footprint advertisement, it is reasonable to assume that a
significant part of the actual (resource) capabilities advertisement
will happen in contractual agreements between participating CDNs,
i.e., prior to the advertisement phase using the CDNI FCI. The role
of capability advertisement is hence rather to enable the dCDN to
update a uCDN on changes since a contract has been set up (e.g., in
case a new delivery protocol is suddenly being added to the list of
supported delivery protocols of a given dCDN, or in case a certain
delivery protocol is suddenly not being supported anymore due to
failures). Capabilities advertisement thus refers to conveying
information to a uCDN about changes/updates of certain capabilities
with respect to a given contract.
Given these semantics, it needs to be decided what exact capabilities
are useful and how these can be expressed. Since the details of CDNI
contracts are not known at the time of this writing (and the CDNI
interface are better off being agnostic to these contracts anyway),
it remains to be seen what capabilities will be used to define
agreements between CDNs in practice. One implication for
standardization could be to initially only specify a very limited set
of mandatory capabilities for advertisement and have on top of that a
flexible data model that allows exchanging additional capabilities
when needed. Still, agreement needs to be found on which
capabilities (if any) will be mandatory among CDNs. As discussed in
Section 2.5, finding the concrete answers to these questions can
benefit from focusing on a small number of key use cases that are
highly relevant and contain enough complexity to help in
understanding what concrete capabilities are needed to facilitate CDN
Interconnection.
Under the above considerations, the following capabilities seem
useful as 'base' capabilities, i.e., ones that are needed in any case
and therefore constitute mandatory capabilities that MUST be
supported by the CDNI FCI:
o Delivery Protocol (for delivering content to the end user) o Delivery Protocol (for delivering content to the end user)
o Acquisition Protocol (for acquiring content from the uCDN or o Acquisition Protocol (for acquiring content from the uCDN or
origin server) origin server)
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 13, line 4 skipping to change at page 9, line 9
o Delivery Protocol (for delivering content to the end user) o Delivery Protocol (for delivering content to the end user)
o Acquisition Protocol (for acquiring content from the uCDN or o Acquisition Protocol (for acquiring content from the uCDN or
origin server) origin server)
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 feasible to enumerate all the possible options for the Each payload type is prefaced with "FCI.". Updates to capability
mandatory capabilities listed above (e.g., all the potential delivery objects MUST indicate the version of the capability object in a newly
protocols or metadata options) or anticipate all the future needs for registered payload type, e.g., by appending ".v2". Each capability
additional capabilities. It would be unreasonable to burden the CDNI type MAY have a list of valid values. Future specifications which
FCI specification with defining each supported capability. Instead, define a given capability MUST define any necessary registries (and
the CDNI FCI specification SHOULD define a generic protocol for the rules for adding new entries to the registry) for the values
conveying any capability information (e.g. with common encoding, advertised for a given capability type.
error handling, and security mechanism; further requirements for the
CDNI FCI Advertisement Interface are listed in [RFC7337]). In this
respect, it seems reasonable to initially define the mandatory
capabilities listed above and extend the list as needs dictate. This
document registers CDNI Payload Types [RFC7736] for the mandatory
capability types (see Section 8), prefixing each payload type with
"FCI". Updates to capability objects MUST indicate the version of
the capability object in a newly registered payload type, e.g., by
appending ".v2". Each capability type MAY have a list of valid
values. Future specifications which define a given capability MUST
define any necessary registries (and the rules for adding new entries
to the registry) for the values advertised for a given capability
type.
The "CDNI Logging record-types" registry [I-D.ietf-cdni-logging] The "CDNI Logging record-types" registry [I-D.ietf-cdni-logging]
defines all known record types, including mandatory-to-implement defines all known record types, including mandatory-to-implement
record-types Advertising support for mandatory-to-implement record- record-types Advertising support for mandatory-to-implement record-
types would be redundant. CDNs SHOULD NOT advertise support for types would be redundant. CDNs SHOULD NOT advertise support for
mandatory-to-implement record-types. mandatory-to-implement record-types.
The "CDNI Logging Fields Names" registry [I-D.ietf-cdni-logging] The "CDNI Logging Fields Names" registry [I-D.ietf-cdni-logging]
defines all known logging fields. Logging fields may be reused by defines all known logging fields. Logging fields may be reused by
different record-types and be mandatory-to-implement in some record- different record-types and be mandatory-to-implement in some record-
skipping to change at page 14, line 11 skipping to change at page 10, line 5
requires that CDNs be able to parse all the defined metadata objects, requires that CDNs be able to parse all the defined metadata objects,
but does not require dCDNs to support enforcement of non-structural but does not require dCDNs to support enforcement of non-structural
GenericMetadata objects. Advertising support for mandatory-to- GenericMetadata objects. Advertising support for mandatory-to-
enforce GenericMetadata types MUST be supported. Advertising support enforce GenericMetadata types MUST be supported. Advertising support
for non-mandatory-to-enforce GenericMetadata types SHOULD be for non-mandatory-to-enforce GenericMetadata types SHOULD be
supported. Advertisement of non-mandatory-to-enforce GenericMetadata supported. Advertisement of non-mandatory-to-enforce GenericMetadata
MAY be necessary, e.g., to signal temporary outages and subsequent MAY be necessary, e.g., to signal temporary outages and subsequent
recovery. It is expected that structural metadata will be supported recovery. It is expected that structural metadata will be supported
at all times. at all times.
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 might 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 MUST specify how protocol. In particular, any FCI solution protocol MUST specify 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 dCDN does not understand; in this case it only selects a suitable dCDN
based on the types of capabilities and footprint it understands. based on the types of capabilities and footprint it understands.
Similarly, if a dCDN does not use an optional capability or footprint Similarly, if a dCDN does not use an optional capability or footprint
which is, however, supported by a uCDN, this causes no problem for which is, however, supported by a uCDN, this causes no problem for
the FCI functionality because the uCDN decides on the remaining the FCI functionality because the uCDN decides on the remaining
capabilities/footprint information that is being conveyed by the capabilities/footprint information that is being conveyed by the
dCDN. dCDN.
7. Capability Advertisement Object 4. Capability Advertisement Object
To support extensibility, the FCI defines a generic base object To support extensibility, the FCI defines a generic base object
(similar to the CDNI Metadata interface GenericMetadata object) (similar to the CDNI Metadata interface GenericMetadata object)
[I-D.ietf-cdni-metadata] to facilitate a uniform set of mandatory [I-D.ietf-cdni-metadata] to facilitate a uniform set of mandatory
parsing requirements for all future FCI objects. parsing requirements for all future FCI objects.
Future object definitions (e.g. regarding CDNI Metadata or Logging) Future object definitions (e.g. regarding CDNI Metadata or Logging)
will build off the base object defined here, but will be specified in will build off the base object defined here, but will be specified in
separate documents. separate documents.
7.1. Base Advertisement Object 4.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: FCI specific CDNI Payload type (from the CDNI Payload Type: FCI specific CDNI Payload type (from the CDNI Payload
Types registry [RFC7736]) Types registry [RFC7736])
skipping to change at page 15, line 28 skipping to change at page 11, line 19
Property: footprints Property: footprints
Description: CDNI Capability Footprint. Description: CDNI Capability Footprint.
Type: List of CDNI Footprint objects (as defined in Type: List of CDNI Footprint objects (as defined in
[I-D.ietf-cdni-metadata]). [I-D.ietf-cdni-metadata]).
Mandatory-to-Specify: No. Mandatory-to-Specify: No.
7.2. Delivery Protocol Capability Object 4.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 Protocol for one or more of the protocols listed in the CDNI Metadata Protocol
Types 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 Protocol Type: List of Protocol Types (from the CDNI Metadata Protocol
Types 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 4.2.1. Delivery Protocol Capability Object Serialization
The following shows an example of Delivery Protocol Capability Object
Serialization, for a CDN that supports only HTTP/1.1 without TLS for
content delivery.
{
"capabilities": [
{
"capability-type": "FCI.DeliveryProtocol",
"capability-value": {
"delivery-protocols": [
"http1.1",
]
},
"footprints": [
<Footprint objects>
]
}
]
}
4.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
Protocol Types registry (defined in the CDNI Metadata Interface Protocol Types registry (defined in the CDNI Metadata Interface
document [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 Protocol Type: List of Protocol Types (from the CDNI Metadata Protocol
Types 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 4.3.1. Acquisition Protocol Capability Object Serialization
The following shows an example of Acquisition Protocol Capability
Object Serialization, for a CDN that supports HTTP/1.1 with or
without TLS for content acquisition.
{
"capabilities": [
{
"capability-type": "FCI.AcquisitionProtocol",
"capability-value": {
"acquisition-protocols": [
"http1.1",
"https1.1"
]
},
"footprints": [
<Footprint objects>
]
}
]
}
4.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.2). Redirection Modes registry (see Section 5.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.2) Type: List of Redirection Modes (from Section 5.2)
Mandatory-to-Specify: Yes. Mandatory-to-Specify: Yes.
7.5. Capability Advertisement Object Serialization 4.4.1. Redirection Mode Capability Object Serialization
The following shows an example of CDNI FCI Capability Advertisement The following shows an example of Redirection Mode Capability Object
Object Serialization. Serialization, for a CDN that supports only iterative (but not
recursive) redirection with HTTP and DNS.
{ {
"capabilities": [ "capabilities": [
{ {
"capability-type": "FCI.DeliveryProtocol", "capability-type": "FCI.RedirectionMode",
"capability-value": { "capability-value": {
"delivery-protocols": [ "redirection-modes": [
"http1.1" "DNS-I",
"HTTP-I"
] ]
}
"footprints": [
<Footprint objects>
]
}
]
}
4.5. CDNI Logging Capability Object
The CDNI Logging capability object is used to indicate support for
CDNI Logging record-types, as well as CDNI Logging fields which are
marked as optional for the specified record-types
[I-D.ietf-cdni-logging].
Property: record-type
Description: Supported CDNI Logging record-type.
Type: String corresponding to an entry from the CDNI Logging
record-types registry [I-D.ietf-cdni-logging])
Mandatory-to-Specify: Yes.
Property: fields
Description: List of supported CDNI Logging fields that are
optional for the specified record-type.
Type: List of Strings corresponding to entries from the CDNI
Logging Field Names registry [I-D.ietf-cdni-logging].
Mandatory-to-Specify: No. Default is that all optional fields
are supported. Inclusion of an empty list SHALL be understood
to mean that none of the optional fields are supported.
Otherwise, only those optional fields that are listed SHALL be
understood to be supported.
4.5.1. CDNI Logging Capability Object Serialization
The following shows an example of CDNI Logging Capability Object
Serialization, for a CDN that supports the optional Content
Collection ID logging field (but not the optional Session ID logging
field) for the "cdni_http_request_v1" record type.
{
"capabilities": [
{
"capability-type": "FCI.Logging",
"capability-value": {
"record-type": "cdni_http_request_v1",
"fields": [ "s-ccid" ]
}, },
"footprints": [ "footprints": [
<Footprint objects> <Footprint objects>
] ]
}, }
]
}
The next example shows the CDNI Logging Capability Object
Serialization, for a CDN that supports all optional fields for the
"cdni_http_request_v1" record type.
{
"capabilities": [
{ {
"capability-type": "FCI.AcquisitionProtocol", "capability-type": "FCI.Logging",
"capability-value": { "capability-value": {
"acquisition-protocols": [ "record-type": "cdni_http_request_v1"
"http1.1", },
"https1.1" "footprints": [
] <Footprint objects>
} ]
}, }
]
}
4.6. CDNI Metadata Capability Object
The CDNI Metadata capability object is used to indicate support for
CDNI GenericMetadata types [I-D.ietf-cdni-metadata].
Property: metadata
Description: List of supported CDNI GenericMetadata types.
Type: List of Strings corresponding to entries from the CDNI
Payload Type registry [RFC7736]) that correspond to CDNI
GenericMetadata objects.
Mandatory-to-Specify: Yes. It SHALL be understood that only
those GenericMetadata types listed are supported; an empty list
SHALL be understood to mean that only structural metadata and
simple types are supported [I-D.ietf-cdni-metadata].
4.6.1. CDNI Metadata Capability Object Serialization
The following shows an example of CDNI Metadata Capability Object
Serialization, for a CDN that supports only the SourceMetadata
GenericMetadata type (i.e., it can acquire and deliver content, but
cannot enforce and security policies, e.g., time, location, or
protocol ACLs).
{
"capabilities": [
{ {
"capability-type": "FCI.RedirectionMode", "capability-type": "FCI.Metadata",
"capability-value": { "capability-value": {
"redirection-modes": [ "metadata": ["MI.SourceMetadata"]
"DNS-I", },
"HTTP-I" "footprints": [
] <Footprint objects>
} ]
} }
] ]
} }
8. IANA Considerations The next example shows the CDNI Metadata Capability Object
Serialization, for a CDN that supports only structural metadata
(i.e., it can parse metadata as a transit CDN, but cannot enforce
security policies or deliver content).
8.1. CDNI Payload Types {
"capabilities": [
{
"capability-type": "FCI.Metadata",
"capability-value": {
"metadata": []
},
"footprints": [
<Footprint objects>
]
}
]
}
5. IANA Considerations
5.1. CDNI Payload Types
This document requests the registration of the following CDNI Payload This document requests the registration of the following CDNI Payload
Types under the IANA CDNI Payload Type registry: Types under the IANA CDNI Payload Type registry:
+-------------------------+---------------+ +-------------------------+---------------+
| Payload Type | Specification | | Payload Type | Specification |
+-------------------------+---------------+ +-------------------------+---------------+
| FCI.DeliveryProtocol | RFCthis | | FCI.DeliveryProtocol | RFCthis |
| | | | | |
| FCI.AcquisitionProtocol | RFCthis | | FCI.AcquisitionProtocol | RFCthis |
| | | | | |
| FCI.RedirectionMode | RFCthis | | FCI.RedirectionMode | RFCthis |
| | |
| FCI.Logging | RFCthis |
| | |
| FCI.Metadata | 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.]
8.1.1. CDNI FCI DeliveryProtocol Payload Type 5.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.2 and Section 7.5 Encoding: see Section 4.2
8.1.2. CDNI FCI AcquisitionProtocol Payload Type 5.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.3 and Section 7.5 Encoding: see Section 4.3
8.1.3. CDNI FCI RedirectionMode Payload Type 5.1.3. CDNI FCI RedirectionMode 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 redirection modes advertisement objects for supported redirection modes
Interface: FCI Interface: FCI
Encoding: see Section 7.4 and Section 7.5 Encoding: see Section 4.4
8.2. Redirection Mode Registry 5.1.4. CDNI FCI Logging Payload Type
Purpose: The purpose of this payload type is to distinguish FCI
advertisement objects for supported CDNI Logging record-types and
optional CDNI Logging Field Names.
Interface: FCI
Encoding: see Section 4.5
5.1.5. CDNI FCI Metadata Payload Type
Purpose: The purpose of this payload type is to distinguish FCI
advertisement objects for supported CDNI GenericMetadata types.
Interface: FCI
Encoding: see Section 4.6
5.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 can 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:
skipping to change at page 19, line 24 skipping to change at page 19, line 20
| DNS-R | Recursive DNS-based Redirection | RFCthis | | DNS-R | Recursive DNS-based Redirection | RFCthis |
| | | | | | | |
| HTTP-I | Iterative HTTP-based Redirection | RFCthis | | HTTP-I | Iterative HTTP-based Redirection | RFCthis |
| | | | | | | |
| 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 6. Security Considerations
This specification describes the semantics for capabilities and This specification describes the semantics for capabilities and
footprint advertisement objects across interconnected CDNs. It does footprint advertisement objects across interconnected CDNs. It 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
skipping to change at page 20, line 16 skipping to change at page 20, line 10
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 (e.g., TLS transport coupled with domain certificates as credentials (e.g., TLS transport
for HTTP as per [RFC2818] and [RFC7230], with usage guidance from for HTTP as per [RFC2818] and [RFC7230], with usage guidance from
[RFC7525]). There is no apparent need for further object-level [RFC7525]). There is no apparent need for further object-level
security in this framework, as the trust relationships it defines are security in this framework, as the trust relationships it defines are
bilateral relationships between uCDNs and dCDNs rather than bilateral relationships between uCDNs and dCDNs rather than
transitive relationships. transitive relationships.
10. References 7. References
10.1. Normative References 7.1. Normative 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-25 (work in progress), April 2016. logging-25 (work in progress), April 2016.
[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-15 (work in progress), April 2016. metadata-15 (work in progress), April 2016.
skipping to change at page 21, line 11 skipping to change at page 21, line 5
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014, RFC 7230, DOI 10.17487/RFC7230, June 2014,
<http://www.rfc-editor.org/info/rfc7230>. <http://www.rfc-editor.org/info/rfc7230>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <http://www.rfc-editor.org/info/rfc7525>. 2015, <http://www.rfc-editor.org/info/rfc7525>.
10.2. Informative References 7.2. Informative References
[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, DOI 10.17487/RFC6707, September Statement", RFC 6707, DOI 10.17487/RFC6707, September
2012, <http://www.rfc-editor.org/info/rfc6707>. 2012, <http://www.rfc-editor.org/info/rfc6707>.
[RFC6770] Bertrand, G., Ed., Stephan, E., Burbridge, T., Eardley, [RFC6770] Bertrand, G., Ed., Stephan, E., Burbridge, T., Eardley,
P., Ma, K., and G. Watson, "Use Cases for Content Delivery P., Ma, K., and G. Watson, "Use Cases for Content Delivery
Network Interconnection", RFC 6770, DOI 10.17487/RFC6770, Network Interconnection", RFC 6770, DOI 10.17487/RFC6770,
November 2012, <http://www.rfc-editor.org/info/rfc6770>. November 2012, <http://www.rfc-editor.org/info/rfc6770>.
skipping to change at page 21, line 37 skipping to change at page 21, line 31
[RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution [RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution
Network Interconnection (CDNI) Requirements", RFC 7337, Network Interconnection (CDNI) Requirements", RFC 7337,
DOI 10.17487/RFC7337, August 2014, DOI 10.17487/RFC7337, August 2014,
<http://www.rfc-editor.org/info/rfc7337>. <http://www.rfc-editor.org/info/rfc7337>.
[RFC7736] Ma, K., "Content Delivery Network Interconnection (CDNI) [RFC7736] Ma, K., "Content Delivery Network Interconnection (CDNI)
Media Type Registration", RFC 7736, DOI 10.17487/RFC7736, Media Type Registration", RFC 7736, DOI 10.17487/RFC7736,
December 2015, <http://www.rfc-editor.org/info/rfc7736>. December 2015, <http://www.rfc-editor.org/info/rfc7736>.
Appendix A. Acknowledgment Appendix A. Main Use Case to Consider
Focusing on a main use case that contains a simple (yet somewhat
challenging), realistic, and generally imaginable scenario can help
in narrowing down the requirements for the CDNI FCI. To this end,
the following (simplified) use case can help in clarifying the
semantics of footprint and capabilities for CDNI. In particular, the
intention of the use case is to clarify what information needs to be
exchanged on the CDNI FCI, what types of information need to be
supported in a mandatory fashion (and which can be considered
optional), and what types of information need to be updated with
respect to a priori established CDNI contracts.
Use case: A given uCDN has several dCDNs. It selects one dCDN for
delivery protocol A and footprint 1 and another dCDN for delivery
protocol B and footprint 1. The dCDN that serves delivery protocol B
has a further, transitive (level-2) dCDN, that serves delivery
protocol B in a subset of footprint 1 where the first-level dCDN
cannot serve delivery protocol B itself. What happens if
capabilities change in the transitive level-2 dCDN that might affect
how the uCDN selects a level-1 dCDN (e.g., in case the level-2 dCDN
cannot serve delivery protocol B anymore)? How will these changes be
conveyed to the uCDN? In particular, what information does the uCDN
need to be able to select a new first-level dCDN, either for all of
footprint 1 or only for the subset of footprint 1 that the transitive
level-2 dCDN served on behalf of the first-level dCDN?
Appendix B. Semantics for Footprint Advertisement
Roughly speaking, "footprint" can be defined as "ability and
willingness to serve" by a dCDN. However, in addition to simple
"ability and willingness to serve", the uCDN could want additional
information to make a dCDN selection decision, e.g., "how well" a
given dCDN can actually serve a given end user request. The "ability
and willingness" to serve SHOULD be distinguished from the subjective
qualitative measurement of "how well" it was served. One can imagine
that such additional information is implicitly associated with a
given footprint, due to contractual agreements, SLAs, business
relationships, or past perceptions of dCDN quality. As an
alternative, such additional information could also be explicitly
tagged along with the footprint.
It is reasonable to assume that a significant part of the actual
footprint advertisement will happen in contractual agreements between
participating CDNs, prior to the advertisement phase using the CDNI
FCI. The reason for this assumption is that any contractual
agreement is likely to contain specifics about the dCDN coverage
(footprint) to which the contractual agreement applies. In
particular, additional information to judge the delivery quality
associated with a given dCDN footprint might be defined in
contractual agreements, outside of the CDNI FCI. Further, one can
assume that dCDN contractual agreements about the delivery quality
associated with a given footprint will probably be based on high-
level aggregated statistics and not too detailed.
Given that a large part of footprint advertisement will actually
happen in contractual agreements, the semantics of CDNI footprint
advertisement refer to answering the following question: what exactly
still needs to be advertised by the CDNI FCI? For instance, updates
about temporal failures of part of a footprint can be useful
information to convey via the CDNI request routing interface. Such
information would provide updates on information previously agreed in
contracts between the participating CDNs. In other words, the CDNI
FCI is a means for a dCDN to provide changes/updates regarding a
footprint it has prior agreed to serve in a contract with a uCDN.
Generally speaking, one can imagine two categories of footprint to be
advertised by a dCDN:
o Footprint could be defined based on "coverage/reachability", where
coverage/reachability refers to a set of prefixes, a geographic
region, or similar boundary. The dCDN claims that it can cover/
reach 'end user requests coming from this footprint'.
o Footprint could be defined based on "resources", where resources
refers to surrogates/caches a dCDN claims to have (e.g., the
location of surrogates/resources). The dCDN claims that 'from
this footprint' it can serve incoming end user requests.
For each of these footprint types, there are capabilities associated
with a given footprint:
o capabilities such as delivery protocol, redirection mode, and
metadata, which are supported in the coverage area for a
"coverage/reachability" defined footprint, or
o capabilities of resources, such as delivery protocol, redirection
mode, and metadata, which apply to a "resource" defined footprint.
"Resource" types of footprints are more specific than "coverage/
reachability" types of footprints, where the actual coverage/
reachability are extrapolated from the resource location (e.g.,
netmask applied to resource IP address to derive IP-prefix). The
specific methods for extrapolating coverage/reachability from
resource location are beyond the scope of this document. In the
degenerate case, the resource address could be specified as a
coverage/reachability type of footprint, in which case no
extrapolation is necessary. Resource types of footprints could
expose the internal structure of a CDN network which could be
undesirable. As such, the resource types of footprints are not
considered mandatory to support for CDNI.
Footprints can be viewed as constraints for delegating requests to a
dCDN: A dCDN footprint advertisement tells the uCDN the limitations
for delegating a request to the dCDN. For IP prefixes or ASN(s), the
footprint signals to the uCDN that it should consider the dCDN a
candidate only if the IP address of the request routing source falls
within the prefix set (or ASN, respectively). The CDNI
specifications do not define how a given uCDN determines what address
ranges are in a particular ASN. Similarly, for country codes a uCDN
should only consider the dCDN a candidate if it covers the country of
the request routing source. The CDNI specifications do not define
how a given uCDN determines the country of the request routing
source. Multiple footprint constraints are additive: the
advertisement of different types of footprint narrows the dCDN
candidacy cumulatively.
Independent of the exact type of a footprint, a footprint might also
include the connectivity of a given dCDN to other CDNs that are able
to serve content to users on behalf of that dCDN, to cover cases with
cascaded CDNs. Further, the dCDN needs to be able to express its
footprint to an interested uCDN in a comprehensive form, e.g., as a
data set containing the complete footprint. Making incremental
updates, however, to express dynamic changes in state is also
desirable.
Appendix C. Semantics for Capabilities Advertisement
In general, the dCDN needs to be able to express its general
capabilities to the uCDN. These general capabilities could express
if the dCDN supports a given service, for instance, HTTP vs HTTPS
delivery. Furthermore, the dCDN needs to be able to express
particular capabilities for the delivery in a particular footprint
area. For example, the dCDN might in general offer HTTPS but not in
some specific areas, either for maintenance reasons or because the
caches covering this particular area cannot deliver this type of
service. Hence, in certain cases footprint and capabilities are tied
together and cannot be interpreted independently from each other. In
such cases, i.e., where capabilities need to be expressed on a per
footprint basis, it could be beneficial to combine footprint and
capabilities advertisement.
A high-level and very rough semantic for capabilities is thus the
following: Capabilities are types of information that allow a uCDN to
determine if a dCDN is able (and willing) to accept (and properly
handle) a delegated content request. In addition, Capabilities are
characterized by the fact that this information can change over time
based on the state of the network or caches.
At a first glance, several broad categories of capabilities seem
useful to convey via an advertisement interface, however, advertising
capabilities that change highly dynamically (e.g., real-time delivery
performance metrics, CDN resource load, or other highly dynamically
changing QoS information) is beyond the scope for CDNI FCI. First,
out of the multitude of possible metrics and capabilities, it is hard
to agree on a subset and the precise metrics to be used. Second, it
seems infeasible to specify such highly dynamically changing
capabilities and the corresponding metrics within a reasonable time-
frame.
Useful capabilities refer to information that does not change highly
dynamically and which in many cases is absolutely necessary to decide
on a particular dCDN for a given end user request. For instance, if
an end user request concerns the delivery of a video file with a
certain protocol, the uCDN needs to know if a given dCDN has the
capability of supporting this delivery protocol.
Similar to footprint advertisement, it is reasonable to assume that a
significant part of the actual (resource) capabilities advertisement
will happen in contractual agreements between participating CDNs,
i.e., prior to the advertisement phase using the CDNI FCI. The role
of capability advertisement is hence rather to enable the dCDN to
update a uCDN on changes since a contract has been set up (e.g., in
case a new delivery protocol is suddenly being added to the list of
supported delivery protocols of a given dCDN, or in case a certain
delivery protocol is suddenly not being supported anymore due to
failures). Capabilities advertisement thus refers to conveying
information to a uCDN about changes/updates of certain capabilities
with respect to a given contract.
Given these semantics, it needs to be decided what exact capabilities
are useful and how these can be expressed. Since the details of CDNI
contracts are not known at the time of this writing (and the CDNI
interface are better off being agnostic to these contracts anyway),
it remains to be seen what capabilities will be used to define
agreements between CDNs in practice. One implication for
standardization could be to initially only specify a very limited set
of mandatory capabilities for advertisement and have on top of that a
flexible data model that allows exchanging additional capabilities
when needed. Still, agreement needs to be found on which
capabilities (if any) will be mandatory among CDNs.
It is not feasible to enumerate all the possible options for the
mandatory capabilities listed above (e.g., all the potential delivery
protocols or metadata options) or anticipate all the future needs for
additional capabilities. It would be unreasonable to burden the CDNI
FCI specification with defining each supported capability. Instead,
the CDNI FCI specification should define a generic protocol for
conveying any capability information (e.g. with common encoding,
error handling, and security mechanism; further requirements for the
CDNI FCI Advertisement Interface are listed in [RFC7337]).
Appendix D. 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
interpreted as necessarily representing the official policies or interpreted as necessarily representing the official policies or
endorsements, either expressed or implied, of the GreenICN project, endorsements, either expressed or implied, of the GreenICN project,
 End of changes. 50 change blocks. 
332 lines changed or deleted 520 lines changed or added

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