CDNI                                                          J. Seedorf
Internet-Draft                                                       NEC
Intended status: Informational                               J. Peterson
Expires: January 16, April 24, 2014                                          Neustar
                                                              S. Previdi
                                                                   Cisco
                                                      R. van Brandenburg
                                                                     TNO
                                                                   K. Ma
                                                     Azuki Systems, Inc.
                                                           July 15,
                                                        October 21, 2013

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

Abstract

   This document tries to capture the semantics of the "Footprint and
   Capabilities Advertisement" part of the CDNI Request Routing
   interface, i.e. the desired meaning and what "Footprint and
   Capabilities Advertisement" is expected to offer within CDNI.  The
   discussion in this document has the goal to facilitate the choosing
   of one or more suitable protocols for "Footprint and Capabilities
   Advertisement" within CDNI Request Routing.

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."

   This Internet-Draft will expire on January 16, April 24, 2014.

Copyright Notice

   Copyright (c) 2013 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 Scope  . . . . . . . . . . . . . . . . . . .   2
   2.  CDNI FCI in existing CDNI Documents . . . . . . . . . . . . .   3
   3.  Design Decisions for Footprint and Capabilities . . . . . . .   6
     3.1.   4
     2.1.  Advertising Limited Coverage  . . . . . . . . . . . . . .   6
     3.2.   4
     2.2.  Capabilities and Dynamic Data . . . . . . . . . . . . . .   7
     3.3.   5
     2.3.  Advertisement versus Queries  . . . . . . . . . . . . . .   8
     3.4.   6
     2.4.  Avoiding or Handling 'cheating' dCDNs . . . . . . . . . .   9
     3.5.   6
     2.5.  Focus on Main Use Cases may Simplify Things . . . . . . .   9
   4.   7
   3.  Main Use Case to foster the Clarification of Semantics Consider . . .  10
   5.  Towards . . . . . . . . . . . . . . .   7
   4.  Semantics for Footprint Advertisement . . . . . . . .  10
   6.  Towards . . . .   8
   5.  Semantics for Capabilities Advertisement  . . . . . . . . . .  10
   6.  Negotiation of Support for Optional Types of
       Footprint/Capabilities  . . . . . . . . . . . . . . . . . . .  13
   7.  Open Issues and Questions  IANA Considerations . . . . . . . . . . . . . . . . . .  15 . . .  13
     7.1.  Footprint Sub-Registry  . . . . . . . . . . . . . . . . .  14
     7.2.  Protocol Sub-Registry . . . . . . . . . . . . . . . . . .  14
     7.3.  Redirection Mode Sub-Registry . . . . . . . . . . . . . .  14
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  16  15
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  16  15
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  16  15
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  16
   Appendix A.  Acknowledgment . . . . . . . . . . . . . . . . . . .  17  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

1.  Introduction and scope Scope

   The CDNI working group is working on a set of protocols to enable the
   interconnection of multiple CDNs to a CDN federation.  This CDN-
   federation should 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 in the
   CDNI WG 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 '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 should
   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.

   General assumptions in this document:

   o  The CDNs participating in the CDN federation 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 uCDN has received footprint and/or capability advertisements
      from a set of dCDNs.  Footprint advertisement and capability
      advertisement need not use the same underlying protocol.

   o  The upstream CDN (uCDN) receives the initial request-routing
      request from the endpoint requesting the resource.

   This document is organized as follows.  First, a recap of the
   definition of "footprint

   The CDNI Problem Statement [RFC6707] describes footprint and
   capabilities advertisement" advertisement as: "[enabling] a Request Routing function
   in existing
   documents is given, attempting an Upstream CDN to distill the apparent common
   understanding of what the terms 'footprint' and 'capabilities' mean query a Request Routing function in a
   Downstream CDN to determine if the context of CDNI.  Then, the detailed semantics of the
   footprint advertisement mechanism and the capability advertisement
   mechanism will be discussed.  Finally, open issues and questions Downstream CDN is able (and
   willing) to
   be discussed in accept the delegated Content Request".  In addition, the CDNI WG will be listed.

