rfc9275.original.xml   rfc9275.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!-- [CS] updated by Chris 06/15/22 -->
<!-- [ST] formatted by Sarah 07/06/22 -->
<!-- draft submitted in xml v3 -->
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.5.6 --> <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.5.6 -->
<?rfc strict="yes"?>
<?rfc comments="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
<?rfc inline="yes"?> -ietf-alto-path-vector-25" number="9275" submissionType="IETF" category="exp" co
<?rfc editing="no"?> nsensus="true" obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDepth=
<?rfc toc="yes"?> "3" sortRefs="true" symRefs="true" version="3">
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc iprnotified="no"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
-ietf-alto-path-vector-25" category="exp" obsoletes="" updates="" submissionType
="IETF" xml:lang="en" tocInclude="true" tocDepth="3" sortRefs="true" symRefs="tr
ue" version="3">
<!-- xml2rfc v2v3 conversion 3.12.0 --> <!-- xml2rfc v2v3 conversion 3.12.0 -->
<front> <front>
<title abbrev="ALTO-PV">An ALTO Extension: Path Vector</title> <title abbrev="ALTO-PV">An Extension for Application-Layer Traffic Optimizat
<seriesInfo name="Internet-Draft" value="draft-ietf-alto-path-vector-25"/> ion (ALTO): Path&nbsp;Vector</title>
<seriesInfo name="RFC" value="9275"/>
<author initials="K." surname="Gao" fullname="Kai Gao"> <author initials="K." surname="Gao" fullname="Kai Gao">
<organization>Sichuan University</organization> <organization>Sichuan University</organization>
<address> <address>
<postal> <postal>
<street>No.24 South Section 1, Yihuan Road</street> <street>No.24 South Section 1, Yihuan Road</street>
<city>Chengdu</city> <city>Chengdu</city>
<code>610000</code> <code>610000</code>
<country>China</country> <country>China</country>
</postal> </postal>
<email>kaigao@scu.edu.cn</email> <email>kaigao@scu.edu.cn</email>
</address> </address>
</author> </author>
<author initials="Y." surname="Lee" fullname="Young Lee"> <author initials="Y." surname="Lee" fullname="Young Lee">
<organization>Samsung</organization> <organization>Samsung</organization>
<address> <address>
<postal> <postal>
<country>South Korea</country> <country>Republic of Korea</country>
</postal> </postal>
<email>younglee.tx@gmail.com</email> <email>younglee.tx@gmail.com</email>
</address> </address>
</author> </author>
<author initials="S." surname="Randriamasy" fullname="Sabine Randriamasy"> <author initials="S." surname="Randriamasy" fullname="Sabine Randriamasy">
<organization>Nokia Bell Labs</organization> <organization>Nokia Bell Labs</organization>
<address> <address>
<postal> <postal>
<street>Route de Villejust</street> <street>Route de Villejust</street>
<city>Nozay</city> <city>Nozay</city>
<code>91460</code> <code>91460</code>
<country>France</country> <country>France</country>
</postal> </postal>
<email>sabine.randriamasy@nokia-bell-labs.com</email> <email>sabine.randriamasy@nokia-bell-labs.com</email>
</address> </address>
</author> </author>
<author initials="Y.R." surname="Yang" fullname="Yang Richard Yang"> <author initials="Y." surname="Yang" fullname="Yang Richard Yang">
<organization>Yale University</organization> <organization>Yale University</organization>
<address> <address>
<postal> <postal>
<street>51 Prospect Street</street> <street>51 Prospect Street</street>
<city>New Haven</city> <city>New Haven</city>
<code>CT</code> <code>06511</code>
<country>USA</country> <region>CT</region>
<country>United States of America</country>
</postal> </postal>
<email>yry@cs.yale.edu</email> <email>yry@cs.yale.edu</email>
</address> </address>
</author> </author>
<author initials="J." surname="Zhang" fullname="Jingxuan Jensen Zhang"> <author initials="J." surname="Zhang" fullname="Jingxuan Jensen Zhang">
<organization>Tongji University</organization> <organization>Tongji University</organization>
<address> <address>
<postal> <postal>
<street>4800 Caoan Road</street> <street>4800 Caoan Road</street>
<city>Shanghai</city> <city>Shanghai</city>
<code>201804</code> <code>201804</code>
<country>China</country> <country>China</country>
</postal> </postal>
<email>jingxuan.n.zhang@gmail.com</email> <email>jingxuan.n.zhang@gmail.com</email>
</address> </address>
</author> </author>
<date/>
<area>Application</area> <date year="2022" month="August" />
<workgroup>ALTO</workgroup>
<area>tsv</area>
<workgroup>alto</workgroup>
<keyword>network visibility</keyword>
<keyword>abstract network element</keyword>
<keyword>shared bottleneck</keyword>
<abstract> <abstract>
<t>This document is an extension to the base Application-Layer Traffic Opt imization <t>This document is an extension to the base Application-Layer Traffic Opt imization
(ALTO) protocol. It extends the ALTO Cost Map and ALTO Property Map services so (ALTO) protocol. It extends the ALTO cost map and ALTO property map services so
that an application can decide which endpoint(s) to connect based on not only that an application can decide to which endpoint(s) to connect based not only on
numerical/ordinal cost values but also fine-grained abstract information of the numerical/ordinal cost values but also on fine-grained abstract information rega
rding the
paths. This is useful for applications whose performance is impacted by paths. This is useful for applications whose performance is impacted by
specified components of a network on the end-to-end paths, e.g., they may infer specific components of a network on the end-to-end paths, e.g., they may infer
that several paths share common links and prevent traffic bottlenecks by that several paths share common links and prevent traffic bottlenecks by
avoiding such paths. This extension introduces a new abstraction called Abstract avoiding such paths. This extension introduces a new abstraction called the "Abs
Network Element (ANE) to represent these components and encodes a network path tract
Network Element" (ANE) to represent these components and encodes a network path
as a vector of ANEs. Thus, it provides a more complete but still abstract graph as a vector of ANEs. Thus, it provides a more complete but still abstract graph
representation of the underlying network(s) for informed traffic optimization representation of the underlying network(s) for informed traffic optimization
among endpoints.</t> among endpoints.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction" numbered="true" toc="default"> <section anchor="introduction" numbered="true" toc="default">
<name>Introduction</name> <name>Introduction</name>
<!-- ALTO can improve QoE of overlay applications. --> <t>Network performance metrics are crucial for assessing the Quality of Experien
<t>Network performance metrics are crucial to assess the Quality of Experience ce
(QoE) of applications. The ALTO protocol allows Internet Service Providers (QoE) of applications. The Application-Layer Traffic Optimization (ALTO) protoco
(ISPs) to provide guidance, such as topological distance between different end l allows Internet Service Providers
(ISPs) to provide guidance, such as topological distances between different end
hosts, to overlay applications. Thus, the overlay applications can potentially hosts, to overlay applications. Thus, the overlay applications can potentially
improve the perceived QoE by better orchestrating their traffic to utilize the improve the perceived QoE by better orchestrating their traffic to utilize the
resources in the underlying network infrastructure.</t> resources in the underlying network infrastructure.</t>
<!-- ALTO supports only cost information of end-to-end paths. --> <t>The existing ALTO
<t>Existing ALTO cost map (<xref target="RFC7285" sectionFormat="of" section=
Cost Map (Section 11.2.3 of <xref target="RFC7285" format="default"/>) and Endpo "11.2.3"/>) and Endpoint Cost Service (<xref target="RFC7285" sectionFormat="of"
int Cost Service (Section 11.5 section="11.5"/>) provide only cost information for an end-to-end path defined
of <xref target="RFC7285" format="default"/>) provide only cost information on a by
n end-to-end path defined by its &lt;source, destination&gt; endpoints: the base protocol <xref target="RFC72
its &lt;source, destination&gt; endpoints: The base protocol <xref target="RFC72 85" format="default"/> allows the
85" format="default"/> allows the
services to expose the topological distances of end-to-end paths, while various services to expose the topological distances of end-to-end paths, while various
extensions have been proposed to extend the capability of these services, e.g., extensions have been proposed to extend the capability of these services, e.g.,
to express other performance metrics <xref target="I-D.ietf-alto-performance-met to express other performance metrics <xref target="ALTO-PERF-METRICS" format="de
rics" format="default"/>, to fault"/>, to
query multiple costs simultaneously <xref target="RFC8189" format="default"/>, a query multiple costs simultaneously <xref target="RFC8189" format="default"/>, a
nd to obtain the time-varying nd to obtain time-varying
values <xref target="RFC8896" format="default"/>.</t> values <xref target="RFC8896" format="default"/>.</t>
<!-- However, the QoE also depends on ANEs. --> <t>While numerical/ordinal cost values for end-to-end paths provided by
<t>While the existing extensions are sufficient for many overlay applications, the existing extensions are sufficient to optimize the QoE of many
the QoE of some overlay applications depends not only on the cost overlay applications, the QoE of some overlay applications also
information of end-to-end paths, but also on particular components of a network depends on the properties of particular components on the paths. For example, jo
on the paths and their properties. For example, job completion time, which is an b completion time, which is an
important QoE metric for a large-scale data analytics application, is impacted important QoE metric for a large-scale data analytics application, is impacted
by shared bottleneck links inside the carrier network as link capacity may by shared bottleneck links inside the carrier network, as link capacity may
impact the rate of data input/output to the job. We refer to such components of impact the rate of data input/output to the job. We refer to such components of
a network as Abstract Network Elements (ANE).</t> a network as Abstract Network Elements (ANEs).</t>
<t>Predicting such information can be very complex without the help of ISP <t>Predicting such information can be very complex without the help of ISP
s, for s; for
example, <xref target="BOXOPT" format="default"/> has shown that finding the opt imal bandwidth reservation for example, <xref target="BOXOPT" format="default"/> has shown that finding the opt imal bandwidth reservation for
multiple flows can be NP-hard without further information than whether a multiple flows can be NP-hard without further information than whether a
reservation succeeds. With proper guidance from the ISP, an overlay application reservation succeeds. With proper guidance from the ISP, an overlay application
may be able to schedule its traffic for better QoE. In the meantime, it may be may be able to schedule its traffic for better QoE. In the meantime, it may be
helpful as well for ISPs if applications could avoid using bottlenecks or helpful as well for ISPs if applications could avoid using bottlenecks or
challenging the network with poorly scheduled traffic.</t> challenging the network with poorly scheduled traffic.</t>
<t>Despite the claimed benefits, ISPs are not likely to expose raw details <t>Despite the claimed benefits, ISPs are not likely to expose raw details
on their on their network paths: first because ISPs have requirements
network paths: first for the sake of topology hiding requirement, second because to hide their network topologies, second because these details may
it may increase volume and computation overhead, and last because applications increase volume and computation overhead, and last because applications
do not necessarily need all the network path details and are likely not able to do not necessarily need all the network path details and are likely not
understand them.</t> able to understand them.</t>
<t>Therefore, it is beneficial for both ISPs and applications if an ALTO s erver <t>Therefore, it is beneficial for both ISPs and applications if an ALTO s erver
provides ALTO clients with an "abstract network state" that provides the provides ALTO clients with an "abstract network state" that provides the
necessary information to applications, while hiding the network complexity and necessary information to applications, while hiding network complexity and
confidential information. An "abstract network state" is a selected set of confidential information. An "abstract network state" is a selected set of
abstract representations of Abstract Network Elements traversed by the paths abstract representations of ANEs traversed by the paths
between &lt;source, destination&gt; pairs combined with properties of these Abst between &lt;source, destination&gt; pairs combined with properties of these ANEs
ract that are relevant to the overlay applications' QoE. Both an
Network Elements that are relevant to the overlay applications' QoE. Both an
application via its ALTO client and the ISP via the ALTO server can achieve application via its ALTO client and the ISP via the ALTO server can achieve
better confidentiality and resource utilization by appropriately abstracting better confidentiality and resource utilization by appropriately abstracting
relevant Abstract Network Elements. Server scalability can also be improved by relevant ANEs. Server scalability can also be improved by
combining Abstract Network Elements and their properties in a single response.</ combining ANEs and their properties in a single response.</t>
t> <t>This document extends the ALTO base protocol <xref target="RFC7285" for
<t>This document extends <xref target="RFC7285" format="default"/> to allo mat="default"/> to allow an ALTO server to convey "abstract
w an ALTO server to convey "abstract network state" for paths defined by their &lt;source, destination&gt; pairs. To
network state", for paths defined by their &lt;source, destination&gt; pairs. To this
this end, it introduces a new cost type called a "Path Vector", following the cost
end, it introduces a new cost type called "Path Vector" following the cost
metric registration specified in <xref target="RFC7285" format="default"/> and t he updated cost mode metric registration specified in <xref target="RFC7285" format="default"/> and t he updated cost mode
registration specified in <xref target="I-D.bw-alto-cost-mode" format="default"/ registration specified in <xref target="RFC9274" format="default"/>. A Path Vect
>. A Path Vector is an array or is an array
of identifiers that identifies an Abstract Network Element, which can be of identifiers that identifies an ANE, which can be
associated with various properties. The associations between ANEs and their associated with various properties. The associations between ANEs and their
properties are encoded in an ALTO information resource called Unified Property properties are encoded in an ALTO information resource called the "entity proper
Map, which is specified in <xref target="I-D.ietf-alto-unified-props-new" format ty
="default"/>.</t> map", which is specified in <xref target="RFC9240" format="default"/>.</t>
<t>For better confidentiality, this document aims to minimize information exposure <t>For better confidentiality, this document aims to minimize information exposure
of an ALTO server when providing Path Vector service. In particular, this of an ALTO server when providing Path Vector services. In particular, this
document enables and recommends that first ANEs are constructed on demand, and document enables the capability, and also recommends that 1) ANEs be constructed
second an ANE is only associated with properties that are requested by an ALTO on demand and
client. A Path Vector response involves two ALTO Maps: the Cost Map that 2) an ANE only be associated with properties that are requested by an ALTO
contains the Path Vector results and the up-to-date Unified Property Map that client. A Path Vector response involves two ALTO maps: the cost map, which
contains the Path Vector results; and the up-to-date entity property map, which
contains the properties requested for these ANEs. To enforce consistency and contains the properties requested for these ANEs. To enforce consistency and
improve server scalability, this document uses the "multipart/related" content improve server scalability, this document uses the "multipart/related" content
type defined in <xref target="RFC2387" format="default"/> to return the two maps type as defined in <xref target="RFC2387" format="default"/> to return the two m
in a single response.</t> aps in a single response.</t>
<t>As a single ISP may not have the knowledge of the full Internet paths b <t>As a single ISP may not have knowledge of the full Internet paths betwe
etween en
arbitrary endpoints, this document is mainly applicable 1) when there is a arbitrary endpoints, this document is mainly applicable when</t>
single ISP between the requested source and destination PIDs or endpoints, for <ul spacing="normal">
example, ISP-hosted CDN/edge, tenant interconnection in a single public cloud <li>there is a
platform, etc.; or 2) when the Path Vectors are generated from end-to-end single ISP between the requested source and destination Provider-defined Identif
measurement data.</t> iers (PIDs) or endpoints -- for
example, ISP-hosted Content Delivery Network (CDN) / edge, tenant interconnectio
n in a single public cloud
platform, etc., or</li>
<li>the Path Vectors are generated from end-to-end
measurement data.</li>
</ul>
</section> </section>
<section anchor="requirements-languages" numbered="true" toc="default"> <section anchor="requirements-languages" numbered="true" toc="default">
<name>Requirements Languages</name> <name>Requirements Language</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SH <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
OULD", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
document are to be interpreted as described in BCP 14 <xref target="RFC2119" for "<bcp14>SHOULD NOT</bcp14>",
mat="default"/> <xref target="RFC8174" format="default"/> "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
when, and only when, they appear in all capitals, as shown here.</t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
<t>When the words appear in lower case, they are to be interpreted with th are to be interpreted as described in BCP&nbsp;14
eir <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
natural language meanings.</t> when, they appear in all capitals, as shown here.</t>
</section> </section>
<section anchor="term" numbered="true" toc="default"> <section anchor="term" numbered="true" toc="default">
<name>Terminology</name> <name>Terminology</name>
<t>This document extends the ALTO base protocol <xref target="RFC7285" for <t>This document extends the ALTO base protocol <xref target="RFC7285" for
mat="default"/> and the Unified mat="default"/> and the entity
Property Map extension <xref target="I-D.ietf-alto-unified-props-new" format="de property map extension <xref target="RFC9240" format="default"/>. In addition to
fault"/>. In addition to the terms defined in those documents, this document also uses the following
the terms defined in these documents, this document also uses the following terms:</t>
additional terms:</t>
<dl> <dl>
<dt> <dt>
Abstract Network Element (ANE): </dt> Abstract Network Element (ANE): </dt>
<dd> <dd>
<t>An abstract representation for a component in a network that handle s data <t>An abstract representation for a component in a network that handle s data
packets and whose properties can potentially have an impact on the end-to-end packets and whose properties can potentially have an impact on the end-to-end
performance of traffic. An ANE can be a physical device such as a router, a performance of traffic. An ANE can be a physical device such as a router, a
link or an interface, or an aggregation of devices such as a subnetwork or a link, or an interface; or an aggregation of devices such as a subnetwork or a
data center. data center.
</t> </t>
<t>The definition of Abstract Network Element is similar to Network El <t>The definition of an ANE is similar to that for a network element
ement as defined in <xref target="RFC2216" format="default"/> in the sense that they b
defined in <xref target="RFC2216" format="default"/> in the sense that they both oth provide an abstract
provide an abstract
representation of specific components of a network. However, they have representation of specific components of a network. However, they have
different criteria on how these particular components are selected. different criteria on how these particular components are selected.
Specifically, a Network Element requires the components to be capable of Specifically, a network element requires the components to be capable of
exercising QoS control, while Abstract Network Element only requires the exercising QoS control, while an ANE only requires the
components to have an impact on the end-to-end performance.</t> components to have an impact on end-to-end performance.</t>
</dd> </dd>
<dt> <dt>
ANE Name: </dt> ANE name: </dt>
<dd> <dd>
<t>A string that uniquely identifies an ANE in a specific scope. An AN E <t>A string that uniquely identifies an ANE in a specific scope. An AN E
can be constructed either statically in advance or on demand based on the can be constructed either statically in advance or on demand based on the
requested information. Thus, different ANEs may only be valid within a requested information. Thus, different ANEs may only be valid within a
particular scope, either ephemeral or persistent. Within each scope, an ANE is particular scope, either ephemeral or persistent. Within each scope, an ANE is
uniquely identified by an ANE Name, as defined in <xref target="ane-name-spec" f ormat="default"/>. Note that uniquely identified by an ANE name, as defined in <xref target="ane-name-spec" f ormat="default"/>. Note that
an ALTO client must not assume ANEs in different scopes but with the same ANE an ALTO client must not assume ANEs in different scopes but with the same ANE
Name refer to the same component(s) of the network.</t> name refer to the same component(s) of the network.</t>
</dd> </dd>
<dt> <dt>
Path Vector: </dt> Path Vector (or ANE Path Vector): </dt>
<dd> <dd>
<t>Path Vector, or ANE Path Vector, refers to a JSON array of ANE Name <t>Refers to a JSON array of ANE names. It is a
s. It is a generalization of a BGP path vector. While a standard BGP path vector (<xref tar
generalization of BGP path vector. While standard BGP path vector (Section get="RFC4271" sectionFormat="of" section="5.1.2"/>) specifies a sequence of Auto
5.1.2 of <xref target="RFC4271" format="default"/>) specifies a sequence of auto nomous Systems (ASes) for a
nomous systems for a
destination IP prefix, the Path Vector defined in this extension specifies a destination IP prefix, the Path Vector defined in this extension specifies a
sequence of ANEs either for a source Provider-Defined Identifier (PID) and a sequence of ANEs for either 1) a source PID and a
destination PID as in the CostMapData (11.2.3.6 in <xref target="RFC7285" format destination PID, as in the CostMapData object (<xref target="RFC7285" sectionFor
="default"/>), or for a mat="of" section="11.2.3.6"/>) or 2) a
source endpoint and a destination endpoint as in the EndpointCostMapData source endpoint and a destination endpoint, as in the EndpointCostMapData
object (Section 11.5.1.6 of <xref target="RFC7285" format="default"/>).</t> object (<xref target="RFC7285" sectionFormat="of" section="11.5.1.6"/>).</t>
</dd> </dd>
<dt> <dt>
Path Vector resource: </dt> Path Vector resource: </dt>
<dd> <dd>
<t>An ALTO information resource (Section 8.1 of <xref target="RFC7285" format="default"/>) which supports the <t>An ALTO information resource (<xref target="RFC7285" sectionFormat= "of" section="8.1"/>) that supports the
extension defined in this document.</t> extension defined in this document.</t>
</dd> </dd>
<dt> <dt>
Path Vector cost type: </dt> Path Vector cost type: </dt>
<dd> <dd>
<t>A special cost type, which is specified in <xref target="cost-type- spec" format="default"/>. When this cost <t>A special cost type, which is specified in <xref target="cost-type- spec" format="default"/>. When this cost
type is present in an IRD entry, it indicates that the information resource is type is present in an Information Resource Directory (IRD) entry, it indicates t
a Path Vector resource. When this cost type is present in a Filtered Cost Map hat the information resource is
request or an Endpoint Cost Service request, it indicates each cost value must a Path Vector resource. When this cost type is present in a filtered cost map
request or an Endpoint Cost Service request, it indicates that each cost value m
ust
be interpreted as a Path Vector.</t> be interpreted as a Path Vector.</t>
</dd> </dd>
<dt> <dt>
Path Vector request: </dt> Path Vector request: </dt>
<dd> <dd>
<t>The POST message sent to an ALTO Path Vector resource.</t> <t>The POST message sent to an ALTO Path Vector resource.</t>
</dd> </dd>
<dt> <dt>
Path Vector response: </dt> Path Vector response: </dt>
<dd> <dd>
<t>A Path Vector response refers to the multipart/related message retu rned by a <t>Refers to the multipart/related message returned by a
Path Vector resource.</t> Path Vector resource.</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="probstat" numbered="true" toc="default"> <section anchor="probstat" numbered="true" toc="default">
<name>Requirements and Use Cases</name> <name>Requirements and Use Cases</name>
<section anchor="design-requirements" numbered="true" toc="default"> <section anchor="design-requirements" numbered="true" toc="default">
<name>Design Requirements</name> <name>Design Requirements</name>
<t>This section gives an illustrative example of how an overlay applicat ion can <t>This section gives an illustrative example of how an overlay applicat ion can
benefit from the extension defined in this document.</t> benefit from the extension defined in this document.</t>
<t>Assume that an application has control over a set of flows, which may go through <t>Assume that an application has control over a set of flows, which may go through
shared links/nodes and share bottlenecks. The application seeks to schedule the shared links/nodes and share bottlenecks. The application seeks to schedule the
traffic among multiple flows to get better performance. The constraints of traffic among multiple flows to get better performance. The constraints of
feasible rate allocations of those flows will benefit the scheduling. However, feasible rate allocations of those flows will benefit the scheduling. However,
Cost Maps as defined in <xref target="RFC7285" format="default"/> can not reveal cost maps as defined in <xref target="RFC7285" format="default"/> cannot reveal
such information.</t> such information.</t>
<t>Specifically, consider a network as shown in <xref target="fig-dumbbe <t>Specifically, consider the example network shown in <xref target="fig
ll" format="default"/>. The network has 7 -dumbbell" format="default"/>. The network has seven
switches (sw1 to sw7) forming a dumb-bell topology. Switches "sw1", "sw2", "sw3" switches ("sw1" to "sw7") forming a dumbbell topology. Switches "sw1", "sw2", "s
and "sw4" are access switches, and sw5-sw7 form the backbone. End hosts eh1 to w3",
eh4 are connected to access switches sw1 to sw4 respectively. Assume that the and "sw4" are access switches, and "sw5-sw7" form the backbone. End hosts "eh1"
bandwidth of link eh1 -&gt; sw1 and link sw1 -&gt; sw5 is 150 Mbps, and the band to
width "eh4" are connected to access switches "sw1" to "sw4", respectively. Assume that
the
bandwidth of link "eh1 -&gt; sw1" and link "sw1 -&gt; sw5" is 150 Mbps and the b
andwidth
of the other links is 100 Mbps.</t> of the other links is 100 Mbps.</t>
<figure anchor="fig-dumbbell"> <figure anchor="fig-dumbbell">
<name>Raw Network Topology</name> <name>Raw Network Topology</name>
<sourcecode type="drawing"><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
+-----+ +-----+
| | | |
--+ sw6 +-- --+ sw6 +--
/ | | \ / | | \
PID1 +-----+ / +-----+ \ +-----+ PID2 PID1 +-----+ / +-----+ \ +-----+ PID2
eh1__| |_ / \ ____| |__eh2 eh1__| |_ / \ ____| |__eh2
192.0.2.2 | sw1 | \ +--|--+ +--|--+ / | sw2 | 192.0.2.3 192.0.2.2 | sw1 | \ +--|--+ +--|--+ / | sw2 | 192.0.2.3
+-----+ \ | | | |/ +-----+ +-----+ \ | | | |/ +-----+
\_| sw5 +---------+ sw7 | \_| sw5 +---------+ sw7 |
PID3 +-----+ / | | | |\ +-----+ PID4 PID3 +-----+ / | | | |\ +-----+ PID4
eh3__| |__/ +-----+ +-----+ \____| |__eh4 eh3__| |__/ +-----+ +-----+ \____| |__eh4
192.0.2.4 | sw3 | | sw4 | 192.0.2.5 192.0.2.4 | sw3 | | sw4 | 192.0.2.5
+-----+ +-----+ +-----+ +-----+
bw(eh1--sw1) = bw(sw1--sw5) = 150 Mbps bw(eh1--sw1) = bw(sw1--sw5) = 150 Mbps
bw(eh2--sw2) = bw(eh3--sw3) = bw(eh4--sw4) = 100 Mbps bw(eh2--sw2) = bw(eh3--sw3) = bw(eh4--sw4) = 100 Mbps
bw(sw1--sw5) = bw(sw3--sw5) = bw(sw2--sw7) = bw(sw4--sw7) = 100 Mbps bw(sw1--sw5) = bw(sw3--sw5) = bw(sw2--sw7) = bw(sw4--sw7) = 100 Mbps
bw(sw5--sw6) = bw(sw5--sw7) = bw(sw6--sw7) = 100 Mbps bw(sw5--sw6) = bw(sw5--sw7) = bw(sw6--sw7) = 100 Mbps
]]></sourcecode> ]]></artwork>
</figure> </figure>
<t>The base ALTO topology abstraction of the network is shown in <xref t arget="fig-base" format="default"/>. <t>The base ALTO topology abstraction of the network is shown in <xref t arget="fig-base" format="default"/>.
Assume the cost map returns an hypothetical cost type representing the available Assume that the cost map returns a hypothetical cost type representing the avail
bandwidth between a source and a destination.</t> able
bandwidth between a source and a destination.</t>
<figure anchor="fig-base"> <figure anchor="fig-base">
<name>Base Topology Abstraction</name> <name>Base Topology Abstraction</name>
<sourcecode type="drawing"><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
+----------------------+ +----------------------+
{eh1} | | {eh2} {eh1} | | {eh2}
PID1 | | PID2 PID1 | | PID2
+------+ +------+ +------+ +------+
| | | |
| | | |
{eh3} | | {eh4} {eh3} | | {eh4}
PID3 | | PID4 PID3 | | PID4
+------+ +------+ +------+ +------+
| | | |
+----------------------+ +----------------------+
]]></sourcecode> ]]></artwork>
</figure> </figure>
<t>Now assume the application wants to maximize the total rate of the tr <t>Now, assume that the application wants to maximize the total rate of
affic among the traffic among
a set of &lt;source, destination&gt; pairs, say "eh1 -&gt; eh2" and "eh1 -&gt; e a set of &lt;source, destination&gt; pairs -- say, "eh1 -&gt; eh2" and "eh1 -&gt
h4". Let "x" ; eh4". Let "x"
denote the transmission rate of "eh1 -&gt; eh2" and "y" denote the rate of "eh1 -&gt; denote the transmission rate of "eh1 -&gt; eh2" and "y" denote the rate of "eh1 -&gt;
eh4". The objective function is</t> eh4". The objective function is</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
max(x + y). max(x + y).
]]></artwork> ]]></artwork>
<t>With the ALTO Cost Map, the cost between PID1 and PID2 and between PI D1 and PID4 will <t>With the ALTO cost map, the costs between PID1 and PID2 and between P ID1 and PID4 will
both be 100 Mbps. The client can get a capacity region of</t> both be 100 Mbps. The client can get a capacity region of</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
x <= 100 Mbps, x <= 100 Mbps
y <= 100 Mbps. y <= 100 Mbps.
]]></artwork> ]]></artwork>
<t>With this information, the client may mistakenly think it can achieve a maximum <t>With this information, the client may mistakenly think it can achieve a maximum
total rate of 200 Mbps. However, this rate is infeasible, as there are only two total rate of 200 Mbps. However, this rate is infeasible, as there are only two
potential cases:</t> potential cases:</t>
<ul spacing="normal"> <dl spacing="normal">
<li> <dt>Case 1:</dt><dd><t>"eh1 -&gt; eh2" and "eh1 -&gt; eh4" take differ
<t>Case 1: "eh1 -&gt; eh2" and "eh1 -&gt; eh4" take different path s ent path segments from "sw5" to "sw7". For
egments from "sw5" to "sw7". For
example, if "eh1 -&gt; eh2" uses path "eh1 -&gt; sw1 -&gt; sw5 -&gt; sw6 -&gt; s w7 -&gt; sw2 -&gt; eh2" example, if "eh1 -&gt; eh2" uses path "eh1 -&gt; sw1 -&gt; sw5 -&gt; sw6 -&gt; s w7 -&gt; sw2 -&gt; eh2"
and "eh1 -&gt; eh4" uses path "eh1 -&gt; sw1 -&gt; sw5 -&gt; sw7 -&gt; sw4 -&gt; eh4", then the shared and "eh1 -&gt; eh4" uses path "eh1 -&gt; sw1 -&gt; sw5 -&gt; sw7 -&gt; sw4 -&gt; eh4", then the shared
bottleneck links are "eh1 -&gt; sw1" and "sw1 -&gt; sw5". In this case, the capa city bottleneck links are "eh1 -&gt; sw1" and "sw1 -&gt; sw5". In this case, the capa city
region is: </t> region is: </t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
x <= 100 Mbps x <= 100 Mbps
y <= 100 Mbps y <= 100 Mbps
x + y <= 150 Mbps x + y <= 150 Mbps
]]></artwork> ]]></artwork>
<t> <t>
and the real optimal total rate is 150 Mbps.</t> and the real optimal total rate is 150 Mbps.</t>
</li> </dd>
<li> <dt>Case 2:</dt><dd><t>"eh1 -&gt; eh2" and "eh1 -&gt; eh4" take the
<t>Case 2: "eh1 -&gt; eh2" and "eh1 -&gt; eh4" take the same path se same path segment from "sw5" to "sw7".
gment from "sw5" to "sw7".
For example, if "eh1 -&gt; eh2" uses path "eh1 -&gt; sw1 -&gt; sw5 -&gt; sw7 -&g t; sw2 -&gt; eh2" For example, if "eh1 -&gt; eh2" uses path "eh1 -&gt; sw1 -&gt; sw5 -&gt; sw7 -&g t; sw2 -&gt; eh2"
and "eh1 -&gt; eh4" also uses path "eh1 -&gt; sw1 -&gt; sw5 -&gt; sw7 -&gt; sw4 -&gt; eh4", then the and "eh1 -&gt; eh4" also uses path "eh1 -&gt; sw1 -&gt; sw5 -&gt; sw7 -&gt; sw4 -&gt; eh4", then the
shared bottleneck link is "sw5 -&gt; sw7". In this case, the capacity region is: </t> shared bottleneck link is "sw5 -&gt; sw7". In this case, the capacity region is: </t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
x <= 100 Mbps x <= 100 Mbps
y <= 100 Mbps y <= 100 Mbps
x + y <= 100 Mbps x + y <= 100 Mbps
]]></artwork> ]]></artwork>
<t> <t>
and the real optimal total rate is 100 Mbps.</t> and the real optimal total rate is 100 Mbps.</t>
</li> </dd>
</ul> </dl>
<t>Clearly, with more accurate and fine-grained information, the applica tion can <t>Clearly, with more accurate and fine-grained information, the applica tion can
gain a better prediction of its traffic and may orchestrate its resources better predict its traffic and may orchestrate its resources
accordingly. However, to provide such information, the network needs to expose accordingly. However, to provide such information, the network needs to expose
abstract information beyond the simple cost map abstraction. In particular:</t> abstract information beyond the simple cost map abstraction. In particular:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>The ALTO server must expose abstract information about the network paths that are <li>The ALTO server must expose abstract information about the network paths that are
traversed by the traffic between a source and a destination beyond a simple traversed by the traffic between a source and a destination beyond a simple
numerical value, which allows the overlay application to distinguish between numerical value, which allows the overlay application to distinguish between
Cases 1 and 2 and to compute the optimal total rate accordingly.</li> Cases 1 and 2 and to compute the optimal total rate accordingly.</li>
<li>The ALTO server must allow the client to distinguish the common AN E shared by <li>The ALTO server must allow the client to distinguish the common AN E shared by
"eh1 -&gt; eh2" and "eh1 -&gt; eh4", e.g., "eh1 - sw1" and "sw1 - sw5" in Case 1 .</li> "eh1 -&gt; eh2" and "eh1 -&gt; eh4", e.g., "eh1&nbhy;&nbhy;sw1" and "sw1&nbhy;&n bhy;sw5" in Case 1.</li>
<li>The ALTO server must expose abstract information on the properties of the <li>The ALTO server must expose abstract information on the properties of the
ANEs used by "eh1 -&gt; eh2" and "eh1 -&gt; eh4". For example, an ALTO server ca n ANEs used by "eh1 -&gt; eh2" and "eh1 -&gt; eh4". For example, an ALTO server ca n
either expose the available bandwidth between "eh1 - sw1", "sw1 - sw5", "sw5 - either expose the available bandwidth between "eh1&nbhy;&nbhy;sw1", "sw1&nbhy;&n
sw7", "sw5 - sw6", "sw6 - sw7", "sw7 - sw2", "sw7 - sw4", "sw2 - eh2", "sw4 - bhy;sw5", "sw5&nbhy;&nbhy;sw7", "sw5&nbhy;&nbhy;sw6", "sw6&nbhy;&nbhy;sw7", "sw7
eh4" in Case 1, or expose 3 abstract elements "A", "B" and "C", which &nbhy;&nbhy;sw2", "sw7&nbhy;&nbhy;sw4", "sw2&nbhy;&nbhy;eh2", "sw4&nbhy;&nbhy;eh
4" in Case 1 or expose three abstract elements "A", "B", and "C", which
represent the linear constraints that define the same capacity region in Case represent the linear constraints that define the same capacity region in Case
1.</li> 1.</li>
</ul> </ul>
<t>In general, we can conclude that to support the multiple flow schedul <t>In general, we can conclude that to support the use case for multiple
ing flow scheduling, the ALTO framework must be extended to satisfy the following
use case, the ALTO framework must be extended to satisfy the following additional requirements (ARs):</t>
additional requirements:</t>
<dl> <dl>
<dt> <dt>
AR1: </dt> AR1: </dt>
<dd> <dd>
<t>An ALTO server must provide the ANEs that are important to assess the QoE of <t>An ALTO server must provide the ANEs that are important for asses sing the QoE of
the overlay application on the path of a &lt;source, destination&gt; pair.</t> the overlay application on the path of a &lt;source, destination&gt; pair.</t>
</dd> </dd>
<dt> <dt>
AR2: </dt> AR2: </dt>
<dd> <dd>
<t>An ALTO server must provide information to identify how ANEs are shared on the <t>An ALTO server must provide information to identify how ANEs are shared on the
paths of different &lt;source, destination&gt; pairs.</t> paths of different &lt;source, destination&gt; pairs.</t>
</dd> </dd>
<dt> <dt>
AR3: </dt> AR3: </dt>
<dd> <dd>
<t>An ALTO server must provide information on the properties that ar e important <t>An ALTO server must provide information on the properties that ar e important
to assess the QoE of the application for ANEs.</t> for assessing the QoE of the application for ANEs.</t>
</dd> </dd>
</dl> </dl>
<t>The extension defined in this document specifies a solution to expose such <t>The extension defined in this document specifies a solution to expose such
abstract information.</t> abstract information.</t>
</section> </section>
<section anchor="sample-use-cases" numbered="true" toc="default"> <section anchor="sample-use-cases" numbered="true" toc="default">
<name>Sample Use Cases</name> <name>Sample Use Cases</name>
<t>While the multiple flow scheduling problem is used to help identify t he <t>While the problem related to multiple flow scheduling is used to help identify the
additional requirements, the extension defined in this document can be applied additional requirements, the extension defined in this document can be applied
to a wide range of applications. This section highlights some use cases that are to a wide range of applications. This section highlights some of the reported us
reported.</t> e cases.</t>
<section anchor="exposing-network-bottlenecks" numbered="true" toc="defa ult"> <section anchor="exposing-network-bottlenecks" numbered="true" toc="defa ult">
<name>Exposing Network Bottlenecks</name> <name>Exposing Network Bottlenecks</name>
<t>An important use case of the Path Vector extension is to expose net <t>One important use case for the Path Vector extension is to expose n
work etwork
bottlenecks. Applications which need to perform large scale data transfers can bottlenecks. Applications that need to perform large-scale data transfers can
benefit from being aware of the resource constraints exposed by this extension benefit from being aware of the resource constraints exposed by this extension
even if they have different objectives. One such example is the Worldwide LHC even if they have different objectives. One such example is the Worldwide LHC
Computing Grid (WLCG), the largest example of a distributed computation Computing Grid (WLCG) (where "LHC" means "Large Hadron Collider"), which is the largest example of a distributed computation
collaboration in the research and education world.</t> collaboration in the research and education world.</t>
<t><xref target="fig-da" format="default"/> illustrates an example of using ALTO Path Vector as an interface <t><xref target="fig-da" format="default"/> illustrates an example of using an ALTO Path Vector as an interface
between the job optimizer for a data analytics system and the network manager. between the job optimizer for a data analytics system and the network manager.
In particular, we assume the objective of the job optimizer is to minimize the In particular, we assume that the objective of the job optimizer is to minimize the
job completion time.</t> job completion time.</t>
<t>In such a setting, the network-aware job optimizer (e.g., <xref tar get="CLARINET" format="default"/>) takes a <t>In such a setting, the network-aware job optimizer (e.g., <xref tar get="CLARINET" format="default"/>) takes a
query and generates multiple query execution plans (QEP). It can encode the QEPs query and generates multiple query execution plans (QEPs). It can encode the QEP
as Path Vector requests that are send to an ALTO server. The ALTO server obtains s
as Path Vector requests that are sent to an ALTO server. The ALTO server obtains
the routing information for the flows in a QEP and finds links, routers, or the routing information for the flows in a QEP and finds links, routers, or
middleboxes (e.g., a stateful firewall) that can potentially become bottlenecks middleboxes (e.g., a stateful firewall) that can potentially become bottlenecks
of the QEP (e.g., see <xref target="NOVA" format="default"/> and <xref target="G 2" format="default"/> for mechanisms to identify bottleneck for the QEP (e.g., see <xref target="NOVA" format="default"/> and <xref target=" G2" format="default"/> for mechanisms to identify bottleneck
links under different settings). The resource constraint information is encoded links under different settings). The resource constraint information is encoded
in a Path Vector response and returned to the ALTO client.</t> in a Path Vector response and returned to the ALTO client.</t>
<t>With the network resource constraints, the job optimizer may choose the QEP with <t>With the network resource constraints, the job optimizer may choose the QEP with
the optimal job completion time to be executed. It must be noted that the ALTO the optimal job completion time to be executed. It must be noted that the ALTO
framework itself does not offer the capability to control the traffic. However, framework itself does not offer the capability to control the traffic. However,
certain network managers may offer ways to enforce resource guarantees, such as certain network managers may offer ways to enforce resource guarantees, such as
on-demand tunnels (e.g., <xref target="SWAN" format="default"/>), demand vector on-demand tunnels (e.g., <xref target="SWAN" format="default"/>), demand vectors
(e.g., <xref target="HUG" format="default"/>, <xref target="UNICORN" format="def (e.g., <xref target="HUG" format="default"/>, <xref target="UNICORN" format="de
ault"/>), fault"/>),
etc. The traffic control interfaces and mechanisms are out of the scope of this etc. The traffic control interfaces and mechanisms are out of scope for this
document.</t> document.</t>
<figure anchor="fig-da"> <figure anchor="fig-da">
<name>Example Use Case for Data Analytics</name> <name>Example Use Case for Data Analytics</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
Data schema Queries Data schema Queries
| | | |
\ / \ /
+-------------+ +-----------------+ +-------------+ +-----------------+
| ALTO Client | <===============> | Job Optimizer | | ALTO Client | <===============> | Job Optimizer |
+-------------+ +-----------------+ +-------------+ +-----------------+
PV | ^ PV | PV | ^ PV |
Request | | Response | Request | | Response |
| | On-demand resource | | | On-demand resource |
(Data | | (Network allocation, demand | (Potential | | (Network allocation, demand |
Transfer | | Resource vector, etc. | Data | | Resource vectors, etc. |
Intents) | | Constraints) (Non-ALTO interfaces)| Transfers) | | Constraints) (Non-ALTO interfaces)|
v | v v | v
+-------------+ +-----------------+ +-------------+ +-----------------+
| ALTO Server | <===============> | Network Manager | | ALTO Server | <===============> | Network Manager |
+-------------+ +-----------------+ +-------------+ +-----------------+
/ | \ / | \
| | | | | |
WAN DC1 DC2 WAN DC1 DC2
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Another example is as illustrated in <xref target="fig-dts" format= "default"/>. Consider a network consisting <t>Another example is illustrated in <xref target="fig-dts" format="de fault"/>. Consider a network consisting
of multiple sites and a non-blocking core network, i.e., the links in the core of multiple sites and a non-blocking core network, i.e., the links in the core
network have sufficient bandwidth that they will not become the bottleneck of network have sufficient bandwidth that they will not become a bottleneck for
the data transfers.</t> the data transfers.</t>
<figure anchor="fig-dts"> <figure anchor="fig-dts">
<name>Example Use Case for Cross-site Bottleneck Discovery</name> <name>Example Use Case for Cross-Site Bottleneck Discovery</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
On-going transfers New transfer requests Ongoing transfers New transfer requests
\----\ | \----\ |
| | | |
v v v v
+-------------+ +---------------+ +-------------+ +---------------+
| ALTO Client | <===========> | Data Transfer | | ALTO Client | <===========> | Data Transfer |
+-------------+ | Scheduler | +-------------+ | Scheduler |
^ | ^ | PV request +---------------+ ^ | ^ | PV Request +---------------+
| | | \--------------\ | | | \--------------\
| | \--------------\ | | | \--------------\ |
| v PV response | v | v PV Response | v
+-------------+ +-------------+ +-------------+ +-------------+
| ALTO Server | | ALTO Server | | ALTO Server | | ALTO Server |
+-------------+ +-------------+ +-------------+ +-------------+
|| || || ||
+---------+ +---------+ +---------+ +---------+
| Network | | Network | | Network | | Network |
| Manager | | Manager | | Manager | | Manager |
+---------+ +---------+ +---------+ +---------+
. . . .
. _~_ __ . . . . _~_ __ . . .
. ( )( ) .___ . ( )( ) .___
~v~v~ /--( )------------( ) ~v~v~ /--( )------------( )
( )-----/ ( ) ( ) ( )-----/ ( ) ( )
~w~w~ ~^~^~^~ ~v~v~ ~w~w~ ~^~^~^~ ~v~v~
Site 1 Non-blocking Core Site 2 Site 1 Non-blocking Core Site 2
]]></artwork> ]]></artwork>
</figure> </figure>
<t>With the Path Vector extension, a site can reveal the bottlenecks i
nside its own
network with necessary information (such as link capacities) to the ALTO client,
instead of providing the full topology and routing information, or no bottleneck
information at all. The bottleneck information can be used to analyze the impact
of adding/removing data transfer flows, e.g., using the framework defined in <xr
ef target="G2" format="default"/>. For
example, assume that hosts "a", "b", and "c" are in Site 1 and hosts "d", "e", a
nd "f" are in
Site 2, and there are three flows in two sites: "a -&gt; b", "c -&gt; d", and "e
-&gt; f" (<xref target="fig-sbot"/>).</t>
<figure anchor="fig-sbot"> <figure anchor="fig-sbot">
<name>Example: Three Flows in Two Sites</name> <name>Example: Three Flows in Two Sites</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
Site 1: Site 1:
[c] [c]
. .
........................................> [d] ........................................> [d]
+---+ 10 Gbps +---+ 10 Gbps +----+ 50 Gbps +---+ 10 Gbps +---+ 10 Gbps +----+ 50 Gbps
| A |---------| B |---------| GW |--------- Core | A |---------| B |---------| GW |--------- Core
skipping to change at line 532 skipping to change at line 543
[d] <........................................ [c] [d] <........................................ [c]
+---+ 5 Gbps +---+ 10 Gbps +----+ 20 Gbps +---+ 5 Gbps +---+ 10 Gbps +----+ 20 Gbps
| X |--------| Y |---------| GW |--------- Core | X |--------| Y |---------| GW |--------- Core
+---+ +---+ +----+ +---+ +---+ +----+
.................... ....................
. . . .
. v . v
[e] [f] [e] [f]
]]></artwork> ]]></artwork>
</figure> </figure>
<t>With the Path Vector extension, a site can reveal the bottlenecks i <t>For
nside its own these flows, Site 1 returns:</t>
network with necessary information (such as link capacities) to the ALTO client,
instead of providing the full topology and routing information, or no bottleneck <sourcecode name="" type=""><![CDATA[
information at all. The bottleneck information can be used to analyze the impact
of adding/removing data transfer flows, e.g., using the <xref target="G2" format
="default"/> framework. For
example, assume hosts "a", "b", "c" are in site 1 and hosts "d", "e", "f" are in
site 2, and there are 3 flows in two sites: "a -&gt; b", "c -&gt; d", "e -&gt; f
". For
these flows, site 1 returns:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
a: { b: [ane1] }, a: { b: [ane1] },
c: { d: [ane1, ane2, ane3] } c: { d: [ane1, ane2, ane3] }
ane1: bw = 10 Gbps (link: A->B) ane1: bw = 10 Gbps (link: A->B)
ane2: bw = 10 Gbps (link: B->GW) ane2: bw = 10 Gbps (link: B->GW)
ane3: bw = 50 Gbps (link: GW->Core) ane3: bw = 50 Gbps (link: GW->Core)
]]></artwork> ]]></sourcecode>
<t>and site 2 returns:</t> <t>and Site 2 returns:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode name="" type=""><![CDATA[
c: { d: [anei, aneii, aneiii] } c: { d: [anei, aneii, aneiii] }
e: { f: [aneiv] } e: { f: [aneiv] }
anei: bw = 5 Gbps (link Y->X) anei: bw = 5 Gbps (link Y->X)
aneii: bw = 10 Gbps (link GW->Y) aneii: bw = 10 Gbps (link GW->Y)
aneiii: bw = 20 Gbps (link Core->GW) aneiii: bw = 20 Gbps (link Core->GW)
aneiv: bw = 10 Gbps (link Y->GW) aneiv: bw = 10 Gbps (link Y->GW)
]]></artwork> ]]></sourcecode>
<t>With the information, the data transfer scheduler can use algorithm <t>With this information, the data transfer scheduler can use algorith
s such as the ms such as the
theory on bottleneck structure <xref target="G2" format="default"/> to predict t he potential throughput of the theory on bottleneck structure <xref target="G2" format="default"/> to predict t he potential throughput of the
flows.</t> flows.</t>
</section> </section>
<section anchor="resource-exposure-for-cdn-and-service-edge" numbered="t rue" toc="default"> <section anchor="resource-exposure-for-cdn-and-service-edge" numbered="t rue" toc="default">
<name>Resource Exposure for CDN and Service Edge</name> <name>Resource Exposure for CDNs and Service Edges</name>
<t>A growing trend in today's applications (2021) is to bring storage <t>At the time of this writing, a growing trend in today's application
and computation s is to bring storage and computation
closer to the end users for better QoE, such as Content Delivery Network (CDN), closer to the end users for better QoE, such as CDNs,
AR/VR, and cloud gaming, as reported in various documents (e.g., <xref target="S augmented reality / virtual reality, and cloud gaming, as reported in various do
EREDGE" format="default"/> and cuments (e.g., <xref target="SEREDGE" format="default"/> and
<xref target="MOWIE" format="default"/>). Internet Service Providers may deploy <xref target="MOWIE" format="default"/>). ISPs may deploy multiple layers of CDN
multiple layers of CDN caches, caches
or more generally service edges, with different latency and available resources or, more generally, service edges, with different latencies and available resour
including number of CPU cores, memory, and storage.</t> ces,
including the number of CPU cores, memory, and storage.</t>
<t>For example, <xref target="fig-se" format="default"/> illustrates a typical edge-cloud scenario where memory <t>For example, <xref target="fig-se" format="default"/> illustrates a typical edge-cloud scenario where memory
is measured in Gigabytes (G) and storage is measured in Terabytes (T). The is measured in gigabytes (GB) and storage is measured in terabytes (TB). The
"on-premise" edge nodes are closest to the end hosts and have the smallest "on-premise" edge nodes are closest to the end hosts and have the lowest
latency, and the site-radio edge node and access central office (CO) have larger latency, and the site-radio edge node and access central office (CO) have higher
latency but more available resources.</t> latencies but more available resources.</t>
<figure anchor="fig-se"> <figure anchor="fig-se">
<name>Example Use Case for Service Edge Exposure</name> <name>Example Use Case for Service Edge Exposure</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
+-------------+ +----------------------+ +-------------+ +----------------------+
| ALTO Client | <==========> | Application Provider | | ALTO Client | <==========> | Application Provider |
+-------------+ +----------------------+ +-------------+ +----------------------+
PV | ^ PV | PV | ^ PV |
Request | | Response | Resource allocation, Request | | Response | Resource allocation,
| | | service establishment, | | | service establishment,
(End hosts | | (Edge nodes | etc. (End hosts | | (Edge nodes | etc.
skipping to change at line 614 skipping to change at line 620
| / | /
Site-radio /_\ / Site-radio /_\ /
Edge Node 2(/\_/\)-----/ Edge Node 2(/\_/\)-----/
/(_____)\ /(_____)\
___ / \ --- ___ / \ ---
b--|_| -/ \--|_|--c b--|_| -/ \--|_|--c
/---\ /---\ /---\ /---\
On premise On premise On premise On premise
]]></artwork> ]]></artwork>
</figure> </figure>
<t>With the extension defined in this document, an ALTO server can sel
ectively
reveal the CDNs and service edges that reside along the paths between different
end hosts and/or the cloud servers, together with their properties
(e.g., storage capabilities or Graphics Processing Unit (GPU) capabilities) and
available Service Level Agreement (SLA)
plans. See <xref target="fig-se-example" format="default"/> for an example where
the query is made for sources
[a, b] and destinations [b, c, DC]. Here, each ANE represents a service edge, an
d
the properties include access latency, available resources, etc. Note that the
properties here are only used for illustration purposes and are not part of this
extension.</t>
<figure anchor="fig-se-example"> <figure anchor="fig-se-example">
<name>Example Service Edge Query Results</name> <name>Example Service Edge Query Results</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode name="" type=""><![CDATA[
a: { b: [ane1, ane2, ane3, ane4, ane5], a: { b: [ane1, ane2, ane3, ane4, ane5],
c: [ane1, ane2, ane3, ane4, ane6], c: [ane1, ane2, ane3, ane4, ane6],
DC: [ane1, ane2, ane3] } DC: [ane1, ane2, ane3] }
b: { c: [ane5, ane4, ane6], DC: [ane5, ane4, ane3] } b: { c: [ane5, ane4, ane6], DC: [ane5, ane4, ane3] }
ane1: latency=5ms cpu=2 memory=8G storage=10T ane1: latency = 5 ms cpu = 2 memory = 8 GB storage = 10 TB
(on premise, a) (On premise, a)
ane2: latency=20ms cpu=4 memory=8G storage=10T ane2: latency = 20 ms cpu = 4 memory = 8 GB storage = 10 TB
(Site-radio Edge Node 1) (Site-radio Edge Node 1)
ane3: latency=100ms cpu=8 memory=128G storage=100T ane3: latency = 100 ms cpu = 8 memory = 128 GB storage = 100 TB
(Access CO) (Access CO)
ane4: latency=20ms cpu=4 memory=8G storage=10T ane4: latency = 20 ms cpu = 4 memory = 8 GB storage = 10 TB
(Site-radio Edge Node 2) (Site-radio Edge Node 2)
ane5: latency=5ms cpu=2 memory=8G storage=10T ane5: latency = 5 ms cpu = 2 memory = 8 GB storage = 10 TB
(on premise, b) (On premise, b)
ane6: latency=5ms cpu=2 memory=8G storage=10T ane6: latency = 5 ms cpu = 2 memory = 8 GB storage = 10 TB
(on premise, c) (On premise, c)
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t>With the extension defined in this document, an ALTO server can sel
ectively
reveal the CDNs and service edges that reside along the paths between different
end hosts and/or the cloud servers, together with their properties such as
capabilities (e.g., storage, GPU) and available Service Level Agreement (SLA)
plans. See <xref target="fig-se-example" format="default"/> for an example where
the query is made for sources
[a, b] and destinations [b, c, DC]. Here each ANE represents a service edge and
the properties include access latency, available resources, etc. Note the
properties here are only used for illustration purposes and are not part of this
extension.</t>
<t>With the service edge information, an ALTO client may better conduc t CDN request <t>With the service edge information, an ALTO client may better conduc t CDN request
routing or offload functionalities from the user equipment to the service edge, routing or offload functionalities from the user equipment to the service edge,
with considerations on customized quality of experience.</t> with considerations in place for customized quality of experience.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="Overview" numbered="true" toc="default"> <section anchor="Overview" numbered="true" toc="default">
<name>Path Vector Extension: Overview</name> <name>Path Vector Extension: Overview</name>
<t>This section provides a non-normative overview of the Path Vector exten sion <t>This section provides a non-normative overview of the Path Vector exten sion
defined in this document. It is assumed that the readers are familiar with both defined in this document. It is assumed that readers are familiar with both
the base protocol <xref target="RFC7285" format="default"/> and the Unified Prop the base protocol <xref target="RFC7285" format="default"/> and the entity prope
erty Map extension rty map extension
<xref target="I-D.ietf-alto-unified-props-new" format="default"/>.</t> <xref target="RFC9240" format="default"/>.</t>
<t>To satisfy the additional requirements listed in Section 4.1, this exte <t>To satisfy the additional requirements listed in <xref target="design-r
nsion:</t> equirements"/>, this extension:</t>
<ol spacing="normal" type="1"><li>introduces the concept of Abstract Netwo <ol spacing="normal" type="1"><li>introduces the concept of an ANE as the
rk Element (ANE) as the abstraction abstraction
of components in a network whose properties may have an impact on the of components in a network whose properties may have an impact on
end-to-end performance of the traffic handled by those components,</li> end-to-end performance of the traffic handled by those components,</li>
<li>extends the Cost Map and Endpoint Cost Service to convey the ANEs tr aversed <li>extends the cost map and Endpoint Cost Service to convey the ANEs tr aversed
by the path of a &lt;source, destination&gt; pair as Path Vectors, and</li> by the path of a &lt;source, destination&gt; pair as Path Vectors, and</li>
<li>uses the Unified Property Map to convey the association between the <li>uses the entity property map to convey the association between the
ANEs and their properties.</li> ANEs and their properties.</li>
</ol> </ol>
<t>Thus, an ALTO client can learn about the ANEs that are important to ass ess the <t>Thus, an ALTO client can learn about the ANEs that are important for as sessing the
QoE of different &lt;source, destination&gt; pairs by investigating the correspo nding QoE of different &lt;source, destination&gt; pairs by investigating the correspo nding
Path Vector value (AR1), identify common ANEs if an ANE appears in the Path Path Vector value (AR1) and can also (1)&nbsp;identify common ANEs if an ANE app
Vectors of multiple &lt;source, destination&gt; pairs (AR2), and retrieve the ears in the Path Vectors of multiple &lt;source, destination&gt; pairs (AR2) and
properties of the ANEs by searching the Unified Property Map (AR3).</t> (2)&nbsp;retrieve the properties of the ANEs by searching the entity property ma
p (AR3).</t>
<section anchor="ane-design" numbered="true" toc="default"> <section anchor="ane-design" numbered="true" toc="default">
<name>Abstract Network Element (ANE)</name> <name>Abstract Network Element (ANE)</name>
<t>This extension introduces ANE as an indirect and network-agnostic way to specify <t>This extension introduces the ANE as an indirect and network-agnostic way to specify
a component or an aggregation of components of a network whose properties have a component or an aggregation of components of a network whose properties have
an impact on the end-to-end performance for application traffic between an impact on end-to-end performance for application traffic between
endpoints.</t> endpoints.</t>
<t>ANEs allow ALTO servers to focus on common properties of different ty pes of <t>ANEs allow ALTO servers to focus on common properties of different ty pes of
network components. For example, the throughput of a flow can be constrained by network components. For example, the throughput of a flow can be constrained by
different components in a network: the capacity of a physical link, the maximum different components in a network: the capacity of a physical link, the maximum
throughput of a firewall, the reserved bandwidth of an MPLS tunnel, etc. See the throughput of a firewall, the reserved bandwidth of an MPLS tunnel, etc. In the
example below, assume the throughput of the firewall is 100 Mbps and the example below, assume that the throughput of the firewall is 100 Mbps and the
capacity for link (A, B) is also 100 Mbps, they result in the same constraint on capacity for link (A, B) is also 100 Mbps; they result in the same constraint on
the total throughput of f1 and f2. Thus, they are identical when treated as an the total throughput of f1 and f2. Thus, they are identical when treated as an
ANE.</t> ANE.</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
f1 | ^ f1 f1 | ^ f1
| | -----------------> | | ----------------->
+----------+ +---+ +---+ +----------+ +---+ +---+
| Firewall | | A |-----| B | | Firewall | | A |-----| B |
+----------+ +---+ +---+ +----------+ +---+ +---+
| | -----------------> | | ----------------->
v | f2 f2 v | f2 f2
]]></artwork> ]]></artwork>
<t>When an ANE is defined by an ALTO server, it is assigned an identifie r by the <t>When an ANE is defined by an ALTO server, it is assigned an identifie r by the
ALTO server, i.e., a string of type ANEName as specified in <xref target="ane-na me-spec" format="default"/>, ALTO server, i.e., a string of type ANEName as specified in <xref target="ane-na me-spec" format="default"/>,
and a set of associated properties.</t> and a set of associated properties.</t>
<section anchor="ane-entity-domain" numbered="true" toc="default"> <section anchor="ane-entity-domain" numbered="true" toc="default">
<name>ANE Entity Domain</name> <name>ANE Entity Domain</name>
<t>In this extension, the associations between ANE and the properties <t>In this extension, the associations between ANEs and their properti
are conveyed es are conveyed
in a Unified Property Map. Thus, ANEs must constitute an entity domain (Section in an entity property map. &nbsp;Thus, ANEs must constitute an "entity domain" (
5.1 of <xref target="I-D.ietf-alto-unified-props-new" format="default"/>), and e <xref target="RFC9240" sectionFormat="of" section="5.1"/>), and each ANE propert
ach ANE property must be an y must be an
entity property (Section 5.2 of <xref target="I-D.ietf-alto-unified-props-new" f entity property (<xref target="RFC9240" sectionFormat="of" section="5.2"/>).</t>
ormat="default"/>).</t>
<t>Specifically, this document defines a new entity domain called "ane " as <t>Specifically, this document defines a new entity domain called "ane " as
specified in <xref target="ane-domain-spec" format="default"/> and defines two i nitial properties for the ANE specified in <xref target="ane-domain-spec" format="default"/>; <xref target="in itial-ane-property-types"/> defines two initial property types for the ANE
entity domain.</t> entity domain.</t>
</section> </section>
<section anchor="assoc" numbered="true" toc="default"> <section anchor="assoc" numbered="true" toc="default">
<name>Ephemeral and Persistent ANEs</name> <name>Ephemeral and Persistent ANEs</name>
<t>By design, ANEs are ephemeral and not to be used in further request s to other <t>By design, ANEs are ephemeral and not to be used in further request s to other
ALTO resources. More precisely, the corresponding ANE names are no longer valid ALTO resources. More precisely, the corresponding ANE names are no longer valid
beyond the scope of a Path Vector response or the incremental update stream beyond the scope of a Path Vector response or the incremental update stream
for a Path Vector request. Compared with globally unique ANE names, ephemeral for a Path Vector request. Compared with globally unique ANE names, ephemeral
ANE has several benefits including better privacy of the ISP's internal ANEs have several benefits, including better privacy for the ISP's internal
structure and more flexible ANE computation.</t> structure and more flexible ANE computation.</t>
<t>For example, an ALTO server may define an ANE for each aggregated b ottleneck <t>For example, an ALTO server may define an ANE for each aggregated b ottleneck
link between the sources and destinations specified in the request. For requests link between the sources and destinations specified in the request. For requests
with different sources and destinations, the bottlenecks may be different but with different sources and destinations, the bottlenecks may be different but
can safely reuse the same ANE names. The client can still adjust its traffic can safely reuse the same ANE names. The client can still adjust its traffic
based on the information but is difficult to infer the underlying topology with based on the information, but it is difficult to infer the underlying topology w ith
multiple queries.</t> multiple queries.</t>
<t>However, sometimes an ISP may intend to selectively reveal some "pe rsistent" <t>However, sometimes an ISP may intend to selectively reveal some "pe rsistent"
network components which, opposite to being ephemeral, have a longer life cycle. network components that, as opposed to being ephemeral, have a longer life cycle .
For example, an ALTO server may define an ANE for each service edge cluster. For example, an ALTO server may define an ANE for each service edge cluster.
Once a client chooses to use a service edge, e.g., by deploying some Once a client chooses to use a service edge, e.g., by deploying some
user-defined functions, it may want to stick to the service edge to avoid the user-defined functions, it may want to stick to the service edge to avoid the
complexity of state transition or synchronization, and continuously query the complexity of state transition or synchronization, and continuously query the
properties of the edge cluster.</t> properties of the edge cluster.</t>
<t>This document provides a mechanism to expose such network component s as <t>This document provides a mechanism to expose such network component s as
persistent ANEs. A persistent ANE has a persistent ID that is registered in a persistent ANEs. A persistent ANE has a persistent ID that is registered in a
Property Map, together with their properties. See <xref target="domain-defining" property map, together with its properties. See Sections&nbsp;<xref target="doma
format="default"/> and in-defining" format="counter"/> and
<xref target="persistent-entity-id" format="default"/> for more detailed instruc <xref target="persistent-entity-id" format="counter"/> for more detailed instruc
tions on how to identify tions on how to identify
ephemeral ANEs and persistent ANEs.</t> ephemeral ANEs and persistent ANEs.</t>
</section> </section>
<section anchor="property-filtering" numbered="true" toc="default"> <section anchor="property-filtering" numbered="true" toc="default">
<name>Property Filtering</name> <name>Property Filtering</name>
<t>Resource-constrained ALTO clients (see Section 4.1.2 of <xref targe t="RFC7285" format="default"/>) may benefit <t>Resource-constrained ALTO clients (see <xref target="RFC7285" secti onFormat="of" section="4.1.2"/>) may benefit
from the filtering of Path Vector query results at the ALTO server, as an ALTO from the filtering of Path Vector query results at the ALTO server, as an ALTO
client may only require a subset of the available properties.</t> client may only require a subset of the available properties.</t>
<t>Specifically, the available properties for a given resource are ann ounced in the <t>Specifically, the available properties for a given resource are ann ounced in the
Information Resource Directory as a new capability called "ane-property-names". Information Resource Directory (IRD) as a new filtering capability called "ane-p roperty-names".
The properties selected by a client as being of interest are specified in the The properties selected by a client as being of interest are specified in the
subsequent Path Vector queries using the filter called 'ane-property-names'. The subsequent Path Vector queries using the "ane-property-names" filter. The
response includes and only includes the selected properties for the ANEs in the response only includes the selected properties for the ANEs.</t>
response.</t> <t>The "ane-property-names" capability for the cost map and the Endpoi
<t>The "ane-property-names" capability for Cost Map and for Endpoint C nt Cost Service
ost Service is specified in Sections&nbsp;<xref target="pvcm-cap" format="counter"/> and <xr
is specified in <xref target="pvcm-cap" format="default"/> and <xref target="pve ef target="pvecs-cap" format="counter"/>, respectively. The
cs-cap" format="default"/> respectively. The "ane-property-names" filter for the cost map and the Endpoint Cost Service is sp
"ane-property-names" filter for Cost Map and Endpoint Cost Service is specified ecified
in <xref target="pvcm-accept" format="default"/> and <xref target="pvecs-accept" in Sections&nbsp;<xref target="pvcm-accept" format="counter"/> and <xref target=
format="default"/> accordingly.</t> "pvecs-accept" format="counter"/> accordingly.</t>
</section> </section>
</section> </section>
<section anchor="path-vector-design" numbered="true" toc="default"> <section anchor="path-vector-design" numbered="true" toc="default">
<name>Path Vector Cost Type</name> <name>Path Vector Cost Type</name>
<t>For an ALTO client to correctly interpret the Path Vector, this exten sion <t>For an ALTO client to correctly interpret the Path Vector, this exten sion
specifies a new cost type called the Path Vector cost type.</t> specifies a new cost type called the "Path Vector cost type".</t>
<t>The Path Vector cost type must convey both the interpretation and sem antics in <t>The Path Vector cost type must convey both the interpretation and sem antics in
the "cost-mode" and "cost-metric" respectively. Unfortunately, a single the "cost-mode" and "cost-metric" parameters, respectively. Unfortunately, a sin gle
"cost-mode" value cannot fully specify the interpretation of a Path Vector, "cost-mode" value cannot fully specify the interpretation of a Path Vector,
which is a compound data type. For example, in programming languages such as C++ which is a compound data type. For example, in programming languages such as C++
where there existed a JSON array type named JSONArray, a Path Vector will have ,
if there existed a JSON array type named JSONArray, a Path Vector would have
the type of <tt>JSONArray&lt;ANEName&gt;</tt>.</t> the type of <tt>JSONArray&lt;ANEName&gt;</tt>.</t>
<t>Instead of extending the "type system" of ALTO, this document takes a simple <t>Instead of extending the "type system" of ALTO, this document takes a simple
and backward compatible approach. Specifically, the "cost-mode" of the Path and backward-compatible approach. Specifically, the "cost-mode" of the Path
Vector cost type is "array", which indicates the value is a JSON array. Then, an Vector cost type is "array", which indicates that the value is a JSON array. The
ALTO client must check the value of the "cost-metric". If the value is n, an
ALTO client must check the value of the "cost-metric" parameter. If the value is
"ane-path", it means that the JSON array should be further interpreted as a path "ane-path", it means that the JSON array should be further interpreted as a path
of ANENames.</t> of ANENames.</t>
<t>The Path Vector cost type is specified in <xref target="cost-type-spe c" format="default"/>.</t> <t>The Path Vector cost type is specified in <xref target="cost-type-spe c" format="default"/>.</t>
</section> </section>
<section anchor="multipart-path-vector-response" numbered="true" toc="defa ult"> <section anchor="multipart-path-vector-response" numbered="true" toc="defa ult">
<name>Multipart Path Vector Response</name> <name>Multipart Path Vector Response</name>
<t>For a basic ALTO information resource, a response contains only one t ype of <t>For a basic ALTO information resource, a response contains only one t ype of
ALTO resources, e.g., Network Map, Cost Map, or Property Map. Thus, only one ALTO resource, e.g., network map, cost map, or property map. &nbsp;Thus, only on
round of communication is required: An ALTO client sends a request to an ALTO e
round of communication is required: an ALTO client sends a request to an ALTO
server, and the ALTO server returns a response, as shown in <xref target="fig-al to" format="default"/>.</t> server, and the ALTO server returns a response, as shown in <xref target="fig-al to" format="default"/>.</t>
<figure anchor="fig-alto"> <figure anchor="fig-alto">
<name>A Typical ALTO Request and Response</name> <name>A Typical ALTO Request and Response</name>
<artwork type="drawing" align="center" name="" alt=""><![CDATA[ <artwork type="" align="center" name="" alt=""><![CDATA[
ALTO client ALTO server ALTO client ALTO server
|-------------- Request ---------------->| |-------------- Request ---------------->|
|<------------- Response ----------------| |<------------- Response ----------------|
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The extension defined in this document, on the other hand, involves t wo types of <t>The extension defined in this document, on the other hand, involves t wo types of
information resources: Path Vectors conveyed in an InfoResourceCostMap (defined information resources: Path Vectors conveyed in an InfoResourceCostMap data comp
in Section 11.2.3.6 of <xref target="RFC7285" format="default"/>) or an InfoReso onent (defined
urceEndpointCostMap (defined in <xref target="RFC7285" sectionFormat="of" section="11.2.3.6"/>) or an InfoRes
in Section 11.5.1.6 of <xref target="RFC7285" format="default"/>), and ANE prope ourceEndpointCostMap data component (defined
rties conveyed in an in <xref target="RFC7285" sectionFormat="of" section="11.5.1.6"/>), and ANE prop
InfoResourceProperties (defined in Section 7.6 of <xref target="I-D.ietf-alto-un erties conveyed in an
ified-props-new" format="default"/>).</t> InfoResourceProperties data component (defined in <xref target="RFC9240" section
Format="of" section="7.6"/>).</t>
<t>Instead of two consecutive message exchanges, the extension defined i n this <t>Instead of two consecutive message exchanges, the extension defined i n this
document enforces one round of communication. Specifically, the ALTO client must document enforces one round of communication. Specifically, the ALTO client must
include the source and destination pairs and the requested ANE properties in a include the source and destination pairs and the requested ANE properties in a
single request, and the ALTO server must return a single response containing single request, and the ALTO server must return a single response containing
both the Path Vectors and properties associated with the ANEs in the Path both the Path Vectors and properties associated with the ANEs in the Path
Vectors, as shown in <xref target="fig-pv" format="default"/>. Since the two par ts are bundled together in one Vectors, as shown in <xref target="fig-pv" format="default"/>. Since the two par ts are bundled together in one
response message, their orders are interchangeable. See <xref target="pvcm-resp" response message, their orders are interchangeable. See Sections&nbsp;<xref targ
format="default"/> and et="pvcm-resp" format="counter"/> and
<xref target="pvecs-resp" format="default"/> for details.</t> <xref target="pvecs-resp" format="counter"/> for details.</t>
<figure anchor="fig-pv"> <figure anchor="fig-pv">
<name>The Path Vector Extension Request and Response</name> <name>The Path Vector Extension Request and Response</name>
<artwork type="drawing" align="center" name="" alt=""><![CDATA[ <artwork type="" align="center" name="" alt=""><![CDATA[
ALTO client ALTO server ALTO client ALTO server
|------------- PV Request -------------->| |------------- PV Request -------------->|
|<----- PV Response (Cost Map Part) -----| |<----- PV Response (Cost Map Part) -----|
|<--- PV Response (Property Map Part) ---| |<--- PV Response (Property Map Part) ---|
]]></artwork> ]]></artwork>
</figure> </figure>
<t>This design is based on the following considerations:</t> <t>This design is based on the following considerations:</t>
<ol spacing="normal" type="1"><li>ANEs may be constructed on demand, and <ol spacing="normal" type="1"><li>ANEs may be constructed on demand and,
potentially based on the potentially, based on the
requested properties (See <xref target="ane-design" format="default"/> for more requested properties (see <xref target="ane-design" format="default"/> for more
details). If sources and details). If sources and
destinations are not in the same request as the properties, an ALTO server destinations are not in the same request as the properties, an ALTO server
either cannot construct ANEs on-demand, or must wait until both requests are either cannot construct ANEs on demand or must wait until both requests are
received.</li> received.</li>
<li>As ANEs may be constructed on demand, mappings of each ANE to its underlying <li>As ANEs may be constructed on demand, mappings of each ANE to its underlying
network devices and resources can be specific to the request. In order network devices and resources can be specific to the request. In order
to respond to the Property Map request correctly, an ALTO server must store to respond to the property map request correctly, an ALTO server must store
the mapping of each Path Vector request until the client fully retrieves the the mapping of each Path Vector request until the client fully retrieves the
property information. The "stateful" behavior may substantially harm the property information. This "stateful" behavior may substantially harm
server scalability and potentially lead to Denial-of-Service attacks.</li> server scalability and potentially lead to denial-of-service attacks.</li>
</ol> </ol>
<t>One approach to realize the one-round communication is to define a ne w media <t>One approach for realizing the one-round communication is to define a new media
type to contain both objects, but this violates modular design. This document type to contain both objects, but this violates modular design. This document
follows the standard-conforming usage of "multipart/related" media type defined follows the standard-conforming usage of the "multipart/related" media type as d efined
in <xref target="RFC2387" format="default"/> to elegantly combine the objects. P ath Vectors are encoded in an in <xref target="RFC2387" format="default"/> to elegantly combine the objects. P ath Vectors are encoded in an
InfoResourceCostMap or an InfoResourceEndpointCostMap, and the Property Map is InfoResourceCostMap data component or InfoResourceEndpointCostMap data component
encoded in an InfoResourceProperties. They are encapsulated as parts of a , and the property map is
multipart message. The modular composition allows ALTO servers and clients to encoded in an InfoResourceProperties data component. They are encapsulated as pa
rts of a
multipart message. This modular composition allows ALTO servers and clients to
reuse the data models of the existing information resources. Specifically, this reuse the data models of the existing information resources. Specifically, this
document addresses the following practical issues using "multipart/related".</t> document addresses the following practical issues using "multipart/related".</t>
<section anchor="identifying-the-media-type-of-the-root-object" numbered ="true" toc="default"> <section anchor="identifying-the-media-type-of-the-root-object" numbered ="true" toc="default">
<name>Identifying the Media Type of the Root Object</name> <name>Identifying the Media Type of the Object Root</name>
<t>ALTO uses media type to indicate the type of an entry in the Inform <t>ALTO uses a media type to indicate the type of an entry in the IRD
ation (e.g., "application/alto-costmap+json" for the cost map
Resource Directory (IRD) (e.g., "application/alto-costmap+json" for Cost Map and "application/alto-endpointcost+json" for the Endpoint Cost Service). Simply
and "application/alto-endpointcost+json" for Endpoint Cost Service). Simply using "multipart/related" as the media type, however, makes it impossible
putting "multipart/related" as the media type, however, makes it impossible
for an ALTO client to identify the type of service provided by related for an ALTO client to identify the type of service provided by related
entries.</t> entries.</t>
<t>To address this issue, this document uses the "type" parameter to i ndicate the <t>To address this issue, this document uses the "type" parameter to i ndicate the
root object of a multipart/related message. For a Cost Map resource, the object root of a multipart/related message. For a cost map resource, the
"media-type" field in the IRD entry is "multipart/related" with the parameter "media-type" field in the IRD entry is "multipart/related" with the parameter
"type=application/alto-costmap+json"; for an Endpoint Cost Service, the "type=application/alto-costmap+json"; for an Endpoint Cost Service, the
parameter is "type=application/alto-endpointcost+json".</t> parameter is "type=application/alto-endpointcost+json".</t>
</section> </section>
<section anchor="ref-partmsg-design" numbered="true" toc="default"> <section anchor="ref-partmsg-design" numbered="true" toc="default">
<name>References to Part Messages</name> <name>References to Part Messages</name>
<t>As the response of a Path Vector resource is a multipart message wi th two <t>As the response of a Path Vector resource is a multipart message wi th two
different parts, it is important that each part can be uniquely identified. different parts, it is important that each part can be uniquely identified.
Following the designs of <xref target="RFC8895" format="default"/>, this extensi Following the design provided in <xref target="RFC8895" format="default"/>, this
on requires that an ALTO extension requires that an ALTO
server assigns a unique identifier to each part of the multipart response server assign a unique identifier to each part of the multipart response
message. This identifier, referred to as a Part Resource ID (See message. This identifier, referred to as a Part Resource ID (see
<xref target="part-rid-spec" format="default"/> for details), is present in the part message's "Content-ID" <xref target="part-rid-spec" format="default"/> for details), is present in the part message's "Content-ID"
header. By concatenating the Part Resource ID to the identifier of the Path header field. By concatenating the Part Resource ID to the identifier of the Pat
Vector request, an ALTO server/client can uniquely identify the Path Vector Part h
or the Property Map part.</t> Vector request, an ALTO server/client can uniquely identify the Path Vector part
or the property map part.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="Basic" numbered="true" toc="default"> <section anchor="Basic" numbered="true" toc="default">
<name>Specification: Basic Data Types</name> <name>Specification: Basic Data Types</name>
<section anchor="ane-name-spec" numbered="true" toc="default"> <section anchor="ane-name-spec" numbered="true" toc="default">
<name>ANE Name</name> <name>ANE Name</name>
<t>An ANE Name is encoded as a JSON string with the same format as that <t>An ANE name is encoded as a JSON string with the same format as that
of the type of the type
PIDName (Section 10.1 of <xref target="RFC7285" format="default"/>).</t> PIDName (<xref target="RFC7285" sectionFormat="of" section="10.1"/>).</t>
<t>The type ANEName is used in this document to indicate a string of thi s <t>The type ANEName is used in this document to indicate a string of thi s
format.</t> format.</t>
</section> </section>
<section anchor="ane-domain-spec" numbered="true" toc="default"> <section anchor="ane-domain-spec" numbered="true" toc="default">
<name>ANE Entity Domain</name> <name>ANE Entity Domain</name>
<t>The ANE entity domain associates property values with the Abstract Ne <t>The ANE entity domain associates property values with the ANEs in a p
twork roperty map. &nbsp;Accordingly, the ANE entity domain always depends on
Elements in a Property Map. Accordingly, the ANE entity domain always depends on a property map.</t>
a Property Map.</t>
<t>It must be noted that the term "domain" here does not refer to a netw ork domain. <t>It must be noted that the term "domain" here does not refer to a netw ork domain.
Rather, it is inherited from the "entity domain" defined in Sec 3.2 in Rather, it is inherited from the entity domain as defined in
<xref target="I-D.ietf-alto-unified-props-new" format="default"/> that represent <xref target="RFC9240" sectionFormat="of" section="3.2"/>; the entity domain rep
s the set of valid entities resents the set of valid entities
defined by an ALTO information resource (called the defining information defined by an ALTO information resource (called the "defining information
resource).</t> resource").</t>
<section anchor="domain-type" numbered="true" toc="default"> <section anchor="domain-type" numbered="true" toc="default">
<name>Entity Domain Type</name> <name>Entity Domain Type</name>
<t>The Entity Domain Type is "ane".</t> <t>The entity domain type is "ane".</t>
</section> </section>
<section anchor="entity-address" numbered="true" toc="default"> <section anchor="entity-address" numbered="true" toc="default">
<name>Domain-Specific Entity Identifier</name> <name>Domain-Specific Entity Identifier</name>
<t>The entity identifiers are the ANE Names in the associated Property Map.</t> <t>The entity identifiers are the ANE names in the associated property map.</t>
</section> </section>
<section anchor="hierarchy-and-inheritance" numbered="true" toc="default "> <section anchor="hierarchy-and-inheritance" numbered="true" toc="default ">
<name>Hierarchy and Inheritance</name> <name>Hierarchy and Inheritance</name>
<t>There is no hierarchy or inheritance for properties associated with ANEs.</t> <t>There is no hierarchy or inheritance for properties associated with ANEs.</t>
</section> </section>
<section anchor="domain-defining" numbered="true" toc="default"> <section anchor="domain-defining" numbered="true" toc="default">
<name>Media Type of Defining Resource</name> <name>Media Type of Defining Resource</name>
<t>The defining resource for entity domain type "ane" MUST be a Proper ty Map, i.e., <t>The defining resource for entity domain type "ane" <bcp14>MUST</bcp 14> be a property map, i.e.,
the media type of defining resources is:</t> the media type of defining resources is:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
application/alto-propmap+json application/alto-propmap+json
]]></artwork> ]]></artwork>
<t>Specifically, for ephemeral ANEs that appear in a Path Vector respo nse, their <t>Specifically, for ephemeral ANEs that appear in a Path Vector respo nse, their
entity domain names MUST be exactly ".ane" and the defining resource of these entity domain names <bcp14>MUST</bcp14> be exactly ".ane", and the defining reso
ANEs is the Property Map part of the multipart response. Meanwhile, for any urce of these
persistent ANE whose defining resource is a Property Map resource, its entity ANEs is the property map part of the multipart response. Meanwhile, for any
domain name MUST have the format of "PROPMAP.ane" where PROPMAP is the resource persistent ANE whose defining resource is a property map resource, its entity
domain name <bcp14>MUST</bcp14> have the format of "PROPMAP.ane", where PROPMAP
is the resource
ID of the defining resource. Persistent entities are "persistent" because ID of the defining resource. Persistent entities are "persistent" because
standalone queries can be made by an ALTO client to their defining resource(s) standalone queries can be made by an ALTO client to their defining resource(s)
when the connection to the Path Vector service is closed.</t> when the connection to the Path Vector service is closed.</t>
<t>For example, the defining resource of an ephemeral ANE whose entity identifier <t>For example, the defining resource of an ephemeral ANE whose entity identifier
is ".ane:NET1" is the Property Map part that contains this identifier. The is ".ane:NET1" is the property map part that contains this identifier. The
defining resource of a persistent ANE whose entity identifier is defining resource of a persistent ANE whose entity identifier is
"dc-props.ane:DC1" is the Property Map with the resource ID "dc-props".</t> "dc-props.ane:DC1" is the property map with the resource ID "dc-props".</t>
</section> </section>
</section> </section>
<section anchor="ane-prop-name-spec" numbered="true" toc="default"> <section anchor="ane-prop-name-spec" numbered="true" toc="default">
<name>ANE Property Name</name> <name>ANE Property Name</name>
<t>An ANE Property Name is encoded as a JSON string with the same format <t>An ANE property name is encoded as a JSON string with the same format
as that of as that of an
Entity Property Name (Section 5.2.2 of <xref target="I-D.ietf-alto-unified-props entity property name (<xref target="RFC9240" sectionFormat="of" section="5.2.2"/
-new" format="default"/>).</t> >).</t>
</section> </section>
<section anchor="initial-ane-property-types" numbered="true" toc="default" > <section anchor="initial-ane-property-types" numbered="true" toc="default" >
<name>Initial ANE Property Types</name> <name>Initial ANE Property Types</name>
<t>Two initial ANE property types are specified, "max-reservable-bandwid th" and <t>Two initial ANE property types are specified: "max-reservable-bandwid th" and
"persistent-entity-id".</t> "persistent-entity-id".</t>
<t>Note that these property types do not depend on any information resou <t>Note that these property types do not depend on any information resou
rce. As rces. As
such, the EntityPropertyName MUST only have the EntityPropertyType part.</t> such, the "EntityPropertyName" parameter <bcp14>MUST</bcp14> only have the Entit
yPropertyType part.</t>
<section anchor="maxresbw" numbered="true" toc="default"> <section anchor="maxresbw" numbered="true" toc="default">
<name>Maximum Reservable Bandwidth</name> <name>Maximum Reservable Bandwidth</name>
<t>The maximum reservable bandwidth property ("max-reservable-bandwidt h") stands <t>The maximum reservable bandwidth property ("max-reservable-bandwidt h") stands
for the maximum bandwidth that can be reserved for all the traffic that for the maximum bandwidth that can be reserved for all the traffic that
traverses an ANE. The value MUST be encoded as a non-negative numerical cost traverses an ANE. The value <bcp14>MUST</bcp14> be encoded as a non-negative num
value as defined in Section 6.1.2.1 of <xref target="RFC7285" format="default"/> erical cost
and the unit is bit per value as defined in
second (bps). If this property is requested by the ALTO client but not present <xref target="RFC7285" sectionFormat="of" section="6.1.2.1"/>, and the unit is b
for an ANE in the server response, it MUST be interpreted as that the property its per
second (bps). If this property is requested by the ALTO client but is not presen
t
for an ANE in the server response, it <bcp14>MUST</bcp14> be interpreted as mean
ing that the property
is not defined for the ANE.</t> is not defined for the ANE.</t>
<t>This property can be offered in a setting where the ALTO server is part of a <t>This property can be offered in a setting where the ALTO server is part of a
network system that provides on-demand resource allocation and the ALTO client network system that provides on-demand resource allocation and the ALTO client
is part of a user application. One existing example is <xref target="NOVA" forma t="default"/>: the ALTO server is part of a user application. One existing example is <xref target="NOVA" forma t="default"/>: the ALTO server
is part of an SDN controller and exposes a list of traversed network elements is part of a Software-Defined Networking (SDN) controller and exposes a list of traversed network elements
and associated link bandwidth to the client. The encoding in <xref target="NOVA" format="default"/> differs and associated link bandwidth to the client. The encoding in <xref target="NOVA" format="default"/> differs
from the Path Vector response defined in this document that the Path Vector part from the Path Vector response defined in this document in that the Path Vector p
and Property Map part are put in the same JSON object.</t> art
<t>In such a framework, the ALTO server exposes resource (e.g., reserv and property map part are placed in the same JSON object.</t>
able bandwidth) <t>In such a framework, the ALTO server exposes resource
availability information to the ALTO client. How the client makes resource availability information (e.g., reservable bandwidth) to the ALTO client. How th
requests based on the information and how the resource allocation is achieved e client makes resource
respectively depend on interfaces between the management system and the users or requests based on the information, and how the resource allocation is achieved,
a higher-layer protocol (e.g., SDN network intents or MPLS tunnels), which are respectively, depend on interfaces between the management system and the users o
out of the scope of this document.</t> r
a higher-layer protocol (e.g., SDN network intents <xref target="INTENT-BASED-NE
TWORKING"/> or MPLS tunnels), which are
out of scope for this document.</t>
</section> </section>
<section anchor="persistent-entity-id" numbered="true" toc="default"> <section anchor="persistent-entity-id" numbered="true" toc="default">
<name>Persistent Entity ID</name> <name>Persistent Entity ID</name>
<t>The persistent entity ID property is the entity identifier of the p <t>This document enables the discovery of a persistent ANE by exposing
ersistent its
ANE which an ephemeral ANE presents (See <xref target="assoc" format="default"/> entity identifier as the persistent entity ID property of an ephemeral ANE in th
for details). The value of e path
this property is encoded with the format EntityID defined in Section 5.1.3 of vector response. The value of this property is encoded with the EntityID format
<xref target="I-D.ietf-alto-unified-props-new" format="default"/>.</t> defined in <xref target="RFC9240" sectionFormat="of" section="5.1.3"/>.</t>
<t>In this format, the entity ID combines:</t> <t>In this format, the entity ID combines:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>a defining information resource for the ANE on which a <li>a defining information resource for the ANE on which a
"persistent-entity-id" is queried, which is the Property Map resource "persistent-entity-id" is queried, which is the property map resource
defining the ANE as a persistent entity, together with the properties;</li> defining the ANE as a persistent entity, together with the properties.</li>
<li>the persistent name of the ANE in that Property Map.</li> <li>the persistent name of the ANE in that property map.</li>
</ul> </ul>
<t>With this format, the client has all the needed information for fur ther <t>With this format, the client has all the needed information for fur ther
standalone query properties on the persistent ANE.</t> standalone query properties on the persistent ANE.</t>
</section> </section>
<section anchor="examples" numbered="true" toc="default"> <section anchor="examples" numbered="true" toc="default">
<name>Examples</name> <name>Examples</name>
<t>To illustrate the use of "max-reservable-bandwidth", consider the f ollowing <t>To illustrate the use of "max-reservable-bandwidth", consider the f ollowing
network with 5 nodes. Assume the client wants to query the maximum reservable network with five nodes. Assume that the client wants to query the maximum reser vable
bandwidth from H1 to H2. An ALTO server may split the network into two ANEs: bandwidth from H1 to H2. An ALTO server may split the network into two ANEs:
"ane1" that represents the subnetwork with routers A, B, and C, and "ane2" that "ane1", which represents the subnetwork with routers A, B, and C; and "ane2", wh
represents the subnetwork with routers B, D and E. The maximum reservable ich
bandwidth for "ane1" is 15 Mbps (using path A-&gt;C-&gt;B) and the maximum reser represents the subnetwork with routers B, D, and E. The maximum reservable
vable bandwidth for "ane1" is 15 Mbps (using path A-&gt;C-&gt;B), and the maximum rese
rvable
bandwidth for "ane2" is 20 Mbps (using path B-&gt;D-&gt;E).</t> bandwidth for "ane2" is 20 Mbps (using path B-&gt;D-&gt;E).</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
20 Mbps 20 Mbps 20 Mbps 20 Mbps
10 Mbps +---+ +---+ +---+ 10 Mbps +---+ +---+ +---+
/----| B |---| D |----| E |---- H2 /----| B |---| D |----| E |---- H2
+---+/ +---+ +---+ +---+ +---+/ +---+ +---+ +---+
H1 ----| A | 15 Mbps| H1 ----| A | 15 Mbps|
+---+\ +---+ +---+\ +---+
\----| C | \----| C |
15 Mbps +---+ 15 Mbps +---+
]]></artwork> ]]></artwork>
<t>To illustrate the use of "persistent-entity-id", consider the scena rio in <t>To illustrate the use of "persistent-entity-id", consider the scena rio in
<xref target="fig-se" format="default"/>. As the life cycle of service edges are typically long, they may <xref target="fig-se" format="default"/>. As the life cycles of service edges ar e typically long, the service edges may
contain information that is not specific to the query. Such information can be contain information that is not specific to the query. Such information can be
stored in an individual unified property map and later be accessed by an ALTO stored in an individual entity property map and can later be accessed by an ALTO
client.</t> client.</t>
<t>For example, "ane1" in <xref target="fig-se-example" format="defaul t"/> represents the on-premise service edge <t>For example, "ane1" in <xref target="fig-se-example" format="defaul t"/> represents the on-premise service edge
closest to host a. Assume the properties of the service edges are provided in closest to host "a". Assume that the properties of the service edges are provide
a unified property map called "se-props" and the ID of the on-premise service d in
edge is "9a0b55f7-7442-4d56-8a2c-b4cc6a8e3aa1", the "persistent-entity-id" of an entity property map called "se-props" and the ID of the on-premise service
edge is "9a0b55f7-7442-4d56-8a2c-b4cc6a8e3aa1"; the "persistent-entity-id" setti
ng for
"ane1" will be "se-props.ane:9a0b55f7-7442-4d56-8a2c-b4cc6a8e3aa1". With this "ane1" will be "se-props.ane:9a0b55f7-7442-4d56-8a2c-b4cc6a8e3aa1". With this
persistent entity ID, an ALTO client may send queries to the "se-props" resource persistent entity ID, an ALTO client may send queries to the "se-props" resource
with the entity ID ".ane:9a0b55f7-7442-4d56-8a2c-b4cc6a8e3aa1".</t> with the entity ID ".ane:9a0b55f7-7442-4d56-8a2c-b4cc6a8e3aa1".</t>
</section> </section>
</section> </section>
<section anchor="cost-type-spec" numbered="true" toc="default"> <section anchor="cost-type-spec" numbered="true" toc="default">
<name>Path Vector Cost Type</name> <name>Path Vector Cost Type</name>
<t>This document defines a new cost type, which is referred to as the Pa th Vector <t>This document defines a new cost type, which is referred to as the Pa th Vector
cost type. An ALTO server MUST offer this cost type if it supports the extension cost type. An ALTO server <bcp14>MUST</bcp14> offer this cost type if it support s the extension
defined in this document.</t> defined in this document.</t>
<section anchor="metric-spec" numbered="true" toc="default"> <section anchor="metric-spec" numbered="true" toc="default">
<name>Cost Metric: ane-path</name> <name>Cost Metric: &quot;ane-path&quot;</name>
<t>The cost metric "ane-path" indicates the value of such a cost type <t>The cost metric "ane-path" indicates that the value of such a cost
conveys an type conveys an
array of ANE names, where each ANE name uniquely represents an ANE traversed by array of ANE names, where each ANE name uniquely represents an ANE traversed by
traffic from a source to a destination.</t> traffic from a source to a destination.</t>
<t>An ALTO client MUST interpret the Path Vector as if the traffic bet ween a source <t>An ALTO client <bcp14>MUST</bcp14> interpret the Path Vector as if the traffic between a source
and a destination logically traverses the ANEs in the same order as they appear and a destination logically traverses the ANEs in the same order as they appear
in the Path Vector.</t> in the Path Vector.</t>
<t>When the Path Vector procedures defined in this document are in use , an ALTO <t>When the Path Vector procedures defined in this document are in use , an ALTO
server using the "ane-path" cost metric and the "array" cost mode (see server using the "ane-path" cost metric and the "array" cost mode (see
<xref target="mode-spec" format="default"/>) MUST return as the cost value a JSO <xref target="mode-spec" format="default"/>) <bcp14>MUST</bcp14> return as the c
N array of ANEName and the ost value a JSON array of data type ANEName, and the
client MUST also check that each element contained in the array is an ANEName client <bcp14>MUST</bcp14> also check that each element contained in the array i
(<xref target="ane-name-spec" format="default"/>). Otherwise, the client MUST di s an ANEName
scard the response and SHOULD (<xref target="ane-name-spec" format="default"/>). Otherwise, the client <bcp14>
follow the instructions in Section 8.3.4.3 of <xref target="RFC7285" format="def MUST</bcp14> discard the response and <bcp14>SHOULD</bcp14>
ault"/> to handle the error.</t> follow the guidance in <xref target="RFC7285" sectionFormat="of" section="8.3.4.
3"/> to handle the error.</t>
</section> </section>
<section anchor="mode-spec" numbered="true" toc="default"> <section anchor="mode-spec" numbered="true" toc="default">
<name>Cost Mode: array</name> <name>Cost Mode: &quot;array&quot;</name>
<t>The cost mode "array" indicates that every cost value in the respon se body of a <t>The cost mode "array" indicates that every cost value in the respon se body of a
(Filtered) Cost Map or an Endpoint Cost Service MUST be interpreted as a JSON (filtered) cost map or an Endpoint Cost Service <bcp14>MUST</bcp14> be interpret ed as a JSON
array object. While this cost mode can be applied to all cost metrics, array object. While this cost mode can be applied to all cost metrics,
additional specifications will be needed to clarify the semantics of the array additional specifications will be needed to clarify the semantics of the "array"
cost mode when combined with cost metrics other than 'ane-path'.</t> cost mode when combined with cost metrics other than "ane-path".</t>
</section> </section>
</section> </section>
<section anchor="part-rid-spec" numbered="true" toc="default"> <section anchor="part-rid-spec" numbered="true" toc="default">
<name>Part Resource ID and Part Content ID</name> <name>Part Resource ID and Part Content ID</name>
<t>A Part Resource ID is encoded as a JSON string with the same format a s that of the <t>A Part Resource ID is encoded as a JSON string with the same format a s that of the
type ResourceID (Section 10.2 of <xref target="RFC7285" format="default"/>).</t> type ResourceID (<xref target="RFC7285" sectionFormat="of" section="10.2"/>).</t
<t>Even though the client-id assigned to a Path Vector request and the P >
art <t>Even though the "client-id" assigned to a Path Vector request and the
Resource ID MAY contain up to 64 characters by their own definition, their Part
concatenation (see <xref target="ref-partmsg-design" format="default"/>) MUST al Resource ID <bcp14>MAY</bcp14> contain up to 64 characters by their own definiti
so conform to the same length on, their
concatenation (see <xref target="ref-partmsg-design" format="default"/>) <bcp14>
MUST</bcp14> also conform to the same length
constraint. The same requirement applies to the resource ID of the Path Vector constraint. The same requirement applies to the resource ID of the Path Vector
resource, too. Thus, it is RECOMMENDED to limit the length of resource ID and resource, too. Thus, it is <bcp14>RECOMMENDED</bcp14> to limit the length of the resource ID and
client ID related to a Path Vector resource to 31 characters.</t> client ID related to a Path Vector resource to 31 characters.</t>
<t>A Part Content ID conforms to the format of msg-id as specified in <t>A Part Content ID conforms to the format of "msg-id" as specified in
<xref target="RFC2387" format="default"/> and <xref target="RFC5322" format="def ault"/>. Specifically, it has the following format:</t> <xref target="RFC2387" format="default"/> and <xref target="RFC5322" format="def ault"/>. Specifically, it has the following format:</t>
<t>"&lt;" PART-RESOURCE-ID "@" DOMAIN-NAME "&gt;"</t> <t>"&lt;" PART-RESOURCE-ID "@" DOMAIN-NAME "&gt;"</t>
<dl> <dl>
<dt> <dt>
PART-RESOURCE-ID: </dt> PART-RESOURCE-ID: </dt>
<dd> <dd>
<t>PART-RESOURCE-ID has the same format as the Part Resource ID. It is used to <t>PART-RESOURCE-ID has the same format as the Part Resource ID. It is used to
identify whether a part message is a Path Vector or a Property Map.</t> identify whether a part message is a Path Vector or a property map.</t>
</dd> </dd>
<dt> <dt>
DOMAIN-NAME: </dt> DOMAIN-NAME: </dt>
<dd> <dd>
<t>DOMAIN-NAME has the same format as dot-atom-text specified in Sec <t>DOMAIN-NAME has the same format as "dot-atom-text" as specified i
tion 3.2.3 of n
<xref target="RFC5322" format="default"/>. It must be the domain name of the ALT <xref target="RFC5322" sectionFormat="of" section="3.2.3"/>. It must be the doma
O server.</t> in name of the ALTO server.</t>
</dd> </dd>
</dl> </dl>
</section> </section>
</section> </section>
<section anchor="Services" numbered="true" toc="default"> <section anchor="Services" numbered="true" toc="default">
<name>Specification: Service Extensions</name> <name>Specification: Service Extensions</name>
<section anchor="notations" numbered="true" toc="default"> <section anchor="notation" numbered="true" toc="default">
<name>Notations</name> <name>Notation</name>
<t>This document uses the same syntax and notations as introduced in Sec <t>This document uses the same syntax and notation as those introduced i
tion 8.2 of n <xref target="RFC7285" sectionFormat="of" section="8.2"/> to specify the exten
RFC 7285 <xref target="RFC7285" format="default"/> to specify the extensions to sions to existing ALTO resources and
existing ALTO resources and
services.</t> services.</t>
</section> </section>
<section anchor="pvcm-spec" numbered="true" toc="default"> <section anchor="pvcm-spec" numbered="true" toc="default">
<name>Multipart Filtered Cost Map for Path Vector</name> <name>Multipart Filtered Cost Map for Path Vector</name>
<t>This document introduces a new ALTO resource called multipart Filtere <t>This document introduces a new ALTO resource called the "multipart fi
d Cost Map ltered cost map
resource, which allows an ALTO server to provide other ALTO resources associated resource", which allows an ALTO server to provide other ALTO resources associate
with the Cost Map resource in the same response.</t> d
with the cost map resource in the same response.</t>
<section anchor="media-type" numbered="true" toc="default"> <section anchor="media-type" numbered="true" toc="default">
<name>Media Type</name> <name>Media Type</name>
<t>The media type of the multipart Filtered Cost Map resource is <t>The media type of the multipart filtered cost map resource is
"multipart/related" and the required "type" parameter MUST have "multipart/related", and the required "type" parameter <bcp14>MUST</bcp14> have
a value of "application/alto-costmap+json".</t> a value of "application/alto-costmap+json".</t>
</section> </section>
<section anchor="http-method" numbered="true" toc="default"> <section anchor="http-method" numbered="true" toc="default">
<name>HTTP Method</name> <name>HTTP Method</name>
<t>The multipart Filtered Cost Map is requested using the HTTP POST me thod.</t> <t>The multipart filtered cost map is requested using the HTTP POST me thod.</t>
</section> </section>
<section anchor="pvcm-accept" numbered="true" toc="default"> <section anchor="pvcm-accept" numbered="true" toc="default">
<name>Accept Input Parameters</name> <name>Accept Input Parameters</name>
<t>The input parameters of the multipart Filtered Cost Map are supplie d in the body <t>The input parameters of the multipart filtered cost map are supplie d in the body
of an HTTP POST request. This document extends the input parameters to a of an HTTP POST request. This document extends the input parameters to a
Filtered Cost Map, which is defined as a JSON object of type filtered cost map, which is defined as a JSON object of type
ReqFilteredCostMap in Section 4.1.2 of RFC 8189 <xref target="RFC8189" format="d ReqFilteredCostMap in <xref target="RFC8189" sectionFormat="of" section="4.1.2"/
efault"/>, with a data >, with a data
format indicated by the media type "application/alto-costmapfilter+json", which format indicated by the media type "application/alto-costmapfilter+json", which
is a JSON object of type PVReqFilteredCostMap:</t> is a JSON object of type PVReqFilteredCostMap:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
object { object {
[EntityPropertyName ane-property-names<0..*>;] [EntityPropertyName ane-property-names<0..*>;]
} PVReqFilteredCostMap : ReqFilteredCostMap; } PVReqFilteredCostMap : ReqFilteredCostMap;
]]></artwork> ]]></artwork>
<t>with fields:</t> <t>with field:</t>
<dl> <dl>
<dt> <dt>
ane-property-names: </dt> ane-property-names: </dt>
<dd> <dd>
<t>A list of selected ANE properties to be included in the respons <t>This field provides a list of selected ANE properties to be inc
e. Each luded in the response. Each
property in this list MUST match one of the supported ANE properties indicated property in this list <bcp14>MUST</bcp14> match one of the supported ANE propert
ies indicated
in the resource's "ane-property-names" capability (<xref target="pvcm-cap" forma t="default"/>). If the in the resource's "ane-property-names" capability (<xref target="pvcm-cap" forma t="default"/>). If the
field is not present, it MUST be interpreted as an empty list.</t> field is not present, it <bcp14>MUST</bcp14> be interpreted as an empty list.</t >
</dd> </dd>
</dl> </dl>
<t>Example: Consider the network in <xref target="fig-dumbbell" format ="default"/>. If an ALTO client wants to <t>Example: Consider the network in <xref target="fig-dumbbell" format ="default"/>. If an ALTO client wants to
query the "max-reservable-bandwidth" between PID1 and PID2, it can submit the query the "max-reservable-bandwidth" setting between PID1 and PID2, it can submi t the
following request.</t> following request.</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode name="" type="http-message"><![CDATA[
POST /costmap/pv HTTP/1.1 POST /costmap/pv HTTP/1.1
Host: alto.example.com Host: alto.example.com
Accept: multipart/related;type=application/alto-costmap+json, Accept: multipart/related;type=application/alto-costmap+json,
application/alto-error+json application/alto-error+json
Content-Length: 201 Content-Length: 212
Content-Type: application/alto-costmapfilter+json Content-Type: application/alto-costmapfilter+json
{ {
"cost-type": { "cost-type": {
"cost-mode": "array", "cost-mode": "array",
"cost-metric": "ane-path" "cost-metric": "ane-path"
}, },
"pids": { "pids": {
"srcs": [ "PID1" ], "srcs": [ "PID1" ],
"dsts": [ "PID2" ] "dsts": [ "PID2" ]
}, },
"ane-property-names": [ "max-reservable-bandwidth" ] "ane-property-names": [ "max-reservable-bandwidth" ]
} }
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="pvcm-cap" numbered="true" toc="default"> <section anchor="pvcm-cap" numbered="true" toc="default">
<name>Capabilities</name> <name>Capabilities</name>
<t>The multipart Filtered Cost Map resource extends the capabilities d <t>The multipart filtered cost map resource extends the capabilities d
efined efined
in Section 4.1.1 of <xref target="RFC8189" format="default"/>. The capabilities in <xref target="RFC8189" sectionFormat="of" section="4.1.1"/>. The capabilities
are defined by a JSON are defined by a JSON
object of type PVFilteredCostMapCapabilities:</t> object of type PVFilteredCostMapCapabilities:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
object { object {
[EntityPropertyName ane-property-names<0..*>;] [EntityPropertyName ane-property-names<0..*>;]
} PVFilteredCostMapCapabilities : FilteredCostMapCapabilities; } PVFilteredCostMapCapabilities : FilteredCostMapCapabilities;
]]></artwork> ]]></artwork>
<t>with fields:</t> <t>with field:</t>
<dl> <dl>
<dt> <dt>
ane-property-names: </dt> ane-property-names: </dt>
<dd> <dd>
<t>Defines a list of ANE properties that can be returned. If the f <t>This field provides a list of ANE properties that can be return
ield is not ed. If the field is not
present, it MUST be interpreted as an empty list, indicating the ALTO server present, it <bcp14>MUST</bcp14> be interpreted as an empty list, indicating that
cannot provide any ANE property.</t> the ALTO server
cannot provide any ANE properties.</t>
</dd> </dd>
</dl> </dl>
<t>This extension also introduces additional restrictions for the foll owing fields:</t> <t>This extension also introduces additional restrictions for the foll owing fields:</t>
<dl> <dl>
<dt> <dt>
cost-type-names: </dt> cost-type-names: </dt>
<dd> <dd>
<t>The "cost-type-names" field MUST include the Path Vector cost t ype, <t>The "cost-type-names" field <bcp14>MUST</bcp14> include the Pat h Vector cost type,
unless explicitly documented by a future extension. This also implies that the unless explicitly documented by a future extension. This also implies that the
Path Vector cost type MUST be defined in the "cost-types" of the Information Path Vector cost type <bcp14>MUST</bcp14> be defined in the "cost-types" of the
Resource Directory's "meta" field.</t> IRD's "meta" field.</t>
</dd> </dd>
<dt> <dt>
cost-constraints: </dt> cost-constraints: </dt>
<dd> <dd>
<t>If the "cost-type-names" field includes the Path Vector cost ty pe, <t>If the "cost-type-names" field includes the Path Vector cost ty pe,
"cost-constraints" field MUST be "false" or not present unless specifically the "cost-constraints" field <bcp14>MUST</bcp14> be either "false" or not presen
t,
unless specifically
instructed by a future document.</t> instructed by a future document.</t>
</dd> </dd>
<dt> <dt>
testable-cost-type-names (Section 4.1.1 of <xref target="RFC8189" format="defaul t"/>): </dt> testable-cost-type-names (<xref target="RFC8189" sectionFormat="of" section="4.1 .1"/>): </dt>
<dd> <dd>
<t>If the "cost-type-names" field includes the Path Vector cost ty pe and the <t>If the "cost-type-names" field includes the Path Vector cost ty pe and the
"testable-cost-type-names" field is present, the Path Vector cost type MUST "testable-cost-type-names" field is present, the Path Vector cost type <bcp14>MU
NOT be included in the "testable-cost-type-names" field unless specifically ST
NOT</bcp14> be included in the "testable-cost-type-names" field unless specifica
lly
instructed by a future document.</t> instructed by a future document.</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="uses" numbered="true" toc="default"> <section anchor="uses" numbered="true" toc="default">
<name>Uses</name> <name>Uses</name>
<t>This member MUST include the resource ID of the network map based o <t>This member <bcp14>MUST</bcp14> include the resource ID of the netw
n which the ork map based on which the
PIDs are defined. If this resource supports "persistent-entity-id", it MUST also PIDs are defined. If this resource supports "persistent-entity-id", it <bcp14>MU
ST</bcp14> also
include the defining resources of persistent ANEs that may appear in the respons e.</t> include the defining resources of persistent ANEs that may appear in the respons e.</t>
</section> </section>
<section anchor="pvcm-resp" numbered="true" toc="default"> <section anchor="pvcm-resp" numbered="true" toc="default">
<name>Response</name> <name>Response</name>
<t>The response MUST indicate an error, using ALTO protocol error hand <t>The response <bcp14>MUST</bcp14> indicate an error, using ALTO Prot
ling, as ocol error handling as
defined in Section 8.5 of <xref target="RFC7285" format="default"/>, if the requ defined in <xref target="RFC7285" sectionFormat="of" section="8.5"/>, if the req
est is invalid.</t> uest is invalid.</t>
<t>The "Content-Type" header of the response MUST be "multipart/relate <t>The "Content-Type" header field of the response <bcp14>MUST</bcp14>
d" as defined be "multipart/related" as defined
by <xref target="RFC2387" format="default"/> with the following parameters:</t> by <xref target="RFC2387" format="default"/>, with the following parameters:</t>
<dl> <dl>
<dt> <dt>
type: </dt> type: </dt>
<dd> <dd>
<t>The type parameter is mandatory and MUST be "application/alto-c <t>The "type" parameter is mandatory and <bcp14>MUST</bcp14> be "a
ostmap+json". Note pplication/alto-costmap+json". Note
that <xref target="RFC2387" format="default"/> permits both parameters with and that <xref target="RFC2387" format="default"/> permits parameters both with and
without the double quotes.</t> without double quotes.</t>
</dd> </dd>
<dt> <dt>
start: </dt> start: </dt>
<dd> <dd>
<t>The start parameter is as defined in <xref target="RFC2387" for <t>The "start" parameter is as defined in <xref target="RFC2387" f
mat="default"/> and is optional. ormat="default"/> and is optional.
If present, it MUST have the same value as the "Content-ID" header of the Path If present, it <bcp14>MUST</bcp14> have the same value as the "Content-ID" heade
r field of the Path
Vector part.</t> Vector part.</t>
</dd> </dd>
<dt> <dt>
boundary: </dt> boundary: </dt>
<dd> <dd>
<t>The boundary parameter is as defined in Section 5.1.1 of <xref target="RFC2046" format="default"/> and is mandatory.</t> <t>The "boundary" parameter is as defined in <xref target="RFC2046 " sectionFormat="of" section="5.1.1"/> and is mandatory.</t>
</dd> </dd>
</dl> </dl>
<t>The body of the response MUST consist of two parts:</t> <t>The body of the response <bcp14>MUST</bcp14> consist of two parts:< /t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>The Path Vector part MUST include "Content-ID" and "Content-Typ <t>The Path Vector part <bcp14>MUST</bcp14> include "Content-ID" a
e" in its nd "Content-Type" in its
header. The "Content-Type" MUST be "application/alto-costmap+json". header. The "Content-Type" <bcp14>MUST</bcp14> be "application/alto-costmap+json
The value of "Content-ID" MUST have the same format as the Part Content ID as ".
The value of "Content-ID" <bcp14>MUST</bcp14> have the same format as the Part C
ontent ID as
specified in <xref target="part-rid-spec" format="default"/>. </t> specified in <xref target="part-rid-spec" format="default"/>. </t>
<t> <t>
The body of the Path Vector part MUST be a JSON object with the same format as The body of the Path Vector part <bcp14>MUST</bcp14> be a JSON object with the s
defined in Section 11.2.3.6 of <xref target="RFC7285" format="default"/> when th ame format as that
e "cost-type" field is defined in <xref target="RFC7285" sectionFormat="of" section="11.2.3.6"/> when t
present in the input parameters and MUST be a JSON object with the same format he "cost-type" field is
as defined in Section 4.1.3 of <xref target="RFC8189" format="default"/> if the present in the input parameters and <bcp14>MUST</bcp14> be a JSON object with th
"multi-cost-types" field is e same format
present. The JSON object MUST include the as that defined in <xref target="RFC8189" sectionFormat="of" section="4.1.3"/> i
f the "multi-cost-types" field is
present. The JSON object <bcp14>MUST</bcp14> include the
"vtag" field in the "meta" field, which provides the version tag of the "vtag" field in the "meta" field, which provides the version tag of the
returned CostMapData. The resource ID of the version tag MUST follow the returned CostMapData object. The resource ID of the version tag <bcp14>MUST</bcp 14> follow the
format of </t> format of </t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode name="" type="rbnf"><![CDATA[
resource-id '.' part-resource-id resource-id '.' part-resource-id
]]></artwork> ]]></sourcecode>
<t> <t>
where "resource-id" is the resource Id of the Path Vector resource, and where "resource-id" is the resource ID of the Path Vector resource and
"part-resource-id" has the same value as the PART-RESOURCE-ID in the "part-resource-id" has the same value as the PART-RESOURCE-ID in the
"Content-ID" of the Path Vector part. "Content-ID" of the Path Vector part.
The "meta" field MUST also include the "dependent-vtags" field, whose value is The "meta" field <bcp14>MUST</bcp14> also include the "dependent-vtags" field, w hose value is
a single-element array to indicate the version tag of the network map used, a single-element array to indicate the version tag of the network map used,
where the network map is specified in the "uses" attribute of the multipart where the network map is specified in the "uses" attribute of the multipart
Filtered Cost Map resource in IRD.</t> filtered cost map resource in the IRD.</t>
</li> </li>
<li> <li>
<t>The Unified Property Map part MUST also include "Content-ID" an <t>The entity property map part <bcp14>MUST</bcp14> also include "
d Content-ID" and
"Content-Type" in its header. The "Content-Type" MUST be "Content-Type" in its header. The "Content-Type" <bcp14>MUST</bcp14> be
"application/alto-propmap+json". The value of "Content-ID" MUST have the same "application/alto-propmap+json". The value of "Content-ID" <bcp14>MUST</bcp14> h
ave the same
format as the Part Content ID as specified in <xref target="part-rid-spec" forma t="default"/>. </t> format as the Part Content ID as specified in <xref target="part-rid-spec" forma t="default"/>. </t>
<t> <t>
The body of the Unified Property Map part is a JSON object with the same The body of the entity property map part is a JSON object with the same
format as defined in Section 7.6 of <xref target="I-D.ietf-alto-unified-props-ne format as that defined in <xref target="RFC9240" sectionFormat="of" section="7.6
w" format="default"/>. The "/>. The
JSON object MUST include the "dependent-vtags" field in the "meta" field. The JSON object <bcp14>MUST</bcp14> include the "dependent-vtags" field in the "meta
value of the "dependent-vtags" field MUST be an array of VersionTag objects as " field. The
defined by Section 10.3 of <xref target="RFC7285" format="default"/>. The "vtag" value of the "dependent-vtags" field <bcp14>MUST</bcp14> be an array of VersionT
of the Path Vector part MUST ag objects as
be included in the "dependent-vtags". If "persistent-entity-id" is requested, th defined by <xref target="RFC7285" sectionFormat="of" section="10.3"/>. The "vtag
e " of the Path Vector part <bcp14>MUST</bcp14>
be included in the "dependent-vtags" field. If "persistent-entity-id" is request
ed, the
version tags of the dependent resources that may expose the entities in the version tags of the dependent resources that may expose the entities in the
response MUST also be included. </t> response <bcp14>MUST</bcp14> also be included. </t>
<t> <t>
The PropertyMapData has one member for each ANEName that appears in the Path The PropertyMapData object has one member for each ANEName that appears in the P ath
Vector part, which is an entity identifier belonging to the self-defined Vector part, which is an entity identifier belonging to the self-defined
entity domain as defined in Section 5.1.2.3 of entity domain as defined in
<xref target="I-D.ietf-alto-unified-props-new" format="default"/>. The EntityPro <xref target="RFC9240" sectionFormat="of" section="5.1.2.3"/>. The EntityProps o
ps for each ANE has one bject for each ANE has one
member for each property that is both 1) associated with the ANE, and 2) member for each property that is both 1) associated with the ANE and 2)
specified in the "ane-property-names" in the request. If the Path Vector cost specified in the "ane-property-names" field in the request. If the Path Vector c
ost
type is not included in the "cost-type" field or the "multi-cost-type" field, type is not included in the "cost-type" field or the "multi-cost-type" field,
the "property-map" field MUST be present and the value MUST be an empty object the "property-map" field <bcp14>MUST</bcp14> be present and the value <bcp14>MUS T</bcp14> be an empty object
({}).</t> ({}).</t>
</li> </li>
</ul> </ul>
<t>A complete and valid response MUST include both the Path Vector par <t>A complete and valid response <bcp14>MUST</bcp14> include both the
t and the Path Vector part and the
Property Map part in the multipart message. If any part is NOT present, the property map part in the multipart message. If any part is <strong>not</strong>
client MUST discard the received information and send another request if present, the
client <bcp14>MUST</bcp14> discard the received information and send another req
uest if
necessary.</t> necessary.</t>
<t>According to <xref target="RFC2387" format="default"/>, the Path Ve <t>The Path Vector part, whose media type is the same as the "type" pa
ctor part, whose media type is rameter of the multipart response message, is the root body part as defined in
the same as the "type" parameter of the multipart response message, is the root <xref target="RFC2387" format="default"/>. Thus, it is the element that the appl
object. Thus, it is the element the application processes first. Even though the ication processes first. Even though the
"start" parameter allows it to be placed anywhere in the part sequence, it is "start" parameter allows it to be placed anywhere in the part sequence, it is
RECOMMENDED that the parts arrive in the same order as they are processed, i.e., <bcp14>RECOMMENDED</bcp14> that the parts arrive in the same order as they are p
the Path Vector part is always put as the first part, followed by the Property rocessed, i.e.,
Map part. When doing so, an ALTO server MAY choose not to set the "start" the Path Vector part is always placed as the first part, followed by the propert
parameter, which implies the first part is the root object.</t> y
<t>Example: Consider the network in <xref target="fig-dumbbell" format map part. When doing so, an ALTO server <bcp14>MAY</bcp14> choose not to set the
="default"/>. The response of the example "start"
parameter, which implies that the first part is the object root.</t>
<t>Example: Consider the network in <xref target="fig-dumbbell" format
="default"/>. The response to the example
request in <xref target="pvcm-accept" format="default"/> is as follows, where "A NE1" represents the request in <xref target="pvcm-accept" format="default"/> is as follows, where "A NE1" represents the
aggregation of all the switches in the network.</t> aggregation of all the switches in the network.</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode name="" type="http-message"><![CDATA[
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Length: 859 Content-Length: 911
Content-Type: multipart/related; boundary=example-1; Content-Type: multipart/related; boundary=example-1;
type=application/alto-costmap+json type=application/alto-costmap+json
--example-1 --example-1
Content-ID: <costmap@alto.example.com> Content-ID: <costmap@alto.example.com>
Content-Type: application/alto-costmap+json Content-Type: application/alto-costmap+json
{ {
"meta": { "meta": {
"vtag": { "vtag": {
skipping to change at line 1297 skipping to change at line 1296
}, },
"dependent-vtags": [ "dependent-vtags": [
{ {
"resource-id": "my-default-networkmap", "resource-id": "my-default-networkmap",
"tag": "75ed013b3cb58f896e839582504f6228" "tag": "75ed013b3cb58f896e839582504f6228"
} }
], ],
"cost-type": { "cost-mode": "array", "cost-metric": "ane-path" } "cost-type": { "cost-mode": "array", "cost-metric": "ane-path" }
}, },
"cost-map": { "cost-map": {
"PID1": { "PID2": ["ANE1"] } "PID1": { "PID2": [ "ANE1" ] }
} }
} }
--example-1 --example-1
Content-ID: <propmap@alto.example.com> Content-ID: <propmap@alto.example.com>
Content-Type: application/alto-propmap+json Content-Type: application/alto-propmap+json
{ {
"meta": { "meta": {
"dependent-vtags": [ "dependent-vtags": [
{ {
"resource-id": "filtered-cost-map-pv.costmap", "resource-id": "filtered-cost-map-pv.costmap",
"tag": "fb20b76204814e9db37a51151faaaef2" "tag": "fb20b76204814e9db37a51151faaaef2"
} }
] ]
}, },
"property-map": { "property-map": {
".ane:ANE1": { "max-reservable-bandwidth": 100000000 } ".ane:ANE1": { "max-reservable-bandwidth": 100000000 }
} }
} }
]]></artwork> --example-1
<!-- TODO: Error Handling --> ]]></sourcecode>
</section> </section>
</section> </section>
<section anchor="pvecs-spec" numbered="true" toc="default"> <section anchor="pvecs-spec" numbered="true" toc="default">
<name>Multipart Endpoint Cost Service for Path Vector</name> <name>Multipart Endpoint Cost Service for Path Vector</name>
<t>This document introduces a new ALTO resource called multipart Endpoin <t>This document introduces a new ALTO resource called the "multipart En
t Cost dpoint Cost
Service, which allows an ALTO server to provide other ALTO resources associated Service", which allows an ALTO server to provide other ALTO resources associated
with the Endpoint Cost Service resource in the same response.</t> with the Endpoint Cost Service resource in the same response.</t>
<section anchor="media-type-1" numbered="true" toc="default"> <section anchor="media-type-1" numbered="true" toc="default">
<name>Media Type</name> <name>Media Type</name>
<t>The media type of the multipart Endpoint Cost Service resource is <t>The media type of the multipart Endpoint Cost Service resource is
"multipart/related" and the required "type" parameter MUST have "multipart/related", and the required "type" parameter <bcp14>MUST</bcp14> have
a value of "application/alto-endpointcost+json".</t> a value of "application/alto-endpointcost+json".</t>
</section> </section>
<section anchor="http-method-1" numbered="true" toc="default"> <section anchor="http-method-1" numbered="true" toc="default">
<name>HTTP Method</name> <name>HTTP Method</name>
<t>The multipart Endpoint Cost Service resource is requested using the HTTP POST method.</t> <t>The multipart Endpoint Cost Service resource is requested using the HTTP POST method.</t>
</section> </section>
<section anchor="pvecs-accept" numbered="true" toc="default"> <section anchor="pvecs-accept" numbered="true" toc="default">
<name>Accept Input Parameters</name> <name>Accept Input Parameters</name>
<t>The input parameters of the multipart Endpoint Cost Service resourc e are <t>The input parameters of the multipart Endpoint Cost Service resourc e are
supplied in the body of an HTTP POST request. This document extends the input supplied in the body of an HTTP POST request. This document extends the input
parameters to an Endpoint Cost Service, which is defined as a JSON object of parameters to an Endpoint Cost Service, which is defined as a JSON object of
type ReqEndpointCost in Section 4.2.2 of <xref target="RFC8189" format="default" />, with a data type ReqEndpointCostMap in <xref target="RFC8189" sectionFormat="of" section="4. 2.2"/>, with a data
format indicated by the media type "application/alto-endpointcostparams+json", format indicated by the media type "application/alto-endpointcostparams+json",
which is a JSON object of type PVReqEndpointCost:</t> which is a JSON object of type PVReqEndpointCostMap:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
object { object {
[EntityPropertyName ane-property-names<0..*>;] [EntityPropertyName ane-property-names<0..*>;]
} PVReqEndpointcost : ReqEndpointcostMap; } PVReqEndpointCostMap : ReqEndpointCostMap;
]]></artwork> ]]></artwork>
<t>with fields:</t> <t>with field:</t>
<dl> <dl>
<dt> <dt>
ane-property-names: </dt> ane-property-names: </dt>
<dd> <dd>
<t>This document defines the "ane-property-names" in PVReqEndpoint cost as the <t>This document defines the "ane-property-names" field in PVReqEn dpointCostMap as being the
same as in PVReqFilteredCostMap. See <xref target="pvcm-accept" format="default" />.</t> same as in PVReqFilteredCostMap. See <xref target="pvcm-accept" format="default" />.</t>
</dd> </dd>
</dl> </dl>
<t>Example: Consider the network in <xref target="fig-dumbbell" format ="default"/>. If an ALTO client wants to <t>Example: Consider the network in <xref target="fig-dumbbell" format ="default"/>. If an ALTO client wants to
query the "max-reservable-bandwidth" between eh1 and eh2, it can submit the query the "max-reservable-bandwidth" setting between "eh1" and "eh2", it can sub mit the
following request.</t> following request.</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode name="" type="http-message"><![CDATA[
POST /ecs/pv HTTP/1.1 POST /ecs/pv HTTP/1.1
Host: alto.example.com Host: alto.example.com
Accept: multipart/related;type=application/alto-endpointcost+json, Accept: multipart/related;type=application/alto-endpointcost+json,
application/alto-error+json application/alto-error+json
Content-Length: 227 Content-Length: 238
Content-Type: application/alto-endpointcostparams+json Content-Type: application/alto-endpointcostparams+json
{ {
"cost-type": { "cost-type": {
"cost-mode": "array", "cost-mode": "array",
"cost-metric": "ane-path" "cost-metric": "ane-path"
}, },
"endpoints": { "endpoints": {
"srcs": [ "ipv4:192.0.2.2" ], "srcs": [ "ipv4:192.0.2.2" ],
"dsts": [ "ipv4:192.0.2.18" ] "dsts": [ "ipv4:192.0.2.18" ]
}, },
"ane-property-names": [ "max-reservable-bandwidth" ] "ane-property-names": [ "max-reservable-bandwidth" ]
} }
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="pvecs-cap" numbered="true" toc="default"> <section anchor="pvecs-cap" numbered="true" toc="default">
<name>Capabilities</name> <name>Capabilities</name>
<t>The capabilities of the multipart Endpoint Cost Service resource ar e defined by <t>The capabilities of the multipart Endpoint Cost Service resource ar e defined by
a JSON object of type PVEndpointcostCapabilities, which is defined as the same a JSON object of type PVEndpointCostCapabilities, which is defined as being the same
as PVFilteredCostMapCapabilities. See <xref target="pvcm-cap" format="default"/> .</t> as PVFilteredCostMapCapabilities. See <xref target="pvcm-cap" format="default"/> .</t>
</section> </section>
<section anchor="uses-1" numbered="true" toc="default"> <section anchor="uses-1" numbered="true" toc="default">
<name>Uses</name> <name>Uses</name>
<t>If this resource supports "persistent-entity-id", it MUST also incl ude the <t>If this resource supports "persistent-entity-id", it <bcp14>MUST</b cp14> also include the
defining resources of persistent ANEs that may appear in the response.</t> defining resources of persistent ANEs that may appear in the response.</t>
</section> </section>
<section anchor="pvecs-resp" numbered="true" toc="default"> <section anchor="pvecs-resp" numbered="true" toc="default">
<name>Response</name> <name>Response</name>
<t>The response MUST indicate an error, using ALTO protocol error hand <t>The response <bcp14>MUST</bcp14> indicate an error, using ALTO Prot
ling, as ocol error handling as
defined in Section 8.5 of <xref target="RFC7285" format="default"/>, if the requ defined in <xref target="RFC7285" sectionFormat="of" section="8.5"/>, if the req
est is invalid.</t> uest is invalid.</t>
<t>The "Content-Type" header of the response MUST be "multipart/relate <t>The "Content-Type" header field of the response <bcp14>MUST</bcp14>
d" as defined be "multipart/related" as defined
by <xref target="RFC7285" format="default"/> with the following parameters:</t> by <xref target="RFC2387" format="default"/>, with the following parameters:</t>
<dl> <dl>
<dt> <dt>
type: </dt> type: </dt>
<dd> <dd>
<t>The type parameter MUST be "application/alto-endpointcost+json" and is mandatory.</t> <t>The "type" parameter <bcp14>MUST</bcp14> be "application/alto-e ndpointcost+json" and is mandatory.</t>
</dd> </dd>
<dt> <dt>
start: </dt> start: </dt>
<dd> <dd>
<t>The start parameter is as defined in <xref target="pvcm-resp" f ormat="default"/>.</t> <t>The "start" parameter is as defined in <xref target="pvcm-resp" format="default"/>.</t>
</dd> </dd>
<dt> <dt>
boundary: </dt> boundary: </dt>
<dd> <dd>
<t>The boundary parameter is as defined in Section 5.1.1 of <xref target="RFC2046" format="default"/> and is mandatory.</t> <t>The "boundary" parameter is as defined in <xref target="RFC2046 " sectionFormat="of" section="5.1.1"/> and is mandatory.</t>
</dd> </dd>
</dl> </dl>
<t>The body MUST consist of two parts:</t> <t>The body of the response <bcp14>MUST</bcp14> consist of two parts:< /t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>The Path Vector part MUST include "Content-ID" and "Content-Typ e" in its <t>The Path Vector part <bcp14>MUST</bcp14> include "Content-ID" a nd "Content-Type" in its
header. header.
The "Content-Type" MUST be "application/alto-endpointcost+json". The "Content-Type" <bcp14>MUST</bcp14> be "application/alto-endpointcost+json".
The value of "Content-ID" MUST have the same format as the Part Content ID as The value of "Content-ID" <bcp14>MUST</bcp14> have the same format as the Part C
ontent ID as
specified in <xref target="part-rid-spec" format="default"/>. </t> specified in <xref target="part-rid-spec" format="default"/>. </t>
<t> <t>
The body of the Path Vector part MUST be a JSON object with the same format as The body of the Path Vector part <bcp14>MUST</bcp14> be a JSON object with the s
defined in Section 11.5.1.6 of <xref target="RFC7285" format="default"/> when th ame format as that
e "cost-type" field is defined in <xref target="RFC7285" sectionFormat="of" section="11.5.1.6"/> when t
present in the input parameters and MUST be a JSON object with the same format he "cost-type" field is
as defined in Section 4.2.3 of <xref target="RFC8189" format="default"/> if the present in the input parameters and <bcp14>MUST</bcp14> be a JSON object with th
"multi-cost-types" field is e same format
present. The JSON object MUST include the as that defined in <xref target="RFC8189" sectionFormat="of" section="4.2.3"/> i
f the "multi-cost-types" field is
present. The JSON object <bcp14>MUST</bcp14> include the
"vtag" field in the "meta" field, which provides the version tag of the returned "vtag" field in the "meta" field, which provides the version tag of the returned
EndpointCostMapData. The resource ID of the version tag MUST follow the format o EndpointCostMapData object. The resource ID of the version tag <bcp14>MUST</bcp1
f </t> 4> follow the format of </t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode name="" type="rbnf"><![CDATA[
resource-id '.' part-resource-id resource-id '.' part-resource-id
]]></artwork> ]]></sourcecode>
<t> <t>
where "resource-id" is the resource Id of the Path Vector resource, and where "resource-id" is the resource ID of the Path Vector resource and
"part-resource-id" has the same value as the PART-RESOURCE-ID in the "Content-ID " "part-resource-id" has the same value as the PART-RESOURCE-ID in the "Content-ID "
of the Path Vector part.</t> of the Path Vector part.</t>
</li> </li>
<li> <li>
<t>The Unified Property Map part MUST also include "Content-ID" an <t>The entity property map part <bcp14>MUST</bcp14> also include "
d Content-ID" and
"Content-Type" in its header. The "Content-Type" MUST be "Content-Type" in its header. The "Content-Type" <bcp14>MUST</bcp14> be
"application/alto-propmap+json". "application/alto-propmap+json".
The value of "Content-ID" MUST have the same format as the Part Content ID as The value of "Content-ID" <bcp14>MUST</bcp14> have the same format as the Part C ontent ID as
specified in <xref target="part-rid-spec" format="default"/>. </t> specified in <xref target="part-rid-spec" format="default"/>. </t>
<t> <t>
The body of the Unified Property Map part MUST be a JSON object with the same The body of the entity property map part <bcp14>MUST</bcp14> be a JSON object wi
format as defined in Section 7.6 of <xref target="I-D.ietf-alto-unified-props-ne th the same
w" format="default"/>. The format as that defined in <xref target="RFC9240" sectionFormat="of" section="7.6
JSON object MUST include the "dependent-vtags" field in the "meta" field. The "/>. The
value of the "dependent-vtags" field MUST be an array of VersionTag objects as JSON object <bcp14>MUST</bcp14> include the "dependent-vtags" field in the "meta
defined by Section 10.3 of <xref target="RFC7285" format="default"/>. The "vtag" " field. The
of the Path Vector part MUST value of the "dependent-vtags" field <bcp14>MUST</bcp14> be an array of VersionT
be included in the "dependent-vtags". If "persistent-entity-id" is requested, th ag objects as
e defined by <xref target="RFC7285" sectionFormat="of" section="10.3"/>. The "vtag
" of the Path Vector part <bcp14>MUST</bcp14>
be included in the "dependent-vtags" field. If "persistent-entity-id" is request
ed, the
version tags of the dependent resources that may expose the entities in the version tags of the dependent resources that may expose the entities in the
response MUST also be included. </t> response <bcp14>MUST</bcp14> also be included. </t>
<t> <t>
The PropertyMapData has one member for each ANEName that appears in the Path The PropertyMapData object has one member for each ANEName that appears in the P ath
Vector part, which is an entity identifier belonging to the self-defined Vector part, which is an entity identifier belonging to the self-defined
entity domain as defined in Section 5.1.2.3 of entity domain as defined in
<xref target="I-D.ietf-alto-unified-props-new" format="default"/>. The EntityPro <xref target="RFC9240" sectionFormat="of" section="5.1.2.3"/>. The EntityProps o
ps for each ANE has one bject for each ANE has one
member for each property that is both 1) associated with the ANE, and 2) member for each property that is both 1) associated with the ANE and 2)
specified in the "ane-property-names" in the request. If the Path Vector cost specified in the "ane-property-names" field in the request. If the Path Vector c
ost
type is not included in the "cost-type" field or the "multi-cost-type" field, type is not included in the "cost-type" field or the "multi-cost-type" field,
the "property-map" field MUST be present and the value MUST be an empty object the "property-map" field <bcp14>MUST</bcp14> be present and the value <bcp14>MUS T</bcp14> be an empty object
({}).</t> ({}).</t>
</li> </li>
</ul> </ul>
<t>A complete and valid response MUST include both the Path Vector par <t>A complete and valid response <bcp14>MUST</bcp14> include both the
t and the Path Vector part and the
Property Map part in the multipart message. If any part is NOT present, the property map part in the multipart message. If any part is <strong>not</strong>
client MUST discard the received information and send another request if present, the
client <bcp14>MUST</bcp14> discard the received information and send another req
uest if
necessary.</t> necessary.</t>
<t>According to <xref target="RFC2387" format="default"/>, the Path Ve <t>The Path Vector part, whose media type is the same as the "type" pa
ctor part, whose media type is rameter of the multipart response message, is the root body part as defined in
the same as the "type" parameter of the multipart response message, is the root <xref target="RFC2387" format="default"/>. Thus, it is the element that the appl
object. Thus, it is the element the application processes first. Even though the ication processes first. Even though the
"start" parameter allows it to be placed anywhere in the part sequence, it is "start" parameter allows it to be placed anywhere in the part sequence, it is
RECOMMENDED that the parts arrive in the same order as they are processed, i.e., <bcp14>RECOMMENDED</bcp14> that the parts arrive in the same order as they are p
the Path Vector part is always put as the first part, followed by the Property rocessed, i.e.,
Map part. When doing so, an ALTO server MAY choose not to set the "start" the Path Vector part is always placed as the first part, followed by the propert
parameter, which implies the first part is the root object.</t> y
<t>Example: Consider the network in <xref target="fig-dumbbell" format map part. When doing so, an ALTO server <bcp14>MAY</bcp14> choose not to set the
="default"/>. The response of the example "start"
parameter, which implies that the first part is the object root.</t>
<t>Example: Consider the network in <xref target="fig-dumbbell" format
="default"/>. The response to the example
request in <xref target="pvecs-accept" format="default"/> is as follows.</t> request in <xref target="pvecs-accept" format="default"/> is as follows.</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode name="" type="http-message"><![CDATA[
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Length: 845 Content-Length: 899
Content-Type: multipart/related; boundary=example-1; Content-Type: multipart/related; boundary=example-1;
type=application/alto-endpointcost+json type=application/alto-endpointcost+json
--example-1 --example-1
Content-ID: <ecs@alto.example.com> Content-ID: <ecs@alto.example.com>
Content-Type: application/alto-endpointcost+json Content-Type: application/alto-endpointcost+json
{ {
"meta": { "meta": {
"vtag": { "vtag": {
skipping to change at line 1507 skipping to change at line 1504
}, },
"dependent-vtags": [ "dependent-vtags": [
{ {
"resource-id": "my-default-networkmap", "resource-id": "my-default-networkmap",
"tag": "677fe5f4066848d282ece213a84f9429" "tag": "677fe5f4066848d282ece213a84f9429"
} }
], ],
"cost-type": { "cost-mode": "array", "cost-metric": "ane-path" } "cost-type": { "cost-mode": "array", "cost-metric": "ane-path" }
}, },
"cost-map": { "cost-map": {
"ipv4:192.0.2.2": { "ipv4:192.0.2.18": ["ANE1"] } "ipv4:192.0.2.2": { "ipv4:192.0.2.18": [ "ANE1" ] }
} }
} }
--example-1 --example-1
Content-ID: <propmap@alto.example.com> Content-ID: <propmap@alto.example.com>
Content-Type: application/alto-propmap+json Content-Type: application/alto-propmap+json
{ {
"meta": { "meta": {
"dependent-vtags": [ "dependent-vtags": [
{ {
"resource-id": "ecs-pv.ecs", "resource-id": "ecs-pv.ecs",
"tag": "ec137bb78118468c853d5b622ac003f1" "tag": "ec137bb78118468c853d5b622ac003f1"
} }
] ]
}, },
"property-map": { "property-map": {
".ane:ANE1": { "max-reservable-bandwidth": 100000000 } ".ane:ANE1": { "max-reservable-bandwidth": 100000000 }
} }
} }
]]></artwork> --example-1
]]></sourcecode>
</section> </section>
</section> </section>
</section> </section>
<section anchor="Examples" numbered="true" toc="default"> <section anchor="Examples" numbered="true" toc="default">
<name>Examples</name> <name>Examples</name>
<t>This section lists some examples of Path Vector queries and the corresp onding <t>This section lists some examples of Path Vector queries and the corresp onding
responses. Some long lines are truncated for better readability.</t> responses. Some long lines are truncated for better readability.</t>
<section anchor="sample-setup" numbered="true" toc="default"> <section anchor="sample-setup" numbered="true" toc="default">
<name>Sample Setup</name> <name>Sample Setup</name>
<t><xref target="fig-pe" format="default"/> illustrates the network prop
erties and thus the message contents. There
are three subnetworks (NET1, NET2, and NET3) and two interconnection links (L1 a
nd
L2). It is assumed that each subnetwork has sufficiently large bandwidth to be
reserved.</t>
<figure anchor="fig-pe"> <figure anchor="fig-pe">
<name>Examples of ANE Properties</name> <name>Examples of ANE Properties</name>
<artwork type="drawing" align="center" name="" alt=""><![CDATA[ <artwork type="" align="center" name="" alt=""><![CDATA[
----- L1 ----- L1
/ /
PID1 +----------+ 10 Gbps +----------+ PID3 PID1 +----------+ 10 Gbps +----------+ PID3
192.0.2.0/28+-+ +------+ +---------+ +--+192.0.2.32/28 192.0.2.0/28+-+ +------+ +---------+ +--+192.0.2.32/28
| | MEC1 | | | | 2001:db8::3:0/16 | | MEC1 | | | | 2001:db8::3:0/16
| +------+ | +-----+ | | +------+ | +-----+ |
PID2 | | | +----------+ PID2 | | | +----------+
192.0.2.16/28+-+ | | NET3 192.0.2.16/28+-+ | | NET3
| | | 15 Gbps | | | 15 Gbps
| | | \ | | | \
+----------+ | -------- L2 +----------+ | -------- L2
NET1 | NET1 |
+----------+ +----------+
| +------+ | PID4 | +------+ | PID4
| | MEC2 | +--+192.0.2.48/28 | | MEC2 | +--+192.0.2.48/28
| +------+ | 2001:db8::4:0/16 | +------+ | 2001:db8::4:0/16
+----------+ +----------+
NET2 NET2
]]></artwork> ]]></artwork>
</figure> </figure>
<t>In this document, <xref target="fig-pe" format="default"/> is used to
illustrate the message contents. There
are 3 sub-networks (NET1, NET2 and NET3) and two interconnection links (L1 and
L2). It is assumed that each sub-network has sufficiently large bandwidth to be
reserved.</t>
</section> </section>
<section anchor="example-ird" numbered="true" toc="default"> <section anchor="example-ird" numbered="true" toc="default">
<name>Information Resource Directory</name> <name>Information Resource Directory</name>
<t>To give a comprehensive example of the extension defined in this docu ment, we <t>To give a comprehensive example of the extension defined in this docu ment, we
consider the network in <xref target="fig-pe" format="default"/>. Assume that th e ALTO server provides the consider the network in <xref target="fig-pe" format="default"/>. Assume that th e ALTO server provides the
following information resources:</t> following information resources:</t>
<ul spacing="normal"> <dl spacing="normal">
<li>"my-default-networkmap": A Network Map resource which contains the <dt>"my-default-networkmap":</dt><dd>A network map resource that conta
PIDs in the ins the PIDs in the
network.</li> network.</dd>
<li>"filtered-cost-map-pv": A Multipart Filtered Cost Map resource for <dt>"filtered-cost-map-pv":</dt><dd>A multipart filtered cost map reso
Path Vector, urce for the Path Vector. Exposes the "max-reservable-bandwidth" property for t
which exposes the "max-reservable-bandwidth" property for the PIDs in he PIDs in
"my-default-networkmap".</li> "my-default-networkmap".</dd>
<li>"ane-props": A filtered Unified Property resource that exposes the <dt>"ane-props":</dt><dd>A filtered entity property resource that expo
information for persistent ANEs in the network.</li> ses the
<li>"endpoint-cost-pv": A Multipart Endpoint Cost Service for Path Vec information for persistent ANEs in the network.</dd>
tor, which <dt>"endpoint-cost-pv":</dt><dd>A multipart Endpoint Cost Service for
exposes the "max-reservable-bandwidth" and the "persistent-entity-id" properties the Path Vector. Exposes the "max-reservable-bandwidth" and "persistent-entity-
.</li> id" properties.</dd>
<li>"update-pv": An Update Stream service, which provides the incremen <dt>"update-pv":</dt><dd>An update stream service that provides the in
tal update cremental update
service for the "endpoint-cost-pv" service.</li> service for the "endpoint-cost-pv" service.</dd>
<li>"multicost-pv": A Multipart Endpoint Cost Service with both Multi- <dt>"multicost-pv":</dt><dd>A multipart Endpoint Cost Service with bot
Cost and h the Multi-Cost extension and Path Vector extension enabled.</dd>
Path Vector.</li> </dl>
</ul> <t>Below is the IRD of the example ALTO server. To
<t>Below is the Information Resource Directory of the example ALTO serve enable the extension defined in this document, the Path Vector cost type
r. To (<xref target="cost-type-spec" format="default"/>), represented by "path-vector"
enable the extension defined in this document, the "path-vector" cost type below,
(<xref target="cost-type-spec" format="default"/>) is defined in the "cost-types is defined in the "cost-types" of the "meta" field and is
" of the "meta" field, and is
included in the "cost-type-names" of resources "filtered-cost-map-pv" and included in the "cost-type-names" of resources "filtered-cost-map-pv" and
"endpoint-cost-pv".</t> "endpoint-cost-pv".</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode name="" type="json"><![CDATA[
{ {
"meta": { "meta": {
"cost-types": { "cost-types": {
"path-vector": { "path-vector": {
"cost-mode": "array", "cost-mode": "array",
"cost-metric": "ane-path" "cost-metric": "ane-path"
}, },
"num-rc": { "num-rc": {
"cost-mode": "numerical", "cost-mode": "numerical",
"cost-metric": "routingcost" "cost-metric": "routingcost"
skipping to change at line 1669 skipping to change at line 1665
"max-cost-types": 2, "max-cost-types": 2,
"testable-cost-type-names": [ "num-rc" ], "testable-cost-type-names": [ "num-rc" ],
"ane-property-names": [ "ane-property-names": [
"max-reservable-bandwidth", "persistent-entity-id" "max-reservable-bandwidth", "persistent-entity-id"
] ]
}, },
"uses": [ "ane-props" ] "uses": [ "ane-props" ]
} }
} }
} }
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="multipart-filtered-cost-map" numbered="true" toc="default "> <section anchor="multipart-filtered-cost-map" numbered="true" toc="default ">
<name>Multipart Filtered Cost Map</name> <name>Multipart Filtered Cost Map</name>
<t>The following examples demonstrate the request to the "filtered-cost- map-pv" <t>The following examples demonstrate the request to the "filtered-cost- map-pv"
resource and the corresponding response.</t> resource and the corresponding response.</t>
<t>The request uses the "path-vector" cost type in the "cost-type" field . The <t>The request uses the "path-vector" cost type in the "cost-type" field . The
"ane-property-names" field is missing, indicating that the client only requests "ane-property-names" field is missing, indicating that the client only requests
for the Path Vector but not the ANE properties.</t> the Path Vector and not the ANE properties.</t>
<t>The response consists of two parts. The first part returns the array <t>The response consists of two parts:</t>
of ANEName <ul spacing="normal">
<li>The first part returns the array of data type ANEName
for each source and destination pair. There are two ANEs, where "L1" represents for each source and destination pair. There are two ANEs, where "L1" represents
the interconnection link L1, and "L2" represents the interconnection link L2.</t interconnection link L1 and "L2" represents interconnection link L2.</li>
> <li>The second part returns the property map. &nbsp;Note that the proper
<t>The second part returns an empty Property Map. Note that the ANE entr ties of the ANE entries are equal to the literal string "{}"
ies are (see <xref target="RFC9240" sectionFormat="of" section="8.3"/>).</li>
omitted since they have no properties (See Section 3.1 of </ul>
<xref target="I-D.ietf-alto-unified-props-new" format="default"/>).</t> <sourcecode name="" type="http-message"><![CDATA[
<artwork name="" type="" align="left" alt=""><![CDATA[
POST /costmap/pv HTTP/1.1 POST /costmap/pv HTTP/1.1
Host: alto.example.com Host: alto.example.com
Accept: multipart/related;type=application/alto-costmap+json, Accept: multipart/related;type=application/alto-costmap+json,
application/alto-error+json application/alto-error+json
Content-Length: 153 Content-Length: 163
Content-Type: application/alto-costmapfilter+json Content-Type: application/alto-costmapfilter+json
{ {
"cost-type": { "cost-type": {
"cost-mode": "array", "cost-mode": "array",
"cost-metric": "ane-path" "cost-metric": "ane-path"
}, },
"pids": { "pids": {
"srcs": [ "PID1" ], "srcs": [ "PID1" ],
"dsts": [ "PID3", "PID4" ] "dsts": [ "PID3", "PID4" ]
} }
} }
]]></artwork> ]]></sourcecode>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode name="" type="http-message"><![CDATA[
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Length: 855 Content-Length: 952
Content-Type: multipart/related; boundary=example-1; Content-Type: multipart/related; boundary=example-1;
type=application/alto-costmap+json type=application/alto-costmap+json
--example-1 --example-1
Content-ID: <costmap@alto.example.com> Content-ID: <costmap@alto.example.com>
Content-Type: application/alto-costmap+json Content-Type: application/alto-costmap+json
{ {
"meta": { "meta": {
"vtag": { "vtag": {
skipping to change at line 1751 skipping to change at line 1749
{ {
"meta": { "meta": {
"dependent-vtags": [ "dependent-vtags": [
{ {
"resource-id": "filtered-cost-map-pv.costmap", "resource-id": "filtered-cost-map-pv.costmap",
"tag": "d827f484cb66ce6df6b5077cb8562b0a" "tag": "d827f484cb66ce6df6b5077cb8562b0a"
} }
] ]
}, },
"property-map": { "property-map": {
".ane:L1": {},
".ane:L2": {}
} }
} }
]]></artwork> --example-1
]]></sourcecode>
</section> </section>
<section anchor="example-ecspv" numbered="true" toc="default"> <section anchor="example-ecspv" numbered="true" toc="default">
<name>Multipart Endpoint Cost Service Resource</name> <name>Multipart Endpoint Cost Service Resource</name>
<t>The following examples demonstrate the request to the "endpoint-cost- pv" <t>The following examples demonstrate the request to the "endpoint-cost- pv"
resource and the corresponding response.</t> resource and the corresponding response.</t>
<t>The request uses the Path Vector cost type in the "cost-type" field, <t>The request uses the "path-vector" cost type in the "cost-type" field
and and
queries the Maximum Reservable Bandwidth ANE property and the Persistent Entity queries the maximum reservable bandwidth ANE property and the persistent entity
ID
property for two IPv4 source and destination pairs (192.0.2.34 -&gt; 192.0.2.2 a nd property for two IPv4 source and destination pairs (192.0.2.34 -&gt; 192.0.2.2 a nd
192.0.2.34 -&gt; 192.0.2.50) and one IPv6 source and destination pair 192.0.2.34 -&gt; 192.0.2.50) and one IPv6 source and destination pair
(2001:db8::3:1 -&gt; 2001:db8::4:1).</t> (2001:db8::3:1 -&gt; 2001:db8::4:1).</t>
<t>The response consists of two parts. The first part returns the array <t>The response consists of two parts:</t>
of ANEName <ul spacing="normal">
<li>The first part returns the array of data type ANEName
for each valid source and destination pair. As one can see in <xref target="fig- pe" format="default"/>, flow for each valid source and destination pair. As one can see in <xref target="fig- pe" format="default"/>, flow
192.0.2.34 -&gt; 192.0.2.2 traverses NET2, L1 and NET1, and flows 192.0.2.34 -&g 192.0.2.34 -&gt; 192.0.2.2 traverses NET3, L1, and NET1; and flows 192.0.2.34 -&
t; gt;
192.0.2.50 and 2001:db8::3:1 -&gt; 2001:db8::4:1 traverse NET2, L2 and NET3.</t> 192.0.2.50 and 2001:db8::3:1 -&gt; 2001:db8::4:1 traverse NET2, L2, and NET3.</l
<t>The second part returns the requested properties of ANEs. Assume NET1 i>
, NET2 and NET3 has <li>The second part returns the requested properties of ANEs. Assume tha
t NET1, NET2, and NET3 have
sufficient bandwidth and their "max-reservable-bandwidth" values are set to a su fficiently sufficient bandwidth and their "max-reservable-bandwidth" values are set to a su fficiently
large number (50 Gbps in this case). On the other hand, assume there are no large number (50 Gbps in this case). On the other hand, assume that there are no
prior reservation on L1 and L2, and their "max-reservable-bandwidth" values are prior reservations on L1 and L2 and their "max-reservable-bandwidth" values are
the corresponding link capacity (10 Gbps for L1 and 15 Gbps for L2).</t> the corresponding link capacity (10 Gbps for L1 and 15 Gbps for L2).</li>
</ul>
<t>Both NET1 and NET2 have a mobile edge deployed, i.e., MEC1 in NET1 an d MEC2 in <t>Both NET1 and NET2 have a mobile edge deployed, i.e., MEC1 in NET1 an d MEC2 in
NET2. Assume the ANEName for MEC1 and MEC2 are "MEC1" and "MEC2" and their NET2. Assume that the ANEName values for MEC1 and MEC2 are "MEC1" and "MEC2" and
properties can be retrieved from the Property Map "ane-props". Thus, the their
"persistent-entity-id" property of NET1 and NET3 are "ane-props.ane:MEC1" and properties can be retrieved from the property map "ane-props". Thus, the
"ane-props.ane:MEC2" respectively.</t> "persistent-entity-id" property values for NET1 and NET2 are "ane-props.ane:MEC1
<artwork name="" type="" align="left" alt=""><![CDATA[ " and
"ane-props.ane:MEC2", respectively.</t>
<sourcecode name="" type="http-message"><![CDATA[
POST /endpointcost/pv HTTP/1.1 POST /endpointcost/pv HTTP/1.1
Host: alto.example.com Host: alto.example.com
Accept: multipart/related; Accept: multipart/related;
type=application/alto-endpointcost+json, type=application/alto-endpointcost+json,
application/alto-error+json application/alto-error+json
Content-Length: 362 Content-Length: 383
Content-Type: application/alto-endpointcostparams+json Content-Type: application/alto-endpointcostparams+json
{ {
"cost-type": { "cost-type": {
"cost-mode": "array", "cost-mode": "array",
"cost-metric": "ane-path" "cost-metric": "ane-path"
}, },
"endpoints": { "endpoints": {
"srcs": [ "srcs": [
"ipv4:192.0.2.34", "ipv4:192.0.2.34",
skipping to change at line 1808 skipping to change at line 1812
"ipv4:192.0.2.2", "ipv4:192.0.2.2",
"ipv4:192.0.2.50", "ipv4:192.0.2.50",
"ipv6:2001:db8::4:1" "ipv6:2001:db8::4:1"
] ]
}, },
"ane-property-names": [ "ane-property-names": [
"max-reservable-bandwidth", "max-reservable-bandwidth",
"persistent-entity-id" "persistent-entity-id"
] ]
} }
]]></artwork> ]]></sourcecode>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode name="" type="http-message"><![CDATA[
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Length: 1432 Content-Length: 1508
Content-Type: multipart/related; boundary=example-2; Content-Type: multipart/related; boundary=example-2;
type=application/alto-endpointcost+json type=application/alto-endpointcost+json
--example-2 --example-2
Content-ID: <ecs@alto.example.com> Content-ID: <ecs@alto.example.com>
Content-Type: application/alto-endpointcost+json Content-Type: application/alto-endpointcost+json
{ {
"meta": { "meta": {
"vtags": { "vtags": {
skipping to change at line 1877 skipping to change at line 1881
"max-reservable-bandwidth": 50000000000 "max-reservable-bandwidth": 50000000000
}, },
".ane:L1": { ".ane:L1": {
"max-reservable-bandwidth": 10000000000 "max-reservable-bandwidth": 10000000000
}, },
".ane:L2": { ".ane:L2": {
"max-reservable-bandwidth": 15000000000 "max-reservable-bandwidth": 15000000000
} }
} }
} }
]]></artwork> --example-2
<t>Under certain scenarios where the traversal order is not crucial, an ]]></sourcecode>
ALTO server <t>In certain scenarios where the traversal order is not crucial, an ALT
implementation may choose to not follow strictly the physical traversal order O server
implementation may choose not to strictly follow the physical traversal order
and may even obfuscate the order intentionally to preserve its own privacy or and may even obfuscate the order intentionally to preserve its own privacy or
conform to its own policies. conform to its own policies.
For example, an ALTO server may choose to aggregate NET1 and L1 as a new ANE For example, an ALTO server may choose to aggregate NET1 and L1 as a new ANE
with ANE name "AGGR1", and aggregate NET2 and L2 as a new ANE with ANE name with ANE name "AGGR1" and aggregate NET2 and L2 as a new ANE with ANE name
"AGGR2". The "max-reservable-bandwidth" of "AGGR1" takes the value of L1, which "AGGR2". The "max-reservable-bandwidth" property of "AGGR1" takes the value of L
is smaller than that of NET1, and the "persistent-entity-id" of "AGGR1" takes 1, which
the value of NET1. The properties of "AGGR2" are computed in a similar way and is smaller than that of NET1, and the "persistent-entity-id" property of "AGGR1"
takes
the value of NET1. The properties of "AGGR2" are computed in a similar way;
the obfuscated response is as shown below. Note that the obfuscation of Path the obfuscated response is as shown below. Note that the obfuscation of Path
Vector responses is implementation-specific and is out of the scope of this Vector responses is implementation specific and is out of scope for this
document, and developers may refer to <xref target="Security" format="default"/> document. Developers may refer to <xref target="Security" format="default"/> for
for further references.</t> further references.</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode name="" type="http-message"><![CDATA[
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Length: 1263 Content-Length: 1333
Content-Type: multipart/related; boundary=example-2; Content-Type: multipart/related; boundary=example-2;
type=application/alto-endpointcost+json type=application/alto-endpointcost+json
--example-2 --example-2
Content-ID: <ecs@alto.example.com> Content-ID: <ecs@alto.example.com>
Content-Type: application/alto-endpointcost+json Content-Type: application/alto-endpointcost+json
{ {
"meta": { "meta": {
"vtags": { "vtags": {
skipping to change at line 1952 skipping to change at line 1957
}, },
".ane:AGGR2": { ".ane:AGGR2": {
"max-reservable-bandwidth": 15000000000, "max-reservable-bandwidth": 15000000000,
"persistent-entity-id": "ane-props.ane:MEC2" "persistent-entity-id": "ane-props.ane:MEC2"
}, },
".ane:NET3": { ".ane:NET3": {
"max-reservable-bandwidth": 50000000000 "max-reservable-bandwidth": 50000000000
} }
} }
} }
]]></artwork> --example-2
]]></sourcecode>
</section> </section>
<section anchor="example-sse" numbered="true" toc="default"> <section anchor="example-sse" numbered="true" toc="default">
<name>Incremental Updates</name> <name>Incremental Updates</name>
<t>In this example, an ALTO client subscribes to the incremental update for the <t>In this example, an ALTO client subscribes to the incremental update for the
multipart Endpoint Cost Service resource "endpoint-cost-pv".</t> multipart Endpoint Cost Service resource "endpoint-cost-pv".</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode name="" type="http-message"><![CDATA[
POST /updates/pv HTTP/1.1 POST /updates/pv HTTP/1.1
Host: alto.example.com Host: alto.example.com
Accept: text/event-stream Accept: text/event-stream
Content-Type: application/alto-updatestreamparams+json Content-Type: application/alto-updatestreamparams+json
Content-Length: 112 Content-Length: 120
{ {
"add": { "add": {
"ecspvsub1": { "ecspvsub1": {
"resource-id": "endpoint-cost-pv", "resource-id": "endpoint-cost-pv",
"input": <ecs-input> "input": <ecs-input>
} }
} }
} }
]]></artwork> ]]></sourcecode>
<t>Based on the server-side process defined in <xref target="RFC8895" fo rmat="default"/>, the ALTO server will <t>Based on the server-side process defined in <xref target="RFC8895" fo rmat="default"/>, the ALTO server will
send the "control-uri" first using Server-Sent Event (SSE), followed by the full send the "control-uri" first, using a Server-Sent Event (SSE) followed by the fu ll
response of the multipart message.</t> response of the multipart message.</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode name="" type="http-message"><![CDATA[
HTTP/1.1 200 OK HTTP/1.1 200 OK
Connection: keep-alive Connection: keep-alive
Content-Type: text/event-stream Content-Type: text/event-stream
event: application/alto-updatestreamcontrol+json event: application/alto-updatestreamcontrol+json
data: {"control-uri": "https://alto.example.com/updates/streams/123"} data: {"control-uri": "https://alto.example.com/updates/streams/123"}
event: multipart/related;boundary=example-3; event: multipart/related;boundary=example-3;
type=application/alto-endpointcost+json,ecspvsub1 type=application/alto-endpointcost+json,ecspvsub1
data: --example-3 data: --example-3
data: Content-ID: <ecsmap@alto.example.com> data: Content-ID: <ecsmap@alto.example.com>
data: Content-Type: application/alto-endpointcost+json data: Content-Type: application/alto-endpointcost+json
data: data:
data: <endpoint-cost-map-entry> data: <endpoint-cost-map-entry>
data: --example-3 data: --example-3
data: Content-ID: <propmap@alto.example.com> data: Content-ID: <propmap@alto.example.com>
data: Content-Type: application/alto-propmap+json data: Content-Type: application/alto-propmap+json
data: data:
data: <property-map-entry> data: <property-map-entry>
data: --example-3-- data: --example-3--
]]></artwork> ]]></sourcecode>
<t>When the contents change, the ALTO server will publish the updates fo r each node <t>When the contents change, the ALTO server will publish the updates fo r each node
in this tree separately, based on Section 6.7.3 of <xref target="RFC8895" format in this tree separately, based on <xref target="RFC8895" sectionFormat="of" sect
="default"/>.</t> ion="6.7.3"/>.</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode name="" type="http-message"><![CDATA[
event: application/merge-patch+json, ecspvsub1.ecsmap@alto.example.com event: application/merge-patch+json,
ecspvsub1.ecsmap@alto.example.com
data: <Merge patch for endpoint-cost-map-update> data: <Merge patch for endpoint-cost-map-update>
event: application/merge-patch+json, ecspvsub1.propmap@alto.example.com event: application/merge-patch+json,
ecspvsub1.propmap@alto.example.com
data: <Merge patch for property-map-update> data: <Merge patch for property-map-update>
]]></artwork> ]]></sourcecode>
<!-- TODO: the remaining issue is where to specify the json-merge-patch
capability for each node -->
</section> </section>
<section anchor="multi-cost" numbered="true" toc="default"> <section anchor="multi-cost" numbered="true" toc="default">
<name>Multi-cost</name> <name>Multi-Cost</name>
<t>The following examples demonstrate the request to the "multicost-pv" resource <t>The following examples demonstrate the request to the "multicost-pv" resource
and the corresponding response.</t> and the corresponding response.</t>
<t>The request asks for two cost types: the first is the Path Vector cos t type, and <t>The request asks for two cost types: the first is the Path Vector cos t type, and
the second is a numerical routing cost. It also queries the Maximum Reservable the second is a numerical routing cost. It also queries the maximum reservable
Bandwidth ANE property and the Persistent Entity property for two IPv4 source an bandwidth ANE property and the persistent entity ID property for two IPv4 source
d and
destination pairs (192.0.2.34 -&gt; 192.0.2.2 and 192.0.2.34 -&gt; 192.0.2.50) a nd one destination pairs (192.0.2.34 -&gt; 192.0.2.2 and 192.0.2.34 -&gt; 192.0.2.50) a nd one
IPv6 source and destination pair (2001:db8::3:1 -&gt; 2001:db8::4:1).</t> IPv6 source and destination pair (2001:db8::3:1 -&gt; 2001:db8::4:1).</t>
<t>The response consists of two parts. The first part returns a JSONArra <t>The response consists of two parts:</t>
y that <ul spacing="normal">
contains two JSONValue for each requested source and destination pair: the first <li>The first part returns a JSONArray that
contains two JSONValue entries for each requested source and destination pair: t
he first
JSONValue is a JSONArray of ANENames, which is the value of the Path Vector cost JSONValue is a JSONArray of ANENames, which is the value of the Path Vector cost
type, and the second JSONValue is a JSONNumber which is the value of the routing type; and the second JSONValue is a JSONNumber, which is the value of the routin
cost. The second part contains a Property Map that maps the ANEs to their g
requested properties.</t> cost.</li>
<artwork name="" type="" align="left" alt=""><![CDATA[ <li>The second part contains a property map that maps the ANEs to their
requested properties.</li>
</ul>
<sourcecode name="" type="http-message"><![CDATA[
POST /endpointcost/mcpv HTTP/1.1 POST /endpointcost/mcpv HTTP/1.1
Host: alto.example.com Host: alto.example.com
Accept: multipart/related; Accept: multipart/related;
type=application/alto-endpointcost+json, type=application/alto-endpointcost+json,
application/alto-error+json application/alto-error+json
Content-Length: 433 Content-Length: 454
Content-Type: application/alto-endpointcostparams+json Content-Type: application/alto-endpointcostparams+json
{ {
"multi-cost-types": [ "multi-cost-types": [
{ "cost-mode": "array", "cost-metric": "ane-path" }, { "cost-mode": "array", "cost-metric": "ane-path" },
{ "cost-mode": "numerical", "cost-metric": "routingcost" } { "cost-mode": "numerical", "cost-metric": "routingcost" }
], ],
"endpoints": { "endpoints": {
"srcs": [ "srcs": [
"ipv4:192.0.2.34", "ipv4:192.0.2.34",
skipping to change at line 2056 skipping to change at line 2067
"ipv4:192.0.2.2", "ipv4:192.0.2.2",
"ipv4:192.0.2.50", "ipv4:192.0.2.50",
"ipv6:2001:db8::4:1" "ipv6:2001:db8::4:1"
] ]
}, },
"ane-property-names": [ "ane-property-names": [
"max-reservable-bandwidth", "max-reservable-bandwidth",
"persistent-entity-id" "persistent-entity-id"
] ]
} }
]]></artwork> ]]></sourcecode>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode name="" type="http-message"><![CDATA[
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Length: 1350 Content-Length: 1419
Content-Type: multipart/related; boundary=example-4; Content-Type: multipart/related; boundary=example-4;
type=application/alto-endpointcost+json type=application/alto-endpointcost+json
--example-4 --example-4
Content-ID: <ecs@alto.example.com> Content-ID: <ecs@alto.example.com>
Content-Type: application/alto-endpointcost+json Content-Type: application/alto-endpointcost+json
{ {
"meta": { "meta": {
"vtags": { "vtags": {
skipping to change at line 2119 skipping to change at line 2130
}, },
".ane:AGGR2": { ".ane:AGGR2": {
"max-reservable-bandwidth": 15000000000, "max-reservable-bandwidth": 15000000000,
"persistent-entity-id": "ane-props.ane:MEC2" "persistent-entity-id": "ane-props.ane:MEC2"
}, },
".ane:NET3": { ".ane:NET3": {
"max-reservable-bandwidth": 50000000000 "max-reservable-bandwidth": 50000000000
} }
} }
} }
]]></artwork> --example-4
]]></sourcecode>
</section> </section>
</section> </section>
<section anchor="Compatibility" numbered="true" toc="default"> <section anchor="Compatibility" numbered="true" toc="default">
<name>Compatibility with Other ALTO Extensions</name> <name>Compatibility with Other ALTO Extensions</name>
<section anchor="compatibility-with-legacy-alto-clientsservers" numbered=" true" toc="default"> <section anchor="compatibility-with-legacy-alto-clientsservers" numbered=" true" toc="default">
<name>Compatibility with Legacy ALTO Clients/Servers</name> <name>Compatibility with Legacy ALTO Clients/Servers</name>
<t>The multipart Filtered Cost Map resource and the multipart Endpoint C <t>The multipart filtered cost map resource and the multipart Endpoint C
ost ost
Service resource has no backward compatibility issue with legacy ALTO clients an Service resource have no backward-compatibility issues with legacy ALTO clients
d and
servers. Although these two types of resources reuse the media types defined in servers. Although these two types of resources reuse the media types defined in
the base ALTO protocol for the accept input parameters, they have different the base ALTO Protocol for the "Accept" input parameters, they have different
media types for responses. If the ALTO server provides these two types of media types for responses. If the ALTO server provides these two types of
resources, but the ALTO client does not support them, the ALTO client will resources but the ALTO client does not support them, the ALTO client will
ignore the resources without incurring any incompatibility problem.</t> ignore the resources without incurring any incompatibility problems.</t>
<!--
The Path Vector extension on Filtered Cost Map and Endpoint Cost Service is
backward compatible with the base ALTO protocol:
- If the ALTO server provides extended capabilities "dependent-property-map" and
"allow-compound-response" for Filtered Cost Map or Endpoint Cost Service, but
the client only supports the base ALTO protocol, then the client will ignore
those capabilities without conducting any incompatibility.
- If the client sends a request with the input parameter "properties", but the
server only supports the base ALTO protocol, the server will ignore this
field.
</section> </section>
<section anchor="compatibility-with-multi-cost-extension" numbered="true" toc="default"> <section anchor="compatibility-with-multi-cost-extension" numbered="true" toc="default">
<name>Compatibility with Multi-Cost Extension</name> <name>Compatibility with Multi-Cost Extension</name>
<!-- FIXME: path-vector cannot be used in multi-cost, also no reason -->
<t>The extension defined in this document is compatible with the multi-cost <t>The extension defined in this document is compatible with the multi-cost
extension <xref target="RFC8189" format="default"/>. Such a resource has a media type of either extension <xref target="RFC8189" format="default"/>. Such a resource has a media type of either
"multipart/related; type=application/alto-costmap+json" or "multipart/related; "multipart/related; type=application/alto-costmap+json" or "multipart/related;
type=application/alto-endpointcost+json". Its "cost-constraints" field must type=application/alto-endpointcost+json". Its "cost-constraints" field must be
either be "false" or not present and the Path Vector cost type must be present either "false" or not present, and the Path Vector cost type must be present
in the "cost-type-names" capability field but must not be present in the in the "cost-type-names" capability field but must not be present in the
"testable-cost-type-names" field, as specified in <xref target="pvcm-cap" format "testable-cost-type-names" field, as specified in Sections&nbsp;<xref target="pv
="default"/> and <xref target="pvecs-cap" format="default"/>.</t> cm-cap" format="counter"/> and <xref target="pvecs-cap" format="counter"/>.</t>
<!--
As [](#fcm-cap) mentions, the syntax and semantics of whether "constraints" or
"or-constraints" field for the "array" cost mode is not specified in this
document. So if an ALTO server provides a resource with the "array" cost mode
and the capability "cost-constraints" or "testable-cost-types-names", the ALTO
client MAY ignore the capability "cost-constraints" or
"testable-cost-types-names" unless the implementation or future documents
specify the behavior.
<!--
Cost type path-vector is not a testable cost type. Any format of constraints
SHOULD NOT be applied to cost type path-vector in order for multi-cost to
support the path-vector extension. Specifically,
- Cost type path-vector MUST NOT be included in "testable-cost-types-names" or
"testable-cost-types".
- When "testable-cost-types-names" is omitted in the "capabilities" and
"testable-cost-types" is omitted in the input parameters, "constraints" or
"or-constraints" SHOULD NOT add any format of constraints on cost type
path-vector.
</section> </section>
<section anchor="compatibility-with-incremental-update" numbered="true" to c="default"> <section anchor="compatibility-with-incremental-update" numbered="true" to c="default">
<name>Compatibility with Incremental Update</name> <name>Compatibility with Incremental Update Extension</name>
<!-- FIXME: using resource-id header in MIME part -->
<t>This extension is compatible with the incremental update extension <xref targ et="RFC8895" format="default"/>. <t>This extension is compatible with the incremental update extension <xref targ et="RFC8895" format="default"/>.
ALTO clients and servers MUST follow the specifications given in Sections 5.2 ALTO clients and servers <bcp14>MUST</bcp14> follow the specifications given in
and 6.7.3 of <xref target="RFC8895" format="default"/> to support incremental up Sections&nbsp;<xref target="RFC8895" section=
dates for a Path Vector "5.2" sectionFormat="bare"/> and <xref target="RFC8895" section="6.7.3" sectionF
ormat="bare"/> of <xref target="RFC8895"/> to support incremental updates for a
Path Vector
resource.</t> resource.</t>
</section> </section>
<section anchor="compatibility-with-cost-calendar" numbered="true" toc="de fault"> <section anchor="compatibility-with-cost-calendar" numbered="true" toc="de fault">
<name>Compatibility with Cost Calendar</name> <name>Compatibility with Cost Calendar Extension</name>
<t>The extension specified in this document is compatible with the Cost Calendar <t>The extension specified in this document is compatible with the Cost Calendar
extension <xref target="RFC8896" format="default"/>. When used together with the Cost Calendar extension, the extension <xref target="RFC8896" format="default"/>. When used together with the Cost Calendar extension, the
cost value between a source and a destination is an array of Path Vectors, where cost value between a source and a destination is an array of Path Vectors, where
the k-th Path Vector refers to the abstract network paths traversed in the k-th the k-th Path Vector refers to the abstract network paths traversed in the k-th
time interval by traffic from the source to the destination.</t> time interval by traffic from the source to the destination.</t>
<t>When used with time-varying properties, e.g., maximum reservable band width, a <t>When used with time-varying properties, e.g., maximum reservable band width, a
property of a single ANE may also have different values in different time property of a single ANE may also have different values in different time
intervals. In this case, if such an ANE has different property values in two intervals. In this case, if such an ANE has different property values in two
time intervals, it MUST be treated as two different ANEs, i.e., with different time intervals, it <bcp14>MUST</bcp14> be treated as two different ANEs, i.e., w ith different
entity identifiers. However, if it has the same property values in two time entity identifiers. However, if it has the same property values in two time
intervals, it MAY use the same identifier.</t> intervals, it <bcp14>MAY</bcp14> use the same identifier.</t>
<t>This rule allows the Path Vector extension to represent both changes of ANEs and <t>This rule allows the Path Vector extension to represent both changes of ANEs and
changes of the ANEs' properties in a uniform way. The Path Vector part is changes of the ANEs' properties in a uniform way. The Path Vector part is
calendared in a compatible way, and the Property Map part is not affected by the calendared in a compatible way, and the property map part is not affected by the
calendar extension.</t> Cost Calendar extension.</t>
<t>The two extensions combined together can provide the historical netwo rk <t>The two extensions combined together can provide the historical netwo rk
correlation information for a set of source and destination pairs. A network correlation information for a set of source and destination pairs. A network
broker or client may use this information to derive other resource requirements broker or client may use this information to derive other resource requirements
such as Time-Block-Maximum Bandwidth, Bandwidth-Sliding-Window, and such as Time-Block-Maximum Bandwidth, Bandwidth-Sliding-Window, and
Time-Bandwidth-Product (TBP) (See <xref target="SENSE" format="default"/> for de tails).</t> Time-Bandwidth-Product (TBP) (see <xref target="SENSE" format="default"/> for de tails).</t>
</section> </section>
</section> </section>
<section anchor="SecDisc" numbered="true" toc="default"> <section anchor="SecDisc" numbered="true" toc="default">
<name>General Discussions</name> <name>General Discussion</name>
<!--
Cost Calendar is proposed as a useful ALTO extension to provide the historical
cost values for Filtered Cost Map Service and Endpoint Cost Service. Since path
vector is an extension to these services, it SHOULD be compatible with Cost
Calendar extension.
However, the calendar of a path-vector (Endpoint) Cost Map is insufficient for
the application which requires the historical data of routing state information.
The (Endpoint) Cost Map can only provide the changes of the paths. But more
useful information is the history of network element properties which are
recorded in the dependent Network Element Property Map.
Before the Unified Property Map is introduced as an ALTO extension, Filtered
Cost Map Service and Endpoint Cost Service are the only resources which require
the calendar supported. Because other resources don't have to be updated
frequently. But Network Element Property Map as a use case of Unified Property
Map will collect the real-time information of the network. It SHOULD be updated
as soon as possible once the metrics of network elements change.
So the requirement is to provide a general calendar extension which not only
meets the Filtered Cost Map and Endpoint Cost Service but also applies to the
Property Map Service.
<section anchor="constraint-tests-for-general-cost-types" numbered="true" toc="d efault"> <section anchor="constraint-tests-for-general-cost-types" numbered="true" toc="d efault">
<name>Constraint Tests for General Cost Types</name> <name>Constraint Tests for General Cost Types</name>
<t>The constraint test is a simple approach to query the data. It allows <t>The constraint test is a simple approach for querying the data. It al
users to lows users to
filter the query result by specifying some boolean tests. This approach is filter query results by specifying some boolean tests. This approach is
already used in the ALTO protocol. <xref target="RFC7285" format="default"/> and already used in the ALTO Protocol. ALTO clients are permitted to specify either
<xref target="RFC8189" format="default"/> allow ALTO the "constraints" test <xref target="RFC7285" format="default"/> <xref target="R
clients to specify the "constraints" and "or-constraints" tests to better FC8189" format="default"/> or the "or-constraints" test <xref target="RFC8189"
filter the result.</t> format="default"/> to better
<t>However, the current syntax can only be used to test scalar cost type filter the results.</t>
s, and <t>However, the current syntax can only be used to test scalar cost type
s and
cannot easily express constraints on complex cost types, e.g., the Path Vector cannot easily express constraints on complex cost types, e.g., the Path Vector
cost type defined in this document.</t> cost type defined in this document.</t>
<t>In practice, developing a bespoke language for general-purpose boolea n tests can <t>In practice, developing a bespoke language for general-purpose boolea n tests can
be a complex undertaking, and it is conceivable that there are some existing be a complex undertaking, and it is conceivable that such implementations alread
implementations already (the authors have not done an exhaustive search to y exist
determine whether there are such implementations). One avenue to develop such a (the authors have not done an exhaustive search to
determine whether such implementations exist). One avenue for developing such a
language may be to explore extending current query languages like XQuery language may be to explore extending current query languages like XQuery
<xref target="XQuery" format="default"/> or JSONiq <xref target="JSONiq" format= "default"/> and integrating these with ALTO.</t> <xref target="XQuery" format="default"/> or JSONiq <xref target="JSONiq" format= "default"/> and integrating these with ALTO.</t>
<t>Filtering the Path Vector results or developing a more sophisticated filtering <t>Filtering the Path Vector results or developing a more sophisticated filtering
mechanism is beyond the scope of this document.</t> mechanism is beyond the scope of this document.</t>
</section> </section>
<section anchor="general-multi-resource-query" numbered="true" toc="defaul t"> <section anchor="general-multi-resource-query" numbered="true" toc="defaul t">
<name>General Multi-Resource Query</name> <name>General Multi-Resource Query</name>
<t>Querying multiple ALTO information resources continuously is a genera l <t>Querying multiple ALTO information resources continuously is a genera l
requirement. Enabling such a capability, however, must address general requirement. Enabling such a capability, however, must address general
issues like efficiency and consistency. The incremental update extension issues like efficiency and consistency. The incremental update extension
<xref target="RFC8895" format="default"/> supports submitting multiple queries i n a single request, and allows <xref target="RFC8895" format="default"/> supports submitting multiple queries i n a single request and allows
flexible control over the queries. However, it does not cover the case flexible control over the queries. However, it does not cover the case
introduced in this document where multiple resources are needed for a single introduced in this document where multiple resources are needed for a single
request.</t> request.</t>
<t>This extension gives an example of using a multipart message to encod <t>The extension specified in this document gives an example of using a
e the multipart message to encode the
responses from two specific ALTO information resources: a Filtered Cost Map or responses from two specific ALTO information resources: a filtered cost map or
an Endpoint Cost Service, and a Property Map. By packing multiple resources in a an Endpoint Cost Service, and a property map. &nbsp;By packing multiple resource
s in a
single response, the implication is that servers may proactively push related single response, the implication is that servers may proactively push related
information resources to clients.</t> information resources to clients.</t>
<t>Thus, it is worth looking into the direction of extending the SSE mec <t>Thus, it is worth looking into extending the SSE mechanism as
hanism as used in the incremental update extension <xref target="RFC8895" format="default"
used in the incremental update extension <xref target="RFC8895" format="default" />; or upgrading to HTTP/2
/>, or upgrading to HTTP/2 <xref target="RFC9113" format="default"/> and HTTP/3 <xref target="RFC9114" form
<xref target="I-D.ietf-httpbis-http2bis" format="default"/> and HTTP/3 <xref tar at="default"/>, which
get="I-D.ietf-quic-http" format="default"/>, which provides the ability to multiplex queries and to allow servers to proactively se
provides the ability to multiplex queries and to allow servers proactively send nd
related information resources.</t> related information resources.</t>
<t>Defining a general multi-resource query mechanism is out of the scope of this <t>Defining a general multi-resource query mechanism is out of scope for this
document.</t> document.</t>
</section> </section>
</section> </section>
<section anchor="Security" numbered="true" toc="default"> <section anchor="Security" numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>This document is an extension of the base ALTO protocol, so the Securit <t>This document is an extension of the base ALTO Protocol, so the securit
y y
Considerations <xref target="RFC7285" format="default"/> of the base ALTO protoc considerations provided for the base ALTO Protocol <xref target="RFC7285" format
ol fully apply when this ="default"/> fully apply when this
extension is provided by an ALTO server.</t> extension is provided by an ALTO server.</t>
<!-- Additional security considerations --> <t>The Path Vector extension requires additional scrutiny of three security
<!-- ## Privacy Concerns { #pricon } -->
<t>The Path Vector extension requires additional scrutiny on three security
considerations discussed in the base protocol: confidentiality of ALTO considerations discussed in the base protocol: confidentiality of ALTO
information (Section 15.3 of <xref target="RFC7285" format="default"/>), potenti information (<xref target="RFC7285" sectionFormat="of" section="15.3"/>), potent
al undesirable guidance from ial undesirable guidance from
authenticated ALTO information (Section 15.2 of <xref target="RFC7285" format="d authenticated ALTO information (<xref target="RFC7285" sectionFormat="of" sectio
efault"/>), and availability n="15.2"/>), and availability
of ALTO service (Section 15.5 of <xref target="RFC7285" format="default"/>).</t> of ALTO services (<xref target="RFC7285" sectionFormat="of" section="15.5"/>).</
t>
<t>For confidentiality of ALTO information, a network operator should be a ware that <t>For confidentiality of ALTO information, a network operator should be a ware that
this extension may introduce a new risk: the Path Vector information, when used this extension may introduce a new risk: the Path Vector information, when used
together with sensitive ANE properties such as capacities of bottleneck links, together with sensitive ANE properties such as capacities of bottleneck links,
may make network attacks easier. For example, as the Path Vector information may may make network attacks easier. For example, as the Path Vector information may
reveal more fine-grained internal network structures than the base protocol, an reveal more fine-grained internal network structures than the base protocol, an
attacker may identify the bottleneck link and start a distributed attacker may identify the bottleneck link or links and start a distributed
denial-of-service (DDoS) attack involving minimal flows to conduct the denial-of-service (DDoS) attack involving minimal flows, triggering
in-network congestion. Given the potential risk of leaking sensitive in-network congestion. Given the potential risk of leaking sensitive
information, the Path Vector extension is mainly applicable in scenarios where information, the Path Vector extension is mainly applicable in scenarios where
1) the ANE structures and ANE properties do not impose security risks to the 1) the ANE structures and ANE properties do not impose security risks on the
ALTO service provider, e.g., not carrying sensitive information, or 2) the ALTO ALTO service provider (e.g., they do not carry sensitive information) or 2) the
server and client have established a reliable trust relationship, for example, ALTO
operated in the same administrative domain, or managed by business partners with server and client have established a reliable trust relationship (e.g.,
legal contracts.</t> they operate in the same administrative domain or are managed by business partne
<t>Three risk types are identified in Section 15.3.1 of <xref target="RFC7 rs with
285" format="default"/>: (1) Excess legal contracts).</t>
disclosure of the ALTO service provider's data to an unauthorized ALTO client; <t>Three risk types are identified in <xref target="RFC7285" sectionFormat
(2) Disclosure of the ALTO service provider's data (e.g., network topology ="of" section="15.3.1"/>:</t>
information or endpoint addresses) to an unauthorized third party; and (3)
Excess retrieval of the ALTO service provider's data by collaborating ALTO <ol spacing="normal" type="(%d)">
clients. To mitigate these risks, an ALTO server MUST follow the guidelines in <li>excess disclosure of the ALTO service provider's data to an unauthorized A
Section 15.3.2 of <xref target="RFC7285" format="default"/>. Furthermore, an ALT LTO client,</li>
O server MUST follow the <li>disclosure of the ALTO service provider's data (e.g., network topology
information or endpoint addresses) to an unauthorized third party, and</li>
<li>excess retrieval of the ALTO service provider's data by collaborating ALTO
clients.</li>
</ol>
<t>To mitigate these risks, an ALTO server <bcp14>MUST</bcp14> follow the guidel
ines in <xref target="RFC7285" sectionFormat="of" section="15.3.2"/>. Furthermor
e, an ALTO server <bcp14>MUST</bcp14> follow the
following additional protections strategies for risk types (1) and (3).</t> following additional protections strategies for risk types (1) and (3).</t>
<t>For risk type (1), an ALTO server MUST use the authentication methods s <t>For risk type (1), an ALTO server <bcp14>MUST</bcp14> use the authentic
pecified ation methods specified
in Section 15.3.2 of <xref target="RFC7285" format="default"/> to authenticate t in <xref target="RFC7285" sectionFormat="of" section="15.3.2"/> to authenticate
he identify of an ALTO client, the identity of an ALTO client
and apply access control techniques to restrict unprivileged ALTO clients from and apply access control techniques to restrict the retrieval of sensitive Path
retrieving sensitive Path Vector information. For settings where the ALTO server Vector information by unprivileged ALTO clients. For settings where the ALTO ser
ver
and client are not in the same trust domain, the ALTO server should reach and client are not in the same trust domain, the ALTO server should reach
agreements with the ALTO client on protecting the confidentiality before agreements with the ALTO client regarding protection of confidentiality before
granting the access to Path Vector service with sensitive information. Such granting access to Path Vector services with sensitive information. Such
agreements may include legal contracts or Digital Right Management (DRM) agreements may include legal contracts or Digital Rights Management (DRM)
techniques. Otherwise, the ALTO server MUST NOT offer the Path Vector service techniques. Otherwise, the ALTO server <bcp14>MUST NOT</bcp14> offer Path Vector
carrying sensitive information to the clients unless the potential risks are services that
carry sensitive information to the clients, unless the potential risks are
fully assessed and mitigated.</t> fully assessed and mitigated.</t>
<t>For risk type (3), an ALTO service provider must be aware that persiste nt ANEs <t>For risk type (3), an ALTO service provider must be aware that persiste nt ANEs
may be used as "landmarks" in collaborative inferences. Thus, they should only may be used as "landmarks" in collaborative inferences. Thus, they should only
be used when exposing public service access points (e.g., API gateways, CDNi) be used when exposing public service access points (e.g., API gateways, CDN Inte
and/or when the granularity is coarse-grained (e.g., when an ANE represents an rconnections)
AS, a data center or a WAN). and/or when the granularity is coarse grained (e.g., when an ANE represents an
Otherwise, an ALTO server MUST use dynamic mappings from ephemeral ANE names to AS, a data center, or a WAN).
Otherwise, an ALTO server <bcp14>MUST</bcp14> use dynamic mappings from ephemera
l ANE names to
underlying physical entities. Specifically, for the same physical entity, an underlying physical entities. Specifically, for the same physical entity, an
ALTO server SHOULD assign a different ephemeral ANE name when the entity appears ALTO server <bcp14>SHOULD</bcp14> assign a different ephemeral ANE name when the
in the responses to different clients or even for different request from the entity appears
same client. A RECOMMENDED assignment strategy is to generate ANE names from in the responses to different clients or even for different requests from the
same client. A <bcp14>RECOMMENDED</bcp14> assignment strategy is to generate ANE
names from
random numbers.</t> random numbers.</t>
<t>Further, to protect the network topology from graph reconstruction (e.g ., <t>Further, to protect the network topology from graph reconstruction (e.g .,
through isomorphic graph identification <xref target="BONDY" format="default"/>) , the ALTO server SHOULD through isomorphic graph identification <xref target="BONDY" format="default"/>) , the ALTO server <bcp14>SHOULD</bcp14>
consider protection mechanisms to reduce information exposure or obfuscate the consider protection mechanisms to reduce information exposure or obfuscate the
real information. When doing so, the ALTO server must be aware that information real information. When doing so, the ALTO server must be aware that information
reduction/obfuscation may lead to potential Undesirable Guidance from reduction/obfuscation may lead to a potential risk of undesirable guidance from
Authenticated ALTO Information risk (Section 15.2 of <xref target="RFC7285" form authenticated ALTO information (<xref target="RFC7285" sectionFormat="of" sectio
at="default"/>).</t> n="15.2"/>).</t>
<t>Thus, implementations of ALTO servers involving reduction or obfuscatio n of the <t>Thus, implementations of ALTO servers involving reduction or obfuscatio n of the
Path Vector information SHOULD consider reduction/obfuscation mechanisms that Path Vector information <bcp14>SHOULD</bcp14> consider reduction/obfuscation mec
can preserve the integrity of ALTO information, for example, by using minimal hanisms that
can preserve the integrity of ALTO information -- for example, by using minimal
feasible region compression algorithms <xref target="NOVA" format="default"/> or obfuscation protocols feasible region compression algorithms <xref target="NOVA" format="default"/> or obfuscation protocols
<xref target="RESA" format="default"/><xref target="MERCATOR" format="default"/> <xref target="RESA" format="default"/> <xref target="MERCATOR" format="default"/
. However, these obfuscation methods are experimental and >. However, these obfuscation methods are experimental, and their
their practical applicability of these methods to the generic capability practical applicability to the generic capability
provided by this extension is not fully assessed. The ALTO server MUST carefully provided by this extension has not been fully assessed. The ALTO server <bcp14>M
UST</bcp14> carefully
verify that the deployment scenario satisfies the security assumptions of these verify that the deployment scenario satisfies the security assumptions of these
methods before applying them to protect Path Vector services with sensitive methods before applying them to protect Path Vector services with sensitive
network information.</t> network information.</t>
<t>For availability of ALTO service, an ALTO server should be cognizant th <t>For availability of ALTO services, an ALTO server should be cognizant t
at using hat using a
Path Vector extension might have a new risk: frequent requesting for Path Path Vector extension might introduce a new risk: frequent requests for Path
Vectors might consume intolerable amounts of the server-side computation and Vectors might consume intolerable amounts of server-side computation and
storage, which can break the ALTO server. For example, if an ALTO server storage. This behavior can break the ALTO server. For example, if an ALTO serve
r
implementation dynamically computes the Path Vectors for each request, the implementation dynamically computes the Path Vectors for each request, the
service providing Path Vectors may become an entry point for denial-of-service service that provides the Path Vectors may become an entry point for denial-of-s ervice
attacks on the availability of an ALTO server.</t> attacks on the availability of an ALTO server.</t>
<t>To mitigate this risk, an ALTO server may consider using optimizations such as <t>To mitigate this risk, an ALTO server may consider using such optimizat ions as
precomputation-and-projection mechanisms <xref target="MERCATOR" format="default "/> to reduce the overhead for precomputation-and-projection mechanisms <xref target="MERCATOR" format="default "/> to reduce the overhead for
processing each query. Also, an ALTO server may also protect itself from processing each query. An ALTO server may also protect itself from
malicious clients by monitoring the behaviors of clients and stopping serving malicious clients by monitoring client behavior and stopping service to
clients with suspicious behaviors (e.g., sending requests at a high frequency).< clients that exhibit suspicious behavior (e.g., sending requests at a high frequ
/t> ency).</t>
<t>The ALTO service providers must be aware that providing incremental upd ates of <t>The ALTO service providers must be aware that providing incremental upd ates of
the "max-reservable-bandwidth" may provide information about other consumers of "max-reservable-bandwidth" may provide information about other consumers of
the network. For example, a change of the value may indicate one or more the network. For example, a change in value may indicate that one or more
reservations has been made or changed. To mitigate this risk, an ALTO server reservations have been made or changed. To mitigate this risk, an ALTO server
can batch the updates and/or add a random delay before publishing the updates.</ t> can batch the updates and/or add a random delay before publishing the updates.</ t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default"> <section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<section anchor="alto-cost-metric-registry" numbered="true" toc="default"> <section anchor="alto-cost-metrics-registry" numbered="true" toc="default"
<name>ALTO Cost Metric Registry</name> >
<t>This document registers a new entry to the ALTO Cost Metric Registry, <name>&quot;ALTO Cost Metrics&quot; Registry</name>
as <t>This document registers a new entry in the "ALTO Cost Metrics" regist
instructed by Section 14.2 of <xref target="RFC7285" format="default"/>. The new ry, per
entry <xref target="RFC7285" sectionFormat="of" section="14.2"/>. The new entry
is as shown below in <xref target="tbl-cost-metric" format="default"/>.</t> is as shown below in <xref target="tbl-cost-metric" format="default"/>.</t>
<table anchor="tbl-cost-metric" align="center"> <table anchor="tbl-cost-metric" align="center">
<name>ALTO Cost Metric Registry</name> <name>&quot;ALTO Cost Metrics&quot; Registry</name>
<thead> <thead>
<tr> <tr>
<th align="left">Identifier</th> <th align="left">Identifier</th>
<th align="left">Intended Semantics</th> <th align="left">Intended Semantics</th>
<th align="left">Security Considerations</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">ane-path</td> <td align="left">ane-path</td>
<td align="left">See <xref target="metric-spec" format="default"/> </td> <td align="left">See <xref target="metric-spec" format="default"/> </td>
<td align="left">See <xref target="Security" format="default"/></t d> <td align="left">RFC 9275</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="alto-cost-mode-registry" numbered="true" toc="default"> <section anchor="alto-cost-modes-registry" numbered="true" toc="default">
<name>ALTO Cost Mode Registry</name> <name>&quot;ALTO Cost Modes&quot; Registry</name>
<t>This document registers a new entry to the ALTO Cost Mode Registry, a <t>This document registers a new entry in the "ALTO Cost Modes" registry
s , per
instructed by Section 4 of <xref target="I-D.bw-alto-cost-mode" format="default" <xref target="RFC9274" sectionFormat="of" section="5"/>. The new entry
/>. The new entry
is as shown below in <xref target="tbl-cost-mode" format="default"/>.</t> is as shown below in <xref target="tbl-cost-mode" format="default"/>.</t>
<table anchor="tbl-cost-mode" align="center"> <table anchor="tbl-cost-mode" align="center">
<name>ALTO Cost Mode Registry</name> <name>&quot;ALTO Cost Modes&quot; Registry</name>
<thead> <thead>
<tr> <tr>
<th align="left">Identifier</th> <th align="left">Identifier</th>
<th align="left">Description</th>
<th align="left">Intended Semantics</th> <th align="left">Intended Semantics</th>
<th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">array</td> <td align="left">array</td>
<td align="left">Indicates that the cost value is a JSON array</td >
<td align="left">See <xref target="mode-spec" format="default"/></ td> <td align="left">See <xref target="mode-spec" format="default"/></ td>
<td align="left">RFC 9275</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="alto-entity-domain-type-registry" numbered="true" toc="de <section anchor="alto-entity-domain-types-registry" numbered="true" toc="d
fault"> efault">
<name>ALTO Entity Domain Type Registry</name> <name>&quot;ALTO Entity Domain Types&quot; Registry</name>
<t>This document registers a new entry to the ALTO Domain Entity Type Re <t>This document registers a new entry in the "ALTO Entity Domain Types"
gistry, as registry, per
instructed by Section 12.2 of <xref target="I-D.ietf-alto-unified-props-new" for <xref target="RFC9240" sectionFormat="of" section="12.3"/>. The new entry
mat="default"/>. The new entry
is as shown below in <xref target="tbl-entity-domain" format="default"/>.</t> is as shown below in <xref target="tbl-entity-domain" format="default"/>.</t>
<table anchor="tbl-entity-domain" align="center"> <table anchor="tbl-entity-domain" align="center">
<name>ALTO Entity Domain Type Registry</name> <name>&quot;ALTO Entity Domain Types&quot; Registry</name>
<thead> <thead>
<tr> <tr>
<th align="left">Identifier</th> <th align="left">Identifier</th>
<th align="left">Entity Identifier Encoding</th> <th align="left">Entity Identifier Encoding</th>
<th align="left">Hierarchy &amp; Inheritance</th> <th align="left">Hierarchy and Inheritance</th>
<th align="left">Media Type of Defining Resoucrce</th> <th align="left">Media Type of Defining Resource</th>
<th align="left">Mapping to ALTO Address Type</th> <th align="left">Mapping to ALTO Address Type</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">ane</td> <td align="left">ane</td>
<td align="left">See <xref target="entity-address" format="default "/></td> <td align="left">See <xref target="entity-address" format="default "/></td>
<td align="left">None</td> <td align="left">None</td>
<td align="left">application/alto-propmap+json</td> <td align="left">application/alto-propmap+json</td>
<td align="left">false</td> <td align="left">false</td>
skipping to change at line 2476 skipping to change at line 2426
<t>None</t> <t>None</t>
</dd> </dd>
<dt> <dt>
Media Type of Defining Resource: </dt> Media Type of Defining Resource: </dt>
<dd> <dd>
<t>See <xref target="domain-defining" format="default"/>.</t> <t>See <xref target="domain-defining" format="default"/>.</t>
</dd> </dd>
<dt> <dt>
Mapping to ALTO Address Type: </dt> Mapping to ALTO Address Type: </dt>
<dd> <dd>
<t>This entity type does not map to ALTO address type.</t> <t>This entity type does not map to an ALTO address type.</t>
</dd> </dd>
<dt> <dt>
Security Considerations: </dt> Security Considerations: </dt>
<dd> <dd>
<t>In some usage scenarios, ANE addresses carried in ALTO Protocol m essages may <t>In some usage scenarios, ANE addresses carried in ALTO Protocol m essages may
reveal information about an ALTO client or an ALTO service provider. reveal information about an ALTO client or an ALTO service provider.
Applications and ALTO service providers using addresses of ANEs will be made If a naming schema is used to generate ANE names, either
aware of how (or if) the addressing scheme relates to private information and used privately or standardized by a future extension, how
network proximity, in further iterations of this document.</t> (or if) the naming schema relates to private information
and network proximity must be explained to ALTO implementers
and service providers.</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="alto-entity-property-type-registry" numbered="true" toc=" <section anchor="alto-entity-property-types-registry" numbered="true" toc=
default"> "default">
<name>ALTO Entity Property Type Registry</name> <name>&quot;ALTO Entity Property Types&quot; Registry</name>
<t>Two initial entries "max-reservable-bandwidth" and "persistent-entity <t>Two initial entries -- "max-reservable-bandwidth" and "persistent-ent
-id" are ity-id" -- are
registered to the ALTO Domain "ane" in the "ALTO Entity Property Type Registry", registered for the ALTO domain "ane" in the "ALTO Entity Property Types" registr
as instructed by Section 12.3 of <xref target="I-D.ietf-alto-unified-props-new" y,
format="default"/>. The two per <xref target="RFC9240" sectionFormat="of" section="12.4"/>. The two
new entries are shown below in <xref target="tbl-prop-type-reg" format="default" new entries are shown below in <xref target="tbl-prop-type-reg" format="default"
/> and their details can be />, and their details can be
found in <xref target="mrb-iana" format="default"/> and <xref target="pei-iana" found in Sections&nbsp;<xref target="mrb-iana" format="counter"/> and <xref targ
format="default"/>.</t> et="pei-iana" format="counter"/> of this document.</t>
<table anchor="tbl-prop-type-reg" align="center"> <table anchor="tbl-prop-type-reg" align="center">
<name>Initial Entries for ane Domain in the ALTO Entity Property Types Registry</name> <name>Initial Entries for the &quot;ane&quot; Domain in the &quot;ALTO Entity Property Types&quot; Registry</name>
<thead> <thead>
<tr> <tr>
<th align="left">Identifier</th> <th align="left">Identifier</th>
<th align="left">Intended Semantics</th> <th align="left">Intended Semantics</th>
<th align="left">Media Type of Defining Resource</th> <th align="left">Media Type of Defining Resource</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">max-reservable-bandwidth</td> <td align="left">max-reservable-bandwidth</td>
skipping to change at line 2539 skipping to change at line 2491
<t>See <xref target="maxresbw" format="default"/>.</t> <t>See <xref target="maxresbw" format="default"/>.</t>
</dd> </dd>
<dt> <dt>
Media Type of Defining Resource: </dt> Media Type of Defining Resource: </dt>
<dd> <dd>
<t>application/alto-propmap+json</t> <t>application/alto-propmap+json</t>
</dd> </dd>
<dt> <dt>
Security Considerations: </dt> Security Considerations: </dt>
<dd> <dd>
<t>This property is essential for applications such as large-scale <t>To make better choices regarding bandwidth reservation, this pr
data operty is essential for applications such as large-scale data
transfers or overlay network interconnection to make better choice of transfers or an overlay network interconnection. It may reveal the bandwidth usa
bandwidth reservation. It may reveal the bandwidth usage of the underlying ge of the underlying
network and can potentially be leveraged to reduce the cost of conducting network and can potentially be leveraged to reduce the cost of conducting
denial-of-service attacks. Thus, the ALTO server MUST consider protection denial-of-service attacks. Thus, the ALTO server <bcp14>MUST</bcp14> consider su
mechanisms including only providing the information to authorized clients, and ch protection
information reduction and obfuscation as introduced in <xref target="Security" f mechanisms as providing the information to authorized clients only and applying
ormat="default"/>.</t> information reduction and obfuscation as discussed in <xref target="Security" fo
rmat="default"/>.</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="pei-iana" numbered="true" toc="default"> <section anchor="pei-iana" numbered="true" toc="default">
<name>New ANE Property Type: Persistent Entity ID</name> <name>New ANE Property Type: Persistent Entity ID</name>
<dl> <dl>
<dt> <dt>
Identifier: </dt> Identifier: </dt>
<dd> <dd>
<t>"persistent-entity-id"</t> <t>"persistent-entity-id"</t>
skipping to change at line 2572 skipping to change at line 2523
<dt> <dt>
Media Type of Defining Resource: </dt> Media Type of Defining Resource: </dt>
<dd> <dd>
<t>application/alto-propmap+json</t> <t>application/alto-propmap+json</t>
</dd> </dd>
<dt> <dt>
Security Considerations: </dt> Security Considerations: </dt>
<dd> <dd>
<t>This property is useful when an ALTO server wants to selectivel y expose <t>This property is useful when an ALTO server wants to selectivel y expose
certain service points whose detailed properties can be further queried by certain service points whose detailed properties can be further queried by
applications. The entity IDs may consider sensitive information about the applications. As mentioned in <xref target="RFC9240" sectionFormat="of"
underlying network, and an ALTO server should follow the security section="12.3.2"/>, the entity IDs may reveal sensitive information about the
considerations in Section 11 of <xref target="I-D.ietf-alto-unified-props-new" f underlying network. An ALTO server should follow the security
ormat="default"/>.</t> considerations provided in <xref target="RFC9240" sectionFormat="of" section="11
"/>.</t>
</dd> </dd>
</dl> </dl>
</section> </section>
</section> </section>
</section> </section>
</middle> </middle>
<back> <back>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC2046">
<front>
<title>Multipurpose Internet Mail Extensions (MIME) Part Two: Media
Types</title>
<author fullname="N. Freed" initials="N." surname="Freed">
<organization/>
</author>
<author fullname="N. Borenstein" initials="N." surname="Borenstein">
<organization/>
</author>
<date month="November" year="1996"/>
<abstract>
<t>This second document defines the general structure of the MIME
media typing system and defines an initial set of media types. [STANDARDS-TRACK
]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2046"/>
<seriesInfo name="DOI" value="10.17487/RFC2046"/>
</reference>
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<author fullname="S. Bradner" initials="S." surname="Bradner">
<organization/>
</author>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used to sig
nify the requirements in the specification. These words are often capitalized.
This document defines these words as they should be interpreted in IETF document
s. This document specifies an Internet Best Current Practices for the Internet
Community, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC7285">
<front>
<title>Application-Layer Traffic Optimization (ALTO) Protocol</title
>
<author fullname="R. Alimi" initials="R." role="editor" surname="Ali
mi">
<organization/>
</author>
<author fullname="R. Penno" initials="R." role="editor" surname="Pen
no">
<organization/>
</author>
<author fullname="Y. Yang" initials="Y." role="editor" surname="Yang
">
<organization/>
</author>
<author fullname="S. Kiesel" initials="S." surname="Kiesel">
<organization/>
</author>
<author fullname="S. Previdi" initials="S." surname="Previdi">
<organization/>
</author>
<author fullname="W. Roome" initials="W." surname="Roome">
<organization/>
</author>
<author fullname="S. Shalunov" initials="S." surname="Shalunov">
<organization/>
</author>
<author fullname="R. Woundy" initials="R." surname="Woundy">
<organization/>
</author>
<date month="September" year="2014"/>
<abstract>
<t>Applications using the Internet already have access to some top
ology information of Internet Service Provider (ISP) networks. For example, vie
ws to Internet routing tables at Looking Glass servers are available and can be
practically downloaded to many network application clients. What is missing is
knowledge of the underlying network topologies from the point of view of ISPs.
In other words, what an ISP prefers in terms of traffic optimization -- and a wa
y to distribute it.</t>
<t>The Application-Layer Traffic Optimization (ALTO) services defi
ned in this document provide network information (e.g., basic network location s
tructure and preferences of network paths) with the goal of modifying network re
source consumption patterns while maintaining or improving application performan
ce. The basic information of ALTO is based on abstract maps of a network. Thes
e maps provide a simplified view, yet enough information about a network for app
lications to effectively utilize them. Additional services are built on top of
the maps.</t>
<t>This document describes a protocol implementing the ALTO servic
es. Although the ALTO services would primarily be provided by ISPs, other entiti
es, such as content service providers, could also provide ALTO services. Applic
ations that could use the ALTO services are those that have a choice to which en
d points to connect. Examples of such applications are peer-to-peer (P2P) and c
ontent delivery networks.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7285"/>
<seriesInfo name="DOI" value="10.17487/RFC7285"/>
</reference>
<reference anchor="RFC2387">
<front>
<title>The MIME Multipart/Related Content-type</title>
<author fullname="E. Levinson" initials="E." surname="Levinson">
<organization/>
</author>
<date month="August" year="1998"/>
<abstract>
<t>This document defines the Multipart/Related content-type and pr
ovides examples of its use. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2387"/>
<seriesInfo name="DOI" value="10.17487/RFC2387"/>
</reference>
<reference anchor="RFC5322">
<front>
<title>Internet Message Format</title>
<author fullname="P. Resnick" initials="P." role="editor" surname="R
esnick">
<organization/>
</author>
<date month="October" year="2008"/>
<abstract>
<t>This document specifies the Internet Message Format (IMF), a sy
ntax for text messages that are sent between computer users, within the framewor
k of "electronic mail" messages. This specification is a revision of Request Fo
r Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, "
Standard for the Format of ARPA Internet Text Messages", updating it to reflect
current practice and incorporating incremental changes that were specified in ot
her RFCs. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5322"/>
<seriesInfo name="DOI" value="10.17487/RFC5322"/>
</reference>
<reference anchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba">
<organization/>
</author>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
l specifications. This document aims to reduce the ambiguity by clarifying tha
t only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC8189">
<front>
<title>Multi-Cost Application-Layer Traffic Optimization (ALTO)</tit
le>
<author fullname="S. Randriamasy" initials="S." surname="Randriamasy
">
<organization/>
</author>
<author fullname="W. Roome" initials="W." surname="Roome">
<organization/>
</author>
<author fullname="N. Schwan" initials="N." surname="Schwan">
<organization/>
</author>
<date month="October" year="2017"/>
<abstract>
<t>The Application-Layer Traffic Optimization (ALTO) protocol, spe
cified in RFC 7285, defines several services that return various metrics describ
ing the costs between network endpoints.</t>
<t>This document defines a new service that allows an ALTO Client
to retrieve several cost metrics in a single request for an ALTO filtered cost m
ap and endpoint cost map. In addition, it extends the constraints to further fi
lter those maps by allowing an ALTO Client to specify a logical combination of t
ests on several cost metrics.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8189"/>
<seriesInfo name="DOI" value="10.17487/RFC8189"/>
</reference>
<reference anchor="RFC8895">
<front>
<title>Application-Layer Traffic Optimization (ALTO) Incremental Upd
ates Using Server-Sent Events (SSE)</title>
<author fullname="W. Roome" initials="W." surname="Roome">
<organization/>
</author>
<author fullname="Y. Yang" initials="Y." surname="Yang">
<organization/>
</author>
<date month="November" year="2020"/>
<abstract>
<t>The Application-Layer Traffic Optimization (ALTO) protocol (RFC
7285) provides network-related information, called network information resource
s, to client applications so that clients can make informed decisions in utilizi
ng network resources. This document presents a mechanism to allow an ALTO server
to push updates to ALTO clients to achieve two benefits: (1) updates can be inc
remental, in that if only a small section of an information resource changes, th
e ALTO server can send just the changes and (2) updates can be immediate, in tha
t the ALTO server can send updates as soon as they are available.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8895"/>
<seriesInfo name="DOI" value="10.17487/RFC8895"/>
</reference>
<reference anchor="RFC8896">
<front>
<title>Application-Layer Traffic Optimization (ALTO) Cost Calendar</
title>
<author fullname="S. Randriamasy" initials="S." surname="Randriamasy
">
<organization/>
</author>
<author fullname="R. Yang" initials="R." surname="Yang">
<organization/>
</author>
<author fullname="Q. Wu" initials="Q." surname="Wu">
<organization/>
</author>
<author fullname="L. Deng" initials="L." surname="Deng">
<organization/>
</author>
<author fullname="N. Schwan" initials="N." surname="Schwan">
<organization/>
</author>
<date month="November" year="2020"/>
<abstract>
<t>This document is an extension to the base Application-Layer Tra
ffic 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 lik
e to schedule these transfers during an off-peak hour, for example. This extens
ion introduces the ALTO Cost Calendar with which an ALTO Server exposes ALTO cos
t 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 I
nformation Resources Directory and ALTO Server responses.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8896"/>
<seriesInfo name="DOI" value="10.17487/RFC8896"/>
</reference>
<reference anchor="I-D.ietf-alto-unified-props-new">
<front>
<title>An ALTO Extension: Entity Property Maps</title>
<author fullname="Wendy Roome">
<organization>Nokia Bell Labs</organization>
</author>
<author fullname="Sabine Randriamasy">
<organization>Nokia Bell Labs</organization>
</author>
<author fullname="Y. Richard Yang">
<organization>Yale University</organization>
</author>
<author fullname="Jingxuan Jensen Zhang">
<organization>Tongji University</organization>
</author>
<author fullname="Kai Gao">
<organization>Sichuan University</organization>
</author>
<date day="28" month="February" year="2022"/>
<abstract>
<t> This document specifies an extension to the base Application
-Layer
Traffic Optimization (ALTO) protocol that generalizes the concept of
"endpoint properties", which were so far tied to IP addresses, to
entities defined by a wide set of objects. Further, these properties
are presented as maps, similar to the network and cost maps in the
base ALTO protocol. While supporting the endpoints and related
endpoint property service defined in RFC7285, the ALTO protocol is
extended in two major directions. First, from endpoints restricted
to IP addresses to entities covering a wider and extensible set of
objects; second, from properties on specific endpoints to entire
entity property maps. These extensions introduce additional features
allowing entities and property values to be specific to a given
information resource. This is made possible by a generic and
flexible design of entity and property types.
</t> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2046.
</abstract> xml"/>
</front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.
<seriesInfo name="Internet-Draft" value="draft-ietf-alto-unified-props xml"/>
-new-24"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7285.
</reference> xml"/>
<reference anchor="I-D.bw-alto-cost-mode"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2387.
<front> xml"/>
<title>A Cost Mode Registry for the Application-Layer Traffic Optimi <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5322.
zation (ALTO) Protocol</title> xml"/>
<author fullname="Mohamed Boucadair"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.
<organization>Orange</organization> xml"/>
</author> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8189.
<author fullname="Qin Wu"> xml"/>
<organization>Huawei</organization> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8895.
</author> xml"/>
<date day="4" month="March" year="2022"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8896.
<abstract> xml"/>
<t> This document creates a new IANA registry for tracking cost
modes
supported by the Application-Layer Traffic Optimization (ALTO)
protocol. Also, this document relaxes a constraint that was imposed
by the ALTO specification on allowed cost mode values.
This document updates RFC 7285. <!-- draft-ietf-alto-unified-props-new (RFC 9240; published 7/14/2022) -->
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9240.
xml"/>
<!-- draft-bw-alto-cost-mode (replaced by draft-ietf-alto-cost-mode)
RFC 9274; published 7/26/2022) -->
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9274.
xml"/>
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-bw-alto-cost-mode-01"/>
</reference>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="RFC2216">
<front>
<title>Network Element Service Specification Template</title>
<author fullname="S. Shenker" initials="S." surname="Shenker">
<organization/>
</author>
<author fullname="J. Wroclawski" initials="J." surname="Wroclawski">
<organization/>
</author>
<date month="September" year="1997"/>
<abstract>
<t>This document defines a framework for specifying services provi
ded by network elements, and available to applications, in an internetwork which
offers multiple qualities of service. The document first provides some necessar
y context -- including relevant definitions and suggested data formats -- and th
en specifies a "template" which service specification documents should follow.
This memo provides information for the Internet community. It does not specify
an Internet standard of any kind.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2216"/>
<seriesInfo name="DOI" value="10.17487/RFC2216"/>
</reference>
<reference anchor="RFC4271">
<front>
<title>A Border Gateway Protocol 4 (BGP-4)</title>
<author fullname="Y. Rekhter" initials="Y." role="editor" surname="R
ekhter">
<organization/>
</author>
<author fullname="T. Li" initials="T." role="editor" surname="Li">
<organization/>
</author>
<author fullname="S. Hares" initials="S." role="editor" surname="Har
es">
<organization/>
</author>
<date month="January" year="2006"/>
<abstract>
<t>This document discusses the Border Gateway Protocol (BGP), whic
h is an inter-Autonomous System routing protocol.</t>
<t>The primary function of a BGP speaking system is to exchange ne
twork reachability information with other BGP systems. This network reachabilit
y information includes information on the list of Autonomous Systems (ASes) that
reachability information traverses. This information is sufficient for construc
ting a graph of AS connectivity for this reachability from which routing loops m
ay be pruned, and, at the AS level, some policy decisions may be enforced.</t>
<t>BGP-4 provides a set of mechanisms for supporting Classless Int
er-Domain Routing (CIDR). These mechanisms include support for advertising a se
t of destinations as an IP prefix, and eliminating the concept of network "class
" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes
, including aggregation of AS paths.</t>
<t>This document obsoletes RFC 1771. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4271"/>
<seriesInfo name="DOI" value="10.17487/RFC4271"/>
</reference>
<reference anchor="I-D.ietf-httpbis-http2bis">
<front>
<title>HTTP/2</title>
<author fullname="Martin Thomson">
<organization>Mozilla</organization>
</author>
<author fullname="Cory Benfield">
<organization>Apple Inc.</organization>
</author>
<date day="24" month="January" year="2022"/>
<abstract>
<t> This specification describes an optimized expression of the
semantics
of the Hypertext Transfer Protocol (HTTP), referred to as HTTP
version 2 (HTTP/2). HTTP/2 enables a more efficient use of network
resources and a reduced latency by introducing field compression and
allowing multiple concurrent exchanges on the same connection.
This document obsoletes RFC 7540 and RFC 8740.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-http2bis-0
7"/>
</reference>
<reference anchor="I-D.ietf-quic-http">
<front>
<title>Hypertext Transfer Protocol Version 3 (HTTP/3)</title>
<author fullname="Mike Bishop">
<organization>Akamai</organization>
</author>
<date day="2" month="February" year="2021"/>
<abstract>
<t>The QUIC transport protocol has several features that are desir
able
in a transport for HTTP, such as stream multiplexing, per-stream flow
control, and low-latency connection establishment. This document
describes a mapping of HTTP semantics over QUIC. This document also
identifies HTTP/2 features that are subsumed by QUIC, and describes
how HTTP/2 extensions can be ported to HTTP/3.
DO NOT DEPLOY THIS VERSION OF HTTP <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2216.
xml"/>
DO NOT DEPLOY THIS VERSION OF HTTP/3 UNTIL IT IS IN AN RFC. This <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4271.
version is still a work in progress. For trial deployments, please xml"/>
use earlier versions.
Note to Readers
Discussion of this draft takes place on the QUIC working group <!-- draft-ietf-httpbis-http2bis (RFC 9113; published) -->
mailing list (quic@ietf.org), which is archived at <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9113.
https://mailarchive.ietf.org/arch/search/?email_list=quic. xml"/>
Working Group information can be found at https://github.com/quicwg; <!-- draft-ietf-quic-http (RFC 9114; published) -->
source code and issues list for this draft can be found at <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9114.
https://github.com/quicwg/base-drafts/labels/-http. xml"/>
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-quic-http-34"/>
</reference>
<reference anchor="I-D.ietf-alto-performance-metrics">
<front>
<title>ALTO Performance Cost Metrics</title>
<author fullname="Qin Wu">
<organization>Huawei</organization>
</author>
<author fullname="Y. Richard Yang">
<organization>Yale University</organization>
</author>
<author fullname="Young Lee">
<organization>Samsung</organization>
</author>
<author fullname="Dhruv Dhody">
<organization>Huawei</organization>
</author>
<author fullname="Sabine Randriamasy">
<organization>Nokia Bell Labs</organization>
</author>
<author fullname="Luis Miguel Contreras Murillo">
<organization>Telefonica</organization>
</author>
<date day="2" month="March" year="2022"/>
<abstract>
<t> The cost metric is a basic concept in Application-Layer Traf
fic
Optimization (ALTO), and different applications may use different
types of cost metrics. Since the ALTO base protocol (RFC 7285)
defines only a single cost metric (namely, the generic "routingcost"
metric), if an application wants to issue a cost map or an endpoint
cost request in order to identify a resource provider that offers
better performance metrics (e.g., lower delay or loss rate), the base
protocol does not define the cost metric to be used.
This document addresses this issue by extending the specification to <!-- draft-ietf-alto-performance-metrics (MISSREF)
provide a variety of network performance metrics, including network Have to do "long way" for correct author initials. Also,
delay, delay variation (a.k.a, jitter), packet loss rate, hop count, "Contreras" vice "Contreras Murillo", per published RFCs
and bandwidth. 7028, 7161, 8432, 8568, 8597, and 9013. -->
<reference anchor="ALTO-PERF-METRICS">
<front>
<title>ALTO Performance Cost Metrics</title>
<author fullname="Qin Wu" initials="Q" surname="Wu">
<organization>Huawei</organization>
</author>
<author fullname="Y. Richard Yang" initials="Y" surname="Yang">
<organization>Yale University</organization>
</author>
<author fullname="Young Lee" initials="Y" surname="Lee">
<organization>Samsung</organization>
</author>
<author fullname="Dhruv Dhody" initials="D" surname="Dhody">
<organization>Huawei</organization>
</author>
<author fullname="Sabine Randriamasy" initials="S" surname="Randriamasy">
<organization>Nokia Bell Labs</organization>
</author>
<author fullname="Luis Miguel Contreras Murillo" initials="L" surname="Con
treras">
<organization>Telefonica</organization>
</author>
<date month="March" day="21" year="2022" />
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-alto-performance-metrics-
28" />
</reference>
There are multiple sources (e.g., estimation based on measurements or <!-- draft-irtf-nmrg-ibn-concepts-definitions (RFC-EDITOR as of 8/23/2022;
service-level agreement) to derive a performance metric. This keep an eye on how it progresses)
document introduces an additional "cost-context" field to the ALTO (Had to do "long way" to get "L. Z. Granville") -->
"cost-type" field to convey the source of a performance metric. <reference anchor="INTENT-BASED-NETWORKING">
<front>
<title>Intent-Based Networking - Concepts and Definitions</title>
<author initials="A" surname="Clemm" fullname="Alexander Clemm">
<organization>Futurewei</organization>
</author>
<author initials="L" surname="Ciavaglia" fullname="Laurent Ciavaglia">
<organization>Rakuten Mobile</organization>
</author>
<author initials="L. Z." surname="Granville" fullname="Lisandro Zambenedet
ti Granville">
<organization>Federal University of Rio Grande do Sul (UFRGS)</organizat
ion>
</author>
<author initials="J" surname="Tantsura" fullname="Jeff Tantsura">
<organization>Microsoft</organization>
</author>
<date month="March" day="24" year="2022" />
</front>
<seriesInfo name="Internet-Draft" value="draft-irtf-nmrg-ibn-concepts-definit
ions-09" />
</reference>
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-alto-performance-m
etrics-26"/>
</reference>
<reference anchor="XQuery" target="https://www.w3.org/TR/xquery-31/"> <reference anchor="XQuery" target="https://www.w3.org/TR/xquery-31/">
<front> <front>
<title>XQuery 3.1: An XML Query Language</title> <title>XQuery 3.1: An XML Query Language</title>
<author> <author initials="J." surname="Robie" fullname="Jonathan Robie" role ="editor">
<organization/> <organization/>
</author> </author>
<date year="2017"/> <author initials="M." surname="Dyck" fullname="Michael Dyck" role="e
ditor">
<organization/>
</author>
<author initials="J." surname="Spiegel" fullname="Josh Spiegel" role
="editor">
<organization/>
</author>
<date year="2017" month="March"/>
</front> </front>
<refcontent>W3C Recommendation</refcontent>
</reference> </reference>
<reference anchor="SEREDGE" target="https://doi.org/10.1109/NOMS47738.20
20.9110342"> <reference anchor="SEREDGE" target="https://ieeexplore.ieee.org/document
/9110342">
<front> <front>
<title>Computing at the Edge: But, what Edge?</title> <title>Computing at the Edge: But, what Edge?</title>
<author initials="L." surname="Contreras" fullname="Luis M. Contrera s"> <author initials="L." surname="Contreras" fullname="Luis M. Contrera s">
<organization>Telefonica</organization> <organization>Telefonica</organization>
</author> </author>
<author initials="J." surname="Baliosian" fullname="Javier Baliosian "> <author initials="J." surname="Baliosian" fullname="Javier Baliosian ">
<organization>Telefonica/Universidad de la República</organization > <organization>Telefonica/Universidad de la República</organization >
</author> </author>
<author initials="P." surname="Martı́nez-Julia" fullname="Pedro Mart <author initials="P." surname="Martínez-Julia" fullname="Pedro
ı́nez-Julia"> Martı́nez-Julia">
<organization>National Institute of Information and Communications Technology, Japan</organization> <organization>National Institute of Information and Communications Technology, Japan</organization>
</author> </author>
<author initials="J." surname="Serrat" fullname="Joan Serrat"> <author initials="J." surname="Serrat" fullname="Joan Serrat">
<organization>Universitat Politcnica de Catalunya</organization> <organization>Universitat Politcnica de Catalunya</organization>
</author> </author>
<date year="2020"/> <date year="2020" month="April"/>
</front> </front>
<seriesInfo name="In proceedings of the NOMS 2020 - 2020 IEEE/IFIP Net <refcontent>Proceedings of NOMS 2020 - 2020 IEEE/IFIP Network Operatio
work Operations and Management Symposium. pp. 1-9." value=""/> ns and Management Symposium, pp. 1-9</refcontent>
<seriesInfo name="DOI" value="10.1109/NOMS47738.2020.9110342"/>
</reference> </reference>
<reference anchor="MOWIE" target="https://doi.org/10.1145/3405672.340948
9"> <reference anchor="MOWIE" target="https://dl.acm.org/doi/10.1145/3405672
.3409489">
<front> <front>
<title>MoWIE: Toward Systematic, Adaptive Network Information Exposu re as an Enabling Technique for Cloud-Based Applications over 5G and Beyond</tit le> <title>MoWIE: Toward Systematic, Adaptive Network Information Exposu re as an Enabling Technique for Cloud-Based Applications over 5G and Beyond</tit le>
<author initials="Y." surname="Zhang" fullname="Yunfei Zhang"> <author initials="Y." surname="Zhang" fullname="Yunfei Zhang">
<organization>Tencent</organization> <organization>Tencent</organization>
</author> </author>
<author initials="G." surname="Li" fullname="Gang Li"> <author initials="G." surname="Li" fullname="Gang Li">
<organization>China Mobile</organization> <organization>China Mobile</organization>
</author> </author>
<author initials="C." surname="Xiong" fullname="Chunshan Xiong"> <author initials="C." surname="Xiong" fullname="Chunshan Xiong">
<organization>Tencent</organization> <organization>Tencent</organization>
skipping to change at line 3032 skipping to change at line 2692
</author> </author>
<author initials="A." surname="Walid" fullname="Anwar Walid"> <author initials="A." surname="Walid" fullname="Anwar Walid">
<organization>Nokia Bell Labs</organization> <organization>Nokia Bell Labs</organization>
</author> </author>
<author initials="Y.R." surname="Yang" fullname="Yang Richard Yang"> <author initials="Y.R." surname="Yang" fullname="Yang Richard Yang">
<organization>Yale University</organization> <organization>Yale University</organization>
</author> </author>
<author initials="Z." surname="Zhang" fullname="Zhi-Li Zhang"> <author initials="Z." surname="Zhang" fullname="Zhi-Li Zhang">
<organization>University of Minnesota</organization> <organization>University of Minnesota</organization>
</author> </author>
<date year="2020"/> <date year="2020" month="August"/>
</front> </front>
<seriesInfo name="In Proceedings of the Workshop on Network Applicatio <refcontent>Proceedings of the Workshop on Network Application Integra
n Integration/CoDesign, ACM, Virtual Event USA, 20-27." value=""/> tion/CoDesign (NAI '20), ACM, Virtual Event USA, pp. 20-27</refcontent>
<seriesInfo name="DOI" value="10.1145/3405672.3409489"/>
</reference> </reference>
<reference anchor="JSONiq" target="https://www.jsoniq.org/"> <reference anchor="JSONiq" target="https://www.jsoniq.org/">
<front> <front>
<title>The JSON Query language</title> <title>The JSON Query Language</title>
<author> <author>
<organization/> <organization>JSONiq</organization>
</author> </author>
<date year="2020"/> <date year="2022"/>
</front> </front>
</reference> </reference>
<reference anchor="MERCATOR" target="https://doi.org/10.1109/JSAC.2019.2
927073"> <reference anchor="MERCATOR" target="https://ieeexplore.ieee.org/documen
t/8756056">
<front> <front>
<title>Toward Fine-Grained, Privacy-Preserving, Efficient Multi-Doma in Network Resource Discovery</title> <title>Toward Fine-Grained, Privacy-Preserving, Efficient Multi-Doma in Network Resource Discovery</title>
<author initials="Q." surname="Xiang" fullname="Qiao Xiang"> <author initials="Q." surname="Xiang" fullname="Qiao Xiang">
<organization>Yale University</organization> <organization>Yale University</organization>
</author> </author>
<author initials="J." surname="Zhang" fullname="Jingxuan Zhang"> <author initials="J." surname="Zhang" fullname="Jingxuan Zhang">
<organization>Tongji University</organization> <organization>Tongji University</organization>
</author> </author>
<author initials="X." surname="Wang" fullname="Xin Wang"> <author initials="X." surname="Wang" fullname="Xin Wang">
<organization>Tongji University</organization> <organization>Tongji University</organization>
skipping to change at line 3075 skipping to change at line 2738
</author> </author>
<author initials="J." surname="MacAuley" fullname="John MacAuley"> <author initials="J." surname="MacAuley" fullname="John MacAuley">
<organization>ESNet</organization> <organization>ESNet</organization>
</author> </author>
<author initials="H." surname="Newman" fullname="Harvey Newman"> <author initials="H." surname="Newman" fullname="Harvey Newman">
<organization>Caltech</organization> <organization>Caltech</organization>
</author> </author>
<author initials="Y.R." surname="Yang" fullname="Yang Richard Yang"> <author initials="Y.R." surname="Yang" fullname="Yang Richard Yang">
<organization>Yale University</organization> <organization>Yale University</organization>
</author> </author>
<date year="2019"/> <date year="2019" month="August"/>
</front> </front>
<seriesInfo name="IEEE/ACM" value="IEEE Journal on Selected Areas of C <refcontent>IEEE/ACM, IEEE Journal on Selected Areas in Communications
ommunication 37(8): 1924-1940"/> , Volume 37, Issue 8, pp. 1924-1940</refcontent>
<seriesInfo name="DOI" value="10.1109/JSAC.2019.2927073"/>
</reference> </reference>
<reference anchor="NOVA" target="https://doi.org/10.1109/IWQoS.2017.7969
117"> <reference anchor="NOVA" target="https://doi.org/10.1109/TNET.2019.28999
05">
<front> <front>
<title>An objective-driven on-demand network abstraction for adaptiv e applications</title> <title>An Objective-Driven On-Demand Network Abstraction for Adaptiv e Applications</title>
<author initials="K." surname="Gao" fullname="Kai Gao"> <author initials="K." surname="Gao" fullname="Kai Gao">
<organization>Sichuan University</organization> <organization>Sichuan University</organization>
</author> </author>
<author initials="Q." surname="Xiang" fullname="Qiao Xiang"> <author initials="Q." surname="Xiang" fullname="Qiao Xiang">
<organization>Yale University</organization> <organization>Yale University</organization>
</author> </author>
<author initials="X." surname="Wang" fullname="Xin Wang"> <author initials="X." surname="Wang" fullname="Xin Wang">
<organization>Tongji University</organization> <organization>Tongji University</organization>
</author> </author>
<author initials="Y.R." surname="Yang" fullname="Yang Richard Yang"> <author initials="Y.R." surname="Yang" fullname="Yang Richard Yang">
<organization>Yale University</organization> <organization>Yale University</organization>
</author> </author>
<author initials="J." surname="Bi" fullname="Jun Bi"> <author initials="J." surname="Bi" fullname="Jun Bi">
<organization>Tsinghua University</organization> <organization>Tsinghua University</organization>
</author> </author>
<date year="2019"/> <date month="April" year="2019"/>
</front> </front>
<seriesInfo name="IEEE/ACM" value="Transactions on Networking (TON) Vo <refcontent>IEEE/ACM Transactions on Networking (TON) Vol. 27, Issue 2
l 27, no. 2 (2019): 805-818."/> , pp. 805-818</refcontent>
<seriesInfo name="DOI" value="10.1109/TNET.2019.2899905"/>
</reference> </reference>
<reference anchor="RESA" target="https://doi.org/10.1109/SC.2018.00008"> <reference anchor="RESA" target="https://ieeexplore.ieee.org/document/86 65783">
<front> <front>
<title>Fine-grained, multi-domain network resource abstraction as a fundamental primitive to enable high-performance, collaborative data sciences</t itle> <title>Fine-Grained, Multi-Domain Network Resource Abstraction as a Fundamental Primitive to Enable High-Performance, Collaborative Data Sciences</t itle>
<author initials="Q." surname="Xiang" fullname="Qiao Xiang"> <author initials="Q." surname="Xiang" fullname="Qiao Xiang">
<organization>Yale University</organization> <organization>Yale University</organization>
</author> </author>
<author initials="J." surname="Zhang" fullname="Jingxuan Zhang"> <author initials="J." surname="Zhang" fullname="Jingxuan Zhang">
<organization>Tongji University</organization> <organization>Tongji University</organization>
</author> </author>
<author initials="X." surname="Wang" fullname="Xin Wang"> <author initials="X." surname="Wang" fullname="Xin Wang">
<organization>Tongji University</organization> <organization>Tongji University</organization>
</author> </author>
<author initials="Y." surname="Liu" fullname="Yang Liu"> <author initials="Y." surname="Liu" fullname="Yang Liu">
skipping to change at line 3131 skipping to change at line 2797
</author> </author>
<author initials="J." surname="MacAuley" fullname="John MacAuley"> <author initials="J." surname="MacAuley" fullname="John MacAuley">
<organization>ESNet</organization> <organization>ESNet</organization>
</author> </author>
<author initials="H." surname="Newman" fullname="Harvey Newman"> <author initials="H." surname="Newman" fullname="Harvey Newman">
<organization>Caltech</organization> <organization>Caltech</organization>
</author> </author>
<author initials="Y.R." surname="Yang" fullname="Yang Richard Yang"> <author initials="Y.R." surname="Yang" fullname="Yang Richard Yang">
<organization>Yale University</organization> <organization>Yale University</organization>
</author> </author>
<date year="2019"/> <date year="2018" month="November"/>
</front> </front>
<seriesInfo name="Proceedings of the Super Computing 2018, 5:1-5:13" v <refcontent>SC18: International Conference for High Performance Comput
alue=""/> ing, Networking, Storage and Analysis, pp. 58-70</refcontent>
<seriesInfo name="DOI" value="10.1109/SC.2018.00008"/>
</reference> </reference>
<reference anchor="BOXOPT" target="https://doi.org/10.1609/aaai.v33i01.3
3011674"> <reference anchor="BOXOPT" target="https://ojs.aaai.org//index.php/AAAI/
article/view/3984">
<front> <front>
<title>Optimizing in the dark: Learning an optimal solution through a simple request interface</title> <title>Optimizing in the Dark: Learning an Optimal Solution through a Simple Request Interface</title>
<author initials="Q." surname="Xiang" fullname="Qiao Xiang"> <author initials="Q." surname="Xiang" fullname="Qiao Xiang">
<organization>Yale University</organization> <organization>Yale University</organization>
</author> </author>
<author initials="H." surname="Yu" fullname="Haitao Yu"> <author initials="H." surname="Yu" fullname="Haitao Yu">
<organization>Tongji University</organization> <organization>Tongji University</organization>
</author> </author>
<author initials="J." surname="Aspnes" fullname="James Aspnes"> <author initials="J." surname="Aspnes" fullname="James Aspnes">
<organization>Yale University</organization> <organization>Yale University</organization>
</author> </author>
<author initials="F." surname="Le" fullname="Franck Le"> <author initials="F." surname="Le" fullname="Franck Le">
<organization>IBM T.J. Watson Research Center</organization> <organization>IBM T.J. Watson Research Center</organization>
</author> </author>
<author initials="L." surname="Kong" fullname="Linghe Kong"> <author initials="L." surname="Kong" fullname="Linghe Kong">
<organization>Shanghai Jiao Tong University</organization> <organization>Shanghai Jiao Tong University</organization>
</author> </author>
<author initials="Y.R." surname="Yang" fullname="Yang Richard Yang"> <author initials="Y.R." surname="Yang" fullname="Yang Richard Yang">
<organization>Yale University</organization> <organization>Yale University</organization>
</author> </author>
<date year="2019"/> <date year="2019" month="July"/>
</front> </front>
<seriesInfo name="Proceedings of the AAAI Conference on Artificial Int <refcontent> Proceedings of the AAAI Conference on Artificial Intellig
elligence 33, 1674-1681" value=""/> ence 33, 1674-1681</refcontent>
<seriesInfo name="DOI" value="10.1609/aaai.v33i01.33011674 "/>
</reference> </reference>
<reference anchor="SENSE" target="https://www.es.net/network-r-and-d/sen se/"> <reference anchor="SENSE" target="https://www.es.net/network-r-and-d/sen se/">
<front> <front>
<title>Software Defined Networking (SDN) for End-to-End Networked Sc ience at the Exascale</title> <title>Software Defined Networking (SDN) for End-to-End Networked Sc ience at the Exascale</title>
<author> <author>
<organization/> <organization>ESnet</organization>
</author> </author>
<date year="2019"/> <date year="2019"/>
</front> </front>
</reference> </reference>
<reference anchor="HUG" target="https://dl.acm.org/doi/10.5555/2930611.2 930638"> <reference anchor="HUG" target="https://dl.acm.org/doi/10.5555/2930611.2 930638">
<front> <front>
<title>HUG: Multi-Resource Fairness for Correlated and Elastic Deman ds</title> <title>HUG: multi-resource fairness for correlated and elastic deman ds</title>
<author initials="M." surname="Chowdhury" fullname="Mosharaf Chowdhu ry"> <author initials="M." surname="Chowdhury" fullname="Mosharaf Chowdhu ry">
<organization>University of Michigan</organization> <organization>University of Michigan</organization>
</author> </author>
<author initials="Z." surname="Liu" fullname="Zhenhua Liu"> <author initials="Z." surname="Liu" fullname="Zhenhua Liu">
<organization>Stony Brook University</organization> <organization>Stony Brook University</organization>
</author> </author>
<author initials="A." surname="Ghodsi" fullname="Ali Ghodsi"> <author initials="A." surname="Ghodsi" fullname="Ali Ghodsi">
<organization>UC Berkeley, Databricks Inc.</organization> <organization>UC Berkeley, Databricks Inc.</organization>
</author> </author>
<author initials="I." surname="Stoica" fullname="Ion Stoica"> <author initials="I." surname="Stoica" fullname="Ion Stoica">
<organization>UC Berkeley, Databricks Inc.</organization> <organization>UC Berkeley, Databricks Inc.</organization>
</author> </author>
<date year="2016"/> <date year="2016" month="March"/>
</front> </front>
<seriesInfo name="13th USENIX Symposium on Networked Systems Design an d Implementation (NSDI 16) (Santa Clara, CA, 2016), 407-424." value=""/> <refcontent>Proceedings of the 13th USENIX Conference on Networked Sys tems Design and Implementation (NSDI'16), Santa Clara, CA, pp. 407-424</refconte nt>
</reference> </reference>
<reference anchor="SWAN" target="http://doi.acm.org/10.1145/2486001.2486
012"> <reference anchor="SWAN" target="https://dl.acm.org/doi/10.1145/2486001.
2486012">
<front> <front>
<title>Achieving High Utilization with Software-driven WAN</title> <title>Achieving high utilization with software-driven WAN</title>
<author initials="C." surname="Hong" fullname="Chi-Yao Hong"> <author initials="C." surname="Hong" fullname="Chi-Yao Hong">
<organization>Microsoft</organization> <organization>Microsoft</organization>
</author> </author>
<author initials="S." surname="Kandula" fullname="Srikanth Kandula"> <author initials="S." surname="Kandula" fullname="Srikanth Kandula">
<organization>Microsoft</organization> <organization>Microsoft</organization>
</author> </author>
<author initials="R." surname="Mahajan" fullname="Ratul Mahajan"> <author initials="R." surname="Mahajan" fullname="Ratul Mahajan">
<organization>Microsoft</organization> <organization>Microsoft</organization>
</author> </author>
<author initials="M." surname="Zhang" fullname="Ming Zhang"> <author initials="M." surname="Zhang" fullname="Ming Zhang">
skipping to change at line 3212 skipping to change at line 2884
</author> </author>
<author initials="V." surname="Gill" fullname="Vijay Gill"> <author initials="V." surname="Gill" fullname="Vijay Gill">
<organization>Microsoft</organization> <organization>Microsoft</organization>
</author> </author>
<author initials="M." surname="Nanduri" fullname="Mohan Nanduri"> <author initials="M." surname="Nanduri" fullname="Mohan Nanduri">
<organization>Microsoft</organization> <organization>Microsoft</organization>
</author> </author>
<author initials="R." surname="Wattenhofer" fullname="Roger Wattenho fer"> <author initials="R." surname="Wattenhofer" fullname="Roger Wattenho fer">
<organization>ETH</organization> <organization>ETH</organization>
</author> </author>
<date year="2013"/> <date year="2013" month="August"/>
</front> </front>
<seriesInfo name="In Proceedings of the ACM SIGCOMM 2013 Conference on <refcontent>Proceedings of the ACM SIGCOMM 2013 conference on SIGCOMM
SIGCOMM (SIGCOMM '13), ACM, New York, NY, USA, 15-26." value=""/> (SIGCOMM '13), New York, NY, pp. 15-26</refcontent>
<seriesInfo name="DOI" value="10.1145/2486001.2486012"/>
</reference> </reference>
<reference anchor="CLARINET" target="https://dl.acm.org/doi/abs/10.5555/ 3026877.3026911"> <reference anchor="CLARINET" target="https://dl.acm.org/doi/abs/10.5555/ 3026877.3026911">
<front> <front>
<title>CLARINET: WAN-Aware Optimization for Analytics Queries</title > <title>CLARINET: WAN-aware optimization for analytics queries</title >
<author initials="R." surname="Viswanathan" fullname="Raajay Viswana than"> <author initials="R." surname="Viswanathan" fullname="Raajay Viswana than">
<organization>University of Wisconsin-Madison</organization> <organization>University of Wisconsin-Madison</organization>
</author> </author>
<author initials="G." surname="Ananthanarayanan" fullname="Ganesh An anthanarayanan"> <author initials="G." surname="Ananthanarayanan" fullname="Ganesh An anthanarayanan">
<organization>Microsoft</organization> <organization>Microsoft</organization>
</author> </author>
<author initials="A." surname="Akella" fullname="Aditya Akella"> <author initials="A." surname="Akella" fullname="Aditya Akella">
<organization>University of Wisconsin-Madison</organization> <organization>University of Wisconsin-Madison</organization>
</author> </author>
<date year="2016"/> <date year="2016" month="November"/>
</front> </front>
<seriesInfo name="In 12th USENIX Symposium on Operating Systems Design <refcontent>
and Implementation (OSDI 16), USENIX Association, Savannah, GA, 435-450" value= Proceedings of the 12th USENIX conference on Operating Systems Design and Implem
""/> entation (OSDI'16), Savannah, GA, pp. 435-450</refcontent>
</reference> </reference>
<reference anchor="G2" target="https://dl.acm.org/doi/10.1145/3366707"> <reference anchor="G2" target="https://dl.acm.org/doi/10.1145/3366707">
<front> <front>
<title>On the Bottleneck Structure of Congestion-Controlled Networks </title> <title>On the Bottleneck Structure of Congestion-Controlled Networks </title>
<author initials="J." surname="Ros-Giralt" fullname="Jordi Ros-Giral t"> <author initials="J." surname="Ros-Giralt" fullname="Jordi Ros-Giral t">
<organization>Reservoir Labs</organization> <organization>Reservoir Labs</organization>
</author> </author>
<author initials="A." surname="Bohara" fullname="Atul Bohara"> <author initials="A." surname="Bohara" fullname="Atul Bohara">
<organization>Reservoir Labs</organization> <organization>Reservoir Labs</organization>
</author> </author>
<author initials="S." surname="Yellamraju" fullname="Sruthi Yellamra ju"> <author initials="S." surname="Yellamraju" fullname="Sruthi Yellamra ju">
skipping to change at line 3265 skipping to change at line 2941
</author> </author>
<author initials="J." surname="Li" fullname="Josie Li"> <author initials="J." surname="Li" fullname="Josie Li">
<organization>University of Virginia</organization> <organization>University of Virginia</organization>
</author> </author>
<author initials="Y." surname="Tan" fullname="Yuanlong Tan"> <author initials="Y." surname="Tan" fullname="Yuanlong Tan">
<organization>University of Virginia</organization> <organization>University of Virginia</organization>
</author> </author>
<author initials="M." surname="Veeraraghavan" fullname="Malathi Veer araghavan"> <author initials="M." surname="Veeraraghavan" fullname="Malathi Veer araghavan">
<organization>University of Virginia</organization> <organization>University of Virginia</organization>
</author> </author>
<date year="2019"/> <date year="2019" month="December"/>
</front> </front>
<seriesInfo name="Proceedings of the ACM on Measurement and Analysis o <refcontent>Proceedings of the ACM on Measurement and Analysis of Comp
f Computing Systems, Volume 3, Issue 3, pp 1-31" value=""/> uting Systems, Volume 3, Issue 3, pp. 1-31</refcontent>
<seriesInfo name="DOI" value="10.1145/3366707"/>
</reference> </reference>
<reference anchor="BONDY" target="https://doi.org/10.1002/jgt.3190010306
"> <reference anchor="BONDY" target="https://onlinelibrary.wiley.com/doi/10
.1002/jgt.3190010306">
<front> <front>
<title>Graph reconstruction—a survey</title> <title>Graph reconstruction--a survey</title>
<author initials="J.A." surname="Bondy" fullname="John Adrian Bondy" > <author initials="J.A." surname="Bondy" fullname="John Adrian Bondy" >
<organization>University of Waterloo</organization> <organization>University of Waterloo</organization>
</author> </author>
<author initials="R.L." surname="Hemminger" fullname="Robert Hemming er"> <author initials="R.L." surname="Hemminger" fullname="Robert Hemming er">
<organization>Vanderbilt University</organization> <organization>Vanderbilt University</organization>
</author> </author>
<date year="1977"/> <date year="1977"/>
</front> </front>
<seriesInfo name="Journal of Graph Theory, Volume 1, Issue 3, pp 227-2 <refcontent>Journal of Graph Theory, Volume 1, Issue 3, pp. 227-268</r
68" value=""/> efcontent>
<seriesInfo name="DOI" value="10.1002/jgt.3190010306"/>
</reference> </reference>
<reference anchor="UNICORN" target="https://doi.org/10.1016/j.future.201
8.09.048"> <reference anchor="UNICORN" target="https://www.sciencedirect.com/scienc
e/article/abs/pii/S0167739X18302413?via%3Dihub">
<front> <front>
<title>Unicorn: Unified Resource Orchestration for Multi-Domain, Geo -Distributed Data Analytics</title> <title>Unicorn: Unified resource orchestration for multi-domain, geo -distributed data analytics</title>
<author initials="Q." surname="Xiang" fullname="Qiao Xiang"> <author initials="Q." surname="Xiang" fullname="Qiao Xiang">
<organization>Yale University</organization> <organization>Yale University</organization>
</author> </author>
<author initials="S." surname="Chen" fullname="Shenshen Chen"> <author initials="T." surname="Wang" fullname="X. Tony Wang">
<organization>Tongji University</organization> <organization>Tongji University</organization>
</author> </author>
<author initials="K." surname="Gao" fullname="Kai Gao"> <author initials="J." surname="Zhang" fullname="Jingxuan Jensen Zhan g">
<organization>Tsinghua University</organization> <organization>Tsinghua University</organization>
</author> </author>
<author initials="H." surname="Newman" fullname="Harvey Newman"> <author initials="H." surname="Newman" fullname="Harvey Newman">
<organization>California Institute of Technology</organization> <organization>California Institute of Technology</organization>
</author> </author>
<author initials="I." surname="Taylor" fullname="Ian Taylor">
<organization>Cardiff University</organization>
</author>
<author initials="J." surname="Zhang" fullname="Jingxuan Zhang">
<organization>Tongji University</organization>
</author>
<author initials="Y.R." surname="Yang" fullname="Yang Richard Yang"> <author initials="Y.R." surname="Yang" fullname="Yang Richard Yang">
<organization>Yale University</organization> <organization>Yale University</organization>
</author> </author>
<date year="2017"/> <author initials="Y." surname="Liu" fullname="Yang Liu">
<organization>Tongji University</organization>
</author>
<date year="2019" month="April"/>
</front> </front>
<seriesInfo name="2017 IEEE SmartWorld, Ubiquitous Intelligence Comput <refcontent>Future Generation Computer Systems, Volume 93, pp. 188-197
ing, Advanced Trusted Computed, Scalable Computing Communications, Cloud Big Dat </refcontent>
a Computing, Internet of People and Smart City Innovation (SmartWorld/SCALCOM/UI <seriesInfo name="DOI" value="10.1016/j.future.2018.09.048"/>
C/ATC/CBDCom/IOP/SCI) (Aug. 2017), 1-6." value=""/>
</reference> </reference>
</references> </references>
</references> </references>
<section anchor="acknowledgments" numbered="true" toc="default"> <section anchor="acknowledgments" numbered="false" toc="default">
<name>Acknowledgments</name> <name>Acknowledgments</name>
<t>The authors would like to thank discussions with Andreas Voellmy, Erran <t>The authors would like to thank <contact fullname="Andreas Voellmy"/>,
Li, <contact fullname="Erran Li"/>, <contact fullname="Haibin Song"/>, <contact full
Haibin Song, Haizhou Du, Jiayuan Hu, Qiao Xiang, Tianyuan Liu, Xiao Shi, Xin name="Haizhou Du"/>, <contact fullname="Jiayuan Hu"/>, <contact fullname="Tianyu
Wang, and Yan Luo. The authors thank Greg Bernstein, Dawn Chen, Wendy Roome, and an Liu"/>, <contact
Michael Scharf for their contributions to earlier drafts.</t> fullname="Xiao Shi"/>, <contact fullname="Xin Wang"/>, and <contact fullname="Ya
<t>The authors would also like to thank Tim Chown, Luis Contreras, Roman D n Luo"/> for fruitful discussions. The authors thank <contact fullname="Greg Ber
anyliw, nstein"/>, <contact fullname="Dawn Chen"/>, <contact fullname="Wendy Roome"/>, a
Benjamin Kaduk, Erik Kline, Suresh Krishnan, Murray Kucherawy, Warren Kumari, nd
Danny Lachos, Francesca Palombini, Eric Vyncke, Samuel Weiler, and Qiao Xiang <contact fullname="Michael Scharf"/> for their contributions to earlier draft ve
whose feedback and suggestions are invaluable to improve the practicability and rsions of this document.</t>
conciseness of this document, and Mohamed Boucadair, Martin Duke, Vijay Gurbani, <t>The authors would also like to thank <contact fullname="Tim Chown"/>, <
Jan Seedorf, and Qin Wu who provide great support and guidance.</t> contact fullname="Luis Contreras"/>, <contact fullname="Roman Danyliw"/>,
</section> <contact fullname="Benjamin Kaduk"/>, <contact fullname="Erik Kline"/>, <contact
<section anchor="revision-logs-to-be-removed-before-publication" numbered="t fullname="Suresh Krishnan"/>, <contact fullname="Murray Kucherawy"/>, <contact
rue" toc="default"> fullname="Warren Kumari"/>, <contact fullname="Danny Lachos"/>, <contact fullnam
<name>Revision Logs (To be removed before publication)</name> e="Francesca Palombini"/>, <contact fullname="Éric Vyncke"/>, <contact fullname=
<section anchor="changes-since-20" numbered="true" toc="default"> "Samuel Weiler"/>, and <contact fullname="Qiao Xiang"/>,
<name>Changes since -20</name> whose feedback and suggestions were invaluable for improving the practicability
<t>Reivision -21</t> and
<ul spacing="normal"> conciseness of this document; and <contact fullname="Mohamed Boucadair"/>, <cont
<li>changes the normative requirement on protecting confidentiality of act fullname="Martin Duke"/>, <contact fullname="Vijay Gurbani"/>,
PV <contact fullname="Jan Seedorf"/>, and <contact fullname="Qin Wu"/>, who provide
information with softer language</li> d great support and guidance.</t>
</ul>
</section>
<section anchor="changes-since-19" numbered="true" toc="default">
<name>Changes since -19</name>
<t>Revision -20</t>
<ul spacing="normal">
<li>changes the IANA registry information</li>
<li>adopts the comments from IESG reviews</li>
</ul>
</section>
<section anchor="changes-since-18" numbered="true" toc="default">
<name>Changes since -18</name>
<t>Revision -19</t>
<ul spacing="normal">
<li>adds detailed examples for use cases</li>
<li>clarify terms with ambiguous meanings</li>
</ul>
</section>
<section anchor="changes-since-17" numbered="true" toc="default">
<name>Changes since -17</name>
<t>Revision -18</t>
<ul spacing="normal">
<li>changes the specification for content-id to conform to <xref targe
t="RFC2387" format="default"/> and <xref target="RFC5322" format="default"/></li
>
<li>adds IPv6 examples</li>
</ul>
</section>
<section anchor="changes-since-16" numbered="true" toc="default">
<name>Changes since -16</name>
<t>Revision -17</t>
<ul spacing="normal">
<li>adds items for media type of defining resources in IANA considerat
ions</li>
</ul>
</section>
<section anchor="changes-since-15" numbered="true" toc="default">
<name>Changes since -15</name>
<t>Revision -16</t>
<ul spacing="normal">
<li>resolves the compatibility with the Multi-Cost extension (RFC 8189
)</li>
<li>adds media types of defining resources for ANE property types (for
IANA
registration)</li>
</ul>
</section>
<section anchor="changes-since-14" numbered="true" toc="default">
<name>Changes since -14</name>
<t>Revision -15</t>
<ul spacing="normal">
<li>fixes the IDNits warnings,</li>
<li>fixes grammar issues,</li>
<li>addresses the comments in the AD review.</li>
</ul>
</section>
<section anchor="changes-since-13" numbered="true" toc="default">
<name>Changes since -13</name>
<t>Revision -14</t>
<ul spacing="normal">
<li>addresses the comments in the chair review,</li>
<li>fixes most issues raised by IDNits.</li>
</ul>
</section>
<section anchor="changes-since-12" numbered="true" toc="default">
<name>Changes since -12</name>
<t>Revision -13</t>
<ul spacing="normal">
<li>changes the abstract based on the chairs' reviews</li>
<li>integrates Richard's responds to WGLC reviews</li>
</ul>
</section>
<section anchor="changes-since-11" numbered="true" toc="default">
<name>Changes since -11</name>
<t>Revision -12</t>
<ul spacing="normal">
<li>clarifies the definition of ANEs in a similar way as how Network E
lements is
defined in <xref target="RFC2216" format="default"/></li>
<li>restructures several paragraphs that are not clear (Sec 3, Path Ve
ctor bullet, Sec 4.2, Sec 5.1.3, Sec 6.2.4, Sec 6.4.2, Sec 9.3)</li>
<li>uses "ALTO Entity Domain Type Registry"</li>
</ul>
</section>
<section anchor="changes-since-10" numbered="true" toc="default">
<name>Changes since -10</name>
<t>Revision -11</t>
<ul spacing="normal">
<li>replaces "part" with "components" in the abstract;</li>
<li>identifies additional requirements (AR) derived from the flow sche
duling
example, and introduces how the extension addresses the additional
requirements</li>
<li>fixes the inconsistent use of "start" parameter in multipart respo
nses;</li>
<li>specifies explicitly how to handle "cost-constraints";</li>
<li>uses the latest IANA registration mechanism defined in
<xref target="I-D.ietf-alto-unified-props-new" format="default"/>;</li>
<li>renames "persistent-entities" to "persistent-entity-id";</li>
<li>makes "application/alto-propmap+json" as the media type of definin
g resources
for the "ane" domain;</li>
<li>updates the examples;</li>
<li>adds the discussion on ephemeral and persistent ANEs.</li>
</ul>
</section>
<section anchor="changes-since-09" numbered="true" toc="default">
<name>Changes since -09</name>
<t>Revision -10</t>
<ul spacing="normal">
<li>
<t>revises the introduction which
</t>
<ul spacing="normal">
<li>extends the scope where the PV extension can be applied beyond
the "path
correlation" information</li>
</ul>
</li>
<li>brings back the capacity region use case to better illustrate the
problem</li>
<li>revises the overview to explain and defend the concepts and decisi
on choices</li>
<li>fixes inconsistent terms, typos</li>
</ul>
</section>
<section anchor="changes-since-08" numbered="true" toc="default">
<name>Changes since -08</name>
<t>This revision</t>
<ul spacing="normal">
<li>fixes a few spelling errors</li>
<li>emphasizes that abstract network elements can be generated on dema
nd in both
introduction and motivating use cases</li>
</ul>
</section>
<section anchor="changes-since-version-06" numbered="true" toc="default">
<name>Changes Since Version -06</name>
<ul spacing="normal">
<li>
<t>We emphasize the importance of the path vector extension in two a
spects: </t>
<ol spacing="normal" type="1"><li>It expands the problem space that
can be solved by ALTO, from preferences
of network paths to correlations of network paths.</li>
<li>It is motivated by new usage scenarios from both application's
and
network's perspectives.</li>
</ol>
</li>
<li>More use cases are included, in addition to the original capacity
region use
case.</li>
<li>We add more discussions to fully explore the design space of the p
ath vector
extension and justify our design decisions, including the concept of abstract
network element, cost type (reverted to -05), newer capabilities and the
multipart message.</li>
<li>Fix the incremental update process to be compatible with SSE -16 d
raft, which
uses client-id instead of resource-id to demultiplex updates.</li>
<li>Register an additional ANE property (i.e., persistent-entities) to
cover all
use cases mentioned in the draft.</li>
</ul>
</section>
</section> </section>
</back> </back>
<!-- ##markdown-source:
H4sIAOwtN2IAA+y9WXsbR5Yo+B6/Ii78YHIMgMTCRSyXpyiSlujWZpG2y227
fRNAgkwLyERlJkixJNXX8xvufbk/477O68zj/Ir+JXO22DITICQvVdVtVFkE
conlxIkTZz+dTkdNsnEazeMjPcmjadlJ4nLaiWZl1llE5XXnJh6XWd7p76ky
KWfwVOs41cdPLp/rs9dlnBZJlh7pF/Ck/pqebKloNMrjmyN6qPPiazWOyvgq
y++OdPx6oSbw60i/OT2+PHunVLLIj3SZL4uyv7v7YLevojyO4NXFYpbAe9C4
us3yV1d5tlxwi0oVZZROfoxmWQoN3cWFWiRHSuuizJNxyVe0HmfzeZyWhfmd
pLPEPK91PEnKJL060mkGv8psbG7A12y+iFw7cGESL8rrIz3AVhZ5mpXJNIkn
8m6R5WUeT20/xd3c/1lprViO7BV4XUXL8jrLcfQd+A9HCW/+S1c/ijL6zevy
L1Fir8As4xjebj3Luv2hvsigBX0BkAdQ6V5bf5tcL6NUv8yiSYteGCclQP7k
Ok6vJku+kk2g0f3eLnzkwjItc3oqSSO6lOUAnItkTI19lSY3cV5AQ3QvnkfJ
7Ei/ipKrKPtTMV5248myO07DWXzb1U/i2JvFt9DLlb1m++QZ/EsG6+71HM0L
eNrv7g5fn8Vxt3z9pyu81AVIqrDPi65+CbiRJ9E8Ku68vi+iEax+7aYB5ksY
Q6wnsf46mc3inwAbPdA9y/4a3XmAe9Ab7lfg9nkepePYDf9Z9iqJ9MN4NtNP
olHhT6OgkXRzN5I/pfh0ZwRPd2bwdMO8EJgvu/rbSEAiAIWf+iWsUZRP3D0z
p72efpFnxQJQQ1/QNX9O8a1+HN3EqTevk8twUl9dHLsZfRvN4hV4cJff/Wlc
dO/gCUSEytC/6Op/vQ7H/QXsvNeIV18A+YhT774Z+/Bwd1efRJkgsjfwC3z2
Okq8cfd3e4e7w7WIfJmlVz8lK8b/kwynm3b/iq372JVm+Ryo0E2MW/Tl5yf9
3eG++drrPZCvB/3DPXN1cHggX/cG/b58PewdDO3XQ/Pa4eGDPfeV2j3vnHYd
/V2mRGk6izxbFJ00vjWPjG75gXFWlJ05QgEoaTqtDrbfM4Md9g96QfvXZbkY
JQX97cOX4OZflsmY7tSHtIhz6gbQvTOPkeLSq3/+chkD3Ams5pjga3rQ7QHh
TvWfnz7RfOUJAHkZXcVMn8oov8I1x/6Ko52d29vb7u2gC+u2c/ly5/Vf8JXO
oLdDD/PhASt+gGh2cfby7PTRWdjtCdDXJRJ3HZW6vI712eQKrj9clm19ew3X
8Pf/yX078oufjvwVzH3S1ScZoFOcR4W9wxj8ZJkU+mnTfUa3eBZPsxQOsOaW
YU88jGZJViRRWmn5i+gmifOG25WGdwwuT6IJEq5ZpF/Gi//n/x7Nmnrltl/E
kzzTT6O8/H//9//3f6XxXztfLGdJFHbxjA7daKbP0wJAinQxm8IPQS44ZIBy
wcTn82UqJ3QB4xpfp9ksu7prwwwWdtjVEXyBO/oizvOoDHu1OxPW50U2S8ox
No4TO4nKaLZM76Jg/ftMgIs4T+ICMf8Ihqhhn4xjONrTqwIHjYv/7PnTC3pe
d/jP+dnZ2c755+cvgAaWyFro54DTMg+c2tMoBdxE3kFf3M0XsArLeVcvFl3d
6zzoNqLsJEsIX3u73V5v98EOdjo8OBgcdrHL7gO4OBj2EWOfPv/mvIKvTzO8
BCTqFsn4xV1RxgjocVsfT6IFbmc7Un8Vzl7D0JZ5rCMctj5LI1h6QHpaigR2
jYZn9cksW046D6Minvg8FYAHwK33HtGMH8Z3WTpZvyPkxFmm0zjxCLaHmUAR
0nLFe4/wpHqShK8QjdZPs1Eyi1e8d3K9TAvoTP8ZBv1ePX6bvAYQPImT93np
G5jb4+V7zg1gMsrgMK1t1XUvHaew2vob2OWTyvZr4Bwa+mw8+W0jTYd1vZF/
vU46TxoX072K2+hpkqZxkZX37sAWbMEX9S34DaBucZ0tNGCtwWQPFwGrQTzg
Hbhzkp1Ca1cpIP/J0zawY3m5BFp0doPbERiSNvT8H//+P/oH3ebDI9iJw72d
wXB3b/+g34W/D4aHD3ALfnHx/Fnyl3APXsIw8bocULN7D6ifCqDCf6GuqlDB
XX728uT48vnLSie8wz8H9q/zKI/gz6QN8EpuovFd50UeAyhvAG5tfTadJuME
Z/x0OSuTzmkGDImD3UtYjGU+jvVpUoxxH99tcJh92YU95C8048CXSZRVbmyE
QXXWzrVp2bsmMtHIiNVa/nMX9kat4T8DEL750CZRHEmWTfvIv/w+LZ6AmLbM
XtVIFowyuE5tnl08i+vEgNr5HAWlSiskULzyr1Mr5w+f6svuFwidEjAQUSGO
8vG1PgFsifOVy/Q0Gh8vZ/FddaWy67R+777xPu6i+DCvsS6Po/wmvqveY1IP
vCOcSytXxpdtKqvzflTO8ocPqtRJ3qXjH2gLUiv4CiBY5sjtZMiXzEBWwoMS
RFGiXgGXowcHW4fbR7r3oD/s9B4MdzegQMALfHFxfNLFAXX7D/oHuwcDJBDP
nn99HBIHYJCz0U8oxt/EHZAMgeDBmDoT4AXghE5l68OJUOYRy/p4vEeGQ4i8
s30DauBpGBy4fS2DBfIKFcBvQl9+HSrwi+FaI1ufVNr9Ypn6F3msgJFXANWf
g7yXQCAKxoTCO1iRA9y6fP5sW3+dzXT/oK3TrKv7egtbBeQ93N3rgAS6yekJ
uHv+zZfZBSLvQffgwT6wsSR1vTy7qCAvHWlX5kib06E14UPLYG5uDi0fhZF1
1dNlOomQ3YZduMiTeUIIXWY6RpY21tfJ1bUvdrZByp/NolGWk6yLUIt0gefl
ON4E938/CX8/CX8/CbVuNbDqF0vYaNppUFC11tZ7R70O/DfYjGhc0HF32EXt
8iHSi4fP//z8xWVIMZ7DsTVP/op9AJJg15Mof3UEyxzlKelu4PjDZ4AoFNls
SeSivM6z5dU10IwimS9gynkMcm5RQhOw5NNoHP+dtj/gwbfVDfU4Skpo8tsP
21GAqcfFIo2riqcv4N+iemvzgf7aG+xJV/9LVoPtEzzu4vAOMxeizAVCCaBC
0PymB/gHbZHj4+Nz1PtN4xxPHDx7j3O0CI0TUpqVILonV3RrMGjr3v4BcIv7
h737N88+bJ4oipLuzWCQ7Pa6g8FuD19nTeezi4re6CKbliBQghgYT/HgDViA
i1NgAZBDPEsnnTLrwB9zH5684NPSKkhfR8UY4bNa3o2LLpzkO3Kad/IOcKWd
yU6BCvydKjDh9+OvHoWjxQsizlr59fMoyQGPC9ZUZXkezyLkv5HjPZtFRZmM
YXLIAG9yrqM69jq7nVwv8yp1f5oVgBbRtOGBRn3HGHiOBh0mdfOvTafnv17H
KTJ0tQP0oszSO/0wz7JX96L2MZyi19mkqLKQx7OkeoNHfaIfxrCecGK19Slw
QaM8Gb8qAAfH3eYezrs4IKcgNj2co/QT3tisB7vo+6t2UG9QXuuvAH3P/+zU
qR7DGhuVZ6FZ80Orf47knXhCIvxbzy5Oz2ErbQNiR3BRn8xgOdv6hPRBcL2t
h7sH//Hv/2PYH65ibWfdaDynvQZ7DvfbHnx2+g8Gu/u9Xpf+Dui4uvjm+FlF
NgN8iFE1ox8DL6q/KpNZ8lce2W2C1lfZiUZugwY2wFdgmh7XaSUwTZ1vgRg+
rhFLQMs8K6Cr5uYugPQC6Jaz6uJe5MkrANp17fYmrb5Ejuk6+qnG4ryMyuWs
dm+TJp8288pPEb4NfPI9rX0NmyaZzSqNfZ38FN2FNzYc2jMEUl7dgk8zVEJX
720IQDhASyAP2dSemhaI2VWcN95nzvPycbjLBqt2WbPiFSRFfXH+6OT506f0
duXYMre2zJf/+Pf/1Rtsi+oVLcTfwgaFb9+2WfXa20PV637DDpOTzOwwo33t
Dw/3d+Eko789MoCcPDl+ef7srMIO2qu4dzrHdKwJixhZZcdxGs3u4EwoSEub
bCTsAfi/TorbKI3K6wYcjhBNmh5oOBa+QW1rCnDvPI0mCbBEzT0+6uJAU2wN
aNQd/Fvt9lEEh9716qc2QSs4K46BLtc2+/EERhtV7208m/vpOWBar7+CpIsh
DfbxBiT9uZD0tmnquCgy4KHwbltfRDdRmkbXbf0IEG84QMwb7q1SuYW0PRoV
lr4Pdvv7hwcHXfz7oNdDDHzUr4giLH88zEr4ncbACl+U+XJcom2NdIDpFcgY
MKoOWXuz2czxWpugILDQL7Oi8yjJQfSrsvNZPkmabtOKvSSTQJbkzaYggwgP
M2RuqoiA5LlyZ+NG4Sz5FhFonkc/VVmdixwmmzTd37h5ILMgMaEXQFFm1d2B
N6McxdDaAxt38BLFHBhlbcOLeFC5uXG7IHx80SA7fosmw8qdzWUykJkuowL2
0KzuZhCjl1BWNDzwXrqpJzWtJOzZuGaQDSnE10l+laTJCheGb3HUVfgiIGYo
xV2uJ6XrmwYM+DoGSpJHIBve1Dp5GoGUABjY/Mx9vX2YzAcHKdCsp3GEFndy
DUCSRgdSkRhTgehMhPa1UQO7nIMU2NbnRbGkL4uF7gElG6ySBmtMKhsxB/v7
B7sHrEt5dvptSL8e5dHiWucxknMiXECq/uPf/2ekYaw38Sa2QVQ2IBlJJ41q
sWN0VEsr95uOFABtPsuy5k5wT8LWjudzAFIDJzSK87LhNvXzNUA7zkfJrGwW
4XsPDg5WLac18Ew1Q+ryOs7yO7s8vXB5+v2DDhwZ90vru7v9nZ+uyu6g9wBY
nF0QHxQu0FfPzk+ev6wIEDDocZanBDB06HIm3Of5+DpGhbjlcnyTL5x+cdY5
TdCzdbRE0RiFMMcI/Z3UXRddcietHgxwqYD/wnvvo/Ta3Cq1yoLyC2loE1gI
IBihC5TzcWru6hwp4t0sq6L2Oeydyg3pB87+6fTvaFv4VXRptY2oW3iVbFf6
Yh7l5TdZPpsA2zdK/rJMymxZhFozS0nRAeoGLT4TfYkO4vFE7qGR6WIMxwCa
hxzhDX3S2uz7pB8mV7xrvHaxvzyNS1zWF3GGqmSk5zQ6fYLk7DxNsxvhVN2g
dy5Ojp+AqLTz1fnJzvHlyc7Jw1Noduf8+Qu4db6tt46XV12CAvC1SOmbhKUa
Jent7/zUnS6R4xTV+YPu7vAQ6Emn07EGM6Uur+GsmWTjJZ1ACfl9xcYHHy1m
eFaNoiL23Ws6T6I7YKYu8wi9SgKpSm2hP/02us2h2/usq89LbnBS8LmHXv4n
WVHCobvgIw+vwAkJ/BlACa+S18o4LnSRqRLdK2FQnjVaj+H3JB4nk1jfXgNK
aWh9kSVpuVVs45jh2ErRRXlEPmrwQprBuqSzO5XCPHNoZraDXDLScHR31TfR
bAndAT3U0azI9NQzPlpg6cRzleNTXGE0QwGbFKEI/18W8RR4ZDKj+55xt9cZ
QNAzOOLDCfnsQwejO4Uu1UzG0ZU/SzHKAPuIrLEzY5EiZt0r/NHUd1vH3atu
G+/d6TlIngmK4wy1IobdhBZQfFCjujKmEAZoapakr9g1cZHH5AhVymKOrMxS
4MAiYF+Rb4GTH+DsT9dhSYIizGSJC4bjvQ3ssQBrFG6ODcYZj6MzltwAvZ+d
0aLl8QL9lVLSHxexDwgcJ+zjbCI9cAs4GEXmXg4nQXhBYzS+JQAmKRELbxJ+
a57x7GFjAu3FlQY6PJu51b3Ck1zZUfjLrJfIK8zuEA7SO2IaLjPjBEzQwC/z
N0M0R87VYGfR5d03TyaTWazUR0g0CHL0sPr0v8FN2g2I4IAeMPpYf5md4TDQ
KWsG6+vjVVd3Op9ZiProJW7UmpYcGDi0IwCMgeVH3ThO6cslnEnMZJ29XiBp
xWiDLehtmxAv6ObSbFyzrWGbzLLbwlG9C96yuI8R4nmhts4vXvB2lFXQV8tk
wtZ2QiZYujJb4OmHG1JPEozBgSZGMJ8Yznw8yVCzVCIAFeygEhYVmmuGBK85
zqzpPkF0kQHGlgAKIAQGuvgCzH4cw8kzIViP7nAEMC04mCwjBasIT4IgZ5YZ
xrEknS01oYwrQmFMj3WMQVTJo8LoAbr+ehfLxSLLccsDkWKSVCE21X1PSw8r
B0DDPiiIyVLVLRu70+v2uwN8/80biSl4926bjSGClEyLzfL5b+6p6ntmIVeM
MqXDIxwo0Gm2JAEtSWCCnzKc2nAdR05vfuZ2yBGhGp03FtW8IRi0Q5DbQwLd
OtBxmRezCaWKJgii534Cp/RNlCfAMChLzwoN4h+iYUze39jyhDvBU4w6GUeL
CEQH2T9Mr8x4hCIrHlaO+y2DJ/LG/fnmzb2hEO/eIdYrillgPxjkLRD6Bdqs
4UKUxjABWBKCFAaD4Du4yLhbRmUkOAmEKe7AdBErlRx5/Mrhg/137wxGPs5u
8eDgzYQ7go7ESbygMxxtk0RkkfR8QxCkc8lgogdGJD7F0jqeIrmEmd01blCA
17WldUU2X7GNzSjMgW6ORQSHumfLtN35Dg8sgAFLxstZlK86cpW0zcdnxEsP
JGDBrArwol39Ocwpfh3hqdLWP2Ujc8IQ8wTgbguDQowVEh3Y5RHAAifK68vM
gp4hM9dhkyl5H0VWM+0BoO3zDQooFR3qE+/QlpMdeHHcqIyreY7hH9bfr6Bn
CIcx/gm5BsVt0vNA7kg2oVEkKfC3O9myhD+GG4RpdvU36CkB5BkvEjUPgKgi
vztz9uvK2V/w4Q949wImkYxLy2f4K4mUewTbFNGfofuaTGTZksd7Hc8WFE4C
x00boansgrx5w34iQDiuI+SAsltcUmCNgCZNhKhbn5ARLPFtMilR8YGb2crP
yu66KVEfGdGzFx0SZsxgpsuc9rk/eFTGAwrEdCNSfsMwUdQJARJ9gwY/xip7
Ruppns1peDCvNrmu1PeDQoZvhP5vM/JuK+C8mizhO1Jac1IhfsmBBljXxZgW
bHYeAx4ShgKfxO0oBCXyrwCrW4wWwFcRrDqZVk7TbDkDxhh5Q+B5EZA+2wgQ
AzEP2L70ysDYYAPZNhcZCD53drSWdwJEOI2LRVIK4s6iBDmrETQ7TfDwp7Eg
VcHtP0texdCKo/55dAv0AajdrBCykOTKZxbhdJkmecGUCHsooleE6nJm3Olr
5nXRByhhpRzwKqgFw1GMI2DvlUArScfo0Qt4ySofJA9jkgaF/sBqXcfRhOkw
Oh6YFgJIqklGkwHAwUEBJxHMKI1R6ADw+4CTs5Rnh00iGAQE2ICggCK+g4KZ
8fV5FyU8YKJgxrzSQD8YnsQSEm7A6SSQxWb9ZcZll7hsxFuQKyxDzWzqLKFt
TKsKT7YsM22GDSMp4xbvOfsunt5mwnfhdsnCQ0GOaFkWHx5CCZB+wbAVLNEU
2ibuzm8RDWerh4VUGWYmLtoFCe/KPhyKAnQ2rKZkcBlVF8TouFNDGV62me1Z
RICOOJURsUi3jg7g6eJYi1XCU8GARVTIYRY3eLIIkW46PT9mAvAwo9VSvkR9
k0RENLxlNSce4gbdt9I74wKRwYjcGGIlBMZfBlka56W79HwcRjQymGqewEoA
DluREVgTO5eV4O4SwwodFqSyYU6MxoOnO1BEYe+J7WT4Epe8cvmaTndk5dEt
ECPEcRZwvBVxt6oyMboNn0tFNEZGtbJ7RDWBSkKLkipESTrAhONwnLMMbQ0S
gfyD654AG5tOeKNXhXLi18u7RWxE8pafYAH6xRGbbUb8lDAoeXyVWHWyU1QA
dALOXLBluZiQwxV1h2HEat37jYHHwIrqYz/9g+ilgJEBVgV2BaMYtJLLDrAX
6LlVy2yYMT6/VSTGYbPzRBAI+DuURiJnRC6scIo8sMMa5WEN7kZWVtAcDQr4
ZM5uCVkJo8I3SjAFQpzHOTbAbE08NzHyn7tDv7In24QmDn/hjCURag5bZI7i
rD/QWAJCEegVXL69ZvHohmmzv1oiCRGr4dhs7li5jUOu+IXQCE6tMSkMe4bH
NMOY1DZihmJtHgew0Mmq5HSOaEUQWCQVVJfWWx6PYpKjL28wmZxi0ldFP7P5
ATZw3N9gK7cZQwNWCtgKRHwrfWMPeCCh3MW6lkpbwE0W3n5BIQX3TA0NVrTm
TcbNQVgaPCxYBYaxDnBxzNCDDQg4yWelUX0UNRJaxQ3gVrjLFnPAsJY74lDZ
wmZRnaKIpBhaZYgCpixgQpjH5TIX+ROANgd4rSKsx4W7jIcO8lnI25A4jg28
SrNb2C9XsdHLAbM6czooJpuyQ1WUjxIgA8BhWO1CdX7wHU1iM3tMIhPV22bc
Rpad9LSR8sZk9j9JShb6Jg4lnfi0Wb84P0Vu2B9AIJ9Agx3Ua6EV4vTZDs4M
hhijEw/7n4sim5WsDjiLJYbkwzmdLSdqAeuBO7at43Lc/QP213dT8HGPN9MV
sH85bQ0SMZyUDPTe2aJR+uuiivKl44ULm2WhILZSv4KTDAgs7NrW068uLuH0
or/62XP6/vLsy6/OX56d4veLx8dPntgv5omLx8+/egL3lXxzb6Lz2NmzU34Z
rurKpafH37aYt26BgHf+/Nnxkxbr3nwag/MtmSFAcAI/R77AeLYW4zwZMcY+
PHmhe0NB3F7vASCuaFIOhu/eKQQld0W0hX+Svh2wJo5yWhrAQxCokxIYkLa2
siaiEEDxG7MYDCz3Gpy4xEgVsWmxccBEw0SeiWA7AY9rwolJjkO/AlqsyzgH
Os6yzJuPoIH5u1X8iuXm1ijbhEQJXVIBXXLq/01OJDwKogkmSCIun5Q9OLzC
pxxMv8xIa7uVeDtLkiy/oky7qOLGJo+AkqzgAFjhcKQoecgKRl8UMlafwTvP
sGl0fIBQP8GjCzeJ0kB3xq9iIeli6XEkuqJ4ZmLG6n3su2bWwfY8RSESOpGO
ccx4yIn6IdKL67uC9ZwxKW+NVj3SOeYeghMXR0fKHpxS6mJa2nIhuroC7sxq
zLidwmuoWI6sASqn5kgtNKZ4jS46JyAdoDVMTCsrgZ+QwjJBlRvgeOUuNl09
RPq9fUBD0V5SXADDn7YKya1GIx255YSG6kYcYaHGq3R93UDryauEI7ImCKAW
MGOQgqA92NqCq81KRNJ7ilSJPu0X0jmuP6xJDS6ibiiE87btMCEgXfMMMQGa
il/DoZCQxuXL7ILO4DybGTl5JeSJcPndKF3p6D609JESj2rAw2do18etRFnS
SHCAtVlSohDorsKTI3dGR5hZiWIMe8QgNY6H0drn9eKE9GYoGjH0qAk24CM+
Wl7QWXp5bu5kDnQBbCNyi0oMJnIZBB9UMmLyDCK32BFtbbvANN62GVO8uAbQ
IiXOSLPPHFbJyjx4OQbJ2LximVNosA4ey38KSNt8PnlbIUrjDjpRdBB2SEyf
ZSXvBGjQsOUitM+XwIWSQqgoUC9FU0x8YxoNim3d5lzRRcSPQns4BKfatTct
tqDhU7gvs3eU8pgMxAjvJ1EanFpwjdonvIs4RwaJdmLApSEU5DhA3JcWlsUq
D+Cxh49esEqMTb8AdtoApPhCnWzlvrVrQWN73V63b01imMQKTVtGxmKNECyR
EN9oWWZpNke5sBAH5KmhhB6nd/4CDenT5HW7xvAHB1xgN/f6VDrolVZNMI2P
I+EwjXm1YwK0zq0orLeA3WTbXnV0cAORSggpCipwgpMDyxZbCLv7FXF+m9bN
zFQ6N2ws9xH04G7ZboyB0esOmuKEBKGdERZkv2qjDJHKSsxydK+WqG3Dh91e
ze7JErU1tjKtcOtRXSnDeVTGYhUpQvxwFY0jCV5eLbmThgMfsTtZOMOkYI2L
ZgVNgkoI9oVgDcL5y1MAcYkuhqTamaDezgizCOxGWBDBiarSJ92r9tzYr/48
mcGhRz5SLNs60ioMRLMVWZ6pDJZIonO3IVIFDdaZ82DINUSgphH0yHm8eA7i
xhw1yVfEIZD+05DExonX8IqkT17KRpnf0Soym1QFYds7C7pCzmFeK3qvSFS4
lb4qMCUZMrZvPgKGZoTnHfDtH31kYh38N4SfLwTNr5IbPmCT2WzJWrab2Jgk
cQNcsxqyQR+MJ64S44ozN220HY75cGnyzUJDm7AlnBAsEsU6G8/M5sBT9yoz
4ddK7JhkvNxJ2dEHIMM+S55tSTRyXn9FHL8qAuMXbmtj/GIHnIr9Dh6+ikuj
H/MZG2qdOZAoEVPmFKTiBBkwMoyiXnfsDAIlsfvc7C26Exl40sHJIwLWyLGX
1kmjqB3zTvBCVgjPcHTNwmD1ikkUFiBkKUnDMyFYe2ZXFkGp6Wly1Zks5yPM
B4pk59KzpOCCHagCeAH0dtFbxW2PwHl7QB5Oc4qc1/g2pRO1xrKuvjDvtOAd
FMqL2z7/GbQUiebF7bBF7HA0RnOPNr2wOF3c7nWgG+pF/AzHr0bAZXSRrmjy
+NHxNQ5HxddDowpM2VyDGz1sVduhD2n7cuab2R3GvTt8RfRwpl5YQxKQsJvO
Z9QCGezwGv6ga3tIGXt7u/rpaCFj5+FKK0oYIvbzEAs8vLHLb8B6/Q0+mAqZ
BFa99vNJBz+f3PPUW/537VPQCgx+H1tc99yObU3r7/lBYBh6ZiD+c96172sj
ptf63ACA88cfpdUfvff9D7fw44/uwR/j677qPeh3d4Ep6cN4cAXe0oPQx1t/
MOb3Dg8cMA/+Na8OvOnawX3vTVM+8nvHf7ARUt//+JbQgJ/hBhFz31pwDTzQ
7Kzq6PsauIYGXAMPCju6Bnvz+/sKuIYWXEOCwsDrdOXnLe0QB669JnDd9zHg
UqPbLVjtDuzk3rb+o4af8A1/7uFPs2v4sT5e78tjMGn8ObA/h/hzSG/turf8
1ujnIPxJbR7Yn0P7M2xkD6/v28f2wrf262/hlv2benOkP/KpJ8df/LH1Mrq1
UvalUMTWO1aLsrs0ciDWscD3iA2lJ2ITQ0qN76MVx1KtWKxp0UK4DDrxr+8W
SHBINPaYOKv8MLa86CZKyK/dI3tGjR35quuApd+caLlNEXwadtIbQJR3jIEr
EFOe6r+rv0w06d6XHQlqHOQKxP5k5ZArzdcv/yKvwJQHGwFm2AyYwdr+zFPD
fxTArMSYYMvRNpLthtlm7T6zei5AU9xzz5DFdXvF5w5vI9FvzaPXbN5kH1FM
DGYc3eiKzy8qy7Kusbi3dQEsbEv4BkDZFlsj7IVhiyJGdet1S4GQnolXU4lJ
1uZJQSy2GUK9mbuW9l6qPKe4daQ1NsEf5jwTS1FBW5fgD9Peeq0/0XcgUOM1
9Y1R+QRxGG1HZAxloO2GQ8EdRV+a7gyJ61WkiwVBznI8zEizSgq5WeS3I+dy
iC4BRAndSF/rTx3xbdOlO/9SOH50g3QMsQxfNGCwLHN0/H0Vo1YPtXGvUBD1
3FUwHADxYTlXISr07fg9dTD0Rfe5T5EGSEvHJkJkS0mBCPRcWVU/WXXQFtEh
2U73jtYji8YBe2o60l4V8RWLiSSeATu910Jkhi8HLXI+Jf2FWBOTCh6RqYSa
aXncrTC09Gef/xzwn755k7SKldHd35i0MjSv0KKI6p6kO5T1q36qCDuvQQGL
a7ol/oqopjBWMotGpI24YpQ/QluEwSXEJvx46CPX71Zcpz1C1/fsdW7NMPs5
SmLGVdTDGk8y6NrF7m+02Fa56q9141LDOAJP4/df6k3W2BnYPnChUVXY6JCM
UGq5Btau6q+wprsfsKZOdjuZxVGOYjapyymOCATPJasDoKUgWKxGlaoKl6uI
VGtG+SCOz8wW+m672DKZJmwQCrv12kgTBYOgILYrlHAdvXLxNlW9QTvgO9HN
1AueUI1hbiNK486YyvnxLCfqsbQVTx8iepcVb0EyTIinbmNX0ch4dAc+u9Zh
B5WjVSdLG7R2LztrZmLy/EFrNhaQ9ZFGM+VCTBqVZgCwCYc6LJPCMtLQHGvw
+GTsm+gLdgmOAz9zD9H8JVwJNHYl9E64yhDEajjnyAy7A5E8riVCJnSQr1XJ
L1FflEn49Fo9vHVraiIoqj6tMDQycSxlLe9howLaV/FDG1OstbHKuTggK/Xo
utTjzbjtT7ctRArpGFAp8xNPSv6xTz/kzgH96Ps/hqIFgx84FfoxpPaIwFpo
knVFBjtwoIuNO2rrGN99KLA4aQlu+qZtmiSWnyLbs9NY0nZhvaJnvavSVh4I
tIcLe54aCxv0ExOjBC2OZ8uJUZllxmji6cBFneppORV6tzuCTqs0zaF/2s2E
LCNRME9YgVcAmhTTu9UOHZ4nPvl1vOz5FiAfDQ3Ro54Rt6yjn4u6qURAUrAR
kpUVW92L/2FngdXiAOrEX/bvG1vF1V1MwHeko7fOjrJ/rS2bqSB6Z1jecJ0j
MA5k8D4Dqe/ROuQQSA2wqx1wUzb2Fhx2sIEtIbS72qSsNqYDj7DGk6lL9pEL
NnNYA4ryItJWYSnOFMjCXOK1CQ8phsguB8J9BQ62N7SRWCcdBA6wvmTpvkXQ
g/jH/ovV8FXPqIPpqWfwH0b4YSic2VfeYQh0AJYG/UsADh9x5RacnNFJudRT
AJTj1NsEpjGzfr6dyovp9uMqTUBcYIg5DgPc8eikyBVkQNikwkFt2gtqI+GX
zGk129MoJkMDpWmTkTk3aY++8ZCEA/DN6Qrj2JEztg483o6xYjIM/HkqrJGx
kiWM05SOgdboyeMT5XJAPMqTid765snJo21efpoWnXzWyhbRiWwyqniBQMpL
LM6EV2bGiW8psn2yNNoKHAGsqBhsInR+Mma9WFIz2C457qpm6OTSPdbTS/kO
qxigKPHp1rGgEmzITg6WQzas2JwKGAGZq7h038a+5sUpI2QFww6T0NEct1lD
yCQfSOyChnoYTq/hDabDSBK2vcW8zJs3Ju0f2vtRykLnCo6dxTkZ59fCkQe+
Gb+Ox0x8FjPAUb315dmLbfJBGVNQM/rzM+U7e1Fg1oEGo7RHOYuY+b+QWenW
OCiOzi3IHxKd9jh5tSPOJlKNLYwkOcAAjNgx4VBOoErs8FcgX6E4vcAoe43W
PAZLxOEllJsCSNktsJTbPNiqe+IIPfEDk6sxbmG/0lwRxwBpLDghXqJv3jzq
w1eK8I3H11GaFBxVYGmqa1Cx5E+Bar5bEq90sc1Aatj7AWBw53OQhSKoNJru
ObRAzPJiwPecpbqeOqxWU8CjOe0GXEbRbHydGW4TgYPiofIZ/QbkFp8+xjag
3ohghjFCbd/EuXRQPIJjn0D2i2fABGSxRD9PyUXrOghG5wAjsr174pFnfR7D
Ee+XUJB9LV5w1ORtdMe0X8IHLESulhGQ7zJG8614iCpXTqRcpmk8K9xGxJy3
5EgkDxhPLHP/8VePMEz9zRtJb4XPKnRhp/U3kp2ZjiVo7BjgYRkdGMvSkBxy
b+Mfnid41yka139OufLDNYyZL0he0A1epU+oDV9vn/U+3we/OPt1qCVvUtDX
9eisqH8r2l0WF9/qT/8Yfj7DYX4B2Pnc4rMM9cP6fPG1N/t/0/bn2s9b9VJc
iei1t5jAjLftPa+5r7rR+vDc4qRFXXxti5bWvrZlOCXzcZ4dFmXxtUthWdwg
TZP8uRGXRsJcN8hzCo4ptuW1E0dNtumJrWewdcSNzWD2tje3m+a5NX5ufhl0
kZDKZnQx0OJKhvnPQpcNp2UcBgQM32/83tvwz6bvAb3CP6cnPf7TV4EBODK2
qLPXodRBx14lid47ZLoz0UlYLhOdIy0/N/Fcc8oCvXJO6m48EruFUjGQNMuz
FEkphBAeBUQaAepSkv4xaifl5bZOunG3bRQFr6xnJj6knPvPTZClw2lLnKs9
eTbhoSPcATm/OA0vCNF4JeTwmyku7M2rjAzTVhLQlBba/La81PpV+x4xyRLN
TZbYbqZNHr6xX/Dh9VhexXDC73UUGLcToYsjLff3gsO/EA+33M3i38y88AvQ
XeOduXJg2JLdH9+HD3xfeaB623T61sKHerRU++094Krc8OBkSY833+DG+7Yr
jayioG9lJp80NVe5YeZsKGClTe+GedLSyOqTIfF8j951V6/+SGGG8JEf//Yj
+la5h/B/qv7cFvy3Df9sh03++OOPaC25gf/JpZ1OZ8ve3/YBTk0oveXd2TFN
06Vqf/S4/tst/M+/9bd/o/+Fk6MhKH2BSUF65uIzn+SdIMmTDz1Wodsolq0h
3Cd5VhQdJKh+um5XBvMd0zEewJFS341/UAjJ7oafz/R3E3iD1vQT3dvVj0aL
ouEX/Nzjn4qwX7+1AH6rHwa/Hn3j/aT52/bNp/4LUalheKoBtRov3qjvoh8q
174b/aAYMn2EzOQH/emmYNEERxnn3hqg9D2g/NnN+63+9j1h0gySYN6N8Ame
qIFF3//ETfDEd3EVivq76Q8ByhZwtlZwFr3dc5C6Pzd6gMvbjLCdWA0nxjYq
80j+x1VCYV98isMj3CaMQgtjdpta7oBMns25WrZMlKCfTQokpe0GSbsNQnpR
xtEEBTOXNKA0IdzOTw659roehOwlaeZrEQLTIRnJWHD0+JKGLFJG4UsKL/EG
4pA3SnEwwWHt5PE8o9IsAUdj/NdZfmXtG75udB9GUme/DGeuYvUYOzO3IrTr
jPCfMTtGw1IWTNsi6/LcmuADmAykNTVPKXqqb52Pxe9k4DRDGF1PfOERdIO2
M+4Gv3F7+G0qbiMlhS/KjGQA4lp4xAQvOtJv9OhIfxelce8H/a6txnhlIldw
IDENJx7AXaXw4pEe3ZILJe/gLcSMI33c+ezhNt7vN99/2Pns0Tf0wEAe2Asf
ePRN5zPc0dvsAkSu4wSNypD9ASY0tMT8SXCMMd6fyv0bM+rEdOr1qb/tfPZn
GlKSNA2ahvStPGCe6AdP4IDtxJKbxla+5QdCx6yawT7EwsIygYjSlE9qdpXl
8PbcBe5SCATlJEfzjrclbPpJg7bkLkA+CGwFsu5LEpmxsJoVRdgi9gYrBtuS
8XSWnj7jpMcSB3Q2uYpBENJXuWSWyVEtiriaTaK7j4sw29RWf7ff2xYt8Ygi
SgugYxhbU8mupcazrHABitgoACIvKrnOXJ7RE85VoU/jWUKJ5AzPtgVD3m6r
45c7X7/kvUVJFfRVNCe1c4QOF2xpwXGbFDE2Rt1Td529PDt9dMYKUfXmzdPn
35yfYSDbmhyppHWbxItZ5mV2nGFuZc7/D+AcRxQvoVCzmtnsDaiplSwrGrNG
FOKc4tSpGJskCT88U7hzHknIvkvpSZfzUUzJc09efEWyIbQ2BxKI0Wa013gR
JKuMl1yPzqq4aqRAL2TyqsCBdRicxThOEXSYPCGPpXWF6Tc45QQB91FyFY3u
sI2tR9t+z7ry4CVAQB68ZHWxagFHCHg8T4q4RR1rCSLCkBFElqL0sYXpLFFc
k1ukmGMunqJUAjkX5oG0ppNHExi+bZnhyuEnGAxPgcAoQ8eAUs+3uVmyE+Wm
QYq4Ze+h+noE0vJaSfAeb+s1gifKnZ7RzqKhlYg/rF9P27de/ecp/O5T+Xl6
Nk8tp4In1unH3rrdUZQA6aS4pgRQassFFoka8MwhS9gCKvSUowjyPCufKTFr
INe8VWzRoav3DM6fx3o9380GK9O8MBV8aNDtITpQOvsOgeC9sGF9nxTTc99n
53vvh7xYjRC6//O9nab7bG1tZfe/uUIN1Hx558dQQU/StffzR/qHom3DzxZM
c+d7D1NIWA5+bv8N/yEQSCc7DE6Rn52s7UnY33/f8eVxEqj1jxRqZYG4xbB1
vW0Fv3T19bc/vtUdtwQXjuzh55iJ3cnzsHXqQfGYPRgRSj1DQmmF9gqacyWF
0xP1HNOIEeXWqz9rlXY7FkI7/mMVPNipNPE2uOXP1lvtHeVm0pfFrPW0w7DY
JmT88cdgEWhN4Xk1Aik1BDAp2OBapzOuA9BO7PtGALlroeQYr9V1+HyZ5dyM
hiNg+H32nv4d0r97PwgRHq9/bt88d3qyQl4YYW/Syl74pn3Jv+4LGXKg/nEP
ON7xYvnHvjAUfzx8ZFiGP/Z2L9VWZqEEbWwrkUHM6/1deX+46n0PKTyE5oYG
rqHermnp0LTU6wdtYWN2A/H7w589kD43tPeBABnx6/sf+Pp4u4J5HWPoqGBg
gHRfkrPFS86Bh5hnxZ77faqaXD8lzw6F+SpPtQGss0SQ+1wymzSA6aKUQVRV
zDj4ucyOlodWAae4I54YwtDyYY/u1lec3Nnl6PJd6Yyd3NroE+eUIaBt60cv
vtquMOoGaE9gSjN9fJXHkr/q4snxtiIXFcyBGlsu3EBfvDA8VyFmuXHo7OlC
Se8mTBCMNPBdBPjwQzV/XaG/G8FC44b8ActsYWJLzOGAXsbWD5UTpjggk/hT
cShMxJlUGGbHYdcZYTGkSoab2E+sGQbbkCaHKnDYxAeInssc3cNcimS0WqHD
kvUIsHjme38EEwgE8Gp6nejOy6uJlTtIShOzizKqKypGAvJyNLFhWZEsvk20
gBKrRtfCxTx2eXv9kbQVIZWJ7jdZB1I9hglnaLefwJraMh6xLeNBaSZ8VeCZ
mfSRfn6DPcS3+s1H5uu7Sk4Jr2oKGhdThsYNO8nSu+tcB9XKvBEmow9pxDxP
lzyOSBrG9ZqC4D1LItlPGFdGyLRxkjrdnKRObZY29TJ0SV7hBKpnieSW0ibb
zLDba1f8EY+U6nX9NLxseoXlWZRr06RxRRzW4vhRFniiwnte3q4gM10t8xzi
amNaL2yoObNXNRySE92Js2UWFOVpK9XvBtkEg6JOzYlhXAJk56ZtYjpwVF7u
7Ps8rnXog8dpGZQadF2KwOZ8qsEQvNy+fmpPHEuY4dfPCozbZVnUaAMeRxgq
5IeybOSJrsSbeiMHb4RRAuOH61e2MA2qbdgQiyqdIMMN59rZOn7Z2247dzwX
L2KzvANR58SU1k8Am1EmdajvfrBueNBTf7ttXO9yCresEHJTARM7xxoW5Apr
ZtK4aNDoYJtdvu/ZNm8+wmxpE8qbY+haY6Uqmq/4yk5gZ485rZX1Mb1KAXFh
C9xG5FbHfup3yk8M2ZhDcVX9rtr2pBSDG2bcq1YUqwY+Kb/EFCMuBQ153BJp
VadAivkE4fUPF8XhHyYSoOQ3frp9nlUlGoeoRaAqjtjhPkjnF5kSQF5CxWYy
dmRdGsdyrHl5LlFpzl3a8N1q1+Ld2rZu1jllgffzvcDAnr54ciEei8JwIC+F
aGq4plEMk2j7zs01hbjtzI8XNBRD2Sng0pG2f+u4rR+SfpsCLW2sM/vYcF5o
m+ySc+5Z11eg/qUNXA9HMmXT0bTv1cDiRLK82xFwnA0YzlmTYStFLHFKx2nP
+ZHUPtNeqGSpq6tqmqDPqt5hNdcwZ439xGqO3urPDURrfTiLOFnDP6j995+B
9QR6C/CtgqUvhhuErcs/7mXtD8UVU34Dyy5fUV3B1EtkL0efCl8g/63I5NdE
tMMMH9ATZWmMagnmKpki24pdxCSbgZcVPTjN0KCDoz+DsQDCcp1Y8sIPOZp2
9cgM0uFbTqySC59PW+On3UTeDeJyOk70hibM5yqp5H1P45rQuFwqxz2T4e9e
zk7OIyu8LEznxvU6QgpKndhbNpHgnskWeX83tcRcYUwQo4apxxDOytRkgBVs
ocDYsLD8pCytyGrcIJp+KQEvFnt00DfBA5jYM+jNBA3ZHKaUzcEmMeWFgJMU
VxoO0YdopEKkbbsotTh4F6Us9mwnsQyGbIohudCIjNNjMYY7w4d+iiYRECbH
Ccjyd+06O0NLhlhtav9olNzjnLO1Kj9E2fh+r4gHEHhQ7R5cERg9l6vAHRZH
c8UhMQ2hHV0q9UqBeSSYXM2yEVnhOJ+rG2LbQYaS5FLdKanDaQoZaWd8s2Hg
yU00NsXkMC/8xwU7BoPsoZzRlqwPCK8p1r5BwZkSQjvLaNVIV9GYsL2RYkOF
YuGMaV8YNiYI3qdYjSDnvSlzWFMVBAjLh69A7nMvQkZVzJSrmmvXHFSk1JV7
dbQsFWmAomlM2Y2XhRfxaheklopEyn5OfsK970XcKz+HcBgEvyTCjV1j3BOh
OpVZZTneVXq0biwUChJEGDGltVH6GNaH8SDEgJpaB7jgHDbkabVsEkB0vG25
TMOtBt6Mw/DaOltgNGAp0SZUlc8gZVtEQrOHZskUoHM3nsXdD8WcQHkyRmUM
Boo9R7Y1soCnUBmiAuSyEOo5xKdmZIzhZPqH+WJAcd4xJ6rRpBS2ZNmtiFLI
qL9q0qCQnEVVyoglczWjMCU4RkSxX4WkLs91cZeOgblKJdOweARkmEtrySUW
WYfWLNCEAKjk3fdL0ZrglUqgq25YUTgKFiFhxuIk4SUiMpF/8fyUhU5MXUPV
d2IxnUdBEv/71JdGxSgnD6d5T6+sj4PrscPnSyeZmDAwpFJcr4x6ZhpmFFiU
Qd1Fhyl3mlipuzprPrLs6Dk1LQq7ypiKO76sEdQn28KANU9V4+V/NqmBmbwQ
fVZWRTc1nVBRb+9UYCywpVxcwJZl3Vi09GrKuDzjokri7PrCmpVBxoKAO6ty
FM0PSjQnpoP1MgBT6s00zZZU8ZwJM/B1jrRZM/spicDoMBTZglEurszjTjqG
QyJGs2h1KdLbV3mbemrIAdtaYoUQIsxygucaugFQoGTl2FAEE8yEXdYgjq07
vzteHDO0j+tD+5hdQ7ziPaSFZvSilbBXmG7IuJs5KKMVse1JjHsTTHzQkV+U
rxnDC43aMVVPGL24Gc870JgNs1zcxONCroQpTskLpmksAqfaOJo1dP4YlBsD
au4XZWUY7mKQxuSjUPdMzV+i3PLmI1TsdThiyuloPmc9iq9KIyVdjhg5u3PZ
oas656rGVfnJBBpLnlWV1vYBWczGe1YkuTFVJ5hBkFGJCyrZmuZYU3OMqELi
esuWNJNMHvyb3EdalfX7CndluUypHF7b1vpRfhusyxvjji7JcfbO6KWahlTl
g9vK1aLlI2aJXBd5FyIIKimmSDt0lUdzygBs6s04H8OTTz5R1raUSwVgFGv9
jP4EP0TECV09xovtCotN0UWkDSMVxx2z8P/dPv+pyLuf/XcKDbd+xKx7NuSg
RS9y+HqL9OuAT1UJTALCTQ4grhwxfnWLJQMQIgA4JKtUmhBYm66uE19/PTwz
iKphDaa8IiC0bEJ4L297LItJi+EARvuY+A5Vq+owvkYPTveq9B4gVVefT4PW
hSbACFvMNsVR6uWN95aquKairqPYK2RbScuOzSguT8A1Gtbtmg3S3xOteGoy
qgftGM8wIQ9oAErGq/P+I05ZQm+rpUmFaItUFdnT8J0uthE4IpcSEfpt0lKY
RtHYl05E5TsHOXBsI9PlhJ+4JCyyjgUZSyIbpuUyBCjLOIgs6zPfNumrnaNX
Y8pGEaJagoDKmVv54+Vv9Qey9uMXfDXqt1A7po0nX01tZh113n5afUNWp/rK
W2+01p0A5wJ4Kbr4GRwUf2xx0aGW8S84xkOFtJs0XjMihJ/pyyTk3cS3QOQ+
jtm8pvqCQbU/qxJvQr8iqHlSWJ2XKd8ArxhOS8ph6C0ZivKsiLYYR5U75RPS
b6ZSXWNVc421NRjJPEUY1akKhqz8vl64p7Y8AJpuDkwPGynIPAKOYEWenTJv
3MS2kkL8GuUj8mpe6xni15KkXAUFbfbmfdlEy6skViU261W8qqYfW7lcBkFT
aKgCTpK1bIlDKYfRtLeJtEuRxFpRREPKcANbziOs6JcGDGu18GWFeQ1Mek00
ZHGDgcgXCQrvdBrDEiFtZtXbaMnmYCs1JilTQjNcWcG2SJLAFBq7PpczpGVF
ycVIlsRc4utOpiTWUi5NqX4OFb3u/vpkDT2XmwlbjazxozLrLctXvwBQbWsh
a/4b4fOBbdO+00gIFzf3kMHqAWxdPdZQRDJTUGURLAfuq71cFeDQ64SdGWy9
rEqdrrAma5hPJizM5W0YD2u3GBk8y21NiYB5YYC18fSF2FqggTTuPr4JzRy0
UbV0alXBRT4RnERQ+Gs7QZ62zXRCjAHt2tsowXpnZTJjscDqujlbJVa1jYGu
YUanPtag2AR+c+A9MQ0OMbjGXoGqkrLwNI3YulEWmaJ9fsKLwphfbbU1UY5Z
pex5yrsTW6IqraRtN48FCGpgaCWyunIQoYHubDRtts/SNOwsGlTqArnSaWdZ
ojFeA6Y+kzPJVGq5Aetrshq1YK4gQSQZKypRh4BuFqbiIpcXwbbqNW9rGDvD
0wngcBqncKGTTTtGNo7KMsLUZ0phCjEjJDD4sDqZJMECLOYjqMYXYuJO0aGS
fApiURJxAV3J3IOmIMIlTqUFaDoiTxJ4GWY348xV2YQK0vFWkdRx5ihUvINF
pSHl0FAzZkq5LOmIxVziDTV9aUDar+ir6hV941l8BcCd3ZnK9TxtHnC3XnA2
KIatmnihe9kbd3QGmEnlzv1K281cCyHLnRlLtCiWM2MI57MNJWVlwWFOMcYx
A20SmEVTLCliA+8KjhRJpJ6icuYIErBRXpw5RfFrzunRKMoUdU4lKGk7mcCT
tSqosEvQSwzZ4aQollZT1rDKokqVynF3RoB+Smt/ebewkuXLDMjgc1pXxaIT
uVZ5SEKGEBZqtS+8s9GWAobZoOXmqRpUjlvnL0+3jVtsy/Nz2bGF4YGgfPJT
kaWtQJHFVYZqLxhvGHzRe6tR47WN7M58MbtTiyVlIGvcGHJ+uKm3UYfNtpw5
KRXQuI8YQtnh1bRRp+VnmLSwMvYKMRCQ3lT6RautWI4uM7PyTA1okVfX68bG
W4jdcAiWHCnpLxTIrplJish6opV1zVgtFDndoRO5saEWgaTD/QG/P7P2P1uz
jjQhDTC1DKodpqJx/3E9AvzBODg3LiePyk0c+25utI4kNraVLIxjNlchewZ7
g2CBRvE8nnZwHvPiyqkwjwvjbySG5gYTtKnJ5wPbijwMi9tM+QUA8rIwTiOe
5yCqbuhMpQZMXHu9rCja8wxxIDpEgy2sMHh4+GAPE7BVilJ6VWK5uJunnRDf
FZyC2L09BxY8GeywhIK4iRrQKI+44rzs+1IUNJf4fK4CCC9acnF+Snwiighw
vZMnE+MK4UkJ6OMYFDEU/LKQ/hjwQaKBO+enLXVNvsdd/fCOfHPRM915VdYG
IOyRN+sGFaAn7vlHxI5ng64u111NM41dK7E+BGceTob8u+0hUZJf90NSkHFe
IVJVvPmILnEhQVNWVfwjnY8QJYe1d11WRV4BUg+K91FYLJbpOdPFyK437jT1
4vyUGnM1PnfrtThFdRj4M5mEvLVkuj71Cryh8GTkkXTtNAMvJuMP6rnOcMf4
ZOiBY0XnwnGcpEUtPFG64nyqzkzGbk5CGagLj51VpG0E8WqfM8q2OIkXpBiE
07HSiFKrE0RisXPd4pZaHB1hs0PaAr7OAdW4/ryMUMqxhCWFHwm2a62erWCM
LR2qfPSg20f7xgbqHi3hNjZShM1shC1caZl6wuyKDV5zzeVdPUOOMUf7Tyrz
5LbxcQqwgbgbuPrmI8EIxD/BiIYnSYWfxuZg4Fsds/HMG14JXmpaTOFyXBsV
JD/rKAfzxgYtSJ1u6JWnxKkgA47iMbyMDtMsuZzz+qGTMHWU06jTTF/bxzBG
xj1F1HKNxsgztocc4akBtyWIForWMYDnahfGLhv5igSYTxufvd2efnVxyQXt
Q98E8n5UIdvFVeorzRemVojWtVMeZ2pYh6otnUYVeh7woUdu8HplXllRb4U+
deKhZiYTv47IeNnqskdfWsFZCxqmnHAwspquaKb4qw/ULixTlFL997ZwRncV
lxHxPa/3TcxIRdY3zB0qHHiCypsgz88mTZBTAKXJFy+fv3h6/IKny3ZBuWQm
ZdpWcJDKdGpD6vpuiIY6cJUgz/UJ8xBGcFQoFnBnqPU1DgLCEFGIm0dNHBPO
qslaz1vFtro1BYukyqjkoq+ezYWzlVNuiUnV627lSqNc5COcrEyNOKArAGHO
0bOzy15rNVpwDmdj7ypDloqdApoHUnUhWjEQsiBOxkzVaUCnJyvGYw/J3GOY
7LtIQ80JbV/zOBJ8qIktCZ/9GfyJEmodNuh7+b6Xny8K0OJxGwyTeC8gg55H
buBxzGakwPMFRN559LrDwQqoHO/YcAUiHMpDfednhQCVKEnmB1x0iellkhEv
wNyFJieFu8ZjFZWTCu36jLoMKTOlZ3bbk+XT7v3wKTolDG+KZwcHaOBhIbMC
DtUEYbz5CCYMnY9u5cSQcA7tYOCFbDiX7NVw2mZdF3GDooDkFivpTIU62MAQ
IpizIFs2PahMWFoh7o6sDGKruqXxPipSpCTFAQF8XGkhKuvOr4X1ng3i7aM7
Wo0/tgcGoB/xaSP4A1AAQQzjTvXWaCEacdrzTkVaeBp2iabz6R9qEykkllky
q6fA2AVRmxuTsznroGMz4YpDgOVETfcqKQTjxGPTuU8Zf0g7UlkJyjku+juT
A94LWfa1zElhj8LIOr9KvQIainWxzOoZoF0amdAKx3BRftscmetxElwywirt
vIS+Jgn+UXWwQYOw2JjJiTOZY+YuCkZ4LYHKFE1KB6KtbmUmZ+oBcRiHY9TY
K9thduZp0RlRCTWZN3aZ+lm3UDj/xkYn+ZUlTexy+6/hJGl49bMJiRzGKPn2
GCLYrHcK6jzY7Hnt2rIbQDkZgPWETbRiW4lvJKv2K/V2KotOafF9+wMr8iyb
Ys05Kx3DOWXfbXjqeZiG/BVXnJwo39vLI8leXnvfzZ7z8nOFnLAiByc6y3KQ
FLFMTJx3KGGYC44W8CDK2RLDnIwcJQEv8g2VJVLyLI/VqhT62kuhTx64jm8w
8s8pevY1uQIzcV9UODp6w6dYZZN8ZAbj3lbMp9CAq3yUFTGNKZFCV0LVkE/C
KWV1hXAacm4ZCeEheJow5gbqjf4VA2xts/hyE1LFLbf9mUP7Yk7hoqFRo3wb
ilRGesTSMQwXrPnWyC3gBJlFnlh3tAYmziK/dt2bXqpO5tx4gw+5J17+AacS
LiPLES4GmOkDwLki67pKrz60ZKuSx7uc21h1KKy8SMARL7aqjHDnC7+m9lXA
C9uSSkTmC9K9uwx3ZhOyCW0VP9K29vPQTBMmVt3jxGPIfrlK3zxBW7jYBhw0
MEleQW+i6Y97+MZjNDbXozcKOM/C+opAFjLy8EDR84g8BYG3b1TaLEfBwKXc
jMaIVrbNnfAfbKPPbagN24AGTtkhWQxua6cJCyvjpMKrHHO7xbYuShtw3Pns
BBOOWoK5UXt9aq+/W2/vYeez085nZ9vrKoiY98wX76me3DLxqDYu1Q9Llc+O
DW+lv6fsnvJWn/EXWFjzPL28477WGwZU4JeP9VsDp7fB69/rFcP4nl88CZJu
GVDz8xT4unpbNFKgypawKSFJl2hSSZKbBN52cUm+jYyz+JDijH3/0F6fSX2o
O0RzZazowdkvsTDIm1Y9Imh/dfVFpVaq8KeKvBqMeRmV0MBhLjFuUOJYXSip
uNWjcSsndRYluwl0msrWHQrUBQah06ZsPpVd5PJcBkBRXpJLTFmko4Co1GOV
6hC19scEtdCN8zNhIEUsQr3dZE6lUx+g4qw6hW49iHZHe3vTg87BcNjvDCd7
+53DqD/ujIbj8X50GA+iqNcSN+vmUwxOWoEWeY2PYjcY0k5s1ENX27NFNTEn
jVl/qKKXUTIJ7niAsAenPQTdud56j6GtDZ+oOFBXQ8zC+GLrie2d9xUTW4WZ
Vy4conqAsPwvJadQ7+XcvLFssSkPKrzc/amA+IhlmzJ5rh9p46eO2gG65Jtr
uOowXdbOo73Rox7JBQsVXvgHObdS3gN2dmcndhOyy/KmdbciBsWa6PxMVywp
+2WIldEa0AFs6w+T5cXzTuuyQsvDKYLoytAWKhUT5uKp1jhW9RrHs+xKiKJT
XwiXVQRiGLl+CQbcib5beS6iMoquZDeoCX15No4nS7QSr5QWJbn5snCxpMaK
7GK4vKX0V9hQFYmfkHuY8w4j+eC4wO9i/d1mSBoPWpNmCV4QrYsf4+BiF1ye
Dm85KC+HCbMwZnYRwo2W1QU4c5OJQQtsVW3VcjCA2PEc+dDbxBY693qcJMUY
g09K33uAUmg/fv7Vk1Px5hLB04uh9ESQw+6gOyQhJFAg4UFA2Zt4S+Y5Lafb
dQDBI5kCbDgLT3+7IcDNEvg7DSFDWbQ9MLvCljyHUTbh7C1qi0M148m28yFZ
48CxStnE62i2L2sQtKn2aigSDTksvUpbcTbz8ato++VdC9+OXthzRaQK9Mub
AZ8iJnoX4mWCNnE8ynVOJgQR5ESU9HuW+AKAYSohi4D8H4tuvOZuQHoVvGjy
l7OoHbg/YH712os/047PLommQXa8sKb8WuwsjP7shqgEZqXxUBxObJfthChi
kxuo9exDTZI/iafH31qfyCUl7tofwu6M0AAfcyIstuWgBztLqzZpfoKHmXXn
oGoVpBdo8N4xFIQ3PztK2lhyBNEsTq/Ka+Wy8bCcYv2LJS2cIJxlDnwzSD1f
njVUo/ycmdgi1vW+PDt5/vTp2bPTM/I4mSVzEdx4JNhaHmKJoWLwy7hvNcDb
nU2DngfIrkUhD80EEHY2ztKHoKOFDcK7lO8kykGi8Htv0O9TQEFgd01Yfg8E
Y+mAzLitT1v6xfHLy87Ls4vnX708OesgE/Wnlj59/vT4/Fnn2fHTM936rKVU
9Smse1170/RVw/e6g49JUShlQmAs1kEHNjZt3ShwJxITqgdmziASqjK8ceMI
/WmsGNwkKztRmc07JTBTYRyd2YoDjBXiAuYBrD2HEbJDesZbo3TxKtI2eBLZ
hK2GjUNfIrlYsDvRs4xjTIsqC2o9EGk+xR3s3tcmQ4xx0y9cGrZJeJAhaVEw
FY2UpXqa+ZGusRsapVAQzXwY3kcbQ2SQohpraA4ldyZNyevKLSS6clB4SiOv
7WWSY3Y76NtISvPV/XkEQHR37FRcca2n+hxctJ2PjuocrVXASR41V81KSISN
X684eXz0kVjjAneLMnA7qMPN8yZQja6zXqgUBkXWnVOtTwHInZaHv8cN2DjD
XF6+QAniOpu44a8ZbGAfc3woNfPiOQxjTm2ZpFgU4K7PUzRjvDDjLdjNx4+L
544Tem7hntsAemQJXgqrIsuEvJNiw5EbmI3cCPHQT8BZ6x/PAFXr05MHDffu
mATnE0y+fC/jv5j3jbN+mPWU2QHcs4e9wwfiWQrf0LOUEJIrjIuXnmUjrXHS
w7WVK84ZDHjdZfAqWTFi/eLr+pilPpA8+QYo5ncNNu568oRPd7vd/+OzP/yg
3jU2q490/eIfWDlGcyd/aFTn15vGc+DYmv5s7olKFCHn1JKoxEmVye7qMxBQ
VBAhw8wwtUvbCoAOS43Kb6P4YUm9KWJRlgZPvTRgYT4u7k1zseUnqzCWaTQj
iE944Zud1xmV0bQzX0CLOAdkLU0BtBNfe+hU2KaE6nI+GsWzGZ2A06oCx2jT
ldOmr/G5MJL2i/NTzq0IX/o0ZsoftRwJP6Yc92J2p1US057dEQTeWdzQTt7p
dSmX4mO4DMIXoHhXFH1dEBko6SzRk6O6O/4f7veMD+qj1N3dUQJkNzi4bVyg
nxBHeaT7uz3/Mh4HR/U26vuRvO7ecMctq55qHZlr2s+XcGQTIlRucu6CI08d
wA+8kwdbi2RSBI0W+RgvfKdbuEgt/YNrclKU7lYfblXaakBkeno1PlAL73hf
kwDtJ3N3ZwGi/v0nkD0ufcodpIdviORGQutcRJi+SmIz/80od+Z7yr5DInON
QFYolj+dX4RSrmkfSOaau+9BO0+trtPQ0CrpDNx9UDkUT2x2DJ8oEf18P7LU
NsTSmkeDQFIJIDV8G3pd+T5g3VpaYhI9fY7SzzuOYrtofYzN15OaDJScatiC
CNGjVbluYnRE++ii3RtzeOCWWaYzDDqKXyMtSNCl1fAeBsmmS8pN6BLrM4vC
k5qLTCy+I9Bgc7YQA/ZAn+iPv7DpVvxgMt2QwQpPKyApkcy1K8Bx8jtB53xa
6SAEUJAaaiVwWtWWA/iidWIKYMBMMbl//hmgFp5YTKeujQj2AespzUsuZxV3
KqN2CpomSrH9i8zXakxh2qvG0XI7y+6p1Q0ikKC1Z88vm7icezv5UCAiCf+q
INItO3EeUwm82qZoUOEYxgPNYdYviPlphA0cOQEZdi56ti1rKlllJk08bXSQ
kaLB8R3LqVbyttJWQ4uVc2MPmEZbwJEVte78opwLfIBZNa6AxMTepKxINuVP
iexZxyO6xUpnqZ2oGjxmDrt7FQVi21g6jEaQwlIoQMTkWPP5Egx1wZgtsyLh
WHHPNcdvmmMVsMLXVXnePjaU1kpQQFgR7ww1LcXJ1cUWopNhxGnzUm/X3yO7
UnkTpXmp/MHAWs7R8Z5CwD1BjiWplBXKprbAJFuOKLsoNIb6DdgteWmGSj/C
sYb+p1V9HTyQLfjQwZLG59P6qehqJSITYJ1aS3+Fzk+r60Ohcdr3F4SxjjBA
PsrvzHDN73Uj9n2uHInr7w733RTsegjmGDNEHVHIGUEcL02SE3K8uqwauygA
1CcNwWTJ6yXET/Q+KNEJxAQXNuDwpqgCrVz6ps2g74ZVadBvelrdCEdVzTEY
RlN2lXTpg64ZHqO4IoOvMC0YZ7JwGVckO9I2CMOTJ+yx4pg1Q9dqSg9/I94/
PKzZ14hlQ/Hs8w9SQ6iYwnR83qQ+QF52v//q+YIn6U0ZXVUCp33mxehqrGsz
2bmR4qNbS3RlDDba8rha+GqMBOUhNJxifgs0KmdnRJHd6PoRFVieNW2g5v/j
7seakcZdlAfhD9vSW949Gy7iBjJpQiwvlxtld2lVO2mF2vKAANW0/olJORPs
mBX4bLaZD3rPKuQfwi323cUGce0Kb6Ewgsbm3dM2m1PHWJAlJWIlZ0J9NQMm
A00RbQvX6t1qkj0aISrhW5itJE9GmEK/qoaE1tapcVMM3e8aUthYj8XRgAA+
VcLoQ98njRsQRnx1bTBfq/tehNGh9UrS+CGEcTV0agrKgPoEw/lZOdU4yEuv
JTSrkLaJ4pj2whyTK963dDZ1DhZfMz5fIjpzTpjwCAD+y7MmV/0WBCeYLK47
faDFJqGhOlBiwFe7RFtjQFuohbcbrf7etukx3pbLlvzdZJUy8YqW9oQsB+0V
b9AWowz2CNkmMocqW5FLbKZ147viRamGmd0CNsvT87siGn7FkRhdJzlvvTg3
zKYm27rStfD4VbyYZ4bcDFu90LEimJyZOLRVnboLbRNfTmKRe9urMt6xO3J/
u8rvEJI06bKrVQvO67hHsVzaZjflXGMV/KvxLKKyqbIM5thQnC+rZYcD9K26
uwzHYyxpYRSa1UzxboMGt96QU8ax5oT3JYvuHHFfleyYRjTlFpQgHhH6Gwhc
WjFu2cwepH+/s2QQ5XtfG6BWO0BxvrRajA35XkYpG0CtlIjVqdDFNiJu32Zb
QGz2hJu6AsLsjawIzE9wZlvWwkg1VUvlyihsl/nQ8DpZVirjpuQ7dxChEIYA
v/tVvcivjnI7TZMckbDiV6NaJNb5IxKrcWLqryxmEZrVAf7MMPgpUDivOgd3
43QDPxMbyyfZHnOMY1zjM8gew+zi7Mfq1zCIVIGU5gIZdeP3gfOTlWDe05kE
Daopm+5EkxfiJOO6ELX0c+QoRAUmTCGaQjwqBV4uH5CliVYv6Y/FXzwXpfYB
FqhAh2KTflEzyuJvPbk6i7ySwc24pbaAmvVaFT9wVak6Z2JhCqCB42uXSkJG
KXYpY4PS/d1d/fxfVNUKdLj3QIUmoLodyorqf5QJdXp/qERF3G+qAuayY19X
jnM70p/KY3+qWsc+U5sZp6R9NF0wW2PMRsxTOCNSIKIc6dZUWGKm0dBSZ3HT
lUatxarFbbSmo/7u6GC/vzs87A3jB5PR4CDa6/X2etMoiuJpnw1YYnOqMSVH
+jtpz1q0asOZ3+FRHAH8O7KI/jjcSA724slubzAajEd7h9PDB/vx4eDB3mF/
b3c43e/3D8WUpt/RX7GThaa6ZhvdauMctfXO6b9xYBbKZI+jRsn8BlNlBP6B
31LvVi+9sPfvv/Rhko+Gpf+QBdgIH94XI+w6WAgGB78dMEUMENwIlCttk0dY
RpA/Fr4kiH/63zogvz0/fX6kz0gv+1j0shpr24W+UM1+uM3+UJic9xdxiAo6
VTZ72y/tC9U8t1/BMeq+jn5l56iV2ezWe0jdO+pf0F3KKxmyqb/UPcPDuOUm
5yn9oc5TahE6T61MMriJB5Xxov6Ln8w0VDH2PW/qX8xrykcFmk8hrlN+/Y+V
rlP+YH8pv6kzb0TsNOVfeT+nqeaQp3ViXX0IkcktbJh981TFNyHIUm64tL+v
T1J8zS5J8fV7eSSxOxLswMAVaYUf0vs6IdVojzsd17kh1XyQ+gf3HfQrUFvO
/Lr/0Wrno3WeR3ww25LKrjXndZQsboZHvQf97i7uYet/5DkfBU/0Dlvekf8h
Hkir3I8MYXXOR4FH0AdQVE9Rp1bRCX83+cNpJoxW6Ykl29d5BwX7jTwJPXO9
Uj/PlB5YXn4VU7pZi/9ihnRjt/twQ/pqY2hDJucGS+/7Wr69qhO/tS36t7Y9
G8PWptbnJj7yP7MJuqlAzj+OCbr/z2OCtgZoaLKSvf9DTdE/wxD9j2aHDpNO
69V26H94q+s/BjW4Bz7r993vxtffja+/G19/N77+bnz93fj6u/H1v7LxNahi
HVhfN7WYDvd+PYtpTRZbYzaFmby/3ayhg/e3myIMFzdd+FOzksbj3uBgNDo4
7PUOh/uH48O9wWRvtN/vR+Pd3cG099tZSfcPDqbx3nS4u79/ODyc9A/7QL36
vUF0OJw+GPYf/NZW0or+kJqvagz/eU2nDSjxvkjxmxlKXaJP/eYj89VYNwvh
tDDoD35lc0tJiD/1ya1JDWf4BKqWSEUVMe2noUeo4sRWkPnDNM4mm2G+TNnA
gzzXKC5LOmujiYRXc/aKC847fQGC9mJFMdQNPly/9Elvo6d37FMUDM35IuXz
CSa3fGSSQtqL/OxAaYPKuzv9w0/gxifmiU/Cp/kDFz8xbwz68Ep1fG/hf0/P
Tnr0xV0MvgKV7h1NRodHR4Oj3Z3efr0NO4i3djLeIN760+3X239rhmonoOyG
3ZdpNryAn2dnl4P6cCoP9/YIoPc+J5/vqw9WFsK9Z0vcPuk3rTtWmaiBoOkT
TH3dgxVIAziH9zxPq9vnFy0mDA8bMGFdRw4Dho0Y8GGzwQ/AqN9YoTe+p0Lv
mUcxvFoRQCywGq9JCe0qkUsl5phZEklFVE21avIPjZm8c43LPFZITQZoETTn
YaG3cHXbNH6iToiJkh6XqlRgYWZX7wRzy8M7T8jMqJ70t01OpIjSiUr9KRIL
vV5IeCyWmKgQxQtMyxrlV3GYpH5ElaKp8IKpoOFEjXocL5ZSktMuySmZeKav
kDGOSLbK42uMN76xJNnxevdXe7+N1XgtQ7mQZLSSQlX4c5/x9fWhnt21uTw8
6vVWMCuYB0TKiYWBGMwse8VdYk3hpVbB4Zz7Os3uStT2upxHQTZx7zTjgBPs
3mTfv8c8bTUEJkRdRkr8ROO0edRGGVDQUM0c6uo9l7yMsM8NSmldTfxdteLV
XCE7zrjL0KpBaiOPKJOKRm8KJJvWslkj5pIX8BiXiwnsdhlcqr+in/qiBL5g
bnLrNirnk3TMKekwTzG9pbRN+GsWqA4C8wj3TnLM+0CHFECky6AnO3ST1dFh
StGHMer3Rdq7hwSE4luQuUxfZipOqf7DpruegQ+D6dxQ+y0XjI6ZOyvpdd9t
+3bsNQkJQmsJW//UauWUUXp5afyKFfuXy//UVkqE0wZu3RudJ7H5Uz7y+fZ1
uVnuS85iM6roVrqcd/LxmqZtPZw1zWM+eCCgeDUUAZwcZcHlJryKptq5L/ME
W78uy0VxtLNTFZB2GsRGv6btUYNBxL3CNpFAil1Bhzcej0sZtGo8dQ1DM++y
QS1d2wMrQYrG6TZl4TLv+c4mDevvoTt5uAR77wcPFz4wKU+AhRT2yG81IoW8
YhbKP3o2Xh330qbIEljPNoK3vBG67t0Lb3wDtk94VQRkhsp4sXRgM5vLbjKB
SsPBeA9woGMBjq9O+tXwt+6gsBFQVztF/iaY7K/ImqIhzZyBfXkdzjvMrOC5
z0ZsjOf8UrFmFTEx6U58gyMtiCVpNQyqzmP8sNFqSffU7nuulviEyaA6UnUL
ninzZdyI8hVO58PQfT7+L4TwbXvkB6iPiB0wIH1f+7cqmw+13tTcP85OCvSF
a7PIsqeXkwattnASzzlLVGlSC7EhwlSSaGQbbI7YZq2i74h46bVpk/Cu4HVX
2kvZ/aDRQmvzOs2ToiCvxCAFmsjHYlykQpGmfJotyehrS00dQjEYh7JPYMAR
X7kicJZjI49nO2LnI551NdW/snZsD5h+2YRFlOSiP2FtrJREshF4T4L4O8Uy
Vl1top/0pArSk341YG/FC32ZrpR1DOZibcthWfGg6KepKZ5L+j+VzZMS9ciw
RiQtx1KxM8385HhUJc0lku5tWMFsO/Amb0pu+Qt5lDentXwfZ/Le3mDDgMEg
m+Wv4Ece5K5clbgyzFo5QAKGKlPxGje0Z7MYzl/RIvmfKoZzctg/mA4Ph+PR
/v443p9M90d7uwcH49Hh3n5/tBv9dtbJ8e5wNN6bRMMHe4Nh/2AY7U+iOI4P
46g3icf71djBJuukPdVXS/Tr5flNYjpNQ4SihKxP/NyrjLLmepvJYHiE/pMY
MN8z9nMzTNrIpNnMZzRr3Ky+zCnK43GxuHn3wVxIjV//uRxIc+LHVfwHe9za
IlvwyNoy0kFhbVtGpFqfVIW6aTjbz1/cDNfxAnA+WkvkUHc+s5ZMsp+o5nt7
u2xTQddB6GB/XQdqyzdU9rAZ327V2/41mSB2RVvLCh2zByTFlsVxaBRp6ylg
1Qog9L3CU2hvamu2I2k2QeG3KblMBa8rB0N2HFwLHNuF6cFZtdYwUx62u6p2
iTXKuRqcDcYyNG4pZ9zyjFqCdEm+TlNFHoNS8z0uuTCLbypTbCoDEQidLrf2
xKhu1NfjqIixiBTvGXbDw9igtljk8LIwrmkGyJ6wCzsOhLNDpGYRnvTb7zti
Vd/yxLii8DimvO/GBwDxS/oRKzZf6iMyP0SzABmZBaZ95kojPc9GWMKJSgQC
pZ5ld9ajja39AAb7IhmIk1RhA0F9Q+Obiz3SW/ZpBEsLL0m0DF5sOSgoDxNc
suicSjZrVyfb97/05EPjXEjegWuNOrQVfQAMeGS2LfJjseNU9RskUbgS0mFc
Z6h4+xnsuD3aftVIz8F+/58k0tNwNoFv1mDoeCq4sX8UEKxWwKQZvr6xoX7Q
jru+t7uyg6HtwA5/jZ5kjYaE76/SkvzwPiJHbziorucmMkf/F/CC7P+mXpDF
GtGjyjo1OkSORvuj0UE/jqbx4fTBaDIeTgeDvfFBPBmMeruH/X40eNAbx9NQ
9Pi1GP1wyKv9EwdDv+Oa66JGhh9JGrH8xPgjpfMFgyp2V1/qy0v9qvK6YXuF
Q6nujaN72q3JIf1/ZDlkLVJ9KFp5Ws/VPdcNXV5308H4cNw77D2Y9If93vhB
9GAvejDZ7UfTvb2DaPABHpyEMN7KrvHj3Nu1H4tfjWTsqPF4DdDL9N3/Lfru
N/c9eP++6+082RR6vbWtbAqH3l6lFV9y/SpFr6oxrDSGLpk634WXwVY4+Ggm
cQ0SzzPOl+MkmlVDDBTGC7A/CzG0GPglEQfAS+OLEjLKlTJmHMiwuL4r0OOg
2hmVzaXYMQzvyEbTZWFT8cpoaJ9TJvTZHScdYq81CqLEYpPAZN9EY+DpqMqk
KRhp72ZYKQM12UGV70rcRDgLk84tdkwiMtM2l9KzM06OYssTt44fPXqJtJaq
APtv94XXD97WwduK3u5LCt01ggDGd3JHuoxeVcsso7rbVuMq5pjhSUqbmlqi
Tuxb4/dU7UQFnWATPM5QaJMpEBuN7oDLUsq06yKZJyBS6duItALUnF1nLwiL
4z2Ka1wzDMe7rerWzUuSY4+C/FyMMPtzU46FAD87tsK8Sau/NHVVYTNkJndU
UijnmMRiOPD1OMOCcINKdXM41UU8XuYArXfvSMCZLnOJxYInMKRo02CVXn+/
qhT/nU9bwac9ONg73O9PR/FgCMfnaDqcRPHgcH/UG/THvck/L38mG21j1kx2
2S/JlYVN/idlyDbBn39ERozx4715iV+GE2PMeG8W5O/PilUU9+eeAy677Rae
jr4oYs/vv8YfiA29WI6KcZ6MXEHpuluvceZVG+d3WulLyook5/azsQ6p5gd0
375c4dtTP616fdm20WTisJQsHACc3nvQeE+bgqlaWnwCdejHZ/UVfGjqOnFc
PrJrHQwVMDG3tTI6h4cP9kyws8/jYS15RfHTYu4gX6QOOhaJ3p7TP11wHxdk
tEBQ6q2Li7PtenTudAkNVmNb60HgK9kBcT440q/ieIHhKjdxZbnqy6no1z0L
KVPjlcTUhbA4wXw3cTbjpoqdXn+AkTHSb51FqXEoA8uhbKq2tFgkg3XHz0Cu
VPmV5jMofHZjxoVek5c/rR3zSLzyu882G9rq83GjsQWnZDAs/5BYOaJOh7fM
NyZjkolHwvryKYbkN+0JvViOZknBWQ9k9V22iRSYJmWsH4ASuAeRUJQxFo+3
RdeM+8p+98DPkkRbUXZAA+bO4/yKuK3xNWOCtqjQXbHKBiBP8VVNr/Jga+vG
U/msccus63jVGq7qOVga02k17S9bvDB9CIUlFQXVpTFSeFhPHQfU8UboV/YN
1iXMHkwz/2Bjc+B3aY8o9V6G5qh4VVi7rjUwF0deboFkXQ1HKyCKzZByo9po
BS0xCfQCxcFRFpn1Bmr1vgZqfZ+BWr2fgVrfa6BW9xmo9a9roObcTMdcDgmk
beWC3OBdvPc1if8W9Zzlds2gvUVXro0k7M5ZxP1klYHGoQlblMUW7WFLQy/P
2Iq7umVBKcUoVTVXW0BEodFRMh4tCmPuNFxhkqsms/Zq8yA6Kv/DGwiHg3u9
99YbCGvZ8Yxw9wFpHNqNL3ohTWtDmYi1/OF3O+MvYWcc7O1+gP5q+Avor4b/
XPqrw2E0nD4Y9+CfwbA33X1wOIgHmP9kEA0OeuPDUPxduVl+xnb5mRvGx7tf
Tg3WpAfTg3t0YQ2aq7bu/3yF2Np2a1qx4X8CrdhmWPnztWJxb+8gmka7g94Q
mu4dHoz2d0ejw93ocH/UH/yuFfu7aMVAEJ0DhUhEqiB71PPSVvE4M+HbqCkL
Hn1H8kbD20/iKzTC0esnpDQrdliTUlTLXKzJfGBYunsqk7gXMNNFmoEcOn51
i8nzxsHIWM6i8c288bFSj7IDKRaE0eNw5rLLFRx2QvQ3jAzP42Vhcn6YfHm+
CorEF5SKK1nETdgNB4nVkhS3veCQSTIlU1Kp/C6mvp3L5mRclQKjMgHrOAwd
jZZe9gxRb06ymI2+Eq+HD8zbtcdIg5ZcpVkeVmQvbCXsJB0v8xyFNEx7CL+C
5YARAprOuywZE1b4rL1LGgD/ryMJ4kazQjUpVA0BZrFLgllfD0oBsg6GXIwE
ug8S+Hv0OMxSKYl+KQVhB4eAbE/HrFeLVq8+I7i4oqIJLJLStSAum2G/eVK0
YKn/Fql3eMGoObRvBxMy64Yyz3Jcrli4rgOW0YdTpZbISv4W1BXEtnQcwxot
7ilt4L3xtAKFlUVBSq/NwXLK6EIaaJOXAsNSNiq/Qwqaz8///PTsSHvReeh8
irthFHPCnyTVjitrs9oBiE4eR3BusxLmcqOkFyiDNiGoa125Rrw84119scRC
TCHdiyolkOIEKXhDZaM/bJJ9ALGxKTh20zhY1MgUwkuOWdVE0pUEK86XODka
IeW6nwIUY+oUIV3N69ocqYBteFlg1cpkHr7CjHpHxKO3ZVnDnPFqdTysDYWo
FyS2ZTFo1CaBpSmUQRTuuNDf/bD10ZSf3NZzdmUpBKXv0jJ6LWld5xHcGtNp
c3sdE5haARgzWNksbwKtTSLD8gADDBl948pTSfvrOTtgAjxMYl9xh7Fk0MM4
i6y1bpyS0IG9AQ8Qv+pwLgTQ7rSxSXGPv9XeYXNf402LaBrXy3SGpiKiUKH/
ErlwlEustCIwKZSvjB3FcCgnmCqH9jkt64nFSJ9oCLBhP8o4HOYCd5HeuQT6
2hu6unj8/Ksnp5QaeCQ5cDnH2Li5l1Qco3DVHd3A0kXe4R28YkkKrLZ4w6Az
VRvPwOapUD5iGZGfOmcdiGEFdOMDLTw+yCSx7nV0zZFoWbut/Zh4c8Q2ddDw
cp3Bqu0maKy6n7y1iCaUOrh50ZBBscsDDXmwW3sQ1U3RtWOIbZB+YQWpCwMT
e3r+9Iw1k3LmJIV36Kw4WxoM1dUzRqw0Vd5YqEFRqwRhfKpoBxWUBi71UqEX
eq/bJ6LQZA0ia4dgan1szOhG/gFgmVegqivgSlh8Es1i1DVVD+Ma9bv3OA6b
q0NrH09kwmjJB3jFBLu5ATcUyfmNN1kLbeqIRb4mPQp06Zyy3gaQeXAxEfEk
crzqwPWwbsZU6uaR2DFC1B2XNrUeYmxhg7fstsFmVJnMJUIeRknG7jzCACkX
gmPSv3Hj3nC7YnwkuDA4oLHOTZTfUQkiywy2ddy96rb1XCw2Top1AV1w6rpw
QSwiiHH0VzMOs6dCUMiIhTKTiZaC+bhrOAZlJoTCkxfMRWWaCuKuUpt4371q
+3ftAgBDEBWutNUI3Wlj8myM2H7imuIkBhxMRaBxgl5crUgAg3yc3cY3mKYb
xgfNB0VOmkdVmSePCg5RI7HSq66PrlCQfAkgleTpVd7L4X6ZuRwKnFiObco2
Zo8ItHfNmEY+9l1FySUUcxmgl+5tdNdtLrIEHMpYdo/xI/X3aXTnjD8N2fjl
HAbgjl2VRtugdxwypUDIxU7hAR2NiHm32xpD0UypU+wSgAYjJZOkbCdF5tGZ
7NhKBsSIAg0BIuuCXIFDsI2N8uwVyka5kbYQ13kRqYaYax4WBY4GzLppCgJI
H1LBVNgZwu5CX+JWfDjLxq86xlD60O01+7VzMUvQytv5Jkkn2S1bZfld+8gL
qi5b6q3Lhy+2OYHFmzcXZ88uzsQtdhKXUTIr0DT5kX4Up3EO0DpNivGyMHol
OC3wwjufqbI0EyaKaJMVpponzH+6nDGXGmBl88p4VLZYIX0b7cFKvQKwS5S3
A2mlckweZgLxB8DqFknXyLtO+IhRXDteSItVPxkATHa/M7MrTxDZ81mzLTPU
bTcTwgovJBbmS4eCX1CBbaCCF0UVj9G1gRRdYmIHHquMfVTr0lZp6hx3B4nx
/kJU6ACdNl39EKUw1EXIYvqonPhjInJvjipTIsIjI1KXOMcUtljrwh1grkCN
yeJ6Jq8HeVsw7+XUSBaN5YsIplJEmVEwrSBf2+KU2hynOKUNurNzVh6rQPOX
RwUoIMxSPAEAxuMICUG425GhST8updQT1b5gZmqipqSgwbhmhv46oNh9Ruci
rkAVMFSGgjQwY2AGsbwSawGjWUcORLeesvImzyu6a7hdYYaHUnWWUUUd2OoF
bZNMUuVoNkgVDahg/JlgGS8y680i9I4wyZGFSF8J9akfAAJ1PC1wOdQ8jkUL
9T7aR9QtECfCspvhucI6MYakeNKBkSb0JSZmIiJlCCW1f0nKW1Ml2kkfJF+y
j0NBwix2nGfomVGyOwxLrhMq9EZuMnS2w8oSQ6g4nwY9w08DIoEgiQelSL5c
XWSO1XCyWYwhJDhEKdhse4NTOpphXvw7qyaz+lSjvOsGpfxYUeLK59HIfKG/
qPpChVIbBY1XhTYaG+M9Zur3p8cTqxHXZU4MmehfLAEz6j5cPwRxARgTefqn
go9CUQ7GUZHMqOhVjqqFmnSIK/M6eJk53gqLpZyYv0pr2CX/5AXy76QcltgU
UtbCoIsFsAt6BhtiiTnIEY8E5TuLZU4luYJlxAmrkUncjYNcYoxYGb3i+qbo
eCWiUYpViCSpL4fhSG4DKb6QFOQ9E6pUsMgNY8UWHULL8hqEFZP4Co0NKZdq
en0NxAwD6OHwjHJCXzVBaX0OYLBaMK/TpZSr8fqiXAxwGyTQZcz8EAFHWHpl
wYI81IiegBWbIelnFT85lAlC8G4wrxR6lgBg//wlXlVv3vAXwFoAMDoXJX8B
XOYvpswosN5XucnChlwBB3oBfsMaMk0xVdsrNQ4BTQtNfJO3tnhWAqgXeChK
yfGpaQSIFRLBpJhTCbD4LjPeUH5Uk49DHzlGjBXiNmMNTYwoDX3DzlkRbJI8
N6ZRJ/eoJF1my2J2x/RI8E555LgLVBMwiCgK67CdIq+tr82+JOVsNJnQXjLN
kPlOliEW7mbMvnvi4oa/WYZYp+ZQvvrBWhu4UHcZzNY4E0roGkmbYuOQ4D6i
pWoK2yZhFR95VevsxqOoVDzZyW+efW1sn8MzVnkcRk03wa6hdmQO7JRbJI4n
Up/EjFO5GuMVxRDqZ4Rttan5Wc0U1d3VaYek40wqkrrQOhb+bzOr/VmDGkfQ
cpO5S8EgVli8WPMRJtd7iJXTxq+CFXJwwDVSdo14mG2r4jV8byIFCo0uC+kA
nV+cuUMvlgXyXWTsUM14jrpYPp0Itq6AGfAkaFnOsldca8DoQyhhujBBjsrg
rYuLM+02blQo/+DcVFPXRkKxXAClMUXeyFer7ycNRPf+UVLQ3z58EQpFDw78
8oSwUcf0FLbL8aNB+nqjc4dezBq8DsvrZHKMGwj70EU7oRLoNqMKgPTUlP92
vBortq04y4Q5oHj3xnGS5GmCNW3BMjmhSPrkME7ZLr5OMJDwpJMmu2TB622a
UtVOPM5nZSsURUI1zeFfKXUMswjUurIgpMoILTViaNLHk0nCQdLowMpTHoej
seYLIPSwzzhm+gSPeHQCfqM/WgC3Df29cwbNZk2QlSEjr9NxjoLjHcfpcJSA
AKUyjAnrABzWE0isXR5HPWUdVUR4h9ol5A995NmyVVP3alVTt9sgSpT8PjE2
RZITB3O1TCYRyhZIyBRyJfgQn6o1Sub30K/3QMTqJkpmsjuUjNLWdfDfrxaG
R50IBaOvmKo/kDYFjbPwg5QRK5hjkPQSbZqwOW9ZnIxKVYY0H8mcPV0k8jxP
ildHNeYj6O3WKG9VqNQusFli1cL8sNroliQFlYSDj7KyBGErHr/iCjZtheOZ
R69cbZeoLIG0F8RGY/2IMDq/ron0VwcaA6JyEyOhQBYJ2ebOFTLfMTNheep0
c5iIYDlGCx+dBA1Ih+upeDySCkCUpGIBDCfDlhEqax8hNoOQOsJwd2BdU1jI
TjbtWCw4Pc0utmWqMLCbbHZDhxmQuzmMkLOvkamP3C/oxE1SW8YHLl+hohAt
d4+SG/HtcOiNC4rgBt6eTiC7SipY1NVKXcwgDFAT+gObATdKPU2E6m0bda4P
TQREBR0mnAICDuCscDSABmrl4mCjCGnLjXRETFKUMxPqsC6YD0yhv+3MxWKz
Jq6Q9aUkarCdMCmuUX2DJ3zCgkyOnKZR1hbXyaLNkQ2Ce4q3maNPXAV1gmtG
4TM4HC4ETCOZRylwTUSaR8hUIf+K/FSKRyHuHYWeZzNmFOFcZB4CKSStHnto
4S62ivmgqjBSOMoI7FOQI70FK3L2GsMfFRLUWVagBTurODT5AP6Pf/9fBav5
8MCGTZ6yYJb81dA/Bt4f/v/erm25bSOJvuMrUHLVWqoitbrYjmM/yZbjKLYV
r+SVktraB1AEqbEAQgWQlhUrH5Dv2h/bPn0ZzIAgpexubV4iE8Bce/p6uifZ
pMU9fFijj7XJTd08pdt5dV0V1fQ2YtpBjpYp+nmz1TcaYmW1ZGDcvuRt3dzf
SmS2Vg8O9UMeNNnRLfuqslGldlnobMCtNXQY526qWVGN7EqzfK9qJwIKYZLL
jYFulkSb1RUXxNqkRARY1X0NB1dXBdIVjMpCq5LCNXUGCWyJCDShq2USxj/F
w/6+LTgUCERmscT8q3EAekm6RMnz/IdO85+8j4FMFYXW2GjVIkxk6QccHhal
B5BIcaCwJUUzvZw5mDISc5I6MkQhqPPi6DDF9CqGSaJ0EXONFfJDhE2Ts+0X
VsIJy9wE7ESKOc4jhiBsxPhAF0aoErpGulSSTem0i9uyvZY7QFXKbce8wWol
dBWDEfuqE5JwM/+OrhotUThLOwgdoR1NHlCycFCiKsjt1x1ehUN76KYOFsmJ
m17CjgO7Y0V58/Dkw1bSbte2IIhvXNOTaOoRJdVkki9XoNdxJ+tZvwWcbecD
VE8sFKVapmrW4DMcRkKpIT3s454Tst85ISFD8dCzVuPq3myWqIdpoSGrjYI6
LLP6Sm5UD7iQTMqqxbRVK2+NbtgZbU2xSsZ3mnEEHbm6F358SgWSyGRs+ODj
UYpJ4qbpQfr68NhtgZz/WtVmYBADI1paFFktKGkaXVY3rQ6lDfHbGhYPCuiT
tnRwCs2UOazcr5iyJ+L84Jh4T0AGqzjO+HaWlTQPuydHvAv59SWRFuw/q43E
/mp2TxYCILA6UhwxZz9LBGnyWDgJk0dvc9A4CYejAQmiEDedsTZnsfrlkbRL
p8F6GnlOi2YgxNZRMg+D/kaqkH5Q4Dg26p8afNaAFQkPW75BRDi8llxGySdP
ZcCthjrEaJ7nwaoJT6RNp3allC30DhVEA42PzC2C05XbMh4ihmu4RsSzvRDW
L5RB1kbNWHnXVCTWri9pK+V102JUjHz79urn48Nf2WjqsgRZ/fbmx1bKtZa+
ygA2YkJGwOeBtZM6rhqWIBoV87vOjendYfSc7ODzhDtn3GtYgApnnbRu9n60
rOfvgbn5NjI3D5bNzfCuPeZCa23O1vPU8bWHlidUztbK8CMPF6n1aCSrrCs9
FX5fVqxAsEWcNMwgCS3NJt4sOMNX2rWhzg0tTRySahklE5iFI3bsTZ2GU6Ax
4u+smJKiOL8s4WE5/vnsQFzy4eDMsmvg+X1zSm98+/bhzcnrg08/n0AjC8NB
TVxazBSfjCMExOOdeuQ0N93VFonBb2o1ObPfpT1rQ8UVn086Ia3jOwk9OvMl
GB9X0YuEl/i4l1gpicucX0zoJ7FXtVqaVG8WbqHGHPHEuWsmlivvjTMuXH3t
qYmnkNgURPUQTU1VjzJkHz1CvOloH0l7nWsAJxDxGzpR0o4TZUl6tH6Pi2o6
c79liIViwkw7Sb+JW7LaovWtWy+IBcaNBWNudqOolpVr9FschIXAvaoil9Od
ldViNvf4hrAsjZS/E2LiBCNqKpv6u0G5rjUxqasuI+q4QJZA2d3CiypCuSyi
ltxb8po0S0n7AkGM1RvMPfpINJkLxPjgCkW1EVExFNrT8XMk5svRIj3dTV1y
WcZWFyBotCf9NRmNCQl7qIhMS9p4NYXE90SHKQ8WfUiLjuycz8uyJGQCgWBh
OAb1CKAtY2e0shDXz8DasfsZGWKQHz2j5Oi/nQg3b/JiImyfWJm7cNWi8XoA
nfeymjngblSRN4A5E1OEviVxfC26cP2FixToQzlei+Za225bUL2tya1Mh1z6
lGbwVV0SNRvdX9xa0Yhedbfp1Xc9sfTBdqsJo1bWlK/UyAujMkJ5Q1oxfPkC
tZOzVvv2PH4k9g8qAMTOn6BpxZAZi/2JIDPcM1Vt91wr1QBIOQLotszG/Io0
Ne46A1aQJQu6EZdlQc82fdWvGTWequI1zovMjDcrsmO7rt9xkOLo4PigG6B4
lH57hN8l31KyKjmOxqCY9ITEYjPXoG0cv6j5EZZQ+J0cXxVFKxuCz5VUWVH0
RC55deRJj0/jE++Ntp4sFe+UFJn5qBgGueWcF3OXHnkEakr/mGme3anPgLlb
GbW5S+6GwX/RP+75FQ+ob8uMT1PuBqhFGZteMux/Dap83vHl8p252HXyKxd0
Y2nnEFL9H+xb2MyaXXsiW4Y43+hm6NO9uADAf7CB8tWDtu9Bm4S9YEy73wbq
wW9CZ8U5GL203uFChKutdXwO2TfDKKr/btm1IW02am/dqdmzU3PvRW5/YjM0
ZVz8TrwhS1ui4wx+e4NwPhjPXfoj/RtQm9v0L7R3xHHdnI2UOyJfpBJ+0lRC
H5JljMhFLa+IsY7F4YU5ULgGf/Sgbb/34drPHvSKnnIrQ2DkpQunjmeiMXl4
XLWvhv/dra/VQM85f7HvU/7cE3C0YRERryFTUHO7fy+SFzoJaYWTnnjvV291
+0134gDDGRHgLawA8GWeFtof15FELS9G4xrrG9zJOmLBl4JRkQkI+s0wMiUq
LOlXhgjiJLokWSEY0N7RTEBpCwax+ADWgJ0iPt7AsSUNsXAHHy0Mr/AXVn6T
NNXw4rKe0ikMCpm/wme4Tc0ctFSk8bJ+dUvhOH6YllPBYNtRzroKNSfaGD0k
3pBuwm6fSCBMv2Rt8QKuK4W0KBTWfenAuTWbzmcD1dVXUqzhIqOFsZLWbu4l
bz+cLKRjj9zpYbg3FTXr2EWS6+2Ya/REBnn2FycXxLcwbAVqdrg06mhs+AzC
+we4MQAIeSUL3/9TLByZQcbGnV0y1cfG8aVkGdNsFJojvgXNm9Drj5IJ6gjI
d2U9GrpslrX5xrnTH7pyucPKeoR08PSeU95l7H+CF9/PzMGsVxFCqxlkX+n5
6EaZ9kM5NDXdR0SRVOh7gZXA+9o29h5tpLH3I6X1N0oGjNIjOaMkGsKk+2iz
6Wg1j9JjvTYgeu3F+uv4vj3yBNMVJqvPHgRBl1ZaNt9uxPaDhMM95Y7WMHMW
Dj7JDYKiadTHyosZclVDoPC9bUNgtgX6joIXZIg1nAYJ/yAZb7DHWm9UfAUw
AG4AqAiKHLdBgEWTGZoGV8wFliRD6+VuABYVAiuxF0UMqXnaBjACnssBRjhN
zX0sCPQCjklGFMQOCoaJSxayVuqgtpYhJ+qKCaJKPV7DZY87tRX4SSQayA6X
NrHHLNdOPC6I26t/YqDCJYb7mS+ai14G/tYsyrNhTtfaXttr6X+5dufRIdG9
54tLdN9f924Fza9lEf/3A6AZUz4iF9bwzSxvIi/sQjoJkEBl8De/mM4hocIb
rgUj0ia+glEv3jMlQKCekItJVDVS64nmtvBN7K/rj9+KCjXnCjBBVE+PhOLq
ep2+Yfa5IQvTLsQxhCjsPlRyo7DgkAtIwRdzcHE1q25oSaYSHNfsG0tiuOHB
MCCdlY9sdmWIRh6B4P1nY5SGSc+qvChK0qnekKU7S9+7QfJj5kYYZYVMC/rH
bzS79HAxSH9y2e2CXvqR/v6by6r0FyJheucT/Y8fvHf05Bc8Ob10+GuWnGeW
r/ErXlhUsiU2VhndWwimV8B4znNAFQ4zUkdeExkN0nOi+tv0pCK1Wc7sB0cs
IC/SU/pfPbFYqqsFEACYG08SCPGsLqBpjOtsMrdb4uNFYqdovFKfXEldkz40
oNESUaM6Xk27RyzjhGTjjAY3uy3czSB5lc8+ZyWt1LtsvLjCCrqr9B0AN4P0
FOCzy/Rd7ZrLWUZtfViwJ+EdCQJq7IYW/DxDQgf9UpIRMEio2dlt+j4jnk5d
/VDDzCH+k37MCk72pfX81x9w3pzdzi6u0EVWLmgdznM6HLUscbspiZydSZ6P
QTXiq11MFamnYK4ZXJICOKsQsyMWKnzcgkfqHueEomp24ejAwNDpKtrS+Yfq
MivpEL4iWzwbZ47G9CGj40ortsB4z9xnWoC3i5oEEM33pwwHIR9X9cQGP0vP
Fzj03gM7RZq6L8SAlwwgyz7Jk/yL4/jJ+2rapJufKrmMs6xwFWfo0hRusCU5
bZr1KdfdD/d2kuQkd9rQcG8XBUcsM5Sdu8IYvsT5ezEepgck+/GsI13EIV5N
ILcte6dvQLvfY0B+PDvd8bAjtjbTJYwCD8nCqq41OfCiKkuPPEqP3py+hQ7g
8pumt9PnYacYAhobNy3z9TW6ceAs/7LB2ADQQFQvr0vlLRnR6xQpNySvMwic
/j6/i/p83p1oVMCDu9VK8VCQBY9q92ix13dv//l3Yfre0/29vd9/t4lw/Wqb
RNI7nmfReL7za0AmZinzjktZmSshTvfg/Yl5fm9vT6PenqE3tFN8yf0GdiuI
4OegTFgbP9yk6aZIV9yyMYdV+fqHivlE1cYVoIffMQf2L0wVTrri8Ow+iSbx
FJOYuK9GqYfHuODsJquZBgb+4bTOypLz55E6NZAxq1Mhol2zQg6Vdrf7N24/
GsWT5N4GicxcrW22wyorTlnldK46c40Y2jKL7d6O96KO97sU7Aua+BsIfOfN
Y38chz4lD1YVpFs9ftwoVkcC9Odv379ee3x3o4HsJf5cWiBdCMCQFey2Wb75
rGGXTSf9GveVsRYfX2Cyt7f7jE8Xgx8Nbd2wYVBwTSPG2mhik6ETLwoSygwi
SfcHUVx+tCiKnCQJHj3Z3pM/nm7vbu/Ln8+297af2J/+he+390HyfHn8/R7L
3qXbiZZuV87hdZHhjGwA37uRyunb4JKJs5zzeZWQbIdfYhdNj4+STsIiF+nm
wcmWFsMI7oqecGIS6QXjRSEmU3DDz7i1PGR7GN3lT35M522/fHqD8hrhuUTh
xJkZJQvJot/gZIGNoCii1RPUMvwKHMNEDW7bcJaqu3C4QJGHVvE140XeU/zs
pW0TRsBev3kkyjqAnbBaafoQFfkl75sAy5ZsKK7NRaPrN67wacl3FW6sNYY2
LOXjPjGAeo++3B1cfeJ75iXQUKzsokijl8a0+aB6RR38ooX4gRI6YM5+brgT
6Q+7O0LQ9G+/+0JObcENGu5QUwCbIFethRx/PAsoTk0vqwEXJPVucA0SuK6C
SjMbHRVlVDOUkpVS5oZ2LbyCqHxpB58rn7qiWASXgmiB1s604DkBf7TkaZx+
KWIzsduUOFX8WoELY6JhmQ/7UNoTEp0OVmoG2Oqql/HuPLf6RLrirQTMSPm+
wVkpOK+Yry5AL3l5fZk17rfcWGO36lVbP0JW2pCTLEDGsP6ZC6O8EauYwXYy
eriaw5OOPls1LRy61Is5Ay2BQnaewX4ckh3RDk0IpYTWzZG3oEJK2q3XZ3Wd
Mr5pvnmR0KB22e9E25AZSemm0XpkFwrV0OmxysOSFvx7IGzxur2pUspIB/U1
tCpYFVJZs/QCAht7PAzkD8maSDdwfncCMNIpF4wKOMDjRp1EqXeI0U84hNfi
wsAJHJLdU+ftUqtlJeUIOVJhTNkiAVXtpm7GtT6WSB/ugoyvrOENAVKDk8dC
852aEdyd1QgQ+c7wYFne5e1imeJlBlHJZxQ1QNLDorZv7UQAv+l9a8G5YZSU
EmvgIlRyHQSlIDfhbUQxGIx1uPN0C1k3N1ykKijrq/EEePV6riMbpj+4ryau
uhnHdqua1JHpli9C/jJp1GL3DzyPY+kj7j9YEAinAEsVVM5Ww4LOmE8ibiEw
Q9UjOIsrlPCREr0ppdN6BNCWkCxngRWFjEdJRiuuBgWCMPLt5N+DQ75lFtEB
AA==
</rfc> </rfc>
 End of changes. 420 change blocks. 
2478 lines changed or deleted 1298 lines changed or added

This html diff was produced by rfcdiff 1.48.