ALTO WG                                                     G. Bernstein
Internet-Draft                                         Grotto Networking
Intended status: Standards Track                                 S. Chen
Expires: November January 4, 2017 2018                               Tongji University
                                                                  K. Gao
                                                     Tsinghua University
                                                                  Y. Lee
                                                                  Huawei
                                                                W. Roome
                                                               M. Scharf
                                                                   Nokia
                                                                 Y. Yang
                                                         Yale University
                                                                J. Zhang
                                                       Tongji University
                                                             May
                                                            July 3, 2017

                 ALTO Extension: Path Vector Cost Mode
                   draft-ietf-alto-path-vector-00.txt
                   draft-ietf-alto-path-vector-01.txt

Abstract

   The Application-Layer Traffic Optimization (ALTO) Service protocol [RFC7285]
   has defined
   network several resources and cost maps services to provide clients with
   basic network information, where information.  However, the
   cost maps allow base ALTO protocol and
   latest extensions only scalar (numerical or ordinal) cost mode values. provide end-to-end metrics, which are
   insufficient to satisfy the demands of solving more complex network
   optimization problems.  This document introduces a new cost mode called path-vector an extension to allow the
   base ALTO protocol, namely the path-vector extension, which allows
   ALTO clients to support use cases query information such as capacity regions for
   applications.  This document starts with a
   given set of flows.  A non-normative example called multi-flow
   scheduling (or capacity region) is presented to illustrate that the limitations of existing
   ALTO (endpoint) cost maps without path vectors cannot provide sufficient
   information.  This document then defines path-vector as a new cost
   mode. maps.  After that, details of the extension are
   defined.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on November January 4, 2017. 2018.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) 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 Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3   4
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  Use Case: Capacity Region for Multi-Flow Scheduling . . . . .   5
   4.  Overview of Approach  .  . . . . . . . . . . . . . . . . . . .   7
     4.1.  Path Vector Data Format . . . . . . . . .   7
     4.1.  Path Vector . . . . . . . .   7
     4.2.  Network Element Property Map . . . . . . . . . . . . . .   8
     4.3.  Flow Query Format .   7
     4.2.  Cost Type Extension . . . . . . . . . . . . . . . . . . .   8
     4.4.  Query Specific
     4.3.  Abstract Network Element Property Map . . . . . . . . . .   8
     4.4.  New Media Type: multipart/related . . . . . . . . . . . .   8
   5.  Protocol Extensions . . . . . . . . . .  Path-Vector Extension: Basic Data Types . . . . . . . . . . .   8   9
     5.1.  Cost Type . . . . . . . . . . . . . . . . . . . . . . . .   9
       5.1.1.  Cost Metric . . . . . . . . . . . . . . . . . . . . .   9
       5.1.2.  Cost Mode: Path Vector  . . . Mode . . . . . . . . . . . .   9
     5.2.  Version Tag . . . . . . . . . .  10
     5.2.  ANE Domain  . . . . . . . . . . . . .   9
     5.3.  Network Element Name . . . . . . . . . .  10
       5.2.1.  Domain Name . . . . . . . .  10
     5.4.  ANE Domain . . . . . . . . . . . . .  10
       5.2.2.  Domain-Specific Entity Addresses  . . . . . . . . . .  10
       5.4.1.  Domain
     5.3.  Abstract Network Element Name . . . . . . . . . . . . . .  11
     5.4.  Version Tag . . . . . . .  10
       5.4.2.  Domain-Specific Entity Addresses  . . . . . . . . . .  10
     5.5.  Filtered Network Element Property Map . . . . . . . . .  11
   6.  Path-Vector Extension: Services .  10
       5.5.1.  Accept Input Parameters . . . . . . . . . . . . . .  11
     6.1.  IRD Extensions  .  10
       5.5.2.  Capabilities . . . . . . . . . . . . . . . . . . . .  11
       5.5.3.  Response  . .
     6.2.  Cost Map Extensions . . . . . . . . . . . . . . . . . . .  12
       6.2.1.  Media Type  .  11

     5.6.  IRD Extensions . . . . . . . . . . . . . . . . . . . .  12
       6.2.2.  Capabilities  .  11
     5.7.  Cost Map Extensions . . . . . . . . . . . . . . . . . . .  12
       5.7.1.  Propertymap .
       6.2.3.  Property-map  . . . . . . . . . . . . . . . . . . . .  12
       5.7.2.
       6.2.4.  Response  . . . . . . . . . . . . . . . . . . . . . .  12
     5.8.  13
     6.3.  Filtered Cost Map Extensions  . . . . . . . . . . . . . .  12
       5.8.1.  Capabilities  13
       6.3.1.  Media Type  . . . . . . . . . . . . . . . . . . . .  12
       5.8.2.  Accept Input Parameters .  13
       6.3.2.  Capabilities  . . . . . . . . . . . . . .  13
       5.8.3.  Propertymap . . . . . .  13
       6.3.3.  Property-map  . . . . . . . . . . . . . . .  14
       5.8.4. . . . . .  14
       6.3.4.  Accept Input Parameters . . . . . . . . . . . . . . .  14
       6.3.5.  Response  . . . . . . . . . . . . . . . . . . . . . .  14
     5.9.
     6.4.  Endpoint Cost Service Extensions  . . . . . . . . . . . .  14
       5.9.1.  Capabilities
       6.4.1.  Media Type  . . . . . . . . . . . . . . . . . . . . .  15
       5.9.2.  Accept Input Parameters
       6.4.2.  Capabilities  . . . . . . . . . . . . . . . . . . . .  15
       5.9.3.  Propertymap
       6.4.3.  Property-map  . . . . . . . . . . . . . . . . . . . .  15
       6.4.4.  Accept Input Parameters . . .  16
       5.9.4. . . . . . . . . . . . .  15
       6.4.5.  Response  . . . . . . . . . . . . . . . . . . . . . .  16
   6.  15
   7.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .  16
     6.1.
     7.1.  Workflow  . . . . . . . . . . . . . . . . . . . . . . . .  16
     6.2.
     7.2.  Information Resource Directory Example  . . . . . . . . .  17
     6.3.  Cost Map
     7.3.  Single Query Example # 1  . . . . . . . . . . . . . . . .  18
     7.4.  Single Query Example # 2  . . . . . .  19
     6.4.  Multi-Cost Filtered Cost Map Example . . . . . . . . . .  20
     6.5.  Endpoint Cost Service
     7.5.  Multiple Queries Example  . . . . . . . . . . . . . .  22
     6.6.  Network Element Property Map . .  21
       7.5.1.  Endpoint Cost Service Example # 1 . . . . . . . .  23
     6.7. . . . .  21
       7.5.2.  Abstract Network Element Property Map Example # 2  . . . . . . . .  24
   7.  23
   8.  Compatibility . . . . . . . . . . . . . . . . . . . . . . . .  25
     7.1.  23
     8.1.  Compatibility with Legacy ALTO Clients/Servers  . . . . .  25
     7.2.  23
     8.2.  Compatibility with Multi-Cost Extensions  . . . . . . . .  25
     7.3.  23
     8.3.  Compatibility with Incremental Update . . . . . . . . . .  26
   8.  Time to live  . . . . . . . . . . . . . . . . . . . . . . . .  26  24
   9.  Design Decisions and Discussions  . . . . . . . . . . . . . .  26  24
     9.1.  Path Vector or Path Graph  Provide More General Calendar Extension . . . . . . . . .  24
   10. Security Considerations . . . . . . .  26
     9.2.  Provide More General Calendar Extension . . . . . . . . .  27
     9.3.  Snapshot and real-time update . . .  24
     10.1.  Privacy Concerns . . . . . . . . . . .  27
   10. Security Considerations . . . . . . . . .  24
     10.2.  Resource Consumption on ALTO Servers . . . . . . . . . .  27  25
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  28  25
     11.1.  ALTO Cost Mode Registry  . . . . . . . . . . . . . . . .  28  25
     11.2.  ALTO Cost Metric Registry  . . . . . . . . . . . . . . .  28  25
     11.3.  ALTO Entity Domain Registry  . . . . . . . . . . . . . .  28  26
     11.4.  ALTO Network Element Property Type Registry  . . . . . .  29  26
   12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  29  26
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  29  26
     13.1.  Normative References . . . . . . . . . . . . . . . . . .  29  27
     13.2.  Informative References . . . . . . . . . . . . . . . . .  29  27
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  31  28

