-------- 
  /        \
  |   CSP  |
  \        /
   --------
       *
       *
       *                         /\
       *                        /  \
   ----------------------      |CDNI|       ----------------------
  /     Upstream CDN     \     |    |      /    Downstream CDN    \
  |      +-------------+ |     | CI |      | +-------------+      |
  |*******   Control   |<======|====|=======>|   Control   *******|
  |*     +------*----*-+ |     |    |      | +-*----*------+     *|
  |*            *    *   |     |    |      |   *    *            *|
  |*     +------*------+ |     | LI |      | +------*------+     *|
  |* *****   Logging   |<======|====|=======>|   Logging   ***** *|
  |* *   +-*-----------+ |     |    |      | +-----------*-+   * *|
  |* *     *         *   |     |    |      |   *         *     * *|
.....*...+-*---------*-+ |     | RI |      | +-*---------*-+...*.*...
. |* *   |             |<======|====|=======>|             |   * *| .
. |* *   | Req-Routing | |     |FCI |      | | Req-Routing |   * *| .
. |* * ***             |<======|====|=======>|             |** * *| .
. |* * * +-------------+.|     |    |      | +-------------+ * * *| .
. |* * *                 .     |    |      |                 * * *| .
. |* * * +-------------+ |.    | MI |      | +-------------+ * * *| .
. |* * * | Distribution|<==.===|====|=======>| Distribution| * * *| .
. |* * * |             | |  .   \  /       | |             | * * *| .
. |* * * |+---------+  | |   .   \/        | |  +---------+| * * *| .
. |* * ***| +---------+| |    ...Request......+---------+ |*** * *| .
. |* *****+-|Surrogate|***********************|Surrogate|-+***** *| .
. |*******  +---------+| |   Acquisition   | |+----------+ *******| .
. |      +-------------+ |                 | +-------*-----+      | .
. \                      /                 \         *            / .
.  ----------------------                   ---------*------------  .
.                                                    *              .
.                                                    * Delivery     .
.                                                    *              .
.                                                 +--*---+          .
...............Request............................| User |..Request..
                                                  | Agent|
                                                  +------+

<==>           interfaces inside the scope of CDNI

**** and ....  interfaces outside the scope of CDNI

Figure 1: CDNI Expanded Model and CDNI Interfaces

3. Generic CDNI Requirements

This section identifies generic requirements independent of the individual CDNI interfaces. Some of those are expected to affect multiple or all interfaces. Management is an important aspect of CDN operation. The fault and performance management is covered in CDNI Logging interface requirements. The other types of management are specific to the CDN provider and not needed for interoperability between CDN providers.

GEN-1

{MED} Wherever possible, the CDNI interfaces should reuse or leverage existing IETF protocols.

GEN-2

{HIGH} The CDNI solution shall not require a change, or an upgrade, to the User Agent to benefit from content delivery through interconnected CDNs.

GEN-3

{HIGH} The CDNI solution shall not require a change, or an upgrade, to the Content Service Provider delivering content through a single CDN, to benefit from content delivery through interconnected CDNs.

GEN-4

{HIGH} The CDNI solution shall not depend on intra-CDN information to be exposed to other CDNs for effective and efficient delivery of the content. Examples of intra-CDN information include surrogate topology, surrogate status, cached content, etc.

GEN-5

{HIGH} The CDNI solution shall support delivery to the user agent based on HTTP [RFC2616]. (Note that while delivery and acquisition "data plane" protocols are out of the CDNI solution scope, the CDNI solution "control plane" protocols are expected to participate in enabling, selecting or facilitating operations of such acquisition and delivery protocols. Hence it is useful to state requirements on the CDNI solution in terms of which acquisition and delivery protocols).

GEN-6

{HIGH} The CDNI solution shall support acquisition across CDNs based on HTTP [RFC2616]. (The note above applies to this requirement too)

GEN-7

{LOW} The CDNI solution may support delivery to the user agent based on protocols other than HTTP.

