draft-ietf-cdni-footprint-capabilities-semantics-13.txt   draft-ietf-cdni-footprint-capabilities-semantics-14.txt 
skipping to change at page 1, line 16 skipping to change at page 1, line 16
Expires: October 6, 2016 Neustar Expires: October 6, 2016 Neustar
S. Previdi S. Previdi
Cisco Cisco
R. van Brandenburg R. van Brandenburg
TNO TNO
K. Ma K. Ma
Ericsson Ericsson
April 4, 2016 April 4, 2016
CDNI Request Routing: Footprint and Capabilities Semantics CDNI Request Routing: Footprint and Capabilities Semantics
draft-ietf-cdni-footprint-capabilities-semantics-13 draft-ietf-cdni-footprint-capabilities-semantics-14
Abstract Abstract
This document captures the semantics of the "Footprint and This document captures 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 of "Footprint" and interface, i.e., the desired meaning of "Footprint" and
"Capabilities" in the CDNI context, and what the "Footprint and "Capabilities" in the CDNI context, and what the "Footprint and
Capabilities Advertisement Interface (FCI)" offers within CDNI. The Capabilities Advertisement Interface (FCI)" offers within CDNI. The
document also provides guidelines for the CDNI FCI protocol. It document also provides guidelines for the CDNI FCI protocol. It
further defines a Base Advertisement Object, the necessary registries further defines a Base Advertisement Object, the necessary registries
skipping to change at page 3, line 17 skipping to change at page 3, line 17
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. This CDN interconnection (CDNI) interconnection of multiple CDNs. This CDN interconnection (CDNI)
can serve multiple purposes, as discussed in [RFC6770], for instance, can serve multiple purposes, as discussed in [RFC6770], for instance,
to extend the reach of a given CDN to areas in the network which are to extend the reach of a given CDN to areas in the network which are
not covered by this particular CDN. not covered by this particular CDN.
The goal of this document is to achieve a clear understanding about The goal of this document is to achieve a clear understanding about
the semantics associated with the CDNI Request Routing Footprint & the semantics associated with the CDNI Request Routing Footprint &
Capabilities Advertisement Interface (from now on referred to as Capabilities Advertisement Interface (from now on referred to as
FCI), in particular the type of information a downstream CDN FCI), in particular the type of information a downstream CDN (dCDN)
'advertises' regarding its footprint and capabilities. To narrow 'advertises' regarding its footprint and capabilities. To narrow
down undecided aspects of these semantics, this document tries to down undecided aspects of these semantics, this document tries to
establish a common understanding of what the FCI needs to offer and establish a common understanding of what the FCI needs to offer and
accomplish in the context of CDN Interconnection. accomplish in the context of CDN Interconnection.
It is explicitly outside the scope of this document to decide on It is explicitly outside the scope of this document to decide on
specific protocols to use for the FCI. However, guidelines for such specific protocols to use for the FCI. However, guidelines for such
FCI protocols are provided. FCI protocols are provided.
General assumptions in this document: General assumptions in this document:
o The CDNs participating in the interconnected CDN have already o The CDNs participating in the interconnected CDN have already
performed a boot strap process, i.e., they have connected to each performed a boot strap process, i.e., they have connected to each
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 upstream CDN (uCDN) receives footprint and/or capability o The upstream CDN (uCDN) receives footprint and/or capability
advertisements from a set of downstream CDNs (dCDNs). Footprint advertisements from a set of dCDNs. Footprint advertisement and
advertisement and capability advertisement need not use the same capability advertisement need not use the same underlying
underlying protocol. protocol.
o The uCDN receives the initial request-routing request from the o The uCDN receives the initial request-routing request from the
endpoint requesting the resource. endpoint requesting the resource.
The CDNI Problem Statement [RFC6707] describes the Request Routing The CDNI Problem Statement [RFC6707] describes the Request Routing
Interface as: "[enabling] a Request Routing function in an Upstream Interface as: "[enabling] a Request Routing function in a uCDN to
CDN to query a Request Routing function in a Downstream CDN to query a Request Routing function in a dCDN to determine if the dCDN
determine if the Downstream CDN is able (and willing) to accept the is able (and willing) to accept the delegated Content Request". In
delegated Content Request". In addition, RFC6707 says "the CDNI addition, RFC6707 says "the CDNI Request Routing interface is also
Request Routing interface is also expected to enable a downstream CDN expected to enable a dCDN to provide to the uCDN (static or dynamic)
to provide to the upstream CDN (static or dynamic) information (e.g., information (e.g., resources, footprint, load) to facilitate
resources, footprint, load) to facilitate selection of the downstream selection of the dCDN by the uCDN request routing system when
CDN by the upstream CDN request routing system when processing processing subsequent content requests from User Agents". It thus
subsequent content requests from User Agents". It thus considers considers "resources" and "load" as capabilities to be advertised by
"resources" and "load" as capabilities to be advertised by the the dCDN.
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 [RFC7337] lists the specific requirements for the requirements draft [RFC7337] lists the specific requirements for the
CDNI Footprint & Capabilities Advertisement Interface in order to CDNI Footprint & Capabilities Advertisement Interface in order to
disambiguate footprints and capabilities with respect to CDNI. This disambiguate footprints and capabilities with respect to CDNI. This
document defines a common understanding of what the terms 'footprint' document defines a common understanding of what the terms 'footprint'
and 'capabilities' mean in the context of CDNI, and details the and 'capabilities' mean in the context of CDNI, and details the
semantics of the footprint advertisement mechanism and the capability semantics of the footprint advertisement mechanism and the capability
skipping to change at page 8, line 37 skipping to change at page 8, line 37
how the uCDN selects a level-1 dCDN (e.g., in case the level-2 dCDN how the uCDN selects a level-1 dCDN (e.g., in case the level-2 dCDN
cannot serve delivery protocol B anymore)? How will these changes be cannot serve delivery protocol B anymore)? How will these changes be
conveyed to the uCDN? In particular, what information does the uCDN conveyed to the uCDN? In particular, what information does the uCDN
need to be able to select a new first-level dCDN, either for all of need to be able to select a new first-level dCDN, either for all of
footprint 1 or only for the subset of footprint 1 that the transitive footprint 1 or only for the subset of footprint 1 that the transitive
level-2 dCDN served on behalf of the first-level dCDN? level-2 dCDN served on 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 dCDN. However, in addition to simple
simple "ability and willingness to serve", the uCDN could want "ability and willingness to serve", the uCDN could want additional
additional information to make a dCDN selection decision, e.g., "how information to make a dCDN selection decision, e.g., "how well" a
well" a given dCDN can actually serve a given end user request. The given dCDN can actually serve a given end user request. The "ability
"ability and willingness" to serve SHOULD be distinguished from the and willingness" to serve SHOULD be distinguished from the subjective
subjective qualitative measurement of "how well" it was served. One qualitative measurement of "how well" it was served. One can imagine
can imagine that such additional information is implicitly associated that such additional information is implicitly associated with a
with a given footprint, due to contractual agreements, SLAs, business given footprint, due to contractual agreements, SLAs, business
relationships, or past perceptions of dCDN quality. As an relationships, or past perceptions of dCDN quality. As an
alternative, such additional information could also be explicitly alternative, such additional information could also be explicitly
tagged along with the footprint. 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, prior to the advertisement phase using the CDNI participating CDNs, prior to the advertisement phase using the CDNI
FCI. The reason for this assumption is that any contractual 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
(footprint) to which the contractual agreement applies. In (footprint) to which the contractual agreement applies. In
skipping to change at page 11, line 8 skipping to change at page 11, line 8
footprint, other optional "coverage/reachability" types of footprint footprint, other optional "coverage/reachability" types of footprint
or "resource" types of footprint MAY be defined by future or "resource" types of footprint MAY be 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 an IANA registry is specified in the CDNI optional footprint types in an IANA registry is specified in the CDNI
Metadata Footprint Types registry (defined in the CDNI Metadata Metadata Footprint Types registry (defined in the CDNI Metadata
Interface document [I-D.ietf-cdni-metadata]). Interface document [I-D.ietf-cdni-metadata]).
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 are able include the connectivity of a given dCDN to other CDNs that are able
to serve content to users on behalf of that dCDN, to cover cases with to serve content to users on behalf of that dCDN, to cover cases with
cascaded CDNs. Further, the downstream CDN needs to be able to cascaded CDNs. Further, the dCDN needs to be able to express its
express its footprint to an interested upstream CDN (uCDN) in a footprint to an interested uCDN in a comprehensive form, e.g., as a
comprehensive form, e.g., as a data set containing the complete data set containing the complete footprint. Making incremental
footprint. Making incremental updates, however, to express dynamic updates, however, to express dynamic changes in state is also
changes in state is also desirable. 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 vs HTTPS delivery. supports a given service, for instance, HTTP vs HTTPS delivery.
Furthermore, the dCDN MUST be able to express particular capabilities Furthermore, the dCDN MUST be able to express particular capabilities
for the delivery in a particular footprint area. For example, the for the delivery in a particular footprint area. For example, the
dCDN might in general offer HTTPS but not in some specific areas, dCDN might in general offer HTTPS but not in some specific areas,
either for maintenance reasons or because the caches covering this either for maintenance reasons or because the caches covering this
particular area cannot deliver this type of service. Hence, in particular area cannot deliver this type of service. Hence, in
certain cases footprint and capabilities are tied together and cannot certain cases footprint and capabilities are tied together and cannot
be interpreted independently from each other. In such cases, i.e., be interpreted independently from each other. In such cases, i.e.,
where capabilities need to be expressed on a per footprint basis, it where capabilities need to be expressed on a per footprint basis, it
could be beneficial to combine footprint and capabilities could be beneficial to combine footprint and capabilities
advertisement. 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 dCDN is able (and willing) to accept (and properly
properly handle) a delegated content request. In addition, handle) a delegated content request. In addition, Capabilities are
Capabilities are characterized by the fact that this information can characterized by the fact that this information can change over time
change over time based on the state of the network or caches. based on the state of the network or 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) is beyond the scope for CDNI FCI. First, changing QoS information) is beyond the scope for CDNI FCI. First,
out of the multitude of possible metrics and capabilities, it is hard out of the multitude of possible metrics and capabilities, it is hard
to agree on a subset and the precise metrics to be used. Second, it to agree on a subset and the precise metrics to be used. Second, it
seems infeasible to specify such highly dynamically changing seems infeasible to specify such highly dynamically changing
capabilities and the corresponding metrics within a reasonable time- capabilities and the corresponding metrics within a reasonable time-
skipping to change at page 14, line 17 skipping to change at page 14, line 17
The notion of optional types of footprint and capabilities implies The notion of optional types of footprint and capabilities implies
that certain implementations might not support all kinds of footprint that certain implementations might 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 MUST specify how protocol. In particular, any FCI solution protocol MUST specify how
to handle failure cases or non-supported types of footprint/ to handle failure cases or non-supported types of footprint/
capabilities. capabilities.
In general, a uCDN MAY ignore capabilities or types of footprints it In general, a uCDN MAY ignore capabilities or types of footprints it
does not understand; in this case it only selects a suitable does not understand; in this case it only selects a suitable dCDN
downstream CDN based on the types of capabilities and footprint it based on the types of capabilities and footprint it understands.
understands. Similarly, if a dCDN does not use an optional Similarly, if a dCDN does not use an optional capability or footprint
capability or footprint which is, however, supported by a uCDN, this which is, however, supported by a uCDN, this causes no problem for
causes no problem for the FCI functionality because the uCDN decides the FCI functionality because the uCDN decides on the remaining
on the remaining capabilities/footprint information that is being capabilities/footprint information that is being conveyed by the
conveyed by the dCDN. dCDN.
7. Capability Advertisement Object 7. Capability Advertisement Object
To support extensibility, the FCI defines a generic base object To support extensibility, the FCI defines a generic base object
(similar to the CDNI Metadata interface GenericMetadata object) (similar to the CDNI Metadata interface GenericMetadata object)
[I-D.ietf-cdni-metadata] to facilitate a uniform set of mandatory [I-D.ietf-cdni-metadata] to facilitate a uniform set of mandatory
parsing requirements for all future FCI objects. parsing requirements for all future FCI objects.
Future object definitions (e.g. regarding CDNI Metadata or Logging) Future object definitions (e.g. regarding CDNI Metadata or Logging)
will build off the base object defined here, but will be specified in will build off the base object defined here, but will be specified in
 End of changes. 8 change blocks. 
40 lines changed or deleted 39 lines changed or added

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