< draft-ietf-cdni-problem-statement-01.txt   draft-ietf-cdni-problem-statement-02.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: May 3, 2012 Cisco Expires: July 19, 2012 Cisco
N. Bitar N. Bitar
Verizon Verizon
October 31, 2011 January 16, 2012
Content Distribution Network Interconnection (CDNI) Problem Statement Content Distribution Network Interconnection (CDNI) Problem Statement
draft-ietf-cdni-problem-statement-01 draft-ietf-cdni-problem-statement-02
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
content item can be delivered to an End User regardless of that End content item can be delivered to an End User regardless of that End
User's location or attachment network. This creates a requirement User's location or attachment network. This creates a requirement
for interconnecting standalone CDNs so they can interoperate as an for interconnecting standalone CDNs so they can interoperate as an
open content delivery infrastructure for the end-to-end delivery of open content delivery infrastructure for the end-to-end delivery of
content from Content Service Providers (CSPs) to End Users. However, content from Content Service Providers (CSPs) to End Users. However,
no standards or open specifications currently exist to facilitate no standards or open specifications currently exist to facilitate
such CDN interconnection. such CDN interconnection.
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 (CDNI) for the IETF. interconnection for the IETF CDNI (CDN Interconnection) working
group.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 19, 2012.
This Internet-Draft will expire on May 3, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. CDN Background . . . . . . . . . . . . . . . . . . . . . . 8 1.2. CDN Background . . . . . . . . . . . . . . . . . . . . . . 8
2. CDN Interconnect Use Cases . . . . . . . . . . . . . . . . . . 8 2. CDN Interconnection Use Cases . . . . . . . . . . . . . . . . 9
3. CDN Interconnect Model & Problem Area for IETF . . . . . . . . 10 3. CDN Interconnection Model & Problem Area for IETF . . . . . . 10
4. Design Approach for Realizing the CDNI APIs . . . . . . . . . 14 4. Design Approach for Realizing the CDNI Interfaces . . . . . . 14
4.1. CDNI Request Routing Interface . . . . . . . . . . . . . . 15 4.1. CDNI Request Routing Interface . . . . . . . . . . . . . . 15
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 . . . . . . . . . . . . . . . . . . 19 4.4. CDNI Control Interface . . . . . . . . . . . . . . . . . . 19
5. Gap Analysis of relevant Standardization Activities . . . . . 19 5. Relevant work from other standardization activities . . . . . 19
5.1. Content Acquisition across CDNs and Delivery to End 5.1. Content Acquisition across CDNs and Delivery to End
User (Data plane) . . . . . . . . . . . . . . . . . . . . 20 User (Data plane) . . . . . . . . . . . . . . . . . . . . 20
5.2. CDNI Metadata . . . . . . . . . . . . . . . . . . . . . . 21 5.2. CDNI Metadata . . . . . . . . . . . . . . . . . . . . . . 21
6. Relationship to relevant IETF Working Groups . . . . . . . . . 22 6. Relationship to relevant IETF Working Groups . . . . . . . . . 22
6.1. ALTO . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 6.1. ALTO . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.2. DECADE . . . . . . . . . . . . . . . . . . . . . . . . . . 22 6.2. DECADE . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.3. PPSP . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 6.3. PPSP . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.1. Normative References . . . . . . . . . . . . . . . . . . . 25 10.1. Normative References . . . . . . . . . . . . . . . . . . . 25
10.2. Informative References . . . . . . . . . . . . . . . . . . 25 10.2. Informative References . . . . . . . . . . . . . . . . . . 25
Appendix A. Additional Material . . . . . . . . . . . . . . . . . 28 Appendix A. Additional Material . . . . . . . . . . . . . . . . . 28
A.1. Non-Goals for IETF . . . . . . . . . . . . . . . . . . . . 28 A.1. Non-Goals for IETF . . . . . . . . . . . . . . . . . . . . 28
A.2. Related standardization activities . . . . . . . . . . . . 29 A.2. Related standardization activities . . . . . . . . . . . . 29
A.2.1. IETF CDI Working Group (Concluded) . . . . . . . . . . 29 A.2.1. IETF CDI Working Group (Concluded) . . . . . . . . . . 29
A.2.2. 3GPP . . . . . . . . . . . . . . . . . . . . . . . . . 30 A.2.2. 3GPP . . . . . . . . . . . . . . . . . . . . . . . . . 30
A.2.3. ISO MPEG . . . . . . . . . . . . . . . . . . . . . . . 30 A.2.3. ISO MPEG . . . . . . . . . . . . . . . . . . . . . . . 31
A.2.4. ATIS IIF . . . . . . . . . . . . . . . . . . . . . . . 31 A.2.4. ATIS IIF . . . . . . . . . . . . . . . . . . . . . . . 31
A.2.5. CableLabs . . . . . . . . . . . . . . . . . . . . . . 31 A.2.5. CableLabs . . . . . . . . . . . . . . . . . . . . . . 31
A.2.6. ETSI MCD . . . . . . . . . . . . . . . . . . . . . . . 32 A.2.6. ETSI MCD . . . . . . . . . . . . . . . . . . . . . . . 32
A.2.7. ETSI TISPAN . . . . . . . . . . . . . . . . . . . . . 32 A.2.7. ETSI TISPAN . . . . . . . . . . . . . . . . . . . . . 32
A.2.8. ITU-T . . . . . . . . . . . . . . . . . . . . . . . . 32 A.2.8. ITU-T . . . . . . . . . . . . . . . . . . . . . . . . 32
A.2.9. Open IPTV Forum (OIPF) . . . . . . . . . . . . . . . . 33 A.2.9. Open IPTV Forum (OIPF) . . . . . . . . . . . . . . . . 33
A.2.10. TV-Anytime Forum . . . . . . . . . . . . . . . . . . . 33 A.2.10. TV-Anytime Forum . . . . . . . . . . . . . . . . . . . 33
A.2.11. SNIA . . . . . . . . . . . . . . . . . . . . . . . . . 33 A.2.11. SNIA . . . . . . . . . . . . . . . . . . . . . . . . . 33
A.3. Related Research Projects . . . . . . . . . . . . . . . . 33 A.3. Related Research Projects . . . . . . . . . . . . . . . . 34
A.3.1. IRTF P2P Research Group . . . . . . . . . . . . . . . 34 A.3.1. IRTF P2P Research Group . . . . . . . . . . . . . . . 34
A.3.2. OCEAN . . . . . . . . . . . . . . . . . . . . . . . . 34 A.3.2. OCEAN . . . . . . . . . . . . . . . . . . . . . . . . 34
A.3.3. Eurescom P1955 . . . . . . . . . . . . . . . . . . . . 34 A.3.3. Eurescom P1955 . . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
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 and increased content, improved quality of experience for End Users and increased
robustness of delivery. For these reasons CDNs are frequently used robustness of delivery. For these reasons CDNs are frequently used
for large-scale content delivery. As a result, existing CDN for large-scale content delivery. As a result, existing CDN
providers are scaling up their infrastructure and many Network Providers are scaling up their infrastructure and many Network
Service Providers (NSPs) are deploying their own CDNs. Service Providers (NSPs) are deploying their own CDNs.
It is generally desirable that a given content item can be delivered It is generally desirable that a given content item can be delivered
to an End User regardless of that End User's location or attachment to an End User regardless of that End User's location or attachment
network. However, the footprint of a given CDN in charge of network. However, a given CDN in charge of delivering a given
delivering a given content may not expand close enough to the End content may not have a footprint that expands close enough to the End
User's current location or attachment network to realize the cost User's current location or attachment network, or may not have the
benefit and user experience that a more distributed CDN would necessary resources, to realize the user experience and cost benefit
provide. This creates a requirement for interconnecting standalone that a more distributed CDN infrastructure would allow. This creates
CDNs so that their collective CDN footprint can be leveraged for the a requirement for interconnecting standalone CDNs so that their
end-to-end delivery of content from Content Service Providers (CSPs) collective CDN footprint and resources can be leveraged for the end-
to End Users. For example, a CSP could contract with an to-end delivery of content from Content Service Providers (CSPs) to
"authoritative" CDN for the delivery of content and that End Users. As an example, a CSP could contract with an
authoritative CDN could contract with one or more downstream CDN(s) "authoritative" CDN Provider for the delivery of content and that
to distribute and deliver some or all of the content on behalf of the authoritative CDN Provider could contract with one or more downstream
authoritative CDN. The formation and details of any business CDN Provider(s) to distribute and deliver some or all of the content
relationships between a CSP and a CDN and between one CDN and another on behalf of the authoritative CDN Provider. The formation and
CDN are out of scope of this document. However, no standards or open details of any business relationships between a CSP and a CDN
Provider and between one CDN Provider and another CDN Provider are
out of scope of this document. However, no standards or open
specifications currently exist to facilitate such CDN specifications currently exist to facilitate such CDN
interconnection. interconnection.
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 (CDNI) for the IETF. Section 2 discusses the use interconnection for the IETF CDNI (CDN Interconnection) working
cases for CDN interconnection. Section 3 presents the CDNI model and group. Section 2 discusses the use cases for CDN interconnection.
problem area being considered by the IETF. Section 4 describes each Section 3 presents the CDNI model and problem area being considered
CDNI interface individually and highlights example candidate by the IETF. Section 4 describes each CDNI interface individually
protocols that could considered for reuse or leveraging to implement and highlights example candidate protocols that could be considered
the CDNI interfaces. Section 5 provides a gap analysis against the for reuse or leveraging to implement the CDNI interfaces. Section 5
work of other standards organizations. Section 6 describes the discusses the relevant work of other standards organizations.
relationships between the CDNI problem space and other relevant IETF Section 6 describes the relationships between the CDNI problem space
Working Groups. and other relevant IETF Working 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).
Metadata: Metadata in general is data about data. Metadata: Metadata in general is data about data.
Content Metadata: This is metadata about Content. Content Metadata Content Metadata: This is metadata about Content. Content Metadata
comprises: comprises:
1. Metadata that is relevant to the distribution of the content (and 1. Metadata that is relevant to the distribution of the content (and
therefore relevant to a CDN involved in the delivery of that therefore relevant to a CDN involved in the delivery of that
content). We refer to this type of metadata as "Content content). We refer to this type of metadata as "Content
Distribution Metadata". See also the definition of Content Distribution Metadata". See also the definition of Content
Distribution Metadata. Distribution Metadata.
2. Metadata that is associated with the actual Content (and not 2. Metadata that is associated with the actual Content or content
directly relevant to the distribution of that Content) or content representation, and not directly relevant to the distribution of
representation. For example, such metadata may include that Content. For example, such metadata may include information
information pertaining to the Content's genre, cast, rating, etc pertaining to the Content's genre, cast, rating, etc as well as
as well as information pertaining to the Content representation's information pertaining to the Content representation's
resolution, aspect ratio, etc. resolution, aspect ratio, etc.
Content Distribution Metadata: The subset of Content Metadata that is Content Distribution Metadata: The subset of Content Metadata that is
relevant to the distribution of the content. This is the metadata relevant to the distribution of the content. This is the metadata
required by a CDN in order to enable and control content distribution required by a CDN in order to enable and control content distribution
and delivery by the CDN. In a CDN Interconnection environment, some and delivery by the CDN. In a CDN Interconnection environment, some
of the Content Distribution Metadata may have an intra-CDN scope (and of the Content Distribution Metadata may have an intra-CDN scope (and
therefore need not be communicated between CDNs), while some of the therefore need not be communicated between CDNs), while some of the
Content Distribution Metadata have an inter-CDN scope (and therefore Content Distribution Metadata may have an inter-CDN scope (and
needs to be communicated between CDNs). therefore needs to be communicated between CDNs).
CDNI Metadata: Content Distribution Metadata with inter-CDN scope. CDNI Metadata: Content Distribution Metadata with inter-CDN scope.
For example, CDNI Metadata may include geo-blocking information (i.e. For example, CDNI Metadata may include geo-blocking information (i.e.
information defining geographical areas where the content is to be information defining geographical areas where the content is to be
made available or blocked), availability windows (i.e. information made available or blocked), availability windows (i.e. information
defining time windows during which the content is to be made defining time windows during which the content is to be made
available or blocked) and access control mechanisms to be enforced available or blocked) and access control mechanisms to be enforced
(e.g. URI signature validation). CDNI Metadata may also include (e.g. URI signature validation). CDNI Metadata may also include
information about desired distribution policy (e.g. prepositioned vs information about desired distribution policy (e.g. prepositioned vs
dynamic acquisition) and about where/how a CDN can acquire the dynamic acquisition) and about where/how a CDN can acquire the
content. CDNI Metadata may also include content management content. CDNI Metadata may also include content management
information (e.g. request for deletion of Content from Surrogates) information (e.g. request for deletion of Content from Surrogates)
across interconnected CDNs. across interconnected CDNs.
Dynamic content acquisition: Dynamic content acquisition is where a Dynamic content acquisition: Dynamic content acquisition is where a
CDN acquires content from the content source in response to an End CDN acquires content from the content source in response to an End
User requesting that content from the CDN. In the context of CDN User requesting that content from the CDN. In the context of CDN
Interconnection, dynamic acquisition means that a downstream CDN does Interconnection, dynamic acquisition means that a downstream CDN
not acquire the content from content sources (including upstream acquires the content from content sources (including upstream CDNs)
CDNs) until a request for that content has been delegated to the at some point in time after a request for that content is delegated
downstream CDN by an Upstream CDN. to the downstream CDN by an Upstream CDN (and that specific content
is not yet available in the downstream CDN).
Dynamic CDNI metadata acquisition: In the context of CDN Dynamic CDNI metadata acquisition: In the context of CDN
Interconnection, dynamic CDNI metadata acquisition means that a Interconnection, dynamic CDNI metadata acquisition means that a
downstream CDN does not acquire CDNI metadata for content from the downstream CDN acquires CDNI metadata for content from the upstream
upstream CDN until a request for that content has been delegated to CDN at some point in time after a request for that content is
the downstream CDN by an Upstream CDN. delegated to the downstream CDN by an Upstream CDN (and that specific
CDNI metadata is not yet available in the downstream CDN).
Pre-positioned content acquisition: Content Pre-positioning is where Pre-positioned content acquisition: Content Pre-positioning is where
a CDN acquires content from the content source prior to or a CDN acquires content from the content source prior to, or
independent of any End User requesting that content from the CDN. In independently of, any End User requesting that content from the CDN.
the context of CDN interconnection the Upstream CDN instructs the In the context of CDN interconnection the Upstream CDN instructs the
Downstream CDN to acquire the content from content sources (including Downstream CDN to acquire the content from content sources (including
upstream CDNs) in advance of or independent of any End User upstream CDNs) in advance of or independent of any End User
requesting it. requesting it.
Pre-positioned CDNI Metadata acquisition: In the context of CDN Pre-positioned CDNI Metadata acquisition: In the context of CDN
Interconnection, CDNI Metadata pre-positioning is where the Interconnection, CDNI Metadata pre-positioning is where the
Downstream CDN acquires CDNI metadata for content prior to or Downstream CDN acquires CDNI metadata for content prior to or
independent of any End User requesting that content from the independent of any End User requesting that content from the
Downstream CDN. Downstream CDN.
skipping to change at page 6, line 48 skipping to change at page 7, line 4
Network Service Provider (NSP): Provides network-based connectivity/ Network Service Provider (NSP): Provides network-based connectivity/
services to End Users. services to End Users.
Content Service Provider (CSP): Provides a Content Service to End Content Service Provider (CSP): Provides a Content Service to End
Users (which they access via a User Agent). A CSP may own the Users (which they access via a User Agent). A CSP may own the
Content made available as part of the Content Service, or may license Content made available as part of the Content Service, or may license
content rights from another party. content rights from another party.
Content Service: The service offered by a Content Service Provider. Content Service: The service offered by a Content Service Provider.
The Content Service encompasses the complete service which may be The Content Service encompasses the complete service which may be
wider than just the delivery of items of Content, e.g. the Content wider than just providing access to items of Content, e.g. the
Service also includes any middleware, key distribution, program Content Service also includes any middleware, key distribution,
guide, etc. which may not require any direct interaction with the program guide, etc. which may not require any direct interaction with
CDN. the CDN, or CDNs, involved in the distribution and delivery of the
content.
Content Distribution Network (CDN) / Content Delivery Network (CDN): Content Distribution Network (CDN) / Content Delivery Network (CDN):
Network infrastructure in which the network elements cooperate at Network infrastructure in which the network elements cooperate at
layers 4 through layer 7 for more effective delivery of Content to layers 4 through layer 7 for more effective delivery of Content to
User Agents. Typically a CDN consists of a Request Routing system, a User Agents. Typically a CDN consists of a Request Routing system, a
Distribution System (that includes a set of Surrogates), a Logging Distribution System (that includes a set of Surrogates), a Logging
System and a CDN control system. System and a CDN control system.
CDN Provider: The service provider who operates a CDN. Note that a CDN Provider: The service provider who operates a CDN and offers a
given entity may operate in more than one role. For example, a service of content delivery, typically used by a Content Service
company may simultaneously operate as a Content Service Provider, a Provider or another CDN Provider. Note that a given entity may
Network Service Provider and a CDN Provider. operate in more than one role. For example, a company may
simultaneously operate as a Content Service Provider, a Network
Service Provider and a CDN Provider.
CDN Interconnection (CDNI): The set of interfaces over which two or CDN Interconnection (CDNI): A relationship between a pair of CDNs
more CDNs communicate with each other in order to achieve the that enables one CDN to provide content delivery services on behalf
delivery of content to User Agents by Surrogates in one CDN (the of another CDN. A CDN Interconnection may be wholly or partially
downstream CDN) on behalf of another CDN (the upstream CDN). realised through a set of interfaces over which a pair of CDNs
communicate with each other in order to achieve the delivery of
content to User Agents by Surrogates in one CDN (the downstream CDN)
on behalf of another CDN (the upstream CDN).
Authoritative CDN: A CDN which has a direct relationship with a CSP Authoritative CDN: A CDN which has a direct relationship with a CSP
for the distribution & delivery of that CSP's content. for the distribution & delivery of that CSP's content by the
authoritative CDN or by downstream CDNs of the authoritative CDN.
Upstream CDN: For a given End User request, the CDN (within a pair of Upstream CDN: For a given End User request, the CDN (within a pair of
directly interconnected CDNs) that redirects the request to the other directly interconnected CDNs) that redirects the request to the other
CDN. CDN.
Downstream CDN: For a given End User request, the CDN (within a pair Downstream CDN: For a given End User request, the CDN (within a pair
of directly interconnected CDNs) to which the request is redirected of directly interconnected CDNs) to which the request is redirected
by the other CDN (the Upstream CDN). Note that in the case of by the other CDN (the Upstream CDN). Note that in the case of
successive redirections (e.g. CDN1-->CDN2-->CDN3) a given CDN (e.g. successive redirections (e.g. CDN1-->CDN2-->CDN3) a given CDN (e.g.
CDN2) may act as the Downstream CDN for a redirection (e.g. CDN2) may act as the Downstream CDN for a redirection (e.g.
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. a CDN, operated by a different Over-the-top (OTT): A service, e.g. content delivery using a CDN,
operator than the NSP to which the users of that service are operated by a different operator than the NSP to which the users of
attached. that service are attached.
Surrogate: A device/function that interacts with other elements of Surrogate: A device/function that interacts with other elements of
the CDN for the control and distribution of Content within the CDN the CDN for the control and distribution of Content within the CDN
and interacts with User Agents for the delivery of the Content. and interacts with User Agents for the delivery of the Content.
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
skipping to change at page 8, line 21 skipping to change at page 8, line 32
delivering a piece of content to the User Agent. For example, delivering a piece of content to the User Agent. For example,
delivery may be based on HTTP progressive download or HTTP adaptive delivery may be based on HTTP progressive download or HTTP adaptive
streaming. streaming.
Logging System: The function within a CDN responsible for collecting Logging System: The function within a CDN responsible for collecting
the measurement and recording of distribution and delivery the measurement and recording of distribution and delivery
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
bootstrapping and controlling the other components of the CDN as well
as for handling interactions with external systems (e.g. handling
delivery service creation/update/removal requests, or specific
service provisioning requests).
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
IETF Content Delivery Internetworking (CDI) working group which IETF Content Delivery Internetworking (CDI) working group which
was closed in 2003. was closed in 2003.
Note: Some of the terms used in this document are similar to terms Note: Some of the terms used in this document are similar to terms
used the above referenced documents. When reading this document used the above referenced documents. When reading this document
terms should be interpreted as having the definitions provided in terms should be interpreted as having the definitions provided in
Section 1.1. Section 1.1.
2. CDN Interconnect Use Cases 2. CDN Interconnection Use Cases
An increasing number of NSPs are deploying CDNs in order to deal An increasing number of NSPs are deploying CDNs in order to deal
cost-effectively with the growing usage of on-demand video services cost-effectively with the growing usage of on-demand video services
and other content delivery applications. and other content delivery applications.
CDNs allow caching of content closer to the edge of a network so that CDNs allow caching of content closer to the edge of a network so that
a given item of content can be delivered by a CDN Surrogate (i.e. a a given item of content can be delivered by a CDN Surrogate (i.e. a
cache) to multiple User Agents (and their End Users) without cache) to multiple User Agents (and their End Users) without
transiting multiple times through the network core (i.e from the transiting multiple times through the network core (i.e from the
content origin to the surrogate). This contributes to bandwidth cost content origin to the surrogate). This contributes to bandwidth cost
skipping to change at page 9, line 19 skipping to change at page 9, line 34
The CDNs deployed by NSPs are not just restricted to the delivery of The CDNs deployed by NSPs are not just restricted to the delivery of
content to support the Network Service Provider's own 'walled garden' content to support the Network Service Provider's own 'walled garden'
services, such as IP delivery of television services to Set Top services, such as IP delivery of television services to Set Top
Boxes, but are also used for delivery of content to other devices Boxes, but are also used for delivery of content to other devices
including PCs, tablets, mobile phones etc. including PCs, tablets, mobile phones etc.
Some service providers operate over multiple geographies and federate Some service providers operate over multiple geographies and federate
multiple affiliate NSPs. These NSPs typically operate independent multiple affiliate NSPs. These NSPs typically operate independent
CDNs. As they evolve their services (e.g. for seamless support of CDNs. As they evolve their services (e.g. for seamless support of
content services to nomadic users across affiliate NSPs) there is a content services to nomadic users across affiliate NSPs) there is a
need for interconnection of these CDNs. However there are no open need for interconnection of these CDNs, that represents a first use
specifications, nor common best practices, defining how to achieve case for CDNI. However there are no open specifications, nor common
such CDN interconnection. best practices, defining how to achieve such CDN interconnection.
CSPs have a desire to be able to get (some of) their content to very CSPs have a desire to be able to get (some of) their content to very
large number of End Users and/or over many/all geographies and/or large number of End Users and/or over many/all geographies and/or
with a high quality of experience, all without having to maintain with a high quality of experience, all without having to maintain
direct business relationships with many different CDN providers (or direct business relationships with many different CDN providers (or
having to extend their own CDN to a large number of locations). Some having to extend their own CDN to a large number of locations). Some
NSPs are considering interconnecting their respective CDNs (as well NSPs are considering interconnecting their respective CDNs (as well
as possibly over-the-top CDNs) so that this collective infrastructure as possibly over-the-top CDNs) so that this collective infrastructure
can address the requirements of CSPs in a cost effective manner. In can address the requirements of CSPs in a cost effective manner.
particular, this would enable the CSPs to benefit from on-net This represents a second use case for CDNI. In particular, this
delivery (i.e. within the Network Service Provider's own network/CDN would enable the CSPs to benefit from on-net delivery (i.e. within
footprint) whenever possible and off-net delivery otherwise, without the Network Service Provider's own network/CDN footprint) whenever
requiring the CSPs to maintain direct business relationships with all possible and off-net delivery otherwise, without requiring the CSPs
the CDNs involved in the delivery. Again, for this requirement, CDN to maintain direct business relationships with all the CDNs involved
providers (NSPs or over-the-top CDN operators) are faced with a lack in the delivery. Again, for this requirement, CDN providers (NSPs or
of open specifications and best practices. over-the-top CDN operators) are faced with a lack of open
specifications and best practices.
NSPs have often deployed CDNs as specialized cost-reduction projects NSPs have often deployed CDNs as specialized cost-reduction projects
within the context of a particular service or environment, some NSPs within the context of a particular service or environment, some NSPs
operate separate CDNs for separate services. For example, there may operate separate CDNs for separate services. For example, there may
be a CDN for managed IPTV service delivery, a CDN for web-TV delivery be a CDN for managed IPTV service delivery, a CDN for web-TV delivery
and a CDN for video delivery to Mobile terminals. As NSPs integrate and a CDN for video delivery to Mobile terminals. As NSPs integrate
their service portfolio, there is a need for interconnecting these their service portfolio, there is a need for interconnecting these
CDNs. Again, NSPs face the problem of lack of open interfaces for CDNs, representing a third use case for CDNI. Again, NSPs face the
CDN interconnection. problem of lack of open interfaces for CDN interconnection.
For operational reasons (e.g. disaster, flash crowd) or commercial For operational reasons (e.g. disaster, flash crowd) or commercial
reasons, an over-the-top CDN may elect to make use of another CDN reasons, an over-the-top CDN may elect to make use of another CDN
(e.g. an NSP CDN with on-net Surrogates for a given footprint) for (e.g. an NSP CDN with on-net Surrogates for a given footprint) for
serving a subset of the user requests (e.g. requests from users serving a subset of the user requests (e.g. requests from users
attached to that NSP). Again, for this requirement, CDN providers attached to that NSP), which results in a fourth use case for CDNI.
(over-the-top CDN providers or NSPs) are faced with a lack of open Again, for this requirement, CDN providers (over-the-top CDN
specifications and best practices. providers or NSPs) are faced with a lack of open specifications and
best practices.
Use cases for CDN Interconnection are further discussed in Use cases for CDN Interconnection are further discussed in
[I-D.ietf-cdni-use-cases]. [I-D.ietf-cdni-use-cases].
3. CDN Interconnect Model & Problem Area for IETF 3. CDN Interconnection Model & Problem Area for IETF
Interconnecting CDNs involves interactions among multiple different Interconnecting CDNs involves interactions among multiple different
functions and components that form each CDN. Only some of those functions and components that form each CDN. Only some of those
require standardization. This section discusses the problem area for require standardization. This section discusses the problem area for
the IETF work on CDN Interconnection. The CDNI model and problem the IETF work on CDN Interconnection. The CDNI model and problem
area defined for IETF work is illustrated in Figure 1. area defined for IETF work is illustrated in Figure 1.
-------- --------
/ \ / \
| CSP | | CSP |
skipping to change at page 11, line 50 skipping to change at page 11, line 50
. * . . * .
. +--*---+ . . +--*---+ .
...............Request.............................| User |..Request.. ...............Request.............................| User |..Request..
| Agent| | Agent|
+------+ +------+
<==> interfaces inside the scope of CDNI <==> interfaces inside the scope of CDNI
**** interfaces outside the scope of CDNI **** interfaces outside the scope of CDNI
.... interfaces outside the scope of CDNI .... interfaces outside the scope of CDNI
Figure 1: CDNI Problem Area Figure 1: CDNI Model
Listed below are the four interfaces required to interconnect a pair Listed below are the four interfaces required to interconnect a pair
of CDNs and that constitute the problem space that is proposed to be of CDNs and that constitute the problem space that is proposed to be
addressed by a potential CDNI working group in the IETF. The use of addressed by the CDNI working group in the IETF. The use of the term
the term "interface" is meant to encompass the protocol over which "interface" is meant to encompass the protocol over which CDNI data
CDNI data representations (e.g. CDNI Metadata records) are exchanged representations (e.g. CDNI Metadata objects) are exchanged as well
as well as the specification of the data representations themselves as the specification of the data representations themselves (i.e.
(i.e. what properties/fields each record contains, its structure, what properties/fields each object contains, its structure, etc.).
etc.).
o CDNI Control interface: This interface allows the "CDNI Control" o CDNI Control interface: This interface allows the "CDNI Control"
system in interconnected CDNs to communicate. This interface may system in interconnected CDNs to communicate. This interface may
support the following: support the following:
* Allow bootstrapping of the other CDNI interfaces (e.g. * Allow bootstrapping of the other CDNI interfaces (e.g.
interface address/URL discovery and establishment of security interface address/URL discovery and establishment of security
associations). associations).
* Allow configuration of the other CDNI interfaces (e.g. * Allow configuration of the other CDNI interfaces (e.g.
Upstream CDN specifies information to be reported through the Upstream CDN specifies information to be reported through the
CDNI Logging interface). CDNI Logging interface).
skipping to change at page 13, line 44 skipping to change at page 13, line 44
points' that require standardization. However, it is expected that points' that require standardization. However, it is expected that
the CDNI interfaces need not be defined from scratch and instead can the CDNI interfaces need not be defined from scratch and instead can
very significantly reuse or leverage existing protocols: this is very significantly reuse or leverage existing protocols: this is
discussed further in Section 4. Also, it is expected that the items discussed further in Section 4. Also, it is expected that the items
above will be prioritized so that the CDNI Working Group can focus above will be prioritized so that the CDNI Working Group can focus
(at least initially) on the most essential and urgent work. (at least initially) on the most essential and urgent work.
As part of the development of the CDNI interfaces and solutions it As part of the development of the CDNI interfaces and solutions it
will also be necessary to agree on common mechanisms for how to will also be necessary to agree on common mechanisms for how to
identify and name the data objects that are to be interchanged identify and name the data objects that are to be interchanged
between interconnected CDNs, as well as how to describe which policy between interconnected CDNs.
should be used when doing so.
Some NSPs have started to perform experiments to explore whether Some NSPs have started to perform experiments to explore whether
their CDN use cases can already be addressed with existing CDN their CDN use cases can already be addressed with existing CDN
implementations. One set of such experiments is documented in implementations. One set of such experiments is documented in
[I-D.bertrand-cdni-experiments]. The conclusions of those [I-D.bertrand-cdni-experiments]. The conclusions of those
experiments are that while some basic limited CDN Interconnection experiments are that while some basic limited CDN Interconnection
functionality can be achieved with existing CDN technology, the functionality can be achieved with existing CDN technology, the
current lack of any standardized CDNI interfaces/protocols such as current lack of any standardized CDNI interfaces/protocols such as
those discussed in this document is preventing the deployment of those discussed in this document is preventing the deployment of
production CDN Interconnection solutions with the necessary level of production CDN Interconnection solutions with the necessary level of
functionality. functionality.
The acquisition of content between interconnected CDNs is out of As illustrated in Figure 1, the acquisition of content between
scope for CDNI and deserves some additional explanation. The interconnected CDNs is out of scope for CDNI, which deserves some
consequence of such a decision is that the CDNI WG is focussed on additional explanation. The consequence of such a decision is that
only defining the control plane for CDNI; and the CDNI data plane the CDNI working group is focussed on only defining the control plane
(i.e. the acquisition & distribution of the actual content objects) for CDNI; and the CDNI data plane (i.e. the acquisition &
will not be addressed by the CDNI WG. The rationale for such a distribution of the actual content objects) will not be addressed by
decision is that CDNs today typically already use standardized the CDNI working group. The rationale for such a decision is that
protocols such as HTTP, FTP, rsync, etc. to acquire content from CDNs today typically already use standardized protocols such as HTTP,
their CSP customers and it is expected that the same protocols could FTP, rsync, etc. to acquire content from their CSP customers and it
be used for acquisition between interconnected CDNs. Therefore the is expected that the same protocols could be used for acquisition
problem of content acquisition is considered already solved and all between interconnected CDNs. Therefore the problem of content
that is required from specifications developed by the CDNI WG is to acquisition is considered already solved and all that is required
from specifications developed by the CDNI working group is to
describe within the CDNI Metadata where to go and which protocol to describe within the CDNI Metadata where to go and which protocol to
use to retrieve the content. use to retrieve the content.
4. Design Approach for Realizing the CDNI APIs 4. Design Approach for Realizing the CDNI Interfaces
This section expands on how CDNI interfaces can reuse and leverage This section expands on how CDNI interfaces can reuse and leverage
existing protocols before describing each CDNI interface individually existing protocols before describing each CDNI interface individually
and highlighting example candidate protocols that could considered and highlighting example candidate protocols that could be considered
for reuse or leveraging to implement the CDNI interfaces. This for reuse or leveraging to implement the CDNI interfaces. This
discussion is not intended to pre-empt any WG decision as to the most discussion is not intended to pre-empt any working group decision as
appropriate protocols, technologies and solutions to select to solve to the most appropriate protocols, technologies and solutions to
CDNI but is intended as an illustration of the fact that the CDNI select to realize the CDNI interfaces but is intended as an
interfaces need not be created in a vacuum and that reuse or leverage illustration of the fact that the CDNI interfaces need not be created
of existing protocols is likely possible. in a vacuum and that reuse or leverage of existing protocols is
likely possible.
The four CDNI interfaces (CDNI Control interface, CDNI Request The four CDNI interfaces (CDNI Control interface, CDNI Request
Routing interface, CDNI Metadata interface, CDNI Logging interface) Routing interface, CDNI Metadata interface, CDNI Logging interface)
described in Section 3 within the CDNI problem area are all control described in Section 3 within the CDNI problem area are all control
plane interfaces operating at the application layer (Layer 7 in the plane interfaces operating at the application layer (Layer 7 in the
OSI network model). Since it is not expected that these interfaces OSI network model). Firstly, since it is not expected that these
would exhibit unique session, transport or network requirements as interfaces would exhibit unique session, transport or network
compared to the many other existing applications in the Internet, it requirements as compared to the many other existing applications in
is expected that the CDNI interfaces will be defined on top of the Internet, it is expected that the CDNI interfaces will be defined
existing session, transport and network protocols. on top of existing session, transport and network protocols.
Although a new application protocol could be designed specifically Secondly, although a new application protocol could be designed
for CDNI we assume that this is unnecessary and it is recommended specifically for CDNI we assume that this is unnecessary and it is
that existing application protocols be reused or leveraged (HTTP recommended that existing application protocols be reused or
[RFC2616], Atom Publishing Protocol [RFC5023], XMPP [RFC6120], for leveraged (HTTP [RFC2616], Atom Publishing Protocol [RFC5023], XMPP
example) to realize the CDNI interfaces.
[RFC6120], for example) to realize the CDNI interfaces.
4.1. CDNI Request Routing Interface 4.1. CDNI Request Routing Interface
The CDNI Request Routing interface enables a Request Routing function The CDNI Request Routing interface enables a Request Routing function
in an upstream CDN to query a Request Routing function in a in an upstream CDN to query a Request Routing function in a
downstream CDN to determine if the downstream CDN is able (and downstream CDN to determine if the downstream CDN is able (and
willing) to accept the delegated content request and to allow the willing) to accept the delegated content request and to allow the
downstream CDN to control what the upstream Request Routing function downstream CDN to control what the upstream Request Routing function
should return to the User Agent in the redirection message. should return to the User Agent in the redirection message.
The CDNI Request Routing interface needs to offer a mechanism for an Therefore, the CDNI Request Routing interface needs to offer a
upstream CDN to issue a "Redirection Request" to a downstream CDN. mechanism for an upstream CDN to issue a "Redirection Request" to a
The Request Routing interface needs to be able to support scenarios downstream CDN. The Request Routing interface needs to be able to
where the initial User Agent request to the upstream CDN is received support scenarios where the initial User Agent request to the
over DNS as well as over a content specific application protocol upstream CDN is received over DNS as well as over a content specific
(e.g. HTTP, RTSP, RTMP, etc.). application protocol (e.g. HTTP, RTSP, RTMP, etc.).
Therefore a Redirection Request needs to contain information such as: Therefore a Redirection Request is expected to contain information
such as:
o The protocol (e.g. DNS, HTTP) over which the upstream CDN o The protocol (e.g. DNS, HTTP) over which the upstream CDN
received the initial User Agent request. received the initial User Agent request.
o Additional details of the User Agent request that are required to o Additional details of the User Agent request that are required to
perform effective Request Routing by the Downstream CDN. For DNS perform effective Request Routing by the Downstream CDN. For DNS
this would typically be the IP address of the DNS resolver making this would typically be the IP address of the DNS resolver making
the request on behalf of the User Agent. For requests received the request on behalf of the User Agent. For requests received
over content specific application protocols the Redirection over content specific application protocols the Redirection
Request could contain significantly more information related to Request could contain significantly more information related to
the original User Agent request but at a minimum would need to the original User Agent request but at a minimum is expected to
contain the User Agent's IP address, the equivalent of the HTTP include the User Agent's IP address, the equivalent of the HTTP
Host header and the equivalent of the HTTP abs_path defined in Host header and the equivalent of the HTTP abs_path defined in
[RFC2616]. [RFC2616].
It should be noted that, the CDNI architecture needs to consider that It should be noted that, the CDNI architecture needs to consider that
a downstream CDN may receive requests from User Agents without first a downstream CDN may receive requests from User Agents without first
receiving a Redirection Request from an upstream CDN, for example receiving a Redirection Request from an upstream CDN for the
because: corresponding User Agent request, for example because:
o User Agents (or DNS resolvers) may cache DNS or application o User Agents (or DNS resolvers) may cache DNS or application
responses from Request Routers. responses from Request Routers.
o Responses to Redirection Requests over the Request Routing o Responses to Redirection Requests over the Request Routing
interface may be cacheable. interface may be cacheable.
o Some CDNs may want broader policies, e.g. CDN B agrees to always o Some CDNs may rely on simple coarse policies, e.g. CDN B agrees
take CDN A's delegated redirection requests, in which case the to always serve CDN A's delegated redirection requests, in which
necessary redirection details are exchanged out of band (of the case the necessary redirection details are exchanged out of band
CDNI interfaces), e.g. configured. (of the CDNI interfaces), e.g. configured.
On receiving a Redirection Request, the downstream CDN will use the On receiving a Redirection Request, the downstream CDN will use the
information provided in the request to determine if it is able (and information provided in the request to determine if it is able (and
willing) to accept the delegated content request and needs to return willing) to accept the delegated content request and needs to return
the result of its decision to the upstream CDN. the result of its decision to the upstream CDN.
Thus, a Redirection Response from the downstream CDN needs to contain Thus, a Redirection Response from the downstream CDN is expected to
information such as: contain information such as:
o Status code indicating acceptance or rejection (possibly with o Status code indicating acceptance or rejection (possibly with
accompanying reasons). accompanying reasons).
o Information to allow redirection by the Upstream CDN. In the case o Information to allow redirection by the Upstream CDN. In the case
of DNS-based request routing, this is expected to include the of DNS-based request routing, this is expected to include the
equivalent of a DNS record(s) (e.g. a CNAME) that the upstream CDN equivalent of a DNS record(s) (e.g. a CNAME) that the upstream CDN
should return to the requesting DNS resolver. In the case of should return to the requesting DNS resolver. In the case of
application based request routing, this is expected to include the application based request routing, this is expected to include the
application specific redirection response(s) to return to the information necessary to construct the application specific
requesting User Agent. For HTTP requests from User Agents this redirection response(s) to return to the requesting User Agent.
could be in the form of a URI that the upstream CDN could return For HTTP requests from User Agents this could include a URI that
in a HTTP 302 response. the upstream CDN could return in a HTTP 3xx response.
The CDNI Request Routing interface is therefore a fairly The CDNI Request Routing interface is therefore a fairly
straightforward request/response interface and could be implemented straightforward request/response interface and could be implemented
over any number of request/response protocols. For example, it may over any number of request/response protocols. For example, it may
be implemented as a WebService using one of the common WebServices be implemented as a WebService using one of the common WebServices
methodologies (XML-RPC, HTTP query to a known URI, etc.). This methodologies (XML-RPC, HTTP query to a known URI, etc.). This
removes the need for the CDNI WG to define a new protocol for the removes the need for the CDNI working group to define a new protocol
request/response element of the CDNI Request Routing interface. for the request/response element of the CDNI Request Routing
Thus, the CDNI WG would be left only with the task of specifying: interface. Thus, the CDNI working group would be left only with the
task of specifying:
o The recommended request/response protocol to use along with any o The recommended request/response protocol to use along with any
additional semantics and procedures that are specific to the CDNI additional semantics and procedures that are specific to the CDNI
Request Routing interface (e.g. handling of malformed requests/ Request Routing interface (e.g. handling of malformed requests/
responses). responses).
o The syntax (i.e representation/encoding) of the redirection o The syntax (i.e representation/encoding) of the redirection
requests and responses. requests and responses.
o The semantics (i.e. meaning and expected contents) of the o The semantics (i.e. meaning and expected contents) of the
redirection requests and responses. redirection requests and responses.
Additionally, as discussed in Section 3, the CDNI Request Routing Additionally, as discussed in Section 3, the CDNI Request Routing
interface is also expected to enable a downstream CDN to provide to interface is also expected to enable a downstream CDN to provide to
the upstream CDN (static or dynamic) information (e.g. resources, the upstream CDN (static or dynamic) information (e.g. resources,
footprint, load) to facilitate selection of the downstream CDN by the footprint, load) to facilitate selection of the downstream CDN by the
upstream CDN request routing system when processing subsequent upstream CDN request routing system when processing subsequent
content requests from User Agents. It is expected that such content requests from User Agents. It is expected that such
functionality of the CDNI request Routing could be specified by the functionality of the CDNI request Routing could be specified by the
CDNI WG with significant leveraging of existing IETF protocols CDNI working group with significant leveraging of existing IETF
supporting the dynamic distribution of reachability information (for protocols supporting the dynamic distribution of reachability
example by leveraging existing routing protocols) or supporting information (for example by leveraging existing routing protocols) or
application level queries for topological information (for example by supporting application level queries for topological information (for
leveraging ALTO). example by leveraging ALTO).
4.2. CDNI Metadata Interface 4.2. CDNI Metadata Interface
The CDNI Metadata interface enables the Metadata function in a The CDNI Metadata interface enables the Distribution System in a
downstream CDN to obtain CDNI Metadata from an upstream CDN so that downstream CDN to obtain CDNI Metadata from an upstream CDN so that
the downstream CDN can properly process and respond to: the downstream CDN can properly process and respond to:
o Redirection Requests received over the CDNI Request Routing o Redirection Requests received over the CDNI Request Routing
interface. interface.
o Content Requests received directly from User Agents. o Content Requests received directly from User Agents.
The CDNI Metadata interface needs to offer a mechanism for an The CDNI Metadata interface needs to offer a mechanism for an
Upstream CDN to: Upstream CDN to:
o Distribute/update/remove CDNI Metadata to a Downstream CDN. o Distribute/update/remove CDNI Metadata to a Downstream CDN.
and/or to allow a downstream CDN to: and/or to allow a downstream CDN to:
o Make direct requests for CDNI Metadata records where the o Make direct requests for CDNI Metadata objects
downstream CDN knows the identity of the Metadata record(s) it o Make recursive requests for CDNI metadata, for example to enable a
requires. downstream CDN to walk down a tree of objects with inter-object
o Search for CDNI Metadata records where the downstream CDN does not relationships.
know the specific Metadata record(s) it requires but does know
some property of the record it is searching for. For example, it
may know the value of the HTTP Host header received in a HTTP
request and it wants to obtain the CDNI Metadata for that host so
that it can determine how to further process the received HTTP
request.
The CDNI Metadata interface is therefore similar to the CDNI Request The CDNI Metadata interface is therefore similar to the CDNI Request
Routing interface because it is a request/response interface with the Routing interface because it is a request/response interface with the
potential addition that CDNI Metadata search may have more complex potential addition that CDNI Metadata search may have more complex
semantics than a straightforward Request Routing redirection request. semantics than a straightforward Request Routing redirection request.
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 WG to define a new protocol for This removes the need for the CDNI working group to define a new
the request/response element of the CDNI Metadata interface. protocol for the request/response element of the CDNI Metadata
interface.
Thus, the CDNI WG would be left only with the task of specifying: Thus, the CDNI working group would be left only with the task of
specifying:
o The recommended request/response protocol to use along with any o The recommended request/response protocol to use along with any
additional semantics that are specific to the CDNI Metadata additional semantics that are specific to the CDNI Metadata
interface (e.g. handling of malformed requests/responses). interface (e.g. handling of malformed requests/responses).
o The syntax (i.e representation/encoding) of the CDNI Metadata o The syntax (i.e representation/encoding) of the CDNI Metadata
records that will be exchanged over the interface. objects that will be exchanged over the interface.
o The semantics (i.e. meaning and expected contents) of the o The semantics (i.e. meaning and expected contents) of the
individual properties of a Metadata record. individual properties of a Metadata object.
o How the relationships between different CDNI Metadata records are o How the relationships between different CDNI Metadata objects are
represented. represented.
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 logs or events to be
exchanged between interconnected CDNs, where events could be: exchanged between interconnected CDNs, where events could be:
o Log lines related to the delivery of content (similar to the log o Log lines related to the delivery of content (similar to the log
lines recorded in a web server's access log). lines recorded in a web server's access log).
o Real-time or near-real time events before, during or after content o Real-time or near-real time events before, during or after content
delivery, e.g. content Start/Pause/Stop events, etc. delivery, e.g. content delivery interruption
o Operations and diagnostic messages. o Operations and diagnostic messages.
Within CDNs today, logs and events are used for a variety of purposes Within CDNs today, logs and events are used for a variety of purposes
in addition to real-time and non real-time diagnostics and auditing in addition to real-time and non real-time diagnostics and auditing
by the CDN Provider and its customers. Specifically CDNs use logs to by the CDN Provider and its customers. Specifically CDNs use logs to
generate Call Data Records (CDRs) for passing to billing and payment generate Call Data Records (CDRs) for passing to billing and payment
systems and to real-time (and near real-time) analytics systems. systems and to real-time (and near real-time) analytics systems.
Such use cases place requirements on the CDNI Logging interface to Such applications place requirements on the CDNI Logging interface to
support guaranteed and timely delivery of log messages between support guaranteed and timely delivery of log messages between
interconnected CDNs. It may also be necessary to be able to prove interconnected CDNs. It may also be necessary to be able to prove
the integrity of received log messages. the integrity of received log 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 Traps, exchange CDNI logs between interconnected CDNs including SNMP Traps,
syslog, ftp, HTTP POST, etc. although it is likely that some of the syslog, ftp, HTTP POST, etc. although it is likely that some of the
candidate protocols may not be well suited to meet all the candidate protocols may not be well suited to meet all the
requirements of CDNI. For example SNMP traps pose scalability requirements of CDNI. For example SNMP traps pose scalability
concerns and SNMP does not support guaranteed delivery of Traps and concerns and SNMP does not support guaranteed delivery of Traps and
therefore could result in log records being lost and the consequent therefore could result in log records being lost and the consequent
CDRs and billing records for that content delivery not being produced CDRs and billing records for that content delivery not being produced
as well as that content delivery being invisible to any analytics as well as that content delivery being invisible to any analytics
platforms. platforms.
Although it is not necessary to define a new protocol for exchanging Although it is not necessary to define a new protocol for exchanging
logs across the CDNI Logging interface, the CDNI WG would still need logs across the CDNI Logging interface, the CDNI working group would
to specify: still need to specify:
o The recommended protocol to use. o The recommended protocol to use.
o A default set of log fields and their syntax & semantics. Today o A default set of log fields and their syntax & semantics. Today
there is no standard set of common log fields across different there is no standard set of common log fields across different
content delivery protocols and in some cases there is not even a content delivery protocols and in some cases there is not even a
standard set of log field names and values for different standard set of log field names and values for different
implementations of the same delivery protocol. implementations of the same delivery protocol.
o A default set of events that trigger logs to be generated. o A default set of events that trigger logs to be generated.
4.4. CDNI Control Interface 4.4. CDNI Control Interface
The CDNI Control interface allows the "CDNI 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
is less well defined than the other three CDNI interfaces at this is less well defined than the other three CDNI interfaces at this
time. time.
However, as discussed in Section 3, the CDNI Control interface may be However, as discussed in Section 3, the CDNI Control interface may be
required to support functionality similar to the following: required to support functionality similar to the following:
o Allow an upstream CDN and downstream CDN to establish, update or o Allow an upstream CDN and downstream CDN to establish, update or
terminate their CDNI interconnection. terminate their CDNI interconnection.
o Allow bootstrapping of the other CDNI interfaces (e.g. protocol o Allow bootstrapping of the other CDNI interfaces (e.g. protocol
skipping to change at page 19, line 33 skipping to change at page 19, line 33
interface). interface).
o Allow the downstream CDN to communicate static information about o Allow the downstream CDN to communicate static information about
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.
5. Gap Analysis of relevant Standardization Activities 5. Relevant work from other standardization activities
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 WG and any component that could potentially be reused by the CDNI working group and any component that could potentially be
CDNI. 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:
o TISPAN has a dedicated specification for CDN. o ETSI TISPAN (Telecommunications and Internet converged Services
o OIPF and ATIS specify the architecture and the protocols of an and Protocols for Advanced Networking) has a series of
IPTV solution. Although OIPF and ATIS specifications include the specifications focusing on CDNs.
o The Open IPTV Forum (OIPF) and ATIS IPTV Interoperability Forum
(IIF) specify the architecture and the protocols of an IPTV
solution. Although OIPF and ATIS specifications include the
interaction with a CDN, the CDN specifications are coupled with interaction with a CDN, the CDN specifications are coupled with
their IPTV specifications. their IPTV specifications and do not cover interconnection of
o CableLabs, SNIA and ITU have defined (or are working on) CDNs.
definitions for content related metadata definitions and o ATIS Cloud Services Forum (CSF) has started investigating
specification for its distribution. However, they do not include interconnection of CDNs. The ATIS CSF focuses on defining use
metadata specific to the distribution of content within a CDN or cases and requirements for such CDN interconnection, which are
between interconnected CDNs. expected to be considered as input into the work of the CDNI
o IETF CDI WG (now concluded) touched on the same problem space as working group. At the time of writing this document, ATIS CSF is
the present document. However, in accordance with its initial not specifying the corresponding protocols or interfaces and is
charter, the CDI WG did not define any protocols or interfaces to expected to leverage the work of the IETF CDNI working group for
actually enable CDN Interconnection and at that time (2003) there those.
was not enough industry interest and real life requirements to o CableLabs, SNIA and ITU have developed (or are working on)
justify rechartering the WG to conduct the corresponding protocol definitions for content related metadata and specifications for
work. its distribution. However, they do not include metadata specific
to the distribution of content within a CDN or between
interconnected CDNs.
o IETF CDI working group (now concluded) touched on the same problem
space as the present document. However, in accordance with its
initial charter, the CDI working group did not define any
protocols or interfaces to actually enable CDN Interconnection and
at that time (2003) there was not enough industry interest and
real life requirements to justify rechartering the working group
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.
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.
Section 5.1 summarises existing interfaces that could be leveraged Section 5.1 summarises existing interfaces that could be leveraged
skipping to change at page 20, line 37 skipping to change at page 20, line 49
and CDNI Logging). and CDNI Logging).
5.1. Content Acquisition across CDNs and Delivery to End User (Data 5.1. Content Acquisition across CDNs and Delivery to End User (Data
plane) 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 CoD services, TISPAN, OIPF and ATIS have specified IPTV and/or Content on Demand
including the data plane aspects (typically different flavors of RTP/ (CoD) services, including the data plane aspects (typically different
RTCP and HTTP) to obtain content and deliver it to User Agents. For flavors of RTP/RTCP and HTTP) to obtain content and deliver it to
example, : User Agents. For example, :
o The OIPF data plane includes both RTP and HTTP flavors (HTTP o The OIPF data plane includes both RTP and HTTP flavors (HTTP
progressive download, HTTP Adaptive streaming [_3GP-DASH]). progressive download, HTTP Adaptive streaming [3GP-DASH]).
o The ATIS specification "IPTV Content on Demand (CoD) Service" o The ATIS IIF specification "IPTV Content on Demand (CoD) Service"
[ATIS-COD] defines a reference point (C2) and the corresponding [ATIS-COD] defines a reference point (C2) and the corresponding
HTTP-based data plane protocol for content acquisition between an HTTP-based data plane protocol for content acquisition between an
authoritative origin server and the CDN. authoritative origin server and the CDN.
While these protocols have not been explicitly specified for content While these protocols have not been explicitly specified for content
acquisition across CDNs, they are suitable (in addition to others acquisition across CDNs, they are suitable (in addition to others
such as standard HTTP) for content acquisition between CDNs in a CDN such as standard HTTP) for content acquisition between CDNs in a CDN
Interconnection environment. Therefore for the purpose of the CDNI Interconnection environment. Therefore for the purpose of the CDNI
WG there are already multiple existing data plane protocols that can working group there are already multiple existing data plane
be used for content acquisition across CDNs. protocols that can be used for content acquisition across CDNs.
Similarly, there are multiple existing standards (e.g. the OIPF data Similarly, there are multiple existing standards (e.g. the OIPF data
plane mentioned above, HTTP adaptive streaming [_3GP-DASH]) or public plane mentioned above, HTTP adaptive streaming [3GP-DASH]) or public
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 CDNI. CDNI may only concern itself with the are out of scope for the CDNI working group. The CDNI working group
negotiation/selection aspects of the acquisition protocol to be used may only concern itself with the negotiation/selection aspects of the
in a CDN interonnect scenario. acquisition protocol to be used in a CDN interonnect scenario.
5.2. CDNI Metadata 5.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-
skipping to change at page 22, line 22 skipping to change at page 22, line 34
6.1. ALTO 6.1. ALTO
As stated in the ALTO Working Group charter [ALTO-Charter]: As stated in the ALTO Working Group charter [ALTO-Charter]:
"The Working Group will design and specify an Application-Layer "The Working Group will design and specify an Application-Layer
Traffic Optimization (ALTO) service that will provide applications Traffic Optimization (ALTO) service that will provide applications
with information to perform better-than-random initial peer with information to perform better-than-random initial peer
selection. ALTO services may take different approaches at balancing selection. ALTO services may take different approaches at balancing
factors such as maximum bandwidth, minimum cross-domain traffic, factors such as maximum bandwidth, minimum cross-domain traffic,
lowest cost to the user, etc. The WG will consider the needs of lowest cost to the user, etc. The working group will consider the
BitTorrent, tracker-less P2P, and other applications, such as content needs of BitTorrent, tracker-less P2P, and other applications, such
delivery networks (CDN) and mirror selection." as content delivery networks (CDN) and mirror selection."
In particular, the ALTO service can be used by a CDN Request Routing 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 system to improve its selection of a CDN surrogate to serve a
particular User Agent request (or to serve a request from another particular User Agent request (or to serve a request from another
surrogate). [I-D.jenkins-alto-cdn-use-cases] describes a number of 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 use cases for a CDN to be able to obtain network topology and cost
information from an ALTO server(s) and [I-D.penno-alto-cdn] discusses information from an ALTO server(s) and discusses how CDN Request
how CDN Request Routing could be used as an integration point of ALTO Routing could be used as an integration point of ALTO into CDNs. It
into CDNs. It is possible that the ALTO service could be used in the is possible that the ALTO service could be used in the same manner in
same manner in a multi-CDN environment based on CDN Interconnection. a multi-CDN environment based on CDN Interconnection. For example,
For example, an upstream CDN may take advantage of the ALTO service an upstream CDN may take advantage of the ALTO service in its
in its decision for selecting a downstream CDN to which a user decision for selecting a downstream CDN to which a user request
request should be delegated. should be delegated.
However, the work of ALTO is complementary to and does not overlap However, the current work of ALTO is complementary to and does not
with the work described in this document because the integration overlap with the work described in this document because the
between ALTO and a CDN is an internal decision for a specific CDN and integration between ALTO and a CDN is an internal decision for a
is therefore out of scope for the CDNI WG. One area for further specific CDN and is therefore out of scope for the CDNI working
study is whether additional information should be provided by an ALTO group. One area for further study is whether additional information
service to facilitate CDNI CDN selection. should be provided by an ALTO service to facilitate CDNI CDN
selection.
6.2. DECADE 6.2. DECADE
The DECADE Working Group [DECADE-Charter] is addressing the problem The DECADE Working Group [DECADE-Charter] is addressing the problem
of reducing traffic on the last-mile uplink, as well as backbone and of reducing traffic on the last-mile uplink, as well as backbone and
transit links caused by P2P streaming and file sharing applications. transit links caused by P2P streaming and file sharing applications.
It addresses the problem by enabling an application endpoint to make It addresses the problem by enabling an application endpoint to make
content available from an in-network storage service and by enabling content available from an in-network storage service and by enabling
other application endpoints to retrieve the content from there. other application endpoints to retrieve the content from there.
Exchanging data through the in-network storage service in this Exchanging data through the in-network storage service in this
manner, instead of through direct communication, provides significant manner, instead of through direct communication, provides significant
gain where: gain where:
o The network capacity/bandwidth from in-network storage service to o The network capacity/bandwidth from in-network storage service to
application endpoint significantly exceeds the capacity/bandwidth application endpoint significantly exceeds the capacity/bandwidth
skipping to change at page 24, line 21 skipping to change at page 24, line 33
Therefore, the work of DECADE may be complementary to but does not Therefore, the work of DECADE may be complementary to but does not
overlap with the CDNI work described in this document. overlap with the CDNI work described in this document.
6.3. PPSP 6.3. PPSP
As stated in the PPSP Working Group charter [PPSP-Charter]: As stated in the PPSP Working Group charter [PPSP-Charter]:
"The Peer-to-Peer Streaming Protocol (PPSP) working group develops "The Peer-to-Peer Streaming Protocol (PPSP) working group develops
two signaling and control protocols for a peer-to-peer (P2P) two signaling and control protocols for a peer-to-peer (P2P)
streaming system for transmitting live and time-shifted media content streaming system for transmitting live and time-shifted media content
with near real-time delivery requirements." and "The PPSP WG designs with near real-time delivery requirements." and "The PPSP working
a protocol for signaling and control between trackers and peers (the group designs a protocol for signaling and control between trackers
PPSP "tracker protocol") and a signaling and control protocol for and peers (the PPSP "tracker protocol") and a signaling and control
communication among the peers (the PPSP "peer protocol"). The two protocol for communication among the peers (the PPSP "peer
protocols enable peers to receive streaming data within the time protocol"). The two protocols enable peers to receive streaming data
constraints required by specific content items." within the time constraints required by specific content items."
Therefore PPSP is concerned with the distribution of the streamed Therefore PPSP is concerned with the distribution of the streamed
content itself along with the necessary signaling and control content itself along with the necessary signaling and control
required to distribute the content. As such, it could potentially be required to distribute the content. As such, it could potentially be
used for the acquisition of streamed content across interconnected used for the acquisition of streamed content across interconnected
CDNs. But since the acquisition protocol is outside the scope of the CDNs. But since the acquisition protocol is outside the scope of the
work proposed for CDNI, we leave this for further study. Also, work proposed for CDNI, we leave this for further study. Also,
because of its streaming nature, PPSP is not seen as applicable to because of its streaming nature, PPSP is not seen as applicable to
the distribution and control of the CDNI control plane and CDNI data the distribution and control of the CDNI control plane and CDNI data
representations. representations.
skipping to change at page 25, line 18 skipping to change at page 25, line 29
new set of security considerations by extending the trust model (i.e. new set of security considerations by extending the trust model (i.e.
the CSP "trusts" a CDN that "trusts" another CDN). the CSP "trusts" a CDN that "trusts" another CDN).
Maintaining the security of the content itself, its associated Maintaining the security of the content itself, its associated
metadata (including distribution and delivery policies) and the CDNs metadata (including distribution and delivery policies) and the CDNs
distributing and delivering it, are critical requirements for both distributing and delivering it, are critical requirements for both
CDN Providers and CSPs and any work on CDN Interconnection must CDN Providers and CSPs and any work on CDN Interconnection must
provide sufficient mechanisms to maintain the security of the overall provide sufficient mechanisms to maintain the security of the overall
system of interconnected CDNs as well as the information (content, system of interconnected CDNs as well as the information (content,
metadata, logs, etc) distributed and delivered through any CDN metadata, logs, etc) distributed and delivered through any CDN
interconnects. interconnections.
9. Acknowledgements 9. Acknowledgements
The authors would like to thank Andre Beck, Gilles Bertrand, Mark The authors would like to thank Andre Beck, Gilles Bertrand, Mark
Carlson, Bruce Davie, David Ferguson, Yiu Lee, Kent Leung, Will Li, Carlson, Bruce Davie, David Ferguson, Yiu Lee, Kent Leung, Will Li,
Kevin Ma, Julien Maisonneuve, Guy Meador, Emile Stephan, Oskar van Kevin Ma, Julien Maisonneuve, Guy Meador, Emile Stephan, Oskar van
Deventer and Mahesh Viveganandhan for their review comments and Deventer and Mahesh Viveganandhan for their review comments and
contributions to the text. contributions to the text.
10. References 10. References
10.1. Normative References 10.1. Normative References
10.2. Informative References 10.2. Informative References
[3GP-DASH]
"Transparent end-to-end Packet-switched Streaming Service
(PSS); Progressive Download and Dynamic Adaptive Streaming
over HTTP (3GP-DASH)
http://www.3gpp.org/ftp/Specs/html-info/26247.htm".
[ALTO-Charter] [ALTO-Charter]
"IETF ALTO WG Charter "IETF ALTO WG Charter
(http://datatracker.ietf.org/wg/alto/charter/)". (http://datatracker.ietf.org/wg/alto/charter/)".
[ATIS] "ATIS (http://www.atis.org/)". [ATIS] "ATIS (http://www.atis.org/)".
[ATIS-COD] [ATIS-COD]
"ATIS IIF: IPTV Content on Demand Service, January 2011 (h "ATIS IIF: IPTV Content on Demand Service, January 2011 (h
ttp://www.atis.org/iif/_Com/Docs/Task_Forces/ARCH/ ttp://www.atis.org/iif/_Com/Docs/Task_Forces/ARCH/
ATIS-0800042.pdf)". ATIS-0800042.pdf)".
skipping to change at page 26, line 21 skipping to change at page 26, line 38
"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]
Bertrand, G., Faucheur, F., and L. Peterson, "Content Bertrand, G., Faucheur, F., and L. Peterson, "Content
Distribution Network Interconnection (CDNI) Experiments", Distribution Network Interconnection (CDNI) Experiments",
draft-bertrand-cdni-experiments-01 (work in progress), draft-bertrand-cdni-experiments-01 (work in progress),
August 2011. August 2011.
[I-D.ietf-cdni-use-cases] [I-D.ietf-cdni-use-cases]
Bertrand, G., Emile, S., Watson, G., Burbridge, T., Gilles, B., Emile, S., Watson, G., Burbridge, T., Eardley,
Eardley, P., and K. Ma, "Use Cases for Content Delivery P., and K. Ma, "Use Cases for Content Delivery Network
Network Interconnection", draft-ietf-cdni-use-cases-00 Interconnection", draft-ietf-cdni-use-cases-01 (work in
(work in progress), September 2011. progress), December 2011.
[I-D.jenkins-alto-cdn-use-cases] [I-D.jenkins-alto-cdn-use-cases]
Niven-Jenkins, B., Watson, G., Bitar, N., Medved, J., and Niven-Jenkins, B., Watson, G., Bitar, N., Medved, J., and
S. Previdi, "Use Cases for ALTO within CDNs", S. Previdi, "Use Cases for ALTO within CDNs",
draft-jenkins-alto-cdn-use-cases-01 (work in progress), draft-jenkins-alto-cdn-use-cases-01 (work in progress),
June 2011. June 2011.
[I-D.penno-alto-cdn]
Penno, R., Medved, J., Alimi, R., Yang, R., and S.
Previdi, "ALTO and Content Delivery Networks",
draft-penno-alto-cdn-03 (work in progress), March 2011.
[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",
September 2010. September 2010.
skipping to change at page 27, line 49 skipping to change at page 28, line 12
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
architecture"", September 2008. architecture"", September 2008.
[Y.2019] "ITU-T Recomendation Y.2019 "Content delivery functional [Y.2019] "ITU-T Recomendation Y.2019 "Content delivery functional
architecture in NGN"", September 2010. architecture in NGN"", September 2010.
[_3GP-DASH]
"Transparent end-to-end Packet-switched Streaming Service
(PSS); Progressive Download and Dynamic Adaptive Streaming
over HTTP (3GP-DASH)
http://www.3gpp.org/ftp/Specs/html-info/26247.htm".
Appendix A. Additional Material Appendix A. Additional Material
Note to RFC Editor: This appendix is to be removed on publication as Note to RFC Editor: This appendix is to be removed on publication as
an RFC. an RFC.
A.1. Non-Goals for IETF A.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 a potential CDNI working group:
o The interface between Content Service Provider and the o The interface between Content Service Provider and the
skipping to change at page 29, line 35 skipping to change at page 29, line 38
interconnections of CDNs. interconnections of CDNs.
A.2. Related standardization activities A.2. Related standardization activities
A.2.1. IETF CDI Working Group (Concluded) A.2.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 WG charter For convenience, here is an extract from the CDI working group
[CDI-Charter]: charter [CDI-Charter]:
" "
o The goal of this working group is to define protocols to allow the o The goal of this working group is to define protocols to allow the
interoperation of separately-administered content networks. interoperation of separately-administered content networks.
o A content network is an architecture of network elements, arranged o A content network is an architecture of network elements, arranged
for efficient delivery of digital content. Such content includes, for efficient delivery of digital content. Such content includes,
but is not limited to, web pages and images delivered via HTTP, but is not limited to, web pages and images delivered via HTTP,
and streaming or continuous media which are controlled by RTSP. and streaming or continuous media which are controlled by RTSP.
o The working group will first define requirements for three modes o The working group will first define requirements for three modes
skipping to change at page 30, line 4 skipping to change at page 30, line 7
o A content network is an architecture of network elements, arranged o A content network is an architecture of network elements, arranged
for efficient delivery of digital content. Such content includes, for efficient delivery of digital content. Such content includes,
but is not limited to, web pages and images delivered via HTTP, but is not limited to, web pages and images delivered via HTTP,
and streaming or continuous media which are controlled by RTSP. and streaming or continuous media which are controlled by RTSP.
o The working group will first define requirements for three modes o The working group will first define requirements for three modes
of content internetworking: interoperation of request-routing of content internetworking: interoperation of request-routing
systems, interoperation of distribution systems, and systems, interoperation of distribution systems, and
interoperation of accounting systems. These requirements are interoperation of accounting systems. These requirements are
intended to lead to a follow-on effort to define protocols for intended to lead to a follow-on effort to define protocols for
interoperation of these systems. interoperation of these systems.
o In its initial form, the working group is not chartered to deliver o In its initial form, the working group is not chartered to deliver
those protocols [...] those protocols [...]
" "
Thus, the CDI WG touched on the same problem space as the present Thus, the CDI working group touched on the same problem space as the
document. present document.
The CDI WG 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".
A.2.2. 3GPP A.2.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 is preparing an extended version for Release 10, which addition, 3GPP is preparing an extended version for Release 10, which
is scheduled to be published later in 2011. This release will is scheduled to be published later in 2011. This release will
include a number of clarifications, improvements and new features. include a number of 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
encapsulation format. It has support for fast initial startup and encapsulation format. It has support for fast initial startup and
seeking, adaptive bitrate switching, re-use of HTTP origin and cache seeking, adaptive bitrate switching, re-use of HTTP origin and cache
servers, re-use of existing media playout engines, on-demand, live servers, re-use of existing media playout engines, on-demand, live
and time-shifted delivery. It specifies syntax and semantics of and time-shifted delivery. It specifies syntax and semantics of
Media Presentation Description (MPD), format of segments and delivery Media Presentation Description (MPD), format of segments and delivery
protocol for segments. It does not specify content provisioning, protocol for segments. It does not specify content provisioning,
client behavior or transport of MPD. client behavior or transport of MPD.
The content retrieved by a client using [_3GP-DASH] adaptive The content retrieved by a client using [3GP-DASH] adaptive streaming
streaming could be obtained from a CDN but this is not discussed or could be obtained from a CDN but this is not discussed or specified
specified in the 3GPP specifications as it is transparent to in the 3GPP specifications as it is transparent to [3GP-DASH]
[_3GP-DASH] operations. Similarly, it is expected that [_3GP-DASH] operations. Similarly, it is expected that [3GP-DASH] can be used
can be used transparently from the CDNs as a delivery protocol transparently from the CDNs as a delivery protocol (between the
(between the delivering CDN surrogate and the User Agent) in a CDN delivering CDN surrogate and the User Agent) in a CDN Interconnection
Interconnection environment. [_3GP-DASH] could also be a candidate environment. [3GP-DASH] could also be a candidate for content
for content acquisition between CDNs in a CDN Interconnection acquisition between CDNs in a CDN Interconnection environment.
environment.
A.2.3. ISO MPEG A.2.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
Agent and for content acquisition between CDNs in a CDN Agent and for content acquisition between CDNs in a CDN
Interconnection environment. The Draft International Standard (DIS) Interconnection environment. The Draft International Standard (DIS)
version [MPEG-DASH] is currently publicly available since early version [MPEG-DASH] is currently publicly available since early
 End of changes. 90 change blocks. 
269 lines changed or deleted 294 lines changed or added

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