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

Versions: 00

Network Working Group                                       M. Caulfield
Internet-Draft                                                  K. Leung
Intended status: Standards Track                                   Cisco
Expires: April 26, 2012                                 October 24, 2011


   Content Distribution Network Interconnection (CDNI) Core Metadata
                 draft-caulfield-cdni-metadata-core-00

Abstract

   The CDNI Metadata Interface enables interconnected CDNs to exchange
   content distribution metadata for the purpose of content acquisition
   and delivery.  The CDNI metadata associated with a piece of content
   provides a downstream CDN with the information necessary for the
   downstream CDN to service content requests on behalf of an upstream
   CDN in accordance with the delivery policies defined by the upstream
   CDN.  This document describes the core set of CDNI metadata that all
   interconnected CDNs must support.

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 26, 2012.

Copyright Notice

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



Caulfield & Leung        Expires April 26, 2012                 [Page 1]


Internet-Draft             CDNI Core Metadata               October 2011


   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.  Core CDNI Metadata . . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  Acquisition Metadata . . . . . . . . . . . . . . . . . . .  4
     2.2.  Delivery Metadata  . . . . . . . . . . . . . . . . . . . .  5
   3.  Metadata Encoding  . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  ContentSource object . . . . . . . . . . . . . . . . . . .  6
     3.2.  ContentDelivery object . . . . . . . . . . . . . . . . . .  7
     3.3.  MetadataScope object . . . . . . . . . . . . . . . . . . .  7
     3.4.  Authentication object  . . . . . . . . . . . . . . . . . .  7
     3.5.  DeliveryCriteria object  . . . . . . . . . . . . . . . . .  8
     3.6.  DeliveryRules object . . . . . . . . . . . . . . . . . . .  8
     3.7.  Region object  . . . . . . . . . . . . . . . . . . . . . .  8
     3.8.  TimeWindow object  . . . . . . . . . . . . . . . . . . . .  9
     3.9.  Authorization object . . . . . . . . . . . . . . . . . . .  9
     3.10. Reference object . . . . . . . . . . . . . . . . . . . . .  9
   4.  Metadata Transport . . . . . . . . . . . . . . . . . . . . . . 10
   5.  CDNI Metadata Interface Bootstrapping  . . . . . . . . . . . . 10
   6.  Compliance with CDNI Requirements  . . . . . . . . . . . . . . 11
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
   10. Normative References . . . . . . . . . . . . . . . . . . . . . 12
   Appendix A.  Example Metadata  . . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13




















Caulfield & Leung        Expires April 26, 2012                 [Page 2]


Internet-Draft             CDNI Core Metadata               October 2011


1.  Introduction

   Several types of metadata flow through content delivery networks.
   For readability, a number of definitions from
   [I-D.ietf-cdni-problem-statement] related to metadata are quoted
   below:

      Content Metadata: This is metadata about Content.  Content
      Metadata comprises:

      1.  CDNI Metadata: Content Distribution Metadata with inter-CDN
          scope.  For example, CDNI Metadata may include geo-blocking
          information (i.e. information defining geographical areas
          where the content is to be made available or blocked),
          availability windows (i.e. information defining time windows
          during which the content is to be made available or blocked)
          and access control mechanisms to be enforced (e.g.  URI
          signature validation).  CDNI Metadata may also include
          information about desired distribution policy (e.g.
          prepositioned vs dynamic acquisition) and about where/how a
          CDN can acquire the content.  CDNI Metadata may also include
          content management information (e.g. request for deletion of
          Content from Surrogates) across interconnected CDNs. that is
          relevant to the distribution of the content (and therefore
          relevant to a CDN involved in the delivery of that content).
          We refer to this type of metadata as "Content Distribution
          Metadata".  See also the definition of Content Distribution
          Metadata.

      2.  Metadata that is associated with the actual Content (and not
          directly relevant to the distribution of that Content) or
          content representation.  For example, such metadata may
          include information pertaining to the Content's genre, cast,
          rating, etc as well as information pertaining to the Content
          representation's resolution, aspect ratio, etc.

      Content Distribution Metadata: The subset of Content Metadata that
      is relevant to the distribution of the content.  This is the
      metadata required by a CDN in order to enable and control content
      distribution and delivery by the CDN.  In a CDN Interconnection
      environment, some of the Content Distribution Metadata may have an
      intra-CDN scope (and therefore need not be communicated between
      CDNs), while some of the Content Distribution Metadata have an
      inter-CDN scope (and therefore needs to be communicated between
      CDNs).

      CDNI Metadata: Content Distribution Metadata with inter-CDN scope.
      For example, CDNI Metadata may include geo-blocking information



Caulfield & Leung        Expires April 26, 2012                 [Page 3]


Internet-Draft             CDNI Core Metadata               October 2011


      (i.e. information defining geographical areas where the content is
      to be made available or blocked), availability windows (i.e.
      information defining time windows during which the content is to
      be made available or blocked) and access control mechanisms to be
      enforced (e.g.  URI signature validation).  CDNI Metadata may also
      include information about desired distribution policy (e.g.
      prepositioned vs dynamic acquisition) and about where/how a CDN
      can acquire the content.  CDNI Metadata may also include content
      management information (e.g. request for deletion of Content from
      Surrogates) across interconnected CDNs.

   Interconnecting CDNs necessitates the exchange of the CDNI metadata
   as defined above.  The CDNI metadata associated with a piece of
   content (or set of contents) provides a downstream CDN with the
   information necessary for the downstream CDN to service content
   requests on behalf of an upstream CDN in accordance with the delivery
   policies defined by the upstream CDN.

   The CDNI Metadata Interface is introduced by
   [I-D.ietf-cdni-problem-statement], and discussed in
   [I-D.davie-cdni-framework], as one of the four required interfaces
   for CDN interconnection.  The requirements for this interface are
   specified in [I-D.ietf-cdni-requirements].

   This document first describes the core set of CDNI metadata that all
   interconnected CDNs must support.  Then the document describes the
   relationship between the core metadata and the encoding and transport
   for exchanging that metadata.


2.  Core CDNI Metadata

   Although the CDNI Metadata Interface should be flexible enough to
   support the exchange of arbitrary pieces of metadata, a CDN
   implementing the interface must support a set of core metadata.  The
   core CDNI metadata represent common policies for content distribution
   across CDNs.  All CDNI metadata may differ on a per-content-item
   basis or may be shared by a set of content items.  The core CDNI
   Metadata comprises acquisition metadata and delivery metadata.

2.1.  Acquisition Metadata

   If a downstream CDN receives a request for a content that is not yet
   cached by that CDN, it will attempt to acquire it from either an
   upstream CDN or an origin server.  The acquisition metadata for a
   piece of content provides the information needed by a downstream CDN
   to acquire the missing content.  The acquisition metadata includes a
   prioritized list of content sources.  Each content source includes



Caulfield & Leung        Expires April 26, 2012                 [Page 4]


Internet-Draft             CDNI Core Metadata               October 2011


   the following:

   1.  Protocol - acquisition protocol (e.g.  HTTP, FTP, ...).

   2.  URI - either an explicit URI for acquiring the content or a regex
       rule for converting from the content request URI to the
       acquisition URI.

   3.  Authentication - an object describing the authentication type
       (e.g.  HTTP Basic, Digest, etc.) and any parameters for that type
       (e.g. username and password).

2.2.  Delivery Metadata

   Once a piece of content is acquired, the delivery metadata controls
   where, when, how, and to whom the downstream CDN may deliver that
   content.  The delivery metadata includes a list of permissible
   delivery profiles.  Each profile includes criteria and rules for
   delivery.  Profile criteria include the following:

   1.  Protocol - delivery protocol (e.g.  HTTP, FTP, RTSP).

   2.  Region - a geographic region identified by country, AS number, or
       IP subnet.

   3.  Time window - a time period including a start time and an end
       time.

   If a content request matches all the criteria of a profile, then the
   rules for that profile should be applied.  Profile rules include the
   following:

   1.  Allow/deny - flag indicating whether or not the request should be
       permitted.

   2.  Authorization - a list of permissible authorization methods and
       their related parameters (e.g.  URL-signing, token-based, etc.).

   If a content request matches the criteria of multiple profiles in a
   list, it should use the rules of the first matching profile.


3.  Metadata Encoding

   Metadata is encoded as a hierarchy of objects which in practice may
   be implemented in JavaScript Object Notation (JSON), Extensible
   Markup Language (XML), or another variant.  This section describes
   the structure of the data but does not prescribe a particular



Caulfield & Leung        Expires April 26, 2012                 [Page 5]


Internet-Draft             CDNI Core Metadata               October 2011


   encoding (such as JSON or XML).  The language used below uses generic
   terms like "lists", "objects", and "fields" to describe the structure
   of the metadata.

   Each piece of content is associated with a CDNIMetadata object which
   has the following fields:

   1.  acquisitionOptions - an ordered list of ContentSource objects.
       The content sources are listed in order of priority with the
       first being the most desirable option.

   2.  deliveryProfiles - an ordered list of ContentDelivery objects.
       Like the content sources, the content delivery profiles are
       listed in order of priority.

   3.  metadataScope - a single MetadataScope object.

   The CDNIMetadata object fields may be expanded in the future to
   include a richer set of optional metadata.  Proprietary fields may be
   added with the "x-" prefix.

   All fields in the CDNI metadata are optional unless stated otherwise.
   If a field is missing, its default value should be used.  If the
   value of the field is the default, it need not be included.  The
   default value of a list is the empty list, an object is an empty
   object, and a string is an empty string unless stated otherwise.

3.1.  ContentSource object

   The ContentSource object describes a single acquisition point that a
   downstream CDN may contact to acquire the content.  This object has
   the following fields:

   1.  protocol - a string containing the name of the protocol that may
       be used to acquire the content (e.g.  HTTP, FTP, ...).  The
       default protocol is "http".

   2.  uriType - a string containing either "explicit" or "regex" which
       dictates how the uri field should be interpreted.  If the type is
       "explicit", the URI is to be used as is.  If the type is "regex"
       then the uri field specifies a regex substitution that should be
       performed on the content URL for mapping to the explicit URI.
       The default uriType is "explicit".

   3.  uri - a string containing either the URI of the content source or
       a regex substitution to generate the acquisition URI, depending
       on the value of uriType.  This field is required in a
       ContentSource object and its value may not be empty.



Caulfield & Leung        Expires April 26, 2012                 [Page 6]


Internet-Draft             CDNI Core Metadata               October 2011


   4.  auth - a single Authentication object.  If the auth field is
       missing, then authentication is not required for this
       ContentSource.

3.2.  ContentDelivery object

   The ContentDelivery object describes a permissible delivery profile
   for the content.  This object has the following fields:

   1.  deliveryCriteria - an ordered list of DeliveryCriteria objects.

   2.  deliveryRules - a single DeliveryRules object.

3.3.  MetadataScope object

   The MetadataScope object indicates that a CDNIMetadata object applies
   to more than one content and may be used as an optimization by
   downstream CDNs to avoid refetching duplicate metadata.  If a new
   content request meets the criteria in this object, then the entire
   CDNIMetadata object applies to that request and the downstream CDN
   need not refetch it.  The object includes the following fields:

   1.  host - an optional string containing a regex that could be
       checked against the Host header of an incoming HTTP request.

   2.  resource - an optional string containing a regex that could be
       checked against the requested resource name in an incoming HTTP
       request, to determine if the metadata object is associated to the
       requested content item.

   3.  protocol - an optional string containing a protocol name that may
       be checked against the client request protocol (e.g. "http" or
       "ftp").

   If the MetadataGroup object is missing from the CDNIMetadata object,
   then the CDNIMetadata object only applies to the requested content
   and may not be reused for different content requests.

3.4.  Authentication object

   The Authentication object describes an authentication type and its
   parameters.  It provides information for content acquisition such
   that the downstream CDN can be authenticated as a client when
   acquiring content from an upstream CDN or an origin server.  The
   Authentication object contains the following fields:

   1.  type - a string containing the authentication type "basic" or
       "digest".  The type dictates which optional fields are present



Caulfield & Leung        Expires April 26, 2012                 [Page 7]


Internet-Draft             CDNI Core Metadata               October 2011


       and valid in the rest of the object.  The "basic" and "digest"
       types refer to HTTP Basic and Digest access authentication
       [RFC2617] respectively.

   2.  username - a string containing the username for "basic" and
       "digest" types.

   3.  password - a string containing the password for "basic" and
       "digest" types.

3.5.  DeliveryCriteria object

   The DeliveryCriteria object specifies a set of criteria to match
   against incoming content requests including protocol, region, and
   time window.  The object includes the following fields:

   1.  protocol - a string containing the name of a protocol to match
       (e.g. "http", "ftp", ...).

   2.  region - a single Region object.

   3.  timeWindow - a single TimeWindow object.

3.6.  DeliveryRules object

   The DeliveryRules object describes the rules to apply to a particular
   content request in order to deliver a piece of content to the user
   agent on behalf of an upstream CDN.  This object includes the
   following fields:

   1.  allow - a boolean stating whether or not delivery is permitted.

   2.  auth - a single Authorization object.

3.7.  Region object

   The Region object specifies a region where the content is either
   allowed or disallowed.  A region may be described in three ways, only
   one of which needs to be present per Region object.  The object
   includes the following fields:

   1.  country - a string containing the country code for the region.

   2.  bgpAs - a number containing the BGP AS identifier of the region.

   3.  subnet - a string containing a dotted decimal IP address and
       subnet mask.




Caulfield & Leung        Expires April 26, 2012                 [Page 8]


Internet-Draft             CDNI Core Metadata               October 2011


3.8.  TimeWindow object

   The TimeWindow object specifies a time period when a content is
   available or not available.  The object includes the following
   fields:

   1.  startTime - a string containing an ISO 8601 formatted date and
       time in UTC.

   2.  endTime - a string containing the same format as startTime.

3.9.  Authorization object

   The Authorization object describes an authorization type and its
   parameters.  It provides information for content delivery such that
   the user agent can be authenticated as a client when requesting
   content from a downstream CDN.  The Authorization object contains the
   following fields:

   1.  type - a string containing the authorization type "url-signing"
       or "url-token".  The type dictates which optional fields are
       present and valid in the rest of the object.  The "url-signing"
       type refers to URL signing authorization.  The "url-token" type
       refers to token-based authorization.

   2.  algo - a string containing the signature algorithm (e.g. "md5",
       "sha-1", etc.).

   3.  symmetric - a boolean if true, URL signing uses symmetric keys,
       otherwise asymmetric.

   4.  key - a number containing the public key for verifying
       signatures, only valid if "symmetric" field is set to false.

   [Editor's note: parameters for URL signing and URL token
   authorization schemes are TBD.  Private key provisioning and
   distribution are outside the scope of the CDNI Metadata Interface. ]

3.10.  Reference object

   In order to avoid refetching large or common objects, any object may
   be replaced by a Reference object.  For example, the ContentSource
   object could be replaced by a Reference object which points to a URI.
   The downstream CDN should then request the referenced object in order
   to complete the metadata.  This object includes the following fields:

   1.  ref - a string containing a URI which points to the actual
       object.



Caulfield & Leung        Expires April 26, 2012                 [Page 9]


Internet-Draft             CDNI Core Metadata               October 2011


   A Reference object may be distinguished from any other type of object
   by checking for the presence of the "ref" field with a non-empty
   value.


4.  Metadata Transport

   Metadata objects (JSON, XML, etc.) are assumed to be transported over
   HTTP.  This section describes the relationship between the encoding
   and transport layers.

   Given a content request from an end client, when the downstream CDN
   needs to acquire the metadata associated with that content, the
   downstream CDN uses an HTTP GET to query the upstream CDN metadata
   server for the metadata object.

   The parameters to the query request are identical to the fields of
   the MetadataScope object discussed earlier.  This similarity is
   intentional and allows the downstream CDN to avoid refetching the
   same metadata for two different pieces of content (if the metadata is
   the same).  The query parameters are extracted from an incoming
   content request and are as follows:

   1.  host - the value of the Host header in an HTTP request.

   2.  resource - the resource on the request line of the HTTP request.

   3.  protocol - the protocol of the incoming request.

   After extracting these fields from the content request, the
   downstream CDN should first check its existing cache of metadata
   objects for possible matches (using the MetadataScope object).  If no
   match is found, the downstream CDN should then form a request to the
   upstream CDN metadata server, appending the host, resource, and
   protocol as query string parameters.

   The metadata server will respond with a CDNIMetadata object encoded
   in JSON, XML, or some other variant.


5.  CDNI Metadata Interface Bootstrapping

   This document makes a number of assumptions regarding the information
   available to the downstream CDN which is not part of the CDNI Core
   Metadata.  Information such as how a downstream CDN learns the
   address or hostname of the upstream metadata server is briefly
   described below.




