Network Working Group F. Le Faucheur
Internet-Draft M. Viveganandhan
Intended status: Informational Cisco
Expires: July 30, 2011 G. Watson
BT
Y. Lee
Comcast
January 26, 2011
Content Distribution Network Interconnection (CDNI) Requirements
draft-lefaucheur-cdni-requirements-00
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 July 30, 2011 [Page 1]
Internet-Draft CDNI Requirements January 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 July 30, 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 July 30, 2011 [Page 2]
Internet-Draft CDNI Requirements January 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. CDNI Model and CDNI APIs . . . . . . . . . . . . . . . . . . . 5
3. Generic Requirements . . . . . . . . . . . . . . . . . . . . . 7
3.1. Within Initial CDNI Scope . . . . . . . . . . . . . . . . 7
3.2. Beyond Initial CDNI Scope . . . . . . . . . . . . . . . . 7
4. CDNI Control API Requirements . . . . . . . . . . . . . . . . 8
4.1. Within Initial CDNI Scope . . . . . . . . . . . . . . . . 8
4.2. Beyond Initial CDNI Scope . . . . . . . . . . . . . . . . 9
5. Request Routing API Requirements . . . . . . . . . . . . . . . 12
5.1. Within Initial CDNI Scope . . . . . . . . . . . . . . . . 12
5.2. Beyond Initial CDNI Scope . . . . . . . . . . . . . . . . 14
6. CDNI Metadata API Requirements . . . . . . . . . . . . . . . . 14
6.1. Within Initial CDNI Scope . . . . . . . . . . . . . . . . 15
6.2. Beyond Initial CDNI Scope . . . . . . . . . . . . . . . . 17
7. CDNI Logging API Requirements . . . . . . . . . . . . . . . . 18
7.1. Within Initial CDNI Scope . . . . . . . . . . . . . . . . 18
7.2. Beyond Initial CDNI Scope . . . . . . . . . . . . . . . . 18
8. CDNI Security Requirements . . . . . . . . . . . . . . . . . . 19
8.1. Within Initial CDNI Scope . . . . . . . . . . . . . . . . 19
8.2. Beyond Initial CDNI Scope . . . . . . . . . . . . . . . . 19
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
10. Security Considerations . . . . . . . . . . . . . . . . . . . 20
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
12.1. Normative References . . . . . . . . . . . . . . . . . . . 20
12.2. Informative References . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Le Faucheur, et al. Expires July 30, 2011 [Page 3]
Internet-Draft CDNI Requirements January 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.watson-cdni-use-cases] and
[I-D.bertrand-cdni-use-cases] discuss 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].
Le Faucheur, et al. Expires July 30, 2011 [Page 4]
Internet-Draft CDNI Requirements January 2011
2. CDNI Model and CDNI APIs
For convenience Figure 1 from [I-D.jenkins-cdni-problem-statement]
illustrating the CDNI problem area and the CDNI APIs is replicated
below.
Le Faucheur, et al. Expires July 30, 2011 [Page 5]
Internet-Draft CDNI Requirements January 2011
--------
/ \
| CSP |
\ /
--------
*
*
* /\
* / \
--------------------- |CDNI| ---------------------
/ Upstream CDN \ | | / Downstream CDN \
| +-------------+ | Control API | +-------------+ |
| |CDN Control |<======|====|=======>| CDN Control | |
| +------*-*-*--+ | | | | +-*-*-*-------+ |
| * * * | | | | * * * |
| +------*------+ | Logging API | +-----*-------+ |
| ****| Logging |<======|====|=======>| Logging |**** |
| * --------------+ | | | | +-------------+ * |
| * * * | | | | * * * |
| * +--------*----+ | Req-Routing API | +---*---------+ * |
| * **|Req-Routing |<======|====|=======>| Req-Routing |** * |
| * * +-------------+ | | | | +-------------+ * * |
| * * * | | | | * * * |
| * * +----------*--+ |CDNI Metadata API| +-*-----------+ * * |
| * * |Distribution |<======|====|=======>| Distribution| * * |
| * * | | | \ / | | | * * |
| * * | | | \/ | | | * * |
| * ****+---------+ | | | | +---------+**** * |
| ******|Surrogate|*************************|Surrogate|****** |
| | +---------+ | | Acquisition | | +-----*---+ | |
| +-------------+ | | +-------*-----+ |
\ / \ * /
--------------------- ---------*-----------
*
* Delivery
*
+------+
| User |
| Agent|
+------+
<==> interfaces inside the scope of CDNI
**** interfaces outside the scope of CDNI
Figure 1: CDNI Model and CDNI APIs
Le Faucheur, et al. Expires July 30, 2011 [Page 6]
Internet-Draft CDNI Requirements January 2011
3. Generic Requirements
This section identifies generic requirements independent of the
individual CDNI APIs. Some of those are expected to affect multiple
or all APIs.
3.1. Within Initial CDNI Scope
R1 Wherever possible, the CDNI APIs 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 to expose the intra-CDN
information across CDNs (e.g. Surrogates topology, surrogates
status, cached content, ...) for effective and efficient delivery
of the content.
R4 The CDNI solution MUST support delivery to the user agent based
on HTTP [ RFC 3040 [RFC2616]].
R5 The CDNI solution MUST support acquisition across CDNs based on
HTTP [ RFC 3040 [RFC2616]].
R6 The CDNI solution MAY support delivery to the user agent based on
other protocols than HTTP.
R7 The CDNI solution MAY support acquisition across CDNs based on
other protocols 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.).
3.2. Beyond Initial CDNI Scope
R10 The CDNI solution MUST support cascaded CDN redirection (CDN1
redirects to CDN2 that redirects to CDN3) to an arbitrary number
of levels.
Le Faucheur, et al. Expires July 30, 2011 [Page 7]
Internet-Draft CDNI Requirements January 2011
R11 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.).
4. CDNI Control API Requirements
The primary purpose of the CDNI Control API is to initiate the
interconnection across CDNs and bootstrap the other CDNI interfaces.
We observe that while the CDNI Control API is currently discussed as
a single "API", further analysis will determine whether the
corresponding requirements are to be realized over a single interface
and protocol, or over multiple interfaces and protocols.
4.1. Within Initial CDNI Scope
R12 The CDNI Control API 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.
R13 The CDNI Control API SHOULD allow the Downstream CDN to
communicate to the Upstream CDN aggregate information on the
Downstream CDN capabilities, resources and affinities (i.e.
Preferences or cost). 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:
* 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).
[Editor's note: this functionality is currently described in
draft-jenkins-cdni-problem-statement-01 under the Control API.
Should it be moved under the Request-Routing API since it is
about exchange of information that is to be consumed by the
Request-Routing system to facilitate its request routing
Le Faucheur, et al. Expires July 30, 2011 [Page 8]
Internet-Draft CDNI Requirements January 2011
decisions?].
R14 If cascaded redirection is supported by the CDNI solution, the
CDNI Control API 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 Control API MUST
prevent looping of information exchange.
R15 The CDNI Control API 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 his 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
R16 The CDNI Control API MUST allow the Upstream CDN to request the
Downstream CDN (and potential cascaded Downstream CDNs - if
cascaded CDNs are supported by the solution) to interrupt
delivery of an object (or object set) and trigger specific cache
actions or behaviors in the Downstream CDN surrogates (e.g.
Object removal from cache, revalidation). [Editor's note: this
functionality is currently described in
draft-jenkins-cdni-problem-statement-01 under the Metadata API
but probably fits better under the Control API].
4.2. Beyond Initial CDNI Scope
R17 The CDNI Control API 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).
R18 The CDNI Control API 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).
Le Faucheur, et al. Expires July 30, 2011 [Page 9]
Internet-Draft CDNI Requirements January 2011
R19 The CDNI Control API SHOULD allow bootstrapping of the Request-
Routing API. 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 API endpoints
* information necessary to establish secure communication
between the Request-Routing API endpoints.
R20 The CDNI Control API MUST allow the Downstream CDN to
communicate to the Upstream CDN aggregate information on the
Downstream CDN capabilities, resources and affinities (i.e.
Preferences or cost). This information can be taken into
account by the Upstream CDN Request Routing system in his CDN
Selection decisions. 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).
R21 The CDNI Control API 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 API MUST prevent
looping of information exchange.
R22 The CDNI Control API 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 his
CDN Selection decisions. This information could, for example,
include:
Le Faucheur, et al. Expires July 30, 2011 [Page 10]
Internet-Draft CDNI Requirements January 2011
* 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
R23 The CDNI Control API SHOULD support virtualization of the
Downstream CDN, so that the Downstream CDN appears as multiple
virtual Downstream CDN. In that case, the information discussed
in the previous requirement MUST be complemented with a Virtual
CDN Identifier that is unique in the context of the pair of CDNs
on both sides of the CDNI Control API.
R24 The CDNI Control API SHOULD allow bootstrapping of the Metadata
Signaling API. This information could, for example, include:
* discovery of the Metadata Signaling API endpoints
* information necessary to establish secure communication
between the Metadata Signaling API endpoints.
R25 The CDNI Control API SHOULD allow bootstrapping of the Content
Acquisition API. This information could, for example, include:
* negotiation of the Content Acquisition protocol to be used
(e.g. HTTP, HTTPS, FTP, ATIS C2), with some granularity
(e.g. On a per content type basis).
R26 The CDNI Control API SHOULD allow the Upstream CDN to distribute
the information necessary to bootstrap delivery authorization
mechanisms to be performed by Downstream CDN. This information
could, for example, include:
* information necessary for surrogates to perform URI
signature based validation
R27 The CDNI Control API SHOULD allow bootstrapping of the CDNI
Logging API. This information could, for example, include:
* discovery of the Logging API endpoints
* information necessary to establish secure communication
between the Logging API endpoints
* negotiation/definition of the log file format and set of
fields to be exported through the Logging API, with some
granularity (e.g. On a per content type basis). For
example, in the case of HTTP delivery, one candidate
Le Faucheur, et al. Expires July 30, 2011 [Page 11]
Internet-Draft CDNI Requirements January 2011
approach might be :
+ to specify one (or set of) base log file format in a
similar manner to the Apache Common Log file Format
([Apache-Common] ), and
+ to specify a mechanism allowing the Upstream CDN to
define alternative custom file formats (i.e. Containing
an alternative set of fields out of those defined by the
CDNI WG) in a similar manner to the Apache LogFormat
directive [Apache-Format], and
+ to specify a mechanism allowing negotiations/selection
of the file format (among the base formats or the
alternative formats).
* negotiation/definition of parameters related to transaction
Logs export (e.g., export protocol, file compression, export
frequency, directory).
5. Request Routing API Requirements
5.1. Within Initial CDNI Scope
The main function of the Request Routing API is to allow the Request-
Routing systems in interconnected CDNs to communicate to facilitate
redirection of the request across CDNs.
R28 The CDNI Request-Routing architecture and API 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).
R29 The CDNI Request-Routing architecture and API 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 API call.
R30 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 API (or use
information cached from earlier similar queries) to find out how
Le Faucheur, et al. Expires July 30, 2011 [Page 12]
Internet-Draft CDNI Requirements January 2011
the Downstream CDN wants the request to be redirected, which
allows the Upstream CDN to factor this when redirecting the user
agent. This approach is referred to as "recursive". 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. The CDNI Request-Routing
architecture MUST support recursive request routing.
R31 Alternatively, 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 always
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". The CDNI
Request-Routing architecture MUST support iterative request
routing.
R32 The CDNI Request-Routing API SHOULD support request loop
detection and prevention (e.g. Prevent request looping in a
situation where CDN1 redirects to CDN2 that redirects to CDN3
that would redirect to CDN1).
R33 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).
R34 The CDNI Request-Routing API SHOULD support optional enforcement
of a limit on the number of successive CDN redirections for a
given request.
R35 The CDNI Request-Routing API 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 about the location of the user-agent that
originated the request (e.g. IP address of User Agent in
case of HTTP-based Request Routing, DNS Proxy 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)
Le Faucheur, et al. Expires July 30, 2011 [Page 13]
Internet-Draft CDNI Requirements January 2011
* additional available request information (e.g request
headers in case of HTTP-based Request Routing)
R36 The CDNI Request-Routing API MAY also allow the Upstream CDN to
convey information pointing to CDNI metadata associated with the
requested content.
R37 The CDNI Request-Routing API 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. In case of rejection, an error code
is also provided)
* 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)
R38 The CDNI Request-Routing architecture MUST support a mechanism
by which a Downstream CDN can notify the Upstream CDN when it is
unable or unwilling to serve a request, so the Upstream CDN can
react accordingly (e.g. Select another Downstream CDN, or serve
the request itself).
5.2. Beyond Initial CDNI Scope
R39 The CDNI Request-Routing API MUST support request loop detection
and prevention (e.g. Prevent request looping in a situation
where CDN1 redirects to CDN2 that redirects to CDN3 that would
redirect to CDN1).
R40 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).
R41 The CDNI Request-Routing API MUST support optional enforcement
of a limit on the number of successive CDN redirections for a
given request.
6. CDNI Metadata API Requirements
The primary function of the CDNI Metadata API 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 API is
currently discussed as a single "API", further analysis will
Le Faucheur, et al. Expires July 30, 2011 [Page 14]
Internet-Draft CDNI Requirements January 2011
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
R42 The CDNI Metadata API MUST support a dynamic acquisition model
whereby the Upstream CDN provides the Downstream CDN with
content distribution metadata (including information about how
to acquire content from the Upstream CDN), and whereby the
Downstream CDN surrogates acquire content when it is actually
requested by endusers.
R43 The CDNI Metadata API SHOULD support a pre-positioning model
whereby the Upstream CDN requests the Downstream CDN to acquire
content and associated distribution metadata (and possibly
position those into Downstream CDN surrogates) at an appropriate
time (now or a specified future time), before the content is
actually requested by endusers. [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].
[Editor's note: this functionality is currently described in
draft-jenkins-cdni-problem-statement-01 under the Metadata API.
Should it be moved under the Control API (since it is not
strictly about exchange of metadata but more about triggering
multiple actions in downstream CDN, one of them being possibly
to get metadata) ?].
R44 The CDNI Metadata API 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.
R45 The CDNI Metadata API MUST/SHOULD/MAY? support a mode where all
the relevant Metadata is initially communicated to the
Downstream CDN.
R46 Whether in the pre-positioning model or a dynamic acquisition
model, the CDNI Metadata API MUST provide the necessary
information to allow the Downstream CDN to acquire the content
from the Upstream CDN (e.g. Acquisition protocol and Uniform
Resource Identifier in Upstream CDN- or rules to construct this
URI).
Le Faucheur, et al. Expires July 30, 2011 [Page 15]
Internet-Draft CDNI Requirements January 2011
R47 The CDNI Metadata API MUST also provide the necessary
information to allow the Downstream CDN to attempt to acquire
the content from the content Origin Server, in case it can not
be obtained from the Upstream CDN (e.g. Because of a failure
scenario). Note that the content Origin Server may or may not
be willing to serve the content to the Downstream CDN since the
Content Provider may not have a direct agreement/relationship
with the Downstream CDN for delivery of this content.
R48 The CDNI Metadata API MUST allow the Upstream CDN to add and
modify CDNI Metadata into the Downstream CDN.
R49 The CDNI Metadata API 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).
R50 The CDNI Metadata API 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.
R51 The CDNI Metadata API 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.
R52 The CDNI Metadata API 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 API MUST allow the
Downstream CDN to provide information about the cause of the
rejection.
R53 The Metadata that can be distributed by the CDNI Metadata API
MUST allow signaling of 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)
Le Faucheur, et al. Expires July 30, 2011 [Page 16]
Internet-Draft CDNI Requirements January 2011
R54 The Metadata that can be distributed by the CDNI Metadata API
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).
R55 If cascaded CDNs are supported by the CDNI solution, the CDNI
Metadata API MUST prevent looping of CDNI Metadata distribution
across CDNs.
6.2. Beyond Initial CDNI Scope
R56 The CDNI Metadata API MUST support a pre-positioning model
whereby the Upstream CDN requests the Downstream CDN to acquire
content and associated distribution metadata (and possibly
position those into Downstream CDN surrogates) at an appropriate
time (now or a specified future time), before the content is
actually requested by endusers. [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].
[Editor's note: this functionality is currently described in
draft-jenkins-cdni-problem-statement-01 under the Metadata API.
Should it be moved under the Control API (since it is not
strictly about exchange of metadata but more about triggering
multiple actions in downstream CDN, one of them being possibly
to get metadata) ?].
R57 The Metadata that can be distributed by the CDNI Metadata API
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
* content revalidation parameters (e.g. TTL)
R58 The CDNI Metadata API MUST prevent looping of CDNI Metadata
distribution across CDNs in the presence of cascaded CDNs.
R59 The CDNI Metadata API SHOULD allow signalling of the Virtual CDN
identifier to be used in the Downstream CDN for distribution and
delivery of the corresponding content (or content set).
Le Faucheur, et al. Expires July 30, 2011 [Page 17]
Internet-Draft CDNI Requirements January 2011
7. CDNI Logging API Requirements
This section identifies the requirements related to the CDNI Logging
API. We observe that while the CDNI Logging API is currently
discussed as a single "API", further analysis will determine whether
the corresponding requirements are to be realised over a single
interface and protocol, or over multiple interfaces and protocols.
7.1. Within Initial CDNI Scope
R60 The CDNI logging architecture and API MUST ensure reliable, non-
repudiable logging of deliveries performed by a Downstream CDN
on behalf of an Upstream CDN.
R61 The CDNI Logging API MUST provide logging of deliveries to User
Agents performed by the Downstream CDN as a result of request
redirection by the Upstream CDN.
R62 The CDNI Logging API MUST provide logging of distribution
performed by the Upstream CDN as a result of acquisition request
by the Downstream CDN.
R63 The CDNI Logging API MUST support batch/offline exchange of
logging records.
R64 The CDNI Logging API SHOULD also support additional timing
constraints for some types of logging records (e.g. near-real
time for monitoring and analytics applications)
R65 The CDNI Logging API MUST define a log file format and a set of
fields to be exported through the Logging API, with some
granularity (e.g. On a per content type basis).
R66 The CDNI Logging API MUST define a transport mechanisms to
exchange CDNI Logging files.
7.2. Beyond Initial CDNI Scope
R67 The CDNI Logging API MUST support real-time exchange of some
types of logging records (e.g. For real-time monitoring of
deliveries across CDNs).
R68 The CDNI Logging API MUST allow a CDN to query another CDN for
relevant logging records.
Le Faucheur, et al. Expires July 30, 2011 [Page 18]
Internet-Draft CDNI Requirements January 2011
8. CDNI Security Requirements
This section identifies the requirements related to the CDNI
security. Some of those are expected to affect multiple or all APIs.
8.1. Within Initial CDNI Scope
R69 All the CDNI APIs 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.
R70 The CDNI solution MUST provide sufficient protection against
Denial of Service attacks. In particular, 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.
R71 The CDNI solution MUST 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.
R72 The CDNI solution MUST 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.
R73 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
R74 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).
Le Faucheur, et al. Expires July 30, 2011 [Page 19]
Internet-Draft CDNI Requirements January 2011
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 Nivens-Jenkins for his review
and comments.
12. References
12.1. Normative References
[I-D.bertrand-cdni-use-cases]
Bertrand, G. and E. Stephan, "Use Cases for Content
Distribution Network Interconnection",
draft-bertrand-cdni-use-cases-00 (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-01 (work
in progress), January 2011.
[I-D.watson-cdni-use-cases]
Watson, G., "CDN Interconnect Use Cases",
draft-watson-cdni-use-cases-00 (work in progress),
January 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Le Faucheur, et al. Expires July 30, 2011 [Page 20]
Internet-Draft CDNI Requirements January 2011
[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
[Apache-Common]
"Apache Common Log File Format (http://www.w3.org/Daemon/
User/Config/Logging.html#common-logfile-format)".
[Apache-Format]
"Apache LogFormat Directive (http://httpd.apache.org/docs/
1.3/mod/mod_log_config.html#logformat)".
[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.
[RFC3570] Rzewski, P., Day, M., and D. Gilletti, "Content
Internetworking (CDI) Scenarios", RFC 3570, July 2003.
Le Faucheur, et al. Expires July 30, 2011 [Page 21]
Internet-Draft CDNI Requirements January 2011
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 July 30, 2011 [Page 22]