GEN-8

{LOW} The CDNI solution may support acquisition across CDNs based on protocols other than HTTP.

GEN-9

{MED} The CDNI solution should support cascaded CDN redirection (CDN1 redirects to CDN2 that redirects to CDN3) to an arbitrary number of levels beyond the first level.

GEN-10

{MED} The CDNI solution should support an arbitrary topology of interconnected CDNs (i.e. the topology of interconnected CDNs cannot be restricted to a tree, ring, star, etc.).

GEN-11

{HIGH} The CDNI solution shall prevent looping of any CDNI information exchange.

GEN-12

{HIGH} When making use of third party reference, the CDNI solution shall consider the potential issues associated with the use of various format of third-party references (e.g. NAT or IPv4/IPv6 translation potentially breaking third-party references based on an IP addresses such as URI containing IPv4 or IPv6 address litterals, split DNS situations potentially breaking third-party references based on DNS fully qualified domain names) and wherever possible avoid, minimize or mitigate the associated risks based on the specifics of the environments where the reference is used (e.g. likely or unlikely presence of NAT in the path). In particular, this applies to situations where the CDNI solution needs to construct and convey uniform resource identifiers for directing/redirecting a content request, as well as to situations where the CDNI solution needs to pass on a third party reference (e.g. to identify a User Agent) in order to allow another entity to make a more informed decision (e.g. make a more informed request routing decision by attempting to derive location information from the third party reference).

GEN-13

{HIGH} The CDNI solution shall support HTTP Adaptive Streaming content.

4. CDNI Control Interface Requirements

The primary purpose of the CDNI Control interface (CI) is to initiate the interconnection across CDNs, bootstrap the other CDNI interfaces and trigger actions into the Downstream CDN by the Upstream CDN (such as delete object from caches or trigger pre-positioned content acquisition). The working group attempts to align requirements with the appropriate interface; however, solutions to these requirements may apply to a different interface or another interface in addition to the interface it is associated with.

CI-1

{HIGH} The CDNI Control interface shall allow the Upstream CDN to request that the Downstream CDN, including downstream cascaded CDNs, delete an object or set of objects and/or its CDNI metadata from the CDN surrogates and any storage. Only the object(s) and CDNI metadata that pertain to the requesting Upstream CDN are allowed to be purged.

CI-2

{MED} The CDNI Control interface should allow for multiple content items identified by a Content Collection ID to be purged using a single Content Purge action.

CI-3

{MED} The CDNI Control interface should allow the Upstream CDN to request that the Downstream CDN, including downstream cascaded CDNs, mark an object or set of objects and/or its CDNI metadata as “stale” and revalidate them before they are delivered again.

CI-4

{HIGH} The CDNI Control interface shall allow the Downstream CDN to report on the completion of these actions (by itself, and including downstream cascaded CDNs), in a manner appropriate for the action (e.g. synchronously or asynchronously). The confirmation receipt should include a success or failure indication. The failure indication and the reason are included if the Downstream CDN cannot delete the content in its storage.

CI-5

{MED} The CDNI Control interface should support initiation and control by the Upstream CDN of pre-positioned CDNI metadata acquisition by the Downstream CDN.

CI-6

{MED} The CDNI Control interface should support initiation and control by the Upstream CDN of pre-positioned content acquisition by the Downstream CDN.

CI-7

{LOW} The CDNI Control interface may allow a CDN to establish, update and terminate a CDN interconnection with another CDN whereby one CDN can act as a Downstream CDN for the other CDN (that acts as an Upstream CDN).

CI-8

{LOW} The CDNI Control interface may allow control of the CDNI interfaces between any two CDNs independently for each direction (e.g. For the direction where CDN1 is the Upstream CDN and CDN2 is the Downstream CDN, and for the direction where CDN2 is the Upstream CDN and CDN1 is the Downstream CDN).

CI-9

{LOW} The CDNI Control interface may allow bootstrapping of the Request-Routing interface. For example, this can potentially include:

