Skip to main content

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

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Kevin J. Ma , Jan Seedorf
Last updated 2016-04-14
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ma-cdni-capabilities-08
Network Working Group                                              K. Ma
Internet-Draft                                                  Ericsson
Intended status: Standards Track                              J. Seedorf
Expires: October 16, 2016                                            NEC
                                                          April 14, 2016

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

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 October 16, 2016.

Ma & Seedorf            Expires October 16, 2016                [Page 1]
Internet-Draft                  CDNI FCI                      April 2016

Copyright Notice

   Copyright (c) 2016 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  . . . . . . . . . . .   5
   3.  CDNI FCI Capabilities Service . . . . . . . . . . . . . . . .   5
     3.1.  CDNI FCI Map  . . . . . . . . . . . . . . . . . . . . . .   5
       3.1.1.  Media Type  . . . . . . . . . . . . . . . . . . . . .   6
       3.1.2.  HTTP Method . . . . . . . . . . . . . . . . . . . . .   6
       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  . . . . . . . . . . . . . .   9
         3.1.7.3.  Redirection Mode  . . . . . . . . . . . . . . . .  11
         3.1.7.4.  Logging Capabilities  . . . . . . . . . . . . . .  13
         3.1.7.5.  Metadata Capabilities . . . . . . . . . . . . . .  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 . . . . . . . . . . . . . . . . . . . . . . .  17
   5.  Footprint via ALTO Network Map  . . . . . . . . . . . . . . .  17
     5.1.  ALTO Network Maps . . . . . . . . . . . . . . . . . . . .  17
     5.2.  Example ALTO Network Map for CDNI FCI Footprint . . . . .  17
     5.3.  Example of ALTO Network Map Footprint in FCI Map  . . . .  18

Ma & Seedorf            Expires October 16, 2016                [Page 2]
Internet-Draft                  CDNI FCI                      April 2016

   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
     6.1.  ALTO Media Types  . . . . . . . . . . . . . . . . . . . .  20
       6.1.1.  ALTO CDNI FCI Map Media Type  . . . . . . . . . . . .  20
       6.1.2.  ALTO CDNI FCI Map Filter Media Type . . . . . . . . .  21
     6.2.  CDNI Payload Types  . . . . . . . . . . . . . . . . . . .  23
       6.2.1.  CDNI FCI Logging Payload Type . . . . . . . . . . . .  23
       6.2.2.  CDNI FCI Metadata Payload Type  . . . . . . . . . . .  23
     6.3.  CDNI Footprint Types  . . . . . . . . . . . . . . . . . .  23
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  24
     7.1.  Securing the CDNI Footprint & Capabilities Advertisement
           interface . . . . . . . . . . . . . . . . . . . . . . . .  24
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  25
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  25
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  25
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  26
   Appendix A.  Capability Aggregation . . . . . . . . . . . . . . .  27
     A.1.  Downstream CDN Aggregation  . . . . . . . . . . . . . . .  27
     A.2.  Internal Request Router Aggregation . . . . . . . . . . .  28
     A.3.  Internal Capability Aggregation . . . . . . . . . . . . .  30
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  32

1.  Introduction

   The need for footprint and capabilities advertisement in Content
   Distribution Network Interconnection (CDNI) is described in the CDNI
   requirements document [RFC7337].  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.

Ma & Seedorf            Expires October 16, 2016                [Page 3]
Internet-Draft                  CDNI FCI                      April 2016

   It is assumed that an authoritative request router in each CDN will
   be responsible for aggregating and advertising capabilities
   information in a dCDN and/or receiving and aggregating capabilities
   information in the uCDN.  The CDNI Footprint & Capabilities
   Advertisement interface (FCI) along with the CDNI Request Routing
   Redirection interface (RI) [I-D.ietf-cdni-redirection] 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 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
   [I-D.ietf-cdni-footprint-capabilities-semantics].  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 [RFC7336] document.

2.  CDNI FCI Capability Advertisement

   The FCI is implemented as an ALTO [RFC7285] 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

Ma & Seedorf            Expires October 16, 2016                [Page 4]
Internet-Draft                  CDNI FCI                      April 2016

   separate FCI Filter Service 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 a 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
   information to initialize its capabilities database.  In either case,
   the uCDN SHOULD verify the initial state of the dCDN (as a temporary
   outage may affect availability in the dCDN).

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

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.  [I-D.ietf-cdni-footprint-capabilities-semantics] 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 protocol
   [RFC7285].