1.  Introduction

   The ALTO base protocol [RFC7285] is designed for exposing network
   information through services such as the Network Map service and the
   Cost Map service.  These services use the an extreme "single-node"
   abstraction, which represents the whole network with a single node
   and hosts are with "endpoint groups" directly connected to the node's access ports. node.

   Although the "single-node" abstraction works well for in many settings,
   it lacks the ability to support new emerging use cases, such as
   inter-datacenter data transfers flow scheduling and scientific high-performance
   computing data transfers, require additional network transfers.  Specifically, the base ALTO protocol MUST
   provide the following two functionalities:

   o  Providing information beyond on shared bottlenecks: In the single-node abstraction, to support
   application capabilities, in particular, aforementioned
      use cases, the ability volume of application a single flow scheduling.

   Specifically, providing can reach 10s - 100s Gbps,
      so that the network cannot treat the flows as independent like in
      the base ALTO protocol.  In this case, ALTO servers MUST be able
      to provide information on shared bottlenecks to support application help applications
      avoid congestion.

   o  Encapsulating multiple cost values in a single session: Some flow
      scheduling problems take multiple metrics into consideration.
      Making multiple queries introduces larger communication overhead,
      and more importantly, out-of-sync data for different cost types.
      Encapsulating multiple complexities.  First, the
   underlying assumption of existing ALTO services is single-commodity
   flows.  Hence, given the flow from a source to cost values in a destination, ALTO
   computes single query and response
      session reduces communication overhead and simplifies the network metrics of
      synchronization in use cases involving multiple cost types.

   This draft aims to extend the flow and returns them base ALTO protocol to support these new
   functionalities, with the
   application. path-vector extension.  The metric values for different flows are independent.
   Application flow scheduling, however, requires network information path-vector
   extension specifies how to
   compute application-desirable multi-commodity flows, where multiple
   flows under the control of encode the same application may share common shared bottlenecks in a network bottlenecks.  This requirement is beyond the capability
   for a given set of
   the single-node abstraction adopted flows with many design details driven by
   effectiveness, performance and backward compatibility considerations.

   The second functionality for simple cost types, such as those
   introduced in the base ALTO protocol.
   Second, some flow scheduling problems may consider end-to-end metrics
   at the same time and thus require multiple costs to be updated
   simultaneously.  Such a requirement, even though protocol, is already addressed by
   [I-D.ietf-alto-multi-cost], still needs to be handled very carefully.

   To address these complexities in supporting the new flow scheduling
   use case, this document specifies a path-vector extension to recent
   extension, e.g.  [I-D.ietf-alto-multi-cost].  However, the base
   ALTO protocol.  This path-
   vector extension introduces in this document has introduced a new cost type, type
   which uses
   "path-vector" as complicates the situation.  Thus, the multiple cost mode and "ane" (abstract network element)
   encapsulation must still be taken into consideration.

   The document is organized as
   cost metric.  It extends "Filtered Property Map" defined in
   [I-D.roome-alto-unified-props] to address the issue follows.  Section 3 gives an example of scalability
   flow scheduling and consistency illustrates the limitations of the base ALTO
   protocol in providing path vectors with fine-grained
   information.  This document also registers such a new entity domain,
   entity specification and properties in the ALTO Entity Domain
   Registry.  Besides, (Filtered) Cost Map and Endpoint Cost Service are
   extended to support path-vector and flow query format.  The concept
   of "query specific" is put forward to correlate the response
   information of (Filtered) Cost Map/Endpoint Cost service and query of
   property map.

   The document is organized as follows.  Section 3 gives an example of
   flow scheduling to illustrate the need to introduce cost mode "path-
   vector" and cost metric "ane". use case.  Section 4 gives an overview of the
   path-vector extension. extension, before specifying the details of the extension
   in Section 5 specifies the new cost mode and
   cost metric, new domain type, entity properties and protocol
   extensions for (Filtered) Cost Maps and Endpoint Cost Services. Section 6 6.  Section 7 presents several examples. examples, and
   Section 7 9 explains some design decisions.  Section 8 discusses the
   compatibility issues with some other proposed ALTO extensions.  Section 8 discusses the time to live problem.  Section 9 discusses
   several design decisions.  Section 10 and
   Section 11 discusses about security and IANA Considerations. considerations.

2.  Terminology

   This document uses the same terms as defined in [RFC7285],
   [I-D.ietf-alto-multi-cost] and [I-D.roome-alto-unified-props] with
   the following additional terms: Abstract Network Element, Abstract
   Network Element Name, Abstract Network Element Property, Abstract
   Network Element Property Map and Path Vector.

   o  Abstract Network Element (NE): A Network Element (ANE): An abstract network element is an abstract
      abstraction of network
      element, which components, it can be a link, a network switching device, or a set an aggregation of devices.

   o
      links, middle boxes, Virtualized Network Element Name (NEN): The id of Function (VNF), or even a NE.  It can be referenced
      by Cost Map, Filtered Cost Map, Endpoint Cost Service
      sub-network.  An abstract network element has two attributes:
      abstract network element name and Property
      Map. abstract network element
      property, which are defined below.

   o  Abstract Network Element Property (NEP): The property of a NE.  It can be
      the available bandwidth of a link, the delay or other available
      properties. Name (ANEN): An abstract network element
      name is an identifier which uniquely identifies an abstract
      network element, as defined in Section 5.3.

   o  Abstract Network Element Property Map (NEP Map): It (ANEP): An abstract network
      element property is a Filtered Property
      Map resource defined in [I-D.roome-alto-unified-props] and
      supports "ane" specific metric associated with a given
      abstract network element, as introduced in Section 4.3.  An
      abstract network element CAN have several network element
      properties.

   o  Abstract Network Element Property Map (ANEP Map): An abstract
      network element property map is a Filtered Property Map defined in
      [I-D.roome-alto-unified-props] which supports the "ane" domain in
      its "domain-types" capability.

   o  Cost Map, Filtered Cost Map, Endpoint Cost Service: If not
      explained explicitly, they are the same definition as of
      [I-D.ietf-alto-multi-cost] by default.

   o  Path Vector (PV): An A path vector is an array of NENs.  It can be used to convey the
      routing information. abstract network
      elements, representing an abstract path between entities (PIDs or
      endpoints).

3.  Use Case: Capacity Region for Multi-Flow Scheduling

   Consider the case that routing is given.  Then what application-layer
   traffic optimization will focus on is traffic scheduling among
   application-layer paths.  Specifically, assume that an application
   has control over a set of flows F = {f_1, f_2, ..., f_|F|}. If
   routing is given, what the application can control is x_1, x_2, ...,
   x_|F|, where x_i is the amount of traffic for flow i.  Let x = [x_1,
   ..., x_|F|] be the vector of the flow traffic amounts.  Due to shared
   links, feasible values of x where link capacities are not exceeded
   can be a complex polytype.

   Specifically, consider a network as shown in Figure 1.  The network
   has 7 switches (sw1 to sw7) forming a dumb-bell topology.  Switches
   sw1/sw3 provide access on one side, sw2/sw4 provide access on the
   other side, 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 each link is eh1 -> sw1 and link sw1 -> sw5 are 150 Mbps,
   and the bandwidth of the rest links are 100 Mbps.

                                  +------+
                                  |      |
                                --+ sw6  +--
                              /   |      |  \
        PID1 +-----+         /    +------+   \          +-----+  PID2
        eh1__|     |_       /                 \     ____|     |__eh2
             | sw1 | \   +--|---+         +---|--+ /    | sw2 |
             +-----+  \  |      |         |      |/     +-----+
                       \_| sw5  +---------+ sw7  |
        PID3 +-----+   / |      |         |      |\     +-----+  PID4
        eh3__|     |__/  +------+         +------+ \____|     |__eh4
             | sw3 |                                    | sw4 |
             +-----+                                    +-----+

                      Figure 1: Raw Network Topology.

   The single-node ALTO topology abstraction of the network is shown in
   Figure 2.

                          +----------------------+
                 {eh1}    |                      |     {eh2}
                 PID1     |                      |     PID2
                   +------+                      +------+
                          |                      |
                          |                      |
                 {eh3}    |                      |     {eh4}
                 PID3     |                      |     PID4
                   +------+                      +------+
                          |                      |
                          +----------------------+

             Figure 2: Base Single-Node Topology Abstraction.

   Consider an application overlay (e.g., a large data analysis system)
   which needs to schedule the traffic among a set of end host source-
   destination pairs, say eh1 -> eh2, eh2 and eh3 eh1 -> eh4.  The application
   can request a cost map providing end-to-end available bandwidth,
   using 'availbw' as cost-metric and 'numerical' as cost-mode.

   Assume that the

   The application receives will receive from the ALTO server that the bandwidth of
   eh1 -> eh2 and eh3 ->eh4 eh1 -> eh4 are both 100 Mbps.  It cannot
   determine that if it schedules the two flows together, whether it
   will obtain a total of 100 Mbps or 200 Mbps.  This depends on whether
   the routing paths of  But this information is
   not enough.  Consider the following two flows share a bottleneck in the
   underlying topology: cases:

   o  Case 1: If eh1 -> eh2 and eh3 -> eh4 use different paths, for
      example, when the first uses the path eh1 -> sw1 -> sw5 -> sw6 ->
      sw7 -> sw2, sw2 -> eh2 and the
      second eh1 -> eh4 uses sw3 path eh1 -> sw5 sw1 -> sw6 sw5 ->
      sw7 -> sw4.  Then sw4 -> eh4, then the application will obtain 200 150 Mbps.

   o  Case 2: If eh1 -> eh2 uses the path eh1 -> sw1 -> sw5 -> sw7 ->
      sw2 -> eh2 and eh3 eh1 -> eh4 share a bottleneck, for
      example, when both use uses the direct link path eh1 -> sw1 -> sw5 -> sw7, sw7
      -> sw4 -> eh4, then the application will obtain only 100 Mbps.

   To allow applications to distinguish the two aforementioned cases,
   the network needs to provide more details.  In particular, it needs
   to provide the following new capabilities:

   o  The network needs to expose more detailed routing information to
      show the shared bottlenecks.

   o  The network needs to provide the necessary abstraction to hide the
      real topology information as possible.

   The path-vector extension defined in this document will satisfy all
   the requirements.

   See [I-D.bernstein-alto-topo] for a survey of use-cases where
   extended network topology information is needed.

