[要約] この文書は、アプリケーション層がネットワークのトポロジ情報を取得してトラフィックを最適化するための「ALTO (Application-Layer Traffic Optimization)」プロトコルの基本仕様を定義しています。P2PやCDNなどのアプリケーションが、ISPから提供されるコストマップやネットワークマップを利用して、通信遅延や帯域幅の観点で最適な接続先を選択するための、HTTPベースのRESTfulな通信手順を規定しています。
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）の成果です。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および本書の著者として記載された人々。All rights reserved.
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 Trustの法的規定（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.
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サービスが提供するネットワーク情報を、その地域の「my-Internet view」と呼びます。
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 view」はネットワークの内部トポロジを規定しないため、「single-node」の抽象トポロジを提供すると説明されます。この文書の拡張仕様では、「my-Internet view」にトポロジの詳細を追加する場合があります。
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情報は、多数のアプリケーションやユーザーにとって有用な場合があります。同時に、その配布は効率的に行い、ボトルネックを生じさせないようにする必要があります。
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情報を提供するマップサービスと、追加の3つの情報サービス、すなわちマップフィルタリングサービス、エンドポイントプロパティサービス（EPS）、エンドポイントコストサービス（ECS）を定義することで達成します。関連文書で追加の情報サービスを定義できます。図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サーバーが定義するグループ）があります。ADSL（Asymmetric Digital Subscriber Line）、ケーブル接続、FTTH（Fiber To The Home）などの接続種別もプロパティの例です。
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情報の粒度によって異なることです。ある環境では同じサブネット上のエンドポイントを近接していると見なす一方、別の環境では同じ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は、Provider-defined Identifier（PID）と呼ぶプロバイダー定義のネットワークロケーション識別子を導入します。これにより、ネットワークトポロジ、種別、その他のプロパティに基づいて同様に扱えるネットワークエンドポイント群を、ネットワーク方式に依存せず間接的に指定できます。具体的には、PIDはPIDName型（セクション10.1参照）の文字列で表され、それにエンドポイントアドレスの集合が関連付けられます。前述のとおり、エンドポイントをグループ化してPIDを割り当てる方法は多数あります。たとえば、PIDはサブネット、サブネット群、都市圏、POP、自律システム、または自律システム群を表せます。ALTOネットワークマップで定義されたPIDを「single-node」抽象化に基づいて解釈すると、各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の主な用途の1つは、個々のエンドポイントではなくPID間のネットワーク選好（コスト）を指定することです。これにより、コスト情報をより簡潔に表現し、ネットワーク集約自体より短い時間間隔で更新できます。たとえば、ISPは、P2Pアプリケーションで同じPOPに属するエンドポイント同士が、他のPOPのエンドポイントと通信するよりもローカルに通信することを望む場合があります。ISPは、POP内のエンドポイントをネットワークマップ内の単一のPIDに集約できます。コストを符号化して、同じPID内のネットワークロケーションが優先されることを示せます。たとえば、cost(PID_i, PID_i) == c および cost(PID_i, PID_j) > c for i != j です。ALTOコストマップでPIDを使ってコストを表す方法の詳細は、セクション6を参照してください。
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など、アドレスには多くの種類があります。本書では、IPv4/IPv6アドレスまたはプレフィックスの指定方法をセクション10.4で規定します。拡張文書で他のアドレス種別を定義することもできます。本書のセクション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」コストメトリックを提供しなければなりません (MUST)。
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アドレスの集合と、それらの順位を示すコストを返す場合があります。数値には意味のある算術演算でも、序数ランキングには意味がありません。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つ（数値または序数）をサポートしなければなりません (MUST)。希望するコストモードがサポートされない場合にどの操作を行うかを、ALTOクライアントは考慮する必要があります。具体的には、数値コストを希望するALTOクライアントは、序数コストモードしか利用できない場合、動作を調整してもよい (MAY) です。逆に、序数コストを希望する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.
このコストモードは文字列 "numerical" で示します。このモードは、返されたコストに数値演算（正規化や、重み付き負荷分散に用いる比率の計算など）を安全に適用できることを示します。値は浮動小数点数です。
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" で示します。このモードでは、コストマップ内のコスト値は実際のコストではなく、コストマップ内の他のすべての値と比較した順位を表します。値は0以上の整数で、値が小さいほど優先度が高いことを示します。コストマップ内の序数コスト値は、一意である必要も連続している必要もありません。特に、コストマップ内の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ネットワークマップのコンテンツが変更されるたびに、タグも変更しなければなりません (MUST)。タグの構成要素の設定方法としては、ネットワークマップの最終変更タイムスタンプや、実際の展開シナリオでは衝突確率がゼロとみなせるようなそのコンテンツのハッシュなどが考えられます。
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" を定義しなければなりません (MUST)。具体的には、各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プロトコルはRESTful設計を採用します。この設計には主な構成要素が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].
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クライアントとサーバーは、すべてのALTO要求パラメーター（ある場合）と応答に汎用のapplication/jsonメディアタイプを使う代わりに、コンテンツ種別を示す複数の個別のJSONベースのメディアタイプ（application/alto-networkmap+json、application/alto-costmap+jsonなど）を使います。本書で定義するメディアタイプの一覧は表2を参照してください。この方式により、明確な意味とバージョン管理を保ちながら容易に拡張できます。たとえば、application/alto-networkmap-v2+jsonなどの新しいメディアタイプを導入するだけで、ALTOプロトコルの構成要素（ALTOネットワークマップなど）の新しいバージョンを定義できます。
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クライアントのRoot IRDと呼びます。IRD内の各エントリーは、ALTOサーバーが要求を受け付けるURIを示します。そのURIへの要求に対する応答は、情報リソース、または追加の情報リソースを参照する情報リソースディレクトリのいずれかです。Root 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メソッドを使わなければなりません (MUST)。
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ヘッダーを、提供された入力パラメーターの形式に対応するメディアタイプに設定しなければなりません (MUST)。
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メソッドが交換可能であることを想定してはなりません (MUST NOT)。特に、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サーバーは、明示的な鮮度情報（[RFC7230]のセクション14参照）を含めることで、キャッシュ機能を持つHTTP中継者を利用してGET要求とPOST要求の両方に応答できます。HTTP中継者ではPOST要求のキャッシュが広く実装されていません。代替策として、ALTOサーバーはPOST要求への応答でHTTP 303ステータスコード（"See Other"）を返し、結果の情報リソースを別のURLへのGET要求で取得できることをALTOクライアントに示せます。POST要求のキャッシュをサポートしないHTTP中継者でも、その後のGET要求への応答に明示的な鮮度情報が含まれていれば、ALTOクライアントが303応答の別URLに従って送った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で通知されたメディアタイプや要求で指定したメディアタイプと同じだと想定してはなりません (MUST NOT)（つまり、クライアントは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情報を使わずにピアを選択します。
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ダイジェスト認証をサポートしなければなりません (MUST)。 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メッセージを処理するときに不明なフィールドを無視しなければなりません (MUST)。
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ステータスコードを設定しなければなりません (MUST)。 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エラー応答は、応答の "meta" フィールドに "code" という名前のフィールドを含めなければなりません (MUST)。その値は、表1で定義するALTOエラーコードを文字列としてエンコードしたものでなければなりません (MUST)。表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サーバーはエラー応答の "meta" フィールドに "syntax-error" という任意のフィールドを含めてもよい (MAY) です。"syntax-error" を含める目的は、エンドユーザーではなく開発者に技術的なデバッグ情報を提供することです。そのため、この値は構文エラーを説明する、人が読める自由形式のテキストにします。可能な場合は、行番号や行内オフセットなど、構文エラーの位置情報を含めます。最低限、"syntax-error" フィールドの値に位置だけを含めてもかまいません。実運用環境で構文エラーが発生した場合、ALTOクライアントは、ALTOサーバーとの通信中にエラーが発生したことをエンドユーザーに知らせ、"syntax-error" を含むエラー情報を開発者に送るようユーザーに提案できます。
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コードで示します。本書では、Filtered Network Map（セクション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".
Filtered Cost Map（セクション11.3.2.3）、Endpoint Properties（セクション11.4.1.3）、Endpoint Cost（セクション11.5.1.3）の各サービスについて必須フィールドを定義します。E_MISSING_FIELDエラーの場合、欠落したフィールドを示すため、サーバーはエラー応答の "meta" フィールドに "field" という任意のフィールドを含めることがあります。"field" は、欠落したフィールドの完全なパスを示すJSONStringにします。たとえば、Filtered Cost Map要求（セクション11.3.2.3参照）で "cost-metric" フィールドが省略されたとします。ALTOサーバーのエラー応答では、"field" の値として "cost-type/cost-metric" を指定できます。
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コードで示します。誤った型を含むフィールドを示すため、サーバーは応答の "meta" フィールドに "field" という任意のフィールドを含めることがあります。
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:
フィールドとその値の型が正しい要求でも、フィールドに誤った値が指定される場合があります。たとえば、Filtered Cost Map要求の "cost-type" フィールドでCostModeに誤った値を指定する場合です（セクション11.3.2.3）。サーバーは、このエラーをE_INVALID_FIELD_VALUEコードで示します。E_INVALID_FIELD_VALUEエラーの場合、誤った値を含むフィールドを示すため、サーバーは応答の "meta" フィールドに "field" という任意のフィールドを含めることがあります。また、エラーの原因となった誤った値を示すため、"meta" フィールドに "value" という任意のフィールドを含めることもあります。"value" フィールドを指定する場合は、"field" フィールドも指定しなければなりません (MUST)。"value" フィールドの値はJSONStringでなければなりません (MUST)。無効な値が文字列でない場合、ALTOサーバーはその値を文字列に変換しなければなりません (MUST)。"value" キーの指定規則は次のとおりです。
o If the invalid value is a string, "value" is that string;
o 無効な値が文字列の場合、"value" はその文字列です。
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 無効な値がサブフィールドの場合、サーバーは "field" キーにフィールド名の完全なパスを設定し、"value" に無効なサブフィールド値を設定します。必要に応じて、その値は文字列に変換します。たとえば、"cost-type" フィールドの "cost-mode" サブフィールドに無効なモード "foo" が指定された場合、サーバーは "value" を "foo" に、"field" を "cost-mode/cost-type" に設定します。
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配列の要素の値が無効な場合、サーバーは "value" にその要素の値を文字列として設定し、"field" に配列名を設定します。配列要素の型が誤っている場合（たとえば、文字列配列が期待されるところに数値がある場合）も、無効な型エラーではなく無効な値エラーです。サーバーは "value" に誤った要素を文字列にした値を、"field" に配列名を設定します。
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つを返さなければなりません (MUST)。ただし、メッセージ処理の特定の順序を規定すると実装手法を不必要に制約することになるため、報告されるエラーは実装定義です。
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クライアントが要求できる各情報リソースには、クライアントの情報リソース閉包に含まれるすべての情報リソースの中で一意となるresource ID属性を割り当てなければなりません (MUST)。そのリソースが提供するデータが変化しても、resource IDは安定しているべきです (SHOULD)。たとえば、ALTOネットワークマップ内のPID数を変更しても、resource IDは同じままであることが望ましいです。同様に、ALTOコストマップのエントリーを更新しても、resource IDは同じままであることが望ましいです。IDを時間の経過とともに別のリソースに再利用すべきではありません (SHOULD NOT)。
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.
情報リソースのCapabilities属性は、サーバーが提供できる特定の機能を示します。たとえば、クライアントがコストマップ情報リソースを要求する際にALTOサーバーがコスト制約を指定できるようにしている場合、サーバーはそのコストマップ情報リソースの "cost-constraints" 機能を通知します。
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クライアントに入力パラメーターの指定を許可する場合があります。その情報リソースに関連付けられた "accepts" 属性はメディアタイプを指定し、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に利用できるようにしなければなりません (MUST)。この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" エントリーで使用できる複数のCostTypeに名前を割り当て、指定を簡潔にすることです。IRD内の "cost-types" で定義する名前は、その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.
Root IRDでは、"meta" に "default-alto-network-map" というフィールドを含めなければなりません (MUST)。その値はALTOネットワークマップのresource 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:
情報リソースディレクトリ応答のdataコンポーネントは "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に従って解決しなければなりません (MUST)。
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を参照）。このフィールドが存在しない場合は、空であると想定しなければなりません (MUST)。
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オブジェクト。このフィールドが存在しない場合は、空のオブジェクトであると想定しなければなりません (MUST)。提供された情報リソースのいずれかの機能がここに明示的にリストされていない場合、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.
uses: 同じIRD内で定義され、このリソースが直接依存するリソースを示すresource 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.
"accepts" の値が空の一覧であるエントリーでは、対応するURIはGET要求をサポートしなければなりません (MUST)。"accepts" の値が空でないエントリーでは、対応するURIはPOST要求をサポートしなければなりません (MUST)。ALTOサーバーが単一のURIでGETとPOSTの両方をサポートする場合、情報リソースディレクトリに2つのエントリーを指定しなければなりません (MUST)。
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の "meta" にある "cost-types" フィールドは、このIRD内の4つのコスト種別に名前を定義します。たとえば、この例の "num-routing" は、コストモードが "numerical"、コスト指標が "routingcost" であるコスト種別を指す名前です。この名前は、コストマップを定義する "resources" の2番目のエントリーで使われます。具体的には、そのエントリーの "capabilities" にある "cost-type-names" が、このリソースは "num-routing" という名前のコスト種別をサポートすると示します。ALTOクライアントはIRDの "cost-types" 内で "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の "meta" で定義されるもう1つのフィールドは "default-alto-network-map" で、その値は "my-default-network-map" です。これは、"resources" で定義されるALTOネットワークマップのresource 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の "resources" フィールドは、6つの情報リソースを定義します。たとえば、resource ID "numerical-routing-cost-map" が割り当てられた2番目のエントリーは、media-type "application/alto-costmap+json" が示すとおり、コストマップを提供します。このコストマップは、resource ID "my-default-network-map" で定義されるネットワークマップに基づきます。また、resource ID "endpoint-cost" が割り当てられた最後のエントリーは、media-type "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クライアントは、情報リソースの "accepts" 属性で指定された "application/alto-endpointcostparams+json" メディアタイプに要求本文を整形することが望ましいです。情報リソースの "capabilities" 属性にある "cost-type-names" フィールドには、IRDの "meta" の "cost-types" フィールドで指定された4つのコスト種別が含まれます。したがって、ALTOクライアントは、Endpoint Cost情報リソースがコスト指標 "routingcost" と "hopcount" の両方をサポートし、それぞれで "numerical" と "ordinal" の両コストモードを利用できると確認できます。情報リソースを要求する際、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" に委任するとします。このサブドメインで利用できるマップは、フィルター済みネットワークマップ、フィルター済みコストマップ、およびコスト指標 "hopcount" と "routingcost" についてコストモード "ordinal" で事前生成されたマップだとします。直前の例のIRDで "resources" の4番目のエントリーが委任を実現しています。このエントリーのmedia-typeは "application/alto-directory+json" です。ALTOクライアントが "http://custom.alto.example.com/maps" への要求に成功すると、"custom.alto.example.com" で利用可能な情報リソースを発見できます。
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の例では、コストモード "numerical"、コスト指標 "routingcost" の完全なコストマップを、"http://alto.example.com/costmap/num/routingcost" へのGET要求、または "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文字以下でなければならず (MUST)、US-ASCII英数字（U+0030-U+0039、U+0041-U+005A、U+0061-U+007A）、ハイフン（'-'、U+002D）、コロン（':'、U+003A）、アットマーク（'@'、コードポイントU+0040）、アンダースコア（'_'、U+005F）、または区切り文字'.'（U+002E）以外の文字を含んではなりません (MUST NOT)。'.'区切り文字は将来の使用のために予約されており、本書または拡張文書で明示的に許可されない限り、使用してはなりません (MUST NOT)。
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" フィールドは情報リソースディレクトリで定義されたリソース（ネットワークマップなど）のresource 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.
"tag" フィールドを表す文字列は64文字以下でなければなりません (MUST)。また、U+0021より小さい文字またはU+007Eより大きい文字を含んではなりません (MUST NOT)。他のタグとの衝突確率が低くなるよう、"tag" 文字列を選ぶべきです (SHOULD)。推奨される方法の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の値として、IPv4アドレスを表す "ipv4" とIPv6アドレスを表す "ipv6" の2つを定義します。"application/alto-*" メディアタイプを使うHTTP要求または応答に現れるすべてのAddressType識別子は、"ALTO Address Type Registry" に登録しなければなりません (MUST)（セクション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".
コストモードは文字列としてエンコードします。この文字列の値は "numerical" または "ordinal" のいずれかでなければなりません (MUST)。
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文字以下でなければならず (MUST)、US-ASCII英数字（U+0030-U+0039、U+0041-U+005A、U+0061-U+007A）、ハイフン（'-'、U+002D）、コロン（':'、U+003A）、アンダースコア（'_'、U+005F）、または区切り文字'.'（U+002E）以外の文字を含んではなりません (MUST NOT)。'.'区切り文字は将来の使用のために予約されており、関連文書または拡張文書で明示的に許可されない限り、使用してはなりません (MUST NOT)。
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 Cost Metric Registry"（セクション14.2）に登録しなければなりません (MUST)。"priv:" で始まる識別子では、衝突の可能性を減らすために、"priv:" だけではなく、その後に追加の文字列（会社識別子やランダム文字列など）を続けなければなりません (MUST)。
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" フィールドが存在する場合、コスト指標とコストモードを人が読める形で説明する文字列値を含めなければなりません (MUST)。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).
リソース固有のエンドポイントプロパティ名は、次の形式でなければなりません (MUST): resource 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文字以下でなければならず (MUST)、US-ASCII英数字（U+0030-U+0039、U+0041-U+005A、U+0061-U+007A）、ハイフン（'-'、U+002D）、コロン（':'、U+003A）、またはアンダースコア（'_'、U+005F）以外の文字を含んではなりません (MUST NOT)。エンドポイントプロパティがグローバルかリソース固有かを曖昧にしないため、'.'区切り文字は使用できません。
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 Endpoint Property Type Registry"（セクション14.3）に登録しなければなりません (MUST)。"priv:" で始まるエンドポイントプロパティ識別子では、衝突の可能性を減らすため、"priv:" だけではなく、その後に追加の文字列（会社識別子やランダム文字列など）を続けなければなりません (MUST)。
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.
個々の情報リソースへの応答の "meta" フィールドについて、本書では汎用フィールドを2つ定義します。"vtag" フィールドは現在の情報リソースのバージョンタグ（セクション10.3参照）を示します。"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つのネットワークマップを提供しなければなりません (MUST)。
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」フィールドを含めなければなりません (MUST)。
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を含めなければなりません (MUST)。
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を無視しなければなりません (MUST)。その結果、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のLongest Match）を使用しなければなりません (MUST)。
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つの要件を満たしていなければなりません (MUST)。
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を定義しなければなりません (MUST)。これはALTOネットワークマップの完全性特性と呼びます。この特性を満たす方法として、マップで提供されるアドレスをすべて包含する最短プレフィックスにPIDを定義することを推奨します (SHOULD)。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アドレスがPID 1つだけに対応付けられるよう、そのネットワークマップは同一のIPプレフィックスを含むPIDを2つ以上定義してはなりません (MUST NOT)。これは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つのプレフィックスを1つのプレフィックスに統合すると、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」コストメトリックに対して提供しなければなりません (MUST)。
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名を1つだけ含めなければなりません (MUST)。入力パラメーターを受け付けないHTTP GETで、フィルターなしのコストマップ（accept == ""）を要求するためです。これに対して、フィルター済みコストマップ（セクション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」フィールドを含めなければなりません (MUST)。このフィールドの値は、使用されるネットワークマップのバージョンタグを示す単一要素の配列です。ネットワークマップは、「uses」で指定されています。 IRD。 「メタ」には、「コストタイプ」フィールドも含めなければなりません (MUST)。このフィールドの値は、コストマップのコストタイプ（セクション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と想定し、そうでなければ解析に失敗すべきです (SHOULD)。ただし、他のデータ型のコストをいつどのように通知するかを定める本書の拡張を、その実装が使用している場合は除きます。
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）の組について、そのパスコストを含めなければなりません (MUST)。ALTOサーバーは、パスコストが定義されていないエントリーを省略してもよい (MAY) です（たとえば、送信元または宛先の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サーバーによって提供される場合があります (MAY)。
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のリストが含まれているかのように解釈しなければなりません (MUST)。 ALTOサーバーは、複数回出現するエントリを、1回だけ出現するかのように解釈しなければなりません (MUST)。
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サーバーに既知のすべてのアドレスタイプのリストを含んでいるかのように解釈しなければなりません (MUST)。 ALTOサーバーは、複数回出現するエントリを、1回だけ出現するかのように解釈しなければなりません (MUST)。
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だけを応答に含めなければなりません (MUST)。入力パラメーターに現在ALTOサーバーが定義していないPID名が含まれている場合、ALTOサーバーはそのPID名が入力パラメーターに含まれていなかったものとして動作しなければなりません (MUST)。同様に、ALTOサーバーは、要求で暗黙的または明示的に指定された種別のアドレスだけを各PID内に列挙しなければなりません (MUST)。入力パラメーターに現在ALTOサーバーが認識していないアドレス種別が含まれている場合、ALTOサーバーはそのアドレス種別が入力パラメーターに含まれていなかったものとして動作しなければなりません (MUST)。
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」フィールドに含まれるバージョンタグは、フィルタリングされた情報が提供される完全な（フィルタリングされていない）ネットワークマップ情報リソースに対応していなければなりません (MUST)。これにより、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サーバーによって提供される場合があります (MAY)。
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参照）で示されたサポート対象のコスト種別のいずれかと一致しなければなりません (MUST)。ALTOクライアントは "description" フィールドを省略すべきです (SHOULD)。このフィールドが存在する場合、ALTOサーバーは無視しなければなりません (MUST)。
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.
constraints: コストマップのうち、どの要素を返すかを制限する追加条件の一覧です。このリソースの "capabilities" フィールド（セクション11.3.2.4参照）が条件指定をサポートしないと示す場合、このパラメーターを指定してはなりません (MUST NOT)。各条件は空白で区切られた2つの要素から成ります。(1) 演算子（より大きい場合は "gt"、より小さい場合は "lt"、以上の場合は "ge"、以下の場合は "le"、等しい場合は "eq"）と、(2) 対象のコスト値です。コスト値は数値であり、"cost-metric" パラメーターで示すコスト指標と同じ単位で定義しなければなりません (MUST)。ALTOサーバーは、コスト値の格納に少なくともIEEE 754倍精度浮動小数点数[IEEE.754.2008]を使うべきであり (SHOULD)、内部計算にも倍精度浮動小数点演算を使うべきです (SHOULD)。複数の "constraint" パラメーターは、論理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の完全なセットとして解釈しなければなりません (MUST)。 ALTOサーバーは、リストに複数回出現するエントリを、1回だけ出現するかのように解釈しなければなりません (MUST)。 「pids」フィールドが存在しない場合、両方のリストは、現在定義されているPIDの完全なセットを含むものとしてALTOサーバーによって解釈されなければなりません (MUST)。
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が指定されたものとして解釈しなければなりません (MUST)。序数コストは連続する整数に限定されないため、ALTOクライアントは、序数コストモードのコストマップでは制約が意図した効果をもたらさない場合があることに留意してください。
The resource ID of the network map based on which the cost map will be filtered.
コストマップのフィルタリングに使うネットワークマップのresource 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" フィールドは、フィルタリングに使ったネットワークマップのバージョンタグを1つだけ含む配列です。該当する場合、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.
返されるコストマップには、入力パラメーターで（暗黙的または明示的に）示されているソース/宛先のペアのみを含めなければなりません (MUST)。入力パラメーターに、現在ALTOサーバーで定義されていないPID名が含まれている場合、ALTOサーバーは、PIDが入力パラメーターに表示されなかったかのように動作しなければなりません (MUST)。
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サーバーはエンドポイントプロパティを追加で提供してもよい (MAY)。
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: 各エンドポイントについて返すエンドポイントプロパティの一覧です。指定する各プロパティは、このリソースの "capabilities" フィールド（セクション11.4.1.4参照）が示すサポート対象プロパティの一覧に含まれなければなりません (MUST)。ALTOサーバーは、複数回現れるエントリーを1回だけ現れたものとして解釈しなければなりません (MUST)。
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回だけ出現するかのように解釈しなければなりません (MUST)。
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のルックアップを提供しなければなりません (MUST)。
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ネットワークマップのバージョンタグを含む配列でなければなりません (MUST)。
The data component of an endpoint properties response is named "endpoint-properties", which is a JSON object of type EndpointPropertyMapData, where:
エンドポイントプロパティ応答のdataコンポーネントは "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であると想定し、そうでない場合は解析を失敗させるべきです (SHOULD)。ただし、他のデータ型のプロパティ値がいつどのように通知されるかを示すこのドキュメントの拡張機能を実装が使用している場合を除きます。
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サーバーによって提供される場合があります (MAY)。
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: 返されるコストに使うCostType（セクション10.7参照）。"cost-metric" および "cost-mode" フィールドは、このリソースの "capabilities" フィールド（セクション11.5.1.4参照）が示すサポート対象コスト種別のいずれかと一致しなければなりません (MUST)。ALTOクライアントは "description" フィールドを省略すべきです (SHOULD)。このフィールドが存在する場合、ALTOサーバーは無視しなければなりません (MUST)。
constraints: Defined equivalently to the "constraints" input parameter of a filtered cost map (see Section 11.3.2).
constraints: フィルター済みコストマップの "constraints" 入力パラメーターと同じように定義します（セクション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アドレスに対応するエンドポイントアドレスがその一覧に含まれているものとして解釈しなければなりません (MUST)（この動作の説明と考慮事項はセクション13.3参照）。送信元と宛先のエンドポイント一覧を両方とも空にしてはなりません (MUST NOT)。ALTOサーバーは、一覧内で複数回現れるエントリーを1回だけ現れたものとして解釈しなければなりません (MUST)。
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サーバーは個々のエンドポイント間のコストを明らかにできますが、明らかにすることは必須ではありません。ECSの単純な実装では、サーバーが公開するネットワークマップとコストマップのいずれかを使い、2つのエンドポイントに対応するPID間のコストをエンドポイント間のコストとして計算できます。ECSはネットワークマップまたはコストマップを示すために "use" フィールドを指定してはなりません (MUST NOT)。したがって、ECSコストは送信元エンドポイントから宛先エンドポイントへのコストです。将来の拡張でECSがネットワークマップを "uses" と指定できるようにする場合、その意味を定義する必要があります。
The "meta" field of an endpoint cost response MUST include the "cost-type" field, to indicate the cost type used.
エンドポイントコスト応答の "meta" フィールドには、使用したコスト種別を示す "cost-type" フィールドを含めなければなりません (MUST)。
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であると想定し、そうでない場合は解析に失敗すべきです (SHOULD)。ただし、他のデータ型のコストがいつどのように通知されるかを示すこのドキュメントの拡張機能を実装が使用している場合を除きます。 ALTOサーバーがソースエンドポイントから特定の宛先エンドポイントへのコスト値を定義しない場合は、応答から省略できます (MAY)。
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サーバーが提供する "my-Internet view" には、すべての候補ピアに対する選好を含められます。
.---------. (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クライアントは、検出したピアを宛先エンドポイントの集合として指定し、コストモード "ordinal" を指定して、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サービスプロバイダーは、ある種別のエンドポイントアドレスから別の種別のエンドポイントアドレスへのパスの選好を柔軟に示せます。
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.
エンドポイントコストサービスで送信元エンドポイントアドレスを指定する場合など、ALTOクライアントが自身のIPアドレスを調べる必要が生じることがあります。ALTOクライアントが複数のネットワークインターフェイスアドレスを持ち、その一部またはすべてがパブリックインターネットへの接続にNATを必要とする場合もあります。
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のためのSession Traversal Utilities for NAT（STUN）[RFC5389]を使うべきです (SHOULD)。この方法を使う場合、ホストは "Binding Request" メッセージと、応答で返される "XOR-MAPPED-ADDRESS" パラメーターを使わなければなりません (MUST)。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.
本書では、表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
タイプ名: 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.
新しいALTOコスト指標は、適切な文書にコスト指標の意味とセキュリティ上の考慮事項が記載されていることを確認するため、IETF Review [RFC5226] の後に割り当てます。新しい指標を記述するRFCでは、登録されたALTOコスト指標の値をどう解釈するかについて、ALTOサービスプロバイダーとALTOクライアントを利用するアプリケーションの双方に十分な指針を示すことが望ましいです。ALTOコスト指標の更新と削除にも同じ手順を適用します。
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で指定された構文要件に準拠しなければなりません (MUST)。識別子は記録され、文字列として表示されます。
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:
レジストリへの新しい値の追加申請には、次の情報を含めなければなりません (MUST)。
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 クライアントによる利用を導くためのセマンティクスが付随します。たとえば、値が測定値を指す場合、測定単位が文書化されていなければなりません。順序コスト（ordinal cost）モードを（たとえばサードパーティサービスによって）適切に実装するためには、コストの値が高い方と低い方のどちらがより好ましいかが文書化されているべきです。
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
表4: ALTOエンドポイントプロパティ種別
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.
新しいALTOエンドポイントプロパティ種別は、意味とセキュリティ上の考慮事項が適切に文書化されるよう、IETF Review [RFC5226] の後に割り当てます。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.
登録するALTOエンドポイントプロパティ種別の識別子は、セクション10.8.1で規定する構文要件に準拠しなければなりません (MUST)。識別子は文字列として記録し、表示します。
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:
レジストリに新しい値を追加するリクエストには、次の情報を含めなければなりません (MUST)。
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.
新しいALTOアドレスタイプは、そのタイプとセキュリティ上の考慮事項に関する適切な文書が提供されるよう、IETF Review [RFC5226] の後に割り当てます。新しいアドレスタイプを定義する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で指定された構文要件に準拠しなければなりません (MUST)。識別子は記録され、文字列として表示されます。
Requests to add a new value to the registry MUST include the following information:
レジストリに新しい値を追加するリクエストには、次の情報を含めなければなりません (MUST)。
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 エンドポイントプレフィックスの符号化: 登録済みタイプのアドレス集合を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エラーコードを追加する要求には、次の情報を含めなければなりません (MUST)。
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.
ネットワーク環境によっては、攻撃者は、イーサネット上で偽造DHCP応答を送信する、DNSポイズニングを行う、変更を加える透過HTTPプロキシを設置するなど、さまざまな手法でALTO情報リソースの真正性と完全性を攻撃できます。これらの手法に限られるわけではありません。
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は、TLSの真正性確認および完全性保護の仕組みを利用して、ALTO情報（情報リソースディレクトリと個々の情報リソースの両方）の真正性と完全性を保護します（セクション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サービスプロバイダーと、ALTO専用証明書を発行する認証局は、[RFC6125]に定められた推奨事項とガイドラインを考慮すべきです (SHOULD)。
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を開発するソフトウェアエンジニアとALTOを展開するサービスプロバイダーは、更新される可能性のある標準文書や、HTTP over TLSの設定に関する最新のBest Current Practicesに精通しておくことが望ましいです。
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情報を検証できる必要があります。この検証のサポートはこのドキュメントでは提供されていませんが、拡張ドキュメントによって提供される場合があります。
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.
関連するシナリオとして、ALTOサーバーが意図せず「不適切な」指針を与える場合があります。たとえば、多数のALTOクライアントが追加の妥当性確認や適応をせずにコストマップまたはエンドポイントコストサービスの指針に従うと、より好ましいホストやリンクが過負荷になり、好ましくないものが使われずに残る可能性があります。関連するアプリケーション上の考慮事項については、[RFC6708]のAR-14を参照してください。
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.
リスクの種類（2）に対処するためクライアント認証が望まれる展開では、ALTO情報を直接共有する相手の数を制限できるよう、ALTOクライアントの認証にHTTP Digest Authenticationをサポートする必要があります。TLSクライアント認証をサポートすることもできます。ユースケースやシナリオに応じて、ALTOサーバーはサービスへのアクセスを制限するために他のアクセス制御方式を適用する場合があります。アクセス制御は、インターネット上の任意のホストによるサービス拒否攻撃の防止にも役立ちます。この点の詳細な議論については[ALTO-DEPLOYMENT]を参照してください。
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.
ユーザーのプライバシーを保護するため、ALTOクライアントは、HTTP Cookieなどを使ったクライアントクエリ経由のALTOサーバーによる追跡の可能性に留意することが望ましいです。本書で定義するALTOプロトコルはHTTP Cookieに依存しません。追跡を難しくするため、ALTOクライアントはサーバーから受け取ったCookieを返さないことを選択してもよい (MAY) です。ただし、これにより本書の範囲外であるプロトコル拡張が動作しなくなる可能性があります。
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.
他のエンドポイント（ピアなど）のIPアドレスをALTOサーバーに渡さないよう、ALTOクライアントはPID用のALTOネットワークマップとPID間のコストマップだけに依存する方法を検討できます。特定のIPアドレスが必要な場合（エンドポイントコストサービスを使う場合など）、ALTOクライアントは送信するIPアドレスから得られる情報を最小限にすべきです (SHOULD)。たとえば、より広いアドレス範囲（すなわち短いプレフィックス長）を指定する、またはIPアドレスの末尾数ビットをゼロにするか無作為化するなど、難読化の手法を検討できます。難読化により結果の精度が低下する場合があることに注意してください。
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つ目にはプロバイダーのネットワーク内のエンドポイントを格納し、2つ目はIPv4およびIPv6全体への到達可能性を表します（セクション11.2.2参照）。各送信元/宛先PID間のコストは1に設定します。ALTOサービスプロバイダーが考慮する別の運用上の問題は、フィルタリング入力が空の場合、フィルタリングサービスが完全なマップを提供するサービスに退化する可能性があることです。この退化動作は継続性をもたらしますが、多数の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.
ALTOサービスプロバイダーは、ALTOサーバーの正確性と応答性を監視するだけでなく、トラフィックエンジニアリングへの影響や統合の状況をどのように測定するかも検討することが望ましいです。ALTO対応アプリケーションが関連情報をALTOサービスプロバイダーに返さない場合があるため、影響の測定は難しいことがあります。また、ALTOサービスプロバイダーによる測定から、ALTOが情報源の1つにすぎないため、ALTOクライアントがALTOサーバーの指針に従っていないことが分かる場合もあります。
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:
ALTOサーバーとALTOクライアントから得られる望ましい性能情報をすべて列挙することは、本書の範囲外です。既存の展開とプロトコル開発の経験に基づき、監視対象として推奨するALTO固有のメトリックを以下に示します。
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.
[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. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[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., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[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. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, August 2006.
[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. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[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., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[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. 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.
[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, February 2014.
[ALTO-INFOEXPORT] Shalunov, S., Penno, R., and R. Woundy, "ALTO Information Export Service", Work in Progress, October 2008.
[ALTO-INFOEXPORT] Shalunov, S., Penno, R., and R. Woundy, "ALTO Information Export Service", Work in Progress, October 2008.
[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., and L. Dondeti, "ALTO: A Multi Dimensional Peer Selection Problem", Work in Progress, October 2008.
[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. and V. Narayanan, "A Client to Service Query Response Protocol for ALTO", Work in Progress, March 2009.
[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] Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., and H. Song, "ALTO Server Discovery", Work in Progress, September 2013.
[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., and D. McDysan, "ALTO Network-Server and Server-Server APIs", Work in Progress, March 2011.
[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", University of California, Irvine, 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., and Y. Yang, "P4P: Provider Portal for P2P Applications", Work in Progress, November 2008.
[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., and A. Silberschatz, "P4P: Provider Portal for (P2P) Applications", SIGCOMM 2008, August 2008.
[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., and Y. Yang, "P4P Protocol Specification", Work in Progress, March 2009.
[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., and D. Saucez, "The PROXIDOR Service", Work in Progress, March 2009.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic Optimization (ALTO) Problem Statement", RFC 5693, October 2009.
[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic Optimization (ALTO) Problem Statement", RFC 5693, October 2009.
[RFC5706] Harrington, D., "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions", RFC 5706, November 2009.
[RFC5706] Harrington, D., "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions", RFC 5706, November 2009.
[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., and K. Yin, "Framework for IPv4/IPv6 Translation", RFC 6144, April 2011.
[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] Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, March 2014.
[RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, June 2014.
[RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, June 2014.
[SIP] Jennings, C., "Computational Puzzles for SPAM Reduction in SIP", Work in Progress, July 2007.
[SIP] Jennings, C., "Computational Puzzles for SPAM Reduction in SIP", Work in Progress, July 2007.
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),
Obi Akonjang (DT Labs/TU Berlin),
Saumitra M. Das (Qualcomm Inc.),
Saumitra M. Das (Qualcomm Inc.),
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 (Juniper Networks),
Albert Tian (Ericsson/Redback),
Albert Tian (Ericsson/Redback),
Yu-Shun Wang (Microsoft),
Yu-Shun 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), 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).
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 Query/Response [ALTO-QUERYRESPONSE]、[ALTO-MULTI-PS]、および
o Proxidor [PROXIDOR].
o Proxidor [PROXIDOR].
Authors' Addresses
著者のアドレス
Richard Alimi (editor) Google 1600 Amphitheatre Parkway Mountain View, CA 94043 USA
Richard Alimi (editor) 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 (editor) 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. Richard Yang (editor) Yale University 51 Prospect St New Haven, CT 06511 USA
EMail: yry@cs.yale.edu Sebastian Kiesel University of Stuttgart Information Center Networks and Communication Systems Department Allmandring 30 Stuttgart 70550 Germany
EMail: yry@cs.yale.edu Sebastian Kiesel University of Stuttgart Information Center Networks and Communication Systems Department Allmandring 30 Stuttgart 70550 Germany
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