<?xml version='1.0' encoding='utf-8'?> 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 [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>

<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.5.6 -->
<?rfc strict="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc editing="no"?>
<?rfc toc="yes"?>
<?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" number="9275" submissionType="IETF" category="exp" consensus="true" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="3" sortRefs="true" symRefs="true" version="3">

  <!-- xml2rfc v2v3 conversion 3.12.0 -->
  <front>
    <title abbrev="ALTO-PV">An ALTO Extension: Path Vector</title> Extension for Application-Layer Traffic Optimization (ALTO): Path&nbsp;Vector</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-alto-path-vector-25"/> name="RFC" value="9275"/>
    <author initials="K." surname="Gao" fullname="Kai Gao">
      <organization>Sichuan University</organization>
      <address>
        <postal>
          <street>No.24 South Section 1, Yihuan Road</street>
          <city>Chengdu</city>
          <code>610000</code>
          <country>China</country>
        </postal>
        <email>kaigao@scu.edu.cn</email>
      </address>
    </author>
    <author initials="Y." surname="Lee" fullname="Young Lee">
      <organization>Samsung</organization>
      <address>
        <postal>
          <country>South
          <country>Republic of Korea</country>
        </postal>
        <email>younglee.tx@gmail.com</email>
      </address>
    </author>
    <author initials="S." surname="Randriamasy" fullname="Sabine Randriamasy">
      <organization>Nokia Bell Labs</organization>
      <address>
        <postal>
          <street>Route de Villejust</street>
          <city>Nozay</city>
          <code>91460</code>
          <country>France</country>
        </postal>
        <email>sabine.randriamasy@nokia-bell-labs.com</email>
      </address>
    </author>
    <author initials="Y.R." initials="Y." surname="Yang" fullname="Yang Richard Yang">
      <organization>Yale University</organization>
      <address>
        <postal>
          <street>51 Prospect Street</street>
          <city>New Haven</city>
          <code>CT</code>
          <country>USA</country>
	  <code>06511</code>
          <region>CT</region>
          <country>United States of America</country>
        </postal>
        <email>yry@cs.yale.edu</email>
      </address>
    </author>
    <author initials="J." surname="Zhang" fullname="Jingxuan Jensen Zhang">
      <organization>Tongji University</organization>
      <address>
        <postal>
          <street>4800 Caoan Road</street>
          <city>Shanghai</city>
          <code>201804</code>
          <country>China</country>
        </postal>
        <email>jingxuan.n.zhang@gmail.com</email>
      </address>
    </author>
    <date/>
    <area>Application</area>
    <workgroup>ALTO</workgroup>

    <date year="2022" month="August" />

    <area>tsv</area>
    <workgroup>alto</workgroup>

<keyword>network visibility</keyword>
<keyword>abstract network element</keyword>
<keyword>shared bottleneck</keyword>

    <abstract>
      <t>This document is an extension to the base Application-Layer Traffic Optimization
(ALTO) protocol. It extends the ALTO Cost Map cost map and ALTO Property Map property map services so
that an application can decide to which endpoint(s) to connect based on not only on
numerical/ordinal cost values but also on fine-grained abstract information of regarding the
paths. This is useful for applications whose performance is impacted by
specified
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
avoiding such paths. This extension introduces a new abstraction called Abstract the "Abstract
Network Element 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
representation of the underlying network(s) for informed traffic optimization
among endpoints.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="default">
      <name>Introduction</name>
      <!-- ALTO can improve QoE of overlay applications. -->
<t>Network performance metrics are crucial to assess for assessing the Quality of Experience
(QoE) of applications. The ALTO Application-Layer Traffic Optimization (ALTO) protocol allows Internet Service Providers
(ISPs) to provide guidance, such as topological distance distances between different end
hosts, to overlay applications. Thus, the overlay applications can potentially
improve the perceived QoE by better orchestrating their traffic to utilize the
resources in the underlying network infrastructure.</t>
      <!--
<t>The existing ALTO supports only
cost information of end-to-end paths. -->
<t>Existing ALTO
Cost Map (Section 11.2.3 of <xref map (<xref target="RFC7285" format="default"/>) sectionFormat="of" section=
"11.2.3"/>) and Endpoint Cost Service (Section 11.5
of <xref (<xref target="RFC7285" format="default"/>) sectionFormat="of" section="11.5"/>) provide only cost information on for an end-to-end path defined by
its &lt;source, destination&gt; endpoints: The the base protocol <xref target="RFC7285" format="default"/> allows the
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.,
to express other performance metrics <xref target="I-D.ietf-alto-performance-metrics" target="ALTO-PERF-METRICS" format="default"/>, to
query multiple costs simultaneously <xref target="RFC8189" format="default"/>, and to obtain the time-varying
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
the existing extensions are sufficient for to optimize the QoE of many
overlay applications, the QoE of some overlay applications also
depends not only on the cost
information properties of end-to-end paths, but also on particular components of a network on the paths and their properties. paths. For example, job completion time, which is an
important QoE metric for a large-scale data analytics application, is impacted
by shared bottleneck links inside the carrier network network, as link capacity may
impact the rate of data input/output to the job. We refer to such components of
a network as Abstract Network Elements (ANE).</t> (ANEs).</t>
      <t>Predicting such information can be very complex without the help of ISPs, ISPs; for
example, <xref target="BOXOPT" format="default"/> has shown that finding the optimal bandwidth reservation for
multiple flows can be NP-hard without further information than whether a
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
helpful as well for ISPs if applications could avoid using bottlenecks or
challenging the network with poorly scheduled traffic.</t>
      <t>Despite the claimed benefits, ISPs are not likely to expose raw details on their network paths: first for the sake of topology hiding requirement, because ISPs have requirements
to hide their network topologies, second because
it these details may
increase volume and computation overhead, and last because applications
do not necessarily need all the network path details and are likely not
able to understand them.</t>
      <t>Therefore, it is beneficial for both ISPs and applications if an ALTO server
provides ALTO clients with an "abstract network state" that provides the
necessary information to applications, while hiding the network complexity and
confidential information. An "abstract network state" is a selected set of
abstract representations of Abstract Network Elements ANEs traversed by the paths
between &lt;source, destination&gt; pairs combined with properties of these Abstract
Network Elements ANEs that are relevant to the overlay applications' QoE. Both an
application via its ALTO client and the ISP via the ALTO server can achieve
better confidentiality and resource utilization by appropriately abstracting
relevant Abstract Network Elements. ANEs. Server scalability can also be improved by
combining Abstract Network Elements ANEs and their properties in a single response.</t>
      <t>This document extends the ALTO base protocol <xref target="RFC7285" format="default"/> to allow an ALTO server to convey "abstract
network state", state" for paths defined by their &lt;source, destination&gt; pairs. To this
end, it introduces a new cost type called a "Path Vector" Vector", following the cost
metric registration specified in <xref target="RFC7285" format="default"/> and the updated cost mode
registration specified in <xref target="I-D.bw-alto-cost-mode" target="RFC9274" format="default"/>. A Path Vector is an array
of identifiers that identifies an Abstract Network Element, ANE, which can be
associated with various properties. The associations between ANEs and their
properties are encoded in an ALTO information resource called Unified Property
Map, the "entity property
map", which is specified in <xref target="I-D.ietf-alto-unified-props-new" target="RFC9240" format="default"/>.</t>
      <t>For better confidentiality, this document aims to minimize information exposure
of an ALTO server when providing Path Vector service. services. In particular, this
document enables the capability, and also recommends that first 1) ANEs are be constructed on demand, demand and
second
2) an ANE is only be associated with properties that are requested by an ALTO
client. A Path Vector response involves two ALTO Maps: maps: the Cost Map that cost map, which
contains the Path Vector results results; and the up-to-date Unified Property Map that entity property map, which
contains the properties requested for these ANEs. To enforce consistency and
improve server scalability, this document uses the "multipart/related" content
type as defined in <xref target="RFC2387" format="default"/> to return the two maps in a single response.</t>
      <t>As a single ISP may not have the knowledge of the full Internet paths between
arbitrary endpoints, this document is mainly applicable 1) when there when</t>
  <ul spacing="normal">
  <li>there is a
single ISP between the requested source and destination PIDs Provider-defined Identifiers (PIDs) or endpoints, endpoints -- for
example, ISP-hosted CDN/edge, Content Delivery Network (CDN) / edge, tenant interconnection in a single public cloud
platform, etc.; or 2) when the etc., or</li>
  <li>the Path Vectors are generated from end-to-end
measurement data.</t> data.</li>
  </ul>
    </section>
    <section anchor="requirements-languages" numbered="true" toc="default">
      <name>Requirements Languages</name> Language</name>
       <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
       "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
       "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
       "<bcp14>SHOULD NOT</bcp14>",
       "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
       "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document
       are to be interpreted as described in BCP 14 BCP&nbsp;14
       <xref target="RFC2119" format="default"/> target="RFC2119"/> <xref target="RFC8174" format="default"/> target="RFC8174"/> when, and only
       when, they appear in all capitals, as shown here.</t>
      <t>When the words appear in lower case, they are to be interpreted with their
natural language meanings.</t>
    </section>
    <section anchor="term" numbered="true" toc="default">
      <name>Terminology</name>
      <t>This document extends the ALTO base protocol <xref target="RFC7285" format="default"/> and the Unified
Property Map entity
property map extension <xref target="I-D.ietf-alto-unified-props-new" target="RFC9240" format="default"/>. In addition to
the terms defined in these those documents, this document also uses the following
additional
terms:</t>
      <dl>
        <dt>
Abstract Network Element (ANE):  </dt>
        <dd>
          <t>An abstract representation for a component in a network that handles data
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
link
link, or an interface, interface; or an aggregation of devices such as a subnetwork or a
data center.
</t>
          <t>The definition of Abstract Network Element an ANE is similar to Network Element that for a network element
as defined in <xref target="RFC2216" format="default"/> in the sense that they both provide an abstract
representation of specific components of a network. However, they have
different criteria on how these particular components are selected.
Specifically, a Network Element network element requires the components to be capable of
exercising QoS control, while Abstract Network Element an ANE only requires the
components to have an impact on the end-to-end performance.</t>
        </dd>
        <dt>
ANE Name: name:  </dt>
        <dd>
          <t>A string that uniquely identifies an ANE in a specific scope. An ANE
can be constructed either statically in advance or on demand based on the
requested information. Thus, different ANEs may only be valid within a
particular scope, either ephemeral or persistent. Within each scope, an ANE is
uniquely identified by an ANE Name, name, as defined in <xref target="ane-name-spec" format="default"/>. Note that
an ALTO client must not assume ANEs in different scopes but with the same ANE
Name
name refer to the same component(s) of the network.</t>
        </dd>
        <dt>
Path Vector:  </dt>
        <dd>
          <t>Path Vector, or Vector (or ANE Path Vector, refers Vector):  </dt>
        <dd>
          <t>Refers to a JSON array of ANE Names. names. It is a
generalization of a BGP path vector. While a standard BGP path vector (Section
5.1.2 of <xref (<xref target="RFC4271" format="default"/>) sectionFormat="of" section="5.1.2"/>) specifies a sequence of autonomous systems Autonomous Systems (ASes) for a
destination IP prefix, the Path Vector defined in this extension specifies a
sequence of ANEs either for either 1) a source Provider-Defined Identifier (PID) PID and a
destination PID PID, as in the CostMapData (11.2.3.6 in <xref object (<xref target="RFC7285" format="default"/>), sectionFormat="of" section="11.2.3.6"/>) or for 2) a
source endpoint and a destination endpoint endpoint, as in the EndpointCostMapData
object (Section 11.5.1.6 of <xref (<xref target="RFC7285" format="default"/>).</t> sectionFormat="of" section="11.5.1.6"/>).</t>
        </dd>
        <dt>
Path Vector resource:  </dt>
        <dd>
          <t>An ALTO information resource (Section 8.1 of <xref (<xref target="RFC7285" format="default"/>) which sectionFormat="of" section="8.1"/>) that supports the
extension defined in this document.</t>
        </dd>
        <dt>
Path Vector cost type:  </dt>
        <dd>
          <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 Information Resource Directory (IRD) entry, it indicates that the information resource is
a Path Vector resource. When this cost type is present in a Filtered Cost Map filtered cost map
request or an Endpoint Cost Service request, it indicates that each cost value must
be interpreted as a Path Vector.</t>
        </dd>
        <dt>
Path Vector request:  </dt>
        <dd>
          <t>The POST message sent to an ALTO Path Vector resource.</t>
        </dd>
        <dt>
Path Vector response:  </dt>
        <dd>
          <t>A Path Vector response refers
          <t>Refers to the multipart/related message returned by a
Path Vector resource.</t>
        </dd>
      </dl>
    </section>
    <section anchor="probstat" numbered="true" toc="default">
      <name>Requirements and Use Cases</name>
      <section anchor="design-requirements" numbered="true" toc="default">
        <name>Design Requirements</name>
        <t>This section gives an illustrative example of how an overlay application can
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
shared links/nodes and share bottlenecks. The application seeks to schedule the
traffic among multiple flows to get better performance. The constraints of
feasible rate allocations of those flows will benefit the scheduling. However,
Cost Maps
cost maps as defined in <xref target="RFC7285" format="default"/> can not cannot reveal such information.</t>
        <t>Specifically, consider a the example network as shown in <xref target="fig-dumbbell" format="default"/>. The network has 7 seven
switches (sw1 ("sw1" to sw7) "sw7") forming a dumb-bell dumbbell topology. Switches "sw1", "sw2", "sw3" "sw3",
and "sw4" are access switches, and sw5-sw7 "sw5-sw7" form the backbone. End hosts eh1 "eh1" to
eh4
"eh4" are connected to access switches sw1 "sw1" to sw4 "sw4", respectively. Assume that the
bandwidth of link eh1 "eh1 -&gt; sw1 sw1" and link sw1 "sw1 -&gt; sw5 sw5" is 150 Mbps, Mbps and the bandwidth
of the other links is 100 Mbps.</t>
        <figure anchor="fig-dumbbell">
          <name>Raw Network Topology</name>
          <sourcecode type="drawing"><![CDATA[
<artwork name="" type="" align="left" alt=""><![CDATA[
                              +-----+
                              |     |
                            --+ sw6 +--
                           /  |     |  \
     PID1 +-----+         /   +-----+   \          +-----+  PID2
     eh1__|     |_       /               \     ____|     |__eh2
192.0.2.2 | sw1 | \   +--|--+         +--|--+ /    | sw2 | 192.0.2.3
          +-----+  \  |     |         |     |/     +-----+
                    \_| sw5 +---------+ sw7 |
     PID3 +-----+   / |     |         |     |\     +-----+  PID4
     eh3__|     |__/  +-----+         +-----+ \____|     |__eh4
192.0.2.4 | sw3 |                                  | sw4 | 192.0.2.5
          +-----+                                  +-----+

bw(eh1--sw1) = bw(sw1--sw5) = 150 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(sw5--sw6) = bw(sw5--sw7) = bw(sw6--sw7) = 100 Mbps
]]></sourcecode>
]]></artwork>
        </figure>
        <t>The base ALTO topology abstraction of the network is shown in <xref target="fig-base" format="default"/>.
Assume that the cost map returns an a hypothetical cost type representing the available
	bandwidth between a source and a destination.</t>

        <figure anchor="fig-base">
          <name>Base Topology Abstraction</name>
          <sourcecode type="drawing"><![CDATA[
	  <artwork name="" type="" align="left" alt=""><![CDATA[
                          +----------------------+
                 {eh1}    |                      |     {eh2}
                 PID1     |                      |     PID2
                   +------+                      +------+
                          |                      |
                          |                      |
                 {eh3}    |                      |     {eh4}
                 PID3     |                      |     PID4
                   +------+                      +------+
                          |                      |
                          +----------------------+
]]></sourcecode>
]]></artwork>
        </figure>
        <t>Now
        <t>Now, assume that the application wants to maximize the total rate of the traffic among
a set of &lt;source, destination&gt; pairs, say pairs -- say, "eh1 -&gt; eh2" and "eh1 -&gt; eh4". Let "x"
denote the transmission rate of "eh1 -&gt; eh2" and "y" denote the rate of "eh1 -&gt;
eh4". The objective function is</t>

        <artwork name="" type="" align="left" alt=""><![CDATA[
    max(x + y).
]]></artwork>
        <t>With the ALTO Cost Map, the cost map, the costs between PID1 and PID2 and between PID1 and PID4 will
both be 100 Mbps. The client can get a capacity region of</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
    x <= 100 Mbps, Mbps
    y <= 100 Mbps.
]]></artwork>
        <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
potential cases:</t>
        <ul
        <dl spacing="normal">
          <li>
            <t>Case 1: "eh1
          <dt>Case 1:</dt><dd><t>"eh1 -&gt; eh2" and "eh1 -&gt; eh4" take different path segments from "sw5" to "sw7". For
example, if "eh1 -&gt; eh2" uses path "eh1 -&gt; sw1 -&gt; sw5 -&gt; sw6 -&gt; sw7 -&gt; sw2 -&gt; eh2"
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 capacity
region is:  </t>
            <artwork name="" type="" align="left" alt=""><![CDATA[
    x     <= 100 Mbps
    y     <= 100 Mbps
    x + y <= 150 Mbps
]]></artwork>
            <t>
and the real optimal total rate is 150 Mbps.</t>
          </li>
          <li>
            <t>Case 2: "eh1
          </dd>
            <dt>Case 2:</dt><dd><t>"eh1 -&gt; eh2" and "eh1 -&gt; eh4" take the same path segment from "sw5" to "sw7".
For example, if "eh1 -&gt; eh2" uses path "eh1 -&gt; sw1 -&gt; sw5 -&gt; sw7 -&gt; sw2 -&gt; eh2"
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>
            <artwork name="" type="" align="left" alt=""><![CDATA[
    x     <= 100 Mbps
    y     <= 100 Mbps
    x + y <= 100 Mbps
]]></artwork>
            <t>
and the real optimal total rate is 100 Mbps.</t>
          </li>
        </ul>
         </dd>
	</dl>
        <t>Clearly, with more accurate and fine-grained information, the application can
gain a
better prediction of predict its traffic and may orchestrate its resources
accordingly. However, to provide such information, the network needs to expose
abstract information beyond the simple cost map abstraction. In particular:</t>
        <ul spacing="normal">
          <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
numerical value, which allows the overlay application to distinguish between
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 ANE shared by
"eh1 -&gt; eh2" and "eh1 -&gt; eh4", e.g., "eh1 - sw1" "eh1&nbhy;&nbhy;sw1" and "sw1 - sw5" "sw1&nbhy;&nbhy;sw5" in Case 1.</li>
          <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 can
either expose the available bandwidth between "eh1 - sw1", "sw1 - sw5", "sw5 -
sw7", "sw5 - sw6", "sw6 - sw7", "sw7 - sw2", "sw7 - sw4", "sw2 - eh2", "sw4 -
eh4" "eh1&nbhy;&nbhy;sw1", "sw1&nbhy;&nbhy;sw5", "sw5&nbhy;&nbhy;sw7", "sw5&nbhy;&nbhy;sw6", "sw6&nbhy;&nbhy;sw7", "sw7&nbhy;&nbhy;sw2", "sw7&nbhy;&nbhy;sw4", "sw2&nbhy;&nbhy;eh2", "sw4&nbhy;&nbhy;eh4" in Case 1, 1 or expose 3 three abstract elements "A", "B" "B", and "C", which
represent the linear constraints that define the same capacity region in Case
1.</li>
        </ul>
        <t>In general, we can conclude that to support the use case for multiple flow scheduling
