< draft-jenkins-cdni-problem-statement-00.txt   draft-jenkins-cdni-problem-statement-01.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: June 5, 2011 Cisco Expires: July 21, 2011 Cisco
N. Bitar N. Bitar
Verizon Verizon
December 2, 2010 January 17, 2011
Content Distribution Network Interconnection (CDNI) Problem Statement Content Distribution Network Interconnection (CDNI) Problem Statement
draft-jenkins-cdni-problem-statement-00 draft-jenkins-cdni-problem-statement-01
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 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 for the IETF The goal of this document is to outline the problem area for the IETF
with a view towards creating a working group. This working group with a view towards creating a working group. This working group
would work on interoperable and scalable solutions for CDN would work on interoperable and scalable solutions for CDN
skipping to change at page 2, line 11 skipping to change at page 2, line 11
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 June 5, 2011. This Internet-Draft will expire on July 21, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
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 . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. CDN Background . . . . . . . . . . . . . . . . . . . . . . 6 1.2. CDN Background . . . . . . . . . . . . . . . . . . . . . . 8
2. CDN Interconnect Use Cases . . . . . . . . . . . . . . . . . . 6 2. CDN Interconnect Use Cases . . . . . . . . . . . . . . . . . . 9
3. Gap Analysis of relevant Standardization Activities . . . . . 7 3. CDN Interconnect Model & Problem Area for IETF . . . . . . . . 10
3.1. IETF Concluded CDI Working Group . . . . . . . . . . . . . 7 3.1. Candidate CDNI Problem Area for IETF . . . . . . . . . . . 12
3.2. IRTF P2P Research Group . . . . . . . . . . . . . . . . . 8 3.2. Non-Goals for IETF . . . . . . . . . . . . . . . . . . . . 13
3.3. ETSI . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Design Approach for Realizing the CDNI APIs . . . . . . . . . 14
3.3.1. TISPAN . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Relationship to the OSI network model . . . . . . . . . . 15
3.3.2. MCD . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. "Reuse Instead of Reinvent" Principle . . . . . . . . . . 15
3.4. ATIS IIF . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.3. CDNI Request Routing API . . . . . . . . . . . . . . . . . 15
3.5. Open IPTV Forum (OIPF) . . . . . . . . . . . . . . . . . . 10 4.4. CDNI Metadata API . . . . . . . . . . . . . . . . . . . . 17
3.6. ITU-T . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.5. CDNI Logging API . . . . . . . . . . . . . . . . . . . . . 18
3.7. OCEAN . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.6. CDNI Control API . . . . . . . . . . . . . . . . . . . . . 19
3.8. CableLabs VoD Metadata . . . . . . . . . . . . . . . . . . 11 5. Prioritizing the CDNI Work . . . . . . . . . . . . . . . . . . 19
4. CDN Interconnect Problem Area for IETF . . . . . . . . . . . . 11 6. Gap Analysis of relevant Standardization and Research
4.1. Candidate CDNI Goals for IETF . . . . . . . . . . . . . . 13 Activities . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2. Non-Goals for IETF . . . . . . . . . . . . . . . . . . . . 14 6.1. Related standardization activities . . . . . . . . . . . . 20
5. Relationship to relevant IETF Working Group . . . . . . . . . 15 6.1.1. IETF CDI Working Group (Concluded) . . . . . . . . . . 20
5.1. ALTO . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.1.2. 3GPP . . . . . . . . . . . . . . . . . . . . . . . . . 21
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6.1.3. ATIS IIF . . . . . . . . . . . . . . . . . . . . . . . 21
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6.1.4. Cable Labs . . . . . . . . . . . . . . . . . . . . . . 22
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 6.1.5. ETSI MCD . . . . . . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.1.6. ETSI TISPAN . . . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 6.1.7. ITU-T . . . . . . . . . . . . . . . . . . . . . . . . 23
9.2. Informative References . . . . . . . . . . . . . . . . . . 16 6.1.8. Open IPTV Forum (OIPF) . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 6.1.9. TV-Anytime Forum . . . . . . . . . . . . . . . . . . . 23
6.1.10. SNIA . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.2. Related Research Projects . . . . . . . . . . . . . . . . 24
6.2.1. IRTF P2P Research Group . . . . . . . . . . . . . . . 24
6.2.2. OCEAN . . . . . . . . . . . . . . . . . . . . . . . . 24
6.2.3. Eurescom P1955 . . . . . . . . . . . . . . . . . . . . 24
6.3. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . 25
6.3.1. Content Acquisition across CDNs and Delivery to
End User (Data plane) . . . . . . . . . . . . . . . . 25
6.3.2. CDNI Metadata . . . . . . . . . . . . . . . . . . . . 26
7. Relationship to relevant IETF Working Groups . . . . . . . . . 27
7.1. ALTO . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
7.2. DECADE . . . . . . . . . . . . . . . . . . . . . . . . . . 28
7.3. PPSP . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
9. Security Considerations . . . . . . . . . . . . . . . . . . . 30
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
11.1. Normative References . . . . . . . . . . . . . . . . . . . 30
11.2. Informative References . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32
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. It is Service Providers (NSPs) are deploying their own CDNs. It is
generally desirable that a given content item can be delivered to an generally desirable that a given content item can be delivered to an
end user regardless of that user's location or attachment network. End User regardless of that End User's location or attachment
This creates a requirement for interconnecting standalone CDNs so network. However, the footprint of a given CDN in charge of
they can interoperate as an open content delivery infrastructure for delivering a given content may not expand close enough to the End
the end-to-end delivery of content from Content Service Providers User's current location or attachment network to realize the cost
(CSPs) to end users. However, no standards or open specifications benefit and user experience that a more distributed CDN would
currently exist to facilitate such CDN interconnection. provide. This creates a requirement for interconnecting standalone
CDNs so that their collective CDN footprint can be leveraged for the
end-to-end delivery of content from Content Service Providers (CSPs)
to End Users. However, no standards or open specifications currently
exist to facilitate such CDN interconnection.
The goal of this document is to outline the problem area for the IETF The goal of this document is to outline the problem area for the IETF
with a view towards creating a working group. This working group with a view towards creating a working group. This working group
would work on interoperable and scalable solutions for CDN would work on interoperable and scalable solutions for CDN
interconnection. interconnection.
Section 2 discusses the use cases for CDN interconnection. Section 3
presents the CDNI model and problem area to be considered by the
IETF. Section 4 discusses how existing protocols can be reused to
define the CDNI APIs while Section 5 proposes to focus the scope for
the initial charter of a CDNI Working Group to the minimum functional
elements necessary for basic CDN interconnection. Section 5 provides
a gap analysis of the work of other standards organization and
finally Section 5 discusses the relationship with 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 Metata: this is metadata about content. It may vary in depth Content Metadata: This is metadata about Content. Content Metadata
from merely identifying the content (e.g. title or other information comprises:
to populate a program guide), to providing a complete index of
different scenes in a movie or providing business rules detailing how
the content may be displayed, copied, or sold and it can include
policies to control the distribution and delivery of the content.
Content Distribution Metadata: Content Distribution Metadata is the 1. Metadata that is relevant to the distribution of the content (and
subset of the Metadata pertaining to rules that control how the therefore relevant to a CDN involved in the delivery of that
content is to be distributed and delivered by CDNs. content). We refer to this type of metadata as "Content
Distribution Metadata". See also the definition of Content
Distribution Metadata.
2. Metadata that is associated with the actual Content (and not
directly relevant to the distribution of that Content) or content
representation. For example, such metadata may include
information pertaining to the Content's genre, cast, rating, etc
as well as information pertaining to the Content representation's
resolution, aspect ratio, etc.
User: The 'real' user of the system, typically a human but maybe some Content Distribution Metadata: The subset of Content Metadata that is
combination of hardware and/or software emulating a human (e.g. for relevant to the distribution of the content. This is the metadata
automated quality monitoring etc.) required by a CDN in order to enable and control content distribution
and delivery by the CDN. In a CDN Interconnection environment, some
of the Content Distribution Metadata may have an intra-CDN scope (and
therefore need not be communicated between CDNs), while some of the
Content Distribution Metadata have an inter-CDN scope (and therefore
needs to be communicated between CDNs).
CDNI Metadata: Content Distribution Metadata with inter-CDN scope.
For example, CDNI Metadata may include geo-blocking information (i.e.
information defining geographical areas where the content is to be
made available or blocked), availability windows (i.e. information
defining time windows during which the content is to be made
available or blocked) and access control mechanisms to be enforced
(e.g. URI signature validation). CDNI Metadata may also include
information about desired distribution policy (e.g. prepositioning vs
dynamic acquisition) and about where/how a CDN can acquire the
content. CDNI Metadata may also include content management
information (e.g. request for deletion of Content from Surrogates)
across interconnected CDNs.
End User (EU): The 'real' user of the system, typically a human but
maybe some combination of hardware and/or software emulating a human
(e.g. for automated quality monitoring etc.)
User Agent (UA): Software (or a combination of hardware and software)
through which the End User interacts with the Content Service. The
User Agent will communicate with the CSP's Service for the selection
of content and one or more CDNs for the delivery of the Content.
Such communication is not restricted to HTTP and may be via a variety
of protocols. Examples of User Agents (non-exhaustive) are:
Browsers, Set Top Boxes (STB), Dedicated content applications (e.g.
media players), etc.
Network Service Provider (NSP): Provides network-based connectivity/ Network Service Provider (NSP): Provides network-based connectivity/
services to Users. services to Users.
Content Service Provider (CSP): Provides a Content Service to Users. Content Service Provider (CSP): Provides a Content Service to End
A CSP may own the content made available as part of the Content Users (which they access via a User Agent). A CSP may own the
Service, or may license content rights from another party. Content made available as part of the Content Service, or may license
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 the delivery of items of Content, e.g. the Content
Service also includes any middleware, key distribution, program Service also includes any middleware, key distribution, program
guide, etc. which may not require any direct interaction with the guide, etc. which may not require any direct interaction with the
CDN. CDN.
Content Distribution Network (CDN) / Content Delivery Network (CDN): Content Distribution Network (CDN) / Content Delivery Network (CDN):
A type of network in which the content network elements are arranged Network infrastructure in which the network elements cooperate at
for more effective delivery of content to User Agents. Typically a layers 4 through layer 7 for more effective delivery of Content to
CDN consists of a Request Routing system, a Distribution System and a User Agents. Typically a CDN consists of a Request Routing system, a
set of Surrogates. Distribution System (that includes a set of Surrogates), a Logging
System and a CDN control system .
CDN Provider: The service provider who operates a CDN. CDN Provider: The service provider who operates a CDN. Note that a
given entity may 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 Interconnect (CDNI): The set of interfaces over which two or more CDN Interconnect (CDNI): The set of interfaces over which two or more
CDNs communicate with each other in order to achieve the delivery of CDNs communicate with each other in order to achieve the delivery of
content to users by surrogates in one CDN (the downstream CDN) on content to User Agents by Surrogates in one CDN (the downstream CDN)
behalf of another CDN (the upstream CDN). on behalf of another CDN (the upstream CDN).
Over-the-top (OTT): A service, e.g. a CDN, operated over the Internet Upstream CDN: For a given user request, the CDN (within a pair of
rather than by a particular NSP. directly interconnected CDNs) that redirects the request to the other
CDN.
Downstream CDN: For a given user request, the CDN (within a pair of
directly interconnected CDNs) to which the request is redirected 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.
CDN2) may act as the Downstream CDN for a redirection (e.g.
CDN1-->CDN2) and as the Upstream CDN for the subsequent redirection
of the same request (e.g. CDN2-->CDN3).
Over-the-top (OTT): A service, e.g. a CDN, operated by a different
operator than the NSP to which the users of 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
steering or directing a content request received directly from an end receiving a content request from a user agent, obtaining and
user to a suitable Surrogate. maintaining necessary information about a set of candidate surrogates
or candidate CDNs, and for selecting and redirecting the user to the
appropriate surrogate or CDN. To enable CDN Interconnect, the
Request Routing System must also be capable of handling user agent
content requests passed to it by another CDN.
Distribution System: the function within a CDN responsible for Distribution System: the function within a CDN responsible for
distributing Content Distribution Metadata as well as content inside distributing Content Distribution Metadata as well as content inside
the CDN (e.g. down to the surrogates) the CDN (e.g. down to the surrogates)
Delivery: the function within CDN surrogates responsible for Delivery: the function within CDN surrogates responsible for
delivering a piece of content to the end user. For example, delivery delivering a piece of content to the User Agent. For example,
may be based on HTTP progressive download or HTTP adaptive streaming. delivery may be based on HTTP progressive download or HTTP adaptive
streaming.
Logging System: the function within a CDN responsible for collecting Logging System: the function within a CDN responsible for collecting
measurement and recording of distribution and delivery activities. measurement and recording of distribution and delivery activities.
The information recorded by the logging system may be used for The information recorded by the logging system may be used for
various purposes including charging (e.g. of the CSP), analytics and various purposes including charging (e.g. of the CSP), analytics and
monitoring. monitoring.
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
skipping to change at page 6, line 36 skipping to change at page 9, line 12
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 Interconnect 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 so that a given item CDNs allow caching of content closer to the edge so that a given item
of content can be delivered by a CDN surrogate (i.e. a cache) to of content can be delivered by a CDN Surrogate (i.e. a cache) to
multiple end users without transiting multiple times through the multiple User Agents (and their End Users) without transiting
network core (i.e from the content origin to the cache). This multiple times through the network core (i.e from the content origin
contributes to bandwidth cost reductions for the NSP. CDNs also to the surrogate). This contributes to bandwidth cost reductions for
enable replication of popular content across many surrogates, which the NSP and to improved quality of experience for the end users.
enables content to be served to large numbers of users concurrently. CDNs also enable replication of popular content across many
This also helps dealing with situations such as flash crowds and surrogates, which enables content to be served to large numbers of
denial of service attacks. User Agents concurrently. This also helps dealing with situations
such as flash crowds and denial of service attacks.
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 delivery of IPTV services to Set Top Boxes, but are services, such as IP delivery of television services to Set Top
also used for delivery of content to other devices including PCs, Boxes, but are also used for delivery of content to other devices
tablets, mobile phones etc. including PCs, tablets, mobile phones etc.
Traditional CDNs have operated as over-the-top providers of digital
content distribution services, operating as an overlay on the
Internet. More recently, Network Service Providers have begun to
operate their own CDNs by deploying CDN devices within their network
infrastructure.
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. However there are no open
specifications, nor common best practices, defining how to achieve specifications, nor common best practices, defining how to achieve
such CDN interconnection. 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 users and/or over many/all geographies and/or with a large number of End Users and/or over many/all geographies and/or
high quality of experience, all without having to maintain direct with a high quality of experience, all without having to maintain
business relationships with many different CDN providers. Some NSPs direct business relationships with many different CDN providers (or
are considering interconnecting their respective CDNs (as well as having to extend their own CDN to a large number of locations). Some
possibly over-the-top CDNs) so that this collective infrastructure NSPs are considering interconnecting their respective CDNs (as well
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. In
particular, this would enable the CSPs to benefit from on-net particular, this would enable the CSPs to benefit from on-net
delivery (i.e. within the Network Service Provider's own network/CDN delivery (i.e. within the Network Service Provider's own network/CDN
footprint) whenever possible and off-net delivery otherwise without footprint) whenever possible and off-net delivery otherwise, without
requiring the CSPs having to maintain direct business relationships requiring the CSPs to maintain direct business relationships with all
with all the CDNs involved in the delivery. Again, for this the CDNs involved in the delivery. Again, for this requirement, CDN
requirement, CDN operators (NSPs or over-the-top) are faced with a operators (NSPs or over-the-top CDN operators) are faced with a lack
lack of open specifications and best practices. of open specifications and best practices.
Finally, NSPs have often deployed CDNs as specialized cost-reduction NSPs have often deployed CDNs as specialized cost-reduction projects
projects within the context of a particular service or environment, within the context of a particular service or environment, some NSPs
some NSPs operate separate CDNs for separate services. For example, operate separate CDNs for separate services. For example, there may
there may be a CDN for managed IPTV service delivery, a CDN for be a CDN for managed IPTV service delivery, a CDN for web-TV delivery
web-TV delivery and a CDN for video delivery to Mobile terminals. As and a CDN for video delivery to Mobile terminals. As NSPs integrate
NSPs integrate their service portfolio, there is a need for their service portfolio, there is a need for interconnecting these
interconnecting these CDNs. Again, NSPs face the problem of lack of CDNs. Again, NSPs face the problem of lack of open interfaces for
open interfaces for CDN interconnection. CDN interconnection.
3. Gap Analysis of relevant Standardization Activities For operational reasons (e.g. disaster, flash crowd) or commercial
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
serving a subset of the user requests (e.g. requests from users
attached to that NSP). Again, for this requirement, CDN operators
(over-the-top CDN operators or NSPs) are faced with a lack of open
specifications and best practices.
3.1. IETF Concluded CDI Working Group Use cases for CDN Interconnection are further discussed in
[I-D.watson-cdni-use-cases] and [I-D.bertrand-cdni-use-cases].
3. CDN Interconnect Model & Problem Area for IETF
Interconnecting CDNs involves interactions among multiple different
functions and components that form each CDN. Only some of those
require standardization. The CDNI model and problem area proposed
for IETF work is illustrated in Figure 1. The candidate problem area
(and respectively the non-goals) for IETF work on CDN Interconnection
are discussed in Section 3.1 (and respectively Section 3.2 ).
--------
/ \
| CSP |
\ /
--------
*
*
* /\
* / \
--------------------- |CDNI| ---------------------
/ Upstream CDN \ | | / Downstream CDN \
| +-------------+ | Control API | +-------------+ |
| |CDN Control |<======|====|=======>| CDN Control | |
| +------*-*-*--+ | | | | +-*-*-*-------+ |
| * * * | | | | * * * |
| +------*------+ | Logging API | +-----*-------+ |
| ****| Logging |<======|====|=======>| Logging |**** |
| * --------------+ | | | | +-------------+ * |
| * * * | | | | * * * |
| * +--------*----+ | Req-Routing API | +---*---------+ * |
| * **|Req-Routing |<======|====|=======>| Req-Routing |** * |
| * * +-------------+ | | | | +-------------+ * * |
| * * * | | | | * * * |
| * * +----------*--+ |CDNI Metadata API| +-*-----------+ * * |
| * * |Distribution |<======|====|=======>| Distribution| * * |
| * * | | | \ / | | | * * |
| * * | | | \/ | | | * * |
| * ****+---------+ | | | | +---------+**** * |
| ******|Surrogate|*************************|Surrogate|****** |
| | +---------+ | | Acquisition | | +-----*---+ | |
| +-------------+ | | +-------*-----+ |
\ / \ * /
--------------------- ---------*-----------
*
* Delivery
*
+------+
| User |
| Agent|
+------+
<==> interfaces inside the scope of CDNI
**** interfaces outside the scope of CDNI
Figure 1: CDNI Problem Area
3.1. Candidate CDNI Problem Area for IETF
Listed below are the four APIs required to interconnect a pair 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
the term "API" is meant to encompass the protocol over which CDNI
data representations (e.g. CDNI Metadata records) are exchanged as
well as the specification of the data representations themselves
(i.e. what properties/fields each record contains, its structure,
etc.). While "interface" would be a more accurate term, the term
"API" is retained in this document because of its common use.
o CDNI Control API: This API allows the "CDNI Control" system in
interconnected CDNs to communicate. This API may support the
following:
* Allow bootstrapping of the other CDNI APIs (e.g. API address
discovery and establishment of security associations).
* Allow configuration of the other CDNI APIs (e.g. Upstream CDN
specifies information to be reported through the CDNI Logging
API).
* Allow the downstream CDN to communicate information about its
delivery capabilities, resources and policies.
* Allow bootstrapping of the interface between CDNs for content
acquisition (even if that interface itself is outside the scope
of the CDNI work).
o CDNI Request Routing API: This API allows the Request Routing
system in interconnected CDNs to communicate to ensure that an end
user request can be (re)directed from an upstream CDN to a
surrogate in the downstream CDN, in particular where selection
responsibilities may be split across CDNs (for example the
upstream CDN may be responsible for selecting the downstream CDN
while the downstream CDN may be responsible for selecting the
actual surrogate within that CDN).
o CDNI Metadata Signaling API: This API allows:
* The Distribution system in interconnected CDNs to communicate
to ensure CDNI Metadata can be exchanged across CDNs. See
Section 1.1 for definition and examples of CDNI Metadata.
* Limited control management of a downstream CDN by an upstream
CDN, for example to allow an upstream CDN to request that
content files and/or CDNI Metadata that it shared to be purged
from a downstream CDN. Support for content deletion from a CDN
is a key requirement for some Content Service Providers in
order, amongst other use cases for content deletion, to support
the content rights agreements they have negotiated. Today's
CDNs use proprietary control interfaces to enable CSPs to
remove content cached in the CDN and therefore there is a need
to have a similar but standardised content deletion capability
between interconnected CDNs.
o CDNI Logging API: This API allows the Logging system in
interconnected CDNs to communicate the relevant activity logs in
order to allow log consuming applications to operate in a multi-
CDN environments. For example, an upstream CDN may collect
delivery logs from a downstream CDN in order to perform
consolidated charging of the CSP or for settlement purposes across
CDNs. Similarly, an upstream CDN may collect delivery logs from a
downstream CDN in order to provide consolidated reporting and
monitoring to the CSP.
Note that the actual grouping of functionalities under these four
APIs is considered tentative at this stage and may be changed after
further study (e.g. some subset of functionality be moved from one
API into another).
The above list covers a significant potential problem space, in part
because in order to interconnect two CDNs there are several 'touch
points' that require standardization. However, it is expected that
the CDNI APIs need not be defined from scratch and instead can very
significantly reuse or leverage existing protocols: this is discussed
further in Section 4. Also, it is expected that the items above will
be prioritized so that the CDNI Working Group can focus (at least
initially) on the most esssential and urgent work: this is discussed
further in Section 5.
3.2. Non-Goals for IETF
Listed below are aspects of content delivery that the authors propose
be kept outside of the scope of a potential CDNI working group:
o The interface between Content Service Provider and the
Authoritative CDN (i.e. the upstream CDN contracted by the CSP for
delivery by this CDN or by its downstream CDNs).
o The delivery interface between the delivering CDN surrogate and
the User Agent, such as streaming protocols.
o The content acquisition interface between CDNs (i.e. the data
plane interface for actual delivery of a piece of content from one
CDN to the other). This is expected to use existing protocols
such as HTTP or protocols defined in other forums for content
acquisition between an origin server and a CDN (e.g. HTTP-based
C2 reference point of ATIS IIF CoD). The CDN Interconnection
solution may only concern itself with the agreement/negotiation
aspects of which content acquisition protocol is to be used
between two interconnected CDNs in view of facilitating
interoperability.
o End User/User Agent Authentication. End User/User Agent
authentication and authorization are the responsibility of the
Content Service Provider.
o Content preparation, including encoding and transcoding. The CDNI
architecture aims at allowing distribution across interconnected
CDNs of content treated as opaque objects. Interpretation and
processing of the objects, as well as optimized delivery of these
objects by the surrogate to the end user are outside the scope of
CDNI.
o Digital Rights Management (DRM). DRM is an end-to-end issue
between a content protection system and the User Agent.
o Applications consuming CDNI logs (e.g. charging, analytics,
reporting,...).
o Internal CDN Protocols. i.e. protocols within one CDN.
o Scalability of individual CDNs. While scalability of the CDNI
protocols/approach is in scope, how an individual CDN scales is
out of scope.
o Actual algorithms for selection of CDNs or Surrogates by Request
Routing systems (however, some specific parameters required as
input to these algorithms may be in scope when they need to be
communicated across CDNs).
o Surrogate algorithms. For example caching algorithms and content
acquistion methods are outside the scope of the CDNI work.
Content management (e.g. Content Deletion) as it relates to CDNI
content management policies, is in scope but the internal
algorithms used by a cache to determine when to no longer cache an
item of Content (in the absence of any specific metadata to the
contrary) is out of scope.
o Element management interfaces.
o Commercial, business and legal aspects related to the
interconnections of CDNs.
The third bullet in the list above places the acquisition of content
between interconnected CDNs as out of scope for CDNI and deserves
some additional explanation. The consequence of such a decision is
that a CDNI WG would be focussed on only defining the control plane
for CDNI; and the CDNI data plane (i.e. the acquisition &
distribution of the actual content objects) would not be addressed by
a CDNI WG. The rationale for such a decision is that CDNs today
typically already use standardized protocols such as HTTP, FTP,
rsync, etc. to acquire content from their CSP customers and it is
expected that the same protocols could be used for acquisition
between interconnected CDNs. Therefore the problem of content
acquisition is considered already solved and all that is required
from a CDNI WG is describing within the CDNI Metadata where to go and
which protocol to use to retrieve the content.
4. Design Approach for Realizing the CDNI APIs
This section expands on how CDNI APIs can reuse and leverage existing
protocols. First the "reuse instead of reinvent" design principle is
restated, then each API is discussed individually with example
candidate protocols that can be considered for reuse or leverage.
This discussion is not intended to pre-empt any WG decision as to the
most appropriate protocols, technologies and solutions to select to
solve CDNI but is intended as an illustration of the fact that these
APIs need not be created in a vacuum and that reuse or leverage of
existing protocols is likely possible.
4.1. Relationship to the OSI network model
The four CDNI APIs (CDNI Control API, CDNI Request Routing API, CDNI
Metadata API, CDNI Logging API) described in Section 3.1 within the
CDNI problem area are all control plane interfaces operating at the
application layer (Layer 7 in the OSI network model). Since it is
not expected that these APIs would exhibit unique session, transport
or network requirements as compared to the many other existing
applications in the Internet, it is expected that the CDNI APIs will
be defined on top of existing session, transport and network
protocols.
4.2. "Reuse Instead of Reinvent" Principle
Although a new application protocol could be designed specifically
for CDNI we assume that this is unnecessary and it is recommended
that existing application protocols be reused or leveraged (HTTP
[RFC2616], Atom Publishing Protocol [RFC5023], XMPP [RFC3920], for
example) to realize the CDNI APIs.
4.3. CDNI Request Routing API
The CDNI Request Routing API enables a Request Routing function in an
upstream CDN to query a Request Routing function in a downstream CDN
to determine if the downstream CDN is able (and willing) to accept
the delegated content request and to allow the downstream CDN to
control what the upstream Request Routing function should return to
the User Agent in the redirection message.
The CDNI Request Routing API needs to offer a mechanism for an
upstream CDN to issue a "Redirection Request" to a downstream CDN.
The Request Routing API needs to be able to support scenarios where
the initial User Agent request to the upstream CDN is received over
DNS as well as over a content specific application protocol (e.g.
HTTP, RTSP, RTMP, etc.).
Therefore a Redirection Request needs to contain information such as:
o The protocol (e.g. DNS, HTTP) over which the upstream CDN
received the initial User Agent request
o Additional details of the User Agent request that are required to
perform effective Request Routing by the Downstream CDN. For DNS
this would typically be the IP address of the DNS resolver making
the request on behalf of the User Agent. For requests received
over content specific application protocols the Redirection
Request could contain significantly more information related to
the original User Agent request but at a minimum would need to
contain the User Agent's IP address, the equivalent of the HTTP
Host header and the equivalent of the HTTP abs_path defined in
[RFC2616].
It should be noted that, the CDNI architecture needs to consider that
a downstream CDN may receive requests from User Agents without first
receiving a Redirection Request from an upstream CDN, for example
because:
o User Agents (or DNS resolvers) may cache DNS or application
responses from Request Routers.
o Responses to Redirection Requests over the Request Routing API may
be cacheable.
o Some CDNs may want broader policies, e.g. CDN B agrees to always
take CDN A's delegated redirection requests, in which case the
necessary redirection details are exchanged out of band (of the
CDNI protocols), e.g. configured.
On receiving a Redirection Request, the downstream CDN will use the
information provided in the request to determine if it is able (and
willing) to accept the delegated content request and needs to return
the result of its decision to the upstream CDN.
Thus, a Redirection Response from the downstream CDN needs to contain
information such as:
o Status code indicating acceptance or rejection (possibly with
accompanying reasons).
o Information to allow redirection by the Upstream CDN. In the case
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
should return to the requesting DNS resolver. In the case of
application based request routing, this is expected to include the
application specific redirection response(s) to return to the
requesting User Agent. For HTTP requests from User Agents this
could be in the form of a URI that the upstream CDN could return
in a HTTP 302 response.
The CDNI Request Routing API is therefore a fairly straightforward
request/response protocol and could be implemented over any number of
request/response protocols. For example, it may be implemented as a
WebService using one of the common WebServices methodologies (XML-
RPC, HTTP query to a known URI, etc.). This removes the need for a
CDNI WG to define a new protocol for the request/response element of
the Request Routing API. Thus, a CDNI WG would be left only with the
task of specifying:
o The recommended request/response protocol to use along with any
additional semantics and procedures that are specific to the CDNI
Request Routing API (e.g. handling of malformed requests/
responses).
o The syntax (i.e representation/encoding) of the redirection
requests and responses.
o The semantics (i.e. meaning and expected contents) of the
redirection requests and responses.
4.4. CDNI Metadata API
The CDNI Metadata API enables the Metadata function in a downstream
CDN to obtain CDNI Metadata from an upstream CDN so that the
downstream CDN can properly process and respond to:
o Redirection Requests received over the CDNI Request Routing API.
o Content Requests received directly from User Agents.
The CDNI Metadata API needs to offer a mechanism for an Upstream CDN
to:
o distribute/update/remove CDNI Metadata to a Downstream CDN
and/or to allow a downstream CDN to:
o Make direct requests for CDNI Metadata records where the
downstream CDN knows the identity of the Metadata record(s) it
requires.
o Search for CDNI Metadata records where the downstream CDN does not
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 API is therefore similar to the CDNI Request
Routing API because it is a request/response protocol with the
potential addition that CDNI Metadata search may have more complex
semantics than a straightforward Request Routing redirection request.
Therefore, like the CDNI Request Routing API, the CDNI Metadata API
may be implemented as a WebService using one of the common
WebServices methodologies (XML-RPC, HTTP query to a known URI, etc.)
or possibly using other existing protocols such as XMPP [RFC3920].
This removes the need for a CDNI WG to define a new protocol for the
request/response element of the Metadata API.
Thus, a CDNI WG would be left only with the task of specifying:
o The recommended request/response protocol to use along with any
additional semantics that are specific to the CDNI Metadata API
(e.g. handling of malformed requests/responses).
o The syntax (i.e representation/encoding) of the CDNI Metadata
records that will be exchanged over the API.
o The semantics (i.e. meaning and expected contents) of the
individual properties of a Metadata record.
o How the relationships between different CDNI Metadata records are
represented.
4.5. CDNI Logging API
The CDNI Logging API enables details of logs or events to be
exchanged between interconnected CDNs, where events could be:
o Log lines related to the delivery of content (similar to the log
lines recorded in a web server's access log).
o Real-time or near-real time events before, during or after content
delivery, e.g. content Start/Pause/Stop events, etc.
o Operations and diagnostic messages.
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
by the CDN Operator and its customers. Specifically CDNs use logs to
generate Call Data Records (CDRs) for passing to billing and payment
systems and to real-time (and near real-time) analytics systems.
Such use cases place requirements on the CDNI Logging API to support
guaranteed and timely delivery of log messages between interconnected
CDNs. It may also be necessary to be able to prove the integrity of
received log messages.
Several protocols already exist that could potentially be used to
exchange CDNI logs between interconnected CDNs including SNMP Traps,
syslog, ftp, HTTP POST, etc. although it is likely that some of the
candidate protocols may not be well suited to meet all the
requirements of CDNI. For example SNMP traps pose scalability
concerns and SNMP does not support guaranteed delivery of Traps and
therefore could result in log records being lost and the consequent
CDRs and billing records for that content delivery not being produced
as well as that content delivery being invisible to any analytics
platforms.
Although it is not necessary to define a new protocol for exchanging
logs across the CDNI Logging API, a CDNI WG would still need to
specify:
o The recommended protocol to use.
o A default set of log fields and their syntax & semantics. Today
there is no standard set of common log fields across different
content delivery protocols and in some cases there is not even a
standard set of log field names and values for different
implementations of the same delivery protocol.
o A default set of events that trigger logs to be generated.
4.6. CDNI Control API
The CDNI Control API allows the "CDNI Control" system in
interconnected CDNs to communicate. The exact inter-CDN control
functionality required to be supported by the CDNI Control API is
less well defined than the other three CDNI interfaces at this time.
However, as discussed in Section 3.1, the CDNI Control API may be
required to support functionality similar to the following:
o Allow an upstream CDN and downstream CDN to establish, update or
terminate their CDNI interconnection.
o Allow bootstrapping of the other CDNI APIs (e.g. API address
discovery and establishment of security associations).
o Allow configuration of the other CDNI APIs (e.g. Upstream CDN
specifies information to be reported through the CDNI Logging
API).
o Allow the downstream CDN to communicate information about its
delivery capabilities, resources and policies.
o Allow bootstrapping of the interface between CDNs for content
acquisition (even if that interface itself is outside the scope of
the CDNI work).
It is expected that for the Control API also, existing protocols can
be reused or leveraged. Those will be considered once the
requirements for the Control API have been refined.
5. Prioritizing the CDNI Work
In order to manage the potential workload of a CDNI WG, it is
recommended that the work be prioritized in a "walk before you run"
approach.
The CDNI problem area can be categorized into different solution
scopes as follows:
o "Base CDNI" Scope: This solution scope comprises the solution
elements that can be considered as the 'minimum' needed to
actually deliver any content using interconnected CDNs. For
example, a base CDNI Request Routing API and a base CDNI Metadata
API belong to this scope because without them the upstream CDN is
unable to redirect User Agents to the downstream CDN and the
downstream CDN is unable to obtain the delivery policies and other
CDNI Metadata required to ingest and deliver the content.
o "Operationalized CDNI" Scope: This solution scope comprises the
solution elements that can be considered as the 'minimum' needed
to 'operationalize' CDN Interconnects. For example, the CDNI
Logging API and the base capabilities of the CDNI Control API
(e.g. content file/metadata deletion) belong to this scope because
without them CDN operators are required to substitute for them
either with manual processes or proprietary interfaces.
o "Enhanced CDNI" Scope: This solution scope comprises the solution
elements that can be classed as 'enhanced features'. For example,
the aspects of the CDNI Control API related to automatic
bootstrapping and configuration belong to this scope.
It is proposed that these solution scopes be addressed primarily
sequentially by a CDNI WG and that the initial charter be centered
around the "Base CDNI" scope. However there is obvious benefit from
having a solution for the "Base CDNI" scope that is amenable to
extension for support of the "Operational" scope and "Enhanced"
scope. Therefore it is proposed that the initial CDNI WG charter
also includes definition of (at least) the main requirements for the
"Operationalized CDNI" scope and "Enhanced CDNI" Scope, so those can
be kept in mind when defining the solution for the "Base CDNI" scope.
6. Gap Analysis of relevant Standardization and Research Activities
There are a number of other standards bodies and industry forums that
are working in areas related to CDN, and in some cases related to
CDNI. This section will first outline the key standardization
organizations undertaking related work, some related research
projects, and will then outline any potential overlap with the
proposed CDNI WG and any component that could potentially be reused
by CDNI .
6.1. Related standardization activities
6.1.1. IETF CDI Working Group (Concluded)
The Content Distribution Internetworking (CDI) Working Group was The Content Distribution Internetworking (CDI) Working Group was
formed in the IETF following a BoF in December 2000 and closed in mid formed in the IETF following a BoF in December 2000 and closed in mid
2003. 2003.
For convenience, here is an extract from the CDI WG charter For convenience, here is an extract from the CDI WG charter
[CDI-Charter]: [CDI-Charter]:
" "
skipping to change at page 8, line 34 skipping to change at page 21, line 37
Thus, the CDI WG touched on the same problem space as the present Thus, the CDI WG touched on the same problem space as the present
document. document.
The CDI WG published 3 Informational RFCs: The CDI WG 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".
Although the market, design and requirements placed on CDNs has 6.1.2. 3GPP
changed since 2003, the RFCs above provide a reasonable starting
point and framework for discussing CDN Interconnect.
However, in accordance with its initial charter, the CDI WG did not 3GPP has specified a Progressive Download and Dynamic Adaptive
define any protocols or interfaces to actually enable CDN Streaming over HTTP [3GPP-DASH] based on a Media Presentation
Interconnection and at that time (2003) there was not enough industry Description (MPD) and Media Segmentation Format. The 3GPP DASH work
interest and real life requirements to justify rechartering the WG to is focussed on the information required by a User Agent to obtain and
conduct the corresponding protocol work. present (e.g. play) content to an end user. Such content could be
obtained from a CDN but that is independent of the DASH
specifications. 3GPP DASH could be a candidate for content
acquisition between CDNs in a CDN Interconnect environment.
3.2. IRTF P2P Research Group 6.1.3. ATIS IIF
Some information on CDN interconnection motivations and technical ATIS ([ATIS]) IIF is the IPTV Interoperability Forum (within ATIS)
issues were presented in the P2P RG at IETF 77. The presentation can that develops requirements, standards, and specifications for IPTV.
be found in [P2PRG-CDNI].
3.3. ETSI ATIS IIF is developing the "IPTV Content on Demand (CoD) Service"
specification. This includes use of a CDN (referred to in ATIS IIF
CoD as the "Content Distribution and Delivery Functions") for support
of a Content on Demand (CoD) Service as part of a broader IPTV
service. However, this only covers the case of a managed IPTV
service (in particular where the CDN is administered by the service
provider) and does not cover the use, or interconnection, of multiple
CDNs.
ETSI is the European Telecommunications Standards Institute. ETSI 6.1.4. Cable Labs
produces standards for Information and Communications Technologies
(ICT), including fixed, mobile, radio, converged, broadcast and
internet technologies.
3.3.1. TISPAN "Founded in 1988 by cable operating companies, Cable Television
Laboratories, Inc. (CableLabs) is a non-profit research and
development consortium that is dedicated to pursuing new cable
telecommunications technologies and to helping its cable operator
members integrate those technical advancements into their business
objectives." [CableLabs]
TISPAN (Telecommunications and Internet converged Services and Cable Labs has defined specifications for CoD Content Metadata as
Protocols for Advanced Networking) is an ETSI technical committee part of its VOD Metadata project.
creating Next Generation Networks (NGN) specifications.
TISPAN has published two IPTV specifications, one of which is based 6.1.5. ETSI MCD
on IMS. An extension of these specifications is being designed with
a CDN architecture supporting VoD for delivery to TISPAN devices ETSI MCD (Media Content Distribution) is the ETSI technical committee
"in charge of guiding and coordinating standardization work aiming at
the successful overall development of multimedia systems (television
and communication) responding to the present and future market
requests on media content distribution".
MCD created a specific work item on interconnection of heterogeneous
CDNs ("CDN Interconnection, use cases and requirements") in March
2010. MCD very recently created a working group to progress this
work item. However, no protocol level work has yet started in MCD
for CDN Interconnect.
6.1.6. ETSI TISPAN
ETSI TISPAN has published two sets of IPTV specifications, one of
which is based on IMS. In addition, TISPAN is about to complete the
specifications of a CDN architecture supporting delivery of various
content services such as time-shifted TV and VoD to TISPAN devices
(UEs) or regular PCs. The use cases allow for hierarchically and (UEs) or regular PCs. The use cases allow for hierarchically and
geographically distributed CDN scenarios, along with multi-CDN geographically distributed CDN scenarios, along with multi-CDN
cooperation. As a result, the architecture contains reference points cooperation. As a result, the architecture contains reference points
to support interconnection of other TISPAN CDNs. There is no intent to support interconnection of other TISPAN CDNs. The protocol
to support heterogeneous interconnection at this point. Also, this definition phase for the corresponding CDN architecture was kicked-
effort is focusing on managed IPTV services. off at the end of 2010.
The protocols phase has not yet started, and thus no protocols have 6.1.7. ITU-T
yet been defined.
3.3.2. MCD SG13 is developing standards related to the support of IPTV services
(i.e.. multimedia services such as television/VoD/audio/text/
graphics/data delivered over IP-based managed networks).
MCD (Media Content Distribution) is the ETSI technical committee "in ITU-T Recommendation Y.1910 [Y.1910] provides the description of the
charge of guiding and coordinating standardization work aiming at the IPTV functional architecture. This architecture includes functions
successful overall development of multimedia systems (television and and interfaces for the distribution and delivery of content. This
communication) responding to the present and future market requests architecture is aligned with the ATIS IIF architecture.
on media content distribution".
MCD created a specific work item on interconnection of heterogeneous Based upon ITU-T Rec. Y.1910, ITU-T Rec. Y.2019 [Y.2019] describes in
CDNs ("CDN Interconnection, use cases and requirements") in March more detail the content delivery functional architecture. This
2010. However, no protocol level work has yet started in MCD for CDN architecture allows CDN Interconnection: some interfaces (such as D3,
Interconnect. D4) at the control level allow relationships between different CDNs,
in the same domain or in different domains. Generic procedures are
described, but the choice of the protocols is open.
3.4. ATIS IIF 6.1.8. Open IPTV Forum (OIPF)
ATIS ([ATIS]) is the Alliance for Telecommunications Industry The Open IPTV Forum has developed an end-to-end solution to allow any
Solutions. OIPF terminal to access enriched and personalized IPTV services
either in a managed or a non-managed network[OIPF-Overview]. Some
OIPF services (such as Network PVR) may be hosted in a CDN.
IIF is the IPTV Interoperability Forum (within ATIS) that develops To that end, the Open IPTV Forum specification is made of 5 parts:
requirements, standards, and specifications for IPTV.
The IIF is developing the "IPTV Content on Demand (CoD) Service" o Media Formats including HTTP Adaptive Streaming
specification. This includes use of a CDN (referred to in ATIS IIF o Content Metadata
CoD as the "Content Distribution and Delivery Functions") for support o Protocols
of a Content on Demand (CoD) Service as part of a broader IPTV o Terminal (Declarative or Procedural Application Environment)
service. However, this only covers the case of a managed IPTV o Authentication, Content Protection and Service Protection
service (in particular where the CDN is administered by the IPTV
service provider) and does not cover the use, or interconnection, of
multiple CDNs.
The "IPTV Content on Demand (CoD) Service" specification defines a 6.1.9. TV-Anytime Forum
reference point (C2) and the corresponding HTTP-based data plane
protocol for content acquisition between an authoritative origin
server and the CDN. While this protocol has not been explicitly
specified for content acquisition across CDNs, it could be a
candidate (in addition to others such as standard HTTP) for content
acquisition between CDNs in a CDN Interconnect environment.
3.5. Open IPTV Forum (OIPF) Version 1 of the TV-Anytime Forum specifications were published as
ETSI TS 102 822-1 through ETSI TS 102 822-7 "Broadcast and On-line
Services: Search, select, and rightful use of content on personal
storage systems ("TV-Anytime")". It includes the specification of
content metadata in XML schemas (ETSI TS 102 822-3) which define
technical parameters for the description of CoD and Live contents.
The specification is referenced by DVB and OIPF.
"The Open IPTV Forum has developed an end-to-end solution to allow The TV-anytime Forum was closed in 2005.
any consumer end-device, compliant to the Open IPTV Forum
specifications, to access enriched and personalised IPTV services
either in a managed or a non-managed network. To that end, the Open
IPTV Forum focuses on standardising the user-to-network interface
(UNI) both for a managed and a non-managed network" [OIPF-Overview].
OIPF has defined specifications for Content Metadata, however they 6.1.10. SNIA
specify a definition for IPTV service related metadata and do not
include a metadata definition or interface that could be used between
CDNs.
3.6. ITU-T The Storage Networking Industry Association (SNIA) is an association
of producers and consumers of storage networking products whose goal
is to further storage networking technology and applications.
Text to be added in a future version of this document. SNIA has published the Cloud Data Management Interface (CDMI)
standard ([SNIA-CDMI]).
3.7. OCEAN "The Cloud Data Management Interface defines the functional interface
that applications will use to create, retrieve, update and delete
data elements from the Cloud. As part of this interface the client
will be able to discover the capabilities of the cloud storage
offering and use this interface to manage containers and the data
that is placed in them. In addition, metadata can be set on
containers and their contained data elements through this interface."
6.2. Related Research Projects
6.2.1. IRTF P2P Research Group
Some information on CDN interconnection motivations and technical
issues were presented in the P2P RG at IETF 77. The presentation can
be found in [P2PRG-CDNI].
6.2.2. OCEAN
OCEAN (http://www.ict-ocean.eu/) is an EU funded research project OCEAN (http://www.ict-ocean.eu/) is an EU funded research project
that started in February 2010. Some of its objectives are relevant that started in February 2010 for 3 years. Some of its objectives
to CDNI, for example "design a new content delivery framework" and are relevant to CDNI. It aims, among other things, at designing a
"foster multi-vendor solutions", however others are much more new architectural framework for audiovisual content delivery over the
implementation orientated, e.g. "self-learning caching algorithms" Internet, defining public interfaces between its major building
and "media-aware congestion control mechanisms". blocks in order to foster multi-vendor solutions and interconnection
between Content Networks (the term "Content Networks" corresponds
here to the definition introduced in [IETF RFC3466], which
encompasses CDNs).
OCEAN has not yet defined any protocols for CDN Interconnection. OCEAN has not yet published any open specifications, nor common best
practices, defining how to achieve such CDN interconnection.
3.8. CableLabs VoD Metadata 6.2.3. Eurescom P1955
"Founded in 1988 by cable operating companies, Cable Television Eurescom P1955 was a 2010 research project involving a four European
Laboratories, Inc. (CableLabs) is a non-profit research and Network operators, which studied the interests and feasibility of
development consortium that is dedicated to pursuing new cable interconnecting CDNs by firstly elaborating the main service models
telecommunications technologies and to helping its cable operator around CDN interconnection, as well as analyzing an adequate CDN
members integrate those technical advancements into their business interconnection technical architecture and framework, and finally by
objectives." [CableLabs] providing recommendations for telcos to implement CDN
interconnection. The Eurescom P1955 project ended in July 2010.
Cable Labs has defined specifications for CoD Content Metadata as The authors are not aware of material discussing CDN interconnection
part of its VOD Metadata project. "The VOD Metadata project is a protocols made publically available as a deliverable of this project.
cable television industry and cross-industry-wide effort to specify
the metadata and interfaces for distribution of video-on-demand (VOD)
material from multiple content providers to cable operators."
[CableLabs-Metadata]
However, while the CableLabs work specifies an interface between a 6.3. Gap Analysis
content provider and a service provider running a CDN, it does not
include an interface that could be used between CDNs.
4. CDN Interconnect Problem Area for IETF A number of standards bodies have produced specifications related to
CDNs, namely:
Interconnecting CDNs involves many different functions and components o TISPAN has a dedicated specification for CDN.
being integrated to some degree. Only some of those require o OIPF and ATIS specify the architecture and the protocols of an
standardization. Out of those, only some fit within the expertise IPTV solution. Although OIPF and ATIS specifications include the
and charter of the IETF. The problem area proposed for IETF work is interaction with a CDN, the CDN specifications are coupled with
illustrated in Figure 1. The candidate goals (and respectively the their IPTV specifications.
non-goals) for IETF work on CDN Interconnection are discussed in o <TODO: Add a sentence on ITU>
Section 4.1 (and respectively Section 4.2 ). o IETF CDN WG (now concluded) touched on the same problem space as
the present document. However, in accordance with its initial
charter, the CDI WG 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 WG to conduct the corresponding protocol
work.
-------- Although some of the specifications describe multi-CDN cooperation or
/ \ include reference points for interconnecting CDNs, none of them
| CSP | specify in sufficient detail all the CDNI protocols/APIs and CDNI
\ / Metadata representations required to enable even a base level of CDN
-------- Interconnect functionality to be implemented.
*
*
* /\
* / \
--------------------- |CDNI| ---------------------
/ Upstream CDN \ | | / Downstream CDN \
| +-------------+ | Control API | +-------------+ |
| |CDNI Control |<======|====|=======>| CDNI Control| |
| +------*-*-*--+ | | | | +-*-*-*-------+ |
| * * * | | | | * * * |
| +------*------+ | Logging API | +-----*-------+ |
| ****| Logging |<======|====|=======>| Logging |**** |
| * --------------+ | | | | +-------------+ * |
| * * * | | | | * * * |
| * +--------*----+ | Req-Routing API | +---*---------+ * |
| * **|Req-Routing |<======|====|=======>| Req-Routing |** * |
| * * +-------------+ | | | | +-------------+ * * |
| * * * | | | | * * * |
| * * +----------*--+ | CD Metadata API | +-*-----------+ * * |
| * * |Distribution |<======|====|=======>| Distribution| * * |
| * * | | | \ / | | | * * |
| * * | | | \/ | | | * * |
| * ****+---------+ | | | | +---------+**** * |
| ******|Surrogate|*************************|Surrogate|****** |
| | +---------+ | | Acquisition | | +-----*---+ | |
| +-------------+ | | +-------*-----+ |
\ / \ * /
--------------------- ---------*-----------
*
*
+------+
| user |
+------+
<==> interfaces inside the scope of CDNI The following sections will summarize the existing work described in
Section 6.1 against the CDNI problem space.
**** interfaces outside the scope of CDNI 6.3.1. Content Acquisition across CDNs and Delivery to End User (Data
plane)
Figure 1: CDNI Problem Area 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
on the delivery interface between the surrogate and the User Agent.
Some of this work is summarized below.
4.1. Candidate CDNI Goals for IETF TISPAN, OIPF and ATIS have specified IPTV and/or CoD services,
including the data plane aspects (typically different flavors of RTP/
RTCP and HTTP) to obtain content and deliver it to User Agents. For
example, :
o The OIPF data plane includes both RTP and HTTP flavors (HTTP
progressive download, HTTP Adaptive streaming [3GPP-DASH],...).
Listed below are parts of the problem space that are proposed to be o ATIS specification "IPTV Content on Demand (CoD) Service" [REF]
addressed by a potential CDNI working group in the IETF: defines a reference point (C2) and the corresponding HTTP-based
o Specification of a control plane architecture for CDN data plane protocol for content acquisition between an
Interconnect. authoritative origin server and the CDN.
o Specification of the APIs and protocols required to Interconnect a While these protocols have not been explicitly specified for content
pair of CDNs (where a given CDN may support multiple interconnects acquisition across CDNs, they are suitable (in addition to others
with different CDNs). This is expected to comprise (but possibly such as standard HTTP) for content acquisition between CDNs in a CDN
grouped in a different manner): Interconnect environment. Therefore for the purpose of a CDNI WG
* CDNI Control API: This API allows the "CDNI Control" system in there are already multiple existing data plane protocols that can be
interconnected CDNs to communicate. This API may support the used for content acquisition across CDNs.
following:
+ allows an upstream CDN and downstream CDN to establish,
update or terminate their CDNI relationship
+ allows bootstrapping of the other CDNI APIs (e.g. API
address discovery and establishment of security
associations)
+ allows configuration of the other CDNI APIs (e.g. Upstream
CDN specifies information to be reported through the Logging
API)
+ allows the downstream CDN to communicate information about
its delivery capabilities, resources and policies
+ allows bootstrapping of the interface between CDNs for
content acquisition (even if that interface itself is
outside the scope of the CDNI work)
* Request-Routing API: This API allows the Request-Routing system
in interconnected CDNs to communicate to ensure that an end-
user request can be (re)directed from an upstream CDN to a
surrogate in the downstream CDN, in particular where selection
responsibilities may be split across CDNs (for example the
upstream CDN may be responsible for selecting the downstream
CDN while the downstream CDN may be responsible for selecting
the actual surrogate within that CDN).
* Content Distribution Metadata Signaling API: This API allows
the Distribution system in interconnected CDNs to communicate
to ensure content distribution metadata can be exchanged across
CDNs. For example, the distribution metadata information may
include information about desired distribution policy (e.g.
prepositioning vs dynamic acquisition) and about content access
policy (e.g. allowed/blocked time/geography, authorization
checks to be performed at delivery time). It may also contain
information about where/how to acquire the content. This may
also include content management (e.g. deletion of Content from
caches) across interconnected CDNs. It is expected that the
specification of this API will comprise (i) specification of a
schema for Content Distribution Metadata as well as (ii)
specification/selection of a signaling protocol (quite possibly
an existing IETF protocol) to signal the actual Content
Distribution Metadata encoded as per the schema.
* Logging API: This API allows the Logging system in
interconnected CDNs to communicate the relevant activity logs
in order to allow log consuming applications to operate in a
multi-CDN environments. For example, an upstream CDN may
collect delivery logs from a downstream CDN in order to perform
consolidated charging of the CSP. Similarly, an upstream CDN
may collect delivery logs from a downstream CDN in order to
provide consolidated reporting and monitoring to the CSP.
o Scalability of the CDNI protocols & approach.
4.2. Non-Goals for IETF Similarly, there are multiple existing standards (e.g. OIPTF data
plane mentioned above, HTTP adaptive streaming [3GPP-DASH]) or public
specifications (e.g. vendor specific HTTP Adaptive streaming
specification) so that content delivery is considered already solved
(or at least sufficiently addressed in other forums).
Listed below are aspects of content delivery that the authors propose Thus, specificatio of the content acquisition interface between CDNs
be kept outside of the scope of a potential CDNI working group: and the delivery interface between the surrogate and the User Agent
o The interface between Content Service Provider and the are out of scope for CDNI. CDNI may only concern itself with the
Authoritative CDN (i.e. the upstream CDN contracted by the CSP for negotiation/selection aspects of the acquisition protocol to be used
delivery by this CDN or by its downstream CDNs). in a CDN interonnect scenario.
o The delivery interface between the delivering CDN surrogate and
the enduser, such as streaming protocols.
o The content acquisition interface between CDNs (i.e. the dataplane
interface for actual delivery of a piece of content from one CDN
to the other). This is expected to use existing protocols such as
HTTP or protocols defined in other forums for content acquisition
between an origin server and a CDN (e.g. HTTP-based C2 reference
point of ATIS IIF CoD).
o User Authentication. User authentication and authorization are
the responsibility of the Content Service Provider.
o Content preparation, including encoding and transcoding. The CDNI
architecture aims at allowing distribution across interconnected
CDNs of content treated as opaque objects. Interpretation and
processing of the objects, as well as optimised delivery of these
objects by the surrogate to the enduser are outside the scope of
CDNI.
o Digital Right Management (DRM). DRM is an end-to-end issue
between Origin and User-Agent.
o applications consuming CDNI logs (e.g. charging, analytics,
reporting,...)
o Internal CDN Protocols. i.e. protocols within one CDN.
o Scalability of individual CDNs. While scalability of the CDNI
protocols/approach is in scope, how an individual CDN scales is
out of scope.
o actual criteria and algorithms for selection of CDN or Surrogate
by Request-Routing systems.
o Surrogate algorithms - e.g. how to acquire content or cache
replacement algorithms. Content management (e.g. Content
Deletion) is in scope but the internal algorithms used by a cache
to determine when to no longer cache an item of Content (in the
absence of any specific metadata to the contrary) is out of scope.
o Element management interfaces
o commercial, business and legal aspects related to the
interconnections of CDNs.
5. Relationship to relevant IETF Working Group 6.3.2. CDNI Metadata
5.1. ALTO Cable Labs, ITU, OIPF and TV-Anytime have work items dedicated to the
specification of content metadata:
o Cable Labs has defined specifications for CoD Content Metadata as
part of its VOD Metadata project. "The VOD Metadata project is a
cable television industry and cross-industry-wide effort to
specify the metadata and interfaces for distribution of video-on-
demand (VOD) material from multiple content providers to cable
operators." [CableLabs-Metadata]. However, while the CableLabs
work specifies an interface between a content provider and a
service provider running a CDN, it does not include an interface
that could be used between CDNs.
o ITU Study Group 16 has started work on a number of draft
Recommendations (H.IPTV-CPMD, H.IPTV-CPMD, HSTP.IPTV-CMA,
HSTP.IPTV-UMCI) specifying metadata for content distribution in
IPTV services.
o An Open IPTV Terminal receives the technical description of the
content distribution from the OIPF IPTV platform before receiving
any content. The Content distribution metadata is sent in the
format of a TV-Anytime XSD including tags to describes the
location and program type (on demand or Live) as well as
describing the time availability of the on demand and live
content.
However the specifications outlined above do not include metadata
specific to the distribution of content within a CDN or between
interconnected CDNs, for example geo-blocking information,
availability windows, access control mechanisms to be enforced by the
surrogate, how to map an incoming content request to a file on the
origin server or acquire it from the upstream CDN etc.
The CDMI standard ([SNIA-CDMI]) from SNIA defines metadata that can
be associated with data that is stored by a cloud storage provider.
While the metadata currently defined do not match the need of a CDN
Interconnect solution, it is worth considering CDMI as one of the
existing pieces of work that may potentially be leveraged for the
CDNI Metadata API (e.g by extending the CDMI metadata to address more
specific CDNI needs).
7. Relationship to relevant IETF Working Groups
7.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 WG will consider the needs of
BitTorrent, tracker-less P2P, and other applications, such as content BitTorrent, tracker-less P2P, and other applications, such as content
delivery networks (CDN) and mirror selection." delivery networks (CDN) and mirror selection."
In particular, the ALTO service could be used by a CDN Request In particular, the ALTO service can be used by a CDN Request Routing
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 request. See [I-D.penno-alto-cdn] for a detailed particular User Agent request (or to serve a request from another
discussion on how CDN Request Routing can be used as an integration surrogate). See [I-D.penno-alto-cdn] for a detailed discussion on
point of ALTO into CDNs. It is possible that the ALTO service could how CDN Request Routing can be used as an integration point of ALTO
be used in the same manner in a multi-CDN environment based on CDN into CDNs. It is possible that the ALTO service could be used in the
Interconnect. For example, an upstream CDN may take advantage of the same manner in a multi-CDN environment based on CDN Interconnect.
ALTO service in its decision for selecting a downstream CDN to which For example, an upstream CDN may take advantage of the ALTO service
a user request should be delegated. in its decision for selecting a downstream CDN to which a user
request should be delegated.
However, the work of ALTO is complementary to and does not overlap However, the work of ALTO is complementary to and does not overlap
with the work proposed in this document because the integration with the work proposed in this document because the integration
between ALTO and a CDN would fall under "algorithms for selection of between ALTO and a CDN would fall under "algorithms for selection of
CDN or Surrogate by Request-Routing systems" in Section 4.2 CDN or Surrogate by Request-Routing systems" in Section 3.2 and is
therefore out of scope for a CDNI WG. One area for further study is
whether additional information should be provided by an ALTO service
to facilitate CDNI CDN selection.
6. IANA Considerations 7.2. DECADE
The DECADE Working Group [DECADE-Charter] is addressing the problem
of reducing traffic on the last-mile uplink, as well as backbone and
transit links caused by P2P streaming and file sharing applications.
It addresses the problem by enabling an application endpoint to make
content available from an in-network storage service and by enabling
other application endpoints to retrieve the content from there.
Exchanging data through the in-network storage service in this
manner, instead of through direct communication, provides significant
gain where:
o The network capacity/bandwidth from in-network storage service to
application endpoint significantly exceeds the capacity/bandwidth
from application endpoint to application endpoint (e.g. because of
an end-user uplink bottleneck); and
o Where the content is to be accessed by multiple instances of
application endpoints (e.g. as is typically the case for P2P
applications).
While, as is the case for any other data distribution application,
the DECADE architecture and mechanisms could potentially be used for
exchange of CDNI control plane information via an in-network-storage
service (as opposed to directly between the entities terminating the
CDNI APIs in the neighbor CDNs), we observe that:
o CDNI would operate as a "Content Distribution Application" from
the DECADE viewpoint (i.e. would operate on top of DECADE).
o There does not seem to be obvious benefits in integrating the
DECADE control plane responsible for signaling information
relating to control of the in-network storage service itself, and
the CDNI control plane responsible for application-specific CDNI
interactions (such as exchange of CDNI metadata, CDNI request
redirection, transfer of CDNI logging information).
o There would typically be limited benefits in making use of a
DECADE in-network storage service because the CDNI APIs are
expected to be terminated by a very small number of CDNI clients
(if not one) in each CDN, and the CDNI clients are expected to
benefit from high bandwidth/capacity when communicating directly
to each other (at least as high as if they were communicating via
an in-network storage server).
The DECADE in-network storage architecture and mechanisms may
theoretically be used for the acquisition of the content objects
themselves between interconnected CDNs. It is not expected that this
would have obvious benefits in typical situations where a content
object is acquired only once from an Upstream CDN to a Downstream CDN
(and then distributed as needed inside the Downstream CDN). But it
might have benefits in some particular situations. Since the
acquisition API between CDNs is outside the scope of the CDNI work,
this question is left for further study.
The DECADE in-network storage architecture and mechanisms may
potentially also be used within a given CDN for the distribution of
the content objects themselves among surrogates of that CDN. Since
the CDNI work does not concern itself with operation within a CDN,
this question is left for further study.
Therefore, the work of DECADE may be complementary to but does not
overlap with the CDNI work proposed in this document.
7.3. PPSP
As stated in the PPSP Working Group charter [PPSP-Charter]:
"The Peer-to-Peer Streaming Protocol (PPSP) working group develops
two signaling and control protocols for a peer-to-peer (P2P)
streaming system for transmitting live and time-shifted media content
with near real-time delivery requirements." and "The PPSP WG designs
a protocol for signaling and control between trackers and peers (the
PPSP "tracker protocol") and a signaling and control protocol for
communication among the peers (the PPSP "peer protocol"). The two
protocols enable peers to receive streaming data within the time
constraints required by specific content items."
Therefore PPSP is concerned with the distribution of the streamed
content itself along with the necessary signaling and control
required to distribute the content. As such, it could potentially be
used for the acquisition of streamed content across interconnected
CDNs. But since the acquisition API is outside the scope of the work
proposed for CDNI, we leave this for further study. Also, because of
its streaming nature, PPSP is not seen as applicable to the
distribution and control of the CDNI control plane and CDNI data
representations.
Therefore, the work of PPSP may be complementary to but does not
overlap with the work proposed in this document for CDNI.
8. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an Note to RFC Editor: this section may be removed on publication as an
RFC. RFC.
7. Security Considerations 9. Security Considerations
This document describes a problem faced by CDN Providers and does not Distribution of content by a CDN comes with a range of security
itself introduce any new security considerations. considerations such as how to enforce control of access to the
content by users in line with the CSP policy. These security aspects
are already dealt with by CDN Providers and CSPs today in the context
of standalone CDNs. However, interconnection of CDNs introduces a
new set of security considerations by extending the trust model (i.e.
the CSP "trusts" a CDN that "trusts" another CDN).
However, maintaining the security of the content itself, its Maintaining the security of the content itself, its associated
associated metadata (including distribution and delivery policies) metadata (including distribution and delivery policies) and the CDNs
and the CDNs distributing and delivering it are critical requirements distributing and delivering it, are critical requirements for both
for both CDN Providers and their customers and any work on CDN CDN Providers and CSPs and any work on CDN Interconnection must
Interconnection must provide sufficient mechanisms to maintain the provide sufficient mechanisms to maintain the security of the overall
security of the overall system of interconnected CDNs as well as the system of interconnected CDNs as well as the information (content,
information (content, metadata, logs, etc) distributed and delivered metadata, logs, etc) distributed and delivered through any CDN
through any CDN Interconnects. Interconnects.
8. Acknowledgements 10. Acknowledgements
The authors would like to thank David Ferguson, Julien Maisonneuve, The authors would like to thank Andre Beck, Mark Carlson, Bruce
Mahesh Viveganandhan and Bruce Davie for their early review comments Davie, David Ferguson, Yiu Lee, Julien Maisonneuve, Emile Stephan and
and contributions to the text. Mahesh Viveganandhan for their review comments and contributions to
the text.
9. References 11. References
9.1. Normative References 11.1. Normative References
[I-D.bertrand-cdni-use-cases]
Bertrand, G. and E. Stephan, "Use Cases for Content
Distribution Network Interconnection",
draft-bertrand-cdni-use-cases-00 (work in progress),
January 2011.
[I-D.watson-cdni-use-cases]
Watson, G., "CDN Interconnect Use Cases",
draft-watson-cdni-use-cases-00 (work in progress),
January 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References 11.2. Informative References
[3GPP-DASH]
""Progressive Download and Dynamic Adaptive Streaming over
HTTP" http://www.3gpp.org/ftp/Specs/html-info/26.234.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/)".
[CDI-Charter] [CDI-Charter]
"IETF CDI WG Charter "IETF CDI WG Charter
(http://www.ietf.org/wg/concluded/cdi)". (http://www.ietf.org/wg/concluded/cdi)".
[CableLabs] [CableLabs]
"CableLabs (http://www.cablelabs.com/about/)". "CableLabs (http://www.cablelabs.com/about/)".
[CableLabs-Metadata] [CableLabs-Metadata]
"CableLabs VoD Metadata Project Primer "CableLabs VoD Metadata Project Primer
(http://www.cablelabs.com/projects/metadata/primer/)". (http://www.cablelabs.com/projects/metadata/primer/)".
[DECADE-Charter]
"IETF DECADE WG Charter
(http://datatracker.ietf.org/wg/decade/charter/)".
[I-D.penno-alto-cdn] [I-D.penno-alto-cdn]
Penno, R., Raghunath, S., Medved, J., Alimi, R., Yang, R., Penno, R., Raghunath, S., Medved, J., Alimi, R., Yang, R.,
and S. Previdi, "ALTO and Content Delivery Networks", and S. Previdi, "ALTO and Content Delivery Networks",
draft-penno-alto-cdn-02 (work in progress), October 2010. draft-penno-alto-cdn-02 (work in progress), October 2010.
[OIPF-Overview] [OIPF-Overview]
"OIPF Release 2 Specification Volume 1 - Overview", "OIPF Release 2 Specification Volume 1 - Overview",
September 2010. September 2010.
[P2PRG-CDNI] [P2PRG-CDNI]
Davie, B. and F. Le Faucheur, "Interconnecting CDNs aka Davie, B. and F. Le Faucheur, "Interconnecting CDNs aka
"Peering Peer-to-Peer" "Peering Peer-to-Peer"
(http://www.ietf.org/proceedings/77/slides/P2PRG-2.pdf)", (http://www.ietf.org/proceedings/77/slides/P2PRG-2.pdf)",
March 2010. March 2010.
[PPSP-Charter]
"IETF PPSP WG Charter
(http://datatracker.ietf.org/wg/ppsp/charter/)".
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web [RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web
Replication and Caching Taxonomy", RFC 3040, January 2001. Replication and Caching Taxonomy", RFC 3040, January 2001.
[RFC3466] Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model [RFC3466] Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model
for Content Internetworking (CDI)", RFC 3466, for Content Internetworking (CDI)", RFC 3466,
February 2003. February 2003.
[RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known [RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known
Content Network (CN) Request-Routing Mechanisms", Content Network (CN) Request-Routing Mechanisms",
RFC 3568, July 2003. RFC 3568, July 2003.
[RFC3570] Rzewski, P., Day, M., and D. Gilletti, "Content [RFC3570] Rzewski, P., Day, M., and D. Gilletti, "Content
Internetworking (CDI) Scenarios", RFC 3570, July 2003. Internetworking (CDI) Scenarios", RFC 3570, July 2003.
[RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 3920, October 2004.
[RFC5023] Gregorio, J. and B. de hOra, "The Atom Publishing
Protocol", RFC 5023, October 2007.
[SNIA-CDMI]
"SNIA CDMI (http://www.snia.org/tech_activities/standards/
curr_standards/cdmi)".
[TAXONOMY] [TAXONOMY]
Pathan, A., "A Taxonomy and Survey of Content Delivery Pathan, A., "A Taxonomy and Survey of Content Delivery
Networks Networks
(http://www.gridbus.org/reports/CDN-Taxonomy.pdf)", 2007. (http://www.gridbus.org/reports/CDN-Taxonomy.pdf)", 2007.
[Y.1910] "ITU-T Recomendation Y.1910 "IPTV functional
architecture"", September 2008.
[Y.2019] "ITU-T Recomendation Y.2019 "Content delivery functional
architecture in NGN"", September 2010.
Authors' Addresses Authors' Addresses
Ben Niven-Jenkins Ben Niven-Jenkins
Velocix (Alcatel-Lucent) Velocix (Alcatel-Lucent)
326 Cambridge Science Park 326 Cambridge Science Park
Milton Road, Cambridge CB4 0WG Milton Road, Cambridge CB4 0WG
UK UK
Email: ben@velocix.com Email: ben@velocix.com
Francois Le Faucheur Francois Le Faucheur
Cisco Systems Cisco Systems
Greenside, 400 Avenue de Roumanille Greenside, 400 Avenue de Roumanille
Sophia Antipolis 06410 Sophia Antipolis 06410
France France
Phone: +33 4 97 23 26 19 Phone: +33 4 97 23 26 19
Email: flefauch@cisco.com Email: flefauch@cisco.com
Nabil Bitar Nabil Bitar
 End of changes. 86 change blocks. 
379 lines changed or deleted 1085 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/