[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 draft-ietf-alto-path-vector

ALTO WG                                                     G. Bernstein
Internet-Draft                                         Grotto Networking
Intended status: Standards Track                                 S. Chen
Expires: September 14, 2017                            Tongji University
                                                                  K. Gao
                                                     Tsinghua University
                                                                  Y. Lee
                                                                  Huawei
                                                                W. Roome
                                                               M. Scharf
                                                                   Nokia
                                                                 Y. Yang
                                                         Yale University
                                                                J. Zhang
                                                       Tongji University
                                                          March 13, 2017


                 ALTO Extension: Path Vector Cost Mode
                   draft-yang-alto-path-vector-04.txt

Abstract

   The Application-Layer Traffic Optimization (ALTO) Service has defined
   network and cost maps to provide basic network information, where the
   cost maps allow only scalar (numerical or ordinal) cost mode values.
   This document introduces a new cost mode called path-vector to allow
   ALTO clients to support use cases such as capacity regions for
   applications.  This document starts with a non-normative example
   called multi-flow scheduling (or capacity region) to illustrate that
   ALTO cost maps without path vectors cannot provide sufficient
   information.  This document then defines path-vector as a new cost
   mode.

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




Bernstein, et al.      Expires September 14, 2017               [Page 1]


Internet-Draft         ALTO Extension: Path Vector            March 2017


   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 September 14, 2017.

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  . . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Overview of Approach  . . . . . . . . . . . . . . . . . . . .   5
     2.1.  Graph Model and Path Vector Data Format . . . . . . . . .   5
     2.2.  Network Element Property Map Data Format  . . . . . . . .   6
     2.3.  Flow-based Query Data Format  . . . . . . . . . . . . . .   6
     2.4.  Routing State Abstraction Service . . . . . . . . . . . .   6
   3.  Changes Since Version -03 . . . . . . . . . . . . . . . . . .   6
   4.  Use Case: Capacity Region for Multi-Flow Scheduling . . . . .   6
   5.  Protocol Extensions . . . . . . . . . . . . . . . . . . . . .   8
     5.1.  Cost Type . . . . . . . . . . . . . . . . . . . . . . . .   8
       5.1.1.  Cost Metric . . . . . . . . . . . . . . . . . . . . .   8
       5.1.2.  Cost Mode: Path Vector  . . . . . . . . . . . . . . .   9
     5.2.  Network Element Name  . . . . . . . . . . . . . . . . . .   9
     5.3.  Entity Domains  . . . . . . . . . . . . . . . . . . . . .   9
       5.3.1.  NE Domain . . . . . . . . . . . . . . . . . . . . . .   9
       5.3.2.  ANE Domain  . . . . . . . . . . . . . . . . . . . . .  10
     5.4.  (Filtered) Network Element Property Map Resource  . . . .  10
       5.4.1.  Media Type  . . . . . . . . . . . . . . . . . . . . .  10
       5.4.2.  HTTP Method . . . . . . . . . . . . . . . . . . . . .  10
       5.4.3.  Accept Input Parameters . . . . . . . . . . . . . . .  10
       5.4.4.  Capabilities  . . . . . . . . . . . . . . . . . . . .  11



Bernstein, et al.      Expires September 14, 2017               [Page 2]


Internet-Draft         ALTO Extension: Path Vector            March 2017


       5.4.5.  Uses  . . . . . . . . . . . . . . . . . . . . . . . .  11
       5.4.6.  Response  . . . . . . . . . . . . . . . . . . . . . .  11
     5.5.  Cost Map Extensions . . . . . . . . . . . . . . . . . . .  11
       5.5.1.  Media Types . . . . . . . . . . . . . . . . . . . . .  11
       5.5.2.  HTTP Method . . . . . . . . . . . . . . . . . . . . .  11
       5.5.3.  Accept Input Parameters . . . . . . . . . . . . . . .  11
       5.5.4.  Capabilities  . . . . . . . . . . . . . . . . . . . .  11
       5.5.5.  Uses  . . . . . . . . . . . . . . . . . . . . . . . .  12
       5.5.6.  Response  . . . . . . . . . . . . . . . . . . . . . .  12
     5.6.  Filtered Cost Map Extensions  . . . . . . . . . . . . . .  12
       5.6.1.  Media Type  . . . . . . . . . . . . . . . . . . . . .  12
       5.6.2.  HTTP Method . . . . . . . . . . . . . . . . . . . . .  12
       5.6.3.  Accept Input Parameters . . . . . . . . . . . . . . .  12
       5.6.4.  Capabilities  . . . . . . . . . . . . . . . . . . . .  13
       5.6.5.  Uses  . . . . . . . . . . . . . . . . . . . . . . . .  14
       5.6.6.  Response  . . . . . . . . . . . . . . . . . . . . . .  14
     5.7.  Endpoint Cost Service Extensions  . . . . . . . . . . . .  14
       5.7.1.  Media Type  . . . . . . . . . . . . . . . . . . . . .  14
       5.7.2.  HTTP Method . . . . . . . . . . . . . . . . . . . . .  15
       5.7.3.  Accept Input Parameters . . . . . . . . . . . . . . .  15
       5.7.4.  Capabilities  . . . . . . . . . . . . . . . . . . . .  15
       5.7.5.  Uses  . . . . . . . . . . . . . . . . . . . . . . . .  16
       5.7.6.  Response  . . . . . . . . . . . . . . . . . . . . . .  16
     5.8.  Optional: RSA Extension . . . . . . . . . . . . . . . . .  16
       5.8.1.  Media Type  . . . . . . . . . . . . . . . . . . . . .  16
       5.8.2.  HTTP Method . . . . . . . . . . . . . . . . . . . . .  16
       5.8.3.  Accept Input Parameters . . . . . . . . . . . . . . .  17
       5.8.4.  Capabilities  . . . . . . . . . . . . . . . . . . . .  17
       5.8.5.  Response  . . . . . . . . . . . . . . . . . . . . . .  17
   6.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .  17
     6.1.  Information Resource Directory Example  . . . . . . . . .  17
     6.2.  Network Element Property Map Example  . . . . . . . . . .  19
     6.3.  Filtered Cost Map Example #1  . . . . . . . . . . . . . .  19
     6.4.  Filtered Cost Map Example #2  . . . . . . . . . . . . . .  21
     6.5.  Endpoint Cost Map Example #1  . . . . . . . . . . . . . .  22
     6.6.  Endpoint Cost Map Example #2  . . . . . . . . . . . . . .  23
   7.  Compatibility . . . . . . . . . . . . . . . . . . . . . . . .  24
     7.1.  Compatibility with Legacy ALTO Clients/Servers  . . . . .  24
     7.2.  Compatibility with Multi-Cost Extensions  . . . . . . . .  25
     7.3.  Compatibility with Incremental Update . . . . . . . . . .  25
   8.  Design Decisions and Discussions  . . . . . . . . . . . . . .  25
     8.1.  Path Vector or Path Graph?  . . . . . . . . . . . . . . .  25
     8.2.  Provide More General Calendar Extension?  . . . . . . . .  26
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  26
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  27
     10.1.  ALTO Cost Mode Registry  . . . . . . . . . . . . . . . .  27
     10.2.  ALTO Cost Metric Registry  . . . . . . . . . . . . . . .  27
     10.3.  ALTO Entity Domain Registry  . . . . . . . . . . . . . .  27



Bernstein, et al.      Expires September 14, 2017               [Page 3]


Internet-Draft         ALTO Extension: Path Vector            March 2017


   11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  28
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  28
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  28
     12.2.  Informative References . . . . . . . . . . . . . . . . .  28
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  29

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 extreme "single-node"
   abstraction, which represents a whole network with a single node and
   hosts are connected to the node's access ports.

   Although the "single-node" abstraction works well for many settings,
   new use cases, such as inter-datacenter data transfers and scientific
   high-performance computing data transfers, require additional network
   information beyond the single-node abstraction, to support
   application capabilities, in particular, the ability of application
   flow scheduling.

   Specifically, providing network information to support application
   flow scheduling introduces multiple complexities.  First, the
   underlying assumption of existing ALTO services is single-commodity
   flows.  Hence, given the flow from a source to a destination, ALTO
   computes the network metrics of the flow and returns them to the
   application.  The metrics for different flows are independent.
   Application flow scheduling, however, requires network information to
   compute application-desirable multi-commodity flows, where multiple
   flows under the control of the same application may share common
   network bottlenecks.  This requirement is beyond the capability of
   the single-node abstraction adopted by 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 already addressed by
   [I-D.ietf-alto-multi-cost], still needs to be handled very carefully.
   Third, flow scheduling can be conducted with several independent sets
   of flows.  Using the cross product of "src" and "dst" lists will
   introduce a lot of redundancies.

   To address these complexities in supporting the new flow scheduling
   use case, this document specifies a path vector extension to the base
   ALTO protocol.  This extension introduces a new family of cost types,
   which uses "path-vector" as cost mode and "ne" (network element) or
   "ane" (abstract network element) as cost metric.  It also extends
   "Unified Property Map" defined in [I-D.roome-alto-unified-props] to
   address the issue of scalability and consistency in providing path
   vectors with fine-grained information, and declares "pid-flows" and



Bernstein, et al.      Expires September 14, 2017               [Page 4]


Internet-Draft         ALTO Extension: Path Vector            March 2017


   "endpoint-flows" to support queries for multiple independent flow
   sets.  This document also registers new domains, entity specification
   and properties in the ALTO Entity Domain Registry.

   The document is organized as follows.  Section 2 gives an overview of
   the path vector extension.  Section 4 gives an example of flow
   scheduling to illustrate the need to introduce cost mode "path-
   vector" and new cost metrics.  Section 5 specifies the new cost mode
   and cost metrics, new domain types and entity properties, new
   resource Network Element Property Map, and protocol extensions for
   (Filtered) Cost Maps and Endpoint Cost Services.  Section 6 presents
   examples of Information Resources, requests and responses.  Section 7
   discusses the compatibility issues with some other proposed ALTO
   extensions.  Section 8 lists several to-be-determined design
   decisions.  Section 9 discusses about security and Section 10
   discusses about IANA Considerations.

2.  Overview of Approach

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

2.1.  Graph Model and Path Vector Data Format

   In this document, the graph model presented to ALTO clients is
   represented by path vectors.  A path vector between two entities
   (either PIDs or endpoints) is an array of Network Element Names,
   where each Network Element Name represents a network element (usually
   a link) in the path between the two entities.

   A specific Network Element Name MUST represent the same network
   element in the same ALTO Network Element Property Map resource.
   Thus, ALTO clients can find the flows that share this specific
   network element by finding the source-destination pairs whose
   corresponding path vectors contain the Network Element Name.

   The cost entries contained in an ALTO Cost Map or Endpoint Cost Map
   are formally defined in Section 11.2.3.6 [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 and
   Endpoint Cost Map to allow the returned cost to be a path vector,
   which is a JSONArray of Network Element Names.

   An example can be found in Section 6.3.



Bernstein, et al.      Expires September 14, 2017               [Page 5]


Internet-Draft         ALTO Extension: Path Vector            March 2017


2.2.  Network Element Property Map Data Format

   An ALTO client may need not know all attributes associated with all
   network elements.  Thus, Network Element Property Map is provided so
   after an ALTO client obtains the path vectors, it can use Network
   Element Names to selectively query the associated attributes in the
   corresponding Network Element Property Map.

2.3.  Flow-based Query Data Format

   Flow scheduling may involve multiple sets of flows which have
   different source-destination combinations.  Using source and
   destination lists can lead to a lot of redundancies.  To allow more
   flexible specification of path vector requests, two new filter types
   for ReqFilteredCostMap and ReqEndpointCostMap are specified in this
   document.

2.4.  Routing State Abstraction Service

   For security and scalability considerations, this document specifies
   an optional feature called Routing State Abstraction (RSA).  Routing
   State Abstraction feature compresses the original path vector
   information without loss of equivalence.  A Routing State Abstraction
   compression feature MUST be applied only when a (Filtered) Cost Map
   or Endpoint Cost Service provides the path vector cost type with cost
   metric being "ane".

3.  Changes Since Version -03

   o  Define "ne" and "ane" as the only cost metrics of the cost mode
      "path-vector".

   o  Define new entity domains for network property map and add the
      "availbw", "delay" property to these domains.

   o  Use Unified Property service to query properties of network
      elements.

   o  Augment the request schema of the (Filtered) Cost Map and Endpoint
      Cost Service.

4.  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, ...,



Bernstein, et al.      Expires September 14, 2017               [Page 6]


Internet-Draft         ALTO Extension: Path Vector            March 2017


   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 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, and eh3 -> eh4.  The application



Bernstein, et al.      Expires September 14, 2017               [Page 7]


Internet-Draft         ALTO Extension: Path Vector            March 2017


   can request a cost map providing end-to-end available bandwidth,
   using 'availbw' as cost-metric and 'numerical' as cost-mode.

   Assume that the application receives from the ALTO server that the
   bandwidth of eh1 -> eh2 and eh3 ->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 the two flows share a bottleneck in the
   underlying topology:

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

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

   To allow applications to distinguish the two aforementioned cases,
   the network needs to provide more details.  The path vector extension
   defined in this document resolves this issue.

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

5.  Protocol Extensions

   This section formally specifies the path vector extension.

5.1.  Cost Type

   The path vector extension defined in this document extends the Cost
   Types as specified in Section 6.1 of [RFC7285] .

5.1.1.  Cost Metric

   This document specifies two new cost metrics: "ne" and "ane".  Both
   cost metrics are of type CostMetric as defined in Section 10.6 of
   [RFC7285].  These cost metrics MUST NOT be used when the cost mode is
   not "path-vector" unless it is explicitly specified in a future
   extension.  An ALTO server with path vector extension MUST support at
   least one of these two cost metrics.

   Cost metric "ne":  This cost metric MUST be encoded as the JSONString
      "ne".  When cost metric is "ne", Network Element Names contained
      in the path vectors MUST be resource-specific.  In this case,
      different path vector queries to the same (Filtered) Cost Map or



Bernstein, et al.      Expires September 14, 2017               [Page 8]


Internet-Draft         ALTO Extension: Path Vector            March 2017


      Endpoint Cost Service MUST have the same Network Element Property
      Map in the responses.

   Cost metric "ane":  This cost metric MUST be encoded as the
      JSONString "ane".  When cost metric is "ane", Network Element
      Names contained in the path vector MUST be query-specific.  In
      this case, different path vector queries to the same (Filtered)
      Cost Map or Endpoint Cost Service MAY have different Network
      Element Property Maps.

5.1.2.  Cost Mode: Path Vector

   This document extends the cost mode as defined in Section 10.5 of
   [RFC7285] by allowing an ALTO server to provide a new cost mode other
   than "numerical" and "ordinal".  The path vector cost mode is of type
   CostMode and is encoded as the JSONString "path-vector".

   A (Filtered) Cost Map resource or Endpoint Cost Service, when queried
   with this cost mode, MUST return a CostMapData or EndpointCostMapData
   whose costs are JSONArrays of type NetworkElementName as specified in
   Section 5.2.

   This cost mode MUST be used with either cost metric "ne" or "ane"
   unless it is explicitly specified by a future extension.

5.2.  Network Element Name

   This document also extends [RFC7285] with a new basic data type:
   Network Element Name.  A Network Element Name is of type EntityAddr
   as defined in Section 2.3 of [I-D.roome-alto-unified-props] and is
   encoded as a JSONString.  A Network Element Name MUST be an
   EntityAddr either of the NE domain (Section 5.3.1) or of the ANE
   domain (Section 5.3.2).

5.3.  Entity Domains

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

5.3.1.  NE Domain

5.3.1.1.  Domain Name

   ne







Bernstein, et al.      Expires September 14, 2017               [Page 9]


Internet-Draft         ALTO Extension: Path Vector            March 2017


5.3.1.2.  Domain-Specific Entity Addresses

   Entity address of NE domain MUST be encoded as a JSONString with the
   same format as PID name defined in Section 10.1 of [RFC7285].

5.3.2.  ANE Domain

5.3.2.1.  Domain Name

   ane

5.3.2.2.  Domain-Specific Entity Addresses

   The same as Section 5.3.1.2.

5.4.  (Filtered) Network Element Property Map Resource

   This document extends the base ALTO protocol with a new (filtered)
   resource: (Filtered) Network Element Property Map.

   A Network Element Property Map MUST be a Property Map as defined in
   Section 4 of [I-D.roome-alto-unified-props] and a Filtered Network
   Element Property Map MUST be a Filtered Property Map as defined in
   Section 5 of [I-D.roome-alto-unified-props].

5.4.1.  Media Type

   The media type of a (Filtered) Network Element Property Map resource
   is "application/alto-propmap+json".

5.4.2.  HTTP Method

   An ALTO Network Element Property Map is requested using the HTTP GET
   method.

   An ALTO Filtered Network Element Property Map is requested using the
   HTTP POST method.

5.4.3.  Accept Input Parameters

   Network Element Property Map does not accept any input parameters.

   The input parameters of a Filtered Network Element Property Map MUST
   conform to the format in Section 5.3 of
   [I-D.roome-alto-unified-props].  The EntityAddr in the request MUST
   have the same format as Network Element Name specified in
   Section 5.2.




Bernstein, et al.      Expires September 14, 2017              [Page 10]


Internet-Draft         ALTO Extension: Path Vector            March 2017


5.4.4.  Capabilities

   A (Filtered) Network Element Property Map MUST have capabilities
   "domain-types" and "prop-types" as defined in Section 4.4 of
   [I-D.roome-alto-unified-props].  The "domain-types" capability MUST
   contain either "ne" or "ane" but not both at the same time and the
   "prop-types" capability MUST contain property type "availbw".

5.4.5.  Uses

   None.

5.4.6.  Response

   The "vtag" field MUST be included in the "meta" field of a response
   to a (Filtered) Network Element Map, with the same format as defined
   in Section 11.2.1.6 of [RFC7285].

   The response is the same as for the Property Map, as defined in
   Section 4.6 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.2.

5.5.  Cost Map Extensions

5.5.1.  Media Types

   The same as Section 11.2.3.1 of [RFC7285].

5.5.2.  HTTP Method

   The same as Section 11.2.3.2 of [RFC7285].

5.5.3.  Accept Input Parameters

   The same as Section 11.2.3.3 of [RFC7285].

5.5.4.  Capabilities

   If a Cost Map resource supports the path vector extension defined in
   this document, its "cost-type-names" capability MUST have exactly one
   single cost type with the cost mode being "path-vector" and the cost
   metric being either "ne" or "ane", unless it is explicitly specified
   by a future extension.







Bernstein, et al.      Expires September 14, 2017              [Page 11]


Internet-Draft         ALTO Extension: Path Vector            March 2017


5.5.5.  Uses

   The same as Section 11.2.3.5 of [RFC7285].

5.5.6.  Response

   The response has the same format as in Section 4.1.3 of
   [I-D.ietf-alto-multi-cost], except the follows.

   o  If cost mode is "path-vector", the costs MUST be JSONArrays of
      Network Element Names.

   o  If cost mode is "path-vector", the "meta" field MUST include the
      "nep-map" field, whose value is of type IRDResourceEntry as
      defined in Section 9.2.2 of [RFC7285] and represents the Filtered
      Network Element Property Map associated with this Cost Map as
      defined in Section 5.4.  An ALTO server providing this resource
      MUST verify the following conditions are met:

   o  If cost metric of this Cost Map resource is "ne", the "nep-map"
      entry MUST have "domain-types" capability which includes domain
      name "ne".

   o  If cost metric of this Cost Map resource is "ane", the "nep-map"
      entry MUST have "domain-types" capability which includes domain
      name "ane".

   ALTO servers MUST also verity the conditions in Section 5.1.1 are
   also met.

5.6.  Filtered Cost Map Extensions

5.6.1.  Media Type

   The same as Section 11.3.2.1 of [RFC7285].

5.6.2.  HTTP Method

   The same as Section 11.3.2.2 of [RFC7285].

5.6.3.  Accept Input Parameters

   This document extends the ReqFilteredCostMap as follows:








Bernstein, et al.      Expires September 14, 2017              [Page 12]


Internet-Draft         ALTO Extension: Path Vector            March 2017


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

     object {
       PIDName src;
       PIDName dst;
     } PIDFlow;

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

   pids:  As defined in Section 11.3.2.3 of [RFC7285].

   cost-type, multi-cost-types, testable-cost-types, constraints, or-
   constraints:
      As defined in Section 4.1.2 of [I-D.ietf-alto-multi-cost].  A
      valid query MUST be considered a path vector query, either when
      "cost-type" of this query exists with "path-vector" cost mode, or
      when "multi-cost-types" exists and exact one cost type uses "path-
      vector" cost mode.  For a path vector query, the path vector cost
      type MUST follow the definition in Section 5.1, otherwise the ALTO
      server SHOULD return an error with error code
      "E_INVALID_FIELD_VALUE".  If "multi-cost-types" contains multiple
      path vector cost types, ALTO servers SHOULD return an error with
      the error code "E_INVALID_FIELD_VALUE".  If a query is a path
      vector query and its "constraints" or "or-constraints" field is
      present, the "testable-cost-types" field MUST be explicitly
      specified and MUST NOT include any path vector cost type.  If a
      path vector cost type is included, an ALTO server SHOULD return an
      error with the error code "E_INVALID_FIELD_VALUE".

   An ALTO client MUST specify either "pids" or "pid-flows", but MUST
   NOT specify both in a single query.

5.6.4.  Capabilities

   A Filtered Cost Map with the path vector extension MAY have the
   "flow-based-filter" in its IRD capabilities.






Bernstein, et al.      Expires September 14, 2017              [Page 13]


Internet-Draft         ALTO Extension: Path Vector            March 2017


     object {
       JSONString cost-type-names<1..*>;
       [JSONBool cost-constraints;]
       [JSONNumber max-cost-types;]
       [JSONString testable-cost-type-names<1..*>;]
       [JSONBool flow-based-filter;]
     } FilteredCostMapCapabilities;

   flow-based-filter:  If the value is true, the ALTO server allows ALTO
      clients to use "pid-flows" to query the Filtered Cost Map. If
      false or not present, ALTO clients MUST NOT include this field in
      the queries and the ALTO server SHOULD return an error with the
      error code "E_INVALID_FIELD_TYPE" for the queries including this
      field.

   cost-type-names and cost-constraints:  As defined in Section 11.3.2.4
      of [RFC7285].

   max-cost-types and testable-cost-type-names:  As defined in
      Section 4.1.1 of [I-D.ietf-alto-multi-cost].  If a cost type with
      "path-vector" mode is included in "cost-type-names", either the
      "testable-cost-type-names" field is explicitly specified which
      MUST NOT include any path vector cost type, or the "testable-cost-
      type-names" field is empty where ALTO clients MUST interpret this
      as specified in Section 4.1.1 of [I-D.ietf-alto-multi-cost] except
      that the resource MUST NOT accept tests on any path vector cost
      type.

5.6.5.  Uses

   The same as Section 5.5.5.

5.6.6.  Response

   The response MUST have the same format as defined in Section 5.5.6
   with the supplement that if a query uses the field "pid-flows", the
   response MUST still conform to the CostMapData format defined in
   Section 11.2.3.6 of [RFC7285].  Examples can be found in Section 6.3.

5.7.  Endpoint Cost Service Extensions

5.7.1.  Media Type

   The same as Section 11.5.1.1 of [RFC7285].







Bernstein, et al.      Expires September 14, 2017              [Page 14]


Internet-Draft         ALTO Extension: Path Vector            March 2017


5.7.2.  HTTP Method

   The same as Section 11.5.1.2 of [RFC7285].

5.7.3.  Accept Input Parameters

   This document extends the input parameters of Endpoint Cost Service
   as follows:

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

     object {
       TypedEndpointAddr src;
       TypedEndpointAddr dst;
     } EndpointFlow;

   endpoint-flows:  A list of source-destination endpoint pairs for
      which path costs are to be returned.

   endpoints:  As defined in Section 11.5.1.3 of [RFC7285].

   cost-type, multi-cost-types, testable-cost-types, constraints, or-
   constraints:
      As defined in Section 5.6.3.

   ALTO clients MUST specify either "endpoints" or "endpoint-flows", but
   MUST NOT specify both in the same query.

5.7.4.  Capabilities

   This document defines EndpointCostMapCpabilities the same as
   FilteredCostMapCapabilities in Section 5.6.4.

   If the value of capability flow-based-filter is true, the ALTO server
   MUST be able to process "endpoint-flows" in a query.  If the value is
   false or not present, ALTO clients MUST assume the "endpoint-flows"
   is not supported and ALTO servers SHOULD return an error with the
   error code "E_INVALID_FIELD_TYPE" if "endpoint-flows" is included in
   the query.




Bernstein, et al.      Expires September 14, 2017              [Page 15]


Internet-Draft         ALTO Extension: Path Vector            March 2017


5.7.5.  Uses

   The same as Section 11.5.1.5 of [RFC7285].

5.7.6.  Response

   The response has the same format as in Section 4.2.3 of
   [I-D.ietf-alto-multi-cost] for compatibility, except the follows.

   o  If cost mode is "path-vector", the costs MUST be JSONArrays of
      Network Element Names.

   o  If cost mode is "path-vector", the "meta" field MUST include the
      "nep-map" field, whose value is of type IRDResourceEntry as
      defined in Section 9.2.2 of [RFC7285] and represents the Filtered
      Network Element Property Map associated with this Endpoint Cost
      Service as defined in Section 5.4.  An ALTO server providing this
      resource MUST verify the following conditions are met:

   o  If cost metric of this Endpoint Cost Service is "ne", the "nep-
      map" entry MUST have "domain-types" capability which includes
      domain name "ne".

   o  If cost metric of this Endpoint Cost Service is "ane", the "nep-
      map" entry MUST have "domain-types" capability which includes
      domain name "ane".

   ALTO servers MUST also verity the conditions in Section 5.1.1 are
   also met.

   Examples can be found in Section 6.5.

5.8.  Optional: RSA Extension

5.8.1.  Media Type

   RSA extension MUST NOT change media types of (Filtered) Cost Map
   resource or Endpoint Cost Service.

5.8.2.  HTTP Method

   RSA extension MUST NOT change HTTP method for (Filtered) Cost Map or
   Endpoint Cost Service.








Bernstein, et al.      Expires September 14, 2017              [Page 16]


Internet-Draft         ALTO Extension: Path Vector            March 2017


5.8.3.  Accept Input Parameters

   RSA extension SHOULD NOT change the input parameters of a Filtered
   Cost Map or an Endpoint Cost Service unless it is explicitly
   specified by a future extension.

5.8.4.  Capabilities

   If a (Filtered) Cost Map or an Endpoint Cost Service supports RSA
   extension, the "cost-type-names" MUST have one cost type with "path-
   vector" cost mode and "ane" cost metric, and ALTO clients MUST ignore
   this field when no such path vector cost type exists.  The resource/
   service MUST also have the field "rsa" explicitly specified to "true"
   in the "capabilities" field.  If the "rsa" field has a value of
   "false" or is not present, ALTO clients MUST assume this resource/
   service does not provide RSA compression.

   An example can be found in Section 6.1.

5.8.5.  Response

   RSA extension SHOULD NOT change the output of a (Filtered) Cost Map
   or an Endpoint Cost Service unless it is explicitly specified in a
   future extension.

6.  Examples

6.1.  Information Resource Directory Example

   Here is an example of an ALTO server's Information Resource
   Directory.

  "meta" {
    "cost-types": {
      "pv-ne": {
        "cost-mode": "pv",
        "cost-metric": "ne"
      },
      "pv-ane": {
        "cost-mode": "pv",
        "cost-metric": "ane"
      },
      "num-hopcount": {
        "cost-mode": "numerical",
        "cost-metric": "hopcount"
      },
      "num-routingcost": {
        "cost-mode": "numerical",



Bernstein, et al.      Expires September 14, 2017              [Page 17]


Internet-Draft         ALTO Extension: Path Vector            March 2017


        "cost-metric": "routingcost"
      },
      "num-delay": {
          "cost-mode": "numerial",
          "cost-metric": "delay"
      },
      "num-availbw": {
        "cost-mode": "numerical",
        "cost-metric": "availbw"
      }
    }
  },
  "resource": {
    "default-network-map": {
      "uri": "http://alto.example.com/networkmap",
      "media-type": "application/alto-networkmap+json"
    },

    ... Filtered Cost Map Resource ...

    "filtered-multi-cost-map1": {
      "uri": "http://alto.example.com/costmap/multi/filtered1",
      "media-type": "application/alto-costmap+json",
      "accepts": "application/alto-costmapfilter+json",
      "uses": ["default-network-map"],
      "capabilities": {
        "max-cost-types": 3,
        "cost-type-names": ["pv-ne", "num-availbw", "num-hopcount"],
        "testable-cost-types-names": ["num-availbw", "num-hopcount"]
      }
    },

    "filtered-multi-cost-map2": {
      "uri": "http://alto.example.com/costmap/multi/filtered2",
      "media-type": "application/alto-costmap",
      "accepts": "application/alto-costmapfilter+json",
      "uses": ["default-network-map"],
      "capabilities": {
        "max-cost-types":2,
        "cost-type-names": ["pv-ne", "num-routingcost", "num-delay"],
        "cost-constraints": true
      }
    }
    ... Endpoint Cost Map Resource ...

    "default-endpoint-cost-map": {
      "uri": "http://alto.example.com//endpointcost/lookup/ne-ane",
      "media-type": "application/alto-endpointcostmap+json",



Bernstein, et al.      Expires September 14, 2017              [Page 18]


Internet-Draft         ALTO Extension: Path Vector            March 2017


      "accepts": "application/alto-endpointcostparams+json",
      "capabilities": {
        "rsa": true,
        "max-cost-types": 4,
        "cost-type-names": ["pv-ne", "pv-ane", "num-routingcost", "num-hopcount"],
        "testable-cost-types-names": ["num-hopcount", "num-routingcost"]
      }
    }
  }

6.2.  Network Element Property Map Example

     POST /propmap/lookup/nep-map 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

     {
       "entities" : [ "ne:ne12",
                     "ne:ne23",
                     "ne:ne34" ],
       "properties" : [ "availbw", "delay" ]
     }

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

     {
       "meta": {
           "vtag": {
               "resource-id": "default-network-element-prop-map",
               "tag": "babbc14521772381472bffefff627813909875dd"
           }
       }
       "property-map": {
         "ne:ne12": { "availbw": "90", "delay": "30" },
         "ne:ne23": { "availbw": "80", "delay": "15" },
         "ne:ne34": { "availbw": "70", "delay": "25" }
       }
     }

6.3.  Filtered Cost Map Example #1

   Assume that the available bandwidth between PID1 and PID3 is less
   than 50.




Bernstein, et al.      Expires September 14, 2017              [Page 19]


Internet-Draft         ALTO Extension: Path Vector            March 2017


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

     {
       "cost-type": {
         "cost-mode": "path-vector",
         "cost-metric": "ne"
       },
       "testable-cost-types": [
         { "cost-mode": "numerical", "cost-metric": "availbw" },
         { "cost-mode": "numerical", "cost-metric": "hopcount" }
       ],
       "or-constraints": [
         ["[0] ge 50", "[1] le 100"]
       ],
       "pid-flows": [
         { "src": "PID1", "dst": "PID2" }
         { "src": "PID1", "dst": "PID3" }
         { "src": "PID3", "dst": "PID4" }
       ]
     }

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

     {
       "meta": {
         "dependent-vtags": [
           {
             "resource-id": "my-default-network-map",
             "tag": "75ed013b3cb58f896e839582504f622838ce670f"
           }
         ],
         "cost-type": {
           "cost-mode": "path-vector",
           "cost-metric": "ne"
         },
         "nep-map": {
           "uri": "http://alto.example.com/propmap/lookup/nep-map",
           "media-type": "application/alto-prompmap+json",
           "accepts": "application/alto-propmapparams+json",
           "capabilities": {
             "domain-types": ["ne"],
             "prop-types": ["availbw", "delay"]



Bernstein, et al.      Expires September 14, 2017              [Page 20]


Internet-Draft         ALTO Extension: Path Vector            March 2017


           }
         }
       },
       "cost-map": {
         "PID1": { "PID2": [ "ne:ne12", "ne:ne23" ] },
         "PID3": { "PID4": [ "ne:ne23", "ne:ne34" ] }
       }
     }

6.4.  Filtered Cost Map Example #2

   Assume that the delay between PID1 and PID2 is greater than 80.

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

     {
       "multi-cost-types": [
         { "cost-mode": "path-vector", "cost-metric": "ne" },
         { "cost-mode": "numerical", "cost-metric": "delay" }
       ],
       "testable-cost-types": [
         { "cost-mode": "numerical", "cost-metric": "delay" }
       ],
       "constraints": [ "[0] le 80" ],
       "pid-flows": [
         { "src": "PID1", "dst": "PID2" },
         { "src": "PID1", "dst": "PID3" },
         { "src": "PID3", "dst": "PID4" }
       ]
     }

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

     {
       "meta": {
         "dependent-vtags": [
           {
             "resource-id": "my-default-network-map",
             "tag": "75ed013b3cb58f896e839582504f622838ce670f"
           }
         ],
         "cost-type": {},



Bernstein, et al.      Expires September 14, 2017              [Page 21]


Internet-Draft         ALTO Extension: Path Vector            March 2017


         "multi-cost-types": [
           { "cost-mode": "path-vector", "cost-metric": "ne"},
           { "cost-mode": "numerical", "cost-metric": "delay"}
         ],
         "nep-map": {
           "uri": "http://alto.example.com/propmap/lookup/nep-map",
           "media-type": "application/alto-prompmap+json",
           "accepts": "application/alto-propmapparams+json",
           "capabilities": {
             "domain-types": ["ne"],
             "prop-types": ["availbw", "delay"]
           }
         }
       },
       "cost-map": {
         "PID1": { "PID3": [ [ "ne:ne23", "ne:ne45" ], 60 ] },
         "PID3": { "PID4": [ [ "ne:ne23", "ne:ne34" ], 40 ] }
       }
     }

6.5.  Endpoint Cost Map Example #1

   Assume that the delay between ipv4:203.0.113.45 and
   ipv4:198.51.100.34 is greater than 100.

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

  {
    "cost-type": {
      "cost-mode": "path-vector",
      "cost-metric": "ne"
    },
    "testable-cost-types": [
      {
        "cost-mode": "numerical",
        "cost-metric": "delay"
      }
    ],
    "constraints": [
      "[0] le 100"
    ],
    "endpoint-flows": [
      { "src": "ipv4:192.0.2.2", "dst": "ipv4:192.0.2.89" },
      { "src": "ipv4:192.0.2.2", "dst": "ipv4:198.51.100.34" },



Bernstein, et al.      Expires September 14, 2017              [Page 22]


Internet-Draft         ALTO Extension: Path Vector            March 2017


      { "src": "ipv4:203.0.113.45", "dst": "ipv4:198.51.100.34" }
    ]
  }


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

  {
      "meta": {
      "cost-type": {
        "cost-mode": "path-vector",
        "cost-metric": "ne"
      },
      "nep-map": {
        "uri": "http://alto.example.com/propmap/lookup/nep-map",
        "media-type": "application/alto-prompmap+json",
        "accepts": "application/alto-propmapparams+json",
        "capabilities": {
          "domain-types": ["ne"],
          "prop-types": ["availbw", "delay"]
        }
      }
    },
    "endpoint-cost-map": {
      "ipv4:192.0.2.2": {
        "ipv4:192.0.2.89": [ "ne:ne12", "ne:ne23" ],
        "ipv4:198.51.100.34": [ "ne:ne12", "ne:ne24", "ne:ne45" ]
      }
    }
  }

6.6.  Endpoint Cost Map Example #2

  POST /endpointcost/lookup/ne-ane HTTP/1.1
  Host: alto.example.com
  Accept: application/alto-endpointcost+json,application/alto-error+json
  Content-Length: [TBD]
  Content-Type: application/alto-endpointcostparams+json

  {
    "multi-cost-types": [
    {
      "cost-mode": "path-vector",
      "cost-metric": "ane"
    },
    {



Bernstein, et al.      Expires September 14, 2017              [Page 23]


Internet-Draft         ALTO Extension: Path Vector            March 2017


      "cost-mode": "numerical",
      "cost-metric": "delay"
    }],
    "endpoint-flows": [
      { "src": "ipv4:192.0.2.2", "dst": "ipv4:192.0.2.89" },
      { "src": "ipv4:192.0.2.2", "dst": "ipv4:198.51.100.34" },
      { "src": "ipv4:203.0.113.45", "dst": "ipv4:198.51.100.34" }
    ]
  }

  HTTP/1.1 200 OK
  Content-Length: [TBD]
  Content-Type: application/alto-endpointcost+json
  {
    "meta": {
      "cost-type": {},
      "multi-cost-types": [
      { "cost-mode": "path-vector", "cost-metric": "ane"},
      { "cost-mode": "numerical", "cost-metric": "delay"}
      ],
      "nep-map": {
        "uri": "http://alto.example.com/propmap/lookup/nep-map/31415926",
        "media-type": "application/alto-prompmap+json",
        "accepts": "application/alto-propmapparams+json",
        "capabilities": {
          "domain-types": ["ane"],
          "prop-types": ["availbw", "delay"]
        }
      }
    },
    "endpoint-cost-map": {
      "ipv4:192.0.2.2": {
        "ipv4:192.0.2.89": [ ["ane:ane12", "ane:ane23"], 45 ],
        "ipv4:198.51.100.34": [ ["ane:ane12", "ane:ane24"], 90 ]
      },
      "ipv4:203.0.113.45": {
        "ipv4:198.51.100.34": [ ["ane:ane34"], 120 ]
      }
    }
  }

7.  Compatibility

7.1.  Compatibility with Legacy ALTO Clients/Servers

   Legacy ALTO clients SHOULD NOT send queries with path vector
   extension and ALTO servers with this extension SHOULD NOT have any
   compatibility issue.  Legacy ALTO servers do not support cost types



Bernstein, et al.      Expires September 14, 2017              [Page 24]


Internet-Draft         ALTO Extension: Path Vector            March 2017


   with the "path-vector" cost mode and 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.  Compatibility with Multi-Cost Extensions

   Path Vector extension SHOULD be fully compatible with Multi-Cost
   extensions.

7.3.  Compatibility with Incremental Update

   There is no compatibility issue with incremental update extension.

8.  Design Decisions and Discussions

8.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 to express multiple
   paths.  The simple solution is to list the network elements of all
   accessible paths in a single path vector.  This solution will lose
   the information about paths.  Another solution is to define the path
   as a new type of network elements.  In this way, the path vector can
   provide an array of paths.  Each element of this array contains a
   path vector of network elements in the Network Element Property Map.





Bernstein, et al.      Expires September 14, 2017              [Page 25]


Internet-Draft         ALTO Extension: Path Vector            March 2017


   So in this document, we just introduce "path-vector" as the only
   required cost mode for routing state information.

8.2.  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 a new ALTO service,
   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.  Security Considerations

   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.





Bernstein, et al.      Expires September 14, 2017              [Page 26]


Internet-Draft         ALTO Extension: Path Vector            March 2017


   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.  IANA Considerations

10.1.  ALTO Cost Mode Registry

   This document specifies a new cost mode "path-vector".  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.

10.2.  ALTO Cost Metric Registry

   Two new cost metrics need to be registered in the "ALTO Cost Metric
   Registry", listed in Table 1.

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

                        Table 1: ALTO Cost Metrics

10.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, two new domains are
   to be registered, listed in Table 2.

   +-------------+--------------------------+--------------------------+
   | Identifier  | Entity Address Encoding  |  Hierarchy & Inheritance |
   +-------------+--------------------------+--------------------------+
   | ne          |   See Section 5.3.1.2    |                     None |
   | ane         |   See Section 5.3.2.2    |                     None |
   +-------------+--------------------------+--------------------------+

                        Table 2: ALTO Entity Domain






Bernstein, et al.      Expires September 14, 2017              [Page 27]


Internet-Draft         ALTO Extension: Path Vector            March 2017


11.  Acknowledgments

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

12.  References

12.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>.

12.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.ietf-alto-cost-calendar]
              Randriamasy, S., Yang, Y., Wu, W., 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-05 (work in progress),
              February 2017.




Bernstein, et al.      Expires September 14, 2017              [Page 28]


Internet-Draft         ALTO Extension: Path Vector            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.

   [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








Bernstein, et al.      Expires September 14, 2017              [Page 29]


Internet-Draft         ALTO Extension: Path Vector            March 2017


   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










Bernstein, et al.      Expires September 14, 2017              [Page 30]


Html markup produced by rfcmarkup 1.127, available from https://tools.ietf.org/tools/rfcmarkup/