[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 04

CDNI                                                          J. Seedorf
Internet-Draft                                                       NEC
Intended status: Informational                               J. Peterson
Expires: April 25, 2013                                          Neustar
                                                              S. Previdi
                                                                   Cisco
                                                        October 22, 2012


       CDNI Request Routing: Footprint and Capabilities Semantics
                draft-spp-cdni-rr-foot-cap-semantics-02

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 April 25, 2013.

Copyright Notice

   Copyright (c) 2012 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



Seedorf, et al.          Expires April 25, 2013                 [Page 1]


Internet-Draft  CDNI RR Footprint/Capabilities Semantics    October 2012


   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 . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Apparent Understanding of CDNI Footprint and Capabilities
       Advertisement  . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  Description of footprint and capabilities
           advertisement in existing CDNI documents . . . . . . . . .  4
     2.2.  Summary of understanding of footprint and capabilities
           advertisement in existing CDNI documents . . . . . . . . .  6
   3.  Design Decisions for Footprint and Capabilities  . . . . . . .  7
     3.1.  Advertising Limited Coverage . . . . . . . . . . . . . . .  7
     3.2.  Capabilities and Dynamic Data  . . . . . . . . . . . . . .  8
     3.3.  Advertisement versus Queries . . . . . . . . . . . . . . .  9
     3.4.  Avoiding or Handling 'cheating' Downstream CDNs  . . . . .  9
     3.5.  Focus on Main Use Cases may Simplify Things  . . . . . . . 10
   4.  Towards Semantics for Footprint Advertisement  . . . . . . . . 11
   5.  Towards Semantics for Capabilities Advertisement . . . . . . . 13
   6.  Open Issues and Questions  . . . . . . . . . . . . . . . . . . 16
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   8.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 18
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 19
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 19
   Appendix A.  Acknowledgment  . . . . . . . . . . . . . . . . . . . 20
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21



















Seedorf, et al.          Expires April 25, 2013                 [Page 2]


Internet-Draft  CDNI RR Footprint/Capabilities Semantics    October 2012


1.  Introduction

   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
   [I-D.ietf-cdni-use-cases], 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
   interface, in particular regarding the "footprint and capabilities
   advertisement" of a downstream CDN.  To narrow down undecided aspects
   of these semantics, this document first tries to capture the common
   understanding of what the "footprint and capabilities advertisement"
   should offer and accomplish, i.e. what seems to be agreed.  Then, the
   document will discuss open questions.  It is the goal of this
   document to capture the outcome of discussions and answers to open
   questions in future versions of this draft.  In particular, this
   document summarizes the progress of the recently formed CDNI design
   team on "footprint and capabilities advertisement".

   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.  We first recap the
   descriptions regarding "footprint and capabilities advertisement" in
   existing documents and try to distill the apparent common
   understanding of the terms "footprint" and "capabilities" in the CDNI
   request routing context.  We then separately discuss the semantics of
   the footprint advertisement mechanism, and the capability
   advertisement mechanism.  Finally, we list open issues and questions
   to be discussed in the CDNI WG.

   Comments and discussions about this memo should be directed to the
   CDNI WG: cdni@ietf.org.




Seedorf, et al.          Expires April 25, 2013                 [Page 3]


Internet-Draft  CDNI RR Footprint/Capabilities Semantics    October 2012


2.  Apparent Understanding of CDNI Footprint and Capabilities
    Advertisement

   In the following, we will summarize the descriptions of the CDNI
   "footprint and capabilities advertisement" as part of the "request
   routing" interface in existing documents.  We will then carve out the
   apparent common understanding of what this interface is intended to
   offer and accomplish.

2.1.  Description of footprint and capabilities advertisement in
      existing CDNI documents

   The CDNI problem statement draft [I-D.ietf-cdni-problem-statement]
   describes footprint and capabilities advertisement as: "enabling an
   upstream CDN to determine if a downstream CDN is able (and willing)
   to accept the delegated content request".  In addition, the draft
   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 draft [I-D.ietf-cdni-use-cases] describes
   capabilities as "... supported range of devices and User Agents or
   the supported range of delivery technologies".  Examples for such
   capabilities given are specific delivery protocols, technology
   migration, and meeting a certain QoS.

   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 requirements for the CDNI Request Routing
   Interface and general requirements are relevant for the understanding
   of the semantics of the "footprint and capabilities advertisement":

   o  GEN-4 [HIGH], "The CDNI solution shall not require intra-CDN
      information to be exposed to other CDNs for effective and
      efficient delivery 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 of levels beyond the first level."





Seedorf, et al.          Expires April 25, 2013                 [Page 4]


Internet-Draft  CDNI RR Footprint/Capabilities Semantics    October 2012


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

   o  GEN-11 [HIGH], "The CDNI solution shall prevent looping of any
      CDNI information exchange."

   o  REQ-1 [HIGH], allowing the downstream CDN "to communicate to the
      Upstream CDN coarse information about the Downstream CDN ability
      and/or willingness to handle requests from the Upstream CDN.  For
      example, this could potentially include 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), 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 CDNI
      Request-Routing interface shall allow the Downstream CDN to also
      include in the information communicated to the Upstream CDN,
      information on the capabilities, resources and affinities of CDNs
      to which the Downstream CDN may (in turn) redirect requests
      received by the Upstream CDN.  In that case, the CDNI Request-
      Routing interface shall prevent looping of such information
      exchange."

   o  REQ-4 [LOW], allowing the downstream CDN to communicate "aggregate
      information on CDNI administrative limits and policy" (e.g. the
      maximum number of requests redirected by the Upstream CDN to be
      served simultaneously by the Downstream CDN or maximum aggregate
      volume of content (e.g. in Terabytes) to be delivered by the
      Downstream CDN over a time period).

   o  REQ-11 [LOW], "The CDNI Request-Routing protocol may support a
      mechanism allowing an Upstream CDN to avoid redirecting a request
      to a Downstream CDN if that is likely to result in the total
      redirection time exceeding some limit."

   Note that in REQ-2 [MED] "Layer-3 coverage" is given as an example of
   what "footprint" information might convey in the CDNI requirements
   draft [I-D.ietf-cdni-requirements].  Also, note that REQ-3 [MED]
   addresses cascaded (transitive) downstream CDNs.  In such a case, a



