CDNI Request Routing: Footprint and Capabilities Semantics
draft-ietf-cdni-footprint-capabilities-semantics-15

CDNI                                                          J. Seedorf
Internet-Draft                                                       NEC
Intended status: Informational                               J. Peterson
Expires: October 14, 2016                                        Neustar
                                                              S. Previdi
                                                                   Cisco
                                                      R. van Brandenburg
                                                                     TNO
                                                                   K. Ma
                                                                Ericsson
                                                          April 12, 2016

       CDNI Request Routing: Footprint and Capabilities Semantics
          draft-ietf-cdni-footprint-capabilities-semantics-15

Abstract

   This document captures the semantics of the "Footprint and
   Capabilities Advertisement" part of the CDNI Request Routing
   interface, i.e., the desired meaning of "Footprint" and
   "Capabilities" in the CDNI context, and what the "Footprint and
   Capabilities Advertisement Interface (FCI)" offers within CDNI.  The
   document also provides guidelines for the CDNI FCI protocol.  It
   further defines a Base Advertisement Object, the necessary registries
   for capabilities and footprints, and 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

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

Seedorf, et al.         Expires October 14, 2016                [Page 1]
Internet-Draft  CDNI RR Footprint/Capabilities Semantics      April 2016

   This Internet-Draft will expire on October 14, 2016.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction and Scope  . . . . . . . . . . . . . . . . . . .   3
   2.  Design Decisions for Footprint and Capabilities . . . . . . .   4
     2.1.  Advertising Limited Coverage  . . . . . . . . . . . . . .   4
     2.2.  Capabilities and Dynamic Data . . . . . . . . . . . . . .   5
     2.3.  Advertisement versus Queries  . . . . . . . . . . . . . .   6
     2.4.  Avoiding or Handling 'cheating' dCDNs . . . . . . . . . .   7
     2.5.  Focusing on Main Use Cases  . . . . . . . . . . . . . . .   7
   3.  Main Use Case to Consider . . . . . . . . . . . . . . . . . .   8
   4.  Semantics for Footprint Advertisement . . . . . . . . . . . .   8
   5.  Semantics for Capabilities Advertisement  . . . . . . . . . .  11
   6.  Negotiation of Support for Optional Types of
       Footprint/Capabilities  . . . . . . . . . . . . . . . . . . .  14
   7.  Capability Advertisement Object . . . . . . . . . . . . . . .  14
     7.1.  Base Advertisement Object . . . . . . . . . . . . . . . .  14
     7.2.  Delivery Protocol Capability Object . . . . . . . . . . .  15
     7.3.  Acquisition Protocol Capability Object  . . . . . . . . .  15
     7.4.  Redirection Mode Capability Object  . . . . . . . . . . .  16
     7.5.  Capability Advertisement Object Serialization . . . . . .  16
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
     8.1.  CDNI Payload Types  . . . . . . . . . . . . . . . . . . .  17
       8.1.1.  CDNI FCI DeliveryProtocol Payload Type  . . . . . . .  18
       8.1.2.  CDNI FCI AcquisitionProtocol Payload Type . . . . . .  18
       8.1.3.  CDNI FCI RedirectionMode Payload Type . . . . . . . .  18
     8.2.  Redirection Mode Registry . . . . . . . . . . . . . . . .  18
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  19
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  20
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  20
     10.2.  Informative References . . . . . . . . . . . . . . . . .  21
   Appendix A.  Acknowledgment . . . . . . . . . . . . . . . . . . .  21

Seedorf, et al.         Expires October 14, 2016                [Page 2]
Internet-Draft  CDNI RR Footprint/Capabilities Semantics      April 2016

   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  22

1.  Introduction and Scope

   The CDNI working group is working on a set of protocols to enable the
   interconnection of multiple CDNs.  This CDN interconnection (CDNI)
   can serve multiple purposes, as discussed in [RFC6770], for instance,
   to extend the reach of a given CDN to areas in the network which are
   not covered by this particular CDN.

   The goal of this document is to achieve a clear understanding about
   the semantics associated with the CDNI Request Routing Footprint &
   Capabilities Advertisement Interface (from now on referred to as
   FCI), in particular the type of information a downstream CDN (dCDN)
   'advertises' regarding its footprint and capabilities.  To narrow
   down undecided aspects of these semantics, this document tries to
   establish a common understanding of what the FCI needs to offer and
   accomplish in the context of CDN Interconnection.

   It is explicitly outside the scope of this document to decide on
   specific protocols to use for the FCI.  However, guidelines for such
   FCI protocols are provided.

   General assumptions in this document:

   o  The CDNs participating in the interconnected CDN have already
      performed a boot strap process, i.e., they have connected to each
      other, either directly or indirectly, and can exchange information
      amongst each other.

   o  The upstream CDN (uCDN) receives footprint and/or capability
      advertisements from a set of dCDNs.  Footprint advertisement and
      capability advertisement need not use the same underlying
      protocol.

   o  The uCDN receives the initial request-routing request from the
      endpoint requesting the resource.

   The CDNI Problem Statement [RFC6707] describes the Request Routing
   Interface as: "[enabling] a Request Routing function in a uCDN to
   query a Request Routing function in a dCDN to determine if the dCDN
   is able (and willing) to accept the delegated Content Request".  In
   addition, RFC6707 says "the CDNI Request Routing interface is also
   expected to enable a dCDN to provide to the uCDN (static or dynamic)
   information (e.g., resources, footprint, load) to facilitate
   selection of the dCDN by the uCDN request routing system when
   processing subsequent content requests from User Agents".  It thus