• negotiation of the Request-Routing method (e.g. DNS vs HTTP, if more than one method is specified)
• discovery of the Request-Routing protocol endpoints
• information necessary to establish secure communication between the Request-Routing protocol endpoints.

CI-10

{LOW} The CDNI Control interface may allow bootstrapping of the CDNI Metadata interface. This information could, for example, include:

• discovery of the CDNI Metadata signaling protocol endpoints
• information necessary to establish secure communication between the CDNI Metadata signaling protocol endpoints.

CI-11

{LOW} The CDNI Control interface may allow bootstrapping of the Content Acquisition interface. This could, for example, include exchange and negotiation of the Content Acquisition methods to be used across the CDNs (e.g. HTTP, HTTPS, FTP, ATIS C2[ATIS-0800042]).

CI-12

{LOW} The CDNI Control interface may allow bootstrapping of the CDNI Logging interface. This information could, for example, include:

• discovery of the Logging protocol endpoints
• information necessary to establish secure communication between the Logging protocol endpoints
• negotiation/definition of the log file format and set of fields to be exported through the Logging protocol, with some granularity (e.g. On a per content type basis).
• negotiation/definition of parameters related to transaction Logs export (e.g., export protocol, file compression, export frequency, directory).

5. CDNI Request Routing Redirection Interface Requirements

The main function of the CDNI Request Routing Redirection interface (RI) is to allow the Request-Routing systems in interconnected CDNs to communicate to facilitate redirection of the request across CDNs.

RI-1

{HIGH} The CDNI Request Routing Redirection interface shall support efficient request-routing for small objects. This may, for example, call for a mode of operation (e.g. DNS-based request routing) where freshness and accuracy of CDN/Surrogate selection can be traded-off against reduced request-routing load (e.g. Via lighter-weight queries and caching of request-routing decisions).

RI-2

{HIGH} The CDNI Request Routing Redirection interface shall support efficient request-routing for large objects. This may, for example, call for a mode of operation (e.g. HTTP-based request routing) where freshness and accuracy of CDN/Surrogate selection justifies a per-request decision and a per-request CDNI Request-Routing protocol call.

RI-3

{HIGH} The CDNI Request Routing Redirection interface shall support recursive CDNI request routing.

RI-4

{HIGH} The CDNI Request Routing Redirection interface shall support iterative CDNI request routing.

RI-5

{MED} In case of detection of a request redirection loop, the CDNI Request Routing Redirection Interface's loop prevention mechanism should allow redirection of the request on an alternate CDN path (as opposed to the request not being redirected at all).

RI-6

{MED} The CDNI Request Routing Redirection interface should support a mechanism allowing enforcement of a limit on the number of successive CDN redirections for a given request.

RI-7

{LOW} The CDNI Request Routing Redirection interface may support a mechanism allowing an Upstream CDN to avoid redirecting a request to a Downstream CDN if that is likely to result in the total redirection time exceeding some limit.

RI-8

{HIGH} The CDNI Request Routing Redirection interface shall allow the Upstream CDN to include, in the query to the Downstream CDN, the necessary information to allow the Downstream CDN to process the redirection query. This could, for example, include:

• information from which the location of the user-agent that originated the request can be inferred (e.g. User Agent fully qualified domain name in case of HTTP-based Request Routing, DNS Proxy fully qualified domain name in case of DNS-based Request Routing)
• requested resource information (e.g. Resource URI in case of HTTP-based Request Routing, Resource hostname in case of DNS-based Request Routing)
• additional available request information (e.g. request headers in case of HTTP-based Request Routing).

RI-9

{LOW} The CDNI Request Routing Redirection interface may also allow the Upstream CDN to convey information pointing to CDNI metadata applicable (individually or through inheritance) to the requested content. For illustration, the CDNI metadata pointed to could potentially include metadata that is applicable to any content, metadata that is applicable to a content collection (to which the requested content belongs) and/or metadata that is applicable individually to the requested content.

