[要約] RFC 8189は、ALTOプロトコルを使用してアプリケーション層トラフィックの最適化を行うためのマルチコストアプローチを提案しています。このRFCの目的は、ネットワークリソースの効率的な利用とトラフィックの最適化を実現することです。
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で指定されているApplication-Layer Traffic Optimization（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.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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サービスを定義して、オーバーレイアプリケーションにガイダンスを提供します。オーバーレイアプリケーションは、希望のリソースを提供できる候補のセットから1つまたは複数のホストを選択する必要があります。このガイダンスは、ホスト間のデータ転送のパフォーマンスに影響を与えるトポロジー距離などのパラメーターに基づいています。 ALTOの目的は、アプリケーションのQuality of Experience（QoE）を改善すると同時に、基盤となるネットワークインフラストラクチャのリソース消費を削減することです。 ALTOプロトコルは、サブネットから複数の自律システム（AS）に及ぶプロバイダー定義の場所で構成されるネットワークマップと呼ばれるインターネットのビューを伝達します。 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コストタイプは、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要求ごとに1つのコストタイプのみに制限します。複数のコストタイプの情報を取得するには、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個のコストタイプに関する1つのコストマップレポートは、それぞれ1つのコストタイプを含むN個のコストマップよりもかさばりません。これは、これらのマップの保存と送信の両方に役立ちます。さらに、いくつかのコストタイプに関する情報を必要とする多くの新しいアプリケーションでは、それらを1つのマップに集めることで時間を節約できます。もう1つの利点は一貫性です。1つのバッチで複数のコストタイプの値を指定することは、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 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")".
マルチコスト値のクエリに加えて、フィルタリング機能を拡張して、複数のメトリックに対する制約を許可する必要があります。基本プロトコルにより、ALTOクライアントは、フィルターされたコストマップサービスまたはエンドポイントコストサービスのオプションの制約テストを提供できます。制約テストは、（単一の）要求されたコストタイプの値に対する比較テストのANDの組み合わせに限定されます。ただし、いくつかのメトリックに敏感で、複雑なネットワーク条件に苦労しているアプリケーションは、ルーティングコストやネットワークパフォーマンスなどの競合する目標を調整する必要がある場合があります。このため、このドキュメントでは、複数のメトリックをテストし、論理「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.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、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.
したがって、このドキュメントでは、コストマップの定義を拡張して、1つの数値ではなく、メトリックごとに1つのコストの配列をコストにできるようにします。たとえば、「routingcost」および「hopcount」メトリックのコストマップは次のとおりです。これは、値が数値ではなく配列であることを除いて、通常のALTOコストマップと同じです。複数のメトリックはメンバー「multi-cost-types」にリストされており、配列内の値をコストメトリックにマップする方法をクライアントに示します。
{
"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].
[RFC7285]との下位互換性を維持するために、メンバー「 "cost-type"：{}」の存在にも注意してください。
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.
このドキュメントはFiltered Cost Map Serviceを拡張して、同じリソースが[RFC7285]で定義されている単一値のコストマップ、またはこのドキュメントで定義されている配列値の複数コストマップを返すことができるようにします。拡張Filtered Cost Mapリソースには、「max-cost-types」という新機能があります。値は、このリソースが1つの要求に対して返すことができるコストタイプの最大数です。この機能の存在は、リソースがこのドキュメントの拡張機能を理解することを意味します。
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" ],
...
}
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クライアントは「max-cost-types」機能を無視し、[RFC7285]で定義されているように、必要なコスト指標を説明する入力パラメーター「cost-type」を使用してリクエストを送信します。 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 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".
ただし、マルチコスト対応のALTOクライアントは、このリソースがマルチコスト拡張をサポートし、値がコストタイプの配列である新しい入力パラメーター「multi-cost-types」でPOSTリクエストを送信できることを認識します。リクエストには（基本プロトコルで定義された「cost-type」パラメーターではなく）「multi-cost-types」パラメーターがあるため、サーバーは、ALTOクライアントもこのドキュメントの拡張機能をサポートしていることを認識し、マルチ-「マルチコストタイプ」にリストされている順序でのコストを含むコストマップ。
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は、「Endpoint Cost Serviceは、ALTOサーバーがエンドポイント間で直接コストを返すことを許可する」と規定していますが、Filtered Cost Map Serviceは、プロバイダー定義の識別子（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]は、Filtered Cost MapおよびEndpoint Cost Servicesの簡単な制約テスト機能を定義しています。リソースが制約をサポートする場合、サーバーは、ALTOクライアントによって提供される単純な述語のリストを満たすコストに応答を制限します。たとえば、ALTOクライアントが次の制約を与える場合：
"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.
第2に、複数のコストメトリックが含まれると、単純な述語の「AND」ではもはや十分ではありません。役立つためには、クライアントは「OR」テストを表現できなければなりません。したがって、新しいフィールド「or-constraints」をクライアント要求に追加します。値は単純な述語の配列の配列であり、それらの述語の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 AND「hopcount」<= 2、または「routingcost」<= 10 AND「hopcount」<= 6でコストポイントに応答を制限するようサーバーに指示します。
{
"multi-cost-types": [
{"cost-metric": "routingcost", "cost-mode": "numerical"},
{"cost-metric": "hopcount", "cost-mode": "numerical"}
],
"or-constraints": [
["[0] le 100", "[1] le 2"],
["[0] le 10", "[1] le 6"]
],
"pids": {...}
}
Note that a "constraints" parameter with the array of predicates [P1, P2, ...] is equivalent to an "or-constraints" parameter with one array of value [[P1, P2, ...]]. A Client is therefore allowed to express either "constraints" or "or-constraints" but not both.
述語の配列[P1、P2、...]を持つ「制約」パラメーターは、値の配列[[P1、P2、...]]を持つ「or-constraints」パラメーターと同等であることに注意してください。したがって、クライアントは「制約」または「または制約」のいずれかを表現できますが、両方を表現することはできません。
Finally, a Client may want to test a cost type whose actual value is irrelevant, as long as it satisfies the tests. For example, a Client may want the value of the cost metric "routingcost" for all PID pairs that satisfy constraints on the metric "hopcount", without needing the actual value of "hopcount".
最後に、クライアントは、テストを満たす限り、実際の値が無関係であるコストタイプをテストすることができます。たとえば、クライアントは、「hopcount」の実際の値を必要とせずに、メトリック「hopcount」の制約を満たすすべてのPIDペアのコストメトリック「routingcost」の値を必要とする場合があります。
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".
この目的のために、パラメーター「multi-cost-types」と同じコストタイプを含まない「testable-cost-types」という名前の特定のパラメーターを追加します。クライアントは、「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": {...}
}
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の場合、サーバーは「cost-type-names」機能にリストされているすべてのコストタイプに対する制約を受け入れます。ただし、一部のALTOサーバーは、使用可能なすべてのコストメトリックの制約テストを許可しない場合があります。したがって、マルチコストALTOプロトコル拡張は、機能フィールド「testable-cost-type-names」を定義します。 「コストタイプ名」と同様に、これはコストタイプ名の配列です。存在する場合、そのリソースは、リスト内のコストタイプに対する制約テストのみを許可します。 「testable-cost-type-names」は「cost-type-names」のサブセットである必要があります。
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".
マルチコスト対応のクライアントは「testable-cost-type-names」フィールドを認識し、それらの制限を順守しますが、レガシークライアントはそうしません。したがって、「constraints」の値が「true」の場合、レガシークライアントは「cost-type-names」にリストされているコストタイプのいずれかに対する制約テストを含むリクエストを送信できます。
To avoid that problem, the "testable-cost-type-names" and "cost-constraints" fields are mutually exclusive: a resource may define one or the other capability but MUST NOT define both. Thus, a resource that does not allow constraint tests on all cost metrics will set "testable-cost-type-names" to the testable metrics and will set "cost-constraints" to 'false'. A multi-cost-aware Client will recognize the "testable-cost-type-names" field and will realize that its existence means the resource does allow (limited) constraint 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.
この問題を回避するために、「testable-cost-type-names」フィールドと「cost-constraints」フィールドは相互に排他的です。リソースはどちらか一方の機能を定義できますが、両方を定義してはなりません。したがって、すべてのコストメトリックに対する制約テストを許可しないリソースは、「testable-cost-type-names」をテスト可能なメトリックに設定し、「cost-constraints」を「false」に設定します。マルチコスト対応のクライアントは「testable-cost-type-names」フィールドを認識し、その存在がリソースが（制限された）制約テストを許可することを認識しますが、レガシークライアントはリソースが制約テストを許可しないと考えますまったく。レガシークライアントが制約テストを使用できるようにするために、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-bwscore」の3つのメトリックの値を提供します。 「testable-cost-type-names」機能は、サーバーが「routingcost」と「hopcount」の制約のみを許可することを示します。マルチコスト対応のクライアントはこの機能を認識し、制約テストをそれらのメトリックに制限します。機能「コスト制約」は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.
2番目のリソース「filtered-multicost-map」は、返されるすべてのメトリックがテスト可能であることを除いて、最初のリソースと同じです。したがって、「cost-constraints」を「true」に設定し、「testable-cost-type-names」フィールドを設定しません。制約テストを必要とするレガシークライアントは、最初ではなくこのリソースを使用します。 「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」を指定した場合、後者の機能が前者の機能でカバーされている場合、またはそうでない場合は、「filtered-multicost-map」を指定しない可能性が高いことに注意してください。 「filtered-multicost-map」リソースは、レガシークライアントも対象としています。
"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"],
}
}
This section formally specifies the extensions to [RFC7285] to support multi-cost ALTO transactions.
このセクションでは、マルチコストALTOトランザクションをサポートするための[RFC7285]の拡張を正式に指定します。
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名は大文字と小文字が区別されます。配列は山かっこで囲まれた2つの数値<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で定義されているように、フィルターされたコストマップを拡張し、新しい入力パラメーターと機能を追加し、JSONNumbersではなくJSONArraysをコスト値として返します。
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:
フィルターされたコストマップ機能は、2つの新しいメンバーで拡張されます。
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:
機能「max-cost-types」は、このリソースがマルチコストALTO拡張をサポートするかどうかを示し、機能「testable-cost-type-names」は、リソースが制約テストを使用可能なコストタイプのサブセットに制限できるようにします。これら2つの追加メンバーにより、[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;
cost-type-names: As defined in Section 11.3.2.4 of [RFC7285].
cost-type-names：[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で定義されています。したがって、「cost-constraints」がtrueの場合、リソースは「cost-type-names」のすべてのコストタイプの制約テストを受け入れる必要があります。さらに、「cost-constraints」がtrueの場合、「testable-cost-type-names」機能が存在してはならないことに注意してください。
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.
max-cost-types：値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.
testable-cost-type-names：存在する場合、リソースは制約テストを許可しますが、この配列のコストタイプ名に対してのみです。 「testable-cost-type-names」の各名前は、「cost-type-names」にも含まれている必要があります。 「testable-cost-type-names」が存在する場合、「cost-constraints」機能は真であってはなりません（MUST NOT）。
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;
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.
multi-cost-types：存在する場合、ALTOサーバーはこのリストのコストタイプの配列値のコストを返さなければなりません（MUST）。各エントリについて、「cost-metric」フィールドと「cost-mode」フィールドは、このリソースの「capabilities」フィールドのメンバー「cost-type-names」に示されているサポートされているコストタイプの1つと一致する必要があります（セクション4.1.1）。このリソースの「max-cost-types」機能が存在し、値が0を超えていない限り、クライアントはこのフィールドを使用してはならない（MUST NOT）。このフィールドは、「max-cost-types」以上のコストタイプを持っていてはならない。クライアントは「コストタイプ」または「マルチコストタイプ」のいずれかを指定する必要がありますが、両方を指定してはなりません。
Note that if "multi-cost-types" has one cost type, the values in the cost map will be arrays with one value.
「マルチコストタイプ」に1つのコストタイプがある場合、コストマップの値は1つの値を持つ配列になります。
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.
testable-cost-types：「constraints」および「or-constraints」パラメータで説明されている、拡張制約テストに使用されるコストタイプのリスト。これらのコストタイプは、リソースの「testable-cost-type-names」機能（セクション4.1.1）のコストタイプのサブセットであるか、リソースの機能「コスト制約」がtrueの場合、リソースの「コストタイプ名」機能のコストタイプ。
If "testable-cost-types" is omitted, it is assumed to have the cost types in "multi-cost-types" or "cost-type".
「testable-cost-types」が省略された場合、「multi-cost-types」または「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.
制約：このリソースの「max-cost-types」機能（セクション4.1.1）の値が0（または定義されていない）の場合、このパラメーターは[RFC7285]のセクション11.3.2.3で定義されているとおりです：制約テストの配列論理ANDによって互いに関連付けられています。この場合、リソースの「コスト制約」機能がtrueでない限り、指定してはなりません（MUST NOT）。
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).
このリソースの「max-cost-types」機能の値が0より大きい場合、このパラメーターは、以下で定義され、論理ANDによって互いに関連付けられている拡張制約述語の配列です。この場合、リソースが制約テストを許可するかどうかを指定することができます（リソースの「コスト制約」機能がtrueであるか、または「testable-cost-type-names」機能が空ではない）。
This parameter MUST NOT be specified if the "or-constraints" parameter is specified.
「or-constraints」パラメーターが指定されている場合、このパラメーターを指定してはなりません（MUST NOT）。
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.
拡張制約述語は、空白で区切られた2つまたは3つのエンティティで構成されます：（1）デフォルト値が[[0] "のフォーム" [＃] "のオプションのコストタイプインデックス、（2）必須演算子、および（3 ）必要な目標値。演算子と目標値は、[RFC7285]のセクション11.3.2.3で定義されています。コストタイプインデックスiは、テストするコストタイプを指定します。 「testable-cost-type」パラメーターが存在する場合、テストは「testable-cost-types」のi番目のコストタイプにインデックス0から始まります。それ以外の場合、「multi-cost-types」パラメーターが現在、テストはその配列のi番目のコストタイプに適用されます。どちらのパラメーターも存在しない場合、テストは「cost-type」パラメーターのコストタイプに適用されます。この場合、インデックスは0でなければなりません。テストされたコストタイプの選択方法に関係なく、リソースの「testable- 「コストタイプ名」機能、または存在しない場合は「コストタイプ名」機能。
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".
例として、「multi-cost-types」に「routingcost」という単一の要素があり、「testable-cost-types」に「hopcount」という単一の要素があり、「constraints」に「[0] le 5」という単一の要素があるとします。 。これは、データベースクエリ「SELECTとルーティングコストWHEREホップカウント<= 5を提供する」と同等です。
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-制約」パラメーターと同等であることに注意してください。
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-constraints：JSONStringsのJSONArraysのJSONArray。各文字列は、上記で定義した拡張制約述語です。 「or-constraint」テストは、述語の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.
このパラメーターは、このリソースの「max-cost-types」機能が0より大きい値で定義されている場合（セクション4.1.1）、リソースが制約テストを許可する場合（リソースの「cost-constraints」機能がtrueである場合）、または「testable-cost-type-names」機能は空ではありません）。それ以外の場合、このパラメーターを指定してはなりません（MUST NOT）。
This parameter MUST NOT be specified if the "constraints" parameter is specified.
「制約」パラメーターが指定されている場合、このパラメーターを指定してはなりません（MUST NOT）。
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.
このパラメーターには、AND述部の空の配列を含めてはなりません。空の配列は、常に真である制約と同等です。このような制約を含む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)".
例として、「multi-cost-types」に「routingcost」と「bandwidthscore」の2つの要素があり、「testable-cost-types」に「routingcost」と「hopcount」の2つの要素があり、「or-constraints」に2つの要素["[0] le 100"、 "[1] le 2"]および["[0] le 10"、 "[1] le 6"]。これは、「SELECTとルーティングコストと帯域幅スコアを提供するWHERE（ "routingcost" <= 100 AND "hopcount" <= 2）OR（ "routingcost" <= 10 AND "hopcount" <= 6）」と同等です。
Note that if the "max-cost-types" capability has a value greater than 0, a Client MAY use the "or-constraints" parameter together with the "cost-type" parameter. That is, if the Client and Server are both aware of the extensions in this document, a Client MAY use an "OR" test for a single-valued cost request.
「max-cost-types」機能の値が0より大きい場合、クライアントは「or-constraints」パラメーターを「cost-type」パラメーターと一緒に使用できます。つまり、クライアントとサーバーの両方がこのドキュメントの拡張を認識している場合、クライアントは単一値のコスト要求に対して「OR」テストを使用できます（MAY）。
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:
クライアントが「cost-type」入力パラメータを指定した場合、応答は[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」の値はレシーバーによって無視され、{}に設定されます。代わりに、フィールド「multi-cost-types」が「multi-cost-types」入力パラメーターと同じ値で追加されます。
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 コストはJSONNumbersではなくJSONArraysです。すべての配列は、「multi-cost-types」入力パラメーターと同じカーディナリティーを持ち、この順序でコストタイプ値を含みます。特定のソースと宛先でコストタイプが使用できない場合、ALTOサーバーはその配列要素にJSONの「null」値を使用する必要があります。特定のソースと宛先で使用できるコストタイプがない場合、ALTOサーバーはそのソースと宛先のエントリを省略できます（MAY）。
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で定義されているように、新しい入力パラメーターと機能を追加し、コスト値としてJSONNumbersではなくJSONArraysを返すことにより、Endpoint Cost Serviceを拡張します。
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).
Endpoint Cost Service機能の拡張は、フィルター済みコストマップの拡張と同じです（セクション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;
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.
multi-cost-types：存在する場合、ALTOサーバーはこのリストのコストタイプの配列値のコストを返さなければなりません（MUST）。エントリごとに、「コストメトリック」および「コストモード」フィールドは、このリソースの「機能」フィールド（セクション4.2.1）に示されているサポートされているコストタイプの1つと一致する必要があります。このリソースの「max-cost-types」機能が存在し、値が0を超えていない限り、クライアントはこのフィールドを使用してはならない（MUST NOT）。このフィールドは、「max-cost-types」以上のコストタイプを持っていてはならない。クライアントは「コストタイプ」または「マルチコストタイプ」のいずれかを指定する必要がありますが、両方を指定してはなりません。
Note that if "multi-cost-types" has one cost type, the values in the cost map will be arrays with one value.
「マルチコストタイプ」に1つのコストタイプがある場合、コストマップの値は1つの値を持つ配列になります。
testable-cost-types, constraints, or-constraints: Defined equivalently to the corresponding input parameters for an extended filtered cost map (Section 4.1.2).
testable-cost-types、constraints、またはconstraints：拡張フィルター済みコストマップの対応する入力パラメーターと同等に定義されます（セクション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:
Endpoint Cost Service応答の拡張は、Filtered Cost Map応答の拡張（セクション4.1.3）に似ています。具体的には、クライアントが「cost-type」入力パラメーターを指定した場合、応答は[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」の値はレシーバーによって無視され、{}に設定されます。代わりに、フィールド「multi-cost-types」が「multi-cost-types」入力パラメーターと同じ値で追加されます。
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 コストはJSONNumbersではなくJSONArraysです。すべての配列は、「multi-cost-types」入力パラメーターと同じカーディナリティーを持ち、この順序でコストタイプ値を含みます。特定のソースと宛先でコストタイプが使用できない場合、ALTOサーバーはその配列要素にJSONの「null」値を使用する必要があります。特定のソースと宛先で使用できるコストタイプがない場合、ALTOサーバーはそのソースと宛先のエントリを省略できます（MAY）。
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サーバーの情報リソースディレクトリの例です。ネットワークとコストマップのリソースに加えて、2つのフィルターされたコストマップとエンドポイントコストサービスを定義します。これらはすべてマルチコスト拡張を理解します。
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
{
"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" ]
}
}
}
}
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」の2つのコストタイプを提供します。どちらも「数値」モードです。クライアントはマルチコストマップ全体を求めています。サーバーは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
{
"multi-cost-types": [
{"cost-mode": "numerical", "cost-metric": "routingcost"},
{"cost-mode": "numerical", "cost-metric": "shoesize"}
],
"pids" : {
"srcs" : [ ],
"dsts" : [ ]
}
}
HTTP/1.1 200 OK
Content-Type: application/alto-costmap+json
Content-Length: 549
{
"meta" : {
"dependent-vtags" : [
{"resource-id": "my-default-network-map",
"tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e"
}
],
"cost-type" : {},
"multi-cost-types" : [
{"cost-mode": "numerical", "cost-metric": "routingcost"},
{"cost-mode": "numerical", "cost-metric": "shoesize"}
]
}
"cost-map" : {
"PID1": { "PID1":[1,0], "PID2":[4,3], "PID3":[10,2] },
"PID2": { "PID1":[15,5], "PID2":[1,0], "PID3":[null,9] },
"PID3": { "PID1":[20,12], "PID2":[null,1], "PID3":[1,0] }
}
}
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ペアを5〜10の「ルーティングコスト」または0に等しい「靴のサイズ」を持つペアに制限しています。
POST /multi/costmap/filtered HTTP/1.1
Host: alto.example.com
Accept: application/alto-costmap+json,application/alto-error+json
Content-Type: application/alto-costmapfilter+json
Content-Length: 333
{
"multi-cost-types" : [
{"cost-mode": "numerical", "cost-metric": "routingcost"},
{"cost-mode": "numerical", "cost-metric": "shoesize"}
],
"or-constraints" : [ ["[0] ge 5", "[0] le 10"],
["[1] eq 0"] ]
"pids" : {
"srcs" : [ "PID1", "PID2" ],
"dsts" : [ "PID1", "PID2", "PID3" ]
}
}
HTTP/1.1 200 OK
Content-Type: application/alto-costmap+json
Content-Length: 461
{
"meta" : {
"dependent-vtags" : [
{"resource-id": "my-default-network-map",
"tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e"
}
],
"cost-type" : {},
"multi-cost-types" : [
{"cost-mode": "numerical", "cost-metric": "routingcost"},
{"cost-mode": "numerical", "cost-metric": "shoesize"}
]
}
"cost-map" : {
"PID1": { "PID1": [1,0], "PID3": [10,5] },
"PID2": { "PID2": [1,0] }
}
}
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 AND "shoesize" <= 2）またはOR（ "routingcost" <= 3 AND "shoesize" <= 6）でコストポイントへの応答を制限します。前の例とは異なり、クライアントは「routingcost」コストタイプのみに関心があり、「multi-cost-types」ではなく「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]」は、「testable-cost-types」パラメーターの最初のコストタイプであるため、「routingcost」に制約が適用されることを意味します。 （「testable-cost-types」が省略された場合、「multi-cost-types」と同じであると見なされます。）コストタイプを参照するためにインデックスを使用するという選択は、制約の式の長さを最小化することを目的としています、特に複数のORおよびAND式を組み合わせる場合。 [RFC7285]の制約設計からの最短経路でもありました。
POST /multi/multicostmap/filtered HTTP/1.1
Host: alto.example.com
Accept: application/alto-costmap+json,application/alto-error+json
Content-Type: application/alto-costmapfilter+json
Content-Length: 390
{
"cost-type" : {
"cost-mode": "numerical", "cost-metric": "routingcost"
},
"testable-cost-types" : [
{"cost-mode": "numerical", "cost-metric": "routingcost"},
{"cost-mode": "numerical", "cost-metric": "shoesize"}
],
"or-constraints": [
["[0] le 10", "[1] le 2"],
["[0] le 3", "[1] le 6"]
],
"pids" : {
"srcs" : [ ],
"dsts" : [ ]
}
}
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 }
}
}
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 AND "shoesize" <= 2）またはOR（ "routingcost" <= 3 AND "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
{
"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" : [ ]
}
}
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] }
}
}
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).
この例では、Endpoint Cost Serviceを使用して、選択したエンドポイントの「routingcost」と「shoesize」を取得し、低い「shoesize」と妥当な「routingcost」（「shoesize」<= 2 AND「routingcost」<= 10）または、それ以外の場合は、「ルーティングコスト」が低く、妥当な「靴のサイズ」（「ルーティングコスト」<= 3 AND「靴のサイズ」<= 6）。
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
{
"multi-cost-types" : [
{"cost-mode": "numerical", "cost-metric": "routingcost"},
{"cost-mode": "numerical", "cost-metric": "shoesize"}
],
"or-constraints": [
["[0] le 10", "[1] le 2"],
["[0] le 3", "[1] le 6"]
],
"endpoints" : {
"srcs": [ "ipv4:192.0.2.2", "ipv6:2001:db8::1:0 ],
"dsts": [
"ipv4:192.0.2.89",
"ipv4:198.51.100.34",
"ipv4:203.0.113.45",
"ipv6:2001:db8::10"
]
}
}
HTTP/1.1 200 OK
Content-Length: 419
Content-Type: application/alto-endpointcost+json
{
"meta" : {
"multi-cost-types" : [
{"cost-mode": "numerical", "cost-metric": "routingcost"},
{"cost-mode": "numerical", "cost-metric": "shoesize"}
]
}
"endpoint-cost-map" : {
"ipv4:192.0.2.2": {
"ipv4:192.0.2.89": [15, 5],
"ipv4:203.0.113.45": [4, 23]
}
"ipv6:2001:db8::1:0": {
"ipv4:198.51.100.34": [16, 5],
"ipv6:2001:db8::10": [10, 2]
}
}
}
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]アリミ、R。、エド、ペンノ、R。、エド、ヤン、Y。、エド、キーゼル、S。、プレビディ、S。、ルーム、W。、シャルノフ、S.、R。 Woundy、「Application-Layer Traffic Optimization（ALTO）Protocol」、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]ブレイ、T。、編、「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に感謝します。 Gao Kai、Hans Seidel、Richard Yang、Qiao Xiang、Wang Xinは、プロトコル設計に実質的なレビューフィードバックと提案を提供しました。
Authors' Addresses
著者のアドレス
Sabine Randriamasy Nokia Bell Labs Route de Villejust Nozay 91460 France
Sabine Randriamasy Nokia Bell Labs Route de Villejust Nozay 91460フランス
Email: Sabine.Randriamasy@nokia-bell-labs.com
Wendy Roome Nokia Bell Labs 124 Burlington Rd Murray Hill, NJ 07974 United States of America
ウェンディルームノキアベルラボ124バーリントンロードマレーヒル、ニュージャージー07974アメリカ合衆国
Email: ietf@wdroome.com
Nico Schwan Thales Deutschland Lorenzstrasse 10 Stuttgart 70435 Germany
ニコシュヴァンタレスドイツLorenzstrasse 10シュトゥットガルト70435ドイツ
Email: nico.schwan@thalesgroup.com