Seedorf, et al.         Expires October 14, 2016                [Page 3]
Internet-Draft  CDNI RR Footprint/Capabilities Semantics      April 2016

   considers "resources" and "load" as capabilities to be advertised by
   the dCDN.

   The range of different footprint definitions and possible
   capabilities is very broad.  Attempting to define a comprehensive
   advertisement solution quickly becomes intractable.  The CDNI
   requirements draft [RFC7337] lists the specific requirements for the
   CDNI Footprint & Capabilities Advertisement Interface in order to
   disambiguate footprints and capabilities with respect to CDNI.  This
   document defines a common understanding of what the terms 'footprint'
   and 'capabilities' mean in the context of CDNI, and details the
   semantics of the footprint advertisement mechanism and the capability
   advertisement mechanism.

2.  Design Decisions for Footprint and Capabilities

   A large part of the difficulty in discussing the FCI lies in
   understanding what exactly is meant when trying to define footprint
   in terms of "coverage" or "reachability."  While the operators of
   CDNs pick strategic locations to situate caches, a cache with a
   public IPv4 address is reachable by any endpoint on the Internet
   unless some policy enforcement precludes the use of the cache.

   Some CDNs aspire to cover the entire world; we refer to these as
   global CDNs.  The footprint advertised by such a CDN in the CDNI
   environment would, from a coverage or reachability perspective,
   presumably cover all prefixes.  Potentially more interesting for CDNI
   use cases, however, are CDNs that claim a more limited coverage, but
   seek to interconnect with other CDNs in order to create a single CDN
   fabric which shares resources.

   Furthermore, not all capabilities need to be footprint restricted.
   Depending upon the use case, the optimal semantics of "footprints
   with capability attributes" vs. "capabilities with footprint
   restrictions" are not clear.

   The key to understanding the semantics of footprint and capability
   advertisement lies in understand why a dCDN would advertise a limited
   coverage area, and how a uCDN would use such advertisements to decide
   among one of several dCDNs.  The following section will discuss some
   of the trade-offs and design decisions that need to be decided upon
   for the CDNI FCI.

2.1.  Advertising Limited Coverage

   The basic use case that would motivate a dCDN to advertise a limited
   coverage is that the CDN was built to cover only a particular portion
   of the Internet.  For example, an ISP could purpose-build a CDN to

Seedorf, et al.         Expires October 14, 2016                [Page 4]
Internet-Draft  CDNI RR Footprint/Capabilities Semantics      April 2016

   serve only their own customers by situating caches in close
   topological proximity to high concentrations of their subscribers.
   The ISP knows the prefixes it has allocated to end users and thus can
   easily construct a list of prefixes that its caches were positioned
   to serve.

   When such a purpose-built CDN interconnects with other CDNs and
   advertises its footprint to a uCDN, however, the original intended
   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
   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
   to a cache fielded by ISP-A, if E happens to live in a region where
   ISP-B has few customers and ISP-A has many.  In this case, is 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 caches are potentially
   available as back-ups - and if so, how does ISP-A advertise itself as
   a "standby" for E?  What about the case where CDNs advertising to the
   same uCDN express overlapping coverage (for example, mixing global
   and limited CDNs)?

   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
   three dCDNs to choose from that "cover" the IP address of user E,
   obviously the uCDN might be interested to know how optimal the
   coverage is from each of the dCDNs - coverage need not be binary,
   either provided or not provided. dCDNs could advertise a coverage
   "score," for example, and provided that they all reported scores
   fairly on the same scale, uCDNs could use that to make their
   topological optimality decision.  Alternately, dCDNs could advertise
   the IP addresses of their caches rather than prefix "coverage," and
   let the uCDN decide for itself (based on its own topological
   intelligence) which dCDN has better resources to serve a given user.

   In summary, the semantics of advertising footprint depend on whether
   such qualitative metrics for expressing footprint (such as the
   coverage 'score' mentioned above) are included as part of the CDNI
   FCI, or if the focus is just on 'binary' footprint.

2.2.  Capabilities and Dynamic Data

   In cases where the apparent footprints of dCDNs overlap, uCDNs might
   also want to rely on other factors to evaluate the respective merits
   of dCDNs.  These include facts related to the caches themselves, to
   the network where the cache is deployed, to the nature of the
   resource sought, and to the administrative policies of the respective
   networks.

Seedorf, et al.         Expires October 14, 2016                [Page 5]
Internet-Draft  CDNI RR Footprint/Capabilities Semantics      April 2016

   In the absence of network-layer impediments to reaching caches, the
   choice to limit coverage is necessarily an administrative policy.
   Much policy needs to be agreed upon before CDNs can interconnect,
   including questions of membership, compensation, volumes, and so on.
   A uCDN certainly will factor these sorts of considerations into its
   decision to select a dCDN, but there is probably little need for
   dCDNs to actually advertise them through an interface - they will be
   settled out-of-band as a precondition for interconnection.

   Other facts about the dCDN would be expressed through the interface
   to the uCDN.  Some capabilities of a dCDN are static, and some are
   highly dynamic.  Expressing the total storage built into its caches,
   for example, changes relatively rarely, whereas the amount of storage
   in use at any given moment is highly volatile.  Network bandwidth
   similarly could be expressed as either total bandwidth available to a
   cache, or based on the current state of the network.  A cache can at
   one moment lack a particular resource in storage, but have it the
   next.

   The semantics of the capabilities interface will depend on how much
   of the dCDN state needs to be pushed to the uCDN and qualitatively
   how often that information needs to be updated.