3.1.  CDNI FCI Map

Ma & Seedorf            Expires October 16, 2016                [Page 5]
Internet-Draft                  CDNI FCI                      April 2016

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.

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 {
         FCICapability capabilities<1..*>;
      } FCIMapData;

      object {
         JSONString capability-type;
         JSONValue capability-value
         FCIFootprint footprints<0..*>;
      } FCICapability;

      object {
         JSONString footprint-type;
         JSONString footprint-value<1..*>;
      } FCIFootprint;

   The FCIMapData object contains a CDNI Payload Type [RFC7736] "ptype"
   which identifies the capability and a "value" object containing the
   associated Capability Advertisement Object (e.g., delivery-protocols,
   acquisition-protocols, or redirection-modes, as defined in

Ma & Seedorf            Expires October 16, 2016                [Page 6]
Internet-Draft                  CDNI FCI                      April 2016

   [I-D.ietf-cdni-footprint-capabilities-semantics]).  The FCIMapData
   object may also contain an optional list of FCIFootprint objects
   "footprints".  The FCIFootprint object specifies a "footprint-type"
   (as defined by the CDNI Metadata Footprint Types registry, e.g.,
   ipv4cidr, ipv6cidr, asn, or countrycode [I-D.ietf-cdni-metadata])
   which identifies the contents and encoding of the individual
   footprint entries contained in the associated "footprint-value"
   array.

   The "footprints" list MUST NOT contain multiple FCIFootprint 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 necessary for 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
   footprint-value 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 MUST have different
   footprint restrictions.  Capability objects of a given capability
   type with identical footprint restrictions MUST 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
   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]) of the client request URL, protocol feature
   subsets or augmented protocol feature sets MAY be defined and SHOULD
   correspond with the protocols listed in the CDNI Metadata Protocol
   Types registry, e.g., http1.1 or https1.1 [I-D.ietf-cdni-metadata].

Ma & Seedorf            Expires October 16, 2016                [Page 7]
Internet-Draft                  CDNI FCI                      April 2016

   The following example shows two lists of delivery protocols with
   different footprints.

      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: 627
      Content-Type: application/alto-fcimap+json
      {
        "meta" : {
        },
        "fcimap": {
          "capabilities": [
            { "capability-type": "FCI.DeliveryProtocol"
              "capability-value": {
                "delivery-protocols": [
                  "http1.1"
                ]
              }
            },
            { "capability-type": "FCI.DeliveryProtocol"
              "capability-value": {
                "delivery-protocols": [
                  "https1.1"
                ]
              },
              "footprints": [
                { "footprint-type": "ipv4cidr",
                  "footprint-value": [
                    "10.1.0.0/16",
                    "10.10.10.0/24"
                  ]
                }
              ]
            }
          ]
        }
      }

   In the above example, the HTTP/1.1 protocol is supported globally,
   while the HTTP/1.1 over TLS protocol is only supported in a
   restricted footprint (in this case, specified by IPv4 prefix).

   A given protocol MUST NOT appear in multiple FCIMapData
   FCI.DeliveryProtocol object values.

Ma & Seedorf            Expires October 16, 2016                [Page 8]
Internet-Draft                  CDNI FCI                      April 2016

3.1.7.2.  Acquisition Protocol

   The acquisition protocol refers to the protocol over which an end
   user (EU) has requested content.  If a dCDN does not support the
   protocol requested by the client, then the dCDN is not a viable
   candidate for delegation.

   Though the acquisition protocol is specified in the URI scheme (as
   defined in [RFC3986]) of the client request URL, protocol feature
   subsets or augmented protocol feature sets MAY be defined and SHOULD
   correspond with the protocols listed in the CDNI Metadata Protocol
   Types registry, e.g., http1.1 or https1.1 [I-D.ietf-cdni-metadata].

   The following example shows two lists of acquisition protocols with
   different footprints.