4.  Overview of Approach

   This section presents a non-normative overview of the path-vector
   extension defined in this document.
   extension.  It assumes the readers are familiar with (Filtered) Cost
   Map and Endpoint Cost Service defined in [RFC7285], their extensions
   defined in [I-D.ietf-alto-multi-cost] and Filtered Property Map
   defined in [I-D.roome-alto-unified-props].

4.1.  Path Vector Data Format

   The path-vector extension defined in this document introduces "path-
   vector" as a cost mode, where a

   A path vector between two entities
   (either PIDs or endpoints) is an array of abstract network elements. elements, representing
   an abstract path between entities (PIDs or endpoints).  Each abstract
   network element is represented by a name.  An has two attributes: name and property.  The abstract
   network element can be a link, a network switching device, or a set
   of devices.

   One issue of introducing path vectors is how to encode them.  The
   cost entries contained in an ALTO (Filtered) Cost Map or Endpoint
   Cost Service names are formally defined encoded in Section 11.2.3.6 of [RFC7285] to
   be any type of JSON value.  But the section also suggests that
   implementations may assume the cost values are numbers unless
   specifically defined by an extension.  This document extends the
   definition of Cost Map maps and Endpoint Cost Map to allow the returned
   cost to be abstract
   network element properties are encoded in abstract network element
   property maps.

4.2.  Cost Type Extension

   To provide abstract network element names of a path vector, which in cost maps,
   each cost value is a JSONArray of Network Element
   Names.

4.2.  Network Element Property Map

   The response with only the names of network elements does not provide
   enough information.  To be useful to applications, the extension need
   to provide desired properties list of the abstract network elements element names.
   However, as
   well. defined in Section 6.1.2 of [RFC7285], a cost mode is
   either "numerical" or "ordinal", none of which can be used to present
   a list.

   This document registers specifies a new entity domain "ane" cost mode "array" and entity
   specifications. a new cost metric
   "ane-path".  The Filtered Property Map defined new cost mode "array" means each cost value in
   [I-D.roome-alto-unified-props] supporting "ane" domain (named Network
   Element Property Map) is used for ALTO clients to retrieve the
   properties
   cost maps is a list.  The new cost metric "ane-path" means each cost
   value represents an abstract path consisting of abstract network elements.

4.3.  Flow Query Format

   Current queries of
   element names between two entities (PIDs or endpoints).

   The new cost type follows the (Filtered) Cost Map/Endpoint Cost Service are
   of cross-product format.  Such format fails to support lists convention of
   single src to single dst costs.  So the input scheme of cost types in the Filtered
   base protocol.  For example:

   +------------+--------------+---------------------------------------+
   | cost mode  | cost metric  | meaning                               |
   +------------+--------------+---------------------------------------+
   | numerical  | routingcost  | a number representing the routing     |
   |            |              | cost                                  |
   | ordinal    | hopcount     | a ranking representing the hop count  |
   | array      | ane-path     | a list representing the ane path      |
   +------------+--------------+---------------------------------------+

                  Table 1: Cost Types and Their Meanings

4.3.  Abstract Network Element Property Map

   Given that Cost Map and Endpoint Cost Service is extended to support service now provide the above
   flow query format.

4.4.  Query Specific

   Path Vector extension has raised
   abstract network element names along a new occasion flow path, ALTO clients can
   learn that there exist bottlenecks between different
   resources can be associated with flows.  However,
   only providing the same query.  Here, abstract network element names without abstract
   network element properties is not enough, because ALTO clients often
   require the cost path
   vector of information on specific metric values like the (Filtered) Cost Map/Endpoint Cost Service and link
   capacity.  This document adopts the property map defined in a recent
   draft [I-D.roome-alto-unified-props] to encode the properties of the
   abstract network elements of elements.  A new domain "ane" is registered in the
   property map.  Each entity in the "ane" domain is an abstract network
   element.  The property map which supports "ane" domain is an Abstract
   Network Element Property Map are generated at Map.

4.4.  New Media Type: multipart/related

   In the same time and they are related.
   So, a query-specific attribute "query-id" is introduced base ALTO protocol, ALTO servers use media types in the "vtag" HTTP
   header to express such information.  Also, indicate the input parameters type of the
   Network Element Property Map is extended to support the query-
   specific queries.

5.  Protocol Extensions

   This section formally specifies the path-vector extension which
   includes the following components: response.  Typically one response
   only contains a new cost single media type, a new entity
   domain, extensions such as "application/alto-
   costmap+json" or "application/alto-propmap+json".  This has limited
   the capability of (Filtered) Cost Map and Endpoint Cost Map.
   Below we specify each component ALTO servers to return multiple services in details.

5.1.  Cost Type

   The path-vector extension a
   single response.

   Thus, an ALTO client MUST make multiple queries to get the
   information from services of different types.  This has led to the
   data synchronization problem between dependent ALTO services because
   when making the second query, the result for the first query may have
   already changed.  The very same problem can happen to Network Map and
   Cost Map resources.  However, unlike Network Map and Cost Map which
   are considered more stable, path vectors and the dependent abstract
   network element property maps might change more frequently.

   Instead of introducing a new media type to encapsulate multiple types
   in a single response, this documents adopts the "multipart" media
   type defined in [RFC2387].  Thus, a response can contain both the
   path vector as a Cost Map (or Endpoint Cost Map) and the
   corresponding abstract network element property map as a Property
   Map. The media types of the path vector and the abstract network
   element property map can still be retrieved from the response,
   achieving consistency with the base ALTO protocol.

   For backward compatibility, this extension also allows ALTO clients
   to make multiple queries instead of encapsulating abstract network
   element property map along with the path vector.  Thus, each Cost Map
   or Endpoint Cost Service with this extension MUST include a "prop-
   map" in their capabilities to indicate where to retrieve the network
   element properties.  An additional field "query-id" MUST also be
   added to the "vtag" field to uniquely identify a path vector query
   session.

5.  Path-Vector Extension: Basic Data Types

   This section formally specifies the path-vector extension of some
   basic data types.

5.1.  Cost Type

   This document enriches extends the cost types defined in Section 6.1 of [RFC7285].
   [RFC7285] by introducing a new cost mode "array" and a new cost
   metric "ane-path".

5.1.1.  Cost Metric

   This document specifies a new cost metric: "ane". "ane-path".  It is of type
   CostMetric as defined in Section 10.6 of [RFC7285].  The cost metric
   "ane"
   "ane-path" MUST NOT be used when the cost mode is not "path-vector" "array" unless
   it is explicitly specified in by a future extension.  Meanwhile, an ALTO
   server with path-vector extension MUST support the cost metric "ane". "ane-
   path".

   Cost metric "ane": "ane-path":  This cost metric MUST be encoded as the
      JSONString "ane".  When cost metric is "ane", Network Element
      Names contained in the path vectors MUST be query-specific. "ane-path".

5.1.2.  Cost Mode: Path Vector Mode

   This document specifies a new cost mode: "path-vector".  The path-
   vector cost mode is of type extends the CostMode as defined in Section 6.1.2 10.5 of
   [RFC7285] and with a new cost mode: "array".  The extended CostMode is
   encoded as the JSONString "path-vector".

   A (Filtered) Cost Map resource or Endpoint Cost Service, when queried
   with this cost mode, a string and MUST return have a CostMapData or EndpointCostMapData
   whose cost value is a JSONArray of type NetworkElementName as
   specified in Section 5.3.

   This cost mode MUST be used with the cost metric "ane" either "numerical",
   "ordinal" or "array" unless it is explicitly specified by a future
   extension.

5.2.  Version Tag

   To support  In particular, this extension has specified that when the concept of query specific, a new field named "query-
   id"
   cost metric is introduced to correlate the query information between the
   (Filtered) Cost Map/Endpoint Cost Service response and "ane-path", the
   corresponding property map query.  The object VersionTag as defined
   in Section 10.3 of [RFC7285] is extended cost value MUST be interpreted as follows:

     object {
       ResourceID   resource-id;
       JSONString   tag;
       [JSONString  query-id;]
     } VersionTag;

   resource-id, tag:  As defined in Section 10.3 a
   JSONArray of [RFC7285].

   query-id:  A string used to uniquely identify the abstract network
      elements in the property map.

5.3. Abstract Network Element Name

   This document also extends [RFC7285] with a new basic data type:
   NetworkElementName.  A NetworkElementName is of type EntityAddr as
   defined Names (defined in Section 2.3 5.3).

   An ALTO cost service MUST return a JSONArray of [I-D.roome-alto-unified-props] and JSONValue when the
   cost mode is
   encoded as a JSONString.  A NetworkElementName "array" unless the interpretation is explicitly
   specified by an ALTO extension.

   Cost mode "array":  This cost mode MUST be an EntityAddr
   of encoded as the ANE domain (Section 5.4).

5.4. JSONString
      "array".

5.2.  ANE Domain

   This document specifies a new domain in addition to the ones in
   [I-D.roome-alto-unified-props].

5.4.1. [I-
   D.roome-alto-unified-props].

5.2.1.  Domain Name

   ane

5.4.2.

5.2.2.  Domain-Specific Entity Addresses

   The entity address of ane domain is encoded as a JSON string.  The
   string MUST be no more than 64 characters, and it MUST NOT contain
   characters other than US-ASCII alphanumeric characters
   (U+0030-U+0039, U+0041-U+005A, and U+0061-U+007A), the hyphen ('-',
   U+002D), the colon (':', U+003A), the at sign ('@', code point
   U+0040), the low line ('_', U+005F), or the '.' separator (U+002E).
   The '.' separator is reserved for future use and MUST NOT be used
   unless specifically indicated in this document, or an extension
   document.

