draft-ietf-cdni-framework-00.txt   draft-ietf-cdni-framework-01.txt 
Network Working Group L. Peterson, Ed. Network Working Group L. Peterson, Ed.
Internet-Draft Verivue, Inc. Internet-Draft Verivue, Inc.
Intended status: Informational B. Davie Obsoletes: 3466 (if approved) B. Davie
Expires: October 29, 2012 Nicira Networks, Inc. Intended status: Informational Nicira Networks, Inc.
April 27, 2012 Expires: January 17, 2013 July 16, 2012
Framework for CDN Interconnection Framework for CDN Interconnection
draft-ietf-cdni-framework-00 draft-ietf-cdni-framework-01
Abstract Abstract
This document presents a framework for Content Distribution Network This document presents a framework for Content Distribution Network
Interconnection (CDNI). The purpose of the framework is to provide Interconnection (CDNI). The purpose of the framework is to provide
an overall picture of the problem space of CDNI and to describe the an overall picture of the problem space of CDNI and to describe the
relationships among the various components necessary to interconnect relationships among the various components necessary to interconnect
CDNs. CDN Interconnection requires the specification of several CDNs. CDN Interconnection requires the specification of several
interfaces and mechanisms to address issues such as request routing, interfaces and mechanisms to address issues such as request routing,
metadata exchange, and the acquisition of content by one CDN from metadata exchange, and the acquisition of content by one CDN from
another. The intent of this document is to outline what each another. The intent of this document is to outline what each
interface needs to accomplish, and to describe how these interfaces interface needs to accomplish, and to describe how these interfaces
and mechanisms fit together, while leaving their detailed and mechanisms fit together, while leaving their detailed
specification to other documents. specification to other documents. It obsoletes RFC 3466.
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 29, 2012. This Internet-Draft will expire on January 17, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 28 skipping to change at page 3, line 28
3.2.1. Comments on the example . . . . . . . . . . . . . . . 18 3.2.1. Comments on the example . . . . . . . . . . . . . . . 18
3.3. Recursive Redirection Example . . . . . . . . . . . . . . 19 3.3. Recursive Redirection Example . . . . . . . . . . . . . . 19
3.3.1. Comments on the example . . . . . . . . . . . . . . . 23 3.3.1. Comments on the example . . . . . . . . . . . . . . . 23
3.4. DNS-based redirection example . . . . . . . . . . . . . . 23 3.4. DNS-based redirection example . . . . . . . . . . . . . . 23
3.4.1. Comments on the example . . . . . . . . . . . . . . . 26 3.4.1. Comments on the example . . . . . . . . . . . . . . . 26
3.5. Dynamic Footprint Discovery . . . . . . . . . . . . . . . 27 3.5. Dynamic Footprint Discovery . . . . . . . . . . . . . . . 27
3.6. Content Removal . . . . . . . . . . . . . . . . . . . . . 29 3.6. Content Removal . . . . . . . . . . . . . . . . . . . . . 29
3.7. Pre-Positioned Content Acquisition Example . . . . . . . . 29 3.7. Pre-Positioned Content Acquisition Example . . . . . . . . 29
3.8. Asynchronous CDNI Metadata Example . . . . . . . . . . . . 31 3.8. Asynchronous CDNI Metadata Example . . . . . . . . . . . . 31
3.9. Synchronous CDNI Metadata Acquisition Example . . . . . . 33 3.9. Synchronous CDNI Metadata Acquisition Example . . . . . . 33
4. Main Interfaces . . . . . . . . . . . . . . . . . . . . . . . 36 3.10. Content Acquisition with Multiple Upstream CDNs . . . . . 36
4.1. In-Band versus Out-of-Band Interfaces . . . . . . . . . . 36 4. Main Interfaces . . . . . . . . . . . . . . . . . . . . . . . 37
4.2. Request Routing Interface . . . . . . . . . . . . . . . . 37 4.1. In-Band versus Out-of-Band Interfaces . . . . . . . . . . 37
4.3. Logging Interface . . . . . . . . . . . . . . . . . . . . 38 4.2. Cross Interface Concerns . . . . . . . . . . . . . . . . . 38
4.4. Control Interface . . . . . . . . . . . . . . . . . . . . 40 4.3. Request Routing Interface . . . . . . . . . . . . . . . . 38
4.5. Metadata Interface . . . . . . . . . . . . . . . . . . . . 41 4.4. Logging Interface . . . . . . . . . . . . . . . . . . . . 40
5. Deployment Models . . . . . . . . . . . . . . . . . . . . . . 42 4.5. Control Interface . . . . . . . . . . . . . . . . . . . . 42
5.1. Meshed CDNs . . . . . . . . . . . . . . . . . . . . . . . 42 4.6. Metadata Interface . . . . . . . . . . . . . . . . . . . . 42
5.2. CSP combined with CDN . . . . . . . . . . . . . . . . . . 43 5. Deployment Models . . . . . . . . . . . . . . . . . . . . . . 43
5.3. CSP using CDNI Request Routing Interface . . . . . . . . . 44 5.1. Meshed CDNs . . . . . . . . . . . . . . . . . . . . . . . 44
5.4. CDN Federations and CDN Exchanges . . . . . . . . . . . . 45 5.2. CSP combined with CDN . . . . . . . . . . . . . . . . . . 44
6. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 48 5.3. CSP using CDNI Request Routing Interface . . . . . . . . . 45
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 5.4. CDN Federations and CDN Exchanges . . . . . . . . . . . . 46
8. Security Considerations . . . . . . . . . . . . . . . . . . . 49 6. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 49
8.1. Security of CDNI Interfaces . . . . . . . . . . . . . . . 50 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50
8.2. Digital Rights Management . . . . . . . . . . . . . . . . 51 8. Security Considerations . . . . . . . . . . . . . . . . . . . 50
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 51 8.1. Security of CDNI Interfaces . . . . . . . . . . . . . . . 51
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 51 8.2. Digital Rights Management . . . . . . . . . . . . . . . . 52
11. Informative References . . . . . . . . . . . . . . . . . . . . 51 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 52
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 53 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 52
11. Informative References . . . . . . . . . . . . . . . . . . . . 52
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 54
1. Introduction 1. Introduction
The interconnection of Content Distribution Networks (CDNs) is The interconnection of Content Distribution Networks (CDNs) is
motivated by several use cases, such as those described in motivated by several use cases, such as those described in
[I-D.ietf-cdni-use-cases]. The overall problem space for CDN [I-D.ietf-cdni-use-cases]. The overall problem space for CDN
Interconnection is described in [I-D.ietf-cdni-problem-statement]. Interconnection is described in [I-D.ietf-cdni-problem-statement].
The purpose of this document is to provide an overview of the various The purpose of this document is to provide an overview of the various
components necessary to interconnect CDNs. CDN Interconnection components necessary to interconnect CDNs. CDN Interconnection
requires the specification of several interfaces and mechanisms to requires the specification of several interfaces and mechanisms to
address issues such as request routing, metadata exchange, and the address issues such as request routing, metadata exchange, and the
acquisition of content by one CDN from another. The intent of this acquisition of content by one CDN from another. The intent of this
document is to describe how these interfaces and mechanisms fit document is to describe how these interfaces and mechanisms fit
together, leaving their detailed specification to other documents. together, leaving their detailed specification to other documents.
We make extensive use of message flow examples to illustrate the We make extensive use of message flow examples to illustrate the
operation of interconnected CDNs, but these examples should be operation of interconnected CDNs, but these examples should be
considered illustrative rather than prescriptive. considered illustrative rather than prescriptive.
1.1. Terminology RFC 3466 uses different terminology and models for "Content
Internetworking (CDI)". It is also less prescriptive in terms of
interfaces. To avoid confusion, this document obsoletes RFC 3466.
This document draws freely on the terminology defined in [RFC3466] 1.1. Terminology
and [I-D.ietf-cdni-problem-statement].
We also introduce the following terms: This document draws freely on the core terminology defined in
[I-D.ietf-cdni-problem-statement]. It also introduce the following
terms:
CDN Domain: a host name (FQDN) at the beginning of a URL, CDN Domain: a host name (FQDN) at the beginning of a URL,
representing a set of content that is served by a given CDN. For representing a set of content that is served by a given CDN. For
example, in the URL http://cdn.csp.com/...rest of url..., the CDN example, in the URL http://cdn.csp.com/...rest of url..., the CDN
domain is cdn.csp.com. domain is cdn.csp.com. A major role of CDN Domain is to identify a
region (subset) of the URI space relative to which various CDN
Interconnection rules and policies are to apply. For example, a
record of CDN Metadata might be defined for the set of resources
corresponding to some CDN Domain.
Distinguished CDN Domain: a CDN domain that is allocated by a CDN for Distinguished CDN Domain: a CDN domain that is allocated by a CDN for
the purposes of communication with a peer CDN, but which is not found the purposes of communication with a peer CDN, but which is not found
in client requests. Such CDN domains may be used for inter-CDN in client requests. Such CDN domains may be used for inter-CDN
acquisition, or as redirection targets, and enable a CDN to acquisition, or as redirection targets, and enable a CDN to
distinguish a request from a peer CDN from an end-user request. distinguish a request from a peer CDN from an end-user request.
Delivering CDN: the CDN that ultimately delivers a piece of content
to the end-user. The last in a potential sequence of downstream
CDNs.
Recursive CDNI request routing: When an Upstream CDN elects to Recursive CDNI request routing: When an Upstream CDN elects to
redirect a request towards a Downstream CDN, the Upstream CDN can redirect a request towards a Downstream CDN, the Upstream CDN can
query the Downstream CDN Request Routing system via the CDNI Request query the Downstream CDN Request Routing system via the CDNI Request
Routing interface (or use information cached from earlier similar Routing interface (or use information cached from earlier similar
queries) to find out how the Downstream CDN wants the request to be queries) to find out how the Downstream CDN wants the request to be
redirected, which allows the Upstream CDN to factor in the Downstream redirected, which allows the Upstream CDN to factor in the Downstream
CDN response when redirecting the user agent. This approach is CDN response when redirecting the user agent. This approach is
referred to as "recursive" CDNI request routing. Note that the referred to as "recursive" CDNI request routing. Note that the
Downstream CDN may elect to have the request redirected directly to a Downstream CDN may elect to have the request redirected directly to a
Surrogate inside the Downstream CDN, to the Request-Routing System of Surrogate inside the Downstream CDN, to the Request-Routing System of
skipping to change at page 36, line 5 skipping to change at page 36, line 5
required. required.
10. Operator A's CDN responds to the CDNI Metadata Request and makes 10. Operator A's CDN responds to the CDNI Metadata Request and makes
the corresponding CDNI metadata available to Operator B. This the corresponding CDNI metadata available to Operator B. This
metadata influence how Operator B's CDN processes the end-user metadata influence how Operator B's CDN processes the end-user
request. request.
11. Content is served (possibly preceded by inter-CDN acquisition) 11. Content is served (possibly preceded by inter-CDN acquisition)
as in Section 3.3. as in Section 3.3.
3.10. Content Acquisition with Multiple Upstream CDNs
A single dCDN may receive end-user requests from multiple uCDNs.
When a dCDN receives an end-user request, it must determine the
identity of the uCDN from which it should acquire the requested
content.
Ideally, the acquisition path of an end-user request will follow the
redirection path of the request. The dCDN should acquire the content
from the same uCDN which redirected the request.
Determining the acquisition path requires the dCDN to reconstruct the
redirection path based on information in the end-user request. The
method for reconstructing the redirection path differs based on the
redirection approach: HTTP or DNS.
With HTTP-redirection, the rewritten URI must include sufficient
information for the dCDN to directly or indirectly determine the uCDN
when the end-user request is received. The HTTP-redirection approach
can be further broken-down based on the how the URL is rewritten
during redirection: HTTP-redirection with or without Site
Aggregation. HTTP-redirection with Site Aggregation hides the
identity of the original CSP. HTTP-redirection without Site
Aggregation does not attempt to hide the identity of the original
CSP. With both approaches, the rewritten URI must include enough
information to identify the immediate neighbor uCDN.
With DNS-redirection, the dCDN receives the published URI (instead of
a rewritten URI) and does not have sufficient information for the
dCDN to identify the appropriate uCDN. Given that the dCDN has
established a business relationship with each of its uCDNs, assume
that the dCDN can trust any uCDN to acquire the content. The dCDN
may narrow the set of viable uCDNs by examining the CDNI metadata
from each to determine which uCDNs are hosting metadata for the
requested content.
Content acquisition may be preceded by content metadata acquisition.
If possible, the acquisition path for metadata should also follow the
redirection path. Additionally, metadata must be indexed based on
rewritten URIs in the case of HTTP-redirection and must be indexed
based on published URIs in the case of DNS-redirection. Thus, the
request routing interface and the metadata interface are tightly c
coupled in that the result of request routing (a rewritten URI
pointing to the dCDN) must serve as a input to metadata lookup. If
the content metadata includes information for acquiring the content,
then the metadata interface is also tightly coupled with the
acquisition interface in that the result of the metadata lookup (an
acquisition URL likely hosted by the uCDN) should serve as input to
the content acquisition.
4. Main Interfaces 4. Main Interfaces
Figure 1 illustrates the four main interfaces that are in scope for Figure 1 illustrates the four main interfaces that are in scope for
the CDNI WG, along with several others. The detailed specifications the CDNI WG, along with several others. The detailed specifications
of these interfaces are left to other documents (mostly still to be of these interfaces are left to other documents (mostly still to be
written, but see [I-D.ietf-cdni-problem-statement] and written, but see [I-D.ietf-cdni-problem-statement] and
[I-D.ietf-cdni-requirements] for some discussion of the interfaces). [I-D.ietf-cdni-requirements] for some discussion of the interfaces).
One interface that is not shown in Figure 1 is the interface between One interface that is not shown in Figure 1 is the interface between
the user and the CSP. While for the purposes of CDNI that interface the user and the CSP. While for the purposes of CDNI that interface
skipping to change at page 37, line 9 skipping to change at page 38, line 12
There are other opportunities for in-band communication beyond HTTP There are other opportunities for in-band communication beyond HTTP
redirects. For example, many of the HTTP directives used by proxy redirects. For example, many of the HTTP directives used by proxy
servers can also be used by peer CDNs to inform each other of caching servers can also be used by peer CDNs to inform each other of caching
activity. Of these, one that is particularly relevant is the If- activity. Of these, one that is particularly relevant is the If-
Modified-Since directive, which is used with the GET method to make Modified-Since directive, which is used with the GET method to make
it conditional: if the requested object has not been modified since it conditional: if the requested object has not been modified since
the time specified in this field, a copy of the object will not be the time specified in this field, a copy of the object will not be
returned, and instead, a 304 (not modified) response will be returned, and instead, a 304 (not modified) response will be
returned. returned.
4.2. Request Routing Interface 4.2. Cross Interface Concerns
Although the CDNI interfaces are largely independent, there are a set
of conventions practiced consistently across all interfaces. Most
important among these is how resources are named, for exampmle, how
the Metadata and Control interfaces identify the set of resources to
which a given directive applies, or the Logging interface identifies
the set of resources for which a summary record applies.
While in the the limit the CDNI interfaces could explicitly identify
every individual resource, in practice, they name resource aggregates
(sets of URIs) that are to be treated in a similar way. For example,
URI aggregates can be identified by a CDN-Domain (i.e., the FQDN at
the beginning of a URI) or by a URI-Filter (i.e., a regular
expression that matches a subset of URIs contained in some CDN-
Doman). In other words, CDN-Domains and URI-Filters provide a
uniform means to aggregate sets (and subsets) of URIs for the purpose
of defining the scope for some operation in one of the CDNI
interfaces.
4.3. Request Routing Interface
We may think of the request routing interface as comprising two We may think of the request routing interface as comprising two
parts: the asynchronous advertisement of footprint and capabilities parts: the asynchronous advertisement of footprint and capabilities
by a dCDN that allows a uCDN to decide whether to redirect particular by a dCDN that allows a uCDN to decide whether to redirect particular
user requests to that dCDN; and the synchronous operation of actually user requests to that dCDN; and the synchronous operation of actually
redirecting a user request. (These are somewhat analogous to the redirecting a user request. (These are somewhat analogous to the
operations of routing and forwarding in IP.) operations of routing and forwarding in IP.)
As illustrated in Section 3, the synchronous part of the request As illustrated in Section 3, the synchronous part of the request
routing interface may be implemented in part by DNS and HTTP. Naming routing interface may be implemented in part by DNS and HTTP. Naming
skipping to change at page 38, line 38 skipping to change at page 40, line 11
dCDN with only a single redirection step (as seen by the user). This dCDN with only a single redirection step (as seen by the user). This
may be particularly valuable as the chain of interconnected CDNs may be particularly valuable as the chain of interconnected CDNs
increases beyond two CDNs. increases beyond two CDNs.
One final issue is how HTTP adaptive streaming impacts the Request One final issue is how HTTP adaptive streaming impacts the Request
Routing interface, and in particular, the interplay between the Routing interface, and in particular, the interplay between the
request router and manifest files, which may contain either absolute request router and manifest files, which may contain either absolute
or relative URLs. These issues are discussed in more detail in or relative URLs. These issues are discussed in more detail in
[I-D.brandenburg-cdni-has]. [I-D.brandenburg-cdni-has].
4.3. Logging Interface 4.4. Logging Interface
It is necessary for the upstream CDN to have visibility into the It is necessary for the upstream CDN to have visibility into the
delivery of content it originates to end-users connected to the delivery of content it originates to end-users connected to the
downstream CDN. This allows the upstream CDN to properly bill its downstream CDN. This allows the upstream CDN to properly bill its
customers for multiple deliveries of content cached by the downstream customers for multiple deliveries of content cached by the downstream
CDN, as well as to report accurate traffic statistics to those CDN, as well as to report accurate traffic statistics to those
content providers. This is one role of the Logging interface. content providers. This is one role of the Logging interface.
Other operational data that may be relevant to CDNI can also be Other operational data that may be relevant to CDNI can also be
exchanged by the Logging interface. For example, dCDN may report the exchanged by the Logging interface. For example, dCDN may report the
skipping to change at page 40, line 45 skipping to change at page 42, line 18
adaptive streaming are discussed further in adaptive streaming are discussed further in
[I-D.brandenburg-cdni-has]. [I-D.brandenburg-cdni-has].
Other forms of aggregation may also be useful. For example, there Other forms of aggregation may also be useful. For example, there
may be situations where bulk metrics such as bytes delivered per hour may be situations where bulk metrics such as bytes delivered per hour
may suffice rather than the detailed per-request logs outlined above. may suffice rather than the detailed per-request logs outlined above.
It seems likely that a range of granularities of logging will be It seems likely that a range of granularities of logging will be
needed along with ways to specify the type and degree of aggregation needed along with ways to specify the type and degree of aggregation
required. required.
4.4. Control Interface 4.5. Control Interface
The control interface is initially used to bootstrap the other The control interface is initially used to bootstrap the other
interfaces. As a simple example, it could be used to provide the interfaces. As a simple example, it could be used to provide the
address of the logging server in dCDN to uCDN in order to bootstrap address of the logging server in dCDN to uCDN in order to bootstrap
the logging interface. It may also be used, for example, to the logging interface. It may also be used, for example, to
establish security associations for the other interfaces. establish security associations for the other interfaces.
The other role the Control interface plays is to allow the uCDN to The other role the Control interface plays is to allow the uCDN to
pre-position, revalidate, or purge metadata and content on a dCDN. pre-position, revalidate, or purge metadata and content on a dCDN.
These operations, sometimes collectively called the trigger These operations, sometimes collectively called the trigger
interface, are discussed further in [I-D.murray-cdni-triggers]. interface, are discussed further in [I-D.murray-cdni-triggers].
4.5. Metadata Interface 4.6. Metadata Interface
The role of the metadata interface is to enable CDNI distribution The role of the metadata interface is to enable CDNI distribution
metadata to be conveyed to the downstream CDN by the upstream CDN. metadata to be conveyed to the downstream CDN by the upstream CDN.
For example, see [I-D.ma-cdni-metadata] and For example, see [I-D.ma-cdni-metadata] and
[I-D.caulfield-cdni-metadata-core]. Such metadata includes geo- [I-D.cjlmw-cdni-metadata]. Such metadata includes geo-blocking
blocking restrictions, availability windows, access control policies, restrictions, availability windows, access control policies, and so
and so on. It may also include policy information such as the desire on. It may also include policy information such as the desire to
to pre-position content rather than fetch it on demand. pre-position content rather than fetch it on demand.
Some metadata may be able to be conveyed using in-band mechanisms. Some metadata may be able to be conveyed using in-band mechanisms.
For example, to inform the downstream CDN of any geo-blocking For example, to inform the downstream CDN of any geo-blocking
restrictions or availability windows, the upstream can elect to restrictions or availability windows, the upstream can elect to
redirect a request to the downstream CDN only if that CDN's redirect a request to the downstream CDN only if that CDN's
advertised delivery footprint is acceptable for the requested URL. advertised delivery footprint is acceptable for the requested URL.
Similarly, the request could be forwarded only if the current time is Similarly, the request could be forwarded only if the current time is
within the availability window. within the availability window.
Similarly, some forms of access control may also be performed on a Similarly, some forms of access control may also be performed on a
skipping to change at page 51, line 23 skipping to change at page 52, line 23
distribute encrypted content, with decryption keys distributed to distribute encrypted content, with decryption keys distributed to
users by some other means (e.g. directly from the CSP to the end users by some other means (e.g. directly from the CSP to the end
user.) For this reason, DRM is considered out of scope for the CDNI user.) For this reason, DRM is considered out of scope for the CDNI
WG [I-D.ietf-cdni-problem-statement] and does not introduce WG [I-D.ietf-cdni-problem-statement] and does not introduce
additional security issues for CDNI. additional security issues for CDNI.
9. Contributors 9. Contributors
The following individuals contributed to this document: The following individuals contributed to this document:
o Matt Caulfield
o Francois le Faucheur o Francois le Faucheur
o Aaron Falk o Aaron Falk
o David Ferguson o David Ferguson
o John Hartman o John Hartman
o Ben Niven-Jenkins o Ben Niven-Jenkins
o Kent Leung
10. Acknowledgements 10. Acknowledgements
We thank Huw Jones for their helpful input to the draft. We thank Huw Jones for helpful input to the draft.
11. Informative References 11. Informative References
[I-D.bertrand-cdni-logging] [I-D.bertrand-cdni-logging]
Bertrand, G. and S. Emile, "CDNI Logging Interface", Bertrand, G. and S. Emile, "CDNI Logging Interface",
draft-bertrand-cdni-logging-00 (work in progress), draft-bertrand-cdni-logging-00 (work in progress),
February 2012. February 2012.
[I-D.brandenburg-cdni-has] [I-D.brandenburg-cdni-has]
Brandenburg, R., "Models for adaptive-streaming-aware CDN Brandenburg, R., Deventer, O., Faucheur, F., and K. Leung,
Interconnection", draft-brandenburg-cdni-has-00 (work in "Models for adaptive-streaming-aware CDN Interconnection",
progress), February 2012. draft-brandenburg-cdni-has-03 (work in progress),
July 2012.
[I-D.caulfield-cdni-metadata-core] [I-D.cjlmw-cdni-metadata]
Leung, K. and M. Caulfield, "Content Distribution Network Niven-Jenkins, B., Murray, R., Watson, G., Caulfield, M.,
Interconnection (CDNI) Core Metadata", and K. Leung, "CDN Interconnect Metadata",
draft-caulfield-cdni-metadata-core-00 (work in progress), draft-cjlmw-cdni-metadata-00 (work in progress),
October 2011. July 2012.
[I-D.ietf-cdni-problem-statement] [I-D.ietf-cdni-problem-statement]
Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content
Distribution Network Interconnection (CDNI) Problem Distribution Network Interconnection (CDNI) Problem
Statement", draft-ietf-cdni-problem-statement-04 (work in Statement", draft-ietf-cdni-problem-statement-08 (work in
progress), March 2012. progress), June 2012.
[I-D.ietf-cdni-requirements] [I-D.ietf-cdni-requirements]
Leung, K. and Y. Lee, "Content Distribution Network Leung, K. and Y. Lee, "Content Distribution Network
Interconnection (CDNI) Requirements", Interconnection (CDNI) Requirements",
draft-ietf-cdni-requirements-02 (work in progress), draft-ietf-cdni-requirements-03 (work in progress),
December 2011. June 2012.
[I-D.ietf-cdni-use-cases] [I-D.ietf-cdni-use-cases]
Bertrand, G., Emile, S., Watson, G., Burbridge, T., Bertrand, G., Emile, S., Burbridge, T., Eardley, P., Ma,
Eardley, P., and K. Ma, "Use Cases for Content Delivery K., and G. Watson, "Use Cases for Content Delivery Network
Network Interconnection", draft-ietf-cdni-use-cases-04 Interconnection", draft-ietf-cdni-use-cases-09 (work in
(work in progress), March 2012. progress), July 2012.
[I-D.lefaucheur-cdni-logging-delivery] [I-D.lefaucheur-cdni-logging-delivery]
Faucheur, F., Viveganandhan, M., and K. Leung, "CDNI Faucheur, F., Viveganandhan, M., and K. Leung, "CDNI
Logging Formats for HTTP and HTTP Adaptive Streaming Logging Formats for HTTP and HTTP Adaptive Streaming
Deliveries", draft-lefaucheur-cdni-logging-delivery-00 Deliveries", draft-lefaucheur-cdni-logging-delivery-01
(work in progress), February 2012. (work in progress), July 2012.
[I-D.ma-cdni-metadata] [I-D.ma-cdni-metadata]
Ma, K., "Content Distribution Network Interconnection Ma, K., "Content Distribution Network Interconnection
(CDNI) Metadata Interface", draft-ma-cdni-metadata-02 (CDNI) Metadata Interface", draft-ma-cdni-metadata-03
(work in progress), April 2012. (work in progress), July 2012.
[I-D.murray-cdni-triggers] [I-D.murray-cdni-triggers]
Murray, R. and B. Niven-Jenkins, "CDN Interconnect Murray, R. and B. Niven-Jenkins, "CDN Interconnect
Triggers", draft-murray-cdni-triggers-00 (work in Triggers", draft-murray-cdni-triggers-00 (work in
progress), February 2012. progress), February 2012.
[I-D.previdi-cdni-footprint-advertisement] [I-D.previdi-cdni-footprint-advertisement]
Previdi, S., Faucheur, F., Faucheur, F., Medved, J., and Previdi, S., Faucheur, F., Faucheur, F., Medved, J., and
L. Faucheur, "CDNI Footprint Advertisement", L. Faucheur, "CDNI Footprint Advertisement",
draft-previdi-cdni-footprint-advertisement-01 (work in draft-previdi-cdni-footprint-advertisement-01 (work in
 End of changes. 26 change blocks. 
60 lines changed or deleted 148 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/