GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc8189

Internet Engineering Task Force (IETF) S. Randriamasy Request for Comments: 8189 W. Roome Category: Standards Track Nokia Bell Labs ISSN: 2070-1721 N. Schwan

                                                    Thales Deutschland
                                                          October 2017
      Multi-Cost Application-Layer Traffic Optimization (ALTO)

Abstract

 The Application-Layer Traffic Optimization (ALTO) protocol, specified
 in RFC 7285, defines several services that return various metrics
 describing the costs between network endpoints.
 This document defines a new service that allows an ALTO Client to
 retrieve several cost metrics in a single request for an ALTO
 filtered cost map and endpoint cost map.  In addition, it extends the
 constraints to further filter those maps by allowing an ALTO Client
 to specify a logical combination of tests on several cost metrics.

Status of This Memo

 This is an Internet Standards Track document.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 Internet Standards is available in Section 2 of RFC 7841.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 https://www.rfc-editor.org/info/rfc8189.

Randriamasy, et al. Standards Track [Page 1] RFC 8189 Multi-Cost ALTO October 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
 (https://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.

Randriamasy, et al. Standards Track [Page 2] RFC 8189 Multi-Cost ALTO October 2017

Table of Contents

 1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
   1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   5
 2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
 3.  Overview Of Approach  . . . . . . . . . . . . . . . . . . . .   6
   3.1.  Multi-Cost Data Format  . . . . . . . . . . . . . . . . .   6
   3.2.  Compatibility with Legacy ALTO Clients  . . . . . . . . .   7
   3.3.  Filtered Multi-Cost Map Resources . . . . . . . . . . . .   7
   3.4.  Endpoint Cost Service Resources . . . . . . . . . . . . .   8
   3.5.  Full Cost Map Resources . . . . . . . . . . . . . . . . .   8
   3.6.  Extended Constraint Tests . . . . . . . . . . . . . . . .   8
     3.6.1.  Extended Constraint Predicates  . . . . . . . . . . .   9
     3.6.2.  Extended Logical Combination of Predicates  . . . . .   9
     3.6.3.  Testable Cost Types in Constraints  . . . . . . . . .   9
     3.6.4.  Testable Cost Type Names in IRD Capabilities  . . . .  10
     3.6.5.  Legacy ALTO Client Issues . . . . . . . . . . . . . .  10
 4.  Protocol Extensions for Multi-Cost ALTO Transactions  . . . .  12
   4.1.  Filtered Cost Map Extensions  . . . . . . . . . . . . . .  12
     4.1.1.  Capabilities  . . . . . . . . . . . . . . . . . . . .  13
     4.1.2.  Accept Input Parameters . . . . . . . . . . . . . . .  14
     4.1.3.  Response  . . . . . . . . . . . . . . . . . . . . . .  17
   4.2.  Endpoint Cost Service Extensions  . . . . . . . . . . . .  17
     4.2.1.  Capabilities  . . . . . . . . . . . . . . . . . . . .  17
     4.2.2.  Accept Input Parameters . . . . . . . . . . . . . . .  18
     4.2.3.  Response  . . . . . . . . . . . . . . . . . . . . . .  19
 5.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .  19
   5.1.  Information Resource Directory  . . . . . . . . . . . . .  19
   5.2.  Multi-Cost Filtered Cost Map: Example #1  . . . . . . . .  21
   5.3.  Multi-Cost Filtered Cost Map: Example #2  . . . . . . . .  23
   5.4.  Multi-Cost Filtered Cost Map: Example #3  . . . . . . . .  24
   5.5.  Multi-Cost Filtered Cost Map: Example #4  . . . . . . . .  25
   5.6.  Endpoint Cost Service . . . . . . . . . . . . . . . . . .  26
 6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  28
 7.  Privacy and Security Considerations . . . . . . . . . . . . .  28
 8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  28
   8.1.  Normative References  . . . . . . . . . . . . . . . . . .  28
   8.2.  Informative References  . . . . . . . . . . . . . . . . .  28
 Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  29
 Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  29

Randriamasy, et al. Standards Track [Page 3] RFC 8189 Multi-Cost ALTO October 2017

1. Introduction

 IETF has defined ALTO services in [RFC7285] to provide guidance to
 overlay applications, which have to select one or several hosts from
 a set of candidates that are able to provide a desired resource.
 This guidance is based on parameters such as the topological distance
 that affect performance of the data transmission between the hosts.
 The purpose of ALTO is to improve Quality of Experience (QoE) in the
 application while reducing resource consumption in the underlying
 network infrastructure.  The ALTO protocol conveys a view of the
 Internet called a Network Map, which is composed of provider-defined
 locations spanning from subnets to several Autonomous Systems (ASes).
 ALTO may also convey the provider-determined costs between Network
 Map locations or between groups of individual endpoints.
 Current ALTO cost types provide values such as "hopcount" and
 administrative "routingcost" to reflect ISP routing preferences.
 Recently, new use cases have extended the usage scope of ALTO to
 Content Delivery Networks (CDNs), data centers, and applications that
 need additional information to select their endpoints or network
 locations.  Thus, a multitude of new cost types that better reflect
 the requirements of these applications are expected to be specified.
 The ALTO protocol [RFC7285], which this document refers to as the
 base protocol, restricts ALTO cost maps and Endpoint Cost Services to
 only one cost type per ALTO request.  To retrieve information for
 several cost types, an ALTO Client must send several separate
 requests to the Server.
 It is far more efficient, in terms of Round-Trip Time (RTT), traffic,
 and processing load on the ALTO Client and Server, to get all costs
 with a single query/response transaction.  One cost map reporting on
 N cost types is less bulky than N cost maps containing one cost type
 each.  This is valuable for both the storage of these maps and their
 transmission.  Additionally, for many emerging applications that need
 information on several cost types, having them gathered in one map
 will save time.  Another advantage is consistency: providing values
 for several cost types in one single batch is useful for ALTO Clients
 needing synchronized ALTO information updates.  This document defines
 how to retrieve multiple cost metrics in a single request for ALTO
 filtered cost maps and endpoint cost maps.  To ensure compatibility
 with legacy ALTO Clients, only the Filtered Cost Map and Endpoint
 Cost Map Services are extended to return multi-cost values.
 Along with multi-cost values queries, the filtering capabilities need
 to be extended to allow constraints on multiple metrics.  The base
 protocol allows an ALTO Client to provide optional constraint tests
 for a Filtered Cost Map Service or the Endpoint Cost Service, where

Randriamasy, et al. Standards Track [Page 4] RFC 8189 Multi-Cost ALTO October 2017

 the constraint tests are limited to the AND combination of comparison
 tests on the value of the (single) requested cost type.  However,
 applications that are sensitive to several metrics and struggle with
 complicated network conditions may need to arbitrate between
 conflicting objectives such as routing cost and network performance.
 To this end, this document extends the base protocol with constraints
 that may test multiple metrics and may be combined with logical 'ORs'
 as well as logical 'ANDs'.  This allows an application to make
 requests such as: "select solutions with either (moderate "hopcount"
 AND high "routingcost") OR (higher "hopcount" AND moderate
 "routingcost")".
 This document is organized as follows.  Section 2 defines terminology
 used in this document.  Section 3 gives a non-normative overview of
 the multi-cost extensions, and Section 4 gives the formal
 definitions.  Section 5 gives several complete examples.  The
 remaining sections describe the IANA, privacy, and security
 considerations.

