CDNI                                                          J. Seedorf
Internet-Draft                                                       NEC
Intended status: Informational                               J. Peterson
Expires: September 6, 2012                                       Neustar
                                                              S. Previdi
                                                                   Cisco
                                                           March 5, 2012


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

Abstract

   This document tries to capture the semantics of the "Footprint and
   Capabilities Advertisment" part of the CDNI Request Routing
   interface, i.e. the desired meaning and what "Footprint and
   Capabilities Advertisment" 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
   Advertisment" 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 September 6, 2012.

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 September 6, 2012               [Page 1]


Internet-Draft     RR Footprint/Capabilities Semantics        March 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 footpring and capabilities
           advertisement in existing CDNI documents . . . . . . . . .  4
     2.2.  Summary of understanding of footprint and capabilities
           advertisement in existing CDNI documents . . . . . . . . .  5
   3.  Design Decisions for Footprint and Capabilities  . . . . . . .  6
     3.1.  Advertising Limited Coverage . . . . . . . . . . . . . . .  6
     3.2.  Capabilities and Dynamic Datae . . . . . . . . . . . . . .  7
     3.3.  Advertisement versus Queries . . . . . . . . . . . . . . .  8
   4.  Semantics for Footprint Advertisement  . . . . . . . . . . . .  9
   5.  Semantics for Capabilities Advertisement . . . . . . . . . . . 10
   6.  Open Issues and Questions  . . . . . . . . . . . . . . . . . . 12
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   8.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 15
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 15
   Appendix A.  Acknowledgment  . . . . . . . . . . . . . . . . . . . 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17





















Seedorf, et al.         Expires September 6, 2012               [Page 2]


Internet-Draft     RR Footprint/Capabilities Semantics        March 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 dicussions and answers to open
   questions in future versions of this draft.

   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 "capabilties" 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 September 6, 2012               [Page 3]


Internet-Draft     RR Footprint/Capabilities Semantics        March 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 footpring 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 are relevant for the
   understanding of the semantics of the "footprint and capabilities
   advertisement":

   o  REQ-1, allowing the downstream CDN to communicate "excessive load
      or failure condition".

   o  REQ-2, 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").




Seedorf, et al.         Expires September 6, 2012               [Page 4]


Internet-Draft     RR Footprint/Capabilities Semantics        March 2012


   o  REQ-4, 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).

   "Layer-3 coverage" is hence given as an example of what "footprint"
   information might convey in the CDNI requirements draft
   [I-D.ietf-cdni-requirements].

   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

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





















Seedorf, et al.         Expires September 6, 2012               [Page 5]


Internet-Draft     RR Footprint/Capabilities Semantics        March 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 covergage, 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 September 6, 2012               [Page 6]


Internet-Draft     RR Footprint/Capabilities Semantics        March 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 Datae

   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 September 6, 2012               [Page 7]


Internet-Draft     RR Footprint/Capabilities Semantics        March 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 built 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.  However, when the uCDN must
   deal with many potential dCDNs, this approach does not scale.
   Especially as CDNs scale up from dozens or hundred 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?

























Seedorf, et al.         Expires September 6, 2012               [Page 8]


Internet-Draft     RR Footprint/Capabilities Semantics        March 2012


4.  Semantics for Footprint Advertisement

   Based on the characterizations in existing documents (see Section 2),
   we can distill the following "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 be defined as the set of the IP addresses of the
      caches deployed by a CDN.

   o  Potentially, a footprint may include "the connectivity of the dCDN
      to other CDNs that may be able to serve content to users on behalf
      of dCDN".

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

   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.

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





















Seedorf, et al.         Expires September 6, 2012               [Page 9]


Internet-Draft     RR Footprint/Capabilities Semantics        March 2012


5.  Semantics for Capabilities Advertisement

   The dCDN must be able to express its general capabilities to the
   uCDN.  These general capabilites 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.

   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 if a downstream CDN is able (and willing) to accept
      the delegated content request.

   o  Some capabilities may change dynamically based on the state of the
      network or a cache.

   Capabilities seem to fall into several broad categories.  Some are
   capabilities associated with a resource iteslf, 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.

   Cache Capabilites are:

   o  load, or "excessive load"

   o  available resources, storage resources

   o  failure conditions

   Resource Capabilities:





Seedorf, et al.         Expires September 6, 2012              [Page 10]


Internet-Draft     RR Footprint/Capabilities Semantics        March 2012


   o  supported range of playback devices

   o  supported range of delivery technologies

   o  specific delivery protocols

   o  supported content types (MIME)

   Network Capabilities:

   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


























Seedorf, et al.         Expires September 6, 2012              [Page 11]


Internet-Draft     RR Footprint/Capabilities Semantics        March 2012


6.  Open Issues and Questions

   The following open issues deserve 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  Should footprint advertisement be based on prefixes, on cache
      addresses, or on other facts?

   o  Should capability advertisement include only static attributes of
      the CDN, or should it factor in dynamic attributes as well?

   o  How can the dCDN express the associated costs of delivery, either
      monetary or virtual costs, to the uCDN for the actual delivery?
      Is this in scope of this interface?

   o  Are monetary delivery costs explictly in scope of capabilities
      advertisement?

   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?






















Seedorf, et al.         Expires September 6, 2012              [Page 12]


Internet-Draft     RR Footprint/Capabilities Semantics        March 2012


7.  Security Considerations

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















































Seedorf, et al.         Expires September 6, 2012              [Page 13]


Internet-Draft     RR Footprint/Capabilities Semantics        March 2012


8.  Conclusion

   This document tried to capture the semantics of the "Footprint and
   Capabilities Advertisment" part of the CDNI Request Routing
   interface, i.e. the desired meaning and what "Footprint and
   Capabilities Advertisment" is expected to offer within CDNI.  Several
   key design decisions and open questions have been discussed.

   The discussion in this document has the onjective to facilitate the
   choosing of one or more suitable protocols for "Footprint and
   Capabilities Advertisment" within CDNI Request Routing.  It is the
   goal of this document to capture the outcome of dicussions and
   answers to open questions in future versions of this draft.






































Seedorf, et al.         Expires September 6, 2012              [Page 14]


Internet-Draft     RR Footprint/Capabilities Semantics        March 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-03 (work in
              progress), January 2012.

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

   [I-D.ietf-cdni-use-cases]
              Gilles, B., Watson, G., Ma, K., Eardley, P., Emile, S.,
              and T. Burbridge, "Use Cases for Content Delivery Network
              Interconnection", draft-ietf-cdni-use-cases-03 (work in
              progress), January 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., and J. Medved,
              "CDNI Footprint Advertisement",
              draft-previdi-cdni-footprint-advertisement-00 (work in
              progress), October 2011.

   [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 September 6, 2012              [Page 15]


Internet-Draft     RR Footprint/Capabilities Semantics        March 2012


Appendix A.  Acknowledgment

   Jan Seedorf is 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 September 6, 2012              [Page 16]


Internet-Draft     RR Footprint/Capabilities Semantics        March 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 September 6, 2012              [Page 17]