rfc8896xml2.original.xml   rfc8896.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<!ENTITY I-D.ietf-alto-incr-update-sse SYSTEM "https://xml2rfc.ietf.org/public/r
fc/bibxml3/reference.I-D.ietf-alto-incr-update-sse.xml">
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.2119.xml">
<!ENTITY RFC7285 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7285.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8174.xml">
<!ENTITY RFC8189 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8189.xml">
<!ENTITY RFC8259 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8259.xml">
<!ENTITY I-D.ietf-alto-performance-metrics SYSTEM "https://xml2rfc.ietf.org/publ
ic/rfc/bibxml3/reference.I-D.ietf-alto-performance-metrics.xml">
<!ENTITY I-D.xiang-alto-multidomain-analytics SYSTEM "https://xml2rfc.ietf.org/p
ublic/rfc/bibxml3/reference.I-D.xiang-alto-multidomain-analytics.xml">
<!ENTITY IEEE.754.2008 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml6/refer
ence.IEEE.754.2008.xml">
<!ENTITY RFC2818 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.2818.xml">
<!ENTITY RFC5246 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5246.xml">
<!ENTITY RFC5693 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5693.xml">
<!ENTITY RFC6708 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6708.xml">
<!ENTITY RFC7159 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7159.xml">
<!ENTITY RFC7231 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7231.xml">
<!ENTITY RFC8446 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8446.xml">
]>
<rfc submissionType="IETF" docName="draft-ietf-alto-cost-calendar-21" category="
std" ipr="trust200902">
<!-- Generated by id2xml 1.5.0 on 2020-02-23T20:23:49Z -->
<?rfc compact="yes"?>
<?rfc text-list-symbols="o*+-"?>
<?rfc subcompact="no"?>
<?rfc sortrefs="no"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<front>
<title abbrev="ALTO Cost Calendar">Application-Layer Traffic Optimization
(ALTO) Cost Calendar</title>
<author fullname="Sabine Randriamasy" initials="S." surname="Randriamasy"
>
<organization>Nokia Bell Labs</organization>
<address><postal><street>Route de Villejust</street>
<street>NOZAY 91460</street>
<street>FRANCE</street>
</postal>
<email>Sabine.Randriamasy@nokia-bell-labs.com</email>
</address>
</author>
<author fullname="Richard Yang" initials="R." surname="Yang">
<organization>Yale University</organization>
<address><postal><street>51 Prospect st</street>
<street>New Haven, CT 06520</street>
<street>USA</street>
</postal>
<email>yry@cs.yale.edu</email>
</address>
</author>
<author fullname="Qin Wu" initials="Q." surname="Wu">
<organization>Huawei</organization>
<address><postal><street>101 Software Avenue, Yuhua District</street>
<street>Nanjing, Jiangsu 210012</street>
<street>China</street>
</postal>
<email>sunseawq@huawei.com</email>
</address>
</author>
<author fullname="Lingli Deng" initials="L." surname="Deng">
<organization>China Mobile</organization>
<address><postal><street>China</street>
</postal>
<email>denglingli@chinamobile.com</email>
</address>
</author>
<author fullname="Nico Schwan" initials="N." surname="Schwan">
<organization>Thales Deutschland</organization>
<address><postal><street>Lorenzstrasse 10</street>
<street>Stuttgart 70435</street>
<street>Germany</street>
</postal>
<email>nico.schwan@thalesgroup.com</email>
</address>
</author>
<date day="17" month="March" year="2020"/>
<abstract><t>
This document is an extension to the base Application-Layer Traffic
Optimization (ALTO) protocol. It extends the ALTO cost information
service so that applications decide not only 'where' to connect, but
also 'when'. This is useful for applications that need to perform
bulk data transfer and would like to schedule these transfers during
an off-peak hour, for example. This extension introduces ALTO Cost
Calendar, with which an ALTO Server exposes ALTO cost values in JSON
arrays where each value corresponds to a given time interval. The
time intervals as well as other Calendar attributes, are specified in
the Information Resources Directory and ALTO Server responses.</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="sect-1"><t>
The base Application-Layer Traffic Optimization (ALTO) protocol
specified in <xref target="RFC7285"/> provides guidance to overlay applicatio
ns that
need to select one or several hosts from a set of candidates able to
provide a desired resource. This guidance is based on parameters
that affect performance and efficiency of the data transmission
between the hosts such as the topological distance. The goal of ALTO
is to improve the Quality of Experience (QoE) in the application
while optimizing resource usage in the underlying network
infrastructure.</t>
<t>
The ALTO protocol in <xref target="RFC7285"/> specifies a network map which d
efines
groupings of endpoints in provider-defined network regions identified
by Provider-defined Identifiers (PIDs). The Cost Map Service,
Endpoint Cost Service (ECS) and Endpoint Ranking Service then provide
ISP-defined costs and rankings for connections among the specified
endpoints and PIDs and thus incentives for application clients to
connect to ISP preferred locations, for instance, to reduce their
costs. For the reasons outlined in the ALTO problem statement
<xref target="RFC5693"/> and requirement AR-14 of <xref target="RFC6708"/>, A
LTO does not
disseminate network metrics that change frequently. In a network,
the costs can fluctuate for many reasons having to do with
instantaneous traffic load or due to diurnal patterns of traffic
demand or planned events such as network maintenance, holidays or
highly publicized events. Thus, an ALTO application wishing to use
the Cost Map and Endpoint Cost Service at some future time will have
to estimate the state of the network at that time, a process that is,
at best, fragile and brittle since the application does not have any
visibility into the state of the network. Providing network costs
for only the current time thus may not be sufficient, in particular
for applications that can schedule their traffic in a span of time,
for example by deferring backups or other background traffic to off-
peak hours.</t>
<t>
In case the ALTO Cost value changes are predictable over a certain
period of time and the application does not require immediate data
transfer, it can save time to get the whole set of cost values over
this period in one single ALTO response. Using this set to schedule
data transfers allows optimizing the network resources usage and QoE.
ALTO Clients and Servers can also minimize their workload by reducing
and accordingly scheduling their data exchanges.</t>
<t>
This document extends <xref target="RFC7285"/> to allow an ALTO Server to pro
vide
network costs for a given duration of time. A sequence of network
costs across a time span for a given pair of network locations is
named an "ALTO Cost Calendar". The Filtered Cost Map Service and
Endpoint Cost Service are extended to provide Cost Calendars. In
addition to this functional ALTO enhancement, we expect to further
save network and storage resources by gathering multiple Cost Values
for one cost type into one single ALTO Server response.</t>
<t>
In this document, an "ALTO Cost Calendar" is specified in terms of
information resource capabilities that are applicable to time-
sensitive ALTO metrics. An ALTO Cost Calendar exposes ALTO Cost
Values in JSON arrays, see <xref target="RFC8259"/>, where each value corresp
onds to
a given time interval. The time intervals as well as other Calendar
attributes are specified in the Information Resources Directory (IRD)
and in the Server response to allow the ALTO Client to interpret the
received ALTO values. Last, the extensions for ALTO Calendars are
applicable to any Cost Mode and they ensure backwards compatibility
with legacy ALTO Clients - those that only support <xref target="RFC7285"/>.<
/t>
<t>
In the rest of this document, <xref target="sect-3"/> provides the design
characteristics. Sections <xref target="sect-4"/> and <xref target="sect-5"/
>
define the formal specifications for the IRD and the information resources.
IANA, security and operational considerations are addressed respectively in s
ections
<xref target="sect-6"/>, <xref target="sect-7"/> and <xref target="sect-8"/>.
</t>
<section title="Some recent known uses" anchor="sect-1.1">
<t> A potential use case is implementing smart network services that
allow applications to dynamically build end-to-end, virtual networks,
to satisfy given demands, with no manual intervention. For
example, data-transfer automation applications may need a network
service to determine on the availability of bandwidth resources,
to decide when to transfer their data sets. The SENSE project
[SENSE-sdn-e2e-net] supports such applications by requiring that
a network provides services such as the Time-Bandwidth-Product (TBP)
service, which informs applications of bandwidth availability during
a specific time period. ALTO Calendars can support this service if the
Calendar start date and duration cover the period of interest of the
requesting application.
</t>
<t>
The need of future scheduling of large scale traffic that can be
addressed by the ALTO protocol is also motivated by Unicorn, a
unified resource orchestration framework for multi-domain, geo-
distributed data analytics, see
<xref target="Unicorn-fgcs"/>.
</t>
</section>
<section title="Terminology" anchor="sect-1.2"><t><list style="symbols">
<t>ALTO transaction: A request/response exchange between an ALTO
Client and an ALTO Server.</t>
<t>Client: When used with a capital "C", this term refers to an ALTO
Client.</t>
<t>Calendar, Cost Calendar: When used with capitalized words, these
terms refer to an ALTO Cost Calendar.</t>
<t>Calendared: this adjective qualifies information resources providing Co
st Calendars
and information on costs that are provided in the form of a Cost Calendar.
</t>
<t>Endpoint (EP): An endpoint is defined as in Section 2.1 of
<xref target="RFC7285"/>. It can be, for example, a peer, a CDN storage
location, a physical server involved in a virtual server-supported
application, a party in a resource-sharing swarm such as a
computation grid, or an online multi-party game.</t>
<t>ECM: Is an abbreviation for Endpoint Cost Map.</t>
<t>FCM: Is an abbreviation for Filtered Cost Map.</t>
<t>Server: When used with a capital "S", this term refers to an ALTO
Server.</t>
</list>
</t>
</section>
</section>
<section title="Requirements Language" anchor="sect-2"><t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this 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 here.</t>
<t> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF"
When the words appear in lower case, they are to be interpreted with category="std" consensus="true"
their natural language meanings.</t> docName="draft-ietf-alto-cost-calendar-21" number="8896"
ipr="trust200902" obsoletes="" updates="" xml:lang="en" sortRefs="true"
symRefs="true" tocInclude="true" version="3">
</section> <!-- xml2rfc v2v3 conversion 2.42.0 -->
<!-- Generated by id2xml 1.5.0 on 2020-02-23T20:23:49Z -->
<front>
<title abbrev="ALTO Cost Calendar">Application-Layer Traffic Optimization
(ALTO) Cost Calendar</title>
<seriesInfo name="RFC" value="8896"/>
<author fullname="Sabine Randriamasy" initials="S." surname="Randriamasy">
<organization>Nokia Bell Labs</organization>
<address>
<postal>
<street>Route de Villejust</street>
<city>Nozay</city>
<code>91460</code>
<country>France</country>
</postal>
<email>Sabine.Randriamasy@nokia-bell-labs.com</email>
</address>
</author>
<author fullname="Y. Richard Yang" initials="Y." surname="Yang">
<organization>Yale University</organization>
<address>
<postal>
<street>51 Prospect St.</street>
<city>New Haven</city>
<region>CT</region>
<code>06520</code>
<country>United States of America</country>
</postal>
<email>yry@cs.yale.edu</email>
</address>
</author>
<author fullname="Qin Wu" initials="Q." surname="Wu">
<organization>Huawei</organization>
<address>
<postal>
<street>101 Software Avenue</street>
<extaddr>Yuhua District</extaddr>
<city>Nanjing</city>
<region>Jiangsu</region>
<code>210012</code>
<country>China</country>
</postal>
<email>sunseawq@huawei.com</email>
</address>
</author>
<author fullname="Lingli Deng" initials="L." surname="Deng">
<organization>China Mobile</organization>
<address>
<postal>
<country>China</country>
</postal>
<email>denglingli@chinamobile.com</email>
</address>
</author>
<author fullname="Nico Schwan" initials="N." surname="Schwan">
<organization>Thales Deutschland</organization>
<address>
<postal>
<street>Lorenzstrasse 10</street>
<city>Stuttgart</city><code>70435</code>
<country>Germany</country>
</postal>
<email>nico.schwan@thalesgroup.com</email>
</address>
</author>
<date year="2020" month="November" />
<section title="Overview of ALTO Cost Calendars and terminology" anchor=" <abstract>
sect-3"> <t>This document is an extension to the base Application-Layer Traffic
Optimization (ALTO) protocol. It extends the ALTO cost information
service so that applications decide not only 'where' to connect but
also 'when'. This is useful for applications that need to perform bulk
data transfer and would like to schedule these transfers during an
off-peak hour, for example. This extension introduces the ALTO Cost
Calendar with which an ALTO Server exposes ALTO cost values in JSON
arrays where each value corresponds to a given time interval. The time
intervals, as well as other Calendar attributes, are specified in the
Information Resources Directory and ALTO Server responses.</t>
</abstract>
</front>
<middle>
<section anchor="sect-1" numbered="true" toc="default">
<name>Introduction</name>
<t>The base Application-Layer Traffic Optimization (ALTO) protocol
specified in <xref target="RFC7285" format="default"/> provides guidance
to overlay applications that need to select one or several hosts from a
set of candidates able to provide a desired resource. This guidance is
based on parameters that affect performance and efficiency of the data
transmission between the hosts, such as the topological distance. The
goal of ALTO is to improve the Quality of Experience (QoE) in the
application while optimizing resource usage in the underlying network
infrastructure.</t>
<t>The ALTO protocol in <xref target="RFC7285" format="default"/>
specifies a network map that defines groupings of endpoints in
provider-defined network regions identified by Provider-defined
Identifiers (PIDs). The Cost Map Service, Endpoint Cost Service (ECS),
and Endpoint Ranking Service then provide ISP-defined costs and rankings
for connections among the specified endpoints and PIDs and thus
incentives for application clients to connect to ISP-preferred
locations, for instance, to reduce their costs. For the reasons
outlined in the ALTO problem statement <xref target="RFC5693"
format="default"/> and requirement AR-14 of <xref target="RFC6708"
format="default"/>, ALTO does not disseminate network metrics that
change frequently. In a network, the costs can fluctuate for many
reasons having to do with instantaneous traffic load or diurnal
patterns of traffic demand or planned events, such as network
maintenance, holidays, or highly publicized events. Thus, an ALTO
application wishing to use the Cost Map and Endpoint Cost Service at
some future time will have to estimate the state of the network at that
time, a process that is, at best, fragile and brittle, since the
application does not have any visibility into the state of the network.
Providing network costs for only the current time thus may not be
sufficient, in particular for applications that can schedule their
traffic in a span of time, for example, by deferring backups or other
background traffic to off- peak hours.</t>
<t>In case the ALTO cost value changes are predictable over a certain
period of time and the application does not require immediate data
transfer, it can save time to get the whole set of cost values over this
period in one single ALTO response. Using this set to schedule data
transfers allows optimizing the network resources usage and QoE. ALTO
Clients and Servers can also minimize their workload by reducing and
accordingly scheduling their data exchanges.</t>
<t>This document extends <xref target="RFC7285" format="default"/> to
allow an ALTO Server to provide network costs for a given duration of
time. A sequence of network costs across a time span for a given pair
of network locations is named an "ALTO Cost Calendar". The Filtered
Cost Map Service and Endpoint Cost Service are extended to provide Cost
Calendars. In addition to this functional ALTO enhancement, we expect
to further save network and storage resources by gathering multiple cost
values for one cost type into one single ALTO Server response.</t>
<t>In this document, an "ALTO Cost Calendar" is specified in terms of
information resource capabilities that are applicable to time-sensitive
ALTO metrics. An ALTO Cost Calendar exposes ALTO cost values in JSON
arrays, see <xref target="RFC8259" format="default"/>, where each value
corresponds to a given time interval. The time intervals, as well as
other Calendar attributes, are specified in the Information Resources
Directory (IRD) and in the Server response to allow the ALTO Client to
interpret the received ALTO values. Last, the extensions for ALTO
Calendars are applicable to any cost mode, and they ensure backwards
compatibility with legacy ALTO Clients -- those that only support <xref
target="RFC7285" format="default"/>.</t>
<t>In the rest of this document, <xref target="sect-3"
format="default"/> provides the design characteristics. Sections <xref
target="sect-4" format="counter"/> and <xref target="sect-5"
format="counter"/> define the formal specifications for the IRD and the
information resources. IANA, security considerations, and operational
considerations are addressed respectively in Sections <xref
target="sect-6" format="counter"/>, <xref target="sect-7"
format="counter"/>, and <xref target="sect-8" format="counter"/>.</t>
<section anchor="sect-1.1" numbered="true" toc="default">
<name>Some Recent Known Uses</name>
<t> A potential use case is implementing smart network services that
allow applications to dynamically build end-to-end, virtual networks
to satisfy given demands with no manual intervention. For example,
data-transfer automation applications may need a network service to
determine the availability of bandwidth resources to decide when
to transfer their data sets. The SENSE project <xref
target="SENSE" format="default"/> supports such
applications by requiring that a network provides services such as the
Time-Bandwidth-Product (TBP) service, which informs applications of
bandwidth availability during a specific time period. ALTO Calendars
can support this service if the Calendar start date and duration cover
the period of interest of the requesting application.</t>
<t>The need of future scheduling of large-scale traffic that can be
addressed by the ALTO protocol is also motivated by Unicorn, a unified
resource orchestration framework for multi-domain, geo-distributed
data analytics, see <xref target="UNICORN-FGCS"
format="default"/>.</t>
</section>
<section anchor="sect-1.2" numbered="true" toc="default">
<name>Terminology</name>
<dl newline="true" spacing="normal">
<dt>ALTO transaction:</dt>
<dd>A request/response exchange between an ALTO
Client and an ALTO Server.</dd>
<dt>Client:</dt>
<dd>When used with a capital "C", this term refers to an ALTO
Client.</dd>
<dt>Calendar, Cost Calendar, ALTO Calendar:</dt>
<dd>When used with capitalized words, these terms refer to an ALTO
Cost Calendar.</dd>
<dt>Calendared:</dt>
<dd>This adjective qualifies information resources providing Cost
Calendars and information on costs that are provided in the form of
a Cost Calendar.</dd>
<dt>Endpoint (EP):</dt>
<dd>An endpoint is defined as in <xref target="RFC7285"
sectionFormat="of" section="2.1"/>. It can be, for example, a peer,
a CDN storage location, a physical server involved in a virtual
server-supported application, a party in a resource-sharing swarm
such as a computation grid, or an online multi-party game.</dd>
<dt>ECM:</dt>
<dd>An abbreviation for Endpoint Cost Map.</dd>
<dt>FCM:</dt>
<dd>An abbreviation for Filtered Cost Map.</dd>
<dt>Server:</dt>
<dd>When used with a capital "S", this term refers to an ALTO Server.</
dd>
</dl>
</section>
</section>
<section anchor="sect-2" numbered="true" toc="default">
<name>Requirements Language</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
to be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
<t>When the words appear in lower case, they are to be interpreted with
their natural language meanings.</t>
</section>
<section anchor="sect-3" numbered="true" toc="default">
<name>Overview of ALTO Cost Calendars and Terminology</name>
<t>This section gives a high-level overview of the design. <t>This section gives a high-level overview of the design.
<!--It sets rules to ensure backwards compatibility with legacy ALTO Clien
ts
in <xref target="sect-3.3.2"/> .-->
It assumes the reader is familiar with the ALTO protocol <xref target="RFC
7285"/> and
its Multi-Cost ALTO extension <xref target="RFC8189"/>.
</t>
<section title="ALTO Cost Calendar overview" anchor="sect-3.1"> It assumes the reader is familiar with the ALTO protocol <xref
<t>An ALTO Cost Calendar provided by the ALTO Server provides 2 target="RFC7285" format="default"/> and its Multi-Cost ALTO extension
<xref target="RFC8189" format="default"/>.</t>
<section anchor="sect-3.1" numbered="true" toc="default">
<name>ALTO Cost Calendar Overview</name>
<t>An ALTO Cost Calendar provided by the ALTO Server provides 2
information items:</t> information items:</t>
<ul spacing="normal">
<t> <li>an array of values for a given metric, where each value
<list style="symbols"><t>an array of values for a given metric, specifies the metric corresponding to a time interval, where the
where each value value array can sometimes be a cyclic pattern that repeats a certain
specifies the metric corresponding to a time interval, where the number of times and</li>
value array can <li>attributes describing the time scope of the Calendar, including
sometimes be a cyclic pattern that repeats a certain number of the size and number of the intervals and the date of the starting
times.</t> point of the Calendar, allowing an ALTO Client to interpret the
values properly.</li>
<t>attributes describing the time scope of the Calendar, includ </ul>
ing the <t>An ALTO Cost Calendar can be used like a "time table" to figure out
size and number of the intervals and the date of the starting the best time to schedule data transfers and also to proactively
point of the Calendar, allowing an ALTO Client to interpret the manage application traffic given predictable events, such as an expected
values properly.</t> spike in traffic due to crowd gathering (concerts, sports, etc.),
</list> traffic-intensive holidays, and network maintenance. A Calendar may be
</t> viewed as a synthetic abstraction of, for example, real measurements
gathered over previous periods on which statistics have been computed.
<t> However, like for any schedule, unexpected network incidents may
An ALTO Cost Calendar can be used like a "time table" to figure out require the current ALTO Calendar to be updated and resent to the
the best time to schedule data transfers and also to proactively ALTO Clients needing it. The "ALTO Incremental Updates Using
manage application traffic given predictable events such as expected Server-Sent Events (SSE)" Service <xref target="RFC8895"
spike in traffic due to crowd gathering (concerts, sports, etc.), format="default"/> can be used to directly update the Calendar upon
traffic-intensive holidays and network maintenance. A Calendar may value changes if supported by both the Server and the Client.</t>
be viewed as a synthetic abstraction of, for example, real <t>
measurements gathered over previous periods on which statistics have
been computed. However, like for any schedule, unexpected network
incidents may require the current ALTO Calendar to be updated and re-
sent to the ALTO Clients needing it. The "ALTO Incremental Updates
Using Server-Sent Events (SSE)" Service
<xref target="I-D.ietf-alto-incr-update-sse"/> can be used to
directly update the Calendar upon value changes,
if supported by both the Server and the Client.</t>
<t>
Most likely, the ALTO Cost Calendar would be used for the Endpoint Most likely, the ALTO Cost Calendar would be used for the Endpoint
Cost Service, assuming that a limited set of feasible Endpoints for a Cost Service, assuming that a limited set of feasible endpoints for a
non-real time application is already identified, that they do not non-real time application is already identified, and that those
need to be accessed immediately and that their access can be endpoints do not need to be accessed immediately and that their
scheduled within a given time period. The Filtered Cost Map Service access can be scheduled within a given time period.
is also applicable as long as the size of the Map allows it.</t> The Filtered Cost Map Service is also
applicable as long as the size of the Map allows it.</t>
</section> </section>
<section anchor="sect-3.2" numbered="true" toc="default">
<section title="ALTO Cost Calendar information features" anchor="sect-3.2 <name>ALTO Cost Calendar Information Features</name>
"><t> <t>
The Calendar attributes are provided in the Information Resources The Calendar attributes are provided in the Information Resources
Directory (IRD) and in ALTO Server responses. The IRD announces Directory (IRD) and in ALTO Server responses. The IRD announces
attributes without date values attributes without date values
in its information resources capabilities, whereas attributes with in its information resources capabilities, whereas attributes with
time dependent values are provided in the "meta" section of Server responses. time-dependent values are provided in the "meta" section of Server responses.
The ALTO Cost Calendar attributes provide the following information:</t> The ALTO Cost Calendar attributes provide the following information:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>attributes to describe the time scope of the Calendar value array: <t>attributes to describe the time scope of the Calendar value array
<list style="symbols"> :
<!-- <t>The time is always expressed in UTC, </t> -->
<t>"time-interval-size": the applicable time interval size
for each Calendar value, defined in seconds, that can cover a wi
de range of values.
</t>
<t>"number-of-intervals": the number of intervals
provided in the Calendar.
</t> </t>
</list> <ul spacing="normal">
</t>
<t>"calendar-start-time": specifying when the Calendar starts, that
is to which date the first value of the Cost Calendar is
applicable.</t>
<t>"repeated": an optional attribute indicating how many iterations
of the provided Calendar will have the same values. The Server
may use it to allow the Client to schedule its next request and
thus save its own workload by reducing processing of similar
requests.</t>
</list>
</t>
<t>
Attribute "repeated" may take a very high value if a Calendar
represents a cyclic value pattern that the Server considers valid for
a long period. In this case, the Server will only update the
Calendar values once this period has elapsed or if an unexpected
event occurs on the network. See <xref target="sect-8"/> for more
discussion.</t>
</section>
<section title="ALTO Calendar design characteristics" anchor="sect-3.3">
<t>The present document uses the notations defined in Section "8.2 Notati
on" of
<xref target="RFC7285"/>.</t>
<t>The extensions in this document encode requests and responses
using JSON <xref target="RFC8259"/>.</t>
<t>
In the base protocol <xref target="RFC7285"/> section 11.2.3.6, an ALTO cost
is
specified as a generic JSONValue <xref target="RFC8259"/>, to allow extension
s.
However, that section 11.2.3.6 states: "An implementation of
the protocol in this document (<xref target="RFC7285"/>) SHOULD assume that
the cost is a JSONNumber and fail to parse if it is not, unless the implement
ation
is using an extension to this document that indicates when and how costs of o
ther
data types are signaled". </t>
<t>
The present document extends the
definition of a legacy cost map given in <xref target="RFC7285"/> to allow a
cost
entry to be an array of values, with one value per time interval, instead of
being just one number, when the Cost Calendar functionality is activated on t
his cost.
Therefore the implementor of this extension MUST consider that a cost entry i
s an array of values
if this cost has been queried as a Calendar. </t>
<t> Specifically, an implementation of this extension MUST parse the
"number-of-intervals" attribute of the Calendar attributes
in an IRD entry announcing a service providing a Cost Calendar for a given
cost type.
The implementation then will know that a cost entry of the
service will be an array of values, and the expected size of
the array is that specified by the "number-of-intervals" attribute.
The following rules attempt to ensure consistency between the array size anno
unced by the Server and the
actual size of the array received by the Client:
<list style="symbols">
<t>The size of the array of values conveyed in a Cost Calendar and received b
y the Client MUST
be equal to the value of attribute "number-of-intervals" indicated in the IRD
for the
requested cost type.</t>
<t>When the size of the array received by the Client is different from the ex
pected size,
the Client SHOULD ignore the received array.</t>
</list>
</t>
<t>
To realize an ALTO Calendar, this document extends the IRD and the ALTO
requests and responses for Cost Calendars.</t>
<t>
This extension is designed to be lightweight and to ensure backwards
compatibility with base protocol ALTO Clients and with other
extensions. It relies on section 8.3.7 "Parsing of Unknown Fields"
of <xref target="RFC7285"/> that writes: "Extensions may include additional f
ields within JSON objects defined in this document. ALTO implementations MUST i
gnore unknown fields when processing ALTO messages."</t>
<t>
The Calendar-specific capabilities are integrated in the information
resources of the IRD and in the "meta" member of ALTO responses to
Cost Calendars requests. A Calendar and its capabilities are
associated with a given information resource and within this
information resource, with a given cost type. This design has several
advantages:</t>
<t><list style="symbols"><t>it does not introduce a new mode,</t>
<t>it does not introduce new media types,</t>
<t>it allows an ALTO Server to offer, for a cost type, different Calendar
s
with attributes that are specific to the information resources providing
a Calendar for this cost type, instead of being globally specific to the
cost type.
</t>
</list>
</t>
<t>
The applicable Calendared information resources are:</t>
<t><list style="symbols"><t>the Filtered Cost Map,</t>
<t>the Endpoint Cost Map.</t>
</list>
</t>
<t>
The ALTO Server can choose in which frequency it provides cost
Calendars to ALTO Clients. It may either provide Calendar updates
starting at the request date, or carefully schedule its updates so as
to take profit from a potential repetition/periodicity of Calendar
values.</t>
<t>Since Calendar attributes are specific to an information resource, a Serve
r may adapt
the granularity of the calendared information so as to moderate the volume of
exchanged data.
For example: suppose a Server provides a Calendar for cost type name "routing
cost".
The Server may offer a Calendar in a Cost Map resource, which may be a volumi
nous resource,
as an array of 6 intervals lasting each 4 hours. It may also offer a Calendar
in an Endpoint Cost Map resource,
which is potentially less voluminous, as a finer-grained array of 24 interval
s lasting 1 hour each.
</t>
<t>The ALTO Server does not support constraints on Calendars,
provided Calendars are requested for numerical values, for two main reasons:
<list style="symbols">
<t>constraints on an array of values may be various: for instance, some Clien
ts may
refuse Calendars with one single value violating a constraint, where as
other ones may tolerate Calendars with values violating constraints for examp
le
at given times. Therefore, expressing constraints in a way that covers all po
ssible
Client preferences is challenging, </t>
<t>if constraints were to be supported, the processing overhead would be subs
tantial
for the Server as it would have to parse alle the values of the Calendar arra
y before
returning a response. </t>
</list>
</t>
<t>As providing the constraint functionality in conjunction
with the Calendar functionality is not feasible for the reasons described abo
ve,
the two features are mutually exclusive. The absence of constraints on
Filtered Cost Map and Endpoint Cost Map Calendars
reflects a divergence from the non-calendared information resources defined i
n
<xref target="RFC7285"/> and extended in <xref target="RFC8189"/>,
that support optional constraints. </t>
<section title="ALTO Cost Calendar for all cost modes" anchor="sect-3.3.1
"><t>
An ALTO Cost Calendar is well-suited for values encoded in the
"numerical" mode. Actually, a Calendar can also represent metrics in
other modes considered as compatible with time-varying values. For
example, types of Cost values such as JSONBool can also be
calendared, as their value may be 'true' or 'false' depending on
given time periods or likewise, values represented by strings, such
as "medium", "high", "low", "blue", "open".</t>
<t>
Note also that a Calendar is suitable as well for time-varying
metrics provided in the "ordinal" mode, if these values are time-
varying and the ALTO Server provides updates of cost value based
preferences.</t>
</section>
<section title="Compatibility with legacy ALTO Clients" anchor="sect-3.3.
2"><t>
The ALTO protocol extensions for Cost Calendars have been defined so
as to ensure that Calendar-capable ALTO Servers can provide legacy
ALTO Clients with legacy information resources as well. That is, a
legacy ALTO Client can request resources and receive responses as
specified in <xref target="RFC7285"/>.</t>
<t>
A Calendar-aware ALTO Server MUST implement the base protocol
specified in <xref target="RFC7285"/>.</t>
<t>
A Calendar-aware ALTO Client MUST implement the base protocol
specified in <xref target="RFC7285"/>.</t>
<t>
As a consequence, when a metric is available as a Calendar array, it
also MUST be available as a single value as required by <xref target="RFC7285
"/>.
The Server, in this case, provides the current value of the metric to
either Calendar-aware Clients not interested in future or time-based
values, or Clients implementing <xref target="RFC7285"/> only.</t>
<t>
For compatibility with legacy ALTO Clients specified in <xref target="RFC7285
"/>,
calendared information resources are not applicable for full cost
maps for the following reason: a legacy ALTO Client would receive a
calendared cost map via an HTTP 'GET' command. As specified in
section 8.3.7 of <xref target="RFC7285"/>, it will ignore the Calendar Attrib
utes
indicated in the "meta" of the responses. Therefore, lacking
information on Calendar attributes, it will not be able to correctly
interpret and process the values of the received array of Calendar
cost values.</t>
<t>
Therefore, calendared information resources MUST be requested via the
Filtered Cost Map Service or the Endpoint Cost Service, using a POST
method.</t>
</section>
</section>
</section>
<section title="ALTO Calendar specification: IRD extensions" anchor="sect
-4"><t>
The Calendar attributes in the IRD information resources capabilities
carry dateless values. A Calendar is associated with an
information resource rather than a cost type. For example, a Server
can provide a "routingcost" Calendar for the Filtered Cost Map
Service at a granularity of one day and a "routingcost" Calendar for
the Endpoint Cost Service at a finer granularity but for a limited
number of endpoints. An example IRD with Calendar specific features
is provided in <xref target="sect-4.3"/>.</t>
<section title="Calendar attributes in the IRD resource capabilities" anc
hor="sect-4.1"><t>
A Cost Calendar for a given cost type MUST be indicated in the IRD by
an object of type CalendarAttributes. A CalendarAttributes object is
represented by the "calendar-attributes" member of a resource entry.
Member "calendar-attributes" is an array of CalendarAttributes objects.
Each CalendarAttributes object lists a set of one or more cost
types it applies to. A cost type name MUST NOT appear more than once in the
"calendar-attributes" member of a resource entry; multiple
appearances of a cost type name in the CalendarAttributes object of the
"calendar-attributes" member MUST cause the ALTO Client to ignore any
occurrences of this name beyond the first encountered occurrence.
The Client SHOULD consider the CalendarAttributes object in the array
containing the first encountered occurrence of a cost type as the
valid one for this cost type. As an alternative, the Client may want to avoid
the risks of erroneous guidance associated to the use
of potentially invalid Calendar values. In this case, the Client MAY ignore
the totality of occurences of CalendarAttributes objects containing the cost
type name
and query the cost type using <xref target="RFC7285"/>. </t>
<t>
The encoding format for object CalendarAttributes, using JSON
<xref target="RFC8259"/>, is as follows:</t>
<t> <li>"time-interval-size": the applicable time interval size for
CalendarAttributes calendar-attributes &lt;1..*&gt;;</t> each Calendar value, defined in seconds, that can cover a wide
range of values.</li>
<li>"number-of-intervals": the number of intervals provided in
the Calendar.</li>
</ul>
</li>
<li>"calendar-start-time": specifying when the Calendar starts; that
is, to which date the first value of the Cost Calendar is
applicable.</li>
<li>"repeated": an optional attribute indicating how many iterations
of the provided Calendar will have the same values. The Server may
use it to allow the Client to schedule its next request and thus
save its own workload by reducing processing of similar
requests.</li>
</ul>
<t>Attribute "repeated" may take a very high value if a Calendar
represents a cyclic value pattern that the Server considers valid for
a long period. In this case, the Server will only update the Calendar
values once this period has elapsed or if an unexpected event occurs
on the network. See <xref target="sect-8" format="default"/> for more
discussion.</t>
</section>
<section anchor="sect-3.3" numbered="true" toc="default">
<name>ALTO Calendar Design Characteristics</name>
<t>The present document uses the notations defined in "Notation"
(<xref target="RFC7285" sectionFormat="of" section="8.2"/>).</t>
<t>The extensions in this document encode requests and responses using
JSON <xref target="RFC8259" format="default"/>.</t>
<figure><artwork><![CDATA[ <t>In the base protocol <xref target="RFC7285"/>, an ALTO cost is
specified as a generic JSONValue <xref target="RFC8259"
format="default"/> to allow extensions. However, that section (<xref
target="RFC7285" sectionFormat="of" section="11.2.3.6"/>) states:</t>
<blockquote>An implementation of the protocol in
this document
<bcp14>SHOULD</bcp14> assume that the cost is a JSONNumber and fail to
parse if it is not, unless the implementation is using an extension to
this document that indicates when and how costs of other data types
are signaled.</blockquote>
<t>The present document extends the definition of a legacy cost map
given in <xref target="RFC7285" format="default"/> to allow a cost
entry to be an array of values, with one value per time interval,
instead of being just one number, when the Cost Calendar functionality
is activated on this cost. Therefore, the implementor of this extension
<bcp14>MUST</bcp14> consider that a cost entry is an array of values
if this cost has been queried as a Calendar. </t>
<t> Specifically, an implementation of this extension
<bcp14>MUST</bcp14> parse the "number-of-intervals" attribute of the
Calendar attributes in an IRD entry announcing a service providing a
Cost Calendar for a given cost type. The implementation then will know
that a cost entry of the service will be an array of values, and the
expected size of the array is that specified by the
"number-of-intervals" attribute. The following rules attempt to ensure
consistency between the array size announced by the Server and the
actual size of the array received by the Client:</t>
<ul spacing="normal">
<li>The size of the array of values conveyed in a Cost Calendar and
received by the Client <bcp14>MUST</bcp14> be equal to the value of
attribute "number-of-intervals" indicated in the IRD for the
requested cost type.</li>
<li>When the size of the array received by the Client is different
from the expected size, the Client <bcp14>SHOULD</bcp14> ignore the
received array.</li>
</ul>
<t>To realize an ALTO Calendar, this document extends the IRD and the
ALTO requests and responses for Cost Calendars.</t>
<t>This extension is designed to be lightweight and to ensure
backwards compatibility with base protocol ALTO Clients and with other
extensions. It relies on "Parsing of Unknown Fields" (<xref
target="RFC7285" sectionFormat="of" section="8.3.7"/>), which states:
"Extensions may include additional fields within JSON objects defined
in this document. ALTO implementations <bcp14>MUST</bcp14> ignore
unknown fields when processing ALTO messages."</t>
<t>The Calendar-specific capabilities are integrated in the
information resources of the IRD and in the "meta" member of ALTO
responses to Cost Calendars requests. A Calendar and its capabilities
are associated with a given information resource and within this
information resource with a given cost type. This design has several
advantages:</t>
<ul spacing="normal">
<li>it does not introduce a new mode,</li>
<li>it does not introduce new media types, and</li>
<li>it allows an ALTO Server to offer, for a cost type, different
Calendars with attributes that are specific to the information
resources providing a Calendar for this cost type, instead of being
globally specific to the cost type.</li>
</ul>
<t>The applicable Calendared information resources are:</t>
<ul spacing="normal">
<li>the Filtered Cost Map and</li>
<li>the Endpoint Cost Map.</li>
</ul>
<t>The ALTO Server can choose in which frequency it provides cost
Calendars to ALTO Clients. It may either provide Calendar updates
starting at the request date or carefully schedule its updates so as
to take profit from a potential repetition/periodicity of Calendar
values.</t>
<t>Since Calendar attributes are specific to an information resource,
a Server may adapt the granularity of the calendared information so as
to moderate the volume of exchanged data. For example, suppose a
Server provides a Calendar for cost type name "routingcost". The
Server may offer a Calendar in a Cost Map resource, which may be a
voluminous resource, as an array of 6 intervals lasting each 4
hours. It may also offer a Calendar in an Endpoint Cost Map resource,
which is potentially less voluminous, as a finer-grained array of 24
intervals lasting 1 hour each.</t>
<t>The ALTO Server does not support constraints on Calendars, provided
Calendars are requested for numerical values, for two main
reasons:</t>
<ul spacing="normal">
<li>Constraints on an array of values may be various. For instance,
some Clients may refuse Calendars with one single value violating a
constraint, whereas other ones may tolerate Calendars with values
violating constraints, for example, at given times. Therefore,
expressing constraints in a way that covers all possible Client
preferences is challenging.</li>
<li>If constraints were to be supported, the processing overhead
would be substantial for the Server as it would have to parse all
the values of the Calendar array before returning a response. </li>
</ul>
<t>As providing the constraint functionality in conjunction with the
Calendar functionality is not feasible for the reasons described
above, the two features are mutually exclusive. The absence of
constraints on Filtered Cost Map and Endpoint Cost Map Calendars
reflects a divergence from the non-calendared information resources
defined in <xref target="RFC7285" format="default"/> and extended in
<xref target="RFC8189" format="default"/>, which support optional
constraints. </t>
<section anchor="sect-3.3.1" numbered="true" toc="default">
<name>ALTO Cost Calendar for All Cost Modes</name>
<t>An ALTO Cost Calendar is well suited for values encoded in the
"numerical" mode. Actually, a Calendar can also represent metrics
in other modes considered as compatible with time-varying
values. For example, types of cost values (such as JSONBool) can also
be calendared (as their value may be 'true' or 'false' depending on
given time periods or likewise) values represented by strings, such
as "medium", "high", "low", "blue", and "open".</t>
<t>Note also that a Calendar is suitable as well for time-varying
metrics provided in the "ordinal" mode if these values are
time-varying and the ALTO Server provides updates of
cost-value-based preferences.</t>
</section>
<section anchor="sect-3.3.2" numbered="true" toc="default">
<name>Compatibility with Legacy ALTO Clients</name>
<t>The ALTO protocol extensions for Cost Calendars have been defined
so as to ensure that Calendar-capable ALTO Servers can provide
legacy ALTO Clients with legacy information resources as well. That
is, a legacy ALTO Client can request resources and receive responses
as specified in <xref target="RFC7285" format="default"/>.</t>
<t>A Calendar-aware ALTO Server <bcp14>MUST</bcp14> implement the
base protocol specified in <xref target="RFC7285"
format="default"/>.</t>
<t>A Calendar-aware ALTO Client <bcp14>MUST</bcp14> implement the
base protocol specified in <xref target="RFC7285"
format="default"/>.</t>
<t>As a consequence, when a metric is available as a Calendar array,
it also <bcp14>MUST</bcp14> be available as a single value, as
required by <xref target="RFC7285" format="default"/>. The Server,
in this case, provides the current value of the metric to either
Calendar-aware Clients not interested in future or time-based values
or Clients implementing <xref target="RFC7285" format="default"/>
only.</t>
<t>For compatibility with legacy ALTO Clients specified in <xref
target="RFC7285" format="default"/>, calendared information
resources are not applicable for full cost maps for the following
reason: a legacy ALTO Client would receive a calendared cost map via
an HTTP 'GET' command. As specified in <xref target="RFC7285"
sectionFormat="of" section="8.3.7"/>, it will ignore the Calendar
attributes indicated in the "meta" of the responses. Therefore,
lacking information on Calendar attributes, it will not be able to
correctly interpret and process the values of the received array of
Calendar cost values.</t>
<t>Therefore, calendared information resources <bcp14>MUST</bcp14>
be requested via the Filtered Cost Map Service or the Endpoint Cost
Service using a POST method.</t>
</section>
</section>
</section>
<section anchor="sect-4" numbered="true" toc="default">
<name>ALTO Calendar Specification: IRD Extensions</name>
<t>The Calendar attributes in the IRD information resources capabilities
carry dateless values. A Calendar is associated with an information
resource rather than a cost type. For example, a Server can provide a
"routingcost" Calendar for the Filtered Cost Map Service at a
granularity of one day and a "routingcost" Calendar for the Endpoint
Cost Service at a finer granularity but for a limited number of
endpoints. An example IRD with Calendar-specific features is provided
in <xref target="sect-4.3" format="default"/>.</t>
<section anchor="sect-4.1" numbered="true" toc="default">
<name>Calendar Attributes in the IRD Resource Capabilities</name>
<t>A Cost Calendar for a given cost type <bcp14>MUST</bcp14> be
indicated in the IRD by an object of type CalendarAttributes. A
CalendarAttributes object is represented by the "calendar-attributes"
member of a resource entry. Member "calendar-attributes" is an array
of CalendarAttributes objects. Each CalendarAttributes object lists a
set of one or more cost types it applies to. A cost type name
<bcp14>MUST NOT</bcp14> appear more than once in the
"calendar-attributes" member of a resource entry; multiple appearances
of a cost type name in the CalendarAttributes object of the
"calendar-attributes" member <bcp14>MUST</bcp14> cause the ALTO Client
to ignore any occurrences of this name beyond the first encountered
occurrence. The Client <bcp14>SHOULD</bcp14> consider the
CalendarAttributes object in the array containing the first
encountered occurrence of a cost type as the valid one for this cost
type. As an alternative, the Client may want to avoid the risks of
erroneous guidance associated to the use of potentially invalid
Calendar values. In this case, the Client <bcp14>MAY</bcp14> ignore
the totality of occurrences of CalendarAttributes objects containing
the cost type name and query the cost type using <xref
target="RFC7285" format="default"/>.</t>
<t>The encoding format for object CalendarAttributes using JSON <xref
target="RFC8259" format="default"/> is as follows:</t>
<t>CalendarAttributes calendar-attributes &lt;1..*&gt;;</t>
<sourcecode><![CDATA[
object{ object{
JSONString cost-type-names <1..*>; JSONString cost-type-names <1..*>;
JSONNumber time-interval-size; JSONNumber time-interval-size;
JSONNumber number-of-intervals; JSONNumber number-of-intervals;
} CalendarAttributes; } CalendarAttributes;
]]></artwork> ]]></sourcecode>
</figure> <dl newline="true" spacing="normal">
<t><list style="symbols"><t>"cost-type-names": <dt>"cost-type-names":</dt>
<list style="symbols"><t>An array of one or more elements indicating the <dd>An array of one or more elements indicating the cost type
cost type names names in the IRD entry to which the values of "time-interval-size"
in the IRD entry to which the values of "time-interval-size" and and "number-of-intervals" apply.</dd>
"number-of-intervals" apply.</t> <dt>"time-interval-size":</dt>
</list> <dd>The duration of an ALTO Calendar time interval in a unit of
</t> seconds. A "time-interval-size" value contains a non-negative
JSONNumber. Example values are 300 and 7200, meaning that each
<t>"time-interval-size":<list style="symbols"><t>is the duration of an Calendar value applies on a time interval that lasts 5 minutes and
ALTO Calendar time interval in a unit of seconds. A "time-interval-size 2 hours, respectively. Since an interval size (e.g., 100 ms) can
" value be smaller than the unit, the value specified may be a floating
contains a non-negative JSONNumber. Example values are: 300 and point (e.g., 0.1). Both ALTO Clients and Servers should be aware
7200, meaning that each Calendar value applies on a time of potential precision issues caused by using floating point
interval that lasts 5 minutes and 2 hours, respectively. Since an numbers; for example, the floating number 0.1 cannot be
interval size (e.g., 100 ms) can be smaller than the unit, the value represented precisely using a finite number of binary bits. To
specified may be a floating point (e.g., 0.1). Both ALTO Clients and improve interoperability and be consistent with <xref
Servers should be aware of potential precision issues caused by using target="RFC7285" format="default"/> on the
floating point numbers; for example, use of floating point numbers, the Server and the Client
the floating number 0.1 cannot be represented precisely using a finite <bcp14>SHOULD</bcp14> use IEEE 754 double-precision floating point
number of binary bits. To improve interoperability and be consistent wi <xref target="IEEE.754.2019" format="default"/> to store this
th value.</dd>
[RFC7285] on the use of floating point numbers, the Server and the Clie
nt
SHOULD use IEEE 754
double-precision floating point <xref target="IEEE.754.2008"/> to store
this value.
</t>
<!--
, if the client and the server use different storage, they may encounte
r
interop issues (see Sectio)
the server may have an internal, integer representation in ms, and stor
e
100 as an int (0.1 sec) in the local storage; the sever sends "0.1" as
the interval size to the client; the client may use a float/double to s
tore
the JSON number, which may not represent 0.1 precisely. To improve
interoperability, the server and the client SHOULD use IEEE 754
double-precision floating point <xref target="IEEE.754.2008"/> to store
this value, in unit of seconds.</t>
-->
</list>
</t>
<t>"number-of-intervals":<list style="symbols">
<t>is a strictly positive integer (greater or equal to 1), that indicates
the number of values of the Cost Calendar array.</t>
</list>
</t>
</list>
</t>
<t> <dt>"number-of-intervals":</dt>
- An ALTO Server SHOULD specify the "time-interval-size" in the IRD <dd>A strictly positive integer (greater or equal to 1) that
indicates the number of values of the Cost Calendar array.</dd>
</dl>
<ul spacing="normal">
<li>An ALTO Server <bcp14>SHOULD</bcp14> specify the "time-interval-siz
e" in the IRD
as the smallest it is able to provide. A Client that needs as the smallest it is able to provide. A Client that needs
a longer interval can aggregate multiple cost values to obtain it.</t> a longer interval can aggregate multiple cost values to obtain it.</li>
<t> <li>Attribute "cost-type-names" is associated with
- Attribute "cost-type-names" is associated with "time-interval-size" and "time-interval-size" and "number-of-intervals", because multiple cost
"number-of-intervals", because multiple cost types may share the same types may share the same values for attributes "time-interval-size"
values for attributes "time-interval-size" and "number-of-intervals". and "number-of-intervals". To avoid redundancies, cost type names
To avoid redundancies, cost type names sharing the same values for "time-inte sharing the same values for "time-interval-size" and
rval-size" "number-of-intervals" are grouped in the "cost-type-names"
and "number-of-intervals" are grouped in the "cost-type-names" attribute. attribute. In the example IRD provided in <xref target="sect-4.3"
In the example IRD provided in <xref target="sect-4.3"/>, the information res format="default"/>, the information resource
ource "filtered-cost-map-calendar" provides a Calendar for cost type names
“filtered-cost-map-calendar” provides a Calendar for cost type names "num-routingcost", "num-throughputrating", and
"num-routingcost", "num-throughputrating" and "string-servicestatus". "string-servicestatus". Cost type names "num-routingcost" and
Cost type names "num-routingcost" and "num-throughputrating" are "num-throughputrating" are grouped in the "cost-type-names" attribute
grouped in the "cost-type-names" attribute because they share the because they share the same values for "time-interval-size" and
same values for "time-interval-size" and "number-of-intervals", "number-of-intervals", which are respectively 7200 and 12.</li>
which are respectively 7200 and 12. <li>Multiplying "time-interval-size" by "number-of-intervals" provides
</t> the duration of the provided Calendar. For example, an ALTO Server
may provide a Calendar for ALTO values changing every
<t> "time-interval-size" equal to 5 minutes. If "number-of-intervals" has
- Multiplying "time-interval-size" by "number-of-intervals" provides the value 12, then the duration of the provided Calendar is 1
the duration of the provided Calendar. For example, an ALTO Server hour.</li>
may provide a Calendar for ALTO values changing every "time-interval- </ul>
size" equal to 5 minutes. If "number-of-intervals" has the value 12, </section>
then the duration of the provided Calendar is 1 hour.</t> <section anchor="sect-4.2" numbered="true" toc="default">
<name>Calendars in a Delegate IRD</name>
</section> <t>It may be useful to distinguish IRD resources supported by the base
ALTO protocol from resources supported by its extensions. To achieve
<section title="Calendars in a delegate IRD" anchor="sect-4.2"><t> this, one option is that a "root" ALTO Server implementing <xref
It may be useful to distinguish IRD resources supported by the base target="RFC7285" format="default"/> resources and running at a given
ALTO protocol from resources supported by its extensions. To achieve domain delegates "specialized" information resources, such as the ones
this, one option, is that a "root" ALTO Server implementing providing Cost Calendars, to another ALTO Server running in a
<xref target="RFC7285"/> resources and running at a given domain, delegates " subdomain. The "root" ALTO Server can provide a Calendar-specific
specialized" resource entry that has a media-type of
information resources such as the ones providing Cost Calendars, "application/alto-directory+json" and that specifies the URI allowing
to another ALTO Server running in a subdomain. The "root" ALTO Server to retrieve the location of a Calendar-aware Server and discover its
can provide a Calendar-specific resource entry, that has a media-type resources. This option is described in "Delegation Using IRD" (<xref
of "application/alto-directory+json" and that specifies the target="RFC7285" sectionFormat="of" section="9.2.4"/>).</t>
URI allowing to retrieve the location of a Calendar-aware Server and <t>This document provides an example where a "root" ALTO Server runs
discover its resources. in a domain called "alto.example.com". It delegates the announcement
of Calendars capabilities to an ALTO Server running in a subdomain
This option is described in Section 9.2.4 "Delegation using IRDs" called "custom.alto.example.com". The location of the "delegate
of <xref target="RFC7285"/>.</t> Calendar IRD" is assumed to be indicated in the "root" IRD by the
resource entry: "custom-calendared-resources".</t>
<t> <t>
This document provides an example, where a "root" ALTO Server runs in
a domain called "alto.example.com". It delegates the announcement of
Calendars capabilities to an ALTO Server running in a subdomain
called "custom.alto.example.com". The location of the "delegate Calendar IRD
" is
assumed to be indicated in the "root" IRD by the
resource entry: "custom-calendared-resources".</t>
<t>
Another benefit of delegation is that some cost types for some resources Another benefit of delegation is that some cost types for some resources
may be more advantageous as Cost Calendars and it makes little sense to g et them may be more advantageous as Cost Calendars, and it makes little sense to get them
as a single value. For example, if a cost type has predictable and freque ntly as a single value. For example, if a cost type has predictable and freque ntly
changing values, calendared in short time intervals such as a minute, changing values calendared in short time intervals, such as a minute,
it saves time and network resources to track the cost values via a focuse d it saves time and network resources to track the cost values via a focuse d
delegate Server rather than the more general "root" Server.</t> delegate Server rather than the more general "root" Server.</t>
</section>
</section> <section anchor="sect-4.3" numbered="true" toc="default">
<name>Example IRD with ALTO Cost Calendars</name>
<section title="Example IRD with ALTO Cost Calendars" anchor="sect-4.3">< <t>This section provides an example ALTO Server IRD that supports
t> various cost metrics and cost modes. In particular, since <xref
This section provides an example ALTO Server IRD that supports target="RFC7285" format="default"/> makes it mandatory, the Server
various cost metrics and cost modes. In particular, since <xref target="RFC7 uses metric "routingcost" in the "numerical" mode.</t>
285"/> <t>For illustrative purposes, this section introduces 3 other
makes it mandatory, the Server uses metric "routingcost" in the fictitious example metrics and modes that should be understood as
"numerical" mode.</t> examples and should not be used or considered as normative.</t>
<t>The cost type names used in the example IRD are as follows:</t>
<t> <dl newline="true" spacing="normal">
For illustrative purposes, this section introduces 3 other fictitious <dt>"num-routingcost":</dt>
example metrics and modes that should be understood as examples and <dd>Refers to metric "routingcost" in the
should not be used or considered as normative.</t> numerical mode, as defined in <xref target="RFC7285"
format="default"/> and registered with IANA.</dd>
<t> <dt>"num-owdelay":</dt>
The cost type names used in the example IRD are as follows:</t> <dd>Refers to fictitious performance metric "owdelay"
in the "numerical" mode to reflect the one-way packet transmission
<t><list style="symbols"><t>"num-routingcost": refers to metric "routingc delay on a path. A related performance metric is currently under
ost" in the numerical definition in <xref target="I-D.ietf-alto-performance-metrics"
mode as defined in <xref target="RFC7285"/> and registered with IANA.</t> format="default"/>.</dd>
<dt>"num-throughputrating":</dt>
<t>"num-owdelay": refers to fictitious performance metric "owdelay" <dd>Refers to fictitious metric
in the "numerical" mode, to reflect the one-way packet transmission "throughputrating" in the "numerical" mode to reflect the provider
delay on a path. A related performance metric is currently under preference in terms of end-to-end throughput.</dd>
definition in <xref target="I-D.ietf-alto-performance-metrics"/>.</t> <dt>"string-servicestatus":</dt>
<dd>Refers to fictitious metric
<t>"num-throughputrating": refers to fictitious metric "servicestatus" containing a string to reflect the availability,
"throughputrating" in the "numerical" mode, to reflect the defined by the provider, of, for instance, path connectivity.</dd>
provider preference in terms of end to end throughput.</t> </dl>
<t>The example IRD includes 2 particular URIs providing Calendars:</t>
<t>"string-servicestatus": refers to fictitious metric <dl newline="true" spacing="normal">
"servicestatus" containing a string, to reflect the availability, <dt>"https://custom.alto.example.com/calendar/costmap/filtered":</dt>
defined by the provider, of for instance path connectivity.</t> <dd>A Filtered Cost Map in which Calendar capabilities are indicated
for cost type names "num-routingcost", "num-throughputrating", and
</list> "string-servicestatus" and</dd>
</t> <dt>"https://custom.alto.example.com/calendar/endpointcost/lookup":</d
t>
<t> <dd>An Endpoint Cost Map in which Calendar capabilities are indicated
The example IRD includes 2 particular URIs providing Calendars:</t> for cost type names "num-routingcost", "num-owdelay",
"num-throughputrating", and "string-servicestatus".</dd>
<t><list style="symbols"><t>"https://custom.alto.example.com/calendar/cos </dl>
tmap/filtered": a <t>The design of the Calendar capabilities allows some Calendars with
Filtered Cost Map in which Calendar capabilities are indicated for the same cost type name to be available in several information
cost type names: "num-routingcost", "num-throughputrating" and resources with different Calendar attributes. This is the case for
"string-servicestatus",</t> Calendars on "num-routingcost", "num-throughputrating", and
"string-servicestatus", available in both the Filtered Cost Map and
<t>"https://custom.alto.example.com/calendar/endpointcost/lookup": an Endpoint Cost Service but with different time interval sizes for
Endpoint Cost Map in which Calendar capabilities are indicated for "num-throughputrating" and "string-servicestatus".</t>
cost type names: "num-routingcost", "num-owdelay", "num-throughputrating", <sourcecode><![CDATA[
"string-servicestatus".</t>
</list>
</t>
<t>
The design of the Calendar capabilities allows some Calendars with
the same cost type name to be available in several information
resources with different Calendar Attributes. This is the case for
Calendars on "num-routingcost", "num-throughputrating" and "string-servicesta
tus", available in both the Filtered Cost map and Endpoint
Cost Service, but with different time interval sizes for "num-throughputratin
g" and "string-servicestatus".</t>
<figure><artwork><![CDATA[
--- Client to Server request for IRD ---------- --- Client to Server request for IRD ----------
GET /calendars-directory HTTP/1.1 GET /calendars-directory HTTP/1.1
Host: custom.alto.example.com Host: custom.alto.example.com
Accept: application/alto-directory+json,application/alto-error+json Accept: application/alto-directory+json,application/alto-error+json
--- Server response to Client ----------------- --- Server response to Client -----------------
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Length: 2622 Content-Length: 2622
skipping to change at line 823 skipping to change at line 726
}, },
{"cost-type-names" : [ "string-servicestatus" ], {"cost-type-names" : [ "string-servicestatus" ],
"time-interval-size" : 120, "time-interval-size" : 120,
"number-of-intervals" : 30 "number-of-intervals" : 30
} }
] ]
} }
} }
} }
} }
]]></sourcecode>
<t>In this example IRD, for the Filtered Cost Map Service:</t>
<ul spacing="normal">
<li>the Calendar for "num-routingcost" and "num-throughputrating" is
an array of 12 values, each provided on a time interval lasting 7200
seconds (2 hours) and</li>
<li>the Calendar for "string-servicestatus" is an array of 48
values, each provided on a time interval lasting 1800 seconds (30
minutes).</li>
</ul>
<t>For the Endpoint Cost Service:</t>
<ul spacing="normal">
<li>the Calendar for "num-routingcost" is an array of 24 values, each
provided on a time interval lasting 3600 seconds (1 hour),</li>
<li>the Calendar for "num-owdelay" is an array of 12 values, each
provided on a time interval lasting 300 seconds (5 minutes),</li>
<li>the Calendar for "num-throughputrating" is an array of 60
values, each provided on a time interval lasting 60 seconds (1
minute), and</li>
<li>the Calendar for "string-servicestatus" is an array of 30
values, each provided on a time interval lasting 120 seconds (2
minutes).</li>
</ul>
<t>Note that in this example IRD, member "cost-constraints" is present
with a value set to "true" in both information resources
"filtered-cost-map-calendar" and
"endpoint-cost-map-calendar". Although a Calendar-aware ALTO Server
does not support constraints for the reasons explained in
<xref target="sect-3.3" format="default"/>, it <bcp14>MUST</bcp14>
support constraints on cost types that are not requested as Calendars
but are requested as specified in <xref target="RFC7285"
format="default"/> and <xref target="RFC8189" format="default"/>.</t>
</section>
</section>
<section anchor="sect-5" numbered="true" toc="default">
<name>ALTO Calendar Specification: Service Information Resources</name>
<t>This section documents extensions to two basic ALTO information
resources (Filtered Cost Maps and Endpoint Cost Service) to provide
calendared information services for them.</t>
In this example IRD, for the Filtered Cost Map Service: <t>Both extensions return calendar start time (calendar-start-time, a
]]></artwork> point in time), which <bcp14>MUST</bcp14> be specified as an HTTP
</figure> "Date" header field using the IMF-fixdate format specified in
<t><list style="symbols"><t>the Calendar for "num-routingcost" and "num-t <xref target="RFC7231" sectionFormat="of" section="7.1.1.1"/>. Note that
hroughputrating" is the
an array of 12 values each provided on a time interval lasting IMF-fixdate format uses "GMT", not "UTC", to designate the time zone,
7200 seconds (2 hours).</t> as in this example:</t>
<sourcecode><![CDATA[
<t>the Calendar for "string-servicestatus": "is an array of 48 values eac Date: Tue, 15 Nov 2019 08:12:31 GMT
h provided on a time interval lasting 1800 seconds (30 minutes).</t> ]]></sourcecode>
</list>
</t>
<t>
For the Endpoint Cost Service:</t>
<t><list style="symbols"><t>the Calendar for "num-routingcost": is an arr
ay of 24 values each
provided on a time interval lasting 3600 seconds (1 hour).</t>
<t>the Calendar for "num-owdelay": is an array of 12 values each provided
on a time interval lasting 300 seconds (5 minutes).</t>
<t>the Calendar for "num-throughputrating": is an array of 60 values
each provided on a time interval lasting 60 seconds (1 minute).</t>
<t>the Calendar for "string-servicestatus": "is an array of 30 values eac
h provided on a time interval lasting 120 seconds (2 minutes).</t>
</list>
</t>
<t>Note that in this example IRD, member "cost-constraints" is present with
a value set to "true" in
both information resources "filtered-cost-map-calendar" and "endpoint-cost-
map-calendar".
Although a Calendar-aware ALTO Server does not support constraints
for the reasons explained in section <xref target="sect-3.3"/>, it MUST sup
port constraints on
cost types that are not requested as Calendars but are requested as specifi
ed in <xref target="RFC7285"/> and
<xref target="RFC8189"/>.</t>
</section>
</section>
<section title="ALTO Calendar specification: Service Information Resource
s" anchor="sect-5"><t>
This section documents extensions to two basic ALTO information resources (Fi
ltered Cost
Maps and Endpoint Cost Service) to provide calendared information services fo
r them.</t>
<!-- old
The reference time zone for the provided time values is UTC. The
option chosen to express the time format is the HTTP header fields
format specified in [RFC7231] where, however, timestamps are still
displayed with the acronym "GMT" rather than "UTC":
-->
<t>
Both extensions return calendar start time (calendar-start-time, a point in t
ime),
which MUST be specified as an HTTP "Date" header field using the IMF-fixdate
format
specified in Section 7.1.1.1 of <xref target="RFC7231"/>.
Note that the IMF-fixdate format uses "GMT", not "UTC", to designate the time
zone,
as in this example:</t>
<t><list hangIndent="17" style="hanging"><t>
Date: Tue, 15 Nov 2019 08:12:31 GMT</t>
</list>
</t>
<!-- <t>The value of a Calendar time interval size is expressed in second
s.</t> -->
<section title="Calendar extensions for Filtered Cost Maps (FCM)" anchor=
"sect-5.1"><t>
A legacy ALTO Client requests and gets Filtered Cost Map responses as
specified in <xref target="RFC7285"/>.</t>
<section title="Calendar extensions in Filtered Cost Map requests" anchor
="sect-5.1.1"><t>
The input parameters of a "legacy" request for a Filtered Cost Map,
defined by object ReqFilteredCostMap in section 11.3.2 of <xref target="RFC72
85"/>,
are augmented with one additional member. The same augmentation applies to ob
ject ReqFilteredCostMap
defined in section 4.1.2 of <xref target="RFC8189"/>.</t>
<t>
A Calendar-aware ALTO Client requesting a Calendar on a given Cost
Type for a Filtered Cost Map resource having Calendar capabilities
MUST add the following field to its input parameters:</t>
<t><list hangIndent="23" style="hanging"><t>
JSONBoolean calendared&lt;1..*&gt;;</t>
</list>
</t>
<t>
This field is an array of 1 to N boolean values, where N is the
number of requested metrics. N is greater than 1 when the Client and the
Server also implement <xref target="RFC8189"/>. </t>
<t> Each entry corresponds to the requested
metric at the same array position. Each boolean value indicates
whether or not the ALTO Server should provide the values for this
cost type as a Calendar. The array MUST contain exactly N boolean
values, otherwise, the Server returns an error.</t>
<t>
This field MUST NOT be included if no member "calendar-attributes" is
specified in this information resource.</t>
<t>
If a value of field "calendared" is 'true' for a cost type name for
which no Calendar attributes have been specified: an ALTO Server,
whether it implements the extensions of this document or only
implements <xref target="RFC7285"/>, MUST ignore it and return a response wit
h a
single cost value as specified in <xref target="RFC7285"/>.</t>
<t>
If this field is not present, it MUST be assumed to have only values
equal to 'false'.</t>
<t>
A Calendar-aware ALTO Client that supports requests for only one cost
type at a time and wants to request a Calendar MUST provide an array
of 1 element:</t>
<t><list hangIndent="23" style="hanging"><t>
"calendared" : [true],</t>
</list>
</t>
<t>
A Calendar-aware ALTO Client that supports requests for more than one
cost types at a time, as specified in <xref target="RFC8189"/> MUST provide a
n array
of N values set to 'true' or 'false', depending whether it wants the
applicable cost type values as a single or calendared value.</t>
</section>
<section title="Calendar extensions in Filtered Cost Map responses" ancho <section anchor="sect-5.1" numbered="true" toc="default">
r="sect-5.1.2"><t> <name>Calendar Extensions for Filtered Cost Maps (FCM)</name>
<t>A legacy ALTO Client requests and gets Filtered Cost Map responses,
as specified in <xref target="RFC7285" format="default"/>.</t>
<section anchor="sect-5.1.1" numbered="true" toc="default">
<name>Calendar Extensions in Filtered Cost Map Requests</name>
<t>The input parameters of a "legacy" request for a Filtered Cost
Map, defined by object ReqFilteredCostMap in <xref target="RFC7285"
sectionFormat="of" section="11.3.2"/>, are augmented with one
additional member. The same augmentation applies to object
ReqFilteredCostMap defined in <xref target="RFC8189"
sectionFormat="of" section="4.1.2"/>.</t>
<t>A Calendar-aware ALTO Client requesting a Calendar on a given
cost type for a Filtered Cost Map resource having Calendar
capabilities <bcp14>MUST</bcp14> add the following field to its
input parameters:</t>
<sourcecode><![CDATA[
JSONBoolean calendared<1..*>;
]]></sourcecode>
<t>This field is an array of 1 to N boolean values, where N is the
number of requested metrics. N is greater than 1 when the Client and
the Server also implement <xref target="RFC8189"
format="default"/>.</t>
<t> Each entry corresponds to the requested metric at the same array
position. Each boolean value indicates whether or not the ALTO
Server should provide the values for this cost type as a Calendar.
The array <bcp14>MUST</bcp14> contain exactly N boolean values,
otherwise, the Server returns an error.</t>
<t>This field <bcp14>MUST NOT</bcp14> be included if no member
"calendar-attributes" is specified in this information resource.</t>
<t>If a value of field "calendared" is 'true' for a cost type name
for which no Calendar attributes have been specified, an ALTO
Server, whether it implements the extensions of this document or
only implements <xref target="RFC7285" format="default"/>,
<bcp14>MUST</bcp14> ignore it and return a response with a single
cost value, as specified in <xref target="RFC7285"
format="default"/>.</t>
<t>If this field is not present, it <bcp14>MUST</bcp14> be assumed
to have only values equal to 'false'.</t>
<t>A Calendar-aware ALTO Client that supports requests for only one
cost type at a time and wants to request a Calendar
<bcp14>MUST</bcp14> provide an array of 1 element:</t>
<sourcecode><![CDATA[
"calendared" : [true],
]]></sourcecode>
<t>A Calendar-aware ALTO Client that supports requests for more than
one cost type at a time, as specified in <xref target="RFC8189"
format="default"/>, <bcp14>MUST</bcp14> provide an array of N values
set to 'true' or 'false', depending whether it wants the applicable
cost type values as a single or calendared value.</t>
</section>
<section anchor="sect-5.1.2" numbered="true" toc="default">
<name>Calendar Extensions in Filtered Cost Map Responses</name>
<t>
In a calendared ALTO Filtered Cost Map, a cost value between a source In a calendared ALTO Filtered Cost Map, a cost value between a source
and a destination is a JSON array of JSON values. An ALTO Calendar and a destination is a JSON array of JSON values. An ALTO Calendar
values array has a number of values equal to the value of member values array has a number of values equal to the value of member
"number-of-intervals" of the Calendar attributes that are indicated "number-of-intervals" of the Calendar attributes that are indicated
in the IRD. These attributes will be conveyed as metadata in the in the IRD. These attributes will be conveyed as metadata in the
Filtered Cost Map response. Each element of the array is valid for Filtered Cost Map response. Each element of the array is valid for
the time-interval that matches its array position.</t> the time interval that matches its array position.</t>
<t>
<t> The FCM response conveys metadata, among which:</t>
The FCM response conveys metadata among which:</t> <ul spacing="normal">
<li>some are not specific to Calendars and ensure compatibility
<t><list style="symbols"><t>some are not specific to Calendars and ensure with <xref target="RFC7285" format="default"/> and <xref
compatibility with target="RFC8189" format="default"/> and</li>
<xref target="RFC7285"/> and <xref target="RFC8189"/></t> <li>some are specific to Calendars.</li>
</ul>
<t>some are specific to Calendars.</t> <t>The non-Calendar-specific "meta" fields of a calendared Filtered
Cost Map response <bcp14>MUST</bcp14> include at least:</t>
</list> <ul spacing="normal">
</t> <li>
<t>if the ALTO Client requests cost values for one cost type at
<t> a time, only the "meta" fields specified in <xref
The non Calendar-specific "meta" fields of a calendared Filtered Cost target="RFC7285" format="default"/> for these information
Map response MUST include at least:</t> service responses:</t>
<ul spacing="normal">
<t><list style="symbols"><t>if the ALTO Client requests cost values for o <li>"dependent-vtags" and</li>
ne cost type at a <li>"cost-type" field.</li>
time only: the "meta" fields specified in <xref target="RFC7285"/> for the </ul>
se </li>
information service responses:<list style="symbols"><t>"dependent-vtags ", <li>
</t> <t>if the ALTO Client implements the Multi-Cost ALTO extension
specified in <xref target="RFC8189" format="default"/> and
<t>"cost-type" field.</t> requests cost values for several cost types at a time, the
"meta" fields specified in <xref target="RFC8189"
</list> format="default"/> for these information service responses:</t>
</t> <ul spacing="normal">
<li>"dependent-vtags",</li>
<t>if the ALTO Client implements the Multi-Cost ALTO extension <li>"cost-type" field with value set to '{}', for backwards
specified in <xref target="RFC8189"/> and requests cost values for several compatibility with <xref target="RFC7285" format="default"/>,
cost and</li>
types at a time: the "meta" fields specified in <xref target="RFC8189"/> f <li>"multi-cost-types" field.</li>
or </ul>
these information service responses:<list style="symbols"><t>"dependent-vt </li>
ags ",</t> </ul>
<t>If the Client request does not provide member "calendared" or if
<t>"cost-type" field with value set to '{}', for backwards it provides it with a value equal to 'false' for all the requested
compatibility with <xref target="RFC7285"/>.</t> cost types, then the ALTO Server response is exactly as specified in
<xref target="RFC7285" format="default"/> and <xref target="RFC8189"
<t>"multi-cost-types" field.</t> format="default"/>.</t>
<t>
</list>
</t>
</list>
</t>
<t>
If the Client request does not provide member "calendared" or if it
provides it with a value equal to 'false', for all the requested cost
types, then the ALTO Server response is exactly as specified in
<xref target="RFC7285"/> and <xref target="RFC8189"/>.</t>
<t>
If the value of member "calendared" is equal to 'false' for a given If the value of member "calendared" is equal to 'false' for a given
requested cost type, the ALTO Server MUST return, for this cost type, requested cost type, the ALTO Server <bcp14>MUST</bcp14> return, for this cos
a single cost value as specified in <xref target="RFC7285"/>.</t> t type,
a single cost value as specified in <xref target="RFC7285" format="default"/>
<t> .</t>
<t>
If the value of member "calendared" is equal to 'true' for a given If the value of member "calendared" is equal to 'true' for a given
requested cost type, the ALTO Server returns, for this cost type, a requested cost type, the ALTO Server returns, for this cost type, a
cost value Calendar as specified above in this section. In addition cost value Calendar, as specified above in this section. In addition
to the above cited non Calendar specific "meta" members, the Server to the above cited non-Calendar-specific "meta" members, the Server
MUST provide a Calendar specific metadata field.</t> <bcp14>MUST</bcp14> provide a Calendar-specific metadata field.</t>
<t>
<t>
The Calendar-specific "meta" field that a calendared Filtered Cost The Calendar-specific "meta" field that a calendared Filtered Cost
Map response MUST include is a member called "calendar-response-attributes", Map response <bcp14>MUST</bcp14> include is a member called "calendar-respons
that describes properties of the Calendar and where:</t> e-attributes",
which describes properties of the Calendar and where:</t>
<t><list style="symbols"> <ul spacing="normal">
<t>member "calendar-response-attributes" is an array of one or more <li>member "calendar-response-attributes" is an array of one or
objects of type "CalendarResponseAttributes".</t> more objects of type "CalendarResponseAttributes",</li>
<li>each "CalendarResponseAttributes" object in the array is specifi
<t>each "CalendarResponseAttributes" object in the array is specified ed
for one or more cost types for which the value of member for one or more cost types for which the value of member
"calendared", in object ReqFilteredCostMap provided in the Client request, "calendared", in object ReqFilteredCostMap provided in the Client request,
is equal to 'true' and for which a Calendar is is equal to 'true' and for which a Calendar is
provided for the requested information resource.</t> provided for the requested information resource, and</li>
<li>the "CalendarResponseAttributes" object that applies to a cost
<t>the "CalendarResponseAttributes" object that applies to a cost type name has a corresponding "CalendarAttributes" object defined
type name has a corresponding "CalendarAttributes" object defined for this cost type name in the IRD capabilities of the requested
for this cost type name in the IRD capabilities of the requested information resource. This object is the entry in the
information resource. This object is the entry, in the "calendar-attribute "calendar-attributes" array member of the IRD resource entry,
s" which includes the name of the requested cost type. This
array member of the IRD resource entry, that includes the name of the requ corresponding "CalendarAttributes" object has the same values as
ested cost type. object "CalendarResponseAttributes" for members
This corresponding "CalendarAttributes" object has the same values "time-interval-size" and "number-of-intervals". The members of the
as object "CalendarResponseAttributes" for members "time-interval-size" "CalendarResponseAttributes" object include all the members of the
and "number-of-intervals". The members of the "CalendarResponseAttributes" corresponding "CalendarAttributes" object.</li>
object </ul>
include all the members of the corresponding "CalendarAttributes" object.< <t>
/t>
</list>
</t>
<t>
The format of member "CalendarResponseAttributes is defined as follows:</t> The format of member "CalendarResponseAttributes is defined as follows:</t>
<t>
<t>
CalendarResponseAttributes calendar-response-attributes &lt;1..*&gt;;</t> CalendarResponseAttributes calendar-response-attributes &lt;1..*&gt;;</t>
<sourcecode><![CDATA[
<figure><artwork><![CDATA[
object{ object{
[JSONString cost-type-names <1..*>;] [JSONString cost-type-names <1..*>;]
JSONString calendar-start-time; JSONString calendar-start-time;
JSONNumber time-interval-size; JSONNumber time-interval-size;
JSONNumber number-of-intervals; JSONNumber number-of-intervals;
[JSONNumber repeated;] [JSONNumber repeated;]
} CalendarResponseAttributes; } CalendarResponseAttributes;
Object CalendarResponseAttributes has the following attributes: Object CalendarResponseAttributes has the following attributes:
]]></artwork> ]]></sourcecode>
</figure> <dl newline="true" spacing="normal">
<t><list style="symbols"> <dt>"cost-type-names":</dt>
<t>"cost-type-names": is an array of one or more cost-type-names to <dd>An array of one or more cost type names to which the value
which the value of the other members of CalendarResponseAttributes apply of the other members of CalendarResponseAttributes apply and for
and for which a Calendar has been requested. which a Calendar has been requested. The value of this member is a
The value of this member is a subset of the "cost-type-names" member of th subset of the "cost-type-names" member of the abovementioned
e corresponding "CalendarAttributes" object in the
abovementioned corresponding "CalendarAttributes" object in the "calendar- "calendar-attributes" array member in the IRD. This member
attributes" <bcp14>MUST</bcp14> be present when Cost Calendars are provided
array member in the IRD. This member MUST be present when Cost Calendars a for more than one cost type.</dd>
re provided for <dt>"calendar-start-time":</dt>
more than one cost type.</t> <dd>Indicates the date at which the first value of the Calendar
applies. The value is a string that, as specified in <xref
<t>"calendar-start-time": indicates the date at which the first value target="sect-5" format="default"/>, contains an HTTP "Date" header
of the Calendar applies. The value is a string that, as specified in field using the IMF-fixdate format specified in <xref
<xref target="sect-5"/>, contains an HTTP "Date" header field using the target="RFC7231" sectionFormat="of" section="7.1.1.1"/>. The
IMF-fixdate format specified in Section 7.1.1.1 of <xref target="RFC7231"/ value provided for attribute "calendar-start-time" <bcp14>SHOULD
>. NOT</bcp14> be later than the request date.</dd>
The value provided for attribute "calendar-start-time" SHOULD NOT be later <dt>"time-interval-size":</dt>
than the request date.</t> <dd>As specified in <xref target="sect-4.1" format="default"/> and
with the same value as in the abovementioned corresponding
<t>"time-interval-size": as specified in <xref target="sect-4.1"/> and wi "CalendarAttributes" object.</dd>
th the <dt>"number-of-intervals":</dt>
same value as in the abovementioned corresponding "CalendarAttributes" obj <dd>As specified in <xref target="sect-4.1" format="default"/> and
ect.</t> with the same value as in the abovementioned corresponding
"CalendarAttributes" object.</dd>
<t>"number-of-intervals": as specified in <xref target="sect-4.1"/> and w <dt>"repeated":</dt>
ith the <dd>An optional field provided for Calendars. It is an integer
same value as in the abovementioned corresponding "CalendarAttributes" obj N greater or equal to '1' that indicates how many iterations of
ect.</t> the Calendar value array starting at the date indicated by
"calendar-start-time" have the same values. The number N includes
<t>"repeated": is an optional field provided for Calendars. It is an the iteration provided in the returned response.</dd>
integer N greater or equal to '1' that indicates how many </dl>
iterations of the Calendar value array starting at the date <t>For example, suppose the "calendar-start-time" member has value
indicated by "calendar-start-time" have the same values. The "Mon, 30 Jun 2019 00:00:00 GMT", the "time-interval-size" member has
number N includes the iteration provided in the returned response.</t> value '3600', the "number-of-intervals" member has value '24', and
the value of member "repeated" is equal to '4'. This means that the
</list> Calendar values are the same on Monday, Tuesday, Wednesday, and
</t> Thursday on a period of 24 hours starting at 00:00:00 GMT. The ALTO
Client thus may use the same Calendar for the next 4 days starting
<t> at "calendar-start-time" and will only need to request a new one for
For example: suppose the "calendar-start-time" member has value Friday, July 4th at 00:00:00 GMT.</t>
"Mon, 30 Jun 2019 00:00:00 GMT", the "time-interval-size" member has <t>Attribute "repeated" may take a very high value if a Calendar
value '3600', the "number-of-intervals" member has value '24' and the represents a cyclic value pattern that the Server considers valid
value of member "repeated" is equal to '4'. This means that the for a long period and hence will only update once this period has
Calendar values are the same on Monday, Tuesday, Wednesday and elapsed or if an unexpected event occurs on the network. In the
Thursday on a period of 24 hours starting at 00:00:00 GMT. The ALTO latter case, the Client will be notified if it uses the "ALTO
Client thus may use the same Calendar for the next 4 days starting at Incremental Updates Using Server-Sent Events (SSE)" Service,
"calendar-start-time" and will only need to request a new one for specified in <xref target="RFC8895" format="default"/>. To this
Friday July 4th at 00:00:00 GMT.</t> end, it is <bcp14>RECOMMENDED</bcp14> that ALTO Servers providing
ALTO Calendars also provide the "ALTO Incremental Updates Using
<t> Server-Sent Events (SSE)" Service, which is specified in <xref
Attribute "repeated" may take a very high value if a Calendar target="RFC8895" format="default"/>. Likewise, ALTO Clients capable
represents a cyclic value pattern that the Server considers valid for of using ALTO Calendars <bcp14>SHOULD</bcp14> also use the SSE
a long period and hence will only update once this period has elapsed Service. See also discussion in <xref target="sect-8"
or if an unexpected event occurs on the network. In the latter case, format="default"/> "Operational Considerations".</t>
the Client will be notified if it uses the "ALTO Incremental Updates Using Se </section>
rver-Sent Events (SSE)" Service, specified in <section anchor="sect-5.1.3" numbered="true" toc="default">
<xref target="I-D.ietf-alto-incr-update-sse"/>. To this end, it is RECOMMEND <name>Use Case and Example: FCM with a Bandwidth Calendar</name>
ED <t>An example of non-real-time information that can be provisioned
that ALTO Servers providing ALTO Calendars also provide the "ALTO Incremental in a Calendar is the expected path throughput. While the
Updates Using Server-Sent Events (SSE)" Service that is transmission rate can be measured in real time by end systems, the
specified in <xref target="I-D.ietf-alto-incr-update-sse"/>. Likewise, ALTO operator of a data center is in the position of formulating
Clients capable of using ALTO Calendars SHOULD also use the SSE preferences for given paths at given time periods to avoid traffic
Service. See also discussion in <xref target="sect-8"/> "Operational Conside peaks due to diurnal usage patterns. In this example, we assume
rations".</t> that an ALTO Client requests a Calendar of network-provider-defined
throughput ratings as specified in the IRD to schedule its bulk
</section> data transfers as described in the use cases.</t>
<t>In the example IRD, Calendars for cost type name
<section title="Use case and example: FCM with a bandwidth Calendar" anch "num-throughputrating" are available for the information resources
or="sect-5.1.3"><t> "filtered-cost-calendar-map" and "endpoint-cost-map-calendar". The
An example of non-real-time information that can be provisioned in a ALTO Client requests a Calendar for "num-throughputrating" via a
Calendar is the expected path throughput. While the transmission POST request for a Filtered Cost Map.</t>
rate can be measured in real time by end systems, the operator of a <t>
data center is in the position of formulating preferences for given
paths, at given time periods to avoid traffic peaks due to diurnal
usage patterns. In this example, we assume that an ALTO Client
requests a Calendar of network-provider-defined throughput ratings,
as specified in the IRD, to schedule its bulk data transfers as
described in the use cases.</t>
<t>
In the example IRD, Calendars for cost type name "num-throughputrating" are a
vailable for the information resources:
"filtered-cost-calendar-map" and "endpoint-cost-map-calendar". The
ALTO Client requests a Calendar for "num-throughputrating" via a POST
request for a Filtered Cost Map.</t>
<t>
We suppose in the present example that the ALTO Client sends its We suppose in the present example that the ALTO Client sends its
request on Tuesday July 1st 2019 at 13:15. The Server returns request on Tuesday, July 1st 2019 at 13:15. The Server returns
Calendars with arrays of 12 numbers for each source and destination Calendars with arrays of 12 numbers for each source and destination
pair. The values for metric "throughputrating", in this example, are pair. The values for metric "throughputrating", in this example, are
assumed to be encoded in 2 digits.</t> assumed to be encoded in 2 digits.</t>
<sourcecode><![CDATA[
<figure><artwork><![CDATA[
POST /calendar/costmap/filtered HTTP/1.1 POST /calendar/costmap/filtered HTTP/1.1
Host: custom.alto.example.com Host: custom.alto.example.com
Content-Length: 217 Content-Length: 217
Content-Type: application/alto-costmapfilter+json Content-Type: application/alto-costmapfilter+json
Accept: application/alto-costmap+json,application/alto-error+json Accept: application/alto-costmap+json,application/alto-error+json
{ {
"cost-type" : {"cost-mode" : "numerical", "cost-type" : {"cost-mode" : "numerical",
"cost-metric" : "throughputrating"}, "cost-metric" : "throughputrating"},
"calendared" : [true], "calendared" : [true],
skipping to change at line 1197 skipping to change at line 1057
"PID3": [20, 20, 18, 14, 12, 12, "PID3": [20, 20, 18, 14, 12, 12,
14, 14, 12, 12, 14, 16] }, 14, 14, 12, 12, 14, 16] },
"PID2": { "PID1": [17, 18, 19, 10, 11, 12, "PID2": { "PID1": [17, 18, 19, 10, 11, 12,
13, 14, 15, 16, 17, 18], 13, 14, 15, 16, 17, 18],
"PID2": [20, 20, 18, 16, 14, 14, "PID2": [20, 20, 18, 16, 14, 14,
14, 16, 16, 16, 14, 16], 14, 16, 16, 16, 14, 16],
"PID3": [20, 20, 18, 14, 12, 12, "PID3": [20, 20, 18, 14, 12, 12,
14, 14, 12, 12, 14, 16] } 14, 14, 12, 12, 14, 16] }
} }
} }
]]></artwork> ]]></sourcecode>
</figure> </section>
</section> </section>
<section anchor="sect-5.2" numbered="true" toc="default">
</section> <name>Calendar Extensions in the Endpoint Cost Service</name>
<t>This document extends the Endpoint Cost Service, as defined in
<section title="Calendar extensions in the Endpoint Cost Service" anchor= <xref target="RFC7285" sectionFormat="of" section="11.5.1"/>, by adding n
"sect-5.2"><t> ew
This document extends the Endpoint Cost Service, as defined in input parameters and capabilities and by returning JSONArrays instead
{11.5.1} of <xref target="RFC7285"/>, by adding new input parameters and of JSONNumbers as the cost values. The media type (<xref
capabilities, and by returning JSONArrays instead of JSONNumbers as target="RFC7285" sectionFormat="of" section="11.5.1.1"/>) and HTTP
the cost values. The media type {11.5.1.1} and HTTP method method (<xref target="RFC7285" sectionFormat="of"
{11.5.1.2} are unchanged.</t> section="11.5.1.2"/>) are unchanged.</t>
<section anchor="sect-5.2.1" numbered="true" toc="default">
<section title="Calendar specific input in Endpoint Cost requests" anchor <name>Calendar-Specific Input in Endpoint Cost Requests</name>
="sect-5.2.1"><t> <t>The extensions to the requests for calendared Endpoint Cost Maps
The extensions to the requests for calendared Endpoint Cost Maps are are the same as for the Filtered Cost Map Service, specified in
the same as for the Filtered Cost Map Service, specified in <xref target="sec <xref target="sect-5.1.1" format="default"/> of this
t-5.1.1"/> document. Likewise, the rules defined around the extensions to ECM
of this document. Likewise, the rules defined around the extensions to ECM re requests are the same as those defined in <xref target="sect-5.1.1"
quests format="default"/> for FCM requests. </t>
are the same as those defined in <xref target="sect-5.1.1"/> for FCM requests <t>
. </t>
<t>
The ReqEndpointCostMap object for a calendared ECM request will have The ReqEndpointCostMap object for a calendared ECM request will have
the following format:</t> the following format:</t>
<sourcecode><![CDATA[
<figure><artwork><![CDATA[
object { object {
[CostType cost-type;] [CostType cost-type;]
[CostType multi-cost-types<1..*>;] [CostType multi-cost-types<1..*>;]
[JSONBoolean calendared<1..*>;] [JSONBoolean calendared<1..*>;]
EndpointFilter endpoints; EndpointFilter endpoints;
} ReqEndpointCostMap; } ReqEndpointCostMap;
object { object {
[TypedEndpointAddr srcs<0..*>;] [TypedEndpointAddr srcs<0..*>;]
[TypedEndpointAddr dsts<0..*>;] [TypedEndpointAddr dsts<0..*>;]
} EndpointFilter; } EndpointFilter;
]]></artwork> ]]></sourcecode>
</figure> <t>Member "cost-type" is optional because, in the ReqEndpointCostMap
object definition of this document, it is jointly present with
<t>Member "cost-type" is optional because, member "multi-cost-types" to ensure compatibility with <xref
in the ReqEndpointCostMap object definition of this document, it is jointly pres target="RFC8189" format="default"/>. In <xref target="RFC8189"
ent format="default"/>, members "cost-type" and "multi-cost-types" are
with member "multi-cost-types", to ensure compatibility with RFC 8189. In RFC818 both optional and have to obey the rule specified in <xref
9, target="RFC8189" sectionFormat="of" section="4.1.2"/> stating that
members "cost-type" and "multi-cost-types" are both optional and have to obey th "the Client <bcp14>MUST</bcp14> specify either "cost-type" or
e rule "multi-cost-types" but <bcp14>MUST NOT</bcp14> specify both".</t>
specified in section 4.1.2 of 8189 saying that: "the Client MUST specify either <t>The interpretation of member "calendared" is the same as for the
"cost-type" or "multi-cost-types" but MUST NOT specify both".</t> ReqFilteredCostMap object defined in <xref target="sect-5.1.1"
format="default"/> of this document. The interpretation of the other
<t>The interpretation of member "calendared" is the same as for the ReqFilteredC members is the same as for object ReqEndpointCostMap defined in
ostMap <xref target="RFC7285" format="default"/> and <xref target="RFC8189"
object defined in <xref target="sect-5.1.1"/> of this document. The interpretati format="default"/>. The type TypedEndpointAddr is defined in <xref
on of the target="RFC7285" sectionFormat="of" section="10.4.1"/>.</t>
other members is the same as for object ReqEndpointCostMap is defined in <xref t <t>For the reasons explained in <xref target="sect-3.3"
arget="RFC7285"/> format="default"/>, a Calendar-aware ALTO Server does not support
and <xref target="RFC8189"/>. The type TypedEndpointAddr is defined in section 1 constraints. Therefore, member "[constraints]" is not present in the
0.4.1 ReqEndpointCostMap object, and member "constraints" <bcp14>MUST
of <xref target="RFC7285"/>. </t> NOT</bcp14> be present in the input parameters of a request for an
Endpoint Cost Calendar. If this member is present, the Server
<t>For the reasons explained in section <xref target="sect-3.3"/>, <bcp14>MUST</bcp14> ignore it.</t>
a Calendar-aware ALTO Server does not support constraints. </section>
Therefore, member "[constraints]" is not present in the ReqEndpointCostMap objec <section anchor="sect-5.2.2" numbered="true" toc="default">
t and <name>Calendar Attributes in the Endpoint Cost Response</name>
member "constraints" MUST NOT be present in the input <t>The "meta" field of a calendared Endpoint Cost response
parameters of a request for an Endpoint Cost Calendar. <bcp14>MUST</bcp14> include at least:</t>
If this member is present, the Server MUST ignore it.</t> <ul spacing="normal">
<li>
</section> <t>if the ALTO Client supports cost values for one cost type at
a time only, the "meta" fields specified in <xref
<section title="Calendar attributes in the Endpoint Cost response" anchor target="RFC7285" sectionFormat="of" section="11.5.1.6"/> for the
="sect-5.2.2"><t> Endpoint Cost response:</t>
The "meta" field of a calendared Endpoint Cost response MUST include <ul spacing="normal">
at least:</t> <li>"cost-type" field.</li>
</ul>
<t><list style="symbols"><t>if the ALTO Client supports cost values for o </li>
ne cost type at a <li>
time only: the "meta" fields specified in {11.5.1.6} of <xref target="RFC7 <t>if the ALTO Client supports cost values for several cost
285"/> types at a time, as specified in <xref target="RFC8189"
for the Endpoint Cost response:<list style="symbols"><t>"cost-type" field. format="default"/>, the "meta" fields specified in <xref
</t> target="RFC8189" format="default"/> for the Endpoint Cost
response:</t>
</list> <ul spacing="normal">
</t> <li>"cost-type" field with value set to '{}', for backwards
compatibility with <xref target="RFC7285"
<t>if the ALTO Client supports cost values for several cost types at format="default"/>.</li>
a time, as specified in <xref target="RFC8189"/> : the "meta" fields speci <li>"multi-cost-types" field.</li>
fied in </ul>
<xref target="RFC8189"/> for the the Endpoint Cost response: </li>
<list style="symbols"> </ul>
<t>"cost-type" field with value set to '{}', for backwards compatibility <t>If the Client request does not provide member "calendared" or if
with <xref target="RFC7285"/>.</t> it provides it with a value equal to 'false', for all the requested
cost types, then the ALTO Server response is exactly as specified in
<t>"multi-cost-types" field.</t> <xref target="RFC7285" format="default"/> and <xref target="RFC8189"
format="default"/>.</t>
</list> <t>If the ALTO Client provides member "calendared" in the input
</t> parameters with a value equal to 'true' for given requested cost
types, the "meta" member of a calendared Endpoint Cost response
</list> <bcp14>MUST</bcp14> include, for these cost types, an additional
</t> member "calendar-response-attributes", the contents of which obey
the same rules as for the Filtered Cost Map Service, specified in
<t> <xref target="sect-5.1.2" format="default"/>. The Server response
If the Client request does not provide member "calendared" or if it is thus changed as follows, with respect to <xref target="RFC7285"
provides it with a value equal to 'false', for all the requested Cost format="default"/> and <xref target="RFC8189"
Types, then the ALTO Server response is exactly as specified in format="default"/>:</t>
<xref target="RFC7285"/> and <xref target="RFC8189"/>.</t> <ul spacing="normal">
<li>the "meta" member has one additional field
<t> "CalendarResponseAttributes", as specified for the Filtered Cost
If the ALTO Client provides member "calendared" in the input Map Service, and</li>
parameters with a value equal to 'true' for given requested Cost <li>the calendared costs are JSONArrays instead of the JSONNumbers
Types, the "meta" member of a calendared Endpoint Cost response MUST format used by legacy ALTO implementations. All arrays have a
include, for these cost types, an additional member "calendar-response-attrib number of values equal to 'number-of-intervals'. Each value
utes", the contents of which obey the same rules as corresponds to the cost in that interval.</li>
for the Filtered Cost Map Service, specified in <xref target="sect-5.1.2"/>. </ul>
The <t>If the value of member "calendared" is equal to 'false' for a
Server response is thus changed as follows, with respect to <xref target="RFC given requested cost type, the ALTO Server <bcp14>MUST</bcp14>
7285"/> and return, for this cost type, a single cost value as specified in
<xref target="RFC8189"/>:</t> <xref target="RFC7285" format="default"/>.</t>
</section>
<t><list style="symbols"><t>the "meta" member has one additional field <section anchor="sect-5.2.3" numbered="true" toc="default">
"CalendarResponseAttributes", as specified for the Filtered Cost <name>Use Case and Example: ECS with a routingcost Calendar</name>
Map Service,</t> <t>Let us assume an Application Client is located in an end system
with limited resources and has access to the network that is either
<t>the calendared costs are JSONArrays instead of the JSONNumbers intermittent or provides an acceptable quality in limited but
format used by legacy ALTO implementations. All arrays have a predictable time periods. Therefore, it needs to schedule both its
number of values equal to 'number-of-intervals'. resource-greedy networking activities and its ALTO transactions.</t>
Each value corresponds to the cost in that interval.</t> <t>The Application Client has the choice to trade content or
resources with a set of endpoints and needs to decide with which one
</list> it will connect and at what time. For instance, the endpoints are
</t> spread in different time zones or have intermittent access. In
this example, the 'routingcost' is assumed to be time-varying, with
<t> values provided as ALTO Calendars.</t>
If the value of member "calendared" is equal to 'false' for a given <t>The ALTO Client associated with the Application Client queries an
requested cost type, the ALTO Server MUST return, for this cost type, ALTO Calendar on 'routingcost' and will get the Calendar covering
a single cost value as specified in <xref target="RFC7285"/>.</t> the 24-hour time period "containing" the date and time of the ALTO
Client request.</t>
</section> <t>
<section title="Use case and example: ECS with a routingcost Calendar" an
chor="sect-5.2.3"><t>
Let us assume an Application Client is located in an end system with
limited resources and having access to the network that is either
intermittent or provides an acceptable quality in limited but
predictable time periods. Therefore, it needs to schedule both its
resource-greedy networking activities and its ALTO transactions.</t>
<t>
The Application Client has the choice to trade content or resources
with a set of Endpoints and needs to decide with which one it will
connect and at what time. For instance, the Endpoints are spread in
different time-zones, or have intermittent access. In this example,
the 'routingcost' is assumed to be time-varying, with values provided
as ALTO Calendars.</t>
<t>
The ALTO Client associated with the Application Client queries an
ALTO Calendar on 'routingcost' and will get the Calendar covering the
24 hours time period "containing" the date and time of the ALTO
Client request.</t>
<t>
For cost type "num-routingcost", the solicited ALTO Server has For cost type "num-routingcost", the solicited ALTO Server has
defined 3 different daily patterns each represented by a Calendar, to defined 3 different daily patterns, each represented by a Calendar to
cover the week of Monday June 30th at 00:00 to Sunday July 6th 23:59:</t> cover the week of Monday, June 30th at 00:00 to Sunday, July 6th 23:59:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>C1 for Monday, Tuesday, Wednesday, and Thursday (weekdays)</li>
<t>C1 for Monday, Tuesday, Wednesday, Thursday, (weekdays)</t> <li>C2 for Saturday and Sunday (weekends)</li>
<li>C3 for Friday (maintenance outage on July 4, 2019 from
<t>C2 for Saturday, Sunday, (weekend)</t> 02:00:00 GMT to 04:00:00 GMT or a big holiday that
is widely celebrated and generates a large number of connections).</l
<t>C3 for Friday (maintenance outage on July 4, 2019 from 02:00:00 GMT i>
to 04:00:00 GMT, or big holiday such as New Year evening).</t> </ul>
</list> <t>In the following example, the ALTO Client sends its request on
</t> Tuesday, July 1st 2019 at 13:15.</t>
<t>The "routingcost" values are assumed to be encoded in 3
<t> digits.</t>
In the following example, the ALTO Client sends its request on <sourcecode><![CDATA[
Tuesday July 1st 2019 at 13:15.</t>
<t>
The "routingcost" values are assumed to be encoded in 3 digits.</t>
<figure><artwork><![CDATA[
POST /calendar/endpointcost/lookup HTTP/1.1 POST /calendar/endpointcost/lookup HTTP/1.1
Host: custom.alto.example.com Host: custom.alto.example.com
Content-Length: 304 Content-Length: 304
Content-Type: application/alto-endpointcostparams+json Content-Type: application/alto-endpointcostparams+json
Accept: application/alto-endpointcost+json,application/alto-error+json Accept: application/alto-endpointcost+json,
application/alto-error+json
{ {
"cost-type" : {"cost-mode" : "numerical", "cost-type" : {"cost-mode" : "numerical",
"cost-metric" : "routingcost"}, "cost-metric" : "routingcost"},
"calendared" : [true], "calendared" : [true],
"endpoints" : { "endpoints" : {
"srcs": [ "ipv4:192.0.2.2" ], "srcs": [ "ipv4:192.0.2.2" ],
"dsts": [ "dsts": [
"ipv4:192.0.2.89", "ipv4:192.0.2.89",
"ipv4:198.51.100.34", "ipv4:198.51.100.34",
skipping to change at line 1420 skipping to change at line 1267
150, 100, 100, 100, 100, 100, 150, 100, 100, 100, 100, 100,
100, 100, 100, 100, 100, 150, 100, 100, 100, 100, 100, 150,
200, 300, 300, 300, 300, 250], 200, 300, 300, 300, 300, 250],
"ipv6:2001:db8::10" : [200, 250, 300, 300, 300, 300, "ipv6:2001:db8::10" : [200, 250, 300, 300, 300, 300,
250, 300, 300, 300, 300, 350, 250, 300, 300, 300, 300, 350,
300, 400, 250, 150, 100, 100, 300, 400, 250, 150, 100, 100,
100, 150, 200, 250, 250, 300] 100, 150, 200, 250, 250, 300]
} }
} }
} }
]]></artwork> ]]></sourcecode>
</figure> <t>When the Client gets the Calendar for "routingcost", it sees that
<t> the "calendar-start-time" is Monday at 00h00 GMT and member
When the Client gets the Calendar for "routingcost", it sees that the "repeated" is equal to '4'. It understands that the provided values
"calendar-start-time" is Monday at 00h00 GMT and member "repeated" is are valid until Thursday and will only need to get a Calendar update
equal to '4'. It understands that the provided values are valid on Friday.</t>
until Thursday included and will only need to get a Calendar update </section>
on Friday.</t> <section anchor="sect-5.2.4" numbered="true" toc="default">
<name>Use Case and Example: ECS with a Multi-cost Calendar for
</section> routingcost and owdelay</name>
<t>In this example, it is assumed that the ALTO Server implements
<section title="Use case and example: ECS with a multi-cost Calendar for multi-cost capabilities, as specified in <xref target="RFC8189"
routingcost and owdelay" anchor="sect-5.2.4"><t> format="default"/> . That is, an ALTO Client can request and receive
In this example, it is assumed that the ALTO Server implements multi- values for several cost types in one single transaction. An
cost capabilities, as specified in <xref target="RFC8189"/> . That is, an ALT illustrating use case is a path selection done on the basis of 2
O metrics: routingcost and owdelay.</t>
Client can request and receive values for several cost types in one <t>As in the previous example, the IRD indicates that the ALTO
single transaction. An illustrating use case is a path selection Server provides "routingcost" Calendars in terms of 24 time
done on the basis of 2 metrics: routing cost and owdelay.</t> intervals of 1 hour (3600 seconds) each.</t>
<t>For metric "owdelay", the IRD indicates that the ALTO Server
<t> provides Calendars in terms of 12 time interval values lasting 5
As in the previous example, the IRD indicates that the ALTO Server minutes (300 seconds) each.</t>
provides "routingcost" Calendars in terms of 24 time intervals of 1 <t>In the following example transaction, the ALTO Client sends its
hour (3600 seconds) each.</t> request on Tuesday, July 1st 2019 at 13:15.</t>
<t>
<t>
For metric "owdelay", the IRD indicates that the ALTO Server provides
Calendars in terms of 12 time intervals values lasting each 5 minutes
(300 seconds).</t>
<t>
In the following example transaction, the ALTO Client sends its
request on Tuesday July 1st 2019 at 13:15.</t>
<t>
This example assumes that the values of metric "owdelay" and This example assumes that the values of metric "owdelay" and
"routingcost" are encoded in 3 digits.</t> "routingcost" are encoded in 3 digits.</t>
<figure><artwork><![CDATA[ <sourcecode><![CDATA[
POST calendar/endpointcost/lookup HTTP/1.1 POST calendar/endpointcost/lookup HTTP/1.1
Host: custom.alto.example.com Host: custom.alto.example.com
Content-Length: 390 Content-Length: 390
Content-Type: application/alto-endpointcostparams+json Content-Type: application/alto-endpointcostparams+json
Accept: application/alto-endpointcost+json,application/alto-error+json Accept: application/alto-endpointcost+json,
application/alto-error+json
{ {
"cost-type" : {}, "cost-type" : {},
"multi-cost-types" : [ "multi-cost-types" : [
{"cost-mode" : "numerical", "cost-metric" : "routingcost"}, {"cost-mode" : "numerical", "cost-metric" : "routingcost"},
{"cost-mode" : "numerical", "cost-metric" : "owdelay"} {"cost-mode" : "numerical", "cost-metric" : "owdelay"}
], ],
"calendared" : [true, true], "calendared" : [true, true],
"endpoints" : { "endpoints" : {
"srcs": [ "ipv4:192.0.2.2" ], "srcs": [ "ipv4:192.0.2.2" ],
skipping to change at line 1532 skipping to change at line 1372
40, 40, 60, 90, 100, 80]], 40, 40, 60, 90, 100, 80]],
"ipv6:2001:db8::10" : [[200, 250, 300, 300, 300, 300, "ipv6:2001:db8::10" : [[200, 250, 300, 300, 300, 300,
250, 300, 300, 300, 300, 350, 250, 300, 300, 300, 300, 350,
300, 400, 250, 150, 100, 100, 300, 400, 250, 150, 100, 100,
100, 150, 200, 250, 250, 300], 100, 150, 200, 250, 250, 300],
[ 40, 40, 40, 40, 50, 50, [ 40, 40, 40, 40, 50, 50,
50, 20, 10, 15, 30, 40]] 50, 20, 10, 15, 30, 40]]
} }
} }
} }
]]></artwork> ]]></sourcecode>
</figure>
<t>
When receiving the response, the Client sees that the Calendar values
for metric "routingcost" are repeated for 4 iterations. Therefore,
in its next requests until the "routingcost" Calendar is expected to
change, the Client will only need to request a Calendar for
"owdelay".</t>
<t> <t>When receiving the response, the Client sees that the Calendar
values for metric "routingcost" are repeated for 4 iterations.
Therefore, in its next requests until the "routingcost" Calendar is
expected to change, the Client will only need to request a Calendar
for "owdelay".</t>
<t>
Without the ALTO Calendar extensions, the ALTO Client would have no Without the ALTO Calendar extensions, the ALTO Client would have no
clue on the dynamicity of the metric value change and would spend clue on the dynamicity of the metric value change and would spend
needless time requesting values at an inappropriate pace. In needless time requesting values at an inappropriate pace. In
addition, without the Multi-Cost ALTO capabilities, the ALTO Client addition, without the Multi-Cost ALTO capabilities, the ALTO Client
would duplicate this waste of time as it would need to send one would duplicate this waste of time as it would need to send one
request per cost metric.</t> request per cost metric.</t>
</section>
</section> </section>
</section>
</section> <section anchor="sect-6" numbered="true" toc="default">
<name>IANA Considerations</name>
</section> <t>This document has no IANA actions.</t>
</section>
<section title="IANA Considerations" anchor="sect-6"><t> <section anchor="sect-7" numbered="true" toc="default">
This document does not define any new media types or introduce any <name>Security Considerations</name>
new IANA considerations.</t> <t>As an extension of the base ALTO protocol <xref target="RFC7285"
format="default"/>, this document fits into the architecture of the base
</section> protocol and hence the security considerations (<xref target="RFC7285"
sectionFormat="of" section="15"/>) fully apply when this extension is
<section title="Security Considerations" anchor="sect-7"><t> provided by an ALTO Server. For example, the same authenticity and
As an extension of the base ALTO protocol <xref target="RFC7285"/>, this docu integrity considerations (<xref target="RFC7285" sectionFormat="of"
ment section="15.1"/>) still fully apply; the same considerations for the
fits into the architecture of the base protocol, and hence the privacy of ALTO users (<xref target="RFC7285" sectionFormat="of"
Security Considerations (Section 15) of <xref target="RFC7285"/> fully apply section="15.4"/>) also still fully apply.</t>
when this extension is provided by an ALTO Server. For example, the <t>
same authenticity and integrity considerations (Section 15.1 of
<xref target="RFC7285"/> still fully apply; the same considerations for the p
rivacy
of ALTO users (Section 15.4 of <xref target="RFC7285"/>) also still fully app
ly.</t>
<t>
The calendaring information provided by this extension requires The calendaring information provided by this extension requires
additional considerations on three security considerations discussed additional considerations on three security considerations discussed
in <xref target="RFC7285"/>: potential undesirable guidance to Clients in <xref target="RFC7285" format="default"/>: potential undesirable guidance
(Section 15.2 of <xref target="RFC7285"/>), confidentiality of ALTO informati to Clients
on (<xref target="RFC7285" sectionFormat="of" section="15.2"/>), confidentiality
(Section 15.2 of <xref target="RFC7285"/>), and availability of ALTO (Section of ALTO information
15.5 (<xref target="RFC7285" sectionFormat="of" section="15.3"/>), and
of <xref target="RFC7285"/>). For example, by providing network information availability of ALTO (<xref target="RFC7285"
in the sectionFormat="of" section="15.5"/>). For example, by providing network info
rmation in the
future in a Calendar, this extension may improve availability of future in a Calendar, this extension may improve availability of
ALTO, when the ALTO Server is unavailable but related information is ALTO when the ALTO Server is unavailable but related information is
already provided in the Calendar.</t> already provided in the Calendar.</t>
<t>
<t>
For confidentiality of ALTO information, an operator should be For confidentiality of ALTO information, an operator should be
cognizant that this extension may introduce a new risk: a malicious ALTO cognizant that this extension may introduce a new risk, a malicious ALTO
Client may get information for future events that are scheduled Client may get information for future events that are scheduled
through Calendaring. Possessing such information, the malicious Client may u se through Calendaring. Possessing such information, the malicious Client may u se
it to generate massive connections to the network at times where its load it to generate massive connections to the network at times where its load
is expected to be high.</t> is expected to be high.</t>
<t>To mitigate this risk, the operator should address the risk of ALTO
information being leaked to malicious Clients or third parties. As
specified in "Protection Strategies" (<xref target="RFC7285" sectionFormat
="of"
section="15.3.2"/>), the ALTO Server should
authenticate ALTO Clients and use the Transport Layer Security (TLS)
protocol so that man-in-the-middle (MITM) attacks to intercept an ALTO
Calendar are not possible. "Authentication and Encryption" (<xref target="
RFC7285" sectionFormat="of"
section="8.3.5"/>) ensures the availability of such a
solution. It specifies that "ALTO
Server implementations as well as ALTO Client implementations
<bcp14>MUST</bcp14> support the "https" URI scheme of <xref
target="RFC2818" format="default"/> and Transport Layer Security (TLS)
of <xref target="RFC5246" format="default"/>".</t>
<t>Section <xref target="RFC8446" sectionFormat="bare" section="1"/> of
TLS 1.3 <xref target="RFC8446"/> states: "While TLS 1.3 is not directly co
mpatible with previous
versions, all versions of TLS incorporate a versioning mechanism which
allows Clients and Servers to interoperably negotiate a common version
if one is supported by both peers". ALTO Clients and Servers
<bcp14>SHOULD</bcp14> support both TLS 1.3 <xref target="RFC8446"
format="default"/> and TLS 1.2 <xref target="RFC5246" format="default"/>
and <bcp14>MAY</bcp14> support and use newer versions of TLS as long as
the negotiation process succeeds.</t>
<t>The operator should be cognizant that the preceding mechanisms do not
address all security risks. In particular, they will not help in the
case of "malicious Clients" possessing valid authentication
credentials. The threat here is that legitimate Clients have become
subverted by an attacker and are now 'bots' being asked to participate
in a DDoS attack. The Calendar information now becomes valuable in
knowing exactly when to perpetrate a DDoS attack. A mechanism, such as a
monitoring system that detects abnormal behaviors, may still be needed.</t
>
<t> <t>To avoid malicious or erroneous guidance from ALTO information, an
To mitigate this risk, the operator should address the risk of ALTO ALTO Client should be cognizant that using calendaring information can
information being leaked to malicious Clients or third parties. As have risks: (1) Calendar values, especially in "repeated" Calendars, may
specified in Section 15.3.2 ("Protection Strategies") of <xref target="RFC728 be only statistical and (2) future events may change. Hence, a more
5"/>, robust ALTO Client should adapt and extend protection strategies
the ALTO Server should authenticate ALTO Clients and use the specified in <xref target="RFC7285" sectionFormat="of" section="15.2"/>.
Transport Layer Security (TLS) protocol so that Man In The Middle For example, to be notified immediately when a particular ALTO value
(MITM) attacks to intercept an ALTO Calendar are not possible. that the Client depends on changes, it is <bcp14>RECOMMENDED</bcp14>
<xref target="RFC7285"/> ensures the availability of such a solution in its that both the ALTO Client and ALTO Server using this extension support
Section 8.3.5. "Authentication and Encryption", which specifies "Application-Layer Traffic
that: "ALTO Server implementations as well as ALTO Client implementations Optimization (ALTO) Incremental Updates Using Server-Sent
MUST support the "https" URI scheme of <xref target="RFC2818"/> and Transport Events (SSE)" <xref
Layer target="RFC8895" format="default"/>.</t>
Security (TLS) of <xref target="RFC5246"/>".</t> <t>Another risk of erroneous guidance appears when the Server exposes an
occurrence of a same cost type name in different elements of the
<t> Calendar objects array associated to an information resource. In this
<xref target="RFC8446"/> specifies TLS 1.3 and writes in its section 1: case, there is no way for the Client to figure out which Calendar object
"While TLS 1.3 is not directly compatible with previous versions, all in the array is valid. The specification in this document recommends, in
versions of TLS incorporate a versioning mechanism which allows Clients this case, that the Client uses the first encountered Calendar object
and Servers to interoperably negotiate a common version if one is occurrence containing the cost type name. However, the Client may want
supported by both peers". to avoid the risks of erroneous guidance associated to the use of
ALTO Clients and Servers SHOULD support both TLS 1.3 [RFC8446] and potentially invalid Calendar values. To this end, as an alternative to
TLS 1.2 [RFC5246], and MAY support and use newer versions of TLS the recommendation in this document, the Client <bcp14>MAY</bcp14>
as long as the negotiation process succeeds. ignore the totality of occurrences of CalendarAttributes objects
</t> containing the cost type name and query this cost type using <xref
target="RFC7285" format="default"/>.</t>
<t> </section>
The operator should be cognizant that the preceding mechanisms <section anchor="sect-8" numbered="true" toc="default">
do not address all security risks. In particular, they will not help in <name>Operational Considerations</name>
the case of “malicious Clients” possessing valid authentication credentials. <t>It is important that both the operator of the network and the
The threat here is that legitimate Clients have operator of the applications consider both the feedback aspect and the
become subverted by an attacker and are now ‘bots’ being asked to prediction-based (uncertainty) aspect of using the Cost Calendar.</t>
participate in a DDoS attack. The Calendar information now becomes valuable <t>First, consider the feedback aspect and consider the Cost Calendar as
in knowing exactly when to perpetrate a DDoS attack. A mechanism such as a traffic-aware map service (e.g., Google Maps). Using the service
a monitoring system that detects abnormal behaviors may still be needed. without considering its own effect, a large fleet can turn a
</t> not-congested road into a congested one; a large number of individual
cars each choosing a road with light traffic ("cheap link") can also
<t> result in congestion or result in a less-optimal global outcome (e.g.,
To avoid malicious or erroneous guidance from ALTO information, an the Braess' Paradox <xref target="BRAESS_PARADOX"
ALTO Client should be cognizant that using calendaring information format="default"/>).</t>
can have risks: (1) Calendar values, especially in "repeated" <t>Next, consider the prediction aspect. Conveying ALTO Cost Calendars
Calendars may be only statistical, and (2) future events may change. tends to reduce the on-the-wire data exchange volume compared to
Hence, a more robust ALTO Client should adapt and extend protection multiple single-cost ALTO transactions. An application using Calendars
strategies specified in Section 15.2 of <xref target="RFC7285"/>. For has a set of time-dependent values upon which it can plan its
example, to be notified immediately when a particular ALTO value that connections in advance with no need for the ALTO Client to query
the Client depends on changes, it is RECOMMENDED that both the ALTO information at each time. Additionally, the Calendar response attribute
Client and ALTO Server using this extension support "ALTO Incremental "repeated", when provided, saves additional data exchanges in that it
Updates Using Server-Sent Events(SSE)" Service <xref target="I-D.ietf-alto-in indicates that the ALTO Client does not need to query Calendars during a
cr-update-sse"/>.</t> period indicated by this attribute. The preceding is true only when
"accidents" do not happen.</t>
<t>Another risk of erroneous guidance appears when the Server exposes an occu <t>Although individual network operators and application operators can
rrence of choose their own approaches to address the aforementioned issues, this
a same cost type name in different elements of the Calendar objects array ass document recommends the following considerations. First, a typical
ociated approach to reducing instability and handling uncertainty is to ensure
to an information resource. In this case, there is no way for the Client to f timely update of information. The SSE Service, as discussed in <xref
igure out target="sect-7" format="default"/>, can handle updates if supported by
which Calendar object in the array is valid. both the Server and the Client. Second, when a network operator updates
The specification in this document recommends, in this case, that the Client the Cost Calendar and when an application reacts to the update, they
uses the should consider the feedback effects. This is the best approach even
first encountered Calendar object occurrence containing the cost type name. though there is theoretical analysis <xref
However, the Client may want to avoid the risks of erroneous guidance associa target="SELFISH_RTG_2002" format="default"/> and
ted to Internet-based evaluation <xref target="SELFISH_RTG_2003"
the use of potentially invalid Calendar values. To this end, as an alternativ format="default"/> showing that uncoordinated behaviors do not always
e to the cause substantial suboptimal results.</t>
recommendation in this document, the Client MAY ignore the totality of occure
nces of
CalendarAttributes objects containing the cost type name and query this cost
type
using <xref target="RFC7285"/>.</t>
</section>
<section title="Operational Considerations" anchor="sect-8">
<t>
It is important that both the operator of the network and the operator
of
the applications consider both the feedback aspect and the prediction-b
ased
(uncertainty) aspect of using the Cost Calendar.
</t>
<t>
First consider the feedback aspect and consider the Cost Calendar as a
traffic-aware map service (e.g.,
Google Maps). Using the service
without considering its own effect, a large fleet can turn a not-conges
ted
road into a congested one; a large number of individual cars each choos
ing
a road with light traffic ("cheap link") can also result in congestion
or
result in a less optimal global outcome (e.g., the Braess' Paradox
<xref target="Braess-paradox"/>).
</t>
<t>
Next consider the prediction aspect. Conveying ALTO Cost Calendars
tends to reduce the on-the-wire data exchange volume compared to multip
le
single cost ALTO transactions. An application using Calendars has a set
of
time-dependent values upon which it can plan its connections in advance
with no need for the ALTO Client to query information at each time.
Additionally, the Calendar response attribute "repeated", when provided
, saves
additional data exchanges in that it indicates that the ALTO Client
does not need to query Calendars during a period indicated by this
attribute. The preceding is true only when "accidents" do not happen.
</t>
<t> <t>
Although individual network operators and application operators can cho
ose
their own approaches to address the aforementioned issues, this documen
t
recommends the following considerations. First, a typical approach to
reducing instability and handling uncertainty is to ensure timely updat
e of
information. The SSE Service as discussed in <xref target="sect-7"/> ca
n handle
updates, if supported by both the Server and the Client.
Second, when a network operator updates the Cost Calendar and when an
application reacts to the update, they should consider the feedback eff
ects.
This is the best approach even though there is theoretical analysis
<xref target="Selfish-routing-Roughgarden-thesis"/> and Internet based
evaluation
<xref target="Selfish-routing-Internet-eval"/> showing that uncoordinat
ed behaviors
do not always cause substantial sub-optimal results.
</t>
<t>
High-resolution intervals may be needed when values change, sometimes High-resolution intervals may be needed when values change, sometimes
during very small time intervals but in a significant manner. A way during very small time intervals but in a significant manner. A way
to avoid conveying too many entries is to leverage on the "repeated" to avoid conveying too many entries is to leverage on the "repeated"
feature. A Server can smartly set the Calendar start time and number feature. A Server can smartly set the Calendar start time and number
of intervals so as to declare them "repeated" for a large number of of intervals so as to declare them "repeated" for a large number of
periods, until the Calendar values change and are conveyed to periods until the Calendar values change and are conveyed to
requesting Clients. requesting Clients.
</t> </t>
<t>The newer JSON Data Interchange Format specification <xref
target="RFC8259" format="default"/> used in ALTO Calendars replaces the
older one <xref target="RFC7159" format="default"/> used in the base
ALTO protocol <xref target="RFC7285" format="default"/>. The newer JSON
mandates UTF-8 text encoding to improve interoperability. Therefore,
ALTO Clients and Servers implementations using UTF-{16,32} need to be
cognizant of the subsequent interoperability risks and
<bcp14>MUST</bcp14> switch to UTF-8 encoding if they want to
interoperate with Calendar-aware Servers and Clients.</t>
</section>
</middle>
<back>
<t> <displayreference target="I-D.ietf-alto-performance-metrics" to="ALTO_METRICS"/>
The newer JSON Data Interchange Format specification <xref target="RF <references>
C8259"/> used in <name>References</name>
ALTO Calendars replaces the older one <xref target="RFC7159"/> used in <references>
the base ALTO <name>Normative References</name>
protocol <xref target="RFC7285"/>. The newer JSON mandates UTF-8 text e <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ncoding to ence.RFC.2119.xml"/>
improve interoperability. <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
Therefore, ALTO Clients and Servers implementations using UTF-{16,32} ence.RFC.7231.xml"/>
need to be cognizant of the subsequent interoperability risks and <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
MUST switch to UTF-8 encoding, if they want to ence.RFC.7285.xml"/>
interoperate with Calendar-aware Servers and Clients. <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
</t> ence.RFC.8174.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
</section> ence.RFC.8189.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<section title="Acknowledgements" anchor="sect-9"><t> ence.RFC.8259.xml"/>
The authors would like to thank Fred Baker, Li Geng, Diego Lopez, He <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
Peng and Haibin Song for fruitful discussions and feedback on earlier ence.RFC.5246.xml"/>
draft versions. Dawn Chan, Kai Gao, Vijay Gurbani, Yichen Qian, <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
Jürgen Schönwälder, and Brian Weis and Jensen Zhang provided substantial ence.RFC.8446.xml"/>
review feedback and suggestions to the protocol design.</t> <!-- draft-ietf-alto-incr-update-sse-22 -->
<reference anchor="RFC8895" target="https://www.rfc-editor.org/info/rfc8895">
</section> <front>
<title>Application-Layer Traffic Optimization (ALTO) Incremental Updates Using
</middle> Server-Sent Events (SSE)</title>
<author initials="W" surname="Roome" fullname="Wendy Roome">
<back> <organization/>
<references title="Normative References"> </author>
&RFC2119; <author initials="Y" surname="Yang" fullname="Y. Yang">
&RFC7231; <organization/>
&RFC7285; </author>
&RFC8174; <date month='November' year='2020'/>
&RFC8189; </front>
&RFC8259; <seriesInfo name="RFC" value="8895"/>
&RFC5246; <seriesInfo name="DOI" value="10.17487/RFC8895"/>
&RFC8446; </reference>
&I-D.ietf-alto-incr-update-sse;
<reference anchor="IEEE.754.2008">
<front>
<title>Standard for Binary Floating-Point Arithmetic, IEEE Standard 75
4</title>
<author surname="Institute of Electrical and Electronics Engineers">
<organization/>
</author>
<date day="" month="August" year="2008"/>
</front>
</reference>
</references>
<references title="Informative References">
&RFC2818;
&RFC5693;
&RFC6708;
&RFC7159;
&I-D.ietf-alto-performance-metrics;
&I-D.xiang-alto-multidomain-analytics;
<reference anchor="SENSE-sdn-e2e-net">
<front>
<title>SDN for End-to-End Networked Science at the Exascale (SENSE),
http://sense.es.net/overview</title>
<author surname="project supported by the Department of Energy Office
of
Science Advanced Scientific Computing Research (ASCR) Program">
<organization/>
</author>
<date day="" month="" year=""/> <reference anchor="IEEE.754.2019">
</front> <front>
</reference> <title>IEEE Standard for Floating-Point Arithmetic</title>
<author>
<organization>IEEE</organization>
</author>
<date month="June" year="2019"/>
</front>
<seriesInfo name="IEEE" value="754-2019"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2019.8766229"/>
</reference>
</references>
<references>
<reference anchor="Braess-paradox"> <name>Informative References</name>
<front> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<title>The Prevalence of Braess' Paradox</title> ence.RFC.2818.xml"/>
<author initials="R." surname="Steinberg" fullname="Richard Steinberg" <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
/> ence.RFC.5693.xml"/>
<author initials="W." surname="Zangwill" fullname="Willard I. Zangwill <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
"/> ence.RFC.6708.xml"/>
<date day="1" month="August" year="1983"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
</front> ence.RFC.7159.xml"/>
<seriesInfo name="Transportation Science" value="Vol. 17 No. 3"/>
</reference>
<reference anchor="Unicorn-fgcs"> <!-- draft-ietf-alto-performance-metrics-09: I-D Exists -->
<front> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
<title>Unicorn: Unified resource orchestration for multi-domain, geo-d .draft-ietf-alto-performance-metrics-09.xml"/>
istributed data analytics</title>
<author initials="Q." surname="Xiang" fullname="Qiao Xiang"/> <reference anchor="SENSE" target="http://sense.es.net/overview">
<author initials="T." surname="Wang" fullname="Tony Wang"/> <front>
<author initials="J." surname="Zhang" fullname="Jensen Zhang"/> <title>SDN for End-to-End Networked Science at the Exascale (SENSE)<
<author initials="H." surname="Newman" fullname="Harvey Newman"/> /title>
<author initials="Y." surname="Liu" fullname="Jace Liu"/> <author>
<date day="" month="April" year="2019"/> <organization>Department of Energy Office of Science Advanced
</front> Scientific Computing Research (ASCR) Program</organization>
<seriesInfo name="Future Generation of Computer Systems (FGCS)" value=" </author>
Volume 93, Pages 188-197"/> <date/>
</reference> </front>
</reference>
<reference anchor="Selfish-routing-Roughgarden-thesis"> <reference anchor="BRAESS_PARADOX">
<front> <front>
<title>Selfish Routing</title> <title>The Prevalence of Braess' Paradox</title>
<author initials="R." surname="Steinberg" fullname="Richard Steinber
g"/>
<author initials="W." surname="Zangwill" fullname="Willard I. Zangwi
ll"/>
<date day="1" month="August" year="1983"/>
</front>
<refcontent>Transportation Science Vol. 17, No. 3</refcontent>
<seriesInfo name="DOI" value="10.1287/trsc.17.3.301"/>
</reference>
<author initials="T." surname="Roughgarden" fullname="Tim Roughgarden" <reference anchor="UNICORN-FGCS">
/> <front>
<date day="1" month="May" year="2002"/> <title>Unicorn: Unified resource orchestration for multi-domain,
</front> geo-distributed data analytics</title>
<seriesInfo name="Dissertation Thesis, Cornell" value="2002"/> <author initials="Q." surname="Xiang" fullname="Qiao Xiang"/>
</reference> <author initials="T." surname="Wang" fullname="Tony Wang"/>
<author initials="J." surname="Zhang" fullname="Jensen Zhang"/>
<author initials="H." surname="Newman" fullname="Harvey Newman"/>
<author initials="Y." surname="Yang" fullname="Yang Richard Yang"/>
<author initials="Y." surname="Liu" fullname="Jace Liu"/>
<date month="March" year="2019"/>
</front>
<refcontent>Future Generation Computer Systems (FGCS), Vol. 93,
Pages 188-197</refcontent>
<seriesInfo name="DOI" value="10.1016/j.future.2018.09.048"/>
<seriesInfo name="ISSN" value="0167-739X"/>
</reference>
<reference anchor="Selfish-routing-Internet-eval"> <reference anchor="SELFISH_RTG_2002">
<front> <front>
<title>Selfish Routing in Internet-LIke Environments</title> <title>Selfish Routing</title>
<author initials="T." surname="Roughgarden" fullname="Tim Roughgarde
n"/>
<date month="May" year="2002"/>
</front>
<refcontent>Dissertation Thesis, Cornell</refcontent>
</reference>
<author initials="L." surname="Qiu" fullname="Lili Qiu"/> <reference anchor="SELFISH_RTG_2003">
<author initials="Y." surname="Yang" fullname="Y. Richard Yang"/> <front>
<author initials="Y." surname="Zhang" fullname="Yin Zhang"/> <title>Selfish Routing in Internet-LIke Environments</title>
<author initials="S." surname="Shenker" fullname="Scott Shenker"/> <author initials="L." surname="Qiu" fullname="Lili Qiu"/>
<date day="1" month="August" year="2001"/> <author initials="Y." surname="Yang" fullname="Yang Richard Yang"/>
</front> <author initials="Y." surname="Zhang" fullname="Yin Zhang"/>
<seriesInfo name="Proceedings of ACM SIGCOMM" value="2001"/> <author initials="S." surname="Shenker" fullname="Scott Shenker"/>
</reference> <date month="August" year="2003"/>
</front>
<seriesInfo name="DOI" value="10.1145/863955.863974"/>
<refcontent>Proceedings of SIGCOMM '03</refcontent>
</reference>
</references>
</references>
</references> <section anchor="acks" numbered="false" toc="default">
</back> <name>Acknowledgments</name>
<t>
The authors would like to thank <contact fullname="Fred Baker"/>, <contact
fullname="Li Geng"/>, <contact fullname="Diego Lopez"/>, <contact
fullname="He Peng"/>, and <contact fullname="Haibin Song"/> for fruitful
discussions and feedback on earlier draft versions. <contact
fullname="Dawn Chan"/>, <contact fullname="Kai Gao"/>, <contact
fullname="Vijay Gurbani"/>, <contact fullname="Yichen Qian"/>, <contact
fullname="Jürgen Schönwälder"/>, <contact fullname="Brian Weis"/>, and
<contact fullname="Jensen Zhang"/> provided substantial review feedback and
suggestions to the protocol design.</t>
</section>
</back>
</rfc> </rfc>
 End of changes. 63 change blocks. 
1646 lines changed or deleted 1322 lines changed or added

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