1.1. Requirements Language

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
 "OPTIONAL" in this document are to be interpreted as described in
 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
 capitals, as shown here.
 When the words appear in lower case, they are to be interpreted with
 their natural language meanings.

2. Terminology

 o  ALTO transaction: A request/response exchange between an ALTO
    Client and an ALTO Server.
 o  Client: When used with a capital "C", this term refers to an ALTO
    Client.
 o  Endpoint (EP): An endpoint is defined as in Section 2.1 of
    [RFC7285].  It can be, for example, a peer, a CDN storage
    location, a physical server involved in a virtual server-supported
    application, a party in a resource-sharing swarm such as a
    computation grid, or an online multi-party game.
 o  Server: When used with a capital "S", this term refers to an ALTO
    Server.

Randriamasy, et al. Standards Track [Page 5] RFC 8189 Multi-Cost ALTO October 2017

3. Overview Of Approach

 The following is a non-normative overview of the multi-cost ALTO
 extensions defined in this document.  It assumes the reader is
 familiar with cost map resources in the ALTO protocol [RFC7285].

3.1. Multi-Cost Data Format

 Formally, the cost entries in an ALTO cost map can be any type of
 JSON value [RFC7159] (see the DstCosts object in Section 11.2.3.6 of
 [RFC7285]).  However, that section also says that an implementation
 may assume costs are JSON numbers, unless the implementation is using
 an extension that signals a different data type.
 Therefore, this document extends the definition of a cost map to
 allow a cost to be an array of costs, one per metric, instead of just
 one number.  For example, here is a cost map with the "routingcost"
 and "hopcount" metrics.  Note that this is identical to a regular
 ALTO cost map, except that the values are arrays instead of numbers.
 The multiple metrics are listed in member "multi-cost-types",
 indicating to the Client how to map values in the array to cost
 metrics.
 {
  "meta" : {
    "dependent-vtags" : [ ... ],
    "cost-type" : {},
    "multi-cost-types" : [
      {"cost-mode": "numerical", "cost-metric": "routingcost"},
      {"cost-mode": "numerical", "cost-metric": "hopcount"}
    ]
  }
  "cost-map" : {
    "PID1": { "PID1":[1,0],  "PID2":[5,23],  "PID3":[10,5] },
    ...
  }
 }
 Note also the presence of member '"cost-type" : {}' to maintain
 backwards compatibility with [RFC7285].

Randriamasy, et al. Standards Track [Page 6] RFC 8189 Multi-Cost ALTO October 2017

3.2. Compatibility with Legacy ALTO Clients

 This document does not define any new media types.  Instead, as
 described below, it extends the specifications in the ALTO Server's
 Information Resource Directory (IRD) so that legacy Clients will not
 request array-valued multi-cost map resources.  This relies on the
 requirement that ALTO Clients MUST ignore unknown fields
 (Section 8.3.7 of [RFC7285]).

3.3. Filtered Multi-Cost Map Resources

 This document extends the Filtered Cost Map Service to allow the same
 resource to return either a single-valued cost map, as defined in
 [RFC7285], or an array-valued multi-cost map, as defined in this
 document.  An extended Filtered Cost Map resource has a new
 capability, "max-cost-types".  The value is the maximum number of
 cost types this resource can return for one request.  The existence
 of this capability means the resource understands the extensions in
 this document.
 For example, the following fragment from an IRD defines an extended
 Filtered Cost Map resource:
    "filtered-multicost-map" : {
      "uri" : "http://alto.example.com/multi/costmap/filtered",
      "media-type" : "application/alto-costmap+json",
      "accepts" : "application/alto-costmapfilter+json",
      "uses" : [ "my-default-network-map" ],
      "capabilities" : {
        "max-cost-types" : 2,
        "cost-type-names" : [ "num-routingcost",
                              "num-hopcount" ],
        ...
      }
 A legacy ALTO Client will ignore the "max-cost-types" capability and
 will send a request with the input parameter "cost-type" describing
 the desired cost metric, as defined in [RFC7285].  The ALTO Server
 will return a single-valued legacy cost map.
 However, a multi-cost-aware ALTO Client will realize that this
 resource supports the multi-cost extensions and can send a POST
 request with the new input parameter "multi-cost-types", whose value
 is an array of cost types.  Because the request has the "multi-cost-
 types" parameter (rather than the "cost-type" parameter defined in
 the base protocol), the Server realizes that the ALTO Client also

Randriamasy, et al. Standards Track [Page 7] RFC 8189 Multi-Cost ALTO October 2017

 supports the extensions in this document and hence responds with a
 multi-cost map with the costs in the order listed in "multi-cost-
 types".

3.4. Endpoint Cost Service Resources

 Section 4.1.4 of [RFC7285] specifies that "The Endpoint Cost Service
 allows an ALTO server to return costs directly amongst endpoints",
 whereas the Filtered Cost Map Service returns costs amongst Provider-
 defined Identifiers (PIDs).  This document uses the technique
 described in Section 3.3 to extend the Endpoint Cost Service to
 return array-valued costs to ALTO Clients who also are aware of these
 extensions.

