draft-ietf-cdni-footprint-capabilities-semantics-00.txt   draft-ietf-cdni-footprint-capabilities-semantics-01.txt 
CDNI J. Seedorf CDNI J. Seedorf
Internet-Draft NEC Internet-Draft NEC
Intended status: Informational J. Peterson Intended status: Informational J. Peterson
Expires: January 16, 2014 Neustar Expires: April 24, 2014 Neustar
S. Previdi S. Previdi
Cisco Cisco
R. van Brandenburg R. van Brandenburg
TNO TNO
K. Ma K. Ma
Azuki Systems, Inc. Azuki Systems, Inc.
July 15, 2013 October 21, 2013
CDNI Request Routing: Footprint and Capabilities Semantics CDNI Request Routing: Footprint and Capabilities Semantics
draft-ietf-cdni-footprint-capabilities-semantics-00 draft-ietf-cdni-footprint-capabilities-semantics-01
Abstract Abstract
This document tries to capture the semantics of the "Footprint and This document tries to capture the semantics of the "Footprint and
Capabilities Advertisement" part of the CDNI Request Routing Capabilities Advertisement" part of the CDNI Request Routing
interface, i.e. the desired meaning and what "Footprint and interface, i.e. the desired meaning and what "Footprint and
Capabilities Advertisement" is expected to offer within CDNI. The Capabilities Advertisement" is expected to offer within CDNI. The
discussion in this document has the goal to facilitate the choosing discussion in this document has the goal to facilitate the choosing
of one or more suitable protocols for "Footprint and Capabilities of one or more suitable protocols for "Footprint and Capabilities
Advertisement" within CDNI Request Routing. Advertisement" within CDNI Request Routing.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 16, 2014. This Internet-Draft will expire on April 24, 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
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 and scope . . . . . . . . . . . . . . . . . . . 2 1. Introduction and Scope . . . . . . . . . . . . . . . . . . . 2
2. CDNI FCI in existing CDNI Documents . . . . . . . . . . . . . 3 2. Design Decisions for Footprint and Capabilities . . . . . . . 4
3. Design Decisions for Footprint and Capabilities . . . . . . . 6 2.1. Advertising Limited Coverage . . . . . . . . . . . . . . 4
3.1. Advertising Limited Coverage . . . . . . . . . . . . . . 6 2.2. Capabilities and Dynamic Data . . . . . . . . . . . . . . 5
3.2. Capabilities and Dynamic Data . . . . . . . . . . . . . . 7 2.3. Advertisement versus Queries . . . . . . . . . . . . . . 6
3.3. Advertisement versus Queries . . . . . . . . . . . . . . 8 2.4. Avoiding or Handling 'cheating' dCDNs . . . . . . . . . . 6
3.4. Avoiding or Handling 'cheating' dCDNs . . . . . . . . . . 9 2.5. Focus on Main Use Cases may Simplify Things . . . . . . . 7
3.5. Focus on Main Use Cases may Simplify Things . . . . . . . 9 3. Main Use Case to Consider . . . . . . . . . . . . . . . . . . 7
4. Main Use Case to foster the Clarification of Semantics . . . 10 4. Semantics for Footprint Advertisement . . . . . . . . . . . . 8
5. Towards Semantics for Footprint Advertisement . . . . . . . . 10 5. Semantics for Capabilities Advertisement . . . . . . . . . . 10
6. Towards Semantics for Capabilities Advertisement . . . . . . 13 6. Negotiation of Support for Optional Types of
7. Open Issues and Questions . . . . . . . . . . . . . . . . . . 15 Footprint/Capabilities . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.1. Footprint Sub-Registry . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . 16 7.2. Protocol Sub-Registry . . . . . . . . . . . . . . . . . . 14
7.3. Redirection Mode Sub-Registry . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Acknowledgment . . . . . . . . . . . . . . . . . . . 17 Appendix A. Acknowledgment . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction and scope 1. Introduction and Scope
The CDNI working group is working on a set of protocols to enable the The CDNI working group is working on a set of protocols to enable the
interconnection of multiple CDNs to a CDN federation. This CDN- interconnection of multiple CDNs to a CDN federation. This CDN-
federation should serve multiple purposes, as discussed in [RFC6770], federation should serve multiple purposes, as discussed in [RFC6770],
for instance, to extend the reach of a given CDN to areas in the for instance, to extend the reach of a given CDN to areas in the
network which are not covered by this particular CDN. network which are not covered by this particular CDN.
The goal of this document is to achieve a clear understanding in the The goal of this document is to achieve a clear understanding in the
CDNI WG about the semantics associated with the CDNI Request Routing CDNI WG about the semantics associated with the CDNI Request Routing
Footprint & Capabilities Advertisement Interface (from now on Footprint & Capabilities Advertisement Interface (from now on
skipping to change at page 3, line 26 skipping to change at page 3, line 31
other, either directly or indirectly, and can exchange information other, either directly or indirectly, and can exchange information
amongst each other. amongst each other.
o The uCDN has received footprint and/or capability advertisements o The uCDN has received footprint and/or capability advertisements
from a set of dCDNs. Footprint advertisement and capability from a set of dCDNs. Footprint advertisement and capability
advertisement need not use the same underlying protocol. advertisement need not use the same underlying protocol.
o The upstream CDN (uCDN) receives the initial request-routing o The upstream CDN (uCDN) receives the initial request-routing
request from the endpoint requesting the resource. request from the endpoint requesting the resource.
This document is organized as follows. First, a recap of the
definition of "footprint and capabilities advertisement" in existing
documents is given, attempting to distill the apparent common
understanding of what the terms 'footprint' and 'capabilities' mean
in the context of CDNI. Then, the detailed semantics of the
footprint advertisement mechanism and the capability advertisement
mechanism will be discussed. Finally, open issues and questions to
be discussed in the CDNI WG will be listed.
2. CDNI FCI in existing CDNI Documents
Descriptions of the CDNI FCI interface are highlighted in the CDNI
Problem Statement [RFC6707], CDNI Use Cases [RFC6770], the CDNI draft
requirements [I-D.ietf-cdni-requirements], and the CDNI framework
draft [[I-D.ietf-cdni-framework]. An assessment of these
descriptions is highlighted in the subsequent sections where the
ambiguity associated with footprint and capabilities is examined.
The objective of this document is to clarify the meaning of footprint
and capability and define the semantics and method for which these
attributes are exchanged between two cooperating CDN's.
The CDNI Problem Statement [RFC6707] describes footprint and The CDNI Problem Statement [RFC6707] describes footprint and
capabilities advertisement as: "[enabling] a Request Routing function capabilities advertisement as: "[enabling] a Request Routing function
in an Upstream CDN to query a Request Routing function in a in an Upstream CDN to query a Request Routing function in a
Downstream CDN to determine if the Downstream CDN is able (and Downstream CDN to determine if the Downstream CDN is able (and
willing) to accept the delegated Content Request". In addition, the willing) to accept the delegated Content Request". In addition, the
draft says "the CDNI Request Routing interface is also expected to RFC says "the CDNI Request Routing interface is also expected to
enable a downstream CDN to provide to the upstream CDN (static or enable a downstream CDN to provide to the upstream CDN (static or
dynamic) information (e.g. resources, footprint, load) to facilitate dynamic) information (e.g. resources, footprint, load) to facilitate
selection of the downstream CDN by the upstream CDN request routing selection of the downstream CDN by the upstream CDN request routing
system when processing subsequent content requests from User Agents". system when processing subsequent content requests from User Agents".
It thus considers "resources" and "load" as capabilities to be It thus considers "resources" and "load" as capabilities to be
advertised by the downstream CDN. advertised by the downstream CDN.
The CDNI Use Cases document [RFC6770] describes capabilities as "... The range of different footprint definitions and possible
supported range of devices and User Agents or the supported range of capabilities is very broad. Attempting to define a comprehensive
delivery technologies". Examples for such capabilities given are advertisement solution quickly becomes intractable. The CDNI
specific delivery protocols, technology migration, and meeting a requirements draft [I-D.ietf-cdni-requirements] lists the specific
certain QoS. requirements for the CDNI Footprint & Capabilities Advertisement
Interface in order to disambiguate footprints and capabilities with
The CDNI requirements draft [I-D.ietf-cdni-requirements] lists respect to CDNI. This document attempts to distill the apparent
several requirements relevant for the "footprint and capabilities common understanding of what the terms 'footprint' and 'capabilities'
advertisement" part of the CDNI request routing interface. In mean in the context of CDNI, and detail the semantics of the
summary, the following requirements for the CDNI Request Routing footprint advertisement mechanism and the capability advertisement
Interface and general requirements are relevant for the understanding mechanism.
of the semantics of "footprint and capabilities advertisement":
o GEN-4 [HIGH], "The CDNI solution shall not require intra-CDN
information to be exposed to other CDNs for effective and
efficient delivery of the content. Examples of intra-CDN
information include surrogate topology, surrogate status, cached
content, etc."
o GEN-9 [MED], "The CDNI solution should support cascaded CDN
redirection (CDN1 redirects to CDN2 that redirects to CDN3) to an
arbitrary number of levels beyond the first level."
o GEN-10 [MED], "The CDNI solution should support an arbitrary
topology of interconnected CDNs (i.e. the CDN topology cannot be
restricted to a tree, a loop-free topology, etc.)."
o GEN-11 [HIGH], "The CDNI solution shall prevent looping of any
CDNI information exchange."
o REQ-1 [HIGH], allowing the downstream CDN "to communicate to the
Upstream CDN coarse information about the Downstream CDN ability
and/or willingness to handle requests from the Upstream CDN. For
example, this could potentially include a binary signal
("Downstream CDN ready/not-ready to take additional requests from
Upstream CDN") to be used in case of excessive load or failure
condition in the Downstream CDN."
o REQ-2 [MED], allowing the downstream CDN to communicate
capabilities such as supported content types and delivery
protocols, a set of metrics/attributes (e.g. Streaming bandwidth,
storage resources, distribution and delivery priority), a set of
affinities (e.g. Preferences, indication of distribution/delivery
fees), information to facilitate request redirection, as well as
footprint information (e.g. "layer-3 coverage").
o REQ-3 [MED], "In the case of cascaded redirection, the CDNI
Request-Routing interface shall allow the Downstream CDN to also
include in the information communicated to the Upstream CDN,
information on the capabilities, resources and affinities of CDNs
to which the Downstream CDN may (in turn) redirect requests
received by the Upstream CDN. In that case, the CDNI Request-
Routing interface shall prevent looping of such information
exchange."
o REQ-4 [LOW], allowing the downstream CDN to communicate "aggregate
information on CDNI administrative limits and policy" (e.g. the
maximum number of requests redirected by the Upstream CDN to be
served simultaneously by the Downstream CDN or maximum aggregate
volume of content (e.g. in Terabytes) to be delivered by the
Downstream CDN over a time period).
o REQ-11 [LOW], "The CDNI Request-Routing protocol may support a
mechanism allowing an Upstream CDN to avoid redirecting a request
to a Downstream CDN if that is likely to result in the total
redirection time exceeding some limit."
Note that in REQ-2 [MED] "Layer-3 coverage" is given as an example of
what "footprint" information might convey in the CDNI requirements
draft [I-D.ietf-cdni-requirements]. Also, note that REQ-3 [MED]
addresses cascaded (transitive) downstream CDNs. In such a case, a
downstream CDN needs to include (in its advertisement information
that it conveys to an upstream CDN) aggregate footprint and
capabilities information for any further transitive downstream CDNs.
Such information may be included implicitly (i.e. the cascaded dCDN
is oblivious to the uCDN), or explicitly (i.e. the cascaded dCDN of
the fact that there is a cascaded dCDN is visible to the uCDN). In
either case, logic is needed to process incoming footprint
information from a cascaded dCDN and decide if/how it is to be re-
advertised/aggregated when advertising footprint to an upstream CDN.
The CDNI framework draft [I-D.ietf-cdni-framework] describes a
"footprint" as in [I-D.previdi-cdni-footprint-advertisement],
consisting of two parts: 1) "a class of end user requests
(represented, for example, by a set of IP prefixes, or a geographic
region) that the dCDN is willing and able to serve directly, without
use of another dCDN", and 2) "the connectivity of the dCDN to other
CDNs that may be able to serve content to users on behalf of dCDN".
The term "connectivity" has recently been replaced with
"reachability" in [I-D.previdi-cdni-footprint-advertisement], and as
discussed above, "without use of another dCDN" may include aggregated
transitive dCDNs. Further examples for capabilities are "the ability
to handle certain types of content (e.g. specific streaming formats)
or quality of service (QoS)." Content handling capabilities
discussed in [I-D.ma-cdni-capabilities] include delivery and
acquisition protocols, redirection modes, and metadata related
capabilities (e.g., authorization algorithm).
From reading the various draft listed above, it is safe to conclude
that neither the term 'footprint' nor 'capabilities' has been clearly
and unambiguously defined in these documents and a very broad range
of potential capabilities is listed.
3. Design Decisions for Footprint and Capabilities 2. Design Decisions for Footprint and Capabilities
A large part of the difficulty in discussing the FCI lies in A large part of the difficulty in discussing the FCI lies in
understanding what exactly is meant when trying to define footprint understanding what exactly is meant when trying to define footprint
in terms of "coverage" or "reachability." While the operators of in terms of "coverage" or "reachability." While the operators of
CDNs pick strategic locations to situate caches, a cache with a CDNs pick strategic locations to situate caches, a cache with a
public IPv4 address is reachable by any endpoint on the Internet public IPv4 address is reachable by any endpoint on the Internet
unless some policy enforcement precludes the use of the cache. unless some policy enforcement precludes the use of the cache.
Some CDNs aspire to cover the entire world, which we will henceforth Some CDNs aspire to cover the entire world, which we will henceforth
call global CDNs. The footprint advertised by such a CDN in the CDNI call global CDNs. The footprint advertised by such a CDN in the CDNI
environment would, from a coverage or reachability perspective, environment would, from a coverage or reachability perspective,
presumably cover all prefixes. Potentially more interesting for CDNI presumably cover all prefixes. Potentially more interesting for CDNI
use cases, however, are CDNs that claim a more limited coverage, but use cases, however, are CDNs that claim a more limited coverage, but
seek to federate with other CDNs in order to create a single CDN seek to federate with other CDNs in order to create a single CDN
fabric which shares resources. fabric which shares resources.
Futhermore, not all capabilties need be footprint restricted. Futhermore, not all capabilities need be footprint restricted.
Depending upon the use case, the optimal semantics of "footprints Depending upon the use case, the optimal semantics of "footprints
with capability attributes" vs. "capabilities with footprint with capability attributes" vs. "capabilities with footprint
restrictions" are not clear. restrictions" are not clear.
The key to understanding the semantics of footprint and capability The key to understanding the semantics of footprint and capability
advertisement lies in understand why a dCDN would advertise a limited advertisement lies in understand why a dCDN would advertise a limited
coverage area, and how a uCDN would use such advertisements to decide coverage area, and how a uCDN would use such advertisements to decide
among one of several dCDNs. The following section will discuss some among one of several dCDNs. The following section will discuss some
of the trade-offs and design decisions that need to be decided upon of the trade-offs and design decisions that need to be decided upon
for the CDNI FCI. for the CDNI FCI.
3.1. Advertising Limited Coverage 2.1. Advertising Limited Coverage
The basic use case that would motivate a dCDN to advertise a limited The basic use case that would motivate a dCDN to advertise a limited
coverage is that the CDN was built to cover only a particular portion coverage is that the CDN was built to cover only a particular portion
of the Internet. For example, an ISP could purpose-build a CDN to of the Internet. For example, an ISP could purpose-build a CDN to
serve only their own customers by situating caches in close serve only their own customers by situating caches in close
topological proximity to high concentrations of their subscribers. topological proximity to high concentrations of their subscribers.
The ISP knows the prefixes it has allocated to end users and thus can The ISP knows the prefixes it has allocated to end users and thus can
easily construct a list of prefixes that its caches were positioned easily construct a list of prefixes that its caches were positioned
to serve. to serve.
skipping to change at page 7, line 44 skipping to change at page 5, line 32
their footprint advertise the IP addresses of their caches rather their footprint advertise the IP addresses of their caches rather
than prefix "coverage," and let the uCDN decide for itself (based on than prefix "coverage," and let the uCDN decide for itself (based on
its own topological intelligence) which dCDN has better resources to its own topological intelligence) which dCDN has better resources to
serve a given user. serve a given user.
In summary, the semantics of advertising footprint depend on whether In summary, the semantics of advertising footprint depend on whether
such qualitative metrics for expressing footprint (such as the such qualitative metrics for expressing footprint (such as the
coverage 'score' mentioned above) should be part of the CDNI FCI, or coverage 'score' mentioned above) should be part of the CDNI FCI, or
if it should focus just on 'binary' footprint. if it should focus just on 'binary' footprint.
3.2. Capabilities and Dynamic Data 2.2. Capabilities and Dynamic Data
In cases where the apparent footprint of dCDNs overlaps, uCDNs might In cases where the apparent footprint of dCDNs overlaps, uCDNs might
also want to rely on a host of other factors to evaluate the also want to rely on a host of other factors to evaluate the
respective merits of dCDNs. These include facts related to the respective merits of dCDNs. These include facts related to the
caches themselves, to the network where the cache is deployed, to the caches themselves, to the network where the cache is deployed, to the
nature of the resource sought and to the administrative policies of nature of the resource sought and to the administrative policies of
the respective networks. the respective networks.
In the absence of network-layer impediments to reaching caches, the In the absence of network-layer impediments to reaching caches, the
choice to limit coverage is necessarily an administrative policy. choice to limit coverage is necessarily an administrative policy.
skipping to change at page 8, line 18 skipping to change at page 6, line 8
federations, including questions of membership, compensation, volumes federations, including questions of membership, compensation, volumes
and so on. A uCDN certainly will factor these sorts of and so on. A uCDN certainly will factor these sorts of
considerations into its decision to select a dCDN, but there is considerations into its decision to select a dCDN, but there is
probably little need for dCDNs to actually advertise them through an probably little need for dCDNs to actually advertise them through an
interface - they will be settled out of band as a precondition for interface - they will be settled out of band as a precondition for
federating. federating.
Other facts about the dCDN would be expressed through the interface Other facts about the dCDN would be expressed through the interface
to the uCDN. Some capabilities of a dCDN are static, and some are to the uCDN. Some capabilities of a dCDN are static, and some are
highly dynamic. Expressing the total storage built into its caches, highly dynamic. Expressing the total storage built into its caches,
for example, changes relatively rarely, whereas the amount storage in for example, changes relatively rarely, whereas the amount of storage
use at any given moment is highly volatile. Network bandwidth in use at any given moment is highly volatile. Network bandwidth
similarly could be expressed as either total bandwidth available to a similarly could be expressed as either total bandwidth available to a
cache, or based on the current state of the network. A cache may at cache, or based on the current state of the network. A cache may at
one moment lack a particular resource in storage, but have it the one moment lack a particular resource in storage, but have it the
next. next.
The semantics of the capabilities interface will depend on how much The semantics of the capabilities interface will depend on how much
of the dCDN state needs to be pushed to the uCDN and qualitatively of the dCDN state needs to be pushed to the uCDN and qualitatively
how often that information should be updated. how often that information should be updated.
3.3. Advertisement versus Queries 2.3. Advertisement versus Queries
In a federated CDN environment, each dCDN shares some of its state In a federated CDN environment, each dCDN shares some of its state
with the uCDN, which the uCDN uses to build a unified picture of all with the uCDN, which the uCDN uses to build a unified picture of all
of the dCDNs available to it. In architectures that share detailed of the dCDNs available to it. In architectures that share detailed
capability information, the uCDN could basically perform the entire capability information, the uCDN could basically perform the entire
request-routing intelligence down to selecting a particular cache request-routing intelligence down to selecting a particular cache
before sending the request to the dCDN (note that within the current before sending the request to the dCDN (note that within the current
CDNI WG scope, such direct selection of specific caches by the uCDN CDNI WG scope, such direct selection of specific caches by the uCDN
is out of scope). However, when the uCDN must deal with many is out of scope). However, when the uCDN must deal with many
potential dCDNs, this approach does not scale. Especially as CDNs potential dCDNs, this approach does not scale. Especially as CDNs
skipping to change at page 9, line 10 skipping to change at page 6, line 49
of querying dCDNs would be that much of the dynamic data that dCDNs of querying dCDNs would be that much of the dynamic data that dCDNs
cannot share with the uCDN would now be factored into the uCDN's cannot share with the uCDN would now be factored into the uCDN's
decision. dCDNs need not replicate any state to the uCDN - uCDNs decision. dCDNs need not replicate any state to the uCDN - uCDNs
could effectively operate in a stateless mode. could effectively operate in a stateless mode.
The semantics of both footprint and capability advertisement depend The semantics of both footprint and capability advertisement depend
on the service model here: are there cases where a synchronous query/ on the service model here: are there cases where a synchronous query/
response model would work better for the uCDN decision than a state response model would work better for the uCDN decision than a state
replication model? replication model?
3.4. Avoiding or Handling 'cheating' dCDNs 2.4. Avoiding or Handling 'cheating' dCDNs
In a situation where more than one dCDN is willing to serve a given In a situation where more than one dCDN is willing to serve a given
end user request, it might be attractive for a dCDN to 'cheat' in the end user request, it might be attractive for a dCDN to 'cheat' in the
sense that the dCDN provides inaccurate information to the uCDN in sense that the dCDN provides inaccurate information to the uCDN in
order to convince the uCDN to select it opposed to 'competing' dCDNs. order to convince the uCDN to select it opposed to 'competing' dCDNs.
It could therefore be desirable to take away the incentive for dCDNs It could therefore be desirable to take away the incentive for dCDNs
to cheat (in information advertised) as much as possible. One option to cheat (in information advertised) as much as possible. One option
here is to make the information the dCDN advertises somehow here is to make the information the dCDN advertises somehow
verifiable for the uCDN. One the other hand, a cheating dCDN might verifiable for the uCDN. One the other hand, a cheating dCDN might
be avoided or handled by the fact that there will be strong be avoided or handled by the fact that there will be strong
skipping to change at page 9, line 35 skipping to change at page 7, line 25
Overall, it seems that information a dCDN advertises should (in the Overall, it seems that information a dCDN advertises should (in the
long run) be somehow qualitatively verifiable by the uCDN, though long run) be somehow qualitatively verifiable by the uCDN, though
possibly through non-real-time out-of-band audits. It is probably an possibly through non-real-time out-of-band audits. It is probably an
overly strict requirement to mandate that such verification be overly strict requirement to mandate that such verification be
possible "immediately", i.e. during the request routing process possible "immediately", i.e. during the request routing process
itself. If the uCDN can detect a cheating dCDN at a later stage, it itself. If the uCDN can detect a cheating dCDN at a later stage, it
should suffice for the uCDN to "de-incentivize" cheating because it should suffice for the uCDN to "de-incentivize" cheating because it
would negatively affect the long-term business relationship with a would negatively affect the long-term business relationship with a
particular dCDN. particular dCDN.
3.5. Focus on Main Use Cases may Simplify Things 2.5. Focus on Main Use Cases may Simplify Things
To narrow down semantics for "footprint" and "capabilities" in the To narrow down semantics for "footprint" and "capabilities" in the
CDNI context, it can be useful to initially focus on key use cases to CDNI context, it can be useful to initially focus on key use cases to
be addressed by the CDNI WG that are to be envisioned the main be addressed by the CDNI WG that are to be envisioned the main
deployments in the foreseeable future. In this regard, a main deployments in the foreseeable future. In this regard, a main
realistic use case is the existence of ISP-owned CDNs, which realistic use case is the existence of ISP-owned CDNs, which
essentially cover a certain operator's network. At the same time, essentially cover a certain operator's network. At the same time,
however, the possibility of overlapping footprints should not be however, the possibility of overlapping footprints should not be
excluded, i.e. the scenario where more than one dCDN claims it can excluded, i.e. the scenario where more than one dCDN claims it can
serve a given end user request. The ISPs may also choose to federate serve a given end user request. The ISPs may also choose to federate
with a fallback global CDN. with a fallback global CDN.
It seems reasonable to assume that in most use cases it is the uCDN It seems reasonable to assume that in most use cases it is the uCDN
that makes the decision on selecting a certain dCDN for request that makes the decision on selecting a certain dCDN for request
routing based on information the uCDN has received from this routing based on information the uCDN has received from this
particular dCDN. It may be assumed that 'cheating' CDNs will be particular dCDN. It may be assumed that 'cheating' CDNs will be
dealt with via means outside the scope of CDNI and that the dealt with via means outside the scope of CDNI and that the
information advertised between CDNs is accurate. In addition, information advertised between CDNs is accurate. In addition,
excluding the use of qualitative information (e.g., cache proximity, excluding the use of qualitative information (e.g., cache proximity,
delivery latency, cache load) to to predict the quality of delivery delivery latency, cache load) to predict the quality of delivery
would further simplify the use case allowing it to better focus on would further simplify the use case allowing it to better focus on
the basic functionality of the FCI. the basic functionality of the FCI.
4. Main Use Case to foster the Clarification of Semantics 3. Main Use Case to Consider
Focusing on a main use case that contains a simple (yet somewhat Focusing on a main use case that contains a simple (yet somewhat
challenging), realistic, and generally imaginable scenario can help challenging), realistic, and generally imaginable scenario can help
in narrowing down the requirements for the CDNI FCI. To this end, in narrowing down the requirements for the CDNI FCI. To this end,
the following (simplified) use case can help in clarifying the the following (simplified) use case can help in clarifying the
semantics of footprint and capabilities for CDNI. In particular, the semantics of footprint and capabilities for CDNI. In particular, the
intention of the use case is to clarify what information needs to be intention of the use case is to clarify what information needs to be
exchanged on the CDNI FCI, what types of information need to be exchanged on the CDNI FCI, what types of information need to be
supported in a mandatory fashion (and which should be considered supported in a mandatory fashion (and which should be considered
optional), and what types of information need to be updated with optional), and what types of information need to be updated with
respect to a priori established CDNI contracts. respect to a priori established CDNI contracts.
skipping to change at page 10, line 38 skipping to change at page 8, line 30
footprint 1 where the first-level dCDN cannot serve delivery protocol footprint 1 where the first-level dCDN cannot serve delivery protocol
B itself. What happens if capabilities change in the transitive B itself. What happens if capabilities change in the transitive
level-2 dCDN that might affect how the uCDN selects a level-1 dCDN level-2 dCDN that might affect how the uCDN selects a level-1 dCDN
(e.g. in case the level-2 dCDN cannot serve delivery protocol B (e.g. in case the level-2 dCDN cannot serve delivery protocol B
anymore)? How will these changes be conveyed to the uCDN? In anymore)? How will these changes be conveyed to the uCDN? In
particular, what information does the uCDN need to be able to select particular, what information does the uCDN need to be able to select
a new first-level dCDN, either for all of footprint 1 or only for the a new first-level dCDN, either for all of footprint 1 or only for the
subset of footprint 1 that the transitive level-2 dCDN served on subset of footprint 1 that the transitive level-2 dCDN served on
behalf of the first-level dCDN? behalf of the first-level dCDN?
5. Towards Semantics for Footprint Advertisement 4. Semantics for Footprint Advertisement
Roughly speaking, "footprint" can be defined as "ability and Roughly speaking, "footprint" can be defined as "ability and
willingness to serve" by a downstream CDN. However, in addition to willingness to serve" by a downstream CDN. However, in addition to
simple "ability and willingness to serve", the uCDN may wish to have simple "ability and willingness to serve", the uCDN may wish to have
additional information to make a dCDN selection decision, e.g., "how additional information to make a dCDN selection decision, e.g., "how
well" a given dCDN can actually serve a given end user request. The well" a given dCDN can actually serve a given end user request. The
"ability and willingness" to serve should be distinguished from the "ability and willingness" to serve should be distinguished from the
subjective qualitative measurement of "how well" it was served. One subjective qualitative measurement of "how well" it was served. One
can imagine that such additonal information is implicitly associated can imagine that such additional information is implicitly associated
with a given footprint, e.g. due to contractual agreements (e.g. with a given footprint, e.g. due to contractual agreements (e.g.
SLAs), business relationships, or perceived dCDN quality in the past. SLAs), business relationships, or perceived dCDN quality in the past.
As an alternative, such additional information could also be As an alternative, such additional information could also be
explicitly tagged along with the footprint. explicitly tagged along with the footprint.
It is reasonable to assume that a significant part of the actual It is reasonable to assume that a significant part of the actual
footprint advertisement will happen in contractual agreements between footprint advertisement will happen in contractual agreements between
participating CDNs, i.e. prior to the advertisement phase using the participating CDNs, i.e. prior to the advertisement phase using the
CDNI FCI. The reason for this assumption is that any contractual CDNI FCI. The reason for this assumption is that any contractual
agreement is likely to contain specifics about the dCDN coverage agreement is likely to contain specifics about the dCDN coverage
skipping to change at page 11, line 32 skipping to change at page 9, line 24
about temporal failures of part of a footprint can be useful about temporal failures of part of a footprint can be useful
information to convey via the CDNI request routing interface. Such information to convey via the CDNI request routing interface. Such
information would provide updates on information previously agreed in information would provide updates on information previously agreed in
contracts between the participating CDNs. In other words, the CDNI contracts between the participating CDNs. In other words, the CDNI
FCI is a means for a dCDN to provide changes/updates regarding a FCI is a means for a dCDN to provide changes/updates regarding a
footprint it has prior agreed to serve in a contract with a uCDN. footprint it has prior agreed to serve in a contract with a uCDN.
Generally speaking, one can imagine two categories of footprint to be Generally speaking, one can imagine two categories of footprint to be
advertised by a dCDN: advertised by a dCDN:
o Footprint could be defined based on (layer-3) "coverage/ o Footprint could be defined based on "coverage/reachability", where
reachability", where coverage/reachability refers to a set of coverage/reachability refers to a set of prefixes, a geographic
prefixes, a geographic region, or similar boundary. The dCDN region, or similar boundary. The dCDN claims that it can cover/
claims that it can cover/reach 'end user requests coming from this reach 'end user requests coming from this footprint'.
footprint'.
o Footprint could be defined based on "resources", where resources o Footprint could be defined based on "resources", where resources
refers to surrogates/caches a dCDN claims to have (e.g., the refers to surrogates/caches a dCDN claims to have (e.g., the
location of surrogates/resources). The dCDN claims that 'from location of surrogates/resources). The dCDN claims that 'from
this footprint' it can serve incoming end user requests. this footprint' it can serve incoming end user requests.
For each of these footprint types, there are capabilities associated For each of these footprint types, there are capabilities associated
with a given footprint, i.e. the capabilities (e.g., delivery with a given footprint, i.e. the capabilities (e.g., delivery
protocol, redirection mode, metadata) supported in the coverage area protocol, redirection mode, metadata) supported in the coverage area
for a "coverage/reachability" defined footprint, or the capabilities for a "coverage/reachability" defined footprint, or the capabilities
skipping to change at page 13, line 5 skipping to change at page 10, line 45
Independent of the exact type of a footprint, a footprint might also Independent of the exact type of a footprint, a footprint might also
include the connectivity of a given dCDN to other CDNs that may be include the connectivity of a given dCDN to other CDNs that may be
able to serve content to users on behalf of that dCDN, to cover cases able to serve content to users on behalf of that dCDN, to cover cases
where there is a transitive CDN interconnection. Further, the where there is a transitive CDN interconnection. Further, the
downstream CDN must be able to express its footprint to an interested downstream CDN must be able to express its footprint to an interested
upstream CDN (uCDN) in a comprehensive form, e.g., as a complete data upstream CDN (uCDN) in a comprehensive form, e.g., as a complete data
set containing the complete footprint. Making incremental updates, set containing the complete footprint. Making incremental updates,
however, to express dynamic changes in state is also desirable. however, to express dynamic changes in state is also desirable.
6. Towards Semantics for Capabilities Advertisement 5. Semantics for Capabilities Advertisement
In general, the dCDN must be able to express its general capabilities In general, the dCDN must be able to express its general capabilities
to the uCDN. These general capabilities could express if the dCDN to the uCDN. These general capabilities could express if the dCDN
supports a given service, for instance, HTTP delivery, RTP/RTSP supports a given service, for instance, HTTP delivery, RTP/RTSP
delivery or RTMP. Furthermore, the dCDN must be able to express delivery or RTMP. Furthermore, the dCDN must be able to express
particular capabilities for the delivery in a particular footprint particular capabilities for the delivery in a particular footprint
area. For example, the dCDN might in general offer RTMP but not in area. For example, the dCDN might in general offer RTMP but not in
some specific areas, either for maintenance reasons or because the some specific areas, either for maintenance reasons or because the
caches covering this particular area cannot deliver this type of caches covering this particular area cannot deliver this type of
service. Hence, in certain cases footprint and capabilities are tied service. Hence, in certain cases footprint and capabilities are tied
skipping to change at page 13, line 30 skipping to change at page 11, line 22
A high-level and very rough semantic for capabilities is thus the A high-level and very rough semantic for capabilities is thus the
following: Capabilities are types of information that allow a uCDN to following: Capabilities are types of information that allow a uCDN to
determine if a downstream CDN is able (and willing) to accept (and determine if a downstream CDN is able (and willing) to accept (and
properly handle) a delegated content request. In addition, properly handle) a delegated content request. In addition,
Capabilities are characterized by the fact that this information may Capabilities are characterized by the fact that this information may
possibly change over time based on the state of the network or possibly change over time based on the state of the network or
caches. caches.
At a first glance, several broad categories of capabilities seem At a first glance, several broad categories of capabilities seem
useful to convey via an advertisement interface (and indeed many such useful to convey via an advertisement interface, however, advertising
candidate capabilities have been suggested in CDNI drafts, see capabilities that change highly dynamically (e.g. real-time delivery
Section 2). However, advertising capabilities that change highly performance metrics, CDN resource load, or other highly dynamically
dynamically (e.g. real-time delivery performance metrics, CDN changing QoS information) should probably not be in scope for the
resource load, or other highly dynamically changing QoS information) CDNI FCI. First, out of the multitude of possible metrics and
should probably not be in scope for the CDNI FCI. First, out of the capabilities, it is hard to agree on a subset and the precise metrics
multitude of possible metrics and capabilities, it is hard to agree to be used. Second, and perhaps more importantly, it seems not
on a subset and the precise metrics to be used. Second, and perhaps feasible to specify such highly dynamically changing capabilities and
more importantly, it seems not feasible to specify such highly the corresponding metrics within the CDNI charter time-frame.
dynamically changing capabilities and the corresponding metrics
within the CDNI charter time-frame.
Useful capabilities refer to information that does not change highly Useful capabilities refer to information that does not change highly
dynamically and which in many cases is absolutely necessary to decide dynamically and which in many cases is absolutely necessary to decide
on a particular dCDN for a given end user request. For instance, if on a particular dCDN for a given end user request. For instance, if
an end user request concerns the delivery of a video file with a an end user request concerns the delivery of a video file with a
certain protocol (e.g. RTMP), the uCDN needs to know if a given dCDN certain protocol (e.g. RTMP), the uCDN needs to know if a given dCDN
has the capabiltity of supporting this delivery protocol. has the capabilitity of supporting this delivery protocol.
Similar to footprint advertisement, it is reasonable to assume that a Similar to footprint advertisement, it is reasonable to assume that a
significant part of the actual (resource) capabilities advertisement significant part of the actual (resource) capabilities advertisement
will happen in contractual agreements between participating CDNs, will happen in contractual agreements between participating CDNs,
i.e. prior to the advertisement phase using the CDNI FCI. The role i.e. prior to the advertisement phase using the CDNI FCI. The role
of capability advertisement is hence rather to enable the dCDN to of capability advertisement is hence rather to enable the dCDN to
update a uCDN on changes since a contract has been set up (e.g. in update a uCDN on changes since a contract has been set up (e.g. in
case a new delivery protocol is suddenly being added to the list of case a new delivery protocol is suddenly being added to the list of
supported delivery protocols of a given dCDN, or in case a certain supported delivery protocols of a given dCDN, or in case a certain
delivery protocol is suddenly not being supported anymore due to delivery protocol is suddenly not being supported anymore due to
skipping to change at page 14, line 24 skipping to change at page 12, line 16
are useful and how these can be expressed. Since the details of CDNI are useful and how these can be expressed. Since the details of CDNI
contracts are not known at the time of this writing (and the CDNI contracts are not known at the time of this writing (and the CDNI
interface should probably be agnostic to these contracts anyway), it interface should probably be agnostic to these contracts anyway), it
remains to be seen what capabilities will be used to define remains to be seen what capabilities will be used to define
agreements between CDNs in practice. One implication for agreements between CDNs in practice. One implication for
standardization may be to initially only specify a very limited set standardization may be to initially only specify a very limited set
of mandatory capabilities for advertisement and have on top of that a of mandatory capabilities for advertisement and have on top of that a
flexible data model that allows exchanging additional capabilities flexible data model that allows exchanging additional capabilities
when needed. Still, agreement needs to be found on which when needed. Still, agreement needs to be found on which
capabilities (if any) should be mandatory among CDNs. As discussed capabilities (if any) should be mandatory among CDNs. As discussed
in Section 3.5, finding the concrete answers to these questions can in Section 2.5, finding the concrete answers to these questions can
benefit from focusing on a small number of key use cases that are benefit from focusing on a small number of key use cases that are
highly relevant and contain enough complexity to help in highly relevant and contain enough complexity to help in
understanding what concrete capabilities are needed to facilitate CDN understanding what concrete capabilities are needed to facilitate CDN
Interconnection. Interconnection.
Under the above considerations, the following capabilities seem Under the above considerations, the following capabilities seem
useful as 'base' capabilities, i.e. ones that are needed in any case useful as 'base' capabilities, i.e. ones that are needed in any case
and therefore constitute mandatory capabilities to be supported by and therefore constitute mandatory capabilities to be supported by
the CDNI FCI: the CDNI FCI:
skipping to change at page 15, line 20 skipping to change at page 13, line 11
the rules for adding new entries to the registry) for the different the rules for adding new entries to the registry) for the different
capability types. Each capability type MAY further have a list of capability types. Each capability type MAY further have a list of
valid values. The individual CDNI interface specifications which valid values. The individual CDNI interface specifications which
define a given capability SHOULD define any necessary registries (and define a given capability SHOULD define any necessary registries (and
the rules for adding new entries to the registry) for the values the rules for adding new entries to the registry) for the values
advertised for a given capability type. advertised for a given capability type.
The mandatory capabilities listed above generally relate to The mandatory capabilities listed above generally relate to
information that is configured on a content asset or group of assets information that is configured on a content asset or group of assets
basis via CDNI metadata. The capability requirements for acquisition basis via CDNI metadata. The capability requirements for acquisition
and delivery protocol, redirection mode, and other mandatory metadata and delivery protocol and other mandatory metadata capabilities (e.g.
capabilities (e.g. authorization algorithms) are defined in authorization algorithms) are defined in [I-D.ietf-cdni-metadata].
[I-D.ietf-cdni-metadata].
Note: CDNI interface support for logging configuration (i.e., control Note: CDNI interface support for logging configuration (i.e., control
interface vs. metadata interface) has not yet been decided. Once it interface vs. metadata interface) has not yet been decided. Once it
has been decided, the corresponding CDNI interface specification has been decided, the corresponding CDNI interface specification
should define the associated capability requirements. should define the associated capability requirements.
7. Open Issues and Questions 6. Negotiation of Support for Optional Types of Footprint/Capabilities
The following open issues deserve further discussion in the CDNI WG: The notion of optional types of footprint and capabilities implies
that certain implementations may not support all kinds of footprint
and capabilities. Therefore, any FCI solution protocol must define
how the support for optional types of footprint/capabilities will be
negotiated between a uCDN and a dCDN that use the particular FCI
protocol. In particular, any FCI solution protocol needs to specify
how to handle failure cases or non-supported types of footprint/
capabilities.
o What is the service model of this interface: Does the uCDN always In general, a uCDN may ignore capabilities or types of footprint it
query the dCDNs? Or does the dCDN always push information to the does not understand; in this case it only selects a suitable
uCDNs? downstream CDN based on the types of capabilities and footprint it
understands. Similarly, if a dCDN does not use an optional
capability or footprint which is, however, supported by a uCDN, this
causes no problem for the FCI functionality because the uCDN decides
on the remaining capabilities/footprint information that is being
conveyed by the dCDN.
o Does a footprint need to explicitly include the "transitive 7. IANA Considerations
reachability" of a dCDN to further dCDNs that may be able to serve
content to users on behalf of dCDN?
o What is the assumed business relationship between the uCDN and the IANA registries are to be used for mandatory and optional types of
dCDN? Is the uCDN always the "authoritative" CDN provider which footprint and capabilities. Therefore, the mandatory types of
transitively has itself contracted several downstream CDN footprint and capabilities listed in this document (see Section 5)
providers? are to be registered with IANA. In order to prevent namespace
collisions for capabilities a new IANA registry is requested for the
"CDNI Capabilities" namespace. The namespace shall be split into two
partitions: standard and vendor defined. As with the CDNI Metadata
Interface [I-D.ietf-cdni-metadata], the vendor defined namespace
partition SHOULD use a namespace prefix of "ext.", while the standard
namespace partition MUST NOT.
o How exactly can a given dCDN derive its footprint? The standard namespace partition MUST conform to the "RFC Required"
policy as defined in [RFC5226]. The vendor defined namespace
partition should be further partitioned into vendor specific
partitions with the prefix "ext.vendor_name.". The vendor defined
partition SHOULD conform to the "Expert Review" policy as defined in
[RFC5226]. The expert review is simply to prevent namespace
hoarding. The vendor specific partitions MAY conform to the "First
Come First Served" policy as defined in [RFC5226], however, vendors
defining new capabilities which conflict with existing capabilities
SHOULD follow the guidelines for the "Specification Required" policy
as defined in [RFC5226].
o Should the footprint/capabilities advertisement interface only The following table defines the initial capabilities for the standard
signal the delta with respect to a given contract (between a uCDN partition:
and a dCDN) or send the whole dCDN state each time?
o What is the exact process for specifying optional footprint or +----------------------+---------------+
capability types? For instance, for an IANA registry, what level | capability | Specification |
of oversight is needed (should the WG decide, or an expert +----------------------+---------------+
reviewer, or just a free-for-all)? | Delivery Protocol | RFCthis |
| | |
| Acquisition Protocol | RFCthis |
| | |
| Redirection Mode | RFCthis |
+----------------------+---------------+
o How will the support for optional types of footprint/capabilities Additional capabilities specific to the CDNI Metadata Interface
be negotiated? [I-D.ietf-cdni-metadata] and the CDNI Logging Interface
[I-D.ietf-cdni-metadata] SHALL be addressed separately by those
documents.
7.1. Footprint Sub-Registry
The "CDNI Metadata Footprint Types" namespace defined in the CDNI
Metadata Interface document [I-D.ietf-cdni-metadata] contains the
supported footprint formats for use in footprint advertisement. No
further IANA action is required here.
7.2. Protocol Sub-Registry
The "CDNI Metadata Protocols" namespace defined in the CDNI Metadata
Interface document [I-D.ietf-cdni-metadata] contains the supported
protocol values for the Delivery Protocol and Acquisition Protocol
capabilities. No further IANA action is required here.
7.3. Redirection Mode Sub-Registry
The "CDNI Capabilities Redirection Modes" namespace defines the valid
redirection modes that may be advertised as supported by a CDN.
Additions to the Redirection Mode namespace MUST conform to the
"Expert Review" policy as defined in [RFC5226]. The expert review
should verify that new type definitions do not duplicate existing
type definitions and prevent gratuitous additions to the namespace.
For new Redirection Modes which apply to new standard protocols, it
is recommended that registration requests follow the "RFC Required"
policy as defined in [RFC5226].
The following table defines the initial Redirection Modes:
+------------------+----------------------------------+
| Redirection Mode | definition |
+------------------+----------------------------------+
| DNS-I | Iterative DNS-based Redirection |
| | |
| DNS-R | Recursive DNS-based Redirection |
| | |
| HTTP-I | Iterative HTTP-based Redirection |
| | |
| HTTP-R | Recursive HTTP-based Redirection |
+------------------+----------------------------------+
8. Security Considerations 8. Security Considerations
Security considerations will be discussed in a future version of this Security considerations will be discussed in a future version of this
document. document.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[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.
[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.
9.2. Informative References 9.2. Informative References
[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-06 (work in
progress), February 2013. progress), October 2013.
[I-D.ietf-cdni-logging]
Faucheur, F., Bertrand, G., Oprescu, I., and R.
Peterkofsky, "CDNI Logging Interface", draft-ietf-cdni-
logging-08 (work in progress), October 2013.
[I-D.ietf-cdni-metadata] [I-D.ietf-cdni-metadata]
Niven-Jenkins, B., Murray, R., Watson, G., Caulfield, M., Niven-Jenkins, B., Murray, R., Watson, G., Caulfield, M.,
Leung, K., and K. Ma, "CDN Interconnect Metadata", draft- Leung, K., and K. Ma, "CDN Interconnect Metadata", draft-
ietf-cdni-metadata-01 (work in progress), February 2013. ietf-cdni-metadata-02 (work in progress), July 2013.
[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", draft-ietf-cdni- Interconnection (CDNI) Requirements", draft-ietf-cdni-
requirements-09 (work in progress), July 2013. requirements-10 (work in progress), September 2013.
[I-D.ma-cdni-capabilities]
Ma, K., "Content Distribution Network Interconnection
(CDNI) Capabilities Interface", draft-ma-cdni-
capabilities-01 (work in progress), February 2013.
[I-D.previdi-cdni-footprint-advertisement]
Previdi, S., Faucheur, F., Faucheur, F., Medved, J., and
L. Faucheur, "CDNI Footprint Advertisement", draft-
previdi-cdni-footprint-advertisement-02 (work in
progress), September 2012.
Appendix A. Acknowledgment Appendix A. Acknowledgment
Jan Seedorf is partially supported by the CHANGE project (CHANGE: Jan Seedorf is partially supported by the CHANGE project (CHANGE:
Enabling Innovation in the Internet Architecture through Flexible Enabling Innovation in the Internet Architecture through Flexible
Flow-Processing Extensions, http://www.change-project.eu/), a Flow-Processing Extensions, http://www.change-project.eu/), a
research project supported by the European Commission under its 7th research project supported by the European Commission under its 7th
Framework Program (contract no. 257422). The views and conclusions Framework Program (contract no. 257422). The views and conclusions
contained herein are those of the authors and should not be contained herein are those of the authors and should not be
interpreted as necessarily representing the official policies or interpreted as necessarily representing the official policies or
 End of changes. 42 change blocks. 
220 lines changed or deleted 175 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/