2.  CDNI FCI in existing CDNI Documents

   Descriptions of the CDNI FCI interface are highlighted in the CDNI
   Problem Statement [RFC6707], CDNI Use Cases [RFC6770], the CDNI draft
   requirements [I-D.ietf-cdni-requirements], and the CDNI framework
   draft [[I-D.ietf-cdni-framework].  An assessment of these
   descriptions is highlighted in the subsequent sections where the
   ambiguity associated with footprint and capabilities is examined.
   The objective of this document is to clarify the meaning of footprint
   and capability and define the semantics and method for which these
   attributes are exchanged between two cooperating CDN's.

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

   The CDNI Use Cases document [RFC6770] describes capabilities as "...
   supported range of devices different footprint definitions and User Agents or the supported range of
   delivery technologies".  Examples for such possible
   capabilities given are
   specific delivery protocols, technology migration, and meeting is very broad.  Attempting to define a
   certain QoS. comprehensive
   advertisement solution quickly becomes intractable.  The CDNI
   requirements draft [I-D.ietf-cdni-requirements] lists
   several requirements relevant for the "footprint and capabilities
   advertisement" part of the CDNI request routing interface.  In
   summary, the following specific
   requirements for the CDNI Request Routing Footprint & Capabilities Advertisement
   Interface in order to disambiguate footprints and general requirements are relevant for capabilities with
   respect to CDNI.  This document attempts to distill the apparent
   common understanding of what the terms 'footprint' and 'capabilities'
   mean in the context of CDNI, and detail the semantics of "footprint the
   footprint advertisement mechanism and capabilities advertisement":

   o  GEN-4 [HIGH], "The CDNI solution shall not require intra-CDN
      information to be exposed to other CDNs the capability advertisement
   mechanism.

2.  Design Decisions for effective Footprint and
      efficient delivery Capabilities

   A large part of the content.  Examples of intra-CDN
      information include surrogate topology, surrogate status, cached
      content, etc."

   o  GEN-9 [MED], "The CDNI solution should support cascaded CDN
      redirection (CDN1 redirects to CDN2 that redirects to CDN3) to an
      arbitrary number difficulty in discussing the FCI lies in
   understanding what exactly is meant when trying to define footprint
   in terms of levels beyond "coverage" or "reachability."  While the first level."

   o  GEN-10 [MED], "The CDNI solution should support an arbitrary
      topology operators of interconnected
   CDNs (i.e. the CDN topology cannot be
      restricted pick strategic locations to situate caches, a tree, cache with a loop-free topology, etc.)."

   o  GEN-11 [HIGH], "The CDNI solution shall prevent looping of
   public IPv4 address is reachable by any
      CDNI information exchange."

   o  REQ-1 [HIGH], allowing endpoint on the downstream CDN "to communicate to Internet
   unless some policy enforcement precludes the
      Upstream CDN coarse information about use of the Downstream CDN ability
      and/or willingness cache.

   Some CDNs aspire to handle requests from cover the Upstream CDN.  For
      example, this could potentially include entire world, which we will henceforth
   call global CDNs.  The footprint advertised by such a binary signal
      ("Downstream CDN ready/not-ready to take additional requests from
      Upstream CDN") to be used in case of excessive load or failure
      condition in the Downstream CDN."

   o  REQ-2 [MED], allowing the downstream CDN to communicate
      capabilities such as supported content types and delivery
      protocols, a set of metrics/attributes (e.g. Streaming bandwidth,
      storage resources, distribution and delivery priority), CDNI
   environment would, from a set of
      affinities (e.g. Preferences, indication of distribution/delivery
      fees), information to facilitate request redirection, as well as
      footprint information (e.g. "layer-3 coverage").

   o  REQ-3 [MED], "In the case of cascaded redirection, the coverage or reachability perspective,
   presumably cover all prefixes.  Potentially more interesting for CDNI
      Request-Routing interface shall allow the Downstream CDN to also
      include in the information communicated
   use cases, however, are CDNs that claim a more limited coverage, but
   seek to the Upstream CDN,
      information on the capabilities, resources and affinities of federate with other CDNs in order to which the Downstream create a single CDN may (in turn) redirect requests
      received by
   fabric which shares resources.

   Futhermore, not all capabilities need be footprint restricted.
   Depending upon the Upstream CDN.  In that use case, the CDNI Request-
      Routing interface shall prevent looping optimal semantics of such information
      exchange."

   o  REQ-4 [LOW], allowing the downstream CDN "footprints
   with capability attributes" vs. "capabilities with footprint
   restrictions" are not clear.

   The key to communicate "aggregate
      information on CDNI administrative limits and policy" (e.g. understanding the
      maximum number semantics of requests redirected by the Upstream CDN 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 be
      served simultaneously by the Downstream CDN or maximum aggregate
      volume decide
   among one of content (e.g. in Terabytes) several dCDNs.  The following section will discuss some
   of the trade-offs and design decisions that need to be delivered by decided upon
   for the
      Downstream CDN over a time period).

   o  REQ-11 [LOW], "The CDNI Request-Routing protocol may support FCI.

2.1.  Advertising Limited Coverage

   The basic use case that would motivate a
      mechanism allowing an Upstream CDN dCDN to avoid redirecting advertise a request 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 Downstream CDN if that is likely to result in the total
      redirection time exceeding some limit."

   Note that
   serve only their own customers by situating caches in REQ-2 [MED] "Layer-3 coverage" is given as an example close
   topological proximity to high concentrations of
   what "footprint" information might convey in their subscribers.
   The ISP knows the CDNI requirements
   draft [I-D.ietf-cdni-requirements].  Also, note prefixes it has allocated to end users and thus can
   easily construct a list of prefixes that REQ-3 [MED]
   addresses cascaded (transitive) downstream CDNs.  In its caches were positioned
   to serve.

   When such a case, a
   downstream purpose-built CDN needs joins a federation, however, and
   advertises its footprint to include (in a uCDN, the original intended coverage of
   the CDN might not represent its advertisement information
   that it conveys actual value to an upstream CDN) aggregate footprint and
   capabilities information for any further transitive downstream CDNs.
   Such information may be included implicitly (i.e. the cascaded dCDN
   is oblivious to the uCDN), or explicitly (i.e. the cascaded dCDN federation of
   the fact
   CDNs.  Consider an ISP-A and ISP-B that there both field their own CDNs,
   which they federate through CDNI.  A given user E, who is customer of
   ISP-B, might happen to be topologically closest to a cascaded dCDN is visible cache fielded by
   ISP-A, if E happens to the uCDN). live in a region where ISP-B has few customers
   and ISP-A has many.  In
   either this case, logic is needed to process incoming footprint
   information from should ISP-A's CDN "cover" E?  If
   ISP-B's CDN has a cascaded dCDN failure condition, should the uCDN understand that
   ISP-A's caches are potentially available back-ups - and decide if/how it is to be re-
   advertised/aggregated when if so, how
   does ISP-A advertise itself as a "standby" for E?  What about the
   case where CDNs advertising footprint to an upstream CDN. the same uCDN express overlapping
   coverage (for example, a federation mixing global and limited CDNs)?

   The CDNI framework draft [I-D.ietf-cdni-framework] describes answers to these questions greatly depend on how much information
   we want the uCDN to use to make a
   "footprint" as in [I-D.previdi-cdni-footprint-advertisement],
   consisting of two parts: 1) "a class selection of end user requests
   (represented, for example, by a set of IP prefixes, or dCDN.  If a geographic
   region) uCDN has
   three dCDNs to choose from that "cover" the dCDN is willing and able to serve directly, without
   use of another dCDN", and 2) "the connectivity IP address of user E,
   obviously the dCDN to other
   CDNs that may uCDN might be able to serve content interested to users on behalf know how optimal the
   coverage is from each of dCDN".

   The term "connectivity" has recently been replaced with
   "reachability" in [I-D.previdi-cdni-footprint-advertisement], the dCDNs - coverage need not be binary,
   either provided or not provided. dCDNs could advertise a coverage
   "score," for example, and as
   discussed above, "without provided that they all reported scores
   fairly on the same scale, uCDNs could use of another dCDN" may include aggregated
   transitive dCDNs.  Further examples for capabilities are "the ability that to handle certain types of content (e.g. specific streaming formats)
   or quality make their
   topological optimality decision.  Alternatively, dCDNs could for
   their footprint advertise the IP addresses of service (QoS)."  Content handling capabilities
   discussed in [I-D.ma-cdni-capabilities] include delivery and
   acquisition protocols, redirection modes, their caches rather
   than prefix "coverage," and metadata related
   capabilities (e.g., authorization algorithm).

   From reading the various draft listed above, it is safe to conclude
   that neither let the term 'footprint' nor 'capabilities' uCDN decide for itself (based on
   its own topological intelligence) which dCDN has been clearly
   and unambiguously defined in these documents and better resources to
   serve a very broad range given user.

   In summary, the semantics of potential capabilities is listed.

3.  Design Decisions advertising footprint depend on whether
   such qualitative metrics for Footprint and Capabilities

   A large expressing footprint (such as the
   coverage 'score' mentioned above) should be part of the difficulty in discussing CDNI FCI, or
   if it should focus just on 'binary' footprint.