5.5.  Filtered

5.3.  Abstract Network Element Property Map

   A Filtered Name

   An Abstract Network Element Property Map Name MUST be a Filtered Property
   Map encoded as an EntityAddr as
   defined in Section 5 of [I-D.roome-alto-unified-props].

5.5.1.  Accept Input Parameters 5.2.2.  It MUST belong to the "ane" domain.

5.4.  Version Tag

   This document extends ReqFilteredPropertyMap the VersionTag, previously defined in
   Section 5.3 10.3 of [I-D.roome-alto-unified-props] by introducing [RFC7285] with an optional field
   named "query-id".  The ReqFilteredPropertyMap is extended as follows:  If an
   ALTO cost service supports the path-vector extension, this field MUST
   be included in the "vtag" field, and the "vtag" field MUST be
   included in the "meta" field in the response in order to provide the
   "query-id" information.

     object {
       EntityAddr     entities<1..*>
       PropertyName   properties<1..*>;
       ResourceID   resource-id;
       JSONString   tag;
       [JSONString  query-id;]
     } ReqFilteredPropertyMap;

   entities, properties:  The same as VersionTag;

   resource-id, tag:  As defined in Section 5.3 10.3 of
      [I-D.roome-alto-unified-props]. [RFC7285].

   query-id:  Like the "query-id" defined in Section 5.2, the "query-id"
      here is also a  A string used to uniquely identify the abstract network elements
      element names in the property map.

5.5.2.  Capabilities

   A Network Element Property Map MUST have capabilities "domain-types" response and "prop-types" as defined in Section 4.4 of
   [I-D.roome-alto-unified-props].  The "domain-types" capability MUST
   contain domain "ane".  And the "prop-types" capability correlate abstract network
      element names with abstract network element properties.  A "query-
      id" MUST be a
   subset of property types which are registered with the "ALTO Network
   Element Property Type Registry" defined encoded in Section 11.4 of this
   document.

5.5.3.  Response

   The response is the same as for the Property Map, format as defined in Section 4.6 10.1
      of [I-D.roome-alto-unified-props], except that only the
   requested entities and properties are returned for Filtered Network
   Element Map. Examples can be found in Section 6.6 [RFC7285].

6.  Path-Vector Extension: Services

   This section extends IRDResourceEntry, Cost Map Service and Section 6.7.

5.6. Endpoint
   Cost Service.

6.1.  IRD Extensions

   This document extends IRDResourceEntry defined in Section 9.2.2 of
   [RFC7285] by introducing a new entry named "propertymap". "property-map", which
   indicates where the specific properties of the abstract network
   elements can be retrieved.  The IRDResourceEntry object is extended
   as follows:

     object {
       JSONString uri;
       JSONString media-type;
       [JSONString accepts;]
       [Capabilities capabilities;]
       [ResourceID uses<0..*>;]
       [ResourceID propertymap<0..*>;] property-map;]
     } IRDResourceEntry;

   uri, media-type, accepts, capabilities, uses:  The same as defined in
      Section 9.2.2 of [RFC7285].

   propertymap:

   property-map:  A list of resource IDs, ID defined in the same IRD, that
      indicates where the specific properties of the returned IRD pointing to an
      abstract network elements can be retrieved.

5.7. element property map as defined in Section 2.

6.2.  Cost Map Extensions

   This document extends the Cost Map defined in Section 11.2.3 of [RFC7285]
   by returning JSONArray instead of JSONNumber as
   [RFC7285].

   The specifications for "HTTP method", "accept input parameters" and
   "uses" are the cost value,
   including "vtag" same as defined in "meta" field Section 11.2.3 of [RFC7285].

6.2.1.  Media Type

   The path vector extension now enables ALTO clients to receive
   multiple services in the response, and adding a new
   field referencing to cost map response.

   Specifically, if an ALTO client accepts "multipart/related",
   "application/alto-costmap+json" and "application/alto-propmap+json"
   at the same time, the ALTO server MUST use "multipart/related" as the Network Element Property Map.

   The
   media type, type in the HTTP method, capabilities, accept input parameter and
   uses specifications are unchanged.

5.7.1.  Propertymap header.

6.2.2.  Capabilities

   If a service supports the Cost Map path-vector extension, the "cost-type-
   names" field MUST include a single cost type with "ane-path" as cost
   metric and "array" as cost mode.

6.2.3.  Property-map

   If a service supports the path-vector extension, the "property-map"
   field MUST be specified.  This field
   "propertymap" provides is a list of resource ids ID of Network Element
   Property Map. Each an abstract
   network element property map resource provides
   properties for where the dynamically generated abstract network elements.

5.7.2. element
   properties are provided.

6.2.4.  Response

   The response is the same

   If an ALTO client accepts "multipart/related" as defined in
   Section 6.3.1, HTTP body of the response MUST consists of two parts
   with the media types "application/alto-costmap+json" and
   "application/alto-propmap+json" accordingly.  Specifically, the part
   with media type "application/alto-costmap+json" MUST be the first
   part.

   The content of the "application/alto-costmap+json" part uses the
   format in Section 11.2.3.6 of [RFC7285]
   except with the follows: following
   constraints:

   o  If  The cost value for a path vector query, e.g. the cost mode is "path-vector",
      "array" and the cost metric is "ane-path", MUST be encoded as a
      JSONArray of
      Network Element Names. AbstractNetworkElementName.

   o  If the query sent by the client includes cost type path vector,
      the "vtag" filed field defined in Section 5.2 5.4 has to be included in the
      response.  And the "query-id" information in "vtag" MUST be
      provided to ALTO clients.

5.8.

6.3.  Filtered Cost Map Extensions

   This document extends the Filtered Cost Map defined in Section 4.1 of
   [I-D.ietf-alto-multi-cost] by specifying details on capabilities,
   returning JSONArray instead of JSONNumber as the cost value,
   including "vtag" in "meta" field in the response, and adding a new
   field referencing to the Network Element Property Map.
   [I-D.ietf-alto-multi-cost].

   The media type, HTTP method and uses specifications for "HTTP method" and "uses" are unchanged.

5.8.1. the same as
   defined in Section 4.1 of [I-D.ietf-alto-multi-cost].

6.3.1.  Media Type

   The same as Section 6.2.1.

6.3.2.  Capabilities

   The FilteredCostMapCapabilities object is has the same format as defined
   in Section 4.1.1 of [I-D.ietf-alto-multi-cost] expect with the follow: following
   constraint:

   testable-cost-type-names:  Cost  The path vector cost type "path-vector" with "ane-path"
      as the cost metric and "array" as the cost mode MUST NOT appear be
      included in
      the "testable-cost-type-names" field.

5.8.2. "testable-cost-type-names".

6.3.3.  Property-map

   The same as Section 6.2.3.

6.3.4.  Accept Input Parameters

   The ReqFilteredCostMap uses the same format as defined in
   Section 4.1.2 of
   [I-D.ietf-alto-multi-cost] is extended, [I-D.ietf-alto-multi-cost], with the meanings and the
   constraints of some fields are also extended.

     object {
       [CostType cost-type;]
       [CostType multi-cost-types<1..*>;]
       [CostType testable-cost-types<1..*>;]
       [JSONString constraints<0..*>;]
       [JSONString or-constraints<1..*><1..*>;]
       [PIDFilter pids;]
       [PIDFlowFilter pid-flows<1..*>;]
     } ReqFilteredCostMap;

     object {
       PIDName src;
       PIDName dst;
     } PIDFlowFilter;

   cost-type:  If following
   constraints:

   constraints, or-constraints:  If the path vector cost type is path-vector and neither the
      "testable-cost-type-names" field is provided by the server nor the
      "testable-cost-types" field is provided by the client, the
      "constraints" field and the "or-constraints" field SHOULD
      included in either "cost-type" or "multi-cost-types", ALTO clients
      MUST NOT
      appear.  If not, use it in "constraints" or "or-constraints".  Otherwise,
      the ALTO server MUST return an error with error code E_INVALID_FIELD_VALUE.  The server MAY include an optional
      field named "field" in the "meta" field of the response, the value
      of "field" is "constraints" or "or-constraints".
      "E_INVALID_FIELD_VALUE".

   testable-cost-types:  The server MAY
      also include an optional field named "value" in the "meta" field,
      the value of "value" is "path-vector".  If the "value" field is
      specified, the "field" field MUST be specified.

   multi-cost-types:  If "multi-cost-types" includes cost type path-
      vector, meanwhile, neither the "testable-cost-type-names" field is
      provided by the server nor the "testable-cost-types" field is
      provided by the client, the path vector cost type index of path-vector MUST NOT appear be included
      in the "constraints" field or the "or-constraints" "testable-cost-types" field.  If not,  Otherwise, the ALTO server
      MUST return an error with error code E_INVALID_FIELD_VALUE.  The server MAY include "E_INVALID_FIELD_VALUE".

