One document matched: draft-ietf-cdni-requirements-05.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-05"
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="23" month="February" year="2013"/>
<abstract>
<t>Content Delivery Networks (CDNs) are frequently used for large-scale
content delivery. As a result, existing CDN providers are scaling up
their infrastructure and many Network Service Providers (NSPs) are
deploying their own CDNs. There is a requirement for interconnecting
standalone CDNs so that their collective CDN footprint can be leveraged
for the end-to-end delivery of content from Content Service Providers
(CSPs) to end users. The Content Distribution Network Interconnection
(CDNI) working group has been chartered to develop an interoperable and
scalable solution for such CDN interconnection.</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.
This draft is a work in progress and requirements may be added,
modified, or removed by the working group.</t>
</abstract>
<note title="Requirements Language">
<t>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" indicates requirements that are to be supported
by the CDNI interfaces. A requirement is stated as "High Priority"
when it is established by the working group that it can be met
without compromising the targeted schedule for WG deliverables, or
when it is established that specifying a solution without meeting
this requirement would not make sense and would justify re-adjusting
the WG schedule, or both. This is tagged as "[HIGH]".</t>
<t>"Medium Priority" indicates requirements that are to be supported
by the CDNI interfaces unless the WG realizes at a later stage that
attempting to meet this requirement would compromise the overall WG
schedule (for example it would involve complexities that would
result in significantly delaying the deliverables). This is tagged
as "[MED]".</t>
<t>"Low Priority" indicates requirements that are to be supported by
the CDNI interfaces provided that dedicating WG resources to this
work does not prevent addressing "High Priority" and "Medium
Priority" requirements and that attempting to meet this requirement
would not compromise the overall WG schedule. This is tagged as
"[LOW]".</t>
</list></t>
<t/>
</note>
</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, existing CDN providers are scaling up
their infrastructure and many Network Service Providers (NSPs) are
deploying their own CDNs. It is generally desirable that a given content
item can be delivered to an End User regardless of that End User's
location or attachment network. However, the footprint of a given CDN in
charge of delivering a given content may not expand close enough to the
End User's current location or attachment network to realize the cost
benefit and user experience that a more distributed CDN would provide.
This creates a requirement for interconnecting standalone CDNs so that
their collective CDN footprint can be leveraged for the end-to-end
delivery of content from Content Service Providers (CSPs) to End Users.
The Content Distribution Network Interconnection (CDNI) working group
has been chartered to develop an interoperable and scalable solution for
such CDN interconnection.</t>
<t><xref target="I-D.ietf-cdni-problem-statement"/> outlines the problem
area that the CDNI working group is chartered to address. <xref
target="I-D.ietf-cdni-use-cases"/> discusses the use cases for CDN
Interconnection. <xref target="I-D.davie-cdni-framework"/> 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 section 1.1 of <xref
target="I-D.davie-cdni-framework"/>.</t>
</section>
</section>
<section anchor="cdni-interfaces" title="CDNI Model and CDNI Interfaces">
<t>For convenience Figure 1 from <xref
target="I-D.davie-cdni-framework"/> illustrating the CDNI problem area
and the CDNI protocols is replicated below.</t>
<figure anchor="fig-cdni-model" title="CDNI Model and CDNI Interfaces">
<preamble/>
<artwork> --------
/ \
| CSP |
\ /
--------
*
*
* /\
* / \
---------------------- |CDNI| ----------------------
/ Upstream CDN \ | | / Downstream CDN \
| +-------------+ | Control Interface| +-------------+ |
|******* Control |<======|====|========>| Control *******|
|* +------*----*-+ | | | | +-*----*------+ *|
|* * * | | | | * * *|
|* +------*------+ | Logging Interface| +------*------+ *|
|* ***** Logging |<======|====|========>| Logging ***** *|
|* * +-*-----------+ | | | | +-----------*-+ * *|
|* * * * | Request Routing | * * * *|
.....*...+-*---------*-+ | Interface | +-*---------*-+...*.*...
. |* * *** Req-Routing |<======|====|========>| Req-Routing *** * *| .
. |* * * +-------------+.| | | | +-------------+ * * *| .
. |* * * . CDNI Metadata | * * *| .
. |* * * +-------------+ |. Interface | +-------------+ * * *| .
. |* * * | Distribution|<==.===|====|========>| Distribution| * * *| .
. |* * * | | | . \ / | | | * * *| .
. |* * * |+---------+ | | . \/ | | +---------+| * * *| .
. |* * ***| +---------+| | ....Request......+---------+ |*** * *| .
. |* *****+-|Surrogate|************************|Surrogate|-+***** *| .
. |******* +---------+| | Acquisition | |+----------+ *******| .
. | +-------------+ | | +-------*-----+ | .
. \ / \ * / .
. ---------------------- ---------*------------ .
. * .
. * Delivery .
. * .
. +--*---+ .
...............Request.............................| User |..Request..
| Agent|
+------+
<==> interfaces inside the scope of CDNI
**** interfaces outside the scope of CDNI
.... 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.</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 to benefit from content
delivery through interconnected CDNs.</t>
<t>[HIGH] The CDNI solution shall not require 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 HTTP <xref target="RFC2616"/>. (Note that while delivery
and acquisition "data plane" protocols are out of the CDNI solution
scope, the CDNI solution "control plane" protocols are expected to
participate in enabling, selecting or facilitating operations of
such acquisition and delivery protocols. Hence it is useful to state
requirements on the CDNI solution in terms of which acquisition and
delivery protocols).</t>
<t>[HIGH] The CDNI solution shall support acquisition across CDNs
based on HTTP <xref target="RFC2616"/>.</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 CDN topology cannot be restricted to a
tree, a loop-free topology, 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 litterals,
split DNS situations potentially breaking third-party references
based on DNS fully qualified domain names) and wherever possible
avoid, minimize or mitigate the associated risks based on the
specifics of the environments where the reference is used (e.g.
likely or unlikely presence of NAT in the path). In particular, this
applies to situations where the CDNI solution needs to construct and
convey uniform resource identifiers for directing/redirecting a
content request, as well as to situations where the CDNI solution
needs to pass on a third party reference (e.g. to identify a User
Agent) in order to allow another entity to make a more informed
decision (e.g. make a more informed request routing decision by
attempting to derive location information from the third party
reference).</t>
<t>Removed.<del>[LOW] The CDNI solution should support
virtualization ...</del></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 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). We observe that while the CDNI Control 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="control-reqs" hangIndent="4" style="format CNTL-%d">
<t>[HIGH] The CDNI Control interface shall allow the Upstream CDN to
request that the Downstream CDN (and, if cascaded CDNs are supported
by the solution, that the potential cascaded Downstream CDNs)
perform the following actions on an object or object set: <list
style="symbols">
<t>Mark an object or set of objects and/or its CDNI metadata as
“stale” and revalidate them before they are
delivered again</t>
<t>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>
</list></t>
<t>[HIGH] The CDNI Control interface shall allow the Downstream CDN
to report on the completion of these actions (by itself, and if
cascaded CDNs are supported by the solution, by potential cascaded
Downstream 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 is
used if the Downstream CDN cannot delete the content in its
storage.</t>
<t>[HIGH] The CDNI Control interface shall 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
interconnection between any two CDNs independently for each
direction (i.e. 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
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 Request-Routing protocol endpoints</t>
<t>information necessary to establish secure communication
between the Request-Routing protocol 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 signaling protocol
endpoints</t>
<t>information necessary to establish secure communication
between the CDNI Metadata signaling protocol 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 protocols to be
used across the CDNs (e.g. HTTP, HTTPS, FTP, ATIS C2).</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>[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 Logging protocol endpoints</t>
<t>information necessary to establish secure communication
between the Logging protocol 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>
<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>
</list></t>
</section>
<section title="CDNI Request Routing Interface Requirements">
<t/>
<t>The main function of the Request Routing interface 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-reqs" hangIndent="4" style="format REQ-%d">
<t>[HIGH] The CDNI Request-Routing 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 Request-Routing 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
Request-Routing interface shall 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 Request-Routing 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>[HIGH] The CDNI Request-Routing architecture and 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 architecture and 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 architecture shall support
recursive CDNI request routing.</t>
<t>[HIGH] The CDNI Request-Routing architecture shall support
iterative CDNI request routing.</t>
<t>[MED] In case of detection of a request redirection loop, the
CDNI Request-Routing 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).</t>
<t>[MED] The CDNI Request-Routing protocol should support a
mechanism allowing enforcment of a limit on the number of successive
CDN redirections for a given request.</t>
<t>[LOW] The CDNI Request-Routing protocol 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 protocol 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 location of the user-agent that
originated the request can be inferred (e.g. User Agent fully
qualified domain name in case of HTTP-based Request Routing, DNS
Proxy fully qualified domain name in case of DNS-based Request
Routing)</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 protocol 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 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 interface shall allow for
per-chunk request routing of HTTP Adaptive Streaming content. [Ed:
chunk is treated as any content, is this needed?]</t>
<t>[MED] The CDNI Request-Routing interface should 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. [Ed:should this be LOW?]</t>
<t>[MED] The CDNI Request-Routing interface should allow the
Upstream CDN to re-sign the invariant portion of the chunk URIs
embedded in the HTTP Adaptive Streaming manifest file. [Ed: should
this be LOW?]</t>
<t>[MED] The CDNI Request-routing interface should allow the use of
HTTP cookie to associate the chunks with the HTTP Adaptive Stream
manifest file (which is verified by the URI signature) basedon the
Authorization Group ID (which is an identifier used to correlate the
manifest file to the related chunks). [Ed: should this be LOW?]</t>
<t>[MED] The CDNI Request-Routing interface may 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. [Ed:should this be
LOW?]</t>
<t>[MED] The CDNI Request-Routing/Footprint and Advertising
interface shall support advertisement of the following
capabilities:<list style="symbols">
<t>support for customized CDNI Logging</t>
<t>support of Content Collection ID logging</t>
<t>support for Session ID logging</t>
</list></t>
</list></t>
</section>
<section title="CDNI Metadata Distribution Interface Requirements">
<t>The primary function of the CDNI Metadata Distribution interface 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 META-%d">
<t>[HIGH] The CDNI Metadata Distribution 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 Distribution 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 Distribution 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 Distribution 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
Distribution 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 Distribution interface shall allow the
Upstream CDN to request addition and modification of CDNI Metadata
into the Downstream CDN.</t>
<t>[HIGH] The CDNI Metadata Distribution 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 Distribution 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 Distribution 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 Distribution 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 Distribution interface shall ensure that
conflicting metadata with overlapping scope are prevented or
deterministically handled.</t>
<t>Removed.<del>[HIGH] The CDNI Metadata Distribution interface
shall provide indication by the Downstream CDN to the Upstream CDN
of whether the CDNI metadata (and corresponding future request
redirections) is accepted or rejected. When rejected, the CDNI
Metadata Distribution protocol Must allow the Downstream CDN to
provide information about the cause of the rejection.</del></t>
<t>[HIGH] The CDNI Metadata Distribution 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 well-accepted 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 Distribution 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:<list style="symbols">
<t>need to validate URI signed information (e.g. Expiry time,
Client IP address).</t>
</list></t>
<t>[LOW] The CDNI Metadata Distribution interface may 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>content revalidation parameters (e.g. TTL)</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>[HIGH] The CDNI Metadata Distribution interface shall support an
OPTIONAL mechanism allowing the Upstream CDN to indicate to the
Downstream CDN which CDNI Log fields are to be provided for all, for
specific sets of, or for specific content items delivered using
HTTP. A CDNI implementation that does not support this optional CDNI
Metadata Distribution Interface mechanism MUST ignore this log
format indication and generate CDNI logging format for HTTP Adaptive
Streaming using the default set of CDNI Logging fields.</t>
<t>[MED] The CDNI Metadata Distribution interface shall 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 Distribution interface shall allow the
Upstream CDN to signal to the Downstream CDN the Authorization Group
ID value for all the related HTTP Adaptive Streamin 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). [Ed: need to improve wording?]</t>
</list></t>
</section>
<section title="CDNI Logging Interface Requirements">
<t>This section identifies the requirements related to the CDNI Logging
interface. 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 LOG-%d">
<t>[HIGH] The CDNI logging architecture and interface shall ensure
reliable logging of CDNI events.</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
shall 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>Removed.<del>[HIGH] The CDNI Logging interface shall provide
logging of distribution performed by the Upstream CDN as a result of
acquisition request by the Downstream CDN.</del></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 additional
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 through the Logging protocol,
with some granularity (e.g. On a per content type basis).</t>
<t>[HIGH] The CDNI Logging interface shall define a transport
mechanisms 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 shall 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
shall 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 extensibility to
allow proprietary information fields to be carried. These
information fields must be agreed upon ahead of time between the
corresponding CDNs.</t>
<t>[HIGH] The CDNI Logging interface shall support the exchange of
extensible log file formats to support proprietary information
fields. These information fields must be agreed upon ahead of time
between the corresponding CDNs.</t>
<t>[HIGH] The CDNI Logging interface shall support the notification
from Downstream CDN to Upstream CDN for the event that the logging
retention duration or maximum size of logging data has exceeded.</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. This fields can be supported by the "customizable" log
format which is expected to be defined independently of HTTP
Adaptive Streaming.</t>
</list></t>
</section>
<section anchor="sec" title="CDNI Security Requirements">
<t>This section identifies the requirements related to the CDNI
security. Some of those 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 chain of CDN
Delegation (leading to that request being served by that CDN) can be
established with non-repudiation.</t>
<t>[MED] The CDNI solution should be able to ensure that the
Downstream CDN cannot spoof a transaction log attempting to appear
as if it corresponds to a request redirected by a given Upstream CDN
when that request has not been redirected by this Upstream CDN. This
ensures non-repudiation by the Upstream CDN of transaction logs
generated by the Downstream CDN for deliveries performed by the
Downstream CDN on behalf of 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="Authors">
<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>BT</t>
<t>grant.watson@bt.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 Eardly, Ben Niven-Jenkins, Agustin Schapira, Emile
Stephan, Eric Burger, Susan He, Kevin Ma, and Daryl Malas 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 Francois Le Faucheur/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 ?>
<?rfc include='reference.I-D.ietf-cdni-problem-statement'
?>
<?rfc include='reference.I-D.ietf-cdni-use-cases'
?>
<?rfc include="reference.RFC.2616"?>
<?rfc include='reference.I-D.davie-cdni-framework'
?>
<?rfc ?>
<?rfc ?>
</references>
<references title="Informative References">
<?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>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:09:54 |