2.3.  Advertisement versus Queries

   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
   all of the dCDNs available to it.  In architectures that share
   detailed capability information, the uCDN could perform the entire
   request-routing operation down to selecting a particular cache in the
   dCDN.  However, when the uCDN needs to deal with many potential
   dCDNs, this approach does not scale, especially for dCDNs with
   thousands or tens of thousands of caches; the volume of updates to
   footprint and capability becomes onerous.

   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
   dCDNs upon receiving requests (as is the case in the recursive
   redirection mode described in [RFC7336]), instead of receiving
   advertisements and tracking the state of dCDNs.  The advantage of
   querying dCDNs would be that much of the dynamic data that dCDNs
   cannot share with the uCDN would now be factored into the uCDN's
   decision. dCDNs need not replicate any state to the uCDN - uCDNs
   could effectively operate in a stateless mode.

   The semantics of both footprint and capability advertisement depend
   on the service model here: are there cases where a synchronous query/

Seedorf, et al.         Expires October 14, 2016                [Page 6]
Internet-Draft  CDNI RR Footprint/Capabilities Semantics      April 2016

   response model would work better for the uCDN decision than a state
   replication model?

2.4.  Avoiding or Handling 'cheating' dCDNs

   In a situation where more than one dCDN is willing to serve a given
   end user request, it might be attractive for a dCDN to 'cheat' in the
   sense that the dCDN provides inaccurate information to the uCDN in
   order to convince the uCDN to select it over 'competing' dCDNs.  It
   could therefore be desirable to take away the incentive for dCDNs to
   cheat (in information advertised) as much as possible.  One option is
   to make the information the dCDN advertises somehow verifiable for
   the uCDN.  On the other hand, a cheating dCDN might be avoided or
   handled by the fact that there will be strong contractual agreements
   between a uCDN and a dCDN, so that a dCDN would risk severe penalties
   or legal consequences when caught cheating.

   Overall, the information a dCDN advertises (in the long run) needs to
   be somehow qualitatively verifiable by the uCDN, though possibly
   through non-real-time out-of-band audits.  It is probably an overly
   strict requirement to mandate that such verification be possible
   "immediately", i.e., during the request routing process itself.  If
   the uCDN can detect a cheating dCDN at a later stage, it might
   suffice for the uCDN to "de-incentivize" cheating because it would
   negatively affect the long-term business relationship with a
   particular dCDN.

2.5.  Focusing on Main Use Cases

   To narrow down semantics for "footprint" and "capabilities" in the
   CDNI context, it can be useful to initially focus on key use cases to
   be addressed by the CDNI WG that are to be envisioned in the main
   deployments in the foreseeable future.  In this regard, a main
   realistic use case is the existence of ISP-owned CDNs, which
   essentially cover a certain operator's network.  At the same time,
   however, the possibility of overlapping footprints cannot be
   excluded, i.e., the scenario where more than one dCDN claims it can
   serve a given end user request.  The ISPs can also choose to
   interconnect with a fallback global CDN.

   It seems reasonable to assume that in most use cases it is the uCDN
   that makes the decision on selecting a certain dCDN for request
   routing based on information the uCDN has received from this
   particular dCDN.  It can be assumed that 'cheating' CDNs will be
   dealt with via means outside the scope of CDNI and that the
   information advertised between CDNs is accurate.  In addition,
   excluding the use of qualitative information (e.g., cache proximity,
   delivery latency, cache load) to predict the quality of delivery

Seedorf, et al.         Expires October 14, 2016                [Page 7]
Internet-Draft  CDNI RR Footprint/Capabilities Semantics      April 2016

   would further simplify the use case allowing it to better focus on
   the basic functionality of the FCI.

3.  Main Use Case to Consider

   Focusing on a main use case that contains a simple (yet somewhat
   challenging), realistic, and generally imaginable scenario can help
   in narrowing down the requirements for the CDNI FCI.  To this end,
   the following (simplified) use case can help in clarifying the
   semantics of footprint and capabilities for CDNI.  In particular, the
   intention of the use case is to clarify what information needs to be
   exchanged on the CDNI FCI, what types of information need to be
   supported in a mandatory fashion (and which can be considered
   optional), and what types of information need to be updated with
   respect to a priori established CDNI contracts.

   Use case: A given uCDN has several dCDNs.  It selects one dCDN for
   delivery protocol A and footprint 1 and another dCDN for delivery
   protocol B and footprint 1.  The dCDN that serves delivery protocol B
   has a further, transitive (level-2) dCDN, that serves delivery
   protocol B in a subset of footprint 1 where the first-level dCDN
   cannot serve delivery protocol B itself.  What happens if
   capabilities change in the transitive level-2 dCDN that might affect
   how the uCDN selects a level-1 dCDN (e.g., in case the level-2 dCDN
   cannot serve delivery protocol B anymore)?  How will these changes be
   conveyed to the uCDN?  In particular, what information does the uCDN
   need to be able to select a new first-level dCDN, either for all of
   footprint 1 or only for the subset of footprint 1 that the transitive
   level-2 dCDN served on behalf of the first-level dCDN?