use case, scheduling, the ALTO framework must be extended to satisfy the following
additional requirements:</t> requirements (ARs):</t>
        <dl>
          <dt>
AR1:  </dt>
          <dd>
            <t>An ALTO server must provide the ANEs that are important to assess for assessing the QoE of
the overlay application on the path of a &lt;source, destination&gt; pair.</t>
          </dd>
          <dt>
AR2:  </dt>
          <dd>
            <t>An ALTO server must provide information to identify how ANEs are shared on the
paths of different &lt;source, destination&gt; pairs.</t>
          </dd>
          <dt>
AR3:  </dt>
          <dd>
            <t>An ALTO server must provide information on the properties that are important
to assess
for assessing the QoE of the application for ANEs.</t>
          </dd>
        </dl>
        <t>The extension defined in this document specifies a solution to expose such
abstract information.</t>
      </section>
      <section anchor="sample-use-cases" numbered="true" toc="default">
        <name>Sample Use Cases</name>
        <t>While the problem related to multiple flow scheduling problem is used to help identify the
additional requirements, the extension defined in this document can be applied
to a wide range of applications. This section highlights some of the reported use cases that are
reported.</t> cases.</t>
        <section anchor="exposing-network-bottlenecks" numbered="true" toc="default">
          <name>Exposing Network Bottlenecks</name>
          <t>An
          <t>One important use case of for the Path Vector extension is to expose network
bottlenecks. Applications which that need to perform large scale large-scale data transfers can
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
Computing Grid (WLCG), (WLCG) (where "LHC" means "Large Hadron Collider"), which is the largest example of a distributed computation
collaboration in the research and education world.</t>
          <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.
In particular, we assume that the objective of the job optimizer is to minimize the
job completion time.</t>
          <t>In such a setting, the network-aware job optimizer (e.g., <xref target="CLARINET" format="default"/>) takes a
query and generates multiple query execution plans (QEP). (QEPs). It can encode the QEPs
as Path Vector requests that are send sent to an ALTO server. The ALTO server obtains
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
of
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
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
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,
certain network managers may offer ways to enforce resource guarantees, such as
on-demand tunnels (e.g., <xref target="SWAN" format="default"/>), demand vector vectors (e.g., <xref target="HUG" format="default"/>, <xref target="UNICORN" format="default"/>),
etc. The traffic control interfaces and mechanisms are out of the scope of for this
document.</t>
          <figure anchor="fig-da">
            <name>Example Use Case for Data Analytics</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
                                     Data schema      Queries
                                          |             |
                                          \             /
       +-------------+                   +-----------------+
       | ALTO Client | <===============> |  Job Optimizer  |
       +-------------+                   +-----------------+
PV          |   ^ PV                                    |
Request     |   | Response                              |
            |   |                  On-demand resource   |
(Data
(Potential  |   | (Network         allocation, demand   |
Transfer
Data        |   | Resource         vector,         vectors, etc.        |
Intents)
Transfers)  |   | Constraints)     (Non-ALTO interfaces)|
            v   |                                       v
       +-------------+                   +-----------------+
       | ALTO Server | <===============> | Network Manager |
       +-------------+                   +-----------------+
                                           /      |      \
                                           |      |      |
                                          WAN    DC1    DC2
]]></artwork>
          </figure>
          <t>Another example is as illustrated in <xref target="fig-dts" format="default"/>. Consider a network consisting
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 a bottleneck of for
the data transfers.</t>
          <figure anchor="fig-dts">
            <name>Example Use Case for Cross-site Cross-Site Bottleneck Discovery</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
               On-going
               Ongoing transfers    New transfer requests
                             \----\        |
                                  |        |
                                  v        v
   +-------------+               +---------------+
   | ALTO Client | <===========> | Data Transfer |
   +-------------+               |   Scheduler   |
     ^ |      ^ | PV request Request     +---------------+
     | |      | \--------------\
     | |      \--------------\ |
     | v       PV response Response   | v
   +-------------+          +-------------+
   | ALTO Server |          | ALTO Server |
   +-------------+          +-------------+
         ||                       ||
     +---------+              +---------+
     | Network |              | Network |
     | Manager |              | Manager |
     +---------+              +---------+
      .                           .
     .             _~_  __         . . .
    .             (   )(  )             .___
  ~v~v~       /--(         )------------(   )
 (     )-----/    (       )            (     )
  ~w~w~            ~^~^~^~              ~v~v~
 Site 1        Non-blocking Core        Site 2
]]></artwork>
          </figure>
          <figure anchor="fig-sbot">
            <name>Example: Three Flows in Two Sites</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
Site 1:

[c]
 .
 ........................................> [d]
  +---+ 10 Gbps +---+ 10 Gbps +----+ 50 Gbps
  | A |---------| B |---------| GW |--------- Core
  +---+         +---+         +----+
 ...................
 .                 .
 .                 v
[a]               [b]

Site 2:

[d] <........................................ [c]
  +---+ 5 Gbps +---+ 10 Gbps +----+ 20 Gbps
  | X |--------| Y |---------| GW |--------- Core
  +---+        +---+         +----+
             ....................
             .                  .
             .                  v
            [e]                [f]
]]></artwork>
          </figure>
          <t>With the Path Vector extension, a site can reveal the bottlenecks inside 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 <xref target="G2" format="default"/> framework. format="default"/>. For
example, assume that hosts "a", "b", and "c" are in site Site 1 and hosts "d", "e", and "f" are in
site
Site 2, and there are 3 three flows in two sites: "a -&gt; b", "c -&gt; d", and "e -&gt; f". For
these flows, site 1 returns:</t> f" (<xref target="fig-sbot"/>).</t>

          <figure anchor="fig-sbot">
            <name>Example: Three Flows in Two Sites</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
Site 1:

[c]
 .
 ........................................> [d]
  +---+ 10 Gbps +---+ 10 Gbps +----+ 50 Gbps
  | A |---------| B |---------| GW |--------- Core
  +---+         +---+         +----+
 ...................
 .                 .
 .                 v
[a]               [b]

Site 2:

[d] <........................................ [c]
  +---+ 5 Gbps +---+ 10 Gbps +----+ 20 Gbps
  | X |--------| Y |---------| GW |--------- Core
  +---+        +---+         +----+
             ....................
             .                  .
             .                  v
            [e]                [f]
]]></artwork>
          </figure>
<t>For
these flows, Site 1 returns:</t>

          <sourcecode name="" type=""><![CDATA[
a: { b: [ane1] },
c: { d: [ane1, ane2, ane3] }

ane1: bw = 10 Gbps (link: A->B)
ane2: bw = 10 Gbps (link: B->GW)
ane3: bw = 50 Gbps (link: GW->Core)
]]></artwork>
]]></sourcecode>
          <t>and site Site 2 returns:</t>
          <artwork
          <sourcecode name="" type="" align="left" alt=""><![CDATA[ type=""><![CDATA[
c: { d: [anei, aneii, aneiii] }
e: { f: [aneiv] }

anei: bw = 5 Gbps (link Y->X)
aneii: bw = 10 Gbps (link GW->Y)
aneiii: bw = 20 Gbps (link Core->GW)
aneiv: bw = 10 Gbps (link Y->GW)
]]></artwork>
]]></sourcecode>
          <t>With the this information, the data transfer scheduler can use algorithms such as the
theory on bottleneck structure <xref target="G2" format="default"/> to predict the potential throughput of the
flows.</t>
        </section>
        <section anchor="resource-exposure-for-cdn-and-service-edge" numbered="true" toc="default">
          <name>Resource Exposure for CDN CDNs and Service Edge</name>
          <t>A Edges</name>
          <t>At the time of this writing, a growing trend in today's applications (2021) is to bring storage and computation
closer to the end users for better QoE, such as Content Delivery Network (CDN),
AR/VR, CDNs,
augmented reality / virtual reality, and cloud gaming, as reported in various documents (e.g., <xref target="SEREDGE" format="default"/> and
<xref target="MOWIE" format="default"/>). Internet Service Providers ISPs may deploy multiple layers of CDN caches,
or caches
or, more generally generally, service edges, with different latency latencies and available resources resources,
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
is measured in Gigabytes (G) gigabytes (GB) and storage is measured in Terabytes (T). terabytes (TB). The
"on-premise" edge nodes are closest to the end hosts and have the smallest lowest
latency, and the site-radio edge node and access central office (CO) have larger
latency higher
latencies but more available resources.</t>
          <figure anchor="fig-se">
            <name>Example Use Case for Service Edge Exposure</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
      +-------------+              +----------------------+
      | ALTO Client | <==========> | Application Provider |
      +-------------+              +----------------------+
PV         |   ^ PV                      |
Request    |   | Response                | Resource allocation,
           |   |                         | service establishment,
(End hosts |   | (Edge nodes             | etc.
and cloud  |   | and metrics)            |
servers)   |   |                         |
           v   |                         v
      +-------------+             +---------------------+
      | ALTO Server | <=========> | Cloud-Edge Provider |
      +-------------+             +---------------------+
       ____________________________________/\___________
      /                                                 \
      |           (((o                                  |
                     |
                    /_\             _~_            __   __
  a               (/\_/\)          (   )          (  )~(  )_
   \      /------(      )---------(     )----\\---(          )
   _|_   /        (______)         (___)          (          )
   |_| -/         Site-radio     Access CO       (__________)
  /---\          Edge Node 1         |             Cloud DC
On premise                           |
                           /---------/
           (((o           /
              |          /
 Site-radio  /_\        /
Edge Node 2(/\_/\)-----/
          /(_____)\
   ___   /         \   ---
b--|_| -/           \--|_|--c
  /---\               /---\
On premise          On premise
]]></artwork>
          </figure>
          <figure anchor="fig-se-example">
            <name>Example Service Edge Query Results</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
a: { b: [ane1, ane2, ane3, ane4, ane5],
     c: [ane1, ane2, ane3, ane4, ane6],
     DC: [ane1, ane2, ane3] }
b: { c: [ane5, ane4, ane6], DC: [ane5, ane4, ane3] }

ane1: latency=5ms cpu=2 memory=8G storage=10T
(on premise, a)

ane2: latency=20ms cpu=4 memory=8G storage=10T
(Site-radio Edge Node 1)

ane3: latency=100ms cpu=8 memory=128G storage=100T
(Access CO)

ane4: latency=20ms cpu=4 memory=8G storage=10T
(Site-radio Edge Node 2)

ane5: latency=5ms cpu=2 memory=8G storage=10T
(on premise, b)

ane6: latency=5ms cpu=2 memory=8G storage=10T
(on premise, c)
]]></artwork>
          </figure>
          <t>With the extension defined in this document, an ALTO server can selectively
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) 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 Here, each ANE represents a service edge edge, and
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">
            <name>Example Service Edge Query Results</name>
            <sourcecode name="" type=""><![CDATA[
a: { b: [ane1, ane2, ane3, ane4, ane5],
     c: [ane1, ane2, ane3, ane4, ane6],
     DC: [ane1, ane2, ane3] }
b: { c: [ane5, ane4, ane6], DC: [ane5, ane4, ane3] }

ane1: latency = 5 ms  cpu = 2  memory = 8 GB  storage = 10 TB
(On premise, a)

ane2: latency = 20 ms  cpu = 4  memory = 8 GB  storage = 10 TB
(Site-radio Edge Node 1)

ane3: latency = 100 ms  cpu = 8  memory = 128 GB  storage = 100 TB
(Access CO)

ane4: latency = 20 ms  cpu = 4  memory = 8 GB  storage = 10 TB
(Site-radio Edge Node 2)

ane5: latency = 5 ms  cpu = 2  memory = 8 GB  storage = 10 TB
(On premise, b)

ane6: latency = 5 ms  cpu = 2  memory = 8 GB  storage = 10 TB
(On premise, c)
]]></sourcecode>
          </figure>
          <t>With the service edge information, an ALTO client may better conduct CDN request
routing or offload functionalities from the user equipment to the service edge,
with considerations on in place for customized quality of experience.</t>
        </section>
      </section>
    </section>
    <section anchor="Overview" numbered="true" toc="default">
      <name>Path Vector Extension: Overview</name>
      <t>This section provides a non-normative overview of the Path Vector extension
defined in this document. It is assumed that the readers are familiar with both
the base protocol <xref target="RFC7285" format="default"/> and the Unified Property Map entity property map extension
<xref target="I-D.ietf-alto-unified-props-new" target="RFC9240" format="default"/>.</t>
      <t>To satisfy the additional requirements listed in Section 4.1, <xref target="design-requirements"/>, this extension:</t>
      <ol spacing="normal" type="1"><li>introduces the concept of Abstract Network Element (ANE) an ANE as the abstraction
of components in a network whose properties may have an impact on the
end-to-end performance of the traffic handled by those components,</li>
        <li>extends the Cost Map cost map and Endpoint Cost Service to convey the ANEs traversed
by the path of a &lt;source, destination&gt; pair as Path Vectors, and</li>
        <li>uses the Unified Property Map entity property map to convey the association between the
ANEs and their properties.</li>
      </ol>
      <t>Thus, an ALTO client can learn about the ANEs that are important to assess for assessing the
QoE of different &lt;source, destination&gt; pairs by investigating the corresponding
Path Vector value (AR1), identify (AR1) and can also (1)&nbsp;identify common ANEs if an ANE appears in the Path Vectors of multiple &lt;source, destination&gt; pairs (AR2), (AR2) and retrieve
(2)&nbsp;retrieve the properties of the ANEs by searching the Unified Property Map entity property map (AR3).</t>
      <section anchor="ane-design" numbered="true" toc="default">
        <name>Abstract Network Element (ANE)</name>
        <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
an impact on the end-to-end performance for application traffic between
endpoints.</t>
        <t>ANEs allow ALTO servers to focus on common properties of different types of
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
throughput of a firewall, the reserved bandwidth of an MPLS tunnel, etc. See In the
example below, assume that the throughput of the firewall is 100 Mbps and the
capacity for link (A, B) is also 100 Mbps, Mbps; they result in the same constraint on
the total throughput of f1 and f2. Thus, they are identical when treated as an
ANE.</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
   f1 |      ^                  f1
      |      |                 ----------------->
    +----------+                +---+     +---+
    | Firewall |                | A |-----| B |
    +----------+                +---+     +---+
      |      |                 ----------------->
      v      | f2               f2
]]></artwork>
        <t>When an ANE is defined by an ALTO server, it is assigned an identifier by the
ALTO server, i.e., a string of type ANEName as specified in <xref target="ane-name-spec" format="default"/>,
and a set of associated properties.</t>
        <section anchor="ane-entity-domain" numbered="true" toc="default">
          <name>ANE Entity Domain</name>
          <t>In this extension, the associations between ANE ANEs and the their properties are conveyed
in a Unified Property Map. Thus, an entity property map. &nbsp;Thus, ANEs must constitute an entity domain (Section
5.1 of <xref target="I-D.ietf-alto-unified-props-new" format="default"/>), "entity domain" (<xref target="RFC9240" sectionFormat="of" section="5.1"/>), and each ANE property must be an
entity property (Section 5.2 of <xref target="I-D.ietf-alto-unified-props-new" format="default"/>).</t> (<xref target="RFC9240" sectionFormat="of" section="5.2"/>).</t>
          <t>Specifically, this document defines a new entity domain called "ane" as
specified in <xref target="ane-domain-spec" format="default"/> and format="default"/>; <xref target="initial-ane-property-types"/> defines two initial properties property types for the ANE
entity domain.</t>
        </section>
        <section anchor="assoc" numbered="true" toc="default">
          <name>Ephemeral and Persistent ANEs</name>
          <t>By design, ANEs are ephemeral and not to be used in further requests to other
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
for a Path Vector request. Compared with globally unique ANE names, ephemeral
ANE has
ANEs have several benefits benefits, including better privacy of for the ISP's internal
structure and more flexible ANE computation.</t>
          <t>For example, an ALTO server may define an ANE for each aggregated bottleneck
link between the sources and destinations specified in the request. For requests
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
based on the information information, but it is difficult to infer the underlying topology with
multiple queries.</t>
          <t>However, sometimes an ISP may intend to selectively reveal some "persistent"
network components which, opposite 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.
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
complexity of state transition or synchronization, and continuously query the
properties of the edge cluster.</t>
          <t>This document provides a mechanism to expose such network components as
persistent ANEs. A persistent ANE has a persistent ID that is registered in a
Property Map,
property map, together with their its properties. See <xref Sections&nbsp;<xref target="domain-defining" format="default"/> format="counter"/> and
<xref target="persistent-entity-id" format="default"/> format="counter"/> for more detailed instructions on how to identify
ephemeral ANEs and persistent ANEs.</t>
        </section>
        <section anchor="property-filtering" numbered="true" toc="default">
          <name>Property Filtering</name>
          <t>Resource-constrained ALTO clients (see Section 4.1.2 of <xref target="RFC7285" format="default"/>) sectionFormat="of" section="4.1.2"/>) may benefit
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>
          <t>Specifically, the available properties for a given resource are announced in the
Information Resource Directory (IRD) as a new filtering capability called "ane-property-names".
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'. "ane-property-names" filter. The
response includes and only includes the selected properties for the ANEs in the
response.</t> ANEs.</t>
          <t>The "ane-property-names" capability for Cost Map the cost map and for the Endpoint Cost Service
is specified in <xref Sections&nbsp;<xref target="pvcm-cap" format="default"/> format="counter"/> and <xref target="pvecs-cap" format="default"/> format="counter"/>, respectively. The
"ane-property-names" filter for Cost Map the cost map and the Endpoint Cost Service is specified
in <xref Sections&nbsp;<xref target="pvcm-accept" format="default"/> format="counter"/> and <xref target="pvecs-accept" format="default"/> format="counter"/> accordingly.</t>
        </section>
      </section>
      <section anchor="path-vector-design" numbered="true" toc="default">
        <name>Path Vector Cost Type</name>
        <t>For an ALTO client to correctly interpret the Path Vector, this extension
specifies a new cost type called the Path "Path Vector cost type.</t> type".</t>
        <t>The Path Vector cost type must convey both the interpretation and semantics in
the "cost-mode" and "cost-metric" parameters, respectively. Unfortunately, a single
"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++
where C++,
if there existed a JSON array type named JSONArray, a Path Vector will would have
the type of <tt>JSONArray&lt;ANEName&gt;</tt>.</t>
        <t>Instead of extending the "type system" of ALTO, this document takes a simple
and backward compatible backward-compatible approach. Specifically, the "cost-mode" of the Path
Vector cost type is "array", which indicates that the value is a JSON array. Then, an
ALTO client must check the value of the "cost-metric". "cost-metric" parameter. If the value is
"ane-path", it means that the JSON array should be further interpreted as a path
of ANENames.</t>
        <t>The Path Vector cost type is specified in <xref target="cost-type-spec" format="default"/>.</t>
      </section>
      <section anchor="multipart-path-vector-response" numbered="true" toc="default">
        <name>Multipart Path Vector Response</name>
        <t>For a basic ALTO information resource, a response contains only one type of