3.5. Full Cost Map Resources

 Section 11.3.2.3 of [RFC7285] requires a filtered cost map to return
 the entire cost map if the ALTO Client omits the source and
 destination PIDs.  Hence, a multi-cost-aware ALTO Client can use an
 extended Filtered Cost Map resource to get a full multi-cost map.
 Full cost map resources are GET-mode requests.  The response for a
 full cost map conveying multiple cost types would include a "meta"
 field that would itself include a "cost-type" field that would list
 several values corresponding to the cost types of the cost map.  A
 legacy ALTO Client would not be able to understand this list.
 Neither would it be able to interpret the cost values array provided
 by a full multi-cost map.

3.6. Extended Constraint Tests

 [RFC7285] defines a simple constraint test capability for Filtered
 Cost Map and Endpoint Cost Services.  If a resource supports
 constraints, the Server restricts the response to costs that satisfy
 a list of simple predicates provided by the ALTO Client.  For
 example, if the ALTO Client gives the following constraints:
      "constraints": ["ge 10", "le 20"]
 then the Server only returns costs in the range [10,20].
 To be useful with multi-cost requests, the constraint tests require
 several extensions.

Randriamasy, et al. Standards Track [Page 8] RFC 8189 Multi-Cost ALTO October 2017

3.6.1. Extended Constraint Predicates

 First, because a multi-cost request involves more than one cost
 metric, the simple predicates must be extended to specify the metric
 to test.  Therefore, we extend the predicate syntax to "[##] op
 value", where "##" is the index of a cost metric in this multi-cost
 request.

3.6.2. Extended Logical Combination of Predicates

 Second, once multiple cost metrics are involved, the "AND" of simple
 predicates is no longer sufficient.  To be useful, Clients must be
 able to express "OR" tests.  Hence, we add a new field,
 "or-constraints", to the Client request.  The value is an array of
 arrays of simple predicates and represents the OR of ANDs of those
 predicates.
 Thus, the following request tells the Server to limit its response to
 cost points with "routingcost" <= 100 AND "hopcount" <= 2, OR else
 "routingcost" <= 10 AND "hopcount" <= 6:
    {
      "multi-cost-types": [
          {"cost-metric": "routingcost", "cost-mode": "numerical"},
          {"cost-metric": "hopcount",    "cost-mode": "numerical"}
      ],
      "or-constraints": [
          ["[0] le 100", "[1] le 2"],
          ["[0] le 10",  "[1] le 6"]
      ],
      "pids": {...}
    }
 Note that a "constraints" parameter with the array of predicates [P1,
 P2, ...] is equivalent to an "or-constraints" parameter with one
 array of value [[P1, P2, ...]].  A Client is therefore allowed to
 express either "constraints" or "or-constraints" but not both.

3.6.3. Testable Cost Types in Constraints

 Finally, a Client may want to test a cost type whose actual value is
 irrelevant, as long as it satisfies the tests.  For example, a Client
 may want the value of the cost metric "routingcost" for all PID pairs
 that satisfy constraints on the metric "hopcount", without needing
 the actual value of "hopcount".

Randriamasy, et al. Standards Track [Page 9] RFC 8189 Multi-Cost ALTO October 2017

 To this end, we add a specific parameter named "testable-cost-types"
 that does not contain the same cost types as parameter "multi-cost-
 types".  The Client can express constraints only on cost types listed
 in "testable-cost-types".
 For example, the following request tells the Server to return just
 "routingcost" for those source and destination pairs for which
 "hopcount" is <= 6:
    {
      "multi-cost-types": [
          {"cost-metric": "routingcost", "cost-mode": "numerical"},
      ],
      "testable-cost-types": [
          {"cost-metric": "hopcount", "cost-mode": "numerical"},
      ],
      "constraints": ["[0] le 6"],
      "pids": {...}
    }

3.6.4. Testable Cost Type Names in IRD Capabilities

 In [RFC7285], when a resource's capability "constraints" is true, the
 Server accepts constraints on all the cost types listed in the "cost-
 type-names" capability.  However, some ALTO Servers may not be
 willing to allow constraint tests on all available cost metrics.
 Therefore, the multi-cost ALTO protocol extension defines the
 capability field "testable-cost-type-names".  Like "cost-type-names",
 it is an array of cost type names.  If present, that resource only
 allows constraint tests on the cost types in that list. "testable-
 cost-type-names" must be a subset of "cost-type-names".

3.6.5. Legacy ALTO Client Issues

 While a multi-cost-aware Client will recognize the "testable-cost-
 type-names" field and will honor those restrictions, a legacy Client
 will not.  Hence, when "constraints" has the value 'true', a legacy
 Client may send a request with a constraint test on any of the cost
 types listed in "cost-type-names".
 To avoid that problem, the "testable-cost-type-names" and "cost-
 constraints" fields are mutually exclusive: a resource may define one
 or the other capability but MUST NOT define both.  Thus, a resource
 that does not allow constraint tests on all cost metrics will set
 "testable-cost-type-names" to the testable metrics and will set
 "cost-constraints" to 'false'.  A multi-cost-aware Client will
 recognize the "testable-cost-type-names" field and will realize that
 its existence means the resource does allow (limited) constraint

Randriamasy, et al. Standards Track [Page 10] RFC 8189 Multi-Cost ALTO October 2017

 tests, while a legacy Client will think that resource does not allow
 constraint tests at all.  To allow legacy Clients to use constraint
 tests, the ALTO Server can define an additional resource with "cost-
 constraints" set to 'true' and "cost-type-names" set to the metrics
 that can be tested.
 In the IRD example below, the resource "filtered-cost-map-extended"
 provides values for three metrics: "num-routingcost", "num-hopcount",
 and "num-bwscore".  The capability "testable-cost-type-names"
 indicates that the Server only allows constraints on "routingcost"
 and "hopcount".  A multi-cost-capable Client will see this capability
 and will limit its constraint tests to those metrics.  Because
 capability "cost-constraints" is false (by default), a legacy Client
 will not use constraint tests on this resource at all.
 The second resource, "filtered-multicost-map", is similar to the
 first, except that all the metrics it returns are testable.
 Therefore, it sets "cost-constraints" to 'true' and does not set the
 "testable-cost-type-names" field.  A legacy Client that needs a
 constraint test will use this resource rather than the first.  A
 multi-cost-aware Client that does not need to retrieve the
 "num-bwscore" metric may use either resource.
 Note that if a multi-cost Server specifies a "filtered-cost-map-
 extended", it will most likely not specify an "filtered-multicost-
 map" if the capabilities of the latter are covered by the
 capabilities of the former or unless the "filtered-multicost-map"
 resource is also intended for legacy Clients.

