One document matched: draft-ietf-cdni-requirements-15.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-ietf-cdni-requirements-15"
ipr="trust200902">
<front>
<title abbrev="CDNI Requirements">Content Distribution Network
Interconnection (CDNI) Requirements</title>
<author fullname="Kent Leung" initials="K." role="editor" surname="Leung">
<organization abbrev="Cisco">Cisco Systems</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<code>95134</code>
<region>CA</region>
<country>U.S.A.</country>
</postal>
<phone>+1 408 526 5030</phone>
<email>kleung@cisco.com</email>
</address>
</author>
<author fullname="Yiu Lee" initials="Y." role="editor" surname="Lee">
<organization abbrev="Comcast">Comcast</organization>
<address>
<postal>
<street>One Comcast Center</street>
<city>Philadelphia</city>
<region>PA</region>
<code>19103</code>
<country>U.S.A.</country>
</postal>
<email>yiu_lee@cable.comcast.com</email>
</address>
</author>
<date day="14" month="Jan" year="2014"/>
<abstract>
<t>Content delivery is frequently provided by specifically architected
and provisioned Content Delivery Networks (CDNs). As a result of
significant growth in content delivered over IP networks, existing CDN
providers are scaling up their infrastructure. Many Network Service
Providers and Enterprise Service Providers are also deploying their own
CDNs. To deliver contents from the Content Service Provider (CSP) to end
users, the contents may traverse across multiple CDNs. This creates a
need for interconnecting (previously) standalone CDNs so that they can
collectively act as a single delivery platform from the CSP to the end
users.</t>
<t>The goal of the present document is to outline the requirements for
the solution and interfaces to be specified by the CDNI working
group.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The volume of video and multimedia content delivered over the
Internet is rapidly increasing and expected to continue doing so in the
future. In the face of this growth, Content Delivery Networks (CDNs)
provide numerous benefits: reduced delivery cost for cacheable content,
improved quality of experience for end users, and increased robustness
of delivery. For these reasons CDNs are frequently used for large-scale
content delivery. As a result of the significant growth in content
delivered over IP networks, existing CDN providers are scaling up their
infrastructure and many Network Service Providers and Enterprise Service
Providers are deploying their own CDNs. Subject to the policy of the
Content Service Provider (CSP), it is generally desirable that a given
item of content can be delivered to an end user regardless of that end
user's location or attachment network. This creates a need for
interconnecting (previously) standalone CDNs so they can interoperate
and collectively behave as a single delivery infrastructure. The Content
Distribution Network Interconnection (CDNI) working group has been
chartered to develop an interoperable and scalable solution for such CDN
interconnections.</t>
<t><xref target="RFC6707">CDNI Problem Statement</xref> outlines the
problem area that the CDNI working group is chartered to address. <xref
target="RFC6770">Use Cases for CDNI</xref> discusses the use cases for
CDN Interconnection. <xref target="I-D.ietf-cdni-framework">Framework
for CDN Interconnection</xref> discusses the technology framework for
the CDNI solution and interfaces.</t>
<t>The goal of the present document is to document the requirements for
the CDNI solution and interfaces. In order to meet the timelines defined
in the working group charter, the present document categorizes the CDNI
requirements as "High Priority", "Medium Priority", and "Low
Priority".</t>
<section anchor="terminology" title="Terminology">
<t>This document uses the terminology defined in <xref
target="RFC6707"/>. In addition, the key words "High Priority",
"Medium Priority" and "Low Priority" in this document are to be
interpreted in the following way:</t>
<t><list style="symbols">
<t>"High Priority": When a requirement is tagged as "{HIGH}", it
is considered by the working group as an essential function for
CDNI and necessary to a deployable solution. This requirement has
to be met even if it causes a delay in the delivery by the working
group of a deployable solution.</t>
<t>"Medium Priority": When a requirement is tagged as "{MED}", it
is considered by the working group as an important function for
CDNI. This requirement has to be met, unless it is established
that attempting to meet this requirement would cause a delay in
the delivery by the working group of a deployable solution.</t>
<t>"Low Priority": When a requirement is tagged as "{LOW}", it is
considered by the working group as a useful function for CDNI. The
working group will attempt to meet this requirement as long as it
does not prevent meeting the "High Priority" and "Medium Priority"
requirements and does not cause a delay in the delivery by the
working group of a deployable solution.</t>
</list></t>
</section>
</section>
<section anchor="cdni-interfaces" title="CDNI Model and CDNI Interfaces">
<t>The "CDNI Expanded Model and CDNI Interfaces" figure and brief
descriptions of the CDNI interfaces in <xref
target="I-D.ietf-cdni-framework"/> are replicated below for convenience.
That document contains the definitive reference model and descriptions
for the CDNI interfaces.</t>
<t><list style="symbols">
<t>CDNI Control interface (CI): Operations to bootstrap and
parameterize the other CDNI interfaces, as well as operations to
pre-position, revalidate, and purge both metadata and content. The
latter subset of operations is sometimes collectively called the
“Trigger interface.”</t>
<t>CDNI Request Routing interface: Operations to determine what CDN
(and optionally what surrogate within a CDN) is to serve end-user's
requests. This interface is actually a logical bundling of two
separate but related interfaces: <list style="symbols">
<t>CDNI Footprint & Capabilities Advertisement interface
(FCI): Asynchronous operations (as defined in <xref
target="I-D.ietf-cdni-framework"/>) to exchange routing
information (e.g., the network footprint and capabilities served
by a given CDN) that enables CDN selection for subsequent user
requests; and</t>
<t>CDNI Request Routing Redirection interface (RI): Synchronous
operations (as defined in <xref
target="I-D.ietf-cdni-framework"/>) to select a delivery CDN
(surrogate) for a given user request.</t>
</list></t>
<t>CDNI Metadata interface (MI): Operations to communicate metadata
that governs how the content is delivered by interconnected CDNs.
Examples of CDNI metadata include geo-blocking directives,
availability windows, access control mechanisms, and purge
directives. It may include a combination of: <list style="symbols">
<t>Asynchronous operations to exchange metadata that govern
subsequent user requests for content; and</t>
<t>Synchronous operations that govern behavior for a given user
request for content.</t>
</list></t>
<t>CDNI Logging interface (LI): Operations that allow interconnected
CDNs to exchange relevant activity logs. It may include a
combination of: <list style="symbols">
<t>Real-time exchanges, suitable for runtime traffic monitoring;
and</t>
<t>Offline exchanges, suitable for analytics and billing.</t>
</list></t>
</list></t>
<figure anchor="fig-cdni-model"
title="CDNI Expanded Model and CDNI Interfaces">
<preamble/>
<artwork> --------
/ \
| 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
</artwork>
<postamble/>
</figure>
<t/>
<t/>
</section>
<section title="Generic CDNI Requirements">
<t>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.</t>
<t><list counter="gen-reqs" hangIndent="4" style="format GEN-%d">
<t>{MED} Wherever possible, the CDNI interfaces should reuse or
leverage existing IETF protocols.</t>
<t>{HIGH} The CDNI solution shall not require a change, or an
upgrade, to the User Agent to benefit from content delivery through
interconnected CDNs.</t>
<t>{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.</t>
<t>{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.</t>
<t>{HIGH} The CDNI solution shall support delivery to the User Agent
based on <xref target="RFC2616">HTTP</xref>. (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
specifying which acquisition and delivery protocols are to be
supported).</t>
<t>{HIGH} The CDNI solution shall support acquisition across CDNs
based on <xref target="RFC2616">HTTP</xref>. (The note above applies
to this requirement too)</t>
<t>{LOW} The CDNI solution may support delivery to the User Agent
based on protocols other than HTTP.</t>
<t>{LOW} The CDNI solution may support acquisition across CDNs based
on protocols other than HTTP.</t>
<t>{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.</t>
<t>{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.).</t>
<t>{HIGH} The CDNI solution shall prevent looping of any CDNI
information exchange.</t>
<t>{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 literals,
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. identify the IP
address of 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).</t>
<t>{HIGH} The CDNI solution shall support HTTP Adaptive Streaming
content.</t>
</list></t>
</section>
<section title="CDNI Control Interface Requirements">
<t>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.</t>
<t><list counter="control-reqs" hangIndent="4" style="format CI-%d">
<t>{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.</t>
<t>{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.</t>
<t>{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.</t>
<t>{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.</t>
<t>{MED} The CDNI Control interface should support initiation and
control by the Upstream CDN of pre-positioned CDNI metadata
acquisition by the Downstream CDN.</t>
<t>{MED} The CDNI Control interface should support initiation and
control by the Upstream CDN of pre-positioned content acquisition by
the Downstream CDN.</t>
<t>{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).</t>
<t>{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).</t>
<t>{LOW} The CDNI Control interface may allow bootstrapping of the
CDNI Request Routing interface. For example, this can potentially
include:<list style="symbols">
<t>negotiation of the request routing method (e.g. DNS vs HTTP,
if more than one method is specified)</t>
<t>discovery of the CDNI Request Routing interface endpoints</t>
<t>information necessary to establish secure communication
between the CDNI Request Routing interface endpoints.</t>
</list></t>
<t>{LOW} The CDNI Control interface may allow bootstrapping of the
CDNI Metadata interface. This information could, for example,
include:<list style="symbols">
<t>discovery of the CDNI Metadata interface endpoints</t>
<t>information necessary to establish secure communication
between the CDNI Metadata interface endpoints.</t>
</list></t>
<t>{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<xref
target="ATIS-0800042"/>).</t>
<t>{LOW} The CDNI Control interface may allow bootstrapping of the
CDNI Logging interface. This information could, for example,
include:<list style="symbols">
<t>discovery of the CDNI Logging interface endpoints</t>
<t>information necessary to establish secure communication
between the CDNI Logging interface endpoints</t>
<t>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).</t>
<t>negotiation/definition of parameters related to transaction
logs export (e.g., export protocol, file compression, export
frequency, directory).</t>
</list></t>
</list></t>
</section>
<section title="CDNI Request Routing Redirection Interface Requirements">
<t/>
<t>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.</t>
<t><list counter="reqrouting-ri" hangIndent="4" style="format RI-%d">
<t>{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).</t>
<t>{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.</t>
<t>{HIGH} The CDNI Request Routing Redirection interface shall
support recursive CDNI request routing.</t>
<t>{HIGH} The CDNI Request Routing Redirection interface shall
support iterative CDNI request routing.</t>
<t>{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).</t>
<t>{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.</t>
<t>{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.</t>
<t>{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:<list
style="symbols">
<t>information from which the geographic region pertaining to
the IP address 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)</t>
<t>requested resource information (e.g. Resource URI in case of
HTTP-based Request Routing, Resource hostname in case of
DNS-based Request Routing)</t>
<t>additional available request information (e.g. request
headers in case of HTTP-based Request Routing).</t>
</list></t>
<t>{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.</t>
<t>{HIGH} The CDNI Request Routing Redirection interface shall allow
the Downstream CDN to include the following information in the
response to the Upstream CDN:<list style="symbols">
<t>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)</t>
<t>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).</t>
</list></t>
<t>{HIGH} The CDNI Request Routing Redirection interface shall allow
for per-chunk request routing of HTTP Adaptive Streaming
content.</t>
<t>{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.</t>
<t>{LOW} The CDNI Request-Routing interface may allow the Upstream
CDN to re-compute the message digest or digital signature over the
invariant portion of the chunk URIs embedded in the HTTP Adaptive
Streaming manifest file.</t>
<t>{MED} The CDNI Request Routing Redirection interface should
correlate the HTTP Adaptive Stream manifest file to the related
chunks referenced in the manifest file.</t>
<t>{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.</t>
</list></t>
</section>
<section title="CDNI Footprint & Capabilities Advertisement Interface Requirements">
<t/>
<t>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.</t>
<t><list counter="reqrouting-fci" hangIndent="4" style="format FCI-%d">
<t>{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.</t>
<t>{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:<list style="symbols">
<t>supported content types and delivery protocols</t>
<t>footprint (e.g. layer-3 coverage)</t>
<t>a set of metrics/attributes (e.g. Streaming bandwidth,
storage resources, distribution and delivery priority)</t>
<t>a set of affinities (e.g. Preferences, indication of
distribution/delivery fees)</t>
<t>information to facilitate request redirection (e.g.
Reachability information of Downstream CDN Request Routing
system).</t>
</list>[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.]</t>
<t>{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.</t>
<t>{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:<list style="symbols">
<t>maximum number of requests redirected by the Upstream CDN to
be served simultaneously by the Downstream CDN</t>
<t>maximum aggregate volume of content (e.g. in Terabytes) to be
delivered by the Downstream CDN over a time period.</t>
</list></t>
<t>{MED} The CDNI Footprint & Capabilities Advertisement
interface should support advertisement of the following types of
capabilities:<list style="symbols">
<t>delivery protocol (e.g., HTTP vs. RTMP)</t>
<t>acquisition protocol (for acquiring content from an Upstream
CDN)</t>
<t>redirection mode (e.g., DNS Redirection vs. HTTP
Redirection)</t>
<t>capabilities related to CDNI Logging (e.g., supported logging
mechanisms)</t>
<t>capabilities related to CDNI Metadata (e.g., authorization
algorithms or support for proprietary vendor metadata)</t>
</list></t>
<t>{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).</t>
<t>{HIGH} The CDNI Footprint & Capabilities Advertisement
interface shall support extensible fields used to convey the CDN
capabilities and methods to indicate the footprint in the
advertisement from the Downstream CDN to the Upstream CDN.</t>
</list></t>
</section>
<section title="CDNI Metadata Interface Requirements">
<t>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).</t>
<t><list counter="meta-reqs" hangIndent="4" style="format MI-%d">
<t>{HIGH} The CDNI Metadata interface shall allow the Upstream CDN
to provide the Downstream CDN with content distribution metadata of
inter-CDN scope.</t>
<t>{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.</t>
<t>{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).</t>
<t>{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).</t>
<t>{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).</t>
<t>{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.</t>
<t>{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.</t>
<t>{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).</t>
<t>{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.</t>
<t>{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.</t>
<t>{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.</t>
<t>{HIGH} The CDNI Metadata interface shall ensure that conflicting
metadata with overlapping scope are prevented or deterministically
handled.</t>
<t>{HIGH} The CDNI Metadata interface shall allow signaling of
content distribution control policies. For example, this could
potentially include:<list style="symbols">
<t>geo-blocking information (i.e. Information defining
geographical areas where the content is to be made available or
blocked)</t>
<t>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)</t>
<t>delegation whitelist/blacklist (i.e. Information defining
which Downstream CDNs the content may/may not be delivered
through)</t>
</list></t>
<t>{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).</t>
<t>{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.</t>
<t>{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
include the need to validate information (e.g. Expiry time, Client
IP address) required for access authorization.</t>
<t>{MED} The CDNI Metadata interface should allow signaling of
CDNI-relevant surrogate cache behavior parameters. For example, this
could potentially include:<list style="symbols">
<t>control of whether the query string of HTTP URI is to be
ignored by surrogate cache</t>
<t>enforcement of caching directives by Downstream CDN that are
different than the ones signalled in the HTTP headers (e.g.
"Expires" field)</t>
<t>rate-pacing by Downstream CDN for content delivery (e.g.
Progressive Download)</t>
</list></t>
<t>{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: <list style="symbols">
<t>content acquisition for the entire set of files when one
piece of content is requested</t>
<t>local file management and storage bundles all the files for
the content</t>
<t>purging the entire set of files associated with the
content</t>
<t>logging of the delivery of the content for the session when
at least one file in the set was delivered</t>
</list></t>
<t>{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.)</t>
<t>{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.</t>
<t>{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).</t>
<t>{HIGH} The CDNI Metadata interface shall support extensible
format for CDNI metadata delivery from the Upstream CDN to the
Downstream CDN.</t>
</list></t>
</section>
<section title="CDNI Logging Interface Requirements">
<t>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.</t>
<t><list counter="log-reqs" hangIndent="4" style="format LI-%d">
<t>{HIGH} The CDNI logging architecture and interface shall ensure
reliable transfer of CDNI logging information across CDNs.</t>
<t>{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.</t>
<t>{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.</t>
<t>{HIGH} The CDNI Logging interface shall support batch/offline
exchange of logging records.</t>
<t>{MED} The CDNI Logging interface should also support an
additional mechanism taking into account the timing constraints for
some types of logging records (e.g. near-real time for monitoring
and analytics applications).</t>
<t>{HIGH} The CDNI Logging interface shall define a log file format
and a set of fields to be exported for various CDNI logging
events.</t>
<t>{HIGH} The CDNI Logging interface shall define a transport
mechanism to exchange CDNI Logging files.</t>
<t>{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).</t>
<t>{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).</t>
<t>{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.</t>
<t>{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.</t>
<t>{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.</t>
<t>{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.</t>
<t>{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.</t>
<t>{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).</t>
<t>{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.</t>
<t>{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 anonymizes the IP address
carried in the logging field). The use of the privacy protection
mechanism is optional.</t>
</list></t>
</section>
<section anchor="sec" title="CDNI Security Requirements">
<t>This section identifies the requirements related to the CDNI
security. Some of these are expected to affect multiple or all
protocols.</t>
<t><list counter="sec-reqs" hangIndent="4" style="format SEC-%d">
<t>{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.</t>
<t>{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.</t>
<t>{MED} The CDNI solution should be able to ensure that for any
given request redirected to a Downstream CDN, the Downstream CDN can
determine the Upstream CDN that redirected the request directly to
the Downstream CDN (leading to that request being served by that
CDN, or being further redirected).</t>
<t>{MED} The CDNI solution should be able to ensure that for any
given transaction log generated by the Downstream CDN and
communicated to an Upstream CDN, the Upstream CDN can confirm the
transmitted log record corresponds to a request redirection by the
Upstream CDN.</t>
<t>{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).</t>
</list></t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document makes no request of IANA.</t>
<t>Note to RFC Editor: this section may be removed on publication as an
RFC.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>This document discusses CDNI security requirements in <xref
target="sec"/>.</t>
</section>
<section title="Contributors">
<t>This document reflects the contributions from the following
authors:</t>
<t><list style="hanging">
<t hangText="Francois Le Faucheur"/>
<t>Cisco Systems</t>
<t>flefauch@cisco.com</t>
<t hangText="Mahesh Viveganandhan"/>
<t>Cisco Systems</t>
<t>mvittal@cisco.com</t>
<t hangText="Grant Watson"/>
<t>Alcatel-Lucent (Velocix)</t>
<t>gwatson@velocix.com</t>
</list></t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>This document leverages the earlier work of the IETF CDI working
group in particular as documented in <xref
target="I-D.cain-request-routing-req"/>, <xref
target="I-D.amini-cdi-distribution-reqs"/> and <xref
target="I-D.gilletti-cdnp-aaa-reqs"/>.</t>
<t>The authors would like to thank Gilles Bertrand, Christophe Caillet,
Bruce Davie, Phil Eardley, 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.</t>
<t>Ray Brandenburg, Matt Caufield, and Gilles Bertrand provided valuable
inputs for HTTP Adaptive Streaming, CDNI Metadata interface, and CDNI
Logging interface, respectively.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='reference.RFC.6707'?>
<?rfc include='reference.I-D.ietf-cdni-framework'?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.2616"?>
<?rfc include="reference.RFC.4949"?>
<?rfc include='reference.RFC.6770'?>
<?rfc include='reference.I-D.cain-request-routing-req'?>
<?rfc include='reference.I-D.amini-cdi-distribution-reqs'?>
<reference anchor="I-D.gilletti-cdnp-aaa-reqs">
<front>
<title>CDI AAA Requirements,
draft-gilletti-cdnp-aaa-reqs-01.txt</title>
<date month="June" year="2001"/>
<abstract>
<t/>
</abstract>
</front>
</reference>
<reference anchor="ATIS-0800042">
<front>
<title>ATIS IPTV Content on Demand Service,
https://www.atis.org/docstore/product.aspx?id=25670</title>
<date day="8" month="December" year="2010"/>
<abstract>
<t/>
</abstract>
</front>
</reference>
<reference anchor="RTMP">
<front>
<title>Adobe’s Real Time Messaging Protocol,
http://www.adobe.com/content/dam/Adobe/en/devnet/rtmp/pdf/rtmp_specification_1.0.pdf</title>
<date day="21" month="December" year="2012"/>
<abstract>
<t/>
</abstract>
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:09:48 |