draft-ietf-cdni-requirements-09.txt   draft-ietf-cdni-requirements-10.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: January 2, 2014 Comcast Expires: March 14, 2014 Comcast
July 1, 2013 Sept 10, 2013
Content Distribution Network Interconnection (CDNI) Requirements Content Distribution Network Interconnection (CDNI) Requirements
draft-ietf-cdni-requirements-09 draft-ietf-cdni-requirements-10
Abstract Abstract
Content Delivery Networks (CDNs) are frequently used for content Content Delivery Networks (CDNs) are frequently used for content
delivery. As a result of significant growth in content delivered delivery. As a result of significant growth in content delivered
over IP networks, existing CDN providers are scaling up their over IP networks, existing CDN providers are scaling up their
infrastructure. Many Network Service Providers and Enterprise infrastructure. Many Network Service Providers and Enterprise
Service Providers are also deploying their own CDNs. To deliver Service Providers are also deploying their own CDNs. To deliver
contents from the Content Service Protect (CSP) to end users, the contents from the Content Service Provider (CSP) to end users, the
contents may traverse across multiple CDNs. This creates a need for contents may traverse across multiple CDNs. This creates a need for
interconnecting (previously) standalone CDNs so that they can interconnecting (previously) standalone CDNs so that they can
collectively act as a single delivery platform from the CSP to the collectively act as a single delivery platform from the CSP to the
end users. 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. group.
Status of this Memo Status of this Memo
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 January 2, 2014. This Internet-Draft will expire on March 14, 2014.
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
skipping to change at page 2, line 20 skipping to change at page 2, line 20
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . . 7
4. CDNI Control Interface Requirements . . . . . . . . . . . . . 7 4. CDNI Control Interface Requirements . . . . . . . . . . . . . 8
5. CDNI Request Routing/Redirection Interface Requirements . . . 9 5. CDNI Request Routing Redirection Interface Requirements . . . 11
6. CDNI Request Routing/Footprint & Capabilities 6. CDNI Footprint & Capabilities Advertisement Interface
Advertisement Interface Requirements . . . . . . . . . . . . . 12 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. CDNI Metadata Distribution Interface Requirements . . . . . . 14 7. CDNI Metadata Interface Requirements . . . . . . . . . . . . . 15
8. CDNI Logging Interface Requirements . . . . . . . . . . . . . 18 8. CDNI Logging Interface Requirements . . . . . . . . . . . . . 19
9. CDNI Security Requirements . . . . . . . . . . . . . . . . . . 20 9. CDNI Security Requirements . . . . . . . . . . . . . . . . . . 21
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
11. Security Considerations . . . . . . . . . . . . . . . . . . . 21 11. Security Considerations . . . . . . . . . . . . . . . . . . . 22
12. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 12. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
14. Appendix: Requirements Mapping . . . . . . . . . . . . . . . . 22 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 14.1. Normative References . . . . . . . . . . . . . . . . . . . 23
15.1. Normative References . . . . . . . . . . . . . . . . . . . 23 14.2. Informative References . . . . . . . . . . . . . . . . . . 23
15.2. Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 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
skipping to change at page 3, line 27 skipping to change at page 3, line 27
CDNs. Subject to the policy of the CSP, it is generally desirable CDNs. Subject to the policy of the CSP, it is generally desirable
that a given item of content can be delivered to an end user that a given item of content can be delivered to an end user
regardless of that end user's location or attachment network. This regardless of that end user's location or attachment network. This
creates a need for interconnecting (previously) standalone CDNs so creates a need for interconnecting (previously) standalone CDNs so
they can interoperate and collectively behave as a single delivery they can interoperate and collectively behave as a single delivery
infrastructure. The Content Distribution Network Interconnection infrastructure. 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 interconnections. and scalable solution for such CDN interconnections.
CDNI Problem Statement [RFC6707] outlines the problem area that the CDNI Problem Statement [RFC6707] outlines the problem area that the
CDNI working group is chartered to address. CDNI Problem Statement CDNI working group is chartered to address. Use Cases for CDNI
[RFC6770] discusses the use cases for CDN Interconnection. Framework [RFC6770] discusses the use cases for CDN Interconnection. Framework
for CDNI [I-D.ietf-cdni-framework] discusses the technology framework for CDN Interconnection [I-D.ietf-cdni-framework] discusses the
for the CDNI solution and interfaces. technology 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 [RFC6707] as well as in
Framework for CDNI [I-D.ietf-cdni-framework]. In addition, the key section 1.1 of Framework for CDN Interconnection
words "High Priority", "Medium Priority" and "Low Priority" in this [I-D.ietf-cdni-framework]. In addition, the key words "High
document are to be interpreted in the following way: 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 o "High Priority" indicates requirements that are to be supported by
the CDNI interfaces. A requirement is stated as "High Priority" the CDNI interfaces. A requirement is stated as "High Priority"
when it is established by the working group that it can be met to 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 achieve the goal of a deployable solution in a short timeframe as
(18-24 months) as needed by the industry. This is tagged as needed by the industry. This is tagged as "[HIGH]".
"[HIGH]".
o "Medium Priority" indicates requirements that are to be supported o "Medium Priority" indicates requirements that are to be supported
by the CDNI interfaces unless the WG realizes at a later stage by the CDNI interfaces unless the WG realizes at a later stage
that attempting to meet this requirement does not achieve the goal that attempting to meet this requirement does not achieve the goal
of a deployable solution in a short timeframe (18-24 months) as of a deployable solution in a short timeframe as needed by the
needed by the industry. This is tagged as "[MED]". industry. This is tagged as "[MED]".
o "Low Priority" indicates requirements that are to be supported by o "Low Priority" indicates requirements that are to be supported by
the CDNI interfaces provided that dedicating WG resources to this the CDNI interfaces provided that dedicating WG resources to this
work does not prevent addressing "High Priority" and "Medium work does not prevent addressing "High Priority" and "Medium
Priority" requirements and that attempting to meet this Priority" requirements and that attempting to meet this
requirement is not an obstacle to achieving the goal of a requirement is not an obstacle to achieving the goal of a
deployable solution in a short timeframe (18-24 months) as needed deployable solution in a short timeframe as needed by the
by the industry. This is tagged as "[LOW]". industry. This is tagged as "[LOW]".
2. CDNI Model and CDNI Interfaces 2. CDNI Model and CDNI Interfaces
For convenience Figure 1 from Framework for CDNI For convenience, the "CDNI Expanded Model and CDNI Interfaces" figure
[I-D.ietf-cdni-framework] illustrating the CDNI problem area and the and brief descriptions of the CDNI interfaces in
CDNI protocols is replicated below. [I-D.ietf-cdni-framework] are replicated below.
-------- o CDNI Control interface (CI): Operations to bootstrap and
/ \ parameterize the other CDNI interfaces, as well as operations to
| CSP | pre-position, revalidate, and purge both metadata and content.
\ / The latter subset of operations is sometimes collectively called
-------- the "trigger interface."
*
* o CDNI Request Routing interface: Operations to determine what CDN
* /\ (and optionally what surrogate within a CDN) is to serve end-
* / \ user's requests. This interface is actually a logical bundling of
---------------------- |CDNI| ---------------------- two separate but related interfaces:
/ Upstream CDN \ | | / Downstream CDN \
| +-------------+ | Control Interface| +-------------+ | * CDNI Footprint & Capabilities Advertisement interface (FCI):
|******* Control |<======|====|========>| Control *******| Asynchronous operations to exchange routing information (e.g.,
|* +------*----*-+ | | | | +-*----*------+ *| the network footprint and capabilities served by a given CDN)
|* * * | | | | * * *| that enables CDN selection for subsequent user requests; and
|* +------*------+ | Logging Interface| +------*------+ *|
|* ***** Logging |<======|====|========>| Logging ***** *| * CDNI Request Routing Redirection interface (RI): Synchronous
|* * +-*-----------+ | | | | +-----------*-+ * *| operations to select a delivery CDN (surrogate) for a given
|* * * * | Request Routing | * * * *| user request.
.....*...+-*---------*-+ | Interface | +-*---------*-+...*.*...
. |* * *** Req-Routing |<======|====|========>| Req-Routing *** * *| . o CDNI Metadata interface (MI): Operations to communicate metadata
. |* * * +-------------+.| | | | +-------------+ * * *| . that governs how the content is delivered by interconnected CDNs.
. |* * * . CDNI Metadata | * * *| . Examples of CDNI metadata include geo-blocking directives,
. |* * * +-------------+ |. Interface | +-------------+ * * *| . availability windows, access control mechanisms, and purge
. |* * * | Distribution|<==.===|====|========>| Distribution| * * *| . directives. May include a combination of:
. |* * * | | | . \ / | | | * * *| .
. |* * * |+---------+ | | . \/ | | +---------+| * * *| . * Asynchronous operations to exchange metadata that govern
. |* * ***| +---------+| | ....Request......+---------+ |*** * *| . subsequent user requests for content; and
. |* *****+-|Surrogate|************************|Surrogate|-+***** *| .
. |******* +---------+| | Acquisition | |+----------+ *******| . * Synchronous operations that govern behavior for a given user
. | +-------------+ | | +-------*-----+ | . request for content.
. \ / \ * / .
. ---------------------- ---------*------------ . o CDNI Logging interface (LI): Operations that allow interconnected
. * . CDNs to exchange relevant activity logs. May include a
. * Delivery . combination of:
. * .
. +--*---+ . * Real-time exchanges, suitable for runtime traffic monitoring;
...............Request.............................| User |..Request.. and
* Offline exchanges, suitable for analytics and billing.
--------
/ \
| CSP |
\ /
--------
*
*
* /\
* / \
---------------------- |CDNI| ----------------------
/ Upstream CDN \ | | / Downstream CDN \
| +-------------+ | | CI | | +-------------+ |
|******* Control |<======|====|=======>| Control *******|
|* +------*----*-+ | | | | +-*----*------+ *|
|* * * | | | | * * *|
|* +------*------+ | | LI | | +------*------+ *|
|* ***** Logging |<======|====|=======>| Logging ***** *|
|* * +-*-----------+ | | | | +-----------*-+ * *|
|* * * * | | | | * * * *|
.....*...+-*---------*-+ | | RI | | +-*---------*-+...*.*...
. |* * | |<======|====|=======>| | * *| .
. |* * | Req-Routing | | |FCI | | | Req-Routing | * *| .
. |* * *** |<======|====|=======>| |** * *| .
. |* * * +-------------+.| | | | +-------------+ * * *| .
. |* * * . | | | * * *| .
. |* * * +-------------+ |. | MI | | +-------------+ * * *| .
. |* * * | Distribution|<==.===|====|=======>| Distribution| * * *| .
. |* * * | | | . \ / | | | * * *| .
. |* * * |+---------+ | | . \/ | | +---------+| * * *| .
. |* * ***| +---------+| | ...Request......+---------+ |*** * *| .
. |* *****+-|Surrogate|***********************|Surrogate|-+***** *| .
. |******* +---------+| | Acquisition | |+----------+ *******| .
. | +-------------+ | | +-------*-----+ | .
. \ / \ * / .
. ---------------------- ---------*------------ .
. * .
. * Delivery .
. * .
. +--*---+ .
...............Request............................| User |..Request..
| Agent| | Agent|
+------+ +------+
<==> interfaces inside the scope of CDNI <==> interfaces inside the scope of CDNI
**** interfaces outside the scope of CDNI
.... interfaces outside the scope of CDNI
Figure 1: CDNI Model and CDNI Interfaces **** interfaces outside the scope of CDNI
.... interfaces outside the scope of CDNI
Figure 1: CDNI Expanded Model and CDNI Interfaces
3. Generic CDNI Requirements 3. Generic CDNI Requirements
This section identifies generic requirements independent of the This section identifies generic requirements independent of the
individual CDNI interfaces. Some of those are expected to affect individual CDNI interfaces. Some of those are expected to affect
multiple or all interfaces. multiple or all interfaces.
GEN-1 [MED] Wherever possible, the CDNI interfaces should reuse or GEN-1 [MED] Wherever possible, the CDNI interfaces should reuse or
leverage existing IETF protocols. leverage existing IETF protocols.
skipping to change at page 9, line 43 skipping to change at page 11, line 5
between the Logging protocol endpoints between the Logging protocol endpoints
* negotiation/definition of the log file format and set of * negotiation/definition of the log file format and set of
fields to be exported through the Logging protocol, with fields to be exported through the Logging protocol, with
some granularity (e.g. On a per content type basis). some granularity (e.g. On a per content type basis).
* negotiation/definition of parameters related to * negotiation/definition of parameters related to
transaction Logs export (e.g., export protocol, file transaction Logs export (e.g., export protocol, file
compression, export frequency, directory). compression, export frequency, directory).
5. CDNI Request Routing/Redirection Interface Requirements 5. CDNI Request Routing Redirection Interface Requirements
The main function of the CDNI request routing/ Redirection (RI) The main function of the CDNI Request Routing Redirection interface
interface is to allow the Request-Routing systems in interconnected (RI) is to allow the Request-Routing systems in interconnected CDNs
CDNs to communicate to facilitate redirection of the request across to communicate to facilitate redirection of the request across CDNs.
CDNs.
RI-1 [HIGH] The CDNI request routing/Redirection interface shall RI-1 [HIGH] The CDNI Request Routing Redirection interface shall
support efficient request-routing for small objects. This support efficient request-routing for small objects. This
may, for example, call for a mode of operation (e.g. DNS- may, for example, call for a mode of operation (e.g. DNS-
based request routing) where freshness and accuracy of CDN/ based request routing) where freshness and accuracy of CDN/
Surrogate selection can be traded-off against reduced request- Surrogate selection can be traded-off against reduced request-
routing load (e.g. Via lighter-weight queries and caching of routing load (e.g. Via lighter-weight queries and caching of
request-routing decisions). request-routing decisions).
RI-2 [HIGH] The CDNI request routing/Redirection interface shall RI-2 [HIGH] The CDNI Request Routing Redirection interface shall
support efficient request-routing for large objects. This support efficient request-routing for large objects. This
may, for example, call for a mode of operation (e.g. HTTP- may, for example, call for a mode of operation (e.g. HTTP-
based request routing) where freshness and accuracy of CDN/ based request routing) where freshness and accuracy of CDN/
Surrogate selection justifies a per-request decision and a Surrogate selection justifies a per-request decision and a
per-request CDNI Request-Routing protocol call. per-request CDNI Request-Routing protocol call.
RI-3 [HIGH] The CDNI request routing/Redirection interface shall RI-3 [HIGH] The CDNI Request Routing Redirection interface shall
support recursive CDNI request routing. support recursive CDNI request routing.
RI-4 [HIGH] The CDNI request routing/Redirection interface shall RI-4 [HIGH] The CDNI Request Routing Redirection interface shall
support iterative CDNI request routing. support iterative CDNI request routing.
RI-5 [MED] In case of detection of a request redirection loop, the RI-5 [MED] In case of detection of a request redirection loop, the
CDNI request routing/Redirection interface's loop prevention CDNI Request Routing Redirection interface's loop prevention
mechanism should allow routing of the request by avoiding the mechanism should allow routing of the request by avoiding the
loop (as opposed to the request loop being simply interrupted loop (as opposed to the request loop being simply interrupted
without routing the request). without routing the request).
RI-6 [MED] The CDNI request routing/Redirection interface should RI-6 [MED] The CDNI Request Routing Redirection interface should
support a mechanism allowing enforcment of a limit on the support a mechanism allowing enforcment of a limit on the
number of successive CDN redirections for a given request. number of successive CDN redirections for a given request.
RI-7 [LOW] The CDNI request routing/Redirection interface may RI-7 [LOW] The CDNI Request Routing Redirection interface may
support a mechanism allowing an Upstream CDN to avoid support a mechanism allowing an Upstream CDN to avoid
redirecting a request to a Downstream CDN if that is likely to redirecting a request to a Downstream CDN if that is likely to
result in the total redirection time exceeding some limit. result in the total redirection time exceeding some limit.
RI-8 [HIGH] The CDNI request routing/Redirection interface shall RI-8 [HIGH] The CDNI Request Routing Redirection interface shall
allow the Upstream CDN to include, in the query to the allow the Upstream CDN to include, in the query to the
Downstream CDN, the necessary information to allow the Downstream CDN, the necessary information to allow the
Downstream CDN to process the redirection query. This could, Downstream CDN to process the redirection query. This could,
for example, include: for example, include:
* information from which the location of the user-agent that * information from which the location of the user-agent that
originated the request can be inferred (e.g. User Agent originated the request can be inferred (e.g. User Agent
fully qualified domain name in case of HTTP-based Request fully qualified domain name in case of HTTP-based Request
Routing, DNS Proxy fully qualified domain name in case of Routing, DNS Proxy fully qualified domain name in case of
DNS-based Request Routing) DNS-based Request Routing)
* requested resource information (e.g. Resource URI in case * requested resource information (e.g. Resource URI in case
of HTTP-based Request Routing, Resource hostname in case of HTTP-based Request Routing, Resource hostname in case
of DNS-based Request Routing) of DNS-based Request Routing)
* additional available request information (e.g. request * additional available request information (e.g. request
headers in case of HTTP-based Request Routing). headers in case of HTTP-based Request Routing).
RI-9 [LOW] The CDNI request routing/Redirection interface may also RI-9 [LOW] The CDNI Request Routing Redirection interface may also
allow the Upstream CDN to convey information pointing to CDNI allow the Upstream CDN to convey information pointing to CDNI
metadata applicable (individually or through inheritance) to metadata applicable (individually or through inheritance) to
the requested content. For illustration, the CDNI metadata the requested content. For illustration, the CDNI metadata
pointed to could potentially include metadata that is pointed to could potentially include metadata that is
applicable to any content, metadata that is applicable to a applicable to any content, metadata that is applicable to a
content collection (to which the requested content belongs) content collection (to which the requested content belongs)
and/or metadata that is applicable individually to the and/or metadata that is applicable individually to the
requested content. requested content.
RI-10 [HIGH] The CDNI request routing/Redirection interface shall RI-10 [HIGH] The CDNI Request Routing Redirection interface shall
allow the Downstream CDN to include the following information allow the Downstream CDN to include the following information
in the response to the Upstream CDN: in the response to the Upstream CDN:
* status code, in particular indicating acceptance or * status code, in particular indicating acceptance or
rejection of request (e.g. Because the Downstream CDN is rejection of request (e.g. Because the Downstream CDN is
unwilling or unable to serve the request). In case of unwilling or unable to serve the request). In case of
rejection, an error code is also to be provided, which rejection, an error code is also to be provided, which
allows the Upstream CDN to react appropriately (e.g. allows the Upstream CDN to react appropriately (e.g.
Select another Downstream CDN, or serve the request Select another Downstream CDN, or serve the request
itself) itself)
* redirection information (e.g. Resource URI in case of * redirection information (e.g. Resource URI in case of
HTTP-based Request Routing, equivalent of a DNS record in HTTP-based Request Routing, equivalent of a DNS record in
case of DNS-based Request Routing). case of DNS-based Request Routing).
RI-11 [HIGH] The CDNI request routing/Redirection interface shall RI-11 [HIGH] The CDNI Request Routing Redirection interface shall
allow for per-chunk request routing of HTTP Adaptive Streaming allow for per-chunk request routing of HTTP Adaptive Streaming
content. content.
RI-12 [LOW] The CDNI request routing/Redirection interface may allow RI-12 [LOW] The CDNI Request Routing Redirection interface may allow
the Upstream CDN to use the information conveyed by the the Upstream CDN to use the information conveyed by the
Downstream CDN during the Recursive Request Routing process to Downstream CDN during the Recursive Request Routing process to
rewrite an HTTP Adaptive Streaming manifest file. rewrite an HTTP Adaptive Streaming manifest file.
RI-13 [LOW] The CDNI Request-Routing interface may allow the RI-13 [LOW] The CDNI Request-Routing interface may allow the
Upstream CDN to re-sign the invariant portion of the chunk Upstream CDN to re-sign the invariant portion of the chunk
URIs embedded in the HTTP Adaptive Streaming manifest file. URIs embedded in the HTTP Adaptive Streaming manifest file.
RI-14 [MED] The CDNI request routing/Redirection interface should RI-14 [MED] The CDNI Request Routing Redirection interface should
allow the use of HTTP cookie to associate the chunks with the allow the use of HTTP cookie to associate the chunks with the
HTTP Adaptive Stream manifest file (which is verified by the HTTP Adaptive Stream manifest file (which is verified by the
URI signature) based on the Authorization Group ID (which is URI signature) based on the Authorization Group ID (which is
an identifier used to correlate the manifest file to the an identifier used to correlate the manifest file to the
related chunks). related chunks).
RI-15 [MED] The CDNI request routing/Redirection interface should RI-15 [MED] The CDNI Request Routing Redirection interface should
allow for an efficient method of transferring request routing allow for an efficient method of transferring request routing
information for multiple chunks from the Downstream CDN to the information for multiple chunks from the Downstream CDN to the
Upstream CDN as part of the recursive request routing process. Upstream CDN as part of the recursive request routing process.
6. CDNI Request Routing/Footprint & Capabilities Advertisement 6. CDNI Footprint & Capabilities Advertisement Interface Requirements
Interface Requirements
The main function of the CDNI Request Routing Footprint & The main function of the CDNI Footprint & Capabilities Advertisement
Capabilities Advertisement Interface (FCI) is to allow the Downstream interface (FCI) is to allow the Downstream CDN to advertise the
CDN to advertise the information regarding its footprint and information regarding its footprint and capabilities to the Upstream
capabilities to the Upstream CDN. CDN.
FCI-1 [HIGH] The CDNI request routing/Footprint & Capabilities FCI-1 [HIGH] The CDNI Footprint & Capabilities Advertisement
advertisement interface shall allow the Downstream CDN to interface shall allow the Downstream CDN to communicate to the
communicate to the Upstream CDN coarse information about the Upstream CDN coarse information about the Downstream CDN
Downstream CDN ability and/or willingness to handle requests ability and/or willingness to handle requests from the
from the Upstream CDN. For example, this could potentially Upstream CDN. For example, this could potentially include a
include a binary signal ("Downstream CDN ready/not-ready to binary signal ("Downstream CDN ready/not-ready to take
take additional requests from Upstream CDN") to be used in additional requests from Upstream CDN") to be used in case of
case of excessive load or failure condition in the Downstream excessive load or failure condition in the Downstream CDN.
CDN.
FCI-2 [MED] The CDNI request routing/Footprint & Capabilities FCI-2 [MED] The CDNI Footprint & Capabilities Advertisement
advertisement interface should allow the Downstream CDN to interface should allow the Downstream CDN to communicate to
communicate to the Upstream CDN aggregate information to the Upstream CDN aggregate information to facilitate CDN
facilitate CDN selection during request routing, such as selection during request routing, such as Downstream CDN
Downstream CDN capabilities, resources and affinities (i.e. capabilities, resources and affinities (i.e. Preferences or
Preferences or cost). This information could, for example, cost). This information could, for example, include:
include:
* supported content types and delivery protocols * supported content types and delivery protocols
* footprint (e.g. layer-3 coverage) * footprint (e.g. layer-3 coverage)
* a set of metrics/attributes (e.g. Streaming bandwidth, * a set of metrics/attributes (e.g. Streaming bandwidth,
storage resources, distribution and delivery priority) storage resources, distribution and delivery priority)
* a set of affinities (e.g. Preferences, indication of * a set of affinities (e.g. Preferences, indication of
distribution/delivery fees) distribution/delivery fees)
skipping to change at page 13, line 16 skipping to change at page 14, line 19
Reachability information of Downstream CDN Request Routing Reachability information of Downstream CDN Request Routing
system). system).
[Note: Some of this information - such as supported content [Note: Some of this information - such as supported content
types and delivery protocols- may also potentially be taken types and delivery protocols- may also potentially be taken
into account by the distribution system in the Upstream CDN into account by the distribution system in the Upstream CDN
for pre-positioning of content and/or metadata in the for pre-positioning of content and/or metadata in the
Downstream CDN in case of pre-positioned content acquisition Downstream CDN in case of pre-positioned content acquisition
and/or pre-positioned CDNI metadata acquisition.] and/or pre-positioned CDNI metadata acquisition.]
FCI-3 [MED] In the case of cascaded redirection, the CDNI request FCI-3 [MED] In the case of cascaded redirection, the CDNI Footprint
routing/Footprint & Capabilities advertisement interface & Capabilities Advertisement interface should allow the
should allow the Downstream CDN to also include in the Downstream CDN to also include in the information communicated
information communicated to the Upstream CDN, information on to the Upstream CDN, information on the capabilities,
the capabilities, resources and affinities of CDNs to which resources and affinities of CDNs to which the Downstream CDN
the Downstream CDN may (in turn) redirect requests received by may (in turn) redirect requests received by the Upstream CDN.
the Upstream CDN. In that case, the CDNI Request-Routing In that case, the CDNI Request-Routing interface shall prevent
interface shall prevent looping of such information exchange. looping of such information exchange.
FCI-4 [LOW] The CDNI request routing/Footprint & Capabilities FCI-4 [LOW] The CDNI Footprint & Capabilities Advertisement
advertisement interface may allow the Downstream CDN to interface may allow the Downstream CDN to communicate to the
communicate to the Upstream CDN aggregate information on CDNI Upstream CDN aggregate information on CDNI administrative
administrative limits and policy. This information can be limits and policy. This information can be taken into account
taken into account by the Upstream CDN Request Routing system by the Upstream CDN Request Routing system in its CDN
in its CDN Selection decisions. This information could, for Selection decisions. This information could, for example,
example, include: include:
* maximum number of requests redirected by the Upstream CDN * maximum number of requests redirected by the Upstream CDN
to be served simultaneously by the Downstream CDN to be served simultaneously by the Downstream CDN
* maximum aggregate volume of content (e.g. in Terabytes) to * maximum aggregate volume of content (e.g. in Terabytes) to
be delivered by the Downstream CDN over a time period. be delivered by the Downstream CDN over a time period.
FCI-5 [MED] The CDNI request routing/Footprint & Capabilities FCI-5 [MED] The CDNI Footprint & Capabilities Advertisement
advertisement interface should support advertisement of the interface should support advertisement of the following types
following types of capabilities: of capabilities:
* delivery protocol (e.g., HTTP vs. RTMP) * delivery protocol (e.g., HTTP vs. RTMP)
* acquisition protocol (for acquiring content from an * acquisition protocol (for acquiring content from an
Upstream CDN) Upstream CDN)
* redirection mode (e.g., DNS Redirection vs. HTTP * redirection mode (e.g., DNS Redirection vs. HTTP
Redirection) Redirection)
* capabilities related to CDNI Logging (e.g., supported * capabilities related to CDNI Logging (e.g., supported
logging mechanisms) logging mechanisms)
* capabilities related to CDNI Metadata (e.g., authorization * capabilities related to CDNI Metadata (e.g., authorization
algorithms or support for proprietary vendor metadata) algorithms or support for proprietary vendor metadata)
FCI-6 [LOW] The CDNI Control interface may allow exchange and FCI-6 [LOW] The CDNI Control interface may allow exchange and
negotiation of delivery authorization mechanisms to be negotiation of delivery authorization mechanisms to be
supported across the CDNs (e.g. URI signature based supported across the CDNs (e.g. URI signature based
validation). validation).
7. CDNI Metadata Distribution Interface Requirements 7. CDNI Metadata Interface Requirements
The primary function of the CDNI Metadata Distribution interface (MI) The primary function of the CDNI Metadata interface (MI) is to allow
is to allow the Distribution system in interconnected CDNs to the Distribution system in interconnected CDNs to communicate to
communicate to ensure Content Distribution Metadata with inter-CDN ensure Content Distribution Metadata with inter-CDN scope can be
scope can be exchanged across CDNs. We observe that while the CDNI exchanged across CDNs. We observe that while the CDNI Metadata
Metadata Distribution protocol is currently discussed as a single Distribution protocol is currently discussed as a single "protocol",
"protocol", further analysis will determine whether the corresponding further analysis will determine whether the corresponding
requirements are to be realized over a single interface and protocol, requirements are to be realized over a single interface and protocol,
or over multiple interfaces and protocols. For example, a subset of or over multiple interfaces and protocols. For example, a subset of
the CDNI metadata might be conveyed in-band along with the actual the CDNI metadata might be conveyed in-band along with the actual
content acquisition across CDNs (e.g. content MD5 in HTTP header) content acquisition across CDNs (e.g. content MD5 in HTTP header)
while another subset might require an out-of-band interface & while another subset might require an out-of-band interface &
protocol (e.g. geo-blocking information). protocol (e.g. geo-blocking information).
MI-1 [HIGH] The CDNI Metadata Distribution interface shall allow MI-1 [HIGH] The CDNI Metadata interface shall allow the Upstream
the Upstream CDN to provide the Downstream CDN with content CDN to provide the Downstream CDN with content distribution
distribution metadata of inter-CDN scope. metadata of inter-CDN scope.
MI-2 [HIGH] The CDNI Metadata Distribution interface shall support
exchange of CDNI metadata for both the dynamic content
acquisition model and the pre-positioning content acquisition
model.
MI-3 [HIGH] The CDNI Metadata Distribution interface shall support MI-2 [HIGH] The CDNI Metadata interface shall support exchange of
a mode where no, or a subset of, the Metadata is initially CDNI metadata for both the dynamic content acquisition model
communicated to the Downstream CDN along with information and the pre-positioning content acquisition model.
about how/where to acquire the rest of the CDNI Metadata (i.e.
Dynamic CDNI metadata acquisition).
MI-4 [MED] The CDNI Metadata Distribution interface should support MI-3 [HIGH] The CDNI Metadata interface shall support a mode where
a mode where all the relevant Metadata is initially no, or a subset of, the Metadata is initially communicated to
communicated to the Downstream CDN (i.e. Pre-positioned CDNI the Downstream CDN along with information about how/where to
acquire the rest of the CDNI Metadata (i.e. Dynamic CDNI
metadata acquisition). metadata acquisition).
MI-4 [MED] The CDNI Metadata interface should support a mode where
all the relevant Metadata is initially communicated to the
Downstream CDN (i.e. Pre-positioned CDNI metadata
acquisition).
MI-5 [HIGH] Whether in the pre-positioned content acquisition model MI-5 [HIGH] Whether in the pre-positioned content acquisition model
or in the dynamic content acquisition model, the CDNI Metadata or in the dynamic content acquisition model, the CDNI Metadata
Distribution interface shall provide the necessary information interface shall provide the necessary information to allow the
to allow the Downstream CDN to acquire the content from an Downstream CDN to acquire the content from an upstream source
upstream source (e.g. Acquisition protocol and Uniform (e.g. Acquisition protocol and Uniform Resource Identifier in
Resource Identifier in Upstream CDN- or rules to construct Upstream CDN- or rules to construct this URI).
this URI).
MI-6 [HIGH] The CDNI metadata shall allow signaling of one or more MI-6 [HIGH] The CDNI metadata shall allow signaling of one or more
upstream sources, where each upstream source can be in the upstream sources, where each upstream source can be in the
Upstream CDN, in another CDN, the CSP origin server or any Upstream CDN, in another CDN, the CSP origin server or any
arbitrary source designated by the Upstream CDN. Note that arbitrary source designated by the Upstream CDN. Note that
some upstream sources (e.g. the content origin server) may or some upstream sources (e.g. the content origin server) may or
may not be willing to serve the content to the Downstream CDN, may not be willing to serve the content to the Downstream CDN,
if this policy is known to the Upstream CDN then it may omit if this policy is known to the Upstream CDN then it may omit
those sources when exchanging CDNI metadata. those sources when exchanging CDNI metadata.
MI-7 [HIGH] The CDNI Metadata Distribution interface (possibly in MI-7 [HIGH] The CDNI Metadata interface (possibly in conjunction
conjunction with the CDNI Control interface) shall allow the with the CDNI Control interface) shall allow the Upstream CDN
Upstream CDN to request addition and modification of CDNI to request addition and modification of CDNI Metadata into the
Metadata into the Downstream CDN. Downstream CDN.
MI-8 [HIGH] The CDNI Metadata Distribution interface (possibly in MI-8 [HIGH] The CDNI Metadata interface (possibly in conjunction
conjunction with the CDNI Control interface) shall allow with the CDNI Control interface) shall allow removal of
removal of obsolete CDNI Metadata from the Downstream CDN obsolete CDNI Metadata from the Downstream CDN (this could,
(this could, for example, be achieved via an explicit removal for example, be achieved via an explicit removal request from
request from the Upstream CDN or via expiration of a Time-To- the Upstream CDN or via expiration of a Time-To-Live
Live associated to the Metadata). associated to the Metadata).
MI-9 [HIGH] The CDNI Metadata Distribution interface shall allow MI-9 [HIGH] The CDNI Metadata interface shall allow association of
association of CDNI Metadata at the granularity of individual CDNI Metadata at the granularity of individual object. This
object. This is necessary to achieve fine-grain Metadata is necessary to achieve fine-grain Metadata distribution at
distribution at the level of an individual object when the level of an individual object when necessary.
necessary.
MI-10 [HIGH] The CDNI Metadata Distribution interface shall allow MI-10 [HIGH] The CDNI Metadata interface shall allow association of
association of CDNI Metadata at the granularity of an object CDNI Metadata at the granularity of an object set. This is
set. This is necessary to achieve scalable distribution of necessary to achieve scalable distribution of metadata when a
metadata when a large number of objects share the same large number of objects share the same distribution policy.
distribution policy.
MI-11 [HIGH] The CDNI Metadata Distribution interface shall support MI-11 [HIGH] The CDNI Metadata interface shall support multiple
multiple levels of inheritance with precedence to more levels of inheritance with precedence to more specific
specific metadata. For example, the CDNI Metadata metadata. For example, the CDNI Metadata Distribution
Distribution protocol may support metadata that is applicable protocol may support metadata that is applicable to any
to any content, metadata that is applicable to a content content, metadata that is applicable to a content collection
collection and metadata that is applicable to an individual and metadata that is applicable to an individual content where
content where content level metadata overrides content content level metadata overrides content collection metadata
collection metadata that overrides metadata for any content. that overrides metadata for any content.
MI-12 [HIGH] The CDNI Metadata Distribution interface shall ensure MI-12 [HIGH] The CDNI Metadata interface shall ensure that
that conflicting metadata with overlapping scope are prevented conflicting metadata with overlapping scope are prevented or
or deterministically handled. deterministically handled.
MI-13 [HIGH] The CDNI Metadata Distribution interface shall allow MI-13 [HIGH] The CDNI Metadata interface shall allow signaling of
signaling of content distribution control policies. For content distribution control policies. For example, this
example, this could potentially include: could potentially include:
* geo-blocking information (i.e. Information defining * geo-blocking information (i.e. Information defining
geographical areas where the content is to be made geographical areas where the content is to be made
available or blocked) available or blocked)
* availability windows (i.e. Information defining time * availability windows (i.e. Information defining time
windows during which the content is to be made available windows during which the content is to be made available
or blocked; expiration time may also be included to remove or blocked; expiration time may also be included to remove
content) content)
skipping to change at page 16, line 34 skipping to change at page 17, line 34
through) through)
MI-14 [HIGH] The CDNI Metadata interface shall be able to exchange a MI-14 [HIGH] The CDNI Metadata interface shall be able to exchange a
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 interface shall allow signaling of
signaling of authorization checks and validation that are to authorization checks and validation that are to be performed
be performed by the surrogate before delivery. For example, by the surrogate before delivery. For example, this could
this could potentially including the need to validate URI potentially including the need to validate URI signed
signed information (e.g. Expiry time, Client IP address). information (e.g. Expiry time, Client IP address).
MI-17 [MED] The CDNI Metadata Distribution interface should allow MI-17 [MED] The CDNI Metadata interface should allow signaling of
signaling of CDNI-relevant surrogate cache behavior CDNI-relevant surrogate cache behavior parameters. For
parameters. For example, this could potentially include: 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
(e.g. "Expires" field) (e.g. "Expires" field)
* rate-pacing by Downstream CDN for content delivery (e.g. * rate-pacing by Downstream CDN for content delivery (e.g.
Progressive Download) Progressive Download)
skipping to change at page 17, line 23 skipping to change at page 18, line 23
* local file management and storage bundles all the files * local file management and storage bundles all the files
for the content for the content
* purging the entire set of files associated with the * purging the entire set of files associated with the
content content
* logging of the delivery of the content for the session * logging of the delivery of the content for the session
when at least one file in the set was delivered when at least one file in the set was delivered
MI-19 [MED] The CDNI Metadata Distribution interface should support MI-19 [MED] The CDNI Metadata interface should support an optional
an OPTIONAL mechanism allowing the Upstream CDN to indicate to mechanism allowing the Upstream CDN to indicate to the
the Downstream CDN which CDNI Log fields are to be provided Downstream CDN which CDNI Log fields are to be provided for
for all, for specific sets of, or for specific content items all, for specific sets of, or for specific content items
delivered using HTTP. A CDNI implementation that does not delivered using HTTP. A CDNI implementation that does not
support this optional CDNI Metadata Distribution Interface support this optional CDNI Metadata Distribution Interface
mechanism shall ignore this log format indication and generate mechanism shall ignore this log format indication and generate
CDNI logging format for HTTP Adaptive Streaming using the CDNI logging format for HTTP Adaptive Streaming using the
default set of CDNI Logging fields. (Note: this function is default set of CDNI Logging fields. (Note: this function is
not concluded to be in Metadata Interface or Control not concluded to be in Metadata Interface or Control
Interface) Interface)
MI-20 [MED] The CDNI Metadata Distribution interface should allow MI-20 [MED] The CDNI Metadata interface should allow the Upstream
the Upstream CDN to signal to the Downstream CDN the Content CDN to signal to the Downstream CDN the Content Collection ID
Collection ID value for all, for specific sets of, or for value for all, for specific sets of, or for specific content
specific content items delivered using HTTP. Whenever the items delivered using HTTP. Whenever the Downstream CDN is
Downstream CDN is instructed by the Upstream CDN to report the instructed by the Upstream CDN to report the Content
Content Collection ID field in the log records, the Downstream Collection ID field in the log records, the Downstream CDN is
CDN is to use the value provided through the CDNI Metadata to use the value provided through the CDNI Metadata interface
interface for the corresponding content. Note the Session ID for the corresponding content. Note the Session ID field
field along with Content Collection ID may be used for HTTP along with Content Collection ID may be used for HTTP Adaptive
Adaptive Streaming content. Streaming content.
MI-21 [MED] The CDNI Metadata Distribution interface should allow MI-21 [MED] The CDNI Metadata interface should allow the Upstream
the Upstream CDN to signal to the Downstream CDN the CDN to signal to the Downstream CDN the Authorization Group ID
Authorization Group ID value for all the related HTTP Adaptive value for all the related HTTP Adaptive Streaming content
Streaming content (i.e. manifest file and chunks). The (i.e. manifest file and chunks). The authorization result of
authorization result of a content (e.g. manifest file) is a content (e.g. manifest file) is transferred over to related
transferred over to related content (e.g. chunks). content (e.g. chunks).
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 22, line 6 skipping to change at page 23, line 6
[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
input. Serge Manning along with Robert Streijl, Vishwa Prasad, Percy input. Serge Manning along with Robert Streijl, Vishwa Prasad, Percy
Tarapore, Mike Geller, and Ramki Krishnan contributed to this Tarapore, Mike Geller, and Ramki Krishnan contributed to this
document by addressing the requirements of the ATIS Cloud Services document by addressing the requirements of the ATIS Cloud Services
Forum. Forum.
Ray Brandenburg, Matt Caufield, and Francois Le Faucheur/Gilles Ray Brandenburg, Matt Caufield, and Gilles Bertrand provided valuable
Bertrand provided valuable inputs for HTTP Adaptive Streaming, CDNI inputs for HTTP Adaptive Streaming, CDNI Metadata interface, and CDNI
Metadata interface, and CDNI Logging interface, respectively. Logging interface, respectively.
14. Appendix: Requirements Mapping
The labels and numbers changed in version 6 of this document as part
of the requirements cleanup and structuring changes due to
introduction of the new CDNI request routing/Redirection Interface
and CDNI request routing/Footprint & Capabilities advertisement
interface. There are some CDNI drafts that have referenced the
requirements in this document. Therefore, the following table
provides the mapping of the requirement label and numbering.
+--------------------+-------------------------------+
| Version 5 | Version 6 |
+--------------------+-------------------------------+
| GEN-13 | Removed |
| GEN-14 | GEN-13 |
| CNTL-# | CI-# (label changed) |
| CNTL-1 | CI-1 and CI-3 |
| CNTL-2 to CNTL-9 | CI-4 to CI-11 |
| CNTL-10 | FCI-6 |
| CNTL-11 | CI-12 |
| CNTL-12 | CI-2 |
| REQ-# | RI-# or FCI-# (label changed) |
| REQ-1 to REQ-4 | FCI-1 to FCI-4 |
| REQ-5 to REQ-19 | RI-1 to RI-15 |
| REQ-20 | FCI-5 |
| META-# | MI-# (label changed) |
| META-13 | Removed |
| META-14 to META-22 | MI-13 to MI-21 |
| LOG-# | LI-# (label changed) |
| LOG-4 | Removed |
| LOG-5 to LOG-18 | LI-4 to LI-17 |
+--------------------+-------------------------------+
Requirement Reference Mapping Table 14. References
15. References 14.1. Normative References
15.1. Normative References
[RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content
Distribution Network Interconnection (CDNI) Problem Distribution Network Interconnection (CDNI) Problem
Statement", RFC 6707, September 2012. Statement", RFC 6707, September 2012.
15.2. Informative References 14.2. Informative References
[I-D.amini-cdi-distribution-reqs] [I-D.amini-cdi-distribution-reqs]
Amini, L., "Distribution Requirements for Content Amini, L., "Distribution Requirements for Content
Internetworking", draft-amini-cdi-distribution-reqs-02 Internetworking", draft-amini-cdi-distribution-reqs-02
(work in progress), November 2001. (work in progress), November 2001.
[I-D.cain-request-routing-req] [I-D.cain-request-routing-req]
Cain, B., "Request Routing Requirements for Content Cain, B., "Request Routing Requirements for Content
Internetworking", draft-cain-request-routing-req-03 (work Internetworking", draft-cain-request-routing-req-03 (work
in progress), November 2001. in progress), November 2001.
[I-D.gilletti-cdnp-aaa-reqs] [I-D.gilletti-cdnp-aaa-reqs]
"CDI AAA Requirements, "CDI AAA Requirements,
draft-gilletti-cdnp-aaa-reqs-01.txt", June 2001. draft-gilletti-cdnp-aaa-reqs-01.txt", June 2001.
[I-D.ietf-cdni-framework] [I-D.ietf-cdni-framework]
Peterson, L. and B. Davie, "Framework for CDN Peterson, L. and B. Davie, "Framework for CDN
Interconnection", draft-ietf-cdni-framework-03 (work in Interconnection", draft-ietf-cdni-framework-05 (work in
progress), February 2013. progress), September 2013.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC6770] Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma, [RFC6770] Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma,
K., and G. Watson, "Use Cases for Content Delivery Network K., and G. Watson, "Use Cases for Content Delivery Network
Interconnection", RFC 6770, November 2012. Interconnection", RFC 6770, November 2012.
Authors' Addresses Authors' Addresses
 End of changes. 62 change blocks. 
272 lines changed or deleted 271 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/