Seedorf, et al.          Expires April 25, 2013                 [Page 5]


Internet-Draft  CDNI RR Footprint/Capabilities Semantics    October 2012


   downstream CDN needs to include (in its advertisement information
   that it conveys to an upstream CDN) also information the footprint
   and capabilities of any further transitive downstream CDN.  Such
   information may be included implicitly (i.e. the cascaded dCDN is
   oblivious to the uCDN), or explicitly (i.e. the cascaded dCDN of the
   fact that there is a cascaded dCDN is visible to the uCDN).  In any
   case, a logic is needed to process incoming footprint information
   from a cascaded dCDN and decide if/how it is to be re-advertised/
   aggregated when advertising footprint to an upstream CDN.

   The CDNI framework draft [I-D.davie-cdni-framework] describes a
   "footprint" as in [I-D.previdi-cdni-footprint-advertisement],
   consisting of two parts: 1) "a class of end user requests
   (represented, for example, by a set of IP prefixes, or a geographic
   region) that the dCDN is willing and able to serve directly, without
   use of another dCDN", and 2) "the connectivity of the dCDN to other
   CDNs that may be able to serve content to users on behalf of dCDN".
   The term "connectivity" has recently been replaced with
   "reachability" in [I-D.previdi-cdni-footprint-advertisement].
   Further, examples for capabilities are "the ability to handle certain
   types of content (e.g. specific streaming formats) or quality of
   service (QoS)."

2.2.  Summary of understanding of footprint and capabilities
      advertisement in existing CDNI documents

   In summary, neither the term "footprint" nor "capabilities" are
   clearly defined.  Also, a very broad range of potential capabilities
   is listed in the existing documents.






















Seedorf, et al.          Expires April 25, 2013                 [Page 6]


Internet-Draft  CDNI RR Footprint/Capabilities Semantics    October 2012


3.  Design Decisions for Footprint and Capabilities

   A large part of the difficulty lies in understanding what we mean
   when try to define footprint to 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, henceforth global CDNs;
   which we will henceforth call global CDNs.  The footprint advertised
   by such a CDN in the CDNi environment would, from a coverage or
   reachability perspective, presumably cover all prefixes.  More
   interesting for CDNi use cases, however, are CDNs that claim a more
   limited coverage, but seek to federate with other CDNs in order to
   create a single CDN fabric which shares resources fairly.

   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.

3.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
   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 joined a federation, however, and
   advertises its footprint to a uCDN, the original intended coverage of
   the CDN might not represent its actual value to the federation 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 of
   ISP-B, might happen to be topologically closest 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, should ISP-A's CDN "cover" E?  If
   ISP-B's CDN has a failure condition, should the uCDN understand that
   ISP-A's caches are potentially available 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, a federation mixing global and limited CDNs)?

   The answers to these questions greatly depend on how much information