2.2.  Capabilities and Dynamic Data

   In cases where the FCI lies in
   understanding what exactly is meant when trying to define apparent footprint
   in terms of "coverage" or "reachability."  While dCDNs overlaps, uCDNs might
   also want to rely on a host of other factors to evaluate the operators
   respective merits of
   CDNs pick strategic locations dCDNs.  These include facts related to situate caches, a the
   caches themselves, to the network where the cache with a
   public IPv4 address is reachable by any endpoint on the Internet
   unless some policy enforcement precludes deployed, to the use
   nature of the cache.

   Some CDNs aspire resource sought and to cover the entire world, which we will henceforth
   call global CDNs.  The footprint advertised by such a CDN in administrative policies of
   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 respective networks.

   In the absence of network-layer impediments to federate with other reaching caches, the
   choice to limit coverage is necessarily an administrative policy.
   Much policy must be agreed upon before CDNs in order can merge into
   federations, including questions of membership, compensation, volumes
   and so on.  A uCDN certainly will factor these sorts of
   considerations into its decision to create select a single CDN
   fabric which shares resources.

   Futhermore, not all capabilties dCDN, but there is
   probably little need for dCDNs to actually advertise them through an
   interface - they will be footprint restricted.
   Depending upon settled out of band as a precondition for
   federating.

   Other facts about the use case, dCDN would be expressed through the optimal semantics of "footprints
   with capability attributes" vs. "capabilities with footprint
   restrictions" are not clear.

   The key interface
   to understanding the semantics uCDN.  Some capabilities of footprint and capability
   advertisement lies in understand why a dCDN would advertise a limited
   coverage area, are static, and how a uCDN would use such advertisements to decide
   among one of several dCDNs.  The following section will discuss some
   of are
   highly dynamic.  Expressing the trade-offs and design decisions that need to be decided upon total storage built into its caches,
   for example, changes relatively rarely, whereas the CDNI FCI.

3.1.  Advertising Limited Coverage

   The basic amount of storage
   in use case that would motivate a dCDN to advertise a limited
   coverage at any given moment is that the CDN was built highly volatile.  Network bandwidth
   similarly could be expressed as either total bandwidth available to cover only a particular portion
   cache, or based on the current state of the Internet.  For example, an ISP could purpose-build network.  A cache may at
   one moment lack a CDN to
   serve only their own customers by situating caches particular resource in close
   topological proximity to high concentrations of their subscribers. storage, but have it the
   next.

   The ISP knows semantics of the prefixes it has allocated capabilities interface will depend on how much
   of the dCDN state needs to end users be pushed to the uCDN and thus can
   easily construct a list of prefixes qualitatively
   how often that its caches were positioned
   to serve.

   When such information should be updated.

2.3.  Advertisement versus Queries

   In a purpose-built federated CDN joins a federation, however, and
   advertises environment, each dCDN shares some of its footprint to a uCDN, state
   with the original intended coverage of uCDN, which the CDN might not represent its actual value uCDN uses to the federation build a unified picture of
   CDNs.  Consider an ISP-A and ISP-B that both field their own CDNs,
   which they federate through CDNI.  A given user E, who is customer all
   of
   ISP-B, might happen the dCDNs available to be topologically closest it.  In architectures that share detailed
   capability information, the uCDN could basically perform the entire
   request-routing intelligence down to selecting a particular cache fielded by
   ISP-A, if E happens
   before sending the request to live in a region where ISP-B has few customers
   and ISP-A has many.  In this case, should ISP-A's CDN "cover" E?  If
   ISP-B's CDN has a failure condition, should the uCDN understand dCDN (note that
   ISP-A's within the current
   CDNI WG scope, such direct selection of specific caches are potentially available back-ups - and if so, how by the uCDN
   is out of scope).  However, when the uCDN must deal with many
   potential dCDNs, this approach does ISP-A advertise itself not scale.  Especially as a "standby" for E?  What about the
   case where CDNs advertising
   scale up from dozens or hundreds of caches to thousands or tens of
   thousands, the same uCDN express overlapping
   coverage (for example, a federation mixing global and limited CDNs)?

   The answers volume of updates to these questions greatly depend on how much information
   we want footprint and capability may
   become onerous.

   Were the uCDN to use to make a selection volume of a dCDN.  If a uCDN has
   three dCDNs updates to choose from that "cover" exceed the IP address volumes of user E,
   obviously requests to the uCDN
   uCDN, it might be interested to know how optimal make more sense for the
   coverage uCDN to query dCDNs upon
   receiving requests (as is from each the case in the recursive redirection mode
   described in [I-D.ietf-cdni-framework]), instead of receiving
   advertisements and tracking the state of dCDNs - coverage need not be binary,
   either provided or not provided. itself.  The advantage
   of querying dCDNs could advertise a coverage
   "score," for example, and provided would be that they all reported scores
   fairly on much of the same scale, uCDNs could use dynamic data that to make their
   topological optimality decision.  Alternatively, dCDNs could for
   their footprint advertise the IP addresses of their caches rather
   than prefix "coverage," and let
   cannot share with the uCDN decide for itself (based on
   its own topological intelligence) which dCDN has better resources would now be factored into the uCDN's
   decision. dCDNs need not replicate any state to
   serve a given user.

   In summary, the uCDN - uCDNs
   could effectively operate in a stateless mode.

   The semantics of advertising both footprint and capability advertisement depend
   on whether
   such qualitative metrics for expressing footprint (such as the
   coverage 'score' mentioned above) should be part of the CDNI FCI, or
   if it should focus just on 'binary' footprint.

3.2.  Capabilities and Dynamic Data

   In service model here: are there cases where a synchronous query/
   response model would work better for the apparent footprint of uCDN decision than a state
   replication model?