6.3.5.  Response

   If an optional
      field named "field" ALTO client accepts "multipart/related" as defined in
   Section 6.3.1, HTTP body of the "meta" field response MUST consist of two parts
   with the response, media types "application/alto-costmap+json" and
   "application/alto-propmap+json" accordingly.  Specifically, the value
      of "field" is "constraints" or "or-constraints". part
   with media type "application/alto-costmap+json" MUST be the first
   part.

   The server MAY
      also include an optional field named "value" in content of the "meta" field, "application/alto-costmap+json" part has the value same
   format as defined in Section 4.1.3 of "value" is "path-vector".  If [I-D.ietf-alto-multi-cost] with
   the "value" field is
      specified, following constraints:

   o  When the "field" field MUST be specified.

   testable-cost-types:  "testable-cost-types" SHOULD NOT include path- path vector cost type.  If "testable-cost-types" contains path-vector
      cost type, the ALTO server MUST return an error with error code
      E_INVALID_FIELD_VALUE.  The server MAY include an optional field
      named "field" type is included in "cost type" or
      "multi-cost-type", the "meta" field corresponding cost value MUST be encoded as
      a JSONArray of the response, the value of
      "filed" is "testable-cost-types/cost-mode".  The server MAY also
      include an optional field named "value" in the "meta" field, the
      value of "value" is "path-vector".  If the "value" field is
      specified, the "field" field MUST be specified.

   pid-flows:  A list of PID src to PID dst for which path costs are to
      be returned.

   Additional requirement is that the Client MUST specify either "pids"
   or "pid-flows", but MUST NOT specify both.

5.8.3.  Propertymap

   If the Filtered Cost Map supports the path-vector extension, the
   field "propertymap" provides a list of resource ids of Network
   Element Property Map. Each network element property map resource
   provides properties for the dynamically generated abstract network
   elements.

5.8.4.  Response

   The response is the same as defined in Section 4.1.3 of
   [I-D.ietf-alto-multi-cost] except the follows:

   o  Whether the "cost-type" field or the "multi-cost-types" field
      includes cost type path-vector, the cost is a JSONArray of Network
      Element Names.

   o  If AbstractNetworkElementName.

   o  If the query sent by the client includes cost type path vector,
      the "vtag" filed field defined in Section 5.2 5.4 has to be included in the
      response.  And the "query-id" information in "vtag" MUST be
      provided to ALTO clients.

5.9.

6.4.  Endpoint Cost Service Extensions

   This document extends the Endpoint Cost Service defined in
   Section 4.2 in [I-D.ietf-alto-multi-cost] by specifying details on
   capabilities, returning JSONArray instead of JSONNumber as [I-D.ietf-alto-multi-cost].

   The specifications for "HTTP method" and "uses" are the cost
   value, including "vtag" same as
   defined in "meta" field Section 4.2 in [I-D.ietf-alto-multi-cost].

6.4.1.  Media Type

   The path vector extension now enables ALTO clients to receive
   multiple objects from the response, endpoint cost service response.

   Specifically, if an ALTO client accepts "multipart/related",
   "application/alto-endpointcost+json" and adding a
   new field referencing to "application/alto-
   propmap+json" at the same time, the ALTO server MUST use "multipart/
   related" as the Network Element Property Map.

   The media type, type in the HTTP method and uses specifications are unchanged.

5.9.1. header.

6.4.2.  Capabilities

   The same as defined in Section 5.8.1.

5.9.2. 6.3.2.

6.4.3.  Property-map

   The same as Section 6.2.3.

6.4.4.  Accept Input Parameters

   The ReqFilteredCostMap ReqEndpointCostMap uses the same format as defined in
   Section 4.1.2 4.2.2 of
   [I-D.ietf-alto-multi-cost] is extended, [I-D.ietf-alto-multi-cost], with the meanings following
   constraints:

   cost-type, multi-cost-types:  ALTO clients MUST include the path
      vector cost type, e.g.  the one with "ane-path" as cost metric and
      "array" as cost mode, in either "cost-type" or "multi-cost-types"
      to activate the
   constraints of some fields are also extended.

   ``` object { [CostType cost-type;][CostType multi-cost-types<1..*>;]
   [CostType testable-cost-types<1..*>;][JSONString constraints<0..*>;]
   [JSONString or-constraints<1.._><1.._>;][EndpointFilter endpoints;]
   [EndpointFlowFilter endpoint-flows<1..*>;] } ReqEndpointCostMap;

   object { TypedEndpointAddr src; TypedEndpointAddr dst; }
   EndpointFlowFilter; ```

   cost-type: path vector extension.

   constraints, or-constraints:  If the path vector cost type is path-vector and neither the
      "testable-cost-type-names" field is provided by the server nor the
      "testable-cost-types" field is provided by the client, the
      "constraints" field and the "or-constraints" field SHOULD
      included in either "cost-type" or "multi-cost-types", ALTO clients
      MUST NOT
      appear.  If not, use it in "constraints" or "or-constraints".  Otherwise,
      the ALTO server MUST return an error with error code E_INVALID_FIELD_VALUE.  The server MAY include an optional
      field named "field" in the "meta" field of the response, the value
      of "field" is "constraints" or "or-constraints".
      "E_INVALID_FIELD_VALUE".

   testable-cost-types:  The server MAY
      also include an optional field named "value" in the "meta" field,
      the value of "value" is "path-vector".  If the "value" field is
      specified, the "field" field MUST be specified.

   multi-cost-types:  If "multi-cost-types" includes cost type path-
      vector, meanwhile, neither the "testable-cost-type-names" field is
      provided by the server nor the "testable-cost-types" field is
      provided by the client, the path vector cost type index of path-vector MUST NOT appear be included
      in the "constraints" field or the "or-constraints" "testable-cost-types" field.  If not,  Otherwise, the ALTO server
      MUST return an error with error code E_INVALID_FIELD_VALUE.  The server MAY include "E_INVALID_FIELD_VALUE".

6.4.5.  Response

   If an optional
      field named "field" ALTO client accepts "multipart/related" as defined in the "meta" field of the response, the value
   Section 6.4.1, HTTP body of "field" is "constraints" or "or-constraints".  The server MAY
      also include an optional field named "value" in the "meta" field, the value response MUST consist of "value" is "path-vector".  If two parts
   with the "value" field is
      specified, media types "application/alto-endpointcost+json" and
   "application/alto-propmap+json" accordingly.  Specifically, the "field" field part
   with media type "application/alto-endpointcost+json" MUST be specified.

   testable-cost-types:  "testable-cost-types" SHOULD NOT include path-
      vector cost type.  If "testable-cost-types" contains path-vector
      cost type, the ALTO server MUST return an error with error code
      E_INVALID_FIELD_VALUE.
   first part.

   The server MAY include an optional field
      named "field" in the "meta" field content of the response, "application/alto-endpointcost+json" part has the value
   same format as defined in Section 4.2.3 of
      "filed" [I-D.ietf-alto-multi-cost]
   with the following constraints:

   o  When the path vector cost type is "testable-cost-types/cost-mode".  The server MAY also
      include an optional field named "value" included in "cost type" or
      "multi-cost-type", the "meta" field, the corresponding cost value MUST be encoded as
      a JSONArray of "value" is "path-vector". AbstractNetworkElementName.

   o  If the "value" field is
      specified, the "field" field MUST be specified.

   endpoint-flows:  A list of endpoint src to endpoint dst for which
      path costs are to be returned.

   Additional requirement is that the Client MUST specify either
   "endpoints" or "endpoint-flows", but MUST NOT specify both.

5.9.3.  Propertymap

   If the Endpoint Cost Service supports the path-vector extension, the
   field "propertymap" provides a list of resource ids of Network
   Element Property Map. Each network element property map resource
   provides properties for the dynamically generated abstract network
   elements.

5.9.4.  Response

   The response is the same as defined in Section 4.2.3 of
   [I-D.ietf-alto-multi-cost] except the follows:

   o  Whether the "cost-type" field or the "multi-cost-types" field
      includes cost type path-vector, the cost is a JSONArray of Network
      Element Names.

   o  If the query sent by query sent by the client includes cost type path vector,
      the "vtag" filed field defined in Section 5.2 5.4 has to be included in the
      response.  And the "query-id" information in "vtag" MUST be
      provided to ALTO clients.

6.

7.  Examples

   This section lists a series of examples to proceed the multi-flow flow
   scheduling like the use case in Section 3.

   The recommended

7.1.  Workflow

   This section gives a typical workflow is like of an ALTO client using the following:

6.1.  Workflow

   o
   path-vector extension.

   1.  Send the a GET request for the whole Information Resource Directory.

   o

   2.  Look for the resource of the (Filtered) Cost Map/Endpoint Cost
       Service which contains the path-vector path vector cost type and get the
       resource id ID of the dependent abstract network element property
       map.

   o  Look for

   3.  Check whether the resource capabilities of the property map to check whether it
      supports includes the
       desired "prop-types".

   o

   4.  Send a path-vector request to which accepts "multipart/related"
       media type following Section 6.2.1, Section 6.3.1 or
       Section 6.4.1.

   Alternatively, one can replace step 4 with the (Filtered) Cost Map/Endpoint Cost Service and
      get following:

   1.  Send a path-vector request which accepts "application/alto-
       costmap+json" or "application/alto-endpointcost+json".

   2.  Find the response with "query-id" information.  Meanwhile, in "vtag" in the
      properties of response.

   3.  Query the returned dependent abstract network elements are generated
      in the corresponding Network Element Property Map.

   o  Send request to the Network Element Property Map element property map with
       the returned
      "query-id" information query ID and get abstract network element names to retrieve the response.

6.2.
       associated properties.

