One document matched: draft-ma-cdni-capabilities-08.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std" docName="draft-ma-cdni-capabilities-08" ipr="trust200902">
<front>
<title abbrev="CDNI FCI">CDNI Footprint & Capabilities Advertisement Interface</title>
<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>
<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>
<date />
<abstract>
<t>Content Distribution Network Interconnection (CDNI) is
predicated on the ability of downstream CDNs (dCDNs) to handle end-user
requests in a functionally equivalent manner to the upstream CDN (uCDN).
The uCDN must be able to assess the ability of the dCDN to handle
individual requests. The CDNI Footprint & Capabilities Advertisement
interface (FCI) is provided for the advertisement of capabilities and
the footprints to which they apply by the dCDN to the uCDN. This
document describes an approach to implementing the CDNI FCI.</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">
<t>The need for footprint and capabilities advertisement in
Content Distribution Network Interconnection (CDNI) is
described in the <xref target="RFC7337">CDNI
requirements document</xref>. Requirements FCI-1 and FCI-2 describe the
need to allow dCDNs to communicate capabilities to the uCDN. Requirement
FCI-3 describes how a uCDN may aggregate the footprint and capabilities
information for all cascaded dCDNs and use the aggregated information in
advertisements to CDNs further upstream.
This concept of aggregation can apply to both organizationally different
dCDNs (e.g., other CDN providers, or different business units within a
larger organization) or logical entities within the same CDN (e.g., using
multiple request routers for scalability reasons, to segregate
surrogates based on specific protocol support, or to segregate
surrogates based on software version or feature level, etc.).</t>
<t><xref target="appendix_a"/> contains more detailed descriptions of
different footprint and capabilities management scenarios, but it
is important to note that it is the ability of the dCDN to service each
request in a functionally equivalent manner as the uCDN that is
important, not the physical layout of resources through which it
services the request. The aggregation of resource knowledge by the dCDN
into a simple set of capabilities and their affective footprints, that is
then advertised to the uCDN, enables efficient decision making at each
delegation point in the CDN interconnection hierarchy.</t>
<t>It is assumed that an authoritative request router in each CDN will
be responsible for aggregating and advertising capabilities
information in a dCDN and/or receiving and aggregating capabilities
information in the uCDN. The CDNI Footprint & Capabilities
Advertisement interface (FCI) along with the CDNI Request Routing
Redirection interface (RI)
<xref target="I-D.ietf-cdni-redirection"/>
make up the CDNI Request Routing Interface.
As there is no other centralized CDNI controller, the authoritative
request router seems the most logical place for capabilities aggregation
to occur, as it is the request router that needs such information to make
delegation decisions. The protocol defined herein may be implemented as
part of an entity other than an authoritative request router, but for the
purposes of this discussion, the authoritative request router is assumed
to be the centralized capabilities aggregation point.</t>
<t>Though there is an obvious need for the ability to exchange and
update footprint and capability information in real-time, it is assumed
that capabilities do not change very often. It is also assumed that the
capabilities are not by themselves useful for making delegation decisions.
Capability information is assumed to be input into business logic. It is
the business logic which provides the algorithms for delegation decision
making. The definition of business logic occurs outside the scope of
CDNI and outside the timescale of footprint and capability
advertisement
<xref target="I-D.ietf-cdni-footprint-capabilities-semantics"/>.
It may be the case that the business logic anticipates
and reacts to changes in dCDN capabilities, however, it may also be the
case that business logic is tailored through offline processes as dCDN
capabilities change. The FCI is agnostic to the business processes
employed by any given uCDN. The footprints and capabilities that are
advertised over the FCI may be used by the uCDN at its discretion, to
implement delegation rules. Setting proper defaults in the business
logic should prevent any unwanted delegation from occurring when dCDN
capabilities change, however, that is beyond the scope of this
discussion.</t>
<section title="Terminology">
<t>This document uses the terminology defined in section 1.1 of the
<xref target="RFC7336">CDNI Framework</xref>
document.</t>
</section>
</section>
<section title="CDNI FCI Capability Advertisement">
<t>The FCI is implemented as an
<xref target="RFC7285">ALTO</xref> Service. The
ALTO protocol defines an HTTP-based transport through which ALTO
service information may be retrieved using either a GET or POST
method. The uCDN request router may at any time query the dCDN
ALTO FCI Service for the full set of dCDN capability
information. The uCDN may use a separate FCI Filter Service to retrieve a subset of the dCDN capability information.</t>
<t>[Ed.: Need to update this with ALTO asynchronous update support.]</t>
<t>[Ed.: Need to update this with ALTO incremental update support.]</t>
<section title="CDNI FCI Capability Initialization">
<t>In lieu of any out-of-band pre-configured capability information,
when the FCI is first brought up between a uCDN and a dCDN, the uCDN
SHOULD assume that the dCDN has no CDNI capabilities. If an out-of-band
capability baseline has been exchanged, the uCDN MAY use that
information to initialize its capabilities database. In either case,
the uCDN SHOULD verify the initial state of the dCDN (as a temporary
outage may affect availability in the dCDN).</t>
<t>The dCDN MUST support sending its entire set of capabilities to the
uCDN through the ALTO service interface</t>
</section>
</section>
<section title="CDNI FCI Capabilities Service">
<t>As described in Requirement FCI-2, there is a basic set of capabilities
that must be supported by the FCI for the uCDN to be able to determine if
the dCDN is functionally able to handle a given request.
<xref target="I-D.ietf-cdni-footprint-capabilities-semantics"/>
lists mandatory capabilities types:</t>
<t><list style="symbols">
<t>Delivery Protocol</t>
<t>Acquisition Protocol</t>
<t>Redirection Mode</t>
<t>CDNI Logging Capabilities</t>
<t>CDNI Metadata Capabilities</t>
</list></t>
<t>To be consistent with the base ALTO service definitions,
we use the JSON object definition notation as specified in the
<xref target="RFC7285">ALTO protocol</xref>.</t>
<section title="CDNI FCI Map">
<section title="Media Type" anchor="media-type">
<t>The media type of CDNI FCI Map is
"application/alto-cdni-fcimap+json"</t>
</section>
<section title="HTTP Method">
<t>A CDNI FCI Map resource is requested using the
HTTP GET method.</t>
</section>
<section title="Accept Input Parameters">
<t>None.</t>
</section>
<section title="Capabilities">
<t>None.</t>
</section>
<section title="Uses">
<t>None.</t>
</section>
<section title="Response" anchor="response">
<t>The data component of a CDNI FCI Map resource is named
"fcimap" which is a JSON object of type FCIMapData:</t>
<figure align="left">
<artwork align="left"><![CDATA[
object {
FCIMapData fcimap<0..*>;
} InfoResourceFCIMap : ResponseEntityBase;
object {
FCICapability capabilities<1..*>;
} FCIMapData;
object {
JSONString capability-type;
JSONValue capability-value
FCIFootprint footprints<0..*>;
} FCICapability;
object {
JSONString footprint-type;
JSONString footprint-value<1..*>;
} FCIFootprint;
]]></artwork>
</figure>
<t>The FCIMapData object contains a CDNI Payload Type
<xref target="RFC7736"/> "ptype" which
identifies the capability and a "value" object containing the
associated Capability Advertisement Object (e.g.,
delivery-protocols, acquisition-protocols, or
redirection-modes, as defined in
<xref target="I-D.ietf-cdni-footprint-capabilities-semantics"/>).
The FCIMapData object may also contain an optional list of
FCIFootprint objects "footprints". The FCIFootprint object specifies a
"footprint-type" (as defined by the CDNI Metadata Footprint
Types registry, e.g., ipv4cidr, ipv6cidr, asn, or
countrycode <xref target="I-D.ietf-cdni-metadata"/>)
which identifies the contents and encoding of the individual
footprint entries contained in the associated "footprint-value" array.</t>
<t>The "footprints" list MUST NOT contain multiple FCIFootprint
objects of the same type. Footprint restriction information MAY be
specified using multiple different footprint-types. If no footprint
restriction list is specified (or an empty list is
specified), it SHALL be understood that all footprint types
MUST be reset to "global" coverage.</t>
<t>Note: Further optimization of the footprint object to provide
quality information for a given footprint is certainly possible,
however, it is not necessary for the basic interconnection of
CDNs. The ability to transfer quality information in
capabilities advertisements may be desirable and is noted
here for completeness, however, the specifics of such
mechanisms are outside the scope of this document.</t>
<t>Multiple FCIMapData objects with the same capability type are
allowed within a given CDNI FCI Map response as long as the capability
option footprint-value do not overlap, i.e., a given capability option
value MUST NOT show up in multiple FCIMapData objects within a
single CDNI FCI Map response. If multiple FCIMapData objects
for a given capability type exist, those capability objects
MUST have different footprint restrictions. Capability objects
of a given capability type with identical footprint restrictions
MUST be combined into a single capability object.</t>
</section>
<section title="CDNI FCI Capabilities">
<section anchor="deliveryprotocol" title="Delivery Protocol">
<t>The delivery protocol refers to the protocol over which
an end user (EU) has requested content. If a dCDN does
not support the protocol requested by the client, then the
dCDN is not a viable candidate for delegation.</t>
<t>Though the delivery protocol is specified in the URI scheme (as
defined in <xref target="RFC3986"/>) of the
client request URL, protocol feature subsets or augmented
protocol feature sets MAY be defined and SHOULD correspond
with the protocols listed in the CDNI Metadata Protocol
Types registry, e.g., http1.1 or https1.1
<xref target="I-D.ietf-cdni-metadata"/>.</t>
<t>The
following example shows two lists of delivery protocols with different
footprints.</t>
<figure align="left">
<artwork align="left"><![CDATA[
GET /fcimap HTTP/1.1
Host: alto.example.com
Accept: application/alto-fcimap+json,application/alto-error+json
HTTP/1.1 200 OK
Content-Length: 627
Content-Type: application/alto-fcimap+json
{
"meta" : {
},
"fcimap": {
"capabilities": [
{ "capability-type": "FCI.DeliveryProtocol"
"capability-value": {
"delivery-protocols": [
"http1.1"
]
}
},
{ "capability-type": "FCI.DeliveryProtocol"
"capability-value": {
"delivery-protocols": [
"https1.1"
]
},
"footprints": [
{ "footprint-type": "ipv4cidr",
"footprint-value": [
"10.1.0.0/16",
"10.10.10.0/24"
]
}
]
}
]
}
}
]]></artwork>
</figure>
<t>In the above example, the HTTP/1.1 protocol is supported
globally, while the HTTP/1.1 over TLS protocol is only supported in
a restricted footprint (in this case, specified by
IPv4 prefix).</t>
<t>A given protocol MUST NOT appear in multiple FCIMapData
FCI.DeliveryProtocol object values.</t>
</section>
<section title="Acquisition Protocol">
<t>The acquisition protocol refers to the protocol over which
an end user (EU) has requested content. If a dCDN does
not support the protocol requested by the client, then the
dCDN is not a viable candidate for delegation.</t>
<t>Though the acquisition protocol is specified in the URI scheme (as
defined in <xref target="RFC3986"/>) of the
client request URL, protocol feature subsets or augmented
protocol feature sets MAY be defined and SHOULD correspond
with the protocols listed in the CDNI Metadata Protocol
Types registry, e.g., http1.1 or https1.1
<xref target="I-D.ietf-cdni-metadata"/>.</t>
<t>The
following example shows two lists of acquisition protocols with different
footprints.</t>
<figure align="left">
<artwork align="left"><![CDATA[
GET /fcimap HTTP/1.1
Host: alto.example.com
Accept: application/alto-fcimap+json,application/alto-error+json
HTTP/1.1 200 OK
Content-Length: 620
Content-Type: application/alto-fcimap+json
{
"meta" : {
},
"fcimap": {
"capabilities": [
{ "capability-type": "FCI.AcquisitionProtocol"
"capability-value": {
"acquisition-protocols": [
"http1.1"
]
}
},
{ "capability-type": "FCI.AcquisitionProtocol"
"capability-value": {
"acquisition-protocols": [
"https1.1"
]
},
"footprints": [
{ "footprint-type": "asn",
"footprint-value": [
"AS0",
"AS65535"
]
}
]
}
]
}
}
]]></artwork>
</figure>
<t>In the above example, the HTTP/1.1 protocol is supported
globally, while the HTTP/1.1 over TLS protocol is only supported in
a restricted footprint (in this case, specified by
Autonomous System number).</t>
<t>A given protocol MUST NOT appear in multiple FCIMapData
FCI.AcquisitionProtocol value objects.</t>
</section>
<section title="Redirection Mode">
<t>The redirection mode refers to the method(s) employed by request
routers to perform request redirection. The
<xref target="RFC7336">CDNI framework</xref>
document describes four possible request routing modes:</t>
<t><list style="symbols">
<t>DNS iterative (DNS-I)</t>
<t>DNS recursive (DNS-R)</t>
<t>HTTP iterative (HTTP-I)</t>
<t>HTTP recursive (HTTP-R)</t>
</list></t>
<t><xref target="I-D.ietf-cdni-footprint-capabilities-semantics"/>
defines the "CDNI
Capabilities Redirection Modes" registry and the initial
supported redirection mode values shown in parentheses
above.</t>
<t>If a dCDN supports only a specific mode or subset of
modes that does not overlap with the modes supported by
the uCDN, then the dCDN might not be a viable candidate for
delegation.</t>
<t>The following example shows two
lists of redirection modes with different footprints.</t>
<figure align="left">
<artwork align="left"><![CDATA[
GET /fcimap HTTP/1.1
Host: alto.example.com
Accept: application/alto-fcimap+json,application/alto-error+json
HTTP/1.1 200 OK
Content-Length: 767
Content-Type: application/alto-fcimap+json
{
"meta" : {
},
"fcimap": {
"capabilities": [
{ "capability-type": "FCI.RedirectionMode",
"capability-value": {
"redirection-modes": [
"DNS-I",
"HTTP-I"
]
}
},
{ "capability-type": "FCI.RedirectionMode",
"capability-value": {
"redirection-modes": [
"DNS-R",
"HTTP-R"
]
},
"footprints": [
{ "footprint-type": "countrycode",
"footprint-value": [
"SE"
]
},
{ "footprint-type": "ipv6cidr",
"footprint-value": [
"9876:5432::1/36"
]
}
]
}
]
}
}
]]></artwork>
</figure>
<t>In the above example, iterative redirection is supported
globally, while recursive redirection is only supported in a
restricted footprint (in this case, specified by both
Country Code and IPv6 prefix).</t>
<t>A given mode MUST NOT appear in multiple FCIMapData
FCI.RedirectionMode object values.</t>
</section>
<section title="Logging Capabilities">
<t><xref target="I-D.ietf-cdni-logging"/>
describes the "cdni_http_request_v1" logging record-types
and optional vs. mandatory-to-implement logging fields
for that record-type. It also allows new logging
record-types and logging fields to be defined
which would be optional for a dCDN to implement.</t>
<t>If a dCDN does not support certain logging
parameters which may affect billing agreements or legal
requirements of the uCDN, then the dCDN is not a viable
candidate for delegation.</t>
<section anchor="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>
<section anchor="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 title="Metadata Capabilities">
<t><xref target="I-D.ietf-cdni-metadata"/>
describes GenericMetadata types
which may be optional for a dCDN to implement, but which,
if present, are mandatory-to-enforce.
It also allows for new GenericMetadata to be defined
which would be optional for a dCDN to implement.</t>
<t>If a dCDN does not
support certain GenericMetadata types which are designated
mandatory-to-enforce and may affect the correctness or
security of the content being delivered, then the dCDN is
not a viable candidate for delegation.</t>
<section anchor="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>
<section anchor="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>
</section>
<section title="CDNI FCI Capabilities Filtering Service">
<section title="Filtered CDNI FCI Map">
<section title="Media Type">
<t>Since a Filtered CDNI FCI Map is still a CDNI FCI Map, it
uses the media type defined for CDNI FCI Map (see
<xref target="media-type"/>).</t>
</section>
<section title="HTTP Method">
<t>A Filtered CDNI FCI Map is requested using the
HTTP POST method.</t>
</section>
<section title="Accept Input Parameters">
<t>TBD.</t>
</section>
<section title="Capabilities">
<t>None.</t>
</section>
<section title="Uses">
<t>TBD.</t>
</section>
<section title="Response">
<t>The format is the same as unfiltered CDNI FCI Map (see
<xref target="response"/>).</t>
</section>
<section title="Example">
<t>TBD.</t>
</section>
</section>
</section>
<section title="Footprint via ALTO Network Map">
<section title="ALTO Network Maps">
<t>The ALTO Protocol offers an information service "ALTO map
service" that provides information to ALTO clients in the form
of <xref target="RFC7285">Network Map and Cost Map</xref>. As
an alternative to the explicit definition of a CDNI Footprint Type
(e.g., ipv4cidr, ipv6cidr, as, countrycode), a reference to an
ALTO network map can be used to define an FCI footprint. To
enable such referencing to ALTO network maps, a new CDNI
Footprint Type "altonetworkmap" is defined (see also <xref
target="iana.footprint"/>).</t>
<t>The first altonetworkmap entry must be a URI for accessing
the ALTO server that hosts the ALTO network map (as defined in <xref
target="RFC7285">the ALTO protocol specification</xref>). All
subsequent altonetworkmap entries must be of type PIDName (as
defined in <xref target="RFC7285"/>, where the PIDName
corresponds to a PID in the ALTO network map referenced by the
preceding URI. Parsing and processing of an
ALTO network map follows <xref
target="RFC7285">the ALTO protocol specification</xref>.</t>
</section>
<section anchor="examplenetworkmap" title="Example ALTO Network Map for CDNI FCI Footprint">
<t>An ALTO client can retrieve a network map of media type
'application/alto-networkmap+json' under a given URI
(e.g., 'http://alto.example.com/fcifootprint001') with a GET
request for a network map as specified in <xref
target="RFC7285">the ALTO protocol</xref>. The following
network map would convey to a uCDN that the given dCDN (which
would provide the map) has three footprints called
"south-france" and "germany", and provides the corresponding
IPv4 address ranges for these footprints.</t>
<figure>
<artwork align="left"><![CDATA[
GET /networkmap HTTP/1.1
Host: http://alto.example.com/fcifootprint001
Accept: application/alto-networkmap+json,application/alto-error+json
HTTP/1.1 200 OK
Content-Length: 319
Content-Type: application/alto-networkmap+json
{
"meta" : {
"vtag": [
{"resource-id": "my-eu-netmap",
"tag": "1266506139"
}
]
},
"network-map" : {
"south-france" : {
"ipv4" : [ "192.0.2.0/24", "198.51.100.0/25" ]
},
"germany" : {
"ipv4" : [ "192.0.3.0/24"]
}
}
}
]]></artwork>
</figure>
</section>
<section title="Example of ALTO Network Map Footprint in FCI Map">
<t>To reference an ALTO network map as an FCI footprint, set
the footprint-type to "altonetworkmap", and set the first entry
in the footprint-value to the URI of the ALTO server hosting
the network map, followed by a list of PID names contained in
the network map.</t>
<t>The following example shows two lists of delivery protocols
(see <xref target="deliveryprotocol"/>), with the second having
an ALTO network map footprint.</t>
<figure align="left">
<artwork align="left"><![CDATA[
GET /fcimap HTTP/1.1
Host: alto.example.com
Accept: application/alto-fcimap+json,application/alto-error+json
HTTP/1.1 200 OK
Content-Length: 618
Content-Type: application/alto-fcimap+json
{
"meta" : {
},
"fcimap": {
"capabilities": [
{ "capability-type": "FCI.DeliveryProtocol",
"capability-value": [
"http1.1"
]
},
{ "capability-type": "FCI.DeliveryProtocol",
"capability-value": [
"values": [
"https1.1"
],
"footprints": [
{ "footprint-type": "altonetworkmap",
"footprint-value": [
"http://alto.example.com/fcifootprint001",
"germany",
"south-france"
]
}
]
}
]
}
}
]]></artwork>
</figure>
<t>In the above example, the HTTP/1.1 protocol is supported
globally, while the HTTP/1.1 over TLS protocol is only supported in
a restricted footprint (in this case, specified by
an ALTO network map for Germany and Southern France).</t>
</section>
</section>
<section anchor="iana" title="IANA Considerations">
<section anchor="iana.altomediatype" title="ALTO Media Types">
<t>This document requests the registration of the following
media types:</t>
<texttable>
<ttcol align="left">Type</ttcol>
<ttcol align="left">Subtype</ttcol>
<c>application</c>
<c>alto-cdni-fcimap+json</c>
<c>application</c>
<c>alto-cdni-fcimapfilter+json</c>
</texttable>
<section anchor="iana.FCIMapMediaType" title="ALTO CDNI FCI Map Media Type">
<t>Type name: application</t>
<t>Subtype name: alto-cdni-fcimap+json</t>
<t>Required parameters: none</t>
<t>Optional parameters: none</t>
<t>Encoding considerations:</t>
<t><list style="empty">
<t>Encoding considerations are identical to
those specified for the "application/json" media type. See
<xref target="RFC7159"/>.</t>
</list></t>
<t>Security considerations:</t>
<t><list style="empty">
<t>Security considerations relating to the
generation and consumption of ALTO Protocol messages are discussed
in Section 15 of <xref target="RFC7285"/>. Additional
security considerations for the CDNI Footprint &
Capabilities Advertisement interface are discussed in
<xref target="sc"/>.</t>
</list></t>
<t>Interoperability considerations:</t>
<t><list style="empty">
<t><xref target="RFC7285"/> and RFCthis specify the format of
conforming messages and the interpretation thereof. [RFC Editor: Please
replace RFCthis with the published RFC number for this document.]</t>
</list></t>
<t>Published specification: RFCthis [RFC Editor: Please
replace RFCthis with the published RFC number for this document.]</t>
<t>Applications that use this media type:</t>
<t><list style="empty">
<t>ALTO servers and ALTO clients
either stand alone or are embedded within other applications.</t>
</list></t>
<t>Fragment identifier considerations: N/A</t>
<t>Additional information: N/A</t>
<t><list style="empty">
<t>Deprecated alias names for this type: N/A</t>
<t>Magic number(s): N/A</t>
<t>File extension(s): N/A</t>
<t>Macintosh file type code(s): N/A</t>
</list></t>
<t>Person & email address to contact for further
information:</t>
<t><list style="empty">
<t>Kevin Ma <kevin.j.ma@ericsson.com></t>
</list></t>
<t>Intended usage: LIMITED USE</t>
<t>Restrictions on usage:</t>
<t><list style="empty">
<t>This media type is intended only for use in CDNI
Footprint & Capabilities Advertisement interface protocol
message exchanges.</t>
</list></t>
<t>Author: IETF CDNI working group</t>
<t>Change controller: IETF CDNI working group</t>
<t>Provisional registration: no</t>
</section>
<section anchor="iana.FCIMapFilterMediaType" title="ALTO CDNI FCI Map Filter Media Type">
<t>Type name: application</t>
<t>Subtype name: alto-cdni-fcimapfilter+json</t>
<t>Required parameters: none</t>
<t>Optional parameters: none</t>
<t>Encoding considerations:</t>
<t><list style="empty">
<t>Encoding considerations are identical to
those specified for the "application/json" media type. See
<xref target="RFC7159"/>.</t>
</list></t>
<t>Security considerations:</t>
<t><list style="empty">
<t>Security considerations relating to the
generation and consumption of ALTO Protocol messages are discussed
in Section 15 of <xref target="RFC7285"/>. Additional
security considerations for the CDNI Footprint &
Capabilities Advertisement interface are discussed in
<xref target="sc"/>.</t>
</list></t>
<t>Interoperability considerations:</t>
<t><list style="empty">
<t><xref target="RFC7285"/> and RFCthis specify the format of
conforming messages and the interpretation thereof. [RFC Editor: Please
replace RFCthis with the published RFC number for this document.]</t>
</list></t>
<t>Published specification: RFCthis [RFC Editor: Please
replace RFCthis with the published RFC number for this document.]</t>
<t>Applications that use this media type:</t>
<t><list style="empty">
<t>ALTO servers and ALTO clients
either stand alone or are embedded within other applications.</t>
</list></t>
<t>Fragment identifier considerations: N/A</t>
<t>Additional information: N/A</t>
<t><list style="empty">
<t>Deprecated alias names for this type: N/A</t>
<t>Magic number(s): N/A</t>
<t>File extension(s): N/A</t>
<t>Macintosh file type code(s): N/A</t>
</list></t>
<t>Person & email address to contact for further
information:</t>
<t><list style="empty">
<t>Kevin Ma <kevin.j.ma@ericsson.com></t>
</list></t>
<t>Intended usage: LIMITED USE</t>
<t>Restrictions on usage:</t>
<t><list style="empty">
<t>This media type is intended only for use in CDNI
Footprint & Capabilities Advertisement interface protocol
message exchanges.</t>
</list></t>
<t>Author: IETF CDNI working group</t>
<t>Change controller: IETF CDNI working group</t>
<t>Provisional registration: no</t>
</section>
</section>
<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.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.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="loggingObject"/> and
<xref target="loggingSerialization"/></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="metadataObject"/> and
<xref target="metadataSerialization"/></t>
</section>
</section>
<section anchor="iana.footprint" title="CDNI Footprint Types">
<t>This document requests the following addition to the "CDNI
Metadata Footprint Types" registry:</t>
<texttable>
<ttcol align="left">Footprint Type</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">Specification</ttcol>
<c>altonetworkmap</c>
<c>URI of an ALTO Server hosting an ALTO network map, followed by a list of PID-names</c>
<c>RFCthis</c>
</texttable>
<t>[RFC Editor: Please replace RFCthis with the published RFC number for this document.]</t>
</section>
</section>
<section anchor="sc" title="Security Considerations">
<t>There are a number of security concerns associated with the FCI. The
FCI essentially provides configuration information which the uCDN uses to
make request routing decisions. Injection of fake capability
advertisement messages or the interception and discard of real capability
advertisement messages may be used for denial of service (e.g., by
falsely advertising or deleting capabilities or preventing capability
advertisements from reaching the uCDN). FCI messages may also
be monitored to detect when CDN performance degrades or outages
occur. Such information may be considered private by the dCDN.</t>
<t>dCDN capability advertisements
MUST be authenticated by the uCDN to prevent unauthorized capability
injection. uCDN FCI servers MUST be authenticated by the dCDN to prevent
unauthorized interception of ALTO messages. Encryption MUST be
used to ensure confidentiality of the dCDN's private messages.</t>
<section title="Securing the CDNI Footprint & Capabilities Advertisement interface">
<t>An implementation of the CDNI Footprint & Capabilities Advertisement interface MUST support TLS
transport as per <xref target="RFC2818"/> and <xref
target="RFC7230"/>. The use of TLS for transport of the CDNI metadata
interface messages allows:</t>
<t><list style="symbols">
<t>The dCDN and uCDN to authenticate each other.</t>
</list>and, once they have mutually authenticated each other, it
allows:<list style="symbols">
<t>The dCDN and uCDN to authorize each other (to ensure they are
transmitting/receiving CDNI FCI messages from
an authorized CDN);</t>
<t>CDNI FCI messages to be
transmitted with confidentiality; and</t>
<t>The integrity of the CDNI FCI messages
to be protected during the exchange.</t>
</list></t>
<t>In an environment where any such protection is required, TLS MUST
be used (including authentication of the remote end) by the
server-side (uCDN) and the client-side (dCDN) of the CDNI Footprint & Capabilities Advertisement
interface unless alternate methods are used for ensuring the
confidentiality of the information in the CDNI FCI messages
(such as setting up an IPsec tunnel between the
two CDNs or using a physically secured internal network between two
CDNs that are owned by the same corporate entity).</t>
<t>When TLS is used, the general TLS usage guidance in <xref
target="RFC7525"/> MUST be followed.</t>
</section>
</section>
<section title="Acknowledgements">
<t>The authors would like to thank Jon Peterson, Ray van
Brandenburg, Gilles Bertrand, and Scott Wainner for their timely
reviews and invaluable comments.</t>
<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>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.7230"?>
<?rfc include="reference.RFC.7285"?>
<?rfc include="reference.RFC.7525"?>
<?rfc include="reference.I-D.ietf-cdni-metadata"?>
<?rfc include="reference.I-D.ietf-cdni-logging"?>
<?rfc include="reference.I-D.ietf-cdni-footprint-capabilities-semantics"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.2818"?>
<?rfc include="reference.RFC.3986" ?>
<?rfc include="reference.RFC.7159" ?>
<?rfc include="reference.RFC.7337" ?>
<?rfc include="reference.RFC.7336"?>
<?rfc include="reference.RFC.7736"?>
<?rfc include="reference.I-D.ietf-cdni-redirection"?>
</references>
<section title="Capability Aggregation" anchor="appendix_a">
<t>The following sections show examples of three aggregation scenarios.
In each case, CDN-U is the ultimate uCDN and CDN-P is the penultimate
CDN which must perform capabilities aggregation.</t>
<section title="Downstream CDN Aggregation">
<t>Figure A1 shows five organizationally different CDNs: CDN-U, CDN-P,
and CDNS A, B, and C, the dCDNs of CDN-P which are being aggregated.
Given the setup shown in Figure A1, we can construct a number of use
cases, based on the coverage areas of each dCDN (i.e., CDNs P, A, B,
and C). Note: In all cases, the reachability of the uCDN (i.e., CDN-U)
is a don't care as it is assumed that the uCDN knows its own coverage
area and is likely to favor itself in most situations, and if it has
decided that it needs to delegate to a dCDN, then the only relevant
question is if the dCDN can handle the request.</t>
<figure align="center"
title="Figure A1: CDNI dCDN Request Router Aggregation">
<artwork align="center"><![CDATA[
,---,---,---.
,-' `-.
( rr0.u.example.com )
`-. CDN-U ,-'
`---'-+-'- --'
|
,---,-+-,---.
,-' `-.
( rr0.p.example.com )
`-. CDN-P ,-'
`---'-+-'---'
|
+---------------------+---------------------+
/ | \
,---,-+-,---. ,---,-+-,---. ,---,-+-,---.
,-' `-. ,-' `-. ,-' `-.
( rr0.a.example.com ) ( rr0.b.example.com ) ( rr0.c.example.com )
`-. CDN-A ,-' `-. CDN-B ,-' `-. CDN-C ,-'
`---'---'---' `---'---'---' `---'---'---'
]]></artwork>
</figure>
<t><list style="symbols">
<t>None of the four dCDNs (CDNs P, A, B, and C) have global
reachability. In this case, each CDN is likely to advertise
footprint information with its capabilities, specifying its
reachability. When CDN-P advertises capabilities to CDN-U, it may
advertise the aggregate footprint of itself and CDNs A, B, and C.
Note: CDN-P MAY exclude any dCDN, and consequently its footprint, per
its own internal aggregation decision criteria.</t>
<t>All four dCDNs (CDNs P, A, B, and C) have global reachability.
In this case, none of the CDNs is likely to advertise any footprint
information as none have any footprint restrictions. When CDN-P
advertises capabilities to CDN-U, the aggregate of all global
reachability is global reachability.</t>
<t>Some of the four dCDNs (CDNs P, A, B, and C) have global
reachability and some do not. In this case, even though some dCDNs
do not have global reachability, the aggregate of some dCDNs having
global reachability and some not should still be global reachability
(for the given capability). When CDN-P advertises capabilities to
CDN-U, CDN-P may advertise capabilities for which at least one dCDN
has global reach as being supported with global reachability. It is up
to the CDN-P request router to properly select a dCDN to process
individual client requests and not choose a dCDN whose restricted
footprint makes it unsuitable for delivering the requested content.</t>
</list></t>
</section>
<section title="Internal Request Router Aggregation">
<t>Figure A2 shows CDN-U and CDN-P where CDN-P internally has four
request routers: the authoritative request router rr0, and three other
request routers rr1, rr2, and rr3. The use of multiple request routers
may be used to distribute request routing load across resources, possibly
in different geographic regions covered by CDN-P. Similar to Figure A1,
the setup shown in Figure A2 requires the authoritative request router
rr0 in CDN-P to aggregate capabilities information from downstream
request routers rr1, rr2, and rr3. The primary difference between the
scenario is that the request routers in Figure A2 are logically within
the same CDN-P organization. The same reachability scenarios apply to
Figure A2 as with Figure A1.</t>
<figure align="center"
title="Figure A2: Local CDN Request Router Aggregation">
<artwork align="center"><![CDATA[
,---,---,---.
,-' `-.
( rr0.u.example.com )
`-. CDN-U ,-'
`---'-+-'---'
|
,---,---,---,--,-+-,--,---,---,---.
( )
,-' +-------------------+ `-.
( | rr0.p.example.com | )
,-' +---------+---------+ `-.
( | )
,-' +----------+----------+ `-.
( / | \ )
) +---------+---------+ | +---------+---------+ (
( | rr1.p.example.com | | | rr3.p.example.com | )
`. +-------------------+ | +-------------------+ ,'
( | )
`-. +---------+---------+ ,-'
( | rr2.p.example.com | )
`-. +-------------------+ ,-'
( CDN-P )
`---'---'---'---'---'---'---'---'---'
]]></artwork>
</figure>
<t><list style="symbols">
<t>None of the four CDN-P request routers have global reachability.
In this case, each request router is likely to advertise footprint
information with its capabilities, specifying its reachability. When
rr0 advertises capabilities to CDN-U, it may advertise the aggregate
footprint of itself and rr1, rr2, and rr3.</t>
<t>All four CDN-P request routers have global reachability. In this
case, none of the request routers is likely to advertise any footprint
information as none has any footprint restrictions. When rr0
advertises capabilities to CDN-U, the aggregate of all global
reachability is global reachability.</t>
<t>Some of the four CDN-P request routers have global reachability and
some do not. In this case, even though some request routers do not
have global reachability, the aggregate of some request routers having
global reachability and some not should still be global reachability
(for the given capability). When rr0 advertises capabilities to CDN-U,
CDN-P may advertise capabilities for which at least one request router
has global reach as being supported with global reachability. It is up
to the authoritative request router rr0 to properly select from the
other request routers for any given request, and not choose a request
router whose restricted footprint makes it unsuitable for delivering
the requested content.</t>
</list></t>
</section>
<section title="Internal Capability Aggregation">
<t>Figure A3 shows CDN-U and CDN-P where the delivery network of CDN-P
is segregated by delivery protocol (e.g., RTSP, HTTP, and RTMP).
Figure A3 differs from Figures A1 and A2 in that request router rr0
of CDN-P is not aggregating the capabilities advertisements of multiple
other downstream request routers, but rather it is managing the disparate
capabilities across resources within its own local CDN. Though not every
delivery node has the same protocol capabilities, the aggregate delivery
protocol capabilities advertised by CDN-A may include all delivery
protocols. Note, Figure A3 should not be construed to imply anything
about the coverage areas for each delivery protocol. They may all
support the same delivery footprint, or they may have different delivery
footprints. It is the responsibility of the request router rr0 to
properly assign protocol-appropriate delivery nodes to individual content
requests. If certain protocols have limited reachability, CDN-P may
advertise footprint restrictions for each protocol.</t>
<t>It should be noted that though the delivery protocol capability was
selected for this example, the concept of internal capability aggregation
applies to all capabilities as discussed below.</t>
<figure align="center"
title="Figure A3: Local CDN Capability Segregation">
<artwork align="center"><![CDATA[
,---,---,---.
,-' `-.
( rr0.u.example.com )
`-. CDN-U ,-'
`---'-+-'---'
|
,---,---,---,--,-+-,--,---,---,---.
( )
,-' +-------------------+ `-.
( | rr0.p.example.com | )
,-' +---------+---------+ `-.
( . )
,-' ....................... `-.
( . . . )
) +-------------------+ . +-------------------+ (
( |rtsp.p.example.com | . |rtmp.p.example.com | )
`. +-------------------+ . +-------------------+ ,'
( . )
`-. +-------------------+ ,-'
( |http.p.example.com | )
`-. +-------------------+ ,-'
( CDN-A )
`---'---'---'---'---'---'---'---'---'
]]></artwork>
</figure>
<t>Another situation in which physical footprint may not matter in an
aggregated view has to do with feature support (e.g., new CDNI metadata
features or new redirection modes). Situations often arise when phased
roll-out of software upgrades, or staging network segregation result in
only certain portions of a CDN's resources supporting the new feature
set. The dCDN has a few options in this case:</t>
<t><list style="symbols">
<t>Enforce atomic update: The dCDN does not advertise support for the
new capability until all resources have been upgraded to support the
new capability.</t>
<t>Transparent segregation: The dCDN advertises support for the new
capability, and when requests are received that require the new
capability, the dCDN request router properly selects a resource
which supports that capability.</t>
<t>Advertised segregation: The dCDN advertises support for the new
capability with a footprint restriction allowing the uCDN to make
delegation decisions based on the dCDN's limit support.</t>
</list></t>
<t>The level of aggregation employed by the dCDN is likely to vary as
business relationships dictate, however, the FCI should
support all possible modes of operation.</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:25:13 |