Randriamasy, et al. Standards Track [Page 11] RFC 8189 Multi-Cost ALTO October 2017

 "filtered-cost-map-extended" : {
    "uri" : "http://alto.example.com/multi/extn/costmap/filtered",
    "media-type" : "application/alto-costmap+json",
    "accepts" : "application/alto-costmapfilter+json",
    "uses" : [ "my-default-network-map" ],
    "capabilities" : {
       "max-cost-types" : 3,
       "cost-type-names" : [ "num-routingcost",
                             "num-hopcount",
                             "num-bwscore"],
       "testable-cost-type-names" : [ "num-routingcost",
                                      "num-hopcount" ]
    }
 },
 "filtered-multicost-map" : {
    "uri" : "http://alto.example.com/multi/costmap/filtered",
    "media-type" : "application/alto-costmap+json",
    "accepts" : "application/alto-costmapfilter+json",
    "uses" : [ "my-default-network-map" ],
    "capabilities" : {
      "cost-constraints" : true,
      "max-cost-types" : 2,
      "cost-type-names" : [ "num-routingcost",
                            "num-hopcount"],
    }
 }

4. Protocol Extensions for Multi-Cost ALTO Transactions

 This section formally specifies the extensions to [RFC7285] to
 support multi-cost ALTO transactions.
 This document uses the notation rules specified in Section 8.2 of
 [RFC7285].  In particular, an optional field is enclosed by [ ].  In
 the definitions, the JSON names of the fields are case sensitive.  An
 array is indicated by two numbers in angle brackets, <m..n>, where m
 indicates the minimal number of values and n is the maximum.  When
 this document uses * for n, it means no upper bound.

4.1. Filtered Cost Map Extensions

 This document extends Filtered Cost Maps, as defined in
 Section 11.3.2 of [RFC7285], by adding new input parameters and
 capabilities and by returning JSONArrays instead of JSONNumbers as
 the cost values.

Randriamasy, et al. Standards Track [Page 12] RFC 8189 Multi-Cost ALTO October 2017

 The media type, HTTP method, and "uses" specifications (described in
 Sections 11.3.2.1, 11.3.2.2, and 11.3.2.5 of [RFC7285], respectively)
 are unchanged.

4.1.1. Capabilities

 The filtered cost map capabilities are extended with two new members:
 o  max-cost-types
 o  testable-cost-type-names
 The capability "max-cost-types" indicates whether this resource
 supports the multi-cost ALTO extensions, and the capability
 "testable-cost-type-names" allows the resource to restrict constraint
 tests to a subset of the available cost types.  With these two
 additional members, the FilteredCostMapCapabilities object in
 Section 11.3.2.4 of [RFC7285] is structured as follows:
     object {
        JSONString cost-type-names<1..*>;
        [JSONBool cost-constraints;]
        [JSONNumber max-cost-types;]
        [JSONString testable-cost-type-names<1..*>;]
     } FilteredCostMapCapabilities;
 cost-type-names:  As defined in Section 11.3.2.4 of [RFC7285].
 cost-constraints:  As defined in Section 11.3.2.4 of [RFC7285].
    Thus, if "cost-constraints" is true, the resource MUST accept
    constraint tests on any cost type in "cost-type-names".  In
    addition, note that if "cost-constraints" is true, the "testable-
    cost-type-names" capability MUST NOT be present.
 max-cost-types:  If present with value N greater than 0, this
    resource understands the multi-cost extensions in this document
    and can return a multi-cost map with any combination of N or fewer
    cost types in the "cost-type-names" list.  If omitted, the default
    value is 0.
 testable-cost-type-names:  If present, the resource allows constraint
    tests, but only on the cost type names in this array.  Each name
    in "testable-cost-type-names" MUST also be in "cost-type-names".
    If "testable-cost-type-names" is present, the "cost-constraints"
    capability MUST NOT be true.

Randriamasy, et al. Standards Track [Page 13] RFC 8189 Multi-Cost ALTO October 2017

    As discussed in Section 3.6.4, this capability is useful when a
    Server is unable or unwilling to implement constraint tests on all
    cost types.  As discussed in Section 3.6.5, "testable-cost-type-
    names" and "cost-constraints" are mutually exclusive to prevent
    legacy Clients from issuing constraint tests on untestable cost
    types.

4.1.2. Accept Input Parameters

 The ReqFilteredCostMap object in Section 11.3.2.3 of [RFC7285] is
 extended as follows:
     object {
        [CostType cost-type;]
        [CostType multi-cost-types<1..*>;]
        [CostType testable-cost-types<1..*>;]
        [JSONString constraints<0..*>;]
        [JSONString or-constraints<1..*><1..*>;]
        [PIDFilter pids];
     } ReqFilteredCostMap;
 cost-type:  As defined in Section 11.3.2.3 of [RFC7285], with the
    additional requirement that the Client MUST specify either "cost-
    type" or "multi-cost-types" but MUST NOT specify both.  Therefore,
    this field is made optional.  When placing a single cost request
    as specified in [RFC7285], a Client MUST use "cost-type".
 multi-cost-types:  If present, the ALTO Server MUST return array-
    valued costs for the cost types in this list.  For each entry, the
    "cost-metric" and "cost-mode" fields MUST match one of the
    supported cost types indicated in member "cost-type-names" of this
    resource's "capabilities" field (Section 4.1.1).  The Client MUST
    NOT use this field unless this resource's "max-cost-types"
    capability exists and has a value greater than 0.  This field MUST
    NOT have more than "max-cost-types" cost types.  The Client MUST
    specify either "cost-type" or "multi-cost-types" but MUST NOT
    specify both.
    Note that if "multi-cost-types" has one cost type, the values in
    the cost map will be arrays with one value.
 testable-cost-types:  A list of cost types used for extended
    constraint tests, as described for the "constraints" and
    "or-constraints" parameters.  These cost types must either be a
    subset of the cost types in the resource's
    "testable-cost-type-names" capability (Section 4.1.1), or else, if
    the resource's capability "cost-constraints" is true, a subset of
    the cost types in the resource's "cost-type-names" capability.