7.2.  Information Resource Directory Example

   Here is an example of an ALTO server's Information Resource Directory.  In this
   example, both "filtered-multi-cost-map" and
   "default-endpoint-cost-map" filtered cost map "cost-map-pv" doesn't support the multi-
   cost extension but support the path-vector extension, "endpoint-
   multicost-map" supports both multi-cost extension and the path-vector
   extension.  Resource "ane-property-map-availbw"  Filtered Property Map "propmap-delay-availbw" supports
   property
   properties "availbw" and resource "ane-property-map-delay" "delay", and "propmap-location" supports
   property "delay". "location".

     {
       "meta": {
         "cost-types": {
         "pv-ane":
           "pv": {
             "cost-mode": "path-vector", "array",
             "cost-metric": "ane" "ane-path"
           },
         "num-hopcount":
           "num-routingcost": {
             "cost-mode": "numerical",
             "cost-metric": "hopcount" "routingcost"
           },
         "num-routingcost":
           "num-hopcount": {
             "cost-mode": "numerical",
             "cost-metric": "routingcost"
         }, "hopcount"
           }
         }
       },
       "resources": {

       ... NetworkMap Resource ...

       "default-network-map":
         "my-default-networkmap": {
         "uri":
           "uri" : "http://alto.example.com/networkmap",
         "media-type":
           "media-type" : "application/alto-networkmap+json"
       },

       ... Cost Map Resource ...

       "pv-cost-map": {
         "uri": "http://alto.example.com/pv/ane",
         "media-type": "application/alto-costmap+json",
         "capabilities": {
           "cost-type-names": ["pv-ane"]
         },
         "uses": ["default-network-map"],
         "propertymap": ["ane-property-map-delay",
                         "ane-property-map-availbw"]
         }

       ... Multi-Cost Filtered Map Resource ...

       "filtered-multi-cost-map":
         "cost-map-pv" : {
           "uri": "http://alto.example.com/costmap/multi/filtered", "http://alto.example.com/costmap/pv",
           "media-type": "application/alto-costmap+json",
           "accepts": "application/alto-costmapfilter+json",
         "uses": ["default-network-map"],
           "capabilities": {
           "max-cost-types": 3,
             "cost-type-names": ["pv-ane",
                               "num-routingcost",
                               "num-hopcount"],
           "cost-constraints": true [ "pv", "num-hopcount" ]
           },
         "propertymap": ["ane-property-map-delay",
                         "ane-property-map-availbw"]
           "property-map": "propmap-delay",
           "uses": [ "my-default-networkmap" ]
         },

       ... Endpoint Cost Service Resource ...

       "default-endpoint-cost-map":
         "endpoint-multicost-map" : {
           "uri": "http://alto.example.com/endpointcost/lookup", "http://alto.exmaple.com/endpointcostmap/multicost",
           "media-type": "application/alto-endpointcostmap+json", "application/alto-endpointcost+json",
           "accepts": "application/alto-endpointcostparams+json",
           "capabilities": {
           "max-cost-types": 3,
             "cost-constraints": true,
             "cost-type-names": ["pv-ane",
                               "num-routingcost",
                               "num-hopcount"],
           "testable-cost-types-names": ["num-hopcount",
                                         "num-routingcost"], [ "pv", "num-routingcost" ],
             "max-cost-types": 2
           },
         "propertymap": ["ane-property-map-delay"]
       }

       ... Network Element Property Map Resource ...

       "ane-property-map-delay":
           "property-map": "propmap-availbw"
         },
         "propmap-availbw" : {
           "uri": "http://alto.example.com/propmap/lookup/delay", "http://alto.exmaple.com/propmap/availbw",
           "media-type": "application/alto-propmap+json",
           "accepts": "application/alto-propmapparams+json",
           "capabilities": {
             "domain-types": ["ane"], [ "ane" ],
             "prop-types": ["delay"]
         } [ "delay", "availbw" ]
           }

       "ane-property-map-availbw":
         },
         "propmap-delay" : {
           "uri": "http://alto.example.com/propmap/lookup/availbw", "http://alto.exmaple.com/propmap/delay",
           "media-type": "application/alto-propmap+json",
           "accepts": "application/alto-propmapparams+json",
           "capabilities": {
             "domain-types": ["ane"], [ "ane" ],
             "prop-types": ["availbw"] [ "delay" ]
           }
         }
       }

6.3.  Cost Map
     }

7.3.  Single Query Example

   Here is an example of the Cost Map request for path-vector and the
   corresponding response.  In response, the extended "vtag" field is
   included in "meta" to provide "query-id" information.

     GET /costmap/pv/ane # 1

   POST /costmap/pv HTTP/1.1
   Host: alto.example.com
   Accept: application/alto-costmap+json,application/alto-error+json multipart/related, application/alto-costmap+json,
           application/alto-propmap+json, application/alto-error+json
   Content-Length: [TBD]
   Content-Type: application/alto-costmapfilter+json

   {
     "cost-type": {
       "cost-mode": "array",
       "cost-metric": "ane-path"
     },
     "pids": {
       "srcs": [ "PID1" ],
       "dsts": [ "PID2", "PID3" ]
     }

   }

   HTTP/1.1 200 OK
   Content-Length: [TBD]
   Content-Type: multipart/related; boundary=42

   --42
   Content-Type: application/alto-costmap+json

   {
       "meta" :
     "meta": {
         "dependent-vtags" :
       "dependent-vtags": [
         {
           "resource-id": "default-network-map",
           "tag": "5eb2cb7f8d63a9fab71d9b34cbf763436315542f" "75ed013b3cb58f896e839582504f622838ce670f"
         }
       ],
       "cost-type": { "cost-mode": "array", "cost-metric": "ane-path" },

       "vtag": [ {
         "resource-id": "pv-cost-map", "cost-map-pv",
         "tag": "aef527ca2eb7a7566db0597407893e3f8eb1d9dff", "27612897acf278ffu3287c284dd28841da78213",
         "query-id": "query0"
           }
         ],
         "cost-type" : {"cost-mode"  : "pv",
                        "cost-metric": "ane" "query1"
       }
     },
       "cost-map" :

     "cost-map": {
       "PID1": {
         "PID2": ["ane:L001", "ane:L003"], [ "ane:L001", "ane:L003" ],
         "PID3": ["ane:L002", "ane:L004"] },
           "PID2": [ "ane:L001", "ane:L004" ]
       }
     }
   }

   --42
   Content-Type: application/alto-propmap+json

   { "PID1": ["ane:L003", "ane:L002"],
                     "PID3": ["ane:L003", "ane:L004"] },
           "PID3":
     "property-map": { "PID1": ["ane:L004", "ane:L002"],
                     "PID2": ["ane:L004", "ane:L003"] }
       "ane:L001": { "delay": 46},
       "ane:L003": { "delay": 50},
       "ane:L004": { "delay": 70}
     }
   }

6.4.  Multi-Cost Filtered Cost Map

   --42--

7.4.  Single Query Example

   The following example presents the request and response of "filtered-
   multi-cost-map".  In this example, the client is interested in the
   path-vector and numerical routing cost information.  The client uses
   "or-constraints" but all the results satisfy the conditions.  In
   resposne, the extended "vtag" field is included in "meta" to provide
   "query-id" information. # 2

POST /costmap/multi/filtered /endpointcostmap/multicost HTTP/1.1
Host: alto.example.com
Accept: application/alto-costmap+json,application/alto-error+json multipart/related, application/alto-costmap+json,
        application/alto-propmap+json, application/alto-error+json
Content-Length: [TBD]
Content-Type: application/alto-costmapfilter+json

{
  "multi-cost-types": [
    {
      "cost-mode": "path-vector", "array",
      "cost-metric": "ane" "ane-path"
    },
    {
      "cost-mode": "numerical",
      "cost-metric": "routingcost"
    }
  ],
       "testable-cost-types": [
  "endpoints": { "cost-mode": "numerical", "cost-metric": "routingcost" },
         { "cost-mode": "numerical", "cost-metric": "hopcount" }
       ],
       "or-constraints":
    "srcs": [
         ["[0] ge 50", "[1] le 60"] "ipv4:192.0.2.2" ],
       "pid-flows":
    "dsts": [
         { "src": "PID1", "dst": "PID2" },
         { "src": "PID2", "dst": "PID3" } "ipv4:192.0.2.89",
              "ipv4:203.0.113.45",
              "ipv6:2001:db8::10" ]
  }
}

HTTP/1.1 200 OK
Content-Length: [TBD]
Content-Type: application/alto-costmap+json multipart/related; boundary=example-2

--example-2
Content-Type: application/alto-endpointcost+json

{
  "meta": {
         "dependent-vtags":
    "multi-cost-types": [
           {
             "resource-id": "default-network-map",
             "tag": "75ed013b3cb58f896e839582504f622838ce670f"
           }
         ],
      {"cost-mode": "array", "cost-metric": "ane-path"},
      {"cost-mode": "numerical", "cost-metric": "routingcost"}
    ]
    "vtag": [ {
      "resource-id": "filtered-multi-cost-map", "endpoint-multicost-map",
      "tag": "27612897acf278ffu3287c284dd28841da78213", "47612897acf278ffa3287cb84dd28841da78213",
      "query-id": "query1"
           }
         ] "query2"
    }
       "cost-type": {},
       "multi-cost-types": [
         { "cost-mode": "path-vector", "cost-metric": "ane"
  },
  "endpoint-cost-map": { "cost-mode": "numerical",   "cost-metric": "routingcost"}
       ],

       "cost-map": {
         "PID1":
    "ipv4:192.0.2.2": {
           "PID2": [ [
      "ipv4:192.0.2.89":   [[ "ane:L001", "ane:L003" "ane:L003", "ane:L004" ], 77],
      "ipv4:203.0.113.45": [[ "ane:L001", "ane:L004", "ane:L005" ], 68],
      "ipv6:2001:db8::10": [[ "ane:L001", "ane:L005", "ane:L007" ], 98]
    }
  }
}

--example-2
Content-Type: application/alto-propmap+json

{
  "property-map": {
    "ane:L001": { "availbw": 50 },
    "ane:L003": { "availbw": 48 },
    "ane:L004": { "availbw": 55 ] },
         "PID2":
    "ane:L005": {
           "PID3": [ [ "ane:L003", "ane:L004" ], "availbw": 60 ] },
    "ane:L007": { "availbw": 35 }
  }
}