RI-10

{HIGH} The CDNI Request Routing Redirection interface shall allow the Downstream CDN to include the following information in the response to the Upstream CDN:

• status code, in particular indicating acceptance or rejection of request (e.g. Because the Downstream CDN is unwilling or unable to serve the request). In case of rejection, an error code is also to be provided, which allows the Upstream CDN to react appropriately (e.g. Select another Downstream CDN, or serve the request itself)
• redirection information (e.g. Resource URI in case of HTTP-based Request Routing, equivalent of a DNS record in case of DNS-based Request Routing).

RI-11

{HIGH} The CDNI Request Routing Redirection interface shall allow for per-chunk request routing of HTTP Adaptive Streaming content.

RI-12

{LOW} The CDNI Request Routing Redirection interface may allow the Upstream CDN to use the information conveyed by the Downstream CDN during the Recursive Request Routing process to rewrite an HTTP Adaptive Streaming manifest file.

RI-13

{LOW} The CDNI Request-Routing interface may allow the Upstream CDN to re-sign the invariant portion of the chunk URIs embedded in the HTTP Adaptive Streaming manifest file.

RI-14

{MED} The CDNI Request Routing Redirection interface should allow the use of HTTP cookie to associate the chunks with the HTTP Adaptive Stream manifest file (which is verified by the URI signature) based on the Authorization Group ID (which is an identifier used to correlate the manifest file to the related chunks).

RI-15

{MED} The CDNI Request Routing Redirection interface should allow for an efficient method of transferring request routing information for multiple chunks from the Downstream CDN to the Upstream CDN as part of the recursive request routing process.

6. CDNI Footprint & Capabilities Advertisement Interface Requirements

The main function of the CDNI Footprint & Capabilities Advertisement interface (FCI) is to allow the Downstream CDN to advertise the information regarding its footprint and capabilities to the Upstream CDN.

FCI-1

{HIGH} The CDNI Footprint & Capabilities Advertisement interface shall allow the Downstream CDN to communicate to the Upstream CDN coarse information about the Downstream CDN ability and/or willingness to handle requests from the Upstream CDN. For example, this could potentially include a binary signal (“Downstream CDN ready/not-ready to take additional requests from Upstream CDN”) to be used in case of excessive load or failure condition in the Downstream CDN.

FCI-2

{MED} The CDNI Footprint & Capabilities Advertisement interface should allow the Downstream CDN to communicate to the Upstream CDN aggregate information to facilitate CDN selection during request routing, such as Downstream CDN capabilities, resources and affinities (i.e. Preferences or cost). This information could, for example, include:

• supported content types and delivery protocols
• footprint (e.g. layer-3 coverage)
• a set of metrics/attributes (e.g. Streaming bandwidth, storage resources, distribution and delivery priority)
• a set of affinities (e.g. Preferences, indication of distribution/delivery fees)
• information to facilitate request redirection (e.g. Reachability information of Downstream CDN Request Routing system).

[Note: Some of this information - such as supported content types and delivery protocols- may also potentially be taken into account by the distribution system in the Upstream CDN for pre-positioning of content and/or metadata in the Downstream CDN in case of pre-positioned content acquisition and/or pre-positioned CDNI metadata acquisition.]

FCI-3

{MED} In the case of cascaded redirection, the CDNI Footprint & Capabilities Advertisement interface should allow the Downstream CDN to also include in the information communicated to the Upstream CDN, information on the capabilities, resources and affinities of CDNs to which the Downstream CDN may (in turn) redirect requests received by the Upstream CDN. In that case, the CDNI Request-Routing interface shall prevent looping of such information exchange.

FCI-4

{LOW} The CDNI Footprint & Capabilities Advertisement interface may allow the Downstream CDN to communicate to the Upstream CDN aggregate information on CDNI administrative limits and policy. This information can be taken into account by the Upstream CDN Request Routing system in its CDN Selection decisions. This information could, for example, include:

• maximum number of requests redirected by the Upstream CDN to be served simultaneously by the Downstream CDN
• maximum aggregate volume of content (e.g. in Terabytes) to be delivered by the Downstream CDN over a time period.

FCI-5

{MED} The CDNI Footprint & Capabilities Advertisement interface should support advertisement of the following types of capabilities:

• delivery protocol (e.g., HTTP vs. RTMP)
• acquisition protocol (for acquiring content from an Upstream CDN)
• redirection mode (e.g., DNS Redirection vs. HTTP Redirection)
• capabilities related to CDNI Logging (e.g., supported logging mechanisms)
• capabilities related to CDNI Metadata (e.g., authorization algorithms or support for proprietary vendor metadata)

FCI-6

{LOW} The CDNI Control interface may allow exchange and negotiation of delivery authorization mechanisms to be supported across the CDNs (e.g. URI signature based validation).

7. CDNI Metadata Interface Requirements

The primary function of the CDNI Metadata interface (MI) is to allow the Distribution system in interconnected CDNs to communicate to ensure Content Distribution Metadata with inter-CDN scope can be exchanged across CDNs. We observe that while the CDNI Metadata Distribution protocol is currently discussed as a single "protocol", further analysis will determine whether the corresponding requirements are to be realized over a single interface and protocol, or over multiple interfaces and protocols. For example, a subset of the CDNI metadata might be conveyed in-band along with the actual content acquisition across CDNs (e.g. content MD5 in HTTP header) while another subset might require an out-of-band interface & protocol (e.g. geo-blocking information).

MI-1

{HIGH} The CDNI Metadata interface shall allow the Upstream CDN to provide the Downstream CDN with content distribution metadata of inter-CDN scope.

MI-2

{HIGH} The CDNI Metadata interface shall support exchange of CDNI metadata for both the dynamic content acquisition model and the pre-positioning content acquisition model.

MI-3

{HIGH} The CDNI Metadata interface shall support a mode where no, or a subset of, the Metadata is initially communicated to the Downstream CDN along with information about how/where to acquire the rest of the CDNI Metadata (i.e. Dynamic CDNI metadata acquisition).

MI-4

{MED} The CDNI Metadata interface should support a mode where all the relevant Metadata is initially communicated to the Downstream CDN (i.e. Pre-positioned CDNI metadata acquisition).

MI-5

{HIGH} Whether in the pre-positioned content acquisition model or in the dynamic content acquisition model, the CDNI Metadata interface shall provide the necessary information to allow the Downstream CDN to acquire the content from an upstream source (e.g. Acquisition protocol and Uniform Resource Identifier in Upstream CDN- or rules to construct this URI).

MI-6

{HIGH} The CDNI metadata shall allow signaling of one or more upstream sources, where each upstream source can be in the Upstream CDN, in another CDN, the CSP origin server or any arbitrary source designated by the Upstream CDN. Note that some upstream sources (e.g. the content origin server) may or may not be willing to serve the content to the Downstream CDN, if this policy is known to the Upstream CDN then it may omit those sources when exchanging CDNI metadata.

MI-7

{HIGH} The CDNI Metadata interface (possibly in conjunction with the CDNI Control interface) shall allow the Upstream CDN to request addition and modification of CDNI Metadata into the Downstream CDN.

MI-8

{HIGH} The CDNI Metadata interface (possibly in conjunction with the CDNI Control interface) shall allow removal of obsolete CDNI Metadata from the Downstream CDN (this could, for example, be achieved via an explicit removal request from the Upstream CDN or via expiration of a Time-To-Live associated to the Metadata).

MI-9

{HIGH} The CDNI Metadata interface shall allow association of CDNI Metadata at the granularity of individual object. This is necessary to achieve fine-grain Metadata distribution at the level of an individual object when necessary.

MI-10

{HIGH} The CDNI Metadata interface shall allow association of CDNI Metadata at the granularity of an object set. This is necessary to achieve scalable distribution of metadata when a large number of objects share the same distribution policy.