Randriamasy, et al. Standards Track [Page 14] RFC 8189 Multi-Cost ALTO October 2017

    If "testable-cost-types" is omitted, it is assumed to have the
    cost types in "multi-cost-types" or "cost-type".
    This feature is useful when a Client wants to test a cost type
    whose actual value is irrelevant, as long as it satisfies the
    tests.  For example, a Client may want the cost metric
    "routingcost" for those PID pairs whose "hopcount" is less than
    10.  The exact hop count does not matter.
 constraints:  If this resource's "max-cost-types" capability
    (Section 4.1.1) has the value 0 (or is not defined), this
    parameter is as defined in Section 11.3.2.3 of [RFC7285]: an array
    of constraint tests related to each other by a logical AND.  In
    this case, it MUST NOT be specified unless the resource's "cost-
    constraints" capability is true.
    If this resource's "max-cost-types" capability has a value greater
    than 0, then this parameter is an array of extended constraint
    predicates as defined below and related to each other by a logical
    AND.  In this case, it MAY be specified if the resource allows
    constraint tests (the resource's "cost-constraints" capability is
    true, or its "testable-cost-type-names" capability is not empty).
    This parameter MUST NOT be specified if the "or-constraints"
    parameter is specified.
    An extended constraint predicate consists of two or three entities
    separated by white space: (1) an optional cost type index of the
    form "[#]" with default value "[0]", (2) a required operator, and
    (3) a required target value.  The operator and target value are as
    defined in Section 11.3.2.3 of [RFC7285].  The cost type index, i,
    specifies the cost type to test.  If the "testable-cost-type"
    parameter is present, the test applies to the i'th cost type in
    "testable-cost-types", starting with index 0.  Otherwise, if the
    "multi-cost-types" parameter is present, the test applies to the
    i'th cost type in that array.  If neither parameter is present,
    the test applies to the cost type in the "cost-type" parameter, in
    which case the index MUST be 0.  Regardless of how the tested cost
    type is selected, it MUST be in the resource's "testable-cost-
    type-names" capability or, if not present, in the "cost-type-
    names" capability.
    As an example, suppose "multi-cost-types" has the single element
    "routingcost", "testable-cost-types" has the single element
    "hopcount", and "constraints" has the single element "[0] le 5".
    This is equivalent to the database query "SELECT and provide
    routingcost WHERE hopcount <= 5".

Randriamasy, et al. Standards Track [Page 15] RFC 8189 Multi-Cost ALTO October 2017

    Note that the index is optional, so a constraint test as defined
    in Section 11.3.2.3 of [RFC7285], such as "le 10", is equivalent
    to "[0] le 10".  Thus, legacy constraint tests are also legal
    extended constraint tests.
    Note that a "constraints" parameter with the array of extended
    predicates [P1, P2, ...] is equivalent to an "or-constraints"
    parameter as defined below with the value [[P1, P2, ...]].
 or-constraints:  A JSONArray of JSONArrays of JSONStrings, where each
    string is an extended constraint predicate as defined above.  The
    "or-constraint" tests are interpreted as the logical OR of ANDs of
    predicates.  That is, the ALTO Server should return a cost point
    only if it satisfies all constraints in any one of the sub-arrays.
    This parameter MAY be specified if this resource's "max-cost-
    types" capability is defined with a value greater than 0
    (Section 4.1.1) and if the resource allows constraint tests (the
    resource's "cost-constraints" capability is true, or its
    "testable-cost-type-names" capability is not empty).  Otherwise,
    this parameter MUST NOT be specified.
    This parameter MUST NOT be specified if the "constraints"
    parameter is specified.
    This parameter MUST NOT contain any empty array of AND predicates.
    An empty array would be equivalent to a constraint that is always
    true.  An OR combination including such a constraint would be
    always true and thus useless.
    As an example, suppose "multi-cost-types" has the two elements
    "routingcost" and "bandwidthscore", "testable-cost-types" has the
    two elements "routingcost" and "hopcount", and "or-constraints"
    has the two elements ["[0] le 100", "[1] le 2"] and ["[0] le 10",
    "[1] le 6"].  This is equivalent to the words: "SELECT and provide
    routingcost and bandwidthscore WHERE ("routingcost" <= 100 AND
    "hopcount" <= 2) OR ("routingcost" <= 10 AND "hopcount" <= 6)".
    Note that if the "max-cost-types" capability has a value greater
    than 0, a Client MAY use the "or-constraints" parameter together
    with the "cost-type" parameter.  That is, if the Client and Server
    are both aware of the extensions in this document, a Client MAY
    use an "OR" test for a single-valued cost request.
 pids:  As defined in Section 11.3.2.3 of [RFC7285].

Randriamasy, et al. Standards Track [Page 16] RFC 8189 Multi-Cost ALTO October 2017

4.1.3. Response

 If the Client specifies the "cost-type" input parameter, the response
 is exactly as defined in Section 11.2.3.6 of [RFC7285].  If the
 Client provides the "multi-cost-types" instead, then the response is
 changed as follows:
 o  In "meta", the value of field "cost-type" will be ignored by the
    receiver and set to {}.  Instead, the field "multi-cost-types" is
    added with the same value as the "multi-cost-types" input
    parameter.
 o  The costs are JSONArrays instead of JSONNumbers.  All arrays have
    the same cardinality as the "multi-cost-types" input parameter and
    contain the cost type values in that order.  If a cost type is not
    available for a particular source and destination, the ALTO Server
    MUST use the JSON "null" value for that array element.  If none of
    the cost types are available for a particular source and
    destination, the ALTO Server MAY omit the entry for that source
    and destination.

4.2. Endpoint Cost Service Extensions

 This document extends the Endpoint Cost Service, as defined in
 Section 11.5.1 of [RFC7285], by adding new input parameters and
 capabilities and by returning JSONArrays instead of JSONNumbers as
 the cost values.
 The media type, HTTP method, and "uses" specifications (described in
 Sections 11.5.1.1, 11.5.1.2, and 11.5.1.5 of [RFC7285], respectively)
 are unchanged.

