Network Working Group B. Niven-Jenkins
Internet-Draft Velocix (Alcatel-Lucent)
Intended status: Informational F. Le Faucheur
Expires: June 5, 2011 Cisco
N. Bitar
Verizon
December 2, 2010
Content Distribution Network Interconnection (CDNI) Problem Statement
draft-jenkins-cdni-problem-statement-00
Abstract
Content Delivery Networks (CDNs) provide numerous benefits: reduced
delivery cost for cacheable content, improved quality of experience
for end users and increased robustness of delivery. For these
reasons they are frequently used for large-scale content delivery.
As a result, existing CDN providers are scaling up their
infrastructure and many Network Service Providers (NSPs) are
deploying their own CDNs. It is generally desirable that a given
content item can be delivered to an end user regardless of that
user's location or attachment network. This creates a requirement
for interconnecting standalone CDNs so they can interoperate as an
open content delivery infrastructure 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
with a view towards creating a working group. This working group
would work on interoperable and scalable solutions for CDN
interconnection.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Niven-Jenkins, et al. Expires June 5, 2011 [Page 1]
Internet-Draft CDN Interconnection Problem Statement December 2010
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 5, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Niven-Jenkins, et al. Expires June 5, 2011 [Page 2]
Internet-Draft CDN Interconnection Problem Statement December 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. CDN Background . . . . . . . . . . . . . . . . . . . . . . 6
2. CDN Interconnect Use Cases . . . . . . . . . . . . . . . . . . 6
3. Gap Analysis of relevant Standardization Activities . . . . . 7
3.1. IETF Concluded CDI Working Group . . . . . . . . . . . . . 7
3.2. IRTF P2P Research Group . . . . . . . . . . . . . . . . . 8
3.3. ETSI . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3.1. TISPAN . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3.2. MCD . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.4. ATIS IIF . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.5. Open IPTV Forum (OIPF) . . . . . . . . . . . . . . . . . . 10
3.6. ITU-T . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.7. OCEAN . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.8. CableLabs VoD Metadata . . . . . . . . . . . . . . . . . . 11
4. CDN Interconnect Problem Area for IETF . . . . . . . . . . . . 11
4.1. Candidate CDNI Goals for IETF . . . . . . . . . . . . . . 13
4.2. Non-Goals for IETF . . . . . . . . . . . . . . . . . . . . 14
5. Relationship to relevant IETF Working Group . . . . . . . . . 15
5.1. ALTO . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Niven-Jenkins, et al. Expires June 5, 2011 [Page 3]
Internet-Draft CDN Interconnection Problem Statement December 2010
1. Introduction
The volume of video and multimedia content delivered over the
Internet is rapidly increasing and expected to continue doing so in
the future. In the face of this growth, Content Delivery Networks
(CDNs) provide numerous benefits: reduced delivery cost for cacheable
content, improved quality of experience for end users and increased
robustness of delivery. For these reasons CDNs are frequently used
for large-scale content delivery. As a result, existing CDN
providers are scaling up their infrastructure and many Network
Service Providers (NSPs) are deploying their own CDNs. It is
generally desirable that a given content item can be delivered to an
end user regardless of that user's location or attachment network.
This creates a requirement for interconnecting standalone CDNs so
they can interoperate as an open content delivery infrastructure 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
with a view towards creating a working group. This working group
would work on interoperable and scalable solutions for CDN
interconnection.
1.1. Terminology
This document uses the following terms:
Content: Any form of digital data. One important form of Content
with additional constraints on Distribution and Delivery is
continuous media (i.e. where there is a timing relationship between
source and sink).
Metadata: Metadata in general is data about data.
Content Metata: this is metadata about content. It may vary in depth
from merely identifying the content (e.g. title or other information
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
subset of the Metadata pertaining to rules that control how the
content is to be distributed and delivered by CDNs.
User: The 'real' user of the system, typically a human but maybe some
combination of hardware and/or software emulating a human (e.g. for
Niven-Jenkins, et al. Expires June 5, 2011 [Page 4]
Internet-Draft CDN Interconnection Problem Statement December 2010
automated quality monitoring etc.)
Network Service Provider (NSP): Provides network-based connectivity/
services to Users.
Content Service Provider (CSP): Provides a Content Service to Users.
A CSP may own the 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.
The Content Service encompasses the complete service which may be
wider than just the delivery of items of Content, e.g. the Content
Service also includes any middleware, key distribution, program
guide, etc. which may not require any direct interaction with the
CDN.
Content Distribution Network (CDN) / Content Delivery Network (CDN):
A type of network in which the content network elements are arranged
for more effective delivery of content to User Agents. Typically a
CDN consists of a Request Routing system, a Distribution System and a
set of Surrogates.
CDN Provider: The service provider who operates a CDN.
CDN Interconnect (CDNI): The set of interfaces over which two or more
CDNs communicate with each other in order to achieve the delivery of
content to users by surrogates in one CDN (the downstream CDN) on
behalf of another CDN (the upstream CDN).
Over-the-top (OTT): A service, e.g. a CDN, operated over the Internet
rather than by a particular NSP.
Surrogate: A device/function that interacts with other elements of
the CDN for the control and distribution of Content within the CDN
and interacts with User Agents for the delivery of the Content.
Request Routing System: The function within a CDN responsible for
steering or directing a content request received directly from an end
user to a suitable Surrogate.
Distribution System: the function within a CDN responsible for
distributing Content Distribution Metadata as well as content inside
the CDN (e.g. down to the surrogates)
Delivery: the function within CDN surrogates responsible for
delivering a piece of content to the end user. For example, delivery
may be based on HTTP progressive download or HTTP adaptive streaming.
Niven-Jenkins, et al. Expires June 5, 2011 [Page 5]
Internet-Draft CDN Interconnection Problem Statement December 2010
Logging System: the function within a CDN responsible for collecting
measurement and recording of distribution and delivery activities.
The information recorded by the logging system may be used for
various purposes including charging (e.g. of the CSP), analytics and
monitoring.
1.2. CDN Background
Readers are assumed to be familiar with the architecture, features
and operation of CDNs. For readers less familiar with the operation
of CDNs, the following resources may be useful:
o RFC 3040 [RFC3040] describes many of the component technologies
that are used in the construction of a CDN
o Taxonomy [TAXONOMY] compares the architecture of a number of CDNs
o RFC 3466 [RFC3466] and RFC 3570 [RFC3570] are the output of the
IETF Content Delivery Internetworking (CDI) working group which
was closed in 2003.
Note: Some of the terms used in this document are similar to terms
used the above referenced documents. When reading this document
terms should be interpreted as having the definitions provided in
Section 1.1.
2. CDN Interconnect Use Cases
An increasing number of NSPs are deploying CDNs in order to deal
cost-effectively with the growing usage of on-demand video services
and other content delivery applications.
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
multiple end users without transiting multiple times through the
network core (i.e from the content origin to the cache). This
contributes to bandwidth cost reductions for the NSP. CDNs also
enable replication of popular content across many surrogates, which
enables content to be served to large numbers of users 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
content to support the Network Service Provider's own 'walled garden'
services, such as delivery of IPTV services to Set Top Boxes, but are
also used for delivery of content to other devices including PCs,
tablets, mobile phones etc.
Traditional CDNs have operated as over-the-top providers of digital
Niven-Jenkins, et al. Expires June 5, 2011 [Page 6]
Internet-Draft CDN Interconnection Problem Statement December 2010
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
multiple affiliate NSPs. These NSPs typically operate independent
CDNs. As they evolve their services (e.g. for seamless support of
content services to nomadic users across affiliate NSPs) there is a
need for interconnection of these CDNs. However there are no open
specifications, nor common best practices, defining how to achieve
such CDN interconnection.
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
high quality of experience, all without having to maintain direct
business relationships with many different CDN providers. Some 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
particular, this would enable the CSPs to benefit from on-net
delivery (i.e. within the Network Service Provider's own network/CDN
footprint) whenever possible and off-net delivery otherwise without
requiring the CSPs having to maintain direct business relationships
with all the CDNs involved in the delivery. Again, for this
requirement, CDN operators (NSPs or over-the-top) are faced with a
lack of open specifications and best practices.
Finally, NSPs have often deployed CDNs as specialized cost-reduction
projects within the context of a particular service or environment,
some NSPs operate separate CDNs for separate services. For example,
there may be a CDN for managed IPTV service delivery, a CDN for
web-TV delivery and a CDN for video delivery to Mobile terminals. As
NSPs integrate their service portfolio, there is a need for
interconnecting these CDNs. Again, NSPs face the problem of lack of
open interfaces for CDN interconnection.
3. Gap Analysis of relevant Standardization Activities
3.1. IETF Concluded CDI Working Group
The Content Distribution Internetworking (CDI) Working Group was
formed in the IETF following a BoF in December 2000 and closed in mid
2003.
For convenience, here is an extract from the CDI WG charter
[CDI-Charter]:
Niven-Jenkins, et al. Expires June 5, 2011 [Page 7]
Internet-Draft CDN Interconnection Problem Statement December 2010
"
o The goal of this working group is to define protocols to allow the
interoperation of separately-administered content networks.
o A content network is an architecture of network elements, arranged
for efficient delivery of digital content. Such content includes,
but is not limited to, web pages and images delivered via HTTP,
and streaming or continuous media which are controlled by RTSP.
o The working group will first define requirements for three modes
of content internetworking: interoperation of request-routing
systems, interoperation of distribution systems, and
interoperation of accounting systems. These requirements are
intended to lead to a follow-on effort to define protocols for
interoperation of these systems.
o In its initial form, the working group is not chartered to deliver
those protocols [...]
"
Thus, the CDI WG touched on the same problem space as the present
document.
The CDI WG published 3 Informational RFCs:
o RFC 3466 [RFC3466] - "A Model for Content Internetworking (CDI)".
o RFC 3568 [RFC3568] - "Known Content Network (CN) Request-Routing
Mechanisms".
o RFC 3570 [RFC3570] - "Content Internetworking (CDI) Scenarios".
Although the market, design and requirements placed on CDNs has
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
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.
3.2. 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].
Niven-Jenkins, et al. Expires June 5, 2011 [Page 8]
Internet-Draft CDN Interconnection Problem Statement December 2010
3.3. ETSI
ETSI is the European Telecommunications Standards Institute. ETSI
produces standards for Information and Communications Technologies
(ICT), including fixed, mobile, radio, converged, broadcast and
internet technologies.
3.3.1. TISPAN
TISPAN (Telecommunications and Internet converged Services and
Protocols for Advanced Networking) is an ETSI technical committee
creating Next Generation Networks (NGN) specifications.
TISPAN has published two IPTV specifications, one of which is based
on IMS. An extension of these specifications is being designed with
a CDN architecture supporting VoD for delivery to TISPAN devices
(UEs) or regular PCs. The use cases allow for hierarchically and
geographically distributed CDN scenarios, along with multi-CDN
cooperation. As a result, the architecture contains reference points
to support interconnection of other TISPAN CDNs. There is no intent
to support heterogeneous interconnection at this point. Also, this
effort is focusing on managed IPTV services.
The protocols phase has not yet started, and thus no protocols have
yet been defined.
3.3.2. MCD
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. However, no protocol level work has yet started in MCD for CDN
Interconnect.
3.4. ATIS IIF
ATIS ([ATIS]) is the Alliance for Telecommunications Industry
Solutions.
IIF is the IPTV Interoperability Forum (within ATIS) that develops
requirements, standards, and specifications for IPTV.
The IIF is developing the "IPTV Content on Demand (CoD) Service"
Niven-Jenkins, et al. Expires June 5, 2011 [Page 9]
Internet-Draft CDN Interconnection Problem Statement December 2010
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 IPTV
service provider) and does not cover the use, or interconnection, of
multiple CDNs.
The "IPTV Content on Demand (CoD) Service" specification defines a
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)
"The Open IPTV Forum has developed an end-to-end solution to allow
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
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
Text to be added in a future version of this document.
3.7. OCEAN
OCEAN (http://www.ict-ocean.eu/) is an EU funded research project
that started in February 2010. Some of its objectives are relevant
to CDNI, for example "design a new content delivery framework" and
"foster multi-vendor solutions", however others are much more
implementation orientated, e.g. "self-learning caching algorithms"
and "media-aware congestion control mechanisms".
OCEAN has not yet defined any protocols for CDN Interconnection.
Niven-Jenkins, et al. Expires June 5, 2011 [Page 10]
Internet-Draft CDN Interconnection Problem Statement December 2010
3.8. CableLabs VoD Metadata
"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]
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.
4. CDN Interconnect Problem Area for IETF
Interconnecting CDNs involves many different functions and components
being integrated to some degree. Only some of those require
standardization. Out of those, only some fit within the expertise
and charter of the IETF. The problem area proposed for IETF work is
illustrated in Figure 1. The candidate goals (and respectively the
non-goals) for IETF work on CDN Interconnection are discussed in
Section 4.1 (and respectively Section 4.2 ).
Niven-Jenkins, et al. Expires June 5, 2011 [Page 11]
Internet-Draft CDN Interconnection Problem Statement December 2010
--------
/ \
| CSP |
\ /
--------
*
*
* /\
* / \
--------------------- |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
**** interfaces outside the scope of CDNI
Figure 1: CDNI Problem Area
Niven-Jenkins, et al. Expires June 5, 2011 [Page 12]
Internet-Draft CDN Interconnection Problem Statement December 2010
4.1. Candidate CDNI Goals for IETF
Listed below are parts of the problem space that are proposed to be
addressed by a potential CDNI working group in the IETF:
o Specification of a control plane architecture for CDN
Interconnect.
o Specification of the APIs and protocols required to Interconnect a
pair of CDNs (where a given CDN may support multiple interconnects
with different CDNs). This is expected to comprise (but possibly
grouped in a different manner):
* CDNI Control API: This API allows the "CDNI Control" system in
interconnected CDNs to communicate. This API may support the
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
Niven-Jenkins, et al. Expires June 5, 2011 [Page 13]
Internet-Draft CDN Interconnection Problem Statement December 2010
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
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 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
Niven-Jenkins, et al. Expires June 5, 2011 [Page 14]
Internet-Draft CDN Interconnection Problem Statement December 2010
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
5.1. ALTO
As stated in the ALTO Working Group charter [ALTO-Charter]:
"The Working Group will design and specify an Application-Layer
Traffic Optimization (ALTO) service that will provide applications
with information to perform better-than-random initial peer
selection. ALTO services may take different approaches at balancing
factors such as maximum bandwidth, minimum cross-domain traffic,
lowest cost to the user, etc. The WG will consider the needs of
BitTorrent, tracker-less P2P, and other applications, such as content
delivery networks (CDN) and mirror selection."
In particular, the ALTO service could be used by a CDN Request
Routing system to improve its selection of a CDN surrogate to serve a
particular user request. See [I-D.penno-alto-cdn] for a detailed
discussion on how CDN Request Routing can be used as an integration
point of ALTO into CDNs. It is possible that the ALTO service could
be used in the same manner in a multi-CDN environment based on CDN
Interconnect. For example, an upstream CDN may take advantage of the
ALTO service in its decision for selecting a downstream CDN to which
a user request should be delegated.
However, the work of ALTO is complementary to and does not overlap
with the work proposed in this document because the integration
between ALTO and a CDN would fall under "algorithms for selection of
CDN or Surrogate by Request-Routing systems" in Section 4.2
6. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
Niven-Jenkins, et al. Expires June 5, 2011 [Page 15]
Internet-Draft CDN Interconnection Problem Statement December 2010
7. Security Considerations
This document describes a problem faced by CDN Providers and does not
itself introduce any new security considerations.
However, maintaining the security of the content itself, its
associated metadata (including distribution and delivery policies)
and the CDNs distributing and delivering it are critical requirements
for both CDN Providers and their customers and any work on CDN
Interconnection must provide sufficient mechanisms to maintain the
security of the overall system of interconnected CDNs as well as the
information (content, metadata, logs, etc) distributed and delivered
through any CDN Interconnects.
8. Acknowledgements
The authors would like to thank David Ferguson, Julien Maisonneuve,
Mahesh Viveganandhan and Bruce Davie for their early review comments
and contributions to the text.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References
[ALTO-Charter]
"IETF ALTO WG Charter
(http://datatracker.ietf.org/wg/alto/charter/)".
[ATIS] "ATIS (http://www.atis.org/)".
[CDI-Charter]
"IETF CDI WG Charter
(http://www.ietf.org/wg/concluded/cdi)".
[CableLabs]
"CableLabs (http://www.cablelabs.com/about/)".
[CableLabs-Metadata]
"CableLabs VoD Metadata Project Primer
(http://www.cablelabs.com/projects/metadata/primer/)".
Niven-Jenkins, et al. Expires June 5, 2011 [Page 16]
Internet-Draft CDN Interconnection Problem Statement December 2010
[I-D.penno-alto-cdn]
Penno, R., Raghunath, S., Medved, J., Alimi, R., Yang, R.,
and S. Previdi, "ALTO and Content Delivery Networks",
draft-penno-alto-cdn-02 (work in progress), October 2010.
[OIPF-Overview]
"OIPF Release 2 Specification Volume 1 - Overview",
September 2010.
[P2PRG-CDNI]
Davie, B. and F. Le Faucheur, "Interconnecting CDNs aka
"Peering Peer-to-Peer"
(http://www.ietf.org/proceedings/77/slides/P2PRG-2.pdf)",
March 2010.
[RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web
Replication and Caching Taxonomy", RFC 3040, January 2001.
[RFC3466] Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model
for Content Internetworking (CDI)", RFC 3466,
February 2003.
[RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known
Content Network (CN) Request-Routing Mechanisms",
RFC 3568, July 2003.
[RFC3570] Rzewski, P., Day, M., and D. Gilletti, "Content
Internetworking (CDI) Scenarios", RFC 3570, July 2003.
[TAXONOMY]
Pathan, A., "A Taxonomy and Survey of Content Delivery
Networks
(http://www.gridbus.org/reports/CDN-Taxonomy.pdf)", 2007.
Authors' Addresses
Ben Niven-Jenkins
Velocix (Alcatel-Lucent)
326 Cambridge Science Park
Milton Road, Cambridge CB4 0WG
UK
Email: ben@velocix.com
Niven-Jenkins, et al. Expires June 5, 2011 [Page 17]
Internet-Draft CDN Interconnection Problem Statement December 2010
Francois Le Faucheur
Cisco Systems
Greenside, 400 Avenue de Roumanille
Sophia Antipolis 06410
France
Phone: +33 4 97 23 26 19
Email: flefauch@cisco.com
Nabil Bitar
Verizon
40 Sylvan Road
Waltham, MA 02145
USA
Email: nabil.bitar@verizon.com
Niven-Jenkins, et al. Expires June 5, 2011 [Page 18]