draft-ietf-cdni-problem-statement-06.txt   draft-ietf-cdni-problem-statement-07.txt 
Network Working Group B. Niven-Jenkins Network Working Group B. Niven-Jenkins
Internet-Draft Velocix (Alcatel-Lucent) Internet-Draft Velocix (Alcatel-Lucent)
Intended status: Informational F. Le Faucheur Intended status: Informational F. Le Faucheur
Expires: November 21, 2012 Cisco Expires: December 25, 2012 Cisco
N. Bitar N. Bitar
Verizon Verizon
May 20, 2012 June 23, 2012
Content Distribution Network Interconnection (CDNI) Problem Statement Content Distribution Network Interconnection (CDNI) Problem Statement
draft-ietf-cdni-problem-statement-06 draft-ietf-cdni-problem-statement-07
Abstract Abstract
Content Delivery Networks (CDNs) provide numerous benefits: reduced Content Delivery Networks (CDNs) provide numerous benefits: reduced
delivery cost for cacheable content, improved quality of experience delivery cost for cacheable content, improved quality of experience
for End Users and increased robustness of delivery. For these for End Users and increased robustness of delivery. For these
reasons they are frequently used for large-scale content delivery. reasons they are frequently used for large-scale content delivery.
As a result, existing CDN Providers are scaling up their As a result, existing CDN Providers are scaling up their
infrastructure and many Network Service Providers (NSPs) are infrastructure and many Network Service Providers (NSPs) are
deploying their own CDNs. It is generally desirable that a given deploying their own CDNs. It is generally desirable that a given
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 November 21, 2012. This Internet-Draft will expire on December 25, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 10 skipping to change at page 3, line 10
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
1.2. CDN Background . . . . . . . . . . . . . . . . . . . . . . 10 1.2. CDN Background . . . . . . . . . . . . . . . . . . . . . . 10
2. CDN Interconnection Use Cases . . . . . . . . . . . . . . . . 10 2. CDN Interconnection Use Cases . . . . . . . . . . . . . . . . 11
3. CDN Interconnection Model & Problem Area for IETF . . . . . . 12 3. CDN Interconnection Model & Problem Area for IETF . . . . . . 12
4. Scoping the CDNI Problem . . . . . . . . . . . . . . . . . . . 16 4. Scoping the CDNI Problem . . . . . . . . . . . . . . . . . . . 16
4.1. CDNI Request Routing Interface . . . . . . . . . . . . . . 17 4.1. CDNI Request Routing Interface . . . . . . . . . . . . . . 17
4.2. CDNI Metadata Interface . . . . . . . . . . . . . . . . . 17 4.2. CDNI Metadata Interface . . . . . . . . . . . . . . . . . 17
4.3. CDNI Logging Interface . . . . . . . . . . . . . . . . . . 18 4.3. CDNI Logging Interface . . . . . . . . . . . . . . . . . . 18
4.4. CDNI Control Interface . . . . . . . . . . . . . . . . . . 18 4.4. CDNI Control Interface . . . . . . . . . . . . . . . . . . 18
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
6.1. Security of the CDNI Control interface . . . . . . . . . . 19 6.1. Security of the CDNI Control interface . . . . . . . . . . 19
6.2. Security of the CDNI Request Routing Interface . . . . . . 19 6.2. Security of the CDNI Request Routing Interface . . . . . . 19
6.3. Security of the CDNI Metadata interface . . . . . . . . . 19 6.3. Security of the CDNI Metadata interface . . . . . . . . . 20
6.4. Security of the CDNI Logging interface . . . . . . . . . . 20 6.4. Security of the CDNI Logging interface . . . . . . . . . . 20
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Normative References . . . . . . . . . . . . . . . . . . . 20 8.1. Normative References . . . . . . . . . . . . . . . . . . . 20
8.2. Informative References . . . . . . . . . . . . . . . . . . 20 8.2. Informative References . . . . . . . . . . . . . . . . . . 20
Appendix A. Design considerations for realizing the CDNI Appendix A. Design considerations for realizing the CDNI
Interfaces . . . . . . . . . . . . . . . . . . . . . 23 Interfaces . . . . . . . . . . . . . . . . . . . . . 23
A.1. CDNI Request Routing Interface . . . . . . . . . . . . . . 23 A.1. CDNI Request Routing Interface . . . . . . . . . . . . . . 23
A.2. CDNI Metadata Interface . . . . . . . . . . . . . . . . . 25 A.2. CDNI Metadata Interface . . . . . . . . . . . . . . . . . 25
A.3. CDNI Logging Interface . . . . . . . . . . . . . . . . . . 26 A.3. CDNI Logging Interface . . . . . . . . . . . . . . . . . . 26
A.4. CDNI Control Interface . . . . . . . . . . . . . . . . . . 27 A.4. CDNI Control Interface . . . . . . . . . . . . . . . . . . 27
Appendix B. Additional Material . . . . . . . . . . . . . . . . . 27 Appendix B. Additional Material . . . . . . . . . . . . . . . . . 28
B.1. Non-Goals for IETF . . . . . . . . . . . . . . . . . . . . 27 B.1. Non-Goals for IETF . . . . . . . . . . . . . . . . . . . . 28
B.2. Related standardization activites . . . . . . . . . . . . 29 B.2. Relationship to relevant IETF Working Groups & IRTF
B.2.1. IETF CDI Working Group (Concluded) . . . . . . . . . . 30 Reserach Groups . . . . . . . . . . . . . . . . . . . . . 29
B.2.2. 3GPP . . . . . . . . . . . . . . . . . . . . . . . . . 30 B.2.1. ALTO WG . . . . . . . . . . . . . . . . . . . . . . . 29
B.2.3. ISO MPEG . . . . . . . . . . . . . . . . . . . . . . . 31 B.2.2. DECADE WG . . . . . . . . . . . . . . . . . . . . . . 30
B.2.4. ATIS IIF . . . . . . . . . . . . . . . . . . . . . . . 32 B.2.3. PPSP WG . . . . . . . . . . . . . . . . . . . . . . . 31
B.2.5. CableLabs . . . . . . . . . . . . . . . . . . . . . . 32 B.2.4. IRTF P2P Research Group . . . . . . . . . . . . . . . 32
B.2.6. ETSI MCD . . . . . . . . . . . . . . . . . . . . . . . 32 Appendix C. Additional Material . . . . . . . . . . . . . . . . . 32
B.2.7. ETSI TISPAN . . . . . . . . . . . . . . . . . . . . . 32 C.1. Related standardization activites . . . . . . . . . . . . 32
B.2.8. ITU-T . . . . . . . . . . . . . . . . . . . . . . . . 33 C.1.1. IETF CDI Working Group (Concluded) . . . . . . . . . . 33
B.2.9. Open IPTV Forum (OIPF) . . . . . . . . . . . . . . . . 33 C.1.2. 3GPP . . . . . . . . . . . . . . . . . . . . . . . . . 34
B.2.10. TV-Anytime Forum . . . . . . . . . . . . . . . . . . . 33 C.1.3. ISO MPEG . . . . . . . . . . . . . . . . . . . . . . . 34
B.2.11. SNIA . . . . . . . . . . . . . . . . . . . . . . . . . 34 C.1.4. ATIS IIF . . . . . . . . . . . . . . . . . . . . . . . 35
B.2.12. Summary of existing standardization work . . . . . . . 34 C.1.5. CableLabs . . . . . . . . . . . . . . . . . . . . . . 35
B.3. Related Research Projects . . . . . . . . . . . . . . . . 36 C.1.6. ETSI MCD . . . . . . . . . . . . . . . . . . . . . . . 35
B.3.1. IRTF P2P Research Group . . . . . . . . . . . . . . . 36 C.1.7. ETSI TISPAN . . . . . . . . . . . . . . . . . . . . . 36
B.3.2. OCEAN . . . . . . . . . . . . . . . . . . . . . . . . 36 C.1.8. ITU-T . . . . . . . . . . . . . . . . . . . . . . . . 36
B.3.3. Eurescom P1955 . . . . . . . . . . . . . . . . . . . . 36 C.1.9. Open IPTV Forum (OIPF) . . . . . . . . . . . . . . . . 36
B.4. Relationship to relevant IETF Working Groups . . . . . . . 37 C.1.10. TV-Anytime Forum . . . . . . . . . . . . . . . . . . . 37
B.4.1. ALTO . . . . . . . . . . . . . . . . . . . . . . . . . 37 C.1.11. SNIA . . . . . . . . . . . . . . . . . . . . . . . . . 37
B.4.2. DECADE . . . . . . . . . . . . . . . . . . . . . . . . 37 C.1.12. Summary of existing standardization work . . . . . . . 37
B.4.3. PPSP . . . . . . . . . . . . . . . . . . . . . . . . . 39 C.2. Related Research Projects . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 C.2.1. OCEAN . . . . . . . . . . . . . . . . . . . . . . . . 39
C.2.2. Eurescom P1955 . . . . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40
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
(CDNs) provide numerous benefits: reduced delivery cost for cacheable (CDNs) provide numerous benefits: reduced delivery cost for cacheable
content, improved quality of experience for End Users (EUs) and content, improved quality of experience for End Users (EUs) and
increased robustness of delivery. For these reasons CDNs are increased robustness of delivery. For these reasons CDNs are
frequently used for large-scale content delivery. As a result, frequently used for large-scale content delivery. As a result,
skipping to change at page 6, line 8 skipping to change at page 6, line 8
independent business relationship between the EU and the NSP for independent business relationship between the EU and the NSP for
the corresponding network access. the corresponding network access.
The formation and details of any business relationships between a CSP The formation and details of any business relationships between a CSP
and a CDN Provider as well as between one CDN Provider and another and a CDN Provider as well as between one CDN Provider and another
CDN Provider are out of scope of this document. However, this CDN Provider are out of scope of this document. However, this
document concerns itself with the fact that no standards or open document concerns itself with the fact that no standards or open
specifications currently exist to facilitate such CDN interconnection specifications currently exist to facilitate such CDN interconnection
from a technical perspective. from a technical perspective.
One possible flow for performing an end to end content delivery
across a CDN Interconnect is described below:
o The initial request from an EU's User Agent is first received by
the authoritative (upstream) CDN, which is the CDN with a business
arrangement with the CSP.
o The authoritative (upstream) CDN may serve the request itself, or
it may elect to use CDN Interconnect to redirect the request to a
downstream CDN that is in a better position to do so (e.g. a
downstream CDN that is "closer" to the EU).
o The EU's User Agent will "follow" the redirect returned by the
authoritative CDN and request the content from the downstream CDN.
If required the downstream CDN will acquire the requested content
from the authoritative (upstream) CDN, and if necessary the
authoritative CDN will acquire the requested content from the
Content Service Provider.
The goal of this document is to outline the problem area of CDN The goal of this document is to outline the problem area of CDN
interconnection. Section 2 discusses the use cases for CDN interconnection. Section 2 discusses the use cases for CDN
interconnection. Section 3 presents the CDNI model and problem area interconnection. Section 3 presents the CDNI model and problem area
being considered by the IETF. Section 4 describes each CDNI being considered by the IETF. Section 4 describes each CDNI
interface individually and highlights example candidate protocols interface individually and highlights example candidate protocols
that could be considered for reuse or leveraging to implement the that could be considered for reuse or leveraging to implement the
CDNI interfaces. Appendix B.2 discusses the relevant work of other CDNI interfaces. Appendix B.2 describes the relationships between
standards organizations. Appendix B.4 describes the relationships the CDNI problem space and other relevant IETF Working Groups and
between the CDNI problem space and other relevant IETF Working IRTF Reserach Groups.
Groups.
1.1. Terminology 1.1. Terminology
This document uses the following terms: This document uses the following terms:
Content: Any form of digital data. One important form of Content Content: Any form of digital data. One important form of Content
with additional constraints on distribution and delivery is with additional constraints on distribution and delivery is
continuous media (i.e. where there is a timing relationship between continuous media (i.e. where there is a timing relationship between
source and sink). source and sink).
skipping to change at page 9, line 28 skipping to change at page 9, line 44
CDN1-->CDN2) and as the Upstream CDN for the subsequent redirection CDN1-->CDN2) and as the Upstream CDN for the subsequent redirection
of the same request (e.g. CDN2-->CDN3). of the same request (e.g. CDN2-->CDN3).
Over-the-top (OTT): A service, e.g. content delivery using a CDN, Over-the-top (OTT): A service, e.g. content delivery using a CDN,
operated by a different operator than the NSP to which the users of operated by a different operator than the NSP to which the users of
that service are attached. that service are attached.
Surrogate: A device/function (often called a cache) that interacts Surrogate: A device/function (often called a cache) that interacts
with other elements of the CDN for the control and distribution of with other elements of the CDN for the control and distribution of
Content within the CDN and interacts with User Agents for the Content within the CDN and interacts with User Agents for the
delivery of the Content. delivery of the Content. Typically, surrogates will cache requested
content so that it can deliver the same content to a number of User
Agents (and their End Users) avoiding the need for those requests to
transit multiple times through the network core (i.e from the content
origin to the surrogate).
Request Routing System: The function within a CDN responsible for Request Routing System: The function within a CDN responsible for
receiving a content request from a User Agent, obtaining and receiving a content request from a User Agent, obtaining and
maintaining necessary information about a set of candidate surrogates maintaining necessary information about a set of candidate surrogates
or candidate CDNs, and for selecting and redirecting the user to the or candidate CDNs, and for selecting and redirecting the user to the
appropriate surrogate or CDN. To enable CDN Interconnection, the appropriate surrogate or CDN. To enable CDN Interconnection, the
Request Routing System must also be capable of handling User Agent Request Routing System must also be capable of handling User Agent
content requests passed to it by another CDN. content requests passed to it by another CDN.
Distribution System: The function within a CDN responsible for Distribution System: The function within a CDN responsible for
skipping to change at page 10, line 11 skipping to change at page 10, line 31
activities. The information recorded by the logging system may be activities. The information recorded by the logging system may be
used for various purposes including charging (e.g. of the CSP), used for various purposes including charging (e.g. of the CSP),
analytics and monitoring. analytics and monitoring.
Control System: The function within a CDN responsible for Control System: The function within a CDN responsible for
bootstrapping and controlling the other components of the CDN as well bootstrapping and controlling the other components of the CDN as well
as for handling interactions with external systems (e.g. handling as for handling interactions with external systems (e.g. handling
delivery service creation/update/removal requests, or specific delivery service creation/update/removal requests, or specific
service provisioning requests). service provisioning requests).
Quality of Experience (QoE): As defined in Section 2.4 of [RFC6390]
1.2. CDN Background 1.2. CDN Background
Readers are assumed to be familiar with the architecture, features Readers are assumed to be familiar with the architecture, features
and operation of CDNs. For readers less familiar with the operation and operation of CDNs. For readers less familiar with the operation
of CDNs, the following resources may be useful: of CDNs, the following resources may be useful:
o RFC 3040 [RFC3040] describes many of the component technologies o RFC 3040 [RFC3040] describes many of the component technologies
that are used in the construction of a CDN. that are used in the construction of a CDN.
o Taxonomy [TAXONOMY] compares the architecture of a number of CDNs. o Taxonomy [TAXONOMY] compares the architecture of a number of CDNs.
o RFC 3466 [RFC3466] and RFC 3570 [RFC3570] are the output of the o RFC 3466 [RFC3466] and RFC 3570 [RFC3570] are the output of the
skipping to change at page 18, line 9 skipping to change at page 18, line 9
Therefore, like the CDNI Request Routing interface, the CDNI Metadata Therefore, like the CDNI Request Routing interface, the CDNI Metadata
interface may be implemented as a WebService using one of the common interface may be implemented as a WebService using one of the common
WebServices methodologies (XML-RPC, HTTP query to a known URI, etc.) WebServices methodologies (XML-RPC, HTTP query to a known URI, etc.)
or possibly using other existing protocols such as XMPP [RFC6120]. or possibly using other existing protocols such as XMPP [RFC6120].
This removes the need for the CDNI working group to define a new This removes the need for the CDNI working group to define a new
protocol for the request/response element of the CDNI Metadata protocol for the request/response element of the CDNI Metadata
interface. interface.
4.3. CDNI Logging Interface 4.3. CDNI Logging Interface
The CDNI Logging interface enables details of logs or events to be The CDNI Logging interface enables details of content distribution
exchanged between interconnected CDNs, where events could be for and delivery activities to be exchanged between interconnected CDNs.
example log records related to the delivery of content (similar to For example the exchange of log records related to the delivery of
the log records recorded in a web server's access log) as well as content, similar to the log records recorded in a web server's access
real-time or near-real time events before, during or after content log.
delivery and operations and diagnostic messages.
Several protocols already exist that could potentially be used to Several protocols already exist that could potentially be used to
exchange CDNI logs between interconnected CDNs including SNMP, exchange CDNI logs between interconnected CDNs including SNMP,
syslog, ftp (and secure variants), HTTP POST, etc. syslog, ftp (and secure variants), HTTP POST, etc.
4.4. CDNI Control Interface 4.4. CDNI Control Interface
The CDNI Control interface allows the Control System in The CDNI Control interface allows the Control System in
interconnected CDNs to communicate. The exact inter-CDN control interconnected CDNs to communicate. The exact inter-CDN control
functionality required to be supported by the CDNI Control interface functionality required to be supported by the CDNI Control interface
skipping to change at page 19, line 7 skipping to change at page 19, line 6
logging information generated by the CDN for the purposes of charging logging information generated by the CDN for the purposes of charging
the CSP. These security aspects are already dealt with by CDN the CSP. These security aspects are already dealt with by CDN
Providers and CSPs today in the context of standalone CDNs. However, Providers and CSPs today in the context of standalone CDNs. However,
interconnection of CDNs introduces a new set of security interconnection of CDNs introduces a new set of security
considerations by extending the trust model to a chain of trust (i.e. considerations by extending the trust model to a chain of trust (i.e.
the CSP "trusts" a CDN that "trusts" another CDN). The mechanisms the CSP "trusts" a CDN that "trusts" another CDN). The mechanisms
used to mitigate these risks in multi-CDN environments may be similar used to mitigate these risks in multi-CDN environments may be similar
to those used in the single CDN case, but their suitability in this to those used in the single CDN case, but their suitability in this
more complex environment must be validated. more complex environment must be validated.
The interconnection of CDNs may also introduce additional privacy
considerations on top of those that apply to the single CDN case. In
a multi-CDN environment, the different CDNs may reside in different
legal regimes that require differing privacy requirements to be
enforced. Such privacy requirements may impact the granularity of
information that can be exchanged across the CDNI interfaces. For
example the Logging System in a downstream CDN may need to apply some
degree of anonymization, obfuscation or even the complete removal of
some fields before exchanging log records containing details of End
User deliveries with an upstream CDN.
Maintaining the security of the content itself, its associated Maintaining the security of the content itself, its associated
metadata (including delivery policies) and the CDNs distributing and metadata (including delivery policies) and the CDNs distributing and
delivering it, are critical requirements for both CDN Providers and delivering it, are critical requirements for both CDN Providers and
CSPs and the CDN Interconnection interfaces must provide sufficient CSPs and the CDN Interconnection interfaces must provide sufficient
mechanisms to maintain the security of the overall system of mechanisms to maintain the security of the overall system of
interconnected CDNs as well as the information (content, metadata, interconnected CDNs as well as the information (content, metadata,
logs, etc) distributed and delivered through any set of logs, etc) distributed and delivered through any set of
interconnected CDNs. interconnected CDNs.
6.1. Security of the CDNI Control interface 6.1. Security of the CDNI Control interface
Information on this interface is of a very private nature between Information exchanged between interconnected CDNs over this interface
interconnected CDNs. A pair of CDNs use this interface to allow is of a sensitive nature. A pair of CDNs use this interface to allow
bootstrapping of all the other CDNI interfaces possibly including bootstrapping of all the other CDNI interfaces possibly including
establishment of the mechanisms for securing these interfaces. establishment of the mechanisms for securing these interfaces.
Therefore, corruption of that interface may result in corruption of Therefore, corruption of that interface may result in corruption of
all other interfaces. Using this interface, an upstream CDN may pre- all other interfaces. Using this interface, an upstream CDN may pre-
position or delete content or metadata in a downstream CDN and a position or delete content or metadata in a downstream CDN and a
downstream CDN may provide administrative information to an upstream downstream CDN may provide administrative information to an upstream
CDN, etc. All of these operations require that the peer CDNs are CDN, etc. All of these operations require that the peer CDNs are
appropriately authenticated and that the confidentiality and appropriately authenticated and that the confidentiality and
integrity of information flowing between them can be ensured. integrity of information flowing between them can be ensured.
skipping to change at page 21, line 27 skipping to change at page 21, line 36
"IETF DECADE WG Charter "IETF DECADE WG Charter
(http://datatracker.ietf.org/wg/decade/charter/)". (http://datatracker.ietf.org/wg/decade/charter/)".
[I-D.bertrand-cdni-experiments] [I-D.bertrand-cdni-experiments]
Faucheur, F. and L. Peterson, "Content Distribution Faucheur, F. and L. Peterson, "Content Distribution
Network Interconnection (CDNI) Experiments", Network Interconnection (CDNI) Experiments",
draft-bertrand-cdni-experiments-02 (work in progress), draft-bertrand-cdni-experiments-02 (work in progress),
February 2012. February 2012.
[I-D.ietf-cdni-use-cases] [I-D.ietf-cdni-use-cases]
Bertrand, G., Emile, S., Watson, G., Burbridge, T., Bertrand, G., Emile, S., Burbridge, T., Eardley, P., Ma,
Eardley, P., and K. Ma, "Use Cases for Content Delivery K., and G. Watson, "Use Cases for Content Delivery Network
Network Interconnection", draft-ietf-cdni-use-cases-04 Interconnection", draft-ietf-cdni-use-cases-08 (work in
(work in progress), March 2012. progress), June 2012.
[I-D.jenkins-alto-cdn-use-cases] [I-D.jenkins-alto-cdn-use-cases]
Previdi, S., Watson, G., Medved, J., Bitar, N., and B. Niven-Jenkins, B., Watson, G., Bitar, N., Medved, J., and
Niven-Jenkins, "Use Cases for ALTO within CDNs", S. Previdi, "Use Cases for ALTO within CDNs",
draft-jenkins-alto-cdn-use-cases-02 (work in progress), draft-jenkins-alto-cdn-use-cases-03 (work in progress),
December 2011. June 2012.
[MPEG-DASH] [MPEG-DASH]
"Information technology - MPEG systems technologies - Part "Information technology - MPEG systems technologies - Part
6: Dynamic adaptive streaming over HTTP (DASH), (DIS 6: Dynamic adaptive streaming over HTTP (DASH), (DIS
version), February 2011 version), February 2011
http://mpeg.chiariglione.org/ http://mpeg.chiariglione.org/
working_documents.htm#MPEG-B". working_documents.htm#MPEG-B".
[OIPF-Overview] [OIPF-Overview]
"OIPF Release 2 Specification Volume 1 - Overview", "OIPF Release 2 Specification Volume 1 - Overview",
skipping to change at page 22, line 38 skipping to change at page 22, line 48
[RFC5023] Gregorio, J. and B. de hOra, "The Atom Publishing [RFC5023] Gregorio, J. and B. de hOra, "The Atom Publishing
Protocol", RFC 5023, October 2007. Protocol", RFC 5023, October 2007.
[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic
Optimization (ALTO) Problem Statement", RFC 5693, Optimization (ALTO) Problem Statement", RFC 5693,
October 2009. October 2009.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 6120, March 2011. Protocol (XMPP): Core", RFC 6120, March 2011.
[RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New
Performance Metric Development", BCP 170, RFC 6390,
October 2011.
[SNIA-CDMI] [SNIA-CDMI]
"SNIA CDMI (http://www.snia.org/tech_activities/standards/ "SNIA CDMI (http://www.snia.org/tech_activities/standards/
curr_standards/cdmi)". curr_standards/cdmi)".
[TAXONOMY] [TAXONOMY]
Pathan, A., "A Taxonomy and Survey of Content Delivery Pathan, A., "A Taxonomy and Survey of Content Delivery
Networks Networks
(http://www.gridbus.org/reports/CDN-Taxonomy.pdf)", 2007. (http://www.gridbus.org/reports/CDN-Taxonomy.pdf)", 2007.
[Y.1910] "ITU-T Recomendation Y.1910 "IPTV functional [Y.1910] "ITU-T Recomendation Y.1910 "IPTV functional
skipping to change at page 27, line 41 skipping to change at page 28, line 7
its delivery capabilities, resources and policies. its delivery capabilities, resources and policies.
o Allow bootstrapping of the interface between CDNs for content o Allow bootstrapping of the interface between CDNs for content
acquisition (even if that interface itself is outside the scope of acquisition (even if that interface itself is outside the scope of
the CDNI work). the CDNI work).
It is expected that for the Control interface also, existing It is expected that for the Control interface also, existing
protocols can be reused or leveraged. Those will be considered once protocols can be reused or leveraged. Those will be considered once
the requirements for the Control interface have been refined. the requirements for the Control interface have been refined.
Appendix B. Additional Material Appendix B. Additional Material
Note to RFC Editor: This appendix is to be removed on publication as This section records related information that was produced as part of
an RFC. defining the CDNI problem statement.
B.1. Non-Goals for IETF B.1. Non-Goals for IETF
Listed below are aspects of content delivery that the authors propose Listed below are aspects of content delivery that the authors propose
be kept outside of the scope of a potential CDNI working group: be kept outside of the scope of the CDNI working group:
o The interface between Content Service Provider and the o The interface between Content Service Provider and the
Authoritative CDN (i.e. the upstream CDN contracted by the CSP for Authoritative CDN (i.e. the upstream CDN contracted by the CSP for
delivery by this CDN or by its downstream CDNs). delivery by this CDN or by its downstream CDNs).
o The delivery interface between the delivering CDN surrogate and o The delivery interface between the delivering CDN surrogate and
the User Agent, such as streaming protocols. the User Agent, such as streaming protocols.
o The request interface between the User Agent and the request- o The request interface between the User Agent and the request-
routing system of a given CDN. Existing IETF protocols (e.g. routing system of a given CDN. Existing IETF protocols (e.g.
HTTP, RTSP, DNS) are commonly used by User Agents to request HTTP, RTSP, DNS) are commonly used by User Agents to request
content from a CDN and by CDN request routing systems to redirect content from a CDN and by CDN request routing systems to redirect
the User Agent requests. The CDNI working group need not define the User Agent requests. The CDNI working group need not define
new protocols for this purpose. Note however, that the CDNI new protocols for this purpose. Note however, that the CDNI
control plane interface may indirectly affect some of the control plane interface may indirectly affect some of the
information exchanged through the request interface (e.g. URI). information exchanged through the request interface (e.g. URI).
skipping to change at page 29, line 9 skipping to change at page 29, line 23
acquisition methods are outside the scope of the CDNI work. acquisition methods are outside the scope of the CDNI work.
Content management (e.g. Content Deletion) as it relates to CDNI Content management (e.g. Content Deletion) as it relates to CDNI
content management policies, is in scope but the internal content management policies, is in scope but the internal
algorithms used by a cache to determine when to no longer cache an algorithms used by a cache to determine when to no longer cache an
item of Content (in the absence of any specific metadata to the item of Content (in the absence of any specific metadata to the
contrary) is out of scope. contrary) is out of scope.
o Element management interfaces. o Element management interfaces.
o Commercial, business and legal aspects related to the o Commercial, business and legal aspects related to the
interconnections of CDNs. interconnections of CDNs.
B.2. Related standardization activites B.2. Relationship to relevant IETF Working Groups & IRTF Reserach
Groups
B.2.1. ALTO WG
As stated in the ALTO Working Group charter [ALTO-Charter]:
"The Working Group will design and specify an Application-Layer
Traffic Optimization (ALTO) service that will provide applications
with information to perform better-than-random initial peer
selection. ALTO services may take different approaches at balancing
factors such as maximum bandwidth, minimum cross-domain traffic,
lowest cost to the user, etc. The working group will consider the
needs of BitTorrent, tracker-less P2P, and other applications, such
as content delivery networks (CDN) and mirror selection."
In particular, the ALTO service can be used by a CDN Request Routing
system to improve its selection of a CDN surrogate to serve a
particular User Agent request (or to serve a request from another
surrogate). [I-D.jenkins-alto-cdn-use-cases] describes a number of
use cases for a CDN to be able to obtain network topology and cost
information from an ALTO server(s) and discusses how CDN Request
Routing could be used as an integration point of ALTO into CDNs. It
is possible that the ALTO service could be used in the same manner in
a multi-CDN environment based on CDN Interconnection. For example,
an upstream CDN may take advantage of the ALTO service in its
decision for selecting a downstream CDN to which a user request
should be delegated.
However, the current work of ALTO is complementary to and does not
overlap with the work described in this document because the
integration between ALTO and a CDN is an internal decision for a
specific CDN and is therefore out of scope for the CDNI working
group. One area for further study is whether additional information
should be provided by an ALTO service to facilitate CDNI CDN
selection.
B.2.2. DECADE WG
The DECADE Working Group [DECADE-Charter] is addressing the problem
of reducing traffic on the last-mile uplink, as well as backbone and
transit links caused by P2P streaming and file sharing applications.
It addresses the problem by enabling an application endpoint to make
content available from an in-network storage service and by enabling
other application endpoints to retrieve the content from there.
Exchanging data through the in-network storage service in this
manner, instead of through direct communication, provides significant
gain where:
o The network capacity/bandwidth from in-network storage service to
application endpoint significantly exceeds the capacity/bandwidth
from application endpoint to application endpoint (e.g. because of
an end-user uplink bottleneck); and
o Where the content is to be accessed by multiple instances of
application endpoints (e.g. as is typically the case for P2P
applications).
While, as is the case for any other data distribution application,
the DECADE architecture and mechanisms could potentially be used for
exchange of CDNI control plane information via an in-network-storage
service (as opposed to directly between the entities terminating the
CDNI interfaces in the neighbor CDNs), we observe that:
o CDNI would operate as a "Content Distribution Application" from
the DECADE viewpoint (i.e. would operate on top of DECADE).
o There does not seem to be obvious benefits in integrating the
DECADE control plane responsible for signaling information
relating to control of the in-network storage service itself, and
the CDNI control plane responsible for application-specific CDNI
interactions (such as exchange of CDNI metadata, CDNI request
redirection, transfer of CDNI logging information).
o There would typically be limited benefits in making use of a
DECADE in-network storage service because the CDNI interfaces are
expected to be terminated by a very small number of CDNI clients
(if not one) in each CDN, and the CDNI clients are expected to
benefit from high bandwidth/capacity when communicating directly
to each other (at least as high as if they were communicating via
an in-network storage server).
The DECADE in-network storage architecture and mechanisms may
theoretically be used for the acquisition of the content objects
themselves between interconnected CDNs. It is not expected that this
would have obvious benefits in typical situations where a content
object is acquired only once from an Upstream CDN to a Downstream CDN
(and then distributed as needed inside the Downstream CDN). But it
might have benefits in some particular situations. Since the
acquisition protocol between CDNs is outside the scope of the CDNI
work, this question is left for further study.
The DECADE in-network storage architecture and mechanisms may
potentially also be used within a given CDN for the distribution of
the content objects themselves among surrogates of that CDN. Since
the CDNI work does not concern itself with operation within a CDN,
this question is left for further study.
Therefore, the work of DECADE may be complementary to but does not
overlap with the CDNI work described in this document.
B.2.3. PPSP WG
As stated in the PPSP Working Group charter [PPSP-Charter]:
"The Peer-to-Peer Streaming Protocol (PPSP) working group develops
two signaling and control protocols for a peer-to-peer (P2P)
streaming system for transmitting live and time-shifted media content
with near real-time delivery requirements." and "The PPSP working
group designs a protocol for signaling and control between trackers
and peers (the PPSP "tracker protocol") and a signaling and control
protocol for communication among the peers (the PPSP "peer
protocol"). The two protocols enable peers to receive streaming data
within the time constraints required by specific content items."
Therefore PPSP is concerned with the distribution of the streamed
content itself along with the necessary signaling and control
required to distribute the content. As such, it could potentially be
used for the acquisition of streamed content across interconnected
CDNs. But since the acquisition protocol is outside the scope of the
work proposed for CDNI, we leave this for further study. Also,
because of its streaming nature, PPSP is not seen as applicable to
the distribution and control of the CDNI control plane and CDNI data
representations.
Therefore, the work of PPSP may be complementary to but does not
overlap with the work described in this document for CDNI.
B.2.4. IRTF P2P Research Group
Some information on CDN interconnection motivations and technical
issues were presented in the P2P RG at IETF 77. The presentation can
be found in [P2PRG-CDNI].
Appendix C. Additional Material
Note to RFC Editor: This appendix is to be removed on publication as
an RFC.
C.1. Related standardization activites
There are a number of other standards bodies and industry forums that There are a number of other standards bodies and industry forums that
are working in areas related to CDNs, and in some cases related to are working in areas related to CDNs, and in some cases related to
CDNI. This section outlines any potential overlap with the work of CDNI. This section outlines any potential overlap with the work of
the CDNI working group and any component that could potentially be the CDNI working group and any component that could potentially be
reused to realize the CDNI interfaces. reused to realize the CDNI interfaces.
A number of standards bodies have produced specifications related to A number of standards bodies have produced specifications related to
CDNs, for example: CDNs, for example:
skipping to change at page 30, line 8 skipping to change at page 33, line 15
at that time (2003) there was not enough industry interest and at that time (2003) there was not enough industry interest and
real life requirements to justify rechartering the working group real life requirements to justify rechartering the working group
to conduct the corresponding protocol work. to conduct the corresponding protocol work.
Although some of the specifications describe multi-CDN cooperation or Although some of the specifications describe multi-CDN cooperation or
include reference points for interconnecting CDNs, none of them include reference points for interconnecting CDNs, none of them
specify in sufficient detail all the CDNI interfaces and CDNI specify in sufficient detail all the CDNI interfaces and CDNI
Metadata representations required to enable even a base level of CDN Metadata representations required to enable even a base level of CDN
Interconnection functionality to be implemented. Interconnection functionality to be implemented.
B.2.1. IETF CDI Working Group (Concluded) C.1.1. IETF CDI Working Group (Concluded)
The Content Distribution Internetworking (CDI) Working Group was The Content Distribution Internetworking (CDI) Working Group was
formed in the IETF following a BoF in December 2000 and closed in mid formed in the IETF following a BoF in December 2000 and closed in mid
2003. 2003.
For convenience, here is an extract from the CDI working group For convenience, here is an extract from the CDI working group
charter [CDI-Charter]: charter [CDI-Charter]:
" "
skipping to change at page 30, line 44 skipping to change at page 34, line 4
" "
Thus, the CDI working group touched on the same problem space as the Thus, the CDI working group touched on the same problem space as the
present document. present document.
The CDI working group published 3 Informational RFCs: The CDI working group published 3 Informational RFCs:
o RFC 3466 [RFC3466] - "A Model for Content Internetworking (CDI)". o RFC 3466 [RFC3466] - "A Model for Content Internetworking (CDI)".
o RFC 3568 [RFC3568] - "Known Content Network (CN) Request-Routing o RFC 3568 [RFC3568] - "Known Content Network (CN) Request-Routing
Mechanisms". Mechanisms".
o RFC 3570 [RFC3570] - "Content Internetworking (CDI) Scenarios". o RFC 3570 [RFC3570] - "Content Internetworking (CDI) Scenarios".
B.2.2. 3GPP C.1.2. 3GPP
3GPP was the first organization that released a specification related 3GPP was the first organization that released a specification related
to adaptive streaming over HTTP. 3GPP Release 9 specification on to adaptive streaming over HTTP. 3GPP Release 9 specification on
adaptive HTTP streaming was published in March 2010, and there have adaptive HTTP streaming was published in March 2010, and there have
been some bug fixes on this specification since the publication. In been some bug fixes on this specification since the publication. In
addition, 3GPP has produced an extended version for Release 10, which addition, 3GPP has produced an extended version for Release 10, which
was published in 2011. This release will include a number of was published in 2011. This release will include a number of
clarifications, improvements and new features. clarifications, improvements and new features.
[3GP-DASH] is defined as a general framework independent of the data [3GP-DASH] is defined as a general framework independent of the data
skipping to change at page 31, line 26 skipping to change at page 34, line 35
The content retrieved by a client using [3GP-DASH] adaptive streaming The content retrieved by a client using [3GP-DASH] adaptive streaming
could be obtained from a CDN but this is not discussed or specified could be obtained from a CDN but this is not discussed or specified
in the 3GPP specifications as it is transparent to [3GP-DASH] in the 3GPP specifications as it is transparent to [3GP-DASH]
operations. Similarly, it is expected that [3GP-DASH] can be used operations. Similarly, it is expected that [3GP-DASH] can be used
transparently from the CDNs as a delivery protocol (between the transparently from the CDNs as a delivery protocol (between the
delivering CDN surrogate and the User Agent) in a CDN Interconnection delivering CDN surrogate and the User Agent) in a CDN Interconnection
environment. [3GP-DASH] could also be a candidate for content environment. [3GP-DASH] could also be a candidate for content
acquisition between CDNs in a CDN Interconnection environment. acquisition between CDNs in a CDN Interconnection environment.
B.2.3. ISO MPEG C.1.3. ISO MPEG
Within ISO MPEG, the Dynamic Adaptive Streaming over HTTP (DASH) ad- Within ISO MPEG, the Dynamic Adaptive Streaming over HTTP (DASH) ad-
hoc group adopted the 3GPP Release 9 [3GP-DASH] specification as a hoc group adopted the 3GPP Release 9 [3GP-DASH] specification as a
starting point and has made some improvements and extensions. starting point and has made some improvements and extensions.
Similar to 3GPP SA4, the MPEG DASH ad-hoc group has been working on Similar to 3GPP SA4, the MPEG DASH ad-hoc group has been working on
standardizing the manifest file and the delivery format. standardizing the manifest file and the delivery format.
Additionally, the MPEG DASH ad-hoc group has also been working on the Additionally, the MPEG DASH ad-hoc group has also been working on the
use of MPEG-2 Transport Streams as a media format, conversion from/to use of MPEG-2 Transport Streams as a media format, conversion from/to
existing file formats, common encryption, and so on. The MPEG DASH existing file formats, common encryption, and so on. The MPEG DASH
specification could also be a candidate for delivery to the User specification could also be a candidate for delivery to the User
skipping to change at page 32, line 5 skipping to change at page 35, line 10
February 2011. February 2011.
In the 95th MPEG meeting in January 2011, the DASH ad-hoc group In the 95th MPEG meeting in January 2011, the DASH ad-hoc group
decided to start a new evaluation experiment called "CDN-EE". The decided to start a new evaluation experiment called "CDN-EE". The
goals are to understand the requirements for MPEG DASH to better goals are to understand the requirements for MPEG DASH to better
support CDN-based delivery, and to provide a guidelines document for support CDN-based delivery, and to provide a guidelines document for
CDN operators to better support MPEG DASH streaming services. The CDN operators to better support MPEG DASH streaming services. The
ongoing work is still very preliminary and does not currently target ongoing work is still very preliminary and does not currently target
looking into CDN Interconnection use cases. looking into CDN Interconnection use cases.
B.2.4. ATIS IIF C.1.4. ATIS IIF
ATIS ([ATIS]) IIF is the IPTV Interoperability Forum (within ATIS) ATIS ([ATIS]) IIF is the IPTV Interoperability Forum (within ATIS)
that develops requirements, standards, and specifications for IPTV. that develops requirements, standards, and specifications for IPTV.
ATIS IIF is developing the "IPTV Content on Demand (CoD) Service" ATIS IIF is developing the "IPTV Content on Demand (CoD) Service"
specification. This includes use of a CDN (referred to in ATIS IIF specification. This includes use of a CDN (referred to in ATIS IIF
CoD as the "Content Distribution and Delivery Functions") for support CoD as the "Content Distribution and Delivery Functions") for support
of a Content on Demand (CoD) Service as part of a broader IPTV of a Content on Demand (CoD) Service as part of a broader IPTV
service. However, this only covers the case of a managed IPTV service. However, this only covers the case of a managed IPTV
service (in particular where the CDN is administered by the service service (in particular where the CDN is administered by the service
provider) and does not cover the use, or interconnection, of multiple provider) and does not cover the use, or interconnection, of multiple
CDNs. CDNs.
B.2.5. CableLabs C.1.5. CableLabs
"Founded in 1988 by cable operating companies, Cable Television "Founded in 1988 by cable operating companies, Cable Television
Laboratories, Inc. (CableLabs) is a non-profit research and Laboratories, Inc. (CableLabs) is a non-profit research and
development consortium that is dedicated to pursuing new cable development consortium that is dedicated to pursuing new cable
telecommunications technologies and to helping its cable operator telecommunications technologies and to helping its cable operator
members integrate those technical advancements into their business members integrate those technical advancements into their business
objectives." [CableLabs] objectives." [CableLabs]
CableLabs has defined specifications for CoD Content Metadata as part CableLabs has defined specifications for CoD Content Metadata as part
of its VOD Metadata project. of its VOD Metadata project.
B.2.6. ETSI MCD C.1.6. ETSI MCD
ETSI MCD (Media Content Distribution) is the ETSI technical committee ETSI MCD (Media Content Distribution) is the ETSI technical committee
"in charge of guiding and coordinating standardization work aiming at "in charge of guiding and coordinating standardization work aiming at
the successful overall development of multimedia systems (television the successful overall development of multimedia systems (television
and communication) responding to the present and future market and communication) responding to the present and future market
requests on media content distribution". requests on media content distribution".
MCD created a specific work item on interconnection of heterogeneous MCD created a specific work item on interconnection of heterogeneous
CDNs ("CDN Interconnection, use cases and requirements") in March CDNs ("CDN Interconnection, use cases and requirements") in March
2010. MCD very recently created a working group to progress this 2010. MCD very recently created a working group to progress this
work item. However, no protocol level work has yet started in MCD work item. However, no protocol level work has yet started in MCD
for CDN Interconnection. for CDN Interconnection.
B.2.7. ETSI TISPAN C.1.7. ETSI TISPAN
ETSI TISPAN has published two sets of IPTV specifications, one of ETSI TISPAN has published two sets of IPTV specifications, one of
which is based on IMS. In addition, TISPAN has published a CDN which is based on IMS. In addition, TISPAN has published a CDN
architecture supporting delivery of various content services such as architecture supporting delivery of various content services such as
time-shifted TV and VoD to TISPAN devices (UEs) or regular PCs. The time-shifted TV and VoD to TISPAN devices (UEs) or regular PCs. The
use cases allow for hierarchically and geographically distributed CDN use cases allow for hierarchically and geographically distributed CDN
scenarios, along with multi-CDN cooperation. As a result, the scenarios, along with multi-CDN cooperation. As a result, the
architecture contains reference points to support interconnection of architecture contains reference points to support interconnection of
other TISPAN CDNs. The protocol definition phase for the other TISPAN CDNs. The protocol definition phase for the
corresponding CDN architecture was kicked-off at the end of 2010 as corresponding CDN architecture was kicked-off at the end of 2010 as
is still in progress. In line with its long history of leveraging is still in progress. In line with its long history of leveraging
IETF protocols, ETSI could potentially leverage CDNI interfaces IETF protocols, ETSI could potentially leverage CDNI interfaces
developed in the IETF for their related protocol level work on developed in the IETF for their related protocol level work on
interconnections of CDNs. interconnections of CDNs.
B.2.8. ITU-T C.1.8. ITU-T
SG13 is developing standards related to the support of IPTV services SG13 is developing standards related to the support of IPTV services
(i.e.. multimedia services such as television/VoD/audio/text/ (i.e.. multimedia services such as television/VoD/audio/text/
graphics/data delivered over IP-based managed networks). graphics/data delivered over IP-based managed networks).
ITU-T Recommendation Y.1910 [Y.1910] provides the description of the ITU-T Recommendation Y.1910 [Y.1910] provides the description of the
IPTV functional architecture. This architecture includes functions IPTV functional architecture. This architecture includes functions
and interfaces for the distribution and delivery of content. This and interfaces for the distribution and delivery of content. This
architecture is aligned with the ATIS IIF architecture. architecture is aligned with the ATIS IIF architecture.
Based upon ITU-T Rec. Y.1910, ITU-T Rec. Y.2019 [Y.2019] describes in Based upon ITU-T Rec. Y.1910, ITU-T Rec. Y.2019 [Y.2019] describes in
more detail the content delivery functional architecture. This more detail the content delivery functional architecture. This
architecture allows CDN Interconnection: some interfaces (such as D3, architecture allows CDN Interconnection: some interfaces (such as D3,
D4) at the control level allow relationships between different CDNs, D4) at the control level allow relationships between different CDNs,
in the same domain or in different domains. Generic procedures are in the same domain or in different domains. Generic procedures are
described, but the choice of the protocols is open. described, but the choice of the protocols is open.
B.2.9. Open IPTV Forum (OIPF) C.1.9. Open IPTV Forum (OIPF)
The Open IPTV Forum has developed an end-to-end solution to allow any The Open IPTV Forum has developed an end-to-end solution to allow any
OIPF terminal to access enriched and personalized IPTV services OIPF terminal to access enriched and personalized IPTV services
either in a managed or a non-managed network[OIPF-Overview]. Some either in a managed or a non-managed network[OIPF-Overview]. Some
OIPF services (such as Network PVR) may be hosted in a CDN. OIPF services (such as Network PVR) may be hosted in a CDN.
To that end, the Open IPTV Forum specification is made of 5 parts: To that end, the Open IPTV Forum specification is made of 5 parts:
o Media Formats including HTTP Adaptive Streaming o Media Formats including HTTP Adaptive Streaming
o Content Metadata o Content Metadata
o Protocols o Protocols
o Terminal (Declarative or Procedural Application Environment) o Terminal (Declarative or Procedural Application Environment)
o Authentication, Content Protection and Service Protection o Authentication, Content Protection and Service Protection
B.2.10. TV-Anytime Forum C.1.10. TV-Anytime Forum
Version 1 of the TV-Anytime Forum specifications were published as Version 1 of the TV-Anytime Forum specifications were published as
ETSI TS 102 822-1 through ETSI TS 102 822-7 "Broadcast and On-line ETSI TS 102 822-1 through ETSI TS 102 822-7 "Broadcast and On-line
Services: Search, select, and rightful use of content on personal Services: Search, select, and rightful use of content on personal
storage systems ("TV-Anytime")". It includes the specification of storage systems ("TV-Anytime")". It includes the specification of
content metadata in XML schemas (ETSI TS 102 822-3) which define content metadata in XML schemas (ETSI TS 102 822-3) which define
technical parameters for the description of CoD and Live contents. technical parameters for the description of CoD and Live contents.
The specification is referenced by DVB and OIPF. The specification is referenced by DVB and OIPF.
The TV-anytime Forum was closed in 2005. The TV-anytime Forum was closed in 2005.
B.2.11. SNIA C.1.11. SNIA
The Storage Networking Industry Association (SNIA) is an association The Storage Networking Industry Association (SNIA) is an association
of producers and consumers of storage networking products whose goal of producers and consumers of storage networking products whose goal
is to further storage networking technology and applications. is to further storage networking technology and applications.
SNIA has published the Cloud Data Management Interface (CDMI) SNIA has published the Cloud Data Management Interface (CDMI)
standard ([SNIA-CDMI]). standard ([SNIA-CDMI]).
"The Cloud Data Management Interface defines the functional interface "The Cloud Data Management Interface defines the functional interface
that applications will use to create, retrieve, update and delete that applications will use to create, retrieve, update and delete
data elements from the Cloud. As part of this interface the client data elements from the Cloud. As part of this interface the client
will be able to discover the capabilities of the cloud storage will be able to discover the capabilities of the cloud storage
offering and use this interface to manage containers and the data offering and use this interface to manage containers and the data
that is placed in them. In addition, metadata can be set on that is placed in them. In addition, metadata can be set on
containers and their contained data elements through this interface." containers and their contained data elements through this interface."
B.2.12. Summary of existing standardization work C.1.12. Summary of existing standardization work
The following sections will summarize the existing work of the The following sections will summarize the existing work of the
standard bodies listed earlier against the CDNI problem space. standard bodies listed earlier against the CDNI problem space.
Appendix B.2.12.1 summarizes existing interfaces that could be Appendix C.1.12.1 summarizes existing interfaces that could be
leveraged for content acquisition between CDNs and Appendix B.2.12.2 leveraged for content acquisition between CDNs and Appendix C.1.12.2
summarizes existing metadata specifications that may be applicable to summarizes existing metadata specifications that may be applicable to
CDNI. To date we are not aware of any standardization activities in CDNI. To date we are not aware of any standardization activities in
the areas of the remaining CDNI interfaces (CDNI Request Routing, the areas of the remaining CDNI interfaces (CDNI Request Routing,
CDNI Control and CDNI Logging). CDNI Control and CDNI Logging).
B.2.12.1. Content Acquisition across CDNs and Delivery to End User C.1.12.1. Content Acquisition across CDNs and Delivery to End User
(Data plane) (Data plane)
A number of standards bodies have completed work in the areas of A number of standards bodies have completed work in the areas of
content acquisition interface between a CSP and a CDN, as well as as content acquisition interface between a CSP and a CDN, as well as as
on the delivery interface between the surrogate and the User Agent. on the delivery interface between the surrogate and the User Agent.
Some of this work is summarized below. Some of this work is summarized below.
TISPAN, OIPF and ATIS have specified IPTV and/or Content on Demand TISPAN, OIPF and ATIS have specified IPTV and/or Content on Demand
(CoD) services, including the data plane aspects (typically different (CoD) services, including the data plane aspects (typically different
flavors of RTP/RTCP and HTTP) to obtain content and deliver it to flavors of RTP/RTCP and HTTP) to obtain content and deliver it to
skipping to change at page 35, line 28 skipping to change at page 38, line 36
specifications (e.g. vendor specific HTTP Adaptive streaming specifications (e.g. vendor specific HTTP Adaptive streaming
specifications) so that content delivery can be considered already specifications) so that content delivery can be considered already
solved (or at least sufficiently addressed in other forums). solved (or at least sufficiently addressed in other forums).
Thus, specification of the content acquisition interface between CDNs Thus, specification of the content acquisition interface between CDNs
and the delivery interface between the surrogate and the User Agent and the delivery interface between the surrogate and the User Agent
are out of scope for the CDNI working group. The CDNI working group are out of scope for the CDNI working group. The CDNI working group
may only concern itself with the negotiation/selection aspects of the may only concern itself with the negotiation/selection aspects of the
acquisition protocol to be used in a CDN interonnect scenario. acquisition protocol to be used in a CDN interonnect scenario.
B.2.12.2. CDNI Metadata C.1.12.2. CDNI Metadata
CableLabs, ITU, OIPF and TV-Anytime have work items dedicated to the CableLabs, ITU, OIPF and TV-Anytime have work items dedicated to the
specification of content metadata: specification of content metadata:
o CableLabs has defined specifications for CoD Content Metadata as o CableLabs has defined specifications for CoD Content Metadata as
part of its VOD Metadata project. "The VOD Metadata project is a part of its VOD Metadata project. "The VOD Metadata project is a
cable television industry and cross-industry-wide effort to cable television industry and cross-industry-wide effort to
specify the metadata and interfaces for distribution of video-on- specify the metadata and interfaces for distribution of video-on-
demand (VOD) material from multiple content providers to cable demand (VOD) material from multiple content providers to cable
operators." [CableLabs-Metadata]. However, while the CableLabs operators." [CableLabs-Metadata]. However, while the CableLabs
skipping to change at page 36, line 20 skipping to change at page 39, line 32
origin server or acquire it from the upstream CDN etc. origin server or acquire it from the upstream CDN etc.
The CDMI standard ([SNIA-CDMI]) from SNIA defines metadata that can The CDMI standard ([SNIA-CDMI]) from SNIA defines metadata that can
be associated with data that is stored by a cloud storage provider. be associated with data that is stored by a cloud storage provider.
While the metadata currently defined do not match the needs of CDN While the metadata currently defined do not match the needs of CDN
Interconnection, it is worth considering CDMI as one of the existing Interconnection, it is worth considering CDMI as one of the existing
pieces of work that may potentially be leveraged for the CDNI pieces of work that may potentially be leveraged for the CDNI
Metadata interface (e.g by extending the CDMI metadata to address Metadata interface (e.g by extending the CDMI metadata to address
more specific CDNI needs). more specific CDNI needs).
B.3. Related Research Projects C.2. Related Research Projects
B.3.1. IRTF P2P Research Group
Some information on CDN interconnection motivations and technical
issues were presented in the P2P RG at IETF 77. The presentation can
be found in [P2PRG-CDNI].
B.3.2. OCEAN C.2.1. OCEAN
OCEAN (http://www.ict-ocean.eu/) is an EU funded research project OCEAN (http://www.ict-ocean.eu/) is an EU funded research project
that started in February 2010 for 3 years. Some of its objectives that started in February 2010 for 3 years. Some of its objectives
are relevant to CDNI. It aims, among other things, at designing a are relevant to CDNI. It aims, among other things, at designing a
new architectural framework for audiovisual content delivery over the new architectural framework for audiovisual content delivery over the
Internet, defining public interfaces between its major building Internet, defining public interfaces between its major building
blocks in order to foster multi-vendor solutions and interconnection blocks in order to foster multi-vendor solutions and interconnection
between Content Networks (the term "Content Networks" corresponds between Content Networks (the term "Content Networks" corresponds
here to the definition introduced in [RFC3466], which encompasses here to the definition introduced in [RFC3466], which encompasses
CDNs). CDNs).
OCEAN has not yet published any open specifications, nor common best OCEAN has not yet published any open specifications, nor common best
practices, defining how to achieve such CDN interconnection. practices, defining how to achieve such CDN interconnection.
B.3.3. Eurescom P1955 C.2.2. Eurescom P1955
Eurescom P1955 was a 2010 research project involving a four European Eurescom P1955 was a 2010 research project involving a four European
Network operators, which studied the interests and feasibility of Network operators, which studied the interests and feasibility of
interconnecting CDNs by firstly elaborating the main service models interconnecting CDNs by firstly elaborating the main service models
around CDN interconnection, as well as analyzing an adequate CDN around CDN interconnection, as well as analyzing an adequate CDN
interconnection technical architecture and framework, and finally by interconnection technical architecture and framework, and finally by
providing recommendations for telcos to implement CDN providing recommendations for telcos to implement CDN
interconnection. The Eurescom P1955 project ended in July 2010. interconnection. The Eurescom P1955 project ended in July 2010.
The authors are not aware of material discussing CDN interconnection The authors are not aware of material discussing CDN interconnection
protocols or interfaces made publicly available as a deliverable of protocols or interfaces made publicly available as a deliverable of
this project. this project.
B.4. Relationship to relevant IETF Working Groups
B.4.1. ALTO
As stated in the ALTO Working Group charter [ALTO-Charter]:
"The Working Group will design and specify an Application-Layer
Traffic Optimization (ALTO) service that will provide applications
with information to perform better-than-random initial peer
selection. ALTO services may take different approaches at balancing
factors such as maximum bandwidth, minimum cross-domain traffic,
lowest cost to the user, etc. The working group will consider the
needs of BitTorrent, tracker-less P2P, and other applications, such
as content delivery networks (CDN) and mirror selection."
In particular, the ALTO service can be used by a CDN Request Routing
system to improve its selection of a CDN surrogate to serve a
particular User Agent request (or to serve a request from another
surrogate). [I-D.jenkins-alto-cdn-use-cases] describes a number of
use cases for a CDN to be able to obtain network topology and cost
information from an ALTO server(s) and discusses how CDN Request
Routing could be used as an integration point of ALTO into CDNs. It
is possible that the ALTO service could be used in the same manner in
a multi-CDN environment based on CDN Interconnection. For example,
an upstream CDN may take advantage of the ALTO service in its
decision for selecting a downstream CDN to which a user request
should be delegated.
However, the current work of ALTO is complementary to and does not
overlap with the work described in this document because the
integration between ALTO and a CDN is an internal decision for a
specific CDN and is therefore out of scope for the CDNI working
group. One area for further study is whether additional information
should be provided by an ALTO service to facilitate CDNI CDN
selection.
B.4.2. DECADE
The DECADE Working Group [DECADE-Charter] is addressing the problem
of reducing traffic on the last-mile uplink, as well as backbone and
transit links caused by P2P streaming and file sharing applications.
It addresses the problem by enabling an application endpoint to make
content available from an in-network storage service and by enabling
other application endpoints to retrieve the content from there.
Exchanging data through the in-network storage service in this
manner, instead of through direct communication, provides significant
gain where:
o The network capacity/bandwidth from in-network storage service to
application endpoint significantly exceeds the capacity/bandwidth
from application endpoint to application endpoint (e.g. because of
an end-user uplink bottleneck); and
o Where the content is to be accessed by multiple instances of
application endpoints (e.g. as is typically the case for P2P
applications).
While, as is the case for any other data distribution application,
the DECADE architecture and mechanisms could potentially be used for
exchange of CDNI control plane information via an in-network-storage
service (as opposed to directly between the entities terminating the
CDNI interfaces in the neighbor CDNs), we observe that:
o CDNI would operate as a "Content Distribution Application" from
the DECADE viewpoint (i.e. would operate on top of DECADE).
o There does not seem to be obvious benefits in integrating the
DECADE control plane responsible for signaling information
relating to control of the in-network storage service itself, and
the CDNI control plane responsible for application-specific CDNI
interactions (such as exchange of CDNI metadata, CDNI request
redirection, transfer of CDNI logging information).
o There would typically be limited benefits in making use of a
DECADE in-network storage service because the CDNI interfaces are
expected to be terminated by a very small number of CDNI clients
(if not one) in each CDN, and the CDNI clients are expected to
benefit from high bandwidth/capacity when communicating directly
to each other (at least as high as if they were communicating via
an in-network storage server).
The DECADE in-network storage architecture and mechanisms may
theoretically be used for the acquisition of the content objects
themselves between interconnected CDNs. It is not expected that this
would have obvious benefits in typical situations where a content
object is acquired only once from an Upstream CDN to a Downstream CDN
(and then distributed as needed inside the Downstream CDN). But it
might have benefits in some particular situations. Since the
acquisition protocol between CDNs is outside the scope of the CDNI
work, this question is left for further study.
The DECADE in-network storage architecture and mechanisms may
potentially also be used within a given CDN for the distribution of
the content objects themselves among surrogates of that CDN. Since
the CDNI work does not concern itself with operation within a CDN,
this question is left for further study.
Therefore, the work of DECADE may be complementary to but does not
overlap with the CDNI work described in this document.
B.4.3. PPSP
As stated in the PPSP Working Group charter [PPSP-Charter]:
"The Peer-to-Peer Streaming Protocol (PPSP) working group develops
two signaling and control protocols for a peer-to-peer (P2P)
streaming system for transmitting live and time-shifted media content
with near real-time delivery requirements." and "The PPSP working
group designs a protocol for signaling and control between trackers
and peers (the PPSP "tracker protocol") and a signaling and control
protocol for communication among the peers (the PPSP "peer
protocol"). The two protocols enable peers to receive streaming data
within the time constraints required by specific content items."
Therefore PPSP is concerned with the distribution of the streamed
content itself along with the necessary signaling and control
required to distribute the content. As such, it could potentially be
used for the acquisition of streamed content across interconnected
CDNs. But since the acquisition protocol is outside the scope of the
work proposed for CDNI, we leave this for further study. Also,
because of its streaming nature, PPSP is not seen as applicable to
the distribution and control of the CDNI control plane and CDNI data
representations.
Therefore, the work of PPSP may be complementary to but does not
overlap with the work described in this document for CDNI.
Authors' Addresses Authors' Addresses
Ben Niven-Jenkins Ben Niven-Jenkins
Velocix (Alcatel-Lucent) Velocix (Alcatel-Lucent)
326 Cambridge Science Park 326 Cambridge Science Park
Milton Road, Cambridge CB4 0WG Milton Road, Cambridge CB4 0WG
UK UK
Email: ben@velocix.com Email: ben@velocix.com
Francois Le Faucheur Francois Le Faucheur
Cisco Systems Cisco Systems
Greenside, 400 Avenue de Roumanille Greenside, 400 Avenue de Roumanille
Sophia Antipolis 06410 Sophia Antipolis 06410
France France
Phone: +33 4 97 23 26 19 Phone: +33 4 97 23 26 19
Email: flefauch@cisco.com Email: flefauch@cisco.com
Nabil Bitar Nabil Bitar
 End of changes. 42 change blocks. 
206 lines changed or deleted 251 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/