ALTO resources, resource, e.g., Network Map, Cost Map, network map, cost map, or Property Map. Thus, property map. &nbsp;Thus, only one
round of communication is required: An an ALTO client sends a request to an ALTO
server, and the ALTO server returns a response, as shown in <xref target="fig-alto" format="default"/>.</t>
        <figure anchor="fig-alto">
          <name>A Typical ALTO Request and Response</name>
          <artwork type="drawing" type="" align="center" name="" alt=""><![CDATA[
  ALTO client                              ALTO server
       |-------------- Request ---------------->|
       |<------------- Response ----------------|
]]></artwork>
        </figure>
        <t>The extension defined in this document, on the other hand, involves two types of
information resources: Path Vectors conveyed in an InfoResourceCostMap data component (defined
in Section 11.2.3.6 of <xref target="RFC7285" format="default"/>) sectionFormat="of" section="11.2.3.6"/>) or an InfoResourceEndpointCostMap data component (defined
in Section 11.5.1.6 of <xref target="RFC7285" format="default"/>), sectionFormat="of" section="11.5.1.6"/>), and ANE properties conveyed in an
InfoResourceProperties data component (defined in Section 7.6 of <xref target="I-D.ietf-alto-unified-props-new" format="default"/>).</t> target="RFC9240" sectionFormat="of" section="7.6"/>).</t>
        <t>Instead of two consecutive message exchanges, the extension defined in this
document enforces one round of communication. Specifically, the ALTO client must
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
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 parts are bundled together in one
response message, their orders are interchangeable. See <xref Sections&nbsp;<xref target="pvcm-resp" format="default"/> format="counter"/> and
<xref target="pvecs-resp" format="default"/> format="counter"/> for details.</t>
        <figure anchor="fig-pv">
          <name>The Path Vector Extension Request and Response</name>
          <artwork type="drawing" type="" align="center" name="" alt=""><![CDATA[
  ALTO client                              ALTO server
       |------------- PV Request -------------->|
       |<----- PV Response (Cost Map Part) -----|
       |<--- PV Response (Property Map Part) ---|
]]></artwork>
        </figure>
        <t>This design is based on the following considerations:</t>
        <ol spacing="normal" type="1"><li>ANEs may be constructed on demand, and potentially demand and, potentially, based on the
requested properties (See (see <xref target="ane-design" format="default"/> for more details). If sources and
destinations are not in the same request as the properties, an ALTO server
either cannot construct ANEs on-demand, on demand or must wait until both requests are
received.</li>
          <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
to respond to the Property Map property map request correctly, an ALTO server must store
the mapping of each Path Vector request until the client fully retrieves the
property information. The This "stateful" behavior may substantially harm the
server scalability and potentially lead to Denial-of-Service denial-of-service attacks.</li>
        </ol>
        <t>One approach to realize for realizing the one-round communication is to define a new media
type to contain both objects, but this violates modular design. This document
follows the standard-conforming usage of the "multipart/related" media type as defined
in <xref target="RFC2387" format="default"/> to elegantly combine the objects. Path Vectors are encoded in an
InfoResourceCostMap data component or an InfoResourceEndpointCostMap, InfoResourceEndpointCostMap data component, and the Property Map property map is
encoded in an InfoResourceProperties. InfoResourceProperties data component. They are encapsulated as parts of a
multipart message. The This modular composition allows ALTO servers and clients to
reuse the data models of the existing information resources. Specifically, this
document addresses the following practical issues using "multipart/related".</t>
        <section anchor="identifying-the-media-type-of-the-root-object" numbered="true" toc="default">
          <name>Identifying the Media Type of the Root Object</name> Object Root</name>
          <t>ALTO uses a media type to indicate the type of an entry in the Information
Resource Directory (IRD) IRD (e.g., "application/alto-costmap+json" for Cost Map the cost map
and "application/alto-endpointcost+json" for the Endpoint Cost Service). Simply
putting
using "multipart/related" as the media type, however, makes it impossible
for an ALTO client to identify the type of service provided by related
entries.</t>
          <t>To address this issue, this document uses the "type" parameter to indicate the
root
object root of a multipart/related message. For a Cost Map cost map resource, the
"media-type" field in the IRD entry is "multipart/related" with the parameter
"type=application/alto-costmap+json"; for an Endpoint Cost Service, the
parameter is "type=application/alto-endpointcost+json".</t>
        </section>
        <section anchor="ref-partmsg-design" numbered="true" toc="default">
          <name>References to Part Messages</name>
          <t>As the response of a Path Vector resource is a multipart message with two
different parts, it is important that each part can be uniquely identified.
Following the designs of design provided in <xref target="RFC8895" format="default"/>, this extension requires that an ALTO
server assigns assign a unique identifier to each part of the multipart response
message. This identifier, referred to as a Part Resource ID (See (see
<xref target="part-rid-spec" format="default"/> for details), is present in the part message's "Content-ID"
header.
header field. By concatenating the Part Resource ID to the identifier of the Path
Vector request, an ALTO server/client can uniquely identify the Path Vector Part part
or the Property Map property map part.</t>
        </section>
      </section>
    </section>
    <section anchor="Basic" numbered="true" toc="default">
      <name>Specification: Basic Data Types</name>
      <section anchor="ane-name-spec" numbered="true" toc="default">
        <name>ANE Name</name>
        <t>An ANE Name name is encoded as a JSON string with the same format as that of the type
PIDName (Section 10.1 of <xref (<xref target="RFC7285" format="default"/>).</t> sectionFormat="of" section="10.1"/>).</t>
        <t>The type ANEName is used in this document to indicate a string of this
format.</t>
      </section>
      <section anchor="ane-domain-spec" numbered="true" toc="default">
        <name>ANE Entity Domain</name>
        <t>The ANE entity domain associates property values with the Abstract Network
Elements ANEs in a Property Map. Accordingly, property map. &nbsp;Accordingly, the ANE entity domain always depends on
a Property Map.</t> property map.</t>
        <t>It must be noted that the term "domain" here does not refer to a network domain.
Rather, it is inherited from the "entity domain" entity domain as defined in Sec 3.2 in
<xref target="I-D.ietf-alto-unified-props-new" format="default"/> that target="RFC9240" sectionFormat="of" section="3.2"/>; the entity domain represents the set of valid entities
defined by an ALTO information resource (called the defining "defining information
resource).</t>
resource").</t>
        <section anchor="domain-type" numbered="true" toc="default">
          <name>Entity Domain Type</name>
          <t>The Entity Domain Type entity domain type is "ane".</t>
        </section>
        <section anchor="entity-address" numbered="true" toc="default">
          <name>Domain-Specific Entity Identifier</name>
          <t>The entity identifiers are the ANE Names names in the associated Property Map.</t> property map.</t>
        </section>
        <section anchor="hierarchy-and-inheritance" numbered="true" toc="default">
          <name>Hierarchy and Inheritance</name>
          <t>There is no hierarchy or inheritance for properties associated with ANEs.</t>
        </section>
        <section anchor="domain-defining" numbered="true" toc="default">
          <name>Media Type of Defining Resource</name>
          <t>The defining resource for entity domain type "ane" MUST <bcp14>MUST</bcp14> be a Property Map, property map, i.e.,
the media type of defining resources is:</t>
         <artwork name="" type="" align="left" alt=""><![CDATA[
application/alto-propmap+json
]]></artwork>
          <t>Specifically, for ephemeral ANEs that appear in a Path Vector response, their
entity domain names MUST <bcp14>MUST</bcp14> be exactly ".ane" ".ane", and the defining resource of these
ANEs is the Property Map property map part of the multipart response. Meanwhile, for any
persistent ANE whose defining resource is a Property Map property map resource, its entity
domain name MUST <bcp14>MUST</bcp14> have the format of "PROPMAP.ane" "PROPMAP.ane", where PROPMAP is the resource
ID of the defining resource. Persistent entities are "persistent" because
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>
          <t>For example, the defining resource of an ephemeral ANE whose entity identifier
is ".ane:NET1" is the Property Map property map part that contains this identifier. The
defining resource of a persistent ANE whose entity identifier is
"dc-props.ane:DC1" is the Property Map property map with the resource ID "dc-props".</t>
        </section>
      </section>
      <section anchor="ane-prop-name-spec" numbered="true" toc="default">
        <name>ANE Property Name</name>
        <t>An ANE Property Name property name is encoded as a JSON string with the same format as that of
Entity Property Name (Section 5.2.2 of <xref target="I-D.ietf-alto-unified-props-new" format="default"/>).</t> an
entity property name (<xref target="RFC9240" sectionFormat="of" section="5.2.2"/>).</t>
      </section>
      <section anchor="initial-ane-property-types" numbered="true" toc="default">
        <name>Initial ANE Property Types</name>
        <t>Two initial ANE property types are specified, specified: "max-reservable-bandwidth" and
"persistent-entity-id".</t>
        <t>Note that these property types do not depend on any information resource. resources. As
such, the EntityPropertyName MUST "EntityPropertyName" parameter <bcp14>MUST</bcp14> only have the EntityPropertyType part.</t>
        <section anchor="maxresbw" numbered="true" toc="default">
          <name>Maximum Reservable Bandwidth</name>
          <t>The maximum reservable bandwidth property ("max-reservable-bandwidth") stands
for the maximum bandwidth that can be reserved for all the traffic that
traverses an ANE. The value MUST <bcp14>MUST</bcp14> be encoded as a non-negative numerical cost
value as defined in Section 6.1.2.1 of
<xref target="RFC7285" format="default"/> sectionFormat="of" section="6.1.2.1"/>, and the unit is bit bits per
second (bps). If this property is requested by the ALTO client but is not present
for an ANE in the server response, it MUST <bcp14>MUST</bcp14> be interpreted as meaning that the property
is not defined for the ANE.</t>
          <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
is part of a user application. One existing example is <xref target="NOVA" format="default"/>: the ALTO server
is part of an SDN 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
from the Path Vector response defined in this document in that the Path Vector part
and Property Map property map part are put placed in the same JSON object.</t>
          <t>In such a framework, the ALTO server exposes resource
availability information (e.g., reservable bandwidth)
availability information to the ALTO client. How the client makes resource
requests based on the information information, and how the resource allocation is achieved
respectively achieved,
respectively, depend on interfaces between the management system and the users or
a higher-layer protocol (e.g., SDN network intents <xref target="INTENT-BASED-NETWORKING"/> or MPLS tunnels), which are
out of the scope of for this document.</t>
        </section>
        <section anchor="persistent-entity-id" numbered="true" toc="default">
          <name>Persistent Entity ID</name>
          <t>The persistent entity ID property is
          <t>This document enables the discovery of a persistent ANE by exposing its
entity identifier of as the persistent
ANE which entity ID property of an ephemeral ANE presents (See <xref target="assoc" format="default"/> for details). in the path
vector response. The value of this property is encoded with the format EntityID format defined in Section 5.1.3 of <xref target="I-D.ietf-alto-unified-props-new" format="default"/>.</t> target="RFC9240" sectionFormat="of" section="5.1.3"/>.</t>
          <t>In this format, the entity ID combines:</t>
          <ul spacing="normal">
            <li>a defining information resource for the ANE on which a
"persistent-entity-id" is queried, which is the Property Map property map resource
defining the ANE as a persistent entity, together with the properties;</li> properties.</li>
            <li>the persistent name of the ANE in that Property Map.</li> property map.</li>
          </ul>
          <t>With this format, the client has all the needed information for further
standalone query properties on the persistent ANE.</t>
        </section>
        <section anchor="examples" numbered="true" toc="default">
          <name>Examples</name>
          <t>To illustrate the use of "max-reservable-bandwidth", consider the following
network with 5 five nodes. Assume that the client wants to query the maximum reservable
bandwidth from H1 to H2. An ALTO server may split the network into two ANEs:
"ane1" that
"ane1", which represents the subnetwork with routers A, B, and C, C; and "ane2" that "ane2", which
represents the subnetwork with routers B, D D, and E. The maximum reservable
bandwidth for "ane1" is 15 Mbps (using path A-&gt;C-&gt;B) A-&gt;C-&gt;B), and the maximum reservable
bandwidth for "ane2" is 20 Mbps (using path B-&gt;D-&gt;E).</t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
                     20 Mbps  20 Mbps
          10 Mbps +---+   +---+    +---+
             /----| B |---| D |----| E |---- H2
       +---+/     +---+   +---+    +---+
H1 ----| A | 15 Mbps|
       +---+\     +---+
             \----| C |
          15 Mbps +---+
]]></artwork>
          <t>To illustrate the use of "persistent-entity-id", consider the scenario in
<xref target="fig-se" format="default"/>. As the life cycle cycles of service edges are typically long, they the service edges may
contain information that is not specific to the query. Such information can be
stored in an individual unified entity property map and can later be accessed by an ALTO
client.</t>
          <t>For example, "ane1" in <xref target="fig-se-example" format="default"/> represents the on-premise service edge
closest to host a. "a". Assume that the properties of the service edges are provided in
a unified
an entity property map called "se-props" and the ID of the on-premise service
edge is "9a0b55f7-7442-4d56-8a2c-b4cc6a8e3aa1", "9a0b55f7-7442-4d56-8a2c-b4cc6a8e3aa1"; the "persistent-entity-id" of setting for
"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
with the entity ID ".ane:9a0b55f7-7442-4d56-8a2c-b4cc6a8e3aa1".</t>
        </section>
      </section>
      <section anchor="cost-type-spec" numbered="true" toc="default">
        <name>Path Vector Cost Type</name>
        <t>This document defines a new cost type, which is referred to as the Path Vector
cost type. An ALTO server MUST <bcp14>MUST</bcp14> offer this cost type if it supports the extension
defined in this document.</t>
        <section anchor="metric-spec" numbered="true" toc="default">
          <name>Cost Metric: ane-path</name> &quot;ane-path&quot;</name>
          <t>The cost metric "ane-path" indicates that the value of such a cost type conveys an
array of ANE names, where each ANE name uniquely represents an ANE traversed by
traffic from a source to a destination.</t>
          <t>An ALTO client MUST <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
in the Path Vector.</t>
          <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
<xref target="mode-spec" format="default"/>) MUST <bcp14>MUST</bcp14> return as the cost value a JSON array of ANEName data type ANEName, and the
client MUST <bcp14>MUST</bcp14> also check that each element contained in the array is an ANEName
(<xref target="ane-name-spec" format="default"/>). Otherwise, the client MUST <bcp14>MUST</bcp14> discard the response and SHOULD <bcp14>SHOULD</bcp14>
follow the instructions guidance in Section 8.3.4.3 of <xref target="RFC7285" format="default"/> sectionFormat="of" section="8.3.4.3"/> to handle the error.</t>
        </section>
        <section anchor="mode-spec" numbered="true" toc="default">
          <name>Cost Mode: array</name> &quot;array&quot;</name>
          <t>The cost mode "array" indicates that every cost value in the response body of a
(Filtered) Cost Map
(filtered) cost map or an Endpoint Cost Service MUST <bcp14>MUST</bcp14> be interpreted as a JSON
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 "array"
cost mode when combined with cost metrics other than 'ane-path'.</t> "ane-path".</t>
        </section>
      </section>
      <section anchor="part-rid-spec" numbered="true" toc="default">
        <name>Part Resource ID and Part Content ID</name>
        <t>A Part Resource ID is encoded as a JSON string with the same format as that of the
type ResourceID (Section 10.2 of <xref (<xref target="RFC7285" format="default"/>).</t> sectionFormat="of" section="10.2"/>).</t>
        <t>Even though the client-id "client-id" assigned to a Path Vector request and the Part
Resource ID MAY <bcp14>MAY</bcp14> contain up to 64 characters by their own definition, their
concatenation (see <xref target="ref-partmsg-design" format="default"/>) MUST <bcp14>MUST</bcp14> also conform to the same length
constraint. The same requirement applies to the resource ID of the Path Vector
resource, too. Thus, it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> to limit the length of the resource ID and
client ID related to a Path Vector resource to 31 characters.</t>
        <t>A Part Content ID conforms to the format of msg-id "msg-id" as specified in
<xref target="RFC2387" format="default"/> and <xref target="RFC5322" format="default"/>. Specifically, it has the following format:</t>
        <t>"&lt;" PART-RESOURCE-ID "@" DOMAIN-NAME "&gt;"</t>
        <dl>
          <dt>
PART-RESOURCE-ID:  </dt>
          <dd>
            <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> property map.</t>
          </dd>
          <dt>
DOMAIN-NAME:  </dt>
          <dd>
            <t>DOMAIN-NAME has the same format as dot-atom-text "dot-atom-text" as specified in Section 3.2.3 of
<xref target="RFC5322" format="default"/>. sectionFormat="of" section="3.2.3"/>. It must be the domain name of the ALTO server.</t>
          </dd>
        </dl>
      </section>
    </section>
    <section anchor="Services" numbered="true" toc="default">
      <name>Specification: Service Extensions</name>
      <section anchor="notations" anchor="notation" numbered="true" toc="default">
        <name>Notations</name>
        <name>Notation</name>
        <t>This document uses the same syntax and notations notation as those introduced in Section 8.2 of
RFC 7285 <xref target="RFC7285" format="default"/> sectionFormat="of" section="8.2"/> to specify the extensions to existing ALTO resources and
services.</t>
      </section>
      <section anchor="pvcm-spec" numbered="true" toc="default">
        <name>Multipart Filtered Cost Map for Path Vector</name>
        <t>This document introduces a new ALTO resource called multipart Filtered Cost Map
resource, the "multipart filtered cost map
resource", which allows an ALTO server to provide other ALTO resources associated
with the Cost Map cost map resource in the same response.</t>
        <section anchor="media-type" numbered="true" toc="default">
          <name>Media Type</name>
          <t>The media type of the multipart Filtered Cost Map filtered cost map resource is
"multipart/related"
"multipart/related", and the required "type" parameter MUST <bcp14>MUST</bcp14> have
a value of "application/alto-costmap+json".</t>
        </section>
        <section anchor="http-method" numbered="true" toc="default">
          <name>HTTP Method</name>
          <t>The multipart Filtered Cost Map filtered cost map is requested using the HTTP POST method.</t>
        </section>
        <section anchor="pvcm-accept" numbered="true" toc="default">
          <name>Accept Input Parameters</name>
          <t>The input parameters of the multipart Filtered Cost Map filtered cost map are supplied in the body
of an HTTP POST request. This document extends the input parameters to a
Filtered Cost Map,
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="default"/>, sectionFormat="of" section="4.1.2"/>, with a data
format indicated by the media type "application/alto-costmapfilter+json", which
is a JSON object of type PVReqFilteredCostMap:</t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
object {
  [EntityPropertyName ane-property-names<0..*>;]
} PVReqFilteredCostMap : ReqFilteredCostMap;
]]></artwork>
          <t>with fields:</t> field:</t>
          <dl>
            <dt>
ane-property-names:  </dt>
            <dd>
              <t>A
              <t>This field provides a list of selected ANE properties to be included in the response. Each