MI-11

{HIGH} The CDNI Metadata interface shall support multiple levels of inheritance with precedence to more specific metadata. For example, the CDNI Metadata Distribution protocol may support metadata that is applicable to any content, metadata that is applicable to a content collection and metadata that is applicable to an individual content where content level metadata overrides content collection metadata that overrides metadata for any content.

MI-12

{HIGH} The CDNI Metadata interface shall ensure that conflicting metadata with overlapping scope are prevented or deterministically handled.

MI-13

{HIGH} The CDNI Metadata interface shall allow signaling of content distribution control policies. For example, this could potentially include:

• geo-blocking information (i.e. Information defining geographical areas where the content is to be made available or blocked)
• availability windows (i.e. Information defining time windows during which the content is to be made available or blocked; expiration time may also be included to remove content)
• delegation whitelist/blacklist (i.e. Information defining which Downstream CDNs the content may/may not be delivered through)

MI-14

{HIGH} The CDNI Metadata interface shall be able to exchange a set of metadata elements with specified semantics (e.g. start of time window, end of time window).

MI-15

{HIGH} The CDNI Metadata interface shall allow exchange of opaque metadata element, whose semantic is not defined in CDNI but established by private CDN agreement.

MI-16

{HIGH} The CDNI Metadata interface shall allow signaling of authorization checks and validation that are to be performed by the surrogate before delivery. For example, this could potentially including the need to validate URI signed information (e.g. Expiry time, Client IP address).

MI-17

{MED} The CDNI Metadata interface should allow signaling of CDNI-relevant surrogate cache behavior parameters. For example, this could potentially include:

• control of whether the query string of HTTP URI is to be ignored by surrogate cache
• enforcement of caching directives by Downstream CDN that are different than the ones signalled in the HTTP headers (e.g. "Expires" field)
• rate-pacing by Downstream CDN for content delivery (e.g. Progressive Download)

MI-18

{HIGH} The CDNI Metadata interface shall provide indication of related content (e.g. HTTP Adaptive Bit Rate chunks) by the Content Collection ID (CCID) metadata. This could be used by the Downstream CDN for operations on the group of content. For example, this could potentially include:

• content acquisition for the entire set of files when one piece of content is requested
• local file management and storage bundles all the files for the content
• purging the entire set of files associated with the content
• logging of the delivery of the content for the session when at least one file in the set was delivered

MI-19

{MED} The CDNI Metadata interface should support an optional mechanism allowing the Upstream CDN to indicate to the Downstream CDN which CDNI Log fields are to be provided for all content items, for specific sets of content items, or for specific content items delivered using HTTP. A CDNI implementation that does not support this optional CDNI Metadata Distribution interface mechanism shall ignore this log format indication and generate CDNI logging format for HTTP Adaptive Streaming using the default set of CDNI Logging fields. (Note: This function may be part of the CDNI Metadata interface or the CDNI Control interface.)

MI-20

{MED} The CDNI Metadata interface should allow the Upstream CDN to signal to the Downstream CDN the Content Collection ID value for all, for specific sets of, or for specific content items delivered using HTTP. Whenever the Downstream CDN is instructed by the Upstream CDN to report the Content Collection ID field in the log records, the Downstream CDN is to use the value provided through the CDNI Metadata interface for the corresponding content. Note the Session ID field along with Content Collection ID may be used for HTTP Adaptive Streaming content.

MI-21

{MED} The CDNI Metadata interface should allow the Upstream CDN to signal to the Downstream CDN the Authorization Group ID value for all the related HTTP Adaptive Streaming content (i.e. manifest file and chunks). The authorization result of a content (e.g. manifest file) is transferred over to related content (e.g. chunks).

8. CDNI Logging Interface Requirements

This section identifies the requirements related to the CDNI Logging interface (LI). We observe that while the CDNI Logging interface is currently discussed as a single "protocol", further analysis will determine whether the corresponding requirements are to be realized over a single interface and protocol, or over multiple interfaces and protocols.

