draft-ietf-cdni-footprint-capabilities-semantics-20.txt   rfc8008.txt 
CDNI J. Seedorf Internet Engineering Task Force (IETF) J. Seedorf
Internet-Draft NEC Request for Comments: 8008 HFT Stuttgart - Univ. of Applied Sciences
Intended status: Standards Track J. Peterson Category: Standards Track J. Peterson
Expires: November 21, 2016 Neustar ISSN: 2070-1721 Neustar
S. Previdi S. Previdi
Cisco Cisco
R. van Brandenburg R. van Brandenburg
TNO TNO
K. Ma K. Ma
Ericsson Ericsson
May 20, 2016 December 2016
CDNI Request Routing: Footprint and Capabilities Semantics Content Delivery Network Interconnection (CDNI) Request Routing:
draft-ietf-cdni-footprint-capabilities-semantics-20 Footprint and Capabilities Semantics
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 Content Delivery Network
interface, i.e., the desired meaning of "Footprint" and Interconnection (CDNI) Request Routing interface, i.e., the desired
"Capabilities" in the CDNI context, and what the "Footprint and meaning of "Footprint" and "Capabilities" in the CDNI context and
Capabilities Advertisement Interface (FCI)" offers within CDNI. The what the "Footprint & Capabilities Advertisement interface (FCI)"
document also provides guidelines for the CDNI FCI protocol. It offers within CDNI. The document also provides guidelines for the
further defines a Base Advertisement Object, the necessary registries CDNI FCI protocol. It further defines a Base Advertisement Object,
for capabilities and footprints, and guidelines on how these the necessary registries for capabilities and footprints, and
registries can be extended in the future. guidelines on how these registries can be extended in the future.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is a product of the Internet Engineering Task Force
Task Force (IETF). Note that other groups may also distribute (IETF). It represents the consensus of the IETF community. It has
working documents as Internet-Drafts. The list of current Internet- received public review and has been approved for publication by the
Drafts is at http://datatracker.ietf.org/drafts/current/. Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Internet-Drafts are draft documents valid for a maximum of six months Information about the current status of this document, any errata,
and may be updated, replaced, or obsoleted by other documents at any and how to provide feedback on it may be obtained at
time. It is inappropriate to use Internet-Drafts as reference http://www.rfc-editor.org/info/rfc8008.
material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 21, 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 ..........................................4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology ................................................5
2. Design Decisions for Footprint and Capabilities . . . . . . . 5 2. Design Decisions for Footprint and Capabilities .................6
2.1. Advertising Limited Coverage . . . . . . . . . . . . . . 5 2.1. Advertising Limited Coverage ...............................6
2.2. Capabilities and Dynamic Data . . . . . . . . . . . . . . 6 2.2. Capabilities and Dynamic Data ..............................7
2.3. Advertisement versus Queries . . . . . . . . . . . . . . 7 2.3. Advertisement versus Queries ...............................8
2.4. Avoiding or Handling 'cheating' dCDNs . . . . . . . . . . 7 2.4. Avoiding or Handling "Cheating" dCDNs ......................8
3. Focusing on Capabilities with Footprint Restrictions . . . . 8 3. Focusing on Capabilities with Footprint Restrictions ............9
4. Footprint and Capabilities Extension . . . . . . . . . . . . 8 4. Footprint and Capabilities Extension ............................9
5. Capability Advertisement Object . . . . . . . . . . . . . . . 10 5. Capability Advertisement Object ................................11
5.1. Base Advertisement Object . . . . . . . . . . . . . . . . 10 5.1. Base Advertisement Object .................................12
5.2. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 11 5.2. Encoding ..................................................12
5.3. Delivery Protocol Capability Object . . . . . . . . . . . 11 5.3. Delivery Protocol Capability Object .......................13
5.3.1. Delivery Protocol Capability Object Serialization . . 12 5.3.1. Delivery Protocol Capability Object Serialization ..13
5.4. Acquisition Protocol Capability Object . . . . . . . . . 12 5.4. Acquisition Protocol Capability Object ....................14
5.4.1. Acquisition Protocol Capability Object Serialization 13 5.4.1. Acquisition Protocol Capability Object
5.5. Redirection Mode Capability Object . . . . . . . . . . . 13 Serialization ......................................14
5.5.1. Redirection Mode Capability Object Serialization . . 13 5.5. Redirection Mode Capability Object ........................15
5.6. CDNI Logging Capability Object . . . . . . . . . . . . . 14 5.5.1. Redirection Mode Capability Object Serialization ...15
5.6.1. CDNI Logging Capability Object Serialization . . . . 15 5.6. CDNI Logging Capability Object ............................16
5.7. CDNI Metadata Capability Object . . . . . . . . . . . . . 15 5.6.1. CDNI Logging Capability Object Serialization .......17
5.7.1. CDNI Metadata Capability Object Serialization . . . . 16 5.7. CDNI Metadata Capability Object ...........................18
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 5.7.1. CDNI Metadata Capability Object Serialization ......19
6.1. CDNI Payload Types . . . . . . . . . . . . . . . . . . . 17 6. IANA Considerations ............................................20
6.1.1. CDNI FCI DeliveryProtocol Payload Type . . . . . . . 17 6.1. CDNI Payload Types ........................................20
6.1.2. CDNI FCI AcquisitionProtocol Payload Type . . . . . . 18 6.1.1. CDNI FCI DeliveryProtocol Payload Type .............20
6.1.3. CDNI FCI RedirectionMode Payload Type . . . . . . . . 18 6.1.2. CDNI FCI AcquisitionProtocol Payload Type ..........20
6.1.4. CDNI FCI Logging Payload Type . . . . . . . . . . . . 18 6.1.3. CDNI FCI RedirectionMode Payload Type ..............20
6.1.5. CDNI FCI Metadata Payload Type . . . . . . . . . . . 18 6.1.4. CDNI FCI Logging Payload Type ......................21
6.1.5. CDNI FCI Metadata Payload Type .....................21
6.2. Redirection Mode Registry . . . . . . . . . . . . . . . . 18 6.2. "CDNI Capabilities Redirection Modes" Registry ............21
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7. Security Considerations ........................................22
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. References .....................................................23
8.1. Normative References . . . . . . . . . . . . . . . . . . 20 8.1. Normative References ......................................23
8.2. Informative References . . . . . . . . . . . . . . . . . 20 8.2. Informative References ....................................24
Appendix A. Main Use Case to Consider . . . . . . . . . . . . . 21 Appendix A. Main Use Case to Consider .............................25
Appendix B. Semantics for Footprint Advertisement . . . . . . . 22 Appendix B. Semantics for Footprint Advertisement .................25
Appendix C. Semantics for Capabilities Advertisement . . . . . . 24 Appendix C. Semantics for Capabilities Advertisement ..............27
Appendix D. Acknowledgment . . . . . . . . . . . . . . . . . . . 25 Acknowledgments ...................................................30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses ................................................30
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. These CDNI protocols can serve
can serve multiple purposes, as discussed in [RFC6770], for instance, multiple purposes, as discussed in [RFC6770] -- for instance, to
to extend the reach of a given CDN to areas in the network which are extend the reach of a given CDN to areas in the network that are not
not covered by this particular CDN. covered by that 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) the FCI) [RFC7336], in particular the type of information a
'advertises' regarding its footprint and capabilities. To narrow downstream CDN (dCDN) "advertises" regarding its footprint and
down undecided aspects of these semantics, this document tries to capabilities. To narrow down undecided aspects of these semantics,
establish a common understanding of what the FCI needs to offer and this document tries to establish a common understanding of what the
accomplish in the context of CDNI. FCI needs to offer and accomplish in the context of CDNI.
It is explicitly outside the scope of this document to decide on Deciding on specific protocols to use for the FCI is explicitly
specific protocols to use for the FCI. However, guidelines for such outside the scope of this document. However, we provide guidelines
FCI protocols are provided. for such FCI protocols.
General assumptions in this document: We make the following general assumptions in this document:
o The CDNs participating in the interconnected CDN have already o The CDNs participating in the CDN interconnection have already
performed a boot strap process, i.e., they have connected to each performed a bootstrap 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 upstream CDN (uCDN) receives footprint and/or capability o The upstream CDN (uCDN) receives footprint advertisements and/or
advertisements from a set of dCDNs. Footprint advertisement and capability advertisements from a set of dCDNs. Footprint
capability advertisement need not use the same underlying advertisements and capability advertisements need not use the same
protocol. underlying protocol.
o The uCDN receives the initial request-routing request from the o The uCDN receives the initial Request Routing message from the
endpoint requesting the resource. endpoint requesting the resource.
The CDNI Problem Statement [RFC6707] describes the Request Routing The CDNI problem statement [RFC6707] describes the Request Routing
Interface as: "[enabling] a Request Routing function in a uCDN to interface as "[enabling] a Request Routing function in an Upstream
query a Request Routing function in a dCDN to determine if the dCDN CDN to query a Request Routing function in a Downstream CDN to
is able (and willing) to accept the delegated Content Request". In determine if the Downstream CDN is able (and willing) to accept the
addition, RFC6707 says "the CDNI Request Routing interface is also delegated Content Request." In addition, [RFC6707] says "the CDNI
expected to enable a dCDN to provide to the uCDN (static or dynamic) Request Routing interface is also expected to enable a Downstream CDN
information (e.g., resources, footprint, load) to facilitate to provide to the Upstream CDN (static or dynamic) information (e.g.,
selection of the dCDN by the uCDN request routing system when resources, footprint, load) to facilitate selection of the Downstream
processing subsequent content requests from User Agents". It thus CDN by the Upstream CDN Request Routing system when processing
considers "resources" and "load" as capabilities to be advertised by subsequent Content Requests from User Agents." It thus considers
the dCDN. "resources" and "load" as capabilities to be advertised by the dCDN.
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 document [RFC7337] lists the specific requirements for
CDNI Footprint & Capabilities Advertisement Interface in order to the CDNI FCI in order to disambiguate footprints and capabilities
disambiguate footprints and capabilities with respect to CDNI. This with respect to CDNI. This document defines a common understanding
document defines a common understanding of what the terms 'footprint' of what the terms "footprint" and "capabilities" mean in the context
and 'capabilities' mean in the context of CDNI, and details the of CDNI and details the semantics of the footprint advertisement
semantics of the footprint advertisement mechanism and the capability mechanism and the capability advertisement mechanism.
advertisement mechanism.
1.1. Terminology 1.1. Terminology
This document reuses the terminology defined in [RFC6707]. This document reuses the terminology defined in [RFC6707].
Additionally, the following terms are used throughout this document Additionally, the following terms are used throughout this document
and are defined as follows: and are defined as follows:
o Footprint: a description of a CDN's coverage area, i.e., the area 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 from which client requests may originate for content and to which
is willing to deliver, content. Note: There are many ways to the CDN is willing to deliver content. Note: There are many ways
describe a footprint, for example, by address range (e.g., IPv4/ to describe a footprint -- for example, by address range (e.g.,
IPv6 CIDR), by network ID (e.g., ASN), by nation boundaries (e.g., IPv4 CIDR or IPv6 CIDR (Classless Inter-Domain Routing), network
country code), by GPS coordinates, etc. This document does not ID (e.g., Autonomous System Number (ASN)), nation boundaries
(e.g., country code), or GPS coordinates. This document does not
define or endorse the quality or suitability of any particular define or endorse the quality or suitability of any particular
footprint description method; this document only defines a method footprint description method; rather, it only defines a method for
for transporting known footprint descriptions in Footprint and transporting known footprint descriptions in Footprint and
Capabilities Advertisement messages. Capabilities Advertisement messages.
o Capability: a feature of a dCDN, upon which a uCDN relies on the o Capability: a feature of a dCDN upon whose support a uCDN relies
dCDN supporting, when making delegation decisions. Support for a when making delegation decisions. Support for a given feature can
given feature can change over time and can be restricted to a change over time and can be restricted to a limited portion of a
limited portion of a dCDN's footprint. Note: There are many dCDN's footprint. Note: There are many possible dCDN features
possible dCDN features that could be of interest to a uCDN. This that could be of interest to a uCDN. This document does not
document does not presume to define them all; this document presume to define them all; rather, it describes a scheme for
describes a scheme for defining new capabilities and how to defining new capabilities and how to transport them in Footprint
transport them in Footprint and Capabilities Advertisement and Capabilities Advertisement messages.
messages.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
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 a 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 surrogates, a surrogate with CDNs pick strategic locations to situate Surrogates, a Surrogate with
a public IPv4 address is reachable by any endpoint on the Internet a public IPv4 address is reachable by any endpoint on the Internet,
unless some policy enforcement precludes the use of the surrogate. unless some policy enforcement precludes the use of the Surrogate.
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
global CDNs. The footprint advertised by such a CDN in the CDNI 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 area
seek to interconnect with other CDNs in order to create a single CDN but seek to interconnect with other CDNs in order to create a single
fabric which shares resources. CDN fabric that 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 advertisements
advertisement lies in understanding why a dCDN would advertise a and capability advertisements lies in understanding why a dCDN would
limited coverage area, and how a uCDN would use such advertisements advertise a limited coverage area and how a uCDN would use such
to decide among one of several dCDNs. The following section will advertisements to decide among one of several dCDNs. The following
discuss some of the trade-offs and design decisions that need to be section will discuss some of the trade-offs and design decisions that
decided upon for the CDNI FCI. need to be made 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 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 surrogates in close serve only their own customers by situating Surrogates 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 surrogates were easily construct a list of prefixes that its Surrogates were
positioned to serve. positioned to serve.
When such a purpose-built CDN interconnects with other CDNs and When such a purpose-built CDN interconnects with other CDNs and
advertises its footprint to a uCDN, however, the original intended advertises its footprint to a uCDN, however, the original intended
coverage of the CDN might not represent its actual value to the coverage of the CDN might not represent its actual value to the
interconnection of CDNs. Consider an ISP-A and ISP-B that both field interconnection of CDNs. Consider an ISP-A and ISP-B that both field
their own CDNs, which they interconnect via CDNI. A given user E, their own CDNs, which they interconnect via CDNI. A given user E,
who is a customer of ISP-B, might happen to be topologically closer who is a customer of ISP-B, might happen to be topologically closer
to a surrogate fielded by ISP-A, if E happens to live in a region to a Surrogate fielded by ISP-A, if E happens to live in a region
where ISP-B has few customers and ISP-A has many. In this case, is where ISP-B has few customers and ISP-A has many. In this case, is
it ISP-A's CDN that "covers" E? If ISP-B's CDN has a failure it ISP-A's CDN that "covers" E? If ISP-B's CDN has a failure
condition, is it up to the uCDN to understand that ISP-A's surrogates condition, is it up to the uCDN to understand that ISP-A's Surrogates
are potentially available as back-ups - and if so, how does ISP-A are potentially available as backups, and if so, how does ISP-A
advertise itself as a "standby" for E? What about the case where advertise itself as a "standby" for E? What about the case where
CDNs advertising to the same uCDN express overlapping coverage (for CDNs advertising to the same uCDN express overlapping coverage (for
example, mixing global and limited CDNs)? 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 select a dCDN. If a uCDN has three dCDNs to
three dCDNs to choose from that "cover" the IP address of user E, choose from that "cover" the IP address of user E, obviously the uCDN
obviously the uCDN might be interested to know how optimal the might be interested in knowing how optimal the coverage is from each
coverage is from each of the dCDNs - coverage need not be binary, of the dCDNs. Coverage need not be binary (i.e., either provided or
either provided or not provided. dCDNs could advertise a coverage not provided); dCDNs could advertise a coverage "score", for example,
"score," for example, and provided that they all reported scores and provided that they all reported scores fairly on the same scale,
fairly on the same scale, uCDNs could use that to make their uCDNs could use that information to make their topological optimality
topological optimality decision. Alternately, dCDNs could advertise decision. Alternately, dCDNs could advertise the IP addresses of
the IP addresses of their surrogates rather than prefix "coverage," their Surrogates rather than prefix "coverage" and let the uCDN
and let the uCDN decide for itself (based on its own topological decide for itself (based on its own topological intelligence) which
intelligence) which dCDN has better resources to serve a given user. 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 a footprint depend on
such qualitative metrics for expressing footprint (such as the whether (1) such qualitative metrics for expressing a footprint (such
coverage 'score' mentioned above) are included as part of the CDNI as the coverage "score" mentioned above) are included as part of the
FCI, or if the focus is just on 'binary' footprint. CDNI FCI or (2) the focus is just on a "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 surrogates themselves, of dCDNs. These include facts related to the Surrogates themselves,
to the network where the surrogate is deployed, to the nature of the the network where the Surrogate is deployed, the nature of the
resource sought, and to the administrative policies of the respective resource sought, and the administrative policies of the respective
networks. networks.
In the absence of network-layer impediments to reaching surrogates, In the absence of network-layer impediments to reaching Surrogates,
the choice to limit coverage is necessarily an administrative policy. the choice to limit coverage is, by necessity, an administrative
Much policy needs to be agreed upon before CDNs can interconnect, policy. Much policy needs to be agreed upon before CDNs can
including questions of membership, compensation, volumes, and so on. interconnect, including questions of membership, compensation,
A uCDN certainly will factor these sorts of considerations into its volumes, and so on. A uCDN certainly will factor these sorts of
decision to select a dCDN, but there is probably little need for considerations into its decision to select a dCDN, but there is
dCDNs to actually advertise them through an interface - they will be probably little need for dCDNs to actually advertise them through an
settled out-of-band as a precondition for interconnection. interface -- they will be settled out-of-band as a precondition for
interconnection.
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 highly dynamic. Expressing the total storage built into its
surrogates, for example, changes relatively rarely, whereas the Surrogates, for example, changes relatively rarely, whereas the
amount of storage in use at any given moment is highly volatile. amount of storage in use at any given moment is highly volatile.
Network bandwidth similarly could be expressed as either total Network bandwidth similarly could be expressed either as total
bandwidth available to a surrogate, or based on the current state of bandwidth available to a Surrogate or based on the current state of
the network. A surrogate can at one moment lack a particular the network. A Surrogate can at one moment lack a particular
resource in storage, but have it the next. resource in storage but have it the 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 needs to be updated. how often that information needs to be updated.
2.3. Advertisement versus Queries 2.3. Advertisement versus Queries
In a CDNI environment, each dCDN shares some of its state with the In a CDNI environment, each dCDN shares some of its state with the
uCDN. The uCDN uses this information to build a unified picture of uCDN. The uCDN uses this information to build a unified picture of
all of the dCDNs available to it. In architectures that share all of the dCDNs available to it. In architectures that share
detailed capability information, the uCDN could perform the entire detailed capability information, the uCDN could perform the entire
request-routing operation down to selecting a particular surrogate in Request Routing operation down to selecting a particular Surrogate in
the dCDN. However, when the uCDN needs to deal with many potential the dCDN. However, when the uCDN needs to deal with many potential
dCDNs, this approach does not scale, especially for dCDNs with dCDNs, this approach does not scale, especially for dCDNs with
thousands or tens of thousands of surrogates; the volume of updates thousands or tens of thousands of Surrogates; the volume of updates
to footprint and capability becomes onerous. to the footprint and the capability information becomes 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
could effectively operate in a stateless mode. could effectively operate in a stateless mode.
The semantics of both footprint and capability advertisement depend The semantics of both footprint advertisements and capability
on the service model here: are there cases where a synchronous query/ advertisements depend on the service model here: are there cases
response model would work better for the uCDN decision than a state where a synchronous query/response model would work better for the
replication model? uCDN decision than a state replication model?
2.4. Avoiding or Handling 'cheating' dCDNs 2.4. Avoiding or Handling "Cheating" dCDNs
In a situation where more than one dCDN is willing to serve a given In a situation where more than one dCDN is willing to serve a given
end user request, it might be attractive for a dCDN to 'cheat' in the end user request, it might be attractive for a dCDN to "cheat" in the
sense that the dCDN provides inaccurate information to the uCDN in sense that the dCDN provides inaccurate information to the uCDN in
order to convince the uCDN to select it 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. On 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 (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.
3. Focusing on Capabilities with Footprint Restrictions 3. Focusing on Capabilities with Footprint Restrictions
Given the design considerations listed in the previous section, it Given the design considerations listed in the previous section, it
seems reasonable to assume that in most cases it is the uCDN that seems reasonable to assume that in most cases it is the uCDN that
makes the decision on selecting a certain dCDN for request routing makes the decision to select a certain dCDN for Request Routing based
based on information the uCDN has received from this particular dCDN. on information the uCDN has received from this particular dCDN. It
It can be assumed that 'cheating' CDNs will be dealt with via means can be assumed that cheating dCDNs will be dealt with via means
outside the scope of CDNI and that the information advertised between outside the scope of CDNI and that the information advertised between
CDNs is accurate. In addition, excluding the use of qualitative CDNs is accurate. In addition, excluding the use of qualitative
information (e.g., surrogate proximity, delivery latency, surrogate information (e.g., Surrogate proximity, delivery latency, Surrogate
load) to predict the quality of delivery would further simplify the load) to predict the quality of delivery would further simplify the
use case allowing it to better focus on the basic functionality of use case, allowing it to better focus on the basic functionality of
the FCI. the FCI.
Further understanding that in most cases contractual agreements will Furthermore, understanding that in most cases contractual agreements
define the basic coverage used in delegation decisions, the primary will define the basic coverage used in delegation decisions, the
focus of FCI is on providing updates to the basic capabilities and primary focus of the FCI is on providing updates to the basic
coverage by the dCDNs. As such, FCI has choosen the semantics of capabilities and coverage by the dCDNs. As such, the FCI has chosen
"capabilities with footprint restrictions". the semantics of "capabilities with footprint restrictions".
4. Footprint and Capabilities Extension 4. Footprint and Capabilities Extension
Other optional "coverage/reachability" types of footprint or Other optional "coverage/reachability" footprint types or "resource"
"resource" types of footprint may be defined by future footprint types may be defined by future specifications. To
specifications. To facilitate this, a clear process for specifying facilitate this, a clear process for specifying optional footprint
optional footprint types in an IANA registry is specified in the CDNI types in an IANA registry is specified in the "CDNI Metadata
Metadata Footprint Types registry (defined in the CDNI Metadata Footprint Types" registry (defined in the CDNI Metadata interface
Interface document [I-D.ietf-cdni-metadata]). document [RFC8006]).
This document also registers CDNI Payload Types [RFC7736] for the This document also registers CDNI Payload Types [RFC7736] for the
initial capability types (see Section 6): initial capability types (see Section 6):
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 CDNI Logging fields)
o CDNI Metadata (i.e., supported Generic Metadata types) o CDNI Metadata (i.e., supported GenericMetadata types)
Each payload type is prefaced with "FCI.". Updates to capability Each Payload Type is prefaced with "FCI.". Updates to capability
objects MUST indicate the version of the capability object in a newly objects MUST indicate the version of the capability object in a newly
registered payload type, e.g., by appending ".v2". Each capability registered Payload Type, e.g., by appending ".v2". Each capability
type MAY have a list of valid values. Future specifications which type MAY have a list of valid values. Future specifications that
define a given capability MUST define any necessary registries (and define a given capability MUST define any necessary registries (and
the rules for adding new entries to the registry) for the values the rules for adding new entries to the registry) for the values
advertised for a given capability type. advertised for a given capability type.
The "CDNI Logging record-types" registry [I-D.ietf-cdni-logging] The "CDNI Logging record-types" registry [RFC7937] defines all known
defines all known record types, including mandatory-to-implement record-types, including "mandatory-to-implement" record-types.
record-types Advertising support for mandatory-to-implement record- Advertising support for mandatory-to-implement record-types would be
types would be redundant. CDNs SHOULD NOT advertise support for 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 Field Names" registry [RFC7937] defines all known
defines all known logging fields. Logging fields may be reused by CDNI Logging fields. CDNI Logging fields may be reused by different
different record-types and be mandatory-to-implement in some record- record-types and be mandatory-to-implement in some record-types, but
types, but optional in other record-types. CDNs MUST advertise they may be optional in other record-types. CDNs MUST advertise
support for optional logging fields within the context of a specific support for optional CDNI Logging fields within the context of a
record-type. CDNs SHOULD NOT advertise support for mandatory-to- specific record-type. For a given record-type, CDNs SHOULD NOT
implement logging fields, for a given record-type. The following advertise support for mandatory-to-implement CDNI Logging fields.
logging fields are defined as optional for the "cdni_http_request_v1" The following CDNI Logging fields are defined as optional for the
record-type in the CDNI Logging Interface document "cdni_http_request_v1" record-type [RFC7937]:
[I-D.ietf-cdni-logging]:
o s-ccid o s-ccid
o s-sid o s-sid
The CDNI Metadata Interface document [I-D.ietf-cdni-metadata] [RFC8006] requires that CDNs be able to parse all the defined
requires that CDNs be able to parse all the defined metadata objects, metadata objects but does not require dCDNs to support enforcement of
but does not require dCDNs to support enforcement of non-structural non-structural GenericMetadata objects. Advertising support for
GenericMetadata objects. Advertising support for mandatory-to- "mandatory-to-enforce" GenericMetadata types MUST be provided.
enforce GenericMetadata types MUST be supported. Advertising support Advertising support for non-mandatory-to-enforce GenericMetadata
for non-mandatory-to-enforce GenericMetadata types SHOULD be types SHOULD be provided. Advertisement of non-mandatory-to-enforce
supported. Advertisement of non-mandatory-to-enforce GenericMetadata GenericMetadata MAY be necessary, e.g., to signal temporary outages
MAY be necessary, e.g., to signal temporary outages and subsequent and subsequent recovery. It is expected that structural metadata
recovery. It is expected that structural metadata will be supported will be supported at all times.
at all times.
The notion of optional types of footprint and capabilities implies The notion of optional footprint types and capability types implies
that certain implementations might not support all kinds of footprint that certain implementations might not support all kinds of
and capabilities. Therefore, any FCI solution protocol MUST define footprints and capabilities. Therefore, any FCI solution protocol
how the support for optional types of footprint/capabilities will be MUST define how the support for optional footprint types and
negotiated between a uCDN and a dCDN that use the particular FCI capability types will be negotiated between a uCDN and a dCDN that
protocol. In particular, any FCI solution protocol MUST specify how use the particular FCI protocol. In particular, any FCI solution
to handle failure cases or non-supported types of footprint/ protocol MUST specify how to handle failure cases or non-supported
capabilities. footprint or capability types.
In general, a uCDN MAY ignore capabilities or types of footprints it In general, a uCDN MAY ignore capabilities or footprint types it does
does not understand; in this case it only selects a suitable dCDN not understand; in this case, it only selects a suitable dCDN based
based on the types of capabilities and footprint it understands. on the types of capabilities and footprints 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 that is, however, supported by a uCDN, this causes no problem for FCI
the FCI functionality because the uCDN decides on the remaining 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
dCDN. the dCDN.
5. Capability Advertisement Object 5. 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 [RFC8006] to facilitate a uniform set of mandatory parsing
parsing requirements for all future FCI objects. requirements for all future FCI objects.
Future object definitions (e.g. regarding CDNI Metadata or Logging) Future object definitions (e.g., regarding the CDNI Metadata or CDNI
will build off the base object defined here, but will be specified in Logging interfaces) will build off the base object defined here but
separate documents. will be specified in separate documents.
Note: In the following sections, the term "mandatory-to-specify" is Note: In the following sections, the term "mandatory-to-specify" is
used to convey which properties MUST be included when serializing a used to convey which properties MUST be included when serializing a
given capability object. When mandatory-to-specify is defined as given capability object. When mandatory-to-specify is defined as
"Yes" for an individual property, it means that if the object "Yes" for an individual property, it means that if the object
containing that property is included in an FCI message, then the containing that property is included in an FCI message, then the
mandatory-to-specify property MUST also be included. mandatory-to-specify property MUST also be included.
5.1. Base Advertisement Object 5.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])
Mandatory-to-Specify: Yes. Mandatory-to-Specify: Yes.
Property: capability-value Property: capability-value
Description: CDNI Capability object. Description: CDNI capability object.
Type: Format/Type is defined by the value of capability-type Type: Format/Type is defined by the value of the
property above. capability-type property above
Mandatory-to-Specify: Yes. Mandatory-to-Specify: Yes.
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 (from the "CDNI Metadata
[I-D.ietf-cdni-metadata]). Footprint Types" registry [RFC8006])
Mandatory-to-Specify: No. Mandatory-to-Specify: No.
5.2. Encoding 5.2. Encoding
CDNI FCI objects MUST be encoded using JSON [RFC7159] and MUST also CDNI FCI objects MUST be encoded using JSON [RFC7159] and MUST also
follow the recommendations of I-JSON [RFC7493]. FCI objects are follow the recommendations of I-JSON (Internet JSON) [RFC7493]. FCI
composed of a dictionary of (key,value) pairs where the keys are the objects are composed of a dictionary of (key,value) pairs where the
property names and the values are the associated property values. keys are the property names and the values are the associated
property values.
The keys of the dictionary are the names of the properties associated The keys of the dictionary are the names of the properties associated
with the object and are therefore dependent on the specific object with the object and are therefore dependent on the specific object
being encoded (i.e., dependent on the CDNI Payload Type of the being encoded (i.e., dependent on the CDNI Payload Type of the
capability or the CDNI Metadata Footprint Type of the footprint). capability or the CDNI Metadata Footprint Type of the footprint).
Likewise, the values associated with each property (dictionary key) Likewise, the values associated with each property (dictionary key)
are dependent on the specific object being encoded (i.e., dependent are dependent on the specific object being encoded (i.e., dependent
on the CDNI Payload Type of the capability or the CDNI Metadata on the CDNI Payload Type of the capability or the CDNI Metadata
Footprint Type of the footprint). Footprint Type of the footprint).
Dictionary keys (properties) in JSON are case sensitive. By Dictionary keys (properties) in JSON are case sensitive. By
convention, any dictionary key (property) defined by this document convention, any dictionary key (property) defined by this document
MUST be lowercase. MUST be lowercase.
5.3. Delivery Protocol Capability Object 5.3. 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
Types registry (defined in the CDNI Metadata Interface document Protocol Types" registry (defined in [RFC8006]).
[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 [RFC8006])
Mandatory-to-Specify: Yes. Mandatory-to-Specify: Yes.
5.3.1. Delivery Protocol Capability Object Serialization 5.3.1. Delivery Protocol Capability Object Serialization
The following shows an example of Delivery Protocol Capability Object The following shows an example of Delivery Protocol capability object
Serialization, for a CDN that supports only HTTP/1.1 without TLS for serialization for a CDN that supports only HTTP/1.1 without Transport
content delivery. Layer Security (TLS) for content delivery.
{ {
"capabilities": [ "capabilities": [
{ {
"capability-type": "FCI.DeliveryProtocol", "capability-type": "FCI.DeliveryProtocol",
"capability-value": { "capability-value": {
"delivery-protocols": [ "delivery-protocols": [
"http/1.1", "http/1.1",
] ]
}, },
"footprints": [ "footprints": [
<Footprint objects> <Footprint objects>
] ]
} }
] ]
} }
5.4. Acquisition Protocol Capability Object 5.4. 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 [RFC8006]).
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
Types" registry [RFC8006])
Type: List of Protocol Types (from the CDNI Metadata Protocol
Types registry [I-D.ietf-cdni-metadata])
Mandatory-to-Specify: Yes. Mandatory-to-Specify: Yes.
5.4.1. Acquisition Protocol Capability Object Serialization 5.4.1. Acquisition Protocol Capability Object Serialization
The following shows an example of Acquisition Protocol Capability The following shows an example of Acquisition Protocol capability
Object Serialization, for a CDN that supports HTTP/1.1 with or object serialization for a CDN that supports HTTP/1.1 with or without
without TLS for content acquisition. TLS for content acquisition.
{ {
"capabilities": [ "capabilities": [
{ {
"capability-type": "FCI.AcquisitionProtocol", "capability-type": "FCI.AcquisitionProtocol",
"capability-value": { "capability-value": {
"acquisition-protocols": [ "acquisition-protocols": [
"http/1.1", "http/1.1",
"https/1.1" "https/1.1"
] ]
skipping to change at page 13, line 32 skipping to change at page 15, line 8
"footprints": [ "footprints": [
<Footprint objects> <Footprint objects>
] ]
} }
] ]
} }
5.5. Redirection Mode Capability Object 5.5. 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 6.2). Redirection Modes" registry (see Section 6.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 6.2) Type: List of redirection modes (from the "CDNI Capabilities
Redirection Modes" registry, defined in Section 6.2)
Mandatory-to-Specify: Yes. Mandatory-to-Specify: Yes.
5.5.1. Redirection Mode Capability Object Serialization 5.5.1. Redirection Mode Capability Object Serialization
The following shows an example of Redirection Mode Capability Object The following shows an example of Redirection Mode capability object
Serialization, for a CDN that supports only iterative (but not serialization for a CDN that supports only iterative (i.e., not
recursive) redirection with HTTP and DNS. recursive) redirection with HTTP and DNS.
{ {
"capabilities": [ "capabilities": [
{ {
"capability-type": "FCI.RedirectionMode", "capability-type": "FCI.RedirectionMode",
"capability-value": { "capability-value": {
"redirection-modes": [ "redirection-modes": [
"DNS-I", "DNS-I",
"HTTP-I" "HTTP-I"
skipping to change at page 14, line 25 skipping to change at page 16, line 8
"footprints": [ "footprints": [
<Footprint objects> <Footprint objects>
] ]
} }
] ]
} }
5.6. CDNI Logging Capability Object 5.6. CDNI Logging Capability Object
The CDNI Logging capability object is used to indicate support for The CDNI Logging capability object is used to indicate support for
CDNI Logging record-types, as well as CDNI Logging fields which are CDNI Logging record-types, as well as CDNI Logging fields that are
marked as optional for the specified record-types marked as optional for the specified record-types [RFC7937].
[I-D.ietf-cdni-logging].
Property: record-type Property: record-type
Description: Supported CDNI Logging record-type. Description: Supported CDNI Logging record-type.
Type: String corresponding to an entry from the CDNI Logging Type: String corresponding to an entry from the "CDNI Logging
record-types registry [I-D.ietf-cdni-logging]) record-types" registry [RFC7937]
Mandatory-to-Specify: Yes. Mandatory-to-Specify: Yes.
Property: fields Property: fields
Description: List of supported CDNI Logging fields that are Description: List of supported CDNI Logging fields that are
optional for the specified record-type. optional for the specified record-type.
Type: List of Strings corresponding to entries from the CDNI Type: List of strings corresponding to entries from the "CDNI
Logging Field Names registry [I-D.ietf-cdni-logging]. Logging Field Names" registry [RFC7937]
Mandatory-to-Specify: No. Default is that all optional fields Mandatory-to-Specify: No. Default is that all optional fields
are supported. Omission of this field MUST be interpreted as are supported. Omission of this field MUST be interpreted as
"all optional fields are supported". An empty list MUST be "all optional fields are supported". An empty list MUST be
interpreted as "no optional fields are supported. Otherwise, interpreted as "no optional fields are supported". Otherwise,
if a list of fields is provided, the fields in that list MUST if a list of fields is provided, the fields in that list MUST
be interpreted as "the only optional fields that are be interpreted as "the only optional fields that are
supported". supported".
5.6.1. CDNI Logging Capability Object Serialization 5.6.1. CDNI Logging Capability Object Serialization
The following shows an example of CDNI Logging Capability Object The following shows an example of CDNI Logging capability object
Serialization, for a CDN that supports the optional Content serialization for a CDN that supports the optional Content
Collection ID logging field (but not the optional Session ID logging Collection ID CDNI Logging field (but not the optional Session ID
field) for the "cdni_http_request_v1" record type. CDNI Logging field) for the "cdni_http_request_v1" record-type.
{ {
"capabilities": [ "capabilities": [
{ {
"capability-type": "FCI.Logging", "capability-type": "FCI.Logging",
"capability-value": { "capability-value": {
"record-type": "cdni_http_request_v1", "record-type": "cdni_http_request_v1",
"fields": [ "s-ccid" ] "fields": ["s-ccid"]
}, },
"footprints": [ "footprints": [
<Footprint objects> <Footprint objects>
] ]
} }
] ]
} }
The next example shows the CDNI Logging Capability Object The next example shows the CDNI Logging capability object
Serialization, for a CDN that supports all optional fields for the serialization for a CDN that supports all optional fields for the
"cdni_http_request_v1" record type. "cdni_http_request_v1" record-type.
{ {
"capabilities": [ "capabilities": [
{ {
"capability-type": "FCI.Logging", "capability-type": "FCI.Logging",
"capability-value": { "capability-value": {
"record-type": "cdni_http_request_v1" "record-type": "cdni_http_request_v1"
}, },
"footprints": [ "footprints": [
<Footprint objects> <Footprint objects>
] ]
} }
] ]
} }
The final example shows the CDNI Logging capability object
serialization for a CDN that supports none of the optional fields for
the "cdni_http_request_v1" record-type.
{
"capabilities": [
{
"capability-type": "FCI.Logging",
"capability-value": {
"record-type": "cdni_http_request_v1",
"fields": []
},
"footprints": [
<Footprint objects>
]
}
]
}
5.7. CDNI Metadata Capability Object 5.7. CDNI Metadata Capability Object
The CDNI Metadata capability object is used to indicate support for The CDNI Metadata capability object is used to indicate support for
CDNI GenericMetadata types [I-D.ietf-cdni-metadata]. CDNI GenericMetadata types [RFC8006].
Property: metadata Property: metadata
Description: List of supported CDNI GenericMetadata types. Description: List of supported CDNI GenericMetadata types.
Type: List of Strings corresponding to entries from the CDNI Type: List of strings corresponding to entries from the "CDNI
Payload Type registry [RFC7736]) that correspond to CDNI Payload Types" registry [RFC7736] that correspond to CDNI
GenericMetadata objects. GenericMetadata objects
Mandatory-to-Specify: Yes. An empty list MUST be interpreted Mandatory-to-Specify: Yes. An empty list MUST be interpreted
as "no GenericMetadata types are supported", i.e., "only as "no GenericMetadata types are supported", i.e., "only
structural metadata and simple types are supported"; otherwise, structural metadata and simple types are supported"; otherwise,
the list must be interpreted as containing "the only the list must be interpreted as containing "the only
GenericMetadata types that are supported" (in addition to GenericMetadata types that are supported" (in addition to
structural metadata and simple types) [I-D.ietf-cdni-metadata]. structural metadata and simple types) [RFC8006].
5.7.1. CDNI Metadata Capability Object Serialization 5.7.1. CDNI Metadata Capability Object Serialization
The following shows an example of CDNI Metadata Capability Object The following shows an example of CDNI Metadata capability object
Serialization, for a CDN that supports only the SourceMetadata serialization for a CDN that supports only the SourceMetadata
GenericMetadata type (i.e., it can acquire and deliver content, but GenericMetadata type (i.e., it can acquire and deliver content but
cannot enforce and security policies, e.g., time, location, or cannot enforce any security policies, e.g., time, location, or
protocol ACLs). protocol Access Control Lists (ACLs)).
{ {
"capabilities": [ "capabilities": [
{ {
"capability-type": "FCI.Metadata", "capability-type": "FCI.Metadata",
"capability-value": { "capability-value": {
"metadata": ["MI.SourceMetadata"] "metadata": ["MI.SourceMetadata"]
}, },
"footprints": [ "footprints": [
<Footprint objects> <Footprint objects>
] ]
} }
] ]
} }
The next example shows the CDNI Metadata Capability Object The next example shows the CDNI Metadata capability object
Serialization, for a CDN that supports only structural metadata serialization for a CDN that supports only structural metadata (i.e.,
(i.e., it can parse metadata as a transit CDN, but cannot enforce it can parse metadata as a transit CDN but cannot enforce security
security policies or deliver content). policies or deliver content).
{ {
"capabilities": [ "capabilities": [
{ {
"capability-type": "FCI.Metadata", "capability-type": "FCI.Metadata",
"capability-value": { "capability-value": {
"metadata": [] "metadata": []
}, },
"footprints": [ "footprints": [
<Footprint objects> <Footprint objects>
] ]
} }
] ]
} }
6. IANA Considerations 6. IANA Considerations
6.1. CDNI Payload Types 6.1. CDNI Payload Types
This document requests the registration of the following CDNI Payload This document registers the following CDNI Payload Types under the
Types under the IANA CDNI Payload Type registry: IANA "CDNI Payload Types" registry:
+-------------------------+---------------+ +-------------------------+---------------+
| Payload Type | Specification | | Payload Type | Specification |
+-------------------------+---------------+ +-------------------------+---------------+
| FCI.DeliveryProtocol | RFCthis | | FCI.DeliveryProtocol | RFC 8008 |
| | | | FCI.AcquisitionProtocol | RFC 8008 |
| FCI.AcquisitionProtocol | RFCthis | | FCI.RedirectionMode | RFC 8008 |
| | | | FCI.Logging | RFC 8008 |
| FCI.RedirectionMode | RFCthis | | FCI.Metadata | RFC 8008 |
| | |
| FCI.Logging | RFCthis |
| | |
| FCI.Metadata | RFCthis |
+-------------------------+---------------+ +-------------------------+---------------+
[RFC Editor: Please replace RFCthis with the published RFC number for
this document.]
6.1.1. CDNI FCI DeliveryProtocol Payload Type 6.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 5.3 Encoding: see Section 5.3
6.1.2. CDNI FCI AcquisitionProtocol Payload Type 6.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 5.4 Encoding: see Section 5.4
6.1.3. CDNI FCI RedirectionMode Payload Type 6.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 5.5 Encoding: see Section 5.5
6.1.4. CDNI FCI Logging Payload Type 6.1.4. CDNI FCI Logging 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 CDNI Logging record-types and advertisement objects for supported CDNI Logging record-types and
optional CDNI Logging Field Names. optional CDNI Logging field names
Interface: FCI Interface: FCI
Encoding: see Section 5.6 Encoding: see Section 5.6
6.1.5. CDNI FCI Metadata Payload Type 6.1.5. CDNI FCI Metadata 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 CDNI GenericMetadata types. advertisement objects for supported CDNI GenericMetadata types
Interface: FCI Interface: FCI
Encoding: see Section 5.7 Encoding: see Section 5.7
6.2. Redirection Mode Registry 6.2. "CDNI Capabilities Redirection Modes" Registry
The IANA is requested to create a new "CDNI Capabilities Redirection IANA has created a new "CDNI Capabilities Redirection Modes" registry
Modes" registry in the "Content Delivery Networks Interconnection in the "Content Delivery Network Interconnection (CDNI) Parameters"
(CDNI) Parameters" category. The "CDNI Capabilities Redirection registry. The "CDNI Capabilities Redirection Modes" namespace
Modes" namespace defines the valid redirection modes that can be defines the valid redirection modes that can be advertised as
advertised as supported by a CDN. Additions to the Redirection Mode supported by a CDN. Additions to the "CDNI Capabilities Redirection
namespace conform to the "IETF Review" policy as defined in Modes" 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 |
+------------------+----------------------------------+---------+
| DNS-I | Iterative DNS-based Redirection | RFCthis |
| | | |
| DNS-R | Recursive DNS-based Redirection | RFCthis |
| | | |
| HTTP-I | Iterative HTTP-based Redirection | RFCthis |
| | | |
| HTTP-R | Recursive HTTP-based Redirection | RFCthis |
+------------------+----------------------------------+---------+
[RFC Editor: Please replace RFCthis with the published RFC number for +------------------+----------------------------------+----------+
this document.] | Redirection Mode | Description | RFC |
+------------------+----------------------------------+----------+
| DNS-I | Iterative DNS-based Redirection | RFC 8008 |
| DNS-R | Recursive DNS-based Redirection | RFC 8008 |
| HTTP-I | Iterative HTTP-based Redirection | RFC 8008 |
| HTTP-R | Recursive HTTP-based Redirection | RFC 8008 |
+------------------+----------------------------------+----------+
7. Security Considerations 7. 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 capabilities and footprint
integrity and authentication services. Without authentication and advertisement objects are REQUIRED to provide integrity and
integrity, an attacker could trivially deny service by forging a authentication services. Without authentication and integrity, an
footprint advertisement from a dCDN which claims the network has no attacker could trivially deny service by forging a footprint
footprint or capability. This would prevent the uCDN from delegating advertisement from a dCDN that claims the network has no footprint or
any requests to the dCDN. Since a pre-existing relationship between capability. This would prevent the uCDN from delegating any requests
all dCDNs and uCDNs is assumed by CDNI, the exchange of any necessary to the dCDN. Since a preexisting relationship between all dCDNs and
credentials could be conducted before the FCI interface is brought uCDNs is assumed by CDNI, the exchange of any necessary credentials
online. The authorization decision to accept advertisements would could be conducted before the FCI is brought online. The
also follow this pre-existing relationship and any contractual authorization decision to accept advertisements would also follow
obligations that it stipulates. this preexisting relationship and any contractual obligations that it
stipulates.
All protocols that implement these semantics are REQUIRED to provide All protocols that implement these capabilities and footprint
confidentiality services. Some dCDNs are willing to share advertisement objects are REQUIRED to provide confidentiality
information about their footprint or capabilities with a uCDN but not services. Some dCDNs are willing to share information about their
with other, competing dCDNs. For example, if a dCDN incurs an outage footprints or capabilities with a uCDN but not with other, competing
that reduces footprint coverage temporarily, that could be dCDNs. For example, if a dCDN incurs an outage that reduces
information the dCDN would want to share confidentially with the footprint coverage temporarily, that event could be information the
uCDN. dCDN would want to share confidentially with the uCDN.
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 transport-layer security mechanisms coupled with could be met by transport-layer security mechanisms coupled with
domain certificates as credentials (e.g., TLS transport for HTTP as domain certificates as credentials (e.g., TLS transport for HTTP as
per [RFC2818] and [RFC7230], with usage guidance from [RFC7525]) per [RFC2818] and [RFC7230], with usage guidance from [RFC7525])
between CDNs. There is no apparent need for further object-level between CDNs. 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.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-cdni-logging]
Faucheur, F., Bertrand, G., Oprescu, I., and R.
Peterkofsky, "CDNI Logging Interface", draft-ietf-cdni-
logging-25 (work in progress), April 2016.
[I-D.ietf-cdni-metadata]
Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma,
"CDN Interconnection Metadata", draft-ietf-cdni-
metadata-16 (work in progress), April 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
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>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March Interchange Format", RFC 7159, DOI 10.17487/RFC7159,
2014, <http://www.rfc-editor.org/info/rfc7159>. March 2014, <http://www.rfc-editor.org/info/rfc7159>.
[RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed.,
"Framework for Content Distribution Network "Framework for Content Distribution Network
Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336,
August 2014, <http://www.rfc-editor.org/info/rfc7336>. August 2014, <http://www.rfc-editor.org/info/rfc7336>.
[RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493,
DOI 10.17487/RFC7493, March 2015, DOI 10.17487/RFC7493, March 2015,
<http://www.rfc-editor.org/info/rfc7493>. <http://www.rfc-editor.org/info/rfc7493>.
[RFC7937] Le Faucheur, F., Ed., Bertrand, G., Ed., Oprescu, I., Ed.,
and R. Peterkofsky, "Content Distribution Network
Interconnection (CDNI) Logging Interface", RFC 7937,
DOI 10.17487/RFC7937, August 2016,
<http://www.rfc-editor.org/info/rfc7937>.
[RFC8006] Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma,
"Content Delivery Network Interconnection (CDNI)
Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016,
<http://www.rfc-editor.org/info/rfc8006>.
8.2. Informative References 8.2. Informative References
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000, DOI 10.17487/RFC2818, May 2000,
<http://www.rfc-editor.org/info/rfc2818>. <http://www.rfc-editor.org/info/rfc2818>.
[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,
2012, <http://www.rfc-editor.org/info/rfc6707>. September 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>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext
Protocol (HTTP/1.1): Message Syntax and Routing", Transfer 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>.
[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>.
[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,
2015, <http://www.rfc-editor.org/info/rfc7525>. May 2015, <http://www.rfc-editor.org/info/rfc7525>.
[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. Main Use Case to Consider Appendix A. 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, narrow down the requirements for the CDNI FCI. To this end, the
the following (simplified) use case can help in clarifying the following (simplified) use case can help clarify the semantics of
semantics of footprint and capabilities for CDNI. In particular, the footprints and capabilities for CDNI. In particular, the intention
intention of the use case is to clarify what information needs to be of the use case is to clarify what information needs to be exchanged
exchanged on the CDNI FCI, what types of information need to be on the CDNI FCI, what types of information need to be supported in a
supported in a mandatory fashion (and which can be considered mandatory fashion (and which types can be considered optional), and
optional), and what types of information need to be updated with what types of information need to be updated with respect to a priori
respect to a priori established CDNI contracts. 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
how the uCDN selects a level-1 dCDN (e.g., in case the level-2 dCDN 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 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, for either all of
footprint 1 or only for the subset of footprint 1 that the transitive footprint 1 or only 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?
Appendix B. Semantics for Footprint Advertisement Appendix B. Semantics for Footprint Advertisement
Roughly speaking, "footprint" can be defined as "ability and Roughly speaking, "footprint" can be defined as a dCDN's "ability and
willingness to serve" by a dCDN. However, in addition to simple willingness to serve". However, in addition to simple ability and
"ability and willingness to serve", the uCDN could want additional willingness to serve, the uCDN could want additional information
information to make a dCDN selection decision, e.g., "how well" a before deciding which dCDN to select, e.g., "how well" a given dCDN
given dCDN can actually serve a given end user request. The "ability can actually serve a given end user request. The dCDN's ability and
and willingness" to serve SHOULD be distinguished from the subjective willingness to serve SHOULD be distinguished from the subjective
qualitative measurement of "how well" it was served. One can imagine qualitative measurement of how well it can serve a given end user
that such additional information is implicitly associated with a request. One can imagine that such additional information is
given footprint, due to contractual agreements, SLAs, business implicitly associated with a given footprint, due to contractual
relationships, or past perceptions of dCDN quality. As an agreements, Service Level Agreements (SLAs), business relationships,
alternative, such additional information could also be explicitly or past perceptions of dCDN quality. As an alternative, such
tagged along with the footprint. additional information could also be explicitly included with the
given 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 occur out-of-band, prior to any CDNI FCI
participating CDNs, prior to the advertisement phase using the CDNI advertisement, with footprints defined in contractual agreements
FCI. The reason for this assumption is that any contractual between participating CDNs. The reason for this assumption is that
agreement is likely to contain specifics about the dCDN coverage any contractual agreement is likely to contain specifics about the
(footprint) to which the contractual agreement applies. In dCDN coverage (footprint) to which the contractual agreement applies.
particular, additional information to judge the delivery quality In particular, additional information to judge the delivery quality
associated with a given dCDN footprint might be defined in associated with a given dCDN footprint might be defined in
contractual agreements, outside of the CDNI FCI. Further, one can contractual agreements, outside of the CDNI FCI. Further, one can
assume that dCDN contractual agreements about the delivery quality assume that dCDN contractual agreements about the delivery quality
associated with a given footprint will probably be based on high- associated with a given footprint will probably be based on
level aggregated statistics and not too detailed. high-level aggregated statistics and will not be too detailed.
Given that a large part of footprint advertisement will actually Given that a large part of the footprint advertisement will be
happen in contractual agreements, the semantics of CDNI footprint defined in contractual agreements, the semantics of CDNI footprint
advertisement refer to answering the following question: what exactly advertisement refer to answering the following question: what exactly
still needs to be advertised by the CDNI FCI? For instance, updates still needs to be advertised by the CDNI FCI? For instance, updates
about temporal failures of part of a footprint can be useful about temporal failures of part of a footprint can be useful
information to convey via the CDNI request routing interface. Such information to convey via the CDNI Request Routing interface. Such
information would provide updates on information previously agreed in information would provide updates on information previously agreed
contracts between the participating CDNs. In other words, the CDNI upon in contracts between the participating CDNs. In other words,
FCI is a means for a dCDN to provide changes/updates regarding a the CDNI FCI is a means for a dCDN to provide changes/updates
footprint it has prior agreed to serve in a contract with a uCDN. regarding a footprint it has previously agreed to serve in a contract
with a uCDN.
Generally speaking, one can imagine two categories of footprint to be Generally speaking, one can imagine two categories of footprints to
advertised by a dCDN: be advertised by a dCDN:
o Footprint could be defined based on "coverage/reachability", where o A footprint could be defined based on coverage/reachability, where
coverage/reachability refers to a set of prefixes, a geographic "coverage/reachability" refers to a set of prefixes, a geographic
region, or similar boundary. The dCDN claims that it can cover/ region, or similar boundary. The dCDN claims that it can
reach 'end user requests coming from this footprint'. cover/reach "end user requests coming from this footprint".
o Footprint could be defined based on "resources", where resources o A footprint could be defined based on resources, where "resources"
refers to surrogates a dCDN claims to have (e.g., the location of refers to Surrogates a dCDN claims to have (e.g., the location of
surrogates/resources). The dCDN claims that 'from this footprint' Surrogates/resources). The dCDN claims that "from this footprint"
it can serve incoming end user requests. it can serve incoming end user requests.
For each of these footprint types, there are capabilities associated For each of these footprint types, there are capabilities associated
with a given footprint: with a given footprint:
o capabilities such as delivery protocol, redirection mode, and o capabilities such as delivery protocol, redirection mode, and
metadata, which are supported in the coverage area for a metadata, which are supported in the coverage area for a footprint
"coverage/reachability" defined footprint, or that is defined by coverage/reachability, or
o capabilities of resources, such as delivery protocol, redirection o capabilities of resources, such as delivery protocol, redirection
mode, and metadata, which apply to a "resource" defined footprint. mode, and metadata, which apply to a footprint that is defined by
resources.
"Resource" types of footprints are more specific than "coverage/ Resource footprint types are more specific than coverage/reachability
reachability" types of footprints, where the actual coverage/ footprint types, where the actual coverage and reachability are
reachability are extrapolated from the resource location (e.g., extrapolated from the resource location (e.g., a netmask applied to a
netmask applied to resource IP address to derive IP-prefix). The resource IP address to derive an IP prefix). The specific methods
specific methods for extrapolating coverage/reachability from for extrapolating coverage/reachability from the resource location
resource location are beyond the scope of this document. In the are beyond the scope of this document. In the degenerate case, the
degenerate case, the resource address could be specified as a resource address could be specified as a coverage/reachability
coverage/reachability type of footprint, in which case no footprint type, in which case no extrapolation is necessary.
extrapolation is necessary. Resource types of footprints could Resource footprint types could expose the internal structure of a
expose the internal structure of a CDN network which could be CDN; this could be undesirable. As such, the resource footprint
undesirable. As such, the resource types of footprints are not types are not considered mandatory to support for CDNI.
considered mandatory to support for CDNI.
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: the source. Multiple footprint constraints are additive: the
advertisement of different types of footprint narrows the dCDN advertisement of different footprint types narrows the dCDN's
candidacy cumulatively. candidacy cumulatively.
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 are able 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 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 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 footprint to an interested uCDN in a comprehensive form, e.g., as a
data set containing the complete footprint. Making incremental data set containing the complete footprint. However, making
updates, however, to express dynamic changes in state is also incremental updates to express dynamic changes in state is also
desirable. desirable.
Appendix C. Semantics for Capabilities Advertisement Appendix C. Semantics for Capabilities Advertisement
In general, the dCDN needs to be able to express its general In general, the dCDN needs to be able to express its general
capabilities to the uCDN. These general capabilities could express capabilities to the uCDN. These general capabilities could indicate
if the dCDN supports a given service, for instance, HTTP vs HTTPS if the dCDN supports a given service -- for instance, HTTP vs. HTTPS
delivery. Furthermore, the dCDN needs to be able to express delivery. Furthermore, the dCDN needs to be able to express
particular capabilities for the delivery in a particular footprint particular capabilities for service delivery in a particular
area. For example, the dCDN might in general offer HTTPS but not in footprint area. For example, the dCDN might in general offer HTTPS
some specific areas, either for maintenance reasons or because the but not in some specific areas, either for maintenance reasons or
surrogates covering this particular area cannot deliver this type of because the Surrogates covering this particular area cannot deliver
service. Hence, in certain cases footprint and capabilities are tied this type of service. Hence, in certain cases a footprint and
together and cannot be interpreted independently from each other. In capabilities are tied together and cannot be interpreted
such cases, i.e., where capabilities need to be expressed on a per independently of each other. In such cases, i.e., where capabilities
footprint basis, it could be beneficial to combine footprint and need to be expressed on a per-footprint basis, it could be beneficial
capabilities advertisement. to combine footprint advertisement and 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 dCDN is able (and willing) to accept (and properly determine if a dCDN is able (and willing) to accept (and properly
handle) a delegated content request. In addition, Capabilities are handle) a delegated content request. In addition, capabilities are
characterized by the fact that this information can change over time characterized by the fact that this information can change over time
based on the state of the network or surrogates. based on the state of the network or Surrogates.
At a first glance, several broad categories of capabilities seem At first glance, several broad categories of capabilities seem useful
useful to convey via an advertisement interface, however, advertising 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) is beyond the scope for CDNI FCI. First, changing QoS information) are beyond the scope of the CDNI FCI.
out of the multitude of possible metrics and capabilities, it is hard First, out of the multitude of possible metrics and capabilities, it
to agree on a subset and the precise metrics to be used. Second, it is hard to agree on a subset and the precise metrics to be used.
seems infeasible to specify such highly dynamically changing Second, it seems infeasible to specify such highly dynamically
capabilities and the corresponding metrics within a reasonable time- changing capabilities and the corresponding metrics within a
frame. reasonable 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 that, in many cases, is absolutely necessary for
on a particular dCDN for a given end user request. For instance, if deciding on a particular dCDN for a given end user request. For
an end user request concerns the delivery of a video file with a instance, if an end user request concerns the delivery of a video
certain protocol, the uCDN needs to know if a given dCDN has the file with a certain protocol, the uCDN needs to know if a given dCDN
capability of supporting this delivery protocol. is capable of supporting this delivery protocol.
Similar to footprint advertisement, it is reasonable to assume that a Similar to footprint advertisement, it is reasonable to assume that a
significant part of the actual (resource) capabilities advertisement significant part of the actual (resource) capabilities advertisement
will happen in contractual agreements between participating CDNs, will also occur out-of-band, prior to any CDNI FCI advertisement,
i.e., prior to the advertisement phase using the CDNI FCI. The role with capabilities defined in contractual agreements between
of capability advertisement is hence rather to enable the dCDN to participating CDNs. The role of capability advertisement is hence
update a uCDN on changes since a contract has been set up (e.g., in rather to enable the dCDN to update a uCDN on changes since a
case a new delivery protocol is suddenly being added to the list of contract has been set up (e.g., in case a new delivery protocol is
supported delivery protocols of a given dCDN, or in case a certain suddenly being added to the list of supported delivery protocols of a
delivery protocol is suddenly not being supported anymore due to given dCDN or in case a certain delivery protocol is suddenly not
failures). Capabilities advertisement thus refers to conveying being supported anymore due to failures). "Capabilities
information to a uCDN about changes/updates of certain capabilities advertisement" thus refers to conveying information to a uCDN about
with respect to a given contract. changes/updates to certain capabilities 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 are better off being agnostic to these contracts anyway), interface is better off being agnostic to these contracts anyway), it
it remains to be seen what capabilities will be used to define 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 could 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,
flexible data model that allows exchanging additional capabilities a 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 reached regarding which
capabilities (if any) will be mandatory among CDNs. capabilities (if any) will be mandatory among CDNs.
It is not feasible 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. FCI object extensibility is necessary to
FCI specification with defining each supported capability. Instead, support future capabilities, as well as 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 mechanisms; further requirements for the
error handling, and security mechanism; further requirements for the CDNI FCI are listed in [RFC7337]).
CDNI FCI Advertisement Interface are listed in [RFC7337]).
Appendix D. Acknowledgment Acknowledgments
Jan Seedorf is partially supported by the GreenICN project (GreenICN: Jan Seedorf is partially supported by the GreenICN project
Architecture and Applications of Green Information Centric (GreenICN: 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,
the European Commission, or NICT. the European Commission, or NICT.
Martin Stiemerling provided initial input to this document and Martin Stiemerling provided initial input to this document and
valuable comments to the ongoing discussions among the authors of valuable comments to the ongoing discussions among the authors of
this document. Thanks to Francois Le Faucheur and Scott Wainner for this document. Thanks to Francois Le Faucheur and Scott Wainner for
providing valuable comments and suggestions to the text. providing valuable comments and suggestions for the text.
Authors' Addresses Authors' Addresses
Jan Seedorf Jan Seedorf
NEC HFT Stuttgart - University of Applied Sciences Stuttgart
Kurfuerstenanlage 36 Schellingstrasse 24
Heidelberg 69115 Stuttgart 70174
Germany Germany
Phone: +49 6221 4342 221 Phone: +49-0711-8926-2801
Fax: +49 6221 4342 155 Email: jan.seedorf@hft-stuttgart.de
Email: seedorf@neclab.eu
Jon Peterson Jon Peterson
NeuStar NeuStar
1800 Sutter St Suite 570 1800 Sutter St. Suite 570
Concord CA 94520 Concord, CA 94520
USA United States of America
Email: jon.peterson@neustar.biz Email: jon.peterson@neustar.biz
Stefano Previdi Stefano Previdi
Cisco Systems Cisco Systems
Via Del Serafico 200 Via Del Serafico 200
Rome 0144 Rome 0144
Italy Italy
Email: sprevidi@cisco.com Email: sprevidi@cisco.com
Ray van Brandenburg Ray van Brandenburg
TNO TNO
Brassersplein 2 Anna van Buerenplein 1
Delft 2612CT The Hague 2595DA
The Netherlands The Netherlands
Phone: +31-88-866-7000 Phone: +31-88-866-7000
Email: ray.vanbrandenburg@tno.nl Email: ray.vanbrandenburg@tno.nl
Kevin J. Ma Kevin J. Ma
Ericsson Ericsson
43 Nagog Park 43 Nagog Park
Acton, MA 01720 Acton, MA 01720
USA United States of America
Phone: +1 978-844-5100 Phone: +1-978-844-5100
Email: kevin.j.ma@ericsson.com Email: kevin.j.ma@ericsson.com
 End of changes. 161 change blocks. 
541 lines changed or deleted 544 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/