property in this list MUST <bcp14>MUST</bcp14> match one of the supported ANE properties indicated
in the resource's "ane-property-names" capability (<xref target="pvcm-cap" format="default"/>). If the
field is not present, it MUST <bcp14>MUST</bcp14> be interpreted as an empty list.</t>
            </dd>
          </dl>
          <t>Example: Consider the network in <xref target="fig-dumbbell" format="default"/>. If an ALTO client wants to
query the "max-reservable-bandwidth" setting between PID1 and PID2, it can submit the
following request.</t>
          <artwork
          <sourcecode name="" type="" align="left" alt=""><![CDATA[ type="http-message"><![CDATA[
   POST /costmap/pv HTTP/1.1
   Host: alto.example.com
   Accept: multipart/related;type=application/alto-costmap+json,
           application/alto-error+json
   Content-Length: 201 212
   Content-Type: application/alto-costmapfilter+json

   {
     "cost-type": {
       "cost-mode": "array",
       "cost-metric": "ane-path"
     },
     "pids": {
       "srcs": [ "PID1" ],
       "dsts": [ "PID2" ]
     },
     "ane-property-names": [ "max-reservable-bandwidth" ]
   }
]]></artwork>
]]></sourcecode>
        </section>
        <section anchor="pvcm-cap" numbered="true" toc="default">
          <name>Capabilities</name>
          <t>The multipart Filtered Cost Map filtered cost map resource extends the capabilities defined
in Section 4.1.1 of <xref target="RFC8189" format="default"/>. sectionFormat="of" section="4.1.1"/>. The capabilities are defined by a JSON
object of type PVFilteredCostMapCapabilities:</t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
object {
  [EntityPropertyName ane-property-names<0..*>;]
} PVFilteredCostMapCapabilities : FilteredCostMapCapabilities;
]]></artwork>
          <t>with fields:</t> field:</t>
          <dl>
            <dt>
ane-property-names:  </dt>
            <dd>
              <t>Defines
              <t>This field provides a list of ANE properties that can be returned. If the field is not
present, it MUST <bcp14>MUST</bcp14> be interpreted as an empty list, indicating that the ALTO server
cannot provide any ANE property.</t> properties.</t>
            </dd>
          </dl>
          <t>This extension also introduces additional restrictions for the following fields:</t>
          <dl>
            <dt>
cost-type-names:  </dt>
            <dd>
              <t>The "cost-type-names" field MUST <bcp14>MUST</bcp14> include the Path Vector cost type,
unless explicitly documented by a future extension. This also implies that the
Path Vector cost type MUST <bcp14>MUST</bcp14> be defined in the "cost-types" of the Information
Resource Directory's IRD's "meta" field.</t>
            </dd>
            <dt>
cost-constraints:  </dt>
            <dd>
              <t>If the "cost-type-names" field includes the Path Vector cost type,
the "cost-constraints" field MUST <bcp14>MUST</bcp14> be either "false" or not present present,
unless specifically
instructed by a future document.</t>
            </dd>
            <dt>
testable-cost-type-names (Section 4.1.1 of <xref (<xref target="RFC8189" format="default"/>): sectionFormat="of" section="4.1.1"/>):  </dt>
            <dd>
              <t>If the "cost-type-names" field includes the Path Vector cost type and the
"testable-cost-type-names" field is present, the Path Vector cost type MUST
NOT <bcp14>MUST
NOT</bcp14> be included in the "testable-cost-type-names" field unless specifically
instructed by a future document.</t>
            </dd>
          </dl>
        </section>
        <section anchor="uses" numbered="true" toc="default">
          <name>Uses</name>
          <t>This member MUST <bcp14>MUST</bcp14> include the resource ID of the network map based on which the
PIDs are defined. If this resource supports "persistent-entity-id", it MUST <bcp14>MUST</bcp14> also
include the defining resources of persistent ANEs that may appear in the response.</t>
        </section>
        <section anchor="pvcm-resp" numbered="true" toc="default">
          <name>Response</name>
          <t>The response MUST <bcp14>MUST</bcp14> indicate an error, using ALTO protocol Protocol error handling, handling as
defined in Section 8.5 of <xref target="RFC7285" format="default"/>, sectionFormat="of" section="8.5"/>, if the request is invalid.</t>
          <t>The "Content-Type" header field of the response MUST <bcp14>MUST</bcp14> be "multipart/related" as defined
by <xref target="RFC2387" format="default"/> format="default"/>, with the following parameters:</t>
          <dl>
            <dt>
type:  </dt>
            <dd>
              <t>The type "type" parameter is mandatory and MUST <bcp14>MUST</bcp14> be "application/alto-costmap+json". Note
that <xref target="RFC2387" format="default"/> permits both parameters both with and without the double quotes.</t>
            </dd>
            <dt>
start:  </dt>
            <dd>
              <t>The start "start" parameter is as defined in <xref target="RFC2387" format="default"/> and is optional.
If present, it MUST <bcp14>MUST</bcp14> have the same value as the "Content-ID" header field of the Path
Vector part.</t>
            </dd>
            <dt>
boundary:  </dt>
            <dd>
              <t>The boundary "boundary" parameter is as defined in Section 5.1.1 of <xref target="RFC2046" format="default"/> sectionFormat="of" section="5.1.1"/> and is mandatory.</t>
            </dd>
          </dl>
          <t>The body of the response MUST <bcp14>MUST</bcp14> consist of two parts:</t>
          <ul spacing="normal">
            <li>
              <t>The Path Vector part MUST <bcp14>MUST</bcp14> include "Content-ID" and "Content-Type" in its
header. The "Content-Type" MUST <bcp14>MUST</bcp14> be "application/alto-costmap+json".
The value of "Content-ID" MUST <bcp14>MUST</bcp14> have the same format as the Part Content ID as
specified in <xref target="part-rid-spec" format="default"/>.  </t>
              <t>
The body of the Path Vector part MUST <bcp14>MUST</bcp14> be a JSON object with the same format as that
defined in Section 11.2.3.6 of <xref target="RFC7285" format="default"/> sectionFormat="of" section="11.2.3.6"/> when the "cost-type" field is
present in the input parameters and MUST <bcp14>MUST</bcp14> be a JSON object with the same format
as that defined in Section 4.1.3 of <xref target="RFC8189" format="default"/> sectionFormat="of" section="4.1.3"/> if the "multi-cost-types" field is
present. The JSON object MUST <bcp14>MUST</bcp14> include the
"vtag" field in the "meta" field, which provides the version tag of the
returned CostMapData. CostMapData object. The resource ID of the version tag MUST <bcp14>MUST</bcp14> follow the
format of  </t>
              <artwork
              <sourcecode name="" type="" align="left" alt=""><![CDATA[ type="rbnf"><![CDATA[
resource-id '.' part-resource-id
]]></artwork>
]]></sourcecode>
              <t>
where "resource-id" is the resource Id ID of the Path Vector resource, resource and
"part-resource-id" has the same value as the PART-RESOURCE-ID in the
"Content-ID" of the Path Vector part.
The "meta" field MUST <bcp14>MUST</bcp14> also include the "dependent-vtags" field, whose value is
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
Filtered Cost Map
filtered cost map resource in the IRD.</t>
            </li>
            <li>
              <t>The Unified Property Map entity property map part MUST <bcp14>MUST</bcp14> also include "Content-ID" and
"Content-Type" in its header. The "Content-Type" MUST <bcp14>MUST</bcp14> be
"application/alto-propmap+json". The value of "Content-ID" MUST <bcp14>MUST</bcp14> have the same
format as the Part Content ID as specified in <xref target="part-rid-spec" format="default"/>.  </t>
              <t>
The body of the Unified Property Map entity property map part is a JSON object with the same
format as that defined in Section 7.6 of <xref target="I-D.ietf-alto-unified-props-new" format="default"/>. target="RFC9240" sectionFormat="of" section="7.6"/>. The
JSON object MUST <bcp14>MUST</bcp14> include the "dependent-vtags" field in the "meta" field. The
value of the "dependent-vtags" field MUST <bcp14>MUST</bcp14> be an array of VersionTag objects as
defined by Section 10.3 of <xref target="RFC7285" format="default"/>. sectionFormat="of" section="10.3"/>. The "vtag" of the Path Vector part MUST <bcp14>MUST</bcp14>
be included in the "dependent-vtags". "dependent-vtags" field. If "persistent-entity-id" is requested, the
version tags of the dependent resources that may expose the entities in the
response MUST <bcp14>MUST</bcp14> also be included.  </t>
              <t>
The PropertyMapData object has one member for each ANEName that appears in the Path
Vector part, which is an entity identifier belonging to the self-defined
entity domain as defined in Section 5.1.2.3 of
<xref target="I-D.ietf-alto-unified-props-new" format="default"/>. target="RFC9240" sectionFormat="of" section="5.1.2.3"/>. The EntityProps object for each ANE has one
member for each property that is both 1) associated with the ANE, ANE and 2)
specified in the "ane-property-names" field in the request. If the Path Vector cost
type is not included in the "cost-type" field or the "multi-cost-type" field,
the "property-map" field MUST <bcp14>MUST</bcp14> be present and the value MUST <bcp14>MUST</bcp14> be an empty object
({}).</t>
            </li>
          </ul>
          <t>A complete and valid response MUST <bcp14>MUST</bcp14> include both the Path Vector part and the
Property Map
property map part in the multipart message. If any part is NOT <strong>not</strong> present, the
client MUST <bcp14>MUST</bcp14> discard the received information and send another request if
necessary.</t>
          <t>According to <xref target="RFC2387" format="default"/>, the
          <t>The Path Vector part, whose media type is the same as the "type" parameter of the multipart response message, is the root
object. body part as defined in
<xref target="RFC2387" format="default"/>. Thus, it is the element that the application processes first. Even though the
"start" parameter allows it to be placed anywhere in the part sequence, it is
RECOMMENDED
<bcp14>RECOMMENDED</bcp14> that the parts arrive in the same order as they are processed, i.e.,
the Path Vector part is always put placed as the first part, followed by the Property
Map property
map part. When doing so, an ALTO server MAY <bcp14>MAY</bcp14> choose not to set the "start"
parameter, which implies that the first part is the root object.</t> object root.</t>
          <t>Example: Consider the network in <xref target="fig-dumbbell" format="default"/>. The response of to the example
request in <xref target="pvcm-accept" format="default"/> is as follows, where "ANE1" represents the
aggregation of all the switches in the network.</t>
          <artwork
          <sourcecode name="" type="" align="left" alt=""><![CDATA[ type="http-message"><![CDATA[
HTTP/1.1 200 OK
Content-Length: 859 911
Content-Type: multipart/related; boundary=example-1;
              type=application/alto-costmap+json

--example-1
Content-ID: <costmap@alto.example.com>
Content-Type: application/alto-costmap+json

{
  "meta": {
    "vtag": {
      "resource-id": "filtered-cost-map-pv.costmap",
      "tag": "fb20b76204814e9db37a51151faaaef2"
    },
    "dependent-vtags": [
      {
        "resource-id": "my-default-networkmap",
        "tag": "75ed013b3cb58f896e839582504f6228"
      }
    ],
    "cost-type": { "cost-mode": "array", "cost-metric": "ane-path" }
  },
  "cost-map": {
    "PID1": { "PID2": ["ANE1"] [ "ANE1" ] }
  }
}
--example-1
Content-ID: <propmap@alto.example.com>
Content-Type: application/alto-propmap+json

{
  "meta": {
    "dependent-vtags": [
      {
        "resource-id": "filtered-cost-map-pv.costmap",
        "tag": "fb20b76204814e9db37a51151faaaef2"
      }
    ]
  },
  "property-map": {
    ".ane:ANE1": { "max-reservable-bandwidth": 100000000 }
  }
}
]]></artwork>
          <!-- TODO: Error Handling -->
--example-1
]]></sourcecode>
</section>
      </section>
      <section anchor="pvecs-spec" numbered="true" toc="default">
        <name>Multipart Endpoint Cost Service for Path Vector</name>
        <t>This document introduces a new ALTO resource called multipart the "multipart Endpoint Cost
Service,
Service", which allows an ALTO server to provide other ALTO resources associated
with the Endpoint Cost Service resource in the same response.</t>
        <section anchor="media-type-1" numbered="true" toc="default">
          <name>Media Type</name>
          <t>The media type of the multipart Endpoint Cost Service resource is
"multipart/related"
"multipart/related", and the required "type" parameter MUST <bcp14>MUST</bcp14> have
a value of "application/alto-endpointcost+json".</t>
        </section>
        <section anchor="http-method-1" numbered="true" toc="default">
          <name>HTTP Method</name>
          <t>The multipart Endpoint Cost Service resource is requested using the HTTP POST method.</t>
        </section>
        <section anchor="pvecs-accept" numbered="true" toc="default">
          <name>Accept Input Parameters</name>
          <t>The input parameters of the multipart Endpoint Cost Service resource are
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
type ReqEndpointCost ReqEndpointCostMap in Section 4.2.2 of <xref target="RFC8189" format="default"/>, sectionFormat="of" section="4.2.2"/>, with a data
format indicated by the media type "application/alto-endpointcostparams+json",
which is a JSON object of type PVReqEndpointCost:</t> PVReqEndpointCostMap:</t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
object {
  [EntityPropertyName ane-property-names<0..*>;]
} PVReqEndpointcost PVReqEndpointCostMap : ReqEndpointcostMap; ReqEndpointCostMap;
]]></artwork>
          <t>with fields:</t> field:</t>
          <dl>
            <dt>
ane-property-names:  </dt>
            <dd>
              <t>This document defines the "ane-property-names" field in PVReqEndpointcost PVReqEndpointCostMap as being the
same as in PVReqFilteredCostMap. See <xref target="pvcm-accept" format="default"/>.</t>
            </dd>
          </dl>
          <t>Example: Consider the network in <xref target="fig-dumbbell" format="default"/>. If an ALTO client wants to
query the "max-reservable-bandwidth" setting between eh1 "eh1" and eh2, "eh2", it can submit the
following request.</t>
          <artwork
          <sourcecode name="" type="" align="left" alt=""><![CDATA[ type="http-message"><![CDATA[
POST /ecs/pv HTTP/1.1
Host: alto.example.com
Accept: multipart/related;type=application/alto-endpointcost+json,
        application/alto-error+json
Content-Length: 227 238
Content-Type: application/alto-endpointcostparams+json

{
  "cost-type": {
    "cost-mode": "array",
    "cost-metric": "ane-path"
  },
  "endpoints": {
    "srcs": [ "ipv4:192.0.2.2" ],
    "dsts": [ "ipv4:192.0.2.18" ]
  },
  "ane-property-names": [ "max-reservable-bandwidth" ]
}
]]></artwork>
]]></sourcecode>
        </section>
        <section anchor="pvecs-cap" numbered="true" toc="default">
          <name>Capabilities</name>
          <t>The capabilities of the multipart Endpoint Cost Service resource are defined by
a JSON object of type PVEndpointcostCapabilities, PVEndpointCostCapabilities, which is defined as being the same
as PVFilteredCostMapCapabilities. See <xref target="pvcm-cap" format="default"/>.</t>
        </section>
        <section anchor="uses-1" numbered="true" toc="default">
          <name>Uses</name>
          <t>If this resource supports "persistent-entity-id", it MUST <bcp14>MUST</bcp14> also include the
defining resources of persistent ANEs that may appear in the response.</t>
        </section>
        <section anchor="pvecs-resp" numbered="true" toc="default">
          <name>Response</name>
          <t>The response MUST <bcp14>MUST</bcp14> indicate an error, using ALTO protocol Protocol error handling, handling as
defined in Section 8.5 of <xref target="RFC7285" format="default"/>, sectionFormat="of" section="8.5"/>, if the request is invalid.</t>
          <t>The "Content-Type" header field of the response MUST <bcp14>MUST</bcp14> be "multipart/related" as defined
by <xref target="RFC7285" format="default"/> target="RFC2387" format="default"/>, with the following parameters:</t>
          <dl>
            <dt>
type:  </dt>
            <dd>
              <t>The type "type" parameter MUST <bcp14>MUST</bcp14> be "application/alto-endpointcost+json" and is mandatory.</t>
            </dd>
            <dt>
start:  </dt>
            <dd>
              <t>The start "start" parameter is as defined in <xref target="pvcm-resp" format="default"/>.</t>
            </dd>
            <dt>
boundary:  </dt>
            <dd>
              <t>The boundary "boundary" parameter is as defined in Section 5.1.1 of <xref target="RFC2046" format="default"/> sectionFormat="of" section="5.1.1"/> and is mandatory.</t>
            </dd>
          </dl>
          <t>The body MUST of the response <bcp14>MUST</bcp14> consist of two parts:</t>
          <ul spacing="normal">
            <li>
              <t>The Path Vector part MUST <bcp14>MUST</bcp14> include "Content-ID" and "Content-Type" in its
header.
The "Content-Type" MUST <bcp14>MUST</bcp14> be "application/alto-endpointcost+json".
The value of "Content-ID" MUST <bcp14>MUST</bcp14> have the same format as the Part Content ID as
specified in <xref target="part-rid-spec" format="default"/>.  </t>
              <t>
The body of the Path Vector part MUST <bcp14>MUST</bcp14> be a JSON object with the same format as that
defined in Section 11.5.1.6 of <xref target="RFC7285" format="default"/> sectionFormat="of" section="11.5.1.6"/> when the "cost-type" field is
present in the input parameters and MUST <bcp14>MUST</bcp14> be a JSON object with the same format
as that defined in Section 4.2.3 of <xref target="RFC8189" format="default"/> sectionFormat="of" section="4.2.3"/> if the "multi-cost-types" field is
present. The JSON object MUST <bcp14>MUST</bcp14> include the
"vtag" field in the "meta" field, which provides the version tag of the returned
EndpointCostMapData.
EndpointCostMapData object. The resource ID of the version tag MUST <bcp14>MUST</bcp14> follow the format of  </t>
              <artwork
              <sourcecode name="" type="" align="left" alt=""><![CDATA[ type="rbnf"><![CDATA[
resource-id '.' part-resource-id
]]></artwork>
]]></sourcecode>
              <t>
where "resource-id" is the resource Id ID of the Path Vector resource, resource and
"part-resource-id" has the same value as the PART-RESOURCE-ID in the "Content-ID"
of the Path Vector part.</t>
            </li>
            <li>
              <t>The Unified Property Map entity property map part MUST <bcp14>MUST</bcp14> also include "Content-ID" and
"Content-Type" in its header. The "Content-Type" MUST <bcp14>MUST</bcp14> be
"application/alto-propmap+json".
The value of "Content-ID" MUST <bcp14>MUST</bcp14> have the same format as the Part Content ID as
specified in <xref target="part-rid-spec" format="default"/>.  </t>
              <t>
The body of the Unified Property Map entity property map part MUST <bcp14>MUST</bcp14> be a JSON object with the same
format as that defined in Section 7.6 of <xref target="I-D.ietf-alto-unified-props-new" format="default"/>. target="RFC9240" sectionFormat="of" section="7.6"/>. The
JSON object MUST <bcp14>MUST</bcp14> include the "dependent-vtags" field in the "meta" field. The
value of the "dependent-vtags" field MUST <bcp14>MUST</bcp14> be an array of VersionTag objects as
defined by Section 10.3 of <xref target="RFC7285" format="default"/>. sectionFormat="of" section="10.3"/>. The "vtag" of the Path Vector part MUST <bcp14>MUST</bcp14>
be included in the "dependent-vtags". "dependent-vtags" field. If "persistent-entity-id" is requested, the
version tags of the dependent resources that may expose the entities in the
response MUST <bcp14>MUST</bcp14> also be included.  </t>
              <t>
