draft-ietf-cdni-requirements-05.txt   draft-ietf-cdni-requirements-06.txt 
Network Working Group K. Leung, Ed. Network Working Group K. Leung, Ed.
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Informational Y. Lee, Ed. Intended status: Informational Y. Lee, Ed.
Expires: August 27, 2013 Comcast Expires: October 11, 2013 Comcast
February 23, 2013 April 9, 2013
Content Distribution Network Interconnection (CDNI) Requirements Content Distribution Network Interconnection (CDNI) Requirements
draft-ietf-cdni-requirements-05 draft-ietf-cdni-requirements-06
Abstract Abstract
Content Delivery Networks (CDNs) are frequently used for large-scale Content Delivery Networks (CDNs) are frequently used for large-scale
content delivery. As a result, existing CDN providers are scaling up content delivery. As a result, existing CDN providers are scaling up
their infrastructure and many Network Service Providers (NSPs) are their infrastructure and many Network Service Providers (NSPs) are
deploying their own CDNs. There is a requirement for interconnecting deploying their own CDNs. There is a requirement for interconnecting
standalone CDNs so that their collective CDN footprint can be standalone CDNs so that their collective CDN footprint can be
leveraged for the end-to-end delivery of content from Content Service leveraged for the end-to-end delivery of content from Content Service
Providers (CSPs) to end users. The Content Distribution Network Providers (CSPs) to end users. The Content Distribution Network
skipping to change at page 2, line 27 skipping to change at page 2, line 27
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 27, 2013. This Internet-Draft will expire on October 11, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 12 skipping to change at page 3, line 12
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. CDNI Model and CDNI Interfaces . . . . . . . . . . . . . . . . 4 2. CDNI Model and CDNI Interfaces . . . . . . . . . . . . . . . . 4
3. Generic CDNI Requirements . . . . . . . . . . . . . . . . . . 6 3. Generic CDNI Requirements . . . . . . . . . . . . . . . . . . 6
4. CDNI Control Interface Requirements . . . . . . . . . . . . . 7 4. CDNI Control Interface Requirements . . . . . . . . . . . . . 7
5. CDNI Request Routing Interface Requirements . . . . . . . . . 10 5. CDNI Request Routing/Redirection Interface Requirements . . . 10
6. CDNI Metadata Distribution Interface Requirements . . . . . . 14 6. CDNI Request Routing/Footprint & Capabilities
7. CDNI Logging Interface Requirements . . . . . . . . . . . . . 17 Advertisement Interface Requirements . . . . . . . . . . . . . 12
8. CDNI Security Requirements . . . . . . . . . . . . . . . . . . 20 7. CDNI Metadata Distribution Interface Requirements . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 8. CDNI Logging Interface Requirements . . . . . . . . . . . . . 18
10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 9. CDNI Security Requirements . . . . . . . . . . . . . . . . . . 20
11. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 11. Security Considerations . . . . . . . . . . . . . . . . . . . 21
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 12. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
13.1. Normative References . . . . . . . . . . . . . . . . . . . 22 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
13.2. Informative References . . . . . . . . . . . . . . . . . . 22 14. Appendix: Requirements Mapping . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
15.1. Normative References . . . . . . . . . . . . . . . . . . . 23
15.2. Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
The volume of video and multimedia content delivered over the The volume of video and multimedia content delivered over the
Internet is rapidly increasing and expected to continue doing so in Internet is rapidly increasing and expected to continue doing so in
the future. In the face of this growth, Content Delivery Networks the future. In the face of this growth, Content Delivery Networks
(CDNs) provide numerous benefits: reduced delivery cost for cacheable (CDNs) provide numerous benefits: reduced delivery cost for cacheable
content, improved quality of experience for end users, and increased content, improved quality of experience for end users, and increased
robustness of delivery. For these reasons CDNs are frequently used robustness of delivery. For these reasons CDNs are frequently used
for large-scale content delivery. As a result, existing CDN for large-scale content delivery. As a result, existing CDN
skipping to change at page 4, line 29 skipping to change at page 4, line 29
delivering a given content may not expand close enough to the End delivering a given content may not expand close enough to the End
User's current location or attachment network to realize the cost User's current location or attachment network to realize the cost
benefit and user experience that a more distributed CDN would benefit and user experience that a more distributed CDN would
provide. This creates a requirement for interconnecting standalone provide. This creates a requirement for interconnecting standalone
CDNs so that their collective CDN footprint can be leveraged for the CDNs so that their collective CDN footprint can be leveraged for the
end-to-end delivery of content from Content Service Providers (CSPs) end-to-end delivery of content from Content Service Providers (CSPs)
to End Users. The Content Distribution Network Interconnection to End Users. The Content Distribution Network Interconnection
(CDNI) working group has been chartered to develop an interoperable (CDNI) working group has been chartered to develop an interoperable
and scalable solution for such CDN interconnection. and scalable solution for such CDN interconnection.
[I-D.ietf-cdni-problem-statement] outlines the problem area that the [RFC6707] outlines the problem area that the CDNI working group is
CDNI working group is chartered to address. chartered to address. [RFC6770] discusses the use cases for CDN
[I-D.ietf-cdni-use-cases] discusses the use cases for CDN
Interconnection. [I-D.davie-cdni-framework] discusses the technology Interconnection. [I-D.davie-cdni-framework] discusses the technology
framework for the CDNI solution and interfaces. framework for the CDNI solution and interfaces.
The goal of the present document is to document the requirements for The goal of the present document is to document the requirements for
the CDNI solution and interfaces. In order to meet the timelines the CDNI solution and interfaces. In order to meet the timelines
defined in the working group charter, the present document defined in the working group charter, the present document
categorizes the CDNI requirements as "High Priority", "Medium categorizes the CDNI requirements as "High Priority", "Medium
Priority", and "Low Priority". Priority", and "Low Priority".
1.1. Terminology 1.1. Terminology
skipping to change at page 6, line 22 skipping to change at page 6, line 22
leverage existing IETF protocols. leverage existing IETF protocols.
GEN-2 [HIGH] The CDNI solution shall not require a change, or an GEN-2 [HIGH] The CDNI solution shall not require a change, or an
upgrade, to the User Agent to benefit from content delivery upgrade, to the User Agent to benefit from content delivery
through interconnected CDNs. through interconnected CDNs.
GEN-3 [HIGH] The CDNI solution shall not require a change, or an GEN-3 [HIGH] The CDNI solution shall not require a change, or an
upgrade, to the Content Service Provider to benefit from upgrade, to the Content Service Provider to benefit from
content delivery through interconnected CDNs. content delivery through interconnected CDNs.
GEN-4 [HIGH] The CDNI solution shall not require intra-CDN GEN-4 [HIGH] The CDNI solution shall not depend on intra-CDN
information to be exposed to other CDNs for effective and information to be exposed to other CDNs for effective and
efficient delivery of the content. Examples of intra-CDN efficient delivery of the content. Examples of intra-CDN
information include surrogate topology, surrogate status, information include surrogate topology, surrogate status,
cached content, etc. cached content, etc.
GEN-5 [HIGH] The CDNI solution shall support delivery to the user GEN-5 [HIGH] The CDNI solution shall support delivery to the user
agent based on HTTP [RFC2616]. (Note that while delivery and agent based on HTTP [RFC2616]. (Note that while delivery and
acquisition "data plane" protocols are out of the CDNI acquisition "data plane" protocols are out of the CDNI
solution scope, the CDNI solution "control plane" protocols solution scope, the CDNI solution "control plane" protocols
are expected to participate in enabling, selecting or are expected to participate in enabling, selecting or
facilitating operations of such acquisition and delivery facilitating operations of such acquisition and delivery
protocols. Hence it is useful to state requirements on the protocols. Hence it is useful to state requirements on the
CDNI solution in terms of which acquisition and delivery CDNI solution in terms of which acquisition and delivery
protocols). protocols).
GEN-6 [HIGH] The CDNI solution shall support acquisition across GEN-6 [HIGH] The CDNI solution shall support acquisition across
CDNs based on HTTP [RFC2616]. 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 GEN-7 [LOW] The CDNI solution may support delivery to the user
agent based on protocols other than HTTP. agent based on protocols other than HTTP.
GEN-8 [LOW] The CDNI solution may support acquisition across CDNs GEN-8 [LOW] The CDNI solution may support acquisition across CDNs
based on protocols other than HTTP. based on protocols other than HTTP.
GEN-9 [MED] The CDNI solution should support cascaded CDN GEN-9 [MED] The CDNI solution should support cascaded CDN
redirection (CDN1 redirects to CDN2 that redirects to CDN3) redirection (CDN1 redirects to CDN2 that redirects to CDN3)
to an arbitrary number of levels beyond the first level. to an arbitrary number of levels beyond the first level.
skipping to change at page 7, line 33 skipping to change at page 7, line 33
particular, this applies to situations where the CDNI particular, this applies to situations where the CDNI
solution needs to construct and convey uniform resource solution needs to construct and convey uniform resource
identifiers for directing/redirecting a content request, as identifiers for directing/redirecting a content request, as
well as to situations where the CDNI solution needs to pass well as to situations where the CDNI solution needs to pass
on a third party reference (e.g. to identify a User Agent) in on a third party reference (e.g. to identify a User Agent) in
order to allow another entity to make a more informed order to allow another entity to make a more informed
decision (e.g. make a more informed request routing decision decision (e.g. make a more informed request routing decision
by attempting to derive location information from the third by attempting to derive location information from the third
party reference). party reference).
GEN-13 Removed. GEN-13 [HIGH] The CDNI solution shall support HTTP Adaptive
GEN-14 [HIGH] The CDNI solution shall support HTTP Adaptive
Streaming content. Streaming content.
4. CDNI Control Interface Requirements 4. CDNI Control Interface Requirements
The primary purpose of the CDNI Control interface is to initiate the The primary purpose of the CDNI Control interface (CI) is to initiate
interconnection across CDNs, bootstrap the other CDNI interfaces and the interconnection across CDNs, bootstrap the other CDNI interfaces
trigger actions into the Downstream CDN by the Upstream CDN (such as and trigger actions into the Downstream CDN by the Upstream CDN (such
delete object from caches or trigger pre-positioned content as delete object from caches or trigger pre-positioned content
acquisition). We observe that while the CDNI Control interface is acquisition). We observe that while the CDNI Control interface is
currently discussed as a single "protocol", further analysis will currently discussed as a single "protocol", further analysis will
determine whether the corresponding requirements are to be realized determine whether the corresponding requirements are to be realized
over a single interface and protocol, or over multiple interfaces and over a single interface and protocol, or over multiple interfaces and
protocols. protocols.
CNTL-1 [HIGH] The CDNI Control interface shall allow the Upstream CI-1 [HIGH] The CDNI Control interface shall allow the Upstream CDN
CDN to request that the Downstream CDN (and, if cascaded to request that the Downstream CDN (and, if cascaded CDNs are
CDNs are supported by the solution, that the potential supported by the solution, that the potential cascaded
cascaded Downstream CDNs) perform the following actions on Downstream CDNs) delete an object or set of objects and/or its
an object or object set: 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.
* Mark an object or set of objects and/or its CDNI CI-2 [MED] The CDNI Control interface should allow for multiple
metadata as "stale" and revalidate them before they are content items identified by a Content Collection ID to be
delivered again purged using a single Content Purge action.
* Delete an object or set of objects and/or its CDNI CI-3 [MED] The CDNI Control interface should allow the Upstream CDN
metadata from the CDN surrogates and any storage. Only to request that the Downstream CDN (and, if cascaded CDNs are
the object(s) and CDNI metadata that pertain to the supported by the solution, that the potential cascaded
requesting Upstream CDN are allowed to be purged. Downstream CDNs) mark an object or set of objects and/or its
CDNI metadata as "stale" and revalidate them before they are
delivered again.
CNTL-2 [HIGH] The CDNI Control interface shall allow the Downstream CI-4 [HIGH] The CDNI Control interface shall allow the Downstream
CDN to report on the completion of these actions (by itself, CDN to report on the completion of these actions (by itself,
and if cascaded CDNs are supported by the solution, by and if cascaded CDNs are supported by the solution, by
potential cascaded Downstream CDNs), in a manner appropriate potential cascaded Downstream CDNs), in a manner appropriate
for the action (e.g. synchronously or asynchronously). The for the action (e.g. synchronously or asynchronously). The
confirmation receipt should include a success or failure confirmation receipt should include a success or failure
indication. The failure indication is used if the indication. The failure indication is used if the Downstream
Downstream CDN cannot delete the content in its storage. CDN cannot delete the content in its storage.
CNTL-3 [HIGH] The CDNI Control interface shall support initiation CI-5 [MED] The CDNI Control interface should support initiation and
and control by the Upstream CDN of pre-positioned CDNI control by the Upstream CDN of pre-positioned CDNI metadata
metadata acquisition by the Downstream CDN. acquisition by the Downstream CDN.
CNTL-4 [MED] The CDNI Control interface should support initiation CI-6 [MED] The CDNI Control interface should support initiation and
and control by the Upstream CDN of pre-positioned content control by the Upstream CDN of pre-positioned content
acquisition by the Downstream CDN. acquisition by the Downstream CDN.
CNTL-5 [LOW] The CDNI Control interface may allow a CDN to CI-7 [LOW] The CDNI Control interface may allow a CDN to establish,
establish, update and terminate a CDN interconnection with update and terminate a CDN interconnection with another CDN
another CDN whereby one CDN can act as a Downstream CDN for whereby one CDN can act as a Downstream CDN for the other CDN
the other CDN (that acts as an Upstream CDN). (that acts as an Upstream CDN).
CNTL-6 [LOW] The CDNI Control interface may allow control of the CI-8 [LOW] The CDNI Control interface may allow control of the CDNI
CDNI interconnection between any two CDNs independently for interconnection between any two CDNs independently for each
each direction (i.e. For the direction where CDN1 is the direction (i.e. For the direction where CDN1 is the Upstream
Upstream CDN and CDN2 is the Downstream CDN, and for the CDN and CDN2 is the Downstream CDN, and for the direction
direction where CDN2 is the Upstream CDN and CDN1 is the where CDN2 is the Upstream CDN and CDN1 is the Downstream
Downstream CDN). CDN).
CNTL-7 [LOW] The CDNI Control interface may allow bootstrapping of CI-9 [LOW] The CDNI Control interface may allow bootstrapping of
the Request-Routing interface. For example, this can the Request-Routing interface. For example, this can
potentially include: potentially include:
* negotiation of the Request-Routing method (e.g. DNS vs * negotiation of the Request-Routing method (e.g. DNS vs
HTTP, if more than one method is specified) HTTP, if more than one method is specified)
* discovery of the Request-Routing protocol endpoints * discovery of the Request-Routing protocol endpoints
* information necessary to establish secure communication * information necessary to establish secure communication
between the Request-Routing protocol endpoints. between the Request-Routing protocol endpoints.
CNTL-8 [LOW] The CDNI Control interface may allow bootstrapping of CI-10 [LOW] The CDNI Control interface may allow bootstrapping of
the CDNI Metadata interface. This information could, for the CDNI Metadata interface. This information could, for
example, include: example, include:
* discovery of the CDNI Metadata signaling protocol * discovery of the CDNI Metadata signaling protocol
endpoints endpoints
* information necessary to establish secure communication * information necessary to establish secure communication
between the CDNI Metadata signaling protocol endpoints. between the CDNI Metadata signaling protocol endpoints.
CNTL-9 [LOW] The CDNI Control interface may allow bootstrapping of CI-11 [LOW] The CDNI Control interface may allow bootstrapping of
the Content Acquisition interface. This could, for example, the Content Acquisition interface. This could, for example,
include exchange and negotiation of the Content Acquisition include exchange and negotiation of the Content Acquisition
protocols to be used across the CDNs (e.g. HTTP, HTTPS, protocols to be used across the CDNs (e.g. HTTP, HTTPS, FTP,
FTP, ATIS C2). ATIS C2).
CNTL-10 [LOW] The CDNI Control interface may allow exchange and CI-12 [LOW] The CDNI Control interface may allow bootstrapping of
negotiation of delivery authorization mechanisms to be the CDNI Logging interface. This information could, for
supported across the CDNs (e.g. URI signature based example, include:
validation).
CNTL-11 [LOW] The CDNI Control interface may allow bootstrapping of * discovery of the Logging protocol endpoints
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
* information necessary to establish secure communication * negotiation/definition of the log file format and set of
between the Logging protocol endpoints fields to be exported through the Logging protocol, with
some granularity (e.g. On a per content type basis).
* negotiation/definition of the log file format and set of * negotiation/definition of parameters related to
fields to be exported through the Logging protocol, with transaction Logs export (e.g., export protocol, file
some granularity (e.g. On a per content type basis). compression, export frequency, directory).
* negotiation/definition of parameters related to 5. CDNI Request Routing/Redirection Interface Requirements
transaction Logs export (e.g., export protocol, file
compression, export frequency, directory).
CNTL-12 [MED] The CDNI Control interface should allow for multiple The main function of the CDNI request routing/ Redirection (RI)
content items identified by a Content Collection ID to be interface is to allow the Request-Routing systems in interconnected
purged using a single Content Purge action. CDNs to communicate to facilitate redirection of the request across
CDNs.
5. CDNI Request Routing Interface Requirements 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).
The main function of the Request Routing interface is to allow the RI-2 [HIGH] The CDNI request routing/Redirection interface shall
Request-Routing systems in interconnected CDNs to communicate to support efficient request-routing for large objects. This
facilitate redirection of the request across CDNs. 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.
REQ-1 [HIGH] The CDNI Request-Routing interface shall allow the RI-3 [HIGH] The CDNI request routing/Redirection interface shall
Downstream CDN to communicate to the Upstream CDN coarse support recursive CDNI request routing.
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.
REQ-2 [MED] The CDNI Request-Routing interface should allow the RI-4 [HIGH] The CDNI request routing/Redirection interface shall
Downstream CDN to communicate to the Upstream CDN aggregate support iterative CDNI request routing.
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 RI-5 [MED] In case of detection of a request redirection loop, the
CDNI request routing/Redirection interface's loop prevention
mechanism should allow routing of the request by avoiding the
loop (as opposed to the request loop being simply interrupted
without routing the request).
* footprint (e.g. layer-3 coverage) RI-6 [MED] The CDNI request routing/Redirection interface should
support a mechanism allowing enforcment of a limit on the
number of successive CDN redirections for a given request.
* a set of metrics/attributes (e.g. Streaming bandwidth, RI-7 [LOW] The CDNI request routing/Redirection interface may
storage resources, distribution and delivery priority) 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.
* a set of affinities (e.g. Preferences, indication of RI-8 [HIGH] The CDNI request routing/Redirection interface shall
distribution/delivery fees) 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 to facilitate request redirection (e.g. * information from which the location of the user-agent that
Reachability information of Downstream CDN Request originated the request can be inferred (e.g. User Agent
Routing system). fully qualified domain name in case of HTTP-based Request
Routing, DNS Proxy fully qualified domain name in case of
DNS-based Request Routing)
[Note: Some of this information - such as supported content * requested resource information (e.g. Resource URI in case
types and delivery protocols- may also potentially be taken of HTTP-based Request Routing, Resource hostname in case
into account by the distribution system in the Upstream CDN of DNS-based Request Routing)
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.]
REQ-3 [MED] In the case of cascaded redirection, the CDNI Request- * additional available request information (e.g. request
Routing interface shall allow the Downstream CDN to also headers in case of HTTP-based Request Routing).
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.
REQ-4 [LOW] The CDNI Request-Routing interface may allow the RI-9 [LOW] The CDNI request routing/Redirection interface may also
Downstream CDN to communicate to the Upstream CDN aggregate allow the Upstream CDN to convey information pointing to CDNI
information on CDNI administrative limits and policy. This metadata applicable (individually or through inheritance) to
information can be taken into account by the Upstream CDN the requested content. For illustration, the CDNI metadata
Request Routing system in its CDN Selection decisions. This pointed to could potentially include metadata that is
information could, for example, include: 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.
* maximum number of requests redirected by the Upstream CDN RI-10 [HIGH] The CDNI request routing/Redirection interface shall
to be served simultaneously by the Downstream CDN allow the Downstream CDN to include the following information
in the response to the Upstream CDN:
* maximum aggregate volume of content (e.g. in Terabytes) * status code, in particular indicating acceptance or
to be delivered by the Downstream CDN over a time period. 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)
REQ-5 [HIGH] The CDNI Request-Routing architecture and interface * redirection information (e.g. Resource URI in case of
shall support efficient request-routing for small objects. HTTP-based Request Routing, equivalent of a DNS record in
This may, for example, call for a mode of operation (e.g. case of DNS-based Request Routing).
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).
REQ-6 [HIGH] The CDNI Request-Routing architecture and interface RI-11 [HIGH] The CDNI request routing/Redirection interface shall
shall support efficient request-routing for large objects. allow for per-chunk request routing of HTTP Adaptive Streaming
This may, for example, call for a mode of operation (e.g. content.
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.
REQ-7 [HIGH] The CDNI Request-Routing architecture shall support RI-12 [LOW] The CDNI request routing/Redirection interface may allow
recursive CDNI request routing. 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.
REQ-8 [HIGH] The CDNI Request-Routing architecture shall support RI-13 [LOW] The CDNI Request-Routing interface may allow the
iterative CDNI request routing. Upstream CDN to re-sign the invariant portion of the chunk
URIs embedded in the HTTP Adaptive Streaming manifest file.
REQ-9 [MED] In case of detection of a request redirection loop, the RI-14 [MED] The CDNI request routing/Redirection interface should
CDNI Request-Routing loop prevention mechanism should allow allow the use of HTTP cookie to associate the chunks with the
routing of the request by avoiding the loop (as opposed to HTTP Adaptive Stream manifest file (which is verified by the
the request loop being simply interrupted without routing the URI signature) based on the Authorization Group ID (which is
request). an identifier used to correlate the manifest file to the
related chunks).
REQ-10 [MED] The CDNI Request-Routing protocol should support a RI-15 [MED] The CDNI request routing/Redirection interface should
mechanism allowing enforcment of a limit on the number of allow for an efficient method of transferring request routing
successive CDN redirections for a given request. information for multiple chunks from the Downstream CDN to the
Upstream CDN as part of the recursive request routing process.
REQ-11 [LOW] The CDNI Request-Routing protocol may support a 6. CDNI Request Routing/Footprint & Capabilities Advertisement
mechanism allowing an Upstream CDN to avoid redirecting a Interface Requirements
request to a Downstream CDN if that is likely to result in
the total redirection time exceeding some limit.
REQ-12 [HIGH] The CDNI Request-Routing protocol shall allow the The main function of the CDNI Request Routing Footprint &
Upstream CDN to include, in the query to the Downstream CDN, Capabilities Advertisement Interface (FCI) is to allow the Downstream
the necessary information to allow the Downstream CDN to CDN to advertise the information regarding its footprint and
process the redirection query. This could, for example, capabilities to the Upstream CDN.
include:
* information from which the location of the user-agent FCI-1 [HIGH] The CDNI request routing/Footprint & Capabilities
that originated the request can be inferred (e.g. User advertisement interface shall allow the Downstream CDN to
Agent fully qualified domain name in case of HTTP-based communicate to the Upstream CDN coarse information about the
Request Routing, DNS Proxy fully qualified domain name in Downstream CDN ability and/or willingness to handle requests
case of DNS-based Request Routing) 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.
* requested resource information (e.g. Resource URI in FCI-2 [MED] The CDNI request routing/Footprint & Capabilities
case of HTTP-based Request Routing, Resource hostname in advertisement interface should allow the Downstream CDN to
case of DNS-based Request Routing) 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:
* additional available request information (e.g. request * supported content types and delivery protocols
headers in case of HTTP-based Request Routing).
REQ-13 [LOW] The CDNI Request-Routing protocol may also allow the * footprint (e.g. layer-3 coverage)
Upstream CDN to convey information pointing to CDNI metadata * a set of metrics/attributes (e.g. Streaming bandwidth,
applicable (individually or through inheritance) to the storage resources, distribution and delivery priority)
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.
REQ-14 [HIGH] The CDNI Request-Routing interface shall allow the * a set of affinities (e.g. Preferences, indication of
Downstream CDN to include the following information in the distribution/delivery fees)
response to the Upstream CDN:
* status code, in particular indicating acceptance or * information to facilitate request redirection (e.g.
rejection of request (e.g. Because the Downstream CDN is Reachability information of Downstream CDN Request Routing
unwilling or unable to serve the request). In case of system).
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 [Note: Some of this information - such as supported content
HTTP-based Request Routing, equivalent of a DNS record in types and delivery protocols- may also potentially be taken
case of DNS-based Request Routing). 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.]
REQ-15 [HIGH] The CDNI Request-Routing interface shall allow for FCI-3 [MED] In the case of cascaded redirection, the CDNI request
per-chunk request routing of HTTP Adaptive Streaming content. routing/Footprint & Capabilities advertisement interface
[Ed: chunk is treated as any content, is this needed?] 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.
REQ-16 [MED] The CDNI Request-Routing interface should allow the FCI-4 [LOW] The CDNI request routing/Footprint & Capabilities
Upstream CDN to use the information conveyed by the advertisement interface may allow the Downstream CDN to
Downstream CDN during the Recursive Request Routing process communicate to the Upstream CDN aggregate information on CDNI
to rewrite an HTTP Adaptive Streaming manifest file. [Ed: administrative limits and policy. This information can be
should this be LOW?] taken into account by the Upstream CDN Request Routing system
in its CDN Selection decisions. This information could, for
example, include:
REQ-17 [MED] The CDNI Request-Routing interface should allow the * maximum number of requests redirected by the Upstream CDN
Upstream CDN to re-sign the invariant portion of the chunk to be served simultaneously by the Downstream CDN
URIs embedded in the HTTP Adaptive Streaming manifest file.
[Ed: should this be LOW?]
REQ-18 [MED] The CDNI Request-routing interface should allow the use * maximum aggregate volume of content (e.g. in Terabytes) to
of HTTP cookie to associate the chunks with the HTTP Adaptive be delivered by the Downstream CDN over a time period.
Stream manifest file (which is verified by the URI signature)
basedon the Authorization Group ID (which is an identifier
used to correlate the manifest file to the related chunks).
[Ed: should this be LOW?]
REQ-19 [MED] The CDNI Request-Routing interface may allow for an FCI-5 [MED] The CDNI request routing/Footprint & Capabilities
efficient method of transferring request routing information advertisement interface should support advertisement of the
for multiple chunks from the Downstream CDN to the Upstream following types of capabilities:
CDN as part of the recursive request routing process. [Ed:
should this be LOW?]
REQ-20 [MED] The CDNI Request-Routing/Footprint and Advertising * delivery protocol (e.g., HTTP vs. RTMP)
interface shall support advertisement of the following
capabilities:
* support for customized CDNI Logging * acquisition protocol (for acquiring content from an
Upstream CDN)
* support of Content Collection ID logging * redirection mode (e.g., DNS Redirection vs. HTTP
Redirection)
* support for Session ID logging * capabilities related to CDNI Logging (e.g., supported
logging mechanisms)
6. CDNI Metadata Distribution Interface Requirements * capabilities related to CDNI Metadata (e.g., authorization
algorithms or support for proprietary vendor metadata)
The primary function of the CDNI Metadata Distribution interface is FCI-6 [LOW] The CDNI Control interface may allow exchange and
to allow the Distribution system in interconnected CDNs to negotiation of delivery authorization mechanisms to be
supported across the CDNs (e.g. URI signature based
validation).
7. CDNI Metadata Distribution Interface Requirements
The primary function of the CDNI Metadata Distribution interface (MI)
is to allow the Distribution system in interconnected CDNs to
communicate to ensure Content Distribution Metadata with inter-CDN communicate to ensure Content Distribution Metadata with inter-CDN
scope can be exchanged across CDNs. We observe that while the CDNI scope can be exchanged across CDNs. We observe that while the CDNI
Metadata Distribution protocol is currently discussed as a single Metadata Distribution protocol is currently discussed as a single
"protocol", further analysis will determine whether the corresponding "protocol", further analysis will determine whether the corresponding
requirements are to be realized over a single interface and protocol, requirements are to be realized over a single interface and protocol,
or over multiple interfaces and protocols. For example, a subset of or over multiple interfaces and protocols. For example, a subset of
the CDNI metadata might be conveyed in-band along with the actual the CDNI metadata might be conveyed in-band along with the actual
content acquisition across CDNs (e.g. content MD5 in HTTP header) content acquisition across CDNs (e.g. content MD5 in HTTP header)
while another subset might require an out-of-band interface & while another subset might require an out-of-band interface &
protocol (e.g. geo-blocking information). protocol (e.g. geo-blocking information).
META-1 [HIGH] The CDNI Metadata Distribution interface shall allow MI-1 [HIGH] The CDNI Metadata Distribution interface shall allow
the Upstream CDN to provide the Downstream CDN with content the Upstream CDN to provide the Downstream CDN with content
distribution metadata of inter-CDN scope. distribution metadata of inter-CDN scope.
META-2 [HIGH] The CDNI Metadata Distribution interface shall MI-2 [HIGH] The CDNI Metadata Distribution interface shall support
support exchange of CDNI metadata for both the dynamic exchange of CDNI metadata for both the dynamic content
content acquisition model and the pre-positioning content acquisition model and the pre-positioning content acquisition
acquisition model. model.
META-3 [HIGH] The CDNI Metadata Distribution interface shall MI-3 [HIGH] The CDNI Metadata Distribution interface shall support
support a mode where no, or a subset of, the Metadata is a mode where no, or a subset of, the Metadata is initially
initially communicated to the Downstream CDN along with communicated to the Downstream CDN along with information
information about how/where to acquire the rest of the CDNI about how/where to acquire the rest of the CDNI Metadata (i.e.
Metadata (i.e. Dynamic CDNI metadata acquisition). Dynamic CDNI metadata acquisition).
META-4 [MED] The CDNI Metadata Distribution interface should MI-4 [MED] The CDNI Metadata Distribution interface should support
support a mode where all the relevant Metadata is initially a mode where all the relevant Metadata is initially
communicated to the Downstream CDN (i.e. Pre-positioned communicated to the Downstream CDN (i.e. Pre-positioned CDNI
CDNI metadata acquisition). metadata acquisition).
META-5 [HIGH] Whether in the pre-positioned content acquisition MI-5 [HIGH] Whether in the pre-positioned content acquisition model
model or in the dynamic content acquisition model, the CDNI or in the dynamic content acquisition model, the CDNI Metadata
Metadata Distribution interface shall provide the necessary Distribution interface shall provide the necessary information
information to allow the Downstream CDN to acquire the to allow the Downstream CDN to acquire the content from an
content from an upstream source (e.g. Acquisition protocol upstream source (e.g. Acquisition protocol and Uniform
and Uniform Resource Identifier in Upstream CDN- or rules to Resource Identifier in Upstream CDN- or rules to construct
construct this URI). this URI).
META-6 [HIGH] The CDNI metadata shall allow signaling of one or MI-6 [HIGH] The CDNI metadata shall allow signaling of one or more
more upstream sources, where each upstream source can be in upstream sources, where each upstream source can be in the
the Upstream CDN, in another CDN, the CSP origin server or Upstream CDN, in another CDN, the CSP origin server or any
any arbitrary source designated by the Upstream CDN. Note arbitrary source designated by the Upstream CDN. Note that
that some upstream sources (e.g. the content origin server) some upstream sources (e.g. the content origin server) may or
may or may not be willing to serve the content to the may not be willing to serve the content to the Downstream CDN,
Downstream CDN, if this policy is known to the Upstream CDN if this policy is known to the Upstream CDN then it may omit
then it may omit those sources when exchanging CDNI those sources when exchanging CDNI metadata.
metadata.
META-7 [HIGH] The CDNI Metadata Distribution interface shall allow MI-7 [HIGH] The CDNI Metadata Distribution interface (possibly in
the Upstream CDN to request addition and modification of conjunction with the CDNI Control interface) shall allow the
CDNI Metadata into the Downstream CDN. Upstream CDN to request addition and modification of CDNI
Metadata into the Downstream CDN.
META-8 [HIGH] The CDNI Metadata Distribution interface shall allow MI-8 [HIGH] The CDNI Metadata Distribution interface (possibly in
removal of obsolete CDNI Metadata from the Downstream CDN conjunction with the CDNI Control interface) shall allow
(this could, for example, be achieved via an explicit removal of obsolete CDNI Metadata from the Downstream CDN
removal request from the Upstream CDN or via expiration of a (this could, for example, be achieved via an explicit removal
Time-To-Live associated to the Metadata). request from the Upstream CDN or via expiration of a Time-To-
Live associated to the Metadata).
META-9 [HIGH] The CDNI Metadata Distribution interface shall allow MI-9 [HIGH] The CDNI Metadata Distribution interface shall allow
association of CDNI Metadata at the granularity of association of CDNI Metadata at the granularity of individual
individual object. This is necessary to achieve fine-grain object. This is necessary to achieve fine-grain Metadata
Metadata distribution at the level of an individual object distribution at the level of an individual object when
when necessary. necessary.
META-10 [HIGH] The CDNI Metadata Distribution interface shall allow MI-10 [HIGH] The CDNI Metadata Distribution interface shall allow
association of CDNI Metadata at the granularity of an object association of CDNI Metadata at the granularity of an object
set. This is necessary to achieve scalable distribution of set. This is necessary to achieve scalable distribution of
metadata when a large number of objects share the same metadata when a large number of objects share the same
distribution policy. distribution policy.
META-11 [HIGH] The CDNI Metadata Distribution interface shall MI-11 [HIGH] The CDNI Metadata Distribution interface shall support
support multiple levels of inheritance with precedence to multiple levels of inheritance with precedence to more
more specific metadata. For example, the CDNI Metadata specific metadata. For example, the CDNI Metadata
Distribution protocol may support metadata that is Distribution protocol may support metadata that is applicable
applicable to any content, metadata that is applicable to a to any content, metadata that is applicable to a content
content collection and metadata that is applicable to an collection and metadata that is applicable to an individual
individual content where content level metadata overrides content where content level metadata overrides content
content collection metadata that overrides metadata for any collection metadata that overrides metadata for any content.
content.
META-12 [HIGH] The CDNI Metadata Distribution interface shall ensure MI-12 [HIGH] The CDNI Metadata Distribution interface shall ensure
that conflicting metadata with overlapping scope are that conflicting metadata with overlapping scope are prevented
prevented or deterministically handled. or deterministically handled.
META-13 Removed. MI-13 [HIGH] The CDNI Metadata Distribution interface shall allow
signaling of content distribution control policies. For
example, this could potentially include:
META-14 [HIGH] The CDNI Metadata Distribution interface shall allow * geo-blocking information (i.e. Information defining
signaling of content distribution control policies. For geographical areas where the content is to be made
example, this could potentially include: available or blocked)
* geo-blocking information (i.e. Information defining * availability windows (i.e. Information defining time
geographical areas where the content is to be made windows during which the content is to be made available
available or blocked) or blocked; expiration time may also be included to remove
content)
* availability windows (i.e. Information defining time * delegation whitelist/blacklist (i.e. Information defining
windows during which the content is to be made available which Downstream CDNs the content may/may not be delivered
or blocked; expiration time may also be included to through)
remove content)
* delegation whitelist/blacklist (i.e. Information MI-14 [HIGH] The CDNI Metadata interface shall be able to exchange a
defining which Downstream CDNs the content may/may not set of metadata elements with specified semantics (e.g. start
be delivered through) of time window, end of time window).
META-15 [HIGH] The CDNI Metadata interface shall be able to exchange MI-15 [HIGH] The CDNI Metadata interface shall allow exchange of
a set of well-accepted metadata elements with specified opaque metadata element, whose semantic is not defined in CDNI
semantics (e.g. start of time window, end of time window). but established by private CDN agreement.
META-16 [HIGH] The CDNI Metadata interface shall allow exchange of MI-16 [HIGH] The CDNI Metadata Distribution interface shall allow
opaque metadata element, whose semantic is not defined in signaling of authorization checks and validation that are to
CDNI but established by private CDN agreement. be performed by the surrogate before delivery. For example,
this could potentially include:
META-17 [HIGH] The CDNI Metadata Distribution interface shall allow * need to validate URI signed information (e.g. Expiry
signaling of authorization checks and validation that are to time, Client IP address).
be performed by the surrogate before delivery. For example,
this could potentially include:
* need to validate URI signed information (e.g. Expiry MI-17 [MED] The CDNI Metadata Distribution interface should allow
time, Client IP address). signaling of CDNI-relevant surrogate cache behavior
parameters. For example, this could potentially include:
META-18 [LOW] The CDNI Metadata Distribution interface may allow * control of whether the query string of HTTP URI is to be
signaling of CDNI-relevant surrogate cache behavior ignored by surrogate cache
parameters. For example, this could potentially include:
* control of whether the query string of HTTP URI is to be * enforcement of caching directives by Downstream CDN that
ignored by surrogate cache are different than the ones signalled in the HTTP headers
(e.g. "Expires" field)
* content revalidation parameters (e.g. TTL) * rate-pacing by Downstream CDN for content delivery (e.g.
Progressive Download)
META-19 [HIGH] The CDNI Metadata interface shall provide indication MI-18 [HIGH] The CDNI Metadata interface shall provide indication of
of related content (e.g. HTTP Adaptive Bit Rate chunks) by related content (e.g. HTTP Adaptive Bit Rate chunks) by the
the Content Collection ID (CCID) metadata. This could be Content Collection ID (CCID) metadata. This could be used by
used by the Downstream CDN for operations on the group of the Downstream CDN for operations on the group of content.
content. For example, this could potentially include: For example, this could potentially include:
* content acquisition for the entire set of files when one * content acquisition for the entire set of files when one
piece of content is requested piece of content is requested
* local file management and storage bundles all the files * local file management and storage bundles all the files
for the content for the content
* purging the entire set of files associated with the * purging the entire set of files associated with the
content content
* logging of the delivery of the content for the session * logging of the delivery of the content for the session
when at least one file in the set was delivered when at least one file in the set was delivered
META-20 [HIGH] The CDNI Metadata Distribution interface shall MI-19 [MED] The CDNI Metadata Distribution interface should support
support an OPTIONAL mechanism allowing the Upstream CDN to an OPTIONAL mechanism allowing the Upstream CDN to indicate to
indicate to the Downstream CDN which CDNI Log fields are to the Downstream CDN which CDNI Log fields are to be provided
be provided for all, for specific sets of, or for specific for all, for specific sets of, or for specific content items
content items delivered using HTTP. A CDNI implementation delivered using HTTP. A CDNI implementation that does not
that does not support this optional CDNI Metadata support this optional CDNI Metadata Distribution Interface
Distribution Interface mechanism MUST ignore this log format mechanism MUST ignore this log format indication and generate
indication and generate CDNI logging format for HTTP CDNI logging format for HTTP Adaptive Streaming using the
Adaptive Streaming using the default set of CDNI Logging default set of CDNI Logging fields. (Note: this function is
fields. not concluded to be in Metadata Interface or Control
Interface)
META-21 [MED] The CDNI Metadata Distribution interface shall allow MI-20 [MED] The CDNI Metadata Distribution interface should allow
the Upstream CDN to signal to the Downstream CDN the Content the Upstream CDN to signal to the Downstream CDN the Content
Collection ID value for all, for specific sets of, or for Collection ID value for all, for specific sets of, or for
specific content items delivered using HTTP. Whenever the specific content items delivered using HTTP. Whenever the
Downstream CDN is instructed by the Upstream CDN to report Downstream CDN is instructed by the Upstream CDN to report the
the Content Collection ID field in the log records, the Content Collection ID field in the log records, the Downstream
Downstream CDN is to use the value provided through the CDNI CDN is to use the value provided through the CDNI Metadata
Metadata interface for the corresponding content. Note the interface for the corresponding content. Note the Session ID
Session ID field along with Content Collection ID may be field along with Content Collection ID may be used for HTTP
used for HTTP Adaptive Streaming content. Adaptive Streaming content.
META-22 [MED] The CDNI Metadata Distribution interface shall allow MI-21 [MED] The CDNI Metadata Distribution interface should allow
the Upstream CDN to signal to the Downstream CDN the the Upstream CDN to signal to the Downstream CDN the
Authorization Group ID value for all the related HTTP Authorization Group ID value for all the related HTTP Adaptive
Adaptive Streamin content (i.e. manifest file and chunks). Streamin content (i.e. manifest file and chunks). The
The authorization result of a content (e.g. manifest file) authorization result of a content (e.g. manifest file) is
is transferred over to related content (e.g. chunks). [Ed: transferred over to related content (e.g. chunks). [Ed: need
need to improve wording?] to improve wording?]
7. CDNI Logging Interface Requirements 8. CDNI Logging Interface Requirements
This section identifies the requirements related to the CDNI Logging This section identifies the requirements related to the CDNI Logging
interface. We observe that while the CDNI Logging interface is interface (LI). We observe that while the CDNI Logging interface is
currently discussed as a single "protocol", further analysis will currently discussed as a single "protocol", further analysis will
determine whether the corresponding requirements are to be realized determine whether the corresponding requirements are to be realized
over a single interface and protocol, or over multiple interfaces and over a single interface and protocol, or over multiple interfaces and
protocols. protocols.
LOG-1 [HIGH] The CDNI logging architecture and interface shall LI-1 [HIGH] The CDNI logging architecture and interface shall
ensure reliable logging of CDNI events. ensure reliable transfer of CDNI logging information across
CDNs.
LOG-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.
LOG-3 [MED] In the case of cascaded CDNs, the CDNI Logging LI-2 [HIGH] The CDNI Logging interface shall provide logging of
interface shall allow the Downstream CDN to report to the deliveries and incomplete deliveries to User Agents performed
Upstream CDN logging for deliveries and incomplete deliveries by the Downstream CDN as a result of request redirection by
performed by the Downstream CDN itself as well as logging for the Upstream CDN.
deliveries and incomplete deliveries performed by cascaded
CDNs on behalf of the Downstream CDN.
LOG-4 Removed. 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.
LOG-5 [HIGH] The CDNI Logging interface shall support batch/offline LI-4 [HIGH] The CDNI Logging interface shall support batch/offline
exchange of logging records. exchange of logging records.
LOG-6 [MED] The CDNI Logging interface should also support LI-5 [MED] The CDNI Logging interface should also support
additional timing constraints for some types of logging additional timing constraints for some types of logging
records (e.g. near-real time for monitoring and analytics records (e.g. near-real time for monitoring and analytics
applications) applications)
LOG-7 [HIGH] The CDNI Logging interface shall define a log file LI-6 [HIGH] The CDNI Logging interface shall define a log file
format and a set of fields to be exported through the Logging format and a set of fields to be exported for various CDNI
protocol, with some granularity (e.g. On a per content type logging events.
basis).
LOG-8 [HIGH] The CDNI Logging interface shall define a transport LI-7 [HIGH] The CDNI Logging interface shall define a transport
mechanisms to exchange CDNI Logging files. mechanism to exchange CDNI Logging files.
LOG-9 [MED] The CDNI Logging interface should allow a CDN to query LI-8 [MED] The CDNI Logging interface should allow a CDN to query
another CDN for relevant current logging records (e.g. For another CDN for relevant current logging records (e.g. For
on-demand access to real-time logging information). on-demand access to real-time logging information).
LOG-10 [LOW] The CDNI Logging interface may support aggregate/ LI-9 [LOW] The CDNI Logging interface may support aggregate/
summarized logs (e.g. total bytes delivered for a content summarized logs (e.g. total bytes delivered for a content
regardless of individual User Agents to which it was regardless of individual User Agents to which it was
delivered). delivered).
LOG-11 [LOW] The CDNI Logging interface may support logging of LI-10 [LOW] The CDNI Logging interface may support logging of
performance data for deliveries to User Agents performed by performance data for deliveries to User Agents performed by
the Downstream CDN as a result of request redirection by the the Downstream CDN as a result of request redirection by the
Upstream CDN. Performance data may include various traffic Upstream CDN. Performance data may include various traffic
statistics (the specific parameters are to be determined). statistics (the specific parameters are to be determined).
The CDNI Logging interface may support the Upstream CDN to The CDNI Logging interface may support the Upstream CDN to
indicate the nature and contents of the performance data to indicate the nature and contents of the performance data to be
be reported by the Downstream CDN. reported by the Downstream CDN.
LOG-12 [MED] The CDNI Logging interface shall support logging of LI-11 [MED] The CDNI Logging interface should support logging of
consumed resources (e.g. storage, bandwidth) to the Upstream consumed resources (e.g. storage, bandwidth) to the Upstream
CDN for deliveries where content is stored by the Downstream CDN for deliveries where content is stored by the Downstream
CDN for delivery to User Agents. The information logged may CDN for delivery to User Agents. The information logged may
include the type of storage (e.g., Origin, Intermediate, include the type of storage (e.g., Origin, Intermediate, Edge,
Edge, Cache) as well as the amount of storage (e.g., total Cache) as well as the amount of storage (e.g., total GB, GB
GB, GB used, per time period, per content domain) all of used, per time period, per content domain) all of which may
which may impact the cost of the services. impact the cost of the services.
LOG-13 [MED] In the case of cascaded CDNs, the CDNI Logging LI-12 [MED] In the case of cascaded CDNs, the CDNI Logging interface
interface shall support the Downstream CDN to report consumed should support the Downstream CDN to report consumed resources
resources (e.g. storage, bandwidth) to the Upstream CDN where (e.g. storage, bandwidth) to the Upstream CDN where content is
content is stored by the Downstream CDN itself as well as stored by the Downstream CDN itself as well as logging for
logging for storage resources when content storage is storage resources when content storage is performed by
performed by cascaded CDNs on behalf of the Downstream CDN. cascaded CDNs on behalf of the Downstream CDN.
LOG-14 [HIGH] The CDNI Logging interface shall support logging of LI-13 [HIGH] The CDNI Logging interface shall support logging of
deleted objects from the Downstream CDN to the Upstream CDN deleted objects from the Downstream CDN to the Upstream CDN as
as a result of explicit delete requests on via the CDNI a result of explicit delete requests on via the CDNI Control
Control interface from the Upstream CDN. interface from the Upstream CDN.
LOG-15 [HIGH] The CDNI Logging interface shall support extensibility LI-14 [HIGH] The CDNI Logging interface shall support extensibility
to allow proprietary information fields to be carried. These to allow proprietary information fields to be carried. These
information fields must be agreed upon ahead of time between information fields must be agreed upon ahead of time between
the corresponding CDNs. the corresponding CDNs.
LOG-16 [HIGH] The CDNI Logging interface shall support the exchange LI-15 [HIGH] The CDNI Logging interface shall support the exchange
of extensible log file formats to support proprietary of extensible log file formats to support proprietary
information fields. These information fields must be agreed information fields. These information fields must be agreed
upon ahead of time between the corresponding CDNs. upon ahead of time between the corresponding CDNs.
LOG-17 [HIGH] The CDNI Logging interface shall support the LI-16 [HIGH] The CDNI Logging interface shall allow a CDN to notify
notification from Downstream CDN to Upstream CDN for the another CDN about which CDNI logging information is available
event that the logging retention duration or maximum size of for transfer and/or no longer available (e.g. it exceeded some
logging data has exceeded. logging retention period or some logging retention volume).
LOG-18 [MED] The CDNI Logging interface should support the ability LI-17 [MED] The CDNI Logging interface should support the ability
for the Downstream CDN to include the Content Collection ID for the Downstream CDN to include the Content Collection ID
and Session ID fields in CDNI log entries generated for HTTP and Session ID fields in CDNI log entries generated for HTTP
Adaptive Streaming content. This fields can be supported by Adaptive Streaming content.
the "customizable" log format which is expected to be defined
independently of HTTP Adaptive Streaming.
8. CDNI Security Requirements 9. CDNI Security Requirements
This section identifies the requirements related to the CDNI This section identifies the requirements related to the CDNI
security. Some of those are expected to affect multiple or all security. Some of those are expected to affect multiple or all
protocols. protocols.
SEC-1 [HIGH] All the CDNI interface shall support secure operation SEC-1 [HIGH] All the CDNI interface shall support secure operation
over unsecured IP connectivity (e.g. The Internet). This over unsecured IP connectivity (e.g. The Internet). This
includes authentication, confidentiality, integrity protection includes authentication, confidentiality, integrity protection
as well as protection against spoofing and replay. as well as protection against spoofing and replay.
skipping to change at page 20, line 43 skipping to change at page 21, line 15
deliveries performed by the Downstream CDN on behalf of the deliveries performed by the Downstream CDN on behalf of the
Upstream CDN. Upstream CDN.
SEC-5 [LOW] The CDNI solution may provide a mechanism allowing an SEC-5 [LOW] The CDNI solution may provide a mechanism allowing an
Upstream CDN that has credentials to acquire content from the Upstream CDN that has credentials to acquire content from the
CSP origin server (or another CDN), to allow establishment of CSP origin server (or another CDN), to allow establishment of
credentials authorizing the Downstream CDN to acquire the credentials authorizing the Downstream CDN to acquire the
content from the CSP origin server (or the other CDN) (e.g. content from the CSP origin server (or the other CDN) (e.g.
In case the content cannot be acquired from the Upstream CDN). In case the content cannot be acquired from the Upstream CDN).
9. IANA Considerations 10. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an Note to RFC Editor: this section may be removed on publication as an
RFC. RFC.
10. Security Considerations 11. Security Considerations
This document discusses CDNI security requirements in Section 8. This document discusses CDNI security requirements in Section 9.
11. Authors 12. Authors
This document reflects the contributions from the following authors: This document reflects the contributions from the following authors:
Francois Le Faucheur Francois Le Faucheur
Cisco Systems Cisco Systems
flefauch@cisco.com flefauch@cisco.com
Mahesh Viveganandhan Mahesh Viveganandhan
skipping to change at page 21, line 28 skipping to change at page 22, line 4
Mahesh Viveganandhan Mahesh Viveganandhan
Cisco Systems Cisco Systems
mvittal@cisco.com mvittal@cisco.com
Grant Watson Grant Watson
BT BT
grant.watson@bt.com grant.watson@bt.com
12. Acknowledgements 13. Acknowledgements
This document leverages the earlier work of the IETF CDI working This document leverages the earlier work of the IETF CDI working
group in particular as documented in [I-D.cain-request-routing-req], 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]. [I-D.amini-cdi-distribution-reqs] and [I-D.gilletti-cdnp-aaa-reqs].
The authors would like to thank Gilles Bertrand, Christophe Caillet, The authors would like to thank Gilles Bertrand, Christophe Caillet,
Bruce Davie, Phil Eardly, Ben Niven-Jenkins, Agustin Schapira, Emile Bruce Davie, Phil Eardly, Ben Niven-Jenkins, Agustin Schapira, Emile
Stephan, Eric Burger, Susan He, Kevin Ma, and Daryl Malas for their Stephan, Eric Burger, Susan He, Kevin Ma, and Daryl Malas for their
input. Serge Manning along with Robert Streijl, Vishwa Prasad, Percy input. Serge Manning along with Robert Streijl, Vishwa Prasad, Percy
Tarapore, Mike Geller, and Ramki Krishnan contributed to this Tarapore, Mike Geller, and Ramki Krishnan contributed to this
document by addressing the requirements of the ATIS Cloud Services document by addressing the requirements of the ATIS Cloud Services
Forum. Forum.
Ray Brandenburg, Matt Caufield, and Francois Le Faucheur/Gilles Ray Brandenburg, Matt Caufield, and Francois Le Faucheur/Gilles
Bertrand provided valuable inputs for HTTP Adaptive Streaming, CDNI Bertrand provided valuable inputs for HTTP Adaptive Streaming, CDNI
Metadata interface, and CDNI Logging interface, respectively. Metadata interface, and CDNI Logging interface, respectively.
13. References 14. Appendix: Requirements Mapping
13.1. Normative References
The labels and numbers changed in version 6 of this document as part
of the requirements cleanup and structuring changes due to
introduction of the new CDNI request routing/Redirection Interface
and CDNI request routing/Footprint & Capabilities advertisement
interface. There are some CDNI drafts that have referenced the
requirements in this document. Therefore, the following table
provides the mapping of the requirement label and numbering.
+--------------------+-------------------------------+
| Version 5 | Version 6 |
+--------------------+-------------------------------+
| GEN-13 | Removed |
| GEN-14 | GEN-13 |
| CNTL-# | CI-# (label changed) |
| CNTL-1 | CI-1 and CI-3 |
| CNTL-2 to CNTL-9 | CI-4 to CI-11 |
| CNTL-10 | FCI-6 |
| CNTL-11 | CI-12 |
| CNTL-12 | CI-2 |
| REQ-# | RI-# or FCI-# (label changed) |
| REQ-1 to REQ-4 | FCI-1 to FCI-4 |
| REQ-5 to REQ-19 | RI-1 to RI-15 |
| REQ-20 | FCI-5 |
| META-# | MI-# (label changed) |
| META-13 | Removed |
| META-14 to META-22 | MI-13 to MI-21 |
| LOG-# | LI-# (label changed) |
| LOG-4 | Removed |
| LOG-5 to LOG-18 | LI-4 to LI-17 |
+--------------------+-------------------------------+
Requirement Reference Mapping Table
15. References
15.1. Normative References
[I-D.davie-cdni-framework] [I-D.davie-cdni-framework]
Davie, B. and L. Peterson, "Framework for CDN Davie, B. and L. Peterson, "Framework for CDN
Interconnection", draft-davie-cdni-framework-01 (work in Interconnection", draft-davie-cdni-framework-01 (work in
progress), October 2011. progress), October 2011.
[I-D.ietf-cdni-problem-statement]
Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content
Distribution Network Interconnection (CDNI) Problem
Statement", draft-ietf-cdni-problem-statement-08 (work in
progress), June 2012.
[I-D.ietf-cdni-use-cases]
Bertrand, G., Emile, S., Burbridge, T., Eardley, P., Ma,
K., and G. Watson, "Use Cases for Content Delivery Network
Interconnection", draft-ietf-cdni-use-cases-10 (work in
progress), August 2012.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
13.2. Informative References [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content
Distribution Network Interconnection (CDNI) Problem
Statement", RFC 6707, September 2012.
[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.
15.2. Informative References
[I-D.amini-cdi-distribution-reqs] [I-D.amini-cdi-distribution-reqs]
Amini, L., "Distribution Requirements for Content Amini, L., "Distribution Requirements for Content
Internetworking", draft-amini-cdi-distribution-reqs-02 Internetworking", draft-amini-cdi-distribution-reqs-02
(work in progress), November 2001. (work in progress), November 2001.
[I-D.cain-request-routing-req] [I-D.cain-request-routing-req]
Cain, B., "Request Routing Requirements for Content Cain, B., "Request Routing Requirements for Content
Internetworking", draft-cain-request-routing-req-03 (work Internetworking", draft-cain-request-routing-req-03 (work
in progress), November 2001. in progress), November 2001.
 End of changes. 133 change blocks. 
487 lines changed or deleted 535 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/