Seedorf, et al.          Expires April 25, 2013                 [Page 7]


Internet-Draft  CDNI RR Footprint/Capabilities Semantics    October 2012


   we want the uCDN 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.  Alternatively, dCDNs could for
   their footprint 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.

3.2.  Capabilities and Dynamic Data

   In cases where the apparent footprint of dCDNs overlaps, uCDNs might
   also want to rely on a host of 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.

   In the absence of network-layer impediments to reaching caches, the
   choice to limit coverage is necessarily an administrative policy.
   Much policy must be agreed upon before CDNs 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 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
   federating.

   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 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 may 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 in order for it to
   make a decision.






Seedorf, et al.          Expires April 25, 2013                 [Page 8]


Internet-Draft  CDNI RR Footprint/Capabilities Semantics    October 2012


3.3.  Advertisement versus Queries

   In a federated CDN environment, each dCDN shares some of its state
   with the uCDN, which the uCDN uses to build a unified picture of all
   of the dCDNs available to it.  In architectures that share detailed
   capability information, the uCDN could basically perform the entire
   request-routing intelligence down to selecting a particular cache
   before sending the request to the dCDN (note that within the current
   CDNI WG scope, such direct selection of specific caches by the uCDN
   is out of scope).  However, when the uCDN must deal with many
   potential dCDNs, this approach does not scale.  Especially as CDNs
   scale up from dozens or hundreds of caches to thousands or tens of
   thousands, the volume of updates to footprint and capability may
   become onerous.

   Were the volume of updates to exceed the volumes of requests to the
   uCDN, it might make more sense for the uCDN to query dCDNs upon
   receiving requests, instead of receiving advertisements and tracking
   the state of dCDNs itself.  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/
   response model would work better for the uCDN decision than a state
   replication model?

3.4.  Avoiding or Handling 'cheating' Downstream CDNs

   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 uDCDN in
   order to convince the uCDN to select it opposed to "competing" other
   dCDNs.  It is therefore desirable to take away the incentive for
   dCDNs to cheat (in information advertised) as much as possible.  One
   option here is to make the information the dCDN advertises somehow
   verifiable for the uCDN.  One 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, it seems that information a dCDN advertises should (in the
   long run) be somehow verifiable by the uCDN.  However, it is probably
   an overly strict requirement to demand that such verification must be
   possible "immediately", i.e. during the request routing process



Seedorf, et al.          Expires April 25, 2013                 [Page 9]


Internet-Draft  CDNI RR Footprint/Capabilities Semantics    October 2012


   itself.  If the uCDN can detect a cheating dCDN at a later stage, it
   should suffice for the dCDN to "de-incentivize" cheating because it
   would negatively affect long-term business relationsships with uCDNs.

3.5.  Focus on Main Use Cases may Simplify Things

   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 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 should not be
   excluded, i.e. the scenario where more than one dCDN claims it can
   serve a given end user request.  Further, 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.

































Seedorf, et al.          Expires April 25, 2013                [Page 10]


Internet-Draft  CDNI RR Footprint/Capabilities Semantics    October 2012