The PropertyMapData object has one member for each ANEName that appears in the Path
Vector part, which is an entity identifier belonging to the self-defined
entity domain as defined in Section 5.1.2.3 of
<xref target="I-D.ietf-alto-unified-props-new" format="default"/>. target="RFC9240" sectionFormat="of" section="5.1.2.3"/>. The EntityProps object for each ANE has one
member for each property that is both 1) associated with the ANE, ANE and 2)
specified in the "ane-property-names" field in the request. If the Path Vector cost
type is not included in the "cost-type" field or the "multi-cost-type" field,
the "property-map" field MUST <bcp14>MUST</bcp14> be present and the value MUST <bcp14>MUST</bcp14> be an empty object
({}).</t>
            </li>
          </ul>
          <t>A complete and valid response MUST <bcp14>MUST</bcp14> include both the Path Vector part and the
Property Map
property map part in the multipart message. If any part is NOT <strong>not</strong> present, the
client MUST <bcp14>MUST</bcp14> discard the received information and send another request if
necessary.</t>
          <t>According to <xref target="RFC2387" format="default"/>, the
          <t>The Path Vector part, whose media type is the same as the "type" parameter of the multipart response message, is the root
object. body part as defined in
<xref target="RFC2387" format="default"/>. Thus, it is the element that the application processes first. Even though the
"start" parameter allows it to be placed anywhere in the part sequence, it is
RECOMMENDED
<bcp14>RECOMMENDED</bcp14> that the parts arrive in the same order as they are processed, i.e.,
the Path Vector part is always put placed as the first part, followed by the Property
Map property
map part. When doing so, an ALTO server MAY <bcp14>MAY</bcp14> choose not to set the "start"
parameter, which implies that the first part is the root object.</t> object root.</t>
          <t>Example: Consider the network in <xref target="fig-dumbbell" format="default"/>. The response of to the example
request in <xref target="pvecs-accept" format="default"/> is as follows.</t>
          <artwork
          <sourcecode name="" type="" align="left" alt=""><![CDATA[ type="http-message"><![CDATA[
HTTP/1.1 200 OK
Content-Length: 845 899
Content-Type: multipart/related; boundary=example-1;
              type=application/alto-endpointcost+json

--example-1
Content-ID: <ecs@alto.example.com>
Content-Type: application/alto-endpointcost+json

{
  "meta": {
    "vtag": {
      "resource-id": "ecs-pv.ecs",
      "tag": "ec137bb78118468c853d5b622ac003f1"
    },
    "dependent-vtags": [
      {
        "resource-id": "my-default-networkmap",
        "tag": "677fe5f4066848d282ece213a84f9429"
      }
    ],
    "cost-type": { "cost-mode": "array", "cost-metric": "ane-path" }
  },
  "cost-map": {
    "ipv4:192.0.2.2": { "ipv4:192.0.2.18": ["ANE1"] [ "ANE1" ] }
  }
}
--example-1
Content-ID: <propmap@alto.example.com>
Content-Type: application/alto-propmap+json

{
  "meta": {
    "dependent-vtags": [
      {
        "resource-id": "ecs-pv.ecs",
        "tag": "ec137bb78118468c853d5b622ac003f1"
      }
    ]
  },
  "property-map": {
    ".ane:ANE1": { "max-reservable-bandwidth": 100000000 }
  }
}
]]></artwork>
--example-1
]]></sourcecode>
        </section>
      </section>
    </section>
    <section anchor="Examples" numbered="true" toc="default">
      <name>Examples</name>
      <t>This section lists some examples of Path Vector queries and the corresponding
responses. Some long lines are truncated for better readability.</t>
      <section anchor="sample-setup" numbered="true" toc="default">
        <name>Sample Setup</name>
        <t><xref target="fig-pe" format="default"/> illustrates the network properties and thus the message contents. There
are three subnetworks (NET1, NET2, and NET3) and two interconnection links (L1 and
L2). It is assumed that each subnetwork has sufficiently large bandwidth to be
reserved.</t>
        <figure anchor="fig-pe">
          <name>Examples of ANE Properties</name>
          <artwork type="drawing" type="" align="center" name="" alt=""><![CDATA[
                                     ----- L1
                                    /
        PID1   +----------+ 10 Gbps +----------+    PID3
 192.0.2.0/28+-+ +------+ +---------+          +--+192.0.2.32/28
               | | MEC1 | |         |          |   2001:db8::3:0/16
               | +------+ |   +-----+          |
        PID2   |          |   |     +----------+
192.0.2.16/28+-+          |   |         NET3
               |          |   | 15 Gbps
               |          |   |        \
               +----------+   |         -------- L2
                   NET1       |
                            +----------+
                            | +------+ |   PID4
                            | | MEC2 | +--+192.0.2.48/28
                            | +------+ |   2001:db8::4:0/16
                            +----------+
                                NET2
]]></artwork>
        </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 anchor="example-ird" numbered="true" toc="default">
        <name>Information Resource Directory</name>
        <t>To give a comprehensive example of the extension defined in this document, we
consider the network in <xref target="fig-pe" format="default"/>. Assume that the ALTO server provides the
following information resources:</t>
        <ul
        <dl spacing="normal">
          <li>"my-default-networkmap": A Network Map
          <dt>"my-default-networkmap":</dt><dd>A network map resource which that contains the PIDs in the
network.</li>
          <li>"filtered-cost-map-pv": A Multipart Filtered Cost Map
network.</dd>
          <dt>"filtered-cost-map-pv":</dt><dd>A multipart filtered cost map resource for the Path Vector,
which exposes Vector.  Exposes the "max-reservable-bandwidth" property for the PIDs in
"my-default-networkmap".</li>
          <li>"ane-props": A
"my-default-networkmap".</dd>
          <dt>"ane-props":</dt><dd>A filtered Unified Property entity property resource that exposes the
information for persistent ANEs in the network.</li>
          <li>"endpoint-cost-pv": A Multipart network.</dd>
          <dt>"endpoint-cost-pv":</dt><dd>A multipart Endpoint Cost Service for the Path Vector, which
exposes Vector.  Exposes the "max-reservable-bandwidth" and the "persistent-entity-id" properties.</li>
          <li>"update-pv": An Update Stream service, which properties.</dd>
          <dt>"update-pv":</dt><dd>An update stream service that provides the incremental update
service for the "endpoint-cost-pv" service.</li>
          <li>"multicost-pv": A Multipart service.</dd>
          <dt>"multicost-pv":</dt><dd>A multipart Endpoint Cost Service with both the Multi-Cost extension and Path Vector.</li>
        </ul> Vector extension enabled.</dd>
	</dl>
        <t>Below is the Information Resource Directory IRD of the example ALTO server. To
enable the extension defined in this document, the "path-vector" Path Vector cost type
(<xref target="cost-type-spec" format="default"/>) format="default"/>), represented by "path-vector" below,
is defined in the "cost-types" of the "meta" field, field and is
included in the "cost-type-names" of resources "filtered-cost-map-pv" and
"endpoint-cost-pv".</t>
        <artwork
        <sourcecode name="" type="" align="left" alt=""><![CDATA[ type="json"><![CDATA[
{
  "meta": {
    "cost-types": {
      "path-vector": {
        "cost-mode": "array",
        "cost-metric": "ane-path"
      },
      "num-rc": {
        "cost-mode": "numerical",
        "cost-metric": "routingcost"
      }
    }
  },
  "resources": {
    "my-default-networkmap": {
      "uri": "https://alto.example.com/networkmap",
      "media-type": "application/alto-networkmap+json"
    },
    "filtered-cost-map-pv": {
      "uri": "https://alto.example.com/costmap/pv",
      "media-type": "multipart/related;
                     type=application/alto-costmap+json",
      "accepts": "application/alto-costmapfilter+json",
      "capabilities": {
        "cost-type-names": [ "path-vector" ],
        "ane-property-names": [ "max-reservable-bandwidth" ]
      },
      "uses": [ "my-default-networkmap" ]
    },
    "ane-props": {
      "uri": "https://alto.example.com/ane-props",
      "media-type": "application/alto-propmap+json",
      "accepts": "application/alto-propmapparams+json",
      "capabilities": {
        "mappings": {
          ".ane": [ "cpu" ]
        }
      }
    },
    "endpoint-cost-pv": {
      "uri": "https://alto.exmaple.com/endpointcost/pv",
      "media-type": "multipart/related;
                     type=application/alto-endpointcost+json",
      "accepts": "application/alto-endpointcostparams+json",
      "capabilities": {
        "cost-type-names": [ "path-vector" ],
        "ane-property-names": [
          "max-reservable-bandwidth", "persistent-entity-id"
        ]
      },
      "uses": [ "ane-props" ]
    },
    "update-pv": {
      "uri": "https://alto.example.com/updates/pv",
      "media-type": "text/event-stream",
      "uses": [ "endpoint-cost-pv" ],
      "accepts": "application/alto-updatestreamparams+json",
      "capabilities": {
        "support-stream-control": true
      }
    },
    "multicost-pv": {
      "uri": "https://alto.exmaple.com/endpointcost/mcpv",
      "media-type": "multipart/related;
                     type=application/alto-endpointcost+json",
      "accepts": "application/alto-endpointcostparams+json",
      "capabilities": {
        "cost-type-names": [ "path-vector", "num-rc" ],
        "max-cost-types": 2,
        "testable-cost-type-names": [ "num-rc" ],
        "ane-property-names": [
          "max-reservable-bandwidth", "persistent-entity-id"
        ]
      },
      "uses": [ "ane-props" ]
    }
  }
}
]]></artwork>
]]></sourcecode>
      </section>
      <section anchor="multipart-filtered-cost-map" numbered="true" toc="default">
        <name>Multipart Filtered Cost Map</name>
        <t>The following examples demonstrate the request to the "filtered-cost-map-pv"
resource and the corresponding response.</t>
        <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
for
the Path Vector but and not the ANE properties.</t>
        <t>The response consists of two parts. The parts:</t>
        <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
the
interconnection link L1, L1 and "L2" represents the interconnection link L2.</t>
        <t>The L2.</li>
        <li>The second part returns an empty Property Map. Note the property map. &nbsp;Note that the properties of the ANE entries are
omitted since they have no properties (See Section 3.1 of equal to the literal string "{}"
(see <xref target="I-D.ietf-alto-unified-props-new" format="default"/>).</t>
        <artwork target="RFC9240" sectionFormat="of" section="8.3"/>).</li>
	</ul>
        <sourcecode name="" type="" align="left" alt=""><![CDATA[ type="http-message"><![CDATA[
POST /costmap/pv HTTP/1.1
Host: alto.example.com
Accept: multipart/related;type=application/alto-costmap+json,
        application/alto-error+json
Content-Length: 153 163
Content-Type: application/alto-costmapfilter+json

{
  "cost-type": {
    "cost-mode": "array",
    "cost-metric": "ane-path"
  },
  "pids": {
    "srcs": [ "PID1" ],
    "dsts": [ "PID3", "PID4" ]
  }
}
]]></artwork>
        <artwork
]]></sourcecode>
        <sourcecode name="" type="" align="left" alt=""><![CDATA[ type="http-message"><![CDATA[
HTTP/1.1 200 OK
Content-Length: 855 952
Content-Type: multipart/related; boundary=example-1;
              type=application/alto-costmap+json

--example-1
Content-ID: <costmap@alto.example.com>
Content-Type: application/alto-costmap+json

{
  "meta": {
    "vtag": {
      "resource-id": "filtered-cost-map-pv.costmap",
      "tag": "d827f484cb66ce6df6b5077cb8562b0a"
    },
    "dependent-vtags": [
      {
        "resource-id": "my-default-networkmap",
        "tag": "c04bc5da49534274a6daeee8ea1dec62"
      }
    ],
    "cost-type": {
      "cost-mode": "array",
      "cost-metric": "ane-path"
    }
  },
  "cost-map": {
    "PID1": {
      "PID3": [ "L1" ],
      "PID4": [ "L1", "L2" ]
    }
  }
}
--example-1
Content-ID: <propmap@alto.example.com>
Content-Type: application/alto-propmap+json

{
  "meta": {
    "dependent-vtags": [
      {
        "resource-id": "filtered-cost-map-pv.costmap",
        "tag": "d827f484cb66ce6df6b5077cb8562b0a"
      }
    ]
  },
  "property-map": {
    ".ane:L1": {},
    ".ane:L2": {}
  }
}
]]></artwork>
--example-1
]]></sourcecode>
      </section>
      <section anchor="example-ecspv" numbered="true" toc="default">
        <name>Multipart Endpoint Cost Service Resource</name>
        <t>The following examples demonstrate the request to the "endpoint-cost-pv"
resource and the corresponding response.</t>
        <t>The request uses the Path Vector "path-vector" cost type in the "cost-type" field, field and
queries the Maximum Reservable Bandwidth maximum reservable bandwidth ANE property and the Persistent Entity persistent entity ID
property for two IPv4 source and destination pairs (192.0.2.34 -&gt; 192.0.2.2 and
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>
        <t>The response consists of two parts. The parts:</t>
        <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
192.0.2.34 -&gt; 192.0.2.2 traverses NET2, L1 NET3, L1, and NET1, NET1; and flows 192.0.2.34 -&gt;
192.0.2.50 and 2001:db8::3:1 -&gt; 2001:db8::4:1 traverse NET2, L2 L2, and NET3.</t>
        <t>The NET3.</li>
        <li>The second part returns the requested properties of ANEs. Assume that NET1, NET2 NET2, and NET3 has have
sufficient bandwidth and their "max-reservable-bandwidth" values are set to a sufficiently
large number (50 Gbps in this case). On the other hand, assume that there are no
prior reservation reservations on L1 and L2, L2 and their "max-reservable-bandwidth" values are
the corresponding link capacity (10 Gbps for L1 and 15 Gbps for L2).</t> L2).</li>
	</ul>
        <t>Both NET1 and NET2 have a mobile edge deployed, i.e., MEC1 in NET1 and MEC2 in
NET2. Assume that the ANEName values for MEC1 and MEC2 are "MEC1" and "MEC2" and their
properties can be retrieved from the Property Map property map "ane-props". Thus, the
"persistent-entity-id" property of values for NET1 and NET3 NET2 are "ane-props.ane:MEC1" and
"ane-props.ane:MEC2"
"ane-props.ane:MEC2", respectively.</t>
        <artwork
        <sourcecode name="" type="" align="left" alt=""><![CDATA[ type="http-message"><![CDATA[
POST /endpointcost/pv HTTP/1.1
Host: alto.example.com
Accept: multipart/related;
        type=application/alto-endpointcost+json,
        application/alto-error+json
Content-Length: 362 383
Content-Type: application/alto-endpointcostparams+json

{
  "cost-type": {
    "cost-mode": "array",
    "cost-metric": "ane-path"
  },
  "endpoints": {
    "srcs": [
      "ipv4:192.0.2.34",
      "ipv6:2001:db8::3:1"
    ],
    "dsts": [
      "ipv4:192.0.2.2",
      "ipv4:192.0.2.50",
      "ipv6:2001:db8::4:1"
    ]
  },
  "ane-property-names": [
    "max-reservable-bandwidth",
    "persistent-entity-id"
  ]
}
]]></artwork>
        <artwork
]]></sourcecode>
        <sourcecode name="" type="" align="left" alt=""><![CDATA[ type="http-message"><![CDATA[
HTTP/1.1 200 OK
Content-Length: 1432 1508
Content-Type: multipart/related; boundary=example-2;
              type=application/alto-endpointcost+json

--example-2
Content-ID: <ecs@alto.example.com>
Content-Type: application/alto-endpointcost+json

{
  "meta": {
    "vtags": {
      "resource-id": "endpoint-cost-pv.ecs",
      "tag": "bb6bb72eafe8f9bdc4f335c7ed3b10822a391cef"
    },
    "cost-type": {
      "cost-mode": "array",
      "cost-metric": "ane-path"
    }
  },
  "endpoint-cost-map": {
    "ipv4:192.0.2.34": {
      "ipv4:192.0.2.2":   [ "NET3", "L1", "NET1" ],
      "ipv4:192.0.2.50":   [ "NET3", "L2", "NET2" ]
    },
    "ipv6:2001:db8::3:1": {
      "ipv6:2001:db8::4:1": [ "NET3", "L2", "NET2" ]
    }
  }
}
--example-2
Content-ID: <propmap@alto.example.com>
Content-Type: application/alto-propmap+json

{
  "meta": {
    "dependent-vtags": [
      {
        "resource-id": "endpoint-cost-pv.ecs",
        "tag": "bb6bb72eafe8f9bdc4f335c7ed3b10822a391cef"
      },
      {
        "resource-id": "ane-props",
        "tag": "bf3c8c1819d2421c9a95a9d02af557a3"
      }
    ]
  },
  "property-map": {
    ".ane:NET1": {
      "max-reservable-bandwidth": 50000000000,
      "persistent-entity-id": "ane-props.ane:MEC1"
    },
    ".ane:NET2": {
      "max-reservable-bandwidth": 50000000000,
      "persistent-entity-id": "ane-props.ane:MEC2"
    },
    ".ane:NET3": {
      "max-reservable-bandwidth": 50000000000
    },
    ".ane:L1": {
      "max-reservable-bandwidth": 10000000000
    },
    ".ane:L2": {
      "max-reservable-bandwidth": 15000000000
    }
  }
}
]]></artwork>
        <t>Under
--example-2
]]></sourcecode>
        <t>In certain scenarios where the traversal order is not crucial, an ALTO server
implementation may choose to not follow to strictly follow the physical traversal order
and may even obfuscate the order intentionally to preserve its own privacy or
conform to its own policies.
For example, an ALTO server may choose to aggregate NET1 and L1 as a new ANE
with ANE name "AGGR1", "AGGR1" and aggregate NET2 and L2 as a new ANE with ANE name
"AGGR2". The "max-reservable-bandwidth" property of "AGGR1" takes the value of L1, which
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 and way;
the obfuscated response is as shown below. Note that the obfuscation of Path
Vector responses is implementation-specific implementation specific and is out of the scope of for this
document, and developers
document. Developers may refer to <xref target="Security" format="default"/> for further references.</t>
        <artwork
        <sourcecode name="" type="" align="left" alt=""><![CDATA[ type="http-message"><![CDATA[
HTTP/1.1 200 OK
Content-Length: 1263 1333
Content-Type: multipart/related; boundary=example-2;
              type=application/alto-endpointcost+json

--example-2
Content-ID: <ecs@alto.example.com>
Content-Type: application/alto-endpointcost+json

{
  "meta": {
    "vtags": {
      "resource-id": "endpoint-cost-pv.ecs",
      "tag": "bb975862fbe3422abf4dae386b132c1d"
    },
    "cost-type": {
      "cost-mode": "array",
      "cost-metric": "ane-path"
    }
  },
  "endpoint-cost-map": {
    "ipv4:192.0.2.34": {
      "ipv4:192.0.2.2":   [ "NET3", "AGGR1" ],
      "ipv4:192.0.2.50":   [ "NET3", "AGGR2" ]
    },
    "ipv6:2001:db8::3:1": {
      "ipv6:2001:db8::4:1": [ "NET3", "AGGR2" ]
    }
  }
}
--example-2
Content-ID: <propmap@alto.example.com>
Content-Type: application/alto-propmap+json

{
  "meta": {
    "dependent-vtags": [
      {
        "resource-id": "endpoint-cost-pv.ecs",
        "tag": "bb975862fbe3422abf4dae386b132c1d"
      },
      {
        "resource-id": "ane-props",
        "tag": "bf3c8c1819d2421c9a95a9d02af557a3"
      }
    ]
  },
  "property-map": {
    ".ane:AGGR1": {
      "max-reservable-bandwidth": 10000000000,
      "persistent-entity-id": "ane-props.ane:MEC1"
    },
    ".ane:AGGR2": {
      "max-reservable-bandwidth": 15000000000,
      "persistent-entity-id": "ane-props.ane:MEC2"
    },
    ".ane:NET3": {
      "max-reservable-bandwidth": 50000000000
    }
  }
}
]]></artwork>
--example-2
]]></sourcecode>
      </section>
      <section anchor="example-sse" numbered="true" toc="default">
        <name>Incremental Updates</name>
        <t>In this example, an ALTO client subscribes to the incremental update for the