4.2.1. Capabilities

 The extensions to the Endpoint Cost Service capabilities are
 identical to the extensions to the Filtered Cost Map (see
 Section 4.1.1).

Randriamasy, et al. Standards Track [Page 17] RFC 8189 Multi-Cost ALTO October 2017

4.2.2. Accept Input Parameters

 The ReqEndpointCostMap object in Section 11.5.1.3 of [RFC7285] is
 extended 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;
     } ReqEndpointCostMap;
 cost-type:  As defined in Section 11.5.1.3 of [RFC7285], with the
    additional requirement that the Client MUST specify either "cost-
    type" or "multi-cost-types" but MUST NOT specify both.
 multi-cost-types:  If present, the ALTO Server MUST return array-
    valued costs for the cost types in this list.  For each entry, the
    "cost-metric" and "cost-mode" fields MUST match one of the
    supported cost types indicated in this resource's "capabilities"
    field (Section 4.2.1).  The Client MUST NOT use this field unless
    this resource's "max-cost-types" capability exists and has a value
    greater than 0.  This field MUST NOT have more than "max-cost-
    types" cost types.  The Client MUST specify either "cost-type" or
    "multi-cost-types" but MUST NOT specify both.
    Note that if "multi-cost-types" has one cost type, the values in
    the cost map will be arrays with one value.
 testable-cost-types, constraints, or-constraints:  Defined
    equivalently to the corresponding input parameters for an extended
    filtered cost map (Section 4.1.2).
 endpoints:  As defined in Section 11.5.1.3 of [RFC7285].

Randriamasy, et al. Standards Track [Page 18] RFC 8189 Multi-Cost ALTO October 2017

4.2.3. Response

 The extensions to the Endpoint Cost Service response are similar to
 the extensions to the Filtered Cost Map response (Section 4.1.3).
 Specifically, if the Client specifies the "cost-type" input
 parameter, the response is exactly as defined in Section 11.5.1.6 of
 [RFC7285].  If the Client provides the "multi-cost-types" instead,
 then the response is changed as follows:
 o  In "meta", the value of field "cost-type" will be ignored by the
    receiver and set to {}.  Instead, the field "multi-cost-types" is
    added with the same value as the "multi-cost-types" input
    parameter.
 o  The costs are JSONArrays instead of JSONNumbers.  All arrays have
    the same cardinality as the "multi-cost-types" input parameter and
    contain the cost type values in that order.  If a cost type is not
    available for a particular source and destination, the ALTO Server
    MUST use the JSON "null" value for that array element.  If none of
    the cost types are available for a particular source and
    destination, the ALTO Server MAY omit the entry for that source
    and destination.

5. Examples

 This section provides examples of multi-cost ALTO transactions.  It
 uses cost metrics, in addition to the mandatory legacy "routingcost",
 that are deliberately irrelevant and not registered with IANA.

5.1. Information Resource Directory

 The following is an example of an ALTO Server's Information Resource
 Directory.  In addition to network and cost map resources, it defines
 two Filtered Cost Maps and an Endpoint Cost Service, which all
 understand the multi-cost extensions.
 GET /directory HTTP/1.1
 Host: alto.example.com
 Accept: application/alto-directory+json,application/alto-error+json
 HTTP/1.1 200 OK
 Content-Length: 2704
 Content-Type: application/alto-directory+json

Randriamasy, et al. Standards Track [Page 19] RFC 8189 Multi-Cost ALTO October 2017

 {
   "meta" : {
     "default-alto-network-map" : "my-default-network-map",
     "cost-types" : {
       "num-routing" : {
         "cost-mode" : "numerical",
         "cost-metric" : "routingcost"
       },
       "num-shoesize" : {
         "cost-mode" : "numerical",
         "cost-metric" : "shoesize"
       },
       "num-scenery" : {
         "cost-mode" : "numerical",
         "cost-metric" : "sceneryrate"
       }
     }
   },
   "resources" : {
     "my-default-network-map" : {
       "uri" : "http://alto.example.com/networkmap",
       "media-type" : "application/alto-networkmap+json"
     },
     "numerical-routing-cost-map" : {
       "uri" : "http://alto.example.com/costmap/num-routing",
       "media-type" : "application/alto-costmap+json",
       "uses" : [ "my-default-network-map" ],
       "capabilities" : {
         "cost-type-names" : [ "num-routing" ]
       }
     },
     "numerical-shoesize-cost-map" : {
       "uri" : "http://alto.example.com/costmap/num-shoesize",
       "media-type" : "application/alto-costmap+json",
       "uses" : [ "my-default-network-map" ],
       "capabilities" : {
         "cost-type-names" : [ "num-shoesize" ]
       }
     },
     "filtered-multicost-map" : {
       "uri" : "http://alto.example.com/multi/costmap/filtered",
       "media-type" : "application/alto-costmap+json",
       "accepts" : "application/alto-costmapfilter+json",
       "uses" : [ "my-default-network-map" ],
       "capabilities" : {
         "cost-constraints" : true,
         "max-cost-types" : 2,
         "cost-type-names" : [ "num-routingcost",

Randriamasy, et al. Standards Track [Page 20] RFC 8189 Multi-Cost ALTO October 2017

                               "num-shoesize" ]
       }
     },
     "filtered-cost-map-extended" : {
       "uri" : "http://alto.example.com/multi/extn/costmap/filtered",
       "media-type" : "application/alto-costmap+json",
       "accepts" : "application/alto-costmapfilter+json",
       "uses" : [ "my-default-network-map" ],
       "capabilities" : {
         "max-cost-types" : 3,
         "cost-type-names" : [ "num-routingcost",
                               "num-shoesize",
                               "num-scenery"],
         "testable-cost-type-names" : [ "num-routingcost",
                                        "num-shoesize" ]
       }
     },
     "endpoint-multicost-map" : {
       "uri" : "http://alto.example.com/multi/endpointcost/lookup",
       "media-type" : "application/alto-endpointcost+json",
       "accepts" : "application/alto-endpointcostparams+json",
       "uses" : [ "my-default-network-map" ],
       "capabilities" : {
         "cost-constraints" : true,
         "max-cost-types" : 2,
         "cost-type-names" : [ "num-routingcost",
                               "num-shoesize" ]
       }
     }
   }
 }

