draft-ietf-cdni-requirements-13.txt   draft-ietf-cdni-requirements-14.txt 
Network Working Group K. Leung, Ed. Network Working Group K. Leung, Ed.
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Informational Y. Lee, Ed. Intended status: Informational Y. Lee, Ed.
Expires: May 30, 2014 Comcast Expires: June 27, 2014 Comcast
Nov 26, 2013 Dec 24, 2013
Content Distribution Network Interconnection (CDNI) Requirements Content Distribution Network Interconnection (CDNI) Requirements
draft-ietf-cdni-requirements-13 draft-ietf-cdni-requirements-14
Abstract Abstract
Content Delivery Networks (CDNs) are frequently used for content Content delivery is frequently provided by specifically architected
delivery. As a result of significant growth in content delivered and provisioned Content Delivery Networks (CDNs). As a result of
over IP networks, existing CDN providers are scaling up their significant growth in content delivered over IP networks, existing
infrastructure. Many Network Service Providers and Enterprise CDN providers are scaling up their infrastructure. Many Network
Service Providers are also deploying their own CDNs. To deliver Service Providers and Enterprise Service Providers are also deploying
contents from the Content Service Provider (CSP) to end users, the their own CDNs. To deliver contents from the Content Service
contents may traverse across multiple CDNs. This creates a need for Provider (CSP) to end users, the contents may traverse across
interconnecting (previously) standalone CDNs so that they can multiple CDNs. This creates a need for interconnecting (previously)
collectively act as a single delivery platform from the CSP to the standalone CDNs so that they can collectively act as a single
end users. delivery platform from the CSP to the end users.
The goal of the present document is to outline the requirements for The goal of the present document is to outline the requirements for
the solution and interfaces to be specified by the CDNI working the solution and interfaces to be specified by the CDNI working
group. group.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 30, 2014. This Internet-Draft will expire on June 27, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 30 skipping to change at page 2, line 30
3. Generic CDNI Requirements . . . . . . . . . . . . . . . . . . 7 3. Generic CDNI Requirements . . . . . . . . . . . . . . . . . . 7
4. CDNI Control Interface Requirements . . . . . . . . . . . . . 8 4. CDNI Control Interface Requirements . . . . . . . . . . . . . 8
5. CDNI Request Routing Redirection Interface Requirements . . . 11 5. CDNI Request Routing Redirection Interface Requirements . . . 11
6. CDNI Footprint & Capabilities Advertisement Interface 6. CDNI Footprint & Capabilities Advertisement Interface
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 13 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. CDNI Metadata Interface Requirements . . . . . . . . . . . . . 15 7. CDNI Metadata Interface Requirements . . . . . . . . . . . . . 15
8. CDNI Logging Interface Requirements . . . . . . . . . . . . . 19 8. CDNI Logging Interface Requirements . . . . . . . . . . . . . 19
9. CDNI Security Requirements . . . . . . . . . . . . . . . . . . 21 9. CDNI Security Requirements . . . . . . . . . . . . . . . . . . 21
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
11. Security Considerations . . . . . . . . . . . . . . . . . . . 22 11. Security Considerations . . . . . . . . . . . . . . . . . . . 22
12. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 22
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
14.1. Normative References . . . . . . . . . . . . . . . . . . . 23 14.1. Normative References . . . . . . . . . . . . . . . . . . . 23
14.2. Informative References . . . . . . . . . . . . . . . . . . 23 14.2. Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
The volume of video and multimedia content delivered over the The volume of video and multimedia content delivered over the
Internet is rapidly increasing and expected to continue doing so in Internet is rapidly increasing and expected to continue doing so in
the future. In the face of this growth, Content Delivery Networks the future. In the face of this growth, Content Delivery Networks
skipping to change at page 3, line 41 skipping to change at page 3, line 41
technology framework for the CDNI solution and interfaces. technology framework for the CDNI solution and interfaces.
The goal of the present document is to document the requirements for The goal of the present document is to document the requirements for
the CDNI solution and interfaces. In order to meet the timelines the CDNI solution and interfaces. In order to meet the timelines
defined in the working group charter, the present document defined in the working group charter, the present document
categorizes the CDNI requirements as "High Priority", "Medium categorizes the CDNI requirements as "High Priority", "Medium
Priority", and "Low Priority". Priority", and "Low Priority".
1.1. Terminology 1.1. Terminology
This document uses the terminology defined in [RFC6707] as well as in This document uses the terminology defined in [RFC6707]. In
section 1.1 of Framework for CDN Interconnection addition, the key words "High Priority", "Medium Priority" and "Low
[I-D.ietf-cdni-framework]. In addition, the key words "High Priority" in this document are to be interpreted in the following
Priority", "Medium Priority" and "Low Priority" in this document are way:
to be interpreted in the following way:
o "High Priority" indicates requirements that are to be supported by o "High Priority": When a requirement is tagged as "{HIGH}", it is
the CDNI interfaces. A requirement is stated as "High Priority" considered by the working group as an essential function for CDNI
when it is established by the working group that it can be met to and necessary to a deployable solution. This requirement has to
achieve the goal of a deployable solution in a short timeframe as be met even if it causes a delay in the delivery by the working
needed by the industry. This is tagged as "{HIGH}". group of a deployable solution.
o "Medium Priority" indicates requirements that are to be supported o "Medium Priority": When a requirement is tagged as "{MED}", it is
by the CDNI interfaces unless the WG realizes at a later stage considered by the working group as an important function for CDNI.
that attempting to meet this requirement does not achieve the goal This requirement has to be met, unless it is established that
of a deployable solution in a short timeframe as needed by the attempting to meet this requirement would cause a delay in the
industry. This is tagged as "{MED}". delivery by the working group of a deployable solution.
o "Low Priority" indicates requirements that are to be supported by o "Low Priority": When a requirement is tagged as "{LOW}", it is
the CDNI interfaces provided that dedicating WG resources to this considered by the working group as a useful function for CDNI.
work does not prevent addressing "High Priority" and "Medium The working group will attempt to meet this requirement as long as
Priority" requirements and that attempting to meet this it does not prevent meeting the "High Priority" and "Medium
requirement is not an obstacle to achieving the goal of a Priority" requirements and does not cause a delay in the delivery
deployable solution in a short timeframe as needed by the by the working group of a deployable solution.
industry. This is tagged as "{LOW}".
2. CDNI Model and CDNI Interfaces 2. CDNI Model and CDNI Interfaces
For convenience, the "CDNI Expanded Model and CDNI Interfaces" figure The "CDNI Expanded Model and CDNI Interfaces" figure and brief
and brief descriptions of the CDNI interfaces in descriptions of the CDNI interfaces in [I-D.ietf-cdni-framework] are
[I-D.ietf-cdni-framework] are replicated below. replicated below for convenience. That document contains the
definitive reference model and descriptions for the CDNI interfaces.
o CDNI Control interface (CI): Operations to bootstrap and o CDNI Control interface (CI): Operations to bootstrap and
parameterize the other CDNI interfaces, as well as operations to parameterize the other CDNI interfaces, as well as operations to
pre-position, revalidate, and purge both metadata and content. pre-position, revalidate, and purge both metadata and content.
The latter subset of operations is sometimes collectively called The latter subset of operations is sometimes collectively called
the "trigger interface." the "Trigger interface."
o CDNI Request Routing interface: Operations to determine what CDN o CDNI Request Routing interface: Operations to determine what CDN
(and optionally what surrogate within a CDN) is to serve end- (and optionally what surrogate within a CDN) is to serve end-
user's requests. This interface is actually a logical bundling of user's requests. This interface is actually a logical bundling of
two separate but related interfaces: two separate but related interfaces:
* CDNI Footprint & Capabilities Advertisement interface (FCI): * CDNI Footprint & Capabilities Advertisement interface (FCI):
Asynchronous operations to exchange routing information (e.g., Asynchronous operations (as defined in
the network footprint and capabilities served by a given CDN) [I-D.ietf-cdni-framework]) to exchange routing information
that enables CDN selection for subsequent user requests; and (e.g., the network footprint and capabilities served by a given
CDN) that enables CDN selection for subsequent user requests;
and
* CDNI Request Routing Redirection interface (RI): Synchronous * CDNI Request Routing Redirection interface (RI): Synchronous
operations to select a delivery CDN (surrogate) for a given operations (as defined in [I-D.ietf-cdni-framework]) to select
user request. a delivery CDN (surrogate) for a given user request.
o CDNI Metadata interface (MI): Operations to communicate metadata o CDNI Metadata interface (MI): Operations to communicate metadata
that governs how the content is delivered by interconnected CDNs. that governs how the content is delivered by interconnected CDNs.
Examples of CDNI metadata include geo-blocking directives, Examples of CDNI metadata include geo-blocking directives,
availability windows, access control mechanisms, and purge availability windows, access control mechanisms, and purge
directives. May include a combination of: directives. It may include a combination of:
* Asynchronous operations to exchange metadata that govern * Asynchronous operations to exchange metadata that govern
subsequent user requests for content; and subsequent user requests for content; and
* Synchronous operations that govern behavior for a given user * Synchronous operations that govern behavior for a given user
request for content. request for content.
o CDNI Logging interface (LI): Operations that allow interconnected o CDNI Logging interface (LI): Operations that allow interconnected
CDNs to exchange relevant activity logs. May include a CDNs to exchange relevant activity logs. It may include a
combination of: combination of:
* Real-time exchanges, suitable for runtime traffic monitoring; * Real-time exchanges, suitable for runtime traffic monitoring;
and and
* Offline exchanges, suitable for analytics and billing. * Offline exchanges, suitable for analytics and billing.
-------- --------
/ \ / \
| CSP | | CSP |
skipping to change at page 7, line 33 skipping to change at page 7, line 33
upgrade, to the Content Service Provider delivering content upgrade, to the Content Service Provider delivering content
through a single CDN, to benefit from content delivery through a single CDN, to benefit from content delivery
through interconnected CDNs. through interconnected CDNs.
GEN-4 {HIGH} The CDNI solution shall not depend on intra-CDN GEN-4 {HIGH} The CDNI solution shall not depend on intra-CDN
information to be exposed to other CDNs for effective and information to be exposed to other CDNs for effective and
efficient delivery of the content. Examples of intra-CDN efficient delivery of the content. Examples of intra-CDN
information include surrogate topology, surrogate status, information include surrogate topology, surrogate status,
cached content, etc. cached content, etc.
GEN-5 {HIGH} The CDNI solution shall support delivery to the user GEN-5 {HIGH} The CDNI solution shall support delivery to the User
agent based on HTTP [RFC2616]. (Note that while delivery and Agent based on HTTP [RFC2616]. (Note that while delivery and
acquisition "data plane" protocols are out of the CDNI acquisition "data plane" protocols are out of the CDNI
solution scope, the CDNI solution "control plane" protocols solution scope, the CDNI solution "control plane" protocols
are expected to participate in enabling, selecting or are expected to participate in enabling, selecting or
facilitating operations of such acquisition and delivery facilitating operations of such acquisition and delivery
protocols. Hence it is useful to state requirements on the protocols. Hence it is useful to state requirements on the
CDNI solution in terms of which acquisition and delivery CDNI solution in terms of specifying which acquisition and
protocols). delivery protocols are to be supported).
GEN-6 {HIGH} The CDNI solution shall support acquisition across GEN-6 {HIGH} The CDNI solution shall support acquisition across
CDNs based on HTTP [RFC2616]. (The note above applies to CDNs based on HTTP [RFC2616]. (The note above applies to
this requirement too) this requirement too)
GEN-7 {LOW} The CDNI solution may support delivery to the user GEN-7 {LOW} The CDNI solution may support delivery to the User
agent based on protocols other than HTTP. Agent based on protocols other than HTTP.
GEN-8 {LOW} The CDNI solution may support acquisition across CDNs GEN-8 {LOW} The CDNI solution may support acquisition across CDNs
based on protocols other than HTTP. based on protocols other than HTTP.
GEN-9 {MED} The CDNI solution should support cascaded CDN GEN-9 {MED} The CDNI solution should support cascaded CDN
redirection (CDN1 redirects to CDN2 that redirects to CDN3) redirection (CDN1 redirects to CDN2 that redirects to CDN3)
to an arbitrary number of levels beyond the first level. to an arbitrary number of levels beyond the first level.
GEN-10 {MED} The CDNI solution should support an arbitrary topology GEN-10 {MED} The CDNI solution should support an arbitrary topology
of interconnected CDNs (i.e. the topology of interconnected of interconnected CDNs (i.e. the topology of interconnected
skipping to change at page 10, line 6 skipping to change at page 10, line 6
(that acts as an Upstream CDN). (that acts as an Upstream CDN).
CI-8 {LOW} The CDNI Control interface may allow control of the CDNI CI-8 {LOW} The CDNI Control interface may allow control of the CDNI
interfaces between any two CDNs independently for each interfaces between any two CDNs independently for each
direction (e.g. For the direction where CDN1 is the Upstream direction (e.g. For the direction where CDN1 is the Upstream
CDN and CDN2 is the Downstream CDN, and for the direction CDN and CDN2 is the Downstream CDN, and for the direction
where CDN2 is the Upstream CDN and CDN1 is the Downstream where CDN2 is the Upstream CDN and CDN1 is the Downstream
CDN). CDN).
CI-9 {LOW} The CDNI Control interface may allow bootstrapping of CI-9 {LOW} The CDNI Control interface may allow bootstrapping of
the Request-Routing interface. For example, this can the CDNI Request Routing interface. For example, this can
potentially include: potentially include:
* negotiation of the Request-Routing method (e.g. DNS vs * negotiation of the request routing method (e.g. DNS vs
HTTP, if more than one method is specified) HTTP, if more than one method is specified)
* discovery of the Request-Routing protocol endpoints * discovery of the CDNI Request Routing interface endpoints
* information necessary to establish secure communication * information necessary to establish secure communication
between the Request-Routing protocol endpoints. between the CDNI Request Routing interface endpoints.
CI-10 {LOW} The CDNI Control interface may allow bootstrapping of CI-10 {LOW} The CDNI Control interface may allow bootstrapping of
the CDNI Metadata interface. This information could, for the CDNI Metadata interface. This information could, for
example, include: example, include:
* discovery of the CDNI Metadata signaling protocol * discovery of the CDNI Metadata interface endpoints
endpoints
* information necessary to establish secure communication * information necessary to establish secure communication
between the CDNI Metadata signaling protocol endpoints. between the CDNI Metadata interface endpoints.
CI-11 {LOW} The CDNI Control interface may allow bootstrapping of CI-11 {LOW} The CDNI Control interface may allow bootstrapping of
the Content Acquisition interface. This could, for example, the Content Acquisition interface. This could, for example,
include exchange and negotiation of the Content Acquisition include exchange and negotiation of the Content Acquisition
methods to be used across the CDNs (e.g. HTTP, HTTPS, FTP, methods to be used across the CDNs (e.g. HTTP, HTTPS, FTP,
ATIS C2[ATIS-0800042]). ATIS C2[ATIS-0800042]).
CI-12 {LOW} The CDNI Control interface may allow bootstrapping of CI-12 {LOW} The CDNI Control interface may allow bootstrapping of
the CDNI Logging interface. This information could, for the CDNI Logging interface. This information could, for
example, include: example, include:
* discovery of the Logging protocol endpoints * discovery of the CDNI Logging interface endpoints
* information necessary to establish secure communication * information necessary to establish secure communication
between the Logging protocol endpoints between the CDNI Logging interface endpoints
* negotiation/definition of the log file format and set of * negotiation/definition of the log file format and set of
fields to be exported through the Logging protocol, with fields to be exported through the logging protocol, with
some granularity (e.g. On a per content type basis). some granularity (e.g. On a per content type basis).
* negotiation/definition of parameters related to * negotiation/definition of parameters related to
transaction Logs export (e.g., export protocol, file transaction logs export (e.g., export protocol, file
compression, export frequency, directory). compression, export frequency, directory).
5. CDNI Request Routing Redirection Interface Requirements 5. CDNI Request Routing Redirection Interface Requirements
The main function of the CDNI Request Routing Redirection interface The main function of the CDNI Request Routing Redirection interface
(RI) is to allow the Request-Routing systems in interconnected CDNs (RI) is to allow the Request-Routing systems in interconnected CDNs
to communicate to facilitate redirection of the request across CDNs. to communicate to facilitate redirection of the request across CDNs.
RI-1 {HIGH} The CDNI Request Routing Redirection interface shall RI-1 {HIGH} The CDNI Request Routing Redirection interface shall
support efficient request-routing for small objects. This support efficient request routing for small objects. This
may, for example, call for a mode of operation (e.g. DNS- may, for example, call for a mode of operation (e.g. DNS-
based request routing) where freshness and accuracy of CDN/ based request routing) where freshness and accuracy of CDN/
Surrogate selection can be traded-off against reduced request- Surrogate selection can be traded-off against reduced request
routing load (e.g. Via lighter-weight queries and caching of routing load (e.g. Via lighter-weight queries and caching of
request-routing decisions). request routing decisions).
RI-2 {HIGH} The CDNI Request Routing Redirection interface shall RI-2 {HIGH} The CDNI Request Routing Redirection interface shall
support efficient request-routing for large objects. This support efficient request routing for large objects. This
may, for example, call for a mode of operation (e.g. HTTP- may, for example, call for a mode of operation (e.g. HTTP-
based request routing) where freshness and accuracy of CDN/ based request routing) where freshness and accuracy of CDN/
Surrogate selection justifies a per-request decision and a Surrogate selection justifies a per-request decision and a
per-request CDNI Request-Routing protocol call. per-request CDNI Request-Routing protocol call.
RI-3 {HIGH} The CDNI Request Routing Redirection interface shall RI-3 {HIGH} The CDNI Request Routing Redirection interface shall
support recursive CDNI request routing. support recursive CDNI request routing.
RI-4 {HIGH} The CDNI Request Routing Redirection interface shall RI-4 {HIGH} The CDNI Request Routing Redirection interface shall
support iterative CDNI request routing. support iterative CDNI request routing.
skipping to change at page 12, line 5 skipping to change at page 12, line 5
support a mechanism allowing an Upstream CDN to avoid support a mechanism allowing an Upstream CDN to avoid
redirecting a request to a Downstream CDN if that is likely to redirecting a request to a Downstream CDN if that is likely to
result in the total redirection time exceeding some limit. result in the total redirection time exceeding some limit.
RI-8 {HIGH} The CDNI Request Routing Redirection interface shall RI-8 {HIGH} The CDNI Request Routing Redirection interface shall
allow the Upstream CDN to include, in the query to the allow the Upstream CDN to include, in the query to the
Downstream CDN, the necessary information to allow the Downstream CDN, the necessary information to allow the
Downstream CDN to process the redirection query. This could, Downstream CDN to process the redirection query. This could,
for example, include: for example, include:
* information from which the location of the user-agent that * information from which the geographic region of the User
originated the request can be inferred (e.g. User Agent Agent that originated the request can be inferred (e.g.
fully qualified domain name in case of HTTP-based Request User Agent fully qualified domain name in case of HTTP-
Routing, DNS Proxy fully qualified domain name in case of based Request Routing, DNS Proxy fully qualified domain
DNS-based Request Routing) name in case of DNS-based Request Routing)
* requested resource information (e.g. Resource URI in case * requested resource information (e.g. Resource URI in case
of HTTP-based Request Routing, Resource hostname in case of HTTP-based Request Routing, Resource hostname in case
of DNS-based Request Routing) of DNS-based Request Routing)
* additional available request information (e.g. request * additional available request information (e.g. request
headers in case of HTTP-based Request Routing). headers in case of HTTP-based Request Routing).
RI-9 {LOW} The CDNI Request Routing Redirection interface may also RI-9 {LOW} The CDNI Request Routing Redirection interface may also
allow the Upstream CDN to convey information pointing to CDNI allow the Upstream CDN to convey information pointing to CDNI
skipping to change at page 13, line 10 skipping to change at page 13, line 10
RI-12 {LOW} The CDNI Request Routing Redirection interface may allow RI-12 {LOW} The CDNI Request Routing Redirection interface may allow
the Upstream CDN to use the information conveyed by the the Upstream CDN to use the information conveyed by the
Downstream CDN during the Recursive Request Routing process to Downstream CDN during the Recursive Request Routing process to
rewrite an HTTP Adaptive Streaming manifest file. rewrite an HTTP Adaptive Streaming manifest file.
RI-13 {LOW} The CDNI Request-Routing interface may allow the RI-13 {LOW} The CDNI Request-Routing interface may allow the
Upstream CDN to re-sign the invariant portion of the chunk Upstream CDN to re-sign the invariant portion of the chunk
URIs embedded in the HTTP Adaptive Streaming manifest file. URIs embedded in the HTTP Adaptive Streaming manifest file.
RI-14 {MED} The CDNI Request Routing Redirection interface should RI-14 {MED} The CDNI Request Routing Redirection interface should
allow the use of HTTP cookie to associate the chunks with the correlate the HTTP Adaptive Stream manifest file to the
HTTP Adaptive Stream manifest file (which is verified by the related chunks referenced in the manifest file.
URI signature) based on the Authorization Group ID (which is
an identifier used to correlate the manifest file to the
related chunks).
RI-15 {MED} The CDNI Request Routing Redirection interface should RI-15 {MED} The CDNI Request Routing Redirection interface should
allow for an efficient method of transferring request routing allow for an efficient method of transferring request routing
information for multiple chunks from the Downstream CDN to the information for multiple chunks from the Downstream CDN to the
Upstream CDN as part of the recursive request routing process. Upstream CDN as part of the recursive request routing process.
6. CDNI Footprint & Capabilities Advertisement Interface Requirements 6. CDNI Footprint & Capabilities Advertisement Interface Requirements
The main function of the CDNI Footprint & Capabilities Advertisement The main function of the CDNI Footprint & Capabilities Advertisement
interface (FCI) is to allow the Downstream CDN to advertise the interface (FCI) is to allow the Downstream CDN to advertise the
skipping to change at page 15, line 16 skipping to change at page 15, line 13
logging mechanisms) logging mechanisms)
* capabilities related to CDNI Metadata (e.g., authorization * capabilities related to CDNI Metadata (e.g., authorization
algorithms or support for proprietary vendor metadata) algorithms or support for proprietary vendor metadata)
FCI-6 {LOW} The CDNI Control interface may allow exchange and FCI-6 {LOW} The CDNI Control interface may allow exchange and
negotiation of delivery authorization mechanisms to be negotiation of delivery authorization mechanisms to be
supported across the CDNs (e.g. URI signature based supported across the CDNs (e.g. URI signature based
validation). validation).
FCI-7 {HIGH} The CDNI Footprint & Capabilities Advertisement
interface shall support extensible fields used to convey the
CDN capabilities and methods to indicate the footprint in the
advertisement from the Downstream CDN to the Upstream CDN.
7. CDNI Metadata Interface Requirements 7. CDNI Metadata Interface Requirements
The primary function of the CDNI Metadata interface (MI) is to allow The primary function of the CDNI Metadata interface (MI) is to allow
the Distribution system in interconnected CDNs to communicate to the Distribution system in interconnected CDNs to communicate to
ensure Content Distribution Metadata with inter-CDN scope can be ensure Content Distribution Metadata with inter-CDN scope can be
exchanged across CDNs. We observe that while the CDNI Metadata exchanged across CDNs. We observe that while the CDNI Metadata
Distribution protocol is currently discussed as a single "protocol", Distribution protocol is currently discussed as a single "protocol",
further analysis will determine whether the corresponding further analysis will determine whether the corresponding
requirements are to be realized over a single interface and protocol, requirements are to be realized over a single interface and protocol,
or over multiple interfaces and protocols. For example, a subset of or over multiple interfaces and protocols. For example, a subset of
skipping to change at page 17, line 37 skipping to change at page 17, line 37
set of metadata elements with specified semantics (e.g. start set of metadata elements with specified semantics (e.g. start
of time window, end of time window). of time window, end of time window).
MI-15 {HIGH} The CDNI Metadata interface shall allow exchange of MI-15 {HIGH} The CDNI Metadata interface shall allow exchange of
opaque metadata element, whose semantic is not defined in CDNI opaque metadata element, whose semantic is not defined in CDNI
but established by private CDN agreement. but established by private CDN agreement.
MI-16 {HIGH} The CDNI Metadata interface shall allow signaling of MI-16 {HIGH} The CDNI Metadata interface shall allow signaling of
authorization checks and validation that are to be performed authorization checks and validation that are to be performed
by the surrogate before delivery. For example, this could by the surrogate before delivery. For example, this could
potentially including the need to validate URI signed potentially include the need to validate information (e.g.
information (e.g. Expiry time, Client IP address). Expiry time, Client IP address) required for access
authorization.
MI-17 {MED} The CDNI Metadata interface should allow signaling of MI-17 {MED} The CDNI Metadata interface should allow signaling of
CDNI-relevant surrogate cache behavior parameters. For CDNI-relevant surrogate cache behavior parameters. For
example, this could potentially include: example, this could potentially include:
* control of whether the query string of HTTP URI is to be * control of whether the query string of HTTP URI is to be
ignored by surrogate cache ignored by surrogate cache
* enforcement of caching directives by Downstream CDN that * enforcement of caching directives by Downstream CDN that
are different than the ones signalled in the HTTP headers are different than the ones signalled in the HTTP headers
skipping to change at page 19, line 5 skipping to change at page 19, line 7
along with Content Collection ID may be used for HTTP Adaptive along with Content Collection ID may be used for HTTP Adaptive
Streaming content. Streaming content.
MI-21 {MED} The CDNI Metadata interface should allow the Upstream MI-21 {MED} The CDNI Metadata interface should allow the Upstream
CDN to signal to the Downstream CDN the Authorization Group ID CDN to signal to the Downstream CDN the Authorization Group ID
value for all the related HTTP Adaptive Streaming content value for all the related HTTP Adaptive Streaming content
(i.e. manifest file and chunks). The authorization result of (i.e. manifest file and chunks). The authorization result of
a content (e.g. manifest file) is transferred over to related a content (e.g. manifest file) is transferred over to related
content (e.g. chunks). content (e.g. chunks).
MI-22 {HIGH} The CDNI Metadata interface shall support extensible
format for CDNI metadata delivery from the Upstream CDN to the
Downstream CDN.
8. CDNI Logging Interface Requirements 8. CDNI Logging Interface Requirements
This section identifies the requirements related to the CDNI Logging This section identifies the requirements related to the CDNI Logging
interface (LI). We observe that while the CDNI Logging interface is interface (LI). We observe that while the CDNI Logging interface is
currently discussed as a single "protocol", further analysis will currently discussed as a single "protocol", further analysis will
determine whether the corresponding requirements are to be realized determine whether the corresponding requirements are to be realized
over a single interface and protocol, or over multiple interfaces and over a single interface and protocol, or over multiple interfaces and
protocols. protocols.
LI-1 {HIGH} The CDNI logging architecture and interface shall LI-1 {HIGH} The CDNI logging architecture and interface shall
skipping to change at page 19, line 33 skipping to change at page 19, line 39
LI-3 {MED} In the case of cascaded CDNs, the CDNI Logging interface LI-3 {MED} In the case of cascaded CDNs, the CDNI Logging interface
should allow the Downstream CDN to report to the Upstream CDN should allow the Downstream CDN to report to the Upstream CDN
logging for deliveries and incomplete deliveries performed by logging for deliveries and incomplete deliveries performed by
the Downstream CDN itself as well as logging for deliveries the Downstream CDN itself as well as logging for deliveries
and incomplete deliveries performed by cascaded CDNs on behalf and incomplete deliveries performed by cascaded CDNs on behalf
of the Downstream CDN. of the Downstream CDN.
LI-4 {HIGH} The CDNI Logging interface shall support batch/offline LI-4 {HIGH} The CDNI Logging interface shall support batch/offline
exchange of logging records. exchange of logging records.
LI-5 {MED} The CDNI Logging interface should also support LI-5 {MED} The CDNI Logging interface should also support an
additional timing constraints for some types of logging additional mechanism taking into account the timing
records (e.g. near-real time for monitoring and analytics constraints for some types of logging records (e.g. near-real
applications) time for monitoring and analytics applications).
LI-6 {HIGH} The CDNI Logging interface shall define a log file LI-6 {HIGH} The CDNI Logging interface shall define a log file
format and a set of fields to be exported for various CDNI format and a set of fields to be exported for various CDNI
logging events. logging events.
LI-7 {HIGH} The CDNI Logging interface shall define a transport LI-7 {HIGH} The CDNI Logging interface shall define a transport
mechanism to exchange CDNI Logging files. mechanism to exchange CDNI Logging files.
LI-8 {MED} The CDNI Logging interface should allow a CDN to query LI-8 {MED} The CDNI Logging interface should allow a CDN to query
another CDN for relevant current logging records (e.g. For another CDN for relevant current logging records (e.g. For
skipping to change at page 21, line 7 skipping to change at page 21, line 17
for transfer and/or no longer available (e.g. it exceeded some for transfer and/or no longer available (e.g. it exceeded some
logging retention period or some logging retention volume). logging retention period or some logging retention volume).
LI-16 {MED} The CDNI Logging interface should support the ability LI-16 {MED} The CDNI Logging interface should support the ability
for the Downstream CDN to include the Content Collection ID for the Downstream CDN to include the Content Collection ID
and Session ID fields in CDNI log entries generated for HTTP and Session ID fields in CDNI log entries generated for HTTP
Adaptive Streaming content. Adaptive Streaming content.
LI-17 {MED} The CDNI Logging interface should provide privacy LI-17 {MED} The CDNI Logging interface should provide privacy
protection by not disclosing information that can be used to protection by not disclosing information that can be used to
identify the user (e.g. method that anonymize the IP address identify the user (e.g. method that anonymizes the IP address
carried in the logging field). The use of the privacy carried in the logging field). The use of the privacy
protection mechanism is optional. protection mechanism is optional.
9. CDNI Security Requirements 9. CDNI Security Requirements
This section identifies the requirements related to the CDNI This section identifies the requirements related to the CDNI
security. Some of these are expected to affect multiple or all security. Some of these are expected to affect multiple or all
protocols. protocols.
SEC-1 {HIGH} All the CDNI interface shall support secure operation SEC-1 {HIGH} All the CDNI interface shall support secure operation
over unsecured IP connectivity (e.g. The Internet). This over unsecured IP connectivity (e.g. The Internet). This
includes authentication, confidentiality, integrity protection includes authentication, confidentiality, integrity protection
as well as protection against spoofing and replay. as well as protection against spoofing and replay.
SEC-2 {HIGH} The CDNI solution shall provide sufficient protection SEC-2 {HIGH} The CDNI solution shall provide sufficient protection
against Denial of Service attacks. This includes protection against Denial of Service attacks. This includes protection
against spoofed delivery requests sent by user agents directly against spoofed delivery requests sent by User Agents directly
to a Downstream CDN attempting to appear as if they had been to a Downstream CDN attempting to appear as if they had been
redirected by a given Upstream CDN when they have not. redirected by a given Upstream CDN when they have not.
SEC-3 {MED} The CDNI solution should be able to ensure that for any SEC-3 {MED} The CDNI solution should be able to ensure that for any
given request redirected to a Downstream CDN, the chain of CDN given request redirected to a Downstream CDN, the chain of CDN
Delegation (leading to that request being served by that CDN) Delegation (leading to that request being served by that CDN)
can be established with non-repudiation. can be established with non-repudiation (i.e. "non-repudiation
with proof of origin" as defined in [RFC4949]).
SEC-4 {MED} The CDNI solution should be able to ensure non- SEC-4 {MED} The CDNI solution should be able to ensure non-
repudiation by the Downstream CDN of transaction logs repudiation by the Downstream CDN of transaction logs
generated by the Downstream CDN and communicated to an generated by the Downstream CDN and communicated to an
Upstream CDN. This would ensure that the Downstream CDN Upstream CDN. This would ensure that the Downstream CDN
cannot repudiate transmitted Log records, therefore cannot repudiate transmitted Log records, therefore
discouraging the Downstream CDN from spoofing a transaction discouraging the Downstream CDN from spoofing a transaction
log (attempting to appear as if it corresponds to a request log (attempting to appear as if it corresponds to a request
redirected by the Upstream CDN when that request has not been redirected by the Upstream CDN when that request has not been
redirected by this Upstream CDN). redirected by this Upstream CDN).
skipping to change at page 22, line 16 skipping to change at page 22, line 24
This document makes no request of IANA. This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an Note to RFC Editor: this section may be removed on publication as an
RFC. RFC.
11. Security Considerations 11. Security Considerations
This document discusses CDNI security requirements in Section 9. This document discusses CDNI security requirements in Section 9.
12. Authors 12. Contributors
This document reflects the contributions from the following authors: This document reflects the contributions from the following authors:
Francois Le Faucheur Francois Le Faucheur
Cisco Systems Cisco Systems
flefauch@cisco.com flefauch@cisco.com
Mahesh Viveganandhan Mahesh Viveganandhan
skipping to change at page 22, line 45 skipping to change at page 23, line 12
gwatson@velocix.com gwatson@velocix.com
13. Acknowledgements 13. Acknowledgements
This document leverages the earlier work of the IETF CDI working This document leverages the earlier work of the IETF CDI working
group in particular as documented in [I-D.cain-request-routing-req], group in particular as documented in [I-D.cain-request-routing-req],
[I-D.amini-cdi-distribution-reqs] and [I-D.gilletti-cdnp-aaa-reqs]. [I-D.amini-cdi-distribution-reqs] and [I-D.gilletti-cdnp-aaa-reqs].
The authors would like to thank Gilles Bertrand, Christophe Caillet, The authors would like to thank Gilles Bertrand, Christophe Caillet,
Bruce Davie, Phil Eardly, Ben Niven-Jenkins, Agustin Schapira, Emile Bruce Davie, Phil Eardley, Ben Niven-Jenkins, Agustin Schapira, Emile
Stephan, Eric Burger, Susan He, Kevin Ma, Daryl Malas, Iuniana Stephan, Eric Burger, Susan He, Kevin Ma, Daryl Malas, Iuniana
Oprescu, and Spencer Dawkins for their input. Serge Manning along Oprescu, and Spencer Dawkins for their input. Serge Manning along
with Robert Streijl, Vishwa Prasad, Percy Tarapore, Mike Geller, and with Robert Streijl, Vishwa Prasad, Percy Tarapore, Mike Geller, and
Ramki Krishnan contributed to this document by addressing the Ramki Krishnan contributed to this document by addressing the
requirements of the ATIS Cloud Services Forum. requirements of the ATIS Cloud Services Forum.
Ray Brandenburg, Matt Caufield, and Gilles Bertrand provided valuable Ray Brandenburg, Matt Caufield, and Gilles Bertrand provided valuable
inputs for HTTP Adaptive Streaming, CDNI Metadata interface, and CDNI inputs for HTTP Adaptive Streaming, CDNI Metadata interface, and CDNI
Logging interface, respectively. Logging interface, respectively.
14. References 14. References
14.1. Normative References 14.1. Normative References
[I-D.ietf-cdni-framework]
Peterson, L. and B. Davie, "Framework for CDN
Interconnection", draft-ietf-cdni-framework-06 (work in
progress), October 2013.
[RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content
Distribution Network Interconnection (CDNI) Problem Distribution Network Interconnection (CDNI) Problem
Statement", RFC 6707, September 2012. Statement", RFC 6707, September 2012.
14.2. Informative References 14.2. Informative References
[ATIS-0800042] [ATIS-0800042]
"ATIS IPTV Content on Demand Service, "ATIS IPTV Content on Demand Service,
https://www.atis.org/docstore/product.aspx?id=25670", https://www.atis.org/docstore/product.aspx?id=25670",
December 2010. December 2010.
skipping to change at page 23, line 39 skipping to change at page 24, line 9
[I-D.cain-request-routing-req] [I-D.cain-request-routing-req]
Cain, B., "Request Routing Requirements for Content Cain, B., "Request Routing Requirements for Content
Internetworking", draft-cain-request-routing-req-03 (work Internetworking", draft-cain-request-routing-req-03 (work
in progress), November 2001. in progress), November 2001.
[I-D.gilletti-cdnp-aaa-reqs] [I-D.gilletti-cdnp-aaa-reqs]
"CDI AAA Requirements, "CDI AAA Requirements,
draft-gilletti-cdnp-aaa-reqs-01.txt", June 2001. draft-gilletti-cdnp-aaa-reqs-01.txt", June 2001.
[I-D.ietf-cdni-framework]
Peterson, L. and B. Davie, "Framework for CDN
Interconnection", draft-ietf-cdni-framework-06 (work in
progress), October 2013.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
RFC 4949, August 2007.
[RFC6770] Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma, [RFC6770] Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma,
K., and G. Watson, "Use Cases for Content Delivery Network K., and G. Watson, "Use Cases for Content Delivery Network
Interconnection", RFC 6770, November 2012. Interconnection", RFC 6770, November 2012.
[RTMP] "Adobe's Real Time Messaging Protocol, http://
www.adobe.com/content/dam/Adobe/en/devnet/rtmp/pdf/
rtmp_specification_1.0.pdf", December 2012.
Authors' Addresses Authors' Addresses
Kent Leung (editor) Kent Leung (editor)
Cisco Systems Cisco Systems
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
U.S.A. U.S.A.
Phone: +1 408 526 5030 Phone: +1 408 526 5030
Email: kleung@cisco.com Email: kleung@cisco.com
 End of changes. 47 change blocks. 
96 lines changed or deleted 111 lines changed or added

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