multipart Endpoint Cost Service resource "endpoint-cost-pv".</t>
        <artwork
        <sourcecode name="" type="" align="left" alt=""><![CDATA[ type="http-message"><![CDATA[
POST /updates/pv HTTP/1.1
Host: alto.example.com
Accept: text/event-stream
Content-Type: application/alto-updatestreamparams+json
Content-Length: 112 120

{
  "add": {
    "ecspvsub1": {
      "resource-id": "endpoint-cost-pv",
      "input": <ecs-input>
    }
  }
}
]]></artwork>
]]></sourcecode>
        <t>Based on the server-side process defined in <xref target="RFC8895" format="default"/>, the ALTO server will
send the "control-uri" first first, using a Server-Sent Event (SSE), (SSE) followed by the full
response of the multipart message.</t>
        <artwork
        <sourcecode name="" type="" align="left" alt=""><![CDATA[ type="http-message"><![CDATA[
HTTP/1.1 200 OK
Connection: keep-alive
Content-Type: text/event-stream

event: application/alto-updatestreamcontrol+json
data: {"control-uri": "https://alto.example.com/updates/streams/123"}

event: multipart/related;boundary=example-3;
       type=application/alto-endpointcost+json,ecspvsub1
data: --example-3
data: Content-ID: <ecsmap@alto.example.com>
data: Content-Type: application/alto-endpointcost+json
data:
data: <endpoint-cost-map-entry>
data: --example-3
data: Content-ID: <propmap@alto.example.com>
data: Content-Type: application/alto-propmap+json
data:
data: <property-map-entry>
data: --example-3--
]]></artwork>
]]></sourcecode>

        <t>When the contents change, the ALTO server will publish the updates for each node
in this tree separately, based on Section 6.7.3 of <xref target="RFC8895" format="default"/>.</t>
        <artwork sectionFormat="of" section="6.7.3"/>.</t>
        <sourcecode name="" type="" align="left" alt=""><![CDATA[ type="http-message"><![CDATA[
event: application/merge-patch+json,
   ecspvsub1.ecsmap@alto.example.com
data: <Merge patch for endpoint-cost-map-update>

event: application/merge-patch+json,
   ecspvsub1.propmap@alto.example.com
data: <Merge patch for property-map-update>
]]></artwork>
        <!-- TODO: the remaining issue is where to specify the json-merge-patch capability for each node -->
]]></sourcecode>
</section>
      <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
and the corresponding response.</t>
        <t>The request asks for two cost types: the first is the Path Vector cost type, and
the second is a numerical routing cost. It also queries the Maximum Reservable
Bandwidth maximum reservable
bandwidth ANE property and the Persistent Entity persistent entity ID property for two IPv4 source and
destination pairs (192.0.2.34 -&gt; 192.0.2.2 and 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>
        <t>The response consists of two parts. The parts:</t>
        <ul spacing="normal">
        <li>The first part returns a JSONArray that
contains two JSONValue entries for each requested source and destination pair: the first
JSONValue is a JSONArray of ANENames, which is the value of the Path Vector cost
type,
type; and the second JSONValue is a JSONNumber JSONNumber, which is the value of the routing
cost. The
cost.</li>
        <li>The second part contains a Property Map property map that maps the ANEs to their
requested properties.</t>
        <artwork properties.</li>
	</ul>
        <sourcecode name="" type="" align="left" alt=""><![CDATA[ type="http-message"><![CDATA[
POST /endpointcost/mcpv HTTP/1.1
Host: alto.example.com
Accept: multipart/related;
        type=application/alto-endpointcost+json,
        application/alto-error+json
Content-Length: 433 454
Content-Type: application/alto-endpointcostparams+json

{
  "multi-cost-types": [
    { "cost-mode": "array", "cost-metric": "ane-path" },
    { "cost-mode": "numerical", "cost-metric": "routingcost" }
  ],
  "endpoints": {
    "srcs": [
      "ipv4:192.0.2.34",
      "ipv6:2001:db8::3:1"
    ],
    "dsts": [
      "ipv4:192.0.2.2",
      "ipv4:192.0.2.50",
      "ipv6:2001:db8::4:1"
    ]
  },
  "ane-property-names": [
    "max-reservable-bandwidth",
    "persistent-entity-id"
  ]
}
]]></artwork>
        <artwork
]]></sourcecode>
        <sourcecode name="" type="" align="left" alt=""><![CDATA[ type="http-message"><![CDATA[
HTTP/1.1 200 OK
Content-Length: 1350 1419
Content-Type: multipart/related; boundary=example-4;
              type=application/alto-endpointcost+json

--example-4
Content-ID: <ecs@alto.example.com>
Content-Type: application/alto-endpointcost+json

{
  "meta": {
    "vtags": {
      "resource-id": "endpoint-cost-pv.ecs",
      "tag": "84a4f9c14f9341f0983e3e5f43a371c8"
    },
    "multi-cost-types": [
      { "cost-mode": "array", "cost-metric": "ane-path" },
      { "cost-mode": "numerical", "cost-metric": "routingcost" }
    ]
  },
  "endpoint-cost-map": {
    "ipv4:192.0.2.34": {
      "ipv4:192.0.2.2":   [[ "NET3", "AGGR1" ], 3],
      "ipv4:192.0.2.50":   [[ "NET3", "AGGR2" ], 2]
    },
    "ipv6:2001:db8::3:1": {
      "ipv6:2001:db8::4:1": [[ "NET3", "AGGR2" ], 2]
    }
  }
}
--example-4
Content-ID: <propmap@alto.example.com>
Content-Type: application/alto-propmap+json

{
  "meta": {
    "dependent-vtags": [
      {
        "resource-id": "endpoint-cost-pv.ecs",
        "tag": "84a4f9c14f9341f0983e3e5f43a371c8"
      },
      {
        "resource-id": "ane-props",
        "tag": "be157afa031443a187b60bb80a86b233"
      }
    ]
  },
  "property-map": {
    ".ane:AGGR1": {
      "max-reservable-bandwidth": 10000000000,
      "persistent-entity-id": "ane-props.ane:MEC1"
    },
    ".ane:AGGR2": {
      "max-reservable-bandwidth": 15000000000,
      "persistent-entity-id": "ane-props.ane:MEC2"
    },
    ".ane:NET3": {
      "max-reservable-bandwidth": 50000000000
    }
  }
}
]]></artwork>
--example-4
]]></sourcecode>
      </section>
    </section>
    <section anchor="Compatibility" numbered="true" toc="default">
      <name>Compatibility with Other ALTO Extensions</name>
      <section anchor="compatibility-with-legacy-alto-clientsservers" numbered="true" toc="default">
        <name>Compatibility with Legacy ALTO Clients/Servers</name>
        <t>The multipart Filtered Cost Map filtered cost map resource and the multipart Endpoint Cost
Service resource has have no backward compatibility issue backward-compatibility issues with legacy ALTO clients and
servers. Although these two types of resources reuse the media types defined in
the base ALTO protocol Protocol for the accept "Accept" input parameters, they have different
media types for responses. If the ALTO server provides these two types of
resources,
resources but the ALTO client does not support them, the ALTO client will
ignore the resources without incurring any incompatibility problem.</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.
--> problems.</t>
</section>
      <section anchor="compatibility-with-multi-cost-extension" numbered="true" toc="default">
        <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
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;
type=application/alto-endpointcost+json". Its "cost-constraints" field must
either be
either "false" or not present present, and the Path Vector cost type must be present
in the "cost-type-names" capability field but must not be present in the
"testable-cost-type-names" field, as specified in <xref Sections&nbsp;<xref target="pvcm-cap" format="default"/> format="counter"/> and <xref target="pvecs-cap" format="default"/>.</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.
--> format="counter"/>.</t>
</section>
      <section anchor="compatibility-with-incremental-update" numbered="true" toc="default">
        <name>Compatibility with Incremental Update</name>
        <!-- FIXME: using resource-id header in MIME part --> Update Extension</name>
<t>This extension is compatible with the incremental update extension <xref target="RFC8895" format="default"/>.
ALTO clients and servers MUST <bcp14>MUST</bcp14> follow the specifications given in Sections 5.2 Sections&nbsp;<xref target="RFC8895" section=
"5.2" sectionFormat="bare"/> and 6.7.3 of <xref target="RFC8895" format="default"/> section="6.7.3" sectionFormat="bare"/> of <xref target="RFC8895"/> to support incremental updates for a Path Vector
resource.</t>
      </section>
      <section anchor="compatibility-with-cost-calendar" numbered="true" toc="default">
        <name>Compatibility with Cost Calendar</name> Calendar Extension</name>
        <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
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
time interval by traffic from the source to the destination.</t>
        <t>When used with time-varying properties, e.g., maximum reservable bandwidth, a
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
time intervals, it MUST <bcp14>MUST</bcp14> be treated as two different ANEs, i.e., with different
entity identifiers. However, if it has the same property values in two time
intervals, it MAY <bcp14>MAY</bcp14> use the same identifier.</t>
        <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
calendared in a compatible way, and the Property Map property map part is not affected by the
calendar
Cost Calendar extension.</t>
        <t>The two extensions combined together can provide the historical 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
such as Time-Block-Maximum Bandwidth, Bandwidth-Sliding-Window, and
Time-Bandwidth-Product (TBP) (See (see <xref target="SENSE" format="default"/> for details).</t>
      </section>
    </section>
    <section anchor="SecDisc" numbered="true" toc="default">
      <name>General Discussions</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.
--> Discussion</name>
<section anchor="constraint-tests-for-general-cost-types" numbered="true" toc="default">
        <name>Constraint Tests for General Cost Types</name>
        <t>The constraint test is a simple approach to query for querying the data. It allows users to
filter the query result results by specifying some boolean tests. This approach is
already used in the ALTO protocol. Protocol. ALTO clients are permitted to specify either the "constraints" test <xref target="RFC7285" format="default"/> and <xref target="RFC8189" format="default"/> allow ALTO
clients to specify or the "constraints" and "or-constraints" tests test <xref target="RFC8189"
format="default"/> to better
filter the result.</t> results.</t>
        <t>However, the current syntax can only be used to test scalar cost types, types and
cannot easily express constraints on complex cost types, e.g., the Path Vector
cost type defined in this document.</t>
        <t>In practice, developing a bespoke language for general-purpose boolean tests can
be a complex undertaking, and it is conceivable that there are some existing such implementations already exist
(the authors have not done an exhaustive search to
determine whether there are such implementations). implementations exist). One avenue to develop for developing such a
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>
        <t>Filtering the Path Vector results or developing a more sophisticated filtering
mechanism is beyond the scope of this document.</t>
      </section>
      <section anchor="general-multi-resource-query" numbered="true" toc="default">
        <name>General Multi-Resource Query</name>
        <t>Querying multiple ALTO information resources continuously is a general
requirement. Enabling such a capability, however, must address general
issues like efficiency and consistency. The incremental update extension
<xref target="RFC8895" format="default"/> supports submitting multiple queries in a single request, request and allows
flexible control over the queries. However, it does not cover the case
introduced in this document where multiple resources are needed for a single
request.</t>
        <t>This
        <t>The extension specified in this document gives an example of using a multipart message to encode the
responses from two specific ALTO information resources: a Filtered Cost Map filtered cost map or
an Endpoint Cost Service, and a Property Map. By property map. &nbsp;By packing multiple resources in a
single response, the implication is that servers may proactively push related
information resources to clients.</t>
        <t>Thus, it is worth looking into the direction of extending the SSE mechanism as
used in the incremental update extension <xref target="RFC8895" format="default"/>, format="default"/>; or upgrading to HTTP/2
<xref target="I-D.ietf-httpbis-http2bis" target="RFC9113" format="default"/> and HTTP/3 <xref target="I-D.ietf-quic-http" target="RFC9114" format="default"/>, which
provides the ability to multiplex queries and to allow servers to proactively send
related information resources.</t>
        <t>Defining a general multi-resource query mechanism is out of the scope of for this
document.</t>
      </section>
    </section>
    <section anchor="Security" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>This document is an extension of the base ALTO protocol, Protocol, so the Security
Considerations <xref target="RFC7285" format="default"/> of security
considerations provided for the base ALTO protocol Protocol <xref target="RFC7285" format="default"/> fully apply when this
extension is provided by an ALTO server.</t>
      <!-- Additional security considerations -->

<!-- ## Privacy Concerns { #pricon } -->
<t>The Path Vector extension requires additional scrutiny on of three security
considerations discussed in the base protocol: confidentiality of ALTO
information (Section 15.3 of <xref (<xref target="RFC7285" format="default"/>), sectionFormat="of" section="15.3"/>), potential undesirable guidance from
authenticated ALTO information (Section 15.2 of <xref (<xref target="RFC7285" format="default"/>), sectionFormat="of" section="15.2"/>), and availability
of ALTO service (Section 15.5 of <xref services (<xref target="RFC7285" format="default"/>).</t> sectionFormat="of" section="15.5"/>).</t>
      <t>For confidentiality of ALTO information, a network operator should be aware that
this extension may introduce a new risk: the Path Vector information, when used
together with sensitive ANE properties such as capacities of bottleneck links,
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
attacker may identify the bottleneck link or links and start a distributed
denial-of-service (DDoS) attack involving minimal flows to conduct the flows, triggering
in-network congestion. Given the potential risk of leaking sensitive
information, the Path Vector extension is mainly applicable in scenarios where
1) the ANE structures and ANE properties do not impose security risks to on the
ALTO service provider, e.g., provider (e.g., they do not carrying carry sensitive information, information) or 2) the ALTO
server and client have established a reliable trust relationship, for example,
operated relationship (e.g.,
they operate in the same administrative domain, domain or are managed by business partners with
legal contracts.</t> contracts).</t>
      <t>Three risk types are identified in Section 15.3.1 of <xref target="RFC7285" format="default"/>: (1) Excess sectionFormat="of" section="15.3.1"/>:</t>

  <ol spacing="normal" type="(%d)">
  <li>excess disclosure of the ALTO service provider's data to an unauthorized ALTO client;
(2) Disclosure client,</li>
  <li>disclosure of the ALTO service provider's data (e.g., network topology
information or endpoint addresses) to an unauthorized third party; and (3)
Excess party, and</li>
  <li>excess retrieval of the ALTO service provider's data by collaborating ALTO
clients. To
clients.</li>
  </ol>
<t>To mitigate these risks, an ALTO server MUST <bcp14>MUST</bcp14> follow the guidelines in
Section 15.3.2 of <xref target="RFC7285" format="default"/>. sectionFormat="of" section="15.3.2"/>. Furthermore, an ALTO server MUST <bcp14>MUST</bcp14> follow the
following additional protections strategies for risk types (1) and (3).</t>
      <t>For risk type (1), an ALTO server MUST <bcp14>MUST</bcp14> use the authentication methods specified
in Section 15.3.2 of <xref target="RFC7285" format="default"/> sectionFormat="of" section="15.3.2"/> to authenticate the identify identity of an ALTO client, client
and apply access control techniques to restrict unprivileged ALTO clients from
retrieving the retrieval of sensitive Path Vector information. information by unprivileged ALTO clients. For settings where the ALTO server
and client are not in the same trust domain, the ALTO server should reach
agreements with the ALTO client on protecting the regarding protection of confidentiality before
granting the access to Path Vector service services with sensitive information. Such
agreements may include legal contracts or Digital Right Rights Management (DRM)
techniques. Otherwise, the ALTO server MUST NOT <bcp14>MUST NOT</bcp14> offer the Path Vector service
carrying services that
carry sensitive information to the clients clients, unless the potential risks are
fully assessed and mitigated.</t>
      <t>For risk type (3), an ALTO service provider must be aware that persistent ANEs
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) CDN Interconnections)
and/or when the granularity is coarse-grained coarse grained (e.g., when an ANE represents an
AS, a data center center, or a WAN).
Otherwise, an ALTO server MUST <bcp14>MUST</bcp14> use dynamic mappings from ephemeral ANE names to
underlying physical entities. Specifically, for the same physical entity, an
ALTO server SHOULD <bcp14>SHOULD</bcp14> assign a different ephemeral ANE name when the entity appears
in the responses to different clients or even for different request requests from the
same client. A RECOMMENDED <bcp14>RECOMMENDED</bcp14> assignment strategy is to generate ANE names from
random numbers.</t>
      <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 <bcp14>SHOULD</bcp14>
consider protection mechanisms to reduce information exposure or obfuscate the
real information. When doing so, the ALTO server must be aware that information
reduction/obfuscation may lead to a potential Undesirable Guidance from
Authenticated ALTO Information risk (Section 15.2 of <xref undesirable guidance from
authenticated ALTO information (<xref target="RFC7285" format="default"/>).</t> sectionFormat="of" section="15.2"/>).</t>
      <t>Thus, implementations of ALTO servers involving reduction or obfuscation of the
Path Vector information SHOULD <bcp14>SHOULD</bcp14> consider reduction/obfuscation mechanisms that
can preserve the integrity of ALTO information, information -- for example, by using minimal
feasible region compression algorithms <xref target="NOVA" format="default"/> or obfuscation protocols
<xref target="RESA" format="default"/><xref format="default"/> <xref target="MERCATOR" format="default"/>. However, these obfuscation methods are experimental experimental, and their
practical applicability of these methods to the generic capability
provided by this extension is has not been fully assessed. The ALTO server MUST <bcp14>MUST</bcp14> carefully
verify that the deployment scenario satisfies the security assumptions of these
methods before applying them to protect Path Vector services with sensitive
network information.</t>
      <t>For availability of ALTO service, services, an ALTO server should be cognizant that using a
Path Vector extension might have introduce a new risk: frequent requesting requests for Path
Vectors might consume intolerable amounts of the server-side computation and
storage, which
storage.  This behavior can break the ALTO server. For example, if an ALTO server
implementation dynamically computes the Path Vectors for each request, the
service providing that provides the Path Vectors may become an entry point for denial-of-service
attacks on the availability of an ALTO server.</t>
      <t>To mitigate this risk, an ALTO server may consider using optimizations such optimizations as