5.2. Multi-Cost Filtered Cost Map: Example #1

 This example illustrates a simple multi-cost ALTO transaction.  The
 ALTO Server provides two cost types, "routingcost" and "shoesize",
 both in "numerical" mode.  The Client wants the entire multi-cost
 map.  The Server does not know the value of "routingcost" between
 PID2 and PID3 and hence returns the value 'null' for "routingcost"
 between PID2 and PID3.

Randriamasy, et al. Standards Track [Page 21] RFC 8189 Multi-Cost ALTO October 2017

 POST /multi/costmap/filtered" HTTP/1.1
 Host: alto.example.com
 Accept: application/alto-costmap+json,application/alto-error+json
 Content-Type: application/alto-costmapfilter+json
 Content-Length: 206
 {
   "multi-cost-types": [
     {"cost-mode": "numerical", "cost-metric": "routingcost"},
     {"cost-mode": "numerical", "cost-metric": "shoesize"}
   ],
   "pids" : {
     "srcs" : [ ],
     "dsts" : [ ]
   }
 }
 HTTP/1.1 200 OK
 Content-Type: application/alto-costmap+json
 Content-Length: 549
 {
  "meta" : {
    "dependent-vtags" : [
      {"resource-id": "my-default-network-map",
       "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e"
      }
    ],
    "cost-type" : {},
    "multi-cost-types" : [
      {"cost-mode": "numerical", "cost-metric": "routingcost"},
      {"cost-mode": "numerical", "cost-metric": "shoesize"}
    ]
  }
  "cost-map" : {
    "PID1": { "PID1":[1,0],   "PID2":[4,3],    "PID3":[10,2]   },
    "PID2": { "PID1":[15,5],  "PID2":[1,0],    "PID3":[null,9] },
    "PID3": { "PID1":[20,12], "PID2":[null,1], "PID3":[1,0]    }
  }
 }

Randriamasy, et al. Standards Track [Page 22] RFC 8189 Multi-Cost ALTO October 2017

5.3. Multi-Cost Filtered Cost Map: Example #2

 This example uses constraints to restrict the returned source/
 destination PID pairs to those with "routingcost" between 5 and 10 or
 "shoesize" equal to 0.
 POST /multi/costmap/filtered HTTP/1.1
 Host: alto.example.com
 Accept: application/alto-costmap+json,application/alto-error+json
 Content-Type: application/alto-costmapfilter+json
 Content-Length: 333
 {
   "multi-cost-types" : [
     {"cost-mode": "numerical", "cost-metric": "routingcost"},
     {"cost-mode": "numerical", "cost-metric": "shoesize"}
   ],
   "or-constraints" : [ ["[0] ge 5", "[0] le 10"],
                        ["[1] eq 0"] ]
   "pids" : {
     "srcs" : [ "PID1", "PID2" ],
     "dsts" : [ "PID1", "PID2", "PID3" ]
   }
 }
 HTTP/1.1 200 OK
 Content-Type: application/alto-costmap+json
 Content-Length: 461
 {
   "meta" : {
     "dependent-vtags" : [
       {"resource-id": "my-default-network-map",
        "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e"
       }
     ],
     "cost-type" : {},
     "multi-cost-types" : [
       {"cost-mode": "numerical", "cost-metric": "routingcost"},
       {"cost-mode": "numerical", "cost-metric": "shoesize"}
     ]
   }
   "cost-map" : {
     "PID1": { "PID1": [1,0], "PID3": [10,5] },
     "PID2": { "PID2": [1,0]                 }
   }
 }

Randriamasy, et al. Standards Track [Page 23] RFC 8189 Multi-Cost ALTO October 2017

5.4. Multi-Cost Filtered Cost Map: Example #3

 This example uses extended constraints to limit the response to cost
 points with ("routingcost" <= 10 AND "shoesize" <= 2), OR else
 ("routingcost" <= 3 AND "shoesize" <= 6).  Unlike the previous
 example, the Client is only interested in the "routingcost" cost type
 and uses the "cost-type" parameter instead of "multi-cost-types" to
 tell the Server to return scalar costs instead of array costs.
 In this example, "[0]" means the constraint applies to "routingcost"
 because that is the first cost type in the "testable-cost-types"
 parameter.  (If "testable-cost-types" is omitted, it is assumed to be
 the same as "multi-cost-types".)  The choice of using an index to
 refer to cost types aims at minimizing the length of the expression
 of constraints, especially for those combining several OR and AND
 expressions.  It was also the shortest path from the constraints
 design in [RFC7285].
 POST /multi/multicostmap/filtered HTTP/1.1
 Host: alto.example.com
 Accept: application/alto-costmap+json,application/alto-error+json
 Content-Type: application/alto-costmapfilter+json
 Content-Length: 390
 {
   "cost-type" : {
     "cost-mode": "numerical", "cost-metric": "routingcost"
   },
   "testable-cost-types" : [
     {"cost-mode": "numerical", "cost-metric": "routingcost"},
     {"cost-mode": "numerical", "cost-metric": "shoesize"}
   ],
   "or-constraints": [
          ["[0] le 10", "[1] le 2"],
          ["[0] le 3",  "[1] le 6"]
   ],
   "pids" : {
     "srcs" : [ ],
     "dsts" : [ ]
   }
 }

Randriamasy, et al. Standards Track [Page 24] RFC 8189 Multi-Cost ALTO October 2017

 HTTP/1.1 200 OK
 Content-Type: application/alto-costmap+json
 Content-Length: 368
 {
   "meta" : {
     "dependent-vtags" : [
       {"resource-id": "my-default-network-map",
        "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e"
       }
     ],
     "cost-type" : {
       "cost-mode": "numerical", "cost-metric": "routingcost"
     }
   }
   "cost-map" : {
     "PID1": { "PID1": 1, "PID3": 10 },
     "PID2": { "PID2": 1 },
     "PID3": { "PID3": 1 }
   }
 }

