draft-ietf-alto-multi-cost-10.txt   rfc8189.txt 
Network Working Group S. Randriamasy Internet Engineering Task Force (IETF) S. Randriamasy
Internet-Draft W. Roome Request for Comments: 8189 W. Roome
Intended status: Standards Track Nokia Bell Labs Category: Standards Track Nokia Bell Labs
Expires: October 29, 2017 N. Schwan ISSN: 2070-1721 N. Schwan
Thales Deutschland Thales Deutschland
April 27, 2017 October 2017
Multi-Cost ALTO Multi-Cost Application-Layer Traffic Optimization (ALTO)
draft-ietf-alto-multi-cost-10
Abstract Abstract
The ALTO (Application Layer-Traffic Optimization) Protocol The Application-Layer Traffic Optimization (ALTO) protocol, specified
([RFC7285]) defines several services that return various metrics in RFC 7285, defines several services that return various metrics
describing the costs between network endpoints. describing the costs between network endpoints.
This document defines a new service that allows an ALTO Client to This document defines a new service that allows an ALTO Client to
retrieve several cost metrics in a single request for an ALTO retrieve several cost metrics in a single request for an ALTO
Filtered Cost Map and Endpoint Cost Map. In addition, it extends the filtered cost map and endpoint cost map. In addition, it extends the
constraints to further filter those maps by allowing a client to constraints to further filter those maps by allowing an ALTO Client
specify a logical combination of tests on several cost metrics. to specify a logical combination of tests on several cost metrics.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on October 29, 2017. 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.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview Of Approach . . . . . . . . . . . . . . . . . . . . 5 3. Overview Of Approach . . . . . . . . . . . . . . . . . . . . 6
3.1. Multi-Cost Data Format . . . . . . . . . . . . . . . . . 5 3.1. Multi-Cost Data Format . . . . . . . . . . . . . . . . . 6
3.2. Compatibility With Legacy ALTO Clients . . . . . . . . . 5 3.2. Compatibility with Legacy ALTO Clients . . . . . . . . . 7
3.3. Filtered Multi Cost Map Resources . . . . . . . . . . . . 6 3.3. Filtered Multi-Cost Map Resources . . . . . . . . . . . . 7
3.4. Endpoint Cost Service Resources . . . . . . . . . . . . . 6 3.4. Endpoint Cost Service Resources . . . . . . . . . . . . . 8
3.5. Full Cost Map Resources . . . . . . . . . . . . . . . . . 7 3.5. Full Cost Map Resources . . . . . . . . . . . . . . . . . 8
3.6. Extended Constraint Tests . . . . . . . . . . . . . . . . 7 3.6. Extended Constraint Tests . . . . . . . . . . . . . . . . 8
3.6.1. Extended constraint predicates . . . . . . . . . . . 7 3.6.1. Extended Constraint Predicates . . . . . . . . . . . 9
3.6.2. Extended logical combination of predicates . . . . . 7 3.6.2. Extended Logical Combination of Predicates . . . . . 9
3.6.3. Testable Cost Types in constraints . . . . . . . . . 8 3.6.3. Testable Cost Types in Constraints . . . . . . . . . 9
3.6.4. Testable Cost Type Names in IRD capabilities . . . . 9 3.6.4. Testable Cost Type Names in IRD Capabilities . . . . 10
3.6.5. Legacy ALTO Client issues . . . . . . . . . . . . . . 9 3.6.5. Legacy ALTO Client Issues . . . . . . . . . . . . . . 10
4. Protocol Extensions for Multi-Cost ALTO Transactions . . . . 11 4. Protocol Extensions for Multi-Cost ALTO Transactions . . . . 12
4.1. Filtered Cost Map Extensions . . . . . . . . . . . . . . 11 4.1. Filtered Cost Map Extensions . . . . . . . . . . . . . . 12
4.1.1. Capabilities . . . . . . . . . . . . . . . . . . . . 11 4.1.1. Capabilities . . . . . . . . . . . . . . . . . . . . 13
4.1.2. Accept Input Parameters . . . . . . . . . . . . . . . 12 4.1.2. Accept Input Parameters . . . . . . . . . . . . . . . 14
4.1.3. Response . . . . . . . . . . . . . . . . . . . . . . 15 4.1.3. Response . . . . . . . . . . . . . . . . . . . . . . 17
4.2. Endpoint Cost Service Extensions . . . . . . . . . . . . 15 4.2. Endpoint Cost Service Extensions . . . . . . . . . . . . 17
4.2.1. Capabilities . . . . . . . . . . . . . . . . . . . . 16 4.2.1. Capabilities . . . . . . . . . . . . . . . . . . . . 17
4.2.2. Accept Input Parameters . . . . . . . . . . . . . . . 16 4.2.2. Accept Input Parameters . . . . . . . . . . . . . . . 18
4.2.3. Response . . . . . . . . . . . . . . . . . . . . . . 17 4.2.3. Response . . . . . . . . . . . . . . . . . . . . . . 19
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1. Information Resource Directory . . . . . . . . . . . . . 17 5.1. Information Resource Directory . . . . . . . . . . . . . 19
5.2. Multi-Cost Filtered Cost Map: Example #1 . . . . . . . . 19 5.2. Multi-Cost Filtered Cost Map: Example #1 . . . . . . . . 21
5.3. Multi-Cost Filtered Cost Map: Example #2 . . . . . . . . 20 5.3. Multi-Cost Filtered Cost Map: Example #2 . . . . . . . . 23
5.4. Multi-Cost Filtered Cost Map: Example #3 . . . . . . . . 22 5.4. Multi-Cost Filtered Cost Map: Example #3 . . . . . . . . 24
5.5. Multi-Cost Filtered Cost Map: Example #4 . . . . . . . . 23 5.5. Multi-Cost Filtered Cost Map: Example #4 . . . . . . . . 25
5.6. Endpoint Cost Service . . . . . . . . . . . . . . . . . . 24 5.6. Endpoint Cost Service . . . . . . . . . . . . . . . . . . 26
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
7. Privacy And Security Considerations . . . . . . . . . . . . . 26 7. Privacy and Security Considerations . . . . . . . . . . . . . 28
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 8.1. Normative References . . . . . . . . . . . . . . . . . . 28
9.1. Normative References . . . . . . . . . . . . . . . . . . 26 8.2. Informative References . . . . . . . . . . . . . . . . . 28
9.2. Informative References . . . . . . . . . . . . . . . . . 26 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
IETF has defined ALTO services in [RFC7285] to provide guidance to IETF has defined ALTO services in [RFC7285] to provide guidance to
overlay applications, which have to select one or several hosts from overlay applications, which have to select one or several hosts from
a set of candidates that are able to provide a desired resource. a set of candidates that are able to provide a desired resource.
This guidance is based on parameters such as the topological This guidance is based on parameters such as the topological distance
distance, that affect performance of the data transmission between that affect performance of the data transmission between the hosts.
the hosts. The purpose of ALTO is to improve Quality of Experience The purpose of ALTO is to improve Quality of Experience (QoE) in the
(QoE) in the application while reducing resource consumption in the application while reducing resource consumption in the underlying
underlying network infrastructure. The ALTO protocol conveys a view network infrastructure. The ALTO protocol conveys a view of the
of the Internet called a Network Map and composed of Provider defined Internet called a Network Map, which is composed of provider-defined
locations spanning from subnets to several Autonomous Systems (AS). locations spanning from subnets to several Autonomous Systems (ASes).
ALTO may also convey the Provider determined Costs between Network ALTO may also convey the provider-determined costs between Network
Map locations or between groups of individual endpoints. Map locations or between groups of individual endpoints.
Current ALTO Cost Types provide values such as hopcount and Current ALTO cost types provide values such as "hopcount" and
administrative routing cost to reflect ISP routing preferences. administrative "routingcost" to reflect ISP routing preferences.
Recently, new use cases have extended the usage scope of ALTO to Recently, new use cases have extended the usage scope of ALTO to
Content Delivery Networks (CDN), Data Centers and applications that Content Delivery Networks (CDNs), data centers, and applications that
need additional information to select their endpoints or network need additional information to select their endpoints or network
locations. Thus a multitude of new Cost Types that better reflect locations. Thus, a multitude of new cost types that better reflect
the requirements of these applications are expected to be specified. the requirements of these applications are expected to be specified.
The ALTO protocol [RFC7285], which this document refers to as the The ALTO protocol [RFC7285], which this document refers to as the
base protocol, restricts ALTO Cost Maps and Endpoint Cost Services to base protocol, restricts ALTO cost maps and Endpoint Cost Services to
only one Cost Type per ALTO request. To retrieve information for only one cost type per ALTO request. To retrieve information for
several Cost Types, an ALTO Client must send several separate several cost types, an ALTO Client must send several separate
requests to the Server. requests to the Server.
It is far more efficient, in terms of Round Trip Time (RTT), traffic, 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 and processing load on the ALTO Client and Server, to get all costs
with a single query/response transaction. One Cost Map reporting on 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 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 each. This is valuable for both the storage of these maps and their
transmission. Additionally, for many emerging applications that need transmission. Additionally, for many emerging applications that need
information on several Cost Types, having them gathered in one map information on several cost types, having them gathered in one map
will save time. Another advantage is consistency: providing values will save time. Another advantage is consistency: providing values
for several Cost Types in one single batch is useful for ALTO Clients for several cost types in one single batch is useful for ALTO Clients
needing synchronized ALTO information updates. This document defines needing synchronized ALTO information updates. This document defines
how to retrieve multiple cost metrics in a single request for ALTO how to retrieve multiple cost metrics in a single request for ALTO
Filtered Cost Maps and Endpoint Cost Maps. To ensure compatibility filtered cost maps and endpoint cost maps. To ensure compatibility
with legacy ALTO Clients, only the Filtered Cost Map and Endpoint with legacy ALTO Clients, only the Filtered Cost Map and Endpoint
Cost Map services are extended to return Multi-Cost values. Cost Map Services are extended to return multi-cost values.
Along with multi-cost values queries, the filtering capabilities need Along with multi-cost values queries, the filtering capabilities need
to be extended to allow constraints on multiple metrics. The base to be extended to allow constraints on multiple metrics. The base
protocol allows an ALTO Client to provide optional constraint tests protocol allows an ALTO Client to provide optional constraint tests
for a Filtered Cost Map or the Endpoint Cost Service, where the for a Filtered Cost Map Service or the Endpoint Cost Service, where
constraint tests are limited to the AND-combination of comparison the constraint tests are limited to the AND combination of comparison
tests on the value of the (single) requested Cost Type. However, tests on the value of the (single) requested cost type. However,
applications that are sensitive to several metrics and struggle with applications that are sensitive to several metrics and struggle with
complicated network conditions may need to arbitrate between complicated network conditions may need to arbitrate between
conflicting objectives such as routing cost and network performance. conflicting objectives such as routing cost and network performance.
To this end, this document extends the base protocol with constraints To this end, this document extends the base protocol with constraints
that may test multiple metrics and may be combined with logical 'ORs' that may test multiple metrics and may be combined with logical 'ORs'
as well as logical 'ANDs'. This allows an application to make as well as logical 'ANDs'. This allows an application to make
requests such as: "select solutions with either (moderate "hopcount" requests such as: "select solutions with either (moderate "hopcount"
AND high "routingcost") OR (higher "hopcount" AND moderate AND high "routingcost") OR (higher "hopcount" AND moderate
"routingcost")". "routingcost")".
This document is organized as follows: Section 2 defines terminology This document is organized as follows. Section 2 defines terminology
used in this document. Section 3 gives a non-normative overview of used in this document. Section 3 gives a non-normative overview of
the multi-cost extensions, and Section 4 gives their formal the multi-cost extensions, and Section 4 gives the formal
definitions. Section 5 gives several complete examples. The definitions. Section 5 gives several complete examples. The
remaining sections describe the IANA and privacy considerations. remaining sections describe the IANA, privacy, and security
considerations.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119 [RFC2119]. "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, their natural language meaning When the words appear in lower case, they are to be interpreted with
is used. their natural language meanings.
2. Terminology 2. Terminology
o ALTO transaction: A request/response exchange between an ALTO o ALTO transaction: A request/response exchange between an ALTO
Client and an ALTO Server. Client and an ALTO Server.
o Client: This term refers to an ALTO client, when used with a o Client: When used with a capital "C", this term refers to an ALTO
capital "C". Client.
o Endpoint (EP): An endpoint is defined as in {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: This term refers to an ALTO server, when used with a o Endpoint (EP): An endpoint is defined as in Section 2.1 of
capital "S". [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.
References with curly brackets such as '{1.2.3}' are to sections in o Server: When used with a capital "S", this term refers to an ALTO
the ALTO protocol specification [RFC7285], to avoid overloading the Server.
document with citations of [RFC7285].
3. Overview Of Approach 3. Overview Of Approach
The following is a non-normative overview of the multi-cost The following is a non-normative overview of the multi-cost ALTO
extensions defined in this document. It assumes the reader is extensions defined in this document. It assumes the reader is
familiar with Cost Map resources in the ALTO Protocol ([RFC7285]). familiar with cost map resources in the ALTO protocol [RFC7285].
3.1. Multi-Cost Data Format 3.1. Multi-Cost Data Format
Formally, the cost entries in an ALTO Cost Map can be any type of Formally, the cost entries in an ALTO cost map can be any type of
JSON value (see the DstCosts object in {11.2.3.6}). However, that JSON value [RFC7159] (see the DstCosts object in Section 11.2.3.6 of
section also says that an implementation may assume costs are JSON [RFC7285]). However, that section also says that an implementation
numbers, unless the implementation is using an extension which may assume costs are JSON numbers, unless the implementation is using
signals a different data type. an extension that signals a different data type.
Therefore this document extends the definition of a Cost Map to allow Therefore, this document extends the definition of a cost map to
a cost to be an array of costs, one per metric, instead of just one allow a cost to be an array of costs, one per metric, instead of just
number. For example, here is a Cost Map with the "routingcost" and one number. For example, here is a cost map with the "routingcost"
"hopcount" metrics. Note that this is identical to a regular ALTO and "hopcount" metrics. Note that this is identical to a regular
Cost Map, except that the values are arrays instead of numbers. The ALTO cost map, except that the values are arrays instead of numbers.
multiple metrics are listed in member "multi-cost-types", indicating The multiple metrics are listed in member "multi-cost-types",
to the Client how to map values in the array to cost metrics. indicating to the Client how to map values in the array to cost
metrics.
{ {
"meta" : { "meta" : {
"dependent-vtags" : [ ... ], "dependent-vtags" : [ ... ],
"cost-type" : {}, "cost-type" : {},
"multi-cost-types" : [ "multi-cost-types" : [
{"cost-mode": "numerical", "cost-metric": "routingcost"}, {"cost-mode": "numerical", "cost-metric": "routingcost"},
{"cost-mode": "numerical", "cost-metric": "hopcount"} {"cost-mode": "numerical", "cost-metric": "hopcount"}
] ]
} }
"cost-map" : { "cost-map" : {
"PID1": { "PID1":[1,0], "PID2":[5,23], "PID3":[10,5] }, "PID1": { "PID1":[1,0], "PID2":[5,23], "PID3":[10,5] },
... ...
} }
} }
Note also the presence of member '"cost-type" : {}' to maintain Note also the presence of member '"cost-type" : {}' to maintain
backwards compatibility with [RFC7285]. backwards compatibility with [RFC7285].
3.2. Compatibility With Legacy ALTO Clients 3.2. Compatibility with Legacy ALTO Clients
This document does not define any new media types. Instead, as This document does not define any new media types. Instead, as
described below, it extends the specifications in the ALTO Server's described below, it extends the specifications in the ALTO Server's
Information Resource Directory (IRD) so that legacy Clients will not Information Resource Directory (IRD) so that legacy Clients will not
request array-valued Multi Cost Map resources. This relies on the request array-valued multi-cost map resources. This relies on the
requirement that ALTO Clients MUST ignore unknown fields ({8.3.7}). requirement that ALTO Clients MUST ignore unknown fields
(Section 8.3.7 of [RFC7285]).
3.3. Filtered Multi Cost Map Resources 3.3. Filtered Multi-Cost Map Resources
This document extends the Filtered Cost Map service to allow the same This document extends the Filtered Cost Map Service to allow the same
resource to return either a single-valued Cost Map, as defined in resource to return either a single-valued cost map, as defined in
[RFC7285], or an array-valued Multi Cost Map, as defined in this [RFC7285], or an array-valued multi-cost map, as defined in this
document. An extended Filtered Cost Map resource has a new document. An extended Filtered Cost Map resource has a new
capability, "max-cost-types". The value is the maximum number of capability, "max-cost-types". The value is the maximum number of
cost types this resource can return for one request. The existence cost types this resource can return for one request. The existence
of this capability means the resource understands the extensions in of this capability means the resource understands the extensions in
this document. this document.
For example, the following fragment from an IRD defines an extended For example, the following fragment from an IRD defines an extended
Filtered Cost Map resource: Filtered Cost Map resource:
"filtered-multicost-map" : { "filtered-multicost-map" : {
"uri" : "http://alto.example.com/multi/costmap/filtered", "uri" : "http://alto.example.com/multi/costmap/filtered",
"media-types" : [ "application/alto-costmap+json" ], "media-type" : "application/alto-costmap+json",
"accepts" : [ "application/alto-costmapfilter+json" ], "accepts" : "application/alto-costmapfilter+json",
"uses" : [ "my-default-network-map" ], "uses" : [ "my-default-network-map" ],
"capabilities" : { "capabilities" : {
"max-cost-types" : 2, "max-cost-types" : 2,
"cost-type-names" : [ "num-routingcost", "cost-type-names" : [ "num-routingcost",
"num-hopcount" ], "num-hopcount" ],
... ...
} }
A legacy ALTO Client will ignore the "max-cost-types" capability, and A legacy ALTO Client will ignore the "max-cost-types" capability and
will send a request with the input parameter "cost-type" describing will send a request with the input parameter "cost-type" describing
the desired cost metric, as defined in [RFC7285]. The ALTO Server the desired cost metric, as defined in [RFC7285]. The ALTO Server
will return a single-valued legacy Cost Map. will return a single-valued legacy cost map.
However, a multi-cost-aware ALTO Client will realize that this However, a multi-cost-aware ALTO Client will realize that this
resource supports the multi-cost extensions, and can send a POST resource supports the multi-cost extensions and can send a POST
request with the new input parameter "multi-cost-types", whose value request with the new input parameter "multi-cost-types", whose value
is an array of cost types. Because the request has the "multi-cost- is an array of cost types. Because the request has the "multi-cost-
types" parameter (rather than the "cost-type" parameter defined in types" parameter (rather than the "cost-type" parameter defined in
the base protocol), the Server realizes that the ALTO Client also the base protocol), the Server realizes that the ALTO Client also
supports the extensions in this document, and hence responds with a supports the extensions in this document and hence responds with a
Multi Cost Map, with the costs in the order listed in "multi-cost- multi-cost map with the costs in the order listed in "multi-cost-
types". types".
3.4. Endpoint Cost Service Resources 3.4. Endpoint Cost Service Resources
Section {4.1.4} of [RFC7285] specifies that "The Endpoint Cost Section 4.1.4 of [RFC7285] specifies that "The Endpoint Cost Service
Service allows an ALTO Server to return costs directly amongst allows an ALTO server to return costs directly amongst endpoints",
endpoints.", whereas the Filtered Cost Map Service returns costs whereas the Filtered Cost Map Service returns costs amongst Provider-
amongst PIDs. This document uses the technique described in defined Identifiers (PIDs). This document uses the technique
Section 3.3 to extend the Endpoint Cost Service to return array- described in Section 3.3 to extend the Endpoint Cost Service to
valued costs to ALTO Clients who also are aware of these extensions. return array-valued costs to ALTO Clients who also are aware of these
extensions.
3.5. Full Cost Map Resources 3.5. Full Cost Map Resources
Section {11.3.2.3} of [RFC7285] requires a Filtered Cost Map to Section 11.3.2.3 of [RFC7285] requires a filtered cost map to return
return the entire Cost Map if the ALTO Client omits the source and the entire cost map if the ALTO Client omits the source and
destination PIDs. Hence a Multi-Cost aware ALTO Client can use an destination PIDs. Hence, a multi-cost-aware ALTO Client can use an
extended Filtered Cost Map resource to get a full Multi Cost Map. 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 resources are GET-mode requests. The response for a
Full Cost Map conveying multiple cost types would include a "meta" full cost map conveying multiple cost types would include a "meta"
field that would itself include a "cost-type" field, that would list field that would itself include a "cost-type" field that would list
several values corresponding to the cost types of the cost map. A several values corresponding to the cost types of the cost map. A
legacy ALTO Client would not be able to understand this list. legacy ALTO Client would not be able to understand this list.
Neither would it be able to interpret the cost values array provided Neither would it be able to interpret the cost values array provided
by a Multi-Cost full maps. by a full multi-cost map.
3.6. Extended Constraint Tests 3.6. Extended Constraint Tests
[RFC7285] defines a simple constraint test capability for Filtered [RFC7285] defines a simple constraint test capability for Filtered
Cost Maps and Endpoint Cost Services. If a resource supports Cost Map and Endpoint Cost Services. If a resource supports
constraints, the Server restricts the response to costs that satisfy constraints, the Server restricts the response to costs that satisfy
a list of simple predicates provided by the ALTO Client. For a list of simple predicates provided by the ALTO Client. For
example, if the ALTO Client gives the constraints example, if the ALTO Client gives the following constraints:
"constraints": ["ge 10", "le 20"] "constraints": ["ge 10", "le 20"]
Then the Server only returns costs in the range [10,20]. then the Server only returns costs in the range [10,20].
To be useful with multi-cost requests, the constraint tests require To be useful with multi-cost requests, the constraint tests require
several extensions. several extensions.
3.6.1. Extended constraint predicates 3.6.1. Extended Constraint Predicates
First, because a multi-cost request involves more than one cost First, because a multi-cost request involves more than one cost
metric, the simple predicates must be extended to specify the metric metric, the simple predicates must be extended to specify the metric
to test. Therefore we extend the predicate syntax to "[##] op to test. Therefore, we extend the predicate syntax to "[##] op
value", where "##" is the index of a cost metric in this multi-cost value", where "##" is the index of a cost metric in this multi-cost
request. request.
3.6.2. Extended logical combination of predicates 3.6.2. Extended Logical Combination of Predicates
Second, once multiple cost metrics are involved, the "AND" of simple Second, once multiple cost metrics are involved, the "AND" of simple
predicates is no longer sufficient. To be useful, Clients must be predicates is no longer sufficient. To be useful, Clients must be
able to express "OR" tests. Hence we add a new field, "or- able to express "OR" tests. Hence, we add a new field,
constraints", to the Client request. The value is an array of arrays "or-constraints", to the Client request. The value is an array of
of simple predicates, and represents the OR of ANDs of those arrays of simple predicates and represents the OR of ANDs of those
predicates. predicates.
Thus, the following request tells the Server to limit its response to Thus, the following request tells the Server to limit its response to
cost points with "routingcost" <= 100 AND "hopcount" <= 2, OR else cost points with "routingcost" <= 100 AND "hopcount" <= 2, OR else
"routingcost" <= 10 AND "hopcount" <= 6: "routingcost" <= 10 AND "hopcount" <= 6:
{ {
"multi-cost-types": [ "multi-cost-types": [
{"cost-metric": "routingcost", "cost-mode": "numerical"}, {"cost-metric": "routingcost", "cost-mode": "numerical"},
{"cost-metric": "hopcount", "cost-mode": "numerical"} {"cost-metric": "hopcount", "cost-mode": "numerical"}
skipping to change at page 8, line 28 skipping to change at page 9, line 43
["[0] le 10", "[1] le 6"] ["[0] le 10", "[1] le 6"]
], ],
"pids": {...} "pids": {...}
} }
Note that a "constraints" parameter with the array of predicates [P1, Note that a "constraints" parameter with the array of predicates [P1,
P2, ...] is equivalent to an "or-constraints" parameter with one P2, ...] is equivalent to an "or-constraints" parameter with one
array of value [[P1, P2, ...]]. A Client is therefore allowed to array of value [[P1, P2, ...]]. A Client is therefore allowed to
express either "constraints" or "or-constraints" but not both. express either "constraints" or "or-constraints" but not both.
3.6.3. Testable Cost Types in constraints 3.6.3. Testable Cost Types in Constraints
Finally, a Client may want to test a cost type whose actual value is 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 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 may want the value of the cost metric "routingcost" for all PID pairs
that satisfy constraints on the metric "hopcount", without needing that satisfy constraints on the metric "hopcount", without needing
the actual value of "hopcount". the actual value of "hopcount".
To this end, we add a specific parameter named "testable-cost-types", To this end, we add a specific parameter named "testable-cost-types"
that does not contain the same cost types as parameter "multi-cost- that does not contain the same cost types as parameter "multi-cost-
types". The Client can express constraints only on cost types listed types". The Client can express constraints only on cost types listed
in "testable-cost-types". in "testable-cost-types".
For example, the following request tells the Server to return just For example, the following request tells the Server to return just
"routingcost" for those source and destination pairs for which "routingcost" for those source and destination pairs for which
"hopcount" is <= 6: "hopcount" is <= 6:
{ {
"multi-cost-types": [ "multi-cost-types": [
{"cost-metric": "routingcost", "cost-mode": "numerical"}, {"cost-metric": "routingcost", "cost-mode": "numerical"},
], ],
"testable-cost-types": [ "testable-cost-types": [
{"cost-metric": "hopcount", "cost-mode": "numerical"}, {"cost-metric": "hopcount", "cost-mode": "numerical"},
], ],
"constraints": ["[0] le 6"], "constraints": ["[0] le 6"],
"pids": {...} "pids": {...}
} }
3.6.4. Testable Cost Type Names in IRD capabilities 3.6.4. Testable Cost Type Names in IRD Capabilities
In [RFC7285], when a resource's capability "constraints" is true, the In [RFC7285], when a resource's capability "constraints" is true, the
Server accepts constraints on all the cost types listed in the "cost- Server accepts constraints on all the cost types listed in the "cost-
type-names" capability. However, some ALTO Servers may not be type-names" capability. However, some ALTO Servers may not be
willing to allow constraint tests on all available cost metrics. willing to allow constraint tests on all available cost metrics.
Therefore the Multi-Cost ALTO protocol extension defines the Therefore, the multi-cost ALTO protocol extension defines the
capability field "testable-cost-type-names". Like "cost-type-names", capability field "testable-cost-type-names". Like "cost-type-names",
it is an array of cost type names. If present, that resource only it is an array of cost type names. If present, that resource only
allows constraint tests on the cost types in that list. "testable- allows constraint tests on the cost types in that list. "testable-
cost-type-names" must be a subset of "cost-type-names". cost-type-names" must be a subset of "cost-type-names".
3.6.5. Legacy ALTO Client issues 3.6.5. Legacy ALTO Client Issues
While a multi-cost-aware Client will recognize the "testable-cost- While a multi-cost-aware Client will recognize the "testable-cost-
type-names" field, and will honor those restrictions, a legacy Client type-names" field and will honor those restrictions, a legacy Client
will not. Hence, when "constraints" has the value 'true', a legacy 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 Client may send a request with a constraint test on any of the cost
types listed in "cost-type-names". types listed in "cost-type-names".
To avoid that problem, the "testable-cost-type-names" and "cost- To avoid that problem, the "testable-cost-type-names" and "cost-
constraints" fields are mutually exclusive: a resource may define one constraints" fields are mutually exclusive: a resource may define one
or the other capability, but MUST NOT define both. Thus a resource or the other capability but MUST NOT define both. Thus, a resource
that does not allow constraint tests on all cost metrics will set that does not allow constraint tests on all cost metrics will set
"testable-cost-type-names" to the testable metrics, and will set "testable-cost-type-names" to the testable metrics and will set
"cost-constraints" to "false". A multi-cost-aware Client will "cost-constraints" to 'false'. A multi-cost-aware Client will
recognize the "testable-cost-type-names" field, and will realize that recognize the "testable-cost-type-names" field and will realize that
its existence means the resource does allow (limited) constraint its existence means the resource does allow (limited) constraint
tests, while a legacy Client will think that resource does not allow tests, while a legacy Client will think that resource does not allow
constraint tests at all. To allow legacy Clients to use constraint constraint tests at all. To allow legacy Clients to use constraint
tests, the ALTO Server can define an additional resource with "cost- tests, the ALTO Server can define an additional resource with "cost-
constraints" set to "true" and "cost-type-names" set to the metrics constraints" set to 'true' and "cost-type-names" set to the metrics
which can be tested. that can be tested.
In the IRD example below, the resource "filtered-cost-map-extended" In the IRD example below, the resource "filtered-cost-map-extended"
provides values for three metrics: "num-routingcost", "num-hopcount" provides values for three metrics: "num-routingcost", "num-hopcount",
and "num-bwscore". The capability "testable-cost-type-names" and "num-bwscore". The capability "testable-cost-type-names"
indicates that the Server only allows constraints on "routingcost" indicates that the Server only allows constraints on "routingcost"
and "hopcount". A multi-cost capable Client will see this and "hopcount". A multi-cost-capable Client will see this capability
capability, and will limit its constraint tests to those metrics. and will limit its constraint tests to those metrics. Because
Because capability "cost-constraints" is false (by default), a legacy capability "cost-constraints" is false (by default), a legacy Client
Client will not use constraint tests on this resource at all. will not use constraint tests on this resource at all.
The second resource, "filtered-multicost-map", is similar to the The second resource, "filtered-multicost-map", is similar to the
first, except that all the metrics it returns are testable. first, except that all the metrics it returns are testable.
Therefore it sets "cost-constraints" to "true", and does not set the Therefore, it sets "cost-constraints" to 'true' and does not set the
"testable-cost-type-names" field. A legacy Client that needs a "testable-cost-type-names" field. A legacy Client that needs a
constraint test will use this resource rather than the first. A constraint test will use this resource rather than the first. A
multi-cost-aware Client that does not need to retrieve the "num- multi-cost-aware Client that does not need to retrieve the
bwscore" metric may use either resource. "num-bwscore" metric may use either resource.
Note that if a multi-cost Server specifies a "filtered-cost-map- Note that if a multi-cost Server specifies a "filtered-cost-map-
extended", it will most likely not specify an "filtered-multicost- extended", it will most likely not specify an "filtered-multicost-
map" if the capabilities of the latter are covered by the map" if the capabilities of the latter are covered by the
capabilities of the former or unless the "filtered-multicost-map" capabilities of the former or unless the "filtered-multicost-map"
ressource is also intended for legacy Clients. resource is also intended for legacy Clients.
"filtered-cost-map-extended" : { "filtered-cost-map-extended" : {
"uri" : "http://alto.example.com/multi/extn/costmap/filtered", "uri" : "http://alto.example.com/multi/extn/costmap/filtered",
"media-types" : [ "application/alto-costmap+json" ], "media-type" : "application/alto-costmap+json",
"accepts" : [ "application/alto-costmapfilter+json" ], "accepts" : "application/alto-costmapfilter+json",
"uses" : [ "my-default-network-map" ], "uses" : [ "my-default-network-map" ],
"capabilities" : { "capabilities" : {
"max-cost-types" : 3, "max-cost-types" : 3,
"cost-type-names" : [ "num-routingcost", "cost-type-names" : [ "num-routingcost",
"num-hopcount", "num-hopcount",
"num-bwscore"], "num-bwscore"],
"testable-cost-type-names" : [ "num-routingcost", "testable-cost-type-names" : [ "num-routingcost",
"num-hopcount" ] "num-hopcount" ]
} }
}, },
"filtered-multicost-map" : { "filtered-multicost-map" : {
"uri" : "http://alto.example.com/multi/costmap/filtered", "uri" : "http://alto.example.com/multi/costmap/filtered",
"media-types" : [ "application/alto-costmap+json" ], "media-type" : "application/alto-costmap+json",
"accepts" : [ "application/alto-costmapfilter+json" ], "accepts" : "application/alto-costmapfilter+json",
"uses" : [ "my-default-network-map" ], "uses" : [ "my-default-network-map" ],
"capabilities" : { "capabilities" : {
"cost-constraints" : true, "cost-constraints" : true,
"max-cost-types" : 2, "max-cost-types" : 2,
"cost-type-names" : [ "num-routingcost", "cost-type-names" : [ "num-routingcost",
"num-hopcount"], "num-hopcount"],
} }
} }
4. Protocol Extensions for Multi-Cost ALTO Transactions 4. Protocol Extensions for Multi-Cost ALTO Transactions
This section formally specifies the extensions to [RFC7285] to This section formally specifies the extensions to [RFC7285] to
support Multi-Cost ALTO transactions. support multi-cost ALTO transactions.
This document uses the notation rules specified in {8.2}. In This document uses the notation rules specified in Section 8.2 of
particular, an optional field is enclosed by [ ]. In the [RFC7285]. In particular, an optional field is enclosed by [ ]. In
definitions, the JSON names of the fields are case sensitive. An 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 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 indicates the minimal number of values and n is the maximum. When
this document uses * for n, it means no upper bound. this document uses * for n, it means no upper bound.
4.1. Filtered Cost Map Extensions 4.1. Filtered Cost Map Extensions
This document extends Filtered Cost Maps, as defined in {11.3.2} of This document extends Filtered Cost Maps, as defined in
[RFC7285], by adding new input parameters and capabilities, and by Section 11.3.2 of [RFC7285], by adding new input parameters and
returning JSONArrays instead of JSONNumbers as the cost values. capabilities and by returning JSONArrays instead of JSONNumbers as
the cost values.
The media type (11.3.2.1}, HTTP method (11.3.2.2} and "uses" The media type, HTTP method, and "uses" specifications (described in
specifications (11.3.2.5} are unchanged. Sections 11.3.2.1, 11.3.2.2, and 11.3.2.5 of [RFC7285], respectively)
are unchanged.
4.1.1. Capabilities 4.1.1. Capabilities
The filtered cost map capabilities are extended with two new members: The filtered cost map capabilities are extended with two new members:
o max-cost-types, o max-cost-types
o testable-cost-type-names o testable-cost-type-names
The capability "max-cost-types" indicates whether this resource The capability "max-cost-types" indicates whether this resource
supports the Multi-Cost ALTO extensions, and the capability supports the multi-cost ALTO extensions, and the capability
"testable-cost-type-names" allows the resource to restrict constraint "testable-cost-type-names" allows the resource to restrict constraint
tests to a subset of the available cost types. With these two tests to a subset of the available cost types. With these two
additional members, the FilteredCostMapCapabilities object in additional members, the FilteredCostMapCapabilities object in
{11.3.2.4} is structured as follows: Section 11.3.2.4 of [RFC7285] is structured as follows:
object { object {
JSONString cost-type-names<1..*>; JSONString cost-type-names<1..*>;
[JSONBool cost-constraints;] [JSONBool cost-constraints;]
[JSONNumber max-cost-types;] [JSONNumber max-cost-types;]
[JSONString testable-cost-type-names<1..*>;] [JSONString testable-cost-type-names<1..*>;]
} FilteredCostMapCapabilities; } FilteredCostMapCapabilities;
cost-type-names: As defined in {11.3.2.4} of [RFC7285]. cost-type-names: As defined in Section 11.3.2.4 of [RFC7285].
cost-constraints: As defined in {11.3.2.4} of [RFC7285]. Thus if cost-constraints: As defined in Section 11.3.2.4 of [RFC7285].
"cost-constraints" is true, the resource MUST accept constraint Thus, if "cost-constraints" is true, the resource MUST accept
tests on any cost type in "cost-type-names". Note in addition constraint tests on any cost type in "cost-type-names". In
that if "cost-constraints" is "true", the "testable-cost-type- addition, note that if "cost-constraints" is true, the "testable-
names" capability MUST NOT be present cost-type-names" capability MUST NOT be present.
max-cost-types: If present with value N greater than 0, this max-cost-types: If present with value N greater than 0, this
resource understands the multi-cost extensions in this document, resource understands the multi-cost extensions in this document
and can return a Multi Cost Map with any combination of N or fewer 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 cost types in the "cost-type-names" list. If omitted, the default
value is 0. value is 0.
testable-cost-type-names: If present, the resource allows constraint testable-cost-type-names: If present, the resource allows constraint
tests, but only on the cost type names in this array. Each name 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". in "testable-cost-type-names" MUST also be in "cost-type-names".
If "testable-cost-type-names" is present, the "cost-constraints" If "testable-cost-type-names" is present, the "cost-constraints"
capability MUST NOT be true. capability MUST NOT be true.
As discussed in Section 3.6.4, this capability is useful when a As discussed in Section 3.6.4, this capability is useful when a
Server is unable or unwilling to implement constraint tests on all Server is unable or unwilling to implement constraint tests on all
cost types. As discussed in Section 3.6.5, "testable-cost-type- cost types. As discussed in Section 3.6.5, "testable-cost-type-
names" and "cost-constraints" are mutually exclusive to prevent names" and "cost-constraints" are mutually exclusive to prevent
legacy Clients from issuing constraint tests on untestable cost legacy Clients from issuing constraint tests on untestable cost
types. types.
4.1.2. Accept Input Parameters 4.1.2. Accept Input Parameters
The ReqFilteredCostMap object in {11.3.2.3} of [RFC7285] is extended The ReqFilteredCostMap object in Section 11.3.2.3 of [RFC7285] is
as follows: extended as follows:
object { object {
[CostType cost-type;] [CostType cost-type;]
[CostType multi-cost-types<1..*>;] [CostType multi-cost-types<1..*>;]
[CostType testable-cost-types<1..*>;] [CostType testable-cost-types<1..*>;]
[JSONString constraints<0..*>;] [JSONString constraints<0..*>;]
[JSONString or-constraints<1..*><1..*>;] [JSONString or-constraints<1..*><1..*>;]
[PIDFilter pids]; [PIDFilter pids];
} ReqFilteredCostMap; } ReqFilteredCostMap;
cost-type: As defined in {11.3.2.3} of [RFC7285], with the cost-type: As defined in Section 11.3.2.3 of [RFC7285], with the
additional requirement that the Client MUST specify either "cost- additional requirement that the Client MUST specify either "cost-
type" or "multi-cost-types", but MUST NOT specify both. Therefore type" or "multi-cost-types" but MUST NOT specify both. Therefore,
this field is made optional. When placing a single cost request this field is made optional. When placing a single cost request
as specified in [RFC7285], a Client MUST use "cost-type". as specified in [RFC7285], a Client MUST use "cost-type".
multi-cost-types: If present, the ALTO Server MUST return array- multi-cost-types: If present, the ALTO Server MUST return array-
valued costs for the cost types in this list. For each entry, the valued costs for the cost types in this list. For each entry, the
"cost-metric" and "cost-mode" fields MUST match one of the "cost-metric" and "cost-mode" fields MUST match one of the
supported cost types indicated in member "cost-type-names" of this supported cost types indicated in member "cost-type-names" of this
resource's "capabilities" field (Section 4.1.1). The Client MUST resource's "capabilities" field (Section 4.1.1). The Client MUST
NOT use this field unless this resource's "max-cost-types" NOT use this field unless this resource's "max-cost-types"
capability exists and has a value greater than 0. This field MUST capability exists and has a value greater than 0. This field MUST
NOT have more than "max-cost-types" cost types. The Client 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 either "cost-type" or "multi-cost-types" but MUST NOT
specify both. specify both.
Note that if "multi-cost-types" has one cost type, the values in Note that if "multi-cost-types" has one cost type, the values in
the cost map will be arrays with one value. the cost map will be arrays with one value.
testable-cost-types: A list of cost types used for extended testable-cost-types: A list of cost types used for extended
constraint tests, as described for the "constraints" and "or- constraint tests, as described for the "constraints" and
constraints" parameters. These cost types must either be a subset "or-constraints" parameters. These cost types must either be a
of the cost types in the resource's "testable-cost-type-names" subset of the cost types in the resource's
capability (Section 4.1.1), or else, if the resource's capability "testable-cost-type-names" capability (Section 4.1.1), or else, if
"cost-constraints" is true, a subset of the cost types in the the resource's capability "cost-constraints" is true, a subset of
resource's "cost-type-names" capability. the cost types in the resource's "cost-type-names" capability.
If "testable-cost-types" is omitted, it is assumed to have the If "testable-cost-types" is omitted, it is assumed to have the
cost types in "multi-cost-types" or "cost-type". cost types in "multi-cost-types" or "cost-type".
This feature is useful when a Client wants to test a 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 whose actual value is irrelevant, as long as it satisfies the
tests. For example, a Client may want the cost metric tests. For example, a Client may want the cost metric
"routingcost" for those PID pairs whose "hopcount" is less than "routingcost" for those PID pairs whose "hopcount" is less than
10. The exact hopcount does not matter. 10. The exact hop count does not matter.
constraints: If this resource's "max-cost-types" capability constraints: If this resource's "max-cost-types" capability
(Section 4.1.1) has the value 0 (or is not defined), this (Section 4.1.1) has the value 0 (or is not defined), this
parameter is as defined in {11.3.2.3} of [RFC7285]: an array of parameter is as defined in Section 11.3.2.3 of [RFC7285]: an array
constraint tests related to each other by a logical AND. In this of constraint tests related to each other by a logical AND. In
case it MUST NOT be specified unless the resource's "cost- this case, it MUST NOT be specified unless the resource's "cost-
constraints" capability is "true". constraints" capability is true.
If this resource's "max-cost-types" capability has a value greater If this resource's "max-cost-types" capability has a value greater
than 0, then this parameter is an array of extended constraint than 0, then this parameter is an array of extended constraint
predicates as defined below and related to each other by a logical predicates as defined below and related to each other by a logical
AND. In this case, it MAY be specified if the resource allows AND. In this case, it MAY be specified if the resource allows
constraint tests (the resource's "cost-constraints" capability is constraint tests (the resource's "cost-constraints" capability is
"true" or its "testable-cost-type-names" capability is not empty). true, or its "testable-cost-type-names" capability is not empty).
This parameter MUST NOT be specified if the "or-constraints" This parameter MUST NOT be specified if the "or-constraints"
parameter is specified. parameter is specified.
An extended constraint predicate consists of two or three entities An extended constraint predicate consists of two or three entities
separated by white space: (1) an optional cost type index, of the separated by white space: (1) an optional cost type index of the
form "[#]", with default value "[0]", (2) a required operator, and form "[#]" with default value "[0]", (2) a required operator, and
(3) a required target value. The operator and target value are as (3) a required target value. The operator and target value are as
defined in {11.3.2.3} of [RFC7285]. The cost type index, i, 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" specifies the cost type to test. If the "testable-cost-type"
parameter is present, the test applies to the i'th cost type in parameter is present, the test applies to the i'th cost type in
"testable-cost-types", starting with index 0. Otherwise if the "testable-cost-types", starting with index 0. Otherwise, if the
"multi-cost-types" parameter is present, the test applies to the "multi-cost-types" parameter is present, the test applies to the
i'th cost type in that array. If neither parameters are present, 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 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 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 is selected, it MUST be in the resource's "testable-cost-
type-names" capability, or, if not present, in the "cost-type- type-names" capability or, if not present, in the "cost-type-
names" capability. names" capability.
As an example, suppose "multi-cost-types" has the single element As an example, suppose "multi-cost-types" has the single element
"routingcost", "testable-cost-types" has the single element "routingcost", "testable-cost-types" has the single element
"hopcount", and "constraints" has the single element "[0] le 5". "hopcount", and "constraints" has the single element "[0] le 5".
This is equivalent to the database query "SELECT and provide This is equivalent to the database query "SELECT and provide
routingcost WHERE hopcount <= 5". routingcost WHERE hopcount <= 5".
Note that the index is optional, so a constraint test as defined Note that the index is optional, so a constraint test as defined
in {11.3.2.3}, such as "le 10", is equivalent to "[0] le 10". in Section 11.3.2.3 of [RFC7285], such as "le 10", is equivalent
Thus legacy constraint tests are also legal extended constraint to "[0] le 10". Thus, legacy constraint tests are also legal
tests. extended constraint tests.
Note that a "constraints" parameter with the array of extended Note that a "constraints" parameter with the array of extended
predicates [P1, P2, ...] is equivalent to an "or-constraints" predicates [P1, P2, ...] is equivalent to an "or-constraints"
parameter as defined below, with the value [[P1, P2, ...]]. parameter as defined below with the value [[P1, P2, ...]].
or-constraints: A JSONArray of JSONArrays of JSONStrings, where each or-constraints: A JSONArray of JSONArrays of JSONStrings, where each
string is an extended constraint predicate as defined above. The string is an extended constraint predicate as defined above. The
"or-constraint" tests are interpreted as the logical OR of ANDs of "or-constraint" tests are interpreted as the logical OR of ANDs of
predicates. That is, the ALTO Server should return a cost point predicates. That is, the ALTO Server should return a cost point
only if it satisfies all constraints in any one of the sub-arrays. only if it satisfies all constraints in any one of the sub-arrays.
This parameter MAY be specified if this resource's "max-cost- This parameter MAY be specified if this resource's "max-cost-
types" capability is defined with a value greater than 0 types" capability is defined with a value greater than 0
(Section 4.1.1), and if the resource allows constraint tests (the (Section 4.1.1) and if the resource allows constraint tests (the
resource's "cost-constraints" capability is "true" or its resource's "cost-constraints" capability is true, or its
"testable-cost-type-names" capability is not empty). Otherwise "testable-cost-type-names" capability is not empty). Otherwise,
this parameter MUST NOT be specified. this parameter MUST NOT be specified.
This parameter MUST NOT be specified if the "constraints" This parameter MUST NOT be specified if the "constraints"
parameter is specified. parameter is specified.
This parameter MUST NOT contain any empty array of AND predicates. This parameter MUST NOT contain any empty array of AND predicates.
An empty array would be equivalent to a constraint that is always An empty array would be equivalent to a constraint that is always
"true". An OR combination including such a constraint would be true. An OR combination including such a constraint would be
always "true" and thus useless. always true and thus useless.
As an example, suppose "multi-cost-types" has the two elements As an example, suppose "multi-cost-types" has the two elements
"routingcost" and "bandwidthscore", and "testable-cost-types" has "routingcost" and "bandwidthscore", "testable-cost-types" has the
the two elements "routingcost" and "hopcount", and "or- two elements "routingcost" and "hopcount", and "or-constraints"
constraints" has the two elements ["[0] le 100", "[1] le 2"] and has the two elements ["[0] le 100", "[1] le 2"] and ["[0] le 10",
["[0] le 10", "[1] le 6"]. This is equivalent to the words: "[1] le 6"]. This is equivalent to the words: "SELECT and provide
"SELECT and provide routingcost and bandwidthscore WHERE routingcost and bandwidthscore WHERE ("routingcost" <= 100 AND
("routingcost" <= 100 AND "hopcount" <= 2) OR ("routingcost" <= 10 "hopcount" <= 2) OR ("routingcost" <= 10 AND "hopcount" <= 6)".
AND "hopcount" <= 6)".
Note that if the "max-cost-types" capability has a value greater Note that if the "max-cost-types" capability has a value greater
than 0, a Client MAY use the "or-constraints" parameter together than 0, a Client MAY use the "or-constraints" parameter together
with the "cost-type" parameter. That is, if the Client and Server with the "cost-type" parameter. That is, if the Client and Server
are both aware of the extensions in this document, a Client MAY are both aware of the extensions in this document, a Client MAY
use an "OR" test for a single-valued cost request. use an "OR" test for a single-valued cost request.
pids: As defined in {11.3.2.3} of [RFC7285]. pids: As defined in Section 11.3.2.3 of [RFC7285].
4.1.3. Response 4.1.3. Response
If the Client specifies the "cost-type" input parameter, the response If the Client specifies the "cost-type" input parameter, the response
is exactly as defined in {11.2.3.6} of [RFC7285]. If the Client is exactly as defined in Section 11.2.3.6 of [RFC7285]. If the
provides the "multi-cost-types" instead, then the response is changed Client provides the "multi-cost-types" instead, then the response is
as follows: changed as follows:
o In "meta", the value of field "cost-type" will be ignored by the 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 receiver and set to {}. Instead, the field "multi-cost-types" is
added with the same value as the "multi-cost-types" input added with the same value as the "multi-cost-types" input
parameter. parameter.
o The costs are JSONArrays, instead of JSONNumbers. All arrays have o The costs are JSONArrays instead of JSONNumbers. All arrays have
the same cardinality as the "multi-cost-types" input parameter, the same cardinality as the "multi-cost-types" input parameter and
and contain the cost type values in that order. If a cost type is contain the cost type values in that order. If a cost type is not
not available for a particular source and destination, the ALTO available for a particular source and destination, the ALTO Server
Server MUST use the JSON "null" value for that array element. If MUST use the JSON "null" value for that array element. If none of
none of the cost types are available for a particular source and the cost types are available for a particular source and
destination, the ALTO Server MAY omit the entry for that source destination, the ALTO Server MAY omit the entry for that source
and destination. and destination.
4.2. Endpoint Cost Service Extensions 4.2. Endpoint Cost Service Extensions
This document extends the Endpoint Cost Service, as defined in This document extends the Endpoint Cost Service, as defined in
{11.5.1} of [RFC7285], by adding new input parameters and Section 11.5.1 of [RFC7285], by adding new input parameters and
capabilities, and by returning JSONArrays instead of JSONNumbers as capabilities and by returning JSONArrays instead of JSONNumbers as
the cost values. the cost values.
The media type {11.5.1.1}, HTTP method {11.5.1.2} and "uses" The media type, HTTP method, and "uses" specifications (described in
specifications {11.5.1.5} are unchanged. Sections 11.5.1.1, 11.5.1.2, and 11.5.1.5 of [RFC7285], respectively)
are unchanged.
4.2.1. Capabilities 4.2.1. Capabilities
The extensions to the Endpoint Cost Service capabilities are The extensions to the Endpoint Cost Service capabilities are
identical to the extensions to the Filtered Cost Map (see identical to the extensions to the Filtered Cost Map (see
Section 4.1.1). Section 4.1.1).
4.2.2. Accept Input Parameters 4.2.2. Accept Input Parameters
The ReqEndpointCostMap object in {11.5.1.3} of [RFC7285] is extended The ReqEndpointCostMap object in Section 11.5.1.3 of [RFC7285] is
as follows: extended as follows:
object { object {
[CostType cost-type;] [CostType cost-type;]
[CostType multi-cost-types<1..*>;] [CostType multi-cost-types<1..*>;]
[CostType testable-cost-types<1..*>;] [CostType testable-cost-types<1..*>;]
[JSONString constraints<0..*>;] [JSONString constraints<0..*>;]
[JSONString or-constraints<1..*><1..*>;] [JSONString or-constraints<1..*><1..*>;]
EndpointFilter endpoints; EndpointFilter endpoints;
} ReqEndpointCostMap; } ReqEndpointCostMap;
cost-type: As defined in {11.5.1.3} of [RFC7285], with the cost-type: As defined in Section 11.5.1.3 of [RFC7285], with the
additional requirement that the Client MUST specify either "cost- additional requirement that the Client MUST specify either "cost-
type" or "multi-cost-types", but MUST NOT specify both. type" or "multi-cost-types" but MUST NOT specify both.
multi-cost-types: If present, the ALTO Server MUST return array- multi-cost-types: If present, the ALTO Server MUST return array-
valued costs for the cost types in this list. For each entry, the valued costs for the cost types in this list. For each entry, the
"cost-metric" and "cost-mode" fields MUST match one of the "cost-metric" and "cost-mode" fields MUST match one of the
supported cost types indicated in this resource's "capabilities" supported cost types indicated in this resource's "capabilities"
field (Section 4.2.1). The Client MUST NOT use this field unless 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 this resource's "max-cost-types" capability exists and has a value
greater than 0. This field MUST NOT have more than "max-cost- greater than 0. This field MUST NOT have more than "max-cost-
types" cost types. The Client MUST specify either "cost-type" or types" cost types. The Client MUST specify either "cost-type" or
"multi-cost-types", but MUST NOT specify both. "multi-cost-types" but MUST NOT specify both.
Note that if "multi-cost-types" has one cost type, the values in Note that if "multi-cost-types" has one cost type, the values in
the cost map will be arrays with one value. the cost map will be arrays with one value.
testable-cost-types, constraints, or-constraints: Defined testable-cost-types, constraints, or-constraints: Defined
equivalently to the corresponding input parameters for an extended equivalently to the corresponding input parameters for an extended
Filtered Cost Map (Section 4.1.2). filtered cost map (Section 4.1.2).
endpoints: As defined in {11.5.1.3} of [RFC7285]. endpoints: As defined in Section 11.5.1.3 of [RFC7285].
4.2.3. Response 4.2.3. Response
The extensions to the Endpoint Cost Service response are similar to The extensions to the Endpoint Cost Service response are similar to
the extensions to the Filtered Cost Map response (Section 4.1.3). the extensions to the Filtered Cost Map response (Section 4.1.3).
Specifically, if the Client specifies the "cost-type" input Specifically, if the Client specifies the "cost-type" input
parameter, the response is exactly as defined in {11.5.1.6} of parameter, the response is exactly as defined in Section 11.5.1.6 of
[RFC7285]. If the Client provides the "multi-cost-types" instead, [RFC7285]. If the Client provides the "multi-cost-types" instead,
then the response is changed as follows: then the response is changed as follows:
o In "meta", the value of field "cost-type" will be ignored by the 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 receiver and set to {}. Instead, the field "multi-cost-types" is
added with the same value as the "multi-cost-types" input added with the same value as the "multi-cost-types" input
parameter. parameter.
o The costs are JSONArrays, instead of JSONNumbers. All arrays have o The costs are JSONArrays instead of JSONNumbers. All arrays have
the same cardinality as the "multi-cost-types" input parameter, the same cardinality as the "multi-cost-types" input parameter and
and contain the cost type values in that order. If a cost type is contain the cost type values in that order. If a cost type is not
not available for a particular source and destination, the ALTO available for a particular source and destination, the ALTO Server
Server MUST use the JSON "null" value for that array element. If MUST use the JSON "null" value for that array element. If none of
none of the cost types are available for a particular source and the cost types are available for a particular source and
destination, the ALTO Server MAY omit the entry for that source destination, the ALTO Server MAY omit the entry for that source
and destination. and destination.
5. Examples 5. Examples
This section provides examples of Multi-Cost ALTO transactions. It This section provides examples of multi-cost ALTO transactions. It
uses cost metrics, in addition to the mandatory legacy 'routingcost', uses cost metrics, in addition to the mandatory legacy "routingcost",
that are deliberately irrelevant and not registered at the IANA. that are deliberately irrelevant and not registered with IANA.
5.1. Information Resource Directory 5.1. Information Resource Directory
The following is an example of an ALTO Server's Information Resource The following is an example of an ALTO Server's Information Resource
Directory. In addition to Network and Cost Map resources, it defines Directory. In addition to network and cost map resources, it defines
two Filtered Cost Map and an Endpoint Cost Service, which all two Filtered Cost Maps and an Endpoint Cost Service, which all
understand the multi-cost extensions. understand the multi-cost extensions.
GET /directory HTTP/1.1 GET /directory HTTP/1.1
Host: alto.example.com Host: alto.example.com
Accept: application/alto-directory+json,application/alto-error+json Accept: application/alto-directory+json,application/alto-error+json
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Length: 2704 Content-Length: 2704
Content-Type: application/alto-directory+json Content-Type: application/alto-directory+json
{ {
"meta" : { "meta" : {
"default-alto-network-map" : "my-default-network-map", "default-alto-network-map" : "my-default-network-map",
"cost-types" : { "cost-types" : {
"num-routing" : { "num-routing" : {
"cost-mode" : "numerical", "cost-mode" : "numerical",
"cost-metric" : "routingcost" "cost-metric" : "routingcost"
}, },
"num-shoesize" : { "num-shoesize" : {
"cost-mode" : "numerical", "cost-mode" : "numerical",
skipping to change at page 18, line 26 skipping to change at page 20, line 29
} }
} }
}, },
"resources" : { "resources" : {
"my-default-network-map" : { "my-default-network-map" : {
"uri" : "http://alto.example.com/networkmap", "uri" : "http://alto.example.com/networkmap",
"media-type" : "application/alto-networkmap+json" "media-type" : "application/alto-networkmap+json"
}, },
"numerical-routing-cost-map" : { "numerical-routing-cost-map" : {
"uri" : "http://alto.example.com/costmap/num-routing", "uri" : "http://alto.example.com/costmap/num-routing",
"media-types" : [ "application/alto-costmap+json" ], "media-type" : "application/alto-costmap+json",
"uses" : [ "my-default-network-map" ], "uses" : [ "my-default-network-map" ],
"capabilities" : { "capabilities" : {
"cost-type-names" : [ "num-routing" ] "cost-type-names" : [ "num-routing" ]
} }
}, },
"numerical-shoesize-cost-map" : { "numerical-shoesize-cost-map" : {
"uri" : "http://alto.example.com/costmap/num-shoesize", "uri" : "http://alto.example.com/costmap/num-shoesize",
"media-types" : [ "application/alto-costmap+json" ], "media-type" : "application/alto-costmap+json",
"uses" : [ "my-default-network-map" ], "uses" : [ "my-default-network-map" ],
"capabilities" : { "capabilities" : {
"cost-type-names" : [ "num-shoesize" ] "cost-type-names" : [ "num-shoesize" ]
} }
}, },
"filtered-multicost-map" : { "filtered-multicost-map" : {
"uri" : "http://alto.example.com/multi/costmap/filtered", "uri" : "http://alto.example.com/multi/costmap/filtered",
"media-types" : [ "application/alto-costmap+json" ], "media-type" : "application/alto-costmap+json",
"accepts" : [ "application/alto-costmapfilter+json" ], "accepts" : "application/alto-costmapfilter+json",
"uses" : [ "my-default-network-map" ], "uses" : [ "my-default-network-map" ],
"capabilities" : { "capabilities" : {
"cost-constraints" : true, "cost-constraints" : true,
"max-cost-types" : 2, "max-cost-types" : 2,
"cost-type-names" : [ "num-routingcost", "cost-type-names" : [ "num-routingcost",
"num-shoesize" ] "num-shoesize" ]
} }
}, },
"filtered-cost-map-extended" : { "filtered-cost-map-extended" : {
"uri" : "http://alto.example.com/multi/extn/costmap/filtered", "uri" : "http://alto.example.com/multi/extn/costmap/filtered",
"media-types" : [ "application/alto-costmap+json" ], "media-type" : "application/alto-costmap+json",
"accepts" : [ "application/alto-costmapfilter+json" ], "accepts" : "application/alto-costmapfilter+json",
"uses" : [ "my-default-network-map" ], "uses" : [ "my-default-network-map" ],
"capabilities" : { "capabilities" : {
"max-cost-types" : 3, "max-cost-types" : 3,
"cost-type-names" : [ "num-routingcost", "cost-type-names" : [ "num-routingcost",
"num-shoesize", "num-shoesize",
"num-scenery"], "num-scenery"],
"testable-cost-type-names" : [ "num-routingcost", "testable-cost-type-names" : [ "num-routingcost",
"num-shoesize" ] "num-shoesize" ]
} }
}, },
"endpoint-multicost-map" : { "endpoint-multicost-map" : {
"uri" : "http://alto.example.com/multi/endpointcost/lookup", "uri" : "http://alto.example.com/multi/endpointcost/lookup",
"media-types" : [ "application/alto-endpointcost+json" ], "media-type" : "application/alto-endpointcost+json",
"accepts" : [ "application/alto-endpointcostparams+json" ], "accepts" : "application/alto-endpointcostparams+json",
"uses" : [ "my-default-network-map" ], "uses" : [ "my-default-network-map" ],
"capabilities" : { "capabilities" : {
"cost-constraints" : true, "cost-constraints" : true,
"max-cost-types" : 2, "max-cost-types" : 2,
"cost-type-names" : [ "num-routingcost", "cost-type-names" : [ "num-routingcost",
"num-shoesize" ] "num-shoesize" ]
} }
} }
} }
} }
5.2. Multi-Cost Filtered Cost Map: Example #1 5.2. Multi-Cost Filtered Cost Map: Example #1
This example illustrates a simple multi-cost ALTO transaction. The This example illustrates a simple multi-cost ALTO transaction. The
ALTO Server provides two Cost Types, "routingcost" and "shoesize", ALTO Server provides two cost types, "routingcost" and "shoesize",
both in "numerical" mode. The Client wants the entire Multi-Cost both in "numerical" mode. The Client wants the entire multi-cost
Map. The Server does not know the value of "routingcost" between map. The Server does not know the value of "routingcost" between
PID2 and PID3, and hence returns the value 'null' for "routingcost" PID2 and PID3 and hence returns the value 'null' for "routingcost"
between PID2 and PID3. between PID2 and PID3.
POST /multi/costmap/filtered" HTTP/1.1 POST /multi/costmap/filtered" HTTP/1.1
Host: alto.example.com Host: alto.example.com
Accept: application/alto-costmap+json,application/alto-error+json Accept: application/alto-costmap+json,application/alto-error+json
Content-Type: application/alto-costmapfilter+json Content-Type: application/alto-costmapfilter+json
Content-Length: 206 Content-Length: 206
{ {
"multi-cost-types": [ "multi-cost-types": [
skipping to change at page 20, line 49 skipping to change at page 23, line 8
"cost-map" : { "cost-map" : {
"PID1": { "PID1":[1,0], "PID2":[4,3], "PID3":[10,2] }, "PID1": { "PID1":[1,0], "PID2":[4,3], "PID3":[10,2] },
"PID2": { "PID1":[15,5], "PID2":[1,0], "PID3":[null,9] }, "PID2": { "PID1":[15,5], "PID2":[1,0], "PID3":[null,9] },
"PID3": { "PID1":[20,12], "PID2":[null,1], "PID3":[1,0] } "PID3": { "PID1":[20,12], "PID2":[null,1], "PID3":[1,0] }
} }
} }
5.3. Multi-Cost Filtered Cost Map: Example #2 5.3. Multi-Cost Filtered Cost Map: Example #2
This example uses constraints to restrict the returned source/ This example uses constraints to restrict the returned source/
destination PID pairs to those with "routingcost" between 5 and 10, destination PID pairs to those with "routingcost" between 5 and 10 or
or "shoesize" equal to 0. "shoesize" equal to 0.
POST /multi/costmap/filtered HTTP/1.1 POST /multi/costmap/filtered HTTP/1.1
Host: alto.example.com Host: alto.example.com
Accept: application/alto-costmap+json,application/alto-error+json Accept: application/alto-costmap+json,application/alto-error+json
Content-Type: application/alto-costmapfilter+json Content-Type: application/alto-costmapfilter+json
Content-Length: 333 Content-Length: 333
{ {
"multi-cost-types" : [ "multi-cost-types" : [
{"cost-mode": "numerical", "cost-metric": "routingcost"}, {"cost-mode": "numerical", "cost-metric": "routingcost"},
skipping to change at page 22, line 8 skipping to change at page 24, line 8
} }
"cost-map" : { "cost-map" : {
"PID1": { "PID1": [1,0], "PID3": [10,5] }, "PID1": { "PID1": [1,0], "PID3": [10,5] },
"PID2": { "PID2": [1,0] } "PID2": { "PID2": [1,0] }
} }
} }
5.4. Multi-Cost Filtered Cost Map: Example #3 5.4. Multi-Cost Filtered Cost Map: Example #3
This example uses extended constraints to limit the response to cost This example uses extended constraints to limit the response to cost
points with ("routingcost" <= 10 and "shoesize" <= 2), or else points with ("routingcost" <= 10 AND "shoesize" <= 2), OR else
("routingcost" <= 3 and "shoesize" <= 6). Unlike the previous ("routingcost" <= 3 AND "shoesize" <= 6). Unlike the previous
example, the Client is only interested in the "routingcost" cost example, the Client is only interested in the "routingcost" cost type
type, and uses the "cost-type" parameter instead of "multi-cost- and uses the "cost-type" parameter instead of "multi-cost-types" to
types" to tell the Server to return scalar costs instead of array tell the Server to return scalar costs instead of array costs.
costs.
In this example, "[0]" means the constraint applies to "routingcost" In this example, "[0]" means the constraint applies to "routingcost"
because that is the first cost type in the "testable-cost-types" because that is the first cost type in the "testable-cost-types"
parameter. (If "testable-cost-types" is omitted, it is assumed to be 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 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 refer to cost types aims at minimizing the length of the expression
of constraints, especially for those combining several OR and AND of constraints, especially for those combining several OR and AND
expressions. It was also the shortest path from the constraints expressions. It was also the shortest path from the constraints
design in [RFC7285]. design in [RFC7285].
skipping to change at page 23, line 29 skipping to change at page 25, line 29
"cost-map" : { "cost-map" : {
"PID1": { "PID1": 1, "PID3": 10 }, "PID1": { "PID1": 1, "PID3": 10 },
"PID2": { "PID2": 1 }, "PID2": { "PID2": 1 },
"PID3": { "PID3": 1 } "PID3": { "PID3": 1 }
} }
} }
5.5. Multi-Cost Filtered Cost Map: Example #4 5.5. Multi-Cost Filtered Cost Map: Example #4
This example uses extended constraints to limit the response to cost This example uses extended constraints to limit the response to cost
points with ("routingcost" <= 10 and "shoesize" <= 2), or else points with ("routingcost" <= 10 AND "shoesize" <= 2), OR else
("routingcost" <= 3 and "shoesize" <= 6). In this example, the ("routingcost" <= 3 AND "shoesize" <= 6). In this example, the
Client is interested in the "routingcost" and "sceneryrate" cost Client is interested in the "routingcost" and "sceneryrate" cost
metrics, but not in the "shoesize" metric: metrics but not in the "shoesize" metric:
POST /multi/extn/costmap/filtered HTTP/1.1 POST /multi/extn/costmap/filtered HTTP/1.1
Host: alto.example.com Host: alto.example.com
Accept: application/alto-costmap+json,application/alto-error+json Accept: application/alto-costmap+json,application/alto-error+json
Content-Type: application/alto-costmapfilter+json Content-Type: application/alto-costmapfilter+json
Content-Length: 461 Content-Length: 461
{ {
"multi-cost-types" : [ "multi-cost-types" : [
{"cost-mode": "numerical", "cost-metric": "routingcost"}, {"cost-mode": "numerical", "cost-metric": "routingcost"},
skipping to change at page 24, line 41 skipping to change at page 26, line 42
"PID1": { "PID1": [1,16] "PID3": [10,19] }, "PID1": { "PID1": [1,16] "PID3": [10,19] },
"PID2": { "PID2": [1,8] }, "PID2": { "PID2": [1,8] },
"PID3": { "PID3": [1,19] } "PID3": { "PID3": [1,19] }
} }
} }
5.6. Endpoint Cost Service 5.6. Endpoint Cost Service
This example uses the Endpoint Cost Service to retrieve the This example uses the Endpoint Cost Service to retrieve the
"routingcost" and "shoesize" for selected endpoints, limiting the "routingcost" and "shoesize" for selected endpoints, limiting the
response to costs with either low shoesize and reasonable routingcost response to costs with either low "shoesize" and reasonable
(shoesize <= 2 and routingcost <= 10), or else low routingcost and "routingcost" ("shoesize" <= 2 AND "routingcost" <= 10), OR else low
reasonable shoesize (routingcost <= 3 and shoesize <= 6). "routingcost" and reasonable "shoesize" ("routingcost" <= 3 AND
"shoesize" <= 6).
POST /multi/endpointcost/lookup HTTP/1.1 POST /multi/endpointcost/lookup HTTP/1.1
Host: alto.example.com Host: alto.example.com
Accept: application/alto-endpointcost+json, Accept: application/alto-endpointcost+json,
application/alto-error+json application/alto-error+json
Content-Type: application/alto-endpoincostparams+json Content-Type: application/alto-endpoincostparams+json
Content-Length: 455 Content-Length: 455
{ {
"multi-cost-types" : [ "multi-cost-types" : [
{"cost-mode": "numerical", "cost-metric": "routingcost"}, {"cost-mode": "numerical", "cost-metric": "routingcost"},
{"cost-mode": "numerical", "cost-metric": "shoesize"} {"cost-mode": "numerical", "cost-metric": "shoesize"}
], ],
"or-constraints": [ "or-constraints": [
["[0] le 10", "[1] le 2"], ["[0] le 10", "[1] le 2"],
["[0] le 3", "[1] le 6"] ["[0] le 3", "[1] le 6"]
], ],
"endpoints" : { "endpoints" : {
skipping to change at page 26, line 5 skipping to change at page 28, line 10
"ipv6:2001:db8::10": [10, 2] "ipv6:2001:db8::10": [10, 2]
} }
} }
} }
6. IANA Considerations 6. IANA Considerations
This document does not define any new media types or introduce any This document does not define any new media types or introduce any
new IANA considerations. new IANA considerations.
7. Privacy And Security Considerations 7. Privacy and Security Considerations
This document does not introduce any privacy or security issues not This document does not introduce any privacy or security issues not
already present in the ALTO protocol. already present in the ALTO protocol.
The Multi-Cost optimization even tends to reduce the on the wire data The multi-cost optimization even tends to reduce the on-the-wire data
exchange volume, compared to multiple single cost ALTO transactions. exchange volume compared to multiple single cost ALTO transactions.
Likewise, the risk related to massive Multi-Cost requests is Likewise, the risk related to massive multi-cost requests is
moderated by the fact that Multi-Cost constraints additionally filter moderated by the fact that multi-cost constraints additionally filter
ALTO Server responses and thus reduce their volume. ALTO Server responses and thus reduce their volume.
Note that, because queries for multiple metrics represent a stronger Note that, because queries for multiple metrics represent a stronger
fingerprinting signal than queries for a single metric, fingerprinting signal than queries for a single metric,
implementations of this protocol may leak more information about the implementations of this protocol may leak more information about the
ALTO client than would occur with a succession of individual queries. ALTO Client than would occur with a succession of individual queries.
Though, in many cases it would already be possible to link those Though, in many cases, it would already be possible to link those
queries by using the source IP address or other existing information. queries by using the source IP address or other existing information.
8. Acknowledgements 8. References
The authors would like to thank Richard Alimi, Fred Baker, Dhruv
Dhodi, Vijay Gurbani, Dave Mac Dysan, Young Lee, Richard Yang, for
fruitful discussions and feedback on this document and previous
versions. Gao Kai, Hans Seidel, Richard Yang, Qiao Xiang and Wang
Xin provided substantial review feedback and suggestions to the
protocol design.
9. References
9.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC7285] Almi, R., Penno, R., Yang, Y., Kiesel, S., Previdi, S., [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S.,
Roome, W., Shalunov, S., and R. Woundy, "Application-Layer Previdi, S., Roome, W., Shalunov, S., and R. Woundy,
Traffic Optimization (ALTO) Protocol", RFC 7285, September "Application-Layer Traffic Optimization (ALTO) Protocol",
2014. RFC 7285, DOI 10.17487/RFC7285, September 2014,
<https://www.rfc-editor.org/info/rfc7285>.
9.2. Informative References [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>.
[RFC5693] "Application Layer Traffic Optimization (ALTO) Problem 8.2. Informative References
Statement", October 2009.
[RFC6708] "Application-Layer Traffic Optimization (ALTO) [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Requirements", February 2012. Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
2014, <https://www.rfc-editor.org/info/rfc7159>.
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 Authors' Addresses
Sabine Randriamasy Sabine Randriamasy
Nokia Bell Labs Nokia Bell Labs
Route de Villejust Route de Villejust
NOZAY 91460 Nozay 91460
FRANCE France
Email: Sabine.Randriamasy@nokia-bell-labs.com Email: Sabine.Randriamasy@nokia-bell-labs.com
Wendy Roome Wendy Roome
Nokia Bell Labs Nokia Bell Labs
124 Burlington Rd 124 Burlington Rd
Murray Hill, NJ 07974 Murray Hill, NJ 07974
USA United States of America
Email: ietf@wdroome.com Email: ietf@wdroome.com
Nico Schwan Nico Schwan
Thales Deutschland Thales Deutschland
Lorenzstrasse 10 Lorenzstrasse 10
Stuttgart 70435 Stuttgart 70435
Germany Germany
Email: nico.schwan@thalesgroup.com Email: nico.schwan@thalesgroup.com
 End of changes. 142 change blocks. 
337 lines changed or deleted 341 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/