4.  Semantics for Footprint Advertisement

   Roughly speaking, "footprint" can be defined as "ability and
   willingness to serve" by a dCDN.  However, in addition to simple
   "ability and willingness to serve", the uCDN could want additional
   information to make a dCDN selection decision, e.g., "how well" a
   given dCDN can actually serve a given end user request.  The "ability
   and willingness" to serve SHOULD be distinguished from the subjective
   qualitative measurement of "how well" it was served.  One can imagine
   that such additional information is implicitly associated with a
   given footprint, due to contractual agreements, SLAs, business
   relationships, or past perceptions of dCDN quality.  As an
   alternative, such additional information could also be explicitly
   tagged along with the footprint.

   It is reasonable to assume that a significant part of the actual
   footprint advertisement will happen in contractual agreements between
   participating CDNs, prior to the advertisement phase using the CDNI

Seedorf, et al.         Expires October 14, 2016                [Page 8]
Internet-Draft  CDNI RR Footprint/Capabilities Semantics      April 2016

   FCI.  The reason for this assumption is that any contractual
   agreement is likely to contain specifics about the dCDN coverage
   (footprint) to which the contractual agreement applies.  In
   particular, additional information to judge the delivery quality
   associated with a given dCDN footprint might be defined in
   contractual agreements, outside of the CDNI FCI.  Further, one can
   assume that dCDN contractual agreements about the delivery quality
   associated with a given footprint will probably be based on high-
   level aggregated statistics and not too detailed.

   Given that a large part of footprint advertisement will actually
   happen in contractual agreements, the semantics of CDNI footprint
   advertisement refer to answering the following question: what exactly
   still needs to be advertised by the CDNI FCI?  For instance, updates
   about temporal failures of part of a footprint can be useful
   information to convey via the CDNI request routing interface.  Such
   information would provide updates on information previously agreed in
   contracts between the participating CDNs.  In other words, the CDNI
   FCI is a means for a dCDN to provide changes/updates regarding a
   footprint it has prior agreed to serve in a contract with a uCDN.

   Generally speaking, one can imagine two categories of footprint to be
   advertised by a dCDN:

   o  Footprint could be defined based on "coverage/reachability", where
      coverage/reachability refers to a set of prefixes, a geographic
      region, or similar boundary.  The dCDN claims that it can cover/
      reach 'end user requests coming from this footprint'.

   o  Footprint could be defined based on "resources", where resources
      refers to surrogates/caches a dCDN claims to have (e.g., the
      location of surrogates/resources).  The dCDN claims that 'from
      this footprint' it can serve incoming end user requests.

   For each of these footprint types, there are capabilities associated
   with a given footprint:

   o  capabilities such as delivery protocol, redirection mode, and
      metadata, which are supported in the coverage area for a
      "coverage/reachability" defined footprint, or

   o  capabilities of resources, such as delivery protocol, redirection
      mode, and metadata, which apply to a "resource" defined footprint.

   It seems clear that "coverage/reachability" types of footprint MUST
   be supported within CDNI.  The following such types of footprint are
   mandatory and MUST be supported by the CDNI FCI:

Seedorf, et al.         Expires October 14, 2016                [Page 9]
Internet-Draft  CDNI RR Footprint/Capabilities Semantics      April 2016

   o  List of ISO Country Codes

   o  List of AS numbers

   o  Set of IP-prefixes

   A 'set of IP-prefixes' MUST be able to contain full IP addresses,
   i.e., a /32 for IPv4 and a /128 for IPv6, as well as IP prefixes with
   an arbitrary prefix length.  There also MUST be support for multiple
   IP address versions, i.e., IPv4 and IPv6, in such a footprint.

   "Resource" types of footprints are more specific than "coverage/
   reachability" types of footprints, where the actual coverage/
   reachability are extrapolated from the resource location (e.g.,
   netmask applied to resource IP address to derive IP-prefix).  The
   specific methods for extrapolating coverage/reachability from
   resource location are beyond the scope of this document.  In the
   degenerate case, the resource address could be specified as a
   coverage/reachability type of footprint, in which case no
   extrapolation is necessary.  Resource types of footprints could
   expose the internal structure of a CDN network which could be
   undesirable.  As such, the resource types of footprints are not
   considered mandatory to support for CDNI.

   For all of these mandatory-to-implement footprint types, the
   footprints can be viewed as constraints for delegating requests to a
   dCDN: A dCDN footprint advertisement tells the uCDN the limitations
   for delegating a request to the dCDN.  For IP prefixes or ASN(s), the
   footprint signals to the uCDN that it SHOULD consider the dCDN a
   candidate only if the IP address of the request routing source falls
   within the prefix set (or ASN, respectively).  The CDNI
   specifications do not define how a given uCDN determines what address
   ranges are in a particular ASN.  Similarly, for country codes a uCDN
   SHOULD only consider the dCDN a candidate if it covers the country of
   the request routing source.  The CDNI specifications do not define
   how a given uCDN determines the country of the request routing
   source.  Multiple footprint constraints are additive: the
   advertisement of different types of footprint narrows the dCDN
   candidacy cumulatively.

   In addition to these mandatory "coverage/reachability" types of
   footprint, other optional "coverage/reachability" types of footprint
   or "resource" types of footprint MAY be defined by future
   specifications.  To facilitate this, a clear process for specifying
   optional footprint types in an IANA registry is specified in the CDNI
   Metadata Footprint Types registry (defined in the CDNI Metadata
   Interface document [I-D.ietf-cdni-metadata]).