2.4.  Avoiding or Handling 'cheating' dCDNs overlaps, uCDNs might
   also want

   In a situation where more than one dCDN is willing to rely on serve a host of other factors given
   end user request, it might be attractive for a dCDN to evaluate 'cheat' in the
   respective merits of dCDNs.  These include facts related
   sense that the dCDN provides inaccurate information to the
   caches themselves, uCDN in
   order to convince the network where uCDN to select it opposed to 'competing' dCDNs.
   It could therefore be desirable to take away the cache incentive for dCDNs
   to cheat (in information advertised) as much as possible.  One option
   here is deployed, to make the
   nature of information the resource sought and to dCDN advertises somehow
   verifiable for the administrative policies of uCDN.  One the respective networks.

   In the absence of network-layer impediments to reaching caches, other hand, a cheating dCDN might
   be avoided or handled by the
   choice to limit coverage is necessarily an administrative policy.
   Much policy must fact that there will be agreed upon before CDNs can merge into
   federations, including questions of membership, compensation, volumes
   and so on.  A strong
   contractual agreements between a uCDN certainly will factor these sorts of
   considerations into its decision to select and 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 so that a precondition for
   federating.

   Other facts about the dCDN
   would be expressed through the interface
   to the uCDN.  Some capabilities of risk severe penalties or legal consequences when caught
   cheating.

   Overall, it seems that information a dCDN are static, and some are
   highly dynamic.  Expressing advertises should (in the total storage built into its caches,
   for example, changes relatively rarely, whereas
   long run) be somehow qualitatively verifiable by the amount storage in
   use at any given moment uCDN, though
   possibly through non-real-time out-of-band audits.  It is highly volatile.  Network bandwidth
   similarly could be expressed as either total bandwidth available probably an
   overly strict requirement to a
   cache, or based on mandate that such verification be
   possible "immediately", i.e. during the current state of request routing process
   itself.  If the network.  A cache may uCDN can detect a cheating dCDN at
   one moment lack a particular resource in storage, but have later stage, it
   should suffice for the
   next.

   The semantics of uCDN to "de-incentivize" cheating because it
   would negatively affect the capabilities interface will depend long-term business relationship with a
   particular dCDN.

2.5.  Focus on how much
   of Main Use Cases may Simplify Things

   To narrow down semantics for "footprint" and "capabilities" in the dCDN state needs to
   CDNI context, it can be pushed useful to initially focus on key use cases to
   be addressed by the uCDN and qualitatively
   how often CDNI WG that information should are to be updated.

3.3.  Advertisement versus Queries envisioned the main
   deployments in the foreseeable future.  In this regard, a federated CDN environment, each dCDN shares some of its state
   with main
   realistic use case is the uCDN, existence of ISP-owned CDNs, which the uCDN uses to build
   essentially cover a unified picture of all certain operator's network.  At the same time,
   however, the possibility of overlapping footprints should not be
   excluded, i.e. the dCDNs available scenario where more than one dCDN claims it can
   serve a given end user request.  The ISPs may also choose to it.  In architectures federate
   with a fallback global CDN.

   It seems reasonable to assume that share detailed
   capability information, in most use cases it is the uCDN could basically perform
   that makes the entire
   request-routing intelligence down to decision on selecting a particular cache
   before sending the certain dCDN for request to
   routing based on information the dCDN (note uCDN has received from this
   particular dCDN.  It may be assumed that within 'cheating' CDNs will be
   dealt with via means outside the current
   CDNI WG scope, such direct selection scope of specific caches by CDNI and that the uCDN
   information advertised between CDNs is out of scope).  However, when accurate.  In addition,
   excluding the uCDN must deal with many
   potential dCDNs, this approach does not scale.  Especially as CDNs
   scale up from dozens or hundreds use of caches qualitative information (e.g., cache proximity,
   delivery latency, cache load) to thousands or tens of
   thousands, predict the volume quality of updates to footprint and capability may
   become onerous.

   Were delivery
   would further simplify the volume of updates use case allowing it to exceed better focus on
   the volumes basic functionality of requests 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
   uCDN, it might make more sense requirements for the uCDN to query dCDNs upon
   receiving requests (as is CDNI FCI.  To this end,
   the following (simplified) use case can help in clarifying the recursive redirection mode
   described in [I-D.ietf-cdni-framework]), instead
   semantics of receiving
   advertisements footprint and tracking capabilities for CDNI.  In particular, the state of dCDNs itself.  The advantage
   of querying dCDNs would be that much
   intention of the dynamic data that dCDNs
   cannot share with the uCDN would now use case is to clarify what information needs to be factored into
   exchanged on the uCDN's
   decision. dCDNs CDNI FCI, what types of information need not replicate any state to the uCDN - uCDNs
   could effectively operate be
   supported in a stateless mode.

   The semantics of both footprint mandatory fashion (and which should be considered
   optional), and capability advertisement depend
   on the service model here: are there cases where what types of information need to be updated with
   respect to a synchronous query/
   response model would work better for priori established CDNI contracts.

   In short, one can imagine the following use case: A given uCDN decision than a state
   replication model?

3.4.  Avoiding or Handling 'cheating' dCDNs

   In a situation where more than has
   several dCDNs.  It selects one dCDN is willing to serve a given
   end user request, it might be attractive for a delivery protocol A and
   footprint 1 and another dCDN to 'cheat' 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
   sense that first-level dCDN cannot serve delivery protocol
   B itself.  What happens if capabilities change in the transitive
   level-2 dCDN provides inaccurate information to that might affect how the uCDN selects a level-1 dCDN
   (e.g. in
   order case the level-2 dCDN cannot serve delivery protocol B
   anymore)?  How will these changes be conveyed to convince the uCDN?  In
   particular, what information does the uCDN need to select it opposed to 'competing' dCDNs.
   It could therefore be desirable able to take away the incentive select
   a new first-level dCDN, either for dCDNs
   to cheat (in information advertised) as much as possible.  One option
   here is to make the information the dCDN advertises somehow
   verifiable all of footprint 1 or only for the uCDN.  One
   subset of footprint 1 that the other hand, a cheating transitive level-2 dCDN might
   be avoided or handled by served on
   behalf of the fact that there will first-level dCDN?

4.  Semantics for Footprint Advertisement

   Roughly speaking, "footprint" can be strong
   contractual agreements between a uCDN defined as "ability and
   willingness to serve" by a dCDN, so that downstream CDN.  However, in addition to
   simple "ability and willingness to serve", the uCDN may wish to have
   additional information to make a dCDN
   would risk severe penalties or legal consequences when caught
   cheating.

   Overall, 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 seems was served.  One
   can imagine that such additional information is implicitly associated
   with a given footprint, e.g. due to contractual agreements (e.g.
   SLAs), business relationships, or perceived dCDN advertises should (in quality in the
   long run) past.
   As an alternative, such additional information could also be somehow qualitatively verifiable by
   explicitly tagged along with the uCDN, though
   possibly through non-real-time out-of-band audits. footprint.

   It is probably an
   overly strict requirement reasonable to mandate assume that such verification be
   possible "immediately", a significant part of the actual
   footprint advertisement will happen in contractual agreements between
   participating CDNs, i.e. during prior to the request routing process
   itself.  If advertisement phase using the uCDN can detect a cheating dCDN at a later stage, it
   should suffice
   CDNI FCI.  The reason for this assumption is that any contractual
   agreement is likely to contain specifics about the uCDN dCDN coverage
   (i.e. the dCDN footprint) the contractual agreement applies to.  In
   particular, additional information to "de-incentivize" cheating because it
   would negatively affect judge the long-term business relationship delivery quality
   associated with a
   particular dCDN.

