draft-ietf-cdni-requirements-00.txt   draft-ietf-cdni-requirements-01.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: March 12, 2012 Comcast Expires: April 21, 2012 Comcast
September 9, 2011 October 19, 2011
Content Distribution Network Interconnection (CDNI) Requirements Content Distribution Network Interconnection (CDNI) Requirements
draft-ietf-cdni-requirements-00 draft-ietf-cdni-requirements-01
Abstract Abstract
Content Delivery Networks (CDNs) are frequently used for large-scale Content Delivery Networks (CDNs) are frequently used for large-scale
content delivery. As a result, existing CDN providers are scaling up content delivery. As a result, existing CDN providers are scaling up
their infrastructure and many Network Service Providers (NSPs) are their infrastructure and many Network Service Providers (NSPs) are
deploying their own CDNs. There is a requirement for interconnecting deploying their own CDNs. There is a requirement for interconnecting
standalone CDNs so that their collective CDN footprint can be standalone CDNs so that their collective CDN footprint can be
leveraged for the end-to-end delivery of content from Content Service leveraged for the end-to-end delivery of content from Content Service
Providers (CSPs) to end users. The Content Distribution Network Providers (CSPs) to end users. The Content Distribution Network
skipping to change at page 2, line 27 skipping to change at page 2, line 27
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 March 12, 2012. This Internet-Draft will expire on April 21, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 3, line 14 skipping to change at page 3, line 14
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. CDNI Model and CDNI Interfaces . . . . . . . . . . . . . . . . 4 2. CDNI Model and CDNI Interfaces . . . . . . . . . . . . . . . . 4
3. Generic CDNI Requirements . . . . . . . . . . . . . . . . . . 6 3. Generic CDNI Requirements . . . . . . . . . . . . . . . . . . 6
4. CDNI Control Interface Requirements . . . . . . . . . . . . . 7 4. CDNI Control Interface Requirements . . . . . . . . . . . . . 7
5. CDNI Request Routing Interface Requirements . . . . . . . . . 9 5. CDNI Request Routing Interface Requirements . . . . . . . . . 9
6. CDNI Metadata Distribution Interface Requirements . . . . . . 13 6. CDNI Metadata Distribution Interface Requirements . . . . . . 13
7. CDNI Logging Interface Requirements . . . . . . . . . . . . . 16 7. CDNI Logging Interface Requirements . . . . . . . . . . . . . 15
8. CDNI Security Requirements . . . . . . . . . . . . . . . . . . 17 8. CDNI Security Requirements . . . . . . . . . . . . . . . . . . 17
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18
11. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 11. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
13.1. Normative References . . . . . . . . . . . . . . . . . . . 19 13.1. Normative References . . . . . . . . . . . . . . . . . . . 19
13.2. Informative References . . . . . . . . . . . . . . . . . . 19 13.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
skipping to change at page 4, line 39 skipping to change at page 4, line 39
[I-D.jenkins-cdni-problem-statement] outlines the problem area that [I-D.jenkins-cdni-problem-statement] outlines the problem area that
the CDNI working group is chartered to address. the CDNI working group is chartered to address.
[I-D.bertrand-cdni-use-cases] discusses the use cases for CDN [I-D.bertrand-cdni-use-cases] discusses the use cases for CDN
Interconnection. [I-D.davie-cdni-framework] discusses the technology Interconnection. [I-D.davie-cdni-framework] discusses the technology
framework for the CDNI solution and interfaces. 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". (OPEN ISSUE: Should requirements in Priority", and "Low Priority".
each section be ordered by priority?)
1.1. Terminology 1.1. Terminology
This document uses the terminology defined in section 1.1 of This document uses the terminology defined in section 1.1 of
[I-D.davie-cdni-framework]. [I-D.davie-cdni-framework].
2. CDNI Model and CDNI Interfaces 2. CDNI Model and CDNI Interfaces
For convenience Figure 1 from [I-D.davie-cdni-framework] illustrating For convenience Figure 1 from [I-D.davie-cdni-framework] illustrating
the CDNI problem area and the CDNI protocols is replicated below. the CDNI problem area and the CDNI protocols is replicated below.
skipping to change at page 6, line 49 skipping to change at page 6, line 49
CDNs based on HTTP [RFC2616]. CDNs based on HTTP [RFC2616].
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.(OPEN ISSUE: arbitrary to an arbitrary number of levels beyond the first level.
number should more than one 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 CDN topology cannot be of interconnected CDNs (i.e. the CDN topology cannot be
restricted to a tree, a loop-free topology, etc.). restricted to a tree, a loop-free topology, etc.).
GEN-11 [HIGH] The CDNI solution shall prevent looping of any CDNI GEN-11 [HIGH] The CDNI solution shall prevent looping of any CDNI
information exchange. information exchange.
GEN-12 [HIGH] When making use of third party reference, the CDNI GEN-12 [HIGH] When making use of third party reference, the CDNI
solution shall consider the potential issues associated with solution shall consider the potential issues associated with
skipping to change at page 7, line 33 skipping to change at page 7, line 33
particular, this applies to situations where the CDNI particular, this applies to situations where the CDNI
solution needs to construct and convey uniform resource solution needs to construct and convey uniform resource
identifiers for directing/redirecting a content request, as identifiers for directing/redirecting a content request, as
well as to situations where the CDNI solution needs to pass well as to situations where the CDNI solution needs to pass
on a third party reference (e.g. to identify a User Agent) in on a third party reference (e.g. to identify a User Agent) in
order to allow another entity to make a more informed order to allow another entity to make a more informed
decision (e.g. make a more informed request routing decision decision (e.g. make a more informed request routing decision
by attempting to derive location information from the third by attempting to derive location information from the third
party reference). party reference).
GEN-13 [LOW] The CDNI solution should support virtualization of the GEN-13
Downstream CDN, so that the Downstream CDN can appear as
multiple logical Downstream CDNs. (OPEN ISSUE:
Virtualization is transparent to CDNI, remove requirement or
justify why uCDN/dCDN needs to be aware?)
GEN-14 (OPEN ISSUE: Add HTTP ABR requirements) GEN-14 [HIGH] The CDNI solution shall support HTTP Adaptive Bit Rate
(ABR) content.
4. CDNI Control Interface Requirements 4. CDNI Control Interface Requirements
The primary purpose of the CDNI Control interface is to initiate the The primary purpose of the CDNI Control interface is to initiate the
interconnection across CDNs, bootstrap the other CDNI interfaces and interconnection across CDNs, bootstrap the other CDNI interfaces and
trigger actions into the Downstream CDN by the Upstream CDN (such as trigger actions into the Downstream CDN by the Upstream CDN (such as
delete object from caches or trigger pre-positioned content delete object from caches or trigger pre-positioned content
acquisition). We observe that while the CDNI Control interface is acquisition). We observe that while the CDNI Control 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
skipping to change at page 8, line 15 skipping to change at page 8, line 15
CNTL-1 [HIGH] The CDNI Control interface shall allow the Upstream CNTL-1 [HIGH] The CDNI Control interface shall allow the Upstream
CDN to request that the Downstream CDN (and, if cascaded CDN to request that the Downstream CDN (and, if cascaded
CDNs are supported by the solution, that the potential CDNs are supported by the solution, that the potential
cascaded Downstream CDNs) perform the following actions on cascaded Downstream CDNs) perform the following actions on
an object or object set: an object or object set:
* Mark an object(s) and/or its CDNI metadata as "stale" * Mark an object(s) and/or its CDNI metadata as "stale"
and revalidate them before they are delivered again and revalidate them before they are delivered again
* Delete an object(s) and/or its CDNI metadata from the * Delete an object(s) and/or its CDNI metadata from the
CDN surrogates and any storage. CDN surrogates and any storage. Only the object(s) and
CDNI metadata that pertain to the requesting Upstream
CDN are allowed to be purged.
CNTL-2 [HIGH] The CDNI Control interface shall allow the downstream CNTL-2 [HIGH] The CDNI Control interface shall allow the downstream
CDN to report on the completion of these actions (by itself, CDN to report on the completion of these actions (by itself,
and if cascaded CDNs are supported by the solution, by and if cascaded CDNs are supported by the solution, by
potential cascaded Downstream CDNs), in a manner appropriate potential cascaded Downstream CDNs), in a manner appropriate
for the action (e.g. synchronously or asynchronously). for the action (e.g. synchronously or asynchronously).
CNTL-3 [HIGH] The CDNI Control interface shall support initiation CNTL-3 [HIGH] The CDNI Control interface shall support initiation
and control by the Upstream CDN of pre-positioned CDNI and control by the Upstream CDN of pre-positioned CDNI
metadata acquisition by the Downstream CDN. metadata acquisition by the Downstream CDN.
CNTL-4 [MED] The CDNI Control interface should support initiation CNTL-4 [MED] The CDNI Control interface should support initiation
and control by the Upstream CDN of pre-positioned content and control by the Upstream CDN of pre-positioned content
acquisition by the Downstream CDN.(OPEN ISSUE: how much acquisition by the Downstream CDN.
influence the Upstream CDN ought to have on pre-positioning
of the content on surrogates inside the Downstream CDN is
TBD).
CNTL-5 [LOW] The CDNI Control interface may allow a CDN to CNTL-5 [LOW] The CDNI Control interface may allow a CDN to
establish, update and terminate a CDN interconnection with establish, update and terminate a CDN interconnection with
another CDN whereby one CDN can act as a Downstream CDN for another CDN whereby one CDN can act as a Downstream CDN for
the other CDN (that acts as an Upstream CDN). the other CDN (that acts as an Upstream CDN).
CNTL-6 [LOW] The CDNI Control interface may allow control of the CNTL-6 [LOW] The CDNI Control interface may allow control of the
CDNI interconnection between any two CDNs independently for CDNI interconnection between any two CDNs independently for
each direction (i.e. For the direction where CDN1 is the each direction (i.e. For the direction where CDN1 is the
Upstream CDN and CDN2 is the Downstream CDN, and for the Upstream CDN and CDN2 is the Downstream CDN, and for the
skipping to change at page 10, line 6 skipping to change at page 10, line 6
* 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 Interface Requirements 5. CDNI Request Routing Interface Requirements
The main function of the Request Routing interface is to allow the The main function of the Request Routing interface is to allow the
Request-Routing systems in interconnected CDNs to communicate to Request-Routing systems in interconnected CDNs to communicate to
facilitate redirection of the request across CDNs. facilitate redirection of the request across CDNs.
REQ-1 [HIGH] The CDNI Control interface shall allow the Downstream REQ-1 [HIGH] The CDNI Request-Routing interface shall allow the
CDN to communicate to the Upstream CDN coarse information Downstream CDN to communicate to the Upstream CDN coarse
about the Downstream CDN ability and/or willingness to handle information about the Downstream CDN ability and/or
requests from the Upstream CDN. For example, this could willingness to handle requests from the Upstream CDN. For
potentially include a binary signal ("Downstream CDN ready/ example, this could potentially include a binary signal
not-ready to take additional requests from Upstream CDN") to ("Downstream CDN ready/not-ready to take additional requests
be used in case of excessive load or failure condition in the from Upstream CDN") to be used in case of excessive load or
Downstream CDN. (OPEN ISSUE: Belong to Control Interface failure condition in the Downstream CDN.
section?)
REQ-2 [MED] The CDNI Request-Routing interface should allow the REQ-2 [MED] The CDNI Request-Routing interface should allow the
Downstream CDN to communicate to the Upstream CDN aggregate Downstream CDN to communicate to the Upstream CDN aggregate
information to facilitate CDN selection during request information to facilitate CDN selection during request
routing, such as Downstream CDN capabilities, resources and routing, such as Downstream CDN capabilities, resources and
affinities (i.e. Preferences or cost). This information affinities (i.e. Preferences or cost). This information
could, for example, include: could, for example, include:
* supported content types and delivery protocols * supported content types and delivery protocols
skipping to change at page 11, line 5 skipping to change at page 11, line 5
REQ-3 [MED] In the case of cascaded redirection, the CDNI Request- REQ-3 [MED] In the case of cascaded redirection, the CDNI Request-
Routing interface shall allow the Downstream CDN to also Routing interface shall allow the Downstream CDN to also
include in the information communicated to the Upstream CDN, include in the information communicated to the Upstream CDN,
information on the capabilities, resources and affinities of information on the capabilities, resources and affinities of
CDNs to which the Downstream CDN may (in turn) redirect CDNs to which the Downstream CDN may (in turn) redirect
requests received by the Upstream CDN. In that case, the requests received by the Upstream CDN. In that case, the
CDNI Request-Routing interface shall prevent looping of such CDNI Request-Routing interface shall prevent looping of such
information exchange. information exchange.
REQ-4 [LOW] The CDNI Control interface may allow the Downstream CDN REQ-4 [LOW] The CDNI Request-Routing interface may allow the
to communicate to the Upstream CDN aggregate information on Downstream CDN to communicate to the Upstream CDN aggregate
CDNI administrative limits and policy. This information can information on CDNI administrative limits and policy. This
be taken into account by the Upstream CDN Request Routing information can be taken into account by the Upstream CDN
system in its CDN Selection decisions. This information Request Routing system in its CDN Selection decisions. This
could, for example, include: information could, for example, include:
* maximum number of requests redirected by the Upstream CDN * maximum number of requests redirected by the Upstream CDN
to be served simultaneously by the Downstream CDN to be served simultaneously by the Downstream CDN
* maximum aggregate volume of content (e.g. in Terabytes) * maximum aggregate volume of content (e.g. in Terabytes)
to be delivered by the Downstream CDN over a time period. to be delivered by the Downstream CDN over a time period.
REQ-5 [HIGH] The CDNI Request-Routing architecture and interface REQ-5 [HIGH] The CDNI Request-Routing architecture and interface
shall support efficient request-routing for small objects. shall support efficient request-routing for small objects.
This may, for example, call for a mode of operation (e.g. This may, for example, call for a mode of operation (e.g.
DNS-based request routing) where freshness and accuracy of DNS-based request routing) where freshness and accuracy of
CDN/Surrogate selection can be traded-off against reduced CDN/Surrogate selection can be traded-off against reduced
request-routing load (e.g. Via lighter-weight queries and request-routing load (e.g. Via lighter-weight queries and
caching of request-routing decisions). (OPEN ISSUE: caching of request-routing decisions).
Surrogate selection is out of scope?)
REQ-6 [HIGH] The CDNI Request-Routing architecture and interface REQ-6 [HIGH] The CDNI Request-Routing architecture and interface
shall support efficient request-routing for large objects. shall support efficient request-routing for large objects.
This may, for example, call for a mode of operation (e.g. This may, for example, call for a mode of operation (e.g.
HTTP-based request routing) where freshness and accuracy of HTTP-based request routing) where freshness and accuracy of
CDN/Surrogate selection justifies a per-request decision and CDN/Surrogate selection justifies a per-request decision and
a per-request CDNI Request-Routing protocol call. (OPEN a per-request CDNI Request-Routing protocol call.
ISSUE: Surrogate selection is out of scope?)
REQ-7 [HIGH] The CDNI Request-Routing architecture shall support REQ-7 [HIGH] The CDNI Request-Routing architecture shall support
recursive CDNI request routing. recursive CDNI request routing.
REQ-8 [HIGH] The CDNI Request-Routing architecture shall support REQ-8 [HIGH] The CDNI Request-Routing architecture shall support
iterative CDNI request routing. iterative CDNI request routing.
REQ-9 [MED] In case of detection of a request redirection loop, the REQ-9 [MED] In case of detection of a request redirection loop, the
CDNI Request-Routing loop prevention mechanism should allow CDNI Request-Routing loop prevention mechanism should allow
routing of the request (as opposed to the request loop being routing of the request by avoiding the loop (as opposed to
simply interrupted without routing the request). (OPEN the request loop being simply interrupted without routing the
ISSUE: Why route a looped request?) request).
REQ-10 [MED] The CDNI Request-Routing protocol should support a REQ-10 [MED] The CDNI Request-Routing protocol should support a
mechanism allowing enforcment of a limit on the number of mechanism allowing enforcment of a limit on the number of
successive CDN redirections for a given request. successive CDN redirections for a given request.
REQ-11 [LOW] The CDNI Request-Routing protocol may support a REQ-11 [LOW] The CDNI Request-Routing protocol may support a
mechanism allowing an upstream CDN to avoid redirecting a mechanism allowing an upstream CDN to avoid redirecting a
request to a downstream CDN if that is likely to result in request to a downstream CDN if that is likely to result in
the total redirection time exceeding some limit. the total redirection time exceeding some limit.
skipping to change at page 13, line 34 skipping to change at page 13, line 33
META-2 [HIGH] The CDNI Metadata Distribution interface shall META-2 [HIGH] The CDNI Metadata Distribution interface shall
support exchange of CDNI metadata for both the dynamic support exchange of CDNI metadata for both the dynamic
content acquisition model and the pre-positioning content content acquisition model and the pre-positioning content
acquisition model. acquisition model.
META-3 [HIGH] The CDNI Metadata Distribution interface shall META-3 [HIGH] The CDNI Metadata Distribution interface shall
support a mode where no, or a subset of, the Metadata is support a mode where no, or a subset of, the Metadata is
initially communicated to the Downstream CDN along with initially communicated to the Downstream CDN along with
information about how/where to acquire the rest of the CDNI information about how/where to acquire the rest of the CDNI
Metadata (i.e. Dynamic CDNI metadata acquisition). (OPEN Metadata (i.e. Dynamic CDNI metadata acquisition).
ISSUE: Confirm high priority)
META-4 [MED] The CDNI Metadata Distribution interface should META-4 [MED] The CDNI Metadata Distribution interface should
support a mode where all the relevant Metadata is initially support a mode where all the relevant Metadata is initially
communicated to the Downstream CDN (i.e. Pre-positioned communicated to the Downstream CDN (i.e. Pre-positioned
CDNI metadata acquisition). (OPEN ISSUE: Confirm medium CDNI metadata acquisition).
priority)
META-5 [HIGH] Whether in the pre-positioned content acquisition META-5 [HIGH] Whether in the pre-positioned content acquisition
model or in the dynamic content acquisition model, the CDNI model or in the dynamic content acquisition model, the CDNI
Metadata Distribution interface shall provide the necessary Metadata Distribution interface shall provide the necessary
information to allow the Downstream CDN to acquire the information to allow the Downstream CDN to acquire the
content from an upstream source (e.g. Acquisition protocol content from an upstream source (e.g. Acquisition protocol
and Uniform Resource Identifier in Upstream CDN- or rules to and Uniform Resource Identifier in Upstream CDN- or rules to
construct this URI). construct this URI).
META-6 [HIGH] The CDNI metadata shall allow signaling of one or META-6 [HIGH] The CDNI metadata shall allow signaling of one or
skipping to change at page 15, line 24 skipping to change at page 15, line 16
signaling of content distribution control policies. For signaling of content distribution control policies. For
example, this could potentially include: example, this could potentially include:
* geo-blocking information (i.e. Information defining * geo-blocking information (i.e. Information defining
geographical areas where the content is to be made geographical areas where the content is to be made
available or blocked) available or blocked)
* availability windows (i.e. Information defining time * availability windows (i.e. Information defining time
windows during which the content is to be made available windows during which the content is to be made available
or blocked; expiration time may also be included to or blocked; expiration time may also be included to
remove content) (OPEN ISSUE: Expiration time needed?) remove content)
* delegation whitelist/blacklist (i.e. Information * delegation whitelist/blacklist (i.e. Information
defining which downstream CDNs the content may/may not defining which downstream CDNs the content may/may not
be delivered through) be delivered through)
META-15 [HIGH] The CDNI Metadata interface shall be able to exchange META-15 [HIGH] The CDNI Metadata interface shall be able to exchange
a set of well-accepted metadata elements with specified a set of well-accepted metadata elements with specified
semantics (e.g. start of time window, end of time window). semantics (e.g. start of time window, end of time window).
META-16 [HIGH] The CDNI Metadata interface shall allow exchange of META-16 [HIGH] The CDNI Metadata interface shall allow exchange of
skipping to change at page 16, line 16 skipping to change at page 16, line 8
7. CDNI Logging Interface Requirements 7. 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. We observe that while the CDNI Logging interface is interface. 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.
LOG-1 [HIGH] The CDNI logging architecture and interface shall LOG-1 [HIGH] The CDNI logging architecture and interface shall
ensure reliable logging of CDNI events. ensure reliable logging of CDNI events.
LOG-2 [HIGH] The CDNI Logging interface shall provide logging of LOG-2 [HIGH] The CDNI Logging interface shall provide logging of
deliveries to User Agents performed by the Downstream CDN as a deliveries to User Agents performed by the Downstream CDN as
result of request redirection by the Upstream CDN. a result of request redirection by the Upstream CDN.
LOG-3 [MED] In the case of cascaded CDNs, the CDNI Logging interface LOG-3 [MED] In the case of cascaded CDNs, the CDNI Logging
shall allow the Downstream CDN to report to the Upstream CDN interface shall allow the Downstream CDN to report to the
logging for deliveries performed by the Downstream CDN itself Upstream CDN logging for deliveries performed by the
as well as logging for deliveries performed by cascaded CDNs Downstream CDN itself as well as logging for deliveries
on behalf of the Downstream CDN. performed by cascaded CDNs on behalf of the Downstream CDN.
LOG-4 [HIGH] The CDNI Logging interface shall provide logging of LOG-4 [HIGH] The CDNI Logging interface shall provide logging of
distribution performed by the Upstream CDN as a result of distribution performed by the Upstream CDN as a result of
acquisition request by the Downstream CDN. acquisition request by the Downstream CDN.
LOG-5 [HIGH] The CDNI Logging interface shall support batch/offline LOG-5 [HIGH] The CDNI Logging interface shall support batch/offline
exchange of logging records. exchange of logging records.
LOG-6 [MED] The CDNI Logging interface should also support LOG-6 [MED] The CDNI Logging interface should also support
additional timing constraints for some types of logging additional timing constraints for some types of logging
records (e.g. near-real time for monitoring and analytics records (e.g. near-real time for monitoring and analytics
applications) applications)
LOG-7 [HIGH] The CDNI Logging interface shall define a log file LOG-7 [HIGH] The CDNI Logging interface shall define a log file
format and a set of fields to be exported through the Logging format and a set of fields to be exported through the Logging
protocol, with some granularity (e.g. On a per content type protocol, with some granularity (e.g. On a per content type
basis). basis).
LOG-8 [HIGH] The CDNI Logging interface shall define a transport LOG-8 [HIGH] The CDNI Logging interface shall define a transport
mechanisms to exchange CDNI Logging files. mechanisms to exchange CDNI Logging files.
LOG-9 [LOW] The CDNI Logging interface may allow a CDN to query LOG-9 [LOW] The CDNI Logging interface may 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
on-demand access to real-time logging information). on-demand access to real-time logging information).
[Editor's note: should we add a requirement for support of aggregate/ LOG-10 [LOW] The CDNI Logging interface may support aggregate/
summarized logs (e.g. total bytes delivered for a content regardless summarized logs (e.g. total bytes delivered for a content
of individual User Agents to which it was delivered)] (OPEN ISSUE: regardless of individual User Agents to which it was
LOW for aggregate/summarized logs) delivered).
LOG-11 [LOW] The CDNI Logging interface may provide "quality"
metrics in the logging of deliveries to User Agents performed
by the Downstream CDN.
8. CDNI Security Requirements 8. CDNI Security Requirements
This section identifies the requirements related to the CDNI This section identifies the requirements related to the CDNI
security. Some of those are expected to affect multiple or all security. Some of those 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
skipping to change at page 18, line 46 skipping to change at page 18, line 42
grant.watson@bt.com grant.watson@bt.com
12. Acknowledgements 12. 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 Eardly, Ben Niven-Jenkins, Agustin Schapira, Emile
Stephan, Eric Burger, Susan He, and Kevin Ma for their input. Stephan, Eric Burger, Susan He, Kevin Ma, and Daryl Malas for their
input.
13. References 13. References
13.1. Normative References 13.1. Normative References
[I-D.bertrand-cdni-use-cases] [I-D.bertrand-cdni-use-cases]
Bertrand, G., Stephan, E., Watson, G., Burbridge, T., Bertrand, G., Stephan, E., Watson, G., Burbridge, T.,
Eardley, P., and K. Ma, "Use Cases for Content Delivery Eardley, P., and K. Ma, "Use Cases for Content Delivery
Network Interconnection", draft-bertrand-cdni-use-cases-02 Network Interconnection", draft-bertrand-cdni-use-cases-02
(work in progress), July 2011. (work in progress), July 2011.
 End of changes. 30 change blocks. 
81 lines changed or deleted 75 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/