6.5.

--example-2--

7.5.  Multiple Queries Example

7.5.1.  Endpoint Cost Service Example

   If the ALTO client expects the routing state information between
   endpoints, it can also query the "default-endpoint-cost-map" resource
   which supports path vector.  In resposne, the extended "vtag" field
   is included in "meta" to provide "query-id" information.
   POST /endpointcost/lookup /endpointcostmap/multicost HTTP/1.1
   Host: alto.example.com
   Accept: application/alto-endpointcost+json,application/alto-error+json application/alto-costmap+json, application/alto-error+json
   Content-Length: [TBD]
   Content-Type: application/alto-endpointcostparams+json application/alto-costmapfilter+json

   {
     "multi-cost-types": [
       {
         "cost-mode": "path-vector", "array",
         "cost-metric": "ane" "ane-path"
       },
       {
         "cost-mode": "numerical",
         "cost-metric": "hopcount" "routingcost"
       }
     ],
    "endpoint-flows": [
      { "src": "ipv4:192.0.2.2",     "dst": "ipv4:203.0.113.45"  },
      { "src": "ipv4:192.0.2.89",    "dst": "ipv4:198.51.100.34" },
      { "src": "ipv4:194.2.3.67",    "dst": "ipv4:202.56.54.230" },
     "endpoints": { "src": "ipv4:203.32.56.102", "dst": "ipv4:202.76.89.103" }
       "srcs": [ "ipv6:2001:db8::10" ],
       "dsts": [ "ipv4:192.0.2.3",
                 "ipv4:203.0.113.56" ]
     }
   }

   HTTP/1.1 200 OK
   Content-Length: [TBD]
   Content-Type: application/alto-endpointcost+json

   {
     "meta": {
       "vtag": [ {
         "resource-id": "default-endpoint-cost-map", "endpoint-multicost-map",
         "tag": "73182ffa829dc28c218a1823bb1293dea232885", "f7622897bcf278ffu3287c284dd23841da78213",
         "query-id": "query2"
        }
      ],
      "cost-type": {}, "query3"
       },
       "multi-cost-types": [
         { "cost-mode": "path-vector", "array", "cost-metric": "ane" "ane-path" },
         { "cost-mode": "numerical", "cost-metric": "hopcount" } "routingcost"}
       ]
     },
     "endpoint-cost-map": {
      "ipv4:192.0.2.2": {
        "ipv4:203.0.113.45": [ [ "ane:L10", "ane:L11",
                                 "ane:L15", "ane:L16",
                                 "ane:L17", "ane:L13" ], 100]
      },
      "ipv4:192.0.2.89":
       "ipv6:2001:db8::10": {
        "ipv4:198.51.100.34": [
         "ipv4:192.0.2.3":    [ "ane:L14", "ane:L11",
                                  "ane:L12", "ane:L18",
                                  "ane:L19" "ane:L001", "ane:L006" ], 124]
      },
      "ipv4:194.2.3.67": {
        "ipv4:202.56.54.230": [
         "ipv4:203.0.113.56": [ "ane:L21", "ane:L15",
                                  "ane:L16", "ane:L17",
                                  "ane:L18", "ane:L20"], 78]
      },
      "ipv4:203.32.56.102": {
        "ipv4:202.76.89.103": [ [ "ane:L22", "ane:L16",
                                  "ane:L23"], 168] "ane:L001", "ane:L007" ]
       }
     }
   }

6.6.

7.5.2.  Abstract Network Element Property Map Example # 1

   After the client send the query to the Multi-Cost Filtered Cost Map
   "filtered-multi-cost-map" and get the response with query-id "query1"
   (See Section 6.4).  The client send request to the "ane-property-map-
   availbw" with query-id "query1" and get the response.

   POST /propmap/lookup/availbw /propmap/availbw HTTP/1.1
   Host: alto.example.com
   Accept: application/alto-propmap+json,application/alto-error+json
   Content-Length: [TBD]
   Content-Type: application/alto-propmapparams+json

   {
     "query-id": "query1", "query3",
     "entities" :   [ "ane:L001",
                      "ane:L003",
                      "ane:L004"
                      "ane:L006" ],
     "properties" : [ "availbw" ]
   }

   HTTP/1.1 200 OK
   Content-Length: [TBD]
   Content-Type: application/alto-propmap+json

   {
     "property-map": {
       "ane:L001": { "availbw": "50" },
         "ane:L003": { "availbw": "70" 25 },
         "ane:L004":
       "ane:L006": { "availbw": "80" 40 }
     }
   }

6.7.  Network Element Property Map Example # 2

   After the client

8.  Compatibility

8.1.  Compatibility with Legacy ALTO Clients/Servers

   Legacy ALTO clients SHOULD NOT send queries with the query to the Endpoint Cost Service
   "default-endpoint-cost-map" and get the response with query-id
   "query2" (See Section 6.5).  The client send request to the "ane-
   property-map-delay" with query-id "query2" and get the response.

     POST /propmap/lookup/delay HTTP/1.1
     Host: alto.example.com
     Accept: application/alto-propmap+json,application/alto-error+json
     Content-Length: [TBD]
     Content-Type: application/alto-propmapparams+json

     {
       "query-id": "query2",
       "entities" : [ "ane:L11",
                      "ane:L15",
                      "ane:L16",
                      "ane:L18" ],
       "properties" : [ "delay" ]
     }

     HTTP/1.1 200 OK
     Content-Length: [TBD]
     Content-Type: application/alto-propmap+json

     {
       "property-map": {
         "ane:L11": { "delay": "25" },
         "ane:L15": { "delay": "40" },
         "ane:L16": { "delay": "60" },
         "ane:L18": { "delay": "10" }
       }
     }

7.  Compatibility

7.1.  Compatibility with Legacy ALTO Clients/Servers

   Legacy ALTO clients SHOULD NOT send queries with path vector
   extension path-vector
   extension and ALTO servers with this extension SHOULD NOT have any
   compatibility issue.  Legacy ALTO servers do not support cost types
   with the "path-vector" cost mode being "array" and cost metric being "ane-path", so
   they MUST NOT announce the extended cost types in IRD.  Thus, ALTO
   clients MUST NOT send queries specified in this extension to legacy
   ALTO servers according to Section 11.3.2.3 [RFC7285].

7.2.

8.2.  Compatibility with Multi-Cost Extensions

   Path Vector is not a testable cost type.  So two conditions have to
   be satisfied when multi-cost supports path-vector extension.  Any format of constraints SHOULD NOT be applied to cost type path-vector.

   o  Cost type path-vector MUST NOT be included in "testable-cost-
      types-names" or "testable-cost-types".

   o  When "testable-cost-types-names" is omitted in the "capabilities"
      and "testable-cost-types" is omitted in the input parameters,
      "constraints" or "or-constraints" SHOULD NOT add any format of
      constraints on cost type path-vector.

7.3.  Compatibility with Incremental Update

   There is no compatibility issue with incremental update extension.

8.  Time to live

   The Network Element Property Map is dynamically enriched when the
   (Filtered) Cost Map/Endpoint Cost Service is queried of the path-
   vector information.  The properties of the abstract network elements
   can consume a large amount of resources when cached.  So, a time-to-
   live is needed to remove outdated entries in the Network Element
   Property Map.

9.  Design Decisions and Discussions

9.1.  Path Vector or Path Graph

   When we introduce the "path-vector" as a cost mode in the Cost Map,
   an unavoidable problem is how to handle multipath.  Because a PID is
   a group of endpoints, it is common that there are multiple paths
   between two PIDs.  The valid routing state information is all of the
   accessible paths.  So in this scenario, the Cost Map Resource SHOULD
   provide the cost values including of the multiple paths.

   A natural solution is to provide an array of path vectors as the cost
   value.  Every path vector in this array means an accessible path
   between the source PID and the destination PID.  It is different from
   the solution of the path vector extension which provides an array of
   network elements.  So it requires to introduce a different cost mode.
   This document proposes this new cost mode named "path-graph".

   However, the "path-graph" will increase the complexity of the Cost
   Map Response.  Since the applications select ALTO as the protocol to
   get the network information rather than other topology-based solution
   such as I2RS, the major reason should be the simplicity.  If we
   provide "path-graph" for each PID pairs, the ALTO client has to
   handle the complex data structure.

   What's more, the "path-vector" is powerful enough
   SHOULD NOT be applied to express multiple
   paths.  The simple solution is cost type path-vector in order for multi-
   cost to list support the network elements of all
   accessible paths path-vector extension.  Specifically,

   o  Cost type path-vector MUST NOT be included in "testable-cost-
      types-names" or "testable-cost-types".

   o  When "testable-cost-types-names" is omitted in a single path vector.  This solution will lose the information about paths.  Another solution "capabilities"
      and "testable-cost-types" is to define omitted in the path
   as a new type input parameters,
      "constraints" or "or-constraints" SHOULD NOT add any format of network elements.  In this way,
      constraints on cost type path-vector.