LI-1

{HIGH} The CDNI logging architecture and interface shall ensure reliable transfer of CDNI logging information across CDNs.

LI-2

{HIGH} The CDNI Logging interface shall provide logging of deliveries and incomplete deliveries to User Agents performed by the Downstream CDN as a result of request redirection by the Upstream CDN.

LI-3

{MED} In the case of cascaded CDNs, the CDNI Logging interface should allow the Downstream CDN to report to the Upstream CDN logging for deliveries and incomplete deliveries performed by the Downstream CDN itself as well as logging for deliveries and incomplete deliveries performed by cascaded CDNs on behalf of the Downstream CDN.

LI-4

{HIGH} The CDNI Logging interface shall support batch/offline exchange of logging records.

LI-5

{MED} The CDNI Logging interface should also support additional timing constraints for some types of logging records (e.g. near-real time for monitoring and analytics applications)

LI-6

{HIGH} The CDNI Logging interface shall define a log file format and a set of fields to be exported for various CDNI logging events.

LI-7

{HIGH} The CDNI Logging interface shall define a transport mechanism to exchange CDNI Logging files.

LI-8

{MED} The CDNI Logging interface should allow a CDN to query another CDN for relevant current logging records (e.g. For on-demand access to real-time logging information).

LI-9

{LOW} The CDNI Logging interface may support aggregate/ summarized logs (e.g. total bytes delivered for a content regardless of individual User Agents to which it was delivered).

LI-10

{LOW} The CDNI Logging interface may support logging of performance data for deliveries to User Agents performed by the Downstream CDN as a result of request redirection by the Upstream CDN. Performance data may include various traffic statistics (the specific parameters are to be determined). The CDNI Logging interface may support the Upstream CDN to indicate the nature and contents of the performance data to be reported by the Downstream CDN.

LI-11

{MED} The CDNI Logging interface should support logging of consumed resources (e.g. storage, bandwidth) to the Upstream CDN for deliveries where content is stored by the Downstream CDN for delivery to User Agents. The information logged may include the type of storage (e.g., Origin, Intermediate, Edge, Cache) as well as the amount of storage (e.g., total GB, GB used, per time period, per content domain) all of which may impact the cost of the services.

LI-12

{MED} In the case of cascaded CDNs, the CDNI Logging interface should support the Downstream CDN to report consumed resources (e.g. storage, bandwidth) to the Upstream CDN where content is stored by the Downstream CDN itself as well as logging for storage resources when content storage is performed by cascaded CDNs on behalf of the Downstream CDN.

LI-13

{HIGH} The CDNI Logging interface shall support logging of deleted objects from the Downstream CDN to the Upstream CDN as a result of explicit delete requests on via the CDNI Control interface from the Upstream CDN.

LI-14

{HIGH} The CDNI Logging interface shall support the exchange of extensible log file formats to support proprietary information fields. These information fields shall be agreed upon ahead of time between the corresponding CDNs.

LI-15

{HIGH} The CDNI Logging interface shall allow a CDN to notify another CDN about which CDNI logging information is available for transfer and/or no longer available (e.g. it exceeded some logging retention period or some logging retention volume).

LI-16

{MED} The CDNI Logging interface should support the ability for the Downstream CDN to include the Content Collection ID and Session ID fields in CDNI log entries generated for HTTP Adaptive Streaming content.

LI-17

{MED} The CDNI Logging interface should provide privacy protection by not disclosing information that can be used to identify the user (e.g. method that anonymize the IP address carried in the logging field). The use of the privacy protection mechanism is optional.

9. CDNI Security Requirements

This section identifies the requirements related to the CDNI security. Some of these are expected to affect multiple or all protocols.

SEC-1

{HIGH} All the CDNI interface shall support secure operation over unsecured IP connectivity (e.g. The Internet). This includes authentication, confidentiality, integrity protection as well as protection against spoofing and replay.