Ma & Seedorf            Expires October 16, 2016                [Page 9]
Internet-Draft                  CDNI FCI                      April 2016

      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: 620
      Content-Type: application/alto-fcimap+json
      {
        "meta" : {
        },
        "fcimap": {
          "capabilities": [
            { "capability-type": "FCI.AcquisitionProtocol"
              "capability-value": {
                "acquisition-protocols": [
                  "http1.1"
                ]
              }
            },
            { "capability-type": "FCI.AcquisitionProtocol"
              "capability-value": {
                "acquisition-protocols": [
                  "https1.1"
                ]
              },
              "footprints": [
                { "footprint-type": "asn",
                  "footprint-value": [
                    "AS0",
                    "AS65535"
                  ]
                }
              ]
            }
          ]
        }
      }

   In the above example, the HTTP/1.1 protocol is supported globally,
   while the HTTP/1.1 over TLS protocol is only supported in a
   restricted footprint (in this case, specified by Autonomous System
   number).

   A given protocol MUST NOT appear in multiple FCIMapData
   FCI.AcquisitionProtocol value objects.

Ma & Seedorf            Expires October 16, 2016               [Page 10]
Internet-Draft                  CDNI FCI                      April 2016

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 [RFC7336]
   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)

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

   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 might
   not be a viable candidate for delegation.

   The following example shows two lists of redirection modes with
   different footprints.

Ma & Seedorf            Expires October 16, 2016               [Page 11]
Internet-Draft                  CDNI FCI                      April 2016

      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: 767
      Content-Type: application/alto-fcimap+json

      {
        "meta" : {
        },
        "fcimap": {
          "capabilities": [
            { "capability-type": "FCI.RedirectionMode",
              "capability-value": {
                "redirection-modes": [
                  "DNS-I",
                  "HTTP-I"
                ]
              }
            },
            { "capability-type": "FCI.RedirectionMode",
              "capability-value": {
                "redirection-modes": [
                  "DNS-R",
                  "HTTP-R"
                ]
              },
              "footprints": [
                { "footprint-type": "countrycode",
                  "footprint-value": [
                    "SE"
                  ]
                },
                { "footprint-type": "ipv6cidr",
                  "footprint-value": [
                    "9876:5432::1/36"
                  ]
                }
              ]
            }
          ]
        }
      }

   In the above example, iterative redirection is supported globally,
   while recursive redirection is only supported in a restricted

Ma & Seedorf            Expires October 16, 2016               [Page 12]
Internet-Draft                  CDNI FCI                      April 2016

   footprint (in this case, specified by both Country Code and IPv6
   prefix).

   A given mode MUST NOT appear in multiple FCIMapData
   FCI.RedirectionMode object values.

3.1.7.4.  Logging Capabilities

   [I-D.ietf-cdni-logging] describes the "cdni_http_request_v1" logging
   record-types and optional vs. mandatory-to-implement logging fields
   for that record-type.  It also allows new logging record-types and
   logging fields to be defined which would 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.

3.1.7.4.1.  CDNI Logging Capability Object

   The CDNI Logging capability object is used to indicate support for
   CDNI Logging record-types, as well as CDNI Logging fields which are
   marked as optional for the specified record-types
   [I-D.ietf-cdni-logging].

      Property: record-type

         Description: Supported CDNI Logging record-type.

         Type: String corresponding to an entry from the CDNI Logging
         record-types registry [I-D.ietf-cdni-logging])

         Mandatory-to-Specify: Yes.

      Property: fields

         Description: List of supported CDNI Logging fields that are
         optional for the specified record-type.

         Type: List of Strings corresponding to entries from the CDNI
         Logging Field Names registry [I-D.ietf-cdni-logging].

         Mandatory-to-Specify: No.  Default is that all optional fields
         are supported.  Inclusion of an empty list SHALL be understood
         to mean that none of the optional fields are supported.
         Otherwise, only those optional fields that are listed SHALL be
         understood to be supported.

Ma & Seedorf            Expires October 16, 2016               [Page 13]
Internet-Draft                  CDNI FCI                      April 2016

3.1.7.4.2.  CDNI Logging Capability Object Serialization

   The following shows an example of CDNI Logging Capability Object
   Serialization, for a CDN that supports the optional Content
   Collection ID logging field (but not the optional Session ID logging
   field) for the "cdni_http_request_v1" record type.

   {
     "capabilities": [
       {
         "capability-type": "FCI.Logging",
         "capability-value": {
           "record-type": "cdni_http_request_v1",
           "fields": [ "s-ccid" ]
         },
         "footprints": [
           <Footprint objects>
         ]
       }
     ]
   }

   The next example shows the CDNI Logging Capability Object
   Serialization, for a CDN that supports all optional fields for the
   "cdni_http_request_v1" record type.

   {
     "capabilities": [
       {
         "capability-type": "FCI.Logging",
         "capability-value": {
           "record-type": "cdni_http_request_v1"
         },
         "footprints": [
           <Footprint objects>
         ]
       }
     ]
   }