5.5. Multi-Cost Filtered Cost Map: Example #4

 This example uses extended constraints to limit the response to cost
 points with ("routingcost" <= 10 AND "shoesize" <= 2), OR else
 ("routingcost" <= 3 AND "shoesize" <= 6).  In this example, the
 Client is interested in the "routingcost" and "sceneryrate" cost
 metrics but not in the "shoesize" metric:
 POST /multi/extn/costmap/filtered HTTP/1.1
 Host: alto.example.com
 Accept: application/alto-costmap+json,application/alto-error+json
 Content-Type: application/alto-costmapfilter+json
 Content-Length: 461
 {
   "multi-cost-types" : [
     {"cost-mode": "numerical", "cost-metric": "routingcost"},
     {"cost-mode": "numerical", "cost-metric": "sceneryrate"}
   ],
   "testable-cost-types" : [
     {"cost-mode": "numerical", "cost-metric": "routingcost"},
     {"cost-mode": "numerical", "cost-metric": "shoesize"}
   ],

Randriamasy, et al. Standards Track [Page 25] RFC 8189 Multi-Cost ALTO October 2017

   "or-constraints": [
          ["[0] le 10", "[1] le 2"],
          ["[0] le 3",  "[1] le 6"]
   ],
   "pids" : {
     "srcs" : [ ],
     "dsts" : [ ]
   }
 }
 HTTP/1.1 200 OK
 Content-Type: application/alto-costmap+json
 Content-Length: 481
 {
   "meta" : {
     "dependent-vtags" : [
       {"resource-id": "my-default-network-map",
        "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e"
       }
     ],
     "cost-type" : {},
     "multi-cost-types" : [
       {"cost-mode": "numerical", "cost-metric": "routingcost"},
       {"cost-mode": "numerical", "cost-metric": "sceneryrate"}
     ]
   }
   "cost-map" : {
     "PID1": { "PID1": [1,16] "PID3": [10,19] },
     "PID2": { "PID2": [1,8] },
     "PID3": { "PID3": [1,19] }
   }
 }

5.6. Endpoint Cost Service

 This example uses the Endpoint Cost Service to retrieve the
 "routingcost" and "shoesize" for selected endpoints, limiting the
 response to costs with either low "shoesize" and reasonable
 "routingcost" ("shoesize" <= 2 AND "routingcost" <= 10), OR else low
 "routingcost" and reasonable "shoesize" ("routingcost" <= 3 AND
 "shoesize" <= 6).
 POST /multi/endpointcost/lookup HTTP/1.1
 Host: alto.example.com
 Accept: application/alto-endpointcost+json,
         application/alto-error+json

Randriamasy, et al. Standards Track [Page 26] RFC 8189 Multi-Cost ALTO October 2017

 Content-Type: application/alto-endpoincostparams+json
 Content-Length: 455
 {
   "multi-cost-types" : [
     {"cost-mode": "numerical", "cost-metric": "routingcost"},
     {"cost-mode": "numerical", "cost-metric": "shoesize"}
   ],
   "or-constraints": [
          ["[0] le 10", "[1] le 2"],
          ["[0] le 3",  "[1] le 6"]
   ],
   "endpoints" : {
     "srcs": [ "ipv4:192.0.2.2", "ipv6:2001:db8::1:0 ],
     "dsts": [
       "ipv4:192.0.2.89",
       "ipv4:198.51.100.34",
       "ipv4:203.0.113.45",
       "ipv6:2001:db8::10"
     ]
   }
 }
 HTTP/1.1 200 OK
 Content-Length: 419
 Content-Type: application/alto-endpointcost+json
 {
   "meta" : {
     "multi-cost-types" : [
       {"cost-mode": "numerical", "cost-metric": "routingcost"},
       {"cost-mode": "numerical", "cost-metric": "shoesize"}
     ]
   }
   "endpoint-cost-map" : {
     "ipv4:192.0.2.2": {
       "ipv4:192.0.2.89":    [15, 5],
       "ipv4:203.0.113.45":  [4, 23]
     }
     "ipv6:2001:db8::1:0": {
       "ipv4:198.51.100.34": [16, 5],
       "ipv6:2001:db8::10":  [10, 2]
     }
   }
 }

Randriamasy, et al. Standards Track [Page 27] RFC 8189 Multi-Cost ALTO October 2017

6. IANA Considerations

 This document does not define any new media types or introduce any
 new IANA considerations.

7. Privacy and Security Considerations

 This document does not introduce any privacy or security issues not
 already present in the ALTO protocol.
 The multi-cost optimization even tends to reduce the on-the-wire data
 exchange volume compared to multiple single cost ALTO transactions.
 Likewise, the risk related to massive multi-cost requests is
 moderated by the fact that multi-cost constraints additionally filter
 ALTO Server responses and thus reduce their volume.
 Note that, because queries for multiple metrics represent a stronger
 fingerprinting signal than queries for a single metric,
 implementations of this protocol may leak more information about the
 ALTO Client than would occur with a succession of individual queries.
 Though, in many cases, it would already be possible to link those
 queries by using the source IP address or other existing information.

8. References

8.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,
            <https://www.rfc-editor.org/info/rfc2119>.
 [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,
            <https://www.rfc-editor.org/info/rfc7285>.
 [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
            2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
            May 2017, <https://www.rfc-editor.org/info/rfc8174>.

8.2. Informative References

 [RFC7159]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
            Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
            2014, <https://www.rfc-editor.org/info/rfc7159>.

Randriamasy, et al. Standards Track [Page 28] RFC 8189 Multi-Cost ALTO October 2017

Acknowledgements

 The authors would like to thank Richard Alimi, Fred Baker, Dhruv
 Dhodi, Vijay Gurbani, Dave Mac Dysan, Young Lee, and Richard Yang for
 fruitful discussions and feedback on this document and earlier draft
 versions.  Gao Kai, Hans Seidel, Richard Yang, Qiao Xiang, and Wang
 Xin provided substantial review feedback and suggestions to the
 protocol design.

Authors' Addresses

 Sabine Randriamasy
 Nokia Bell Labs
 Route de Villejust
 Nozay  91460
 France
 Email: Sabine.Randriamasy@nokia-bell-labs.com
 Wendy Roome
 Nokia Bell Labs
 124 Burlington Rd
 Murray Hill, NJ  07974
 United States of America
 Email: ietf@wdroome.com
 Nico Schwan
 Thales Deutschland
 Lorenzstrasse 10
 Stuttgart  70435
 Germany
 Email: nico.schwan@thalesgroup.com

Randriamasy, et al. Standards Track [Page 29]

/data/webs/external/dokuwiki/data/pages/rfc/rfc8189.txt · Last modified: 2017/10/25 00:13 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki