[Search] [pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09                                 
Network Working Group                                              K. Ma
Internet-Draft                                                  Ericsson
Intended status: Standards Track                              J. Seedorf
Expires: December 25, 2014                                           NEC
                                                           June 23, 2014


         CDNI Footprint & Capabilities Advertisement Interface
                     draft-ma-cdni-capabilities-05

Abstract

   Content Distribution Network Interconnection (CDNI) is predicated on
   the ability of downstream CDNs (dCDNs) to handle end-user requests in
   a functionally equivalent manner to the upstream CDN (uCDN).  The
   uCDN must be able to assess the ability of the dCDN to handle
   individual requests.  The CDNI Footprint & Capabilities Advertisement
   interface (FCI) is provided for the advertisement of capabilities and
   the footprints to which they apply by the dCDN to the uCDN.  This
   document describes an approach to implementing the CDNI FCI.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Status of This Memo

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

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

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

   This Internet-Draft will expire on December 25, 2014.








Ma & Seedorf            Expires December 25, 2014               [Page 1]


Internet-Draft                CDNI Metadata                    June 2014


Copyright Notice

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

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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  CDNI FCI Capability Advertisement . . . . . . . . . . . . . .   4
     2.1.  CDNI FCI Capability Initialization  . . . . . . . . . . .   4
   3.  CDNI FCI Capabilities Service . . . . . . . . . . . . . . . .   5
     3.1.  CDNI FCI Map  . . . . . . . . . . . . . . . . . . . . . .   5
       3.1.1.  Media Type  . . . . . . . . . . . . . . . . . . . . .   5
       3.1.2.  HTTP Method . . . . . . . . . . . . . . . . . . . . .   5
       3.1.3.  Accept Input Parameters . . . . . . . . . . . . . . .   6
       3.1.4.  Capabilities  . . . . . . . . . . . . . . . . . . . .   6
       3.1.5.  Uses  . . . . . . . . . . . . . . . . . . . . . . . .   6
       3.1.6.  Response  . . . . . . . . . . . . . . . . . . . . . .   6
       3.1.7.  CDNI FCI Capabilities . . . . . . . . . . . . . . . .   7
         3.1.7.1.  Delivery Protocol . . . . . . . . . . . . . . . .   7
         3.1.7.2.  Acquisition Protocol  . . . . . . . . . . . . . .  10
         3.1.7.3.  Redirection Mode  . . . . . . . . . . . . . . . .  12
         3.1.7.4.  Logging Capabilities  . . . . . . . . . . . . . .  14
         3.1.7.5.  Metadata Capabilities . . . . . . . . . . . . . .  14
       3.1.8.  Example . . . . . . . . . . . . . . . . . . . . . . .  14
   4.  CDNI FCI Capabilities Filtering Service . . . . . . . . . . .  16
     4.1.  Filtered CDNI FCI Map . . . . . . . . . . . . . . . . . .  16
       4.1.1.  Media Type  . . . . . . . . . . . . . . . . . . . . .  16
       4.1.2.  HTTP Method . . . . . . . . . . . . . . . . . . . . .  16
       4.1.3.  Accept Input Parameters . . . . . . . . . . . . . . .  16
       4.1.4.  Capabilities  . . . . . . . . . . . . . . . . . . . .  16
       4.1.5.  Uses  . . . . . . . . . . . . . . . . . . . . . . . .  16
       4.1.6.  Response  . . . . . . . . . . . . . . . . . . . . . .  16
       4.1.7.  Example . . . . . . . . . . . . . . . . . . . . . . .  16
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  17
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  17



Ma & Seedorf            Expires December 25, 2014               [Page 2]


Internet-Draft                CDNI Metadata                    June 2014


   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  17
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  17
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  17
   Appendix A.  Capability Aggregation . . . . . . . . . . . . . . .  18
     A.1.  Downstream CDN Aggregation  . . . . . . . . . . . . . . .  18
     A.2.  Internal Request Router Aggregation . . . . . . . . . . .  20
     A.3.  Internal Capability Aggregation . . . . . . . . . . . . .  21
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  23

1.  Introduction

   The need for footprint and capabilities advertisement in CDNI is
   described in the CDNI requirements document
   [I-D.ietf-cdni-requirements].  Requirements FCI-1 and FCI-2 describe
   the need to allow dCDNs to communicate capabilities to the uCDN.
   Requirement FCI-3 describes how a uCDN may aggregate the footprint
   and capabilities information for all cascaded dCDNs and use the
   aggregated information in advertisements to CDNs further upstream.
   This concept of aggregation can apply to both organizationally
   different dCDNs (e.g., other CDN providers, or different business
   units within a larger organization) or logical entities within the
   same CDN (e.g., using multiple request routers for scalability
   reasons, to segregate surrogates based on specific protocol support,
   or to segregate surrogates based on software version or feature
   level, etc.).

   Appendix A contains more detailed descriptions of different footprint
   and capabilities management scenarios, but it is important to note
   that it is the ability of the dCDN to service each request in a
   functionally equivalent manner as the uCDN that is important, not the
   physical layout of resources through which it services the request.
   The aggregation of resource knowledge by the dCDN into a simple set
   of capabilities and their affective footprints, that is then
   advertised to the uCDN enables efficient decision making at each
   delegation point in the CDN interconnection hierarchy.

   It is assumed that an authoritative request router in each CDN will
   be responsible for aggregating and advertising capabilities
   information in a dCDN, and receiving and aggregating capabilities
   information in the uCDN.  The CDNI Footprint & Capabilities
   Advertisement interface (FCI) along with the CDNI Request Routing
   Redirection interface (RI) make up the CDNI Request Routing
   Interface.  As there is no other centralized CDNI controller, the
   authoritative request router seems the most logical place for
   capabilities aggregation to occur, as it is the request router that
   needs such information to make delegation decisions.  The protocol
   defined herein may be implemented as part of an entity other than an
   authoritative request router, but for the purposes of this



Ma & Seedorf            Expires December 25, 2014               [Page 3]


Internet-Draft                CDNI Metadata                    June 2014


   discussion, the authoritative request router is assumed to be the
   centralized capabilities aggregation point.

   Though there is an obvious need for the ability to exchange and
   update footprint and capability information in real-time, it is
   assumed that capabilities do not change very often.  It is also
   assumed that the capabilities are not by themselves useful for making
   delegation decisions.  Capability information is assumed to be input
   into business logic.  It is the business logic which provides the
   algorithms for delegation decision making.  The definition of
   business logic occurs outside the scope of CDNI and outside the
   timescale of footprint and capability advertisement.  It may be the
   case that the business logic anticipates and reacts to changes in
   dCDN capabilities.  However, it may also be the case that business
   logic is tailored through offline processes as dCDN capabilities
   change.  The FCI is agnostic to the business processes employed by
   any given uCDN.  The footprints and capabilities that are advertised
   over the FCI may be used by the uCDN at its discretion to implement
   delegation rules.  Setting proper defaults in the business logic
   should prevent any unwanted delegation from occurring when dCDN
   capabilities change, however, that is beyond the scope of this
   discussion.

1.1.  Terminology

   This document uses the terminology defined in section 1.1 of the CDNI
   Framework [I-D.ietf-cdni-framework] document.

2.  CDNI FCI Capability Advertisement

   The FCI is implemented as an ALTO [I-D.ietf-alto-protocol] Service.
   The ALTO protocol defines an HTTP-based transport through which ALTO
   service information may be retrieved using either a GET or POST
   method.  The uCDN request router may at any time query the dCDN ALTO
   FCI Service for the full set of dCDN capability information.  The
   uCDN may use a separate FCI Filter Service may be used to retrieve a
   subset of the dCDN capability information.

   [Ed.: Need to update this with ALTO asynchronous update support.]

   [Ed.: Need to update this with ALTO incremental update support.]

2.1.  CDNI FCI Capability Initialization

   In lieu of any out-of-band pre-configured capability information,
   when the FCI is first brought up between a uCDN and dCDN, the uCDN
   SHOULD assume that the dCDN has no CDNI capabilities.  If an out-of-
   band capability baseline has been exchanged, the uCDN MAY use that



Ma & Seedorf            Expires December 25, 2014               [Page 4]


Internet-Draft                CDNI Metadata                    June 2014


   information to initialize its capabilities database.  In either case,
   the uCDN SHOULD verify the initial state of the dCDN (as a temporary
   outage may be affecting availability in the dCDN).

   The dCDN MUST support sending its entire set of capabilities to the
   uCDN through the ALTO service interface

   [Ed.: The alternative to using a pull from the uCDN is to use the
   triggers interface for a triggered push, however, this would not be
   triggering a CDN function, it would be triggering an FCI function, so
   given that there is no asynchronous action required by the dCDN, it
   seems that reducing inter-dependency on other CDNI interfaces makes
   the most sense in this case.]

3.  CDNI FCI Capabilities Service

   As described in Requirement FCI-2, there is a basic set of
   capabilities that must be supported by the FCI for the uCDN to be
   able to determine if the dCDN is functionally able to handle a given
   request.  The CDNI Footprint and Capabilities Semantics
   [I-D.ietf-cdni-footprint-capabilities-semantics] document lists
   mandatory capabilities types:

   o  Delivery Protocol

   o  Acquisition Protocol

   o  Redirection Mode

   o  CDNI Logging Capabilities

   o  CDNI Metadata Capabilities

   To be consistent with the base ALTO service definitions, we use the
   JSON object definition notation as specified in the ALTO
   [I-D.ietf-alto-protocol] protocol document.

3.1.  CDNI FCI Map

3.1.1.  Media Type

   The media type of CDNI FCI Map is "application/alto-cdni-fcimap+json"

3.1.2.  HTTP Method

   A CDNI FCI Map resource is requested using the HTTP GET method.





Ma & Seedorf            Expires December 25, 2014               [Page 5]


Internet-Draft                CDNI Metadata                    June 2014


3.1.3.  Accept Input Parameters

   None.

3.1.4.  Capabilities

   None.

3.1.5.  Uses

   None.

3.1.6.  Response

   The data component of a CDNI FCI Map resource is named "fcimap" which
   is a JSON object of type FCIMapData:

      object {
         FCIMapData fcimap<0..*>;
      } InfoResourceFCIMap : ResponseEntityBase;

      object {
         JSONString name;
         JSONString values<1..*>;
         FCIFootprint footprint<0..*>;
      } FCIMapData;

      object {
         JSONString type;
         JSONString values<1..*>;
      } FCIFootprint;

   The FCIMapData object contains a capability name which identifies the
   capability, a values array containing the associated list of
   supported options for that named capability, as well as an optional
   list of FCIFootprint objects.  The FCIFootprint object specifies a
   footprint type which identifies the encoding of the individual
   footprint entries contained in the associated values array.

   The list of valid capability options for a given capability will be
   specific to the given named capability.  Though the degenerate case
   may exist where the range of option values is a single value, it is
   anticipated that all capability types will have more than one
   capability option value.  For consistency in the model, all
   capability types are implemented with lists of values.  To optimize
   actions on the entire range of capability option values for a given
   capability type, the capability option value "ALL" is reserved and
   MUST be supported by all capability types.  For completeness, the



Ma & Seedorf            Expires December 25, 2014               [Page 6]


Internet-Draft                CDNI Metadata                    June 2014


   capability option value "NONE" is also reserved and MUST be supported
   by all capability types.  If a reserved value is specified, it MUST
   be the only entry in the capability value list.

   The CDNIFootprint object type field contains a registered footprint
   type value from the "CDNI Metadata Footprint Types" registry.  The
   CDNI Footprint and Capabilities Semantics
   [I-D.ietf-cdni-footprint-capabilities-semantics] document lists the
   mandatory footprint types as: ISO Country Code, AS number, and IP-
   prefix.  The CDNI Metadata Interface [I-D.ietf-cdni-metadata]
   document defines the footprint type registry and the initial values
   for the mandatory footprint types.  It also describes the process for
   registering additional optional footprint types.  The footprint value
   "GLOBAL" is reserved and MUST be supported by all footprint types.
   If the reserved value "GLOBAL" is specified, it MUST be the only
   entry in the footprint value list.

   The footprint restriction list MUST NOT contain multiple footprint
   objects of the same type.  Footprint restriction information MAY be
   specified using multiple different footprint types.  If no footprint
   restriction list is specified (or an empty list is specified), it
   SHALL be understood that all footprint types MUST be reset to
   "GLOBAL" coverage.

   Note: Further optimization of the footprint object to provide quality
   information for a given footprint is certainly possible, however, it
   is not critical to the basic interconnection of CDNs.  The ability to
   transfer quality information in capabilities advertisements may be
   desirable and is noted here for completeness, however, the specifics
   of such mechanisms are outside the scope of this document.

   Multiple FCIMapData objects with the same capability type are allowed
   within a given CDNI FCI Map response as long as the capability option
   values do not overlap, i.e., a given capability option value MUST NOT
   show up in multiple FCIMapData objects within a single CDNI FCI Map
   response.  If multiple FCIMapData objects for a given capability type
   exist, those capability objects SHOULD have different footprint
   restrictions; capability objects of a given capability type with
   identical footprint restrictions SHOULD be combined into a single
   capability object.

3.1.7.  CDNI FCI Capabilities

3.1.7.1.  Delivery Protocol

   The delivery protocol refers to the protocol over which an end user
   (EU) has requested content.  If a dCDN does not support the protocol




Ma & Seedorf            Expires December 25, 2014               [Page 7]


Internet-Draft                CDNI Metadata                    June 2014


   requested by the client, then the dCDN is not a viable candidate for
   delegation.

   Though the delivery protocol is specified in the URI scheme (as
   defined in RFC3986 [RFC3986]) of the client request URL, protocol
   feature subsets or augmented protocol feature sets MAY be defined and
   SHOULD correspond with the protocols supported by the ProtocolACL
   defined in the CDNI Metadata Interface [I-D.ietf-cdni-metadata]
   document.  The CDNI Metadata Interface document defines the "CDNI
   Metadata Protocols" registry and the initial supported protocol
   values.  It also describes the process for registering additional
   protocols.

   The delivery protocol capability object MUST support a list of
   protocols for a given footprint.  The delivery protocol capability
   SHOULD support optional footprint restriction information.  The
   following example shows two lists of protocols with different
   footprints.

































Ma & Seedorf            Expires December 25, 2014               [Page 8]


Internet-Draft                CDNI Metadata                    June 2014


      GET /fcimap HTTP/1.1
      Host: alto.example.com
      Accept: application/alto-fcimap+json,application/alto-error+json

      HTTP/1.1 200 OK
      Content-Length: 439
      Content-Type: application/alto-fcimap+json
      {
        "meta" : {
        },
        "fcimap": [
          { "name": "delivery_protocol",
            "values": [
              "HTTP",
              "RTSP",
              "MMS"
            ]
          },
          { "name": "delivery_protocol",
            "values": [
              "RTMP",
              "HTTPS"
            ],
            "footprint": [
              { "type": "IPv4CIDR",
                "values": [
                  "10.1.0.0/16",
                  "10.10.10.0/24"
                ]
              }
            ]
          }
        ]
      }

   In the above example, the three protocols HTTP, RTSP, and MMS are
   supported globally, while the protocols RTMP and HTTPS are only
   supported in a restricted footprint (in this case, specified by IP-
   prefix).

   A given protocol MUST NOT appear in multiple FCIMapData object value
   lists.

   [Ed. need to add reference to registry where the protocol values are
   defined, once they are finalized in the semantics/metadata draft.]






Ma & Seedorf            Expires December 25, 2014               [Page 9]


Internet-Draft                CDNI Metadata                    June 2014


3.1.7.2.  Acquisition Protocol

   The acquisition protocol refers to the protocol over which the dCDN
   may acquire content from the uCDN.  If a dCDN does not support any of
   the protocols offered by the uCDN, then the dCDN is not a viable
   candidate for delegation.

   Though the acquisition protocol is disseminated to the dCDN in the
   URI scheme (as defined in RFC3986 [RFC3986]) of the URL provided by
   the uCDN via the CDNI Metadata Interface [I-D.ietf-cdni-metadata],
   protocol feature subsets or augmented protocol feature sets MAY be
   defined and SHOULD correspond with the protocols supported by the
   ProtocolACL defined in the CDNI Metadata Interface
   [I-D.ietf-cdni-metadata] document.  The CDNI Metadata Interface
   document defines the "CDNI Metadata Protocols" registry and the
   initial supported protocol values.  It also describes the process for
   registering additional protocols.

   The acquisition protocol capability object MUST support a list of
   protocols for a given footprint.  The acquisition protocol capability
   SHOULD support optional footprint restriction information.  The
   following example shows two lists of protocols with different
   footprints.




























Ma & Seedorf            Expires December 25, 2014              [Page 10]


Internet-Draft                CDNI Metadata                    June 2014


      GET /fcimap HTTP/1.1
      Host: alto.example.com
      Accept: application/alto-fcimap+json,application/alto-error+json

      HTTP/1.1 200 OK
      Content-Length: 406
      Content-Type: application/alto-fcimap+json
      {
        "meta" : {
        },
        "fcimap": [
          { "name": "acquisition_protocol",
            "values": [
              "HTTP",
              "FTP"
            ]
          },
          { "name": "acquisition_protocol",
            "values": [
              "SFTP",
              "HTTPS"
            ],
            "footprint": [
              { "type": "ASN",
                "values": [
                  "0",
                  "65535"
                ],
              }
            ]
          }
        ]
      }

   In the above example, the two protocols HTTP and FTP are supported
   globally, while the protocols SFTP and HTTPS are updated to only be
   supported in a reduced restricted footprint (in this case, specified
   by ASN).

   A given protocol MUST NOT appear in multiple FCIMapData object value
   lists.

   [Ed. need to add reference to registry where the protocol values are
   defined, once they are finalized in the semantics/metadata draft.]







Ma & Seedorf            Expires December 25, 2014              [Page 11]


Internet-Draft                CDNI Metadata                    June 2014


3.1.7.3.  Redirection Mode

   The redirection mode refers to the method(s) employed by request
   routers to perform request redirection.  The CDNI framework
   [I-D.ietf-cdni-framework] document describes four possible request
   routing modes:

   o  DNS iterative (DNS-I)

   o  DNS recursive (DNS-R)

   o  HTTP iterative (HTTP-I)

   o  HTTP recursive (HTTP-R)

   The CDNI Footprint and Capabilities Semantics
   [I-D.ietf-cdni-footprint-capabilities-semantics] defines the "CDNI
   Capabilities Redirection Modes" registry and the initial supported
   redirection mode values shown in parentheses above.  It also
   describes the process for registering additional redirection modes.

   If a dCDN supports only a specific mode or subset of modes that does
   not overlap with the modes supported by the uCDN, then the dCDN is
   not a viable candidate for delegation.

   The redirection mode capability object MUST support a list of
   redirection modes for a given footprint.  The redirection mode
   capability SHOULD support optional footprint restriction information.
   The following XML-encoded example shows two lists of modes with
   different footprints.





















Ma & Seedorf            Expires December 25, 2014              [Page 12]


Internet-Draft                CDNI Metadata                    June 2014


      GET /fcimap HTTP/1.1
      Host: alto.example.com
      Accept: application/alto-fcimap+json,application/alto-error+json

      HTTP/1.1 200 OK
      Content-Length: 488
      Content-Type: application/alto-fcimap+json
      {
        "meta" : {
        },
        "fcimap": [
          { "name": "redirection_mode",
            "values": [
              "DNS-I",
              "HTTP-I"
            ]
          },
          { "name": "redirection_mode",
            "values": [
              "DNS-R",
              "HTTP-R"
            ],
            "footprint": [
              { "type": "ASN",
                "values": [
                  "9"
                ],
              },
              { "type": "IPv6CIDR",
                "values": [
                  "8765:4321::/36"
                ]
              }
            ]
          }
        ]
      }

   In the above example, iterative redirection is supported globally,
   while recursive redirection is only supported in a restricted
   footprint (in this case, specified by both ASN and IP-prefix).

   A given mode MUST NOT appear in multiple FCIMapData object value
   lists.







Ma & Seedorf            Expires December 25, 2014              [Page 13]


Internet-Draft                CDNI Metadata                    June 2014


3.1.7.4.  Logging Capabilities

   The CDNI Logging interface [I-D.ietf-cdni-logging] document describes
   optional logging fields and functionality which may be optional for a
   dCDN to implement.  If a dCDN does not support certain logging
   parameters which may affect billing agreements or legal requirements
   of the uCDN, then the dCDN is not a viable candidate for delegation.

   [Ed. need to update this section once the list of logging
   capabilities is finalized in the semantics/logging draft.]

3.1.7.5.  Metadata Capabilities

   The CDNI Metadata interface [I-D.ietf-cdni-metadata] document
   describes generic metadata types which may be optional for a dCDN to
   implement, but which, if present, are mandatory-to-enforce.  If a
   dCDN does not support certain metadata types which are designated
   mandatory-to-enforce and may affect the correctness or security of
   the content being delivered, then the dCDN is not a viable candidate
   for delegation.

   [Ed. need to update this section once the list of metadata
   capabilities is finalized in the semantics/metadata draft.]

3.1.8.  Example

      GET /fcimap HTTP/1.1
      Host: alto.example.com
      Accept: application/alto-fcimap+json,application/alto-error+json

      HTTP/1.1 200 OK
      Content-Length: 1137
      Content-Type: application/alto-fcimap+json
      {
        "meta" : {
        },
        "fcimap": [
          { "name": "delivery_protocol",
            "values": [
              "HTTP",
              "RTSP",
              "MMS"
            ]
          },
          { "name": "delivery_protocol",
            "values": [
              "RTMP",
              "HTTPS"



Ma & Seedorf            Expires December 25, 2014              [Page 14]


Internet-Draft                CDNI Metadata                    June 2014


            ],
            "footprint": [
              { "type": "IPv4CIDR",
                "values": [
                  "10.1.0.0/16",
                  "10.10.10.0/24"
                ]
              }
            ]
          }
          { "name": "acquisition_protocol",
            "values": [
              "HTTP",
              "FTP"
            ]
          },
          { "name": "acquisition_protocol",
            "values": [
              "SFTP",
              "HTTPS"
            ],
            "footprint": [
              { "type": "ASN",
                "values": [
                  "0",
                  "65535"
                ],
              }
            ]
          }
          { "name": "redirection_mode",
            "values": [
              "DNS-R",
              "HTTP-R"
            ],
            "footprint": [
              { "type": "ASN",
                "values": [
                  "9"
                ],
              },
              { "type": "IPv6CIDR",
                "values": [
                  "8765:4321::/36"
                ]
              }
            ]
          }



Ma & Seedorf            Expires December 25, 2014              [Page 15]


Internet-Draft                CDNI Metadata                    June 2014


        ]
      }

4.  CDNI FCI Capabilities Filtering Service

4.1.  Filtered CDNI FCI Map

4.1.1.  Media Type

   Since a Filtered CDNI FCI Map is still a CDNI FCI Map, it uses the
   media type defined for CDNI FCI Map (see Section 3.1.1).

4.1.2.  HTTP Method

   A Filtered CDNI FCI Map is requested using the HTTP POST method.

4.1.3.  Accept Input Parameters

   TBD.

4.1.4.  Capabilities

   None.

4.1.5.  Uses

   TBD.

4.1.6.  Response

   The format is the same as unfiltered CDNI FCI Map (see
   Section 3.1.6).

4.1.7.  Example

   TBD.

5.  IANA Considerations

   This document requests the registration of two new media types:

               +-------------+-----------------------------+
               | Type        | Subtype                     |
               +-------------+-----------------------------+
               | application | alto-cdni-fcimap+json       |
               | application | alto-cdni-fcimapfilter+json |
               +-------------+-----------------------------+




Ma & Seedorf            Expires December 25, 2014              [Page 16]


Internet-Draft                CDNI Metadata                    June 2014


6.  Security Considerations

   There are a number of security concerns associated with the FCI.  The
   FCI essentially provides configuration information which the uCDN
   uses to make request routing decisions.  Injection of fake capability
   advertisement messages or the interception and discard of real
   capability advertisement messages may be used for denial of service
   (e.g., by falsely advertising or deleting capabilities or preventing
   capability advertisements from reaching the uCDN).  dCDN capability
   advertisements MUST be authenticated by the uCDN to prevent
   unauthorized capability injection.  uCDN FCI servers MUST be
   authenticated by the dCDN to prevent unauthorized interception of
   ALTO messages.  TLS with client authentication SHOULD be used for all
   FCI implementations.  Deployments in controlled environments where
   physical security and IP address white-listing is employed MAY choose
   not to use TLS.

7.  Acknowledgements

   The authors would like to thank Jon Peterson, Ray van Brandenburg,
   Gilles Bertrand, and Scott Wainner for their timely reviews and
   invaluable comments.

8.  References

8.1.  Normative References

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

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66, RFC
              3986, January 2005.

8.2.  Informative References

   [I-D.ietf-alto-protocol]
              Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", draft-
              ietf-alto-protocol-27 (work in progress), March 2014.

   [I-D.ietf-cdni-footprint-capabilities-semantics]
              Seedorf, J., Peterson, J., Previdi, S., Brandenburg, R.,
              and K. Ma, "CDNI Request Routing: Footprint and
              Capabilities Semantics", draft-ietf-cdni-footprint-
              capabilities-semantics-02 (work in progress), February
              2014.





Ma & Seedorf            Expires December 25, 2014              [Page 17]


Internet-Draft                CDNI Metadata                    June 2014


   [I-D.ietf-cdni-framework]
              Peterson, L., Davie, B., and R. Brandenburg, "Framework
              for CDN Interconnection", draft-ietf-cdni-framework-14
              (work in progress), June 2014.

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

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

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

Appendix A.  Capability Aggregation

   The following sections show examples of three aggregation scenarios.
   In each case, CDN-U is the ultimate uCDN and CDN-P is the penultimate
   CDN which must perform capabilities aggregation.

A.1.  Downstream CDN Aggregation

   Figure A1 shows five organizationally different CDNs: CDN-U, CDN-P,
   and CDNS A, B, and C, the dCDNs of CDN-P which are being aggregated.
   Given the setup shown in Figure A1, we can construct a number of use
   cases, based on the coverage areas of each dCDN (i.e., CDNs P, A, B,
   and C).  Note: In all cases, the reachability of the uCDN (i.e., CDN-
   U) is a don't care as it is assumed that the uCDN knows its own
   coverage area and is likely to favor itself in most situations, and
   if it has decided that it needs to delegate to a dCDN, then the only
   relevant question is if the dCDN can handle the request.














Ma & Seedorf            Expires December 25, 2014              [Page 18]


Internet-Draft                CDNI Metadata                    June 2014


                               ,---,---,---.
                            ,-'             `-.
                           ( rr0.u.example.com )
                            `-.    CDN-U    ,-'
                               `---'-+-'- --'
                                     |
                               ,---,-+-,---.
                            ,-'             `-.
                           ( rr0.p.example.com )
                            `-.    CDN-P    ,-'
                               `---'-+-'---'
                                     |
               +---------------------+---------------------+
              /                      |                      \
       ,---,-+-,---.           ,---,-+-,---.           ,---,-+-,---.
    ,-'             `-.     ,-'             `-.     ,-'             `-.
   ( rr0.a.example.com )   ( rr0.b.example.com )   ( rr0.c.example.com )
    `-.    CDN-A    ,-'     `-.    CDN-B    ,-'     `-.    CDN-C    ,-'
       `---'---'---'           `---'---'---'           `---'---'---'

              Figure A1: CDNI dCDN Request Router Aggregation

   o  None of the four dCDNs (CDNs P, A, B, and C) have global
      reachability.  In this case, each CDN is likely to advertise
      footprint information with its capabilities, specifying its
      reachability.  When CDN-P advertises capabilities to CDN-U, it may
      advertise the aggregate footprint of itself and CDNs A, B, and C.
      Note: CDN-P MAY exclude any dCDN, and consequently its footprint,
      per its own internal aggregation decision criteria.

   o  All four dCDNs (CDNs P, A, B, and C) have global reachability.  In
      this case, none of the CDNs is likely to advertise any footprint
      information as none have any footprint restrictions.  When CDN-P
      advertises capabilities to CDN-U, the aggregate of all global
      reachability is global reachability.

   o  Some of the four dCDNs (CDNs P, A, B, and C) have global
      reachability and some do not.  In this case, even though some
      dCDNs do not have global reachability, the aggregate of some dCDNs
      having global reachability and some not should still be global
      reachability (for the given capability).  When CDN-P advertises
      capabilities to CDN-U, CDN-P may advertise capabilities for which
      at least one dCDN has global reach as being supported with global
      reachability.  It is up to the CDN-P request router to properly
      select a dCDN to process individual client requests and not choose
      a dCDN whose restricted footprint makes it unsuitable for
      delivering the requested content.




Ma & Seedorf            Expires December 25, 2014              [Page 19]


Internet-Draft                CDNI Metadata                    June 2014


A.2.  Internal Request Router Aggregation

   Figure A2 shows CDN-U and CDN-P where CDN-P internally has four
   request routers: the authoritative request router rr0, and three
   other request routers rr1, rr2, and rr3.  The use of multiple request
   routers may be used to distribute request routing load across
   resources, possibly in different geographic regions covered by CDN-P.
   Similar to Figure A1, the setup shown in Figure A2 requires the
   authoritative request router rr0 in CDN-P to aggregate capabilities
   information from downstream request routers rr1, rr2, and rr3.  The
   primary difference between the scenario is that the request routers
   in Figure A2 are logically within the same CDN-P organization.  The
   same reachability scenarios apply to Figure A2 as with Figure A1.

                               ,---,---,---.
                            ,-'             `-.
                           ( rr0.u.example.com )
                            `-.    CDN-U    ,-'
                               `---'-+-'---'
                                     |
                    ,---,---,---,--,-+-,--,---,---,---.
                   (                                   )
                 ,-'       +-------------------+       `-.
                (          | rr0.p.example.com |          )
              ,-'          +---------+---------+          `-.
             (                       |                       )
           ,-'            +----------+----------+            `-.
          (              /           |           \              )
           )  +---------+---------+  |  +---------+---------+  (
          (   | rr1.p.example.com |  |  | rr3.p.example.com |   )
           `. +-------------------+  |  +-------------------+ ,'
            (                        |                        )
             `-.           +---------+---------+           ,-'
               (           | rr2.p.example.com |           )
                `-.        +-------------------+        ,-'
                  (                CDN-P                )
                   `---'---'---'---'---'---'---'---'---'

              Figure A2: Local CDN Request Router Aggregation

   o  None of the four CDN-P request routers have global reachability.
      In this case, each request router is likely to advertise footprint
      information with its capabilities, specifying its reachability.
      When rr0 advertises capabilities to CDN-U, it may advertise the
      aggregate footprint of itself and rr1, rr2, and rr3.

   o  All four CDN-P request routers have global reachability.  In this
      case, none of the request routers is likely to advertise any



Ma & Seedorf            Expires December 25, 2014              [Page 20]


Internet-Draft                CDNI Metadata                    June 2014


      footprint information as none has any footprint restrictions.
      When rr0 advertises capabilities to CDN-U, the aggregate of all
      global reachability is global reachability.

   o  Some of the four CDN-P request routers have global reachability
      and some do not.  In this case, even though some request routers
      do not have global reachability, the aggregate of some request
      routers having global reachability and some not should still be
      global reachability (for the given capability).  When rr0
      advertises capabilities to CDN-U, CDN-P may advertise capabilities
      for which at least one request router has global reach as being
      supported with global reachability.  It is up to the authoritative
      request router rr0 to properly select from the other request
      routers for any given request, and not choose a request router
      whose restricted footprint makes it unsuitable for delivering the
      requested content.

A.3.  Internal Capability Aggregation

   Figure A3 shows CDN-U and CDN-P where the delivery network of CDN-P
   is segregated by delivery protocol (e.g., RTSP, HTTP, and RTMP).
   Figure A3 differs from Figures A1 and A2 in that request router rr0
   of CDN-P is not aggregating the capabilities advertisements of
   multiple other downstream request routers, but rather it is managing
   the disparate capabilities across resources within its own local CDN.
   Though not every delivery node has the same protocol capabilities,
   the aggregate delivery protocol capabilities advertised by CDN-A may
   include all delivery protocols.  Note, Figure A3 should not be
   construed to imply anything about the coverage areas for each
   delivery protocol.  They may all support the same delivery footprint,
   or they may have different delivery footprints.  It is the
   responsibility of the request router rr0 to properly assign protocol-
   appropriate delivery nodes to individual content requests.  If
   certain protocols have limited reachability, CDN-P may advertise
   footprint restrictions for each protocol.

   It should be noted that though the delivery protocol capability was
   selected for this example, the concept of internal capability
   aggregation applies to all capabilities as discussed below.












Ma & Seedorf            Expires December 25, 2014              [Page 21]


Internet-Draft                CDNI Metadata                    June 2014


                               ,---,---,---.
                            ,-'             `-.
                           ( rr0.u.example.com )
                            `-.    CDN-U    ,-'
                               `---'-+-'---'
                                     |
                    ,---,---,---,--,-+-,--,---,---,---.
                   (                                   )
                 ,-'       +-------------------+       `-.
                (          | rr0.p.example.com |          )
              ,-'          +---------+---------+          `-.
             (                       .                       )
           ,-'            .......................            `-.
          (              .           .           .              )
           )  +-------------------+  .  +-------------------+  (
          (   |rtsp.p.example.com |  .  |rtmp.p.example.com |   )
           `. +-------------------+  .  +-------------------+ ,'
            (                        .                        )
             `-.           +-------------------+           ,-'
               (           |http.p.example.com |           )
                `-.        +-------------------+        ,-'
                  (                CDN-A                )
                   `---'---'---'---'---'---'---'---'---'

                Figure A3: Local CDN Capability Segregation

   Another situation in which physical footprint may not matter in an
   aggregated view has to do with feature support (e.g., new CDNI
   metadata features or new redirection modes).  Situations often arise
   when phased roll-out of software upgrades, or staging network
   segregation result in only certain portions of a CDN's resources
   supporting the new feature set.  The dCDN has a few options in this
   case:

   o  Enforce atomic update: The dCDN does not advertise support for the
      new capability until all resources have been upgraded to support
      the new capability.

   o  Transparent segregation: The dCDN advertises support for the new
      capability, and when requests are received that require the new
      capability, the dCDN request router properly selects a resource
      which supports that capability.

   o  Advertised segregation: The dCDN advertises support for the new
      capability with a footprint restriction allowing the uCDN to make
      delegation decisions based on the dCDN's limit support.





Ma & Seedorf            Expires December 25, 2014              [Page 22]


Internet-Draft                CDNI Metadata                    June 2014


   The level of aggregation employed by the dCDN is likely to vary as
   business relationships dictate, however, the FCI should support all
   possible modes of operation.

Authors' Addresses

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

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


   Jan Seedorf
   NEC
   Kurfuerstenanlage 36
   Heidelberg  69115
   Germany

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


























Ma & Seedorf            Expires December 25, 2014              [Page 23]