3.1.7.5.  Metadata Capabilities

   [I-D.ietf-cdni-metadata] describes GenericMetadata types which may be
   optional for a dCDN to implement, but which, if present, are
   mandatory-to-enforce.  It also allows for new GenericMetadata to be
   defined which would be optional for a dCDN to implement.

Ma & Seedorf            Expires October 16, 2016               [Page 14]
Internet-Draft                  CDNI FCI                      April 2016

   If a dCDN does not support certain GenericMetadata 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.

3.1.7.5.1.  CDNI Metadata Capability Object

   The CDNI Metadata capability object is used to indicate support for
   CDNI GenericMetadata types [I-D.ietf-cdni-metadata].

      Property: metadata

         Description: List of supported CDNI GenericMetadata types.

         Type: List of Strings corresponding to entries from the CDNI
         Payload Type registry [RFC7736]) that correspond to CDNI
         GenericMetadata objects.

         Mandatory-to-Specify: Yes.  It SHALL be understood that only
         those GenericMetadata types listed are supported; an empty list
         SHALL be understood to mean that only structural metadata and
         simple types are supported [I-D.ietf-cdni-metadata].

3.1.7.5.2.  CDNI Metadata Capability Object Serialization

   The following shows an example of CDNI Metadata Capability Object
   Serialization, for a CDN that supports only the SourceMetadata
   GenericMetadata type (i.e., it can acquire and deliver content, but
   cannot enforce and security policies, e.g., time, location, or
   protocol ACLs).

   {
     "capabilities": [
       {
         "capability-type": "FCI.Metadata",
         "capability-value": {
           "metadata": ["MI.SourceMetadata"]
         },
         "footprints": [
           <Footprint objects>
         ]
       }
     ]
   }

   The next example shows the CDNI Metadata Capability Object
   Serialization, for a CDN that supports only structural metadata

Ma & Seedorf            Expires October 16, 2016               [Page 15]
Internet-Draft                  CDNI FCI                      April 2016

   (i.e., it can parse metadata as a transit CDN, but cannot enforce
   security policies or deliver content).

   {
     "capabilities": [
       {
         "capability-type": "FCI.Metadata",
         "capability-value": {
           "metadata": []
         },
         "footprints": [
           <Footprint objects>
         ]
       }
     ]
   }

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

Ma & Seedorf            Expires October 16, 2016               [Page 16]
Internet-Draft                  CDNI FCI                      April 2016

4.1.7.  Example

   TBD.

5.  Footprint via ALTO Network Map

5.1.  ALTO Network Maps

   The ALTO Protocol offers an information service "ALTO map service"
   that provides information to ALTO clients in the form of Network Map
   and Cost Map [RFC7285].  As an alternative to the explicit definition
   of a CDNI Footprint Type (e.g., ipv4cidr, ipv6cidr, as, countrycode),
   a reference to an ALTO network map can be used to define an FCI
   footprint.  To enable such referencing to ALTO network maps, a new
   CDNI Footprint Type "altonetworkmap" is defined (see also
   Section 6.3).

   The first altonetworkmap entry must be a URI for accessing the ALTO
   server that hosts the ALTO network map (as defined in the ALTO
   protocol specification [RFC7285]).  All subsequent altonetworkmap
   entries must be of type PIDName (as defined in [RFC7285], where the
   PIDName corresponds to a PID in the ALTO network map referenced by
   the preceding URI.  Parsing and processing of an ALTO network map
   follows the ALTO protocol specification [RFC7285].

5.2.  Example ALTO Network Map for CDNI FCI Footprint

   An ALTO client can retrieve a network map of media type 'application/
   alto-networkmap+json' under a given URI (e.g.,
   'http://alto.example.com/fcifootprint001') with a GET request for a
   network map as specified in the ALTO protocol [RFC7285].  The
   following network map would convey to a uCDN that the given dCDN
   (which would provide the map) has three footprints called "south-
   france" and "germany", and provides the corresponding IPv4 address
   ranges for these footprints.

