One document matched: draft-ietf-cdni-footprint-capabilities-semantics-17.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<?rfc compact="no" ?>
<?rfc subcompact="no" ?>
<rfc category="std" docName="draft-ietf-cdni-footprint-capabilities-semantics-17" ipr="trust200902">
<front>
<title abbrev="CDNI RR Footprint/Capabilities Semantics">CDNI Request
Routing: Footprint and Capabilities Semantics</title>
<author fullname="Jan Seedorf" initials="J." surname="Seedorf">
<organization abbrev="NEC">NEC</organization>
<address>
<postal>
<street>Kurfuerstenanlage 36</street>
<code>69115</code>
<city>Heidelberg</city>
<country>Germany</country>
</postal>
<phone>+49 6221 4342 221</phone>
<facsimile>+49 6221 4342 155</facsimile>
<email>seedorf@neclab.eu</email>
</address>
</author>
<author fullname="Jon Peterson" initials="J." surname="Peterson">
<organization abbrev="Neustar">NeuStar</organization>
<address>
<postal>
<street>1800 Sutter St Suite 570</street>
<code>CA 94520</code>
<city>Concord</city>
<country>USA</country>
</postal>
<phone/>
<facsimile/>
<email>jon.peterson@neustar.biz</email>
</address>
</author>
<author fullname="Stefano Previdi" initials="S." surname="Previdi">
<organization abbrev="Cisco">Cisco Systems</organization>
<address>
<postal>
<street>Via Del Serafico 200</street>
<code>0144</code>
<city>Rome</city>
<country>Italy</country>
</postal>
<phone/>
<facsimile/>
<email>sprevidi@cisco.com</email>
</address>
</author>
<author fullname="Ray van Brandenburg" initials="R." surname="van Brandenburg">
<organization abbrev="TNO">TNO</organization>
<address>
<postal>
<street>Brassersplein 2</street>
<code>2612CT</code>
<city>Delft</city>
<country>The Netherlands</country>
</postal>
<phone>+31-88-866-7000</phone>
<email>ray.vanbrandenburg@tno.nl</email>
</address>
</author>
<author fullname="Kevin J. Ma" initials="K.J." surname="Ma">
<organization>Ericsson</organization>
<address>
<postal>
<street>43 Nagog Park</street>
<city>Acton</city>
<region>MA</region>
<code>01720</code>
<country>USA</country>
</postal>
<phone>+1 978-844-5100</phone>
<email>kevin.j.ma@ericsson.com</email>
</address>
</author>
<date year="2016"/>
<area>ART</area>
<workgroup>CDNI</workgroup>
<keyword>CDNI</keyword>
<keyword>CDN Interconnect</keyword>
<keyword>Request-Routing</keyword>
<abstract>
<t>This document captures the semantics of the "Footprint and
Capabilities Advertisement" part of the CDNI Request Routing interface,
i.e., the desired meaning of "Footprint" and "Capabilities" in the CDNI context, and what the "Footprint and Capabilities
Advertisement Interface (FCI)" offers within CDNI. The document
also provides guidelines for the CDNI FCI protocol. It further
defines a Base Advertisement Object, the necessary registries
for capabilities and footprints, and guidelines on how these registries can be extended in the future.</t>
</abstract>
<note title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction and Scope">
<t>The CDNI working group is working on a set of protocols to enable the
interconnection of multiple CDNs. This
CDN interconnection (CDNI) can serve multiple purposes, as discussed in <xref
target="RFC6770"/>, for instance, to extend the reach of
a given CDN to areas in the network which are not covered by this
particular CDN.</t>
<t>The goal of this document is to achieve a clear understanding about the semantics associated with the CDNI Request Routing
Footprint & Capabilities Advertisement Interface (from now on
referred to as FCI), in particular the type of information a downstream
CDN (dCDN) 'advertises' regarding its footprint and capabilities. To narrow
down undecided aspects of these semantics, this document tries to
establish a common understanding of what the FCI needs to offer and
accomplish in the context of CDNI. </t>
<t>It is explicitly outside the scope of this document to decide on
specific protocols to use for the FCI. However, guidelines for such FCI protocols are provided.</t>
<t>General assumptions in this document: <list style="symbols">
<t>The CDNs participating in the interconnected CDN have already
performed a boot strap process, i.e., they have connected to each
other, either directly or indirectly, and can exchange information
amongst each other.</t>
<t>The upstream CDN (uCDN) receives footprint and/or capability advertisements
from a set of dCDNs. Footprint advertisement and capability
advertisement need not use the same underlying protocol.</t>
<t>The uCDN receives the initial request-routing
request from the endpoint requesting the resource.</t>
</list></t>
<t>The CDNI Problem Statement <xref target="RFC6707"/> describes
the Request Routing Interface as: "[enabling] a Request
Routing function in a uCDN to query a Request Routing function
in a dCDN to determine if the dCDN is able (and
willing) to accept the delegated Content Request". In addition,
RFC6707 says "the CDNI Request Routing interface is also expected to enable a
dCDN to provide to the uCDN (static or dynamic)
information (e.g., resources, footprint, load) to facilitate selection of
the dCDN by the uCDN request routing system when
processing subsequent content requests from User Agents". It thus
considers "resources" and "load" as capabilities to be advertised by the
dCDN.</t>
<t>The range of different footprint definitions and possible capabilities
is very broad. Attempting to define a comprehensive advertisement
solution quickly becomes intractable. The CDNI requirements draft
<xref target="RFC7337"/> lists the specific
requirements for the CDNI Footprint & Capabilities Advertisement
Interface in order to disambiguate footprints and capabilities with
respect to CDNI. This document defines a common
understanding of what the terms 'footprint' and 'capabilities' mean in
the context of CDNI, and details the semantics of the footprint
advertisement mechanism and the capability advertisement mechanism.</t>
<section anchor="terminology" title="Terminology">
<t>This document reuses the terminology defined in <xref
target="RFC6707"/>.</t>
<t>Additionally, the following terms are used throughout this document
and are defined as follows:<list style="symbols">
<t>Footprint: a description of a CDN's coverage area,
i.e., the area from which client requests may originate
for, and to which the CDN is willing to deliver, content.
Note: There are many ways to describe a footprint, for
example, by address range (e.g., IPv4/IPv6 CIDR), by
network ID (e.g., ASN), by nation boundaries (e.g.,
country code), by GPS coordinates, etc. This document
does not define or endorse the quality or suitability of
any particular footprint description method; this document
only defines a method for transporting known footprint
descriptions in Footprint and Capabilities Advertisement
messages.</t>
<t>Capability: a feature of a dCDN, upon which a uCDN relies
on the dCDN supporting, when making delegation decisions.
Support for a given feature can change over time and can
be restricted to a limited portion of a dCDN's footprint.
Note: There are many possible dCDN features that could be
of interest to a uCDN. This document does not presume to
define them all; this document describes a scheme for
defining new capabilities and how to transport them in
Footprint and Capabilities Advertisement messages.</t>
</list></t>
</section>
</section>
<section anchor="sec.designdecisions"
title="Design Decisions for Footprint and Capabilities">
<t>A large part of the difficulty in discussing the FCI lies in
understanding what exactly is meant when trying to define footprint in
terms of "coverage" or "reachability." While the operators of CDNs pick
strategic locations to situate caches, a cache with a public IPv4
address is reachable by any endpoint on the Internet unless some policy
enforcement precludes the use of the cache.</t>
<t>Some CDNs aspire to cover the entire world; we refer to these as
global CDNs. The footprint advertised by such a CDN in the CDNI
environment would, from a coverage or reachability perspective,
presumably cover all prefixes. Potentially more interesting for CDNI use
cases, however, are CDNs that claim a more limited coverage, but seek to
interconnect with other CDNs in order to create a single CDN fabric which
shares resources.</t>
<t>Furthermore, not all capabilities need to be footprint restricted.
Depending upon the use case, the optimal semantics of "footprints with
capability attributes" vs. "capabilities with footprint restrictions"
are not clear.</t>
<t>The key to understanding the semantics of footprint and capability
advertisement lies in understanding why a dCDN would advertise a limited
coverage area, and how a uCDN would use such advertisements to decide
among one of several dCDNs. The following section will discuss some of
the trade-offs and design decisions that need to be decided upon for the
CDNI FCI. </t>
<section anchor="sec.advertisinglimcoverage"
title="Advertising Limited Coverage">
<t>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 of the Internet. For example, an ISP could purpose-build a CDN
to serve only their own customers by situating caches in close
topological proximity to high concentrations of their subscribers. 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 to
serve.</t>
<t>When such a purpose-built CDN interconnects with other CDNs and
advertises its footprint to a uCDN, however, the original intended coverage of
the CDN might not represent its actual value to the interconnection of
CDNs. Consider an ISP-A and ISP-B that both field their own CDNs,
which they interconnect via CDNI. A given user E, who is a customer of
ISP-B, might happen to be topologically closer to a cache fielded by
ISP-A, if E happens to live in a region where ISP-B has few customers
and ISP-A has many. In this case, is it ISP-A's CDN that "covers" E? If
ISP-B's CDN has a failure condition, is it up to the uCDN to understand that
ISP-A's caches are potentially available as back-ups - and if so, how
does ISP-A advertise itself as a "standby" for E? What about the case
where CDNs advertising to the same uCDN express overlapping coverage
(for example, mixing global and limited CDNs)?</t>
<t>The answers to these questions greatly depend on how much
information the uCDN wants to use to make a selection of a dCDN. If
a uCDN has three dCDNs to choose from that "cover" the IP address of
user E, obviously the uCDN might be interested to know how optimal the
coverage is from each of the dCDNs - coverage need not be binary,
either provided or not provided. dCDNs could advertise a coverage
"score," for example, and provided that they all reported scores
fairly on the same scale, uCDNs could use that to make their
topological optimality decision. Alternately, dCDNs could
advertise the IP addresses of their caches rather than
prefix "coverage," and let the uCDN decide for itself (based on its
own topological intelligence) which dCDN has better resources to serve
a given user.</t>
<t>In summary, the semantics of advertising footprint depend on
whether such qualitative metrics for expressing footprint (such as
the coverage 'score' mentioned above) are included as part of the CDNI FCI,
or if the focus is just on 'binary' footprint.</t>
</section>
<section anchor="sec.capanddyndata"
title="Capabilities and Dynamic Data">
<t>In cases where the apparent footprints of dCDNs overlap, uCDNs
might also want to rely on other factors to evaluate the
respective merits of dCDNs. These include facts related 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 the
respective networks.</t>
<t>In the absence of network-layer impediments to reaching caches, the
choice to limit coverage is necessarily an administrative policy. Much
policy needs to be agreed upon before CDNs can interconnect,
including questions of membership, compensation, volumes, and so on. A
uCDN certainly will factor these sorts of considerations into its
decision to select a dCDN, but there is probably little need for dCDNs
to actually advertise them through an interface - they will be settled
out-of-band as a precondition for interconnection.</t>
<t>Other facts about the dCDN would be expressed through the interface
to the uCDN. Some capabilities of a dCDN are static, and some are
highly dynamic. Expressing the total storage built into its caches,
for example, changes relatively rarely, whereas the amount of storage in
use at any given moment is highly volatile. Network bandwidth
similarly could be expressed as either total bandwidth available to a
cache, or based on the current state of the network. A cache can at
one moment lack a particular resource in storage, but have it the
next.</t>
<t>The semantics of the capabilities interface will depend on how much
of the dCDN state needs to be pushed to the uCDN and qualitatively how
often that information needs to be updated.</t>
</section>
<section anchor="sec.advertisingqueries"
title="Advertisement versus Queries">
<t>In a CDNI environment, each dCDN shares some of its state
with the uCDN. The uCDN uses this information to build a unified picture of all
of the dCDNs available to it. In architectures that share detailed
capability information, the uCDN could perform the entire
request-routing operation down to selecting a particular cache
in the dCDN. However, when the uCDN needs to deal with many potential
dCDNs, this approach does not scale, especially for dCDNs with
thousands or tens of thousands of caches; the
volume of updates to footprint and capability becomes onerous.</t>
<t>Were the volume of FCI updates from dCDNs to exceed the volume of requests to the
uCDN, it might make more sense for the uCDN to query dCDNs upon
receiving requests (as is the case in the recursive redirection mode
described in <xref target="RFC7336"/>), instead of
receiving advertisements and tracking the state of dCDNs. The
advantage 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
decision. dCDNs need not replicate any state to the uCDN - uCDNs could
effectively operate in a stateless mode.</t>
<t>The semantics of both footprint and capability advertisement depend
on the service model here: are there cases where a synchronous
query/response model would work better for the uCDN decision than a
state replication model?</t>
</section>
<section anchor="sec.cheating"
title="Avoiding or Handling 'cheating' dCDNs">
<t>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
sense that the dCDN provides inaccurate information to the uCDN in
order to convince the uCDN to select it over 'competing' dCDNs.
It could therefore be desirable to take away the incentive for dCDNs
to cheat (in information advertised) as much as possible. One option
is to make the information the dCDN advertises somehow verifiable
for the uCDN. On the other hand, a cheating dCDN might be avoided or
handled by the fact that there will be strong contractual agreements
between a uCDN and a dCDN, so that a dCDN would risk severe penalties
or legal consequences when caught cheating.</t>
<t>Overall, the information a dCDN advertises (in the
long run) needs to be somehow qualitatively verifiable by the uCDN, though
possibly through non-real-time out-of-band audits. It is probably
an overly strict requirement to mandate that such verification be
possible "immediately", i.e., during the request routing process
itself. If the uCDN can detect a cheating dCDN at a later stage, it
might suffice for the uCDN to "de-incentivize" cheating because it
would negatively affect the long-term business relationship with a
particular dCDN.</t>
</section>
<section anchor="sec.decision"
title="Focusing on Capabilities with Footprint Restrictions">
<t>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 routing
based on information the uCDN has received from this particular dCDN.
It can be assumed that 'cheating' CDNs will be dealt with via means
outside the scope of CDNI and that the information advertised between
CDNs is accurate. In addition, excluding the use of qualitative
information (e.g., cache proximity, delivery latency, cache load)
to predict the quality of delivery would further simplify the use case
allowing it to better focus on the basic functionality of the
FCI.</t>
<t>Further understanding that in most cases contractual agreements will
define the basic coverage used in delegation decisions, the
primary focus of FCI is on providing updates to the basic
capabilities and coverage by the dCDNs. As such, FCI has
choosen the semantics of "capabilities with footprint restrictions".</t>
</section>
</section>
<section anchor="sec.capabilities" title="Footprint and Capabilities Extension">
<t>Other optional "coverage/reachability" types of
footprint or "resource" types of footprint may be defined by future
specifications. To facilitate this, a clear process for
specifying optional footprint types in an IANA registry is
specified in
the CDNI Metadata Footprint Types registry (defined in the CDNI Metadata
Interface document <xref target="I-D.ietf-cdni-metadata"/>).</t>
<t>This document also registers CDNI
Payload Types <xref target="RFC7736"/> for the initial
capability types (see <xref target="sec.IANA"/>):</t>
<t><list style="symbols">
<t>Delivery Protocol (for delivering content to the end user)</t>
<t>Acquisition Protocol (for acquiring content from the uCDN
or origin server)</t>
<t>Redirection Mode (e.g., DNS Redirection vs. HTTP Redirection as
discussed in <xref target="RFC7336"/>)</t>
<t>CDNI Logging (i.e., supported logging fields)</t>
<t>CDNI Metadata (i.e., supported Generic Metadata types)</t>
</list></t>
<t>Each payload type is prefaced with "FCI.". Updates to
capability objects MUST indicate the version of the capability
object in a newly registered payload type, e.g., by appending
".v2". Each capability type MAY have a list of valid
values. Future specifications which define a given capability
MUST define any necessary registries (and the rules for adding
new entries to the registry) for the values advertised for a
given capability type.</t>
<t>The "CDNI Logging record-types" registry
<xref target="I-D.ietf-cdni-logging" /> defines all known record
types, including mandatory-to-implement record-types
Advertising support for mandatory-to-implement record-types
would be redundant. CDNs SHOULD NOT
advertise support for mandatory-to-implement record-types.</t>
<t>The "CDNI Logging Fields Names" registry
<xref target="I-D.ietf-cdni-logging" /> defines all known
logging fields.
Logging fields may be reused by different record-types
and be mandatory-to-implement in some record-types, but optional
in other record-types. CDNs MUST advertise support for optional
logging fields within the context of a specific
record-type. CDNs SHOULD NOT
advertise support for mandatory-to-implement logging fields, for
a given record-type.
The following logging fields are defined as optional for the
"cdni_http_request_v1" record-type in the CDNI Logging Interface document
<xref target="I-D.ietf-cdni-logging" />:<list style="symbols">
<t>s-ccid</t>
<t>s-sid</t>
</list></t>
<t>The CDNI Metadata Interface document
<xref target="I-D.ietf-cdni-metadata" /> requires that CDNs be
able to parse all the defined metadata objects, but does not
require dCDNs to support enforcement of non-structural
GenericMetadata objects. Advertising support for
mandatory-to-enforce GenericMetadata types MUST be
supported. Advertising support for
non-mandatory-to-enforce GenericMetadata types SHOULD be
supported. Advertisement of non-mandatory-to-enforce
GenericMetadata MAY be necessary, e.g., to signal temporary
outages and subsequent recovery. It is expected that
structural metadata will be supported at all times.</t>
<t>The notion of optional types of footprint and
capabilities implies that certain implementations might 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 MUST specify how to handle failure cases or non-supported types of footprint/capabilities. </t>
<t>In general, a uCDN MAY ignore capabilities or types of footprints it does not understand; in this case it only selects a suitable dCDN 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. </t>
</section>
<section anchor="sec.object" title="Capability Advertisement Object">
<t>To support extensibility, the FCI defines a generic base
object (similar to the CDNI Metadata interface GenericMetadata
object) <xref target="I-D.ietf-cdni-metadata" /> to facilitate
a uniform set of mandatory parsing requirements for all future
FCI objects.</t>
<t>Future object definitions (e.g. regarding CDNI Metadata or Logging) will build off the base
object defined here, but will be specified in separate documents.</t>
<section anchor="sec.baseObject" title="Base Advertisement Object">
<t>The FCIBase object is an abstraction for managing
individual CDNI capabilities in an opaque manner.</t>
<t><list style="empty">
<t>Property: capability-type<list style="empty">
<t>Description: CDNI Capability object type.</t>
<t>Type: FCI specific CDNI Payload type (from the CDNI
Payload Types registry
<xref target="RFC7736"/>)</t>
<t>Mandatory-to-Specify: Yes.</t>
</list></t>
</list> <list style="empty">
<t>Property: capability-value<list style="empty">
<t>Description: CDNI Capability object.</t>
<t>Type: Format/Type is defined by the value of
capability-type property above.</t>
<t>Mandatory-to-Specify: Yes.</t>
</list></t>
</list> <list style="empty">
<t>Property: footprints<list style="empty">
<t>Description: CDNI Capability Footprint.</t>
<t>Type: List of CDNI Footprint objects (as defined
in <xref target="I-D.ietf-cdni-metadata"/>).</t>
<t>Mandatory-to-Specify: No.</t>
</list></t>
</list></t>
</section>
<section anchor="sec.deliveryProtocolObject" title="Delivery Protocol Capability Object">
<t>The Delivery Protocol capability object is used to
indicate support for one or more of the protocols listed in the
CDNI Metadata Protocol Types registry (defined in the CDNI Metadata
Interface document <xref target="I-D.ietf-cdni-metadata"/>).</t>
<t><list style="empty">
<t>Property: delivery-protocols<list style="empty">
<t>Description: List of supported CDNI Delivery Protocols.</t>
<t>Type: List of Protocol Types (from the CDNI
Metadata Protocol Types registry
<xref target="I-D.ietf-cdni-metadata"/>)</t>
<t>Mandatory-to-Specify: Yes.</t>
</list></t>
</list></t>
<section anchor="sec.deliverySerialization" title="Delivery Protocol Capability Object Serialization">
<t>The following shows an example of Delivery Protocol Capability
Object Serialization, for a CDN that supports only HTTP/1.1
without TLS for content delivery.</t>
<t><figure>
<artwork><![CDATA[{
"capabilities": [
{
"capability-type": "FCI.DeliveryProtocol",
"capability-value": {
"delivery-protocols": [
"http1.1",
]
},
"footprints": [
<Footprint objects>
]
}
]
}]]>
</artwork>
</figure></t>
</section>
</section>
<section anchor="sec.acquisitionProtocolObject" title="Acquisition Protocol Capability Object">
<t>The Acquisition Protocol capability object is used to
indicate support for one or more of the protocols listed in the
CDNI Metadata Protocol Types registry (defined in the CDNI Metadata
Interface document <xref target="I-D.ietf-cdni-metadata"/>).</t>
<t><list style="empty">
<t>Property: acquisition-protocols<list style="empty">
<t>Description: List of supported CDNI Acquisition Protocols.</t>
<t>Type: List of Protocol Types (from the CDNI
Metadata Protocol Types registry
<xref target="I-D.ietf-cdni-metadata"/>)</t>
<t>Mandatory-to-Specify: Yes.</t>
</list></t>
</list></t>
<section anchor="sec.acquisitionSerialization" title="Acquisition Protocol Capability Object Serialization">
<t>The following shows an example of Acquisition Protocol Capability
Object Serialization, for a CDN that supports HTTP/1.1 with
or without TLS for content acquisition.</t>
<t><figure>
<artwork><![CDATA[{
"capabilities": [
{
"capability-type": "FCI.AcquisitionProtocol",
"capability-value": {
"acquisition-protocols": [
"http1.1",
"https1.1"
]
},
"footprints": [
<Footprint objects>
]
}
]
}]]>
</artwork>
</figure></t>
</section>
</section>
<section anchor="sec.redirectionModeObject" title="Redirection Mode Capability Object">
<t>The Redirection Mode capability object is used to
indicate support for one or more of the modes listed in the
CDNI Capabilities Redirection Modes registry (see
<xref target="iana.redirectionModeRegistry"/>).</t>
<t><list style="empty">
<t>Property: redirection-modes<list style="empty">
<t>Description: List of supported CDNI Redirection Modes.</t>
<t>Type: List of Redirection Modes (from <xref
target="iana.redirectionModeRegistry"></xref>)</t>
<t>Mandatory-to-Specify: Yes.</t>
</list></t>
</list></t>
<section anchor="sec.redirectionSerialization" title="Redirection Mode Capability Object Serialization">
<t>The following shows an example of Redirection Mode Capability
Object Serialization, for a CDN that supports only iterative
(but not recursive) redirection with HTTP and DNS.</t>
<t><figure>
<artwork><![CDATA[{
"capabilities": [
{
"capability-type": "FCI.RedirectionMode",
"capability-value": {
"redirection-modes": [
"DNS-I",
"HTTP-I"
]
}
"footprints": [
<Footprint objects>
]
}
]
}]]>
</artwork>
</figure></t>
</section>
</section>
<section anchor="sec.loggingObject" title="CDNI Logging Capability Object">
<t>The CDNI Logging capability object is used to
indicate support for CDNI Logging record-types, as well
as CDNI Logging fields which are marked as optional for
the specified record-types
<xref target="I-D.ietf-cdni-logging"/>.</t>
<t><list style="empty">
<t>Property: record-type
<list style="empty">
<t>Description: Supported CDNI Logging record-type.</t>
<t>Type: String corresponding to an entry from the CDNI
Logging record-types registry
<xref target="I-D.ietf-cdni-logging"/>)</t>
<t>Mandatory-to-Specify: Yes.</t>
</list></t>
<t>Property: fields
<list style="empty">
<t>Description: List of supported CDNI Logging
fields that are optional for the specified record-type.</t>
<t>Type: List of Strings corresponding to entries
from the CDNI Logging Field Names registry
<xref target="I-D.ietf-cdni-logging"/>.</t>
<t>Mandatory-to-Specify: No. Default is that all
optional fields are supported. Inclusion of an
empty list SHALL be understood to mean that none of
the optional fields are supported. Otherwise, only
those optional fields that are listed SHALL be
understood to be supported.</t>
</list></t>
</list></t>
<section anchor="sec.loggingSerialization" title="CDNI Logging Capability Object Serialization">
<t>The following shows an example of CDNI Logging Capability
Object Serialization, for a CDN that supports the optional Content
Collection ID logging field (but not the optional Session ID
logging field) for the "cdni_http_request_v1" record type.</t>
<t><figure>
<artwork><![CDATA[{
"capabilities": [
{
"capability-type": "FCI.Logging",
"capability-value": {
"record-type": "cdni_http_request_v1",
"fields": [ "s-ccid" ]
},
"footprints": [
<Footprint objects>
]
}
]
}]]>
</artwork>
</figure></t>
<t>The next example shows the CDNI Logging Capability
Object Serialization, for a CDN that supports all
optional fields for the "cdni_http_request_v1" record type.</t>
<t><figure>
<artwork><![CDATA[{
"capabilities": [
{
"capability-type": "FCI.Logging",
"capability-value": {
"record-type": "cdni_http_request_v1"
},
"footprints": [
<Footprint objects>
]
}
]
}]]>
</artwork>
</figure></t>
</section>
</section>
<section anchor="sec.metadataObject" title="CDNI Metadata Capability Object">
<t>The CDNI Metadata capability object is used to
indicate support for CDNI GenericMetadata types
<xref target="I-D.ietf-cdni-metadata"/>.</t>
<t><list style="empty">
<t>Property: metadata
<list style="empty">
<t>Description: List of supported CDNI
GenericMetadata types.</t>
<t>Type: List of Strings corresponding to entries
from the CDNI Payload Type registry
<xref target="RFC7736"/>) that correspond to CDNI
GenericMetadata objects.</t>
<t>Mandatory-to-Specify: Yes. It SHALL
be understood that only those GenericMetadata types
listed are supported; an empty list SHALL be
understood to mean that only
structural metadata and simple types are supported
<xref target="I-D.ietf-cdni-metadata"/>.</t>
</list></t>
</list></t>
<section anchor="sec.metadataSerialization" title="CDNI Metadata Capability Object Serialization">
<t>The following shows an example of CDNI Metadata Capability
Object Serialization, for a CDN that supports only the
SourceMetadata GenericMetadata type (i.e., it can
acquire and deliver content, but cannot enforce and
security policies, e.g., time, location, or protocol ACLs).</t>
<t><figure>
<artwork><![CDATA[{
"capabilities": [
{
"capability-type": "FCI.Metadata",
"capability-value": {
"metadata": ["MI.SourceMetadata"]
},
"footprints": [
<Footprint objects>
]
}
]
}]]>
</artwork>
</figure></t>
<t>The next example shows the CDNI Metadata Capability
Object Serialization, for a CDN that supports only
structural metadata (i.e., it can parse metadata as a
transit CDN, but cannot enforce security policies or
deliver content).</t>
<t><figure>
<artwork><![CDATA[{
"capabilities": [
{
"capability-type": "FCI.Metadata",
"capability-value": {
"metadata": []
},
"footprints": [
<Footprint objects>
]
}
]
}]]>
</artwork>
</figure></t>
</section>
</section>
</section>
<section anchor="sec.IANA" title="IANA Considerations">
<section anchor="sec.IANA.payload" title="CDNI Payload Types">
<t>This document requests the registration of the following CDNI
Payload Types under the IANA CDNI Payload Type registry:</t>
<texttable>
<ttcol align="left">Payload Type</ttcol>
<ttcol align="left">Specification</ttcol>
<c>FCI.DeliveryProtocol</c>
<c>RFCthis</c>
<c>FCI.AcquisitionProtocol</c>
<c>RFCthis</c>
<c>FCI.RedirectionMode</c>
<c>RFCthis</c>
<c>FCI.Logging</c>
<c>RFCthis</c>
<c>FCI.Metadata</c>
<c>RFCthis</c>
</texttable>
<t>[RFC Editor: Please replace RFCthis with the published RFC
number for this document.]</t>
<section anchor="sec.IANA.payload.delivery" title="CDNI FCI DeliveryProtocol Payload Type">
<t>Purpose: The purpose of this payload type is to
distinguish FCI advertisement objects for supported delivery protocols</t>
<t>Interface: FCI</t>
<t>Encoding: see <xref target="sec.deliveryProtocolObject"/></t>
</section>
<section anchor="sec.IANA.payload.acquisition" title="CDNI FCI AcquisitionProtocol Payload Type">
<t>Purpose: The purpose of this payload type is to
distinguish FCI advertisement objects for supported acquisition protocols</t>
<t>Interface: FCI</t>
<t>Encoding: see <xref target="sec.acquisitionProtocolObject"/></t>
</section>
<section anchor="sec.IANA.payload.redirection" title="CDNI FCI RedirectionMode Payload Type">
<t>Purpose: The purpose of this payload type is to
distinguish FCI advertisement objects for supported redirection modes</t>
<t>Interface: FCI</t>
<t>Encoding: see <xref target="sec.redirectionModeObject"/></t>
</section>
<section anchor="sec.IANA.payload.logging" title="CDNI FCI Logging Payload Type">
<t>Purpose: The purpose of this payload type is to
distinguish FCI advertisement objects for supported CDNI
Logging record-types and optional CDNI Logging Field Names.</t>
<t>Interface: FCI</t>
<t>Encoding: see <xref target="sec.loggingObject"/></t>
</section>
<section anchor="sec.IANA.payload.metadata" title="CDNI FCI Metadata Payload Type">
<t>Purpose: The purpose of this payload type is to
distinguish FCI advertisement objects for supported CDNI
GenericMetadata types.</t>
<t>Interface: FCI</t>
<t>Encoding: see <xref target="sec.metadataObject"/></t>
</section>
</section>
<section anchor="iana.redirectionModeRegistry" title="Redirection Mode Registry">
<t>The IANA is requested to create a new "CDNI Capabilities
Redirection Modes" registry in the "Content Delivery Networks
Interconnection (CDNI) Parameters" category. The "CDNI
Capabilities Redirection Modes" namespace defines the
valid redirection modes that can be advertised as supported by a CDN.
Additions to the Redirection Mode namespace conform to the
"IETF Review" policy as defined in <xref target="RFC5226"/>.</t>
<t>The following table defines the initial Redirection Modes:</t>
<texttable>
<ttcol align='left'>Redirection Mode</ttcol>
<ttcol align='left'>Description</ttcol>
<ttcol align='left'>RFC</ttcol>
<c>DNS-I</c>
<c>Iterative DNS-based Redirection</c>
<c>RFCthis</c>
<c>DNS-R</c>
<c>Recursive DNS-based Redirection</c>
<c>RFCthis</c>
<c>HTTP-I</c>
<c>Iterative HTTP-based Redirection</c>
<c>RFCthis</c>
<c>HTTP-R</c>
<c>Recursive HTTP-based Redirection</c>
<c>RFCthis</c>
</texttable>
<t>[RFC Editor: Please replace RFCthis with the published RFC
number for this document.]</t>
</section>
</section>
<section title="Security Considerations">
<t>This specification describes the semantics for capabilities and footprint
advertisement objects across interconnected CDNs. It does not,
however, specify a concrete protocol for transporting those objects. Specific security mechanisms can only be
selected for concrete protocols that instantiate these semantics. This
document does, however, place some high-level security constraints on such
protocols.</t>
<t>All protocols that implement these semantics are REQUIRED to provide
integrity and authentication services. Without authentication and
integrity, an attacker could trivially deny service by forging a footprint
advertisement from a dCDN which claims the network has no footprint or
capability. This would prevent the uCDN from delegating any requests to the
dCDN. Since a pre-existing relationship between all dCDNs and uCDNs is
assumed by CDNI, the exchange of any necessary credentials could be
conducted before the FCI interface is brought online. The authorization
decision to accept advertisements would also follow this pre-existing
relationship and any contractual obligations that it stipulates.</t>
<t>All protocols that implement these semantics are REQUIRED to
provide confidentiality services. Some dCDNs are willing to share
information about their footprint or capabilities with a uCDN but
not with other, competing dCDNs. For example, if a dCDN incurs an outage
that reduces footprint coverage temporarily, that could be information the
dCDN would want to share confidentially with the uCDN.</t>
<t>As specified in this document, the security requirements of the FCI could
be met by hop-by-hop transport-layer security mechanisms coupled with
domain certificates as credentials (e.g., TLS transport for HTTP as per
<xref target="RFC2818"/> and <xref target="RFC7230"/>, with usage guidance
from <xref target="RFC7525"/>). There is no apparent need for further
object-level security in this framework, as the trust relationships it
defines are bilateral relationships between uCDNs and dCDNs rather than
transitive relationships.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.2818" ?>
<?rfc include="reference.RFC.5226" ?>
<?rfc include="reference.RFC.7230" ?>
<?rfc include="reference.RFC.7525" ?>
<?rfc include="reference.I-D.ietf-cdni-metadata"?>
<?rfc include="reference.I-D.ietf-cdni-logging"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.6707" ?>
<?rfc include="reference.RFC.6770" ?>
<?rfc include="reference.RFC.7337" ?>
<?rfc include="reference.RFC.7336" ?>
<?rfc include="reference.RFC.7736" ?>
</references>
<section anchor="sec.usecaseexample"
title="Main Use Case to Consider">
<t>Focusing on a main use case that contains a simple (yet somewhat challenging), realistic, and generally imaginable scenario can help in narrowing down the requirements for the CDNI FCI. To this end, the following (simplified) use case can help in clarifying the semantics of footprint and capabilities for CDNI. In particular, the 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 supported in a mandatory fashion (and which can be considered optional), and what types of information need to be updated with respect to a priori established CDNI contracts. </t>
<t>Use case: A given uCDN has several dCDNs. It selects one dCDN for delivery protocol A and footprint 1 and another dCDN for delivery protocol B and footprint 1. The dCDN that serves delivery protocol B has a further, transitive (level-2) dCDN, that serves delivery protocol B in a subset of footprint 1 where the first-level dCDN cannot serve delivery protocol B itself. What happens if capabilities change in the transitive 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 anymore)? How will these changes be 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 footprint 1 or only for the subset of footprint 1 that the transitive level-2 dCDN served on behalf of the first-level dCDN?</t>
</section>
<section anchor="sec.semantics_footprint"
title="Semantics for Footprint Advertisement">
<t>Roughly speaking, "footprint" can be defined as "ability and willingness to
serve" by a dCDN. However, in addition to simple "ability and willingness
to serve", the uCDN could want additional information to make a
dCDN selection decision, e.g., "how well" a given dCDN can actually serve
a given end user request. The "ability and willingness" to
serve SHOULD be distinguished
from the subjective qualitative measurement of "how well" it was served.
One can imagine that such additional information is implicitly associated
with a given footprint, due to contractual agreements, SLAs,
business relationships, or past perceptions of dCDN quality. As an
alternative, such additional information could also be explicitly tagged
along with the footprint.</t>
<t>It is reasonable to assume that a significant part of the actual
footprint advertisement will happen in contractual agreements between
participating CDNs, prior to the advertisement phase using the CDNI
FCI. The reason for this assumption is that any contractual agreement is
likely to contain specifics about the dCDN coverage (footprint)
to which the contractual agreement applies. In particular,
additional information to judge the delivery quality associated with a
given dCDN footprint might be defined in contractual agreements,
outside of the CDNI FCI. Further, one can assume that dCDN contractual
agreements about the delivery quality associated with a given footprint
will probably be based on high-level aggregated statistics and not too
detailed.</t>
<t>Given that a large part of footprint advertisement will actually
happen in contractual agreements, the semantics of CDNI footprint
advertisement refer to answering the following question: what exactly
still needs to be advertised by the CDNI FCI? For instance, updates
about temporal failures of part of a footprint can be useful information
to convey via the CDNI request routing interface. Such information would
provide updates on information previously agreed in contracts between
the participating CDNs. In other words, the CDNI 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.</t>
<t>Generally speaking, one can imagine two categories of footprint to be
advertised by a dCDN:
<list style="symbols">
<t>Footprint could be defined based on
"coverage/reachability", where coverage/reachability refers to a set
of prefixes, a geographic region, or similar boundary. The dCDN claims that it can
cover/reach 'end user requests coming from this footprint'.</t>
<t>Footprint could be defined based on "resources", where resources
refers to surrogates/caches a dCDN claims to have (e.g., the
location of surrogates/resources). The dCDN claims that 'from this footprint' it can serve
incoming end user requests.</t>
</list>
</t>
<t>For each of these footprint types, there are capabilities associated with a given footprint:
<list style="symbols">
<t>capabilities such as delivery protocol, redirection mode,
and metadata, which are supported in the coverage area for a
"coverage/reachability" defined footprint, or</t>
<t>capabilities of
resources, such as delivery protocol, redirection mode, and
metadata, which apply to a "resource" defined footprint.</t>
</list>
</t>
<t>"Resource" types of footprints are more specific than
"coverage/reachability" types of footprints, where the actual
coverage/reachability are extrapolated from the resource
location (e.g., netmask applied to resource IP address to derive
IP-prefix). The specific methods for extrapolating
coverage/reachability from resource location are beyond the
scope of this document. In the degenerate case, the resource
address could be specified as a coverage/reachability type of
footprint, in which case no extrapolation is necessary.
Resource types of footprints could expose the internal structure
of a CDN network which could be undesirable. As such, the
resource types of footprints are not considered mandatory to
support for CDNI.</t>
<t>
Footprints can be viewed as constraints for delegating requests to a dCDN: A dCDN footprint advertisement tells the uCDN the limitations for 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 candidate only if the IP address of the request routing source falls within the prefix set (or ASN, respectively). The CDNI specifications do not define how a given uCDN determines what address 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 the request routing source. The CDNI specifications do not define how a given uCDN determines the country of the request routing source. Multiple footprint constraints are additive: the advertisement of different types of footprint narrows the dCDN candidacy cumulatively.
</t>
<t>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
to serve content to users on behalf of that dCDN, to cover cases with
cascaded CDNs. Further, the dCDN
needs to be able to express its footprint to an interested uCDN
in a comprehensive form, e.g., as a data set containing
the complete footprint. Making incremental updates, however, to express
dynamic changes in state is also desirable.</t>
</section>
<section anchor="sec.semantics_capabilities"
title="Semantics for Capabilities Advertisement">
<t>In general, the dCDN needs to be able to express its general capabilities
to the uCDN. These general capabilities could express if the dCDN
supports a given service, for instance, HTTP vs HTTPS delivery.
Furthermore, the dCDN needs to be able to express particular
capabilities for the delivery in a particular footprint area. For
example, the dCDN might in general offer HTTPS but not in some specific
areas, either for maintenance reasons or because the caches covering
this particular area cannot deliver this type of service. Hence, in
certain cases footprint and capabilities are tied together and cannot be
interpreted independently from each other. In such cases, i.e., where
capabilities need to be expressed on a per footprint basis, it could be
beneficial to combine footprint and capabilities advertisement.</t>
<t>A high-level and very rough semantic for capabilities is thus the
following: Capabilities are types of information that allow a uCDN to
determine if a dCDN is able (and willing) to accept (and
properly handle) a delegated content request. In addition, Capabilities
are characterized by the fact that this information can change
over time based on the state of the network or caches.</t>
<t>At a first glance, several broad categories of capabilities seem
useful to convey via an advertisement interface, however, advertising
capabilities
that change highly dynamically (e.g., real-time delivery performance
metrics, CDN resource load, or other highly dynamically changing QoS
information) is beyond the scope for CDNI FCI. First,
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 seems infeasible to specify such highly
dynamically changing capabilities and the corresponding metrics within
a reasonable time-frame.</t>
<t>Useful capabilities refer to information that does not change highly
dynamically and which in many cases is absolutely necessary to decide 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 certain
protocol, the uCDN needs to know if a given dCDN has the
capability of supporting this delivery protocol.</t>
<t>Similar to footprint advertisement, it is reasonable to assume that a
significant part of the actual (resource) capabilities advertisement
will happen in contractual agreements between participating CDNs, i.e.,
prior to the advertisement phase using the CDNI FCI. The role 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 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 delivery
protocol is suddenly not being supported anymore due to failures).
Capabilities advertisement thus refers to conveying information to a
uCDN about changes/updates of certain capabilities with respect to a
given contract.</t>
<t>Given these semantics, it needs to be decided what exact capabilities
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
interface are better off being agnostic to these contracts anyway), it
remains to be seen what capabilities will be used to define agreements
between CDNs in practice. One implication for standardization could be to
initially only specify a very limited set of mandatory capabilities for
advertisement and have on top of that a flexible data model that allows
exchanging additional capabilities when needed. Still, agreement needs
to be found on which capabilities (if any) will be mandatory among
CDNs.</t>
<t>It is not feasible to enumerate all the possible options for the
mandatory capabilities listed above (e.g., all the potential delivery
protocols or metadata options) or anticipate all the future needs for
additional capabilities. It would be unreasonable to burden the CDNI
FCI specification with defining each supported capability. Instead, the CDNI
FCI specification should define a generic protocol for conveying any
capability information (e.g. with common encoding, error
handling, and security mechanism; further requirements for the
CDNI FCI Advertisement Interface are listed in <xref
target="RFC7337"/>).</t>
</section>
<section title="Acknowledgment">
<t>Jan Seedorf is partially supported by the GreenICN project (GreenICN: Architecture and Applications of Green Information Centric Networking), a research project supported jointly by the European Commission under its 7th Framework Program (contract no. 608518) and 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 interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the GreenICN project, the European Commission, or NICT.</t>
<t>Martin Stiemerling provided initial input to this document and
valuable comments to the ongoing discussions among the authors of this
document. Thanks to Francois Le Faucheur and Scott Wainner for providing valuable comments and suggestions to the text.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:09:35 |