draft-ietf-cdni-footprint-capabilities-semantics-02.txt   draft-ietf-cdni-footprint-capabilities-semantics-03.txt 
CDNI J. Seedorf CDNI J. Seedorf
Internet-Draft NEC Internet-Draft NEC
Intended status: Informational J. Peterson Intended status: Informational J. Peterson
Expires: August 18, 2014 Neustar Expires: January 21, 2015 Neustar
S. Previdi S. Previdi
Cisco Cisco
R. van Brandenburg R. van Brandenburg
TNO TNO
K. Ma K. Ma
Azuki Systems, Inc. Ericsson
February 14, 2014 July 20, 2014
CDNI Request Routing: Footprint and Capabilities Semantics CDNI Request Routing: Footprint and Capabilities Semantics
draft-ietf-cdni-footprint-capabilities-semantics-02 draft-ietf-cdni-footprint-capabilities-semantics-03
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.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
skipping to change at page 1, line 49 skipping to change at page 1, line 49
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 August 18, 2014. This Internet-Draft will expire on January 21, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 34 skipping to change at page 2, line 34
2.1. Advertising Limited Coverage . . . . . . . . . . . . . . 4 2.1. Advertising Limited Coverage . . . . . . . . . . . . . . 4
2.2. Capabilities and Dynamic Data . . . . . . . . . . . . . . 5 2.2. Capabilities and Dynamic Data . . . . . . . . . . . . . . 5
2.3. Advertisement versus Queries . . . . . . . . . . . . . . 6 2.3. Advertisement versus Queries . . . . . . . . . . . . . . 6
2.4. Avoiding or Handling 'cheating' dCDNs . . . . . . . . . . 7 2.4. Avoiding or Handling 'cheating' dCDNs . . . . . . . . . . 7
2.5. Focus on Main Use Cases may Simplify Things . . . . . . . 7 2.5. Focus on Main Use Cases may Simplify Things . . . . . . . 7
3. Main Use Case to Consider . . . . . . . . . . . . . . . . . . 8 3. Main Use Case to Consider . . . . . . . . . . . . . . . . . . 8
4. Semantics for Footprint Advertisement . . . . . . . . . . . . 8 4. Semantics for Footprint Advertisement . . . . . . . . . . . . 8
5. Semantics for Capabilities Advertisement . . . . . . . . . . 10 5. Semantics for Capabilities Advertisement . . . . . . . . . . 10
6. Negotiation of Support for Optional Types of 6. Negotiation of Support for Optional Types of
Footprint/Capabilities . . . . . . . . . . . . . . . . . . . 13 Footprint/Capabilities . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7.1. Footprint Sub-Registry . . . . . . . . . . . . . . . . . 14 7.1. Footprint Sub-Registry . . . . . . . . . . . . . . . . . 15
7.2. Protocol Sub-Registry . . . . . . . . . . . . . . . . . . 14 7.2. Protocol Sub-Registry . . . . . . . . . . . . . . . . . . 15
7.3. Redirection Mode Sub-Registry . . . . . . . . . . . . . . 15 7.3. Redirection Mode Sub-Registry . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7.4. Logging Field Sub-Registry . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 7.5. Metadata Type Sub-Registry . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Acknowledgment . . . . . . . . . . . . . . . . . . . 16 Appendix A. Acknowledgment . . . . . . . . . . . . . . . . . . . 17
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.
skipping to change at page 3, line 38 skipping to change at page 3, line 40
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.
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
RFC 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 range of different footprint definitions and possible The range of different footprint definitions and possible
capabilities is very broad. Attempting to define a comprehensive capabilities is very broad. Attempting to define a comprehensive
advertisement solution quickly becomes intractable. The CDNI advertisement solution quickly becomes intractable. The CDNI
requirements draft [I-D.ietf-cdni-requirements] lists the specific requirements draft [I-D.ietf-cdni-requirements] lists the specific
requirements for the CDNI Footprint & Capabilities Advertisement requirements for the CDNI Footprint & Capabilities Advertisement
skipping to change at page 7, line 24 skipping to change at page 7, line 24
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
contractual agreements between a uCDN and a dCDN, so that a dCDN contractual agreements between a uCDN and a dCDN, so that a dCDN
would risk severe penalties or legal consequences when caught would risk severe penalties or legal consequences when caught
cheating. cheating.
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.
2.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,
skipping to change at page 8, line 26 skipping to change at page 8, line 26
respect to a priori established CDNI contracts. respect to a priori established CDNI contracts.
In short, one can imagine the following use case: A given uCDN has In short, one can imagine the following use case: A given uCDN has
several dCDNs. It selects one dCDN for delivery protocol A and several dCDNs. It selects one dCDN for delivery protocol A and
footprint 1 and another dCDN for delivery protocol B and footprint 1. footprint 1 and another dCDN for delivery protocol B and footprint 1.
The dCDN that serves delivery protocol B has a further, transitive The dCDN that serves delivery protocol B has a further, transitive
(level-2) dCDN, that serves delivery protocol B in a subset of (level-2) dCDN, that serves delivery protocol B in a subset of
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?
4. 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 additional 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
(i.e. the dCDN footprint) the contractual agreement applies to. In (i.e., the dCDN footprint) to which the contractual agreement
particular, additional information to judge the delivery quality applies. In particular, additional information to judge the delivery
associated with a given dCDN footprint might be defined in quality associated with a given dCDN footprint might be defined in
contractual agreements (i.e. outside of the CDNI FCI). Further, one contractual agreements (i.e. outside of the CDNI FCI). Further, one
can assume that dCDN contractual agreements about the delivery can assume that dCDN contractual agreements about the delivery
quality associated with a given footprint will probably be based on quality associated with a given footprint will probably be based on
high-level aggregated statistics (i.e. not too detailed). high-level aggregated statistics (i.e., not too detailed).
Given that a large part of footprint advertisement will actually Given that a large part of footprint advertisement will actually
happen in contractual agreements, the semantics of CDNI footprint happen in contractual agreements, the semantics of CDNI footprint
advertisement refer to answering the following question: what exactly advertisement refer to answering the following question: what exactly
still needs to be advertised by the CDNI FCI? For instance, updates still needs to be advertised by the CDNI FCI? For instance, updates
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
skipping to change at page 9, line 37 skipping to change at page 9, line 37
coverage/reachability refers to a set of prefixes, a geographic coverage/reachability refers to a set of prefixes, a geographic
region, or similar boundary. The dCDN claims that it can cover/ region, or similar boundary. The dCDN claims that it can cover/
reach 'end user requests coming from this footprint'. reach 'end user requests coming from this 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
of resources (e.g., delivery protocol, redirection mode, metadata of resources (e.g., delivery protocol, redirection mode, metadata
support) for a "resources" defined footprint. support) for a "resources" defined footprint.
It seems clear that "coverage/reachability" types of footprint must It seems clear that "coverage/reachability" types of footprint must
be supported within CDNI. The following such types of footprint are be supported within CDNI. The following such types of footprint are
mandatory and must be supported by the CDNI FCI: mandatory and must be supported by the CDNI FCI:
o List of ISO Country Codes o List of ISO Country Codes
skipping to change at page 10, line 21 skipping to change at page 10, line 21
dCDN footprint advertisement tells the uCDN the limitations for dCDN footprint advertisement tells the uCDN the limitations for
delegating a request to the dCDN. For IP prefixes or ASN(s), the delegating a request to the dCDN. For IP prefixes or ASN(s), the
footprint signals to the uCDN that it should consider the dCDN a footprint signals to the uCDN that it should consider the dCDN a
candidate only if the IP address of the request routing source falls candidate only if the IP address of the request routing source falls
within the prefix set (or ASN, respectively). The CDNI within the prefix set (or ASN, respectively). The CDNI
specifications do not define how a given uCDN determines what address specifications do not define how a given uCDN determines what address
ranges are in a particular ASN. Similarly, for country codes a uCDN ranges are in a particular ASN. Similarly, for country codes a uCDN
should only consider the dCDN a candidate if it covers the country of should only consider the dCDN a candidate if it covers the country of
the request routing source. The CDNI specifications do not define the request routing source. The CDNI specifications do not define
how a given uCDN determines the country of the request routing how a given uCDN determines the country of the request routing
source. Multiple footprint constraints are additive, i.e. the source. Multiple footprint constraints are additive, i.e., the
advertisement of different types of footprint narrows the dCDN advertisement of different types of footprint narrows the dCDN
candidacy cumulatively. candidacy cumulatively.
It addition to these mandatory "coverage/reachability" types of In addition to these mandatory "coverage/reachability" types of
footprint, other optional "coverage/reachability" types of footprint footprint, other optional "coverage/reachability" types of footprint
or "resource" types of footprint may defined by future or "resource" types of footprint may defined by future
specifications. To facilitate this, a clear process for specifying specifications. To facilitate this, a clear process for specifying
optional footprint types in a IANA registry must be specified. This optional footprint types in a IANA registry must be specified. This
includes the specification of the level of oversight necessary (e.g. includes the specification of the level of oversight necessary (e.g.,
WG decision or expert review) for adding new optional footprints to a WG decision or expert review) for adding new optional footprints to a
IANA registry as well as the specification of a template regarding IANA registry as well as the specification of a template regarding
design choices that must be captured by new optional types of design choices that must be captured by new optional types of
footprints. footprints.
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 data set
set containing the complete footprint. Making incremental updates, 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.
5. 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
together and cannot be interpreted independently from each other. In together and cannot be interpreted independently from each other. In
such cases, i.e. where capabilities must be expressed on a per such cases, i.e., where capabilities must be expressed on a per
footprint basis, it may be beneficial to combine footprint and footprint basis, it may be beneficial to combine footprint and
capabilities advertisement. capabilities advertisement.
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, however, advertising useful to convey via an advertisement interface, however, advertising
capabilities that change highly dynamically (e.g. real-time delivery capabilities that change highly dynamically (e.g., real-time delivery
performance metrics, CDN resource load, or other highly dynamically performance metrics, CDN resource load, or other highly dynamically
changing QoS information) should probably not be in scope for the changing QoS information) should probably not be in scope for the
CDNI FCI. First, out of the multitude of possible metrics and CDNI FCI. First, out of the multitude of possible metrics and
capabilities, it is hard to agree on a subset and the precise metrics capabilities, it is hard to agree on a subset and the precise metrics
to be used. Second, and perhaps more importantly, it seems not to be used. Second, and perhaps more importantly, it seems not
feasible to specify such highly dynamically changing capabilities and feasible to specify such highly dynamically changing capabilities and
the corresponding metrics within the CDNI charter time-frame. 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 capabilitity 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
failures). Capabilities advertisement thus refers to conveying failures). Capabilities advertisement thus refers to conveying
information to a uCDN about changes/updates of certain capabilities information to a uCDN about changes/updates of certain capabilities
with respect to a given contract. with respect to a given contract.
Given these semantics, it needs to be decided what exact capabilities Given these semantics, it needs to be decided what exact capabilities
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
skipping to change at page 12, line 23 skipping to change at page 12, line 23
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 2.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:
o Delivery Protocol (e.g., HTTP vs. RTMP) o Delivery Protocol (e.g., HTTP vs. RTMP)
o Acquisition Protocol (for aquiring content from a uCDN) o Acquisition Protocol (for aquiring content from a uCDN)
o Redirection Mode (e.g., DNS Redirection vs. HTTP Redirection as o Redirection Mode (e.g., DNS Redirection vs. HTTP Redirection as
discussed in [I-D.ietf-cdni-framework]) discussed in [I-D.ietf-cdni-framework])
o Capabilities related to CDNI Logging (e.g., supported logging o CDNI Logging (i.e., supported logging fields)
mechanisms)
o Capabilities related to CDNI Metadata (e.g., authorization o CDNI Metadata (i.e., supported GenericMetadata types)
algorithms or support for proprietary vendor metadata)
It is not feasable to enumerate all the possible options for the It is not feasable to enumerate all the possible options for the
mandatory capabilities listed above (e.g., all the potential delivery mandatory capabilities listed above (e.g., all the potential delivery
protocols or metadata options) or anticipate all the future needs for protocols or metadata options) or anticipate all the future needs for
additional capabilities. It would be unreasonable to burden the CDNI additional capabilities. It would be unreasonable to burden the CDNI
FCI specification with defining each supported capability. Instead, FCI specification with defining each supported capability. Instead,
the CDNI FCI specification should define a generic protocol for the CDNI FCI specification should define a generic protocol for
conveying any capability information. In this respect, it seems conveying any capability information. In this respect, it seems
reasonable to define a registry which initially contains the reasonable to define a registry which initially contains the
mandatory capabilities listed above, but may be extended as needs mandatory capabilities listed above, but may be extended as needs
dictate. The CDNI FCI specification SHOULD define the registry (and dictate. This document defines the registry (and the rules for
the rules for adding new entries to the registry) for the different adding new entries to the registry) for the different capability
capability types. Each capability type MAY further have a list of types (see Section 7). Each capability type MAY have a list of valid
valid values. The individual CDNI interface specifications which values. The individual CDNI interface specifications which define a
define a given capability SHOULD define any necessary registries (and given capability SHOULD define any necessary registries (and the
the rules for adding new entries to the registry) for the values 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 "CDNI Logging Fields Names" registry defines all supported
information that is configured on a content asset or group of assets logging fields, including mandatory-to-implement logging fields.
basis via CDNI metadata. The capability requirements for acquisition Advertisement of support for mandatory-to-implement logging fields
and delivery protocol and other mandatory metadata capabilities (e.g. SHOULD be supported but would be redundant. CDNs SHOULD NOT
authorization algorithms) are defined in [I-D.ietf-cdni-metadata]. advertise support for mandatory-to-implement logging fields. The
following logging fields are defined as optional in the CDNI Logging
Interface document [I-D.ietf-cdni-logging]:
Note: CDNI interface support for logging configuration (i.e., control o c-ip-anonimizing
interface vs. metadata interface) has not yet been decided. Once it
has been decided, the corresponding CDNI interface specification o s-ccid
should define the associated capability requirements.
o s-sid
The "CDNI GenericMetadata Types" registry defines all supported
GenericMetadats types, including mandatory-to-implement
GenericMetadata types. Advertisement of support for mandatory-to-
implement GenericMetadata types SHOULD be supported but would be
redundant. CDNs SHOULD NOT advertise support for mandatory-to-
implement GenericMetadata types. The CDNI Metadata Interface
document [I-D.ietf-cdni-metadata] does not define any optional
GenericMetadata types.
6. Negotiation of Support for Optional Types of Footprint/Capabilities 6. Negotiation of Support for Optional Types of Footprint/Capabilities
The notion of optional types of footprint and capabilities implies The notion of optional types of footprint and capabilities implies
that certain implementations may not support all kinds of footprint that certain implementations may not support all kinds of footprint
and capabilities. Therefore, any FCI solution protocol must define and capabilities. Therefore, any FCI solution protocol must define
how the support for optional types of footprint/capabilities will be how the support for optional types of footprint/capabilities will be
negotiated between a uCDN and a dCDN that use the particular FCI negotiated between a uCDN and a dCDN that use the particular FCI
protocol. In particular, any FCI solution protocol needs to specify protocol. In particular, any FCI solution protocol needs to specify
how to handle failure cases or non-supported types of footprint/ how to handle failure cases or non-supported types of footprint/
skipping to change at page 14, line 19 skipping to change at page 14, line 33
partition: partition:
+----------------------+---------+---------+ +----------------------+---------+---------+
| Capability | RFC | Version | | Capability | RFC | Version |
+----------------------+---------+---------+ +----------------------+---------+---------+
| Delivery Protocol | RFCthis | 1 | | Delivery Protocol | RFCthis | 1 |
| | | | | | | |
| Acquisition Protocol | RFCthis | 1 | | Acquisition Protocol | RFCthis | 1 |
| | | | | | | |
| Redirection Mode | RFCthis | 1 | | Redirection Mode | RFCthis | 1 |
| | | |
| CDNI Logging | RFCthis | 1 |
| | | |
| CDNI Metadata | RFCthis | 1 |
+----------------------+---------+---------+ +----------------------+---------+---------+
[Ed. Note: Need to add the CDNI Metadata Interface
[I-D.ietf-cdni-metadata] and the CDNI Logging Interface
[I-D.ietf-cdni-logging] capabilities to this table before
publication, or remove this note if this ends up being handled in
those documents directly.]
The initial FCI version number is set to 1. All three initial The initial FCI version number is set to 1. All three initial
capabilities are considered mandatory to implement for version 1. capabilities are considered mandatory to implement for version 1.
The version field should be incremented when new capability sets are The version field should be incremented when new capability sets are
added to the registry. added to the registry.
The "optional" namespace partition conforms to the "Expert Review" The "optional" namespace partition conforms to the "Expert Review"
policy as defined in [RFC5226]. The expert review is intended to policy as defined in [RFC5226]. The expert review is intended to
prevent namespace hoarding and to prevent the definition of redundant prevent namespace hoarding and to prevent the definition of redundant
capabilities. Vendors defining new capabilities which conflict with capabilities. Vendors defining new capabilities which conflict with
existing capabilities follow the guidelines for the "Specification existing capabilities follow the guidelines for the "Specification
skipping to change at page 15, line 28 skipping to change at page 15, line 40
+------------------+----------------------------------+---------+ +------------------+----------------------------------+---------+
| DNS-I | Iterative DNS-based Redirection | RFCthis | | DNS-I | Iterative DNS-based Redirection | RFCthis |
| | | | | | | |
| DNS-R | Recursive DNS-based Redirection | RFCthis | | DNS-R | Recursive DNS-based Redirection | RFCthis |
| | | | | | | |
| HTTP-I | Iterative HTTP-based Redirection | RFCthis | | HTTP-I | Iterative HTTP-based Redirection | RFCthis |
| | | | | | | |
| HTTP-R | Recursive HTTP-based Redirection | RFCthis | | HTTP-R | Recursive HTTP-based Redirection | RFCthis |
+------------------+----------------------------------+---------+ +------------------+----------------------------------+---------+
7.4. Logging Field Sub-Registry
The "CDNI Logging Fields Names" namespace defined in the CDNI Logging
Interface document [I-D.ietf-cdni-logging] contains the names of all
supported logging fields. No further IANA action is required here.
7.5. Metadata Type Sub-Registry
The "CDNI GenericMetadata Types" namespace defined in the CDNI
Metadata Interface document [I-D.ietf-cdni-metadata] contains the
names of the supported GenericMetadata objects. No further IANA
action is required here.
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
skipping to change at page 16, line 9 skipping to change at page 16, line 33
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., Davie, B., and R. Brandenburg, "Framework Peterson, L., Davie, B., and R. Brandenburg, "Framework
for CDN Interconnection", draft-ietf-cdni-framework-09 for CDN Interconnection", draft-ietf-cdni-framework-14
(work in progress), January 2014. (work in progress), June 2014.
[I-D.ietf-cdni-logging] [I-D.ietf-cdni-logging]
Faucheur, F., Bertrand, G., Oprescu, I., and R. Faucheur, F., Bertrand, G., Oprescu, I., and R.
Peterkofsky, "CDNI Logging Interface", draft-ietf-cdni- Peterkofsky, "CDNI Logging Interface", draft-ietf-cdni-
logging-09 (work in progress), February 2014. logging-12 (work in progress), July 2014.
[I-D.ietf-cdni-metadata] [I-D.ietf-cdni-metadata]
Niven-Jenkins, B., Murray, R., Watson, G., Caulfield, M., Niven-Jenkins, B., Murray, R., Caulfield, M., Leung, K.,
Leung, K., and K. Ma, "CDN Interconnect Metadata", draft- and K. Ma, "CDN Interconnection Metadata", draft-ietf-
ietf-cdni-metadata-04 (work in progress), December 2013. cdni-metadata-07 (work in progress), July 2014.
[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-17 (work in progress), January 2014. requirements-17 (work in progress), January 2014.
Appendix A. Acknowledgment Appendix A. Acknowledgment
Jan Seedorf is partially supported by the CHANGE project (CHANGE: Jan Seedorf is partially supported by the GreenICN project (GreenICN:
Enabling Innovation in the Internet Architecture through Flexible Architecture and Applications of Green Information Centric
Flow-Processing Extensions, http://www.change-project.eu/), a Networking), a research project supported jointly by the European
research project supported by the European Commission under its 7th Commission under its 7th Framework Program (contract no. 608518) and
Framework Program (contract no. 257422). The views and conclusions the National Institute of Information and Communications Technology
(NICT) in Japan (contract no. 167). 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
endorsements, either expressed or implied, of the CHANGE project or endorsements, either expressed or implied, of the GreenICN project,
the European Commission. the European Commission, or NICT.
Jan Seedorf has been partially supported by the COAST project
(COntent Aware Searching, retrieval and sTreaming, http://www.coast-
fp7.eu), a research project supported by the European Commission
under its 7th Framework Program (contract no. 248036). The views and
conclusions contained herein are those of the authors and should not
be interpreted as necessarily representing the official policies or
endorsements, either expressed or implied, of the COAST project or
the European Commission.
Martin Stiemerling provided initial input to this document and Martin Stiemerling provided initial input to this document and
valuable comments to the ongoing discussions among the authors of valuable comments to the ongoing discussions among the authors of
this document. Thanks to Francois Le Faucheur and Scott Wainner for this document. Thanks to Francois Le Faucheur and Scott Wainner for
providing valuable comments and suggestions to the text. providing valuable comments and suggestions to the text.
Authors' Addresses Authors' Addresses
Jan Seedorf Jan Seedorf
NEC NEC
skipping to change at page 17, line 32 skipping to change at page 18, line 4
Email: jon.peterson@neustar.biz Email: jon.peterson@neustar.biz
Stefano Previdi Stefano Previdi
Cisco Systems Cisco Systems
Via Del Serafico 200 Via Del Serafico 200
Rome 0144 Rome 0144
Italy Italy
Email: sprevidi@cisco.com Email: sprevidi@cisco.com
Ray van Brandenburg Ray van Brandenburg
TNO TNO
Brassersplein 2 Brassersplein 2
Delft 2612CT Delft 2612CT
The Netherlands The Netherlands
Phone: +31-88-866-7000 Phone: +31-88-866-7000
Email: ray.vanbrandenburg@tno.nl Email: ray.vanbrandenburg@tno.nl
Kevin J. Ma Kevin J. Ma
Azuki Systems, Inc. Ericsson
43 Nagog Park 43 Nagog Park
Acton MA 01720 Acton, MA 01720
USA USA
Phone: +1 978-844-5100 Phone: +1 978-844-5100
Email: kevin.ma@azukisystems.com Email: kevin.j.ma@ericsson.com
 End of changes. 44 change blocks. 
84 lines changed or deleted 99 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/