Network Working Group F. Le Faucheur
Internet-Draft M. Viveganandhan
Intended status: Informational Cisco
Expires: September 15, 2011 G. Watson
BT
Y. Lee
Comcast
March 14, 2011
Content Distribution Network Interconnection (CDNI) Requirements
draft-lefaucheur-cdni-requirements-01
Abstract
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. However, no standards or open
specifications currently exist to facilitate such CDN
interconnection.
The "CDN Interconnect Problem Statement" Internet-Draft outlines the
problem area for the IETF with a view towards creating a working
group. This working group would work on an interoperable and
scalable solution for CDN interconnection. The goal of the present
document is to start outlining the requirements for such a "CDN
Interconnection" solution.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Le Faucheur, et al. Expires September 15, 2011 [Page 1]
Internet-Draft CDNI Requirements March 2011
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 15, 2011.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Le Faucheur, et al. Expires September 15, 2011 [Page 2]
Internet-Draft CDNI Requirements March 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. CDNI Model and CDNI protocols . . . . . . . . . . . . . . . . 5
3. Generic Requirements . . . . . . . . . . . . . . . . . . . . . 7
3.1. Within Initial CDNI Scope . . . . . . . . . . . . . . . . 7
3.2. Beyond Initial CDNI Scope . . . . . . . . . . . . . . . . 8
4. CDNI Control Protocol Requirements . . . . . . . . . . . . . . 8
4.1. Within Initial CDNI Scope . . . . . . . . . . . . . . . . 9
4.2. Beyond Initial CDNI Scope . . . . . . . . . . . . . . . . 9
5. CDNI Request Routing Protocol Requirements . . . . . . . . . . 11
5.1. Within Initial CDNI Scope . . . . . . . . . . . . . . . . 11
5.2. Beyond Initial CDNI Scope . . . . . . . . . . . . . . . . 13
6. CDNI Metadata Distribution Protocol Requirements . . . . . . . 15
6.1. Within Initial CDNI Scope . . . . . . . . . . . . . . . . 15
6.2. Beyond Initial CDNI Scope . . . . . . . . . . . . . . . . 17
7. CDNI Logging Protocol Requirements . . . . . . . . . . . . . . 18
7.1. Within Initial CDNI Scope . . . . . . . . . . . . . . . . 18
7.2. Beyond Initial CDNI Scope . . . . . . . . . . . . . . . . 19
8. CDNI Security Requirements . . . . . . . . . . . . . . . . . . 19
8.1. Within Initial CDNI Scope . . . . . . . . . . . . . . . . 19
8.2. Beyond Initial CDNI Scope . . . . . . . . . . . . . . . . 20
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
10. Security Considerations . . . . . . . . . . . . . . . . . . . 20
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
12.1. Normative References . . . . . . . . . . . . . . . . . . . 21
12.2. Informative References . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Le Faucheur, et al. Expires September 15, 2011 [Page 3]
Internet-Draft CDNI Requirements March 2011
1. Introduction
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. However, no standards or open specifications currently
exist to facilitate such CDN interconnection.
[I-D.jenkins-cdni-problem-statement] outlines the problem area for
the IETF with a view towards creating a working group. This working
group would work on interoperable and scalable solutions for CDN
interconnection. [I-D.bertrand-cdni-use-cases] discusses the use
cases for CDN Interconnection.
The goal of the present document is to outline the requirements for
such a "CDN Interconnection" solution. As discussed in section 5 of
[I-D.jenkins-cdni-problem-statement] in order to manage the potential
workload of a CDNI WG, it is recommended that the work be prioritized
in a "walk before you run" approach. In line with that approach, the
present document makes a first attempt at separating the CDNI
requirements into a set of more urgent requirements that would be
within the initial scope of a potential CDNI Working Group, and a set
of less urgent additional requirements that would be left to future
rechartering of the potential WG. This is intended to facilitate
discussion and convergence on requirements prioritization in view of
progressing the definition of a potential Working Group charter.
1.1. Terminology
This document uses the terminology defined in section 1.1 of
[I-D.jenkins-cdni-problem-statement].
This also defined the following additionnal terms [Editor's Note:
Le Faucheur, et al. Expires September 15, 2011 [Page 4]
Internet-Draft CDNI Requirements March 2011
these definitions may be better located in another document such as
the Problem Statement]:
o Recursive CDNI request routing: When an Upstream CDN elects to
redirect a request towards a Downstream CDN, the Upstream CDN can
query the Downstream CDN Request Routing system via the CDNI
Request Routing protocol (or use information cached from earlier
similar queries) to find out how the Downstream CDN wants the
request to be redirected, which allows the Upstream CDN to factor
in the Downstream CDN response when redirecting the user agent.
This approach is referred to as "recursive" CDNI request routing.
Note that the Downstream CDN may elect to have the request
redirected directly to a Surrogate inside the Downstream CDN, to
the Request-Routing System of the Downstream CDN, to another CDN,
or to any other system that the Downstream CDN sees as fit for
handling the redirected request.
o Iterative CDNI Request Routing: When an Upstream CDN elects to
redirect a request towards a Downstream CDN, the Upstream CDN can
base its redirection purely on a local decision (and without
attempting to take into account how the Downstream CDN may in turn
redirect the user agent). In that case, the Upstream CDN
redirects the request to the request routing system in the
Downstream CDN, which in turn will decide how to redirect that
request: this approach is referred to as "iterative" CDNI request
routing.
2. CDNI Model and CDNI protocols
For convenience Figure 1 from [I-D.jenkins-cdni-problem-statement]
illustrating the CDNI problem area and the CDNI protocols is
replicated below.
Le Faucheur, et al. Expires September 15, 2011 [Page 5]
Internet-Draft CDNI Requirements March 2011
--------
/ \
| CSP |
\ /
--------
*
*
* /\
* / \
--------------------- |CDNI| ---------------------
/ Upstream CDN \ | | / Downstream CDN \
| +-------------+ | Control protocol| +-------------+ |
| |CDN Control |<======|====|=======>| CDN Control | |
| +------*-*-*--+ | | | | +-*-*-*-------+ |
| * * * | | | | * * * |
| +------*------+ | Logging protocol| +-----*-------+ |
| ****| Logging |<======|====|=======>| Logging |**** |
| * --------------+ | | | | +-------------+ * |
| * * * | Request Routing | * * * |
....*...+--------*----+ | protocol | +---*---------+...*.....
. | * **|Req-Routing |<======|====|=======>| Req-Routing |** * | .
. | * * +-------------+ | | | | +-------------+ * * | .
. | * * * | CDNI Metatdata | * * * | .
. | * * +----------*--+ | protocol | +-*-----------+ * * | .
. | * * |Distribution |<======|====|=======>| Distribution| * * | .
. | * * | | | \ / | | | * * | .
. | * * | | | \/ | | | * * | .
. | * ****+---------+ | | | | +---------+**** * | .
. | ******|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
Figure 1: CDNI Model and CDNI APIs
Le Faucheur, et al. Expires September 15, 2011 [Page 6]
Internet-Draft CDNI Requirements March 2011
3. Generic Requirements
This section identifies generic requirements independent of the
individual CDNI protocols. Some of those are expected to affect
multiple or all protocols.
3.1. Within Initial CDNI Scope
R1 Wherever possible, the CDNI protocols SHOULD reuse or leverage
existing IETF protocols.
R2 The CDNI solution MUST NOT require a change, or an upgrade, to
the User Agent to benefit from content delivery through
interconnected CDNs.
R3 The CDNI solution MUST 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.
R4 The CDNI solution MUST support delivery to the user agent based
on HTTP [RFC2616]. [Note that while delivery and acquisition
"data plane" protocols are out of the CDNI solution scope, the
CDNI solution "control plane" protocols are expected to
participate in enabling, selecting or facilitating operations of
such acquisition and delivery protocols. Hence it is useful to
state requirements on the CDNI solution in terms of which
acquisition and delivery protocols].
R5 The CDNI solution MUST support acquisition across CDNs based on
HTTP [RFC2616].
R6 The CDNI solution MAY support delivery to the user agent based
on protocols other than HTTP.
R7 The CDNI solution MAY support acquisition across CDNs based on
protocols other than HTTP.
R8 The CDNI solution SHOULD support cascaded CDN redirection (CDN1
redirects to CDN2 that redirects to CDN3) to an arbitrary number
of levels.
R9 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.).
Le Faucheur, et al. Expires September 15, 2011 [Page 7]
Internet-Draft CDNI Requirements March 2011
R10 The CDNI solution MUST prevent looping of any CDNI information
exchange.
R11 When making use of third party reference, the CDNI solution MUST
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).
3.2. Beyond Initial CDNI Scope
R12 The CDNI solution MUST support cascaded CDN redirection (CDN1
redirects to CDN2 that redirects to CDN3) to an arbitrary number
of levels. [Note: this "MUST" requirement appeared as a
"SHOULD" requirement in Section 3.1]
R13 The CDNI solution MUST support an arbitrary topology of
interconnected CDNs (i.e. the CDN topology cannot be restricted
to a tree, a loop-free topology, etc.). [Note: this "MUST"
requirement appeared as a "SHOULD" requirement in Section 3.1]
R14 The CDNI solution SHOULD support virtualization of the
Downstream CDN, so that the Downstream CDN can appear as
multiple logical Downstream CDNs.
4. CDNI Control Protocol Requirements
The primary purpose of the CDNI Control protocol 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 protocol is
currently discussed as a single "protocol", further analysis will
determine whether the corresponding requirements are to be realized
Le Faucheur, et al. Expires September 15, 2011 [Page 8]
Internet-Draft CDNI Requirements March 2011
over a single interface and protocol, or over multiple interfaces and
protocols.
4.1. Within Initial CDNI Scope
R15 The CDNI Control protocol MUST 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:
* Mark an object(s) and/or its CDNI metadata as "stale" and
revalidate them before they are delivered again
* Delete an object(s) and/or its CDNI metadata from the CDN
surrogates and any storage.
R16 The CDNI Control protocol MUST 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).
R17 The CDNI Control protocol MUST support initiation and control by
the Upstream CDN of pre-positioned CDNI metadata acquisition by
the Downstream CDN.
R18 The CDNI Control protocol SHOULD support initiation and control
by the Upstream CDN of pre-positioned content acquisition by the
Downstream CDN.[Editor's Note: how much influence the Upstream
CDN ought to have on pre-positioning of the content on
surrogates inside the Downstream CDN is TBD].
4.2. Beyond Initial CDNI Scope
R19 The CDNI Control protocol MUST support support initiation and
control by the Upstream CDN of pre-positioned content
acquisition.[Editor's Note: how much influence the Upstream CDN
ought to have on pre-positioning of the content on surrogates
inside the Downstream CDN is TBD]. [Note: this "MUST"
requirement appeared as a "SHOULD" requirement in Section 4.1]
R20 The CDNI Control protocol MUST 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).
Le Faucheur, et al. Expires September 15, 2011 [Page 9]
Internet-Draft CDNI Requirements March 2011
R21 The CDNI Control protocol MUST 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).
R22 The CDNI Control protocol SHOULD allow bootstrapping of the
Request-Routing protocol. For example, this can potentially
include:
* negotiation of the Request-Routing method (e.g. DNS vs
HTTP, if more than one method is specified)
* discovery of the Request-Routing protocol endpoints
* information necessary to establish secure communication
between the Request-Routing protocol endpoints.
R23 The CDNI Control protocol SHOULD allow bootstrapping of the
Metadata Signaling protocol. This information could, for
example, include:
* discovery of the Metadata Signaling protocol endpoints
* information necessary to establish secure communication
between the Metadata Signaling protocol endpoints.
R24 The CDNI Control protocol SHOULD allow bootstrapping of the
Content Acquisition protocol. 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).
R25 The CDNI Control protocol SHOULD allow exchange and negotiation
of delivery authorization mechanisms to be supported across the
CDNs (e.g. URI signature based validation).
R26 The CDNI Control protocol SHOULD allow bootstrapping of the CDNI
Logging protocol. This information could, for example, include:
* discovery of the Logging protocol endpoints
* information necessary to establish secure communication
between the Logging protocol endpoints
* negotiation/definition of the log file format and set of
fields to be exported through the Logging protocol, with
some granularity (e.g. On a per content type basis).
Le Faucheur, et al. Expires September 15, 2011 [Page 10]
Internet-Draft CDNI Requirements March 2011
* negotiation/definition of parameters related to transaction
Logs export (e.g., export protocol, file compression, export
frequency, directory).
5. CDNI Request Routing Protocol Requirements
5.1. Within Initial CDNI Scope
The main function of the Request Routing protocol is to allow the
Request-Routing systems in interconnected CDNs to communicate to
facilitate redirection of the request across CDNs.
R27 The CDNI Control protocol MUST 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.
R28 The CDNI Request-Routing protocol SHOULD allow the Downstream
CDN to communicate to the Upstream CDN aggregate information to
facilitate CDN selection during request routing, such as
Downstream CDN capabilities, resources and affinities (i.e.
Preferences or cost). This information could, for example,
include:
* supported content types and delivery protocols
* footprint (e.g. layer-3 coverage)
* a set of metrics/attributes (e.g. Streaming bandwidth,
storage resources, distribution and delivery priority)
* a set of affinities (e.g. Preferences, indication of
distribution/delivery fees)
* information to facilitate request redirection (e.g.
Reachability information of Downstream CDN Request Routing
system).
[Note: Some of this information - such as supported content
types and delivery protocols- may also potentially be taken into
account by the distribution system in the Upstream CDN for pre-
positioning of content and/or metadata in the Downstream CDN in
case of pre-positioned content acquisition and/or pre-positioned
CDNI metadata acquisition.]
Le Faucheur, et al. Expires September 15, 2011 [Page 11]
Internet-Draft CDNI Requirements March 2011
R29 If cascaded redirection is supported by the CDNI solution, the
CDNI Request-Routing protocol MUST 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 protocol MUST prevent looping of such
information exchange.
R30 The CDNI Control protocol MAY allow the Downstream CDN to
communicate to the Upstream CDN aggregate information on CDNI
administrative limits and policy. This information can be taken
into account by the Upstream CDN Request Routing system in its
CDN Selection decisions. This information could, for example,
include:
* maximum number of requests redirected by the Upstream CDN to
be served simultaneously by the Downstream CDN
* maximum aggregate volume of content (e.g. in Terabytes) to
be delivered by the Downstream CDN over a time period.
R31 The CDNI Request-Routing architecture and protocol MUST 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).
R32 The CDNI Request-Routing architecture and protocol MUST 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.
R33 The CDNI Request-Routing architecture MUST support recursive
CDNI request routing.
R34 The CDNI Request-Routing architecture MUST support iterative
CDNI request routing.
R35 In case of detection of a request redirection loop, the CDNI
Request-Routing loop prevention mechanism SHOULD allow routing
of the request (as opposed to the request loop being simply
interrupted without routing the request).
Le Faucheur, et al. Expires September 15, 2011 [Page 12]
Internet-Draft CDNI Requirements March 2011
R36 The CDNI Request-Routing protocol SHOULD support an optional
mechanism enforcing a limit on the number of successive CDN
redirections for a given request.
R37 The CDNI Request-Routing protocol MUST allow the Upstream CDN to
include, in the query to the Downstream CDN, the necessary
information to allow the Downstream CDN to process the
redirection query. This could, for example, include:
* information from which the location of the user-agent that
originated the request can be infered (e.g. User Agent
fully qualified domain name in case of HTTP-based Request
Routing, DNS Proxy fully qualified domain name in case of
DNS-based Request Routing)
* requested resource information (e.g. Resource URI in case
of HTTP-based Request Routing, Resource hostname in case of
DNS-based Request Routing)
* additional available request information (e.g. request
headers in case of HTTP-based Request Routing).
R38 The CDNI Request-Routing protocol MAY also allow the Upstream
CDN to convey information pointing to CDNI metadata associated
with the requested content.
R39 The CDNI Request-Routing protocol MUST allow the Downstream CDN
to include the following information in the response to the
Upstream CDN:
* status code, in particular indicating acceptance or
rejection of request (e.g. Because the Downstream CDN is
unwilling or unable to serve the request). In case of
rejection, an error code is also to be provided, which
allows the Upstream CDN to react appropriately (e.g. Select
another Downstream CDN, or serve the request itself)
* redirection information (e.g. Resource URI in case of HTTP-
based Request Routing, equivalent of a DNS record in case of
DNS-based Request Routing).
5.2. Beyond Initial CDNI Scope
R40 The CDNI Request-Routing protocol MUST 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,
Le Faucheur, et al. Expires September 15, 2011 [Page 13]
Internet-Draft CDNI Requirements March 2011
include:
* supported content types and delivery protocols
* footprint (e.g. layer-3 coverage)
* a set of metrics/attributes (e.g. Streaming bandwidth,
storage resources, distribution and delivery priority)
* a set of affinities (e.g. Preferences, indication of
distribution/delivery fees)
* information to facilitate request redirection (e.g.
Reachability information of Downstream CDN Request Routing
system).
[Note: this "MUST" requirement appeared as a "SHOULD"
requirement in Section 5.1]
R41 The CDNI Request-Routing protocol MUST 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. The CDNI Control
protocol MUST prevent looping of such information exchange.
[Note: this "MUST" requirement appeared as a conditional "MUST"
requirement in Section 5.1]
R42 The CDNI Request-Routing protocol SHOULD allow the Downstream
CDN to communicate to the Upstream CDN aggregate information on
CDNI administrative limits and policy. This information can be
taken into account by the Upstream CDN Request Routing system in
its CDN Selection decisions. This information could, for
example, include:
* maximum number of requests redirected by the Upstream CDN
that to be served simultaneously by the Downstream CDN
* maximum aggregate volume of content (e.g. in Terabytes) to
be delivered by the Downstream CDN over a time period
[Note: this "SHOULD" requirement appeared as a "MAY" requirement
in Section 5.1]
R43 The CDNI Request-Routing loop prevention mechanism MUST allow
routing of the request (as opposed to the request loop being
simply interrupted without routing the request). [Note: this
"MUST" requirement appeared as a "SHOULD" requirement in
Le Faucheur, et al. Expires September 15, 2011 [Page 14]
Internet-Draft CDNI Requirements March 2011
Section 5.1]
R44 The CDNI Request-Routing protocol MUST support optional
enforcement of a limit on the number of successive CDN
redirections for a given request. [Note: this "MUST"
requirement appeared as a "SHOULD" requirement in Section 5.1]
6. CDNI Metadata Distribution Protocol Requirements
The primary function of the CDNI Metadata Distribution protocol 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).
6.1. Within Initial CDNI Scope
R45 The CDNI Metadata Distribution protocol MUST allow the Upstream
CDN to provide the Downstream CDN with content distribution
metadata of inter-CDN scope.
R46 The CDNI Metadata Distribution protocol MUST support exchange of
CDNI metadata for both the dynamic content acquisition model and
the pre-positioning content acquisition model.
R47 The CDNI Metadata Distribution protocol MUST/SHOULD/MAY? 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).
R48 The CDNI Metadata Distribution protocol MUST/SHOULD/MAY? support
a mode where all the relevant Metadata is initially communicated
to the Downstream CDN (i.e. Pre-positioned CDNI metadata
acquisition).
R49 Whether in the pre-positioned content acquisition model or in
the dynamic content acquisition model, the CDNI Metadata
Distribution protocol MUST provide the necessary information to
allow the Downstream CDN to acquire the content from an upstream
Le Faucheur, et al. Expires September 15, 2011 [Page 15]
Internet-Draft CDNI Requirements March 2011
source (e.g. Acquisition protocol and Uniform Resource
Identifier in Upstream CDN- or rules to construct this URI).
R50 The CDNI metadata MUST 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.
R51 The CDNI Metadata Distribution protocol MUST allow the Upstream
CDN to request addition and modification of CDNI Metadata into
the Downstream CDN.
R52 The CDNI Metadata Distribution protocol MUST 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).
R53 The CDNI Metadata Distribution protocol MUST 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.
R54 The CDNI Metadata Distribution protocol MUST 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.
R55 The CDNI Metadata Distribution protocol MUST 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.
R56 The CDNI Metadata Distribution protocol MUST ensure that
conflicting metadata with overlapping scope are prevented or
deterministically handled.
Le Faucheur, et al. Expires September 15, 2011 [Page 16]
Internet-Draft CDNI Requirements March 2011
R57 The CDNI Metadata Distribution protocol MUST 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.
R58 The CDNI Metadata Distribution protocol MUST allow signaling of
content distribution control policies. For example, this could
potentially include:
* geo-blocking information (i.e. Information defining
geographical areas where the content is to be made available
or blocked)
* availability windows (i.e. Information defining time
windows during which the content is to be made available or
blocked)
R59 The CDNI Metadata Distribution protocol MUST allow signaling of
authorization checks and validation that are to be performed by
the surrogate before delivery. For example, this could
potentially include:
* need to validate URI signed information (e.g. Expiry time,
Client IP address).
6.2. Beyond Initial CDNI Scope
R60 The CDNI Metadata Distribution protocol MUST 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). [Note: this "MUST" requirement appeared
as a "MUST/SHOULD/MAY?" requirement in Section 6.1]
R61 The CDNI Metadata Distribution protocol MUST support a mode
where all the relevant Metadata is initially communicated to the
Downstream CDN (i.e.Pre-positioned CDNI metadata acquisition).
[Note: this "MUST" requirement appeared as a "MUST/SHOULD/MAY?"
requirement in Section 6.1]
R62 The CDNI Metadata Distribution protocol MUST allow signaling of
CDNI-relevant surrogate cache behavior parameters. For example,
this could potentially include:
* control of whether the query string of HTTP URI is to be
ignored by surrogate cache
Le Faucheur, et al. Expires September 15, 2011 [Page 17]
Internet-Draft CDNI Requirements March 2011
* content revalidation parameters (e.g. TTL)
7. CDNI Logging Protocol Requirements
This section identifies the requirements related to the CDNI Logging
protocol. We observe that while the CDNI Logging 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.
7.1. Within Initial CDNI Scope
R63 The CDNI logging architecture and protocol MUST ensure reliable
logging of CDNI events.
R64 The CDNI Logging protocol MUST provide logging of deliveries to
User Agents performed by the Downstream CDN as a result of
request redirection by the Upstream CDN.
R65 If cascaded CDNs are supported, the CDNI logging protocol MUST
allow the Downstream CDN to report to the Upstream CDN logging
for deliveries performed by the Downstream CDN itself as well as
logging for deliveries performed by cascaded CDNs on behalf of
the Downstream CDN.
R66 The CDNI Logging protocol MUST provide logging of distribution
performed by the Upstream CDN as a result of acquisition request
by the Downstream CDN.
R67 The CDNI Logging protocol MUST support batch/offline exchange of
logging records.
R68 The CDNI Logging protocol SHOULD also support additional timing
constraints for some types of logging records (e.g. near-real
time for monitoring and analytics applications)
R69 The CDNI Logging protocol MUST 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).
R70 The CDNI Logging protocol MUST define a transport mechanisms to
exchange CDNI Logging files.
[Editor's note: should we add a requirement for support of aggregate/
summarized logs (e.g. total bytes delivered for a content regardless
of individual USer Agents to which it was delivered)]
Le Faucheur, et al. Expires September 15, 2011 [Page 18]
Internet-Draft CDNI Requirements March 2011
7.2. Beyond Initial CDNI Scope
R71 The CDNI logging protocol MUST allow the Downstream CDN to
report to the Upstream CDN logging for deliveries performed by
the Downstream CDN itself as well as logging for deliveries
performed by cascaded CDNs on behalf of the Downstream CDN.
[Note: this "MUST" requirement appeared as a conditional "MUST"
requirement in Section 7.1]
R72 The CDNI Logging protocol MUST support real-time exchange of
some types of logging records (e.g. For real-time monitoring of
deliveries across CDNs). [Note: this "MUST" requirement
appeared as a "SHOULD" requirement in Section 7.1]
R73 The CDNI Logging protocol MUST allow a CDN to query another CDN
for relevant current logging records (e.g. For on-demand access
to real-time logging information).
8. CDNI Security Requirements
This section identifies the requirements related to the CDNI
security. Some of those are expected to affect multiple or all
protocols.
8.1. Within Initial CDNI Scope
R74 All the CDNI protocols MUST 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.
R75 The CDNI solution MUST 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.
R76 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.
R77 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
Le Faucheur, et al. Expires September 15, 2011 [Page 19]
Internet-Draft CDNI Requirements March 2011
generated by the Downstream CDN for deliveries performed by the
Downstream CDN on behalf of the Upstream CDN.
R78 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).
8.2. Beyond Initial CDNI Scope
R79 The CDNI solution MUST 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). [Note: this "MUST"
requirement appeared as a "MAY" requirement in Section 8.1]
9. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
10. Security Considerations
This document discusses CDNI security requirements in Section 8.
11. Acknowledgements
This document leverages the earlier work of the IETF CDI Working
group in particular as documented in [I-D.cain-request-routing-req],
[I-D.amini-cdi-distribution-reqs] and [I-D.gilletti-cdnp-aaa-reqs].
The authors would like to thank Gilles Bertrand, Christophe Caillet,
Bruce Davie, Phil Eardly, Agustin Schapira and Emile Stephan for
their input. We also want to thank Ben Niven-Jenkins for his review
and comments.
12. References
Le Faucheur, et al. Expires September 15, 2011 [Page 20]
Internet-Draft CDNI Requirements March 2011
12.1. Normative References
[I-D.bertrand-cdni-use-cases]
Bertrand, G., Stephan, E., Watson, G., Burbridge, T., and
P. Eardley, "Use Cases for Content Distribution Network
Interconnection", draft-bertrand-cdni-use-cases-01 (work
in progress), January 2011.
[I-D.jenkins-cdni-problem-statement]
Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content
Distribution Network Interconnection (CDNI) Problem
Statement", draft-jenkins-cdni-problem-statement-02 (work
in progress), March 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
12.2. Informative References
[I-D.amini-cdi-distribution-reqs]
Amini, L., "Distribution Requirements for Content
Internetworking", draft-amini-cdi-distribution-reqs-02
(work in progress), November 2001.
[I-D.cain-request-routing-req]
Cain, B., "Request Routing Requirements for Content
Internetworking", draft-cain-request-routing-req-03 (work
in progress), November 2001.
[I-D.gilletti-cdnp-aaa-reqs]
"CDI AAA Requirements,
draft-gilletti-cdnp-aaa-reqs-01.txt", June 2001.
[RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web
Replication and Caching Taxonomy", RFC 3040, January 2001.
[RFC3466] Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model
for Content Internetworking (CDI)", RFC 3466,
February 2003.
[RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known
Content Network (CN) Request-Routing Mechanisms",
RFC 3568, July 2003.
Le Faucheur, et al. Expires September 15, 2011 [Page 21]
Internet-Draft CDNI Requirements March 2011
[RFC3570] Rzewski, P., Day, M., and D. Gilletti, "Content
Internetworking (CDI) Scenarios", RFC 3570, July 2003.
Authors' Addresses
Francois Le Faucheur
Cisco Systems
Greenside, 400 Avenue de Roumanille
Sophia Antipolis 06410
France
Phone: +33 4 97 23 26 19
Email: flefauch@cisco.com
Mahesh Viveganandhan
Cisco Systems
375 East Tasman Drive
San Jose 95134
USA
Email: mvittal@cisco.com
Grant Watson
BT
Email: grant.watson@bt.com
Yiu Lee
Comcast
Email: yiu_lee@cable.comcast.com
Le Faucheur, et al. Expires September 15, 2011 [Page 22]