Seedorf, et al.         Expires October 14, 2016               [Page 10]
Internet-Draft  CDNI RR Footprint/Capabilities Semantics      April 2016

   Independent of the exact type of a footprint, a footprint might also
   include the connectivity of a given dCDN to other CDNs that are able
   to serve content to users on behalf of that dCDN, to cover cases with
   cascaded CDNs.  Further, the dCDN needs to be able to express its
   footprint to an interested uCDN in a comprehensive form, e.g., as a
   data set containing the complete footprint.  Making incremental
   updates, however, to express dynamic changes in state is also
   desirable.

5.  Semantics for Capabilities Advertisement

   In general, the dCDN MUST be able to express its general capabilities
   to the uCDN.  These general capabilities could express if the dCDN
   supports a given service, for instance, HTTP vs HTTPS delivery.
   Furthermore, the dCDN MUST be able to express particular capabilities
   for the delivery in a particular footprint area.  For example, the
   dCDN might in general offer HTTPS but not in some specific areas,
   either for maintenance reasons or because the caches covering this
   particular area cannot deliver this type of service.  Hence, in
   certain cases footprint and capabilities are tied together and cannot
   be interpreted independently from each other.  In such cases, i.e.,
   where capabilities need to be expressed on a per footprint basis, it
   could be beneficial to combine footprint and capabilities
   advertisement.

   A high-level and very rough semantic for capabilities is thus the
   following: Capabilities are types of information that allow a uCDN to
   determine if a dCDN is able (and willing) to accept (and properly
   handle) a delegated content request.  In addition, Capabilities are
   characterized by the fact that this information can change over time
   based on the state of the network or caches.

   At a first glance, several broad categories of capabilities seem
   useful to convey via an advertisement interface, however, advertising
   capabilities that change highly dynamically (e.g., real-time delivery
   performance metrics, CDN resource load, or other highly dynamically
   changing QoS information) is beyond the scope for CDNI FCI.  First,
   out of the multitude of possible metrics and capabilities, it is hard
   to agree on a subset and the precise metrics to be used.  Second, it
   seems infeasible to specify such highly dynamically changing
   capabilities and the corresponding metrics within a reasonable time-
   frame.

   Useful capabilities refer to information that does not change highly
   dynamically and which in many cases is absolutely necessary to decide
   on a particular dCDN for a given end user request.  For instance, if
   an end user request concerns the delivery of a video file with a

Seedorf, et al.         Expires October 14, 2016               [Page 11]
Internet-Draft  CDNI RR Footprint/Capabilities Semantics      April 2016

   certain protocol, the uCDN needs to know if a given dCDN has the
   capability of supporting this delivery protocol.

   Similar to footprint advertisement, it is reasonable to assume that a
   significant part of the actual (resource) capabilities advertisement
   will happen in contractual agreements between participating CDNs,
   i.e., prior to the advertisement phase using the CDNI FCI.  The role
   of capability advertisement is hence rather to enable the dCDN to
   update a uCDN on changes since a contract has been set up (e.g., in
   case a new delivery protocol is suddenly being added to the list of
   supported delivery protocols of a given dCDN, or in case a certain
   delivery protocol is suddenly not being supported anymore due to
   failures).  Capabilities advertisement thus refers to conveying
   information to a uCDN about changes/updates of certain capabilities
   with respect to a given contract.

   Given these semantics, it needs to be decided what exact capabilities
   are useful and how these can be expressed.  Since the details of CDNI
   contracts are not known at the time of this writing (and the CDNI
   interface are better off being agnostic to these contracts anyway),
   it remains to be seen what capabilities will be used to define
   agreements between CDNs in practice.  One implication for
   standardization could be to initially only specify a very limited set
   of mandatory capabilities for advertisement and have on top of that a
   flexible data model that allows exchanging additional capabilities
   when needed.  Still, agreement needs to be found on which
   capabilities (if any) will be mandatory among CDNs.  As discussed in
   Section 2.5, finding the concrete answers to these questions can
   benefit from focusing on a small number of key use cases that are
   highly relevant and contain enough complexity to help in
   understanding what concrete capabilities are needed to facilitate CDN
   Interconnection.

   Under the above considerations, the following capabilities seem
   useful as 'base' capabilities, i.e., ones that are needed in any case
   and therefore constitute mandatory capabilities that MUST be
   supported by the CDNI FCI:

   o  Delivery Protocol (for delivering content to the end user)

   o  Acquisition Protocol (for acquiring content from the uCDN or
      origin server)

   o  Redirection Mode (e.g., DNS Redirection vs. HTTP Redirection as
      discussed in [RFC7336])

   o  CDNI Logging (i.e., supported logging fields)