Ma & Seedorf            Expires October 16, 2016               [Page 17]
Internet-Draft                  CDNI FCI                      April 2016

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

    HTTP/1.1 200 OK
    Content-Length: 319
    Content-Type: application/alto-networkmap+json

    {
      "meta" : {
        "vtag": [
          {"resource-id": "my-eu-netmap",
           "tag": "1266506139"
          }
        ]
      },
      "network-map" : {
        "south-france" : {
          "ipv4" : [ "192.0.2.0/24", "198.51.100.0/25" ]
        },
        "germany" : {
          "ipv4" : [ "192.0.3.0/24"]
        }
      }
    }

5.3.  Example of ALTO Network Map Footprint in FCI Map

   To reference an ALTO network map as an FCI footprint, set the
   footprint-type to "altonetworkmap", and set the first entry in the
   footprint-value to the URI of the ALTO server hosting the network
   map, followed by a list of PID names contained in the network map.

   The following example shows two lists of delivery protocols (see
   Section 3.1.7.1), with the second having an ALTO network map
   footprint.

Ma & Seedorf            Expires October 16, 2016               [Page 18]
Internet-Draft                  CDNI FCI                      April 2016

      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: 618
      Content-Type: application/alto-fcimap+json

      {
        "meta" : {
        },
        "fcimap": {
          "capabilities": [
            { "capability-type": "FCI.DeliveryProtocol",
              "capability-value": [
                "http1.1"
              ]
            },
            { "capability-type": "FCI.DeliveryProtocol",
              "capability-value": [
              "values": [
                "https1.1"
              ],
              "footprints": [
                { "footprint-type": "altonetworkmap",
                  "footprint-value": [
                    "http://alto.example.com/fcifootprint001",
                    "germany",
                    "south-france"
                  ]
                }
              ]
            }
          ]
        }
      }

   In the above example, the HTTP/1.1 protocol is supported globally,
   while the HTTP/1.1 over TLS protocol is only supported in a
   restricted footprint (in this case, specified by an ALTO network map
   for Germany and Southern France).

6.  IANA Considerations

Ma & Seedorf            Expires October 16, 2016               [Page 19]
Internet-Draft                  CDNI FCI                      April 2016

6.1.  ALTO Media Types

   This document requests the registration of the following media types:

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

6.1.1.  ALTO CDNI FCI Map Media Type

   Type name: application

   Subtype name: alto-cdni-fcimap+json

   Required parameters: none

   Optional parameters: none

   Encoding considerations:

      Encoding considerations are identical to those specified for the
      "application/json" media type.  See [RFC7159].

   Security considerations:

      Security considerations relating to the generation and consumption
      of ALTO Protocol messages are discussed in Section 15 of
      [RFC7285].  Additional security considerations for the CDNI
      Footprint & Capabilities Advertisement interface are discussed in
      Section 7.

   Interoperability considerations:

      [RFC7285] and RFCthis specify the format of conforming messages
      and the interpretation thereof.  [RFC Editor: Please replace
      RFCthis with the published RFC number for this document.]

   Published specification: RFCthis [RFC Editor: Please replace RFCthis
   with the published RFC number for this document.]

   Applications that use this media type:

      ALTO servers and ALTO clients either stand alone or are embedded
      within other applications.

Ma & Seedorf            Expires October 16, 2016               [Page 20]
Internet-Draft                  CDNI FCI                      April 2016

   Fragment identifier considerations: N/A

   Additional information: N/A

      Deprecated alias names for this type: N/A

      Magic number(s): N/A

      File extension(s): N/A

      Macintosh file type code(s): N/A

   Person & email address to contact for further information:

      Kevin Ma <kevin.j.ma@ericsson.com>

   Intended usage: LIMITED USE

   Restrictions on usage:

      This media type is intended only for use in CDNI Footprint &
      Capabilities Advertisement interface protocol message exchanges.

   Author: IETF CDNI working group

   Change controller: IETF CDNI working group

   Provisional registration: no

6.1.2.  ALTO CDNI FCI Map Filter Media Type

   Type name: application

   Subtype name: alto-cdni-fcimapfilter+json

   Required parameters: none

   Optional parameters: none

   Encoding considerations:

      Encoding considerations are identical to those specified for the
      "application/json" media type.  See [RFC7159].

   Security considerations:

      Security considerations relating to the generation and consumption
      of ALTO Protocol messages are discussed in Section 15 of

Ma & Seedorf            Expires October 16, 2016               [Page 21]
Internet-Draft                  CDNI FCI                      April 2016

      [RFC7285].  Additional security considerations for the CDNI
      Footprint & Capabilities Advertisement interface are discussed in
      Section 7.

   Interoperability considerations:

      [RFC7285] and RFCthis specify the format of conforming messages
      and the interpretation thereof.  [RFC Editor: Please replace
      RFCthis with the published RFC number for this document.]

   Published specification: RFCthis [RFC Editor: Please replace RFCthis
   with the published RFC number for this document.]

   Applications that use this media type:

      ALTO servers and ALTO clients either stand alone or are embedded
      within other applications.

   Fragment identifier considerations: N/A

   Additional information: N/A

      Deprecated alias names for this type: N/A

      Magic number(s): N/A

      File extension(s): N/A

      Macintosh file type code(s): N/A

   Person & email address to contact for further information:

      Kevin Ma <kevin.j.ma@ericsson.com>

   Intended usage: LIMITED USE

   Restrictions on usage:

      This media type is intended only for use in CDNI Footprint &
      Capabilities Advertisement interface protocol message exchanges.

   Author: IETF CDNI working group

   Change controller: IETF CDNI working group

   Provisional registration: no

Ma & Seedorf            Expires October 16, 2016               [Page 22]
Internet-Draft                  CDNI FCI                      April 2016

6.2.  CDNI Payload Types

   This document requests the registration of the following CDNI Payload
   Types under the IANA CDNI Payload Type registry:

                     +--------------+---------------+
                     | Payload Type | Specification |
                     +--------------+---------------+
                     | FCI.Logging  | RFCthis       |
                     | FCI.Metadata | RFCthis       |
                     +--------------+---------------+

   [RFC Editor: Please replace RFCthis with the published RFC number for
   this document.]

6.2.1.  CDNI FCI Logging Payload Type

   Purpose: The purpose of this payload type is to distinguish FCI
   advertisement objects for supported CDNI Logging record-types and
   optional CDNI Logging Field Names.

   Interface: FCI

   Encoding: see Section 3.1.7.4.1 and Section 3.1.7.4.2

6.2.2.  CDNI FCI Metadata Payload Type

   Purpose: The purpose of this payload type is to distinguish FCI
   advertisement objects for supported CDNI GenericMetadata types.

   Interface: FCI

   Encoding: see Section 3.1.7.5.1 and Section 3.1.7.5.2

6.3.  CDNI Footprint Types

   This document requests the following addition to the "CDNI Metadata
   Footprint Types" registry:

   +----------------+----------------------------------+---------------+
   | Footprint Type | Description                      | Specification |
   +----------------+----------------------------------+---------------+
   | altonetworkmap | URI of an ALTO Server hosting an | RFCthis       |
   |                | ALTO network map, followed by a  |               |
   |                | list of PID-names                |               |
   +----------------+----------------------------------+---------------+

Ma & Seedorf            Expires October 16, 2016               [Page 23]
Internet-Draft                  CDNI FCI                      April 2016

   [RFC Editor: Please replace RFCthis with the published RFC number for
   this document.]

7.  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).  FCI messages may
   also be monitored to detect when CDN performance degrades or outages
   occur.  Such information may be considered private by the dCDN.

   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.  Encryption MUST be used to ensure confidentiality of
   the dCDN's private messages.