3.5.  Focus on Main Use Cases may Simplify Things

   To narrow down semantics for "footprint" and "capabilities" given dCDN footprint might be defined in
   contractual agreements (i.e.  outside of the CDNI context, it FCI).  Further, one
   can assume that dCDN contractual agreements about the delivery
   quality associated with a given footprint will probably be useful to initially focus based on key use cases
   high-level aggregated statistics (i.e. 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 addressed advertised by the CDNI WG that are to FCI?  For instance, updates
   about temporal failures of part of a footprint can be envisioned useful
   information to convey via the main
   deployments CDNI request routing interface.  Such
   information would provide updates on information previously agreed in
   contracts between the foreseeable future. participating CDNs.  In this regard, a main
   realistic use case is other words, the existence of ISP-owned CDNs, which
   essentially cover CDNI
   FCI is a means for a certain operator's network.  At the same time,
   however, the possibility of overlapping footprints should not be
   excluded, i.e. the scenario where more than one dCDN claims to provide changes/updates regarding a
   footprint it can has prior agreed to serve in a given end user request.  The ISPs may also choose to federate contract with a fallback global CDN.

   It seems reasonable uCDN.

   Generally speaking, one can imagine two categories of footprint to assume that in most use cases it is the uCDN
   that makes the decision on selecting be
   advertised by a certain dCDN for request
   routing dCDN:

   o  Footprint could be defined based on information the uCDN has received "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
   particular dCDN.  It may be assumed that 'cheating' CDNs will footprint'.

   o  Footprint could 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 to predict the quality of delivery
   would further simplify the use case allowing it to better focus defined based on
   the basic functionality of the FCI.

4.  Main Use Case "resources", where resources
      refers to surrogates/caches a dCDN claims to foster have (e.g., the Clarification
      location of Semantics

   Focusing on a main use case surrogates/resources).  The dCDN claims that contains a simple (yet somewhat
   challenging), realistic, and generally imaginable scenario can help
   in narrowing down the requirements for the CDNI FCI.  To 'from
      this end,
   the following (simplified) use case footprint' it can help in clarifying the
   semantics serve incoming end user requests.

   For each of these footprint and types, there are capabilities for CDNI.  In particular, associated
   with a given footprint, i.e. the
   intention of capabilities (e.g., delivery
   protocol, redirection mode, metadata) supported in the use case is to clarify what information needs to be
   exchanged on coverage area
   for a "coverage/reachability" defined footprint, or the CDNI FCI, what capabilities
   of resources (e.g., delivery protocol, redirection mode, metadata
   support) for a "resources" defined footprint.

   It seems clear that "coverage/reachability" types of information need to footprint must
   be supported in a within CDNI.  The following such types of footprint are
   mandatory fashion (and which should be considered
   optional), and what types must be supported by the CDNI FCI:

   o  List of information need to ISO Country Codes

   o  List of AS numbers

   o  Set of IP-prefixes
   A 'set of IP-prefixes' must be updated with
   respect able to contain full IP addresses,
   i.e., a priori established CDNI contracts.

   In short, one can imagine the following use case: A given uCDN has
   several dCDNs.  It selects one dCDN /32 for delivery protocol A IPv4 and
   footprint 1 a /128 for IPv6, and another dCDN also IP prefixes with
   an arbitrary prefix length.  There must also be support for delivery protocol B multiple
   IP address versions, i.e., IPv4 and footprint 1.
   The dCDN that serves delivery protocol B has a further, transitive
   (level-2) dCDN, that serves delivery protocol B IPv6, in such a subset footprint.

   For all of these mandatory-to-implement footprint 1 where the first-level dCDN cannot serve delivery protocol
   B itself.  What happens if capabilities change in the transitive
   level-2 types, footprints
   can be viewed as constraints for delegating requests to a dCDN: A
   dCDN that might affect how footprint advertisement tells 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 limitations for
   delegating a request 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 dCDN.  For IP prefixes or only for ASN(s), the
   subset of
   footprint 1 signals to the uCDN that it should consider the transitive level-2 dCDN served on
   behalf a
   candidate only if the IP address of the first-level dCDN?

5.  Towards Semantics for Footprint Advertisement

   Roughly speaking, "footprint" can be defined as "ability and
   willingness to serve" by a downstream CDN.  However, in addition to
   simple "ability and willingness to serve", request routing source falls
   within the prefix set (or ASN, respectively).  The CDNI
   specifications do not define how a given uCDN may wish to have
   additional information to make determines what address
   ranges are in a dCDN selection decision, e.g., "how
   well" particular ASN.  Similarly, for country codes a given uCDN
   should only consider the dCDN can actually serve a given end user request.  The
   "ability and willingness" to serve should be distinguished from candidate if it covers the
   subjective qualitative measurement country of "how well" it was served.  One
   can imagine that such additonal information is implicitly associated
   with
   the request routing source.  The CDNI specifications do not define
   how a given footprint, e.g. due to contractual agreements (e.g.
   SLAs), business relationships, or perceived dCDN quality in the past.
   As an alternative, such additional information could also be
   explicitly tagged along with uCDN determines the footprint.

   It is reasonable to assume that a significant part country of the actual request routing
   source.  Multiple footprint advertisement will happen in contractual agreements between
   participating CDNs, constraints are additive, i.e. prior to the
   advertisement phase using the
   CDNI FCI.  The reason for this assumption is that any contractual
   agreement is likely to contain specifics about the dCDN coverage
   (i.e. of different types of footprint narrows the dCDN footprint) the contractual agreement applies to.  In
   particular, additional information
   candidacy cumulatively.

   It addition to judge the delivery quality
   associated with a given dCDN these mandatory "coverage/reachability" types of
   footprint, other optional "coverage/reachability" types of footprint might be
   or "resource" types of footprint may defined by future
   specifications.  To facilitate this, a clear process for specifying
   optional footprint types in
   contractual agreements (i.e.  outside a IANA registry must be specified.  This
   includes the specification of the CDNI FCI).  Further, one
   can assume that dCDN contractual agreements about level of oversight necessary (e.g.
   WG decision or expert review) for adding new optional footprints to a
   IANA registry as well as the delivery
   quality associated with specification of a given footprint will probably be based on
   high-level aggregated statistics (i.e. not too detailed).

   Given template regarding
   design choices that a large part must be captured by new optional types of
   footprints.

   Independent of footprint advertisement will actually
   happen in contractual agreements, the semantics exact type of CDNI a footprint, a footprint
   advertisement refer to answering the following question: what exactly
   still needs to be advertised by might also
   include the CDNI FCI?  For instance, updates
   about temporal failures of part connectivity of a footprint can given dCDN to other CDNs that may be useful
   information
   able to convey via the CDNI request routing interface.  Such
   information would provide updates serve content to users on information previously agreed in
   contracts between the participating CDNs.  In other words, the CDNI
   FCI behalf of that dCDN, to cover cases
   where there is a means for a dCDN transitive CDN interconnection.  Further, the
   downstream CDN must be able to provide changes/updates regarding a express its footprint it has prior agreed to serve an interested
   upstream CDN (uCDN) in a contract with comprehensive form, e.g., as a uCDN.

   Generally speaking, one can imagine two categories of footprint complete 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
   advertised by a dCDN:

   o  Footprint could be defined based on (layer-3) "coverage/
      reachability", where coverage/reachability refers able 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 express its general capabilities
   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 uCDN.  These general capabilities associated
   with could express if the dCDN
   supports a given footprint, i.e. service, for instance, HTTP delivery, RTP/RTSP
   delivery or RTMP.  Furthermore, the dCDN must be able to express
   particular capabilities (e.g., for the delivery
   protocol, redirection mode, metadata) supported in a particular footprint
   area.  For example, the coverage area dCDN might in general offer RTMP but not in
   some specific areas, either for a "coverage/reachability" defined footprint, maintenance reasons or because the capabilities
   of resources (e.g., delivery protocol, redirection mode, metadata
   support) for a "resources" defined footprint.

   It seems clear that "coverage/reachability" types of footprint must
   be supported within CDNI.  The following such types
   caches covering this particular area cannot deliver this type of
   service.  Hence, in certain cases footprint and capabilities are
   mandatory tied
   together and must cannot be supported by the CDNI FCI:

   o  List of ISO Country Codes

   o  List of AS numbers

   o  Set of IP-prefixes

   A 'set of IP-prefixes' interpreted independently from each other.  In
   such cases, i.e. where capabilities must be able to contain full IP addresses,
   i.e., expressed on a /32 for IPv4 per
   footprint basis, it may be beneficial to combine footprint and a /128 for IPv6,
   capabilities advertisement.

   A high-level and also IP prefixes with
   an arbitrary prefix length.  There must also be support very rough semantic for multiple
   IP address versions, i.e., IPv4 and IPv6, in such a footprint.

   For all capabilities is thus the
   following: Capabilities are types of these mandatory-to-implement footprint types, footprints
   can be viewed as constraints for delegating requests to information that allow 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
   determine 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 downstream CDN is able (and willing) to accept (and
   properly handle) a given uCDN determines the country of the request routing
   source.  Multiple footprint constraints delegated content request.  In addition,
   Capabilities are additive, i.e. the
   advertisement of different types of footprint narrows characterized by the dCDN
   candidacy cumulatively.

   It addition to these mandatory "coverage/reachability" types of
   footprint, other optional "coverage/reachability" types of footprint
   or "resource" types of footprint fact that this information may defined by future
   specifications.  To facilitate this, a clear process for specifying
   optional footprint types in a IANA registry must be specified.  This
   includes
   possibly change over time based on the specification state of the level of oversight necessary (e.g.
   WG decision network or expert review) for adding new optional footprints to
   caches.

   At a
   IANA registry as well as the specification first glance, several broad categories of a template regarding
   design choices capabilities seem
   useful to convey via an advertisement interface, however, advertising
   capabilities that must change highly dynamically (e.g. real-time delivery
   performance metrics, CDN resource load, or other highly dynamically
   changing QoS information) should probably not be captured by new optional types of
   footprints.

   Independent of in scope for the exact type
   CDNI FCI.  First, out of a footprint, a footprint might also
   include the connectivity multitude of possible metrics and
   capabilities, it is hard to agree on a given dCDN subset and the precise metrics
   to other CDNs that may be
   able used.  Second, and perhaps more importantly, it seems not
   feasible to serve content specify such highly dynamically changing capabilities and
   the corresponding metrics within the CDNI charter time-frame.

   Useful capabilities refer to users on behalf of information that dCDN, to cover does not change highly
   dynamically and which in many cases
   where there is a transitive CDN interconnection.  Further, the
   downstream CDN must be able to express its footprint absolutely necessary to decide
   on a particular dCDN for a given end user request.  For instance, if
   an interested
   upstream CDN (uCDN) in end user request concerns the delivery of a comprehensive form, e.g., as video file with a complete data
   set containing
   certain protocol (e.g. RTMP), the complete footprint.  Making incremental updates,
   however, uCDN needs to express dynamic changes in state is also desirable.

6.  Towards Semantics for Capabilities Advertisement

   In general, the know if a given dCDN must be able
   has the capabilitity of supporting this delivery protocol.

   Similar to express its general capabilities footprint advertisement, it is reasonable to assume that a
   significant part of the uCDN.  These general actual (resource) capabilities could express if advertisement
   will happen in contractual agreements between participating CDNs,
   i.e.  prior to the dCDN
   supports a given service, for instance, HTTP delivery, RTP/RTSP
   delivery or RTMP.  Furthermore, advertisement phase using the CDNI FCI.  The role
   of capability advertisement is hence rather to enable the dCDN must be able to express
   particular capabilities for the delivery
   update a uCDN on changes since a contract has been set up (e.g. in
   case a particular footprint
   area.  For example, new delivery protocol is suddenly being added to the dCDN might list of
   supported delivery protocols of a given dCDN, or in general offer RTMP but case a certain
   delivery protocol is suddenly not in
   some specific areas, either for maintenance reasons or because the
   caches covering this particular area cannot deliver this type being supported anymore due to
   failures).  Capabilities advertisement thus refers to conveying
   information to a uCDN about changes/updates 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 must be expressed on
   with respect to a per
   footprint basis, given contract.

   Given these semantics, it may be beneficial needs to combine footprint and be decided what exact capabilities advertisement.

   A high-level
   are useful and very rough semantic for capabilities is thus how these can be expressed.  Since the
   following: Capabilities are types details of information that allow a uCDN to
   determine if a downstream CDN is able (and willing) to accept (and
   properly handle) a delegated content request.  In addition,
   Capabilities CDNI
   contracts are characterized by not known at the fact that this information may
   possibly change over time based on the state of this writing (and the network or
   caches.

   At CDNI
   interface should probably be 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 may be to initially only specify a first glance, several broad categories very limited set
   of mandatory capabilities seem
   useful to convey via an for advertisement interface (and indeed many such
   candidate capabilities and have been suggested in CDNI drafts, see
   Section 2).  However, advertising capabilities on top of that change highly
   dynamically (e.g. real-time delivery performance metrics, CDN
   resource load, or other highly dynamically changing QoS information) a
   flexible data model that allows exchanging additional capabilities
   when needed.  Still, agreement needs to be found on which
   capabilities (if any) should probably not be mandatory among CDNs.  As discussed
   in scope for the CDNI FCI.  First, out of Section 2.5, finding the
   multitude of possible metrics and capabilities, it is hard concrete answers to agree these questions can
   benefit from focusing on a subset and the precise metrics to be used.  Second, small number of key use cases that are
   highly relevant and perhaps
   more importantly, it seems not feasible contain enough complexity to specify such highly
   dynamically changing help in
   understanding what concrete capabilities and are needed to facilitate CDN
   Interconnection.

   Under the corresponding metrics
   within above considerations, the CDNI charter time-frame.

   Useful following capabilities refer to information seem
   useful as 'base' capabilities, i.e. ones that does not change highly
   dynamically are needed in any case
   and which therefore constitute mandatory capabilities to be supported by
   the CDNI FCI:

   o  Delivery Protocol (e.g., HTTP vs. RTMP)

   o  Acquisition Protocol (for aquiring content from a uCDN)

   o  Redirection Mode (e.g., DNS Redirection vs. HTTP Redirection as
      discussed in many cases [I-D.ietf-cdni-framework])

   o  Capabilities related to CDNI Logging (e.g., supported logging
      mechanisms)

   o  Capabilities related to CDNI Metadata (e.g., authorization
      algorithms or support for proprietary vendor metadata)

   It is absolutely necessary not feasable to decide
   on a particular dCDN enumerate all the possible options for a given end user request.  For instance, if
   an end user request concerns the
   mandatory capabilities listed above (e.g., all the potential delivery of a video file with a
   certain protocol (e.g. RTMP),
   protocols or metadata options) or anticipate all the uCDN future needs for
   additional capabilities.  It would be unreasonable to know if a given dCDN
   has burden the capabiltity of supporting CDNI
   FCI specification with defining each supported capability.  Instead,
   the CDNI FCI specification should define a generic protocol for
   conveying any capability information.  In this delivery protocol.

   Similar to footprint advertisement, respect, it is seems
   reasonable to assume that define a
   significant part of registry which initially contains the actual (resource)
   mandatory capabilities advertisement
   will happen in contractual agreements between participating CDNs,
   i.e.  prior to the advertisement phase using the CDNI FCI. listed above, but may be extended as needs
   dictate.  The role
   of capability advertisement is hence rather to enable CDNI FCI specification SHOULD define the dCDN to
   update a uCDN on changes since a contract has been set up (e.g. in
   case a registry (and
   the rules for adding new delivery protocol is suddenly being added entries to the registry) for the different
   capability types.  Each capability type MAY further have a list of
   supported delivery protocols of
   valid values.  The individual CDNI interface specifications which
   define 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 capability SHOULD define any necessary registries (and
   the rules for adding new entries to the registry) for the values
   advertised for a uCDN about changes/updates of certain given capability type.

   The mandatory capabilities
   with respect listed above generally relate to
   information that is configured on 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 content asset or group of assets
   basis via CDNI
   contracts metadata.  The capability requirements for acquisition
   and delivery protocol and other mandatory metadata capabilities (e.g.
   authorization algorithms) are defined in [I-D.ietf-cdni-metadata].

   Note: CDNI interface support for logging configuration (i.e., control
   interface vs. metadata interface) has not known at the time of this writing (and yet been decided.  Once it
   has been decided, the corresponding CDNI interface specification
   should probably be agnostic to these contracts anyway), it
   remains to be seen what capabilities will be used to define
   agreements between CDNs in practice.  One implication the associated capability requirements.

6.  Negotiation of Support for
   standardization may be to initially only specify a very limited set Optional Types of mandatory Footprint/Capabilities

   The notion of optional types of footprint and capabilities for advertisement implies
   that certain implementations may not support all kinds of footprint
   and have on top capabilities.  Therefore, any FCI solution protocol must define
   how the support for optional types of that footprint/capabilities will be
   negotiated between a
   flexible data model uCDN and a dCDN that allows exchanging additional capabilities
   when needed.  Still, agreement use the particular FCI
   protocol.  In particular, any FCI solution protocol needs to be found on which
   capabilities (if any) should be mandatory among CDNs.  As discussed
   in Section 3.5, finding the concrete answers specify
   how to these questions can
   benefit from focusing on handle failure cases or non-supported types of footprint/
   capabilities.

   In general, a small number uCDN may ignore capabilities or types of key use cases that are
   highly relevant and contain enough complexity to help footprint it
   does not understand; in
   understanding what concrete capabilities are needed to facilitate this case it only selects a suitable
   downstream CDN
   Interconnection.

   Under the above considerations, based on the following types of capabilities seem
   useful as 'base' capabilities, i.e. ones that are needed in any case and therefore constitute mandatory capabilities to be footprint it
   understands.  Similarly, if a dCDN does not use an optional
   capability or footprint which is, however, supported by
   the CDNI FCI:

   o  Delivery Protocol (e.g., HTTP vs. RTMP)

   o  Acquisition Protocol (for aquiring content from a uCDN)

   o  Redirection Mode (e.g., DNS Redirection vs. HTTP Redirection as
      discussed in [I-D.ietf-cdni-framework])

   o  Capabilities related to CDNI Logging (e.g., supported logging
      mechanisms)

   o  Capabilities related to CDNI Metadata (e.g., authorization
      algorithms or support uCDN, this
   causes no problem for proprietary vendor metadata)

   It the FCI functionality because the uCDN decides
   on the remaining capabilities/footprint information that is not feasable to enumerate all being
   conveyed by the possible options dCDN.

7.  IANA Considerations

   IANA registries are to be used for mandatory and optional types of
   footprint and capabilities.  Therefore, the mandatory types of
   footprint and 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 in this document (see Section 5)
   are to burden the CDNI
   FCI specification be registered with defining each supported capability.  Instead,
   the CDNI FCI specification should define a generic protocol for
   conveying any capability information. IANA.  In this respect, it seems
   reasonable order to define prevent namespace
   collisions for capabilities a new IANA registry which initially contains is requested for the
   mandatory capabilities listed above, but may be extended as needs
   dictate.
   "CDNI Capabilities" namespace.  The namespace shall be split into two
   partitions: standard and vendor defined.  As with the CDNI FCI specification SHOULD define Metadata
   Interface [I-D.ietf-cdni-metadata], the registry (and vendor defined namespace
   partition SHOULD use a namespace prefix of "ext.", while the rules for adding new entries standard
   namespace partition MUST NOT.

   The standard namespace partition MUST conform to the registry) for the different
   capability types.  Each capability type MAY "RFC Required"
   policy as defined in [RFC5226].  The vendor defined namespace
   partition should be further have a list of
   valid values. partitioned into vendor specific
   partitions with the prefix "ext.vendor_name.".  The individual CDNI interface specifications which
   define a given capability vendor defined
   partition SHOULD define any necessary registries (and conform to the rules for adding new entries "Expert Review" policy as defined in
   [RFC5226].  The expert review is simply to prevent namespace
   hoarding.  The vendor specific partitions MAY conform to the registry) "First
   Come First Served" policy as defined in [RFC5226], however, vendors
   defining new capabilities which conflict with existing capabilities
   SHOULD follow the guidelines for the values
   advertised "Specification Required" policy
   as defined in [RFC5226].

   The following table defines the initial capabilities for a given the standard
   partition:

                 +----------------------+---------------+
                 | capability type.

   The mandatory           | Specification |
                 +----------------------+---------------+
                 | Delivery Protocol    | RFCthis       |
                 |                      |               |
                 | Acquisition Protocol | RFCthis       |
                 |                      |               |
                 | Redirection Mode     | RFCthis       |
                 +----------------------+---------------+

   Additional capabilities listed above generally relate specific to
   information that is configured on a content asset or group of assets
   basis via the CDNI metadata.  The capability requirements for acquisition
   and delivery protocol, redirection mode, Metadata Interface
   [I-D.ietf-cdni-metadata] and other mandatory metadata
   capabilities (e.g. authorization algorithms) are the CDNI Logging Interface
   [I-D.ietf-cdni-metadata] SHALL be addressed separately by those
   documents.

7.1.  Footprint Sub-Registry

   The "CDNI Metadata Footprint Types" namespace defined in
   [I-D.ietf-cdni-metadata].

   Note: CDNI interface support for logging configuration (i.e., control
   interface vs. metadata interface) has not yet been decided.  Once it
   has been decided, the corresponding CDNI interface specification
   should define
   Metadata Interface document [I-D.ietf-cdni-metadata] contains the associated capability requirements.

7.  Open Issues and Questions

   The following open issues deserve
   supported footprint formats for use in footprint advertisement.  No
   further discussion IANA action is required here.

7.2.  Protocol Sub-Registry

   The "CDNI Metadata Protocols" namespace defined in the CDNI WG:

   o  What is the service model of this interface: Does the uCDN always
      query the dCDNs?  Or does the dCDN always push information to Metadata
   Interface document [I-D.ietf-cdni-metadata] contains the
      uCDNs?

   o  Does a footprint need to explicitly include supported
   protocol values for the "transitive
      reachability" of a dCDN to Delivery Protocol and Acquisition Protocol
   capabilities.  No further dCDNs IANA action is required here.

7.3.  Redirection Mode Sub-Registry
   The "CDNI Capabilities Redirection Modes" namespace defines the valid
   redirection modes that may be able to serve
      content advertised as supported by a CDN.
   Additions to users on behalf of dCDN?

   o  What is the assumed business relationship between Redirection Mode namespace MUST conform to the uCDN
   "Expert Review" policy as defined in [RFC5226].  The expert review
   should verify that new type definitions do not duplicate existing
   type definitions and the
      dCDN?  Is the uCDN always the "authoritative" CDN provider which
      transitively has itself contracted several downstream CDN
      providers?

   o  How exactly can a given dCDN derive its footprint?

   o  Should the footprint/capabilities advertisement interface only
      signal the delta with respect prevent gratuitous additions to a given contract (between a uCDN
      and a dCDN) or send the whole dCDN state each time?

   o  What is the exact process for specifying optional footprint or
      capability types? namespace.
   For instance, for an IANA registry, what level
      of oversight new Redirection Modes which apply to new standard protocols, it
   is needed (should recommended that registration requests follow the WG decide, or an expert
      reviewer, or just a free-for-all)?

   o  How will "RFC Required"
   policy as defined in [RFC5226].

   The following table defines the support for optional types of footprint/capabilities
      be negotiated? initial Redirection Modes:

          +------------------+----------------------------------+
          | Redirection Mode | definition                       |
          +------------------+----------------------------------+
          | DNS-I            | Iterative DNS-based Redirection  |
          |                  |                                  |
          | DNS-R            | Recursive DNS-based Redirection  |
          |                  |                                  |
          | HTTP-I           | Iterative HTTP-based Redirection |
          |                  |                                  |
          | HTTP-R           | Recursive HTTP-based Redirection |
          +------------------+----------------------------------+

8.  Security Considerations

   Security considerations will be discussed in a future version of this
   document.

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC6707]  Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content
              Distribution Network Interconnection (CDNI) Problem
              Statement", RFC 6707, September 2012.

   [RFC6770]  Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma,
              K., and G. Watson, "Use Cases for Content Delivery Network
              Interconnection", RFC 6770, November 2012.

9.2.  Informative References

   [I-D.ietf-cdni-framework]
              Peterson, L. and B. Davie, "Framework for CDN
              Interconnection", draft-ietf-cdni-framework-03 draft-ietf-cdni-framework-06 (work in
              progress), October 2013.

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

   [I-D.ietf-cdni-metadata]
              Niven-Jenkins, B., Murray, R., Watson, G., Caulfield, M.,
              Leung, K., and K. Ma, "CDN Interconnect Metadata", draft-
              ietf-cdni-metadata-01
              ietf-cdni-metadata-02 (work in progress), February July 2013.

   [I-D.ietf-cdni-requirements]
              Leung, K. and Y. Lee, "Content Distribution Network
              Interconnection (CDNI) Requirements", draft-ietf-cdni-
              requirements-09 (work in progress), July 2013.

   [I-D.ma-cdni-capabilities]
              Ma, K., "Content Distribution Network Interconnection
              (CDNI) Capabilities Interface", draft-ma-cdni-
              capabilities-01 (work in progress), February 2013.

   [I-D.previdi-cdni-footprint-advertisement]
              Previdi, S., Faucheur, F., Faucheur, F., Medved, J., and
              L. Faucheur, "CDNI Footprint Advertisement", draft-
              previdi-cdni-footprint-advertisement-02
              requirements-10 (work in progress), September 2012. 2013.

Appendix A.  Acknowledgment

   Jan Seedorf is partially supported by the CHANGE project (CHANGE:
   Enabling Innovation in the Internet Architecture through Flexible
   Flow-Processing Extensions, http://www.change-project.eu/), a
   research project supported by the European Commission under its 7th
   Framework Program (contract no. 257422).  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 CHANGE project or
   the European Commission.

   Jan Seedorf has been partially supported by the COAST project
   (COntent Aware Searching, retrieval and sTreaming, http://www.coast-
   fp7.eu), a research project supported by the European Commission
   under its 7th Framework Program (contract no. 248036).  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 COAST project or
   the European Commission.

   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.

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
   Kevin J. Ma
   Azuki Systems, Inc.
   43 Nagog Park
   Acton  MA 01720
   USA

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