draft-ietf-cdni-requirements-06.txt   draft-ietf-cdni-requirements-07.txt 
Network Working Group K. Leung, Ed. Network Working Group K. Leung, Ed.
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Informational Y. Lee, Ed. Intended status: Informational Y. Lee, Ed.
Expires: October 11, 2013 Comcast Expires: December 2, 2013 Comcast
April 9, 2013 May 31, 2013
Content Distribution Network Interconnection (CDNI) Requirements Content Distribution Network Interconnection (CDNI) Requirements
draft-ietf-cdni-requirements-06 draft-ietf-cdni-requirements-07
Abstract Abstract
Content Delivery Networks (CDNs) are frequently used for large-scale Content Delivery Networks (CDNs) are frequently used for content
content delivery. As a result, existing CDN providers are scaling up delivery. As a result of significant growth in content delivered
their infrastructure and many Network Service Providers (NSPs) are over IP networks, existing CDN providers are scaling up their
deploying their own CDNs. There is a requirement for interconnecting infrastructure. Many Network Service Providers and Enterprise
standalone CDNs so that their collective CDN footprint can be Service Providers are also deploying their own CDNs. To deliver
leveraged for the end-to-end delivery of content from Content Service contents from the Content Service Protect (CSP) to end users, the
Providers (CSPs) to end users. The Content Distribution Network contents may traverse across multiple CDNs. This creates a need for
Interconnection (CDNI) working group has been chartered to develop an interconnecting (previously) standalone CDNs so that they can
interoperable and scalable solution for such CDN interconnection. collectively act as a single delivery platform from the CSP to the
end users.
The goal of the present document is to outline the requirements for The goal of the present document is to outline the requirements for
the solution and interfaces to be specified by the CDNI working the solution and interfaces to be specified by the CDNI working
group. This draft is a work in progress and requirements may be group.
added, modified, or removed by the working group.
Requirements Language
The key words "High Priority", "Medium Priority" and "Low Priority"
in this document are to be interpreted in the following way:
o "High Priority" indicates requirements that are to be supported by
the CDNI interfaces. A requirement is stated as "High Priority"
when it is established by the working group that it can be met
without compromising the targeted schedule for WG deliverables, or
when it is established that specifying a solution without meeting
this requirement would not make sense and would justify re-
adjusting the WG schedule, or both. This is tagged as "[HIGH]".
o "Medium Priority" indicates requirements that are to be supported
by the CDNI interfaces unless the WG realizes at a later stage
that attempting to meet this requirement would compromise the
overall WG schedule (for example it would involve complexities
that would result in significantly delaying the deliverables).
This is tagged as "[MED]".
o "Low Priority" indicates requirements that are to be supported by
the CDNI interfaces provided that dedicating WG resources to this
work does not prevent addressing "High Priority" and "Medium
Priority" requirements and that attempting to meet this
requirement would not compromise the overall WG schedule. This is
tagged as "[LOW]".
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 11, 2013. This Internet-Draft will expire on December 2, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. CDNI Model and CDNI Interfaces . . . . . . . . . . . . . . . . 4 2. CDNI Model and CDNI Interfaces . . . . . . . . . . . . . . . . 4
3. Generic CDNI Requirements . . . . . . . . . . . . . . . . . . 6 3. Generic CDNI Requirements . . . . . . . . . . . . . . . . . . 6
4. CDNI Control Interface Requirements . . . . . . . . . . . . . 7 4. CDNI Control Interface Requirements . . . . . . . . . . . . . 7
5. CDNI Request Routing/Redirection Interface Requirements . . . 10 5. CDNI Request Routing/Redirection Interface Requirements . . . 9
6. CDNI Request Routing/Footprint & Capabilities 6. CDNI Request Routing/Footprint & Capabilities
Advertisement Interface Requirements . . . . . . . . . . . . . 12 Advertisement Interface Requirements . . . . . . . . . . . . . 12
7. CDNI Metadata Distribution Interface Requirements . . . . . . 14 7. CDNI Metadata Distribution Interface Requirements . . . . . . 14
8. CDNI Logging Interface Requirements . . . . . . . . . . . . . 18 8. CDNI Logging Interface Requirements . . . . . . . . . . . . . 18
9. CDNI Security Requirements . . . . . . . . . . . . . . . . . . 20 9. CDNI Security Requirements . . . . . . . . . . . . . . . . . . 20
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
11. Security Considerations . . . . . . . . . . . . . . . . . . . 21 11. Security Considerations . . . . . . . . . . . . . . . . . . . 21
12. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 12. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
14. Appendix: Requirements Mapping . . . . . . . . . . . . . . . . 22 14. Appendix: Requirements Mapping . . . . . . . . . . . . . . . . 22
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
15.1. Normative References . . . . . . . . . . . . . . . . . . . 23 15.1. Normative References . . . . . . . . . . . . . . . . . . . 23
15.2. Informative References . . . . . . . . . . . . . . . . . . 24 15.2. Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
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 of the significant
providers are scaling up their infrastructure and many Network growth in content delivered over IP networks, existing CDN providers
Service Providers (NSPs) are deploying their own CDNs. It is are scaling up their infrastructure and many Network Service
generally desirable that a given content item can be delivered to an Providers and Enterprise Service Providers are deploying their own
End User regardless of that End User's location or attachment CDNs. Subject to the policy of the CSP, it is generally desirable
network. However, the footprint of a given CDN in charge of that a given item of content can be delivered to an end user
delivering a given content may not expand close enough to the End regardless of that end user's location or attachment network. This
User's current location or attachment network to realize the cost creates a need for interconnecting (previously) standalone CDNs so
benefit and user experience that a more distributed CDN would they can interoperate and collectively behave as a single delivery
provide. This creates a requirement for interconnecting standalone infrastructure. The Content Distribution Network Interconnection
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. The Content Distribution Network Interconnection
(CDNI) working group has been chartered to develop an interoperable (CDNI) working group has been chartered to develop an interoperable
and scalable solution for such CDN interconnection. and scalable solution for such CDN interconnections.
[RFC6707] outlines the problem area that the CDNI working group is CDNI Problem Statement [RFC6707] outlines the problem area that the
chartered to address. [RFC6770] discusses the use cases for CDN CDNI working group is chartered to address. CDNI Problem Statement
Interconnection. [I-D.davie-cdni-framework] discusses the technology [RFC6770] discusses the use cases for CDN Interconnection. Framework
for CDNI [I-D.davie-cdni-framework] discusses the technology
framework for the CDNI solution and interfaces. framework for the CDNI solution and interfaces.
The goal of the present document is to document the requirements for The goal of the present document is to document the requirements for
the CDNI solution and interfaces. In order to meet the timelines the CDNI solution and interfaces. In order to meet the timelines
defined in the working group charter, the present document defined in the working group charter, the present document
categorizes the CDNI requirements as "High Priority", "Medium categorizes the CDNI requirements as "High Priority", "Medium
Priority", and "Low Priority". Priority", and "Low Priority".
1.1. Terminology 1.1. Terminology
This document uses the terminology defined in section 1.1 of This document uses the terminology defined in section 1.1 of
[I-D.davie-cdni-framework]. Framework for CDNI [I-D.davie-cdni-framework]. In addition, the key
words "High Priority", "Medium Priority" and "Low Priority" in this
document are to be interpreted in the following way:
o "High Priority" indicates requirements that are to be supported by
the CDNI interfaces. A requirement is stated as "High Priority"
when it is established by the working group that it can be met to
achieve the goal of a deployable solution in a short timeframe
(18-24 months) as needed by the industry. This is tagged as
"[HIGH]".
o "Medium Priority" indicates requirements that are to be supported
by the CDNI interfaces unless the WG realizes at a later stage
that attempting to meet this requirement does not achieve the goal
of a deployable solution in a short timeframe (18-24 months) as
needed by the industry. This is tagged as "[MED]".
o "Low Priority" indicates requirements that are to be supported by
the CDNI interfaces provided that dedicating WG resources to this
work does not prevent addressing "High Priority" and "Medium
Priority" requirements and that attempting to meet this
requirement is not an obstacle to achieving the goal of a
deployable solution in a short timeframe (18-24 months) as needed
by the industry. This is tagged as "[LOW]".
2. CDNI Model and CDNI Interfaces 2. CDNI Model and CDNI Interfaces
For convenience Figure 1 from [I-D.davie-cdni-framework] illustrating For convenience Figure 1 from Framework for CDNI
the CDNI problem area and the CDNI protocols is replicated below. [I-D.davie-cdni-framework] illustrating the CDNI problem area and the
CDNI protocols is replicated below.
-------- --------
/ \ / \
| CSP | | CSP |
\ / \ /
-------- --------
* *
* *
* /\ * /\
* / \ * / \
skipping to change at page 7, line 42 skipping to change at page 7, line 42
GEN-13 [HIGH] The CDNI solution shall support HTTP Adaptive GEN-13 [HIGH] The CDNI solution shall support HTTP Adaptive
Streaming content. Streaming content.
4. CDNI Control Interface Requirements 4. CDNI Control Interface Requirements
The primary purpose of the CDNI Control interface (CI) is to initiate The primary purpose of the CDNI Control interface (CI) is to initiate
the interconnection across CDNs, bootstrap the other CDNI interfaces the interconnection across CDNs, bootstrap the other CDNI interfaces
and trigger actions into the Downstream CDN by the Upstream CDN (such and trigger actions into the Downstream CDN by the Upstream CDN (such
as delete object from caches or trigger pre-positioned content as delete object from caches or trigger pre-positioned content
acquisition). We observe that while the CDNI Control interface is acquisition). The working group attempts to align requirements with
currently discussed as a single "protocol", further analysis will the appropriate interface; however, solutions to these requirements
determine whether the corresponding requirements are to be realized may apply to a different interface or another interface in addition
over a single interface and protocol, or over multiple interfaces and to the interface it is associated with.
protocols.
CI-1 [HIGH] The CDNI Control interface shall allow the Upstream CDN CI-1 [HIGH] The CDNI Control interface shall allow the Upstream CDN
to request that the Downstream CDN (and, if cascaded CDNs are to request that the Downstream CDN, including downstream
supported by the solution, that the potential cascaded cascaded CDNs, delete an object or set of objects and/or its
Downstream CDNs) delete an object or set of objects and/or its
CDNI metadata from the CDN surrogates and any storage. Only CDNI metadata from the CDN surrogates and any storage. Only
the object(s) and CDNI metadata that pertain to the requesting the object(s) and CDNI metadata that pertain to the requesting
Upstream CDN are allowed to be purged. Upstream CDN are allowed to be purged.
CI-2 [MED] The CDNI Control interface should allow for multiple CI-2 [MED] The CDNI Control interface should allow for multiple
content items identified by a Content Collection ID to be content items identified by a Content Collection ID to be
purged using a single Content Purge action. purged using a single Content Purge action.
CI-3 [MED] The CDNI Control interface should allow the Upstream CDN CI-3 [MED] The CDNI Control interface should allow the Upstream CDN
to request that the Downstream CDN (and, if cascaded CDNs are to request that the Downstream CDN, including downstream
supported by the solution, that the potential cascaded cascaded CDNs, mark an object or set of objects and/or its
Downstream CDNs) mark an object or set of objects and/or its
CDNI metadata as "stale" and revalidate them before they are CDNI metadata as "stale" and revalidate them before they are
delivered again. delivered again.
CI-4 [HIGH] The CDNI Control interface shall allow the Downstream CI-4 [HIGH] The CDNI Control interface shall allow the Downstream
CDN to report on the completion of these actions (by itself, CDN to report on the completion of these actions (by itself,
and if cascaded CDNs are supported by the solution, by and including downstream cascaded CDNs, in a manner
potential cascaded Downstream CDNs), in a manner appropriate appropriate for the action (e.g. synchronously or
for the action (e.g. synchronously or asynchronously). The asynchronously). The confirmation receipt should include a
confirmation receipt should include a success or failure success or failure indication. The failure indication along
indication. The failure indication is used if the Downstream with the reason are used if the Downstream CDN cannot delete
CDN cannot delete the content in its storage. the content in its storage.
CI-5 [MED] The CDNI Control interface should support initiation and CI-5 [MED] The CDNI Control interface should support initiation and
control by the Upstream CDN of pre-positioned CDNI metadata control by the Upstream CDN of pre-positioned CDNI metadata
acquisition by the Downstream CDN. acquisition by the Downstream CDN.
CI-6 [MED] The CDNI Control interface should support initiation and CI-6 [MED] The CDNI Control interface should support initiation and
control by the Upstream CDN of pre-positioned content control by the Upstream CDN of pre-positioned content
acquisition by the Downstream CDN. acquisition by the Downstream CDN.
CI-7 [LOW] The CDNI Control interface may allow a CDN to establish, CI-7 [LOW] The CDNI Control interface may allow a CDN to establish,
update and terminate a CDN interconnection with another CDN update and terminate a CDN interconnection with another CDN
whereby one CDN can act as a Downstream CDN for the other CDN whereby one CDN can act as a Downstream CDN for the other CDN
(that acts as an Upstream CDN). (that acts as an Upstream CDN).
CI-8 [LOW] The CDNI Control interface may allow control of the CDNI CI-8 [LOW] The CDNI Control interface may allow control of the CDNI
interconnection between any two CDNs independently for each interfaces between any two CDNs independently for each
direction (i.e. For the direction where CDN1 is the Upstream direction (e.g. For the direction where CDN1 is the Upstream
CDN and CDN2 is the Downstream CDN, and for the direction CDN and CDN2 is the Downstream CDN, and for the direction
where CDN2 is the Upstream CDN and CDN1 is the Downstream where CDN2 is the Upstream CDN and CDN1 is the Downstream
CDN). CDN).
CI-9 [LOW] The CDNI Control interface may allow bootstrapping of CI-9 [LOW] The CDNI Control interface may allow bootstrapping of
the Request-Routing interface. For example, this can the Request-Routing interface. For example, this can
potentially include: potentially include:
* negotiation of the Request-Routing method (e.g. DNS vs * negotiation of the Request-Routing method (e.g. DNS vs
HTTP, if more than one method is specified) HTTP, if more than one method is specified)
skipping to change at page 16, line 46 skipping to change at page 16, line 37
set of metadata elements with specified semantics (e.g. start set of metadata elements with specified semantics (e.g. start
of time window, end of time window). of time window, end of time window).
MI-15 [HIGH] The CDNI Metadata interface shall allow exchange of MI-15 [HIGH] The CDNI Metadata interface shall allow exchange of
opaque metadata element, whose semantic is not defined in CDNI opaque metadata element, whose semantic is not defined in CDNI
but established by private CDN agreement. but established by private CDN agreement.
MI-16 [HIGH] The CDNI Metadata Distribution interface shall allow MI-16 [HIGH] The CDNI Metadata Distribution interface shall allow
signaling of authorization checks and validation that are to signaling of authorization checks and validation that are to
be performed by the surrogate before delivery. For example, be performed by the surrogate before delivery. For example,
this could potentially include: this could potentially including the need to validate URI
signed information (e.g. Expiry time, Client IP address).
* need to validate URI signed information (e.g. Expiry
time, Client IP address).
MI-17 [MED] The CDNI Metadata Distribution interface should allow MI-17 [MED] The CDNI Metadata Distribution interface should allow
signaling of CDNI-relevant surrogate cache behavior signaling of CDNI-relevant surrogate cache behavior
parameters. For example, this could potentially include: parameters. For example, this could potentially include:
* control of whether the query string of HTTP URI is to be * control of whether the query string of HTTP URI is to be
ignored by surrogate cache ignored by surrogate cache
* enforcement of caching directives by Downstream CDN that * enforcement of caching directives by Downstream CDN that
are different than the ones signalled in the HTTP headers are different than the ones signalled in the HTTP headers
skipping to change at page 18, line 14 skipping to change at page 17, line 49
Downstream CDN is instructed by the Upstream CDN to report the Downstream CDN is instructed by the Upstream CDN to report the
Content Collection ID field in the log records, the Downstream Content Collection ID field in the log records, the Downstream
CDN is to use the value provided through the CDNI Metadata CDN is to use the value provided through the CDNI Metadata
interface for the corresponding content. Note the Session ID interface for the corresponding content. Note the Session ID
field along with Content Collection ID may be used for HTTP field along with Content Collection ID may be used for HTTP
Adaptive Streaming content. Adaptive Streaming content.
MI-21 [MED] The CDNI Metadata Distribution interface should allow MI-21 [MED] The CDNI Metadata Distribution interface should allow
the Upstream CDN to signal to the Downstream CDN the the Upstream CDN to signal to the Downstream CDN the
Authorization Group ID value for all the related HTTP Adaptive Authorization Group ID value for all the related HTTP Adaptive
Streamin content (i.e. manifest file and chunks). The Streaming content (i.e. manifest file and chunks). The
authorization result of a content (e.g. manifest file) is authorization result of a content (e.g. manifest file) is
transferred over to related content (e.g. chunks). [Ed: need transferred over to related content (e.g. chunks).
to improve wording?]
8. CDNI Logging Interface Requirements 8. CDNI Logging Interface Requirements
This section identifies the requirements related to the CDNI Logging This section identifies the requirements related to the CDNI Logging
interface (LI). We observe that while the CDNI Logging interface is interface (LI). We observe that while the CDNI Logging interface is
currently discussed as a single "protocol", further analysis will currently discussed as a single "protocol", further analysis will
determine whether the corresponding requirements are to be realized determine whether the corresponding requirements are to be realized
over a single interface and protocol, or over multiple interfaces and over a single interface and protocol, or over multiple interfaces and
protocols. protocols.
skipping to change at page 20, line 28 skipping to change at page 20, line 13
logging retention period or some logging retention volume). logging retention period or some logging retention volume).
LI-17 [MED] The CDNI Logging interface should support the ability LI-17 [MED] The CDNI Logging interface should support the ability
for the Downstream CDN to include the Content Collection ID for the Downstream CDN to include the Content Collection ID
and Session ID fields in CDNI log entries generated for HTTP and Session ID fields in CDNI log entries generated for HTTP
Adaptive Streaming content. Adaptive Streaming content.
9. CDNI Security Requirements 9. CDNI Security Requirements
This section identifies the requirements related to the CDNI This section identifies the requirements related to the CDNI
security. Some of those are expected to affect multiple or all security. Some of these are expected to affect multiple or all
protocols. protocols.
SEC-1 [HIGH] All the CDNI interface shall support secure operation SEC-1 [HIGH] All the CDNI interface shall support secure operation
over unsecured IP connectivity (e.g. The Internet). This over unsecured IP connectivity (e.g. The Internet). This
includes authentication, confidentiality, integrity protection includes authentication, confidentiality, integrity protection
as well as protection against spoofing and replay. as well as protection against spoofing and replay.
SEC-2 [HIGH] The CDNI solution shall provide sufficient protection SEC-2 [HIGH] The CDNI solution shall provide sufficient protection
against Denial of Service attacks. This includes protection against Denial of Service attacks. This includes protection
against spoofed delivery requests sent by user agents directly against spoofed delivery requests sent by user agents directly
skipping to change at page 21, line 44 skipping to change at page 21, line 34
flefauch@cisco.com flefauch@cisco.com
Mahesh Viveganandhan Mahesh Viveganandhan
Cisco Systems Cisco Systems
mvittal@cisco.com mvittal@cisco.com
Grant Watson Grant Watson
BT Alcatel-Lucent (Velocix)
grant.watson@bt.com
gwatson@velocix.com
13. Acknowledgements 13. Acknowledgements
This document leverages the earlier work of the IETF CDI working This document leverages the earlier work of the IETF CDI working
group in particular as documented in [I-D.cain-request-routing-req], group in particular as documented in [I-D.cain-request-routing-req],
[I-D.amini-cdi-distribution-reqs] and [I-D.gilletti-cdnp-aaa-reqs]. [I-D.amini-cdi-distribution-reqs] and [I-D.gilletti-cdnp-aaa-reqs].
The authors would like to thank Gilles Bertrand, Christophe Caillet, The authors would like to thank Gilles Bertrand, Christophe Caillet,
Bruce Davie, Phil Eardly, Ben Niven-Jenkins, Agustin Schapira, Emile Bruce Davie, Phil Eardly, Ben Niven-Jenkins, Agustin Schapira, Emile
Stephan, Eric Burger, Susan He, Kevin Ma, and Daryl Malas for their Stephan, Eric Burger, Susan He, Kevin Ma, and Daryl Malas for their
 End of changes. 24 change blocks. 
97 lines changed or deleted 87 lines changed or added

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