Caulfield & Leung        Expires April 26, 2012                [Page 10]


Internet-Draft             CDNI Core Metadata               October 2011


   In the simplest case, the Control Interface will provision the URI of
   the metadata server to the downstream CDN and all metadata requests
   will be sent directly to this server.  The Control Interface could
   also provision an alternative URI in case the primary server is
   unreachable.

   In the case of multiple potential upstream CDNs, the downstream CDN
   must decide which metadata server should handle its request.  It is
   expected that the downstream CDN will be able to determine the
   upstream CDN that redirected that particular request from information
   contained in the received request (e.g. via the URI in case of HTTP
   redirection across CDNs).  With knowledge of which upstream CDN
   routed the request, the downstream CDN can choose the correct
   metadata server.


6.  Compliance with CDNI Requirements

   This section reviews compliance of the solution proposed in this
   document against the relevant set of requirements from
   [I-D.ietf-cdni-requirements].

   [Editor's note: the compliance information will be provided in
   subsequent versions]


7.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.


8.  Security Considerations

   The CDNI Metadata Interface is expected to be secured as a function
   of the transport protocol (e.g.  HTTP authentication).

   If a malicious metadata server is contacted by a downstream CDN, the
   malicious server may provide metadata to the downstream CDN which
   denies service for any piece of content to any user agent.  The
   malicious server may also provide metadata which directs a downstream
   CDN to a malicious origin server instead of the actual origin server.







Caulfield & Leung        Expires April 26, 2012                [Page 11]


Internet-Draft             CDNI Core Metadata               October 2011


9.  Acknowledgements

   The authors would like to thank Francois le Faucheur for his input
   and review.


10.  Normative References

   [I-D.davie-cdni-framework]
              Davie, B. and L. Peterson, "Framework for CDN
              Interconnection", draft-davie-cdni-framework-00 (work in
              progress), July 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-00 (work in
              progress), September 2011.

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

   [RFC2617]  Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
              Leach, P., Luotonen, A., and L. Stewart, "HTTP
              Authentication: Basic and Digest Access Authentication",
              RFC 2617, June 1999.


Appendix A.  Example Metadata

   Below is an example of a JSON object encoding a piece of CDNI
   metadata.  This metadata object applies to any content request with a
   hostname of "origin.example.com" and a resource identifier matching
   the regular expression "*/movies/*".  The "metadataScope" field
   summarizes these properties.  There is a single acquisition option as
   seen in the "acquisitionOptions" list.  The "deliveryProfiles"
   information restricts users in subnet "10.1.2.0/24" or using RTSP
   from accessing this content and allows users using HTTP.
   {
     "acquisitionOptions" :
     [
       {
         "protocol" : "http",
         "uri" : "http://origin.example.com/movies/content.mpg",
         "auth" :



Caulfield & Leung        Expires April 26, 2012                [Page 12]


Internet-Draft             CDNI Core Metadata               October 2011


         {
           "type" : "basic",
           "username" : "abcd",
           "password" : "pass123"
         }
       }
     ],
     "deliveryProfiles" :
     [
       {
         "deliveryCriteria" :
         [
           {
             "region" : { "subnet" : "10.1.2.0/24" },
           },
           {
             "protocol" : "rtsp"
           }
         ],
         "deliveryRules" :
         {
           "allow" : false
         }
       },
       {
         "deliveryCriteria" :
         [
           {
             "protocol" : "http"
           }
         ],
         "deliveryRules" :
         {
           "allow" : true
         }
       }
     ],
     "metadataScope" :
     {
       "host" : "origin.example.com",
       "resource" : "*/movies/*"
     }
   }








Caulfield & Leung        Expires April 26, 2012                [Page 13]


Internet-Draft             CDNI Core Metadata               October 2011


Authors' Addresses

   Matt Caulfield
   Cisco Systems
   1414 Massachusetts Ave
   Boxborough, MA  01719
   USA

   Phone: +1 978 936 9307
   Email: mcaulfie@cisco.com


   Kent Leung
   Cisco Systems
   3625 Cisco Way
   San Jose  95134
   USA

   Phone: +1 408 526 5030
   Email: kleung@cisco.com































Caulfield & Leung        Expires April 26, 2012                [Page 14]


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