4.  Towards Semantics for Footprint Advertisement

   Based on the characterizations in existing documents (see Section 2),
   we can distill some "rough" candidates for definitions of a
   footprint:

   o  Footprint could be defined by "layer-3 coverage", where coverage
      refers to a set of prefixes, a geographic region, or similar
      boundary.

   o  Footprint could alternatively be defined as "a class of end user
      requests a dCDN is willing to serve".

   Independent of the exact definition of footprint, a footprint likely
   needs to be able to include the connectivity of a given dCDN to other
   CDNs that may be able to serve content to users on behalf of that
   dCDN, to cover cases where there is a transitive CDN interconnection.
   Further, the downstream CDN must be able to express its footprint to
   an interested upstream CDN (uCDN) in a comprehensive form, e.g., as a
   complete data set containing the complete footprint.  Making
   incremental updates, however, to express dynamic changes in state is
   also desirable.

   Different concrete candidates for a footprint are imaginable (set of
   prefixes, a geographic region, ...).  Among these, "set of IP-
   prefixes" may potentially be a useful footprint in the CDDNI context.
   Such footprint information must be able to contain full IP addresses
   (i.e., a /32 for IPv4 and a /128 for IPv6) and also IP prefixes with
   an arbitrary prefix length.  There must be support for multiple IP
   address version, i.e., IPv4 and IPv6 in the footprint.

   Roughly speaking, footprint can be defined as "willingness to serve"
   by a downstream CDN.  However, in addition to simply "willingness to
   serve", the uCDN needs to have some additional information to make a
   dCDN selection decision.  The uCDN needs additional information so
   that it can assess "how well" a given dCDN can actually serve a given
   end user request; otherwise, any dCDN can claim it can deliver
   content to the whole world.  One can imagine that such additonal
   information is implicitly associated with a given footprint, e.g. due
   to (from the request routing interface's perspective out-of-band)
   contractual agreements (e.g.  SLAs), business relationships, or
   perceived dCDN quality in the past.  As an alternative, such
   additional information could also be explicitly be 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, i.e. prior to the advertisement phase of the CDNI



Seedorf, et al.          Expires April 25, 2013                [Page 11]


Internet-Draft  CDNI RR Footprint/Capabilities Semantics    October 2012


   request routing protocol.  The reason for this assumption is that any
   contractual agreement is likely to contain specifics about the dCDN
   coverage (i.e. the dCDN footprint) the contractual agreement applies
   to.  In particular, additional information to judge the delivery
   quality associated with a given dCDN footprint might be defined in
   contractual agreements (i.e. outside of the CDNI RR interface).
   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 (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 advertised by the CDNI request routing interface?
   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 request routing footprint advertisement 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.






























Seedorf, et al.          Expires April 25, 2013                [Page 12]


Internet-Draft  CDNI RR Footprint/Capabilities Semantics    October 2012


5.  Towards Semantics for Capabilities Advertisement

   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, WWW delivery, Video on Demand (VoD)
   delivery based on flash or apple technologies, or live streaming
   based on RTSP.

   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 VoD but not in some areas, either for maintenance
   reasons or because 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 must be expressed on a per
   footprint basis, it may be beneficial to combine footprint and
   capabilities advertisement.

   High-level and very rough semantics for (and characteristics of)
   capabilities are thus:

   o  Capabilities are types of information that allow a uCDN to
      determine if a downstream CDN is able (and willing) to accept the
      delegated content request.

   o  Capabilities are types of information that possibly may change
      over time based on the state of the network or caches.

   Candidates for capabilities seem to fall into several broad
   categories.  Some are capabilities associated with a resource itself,
   like the codecs or streaming technologies in which a particular
   resource is available.  Some capabilities are associated with the
   cache: these include the load state, available storage resources, and
   so on.  Some capabilities are associated with the network where the
   cache is deployed, including available bandwidth for streaming,
   availability of QoS mechanisms, and so on.

   Some capabilities reflect administrative restrictions or policies
   that may affect the decisions made up a uCDN.  It seems unlikely
   these factors will be shared through the interface, however.

   Potential Cache capabilities are:

   o  aggregate information (i.e. not for individual caches, but still
      helpful for dCDN selection) about load, or "excessive load"

   o  aggregate information (i.e. not for individual caches, but still
      helpful for dCDN selection) about available resources, storage



Seedorf, et al.          Expires April 25, 2013                [Page 13]


Internet-Draft  CDNI RR Footprint/Capabilities Semantics    October 2012


      resources

   o  aggregate information (i.e. not for individual caches, but still
      helpful for dCDN selection) regarding failure conditions

   Potential Resource Capabilities are:

   o  supported range of playback devices

   o  supported range of delivery technologies

   o  specific delivery protocols

   o  supported content types (MIME)

   Potential Network Capabilities are:

   o  meeting a certain QoS

   o  distribution and delivery priority

   o  streaming bandwidth

   Outside the scope of capability advertisements are administrative
   capabilities, such as:

   o  policy (membership in the federation, etc)

   o  administrative limits, e.g. maximum aggregate volume of content
      delivered monthly

   o  indication of distribution/delivery fees

   At a first glance, the above list of candidates contains useful
   capabilities to convey via an advertisement interface (and indeed the
   candidate capabilities listed above have been suggested in CDNI
   drafts, see Section 2).  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 probably not a good idea.  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, and perhaps
   more importantly, it seems not feasible to specify such highly
   dynamically changing capabilities and the corresponding metrics
   within the CDNI charter time-frame.

   Useful capabilities to convey are resource capabilities: Such
   information does not change highly dynamically and in many cases such



Seedorf, et al.          Expires April 25, 2013                [Page 14]


Internet-Draft  CDNI RR Footprint/Capabilities Semantics    October 2012


   information is absolutely necessary to decide on a dCDN for a given
   end user request.  For instance, if an end user request concerns the
   delivery of a movie with a certain protocol (e.g.  RTMP), the uCDN
   needs to knwo if a given dCDN has the capabiltity 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 of the CDNI request routing
   protocol.  The role of capabilities 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).

   Under the above considerations, the semantics of capabilities
   advertisement are roughly the following:

   o  The main category of useful capabilities to convey is resource
      capabilities.

   o  Advertisement 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 capabilities
   exactly are useful and how these can be expressed.  Since the details
   of CDNI contracts are not known at the time of this writing (i.e. at
   this point in time there are only very preliminary trials ongoing and
   no real deployments with actual contracts between CDNs yet), it
   remains to be seen what capabilities will be used to define
   agreements between CDNs in practise.  One implication for
   standardization may be to initially only specify very fey mandatory
   capabilities for advertisement and have on top of that a flexible
   protocol that allows to exchange additional capabilities when needed.
   Still, agreement needs to be found on what core capabilities are
   really needed to convey among CDNs.  As discussed in Section 3.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.








Seedorf, et al.          Expires April 25, 2013                [Page 15]


Internet-Draft  CDNI RR Footprint/Capabilities Semantics    October 2012


6.  Open Issues and Questions

   The following open issues deserve further discussion 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 the
      uCDNs?

   o  What exactly is a footprint based on? (e.g. prefix, geographic
      area, ASN, or location of surrogates/resources)

   o  Does a footprint need to include the "reachability" of the dCDN to
      other CDNs that may be able to serve content to users on behalf of
      dCDN?

   o  What is the assumed business relationship between the uCDN 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  To what extent should capability advertisement include or factor
      in dynamic attributes?



























Seedorf, et al.          Expires April 25, 2013                [Page 16]


Internet-Draft  CDNI RR Footprint/Capabilities Semantics    October 2012


7.  Security Considerations

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















































Seedorf, et al.          Expires April 25, 2013                [Page 17]


Internet-Draft  CDNI RR Footprint/Capabilities Semantics    October 2012


8.  Conclusion

   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, also
   reflecting ongoing discussions in the CDNI design team on "Footprint
   and Capabilities Advertisement".  Several key design decisions and
   open questions have been discussed.

   The discussion in this document has the objective to facilitate the
   choosing of one or more suitable protocols for "Footprint and
   Capabilities Advertisement" within CDNI Request Routing.  It is the
   goal of this document to capture the outcome of further progress of
   the CDNI WG and the design team on "Footprint and Capabilities
   Advertisement" including answers to currently open questions in
   future versions of this draft.


































Seedorf, et al.          Expires April 25, 2013                [Page 18]


Internet-Draft  CDNI RR Footprint/Capabilities Semantics    October 2012


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.

9.2.  Informative References

   [I-D.davie-cdni-framework]
              Davie, B. and L. Peterson, "Framework for CDN
              Interconnection", draft-davie-cdni-framework-01 (work in
              progress), October 2011.

   [I-D.ietf-cdni-problem-statement]
              Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content
              Distribution Network Interconnection (CDNI) Problem
              Statement", draft-ietf-cdni-problem-statement-08 (work in
              progress), June 2012.

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

   [I-D.ietf-cdni-use-cases]
              Bertrand, G., Emile, S., Burbridge, T., Eardley, P., Ma,
              K., and G. Watson, "Use Cases for Content Delivery Network
              Interconnection", draft-ietf-cdni-use-cases-10 (work in
              progress), August 2012.

   [I-D.peterson-cdni-strawman]
              Peterson, L. and J. Hartman, "A Simple Approach to CDN
              Interconnection", draft-peterson-cdni-strawman-01 (work in
              progress), May 2011.

   [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 (work in
              progress), September 2012.

   [I-D.xiaoyan-cdni-requestrouting]
              He, X., Li, J., Dawkins, S., and G. Chen, "Request Routing
              for CDN Interconnection",
              draft-xiaoyan-cdni-requestrouting-01 (work in progress),
              June 2011.



Seedorf, et al.          Expires April 25, 2013                [Page 19]


Internet-Draft  CDNI RR Footprint/Capabilities Semantics    October 2012


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.



























Seedorf, et al.          Expires April 25, 2013                [Page 20]


Internet-Draft  CDNI RR Footprint/Capabilities Semantics    October 2012


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

   Phone:
   Fax:
   Email: jon.peterson@neustar.biz


   Stefano Previdi
   Cisco Systems
   Via Del Serafico 200
   Rome  0144
   Italy

   Phone:
   Fax:
   Email: sprevidi@cisco.com


















Seedorf, et al.          Expires April 25, 2013                [Page 21]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/