rfc9808xml2.original.xml   rfc9808.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?> <!DOCTYPE rfc [
<?rfc tocompact="yes"?> <!ENTITY nbsp "&#160;">
<?rfc tocdepth="4"?> <!ENTITY zwsp "&#8203;">
<?rfc tocindent="yes"?> <!ENTITY nbhy "&#8209;">
<?rfc symrefs="yes"?> <!ENTITY wj "&#8288;">
<?rfc sortrefs="yes"?> ]>
<?rfc comments="yes"?>
<?rfc inline="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
<?rfc compact="yes"?> tf-cdni-capacity-insights-extensions-12" number="9808" consensus="true" ipr="tru
<rfc category="std" docName="draft-ietf-cdni-capacity-insights-extensions-12" ip st200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude
r="trust200902"> ="true" tocDepth="4" symRefs="true" sortRefs="true" version="3">
<front>
<title abbrev="CDNI Capacity Capability Advertisement Extensions"> <front>
CDNI Capacity Capability Advertisement Extensions <title abbrev="CDNI Capacity Capability Advertisement Extensions">Content De
</title> livery Network Interconnection (CDNI)
<author fullname="Andrew Ryan" initials="A." surname="Ryan"> Capacity Capability Advertisement Extensions</title>
<organization> <seriesInfo name="RFC" value="9808"/>
Disney Streaming <author fullname="Andrew Ryan" initials="A." surname="Ryan">
</organization> <organization>Disney Streaming</organization>
<address> <address>
<postal> <postal>
<street> <street>1211 Avenue of the Americas</street>
1211 Avenue of the Americas <city>New York</city>
</street> <region>NY</region>
<city> <code>10036</code>
New York <country>United States of America</country>
</city> </postal>
<region> <email>andrew@andrewnryan.com</email>
NY </address>
</region> </author>
<code> <author fullname="Ben Rosenblum" initials="B." surname="Rosenblum">
10036 <organization>Vecima</organization>
</code> <address>
<country> <postal>
US <street>4375 River Green Pkwy #100</street>
</country> <city>Duluth</city>
</postal> <region>GA</region>
<email> <code>30096</code>
andrew@andrewnryan.com <country>United States of America</country>
</email> </postal>
</address> <email>ben@rosenblum.dev</email>
</author> </address>
<author fullname="Ben Rosenblum" initials="B." surname="Rosenblum"> </author>
<organization> <author fullname="Nir B. Sopher" initials="N." surname="Sopher">
Vecima <organization>Qwilt</organization>
</organization> <address>
<address> <postal>
<postal> <street>6, Ha'harash</street>
<street> <city>Hod HaSharon</city>
4375 River Green Pkwy #100 <code>4524079</code>
</street> <country>Israel</country>
<city> </postal>
Duluth <email>nir@apache.org</email>
</city> </address>
<region> </author>
GA <date month="July" year="2025"/>
</region>
<code> <area>WIT</area>
30096 <workgroup>cdni</workgroup>
</code>
<country> <keyword>cdni</keyword>
US <keyword>Capacity</keyword>
</country> <keyword>telemetry</keyword>
</postal> <keyword>observability</keyword>
<email>
ben@rosenblum.dev <abstract>
</email> <t>This specification defines a set of additional
</address> Capability Objects that provide information about current downstream
</author> CDN (dCDN) utilization and specified usage limits to the delegating
<author fullname="Nir B. Sopher" initials="N." surname="Sopher"> upstream CDN (uCDN) in order to inform traffic delegation decisions.
<organization> </t>
Qwilt <t>This document supplements the CDNI Capability Objects, defined in
</organization> RFC 8008 as part of the Footprint &amp; Capabilities Advertisement
<address> Interface (FCI), with two additional Capability Objects:
<postal> FCI.CapacityLimits and FCI.Telemetry.
<street> </t>
6, Ha'harash </abstract>
</street> </front>
<city> <middle>
Hod HaSharon <section numbered="true" toc="default">
</city> <name>Introduction</name>
<region> <t>
</region>
<code>
4524079
</code>
<country>
Israel
</country>
</postal>
<email>
nir@apache.org
</email>
</address>
</author>
<date />
<workgroup>Content Delivery Networks Interconnection</workgroup>
<abstract>
<t>
The Content Delivery Networks Interconnection (CDNI) Capacity
Capability Advertisement Extensions define a set of additional
Capability Objects that provide information about current
downstream CDN (dCDN) utilization and specified usage limits to
the delegating upstream CDN (uCDN) in order to inform traffic
delegation decisions.
</t>
<t>
This document supplements the CDNI Capability Objects, defined i
n
RFC 8008 as part of the Footprints &amp; Capabilities
Advertisement Interface (FCI), with two additional Capability
Objects: FCI.CapacityLimits and FCI.Telemetry.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
While delegating traffic from an upstream CDN (uCDN) to a While delegating traffic from an upstream CDN (uCDN) to a
downstream CDN (dCDN), it is important to ensure that an downstream CDN (dCDN), it is important to ensure that an
appropriate amount of traffic is delegated. To achieve that, appropriate amount of traffic is delegated. To achieve that,
this specification defines a feedback mechanism to inform the this specification defines a feedback mechanism to inform the
delegator how much traffic may be delegated. The traffic delegator how much traffic may be delegated. The traffic
level information provided by that interface will be consumed level information provided by that interface will be consumed
by services, such as a request router, to inform that by services, such as a request router, to inform that
service's traffic delegation decisions. The provided information is advisory and does not represent a service's traffic delegation decisions. The provided information is advisory and does not represent a
guarantee, commitment, or reservation of capacity. guarantee, commitment, or reservation of capacity.
</t> </t>
<t> <t>
This document defines and registers CDNI Payload Types (as defin This document defines and registers CDNI Payload Types (as defin
ed ed in <xref section="7.1" target="RFC8006" format="default"/>). These Payload Ty
at section 7.1 of <xref target="RFC8006" />). These Payload type pes
s are used for Capability Objects, which are added to those define
are used for Capability Objects added to those defined at sectio d in <xref section="4" target="RFC8008" format="default"/>.
n 4 </t>
of <xref target="RFC8008" />. <section anchor="terminology" numbered="true" toc="default">
</t> <name>Terminology</name>
<section anchor="terminology" title="Terminology"> <t>The following term is used throughout this document:</t>
<t> <dl spacing="normal" newline="false">
The following terms are used throughout this document: <dt>CDN:</dt><dd>Content Delivery Network</dd>
<list style="symbols"> </dl>
<t> <t>Additionally, this document reuses the terminology defined in <xref
CDN - Content Delivery Network target="RFC6707" format="default"/>. Specifically, the
</t> following CDNI acronyms are used:</t>
</list> <dl spacing="normal" newline="false">
</t> <dt>uCDN:</dt><dd>upstream CDN</dd>
<t> <dt>dCDN:</dt><dd>downstream CDN</dd>
Additionally, this document reuses the terminology defined i </dl>
n
<xref target="RFC6707" />. </section>
Specifically, we use the following CDNI acronyms: <section numbered="true" toc="default">
<list style="symbols"> <name>Requirements Language</name>
<t> <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
uCDN, dCDN - Upstream CDN and Downstream CDN, respec "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
tively NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
</t> "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
</list> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
</t> are to be interpreted as described in BCP&nbsp;14 <xref
</section> target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
<section title="Requirements Language"> appear in all capitals, as shown here.
<t> </t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHAL </section>
L NOT", "SHOULD", <section numbered="true" toc="default">
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and " <name>Objectives</name>
OPTIONAL" in this <t>
document are to be interpreted as described in BCP 14
<xref target="RFC2119" />
<xref target="RFC8174" />
when, and only when, they appear in all capitals, as shown h
ere.
</t>
</section>
<section title="Objectives">
<t>
To enable information exchange between a uCDN and a dCDN regard ing acceptable levels of To enable information exchange between a uCDN and a dCDN regard ing acceptable levels of
traffic delegation, the following process has been defined: traffic delegation, the following process has been defined:
</t> </t>
<t indent="3">
<t> In normal operation, a uCDN will communicate with a dCDN, via a
In normal operation a uCDN will communicate with a dCDN, via an n interface, to collect and
interface, to collect and
understand any limits that a dCDN has set forth for traffic del egation from a uCDN. These limits understand any limits that a dCDN has set forth for traffic del egation from a uCDN. These limits
will come in the form of metrics such as bits per second, reque sts per second, etc. These limits will come in the form of metrics such as bits per second, reque sts per second, etc. These limits
can be thought of as Not to Exceed (NTE) limits. can be thought of as Not to Exceed (NTE) limits.
</t> </t>
<t indent="3">
<t> The dCDN should provide access to a Telemetry Source of near re
The dCDN should provide access to a telemetry source of near re al-time metrics that the uCDN can
al-time metrics that the uCDN can
use to track current usage. The uCDN should compare its current usage to the limits the dCDN has use to track current usage. The uCDN should compare its current usage to the limits the dCDN has
put forth and adjust traffic delegation decisions accordingly t o keep current usage under the specified put forth and adjust traffic delegation decisions accordingly t o keep current usage under the specified
limits. limits.
</t> </t>
<t indent="3">
<t>
In summary, the dCDN will inform the uCDN of the amount of In summary, the dCDN will inform the uCDN of the amount of
traffic that may be delegated. Additionally, it will provide a traffic that may be delegated. Additionally, it will provide a
telemetry source aligned with this limit, allowing the uCDN to Telemetry Source aligned with this limit, allowing the uCDN to
monitor its current usage against the advertised value. Having monitor its current usage against the advertised value. Having
a limit and a corresponding telemetry source creates an a limit and a corresponding Telemetry Source creates an
unambiguous definition understood by both parties. unambiguous definition understood by both parties.
</t> </t>
<t>
<t>
Limits that are communicated from the dCDN to the uCDN should Limits that are communicated from the dCDN to the uCDN should
be considered valid based on the TTL (Time To Live) provided by be considered valid based on the Time to Live (TTL) provided by
a mechanism of the underlying transport, e.g., an HTTP a mechanism of the underlying transport, e.g., an HTTP
Cache-Control header. The intention is that the limits would Cache-Control header. The intention is that the limits would
have a long-lived TTL and would represent a reasonable peak have a long-lived TTL and would represent a reasonable peak
utilization limit that the uCDN should target. If the utilization limit that the uCDN should target. If the
underlying transport does not provide a mechanism for the dCDN underlying transport does not provide a mechanism for the dCDN
to communicate the TTL of the limits, the TTL should be to communicate the TTL of the limits, the TTL should be
communicated through an out-of-band mechanism agrred between communicated through an out-of-band mechanism agreed upon betwe en
the dCDN and uCDN. the dCDN and uCDN.
</t> </t>
</section> </section>
</section> </section>
<section anchor="cdni-additional-capability-objects" title="CDNI Additio <section anchor="cdni-additional-capability-objects" numbered="true" toc="de
nal Capability Objects"> fault">
<t> <name>CDNI Additional Capability Objects</name>
Section 5 of <xref target="RFC8008" /> describes the FCI Capabil <t>
ity Advertisement Object, which <xref section="5" target="RFC8008" format="default"/> describes
contains a CDNI Capability Object as well as the capability obje the FCI Capability Advertisement Object, which
ct type (a CDNI Payload Type). contains a CDNI Capability Object as well as the capability-type
(a CDNI Payload Type).
The section also defines the Capability Objects per such type. B elow, we define two additional Capability Objects. The section also defines the Capability Objects per such type. B elow, we define two additional Capability Objects.
</t> </t>
<t> <aside><t>
Note: In the following sections, the term "mandatory-to-specify" Note: In the following sections, the term "mandatory-to-specify"
is used to convey which properties MUST be included when is used to convey which properties <bcp14>MUST</bcp14> be includ ed when
serializing a given capability object. When serializing a given capability object. When
mandatory-to-specify is defined as a "Yes" for an individual mandatory-to-specify is defined as a "Yes" for an individual
property, it means that if the object containing that property property, it means that if the object containing that property
is included in an FCI message, then the mandatory-to-specify is included in an FCI message, then the mandatory-to-specify
property MUST be included. property <bcp14>MUST</bcp14> be included.
</t> </t></aside>
<section anchor="telemetry-capability-object" title="Telemetry Capab <section anchor="telemetry-capability-object" numbered="true" toc="default
ility Object"> ">
<t> <name>Telemetry Capability Object</name>
<t>
The Telemetry Capability Object advertises a list of The Telemetry Capability Object advertises a list of
telemetry sources made available to the uCDN by the dCDN. In Telemetry Sources made available to the uCDN by the dCDN. In
this document, telemetry data is being defined as near this document, telemetry data is being defined as near
real-time aggregated metrics of dCDN utilization, such as real-time aggregated metrics of dCDN utilization, such as
bits per second egress, and is specific to the uCDN and dCDN bits per second egress, and is specific to the uCDN and dCDN
traffic delegation relationship. traffic delegation relationship.
</t> </t>
<t> <t>
Telemetry data is uniquely defined by a source ID, a metric Telemetry data is uniquely defined by a source ID, a metric
name, and the footprints that are associated with an name, and the footprints that are associated with an
FCI.Capability advertisement. When defining a FCI Capabilities advertisement. When defining a
CapacityLimit, the meaning of a limit might be ambiguous if CapacityLimit, the meaning of a limit might be ambiguous if
the uCDN and dCDN are observing telemetry via different data the uCDN and dCDN are observing telemetry via different data
sources. A dCDN-provided telemetry source that both parties sources. A dCDN-provided Telemetry Source that both parties
reference serves as a non-ambiguous metric for use when reference serves as a non-ambiguous metric for use when
comparing current usage to a limit. comparing current usage to a limit.
</t> </t>
<t> <t>
Telemetry data is important for making informed traffic Telemetry data is important for making informed traffic
delegation decisions. Additionally, it is essential in delegation decisions. Additionally, it is essential in
providing visibility of traffic that has been delegated. In providing visibility of traffic that has been delegated. In
situations where there are multiple CDN delegations, a uCDN situations where there are multiple CDN delegations, a uCDN
will need to aggregate the usage information from any dCDNs will need to aggregate the usage information from any dCDNs
to which it delegated when asked to provide usage to which it delegated when asked to provide usage
information, otherwise the traffic may seem unaccounted for. information, otherwise the traffic may seem unaccounted for.
</t> </t>
<t> <t>
Example: A Content Provider Example: A Content Provider
delegates traffic directly to a uCDN, and that uCDN delegates traffic directly to a uCDN, and that uCDN
delegates that traffic to a dCDN. When the Content Provider delegates that traffic to a dCDN. When the Content Provider
polls the uCDN telemetry interface, any of the traffic the polls the uCDN telemetry interface, any of the traffic the
uCDN delegated to the dCDN would uCDN delegated to the dCDN would
become invisible to the Content Provider unless the uCDN become invisible to the Content Provider, unless the uCDN
aggregates the dCDN telemetry with its own metrics. aggregates the dCDN telemetry with its own metrics.
</t> </t>
<t><list style="empty">
<t>Property: sources<list style="empty">
<t>Description: Telemetry sources made available to the
uCDN.</t>
<t>Type: A JSON array of Telemetry Source objects (see <
xref target="telemetry-source-object"/>).</t>
<t>Mandatory-to-Specify: Yes.</t>
</list></t>
</list></t>
<section anchor="telemetry-source-object" title="Telemetry Sourc <dl spacing="normal" newline="false">
e Object"> <dt>Property:</dt><dd><t>sources</t>
<t> <dl spacing="normal" newline="false">
The Telemetry Source Object is built of an associated ty <dt>Description:</dt><dd>Telemetry Sources made available to the uCD
pe, a list of exposed metrics, and type-specific configuration data. N.</dd>
</t> <dt>Type:</dt><dd>A JSON array of Telemetry Source objects (see
<xref target="telemetry-source-object" format="default"/>).</dd>
<dt>Mandatory-to-Specify:</dt><dd>Yes</dd>
</dl>
</dd>
</dl>
<t><list style="empty"> <section anchor="telemetry-source-object" numbered="true" toc="default">
<t>Property: id<list style="empty"> <name>Telemetry Source Object</name>
<t>Description: An identifier of a telemetry source. <t>The Telemetry Source Object is made of an associated type, a
The ID string assigned to this Telemetry Source MUST list of exposed metrics, and type-specific configuration data.
be unique across all Telemetry Source objects in the </t>
advertisement containining this Telemetry Source
Object. The ID string MUST remain consistent for
the same source reference across advertisements.</t>
<t>Type: String.</t>
<t>Mandatory-to-Specify: Yes.</t>
</list></t>
<t>Property: type<list style="empty"> <dl spacing="normal" newline="false">
<t>Description: A valid telemetry source type. See < <dt>Property:</dt><dd><t>id</t>
xref target="telemetry-source-type"/>.</t> <dl spacing="normal" newline="false">
<t>Type: String.</t> <dt>Description:</dt><dd>An identifier of a telemetry source. The
<t>Mandatory-to-Specify: Yes.</t> ID string assigned to this Telemetry Source <bcp14>MUST</bcp14> be
</list></t> unique across all Telemetry Source objects in the advertisement
containing this Telemetry Source Object. The ID string
<bcp14>MUST</bcp14> remain consistent for the same source
reference across advertisements.</dd>
<dt>Type:</dt><dd>String</dd>
<dt>Mandatory-to-Specify:</dt><dd>Yes</dd>
</dl>
</dd>
<dt>Property:</dt><dd><t>type</t>
<dl spacing="normal" newline="false">
<dt>Description:</dt><dd>A valid Telemetry Source Type (see <xref
target="telemetry-source-type" format="default"/>).</dd>
<dt>Type:</dt><dd>String</dd>
<dt>Mandatory-to-Specify:</dt><dd>Yes</dd>
</dl>
</dd>
<dt>Property:</dt><dd><t>metrics</t>
<dl spacing="normal" newline="false">
<dt>Description:</dt><dd>The metrics exposed by this source.</dd>
<dt>Type:</dt><dd>A JSON array of Telemetry Source Metric Objects
(see <xref target="telemetry-source-metric-object"
format="default"/>).</dd>
<dt>Mandatory-to-Specify:</dt><dd>Yes</dd>
</dl>
</dd>
<dt>Property:</dt><dd><t>configuration</t>
<dl spacing="normal" newline="false">
<dt>Description:</dt><dd>A source-specific representation of the
Telemetry Source configuration. For the generic source type, this
configuration format is defined as out-of-band. For other types, the
configuration format will be specified in a yet-to-be-defined
telemetry interface specification. The goal of this element is to
allow for forward compatibility with a formal telemetry
interface.</dd>
<dt>Type:</dt><dd>A JSON object, the structure of which is
specific to the Telemetry Source and outside the scope of this
document.</dd>
<dt>Mandatory-to-Specify:</dt><dd>No</dd>
</dl>
</dd>
</dl>
<t>Property: metrics<list style="empty"> <section anchor="telemetry-source-type" numbered="true" toc="default">
<t>Description: The metrics exposed by this source.< <name>Telemetry Source Types</name>
/t> <t>
<t>Type: A JSON array of Telemetry Source Metric obj At the time of this writing, the "CDNI Telemetry Source Types" registry
ects (see <xref target="telemetry-source-metric-object"/>).</t> is limited to a single type: generic (see <xref target="table3"/> in <xref targe
<t>Mandatory-to-Specify: Yes.</t> t="IANA.cdni.telemetry.generic" format="default"/>).
</list></t> </t>
<t>Property: configuration<list style="empty"> </section>
<t>Description: a source-specific representation of <section anchor="telemetry-source-metric-object" numbered="true" toc="
the Telemetry Source configuration. For the generic source type, default">
this configuration format is defined out-of-band. <name>Telemetry Source Metric Object</name>
For other types, the configuration format will be specified in <t> The Telemetry Source Metric Object describes the metric to be
a yet to be defined telemetry interface specifica exposed.
tion. The goal of this element is to allow for forward compatibility </t>
with a formal telemetry interface.</t>
<t>Type: A JSON object, the structure of which is sp
ecific to the Telemetry Source and outside the scope of this document.</t>
<t>Mandatory-to-Specify: No.</t>
</list></t>
</list></t>
<section anchor="telemetry-source-type" title="Telemetry Sou
rce Types">
<t>
At the time of this writing, the registry of valid
Telemetry Source Object types is limited to a single
type: Generic (see <xref target="IANA.cdni.telemetry
.generic"/>).
</t>
<texttable>
<ttcol align="left">
Source Type
</ttcol>
<ttcol align="left">
Description
</ttcol>
<c>generic</c><c>An object which allows for advertis
ement of generic data sources</c>
</texttable>
</section>
<section anchor="telemetry-source-metric-object" title="Tele
metry Source Metric Object">
<t>
The Telemetry Source Metric Object describes the met
ric to be exposed.
</t>
<t><list style="empty">
<t>Property: name<list style="empty">
<t>Description: An identifier for this metric. T
his name MUST be unique among metric objects within the containing Telemetry Sou
rce.
The name MUST remain consistent for the same
source reference across advertisements.</t>
<t>Type: String.</t>
<t>Mandatory-to-Specify: Yes.</t>
</list></t>
<t>Property: time-granularity<list style="empty"> <dl spacing="normal" newline="false">
<t>Description: The time, in seconds, represent <dt>Property:</dt><dd><t>name</t>
ing the metric data. For example, a value representing the last 5 minutes would <dl spacing="normal" newline="false">
have a time-granularity of 300.</t> <dt>Description:</dt><dd>An identifier for this metric. This
<t>Type: Unsigned Integer.</t> name <bcp14>MUST</bcp14> be unique among metric objects within
<t>Mandatory-to-Specify: No.</t> the containing Telemetry Source. The name <bcp14>MUST</bcp14>
</list></t> remain consistent for the same source reference across
advertisements.</dd>
<dt>Type:</dt><dd>String</dd>
<dt>Mandatory-to-Specify:</dt><dd>Yes</dd>
</dl>
</dd>
<dt>Property:</dt><dd><t>time-granularity</t>
<dl spacing="normal" newline="false">
<dt>Description:</dt><dd>The time, in seconds, representing
the metric data. For example, a value representing the last 5
minutes would have a time-granularity of 300.</dd>
<dt>Type:</dt><dd>Unsigned Integer</dd>
<dt>Mandatory-to-Specify:</dt><dd>No</dd>
</dl>
</dd>
<dt>Property:</dt><dd><t>data-percentile</t>
<dl spacing="normal" newline="false">
<dt>Description:</dt><dd>The percentile calculation the data
represents, i.e., 50 percentile would equate to the median
over the time-granularity. Lack of a data-percentile
indicates that the data <bcp14>MUST</bcp14> be the mean over
the time representation.</dd>
<dt>Type:</dt><dd>Unsigned Integer</dd>
<dt>Mandatory-to-Specify:</dt><dd>No</dd>
</dl>
</dd>
<dt>Property:</dt><dd><t>latency</t>
<dl spacing="normal" newline="false">
<dt>Description:</dt><dd>Time in seconds that the data is
behind real-time. This is important to specify to help the
uCDN understand how long it might take to reflect traffic
adjustments in the metrics.</dd>
<dt>Type:</dt><dd>Unsigned Integer</dd>
<dt>Mandatory-to-Specify:</dt><dd>No</dd>
</dl>
</dd>
</dl>
<t>Property: data-percentile<list style="empty"> </section>
<t>Description: The percentile calculation the d </section>
ata represents, i.e., 50 percentile would equate to the median over the time-gra <section anchor="telemetry-capability-object-serialization" numbered="tr
nularity. ue" toc="default">
Lack of a data-percentile indicates that the <name>Telemetry Capability Object Serialization</name>
data MUST be the mean over the time representation.</t>
<t>Type: Unsigned Integer.</t>
<t>Mandatory-to-Specify: No.</t>
</list></t>
<t>Property: latency<list style="empty"> <t> The following shows an example of a Telemetry Capability Object,
<t>Description: Time in seconds that the data is including two metrics for a source, that is scoped to
behind real-time. This is important to specify to help the uCDN a footprint.
understand how long it might take to reflect </t>
traffic adjustments in the metrics.</t> <sourcecode type="json"><![CDATA[
<t>Type: Unsigned Integer.</t>
<t>Mandatory-to-Specify: No.</t>
</list></t>
</list></t>
</section>
</section>
<section anchor="telemetry-capability-object-serialization" titl
e="Telemetry Capability Object Serialization">
<t>
The following shows an example of Telemetry Capability i
ncluding two metrics for a source, that is scoped to a footprint.
</t>
<figure>
<sourcecode>
<![CDATA[
{ {
"capabilities": [ "capabilities": [
{ {
"capability-type": "FCI.Telemetry", "capability-type": "FCI.Telemetry",
"capability-value": { "capability-value": {
"sources": [ "sources": [
{ {
"id": "capacity_metrics_region1", "id": "capacity_metrics_region1",
"type": "generic", "type": "generic",
"metrics": [ "metrics": [
skipping to change at line 393 skipping to change at line 378
} }
] ]
} }
] ]
}, },
"footprints": [ "footprints": [
<footprint objects> <footprint objects>
] ]
} }
] ]
} }]]></sourcecode>
]]> </section>
</sourcecode> </section>
</figure> <section anchor="capacity-limits-capability-object" numbered="true" toc="d
</section> efault">
</section> <name>CapacityLimits Capability Object</name>
<t>The CapacityLimits Capability Object enables the dCDN to specify
<section anchor="capacity-limits-capability-object" title="CapacityL traffic delegation limits to a uCDN within an FCI Capabilities
imits Capability Object"> advertisement. The limits specified by the dCDN will inform the uCDN
<t> on how much traffic may be delegated to the dCDN. The limits specified
The CapacityLimits Capability Object enables the dCDN to spe by the dCDN should be considered NTE limits. The
cify traffic delegation limits limits should be based on near real-time telemetry data that the dCDN
to a uCDN within an FCI.Capabilities advertisement. The lim provides to the uCDN. In other words, for each limit that is
its specified by the dCDN will inform advertised, there should also exist a Telemetry Source that provides
the uCDN on how much traffic may be delegated to the dCDN. T current utilization data against the particular advertised limit.</t>
he limits specified by the dCDN
should be considered Not To Exceed (NTE) limits. The limits
should be based on near real-time
telemetry data that the dCDN provides to the uCDN. In other
words, for each limit that is
advertised, there should also exist a telemetry source which
provides current utilization data
against the particular advertised limit.
</t>
<t><list style="empty">
<t>Property: limits<list style="empty">
<t>Description: A collection of CapacityLimit objects.</
t>
<t>Type: A JSON array of CapacityLimit objects (see <xre
f target="capacity-limit-object"/>).</t>
<t>Mandatory-to-Specify: Yes.</t>
</list></t>
</list></t>
<section anchor="capacity-limit-object" title="CapacityLimit Obj
ect">
<t>
A CapacityLimit object is used to represent traffic
limits for delegation from the uCDN towards the dCDN.
The limit object is scoped to the footprint associated
with the FCI capability advertisement encompassing this
object. Limits MUST be considered using a logical "AND":
a uCDN will need to ensure that all limits are
considered rather than choosing only the most specific.
</t>
<t><list style="empty">
<t>Property: limit-type<list style="empty">
<t>Description: The units of maximum-hard and maximu
m-soft.</t>
<t>Type: String. One of the values listed in <xref t
arget="capacity-limit-type"/>.</t>
<t>Mandatory-to-Specify: Yes.</t>
</list></t>
<t>Property: id<list style="empty"> <dl spacing="normal" newline="false">
<t>Description: Specifies an identifier associated <dt>Property:</dt><dd><t>limits</t>
with a limit. This MAY be used as a relational <dl spacing="normal" newline="false">
identifier to a specific CapacityLimit Object. If <dt>Description:</dt><dd>A collection of CapacityLimit Objects.</d
specified, this identifier MUST be unique among d>
specified identifiers associated with any other <dt>Type:</dt><dd>A JSON array of CapacityLimit Objects (see
CapacityLimit objects in the advertisement <xref target="capacity-limit-object" format="default"/>).</dd>
containing this CapacityLimit Object.</t> <dt>Mandatory-to-Specify:</dt><dd>Yes</dd>
<t>Type: String.</t> </dl>
<t>Mandatory-to-Specify: No.</t> </dd>
</list></t> </dl>
<t>Property: maximum-hard<list style="empty"> <section anchor="capacity-limit-object" numbered="true" toc="default">
<t>Description: The maximum unit of capacity that is <name>CapacityLimit Object</name>
available for use.</t> <t>A CapacityLimit Object is used to represent traffic limits for
<t>Type: Unsigned Integer.</t> delegation from the uCDN towards the dCDN. The limit object is
<t>Mandatory-to-Specify: Yes.</t> scoped to the footprint associated with the FCI Capabilities
</list></t> advertisement encompassing this object. Limits <bcp14>MUST</bcp14>
be considered using a logical "AND": A uCDN will need to ensure that
all limits are considered rather than choosing only the most
specific.
</t>
<t>Property: maximum-soft<list style="empty"> <dl spacing="normal" newline="false">
<t>Description: A soft limit at which a uCDN SHOULD <dt>Property:</dt><dd><t>limit-type</t>
reduce <dl spacing="normal" newline="false">
traffic before hitting the hard limit. This value MU <dt>Description:</dt><dd>The units of maximum-hard and maximum-sof
ST t.</dd>
be less than the value of maximum-hard. If this valu <dt>Type:</dt><dd>String. One of the values listed in <xref target
e is not specified, it is equal ="capacity-limit-type" format="default"/>.</dd>
to the value of maximum-hard.</t> <dt>Mandatory-to-Specify:</dt><dd>Yes</dd>
<t>Type: Unsigned Integer.</t> </dl>
<t>Mandatory-to-Specify: No.</t> </dd>
</list></t> <dt>Property:</dt><dd><t>id</t>
<dl spacing="normal" newline="false">
<dt>Description:</dt><dd>Specifies an identifier associated with
a limit. This <bcp14>MAY</bcp14> be used as a relational
identifier to a specific CapacityLimit Object. If specified,
this identifier <bcp14>MUST</bcp14> be unique among specified
identifiers associated with any other CapacityLimit Objects in
the advertisement containing this CapacityLimit Object.</dd>
<dt>Type:</dt><dd>String</dd>
<dt>Mandatory-to-Specify:</dt><dd>No</dd>
</dl>
</dd>
<dt>Property:</dt><dd><t>maximum-hard</t>
<dl spacing="normal" newline="false">
<dt>Description:</dt><dd>The maximum unit of capacity that is avai
lable for use.</dd>
<dt>Type:</dt><dd>Unsigned Integer</dd>
<dt>Mandatory-to-Specify:</dt><dd>Yes</dd>
</dl>
</dd>
<dt>Property:</dt><dd><t>maximum-soft</t>
<dl spacing="normal" newline="false">
<dt>Description:</dt><dd>A soft limit at which a uCDN
<bcp14>SHOULD</bcp14> reduce traffic before hitting the hard
limit. This value <bcp14>MUST</bcp14> be less than the value of
maximum-hard. If this value is not specified, it is equal to the
value of maximum-hard.</dd>
<dt>Type:</dt><dd>Unsigned Integer</dd>
<dt>Mandatory-to-Specify:</dt><dd>No</dd>
</dl>
</dd>
<dt>Property:</dt><dd><t>current</t>
<dl spacing="normal" newline="false">
<dt>Description:</dt><dd>Specifies the current usage value of
the limit. It is <bcp14>NOT RECOMMENDED</bcp14> to specify the
current usage value inline with the FCI.CapacityLimits
advertisements as it will reduce the ability to cache the
response, but this mechanism exists for simple use cases where
an external Telemetry Source cannot be feasibly implemented. The
intended method for providing telemetry data is to reference a
Telemetry Source Object (see <xref
target="telemetry-source-object" format="default"/>) to poll for
the current usage.</dd>
<dt>Type:</dt><dd>Unsigned Integer</dd>
<dt>Mandatory-to-Specify:</dt><dd>No</dd>
</dl>
</dd>
<dt>Property:</dt><dd><t>telemetry-source</t>
<dl spacing="normal" newline="false">
<dt>Description:</dt><dd>The mapping of each particular limit to a
specific metric with relevant real-time data provided by a
Telemetry Source.</dd>
<dt>Type:</dt><dd>CapacityLimitTelemetrySource object (see <xref
target="capacity-limit-telemetry-source-object"
format="default"/>).</dd>
<dt>Mandatory-to-Specify:</dt><dd>No</dd>
</dl>
</dd>
</dl>
<t>Property: current<list style="empty"> <section anchor="capacity-limit-type" numbered="true" toc="default">
<t>Description: Specifies the current usage value of <name>CapacityLimit Types</name>
the limit. It is NOT RECOMMENDED to specify the current usage <t>Below are listed the valid limit-type entries registered in
value inline with the FCI.CapacityLimits advertis the "CDNI Capacity Limit Types" registry. The values specified here
ements as it will reduce the ability to cache the response, but this represent the types that were identified as being the most
mechanism exists for simple use cases where an ex relevant metrics for the purposes of traffic delegation between
ternal telemetry source cannot be feasibly implemented. The CDNs.
intended method for providing telemetry data is t </t>
o reference a Telemetry Source object <table align="center">
(see <xref target="telemetry-source-object"/>) to <thead>
poll for the current usage.</t> <tr>
<t>Type: Unsigned Integer.</t> <th align="left">
<t>Mandatory-to-Specify: No.</t> Capacity Limit Type
</list></t> </th>
<th align="left">
Units
</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">egress</td>
<td align="left">Bits per second</td>
</tr>
<tr>
<td align="left">requests</td>
<td align="left">Requests per second</td>
</tr>
<tr>
<td align="left">storage-size</td>
<td align="left">Total bytes</td>
</tr>
<tr>
<td align="left">storage-objects</td>
<td align="left">Count</td>
</tr>
<tr>
<td align="left">sessions</td>
<td align="left">Count</td>
</tr>
<tr>
<td align="left">cache-size</td>
<td align="left">Total bytes</td>
</tr>
</tbody>
</table>
</section>
<section anchor="capacity-limit-telemetry-source-object" numbered="tru
e" toc="default">
<name>CapacityLimitTelemetrySource Object</name>
<t> The CapacityLimitTelemetrySource Object refers to a specific
metric within a Telemetry Source.</t>
<t>Property: telemetry-source<list style="empty"> <dl spacing="normal" newline="false">
<t>Description: Mapping of each particular limit to <dt>Property:</dt><dd><t>id</t>
a specific metric with relevant real-time data provided by <dl spacing="normal" newline="false">
a telemetry source.</t> <dt>Description:</dt><dd>Reference to the "id" of a
<t>Type: CapacityLimitTelemetrySource object (see <x Telemetry Source defined by a Telemetry Capability Object as
ref target="capacity-limit-telemetry-source-object"/>).</t> defined in <xref target="telemetry-capability-object"
<t>Mandatory-to-Specify: No.</t> format="default"/>.</dd>
</list></t> <dt>Type:</dt><dd>String</dd>
<dt>Mandatory-to-Specify:</dt><dd>Yes</dd>
</dl>
</dd>
<dt>Property:</dt><dd><t>metric</t>
<dl spacing="normal" newline="false">
<dt>Description:</dt><dd>Reference to the "name" property of
a metric defined within a Telemetry Source of a Telemetry
Capability object.</dd>
<dt>Type:</dt><dd>String</dd>
<dt>Mandatory-to-Specify:</dt><dd>Yes</dd>
</dl>
</dd>
</dl>
</list></t> </section>
<section anchor="capacity-limit-type" title="CapacityLimit T </section>
ypes"> <section anchor="capacity-limit-object-serialization" numbered="true" to
<t> c="default">
Below are listed the valid capacity limit-types <name>CapacityLimit Object Serialization</name>
registered in the CDNI Capacity Limit Types <t> The following shows an example of an FCI.CapacityLimits object.</t
registry. The values specified here represent the >
types that were identified as being the most
relevant metrics for the purposes of traffic
delegation between CDNs.
</t>
<texttable>
<ttcol align="left">
Limit Type
</ttcol>
<ttcol align="left">
Units
</ttcol>
<c>egress</c><c>Bits per second</c>
<c>requests</c><c>Requests per second</c>
<c>storage-size</c><c>Total bytes</c>
<c>storage-objects</c><c>Count</c>
<c>sessions</c><c>Count</c>
<c>cache-size</c><c>Total bytes</c>
</texttable>
</section>
<section anchor="capacity-limit-telemetry-source-object" tit
le="CapacityLimitTelemetrySource Object">
<t>
The CapacityLimitTelemetrySource Object refers to a
specific metric within a Telemetry Source.
</t>
<t><list style="empty">
<t>Property: id<list style="empty">
<t>Description: Reference to the "id" of a telem
etry source defined by a Telemetry Capability
object as defined in <xref target="telemetry-cap
ability-object"/>.</t>
<t>Type: String.</t>
<t>Mandatory-to-Specify: Yes.</t>
</list></t>
<t>Property: metric<list style="empty"> <sourcecode type="json"><![CDATA[
<t>Description: Reference to the "name" propert
y of a metric defined within a telemetry source of a
Telemetry Capability object.</t>
<t>Type: String.</t>
<t>Mandatory-to-Specify: Yes.</t>
</list></t>
</list></t>
</section>
</section>
<section anchor="capacity-limit-object-serialization" title="Cap
acityLimit Object Serialization">
<t>
The following shows an example of an FCI.CapacityLimits
object.
</t>
<figure>
<sourcecode>
<![CDATA[
{ {
"capabilities": [ "capabilities": [
{ {
"capability-type":"FCI.CapacityLimits", "capability-type":"FCI.CapacityLimits",
"capability-value":{ "capability-value":{
"limits":[ "limits":[
{ {
"id":"capacity_limit_region1", "id":"capacity_limit_region1",
"limit-type":"egress", "limit-type":"egress",
"maximum-hard":50000000000, "maximum-hard":50000000000,
skipping to change at line 555 skipping to change at line 586
"metric":"egress_5m" "metric":"egress_5m"
} }
} }
] ]
}, },
"footprints":[ "footprints":[
"<footprint objects>" "<footprint objects>"
] ]
} }
] ]
} }]]></sourcecode>
]]>
</sourcecode>
</figure>
</section>
</section>
</section> </section>
<section anchor="IANA" title="IANA Considerations"> </section>
<section anchor="IANA.cdni.payload.types" title="CDNI Payload Types" </section>
> <section anchor="IANA" numbered="true" toc="default">
<t> <name>IANA Considerations</name>
This document requests the registration of two additional pa <section anchor="IANA.cdni.payload.types" numbered="true" toc="default">
yload types to the Content Delivery Network Interconnection (CDNI) Parameters "C <name>CDNI Payload Types</name>
DNI Payload Types" registry: <t>Per this document, IANA has registered two additional payload
</t> types in the "CDNI Payload Types" registry within the "Content Delivery
<texttable> Network Interconnection (CDNI) Parameters" registry group:
<ttcol align="left"> </t>
Payload Type <table align="center">
</ttcol> <thead>
<ttcol align="left"> <tr>
Specification <th align="left">Payload Type</th>
</ttcol> <th align="left">Reference</th>
<c>FCI.Telemetry</c><c>RFCthis</c> </tr>
<c>FCI.CapacityLimits</c><c>RFCthis</c> </thead>
</texttable> <tbody>
<t> <tr>
[RFC Editor: Please replace RFCthis with the published RFC <td align="left">FCI.Telemetry</td>
number for this document.] <td align="left">RFC 9808</td>
</t> </tr>
<section anchor="IANA.cdni.fci.telemetry.payload.type" title="CD <tr>
NI FCI Telemetry Payload Type"> <td align="left">FCI.CapacityLimits</td>
<t><list style="empty"> <td align="left">RFC 9808</td>
<t>Purpose: The purpose of this Payload Type is to list </tr>
the supported telemetry sources </tbody>
and the metrics made available by each source.</t> </table>
<t>Interface: FCI.</t>
<t>Encoding: See <xref target="telemetry-capability-obje
ct"/>.</t>
</list></t>
</section>
<section anchor="IANA.cdni.fci.capacity.limits.payload.type" tit
le="CDNI FCI Capacity Limits Payload Type">
<t><list style="empty">
<t>Purpose: The purpose of this Payload Type is to defin
e Capacity Limits based on utilization metrics
corresponding to telemetry sources provided by the dCDN.
</t>
<t>Interface: FCI.</t>
<t>Encoding: See <xref target="capacity-limits-capabilit
y-object"/>.</t>
</list></t>
</section>
</section>
<section anchor="IANA.cdni.telemetry.registry" title="&quot;CDNI Tel <section anchor="IANA.cdni.fci.telemetry.payload.type" numbered="true" t
emetry Source Types&quot; Registry"> oc="default">
<t> <name>CDNI FCI.Telemetry Payload Type</name>
IANA will add the following new registry to the "Content Del
ivery Network Interconnection (CDNI) Parameters" group at https://www.iana.org/a <dl spacing="normal" newline="false">
ssignments/cdni-parameters: <dt>Purpose:</dt><dd>The purpose of this Payload Type is to list
</t> the supported Telemetry Sources and the metrics made available by
<t>Registry Name: CDNI Telemetry Source Types</t> each source.</dd>
<t>Registry Description: The CDNI Telemetry Source Types registr <dt>Interface:</dt><dd>FCI</dd>
y defines the valid values for the "type" property of the Telemetry Source objec <dt>Encoding:</dt><dd>See <xref target="telemetry-capability-object"
t defined in <xref target="telemetry-source-object"/>.</t> format="default"/>.</dd>
<t>Registration Procedure: The registry follows the Specificatio </dl>
n Required policy as defined in <xref target="RFC8126" />.
The Designated Expert should consider the following guidelines w
hen evaluating registration requests:</t>
<list style="symbols">
<t>The new type definition does not duplicate existing types
.</t>
<t>The review should verify that the telemetry source is app
licable to the CDNI use cases and that the description is clear and unambiguous.
</t>
<t>The registration is applicable for general use and not pr
oprietary.</t>
<t>The "configuration" property has a fully specified object
definition with a description of each defined property.</t>
</list>
<t>The following values will be registered:</t>
<texttable>
<ttcol align="left">
Source Type
</ttcol>
<ttcol align="left">
Specification
</ttcol>
<c>generic</c><c>RFCthis</c>
</texttable>
<section anchor="IANA.cdni.telemetry.generic" title="CDNI Generi
c Telemetry Source Type">
<t><list style="empty">
<t>Purpose: The purpose of this Telemetry Source Type is
to provide a source-agnostic telemetry type that may be used for generic teleme
try source advertisement.</t>
<t>Usage: See <xref target="telemetry-source-object"/>.<
/t>
</list></t>
</section>
</section>
<!-- New CDNI Capacity Limit Types Registry -->
<section anchor="IANA.cdni.capacity.registry" title="&quot;CDNI Capa
city Limit Types&quot; Registry">
<t>
IANA will add the following new registry to the "Content Del
ivery Network Interconnection (CDNI) Parameters" group at https://www.iana.org/a
ssignments/cdni-parameters:
</t>
<t>Registry Name: CDNI Capacity Limit Types</t>
<t>Registry Description: The CDNI Capacity Limit Types registry
defines the valid values of the "limit-type" property of a CapacityLimit object
defined in <xref target="capacity-limit-object"/>.</t>
<t>Registration Procedure: The registry follows the Specificatio
n Required policy as defined in <xref target="RFC8126" />.
The Designated Expert should consider the following guidelines w
hen evaluating registration requests:</t>
<list style="symbols">
<t>The new capacity limit type does not duplicate existing e
ntries.</t>
<t>The submission has a defined purpose. The newly defined c
apacity limit type should be clearly justified in the context of one or more CDN
I use cases.</t>
<t>The description of the capacity limit type is well-docume
nted and unambiguous.</t>
</list>
<t>The following values will be registered:</t>
<texttable>
<ttcol align="left">
Capacity Limit Type
</ttcol>
<ttcol align="left">
Units
</ttcol>
<ttcol align="left">
Specification
</ttcol>
<c>egress</c><c>Bits per second</c><c>RFCthis</c>
<c>requests</c><c>Requests per second</c><c>RFCthis</c>
<c>storage-size</c><c>Total bytes</c><c>RFCthis</c>
<c>storage-objects</c><c>Count</c><c>RFCthis</c>
<c>sessions</c><c>Count</c><c>RFCthis</c>
<c>cache-size</c><c>Total bytes</c><c>RFCthis</c>
</texttable>
<t>Usage: See <xref target="capacity-limit-type"/>.</t>
</section>
</section> </section>
<section anchor="IANA.cdni.fci.capacity.limits.payload.type" numbered="t
rue" toc="default">
<name>CDNI FCI.CapacityLimits Payload Type</name>
<dl spacing="normal" newline="false">
<dt>Purpose:</dt><dd>The purpose of this Payload Type is to define
Capacity Limits based on utilization metrics corresponding to
Telemetry Sources provided by the dCDN.</dd>
<dt>Interface:</dt><dd>FCI</dd>
<dt>Encoding:</dt><dd>See <xref target="capacity-limits-capability-o
bject" format="default"/>.</dd>
</dl>
<section anchor="Security" title="Security Considerations">
<t>
This specification is in accordance with the CDNI Request Routin
g:
Footprint and Capabilities Semantics. As such, it is subject to
the security and privacy considerations as
defined in Section 7 of
<xref target="RFC8008" />.
</t>
</section> </section>
<section anchor="Acknowledgements" title="Acknowledgements"> </section>
<t> <section anchor="IANA.cdni.telemetry.registry" numbered="true" toc="defaul
The authors would like to express their gratitude to the t">
members of the <name>CDNI Telemetry Source Types Registry</name>
Streaming Video Technology Alliance <t>IANA has added the following new registry within the "Content Deliver
<xref target="SVTA"/> y
Open Caching Working Group for their guidance, contribution, and Network Interconnection (CDNI) Parameters" registry group at
review. <eref target="https://www.iana.org/assignments/cdni-parameters" brackets
</t> ="angle"/>:</t>
<dl spacing="normal" newline="false">
<dt>Registry Name:</dt><dd>CDNI Telemetry Source Types</dd>
<dt>Registry Description:</dt><dd>The "CDNI Telemetry Source Types"
registry defines the valid values for the "type" property of the
Telemetry Source object defined in <xref
target="telemetry-source-object" format="default"/>.</dd>
<dt>Registration Procedure:</dt><dd><t>The registry follows the
Specification Required policy as defined in <xref target="RFC8126"
format="default"/>. The designated expert should consider the
following guidelines when evaluating registration requests:</t>
<ul spacing="normal">
<li>The new type definition does not duplicate existing
types.</li>
<li>The review should verify that the Telemetry Source is
applicable to the CDNI use cases and that the description is clear
and unambiguous.</li>
<li>The registration is applicable for general use and is not propri
etary.</li>
<li>The "configuration" property has a fully specified object
definition with a description of each defined property.</li>
</ul>
</dd>
</dl>
<t>The following value has been registered:</t>
<table anchor="table3" align="center">
<thead>
<tr>
<th align="left">Source Type</th>
<th align="left">Description</th>
<th align="left">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">generic</td>
<td>An object that allows for advertisement of generic data sources
</td>
<td align="left">RFC 9808</td>
</tr>
</tbody>
</table>
<section anchor="IANA.cdni.telemetry.generic" numbered="true" toc="defau
lt">
<name>CDNI Generic Telemetry Source Type</name>
<dl spacing="normal" newline="false">
<dt>Purpose:</dt><dd>The purpose of this Telemetry Source Type is
to provide a source-agnostic telemetry type that may be used for
generic Telemetry Source advertisement.</dd>
<dt>Usage:</dt><dd>See <xref target="telemetry-source-object" format
="default"/>.</dd>
</dl>
</section> </section>
</middle> </section>
<back>
<references title="Normative References"> <section anchor="IANA.cdni.capacity.registry" numbered="true" toc="default
<?rfc include="reference.RFC.2119"?> ">
<?rfc include="reference.RFC.8008"?> <name>CDNI Capacity Limit Types Registry</name>
<?rfc include="reference.RFC.8126"?> <t>IANA has added the following new registry within the "Content Deliver
<?rfc include="reference.RFC.8174"?> y
</references> Network Interconnection (CDNI) Parameters" registry group at
<eref target="https://www.iana.org/assignments/cdni-parameters" brackets
="angle"/>:</t>
<dl spacing="normal" newline="false">
<dt>Registry Name:</dt><dd>CDNI Capacity Limit Types</dd>
<dt>Registry Description:</dt><dd>The "CDNI Capacity Limit Types"
registry defines the valid values of the "limit-type" property of a
CapacityLimit Object defined in <xref target="capacity-limit-object"
format="default"/>.</dd>
<dt>Registration Procedure:</dt><dd><t>The registry follows the
Specification Required policy as defined in <xref target="RFC8126"
format="default"/>. The designated expert should consider the
following guidelines when evaluating registration requests:</t>
<ul spacing="normal">
<li>The new capacity limit-type does not duplicate existing entries.
</li>
<li>The submission has a defined purpose. The newly defined
capacity limit-type should be clearly justified in the context of
one or more CDNI use cases.</li>
<li>The description of the capacity limit-type is well-documented an
d unambiguous.</li>
</ul>
</dd>
</dl>
<t>The following values have been registered:</t>
<table align="center">
<thead>
<tr>
<th align="left">Capacity Limit Type</th>
<th align="left">Units</th>
<th align="left">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">egress</td>
<td align="left">Bits per second</td>
<td align="left">RFC 9808</td>
</tr>
<tr>
<td align="left">requests</td>
<td align="left">Requests per second</td>
<td align="left">RFC 9808</td>
</tr>
<tr>
<td align="left">storage-size</td>
<td align="left">Total bytes</td>
<td align="left">RFC 9808</td>
</tr>
<tr>
<td align="left">storage-objects</td>
<td align="left">Count</td>
<td align="left">RFC 9808</td>
</tr>
<tr>
<td align="left">sessions</td>
<td align="left">Count</td>
<td align="left">RFC 9808</td>
</tr>
<tr>
<td align="left">cache-size</td>
<td align="left">Total bytes</td>
<td align="left">RFC 9808</td>
</tr>
</tbody>
</table>
<dl spacing="normal" newline="false">
<dt>Usage:</dt><dd>See <xref target="capacity-limit-type" format="defaul
t"/>.</dd>
</dl>
</section>
</section>
<section anchor="Security" numbered="true" toc="default">
<name>Security Considerations</name>
<t>This specification is in accordance with the CDNI Request Routing:
Footprint and Capabilities Semantics. As such, it is subject to the
security and privacy considerations as defined in <xref
section="7" target="RFC8008" format="default"/>.
</t>
</section>
</middle>
<back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
008.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
126.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
006.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
707.xml"/>
<reference anchor="SVTA" target="https://www.svta.org">
<front>
<title>Streaming Video Technology Alliance Home Page</title>
<author/>
<date/>
</front>
</reference>
</references>
</references>
<section anchor="Acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>The authors would like to express their gratitude to the members of
the Streaming Video Technology Alliance <xref target="SVTA"
format="default"/> Open Caching Working Group for their guidance,
contribution, and review.
</t>
</section>
</back>
<references title="Informative References">
<?rfc include="reference.RFC.8006"?>
<?rfc include="reference.RFC.6707"?>
<reference anchor="SVTA" target="https://www.svta.org">
<front>
<title>
Streaming Video Technology Alliance Home Page
</title>
<author />
<date />
</front>
</reference>
<reference anchor="OCWG" target="https://opencaching.svta.org/">
<front>
<title>
Open Caching Home Page
</title>
<author />
<date />
</front>
</reference>
<reference anchor="OC-CII" target="https://www.svta.org/document/ope
n-caching-capacity-interface/">
<front>
<title>
Open Caching Capacity Insights - Functional Specificatio
n (Placeholder before publication)
</title>
<author initials="A." surname="Ryan" fullname="Andrew Ryan"
role="editor">
<organization>
Limelight Networks
</organization>
</author>
<author initials="B." surname="Rosenblum" fullname="Ben Rose
mblum">
<organization>
Vecima
</organization>
</author>
<author initials="G." surname="Goldstein" fullname="Glenn Go
ldstein">
<organization>
Lumen Technologies
</organization>
</author>
<author initials="R." surname="Roskin" fullname="Rob Roskin"
>
<organization>
Lumen Technologies
</organization>
</author>
<author initials="G." surname="Bichot" fullname="Guillaume B
ichot">
<organization>
Broadpeak
</organization>
</author>
<date />
</front>
</reference>
<reference anchor="OC-RR" target="https://www.svta.org/product/open-
cache-request-routing-functional-specification/">
<front>
<title>
Open Caching Request Routing - Functional Specification
</title>
<author initials="O." surname="Finkelman" fullname="Ori Fink
elman" role="editor">
<organization>
Qwilt
</organization>
</author>
<author initials="J." surname="Hofmann" fullname="Jason Hofm
ann">
<organization>
Limelight Networks
</organization>
</author>
<author initials="E." surname="Klein" fullname="Eric Klein">
<organization>
Disney Streaming Services
</organization>
</author>
<author initials="S." surname="Mishra" fullname="Sanjay Mish
ra">
<organization>
Verizon
</organization>
</author>
<author initials="K." surname="Ma" fullname="Kevin J. Ma">
<organization>
Disney Streaming Services
</organization>
</author>
<author initials="D." surname="Sahar" fullname="Dan Sahar">
<organization>
Qwilt
</organization>
</author>
<author initials="B." surname="Zurat" fullname="Bill Zurat">
<organization>
Disney Streaming Services
</organization>
</author>
<date day="4" month="October" year="2019" />
</front>
<seriesInfo name="Version" value="1.1" />
</reference>
</references>
</back>
</rfc> </rfc>
 End of changes. 47 change blocks. 
784 lines changed or deleted 738 lines changed or added

This html diff was produced by rfcdiff 1.48.