7.1.  Securing the CDNI Footprint & Capabilities Advertisement interface

   An implementation of the CDNI Footprint & Capabilities Advertisement
   interface MUST support TLS transport as per [RFC2818] and [RFC7230].
   The use of TLS for transport of the CDNI metadata interface messages
   allows:

   o  The dCDN and uCDN to authenticate each other.

   and, once they have mutually authenticated each other, it allows:

   o  The dCDN and uCDN to authorize each other (to ensure they are
      transmitting/receiving CDNI FCI messages from an authorized CDN);

   o  CDNI FCI messages to be transmitted with confidentiality; and

   o  The integrity of the CDNI FCI messages to be protected during the
      exchange.

   In an environment where any such protection is required, TLS MUST be
   used (including authentication of the remote end) by the server-side
   (uCDN) and the client-side (dCDN) of the CDNI Footprint &
   Capabilities Advertisement interface unless alternate methods are
   used for ensuring the confidentiality of the information in the CDNI
   FCI messages (such as setting up an IPsec tunnel between the two CDNs
   or using a physically secured internal network between two CDNs that
   are owned by the same corporate entity).

Ma & Seedorf            Expires October 16, 2016               [Page 24]
Internet-Draft                  CDNI FCI                      April 2016

   When TLS is used, the general TLS usage guidance in [RFC7525] MUST be
   followed.

