<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="exp" consensus="true" docName="draft-ietf-alto-path-vector-25" indexInclude="true" ipr="trust200902" number="9275" prepTime="2022-09-23T13:22:43" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true" xml:lang="en">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-alto-path-vector-25" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9275" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="ALTO-PV">An Extension for Application-Layer Traffic Optimization (ALTO): Path Vector</title>
    <seriesInfo name="RFC" value="9275" stream="IETF"/>
    <author initials="K." surname="Gao" fullname="Kai Gao">
      <organization showOnFrontPage="true">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 showOnFrontPage="true">Samsung</organization>
      <address>
        <postal>
          <country>Republic of Korea</country>
        </postal>
        <email>younglee.tx@gmail.com</email>
      </address>
    </author>
    <author initials="S." surname="Randriamasy" fullname="Sabine Randriamasy">
      <organization showOnFrontPage="true">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." surname="Yang" fullname="Yang Richard Yang">
      <organization showOnFrontPage="true">Yale University</organization>
      <address>
        <postal>
          <street>51 Prospect Street</street>
          <city>New Haven</city>
          <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 showOnFrontPage="true">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 month="09" year="2022"/>
    <area>tsv</area>
    <workgroup>alto</workgroup>
    <keyword>network visibility</keyword>
    <keyword>abstract network element</keyword>
    <keyword>shared bottleneck</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">This document is an extension to the base Application-Layer Traffic Optimization
(ALTO) protocol. It extends the ALTO cost map and ALTO property map services so
that an application can decide to which endpoint(s) to connect based not only on
numerical/ordinal cost values but also on fine-grained abstract information regarding the
paths. This is useful for applications whose performance is impacted by
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 the "Abstract
Network Element" (ANE) to represent these components and encodes a network path
as a vector of ANEs. Thus, it provides a more complete but still abstract graph
representation of the underlying network(s) for informed traffic optimization
among endpoints.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for examination, experimental implementation, and
            evaluation.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document defines an Experimental Protocol for the Internet
            community.  This document is a product of the Internet Engineering
            Task Force (IETF).  It represents the consensus of the IETF community.
            It has received public review and has been approved for publication
            by the Internet Engineering Steering Group (IESG).  Not all documents
            approved by the IESG are candidates for any level of Internet
            Standard; see Section 2 of RFC 7841. 
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9275" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2022 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements-language">Requirements Language</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements-and-use-cases">Requirements and Use Cases</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-design-requirements">Design Requirements</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-sample-use-cases">Sample Use Cases</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.2.2">
                  <li pn="section-toc.1-1.4.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.4.2.2.2.1.1"><xref derivedContent="4.2.1" format="counter" sectionFormat="of" target="section-4.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-exposing-network-bottleneck">Exposing Network Bottlenecks</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.2.2.2">
                    <t indent="0" pn="section-toc.1-1.4.2.2.2.2.1"><xref derivedContent="4.2.2" format="counter" sectionFormat="of" target="section-4.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-resource-exposure-for-cdns-">Resource Exposure for CDNs and Service Edges</xref></t>
                  </li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-path-vector-extension-overv">Path Vector Extension: Overview</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2">
              <li pn="section-toc.1-1.5.2.1">
                <t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-abstract-network-element-an">Abstract Network Element (ANE)</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2.1.2">
                  <li pn="section-toc.1-1.5.2.1.2.1">
                    <t indent="0" pn="section-toc.1-1.5.2.1.2.1.1"><xref derivedContent="5.1.1" format="counter" sectionFormat="of" target="section-5.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ane-entity-domain">ANE Entity Domain</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.1.2.2">
                    <t indent="0" pn="section-toc.1-1.5.2.1.2.2.1"><xref derivedContent="5.1.2" format="counter" sectionFormat="of" target="section-5.1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ephemeral-and-persistent-an">Ephemeral and Persistent ANEs</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.1.2.3">
                    <t indent="0" pn="section-toc.1-1.5.2.1.2.3.1"><xref derivedContent="5.1.3" format="counter" sectionFormat="of" target="section-5.1.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-property-filtering">Property Filtering</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.5.2.2">
                <t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent="5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-path-vector-cost-type">Path Vector Cost Type</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.3">
                <t indent="0" pn="section-toc.1-1.5.2.3.1"><xref derivedContent="5.3" format="counter" sectionFormat="of" target="section-5.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-multipart-path-vector-respo">Multipart Path Vector Response</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2.3.2">
                  <li pn="section-toc.1-1.5.2.3.2.1">
                    <t indent="0" pn="section-toc.1-1.5.2.3.2.1.1"><xref derivedContent="5.3.1" format="counter" sectionFormat="of" target="section-5.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-identifying-the-media-type-">Identifying the Media Type of the Object Root</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.3.2.2">
                    <t indent="0" pn="section-toc.1-1.5.2.3.2.2.1"><xref derivedContent="5.3.2" format="counter" sectionFormat="of" target="section-5.3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references-to-part-messages">References to Part Messages</xref></t>
                  </li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-specification-basic-data-ty">Specification: Basic Data Types</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2">
              <li pn="section-toc.1-1.6.2.1">
                <t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ane-name">ANE Name</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.2">
                <t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ane-entity-domain-2">ANE Entity Domain</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2.2.2">
                  <li pn="section-toc.1-1.6.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.6.2.2.2.1.1"><xref derivedContent="6.2.1" format="counter" sectionFormat="of" target="section-6.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-entity-domain-type">Entity Domain Type</xref></t>
                  </li>
                  <li pn="section-toc.1-1.6.2.2.2.2">
                    <t indent="0" pn="section-toc.1-1.6.2.2.2.2.1"><xref derivedContent="6.2.2" format="counter" sectionFormat="of" target="section-6.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-domain-specific-entity-iden">Domain-Specific Entity Identifier</xref></t>
                  </li>
                  <li pn="section-toc.1-1.6.2.2.2.3">
                    <t indent="0" pn="section-toc.1-1.6.2.2.2.3.1"><xref derivedContent="6.2.3" format="counter" sectionFormat="of" target="section-6.2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-hierarchy-and-inheritance">Hierarchy and Inheritance</xref></t>
                  </li>
                  <li pn="section-toc.1-1.6.2.2.2.4">
                    <t indent="0" pn="section-toc.1-1.6.2.2.2.4.1"><xref derivedContent="6.2.4" format="counter" sectionFormat="of" target="section-6.2.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-media-type-of-defining-reso">Media Type of Defining Resource</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.6.2.3">
                <t indent="0" pn="section-toc.1-1.6.2.3.1"><xref derivedContent="6.3" format="counter" sectionFormat="of" target="section-6.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ane-property-name">ANE Property Name</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.4">
                <t indent="0" pn="section-toc.1-1.6.2.4.1"><xref derivedContent="6.4" format="counter" sectionFormat="of" target="section-6.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-initial-ane-property-types">Initial ANE Property Types</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2.4.2">
                  <li pn="section-toc.1-1.6.2.4.2.1">
                    <t indent="0" pn="section-toc.1-1.6.2.4.2.1.1"><xref derivedContent="6.4.1" format="counter" sectionFormat="of" target="section-6.4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-maximum-reservable-bandwidt">Maximum Reservable Bandwidth</xref></t>
                  </li>
                  <li pn="section-toc.1-1.6.2.4.2.2">
                    <t indent="0" pn="section-toc.1-1.6.2.4.2.2.1"><xref derivedContent="6.4.2" format="counter" sectionFormat="of" target="section-6.4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-persistent-entity-id">Persistent Entity ID</xref></t>
                  </li>
                  <li pn="section-toc.1-1.6.2.4.2.3">
                    <t indent="0" pn="section-toc.1-1.6.2.4.2.3.1"><xref derivedContent="6.4.3" format="counter" sectionFormat="of" target="section-6.4.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-examples">Examples</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.6.2.5">
                <t indent="0" pn="section-toc.1-1.6.2.5.1"><xref derivedContent="6.5" format="counter" sectionFormat="of" target="section-6.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-path-vector-cost-type-2">Path Vector Cost Type</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2.5.2">
                  <li pn="section-toc.1-1.6.2.5.2.1">
                    <t indent="0" pn="section-toc.1-1.6.2.5.2.1.1"><xref derivedContent="6.5.1" format="counter" sectionFormat="of" target="section-6.5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-cost-metric-ane-path">Cost Metric: "ane-path"</xref></t>
                  </li>
                  <li pn="section-toc.1-1.6.2.5.2.2">
                    <t indent="0" pn="section-toc.1-1.6.2.5.2.2.1"><xref derivedContent="6.5.2" format="counter" sectionFormat="of" target="section-6.5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-cost-mode-array">Cost Mode: "array"</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.6.2.6">
                <t indent="0" pn="section-toc.1-1.6.2.6.1"><xref derivedContent="6.6" format="counter" sectionFormat="of" target="section-6.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-part-resource-id-and-part-c">Part Resource ID and Part Content ID</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-specification-service-exten">Specification: Service Extensions</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
              <li pn="section-toc.1-1.7.2.1">
                <t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-notation">Notation</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.2">
                <t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent="7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-multipart-filtered-cost-map">Multipart Filtered Cost Map for Path Vector</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2.2.2">
                  <li pn="section-toc.1-1.7.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.7.2.2.2.1.1"><xref derivedContent="7.2.1" format="counter" sectionFormat="of" target="section-7.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-media-type">Media Type</xref></t>
                  </li>
                  <li pn="section-toc.1-1.7.2.2.2.2">
                    <t indent="0" pn="section-toc.1-1.7.2.2.2.2.1"><xref derivedContent="7.2.2" format="counter" sectionFormat="of" target="section-7.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-http-method">HTTP Method</xref></t>
                  </li>
                  <li pn="section-toc.1-1.7.2.2.2.3">
                    <t indent="0" pn="section-toc.1-1.7.2.2.2.3.1"><xref derivedContent="7.2.3" format="counter" sectionFormat="of" target="section-7.2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-accept-input-parameters">Accept Input Parameters</xref></t>
                  </li>
                  <li pn="section-toc.1-1.7.2.2.2.4">
                    <t indent="0" pn="section-toc.1-1.7.2.2.2.4.1"><xref derivedContent="7.2.4" format="counter" sectionFormat="of" target="section-7.2.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-capabilities">Capabilities</xref></t>
                  </li>
                  <li pn="section-toc.1-1.7.2.2.2.5">
                    <t indent="0" pn="section-toc.1-1.7.2.2.2.5.1"><xref derivedContent="7.2.5" format="counter" sectionFormat="of" target="section-7.2.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-uses">Uses</xref></t>
                  </li>
                  <li pn="section-toc.1-1.7.2.2.2.6">
                    <t indent="0" pn="section-toc.1-1.7.2.2.2.6.1"><xref derivedContent="7.2.6" format="counter" sectionFormat="of" target="section-7.2.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-response">Response</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.7.2.3">
                <t indent="0" pn="section-toc.1-1.7.2.3.1"><xref derivedContent="7.3" format="counter" sectionFormat="of" target="section-7.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-multipart-endpoint-cost-ser">Multipart Endpoint Cost Service for Path Vector</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2.3.2">
                  <li pn="section-toc.1-1.7.2.3.2.1">
                    <t indent="0" pn="section-toc.1-1.7.2.3.2.1.1"><xref derivedContent="7.3.1" format="counter" sectionFormat="of" target="section-7.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-media-type-2">Media Type</xref></t>
                  </li>
                  <li pn="section-toc.1-1.7.2.3.2.2">
                    <t indent="0" pn="section-toc.1-1.7.2.3.2.2.1"><xref derivedContent="7.3.2" format="counter" sectionFormat="of" target="section-7.3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-http-method-2">HTTP Method</xref></t>
                  </li>
                  <li pn="section-toc.1-1.7.2.3.2.3">
                    <t indent="0" pn="section-toc.1-1.7.2.3.2.3.1"><xref derivedContent="7.3.3" format="counter" sectionFormat="of" target="section-7.3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-accept-input-parameters-2">Accept Input Parameters</xref></t>
                  </li>
                  <li pn="section-toc.1-1.7.2.3.2.4">
                    <t indent="0" pn="section-toc.1-1.7.2.3.2.4.1"><xref derivedContent="7.3.4" format="counter" sectionFormat="of" target="section-7.3.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-capabilities-2">Capabilities</xref></t>
                  </li>
                  <li pn="section-toc.1-1.7.2.3.2.5">
                    <t indent="0" pn="section-toc.1-1.7.2.3.2.5.1"><xref derivedContent="7.3.5" format="counter" sectionFormat="of" target="section-7.3.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-uses-2">Uses</xref></t>
                  </li>
                  <li pn="section-toc.1-1.7.2.3.2.6">
                    <t indent="0" pn="section-toc.1-1.7.2.3.2.6.1"><xref derivedContent="7.3.6" format="counter" sectionFormat="of" target="section-7.3.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-response-2">Response</xref></t>
                  </li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-examples-2">Examples</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.8.2">
              <li pn="section-toc.1-1.8.2.1">
                <t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent="8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-sample-setup">Sample Setup</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.2">
                <t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent="8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-information-resource-direct">Information Resource Directory</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.3">
                <t indent="0" pn="section-toc.1-1.8.2.3.1"><xref derivedContent="8.3" format="counter" sectionFormat="of" target="section-8.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-multipart-filtered-cost-map-2">Multipart Filtered Cost Map</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.4">
                <t indent="0" pn="section-toc.1-1.8.2.4.1"><xref derivedContent="8.4" format="counter" sectionFormat="of" target="section-8.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-multipart-endpoint-cost-serv">Multipart Endpoint Cost Service Resource</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.5">
                <t indent="0" pn="section-toc.1-1.8.2.5.1"><xref derivedContent="8.5" format="counter" sectionFormat="of" target="section-8.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-incremental-updates">Incremental Updates</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.6">
                <t indent="0" pn="section-toc.1-1.8.2.6.1"><xref derivedContent="8.6" format="counter" sectionFormat="of" target="section-8.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-multi-cost">Multi-Cost</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-compatibility-with-other-al">Compatibility with Other ALTO Extensions</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.9.2">
              <li pn="section-toc.1-1.9.2.1">
                <t indent="0" pn="section-toc.1-1.9.2.1.1"><xref derivedContent="9.1" format="counter" sectionFormat="of" target="section-9.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-compatibility-with-legacy-a">Compatibility with Legacy ALTO Clients/Servers</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.2">
                <t indent="0" pn="section-toc.1-1.9.2.2.1"><xref derivedContent="9.2" format="counter" sectionFormat="of" target="section-9.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-compatibility-with-multi-co">Compatibility with Multi-Cost Extension</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.3">
                <t indent="0" pn="section-toc.1-1.9.2.3.1"><xref derivedContent="9.3" format="counter" sectionFormat="of" target="section-9.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-compatibility-with-incremen">Compatibility with Incremental Update Extension</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.4">
                <t indent="0" pn="section-toc.1-1.9.2.4.1"><xref derivedContent="9.4" format="counter" sectionFormat="of" target="section-9.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-compatibility-with-cost-cal">Compatibility with Cost Calendar Extension</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" format="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-general-discussion">General Discussion</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.10.2">
              <li pn="section-toc.1-1.10.2.1">
                <t indent="0" pn="section-toc.1-1.10.2.1.1"><xref derivedContent="10.1" format="counter" sectionFormat="of" target="section-10.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-constraint-tests-for-genera">Constraint Tests for General Cost Types</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.2">
                <t indent="0" pn="section-toc.1-1.10.2.2.1"><xref derivedContent="10.2" format="counter" sectionFormat="of" target="section-10.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-general-multi-resource-quer">General Multi-Resource Query</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="11" format="counter" sectionFormat="of" target="section-11"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.12">
            <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="12" format="counter" sectionFormat="of" target="section-12"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.12.2">
              <li pn="section-toc.1-1.12.2.1">
                <t indent="0" pn="section-toc.1-1.12.2.1.1"><xref derivedContent="12.1" format="counter" sectionFormat="of" target="section-12.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-alto-cost-metrics-registry">"ALTO Cost Metrics" Registry</xref></t>
              </li>
              <li pn="section-toc.1-1.12.2.2">
                <t indent="0" pn="section-toc.1-1.12.2.2.1"><xref derivedContent="12.2" format="counter" sectionFormat="of" target="section-12.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-alto-cost-modes-registry">"ALTO Cost Modes" Registry</xref></t>
              </li>
              <li pn="section-toc.1-1.12.2.3">
                <t indent="0" pn="section-toc.1-1.12.2.3.1"><xref derivedContent="12.3" format="counter" sectionFormat="of" target="section-12.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-alto-entity-domain-types-re">"ALTO Entity Domain Types" Registry</xref></t>
              </li>
              <li pn="section-toc.1-1.12.2.4">
                <t indent="0" pn="section-toc.1-1.12.2.4.1"><xref derivedContent="12.4" format="counter" sectionFormat="of" target="section-12.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-alto-entity-property-types-">"ALTO Entity Property Types" Registry</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.12.2.4.2">
                  <li pn="section-toc.1-1.12.2.4.2.1">
                    <t indent="0" pn="section-toc.1-1.12.2.4.2.1.1"><xref derivedContent="12.4.1" format="counter" sectionFormat="of" target="section-12.4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-new-ane-property-type-maxim">New ANE Property Type: Maximum Reservable Bandwidth</xref></t>
                  </li>
                  <li pn="section-toc.1-1.12.2.4.2.2">
                    <t indent="0" pn="section-toc.1-1.12.2.4.2.2.1"><xref derivedContent="12.4.2" format="counter" sectionFormat="of" target="section-12.4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-new-ane-property-type-persi">New ANE Property Type: Persistent Entity ID</xref></t>
                  </li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.13">
            <t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="13" format="counter" sectionFormat="of" target="section-13"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.13.2">
              <li pn="section-toc.1-1.13.2.1">
                <t indent="0" pn="section-toc.1-1.13.2.1.1"><xref derivedContent="13.1" format="counter" sectionFormat="of" target="section-13.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.13.2.2">
                <t indent="0" pn="section-toc.1-1.13.2.2.1"><xref derivedContent="13.2" format="counter" sectionFormat="of" target="section-13.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.14">
            <t indent="0" pn="section-toc.1-1.14.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments</xref></t>
          </li>
          <li pn="section-toc.1-1.15">
            <t indent="0" pn="section-toc.1-1.15.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">Network performance metrics are crucial for assessing the Quality of Experience
(QoE) of applications. The Application-Layer Traffic Optimization (ALTO) protocol allows Internet Service Providers
(ISPs) to provide guidance, such as topological distances between different end
hosts, to overlay applications. Thus, the overlay applications can potentially
improve the perceived QoE by better orchestrating their traffic to utilize the
resources in the underlying network infrastructure.</t>
      <t indent="0" pn="section-1-2">The existing ALTO
cost map (<xref target="RFC7285" sectionFormat="of" section="11.2.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7285#section-11.2.3" derivedContent="RFC7285"/>) and Endpoint Cost Service (<xref target="RFC7285" sectionFormat="of" section="11.5" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7285#section-11.5" derivedContent="RFC7285"/>) provide only cost information for an end-to-end path defined by
its &lt;source, destination&gt; endpoints: the base protocol <xref target="RFC7285" format="default" sectionFormat="of" derivedContent="RFC7285"/> 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="ALTO-PERF-METRICS" format="default" sectionFormat="of" derivedContent="ALTO-PERF-METRICS"/>, to
query multiple costs simultaneously <xref target="RFC8189" format="default" sectionFormat="of" derivedContent="RFC8189"/>, and to obtain time-varying
values <xref target="RFC8896" format="default" sectionFormat="of" derivedContent="RFC8896"/>.</t>
      <t indent="0" pn="section-1-3">While numerical/ordinal cost values for end-to-end paths provided by
the existing extensions are sufficient to optimize the QoE of many
overlay applications, the QoE of some overlay applications also
depends on the properties of particular components on the 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, 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 (ANEs).</t>
      <t indent="0" pn="section-1-4">Predicting such information can be very complex without the help of ISPs; for
example, <xref target="BOXOPT" format="default" sectionFormat="of" derivedContent="BOXOPT"/> 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 indent="0" pn="section-1-5">Despite the claimed benefits, ISPs are not likely to expose raw details on their network paths: first because ISPs have requirements 
to hide their network topologies, second because 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 indent="0" pn="section-1-6">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 network complexity and
confidential information. An "abstract network state" is a selected set of
abstract representations of ANEs traversed by the paths
between &lt;source, destination&gt; pairs combined with properties of these 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 ANEs. Server scalability can also be improved by
combining ANEs and their properties in a single response.</t>
      <t indent="0" pn="section-1-7">This document extends the ALTO base protocol <xref target="RFC7285" format="default" sectionFormat="of" derivedContent="RFC7285"/> to allow an ALTO server to convey "abstract
network state" for paths defined by their &lt;source, destination&gt; pairs. To this
end, it introduces a new cost type called a "Path Vector", following the cost
metric registration specified in <xref target="RFC7285" format="default" sectionFormat="of" derivedContent="RFC7285"/> and the updated cost mode
registration specified in <xref target="RFC9274" format="default" sectionFormat="of" derivedContent="RFC9274"/>. A Path Vector is an array
of identifiers that identifies an ANE, which can be
associated with various properties. The associations between ANEs and their
properties are encoded in an ALTO information resource called the "entity property
map", which is specified in <xref target="RFC9240" format="default" sectionFormat="of" derivedContent="RFC9240"/>.</t>
      <t indent="0" pn="section-1-8">For better confidentiality, this document aims to minimize information exposure
of an ALTO server when providing Path Vector services. In particular, this
document enables the capability, and also recommends that 1) ANEs be constructed on demand and
2) an ANE only be associated with properties that are requested by an ALTO
client. A Path Vector response involves two ALTO maps: the cost map, which
contains the Path Vector results; and the up-to-date entity property map, which
contains the properties requested for these ANEs. To enforce consistency and
improve server scalability, this document uses the "multipart/related" content
type as defined in <xref target="RFC2387" format="default" sectionFormat="of" derivedContent="RFC2387"/> to return the two maps in a single response.</t>
      <t indent="0" pn="section-1-9">As a single ISP may not have knowledge of the full Internet paths between
arbitrary endpoints, this document is mainly applicable when</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1-10">
        <li pn="section-1-10.1">there is a
single ISP between the requested source and destination Provider-defined Identifiers (PIDs) or endpoints -- for
example, ISP-hosted Content Delivery Network (CDN) / edge, tenant interconnection in a single public cloud
platform, etc., or</li>
        <li pn="section-1-10.2">the Path Vectors are generated from end-to-end
measurement data.</li>
      </ul>
    </section>
    <section anchor="requirements-languages" numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-requirements-language">Requirements Language</name>
      <t indent="0" pn="section-2-1">The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
       "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
       "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
       "<bcp14>SHOULD NOT</bcp14>",
       "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
       "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
       are to be interpreted as described in BCP 14
       <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only
       when, they appear in all capitals, as shown here.</t>
    </section>
    <section anchor="term" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-terminology">Terminology</name>
      <t indent="0" pn="section-3-1">This document extends the ALTO base protocol <xref target="RFC7285" format="default" sectionFormat="of" derivedContent="RFC7285"/> and the entity
property map extension <xref target="RFC9240" format="default" sectionFormat="of" derivedContent="RFC9240"/>. In addition to
the terms defined in those documents, this document also uses the following
terms:</t>
      <dl indent="3" newline="false" spacing="normal" pn="section-3-2">
        <dt pn="section-3-2.1">
Abstract Network Element (ANE):  </dt>
        <dd pn="section-3-2.2">
          <t indent="0" pn="section-3-2.2.1">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, or an interface; or an aggregation of devices such as a subnetwork or a
data center.
</t>
          <t indent="0" pn="section-3-2.2.2">The definition of an ANE is similar to that for a network element
as defined in <xref target="RFC2216" format="default" sectionFormat="of" derivedContent="RFC2216"/> 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 requires the components to be capable of
exercising QoS control, while an ANE only requires the
components to have an impact on end-to-end performance.</t>
        </dd>
        <dt pn="section-3-2.3">
ANE name:  </dt>
        <dd pn="section-3-2.4">
          <t indent="0" pn="section-3-2.4.1">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, as defined in <xref target="ane-name-spec" format="default" sectionFormat="of" derivedContent="Section 6.1"/>. Note that
an ALTO client must not assume ANEs in different scopes but with the same ANE
name refer to the same component(s) of the network.</t>
        </dd>
        <dt pn="section-3-2.5">
Path Vector (or ANE Path Vector):  </dt>
        <dd pn="section-3-2.6">
          <t indent="0" pn="section-3-2.6.1">Refers to a JSON array of ANE names. It is a
generalization of a BGP path vector. While a standard BGP path vector (<xref target="RFC4271" sectionFormat="of" section="5.1.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4271#section-5.1.2" derivedContent="RFC4271"/>) specifies a sequence of Autonomous Systems (ASes) for a
destination IP prefix, the Path Vector defined in this extension specifies a
sequence of ANEs for either 1) a source PID and a
destination PID, as in the CostMapData object (<xref target="RFC7285" sectionFormat="of" section="11.2.3.6" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7285#section-11.2.3.6" derivedContent="RFC7285"/>) or 2) a
source endpoint and a destination endpoint, as in the EndpointCostMapData
object (<xref target="RFC7285" sectionFormat="of" section="11.5.1.6" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7285#section-11.5.1.6" derivedContent="RFC7285"/>).</t>
        </dd>
        <dt pn="section-3-2.7">
Path Vector resource:  </dt>
        <dd pn="section-3-2.8">
          <t indent="0" pn="section-3-2.8.1">An ALTO information resource (<xref target="RFC7285" sectionFormat="of" section="8.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7285#section-8.1" derivedContent="RFC7285"/>) that supports the
extension defined in this document.</t>
        </dd>
        <dt pn="section-3-2.9">
Path Vector cost type:  </dt>
        <dd pn="section-3-2.10">
          <t indent="0" pn="section-3-2.10.1">A special cost type, which is specified in <xref target="cost-type-spec" format="default" sectionFormat="of" derivedContent="Section 6.5"/>. When this cost
type is present in an 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
request or an Endpoint Cost Service request, it indicates that each cost value must
be interpreted as a Path Vector.</t>
        </dd>
        <dt pn="section-3-2.11">
Path Vector request:  </dt>
        <dd pn="section-3-2.12">
          <t indent="0" pn="section-3-2.12.1">The POST message sent to an ALTO Path Vector resource.</t>
        </dd>
        <dt pn="section-3-2.13">
Path Vector response:  </dt>
        <dd pn="section-3-2.14">
          <t indent="0" pn="section-3-2.14.1">Refers to the multipart/related message returned by a
Path Vector resource.</t>
        </dd>
      </dl>
    </section>
    <section anchor="probstat" numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-requirements-and-use-cases">Requirements and Use Cases</name>
      <section anchor="design-requirements" numbered="true" toc="include" removeInRFC="false" pn="section-4.1">
        <name slugifiedName="name-design-requirements">Design Requirements</name>
        <t indent="0" pn="section-4.1-1">This section gives an illustrative example of how an overlay application can
benefit from the extension defined in this document.</t>
        <t indent="0" pn="section-4.1-2">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 as defined in <xref target="RFC7285" format="default" sectionFormat="of" derivedContent="RFC7285"/> cannot reveal such information.</t>
        <t indent="0" pn="section-4.1-3">Specifically, consider the example network shown in <xref target="fig-dumbbell" format="default" sectionFormat="of" derivedContent="Figure 1"/>. The network has seven
switches ("sw1" to "sw7") forming a dumbbell topology. Switches "sw1", "sw2", "sw3",
and "sw4" are access switches, and "sw5-sw7" form the backbone. End hosts "eh1" to
"eh4" are connected to access switches "sw1" to "sw4", respectively. Assume that the
bandwidth of link "eh1 -&gt; sw1" and link "sw1 -&gt; sw5" is 150 Mbps and the bandwidth
of the other links is 100 Mbps.</t>
        <figure anchor="fig-dumbbell" align="left" suppress-title="false" pn="figure-1">
          <name slugifiedName="name-raw-network-topology">Raw Network Topology</name>
          <artwork name="" type="" align="left" alt="" pn="section-4.1-4.1">
                              +-----+
                              |     |
                            --+ 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
</artwork>
        </figure>
        <t indent="0" pn="section-4.1-5">The base ALTO topology abstraction of the network is shown in <xref target="fig-base" format="default" sectionFormat="of" derivedContent="Figure 2"/>.
Assume that the cost map returns a hypothetical cost type representing the available
	bandwidth between a source and a destination.</t>
        <figure anchor="fig-base" align="left" suppress-title="false" pn="figure-2">
          <name slugifiedName="name-base-topology-abstraction">Base Topology Abstraction</name>
          <artwork name="" type="" align="left" alt="" pn="section-4.1-6.1">
                          +----------------------+
                 {eh1}    |                      |     {eh2}
                 PID1     |                      |     PID2
                   +------+                      +------+
                          |                      |
                          |                      |
                 {eh3}    |                      |     {eh4}
                 PID3     |                      |     PID4
                   +------+                      +------+
                          |                      |
                          +----------------------+
</artwork>
        </figure>
        <t indent="0" pn="section-4.1-7">Now, assume that the application wants to maximize the total rate of the traffic among
a set of &lt;source, destination&gt; 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="" pn="section-4.1-8">
    max(x + y).
</artwork>
        <t indent="0" pn="section-4.1-9">With the ALTO 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="" pn="section-4.1-10">
    x &lt;= 100 Mbps
    y &lt;= 100 Mbps.
</artwork>
        <t indent="0" pn="section-4.1-11">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>
        <dl spacing="normal" indent="3" newline="false" pn="section-4.1-12">
          <dt pn="section-4.1-12.1">Case 1:</dt>
          <dd pn="section-4.1-12.2">
            <t indent="0" pn="section-4.1-12.2.1">"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="" pn="section-4.1-12.2.2">
    x     &lt;= 100 Mbps
    y     &lt;= 100 Mbps
    x + y &lt;= 150 Mbps
</artwork>
            <t indent="0" pn="section-4.1-12.2.3">
and the real optimal total rate is 150 Mbps.</t>
          </dd>
          <dt pn="section-4.1-12.3">Case 2:</dt>
          <dd pn="section-4.1-12.4">
            <t indent="0" pn="section-4.1-12.4.1">"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="" pn="section-4.1-12.4.2">
    x     &lt;= 100 Mbps
    y     &lt;= 100 Mbps
    x + y &lt;= 100 Mbps
</artwork>
            <t indent="0" pn="section-4.1-12.4.3">
and the real optimal total rate is 100 Mbps.</t>
          </dd>
        </dl>
        <t indent="0" pn="section-4.1-13">Clearly, with more accurate and fine-grained information, the application can
better 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" bare="false" empty="false" indent="3" pn="section-4.1-14">
          <li pn="section-4.1-14.1">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 pn="section-4.1-14.2">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" and "sw1‑‑sw5" in Case 1.</li>
          <li pn="section-4.1-14.3">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" in Case 1 or expose three abstract elements "A", "B", and "C", which
represent the linear constraints that define the same capacity region in Case
1.</li>
        </ul>
        <t indent="0" pn="section-4.1-15">In general, we can conclude that to support the use case for multiple flow scheduling, the ALTO framework must be extended to satisfy the following
additional requirements (ARs):</t>
        <dl indent="3" newline="false" spacing="normal" pn="section-4.1-16">
          <dt pn="section-4.1-16.1">
AR1:  </dt>
          <dd pn="section-4.1-16.2">
            <t indent="0" pn="section-4.1-16.2.1">An ALTO server must provide the ANEs that are important for assessing the QoE of
the overlay application on the path of a &lt;source, destination&gt; pair.</t>
          </dd>
          <dt pn="section-4.1-16.3">
AR2:  </dt>
          <dd pn="section-4.1-16.4">
            <t indent="0" pn="section-4.1-16.4.1">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 pn="section-4.1-16.5">
AR3:  </dt>
          <dd pn="section-4.1-16.6">
            <t indent="0" pn="section-4.1-16.6.1">An ALTO server must provide information on the properties that are important
for assessing the QoE of the application for ANEs.</t>
          </dd>
        </dl>
        <t indent="0" pn="section-4.1-17">The extension defined in this document specifies a solution to expose such
abstract information.</t>
      </section>
      <section anchor="sample-use-cases" numbered="true" toc="include" removeInRFC="false" pn="section-4.2">
        <name slugifiedName="name-sample-use-cases">Sample Use Cases</name>
        <t indent="0" pn="section-4.2-1">While the problem related to multiple flow scheduling is used to help identify the
additional requirements, the extension defined in this document can be applied
to a wide range of applications. This section highlights some of the reported use cases.</t>
        <section anchor="exposing-network-bottlenecks" numbered="true" toc="include" removeInRFC="false" pn="section-4.2.1">
          <name slugifiedName="name-exposing-network-bottleneck">Exposing Network Bottlenecks</name>
          <t indent="0" pn="section-4.2.1-1">One important use case for the Path Vector extension is to expose network
bottlenecks. Applications that need to perform 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) (where "LHC" means "Large Hadron Collider"), which is the largest example of a distributed computation
collaboration in the research and education world.</t>
          <t indent="0" pn="section-4.2.1-2"><xref target="fig-da" format="default" sectionFormat="of" derivedContent="Figure 3"/> 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 indent="0" pn="section-4.2.1-3">In such a setting, the network-aware job optimizer (e.g., <xref target="CLARINET" format="default" sectionFormat="of" derivedContent="CLARINET"/>) takes a
query and generates multiple query execution plans (QEPs). It can encode the QEPs
as Path Vector requests that are sent to an ALTO server. The ALTO server obtains
the routing information for the flows in a QEP and finds links, routers, or
middleboxes (e.g., a stateful firewall) that can potentially become bottlenecks
for the QEP (e.g., see <xref target="NOVA" format="default" sectionFormat="of" derivedContent="NOVA"/> and <xref target="G2" format="default" sectionFormat="of" derivedContent="G2"/> 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 indent="0" pn="section-4.2.1-4">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" sectionFormat="of" derivedContent="SWAN"/>), demand vectors (e.g., <xref target="HUG" format="default" sectionFormat="of" derivedContent="HUG"/>, <xref target="UNICORN" format="default" sectionFormat="of" derivedContent="UNICORN"/>),
etc. The traffic control interfaces and mechanisms are out of scope for this
document.</t>
          <figure anchor="fig-da" align="left" suppress-title="false" pn="figure-3">
            <name slugifiedName="name-example-use-case-for-data-a">Example Use Case for Data Analytics</name>
            <artwork name="" type="" align="left" alt="" pn="section-4.2.1-5.1">
                                     Data schema      Queries
                                          |             |
                                          \             /
       +-------------+                   +-----------------+
       | ALTO Client | &lt;===============&gt; |  Job Optimizer  |
       +-------------+                   +-----------------+
PV          |   ^ PV                                    |
Request     |   | Response                              |
            |   |                  On-demand resource   |
(Potential  |   | (Network         allocation, demand   |
Data        |   | Resource         vectors, etc.        |
Transfers)  |   | Constraints)     (Non-ALTO interfaces)|
            v   |                                       v
       +-------------+                   +-----------------+
       | ALTO Server | &lt;===============&gt; | Network Manager |
       +-------------+                   +-----------------+
                                           /      |      \
                                           |      |      |
                                          WAN    DC1    DC2
</artwork>
          </figure>
          <t indent="0" pn="section-4.2.1-6">Another example is illustrated in <xref target="fig-dts" format="default" sectionFormat="of" derivedContent="Figure 4"/>. 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 a bottleneck for
the data transfers.</t>
          <figure anchor="fig-dts" align="left" suppress-title="false" pn="figure-4">
            <name slugifiedName="name-example-use-case-for-cross-">Example Use Case for Cross-Site Bottleneck Discovery</name>
            <artwork name="" type="" align="left" alt="" pn="section-4.2.1-7.1">
               Ongoing transfers    New transfer requests
                             \----\        |
                                  |        |
                                  v        v
   +-------------+               +---------------+
   | ALTO Client | &lt;===========&gt; | Data Transfer |
   +-------------+               |   Scheduler   |
     ^ |      ^ | PV Request     +---------------+
     | |      | \--------------\
     | |      \--------------\ |
     | v       PV 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>
          <t indent="0" pn="section-4.2.1-8">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" sectionFormat="of" derivedContent="G2"/>. For
example, assume that hosts "a", "b", and "c" are in Site 1 and hosts "d", "e", and "f" are in
Site 2, and there are three flows in two sites: "a -&gt; b", "c -&gt; d", and "e -&gt; f" (<xref target="fig-sbot" format="default" sectionFormat="of" derivedContent="Figure 5"/>).</t>
          <figure anchor="fig-sbot" align="left" suppress-title="false" pn="figure-5">
            <name slugifiedName="name-example-three-flows-in-two-">Example: Three Flows in Two Sites</name>
            <artwork name="" type="" align="left" alt="" pn="section-4.2.1-9.1">
Site 1:

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

Site 2:

[d] &lt;........................................ [c]
  +---+ 5 Gbps +---+ 10 Gbps +----+ 20 Gbps
  | X |--------| Y |---------| GW |--------- Core
  +---+        +---+         +----+
             ....................
             .                  .
             .                  v
            [e]                [f]
</artwork>
          </figure>
          <t indent="0" pn="section-4.2.1-10">For
these flows, Site 1 returns:</t>
          <sourcecode name="" type="" markers="false" pn="section-4.2.1-11">
a: { b: [ane1] },
c: { d: [ane1, ane2, ane3] }

ane1: bw = 10 Gbps (link: A-&gt;B)
ane2: bw = 10 Gbps (link: B-&gt;GW)
ane3: bw = 50 Gbps (link: GW-&gt;Core)
</sourcecode>
          <t indent="0" pn="section-4.2.1-12">and Site 2 returns:</t>
          <sourcecode name="" type="" markers="false" pn="section-4.2.1-13">
c: { d: [anei, aneii, aneiii] }
e: { f: [aneiv] }

anei: bw = 5 Gbps (link Y-&gt;X)
aneii: bw = 10 Gbps (link GW-&gt;Y)
aneiii: bw = 20 Gbps (link Core-&gt;GW)
aneiv: bw = 10 Gbps (link Y-&gt;GW)
</sourcecode>
          <t indent="0" pn="section-4.2.1-14">With this information, the data transfer scheduler can use algorithms such as the
theory on bottleneck structure <xref target="G2" format="default" sectionFormat="of" derivedContent="G2"/> to predict the potential throughput of the
flows.</t>
        </section>
        <section anchor="resource-exposure-for-cdn-and-service-edge" numbered="true" toc="include" removeInRFC="false" pn="section-4.2.2">
          <name slugifiedName="name-resource-exposure-for-cdns-">Resource Exposure for CDNs and Service Edges</name>
          <t indent="0" pn="section-4.2.2-1">At the time of this writing, a growing trend in today's applications is to bring storage and computation
closer to the end users for better QoE, such as CDNs,
augmented reality / virtual reality, and cloud gaming, as reported in various documents (e.g., <xref target="SEREDGE" format="default" sectionFormat="of" derivedContent="SEREDGE"/> and
<xref target="MOWIE" format="default" sectionFormat="of" derivedContent="MOWIE"/>). ISPs may deploy multiple layers of CDN caches
or, more generally, service edges, with different latencies and available resources,
including the number of CPU cores, memory, and storage.</t>
          <t indent="0" pn="section-4.2.2-2">For example, <xref target="fig-se" format="default" sectionFormat="of" derivedContent="Figure 6"/> illustrates a typical edge-cloud scenario where memory
is measured in gigabytes (GB) and storage is measured in terabytes (TB). The
"on-premise" edge nodes are closest to the end hosts and have the lowest
latency, and the site-radio edge node and access central office (CO) have higher
latencies but more available resources.</t>
          <figure anchor="fig-se" align="left" suppress-title="false" pn="figure-6">
            <name slugifiedName="name-example-use-case-for-servic">Example Use Case for Service Edge Exposure</name>
            <artwork name="" type="" align="left" alt="" pn="section-4.2.2-3.1">
      +-------------+              +----------------------+
      | ALTO Client | &lt;==========&gt; | Application Provider |
      +-------------+              +----------------------+
PV         |   ^ PV                      |
Request    |   | Response                | Resource allocation,
           |   |                         | service establishment,
(End hosts |   | (Edge nodes             | etc.
and cloud  |   | and metrics)            |
servers)   |   |                         |
           v   |                         v
      +-------------+             +---------------------+
      | ALTO Server | &lt;=========&gt; | 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>
          <t indent="0" pn="section-4.2.2-4">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
(e.g., storage capabilities or Graphics Processing Unit (GPU) capabilities) and available Service Level Agreement (SLA)
plans. See <xref target="fig-se-example" format="default" sectionFormat="of" derivedContent="Figure 7"/> for an example where the query is made for sources
[a, b] and destinations [b, c, DC]. Here, each ANE represents a service edge, and
the properties include access latency, available resources, etc. Note that the
properties here are only used for illustration purposes and are not part of this
extension.</t>
          <figure anchor="fig-se-example" align="left" suppress-title="false" pn="figure-7">
            <name slugifiedName="name-example-service-edge-query-">Example Service Edge Query Results</name>
            <sourcecode name="" type="" markers="false" pn="section-4.2.2-5.1">
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 indent="0" pn="section-4.2.2-6">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 in place for customized quality of experience.</t>
        </section>
      </section>
    </section>
    <section anchor="Overview" numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-path-vector-extension-overv">Path Vector Extension: Overview</name>
      <t indent="0" pn="section-5-1">This section provides a non-normative overview of the Path Vector extension
defined in this document. It is assumed that readers are familiar with both
the base protocol <xref target="RFC7285" format="default" sectionFormat="of" derivedContent="RFC7285"/> and the entity property map extension
<xref target="RFC9240" format="default" sectionFormat="of" derivedContent="RFC9240"/>.</t>
      <t indent="0" pn="section-5-2">To satisfy the additional requirements listed in <xref target="design-requirements" format="default" sectionFormat="of" derivedContent="Section 4.1"/>, this extension:</t>
      <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-5-3"><li pn="section-5-3.1" derivedCounter="1.">introduces the concept of an ANE as the abstraction
of components in a network whose properties may have an impact on
end-to-end performance of the traffic handled by those components,</li>
        <li pn="section-5-3.2" derivedCounter="2.">extends the 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 pn="section-5-3.3" derivedCounter="3.">uses the entity property map to convey the association between the
ANEs and their properties.</li>
      </ol>
      <t indent="0" pn="section-5-4">Thus, an ALTO client can learn about the ANEs that are important for assessing the
QoE of different &lt;source, destination&gt; pairs by investigating the corresponding
Path Vector value (AR1) and can also (1) identify common ANEs if an ANE appears in the Path Vectors of multiple &lt;source, destination&gt; pairs (AR2) and
(2) retrieve the properties of the ANEs by searching the entity property map (AR3).</t>
      <section anchor="ane-design" numbered="true" toc="include" removeInRFC="false" pn="section-5.1">
        <name slugifiedName="name-abstract-network-element-an">Abstract Network Element (ANE)</name>
        <t indent="0" pn="section-5.1-1">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 end-to-end performance for application traffic between
endpoints.</t>
        <t indent="0" pn="section-5.1-2">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. 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; 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="" pn="section-5.1-3">
   f1 |      ^                  f1
      |      |                 -----------------&gt;
    +----------+                +---+     +---+
    | Firewall |                | A |-----| B |
    +----------+                +---+     +---+
      |      |                 -----------------&gt;
      v      | f2               f2
</artwork>
        <t indent="0" pn="section-5.1-4">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" sectionFormat="of" derivedContent="Section 6.1"/>,
and a set of associated properties.</t>
        <section anchor="ane-entity-domain" numbered="true" toc="include" removeInRFC="false" pn="section-5.1.1">
          <name slugifiedName="name-ane-entity-domain">ANE Entity Domain</name>
          <t indent="0" pn="section-5.1.1-1">In this extension, the associations between ANEs and their properties are conveyed
in an entity property map.  Thus, ANEs must constitute an "entity domain" (<xref target="RFC9240" sectionFormat="of" section="5.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9240#section-5.1" derivedContent="RFC9240"/>), and each ANE property must be an
entity property (<xref target="RFC9240" sectionFormat="of" section="5.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9240#section-5.2" derivedContent="RFC9240"/>).</t>
          <t indent="0" pn="section-5.1.1-2">Specifically, this document defines a new entity domain called "ane" as
specified in <xref target="ane-domain-spec" format="default" sectionFormat="of" derivedContent="Section 6.2"/>; <xref target="initial-ane-property-types" format="default" sectionFormat="of" derivedContent="Section 6.4"/> defines two initial property types for the ANE
entity domain.</t>
        </section>
        <section anchor="assoc" numbered="true" toc="include" removeInRFC="false" pn="section-5.1.2">
          <name slugifiedName="name-ephemeral-and-persistent-an">Ephemeral and Persistent ANEs</name>
          <t indent="0" pn="section-5.1.2-1">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
ANEs have several benefits, including better privacy for the ISP's internal
structure and more flexible ANE computation.</t>
          <t indent="0" pn="section-5.1.2-2">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, but it is difficult to infer the underlying topology with
multiple queries.</t>
          <t indent="0" pn="section-5.1.2-3">However, sometimes an ISP may intend to selectively reveal some "persistent"
network components that, as opposed to being ephemeral, have a longer life cycle.
For example, an ALTO server may define an ANE for each service edge cluster.
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 indent="0" pn="section-5.1.2-4">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, together with its properties. See Sections <xref target="domain-defining" format="counter" sectionFormat="of" derivedContent="6.2.4"/> and
<xref target="persistent-entity-id" format="counter" sectionFormat="of" derivedContent="6.4.2"/> for more detailed instructions on how to identify
ephemeral ANEs and persistent ANEs.</t>
        </section>
        <section anchor="property-filtering" numbered="true" toc="include" removeInRFC="false" pn="section-5.1.3">
          <name slugifiedName="name-property-filtering">Property Filtering</name>
          <t indent="0" pn="section-5.1.3-1">Resource-constrained ALTO clients (see <xref target="RFC7285" sectionFormat="of" section="4.1.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7285#section-4.1.2" derivedContent="RFC7285"/>) 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 indent="0" pn="section-5.1.3-2">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 "ane-property-names" filter. The
response only includes the selected properties for the ANEs.</t>
          <t indent="0" pn="section-5.1.3-3">The "ane-property-names" capability for the cost map and the Endpoint Cost Service
is specified in Sections <xref target="pvcm-cap" format="counter" sectionFormat="of" derivedContent="7.2.4"/> and <xref target="pvecs-cap" format="counter" sectionFormat="of" derivedContent="7.3.4"/>, respectively. The
"ane-property-names" filter for the cost map and the Endpoint Cost Service is specified
in Sections <xref target="pvcm-accept" format="counter" sectionFormat="of" derivedContent="7.2.3"/> and <xref target="pvecs-accept" format="counter" sectionFormat="of" derivedContent="7.3.3"/> accordingly.</t>
        </section>
      </section>
      <section anchor="path-vector-design" numbered="true" toc="include" removeInRFC="false" pn="section-5.2">
        <name slugifiedName="name-path-vector-cost-type">Path Vector Cost Type</name>
        <t indent="0" pn="section-5.2-1">For an ALTO client to correctly interpret the Path Vector, this extension
specifies a new cost type called the "Path Vector cost type".</t>
        <t indent="0" pn="section-5.2-2">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++,
if there existed a JSON array type named JSONArray, a Path Vector would have
the type of <tt>JSONArray&lt;ANEName&gt;</tt>.</t>
        <t indent="0" pn="section-5.2-3">Instead of extending the "type system" of ALTO, this document takes a simple
and 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" parameter. If the value is
"ane-path", it means that the JSON array should be further interpreted as a path
of ANENames.</t>
        <t indent="0" pn="section-5.2-4">The Path Vector cost type is specified in <xref target="cost-type-spec" format="default" sectionFormat="of" derivedContent="Section 6.5"/>.</t>
      </section>
      <section anchor="multipart-path-vector-response" numbered="true" toc="include" removeInRFC="false" pn="section-5.3">
        <name slugifiedName="name-multipart-path-vector-respo">Multipart Path Vector Response</name>
        <t indent="0" pn="section-5.3-1">For a basic ALTO information resource, a response contains only one type of
ALTO resource, e.g., network map, cost map, or property map.  Thus, only one
round of communication is required: an ALTO client sends a request to an ALTO
server, and the ALTO server returns a response, as shown in <xref target="fig-alto" format="default" sectionFormat="of" derivedContent="Figure 8"/>.</t>
        <figure anchor="fig-alto" align="left" suppress-title="false" pn="figure-8">
          <name slugifiedName="name-a-typical-alto-request-and-">A Typical ALTO Request and Response</name>
          <artwork type="" align="center" name="" alt="" pn="section-5.3-2.1">
  ALTO client                              ALTO server
       |-------------- Request ----------------&gt;|
       |&lt;------------- Response ----------------|
</artwork>
        </figure>
        <t indent="0" pn="section-5.3-3">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 <xref target="RFC7285" sectionFormat="of" section="11.2.3.6" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7285#section-11.2.3.6" derivedContent="RFC7285"/>) or an InfoResourceEndpointCostMap data component (defined
in <xref target="RFC7285" sectionFormat="of" section="11.5.1.6" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7285#section-11.5.1.6" derivedContent="RFC7285"/>), and ANE properties conveyed in an
InfoResourceProperties data component (defined in <xref target="RFC9240" sectionFormat="of" section="7.6" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9240#section-7.6" derivedContent="RFC9240"/>).</t>
        <t indent="0" pn="section-5.3-4">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" sectionFormat="of" derivedContent="Figure 9"/>. Since the two parts are bundled together in one
response message, their orders are interchangeable. See Sections <xref target="pvcm-resp" format="counter" sectionFormat="of" derivedContent="7.2.6"/> and
<xref target="pvecs-resp" format="counter" sectionFormat="of" derivedContent="7.3.6"/> for details.</t>
        <figure anchor="fig-pv" align="left" suppress-title="false" pn="figure-9">
          <name slugifiedName="name-the-path-vector-extension-r">The Path Vector Extension Request and Response</name>
          <artwork type="" align="center" name="" alt="" pn="section-5.3-5.1">
  ALTO client                              ALTO server
       |------------- PV Request --------------&gt;|
       |&lt;----- PV Response (Cost Map Part) -----|
       |&lt;--- PV Response (Property Map Part) ---|
</artwork>
        </figure>
        <t indent="0" pn="section-5.3-6">This design is based on the following considerations:</t>
        <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-5.3-7"><li pn="section-5.3-7.1" derivedCounter="1.">ANEs may be constructed on demand and, potentially, based on the
requested properties (see <xref target="ane-design" format="default" sectionFormat="of" derivedContent="Section 5.1"/> 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 or must wait until both requests are
received.</li>
          <li pn="section-5.3-7.2" derivedCounter="2.">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 request correctly, an ALTO server must store
the mapping of each Path Vector request until the client fully retrieves the
property information. This "stateful" behavior may substantially harm
server scalability and potentially lead to denial-of-service attacks.</li>
        </ol>
        <t indent="0" pn="section-5.3-8">One approach for realizing the one-round communication is to define a new media
type to contain both objects, but this violates modular design. This document
follows the standard-conforming usage of the "multipart/related" media type as defined
in <xref target="RFC2387" format="default" sectionFormat="of" derivedContent="RFC2387"/> to elegantly combine the objects. Path Vectors are encoded in an
InfoResourceCostMap data component or InfoResourceEndpointCostMap data component, and the property map is
encoded in an InfoResourceProperties data component. They are encapsulated as parts of a
multipart message. 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="include" removeInRFC="false" pn="section-5.3.1">
          <name slugifiedName="name-identifying-the-media-type-">Identifying the Media Type of the Object Root</name>
          <t indent="0" pn="section-5.3.1-1">ALTO uses a media type to indicate the type of an entry in the IRD (e.g., "application/alto-costmap+json" for the cost map
and "application/alto-endpointcost+json" for the Endpoint Cost Service). Simply
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 indent="0" pn="section-5.3.1-2">To address this issue, this document uses the "type" parameter to indicate the
object root of a multipart/related message. For a cost map resource, the
"media-type" field in the IRD entry is "multipart/related" with the parameter
"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="include" removeInRFC="false" pn="section-5.3.2">
          <name slugifiedName="name-references-to-part-messages">References to Part Messages</name>
          <t indent="0" pn="section-5.3.2-1">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 design provided in <xref target="RFC8895" format="default" sectionFormat="of" derivedContent="RFC8895"/>, this extension requires that an ALTO
server assign a unique identifier to each part of the multipart response
message. This identifier, referred to as a Part Resource ID (see
<xref target="part-rid-spec" format="default" sectionFormat="of" derivedContent="Section 6.6"/> for details), is present in the part message's "Content-ID"
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
or the property map part.</t>
        </section>
      </section>
    </section>
    <section anchor="Basic" numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-specification-basic-data-ty">Specification: Basic Data Types</name>
      <section anchor="ane-name-spec" numbered="true" toc="include" removeInRFC="false" pn="section-6.1">
        <name slugifiedName="name-ane-name">ANE Name</name>
        <t indent="0" pn="section-6.1-1">An ANE name is encoded as a JSON string with the same format as that of the type
PIDName (<xref target="RFC7285" sectionFormat="of" section="10.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7285#section-10.1" derivedContent="RFC7285"/>).</t>
        <t indent="0" pn="section-6.1-2">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="include" removeInRFC="false" pn="section-6.2">
        <name slugifiedName="name-ane-entity-domain-2">ANE Entity Domain</name>
        <t indent="0" pn="section-6.2-1">The ANE entity domain associates property values with the ANEs in a property map.  Accordingly, the ANE entity domain always depends on
a property map.</t>
        <t indent="0" pn="section-6.2-2">It must be noted that the term "domain" here does not refer to a network domain.
Rather, it is inherited from the entity domain as defined in
<xref target="RFC9240" sectionFormat="of" section="3.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9240#section-3.2" derivedContent="RFC9240"/>; the entity domain represents the set of valid entities
defined by an ALTO information resource (called the "defining information
resource").</t>
        <section anchor="domain-type" numbered="true" toc="include" removeInRFC="false" pn="section-6.2.1">
          <name slugifiedName="name-entity-domain-type">Entity Domain Type</name>
          <t indent="0" pn="section-6.2.1-1">The entity domain type is "ane".</t>
        </section>
        <section anchor="entity-address" numbered="true" toc="include" removeInRFC="false" pn="section-6.2.2">
          <name slugifiedName="name-domain-specific-entity-iden">Domain-Specific Entity Identifier</name>
          <t indent="0" pn="section-6.2.2-1">The entity identifiers are the ANE names in the associated property map.</t>
        </section>
        <section anchor="hierarchy-and-inheritance" numbered="true" toc="include" removeInRFC="false" pn="section-6.2.3">
          <name slugifiedName="name-hierarchy-and-inheritance">Hierarchy and Inheritance</name>
          <t indent="0" pn="section-6.2.3-1">There is no hierarchy or inheritance for properties associated with ANEs.</t>
        </section>
        <section anchor="domain-defining" numbered="true" toc="include" removeInRFC="false" pn="section-6.2.4">
          <name slugifiedName="name-media-type-of-defining-reso">Media Type of Defining Resource</name>
          <t indent="0" pn="section-6.2.4-1">The defining resource for entity domain type "ane" <bcp14>MUST</bcp14> be a property map, i.e.,
the media type of defining resources is:</t>
          <artwork name="" type="" align="left" alt="" pn="section-6.2.4-2">
application/alto-propmap+json
</artwork>
          <t indent="0" pn="section-6.2.4-3">Specifically, for ephemeral ANEs that appear in a Path Vector response, their
entity domain names <bcp14>MUST</bcp14> be exactly ".ane", and the defining resource of these
ANEs is the property map part of the multipart response. Meanwhile, for any
persistent ANE whose defining resource is a property map resource, its entity
domain name <bcp14>MUST</bcp14> have the format of "PROPMAP.ane", where PROPMAP is the resource
ID of the defining resource. Persistent entities are "persistent" because
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 indent="0" pn="section-6.2.4-4">For example, the defining resource of an ephemeral ANE whose entity identifier
is ".ane:NET1" is the property map part that contains this identifier. The
defining resource of a persistent ANE whose entity identifier is
"dc-props.ane:DC1" is the property map with the resource ID "dc-props".</t>
        </section>
      </section>
      <section anchor="ane-prop-name-spec" numbered="true" toc="include" removeInRFC="false" pn="section-6.3">
        <name slugifiedName="name-ane-property-name">ANE Property Name</name>
        <t indent="0" pn="section-6.3-1">An ANE property name is encoded as a JSON string with the same format as that of an
entity property name (<xref target="RFC9240" sectionFormat="of" section="5.2.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9240#section-5.2.2" derivedContent="RFC9240"/>).</t>
      </section>
      <section anchor="initial-ane-property-types" numbered="true" toc="include" removeInRFC="false" pn="section-6.4">
        <name slugifiedName="name-initial-ane-property-types">Initial ANE Property Types</name>
        <t indent="0" pn="section-6.4-1">Two initial ANE property types are specified: "max-reservable-bandwidth" and
"persistent-entity-id".</t>
        <t indent="0" pn="section-6.4-2">Note that these property types do not depend on any information resources. As
such, the "EntityPropertyName" parameter <bcp14>MUST</bcp14> only have the EntityPropertyType part.</t>
        <section anchor="maxresbw" numbered="true" toc="include" removeInRFC="false" pn="section-6.4.1">
          <name slugifiedName="name-maximum-reservable-bandwidt">Maximum Reservable Bandwidth</name>
          <t indent="0" pn="section-6.4.1-1">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 <bcp14>MUST</bcp14> be encoded as a non-negative numerical cost
value as defined in
<xref target="RFC7285" sectionFormat="of" section="6.1.2.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7285#section-6.1.2.1" derivedContent="RFC7285"/>, and the unit is 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 <bcp14>MUST</bcp14> be interpreted as meaning that the property
is not defined for the ANE.</t>
          <t indent="0" pn="section-6.4.1-2">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" sectionFormat="of" derivedContent="NOVA"/>: the ALTO server
is part of a Software-Defined Networking (SDN) controller and exposes a list of traversed network elements
and associated link bandwidth to the client. The encoding in <xref target="NOVA" format="default" sectionFormat="of" derivedContent="NOVA"/> differs
from the Path Vector response defined in this document in that the Path Vector part
and property map part are placed in the same JSON object.</t>
          <t indent="0" pn="section-6.4.1-3">In such a framework, the ALTO server exposes resource
availability information (e.g., reservable bandwidth) to the ALTO client. How the client makes resource
requests based on the information, and how the resource allocation is 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" format="default" sectionFormat="of" derivedContent="INTENT-BASED-NETWORKING"/> or MPLS tunnels), which are
out of scope for this document.</t>
        </section>
        <section anchor="persistent-entity-id" numbered="true" toc="include" removeInRFC="false" pn="section-6.4.2">
          <name slugifiedName="name-persistent-entity-id">Persistent Entity ID</name>
          <t indent="0" pn="section-6.4.2-1">This document enables the discovery of a persistent ANE by exposing its
entity identifier as the persistent entity ID property of an ephemeral ANE in the path
vector response. The value of this property is encoded with the EntityID format defined in <xref target="RFC9240" sectionFormat="of" section="5.1.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9240#section-5.1.3" derivedContent="RFC9240"/>.</t>
          <t indent="0" pn="section-6.4.2-2">In this format, the entity ID combines:</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.4.2-3">
            <li pn="section-6.4.2-3.1">a defining information resource for the ANE on which a
"persistent-entity-id" is queried, which is the property map resource
defining the ANE as a persistent entity, together with the properties.</li>
            <li pn="section-6.4.2-3.2">the persistent name of the ANE in that property map.</li>
          </ul>
          <t indent="0" pn="section-6.4.2-4">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="include" removeInRFC="false" pn="section-6.4.3">
          <name slugifiedName="name-examples">Examples</name>
          <t indent="0" pn="section-6.4.3-1">To illustrate the use of "max-reservable-bandwidth", consider the following
network with 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", which represents the subnetwork with routers A, B, and C; and "ane2", which
represents the subnetwork with routers B, D, and E. The maximum reservable
bandwidth for "ane1" is 15 Mbps (using path 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="" pn="section-6.4.3-2">
                     20 Mbps  20 Mbps
          10 Mbps +---+   +---+    +---+
             /----| B |---| D |----| E |---- H2
       +---+/     +---+   +---+    +---+
H1 ----| A | 15 Mbps|
       +---+\     +---+
             \----| C |
          15 Mbps +---+
</artwork>
          <t indent="0" pn="section-6.4.3-3">To illustrate the use of "persistent-entity-id", consider the scenario in
<xref target="fig-se" format="default" sectionFormat="of" derivedContent="Figure 6"/>. As the life cycles of service edges are typically long, the service edges may
contain information that is not specific to the query. Such information can be
stored in an individual entity property map and can later be accessed by an ALTO
client.</t>
          <t indent="0" pn="section-6.4.3-4">For example, "ane1" in <xref target="fig-se-example" format="default" sectionFormat="of" derivedContent="Figure 7"/> represents the on-premise service edge
closest to host "a". Assume that the properties of the service edges are provided in
an entity property map called "se-props" and the ID of the on-premise service
edge is "9a0b55f7-7442-4d56-8a2c-b4cc6a8e3aa1"; the "persistent-entity-id" 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="include" removeInRFC="false" pn="section-6.5">
        <name slugifiedName="name-path-vector-cost-type-2">Path Vector Cost Type</name>
        <t indent="0" pn="section-6.5-1">This document defines a new cost type, which is referred to as the Path Vector
cost type. An ALTO server <bcp14>MUST</bcp14> offer this cost type if it supports the extension
defined in this document.</t>
        <section anchor="metric-spec" numbered="true" toc="include" removeInRFC="false" pn="section-6.5.1">
          <name slugifiedName="name-cost-metric-ane-path">Cost Metric: "ane-path"</name>
          <t indent="0" pn="section-6.5.1-1">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 indent="0" pn="section-6.5.1-2">An ALTO client <bcp14>MUST</bcp14> interpret the Path Vector as if the traffic between a source
and a destination logically traverses the ANEs in the same order as they appear
in the Path Vector.</t>
          <t indent="0" pn="section-6.5.1-3">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" sectionFormat="of" derivedContent="Section 6.5.2"/>) <bcp14>MUST</bcp14> return as the cost value a JSON array of data type ANEName, and the
client <bcp14>MUST</bcp14> also check that each element contained in the array is an ANEName
(<xref target="ane-name-spec" format="default" sectionFormat="of" derivedContent="Section 6.1"/>). Otherwise, the client <bcp14>MUST</bcp14> discard the response and <bcp14>SHOULD</bcp14>
follow the guidance in <xref target="RFC7285" sectionFormat="of" section="8.3.4.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7285#section-8.3.4.3" derivedContent="RFC7285"/> to handle the error.</t>
        </section>
        <section anchor="mode-spec" numbered="true" toc="include" removeInRFC="false" pn="section-6.5.2">
          <name slugifiedName="name-cost-mode-array">Cost Mode: "array"</name>
          <t indent="0" pn="section-6.5.2-1">The cost mode "array" indicates that every cost value in the response body of a
(filtered) cost map or an Endpoint Cost Service <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"
cost mode when combined with cost metrics other than "ane-path".</t>
        </section>
      </section>
      <section anchor="part-rid-spec" numbered="true" toc="include" removeInRFC="false" pn="section-6.6">
        <name slugifiedName="name-part-resource-id-and-part-c">Part Resource ID and Part Content ID</name>
        <t indent="0" pn="section-6.6-1">A Part Resource ID is encoded as a JSON string with the same format as that of the
type ResourceID (<xref target="RFC7285" sectionFormat="of" section="10.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7285#section-10.2" derivedContent="RFC7285"/>).</t>
        <t indent="0" pn="section-6.6-2">Even though the "client-id" assigned to a Path Vector request and the Part
Resource ID <bcp14>MAY</bcp14> contain up to 64 characters by their own definition, their
concatenation (see <xref target="ref-partmsg-design" format="default" sectionFormat="of" derivedContent="Section 5.3.2"/>) <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 <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 indent="0" pn="section-6.6-3">A Part Content ID conforms to the format of "msg-id" as specified in
<xref target="RFC2387" format="default" sectionFormat="of" derivedContent="RFC2387"/> and <xref target="RFC5322" format="default" sectionFormat="of" derivedContent="RFC5322"/>. Specifically, it has the following format:</t>
        <t indent="0" pn="section-6.6-4">"&lt;" PART-RESOURCE-ID "@" DOMAIN-NAME "&gt;"</t>
        <dl indent="3" newline="false" spacing="normal" pn="section-6.6-5">
          <dt pn="section-6.6-5.1">
PART-RESOURCE-ID:  </dt>
          <dd pn="section-6.6-5.2">
            <t indent="0" pn="section-6.6-5.2.1">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>
          </dd>
          <dt pn="section-6.6-5.3">
DOMAIN-NAME:  </dt>
          <dd pn="section-6.6-5.4">
            <t indent="0" pn="section-6.6-5.4.1">DOMAIN-NAME has the same format as "dot-atom-text" as specified in
<xref target="RFC5322" sectionFormat="of" section="3.2.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5322#section-3.2.3" derivedContent="RFC5322"/>. It must be the domain name of the ALTO server.</t>
          </dd>
        </dl>
      </section>
    </section>
    <section anchor="Services" numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-specification-service-exten">Specification: Service Extensions</name>
      <section anchor="notation" numbered="true" toc="include" removeInRFC="false" pn="section-7.1">
        <name slugifiedName="name-notation">Notation</name>
        <t indent="0" pn="section-7.1-1">This document uses the same syntax and notation as those introduced in <xref target="RFC7285" sectionFormat="of" section="8.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7285#section-8.2" derivedContent="RFC7285"/> to specify the extensions to existing ALTO resources and
services.</t>
      </section>
      <section anchor="pvcm-spec" numbered="true" toc="include" removeInRFC="false" pn="section-7.2">
        <name slugifiedName="name-multipart-filtered-cost-map">Multipart Filtered Cost Map for Path Vector</name>
        <t indent="0" pn="section-7.2-1">This document introduces a new ALTO resource called the "multipart filtered cost map
resource", which allows an ALTO server to provide other ALTO resources associated
with the cost map resource in the same response.</t>
        <section anchor="media-type" numbered="true" toc="include" removeInRFC="false" pn="section-7.2.1">
          <name slugifiedName="name-media-type">Media Type</name>
          <t indent="0" pn="section-7.2.1-1">The media type of the multipart filtered cost map resource is
"multipart/related", and the required "type" parameter <bcp14>MUST</bcp14> have
a value of "application/alto-costmap+json".</t>
        </section>
        <section anchor="http-method" numbered="true" toc="include" removeInRFC="false" pn="section-7.2.2">
          <name slugifiedName="name-http-method">HTTP Method</name>
          <t indent="0" pn="section-7.2.2-1">The multipart filtered cost map is requested using the HTTP POST method.</t>
        </section>
        <section anchor="pvcm-accept" numbered="true" toc="include" removeInRFC="false" pn="section-7.2.3">
          <name slugifiedName="name-accept-input-parameters">Accept Input Parameters</name>
          <t indent="0" pn="section-7.2.3-1">The input parameters of the multipart filtered cost map are supplied in the body
of an HTTP POST request. This document extends the input parameters to a
filtered cost map, which is defined as a JSON object of type
ReqFilteredCostMap in <xref target="RFC8189" sectionFormat="of" section="4.1.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8189#section-4.1.2" derivedContent="RFC8189"/>, 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="" pn="section-7.2.3-2">
object {
  [EntityPropertyName ane-property-names&lt;0..*&gt;;]
} PVReqFilteredCostMap : ReqFilteredCostMap;
</artwork>
          <t indent="0" pn="section-7.2.3-3">with field:</t>
          <dl indent="3" newline="false" spacing="normal" pn="section-7.2.3-4">
            <dt pn="section-7.2.3-4.1">
ane-property-names:  </dt>
            <dd pn="section-7.2.3-4.2">
              <t indent="0" pn="section-7.2.3-4.2.1">This field provides a list of selected ANE properties to be included in the response. Each
property in this list <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" sectionFormat="of" derivedContent="Section 7.2.4"/>). If the
field is not present, it <bcp14>MUST</bcp14> be interpreted as an empty list.</t>
            </dd>
          </dl>
          <t indent="0" pn="section-7.2.3-5">Example: Consider the network in <xref target="fig-dumbbell" format="default" sectionFormat="of" derivedContent="Figure 1"/>. If an ALTO client wants to
query the "max-reservable-bandwidth" setting between PID1 and PID2, it can submit the
following request.</t>
          <sourcecode name="" type="http-message" markers="false" pn="section-7.2.3-6">
   POST /costmap/pv HTTP/1.1
   Host: alto.example.com
   Accept: multipart/related;type=application/alto-costmap+json,
           application/alto-error+json
   Content-Length: 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" ]
   }
</sourcecode>
        </section>
        <section anchor="pvcm-cap" numbered="true" toc="include" removeInRFC="false" pn="section-7.2.4">
          <name slugifiedName="name-capabilities">Capabilities</name>
          <t indent="0" pn="section-7.2.4-1">The multipart filtered cost map resource extends the capabilities defined
in <xref target="RFC8189" sectionFormat="of" section="4.1.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8189#section-4.1.1" derivedContent="RFC8189"/>. The capabilities are defined by a JSON
object of type PVFilteredCostMapCapabilities:</t>
          <artwork name="" type="" align="left" alt="" pn="section-7.2.4-2">
object {
  [EntityPropertyName ane-property-names&lt;0..*&gt;;]
} PVFilteredCostMapCapabilities : FilteredCostMapCapabilities;
</artwork>
          <t indent="0" pn="section-7.2.4-3">with field:</t>
          <dl indent="3" newline="false" spacing="normal" pn="section-7.2.4-4">
            <dt pn="section-7.2.4-4.1">
ane-property-names:  </dt>
            <dd pn="section-7.2.4-4.2">
              <t indent="0" pn="section-7.2.4-4.2.1">This field provides a list of ANE properties that can be returned. If the field is not
present, it <bcp14>MUST</bcp14> be interpreted as an empty list, indicating that the ALTO server
cannot provide any ANE properties.</t>
            </dd>
          </dl>
          <t indent="0" pn="section-7.2.4-5">This extension also introduces additional restrictions for the following fields:</t>
          <dl indent="3" newline="false" spacing="normal" pn="section-7.2.4-6">
            <dt pn="section-7.2.4-6.1">
cost-type-names:  </dt>
            <dd pn="section-7.2.4-6.2">
              <t indent="0" pn="section-7.2.4-6.2.1">The "cost-type-names" field <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 <bcp14>MUST</bcp14> be defined in the "cost-types" of the IRD's "meta" field.</t>
            </dd>
            <dt pn="section-7.2.4-6.3">
cost-constraints:  </dt>
            <dd pn="section-7.2.4-6.4">
              <t indent="0" pn="section-7.2.4-6.4.1">If the "cost-type-names" field includes the Path Vector cost type,
the "cost-constraints" field <bcp14>MUST</bcp14> be either "false" or not present,
unless specifically
instructed by a future document.</t>
            </dd>
            <dt pn="section-7.2.4-6.5">
testable-cost-type-names (<xref target="RFC8189" sectionFormat="of" section="4.1.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8189#section-4.1.1" derivedContent="RFC8189"/>):  </dt>
            <dd pn="section-7.2.4-6.6">
              <t indent="0" pn="section-7.2.4-6.6.1">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 <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="include" removeInRFC="false" pn="section-7.2.5">
          <name slugifiedName="name-uses">Uses</name>
          <t indent="0" pn="section-7.2.5-1">This member <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 <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="include" removeInRFC="false" pn="section-7.2.6">
          <name slugifiedName="name-response">Response</name>
          <t indent="0" pn="section-7.2.6-1">The response <bcp14>MUST</bcp14> indicate an error, using ALTO Protocol error handling as
defined in <xref target="RFC7285" sectionFormat="of" section="8.5" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7285#section-8.5" derivedContent="RFC7285"/>, if the request is invalid.</t>
          <t indent="0" pn="section-7.2.6-2">The "Content-Type" header field of the response <bcp14>MUST</bcp14> be "multipart/related" as defined
by <xref target="RFC2387" format="default" sectionFormat="of" derivedContent="RFC2387"/>, with the following parameters:</t>
          <dl indent="3" newline="false" spacing="normal" pn="section-7.2.6-3">
            <dt pn="section-7.2.6-3.1">
type:  </dt>
            <dd pn="section-7.2.6-3.2">
              <t indent="0" pn="section-7.2.6-3.2.1">The "type" parameter is mandatory and <bcp14>MUST</bcp14> be "application/alto-costmap+json". Note
that <xref target="RFC2387" format="default" sectionFormat="of" derivedContent="RFC2387"/> permits parameters both with and without double quotes.</t>
            </dd>
            <dt pn="section-7.2.6-3.3">
start:  </dt>
            <dd pn="section-7.2.6-3.4">
              <t indent="0" pn="section-7.2.6-3.4.1">The "start" parameter is as defined in <xref target="RFC2387" format="default" sectionFormat="of" derivedContent="RFC2387"/> and is optional.
If present, it <bcp14>MUST</bcp14> have the same value as the "Content-ID" header field of the Path
Vector part.</t>
            </dd>
            <dt pn="section-7.2.6-3.5">
boundary:  </dt>
            <dd pn="section-7.2.6-3.6">
              <t indent="0" pn="section-7.2.6-3.6.1">The "boundary" parameter is as defined in <xref target="RFC2046" sectionFormat="of" section="5.1.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc2046#section-5.1.1" derivedContent="RFC2046"/> and is mandatory.</t>
            </dd>
          </dl>
          <t indent="0" pn="section-7.2.6-4">The body of the response <bcp14>MUST</bcp14> consist of two parts:</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7.2.6-5">
            <li pn="section-7.2.6-5.1">
              <t indent="0" pn="section-7.2.6-5.1.1">The Path Vector part <bcp14>MUST</bcp14> include "Content-ID" and "Content-Type" in its
header. The "Content-Type" <bcp14>MUST</bcp14> be "application/alto-costmap+json".
The value of "Content-ID" <bcp14>MUST</bcp14> have the same format as the Part Content ID as
specified in <xref target="part-rid-spec" format="default" sectionFormat="of" derivedContent="Section 6.6"/>.  </t>
              <t indent="0" pn="section-7.2.6-5.1.2">
The body of the Path Vector part <bcp14>MUST</bcp14> be a JSON object with the same format as that
defined in <xref target="RFC7285" sectionFormat="of" section="11.2.3.6" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7285#section-11.2.3.6" derivedContent="RFC7285"/> when the "cost-type" field is
present in the input parameters and <bcp14>MUST</bcp14> be a JSON object with the same format
as that defined in <xref target="RFC8189" sectionFormat="of" section="4.1.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8189#section-4.1.3" derivedContent="RFC8189"/> if the "multi-cost-types" field is
present. The JSON object <bcp14>MUST</bcp14> include the
"vtag" field in the "meta" field, which provides the version tag of the
returned CostMapData object. The resource ID of the version tag <bcp14>MUST</bcp14> follow the
format of  </t>
              <sourcecode name="" type="rbnf" markers="false" pn="section-7.2.6-5.1.3">
resource-id '.' part-resource-id
</sourcecode>
              <t indent="0" pn="section-7.2.6-5.1.4">
where "resource-id" is the resource ID of the Path Vector resource and
"part-resource-id" has the same value as the PART-RESOURCE-ID in the
"Content-ID" of the Path Vector part.
The "meta" field <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 resource in the IRD.</t>
            </li>
            <li pn="section-7.2.6-5.2">
              <t indent="0" pn="section-7.2.6-5.2.1">The entity property map part <bcp14>MUST</bcp14> also include "Content-ID" and
"Content-Type" in its header. The "Content-Type" <bcp14>MUST</bcp14> be
"application/alto-propmap+json". The value of "Content-ID" <bcp14>MUST</bcp14> have the same
format as the Part Content ID as specified in <xref target="part-rid-spec" format="default" sectionFormat="of" derivedContent="Section 6.6"/>.  </t>
              <t indent="0" pn="section-7.2.6-5.2.2">
The body of the entity property map part is a JSON object with the same
format as that defined in <xref target="RFC9240" sectionFormat="of" section="7.6" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9240#section-7.6" derivedContent="RFC9240"/>. The
JSON object <bcp14>MUST</bcp14> include the "dependent-vtags" field in the "meta" field. The
value of the "dependent-vtags" field <bcp14>MUST</bcp14> be an array of VersionTag objects as
defined by <xref target="RFC7285" sectionFormat="of" section="10.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7285#section-10.3" derivedContent="RFC7285"/>. The "vtag" of the Path Vector part <bcp14>MUST</bcp14>
be included in the "dependent-vtags" field. If "persistent-entity-id" is requested, the
version tags of the dependent resources that may expose the entities in the
response <bcp14>MUST</bcp14> also be included.  </t>
              <t indent="0" pn="section-7.2.6-5.2.3">
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
<xref target="RFC9240" sectionFormat="of" section="5.1.2.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9240#section-5.1.2.3" derivedContent="RFC9240"/>. The EntityProps object for each ANE has one
member for each property that is both 1) associated with the 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 <bcp14>MUST</bcp14> be present and the value <bcp14>MUST</bcp14> be an empty object
({}).</t>
            </li>
          </ul>
          <t indent="0" pn="section-7.2.6-6">A complete and valid response <bcp14>MUST</bcp14> include both the Path Vector part and the
property map part in the multipart message. If any part is <strong>not</strong> present, the
client <bcp14>MUST</bcp14> discard the received information and send another request if
necessary.</t>
          <t indent="0" pn="section-7.2.6-7">The Path Vector part, whose media type is the same as the "type" parameter of the multipart response message, is the root body part as defined in
<xref target="RFC2387" format="default" sectionFormat="of" derivedContent="RFC2387"/>. 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
<bcp14>RECOMMENDED</bcp14> that the parts arrive in the same order as they are processed, i.e.,
the Path Vector part is always placed as the first part, followed by the property
map part. When doing so, an ALTO server <bcp14>MAY</bcp14> choose not to set the "start"
parameter, which implies that the first part is the object root.</t>
          <t indent="0" pn="section-7.2.6-8">Example: Consider the network in <xref target="fig-dumbbell" format="default" sectionFormat="of" derivedContent="Figure 1"/>. The response to the example
request in <xref target="pvcm-accept" format="default" sectionFormat="of" derivedContent="Section 7.2.3"/> is as follows, where "ANE1" represents the
aggregation of all the switches in the network.</t>
          <sourcecode name="" type="http-message" markers="false" pn="section-7.2.6-9">
HTTP/1.1 200 OK
Content-Length: 911
Content-Type: multipart/related; boundary=example-1;
              type=application/alto-costmap+json

--example-1
Content-ID: &lt;costmap@alto.example.com&gt;
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" ] }
  }
}
--example-1
Content-ID: &lt;propmap@alto.example.com&gt;
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 }
  }
}
--example-1
</sourcecode>
        </section>
      </section>
      <section anchor="pvecs-spec" numbered="true" toc="include" removeInRFC="false" pn="section-7.3">
        <name slugifiedName="name-multipart-endpoint-cost-ser">Multipart Endpoint Cost Service for Path Vector</name>
        <t indent="0" pn="section-7.3-1">This document introduces a new ALTO resource called the "multipart Endpoint Cost
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="include" removeInRFC="false" pn="section-7.3.1">
          <name slugifiedName="name-media-type-2">Media Type</name>
          <t indent="0" pn="section-7.3.1-1">The media type of the multipart Endpoint Cost Service resource is
"multipart/related", and the required "type" parameter <bcp14>MUST</bcp14> have
a value of "application/alto-endpointcost+json".</t>
        </section>
        <section anchor="http-method-1" numbered="true" toc="include" removeInRFC="false" pn="section-7.3.2">
          <name slugifiedName="name-http-method-2">HTTP Method</name>
          <t indent="0" pn="section-7.3.2-1">The multipart Endpoint Cost Service resource is requested using the HTTP POST method.</t>
        </section>
        <section anchor="pvecs-accept" numbered="true" toc="include" removeInRFC="false" pn="section-7.3.3">
          <name slugifiedName="name-accept-input-parameters-2">Accept Input Parameters</name>
          <t indent="0" pn="section-7.3.3-1">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 ReqEndpointCostMap in <xref target="RFC8189" sectionFormat="of" section="4.2.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8189#section-4.2.2" derivedContent="RFC8189"/>, with a data
format indicated by the media type "application/alto-endpointcostparams+json",
which is a JSON object of type PVReqEndpointCostMap:</t>
          <artwork name="" type="" align="left" alt="" pn="section-7.3.3-2">
object {
  [EntityPropertyName ane-property-names&lt;0..*&gt;;]
} PVReqEndpointCostMap : ReqEndpointCostMap;
</artwork>
          <t indent="0" pn="section-7.3.3-3">with field:</t>
          <dl indent="3" newline="false" spacing="normal" pn="section-7.3.3-4">
            <dt pn="section-7.3.3-4.1">
ane-property-names:  </dt>
            <dd pn="section-7.3.3-4.2">
              <t indent="0" pn="section-7.3.3-4.2.1">This document defines the "ane-property-names" field in PVReqEndpointCostMap as being the
same as in PVReqFilteredCostMap. See <xref target="pvcm-accept" format="default" sectionFormat="of" derivedContent="Section 7.2.3"/>.</t>
            </dd>
          </dl>
          <t indent="0" pn="section-7.3.3-5">Example: Consider the network in <xref target="fig-dumbbell" format="default" sectionFormat="of" derivedContent="Figure 1"/>. If an ALTO client wants to
query the "max-reservable-bandwidth" setting between "eh1" and "eh2", it can submit the
following request.</t>
          <sourcecode name="" type="http-message" markers="false" pn="section-7.3.3-6">
POST /ecs/pv HTTP/1.1
Host: alto.example.com
Accept: multipart/related;type=application/alto-endpointcost+json,
        application/alto-error+json
Content-Length: 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" ]
}
</sourcecode>
        </section>
        <section anchor="pvecs-cap" numbered="true" toc="include" removeInRFC="false" pn="section-7.3.4">
          <name slugifiedName="name-capabilities-2">Capabilities</name>
          <t indent="0" pn="section-7.3.4-1">The capabilities of the multipart Endpoint Cost Service resource are defined by
a JSON object of type PVEndpointCostCapabilities, which is defined as being the same
as PVFilteredCostMapCapabilities. See <xref target="pvcm-cap" format="default" sectionFormat="of" derivedContent="Section 7.2.4"/>.</t>
        </section>
        <section anchor="uses-1" numbered="true" toc="include" removeInRFC="false" pn="section-7.3.5">
          <name slugifiedName="name-uses-2">Uses</name>
          <t indent="0" pn="section-7.3.5-1">If this resource supports "persistent-entity-id", it <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="include" removeInRFC="false" pn="section-7.3.6">
          <name slugifiedName="name-response-2">Response</name>
          <t indent="0" pn="section-7.3.6-1">The response <bcp14>MUST</bcp14> indicate an error, using ALTO Protocol error handling as
defined in <xref target="RFC7285" sectionFormat="of" section="8.5" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7285#section-8.5" derivedContent="RFC7285"/>, if the request is invalid.</t>
          <t indent="0" pn="section-7.3.6-2">The "Content-Type" header field of the response <bcp14>MUST</bcp14> be "multipart/related" as defined
by <xref target="RFC2387" format="default" sectionFormat="of" derivedContent="RFC2387"/>, with the following parameters:</t>
          <dl indent="3" newline="false" spacing="normal" pn="section-7.3.6-3">
            <dt pn="section-7.3.6-3.1">
type:  </dt>
            <dd pn="section-7.3.6-3.2">
              <t indent="0" pn="section-7.3.6-3.2.1">The "type" parameter <bcp14>MUST</bcp14> be "application/alto-endpointcost+json" and is mandatory.</t>
            </dd>
            <dt pn="section-7.3.6-3.3">
start:  </dt>
            <dd pn="section-7.3.6-3.4">
              <t indent="0" pn="section-7.3.6-3.4.1">The "start" parameter is as defined in <xref target="pvcm-resp" format="default" sectionFormat="of" derivedContent="Section 7.2.6"/>.</t>
            </dd>
            <dt pn="section-7.3.6-3.5">
boundary:  </dt>
            <dd pn="section-7.3.6-3.6">
              <t indent="0" pn="section-7.3.6-3.6.1">The "boundary" parameter is as defined in <xref target="RFC2046" sectionFormat="of" section="5.1.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc2046#section-5.1.1" derivedContent="RFC2046"/> and is mandatory.</t>
            </dd>
          </dl>
          <t indent="0" pn="section-7.3.6-4">The body of the response <bcp14>MUST</bcp14> consist of two parts:</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7.3.6-5">
            <li pn="section-7.3.6-5.1">
              <t indent="0" pn="section-7.3.6-5.1.1">The Path Vector part <bcp14>MUST</bcp14> include "Content-ID" and "Content-Type" in its
header.
The "Content-Type" <bcp14>MUST</bcp14> be "application/alto-endpointcost+json".
The value of "Content-ID" <bcp14>MUST</bcp14> have the same format as the Part Content ID as
specified in <xref target="part-rid-spec" format="default" sectionFormat="of" derivedContent="Section 6.6"/>.  </t>
              <t indent="0" pn="section-7.3.6-5.1.2">
The body of the Path Vector part <bcp14>MUST</bcp14> be a JSON object with the same format as that
defined in <xref target="RFC7285" sectionFormat="of" section="11.5.1.6" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7285#section-11.5.1.6" derivedContent="RFC7285"/> when the "cost-type" field is
present in the input parameters and <bcp14>MUST</bcp14> be a JSON object with the same format
as that defined in <xref target="RFC8189" sectionFormat="of" section="4.2.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8189#section-4.2.3" derivedContent="RFC8189"/> if the "multi-cost-types" field is
present. The JSON object <bcp14>MUST</bcp14> include the
"vtag" field in the "meta" field, which provides the version tag of the returned
EndpointCostMapData object. The resource ID of the version tag <bcp14>MUST</bcp14> follow the format of  </t>
              <sourcecode name="" type="rbnf" markers="false" pn="section-7.3.6-5.1.3">
resource-id '.' part-resource-id
</sourcecode>
              <t indent="0" pn="section-7.3.6-5.1.4">
where "resource-id" is the resource ID of the Path Vector resource and
"part-resource-id" has the same value as the PART-RESOURCE-ID in the "Content-ID"
of the Path Vector part.</t>
            </li>
            <li pn="section-7.3.6-5.2">
              <t indent="0" pn="section-7.3.6-5.2.1">The entity property map part <bcp14>MUST</bcp14> also include "Content-ID" and
"Content-Type" in its header. The "Content-Type" <bcp14>MUST</bcp14> be
"application/alto-propmap+json".
The value of "Content-ID" <bcp14>MUST</bcp14> have the same format as the Part Content ID as
specified in <xref target="part-rid-spec" format="default" sectionFormat="of" derivedContent="Section 6.6"/>.  </t>
              <t indent="0" pn="section-7.3.6-5.2.2">
The body of the entity property map part <bcp14>MUST</bcp14> be a JSON object with the same
format as that defined in <xref target="RFC9240" sectionFormat="of" section="7.6" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9240#section-7.6" derivedContent="RFC9240"/>. The
JSON object <bcp14>MUST</bcp14> include the "dependent-vtags" field in the "meta" field. The
value of the "dependent-vtags" field <bcp14>MUST</bcp14> be an array of VersionTag objects as
defined by <xref target="RFC7285" sectionFormat="of" section="10.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7285#section-10.3" derivedContent="RFC7285"/>. The "vtag" of the Path Vector part <bcp14>MUST</bcp14>
be included in the "dependent-vtags" field. If "persistent-entity-id" is requested, the
version tags of the dependent resources that may expose the entities in the
response <bcp14>MUST</bcp14> also be included.  </t>
              <t indent="0" pn="section-7.3.6-5.2.3">
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
<xref target="RFC9240" sectionFormat="of" section="5.1.2.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9240#section-5.1.2.3" derivedContent="RFC9240"/>. The EntityProps object for each ANE has one
member for each property that is both 1) associated with the 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 <bcp14>MUST</bcp14> be present and the value <bcp14>MUST</bcp14> be an empty object
({}).</t>
            </li>
          </ul>
          <t indent="0" pn="section-7.3.6-6">A complete and valid response <bcp14>MUST</bcp14> include both the Path Vector part and the
property map part in the multipart message. If any part is <strong>not</strong> present, the
client <bcp14>MUST</bcp14> discard the received information and send another request if
necessary.</t>
          <t indent="0" pn="section-7.3.6-7">The Path Vector part, whose media type is the same as the "type" parameter of the multipart response message, is the root body part as defined in
<xref target="RFC2387" format="default" sectionFormat="of" derivedContent="RFC2387"/>. 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
<bcp14>RECOMMENDED</bcp14> that the parts arrive in the same order as they are processed, i.e.,
the Path Vector part is always placed as the first part, followed by the property
map part. When doing so, an ALTO server <bcp14>MAY</bcp14> choose not to set the "start"
parameter, which implies that the first part is the object root.</t>
          <t indent="0" pn="section-7.3.6-8">Example: Consider the network in <xref target="fig-dumbbell" format="default" sectionFormat="of" derivedContent="Figure 1"/>. The response to the example
request in <xref target="pvecs-accept" format="default" sectionFormat="of" derivedContent="Section 7.3.3"/> is as follows.</t>
          <sourcecode name="" type="http-message" markers="false" pn="section-7.3.6-9">
HTTP/1.1 200 OK
Content-Length: 899
Content-Type: multipart/related; boundary=example-1;
              type=application/alto-endpointcost+json

--example-1
Content-ID: &lt;ecs@alto.example.com&gt;
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" ] }
  }
}
--example-1
Content-ID: &lt;propmap@alto.example.com&gt;
Content-Type: application/alto-propmap+json

{
  "meta": {
    "dependent-vtags": [
      {
        "resource-id": "ecs-pv.ecs",
        "tag": "ec137bb78118468c853d5b622ac003f1"
      }
    ]
  },
  "property-map": {
    ".ane:ANE1": { "max-reservable-bandwidth": 100000000 }
  }
}
--example-1
</sourcecode>
        </section>
      </section>
    </section>
    <section anchor="Examples" numbered="true" toc="include" removeInRFC="false" pn="section-8">
      <name slugifiedName="name-examples-2">Examples</name>
      <t indent="0" pn="section-8-1">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="include" removeInRFC="false" pn="section-8.1">
        <name slugifiedName="name-sample-setup">Sample Setup</name>
        <t indent="0" pn="section-8.1-1"><xref target="fig-pe" format="default" sectionFormat="of" derivedContent="Figure 10"/> 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" align="left" suppress-title="false" pn="figure-10">
          <name slugifiedName="name-examples-of-ane-properties">Examples of ANE Properties</name>
          <artwork type="" align="center" name="" alt="" pn="section-8.1-2.1">
                                     ----- 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>
      </section>
      <section anchor="example-ird" numbered="true" toc="include" removeInRFC="false" pn="section-8.2">
        <name slugifiedName="name-information-resource-direct">Information Resource Directory</name>
        <t indent="0" pn="section-8.2-1">To give a comprehensive example of the extension defined in this document, we
consider the network in <xref target="fig-pe" format="default" sectionFormat="of" derivedContent="Figure 10"/>. Assume that the ALTO server provides the
following information resources:</t>
        <dl spacing="normal" indent="3" newline="false" pn="section-8.2-2">
          <dt pn="section-8.2-2.1">"my-default-networkmap":</dt>
          <dd pn="section-8.2-2.2">A network map resource that contains the PIDs in the
network.</dd>
          <dt pn="section-8.2-2.3">"filtered-cost-map-pv":</dt>
          <dd pn="section-8.2-2.4">A multipart filtered cost map resource for the Path Vector.  Exposes the "max-reservable-bandwidth" property for the PIDs in
"my-default-networkmap".</dd>
          <dt pn="section-8.2-2.5">"ane-props":</dt>
          <dd pn="section-8.2-2.6">A filtered entity property resource that exposes the
information for persistent ANEs in the network.</dd>
          <dt pn="section-8.2-2.7">"endpoint-cost-pv":</dt>
          <dd pn="section-8.2-2.8">A multipart Endpoint Cost Service for the Path Vector.  Exposes the "max-reservable-bandwidth" and "persistent-entity-id" properties.</dd>
          <dt pn="section-8.2-2.9">"update-pv":</dt>
          <dd pn="section-8.2-2.10">An update stream service that provides the incremental update
service for the "endpoint-cost-pv" service.</dd>
          <dt pn="section-8.2-2.11">"multicost-pv":</dt>
          <dd pn="section-8.2-2.12">A multipart Endpoint Cost Service with both the Multi-Cost extension and Path Vector extension enabled.</dd>
        </dl>
        <t indent="0" pn="section-8.2-3">Below is the IRD of the example ALTO server. To
enable the extension defined in this document, the Path Vector cost type
(<xref target="cost-type-spec" format="default" sectionFormat="of" derivedContent="Section 6.5"/>), represented by "path-vector" below,
is defined in the "cost-types" of the "meta" field and is
included in the "cost-type-names" of resources "filtered-cost-map-pv" and
"endpoint-cost-pv".</t>
        <sourcecode name="" type="json" markers="false" pn="section-8.2-4">
{
  "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" ]
    }
  }
}
</sourcecode>
      </section>
      <section anchor="multipart-filtered-cost-map" numbered="true" toc="include" removeInRFC="false" pn="section-8.3">
        <name slugifiedName="name-multipart-filtered-cost-map-2">Multipart Filtered Cost Map</name>
        <t indent="0" pn="section-8.3-1">The following examples demonstrate the request to the "filtered-cost-map-pv"
resource and the corresponding response.</t>
        <t indent="0" pn="section-8.3-2">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
the Path Vector and not the ANE properties.</t>
        <t indent="0" pn="section-8.3-3">The response consists of two parts:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-8.3-4">
          <li pn="section-8.3-4.1">The first part returns the array of data type ANEName
for each source and destination pair. There are two ANEs, where "L1" represents
interconnection link L1 and "L2" represents interconnection link L2.</li>
          <li pn="section-8.3-4.2">The second part returns the property map.  Note that the properties of the ANE entries are equal to the literal string "{}"
(see <xref target="RFC9240" sectionFormat="of" section="8.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9240#section-8.3" derivedContent="RFC9240"/>).</li>
        </ul>
        <sourcecode name="" type="http-message" markers="false" pn="section-8.3-5">
POST /costmap/pv HTTP/1.1
Host: alto.example.com
Accept: multipart/related;type=application/alto-costmap+json,
        application/alto-error+json
Content-Length: 163
Content-Type: application/alto-costmapfilter+json

{
  "cost-type": {
    "cost-mode": "array",
    "cost-metric": "ane-path"
  },
  "pids": {
    "srcs": [ "PID1" ],
    "dsts": [ "PID3", "PID4" ]
  }
}
</sourcecode>
        <sourcecode name="" type="http-message" markers="false" pn="section-8.3-6">
HTTP/1.1 200 OK
Content-Length: 952
Content-Type: multipart/related; boundary=example-1;
              type=application/alto-costmap+json

--example-1
Content-ID: &lt;costmap@alto.example.com&gt;
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: &lt;propmap@alto.example.com&gt;
Content-Type: application/alto-propmap+json

{
  "meta": {
    "dependent-vtags": [
      {
        "resource-id": "filtered-cost-map-pv.costmap",
        "tag": "d827f484cb66ce6df6b5077cb8562b0a"
      }
    ]
  },
  "property-map": {
    ".ane:L1": {},
    ".ane:L2": {}
  }
}
--example-1
</sourcecode>
      </section>
      <section anchor="example-ecspv" numbered="true" toc="include" removeInRFC="false" pn="section-8.4">
        <name slugifiedName="name-multipart-endpoint-cost-serv">Multipart Endpoint Cost Service Resource</name>
        <t indent="0" pn="section-8.4-1">The following examples demonstrate the request to the "endpoint-cost-pv"
resource and the corresponding response.</t>
        <t indent="0" pn="section-8.4-2">The request uses the "path-vector" cost type in the "cost-type" field and
queries the maximum reservable bandwidth ANE property and the persistent entity ID
property for two IPv4 source and destination pairs (192.0.2.34 -&gt; 192.0.2.2 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 indent="0" pn="section-8.4-3">The response consists of two parts:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-8.4-4">
          <li pn="section-8.4-4.1">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" sectionFormat="of" derivedContent="Figure 10"/>, flow
192.0.2.34 -&gt; 192.0.2.2 traverses NET3, L1, and 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, and NET3.</li>
          <li pn="section-8.4-4.2">The second part returns the requested properties of ANEs. Assume that NET1, NET2, and NET3 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 reservations on L1 and L2 and their "max-reservable-bandwidth" values are
the corresponding link capacity (10 Gbps for L1 and 15 Gbps for L2).</li>
        </ul>
        <t indent="0" pn="section-8.4-5">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 "ane-props". Thus, the
"persistent-entity-id" property values for NET1 and NET2 are "ane-props.ane:MEC1" and
"ane-props.ane:MEC2", respectively.</t>
        <sourcecode name="" type="http-message" markers="false" pn="section-8.4-6">
POST /endpointcost/pv HTTP/1.1
Host: alto.example.com
Accept: multipart/related;
        type=application/alto-endpointcost+json,
        application/alto-error+json
Content-Length: 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"
  ]
}
</sourcecode>
        <sourcecode name="" type="http-message" markers="false" pn="section-8.4-7">
HTTP/1.1 200 OK
Content-Length: 1508
Content-Type: multipart/related; boundary=example-2;
              type=application/alto-endpointcost+json

--example-2
Content-ID: &lt;ecs@alto.example.com&gt;
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: &lt;propmap@alto.example.com&gt;
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
    }
  }
}
--example-2
</sourcecode>
        <t indent="0" pn="section-8.4-8">In certain scenarios where the traversal order is not crucial, an ALTO server
implementation may choose not to strictly follow the physical traversal order
and may even obfuscate the order intentionally to preserve its own privacy or
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" 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;
the obfuscated response is as shown below. Note that the obfuscation of Path
Vector responses is implementation specific and is out of scope for this
document. Developers may refer to <xref target="Security" format="default" sectionFormat="of" derivedContent="Section 11"/> for further references.</t>
        <sourcecode name="" type="http-message" markers="false" pn="section-8.4-9">
HTTP/1.1 200 OK
Content-Length: 1333
Content-Type: multipart/related; boundary=example-2;
              type=application/alto-endpointcost+json

--example-2
Content-ID: &lt;ecs@alto.example.com&gt;
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: &lt;propmap@alto.example.com&gt;
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
    }
  }
}
--example-2
</sourcecode>
      </section>
      <section anchor="example-sse" numbered="true" toc="include" removeInRFC="false" pn="section-8.5">
        <name slugifiedName="name-incremental-updates">Incremental Updates</name>
        <t indent="0" pn="section-8.5-1">In this example, an ALTO client subscribes to the incremental update for the
multipart Endpoint Cost Service resource "endpoint-cost-pv".</t>
        <sourcecode name="" type="http-message" markers="false" pn="section-8.5-2">
POST /updates/pv HTTP/1.1
Host: alto.example.com
Accept: text/event-stream
Content-Type: application/alto-updatestreamparams+json
Content-Length: 120

{
  "add": {
    "ecspvsub1": {
      "resource-id": "endpoint-cost-pv",
      "input": &lt;ecs-input&gt;
    }
  }
}
</sourcecode>
        <t indent="0" pn="section-8.5-3">Based on the server-side process defined in <xref target="RFC8895" format="default" sectionFormat="of" derivedContent="RFC8895"/>, the ALTO server will
send the "control-uri" first, using a Server-Sent Event (SSE) followed by the full
response of the multipart message.</t>
        <sourcecode name="" type="http-message" markers="false" pn="section-8.5-4">
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: &lt;ecsmap@alto.example.com&gt;
data: Content-Type: application/alto-endpointcost+json
data:
data: &lt;endpoint-cost-map-entry&gt;
data: --example-3
data: Content-ID: &lt;propmap@alto.example.com&gt;
data: Content-Type: application/alto-propmap+json
data:
data: &lt;property-map-entry&gt;
data: --example-3--
</sourcecode>
        <t indent="0" pn="section-8.5-5">When the contents change, the ALTO server will publish the updates for each node
in this tree separately, based on <xref target="RFC8895" sectionFormat="of" section="6.7.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8895#section-6.7.3" derivedContent="RFC8895"/>.</t>
        <sourcecode name="" type="http-message" markers="false" pn="section-8.5-6">
event: application/merge-patch+json,
   ecspvsub1.ecsmap@alto.example.com
data: &lt;Merge patch for endpoint-cost-map-update&gt;

event: application/merge-patch+json,
   ecspvsub1.propmap@alto.example.com
data: &lt;Merge patch for property-map-update&gt;
</sourcecode>
      </section>
      <section anchor="multi-cost" numbered="true" toc="include" removeInRFC="false" pn="section-8.6">
        <name slugifiedName="name-multi-cost">Multi-Cost</name>
        <t indent="0" pn="section-8.6-1">The following examples demonstrate the request to the "multicost-pv" resource
and the corresponding response.</t>
        <t indent="0" pn="section-8.6-2">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 ANE property and the 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 indent="0" pn="section-8.6-3">The response consists of two parts:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-8.6-4">
          <li pn="section-8.6-4.1">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; and the second JSONValue is a JSONNumber, which is the value of the routing
cost.</li>
          <li pn="section-8.6-4.2">The second part contains a property map that maps the ANEs to their
requested properties.</li>
        </ul>
        <sourcecode name="" type="http-message" markers="false" pn="section-8.6-5">
POST /endpointcost/mcpv HTTP/1.1
Host: alto.example.com
Accept: multipart/related;
        type=application/alto-endpointcost+json,
        application/alto-error+json
Content-Length: 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"
  ]
}
</sourcecode>
        <sourcecode name="" type="http-message" markers="false" pn="section-8.6-6">
HTTP/1.1 200 OK
Content-Length: 1419
Content-Type: multipart/related; boundary=example-4;
              type=application/alto-endpointcost+json

--example-4
Content-ID: &lt;ecs@alto.example.com&gt;
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: &lt;propmap@alto.example.com&gt;
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
    }
  }
}
--example-4
</sourcecode>
      </section>
    </section>
    <section anchor="Compatibility" numbered="true" toc="include" removeInRFC="false" pn="section-9">
      <name slugifiedName="name-compatibility-with-other-al">Compatibility with Other ALTO Extensions</name>
      <section anchor="compatibility-with-legacy-alto-clientsservers" numbered="true" toc="include" removeInRFC="false" pn="section-9.1">
        <name slugifiedName="name-compatibility-with-legacy-a">Compatibility with Legacy ALTO Clients/Servers</name>
        <t indent="0" pn="section-9.1-1">The multipart filtered cost map resource and the multipart Endpoint Cost
Service resource have no 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 for the "Accept" input parameters, they have different
media types for responses. If the ALTO server provides these two types of
resources but the ALTO client does not support them, the ALTO client will
ignore the resources without incurring any incompatibility problems.</t>
      </section>
      <section anchor="compatibility-with-multi-cost-extension" numbered="true" toc="include" removeInRFC="false" pn="section-9.2">
        <name slugifiedName="name-compatibility-with-multi-co">Compatibility with Multi-Cost Extension</name>
        <t indent="0" pn="section-9.2-1">The extension defined in this document is compatible with the multi-cost
extension <xref target="RFC8189" format="default" sectionFormat="of" derivedContent="RFC8189"/>. 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 be
either "false" or not present, and the Path Vector cost type must be present
in the "cost-type-names" capability field but must not be present in the
"testable-cost-type-names" field, as specified in Sections <xref target="pvcm-cap" format="counter" sectionFormat="of" derivedContent="7.2.4"/> and <xref target="pvecs-cap" format="counter" sectionFormat="of" derivedContent="7.3.4"/>.</t>
      </section>
      <section anchor="compatibility-with-incremental-update" numbered="true" toc="include" removeInRFC="false" pn="section-9.3">
        <name slugifiedName="name-compatibility-with-incremen">Compatibility with Incremental Update Extension</name>
        <t indent="0" pn="section-9.3-1">This extension is compatible with the incremental update extension <xref target="RFC8895" format="default" sectionFormat="of" derivedContent="RFC8895"/>.
ALTO clients and servers <bcp14>MUST</bcp14> follow the specifications given in Sections <xref target="RFC8895" section="5.2" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8895#section-5.2" derivedContent="RFC8895"/> and <xref target="RFC8895" section="6.7.3" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8895#section-6.7.3" derivedContent="RFC8895"/> of <xref target="RFC8895" format="default" sectionFormat="of" derivedContent="RFC8895"/> to support incremental updates for a Path Vector
resource.</t>
      </section>
      <section anchor="compatibility-with-cost-calendar" numbered="true" toc="include" removeInRFC="false" pn="section-9.4">
        <name slugifiedName="name-compatibility-with-cost-cal">Compatibility with Cost Calendar Extension</name>
        <t indent="0" pn="section-9.4-1">The extension specified in this document is compatible with the Cost Calendar
extension <xref target="RFC8896" format="default" sectionFormat="of" derivedContent="RFC8896"/>. 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 indent="0" pn="section-9.4-2">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 <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 <bcp14>MAY</bcp14> use the same identifier.</t>
        <t indent="0" pn="section-9.4-3">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 part is not affected by the
Cost Calendar extension.</t>
        <t indent="0" pn="section-9.4-4">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 <xref target="SENSE" format="default" sectionFormat="of" derivedContent="SENSE"/> for details).</t>
      </section>
    </section>
    <section anchor="SecDisc" numbered="true" toc="include" removeInRFC="false" pn="section-10">
      <name slugifiedName="name-general-discussion">General Discussion</name>
      <section anchor="constraint-tests-for-general-cost-types" numbered="true" toc="include" removeInRFC="false" pn="section-10.1">
        <name slugifiedName="name-constraint-tests-for-genera">Constraint Tests for General Cost Types</name>
        <t indent="0" pn="section-10.1-1">The constraint test is a simple approach for querying the data. It allows users to
filter query results by specifying some boolean tests. This approach is
already used in the ALTO Protocol. ALTO clients are permitted to specify either the "constraints" test <xref target="RFC7285" format="default" sectionFormat="of" derivedContent="RFC7285"/> <xref target="RFC8189" format="default" sectionFormat="of" derivedContent="RFC8189"/> or the "or-constraints" test <xref target="RFC8189" format="default" sectionFormat="of" derivedContent="RFC8189"/> to better
filter the results.</t>
        <t indent="0" pn="section-10.1-2">However, the current syntax can only be used to test scalar cost types and
cannot easily express constraints on complex cost types, e.g., the Path Vector
cost type defined in this document.</t>
        <t indent="0" pn="section-10.1-3">In practice, developing a bespoke language for general-purpose boolean tests can
be a complex undertaking, and it is conceivable that such implementations already exist
(the authors have not done an exhaustive search to
determine whether such implementations exist). One avenue for developing such a
language may be to explore extending current query languages like XQuery
<xref target="XQuery" format="default" sectionFormat="of" derivedContent="XQuery"/> or JSONiq <xref target="JSONiq" format="default" sectionFormat="of" derivedContent="JSONiq"/> and integrating these with ALTO.</t>
        <t indent="0" pn="section-10.1-4">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="include" removeInRFC="false" pn="section-10.2">
        <name slugifiedName="name-general-multi-resource-quer">General Multi-Resource Query</name>
        <t indent="0" pn="section-10.2-1">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" sectionFormat="of" derivedContent="RFC8895"/> supports submitting multiple queries in a single 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 indent="0" pn="section-10.2-2">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 or
an Endpoint Cost Service, and a property map.  By packing multiple resources in a
single response, the implication is that servers may proactively push related
information resources to clients.</t>
        <t indent="0" pn="section-10.2-3">Thus, it is worth looking into extending the SSE mechanism as
used in the incremental update extension <xref target="RFC8895" format="default" sectionFormat="of" derivedContent="RFC8895"/>; or upgrading to HTTP/2
<xref target="RFC9113" format="default" sectionFormat="of" derivedContent="RFC9113"/> and HTTP/3 <xref target="RFC9114" format="default" sectionFormat="of" derivedContent="RFC9114"/>, which
provides the ability to multiplex queries and to allow servers to proactively send
related information resources.</t>
        <t indent="0" pn="section-10.2-4">Defining a general multi-resource query mechanism is out of scope for this
document.</t>
      </section>
    </section>
    <section anchor="Security" numbered="true" toc="include" removeInRFC="false" pn="section-11">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-11-1">This document is an extension of the base ALTO Protocol, so the security
considerations provided for the base ALTO Protocol <xref target="RFC7285" format="default" sectionFormat="of" derivedContent="RFC7285"/> fully apply when this
extension is provided by an ALTO server.</t>
      <t indent="0" pn="section-11-2">The Path Vector extension requires additional scrutiny of three security
considerations discussed in the base protocol: confidentiality of ALTO
information (<xref target="RFC7285" sectionFormat="of" section="15.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7285#section-15.3" derivedContent="RFC7285"/>), potential undesirable guidance from
authenticated ALTO information (<xref target="RFC7285" sectionFormat="of" section="15.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7285#section-15.2" derivedContent="RFC7285"/>), and availability
of ALTO services (<xref target="RFC7285" sectionFormat="of" section="15.5" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7285#section-15.5" derivedContent="RFC7285"/>).</t>
      <t indent="0" pn="section-11-3">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, 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 on the
ALTO service provider (e.g., they do not carry sensitive information) or 2) the ALTO
server and client have established a reliable trust relationship (e.g.,
they operate in the same administrative domain or are managed by business partners with
legal contracts).</t>
      <t indent="0" pn="section-11-4">Three risk types are identified in <xref target="RFC7285" sectionFormat="of" section="15.3.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7285#section-15.3.1" derivedContent="RFC7285"/>:</t>
      <ol spacing="normal" type="(%d)" indent="adaptive" start="1" pn="section-11-5">
  <li pn="section-11-5.1" derivedCounter="(1)">excess disclosure of the ALTO service provider's data to an unauthorized ALTO client,</li>
        <li pn="section-11-5.2" derivedCounter="(2)">disclosure of the ALTO service provider's data (e.g., network topology
information or endpoint addresses) to an unauthorized third party, and</li>
        <li pn="section-11-5.3" derivedCounter="(3)">excess retrieval of the ALTO service provider's data by collaborating ALTO
clients.</li>
      </ol>
      <t indent="0" pn="section-11-6">To mitigate these risks, an ALTO server <bcp14>MUST</bcp14> follow the guidelines in <xref target="RFC7285" sectionFormat="of" section="15.3.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7285#section-15.3.2" derivedContent="RFC7285"/>. Furthermore, an ALTO server <bcp14>MUST</bcp14> follow the
following additional protections strategies for risk types (1) and (3).</t>
      <t indent="0" pn="section-11-7">For risk type (1), an ALTO server <bcp14>MUST</bcp14> use the authentication methods specified
in <xref target="RFC7285" sectionFormat="of" section="15.3.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7285#section-15.3.2" derivedContent="RFC7285"/> to authenticate the identity of an ALTO client
and apply access control techniques to restrict the retrieval of sensitive Path Vector 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 regarding protection of confidentiality before
granting access to Path Vector services with sensitive information. Such
agreements may include legal contracts or Digital Rights Management (DRM)
techniques. Otherwise, the ALTO server <bcp14>MUST NOT</bcp14> offer Path Vector services that
carry sensitive information to the clients, unless the potential risks are
fully assessed and mitigated.</t>
      <t indent="0" pn="section-11-8">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, CDN Interconnections)
and/or when the granularity is coarse grained (e.g., when an ANE represents an
AS, a data center, or a WAN).
Otherwise, an ALTO server <bcp14>MUST</bcp14> use dynamic mappings from ephemeral ANE names to
underlying physical entities. Specifically, for the same physical entity, an
ALTO server <bcp14>SHOULD</bcp14> assign a different ephemeral ANE name when the entity appears
in the responses to different clients or even for different requests from the
same client. A <bcp14>RECOMMENDED</bcp14> assignment strategy is to generate ANE names from
random numbers.</t>
      <t indent="0" pn="section-11-9">Further, to protect the network topology from graph reconstruction (e.g.,
through isomorphic graph identification <xref target="BONDY" format="default" sectionFormat="of" derivedContent="BONDY"/>), the ALTO server <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 risk of undesirable guidance from
authenticated ALTO information (<xref target="RFC7285" sectionFormat="of" section="15.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7285#section-15.2" derivedContent="RFC7285"/>).</t>
      <t indent="0" pn="section-11-10">Thus, implementations of ALTO servers involving reduction or obfuscation of the
Path Vector information <bcp14>SHOULD</bcp14> consider reduction/obfuscation mechanisms that
can preserve the integrity of ALTO information -- for example, by using minimal
feasible region compression algorithms <xref target="NOVA" format="default" sectionFormat="of" derivedContent="NOVA"/> or obfuscation protocols
<xref target="RESA" format="default" sectionFormat="of" derivedContent="RESA"/> <xref target="MERCATOR" format="default" sectionFormat="of" derivedContent="MERCATOR"/>. However, these obfuscation methods are experimental, and their
practical applicability to the generic capability
provided by this extension has not been fully assessed. The ALTO server <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 indent="0" pn="section-11-11">For availability of ALTO services, an ALTO server should be cognizant that using a
Path Vector extension might introduce a new risk: frequent requests for Path
Vectors might consume intolerable amounts of server-side computation and
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 that provides the Path Vectors may become an entry point for denial-of-service
attacks on the availability of an ALTO server.</t>
      <t indent="0" pn="section-11-12">To mitigate this risk, an ALTO server may consider using such optimizations as
precomputation-and-projection mechanisms <xref target="MERCATOR" format="default" sectionFormat="of" derivedContent="MERCATOR"/> to reduce the overhead for
processing each query. An ALTO server may also protect itself from
malicious clients by monitoring client behavior and stopping service to
clients that exhibit suspicious behavior (e.g., sending requests at a high frequency).</t>
      <t indent="0" pn="section-11-13">The ALTO service providers must be aware that providing incremental updates of
"max-reservable-bandwidth" may provide information about other consumers of
the network. For example, a change in value may indicate that one or more
reservations have been made or changed. To mitigate this risk, an ALTO server
can batch the updates and/or add a random delay before publishing the updates.</t>
    </section>
    <section anchor="IANA" numbered="true" toc="include" removeInRFC="false" pn="section-12">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <section anchor="alto-cost-metrics-registry" numbered="true" toc="include" removeInRFC="false" pn="section-12.1">
        <name slugifiedName="name-alto-cost-metrics-registry">"ALTO Cost Metrics" Registry</name>
        <t indent="0" pn="section-12.1-1">This document registers a new entry in the "ALTO Cost Metrics" registry, per
<xref target="RFC7285" sectionFormat="of" section="14.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7285#section-14.2" derivedContent="RFC7285"/>. The new entry
is as shown below in <xref target="tbl-cost-metric" format="default" sectionFormat="of" derivedContent="Table 1"/>.</t>
        <table anchor="tbl-cost-metric" align="center" pn="table-1">
          <name slugifiedName="name-alto-cost-metrics-registry-2">"ALTO Cost Metrics" Registry</name>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Identifier</th>
              <th align="left" colspan="1" rowspan="1">Intended Semantics</th>
              <th align="left" colspan="1" rowspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">ane-path</td>
              <td align="left" colspan="1" rowspan="1">See <xref target="metric-spec" format="default" sectionFormat="of" derivedContent="Section 6.5.1"/></td>
              <td align="left" colspan="1" rowspan="1">RFC 9275</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="alto-cost-modes-registry" numbered="true" toc="include" removeInRFC="false" pn="section-12.2">
        <name slugifiedName="name-alto-cost-modes-registry">"ALTO Cost Modes" Registry</name>
        <t indent="0" pn="section-12.2-1">This document registers a new entry in the "ALTO Cost Modes" registry, per
<xref target="RFC9274" sectionFormat="of" section="5" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9274#section-5" derivedContent="RFC9274"/>. The new entry
is as shown below in <xref target="tbl-cost-mode" format="default" sectionFormat="of" derivedContent="Table 2"/>.</t>
        <table anchor="tbl-cost-mode" align="center" pn="table-2">
          <name slugifiedName="name-alto-cost-modes-registry-2">"ALTO Cost Modes" Registry</name>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Identifier</th>
              <th align="left" colspan="1" rowspan="1">Description</th>
              <th align="left" colspan="1" rowspan="1">Intended Semantics</th>
              <th align="left" colspan="1" rowspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">array</td>
              <td align="left" colspan="1" rowspan="1">Indicates that the cost value is a JSON array</td>
              <td align="left" colspan="1" rowspan="1">See <xref target="mode-spec" format="default" sectionFormat="of" derivedContent="Section 6.5.2"/></td>
              <td align="left" colspan="1" rowspan="1">RFC 9275</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="alto-entity-domain-types-registry" numbered="true" toc="include" removeInRFC="false" pn="section-12.3">
        <name slugifiedName="name-alto-entity-domain-types-re">"ALTO Entity Domain Types" Registry</name>
        <t indent="0" pn="section-12.3-1">This document registers a new entry in the "ALTO Entity Domain Types" registry, per
<xref target="RFC9240" sectionFormat="of" section="12.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9240#section-12.3" derivedContent="RFC9240"/>. The new entry
is as shown below in <xref target="tbl-entity-domain" format="default" sectionFormat="of" derivedContent="Table 3"/>.</t>
        <table anchor="tbl-entity-domain" align="center" pn="table-3">
          <name slugifiedName="name-alto-entity-domain-types-reg">"ALTO Entity Domain Types" Registry</name>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Identifier</th>
              <th align="left" colspan="1" rowspan="1">Entity Identifier Encoding</th>
              <th align="left" colspan="1" rowspan="1">Hierarchy and Inheritance</th>
              <th align="left" colspan="1" rowspan="1">Media Type of Defining Resource</th>
              <th align="left" colspan="1" rowspan="1">Mapping to ALTO Address Type</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">ane</td>
              <td align="left" colspan="1" rowspan="1">See <xref target="entity-address" format="default" sectionFormat="of" derivedContent="Section 6.2.2"/></td>
              <td align="left" colspan="1" rowspan="1">None</td>
              <td align="left" colspan="1" rowspan="1">application/alto-propmap+json</td>
              <td align="left" colspan="1" rowspan="1">false</td>
            </tr>
          </tbody>
        </table>
        <dl indent="3" newline="false" spacing="normal" pn="section-12.3-3">
          <dt pn="section-12.3-3.1">
Identifier:  </dt>
          <dd pn="section-12.3-3.2">
            <t indent="0" pn="section-12.3-3.2.1">See <xref target="domain-type" format="default" sectionFormat="of" derivedContent="Section 6.2.1"/>.</t>
          </dd>
          <dt pn="section-12.3-3.3">
Entity Identifier Encoding:  </dt>
          <dd pn="section-12.3-3.4">
            <t indent="0" pn="section-12.3-3.4.1">See <xref target="entity-address" format="default" sectionFormat="of" derivedContent="Section 6.2.2"/>.</t>
          </dd>
          <dt pn="section-12.3-3.5">
Hierarchy:  </dt>
          <dd pn="section-12.3-3.6">
            <t indent="0" pn="section-12.3-3.6.1">None</t>
          </dd>
          <dt pn="section-12.3-3.7">
Inheritance:  </dt>
          <dd pn="section-12.3-3.8">
            <t indent="0" pn="section-12.3-3.8.1">None</t>
          </dd>
          <dt pn="section-12.3-3.9">
Media Type of Defining Resource:  </dt>
          <dd pn="section-12.3-3.10">
            <t indent="0" pn="section-12.3-3.10.1">See <xref target="domain-defining" format="default" sectionFormat="of" derivedContent="Section 6.2.4"/>.</t>
          </dd>
          <dt pn="section-12.3-3.11">
Mapping to ALTO Address Type:  </dt>
          <dd pn="section-12.3-3.12">
            <t indent="0" pn="section-12.3-3.12.1">This entity type does not map to an ALTO address type.</t>
          </dd>
          <dt pn="section-12.3-3.13">
Security Considerations:  </dt>
          <dd pn="section-12.3-3.14">
            <t indent="0" pn="section-12.3-3.14.1">In some usage scenarios, ANE addresses carried in ALTO Protocol messages may
reveal information about an ALTO client or an ALTO service provider.
If a naming schema is used to generate ANE names, either
used privately or standardized by a future extension, how
(or if) the naming schema relates to private information
and network proximity must be explained to ALTO implementers
and service providers.</t>
          </dd>
        </dl>
      </section>
      <section anchor="alto-entity-property-types-registry" numbered="true" toc="include" removeInRFC="false" pn="section-12.4">
        <name slugifiedName="name-alto-entity-property-types-">"ALTO Entity Property Types" Registry</name>
        <t indent="0" pn="section-12.4-1">Two initial entries -- "max-reservable-bandwidth" and "persistent-entity-id" -- are
registered for the ALTO domain "ane" in the "ALTO Entity Property Types" registry,
per <xref target="RFC9240" sectionFormat="of" section="12.4" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9240#section-12.4" derivedContent="RFC9240"/>. The two
new entries are shown below in <xref target="tbl-prop-type-reg" format="default" sectionFormat="of" derivedContent="Table 4"/>, and their details can be
found in Sections <xref target="mrb-iana" format="counter" sectionFormat="of" derivedContent="12.4.1"/> and <xref target="pei-iana" format="counter" sectionFormat="of" derivedContent="12.4.2"/> of this document.</t>
        <table anchor="tbl-prop-type-reg" align="center" pn="table-4">
          <name slugifiedName="name-initial-entries-for-the-ane">Initial Entries for the "ane" Domain in the "ALTO Entity Property Types" Registry</name>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Identifier</th>
              <th align="left" colspan="1" rowspan="1">Intended Semantics</th>
              <th align="left" colspan="1" rowspan="1">Media Type of Defining Resource</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">max-reservable-bandwidth</td>
              <td align="left" colspan="1" rowspan="1">See <xref target="maxresbw" format="default" sectionFormat="of" derivedContent="Section 6.4.1"/></td>
              <td align="left" colspan="1" rowspan="1">application/alto-propmap+json</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">persistent-entity-id</td>
              <td align="left" colspan="1" rowspan="1">See <xref target="persistent-entity-id" format="default" sectionFormat="of" derivedContent="Section 6.4.2"/></td>
              <td align="left" colspan="1" rowspan="1">application/alto-propmap+json</td>
            </tr>
          </tbody>
        </table>
        <section anchor="mrb-iana" numbered="true" toc="include" removeInRFC="false" pn="section-12.4.1">
          <name slugifiedName="name-new-ane-property-type-maxim">New ANE Property Type: Maximum Reservable Bandwidth</name>
          <dl indent="3" newline="false" spacing="normal" pn="section-12.4.1-1">
            <dt pn="section-12.4.1-1.1">
Identifier:  </dt>
            <dd pn="section-12.4.1-1.2">
              <t indent="0" pn="section-12.4.1-1.2.1">"max-reservable-bandwidth"</t>
            </dd>
            <dt pn="section-12.4.1-1.3">
Intended Semantics:  </dt>
            <dd pn="section-12.4.1-1.4">
              <t indent="0" pn="section-12.4.1-1.4.1">See <xref target="maxresbw" format="default" sectionFormat="of" derivedContent="Section 6.4.1"/>.</t>
            </dd>
            <dt pn="section-12.4.1-1.5">
Media Type of Defining Resource:  </dt>
            <dd pn="section-12.4.1-1.6">
              <t indent="0" pn="section-12.4.1-1.6.1">application/alto-propmap+json</t>
            </dd>
            <dt pn="section-12.4.1-1.7">
Security Considerations:  </dt>
            <dd pn="section-12.4.1-1.8">
              <t indent="0" pn="section-12.4.1-1.8.1">To make better choices regarding bandwidth reservation, this property is essential for applications such as large-scale data
transfers or an overlay network 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 <bcp14>MUST</bcp14> consider such protection
mechanisms as providing the information to authorized clients only and applying
information reduction and obfuscation as discussed in <xref target="Security" format="default" sectionFormat="of" derivedContent="Section 11"/>.</t>
            </dd>
          </dl>
        </section>
        <section anchor="pei-iana" numbered="true" toc="include" removeInRFC="false" pn="section-12.4.2">
          <name slugifiedName="name-new-ane-property-type-persi">New ANE Property Type: Persistent Entity ID</name>
          <dl indent="3" newline="false" spacing="normal" pn="section-12.4.2-1">
            <dt pn="section-12.4.2-1.1">
Identifier:  </dt>
            <dd pn="section-12.4.2-1.2">
              <t indent="0" pn="section-12.4.2-1.2.1">"persistent-entity-id"</t>
            </dd>
            <dt pn="section-12.4.2-1.3">
Intended Semantics:  </dt>
            <dd pn="section-12.4.2-1.4">
              <t indent="0" pn="section-12.4.2-1.4.1">See <xref target="persistent-entity-id" format="default" sectionFormat="of" derivedContent="Section 6.4.2"/>.</t>
            </dd>
            <dt pn="section-12.4.2-1.5">
Media Type of Defining Resource:  </dt>
            <dd pn="section-12.4.2-1.6">
              <t indent="0" pn="section-12.4.2-1.6.1">application/alto-propmap+json</t>
            </dd>
            <dt pn="section-12.4.2-1.7">
Security Considerations:  </dt>
            <dd pn="section-12.4.2-1.8">
              <t indent="0" pn="section-12.4.2-1.8.1">This property is useful when an ALTO server wants to selectively expose
certain service points whose detailed properties can be further queried by
applications. As mentioned in <xref target="RFC9240" sectionFormat="of" section="12.3.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9240#section-12.3.2" derivedContent="RFC9240"/>, the entity IDs may reveal sensitive information about the
underlying network. An ALTO server should follow the security
considerations provided in <xref target="RFC9240" sectionFormat="of" section="11" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9240#section-11" derivedContent="RFC9240"/>.</t>
            </dd>
          </dl>
        </section>
      </section>
    </section>
  </middle>
  <back>
    <references pn="section-13">
      <name slugifiedName="name-references">References</name>
      <references pn="section-13.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC2046" target="https://www.rfc-editor.org/info/rfc2046" quoteTitle="true" derivedAnchor="RFC2046">
          <front>
            <title>Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types</title>
            <author fullname="N. Freed" initials="N." surname="Freed"/>
            <author fullname="N. Borenstein" initials="N." surname="Borenstein"/>
            <date month="November" year="1996"/>
            <abstract>
              <t indent="0">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" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t indent="0">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="RFC2387" target="https://www.rfc-editor.org/info/rfc2387" quoteTitle="true" derivedAnchor="RFC2387">
          <front>
            <title>The MIME Multipart/Related Content-type</title>
            <author fullname="E. Levinson" initials="E." surname="Levinson"/>
            <date month="August" year="1998"/>
            <abstract>
              <t indent="0">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" target="https://www.rfc-editor.org/info/rfc5322" quoteTitle="true" derivedAnchor="RFC5322">
          <front>
            <title>Internet Message Format</title>
            <author fullname="P. Resnick" initials="P." role="editor" surname="Resnick"/>
            <date month="October" year="2008"/>
            <abstract>
              <t indent="0">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="RFC7285" target="https://www.rfc-editor.org/info/rfc7285" quoteTitle="true" derivedAnchor="RFC7285">
          <front>
            <title>Application-Layer Traffic Optimization (ALTO) Protocol</title>
            <author fullname="R. Alimi" initials="R." role="editor" surname="Alimi"/>
            <author fullname="R. Penno" initials="R." role="editor" surname="Penno"/>
            <author fullname="Y. Yang" initials="Y." role="editor" surname="Yang"/>
            <author fullname="S. Kiesel" initials="S." surname="Kiesel"/>
            <author fullname="S. Previdi" initials="S." surname="Previdi"/>
            <author fullname="W. Roome" initials="W." surname="Roome"/>
            <author fullname="S. Shalunov" initials="S." surname="Shalunov"/>
            <author fullname="R. Woundy" initials="R." surname="Woundy"/>
            <date month="September" year="2014"/>
            <abstract>
              <t indent="0">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 indent="0">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 indent="0">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="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t indent="0">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" target="https://www.rfc-editor.org/info/rfc8189" quoteTitle="true" derivedAnchor="RFC8189">
          <front>
            <title>Multi-Cost Application-Layer Traffic Optimization (ALTO)</title>
            <author fullname="S. Randriamasy" initials="S." surname="Randriamasy"/>
            <author fullname="W. Roome" initials="W." surname="Roome"/>
            <author fullname="N. Schwan" initials="N." surname="Schwan"/>
            <date month="October" year="2017"/>
            <abstract>
              <t indent="0">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 indent="0">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" target="https://www.rfc-editor.org/info/rfc8895" quoteTitle="true" derivedAnchor="RFC8895">
          <front>
            <title>Application-Layer Traffic Optimization (ALTO) Incremental Updates Using Server-Sent Events (SSE)</title>
            <author fullname="W. Roome" initials="W." surname="Roome"/>
            <author fullname="Y. Yang" initials="Y." surname="Yang"/>
            <date month="November" year="2020"/>
            <abstract>
              <t indent="0">The Application-Layer Traffic Optimization (ALTO) protocol (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" target="https://www.rfc-editor.org/info/rfc8896" quoteTitle="true" derivedAnchor="RFC8896">
          <front>
            <title>Application-Layer Traffic Optimization (ALTO) Cost Calendar</title>
            <author fullname="S. Randriamasy" initials="S." surname="Randriamasy"/>
            <author fullname="R. Yang" initials="R." surname="Yang"/>
            <author fullname="Q. Wu" initials="Q." surname="Wu"/>
            <author fullname="L. Deng" initials="L." surname="Deng"/>
            <author fullname="N. Schwan" initials="N." surname="Schwan"/>
            <date month="November" year="2020"/>
            <abstract>
              <t indent="0">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="RFC9240" target="https://www.rfc-editor.org/info/rfc9240" quoteTitle="true" derivedAnchor="RFC9240">
          <front>
            <title>An Extension for Application-Layer Traffic Optimization (ALTO): Entity Property Maps</title>
            <author fullname="W. Roome" initials="W." surname="Roome"/>
            <author fullname="S. Randriamasy" initials="S." surname="Randriamasy"/>
            <author fullname="Y. Yang" initials="Y." surname="Yang"/>
            <author fullname="J. Zhang" initials="J." surname="Zhang"/>
            <author fullname="K. Gao" initials="K." surname="Gao"/>
            <date month="July" year="2022"/>
            <abstract>
              <t indent="0">This document specifies an extension to the base Application-Layer Traffic Optimization (ALTO) Protocol that generalizes the concept of "endpoint properties", which have been tied to IP addresses so far, 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 RFC 7285, 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 for specific endpoints to entire entity property maps.  These extensions introduce additional features that allow 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="RFC" value="9240"/>
          <seriesInfo name="DOI" value="10.17487/RFC9240"/>
        </reference>
        <reference anchor="RFC9274" target="https://www.rfc-editor.org/info/rfc9274" quoteTitle="true" derivedAnchor="RFC9274">
          <front>
            <title>A Cost Mode Registry for the Application-Layer Traffic Optimization (ALTO) Protocol</title>
            <author fullname="M. Boucadair" initials="M." surname="Boucadair"/>
            <author fullname="Q. Wu" initials="Q." surname="Wu"/>
            <date month="July" year="2022"/>
            <abstract>
              <t indent="0">This document creates a new IANA registry for tracking cost modes supported by the Application-Layer Traffic Optimization (ALTO) Protocol. Also, this document relaxes a constraint that was imposed by the ALTO specification on allowed cost mode values.</t>
              <t indent="0">This document updates RFC 7285.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9274"/>
          <seriesInfo name="DOI" value="10.17487/RFC9274"/>
        </reference>
      </references>
      <references pn="section-13.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="ALTO-PERF-METRICS" quoteTitle="true" target="https://datatracker.ietf.org/doc/html/draft-ietf-alto-performance-metrics-28" derivedAnchor="ALTO-PERF-METRICS">
          <front>
            <title>ALTO Performance Cost Metrics</title>
            <author fullname="Qin Wu" initials="Q" surname="Wu">
              <organization showOnFrontPage="true">Huawei</organization>
            </author>
            <author fullname="Y. Richard Yang" initials="Y" surname="Yang">
              <organization showOnFrontPage="true">Yale University</organization>
            </author>
            <author fullname="Young Lee" initials="Y" surname="Lee">
              <organization showOnFrontPage="true">Samsung</organization>
            </author>
            <author fullname="Dhruv Dhody" initials="D" surname="Dhody">
              <organization showOnFrontPage="true">Huawei</organization>
            </author>
            <author fullname="Sabine Randriamasy" initials="S" surname="Randriamasy">
              <organization showOnFrontPage="true">Nokia Bell Labs</organization>
            </author>
            <author fullname="Luis Miguel Contreras Murillo" initials="L" surname="Contreras">
              <organization showOnFrontPage="true">Telefonica</organization>
            </author>
            <date month="March" day="21" year="2022"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-alto-performance-metrics-28"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="BONDY" target="https://onlinelibrary.wiley.com/doi/10.1002/jgt.3190010306" quoteTitle="true" derivedAnchor="BONDY">
          <front>
            <title>Graph reconstruction--a survey</title>
            <author initials="J.A." surname="Bondy" fullname="John Adrian Bondy">
              <organization showOnFrontPage="true">University of Waterloo</organization>
            </author>
            <author initials="R.L." surname="Hemminger" fullname="Robert Hemminger">
              <organization showOnFrontPage="true">Vanderbilt University</organization>
            </author>
            <date year="1977"/>
          </front>
          <refcontent>Journal of Graph Theory, Volume 1, Issue 3, pp. 227-268</refcontent>
          <seriesInfo name="DOI" value="10.1002/jgt.3190010306"/>
        </reference>
        <reference anchor="BOXOPT" target="https://ojs.aaai.org//index.php/AAAI/article/view/3984" quoteTitle="true" derivedAnchor="BOXOPT">
          <front>
            <title>Optimizing in the Dark: Learning an Optimal Solution through a Simple Request Interface</title>
            <author initials="Q." surname="Xiang" fullname="Qiao Xiang">
              <organization showOnFrontPage="true">Yale University</organization>
            </author>
            <author initials="H." surname="Yu" fullname="Haitao Yu">
              <organization showOnFrontPage="true">Tongji University</organization>
            </author>
            <author initials="J." surname="Aspnes" fullname="James Aspnes">
              <organization showOnFrontPage="true">Yale University</organization>
            </author>
            <author initials="F." surname="Le" fullname="Franck Le">
              <organization showOnFrontPage="true">IBM T.J. Watson Research Center</organization>
            </author>
            <author initials="L." surname="Kong" fullname="Linghe Kong">
              <organization showOnFrontPage="true">Shanghai Jiao Tong University</organization>
            </author>
            <author initials="Y.R." surname="Yang" fullname="Yang Richard Yang">
              <organization showOnFrontPage="true">Yale University</organization>
            </author>
            <date year="2019" month="July"/>
          </front>
          <refcontent> Proceedings of the AAAI Conference on Artificial Intelligence 33, 1674-1681</refcontent>
          <seriesInfo name="DOI" value="10.1609/aaai.v33i01.33011674"/>
        </reference>
        <reference anchor="CLARINET" target="https://dl.acm.org/doi/abs/10.5555/3026877.3026911" quoteTitle="true" derivedAnchor="CLARINET">
          <front>
            <title>CLARINET: WAN-aware optimization for analytics queries</title>
            <author initials="R." surname="Viswanathan" fullname="Raajay Viswanathan">
              <organization showOnFrontPage="true">University of Wisconsin-Madison</organization>
            </author>
            <author initials="G." surname="Ananthanarayanan" fullname="Ganesh Ananthanarayanan">
              <organization showOnFrontPage="true">Microsoft</organization>
            </author>
            <author initials="A." surname="Akella" fullname="Aditya Akella">
              <organization showOnFrontPage="true">University of Wisconsin-Madison</organization>
            </author>
            <date year="2016" month="November"/>
          </front>
          <refcontent>
Proceedings of the 12th USENIX conference on Operating Systems Design and Implementation (OSDI'16), Savannah, GA, pp. 435-450</refcontent>
        </reference>
        <reference anchor="G2" target="https://dl.acm.org/doi/10.1145/3366707" quoteTitle="true" derivedAnchor="G2">
          <front>
            <title>On the Bottleneck Structure of Congestion-Controlled Networks</title>
            <author initials="J." surname="Ros-Giralt" fullname="Jordi Ros-Giralt">
              <organization showOnFrontPage="true">Reservoir Labs</organization>
            </author>
            <author initials="A." surname="Bohara" fullname="Atul Bohara">
              <organization showOnFrontPage="true">Reservoir Labs</organization>
            </author>
            <author initials="S." surname="Yellamraju" fullname="Sruthi Yellamraju">
              <organization showOnFrontPage="true">Reservoir Labs</organization>
            </author>
            <author initials="M.H." surname="Langston" fullname="M. Harper Langston">
              <organization showOnFrontPage="true">Reservoir Labs</organization>
            </author>
            <author initials="R." surname="Lethin" fullname="Richard Lethin">
              <organization showOnFrontPage="true">Reservoir Labs</organization>
            </author>
            <author initials="Y." surname="Jiang" fullname="Yuang Jiang">
              <organization showOnFrontPage="true">Yale University</organization>
            </author>
            <author initials="L." surname="Tassiulas" fullname="Leandros Tassiulas">
              <organization showOnFrontPage="true">Yale University</organization>
            </author>
            <author initials="J." surname="Li" fullname="Josie Li">
              <organization showOnFrontPage="true">University of Virginia</organization>
            </author>
            <author initials="Y." surname="Tan" fullname="Yuanlong Tan">
              <organization showOnFrontPage="true">University of Virginia</organization>
            </author>
            <author initials="M." surname="Veeraraghavan" fullname="Malathi Veeraraghavan">
              <organization showOnFrontPage="true">University of Virginia</organization>
            </author>
            <date year="2019" month="December"/>
          </front>
          <refcontent>Proceedings of the ACM on Measurement and Analysis of Computing Systems, Volume 3, Issue 3, pp. 1-31</refcontent>
          <seriesInfo name="DOI" value="10.1145/3366707"/>
        </reference>
        <reference anchor="HUG" target="https://dl.acm.org/doi/10.5555/2930611.2930638" quoteTitle="true" derivedAnchor="HUG">
          <front>
            <title>HUG: multi-resource fairness for correlated and elastic demands</title>
            <author initials="M." surname="Chowdhury" fullname="Mosharaf Chowdhury">
              <organization showOnFrontPage="true">University of Michigan</organization>
            </author>
            <author initials="Z." surname="Liu" fullname="Zhenhua Liu">
              <organization showOnFrontPage="true">Stony Brook University</organization>
            </author>
            <author initials="A." surname="Ghodsi" fullname="Ali Ghodsi">
              <organization showOnFrontPage="true">UC Berkeley, Databricks Inc.</organization>
            </author>
            <author initials="I." surname="Stoica" fullname="Ion Stoica">
              <organization showOnFrontPage="true">UC Berkeley, Databricks Inc.</organization>
            </author>
            <date year="2016" month="March"/>
          </front>
          <refcontent>Proceedings of the 13th USENIX Conference on Networked Systems Design and Implementation (NSDI'16), Santa Clara, CA, pp. 407-424</refcontent>
        </reference>
        <reference anchor="INTENT-BASED-NETWORKING" quoteTitle="true" target="https://datatracker.ietf.org/doc/html/draft-irtf-nmrg-ibn-concepts-definitions-09" derivedAnchor="INTENT-BASED-NETWORKING">
          <front>
            <title>Intent-Based Networking - Concepts and Definitions</title>
            <author initials="A" surname="Clemm" fullname="Alexander Clemm">
              <organization showOnFrontPage="true">Futurewei</organization>
            </author>
            <author initials="L" surname="Ciavaglia" fullname="Laurent Ciavaglia">
              <organization showOnFrontPage="true">Rakuten Mobile</organization>
            </author>
            <author initials="L. Z." surname="Granville" fullname="Lisandro Zambenedetti Granville">
              <organization showOnFrontPage="true">Federal University of Rio Grande do Sul (UFRGS)</organization>
            </author>
            <author initials="J" surname="Tantsura" fullname="Jeff Tantsura">
              <organization showOnFrontPage="true">Microsoft</organization>
            </author>
            <date month="March" day="24" year="2022"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-irtf-nmrg-ibn-concepts-definitions-09"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="JSONiq" target="https://www.jsoniq.org/" quoteTitle="true" derivedAnchor="JSONiq">
          <front>
            <title>The JSON Query Language</title>
            <author>
              <organization showOnFrontPage="true">JSONiq</organization>
            </author>
            <date year="2022"/>
          </front>
        </reference>
        <reference anchor="MERCATOR" target="https://ieeexplore.ieee.org/document/8756056" quoteTitle="true" derivedAnchor="MERCATOR">
          <front>
            <title>Toward Fine-Grained, Privacy-Preserving, Efficient Multi-Domain Network Resource Discovery</title>
            <author initials="Q." surname="Xiang" fullname="Qiao Xiang">
              <organization showOnFrontPage="true">Yale University</organization>
            </author>
            <author initials="J." surname="Zhang" fullname="Jingxuan Zhang">
              <organization showOnFrontPage="true">Tongji University</organization>
            </author>
            <author initials="X." surname="Wang" fullname="Xin Wang">
              <organization showOnFrontPage="true">Tongji University</organization>
            </author>
            <author initials="Y." surname="Liu" fullname="Yang Liu">
              <organization showOnFrontPage="true">Tongji University</organization>
            </author>
            <author initials="C." surname="Guok" fullname="Chin Guok">
              <organization showOnFrontPage="true">ESNet</organization>
            </author>
            <author initials="F." surname="Le" fullname="Franck Le">
              <organization showOnFrontPage="true">IBM T.J. Watson Research Center</organization>
            </author>
            <author initials="J." surname="MacAuley" fullname="John MacAuley">
              <organization showOnFrontPage="true">ESNet</organization>
            </author>
            <author initials="H." surname="Newman" fullname="Harvey Newman">
              <organization showOnFrontPage="true">Caltech</organization>
            </author>
            <author initials="Y.R." surname="Yang" fullname="Yang Richard Yang">
              <organization showOnFrontPage="true">Yale University</organization>
            </author>
            <date year="2019" month="August"/>
          </front>
          <refcontent>IEEE/ACM, IEEE Journal on Selected Areas in Communications, Volume 37, Issue 8, pp. 1924-1940</refcontent>
          <seriesInfo name="DOI" value="10.1109/JSAC.2019.2927073"/>
        </reference>
        <reference anchor="MOWIE" target="https://dl.acm.org/doi/10.1145/3405672.3409489" quoteTitle="true" derivedAnchor="MOWIE">
          <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 showOnFrontPage="true">Tencent</organization>
            </author>
            <author initials="G." surname="Li" fullname="Gang Li">
              <organization showOnFrontPage="true">China Mobile</organization>
            </author>
            <author initials="C." surname="Xiong" fullname="Chunshan Xiong">
              <organization showOnFrontPage="true">Tencent</organization>
            </author>
            <author initials="Y." surname="Lei" fullname="Yixue Lei">
              <organization showOnFrontPage="true">Tencent</organization>
            </author>
            <author initials="W." surname="Huang" fullname="Wei Huang">
              <organization showOnFrontPage="true">Tencent</organization>
            </author>
            <author initials="Y." surname="Han" fullname="Yunbo Han">
              <organization showOnFrontPage="true">Tencent</organization>
            </author>
            <author initials="A." surname="Walid" fullname="Anwar Walid">
              <organization showOnFrontPage="true">Nokia Bell Labs</organization>
            </author>
            <author initials="Y.R." surname="Yang" fullname="Yang Richard Yang">
              <organization showOnFrontPage="true">Yale University</organization>
            </author>
            <author initials="Z." surname="Zhang" fullname="Zhi-Li Zhang">
              <organization showOnFrontPage="true">University of Minnesota</organization>
            </author>
            <date year="2020" month="August"/>
          </front>
          <refcontent>Proceedings of the Workshop on Network Application Integration/CoDesign (NAI '20), ACM, Virtual Event USA, pp. 20-27</refcontent>
          <seriesInfo name="DOI" value="10.1145/3405672.3409489"/>
        </reference>
        <reference anchor="NOVA" target="https://doi.org/10.1109/TNET.2019.2899905" quoteTitle="true" derivedAnchor="NOVA">
          <front>
            <title>An Objective-Driven On-Demand Network Abstraction for Adaptive Applications</title>
            <author initials="K." surname="Gao" fullname="Kai Gao">
              <organization showOnFrontPage="true">Sichuan University</organization>
            </author>
            <author initials="Q." surname="Xiang" fullname="Qiao Xiang">
              <organization showOnFrontPage="true">Yale University</organization>
            </author>
            <author initials="X." surname="Wang" fullname="Xin Wang">
              <organization showOnFrontPage="true">Tongji University</organization>
            </author>
            <author initials="Y.R." surname="Yang" fullname="Yang Richard Yang">
              <organization showOnFrontPage="true">Yale University</organization>
            </author>
            <author initials="J." surname="Bi" fullname="Jun Bi">
              <organization showOnFrontPage="true">Tsinghua University</organization>
            </author>
            <date month="April" year="2019"/>
          </front>
          <refcontent>IEEE/ACM Transactions on Networking (TON) Vol. 27, Issue 2, pp. 805-818</refcontent>
          <seriesInfo name="DOI" value="10.1109/TNET.2019.2899905"/>
        </reference>
        <reference anchor="RESA" target="https://ieeexplore.ieee.org/document/8665783" quoteTitle="true" derivedAnchor="RESA">
          <front>
            <title>Fine-Grained, Multi-Domain Network Resource Abstraction as a Fundamental Primitive to Enable High-Performance, Collaborative Data Sciences</title>
            <author initials="Q." surname="Xiang" fullname="Qiao Xiang">
              <organization showOnFrontPage="true">Yale University</organization>
            </author>
            <author initials="J." surname="Zhang" fullname="Jingxuan Zhang">
              <organization showOnFrontPage="true">Tongji University</organization>
            </author>
            <author initials="X." surname="Wang" fullname="Xin Wang">
              <organization showOnFrontPage="true">Tongji University</organization>
            </author>
            <author initials="Y." surname="Liu" fullname="Yang Liu">
              <organization showOnFrontPage="true">Tongji University</organization>
            </author>
            <author initials="C." surname="Guok" fullname="Chin Guok">
              <organization showOnFrontPage="true">ESNet</organization>
            </author>
            <author initials="F." surname="Le" fullname="Franck Le">
              <organization showOnFrontPage="true">IBM T.J. Watson Research Center</organization>
            </author>
            <author initials="J." surname="MacAuley" fullname="John MacAuley">
              <organization showOnFrontPage="true">ESNet</organization>
            </author>
            <author initials="H." surname="Newman" fullname="Harvey Newman">
              <organization showOnFrontPage="true">Caltech</organization>
            </author>
            <author initials="Y.R." surname="Yang" fullname="Yang Richard Yang">
              <organization showOnFrontPage="true">Yale University</organization>
            </author>
            <date year="2018" month="November"/>
          </front>
          <refcontent>SC18: International Conference for High Performance Computing, Networking, Storage and Analysis, pp. 58-70</refcontent>
          <seriesInfo name="DOI" value="10.1109/SC.2018.00008"/>
        </reference>
        <reference anchor="RFC2216" target="https://www.rfc-editor.org/info/rfc2216" quoteTitle="true" derivedAnchor="RFC2216">
          <front>
            <title>Network Element Service Specification Template</title>
            <author fullname="S. Shenker" initials="S." surname="Shenker"/>
            <author fullname="J. Wroclawski" initials="J." surname="Wroclawski"/>
            <date month="September" year="1997"/>
            <abstract>
              <t indent="0">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" target="https://www.rfc-editor.org/info/rfc4271" quoteTitle="true" derivedAnchor="RFC4271">
          <front>
            <title>A Border Gateway Protocol 4 (BGP-4)</title>
            <author fullname="Y. Rekhter" initials="Y." role="editor" surname="Rekhter"/>
            <author fullname="T. Li" initials="T." role="editor" surname="Li"/>
            <author fullname="S. Hares" initials="S." role="editor" surname="Hares"/>
            <date month="January" year="2006"/>
            <abstract>
              <t indent="0">This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol.</t>
              <t indent="0">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 indent="0">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 indent="0">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="RFC9113" target="https://www.rfc-editor.org/info/rfc9113" quoteTitle="true" derivedAnchor="RFC9113">
          <front>
            <title>HTTP/2</title>
            <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson"/>
            <author fullname="C. Benfield" initials="C." role="editor" surname="Benfield"/>
            <date month="June" year="2022"/>
            <abstract>
              <t indent="0">This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced latency by introducing field compression and allowing multiple concurrent exchanges on the same connection.</t>
              <t indent="0">This document obsoletes RFCs 7540 and 8740.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9113"/>
          <seriesInfo name="DOI" value="10.17487/RFC9113"/>
        </reference>
        <reference anchor="RFC9114" target="https://www.rfc-editor.org/info/rfc9114" quoteTitle="true" derivedAnchor="RFC9114">
          <front>
            <title>HTTP/3</title>
            <author fullname="M. Bishop" initials="M." role="editor" surname="Bishop"/>
            <date month="June" year="2022"/>
            <abstract>
              <t indent="0">The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment.  This document describes a mapping of HTTP semantics over QUIC.  This document also identifies HTTP/2 features that are subsumed by QUIC and describes how HTTP/2 extensions can be ported to HTTP/3.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9114"/>
          <seriesInfo name="DOI" value="10.17487/RFC9114"/>
        </reference>
        <reference anchor="SENSE" target="https://www.es.net/network-r-and-d/sense/" quoteTitle="true" derivedAnchor="SENSE">
          <front>
            <title>Software Defined Networking (SDN) for End-to-End Networked Science at the Exascale</title>
            <author>
              <organization showOnFrontPage="true">ESnet</organization>
            </author>
            <date year="2019"/>
          </front>
        </reference>
        <reference anchor="SEREDGE" target="https://ieeexplore.ieee.org/document/9110342" quoteTitle="true" derivedAnchor="SEREDGE">
          <front>
            <title>Computing at the Edge: But, what Edge?</title>
            <author initials="L." surname="Contreras" fullname="Luis M. Contreras">
              <organization showOnFrontPage="true">Telefonica</organization>
            </author>
            <author initials="J." surname="Baliosian" fullname="Javier Baliosian">
              <organization showOnFrontPage="true">Telefonica/Universidad de la República</organization>
            </author>
            <author initials="P." surname="Martínez-Julia" fullname="Pedro Martı́nez-Julia">
              <organization showOnFrontPage="true">National Institute of Information and Communications Technology, Japan</organization>
            </author>
            <author initials="J." surname="Serrat" fullname="Joan Serrat">
              <organization showOnFrontPage="true">Universitat Politcnica de Catalunya</organization>
            </author>
            <date year="2020" month="April"/>
          </front>
          <refcontent>Proceedings of NOMS 2020 - 2020 IEEE/IFIP Network Operations and Management Symposium, pp. 1-9</refcontent>
          <seriesInfo name="DOI" value="10.1109/NOMS47738.2020.9110342"/>
        </reference>
        <reference anchor="SWAN" target="https://dl.acm.org/doi/10.1145/2486001.2486012" quoteTitle="true" derivedAnchor="SWAN">
          <front>
            <title>Achieving high utilization with software-driven WAN</title>
            <author initials="C." surname="Hong" fullname="Chi-Yao Hong">
              <organization showOnFrontPage="true">Microsoft</organization>
            </author>
            <author initials="S." surname="Kandula" fullname="Srikanth Kandula">
              <organization showOnFrontPage="true">Microsoft</organization>
            </author>
            <author initials="R." surname="Mahajan" fullname="Ratul Mahajan">
              <organization showOnFrontPage="true">Microsoft</organization>
            </author>
            <author initials="M." surname="Zhang" fullname="Ming Zhang">
              <organization showOnFrontPage="true">Microsoft</organization>
            </author>
            <author initials="V." surname="Gill" fullname="Vijay Gill">
              <organization showOnFrontPage="true">Microsoft</organization>
            </author>
            <author initials="M." surname="Nanduri" fullname="Mohan Nanduri">
              <organization showOnFrontPage="true">Microsoft</organization>
            </author>
            <author initials="R." surname="Wattenhofer" fullname="Roger Wattenhofer">
              <organization showOnFrontPage="true">ETH</organization>
            </author>
            <date year="2013" month="August"/>
          </front>
          <refcontent>Proceedings of the ACM SIGCOMM 2013 conference on SIGCOMM (SIGCOMM '13), New York, NY, pp. 15-26</refcontent>
          <seriesInfo name="DOI" value="10.1145/2486001.2486012"/>
        </reference>
        <reference anchor="UNICORN" target="https://www.sciencedirect.com/science/article/abs/pii/S0167739X18302413?via%3Dihub" quoteTitle="true" derivedAnchor="UNICORN">
          <front>
            <title>Unicorn: Unified resource orchestration for multi-domain, geo-distributed data analytics</title>
            <author initials="Q." surname="Xiang" fullname="Qiao Xiang">
              <organization showOnFrontPage="true">Yale University</organization>
            </author>
            <author initials="T." surname="Wang" fullname="X. Tony Wang">
              <organization showOnFrontPage="true">Tongji University</organization>
            </author>
            <author initials="J." surname="Zhang" fullname="Jingxuan Jensen Zhang">
              <organization showOnFrontPage="true">Tsinghua University</organization>
            </author>
            <author initials="H." surname="Newman" fullname="Harvey Newman">
              <organization showOnFrontPage="true">California Institute of Technology</organization>
            </author>
            <author initials="Y.R." surname="Yang" fullname="Yang Richard Yang">
              <organization showOnFrontPage="true">Yale University</organization>
            </author>
            <author initials="Y." surname="Liu" fullname="Yang Liu">
              <organization showOnFrontPage="true">Tongji University</organization>
            </author>
            <date year="2019" month="April"/>
          </front>
          <refcontent>Future Generation Computer Systems, Volume 93, pp. 188-197</refcontent>
          <seriesInfo name="DOI" value="10.1016/j.future.2018.09.048"/>
        </reference>
        <reference anchor="XQuery" target="https://www.w3.org/TR/xquery-31/" quoteTitle="true" derivedAnchor="XQuery">
          <front>
            <title>XQuery 3.1: An XML Query Language</title>
            <author initials="J." surname="Robie" fullname="Jonathan Robie" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Dyck" fullname="Michael Dyck" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Spiegel" fullname="Josh Spiegel" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2017" month="March"/>
          </front>
          <refcontent>W3C Recommendation</refcontent>
        </reference>
      </references>
    </references>
    <section anchor="acknowledgments" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgments">Acknowledgments</name>
      <t indent="0" pn="section-appendix.a-1">The authors would like to thank <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 <contact fullname="Yan Luo"/> for fruitful discussions. The authors thank <contact fullname="Greg Bernstein"/>, <contact fullname="Dawn Chen"/>, <contact fullname="Wendy Roome"/>, and
<contact fullname="Michael Scharf"/> for their contributions to earlier draft versions of this document.</t>
      <t indent="0" pn="section-appendix.a-2">The authors would also like to thank <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 <contact fullname="Qiao Xiang"/>,
whose feedback and suggestions were invaluable for improving the practicability and
conciseness of this document; and <contact fullname="Mohamed Boucadair"/>, <contact fullname="Martin Duke"/>, <contact fullname="Vijay Gurbani"/>,
<contact fullname="Jan Seedorf"/>, and <contact fullname="Qin Wu"/>, who provided great support and guidance.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author initials="K." surname="Gao" fullname="Kai Gao">
        <organization showOnFrontPage="true">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 showOnFrontPage="true">Samsung</organization>
        <address>
          <postal>
            <country>Republic of Korea</country>
          </postal>
          <email>younglee.tx@gmail.com</email>
        </address>
      </author>
      <author initials="S." surname="Randriamasy" fullname="Sabine Randriamasy">
        <organization showOnFrontPage="true">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." surname="Yang" fullname="Yang Richard Yang">
        <organization showOnFrontPage="true">Yale University</organization>
        <address>
          <postal>
            <street>51 Prospect Street</street>
            <city>New Haven</city>
            <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 showOnFrontPage="true">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>
    </section>
  </back>
</rfc>