SEC-2

{HIGH} The CDNI solution shall provide sufficient protection against Denial of Service attacks. This includes protection against spoofed delivery requests sent by user agents directly to a Downstream CDN attempting to appear as if they had been redirected by a given Upstream CDN when they have not.

SEC-3

{MED} The CDNI solution should be able to ensure that for any given request redirected to a Downstream CDN, the chain of CDN Delegation (leading to that request being served by that CDN) can be established with non-repudiation.

SEC-4

{MED} The CDNI solution should be able to ensure non-repudiation by the Downstream CDN of transaction logs generated by the Downstream CDN and communicated to an Upstream CDN. This would ensure that the Downstream CDN cannot repudiate transmitted Log records, therefore discouraging the Downstream CDN from spoofing a transaction log (attempting to appear as if it corresponds to a request redirected by the Upstream CDN when that request has not been redirected by this Upstream CDN).

SEC-5

{LOW} The CDNI solution may provide a mechanism allowing an Upstream CDN that has credentials to acquire content from the CSP origin server (or another CDN), to allow establishment of credentials authorizing the Downstream CDN to acquire the content from the CSP origin server (or the other CDN) (e.g. In case the content cannot be acquired from the Upstream CDN).

10. IANA Considerations

This document makes no request of IANA.

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

11. Security Considerations

This document discusses CDNI security requirements in Section 9.

12. Authors

This document reflects the contributions from the following authors:

Francois Le Faucheur

Cisco Systems

flefauch@cisco.com

Mahesh Viveganandhan

Cisco Systems

mvittal@cisco.com

Grant Watson

Alcatel-Lucent (Velocix)

gwatson@velocix.com

13. Acknowledgements

This document leverages the earlier work of the IETF CDI working group in particular as documented in [I-D.cain-request-routing-req], [I-D.amini-cdi-distribution-reqs] and [I-D.gilletti-cdnp-aaa-reqs].

The authors would like to thank Gilles Bertrand, Christophe Caillet, Bruce Davie, Phil Eardly, Ben Niven-Jenkins, Agustin Schapira, Emile Stephan, Eric Burger, Susan He, Kevin Ma, Daryl Malas, Iuniana Oprescu, and Spencer Dawkins for their input. Serge Manning along with Robert Streijl, Vishwa Prasad, Percy Tarapore, Mike Geller, and Ramki Krishnan contributed to this document by addressing the requirements of the ATIS Cloud Services Forum.

Ray Brandenburg, Matt Caufield, and Gilles Bertrand provided valuable inputs for HTTP Adaptive Streaming, CDNI Metadata interface, and CDNI Logging interface, respectively.

14. References

14.1. Normative References

[RFC6707]

Niven-Jenkins, B., Le Faucheur, F. and N. Bitar, "Content Distribution Network Interconnection (CDNI) Problem Statement", RFC 6707, September 2012.

14.2. Informative References

, ", "

[RFC2616]	Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC6770]	Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma, K. and G. Watson, "Use Cases for Content Delivery Network Interconnection", RFC 6770, November 2012.
[I-D.ietf-cdni-framework]	Peterson, L. and B. Davie, "Framework for CDN Interconnection", Internet-Draft draft-ietf-cdni-framework-06, October 2013.
[I-D.cain-request-routing-req]	Cain, B., "Request Routing Requirements for Content Internetworking", Internet-Draft draft-cain-request-routing-req-03, November 2001.
[I-D.amini-cdi-distribution-reqs]	Amini, L., "Distribution Requirements for Content Internetworking", Internet-Draft draft-amini-cdi-distribution-reqs-02, November 2001.
[I-D.gilletti-cdnp-aaa-reqs]	CDI AAA Requirements, draft-gilletti-cdnp-aaa-reqs-01.txt", June 2001.
[ATIS-0800042]	ATIS IPTV Content on Demand Service, https://www.atis.org/docstore/product.aspx?id=25670", December 2010.

Authors' Addresses