Seedorf, et al.         Expires October 14, 2016               [Page 12]
Internet-Draft  CDNI RR Footprint/Capabilities Semantics      April 2016

   o  CDNI Metadata (i.e., supported Generic Metadata types)

   It is not feasible to enumerate all the possible options for the
   mandatory capabilities listed above (e.g., all the potential delivery
   protocols or metadata options) or anticipate all the future needs for
   additional capabilities.  It would be unreasonable to burden the CDNI
   FCI specification with defining each supported capability.  Instead,
   the CDNI FCI specification SHOULD define a generic protocol for
   conveying any capability information (e.g. with common encoding,
   error handling, and security mechanism; further requirements for the
   CDNI FCI Advertisement Interface are listed in [RFC7337]).  In this
   respect, it seems reasonable to initially define the mandatory
   capabilities listed above and extend the list as needs dictate.  This
   document registers CDNI Payload Types [RFC7736] for the mandatory
   capability types (see Section 8), prefixing each payload type with
   "FCI".  Updates to capability objects MUST indicate the version of
   the capability object in a newly registered payload type, e.g., by
   appending ".v2".  Each capability type MAY have a list of valid
   values.  Future specifications which define a given capability MUST
   define any necessary registries (and the rules for adding new entries
   to the registry) for the values advertised for a given capability
   type.

   The "CDNI Logging record-types" registry [I-D.ietf-cdni-logging]
   defines all known record types, including mandatory-to-implement
   record-types Advertising support for mandatory-to-implement record-
   types would be redundant.  CDNs SHOULD NOT advertise support for
   mandatory-to-implement record-types.

   The "CDNI Logging Fields Names" registry [I-D.ietf-cdni-logging]
   defines all known logging fields.  Logging fields may be reused by
   different record-types and be mandatory-to-implement in some record-
   types, but optional in other record-types.  CDNs MUST advertise
   support for optional logging fields within the context of a specific
   record-type.  CDNs SHOULD NOT advertise support for mandatory-to-
   implement logging fields, for a given record-type.  The following
   logging fields are defined as optional for the "cdni_http_request_v1"
   record-type in the CDNI Logging Interface document
   [I-D.ietf-cdni-logging]:

   o  s-ccid

   o  s-sid

   The CDNI Metadata Interface document [I-D.ietf-cdni-metadata]
   requires that CDNs be able to parse all the defined metadata objects,
   but does not require dCDNs to support enforcement of non-structural
   GenericMetadata objects.  Advertising support for mandatory-to-

Seedorf, et al.         Expires October 14, 2016               [Page 13]
Internet-Draft  CDNI RR Footprint/Capabilities Semantics      April 2016

   enforce GenericMetadata types MUST be supported.  Advertising support
   for non-mandatory-to-enforce GenericMetadata types SHOULD be
   supported.  Advertisement of non-mandatory-to-enforce GenericMetadata
   MAY be necessary, e.g., to signal temporary outages and subsequent
   recovery.  It is expected that structural metadata will be supported
   at all times.

6.  Negotiation of Support for Optional Types of Footprint/Capabilities

   The notion of optional types of footprint and capabilities implies
   that certain implementations might not support all kinds of footprint
   and capabilities.  Therefore, any FCI solution protocol MUST define
   how the support for optional types of footprint/capabilities will be
   negotiated between a uCDN and a dCDN that use the particular FCI
   protocol.  In particular, any FCI solution protocol MUST specify how
   to handle failure cases or non-supported types of footprint/
   capabilities.

   In general, a uCDN MAY ignore capabilities or types of footprints it
   does not understand; in this case it only selects a suitable dCDN
   based on the types of capabilities and footprint it understands.
   Similarly, if a dCDN does not use an optional capability or footprint
   which is, however, supported by a uCDN, this causes no problem for
   the FCI functionality because the uCDN decides on the remaining
   capabilities/footprint information that is being conveyed by the
   dCDN.

7.  Capability Advertisement Object

   To support extensibility, the FCI defines a generic base object
   (similar to the CDNI Metadata interface GenericMetadata object)
   [I-D.ietf-cdni-metadata] to facilitate a uniform set of mandatory
   parsing requirements for all future FCI objects.

   Future object definitions (e.g. regarding CDNI Metadata or Logging)
   will build off the base object defined here, but will be specified in
   separate documents.

7.1.  Base Advertisement Object

   The FCIBase object is an abstraction for managing individual CDNI
   capabilities in an opaque manner.

      Property: capability-type

         Description: CDNI Capability object type.

Seedorf, et al.         Expires October 14, 2016               [Page 14]
Internet-Draft  CDNI RR Footprint/Capabilities Semantics      April 2016

         Type: FCI specific CDNI Payload type (from the CDNI Payload
         Types registry [RFC7736])

         Mandatory-to-Specify: Yes.

      Property: capability-value

         Description: CDNI Capability object.

         Type: Format/Type is defined by the value of capability-type
         property above.

         Mandatory-to-Specify: Yes.

      Property: footprints

         Description: CDNI Capability Footprint.

         Type: List of CDNI Footprint objects (as defined in
         [I-D.ietf-cdni-metadata]).

         Mandatory-to-Specify: No.

7.2.  Delivery Protocol Capability Object

   The Delivery Protocol capability object is used to indicate support
   for one or more of the protocols listed in the CDNI Metadata Protocol
   Types registry (defined in the CDNI Metadata Interface document
   [I-D.ietf-cdni-metadata]).

      Property: delivery-protocols

         Description: List of supported CDNI Delivery Protocols.

         Type: List of Protocol Types (from the CDNI Metadata Protocol
         Types registry [I-D.ietf-cdni-metadata])

         Mandatory-to-Specify: Yes.

7.3.  Acquisition Protocol Capability Object

   The Acquisition Protocol capability object is used to indicate
   support for one or more of the protocols listed in the CDNI Metadata
   Protocol Types registry (defined in the CDNI Metadata Interface
   document [I-D.ietf-cdni-metadata]).

      Property: acquisition-protocols

Seedorf, et al.         Expires October 14, 2016               [Page 15]
Internet-Draft  CDNI RR Footprint/Capabilities Semantics      April 2016

         Description: List of supported CDNI Acquisition Protocols.

         Type: List of Protocol Types (from the CDNI Metadata Protocol
         Types registry [I-D.ietf-cdni-metadata])

         Mandatory-to-Specify: Yes.