8.  Acknowledgements

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

   Jan Seedorf is partially supported by the GreenICN project (GreenICN:
   Architecture and Applications of Green Information Centric
   Networking), a research project supported jointly by the European
   Commission under its 7th Framework Program (contract no. 608518) and
   the National Institute of Information and Communications Technology
   (NICT) in Japan (contract no. 167).  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 GreenICN project,
   the European Commission, or NICT.

9.  References

9.1.  Normative References

   [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-16 (work in progress), April 2016.

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

   [I-D.ietf-cdni-metadata]
              Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma,
              "CDN Interconnection Metadata", draft-ietf-cdni-
              metadata-15 (work in progress), April 2016.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

Ma & Seedorf            Expires October 16, 2016               [Page 25]
Internet-Draft                  CDNI FCI                      April 2016

   [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Message Syntax and Routing",
              RFC 7230, DOI 10.17487/RFC7230, June 2014,
              <http://www.rfc-editor.org/info/rfc7230>.

   [RFC7285]  Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S.,
              Previdi, S., Roome, W., Shalunov, S., and R. Woundy,
              "Application-Layer Traffic Optimization (ALTO) Protocol",
              RFC 7285, DOI 10.17487/RFC7285, September 2014,
              <http://www.rfc-editor.org/info/rfc7285>.

   [RFC7525]  Sheffer, Y., Holz, R., and P. Saint-Andre,
              "Recommendations for Secure Use of Transport Layer
              Security (TLS) and Datagram Transport Layer Security
              (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
              2015, <http://www.rfc-editor.org/info/rfc7525>.

9.2.  Informative References

   [I-D.ietf-cdni-redirection]
              Niven-Jenkins, B. and R. Brandenburg, "Request Routing
              Redirection interface for CDN Interconnection", draft-
              ietf-cdni-redirection-17 (work in progress), February
              2016.

   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818,
              DOI 10.17487/RFC2818, May 2000,
              <http://www.rfc-editor.org/info/rfc2818>.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, DOI 10.17487/RFC3986, January 2005,
              <http://www.rfc-editor.org/info/rfc3986>.

   [RFC7159]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
              2014, <http://www.rfc-editor.org/info/rfc7159>.

   [RFC7336]  Peterson, L., Davie, B., and R. van Brandenburg, Ed.,
              "Framework for Content Distribution Network
              Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336,
              August 2014, <http://www.rfc-editor.org/info/rfc7336>.

   [RFC7337]  Leung, K., Ed. and Y. Lee, Ed., "Content Distribution
              Network Interconnection (CDNI) Requirements", RFC 7337,
              DOI 10.17487/RFC7337, August 2014,
              <http://www.rfc-editor.org/info/rfc7337>.

Ma & Seedorf            Expires October 16, 2016               [Page 26]
Internet-Draft                  CDNI FCI                      April 2016

   [RFC7736]  Ma, K., "Content Delivery Network Interconnection (CDNI)
              Media Type Registration", RFC 7736, DOI 10.17487/RFC7736,
              December 2015, <http://www.rfc-editor.org/info/rfc7736>.

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.

                               ,---,---,---.
                            ,-'             `-.
                           ( 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

Ma & Seedorf            Expires October 16, 2016               [Page 27]
Internet-Draft                  CDNI FCI                      April 2016

      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.

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.

Ma & Seedorf            Expires October 16, 2016               [Page 28]
Internet-Draft                  CDNI FCI                      April 2016

                               ,---,---,---.
                            ,-'             `-.
                           ( 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
      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

Ma & Seedorf            Expires October 16, 2016               [Page 29]
Internet-Draft                  CDNI FCI                      April 2016

      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 October 16, 2016               [Page 30]
Internet-Draft                  CDNI FCI                      April 2016

                               ,---,---,---.
                            ,-'             `-.
                           ( 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 October 16, 2016               [Page 31]
Internet-Draft                  CDNI FCI                      April 2016

   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 October 16, 2016               [Page 32]