precomputation-and-projection mechanisms <xref target="MERCATOR" format="default"/> to reduce the overhead for
processing each query. Also, an An ALTO server may also protect itself from
malicious clients by monitoring the behaviors of clients client behavior and stopping serving service to
clients with that exhibit suspicious behaviors behavior (e.g., sending requests at a high frequency).</t>
      <t>The ALTO service providers must be aware that providing incremental updates of
the
"max-reservable-bandwidth" may provide information about other consumers of
the network. For example, a change of the in value may indicate that one or more
reservations has 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>
    </section>
    <section anchor="IANA" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <section anchor="alto-cost-metric-registry" anchor="alto-cost-metrics-registry" numbered="true" toc="default">
        <name>ALTO
        <name>&quot;ALTO Cost Metric Metrics&quot; Registry</name>
        <t>This document registers a new entry to in the ALTO "ALTO Cost Metric Registry, as
instructed by Section 14.2 of Metrics" registry, per
<xref target="RFC7285" format="default"/>. sectionFormat="of" section="14.2"/>. The new entry
is as shown below in <xref target="tbl-cost-metric" format="default"/>.</t>
        <table anchor="tbl-cost-metric" align="center">
          <name>ALTO
          <name>&quot;ALTO Cost Metric Metrics&quot; Registry</name>
          <thead>
            <tr>
              <th align="left">Identifier</th>
              <th align="left">Intended Semantics</th>
              <th align="left">Security Considerations</th> align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">ane-path</td>
              <td align="left">See <xref target="metric-spec" format="default"/></td>
              <td align="left">See <xref target="Security" format="default"/></td> align="left">RFC 9275</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="alto-cost-mode-registry" anchor="alto-cost-modes-registry" numbered="true" toc="default">
        <name>ALTO
        <name>&quot;ALTO Cost Mode Modes&quot; Registry</name>
        <t>This document registers a new entry to in the ALTO "ALTO Cost Mode Registry, as
instructed by Section 4 of Modes" registry, per
<xref target="I-D.bw-alto-cost-mode" format="default"/>. target="RFC9274" sectionFormat="of" section="5"/>. The new entry
is as shown below in <xref target="tbl-cost-mode" format="default"/>.</t>
        <table anchor="tbl-cost-mode" align="center">
          <name>ALTO
          <name>&quot;ALTO Cost Mode Modes&quot; Registry</name>
          <thead>
            <tr>
              <th align="left">Identifier</th>
              <th align="left">Description</th>
              <th align="left">Intended Semantics</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <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">RFC 9275</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="alto-entity-domain-type-registry" anchor="alto-entity-domain-types-registry" numbered="true" toc="default">
        <name>ALTO
        <name>&quot;ALTO Entity Domain Type Types&quot; Registry</name>
        <t>This document registers a new entry to in the ALTO Domain "ALTO Entity Type Registry, as
instructed by Section 12.2 of Domain Types" registry, per
<xref target="I-D.ietf-alto-unified-props-new" format="default"/>. target="RFC9240" sectionFormat="of" section="12.3"/>. The new entry
is as shown below in <xref target="tbl-entity-domain" format="default"/>.</t>
        <table anchor="tbl-entity-domain" align="center">
          <name>ALTO
          <name>&quot;ALTO Entity Domain Type Types&quot; Registry</name>
          <thead>
            <tr>
              <th align="left">Identifier</th>
              <th align="left">Entity Identifier Encoding</th>
              <th align="left">Hierarchy &amp; and Inheritance</th>
              <th align="left">Media Type of Defining Resoucrce</th> Resource</th>
              <th align="left">Mapping to ALTO Address Type</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">ane</td>
              <td align="left">See <xref target="entity-address" format="default"/></td>
              <td align="left">None</td>
              <td align="left">application/alto-propmap+json</td>
              <td align="left">false</td>
            </tr>
          </tbody>
        </table>
        <dl>
          <dt>
Identifier:  </dt>
          <dd>
            <t>See <xref target="domain-type" format="default"/>.</t>
          </dd>
          <dt>
Entity Identifier Encoding:  </dt>
          <dd>
            <t>See <xref target="entity-address" format="default"/>.</t>
          </dd>
          <dt>
Hierarchy:  </dt>
          <dd>
            <t>None</t>
          </dd>
          <dt>
Inheritance:  </dt>
          <dd>
            <t>None</t>
          </dd>
          <dt>
Media Type of Defining Resource:  </dt>
          <dd>
            <t>See <xref target="domain-defining" format="default"/>.</t>
          </dd>
          <dt>
Mapping to ALTO Address Type:  </dt>
          <dd>
            <t>This entity type does not map to an ALTO address type.</t>
          </dd>
          <dt>
Security Considerations:  </dt>
          <dd>
            <t>In some usage scenarios, ANE addresses carried in ALTO Protocol messages may
reveal information about an ALTO client or an ALTO service provider.
Applications and ALTO service providers using addresses of ANEs will be made
aware of
If a naming schema is used to generate ANE names, either
used privately or standardized by a future extension, how
(or if) the addressing scheme naming schema relates to private information
and network proximity, in further iterations of this document.</t> proximity must be explained to ALTO implementers
and service providers.</t>
          </dd>
        </dl>
      </section>
      <section anchor="alto-entity-property-type-registry" anchor="alto-entity-property-types-registry" numbered="true" toc="default">
        <name>ALTO
        <name>&quot;ALTO Entity Property Type Types&quot; Registry</name>
        <t>Two initial entries -- "max-reservable-bandwidth" and "persistent-entity-id" -- are
registered to for the ALTO Domain domain "ane" in the "ALTO Entity Property Type Registry",
as instructed by Section 12.3 of Types" registry,
per <xref target="I-D.ietf-alto-unified-props-new" format="default"/>. target="RFC9240" sectionFormat="of" section="12.4"/>. The two
new entries are shown below in <xref target="tbl-prop-type-reg" format="default"/> format="default"/>, and their details can be
found in <xref Sections&nbsp;<xref target="mrb-iana" format="default"/> format="counter"/> and <xref target="pei-iana" format="default"/>.</t> format="counter"/> of this document.</t>
        <table anchor="tbl-prop-type-reg" align="center">
          <name>Initial Entries for ane the &quot;ane&quot; Domain in the ALTO &quot;ALTO Entity Property Types Types&quot; Registry</name>
          <thead>
            <tr>
              <th align="left">Identifier</th>
              <th align="left">Intended Semantics</th>
              <th align="left">Media Type of Defining Resource</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">max-reservable-bandwidth</td>
              <td align="left">See <xref target="maxresbw" format="default"/></td>
              <td align="left">application/alto-propmap+json</td>
            </tr>
            <tr>
              <td align="left">persistent-entity-id</td>
              <td align="left">See <xref target="persistent-entity-id" format="default"/></td>
              <td align="left">application/alto-propmap+json</td>
            </tr>
          </tbody>
        </table>
        <section anchor="mrb-iana" numbered="true" toc="default">
          <name>New ANE Property Type: Maximum Reservable Bandwidth</name>
          <dl>
            <dt>
Identifier:  </dt>
            <dd>
              <t>"max-reservable-bandwidth"</t>
            </dd>
            <dt>
Intended Semantics:  </dt>
            <dd>
              <t>See <xref target="maxresbw" format="default"/>.</t>
            </dd>
            <dt>
Media Type of Defining Resource:  </dt>
            <dd>
              <t>application/alto-propmap+json</t>
            </dd>
            <dt>
Security Considerations:  </dt>
            <dd>
              <t>This
              <t>To make better choices regarding bandwidth reservation, this property is essential for applications such as large-scale data
transfers or an overlay network interconnection to make better choice of
bandwidth reservation. interconnection. It may reveal the bandwidth usage of the underlying
network and can potentially be leveraged to reduce the cost of conducting
denial-of-service attacks. Thus, the ALTO server MUST <bcp14>MUST</bcp14> consider such protection
mechanisms including only as providing the information to authorized clients, clients only and applying
information reduction and obfuscation as introduced discussed in <xref target="Security" format="default"/>.</t>
            </dd>
          </dl>
        </section>
        <section anchor="pei-iana" numbered="true" toc="default">
          <name>New ANE Property Type: Persistent Entity ID</name>
          <dl>
            <dt>
Identifier:  </dt>
            <dd>
              <t>"persistent-entity-id"</t>
            </dd>
            <dt>
Intended Semantics:  </dt>
            <dd>
              <t>See <xref target="persistent-entity-id" format="default"/>.</t>
            </dd>
            <dt>
Media Type of Defining Resource:  </dt>
            <dd>
              <t>application/alto-propmap+json</t>
            </dd>
            <dt>
Security Considerations:  </dt>
            <dd>
              <t>This property is useful when an ALTO server wants to selectively expose
certain service points whose detailed properties can be further queried by
applications. The As mentioned in <xref target="RFC9240" sectionFormat="of"
section="12.3.2"/>, the entity IDs may consider reveal sensitive information about the
underlying network, and an network. An ALTO server should follow the security
considerations provided in Section 11 of <xref target="I-D.ietf-alto-unified-props-new" format="default"/>.</t> target="RFC9240" sectionFormat="of" section="11"/>.</t>
            </dd>
          </dl>
        </section>
      </section>
    </section>
  </middle>
  <back>

    <references>
      <name>References</name>
      <references>
        <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</title>
            <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 signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  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="Alimi">
              <organization/>
            </author>
            <author fullname="R. Penno" initials="R." role="editor" surname="Penno">
              <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 topology information of Internet Service Provider (ISP) networks.  For example, views 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 way to distribute it.</t>
              <t>The Application-Layer Traffic Optimization (ALTO) services defined in this document provide network information (e.g., basic network location structure and preferences of network paths) with the goal of modifying network resource consumption patterns while maintaining or improving application performance.  The basic information of ALTO is based on abstract maps of a network.  These maps provide a simplified view, yet enough information about a network for applications to effectively utilize them.  Additional services are built on top of the maps.</t>
              <t>This document describes a protocol implementing the ALTO services. Although the ALTO services would primarily be provided by ISPs, other entities, such as content service providers, could also provide ALTO services.  Applications that could use the ALTO services are those that have a choice to which end points to connect.  Examples of such applications are peer-to-peer (P2P) and content 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 provides 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="Resnick">
              <organization/>
            </author>
            <date month="October" year="2008"/>
            <abstract>
              <t>This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages.  This specification is a revision of Request For 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 other 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</title>
            <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 protocol  specifications.  This document aims to reduce the ambiguity by clarifying that 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)</title>
            <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, specified in RFC 7285, defines several services that return various metrics describing 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 map and endpoint cost map.  In addition, it extends the constraints to further filter those maps by allowing an ALTO Client to specify a logical combination of tests 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 Updates 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

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2046.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7285.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2387.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5322.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8189.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8895.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8896.xml"/>

<!-- draft-ietf-alto-unified-props-new (RFC 7285) provides network-related information, called network information resources, to client applications so that clients can make informed decisions in utilizing 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 incremental, in that if only a small section of an information resource changes, the ALTO server can send just the changes and (2) updates can be immediate, in that 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 Traffic Optimization (ALTO) protocol.  It extends the ALTO cost information service so that applications decide not only 'where' to connect but also 'when'.  This is useful for applications that need to perform bulk data transfer and would like to schedule these transfers during an off-peak hour, for example.  This extension introduces the ALTO Cost Calendar with which an ALTO Server exposes ALTO cost values in JSON arrays where each value corresponds to a given time interval.  The time intervals, as well as other Calendar attributes, are specified in the Information Resources Directory and ALTO Server responses.</t>
            </abstract>
          </front>
          <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>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-alto-unified-props-new-24"/>
        </reference>
        <reference anchor="I-D.bw-alto-cost-mode">
          <front>
            <title>A Cost Mode Registry for the Application-Layer Traffic Optimization (ALTO) Protocol</title>
            <author fullname="Mohamed Boucadair">
              <organization>Orange</organization>
            </author>
            <author fullname="Qin Wu">
              <organization>Huawei</organization>
            </author>
            <date day="4" month="March" year="2022"/>
            <abstract>
              <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 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 the ALTO specification on allowed cost mode values.

   This document updates draft-ietf-alto-cost-mode)
   RFC 7285.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-bw-alto-cost-mode-01"/>
        </reference> 9274; published 7/26/2022) -->
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9274.xml"/>

      </references>
      <references>
        <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 provided by network elements, and available to applications, in an internetwork which offers multiple qualities of service. The document first provides some necessary context -- including relevant definitions and suggested data formats -- and then 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="Rekhter">
              <organization/>
            </author>
            <author fullname="T. Li" initials="T." role="editor" surname="Li">
              <organization/>
            </author>
            <author fullname="S. Hares" initials="S." role="editor" surname="Hares">
              <organization/>
            </author>
            <date month="January" year="2006"/>
            <abstract>
              <t>This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol.</t>
              <t>The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems.  This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may 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 Inter-Domain Routing (CIDR).  These mechanisms include support for advertising a set 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

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2216.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4271.xml"/>

<!-- draft-ietf-httpbis-http2bis (RFC 9113; published) -->
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9113.xml"/>

<!-- draft-ietf-quic-http (RFC 9114; published) -->
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9114.xml"/>

<!-- draft-ietf-alto-performance-metrics (MISSREF)
   Have 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-07"/>
        </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 desirable
   in a transport do "long way" 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

   DO NOT DEPLOY THIS VERSION OF HTTP/3 UNTIL IT IS IN AN RFC.  This
   version is still a work in progress.  For trial deployments, please
   use earlier versions.

Note to Readers

   Discussion of this draft takes place on the QUIC working group
   mailing list (quic@ietf.org), which is archived at
   https://mailarchive.ietf.org/arch/search/?email_list=quic.

   Working Group information can be found at https://github.com/quicwg;
   source code correct author initials.  Also,
   "Contreras" vice "Contreras Murillo", per published RFCs
   7028, 7161, 8432, 8568, 8597, and issues list for this draft can be found at
   https://github.com/quicwg/base-drafts/labels/-http.
              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-quic-http-34"/>
        </reference> 9013. -->
<reference anchor="I-D.ietf-alto-performance-metrics"> anchor="ALTO-PERF-METRICS">
   <front>
      <title>ALTO Performance Cost Metrics</title>
      <author fullname="Qin Wu"> Wu" initials="Q" surname="Wu">
	 <organization>Huawei</organization>
      </author>
      <author fullname="Y. Richard Yang"> Yang" initials="Y" surname="Yang">
	 <organization>Yale University</organization>
      </author>
      <author fullname="Young Lee"> Lee" initials="Y" surname="Lee">
	 <organization>Samsung</organization>
      </author>
      <author fullname="Dhruv Dhody"> Dhody" initials="D" surname="Dhody">
	 <organization>Huawei</organization>
      </author>
      <author fullname="Sabine Randriamasy"> Randriamasy" initials="S" surname="Randriamasy">
	 <organization>Nokia Bell Labs</organization>
      </author>
      <author fullname="Luis Miguel Contreras Murillo"> Murillo" initials="L" surname="Contreras">
	 <organization>Telefonica</organization>
      </author>
      <date day="2" month="March" year="2022"/>
            <abstract>
              <t>   The cost metric is a basic concept in Application-Layer Traffic
   Optimization (ALTO), and different applications may use different
   types day="21" year="2022" />
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ietf-alto-performance-metrics-28" />
</reference>

<!-- draft-irtf-nmrg-ibn-concepts-definitions (RFC-EDITOR as 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 8/23/2022;
   keep 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
   provide a variety of network performance metrics, including network
   delay, delay variation (a.k.a, jitter), packet loss rate, hop count,
   and bandwidth.

   There are multiple sources (e.g., estimation based eye on measurements or
   service-level agreement) to derive a performance metric.  This
   document introduces an additional "cost-context" field how it progresses)
   (Had to the ALTO
   "cost-type" field do "long way" to convey the source get "L. Z. Granville") -->
<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 Zambenedetti Granville">
	 <organization>Federal University of a performance metric.

              </t>
            </abstract> Rio Grande do Sul (UFRGS)</organization>
      </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-ietf-alto-performance-metrics-26"/> value="draft-irtf-nmrg-ibn-concepts-definitions-09" />
</reference>

        <reference anchor="XQuery" target="https://www.w3.org/TR/xquery-31/">
          <front>
            <title>XQuery 3.1: An XML Query Language</title>
            <author>
            <author initials="J." surname="Robie" fullname="Jonathan Robie" role="editor">
              <organization/>
            </author>
            <author initials="M." surname="Dyck" fullname="Michael Dyck" role="editor">
              <organization/>
            </author>
            <author initials="J." surname="Spiegel" fullname="Josh Spiegel" role="editor">
              <organization/>
            </author>
            <date year="2017"/> year="2017" month="March"/>
          </front>
        <refcontent>W3C Recommendation</refcontent>
        </reference>

        <reference anchor="SEREDGE" target="https://doi.org/10.1109/NOMS47738.2020.9110342"> target="https://ieeexplore.ieee.org/document/9110342">
          <front>
            <title>Computing at the Edge: But, what Edge?</title>
            <author initials="L." surname="Contreras" fullname="Luis M. Contreras">
              <organization>Telefonica</organization>
            </author>
            <author initials="J." surname="Baliosian" fullname="Javier Baliosian">
              <organization>Telefonica/Universidad de la República</organization>
            </author>
