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
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)
多成本应用层流量优化（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.
RFC 7285中指定的应用层流量优化（ALTO）协议定义了几个服务，这些服务返回描述网络端点之间成本的各种度量。
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.
本文档定义了一个新的服务，该服务允许ALTO客户端在一个请求中检索多个成本指标，以获得ALTO筛选的成本映射和端点成本映射。此外，它通过允许ALTO客户机指定多个成本指标测试的逻辑组合，扩展了约束条件，以进一步过滤这些映射。
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.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8189.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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
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.
IETF在[RFC7285]中定义了ALTO服务，为覆盖应用程序提供指导，覆盖应用程序必须从一组能够提供所需资源的候选主机中选择一个或多个主机。本指南基于影响主机间数据传输性能的拓扑距离等参数。ALTO的目的是提高应用程序中的体验质量（QoE），同时减少底层网络基础设施中的资源消耗。ALTO协议传递了一种称为网络地图的互联网视图，该网络地图由供应商定义的位置组成，这些位置从子网到多个自治系统（ASE）。ALTO还可以在网络地图位置之间或在各个端点组之间传递提供商确定的成本。
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.
当前的ALTO成本类型提供“hopcount”和管理“routingcost”等值，以反映ISP的路由偏好。最近，新的用例将ALTO的使用范围扩展到了内容交付网络（CDN）、数据中心和需要额外信息来选择其端点或网络位置的应用程序。因此，预计将指定多种新的成本类型，以更好地反映这些应用的要求。
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.
本文档称为基本协议的ALTO协议[RFC7285]将ALTO成本映射和端点成本服务限制为每个ALTO请求只有一种成本类型。要检索多个成本类型的信息，ALTO客户端必须向服务器发送多个单独的请求。
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.
就往返时间（RTT）、通信量和ALTO客户端和服务器上的处理负载而言，通过单个查询/响应事务获得所有成本要高效得多。报告N种成本类型的一个成本图要比包含每种成本类型的N个成本图小。这对这些地图的存储和传输都很有价值。此外，对于许多需要多种成本类型信息的新兴应用程序，将它们收集在一张地图中可以节省时间。另一个优点是一致性：在一个批次中提供多个成本类型的值对于需要同步ALTO信息更新的ALTO客户非常有用。本文档定义了如何在单个请求中检索多个成本指标，以获取ALTO筛选的成本映射和端点成本映射。为确保与旧版ALTO客户端兼容，仅扩展筛选的成本映射和端点成本映射服务以返回多个成本值。
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
与多成本值查询一起，过滤功能需要扩展，以允许对多个指标进行约束。基本协议允许ALTO客户端为筛选的成本映射服务或端点成本服务提供可选的约束测试，其中
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")".
约束测试仅限于对（单个）请求的成本类型的值进行比较测试和组合测试。然而，对多个指标敏感并在复杂网络条件下挣扎的应用程序可能需要在冲突目标（如路由成本和网络性能）之间进行仲裁。为此，本文档使用约束扩展了基本协议，这些约束可以测试多个指标，并且可以与逻辑“OR”和逻辑“and”相结合。这允许应用程序发出请求，例如：“选择具有（中等“跃点数”和高“路由成本”）或（较高“跃点数”和中等“路由成本”）的解决方案”。
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.
本文件的组织结构如下。第2节定义了本文件中使用的术语。第3节给出了多重成本扩展的非规范性概述，第4节给出了正式定义。第5节给出了几个完整的例子。其余部分介绍IANA、隐私和安全注意事项。
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.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
When the words appear in lower case, they are to be interpreted with their natural language meanings.
当这些词以小写形式出现时，将按照其自然语言含义进行解释。
o ALTO transaction: A request/response exchange between an ALTO Client and an ALTO Server.
o ALTO事务：ALTO客户端和ALTO服务器之间的请求/响应交换。
o Client: When used with a capital "C", this term refers to an ALTO Client.
o 客户：当与大写字母“C”一起使用时，此术语指ALTO客户。
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 端点（EP）：端点定义见[RFC7285]第2.1节。例如，它可以是对等方、CDN存储位置、虚拟服务器支持的应用程序中涉及的物理服务器、资源共享群（如计算网格）中的一方或在线多方游戏。
o Server: When used with a capital "S", this term refers to an ALTO Server.
o 服务器：当与大写字母“S”一起使用时，此术语指的是ALTO服务器。
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].
以下是本文件中定义的多成本ALTO扩展的非规范性概述。它假设读者熟悉ALTO协议[RFC7285]中的成本映射资源。
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.
从形式上讲，ALTO成本图中的成本条目可以是任何类型的JSON值[RFC7159]（参见[RFC7285]第11.2.3.6节中的DstCosts对象）。但是，该部分还指出，除非实现使用的扩展表示不同的数据类型，否则实现可能会假定成本是JSON数字。
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.
因此，本文档扩展了成本图的定义，允许成本是一个成本数组，每个度量一个，而不是一个数字。例如，这里有一个带有“routingcost”和“hopcount”度量的成本图。请注意，这与常规ALTO成本映射相同，只是值是数组而不是数字。多个指标列在成员“多成本类型”中，指示客户如何将阵列中的值映射到成本指标。
{
"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] },
...
}
}
{
"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].
还请注意成员“cost type”：{}的存在，以保持与[RFC7285]的向后兼容性。
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]).
本文档未定义任何新的媒体类型。相反，如下所述，它扩展了ALTO服务器的信息资源目录（IRD）中的规范，以便旧客户端不会请求数组值的多成本映射资源。这取决于ALTO客户必须忽略未知字段的要求（RFC7285第8.3.7节）。
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.
本文档扩展了筛选成本映射服务，以允许同一资源返回[RFC7285]中定义的单值成本映射，或本文档中定义的数组值多成本映射。扩展的筛选成本映射资源具有新功能“最大成本类型”。该值是此资源可以为一个请求返回的最大成本类型数。此功能的存在意味着资源了解本文档中的扩展。
For example, the following fragment from an IRD defines an extended Filtered Cost Map resource:
例如，来自IRD的以下片段定义了扩展的过滤成本映射资源：
"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" ],
...
}
"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.
传统ALTO客户端将忽略“最大成本类型”功能，并将发送一个输入参数“成本类型”的请求，该参数描述了[RFC7285]中定义的所需成本指标。ALTO服务器将返回一个单值遗留成本映射。
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
但是，多成本感知ALTO客户端将认识到该资源支持多成本扩展，并可以使用新的输入参数“多成本类型”发送POST请求，该参数的值是成本类型数组。因为请求具有“多成本类型”参数（而不是基本协议中定义的“成本类型”参数），所以服务器意识到ALTO客户端也
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".
支持本文档中的扩展，因此使用多成本图进行响应，成本按“多成本类型”中列出的顺序排列。
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.
[RFC7285]第4.1.4节规定，“端点成本服务允许ALTO服务器直接在端点之间返回成本”，而过滤成本映射服务在提供者定义的标识符（PID）之间返回成本。本文档使用第3.3节中描述的技术扩展Endpoint Cost Service，以向了解这些扩展的ALTO客户端返回数组值成本。
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.
[RFC7285]第11.3.2.3节要求，如果ALTO客户省略了源和目标PID，则过滤后的成本图将返回整个成本图。因此，多成本感知ALTO客户端可以使用扩展的过滤成本映射资源来获得完整的多成本映射。
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.
完全成本映射资源是GET模式请求。传递多个成本类型的完整成本图的响应将包括一个“元”字段，该字段本身将包括一个“成本类型”字段，该字段将列出与成本图的成本类型对应的多个值。旧版ALTO客户端将无法理解此列表。它也无法解释完整的多成本图提供的成本值数组。
[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:
[RFC7285]为过滤成本映射和端点成本服务定义了一个简单的约束测试功能。如果资源支持约束，则服务器将响应限制为满足ALTO客户端提供的简单谓词列表的开销。例如，如果ALTO客户端提供以下约束：
"constraints": ["ge 10", "le 20"]
"constraints": ["ge 10", "le 20"]
then the Server only returns costs in the range [10,20].
然后服务器只返回范围为[10,20]的成本。
To be useful with multi-cost requests, the constraint tests require several extensions.
为了对多成本请求有用，约束测试需要几个扩展。
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.
首先，由于多成本请求涉及多个成本度量，因此必须扩展简单谓词以指定要测试的度量。因此，我们将谓词语法扩展到“[##]op value”，其中“##”是此多成本请求中成本度量的索引。
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.
其次，一旦涉及到多个成本指标，简单谓词的“和”就不再足够了。为了有用，客户机必须能够表示“或”测试。因此，我们在客户机请求中添加了一个新字段“或约束”。值是简单谓词数组的数组，表示这些谓词的and的OR。
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:
因此，以下请求告诉服务器将其响应限制为“routingcost”<=100和“hopcount”<=2的成本点，或者“routingcost”<=10和“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": {...}
}
{
"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.
请注意，具有谓词数组[P1，P2，…]的“约束”参数相当于具有一个值数组[[P1，P2，…]的“或约束”参数。因此，允许客户机表示“约束”或“或约束”，但不能同时表示两者。
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".
最后，客户机可能希望测试实际值无关的成本类型，只要它满足测试要求。例如，客户机可能需要满足度量“hopcount”约束的所有PID对的成本度量“routingcost”的值，而不需要“hopcount”的实际值。
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:
例如，以下请求告诉服务器仅为“hopcount”小于等于6的源和目标对返回“routingcost”：
{
"multi-cost-types": [
{"cost-metric": "routingcost", "cost-mode": "numerical"},
],
"testable-cost-types": [
{"cost-metric": "hopcount", "cost-mode": "numerical"},
],
"constraints": ["[0] le 6"],
"pids": {...}
}
{
"multi-cost-types": [
{"cost-metric": "routingcost", "cost-mode": "numerical"},
],
"testable-cost-types": [
{"cost-metric": "hopcount", "cost-mode": "numerical"},
],
"constraints": ["[0] le 6"],
"pids": {...}
}
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".
在[RFC7285]中，当资源的功能“约束”为true时，服务器接受“成本类型名称”功能中列出的所有成本类型的约束。但是，一些ALTO服务器可能不愿意对所有可用的成本指标进行约束测试。因此，多成本ALTO协议扩展定义了能力字段“可测试成本类型名称”。与“成本类型名称”类似，它是一个成本类型名称数组。如果存在，该资源仅允许对该列表中的成本类型进行约束测试。“可测试成本类型名称”必须是“成本类型名称”的子集。
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".
虽然多成本感知客户机将识别“可测试成本类型名称”字段并遵守这些限制，但传统客户机不会。因此，当“constraints”的值为“true”时，遗留客户端可以发送一个请求，并对“cost type name”中列出的任何成本类型进行约束测试。
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
为了避免这个问题，“可测试成本类型名称”和“成本约束”字段是互斥的：资源可以定义一种或另一种能力，但不能同时定义这两种能力。因此，不允许对所有成本指标进行约束测试的资源将为可测试指标设置“可测试成本类型名称”，并将“成本约束”设置为“false”。多成本感知客户机将识别“可测试成本类型名称”字段，并意识到其存在意味着资源不允许（有限）约束
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.
测试，而遗留客户端将认为资源根本不允许约束测试。为了允许旧客户端使用约束测试，ALTO服务器可以定义一个附加资源，将“成本约束”设置为“true”，并将“成本类型名称”设置为可测试的指标。
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.
在下面的IRD示例中，资源“filtered cost map extended”提供了三个度量值：“num routingcost”、“num hopcount”和“num BWCore”。“可测试成本类型名称”功能表示服务器只允许对“路由成本”和“跳数”进行约束。具有多成本能力的客户机将看到此功能，并将其约束测试限制在这些指标上。由于功能“成本约束”为false（默认情况下），旧客户端根本不会对该资源使用约束测试。
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.
第二个资源“filtered multicost map”与第一个类似，只是它返回的所有度量都是可测试的。因此，它将“成本约束”设置为“true”，而不设置“可测试成本类型名称”字段。需要约束测试的旧客户端将使用此资源，而不是第一个资源。不需要检索“num bwscore”指标的多成本感知客户机可以使用任一资源。
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.
请注意，如果多成本服务器指定了“已过滤的成本映射扩展”，则如果后者的功能包含在前者的功能中，或者除非“已过滤的多成本映射”资源也用于遗留客户端，则它很可能不会指定“已过滤的多成本映射”。
"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-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"],
}
}
"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"],
}
}
This section formally specifies the extensions to [RFC7285] to support multi-cost ALTO transactions.
本节正式指定了[RFC7285]的扩展，以支持多成本ALTO事务。
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.
本文件使用[RFC7285]第8.2节规定的符号规则。特别是，可选字段由[]括起。在定义中，字段的JSON名称区分大小写。一个数组由尖括号中的两个数字表示，<m..n>，其中m表示最小值，n表示最大值。当本文档使用*表示n时，表示没有上限。
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.
本文件扩展了[RFC7285]第11.3.2节中定义的过滤成本图，增加了新的输入参数和功能，并返回JSONArray而不是JSONNumber作为成本值。
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.
介质类型、HTTP方法和“使用”规范（分别在[RFC7285]的第11.3.2.1、11.3.2.2和11.3.2.5节中描述）没有改变。
The filtered cost map capabilities are extended with two new members:
过滤后的成本图功能扩展为两个新成员：
o max-cost-types
o 最大成本类型
o testable-cost-type-names
o 可测试成本类型名称
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:
功能“最大成本类型”指示此资源是否支持多成本ALTO扩展，功能“可测试成本类型名称”允许资源将约束测试限制为可用成本类型的子集。通过这两个附加成员，[RFC7285]第11.3.2.4节中的FilteredCostMapCapabilities对象的结构如下：
object {
JSONString cost-type-names<1..*>;
[JSONBool cost-constraints;]
[JSONNumber max-cost-types;]
[JSONString testable-cost-type-names<1..*>;]
} FilteredCostMapCapabilities;
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].
成本类型名称：如[RFC7285]第11.3.2.4节所定义。
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.
成本限制：如[RFC7285]第11.3.2.4节所定义。因此，如果“成本约束”为真，资源必须接受“成本类型名称”中任何成本类型的约束测试。此外，请注意，如果“成本约束”为真，则“可测试成本类型名称”功能不得存在。
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.
最大成本类型：如果存在的值N大于0，则此资源了解此文档中的多成本扩展，并且可以在“成本类型名称”列表中返回包含N个或更少成本类型的任意组合的多成本映射。如果省略，默认值为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.
可测试的成本类型名称：如果存在，资源允许进行约束测试，但仅限于此数组中的成本类型名称。“可测试成本类型名称”中的每个名称也必须在“成本类型名称”中。如果存在“可测试成本类型名称”，则“成本约束”功能不能为true。
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.
如第3.6.4节所述，当服务器无法或不愿意对所有成本类型实施约束测试时，此功能非常有用。如第3.6.5节所述，“可测试成本类型名称”和“成本约束”相互排斥，以防止遗留客户端对不稳定的成本类型进行约束测试。
The ReqFilteredCostMap object in Section 11.3.2.3 of [RFC7285] is extended as follows:
[RFC7285]第11.3.2.3节中的ReqFilteredCostMap对象扩展如下：
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;
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".
成本类型：如[RFC7285]第11.3.2.3节所定义，另外要求客户必须指定“成本类型”或“多种成本类型”，但不得同时指定两者。因此，此字段是可选的。当按照[RFC7285]中的规定提交单个成本申请时，客户机必须使用“成本类型”。
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.
多成本类型：如果存在，ALTO服务器必须为此列表中的成本类型返回数组值成本。对于每个条目，“成本度量”和“成本模式”字段必须与此资源的“能力”字段（第4.1.1节）的成员“成本类型名称”中指示的支持的成本类型之一相匹配。除非此资源的“最大成本类型”功能存在且其值大于0，否则客户端不得使用此字段。此字段的成本类型不能超过“最大成本类型”。客户必须指定“成本类型”或“多成本类型”，但不能同时指定这两种类型。
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.
可测试成本类型：用于扩展约束测试的成本类型列表，如“约束”和“或约束”参数所述。这些成本类型必须是资源“可测试成本类型名称”功能（第4.1.1节）中成本类型的子集，或者，如果资源的功能“成本约束”为真，则是资源“成本类型名称”功能中成本类型的子集。
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.
当客户机想要测试实际值不相关的成本类型时，此功能非常有用，只要它满足测试要求。例如，客户机可能需要“hopcount”小于10的PID对的成本度量“routingcost”。确切的跳数并不重要。
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.
约束：如果该资源的“最大成本类型”功能（第4.1.1节）的值为0（或未定义），则该参数如[RFC7285]第11.3.2.3节中所定义：通过逻辑AND相互关联的约束测试数组。在这种情况下，除非资源的“成本约束”功能为真，否则不能指定它。
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).
如果此资源的“最大成本类型”功能的值大于0，则此参数是以下定义的扩展约束谓词数组，并通过逻辑and相互关联。在这种情况下，可以指定资源是否允许约束测试（资源的“成本约束”功能为true，或者其“可测试成本类型名称”功能不为空）。
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.
扩展约束谓词由两个或三个由空格分隔的实体组成：（1）形式为“[#]”且默认值为“[0]”的可选成本类型索引，（2）必需的运算符，以及（3）必需的目标值。操作员和目标值如[RFC7285]第11.3.2.3节所述。成本类型索引i指定要测试的成本类型。如果存在“可测试成本类型”参数，则测试将应用于“可测试成本类型”中的第i个成本类型，从索引0开始。否则，如果存在“多成本类型”参数，则测试将应用于该数组中的第i个成本类型。如果两个参数都不存在，则测试将应用于“成本类型”参数中的成本类型，在这种情况下，索引必须为0。无论测试成本类型是如何选择的，它都必须位于资源的“可测试成本类型名称”功能中，如果不存在，则必须位于“成本类型名称”功能中。
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".
例如，假设“多成本类型”具有单个元素“routingcost”，“可测试成本类型”具有单个元素“hopcount”，“约束”具有单个元素“[0]le 5”。这相当于数据库查询“选择并提供hopcount≤5的routingcost”。
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.
请注意，索引是可选的，因此[RFC7285]第11.3.2.3节中定义的约束测试，如“le 10”，相当于“[0]le 10”。因此，遗留约束测试也是合法的扩展约束测试。
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, ...]].
请注意，带有扩展谓词数组[P1，P2，…]的“约束”参数相当于下面定义的值为[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.
or约束：JSONString的JSONArray的JSONArray，其中每个字符串都是上面定义的扩展约束谓词。“或约束”测试被解释为谓词AND的逻辑or。也就是说，ALTO服务器只有在满足任何一个子阵列中的所有约束时才应返回成本点。
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.
如果此资源的“最大成本类型”功能的定义值大于0（第4.1.1节），并且资源允许约束测试（资源的“成本约束”功能为真，或其“可测试成本类型名称”功能不为空），则可以指定此参数。否则，不得指定此参数。
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.
此参数不能包含和谓词的任何空数组。空数组将等效于始终为真的约束。包含这样一个约束的OR组合总是正确的，因此是无用的。
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)".
例如，假设“多成本类型”有两个元素“路由成本”和“带宽分数”，“可测试成本类型”有两个元素“路由成本”和“跳数”，“或约束”有两个元素[“[0]le 100”、“[1]le 2”]和[“[0]le 10”、“[1]le 6”]。这相当于“选择并提供路由成本和带宽分数，其中（“路由成本”<=100和“跳数”<=2）或（“路由成本”<=10和“跳数”<=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.
请注意，如果“最大成本类型”功能的值大于0，则客户机可以将“或约束”参数与“成本类型”参数一起使用。也就是说，如果客户机和服务器都知道本文档中的扩展，则客户机可以对单值成本请求使用“或”测试。
pids: As defined in Section 11.3.2.3 of [RFC7285].
pids：如[RFC7285]第11.3.2.3节所定义。
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:
如果客户指定“成本类型”输入参数，则响应完全符合[RFC7285]第11.2.3.6节的定义。如果客户提供“多成本类型”，则响应更改如下：
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 在“meta”中，“cost type”字段的值将被接收方忽略并设置为{}。相反，“多成本类型”字段添加的值与“多成本类型”输入参数的值相同。
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.
o 成本是JSONArray而不是JSONNumber。所有数组都具有与“多成本类型”输入参数相同的基数，并按该顺序包含成本类型值。如果成本类型不适用于特定的源和目标，ALTO服务器必须为该数组元素使用JSON“null”值。如果没有任何成本类型可用于特定的来源和目的地，ALTO服务器可能会忽略该来源和目的地的条目。
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.
本文档扩展了[RFC7285]第11.5.1节中定义的端点成本服务，添加了新的输入参数和功能，并返回JSONArray而不是JSONNumber作为成本值。
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.
介质类型、HTTP方法和“使用”规范（分别在[RFC7285]的第11.5.1.1、11.5.1.2和11.5.1.5节中描述）不变。
The extensions to the Endpoint Cost Service capabilities are identical to the extensions to the Filtered Cost Map (see Section 4.1.1).
端点成本服务功能的扩展与过滤成本图的扩展相同（参见第4.1.1节）。
The ReqEndpointCostMap object in Section 11.5.1.3 of [RFC7285] is extended as follows:
[RFC7285]第11.5.1.3节中的ReqEndpointCostMap对象扩展如下：
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;
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.
成本类型：如[RFC7285]第11.5.1.3节所定义，另外要求客户必须指定“成本类型”或“多种成本类型”，但不得同时指定两者。
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.
多成本类型：如果存在，ALTO服务器必须为此列表中的成本类型返回数组值成本。对于每个条目，“成本度量”和“成本模式”字段必须与此资源的“能力”字段（第4.2.1节）中指示的一种支持的成本类型相匹配。除非此资源的“最大成本类型”功能存在且其值大于0，否则客户端不得使用此字段。此字段的成本类型不能超过“最大成本类型”。客户必须指定“成本类型”或“多成本类型”，但不能同时指定这两种类型。
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).
可测试成本类型、约束或约束：与扩展过滤成本图的相应输入参数等效定义（第4.1.2节）。
endpoints: As defined in Section 11.5.1.3 of [RFC7285].
端点：如[RFC7285]第11.5.1.3节所定义。
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:
端点成本服务响应的扩展与过滤成本映射响应的扩展类似（第4.1.3节）。具体而言，如果客户指定“成本类型”输入参数，则响应完全符合[RFC7285]第11.5.1.6节的定义。如果客户提供“多成本类型”，则响应更改如下：
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 在“meta”中，“cost type”字段的值将被接收方忽略并设置为{}。相反，“多成本类型”字段添加的值与“多成本类型”输入参数的值相同。
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.
o 成本是JSONArray而不是JSONNumber。所有数组都具有与“多成本类型”输入参数相同的基数，并按该顺序包含成本类型值。如果成本类型不适用于特定的源和目标，ALTO服务器必须为该数组元素使用JSON“null”值。如果没有任何成本类型可用于特定的来源和目的地，ALTO服务器可能会忽略该来源和目的地的条目。
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.
本节提供了多成本ALTO交易的示例。除了强制性的遗留“路由成本”之外，它还使用了成本指标，这些指标故意不相关且未在IANA注册。
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.
以下是ALTO服务器信息资源目录的示例。除了网络和成本映射资源外，它还定义了两个过滤成本映射和一个端点成本服务，它们都理解多成本扩展。
GET /directory HTTP/1.1
Host: alto.example.com
Accept: application/alto-directory+json,application/alto-error+json
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
HTTP/1.1 200 OK
Content-Length: 2704
Content-Type: application/alto-directory+json
{
"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",
{
"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",
"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" ]
}
}
}
}
"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" ]
}
}
}
}
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.
此示例演示了一个简单的多成本ALTO事务。ALTO服务器提供两种成本类型，“routingcost”和“shoesize”，均采用“数字”模式。客户需要整个多成本图。服务器不知道PID2和PID3之间的“routingcost”值，因此返回PID2和PID3之间的“routingcost”值“null”。
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
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" : [ ]
}
}
{
"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
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] }
}
}
{
"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] }
}
}
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.
此示例使用约束将返回的源/目标PID对限制为“routingcost”在5到10之间或“shoesize”等于0的源/目标PID对。
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
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" ]
}
}
{
"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
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] }
}
}
{
"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] }
}
}
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.
此示例使用扩展约束限制对成本点的响应（“routingcost”<=10和“shoesize”<=2），或者（“routingcost”<=3和“shoesize”<=6）。与前面的示例不同，客户端只对“routingcost”成本类型感兴趣，并使用“cost type”参数而不是“multi cost type”来告诉服务器返回标量成本而不是数组成本。
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].
在本例中，“[0]”表示约束适用于“routingcost”，因为这是“可测试成本类型”参数中的第一个成本类型。（如果省略了“可测试成本类型”，则假定其与“多成本类型”相同。）选择使用索引来引用成本类型旨在最小化约束表达式的长度，特别是对于组合了多个OR表达式的约束。这也是[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
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" : [ ]
}
}
{
"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" : [ ]
}
}
HTTP/1.1 200 OK
Content-Type: application/alto-costmap+json
Content-Length: 368
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 }
}
}
{
"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 }
}
}
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:
此示例使用扩展约束限制对成本点的响应（“routingcost”<=10和“shoesize”<=2），或者（“routingcost”<=3和“shoesize”<=6）。在本例中，客户对“routingcost”和“sceneryrate”成本指标感兴趣，但对“shoesize”指标不感兴趣：
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
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"}
],
{
"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"}
],
"or-constraints": [
["[0] le 10", "[1] le 2"],
["[0] le 3", "[1] le 6"]
],
"pids" : {
"srcs" : [ ],
"dsts" : [ ]
}
}
"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
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] }
}
}
{
"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] }
}
}
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).
此示例使用端点成本服务来检索选定端点的“路由成本”和“shoesize”，将响应限制为具有低“shoesize”和合理“routingcost”（“shoesize”<=2和“routingcost”<=10）或低“routingcost”和合理“shoesize”（“routingcost”<=3和“shoesize”<=6）的成本。
POST /multi/endpointcost/lookup HTTP/1.1
Host: alto.example.com
Accept: application/alto-endpointcost+json,
application/alto-error+json
POST /multi/endpointcost/lookup HTTP/1.1
Host: alto.example.com
Accept: application/alto-endpointcost+json,
application/alto-error+json
Content-Type: application/alto-endpoincostparams+json
Content-Length: 455
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"
]
}
}
{
"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
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]
}
}
}
{
"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]
}
}
}
This document does not define any new media types or introduce any new IANA considerations.
本文档未定义任何新的媒体类型或引入任何新的IANA注意事项。
This document does not introduce any privacy or security issues not already present in the ALTO protocol.
本文件不涉及ALTO协议中尚未出现的任何隐私或安全问题。
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.
与多个单成本ALTO事务相比，多成本优化甚至倾向于减少在线数据交换量。类似地，与大规模多成本请求相关的风险也因多成本约束额外过滤ALTO服务器响应从而减少其容量而得到缓解。
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.
请注意，由于对多个度量的查询比对单个度量的查询表示更强的指纹信号，因此该协议的实现可能会泄漏有关ALTO客户端的更多信息，而不是连续的单个查询。不过，在许多情况下，已经可以使用源IP地址或其他现有信息链接这些查询。
[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>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<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>.
[RFC7285]Alimi，R.，Ed.，Penno，R.，Ed.，Yang，Y.，Ed.，Kiesel，S.，Previdi，S.，Room，W.，Shalunov，S.，和R.Woundy，“应用层流量优化（ALTO）协议”，RFC 7285，DOI 10.17487/RFC7285，2014年9月<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>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[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>.
[RFC7159]Bray，T.，Ed.“JavaScript对象表示法（JSON）数据交换格式”，RFC 7159，DOI 10.17487/RFC7159，2014年3月<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.
作者感谢Richard Alimi、Fred Baker、Dhruv Dhodi、Vijay Gurbani、Dave Mac Dysan、Young Lee和Richard Yang对本文件和早期草案版本进行了富有成效的讨论和反馈。高凯、汉斯·赛德尔、理查德·杨、乔翔和王欣为方案设计提供了实质性的审查反馈和建议。
Authors' Addresses
作者地址
Sabine Randriamasy Nokia Bell Labs Route de Villejust Nozay 91460 France
Sabine Randriamasy诺基亚贝尔实验室Villejust Nozay路线91460法国
Email: Sabine.Randriamasy@nokia-bell-labs.com
Email: Sabine.Randriamasy@nokia-bell-labs.com
Wendy Roome Nokia Bell Labs 124 Burlington Rd Murray Hill, NJ 07974 United States of America
Wendy Room诺基亚贝尔实验室美国新泽西州默里山伯灵顿路124号07974
Email: ietf@wdroome.com
Email: ietf@wdroome.com
Nico Schwan Thales Deutschland Lorenzstrasse 10 Stuttgart 70435 Germany
Nico Schwan Thales Deutschland Lorenzstrasse 10斯图加特70435德国
Email: nico.schwan@thalesgroup.com
Email: nico.schwan@thalesgroup.com