8.3.  Compatibility with Incremental Update

   Without considering the path vector can
   provide an array of paths.  Each element of this array contains a
   path vector incremental update of network elements in multipart/related
   information, there is no compatibility issue with incremental update
   extension.  Compatibility issue with the Network Element Property Map.

   So incremental update of
   multipart/related information will be discussed and addressed in this document, we just introduce "path-vector" as the only
   required cost mode for routing state information.

9.2.
   next version.

9.  Design Decisions and Discussions

9.1.  Provide More General Calendar Extension

   Cost Calendar is proposed as a useful ALTO extension to provide the
   historical cost values for Filtered Cost Map Service and Endpoint
   Cost Service.  Since path vector is an extension to these services,
   it SHOULD be compatible with Cost Calendar extension.

   However, the calendar of a path-vector (Endpoint) Cost Map is
   insufficient for the application which requires the historical data
   of routing state information.  The (Endpoint) Cost Map can only
   provide the changes of the paths.  But more useful information is the
   history of network element properties which are recorded in the
   dependent Network Element Property Map.

   Before the Unified Property Map is introduced as an ALTO extension,
   Filtered Cost Map Service and Endpoint Cost Service are the only
   resources which require the calendar supported.  Because other
   resources don't have to be updated frequently.  But Network Element
   Property Map as a use case of Unified Property Map will collect the
   real-time information of the network.  It SHOULD be updated as soon
   as possible once the metrics of network elements change.

   So the requirement is to provide a general calendar extension which
   not only meets the Filtered Cost Map and Endpoint Cost Service but
   also applies to the Property Map Service.

9.3.  Snapshot and real-time update

   As the suggested workflow mentioned in Section 6.1, the properties of
   the abstract network elements are computed ahead of the query of
   these properties.  So the properties of abstract network elements are
   likely to be snapshot rather than realt-time value when queried.

10.  Security Considerations

10.1.  Privacy Concerns

   We can identify multiple potential security issues.  A main security
   issue is network privacy, as the path-vector information may reveal
   more network internal structures than the more abstract single-node
   abstraction.  The network should consider protection mechanisms to
   reduce information exposure, in particular, in settings where the
   network and the application do not belong to the same trust domain.
   On the other hand, in a setting of the same trust domain, a key
   benefit of the path-vector abstraction is reduced information
   transfer from the network to the application.

   The path-vector query may also reveal more information about the
   application.  In particular, the application may reveal all potential
   transfers sites (e.g., where the data source is replicated, and where
   the potential replication sites are).  The application should
   evaluate the potential privacy concerns.

   Beyond the privacy issues, the computation of the path-vector is
   unlikely to be cachable, in that the results will depend on the
   particular requests (e.g., where the flows are distributed).  Hence,
   this service may become an entry point for denial of service attacks
   on the availability of an ALTO server.  Hence, authenticity and
   authorization of this ALTO service may need to be better protected.

10.2.  Resource Consumption on ALTO Servers

   The Abstract Network Element Property Map is dynamically enriched
   when the (Filtered) Cost Map/Endpoint Cost Service is queried of the
   path-vector information.  The properties of the abstract network
   elements can consume a large amount of resources when cached.  So, a
   time-to-live is needed to remove outdated entries in the Network
   Element Property Map.

11.  IANA Considerations

11.1.  ALTO Cost Mode Registry

   This document specifies a new cost mode "path-vector". "array".  However, the base
   ALTO protocol does not have a Cost Mode Registry where new cost mode
   can be registered.  This new cost mode will be registered once the
   registry is defined either in a revised version of [RFC7285] or in
   another future extension.

11.2.  ALTO Cost Metric Registry

   A new cost metric needs to be registered in the "ALTO Cost Metric
   Registry", listed in Table 1. 2.

                   +-------------+---------------------+
                   | Identifier  | Intended Semantics  |
                   +-------------+---------------------+
                   | ane ane-path    | See Section 5.1.1   |
                   +-------------+---------------------+

                        Table 1: 2: ALTO Cost Metrics

11.3.  ALTO Entity Domain Registry

   As proposed in Section 9.2 of [I-D.roome-alto-unified-props], "ALTO
   Entity Domain Registry" is requested.  Besides, a new domain is to be
   registered, listed in Table 2. 3.

   +-------------+--------------------------+--------------------------+
   | Identifier  | Entity Address Encoding  | Hierarchy & Inheritance  |
   +-------------+--------------------------+--------------------------+
   | ane         | See Section 5.4.2 5.2.2        | None                     |
   +-------------+--------------------------+--------------------------+

                        Table 2: 3: ALTO Entity Domain

11.4.  ALTO Network Element Property Type Registry

   The "ALTO Abstract Network Element Property Type Registry" is
   required by the ALTO Entity Domain "ane", listed in Table 3. 4.

                +-------------+--------------------------+
                | Identifier  | Intended Semantics       |
                +-------------+--------------------------+
                | availbw     | The available bandwidth  |
                | delay       | The transmission delay   |
                +-------------+--------------------------+

           Table 3: 4: ALTO Abstract Network Element Property Types

12.  Acknowledgments

   The authors would like to thank discussions with Andreas Voellmy,
   Erran Li, Haibin Son, Haizhou Du, Jiayuan Hu, Qiao Xiang, Tianyuan
   Liu, Xiao Shi, Xin Wang, and Yan Luo.

13.  References
13.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

13.2.  Informative References

   [I-D.amante-i2rs-topology-use-cases]
              Medved, J., Previdi, S., Lopez, V., and S. Amante,
              "Topology API Use Cases", draft-amante-i2rs-topology-use-
              cases-01 (work in progress), October 2013.

   [I-D.bernstein-alto-topo]
              Bernstein, G., Yang, Y., and Y. Lee, "ALTO Topology
              Service: Uses Cases, Requirements, and Framework", draft-
              bernstein-alto-topo-00 (work in progress), October 2013.

   [I-D.clemm-i2rs-yang-network-topo]
              Clemm, A., Medved, J., Tkacik, T., Varga, R., Bahadur, N.,
              and H. Ananthakrishnan, "A YANG Data Model for Network
              Topologies", draft-clemm-i2rs-yang-network-topo-01 (work
              in progress), October 2014.

   [I-D.gao-alto-fcs]
              Gao, K., Zhang, J., Wang, J., Xiang, Q., and Y. Yang,
              "ALTO Extension: Flow-based Cost Query", draft-gao-alto-
              fcs-01 (work in progress), March 2017.

   [I-D.ietf-alto-cost-calendar]
              Randriamasy, S., Yang, Y., Wu, Q., Lingli, D., and N.
              Schwan, "ALTO Cost Calendar", draft-ietf-alto-cost-
              calendar-01 (work in progress), February 2017.

   [I-D.ietf-alto-incr-update-sse]
              Roome, W. and Y. Yang, "ALTO Incremental Updates Using
              Server-Sent Events (SSE)", draft-ietf-alto-incr-update-
              sse-03 (work in progress), September 2016.

   [I-D.ietf-alto-multi-cost]
              Randriamasy, S., Roome, W., and N. Schwan, "Multi-Cost
              ALTO", draft-ietf-alto-multi-cost-07 (work in progress),
              March 2017.

   [I-D.lee-alto-app-net-info-exchange]
              Lee, Y., Bernstein, G., Choi, T., and D. Dhody, "ALTO
              Extensions to Support Application and Network Resource
              Information Exchange for High Bandwidth Applications",
              draft-lee-alto-app-net-info-exchange-02 (work in
              progress), July 2013.

   [I-D.roome-alto-unified-props]
              Roome, W., "Extensible Property Maps for the ALTO
              Protocol", draft-roome-alto-unified-props-01 (work in
              progress), July 2016.

   [RFC2387]  Levinson, E., "The MIME Multipart/Related Content-type",
              RFC 2387, DOI 10.17487/RFC2387, August 1998,
              <http://www.rfc-editor.org/info/rfc2387>.

   [RFC7285]  Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S.,
              Previdi, S., Roome, W., Shalunov, S., and R. Woundy,
              "Application-Layer Traffic Optimization (ALTO) Protocol",
              RFC 7285, DOI 10.17487/RFC7285, September 2014,
              <http://www.rfc-editor.org/info/rfc7285>.

Authors' Addresses

   Greg Bernstein
   Grotto Networking
   Fremont, CA
   USA

   Email: gregb@grotto-networking.com

   Shiwei Dawn Chen
   Tongji University
   4800 Caoan Road
   Shanghai  201804
   China

   Email: dawn_chen_f@hotmail.com

   Kai Gao
   Tsinghua University
   Beijing  Beijing
   China

   Email: gaok12@mails.tsinghua.edu.cn
   Young Lee
   Huawei
   TX
   USA

   Email: leeyoung@huawei.com

   Wendy Roome
   Nokia/Bell Labs
   600 Mountain Ave, Rm 3B-324
   Murray Hill, NJ  07974
   USA

   Phone: +1-908-582-7974
   Email: wendy.roome@nokia.com

   Michael Scharf
   Nokia
   Germany

   Email: michael.scharf@nokia.com

   Y. Richard Yang
   Yale University
   51 Prospect St
   New Haven  CT
   USA

   Email: yry@cs.yale.edu

   Jingxuan Jensen Zhang
   Tongji University
   4800 Caoan Road
   Shanghai  201804
   China

   Email: jingxuan.n.zhang@gmail.com