[要約] RFC 7285は、ALTOプロトコルに関する標準仕様であり、アプリケーションレベルのトラフィック最適化を目的としています。ALTOプロトコルは、ネットワーク内のリソース情報を提供し、アプリケーションが最適なネットワーク経路を選択するための支援をします。
Internet Engineering Task Force (IETF) R. Alimi, Ed.
Request for Comments: 7285 Google
Category: Standards Track R. Penno, Ed.
ISSN: 2070-1721 Cisco Systems, Inc.
Y. Yang, Ed.
Yale University
S. Kiesel
University of Stuttgart
S. Previdi
Cisco Systems, Inc.
W. Roome
Alcatel-Lucent
S. Shalunov
Open Garden
R. Woundy
Comcast
September 2014
Application-Layer Traffic Optimization (ALTO) Protocol
アプリケーション層トラフィック最適化（ALTO）プロトコル
Abstract
概要
Applications using the Internet already have access to some topology information of Internet Service Provider (ISP) networks. For example, views to Internet routing tables at Looking Glass servers are available and can be practically downloaded to many network application clients. What is missing is knowledge of the underlying network topologies from the point of view of ISPs. In other words, what an ISP prefers in terms of traffic optimization -- and a way to distribute it.
インターネットを使用するアプリケーションは、すでにインターネットサービスプロバイダー（ISP）ネットワークの一部のトポロジ情報にアクセスできます。たとえば、Looking Glassサーバーのインターネットルーティングテーブルのビューが利用可能であり、実際に多くのネットワークアプリケーションクライアントにダウンロードできます。不足しているのは、ISPの観点からの基礎となるネットワークトポロジの知識です。言い換えれば、トラフィックの最適化に関してISPが好むものと、それを配布する方法です。
The Application-Layer Traffic Optimization (ALTO) services defined in this document provide network information (e.g., basic network location structure and preferences of network paths) with the goal of modifying network resource consumption patterns while maintaining or improving application performance. The basic information of ALTO is based on abstract maps of a network. These maps provide a simplified view, yet enough information about a network for applications to effectively utilize them. Additional services are built on top of the maps.
このドキュメントで定義されているアプリケーションレイヤートラフィック最適化（ALTO）サービスは、ネットワークリソース情報（基本的なネットワークロケーション構造やネットワークパスの設定など）を提供し、アプリケーションのパフォーマンスを維持または改善しながらネットワークリソースの消費パターンを変更することを目的としています。 ALTOの基本情報は、ネットワークの抽象的なマップに基づいています。これらのマップは簡略化されたビューを提供しますが、アプリケーションがそれらを効果的に利用するためのネットワークに関する十分な情報を提供します。追加のサービスは、マップの上に構築されます。
This document describes a protocol implementing the ALTO services. Although the ALTO services would primarily be provided by ISPs, other entities, such as content service providers, could also provide ALTO services. Applications that could use the ALTO services are those that have a choice to which end points to connect. Examples of such applications are peer-to-peer (P2P) and content delivery networks.
このドキュメントでは、ALTOサービスを実装するプロトコルについて説明します。 ALTOサービスは主にISPによって提供されますが、コンテンツサービスプロバイダーなどの他のエンティティもALTOサービスを提供できます。 ALTOサービスを使用できるアプリケーションは、接続するエンドポイントを選択できるアプリケーションです。このようなアプリケーションの例は、ピアツーピア（P2P）およびコンテンツ配信ネットワークです。
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 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7285.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7285で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................6
1.1. Problem Statement ..........................................6
1.1.1. Requirements Language ...............................7
1.2. Design Overview ............................................7
2. Terminology .....................................................7
2.1. Endpoint ...................................................8
2.2. Endpoint Address ...........................................8
2.3. Network Location ...........................................8
2.4. ALTO Information ...........................................8
2.5. ALTO Information Base ......................................8
3. Architecture ....................................................8
3.1. ALTO Services and Protocol Scope ...........................9
3.2. ALTO Information Reuse and Redistribution .................11
4. ALTO Information Service Framework .............................11
4.1. ALTO Information Services .................................12
4.1.1. Map Service ........................................12
4.1.2. Map-Filtering Service ..............................12
4.1.3. Endpoint Property Service ..........................12
4.1.4. Endpoint Cost Service ..............................13
5. Network Map ....................................................13
5.1. Provider-Defined Identifier (PID) .........................13
5.2. Endpoint Addresses ........................................14
5.3. Example Network Map .......................................14
6. Cost Map .......................................................15
6.1. Cost Types ................................................16
6.1.1. Cost Metric ........................................16
6.1.2. Cost Mode ..........................................17
6.2. Cost Map Structure ........................................18
6.3. Network Map and Cost Map Dependency .......................18
6.4. Cost Map Update ...........................................19
7. Endpoint Properties ............................................19
7.1. Endpoint Property Type ....................................19
7.1.1. Endpoint Property Type: pid ........................19
8. Protocol Specification: General Processing .....................19
8.1. Overall Design ............................................19
8.2. Notation ..................................................20
8.3. Basic Operations ..........................................21
8.3.1. Client Discovering Information Resources ...........21
8.3.2. Client Requesting Information Resources ............22
8.3.3. Server Responding to Information Resource Request ..22
8.3.4. Client Handling Server Response ....................23
8.3.5. Authentication and Encryption ......................23
8.3.6. Information Refreshing .............................24
8.3.7. Parsing of Unknown Fields ..........................24
8.4. Server Response Encoding ..................................24
8.4.1. Meta Information ...................................24
8.4.2. Data Information ...................................25
8.5. Protocol Errors ...........................................25
8.5.1. Media Type .........................................25
8.5.2. Response Format and Error Codes ....................25
8.5.3. Overload Conditions and Server Unavailability ......28
9. Protocol Specification: Information Resource Directory .........28
9.1. Information Resource Attributes ...........................29
9.1.1. Resource ID ........................................29
9.1.2. Media Type .........................................29
9.1.3. Capabilities .......................................29
9.1.4. Accepts Input Parameters ...........................29
9.1.5. Dependent Resources ................................30
9.2. Information Resource Directory (IRD) ......................30
9.2.1. Media Type .........................................30
9.2.2. Encoding ...........................................30
9.2.3. Example ............................................32
9.2.4. Delegation Using IRD ...............................35
9.2.5. Considerations of Using IRD ........................37
10. Protocol Specification: Basic Data Types ......................38
10.1. PID Name .................................................38
10.2. Resource ID ..............................................38
10.3. Version Tag ..............................................38
10.4. Endpoints ................................................39
10.4.1. Typed Endpoint Addresses ..........................39
10.4.2. Address Type ......................................39
10.4.3. Endpoint Address ..................................40
10.4.4. Endpoint Prefixes .................................40
10.4.5. Endpoint Address Group ............................41
10.5. Cost Mode ................................................41
10.6. Cost Metric ..............................................42
10.7. Cost Type ................................................42
10.8. Endpoint Property ........................................42
10.8.1. Resource-Specific Endpoint Properties .............43
10.8.2. Global Endpoint Properties ........................43
11. Protocol Specification: Service Information Resources .........43
11.1. Meta Information .........................................43
11.2. Map Service ..............................................43
11.2.1. Network Map .......................................44
11.2.2. Mapping IP Addresses to PIDs for
'ipv4'/'ipv6' Network Maps ........................46
11.2.3. Cost Map ..........................................47
11.3. Map-Filtering Service ....................................50
11.3.1. Filtered Network Map ..............................50
11.3.2. Filtered Cost Map .................................53
11.4. Endpoint Property Service ................................57
11.4.1. Endpoint Property .................................58
11.5. Endpoint Cost Service ....................................61
11.5.1. Endpoint Cost .....................................61
12. Use Cases .....................................................64
12.1. ALTO Client Embedded in P2P Tracker ......................65
12.2. ALTO Client Embedded in P2P Client: Numerical Costs ......66
12.3. ALTO Client Embedded in P2P Client: Ranking ..............67
13. Discussions ...................................................68
13.1. Discovery ................................................68
13.2. Hosts with Multiple Endpoint Addresses ...................68
13.3. Network Address Translation Considerations ...............69
13.4. Endpoint and Path Properties .............................69
14. IANA Considerations ...........................................70
14.1. application/alto-* Media Types ...........................70
14.2. ALTO Cost Metric Registry ................................71
14.3. ALTO Endpoint Property Type Registry .....................73
14.4. ALTO Address Type Registry ...............................75
14.5. ALTO Error Code Registry .................................76
15. Security Considerations .......................................76
15.1. Authenticity and Integrity of ALTO Information ...........77
15.1.1. Risk Scenarios ....................................77
15.1.2. Protection Strategies .............................77
15.1.3. Limitations .......................................77
15.2. Potential Undesirable Guidance from Authenticated ALTO
Information ..............................................78
15.2.1. Risk Scenarios ....................................78
15.2.2. Protection Strategies .............................78
15.3. Confidentiality of ALTO Information ......................79
15.3.1. Risk Scenarios ....................................79
15.3.2. Protection Strategies .............................79
15.3.3. Limitations .......................................80
15.4. Privacy for ALTO Users ...................................80
15.4.1. Risk Scenarios ....................................80
15.4.2. Protection Strategies .............................80
15.5. Availability of ALTO Services ............................81
15.5.1. Risk Scenarios ....................................81
15.5.2. Protection Strategies .............................81
16. Manageability Considerations ..................................81
16.1. Operations ...............................................82
16.1.1. Installation and Initial Setup ....................82
16.1.2. Migration Path ....................................82
16.1.3. Dependencies on Other Protocols and
Functional Components .............................83
16.1.4. Impact and Observation on Network Operation .......83
16.2. Management ...............................................84
16.2.1. Management Interoperability .......................84
16.2.2. Management Information ............................84
16.2.3. Fault Management ..................................84
16.2.4. Configuration Management ..........................84
16.2.5. Performance Management ............................85
16.2.6. Security Management ...............................85
17. References ....................................................85
17.1. Normative References .....................................85
17.2. Informative References ...................................86
Appendix A. Acknowledgments .......................................89
Appendix B. Design History and Merged Proposals ...................90
This document defines the ALTO Protocol, which provides a solution for the problem stated in [RFC5693]. Specifically, in today's networks, network information such as network topologies, link availability, routing policies, and path costs are hidden from the application layer, and many applications benefited from such hiding of network complexity. However, new applications, such as application-layer overlays, can benefit from information about the underlying network infrastructure. In particular, these new network applications can be adaptive; hence, they can become more network efficient (e.g., reduce network resource consumption) and achieve better application performance (e.g., accelerated download rate), by leveraging network-provided information.
このドキュメントは、[RFC5693]で述べられている問題の解決策を提供するALTOプロトコルを定義しています。具体的には、今日のネットワークでは、ネットワークトポロジ、リンクの可用性、ルーティングポリシー、パスコストなどのネットワーク情報はアプリケーションレイヤーから隠されており、多くのアプリケーションはこのようなネットワークの複雑さの隠蔽から恩恵を受けています。ただし、アプリケーションレイヤーオーバーレイなどの新しいアプリケーションは、基盤となるネットワークインフラストラクチャに関する情報を活用できます。特に、これらの新しいネットワークアプリケーションは適応可能です。したがって、ネットワークから提供される情報を活用することで、ネットワークの効率を高め（ネットワークリソースの消費量を削減するなど）、アプリケーションのパフォーマンスを向上させることができます（ダウンロード速度の加速など）。
At a high level, the ALTO Protocol specified in this document is an information-publishing interface that allows a network to publish its network information such as network locations, costs between them at configurable granularities, and endhost properties to network applications. The information published by the ALTO Protocol should benefit both the network and the applications (i.e., the consumers of the information). Either the operator of the network or a third party (e.g., an information aggregator) can retrieve or derive related information of the network and publish it using the ALTO Protocol.
高レベルでは、このドキュメントで指定されているALTOプロトコルは、ネットワークがネットワークの場所、構成可能な粒度でのネットワーク間のコスト、ネットワークアプリケーションへのエンドホストプロパティなどのネットワーク情報を公開できるようにする情報公開インターフェイスです。 ALTOプロトコルによって公開された情報は、ネットワークとアプリケーション（つまり、情報の利用者）の両方に利益をもたらすはずです。ネットワークのオペレーターまたはサードパーティ（情報アグリゲーターなど）のいずれかが、ネットワークの関連情報を取得または取得し、ALTOプロトコルを使用して公開できます。
To allow better understanding of the goal of the ALTO Protocol, this document provides a short, non-normative overview of the benefits of ALTO to both networks and applications:
ALTOプロトコルの目標をよりよく理解できるようにするために、このドキュメントでは、ネットワークとアプリケーションの両方に対するALTOの利点について、規範的ではない短い概要を提供します。
o A network that provides ALTO information can achieve better utilization of its networking infrastructure. For example, by using ALTO as a tool to interact with applications, a network is able to provide network information to applications so that the applications can better manage traffic on more expensive or difficult-to-provision links such as long-distance, transit, or backup links. During the interaction, the network can choose to protect its sensitive and confidential network state information, by abstracting real metric values into non-real numerical scores or ordinal ranking.
o ALTO情報を提供するネットワークは、ネットワークインフラストラクチャの利用率を向上させることができます。たとえば、ALTOをアプリケーションと対話するためのツールとして使用することにより、ネットワークはアプリケーションにネットワーク情報を提供できるため、アプリケーションは長距離、トランジットなどのより高価な、またはプロビジョニングが困難なリンク上のトラフィックをより適切に管理できます。またはバックアップリンク。相互作用中に、ネットワークは、実際のメトリック値を非実際の数値スコアまたは序数ランキングに抽象化することにより、機密性の高い機密ネットワーク状態情報を保護することを選択できます。
o An application that uses ALTO information can benefit from better knowledge of the network to avoid network bottlenecks. For example, an overlay application can use information provided by the ALTO services to avoid selecting peers connected via high-delay links (e.g., some intercontinental links). Using ALTO to initialize each node with promising ("better-than-random") peers, an adaptive peer-to-peer overlay may achieve faster, better convergence.
o ALTO情報を使用するアプリケーションは、ネットワークのボトルネックを回避するために、ネットワークのより良い知識から利益を得ることができます。たとえば、オーバーレイアプリケーションは、ALTOサービスによって提供される情報を使用して、高遅延リンク（一部の大陸間リンクなど）を介して接続されたピアの選択を回避できます。 ALTOを使用して、有望な（「ランダムよりも良い」）ピアで各ノードを初期化すると、アダプティブピアツーピアオーバーレイによって、より速く、より優れた収束を実現できます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
The ALTO Protocol specified in this document meets the ALTO requirements specified in [RFC5693], and unifies multiple protocols previously designed with similar intentions. See Appendix A for a list of people and Appendix B for a list of proposals that have made significant contributions to this effort.
このドキュメントで指定されたALTOプロトコルは、[RFC5693]で指定されたALTO要件を満たし、以前に同様の意図で設計された複数のプロトコルを統合します。人のリストについては付録Aを、この取り組みに多大な貢献をした提案のリストについては付録Bを参照してください。
The ALTO Protocol uses a REST-ful (Representational State Transfer (REST)) design [Fielding-Thesis], and encodes its requests and responses using JSON [RFC7159]. These designs are chosen because of their flexibility and extensibility. In addition, these designs make it possible for ALTO to be deployed at scale by leveraging existing HTTP [RFC7230] implementations, infrastructures and deployment experience.
ALTOプロトコルはREST-ful（Representational State Transfer（REST））設計[Fielding-Thesis]を使用し、JSON [RFC7159]を使用して要求と応答をエンコードします。これらの設計は、柔軟性と拡張性のために選択されています。さらに、これらの設計により、既存のHTTP [RFC7230]の実装、インフラストラクチャ、および展開の経験を活用して、ALTOを大規模に展開することができます。
The ALTO Protocol uses a modular design by dividing ALTO information publication into multiple ALTO services (e.g., the Map service, the Map-Filtering Service, the Endpoint Property Service, and the Endpoint Cost Service). Each ALTO service provides a given set of functionalities and is realized by a set of information resources, which are announced by information resource directories, to guide ALTO clients.
ALTOプロトコルは、ALTO情報の公開を複数のALTOサービス（マップサービス、マップフィルターサービス、エンドポイントプロパティサービス、エンドポイントコストサービスなど）に分割することにより、モジュール設計を使用します。各ALTOサービスは、所定の機能セットを提供し、ALTOクライアントをガイドするために情報リソースディレクトリによってアナウンスされる情報リソースのセットによって実現されます。
This document uses the following terms defined in [RFC5693]: Application, Overlay Network, Peer, Resource, Resource Identifier, Resource Provider, Resource Consumer, Resource Directory, Transport Address, ALTO Server, ALTO Client, ALTO Query, ALTO Response, ALTO Transaction, Local Traffic, Peering Traffic, and Transit Traffic.
このドキュメントでは、[RFC5693]で定義されている次の用語を使用します：アプリケーション、オーバーレイネットワーク、ピア、リソース、リソース識別子、リソースプロバイダー、リソースコンシューマー、リソースディレクトリ、トランスポートアドレス、ALTOサーバー、ALTOクライアント、ALTOクエリ、ALTO応答、ALTOトランザクション、ローカルトラフィック、ピアリングトラフィック、および通過トラフィック。
This document extends the term "ALTO Service" defined in [RFC5693]. In particular, by adopting a modular design, this document allows the ALTO Protocol to provide multiple ALTO services.
このドキュメントは、[RFC5693]で定義されている「ALTOサービス」という用語を拡張したものです。特に、このドキュメントでは、モジュール式の設計を採用することにより、ALTOプロトコルで複数のALTOサービスを提供できるようにしています。
This document also uses the following additional terms: Endpoint Address, Network Location, ALTO Information, and ALTO Information Base.
このドキュメントでは、エンドポイントアドレス、ネットワークロケーション、ALTO情報、およびALTO情報ベースという追加の用語も使用しています。
An endpoint is an application or host that is capable of communicating (sending and/or receiving messages) on a network.
エンドポイントは、ネットワーク上で通信（メッセージの送信や受信）が可能なアプリケーションまたはホストです。
An endpoint is typically either a resource provider or a resource consumer.
エンドポイントは通常、リソースプロバイダーまたはリソースコンシューマーです。
An endpoint address represents the communication address of an endpoint. Common forms of endpoint addresses include IP addresses, Media Access Control (MAC) addresses, and overlay IDs. An endpoint address can be network-attachment based (e.g., IP address) or network-attachment agnostic (e.g., MAC address).
エンドポイントアドレスは、エンドポイントの通信アドレスを表します。エンドポイントアドレスの一般的な形式には、IPアドレス、メディアアクセス制御（MAC）アドレス、およびオーバーレイIDが含まれます。エンドポイントアドレスは、ネットワーク接続ベース（IPアドレスなど）またはネットワーク接続不可（MACアドレスなど）にすることができます。
Each endpoint address has an associated address type, which indicates both its syntax and semantics.
各エンドポイントアドレスには、構文とセマンティクスの両方を示すアドレスタイプが関連付けられています。
This document uses network location as a generic term to denote a single endpoint or a group of endpoints. For instance, it can be a single IPv4 or IPv6 address, an IPv4 or IPv6 prefix, or a set of prefixes.
このドキュメントでは、単一のエンドポイントまたはエンドポイントのグループを示す一般的な用語としてネットワークロケーションを使用しています。たとえば、単一のIPv4またはIPv6アドレス、IPv4またはIPv6プレフィックス、または一連のプレフィックスを使用できます。
This document uses ALTO information as a generic term to refer to the network information provided by an ALTO server.
このドキュメントでは、ALTOサーバーから提供されるネットワーク情報を指す総称としてALTO情報を使用しています。
This document uses the term ALTO information base to refer to the internal representation of ALTO information maintained by an ALTO server. Note that the structure of this internal representation is not defined by this document.
このドキュメントでは、ALTO情報ベースという用語を使用して、ALTOサーバーによって維持されるALTO情報の内部表現を指します。この内部表現の構造は、このドキュメントでは定義されていないことに注意してください。
This section defines the ALTO architecture and the ALTO Protocol's place in the overall architecture.
このセクションでは、ALTOアーキテクチャと、アーキテクチャ全体におけるALTOプロトコルの位置を定義します。
Each network region in the global Internet can provide its ALTO services, which convey network information from the perspective of that network region. A network region in this context can be an Autonomous System (AS), an ISP, a region smaller than an AS or ISP, or a set of ISPs. The specific network region that an ALTO service represents will depend on the ALTO deployment scenario and ALTO service discovery mechanism.
グローバルインターネットの各ネットワーク地域は、そのネットワーク地域の観点からネットワーク情報を伝達するALTOサービスを提供できます。このコンテキストのネットワーク地域は、自律システム（AS）、ISP、ASまたはISPよりも小さな地域、またはISPのセットにすることができます。 ALTOサービスが表す特定のネットワーク地域は、ALTO展開シナリオとALTOサービス検出メカニズムによって異なります。
The ALTO services specified in this document define network endpoints (and aggregations thereof) and generic costs amongst them from the region's perspective. The network endpoints may include all endpoints in the global Internet. We say that the network information provided by the ALTO services of a network region represents the "my-Internet view" of the network region.
このドキュメントで指定されているALTOサービスは、地域の観点から、ネットワークエンドポイント（およびその集約）とそれらの間の一般的なコストを定義します。ネットワークエンドポイントには、グローバルインターネット内のすべてのエンドポイントが含まれる場合があります。ネットワーク地域のALTOサービスによって提供されるネットワーク情報は、ネットワーク地域の「マイインターネットビュー」を表すと言います。
The "my-Internet view" defined in this document does not specify the internal topology of a network, and hence, it is said to provide a "single-node" abstract topology. Extensions to this document may provide topology details in "my-Internet view".
このドキュメントで定義されている「my-Internetビュー」は、ネットワークの内部トポロジを指定していないため、「単一ノード」の抽象的なトポロジを提供すると言われています。このドキュメントの拡張により、「my-Internetビュー」でトポロジの詳細が提供される場合があります。
Figure 1 provides an overall picture of ALTO's system architecture, so that one can better understand the ALTO services and the role of the ALTO Protocol. In this architecture, an ALTO server prepares ALTO information, an ALTO client uses ALTO service discovery to identify an appropriate ALTO server, and the ALTO client requests available ALTO information from the ALTO server using the ALTO Protocol.
図1に、ALTOのシステムアーキテクチャの全体像を示します。これにより、ALTOサービスとALTOプロトコルの役割をよりよく理解できます。このアーキテクチャでは、ALTOサーバーはALTO情報を準備し、ALTOクライアントはALTOサービス検出を使用して適切なALTOサーバーを識別し、ALTOクライアントはALTOプロトコルを使用してALTOサーバーから利用可能なALTO情報を要求します。
The ALTO information provided by the ALTO server can be updated dynamically based on network conditions, or they can be seen as a policy that is updated on a longer time scale.
ALTOサーバーによって提供されるALTO情報は、ネットワークの状態に基づいて動的に更新することも、より長い時間スケールで更新されるポリシーと見なすこともできます。
+-------------------------------------------------------------------+
| Network Region |
| |
| +-----------+ |
| | Routing | |
| +--------------+ | Protocols | |
| | Provisioning | +-----------+ |
| | Policy | | |
| +--------------+\ | |
| \ | |
| \ | |
| +-----------+ \+---------+ +--------+ |
| |Dynamic | | ALTO | ALTO Protocol | ALTO | |
| |Network |.......| Server | ==================== | Client | |
| |Information| +---------+ +--------+ |
| +-----------+ / / |
| / ALTO SD Query/Response / |
| / / |
| +----------+ +----------------+ |
| | External | | ALTO Service | |
| | Interface| | Discovery (SD) | |
| +----------+ +----------------+ |
| | |
+-------------------------------------------------------------------+
|
+------------------+
| Third Parties |
| |
| Content Providers|
+------------------+
Figure 1: Basic ALTO Architecture
図1：基本的なALTOアーキテクチャ
Figure 1 illustrates that the ALTO information provided by an ALTO server may be influenced (at the service provider's discretion) by other systems. In particular, the ALTO server can aggregate information from multiple systems to provide an abstract and unified view that can be more useful to applications. Examples of other systems include (but are not limited to) static network configuration databases, dynamic network information, routing protocols, provisioning policies, and interfaces to outside parties. These components are shown in the figure for completeness but are outside the scope of this specification. Recall that while the ALTO Protocol may convey dynamic network information, it is not intended to replace near-real-time congestion control protocols.
図1は、ALTOサーバーによって提供されるALTO情報が他のシステムによって（サービスプロバイダーの裁量で）影響を受ける可能性があることを示しています。特に、ALTOサーバーは複数のシステムからの情報を集約して、アプリケーションにとってより有用な抽象的で統一されたビューを提供できます。その他のシステムの例には、静的ネットワーク構成データベース、動的ネットワーク情報、ルーティングプロトコル、プロビジョニングポリシー、および外部関係者へのインターフェイスが含まれます（これらに限定されません）。これらのコンポーネントは、完全を期すために図に示されていますが、この仕様の範囲外です。 ALTOプロトコルは動的なネットワーク情報を伝達する可能性がありますが、ほぼリアルタイムの輻輳制御プロトコルに代わるものではないことを思い出してください。
It may also be possible for an ALTO server to exchange network information with other ALTO servers (either within the same administrative domain or another administrative domain with the consent of both parties) in order to adjust exported ALTO information. Such a protocol is also outside the scope of this specification.
また、ALTOサーバーは、エクスポートされたALTO情報を調整するために、ネットワーク情報を他のALTOサーバー（同じ管理ドメイン内または両当事者の同意を得た別の管理ドメイン内）と交換することもできます。このようなプロトコルも、この仕様の範囲外です。
ALTO information may be useful to a large number of applications and users. At the same time, distributing ALTO information must be efficient and not become a bottleneck.
ALTO情報は、多数のアプリケーションとユーザーに役立つ場合があります。同時に、ALTO情報の配布は効率的で、ボトルネックにならないようにする必要があります。
The design of the ALTO Protocol allows integration with the existing HTTP caching infrastructure to redistribute ALTO information. If caching or redistribution is used, the response message to an ALTO client may be returned from a third party.
ALTOプロトコルの設計により、既存のHTTPキャッシングインフラストラクチャと統合して、ALTO情報を再配布できます。キャッシングまたは再配布が使用されている場合、ALTOクライアントへの応答メッセージはサードパーティから返される場合があります。
Application-dependent mechanisms, such as P2P Distributed Hash Tables (DHTs) or P2P file sharing, may be used to cache and redistribute ALTO information. This document does not define particular mechanisms for such redistribution.
P2P分散ハッシュテーブル（DHT）またはP2Pファイル共有などのアプリケーション依存のメカニズムを使用して、ALTO情報をキャッシュおよび再配布できます。このドキュメントでは、そのような再配布のための特定のメカニズムを定義していません。
Additional protocol mechanisms (e.g., expiration times and digital signatures for returned ALTO information) are left for future investigation.
追加のプロトコルメカニズム（有効期限や返されたALTO情報のデジタル署名など）は、今後の調査のために残されています。
The ALTO Protocol conveys network information through ALTO information services (services for short), where each service defines a set of related functionalities. An ALTO client can request each service individually. All of the services defined in ALTO are said to form the ALTO service framework and are provided through a common transport protocol; messaging structure and encoding; and transaction model. Functionalities offered in different services can overlap.
ALTOプロトコルは、ALTO情報サービス（略してサービス）を介してネットワーク情報を伝達します。各サービスは、関連する機能のセットを定義します。 ALTOクライアントは、各サービスを個別に要求できます。 ALTOで定義されているすべてのサービスは、ALTOサービスフレームワークを形成すると言われ、共通のトランスポートプロトコルを通じて提供されます。メッセージング構造とエンコーディング。とトランザクションモデル。異なるサービスで提供される機能は重複する場合があります。
The goals of the ALTO information services defined in this document are to convey (1) network locations, which denote the locations of endpoints at a network, (2) provider-defined costs for paths between pairs of network locations, and (3) network-related properties of endpoints. The aforementioned goals are achieved by defining the Map Service, which provides the core ALTO information to clients, and three additional information services: the Map-Filtering Service, the Endpoint Property Service (EPS), and the Endpoint Cost Service (ECS). Additional information services can be defined in companion documents. Figure 2 gives an overview of the information services. Details of the services are presented in subsequent sections.
このドキュメントで定義されているALTO情報サービスの目的は、（1）ネットワークのエンドポイントの場所を示すネットワークロケーション、（2）プロバイダーが定義したネットワークロケーションのペア間のパスのコスト、および（3）ネットワークを伝達することです。エンドポイントの関連プロパティ。前述の目標は、コアALTO情報をクライアントに提供するマップサービスと、マップフィルタリングサービス、エンドポイントプロパティサービス（EPS）、およびエンドポイントコストサービス（ECS）の3つの追加情報サービスを定義することで達成されます。追加の情報サービスは、関連ドキュメントで定義できます。図2は、情報サービスの概要を示しています。サービスの詳細については、後続のセクションで説明します。
.-----------------------------------------.
| ALTO Information Services |
| .-----------. .----------. .----------. |
| | Map- | | Endpoint | | Endpoint | |
| | Filtering | | Property | | Cost | |
| | Service | | Service | | Service | |
| `-----------' `----------' `----------' |
| .-------------------------------------. |
| | Map Service | |
| | .-------------. .--------------. | |
| | | Network Map | | Cost Map | | |
| | `-------------' `--------------' | |
| `-------------------------------------' |
`-----------------------------------------'
Figure 2: ALTO Information Service Framework
図2：ALTO情報サービスフレームワーク
The Map Service provides batch information to ALTO clients in the forms of ALTO network maps (network maps for short) and ALTO cost maps (cost maps for short). An ALTO network map (See Section 5) provides a full set of network location groupings defined by the ALTO server and the endpoints contained within each grouping. An ALTO cost map (see Section 6) provides costs between defined groupings.
マップサービスは、ALTOクライアントに、ALTOネットワークマップ（略してネットワークマップ）およびALTOコストマップ（略してコストマップ）の形式でバッチ情報を提供します。 ALTOネットワークマップ（セクション5を参照）は、ALTOサーバーと各グループ内に含まれるエンドポイントによって定義されたネットワークロケーショングループの完全なセットを提供します。 ALTOコストマップ（セクション6を参照）は、定義されたグループ間のコストを提供します。
These two maps can be thought of (and implemented) as simple files with appropriate encoding provided by the ALTO server.
これらの2つのマップは、ALTOサーバーによって提供される適切なエンコーディングを備えた単純なファイルと見なす（および実装する）ことができます。
Resource-constrained ALTO clients may benefit from the filtering of query results at the ALTO server. This avoids the situation in which an ALTO client first spends network bandwidth and CPU cycles to collect results and then performs client-side filtering. The Map-Filtering Service allows ALTO clients to query an ALTO server on ALTO network maps and/or cost maps based on additional parameters.
リソースに制約のあるALTOクライアントは、ALTOサーバーでのクエリ結果のフィルタリングからメリットを得ることができます。これにより、ALTOクライアントが最初にネットワーク帯域幅とCPUサイクルを費やして結果を収集し、次にクライアント側のフィルタリングを実行する状況が回避されます。 Map-Filtering Serviceを使用すると、ALTOクライアントは、追加のパラメーターに基づいて、ALTOネットワークマップまたはコストマップ、あるいはその両方のALTOサーバーにクエリを実行できます。
This service allows ALTO clients to look up properties for individual endpoints. An example property of an endpoint is its network location (i.e., its grouping defined by the ALTO server). Another example property is its connectivity type such as ADSL (Asymmetric Digital Subscriber Line), Cable, or FTTH (Fiber To The Home).
このサービスにより、ALTOクライアントは個々のエンドポイントのプロパティを検索できます。エンドポイントのプロパティの例は、そのネットワークの場所（つまり、ALTOサーバーによって定義されたグループ）です。プロパティのもう1つの例は、ADSL（非対称デジタル加入者線）、ケーブル、FTTH（ファイバートゥザホーム）などの接続タイプです。
Some ALTO clients may also benefit from querying for costs and rankings based on endpoints. The Endpoint Cost Service allows an ALTO server to return costs directly amongst endpoints.
一部のALTOクライアントも、エンドポイントに基づいてコストとランキングをクエリすることでメリットを得られる場合があります。エンドポイントコストサービスにより、ALTOサーバーはエンドポイント間で直接コストを返すことができます。
An ALTO network map defines a grouping of network endpoints. This document uses ALTO network map to refer to the syntax and semantics of how an ALTO server defines the grouping. This document does not discuss the internal representation of this data structure within an ALTO server.
ALTOネットワークマップは、ネットワークエンドポイントのグループを定義します。このドキュメントでは、ALTOネットワークマップを使用して、ALTOサーバーがグループ化を定義する方法の構文とセマンティクスを参照します。このドキュメントでは、ALTOサーバー内のこのデータ構造の内部表現については説明しません。
The definition of ALTO network maps is based on the observation that, in reality, many endpoints are near by to one another in terms of network connectivity. By treating a group of nearby endpoints together as a single entity, an ALTO server indicates aggregation of these endpoints due to their proximity. This aggregation can also lead to greater scalability without losing critical information when conveying other network information (e.g., when defining cost maps).
ALTOネットワークマップの定義は、実際には、ネットワーク接続の点で多くのエンドポイントが互いに近いという観察に基づいています。近くのエンドポイントのグループを1つのエンティティとしてまとめて処理することにより、ALTOサーバーは、それらのエンドポイントが近接しているため、これらのエンドポイントの集約を示します。この集約により、他のネットワーク情報を伝達するとき（たとえば、コストマップを定義するとき）に重要な情報を失うことなく、より優れたスケーラビリティを実現できます。
One issue is that proximity varies depending on the granularity of the ALTO information configured by the provider. In one deployment, endpoints on the same subnet may be considered close; while in another deployment, endpoints connected to the same Point of Presence (POP) may be considered close.
1つの問題は、プロバイダーによって構成されたALTO情報の細分性によって近接性が異なることです。 1つの展開では、同じサブネット上のエンドポイントは近いと見なされる場合があります。別の展開では、同じPoint of Presence（POP）に接続されたエンドポイントは、近いと見なされる場合があります。
ALTO introduces provider-defined network location identifiers called Provider-defined Identifiers (PIDs) to provide an indirect and network-agnostic way to specify an aggregation of network endpoints that may be treated similarly, based on network topology, type, or other properties. Specifically, a PID is a string of type PIDName (see Section 10.1) and its associated set of endpoint addresses. As discussed above, there can be many different ways of grouping the endpoints and assigning PIDs. For example, a PID may denote a subnet, a set of subnets, a metropolitan area, a POP, an autonomous system, or a set of autonomous systems. Interpreting the PIDs defined in an ALTO network map using the "single-node" abstraction, one can consider that each PID represents an abstract port (POP) that connects a set of endpoints.
ALTOは、プロバイダー定義の識別子（PID）と呼ばれるプロバイダー定義のネットワークロケーション識別子を導入して、ネットワークトポロジー、タイプ、またはその他のプロパティに基づいて、同様に扱われる可能性のあるネットワークエンドポイントの集約を指定する間接的でネットワークに依存しない方法を提供します。具体的には、PIDはタイプPIDName（セクション10.1を参照）とそれに関連付けられたエンドポイントアドレスのセットの文字列です。上で説明したように、エンドポイントをグループ化してPIDを割り当てるには、さまざまな方法があります。たとえば、PIDは、サブネット、サブネットのセット、大都市圏、POP、自律システム、または自律システムのセットを表す場合があります。 「単一ノード」の抽象化を使用してALTOネットワークマップで定義されたPIDを解釈すると、各PIDが一連のエンドポイントを接続する抽象ポート（POP）を表すと考えることができます。
A key use case of PIDs is to specify network preferences (costs) between PIDs instead of individual endpoints. This allows cost information to be more compactly represented and updated at a faster time scale than the network aggregations themselves. For example, an ISP may prefer that endpoints associated with the same POP in a P2P application communicate locally instead of communicating with endpoints in other POPs. The ISP may aggregate endpoints within a POP into a single PID in a network map. The cost may be encoded to indicate that network locations within the same PID are preferred; for example, cost(PID_i, PID_i) == c and cost(PID_i, PID_j) > c for i != j. Section 6 provides further details on using PIDs to represent costs in an ALTO cost map.
PIDの主な使用例は、個々のエンドポイントではなくPID間のネットワーク設定（コスト）を指定することです。これにより、コスト情報をよりコンパクトに表現し、ネットワーク集約自体よりも速い時間スケールで更新できます。たとえば、ISPは、P2Pアプリケーションの同じPOPに関連付けられたエンドポイントが、他のPOPのエンドポイントと通信するのではなく、ローカルに通信することを優先する場合があります。 ISPは、POP内のエンドポイントをネットワークマップの単一のPIDに集約できます。コストは、同じPID内のネットワークロケーションが優先されることを示すためにエンコードできます。たとえば、cost（PID_i、PID_i）== cおよびcost（PID_i、PID_j）> c for i！= jです。セクション6では、PIDを使用してALTOコストマップでコストを表す方法について詳しく説明します。
The endpoints aggregated into a PID are denoted by endpoint addresses. There are many types of addresses, such as IP addresses, MAC addresses, or overlay IDs. This document specifies (in Section 10.4) how to specify IPv4/IPv6 addresses or prefixes. Extension documents may define further address types; Section 14.4 of this document provides an IANA registry for endpoint address types.
PIDに集約されたエンドポイントは、エンドポイントアドレスで示されます。 IPアドレス、MACアドレス、オーバーレイIDなど、多くの種類のアドレスがあります。このドキュメントでは、（セクション10.4で）IPv4 / IPv6アドレスまたはプレフィックスを指定する方法を指定します。拡張ドキュメントでは、さらにアドレスタイプを定義できます。このドキュメントのセクション14.4は、エンドポイントアドレスタイプのIANAレジストリを提供します。
This document uses the ALTO network map shown in Figure 3 in most examples.
このドキュメントでは、ほとんどの例で図3に示すALTOネットワークマップを使用しています。
.------------------------------------------------------------.
| An ALTO Network Map |
| |
| .-----------------------------------. .----------------. |
| | NetLoc: PID-1 | | NetLoc: PID-3 | |
| | .------------------------------. | | | |
| | | 192.0.2.0/24 | | | .-----------. | |
| | | .--------------------------. | | | | 0.0.0.0/0 | | |
| | | | Endpoint: 192.0.2.34 | | | | `-----------` | |
| | | `--------------------------` | | | | |
| | `------------------------------` | | | |
| | .------------------------------. | | | |
| | | 198.51.100.0/25 | | | | |
| | | .--------------------------. | | | | |
| | | | Endpoint: 198.51.100.100 | | | | | |
| | | `--------------------------` | | | | |
| | `------------------------------` | | | |
| `-----------------------------------` | | |
| | | |
| .-----------------------------------. | | |
| | NetLoc: PID-2 | | | |
| | .------------------------------. | | | |
| | | 198.51.100.128/25 | | | | |
| | `------------------------------` | | | |
| `-----------------------------------` `----------------` |
`------------------------------------------------------------`
Figure 3: Example Network Map
図3：ネットワークマップの例
An ALTO server indicates preferences amongst network locations in the form of path costs. Path costs are generic costs and can be internally computed by a network provider according to its own policy.
ALTOサーバーは、ネットワークロケーション間の設定をパスコストの形式で示します。パスコストは一般的なコストであり、独自のポリシーに従ってネットワークプロバイダーが内部で計算できます。
For a given ALTO network map, an ALTO cost map defines path costs pairwise amongst the set of source and destination network locations defined by the PIDs contained in the network map. Each path cost is the end-to-end cost when a unit of traffic goes from the source to the destination.
特定のALTOネットワークマップについて、ALTOコストマップは、ネットワークマップに含まれるPIDによって定義された送信元および宛先ネットワークロケーションのセット間のパスコストをペアで定義します。各パスコストは、トラフィックのユニットが送信元から宛先に向かうときのエンドツーエンドのコストです。
Since cost is directional from the source to the destination, an application, when using ALTO information, may independently determine how the resource consumer and resource provider are designated as the source or destination in an ALTO query and, hence, how to utilize the path cost provided by ALTO information. For example, if the cost is expected to be correlated with throughput, a typical application concerned with bulk data retrieval may use the resource provider as the source and the resource consumer as the destination.
コストはソースから宛先への方向性があるため、アプリケーションは、ALTO情報を使用するときに、リソースコンシューマーとリソースプロバイダーをALTOクエリでソースまたは宛先として指定する方法、したがってパスコストを利用する方法を個別に決定できます。 ALTO情報によって提供されます。たとえば、コストがスループットと相関すると予想される場合、バルクデータ取得に関連する一般的なアプリケーションでは、リソースプロバイダーをソースとして使用し、リソースコンシューマーを宛先として使用します。
One advantage of separating ALTO information into network maps and cost maps is that the two types of maps can be updated at different time scales. For example, network maps may be stable for a longer time while cost maps may be updated to reflect more dynamic network conditions.
ALTO情報をネットワークマップとコストマップに分離する1つの利点は、2種類のマップを異なる時間スケールで更新できることです。たとえば、ネットワークマップは長期間にわたって安定している可能性がありますが、より動的なネットワーク状態を反映するようにコストマップが更新される場合があります。
As used in this document, an ALTO cost map refers to the syntax and semantics of the information distributed by the ALTO server. This document does not discuss the internal representation of this data structure within the ALTO server.
このドキュメントで使用されているALTOコストマップは、ALTOサーバーによって配布される情報の構文とセマンティクスを指します。このドキュメントでは、ALTOサーバー内のこのデータ構造の内部表現については説明しません。
Path costs have attributes:
パスコストには属性があります。
o Cost Metric: identifies what the costs represent;
o コストメトリック：コストが表すものを識別します。
o Cost Mode: identifies how the costs should be interpreted.
o コストモード：コストの解釈方法を識別します。
The combination of a cost metric and a cost mode defines an ALTO cost type. Certain queries for ALTO cost maps allow the ALTO client to indicate the desired cost type. For a given ALTO server, the combination of cost type and network map defines a key. In other words, an ALTO server MUST NOT define two ALTO cost maps with the same cost type \ network map pair.
コストメトリックとコストモードの組み合わせにより、ALTOコストタイプが定義されます。 ALTOコストマップに対する特定のクエリでは、ALTOクライアントが目的のコストタイプを示すことができます。特定のALTOサーバーの場合、コストタイプとネットワークマップの組み合わせでキーを定義します。つまり、ALTOサーバーは、同じコストタイプとネットワークマップのペアで2つのALTOコストマップを定義してはなりません（MUST NOT）。
The cost metric attribute indicates what the cost represents. For example, an ALTO server could define costs representing air miles, hop-counts, or generic routing costs.
コストメトリック属性は、コストが何を表すかを示します。たとえば、ALTOサーバーは、航空マイル、ホップ数、または一般的なルーティングコストを表すコストを定義できます。
Cost metrics are indicated in protocol messages as strings.
コストメトリックは、プロトコルメッセージで文字列として示されます。
An ALTO server MUST offer the "routingcost" cost metric.
ALTOサーバーは、「routingcost」コストメトリックを提供する必要があります。
This cost metric conveys a generic measure for the cost of routing traffic from a source to a destination. A lower value indicates a higher preference for traffic to be sent from a source to a destination.
このコストメトリックは、送信元から宛先にトラフィックをルーティングするコストの一般的な尺度を示します。値が小さいほど、送信元から宛先に送信されるトラフィックの優先度が高くなります。
Note that an ISP may internally compute routing cost using any method that it chooses (e.g., air miles or hop-count) as long as it conforms to the semantics.
ISPは、セマンティクスに準拠している限り、選択した任意の方法（エアマイルやホップカウントなど）を使用して内部的にルーティングコストを計算する場合があります。
The cost mode attribute indicates how costs should be interpreted. Specifically, the cost mode attribute indicates whether returned costs should be interpreted as numerical values or ordinal rankings.
コストモード属性は、コストの解釈方法を示します。具体的には、コストモード属性は、返されたコストを数値として解釈するか、序数ランキングとして解釈するかを示します。
It is important to communicate such information to ALTO clients, as certain operations may not be valid on certain costs returned by an ALTO server. For example, it is possible for an ALTO server to return a set of IP addresses with costs indicating a ranking of the IP addresses. Arithmetic operations that would make sense for numerical values, do not make sense for ordinal rankings. ALTO clients may handle such costs differently.
ALTOサーバーから返される特定のコストでは特定の操作が無効になる可能性があるため、ALTOクライアントにそのような情報を伝達することが重要です。たとえば、ALTOサーバーが、IPアドレスのランキングを示すコストを持つIPアドレスのセットを返すことが可能です。数値に意味のある算術演算は、序数のランキングには意味がありません。 ALTOクライアントは、このようなコストを異なる方法で処理する場合があります。
Cost modes are indicated in protocol messages as strings.
コストモードは、プロトコルメッセージで文字列として示されます。
An ALTO server MUST support at least one of the following modes: numerical and ordinal. An ALTO client needs to be cognizant of operations when its desired cost mode is not supported. Specifically, an ALTO client desiring numerical costs MAY adjust its behaviors if only the ordinal cost mode is available. Alternatively, an ALTO client desiring ordinal costs MAY construct ordinal costs from retrieved numerical values, if only the numerical cost mode is available.
ALTOサーバーは、数値と序数のモードの少なくとも1つをサポートする必要があります。 ALTOクライアントは、目的のコストモードがサポートされていない場合、操作を認識する必要があります。特に、数値コストを希望するALTOクライアントは、通常のコストモードしか使用できない場合に、その動作を調整する場合があります。あるいは、数値コストモードのみが利用可能な場合、順序コストを希望するALTOクライアントは、取得した数値から順序コストを構築できます（MAY）。
This cost mode is indicated by the string "numerical". This mode indicates that it is safe to perform numerical operations (e.g., normalization or computing ratios for weighted load-balancing) on the returned costs. The values are floating-point numbers.
このコストモードは、文字列「数値」で示されます。このモードは、返されたコストに対して数値演算（たとえば、正規化や加重負荷分散の比率の計算）を実行しても安全であることを示します。値は浮動小数点数です。
This cost mode is indicated by the string "ordinal". This mode indicates that the cost values in a cost map represent ranking (relative to all other values in a cost map), not actual costs. The values are non-negative integers, with a lower value indicating a higher preference. Ordinal cost values in a cost map need not be unique or contiguous. In particular, it is possible that two entries in a cost map have an identical rank (ordinal cost value). This document does not specify any behavior by an ALTO client in this case; an ALTO client may decide to break ties by random selection, other application knowledge, or some other means.
このコストモードは、文字列「ordinal」で示されます。このモードは、実際のコストではなく、コストマップのコスト値が（コストマップの他のすべての値と比較した）ランキングを表すことを示します。値は負でない整数で、値が小さいほど優先度が高いことを示します。コストマップの通常のコスト値は、一意または連続している必要はありません。特に、コストマップの2つのエントリが同じランク（通常のコスト値）を持つ可能性があります。このドキュメントでは、この場合のALTOクライアントによる動作は指定されていません。 ALTOクライアントは、ランダムな選択、他のアプリケーションの知識、または他の何らかの手段によって関係を断つことを決定する場合があります。
A request for an ALTO cost map will either explicitly or implicitly include a list of source network locations and a list of destination network locations. (Recall that a network location can be an endpoint address or a PID.)
ALTOコストマップのリクエストには、ソースネットワークロケーションのリストと宛先ネットワークロケーションのリストが明示的または暗黙的に含まれます。 （ネットワークロケーションはエンドポイントアドレスまたはPIDである場合があることを思い出してください。）
Specifically, assume that a request specifies a list of source network locations, say [Src_1, Src_2, ..., Src_m], and a list of destination network locations, say [Dst_1, Dst_2, ..., Dst_n].
具体的には、リクエストが送信元ネットワークロケーションのリスト、たとえば[Src_1、Src_2、...、Src_m]と宛先ネットワークロケーションのリスト、たとえば[Dst_1、Dst_2、...、Dst_n]を指定するとします。
The ALTO server will return the path cost for each of the m*n communicating pairs (i.e., Src_1 -> Dst_1, ..., Src_1 -> Dst_n, ..., Src_m -> Dst_1, ..., Src_m -> Dst_n). If the ALTO server does not define the path cost for a particular pair, that cost may be omitted. This document refers to this structure as a cost map.
ALTOサーバーは、m * n通信ペアのそれぞれのパスコストを返します（つまり、Src_1-> Dst_1、...、Src_1-> Dst_n、...、Src_m-> Dst_1、...、Src_m-> Dst_n）。 ALTOサーバーが特定のペアのパスコストを定義しない場合、そのコストは省略できます。このドキュメントでは、この構造をコストマップと呼びます。
If the cost mode is ordinal, the path cost of each communicating pair is relative to the m*n entries.
コストモードが序数の場合、各通信ペアのパスコストは、m * nエントリを基準にしています。
An ALTO cost map gives path costs between the PIDs defined in an ALTO network map. An ALTO server may modify an ALTO network map at any time, say by adding or deleting PIDs, or even redefining them. Hence, to effectively use an instance of an ALTO cost map, an ALTO client must know which version of the network map defined the PIDs in that cost map. Version tags allow an ALTO client to correlate cost map instances with the corresponding versions of the network maps.
ALTOコストマップは、ALTOネットワークマップで定義されたPID間のパスコストを提供します。 ALTOサーバーは、PIDを追加または削除したり、PIDを再定義したりするなどして、いつでもALTOネットワークマップを変更できます。したがって、ALTOコストマップのインスタンスを効果的に使用するには、ALTOクライアントは、そのコストマップでPIDを定義したネットワークマップのバージョンを知る必要があります。バージョンタグを使用すると、ALTOクライアントはコストマップインスタンスを対応するバージョンのネットワークマップに関連付けることができます。
Specifically, a version tag is a tuple of (1) an ID for the resource (e.g., an ALTO network map) and (2) a tag (an opaque string) associated with the version of that resource. An ALTO network map distributed by an ALTO server includes its version tag. An ALTO cost map referring to PIDs also includes the version tag for the network map on which it is based.
具体的には、バージョンタグは、（1）リソースのID（ALTOネットワークマップなど）と（2）そのリソースのバージョンに関連付けられたタグ（不透明な文字列）のタプルです。 ALTOサーバーによって配布されるALTOネットワークマップには、そのバージョンタグが含まれています。 PIDを参照するALTOコストマップには、ベースとなるネットワークマップのバージョンタグも含まれます。
Two ALTO network maps are the same if they have the same version tag. Whenever the content of an ALTO network map maintained by an ALTO server changes, the tag MUST also be changed. Possibilities of setting the tag component include the last-modified timestamp for the network map, or a hash of its contents, where the collision probability is considered zero in practical deployment scenarios.
2つのALTOネットワークマップは、バージョンタグが同じであれば同じです。 ALTOサーバーによって維持されるALTOネットワークマップのコンテンツが変更されるたびに、タグも変更する必要があります。タグコンポーネントを設定する可能性には、ネットワークマップの最終変更タイムスタンプ、またはそのコンテンツのハッシュが含まれます。実際の展開シナリオでは、衝突確率はゼロと見なされます。
An ALTO server can update an ALTO cost map at any time. Hence, the same cost map retrieved from the same ALTO server but from different requests can be inconsistent.
ALTOサーバーは、ALTOコストマップをいつでも更新できます。したがって、同じALTOサーバーから取得された同じコストマップが異なる要求から取得されると、一貫性がなくなる可能性があります。
An endpoint property defines a network-aware property of an endpoint.
エンドポイントプロパティは、エンドポイントのネットワーク対応プロパティを定義します。
For each endpoint and an endpoint property type, there can be a value for the property. The type of an endpoint property is indicated in protocol messages as a string. The value depends on the specific property. For example, for a property such as whether an endpoint is metered, the value is a true or false value. See Section 10.8 for more details on specifying endpoint properties.
各エンドポイントおよびエンドポイントプロパティタイプには、プロパティの値が存在する場合があります。エンドポイントプロパティのタイプは、プロトコルメッセージで文字列として示されます。値は特定のプロパティによって異なります。たとえば、エンドポイントが測定されるかどうかなどのプロパティの場合、値はtrueまたはfalseの値です。エンドポイントプロパティの指定の詳細については、セクション10.8を参照してください。
An ALTO server MUST define the "pid" endpoint property type for each ALTO network map that it provides. Specifically, each ALTO network map defines multiple PIDs. For an "ipv4"/"ipv6" network map, given an endpoint's IP address, the ALTO server uses the algorithm specified in Section 11.2.2 to look up the PID of the endpoint. This PID is the "pid" property of the endpoint for the network map. See Section 11.4.1.7 for an example.
ALTOサーバーは、提供する各ALTOネットワークマップの「pid」エンドポイントプロパティタイプを定義する必要があります。具体的には、各ALTOネットワークマップは複数のPIDを定義します。 「ipv4」/「ipv6」ネットワークマップの場合、エンドポイントのIPアドレスが指定されると、ALTOサーバーはセクション11.2.2で指定されたアルゴリズムを使用してエンドポイントのPIDを検索します。このPIDは、ネットワークマップのエンドポイントの「pid」プロパティです。例については、セクション11.4.1.7を参照してください。
This section first specifies general client and server processing. The details of specific services will be covered in the following sections.
このセクションでは、最初に一般的なクライアントとサーバーの処理を指定します。特定のサービスの詳細については、次のセクションで説明します。
The ALTO Protocol uses a REST-ful design. There are two primary components to this design:
ALTOプロトコルはRESTフル設計を使用しています。この設計には2つの主要なコンポーネントがあります。
o Information Resources: Each ALTO service is realized by a set of network information resources. Each information resource has a media type [RFC2046]. An ALTO client may construct an HTTP request for a particular information resource (including any parameters, if necessary), and the ALTO server returns the requested information resource in an HTTP response.
o 情報リソース：各ALTOサービスは、ネットワーク情報リソースのセットによって実現されます。各情報リソースには、メディアタイプ[RFC2046]があります。 ALTOクライアントは特定の情報リソース（必要に応じてパラメーターを含む）に対するHTTP要求を作成し、ALTOサーバーは要求された情報リソースをHTTP応答で返します。
o Information Resource Directory (IRD): An ALTO server uses an IRD to inform an ALTO client about a list of available information resources and the URI at which each can be accessed. ALTO clients consult the IRDs to determine the services provided by ALTO servers.
o 情報リソースディレクトリ（IRD）：ALTOサーバーは、IRDを使用して、利用可能な情報リソースのリストとそれぞれにアクセスできるURIについてALTOクライアントに通知します。 ALTOクライアントは、IRDを参照して、ALTOサーバーによって提供されるサービスを決定します。
This document uses JSONString, JSONNumber, and JSONBool to indicate the JSON string, number, and boolean types, respectively. The type JSONValue indicates a JSON value, as specified in Section 3 of [RFC7159].
このドキュメントでは、JSONString、JSONNumber、JSONBoolを使用して、それぞれJSON文字列、数値、ブール型を示します。 [RFC7159]のセクション3で指定されているように、JSONValueタイプはJSON値を示します。
This document uses an adaptation of the C-style struct notation to define JSON objects. A JSON object consists of name/value pairs. This document refers to each pair as a field. In some context, this document also refers to a field as an attribute. The name of a field/attribute may be referred to as the key. 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.
このドキュメントでは、Cスタイルの構造体表記の改造を使用してJSONオブジェクトを定義します。 JSONオブジェクトは、名前と値のペアで構成されます。このドキュメントでは、各ペアをフィールドと呼びます。一部のコンテキストでは、このドキュメントではフィールドを属性と呼びます。フィールド/属性の名前はキーと呼ばれることがあります。オプションのフィールドは[]で囲みます。定義では、フィールドのJSON名は大文字と小文字が区別されます。配列は山かっこで囲まれた2つの数値<m..n>で示されます。mは最小値を示し、nは最大値です。このドキュメントでnに*を使用している場合、上限がないことを意味します。
For example, the definition below defines a new type Type4, with three fields named "name1", "name2", and "name3", respectively. The field named "name3" is optional, and the field named "name2" is an array of at least one value.
たとえば、以下の定義は、「name1」、「name2」、および「name3」という名前の3つのフィールドを持つ、新しいタイプType4を定義しています。 「name3」という名前のフィールドはオプションであり、「name2」という名前のフィールドは少なくとも1つの値の配列です。
object { Type1 name1; Type2 name2<1..*>; [Type3 name3;]
} Type4;
This document also defines dictionary maps (or maps for short) from strings to JSON values. For example, the definition below defines a Type3 object as a map. Type1 must be defined as string, and Type2 can be defined as any type.
このドキュメントでは、文字列からJSON値への辞書マップ（または略してマップ）も定義しています。たとえば、以下の定義では、Type3オブジェクトをマップとして定義しています。 Type1は文字列として定義する必要があり、Type2は任意のタイプとして定義できます。
object-map { Type1 -> Type2; } Type3;
This document uses subtyping to denote that one type is derived from another type. The example below denotes that TypeDerived is derived from TypeBase. TypeDerived includes all fields defined in TypeBase. If TypeBase does not have a field named "name1", TypeDerived will have a new field named "name1". If TypeBase already has a field named "name1" but with a different type, TypeDerived will have a field named "name1" with the type defined in TypeDerived (i.e., Type1 in the example).
このドキュメントでは、サブタイプを使用して、あるタイプが別のタイプから派生していることを示しています。以下の例は、TypeDerivedがTypeBaseから派生していることを示しています。 TypeDerivedには、TypeBaseで定義されたすべてのフィールドが含まれます。 TypeBaseに "name1"という名前のフィールドがない場合、TypeDerivedには "name1"という名前の新しいフィールドがあります。 TypeBaseにすでに「name1」という名前のフィールドがあるが、タイプが異なる場合、TypeDerivedには、TypeDerivedで定義されたタイプ（例ではType1）の「name1」という名前のフィールドがあります。
object { Type1 name1; } TypeDerived : TypeBase;
Note that, despite the notation, no standard, machine-readable interface definition or schema is provided in this document. Extension documents may describe these as necessary.
表記にかかわらず、このドキュメントでは標準の機械可読なインターフェース定義またはスキーマは提供されていないことに注意してください。拡張ドキュメントでは、必要に応じてこれらについて説明します。
The ALTO Protocol employs standard HTTP [RFC7230]. It is used for discovering available information resources at an ALTO server and retrieving Information Resources. ALTO clients and ALTO servers use HTTP requests and responses carrying ALTO-specific content with encoding as specified in this document, and they MUST be compliant with [RFC7230].
ALTOプロトコルは標準HTTP [RFC7230]を採用しています。これは、ALTOサーバーで利用可能な情報リソースを検出し、情報リソースを取得するために使用されます。 ALTOクライアントとALTOサーバーは、このドキュメントで指定されているエンコーディングでALTO固有のコンテンツを伝送するHTTP要求と応答を使用し、[RFC7230]に準拠している必要があります。
Instead of specifying the generic application/json media type for all ALTO request parameters (if any) and responses, ALTO clients and servers use multiple, specific JSON-based media types (e.g., application/alto-networkmap+json, application/alto-costmap+json) to indicate content types; see Table 2 for a list of media types defined in this document. This allows easy extensibility while maintaining clear semantics and versioning. For example, a new version of a component of the ALTO Protocol (e.g., a new version of ALTO network maps) can be defined by simply introducing a new media type (e.g., application/alto-networkmap-v2+json).
すべてのALTO要求パラメーター（存在する場合）と応答に汎用のapplication / jsonメディアタイプを指定する代わりに、ALTOクライアントとサーバーは複数の特定のJSONベースのメディアタイプ（例：application / alto-networkmap + json、application / alto- costmap + json）は、コンテンツタイプを示します。このドキュメントで定義されているメディアタイプのリストについては、表2を参照してください。これにより、明確なセマンティクスとバージョン管理を維持しながら、拡張が容易になります。たとえば、ALTOプロトコルのコンポーネントの新しいバージョン（ALTOネットワークマップの新しいバージョンなど）は、新しいメディアタイプ（application / alto-networkmap-v2 + jsonなど）を導入するだけで定義できます。
To discover available information resources provided by an ALTO server, an ALTO client requests its IRD(s).
ALTOサーバーによって提供される利用可能な情報リソースを検出するために、ALTOクライアントはそのIRDを要求します。
Specifically, using an ALTO service discovery protocol, an ALTO client obtains a URI through which it can request an information resource directory (IRD). This document refers to this IRD as the Root IRD of the ALTO client. Each entry in an IRD indicates a URI at which an ALTO server accepts requests, and returns either an information resource or an information resource directory that references additional information resources. Beginning with its Root IRD and following links to IRDs recursively, an ALTO client can discover all information resources available to it. This set of information resources is referred to as the information resource closure of the ALTO client. By inspecting its information resource closure, an ALTO client can determine whether an ALTO server supports the desired information resource, and if it is supported, the URI at which it is available.
具体的には、ALTOサービス検出プロトコルを使用して、ALTOクライアントは、情報リソースディレクトリ（IRD）を要求できるURIを取得します。このドキュメントでは、このIRDをALTOクライアントのルートIRDと呼びます。 IRDの各エントリは、ALTOサーバーが要求を受け入れるURIを示し、追加の情報リソースを参照する情報リソースまたは情報リソースディレクトリを返します。ルートIRDから始まり、IRDへのリンクを再帰的にたどっていくと、ALTOクライアントは利用可能なすべての情報リソースを発見できます。この一連の情報リソースは、ALTOクライアントの情報リソースクロージャと呼ばれます。 ALTOクライアントは、その情報リソースクロージャを検査することにより、ALTOサーバーが目的の情報リソースをサポートしているかどうかを判断でき、サポートされている場合は、利用可能なURIを判断できます。
See Section 9.2 for a detailed specification of IRDs.
IRDの詳細な仕様については、セクション9.2を参照してください。
Where possible, the ALTO Protocol uses the HTTP GET method to request resources. However, some ALTO services provide information resources that are the function of one or more input parameters. Input parameters are encoded in the HTTP request's entity body, and the ALTO client MUST use the HTTP POST method to send the parameters.
可能な場合、ALTOプロトコルはHTTP GETメソッドを使用してリソースを要求します。ただし、一部のALTOサービスは、1つ以上の入力パラメーターの機能である情報リソースを提供します。入力パラメーターはHTTPリクエストのエンティティ本体でエンコードされ、ALTOクライアントはパラメーターを送信するためにHTTP POSTメソッドを使用する必要があります。
When requesting an ALTO information resource that requires input parameters specified in a HTTP POST request, an ALTO client MUST set the Content-Type HTTP header to the media type corresponding to the format of the supplied input parameters.
HTTP POST要求で指定された入力パラメーターを必要とするALTO情報リソースを要求する場合、ALTOクライアントは、Content-Type HTTPヘッダーを、提供された入力パラメーターの形式に対応するメディアタイプに設定する必要があります。
An ALTO client MUST NOT assume that the HTTP GET and POST methods are interchangeable. In particular, for an information resource that uses the HTTP GET method, an ALTO client MUST NOT assume that the information resource will accept a POST request as equivalent to a GET request.
ALTOクライアントは、HTTP GETメソッドとPOSTメソッドが交換可能であることを想定してはなりません。特に、HTTP GETメソッドを使用する情報リソースの場合、ALTOクライアントは、情報リソースがPOSTリクエストをGETリクエストと同等のものとして受け入れると想定してはなりません（MUST NOT）。
Upon receiving a request for an information resource that the ALTO server can provide, the ALTO server normally returns the requested information resource. In other cases, to be more informative ([RFC7231]), the ALTO server either provides the ALTO client with an information resource directory indicating how to reach the desired information resource, or it returns an ALTO error object; see Section 8.5 for more details on ALTO error handling.
ALTOサーバーが提供できる情報リソースの要求を受信すると、ALTOサーバーは通常、要求された情報リソースを返します。その他の場合、より情報を提供するため（[RFC7231]）、ALTOサーバーは、ALTOクライアントに、目的の情報リソースに到達する方法を示す情報リソースディレクトリを提供するか、またはALTOエラーオブジェクトを返します。 ALTOエラー処理の詳細については、セクション8.5を参照してください。
It is possible for an ALTO server to leverage caching HTTP intermediaries to respond to both GET and POST requests by including explicit freshness information (see Section 14 of [RFC7230]). Caching of POST requests is not widely implemented by HTTP intermediaries; however, an alternative approach is for an ALTO server, in response to POST requests, to return an HTTP 303 status code ("See Other") indicating to the ALTO client that the resulting information resource is available via a GET request to an alternate URL. HTTP intermediaries that do not support caching of POST requests could then cache the response to the GET request from the ALTO client following the alternate URL in the 303 response if the response to the subsequent GET request contains explicit freshness information.
ALTOサーバーがHTTP中間キャッシュを利用して、明示的な鮮度情報を含めることで、GETリクエストとPOSTリクエストの両方に応答することができます（[RFC7230]のセクション14を参照）。 POSTリクエストのキャッシュは、HTTP仲介者によって広く実装されていません。ただし、別のアプローチは、POST要求に応じて、ALTOサーバーがHTTP 303ステータスコード（「その他を参照」）を返し、結果の情報リソースが代替URLへのGET要求を介して利用可能であることをALTOクライアントに示すことです。 。 POSTリクエストのキャッシュをサポートしないHTTP仲介者は、後続のGETリクエストへの応答に明示的な鮮度情報が含まれている場合、303レスポンスの代替URLに従って、ALTOクライアントからのGETリクエストへの応答をキャッシュできます。
The ALTO server MUST indicate the type of its response using a media type (i.e., the Content-Type HTTP header of the response).
ALTOサーバーは、メディアタイプ（つまり、応答のContent-Type HTTPヘッダー）を使用して、応答のタイプを示さなければなりません（MUST）。
This specification does not indicate any required actions taken by ALTO clients upon successfully receiving an information resource from an ALTO server. Although ALTO clients are suggested to interpret the received ALTO information and adapt application behavior, ALTO clients are not required to do so.
この仕様は、ALTOサーバーから情報リソースを正常に受信したときにALTOクライアントが実行する必要なアクションを示していません。 ALTOクライアントは、受け取ったALTO情報を解釈してアプリケーションの動作を適合させることをお勧めしますが、ALTOクライアントはそのようにする必要はありません。
After receiving an information resource directory, the client can consult it to determine if any of the offered URIs contain the desired information resource. However, an ALTO client MUST NOT assume that the media type returned by the ALTO server for a request to a URI is the media type advertised in the IRD or specified in its request (i.e., the client must still check the Content-Type header). The expectation is that the media type returned should normally be the media type advertised and requested, but, in some cases, it may legitimately not be so.
情報リソースディレクトリを受信した後、クライアントはそれを参照して、提供されたURIのいずれかに目的の情報リソースが含まれているかどうかを判断できます。ただし、ALTOクライアントは、URIへの要求に対してALTOサーバーから返されたメディアタイプがIRDでアドバタイズされた、またはその要求で指定されたメディアタイプであると想定してはなりません（つまり、クライアントは引き続きContent-Typeヘッダーを確認する必要があります）。 。返されるメディアタイプは通常、アドバタイズおよびリクエストされたメディアタイプであることが期待されますが、場合によってはそうではない場合もあります。
In particular, it is possible for an ALTO client to receive an information resource directory from an ALTO server as a response to its request for a specific information resource. In this case, the ALTO client may ignore the response or still parse the response. To indicate that an ALTO client will always check if a response is an information resource directory, the ALTO client can indicate in the "Accept" header of a HTTP request that it can accept information resource directory; see Section 9.2.1 for the media type.
特に、ALTOクライアントは、特定の情報リソースの要求に対する応答として、ALTOサーバーから情報リソースディレクトリを受け取ることができます。この場合、ALTOクライアントは応答を無視するか、応答を解析する可能性があります。 ALTOクライアントが応答が情報リソースディレクトリかどうかを常にチェックすることを示すために、ALTOクライアントはHTTPリクエストの "Accept"ヘッダーで情報リソースディレクトリを受け入れることができることを示すことができます。メディアタイプについては、セクション9.2.1を参照してください。
If an ALTO client does not successfully receive a desired information resource from a particular ALTO server (i.e., server response indicates error or there is no response), the client can either choose another server (if one is available) or fall back to a default behavior (e.g., perform peer selection without the use of ALTO information, when used in a peer-to-peer system).
ALTOクライアントが特定のALTOサーバーから目的の情報リソースを正常に受信できない場合（つまり、サーバーの応答がエラーを示すか、応答がない場合）、クライアントは別のサーバーを選択するか（使用可能な場合）、デフォルトにフォールバックできます。動作（たとえば、ピアツーピアシステムで使用される場合、ALTO情報を使用せずにピア選択を実行する）。
ALTO server implementations as well as ALTO client implementations MUST support the "https" URI scheme [RFC2818] and Transport Layer Security (TLS) [RFC5246]. See Section 15.1.2 for security considerations and Section 16 for manageability considerations regarding the usage of HTTPS/TLS.
ALTOサーバーの実装とALTOクライアントの実装は、 "https" URIスキーム[RFC2818]およびトランスポート層セキュリティ（TLS）[RFC5246]をサポートする必要があります。セキュリティの考慮事項についてはセクション15.1.2を、HTTPS / TLSの使用に関する管理性の考慮事項についてはセクション16を参照してください。
For deployment scenarios where client authentication is desired, HTTP Digest Authentication MUST be supported. TLS Client Authentication is the preferred mechanism if it is available.
クライアント認証が必要な展開シナリオでは、HTTPダイジェスト認証をサポートする必要があります。 TLSクライアント認証は、利用可能な場合に推奨されるメカニズムです。
An ALTO client can determine the frequency at which ALTO information is refreshed based on information made available via HTTP.
ALTOクライアントは、HTTP経由で提供される情報に基づいて、ALTO情報が更新される頻度を決定できます。
This document only details object fields used by this specification. Extensions may include additional fields within JSON objects defined in this document. ALTO implementations MUST ignore unknown fields when processing ALTO messages.
このドキュメントでは、この仕様で使用されるオブジェクトフィールドについてのみ説明します。拡張機能には、このドキュメントで定義されているJSONオブジェクト内の追加フィールドが含まれる場合があります。 ALTO実装は、ALTOメッセージを処理するときに不明なフィールドを無視する必要があります。
Though each type of ALTO server response (i.e., an information resource directory, an individual information resource, or an error message) has its distinct syntax and, hence, its unique media type, they are designed to have a similar structure: a field named "meta" to provide meta definitions, and another field named "data" to contain the data, if needed.
ALTOサーバーの応答の各タイプ（つまり、情報リソースディレクトリ、個々の情報リソース、またはエラーメッセージ）にはそれぞれ異なる構文があり、したがって固有のメディアタイプがありますが、これらは同様の構造を持つように設計されています。メタ定義を提供する「meta」、および必要に応じてデータを含む「data」という名前の別のフィールド。
Specifically, this document defines the base type of each ALTO server response as ResponseEntityBase:
具体的には、このドキュメントでは、各ALTOサーバー応答の基本タイプをResponseEntityBaseとして定義しています。
object { ResponseMeta meta; } ResponseEntityBase;
with field:
フィールド付き：
meta: meta information pertaining to the response.
meta：応答に関するメタ情報。
Meta information is encoded as a map object for flexibility. Specifically, ResponseMeta is defined as:
メタ情報は、柔軟性を高めるためにマップオブジェクトとしてエンコードされます。具体的には、ResponseMetaは次のように定義されます。
object-map { JSONString -> JSONValue } ResponseMeta;
The data component of the response encodes the response-specific data. This document derives five types from ResponseEntityBase to add different types of data component: InfoResourceDirectory (Section 9.2.2), InfoResourceNetworkMap (Section 11.2.1.6), InfoResourceCostMap (Section 11.2.3.6), InfoResourceEndpointProperties (Section 11.4.1.6), and InfoResourceEndpointCostMap (Section 11.5.1.6).
応答のデータコンポーネントは、応答固有のデータをエンコードします。このドキュメントは、ResponseEntityBaseから5つのタイプを派生させて、さまざまなタイプのデータコンポーネントを追加します。InfoResourceDirectory（セクション9.2.2）、InfoResourceNetworkMap（セクション11.2.1.6）、InfoResourceCostMap（セクション11.2.3.6）、InfoResourceEndpointProperties（セクション11.4.1.6）、およびInfoResourceEndpointCostMap（セクション11.5.1.6）。
If an ALTO server encounters an error while processing a request, the ALTO server SHOULD return additional ALTO-layer information, if it is available, in the form of an ALTO error resource encoded in the HTTP response' entity body. If no ALTO-layer information is available, an ALTO server may omit the ALTO error resource from the response.
ALTOサーバーがリクエストの処理中にエラーを検出した場合、ALTOサーバーは、追加のALTOレイヤー情報が利用可能な場合、HTTP応答のエンティティ本文にエンコードされたALTOエラーリソースの形式で返す必要があります（SHOULD）。 ALTOレイヤー情報が利用できない場合、ALTOサーバーは応答からALTOエラーリソースを省略できます。
With or without additional ALTO-layer error information, an ALTO server MUST set an appropriate HTTP status code. It is important to note that the HTTP status code and ALTO error resource have distinct roles. An ALTO error resource provides detailed information about why a particular request for an ALTO information resource was not successful. The HTTP status code, on the other hand, indicates to HTTP processing elements (e.g., intermediaries and clients) how the response should be treated.
追加のALTOレイヤーエラー情報の有無にかかわらず、ALTOサーバーは適切なHTTPステータスコードを設定する必要があります。 HTTPステータスコードとALTOエラーリソースには異なる役割があることに注意してください。 ALTOエラーリソースは、ALTO情報リソースに対する特定の要求が成功しなかった理由に関する詳細情報を提供します。一方、HTTPステータスコードは、HTTP処理要素（仲介者やクライアントなど）に対して、応答の処理方法を示します。
The media type for an ALTO error response is "application/ alto-error+json".
ALTOエラーレスポンスのメディアタイプは「application / alto-error + json」です。
An ALTO error response MUST include a field named "code" in the "meta" field of the response. The value MUST be an ALTO error code, encoded in string, defined in Table 1. Note that the ALTO error codes defined in Table 1 are limited to support the error conditions needed for purposes of this document. Additional status codes may be defined in companion or extension documents.
ALTOエラー応答には、応答の「メタ」フィールドに「コード」という名前のフィールドを含める必要があります。値は、表1で定義されている文字列でエンコードされたALTOエラーコードである必要があります。表1で定義されているALTOエラーコードは、このドキュメントの目的に必要なエラー条件をサポートするように制限されています。追加のステータスコードは、コンパニオンドキュメントまたは拡張ドキュメントで定義できます。
+-----------------------+-------------------------------------------+
| ALTO Error Code | Description |
+-----------------------+-------------------------------------------+
| E_SYNTAX | Parsing error in request (including |
| | identifiers) |
| E_MISSING_FIELD | A required JSON field is missing |
| E_INVALID_FIELD_TYPE | The type of the value of a JSON field is |
| | invalid |
| E_INVALID_FIELD_VALUE | The value of a JSON field is invalid |
+-----------------------+-------------------------------------------+
Table 1: Defined ALTO Error Codes
表1：定義されたALTOエラーコード
After an ALTO server receives a request, it needs to verify the syntactic and semantic validity of the request. The following paragraphs in this section are intended to illustrate the usage of the error codes defined above during the verification. An individual implementation may define its message processing in a different order.
ALTOサーバーは要求を受信した後、要求の構文的および意味的妥当性を検証する必要があります。このセクションの次の段落は、上記の検証で定義されたエラーコードの使用方法を説明するためのものです。個々の実装では、メッセージの処理を異なる順序で定義できます。
In the first step after an ALTO server receives a request, it checks the syntax of the request body (i.e., whether the JSON structure can be parsed), and indicates a syntax error using the error code E_SYNTAX. For an E_SYNTAX error, the ALTO server MAY provide an optional field named "syntax-error" in the "meta" field of the error response. The objective of providing "syntax-error" is to provide technical debugging information to developers, not end users. Hence, it should be a human-readable, free-form text describing the syntax error. If possible, the text should include position information about the syntax error, such as line number and offset within the line. If nothing else, the value of the field named "syntax-error" could include just the position. If a syntax error occurs in a production environment, the ALTO client could inform the end user that there was an error communicating with the ALTO server, and suggest that the user submit the error information, which includes "syntax-error", to the developers.
ALTOサーバーが要求を受信した後の最初のステップでは、要求本文の構文（つまり、JSON構造を解析できるかどうか）をチェックし、エラーコードE_SYNTAXを使用して構文エラーを示します。 E_SYNTAXエラーの場合、ALTOサーバーは、エラー応答の「メタ」フィールドに「syntax-error」という名前のオプションフィールドを提供できます（MAY）。 「構文エラー」を提供する目的は、エンドユーザーではなく開発者に技術的なデバッグ情報を提供することです。したがって、それは構文エラーを説明する人間が読める、自由形式のテキストである必要があります。可能であれば、テキストには、行番号や行内のオフセットなど、構文エラーに関する位置情報を含める必要があります。他に何もない場合、「syntax-error」というフィールドの値には、位置のみを含めることができます。実稼働環境で構文エラーが発生した場合、ALTOクライアントは、ALTOサーバーとの通信でエラーが発生したことをエンドユーザーに通知し、ユーザーに「構文エラー」を含むエラー情報を開発者に送信するよう提案することができます。 。
A request without syntax errors may still be invalid. An error case is that the request misses a required field. The server indicates such an error using the error code E_MISSING_FIELD. This document defines required fields for Filtered Network Map (Section 11.3.1.3),
構文エラーのない要求は依然として無効である可能性があります。エラーのケースは、リクエストが必須フィールドを欠いていることです。サーバーは、エラーコードE_MISSING_FIELDを使用してそのようなエラーを示します。このドキュメントでは、フィルター済みネットワークマップの必須フィールドを定義します（セクション11.3.1.3）。
Filtered Cost Map (Section 11.3.2.3), Endpoint Properties (Section 11.4.1.3), and Endpoint Cost (Section 11.5.1.3) services. For an E_MISSING_FIELD error, the server may include an optional field named "field" in the "meta" field of the error response, to indicate the missing field. "field" should be a JSONString indicating the full path of the missing field. For example, assume that a Filtered Cost Map request (see Section 11.3.2.3) omits the "cost-metric" field. The error response from the ALTO server may specify the value of "field" as "cost-type/cost-metric".
フィルターされたコストマップ（セクション11.3.2.3）、エンドポイントプロパティ（セクション11.4.1.3）、およびエンドポイントコスト（セクション11.5.1.3）サービス。 E_MISSING_FIELDエラーの場合、サーバーは、欠落しているフィールドを示すために、エラー応答の「メタ」フィールドに「フィールド」という名前のオプションのフィールドを含めることができます。 「フィールド」は、欠落しているフィールドの絶対パスを示すJSONStringである必要があります。たとえば、フィルターされたコストマップリクエスト（セクション11.3.2.3を参照）で「コストメトリック」フィールドが省略されているとします。 ALTOサーバーからのエラー応答では、「フィールド」の値を「コストタイプ/コストメトリック」として指定できます。
A request with the correct fields might use a wrong type for the value of a field. For example, the value of a field could be a JSONString when a JSONNumber is expected. The server indicates such an error using the error code E_INVALID_FIELD_TYPE. The server may include an optional field named "field" in the "meta" field of the response, to indicate the field that contains the wrong type.
正しいフィールドを含むリクエストでは、フィールドの値に間違ったタイプを使用する可能性があります。たとえば、JSONNumberが期待される場合、フィールドの値はJSONStringになる可能性があります。サーバーは、エラーコードE_INVALID_FIELD_TYPEを使用して、このようなエラーを示します。サーバーは、間違ったタイプを含むフィールドを示すために、応答の「メタ」フィールドに「フィールド」という名前のオプションのフィールドを含める場合があります。
A request with the correct fields and types of values for the fields may specify a wrong value for a field. For example, a Filtered Cost Map request may specify a wrong value for CostMode in the "cost-type" field (Section 11.3.2.3). The server indicates such an error with the error code E_INVALID_FIELD_VALUE. For an E_INVALID_FIELD_VALUE error, the server may include an optional field named "field" in the "meta" field of the response, to indicate the field that contains the wrong value. The server may also include an optional field named "value" in the "meta" field of the response to indicate the wrong value that triggered the error. If the "value" field is specified, the "field" field MUST be specified. The "value" field MUST have a JSONString value. If the invalid value is not a string, the ALTO server MUST convert it to a string. Below are the rules to specify the "value" key:
正しいフィールドとフィールドの値のタイプを含むリクエストは、フィールドに間違った値を指定する場合があります。たとえば、フィルターされたコストマップリクエストでは、「cost-type」フィールド（セクション11.3.2.3）でCostModeに誤った値を指定する場合があります。サーバーは、エラーコードE_INVALID_FIELD_VALUEでそのようなエラーを示します。 E_INVALID_FIELD_VALUEエラーの場合、サーバーは、応答の「メタ」フィールドに「フィールド」という名前のオプションのフィールドを含めて、間違った値を含むフィールドを示す場合があります。サーバーは、エラーの原因となった間違った値を示すために、応答の「メタ」フィールドに「値」というオプションのフィールドを含めることもできます。 「値」フィールドを指定する場合は、「フィールド」フィールドを指定する必要があります。 「値」フィールドにはJSONString値が必要です。無効な値が文字列でない場合、ALTOサーバーはそれを文字列に変換する必要があります。以下は、「値」キーを指定するためのルールです。
o If the invalid value is a string, "value" is that string;
o 無効な値が文字列の場合、「値」はその文字列です。
o If the invalid value is a number, "value" must be the invalid number as a string;
o 無効な値が数値の場合、「value」は文字列としての無効な数値でなければなりません。
o If the invalid value is a subfield, the server must set the "field" key to the full path of the field name and "value" to the invalid subfield value, converting it to a string if needed. For example, if the "cost-mode" subfield of the "cost-type" field is an invalid mode "foo", the server should set "value" to "foo", and "field" to "cost-mode/cost-type";
o 無効な値がサブフィールドである場合、サーバーは「フィールド」キーをフィールド名の完全パスに設定し、「値」を無効なサブフィールド値に設定して、必要に応じて文字列に変換する必要があります。たとえば、「cost-type」フィールドの「cost-mode」サブフィールドが無効なモード「foo」である場合、サーバーは「value」を「foo」に設定し、「field」を「cost-mode / cost」に設定する必要があります-タイプ";
o If an element of a JSON array has an invalid value, the server sets "value" to the value of the invalid element, as a string, and "field" to the name of the array. An array element of the wrong type (e.g., a number in what is supposed to be an array of strings) is an invalid value error, not an invalid type error. The server sets "value" to the string version of the incorrect element, and "field" to the name of the array.
o JSON配列の要素に無効な値がある場合、サーバーは「値」を無効な要素の値に文字列として設定し、「フィールド」を配列の名前に設定します。間違った型の配列要素（たとえば、文字列の配列であるはずの数字）は無効な値のエラーであり、無効な型のエラーではありません。サーバーは、「値」を不正な要素の文字列バージョンに設定し、「フィールド」を配列の名前に設定します。
If multiple errors are present in a single request (e.g., a request uses a JSONString when a JSONNumber is expected and a required field is missing), then the ALTO server MUST return exactly one of the detected errors. However, the reported error is implementation defined, since specifying a particular order for message processing encroaches needlessly on implementation techniques.
単一のリクエストに複数のエラーが存在する場合（たとえば、JSONNumberが予期されていて必須フィールドが欠落しているときにリクエストがJSONStringを使用する場合）、ALTOサーバーは検出されたエラーの1つを返す必要があります。ただし、メッセージ処理の特定の順序を指定すると実装技術が不必要に侵害されるため、報告されるエラーは実装定義です。
If an ALTO server detects that it cannot handle a request from an ALTO client due to excessive load, technical problems, or system maintenance, it SHOULD do one of the following:
ALTOサーバーは、過度の負荷、技術的な問題、またはシステムメンテナンスのためにALTOクライアントからの要求を処理できないことを検出した場合、次のいずれかを実行する必要があります。
o Return an HTTP 503 ("Service Unavailable") status code to the ALTO client. As indicated by [RFC7230], the Retry-After HTTP header may be used to indicate when the ALTO client should retry the request.
o HTTP 503（ "Service Unavailable"）ステータスコードをALTOクライアントに返します。 [RFC7230]で示されているように、Retry-After HTTPヘッダーを使用して、ALTOクライアントがリクエストを再試行するタイミングを示すことができます。
o Return an HTTP 307 ("Temporary Redirect") status code indicating an alternate ALTO server that may be able to satisfy the request. Using Temporary Redirect may generate infinite redirection loops. Although [RFC7231] Section 6.4 specifies that an HTTP client SHOULD detect infinite redirection loops, it is more desirable that multiple ALTO servers be configured not to form redirection loops.
o 要求を満たすことができる代替ALTOサーバーを示すHTTP 307（「一時リダイレクト」）ステータスコードを返します。一時リダイレクトを使用すると、無限のリダイレクトループが生成される場合があります。 [RFC7231]セクション6.4は、HTTPクライアントが無限のリダイレクトループを検出する必要があることを指定していますが、リダイレクトループを形成しないように複数のALTOサーバーを構成することがより望ましいです。
The ALTO server MAY also terminate the connection with the ALTO client.
ALTOサーバーは、ALTOクライアントとの接続も終了する場合があります。
The particular policy applied by an ALTO server to determine that it cannot service a request is outside of the scope of this document.
ALTOサーバーが要求を処理できないと判断するために適用する特定のポリシーは、このドキュメントの範囲外です。
As already discussed, an ALTO client starts by retrieving an information resource directory, which specifies the attributes of individual information resources that an ALTO server provides.
すでに説明したように、ALTOクライアントはまず、ALTOサーバーが提供する個々の情報リソースの属性を指定する情報リソースディレクトリを取得します。
In this document, each information resource has up to five attributes associated with it, including its assigned ID, its response format, its capabilities, its accepted input parameters, and other resources on which it may depend. The function of an information resource directory is to publishes these attributes.
このドキュメントでは、各情報リソースに最大5つの属性が関連付けられています。これには、割り当てられたID、応答形式、機能、受け入れられる入力パラメーター、およびリソースが依存する可能性のあるその他のリソースが含まれます。情報リソースディレクトリの機能は、これらの属性を公開することです。
Each information resource that an ALTO client can request MUST be assigned a resource ID attribute that is unique amongst all information resources in the information resource closure of the client. The resource ID SHOULD remain stable even when the data provided by that resource changes. For example, even though the number of PIDs in an ALTO network map may be adjusted, its resource ID should remain the same. Similarly, if the entries in an ALTO cost map are updated, its resource ID should remain the same. IDs SHOULD NOT be reused for different resources over time.
ALTOクライアントが要求できる各情報リソースには、クライアントの情報リソースクロージャ内のすべての情報リソース間で一意のリソースID属性を割り当てる必要があります。リソースIDは、そのリソースによって提供されるデータが変更された場合でも、安定したままである必要があります（SHOULD）。たとえば、ALTOネットワークマップのPIDの数が調整されても、そのリソースIDは同じままである必要があります。同様に、ALTOコストマップのエントリが更新された場合、そのリソースIDは同じままである必要があります。 IDは、時間の経過とともに別のリソースに再利用しないでください。
ALTO uses media types [RFC2046] to uniquely indicate the data format used to encode the content to be transmitted between an ALTO server and an ALTO client in the HTTP entity body.
ALTOはメディアタイプ[RFC2046]を使用して、HTTPエンティティボディでALTOサーバーとALTOクライアント間で送信されるコンテンツのエンコードに使用されるデータ形式を一意に示します。
The Capabilities attribute of an information resource indicates specific capabilities that the server can provide. For example, if an ALTO server allows an ALTO client to specify cost constraints when the client requests a cost map information resource, then the server advertises the "cost-constraints" capability of the cost map information resource.
情報リソースの機能属性は、サーバーが提供できる特定の機能を示します。たとえば、クライアントがコストマップ情報リソースを要求するときに、ALTOサーバーがALTOクライアントにコスト制約の指定を許可している場合、サーバーはコストマップ情報リソースの「コスト制約」機能を通知します。
An ALTO server may allow an ALTO client to supply input parameters when requesting certain information resources. The associated "accepts" attribute of such an information resource specifies a media type, which indicates how the client specifies the input parameters as contained in the entity body of the HTTP POST request.
ALTOサーバーは、特定の情報リソースを要求するときに、ALTOクライアントが入力パラメーターを提供できるようにする場合があります。このような情報リソースの関連する「受け入れ」属性は、メディアタイプを指定します。これは、クライアントがHTTP POSTリクエストのエンティティ本体に含まれる入力パラメータを指定する方法を示します。
The information provided in an information resource may use information provided in some other resources (e.g., a cost map uses the PIDs defined in a network map). The "uses" attribute conveys such information.
情報リソースで提供される情報は、他のリソースで提供される情報を使用できます（たとえば、コストマップはネットワークマップで定義されたPIDを使用します）。 「用途」属性はそのような情報を伝えます。
An ALTO server uses the information resource directory to publish available information resources and their aforementioned attributes. Since resource selection happens after consumption of the information resource directory, the format of the information resource directory is designed to be simple with the intention of future ALTO Protocol versions maintaining backwards compatibility. Future extensions or versions of the ALTO Protocol SHOULD be accomplished by extending existing media types or adding new media types but retaining the same format for the Information Resource Directory.
ALTOサーバーは、情報リソースディレクトリを使用して、利用可能な情報リソースとその前述の属性を公開します。リソースの選択は情報リソースディレクトリの消費後に行われるため、情報リソースディレクトリの形式は、後方互換性を維持する将来のALTOプロトコルバージョンを想定して単純になるように設計されています。 ALTOプロトコルの将来の拡張またはバージョンは、既存のメディアタイプを拡張するか、新しいメディアタイプを追加することによって達成する必要があります（SHOULD）が、情報リソースディレクトリの同じフォーマットを保持します。
An ALTO server MUST make one information resource directory available via the HTTP GET method to a URI discoverable by an ALTO client. Discovery of this URI is out of scope of this document, but it could be accomplished by manual configuration or by returning the URI of an information resource directory from the ALTO Discovery Protocol [ALTO-SERVER-DISC]. For recommendations on what the URI may look like, see [ALTO-SERVER-DISC].
ALTOサーバーは、1つの情報リソースディレクトリを、HTTP GETメソッドを介して、ALTOクライアントが検出できるURIに利用できるようにする必要があります。このURIの検出はこのドキュメントの範囲外ですが、手動で構成するか、ALTO Discovery Protocol [ALTO-SERVER-DISC]から情報リソースディレクトリのURIを返すことで実行できます。 URIがどのように見えるかに関する推奨事項については、[ALTO-SERVER-DISC]を参照してください。
The media type to indicate an information resource directory is "application/alto-directory+json".
情報リソースディレクトリを示すメディアタイプは、「application / alto-directory + json」です。
An information resource directory response may include in the "meta" field the "cost-types" field, whose value is of type IRDMetaCostTypes defined below, where CostType is defined in Section 10.7:
情報リソースディレクトリの応答では、「meta」フィールドに「cost-types」フィールドを含めることができます。その値は、以下で定義されるタイプIRDMetaCostTypesです。ここで、CostTypeはセクション10.7で定義されています。
object-map {
JSONString -> CostType;
} IRDMetaCostTypes;
The function of "cost-types" is to assign names to a set of CostTypes that can be used in one or more "resources" entries in the IRD to simplify specification. The names defined in "cost-types" in an IRD are local to the IRD.
"cost-types"の機能は、IRDの1つ以上の "resources"エントリで使用できる一連のCostTypesに名前を割り当てて、仕様を簡略化することです。 IRDの「コストタイプ」で定義された名前は、IRDに対してローカルです。
For a Root IRD, "meta" MUST include a field named "default-alto-network-map", which value specifies the resource ID of an ALTO network map. When there are multiple network maps defined in an IRD (e.g., with different levels of granularity), the "default-alto-network-map" field provides a guideline to simple clients that use only one network map.
ルートIRDの場合、「メタ」には「default-alto-network-map」というフィールドを含める必要があります。この値は、ALTOネットワークマップのリソースIDを指定します。 IRDに複数のネットワークマップが定義されている場合（たとえば、粒度のレベルが異なる場合）、「default-alto-network-map」フィールドは、1つのネットワークマップのみを使用する単純なクライアントにガイドラインを提供します。
The data component of an information resource directory response is named "resources", which is a JSON object of type IRDResourceEntries:
情報リソースディレクトリの応答のデータコンポーネントの名前は「resources」で、IRDResourceEntriesタイプのJSONオブジェクトです。
object {
IRDResourceEntries resources;
} InfoResourceDirectory : ResponseEntityBase;
object-map {
ResourceID -> IRDResourceEntry;
} IRDResourceEntries;
object {
JSONString uri;
JSONString media-type;
[JSONString accepts;]
[Capabilities capabilities;]
[ResourceID uses<0..*>;]
} IRDResourceEntry;
object {
...
} Capabilities;
An IRDResourceEntries object is a dictionary map keyed by ResourceIDs, where ResourceID is defined in Section 10.2. The value of each entry specifies:
IRDResourceEntriesオブジェクトは、ResourceIDをキーとするディクショナリマップです。ResourceIDはセクション10.2で定義されています。各エントリの値は以下を指定します。
uri: A URI at which the ALTO server provides one or more information resources, or an information resource directory indicating additional information resources. URIs can be relative to the URI of the IRD and MUST be resolved according to Section 5 of [RFC3986].
uri：ALTOサーバーが1つ以上の情報リソースを提供するURI、または追加の情報リソースを示す情報リソースディレクトリ。 URIはIRDのURIを基準にすることができ、[RFC3986]のセクション5に従って解決する必要があります。
media-type: The media type of the information resource (see Section 9.1.2) available via GET or POST requests to the corresponding URI. A value of "application/ alto-directory+json" indicates that the response for a request to the URI will be an information resource directory defining additional information resources in the information resource closure.
media-type：対応するURIへのGETまたはPOSTリクエストを介して利用可能な情報リソース（セクション9.1.2を参照）のメディアタイプ。 「application / alto-directory + json」の値は、URIに対する要求の応答が、情報リソースクロージャ内の追加情報リソースを定義する情報リソースディレクトリになることを示します。
accepts: The media type of input parameters (see Section 9.1.4) accepted by POST requests to the corresponding URI. If this field is not present, it MUST be assumed to be empty.
accepts：対応するURIへのPOSTリクエストによって受け入れられる入力パラメータのメディアタイプ（セクション9.1.4を参照）。このフィールドが存在しない場合は、空であると想定する必要があります。
capabilities: A JSON object enumerating capabilities of an ALTO server in providing the information resource at the corresponding URI and information resources discoverable via the URI. If this field is not present, it MUST be assumed to be an empty object. If a capability for one of the offered information resources is not explicitly listed here, an ALTO client may either issue an OPTIONS HTTP request to the corresponding URI to determine if the capability is supported or assume its default value documented in this specification or an extension document describing the capability.
capabilities：対応するURIの情報リソースとURIを介して検出可能な情報リソースを提供するALTOサーバーの機能を列挙するJSONオブジェクト。このフィールドが存在しない場合は、空のオブジェクトであると想定する必要があります。提供された情報リソースのいずれかの機能がここに明示的にリストされていない場合、ALTOクライアントは対応するURIにOPTIONS HTTPリクエストを発行して、機能がサポートされているかどうかを判断するか、この仕様または拡張ドキュメントに記載されているデフォルト値を想定します。機能の説明。
uses: A list of resource IDs, defined in the same IRD, that define the resources on which this resource directly depends. An ALTO server SHOULD include in this list any resources that the ALTO client would need to retrieve in order to interpret the contents of this resource. For example, an ALTO cost map resource should include in this list the network map on which it depends. ALTO clients may wish to consult this list in order to pre-fetch necessary resources.
使用：このリソースが直接依存するリソースを定義する、同じIRDで定義されたリソースIDのリスト。 ALTOサーバーは、このリソースの内容を解釈するためにALTOクライアントが取得する必要があるすべてのリソースをこのリストに含める必要があります（SHOULD）。たとえば、ALTOコストマップリソースは、このリストに、それが依存するネットワークマップを含める必要があります。 ALTOクライアントは、必要なリソースを事前に取得するために、このリストを参照することをお勧めします。
If an entry has an empty list for "accepts", then the corresponding URI MUST support GET requests. If an entry has a non-empty "accepts", then the corresponding URI MUST support POST requests. If an ALTO server wishes to support both GET and POST on a single URI, it MUST specify two entries in the information resource directory.
エントリが「受け入れる」の空のリストを持っている場合、対応するURIはGETリクエストをサポートする必要があります。エントリに空でない「受け入れ」がある場合、対応するURIはPOSTリクエストをサポートする必要があります。 ALTOサーバーが単一のURIでGETとPOSTの両方をサポートしたい場合は、情報リソースディレクトリに2つのエントリを指定する必要があります。
The following is an example information resource directory returned by an ALTO server to an ALTO client. Assume it is the Root IRD of the client.
以下は、ALTOサーバーからALTOクライアントに返される情報リソースディレクトリの例です。それがクライアントのルートIRDであると想定します。
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: 2333
Content-Type: application/alto-directory+json
{
"meta" : {
"cost-types": {
"num-routing": {
"cost-mode" : "numerical",
"cost-metric": "routingcost",
"description": "My default"
},
"num-hop": {
"cost-mode" : "numerical",
"cost-metric": "hopcount"
},
"ord-routing": {
"cost-mode" : "ordinal",
"cost-metric": "routingcost"
},
"ord-hop": {
"cost-mode" : "ordinal",
"cost-metric": "hopcount"
}
},
"default-alto-network-map" : "my-default-network-map"
},
"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/routingcost",
"media-type" : "application/alto-costmap+json",
"capabilities" : {
"cost-type-names" : [ "num-routing" ]
},
"uses": [ "my-default-network-map" ]
},
"numerical-hopcount-cost-map" : {
"uri" : "http://alto.example.com/costmap/num/hopcount",
"media-type" : "application/alto-costmap+json",
"capabilities" : {
"cost-type-names" : [ "num-hop" ]
},
"uses": [ "my-default-network-map" ]
},
"custom-maps-resources" : {
"uri" : "http://custom.alto.example.com/maps",
"media-type" : "application/alto-directory+json"
},
"endpoint-property" : {
"uri" : "http://alto.example.com/endpointprop/lookup",
"media-type" : "application/alto-endpointprop+json",
"accepts" : "application/alto-endpointpropparams+json",
"capabilities" : {
"prop-types" : [ "my-default-network-map.pid",
"priv:ietf-example-prop" ]
},
},
"endpoint-cost" : {
"uri" : "http://alto.example.com/endpointcost/lookup",
"media-type" : "application/alto-endpointcost+json",
"accepts" : "application/alto-endpointcostparams+json",
"capabilities" : {
"cost-constraints" : true,
"cost-type-names" : [ "num-routing", "num-hop",
"ord-routing", "ord-hop"]
}
}
}
}
Specifically, the "cost-types" field of "meta" of the example IRD defines names for four cost types in this IRD. For example, "num-routing" in the example is the name that refers to a cost type with cost mode being "numerical" and cost metric being "routingcost". This name is used in the second entry of "resources", which defines a cost map. In particular, the "cost-type-names" of its "capabilities" specifies that this resource supports a cost type named as "num-routing". The ALTO client looks up the name "num-routing" in "cost-types" of the IRD to obtain the cost type named as "num-routing". The last entry of "resources" uses all four names defined in "cost-types".
具体的には、サンプルIRDの「メタ」の「コストタイプ」フィールドは、このIRDの4つのコストタイプの名前を定義します。たとえば、例の「num-routing」は、コストモードが「数値」で、コストメトリックが「routingcost」のコストタイプを参照する名前です。この名前は、コストマップを定義する「リソース」の2番目のエントリで使用されます。特に、「機能」の「コストタイプ名」は、このリソースが「num-routing」という名前のコストタイプをサポートすることを指定しています。 ALTOクライアントは、IRDの「cost-types」で「num-routing」という名前を検索して、「num-routing」という名前のコストタイプを取得します。 「resources」の最後のエントリは、「cost-types」で定義された4つの名前すべてを使用します。
Another field defined in "meta" of the example IRD is "default-alto-network-map", which has value "my-default-network-map", which is the resource ID of an ALTO network map that will be defined in "resources".
IRDの例の「メタ」で定義されている別のフィールドは「default-alto-network-map」です。これは、「my-default-network-map」という値を持ちます。これは、で定義されるALTOネットワークマップのリソースIDです。 「リソース」。
The "resources" field of the example IRD defines six information resources. For example, the second entry, which is assigned a resource ID "numerical-routing-cost-map", provides a cost map, as indicated by the media-type "application/alto-costmap+json". The cost map is based on the network map defined with resource ID "my-default-network-map". As another example, the last entry, which is assigned resource ID "endpoint-cost", provides the Endpoint Cost Service, which is indicated by the media-type "application/ alto-endpointcost+json". An ALTO client should use uri "http://alto.example.com/endpointcost/lookup" to access the service.
IRDの例の「リソース」フィールドは、6つの情報リソースを定義します。たとえば、リソースID「numerical-routing-cost-map」が割り当てられている2番目のエントリは、メディアタイプ「application / alto-costmap + json」で示されるコストマップを提供します。コストマップは、リソースID「my-default-network-map」で定義されたネットワークマップに基づいています。別の例として、リソースID「endpoint-cost」が割り当てられている最後のエントリは、メディアタイプ「application / alto-endpointcost + json」で示されるEndpoint Cost Serviceを提供します。 ALTOクライアントは、uri "http://alto.example.com/endpointcost/lookup"を使用してサービスにアクセスする必要があります。
The ALTO client should format its request body to be the "application/alto-endpointcostparams+json" media type, as specified by the "accepts" attribute of the information resource. The "cost-type-names" field of the "capabilities" attribute of the information resource includes four defined cost types specified in the "cost-types" field of "meta" of the IRD. Hence, an ALTO client can verify that the Endpoint Cost information resource supports both cost metrics "routingcost" and "hopcount", each available for both "numerical" and "ordinal" cost modes. When requesting the information resource, an ALTO client can specify cost constraints, as indicated by the "cost-constraints" field of the "capabilities" attribute.
ALTOクライアントは、要求の本文を「application / alto-endpointcostparams + json」メディアタイプにフォーマットし、情報リソースの「accepts」属性で指定する必要があります。情報リソースの「capabilities」属性の「cost-type-names」フィールドには、IRDの「meta」の「cost-types」フィールドで指定された4つの定義済みコストタイプが含まれます。したがって、ALTOクライアントは、エンドポイントコスト情報リソースがコストメトリック「routingcost」と「hopcount」の両方をサポートし、それぞれが「数値」と「通常」の両方のコストモードで使用できることを確認できます。情報リソースを要求するとき、ALTOクライアントは、「capabilities」属性の「cost-constraints」フィールドで示されるように、コスト制約を指定できます。
ALTO IRDs provide the flexibility to define a set of information resources that are provided by ALTO servers running in multiple domains. Consider the preceding example. Assume that the ALTO server running at alto.example.com wants to delegate some information resources to a separate subdomain: "custom.alto.example.com". In particular, assume that the maps available via this subdomain are filtered network maps, filtered cost maps, and some pre-generated maps for the "hopcount" and "routingcost" cost metrics in the "ordinal" cost mode. The fourth entry of "resources" in the preceding example IRD implements the delegation. The entry has a media-type of "application/alto-directory+json", and an ALTO client can discover the information resources available at "custom.alto.example.com" if its request to "http://custom.alto.example.com/maps" is successful:
ALTO IRDは、複数のドメインで実行されているALTOサーバーによって提供される情報リソースのセットを定義する柔軟性を提供します。前の例を考えてみましょう。 alto.example.comで実行されているALTOサーバーが、いくつかの情報リソースを別のサブドメイン「custom.alto.example.com」に委任したいとします。特に、このサブドメインを介して利用できるマップは、フィルター処理されたネットワークマップ、フィルター処理されたコストマップ、および「通常」コストモードの「ホップカウント」および「ルーティングコスト」コストメトリック用に事前に生成されたマップであると想定します。前の例の「リソース」の4番目のエントリは、IRDが委任を実装しています。エントリのメディアタイプは「application / alto-directory + json」であり、「http：//custom.alto」へのリクエストがある場合、ALTOクライアントは「custom.alto.example.com」で利用可能な情報リソースを検出できます。 .example.com / maps "は成功しました：
GET /maps HTTP/1.1
Host: custom.alto.example.com
Accept: application/alto-directory+json,application/alto-error+json
HTTP/1.1 200 OK
Content-Length: 1900
Content-Type: application/alto-directory+json
{
"meta" : {
"cost-types": {
"num-routing": {
"cost-mode" : "numerical",
"cost-metric": "routingcost",
"description": "My default"
},
"num-hop": {
"cost-mode" : "numerical",
"cost-metric": "hopcount"
},
"ord-routing": {
"cost-mode" : "ordinal",
"cost-metric": "routingcost"
},
"ord-hop": {
"cost-mode" : "ordinal",
"cost-metric": "hopcount"
}
}
},
"resources" : {
"filtered-network-map" : {
"uri" : "http://custom.alto.example.com/networkmap/filtered",
"media-type" : "application/alto-networkmap+json",
"accepts" : "application/alto-networkmapfilter+json",
"uses": [ "my-default-network-map" ]
},
"filtered-cost-map" : {
"uri" : "http://custom.alto.example.com/costmap/filtered",
"media-type" : "application/alto-costmap+json",
"accepts" : "application/alto-costmapfilter+json",
"capabilities" : {
"cost-constraints" : true,
"cost-type-names" : [ "num-routing", "num-hop",
"ord-routing", "ord-hop" ]
},
"uses": [ "my-default-network-map" ]
},
"ordinal-routing-cost-map" : {
"uri" : "http://custom.alto.example.com/ord/routingcost",
"media-type" : "application/alto-costmap+json",
"capabilities" : {
"cost-type-names" : [ "ord-routing" ]
},
"uses": [ "my-default-network-map" ]
},
"ordinal-hopcount-cost-map" : {
"uri" : "http://custom.alto.example.com/ord/hopcount",
"media-type" : "application/alto-costmap+json",
"capabilities" : {
"cost-type-names" : [ "ord-hop" ]
},
"uses": [ "my-default-network-map" ]
}
}
}
Note that the subdomain does not define any network maps, and uses the network map with resource ID "my-default-network-map" defined in the Root IRD.
サブドメインはネットワークマップを定義せず、ルートIRDで定義されたリソースID「my-default-network-map」のネットワークマップを使用することに注意してください。
This document specifies no requirements or constraints on ALTO clients with regard to how they process an information resource directory to identify the URI corresponding to a desired information resource. However, some advice is provided for implementers.
このドキュメントでは、ALTOクライアントが情報リソースディレクトリを処理して目的の情報リソースに対応するURIを特定する方法に関して、ALTOクライアントに対する要件や制約を指定していません。ただし、実装者向けにいくつかのアドバイスが提供されています。
It is possible that multiple entries in the directory match a desired information resource. For instance, in the example in Section 9.2.3, a full cost map with the "numerical" cost mode and the "routingcost" cost metric could be retrieved via a GET request to "http://alto.example.com/costmap/num/routingcost" or via a POST request to "http://custom.alto.example.com/costmap/filtered".
ディレクトリ内の複数のエントリが目的の情報リソースと一致する可能性があります。たとえば、セクション9.2.3の例では、「数値」コストモードと「routingcost」コストメトリックを含む完全なコストマップは、「http://alto.example.com/costmap」へのGETリクエストを介して取得できます。 / num / routingcost」または「http://custom.alto.example.com/costmap/filtered」へのPOSTリクエストを介して。
In general, it is preferred for ALTO clients to use GET requests where appropriate, since it is more likely for responses to be cacheable. However, an ALTO client may need to use POST, for example, to get ALTO costs or properties that are for a restricted set of PIDs or endpoints or to update cached information previously acquired via GET requests.
応答がキャッシュ可能になる可能性が高いため、一般に、ALTOクライアントは適切な場所でGET要求を使用することが推奨されます。ただし、ALTOクライアントは、POSTを使用して、たとえば、制限されたPIDまたはエンドポイントのセットに対するALTOコストまたはプロパティを取得したり、GETリクエストによって以前に取得したキャッシュ情報を更新したりする必要がある場合があります。
This document indicates that an ALTO server may or may not provide the information resources specified in the Map-Filtering Service. If these resources are not provided, it is indicated to an ALTO client by the absence of a network map or cost map with any media types listed under "accepts".
このドキュメントは、ALTOサーバーがMap-Filtering Serviceで指定された情報リソースを提供する場合と提供しない場合があることを示しています。これらのリソースが提供されない場合、「accepts」の下にリストされているメディアタイプのネットワークマップまたはコストマップがないことによって、ALTOクライアントに示されます。
This section details the format of basic data types.
このセクションでは、基本的なデータ型の形式について詳しく説明します。
A PID Name is encoded as a JSON string. The string MUST be no more than 64 characters, and it MUST NOT contain characters other than US-ASCII alphanumeric characters (U+0030-U+0039, U+0041-U+005A, and U+0061-U+007A), the hyphen ('-', U+002D), the colon (':', U+003A), the at sign ('@', code point U+0040), the low line ('_', U+005F), or the '.' separator (U+002E). The '.' separator is reserved for future use and MUST NOT be used unless specifically indicated in this document, or an extension document.
PID名はJSON文字列としてエンコードされます。文字列は64文字以下である必要があり、US-ASCII英数字（U + 0030-U + 0039、U + 0041-U + 005A、およびU + 0061-U + 007A）以外の文字を含めることはできません。ハイフン（ '-'、U + 002D）、コロン（ '：'、U + 003A）、アットマーク（ '@'、コードポイントU + 0040）、下線（ '_'、U + 005F ）、 または '。'セパレーター（U + 002E）。 「。」セパレータは将来の使用のために予約されており、このドキュメントまたは拡張ドキュメントで具体的に示されていない限り、使用してはなりません。
The type PIDName is used in this document to indicate a string of this format.
このドキュメントでは、タイプPIDNameを使用して、この形式の文字列を示します。
A resource ID uniquely identifies a particular resource (e.g., an ALTO network map) within an ALTO server (see Section 9.2).
リソースIDは、ALTOサーバー内の特定のリソース（ALTOネットワークマップなど）を一意に識別します（セクション9.2を参照）。
A resource ID is encoded as a JSON string with the same format as that of the type PIDName.
リソースIDは、タイプPIDNameと同じ形式のJSON文字列としてエンコードされます。
The type ResourceID is used in this document to indicate a string of this format.
このドキュメントでは、ResourceIDタイプを使用して、この形式の文字列を示します。
A version tag is defined as:
バージョンタグは次のように定義されます。
object {
ResourceID resource-id;
JSONString tag;
} VersionTag;
As described in Section 6.3, the "resource-id" field provides the resource ID of a resource (e.g., a network map) defined in the information resource directory, and "tag" provides an identifier string.
セクション6.3で説明したように、「resource-id」フィールドは情報リソースディレクトリで定義されたリソース（ネットワークマップなど）のリソースIDを提供し、「tag」は識別子文字列を提供します。
Two version tags are equal if and only if both the "resource-id" fields are byte-for-byte equal and the "tag" fields are byte-for-byte equal.
2つのバージョンタグが等しいのは、両方の「resource-id」フィールドがバイトごとに等しく、「tag」フィールドがバイトごとに等しい場合だけです。
A string representing the "tag" field MUST be no more than 64 characters, and it MUST NOT contain any character below U+0021 or above U+007E. It is RECOMMENDED that the "tag" string have a low collision probability with other tags. One suggested mechanism is to compute it using a hash of the data contents of the resource.
「タグ」フィールドを表す文字列は64文字以下である必要があり、U + 0021以下またはU + 007E以上の文字を含めることはできません。 「タグ」文字列は、他のタグとの衝突確率が低いことが推奨されます。提案されているメカニズムの1つは、リソースのデータ内容のハッシュを使用してそれを計算することです。
This section defines formats used to encode addresses for endpoints. In a case that multiple textual representations encode the same endpoint address or prefix (within the guidelines outlined in this document), the ALTO Protocol does not require ALTO clients or ALTO servers to use a particular textual representation, nor does it require that ALTO servers reply to requests using the same textual representation used by requesting ALTO clients. ALTO clients must be cognizant of this.
このセクションでは、エンドポイントのアドレスをエンコードするために使用される形式を定義します。複数のテキスト表現が同じエンドポイントアドレスまたはプレフィックスをエンコードする場合（このドキュメントで概説されているガイドライン内）、ALTOプロトコルは、ALTOクライアントまたはALTOサーバーが特定のテキスト表現を使用することを要求しません。また、ALTOサーバーが応答することも要求しません。 ALTOクライアントの要求で使用されるのと同じテキスト表現を使用する要求に。 ALTOクライアントはこれを認識している必要があります。
When an endpoint address is used, an ALTO implementation must be able to determine its type. For this purpose, the ALTO Protocol allows endpoint addresses to also explicitly indicate their types. This document refers to such addresses as "Typed Endpoint Addresses".
エンドポイントアドレスが使用される場合、ALTO実装はそのタイプを判別できる必要があります。この目的のために、ALTOプロトコルでは、エンドポイントアドレスがそのタイプも明示的に示すことができます。このドキュメントでは、「型付きエンドポイントアドレス」などのアドレスを参照しています。
Typed endpoint addresses are encoded as strings of the format AddressType:EndpointAddr, with the ':' character as a separator. The type TypedEndpointAddr is used to indicate a string of this format.
入力されたエンドポイントアドレスは、AddressType：EndpointAddr形式の文字列としてエンコードされ、区切り文字として「：」文字が使用されます。 TypedEndpointAddr型は、この形式の文字列を示すために使用されます。
The AddressType component of TypedEndPointAddr is defined as a string consisting of only US-ASCII alphanumeric characters (U+0030-U+0039, U+0041-U+005A, and U+0061-U+007A). The type AddressType is used in this document to indicate a string of this format.
TypedEndPointAddrのAddressTypeコンポーネントは、US-ASCIIの英数字（U + 0030-U + 0039、U + 0041-U + 005A、およびU + 0061-U + 007A）のみで構成される文字列として定義されます。このドキュメントでは、タイプAddressTypeを使用して、この形式の文字列を示します。
This document defines two values for AddressType: "ipv4" to refer to IPv4 addresses and "ipv6" to refer to IPv6 addresses. All AddressType identifiers appearing in an HTTP request or response with an "application/alto-*" media type MUST be registered in the "ALTO Address Type Registry" (see Section 14.4).
このドキュメントでは、AddressTypeの2つの値を定義しています。「ipv4」はIPv4アドレスを指し、「ipv6」はIPv6アドレスを指します。 「application / alto- *」メディアタイプのHTTPリクエストまたはレスポンスに現れるすべてのAddressType識別子は、「ALTOアドレスタイプレジストリ」に登録する必要があります（セクション14.4を参照）。
The EndpointAddr component of TypedEndPointAddr is also encoded as a string. The exact characters and format depend on AddressType. This document defines EndpointAddr when AddressType is "ipv4" or "ipv6".
TypedEndPointAddrのEndpointAddrコンポーネントも文字列としてエンコードされます。正確な文字と形式は、AddressTypeによって異なります。このドキュメントでは、AddressTypeが「ipv4」または「ipv6」の場合のEndpointAddrを定義します。
IPv4 Endpoint Addresses are encoded as specified by the IPv4address rule in Section 3.2.2 of [RFC3986].
IPv4エンドポイントアドレスは、[RFC3986]のセクション3.2.2のIPv4addressルールの指定に従ってエンコードされます。
IPv6 endpoint addresses are encoded as specified in Section 4 of [RFC5952].
IPv6エンドポイントアドレスは、[RFC5952]のセクション4で指定されているようにエンコードされます。
For efficiency, it is useful to denote a set of endpoint addresses using a special notation (if one exists). This specification makes use of the prefix notations for both IPv4 and IPv6 for this purpose.
効率を上げるには、特別な表記法（存在する場合）を使用してエンドポイントアドレスのセットを示すと便利です。この仕様では、この目的でIPv4とIPv6の両方のプレフィックス表記を使用しています。
Endpoint prefixes are encoded as strings. The exact characters and format depend on the type of endpoint address.
エンドポイントプレフィックスは文字列としてエンコードされます。正確な文字と形式は、エンドポイントアドレスのタイプによって異なります。
The type EndpointPrefix is used in this document to indicate a string of this format.
このドキュメントでは、EndpointPrefixタイプを使用して、この形式の文字列を示します。
IPv4 endpoint prefixes are encoded as specified in Section 3.1 of [RFC4632].
IPv4エンドポイントプレフィックスは、[RFC4632]のセクション3.1で指定されているようにエンコードされます。
IPv6 endpoint prefixes are encoded as specified in Section 7 of [RFC5952].
IPv6エンドポイントプレフィックスは、[RFC5952]のセクション7で指定されているようにエンコードされます。
The ALTO Protocol includes messages that specify potentially large sets of endpoint addresses. Endpoint address groups provide a more efficient way to encode such sets, even when the set contains endpoint addresses of different types.
ALTOプロトコルには、潜在的に大きなエンドポイントアドレスのセットを指定するメッセージが含まれています。エンドポイントアドレスグループは、セットに異なるタイプのエンドポイントアドレスが含まれている場合でも、そのようなセットをより効率的にエンコードする方法を提供します。
An endpoint address group is defined as:
エンドポイントアドレスグループは次のように定義されます。
object-map {
AddressType -> EndpointPrefix<0..*>;
} EndpointAddrGroup;
In particular, an endpoint address group is a JSON object representing a map, where each key is the string corresponding to an address type, and the corresponding value is an array listing prefixes of addresses of that type.
特に、エンドポイントアドレスグループは、マップを表すJSONオブジェクトであり、各キーはアドレスタイプに対応する文字列であり、対応する値はそのタイプのアドレスのプレフィックスをリストする配列です。
The following is an example with both IPv4 and IPv6 endpoint addresses:
以下は、IPv4とIPv6の両方のエンドポイントアドレスの例です。
{
"ipv4": [
"192.0.2.0/24",
"198.51.100.0/25"
],
"ipv6": [
"2001:db8:0:1::/64",
"2001:db8:0:2::/64"
]
}
A cost mode is encoded as a string. The string MUST have a value of either "numerical" or "ordinal".
コストモードは文字列としてエンコードされます。文字列には、「数値」または「序数」のいずれかの値が必要です。
The type CostMode is used in this document to indicate a string of this format.
このドキュメントでは、タイプCostModeを使用して、この形式の文字列を示します。
A cost metric is encoded as a string. The string MUST be no more than 32 characters, and it MUST NOT contain characters other than US-ASCII alphanumeric characters (U+0030-U+0039, U+0041-U+005A, and U+0061-U+007A), the hyphen ('-', U+002D), the colon (':', U+003A), the low line ('_', U+005F), or the '.' separator (U+002E). The '.' separator is reserved for future use and MUST NOT be used unless specifically indicated by a companion or extension document.
コストメトリックは文字列としてエンコードされます。文字列は32文字以下にする必要があり、US-ASCII英数字（U + 0030-U + 0039、U + 0041-U + 005A、およびU + 0061-U + 007A）以外の文字を含めることはできません。ハイフン（ '-'、U + 002D）、コロン（ '：'、U + 003A）、下線（ '_'、U + 005F）、または '。'セパレーター（U + 002E）。 「。」セパレータは将来の使用のために予約されており、コンパニオンドキュメントまたは拡張ドキュメントで特に示されていない限り、使用してはなりません。
Identifiers prefixed with "priv:" are reserved for Private Use [RFC5226] without a need to register with IANA. All other identifiers that appear in an HTTP request or response with an "application/alto-*" media type and indicate cost metrics MUST be registered in the "ALTO Cost Metric Registry" Section 14.2. For an identifier with the "priv:" prefix, an additional string (e.g., company identifier or random string) MUST follow (i.e., "priv:" only is not a valid identifier) to reduce potential collisions.
「priv：」で始まる識別子は、IANAに登録する必要なしに、私的使用[RFC5226]のために予約されています。 「application / alto- *」メディアタイプのHTTPリクエストまたはレスポンスに含まれ、コストメトリックを示す他のすべての識別子は、「ALTOコストメトリックレジストリ」セクション14.2に登録する必要があります。プレフィックスが「priv：」の識別子の場合、潜在的な衝突を減らすために、追加の文字列（会社の識別子やランダムな文字列など）を続ける必要があります（つまり、「priv：」だけは有効な識別子ではありません）。
The type CostMetric is used in this document to indicate a string of this format.
このドキュメントでは、タイプCostMetricを使用して、この形式の文字列を示します。
The combination of CostMetric and CostMode defines the type CostType:
CostMetricとCostModeの組み合わせにより、タイプCostTypeが定義されます。
object {
CostMetric cost-metric;
CostMode cost-mode;
[JSONString description;]
} CostType;
The "description" field, if present, MUST provide a string value with a human-readable description of the cost-metric and cost-mode. An ALTO client MAY present this string to a developer, as part of a discovery process; however, the field is not intended to be interpreted by an ALTO client.
「description」フィールドは、存在する場合、人間が読めるコストメトリックとコストモードの説明を文字列値に提供する必要があります。 ALTOクライアントは、発見プロセスの一部として、この文字列を開発者に提示してもよい（MAY）。ただし、フィールドはALTOクライアントによって解釈されることを意図していません。
This document distinguishes two types of endpoint properties: resource-specific endpoint properties and global endpoint properties. The type EndpointPropertyType is used in this document to indicate a string denoting either a resource-specific endpoint property or a global endpoint property.
このドキュメントでは、リソース固有のエンドポイントプロパティとグローバルエンドポイントプロパティの2種類のエンドポイントプロパティを区別しています。このドキュメントでは、EndpointPropertyType型を使用して、リソース固有のエンドポイントプロパティまたはグローバルエンドポイントプロパティを示す文字列を示します。
The name of resource-specific endpoint property MUST follow this format: a resource ID, followed by the '.' separator (U+002E), followed by a name obeying the same rules as for global endpoint property names (Section 10.8.2).
リソース固有のエンドポイントプロパティの名前は、次の形式に従う必要があります：リソースIDの後に「。」セパレーター（U + 002E）、グローバルエンドポイントプロパティ名（10.8.2項）と同じ規則に従う名前が続きます。
This document defines only one resource-specific endpoint property: pid. An example is "my-default-networkmap.pid".
このドキュメントでは、1つのリソース固有のエンドポイントプロパティ（pid）のみを定義しています。例は「my-default-networkmap.pid」です。
A global endpoint property is encoded as a string. The string MUST be no more than 32 characters, and it MUST NOT contain characters other than US-ASCII alphanumeric characters (U+0030-U+0039, U+0041-U+005A, and U+0061-U+007A), the hyphen ('-', U+002D), the colon (':', U+003A), or the low line ('_', U+005F). Note that the '.' separator is not allowed so that there is no ambiguity on whether an endpoint property is global or resource specific.
グローバルエンドポイントプロパティは文字列としてエンコードされます。文字列は32文字以下にする必要があり、US-ASCII英数字（U + 0030-U + 0039、U + 0041-U + 005A、およびU + 0061-U + 007A）以外の文字を含めることはできません。ハイフン（ '-'、U + 002D）、コロン（ '：'、U + 003A）、または下線（ '_'、U + 005F）。 「。」セパレーターは許可されないため、エンドポイントプロパティがグローバルであるかリソース固有であるかが明確になります。
Identifiers prefixed with "priv:" are reserved for Private Use [RFC5226] without a need to register with IANA. All other identifiers for endpoint properties appearing in an HTTP request or response with an "application/alto-*" media type MUST be registered in the "ALTO Endpoint Property Type Registry" Section 14.3. For an endpoint property identifier with the "priv:" prefix, an additional string (e.g., company identifier or random string) MUST follow (i.e., "priv:" only is not a valid endpoint property identifier) to reduce potential collisions.
「priv：」で始まる識別子は、IANAに登録する必要なしに、私的使用[RFC5226]のために予約されています。 「application / alto- *」メディアタイプのHTTPリクエストまたはレスポンスに表示されるエンドポイントプロパティの他のすべての識別子は、「ALTOエンドポイントプロパティタイプレジストリ」セクション14.3に登録する必要があります。プレフィックスが「priv：」のエンドポイントプロパティ識別子の場合、潜在的な衝突を減らすために、追加の文字列（例：会社識別子またはランダム文字列）が続く必要があります（つまり、「priv：」のみが有効なエンドポイントプロパティ識別子ではありません）。
This section documents the individual information resources defined to provide the services defined in this document.
このセクションでは、このドキュメントで定義されているサービスを提供するために定義されている個々の情報リソースについて説明します。
For the "meta" field of the response to an individual information resource, this document defines two generic fields: the "vtag" field, which provides the version tag (see Section 10.3) of the current information resource, and the "dependent-vtags" field, which is an array of version tags, to indicate the version tags of the resources on which this resource depends.
個々の情報リソースへの応答の「メタ」フィールドについて、このドキュメントは2つの一般的なフィールドを定義します：現在の情報リソースのバージョンタグ（セクション10.3を参照）を提供する「vtag」フィールドと「dependent-vtags」 "フィールドはバージョンタグの配列であり、このリソースが依存するリソースのバージョンタグを示します。
The Map Service provides batch information to ALTO clients in the form of two types of maps: ALTO network maps and ALTO cost maps.
マップサービスは、ALTOネットワークマップとALTOコストマップの2種類のマップの形式でバッチ情報をALTOクライアントに提供します。
An ALTO network map information resource defines a set of PIDs, and for each PID, lists the network locations (endpoints) within the PID. An ALTO server MUST provide at least one network map.
ALTOネットワークマップ情報リソースは、一連のPIDを定義し、PIDごとに、PID内のネットワークロケーション（エンドポイント）をリストします。 ALTOサーバーは、少なくとも1つのネットワークマップを提供する必要があります。
The media type of ALTO network maps is "application/alto-networkmap+json".
ALTOネットワークマップのメディアタイプは「application / alto-networkmap + json」です。
An ALTO network map resource is requested using the HTTP GET method.
ALTOネットワークマップリソースは、HTTP GETメソッドを使用して要求されます。
None.
なし。
None.
なし。
None.
なし。
The "meta" field of an ALTO network map response MUST include the "vtag" field, which provides the version tag of the retrieved network map.
ALTOネットワークマップ応答の「メタ」フィールドには、取得したネットワークマップのバージョンタグを提供する「vtag」フィールドを含める必要があります。
The data component of an ALTO network map response is named "network-map", which is a JSON object of type NetworkMapData:
ALTOネットワークマップレスポンスのデータコンポーネントの名前は「network-map」で、タイプはNetworkMapDataのJSONオブジェクトです。
object {
NetworkMapData network-map;
} InfoResourceNetworkMap : ResponseEntityBase;
object-map {
PIDName -> EndpointAddrGroup;
} NetworkMapData;
Specifically, a NetworkMapData object is a dictionary map keyed by PIDs. The value of each PID is the associated set of endpoint addresses for the PID.
具体的には、NetworkMapDataオブジェクトは、PIDをキーとするディクショナリマップです。各PIDの値は、PIDに関連付けられたエンドポイントアドレスのセットです。
The returned network map MUST include all PIDs known to the ALTO server.
返されるネットワークマップには、ALTOサーバーに認識されているすべてのPIDを含める必要があります。
GET /networkmap HTTP/1.1
Host: alto.example.com
Accept: application/alto-networkmap+json,application/alto-error+json
HTTP/1.1 200 OK
Content-Length: 449
Content-Type: application/alto-networkmap+json
{
"meta" : {
"vtag": {
"resource-id": "my-default-network-map",
"tag": "da65eca2eb7a10ce8b059740b0b2e3f8eb1d4785"
}
},
"network-map" : {
"PID1" : {
"ipv4" : [
"192.0.2.0/24",
"198.51.100.0/25"
]
},
"PID2" : {
"ipv4" : [
"198.51.100.128/25"
]
},
"PID3" : {
"ipv4" : [
"0.0.0.0/0"
],
"ipv6" : [
"::/0"
]
}
}
}
When parsing an ALTO network map, an ALTO client MUST ignore any EndpointAddressGroup whose address type it does not recognize. If as a result a PID does not have any address types known to the client, the client still MUST recognize that PID name as valid, even though the PID then contains no endpoints.
ALTOネットワークマップを解析する場合、ALTOクライアントは、認識できないアドレスタイプのEndpointAddressGroupを無視する必要があります。その結果、PIDにクライアントが認識できるアドレスタイプがない場合でも、PIDにエンドポイントが含まれていなくても、クライアントはそのPID名を有効であると認識しなければなりません（MUST）。
Note that the encoding of an ALTO network map response was chosen for readability and compactness. If lookup efficiency at runtime is crucial, then the returned network map can be transformed into data structures offering more efficient lookup. For example, one may store an ALTO network map as a trie-based data structure, which may allow efficient longest-prefix matching of IP addresses.
ALTOネットワークマップ応答のエンコーディングは、読みやすさとコンパクトさのために選択されていることに注意してください。実行時のルックアップ効率が重要な場合は、返されたネットワークマップをより効率的なルックアップを提供するデータ構造に変換できます。たとえば、ALTOネットワークマップをトライベースのデータ構造として保存すると、IPアドレスの最長プレフィックスマッチングを効率的に行うことができます。
A key usage of an ALTO network map is to map endpoint addresses to PIDs. For network maps containing the "ipv4" and "ipv6" address types defined in this document, when either an ALTO client or an ALTO server needs to compute the mapping from IP addresses to PIDs, the longest-prefix matching algorithm (Longest Match in Section 5.2.4.3 of [RFC1812]) MUST be used.
ALTOネットワークマップの主な用途は、エンドポイントアドレスをPIDにマップすることです。このドキュメントで定義されている「ipv4」および「ipv6」アドレスタイプを含むネットワークマップの場合、ALTOクライアントまたはALTOサーバーがIPアドレスからPIDへのマッピングを計算する必要がある場合、最長プレフィックスマッチングアルゴリズム（セクションの最長一致） [RFC1812]の5.2.4.3）を使用する必要があります。
To ensure that the longest-prefix matching algorithm yields one and only one PID, an ALTO network map containing the "ipv4"/"ipv6" address types MUST satisfy the following two requirements.
最長プレフィックスマッチングアルゴリズムでPIDが1つだけ生成されるようにするには、「ipv4」/「ipv6」アドレスタイプを含むALTOネットワークマップが次の2つの要件を満たしている必要があります。
First, such a network map MUST define a PID for each possible address in the IP address space for all of the address types contained in the map. This is defined as the completeness property of an ALTO network map. A RECOMMENDED way to satisfy this property is to define a PID with the shortest enclosing prefix of the addresses provided in the map. For a map with full IPv4 reachability, this would mean including the 0.0.0.0/0 prefix in a PID; for full IPv6 reachability, this would be the ::/0 prefix.
最初に、そのようなネットワークマップは、マップに含まれるすべてのアドレスタイプのIPアドレス空間で可能な各アドレスのPIDを定義する必要があります。これは、ALTOネットワークマップの完全性プロパティとして定義されます。このプロパティを満たすための推奨される方法は、マップで提供されるアドレスの最も短い囲みプレフィックスでPIDを定義することです。完全なIPv4到達可能性を持つマップの場合、これはPIDに0.0.0.0/0プレフィックスを含めることを意味します。完全なIPv6到達可能性の場合、これは:: / 0プレフィックスになります。
Second, such a network map MUST NOT define two or more PIDs that contain an identical IP prefix, in order to ensure that the longest-prefix matching algorithm maps each IP addresses into exactly one PID. This is defined as the non-overlapping property of an ALTO network map. Specifically, to map an IP address to its PID in a non-overlapping network map, one considers the set S, which consists of all prefixes defined in the network map, applies the longest-prefix mapping algorithm to S to identify the longest prefix containing the IP address and assigns that prefix the IP address belonging to the PID containing the identified longest prefix.
第二に、最長プレフィックス一致アルゴリズムが各IPアドレスを正確に1つのPIDにマップすることを保証するために、そのようなネットワークマップは、同一のIPプレフィックスを含む2つ以上のPIDを定義してはなりません。これは、ALTOネットワークマップの重複しないプロパティとして定義されます。具体的には、重複しないネットワークマップでIPアドレスをそのPIDにマップするには、ネットワークマップで定義されたすべてのプレフィックスで構成されるセットSを考慮し、最長プレフィックスマッピングアルゴリズムをSに適用して、 IPアドレス。そのプレフィックスに、識別された最長のプレフィックスを含むPIDに属するIPアドレスを割り当てます。
The following example shows a complete and non-overlapping ALTO network map:
次の例は、完全で重複しないALTOネットワークマップを示しています。
"network-map" : {
"PID0" : { "ipv6" : [ "::/0" ] },
"PID1" : { "ipv4" : [ "0.0.0.0/0" ] },
"PID2" : { "ipv4" : [ "192.0.2.0/24", "198.51.100.0/24" ] },
"PID3" : { "ipv4" : [ "192.0.2.0/25", "192.0.2.128/25" ] }
}
The IP address 192.0.2.1 should be mapped to PID3.
IPアドレス192.0.2.1はPID3にマッピングする必要があります。
If, however, the two adjacent prefixes in PID3 were combined as a single prefix, then PID3 was changed to:
ただし、PID3の2つの隣接するプレフィックスが単一のプレフィックスとして結合された場合、PID3は次のように変更されました。
"PID3" : { "ipv4" : [ "192.0.2.0/24" ] }
The new map is no longer non-overlapping, and 192.0.2.1 could no longer be mapped unambiguously to a PID by means of longest-prefix matching.
新しいマップは重複しなくなり、192.0.2.1は最長プレフィックスマッチングによってPIDに明確にマッピングできなくなりました。
Extension documents may define techniques to allow a single IP address being mapped to multiple PIDs, when a need is identified.
拡張ドキュメントは、ニーズが特定されたときに、単一のIPアドレスを複数のPIDにマップできるようにする手法を定義する場合があります。
An ALTO cost map resource lists the path cost for each pair of source/destination PIDs defined by the ALTO server for a given cost metric and cost mode. This resource MUST be provided for at least the "routingcost" cost metric.
ALTOコストマップリソースは、特定のコストメトリックとコストモードについて、ALTOサーバーによって定義されたソース/宛先PIDの各ペアのパスコストをリストします。このリソースは、少なくとも「routingcost」コストメトリックに対して提供する必要があります。
The media type of ALTO cost maps is "application/alto-costmap+json".
ALTOコストマップのメディアタイプは、「application / alto-costmap + json」です。
An ALTO cost map resource is requested using the HTTP GET method.
ALTOコストマップリソースは、HTTP GETメソッドを使用して要求されます。
None.
なし。
The capabilities of an ALTO server URI providing an unfiltered cost map is a JSON object of type CostMapCapabilities:
フィルターされていないコストマップを提供するALTOサーバーURIの機能は、タイプCostMapCapabilitiesのJSONオブジェクトです。
object {
JSONString cost-type-names<1..1>;
} CostMapCapabilities;
with field:
フィールド付き：
cost-type-names: Note that the array MUST include a single CostType name defined by the "cost-types" field in the "meta" field of the IRD. This is because an unfiltered cost map (accept == "") is requested via an HTTP GET that accepts no input parameters. As a contrast, for filtered cost maps (see Section 11.3.2), the array can have multiple elements.
cost-type-names：配列には、IRDの「meta」フィールドの「cost-types」フィールドで定義された単一のCostType名を含める必要があることに注意してください。これは、入力パラメーターを受け入れないHTTP GETを介して、フィルター処理されていないコストマップ（受け入れ== ""）が要求されるためです。対照的に、フィルターされたコストマップ（セクション11.3.2を参照）では、配列に複数の要素を含めることができます。
The resource ID of the network map based on which the cost map will be defined. Recall (Section 6) that the combination of a network map and a cost type defines a key. In other words, an ALTO server MUST NOT define two cost maps with the same cost type / network map pair.
コストマップの定義に基づくネットワークマップのリソースID。ネットワークマップとコストタイプの組み合わせがキーを定義することを思い出してください（セクション6）。言い換えると、ALTOサーバーは、同じコストタイプとネットワークマップのペアで2つのコストマップを定義してはなりません（MUST NOT）。
The "meta" field of a cost map response MUST include the "dependent-vtags" field, whose value is a single-element array to indicate the version tag of the network map used, where the network map is specified in "uses" of the IRD. The "meta" MUST also include the "cost-type" field, whose value indicates the cost type (Section 10.7) of the cost map.
コストマップレスポンスの「meta」フィールドには、「dependent-vtags」フィールドを含める必要があります。このフィールドの値は、使用されるネットワークマップのバージョンタグを示す単一要素の配列です。ネットワークマップは、「uses」で指定されています。 IRD。 「メタ」には、「コストタイプ」フィールドも含める必要があります。このフィールドの値は、コストマップのコストタイプ（セクション10.7）を示します。
The data component of a cost map response is named "cost-map", which is a JSON object of type CostMapData:
コストマップレスポンスのデータコンポーネントの名前は「cost-map」で、タイプはCostMapDataのJSONオブジェクトです。
object {
CostMapData cost-map;
} InfoResourceCostMap : ResponseEntityBase;
object-map {
PIDName -> DstCosts;
} CostMapData;
object-map {
PIDName -> JSONValue;
} DstCosts;
Specifically, a CostMapData object is a dictionary map object, with each key being the PIDName string identifying the corresponding source PID, and value being a type of DstCosts, which denotes the associated costs from the source PID to a set of destination PIDs (Section 6.2). An implementation of the protocol in this document SHOULD assume that the cost is a JSONNumber and fail to parse if it is not, unless the implementation is using an extension to this document that indicates when and how costs of other data types are signaled.
具体的には、CostMapDataオブジェクトはディクショナリマップオブジェクトであり、各キーは対応するソースPIDを識別するPIDName文字列であり、値はDstCostsのタイプであり、ソースPIDから一連の宛先PIDへの関連コストを示します（セクション6.2 ）。このドキュメントのプロトコルの実装では、コストがJSONNumberであると想定し、そうでない場合は解析に失敗する必要があります。ただし、他のデータ型のコストがいつどのように通知されるかを示すこのドキュメントの拡張機能を実装が使用している場合を除きます。
The returned cost map MUST include the path cost for each (source PID, destination PID) pair for which a path cost is defined. An ALTO server MAY omit entries for which path costs are not defined (e.g., either the source or the destination PIDs contain addresses outside of the network provider's administrative domain).
返されるコストマップには、パスコストが定義されている各（ソースPID、宛先PID）ペアのパスコストを含める必要があります。 ALTOサーバーは、パスコストが定義されていないエントリを省略できます（たとえば、ソースまたは宛先のPIDに、ネットワークプロバイダーの管理ドメイン外のアドレスが含まれている場合があります）。
Similar to the encoding of ALTO network maps, the encoding of ALTO cost maps was chosen for readability and compactness. If lookup efficiency at runtime is crucial, then the returned cost map can be transformed into data structures offering more efficient lookup. For example, one may store a cost map as a matrix.
ALTOネットワークマップのエンコーディングと同様に、ALTOコストマップのエンコーディングは、読みやすさとコンパクトさのために選択されました。実行時のルックアップ効率が重要な場合は、返されたコストマップをより効率的なルックアップを提供するデータ構造に変換できます。たとえば、コストマップを行列として保存できます。
GET /costmap/num/routingcost HTTP/1.1
Host: alto.example.com
Accept: application/alto-costmap+json,application/alto-error+json
HTTP/1.1 200 OK
Content-Length: 435
Content-Type: application/alto-costmap+json
{
"meta" : {
"dependent-vtags" : [
{"resource-id": "my-default-network-map",
"tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e"
}
],
"cost-type" : {"cost-mode" : "numerical",
"cost-metric": "routingcost"
}
},
"cost-map" : {
"PID1": { "PID1": 1, "PID2": 5, "PID3": 10 },
"PID2": { "PID1": 5, "PID2": 1, "PID3": 15 },
"PID3": { "PID1": 20, "PID2": 15 }
}
}
Similar to the network map case, array-based encoding for "map" was considered, but the current encoding was chosen for clarity.
ネットワークマップの場合と同様に、「マップ」の配列ベースのエンコーディングが考慮されましたが、明確にするために現在のエンコーディングが選択されました。
The Map-Filtering Service allows ALTO clients to specify filtering criteria to return a subset of a full map available in the Map Service.
Map-Filtering Serviceを使用すると、ALTOクライアントはフィルタリング基準を指定して、Map Serviceで使用可能なフルマップのサブセットを返すことができます。
A filtered ALTO network map is an ALTO network map information resource (Section 11.2.1) for which an ALTO client may supply a list of PIDs to be included. A filtered ALTO network map MAY be provided by an ALTO server.
フィルタリングされたALTOネットワークマップは、ALTOクライアントが含めるPIDのリストを提供できるALTOネットワークマップ情報リソース（セクション11.2.1）です。フィルタリングされたALTOネットワークマップは、ALTOサーバーによって提供される場合があります。
Since a filtered ALTO network map is still an ALTO network map, it uses the media type defined for ALTO network maps at Section 11.2.1.1.
フィルター処理されたALTOネットワークマップは、まだALTOネットワークマップであるため、セクション11.2.1.1でALTOネットワークマップに対して定義されたメディアタイプを使用します。
A filtered ALTO network map is requested using the HTTP POST method.
フィルターされたALTOネットワークマップは、HTTP POSTメソッドを使用して要求されます。
An ALTO client supplies filtering parameters by specifying media type "application/alto-networkmapfilter+json" with HTTP POST body containing a JSON object of type ReqFilteredNetworkMap, where:
ALTOクライアントは、ReqFilteredNetworkMapタイプのJSONオブジェクトを含むHTTP POST本文でメディアタイプ「application / alto-networkmapfilter + json」を指定することにより、フィルタリングパラメーターを提供します。ここで、
object {
PIDName pids<0..*>;
[AddressType address-types<0..*>;]
} ReqFilteredNetworkMap;
with fields:
フィールド付き：
pids: Specifies list of PIDs to be included in the returned filtered network map. If the list of PIDs is empty, the ALTO server MUST interpret the list as if it contained a list of all currently defined PIDs. The ALTO server MUST interpret entries appearing multiple times as if they appeared only once.
pids：返されたフィルター済みネットワークマップに含まれるPIDのリストを指定します。 PIDのリストが空の場合、ALTOサーバーはそのリストを、現在定義されているすべてのPIDのリストが含まれているかのように解釈する必要があります。 ALTOサーバーは、複数回出現するエントリを、1回だけ出現するかのように解釈する必要があります。
address-types: Specifies a list of address types to be included in the returned filtered network map. If the "address-types" field is not specified, or the list of address types is empty, the ALTO server MUST interpret the list as if it contained a list of all address types known to the ALTO server. The ALTO server MUST interpret entries appearing multiple times as if they appeared only once.
address-types：返されたフィルター済みネットワークマップに含まれるアドレスタイプのリストを指定します。 「address-types」フィールドが指定されていない場合、またはアドレスタイプのリストが空の場合、ALTOサーバーは、リストがALTOサーバーに既知のすべてのアドレスタイプのリストを含んでいるかのように解釈する必要があります。 ALTOサーバーは、複数回出現するエントリを、1回だけ出現するかのように解釈する必要があります。
None.
なし。
The resource ID of the network map based on which the filtering is performed.
フィルタリングの基準となるネットワークマップのリソースID。
The format is the same as unfiltered network maps. See Section 11.2.1.6 for the format.
フォーマットは、フィルタリングされていないネットワークマップと同じです。形式については、セクション11.2.1.6を参照してください。
The ALTO server MUST only include PIDs in the response that were specified (implicitly or explicitly) in the request. If the input parameters contain a PID name that is not currently defined by the ALTO server, the ALTO server MUST behave as if the PID did not appear in the input parameters. Similarly, the ALTO server MUST only enumerate addresses within each PID that have types specified (implicitly or explicitly) in the request. If the input parameters contain an address type that is not currently known to the ALTO server, the ALTO server MUST behave as if the address type did not appear in the input parameters.
ALTOサーバーは、要求で（暗黙的または明示的に）指定された応答にのみPIDを含める必要があります。入力パラメーターに、現在ALTOサーバーで定義されていないPID名が含まれている場合、ALTOサーバーは、PIDが入力パラメーターに表示されなかったかのように動作する必要があります。同様に、ALTOサーバーは、要求で（暗黙的または明示的に）タイプが指定されている各PID内のアドレスのみを列挙する必要があります。入力パラメーターに現在ALTOサーバーで認識されていないアドレスタイプが含まれている場合、ALTOサーバーは、アドレスタイプが入力パラメーターに表示されなかったかのように動作する必要があります。
The version tag included in the "vtag" field of the response MUST correspond to the full (unfiltered) network map information resource from which the filtered information is provided. This ensures that a single, canonical version tag is used independent of any filtering that is requested by an ALTO client.
応答の「vtag」フィールドに含まれるバージョンタグは、フィルタリングされた情報が提供される完全な（フィルタリングされていない）ネットワークマップ情報リソースに対応している必要があります。これにより、ALTOクライアントによって要求されるフィルタリングとは関係なく、単一の正規バージョンタグが使用されることが保証されます。
POST /networkmap/filtered HTTP/1.1
Host: custom.alto.example.com
Content-Length: 33
Content-Type: application/alto-networkmapfilter+json
Accept: application/alto-networkmap+json,application/alto-error+json
{
"pids": [ "PID1", "PID2" ]
}
HTTP/1.1 200 OK
Content-Length: 342
Content-Type: application/alto-networkmap+json
{
"meta" : {
"vtag" : {
"resource-id": "my-default-network-map",
"tag": "c0ce023b8678a7b9ec00324673b98e54656d1f6d"
}
},
"network-map" : {
"PID1" : {
"ipv4" : [
"192.0.2.0/24",
"198.51.100.0/24"
]
},
"PID2" : {
"ipv4": [
"198.51.100.128/24"
]
}
}
}
A filtered ALTO cost map is a cost map information resource (Section 11.2.3) for which an ALTO client may supply additional parameters limiting the scope of the resulting cost map. A filtered ALTO cost map MAY be provided by an ALTO server.
フィルターされたALTOコストマップは、ALTOクライアントが結果のコストマップの範囲を制限する追加のパラメーターを提供できるコストマップ情報リソース（セクション11.2.3）です。フィルタリングされたALTOコストマップは、ALTOサーバーによって提供される場合があります。
Since a filtered ALTO cost map is still an ALTO cost map, it uses the media type defined for ALTO cost maps at Section 11.2.3.1.
フィルタリングされたALTOコストマップはまだALTOコストマップであるため、セクション11.2.3.1でALTOコストマップに対して定義されたメディアタイプを使用します。
A filtered ALTO cost map is requested using the HTTP POST method.
フィルターされたALTOコストマップは、HTTP POSTメソッドを使用して要求されます。
The input parameters for a filtered cost map are supplied in the entity body of the POST request. This document specifies the input parameters with a data format indicated by the media type "application/alto-costmapfilter+json", which is a JSON object of type ReqFilteredCostMap, where:
フィルターされたコストマップの入力パラメーターは、POSTリクエストのエンティティ本体で提供されます。このドキュメントでは、ReqFilteredCostMapタイプのJSONオブジェクトであるメディアタイプ「application / alto-costmapfilter + json」で示されるデータ形式で入力パラメーターを指定します。ここで、
object {
CostType cost-type;
[JSONString constraints<0..*>;]
[PIDFilter pids;]
} ReqFilteredCostMap;
object {
PIDName srcs<0..*>;
PIDName dsts<0..*>;
} PIDFilter;
with fields:
フィールド付き：
cost-type: The CostType (Section 10.7) for the returned costs. The "cost-metric" and "cost-mode" fields MUST match one of the supported cost types indicated in this resource's "capabilities" field (Section 11.3.2.4). The ALTO client SHOULD omit the "description" field, and if present, the ALTO server MUST ignore the "description" field.
cost-type：返されるコストのCostType（セクション10.7）。 "cost-metric"および "cost-mode"フィールドは、このリソースの "capabilities"フィールド（セクション11.3.2.4）で示されているサポートされているコストタイプの1つと一致する必要があります。 ALTOクライアントは「説明」フィールドを省略してください。存在する場合、ALTOサーバーは「説明」フィールドを無視する必要があります。
constraints: Defines a list of additional constraints on which elements of the cost map are returned. This parameter MUST NOT be specified if this resource's "capabilities" field (Section 11.3.2.4) indicate that constraint support is not available. A constraint contains two entities separated by whitespace: (1) an operator, "gt" for greater than, "lt" for less than, "ge" for greater than or equal to, "le" for less than or equal to, or "eq" for equal to and (2) a target cost value. The cost value is a number that MUST be defined in the same units as the cost metric indicated by the "cost-metric" parameter. ALTO servers SHOULD use at least IEEE 754 double-precision floating point [IEEE.754.2008] to store the cost value, and SHOULD perform internal computations using double-precision floating-point arithmetic. If multiple "constraint" parameters are specified, they are interpreted as being related to each other with a logical AND.
制約：コストマップの要素が返される追加の制約のリストを定義します。このリソースの「機能」フィールド（セクション11.3.2.4）が制約のサポートが利用できないことを示している場合、このパラメータを指定してはなりません（MUST NOT）。制約には、空白で区切られた2つのエンティティが含まれます。（1）演算子、「gt」より大きい、「lt」未満、「ge」以上、「le」以下、または「eq」は、（2）に等しい、および目標コスト値。コスト値は、「cost-metric」パラメーターで示されたコストメトリックと同じ単位で定義する必要がある数値です。 ALTOサーバーは、コスト値を格納するために少なくともIEEE 754倍精度浮動小数点[IEEE.754.2008]を使用する必要があり（SHOULD）、倍精度浮動小数点演算を使用して内部計算を実行する必要があります（SHOULD）。複数の「制約」パラメーターが指定されている場合、それらは論理ANDで相互に関連していると解釈されます。
pids: A list of source PIDs and a list of destination PIDs for which path costs are to be returned. If a list is empty, the ALTO server MUST interpret it as the full set of currently defined PIDs. The ALTO server MUST interpret entries appearing in a list multiple times as if they appeared only once. If the "pids" field is not present, both lists MUST be interpreted by the ALTO server as containing the full set of currently defined PIDs.
pids：パスコストが返されるソースPIDのリストと宛先PIDのリスト。リストが空の場合、ALTOサーバーはそれを現在定義されているPIDの完全なセットとして解釈する必要があります。 ALTOサーバーは、リストに複数回出現するエントリを、1回だけ出現するかのように解釈する必要があります。 「pids」フィールドが存在しない場合、両方のリストは、現在定義されているPIDの完全なセットを含むものとしてALTOサーバーによって解釈される必要があります。
The URI providing this resource supports all capabilities documented in Section 11.2.3.4 (with identical semantics), plus additional capabilities. In particular, the capabilities are defined by a JSON object of type FilteredCostMapCapabilities:
このリソースを提供するURIは、セクション11.2.3.4に記載されているすべての機能（同一のセマンティクスを持つ）に加えて、追加の機能をサポートします。特に、機能はFilteredCostMapCapabilitiesタイプのJSONオブジェクトによって定義されます。
object {
JSONString cost-type-names<1..*>;
JSONBool cost-constraints;
} FilteredCostMapCapabilities;
with fields:
フィールド付き：
cost-type-names: See Section 11.2.3.4 and note that the array can have one to many cost types.
cost-type-names：セクション11.2.3.4を参照してください。配列には1対多のコストタイプがあることに注意してください。
cost-constraints: If true, then the ALTO server allows cost constraints to be included in requests to the corresponding URI. If not present, this field MUST be interpreted as if it specified false. ALTO clients should be aware that constraints may not have the intended effect for cost maps with the ordinal cost mode since ordinal costs are not restricted to being sequential integers.
cost-constraints：trueの場合、ALTOサーバーは、対応するURIへの要求にコスト制約を含めることを許可します。存在しない場合、このフィールドはfalseを指定した場合と同様に解釈する必要があります。順序コストは連続した整数に限定されないため、ALTOクライアントは、制約が順序コストモードのコストマップに意図した効果をもたらさない可能性があることに注意する必要があります。
The resource ID of the network map based on which the cost map will be filtered.
コストマップのフィルタリングに基づくネットワークマップのリソースID。
The format is the same as an unfiltered ALTO cost map. See Section 11.2.3.6 for the format.
フォーマットは、フィルタリングされていないALTOコストマップと同じです。形式については、セクション11.2.3.6を参照してください。
The "dependent-vtags" field in the "meta" field provides an array consisting of a single element, which is the version tag of the network map used in filtering. ALTO clients should verify that the version tag included in the response is equal to the version tag of the network map used to generate the request (if applicable). If it is not, the ALTO client may wish to request an updated network map, identify changes, and consider requesting a new filtered cost map.
「meta」フィールドの「dependent-vtags」フィールドは、単一の要素で構成される配列を提供します。これは、フィルタリングで使用されるネットワークマップのバージョンタグです。 ALTOクライアントは、応答に含まれているバージョンタグが、要求の生成に使用されたネットワークマップのバージョンタグと等しいことを確認する必要があります（該当する場合）。そうでない場合、ALTOクライアントは、更新されたネットワークマップを要求し、変更を識別し、フィルターされた新しいコストマップの要求を検討する場合があります。
The returned cost map MUST contain only source/destination pairs that have been indicated (implicitly or explicitly) in the input parameters. If the input parameters contain a PID name that is not currently defined by the ALTO server, the ALTO server MUST behave as if the PID did not appear in the input parameters.
返されるコストマップには、入力パラメーターで（暗黙的または明示的に）示されているソース/宛先のペアのみを含める必要があります。入力パラメーターに、現在ALTOサーバーで定義されていないPID名が含まれている場合、ALTOサーバーは、PIDが入力パラメーターに表示されなかったかのように動作する必要があります。
If any constraints are specified, source/destination pairs for which the path costs do not meet the constraints MUST NOT be included in the returned cost map. If no constraints were specified, then all path costs are assumed to meet the constraints.
制約が指定されている場合、パスコストが制約を満たさない送信元/宛先のペアは、返されるコストマップに含まれてはなりません（MUST NOT）。制約が指定されていない場合、すべてのパスコストが制約を満たすと見なされます。
POST /costmap/filtered HTTP/1.1
Host: custom.alto.example.com
Content-Type: application/alto-costmapfilter+json
Content-Length: 181
Accept: application/alto-costmap+json,application/alto-error+json
{
"cost-type" : {"cost-mode": "numerical",
"cost-metric": "routingcost"
},
"pids" : {
"srcs" : [ "PID1" ],
"dsts" : [ "PID1", "PID2", "PID3" ]
}
}
HTTP/1.1 200 OK
Content-Length: 341
Content-Type: application/alto-costmap+json
{
"meta" : {
"dependent-vtags" : [
{"resource-id": "my-default-network-map",
"tag": "75ed013b3cb58f896e839582504f622838ce670f"
}
],
"cost-type": {"cost-mode" : "numerical",
"cost-metric" : "routingcost"
}
},
"cost-map" : {
"PID1": { "PID1": 0, "PID2": 1, "PID3": 2 }
}
}
The Endpoint Property Service provides information about endpoint properties to ALTO clients.
エンドポイントプロパティサービスは、ALTOクライアントにエンドポイントプロパティに関する情報を提供します。
An endpoint property resource provides information about properties for individual endpoints. In addition to the required "pid" endpoint property (see Sections 7.1.1 and 11.4.1.4), further endpoint properties MAY be provided by an ALTO server.
エンドポイントプロパティリソースは、個々のエンドポイントのプロパティに関する情報を提供します。必須の「pid」エンドポイントプロパティ（セクション7.1.1および11.4.1.4を参照）に加えて、ALTOサーバーによってエンドポイントプロパティがさらに提供される場合があります。
The media type of an endpoint property resource is "application/ alto-endpointprop+json".
エンドポイントプロパティリソースのメディアタイプは「application / alto-endpointprop + json」です。
The endpoint property resource is requested using the HTTP POST method.
エンドポイントプロパティリソースは、HTTP POSTメソッドを使用してリクエストされます。
The input parameters for an endpoint property request are supplied in the entity body of the POST request. This document specifies the input parameters with a data format indicated by the media type "application/alto-endpointpropparams+json", which is a JSON object of type ReqEndpointProp:
エンドポイントプロパティ要求の入力パラメーターは、POST要求のエンティティ本体で提供されます。このドキュメントでは、ReqEndpointPropタイプのJSONオブジェクトである「application / alto-endpointpropparams + json」というメディアタイプで示されるデータ形式で入力パラメーターを指定しています。
object {
EndpointPropertyType properties<1..*>;
TypedEndpointAddr endpoints<1..*>;
} ReqEndpointProp;
with fields:
フィールド付き：
properties: List of endpoint properties to be returned for each endpoint. Each specified property MUST be included in the list of supported properties indicated by this resource's "capabilities" field (Section 11.4.1.4). The ALTO server MUST interpret entries appearing multiple times as if they appeared only once.
properties：各エンドポイントに対して返されるエンドポイントプロパティのリスト。指定された各プロパティは、このリソースの「機能」フィールド（セクション11.4.1.4）によって示されるサポートされるプロパティのリストに含まれている必要があります。 ALTOサーバーは、複数回出現するエントリを、1回だけ出現するかのように解釈する必要があります。
endpoints: List of endpoint addresses for which the specified properties are to be returned. The ALTO server MUST interpret entries appearing multiple times as if they appeared only once.
endpoints：指定されたプロパティが返されるエンドポイントアドレスのリスト。 ALTOサーバーは、複数回出現するエントリを、1回だけ出現するかのように解釈する必要があります。
The capabilities of an ALTO server URI providing endpoint properties are defined by a JSON object of type EndpointPropertyCapabilities:
エンドポイントプロパティを提供するALTOサーバーURIの機能は、EndpointPropertyCapabilitiesタイプのJSONオブジェクトによって定義されます。
object {
EndpointPropertyType prop-types<1..*>;
} EndpointPropertyCapabilities;
with field:
フィールド付き：
prop-types: The endpoint properties (see Section 10.8) supported by the corresponding URI.
prop-types：対応するURIでサポートされるエンドポイントプロパティ（セクション10.8を参照）。
In particular, the information resource closure MUST provide the lookup of pid for every ALTO network map defined.
特に、情報リソースクロージャは、定義されたすべてのALTOネットワークマップのpidのルックアップを提供する必要があります。
None.
なし。
The "dependent-vtags" field in the "meta" field of the response MUST be an array that includes the version tags of all ALTO network maps whose "pid" is queried.
応答の「meta」フィールドの「dependent-vtags」フィールドは、「pid」が照会されるすべてのALTOネットワークマップのバージョンタグを含む配列である必要があります。
The data component of an endpoint properties response is named "endpoint-properties", which is a JSON object of type EndpointPropertyMapData, where:
エンドポイントプロパティレスポンスのデータコンポーネントは「endpoint-properties」という名前で、EndpointPropertyMapDataタイプのJSONオブジェクトです。ここで、
object {
EndpointPropertyMapData endpoint-properties;
} InfoResourceEndpointProperties : ResponseEntityBase;
object-map {
TypedEndpointAddr -> EndpointProps;
} EndpointPropertyMapData;
object {
EndpointPropertyType -> JSONValue;
} EndpointProps;
Specifically, an EndpointPropertyMapData object has one member for each endpoint indicated in the input parameters (with the name being the endpoint encoded as a TypedEndpointAddr). The requested properties for each endpoint are encoded in a corresponding EndpointProps object, which encodes one name/value pair for each requested property, where the property names are encoded as strings of type EndpointPropertyType. An implementation of the protocol in this document SHOULD assume that the property value is a JSONString and fail to parse if it is not, unless the implementation is using an extension to this document that indicates when and how property values of other data types are signaled.
具体的には、EndpointPropertyMapDataオブジェクトには、入力パラメーターで指定されたエンドポイントごとに1つのメンバーがあります（名前はTypedEndpointAddrとしてエンコードされたエンドポイントです）。各エンドポイントの要求されたプロパティは、対応するEndpointPropsオブジェクトにエンコードされます。このオブジェクトは、要求された各プロパティの名前と値のペアをエンコードします。プロパティ名は、EndpointPropertyTypeタイプの文字列としてエンコードされます。このドキュメントのプロトコルの実装では、プロパティ値がJSONStringであると想定し、そうでない場合は解析に失敗する必要があります。ただし、他のデータ型のプロパティ値がいつどのように通知されるかを示すこのドキュメントの拡張機能を実装が使用している場合を除きます。
The ALTO server returns the value for each of the requested endpoint properties for each of the endpoints listed in the input parameters.
ALTOサーバーは、入力パラメーターにリストされている各エンドポイントの要求された各エンドポイントプロパティの値を返します。
If the ALTO server does not define a requested property's value for a particular endpoint, then it MUST omit that property from the response for only that endpoint.
ALTOサーバーが特定のエンドポイントの要求されたプロパティの値を定義しない場合、そのエンドポイントのみの応答からそのプロパティを省略しなければなりません（MUST）。
POST /endpointprop/lookup HTTP/1.1
Host: alto.example.com
Content-Length: 181
Content-Type: application/alto-endpointpropparams+json
Accept: application/alto-endpointprop+json,application/alto-error+json
{
"properties" : [ "my-default-networkmap.pid",
"priv:ietf-example-prop" ],
"endpoints" : [ "ipv4:192.0.2.34",
"ipv4:203.0.113.129" ]
}
HTTP/1.1 200 OK
Content-Length: 396
Content-Type: application/alto-endpointprop+json
{
"meta" : {
"dependent-vtags" : [
{"resource-id": "my-default-network-map",
"tag": "7915dc0290c2705481c491a2b4ffbec482b3cf62"
}
]
},
"endpoint-properties": {
"ipv4:192.0.2.34" : { "my-default-network-map.pid": "PID1",
"priv:ietf-example-prop": "1" },
"ipv4:203.0.113.129" : { "my-default-network-map.pid": "PID3" }
}
}
The Endpoint Cost Service provides information about costs between individual endpoints.
Endpoint Cost Serviceは、個々のエンドポイント間のコストに関する情報を提供します。
In particular, this service allows lists of endpoint prefixes (and addresses, as a special case) to be ranked (ordered) by an ALTO server.
特に、このサービスでは、エンドポイントプレフィックス（および特別なケースとしてのアドレス）のリストをALTOサーバーでランク付け（順序付け）できます。
An endpoint cost resource provides information about costs between individual endpoints. It MAY be provided by an ALTO server.
エンドポイントコストリソースは、個々のエンドポイント間のコストに関する情報を提供します。 ALTOサーバーによって提供される場合があります。
How an ALTO server provides the endpoint cost resource is implementation dependent. An ALTO server may use either fine-grained costs among individual endpoints or coarse-grained costs based on the costs between the PIDs corresponding to the endpoints. See Section 15.3 for additional details.
ALTOサーバーがエンドポイントコストリソースを提供する方法は、実装によって異なります。 ALTOサーバーは、個々のエンドポイント間の細かいコスト、またはエンドポイントに対応するPID間のコストに基づく粗いコストのいずれかを使用できます。詳細については、セクション15.3を参照してください。
The media type of the endpoint cost resource is "application/alto-endpointcost+json".
エンドポイントコストリソースのメディアタイプは「application / alto-endpointcost + json」です。
The endpoint cost resource is requested using the HTTP POST method.
エンドポイントのコストリソースは、HTTP POSTメソッドを使用してリクエストされます。
An ALTO client supplies the endpoint cost parameters through a media type "application/alto-endpointcostparams+json", with an HTTP POST entity body of a JSON object of type ReqEndpointCostMap:
ALTOクライアントは、メディアタイプ「application / alto-endpointcostparams + json」を通じて、タイプReqEndpointCostMapのJSONオブジェクトのHTTP POSTエンティティボディを使用して、エンドポイントコストパラメータを提供します。
object {
CostType cost-type;
[JSONString constraints<0..*>;]
EndpointFilter endpoints;
} ReqEndpointCostMap;
object {
[TypedEndpointAddr srcs<0..*>;]
[TypedEndpointAddr dsts<0..*>;]
} EndpointFilter;
with fields:
フィールド付き：
cost-type: The cost type (Section 10.7) to use for returned costs. The "cost-metric" and "cost-mode" fields MUST match one of the supported cost types indicated in this resource's "capabilities" fields (Section 11.5.1.4). The ALTO client SHOULD omit the "description" field, and if present, the ALTO server MUST ignore the "description" field.
cost-type：返却コストに使用するコストタイプ（セクション10.7）。 「cost-metric」および「cost-mode」フィールドは、このリソースの「capabilities」フィールド（セクション11.5.1.4）で示されているサポートされているコストタイプの1つと一致する必要があります。 ALTOクライアントは「説明」フィールドを省略してください。存在する場合、ALTOサーバーは「説明」フィールドを無視する必要があります。
constraints: Defined equivalently to the "constraints" input parameter of a filtered cost map (see Section 11.3.2).
制約：フィルターされたコストマップの「制約」入力パラメーターと同等に定義されます（セクション11.3.2を参照）。
endpoints: A list of source endpoints and destination endpoints for which path costs are to be returned. If the list of source or destination endpoints is empty (or not included), the ALTO server MUST interpret it as if it contained the endpoint address corresponding to the client IP address from the incoming connection (see Section 13.3 for discussion and considerations regarding this mode). The source and destination endpoint lists MUST NOT be both empty. The ALTO server MUST interpret entries appearing multiple times in a list as if they appeared only once.
endpoints：パスコストが返されるソースエンドポイントと宛先エンドポイントのリスト。ソースまたは宛先エンドポイントのリストが空である（または含まれていない）場合、ALTOサーバーは、着信接続からのクライアントIPアドレスに対応するエンドポイントアドレスが含まれているかのように解釈する必要があります（このモードに関する説明と考慮事項については、セクション13.3を参照してください） ）。ソースと宛先のエンドポイントリストは、両方を空にすることはできません。 ALTOサーバーは、リストに複数回出現するエントリを、1回だけ出現するかのように解釈する必要があります。
This document defines EndpointCostCapabilities as the same as FilteredCostMapCapabilities. See Section 11.3.2.4.
このドキュメントでは、EndpointCostCapabilitiesをFilteredCostMapCapabilitiesと同じように定義しています。セクション11.3.2.4を参照してください。
It is important to note that although this resource allows an ALTO server to reveal costs between individual endpoints, the ALTO server is not required to do so. A simple implementation of ECS may compute the cost between two endpoints as the cost between the PIDs corresponding to the endpoints, using one of the exposed network and cost maps defined by the server. ECS MUST NOT specify the "use" field to indicate a network or cost map. Hence, the ECS cost is the cost from the source endpoint to the destination endpoint. A future extension may allow ECS to state that it "uses" a network map. The extension then will need to define the semantics.
このリソースにより、ALTOサーバーは個々のエンドポイント間のコストを明らかにできますが、ALTOサーバーはそうする必要はありません。 ECSの単純な実装では、公開されたネットワークとサーバーによって定義されたコストマップの1つを使用して、エンドポイントに対応するPID間のコストとして2つのエンドポイント間のコストを計算できます。 ECSは、ネットワークまたはコストマップを示す「使用」フィールドを指定してはなりません（MUST NOT）。したがって、ECSコストは、ソースエンドポイントから宛先エンドポイントまでのコストです。将来の拡張では、ECSがネットワークマップを「使用」することを表明できるようになる可能性があります。次に、拡張機能はセマンティクスを定義する必要があります。
The "meta" field of an endpoint cost response MUST include the "cost-type" field, to indicate the cost type used.
エンドポイントコスト応答の「メタ」フィールドには、使用されるコストタイプを示す「コストタイプ」フィールドを含める必要があります。
The data component of an endpoint cost response is named "endpoint-cost-map", which is a JSON object of type EndpointCostMapData:
エンドポイントコストレスポンスのデータコンポーネントは「endpoint-cost-map」という名前であり、EndpointCostMapDataタイプのJSONオブジェクトです。
object {
EndpointCostMapData endpoint-cost-map;
} InfoResourceEndpointCostMap : ResponseEntityBase;
object-map {
TypedEndpointAddr -> EndpointDstCosts;
} EndpointCostMapData;
object-map {
TypedEndpointAddr -> JSONValue;
} EndpointDstCosts;
Specifically, an EndpointCostMapData object is a dictionary map with each key representing a TypedEndpointAddr string identifying the source endpoint specified in the input parameters. For each source endpoint, an EndpointDstCosts dictionary map object denotes the associated cost to each destination endpoint specified in input parameters. An implementation of the protocol in this document SHOULD assume that the cost value is a JSONNumber and fail to parse if it is not, unless the implementation is using an extension to this document that indicates when and how costs of other data types are signaled. If the ALTO server does not define a cost value from a source endpoint to a particular destination endpoint, it MAY be omitted from the response.
具体的には、EndpointCostMapDataオブジェクトはディクショナリマップであり、各キーは、入力パラメーターで指定されたソースエンドポイントを識別するTypedEndpointAddr文字列を表します。各ソースエンドポイントについて、EndpointDstCostsディクショナリマップオブジェクトは、入力パラメーターで指定された各宛先エンドポイントに関連付けられたコストを示します。このドキュメントのプロトコルの実装では、コスト値がJSONNumberであると想定し、そうでない場合は解析に失敗する必要があります。ただし、他のデータ型のコストがいつどのように通知されるかを示すこのドキュメントの拡張機能を実装が使用している場合を除きます。 ALTOサーバーがソースエンドポイントから特定の宛先エンドポイントへのコスト値を定義しない場合は、応答から省略できます。
POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com
Content-Length: 248
Content-Type: application/alto-endpointcostparams+json
Accept: application/alto-endpointcost+json,application/alto-error+json
{
"cost-type": {"cost-mode" : "ordinal",
"cost-metric" : "routingcost"},
"endpoints" : {
"srcs": [ "ipv4:192.0.2.2" ],
"dsts": [
"ipv4:192.0.2.89",
"ipv4:198.51.100.34",
"ipv4:203.0.113.45"
]
}
}
HTTP/1.1 200 OK
Content-Length: 274
Content-Type: application/alto-endpointcost+json
{
"meta" : {
"cost-type": {"cost-mode" : "ordinal",
"cost-metric" : "routingcost"
}
},
"endpoint-cost-map" : {
"ipv4:192.0.2.2": {
"ipv4:192.0.2.89" : 1,
"ipv4:198.51.100.34" : 2,
"ipv4:203.0.113.45" : 3
}
}
}
The sections below depict typical use cases. While these use cases focus on peer-to-peer applications, ALTO can be applied to other environments such as Content Distribution Networks (CDNs) [ALTO-USE-CASES].
以下のセクションでは、一般的な使用例を示します。これらのユースケースはピアツーピアアプリケーションに重点を置いていますが、ALTOはコンテンツ配信ネットワーク（CDN）[ALTO-USE-CASES]などの他の環境に適用できます。
Many deployed P2P systems use a tracker to manage swarms and perform peer selection. Such a P2P tracker can already use a variety of information to perform peer selection to meet application-specific goals. By acting as an ALTO client, the P2P tracker can use ALTO information as an additional information source to enable more network-efficient traffic patterns and improve application performance.
デプロイされた多くのP2Pシステムは、トラッカーを使用して群れを管理し、ピア選択を実行します。そのようなP2Pトラッカーは、さまざまな情報を使用してピア選択を実行し、アプリケーション固有の目標を満たすことができます。 P2Pトラッカーは、ALTOクライアントとして機能することにより、ALTO情報を追加の情報ソースとして使用して、ネットワーク効率の高いトラフィックパターンを実現し、アプリケーションのパフォーマンスを向上させることができます。
A particular requirement of many P2P trackers is that they must handle a large number of P2P clients. A P2P tracker can obtain and locally store ALTO information (e.g., ALTO network maps and cost maps) from the ISPs containing the P2P clients, and benefit from the same aggregation of network locations done by ALTO servers.
多くのP2Pトラッカーの特定の要件は、多数のP2Pクライアントを処理する必要があることです。 P2Pトラッカーは、P2Pクライアントを含むISPからALTO情報（ALTOネットワークマップやコストマップなど）を取得してローカルに格納でき、ALTOサーバーによって行われるネットワークロケーションの同じ集約から利益を得ることができます。
.---------. (1) Get Network Map .---------------.
| | <----------------------> | |
| ALTO | | P2P Tracker |
| Server | (2) Get Cost Map | (ALTO client) |
| | <----------------------> | |
`---------' `---------------'
^ |
(3) Get Peers | | (4) Selected Peer
| v List
.---------. .-----------.
| Peer 1 | <-------------- | P2P |
`---------' | Client |
. (5) Connect to `-----------'
. Selected Peers /
.---------. /
| Peer 50 | <------------------
`---------'
Figure 4: ALTO Client Embedded in P2P Tracker
図4：P2Pトラッカーに埋め込まれたALTOクライアント
Figure 4 shows an example use case where a P2P tracker is an ALTO client and applies ALTO information when selecting peers for its P2P clients. The example proceeds as follows:
図4は、P2PトラッカーがALTOクライアントであり、P2Pクライアントのピアを選択するときにALTO情報を適用する使用例を示しています。例は次のように進行します。
1. The P2P tracker requests from the ALTO server a network map, so that it locally map P2P clients into PIDs.
1. P2Pトラッカーは、ALTOサーバーにネットワークマップを要求し、ローカルでP2PクライアントをPIDにマップします。
2. The P2P tracker requests from the ALTO server the cost map amongst all PIDs identified in the preceding step.
2. P2Pトラッカーは、前の手順で識別されたすべてのPID間のコストマップをALTOサーバーに要求します。
3. A P2P client joins the swarm, and requests a peer list from the P2P tracker.
3. P2Pクライアントが群れに参加し、P2Pトラッカーにピアリストを要求します。
4. The P2P tracker returns a peer list to the P2P client. The returned peer list is computed based on the network map and the cost map returned by the ALTO server, and possibly other information sources. Note that it is possible that a tracker may use only the network map to implement hierarchical peer selection by preferring peers within the same PID and ISP.
4. P2PトラッカーはピアリストをP2Pクライアントに返します。返されるピアリストは、ALTOサーバーによって返されるネットワークマップとコストマップ、および場合によっては他の情報ソースに基づいて計算されます。トラッカーがネットワークマップのみを使用して、同じPIDとISP内のピアを優先することにより、階層的なピア選択を実装する可能性があることに注意してください。
5. The P2P client connects to the selected peers.
5. P2Pクライアントは、選択したピアに接続します。
Note that the P2P tracker may provide peer lists to P2P clients distributed across multiple ISPs. In such a case, the P2P tracker may communicate with multiple ALTO servers.
P2Pトラッカーは、複数のISPに分散されたP2Pクライアントにピアリストを提供する場合があることに注意してください。このような場合、P2Pトラッカーは複数のALTOサーバーと通信できます。
P2P clients may also utilize ALTO information themselves when selecting from available peers. It is important to note that not all P2P systems use a P2P tracker for peer discovery and selection. Furthermore, even when a P2P tracker is used, the P2P clients may rely on other sources, such as peer exchange and DHTs, to discover peers.
P2Pクライアントは、利用可能なピアから選択するときに、ALTO情報自体を利用することもできます。すべてのP2Pシステムがピアの検出と選択にP2Pトラッカーを使用するわけではないことに注意することが重要です。さらに、P2Pトラッカーが使用されている場合でも、P2Pクライアントはピア交換を発見するためにピア交換やDHTなどの他のソースに依存する場合があります。
When a P2P client uses ALTO information, it typically queries only the ALTO server servicing its own ISP. The "my-Internet view" provided by its ISP's ALTO server can include preferences to all potential peers.
P2PクライアントがALTO情報を使用する場合、通常は、自身のISPにサービスを提供しているALTOサーバーのみを照会します。 ISPのALTOサーバーによって提供される「マイインターネットビュー」には、すべての潜在的なピアへの設定を含めることができます。
.---------. (1) Get Network Map .---------------.
| | <----------------------> | |
| ALTO | | P2P Client |
| Server | (2) Get Cost Map | (ALTO client) |
| | <----------------------> | | .---------.
`---------' `---------------' <- | P2P |
.---------. / | ^ ^ | Tracker |
| Peer 1 | <-------------- | | \ `---------'
`---------' | (3) Gather Peers
. (4) Select Peers | | \
. and Connect / .--------. .--------.
.---------. / | P2P | | DHT |
| Peer 50 | <---------------- | Client | `--------'
`---------' | (PEX) |
`--------'
Figure 5: ALTO Client Embedded in P2P Client
図5：P2Pクライアントに埋め込まれたALTOクライアント
Figure 5 shows an example use case where a P2P client locally applies ALTO information to select peers. The use case proceeds as follows: 1. The P2P client requests the network map covering all PIDs from the ALTO server servicing its own ISP.
図5は、P2Pクライアントが選択したピアにALTO情報をローカルに適用する使用例を示しています。ユースケースは次のように進行します。1. P2Pクライアントは、独自のISPにサービスを提供しているALTOサーバーからすべてのPIDをカバーするネットワークマップを要求します。
2. The P2P client requests the cost map providing path costs amongst all PIDs from the ALTO server. The cost map by default specifies numerical costs.
2. P2Pクライアントは、ALTOサーバーからのすべてのPID間のパスコストを提供するコストマップを要求します。デフォルトでは、コストマップは数値コストを指定します。
3. The P2P client discovers peers from sources such as peer exchange (PEX) from other P2P clients, distributed hash tables (DHT), and P2P trackers.
3. P2Pクライアントは、他のP2Pクライアントからのピア交換（PEX）、分散ハッシュテーブル（DHT）、P2Pトラッカーなどのソースからピアを検出します。
4. The P2P client uses ALTO information as part of the algorithm for selecting new peers and connects to the selected peers.
4. P2Pクライアントは、新しいピアを選択するアルゴリズムの一部としてALTO情報を使用し、選択したピアに接続します。
It is also possible for a P2P client to offload the selection and ranking process to an ALTO server. In this use case, the ALTO client embedded in the P2P client gathers a list of known peers in the swarm, and asks the ALTO server to rank them. This document limits the use case to when the P2P client and the ALTO server are deployed by the same entity; hence, the P2P client uses the ranking provided by the ALTO server directly.
P2Pクライアントが選択とランク付けのプロセスをALTOサーバーにオフロードすることもできます。この使用例では、P2Pクライアントに組み込まれたALTOクライアントが、群れ内の既知のピアのリストを収集し、それらをランク付けするようにALTOサーバーに要求します。このドキュメントでは、P2PクライアントとALTOサーバーが同じエンティティーによってデプロイされる場合に使用例を制限しています。したがって、P2Pクライアントは、ALTOサーバーが直接提供するランキングを使用します。
As in the use case using numerical costs, the P2P client typically only queries the ALTO server servicing its own ISP.
数値コストを使用する使用例と同様に、P2Pクライアントは通常、独自のISPにサービスを提供するALTOサーバーにのみクエリを実行します。
.---------. .---------------.
| | | |
| ALTO | (2) Get Endpoint Ranking | P2P Client |
| Server | <----------------------> | (ALTO client) |
| | | | .---------.
`---------' `---------------' <- | P2P |
.---------. / | ^ ^ | Tracker |
| Peer 1 | <-------------- | | \ `---------'
`---------' | (1) Gather Peers
. (3) Connect to | | \
. Selected Peers / .--------. .--------.
.---------. / | P2P | | DHT |
| Peer 50 | <---------------- | Client | `--------'
`---------' | (PEX) |
`--------'
Figure 6: ALTO Client Embedded in P2P Client: Ranking
図6：P2Pクライアントに埋め込まれたALTOクライアント：ランキング
Figure 6 shows an example of this scenario. The use case proceeds as follows:
図6は、このシナリオの例を示しています。ユースケースは次のように進行します。
1. The P2P client discovers peers from sources such as Peer Exchange (PEX) from other P2P clients, Distributed Hash Tables (DHT), and P2P trackers.
1. P2Pクライアントは、他のP2Pクライアントからのピア交換（PEX）、分散ハッシュテーブル（DHT）、P2Pトラッカーなどのソースからピアを検出します。
2. The P2P client queries the ALTO server's ranking service (i.e., the ECS Service), by including the discovered peers as the set of destination endpoints, and indicating the "ordinal" cost mode. The response indicates the ranking of the candidate peers.
2. P2Pクライアントは、検出されたピアを宛先エンドポイントのセットとして含め、「通常の」コストモードを示すことにより、ALTOサーバーのランキングサービス（つまり、ECSサービス）にクエリを実行します。応答は候補ピアのランキングを示します。
3. The P2P client connects to the peers in the order specified in the ranking.
3. P2Pクライアントは、ランキングで指定された順序でピアに接続します。
The discovery mechanism by which an ALTO client locates an appropriate ALTO server is out of scope for this document. This document assumes that an ALTO client can discover an appropriate ALTO server. Once it has done so, the ALTO client may use the information resource directory (see Section 9.2) to locate an information resource with the desired ALTO information.
ALTOクライアントが適切なALTOサーバーを見つけるための検出メカニズムは、このドキュメントの範囲外です。このドキュメントでは、ALTOクライアントが適切なALTOサーバーを検出できることを前提としています。これが完了すると、ALTOクライアントは情報リソースディレクトリ（セクション9.2を参照）を使用して、目的のALTO情報を含む情報リソースを見つけることができます。
In practical deployments, a particular host can be reachable using multiple addresses (e.g., a wireless IPv4 connection, a wireline IPv4 connection, and a wireline IPv6 connection). In general, the particular network path followed when sending packets to the host will depend on the address that is used. Network providers may prefer one path over another. An additional consideration may be how to handle private address spaces (e.g., behind carrier-grade NATs).
実際の配備では、複数のアドレスを使用して特定のホストに到達できます（ワイヤレスIPv4接続、有線IPv4接続、および有線IPv6接続など）。一般に、パケットをホストに送信するときにたどる特定のネットワークパスは、使用するアドレスによって異なります。ネットワークプロバイダーは、あるパスを別のパスよりも優先する場合があります。追加の考慮事項は、プライベートアドレススペースの処理方法です（たとえば、キャリアグレードのNATの背後）。
To support such behavior, this document allows multiple endpoint addresses and address types. With this support, the ALTO Protocol allows an ALTO service provider the flexibility to indicate preferences for paths from an endpoint address of one type to an endpoint address of a different type.
このような動作をサポートするために、このドキュメントでは複数のエンドポイントアドレスとアドレスタイプを許可しています。このサポートにより、ALTOプロトコルにより、ALTOサービスプロバイダーは、あるタイプのエンドポイントアドレスから別のタイプのエンドポイントアドレスへのパスの設定を柔軟に指定できます。
In this day and age of NAT v4<->v4, v4<->v6 [RFC6144], and possibly v6<->v6 [RFC6296], a protocol should strive to be NAT friendly and minimize carrying IP addresses in the payload or provide a mode of operation where the source IP address provides the information necessary to the server.
NAT v4 <-> v4、v4 <-> v6 [RFC6144]、および場合によってはv6 <-> v6 [RFC6296]のこの時代では、プロトコルはNATに対応し、ペイロードまたは送信元IPアドレスがサーバーに必要な情報を提供する動作モードを提供します。
The protocol specified in this document provides a mode of operation where the source network location is computed by the ALTO server (i.e., the Endpoint Cost Service) from the source IP address found in the ALTO client query packets. This is similar to how some P2P trackers (e.g., BitTorrent trackers -- see "Tracker HTTP/HTTPS Protocol" in [BitTorrent]) operate.
このドキュメントで指定されているプロトコルは、ALTOクライアントのクエリパケットで見つかったソースIPアドレスからALTOサーバー（つまり、Endpoint Cost Service）によってソースネットワークの場所が計算される動作モードを提供します。これは、一部のP2Pトラッカー（たとえば、BitTorrentトラッカー-[BitTorrent]の「トラッカーHTTP / HTTPSプロトコル」を参照）の動作に似ています。
There may be cases in which an ALTO client needs to determine its own IP address, such as when specifying a source endpoint address in the Endpoint Cost Service. It is possible that an ALTO client has multiple network interface addresses, and that some or all of them may require NAT for connectivity to the public Internet.
There may be cases in which an ALTO client needs to determine its own IP address, such as when specifying a source endpoint address in the Endpoint Cost Service. It is possible that an ALTO client has multiple network interface addresses, and that some or all of them may require NAT for connectivity to the public Internet.
If a public IP address is required for a network interface, the ALTO client SHOULD use the Session Traversal Utilities for NAT (STUN) [RFC5389]. If using this method, the host MUST use the "Binding Request" message and the resulting "XOR-MAPPED-ADDRESS" parameter that is returned in the response. Using STUN requires cooperation from a publicly accessible STUN server. Thus, the ALTO client also requires configuration information that identifies the STUN server, or a domain name that can be used for STUN server discovery. To be selected for this purpose, the STUN server needs to provide the public reflexive transport address of the host.
ネットワークインターフェースにパブリックIPアドレスが必要な場合、ALTOクライアントはNAT用のセッショントラバーサルユーティリティ（STUN）[RFC5389]を使用する必要があります（SHOULD）。この方法を使用する場合、ホストは「Binding Request」メッセージと、応答で返される結果の「XOR-MAPPED-ADDRESS」パラメーターを使用する必要があります。 STUNを使用するには、公的にアクセス可能なSTUNサーバーからの協力が必要です。したがって、ALTOクライアントには、STUNサーバーを識別する構成情報、またはSTUNサーバーの検出に使用できるドメイン名も必要です。この目的で選択するには、STUNサーバーがホストのパブリック再帰トランスポートアドレスを提供する必要があります。
ALTO clients should be cognizant that the network path between endpoints can depend on multiple factors, e.g., source address and destination address used for communication. An ALTO server provides information based on endpoint addresses (more generally, network locations), but the mechanisms used for determining existence of connectivity or usage of NAT between endpoints are out of scope of this document.
ALTOクライアントは、エンドポイント間のネットワークパスが、通信に使用される送信元アドレスや宛先アドレスなどの複数の要因に依存する可能性があることを認識する必要があります。 ALTOサーバーはエンドポイントアドレス（より一般的にはネットワークロケーション）に基づいて情報を提供しますが、エンドポイント間の接続の存在またはNATの使用を決定するために使用されるメカニズムは、このドキュメントの範囲外です。
An ALTO server could make available many properties about endpoints beyond their network location or grouping. For example, connection type, geographical location, and others may be useful to applications. This specification focuses on network location and grouping, but the protocol may be extended to handle other endpoint properties.
ALTOサーバーは、ネットワークの場所やグループを超えて、エンドポイントに関する多くのプロパティを利用可能にすることができます。たとえば、接続タイプ、地理的位置などがアプリケーションに役立つ場合があります。この仕様はネットワークの場所とグループ化に重点を置いていますが、プロトコルは他のエンドポイントプロパティを処理するために拡張される場合があります。
This document defines registries for application/alto-* media types, ALTO cost metrics, ALTO endpoint property types, ALTO address types, and ALTO error codes. Initial values for the registries and the process of future assignments are given below.
このドキュメントでは、application / alto- *メディアタイプ、ALTOコストメトリック、ALTOエンドポイントプロパティタイプ、ALTOアドレスタイプ、およびALTOエラーコードのレジストリを定義します。レジストリの初期値と今後の割り当てのプロセスを以下に示します。
This document registers multiple media types, listed in Table 2.
This document registers multiple media types, listed in Table 2.
+-------------+------------------------------+-------------------+
| Type | Subtype | Specification |
+-------------+------------------------------+-------------------+
| application | alto-directory+json | Section 9.2.1 |
| application | alto-networkmap+json | Section 11.2.1.1 |
| application | alto-networkmapfilter+json | Section 11.3.1.1 |
| application | alto-costmap+json | Section 11.2.3.1 |
| application | alto-costmapfilter+json | Section 11.3.2.1 |
| application | alto-endpointprop+json | Section 11.4.1.1 |
| application | alto-endpointpropparams+json | Section 11.4.1.1 |
| application | alto-endpointcost+json | Section 11.5.1.1 |
| application | alto-endpointcostparams+json | Section 11.5.1.1 |
| application | alto-error+json | Section 8.5.1 |
+-------------+------------------------------+-------------------+
Table 2: ALTO Protocol Media Types
表2：ALTOプロトコルのメディアタイプ
Type name: application
タイプ名：アプリケーション
Subtype name: This documents registers multiple subtypes, as listed in Table 2.
サブタイプ名：このドキュメントは、表2に示すように、複数のサブタイプを登録します。
Required parameters: n/a
必須パラメーター：なし
Optional parameters: n/a
オプションのパラメーター：n / a
Encoding considerations: Encoding considerations are identical to those specified for the "application/json" media type. See [RFC7159].
エンコーディングの考慮事項：エンコーディングの考慮事項は、「application / json」メディアタイプに指定されたものと同じです。 [RFC7159]を参照してください。
Security considerations: Security considerations relating to the generation and consumption of ALTO Protocol messages are discussed in Section 15.
セキュリティの考慮事項：ALTOプロトコルメッセージの生成と消費に関するセキュリティの考慮事項については、セクション15で説明します。
Interoperability considerations: This document specifies format of conforming messages and the interpretation thereof.
相互運用性に関する考慮事項：このドキュメントでは、適合メッセージの形式とその解釈について説明します。
Published specification: This document is the specification for these media types; see Table 2 for the section documenting each media type.
公開された仕様：このドキュメントは、これらのメディアタイプの仕様です。各メディアタイプを説明するセクションについては、表2を参照してください。
Applications that use this media type: ALTO servers and ALTO clients either stand alone or are embedded within other applications.
このメディアタイプを使用するアプリケーション：ALTOサーバーとALTOクライアントは、スタンドアロンであるか、他のアプリケーションに組み込まれています。
Additional information:
追加情報：
Magic number(s): n/a
File extension(s): This document uses the mime type to refer to protocol messages and thus does not require a file extension.
ファイル拡張子：このドキュメントでは、MIMEタイプを使用してプロトコルメッセージを参照しているため、ファイル拡張子は必要ありません。
Macintosh file type code(s): n/a
Person & email address to contact for further information: See Authors' Addresses section.
詳細については、連絡先の人と電子メールアドレス：作成者のアドレスセクションを参照してください。
Intended usage: COMMON
使用目的：COMMON
Restrictions on usage: n/a
使用上の制限：なし
Author: See Authors' Addresses section.
作成者：「作成者のアドレス」セクションを参照してください。
Change controller: Internet Engineering Task Force (mailto:iesg@ietf.org).
変更管理者：Internet Engineering Task Force（mailto：iesg@ietf.org）。
IANA has created and now maintains the "ALTO Cost Metric Registry", listed in Table 3.
IANAは、表3に示す「ALTOコストメトリックレジストリ」を作成し、現在維持しています。
+-------------+---------------------+
| Identifier | Intended Semantics |
+-------------+---------------------+
| routingcost | See Section 6.1.1.1 |
| priv: | Private use |
+-------------+---------------------+
Table 3: ALTO Cost Metrics
表3：ALTOコストメトリック
This registry serves two purposes. First, it ensures uniqueness of identifiers referring to ALTO cost metrics. Second, it provides references to particular semantics of allocated cost metrics to be applied by both ALTO servers and applications utilizing ALTO clients.
このレジストリには2つの目的があります。まず、ALTOコストメトリックを参照する識別子の一意性を保証します。第2に、ALTOサーバーとALTOクライアントを利用するアプリケーションの両方によって適用される、割り当てられたコストメトリックの特定のセマンティクスへの参照を提供します。
New ALTO cost metrics are assigned after IETF Review [RFC5226] to ensure that proper documentation regarding ALTO cost metric semantics and security considerations has been provided. The RFCs documenting the new metrics should be detailed enough to provide guidance to both ALTO service providers and applications utilizing ALTO clients as to how values of the registered ALTO cost metric should be interpreted. Updates and deletions of ALTO cost metrics follow the same procedure.
New ALTO cost metrics are assigned after IETF Review [RFC5226] to ensure that proper documentation regarding ALTO cost metric semantics and security considerations has been provided. The RFCs documenting the new metrics should be detailed enough to provide guidance to both ALTO service providers and applications utilizing ALTO clients as to how values of the registered ALTO cost metric should be interpreted. Updates and deletions of ALTO cost metrics follow the same procedure.
Registered ALTO cost metric identifiers MUST conform to the syntactical requirements specified in Section 10.6. Identifiers are to be recorded and displayed as strings.
登録されたALTOコストメトリック識別子は、セクション10.6で指定された構文要件に準拠する必要があります。識別子は記録され、文字列として表示されます。
As specified in Section 10.6, identifiers prefixed with "priv:" are reserved for Private Use.
セクション10.6で指定されているように、「priv：」で始まる識別子は私的使用のために予約されています。
Requests to add a new value to the registry MUST include the following information:
Requests to add a new value to the registry MUST include the following information:
o Identifier: The name of the desired ALTO cost metric.
o 識別子：目的のALTOコストメトリックの名前。
o Intended Semantics: ALTO costs carry with them semantics to guide their usage by ALTO clients. For example, if a value refers to a measurement, the measurement units must be documented. For proper implementation of the ordinal cost mode (e.g., by a third-party service), it should be documented whether higher or lower values of the cost are more preferred.
o 意図されたセマンティクス：ALTOコストは、ALTOクライアントによる使用をガイドするためのセマンティクスを伴います。たとえば、値が測定値を参照している場合、測定単位を文書化する必要があります。通常のコストモードを適切に実装するには（サードパーティのサービスなど）、コストの値が高いか低いかを文書化する必要があります。
o Security Considerations: ALTO costs expose information to ALTO clients. As such, proper usage of a particular cost metric may require certain information to be exposed by an ALTO service provider. Since network information is frequently regarded as proprietary or confidential, ALTO service providers should be made aware of the security ramifications related to usage of a cost metric.
o セキュリティに関する考慮事項：ALTOコストは、ALTOクライアントに情報を公開します。そのため、特定のコスト指標を適切に使用するには、ALTOサービスプロバイダーが特定の情報を公開する必要があります。ネットワーク情報は専有または機密と見なされることが多いため、ALTOサービスプロバイダーは、コストメトリックの使用に関連するセキュリティの影響を認識する必要があります。
This specification requests registration of the identifier "routingcost". Semantics for the this cost metric are documented in Section 6.1.1.1, and security considerations are documented in Section 15.3.
この仕様は、識別子 "routingcost"の登録を要求します。このコストメトリックのセマンティクスはセクション6.1.1.1に記載されており、セキュリティに関する考慮事項はセクション15.3に記載されています。
IANA has created and now maintains the "ALTO Endpoint Property Type Registry", listed in Table 4.
IANAは、表4にリストされている「ALTOエンドポイントプロパティタイプレジストリ」を作成して維持しています。
+------------+--------------------+
| Identifier | Intended Semantics |
+------------+--------------------+
| pid | See Section 7.1.1 |
| priv: | Private use |
+------------+--------------------+
Table 4: ALTO Endpoint Property Types
Table 4: ALTO Endpoint Property Types
The maintenance of this registry is similar to that of the preceding ALTO cost metrics. That is, the registry is maintained by IANA, subject to the description in Section 10.8.2.
このレジストリのメンテナンスは、前述のALTOコストメトリックのメンテナンスと同様です。つまり、レジストリはセクション10.8.2の説明に従い、IANAによって維持されます。
New endpoint property types are assigned after IETF Review [RFC5226] to ensure that proper documentation regarding ALTO endpoint property type semantics and security considerations has been provided. Updates and deletions of ALTO endpoint property types follow the same procedure.
IETOレビュー[RFC5226]の後に新しいエンドポイントプロパティタイプが割り当てられ、ALTOエンドポイントプロパティタイプのセマンティクスとセキュリティに関する考慮事項に関する適切なドキュメントが提供されていることを確認します。 ALTOエンドポイントプロパティタイプの更新と削除は、同じ手順に従います。
Registered ALTO endpoint property type identifiers MUST conform to the syntactical requirements specified in Section 10.8.1. Identifiers are to be recorded and displayed as strings.
Registered ALTO endpoint property type identifiers MUST conform to the syntactical requirements specified in Section 10.8.1. Identifiers are to be recorded and displayed as strings.
As specified in Section 10.8.1, identifiers prefixed with "priv:" are reserved for Private Use.
セクション10.8.1で指定されているように、「priv：」で始まる識別子は私的使用のために予約されています。
Requests to add a new value to the registry MUST include the following information:
レジストリに新しい値を追加するリクエストには、次の情報を含める必要があります。
o Identifier: The name of the desired ALTO endpoint property type.
o 識別子：目的のALTOエンドポイントプロパティタイプの名前。
o Intended Semantics: ALTO endpoint properties carry with them semantics to guide their usage by ALTO clients. Hence, a document defining a new type should provide guidance to both ALTO service providers and applications utilizing ALTO clients as to how values of the registered ALTO endpoint property should be interpreted. For example, if a value refers to a measurement, the measurement units must be documented.
o 意図されたセマンティクス：ALTOエンドポイントプロパティは、ALTOクライアントによる使用法をガイドするためのセマンティクスを持ちます。したがって、新しいタイプを定義するドキュメントは、ALTOサービスプロバイダーと、ALTOクライアントを利用するアプリケーションの両方に、登録されたALTOエンドポイントプロパティの値の解釈方法に関するガイダンスを提供する必要があります。たとえば、値が測定値を参照している場合、測定単位を文書化する必要があります。
o Security Considerations: ALTO endpoint properties expose information to ALTO clients. ALTO service providers should be made aware of the security ramifications related to the exposure of an endpoint property.
o セキュリティに関する考慮事項：ALTOエンドポイントプロパティは、ALTOクライアントに情報を公開します。 ALTOサービスプロバイダーは、エンドポイントプロパティの公開に関連するセキュリティの影響を認識しておく必要があります。
In particular, the request should discuss the sensitivity of the information, and why such sensitive information is required for ALTO-based operations. It may recommend that ISP provide mechanisms for users to grant or deny consent to such information sharing. Limitation to a trust domain being a type of consent bounding.
特に、要求では、情報の機密性、およびALTOベースの操作にそのような機密情報が必要な理由について説明する必要があります。 ISPが、ユーザーがそのような情報共有に同意を与えるまたは拒否するためのメカニズムを提供することを推奨する場合があります。一種の同意境界である信頼ドメインへの制限。
A request defining new endpoint properties should focus on exposing attributes of endpoints that are related to the goals of ALTO -- optimization of application-layer traffic -- as opposed to more general properties of endpoints. Maintaining this focus on technical, network-layer data will also help extension developers avoid the privacy concerns associated with publishing information about endpoints. For example:
新しいエンドポイントプロパティを定義するリクエストは、エンドポイントのより一般的なプロパティとは対照的に、ALTOの目的（アプリケーション層トラフィックの最適化）に関連するエンドポイントの属性の公開に焦点を当てる必要があります。技術的なネットワークレイヤーデータへのこの焦点を維持することは、拡張機能の開発者がエンドポイントに関する情報の公開に関連するプライバシーの問題を回避するのにも役立ちます。例えば：
o An extension to indicate the capacity of a server would likely be appropriate, since server capacities can be used by a client to choose between multiple equivalent servers. In addition, these properties are unlikely to be viewed as private information.
o クライアントがサーバーの容量を使用して複数の同等のサーバーを選択できるため、サーバーの容量を示す拡張が適切である可能性があります。また、これらのプロパティが個人情報として表示されることはほとんどありません。
o An extension to indicate the geolocation of endpoints might be appropriate. In some cases, a certain level of geolocation (e.g., to the country level) can be useful for selecting content sources. More precise geolocation, however, is not relevant to content delivery, and is typically considered private.
o エンドポイントの地理位置情報を示す拡張が適切な場合があります。場合によっては、特定のレベルの地理位置情報（国レベルなど）がコンテンツソースの選択に役立つことがあります。ただし、より正確な地理位置情報はコンテンツ配信には関係なく、通常はプライベートと見なされます。
o An extension indicating demographic attributes of the owner of an endpoint (e.g., age, sex, income) would not be appropriate, because these attributes are not related to delivery optimization, and because they are clearly private data.
o エンドポイントの所有者の人口統計属性（年齢、性別、収入など）を示す拡張は適切ではありません。これらの属性は配信の最適化に関連しておらず、明らかに非公開のデータだからです。
This specification requests registration of the identifier "pid". Semantics for this property are documented in Section 7.1.1, and security considerations are documented in Section 15.4.
この仕様は、識別子「pid」の登録を要求します。このプロパティのセマンティクスはセクション7.1.1に記載されており、セキュリティに関する考慮事項はセクション15.4に記載されています。
IANA has created and now maintains the "ALTO Address Type Registry", listed in Table 5.
IANAは、表5に示す「ALTOアドレスタイプレジストリ」を作成し、現在維持しています。
+------------+-----------------+-----------------+------------------+
| Identifier | Address | Prefix Encoding | Mapping to/from |
| | Encoding | | IPv4/v6 |
+------------+-----------------+-----------------+------------------+
| ipv4 | See Section | See Section | Direct mapping |
| | 10.4.3 | 10.4.4 | to IPv4 |
| ipv6 | See Section | See Section | Direct mapping |
| | 10.4.3 | 10.4.4 | to IPv6 |
+------------+-----------------+-----------------+------------------+
Table 5: ALTO Address Types
表5：ALTOアドレスタイプ
This registry serves two purposes. First, it ensures uniqueness of identifiers referring to ALTO address types. Second, it states the requirements for allocated address type identifiers.
このレジストリには2つの目的があります。まず、ALTOアドレスタイプを参照する識別子の一意性を保証します。次に、割り当てられたアドレスタイプ識別子の要件を示します。
New ALTO address types are assigned after IETF Review [RFC5226] to ensure that proper documentation regarding the new ALTO address types and their security considerations has been provided. RFCs defining new address types should indicate how an address of a registered type is encoded as an EndpointAddr and, if possible, a compact method (e.g., IPv4 and IPv6 prefixes) for encoding a set of addresses as an EndpointPrefix. Updates and deletions of ALTO address types follow the same procedure.
IETFレビュー[RFC5226]の後に新しいALTOアドレスタイプが割り当てられ、新しいALTOアドレスタイプとそのセキュリティに関する考慮事項に関する適切なドキュメントが提供されていることを確認します。新しいアドレスタイプを定義するRFCは、登録されたタイプのアドレスがEndpointAddrとしてエンコードされる方法と、可能であれば、一連のアドレスをEndpointPrefixとしてエンコードするためのコンパクトな方法（IPv4およびIPv6プレフィックスなど）を示す必要があります。 ALTOアドレスタイプの更新と削除は、同じ手順に従います。
Registered ALTO address type identifiers MUST conform to the syntactical requirements specified in Section 10.4.2. Identifiers are to be recorded and displayed as strings.
登録されたALTOアドレスタイプ識別子は、セクション10.4.2で指定された構文要件に準拠する必要があります。識別子は記録され、文字列として表示されます。
Requests to add a new value to the registry MUST include the following information:
レジストリに新しい値を追加するリクエストには、次の情報を含める必要があります。
o Identifier: The name of the desired ALTO address type.
o 識別子：目的のALTOアドレスタイプの名前。
o Endpoint Address Encoding: The procedure for encoding an address of the registered type as an EndpointAddr (see Section 10.4.3).
o エンドポイントアドレスエンコーディング：登録されたタイプのアドレスをEndpointAddrとしてエンコードする手順（セクション10.4.3を参照）。
o Endpoint Prefix Encoding: The procedure for encoding a set of addresses of the registered type as an EndpointPrefix (see Section 10.4.4). If no such compact encoding is available, the same encoding used for a singular address may be used. In such a case, it must be documented that sets of addresses of this type always have exactly one element.
o Endpoint Prefix Encoding：登録されたタイプのアドレスのセットをEndpointPrefixとしてエンコードする手順（セクション10.4.4を参照）。そのようなコンパクトなエンコーディングが利用できない場合、単一のアドレスに使用されるのと同じエンコーディングを使用できます。そのような場合、このタイプのアドレスのセットは常に正確に1つの要素を持つことを文書化する必要があります。
o Mapping to/from IPv4/IPv6 Addresses: If possible, a mechanism to map addresses of the registered type to and from IPv4 or IPv6 addresses should be specified.
o IPv4 / IPv6アドレスとのマッピング：可能であれば、登録済みタイプのアドレスをIPv4またはIPv6アドレスとの間でマッピングするメカニズムを指定する必要があります。
o Security Considerations: In some usage scenarios, endpoint addresses carried in ALTO Protocol messages may reveal information about an ALTO client or an ALTO service provider. Applications and ALTO service providers using addresses of the registered type should be made aware of how (or if) the addressing scheme relates to private information and network proximity.
o セキュリティに関する考慮事項：一部の使用シナリオでは、ALTOプロトコルメッセージで伝送されるエンドポイントアドレスにより、ALTOクライアントまたはALTOサービスプロバイダーに関する情報が明らかになる場合があります。登録されたタイプのアドレスを使用するアプリケーションとALTOサービスプロバイダーは、アドレス指定スキームが個人情報とネットワークの近接性にどのように（または関連して）関連付けられているかを認識させる必要があります。
This specification requests registration of the identifiers "ipv4" and "ipv6", as shown in Table 5.
この仕様は、表5に示すように、識別子「ipv4」と「ipv6」の登録を要求します。
IANA has created and now maintains the "ALTO Error Code Registry". Initial values are listed in Table 1, and recommended usage of the error codes is specified in Section 8.5.2.
IANAは「ALTOエラーコードレジストリ」を作成し、現在維持しています。初期値を表1に示し、エラーコードの推奨される使用法をセクション8.5.2に示します。
Although the error codes defined in Table 1 are already quite complete, future extensions may define new error codes. The "ALTO Error Code Registry" ensures the uniqueness of error codes when new error codes are added.
表1で定義されているエラーコードは既に完全ですが、将来の拡張機能で新しいエラーコードが定義される可能性があります。 「ALTOエラーコードレジストリ」は、新しいエラーコードが追加されたときにエラーコードの一意性を保証します。
New ALTO error codes are assigned after IETF Review [RFC5226] to ensure that proper documentation regarding the new ALTO error codes and their usage has been provided.
IETFレビュー[RFC5226]の後に新しいALTOエラーコードが割り当てられ、新しいALTOエラーコードとその使用法に関する適切なドキュメントが提供されていることを確認します。
A request to add a new ALTO error code to the registry MUST include the following information:
レジストリに新しいALTOエラーコードを追加する要求には、次の情報を含める必要があります。
o Error Code: A string starting with E_ to indicate the error.
o エラーコード：エラーを示すE_で始まる文字列。
o Intended Usage: ALTO error codes carry with them semantics to guide their usage by ALTO servers and clients. In particular, if a new error code indicates conditions that overlap with those of an existing ALTO error code, recommended usage of the new error code should be specified.
o 想定される使用法：ALTOエラーコードは、ALTOサーバーとクライアントによる使用法をガイドするセマンティクスを伴います。特に、新しいエラーコードが既存のALTOエラーコードの条件と重複する条件を示している場合、新しいエラーコードの推奨される使用法を指定する必要があります。
Some environments and use cases of ALTO require consideration of security attacks on ALTO servers and clients. In order to support those environments interoperably, the ALTO requirements document [RFC6708] outlines minimum-to-implement authentication and other security requirements. This document considers the following threats and protection strategies.
ALTOの一部の環境と使用例では、ALTOサーバーとクライアントに対するセキュリティ攻撃を考慮する必要があります。これらの環境を相互運用可能にサポートするために、ALTO要件ドキュメント[RFC6708]は、実装に最低限必要な認証とその他のセキュリティ要件の概要を示しています。このドキュメントでは、次の脅威と保護戦略について検討します。
An attacker may want to provide false or modified ALTO information resources or an information resource directory to ALTO clients to achieve certain malicious goals. As an example, an attacker may provide false endpoint properties. For example, suppose that a network supports an endpoint property named "hasQuota", which reports whether an endpoint has usage quota. An attacker may want to generate a false reply to lead to unexpected charges to the endpoint. An attack may also want to provide a false cost map. For example, by faking a cost map that highly prefers a small address range or a single address, the attacker may be able to turn a distributed application into a Distributed-Denial-of-Service (DDoS) tool.
攻撃者は、特定の悪意のある目標を達成するために、偽または変更されたALTO情報リソースまたは情報リソースディレクトリをALTOクライアントに提供する可能性があります。例として、攻撃者は偽のエンドポイントプロパティを提供する可能性があります。たとえば、ネットワークが「hasQuota」というエンドポイントプロパティをサポートし、エンドポイントに使用量の割り当てがあるかどうかを報告するとします。攻撃者は、誤った応答を生成して、エンドポイントに予期しない請求をもたらす可能性があります。攻撃では、誤ったコストマップを提供することもできます。たとえば、小さなアドレス範囲または単一のアドレスを非常に好むコストマップを偽造することにより、攻撃者は分散アプリケーションを分散サービス拒否（DDoS）ツールに変える可能性があります。
Depending on the network scenario, an attacker can attack authenticity and integrity of ALTO information resources using various techniques, including, but not limited to, sending forged DHCP replies in an Ethernet, DNS poisoning, and installing a transparent HTTP proxy that does some modifications.
Depending on the network scenario, an attacker can attack authenticity and integrity of ALTO information resources using various techniques, including, but not limited to, sending forged DHCP replies in an Ethernet, DNS poisoning, and installing a transparent HTTP proxy that does some modifications.
ALTO protects the authenticity and integrity of ALTO information (both information directory and individual information resources) by leveraging the authenticity and integrity mechanisms in TLS (see Section 8.3.5).
ALTO protects the authenticity and integrity of ALTO information (both information directory and individual information resources) by leveraging the authenticity and integrity mechanisms in TLS (see Section 8.3.5).
ALTO service providers who request server certificates and certification authorities who issue ALTO-specific certificates SHOULD consider the recommendations and guidelines defined in [RFC6125].
ALTO service providers who request server certificates and certification authorities who issue ALTO-specific certificates SHOULD consider the recommendations and guidelines defined in [RFC6125].
Software engineers developing and service providers deploying ALTO should make themselves familiar with possibly updated standards documents as well as up-to-date Best Current Practices on configuring HTTP over TLS.
ALTOを展開しているソフトウェアエンジニアおよびサービスプロバイダーは、更新される可能性のある標準ドキュメントや、HTTP over TLSの構成に関する最新のベストカレントプラクティスに精通する必要があります。
The protection of HTTP over TLS for ALTO depends on that the domain name in the URI for the information resources is not comprised. This will depend on the protection implemented by service discovery.
ALTOのHTTP over TLSの保護は、情報リソースのURIのドメイン名が含まれていないことに依存しています。これは、サービス検出によって実装される保護に依存します。
A deployment scenario may require redistribution of ALTO information to improve scalability. When authenticity and integrity of ALTO information are still required, then ALTO clients obtaining ALTO information through redistribution must be able to validate the received ALTO information. Support for this validation is not provided in this document, but it may be provided by extension documents.
展開シナリオでは、スケーラビリティを向上させるためにALTO情報の再配布が必要になる場合があります。 ALTO情報の信頼性と整合性が依然として必要な場合、再配布を通じてALTO情報を取得するALTOクライアントは、受信したALTO情報を検証できる必要があります。この検証のサポートはこのドキュメントでは提供されていませんが、拡張ドキュメントによって提供される場合があります。
15.2. Potential Undesirable Guidance from Authenticated ALTO Information
15.2. 認証されたALTO情報からの望ましくない可能性のあるガイダンス
The ALTO services make it possible for an ALTO service provider to influence the behavior of network applications. An ALTO service provider may be hostile to some applications and, hence, try to use ALTO information resources to achieve certain goals [RFC5693]:
ALTOサービスにより、ALTOサービスプロバイダーはネットワークアプリケーションの動作に影響を与えることができます。 ALTOサービスプロバイダーは一部のアプリケーションに敵対している可能性があるため、ALTO情報リソースを使用して特定の目標を達成しようとします[RFC5693]：
...redirecting applications to corrupted mediators providing malicious content, or applying policies in computing cost maps based on criteria other than network efficiency.
...悪意のあるコンテンツを提供する破損したメディエーターにアプリケーションをリダイレクトする、またはネットワーク効率以外の基準に基づいてコストマップを計算する際にポリシーを適用する。
See [ALTO-DEPLOYMENT] for additional discussions on faked ALTO guidance.
偽のALTOガイダンスの詳細については、[ALTO-DEPLOYMENT]をご覧ください。
A related scenario is that an ALTO server could unintentionally give "bad" guidance. For example, if many ALTO clients follow the cost map or the Endpoint Cost Service guidance without doing additional sanity checks or adaptation, more preferable hosts and/or links could get overloaded while less preferable ones remain idle; see AR-14 of [RFC6708] for related application considerations.
A related scenario is that an ALTO server could unintentionally give "bad" guidance. For example, if many ALTO clients follow the cost map or the Endpoint Cost Service guidance without doing additional sanity checks or adaptation, more preferable hosts and/or links could get overloaded while less preferable ones remain idle; see AR-14 of [RFC6708] for related application considerations.
To protect applications from undesirable ALTO information resources, it is important to note that there is no protocol mechanism to require conforming behaviors on how applications use ALTO information resources. An application using ALTO may consider including a mechanism to detect misleading or undesirable results from using ALTO information resources. For example, if throughput measurements do not show "better-than-random" results when using an ALTO cost map to select resource providers, the application may want to disable ALTO usage or switch to an external ALTO server provided by an "independent organization" (see AR-20 and AR-21 in [RFC6708]). If the first ALTO server is provided by the access network service provider and the access network service provider tries to redirect access to the external ALTO server back to the provider's ALTO server or try to tamper with the responses, the preceding authentication and integrity protection can detect such a behavior.
望ましくないALTO情報リソースからアプリケーションを保護するには、アプリケーションがALTO情報リソースを使用する方法に準拠する動作を要求するプロトコルメカニズムがないことに注意することが重要です。 ALTOを使用するアプリケーションは、ALTO情報リソースの使用による誤解を招く、または望ましくない結果を検出するメカニズムを含めることを検討する場合があります。たとえば、ALTOコストマップを使用してリソースプロバイダーを選択するときにスループット測定値が「ランダムより良い」結果を示さない場合、アプリケーションは、ALTOの使用を無効にするか、「独立した組織」が提供する外部のALTOサーバーに切り替える必要があります。 （[RFC6708]のAR-20およびAR-21を参照）。最初のALTOサーバーがアクセスネットワークサービスプロバイダーによって提供され、アクセスネットワークサービスプロバイダーが外部ALTOサーバーへのアクセスをプロバイダーのALTOサーバーにリダイレクトしようとしたり、応答を改ざんしようとしたりする場合、前述の認証と整合性保護により検出できます。そのような行動。
In many cases, although ALTO information resources may be regarded as non-confidential information, there are deployment cases in which ALTO information resources can be sensitive information that can pose risks if exposed to unauthorized parties. This document discusses the risks and protection strategies for such deployment scenarios.
多くの場合、ALTO情報リソースは機密情報ではないと見なされる可能性がありますが、ALTO情報リソースが機密情報であり、許可されていない者に公開された場合にリスクをもたらす可能性がある展開事例があります。このドキュメントでは、このような展開シナリオのリスクと保護戦略について説明します。
For example, an attacker may infer details regarding the topology, status, and operational policies of a network through its ALTO network and cost maps. As a result, a sophisticated attacker may be able to infer more fine-grained topology information than an ISP hosting an ALTO server intends to disclose. The attacker can leverage the information to mount effective attacks such as focusing on high-cost links.
たとえば、攻撃者は、ALTOネットワークとコストマップを介して、ネットワークのトポロジ、ステータス、運用ポリシーに関する詳細を推測する可能性があります。その結果、高度な攻撃者は、ALTOサーバーをホストしているISPが開示しようとしているよりも、よりきめの細かいトポロジ情報を推測できる可能性があります。攻撃者はこの情報を利用して、高コストのリンクに集中するなど、効果的な攻撃を仕掛けることができます。
Revealing some endpoint properties may also reveal additional information than the provider intended. For example, when adding the line bitrate as one endpoint property, such information may be potentially linked to the income of the habitants at the network location of an endpoint.
一部のエンドポイントプロパティを明らかにすると、プロバイダーが意図したよりも多くの情報が明らかになる可能性があります。たとえば、ラインビットレートを1つのエンドポイントプロパティとして追加すると、そのような情報は、エンドポイントのネットワークロケーションにいる居住者の収入にリンクされる可能性があります。
In Section 5.2.1 of [RFC6708], three types of risks associated with the confidentiality of ALTO information resources are identified: risk type (1) Excess disclosure of the ALTO service provider's data to an authorized ALTO client; risk type (2) Disclosure of the ALTO service provider's data (e.g., network topology information or endpoint addresses) to an unauthorized third party; and risk type (3) Excess retrieval of the ALTO service provider's data by collaborating ALTO clients. [ALTO-DEPLOYMENT] also discusses information leakage from ALTO.
[RFC6708]のセクション5.2.1で、ALTO情報リソースの機密性に関連する3つのタイプのリスクが識別されています。リスクタイプ（1）認可されたALTOクライアントへのALTOサービスプロバイダーのデータの過度の開示。リスクの種類（2）ALTOサービスプロバイダーのデータ（ネットワークトポロジ情報やエンドポイントアドレスなど）の不正な第三者への開示。およびリスクの種類（3）ALTOクライアントのコラボレーションによるALTOサービスプロバイダーのデータの過剰な取得。 [ALTO-DEPLOYMENT]では、ALTOからの情報漏えいについても説明しています。
To address risk types (1) and (3), the provider of an ALTO server must be cognizant that the network topology and provisioning information provided through ALTO may lead to attacks. ALTO does not require any particular level of details of information disclosure; hence, the provider should evaluate how much information is revealed and the associated risks.
リスクタイプ（1）および（3）に対処するには、ALTOサーバーのプロバイダーは、ALTOを通じて提供されるネットワークトポロジおよびプロビジョニング情報が攻撃につながる可能性があることを認識する必要があります。 ALTOは、特定レベルの情報開示の詳細を要求しません。したがって、プロバイダーは、公開される情報の量と関連するリスクを評価する必要があります。
To address risk type (2), the ALTO Protocol needs confidentiality. Since ALTO requires that HTTP over TLS must be supported, the confidentiality mechanism is provided by HTTP over TLS.
リスクタイプ（2）に対処するには、ALTOプロトコルに機密性が必要です。 ALTOではHTTP over TLSをサポートする必要があるため、機密性メカニズムはHTTP over TLSによって提供されます。
For deployment scenarios where client authentication is desired to address risk type (2), ALTO requires that HTTP Digestion Authentication is supported to achieve ALTO client authentication to limit the number of parties with whom ALTO information is directly shared. TLS client authentication may also be supported. Depending on the use case and scenario, an ALTO server may apply other access control techniques to restrict access to its services. Access control can also help to prevent Denial-of-Service attacks by arbitrary hosts from the Internet. See [ALTO-DEPLOYMENT] for a more detailed discussion on this issue.
For deployment scenarios where client authentication is desired to address risk type (2), ALTO requires that HTTP Digestion Authentication is supported to achieve ALTO client authentication to limit the number of parties with whom ALTO information is directly shared. TLS client authentication may also be supported. Depending on the use case and scenario, an ALTO server may apply other access control techniques to restrict access to its services. Access control can also help to prevent Denial-of-Service attacks by arbitrary hosts from the Internet. See [ALTO-DEPLOYMENT] for a more detailed discussion on this issue.
See Section 14.3 on guidelines when registering endpoint properties to protect endpoint privacy.
エンドポイントのプライバシーを保護するためにエンドポイントプロパティを登録する際のガイドラインについては、セクション14.3を参照してください。
ALTO information providers should be cognizant that encryption only protects ALTO information until it is decrypted by the intended ALTO client. Digital Rights Management (DRM) techniques and legal agreements protecting ALTO information are outside of the scope of this document.
ALTO情報プロバイダーは、暗号化によってALTO情報が保護されるのは、目的のALTOクライアントによって復号化されるまでであることを認識しておく必要があります。デジタル著作権管理（DRM）技術とALTO情報を保護する法的合意は、このドキュメントの範囲外です。
The ALTO Protocol provides mechanisms in which the ALTO client serving a user can send messages containing network location identifiers (IP addresses or fine-grained PIDs) to the ALTO server. This is particularly true for the Endpoint Property, the Endpoint Cost, and the fine-grained Filtered Map services. The ALTO server or a third party who is able to intercept such messages can store and process obtained information in order to analyze user behaviors and communication patterns. The analysis may correlate information collected from multiple clients to deduce additional application/ content information. Such analysis can lead to privacy risks. For a more comprehensive classification of related risk scenarios, see cases 4, 5, and 6 in [RFC6708], Section 5.2.
ALTOプロトコルは、ユーザーにサービスを提供するALTOクライアントがネットワークロケーション識別子（IPアドレスまたは細かいPID）を含むメッセージをALTOサーバーに送信できるメカニズムを提供します。これは、エンドポイントプロパティ、エンドポイントコスト、および粒度の細かいフィルターマップサービスに特に当てはまります。 ALTOサーバーまたはそのようなメッセージを傍受できるサードパーティは、ユーザーの行動や通信パターンを分析するために、取得した情報を保存および処理できます。分析は、追加のアプリケーション/コンテンツ情報を推定するために、複数のクライアントから収集された情報を相互に関連付ける場合があります。このような分析は、プライバシーリスクにつながる可能性があります。関連するリスクシナリオのより包括的な分類については、[RFC6708]、セクション5.2のケース4、5、および6を参照してください。
To protect user privacy, an ALTO client should be cognizant about potential ALTO server tracking through client queries, e.g., by using HTTP cookies. The ALTO Protocol as defined by this document does not rely on HTTP cookies. ALTO clients MAY decide not to return cookies received from the server, in order to make tracking more difficult. However, this might break protocol extensions that are beyond the scope of this document.
To protect user privacy, an ALTO client should be cognizant about potential ALTO server tracking through client queries, e.g., by using HTTP cookies. The ALTO Protocol as defined by this document does not rely on HTTP cookies. ALTO clients MAY decide not to return cookies received from the server, in order to make tracking more difficult. However, this might break protocol extensions that are beyond the scope of this document.
An ALTO client may consider the possibility of relying only on ALTO network maps for PIDs and cost maps amongst PIDs to avoid passing IP addresses of other endpoints (e.g., peers) to the ALTO server. When specific IP addresses are needed (e.g., when using the Endpoint Cost Service), an ALTO client SHOULD minimize the amount of information sent in IP addresses. For example, the ALTO client may consider obfuscation techniques such as specifying a broader address range (i.e., a shorter prefix length) or by zeroing out or randomizing the last few bits of IP addresses. Note that obfuscation may yield less accurate results.
An ALTO client may consider the possibility of relying only on ALTO network maps for PIDs and cost maps amongst PIDs to avoid passing IP addresses of other endpoints (e.g., peers) to the ALTO server. When specific IP addresses are needed (e.g., when using the Endpoint Cost Service), an ALTO client SHOULD minimize the amount of information sent in IP addresses. For example, the ALTO client may consider obfuscation techniques such as specifying a broader address range (i.e., a shorter prefix length) or by zeroing out or randomizing the last few bits of IP addresses. Note that obfuscation may yield less accurate results.
An attacker may want to disable the ALTO services of a network as a way to disable network guidance to large scale applications. In particular, queries that can be generated with low effort but result in expensive workloads at the ALTO server could be exploited for Denial-of-Service attacks. For instance, a simple ALTO query with n source network locations and m destination network locations can be generated fairly easily but results in the computation of n*m path costs between pairs by the ALTO server (see Section 5.2).
攻撃者は、大規模なアプリケーションへのネットワークガイダンスを無効にする方法として、ネットワークのALTOサービスを無効にすることができます。特に、少ない労力で生成できるが、ALTOサーバーでのワークロードが高額になるクエリは、サービス拒否攻撃に悪用される可能性があります。たとえば、n個のソースネットワークロケーションとm個の宛先ネットワークロケーションを持つ単純なALTOクエリはかなり簡単に生成できますが、ALTOサーバーによってペア間のn * mパスコストが計算されます（セクション5.2を参照）。
The ALTO service provider should be cognizant of the workload at the ALTO server generated by certain ALTO Queries, such as certain queries to the Map Service, the Map-Filtering Service and the Endpoint Cost (Ranking) Service. One way to limit Denial-of-Service attacks is to employ access control to the ALTO server. The ALTO server can also indicate overload and reject repeated requests that can cause availability problems. More advanced protection schemes such as computational puzzles [SIP] may be considered in an extension document.
ALTOサービスプロバイダーは、マップサービス、マップフィルターサービス、エンドポイントコスト（ランキング）サービスへの特定のクエリなど、特定のALTOクエリによって生成されるALTOサーバーのワークロードを認識する必要があります。サービス拒否攻撃を制限する1つの方法は、ALTOサーバーへのアクセス制御を採用することです。 ALTOサーバーは、過負荷を示し、可用性の問題を引き起こす可能性がある繰り返し要求を拒否することもできます。計算パズル[SIP]などのより高度な保護スキームは、拡張ドキュメントで検討される場合があります。
An ALTO service provider should also leverage the fact that the Map Service allows ALTO servers to pre-generate maps that can be distributed to many ALTO clients.
ALTOサービスプロバイダーは、マップサービスにより、ALTOサーバーが多くのALTOクライアントに配布できるマップを事前に生成できるという事実を活用する必要もあります。
This section details operations and management considerations based on existing deployments and discussions during protocol development. It also indicates where extension documents are expected to provide appropriate functionality discussed in [RFC5706] as additional deployment experience becomes available.
このセクションでは、既存の展開に基づく運用と管理の考慮事項と、プロトコル開発中の議論について詳しく説明します。また、追加の導入エクスペリエンスが利用可能になったときに、[RFC5706]で説明されている適切な機能を拡張ドキュメントが提供すると予想される場所も示します。
The ALTO Protocol is based on HTTP. Thus, configuring an ALTO server may require configuring the underlying HTTP server implementation to define appropriate security policies, caching policies, performance settings, etc.
ALTOプロトコルはHTTPに基づいています。したがって、ALTOサーバーを構成するには、適切なセキュリティポリシー、キャッシュポリシー、パフォーマンス設定などを定義するために、基になるHTTPサーバー実装を構成する必要がある場合があります。
Additionally, an ALTO service provider will need to configure the ALTO information to be provided by the ALTO server. The granularity of the topological map and the cost maps is left to the specific policies of the ALTO service provider. However, a reasonable default may include two PIDs, one to hold the endpoints in the provider's network and the second PID to represent full IPv4 and IPv6 reachability (see Section 11.2.2), with the cost between each source/ destination PID set to 1. Another operational issue that the ALTO service provider needs to consider is that the filtering service can degenerate into a full map service when the filtering input is empty. Although this choice as the degeneration behavior provides continuity, the computational and network load of serving full maps to a large number of ALTO clients should be considered.
さらに、ALTOサービスプロバイダーは、ALTOサーバーによって提供されるALTO情報を構成する必要があります。トポロジマップとコストマップの粒度は、ALTOサービスプロバイダーの特定のポリシーに任されています。ただし、妥当なデフォルトには2つのPIDが含まれる場合があります。1つはプロバイダーのネットワークのエンドポイントを保持するもので、もう1つは完全なIPv4およびIPv6到達可能性を表す2番目のPID（セクション11.2.2を参照）で、各ソース/宛先PID間のコストは1に設定されています。 。ALTOサービスプロバイダーが考慮する必要があるもう1つの運用上の問題は、フィルタリング入力が空の場合、フィルタリングサービスがフルマップサービスに縮退する可能性があることです。縮退動作としてのこの選択は継続性を提供しますが、フルマップを多数のALTOクライアントに提供する計算負荷とネットワーク負荷を考慮する必要があります。
Implementers employing an ALTO client should attempt to automatically discover an appropriate ALTO server. Manual configuration of the ALTO server location may be used where automatic discovery is not appropriate. Methods for automatic discovery and manual configuration are discussed in [ALTO-SERVER-DISC].
ALTOクライアントを使用する実装者は、適切なALTOサーバーを自動的に検出する必要があります。自動検出が適切でない場合は、ALTOサーバーの場所を手動で構成できます。自動検出と手動設定の方法については、[ALTO-SERVER-DISC]で説明されています。
Specifications for underlying protocols (e.g., TCP, HTTP, TLS) should be consulted for their available settings and proposed default configurations.
基盤となるプロトコル（TCP、HTTP、TLSなど）の仕様は、利用可能な設定と提案されたデフォルト構成について調べる必要があります。
This document does not detail a migration path for ALTO servers since there is no previous standard protocol providing the similar functionality.
同様の機能を提供する以前の標準プロトコルがないため、このドキュメントではALTOサーバーの移行パスについて詳しく説明しません。
There are existing applications making use of network information discovered from other entities such as whois, geo-location databases, or round-trip time measurements, etc. Such applications should consider using ALTO as an additional source of information; ALTO need not be the sole source of network information.
whois、地理位置情報データベース、往復時間測定など、他のエンティティから発見されたネットワーク情報を利用する既存のアプリケーションがあります。そのようなアプリケーションは、追加情報源としてALTOの使用を検討する必要があります。 ALTOがネットワーク情報の唯一のソースである必要はありません。
The ALTO Protocol assumes that HTTP client and server implementations exist. It also assumes that JSON encoder and decoder implementations exist.
ALTOプロトコルは、HTTPクライアントとサーバーの実装が存在することを前提としています。また、JSONエンコーダーとデコーダーの実装が存在することも前提としています。
An ALTO server assumes that it can gather sufficient information to populate Network and Cost maps. "Sufficient information" is dependent on the information being exposed, but likely includes information gathered from protocols such as IGP and EGP Routing Information Bases (see Figure 1). Specific mechanisms have been proposed (e.g., [ALTO-SVR-APIS]) and are expected to be provided in extension documents.
ALTOサーバーは、ネットワークマップとコストマップを生成するのに十分な情報を収集できると想定しています。 「十分な情報」は、公開される情報に依存しますが、IGPやEGPルーティング情報ベースなどのプロトコルから収集された情報が含まれる可能性があります（図1を参照）。特定のメカニズムが提案され（[ALTO-SVR-APIS]など）、拡張ドキュメントで提供されることが期待されています。
ALTO presents a new opportunity for managing network traffic by providing additional information to clients. In particular, the deployment of an ALTO server may shift network traffic patterns, and the potential impact to network operation can be large. An ALTO service provider should ensure that appropriate information is being exposed. Privacy implications for ISPs are discussed in Section 15.3.
ALTOは、クライアントに追加情報を提供することにより、ネットワークトラフィックを管理する新しい機会を提供します。特に、ALTOサーバーの展開により、ネットワークトラフィックのパターンが変化する可能性があり、ネットワーク運用への潜在的な影響が大きくなる可能性があります。 ALTOサービスプロバイダーは、適切な情報が公開されていることを確認する必要があります。 ISPのプライバシーへの影響については、セクション15.3で説明します。
An ALTO service provider should consider how to measure impacts on (or integration with) traffic engineering, in addition to monitoring correctness and responsiveness of ALTO servers. The measurement of impacts can be challenging because ALTO-enabled applications may not provide related information back to the ALTO service provider. Furthermore, the measurement of an ALTO service provider may show that ALTO clients are not bound to ALTO server guidance as ALTO is only one source of information.
An ALTO service provider should consider how to measure impacts on (or integration with) traffic engineering, in addition to monitoring correctness and responsiveness of ALTO servers. The measurement of impacts can be challenging because ALTO-enabled applications may not provide related information back to the ALTO service provider. Furthermore, the measurement of an ALTO service provider may show that ALTO clients are not bound to ALTO server guidance as ALTO is only one source of information.
While it can be challenging to measure the impact of ALTO guidance, there exist some possible techniques. In certain trusted deployment environments, it may be possible to collect information directly from ALTO clients. It may also be possible to vary or selectively disable ALTO guidance for a portion of ALTO clients either by time, geographical region, or some other criteria to compare the network traffic characteristics with and without ALTO.
ALTOガイダンスの影響を測定することは難しい場合がありますが、いくつかの可能な手法が存在します。特定の信頼されたデプロイメント環境では、ALTOクライアントから直接情報を収集できる場合があります。 ALTOクライアントの一部のALTOガイダンスを、時間、地理的地域、またはその他の基準によって変更または選択的に無効にして、ALTOがある場合とない場合のネットワークトラフィック特性を比較することもできます。
Both ALTO service providers and those using ALTO clients should be aware of the impact of incorrect or faked guidance (see [ALTO-DEPLOYMENT]).
ALTOサービスプロバイダーとALTOクライアントを使用するプロバイダーの両方が、誤ったまたは偽のガイダンスの影響を認識している必要があります（[ALTO-DEPLOYMENT]を参照）。
A common management API would be desirable given that ALTO servers may typically be configured with dynamic data from various sources, and ALTO servers are intended to scale horizontally for fault-tolerance and reliability. A specific API or protocol is outside the scope of this document, but may be provided by an extension document.
ALTOサーバーは通常、さまざまなソースからの動的データで構成され、フォールトトレランスと信頼性のために水平方向にスケーリングすることを目的としているため、共通の管理APIが望ましいでしょう。特定のAPIまたはプロトコルは、このドキュメントの範囲外ですが、拡張ドキュメントによって提供される場合があります。
Logging is an important functionality for ALTO servers and, depending on the deployment, ALTO clients. Logging should be done via syslog [RFC5424].
ロギングは、ALTOサーバーにとって重要な機能であり、デプロイメントによってはALTOクライアントにとっても重要です。ロギングは、syslog [RFC5424]を介して行う必要があります。
A Management Information Model (see Section 3.2 of [RFC5706]) is not provided by this document, but should be included or referenced by any extension documenting an ALTO-related management API or protocol.
管理情報モデル（[RFC5706]のセクション3.2を参照）はこのドキュメントでは提供されていませんが、ALTO関連の管理APIまたはプロトコルを文書化した拡張機能に含まれるか参照される必要があります。
An ALTO service provider should monitor whether any ALTO servers have failed. See Section 16.2.5 for related metrics that may indicate server failures.
ALTOサービスプロバイダーは、ALTOサーバーに障害が発生したかどうかを監視する必要があります。サーバー障害を示す可能性のある関連メトリックについては、セクション16.2.5を参照してください。
Standardized approaches and protocols to configuration management for ALTO are outside the scope of this document, but this document does outline high-level principles suggested for future standardization efforts.
ALTOの構成管理に対する標準化されたアプローチとプロトコルは、このドキュメントの範囲外ですが、このドキュメントは、将来の標準化の取り組みのために提案された高レベルの原則を概説しています。
An ALTO server requires at least the following logical inputs:
ALTOサーバーには、少なくとも次の論理入力が必要です。
o Data sources from which ALTO information resources is derived. This can be either raw network information (e.g., from routing elements) or pre-processed ALTO-level information in the forms of network maps, cost maps, etc.
o ALTO情報リソースの派生元のデータソース。これは、生のネットワーク情報（ルーティング要素などから）またはネットワークマップ、コストマップなどの形式で前処理されたALTOレベルの情報のいずれかです。
o Algorithms for computing the ALTO information returned to clients. These could return either information from a database or information customized for each client.
o クライアントに返されるALTO情報を計算するためのアルゴリズム。これらは、データベースからの情報、または各クライアント用にカスタマイズされた情報を返す可能性があります。
o Security policies mapping potential clients to the information that they have privilege to access.
o 潜在的なクライアントを、アクセスする特権を持つ情報にマッピングするセキュリティポリシー。
Multiple ALTO servers can be deployed for scalability. A centralized configuration database may be used to ensure they are providing the desired ALTO information with appropriate security controls. The ALTO information (e.g., network maps and cost maps) being served by each ALTO server, as well as security policies (HTTP authentication, TLS client and server authentication, TLS encryption parameters) intended to serve the same information should be monitored for consistency.
スケーラビリティーのために複数のALTOサーバーをデプロイできます。一元化された構成データベースを使用して、適切なセキュリティ管理機能を備えた希望のALTO情報を確実に提供できます。各ALTOサーバーによって提供されるALTO情報（ネットワークマップやコストマップなど）と、同じ情報を提供することを目的としたセキュリティポリシー（HTTP認証、TLSクライアントおよびサーバー認証、TLS暗号化パラメーター）は、一貫性を保つために監視する必要があります。
An exhaustive list of desirable performance information from ALTO servers and ALTO clients are outside of the scope of this document. The following is a list of suggested ALTO-specific metrics to be monitored based on the existing deployment and protocol development experience:
An exhaustive list of desirable performance information from ALTO servers and ALTO clients are outside of the scope of this document. The following is a list of suggested ALTO-specific metrics to be monitored based on the existing deployment and protocol development experience:
o Requests and responses for each service listed in an information directory (total counts and size in bytes);
o 情報ディレクトリにリストされている各サービスの要求と応答（合計数とサイズ（バイト））。
o CPU and memory utilization;
o CPUとメモリの使用率。
o ALTO map updates;
o ALTOマップの更新。
o Number of PIDs;
o PIDの数。
o ALTO map sizes (in-memory size, encoded size, number of entries).
o ALTOマップサイズ（メモリ内サイズ、エンコードサイズ、エントリ数）。
Section 15 documents ALTO-specific security considerations. Operators should configure security policies with those in mind. Readers should refer to HTTP [RFC7230] and TLS [RFC5246] and related documents for mechanisms available for configuring security policies. Other appropriate security mechanisms (e.g., physical security, firewalls, etc.) should also be considered.
セクション15では、ALTO固有のセキュリティに関する考慮事項について説明します。オペレーターは、それらを考慮してセキュリティー・ポリシーを構成する必要があります。セキュリティポリシーの構成に使用できるメカニズムについては、読者がHTTP [RFC7230]およびTLS [RFC5246]と関連ドキュメントを参照する必要があります。その他の適切なセキュリティメカニズム（物理的なセキュリティ、ファイアウォールなど）も検討する必要があります。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC2046] Freed、N。およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part Two：Media Types」、RFC 2046、1996年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、2005年1月。
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, August 2006.
[RFC4632] Fuller、V。およびT. Li、「Classless Inter-domain Routing（CIDR）：the Internet Address Assignment and Aggregation Plan」、BCP 122、RFC 4632、2006年8月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、2008年8月。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[RFC5389] Rosenberg、J.、Mahy、R.、Matthews、P。、およびD. Wing、「NAT用セッショントラバーサルユーティリティ（STUN）」、RFC 5389、2008年10月。
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[RFC5424] Gerhards、R。、「Syslogプロトコル」、RFC 5424、2009年3月。
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010.
[RFC5952] Kawamura、S. and M. Kawashima、 "A Recommendation for IPv6 Address Text Representation"、RFC 5952、August 2010。
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, March 2011.
[RFC6125] Saint-Andre、P。およびJ. Hodges、「トランスポート層セキュリティ（TLS）のコンテキストでX.509（PKIX）証明書を使用したインターネット公開鍵インフラストラクチャ内のドメインベースのアプリケーションサービスIDの表現と検証」、 RFC 6125、2011年3月。
[RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 2014.
[RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 2014.
[ALTO-DEPLOYMENT] Stiemerling, M., Ed., Kiesel, S., Ed., Previdi, S., and M. Scharf, "ALTO Deployment Considerations", Work in Progress, February 2014.
[ALTO-DEPLOYMENT] Stiemerling、M.、Ed。、Kiesel、S.、Ed。、Previdi、S.、and M. Scharf、 "ALTO Deployment Considerations"、Work in Progress、2014年2月。
[ALTO-INFOEXPORT] Shalunov, S., Penno, R., and R. Woundy, "ALTO Information Export Service", Work in Progress, October 2008.
[ALTO-INFOEXPORT] Shalunov、S.、Penno、R。、およびR. Woundy、「ALTO Information Export Service」、Work in Progress、2008年10月。
[ALTO-MULTI-PS] Das, S., Narayanan, V., and L. Dondeti, "ALTO: A Multi Dimensional Peer Selection Problem", Work in Progress, October 2008.
[ALTO-MULTI-PS] Das、S.、Narayanan、V。、およびL. Dondeti、「ALTO：多次元ピア選択問題」、進行中の作業、2008年10月。
[ALTO-QUERYRESPONSE] Das, S. and V. Narayanan, "A Client to Service Query Response Protocol for ALTO", Work in Progress, March 2009.
[ALTO-QUERYRESPONSE] Das、S。、およびV. Narayanan、「ALTOのクライアントからサービスへのクエリ応答プロトコル」、進行中の作業、2009年3月。
[ALTO-SERVER-DISC] Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., and H. Song, "ALTO Server Discovery", Work in Progress, September 2013.
[ALTO-SERVER-DISC]キーゼル、S。、スティーマーリング、M。、シュワン、N。、シャーフ、M。、およびH.ソング、「ALTOサーバーディスカバリー」、作業中、2013年9月。
[ALTO-SVR-APIS] Medved, J., Ward, D., Peterson, J., Woundy, R., and D. McDysan, "ALTO Network-Server and Server-Server APIs", Work in Progress, March 2011.
[ALTO-SVR-APIS] Medved、J.、Ward、D.、Peterson、J.、Woundy、R。、およびD. McDysan、「ALTO Network-Server and Server-Server APIs」、Work in Progress、2011年3月。
[ALTO-USE-CASES] Niven-Jenkins, B., Watson, G., Bitar, N., Medved, J., and S. Previdi, "Use Cases for ALTO within CDNs", Work in Progress, June 2012.
[ALTO-USE-CASES] Niven-Jenkins, B., Watson, G., Bitar, N., Medved, J., and S. Previdi, "Use Cases for ALTO within CDNs", Work in Progress, June 2012.
[BitTorrent] "Bittorrent Protocol Specification v1.0", <http://wiki.theory.org/BitTorrentSpecification>.
[BitTorrent]「Bittorrent Protocol Specification v1.0」、<http://wiki.theory.org/BitTorrentSpecification>。
[Fielding-Thesis] Fielding, R., "Architectural Styles and the Design of Network-based Software Architectures", University of California, Irvine, Dissertation 2000, 2000.
[Fielding-Thesis] Fielding、R。、「Architectural Styles and the Design of Network-based Software Architectures」、カリフォルニア大学アーバイン校、Dissertation 2000、2000。
[IEEE.754.2008] Institute of Electrical and Electronics Engineers, "Standard for Binary Floating-Point Arithmetic", IEEE Standard 754, August 2008.
[IEEE.754.2008] Institute of Electrical and Electronics Engineers, "Standard for Binary Floating-Point Arithmetic", IEEE Standard 754, August 2008.
[P4P-FRAMEWORK] Alimi, R., Pasko, D., Popkin, L., Wang, Y., and Y. Yang, "P4P: Provider Portal for P2P Applications", Work in Progress, November 2008.
[P4P-FRAMEWORK] Alimi、R.、Pasko、D.、Popkin、L.、Wang、Y。、およびY. Yang、「P4P：Provider Portal for P2P Applications」、Work in Progress、2008年11月。
[P4P-SIGCOMM08] Xie, H., Yang, Y., Krishnamurthy, A., Liu, Y., and A. Silberschatz, "P4P: Provider Portal for (P2P) Applications", SIGCOMM 2008, August 2008.
[P4P-SIGCOMM08] Xie、H.、Yang、Y.、Krishnamurthy、A.、Liu、Y.、A。Silberschatz、「P4P：Provider Portal for（P2P）Applications」、SIGCOMM 2008、2008年8月。
[P4P-SPEC] Wang, Y., Alimi, R., Pasko, D., Popkin, L., and Y. Yang, "P4P Protocol Specification", Work in Progress, March 2009.
[P4P-SPEC] Wang、Y.、Alimi、R.、Pasko、D.、Popkin、L。、およびY. Yang、「P4Pプロトコル仕様」、Work in Progress、2009年3月。
[PROXIDOR] Akonjang, O., Feldmann, A., Previdi, S., Davie, B., and D. Saucez, "The PROXIDOR Service", Work in Progress, March 2009.
[PROXIDOR] Akonjang、O.、Feldmann、A.、Previdi、S.、Davie、B。、およびD. Saucez、「PROXIDORサービス」、2009年3月、作業中。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818] Rescorla、E。、「HTTP over TLS」、RFC 2818、2000年5月。
[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic Optimization (ALTO) Problem Statement", RFC 5693, October 2009.
[RFC5693] Seedorf、J。およびE. Burger、「Application-Layer Traffic Optimization（ALTO）Problem Statement」、RFC 5693、2009年10月。
[RFC5706] Harrington, D., "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions", RFC 5706, November 2009.
[RFC5706]ハリントンD.、「新しいプロトコルとプロトコル拡張の操作と管理を検討するためのガイドライン」、RFC 5706、2009年11月。
[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", RFC 6144, April 2011.
[RFC6144] Baker、F.、Li、X.、Bao、C。、およびK. Yin、「Framework for IPv4 / IPv6 Translation」、RFC 6144、2011年4月。
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix Translation", RFC 6296, June 2011.
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix Translation", RFC 6296, June 2011.
[RFC6708] Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and Y. Yang, "Application-Layer Traffic Optimization (ALTO) Requirements", RFC 6708, September 2012.
[RFC6708] Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and Y. Yang, "Application-Layer Traffic Optimization (ALTO) Requirements", RFC 6708, September 2012.
[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, March 2014.
[RFC7159]ブレイ、T。、「JavaScript Object Notation（JSON）データ交換フォーマット」、RFC 7159、2014年3月。
[RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, June 2014.
[RFC7231] Fielding、R。およびJ. Reschke、「Hypertext Transfer Protocol（HTTP / 1.1）：Semantics and Content」、RFC 7231、2014年6月。
[SIP] Jennings, C., "Computational Puzzles for SPAM Reduction in SIP", Work in Progress, July 2007.
[SIP] Jennings、C。、「SIPにおけるSPAM削減のための計算パズル」、2007年7月、作業中。
Thank you to Jan Seedorf (NEC) for substantial contributions to the Security Considerations section. Ben Niven-Jenkins (Velocix), Michael Scharf, and Sabine Randriamasy (Alcatel-Lucent) gave substantial feedback and suggestions on the protocol design.
セキュリティに関する考慮事項のセクションに多大な貢献をしてくれたJan Seedorf（NEC）に感謝します。 Ben Niven-Jenkins（Velocix）、Michael Scharf、およびSabine Randriamasy（Alcatel-Lucent）は、プロトコル設計に関する実質的なフィードバックと提案を行いました。
We would like to thank the following people whose input and involvement was indispensable in achieving this merged proposal:
この統合された提案を達成するためにインプットと関与が不可欠であった以下の人々に感謝します。
Obi Akonjang (DT Labs/TU Berlin),
おび あこんじゃんｇ （ＤＴ ぁｂｓ／つ べｒぃん）、
Saumitra M. Das (Qualcomm Inc.),
サウミトラM.ダス（クアルコム株式会社）
Syon Ding (China Telecom),
Syon Ding（China Telecom）、
Doug Pasko (Verizon),
Doug Pasko (Verizon),
Laird Popkin (Pando Networks),
Laird Popkin（Pando Networks）、
Satish Raghunath (Juniper Networks),
Satish Raghunath（ジュニパーネットワークス）、
Albert Tian (Ericsson/Redback),
Albert Tian（エリクソン/レッドバック）、
Yu-Shun Wang (Microsoft),
Y U-S Soul Wang（Microsoft）、
David Zhang (PPLive),
David Zhang（PPLive）、
Yunfei Zhang (China Mobile).
Yunfei Zhang (China Mobile).
We would also like to thank the following additional people who were involved in the projects that contributed to this merged document: Alex Gerber (ATT), Chris Griffiths (Comcast), Ramit Hora (Pando Networks), Arvind Krishnamurthy (University of Washington), Marty Lafferty (DCIA), Erran Li (Bell Labs), Jin Li (Microsoft), Y. Grace Liu (IBM Watson), Jason Livingood (Comcast), Michael Merritt (ATT), Ingmar Poese (DT Labs/TU Berlin), James Royalty (Pando Networks), Damien Saucez (UCL), Thomas Scholl (ATT), Emilio Sepulveda (Telefonica), Avi Silberschatz (Yale University), Hassan Sipra (Bell Canada), Georgios Smaragdakis (DT Labs/TU Berlin), Haibin Song (Huawei), Oliver Spatscheck (ATT), See-Mong Tang (Microsoft), Jia Wang (ATT), Hao Wang (Yale University), Ye Wang (Yale University), Haiyong Xie (Yale University).
このマージされたドキュメントに貢献したプロジェクトに関与した次の追加の人々にも感謝します：Alex Gerber（ATT）、Chris Griffiths（Comcast）、Ramit Hora（Pando Networks）、Arvind Krishnamurthy（University of Washington）、 Marty Lafferty（DCIA）、Erran Li（Bell Labs）、Jin Li（Microsoft）、Y。Grace Liu（IBM Watson）、Jason Livingood（Comcast）、Michael Merritt（ATT）、Ingmar Poese（DT Labs / TU Berlin）、ジェームズロイヤルティ（パンドネットワークス）、ダミアンサウセス（UCL）、トーマスショール（ATT）、エミリオセプルベダ（テレフォニカ）、アビシルバーシャッツ（イェール大学）、ハッサンシプラ（ベルカナダ）、ゲオルギオススマラグダキス（DT Labs / TUベルリン）、ハイビンSong（Huawei）、Oliver Spatscheck（ATT）、See-Mong Tang（Microsoft）、Jia Wang（ATT）、Hao Wang（イェール大学）、Ye Wang（イェール大学）、Haiyong Xie（イェール大学）。
Stanislav Shalunov would like to thank BitTorrent, where he worked while contributing to ALTO development.
Stanislav Shalunovは、ALTOの開発に貢献しながら働いたBitTorrentに感謝します。
The ALTO Protocol specified in this document consists of contributions from
このドキュメントで指定されているALTOプロトコルは、
o P4P [P4P-FRAMEWORK], [P4P-SIGCOMM08], [P4P-SPEC];
o P4P [P4P-FRAMEWORK]、[P4P-SIGCOMM08]、[P4P-SPEC];
o ALTO Info-Export [ALTO-INFOEXPORT];
o ALTO Info-Export [ALTO-INFOEXPORT];
o Query/Response [ALTO-QUERYRESPONSE], [ALTO-MULTI-PS]; and
o クエリ/レスポンス[ALTO-QUERYRESPONSE]、[ALTO-MULTI-PS];そして
o Proxidor [PROXIDOR].
o プロジェクター[PROXIDOR]。
Authors' Addresses
著者のアドレス
Richard Alimi (editor) Google 1600 Amphitheatre Parkway Mountain View, CA 94043 USA
Richard Alimi（編集者）Google 1600 Amphitheatre Parkway Mountain View、CA 94043 USA
EMail: ralimi@google.com
Reinaldo Penno (editor) Cisco Systems, Inc. 170 West Tasman Dr San Jose, CA 95134 USA
Reinaldo Penno（編集者）Cisco Systems、Inc. 170 West Tasman Dr San Jose、CA 95134 USA
EMail: repenno@cisco.com
Y. Richard Yang (editor) Yale University 51 Prospect St New Haven, CT 06511 USA
Y.リチャードヤン（編集者）イェール大学51プロスペクトセントニューヘブン、コネチカット06511アメリカ
EMail: yry@cs.yale.edu Sebastian Kiesel University of Stuttgart Information Center Networks and Communication Systems Department Allmandring 30 Stuttgart 70550 Germany
メール：yry@cs.yale.eduセバスチャンキーゼルシュトゥットガルト大学情報センターネットワークおよび通信システム部門Allmandring 30シュトゥットガルト70550ドイツ
EMail: ietf-alto@skiesel.de
Stefano Previdi Cisco Systems, Inc. Via Del Serafico, 200 Rome 00142 Italy
Stefano Previdi Cisco Systems、Inc. Via Del Serafico、200 Rome 00142 Italy
EMail: sprevidi@cisco.com
Wendy Roome Alcatel-Lucent 600 Mountain Ave. Murray Hill, NJ 07974 USA
Wendy Roome Alcatel-Lucent 600 Mountain Ave. Murray Hill、NJ 07974 USA
EMail: w.roome@alcatel-lucent.com
Stanislav Shalunov Open Garden 751 13th St San Francisco, CA 94130 USA
Stanislav Shalunov Open Garden 751 13th St San Francisco、CA 94130 USA
EMail: shalunov@shlang.com
Richard Woundy Comcast Cable Communications One Comcast Center 1701 John F. Kennedy Boulevard Philadelphia, PA 19103 USA
Richard Woundy Comcast Cable Communications One Comcast Center 1701 John F. Kennedy Boulevard Philadelphia、PA 19103 USA
EMail: Richard_Woundy@cable.comcast.com