7.4.  Redirection Mode Capability Object

   The Redirection Mode capability object is used to indicate support
   for one or more of the modes listed in the CDNI Capabilities
   Redirection Modes registry (see Section 8.2).

      Property: redirection-modes

         Description: List of supported CDNI Redirection Modes.

         Type: List of Redirection Modes (from Section 8.2)

         Mandatory-to-Specify: Yes.

7.5.  Capability Advertisement Object Serialization

   The following shows an example of CDNI FCI Capability Advertisement
   Object Serialization.

Seedorf, et al.         Expires October 14, 2016               [Page 16]
Internet-Draft  CDNI RR Footprint/Capabilities Semantics      April 2016

   {
     "capabilities": [
       {
         "capability-type": "FCI.DeliveryProtocol",
         "capability-value": {
           "delivery-protocols": [
             "http1.1"
           ]
         },
         "footprints": [
           <Footprint objects>
         ]
       },
       {
         "capability-type": "FCI.AcquisitionProtocol",
         "capability-value": {
           "acquisition-protocols": [
             "http1.1",
             "https1.1"
           ]
         }
       },
       {
         "capability-type": "FCI.RedirectionMode",
         "capability-value": {
           "redirection-modes": [
             "DNS-I",
             "HTTP-I"
           ]
         }
       }
     ]
   }

8.  IANA Considerations

8.1.  CDNI Payload Types

   This document requests the registration of the following CDNI Payload
   Types under the IANA CDNI Payload Type registry:

Seedorf, et al.         Expires October 14, 2016               [Page 17]
Internet-Draft  CDNI RR Footprint/Capabilities Semantics      April 2016

                +-------------------------+---------------+
                | Payload Type            | Specification |
                +-------------------------+---------------+
                | FCI.DeliveryProtocol    | RFCthis       |
                |                         |               |
                | FCI.AcquisitionProtocol | RFCthis       |
                |                         |               |
                | FCI.RedirectionMode     | RFCthis       |
                +-------------------------+---------------+

   [RFC Editor: Please replace RFCthis with the published RFC number for
   this document.]

8.1.1.  CDNI FCI DeliveryProtocol Payload Type

   Purpose: The purpose of this payload type is to distinguish FCI
   advertisement objects for supported delivery protocols

   Interface: FCI

   Encoding: see Section 7.2 and Section 7.5

8.1.2.  CDNI FCI AcquisitionProtocol Payload Type

   Purpose: The purpose of this payload type is to distinguish FCI
   advertisement objects for supported acquisition protocols

   Interface: FCI

   Encoding: see Section 7.3 and Section 7.5

8.1.3.  CDNI FCI RedirectionMode Payload Type

   Purpose: The purpose of this payload type is to distinguish FCI
   advertisement objects for supported redirection modes

   Interface: FCI

   Encoding: see Section 7.4 and Section 7.5

8.2.  Redirection Mode Registry

   The IANA is requested to create a new "CDNI Capabilities Redirection
   Modes" registry in the "Content Delivery Networks Interconnection
   (CDNI) Parameters" category.  The "CDNI Capabilities Redirection
   Modes" namespace defines the valid redirection modes that can be
   advertised as supported by a CDN.  Additions to the Redirection Mode

Seedorf, et al.         Expires October 14, 2016               [Page 18]
Internet-Draft  CDNI RR Footprint/Capabilities Semantics      April 2016

   namespace conform to the "IETF Review" policy as defined in
   [RFC5226].

   The following table defines the initial Redirection Modes:

     +------------------+----------------------------------+---------+
     | Redirection Mode | Description                      | RFC     |
     +------------------+----------------------------------+---------+
     | DNS-I            | Iterative DNS-based Redirection  | RFCthis |
     |                  |                                  |         |
     | DNS-R            | Recursive DNS-based Redirection  | RFCthis |
     |                  |                                  |         |
     | HTTP-I           | Iterative HTTP-based Redirection | RFCthis |
     |                  |                                  |         |
     | HTTP-R           | Recursive HTTP-based Redirection | RFCthis |
     +------------------+----------------------------------+---------+

   [RFC Editor: Please replace RFCthis with the published RFC number for
   this document.]

9.  Security Considerations

   This specification describes the semantics for capabilities and
   footprint advertisement objects across interconnected CDNs.  It does
   not, however, specify a concrete protocol for transporting those
   objects.  Specific security mechanisms can only be selected for
   concrete protocols that instantiate these semantics.  This document
   does, however, place some high-level security constraints on such
   protocols.

   All protocols that implement these semantics are REQUIRED to provide
   integrity and authentication services.  Without authentication and
   integrity, an attacker could trivially deny service by forging a
   footprint advertisement from a dCDN which claims the network has no
   footprint or capability.  This would prevent the uCDN from delegating
   any requests to the dCDN.  Since a pre-existing relationship between
   all dCDNs and uCDNs is assumed by CDNI, the exchange of any necessary
   credentials could be conducted before the FCI interface is brought
   online.  The authorization decision to accept advertisements would
   also follow this pre-existing relationship and any contractual
   obligations that it stipulates.

   All protocols that implement these semantics are REQUIRED to provide
   confidentiality services.  Some dCDNs are willing to share
   information about their footprint or capabilities with a uCDN but not
   with other, competing dCDNs.  For example, if a dCDN incurs an outage
   that reduces footprint coverage temporarily, that could be