<author initials="P." surname="Martı́nez-Julia" surname="Martínez-Julia" fullname="Pedro
Martı́nez-Julia">
              <organization>National Institute of Information and Communications Technology, Japan</organization>
            </author>
            <author initials="J." surname="Serrat" fullname="Joan Serrat">
              <organization>Universitat Politcnica de Catalunya</organization>
            </author>
            <date year="2020"/> year="2020" month="April"/>
          </front>
          <seriesInfo name="In proceedings
          <refcontent>Proceedings of the NOMS 2020 - 2020 IEEE/IFIP Network Operations and Management Symposium. Symposium, pp. 1-9." value=""/> 1-9</refcontent>
	  <seriesInfo name="DOI" value="10.1109/NOMS47738.2020.9110342"/>
        </reference>

        <reference anchor="MOWIE" target="https://doi.org/10.1145/3405672.3409489"> target="https://dl.acm.org/doi/10.1145/3405672.3409489">
          <front>
            <title>MoWIE: Toward Systematic, Adaptive Network Information Exposure as an Enabling Technique for Cloud-Based Applications over 5G and Beyond</title>
            <author initials="Y." surname="Zhang" fullname="Yunfei Zhang">
              <organization>Tencent</organization>
            </author>
            <author initials="G." surname="Li" fullname="Gang Li">
              <organization>China Mobile</organization>
            </author>
            <author initials="C." surname="Xiong" fullname="Chunshan Xiong">
              <organization>Tencent</organization>
            </author>
            <author initials="Y." surname="Lei" fullname="Yixue Lei">
              <organization>Tencent</organization>
            </author>
            <author initials="W." surname="Huang" fullname="Wei Huang">
              <organization>Tencent</organization>
            </author>
            <author initials="Y." surname="Han" fullname="Yunbo Han">
              <organization>Tencent</organization>
            </author>
            <author initials="A." surname="Walid" fullname="Anwar Walid">
              <organization>Nokia Bell Labs</organization>
            </author>
            <author initials="Y.R." surname="Yang" fullname="Yang Richard Yang">
              <organization>Yale University</organization>
            </author>
            <author initials="Z." surname="Zhang" fullname="Zhi-Li Zhang">
              <organization>University of Minnesota</organization>
            </author>
            <date year="2020"/> year="2020" month="August"/>
          </front>
          <seriesInfo name="In Proceedings
          <refcontent>Proceedings of the Workshop on Network Application Integration/CoDesign, Integration/CoDesign (NAI '20), ACM, Virtual Event USA, 20-27." value=""/> pp. 20-27</refcontent>
	  <seriesInfo name="DOI" value="10.1145/3405672.3409489"/>
        </reference>

        <reference anchor="JSONiq" target="https://www.jsoniq.org/">
          <front>
            <title>The JSON Query language</title> Language</title>
            <author>
              <organization/>
              <organization>JSONiq</organization>
            </author>
            <date year="2020"/> year="2022"/>
          </front>
        </reference>

        <reference anchor="MERCATOR" target="https://doi.org/10.1109/JSAC.2019.2927073"> target="https://ieeexplore.ieee.org/document/8756056">
          <front>
            <title>Toward Fine-Grained, Privacy-Preserving, Efficient Multi-Domain Network Resource Discovery</title>
            <author initials="Q." surname="Xiang" fullname="Qiao Xiang">
              <organization>Yale University</organization>
            </author>
            <author initials="J." surname="Zhang" fullname="Jingxuan Zhang">
              <organization>Tongji University</organization>
            </author>
            <author initials="X." surname="Wang" fullname="Xin Wang">
              <organization>Tongji University</organization>
            </author>
            <author initials="Y." surname="Liu" fullname="Yang Liu">
              <organization>Tongji University</organization>
            </author>
            <author initials="C." surname="Guok" fullname="Chin Guok">
              <organization>ESNet</organization>
            </author>
            <author initials="F." surname="Le" fullname="Franck Le">
              <organization>IBM T.J. Watson Research Center</organization>
            </author>
            <author initials="J." surname="MacAuley" fullname="John MacAuley">
              <organization>ESNet</organization>
            </author>
            <author initials="H." surname="Newman" fullname="Harvey Newman">
              <organization>Caltech</organization>
            </author>
            <author initials="Y.R." surname="Yang" fullname="Yang Richard Yang">
              <organization>Yale University</organization>
            </author>
            <date year="2019"/> year="2019" month="August"/>
          </front>
          <seriesInfo name="IEEE/ACM" value="IEEE
          <refcontent>IEEE/ACM, IEEE Journal on Selected Areas of Communication 37(8): 1924-1940"/> in Communications, Volume 37, Issue 8, pp. 1924-1940</refcontent>
	  <seriesInfo name="DOI" value="10.1109/JSAC.2019.2927073"/>
        </reference>

        <reference anchor="NOVA" target="https://doi.org/10.1109/IWQoS.2017.7969117"> target="https://doi.org/10.1109/TNET.2019.2899905">
          <front>
            <title>An objective-driven on-demand network abstraction Objective-Driven On-Demand Network Abstraction for adaptive applications</title> Adaptive Applications</title>
            <author initials="K." surname="Gao" fullname="Kai Gao">
              <organization>Sichuan University</organization>
            </author>
            <author initials="Q." surname="Xiang" fullname="Qiao Xiang">
              <organization>Yale University</organization>
            </author>
            <author initials="X." surname="Wang" fullname="Xin Wang">
              <organization>Tongji University</organization>
            </author>
            <author initials="Y.R." surname="Yang" fullname="Yang Richard Yang">
              <organization>Yale University</organization>
            </author>
            <author initials="J." surname="Bi" fullname="Jun Bi">
              <organization>Tsinghua University</organization>
            </author>
            <date month="April" year="2019"/>
          </front>
          <seriesInfo name="IEEE/ACM" value="Transactions
          <refcontent>IEEE/ACM Transactions on Networking (TON) Vol Vol. 27, no. 2 (2019): 805-818."/> Issue 2, pp. 805-818</refcontent>
        <seriesInfo name="DOI" value="10.1109/TNET.2019.2899905"/>
        </reference>
        <reference anchor="RESA" target="https://doi.org/10.1109/SC.2018.00008"> target="https://ieeexplore.ieee.org/document/8665783">
          <front>
            <title>Fine-grained, multi-domain network resource abstraction
            <title>Fine-Grained, Multi-Domain Network Resource Abstraction as a fundamental primitive Fundamental Primitive to enable high-performance, collaborative data sciences</title> Enable High-Performance, Collaborative Data Sciences</title>
            <author initials="Q." surname="Xiang" fullname="Qiao Xiang">
              <organization>Yale University</organization>
            </author>
            <author initials="J." surname="Zhang" fullname="Jingxuan Zhang">
              <organization>Tongji University</organization>
            </author>
            <author initials="X." surname="Wang" fullname="Xin Wang">
              <organization>Tongji University</organization>
            </author>
            <author initials="Y." surname="Liu" fullname="Yang Liu">
              <organization>Tongji University</organization>
            </author>
            <author initials="C." surname="Guok" fullname="Chin Guok">
              <organization>ESNet</organization>
            </author>
            <author initials="F." surname="Le" fullname="Franck Le">
              <organization>IBM T.J. Watson Research Center</organization>
            </author>
            <author initials="J." surname="MacAuley" fullname="John MacAuley">
              <organization>ESNet</organization>
            </author>
            <author initials="H." surname="Newman" fullname="Harvey Newman">
              <organization>Caltech</organization>
            </author>
            <author initials="Y.R." surname="Yang" fullname="Yang Richard Yang">
              <organization>Yale University</organization>
            </author>
            <date year="2019"/> year="2018" month="November"/>
          </front>
          <refcontent>SC18: International Conference for High Performance Computing, Networking, Storage and Analysis, pp. 58-70</refcontent>
	  <seriesInfo name="Proceedings of the Super Computing 2018, 5:1-5:13" value=""/> name="DOI" value="10.1109/SC.2018.00008"/>
        </reference>

        <reference anchor="BOXOPT" target="https://doi.org/10.1609/aaai.v33i01.33011674"> target="https://ojs.aaai.org//index.php/AAAI/article/view/3984">
          <front>
            <title>Optimizing in the dark: Dark: Learning an optimal solution Optimal Solution through a simple request interface</title> Simple Request Interface</title>
            <author initials="Q." surname="Xiang" fullname="Qiao Xiang">
              <organization>Yale University</organization>
            </author>
            <author initials="H." surname="Yu" fullname="Haitao Yu">
              <organization>Tongji University</organization>
            </author>
            <author initials="J." surname="Aspnes" fullname="James Aspnes">
              <organization>Yale University</organization>
            </author>
            <author initials="F." surname="Le" fullname="Franck Le">
              <organization>IBM T.J. Watson Research Center</organization>
            </author>
            <author initials="L." surname="Kong" fullname="Linghe Kong">
              <organization>Shanghai Jiao Tong University</organization>
            </author>
            <author initials="Y.R." surname="Yang" fullname="Yang Richard Yang">
              <organization>Yale University</organization>
            </author>
            <date year="2019"/> year="2019" month="July"/>
          </front>
          <seriesInfo name="Proceedings
          <refcontent> Proceedings of the AAAI Conference on Artificial Intelligence 33, 1674-1681" value=""/> 1674-1681</refcontent>
	  <seriesInfo name="DOI" value="10.1609/aaai.v33i01.33011674 "/>
        </reference>

        <reference anchor="SENSE" target="https://www.es.net/network-r-and-d/sense/">
          <front>
            <title>Software Defined Networking (SDN) for End-to-End Networked Science at the Exascale</title>
            <author>
              <organization/>
              <organization>ESnet</organization>
            </author>
            <date year="2019"/>
          </front>
        </reference>

        <reference anchor="HUG" target="https://dl.acm.org/doi/10.5555/2930611.2930638">
          <front>
            <title>HUG: Multi-Resource Fairness multi-resource fairness for Correlated correlated and Elastic Demands</title> elastic demands</title>
            <author initials="M." surname="Chowdhury" fullname="Mosharaf Chowdhury">
              <organization>University of Michigan</organization>
            </author>
            <author initials="Z." surname="Liu" fullname="Zhenhua Liu">
              <organization>Stony Brook University</organization>
            </author>
            <author initials="A." surname="Ghodsi" fullname="Ali Ghodsi">
              <organization>UC Berkeley, Databricks Inc.</organization>
            </author>
            <author initials="I." surname="Stoica" fullname="Ion Stoica">
              <organization>UC Berkeley, Databricks Inc.</organization>
            </author>
            <date year="2016"/> year="2016" month="March"/>
          </front>
          <seriesInfo name="13th
          <refcontent>Proceedings of the 13th USENIX Symposium Conference on Networked Systems Design and Implementation (NSDI 16) (Santa (NSDI'16), Santa Clara, CA, 2016), 407-424." value=""/> pp. 407-424</refcontent>
        </reference>

        <reference anchor="SWAN" target="http://doi.acm.org/10.1145/2486001.2486012"> target="https://dl.acm.org/doi/10.1145/2486001.2486012">
          <front>
            <title>Achieving High Utilization high utilization with Software-driven software-driven WAN</title>
            <author initials="C." surname="Hong" fullname="Chi-Yao Hong">
              <organization>Microsoft</organization>
            </author>
            <author initials="S." surname="Kandula" fullname="Srikanth Kandula">
              <organization>Microsoft</organization>
            </author>
            <author initials="R." surname="Mahajan" fullname="Ratul Mahajan">
              <organization>Microsoft</organization>
            </author>
            <author initials="M." surname="Zhang" fullname="Ming Zhang">
              <organization>Microsoft</organization>
            </author>
            <author initials="V." surname="Gill" fullname="Vijay Gill">
              <organization>Microsoft</organization>
            </author>
            <author initials="M." surname="Nanduri" fullname="Mohan Nanduri">
              <organization>Microsoft</organization>
            </author>
            <author initials="R." surname="Wattenhofer" fullname="Roger Wattenhofer">
              <organization>ETH</organization>
            </author>
            <date year="2013"/> year="2013" month="August"/>
          </front>
          <seriesInfo name="In Proceedings
          <refcontent>Proceedings of the ACM SIGCOMM 2013 Conference conference on SIGCOMM (SIGCOMM '13), ACM, New York, NY, USA, 15-26." value=""/> pp. 15-26</refcontent>
	  <seriesInfo name="DOI" value="10.1145/2486001.2486012"/>
        </reference>

        <reference anchor="CLARINET" target="https://dl.acm.org/doi/abs/10.5555/3026877.3026911">
          <front>
            <title>CLARINET: WAN-Aware Optimization WAN-aware optimization for Analytics Queries</title> analytics queries</title>
            <author initials="R." surname="Viswanathan" fullname="Raajay Viswanathan">
              <organization>University of Wisconsin-Madison</organization>
            </author>
            <author initials="G." surname="Ananthanarayanan" fullname="Ganesh Ananthanarayanan">
              <organization>Microsoft</organization>
            </author>
            <author initials="A." surname="Akella" fullname="Aditya Akella">
              <organization>University of Wisconsin-Madison</organization>
            </author>
            <date year="2016"/> year="2016" month="November"/>
          </front>
          <seriesInfo name="In
          <refcontent>
Proceedings of the 12th USENIX Symposium conference on Operating Systems Design and Implementation (OSDI 16), USENIX Association, (OSDI'16), Savannah, GA, 435-450" value=""/> pp. 435-450</refcontent>
        </reference>

        <reference anchor="G2" target="https://dl.acm.org/doi/10.1145/3366707">
          <front>
            <title>On the Bottleneck Structure of Congestion-Controlled Networks</title>
            <author initials="J." surname="Ros-Giralt" fullname="Jordi Ros-Giralt">
              <organization>Reservoir Labs</organization>
            </author>
            <author initials="A." surname="Bohara" fullname="Atul Bohara">
              <organization>Reservoir Labs</organization>
            </author>
            <author initials="S." surname="Yellamraju" fullname="Sruthi Yellamraju">
              <organization>Reservoir Labs</organization>
            </author>
            <author initials="M.H." surname="Langston" fullname="M. Harper Langston">
              <organization>Reservoir Labs</organization>
            </author>
            <author initials="R." surname="Lethin" fullname="Richard Lethin">
              <organization>Reservoir Labs</organization>
            </author>
            <author initials="Y." surname="Jiang" fullname="Yuang Jiang">
              <organization>Yale University</organization>
            </author>
            <author initials="L." surname="Tassiulas" fullname="Leandros Tassiulas">
              <organization>Yale University</organization>
            </author>
            <author initials="J." surname="Li" fullname="Josie Li">
              <organization>University of Virginia</organization>
            </author>
            <author initials="Y." surname="Tan" fullname="Yuanlong Tan">
              <organization>University of Virginia</organization>
            </author>
            <author initials="M." surname="Veeraraghavan" fullname="Malathi Veeraraghavan">
              <organization>University of Virginia</organization>
            </author>
            <date year="2019"/> year="2019" month="December"/>
          </front>
          <seriesInfo name="Proceedings
          <refcontent>Proceedings of the ACM on Measurement and Analysis of Computing Systems, Volume 3, Issue 3, pp 1-31" value=""/> pp. 1-31</refcontent>
	  <seriesInfo name="DOI" value="10.1145/3366707"/>
        </reference>

        <reference anchor="BONDY" target="https://doi.org/10.1002/jgt.3190010306"> target="https://onlinelibrary.wiley.com/doi/10.1002/jgt.3190010306">
          <front>
            <title>Graph reconstruction—a reconstruction--a survey</title>
            <author initials="J.A." surname="Bondy" fullname="John Adrian Bondy">
              <organization>University of Waterloo</organization>
            </author>
            <author initials="R.L." surname="Hemminger" fullname="Robert Hemminger">
              <organization>Vanderbilt University</organization>
            </author>
            <date year="1977"/>
          </front>
          <seriesInfo name="Journal
          <refcontent>Journal of Graph Theory, Volume 1, Issue 3, pp 227-268" value=""/> pp. 227-268</refcontent>
	  <seriesInfo name="DOI" value="10.1002/jgt.3190010306"/>
        </reference>

        <reference anchor="UNICORN" target="https://doi.org/10.1016/j.future.2018.09.048"> target="https://www.sciencedirect.com/science/article/abs/pii/S0167739X18302413?via%3Dihub">
          <front>
            <title>Unicorn: Unified Resource Orchestration resource orchestration for Multi-Domain, Geo-Distributed Data Analytics</title> multi-domain, geo-distributed data analytics</title>
            <author initials="Q." surname="Xiang" fullname="Qiao Xiang">
              <organization>Yale University</organization>
            </author>
            <author initials="S." surname="Chen" fullname="Shenshen Chen"> initials="T." surname="Wang" fullname="X. Tony Wang">
              <organization>Tongji University</organization>
            </author>
            <author initials="K." surname="Gao" fullname="Kai Gao"> initials="J." surname="Zhang" fullname="Jingxuan Jensen Zhang">
              <organization>Tsinghua University</organization>
            </author>
            <author initials="H." surname="Newman" fullname="Harvey Newman">
              <organization>California Institute of Technology</organization>
            </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">
              <organization>Yale University</organization>
            </author>
            <author initials="Y." surname="Liu" fullname="Yang Liu">
              <organization>Tongji University</organization>
            </author>
            <date year="2017"/> year="2019" month="April"/>
          </front>
          <refcontent>Future Generation Computer Systems, Volume 93, pp. 188-197</refcontent>
	  <seriesInfo name="2017 IEEE SmartWorld, Ubiquitous Intelligence Computing, Advanced Trusted Computed, Scalable Computing Communications, Cloud Big Data Computing, Internet of People and Smart City Innovation (SmartWorld/SCALCOM/UIC/ATC/CBDCom/IOP/SCI) (Aug. 2017), 1-6." value=""/> name="DOI" value="10.1016/j.future.2018.09.048"/>
        </reference>
      </references>
    </references>
    <section anchor="acknowledgments" numbered="true" numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>The authors would like to thank discussions with Andreas Voellmy, Erran Li,
Haibin Song, Haizhou Du, Jiayuan Hu, Qiao Xiang, Tianyuan Liu, Xiao Shi, Xin
Wang, <contact fullname="Andreas Voellmy"/>, <contact fullname="Erran Li"/>, <contact fullname="Haibin Song"/>, <contact fullname="Haizhou Du"/>, <contact fullname="Jiayuan Hu"/>, <contact fullname="Tianyuan Liu"/>, <contact
fullname="Xiao Shi"/>, <contact fullname="Xin Wang"/>, and Yan Luo. <contact fullname="Yan Luo"/> for fruitful discussions. The authors thank Greg Bernstein, Dawn Chen, Wendy Roome, <contact fullname="Greg Bernstein"/>, <contact fullname="Dawn Chen"/>, <contact fullname="Wendy Roome"/>, and
Michael Scharf
<contact fullname="Michael Scharf"/> for their contributions to earlier drafts.</t> draft versions of this document.</t>
      <t>The authors would also like to thank Tim Chown, Luis Contreras, Roman Danyliw,
Benjamin Kaduk, Erik Kline, Suresh Krishnan, Murray Kucherawy, Warren Kumari,
Danny Lachos, Francesca Palombini, Eric Vyncke, Samuel Weiler, <contact fullname="Tim Chown"/>, <contact fullname="Luis Contreras"/>, <contact fullname="Roman Danyliw"/>,
<contact fullname="Benjamin Kaduk"/>, <contact fullname="Erik Kline"/>, <contact fullname="Suresh Krishnan"/>, <contact fullname="Murray Kucherawy"/>, <contact fullname="Warren Kumari"/>, <contact fullname="Danny Lachos"/>, <contact fullname="Francesca Palombini"/>, <contact fullname="Éric Vyncke"/>, <contact fullname="Samuel Weiler"/>, and Qiao Xiang <contact fullname="Qiao Xiang"/>,
whose feedback and suggestions are were invaluable to improve for improving the practicability and
conciseness of this document, document; and Mohamed Boucadair, Martin Duke, Vijay Gurbani,
Jan Seedorf, <contact fullname="Mohamed Boucadair"/>, <contact fullname="Martin Duke"/>, <contact fullname="Vijay Gurbani"/>,
<contact fullname="Jan Seedorf"/>, and Qin Wu <contact fullname="Qin Wu"/>, who provide provided great support and guidance.</t>
    </section>
    <section anchor="revision-logs-to-be-removed-before-publication" numbered="true" toc="default">
      <name>Revision Logs (To be removed before publication)</name>
      <section anchor="changes-since-20" numbered="true" toc="default">
        <name>Changes since -20</name>
        <t>Reivision -21</t>
        <ul spacing="normal">
          <li>changes the normative requirement on protecting confidentiality of PV
information with softer language</li>
        </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 target="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 considerations</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 Elements is
defined in <xref target="RFC2216" format="default"/></li>
          <li>restructures several paragraphs that are not clear (Sec 3, Path Vector 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 scheduling
example, and introduces how the extension addresses the additional
requirements</li>
          <li>fixes the inconsistent use of "start" parameter in multipart responses;</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 defining 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 decision 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 demand 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 aspects:  </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 path 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 draft, 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>
  </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>