Seedorf, et al.         Expires October 14, 2016               [Page 19]
Internet-Draft  CDNI RR Footprint/Capabilities Semantics      April 2016

   information the dCDN would want to share confidentially with the
   uCDN.

   As specified in this document, the security requirements of the FCI
   could be met by hop-by-hop transport-layer security mechanisms
   coupled with domain certificates as credentials (e.g., TLS transport
   for HTTP as per [RFC2818] and [RFC7230], with usage guidance from
   [RFC7525]).  There is no apparent need for further object-level
   security in this framework, as the trust relationships it defines are
   bilateral relationships between uCDNs and dCDNs rather than
   transitive relationships.

10.  References

10.1.  Normative References

   [I-D.ietf-cdni-metadata]
              Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma,
              "CDN Interconnection Metadata", draft-ietf-cdni-
              metadata-15 (work in progress), April 2016.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818,
              DOI 10.17487/RFC2818, May 2000,
              <http://www.rfc-editor.org/info/rfc2818>.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              DOI 10.17487/RFC5226, May 2008,
              <http://www.rfc-editor.org/info/rfc5226>.

   [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Message Syntax and Routing",
              RFC 7230, DOI 10.17487/RFC7230, June 2014,
              <http://www.rfc-editor.org/info/rfc7230>.

   [RFC7525]  Sheffer, Y., Holz, R., and P. Saint-Andre,
              "Recommendations for Secure Use of Transport Layer
              Security (TLS) and Datagram Transport Layer Security
              (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
              2015, <http://www.rfc-editor.org/info/rfc7525>.

Seedorf, et al.         Expires October 14, 2016               [Page 20]
Internet-Draft  CDNI RR Footprint/Capabilities Semantics      April 2016

10.2.  Informative References

   [I-D.ietf-cdni-logging]
              Faucheur, F., Bertrand, G., Oprescu, I., and R.
              Peterkofsky, "CDNI Logging Interface", draft-ietf-cdni-
              logging-25 (work in progress), April 2016.

   [RFC6707]  Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content
              Distribution Network Interconnection (CDNI) Problem
              Statement", RFC 6707, DOI 10.17487/RFC6707, September
              2012, <http://www.rfc-editor.org/info/rfc6707>.

   [RFC6770]  Bertrand, G., Ed., Stephan, E., Burbridge, T., Eardley,
              P., Ma, K., and G. Watson, "Use Cases for Content Delivery
              Network Interconnection", RFC 6770, DOI 10.17487/RFC6770,
              November 2012, <http://www.rfc-editor.org/info/rfc6770>.

   [RFC7336]  Peterson, L., Davie, B., and R. van Brandenburg, Ed.,
              "Framework for Content Distribution Network
              Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336,
              August 2014, <http://www.rfc-editor.org/info/rfc7336>.

   [RFC7337]  Leung, K., Ed. and Y. Lee, Ed., "Content Distribution
              Network Interconnection (CDNI) Requirements", RFC 7337,
              DOI 10.17487/RFC7337, August 2014,
              <http://www.rfc-editor.org/info/rfc7337>.

   [RFC7736]  Ma, K., "Content Delivery Network Interconnection (CDNI)
              Media Type Registration", RFC 7736, DOI 10.17487/RFC7736,
              December 2015, <http://www.rfc-editor.org/info/rfc7736>.

Appendix A.  Acknowledgment

   Jan Seedorf is partially supported by the GreenICN project (GreenICN:
   Architecture and Applications of Green Information Centric
   Networking), a research project supported jointly by the European
   Commission under its 7th Framework Program (contract no. 608518) and
   the National Institute of Information and Communications Technology
   (NICT) in Japan (contract no. 167).  The views and conclusions
   contained herein are those of the authors and should not be
   interpreted as necessarily representing the official policies or
   endorsements, either expressed or implied, of the GreenICN project,
   the European Commission, or NICT.

   Martin Stiemerling provided initial input to this document and
   valuable comments to the ongoing discussions among the authors of
   this document.  Thanks to Francois Le Faucheur and Scott Wainner for
   providing valuable comments and suggestions to the text.

Seedorf, et al.         Expires October 14, 2016               [Page 21]
Internet-Draft  CDNI RR Footprint/Capabilities Semantics      April 2016

Authors' Addresses

   Jan Seedorf
   NEC
   Kurfuerstenanlage 36
   Heidelberg  69115
   Germany

   Phone: +49 6221 4342 221
   Fax:   +49 6221 4342 155
   Email: seedorf@neclab.eu

   Jon Peterson
   NeuStar
   1800 Sutter St Suite 570
   Concord  CA 94520
   USA

   Email: jon.peterson@neustar.biz

   Stefano Previdi
   Cisco Systems
   Via Del Serafico 200
   Rome  0144
   Italy

   Email: sprevidi@cisco.com

   Ray van Brandenburg
   TNO
   Brassersplein 2
   Delft  2612CT
   The Netherlands

   Phone: +31-88-866-7000
   Email: ray.vanbrandenburg@tno.nl

Seedorf, et al.         Expires October 14, 2016               [Page 22]
Internet-Draft  CDNI RR Footprint/Capabilities Semantics      April 2016

   Kevin J. Ma
   Ericsson
   43 Nagog Park
   Acton, MA  01720
   USA

   Phone: +1 978-844-5100
   Email: kevin.j.ma@ericsson.com

Seedorf, et al.         Expires October 14, 2016               [Page 23]