[要約] 要約：RFC 7971は、Application-Layer Traffic Optimization（ALTO）の展開に関する考慮事項を提供するものであり、ALTOプロトコルの実装と展開に関するガイダンスを提供します。目的：このRFCの目的は、ALTOの展開に関連する問題やベストプラクティスを識別し、ALTOプロトコルの効果的な実装と展開を支援することです。
Internet Engineering Task Force (IETF) M. Stiemerling
Request for Comments: 7971 Hochschule Darmstadt
Category: Informational S. Kiesel
ISSN: 2070-1721 University of Stuttgart
M. Scharf
Nokia
H. Seidel
BENOCS
S. Previdi
Cisco
October 2016
Application-Layer Traffic Optimization (ALTO) Deployment Considerations
アプリケーション層トラフィック最適化（ALTO）の展開に関する考慮事項
Abstract
概要
Many Internet applications are used to access resources such as pieces of information or server processes that are available in several equivalent replicas on different hosts. This includes, but is not limited to, peer-to-peer file sharing applications. The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource. This memo discusses deployment-related issues of ALTO. It addresses different use cases of ALTO such as peer-to-peer file sharing and Content Delivery Networks (CDNs) and presents corresponding examples. The document also includes recommendations for network administrators and application designers planning to deploy ALTO, such as recommendations on how to generate ALTO map information.
多くのインターネットアプリケーションは、さまざまなホスト上のいくつかの同等のレプリカで利用可能な情報やサーバープロセスなどのリソースにアクセスするために使用されます。これには、ピアツーピアのファイル共有アプリケーションが含まれますが、これに限定されません。アプリケーション層トラフィック最適化（ALTO）の目標は、目的のリソースを提供できる候補のセットから1つまたは複数のホストを選択する必要があるアプリケーションにガイダンスを提供することです。このメモでは、ALTOの展開関連の問題について説明します。ピアツーピアのファイル共有やコンテンツ配信ネットワーク（CDN）などのALTOのさまざまな使用例に対応し、対応する例を示します。このドキュメントには、ALTOマップ情報の生成方法に関する推奨事項など、ALTOの展開を計画しているネットワーク管理者およびアプリケーション設計者向けの推奨事項も含まれています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7971.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7971で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
2. General Considerations ..........................................4
2.1. ALTO Entities ..............................................4
2.1.1. Baseline Scenario ...................................4
2.1.2. Placement of ALTO Entities ..........................6
2.2. Classification of Deployment Scenarios .....................8
2.2.1. Roles in ALTO Deployments ...........................8
2.2.2. Information Exposure ...............................11
2.2.3. More-Advanced Deployments ..........................12
3. Deployment Considerations by ISPs ..............................15
3.1. Objectives for the Guidance to Applications ...............15
3.1.1. General Objectives for Traffic Optimization ........15
3.1.2. Inter-Network Traffic Localization .................16
3.1.3. Intra-Network Traffic Localization .................17
3.1.4. Network Offloading .................................18
3.1.5. Application Tuning .................................19
3.2. Provisioning of ALTO Topology Data ........................20
3.2.1. High-Level Process and Requirements ................20
3.2.2. Data Collection from Data Sources ..................21
3.2.3. Partitioning and Grouping of IP Address Ranges .....24
3.2.4. Rating Criteria and/or Cost Calculation ............25
3.3. ALTO Focus and Scope ......................................29
3.3.1. Limitations of Using ALTO beyond Design
Assumptions ........................................29
3.3.2. Limitations of Map-Based Services and
Potential Solutions ................................30
3.3.3. Limitations of Non-Map-Based Services and
Potential Solutions ................................32
3.4. Monitoring ALTO ...........................................33
3.4.1. Impact and Observation on Network Operation ........33
3.4.2. Measurement of the Impact ..........................33
3.4.3. System and Service Performance .....................34
3.4.4. Monitoring Infrastructures .........................35
3.5. Abstract Map Examples for Different Types of ISPs .........36
3.5.1. Small ISP with Single Internet Uplink ..............36
3.5.2. ISP with Several Fixed-Access Networks .............39
3.5.3. ISP with Fixed and Mobile Network ..................40
3.6. Comprehensive Example for Map Calculation .................42
3.6.1. Example Network ....................................42
3.6.2. Potential Input Data Processing and Storage ........44
3.6.3. Calculation of Network Map from the Input Data .....47
3.6.4. Calculation of Cost Map ............................49
3.7. Deployment Experiences ....................................50
4. Using ALTO for P2P Traffic Optimization ........................52
4.1. Overview ..................................................52
4.1.1. Usage Scenario .....................................52
4.1.2. Applicability of ALTO ..............................53
4.2. Deployment Recommendations ................................55
4.2.1. ALTO Services ......................................55
4.2.2. Guidance Considerations ............................56
5. Using ALTO for CDNs ............................................58
5.1. Overview ..................................................58
5.1.1. Usage Scenario .....................................58
5.1.2. Applicability of ALTO ..............................60
5.2. Deployment Recommendations ................................62
5.2.1. ALTO Services ......................................62
5.2.2. Guidance Considerations ............................63
6. Other Use Cases ................................................64
6.1. Application Guidance in Virtual Private Networks (VPNs) ...64
6.2. In-Network Caching ........................................66
6.3. Other Application-Based Network Operations ................68
7. Security Considerations ........................................68
7.1. ALTO as a Protocol Crossing Trust Boundaries ..............68
7.2. Information Leakage from the ALTO Server ..................69
7.3. ALTO Server Access ........................................70
7.4. Faking ALTO Guidance ......................................71
8. References .....................................................72
8.1. Normative References ......................................72
8.2. Informative References ....................................73
Acknowledgments ...................................................76
Authors' Addresses ................................................77
Many Internet applications are used to access resources such as pieces of information or server processes that are available in several equivalent replicas on different hosts. This includes, but is not limited to, peer-to-peer (P2P) file sharing applications and Content Delivery Networks (CDNs). The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource. The basic ideas and problem space of ALTO is described in [RFC5693] and the set of requirements is discussed in [RFC6708]. The ALTO protocol is specified in [RFC7285]. An ALTO server discovery procedure is defined in [RFC7286].
多くのインターネットアプリケーションは、さまざまなホスト上のいくつかの同等のレプリカで利用可能な情報やサーバープロセスなどのリソースにアクセスするために使用されます。これには、ピアツーピア（P2P）ファイル共有アプリケーションとコンテンツ配信ネットワーク（CDN）が含まれますが、これらに限定されません。アプリケーション層トラフィック最適化（ALTO）の目標は、目的のリソースを提供できる候補のセットから1つまたは複数のホストを選択する必要があるアプリケーションにガイダンスを提供することです。 ALTOの基本的な考え方と問題空間は[RFC5693]で説明されており、一連の要件は[RFC6708]で説明されています。 ALTOプロトコルは[RFC7285]で指定されています。 ALTOサーバー発見手順は[RFC7286]で定義されています。
This document discusses use cases and operational issues that can be expected when ALTO gets deployed. This includes, but is not limited to, location of the ALTO server, imposed load to the ALTO server, and who initiates the queries. This document provides guidance on which ALTO services to use, and it summarizes known challenges as well as deployment experiences, including potential processes to generate ALTO network and cost maps. It thereby complements the management considerations in the protocol specification [RFC7285], which are independent of any specific use of ALTO.
このドキュメントでは、ALTOの導入時に予想される使用例と運用上の問題について説明します。これには、ALTOサーバーの場所、ALTOサーバーへの負荷、およびクエリの開始者が含まれますが、これらに限定されません。このドキュメントでは、使用するALTOサービスに関するガイダンスを提供し、既知の課題と、ALTOネットワークおよびコストマップを生成するための潜在的なプロセスを含む展開エクスペリエンスを要約します。これにより、プロトコル仕様[RFC7285]の管理上の考慮事項を補完します。これは、ALTOの特定の使用から独立しています。
The ALTO protocol [RFC7285] is a client/server protocol, operating between a number of ALTO clients and an ALTO server, as sketched in Figure 1. Below, the baseline deployment scenario for ALTO entities is first reviewed independently of the actual use case. Specific examples are then discussed in the remainder of this document.
ALTOプロトコル[RFC7285]は、図1に示すように、多数のALTOクライアントとALTOサーバー間で動作するクライアント/サーバープロトコルです。以下では、ALTOエンティティのベースラインデプロイメントシナリオを、実際のユースケースとは関係なく最初にレビューします。次に、このドキュメントの残りの部分で特定の例について説明します。
+----------+
| ALTO |
| Server |
+----------+
^
_.-----|------.
,-'' | `--.
,' | `.
( Network | )
`. | ,'
`--. | _.-'
`------|-----''
v
+----------+ +----------+ +----------+
| ALTO | | ALTO |...| ALTO |
| Client | | Client | | Client |
+----------+ +----------+ +----------+
Figure 1: Baseline Deployment Scenario of the ALTO Protocol
図1：ALTOプロトコルのベースライン展開シナリオ
This document uses the terminology introduced in [RFC5693]. In particular, the following terms are defined by [RFC5693]:
このドキュメントでは、[RFC5693]で導入された用語を使用しています。特に、次の用語は[RFC5693]によって定義されています。
o ALTO Service: Several resource providers may be able to provide the same resource. The ALTO service gives guidance to a resource consumer and/or resource directory about which resource provider(s) to select in order to optimize the client's performance or quality of experience, while improving resource consumption in the underlying network infrastructure.
o ALTOサービス：複数のリソースプロバイダーが同じリソースを提供できる場合があります。 ALTOサービスは、クライアントのパフォーマンスまたはエクスペリエンスの品質を最適化する一方で、基盤となるネットワークインフラストラクチャでのリソース消費を改善するために選択するリソースプロバイダーについて、リソースコンシューマーやリソースディレクトリにガイダンスを提供します。
o ALTO Server: A logical entity that provides interfaces to satisfy the queries about a particular ALTO service.
o ALTOサーバー：特定のALTOサービスに関するクエリを満たすためのインターフェースを提供する論理エンティティ。
o ALTO Client: The logical entity that sends ALTO queries. Depending on the architecture of the application, one may embed it in the resource consumer and/or in the resource directory.
o ALTOクライアント：ALTOクエリを送信する論理エンティティ。アプリケーションのアーキテクチャに応じて、リソースコンシューマやリソースディレクトリに埋め込むことができます。
o Resource Consumer: For P2P applications, a resource consumer is a specific peer that needs to access resources. For client-server or hybrid applications, a consumer is a client that needs to access resources.
o リソースコンシューマ：P2Pアプリケーションの場合、リソースコンシューマは、リソースにアクセスする必要がある特定のピアです。クライアント/サーバーまたはハイブリッドアプリケーションの場合、コンシューマーはリソースにアクセスする必要があるクライアントです。
o Resource Directory: An entity that is logically separate from the resource consumer and that assists the resource consumer to identify a set of resource providers. Some P2P applications refer to the resource directory as a P2P tracker.
o リソースディレクトリ：リソースコンシューマから論理的に分離され、リソースコンシューマがリソースプロバイダのセットを識別するのを支援するエンティティ。一部のP2Pアプリケーションは、リソースディレクトリをP2Pトラッカーと呼びます。
We differentiate between an ALTO Client and a Resource Consumer as follows: the resource consumer is specific instance of a software ("process") running on a specific host. It is a client instance of a client/server application or a peer of a peer-to-peer application. It is the given (constant) endpoint of the data transmissions to be optimized using ALTO. The optimization is done by wisely choosing the other ends of these data flows (i.e., the server(s) in a client/ server application or the peers in a peer-to-peer application), using guidance from ALTO and possibly other information. An ALTO client is a piece of software (e.g., a software library) that implements the client entity of the ALTO protocol as specified in [RFC7285]. It consists of data structures that are suitable for representing ALTO queries, replies, network and cost maps, etc. Furthermore, it has to implement an HTTP client and a JSON encoder/decoder, or it has to include other software libraries that provide these building blocks. In the simplest case, this ALTO client library can be linked (or otherwise incorporated) into the resource consumer, in order to retrieve information from an ALTO server and thereby satisfy the resource consumer's need for guidance. However, other configurations are possible as well, as discussed in Section 2.1.2 and other sections of this document.
ALTOクライアントとリソースコンシューマは、次のように区別されます。リソースコンシューマは、特定のホストで実行されるソフトウェア（「プロセス」）の特定のインスタンスです。これは、クライアント/サーバーアプリケーションのクライアントインスタンス、またはピアツーピアアプリケーションのピアです。これは、ALTOを使用して最適化されるデータ伝送の所定の（定数）エンドポイントです。最適化は、ALTOおよびその他の情報からのガイダンスを使用して、これらのデータフローのもう一方の端（つまり、クライアント/サーバーアプリケーションのサーバーまたはピアツーピアアプリケーションのピア）を賢く選択することによって行われます。 ALTOクライアントは、[RFC7285]で指定されているALTOプロトコルのクライアントエンティティを実装するソフトウェア（ソフトウェアライブラリなど）です。これは、ALTOクエリ、応答、ネットワークおよびコストマップなどを表すのに適したデータ構造で構成されています。さらに、HTTPクライアントとJSONエンコーダー/デコーダーを実装するか、これらの構築を提供する他のソフトウェアライブラリを含める必要があります。ブロック。最も単純なケースでは、このALTOクライアントライブラリをリソースコンシューマーにリンク（または組み込み）して、ALTOサーバーから情報を取得し、リソースコンシューマーのガイダンスのニーズを満たすことができます。ただし、セクション2.1.2およびこのドキュメントの他のセクションで説明するように、他の構成も可能です。
According to these definitions, both an ALTO server and an ALTO client are logical entities. A particular ALTO service may be offered by more than one ALTO server. In ALTO deployments, the functionality of an ALTO server can therefore be realized by several server instances, e.g., by using load balancing between different physical servers. The term ALTO server should not be confused with use of a single physical server.
これらの定義によれば、ALTOサーバーとALTOクライアントはどちらも論理エンティティです。特定のALTOサービスは、複数のALTOサーバーによって提供される場合があります。したがって、ALTO展開では、ALTOサーバーの機能は、たとえば、異なる物理サーバー間の負荷分散を使用することによって、いくつかのサーバーインスタンスによって実現できます。 ALTOサーバーという用語は、単一の物理サーバーの使用と混同しないでください。
This document uses the term "Resource Directory" as defined in [RFC5693]. This term and its meaning is not to be confused with the "Information Resource Directory (IRD)" defined as a part of the ALTO protocol [RFC7285], i.e., a list of available information resources offered by a specific ALTO service and the URIs at which each can be accessed.
このドキュメントでは、[RFC5693]で定義されている「リソースディレクトリ」という用語を使用します。この用語とその意味は、ALTOプロトコル[RFC7285]の一部として定義されている「情報リソースディレクトリ（IRD）」、つまり特定のALTOサービスによって提供される利用可能な情報リソースのリストとのURIと混同しないでください。それぞれにアクセスできます。
The ALTO server and ALTO clients may be situated at various places in a network topology. An important differentiation is whether the ALTO client is located on the host that is the endpoint of the data transmissions to be optimized with ALTO (see Figure 2) or whether the ALTO client is located on a resource directory, which assists peers or clients in finding other peers or servers, respectively, but does not directly take part in the data transmission (see Figure 3).
ALTOサーバーとALTOクライアントは、ネットワークトポロジのさまざまな場所に配置できます。重要な違いは、ALTOで最適化されるデータ転送のエンドポイントであるホストにALTOクライアントが配置されているか（図2を参照）、ALTOクライアントがピアやクライアントの検索を支援するリソースディレクトリに配置されているかどうかです。それぞれ他のピアまたはサーバーですが、データ送信には直接関与しません（図3を参照）。
+--------------+
| App |
+-----------+ |
===>|ALTO Client| |****
=== +-----------+--+ *
=== * *
=== * *
+-------+ +-------+<=== +--------------+ *
| | | | | App | *
| |.....| |<======== +-----------+ | *
| | | | ========>|ALTO Client| | *
+-------+ +-------+<=== +-----------+--+ *
Source of ALTO == * *
topological Server == * *
information == +--------------+ *
== | App | *
== +-----------+ |****
==>|ALTO Client| |
+-----------+--+
Application
Legend:
=== ALTO protocol
*** Application protocol
... Provisioning protocol
Figure 2: Overview of Protocol Interaction between ALTO Elements without a Resource Directory
図2：リソースディレクトリなしのALTO要素間のプロトコル相互作用の概要
Figure 2 shows the operational model for an ALTO client running at endpoints. An example would be a peer-to-peer file sharing application that does not use a tracker, such as edonkey. In addition, ALTO clients at peers could also be used in a similar way even if there is a tracker, as further discussed in Section 4.1.2.
図2は、エンドポイントで実行されているALTOクライアントの運用モデルを示しています。例としては、edonkeyなどのトラッカーを使用しないピアツーピアのファイル共有アプリケーションがあります。さらに、4.1.2節でさらに説明するように、トラッカーが存在する場合でも、ピアのALTOクライアントを同様の方法で使用できます。
+-----+
**| App |****
** +-----+ *
** * *
** * *
+-------+ +-------+ +--------------+ * *
| | | | | | +-----+ *
| |.....| | +-----------+ |*****| App | *
| | | |<===>|ALTO Client| | +-----+ *
+-------+ +-------+ +-----------+--+ * *
Source of ALTO Resource ** * *
topological Server directory ** * *
information ** +-----+ *
**| App |****
+-----+
Application
Legend:
=== ALTO protocol
*** Application protocol
... Provisioning protocol
Figure 3: Overview of Protocol Interaction between ALTO Elements with a Resource Directory
図3：リソースディレクトリを持つALTO要素間のプロトコルの相互作用の概要
In Figure 3, a use case with a resource directory is illustrated, e.g., a tracker in a peer-to-peer file-sharing application such as BitTorrent. Both deployment scenarios may differ in the number of ALTO clients that access an ALTO service. If an ALTO client is implemented in a resource directory, an ALTO server may be accessed by a limited and less dynamic set of clients, whereas in the general case any host could be an ALTO client. This use case is further detailed in Section 4.
図3では、リソースディレクトリの使用例が示されています（例：BitTorrentなどのピアツーピアファイル共有アプリケーションのトラッカー）。両方の展開シナリオでは、ALTOサービスにアクセスするALTOクライアントの数が異なる場合があります。 ALTOクライアントがリソースディレクトリに実装されている場合、ALTOサーバーは限られた動的でないクライアントのセットからアクセスできますが、一般的なケースでは、どのホストもALTOクライアントになる可能性があります。この使用例については、セクション4で詳しく説明します。
Using ALTO in CDNs may be similar to a resource directory [CDN-USE]. The ALTO server can also be queried by CDN entities to get guidance about where a particular client accessing data in the CDN is located in the Internet Service Provider's network, as discussed in Section 5.
CDNでのALTOの使用は、リソースディレクトリ[CDN-USE]に似ている場合があります。セクション5で説明するように、CDNエンティティがALTOサーバーにクエリを実行して、CDNのデータにアクセスする特定のクライアントがインターネットサービスプロバイダーのネットワークのどこにあるかについてのガイダンスを取得することもできます。
ALTO is a general-purpose protocol and it is intended to be used by a wide range of applications. In different use cases, applications, resource directories, etc., can correspond to different functionality. The use cases listed in this document are not meant to be comprehensive. This also implies that there are different possibilities where the ALTO entities are actually located, i.e., if the ALTO clients and the ALTO server are in the same Internet Service Provider (ISP) domain, or if the clients and the ALTO server are managed/owned/located in different domains.
ALTOは汎用プロトコルであり、幅広いアプリケーションでの使用を目的としています。さまざまなユースケースで、アプリケーション、リソースディレクトリなどがさまざまな機能に対応できます。このドキュメントに記載されている使用例は、包括的なものではありません。これは、ALTOエンティティが実際に配置されている場所が異なる可能性があること、つまり、ALTOクライアントとALTOサーバーが同じインターネットサービスプロバイダー（ISP）ドメインにある場合、またはクライアントとALTOサーバーが管理/所有されている場合も意味します。 /別のドメインにあります。
An ALTO deployment involves four kinds of entities:
ALTOの展開には、4種類のエンティティが含まれます。
1. Source of topological information
1. トポロジー情報のソース
2. ALTO server
2. ALTOサーバー
3. ALTO client
3. HIGHクライアント
4. Resource consumer
4. リソース消費者
Each of these entities corresponds to a certain role, which results in requirements and constraints on the interaction between the entities.
これらの各エンティティは特定の役割に対応しており、エンティティ間の相互作用に対する要件と制約が生じます。
A key design objective of the ALTO service is that each of these four roles can be separated, i.e., they can be realized by different organizations or disjoint system components. ALTO is inherently designed for use in multi-domain environments. Most importantly, ALTO is designed to enable deployments in which the ALTO server and the ALTO client are not located within the same administrative domain.
ALTOサービスの主要な設計目標は、これらの4つの役割のそれぞれを分離できることです。つまり、これらの役割は、異なる組織または独立したシステムコンポーネントによって実現できます。 ALTOは本質的にマルチドメイン環境で使用するように設計されています。最も重要なことに、ALTOは、ALTOサーバーとALTOクライアントが同じ管理ドメイン内に配置されていない展開を可能にするように設計されています。
As explained in [RFC5693], from this follows that at least three different kinds of entities can operate an ALTO server:
[RFC5693]で説明されているように、これにより、少なくとも3種類のエンティティがALTOサーバーを操作できます。
1. Network operators. Network Service Providers (NSPs) such as ISPs may have detailed knowledge of their network topology and policies. In this case, the source of the topology information and the provider of the ALTO server may be part of the same organization.
1. ネットワークオペレーター。 ISPなどのネットワークサービスプロバイダー（NSP）は、ネットワークトポロジとポリシーに関する詳細な知識を持っている場合があります。この場合、トポロジ情報のソースとALTOサーバーのプロバイダーが同じ組織の一部である可能性があります。
2. Third parties. Topology information could also be collected by companies or organizations that are distinct from the network operators, yet have arranged certain legal agreements with one or more network operators, regarding access to their topology information and/or doing measurements in their networks. Examples of such entities could be CDN operators or companies specialized in offering ALTO services on behalf of ISPs.
2. 第三者。トポロジー情報は、ネットワークオペレーターとは別の企業または組織が収集することもできますが、トポロジー情報へのアクセスおよび/またはネットワークでの測定の実行に関して、1つ以上のネットワークオペレーターとの法的契約を結んでいます。そのようなエンティティの例としては、ISPに代わってALTOサービスを提供することに特化したCDNオペレーターや企業があります。
3. User communities. User communities could run distributed measurements for estimating the topology of the Internet. In this case, the topology information may not originate from ISP data.
3. ユーザーコミュニティ。ユーザーコミュニティは、インターネットのトポロジを推定するために分散測定を実行できます。この場合、トポロジー情報はISPデータからのものではない可能性があります。
Regarding the interaction between ALTO server and client, ALTO deployments can be differentiated according to the following aspects:
ALTOサーバーとクライアント間の相互作用に関して、ALTOの展開は次の側面に従って区別できます。
1. Applicable trust model: The deployment of ALTO can differ depending on whether or not the ALTO client and ALTO server are operated within the same organization and/or network. This affects a number of constraints because the trust model is very different. For instance, as discussed later in this memo, the level of detail of maps can depend on who the involved parties actually are.
1. 該当する信頼モデル：ALTOの配備は、ALTOクライアントとALTOサーバーが同じ組織やネットワーク内で運用されているかどうかによって異なります。信頼モデルは非常に異なるため、これは多くの制約に影響します。たとえば、このメモの後半で説明するように、マップの詳細レベルは、関係者が実際に誰であるかによって異なります。
2. Composition of the user group: The main use case of ALTO is to provide guidance to any Internet application. However, an operator of an ALTO server could also decide to offer guidance only to a set of well-known ALTO clients, e.g., after authentication and authorization. In the peer-to-peer application use case, this could imply that only selected trackers are allowed to access the ALTO server. The security implications of using ALTO in closed groups differ from the public Internet.
2. ユーザーグループの構成：ALTOの主な使用例は、インターネットアプリケーションへのガイダンスを提供することです。ただし、ALTOサーバーのオペレーターは、たとえば認証と承認の後で、一連の既知のALTOクライアントにのみガイダンスを提供することもできます。ピアツーピアアプリケーションの使用例では、これは選択されたトラッカーのみがALTOサーバーへのアクセスを許可されることを意味します。 ALTOをクローズドグループで使用することによるセキュリティへの影響は、パブリックインターネットとは異なります。
3. Covered destinations: In general, an ALTO server has to be able to provide guidance for all potential destinations. Yet, in practice, a given ALTO client may only be interested in a subset of destinations, e.g., only in the network cost between a limited set of resource providers. For instance, CDN optimization may not need the full ALTO cost maps because traffic between individual residential users is not in scope. This may imply that an ALTO server only has to provide the costs that matter for a given user, e.g., by customized maps.
3. 対象となる宛先：一般に、ALTOサーバーはすべての潜在的な宛先のガイダンスを提供できなければなりません。しかし、実際には、特定のALTOクライアントは宛先のサブセットにのみ関心がある場合があります。たとえば、リソースプロバイダーの限られたセット間のネットワークコストにのみ関心があります。たとえば、個々の住宅ユーザー間のトラフィックは範囲外であるため、CDN最適化では完全なALTOコストマップが必要ない場合があります。これは、ALTOサーバーが、たとえばカスタマイズされたマップなど、特定のユーザーにとって重要なコストのみを提供する必要があることを意味する場合があります。
The following sections enumerate different classes of use cases for ALTO, and they discuss deployment implications of each of them. In principle, an ALTO server can be operated by any organization, and there is no requirement that an ALTO server be deployed and operated by an ISP. Yet, since the ALTO solution is designed for ISPs, most examples in this document assume that the operator of an ALTO server is a network operator (e.g., an ISP or the network department in a large enterprise) that offers ALTO guidance in particular to users of this network.
以下のセクションでは、ALTOのユースケースのさまざまなクラスを列挙し、それぞれのデプロイメントの影響について説明します。原則として、ALTOサーバーはどの組織でも運用でき、ISPがALTOサーバーを展開して運用する必要はありません。ただし、ALTOソリューションはISP用に設計されているため、このドキュメントのほとんどの例では、ALTOサーバーのオペレーターは、特にユーザーにALTOガイダンスを提供するネットワークオペレーター（ISPまたは大企業のネットワーク部門など）であると想定しています。このネットワークの。
It must be emphasized that any application using ALTO must also work if no ALTO servers can be found or if no responses to ALTO queries are received, e.g., due to connectivity problems or overload situations (see also [RFC6708]).
ALTOサーバーが見つからない場合や、接続の問題や過負荷の状況などが原因でALTOクエリへの応答が受信されない場合も、ALTOを使用するアプリケーションはすべて動作する必要があることを強調する必要があります（[RFC6708]も参照）。
There are basically two different approaches to how an ALTO server can provide network information and guidance:
ALTOサーバーがネットワーク情報とガイダンスを提供する方法には、基本的に2つの異なるアプローチがあります。
1. The ALTO server provides maps that contain provider-defined cost values between network location groupings (e.g., sets of IP prefixes). These maps can be retrieved by clients via the ALTO protocol, and the actual processing of the map data is done inside the client. Since the maps contain (aggregated) cost information for all endpoints, the client does not have to reveal any internal operational data, such as the IP addresses of candidate resource providers. The ALTO protocol supports this mode of operation by the Network and Cost Map Service.
1. ALTOサーバーは、ネットワークロケーショングループ間のプロバイダー定義のコスト値（IPプレフィックスのセットなど）を含むマップを提供します。これらのマップは、ALTOプロトコルを介してクライアントが取得でき、マップデータの実際の処理はクライアント内で行われます。マップにはすべてのエンドポイントの（集約された）コスト情報が含まれているため、クライアントは候補リソースプロバイダーのIPアドレスなどの内部の運用データを公開する必要はありません。 ALTOプロトコルは、ネットワークおよびコストマップサービスによるこの動作モードをサポートしています。
2. The ALTO server provides a query interface that returns costs or rankings for explicitly specified endpoints. This means that the query of the ALTO client has to include additional information (e.g., a list of IP addresses). The server then calculates and returns costs or rankings for the endpoints specified in the request (e.g., a sorted list of the IP addresses). In ALTO, this approach can be realized by the Endpoint Cost Service (ECS) and other related services.
2. ALTOサーバーは、明示的に指定されたエンドポイントのコストまたはランキングを返すクエリインターフェイスを提供します。つまり、ALTOクライアントのクエリには追加情報（IPアドレスのリストなど）を含める必要があります。次に、サーバーはリクエストで指定されたエンドポイントのコストまたはランキング（IPアドレスの並べ替えられたリストなど）を計算して返します。 ALTOでは、このアプローチはEndpoint Cost Service（ECS）およびその他の関連サービスによって実現できます。
Both approaches have different privacy implications for the server and client:
どちらの方法でも、サーバーとクライアントのプライバシーは異なります。
For the client, approach 1 has the advantage that all operational information stays within the client and is not revealed to the provider of the server. However, this service implies that a network operator providing an ALTO server has to expose a certain amount of information about its network structure (e.g., IP prefixes or topology information in general).
クライアントの場合、アプローチ1には、すべての運用情報がクライアント内にとどまり、サーバーのプロバイダーに公開されないという利点があります。ただし、このサービスは、ALTOサーバーを提供するネットワークオペレーターが、ネットワーク構造に関する一定量の情報（IPプレフィックスやトポロジー情報など）を公開する必要があることを意味します。
For the operator of a server, approach 2 has the advantage that the query responses reveal less topology information to ALTO clients. However, it should be noted that collaborating ALTO clients could gather more information than expected by aggregating and correlating responses to multiple queries sent to the ALTO server (see Section 5.2.1, item (3) of [RFC6708]). Furthermore, this method requires that clients send internal operational information to the server, such as the IP addresses of hosts also running the application. For clients, such data can be sensitive.
サーバーのオペレーターにとって、アプローチ2の利点は、クエリ応答がトポロジ情報をALTOクライアントに明らかにしないことです。ただし、連携するALTOクライアントは、ALTOサーバーに送信される複数のクエリへの応答を集約および相関させることにより、予想よりも多くの情報を収集する可能性があることに注意してください（[RFC6708]のセクション5.2.1、アイテム（3）を参照）。さらに、この方法では、クライアントがアプリケーションを実行しているホストのIPアドレスなどの内部の運用情報をサーバーに送信する必要があります。クライアントにとって、そのようなデータは機密である可能性があります。
As a result, both approaches have their pros and cons, as further detailed in Section 3.3.
その結果、セクション3.3でさらに詳しく説明するように、どちらのアプローチにも長所と短所があります。
From an ALTO client's perspective, there are different ways to use ALTO:
ALTOクライアントの観点から見ると、ALTOを使用する方法はいくつかあります。
1. Single-service instance with single-metric guidance: An ALTO client only obtains guidance regarding a single metric (e.g., "routingcost") from a single ALTO service, e.g., an ALTO server that is offered by the network service provider of the corresponding access network. Corresponding ALTO server instances can be discovered, e.g., by ALTO server discovery [RFC7286] [XDOM-DISC]. Since the ALTO protocol is an HTTP-based, REST-ful (Representational State Transfer) protocol, the operator of an ALTO may use well-known techniques for serving large web sites, such as load balancers, in order to serve a large number of ALTO queries. The ALTO protocol also supports the use of different URIs for different ALTO features and thereby the distribution of the service onto several servers.
1. 単一メトリックのガイダンスを持つ単一サービスインスタンス：ALTOクライアントは、対応するアクセスのネットワークサービスプロバイダーによって提供される単一のALTOサービス（ALTOサーバーなど）から単一メトリック（たとえば、「ルーティングコスト」）に関するガイダンスのみを取得します。通信網。対応するALTOサーバーインスタンスは、たとえば、ALTOサーバー検出[RFC7286] [XDOM-DISC]によって検出できます。 ALTOプロトコルはHTTPベースのRESTフル（Representational State Transfer）プロトコルであるため、ALTOのオペレーターは、ロードバランサーなどの大規模なWebサイトにサービスを提供するためのよく知られた手法を使用して、 ALTOクエリ。 ALTOプロトコルは、さまざまなALTO機能に対するさまざまなURIの使用もサポートしているため、複数のサーバーへのサービスの配布もサポートしています。
2. Single service instance with multiple metric guidance: An ALTO client could also query an ALTO service for different kinds of information, e.g., cost maps with different metrics. The ALTO protocol is extensible and permits such operation. However, ALTO does not define how a client shall deal with different forms of guidance, and it is up to the client to interpret the received information accordingly.
2. 複数のメトリックガイダンスを持つ単一のサービスインスタンス：ALTOクライアントは、ALTOサービスにさまざまな種類の情報（たとえば、異なるメトリックのコストマップ）を照会することもできます。 ALTOプロトコルは拡張可能であり、そのような操作を許可します。ただし、ALTOはクライアントがさまざまな形式のガイダンスをどのように処理するかを定義しておらず、受信した情報をそれに応じて解釈するのはクライアントの責任です。
3. Multiple service instances: An ALTO client can also decide to access multiple ALTO servers providing guidance, possibly from different operators or organizations. Each of these services may only offer partial guidance, e.g., for a certain network partition. In that case, it may be difficult for an ALTO client to compare the guidance from different services. Different organization may use different methods to determine maps, and they may also have different (possibly even contradicting or competing) guidance objectives. How to discover multiple ALTO servers and how to deal with conflicting guidance is an open issue.
3. 複数のサービスインスタンス：ALTOクライアントは、おそらく異なる事業者や組織からのガイダンスを提供する複数のALTOサーバーにアクセスすることも決定できます。これらの各サービスは、たとえば特定のネットワークパーティションに対して、部分的なガイダンスしか提供しない場合があります。その場合、ALTOクライアントが異なるサービスからのガイダンスを比較することは難しいかもしれません。組織が異なれば、マップを決定するために異なる方法を使用する場合があり、また、異なる（場合によっては矛盾または競合する）ガイダンスの目的を持つ場合もあります。複数のALTOサーバーを検出する方法と、矛盾するガイダンスに対処する方法は、未解決の問題です。
There are also different options regarding the synchronization of guidance offered by an ALTO service:
ALTOサービスによって提供されるガイダンスの同期に関するさまざまなオプションもあります。
1. Authoritative servers: An ALTO server instance can provide guidance for all destinations for all kinds of ALTO clients.
1. 権限のあるサーバー：ALTOサーバーインスタンスは、あらゆる種類のALTOクライアントのすべての宛先にガイダンスを提供できます。
2. Cascaded servers: An ALTO server may itself include an ALTO client and query other ALTO servers, e.g., for certain destinations. This results is a cascaded deployment of ALTO servers, as further explained below.
2. カスケードサーバー：ALTOサーバー自体にALTOクライアントが含まれ、特定の宛先などの他のALTOサーバーにクエリを実行できます。この結果は、以下でさらに説明するように、ALTOサーバーのカスケード配置になります。
3. Inter-server synchronization: Different ALTO servers may communicate by other means. This approach is not further discussed in this document.
3. サーバー間同期：異なるALTOサーバーが他の方法で通信する場合があります。このアプローチについては、このドキュメントではこれ以上説明しません。
An assumption of the ALTO design is that ISPs operate ALTO servers independently, irrespective of other ISPs. This may be true for most envisioned deployments of ALTO, but there may be certain deployments that may have different settings. Figure 4 shows such a setting with a university network that is connected to two upstream providers. NREN is a National Research and Education Network, which provides cheap high-speed connectivity to specific destinations, e.g., other universities. ISP is a commercial upstream provider from which the university buys connectivity to all destinations that cannot be reached via the NREN. The university, as well as ISP, are operating their own ALTO server. The ALTO clients, located on the peers in the university network will contact the ALTO server located at the university.
ALTO設計の前提は、他のISPに関係なく、ISPがALTOサーバーを独立して動作させることです。これは、ALTOの想定されるほとんどの展開に当てはまる可能性がありますが、設定が異なる特定の展開がある場合があります。図4は、2つの上流プロバイダーに接続された大学ネットワークでのこのような設定を示しています。 NRENはNational Research and Education Networkで、特定の目的地（他の大学など）への安価な高速接続を提供します。 ISPは、大学がNRENを介して到達できないすべての宛先への接続を購入する商用上流プロバイダーです。大学とISPは、独自のALTOサーバーを運用しています。大学のネットワークのピアにあるALTOクライアントは、大学にあるALTOサーバーに接続します。
+-----------+
| ISP |
| ALTO |<==========================++
| Server | ||
+-----------+ ||
,-------. ,------. ||
,-' `-. ,-' `-. ||
/ Commercial \ / \ ||
( Upstream ) ( NREN ) ||
\ ISP / \ / ||
`-. ,-' `-. ,-' ||
`---+---' `+------' ||
| | ||
| | ||
|,-------------. | \/
,-+ `-+ +-----------+
,' University `. |University |
( Network ) | ALTO |
`. / | Server |
`-. +--' +-----------+
`+------------'| /\ /\
| | || ||
+--------+-+ +-+--------+ || ||
| Peer1 | | PeerN |<====++ ||
+----------+ +----------+ ||
/\ ||
|| ||
++======================================++
Legend:
=== ALTO protocol
Figure 4: Example of a Cascaded ALTO Server
図4：カスケードされたALTOサーバーの例
In this setting, all destinations that can be reached via the NREN are preferred in the rating of the university's ALTO server. In contrast, all traffic that is not routed via the NREN will be handled by the commercial upstream ISP and is in general less preferred due to the associated costs. Yet, there may be significant differences between various destinations reached via the ISP. Therefore, the ALTO server at the university may also include the guidance given by the ISP ALTO server in its replies to the ALTO clients. This is an example for cascaded ALTO servers.
この設定では、NRENを介して到達できるすべての宛先が、大学のALTOサーバーの評価で優先されます。対照的に、NREN経由でルーティングされないすべてのトラフィックは、商用の上流ISPによって処理され、関連するコストのため、一般にあまり好ましくありません。それでも、ISP経由で到達するさまざまな宛先の間には大きな違いがあるかもしれません。したがって、大学のALTOサーバーには、ISPのALTOサーバーから提供されるガイダンスを、ALTOクライアントへの返信に含めることもできます。これは、カスケードされたALTOサーバーの例です。
The Internet consists of many networks. The networks are owned and managed by different network operators, such as commercial ISPs, enterprise IT departments, universities, and other organizations. These network operators provide network connectivity, e.g., by access networks, such as cable networks, xDSL networks, 3G/4G mobile networks, etc. Network operators need to manage, control, and audit the traffic. Therefore, it is important to understand how to deploy an ALTO service and what its expected impact might be.
インターネットは多くのネットワークで構成されています。ネットワークは、商用ISP、エンタープライズIT部門、大学、その他の組織などのさまざまなネットワークオペレーターによって所有および管理されます。これらのネットワークオペレーターは、ケーブル接続、xDSLネットワーク、3G / 4Gモバイルネットワークなどのアクセスネットワークなどによるネットワーク接続を提供します。ネットワークオペレーターは、トラフィックを管理、制御、および監査する必要があります。したがって、ALTOサービスをデプロイする方法と、その予想される影響が何かを理解することが重要です。
The general objective of ALTO is to give guidance to applications on what endpoints (e.g., IP addresses or IP prefixes) are to be preferred according to the operator of the ALTO server. The ALTO protocol gives means to let the ALTO server operator express its preference, whatever this preference is.
ALTOの一般的な目的は、ALTOサーバーのオペレーターに応じて、どのエンドポイント（IPアドレスやIPプレフィックスなど）を優先するかをアプリケーションにガイダンスすることです。 ALTOプロトコルは、ALTOサーバーオペレーターがこの設定を問わず、その設定を表現できるようにする手段を提供します。
ALTO enables network operators to support application-level traffic engineering by influencing application resource provider selection. This traffic engineering can have different objectives:
ALTOを使用すると、ネットワークオペレーターは、アプリケーションリソースプロバイダーの選択に影響を与えることにより、アプリケーションレベルのトラフィックエンジニアリングをサポートできます。このトラフィックエンジニアリングには、さまざまな目的があります。
1. Inter-network traffic localization: ALTO can help to reduce inter-domain traffic. The networks of different network operators are interconnected through peering points. From a business view, the inter-network settlement is needed for exchanging traffic between these networks. These peering agreements can be costly. To reduce these costs, a simple objective is to decrease the traffic exchange across the peering points and thus keep the traffic in the own network or Autonomous System (AS) as far as possible.
1. ネットワーク間トラフィックのローカリゼーション：ALTOは、ドメイン間トラフィックの削減に役立ちます。異なるネットワークオペレーターのネットワークは、ピアリングポイントを介して相互接続されます。ビジネスの観点からは、これらのネットワーク間でトラフィックを交換するには、ネットワーク間の決済が必要です。これらのピアリング契約は高額になる可能性があります。これらのコストを削減するための単純な目的は、ピアリングポイント間のトラフィック交換を減らし、それによってトラフィックを可能な限り独自のネットワークまたは自律システム（AS）に維持することです。
2. Intra-network traffic localization: In case of large network operators, the network may be grouped into several networks, domains, or ASes. The core network includes one or several backbone networks, which are connected to multiple aggregation, metro, and access networks. If traffic can be limited to certain areas such as access networks, this decreases the usage of backbone and thus helps to save resources and costs.
2. ネットワーク内トラフィックのローカリゼーション：大規模なネットワークオペレーターの場合、ネットワークはいくつかのネットワーク、ドメイン、またはASにグループ化されることがあります。コアネットワークには、複数のアグリゲーション、メトロ、およびアクセスネットワークに接続されている1つ以上のバックボーンネットワークが含まれます。トラフィックをアクセスネットワークなどの特定の領域に制限できる場合、これはバックボーンの使用を減らし、リソースとコストの節約に役立ちます。
3. Network offloading: Compared to fixed networks, mobile networks have some special characteristics, including lower link bandwidth, high cost, limited radio frequency resource, and limited terminal battery. In mobile networks, wireless links should be used efficiently. For example, in the case of a P2P service, it is likely that hosts should prefer retrieving data from hosts in fixed networks, and avoid retrieving data from mobile hosts.
3.ネットワークオフロード：固定ネットワークと比較して、モバイルネットワークには、低リンク帯域幅、高コスト、限られた無線周波数リソース、限られた端末バッテリーなど、いくつかの特別な特性があります。モバイルネットワークでは、ワイヤレスリンクを効率的に使用する必要があります。たとえば、P2Pサービスの場合、ホストは固定ネットワーク内のホストからのデータの取得を優先し、モバイルホストからのデータの取得を回避する必要があります。
4. Application tuning: ALTO is also a tool to optimize the performance of applications that depend on the network and perform resource provider selection decisions among network endpoints; an example is the network-aware selection of CDN caches.
4. アプリケーションの調整：ALTOは、ネットワークに依存するアプリケーションのパフォーマンスを最適化し、ネットワークエンドポイント間でリソースプロバイダーの選択を決定するためのツールでもあります。たとえば、ネットワーク対応のCDNキャッシュの選択です。
In the following, these objectives are explained in more detail with examples.
以下では、これらの目的について例を使用してさらに詳しく説明します。
ALTO guidance can be used to keep traffic local in a network, for instance, in order to reduce peering costs. An ALTO server can let applications prefer other hosts within the same network operator's network instead of randomly connecting to other hosts that are located in another operator's network. Here, a network operator would always express its preference for hosts in its own network, while hosts located outside its own network are to be avoided (i.e., they are undesired to be considered by the applications). Figure 5 shows such a scenario where hosts prefer hosts in the same network (e.g., Host 1 and Host 2 in ISP1 and Host 3 and Host 4 in ISP2).
ALTOガイダンスは、たとえばピアリングコストを削減するために、ネットワーク内のトラフィックをローカルに保つために使用できます。 ALTOサーバーを使用すると、アプリケーションは、別のオペレーターのネットワークにある他のホストにランダムに接続する代わりに、同じネットワークオペレーターのネットワーク内の他のホストを優先できます。ここでは、ネットワークオペレーターは常に自身のネットワーク内のホストの優先順位を表現しますが、自身のネットワークの外部にあるホストは回避されます（つまり、アプリケーションによって考慮されることは望ましくありません）。図5は、ホストが同じネットワーク内のホストを優先するようなシナリオを示しています（ISP1のホスト1とホスト2、ISP2のホスト3とホスト4など）。
,-------. +-----------+
,---. ,-' `-. | Host 1 |
,-' `-. / ISP 1 ########|ALTO Client|
/ \ / # \ +-----------+
/ ISP X \ | # | +-----------+
/ \ \ ########| Host 2 |
; +----------------------------|ALTO Client|
| | | `-. ,-' +-----------+
| | | `-------'
| Inter- | | ,-------. +-----------+
: network | ; ,-' `########| Host 3 |
\ traffic | / / ISP 2 # \ |ALTO Client|
\ | / / # \ +-----------+
\ |/ | # | +-----------+
`-. ,-| \ ########| Host 4 |
`---' +----------------------------|ALTO Client|
`-. ,-' +-----------+
`-------'
Legend:
### preferred "connections"
--- non-preferred "connections"
Figure 5: Inter-Network Traffic Localization
図5：ネットワーク間トラフィックのローカリゼーション
Examples for corresponding ALTO maps can be found in Section 3.5. Depending on the application characteristics, it may not be possible or even desirable to completely localize all traffic.
対応するALTOマップの例は、セクション3.5にあります。アプリケーションの特性によっては、すべてのトラフィックを完全にローカライズすることが不可能または望ましくない場合もあります。
The previous section describes the results of the ALTO guidance on an inter-network level. In the same way, ALTO can also be used for intra-network localization. In this case, ALTO provides guidance on which internal hosts are to be preferred inside a single network (e.g., one AS). This application-level traffic engineering can reduce the capacity requirements in the core network of an ISP. Figure 6 shows such a scenario where Host 1 and Host 2 are located in an access net 1 of ISP 1 and connect via a low capacity link to the core of the same ISP 1. If Host 1 and Host 2 exchange their data with remote hosts, they would probably congest the bottleneck link.
前のセクションでは、ネットワーク間レベルでのALTOガイダンスの結果について説明しました。同様に、ALTOはネットワーク内のローカリゼーションにも使用できます。この場合、ALTOは、単一のネットワーク（1つのASなど）内で優先される内部ホストについてのガイダンスを提供します。このアプリケーションレベルのトラフィックエンジニアリングにより、ISPのコアネットワークの容量要件を減らすことができます。図6は、ホスト1とホスト2がISP 1のアクセスネット1に配置され、低容量リンクを介して同じISP 1のコアに接続するようなシナリオを示しています。ホスト1とホスト2がリモートホストとデータを交換する場合、彼らはおそらくボトルネックのリンクを混雑させるでしょう。
Bottleneck ,-------. +-----------+
,---. | ,-' `-. | Host 1 |
,-' `-. | / ISP 1 ########|ALTO Client|
/ \ | / (Access # \ +-----------+
/ ISP 1 \| | net 1) # | +-----------+
/ (Core V \ ########| Host 2 |
; network) +--X~~~X---------------------|ALTO Client|
| | | `-. ,-' +-----------+
| | | `-------'
| | | ,-------. +-----------+
: | ; ,-' `########| Host 3 |
\ | / / ISP 1 # \ |ALTO Client|
\ | / / (Access # \ +-----------+
\ |/ | net 2) # | +-----------+
`-. ,-X \ ########| Host 4 |
`---' ~~~~~~~X---------------------|ALTO Client|
^ `-. ,-' +-----------+
| `-------'
Bottleneck
Legend:
### preferred "connections"
--- non-preferred "connections"
Figure 6: Intra-Network Traffic Localization
図6：ネットワーク内トラフィックのローカリゼーション
In such a situation, the operator can guide the hosts to try local hosts in the same network islands first, avoiding or at least lowering the effect on the bottleneck link, as shown in Figure 6.
そのような状況では、オペレーターは、図6に示すように、最初に同じネットワークアイランド内のローカルホストを試すようにホストをガイドし、ボトルネックリンクへの影響を回避または少なくとも低減できます。
The objective is to avoid bottlenecks by optimized endpoint selection at the application level. That said, it must be understood that ALTO is not a general-purpose method to deal with the congestion at the bottleneck.
目的は、アプリケーションレベルで最適化されたエンドポイント選択によってボトルネックを回避することです。とはいえ、ALTOはボトルネックの輻輳に対処するための汎用的な方法ではないことを理解する必要があります。
Another scenario is offloading traffic from networks. This use of ALTO can be beneficial in particular in mobile networks. A network operator may have the desire to guide hosts in its mobile network to use hosts outside this mobile network. One reason could be that the wireless network or the mobile hosts were not designed for direct peer-to-peer communications between mobile hosts, and therefore, it makes sense for peers to fetch content from remote peers in other parts of the Internet.
別のシナリオは、ネットワークからトラフィックをオフロードすることです。 ALTOのこの使用は、特にモバイルネットワークで有益です。ネットワークオペレータは、モバイルネットワーク内のホストを、このモバイルネットワーク外のホストを使用するように誘導したい場合があります。理由の1つは、ワイヤレスネットワークまたはモバイルホストがモバイルホスト間の直接のピアツーピア通信用に設計されていないため、ピアがインターネットの他の部分のリモートピアからコンテンツをフェッチすることが理にかなっている可能性があります。
,-------. +-----------+
,---. ,-' `-. | Host 1 |
,-' `-. / ISP 1 +-------|ALTO Client|
/ \ / (Mobile | \ +-----------+
/ ISP X \ | network) | | +-----------+
/ \ \ +-------| Host 2 |
; #############################|ALTO Client|
| # | `-. ,-' +-----------+
| # | `-------'
| # | ,-------.
: # ; ,-' `-.
\ # / / ISP 2 \
\ # / / (Fixed \
\ #/ | network) | +-----------+
`-. ,-# \ / | Host 3 |
`---' #############################|ALTO Client|
`-. ,-' +-----------+
`-------'
Legend:
### preferred "connections"
--- non-preferred "connections"
Figure 7: ALTO Traffic Network De-localization
図7：ALTOトラフィックネットワークのローカライズ解除
Figure 7 shows the result of such a guidance process where Host 2 prefers a connection with Host 3 instead of Host 1, as shown in Figure 5.
図7は、図5に示すように、ホスト2がホスト1ではなくホスト3との接続を優先するようなガイダンスプロセスの結果を示しています。
A realization of this scenario may have certain limitations and may not be possible in all cases. For instance, it may require the ALTO server to distinguish mobile and non-mobile hosts based on their IP address. This may depend on mobility solutions and may not be possible or accurate. In general, ALTO is not intended as a fine-grained traffic engineering solution for individual hosts. Instead, it typically works on aggregates (e.g., if it is known that certain IP prefixes are often assigned to mobile users).
このシナリオの実現には特定の制限があり、すべての場合に可能であるとは限りません。たとえば、IPアドレスに基づいてモバイルホストと非モバイルホストを区別するためにALTOサーバーが必要になる場合があります。これはモビリティソリューションに依存する可能性があり、不可能または正確でない場合があります。一般に、ALTOは個々のホスト用のきめ細かなトラフィックエンジニアリングソリューションとしては意図されていません。代わりに、通常はアグリゲートで機能します（たとえば、特定のIPプレフィックスがモバイルユーザーに割り当てられることが多いことがわかっている場合）。
ALTO can also provide guidance to optimize the application-level topology of networked applications, e.g., by exposing network performance information. Applications can often run their own measurements to determine network performance, e.g., by active delay measurements or bandwidth probing, but such measurements result in overhead and complexity. Accessing an ALTO server can be a simpler alternative. In addition, an ALTO server may also expose network information that applications cannot easily measure or reverse-engineer.
ALTOは、ネットワークパフォーマンス情報を公開するなど、ネットワークアプリケーションのアプリケーションレベルのトポロジを最適化するためのガイダンスも提供します。多くの場合、アプリケーションは独自の測定を実行して、アクティブな遅延測定や帯域幅プローブなどによってネットワークパフォーマンスを決定できますが、このような測定はオーバーヘッドと複雑さをもたらします。 ALTOサーバーへのアクセスは、より簡単な方法です。さらに、ALTOサーバーは、アプリケーションが簡単に測定またはリバースエンジニアリングできないネットワーク情報を公開する場合もあります。
A process to generate ALTO topology information typically comprises several steps. The first step is to gather information, which is described in the following section. The subsequent sections describe how the gathered data can be processed and which methods can be applied to generate the information exposed by ALTO, such as network and cost maps.
ALTOトポロジー情報を生成するプロセスは、通常、いくつかのステップで構成されます。最初のステップは、次のセクションで説明する情報を収集することです。以降のセクションでは、収集されたデータを処理する方法と、ネットワークやコストマップなどのALTOによって公開される情報を生成するために適用できる方法について説明します。
Providing ALTO guidance can result in a win-win situation for network providers and users of the ALTO information. Applications possibly get a better performance, while the network provider has means to optimize the traffic engineering and thus its costs. Yet, there can be security concerns with exposing topology data. Corresponding limitations are discussed in Section 7.2.
ALTOガイダンスを提供すると、ネットワークプロバイダーとALTO情報のユーザーにとって双方にとってメリットのある状況になる可能性があります。ネットワークプロバイダーはトラフィックエンジニアリングを最適化する手段を備えているため、アプリケーションのパフォーマンスが向上する可能性があるため、コストも削減できます。しかし、トポロジデータの公開にはセキュリティ上の懸念がある可能性があります。対応する制限については、セクション7.2で説明します。
ISPs may have important privacy requirements when deploying ALTO, which have to be taken into account when processing ALTO topology data. In particular, an ISP may not be willing to expose sensitive operational details of its network. The topology abstraction of ALTO enables an ISP to expose the network topology at a desired granularity only, determined by security policies.
ISPには、ALTOを展開するときに重要なプライバシー要件がある場合があります。これは、ALTOトポロジデータを処理するときに考慮する必要があります。特に、ISPはそのネットワークの機密の運用詳細を公開することを望んでいない場合があります。 ALTOのトポロジー抽象化により、ISPはネットワークトポロジーを、セキュリティポリシーによって決定される望ましい粒度でのみ公開できます。
With the ECS, the ALTO client does not have to implement any specific algorithm or mechanism in order to retrieve, maintain and process network topology information (of any kind). The complexity of the network topology (computation, maintenance and distribution) is kept in the ALTO server and ECS is delivered on demand. This allows the ALTO server to enhance and modify the way the topology information sources are used and combined. This simplifies the enforcement of privacy policies of the ISP.
ECSを使用すると、ALTOクライアントは、（あらゆる種類の）ネットワークトポロジ情報を取得、維持、および処理するために特定のアルゴリズムまたはメカニズムを実装する必要がありません。ネットワークトポロジの複雑さ（計算、メンテナンス、配布）はALTOサーバーに保持され、ECSはオンデマンドで配信されます。これにより、ALTOサーバーはトポロジー情報ソースの使用方法と結合方法を強化および変更できます。これにより、ISPのプライバシーポリシーの施行が簡素化されます。
The ALTO Network and Cost Map Service expose an abstract view on the ISP network topology. Therefore, care is needed when constructing those maps in order to take privacy policies into account, as further discussed in Section 3.2.3. The ALTO protocol also supports further features such as endpoint properties, which could also be used to expose topology guidance. The privacy considerations for ALTO maps also apply to such ALTO extensions.
ALTOネットワークとコストマップサービスは、ISPネットワークトポロジの抽象的なビューを公開します。したがって、セクション3.2.3でさらに説明するように、プライバシーポリシーを考慮に入れるためにこれらのマップを作成するときは注意が必要です。 ALTOプロトコルは、エンドポイントプロパティなど、トポロジガイダンスを公開するために使用できるその他の機能もサポートしています。 ALTOマップのプライバシーに関する考慮事項は、そのようなALTO拡張にも適用されます。
The first step in the process of generating ALTO information is to gather the required information from the network. An ALTO server can collect topological information from a variety of sources in the network and provides a cohesive, abstract view of the network topology to applications using an ALTO client. Topology data sources may include routing protocols, network policies, state and performance information, geolocation, etc. An ALTO server requires at least some topology and/or routing information, i.e., information about existing endpoints and their interconnection. With this information, it is in principle possible to compute paths between all known endpoints. Based on such basic data, the ALTO server builds an ALTO-specific network topology that represents the network as it should be understood and utilized by applications (resource consumers) at endpoints using ALTO services (e.g., Network and Cost Map Service or ECS). A basic dataset can be extended by many other information obtainable from the network.
ALTO情報を生成するプロセスの最初のステップは、ネットワークから必要な情報を収集することです。 ALTOサーバーは、ネットワーク内のさまざまなソースからトポロジー情報を収集し、ALTOクライアントを使用してアプリケーションにネットワークトポロジーのまとまりのある抽象的なビューを提供します。トポロジデータソースには、ルーティングプロトコル、ネットワークポリシー、状態とパフォーマンスの情報、地理位置情報などが含まれます。ALTOサーバーには、少なくともいくつかのトポロジやルーティング情報、つまり既存のエンドポイントとその相互接続に関する情報が必要です。この情報があれば、原則としてすべての既知のエンドポイント間のパスを計算することが可能です。そのような基本データに基づいて、ALTOサーバーは、ALTOサービス（ネットワークおよびコストマップサービスまたはECSなど）を使用するエンドポイントでアプリケーション（リソースコンシューマー）が理解および利用する必要があるネットワークを表すALTO固有のネットワークトポロジを構築します。基本データセットは、ネットワークから取得できる他の多くの情報によって拡張できます。
The ALTO protocol does not assume a specific network technology or topology. In principle, ALTO can be used with various types of addresses (Endpoint Addresses). [RFC7285] defines the use of IPv4/ IPv6 addresses or prefixes in ALTO, but further address types could be added by extensions. In this document, only the use of IPv4/IPv6 addresses is considered.
ALTOプロトコルは、特定のネットワーク技術またはトポロジを想定していません。原則として、ALTOはさまざまなタイプのアドレス（エンドポイントアドレス）で使用できます。 [RFC7285]は、ALTOでのIPv4 / IPv6アドレスまたはプレフィックスの使用を定義しますが、拡張機能によってさらにアドレスタイプを追加できます。このドキュメントでは、IPv4 / IPv6アドレスの使用のみが考慮されています。
The exposure of network topology information is controlled and managed by the ALTO server. ALTO abstract network topologies can be automatically generated from the physical or logical topology of the network, e.g., using "live" network data. The generation would typically be based on policies and rules set by the network operator. The maps and the guidance can significantly differ depending on the use case, the network architecture, and the trust relationship between ALTO server and ALTO client, etc. Besides the security requirements that consist of not delivering any confidential or critical information about the infrastructure, there are efficiency requirements in terms of what aspects of the network are visible and required by the given use case and/or application.
ネットワークトポロジ情報の公開は、ALTOサーバーによって制御および管理されます。 ALTOの抽象的なネットワークトポロジは、「ライブ」ネットワークデータなどを使用して、ネットワークの物理トポロジまたは論理トポロジから自動的に生成できます。生成は通常、ネットワークオペレーターによって設定されたポリシーとルールに基づきます。マップとガイダンスは、ユースケース、ネットワークアーキテクチャ、ALTOサーバーとALTOクライアント間の信頼関係などによって大幅に異なる場合があります。インフラストラクチャに関する機密情報や重要な情報を配信しないことからなるセキュリティ要件に加えてネットワークのどの側面が可視であり、特定のユースケースまたはアプリケーション、あるいはその両方で必要とされるかという点で効率要件です。
The ALTO server operator has to ensure that the ALTO topology does not reveal any details that would endanger the network integrity and security. For instance, ALTO is not intended to leak raw Interior Gateway Protocol (IGP) or Border Gateway Protocol (BGP) databases to ALTO clients.
ALTOサーバーオペレーターは、ALTOトポロジがネットワークの整合性とセキュリティを危険にさらす可能性のある詳細を明らかにしないことを確認する必要があります。たとえば、ALTOは、生のInterior Gateway Protocol（IGP）またはBorder Gateway Protocol（BGP）データベースをALTOクライアントにリークすることを意図していません。
+--------+ +--------+
| ALTO | | ALTO |
| Client | | Client |
+--------+ +--------+
/\ /\
|| || ALTO protocol
|| ||
\/ \/
+---------+
| ALTO |
| Server |
+---------+
: : : :
: : : :
+..........+ : : +..........+ Provisioning
: : : : protocol
: : : :
+---------+ +---------+ +---------+ +---------+
| BGP | | I2RS | | PCE | | NMS | Potential
| Speaker | | Client | | | | OSS | data sources
+---------+ +---------+ +---------+ +---------+
^ ^ ^ ^
| | | |
Link-State I2RS TED Topology and traffic-related
NLRI for data data data from SNMP, NETCONF,
IGP/BGP RESTCONF, REST, IPFIX, etc.
Figure 8: Potential Data Sources for ALTO
図8：ALTOの潜在的なデータソース
As illustrated in Figure 8, the topology data used by an ALTO server can originate from different data sources:
図8に示すように、ALTOサーバーが使用するトポロジデータは、さまざまなデータソースから取得できます。
o Relevant information sources are IGPs or BGP. An ALTO server could get network routing information by listening to IGPs and/or peering with BGP speakers. For data collection, link-state protocols are more suitable since every router propagates its information throughout the whole network. Hence, it is possible to obtain information about all routers and their neighbors from one single router in the network. In contrast, distance-vector protocols are less suitable since routing information is only shared among neighbors. To obtain the whole topology with distance-vector routing protocols it is necessary to retrieve routing information from every router in the network.
o 関連する情報ソースはIGPまたはBGPです。 ALTOサーバーは、IGPをリッスンしたり、BGPスピーカーとピアリングしたりすることにより、ネットワークルーティング情報を取得できます。すべてのルーターがネットワーク全体に情報を伝達するため、データ収集にはリンクステートプロトコルの方が適しています。したがって、ネットワーク内の1つのルーターからすべてのルーターとその隣接ルーターに関する情報を取得できます。対照的に、ルーティング情報はネイバー間でのみ共有されるため、距離ベクトルプロトコルはあまり適していません。距離ベクトルルーティングプロトコルを使用してトポロジ全体を取得するには、ネットワーク内のすべてのルーターからルーティング情報を取得する必要があります。
o [RFC7752] describes a mechanism by which link-state and Traffic Engineering (TE) information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a new BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism is applicable to physical and virtual IGP links and can also include TE data. For instance, prefix data can be carried and originated in BGP, while TE data is originated and carried in an IGP. The mechanism described is subject to policy control.
o [RFC7752]は、リンクステートおよびトラフィックエンジニアリング（TE）情報をネットワークから収集し、BGPルーティングプロトコルを使用して外部コンポーネントと共有できるメカニズムを記述しています。これは、新しいBGPネットワーク層到達可能性情報（NLRI）エンコード形式を使用して実現されます。このメカニズムは、物理IGPリンクと仮想IGPリンクに適用でき、TEデータを含めることもできます。たとえば、プレフィックスデータはBGPで伝送および発信でき、TEデータはIGPで伝送および発信できます。説明されているメカニズムはポリシー制御の対象です。
o The Interface to the Routing System (I2RS) is a solution for state transfer in and out of the Internet's routing system [RFC7921]. An ALTO server could use an I2RS client to observe routing-related information. With the rise of Software-Defined Networking (SDN) and a decoupling of network data and control plane, topology information could also be fetched from an SDN controller. If I2RS is used, [RFC7922] provides traceability for these interactions. This scenario is not further discussed in the remainder of this document.
o ルーティングシステムへのインターフェイス（I2RS）は、インターネットのルーティングシステム[RFC7921]との間の状態転送のソリューションです。 ALTOサーバーはI2RSクライアントを使用して、ルーティング関連の情報を監視できます。 Software-Defined Networking（SDN）の登場とネットワークデータとコントロールプレーンの分離により、トポロジー情報もSDNコントローラーからフェッチできるようになりました。 I2RSが使用される場合、[RFC7922]はこれらの相互作用のトレーサビリティを提供します。このシナリオについては、このドキュメントの残りの部分では詳しく説明しません。
o Another potential source of topology information could be a Path Computation Element (PCE) [RFC4655]. Topology and traffic-related information can be retrieved from the Traffic Engineering Database (TED) and Label Switched Path Database (LSP-DB). This scenario is not further discussed in the remainder of this document.
o トポロジ情報の別の潜在的なソースは、パス計算要素（PCE）[RFC4655]である可能性があります。トポロジおよびトラフィック関連の情報は、トラフィックエンジニアリングデータベース（TED）およびラベルスイッチドパスデータベース（LSP-DB）から取得できます。このシナリオについては、このドキュメントの残りの部分では詳しく説明しません。
o An ALTO server can also leverage a Network Management System (NMS) or an Operations Support System (OSS) as data sources. NMS or OSS solutions are used to control, operate, and manage a network, e.g., using the Simple Network Management Protocol (SNMP) or Network Configuration Protocol (NETCONF). As explained for instance in [RFC7491], the NMS and OSS can be consumers of network events reported and can act on these reports as well as displaying them to users and raising alarms. In addition, NMS and OSS systems may have access to routing information and network inventory data (e.g., links, nodes, or link properties not visible to routing protocols, such as Shared Risk Link Groups). Furthermore, Operations, Administration, and Maintenance (OAM) information can be leveraged, including traffic utilization obtained from IP Flow Information Export (IPFIX), event notifications (e.g., via syslog), liveness detection (e.g., bidirectional forwarding detection, BFD). NMS or OSS systems also may have functions to correlate and orchestrate information originating from other data sources. For instance, it could be required to correlate IP prefixes with routers (Provider, Provider Edge, Customer Edge, etc.), IGP areas, VLAN IDs, or policies.
o ALTOサーバーは、データソースとしてネットワーク管理システム（NMS）または運用サポートシステム（OSS）を活用することもできます。 NMSまたはOSSソリューションは、ネットワークを制御、操作、および管理するために使用されます。たとえば、簡易ネットワーク管理プロトコル（SNMP）またはネットワーク構成プロトコル（NETCONF）を使用します。たとえば[RFC7491]で説明されているように、NMSとOSSは、報告されたネットワークイベントのコンシューマであり、これらのレポートに基づいてアクションを実行したり、ユーザーに表示したり、アラームを発生させたりできます。さらに、NMSおよびOSSシステムは、ルーティング情報およびネットワークインベントリデータ（共有リスクリンクグループなどのルーティングプロトコルには表示されないリンク、ノード、またはリンクプロパティなど）にアクセスできます。さらに、運用、管理、および保守（OAM）情報を活用できます。これには、IPフロー情報エクスポート（IPFIX）、イベント通知（syslogなど）、活性検出（双方向転送検出、BFDなど）から取得したトラフィック使用率が含まれます。 NMSまたはOSSシステムは、他のデータソースから発信された情報を関連付けて調整する機能も備えている場合があります。たとえば、IPプレフィックスをルーター（プロバイダー、プロバイダーエッジ、カスタマーエッジなど）、IGPエリア、VLAN ID、またはポリシーと関連付ける必要がある場合があります。
In the context of the provisioning protocol, topology information could be modeled in a YANG data model [NETWORK-TOPO].
プロビジョニングプロトコルのコンテキストでは、トポロジ情報をYANGデータモデル[NETWORK-TOPO]でモデル化できます。
The data sources mentioned so far are only a subset of potential topology sources and protocols. Depending on the network type, (e.g., mobile, satellite network) different hardware and protocols are in operation to form and maintain the network.
これまでに述べたデータソースは、潜在的なトポロジソースとプロトコルのサブセットにすぎません。ネットワークのタイプ（モバイル、衛星ネットワークなど）に応じて、ネットワークを形成および維持するためにさまざまなハードウェアとプロトコルが動作しています。
In general, it is challenging to gather detailed information about the whole Internet, since the network consists of multiple domains and in many cases it is not possible to collect information across network borders. Hence, potential information sources may be limited to a certain domain.
一般に、ネットワークは複数のドメインで構成されており、多くの場合、ネットワークの境界を越えて情報を収集することはできないため、インターネット全体に関する詳細な情報を収集することは困難です。したがって、潜在的な情報源が特定のドメインに制限される場合があります。
ALTO introduces provider-defined network location identifiers called Provider-defined Identifiers (PIDs) to aggregate network endpoints in the Map Services. Endpoints within one PID may be treated as single entity, assuming proximity based on network topology or other similarity. A key use case of PIDs is to specify network preferences (costs) between PIDs instead of individual endpoints. It is up to the operator of the ALTO server how to group endpoints and how to assign 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.
ALTOは、プロバイダー定義の識別子（PID）と呼ばれるプロバイダー定義のネットワークロケーション識別子を導入して、マップサービスのネットワークエンドポイントを集約します。 1つのPID内のエンドポイントは、ネットワークトポロジまたはその他の類似性に基づいて近接していると仮定して、単一のエンティティとして扱われる場合があります。 PIDの主な使用例は、個々のエンドポイントではなくPID間のネットワーク設定（コスト）を指定することです。エンドポイントをグループ化する方法とPIDを割り当てる方法は、ALTOサーバーのオペレーター次第です。たとえば、PIDは、サブネット、サブネットのセット、大都市圏、POP、自律システム、または自律システムのセットを表す場合があります。
This document only considers deployment scenarios in which PIDs expand to a set of IP address ranges (CIDR). A PID is characterized by a string identifier and its associated set of endpoint addresses [RFC7285]. If an ALTO server offers the Map Service, corresponding identifiers have to be configured.
このドキュメントでは、PIDが一連のIPアドレス範囲（CIDR）に展開される展開シナリオのみを考慮しています。 PIDは、文字列識別子とそれに関連付けられた一連のエンドポイントアドレス[RFC7285]によって特徴付けられます。 ALTOサーバーがマップサービスを提供する場合、対応する識別子を構成する必要があります。
An automated ALTO implementation may use dynamic algorithms to aggregate network topology. However, it is often desirable to have a mechanism through which the network operator can control the level and details of network aggregation based on a set of requirements and constraints. This will typically be governed by policies that enforce a certain level of abstraction and prevent leakage of sensitive operational data.
自動化されたALTO実装では、動的アルゴリズムを使用してネットワークトポロジを集約できます。ただし、多くの場合、ネットワークオペレータが一連の要件と制約に基づいてネットワーク集約のレベルと詳細を制御できるメカニズムが必要です。これは通常、特定のレベルの抽象化を適用し、機密の運用データの漏洩を防ぐポリシーによって管理されます。
For instance, an ALTO server may leverage BGP information that is available in a network's service provider network layer and compute the group of prefix. An example being BGP communities, which are used in MPLS/IP networks as a common mechanism to aggregate and group prefixes. A BGP community is an attribute used to tag a prefix to group prefixes based on mostly any criteria (as an example, most ISP networks originate BGP prefixes with communities identifying the Point of Presence (PoP) where the prefix has been originated). These BGP communities could be used to map IP address ranges to PIDs. By an additional policy, the ALTO server operator may decide an arbitrary cost defined between groups. Alternatively, there are algorithms that allow the dynamic computation of costs between groups. The ALTO protocol itself is independent of such algorithms and policies.
たとえば、ALTOサーバーは、ネットワークのサービスプロバイダーネットワークレイヤーで利用可能なBGP情報を利用して、プレフィックスのグループを計算します。たとえば、BGPコミュニティは、プレフィックスを集約およびグループ化するための共通のメカニズムとしてMPLS / IPネットワークで使用されます。 BGPコミュニティは、ほとんどすべての基準に基づいてプレフィックスをグループプレフィックスにタグ付けするために使用される属性です（例として、ほとんどのISPネットワークは、プレフィックスが作成されたポイントオブプレゼンス（PoP）を識別するコミュニティでBGPプレフィックスを作成します）。これらのBGPコミュニティは、IPアドレス範囲をPIDにマップするために使用できます。追加のポリシーにより、ALTOサーバーオペレーターは、グループ間で定義される任意のコストを決定できます。あるいは、グループ間のコストの動的計算を可能にするアルゴリズムがあります。 ALTOプロトコル自体は、そのようなアルゴリズムやポリシーから独立しています。
An ALTO server indicates preferences amongst network locations in the form of abstract costs. These costs are generic costs and can be internally computed by the operator of the ALTO server according to its own policy. For a given ALTO network map, an ALTO cost map defines directional costs pairwise amongst the set of source and destination network locations defined by the PIDs.
ALTOサーバーは、ネットワークロケーション間の好みを抽象的なコストの形で示します。これらのコストは一般的なコストであり、ALTOサーバーのオペレーターが独自のポリシーに従って内部的に計算できます。特定のALTOネットワークマップの場合、ALTOコストマップは、PIDで定義された送信元と宛先のネットワークロケーションのセット間で、ペアで方向性コストを定義します。
The ALTO protocol permits the use of different cost types. An ALTO cost type is defined by the combination of a cost metric and a cost mode. The cost metric identifies what the costs represent. The cost mode identifies how the costs should be interpreted, i.e., whether returned costs should be interpreted as numerical values or ordinal rankings. The ALTO protocol also allows the definition of additional constraints defining which elements of a cost map shall be returned.
ALTOプロトコルでは、さまざまなコストタイプを使用できます。 ALTOコストタイプは、コストメトリックとコストモードの組み合わせによって定義されます。コストメトリックは、コストが表すものを識別します。コストモードは、コストの解釈方法、つまり返されたコストを数値または序数のランキングとして解釈するかどうかを識別します。 ALTOプロトコルでは、コストマップのどの要素を返すかを定義する追加の制約を定義することもできます。
The ALTO protocol specification [RFC7285] defines the "routingcost" cost metric as the basic set of rating criteria, which has to be supported by all implementations. 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. How that metric is calculated is up to the ALTO server.
ALTOプロトコル仕様[RFC7285]は、「routingcost」コストメトリックを、すべての実装でサポートする必要がある評価基準の基本セットとして定義しています。このコストメトリックは、送信元から宛先にトラフィックをルーティングするコストの一般的な尺度を示します。値が小さいほど、送信元から宛先に送信されるトラフィックの優先度が高くなります。そのメトリックの計算方法は、ALTOサーバー次第です。
It is possible to calculate the "routingcost" cost metric based on actual routing protocol information. Typically, IGPs provide details about endpoints and links within a given network, while the BGP is used to provide details about links to endpoints in other networks. Besides topology and routing information, networks have a multitude of other attributes about their state, condition, and operation that comprises but is not limited to attributes like link utilization, bandwidth and delay, ingress/egress points of data flows from/towards endpoints outside of the network up to the location of nodes and endpoints.
実際のルーティングプロトコル情報に基づいて「routingcost」コストメトリックを計算することが可能です。通常、IGPは特定のネットワーク内のエンドポイントとリンクに関する詳細を提供し、BGPは他のネットワーク内のエンドポイントへのリンクに関する詳細を提供するために使用されます。トポロジとルーティング情報に加えて、ネットワークには、リンクの使用状況、帯域幅と遅延、外部のエンドポイントとの間のエンドポイントへのデータフローの入出力ポイントなどの属性を含むがこれらに限定されない、状態、条件、および操作に関する他の多数の属性がありますノードとエンドポイントの場所までのネットワーク。
In order to enable use of extended information, there is a protocol extension procedure to add new ALTO cost types. The following list gives an overview on further rating criteria that have been proposed or that are in use by ALTO-related prototype implementations. This list is not intended as normative text. Instead, its only purpose is to document and discuss rating criteria that have been proposed so far. Whether such rating criteria are useful and whether the corresponding information would actually be made available by ISPs can also depend on the use case of ALTO. A list of rating criteria for which normative specifications exist and which have successfully passed the IETF review process can be found at IANA's "ALTO Cost Metric Registry", available from [ALTO-REG].
拡張情報の使用を可能にするために、新しいALTOコストタイプを追加するプロトコル拡張手順があります。以下のリストは、提案されている、またはALTO関連のプロトタイプ実装で使用されている、さらに別の評価基準の概要を示しています。このリストは、規範的なテキストではありません。代わりに、その唯一の目的は、これまでに提案されている評価基準を文書化して議論することです。そのような評価基準が役立つかどうか、および対応する情報が実際にISPによって提供されるかどうかも、ALTOの使用例に依存する可能性があります。規範的な仕様が存在し、IETFレビュープロセスに合格した評価基準のリストは、[ALTO-REG]から入手できるIANAの「ALTO Cost Metric Registry」にあります。
Distance-related rating criteria:
距離関連の評価基準：
o Relative topological distance: The term relative means that a larger numerical value means greater distance, but it is up to the ALTO service how to compute the values, and the ALTO client will not be informed about the nature of the computation. One way to determine relative topological distance may be counting AS hops, but when querying this parameter, the ALTO client must not assume that the numbers actually are AS hops. In addition to the AS path, a relative cost value could also be calculated taking into account other routing protocol parameters, such as BGP local preference or Multi-Exit Discriminator (MED) attributes.
o 相対トポロジー距離：相対という用語は、数値が大きいほど距離が大きくなることを意味しますが、値の計算方法はALTOサービス次第であり、ALTOクライアントには計算の性質が通知されません。相対トポロジー距離を決定する1つの方法はASホップをカウントすることですが、このパラメーターを照会する場合、ALTOクライアントは、数値が実際にASホップであると想定してはなりません。 ASパスに加えて、BGPローカルプリファレンスやMulti-Exit Discriminator（MED）属性などの他のルーティングプロトコルパラメータを考慮して、相対コスト値を計算することもできます。
o Absolute topological distance, expressed in the number of traversed autonomous systems.
o 通過した自律システムの数で表される絶対トポロジー距離。
o Absolute topological distance, expressed in the number of router hops (i.e., how much the TTL value of an IP packet will be decreased during transit).
o ルーターホップの数で表される絶対トポロジー距離（つまり、転送中にIPパケットのTTL値がどれだけ減少するか）。
o Absolute physical distance, based on knowledge of the approximate geolocation (e.g., continent, country) of an IP address.
o IPアドレスのおおよその地理位置情報（大陸、国など）に基づく、物理的な絶対距離。
Performance-related rating criteria:
パフォーマンス関連の評価基準：
o The minimum achievable throughput between the resource consumer and the candidate resource provider, which is considered useful by the application (only in ALTO queries).
o リソースコンシューマーと候補リソースプロバイダーの間で達成可能な最小スループット。これは、アプリケーションで役立つと見なされます（ALTOクエリでのみ）。
o An arbitrary upper bound for the throughput from/to the candidate resource provider (only in ALTO responses). This may be, but is not necessarily, the provisioned access bandwidth of the candidate resource provider.
o 候補リソースプロバイダーとの間のスループットの任意の上限（ALTO応答のみ）。これは、必ずしもそうである必要はありませんが、候補リソースプロバイダーのプロビジョニングされたアクセス帯域幅です。
o The maximum Round-Trip Time (RTT) between resource consumer and the candidate resource provider, which is acceptable for the application for useful communication with the candidate resource provider (only in ALTO queries).
o リソースコンシューマーと候補リソースプロバイダーの間の最大ラウンドトリップ時間（RTT）。これは、アプリケーションが候補リソースプロバイダーとの有用な通信を行うために許容されます（ALTOクエリのみ）。
o An arbitrary lower bound for the RTT between resource consumer and the candidate resource provider (only in ALTO responses). This may be, for example, based on measurements of the propagation delay in a completely unloaded network.
o リソースコンシューマーと候補リソースプロバイダーの間のRTTの任意の下限（ALTO応答のみ）。これは、例えば、完全に無負荷のネットワークにおける伝搬遅延の測定に基づくことができる。
Charging-related rating criteria:
充電関連の評価基準：
o Metrics representing an abstract cost, e.g., determined by policies that distinguish "cheap" from "expensive" IP subnet ranges without detailing the cost function. According to [RFC7285], the abstract metric "routingcost" is an example for a metric for which the cost function does not have to be disclosed.
o 抽象コストを表すメトリック。たとえば、コスト関数を詳述せずに「安価な」IPサブネット範囲と「高価な」IPサブネット範囲を区別するポリシーによって決定されます。 [RFC7285]によれば、抽象的なメトリック「routingcost」は、コスト関数を開示する必要がないメトリックの例です。
o Traffic volume caps, in case the Internet access of the resource consumer is not charged with a "flat rate". For each candidate resource location, the ALTO service could indicate the amount of data or the bitrate that may be transferred from/to this resource location until a given point in time, and how much of this amount has already been consumed. Furthermore, an ALTO server may have to indicate how excess traffic would be handled (e.g., blocked, throttled, or charged separately at an indicated price), e.g., by a new endpoint property. This is outside the scope of this document. Also, it is left for further study how several applications would interact if only some of them use this criterion. Also left for further study is the use of such a criterion in resource directories that issue ALTO queries on behalf of other endpoints.
o リソース消費者のインターネットアクセスが「定額」で課金されない場合のトラフィック量の上限。候補となるリソースの場所ごとに、ALTOサービスは、特定の時点までにこのリソースの場所との間で転送されるデータ量またはビットレート、およびこの量のどの程度がすでに消費されているかを示すことができます。さらに、ALTOサーバーは、新しいエンドポイントプロパティなどによって、過剰なトラフィックがどのように処理されるか（たとえば、ブロック、スロットル、または指定された価格で個別に課金されるか）を示す必要がある場合があります。これはこのドキュメントの範囲外です。また、いくつかのアプリケーションだけがこの基準を使用する場合、複数のアプリケーションがどのように相互作用するかについては、さらに調査する必要があります。また、他のエンドポイントに代わってALTOクエリを発行するリソースディレクトリでこのような基準を使用することも検討する必要があります。
All the above-listed rating criteria are subject to the remarks below:
上記のすべての評価基準には、以下の注釈が適用されます。
The ALTO client must be aware that with high probability the actual performance values will differ from whatever an ALTO server exposes. In particular, an ALTO client must not consider a throughput parameter as a permission to send data at the indicated rate without using congestion control mechanisms.
ALTOクライアントは、高い確率で実際のパフォーマンス値がALTOサーバーが公開するものと異なることに注意する必要があります。特に、ALTOクライアントは、スループットパラメータを、輻輳制御メカニズムを使用せずに指定された速度でデータを送信するための許可と見なしてはなりません。
The discrepancies are due to various reasons, including, but not limited to the following facts:
不一致は、次の事実を含むがこれらに限定されないさまざまな理由が原因です。
o The ALTO service is not an admission control system.
o ALTOサービスは、入場管理システムではありません。
o The ALTO service may not know the instantaneous congestion status of the network.
o ALTOサービスは、ネットワークの瞬間的な輻輳ステータスを認識しない場合があります。
o The ALTO service may not know all link bandwidths, i.e., where the bottleneck really is, and there may be shared bottlenecks.
o ALTOサービスは、すべてのリンク帯域幅、つまり、ボトルネックが実際にどこにあるかを知っているわけではなく、ボトルネックが共有されている可能性があります。
o The ALTO service may not have all information about the actual routing.
o ALTOサービスには、実際のルーティングに関するすべての情報がない場合があります。
o The ALTO service may not know whether the candidate endpoint itself is overloaded.
o ALTOサービスは、候補エンドポイント自体が過負荷になっているかどうかを認識しない場合があります。
o The ALTO service may not know whether the candidate endpoint throttles the bandwidth it devotes for the considered application.
o ALTOサービスは、対象のエンドポイントが、検討中のアプリケーションに費やす帯域幅を調整するかどうかを認識していない場合があります。
o The ALTO service may not know whether the candidate endpoint will throttle the data it sends to the client (e.g., because of some fairness algorithm, such as tit for tat).
o ALTOサービスは、候補エンドポイントがクライアントに送信するデータを調整するかどうかを認識できない場合があります（たとえば、tatのtitのようないくつかの公平性アルゴリズムのため）。
Because of these inaccuracies and the lack of complete, instantaneous state information, which are inherent to the ALTO service, the application must use other mechanisms (such as passive measurements on actual data transmissions) to assess the currently achievable throughput, and it must use appropriate congestion control mechanisms in order to avoid a congestion collapse. Nevertheless, the rating criteria may provide a useful shortcut for quickly excluding candidate resource providers from such probing, if it is known in advance that connectivity is in any case worse than what is considered the minimum useful value by the respective application.
これらの不正確さと、ALTOサービスに固有の完全な瞬間的な状態情報がないため、アプリケーションは他のメカニズム（実際のデータ送信のパッシブ測定など）を使用して、現在達成可能なスループットを評価し、適切な輻輳の崩壊を回避するための輻輳制御メカニズム。それにもかかわらず、接続性がそれぞれのアプリケーションで最小の有用な値と見なされるものよりも悪いことが事前にわかっている場合、評価基準は候補のリソースプロバイダーをそのような調査から迅速に除外するための便利なショートカットを提供します。
Rating criteria that should not be defined for and used by the ALTO service include:
ALTOサービスで定義および使用すべきではない評価基準には、次のものがあります。
o Performance metrics that are closely related to the instantaneous congestion status. The definition of alternate approaches for congestion control is explicitly out of the scope of ALTO. Instead, other appropriate means, such as using TCP-based transport, have to be used to avoid congestion. In other words, ALTO is a service to provide network and policy information, with update intervals that are possibly several orders of magnitude slower than congestion-control loops (e.g., in TCP) can react on changes in network congestion state. This clear separation of responsibilities avoids traffic oscillations and can help for network stability and cost optimization.
o 瞬間的な輻輳ステータスに密接に関連するパフォーマンスメトリック。輻輳制御のための代替アプローチの定義は、明示的にALTOの範囲外です。代わりに、TCPベースのトランスポートを使用するなど、他の適切な手段を使用して、輻輳を回避する必要があります。言い換えると、ALTOはネットワークとポリシー情報を提供するサービスであり、更新間隔は、輻輳制御ループ（TCPなど）がネットワークの輻輳状態の変化に対応できるよりも数桁遅い可能性があります。この明確な責任の分離により、トラフィックの変動が回避され、ネットワークの安定性とコストの最適化に役立ちます。
o Performance metrics that raise privacy concerns. For instance, it has been questioned whether an ALTO service should publicly expose the provisioned access bandwidth of cable/DSL customers, as this could enable identification of "premium customers" of an ISP.
o プライバシーの問題を引き起こすパフォーマンスメトリック。たとえば、ALTOサービスがケーブル/ DSL顧客のプロビジョニングされたアクセス帯域幅を公に公開すべきかどうかが問われています。これにより、ISPの「プレミアム顧客」を識別できるようになるためです。
The purpose of this section is ensure that administrators and users of ALTO services are aware of the objectives of the ALTO protocol design. Using ALTO beyond this scope may limit its efficiency. Likewise, Map-based and Endpoint-based ALTO Services may face certain issues during deployment. This section explains these limitations and also outlines potential solutions.
このセクションの目的は、ALTOサービスの管理者とユーザーがALTOプロトコル設計の目的を確実に認識できるようにすることです。この範囲を超えてALTOを使用すると、効率が制限される可能性があります。同様に、マップベースおよびエンドポイントベースのALTOサービスは、展開中に特定の問題に直面する可能性があります。このセクションでは、これらの制限について説明し、可能な解決策の概要も示します。
ALTO is designed as a protocol between clients integrated in applications and servers that provide network information and guidance (e.g., basic network location structure and preferences of network paths). The objective is to modify network resource consumption patterns at application level while maintaining or improving application performance. This design focus results in a number of characteristics of ALTO:
ALTOは、アプリケーションとサーバーに統合されたクライアント間のプロトコルとして設計されており、ネットワーク情報とガイダンス（例：基本的なネットワークロケーション構造とネットワークパスの設定）を提供します。目的は、アプリケーションのパフォーマンスを維持または改善しながら、アプリケーションレベルでネットワークリソースの消費パターンを変更することです。この設計の焦点は、ALTOの多くの特性をもたらします。
o Endpoint focus: In typical ALTO use cases, neither the consumer of the topology information (i.e., the ALTO client) nor the considered resources (e.g., files at endpoints) are part of the network. The ALTO server presents an abstract network topology containing only information relevant to an application overlay for better-than-random resource provider selection among its endpoints. The ALTO protocol specification [RFC7285] is not designed to expose network internals such as routing tables or configuration data that are not relevant for application-level resource provider selection decisions in network endpoints.
o エンドポイントの焦点：一般的なALTOの使用例では、トポロジー情報のコンシューマー（つまり、ALTOクライアント）も考慮されるリソース（エンドポイントのファイルなど）もネットワークの一部ではありません。 ALTOサーバーは、エンドポイント間でランダムプロバイダーよりも優れたリソースプロバイダーを選択するために、アプリケーションオーバーレイに関連する情報のみを含む抽象的なネットワークトポロジを提示します。 ALTOプロトコル仕様[RFC7285]は、ルーティングテーブルやネットワークエンドポイントでのアプリケーションレベルのリソースプロバイダー選択の決定に関係のない構成データなどのネットワーク内部を公開するようには設計されていません。
o Abstraction: The ALTO services such as the Network and Cost Map Service or the ECS provide an abstract view of the network only. The operator of the ALTO server has full control over the granularity (e.g., by defining policies how to aggregate subnets into PIDs) and the level of detail of the abstract network representation (e.g., by deciding what cost types to support).
o 抽象化：ネットワークおよびコストマップサービスやECSなどのALTOサービスは、ネットワークのみの抽象ビューを提供します。 ALTOサーバーのオペレーターは、細分性（たとえば、サブネットをPIDに集約する方法をポリシーで定義すること）と抽象ネットワーク表現の詳細レベル（たとえば、サポートするコストタイプを決定すること）を完全に制御できます。
o Multiple administrative domains: The ALTO protocol is designed for use cases where the ALTO server and client can be located in different organizations or trust domains. ALTO assumes a loose coupling between server and client. In addition, ALTO does not assume that an ALTO client has any a priori knowledge about the ALTO server and its supported features. An ALTO server can be discovered automatically.
o 複数の管理ドメイン：ALTOプロトコルは、ALTOサーバーとクライアントを異なる組織または信頼ドメインに配置できるユースケース向けに設計されています。 ALTOは、サーバーとクライアント間の疎結合を前提としています。さらに、ALTOは、ALTOクライアントがALTOサーバーとそのサポートされている機能について事前の知識を持っているとは想定していません。 ALTOサーバーは自動的に検出されます。
o Read-only: ALTO is a query/response protocol to retrieve guidance information. Neither network/cost map queries nor queries to the ECS are designed to affect state in the network.
o 読み取り専用：ALTOは、ガイダンス情報を取得するためのクエリ/応答プロトコルです。ネットワーク/コストマップクエリもECSへのクエリも、ネットワークの状態に影響を与えるようには設計されていません。
If ALTO shall be deployed for use cases beyond the scope defined by these assumptions, the protocol design may result in limitations.
ALTOがこれらの前提条件で定義された範囲を超えるユースケースに展開される場合、プロトコル設計により制限が生じる可能性があります。
For instance, in an Application-Based Network Operations (ABNO) environment, the application could issue an explicit service request to the network [RFC7491]. In this case, the application would require detailed knowledge about the internal network topology and the actual state. A network configuration would also require a corresponding security solution for authentication and authorization. ALTO is not designed for operations to control, operate, and manage a network.
たとえば、アプリケーションベースのネットワーク操作（ABNO）環境では、アプリケーションはネットワークに明示的なサービス要求を発行できます[RFC7491]。この場合、アプリケーションには、内部ネットワークトポロジと実際の状態に関する詳細な知識が必要です。ネットワーク構成には、認証と承認のための対応するセキュリティソリューションも必要です。 ALTOは、ネットワークを制御、操作、および管理する操作用に設計されていません。
Such deployments could be addressed by network management solutions, e.g., based on SNMP [RFC3411] or NETCONF [RFC6241] and YANG [RFC6020], that are typically designed to manipulate configuration state. [RFC7491] contains a more detailed discussion of interfaces between components such as Element Management System (EMS), Network Management System (NMS), Operational Support System (OSS), Traffic Engineering Database (TED), Label Switched Path Database (LSP-DB), Path Computation Element (PCE), and other Operations, Administration, and Maintenance (OAM) components.
このような展開は、たとえばSNMP [RFC3411]またはNETCONF [RFC6241]およびYANG [RFC6020]に基づくネットワーク管理ソリューションで対処できます。これらは通常、構成状態を操作するように設計されています。 [RFC7491]には、Element Management System（EMS）、Network Management System（NMS）、Operational Support System（OSS）、Traffic Engineering Database（TED）、Label Switched Path Database（LSP-DB）などのコンポーネント間のインターフェースの詳細な説明が含まれています）、パス計算要素（PCE）、およびその他の運用、管理、保守（OAM）コンポーネント。
The specification of the Map Service in the ALTO protocol [RFC7285] is based on the concept of network maps. A network map partitions the network into PIDs that group one or more endpoints (e.g., subnetworks) to a single aggregate. The "costs" between the various PIDs are stored in a cost map. Map-based approaches such as the ALTO Network and Cost Map Service lower the signaling load on the server as maps have to be retrieved only if they change.
ALTOプロトコル[RFC7285]のマップサービスの仕様は、ネットワークマップの概念に基づいています。ネットワークマップは、ネットワークを1つ以上のエンドポイント（サブネットワークなど）を単一の集合体にグループ化するPIDに分割します。さまざまなPID間の「コスト」は、コストマップに格納されます。 ALTO NetworkやCost Map Serviceなどのマップベースのアプローチは、マップが変更された場合にのみマップを取得する必要があるため、サーバーのシグナリング負荷を軽減します。
One main assumption for map-based approaches is that the information provided in these maps is static for a long period of time. This assumption is fine as long as the network operator does not change any parameter, e.g., routing within the network and to the upstream peers, and IP address assignment stays stable (and thus the mapping to the partitions). However, there are several cases where this assumption is not valid:
マップベースのアプローチの主な前提の1つは、これらのマップで提供される情報が長期間にわたって静的であることです。この仮定は、ネットワークオペレーターがネットワーク内やアップストリームピアへのルーティングなどのパラメーターを変更せず、IPアドレスの割り当てが安定している（したがって、パーティションへのマッピング）限り、問題ありません。ただし、この仮定が有効でない場合がいくつかあります。
1. ISPs reallocate IP subnets from time to time.
1. ISPは時々IPサブネットを再割り当てします。
2. ISPs reallocate IP subnets on short notice.
2. ISPはすぐにIPサブネットを再割り当てします。
3. IP prefix blocks may be assigned to a router that serves a variety of access networks.
3. IPプレフィックスブロックは、さまざまなアクセスネットワークを提供するルーターに割り当てることができます。
4. Network costs between IP prefixes may change depending on the ISP's routing and traffic engineering.
4. IPプレフィックス間のネットワークコストは、ISPのルーティングとトラフィックエンジニアリングによって異なります。
These effects can be explained as follows:
これらの影響は次のように説明できます。
Case 1: ISPs may reallocate IP subnets within their infrastructure from time to time, partly to ensure the efficient usage of IPv4 addresses (a scarce resource), and partly to enable efficient route tables within their network routers. The frequency of these "renumbering events" depends on the growth in number of subscribers and the availability of address space within the ISP. As a result, a subscriber's household device could retain an IP address for as short as a few minutes or for months at a time or even longer.
ケース1：ISPは、インフラストラクチャ内でIPサブネットを時々再割り当てすることがあります。これは、一部はIPv4アドレス（希少なリソース）の効率的な使用を保証し、一部はネットワークルーター内の効率的なルートテーブルを有効にするためです。これらの「再番号付けイベント」の頻度は、加入者数の増加とISP内のアドレス空間の可用性に依存します。その結果、加入者の家庭用デバイスは、IPアドレスを一度に数分または数か月間、あるいはそれ以上も保持する可能性があります。
It has been suggested that ISPs providing ALTO services could subdivide their subscribers' devices into different IP subnets (or certain IP address ranges) based on the purchased service tier, as well as based on the location in the network topology. The problem is that this sub-allocation of IP subnets tends to decrease the efficiency of IP address allocation, in particular for IPv4. A growing ISP that needs to maintain high efficiency of IP address utilization may be reluctant to jeopardize their future acquisition of IP address space.
ALTOサービスを提供するISPは、加入者のデバイスを、購入したサービス階層とネットワークトポロジ内の場所に基づいて、異なるIPサブネット（または特定のIPアドレス範囲）に分割できることが示唆されています。問題は、IPサブネットのこのサブ割り当ては、特にIPv4の場合、IPアドレス割り当ての効率を低下させる傾向があることです。 IPアドレスの使用効率を高く維持する必要のある成長しているISPは、IPアドレス空間の将来の獲得を危うくするのをためらう場合があります。
However, this is not an issue for map-based approaches if changes are applied in the order of days.
ただし、変更が日単位で適用される場合、これはマップベースのアプローチの問題ではありません。
Case 2: ISPs can use techniques that allow the reallocation of IP prefixes on very short notice, i.e., within minutes. An IP prefix that has no IP address assignment to a host anymore can be reallocated to areas where there is currently a high demand for IP addresses.
ケース2：ISPは、IPプレフィックスの再割り当てを非常に短い時間で（つまり、数分以内に）許可する手法を使用できます。ホストにIPアドレスが割り当てられなくなったIPプレフィックスは、現在IPアドレスの需要が高いエリアに再割り当てできます。
Case 3: In residential access networks (e.g., DSL, cable), IP prefixes are assigned to broadband gateways, which are the first IP-hop in the access-network between the Customer Premises Equipment (CPE) and the Internet. The access-network between CPE and broadband gateway (called aggregation network) can have varying characteristics (and thus associated costs), but still using the same IP prefix. For instance, one IP address IP1 out of a given CIDR prefix can be assigned to a VDSL access line (e.g., 2 Mbit/s uplink) while another IP address IP2 within the same given CIDR prefix is assigned to a slow ADSL line (e.g., 128 kbit/s uplink). These IP addresses may be assigned on a first come first served basis, i.e., a single IP address out of the same CIDR prefix can change its associated costs quite fast. This may not be an issue with respect to the used upstream provider (thus the cross ISP traffic), but, depending on the capacity of the aggregation network, this may raise to an issue.
ケース3：住宅用アクセスネットワーク（DSL、ケーブルなど）では、ブロードバンドゲートウェイにIPプレフィックスが割り当てられます。ブロードバンドゲートウェイは、顧客宅内機器（CPE）とインターネット間のアクセスネットワークの最初のIPホップです。 CPEとブロードバンドゲートウェイ（アグリゲーションネットワークと呼ばれる）間のアクセスネットワークは、さまざまな特性（および関連するコスト）を持つ可能性がありますが、同じIPプレフィックスを使用します。たとえば、特定のCIDRプレフィックスから1つのIPアドレスIP1をVDSLアクセス回線（たとえば、2 Mbit / sアップリンク）に割り当てることができ、同じ特定のCIDRプレフィックス内の別のIPアドレスIP2は低速のADSL回線（たとえば、 、128 kbit / sアップリンク）。これらのIPアドレスは、先着順で割り当てることができます。つまり、同じCIDRプレフィックスからの単一のIPアドレスは、関連するコストを非常に速く変更できます。これは、使用されているアップストリームプロバイダー（したがって、クロスISPトラフィック）に関する問題ではない可能性がありますが、集約ネットワークの容量によっては、問題が発生する可能性があります。
Case 4: The routing and traffic engineering inside an ISP network, as well as the peering with other autonomous systems, can change dynamically and affect the information exposed by an ALTO server. As a result, cost maps and possibly also network maps can change.
ケース4：ISPネットワーク内のルーティングとトラフィックエンジニアリング、および他の自律システムとのピアリングは、動的に変化し、ALTOサーバーによって公開される情報に影響を与える可能性があります。その結果、コストマップおよび場合によってはネットワークマップも変更される可能性があります。
One solution to deal with map changes is to use incremental ALTO updates [UPDATE-SSE].
マップの変更を処理する1つのソリューションは、ALTOの増分更新を使用することです[UPDATE-SSE]。
The specification of the ALTO protocol [RFC7285] also includes the ECS mechanism. ALTO clients can ask the ALTO server for guidance for specific IP addresses, thereby avoiding the need of processing maps. This can mitigate some of the problems mentioned in the previous section.
ALTOプロトコル[RFC7285]の仕様には、ECSメカニズムも含まれています。 ALTOクライアントは、特定のIPアドレスのガイダンスをALTOサーバーに要求できるため、マップを処理する必要がなくなります。これにより、前のセクションで説明した問題の一部を軽減できます。
However, frequent requests, particularly with long lists of IP addresses, may overload the ALTO server. The server has to rank each received IP address, which causes load at the server. This may be amplified when a large number of ALTO clients are asking for guidance. The results of the ECS are also more difficult to cache than ALTO maps. Therefore, the ALTO client may have to await the server response before starting a communication, which results in an additional delay.
ただし、特にIPアドレスの長いリストでの頻繁な要求は、ALTOサーバーに過負荷をかける可能性があります。サーバーは受信した各IPアドレスをランク付けする必要があるため、サーバーに負荷がかかります。これは、多数のALTOクライアントがガイダンスを求めているときに増幅される可能性があります。 ECSの結果は、ALTOマップよりもキャッシュするのが困難です。したがって、ALTOクライアントは通信を開始する前にサーバーの応答を待たなければならない場合があり、その結果、追加の遅延が発生します。
Caching of IP addresses at the ALTO client or the use of the H12 approach [ALTO-H12] in conjunction with caching may lower the query load on the ALTO server.
ALTOクライアントでのIPアドレスのキャッシュ、またはH12アプローチ[ALTO-H12]をキャッシュと組み合わせて使用すると、ALTOサーバーのクエリ負荷が低下する場合があります。
When an ALTO server receives an ECS request, it may not have the most appropriate topology information in order to accurately determine the ranking. [RFC7285] generally assumes that a server can always offer some guidance. In such a case, the ALTO server could adopt one of the following strategies:
ALTOサーバーがECS要求を受信したとき、ランキングを正確に決定するために、最適なトポロジー情報がない可能性があります。 [RFC7285]は通常、サーバーが常に何らかのガイダンスを提供できると想定しています。このような場合、ALTOサーバーは次のいずれかの方法を採用できます。
o Reply with available information (best effort).
o 利用可能な情報で返信します（ベストエフォート）。
o Query another ALTO server presumed to have better topology information and return that response (cascaded servers).
o より適切なトポロジ情報があると推定される別のALTOサーバーにクエリを実行し、その応答を返します（カスケードサーバー）。
o Redirect the request to another ALTO server presumed to have better topology information (redirection).
o より良いトポロジー情報があると推定される別のALTOサーバーに要求をリダイレクトします（リダイレクト）。
The protocol mechanisms and decision processes that would be used to determine if redirection is necessary and which mode to use is out of the scope of this document, since protocol extensions could be required.
プロトコルの拡張が必要になる可能性があるため、リダイレクトが必要かどうか、およびどのモードを使用するかを決定するために使用されるプロトコルメカニズムと決定プロセスは、このドキュメントの範囲外です。
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 ISP providing ALTO may want to assess the benefits of ALTO as part of the management and operations (cf. [RFC7285]). For instance, the ISP might be interested in understanding whether the provided ALTO maps are effective in order to decide whether an adjustment of the ALTO configuration would be useful. Such insight can be obtained from a monitoring infrastructure. An ISP offering ALTO could consider the impact on (or integration with) traffic engineering and the deployment of a monitoring service to observe the effects of ALTO operations. The measurement of impacts can be challenging because ALTO-enabled applications may not provide related information back to the ALTO service provider.
ALTOは、クライアントに追加情報を提供することにより、ネットワークトラフィックを管理する新しい機会を提供します。特に、ALTOサーバーの展開により、ネットワークトラフィックのパターンが変化する可能性があり、ネットワーク運用への潜在的な影響が大きくなる可能性があります。 ALTOを提供するISPは、管理と運用の一部としてALTOの利点を評価する必要がある場合があります（[RFC7285]を参照）。たとえば、ISPは、ALTO構成の調整が役立つかどうかを判断するために、提供されたALTOマップが有効かどうかを理解することに関心を持つ場合があります。このような洞察は、監視インフラストラクチャから取得できます。 ALTOを提供するISPは、トラフィックエンジニアリングへの影響（または統合）および監視サービスの導入を検討して、ALTO操作の影響を観察できます。 ALTO対応のアプリケーションが関連情報をALTOサービスプロバイダーに提供しない場合があるため、影響の測定は困難な場合があります。
To construct an effective monitoring infrastructure, the ALTO service provider should decide how to monitor the performance of ALTO and identify and deploy data sources to collect data to compute the performance metrics. 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. Monitoring an ALTO service could also be realized by third parties. In this case, insight into ALTO data may require a trust relationship between the monitoring system operator and the network service provider offering an ALTO service.
ALTOサービスプロバイダーは、効果的な監視インフラストラクチャを構築するために、ALTOのパフォーマンスを監視する方法を決定し、データソースを特定および展開してデータを収集し、パフォーマンスメトリックを計算する必要があります。特定の信頼されたデプロイメント環境では、ALTOクライアントから直接情報を収集できる場合があります。また、時間、地理的地域、またはその他の基準によって、ALTOクライアントの一部のALTOガイダンスを変更したり、選択的に無効にしたりして、ALTOがある場合とない場合のネットワークトラフィック特性を比較することもできます。 ALTOサービスの監視は、サードパーティによっても実現できます。この場合、ALTOデータへの洞察には、監視システムのオペレーターと、ALTOサービスを提供するネットワークサービスプロバイダーとの間の信頼関係が必要な場合があります。
The required monitoring depends on the network infrastructure and the use of ALTO, and an exhaustive description is outside the scope of this document.
必要な監視は、ネットワークインフラストラクチャとALTOの使用に依存し、徹底的な説明はこのドキュメントの範囲外です。
ALTO realizes an interface between the network and applications. This implies that an effective monitoring infrastructure may have to deal with both network and application performance metrics. This document does not comprehensively list all performance metrics that could be relevant, nor does it formally specify metrics.
ALTOは、ネットワークとアプリケーション間のインターフェースを実現します。これは、効果的な監視インフラストラクチャがネットワークとアプリケーションの両方のパフォーマンスメトリックを処理する必要があることを意味します。このドキュメントは、関連する可能性のあるすべてのパフォーマンスメトリックを包括的にリストしたものではなく、正式にメトリックを指定したものでもありません。
The impact of ALTO can be classified regarding a number of different criteria:
ALTOの影響は、いくつかの異なる基準に関して分類できます。
o Total amount and distribution of traffic: ALTO enables ISPs to influence and localize traffic of applications that use the ALTO service. Therefore, an ISP may be interested in analyzing the impact on the traffic, i.e., whether network traffic patterns are shifted. For instance, if ALTO shall be used to reduce the inter-domain P2P traffic, it makes sense to evaluate the total amount of inter-domain traffic of an ISP. Then, one possibility is to study how the introduction of ALTO reduces the total inter-domain traffic (inbound and/our outbound). If the ISP's intention is to localize the traffic inside his network, the network-internal traffic distribution will be of interest. Effectiveness of localization can be quantified in different ways, e.g., by the load on core routers and backbone links or by considering more-advanced effects, such as the average number of hops that traffic traverses inside a domain.
o トラフィックの総量と分布：ALTOを使用すると、ISPはALTOサービスを使用するアプリケーションのトラフィックに影響を与えてローカライズできます。したがって、ISPは、トラフィックへの影響、つまりネットワークトラフィックパターンがシフトしたかどうかの分析に関心を持つ可能性があります。たとえば、ALTOを使用してドメイン間P2Pトラフィックを削減する場合、ISPのドメイン間トラフィックの総量を評価することは理にかなっています。次に、ALTOの導入によりドメイン間トラフィック全体（インバウンドおよび/またはアウトバウンド）がどのように減少するかを検討する可能性があります。 ISPの意図が彼のネットワーク内のトラフィックをローカライズすることである場合、ネットワーク内部のトラフィック分散に関心があります。ローカリゼーションの有効性は、さまざまな方法で定量化できます。たとえば、コアルーターとバックボーンリンクの負荷によって、またはドメイン内を通過するトラフィックの平均ホップ数などのより高度な効果を検討することによってです。
o Application performance: The objective of ALTO is to improve application performance. ALTO can be used by very different types of applications, with different communication characteristics and requirements. For instance, if ALTO guidance achieves traffic localization, one would expect that applications achieve a higher throughput and/or smaller delays to retrieve data. If application-specific performance characteristics (e.g., video or audio quality) can be monitored, such metrics related to user experience could also help to analyze the benefit of an ALTO deployment. If available, selected statistics from the TCP/IP stack in hosts could be leveraged, too.
o アプリケーションのパフォーマンス：ALTOの目的は、アプリケーションのパフォーマンスを向上させることです。 ALTOは、通信特性や要件が異なる非常に異なるタイプのアプリケーションで使用できます。たとえば、ALTOガイダンスがトラフィックのローカリゼーションを達成する場合、アプリケーションがデータを取得するために、より高いスループットや小さな遅延を実現することが期待されます。アプリケーション固有のパフォーマンス特性（ビデオやオーディオの品質など）を監視できる場合、ユーザーエクスペリエンスに関連するそのようなメトリックは、ALTO展開の利点の分析にも役立ちます。利用可能な場合は、ホストのTCP / IPスタックから選択した統計も利用できます。
Of potential interest can also be the share of applications or customers that actually use an offered ALTO service, i.e., the adoption of the service.
潜在的に興味深いのは、提供されたALTOサービスを実際に使用するアプリケーションまたは顧客のシェア、つまりサービスの採用です。
Monitoring statistics can be aggregated, averaged, and normalized in different ways. This document does not mandate specific ways how to calculate metrics.
モニタリング統計は、さまざまな方法で集約、平均化、および正規化できます。このドキュメントでは、メトリックの計算方法を具体的に規定していません。
A number of interesting parameters can be measured at the ALTO server. [RFC7285] suggests certain ALTO-specific metrics to be monitored:
ALTOサーバーでは、いくつかの興味深いパラメーターを測定できます。 [RFC7285]は、監視する特定の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マップサイズ（メモリ内サイズ、エンコードされたサイズ、エントリ数）
This data characterizes the workload, the system performance as well as the map data. Obviously, such data will depend on the implementation and the actual deployment of the ALTO service. Logging is also recommended in [RFC7285].
このデータは、ワークロード、システムパフォーマンス、およびマップデータを特徴付けます。明らかに、そのようなデータは、ALTOサービスの実装と実際の展開に依存します。ロギングは[RFC7285]でも推奨されています。
Understanding the impact of ALTO may require interaction between different systems operating at different layers. Some information discussed in the preceding sections is only visible to an ISP, while application-level performance can hardly be measured inside the network. It is possible that not all information of potential interest can directly be measured, either because no corresponding monitoring infrastructure or measurement method exists or because it is not easily accessible.
ALTOの影響を理解するには、異なるレイヤーで動作する異なるシステム間の相互作用が必要になる場合があります。前のセクションで説明した情報の一部はISPにのみ表示されますが、アプリケーションレベルのパフォーマンスはネットワーク内部ではほとんど測定できません。対応する監視インフラストラクチャまたは測定方法が存在しないか、簡単にアクセスできないため、潜在的な関心のあるすべての情報を直接測定できるわけではありません。
One way to quantify the benefit of deploying ALTO is to measure before and after enabling the ALTO service. In addition to passive monitoring, some data could also be obtained by active measurements, but due to the resulting overhead, the latter should be used with care. Yet, in all monitoring activities, an ALTO service provider has to take into account that ALTO clients are not bound to ALTO server guidance as ALTO is only one source of information, and any measurement result may thus be biased.
ALTOを展開する利点を定量化する1つの方法は、ALTOサービスを有効にする前後に測定することです。パッシブモニタリングに加えて、一部のデータはアクティブ測定によっても取得できますが、結果として生じるオーバーヘッドのため、後者は注意して使用する必要があります。ただし、すべての監視アクティビティにおいて、ALTOは情報の1つのソースにすぎないため、ALTOサービスプロバイダーは、ALTOクライアントがALTOサーバーガイダンスに拘束されないことを考慮に入れる必要があり、測定結果にバイアスがかかる可能性があります。
Potential sources for monitoring the use of ALTO include:
ALTOの使用を監視するための潜在的な情報源は次のとおりです。
o Network monitoring and performance management systems: Many ISPs deploy systems to monitor the network traffic, which may have insight into traffic volumes, network topology, bandwidth information inside the management area. Data can be obtained by SNMP, NETCONF, IP Flow Information Export (IPFIX), syslog, etc. On-demand OAM tests (such as Ping or BDF) could also be used.
o ネットワーク監視およびパフォーマンス管理システム：多くのISPは、ネットワークトラフィックを監視するシステムを展開しています。これにより、管理領域内のトラフィック量、ネットワークトポロジ、帯域幅情報を把握できます。 SNMP、NETCONF、IPフロー情報エクスポート（IPFIX）、syslogなどによってデータを取得できます。オンデマンドOAMテスト（PingやBDFなど）を使用することもできます。
o Applications/clients: Relevant data could be obtained by instrumentation of applications.
o アプリケーション/クライアント：関連するデータは、アプリケーションの計測によって取得できます。
o ALTO server: If available, log files or other statistics data could be analyzed.
o ALTOサーバー：利用可能な場合、ログファイルまたはその他の統計データを分析できます。
o Other application entities: In several use cases, there are other application entities that could provide data as well. For instance, there may be centralized log servers that collect data.
o その他のアプリケーションエンティティ：いくつかの使用例では、データを提供できる他のアプリケーションエンティティもあります。たとえば、データを収集する集中ログサーバーが存在する場合があります。
In many ALTO use cases, some data sources are located within an ISP network while some other data is gathered at the application level. Correlation of data could require a collaboration agreement between the ISP and an application owner, including agreements of data interchange formats, methods of delivery, etc. In practice, such a collaboration may not be possible in all use cases of ALTO, because the monitoring data can be sensitive and because the interacting entities may have different priorities. Details of how to build an overarching monitoring system for evaluating the benefits of ALTO are outside the scope of this memo.
多くのALTOの使用例では、一部のデータソースはISPネットワーク内にあり、他のデータはアプリケーションレベルで収集されます。データの相関には、データ交換フォーマット、配信方法などの合意を含む、ISPとアプリケーション所有者の間のコラボレーション合意が必要になる場合があります。実際には、そのようなコラボレーションは、ALTOのすべてのユースケースで可能とは限りません。影響を受けやすいエンティティが異なる優先順位を持つ可能性があるため、敏感になる可能性があります。 ALTOの利点を評価するための包括的な監視システムを構築する方法の詳細は、このメモの範囲外です。
The ALTO protocol does not mandate how to determine costs between endpoints and/or determine map data. In complex usage scenarios, this can be a non-trivial problem. In order to show the basic principle, this and the following sections explain for different deployment scenarios how ALTO maps could be structured.
ALTOプロトコルは、エンドポイント間のコストの決定方法やマップデータの決定方法を義務付けていません。複雑な使用シナリオでは、これは重要な問題になる可能性があります。基本的な原理を示すために、このセクションと次のセクションでは、ALTOマップをどのように構造化できるかをさまざまな展開シナリオについて説明します。
For a small ISP, the inter-domain traffic optimizing problem is how to decrease the traffic exchanged with other ISPs, because of high settlement costs. By using the ALTO service to optimize traffic, a small ISP can define two "optimization areas": one is its own network and the other one consists of all other network destinations. The cost map can be defined as follows: the cost of a link between clients of the inner ISP's network is lower than between clients of the outer ISP's network and clients of inner ISP's network. As a result, a host with an ALTO client inside the network of this ISP will prefer retrieving data from hosts connected to the same ISP.
小規模なISPの場合、ドメイン間トラフィックの最適化の問題は、決済コストが高いため、他のISPと交換されるトラフィックを減らす方法です。 ALTOサービスを使用してトラフィックを最適化することにより、小規模なISPは2つの「最適化領域」を定義できます。1つは独自のネットワークで、もう1つは他のすべてのネットワーク宛先で構成されます。コストマップは次のように定義できます。内部ISPのネットワークのクライアント間のリンクのコストは、外部ISPのネットワークのクライアントと内部ISPのネットワークのクライアント間のリンクよりも低くなります。その結果、このISPのネットワーク内にALTOクライアントを持つホストは、同じISPに接続されているホストからデータを取得することを好みます。
An example is given in Figure 9. It is assumed that ISP A is a small ISP only having one access network. As operator of the ALTO service, ISP A can define its network to be one optimization area, named as PID1, and define other networks to be the other optimization area, named as PID2. C1 is denoted as the cost inside the network of ISP A. C2 is denoted as the cost from PID2 to PID1, and C3 from PID1 to PID2. In the following, C2=C3 is assumed for the sake of simplicity. In order to keep traffic local inside ISP A, it makes sense to define C1<C2.
例を図9に示します。ISPAは、1つのアクセスネットワークしかない小規模ISPであると想定しています。 ISP Aは、ALTOサービスのオペレーターとして、そのネットワークをPID1という名前の1つの最適化エリアとして定義し、他のネットワークをPID2という名前の別の最適化エリアとして定義できます。 C1はISP Aのネットワーク内のコストとして表されます。C2はPID2からPID1へのコストとして表され、C3はPID1からPID2へのコストとして表されます。以下では、簡単にするために、Ｃ２ ＝ Ｃ３と仮定する。 ISP A内のトラフィックをローカルに保つために、C1 <C2を定義することは理にかなっています。
-----------
//// \\\\
// \\
// \\ /-----------\
| +---------+ | //// \\\\
| | ALTO | ISP A | C2 | Other Networks |
| | Service | PID 1 <----------- PID 2
| +---------+ C1 |----------->| |
| | C3 (=C2) \\\\ ////
\\ // \-----------/
\\ //
\\\\ ////
-----------
Figure 9: Example ALTO Deployment for a Small ISP
図9：小規模ISPのALTO配置の例
A simplified extract of the corresponding ALTO network and cost maps is listed in Figures 10 and 11, assuming that the network of ISP A has the IPv4 address ranges 192.0.2.0/24 and 198.51.100.0/25, as well as the IPv6 address range 2001:db8:100::/48. In this example, the cost values C1 and C2 can be set to any number C1<C2.
ISP AのネットワークにIPv4アドレス範囲192.0.2.0/24と198.51.100.0/25があり、IPv6アドレス範囲があると仮定すると、対応するALTOネットワークとコストマップの簡単な抜粋を図10と11に示します。 2001：db8：100 :: / 48。この例では、コスト値C1およびC2は、C1 <C2の任意の数に設定できます。
HTTP/1.1 200 OK ... Content-Type: application/alto-networkmap+json
HTTP / 1.1 200 OK ... Content-Type：application / alto-networkmap + json
{
...
"network-map" : {
"PID1" : {
"ipv4" : [
"192.0.2.0/24",
"198.51.100.0/25"
],
"ipv6" : [
"2001:db8:100::/48"
]
},
"PID2" : {
"ipv4" : [
"0.0.0.0/0"
],
"ipv6" : [
"::/0"
]
}
}
}
Figure 10: Example ALTO Network Map
図10：ALTOネットワークマップの例
HTTP/1.1 200 OK ... Content-Type: application/alto-costmap+json
HTTP / 1.1 200 OK ... Content-Type：application / alto-costmap + json
{
...
"cost-type" : {"cost-mode" : "numerical",
"cost-metric": "routingcost"
}
},
"cost-map" : {
"PID1": { "PID1": C1, "PID2": C2 },
"PID2": { "PID1": C2, "PID2": 0 },
}
}
Figure 11: Example ALTO Cost Map
図11：ALTOコストマップの例
This example discusses a P2P application traffic optimization use case for a larger ISP with a fixed network comprising several access networks and a core network. The traffic optimizing objectives include (1) using the backbone network efficiently, (2) adjusting the traffic balance in different access networks according to traffic conditions and management policies, and (3) achieving a reduction of settlement costs with other ISPs.
この例では、複数のアクセスネットワークとコアネットワークで構成される固定ネットワークを持つ大規模ISPのP2Pアプリケーショントラフィック最適化の使用例について説明します。トラフィックを最適化する目的には、（1）バックボーンネットワークを効率的に使用する、（2）トラフィックの状態と管理ポリシーに従って異なるアクセスネットワークのトラフィックバランスを調整する、（3）他のISPとの決済コストを削減する、などがあります。
Such a large ISP deploying an ALTO service may want to optimize its traffic according to the network topology of its access networks. For example, each access network could be defined to be one optimization area, i.e., traffic should be kept local withing that area if possible. This can be achieved by mapping each area to a PID. Then, the costs between those access networks can be defined according to a corresponding traffic optimizing requirement by this ISP. One example setup is further described below and also shown in Figure 12.
ALTOサービスを展開するこのような大規模なISPは、そのアクセスネットワークのネットワークトポロジに従ってトラフィックを最適化したい場合があります。たとえば、各アクセスネットワークを1つの最適化エリアとして定義することができます。つまり、可能であれば、トラフィックをそのエリア内でローカルに維持する必要があります。これは、各領域をPIDにマッピングすることで実現できます。次に、これらのアクセスネットワーク間のコストは、このISPによる対応するトラフィック最適化要件に従って定義できます。設定例の1つを以下でさらに説明し、図12にも示します。
In this example, ISP A has one backbone network and three access networks, named as AN A, AN B, and AN C. A P2P application is used in this example. For a reasonable application-level traffic optimization, the first requirement could be a decrease of the P2P traffic on the backbone network inside the AS of ISP A and the second requirement could be a decrease of the P2P traffic to other ISPs, i.e., other ASes. The second requirement can be assumed to have priority over the first one. Also, we assume that the settlement rate with ISP B is lower than with other ISPs. ISP A can deploy an ALTO service to meet these traffic distribution requirements. In the following, we will give an example of an ALTO setting and configuration according to these requirements.
この例では、ISP Aには1つのバックボーンネットワークと、AN A、AN B、AN Cという名前の3つのアクセスネットワークがあります。この例ではP2Pアプリケーションが使用されています。適切なアプリケーションレベルのトラフィック最適化の場合、最初の要件はISP AのAS内のバックボーンネットワーク上のP2Pトラフィックの減少であり、2番目の要件は他のISP、つまり他のASへのP2Pトラフィックの減少です。 。 2番目の要件は、最初の要件よりも優先されると想定できます。また、ISP Bの決済レートは他のISPよりも低いと想定しています。 ISP Aは、これらのトラフィック分散要件を満たすためにALTOサービスを展開できます。以下では、これらの要件に応じたALTOの設定と構成の例を示します。
In the network of ISP A, the operator of the ALTO server can define each access network to be one optimization area, and assign one PID to each access network, such as PID 1, PID 2, and PID 3. Because of different peerings with different outer ISPs, one can define ISP B to be one additional optimization area and assign PID 4 to it. All other networks can be added to a PID to be one further optimization area (PID 5).
ISP Aのネットワークでは、ALTOサーバーのオペレーターは、各アクセスネットワークを1つの最適化領域として定義し、PID 1、PID 2、PID 3などの各アクセスネットワークに1つのPIDを割り当てることができます。異なる外部ISPの場合、ISP Bを1つの追加の最適化領域として定義し、それにPID 4を割り当てることができます。他のすべてのネットワークをPIDに追加して、さらに1つの最適化領域（PID 5）にすることができます。
In the setup, costs (C1, C2, C3, C4, C5, C6, C7, C8) can be assigned as shown in Figure 12. Cost C1 is denoted as the link cost in inner AN A (PID 1), and C2 and C3 are defined accordingly. C4 is denoted as the link cost from PID 1 to PID 2, and C5 is the corresponding cost from PID 3, which is assumed to have a similar value. C6 is the cost between PID 1 and PID 3. For simplicity, this scenario assumes symmetrical costs between the AN this example. C7 is denoted as the link cost from the ISP B to ISP A. C8 is the link cost from other networks to ISP A.
セットアップでは、図12に示すように、コスト（C1、C2、C3、C4、C5、C6、C7、C8）を割り当てることができます。コストC1は、内部AN A（PID 1）のリンクコストとして示され、C2とC3はそれに応じて定義されます。 C4はPID 1からPID 2へのリンクコストとして示され、C5はPID 3からの対応するコストで、同様の値を持つと想定されています。 C6は、PID 1とPID 3の間のコストです。簡単にするために、このシナリオでは、AN間で対称的なコストを想定しています。 C7は、ISP BからISP Aへのリンクコストとして表されます。C8は、他のネットワークからISP Aへのリンクコストです。
According to previous discussion of the first requirement and the second requirement, the relationship of these costs will be defined as: (C1, C2, C3) < (C4, C5, C6) < (C7) < (C8)
最初の要件と2番目の要件の以前の説明によれば、これらのコストの関係は次のように定義されます：（C1、C2、C3）<（C4、C5、C6）<（C7）<（C8）
+------------------------------------+ +----------------+
| ISP A +---------------+ | | |
| | Backbone | | C7 | ISP B |
| +---+ Network +----+ |<--------+ PID 4 |
| | +-------+-------+ | | | |
| | | | | | |
| | | | | +----------------+
| +---+--+ +--+---+ +--+---+ |
| |AN A | C4 |AN B | C5 |AN C | |
| |PID 1 +<--->|PID 2 |<--->+PID 3 | |
| |C1 | |C2 | |C3 | | +----------------+
| +---+--+ +------+ +--+---+ | | |
| ^ ^ | C8 | Other Networks |
| | | |<--------+ PID 5 |
| +------------------------+ | | |
| C6 | | |
+------------------------------------+ +----------------+
Figure 12: ALTO Deployment in Large ISPs with Layered Fixed-Network Structures
図12：固定ネットワーク構造が階層化された大規模ISPでのALTOの展開
An ISP with both mobile network and fixed network may focus on optimizing the mobile traffic by keeping traffic in the fixed network as much as possible, because wireless bandwidth is a scarce resource and traffic is costly in mobile network. In such a case, the main requirement of traffic optimization could be decreasing the usage of radio resources in the mobile network. An ALTO service can be deployed to meet these needs.
モバイルネットワークと固定ネットワークの両方を備えたISPは、無線帯域幅が乏しいリソースであり、トラフィックはモバイルネットワークでコストがかかるため、固定ネットワークのトラフィックを可能な限り維持することにより、モバイルトラフィックの最適化に重点を置くことがあります。このような場合、トラフィック最適化の主な要件は、モバイルネットワークでの無線リソースの使用を減らすことです。これらのニーズを満たすために、ALTOサービスを展開できます。
Figure 13 shows an example: ISP A operates one mobile network, which is connected to a backbone network. The ISP also runs two fixed-access networks AN A and AN B, which are also connected to the backbone network. In this network structure, the mobile network can be defined as one optimization area, and PID 1 can be assigned to it. Access networks AN A and B can also be defined as optimization areas, and PID 2 and PID 3 can be assigned, respectively. The cost values are then defined as shown in Figure 13.
図13に例を示します。ISPAは、バックボーンネットワークに接続されている1つのモバイルネットワークを運用しています。また、ISPは、バックボーンネットワークに接続されている2つの固定アクセスネットワークAN AおよびAN Bも実行しています。このネットワーク構造では、モバイルネットワークを1つの最適化エリアとして定義し、それにPID 1を割り当てることができます。アクセスネットワークAN AおよびBも最適化領域として定義でき、PID 2およびPID 3をそれぞれ割り当てることができます。次に、図13に示すように、コスト値が定義されます。
To decrease the usage of wireless link, the relationship of these costs can be defined as follows:
ワイヤレスリンクの使用を減らすために、これらのコストの関係を次のように定義できます。
From view of mobile network: C4 < C1 and C4 = C8. This means that clients in mobile network requiring data resources from other clients will prefer clients in AN A or B to clients in the mobile network. This policy can decrease the usage of wireless link and power consumption in terminals.
モバイルネットワークの観点から：C4 <C1およびC4 = C8。つまり、他のクライアントからのデータリソースを必要とするモバイルネットワークのクライアントは、モバイルネットワークのクライアントよりもAN AまたはBのクライアントを優先します。このポリシーは、無線リンクの使用と端末の電力消費を減らすことができます。
From view of AN A: C2 < C6, C5 = maximum cost. This means that clients in other optimization area will avoid retrieving data from the mobile network.
AN Aの観点から：C2 <C6、C5 =最大コスト。つまり、他の最適化領域のクライアントは、モバイルネットワークからのデータの取得を回避します。
From view of AN B: Analog to the view of AN A, C3 < C8 and C9 = maximum cost.
AN Bの視点から：AN Aの視点に類似、C3 <C8およびC9 =最大コスト。
+-----------------------------------------------------------------+
| |
| ISP A +-------------+ |
| +--------+ ALTO +---------+ |
| | | Service | | |
| | +------+------+ | |
| | | | |
| | | | |
| | | | |
| +-------+-------+ | C6 +--------+------+ |
| | AN A |<--------------| AN B | |
| | PID 2 | C7 | | PID 3 | |
| | C2 |-------------->| C3 | |
| +---------------+ | +---------------+ |
| ^ | | | ^ |
| | | | | | |
| | | C4 | C8 | | |
| C5 | | | | | C9 |
| | | +--------+---------+ | | |
| | +-->| Mobile Network |<---+ | |
| | | PID 1 | | |
| +------- | C1 |----------+ |
| +------------------+ |
+-----------------------------------------------------------------+
Figure 13: ALTO Deployment in ISPs with Mobile Network
図13：モバイルネットワークを使用するISPでのALTOの展開
These examples show that for ALTO in particular the relationships between different costs matter; the operator of the server has several degrees of freedom how to set the absolute values.
これらの例は、ALTOの場合、特に異なるコスト間の関係が重要であることを示しています。サーバーのオペレーターは、絶対値を設定する方法にいくつかの自由度があります。
In addition to the previous, abstract examples, this section presents a more detailed scenario with a realistic IGP and BGP routing protocol configuration. This example was first described in [MAP-CALC].
前の抽象的な例に加えて、このセクションでは、現実的なIGPおよびBGPルーティングプロトコル構成を使用したより詳細なシナリオを示します。この例は、[MAP-CALC]で最初に説明されました。
Figure 14 depicts a network that is used to explain the steps carried
out in the course of this example. The network consists of nine
routers (R1 to R9). Two of them are border routers (R1 + R8)
connected to neighbored networks (AS 2 to AS 4). Furthermore, AS 4
is not directly connected to the local network, but has AS 3 as
transit network. The links between the routers are point-to-point
connections. These connections also form the core network with the
2001:db8:1:0::/56 prefix. This prefix is large enough to provide
addresses for all router interconnections. In addition to the core
network, the local network also has five client networks attached to
five different routers (R2, R5, R6, R7 and R9). Each client network
has a /56 prefix with 2001:db8:1:x00:: (x = [1..5]) as network
address.
+-------------------+ +-----+ +-----+ +-------------------+
|2001:db8:1:200::/56+----+ R6 | | R7 +----+2001:db8:1:300::/56|
+-------------------+ +--+--+ +--+--+ +-------------------+
| |
+---------------+ | |
| AS 2 | | |
|2001:db8:2::/48| | 10 | 10
+------------+--+ | |
| | |
| | |
+--+--+ 15 +--+--+ +--+--+ +-------------------+
| R1 +--------+ R3 +----+ R5 |----+2001:db8:1:400::/56|
+--+--+ +--+--+ 5 +--+--+ +-------------------+
| \ / | |
| \ / 15 | |
| \ / | | +---------------+
| \/ | | | AS 4 |
| 20 /\ | 5 | 10 |2001:db8:4::/48|
| / \ | | +-------+-------+
| / \ 20 | | |
| / \ | | |
+--+--+ +--+--+ +--+--+ +-------+-------+
| R2 | | R4 | | R8 +--------+ AS 3 |
+--+--+ +--+--+ +--+--+ |2001:db8:3::/48|
| | | +---------------+
| | | 10
| | 20 |
+------------+------+ | +--+--+ +-------------------+
|2001:db8:1:100::/56| +-------+ R9 +----+2001:db8:1:500::/56|
+-------------------+ +-----+ +-------------------+
Figure 14: Example Network
図14：ネットワークの例
The example network utilizes two different routing protocols, one for IGP and another for EGP routing. The used IGP is a link-state protocol such as IS-IS. The applied link weights are annotated in the graph and additionally shown in Figure 15. All links are bidirectional and their weights are symmetric. To obtain the topology and routing information from the network, the topology data source must be connected directly to one of the routers (R1...R9). Furthermore, the topology data source must be enabled to communicate with the router and vice versa.
サンプルネットワークでは、IGP用とEGPルーティング用の2つの異なるルーティングプロトコルを使用しています。使用されるIGPは、IS-ISなどのリンクステートプロトコルです。適用されたリンクの重みはグラフで注釈が付けられ、さらに図15に表示されます。すべてのリンクは双方向であり、それらの重みは対称です。ネットワークからトポロジとルーティング情報を取得するには、トポロジデータソースをルーター（R1 ... R9）の1つに直接接続する必要があります。さらに、トポロジデータソースがルーターと通信できるようにする必要があり、その逆も可能です。
The BGP is used in this scenario to route between autonomous systems. External BGP is running on the two border routers R1 and R8. Furthermore, internal BGP is used to propagate external as well as internal prefixes within the network boundaries; it is running on every router with an attached client network (R2, R5, R6, R7 and R9).
このシナリオでは、BGPを使用して自律システム間をルーティングします。外部BGPは、2つの境界ルータR1とR8で実行されています。さらに、内部BGPは、ネットワーク境界内で外部プレフィックスと内部プレフィックスを伝播するために使用されます。クライアントネットワーク（R2、R5、R6、R7、R9）が接続されているすべてのルーターで実行されています。
Since no route reflector is present it is necessary to fetch routes from each BGP router separately.
ルートリフレクターが存在しないため、各BGPルーターから個別にルートをフェッチする必要があります。
R1 R2 R3 R4 R5 R6 R7 R8 R9
R1 0 15 15 20 - - - - -
R2 15 0 20 - - - - - -
R3 15 20 0 5 5 10 - - -
R4 20 - 5 0 5 - - - 20
R5 - - 5 5 0 - 10 10 -
R6 - - 10 - - 0 - - -
R7 - - - - 10 - 0 - -
R8 - - - - 10 - - 0 10
R9 - - - 20 - - - 10 0
Figure 15: Example Network Link Weights
図15：ネットワークリンクの重みの例
For monitoring purposes, it is possible to enable, e.g., SNMP or NETCONF on the routers within the network. This way an ALTO server may obtain several additional information about the state of the network. For example, utilization, latency, and bandwidth information could be retrieved periodically from the network components to get and keep an up-to-date view on the network situation.
監視を目的として、ネットワーク内のルーターでSNMPやNETCONFなどを有効にすることができます。このようにして、ALTOサーバーはネットワークの状態に関するいくつかの追加情報を取得できます。たとえば、使用率、レイテンシ、帯域幅の情報をネットワークコンポーネントから定期的に取得して、ネットワーク状況の最新のビューを取得および保持できます。
In the following, it is assumed that the listed attributes are collected from the network:
以下では、リストされた属性がネットワークから収集されると想定しています。
o IS-IS: topology, link weights
o IS-IS：トポロジ、リンクの重み
o BGP: prefixes, AS numbers, AS distances, or other BGP metrics
o BGP：プレフィックス、AS番号、AS距離、またはその他のBGPメトリック
o SNMP: latency, utilization, bandwidth
o SNMP：待ち時間、使用率、帯域幅
Due to the variety of data sources available in a network, it may be necessary to aggregate the information and define a suitable data model that can hold the information efficiently and easily accessible. One potential model is an annotated directed graph that represents the topology. The attributes can be annotated at the corresponding positions in the graph. The following shows how such a topology graph could describe the example topology.
ネットワークではさまざまなデータソースを利用できるため、情報を集約し、情報を効率的かつ簡単にアクセスできる適切なデータモデルを定義する必要がある場合があります。考えられるモデルの1つは、トポロジを表す注釈付き有向グラフです。属性は、グラフの対応する位置に注釈を付けることができます。以下は、このようなトポロジグラフがトポロジの例をどのように説明できるかを示しています。
In the topology graph, a node represents a router in the network, while the edges stand for the links that connect the routers. Both routers and links have a set of attributes that store information gathered from the network.
トポロジグラフでは、ノードはネットワーク内のルーターを表し、エッジはルーターを接続するリンクを表します。ルーターとリンクの両方に、ネットワークから収集した情報を格納する一連の属性があります。
Each router could be associated with a basic set of information, such as:
各ルーターは、次のような基本的な情報に関連付けることができます。
o ID: Unique ID within the network to identify the router.
o ID：ルーターを識別するためのネットワーク内の一意のID。
o Neighbor IDs: List of directly connected routers.
o ネイバーID：直接接続されたルーターのリスト。
o Endpoints: List of connected endpoints. The endpoints may also have further attributes themselves depending on the network and address type. Such potential attributes are costs for reaching the endpoint from the router, AS numbers, or AS distances.
o エンドポイント：接続されているエンドポイントのリスト。エンドポイントは、ネットワークとアドレスのタイプに応じて、それ自体がさらに属性を持つこともあります。そのような潜在的な属性は、ルーター、AS番号、またはAS距離からエンドポイントに到達するためのコストです。
In addition to the basic set, many more attributes may be assigned to router nodes. This mainly depends on the utilized data sources. Examples for such additional attributes are geographic location, host name and/or interface types, just to name a few.
基本セットに加えて、より多くの属性をルーターノードに割り当てることができます。これは主に、使用するデータソースによって異なります。そのような追加の属性の例としては、地理的な場所、ホスト名、インターフェースタイプなどがあります。
The example network shown in Figure 14 represents such an internal network graph where the routers R1 to R9 represent the nodes and the connections between them are the links. For instance, R2 has one directly attached IPv6 endpoint that belongs to its own AS, as shown in Figure 16.
図14に示すネットワークの例は、ルーターR1からR9がノードを表し、それらの間の接続がリンクであるような内部ネットワークのグラフを表しています。たとえば、図16に示すように、R2には、独自のASに属する1つの直接接続されたIPv6エンドポイントがあります。
ID: 2
ID：2
Neighbor IDs: 1,3 (R1, R3)
ネイバーID：1,3（R1、R3）
Endpoints:
エンドポイント：
Endpoint: 2001:db8:1:100::/56
Weight: 10 (e.g., the default IGP metric value)
重み：10（たとえば、デフォルトのIGPメトリック値）
ASNumber: 1 (our own AS)
ASNumber：1（私たち自身のAS）
ASDistance: 0
ASSistance：0
Host Name: R2
ホスト名：R2
Figure 16: Example Router R2
図16：ルーターR2の例
Router R8 has two attached IPv6 endpoints, as explained in Figure 17. The first one belongs to a directly neighbored AS with AS number 3. The AS distance from our network to AS3 is 1. The second endpoint belongs to an AS (AS4) that is no direct neighbor but directly connected to AS3. To reach endpoints in AS4, it is necessary to cross AS3, which increases the AS distance by one.
図17で説明するように、ルーターR8には2つのIPv6エンドポイントが接続されています。最初のエンドポイントは、AS番号3の直接隣接するASに属しています。ネットワークからAS3へのAS距離は1です。直接の隣接ではなく、AS3に直接接続されています。 AS4のエンドポイントに到達するには、AS3を通過する必要があります。これにより、AS距離が1つ増加します。
ID: 8
商品ID：8
Neighbor IDs: 5,9 (R5, R9)
ネイバーID：5,9（R5、R9）
Endpoints:
エンドポイント：
Endpoint: 2001:db8:3::/48
Weight: 100
重量：100
ASNumber: 3
AS番号：3
ASDistance: 1
ASSistance：1
Endpoint: 2001:db8:4::/48
Weight: 200
重量：200
ASNumber: 4
AS番号：4
ASDistance: 2
ASSistance：2
Host Name: R8
ホスト名：R8
Figure 17: Example Router R8
図17：ルーターR8の例
A potential set of attributes for a link is described in the following list:
リンクの潜在的な属性のセットは、次のリストで説明されています。
o Source ID: ID of the source router of the link.
o 送信元ID：リンクの送信元ルーターのID。
o Destination ID: ID of the destination router of the link.
o 宛先ID：リンクの宛先ルーターのID。
o Weight: The cost to cross the link, e.g., defined by the used IGP.
o 重み：リンクを通過するためのコスト。たとえば、使用されたIGPによって定義されます。
Additional attributes that provide technical details and state information can be assigned to links as well. The availability of such additional attributes depends on the utilized data sources. Such attributes can be characteristics like maximum bandwidth, utilization, or latency on the link as well as the link type.
技術的な詳細と状態情報を提供する追加の属性もリンクに割り当てることができます。そのような追加の属性を利用できるかどうかは、使用するデータソースによって異なります。このような属性には、リンクのタイプだけでなく、リンクの最大帯域幅、使用率、遅延などの特性があります。
In the example, the link attributes are equal for all links and only their values differ. It is assumed that the attributes utilization, bandwidth, and latency are collected, e.g., via SNMP or NETCONF. In the topology of Figure 14, the links between R1 and R2 would then have the following link attributes explained in Figure 18:
この例では、リンク属性はすべてのリンクで等しく、それらの値のみが異なります。属性の使用率、帯域幅、および待機時間は、SNMPやNETCONFなどを介して収集されると想定されています。図14のトポロジでは、R1とR2の間のリンクは、図18で説明する次のリンク属性を持ちます。
R1->R2:
R1-> R2：
Source ID: 1
ソースID：1
Destination ID: 2
宛先ID：2
Weight: 15
重量：15
Bandwidth: 10 Gbit/s
帯域幅：10 Gbit / s
Utilization: 0.1
使用率：0.1
Latency: 2 ms
待ち時間：2 ms
R2->R1:
R2-> R1：
Source ID: 2
ソースID：2
Destination ID: 1
宛先ID：1
Weight: 15
重量：15
Bandwidth: 10 Gbit/s
帯域幅：10 Gbit / s
Utilization: 0.55
使用率：0.55
Latency: 5 ms
待ち時間：5 ms
Figure 18: Link Attributes
図18：リンク属性
It has to be emphasized that values for utilization and latency can be very volatile.
使用率とレイテンシの値は非常に不安定になる可能性があることを強調する必要があります。
The goal of the ALTO map calculation process is to get from the graph representation of the network to a coarser-grained and abstract matrix representation. The first step is to generate the network map. Only after the network map has been generated is it possible to compute the cost map since it relies on the network map.
ALTOマップ計算プロセスの目標は、ネットワークのグラフ表現から、より粗い抽象マトリックス表現に移行することです。最初のステップは、ネットワークマップを生成することです。ネットワークマップに依存しているため、ネットワークマップが生成されて初めて、コストマップを計算できます。
To generate an ALTO network map, a grouping function is required. A grouping function processes information from the network graph to group endpoints into PIDs. The way of grouping is manifold and algorithms can utilize any information provided by the network graph to perform the grouping. The functions may omit certain endpoints in order to simplify the map or in order to hide details about the network that are not intended to be published in the resulting ALTO network map.
ALTOネットワークマップを生成するには、グループ化機能が必要です。グループ化機能は、ネットワークグラフからの情報を処理して、エンドポイントをPIDにグループ化します。グループ化の方法は多様であり、アルゴリズムはネットワークグラフによって提供される情報を利用してグループ化を実行できます。関数は、マップを簡略化するため、または結果のALTOネットワークマップで公開することを意図していないネットワークに関する詳細を非表示にするために、特定のエンドポイントを省略する場合があります。
For IP endpoints, which are either an IP (version 4 or version 6) address or prefix, [RFC7285] requires the use of a longest-prefix matching algorithm to map IPs to PIDs. This requirement results in the constraints that every IP must be mapped to a PID and the same prefix or address not be mapped to more than one PID. To meet the first constraint, every calculated map must provide a default PID that contains the prefixes 0.0.0.0/0 for IPv4 and ::/0 for IPv6. Both prefixes cover their entire address space, and if no other PID matches an IP endpoint, the default PID will. The second constraint must be met by the grouping function that assigns endpoints to PIDs. In case of collision, the grouping function must decide to which PID an endpoint is assigned. These or other constraints may apply to other endpoint types depending on the used matching algorithm.
IP（バージョン4またはバージョン6）アドレスまたはプレフィックスであるIPエンドポイントの場合、[RFC7285]では、IPをPIDにマップするために最長プレフィックスマッチングアルゴリズムを使用する必要があります。この要件により、すべてのIPがPIDにマッピングされ、同じプレフィックスまたはアドレスが複数のPIDにマッピングされないという制約が生じます。最初の制約を満たすために、計算されたすべてのマップは、IPv4の場合はプレフィックス0.0.0.0/0、IPv6の場合は:: / 0を含むデフォルトのPIDを提供する必要があります。どちらのプレフィックスもアドレス空間全体をカバーします。他のPIDがIPエンドポイントと一致しない場合、デフォルトのPIDが一致します。 2番目の制約は、エンドポイントをPIDに割り当てるグループ化関数によって満たされる必要があります。衝突が発生した場合、グループ化機能は、エンドポイントを割り当てるPIDを決定する必要があります。これらまたは他の制約は、使用されるマッチングアルゴリズムに応じて、他のエンドポイントタイプに適用される場合があります。
A simple example for such grouping is to compose PIDs by host names. For instance, each router's host name is selected as the name for a PID and the attached endpoints are the member endpoints of the corresponding PID. Additionally, backbone prefixes should not appear in the map so they are filtered out. The following table in Figure 19 shows the resulting ALTO network map, using the network in Figure 14 as example:
このようなグループ化の簡単な例は、ホスト名でPIDを作成することです。たとえば、各ルーターのホスト名がPIDの名前として選択され、接続されているエンドポイントは対応するPIDのメンバーエンドポイントです。さらに、バックボーンプレフィックスはマップに表示されないため、除外されます。図19の次の表は、図14のネットワークを例として使用して、結果のALTOネットワークマップを示しています。
PID | Endpoints
---------+-----------------------------------
R1 | 2001:db8:2::/48
R2 | 2001:db8:1:100::/56
R5 | 2001:db8:1:400::/56
R6 | 2001:db8:1:200::/56
R7 | 2001:db8:1:300::/56
R8 | 2001:db8:3::/48, 2001:db8:4::/48
R9 | 2001:db8:1:500::/56
default | 0.0.0.0/0, ::/0
Figure 19: Example ALTO Network Map
図19：ALTOネットワークマップの例
Since router R3 and R4 have no endpoints assigned, they are not represented in the network map. Furthermore, as previously mentioned, the "default" PID was added to represent all endpoints that are not part of the example network.
ルータR3とR4にはエンドポイントが割り当てられていないため、ネットワークマップには表示されません。さらに、前述のように、サンプルネットワークの一部ではないすべてのエンドポイントを表す「デフォルト」PIDが追加されました。
After successfully creating the network map, the typical next step is to calculate the costs between the generated PIDs, which form the cost map. Those costs are calculated by cost functions. A cost function may calculate unidirectional values, which means it is necessary to compute the costs from every PID to every PID. In general, it is possible to use all available information in the network graph to compute the costs. In case a PID contains more than one IP address or prefix, the cost function may first calculate a set of cost values for each source/destination IP pair. In that case, a tiebreaker function is required to decide the resulting cost value, as [RFC7285] allows one cost value only between two PIDs. Such a tiebreaker can be a simple function such as minimum, maximum, or average value.
ネットワークマップを正常に作成した後の一般的な次のステップは、コストマップを形成する、生成されたPID間のコストを計算することです。これらのコストは、コスト関数によって計算されます。コスト関数は一方向の値を計算する場合があります。つまり、すべてのPIDからすべてのPIDまでのコストを計算する必要があります。一般に、ネットワークグラフで利用可能なすべての情報を使用してコストを計算することができます。 PIDに複数のIPアドレスまたはプレフィックスが含まれている場合、コスト関数は最初に各ソース/宛先IPペアのコスト値のセットを計算します。その場合、[RFC7285]は2つのPIDの間でのみ1つのコスト値を許可するため、結果のコスト値を決定するためにタイブレーカー関数が必要です。このようなタイブレーカーは、最小値、最大値、平均値などの単純な関数にすることができます。
No matter what metric the cost function uses, the path from source to destination is usually defined by the path with minimum weight. When the link weight is represented by an additive metric, the path weight is the sum of link weights of all traversed links. The path may be determined, for instance, with the Bellman-Ford or Dijkstra algorithms. The latter progressively builds the shortest path in terms of cumulated link lengths. In our example, the link lengths are link weights with values illustrated in Figure 15. Hence, the cost function generally extracts the optimal path with respect to a chosen metric, such as the IGP link weight. It is also possible that more than one path with the same minimum weight exists, which means it is not entirely clear which path is going to be selected by the network. Hence, a tiebreaker similar to the one used to resolve costs for PIDs with multiple endpoints is necessary.
コスト関数が使用するメトリックに関係なく、ソースから宛先へのパスは通常、最小の重みを持つパスによって定義されます。リンクの重みが付加的なメトリックによって表される場合、パスの重みは、通過したすべてのリンクのリンクの重みの合計です。経路は、例えば、ベルマン・フォードまたはダイクストラのアルゴリズムを用いて決定することができる。後者は、累積されたリンク長の点で最短経路を徐々に構築します。この例では、リンクの長さは図15に示す値を持つリンクの重みです。したがって、コスト関数は一般に、IGPリンクの重みなど、選択したメトリックに関して最適なパスを抽出します。同じ最小の重みを持つ複数のパスが存在する可能性もあります。つまり、どのパスがネットワークによって選択されるのかが完全に明確ではありません。したがって、複数のエンドポイントを持つPIDのコストを解決するために使用されるものと同様のタイブレーカーが必要です。
An important note is that [RFC7285] does not require cost maps to provide costs for every PID pair, so if no path cost can be calculated for a certain pair, the corresponding field in the cost map is left out. Administrators may also not want to provide cost values for some PID pairs due to various reasons. Such pairs may be defined before the cost calculation is performed.
重要な注意事項は、[RFC7285]がすべてのPIDペアのコストを提供するためにコストマップを必要としないため、特定のペアのパスコストを計算できない場合、コストマップの対応するフィールドは省略されます。管理者は、さまざまな理由により、一部のPIDペアにコスト値を提供したくない場合もあります。このようなペアは、コスト計算を実行する前に定義できます。
Based on the network map example shown in the previous section, it is possible to calculate the cost maps. Figure 20 provides an example where the selected metric for the cost map is the minimum number of hops necessary to get from the endpoints in the source PID to endpoints in the destination PID. Our chosen tiebreaker selects the minimum hop count when more than one value is returned by the cost function.
前のセクションで示したネットワークマップの例に基づいて、コストマップを計算できます。図20は、コストマップの選択されたメトリックが、送信元PIDのエンドポイントから宛先PIDのエンドポイントに到達するために必要なホップの最小数である例を示しています。選択したタイブレーカーは、コスト関数から複数の値が返されたときに最小ホップカウントを選択します。
PID | default | R1 | R2 | R5 | R6 | R7 | R8 | R9 |
--------+---------+-----+-----+-----+-----+-----+-----+-----|
default | x | x | x | x | x | x | x | x |
R1 | x | 0 | 2 | 3 | 3 | 4 | 4 | 3 |
R2 | x | 2 | 0 | 3 | 3 | 4 | 4 | 4 |
R5 | x | 3 | 3 | 0 | 3 | 2 | 2 | 3 |
R6 | x | 3 | 3 | 3 | 0 | 4 | 4 | 4 |
R7 | x | 4 | 4 | 2 | 4 | 0 | 3 | 4 |
R8 | x | 4 | 4 | 2 | 4 | 3 | 0 | 2 |
R9 | x | 3 | 4 | 3 | 4 | 4 | 2 | 0 |
Figure 20: Example ALTO Hop Count Cost Map
図20：ALTOホップカウントコストマップの例
It should be mentioned that R1->R9 has several paths with equal path weights. The paths R1->R3->R5->R8->R9, R1->R3->R4->R9, and R1->R4->R9 all have a path weight of 40. Due to the minimum hop count value tiebreaker, 3 hops is chosen as value for the path R1->R4->R9. Furthermore, since the "default" PID is, in a sense, a virtual PID with no endpoints that are part of the example network, no cost values are calculated for other PIDs from or towards it.
R1-> R9には、パスの重みが等しい複数のパスがあることに注意してください。パスR1-> R3-> R5-> R8-> R9、R1-> R3-> R4-> R9、およびR1-> R4-> R9のパスの重みはすべて40です。最小ホップカウント値のため、タイブレーカー、3ホップがパスR1-> R4-> R9の値として選択されます。さらに、「デフォルト」のPIDは、ある意味では、サンプルネットワークの一部であるエンドポイントのない仮想PIDであるため、そこからまたはそれに向かう他のPIDのコスト値は計算されません。
There are multiple interoperable implementations of the ALTO protocol. Some experiences in implementing and using ALTO for large-scale networks have been documented in [MAP-CALC] and are here summarized:
ALTOプロトコルには複数の相互運用可能な実装があります。大規模ネットワーク用のALTOの実装と使用に関するいくつかの経験が[MAP-CALC]に文書化されており、ここに要約されています。
o Data collection: Retrieving topology information typically requires implementing several protocols other than ALTO for data collection. For such other protocols, ALTO deployments faced protocol behaviors that were different from what would be expected from the specification of the corresponding protocol. This includes behavior caused by older versions of the protocol specification, a lax interpretation on the remote side or simply incompatibility with the corresponding standard. This sort of problems in collecting data can make an ALTO deployment more complicated, even if it is unrelated to ALTO protocol itself.
o データ収集：トポロジー情報を取得するには、通常、データ収集のためにALTO以外のいくつかのプロトコルを実装する必要があります。そのような他のプロトコルの場合、ALTO展開は、対応するプロトコルの仕様から期待されるものとは異なるプロトコル動作に直面しました。これには、古いバージョンのプロトコル仕様、リモート側での緩やかな解釈、または単に対応する標準との非互換性によって引き起こされる動作が含まれます。データ収集におけるこの種の問題は、ALTOプロトコル自体とは無関係であっても、ALTOの展開をより複雑にする可能性があります。
o Data processing: Processing network information can be very complex and quite resource demanding. Gathering information from an autonomous system connected to the Internet may imply that a server must store and process hundreds of thousands of prefixes, several hundreds of megabytes of IPFIX/Netflow information per minute, and information from hundreds of routers and attributes of thousands of links. A lot of disk memory, RAM, and CPU cycles as well as efficient algorithms are required to process the information. Operators of an ALTO server have to be aware that significant compute resources are not only required for the ALTO server, but also for the corresponding data collection.
oデータ処理：ネットワーク情報の処理は非常に複雑で、かなりのリソースを必要とします。インターネットに接続された自律システムから情報を収集することは、サーバーが数十万のプレフィックス、毎分数百メガバイトのIPFIX / Netflow情報、および数百のルーターからの情報と数千のリンクの属性を保存および処理する必要があることを意味します。情報を処理するには、大量のディスクメモリ、RAM、CPUサイクル、および効率的なアルゴリズムが必要です。 ALTOサーバーのオペレーターは、ALTOサーバーだけでなく、対応するデータ収集にも大量の計算リソースが必要であることを認識しておく必要があります。
o Network map calculation: Large IP-based networks consist of hundreds of thousands of prefixes that have to be mapped to PIDs in the process of network map calculation. As a result, network maps get very large (up to tens of megabytes). However, depending on the design of the network and the chosen grouping function the calculated network maps contains redundancy that can be removed. There are at least two ways to reduce the size by removing redundancy. First, adjacent IP prefixes can be merged. When a PID has two adjacent prefix entries it can merge them together to one larger prefix. It is mandatory that both prefixes be in the same PID. However, the large prefix being assigned to another PID cannot be ruled out. This must be checked, and it is up to the grouping function whether or not to merge the prefixes and remove the larger prefix from the other PID. A simple example, when a PID comprises the prefixes 2001:db8:0:0::/64 and 2001:db8:0:1::/64 it can easily merge them to 2001:db8:0:0::/63. Second, a prefix and its next-longest-prefix match may be in the same PID. In this case, the smaller prefix can simply be removed since it is redundant for obvious reasons. A simple example, a PID comprises the prefixes 2001:db8:0:0::/62 and 2001:db8:0:1::/64 and the /62 is the next-longer prefix match of the /64, the /64 prefix can simply be removed. In contrast, if another PID contains the 2001:db8:0:0::/63 prefix, the entry 2001:db8:0:1::/64 cannot be removed since the next-longest prefix is not in the same PID anymore. Operators of an ALTO server thus have to analyze whether their address assignment schemes allows such tuning.
o ネットワークマップ計算：大規模なIPベースのネットワークは、ネットワークマップ計算のプロセスでPIDにマップする必要がある数十万のプレフィックスで構成されます。その結果、ネットワークマップは非常に大きくなります（最大数十メガバイト）。ただし、ネットワークの設計と選択したグループ化機能によっては、計算されたネットワークマップに削除可能な冗長性が含まれています。冗長性を削除してサイズを削減するには、少なくとも2つの方法があります。まず、隣接するIPプレフィックスをマージできます。 PIDに2つの隣接するプレフィックスエントリがある場合、それらを1つの大きなプレフィックスにマージできます。両方のプレフィックスが同じPIDにあることが必須です。ただし、別のPIDに割り当てられている大きなプレフィックスを除外することはできません。これをチェックする必要があり、接頭辞をマージして、より大きな接頭辞を他のPIDから削除するかどうかは、グループ化機能次第です。簡単な例では、PIDがプレフィックス2001：db8：0：0 :: / 64および2001：db8：0：1 :: / 64で構成されている場合、それらを2001：db8：0：0 :: / 63に簡単にマージできます。 。第二に、プレフィックスとその次に長いプレフィックスの一致が同じPIDにある可能性があります。この場合、明白な理由で冗長であるため、小さい接頭辞は単に削除できます。簡単な例では、PIDはプレフィックス2001：db8：0：0 :: / 62および2001：db8：0：1 :: / 64で構成され、/ 62は/ 64の次に長いプレフィックス一致である/ 64プレフィックスは簡単に削除できます。対照的に、別のPIDに2001：db8：0：0 :: / 63プレフィックスが含まれている場合、エントリ2001：db8：0：1 :: / 64は、次に長いプレフィックスが同じPIDにないため削除できません。 。したがって、ALTOサーバーのオペレーターは、自分のアドレス割り当てスキームでこのような調整が可能かどうかを分析する必要があります。
o Cost map calculation: One known implementation challenge with cost map calculations is the vast amount of CPU cycles that may be required to calculate the costs in large networks. This is particular problematic if costs are calculated between the endpoints of each source-destination PID pair. Very often several to many endpoints of a PID are attached to the same node, so the same path cost is calculated several times. This is clearly inefficient. A remedy could be more sophisticated algorithms, such as looking up the routers the endpoints of each PID are connected to in our network graph and calculated cost map based on the costs between the routers. When deploying and configuring ALTO servers, administrators should consider the impact of huge cost maps and possibly ensure that map sizes do not get too large.
o コストマップの計算：コストマップの計算に関する既知の実装の課題の1つは、大規模ネットワークでのコストの計算に必要となる可能性のある膨大な量のCPUサイクルです。これは、各送信元と宛先のPIDペアのエンドポイント間でコストが計算される場合、特に問題になります。多くの場合、PIDのいくつかのエンドポイントから多くのエンドポイントが同じノードに接続されているため、同じパスコストが数回計算されます。これは明らかに非効率的です。解決策は、各PIDのエンドポイントが接続されているルーターをネットワークグラフで検索し、ルーター間のコストに基づいてコストマップを計算するなど、より洗練されたアルゴリズムである可能性があります。 ALTOサーバーを展開および構成する場合、管理者は巨大なコストマップの影響を考慮し、マップのサイズが大きくなりすぎないようにする必要があります。
In addition, further deployment experiences have been documented. One real example is described in greater detail in reference [CHINA-TRIAL].
さらに、さらなる展開経験が文書化されています。 1つの実際の例は、リファレンス[CHINA-TRIAL]で詳細に説明されています。
Also, experiments have been conducted with ALTO-like deployments in ISP networks. For instance, NTT performed tests with their HINT server implementation and dummy nodes to gain insight on how an ALTO-like service can influence peer-to-peer systems [RFC6875]. The results of an early experiment conducted in the Comcast network are documented in [RFC5632].
また、ISPネットワークでのALTOのような展開で実験が行われました。たとえば、NTTはHINTサーバーの実装とダミーノードを使用してテストを実行し、ALTOのようなサービスがピアツーピアシステムにどのように影響するかについて洞察を得ました[RFC6875]。 Comcastネットワークで行われた初期の実験の結果は、[RFC5632]に文書化されています。
Originally, P2P applications were the main driver for the development of ALTO. In this use case, it is assumed that one party (usually the operator of a "managed" IP network domain) will disclose information about the network through ALTO. The application overlay will query this information and optimize its behavior in order to improve performance or Quality of Experience in the application while reducing the utilization of the underlying network infrastructure. The resulting win-win situation is assumed to be the incentive for both parties to provide or consume the ALTO information, respectively.
もともと、P2PアプリケーションがALTOの開発の主な推進力でした。この使用例では、一方の当事者（通常は「管理された」IPネットワークドメインのオペレーター）がALTOを介してネットワークに関する情報を開示すると想定されています。アプリケーションオーバーレイはこの情報を照会し、その動作を最適化して、基盤となるネットワークインフラストラクチャの使用率を削減しながら、アプリケーションのパフォーマンスまたはエクスペリエンスの品質を向上させます。結果として生じる双方にとって有利な状況は、双方がそれぞれALTO情報を提供または消費するインセンティブであると想定されます。
P2P systems can be built with or without use of a centralized resource directory ("tracker"). The scope of this section is the interaction of P2P applications with the ALTO service. In this scenario, the resource consumer ("peer") asks the resource directory for a list of candidates that can provide the desired resource. There are different options for how ALTO can be deployed in such use cases with a centralized resource directory.
P2Pシステムは、集中型リソースディレクトリ（「トラッカー」）を使用してもしなくても構築できます。このセクションの範囲は、P2PアプリケーションとALTOサービスの相互作用です。このシナリオでは、リソースコンシューマ（「ピア」）がリソースディレクトリに、目的のリソースを提供できる候補のリストを要求します。一元化されたリソースディレクトリを使用するこのようなユースケースでALTOをデプロイする方法には、さまざまなオプションがあります。
For efficiency reasons (i.e., message size), only a subset of all resource providers known to the resource directory will be returned to the resource consumer. Some or all of these resource providers, plus further resource providers learned by other means such as direct communication between peers, will be contacted by the resource consumer for accessing the resource. The purpose of ALTO is giving guidance on this peer selection, which should yield better-than-random results. The tracker response as well as the ALTO guidance are most beneficial in the initial phase after the resource consumer has decided to access a resource, as long as only few resource providers are known. Later, when the resource consumer has already exchanged some data with other peers and measured the transmission speed, the relative importance of ALTO may dwindle.
効率上の理由（つまり、メッセージサイズ）のため、リソースディレクトリに認識されているすべてのリソースプロバイダーのサブセットのみがリソースコンシューマーに返されます。これらのリソースプロバイダーの一部またはすべて、およびピア間の直接通信などの他の手段によって学習されたその他のリソースプロバイダーは、リソースにアクセスするためにリソースコンシューマーによって接続されます。 ALTOの目的は、このピア選択についてのガイダンスを提供することです。これにより、ランダムよりも優れた結果が得られます。トラッカー応答とALTOガイダンスは、リソースプロバイダーがほとんど知らない限り、リソースコンシューマーがリソースへのアクセスを決定した後の初期フェーズで最も有益です。その後、リソースコンシューマがすでに他のピアと一部のデータを交換し、伝送速度を測定している場合、ALTOの相対的な重要性は減少する可能性があります。
A tracker-based P2P application can leverage ALTO in different ways. In the following, the different alternatives and their pros and cons are discussed.
トラッカーベースのP2Pアプリケーションは、さまざまな方法でALTOを活用できます。以下では、さまざまな代替案とその長所と短所について説明します。
,-------. +-----------+
,---. ,-' ========>| Peer 1 |********
,-' `-. / ISP 1 V \ |ALTO Client| *
/ \ / +-------------+ \ +-----------+ *
/ ISP X \ | + ALTO Server | | +-----------+ *
/ \ \ +-------------+<====>| Peer 2 | *
; +---------+ : \ / |ALTO Client|****** *
| | Global | | `-. ,-' +-----------+ * *
| | Tracker | | `-------' * *
| +---------+ | ,-------. +-----------+ * *
: * ; ,-' ========>| Peer 3 | * *
\ * / / ISP 2 V \ |ALTO Client|**** * *
\ * / / +-------------+ \ +-----------+ * * *
\ * / | | ALTO Server | | +-----------+ * * *
`-. * ,-' \ +-------------+<====>| Peer 4 |** * * *
`-*-' \ / |ALTO Client| * * * *
* `-. ,-' +-----------+ * * * *
* `-------' * * * *
* * * * *
*******************************************************
Legend:
=== ALTO protocol
*** Application protocol
Figure 21: Global Tracker and Local ALTO Servers
図21：グローバルトラッカーとローカルALTOサーバー
Figure 21 depicts a tracker-based P2P system with several peers. The peers (i.e., resource consumers) embed an ALTO client to improve the resource provider selection. The tracker (i.e., resource directory) itself may be hosted and operated by another entity. A tracker external to the ISPs of the peers may be a typical use case. For instance, a tracker like Pirate Bay can serve BitTorrent peers worldwide. The figure only shows one tracker instance, but deployments with several trackers could be possible, too.
図21は、複数のピアを持つトラッカーベースのP2Pシステムを示しています。ピア（リソースコンシューマ）は、ALTOクライアントを組み込んでリソースプロバイダの選択を改善します。トラッカー（つまり、リソースディレクトリ）自体は、別のエンティティによってホストおよび操作される場合があります。ピアのISPの外部にあるトラッカーは、一般的な使用例です。たとえば、Pirate Bayのようなトラッカーは、世界中のBitTorrentピアにサービスを提供できます。この図は1つのトラッカーインスタンスのみを示していますが、複数のトラッカーを使用した配置も可能です。
The scenario depicted in Figure 21 lets the peers directly communicate with their ISP's ALTO server (i.e., ALTO client embedded in the peers), thus giving the peers the most control on which information they query for, as they can integrate information received from one tracker or several trackers and through direct peer-to-peer knowledge exchange. For instance, the latter approach is called peer exchange (PEX) in BitTorrent. In this deployment scenarios, the peers have to discover a suitable ALTO server (e.g., offered by their ISP, as described in [RFC7286]).
図21に示すシナリオでは、ピアがISPのALTOサーバー（つまり、ピアに埋め込まれたALTOクライアント）と直接通信できるため、1つのトラッカーから受信した情報を統合できるため、クエリする情報をピアに最も多く制御できます。またはいくつかのトラッカーと、直接のピアツーピアの知識交換を通じて。たとえば、後者のアプローチは、BitTorrentではピア交換（PEX）と呼ばれます。この展開シナリオでは、ピアは適切なALTOサーバー（たとえば、[RFC7286]で説明されているように、ISPによって提供されている）を検出する必要があります。
There are also tracker-less P2P system architectures that do not rely on centralized resource directories, e.g., unstructured P2P networks. Regarding the use of ALTO, their deployment would be similar to Figure 21, since the ALTO client would be embedded in the peers as well. This option is not further considered in this memo.
構造化されていないP2Pネットワークなど、集中化されたリソースディレクトリに依存しないトラッカーのないP2Pシステムアーキテクチャもあります。 ALTOの使用に関しては、ALTOクライアントもピアに組み込まれているため、それらの配置は図21のようになります。このオプションは、このメモではさらに考慮されていません。
,-------.
,---. ,-' `-. +-----------+
,-' `-. / ISP 1 \ | Peer 1 |********
/ \ / +-------------+ \ | | *
/ ISP X \ ++====>| ALTO Server | )+-----------+ *
/ \ || \ +-------------+ / +-----------+ *
; +-----------+ : || \ / | Peer 2 | *
| | Tracker |<====++ `-. ,-' | |****** *
| |ALTO Client| | `-------' +-----------+ * *
| +-----------+<====++ ,-------. * *
: * ; || ,-' `-. +-----------+ * *
\ * / || / ISP 2 \ | Peer 3 | * *
\ * / || / +-------------+ \ | |**** * *
\ * / ++====>| ALTO Server | )+-----------+ * * *
`-. * ,-' \ +-------------+ / +-----------+ * * *
`-*-' \ / | Peer 4 |** * * *
* `-. ,-' | | * * * *
* `-------' +-----------+ * * * *
* * * * *
* * * * *
*********************************************************
Legend:
=== ALTO protocol
*** Application protocol
Figure 22: Global Tracker Accessing ALTO Server at Various ISPs
図22：さまざまなISPでALTOサーバーにアクセスするグローバルトラッカー
An alternative deployment scenario for a tracker-based system is depicted in Figure 22. Here, the tracker embeds the ALTO client. When the tracker receives a request from a querying peer, it first discovers the ALTO server responsible for the querying peer. This discovery can be done by using various ALTO server discovery mechanisms [RFC7286] [XDOM-DISC]. The ALTO client subsequently sends to the querying peer only those peers that are preferred by the ALTO server responsible for the querying peer. The peers do not query the ALTO servers themselves. This gives the peers a better initial selection of candidates, but does not consider peers learned through direct peer-to-peer knowledge exchange.
トラッカーベースのシステムの別の展開シナリオを図22に示します。ここでは、トラッカーがALTOクライアントを埋め込みます。トラッカーは、クエリを行うピアから要求を受信すると、最初にクエリを行うピアを担当するALTOサーバーを検出します。この検出は、さまざまなALTOサーバー検出メカニズム[RFC7286] [XDOM-DISC]を使用して実行できます。その後、ALTOクライアントは、クエリピアを担当するALTOサーバーが優先するピアのみをクエリピアに送信します。ピアは、ALTOサーバー自体にクエリを実行しません。これにより、ピアは候補をより適切に初期選択できますが、ピアツーピアの直接の知識交換を通じて学習したピアは考慮されません。
ISP 1 ,-------. +-----------+
,---. +-------------+******| Peer 1 |
,-' `-. /| Tracker |\ | |
/ \ / +-------------+**** +-----------+
/ ISP X \ | === | * +-----------+
/ \ \ +-------------+ / * | Peer 2 |
; +---------+ : \| ALTO Server |/ ***| |
| | Global | | +-------------+ +-----------+
| | Tracker | | `-------'
| +---------+ | +-----------+
: * ; ,-------. | Peer 3 |
\ * / +-------------+ ****| |
\ * / /| Tracker |*** +-----------+
\ * / / +-------------+ \ +-----------+
`-. * ,-' | === | | Peer 4 |**
`-*-' \ +-------------+ / | | *
* \| ALTO Server |/ +-----------+ *
* +-------------+ *
* ISP 2 `-------' *
*************************************************
Legend:
=== ALTO protocol
*** Application protocol
Figure 23: Local Trackers and Local ALTO Servers (P4P Approach)
図23：ローカルトラッカーとローカルALTOサーバー（P4Pアプローチ）
There are some attempts to let ISPs deploy their own trackers, as shown in Figure 23. In this case, the client cannot get guidance from the ALTO server other than by talking to the ISP's tracker, which in turn communicates with the ALTO server using the ALTO protocol. It should be noted that the peers are still allowed to contact other trackers operated by entities other than the peer's ISP, but in this case they cannot benefit from ALTO guidance.
図23に示すように、ISPに独自のトラッカーをデプロイさせる試みがいくつかあります。この場合、クライアントは、ISPのトラッカーと通信する以外に、ALTOサーバーからガイダンスを取得できません。 ALTOプロトコル。ピアは、ピアのISP以外のエンティティによって運営されている他のトラッカーに連絡することを許可されていますが、この場合、ALTOガイダンスの恩恵を受けることができないことに注意してください。
The ALTO protocol specification [RFC7285] details how an ALTO client can query an ALTO server for guiding information and receive the corresponding replies. In case of peer-to-peer networks, two different ALTO services can be used: the cost map service is often preferred as solution by peer-to-peer software implementors and users, since it avoids disclosing peer IP addresses to a centralized entity. Alternatively, network operators may have a preference for the ECS, since it does not require exposure of the network topology.
ALTOプロトコル仕様[RFC7285]は、ALTOクライアントがガイド情報を求めてALTOサーバーにクエリを行い、対応する応答を受信する方法を詳しく説明しています。ピアツーピアネットワークの場合、2つの異なるALTOサービスを使用できます。コストマッピングサービスは、ピアツーピアソフトウェアの実装者とユーザーによるソリューションとして好まれます。これは、集中化されたエンティティへのピアIPアドレスの開示を回避するためです。または、ネットワークトポロジーを公開する必要がないため、ネットワークオペレーターがECSを優先する場合があります。
For actual use of ALTO in P2P applications, both software vendors and network operators have to agree which ALTO services to use. The ALTO protocol is flexible and supports both services. Note that for other use cases of ALTO, in particular in more controlled environments, both the cost map service and the ECS might be feasible; it is more of an engineering trade-off whether to use a map-based or query-based ALTO service.
P2PアプリケーションでALTOを実際に使用するには、ソフトウェアベンダーとネットワークオペレーターの両方が、使用するALTOサービスに同意する必要があります。 ALTOプロトコルは柔軟性があり、両方のサービスをサポートします。 ALTOの他の使用例、特により制御された環境では、コストマップサービスとECSの両方が実行可能であることに注意してください。マップベースのALTOサービスを使用するか、クエリベースのALTOサービスを使用するかは、エンジニアリング上のトレードオフです。
As explained in Section 4.1.2, for a tracker-based P2P application, there are two fundamentally different possibilities where to place the ALTO client:
セクション4.1.2で説明したように、トラッカーベースのP2Pアプリケーションの場合、ALTOクライアントを配置する場所には2つの根本的に異なる可能性があります。
1. ALTO client in the resource consumer ("peer")
1. リソースコンシューマ（ "ピア"）のALTOクライアント
2. ALTO client in the resource directory ("tracker")
2. リソースディレクトリ内のALTOクライアント（「トラッカー」）
Both approaches have advantages and drawbacks that have to be considered. If the ALTO client is in the resource consumer (Figure 21), a potentially very large number of clients has to be deployed. Instead, when using an ALTO client in the resource directory (Figures 22 and 23), ostensibly peers do not have to directly query the ALTO server. In this case, an ALTO server could even not permit access to peers.
どちらのアプローチにも、考慮すべき長所と短所があります。 ALTOクライアントがリソースコンシューマー内にある場合（図21）、非常に多数のクライアントを展開する必要がある可能性があります。代わりに、リソースディレクトリでALTOクライアントを使用する場合（図22および23）、表面的にはピアがALTOサーバーに直接クエリを実行する必要はありません。この場合、ALTOサーバーはピアへのアクセスを許可することさえできません。
However, it seems to be beneficial for all participants to let the peers directly query the ALTO server. Considering the plethora of different applications that could use ALTO, e.g., multiple-tracker-based or non-tracker-based P2P systems or other applications searching for relays, this renders the ALTO service more useful. The peers are also the single point having all operational knowledge to decide whether to use the ALTO guidance and how to use the ALTO guidance. For a given peer, one can also expect that an ALTO server of the corresponding ISP provides useful guidance and can be discovered.
ただし、すべての参加者にとって、ピアがALTOサーバーに直接クエリできるようにすることは有益であるようです。 ALTOを使用する可能性のあるさまざまなアプリケーション（たとえば、マルチトラッカーベースまたは非トラッカーベースのP2Pシステム、またはリレーを検索する他のアプリケーション）を考慮すると、ALTOサービスがより便利になります。ピアは、ALTOガイダンスを使用するかどうか、およびALTOガイダンスの使用方法を決定するためのすべての運用知識を持つ単一のポイントでもあります。特定のピアについて、対応するISPのALTOサーバーが有用なガイダンスを提供し、発見できることも期待できます。
Yet, ALTO clients in the resource consumer also have drawbacks compared to use in the resource directory. In the following, both scenarios are compared more in detail in order to explain the impact on ALTO guidance and the need for third-party ALTO queries.
ただし、リソースコンシューマのALTOクライアントには、リソースディレクトリでの使用に比べて欠点もあります。以下では、ALTOガイダンスへの影響とサードパーティのALTOクエリの必要性を説明するために、両方のシナリオをより詳細に比較します。
In the first scenario (see Figure 24), the peer (resource consumer) queries the tracker (resource directory) for the desired resource (F1). The resource directory returns a list of potential resource providers without considering ALTO (F2). It is then the duty of the resource consumer to invoke ALTO (F3/F4), in order to solicit guidance regarding this list.
最初のシナリオ（図24を参照）では、ピア（リソースコンシューマー）がトラッカー（リソースディレクトリ）に目的のリソース（F1）を照会します。リソースディレクトリは、ALTO（F2）を考慮せずに、潜在的なリソースプロバイダーのリストを返します。このリストに関するガイダンスを求めるために、ALTO（F3 / F4）を呼び出すのはリソースコンシューマーの義務です。
Peer w. ALTO cli. Tracker ALTO Server
--------+-------- --------+-------- --------+--------
| F1 Tracker query | |
|======================>| |
| F2 Tracker reply | |
|<======================| |
| F3 ALTO protocol query |
|---------------------------------------------->|
| F4 ALTO protocol reply |
|<----------------------------------------------|
| | |
==== Application protocol (i.e., tracker-based P2P app protocol)
---- ALTO protocol
Figure 24: Basic Message Sequence Chart for Resource-Consumer-Initiated ALTO Query
図24：リソース-コンシューマーが開始したALTOクエリの基本的なメッセージシーケンスチャート
In the second scenario (see Figure 25), the resource directory has an embedded ALTO client, which we will refer to as Resource Directory ALTO Client (RDAC) in this document. After receiving a query for a given resource (F1), the resource directory invokes the RDAC to evaluate all resource providers it knows (F2/F3). Then, it returns a, possibly shortened, list containing the "best" resource providers to the resource consumer (F4).
2番目のシナリオ（図25を参照）では、リソースディレクトリに埋め込まれたALTOクライアントがあり、これをこのドキュメントではリソースディレクトリALTOクライアント（RDAC）と呼びます。特定のリソース（F1）のクエリを受け取った後、リソースディレクトリはRDACを呼び出して、知っているすべてのリソースプロバイダーを評価します（F2 / F3）。次に、「ベスト」リソースプロバイダーを含む短縮されたリストをリソースコンシューマーに返します（F4）。
Peer Tracker w. RDAC ALTO Server
--------+-------- --------+-------- --------+--------
| F1 Tracker query | |
|======================>| |
| | F2 ALTO cli. p. query |
| |---------------------->|
| | F3 ALTO cli. p. reply |
| |<----------------------|
| F4 Tracker reply | |
|<======================| |
| | |
==== Application protocol (i.e., tracker-based P2P app protocol)
---- ALTO protocol
Figure 25: Basic Message Sequence Chart for Third-Party ALTO Query
図25：サードパーティのALTOクエリの基本的なメッセージシーケンスチャート
Note: The message sequences depicted in Figures 24 and 25 may occur both in the target-aware and the target-independent query mode (cf. [RFC6708]). In the target-independent query mode, no message exchange with the ALTO server might be needed after the tracker query, because the candidate resource providers could be evaluated using a locally cached "map", which has been retrieved from the ALTO server some time ago.
注：図24および25に示されているメッセージシーケンスは、ターゲットを認識するモードとターゲットに依存しないクエリモードの両方で発生する可能性があります（[RFC6708]を参照）。ターゲットに依存しないクエリモードでは、候補リソースプロバイダーは、ALTOサーバーからしばらく前に取得されたローカルにキャッシュされた「マップ」を使用して評価できるため、トラッカークエリの後にALTOサーバーとのメッセージ交換は必要ない場合があります。 。
The first approach has the following problem: While the resource directory might know thousands of peers taking part in a swarm, the list returned to the resource consumer is usually shortened for efficiency reasons. Therefore, the "best" (in the sense of ALTO) potential resource providers might not be contained in that list anymore, even before ALTO can consider them.
最初のアプローチには次の問題があります。リソースディレクトリはスウォームに参加している数千のピアを知っている可能性がありますが、リソースコンシューマに返されるリストは通常、効率上の理由から短縮されます。したがって、ALTOが考慮に入れる前であっても、（ALTOの意味で）「最良」の潜在的なリソースプロバイダーは、そのリストに含まれなくなる可能性があります。
Much better traffic optimization could be achieved if the tracker would evaluate all known peers using ALTO. This list would then include a significantly higher fraction of "good" peers. If the tracker returned "good" peers only, there might be a risk that the swarm might disconnect and split into several disjunct partitions. However, finding the right mix of ALTO-biased and random peer selection is out of the scope of this document.
トラッカーがALTOを使用してすべての既知のピアを評価する場合、はるかに優れたトラフィック最適化を実現できます。このリストには、「良い」ピアのかなり高い割合が含まれます。トラッカーが「良好な」ピアのみを返した場合、スウォームが切断され、いくつかの分離したパーティションに分割される可能性があります。ただし、ALTOバイアスとランダムなピア選択の適切な組み合わせを見つけることは、このドキュメントの範囲外です。
Therefore, from an overall optimization perspective, the second scenario with the ALTO client embedded in the resource directory is advantageous, because it is ensured that the addresses of the "best" resource providers are actually delivered to the resource consumer. An architectural implication of this insight is that the ALTO server discovery procedures must support third-party discovery. That is, as the tracker issues ALTO queries on behalf of the peer that contacted the tracker, the tracker must be able to discover an ALTO server that can give guidance suitable for that respective peer (see [XDOM-DISC]).
したがって、全体的な最適化の観点から見ると、ALTOクライアントがリソースディレクトリに埋め込まれている2番目のシナリオは、「最適な」リソースプロバイダーのアドレスが実際にリソースコンシューマーに確実に配信されるため、有利です。この洞察のアーキテクチャ上の意味は、ALTOサーバーの検出手順がサードパーティの検出をサポートする必要があることです。つまり、トラッカーは、トラッカーに連絡したピアに代わってALTOクエリを発行するため、そのピアに適したガイダンスを提供できるALTOサーバーを検出できる必要があります（[XDOM-DISC]を参照）。
In principle, a combined approach could also be possible. For instance, a tracker could use a coarse-grained "global" ALTO server to find the peers in the general vicinity of the requesting peer, while peers could use "local" ALTO servers for a more fine-grained guidance. Yet, there is no known deployment experience for such a combined approach.
原則として、組み合わせたアプローチも可能です。たとえば、トラッカーは粗粒度の「グローバル」ALTOサーバーを使用して要求側ピアの一般的な近傍にあるピアを見つけることができ、ピアは「ローカル」ALTOサーバーを使用してより細かいガイダンスを行うことができます。しかし、そのような組み合わせたアプローチの配備経験は知られていない。
This section briefly introduces the usage of ALTO for CDNs, as explained in [CDN-USE]. CDNs are used in the delivery of some Internet services (e.g., delivery of websites, software updates, and video delivery) from a location closer to the location of the user. A CDN typically consists of a network of servers often attached to ISP networks. The point of attachment is often as close to content consumers and peering points as economically or operationally feasible in order to decrease traffic load on the ISP backbone and to provide better user experience measured by reduced latency and higher throughput.
このセクションでは、[CDN-USE]で説明されているように、CDNに対するALTOの使用法を簡単に紹介します。 CDNは、一部のインターネットサービスの配信（Webサイトの配信、ソフトウェアの更新、ビデオ配信など）で、ユーザーの場所に近い場所から使用されます。 CDNは通常、ISPネットワークに接続されていることが多いサーバーのネットワークで構成されます。アタッチメントポイントは、ISPバックボーンのトラフィック負荷を減らし、レイテンシの短縮とスループットの向上によって測定されるより良いユーザーエクスペリエンスを提供するために、多くの場合、経済的または運用上可能な限りコンテンツコンシューマーとピアリングポイントに近い場所にあります。
CDNs use several techniques to redirect a client to a server (surrogate). A request-routing function within a CDN is responsible for receiving content requests from user agents, obtaining and maintaining necessary information about a set of candidate surrogates, and selecting and redirecting the user agent to the appropriate surrogate. One common way is relying on the DNS system, but there are many other ways, see [RFC3568].
CDNは、いくつかの手法を使用して、クライアントをサーバー（代理）にリダイレクトします。 CDN内の要求ルーティング機能は、ユーザーエージェントからコンテンツ要求を受信し、一連の候補サロゲートに関する必要な情報を取得して維持し、ユーザーエージェントを選択して適切なサロゲートにリダイレクトします。一般的な方法の1つはDNSシステムに依存することですが、他にも多くの方法があります。[RFC3568]を参照してください。
+--------------------+
| CDN Request Router |
| with ALTO Client |
+--------------------+
/\
|| ALTO protocol
||
\/
+---------+
| ALTO |
| Server |
+---------+
:
: Provisioning protocol
:
,-----------.
,-' Source of `-.
( topological )
`-. information ,-'
`-----------'
Figure 26: Use of ALTO Information for CDN Request Routing
図26：CDN要求ルーティングのためのALTO情報の使用
In order to derive the optimal benefit from a CDN, it is preferable to deliver content from the servers (caches) that are "closest" to the end user requesting the content. The definition of "closest" may be as simple as geographical or IP topology distance, but it may also consider other combinations of metrics and CDN or ISP policies. As illustrated in Figure 26, ALTO could provide this information.
CDNから最適なメリットを引き出すには、コンテンツを要求するエンドユーザーに「最も近い」サーバー（キャッシュ）からコンテンツを配信することが望ましいです。 「最も近い」の定義は、地理的距離またはIPトポロジー距離と同じくらい単純な場合がありますが、メトリックとCDNまたはISPポリシーの他の組み合わせも考慮する場合があります。図26に示すように、ALTOはこの情報を提供できます。
User Agent Request Router Surrogate
| | |
| F1 Initial Request | |
+---------------------------->| |
| +--+ |
| | | F2 Surrogate Selection |
| |<-+ (using ALTO) |
| F3 Redirection Response | |
|<----------------------------+ |
| | |
| F4 Content Request | |
+-------------------------------------------------------->|
| | |
| | F5 Content |
|<--------------------------------------------------------+
| | |
Figure 27: Example of CDN Surrogate Selection
図27：CDNサロゲート選択の例
Figure 27 illustrates the interaction between a user agent, a request router, and a surrogate for the delivery of content in a single CDN. As explained in [CDN-USE], the user agent makes an initial request to the CDN (F1). This may be an application-level request (e.g., HTTP) or a DNS request. In the second step (F2), the request router selects an appropriate surrogate (or set of surrogates) based on the user agent's (or its proxy's) IP address, the request router's knowledge of the network topology (which can be obtained by ALTO) and reachability cost between CDN caches and end users, and any additional CDN policies. Then, the request router responds to the initial request with an appropriate response containing a redirection to the selected cache (F3), for example, by returning an appropriate DNS A/AAAA record or an HTTP 302 redirect, etc. The user agent uses this information to connect directly to the surrogate and request the desired content (F4), which is then delivered (F5).
図27は、ユーザーエージェント、リクエストルーター、および単一のCDNでコンテンツを配信するためのサロゲート間の相互作用を示しています。 [CDN-USE]で説明したように、ユーザーエージェントはCDN（F1）に最初のリクエストを行います。これは、アプリケーションレベルのリクエスト（HTTPなど）またはDNSリクエストです。 2番目のステップ（F2）では、リクエストルーターは、ユーザーエージェント（またはそのプロキシ）のIPアドレス、リクエストルーターのネットワークトポロジに関する知識（ALTOで取得可能）に基づいて、適切なサロゲート（またはサロゲートのセット）を選択します。 CDNキャッシュとエンドユーザー間の到達可能性コスト、および追加のCDNポリシー。次に、要求ルーターは、選択されたキャッシュ（F3）へのリダイレクトを含む適切な応答で初期要求に応答します。たとえば、適切なDNS A / AAAAレコードまたはHTTP 302リダイレクトなどを返します。ユーザーエージェントはこれを使用します。サロゲートに直接接続し、目的のコンテンツを要求するための情報（F4）が配信されます（F5）。
The most simple use case for ALTO in a CDN context is to improve the selection of a CDN surrogate or origin. In this case, the CDN makes use of an ALTO server to choose a better CDN surrogate or origin than would otherwise be the case. Although it is possible to obtain raw network map and cost information in other ways, for example, passively listening to the ISP's routing protocols or use of active probing, the use of an ALTO service to expose that information may provide additional control to the ISP over how their network map/cost is exposed. Additionally, it may enable the ISP to maintain a functional separation between their routing plane and network map computation functions. This may be attractive for a number of reasons, for example:
CDNコンテキストでのALTOの最も単純な使用例は、CDNサロゲートまたはオリジンの選択を改善することです。この場合、CDNはALTOサーバーを使用して、他の場合よりも優れたCDNサロゲートまたはオリジンを選択します。 ISPのルーティングプロトコルをパッシブにリッスンしたり、アクティブプローブを使用したりするなど、他の方法で生のネットワークマップとコスト情報を取得することは可能ですが、ALTOサービスを使用してその情報を公開すると、ISPに追加の制御を提供できます。ネットワークマップ/コストがどのように公開されるか。さらに、ISPがルーティングプレーンとネットワークマップ計算機能の間の機能分離を維持できるようにする場合もあります。これは、次のようないくつかの理由で魅力的です。
o The ALTO service could provide a filtered view of the network and/ or cost map that relates to CDN locations and their proximity to end users, for example, to allow the ISP to control the level of topology detail they are willing to share with the CDN.
o ALTOサービスは、CDNの場所とエンドユーザーへの近接性に関連するネットワークやコストマップのフィルターされたビューを提供できます。たとえば、ISPがCDNと共有するトポロジの詳細レベルを制御できるようにします。 。
o The ALTO service could apply additional policies to the network map and cost information to provide a CDN-specific view of the network map/cost, for example, to allow the ISP to encourage the CDN to use network links that would not ordinarily be preferred by a Shortest Path First routing calculation.
o ALTOサービスは、ネットワークマップとコスト情報に追加のポリシーを適用して、ネットワークマップ/コストのCDN固有のビューを提供することができます。たとえば、ISPがCDNに、通常は推奨されないネットワークリンクを使用するように促すことができます。最短経路優先ルーティング計算。
o The routing plane may be operated and controlled by a different operational entity (even within a single ISP) than the CDN. Therefore, the CDN may not be able to passively listen to routing protocols, nor may it have access to other network topology data (e.g., inventory databases).
o ルーティングプレーンは、CDNとは別の運用エンティティ（単一のISP内でも）によって操作および制御できます。したがって、CDNはルーティングプロトコルを受動的にリッスンできない場合や、他のネットワークトポロジデータ（インベントリデータベースなど）にアクセスできない場合があります。
When CDN servers are deployed outside of an ISP's network or in a small number of central locations within an ISP's network, a simplified view of the ISP's topology or an approximation of proximity is typically sufficient to enable the CDN to serve end users from the optimal server/location. As CDN servers are deployed deeper within ISP networks, it becomes necessary for the CDN to have more detailed knowledge of the underlying network topology and costs between network locations in order to enable the CDN to serve end users from the optimal servers for the ISP.
CDNサーバーがISPのネットワークの外部またはISPのネットワーク内の少数の中央の場所に展開されている場合、CDNが最適なサーバーからエンドユーザーにサービスを提供できるようにするには、ISPのトポロジの簡略化されたビューまたは近接度で十分です。 /ロケーション。 CDNサーバーはISPネットワーク内のより深い場所に展開されるため、CDNがISPに最適なサーバーからエンドユーザーにサービスを提供できるようにするためには、CDNが基になるネットワークトポロジとネットワークロケーション間のコストについてより詳細な知識を持つ必要があります。
The request router in a CDN will typically also take into account criteria and constraints that are not related to network topology, such as the current load of CDN surrogates, content owner policies, end user subscriptions, etc. This document only discusses use of ALTO for network information.
CDNのリクエストルーターは、通常、CDNサロゲートの現在の負荷、コンテンツ所有者ポリシー、エンドユーザーサブスクリプションなど、ネットワークトポロジに関連しない基準と制約も考慮します。このドキュメントでは、ALTOの使用についてのみ説明しますネットワーク情報。
A general issue for CDNs is that the CDN logic has to match the client's IP address with the closest CDN surrogate, for approaches that are both DNS or HTTP redirect based (see, for instance, [ALTO-CDN]). This matching is not trivial, for example, in DNS-based approaches, where the IP address of the DNS original requester is unknown (see [RFC7871] for a discussion of this and a solution approach).
CDNの一般的な問題は、DNSまたはHTTPリダイレクトベースのアプローチ（たとえば、[ALTO-CDN]を参照）のアプローチでは、CDNロジックがクライアントのIPアドレスを最も近いCDNサロゲートと一致させる必要があることです。この一致は、たとえば、DNSベースのアプローチでは簡単ではありません。DNSベースのアプローチでは、元のDNSリクエスターのIPアドレスが不明です（これとソリューションアプローチの説明については、[RFC7871]を参照してください）。
In addition to use by a single CDN, ALTO can also be used in scenarios that interconnect several CDNs. This use case is detailed in [CDNI-FCI].
ALTOは、単一のCDNによる使用に加えて、複数のCDNを相互接続するシナリオでも使用できます。この使用例は、[CDNI-FCI]で詳しく説明されています。
In its simplest form, an ALTO server would provide an ISP with the capability to offer a service to a CDN that provides network map and cost information. The CDN can use that data to enhance its surrogate and/or origin selection. If an ISP offers an ALTO Network and Cost Map Service to expose a cost mapping/ranking between end user IP subnets (within that ISP's network) and CDN surrogate IP subnets/ locations, periodic updates of the maps may be needed. As introduced in Section 3.3), it is common for broadband subscribers to obtain their IP addresses dynamically, and in many deployments, the IP subnets allocated to a particular network region can change relatively frequently, even if the network topology itself is reasonably static.
最も単純な形態では、ALTOサーバーは、ネットワークマップとコスト情報を提供するサービスをCDNに提供する機能をISPに提供します。 CDNはそのデータを使用して、代理および/または発信元の選択を強化できます。 ISPがALTOネットワークとコストマップサービスを提供して、エンドユーザーIPサブネット（そのISPのネットワーク内）とCDNサロゲートIPサブネット/ロケーション間のコストマッピング/ランキングを公開する場合、マップの定期的な更新が必要になる場合があります。セクション3.3）で紹介したように、ブロードバンドサブスクライバーがIPアドレスを動的に取得することは一般的であり、多くの展開では、特定のネットワーク地域に割り当てられたIPサブネットは、ネットワークトポロジ自体がかなり静的であっても比較的頻繁に変更される可能性があります。
An alternative would be to use the ALTO ECS: when an end user requests a given content, the CDN request router issues an ECS request with the endpoint address (IPv4/IPv6) of the end user (content requester) and the set of endpoint addresses of the surrogate (content targets). The ALTO server receives the request and ranks the addresses based on their distance from the content requester. Once the request router obtained from the ALTO server the ranked list of locations (for the specific user), it can incorporate this information into its selection mechanisms in order to point the user to the most appropriate surrogate.
代替方法は、ALTO ECSを使用することです。エンドユーザーが特定のコンテンツを要求すると、CDN要求ルーターは、エンドユーザー（コンテンツリクエスター）のエンドポイントアドレス（IPv4 / IPv6）とエンドポイントアドレスのセットを使用してECS要求を発行します。サロゲート（コンテンツターゲット）の。 ALTOサーバーはリクエストを受信し、コンテンツリクエスターからの距離に基づいてアドレスをランク付けします。リクエストルーターは、（特定のユーザーの）場所のランク付けされたリストをALTOサーバーから取得すると、この情報をその選択メカニズムに組み込んで、ユーザーに最も適切な代理を示すことができます。
Since CDNs operate in a controlled environment, the ALTO Network and Cost Map Service and ECS have a similar level of security and confidentiality of network-internal information. However, the Network and Cost Map Service and ECS differ in the way the ALTO service is delivered and address a different set of requirements in terms of topology information and network operations.
CDNは制御された環境で動作するため、ALTOネットワークおよびコストマップサービスとECSは、ネットワーク内部情報のセキュリティと機密性のレベルが同じです。ただし、ネットワークおよびコストマップサービスとECSは、ALTOサービスの提供方法が異なり、トポロジ情報とネットワーク操作の点で異なる一連の要件に対応します。
If a CDN already has means to model connectivity policies, the map-based approaches could possibly be integrated into that. If the ECS service is preferred, a request router that uses ECS could cache the results of ECS queries for later usage in order to address the scalability limitations of ECS and to reduce the number of transactions between the CDN and ALTO server. The ALTO server may indicate in the reply message how long the content of the message is to be considered reliable and insert a lifetime value that will be used by the CDN in order to cache (and then flush or refresh) the entry.
CDNに接続ポリシーをモデル化する手段がすでにある場合は、マップベースのアプローチをそれに統合できる可能性があります。 ECSサービスが優先される場合、ECSを使用するリクエストルーターは、ECSのスケーラビリティの制限に対処し、CDNとALTOサーバー間のトランザクション数を減らすために、後で使用するためにECSクエリの結果をキャッシュできます。 ALTOサーバーは、メッセージのコンテンツが信頼できると見なされる期間を応答メッセージで示し、エントリをキャッシュ（およびフラッシュまたは更新）するためにCDNで使用されるライフタイム値を挿入します。
The following discusses how a CDN could make use of ALTO services.
以下では、CDNがALTOサービスを利用する方法について説明します。
In one deployment scenario, ALTO could expose ISP end-user reachability to a CDN. The request router needs to have information about which end-user IP subnets are reachable via which networks or network locations. The network map services offered by ALTO could be used to expose this topology information while avoiding routing-plane peering between the ISP and the CDN. For example, if CDN surrogates are deployed within the access or aggregation network, the ISP is likely to want to utilize the surrogates deployed in the same access/ aggregation region in preference to surrogates deployed elsewhere, in order to alleviate the cost and/or improve the user experience.
1つの展開シナリオでは、ALTOはISPエンドユーザーの到達可能性をCDNに公開する可能性があります。リクエストルーターには、どのネットワークまたはネットワークロケーションを介して到達可能なエンドユーザーIPサブネットに関する情報が必要です。 ALTOが提供するネットワークマップサービスを使用すると、ISPとCDN間のルーティングプレーンピアリングを回避しながら、このトポロジ情報を公開できます。たとえば、CDNサロゲートがアクセスまたは集約ネットワーク内に展開されている場合、ISPは、コストを軽減および/または改善するために、他の場所に展開されたサロゲートよりも同じアクセス/集約領域に展開されたサロゲートを利用する可能性があります。ユーザーエクスペリエンス。
In addition, CDN surrogates could also use ALTO guidance, e.g., if there is more than one upstream source of content or several origins. In this case, ALTO could help a surrogate with the decision about which upstream source to use. This specific variant of using ALTO is not further detailed in this document.
さらに、CDNサロゲートは、コンテンツの複数の上流ソースまたは複数のオリジンがある場合などに、ALTOガイダンスを使用することもできます。この場合、ALTOは、どのアップストリームソースを使用するかを決定するサロゲートに役立ちます。 ALTOを使用するこの特定のバリアントについては、このドキュメントでは詳しく説明していません。
If content can be provided by several CDNs, there may be a need to interconnect these CDNs. In this case, ALTO can be used as an interface [CDNI-FCI], in particular, for footprint and capabilities advertisement.
複数のCDNでコンテンツを提供できる場合は、これらのCDNを相互接続する必要がある場合があります。この場合、ALTOは、特にフットプリントと機能のアドバタイズのためのインターフェース[CDNI-FCI]として使用できます。
Other, and more advanced, scenarios of deploying ALTO are also listed in [CDN-USE] and [ALTO-CDN].
ALTOを展開するその他の、より高度なシナリオも[CDN-USE]と[ALTO-CDN]に記載されています。
The granularity of ALTO information required depends on the specific deployment of the CDN. For example, an "over-the-top" CDN whose surrogates are deployed only within the Internet backbone may only require knowledge of which end-user IP subnets are reachable via which ISP's networks, whereas a CDN deployed within a particular ISP's network requires a finer granularity of knowledge.
必要なALTO情報の粒度は、CDNの特定の展開によって異なります。たとえば、サロゲートがインターネットバックボーン内にのみ展開されている「オーバーザトップ」のCDNでは、どのISPのネットワークを介して到達可能なエンドユーザーIPサブネットの知識のみが必要なのに対し、特定のISPのネットワーク内に展開されたCDNには、知識の細分性。
An ALTO server ranks addresses based on topology information it acquires from the network. By default, according to [RFC7285], distance in ALTO represents an abstract "routingcost" that can be computed, for instance, from routing protocol information. But an ALTO server may also take into consideration other criteria or other information sources for policy, state, and performance information (e.g., geolocation), as explained in Section 3.2.2.
ALTOサーバーは、ネットワークから取得したトポロジー情報に基づいてアドレスをランク付けします。デフォルトでは、[RFC7285]によれば、ALTOの距離は、たとえばルーティングプロトコル情報から計算できる抽象的な「ルーティングコスト」を表します。ただし、セクション3.2.2で説明されているように、ALTOサーバーは、ポリシー、状態、およびパフォーマンス情報（ジオロケーションなど）の他の基準または他の情報源を考慮に入れる場合もあります。
The different methods and algorithms through which the ALTO server computes topology information and rankings is out of the scope of this document. If rankings are based on routing protocol information, it is obvious that network events may impact the ranking computation. Due to internal redundancy and resilience mechanisms inside current networks, most of the network events happening in the infrastructure will be handled internally in the network, and they should have limited impact on a CDN. However, catastrophic events such as main trunks failures or backbone partitioning will have to be taken into account by the ALTO server to redirect traffic away from the impacted area.
ALTOサーバーがトポロジー情報とランキングを計算するさまざまな方法とアルゴリズムは、このドキュメントの範囲外です。ランキングがルーティングプロトコル情報に基づいている場合、ネットワークイベントがランキング計算に影響を与える可能性があることは明らかです。現在のネットワーク内の内部冗長性と復元メカニズムにより、インフラストラクチャで発生するほとんどのネットワークイベントはネットワーク内部で処理され、CDNへの影響は限定的です。ただし、メイントランクの障害やバックボーンのパーティショニングなどの壊滅的なイベントは、影響を受けるエリアからトラフィックをリダイレクトするために、ALTOサーバーで考慮に入れる必要があります。
An ALTO server implementation may want to keep state about ALTO clients in order to inform and signal to these clients when a major network event happened, e.g., by a notification mechanism. In a CDN/ ALTO interworking architecture with few CDN components interacting with the ALTO server, there are less scalability issues in maintaining state about clients in the ALTO server, compared to ALTO guidance to any Internet user.
ALTOサーバーの実装では、通知メカニズムなどによって主要なネットワークイベントが発生したときに、ALTOクライアントに関する状態を保持して、これらのクライアントに通知および通知することができます。 ALTOサーバーとやり取りするCDNコンポーネントがほとんどないCDN / ALTOインターワーキングアーキテクチャでは、インターネットユーザーへのALTOガイダンスと比較して、ALTOサーバーのクライアントに関する状態を維持する際のスケーラビリティの問題が少なくなります。
This section briefly surveys and references other use cases that have been tested or suggested for ALTO deployments.
このセクションでは、ALTOの展開についてテストまたは提案された他の使用例を簡単に調査して参照します。
Virtual Private Network (VPN) technology is widely used in public and private networks to create groups of users that are separated from other users of the network and allows these users to communicate among themselves as if they are on a private network. Network Service Providers (NSPs) offer different types of VPNs. [RFC4026] distinguishes between Layer 2 VPN (L2VPN) and Layer 3 VPN (L3VPN) using different sub-types. In the following, the term "VPN" is used to refer to provider supplied virtual private networking.
仮想プライベートネットワーク（VPN）テクノロジは、パブリックネットワークおよびプライベートネットワークで広く使用されており、ネットワークの他のユーザーから分離されたユーザーのグループを作成し、これらのユーザーがプライベートネットワーク上にいるかのように相互に通信できます。ネットワークサービスプロバイダー（NSP）は、さまざまな種類のVPNを提供します。 [RFC4026]は、異なるサブタイプを使用するレイヤー2 VPN（L2VPN）とレイヤー3 VPN（L3VPN）を区別します。以下では、「VPN」という用語は、プロバイダーが提供する仮想プライベートネットワーキングを指すために使用されます。
From the perspective of an application at an endpoint, a VPN may not be very different from any other IP connectivity solution, but there are a number of specific applications that could benefit from ALTO topology exposure and guidance in VPNs. As, in the general Internet, one advantage is that applications do not have to perform excessive measurements on their own. For instance, potential use cases for ALTO application guidance in VPN environments are:
エンドポイントのアプリケーションの観点から見ると、VPNは他のIP接続ソリューションとそれほど変わらない可能性がありますが、VPNでのALTOトポロジの公開とガイダンスから恩恵を受けることができる特定のアプリケーションがいくつかあります。一般的なインターネットの場合と同様に、1つの利点は、アプリケーションが過度に測定する必要がないことです。たとえば、VPN環境でのALTOアプリケーションガイダンスの潜在的な使用例は次のとおりです。
o Enterprise application optimization: Enterprise customers often run distributed applications that exchange large amounts of data, e.g., for synchronization of replicated data bases. Network topology information could be useful for placement of replicas as well as for the scheduling of transfers.
o エンタープライズアプリケーションの最適化：エンタープライズのお客様は、複製されたデータベースの同期などのために、大量のデータを交換する分散アプリケーションを実行することがよくあります。ネットワークトポロジ情報は、レプリカの配置や転送のスケジューリングに役立ちます。
o Private cloud computing solution: An enterprise customer could run its own data centers at several sites. The cloud management system could want to understand the network costs between different sites for intelligent routing and placement decisions of Virtual Machines (VMs) among the VPN sites.
oプライベートクラウドコンピューティングソリューション：企業の顧客は、複数のサイトで独自のデータセンターを運営できます。クラウド管理システムは、VPNサイト間の仮想マシン（VM）のインテリジェントなルーティングと配置を決定するために、異なるサイト間のネットワークコストを理解する必要がある場合があります。
o Cloud-bursting: One or more VPN endpoints could be located in a public cloud. If an enterprise customer needs additional resources, they could be provided by a public cloud, which is accessed through the VPN. Network topology awareness would help to decide in which data center of the public cloud those resources should be allocated.
o クラウドバースト：1つ以上のVPNエンドポイントがパブリッククラウドに配置される可能性があります。企業の顧客が追加のリソースを必要とする場合、それらはVPNを介してアクセスされるパブリッククラウドによって提供される可能性があります。ネットワークトポロジの認識は、パブリッククラウドのどのデータセンターにこれらのリソースを割り当てるかを決定するのに役立ちます。
These examples focus on enterprises, which are typical users of VPNs. VPN customers typically have no insight into the network topology that transports the VPN. Similar to other ALTO use cases, better-than-random application-level decisions would be enabled by an ALTO server offered by the NSP, as illustrated in Figure 28.
これらの例は、VPNの一般的なユーザーである企業に焦点を当てています。 VPNの顧客は、通常、VPNを転送するネットワークトポロジーを理解できません。他のALTOの使用例と同様に、図28に示すように、NSPが提供するALTOサーバーによって、ランダムなアプリケーションレベルよりも優れた決定が可能になります。
+---------------+
| Customer's |
| management |
| application |.
| (ALTO client) | .
+---------------+ . VPN provisioning
/\ . (out-of-scope)
|| ALTO .
\/ .
+---------------------+ +----------------+
| ALTO server | | VPN portal/OSS |
| provided by NSP | | (out-of-scope) |
+---------------------+ +----------------+
: VPN network
: and cost maps
:
/---------:---------\ Network service provider
| : |
+-------+ _______________________ +-------+
| App a | ()_____. .________. .____() | App d |
+-------+ | | | | | | +-------+
\---| |--------| |--/
| | | |
|^| |^| Customer VPN
V V
+-------+ +-------+
| App b | | App c |
+-------+ +-------+
Figure 28: Using ALTO in VPNs
図28：VPNでのALTOの使用
A common characteristic of these use cases is that applications will not necessarily run in the public Internet, and that the relationship between the provider and customer of the VPN is rather well defined. Since VPNs often run in a managed environment, an ALTO server may have access to topology information (e.g., traffic engineering data) that would not be available for the public Internet, and it may expose it to the customer of the VPN only.
これらの使用例の共通の特徴は、アプリケーションが必ずしもパブリックインターネットで実行されるわけではないこと、およびVPNのプロバイダーとカスタマー間の関係がかなり明確になっていることです。 VPNは管理された環境で実行されることが多いため、ALTOサーバーは公衆インターネットでは利用できないトポロジ情報（トラフィックエンジニアリングデータなど）にアクセスでき、VPNの顧客にのみ公開される可能性があります。
Also, a VPN will not necessarily be static. The customer could possibly modify the VPN and add new VPN sites by a Web portal, network management systems, or other OSS solutions. Prior to adding a new VPN site, an application will not have connectivity to that site, i.e., an ALTO server could offer access to information that an application cannot measure on its own (e.g., expected delay to a new VPN site).
また、VPNは必ずしも静的ではありません。顧客は、VPNを変更し、Webポータル、ネットワーク管理システム、または他のOSSソリューションによって新しいVPNサイトを追加する可能性があります。新しいVPNサイトを追加する前は、アプリケーションはそのサイトに接続できません。つまり、ALTOサーバーは、アプリケーション自体では測定できない情報（新しいVPNサイトへの予想される遅延など）へのアクセスを提供できます。
The VPN use cases, requirements, and solutions are further detailed in [VPN-SERVICE].
VPNの使用例、要件、およびソリューションについては、[VPN-SERVICE]で詳しく説明しています。
Deployment of intra-domain P2P caches has been proposed for cooperation between the network operator and the P2P service providers, e.g., to reduce the bandwidth consumption in access networks [ALTO-P2PCACHE].
ドメイン内P2Pキャッシュの展開は、ネットワークオペレーターとP2Pサービスプロバイダーの間の連携のために提案されています。たとえば、アクセスネットワークの帯域幅消費を削減するために[ALTO-P2PCACHE]。
+--------------+ +------+
| ISP 1 network+----------------+Peer 1|
+-----+--------+ +------+
|
+--------+------------------------------------------------------+
| | ISP 2 network |
| +---------+ |
| |L1 Cache | |
| +-----+---+ |
| +--------------------+----------------------+ |
| | | | |
| +------+------+ +------+-------+ +------+-------+ |
| | AN1 | | AN2 | | AN3 | |
| | +---------+ | | +----------+ | | | |
| | |L2 Cache | | | |L2 Cache | | | | |
| | +---------+ | | +----------+ | | | |
| +------+------+ +------+-------+ +------+-------+ |
| | | |
| +--------------------+ | |
| | | | |
| +------+------+ +------+-------+ +------+-------+ |
| | SUB-AN11 | | SUB-AN12 | | SUB-AN31 | |
| | +---------+ | | | | | |
| | |L3 Cache | | | | | | |
| | +---------+ | | | | | |
| +------+------+ +------+-------+ +------+-------+ |
| | | | |
+--------+--------------------+----------------------+----------+
| | |
+---+---+ +---+---+ |
| | | | |
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+
|Peer2| |Peer3| |Peer4| |Peer5| |Peer6|
+-----+ +-----+ +-----+ +-----+ +-----+
Figure 29: General Architecture of Intra-ISP Caches
図29：ISP内キャッシュの一般的なアーキテクチャ
Figure 29 depicts the overall architecture of potential P2P cache deployments inside an ISP 2 with various access network types. As shown in the figure, P2P caches may be deployed at various levels, including the interworking gateway linking with other ISPs, internal access network gateways linking with different types of accessing networks (e.g., WLAN, cellular, and wired), and even within an accessing network at the entries of individual WLAN subnetworks. Moreover, depending on the network context and the operator's policy, each cache can be a Forwarding Cache or a Bidirectional Cache [ALTO-P2PCACHE].
図29は、さまざまなアクセスネットワークタイプを備えたISP 2内の潜在的なP2Pキャッシュ配置の全体的なアーキテクチャを示しています。図に示すように、P2Pキャッシュは、他のISPとリンクするインターワーキングゲートウェイ、さまざまなタイプのアクセスネットワーク（WLAN、セルラー、有線など）とリンクする内部アクセスネットワークゲートウェイ、さらには個々のWLANサブネットワークのエントリでネットワークにアクセスします。さらに、ネットワークコンテキストとオペレーターのポリシーに応じて、各キャッシュは転送キャッシュまたは双方向キャッシュになる場合があります[ALTO-P2PCACHE]。
In such a cache architecture, the locations of caches could be used as dividers of different PIDs to guide intra-ISP network abstraction and mark costs among them according to the location and type of relevant caches.
このようなキャッシュアーキテクチャでは、キャッシュの場所をさまざまなPIDの仕切りとして使用して、ISP内ネットワークの抽象化を導き、関連するキャッシュの場所と種類に応じてそれらの間のコストをマークできます。
Further details and deployment considerations can be found in [ALTO-P2PCACHE].
詳細と展開に関する考慮事項は、[ALTO-P2PCACHE]にあります。
An ALTO server can be part of an overall framework for Application-Based Network Operations (ABNO) [RFC7491] that brings together different technologies. Such an architecture may include additional components such as a PCE for on-demand and application-specific reservation of network connectivity, reliability, and resources (such as bandwidth). Some use cases how to leverage ALTO for joint network and application-layer optimization are explained in [RFC7491].
ALTOサーバーは、さまざまなテクノロジーを統合するアプリケーションベースのネットワーク操作（ABNO）[RFC7491]の全体的なフレームワークの一部にすることができます。このようなアーキテクチャには、ネットワーク接続、信頼性、およびリソース（帯域幅など）のオンデマンドおよびアプリケーション固有の予約のためのPCEなどの追加コンポーネントが含まれる場合があります。共同ネットワークとアプリケーション層の最適化にALTOを活用するいくつかの使用例は、[RFC7491]で説明されています。
Security concerns were extensively discussed from the very beginning of the development of the ALTO protocol, and they have been considered in detail in the ALTO requirements document [RFC6708] as well as in the ALTO protocol specification document [RFC7285]. The two main security concerns are related to the unwanted disclosure of information through ALTO and the negative impact of specially crafted, wrong ("faked") guidance presented to an ALTO client. In addition to this, the usual concerns related to the operation of any networked application apply.
セキュリティの問題は、ALTOプロトコルの開発の最初から広範囲にわたって議論されており、ALTO要件ドキュメント[RFC6708]とALTOプロトコル仕様ドキュメント[RFC7285]で詳細に検討されています。 2つの主要なセキュリティ上の懸念は、ALTOを介した情報の望ましくない開示と、ALTOクライアントに提示される特別に細工された、誤った（「偽造された」）ガイダンスの悪影響です。これに加えて、ネットワークアプリケーションの操作に関連する通常の問題が適用されます。
This section focuses on the peer-to-peer use case, which is -- from a security perspective -- probably the most difficult ALTO use case that has been considered. Special attention is given to the two main security concerns.
このセクションでは、ピアツーピアのユースケースに焦点を当てます。これは、セキュリティの観点から、おそらく検討されてきた最も難しいALTOのユースケースです。 2つの主要なセキュリティ問題に特別な注意が払われます。
The optimization of peer-to-peer applications was the first use case and the impetus for the development of the ALTO protocol, in particular, file sharing applications such as BitTorrent [RFC5594].
ピアツーピアアプリケーションの最適化は、ALTOプロトコル、特にBitTorrent [RFC5594]などのファイル共有アプリケーションの開発の最初のユースケースと推進力でした。
As explained in Section 4.1.1, for the publisher of the ALTO information (i.e., the ALTO server operator), it may not be apparent who is in charge of the P2P application overlay. Some P2P applications do not have any central control entity and the whole overlay consists only of the peers, which are under control of the individual users. Other P2P applications may have some control entities such as super peers or trackers, but these may be located in foreign countries and under the control of unknown organizations. As outlined in Section 4.2.2, in some scenarios, it may be very beneficial to forward ALTO information to such trackers, super peers, etc., located in remote networks. This situation is aggravated by the vast number of different P2P applications that are evolving quickly and often without any coordination with the network operators.
セクション4.1.1で説明したように、ALTO情報の発行者（つまり、ALTOサーバーオペレーター）にとっては、P2Pアプリケーションオーバーレイの担当者が明確でない場合があります。一部のP2Pアプリケーションには中央制御エンティティがなく、オーバーレイ全体は、個々のユーザーの制御下にあるピアのみで構成されています。他のP2Pアプリケーションには、スーパーピアやトラッカーなどの制御エンティティが含まれる場合がありますが、これらは海外にあり、不明な組織の制御下にある場合があります。セクション4.2.2で概説されているように、いくつかのシナリオでは、ALTO情報をリモートネットワークにあるそのようなトラッカー、スーパーピアなどに転送することが非常に有益な場合があります。この状況は、ネットワークオペレーターとの調整なしに、急速かつ頻繁に進化する膨大な数のさまざまなP2Pアプリケーションによって悪化します。
In summary, it can be said that in many instances of the P2P use case, the ALTO protocol bridges the border between the "managed" IP network infrastructure under strict administrative control and one or more "unmanaged" application overlays, i.e., overlays for which it is hard to tell who is in charge of them. This differs from more-controlled environments (e.g., in the CDN use case), in which bilateral agreements between the producer and consumer of guidance are possible.
要約すると、P2Pユースケースの多くの場合、ALTOプロトコルは厳密な管理制御下の「管理対象」IPネットワークインフラストラクチャと1つ以上の「管理対象外」アプリケーションオーバーレイ、つまり、誰が担当しているかはわかりません。これは、ガイダンスの生産者と消費者の間で二国間協定が可能である、より制御された環境（たとえば、CDNユースケース）とは異なります。
An ALTO server will be provisioned with information about the ISP's network and possibly also with information about neighboring ISPs. This information (e.g., network topology, business relations, etc.) is often considered to be confidential to the ISP and can include very sensitive information. 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.
ALTOサーバーには、ISPのネットワークに関する情報と、場合によっては隣接するISPに関する情報がプロビジョニングされます。この情報（ネットワークトポロジ、ビジネス関係など）は、ISPの機密情報であると見なされることが多く、非常に機密情報が含まれる場合があります。 ALTOは、特定レベルの情報開示の詳細を要求しません。したがって、プロバイダーは、公開される情報の量と関連するリスクを評価する必要があります。
Furthermore, if the ALTO information is very fine grained, it may also be considered sensitive with respect to user privacy. For example, consider a hypothetical endpoint property "provisioned access link bandwidth" or "access technology (ADSL, VDSL, FTTH, etc.)" and an ALTO service that publishes this property for individual IP addresses. This information could not only be used for traffic optimization but, for example, also for targeted advertising to residential users with exceptionally good (or bad) connectivity, such as special banner ads. For an advertisement system, it would be more complex to obtain such information otherwise, e.g., by bandwidth probing.
さらに、ALTO情報が非常に細かい場合、ユーザーのプライバシーに関して機密情報と見なされることもあります。たとえば、「プロビジョニングされたアクセスリンク帯域幅」または「アクセステクノロジー（ADSL、VDSL、FTTHなど）」という架空のエンドポイントプロパティと、個々のIPアドレスに対してこのプロパティを公開するALTOサービスについて考えてみます。この情報は、トラフィックの最適化だけでなく、たとえば、特別なバナー広告など、接続性が非常に良い（または悪い）住宅ユーザーへのターゲット広告にも使用できます。広告システムの場合、そうでなければ、たとえば帯域幅調査などによって、そのような情報を取得することはより複雑になります。
Different scenarios related to the unwanted disclosure of an ALTO server's information have been itemized and categorized in RFC 6708, Section 5.2.1., cases (1)-(3) [RFC6708].
ALTOサーバーの情報の不要な開示に関連するさまざまなシナリオが、RFC 6708のセクション5.2.1の項目（1）〜（3）[RFC6708]で項目化および分類されています。
In some use cases, it is not possible to use access control (see Section 7.3) to limit the distribution of ALTO knowledge to a small set of trusted clients. In these scenarios, it seems tempting not to use network maps and cost maps at all, and instead completely rely on ECS and endpoint ranking in the ALTO server. While this practice may indeed reduce the amount of information that is disclosed to an individual ALTO client, some issues should be considered: first, when using the map-based approach, it is trivial to analyze the maximum amount of information that could be disclosed to a client -- the full maps. In contrast, when providing endpoint-cost service only, the ALTO server operator could be prone to a false feeling of security, while clients use repeated queries and/or collaboration to gather more information than they are expected to get (see Section 5.2.1., case (3) in [RFC6708]). Second, the ECS reveals more information about the user or application behavior to the ALTO server, e.g., which other hosts are considered as peers for the exchange of a significant amount of data (see Section 5.2.1., cases (4)-(6) in [RFC6708]).
一部の使用例では、アクセス制御（セクション7.3を参照）を使用して、ALTOナレッジの配布を信頼できるクライアントの小さなセットに制限することができない場合があります。これらのシナリオでは、ネットワークマップやコストマップをまったく使用せず、代わりに完全にALTOサーバーのECSおよびエンドポイントランキングに依存するのが魅力的です。この方法により、実際に個々のALTOクライアントに開示される情報の量が減る可能性がありますが、いくつかの問題を考慮する必要があります。まず、マップベースのアプローチを使用する場合、開示できる情報の最大量を分析するのは簡単です。クライアント-フルマップ。対照的に、エンドポイントコストのサービスのみを提供する場合、ALTOサーバーオペレーターは誤った安心感を抱きやすい一方で、クライアントは繰り返しのクエリやコラボレーションを使用して、予想以上の情報を収集します（セクション5.2.1を参照）。 、[RFC6708]のケース（3））。第2に、ECSはユーザーまたはアプリケーションの動作に関する詳細情報をALTOサーバーに明らかにします。たとえば、他のどのホストが大量のデータ交換のピアと見なされるか（セクション5.2.1のケース（4）〜（ 6）[RFC6708]で）。
Consequently, users may be more reluctant to use the ALTO service at all if it is based on the ECS instead of providing network and cost maps. Given that some popular P2P applications are sometimes used for purposes such as distribution of files without the explicit permission from the copyright owner, it may also be in the interest of the ALTO server operator that an ALTO server cannot infer the behavior of the application to be optimized. One possible conclusion could be to publish network and cost maps through ALTO that are so coarse grained that they do not violate the network operator's or the user's interests.
その結果、ユーザーは、ネットワークやコストのマップを提供する代わりに、ECSに基づいている場合は、ALTOサービスを使用することに抵抗を感じる可能性があります。一部の一般的なP2Pアプリケーションは、著作権所有者からの明示的な許可なしにファイルの配布などの目的で使用されることがあるので、ALTOサーバーがアプリケーションの動作を推測できないことは、ALTOサーバーオペレーターの利益になる場合もあります。最適化。考えられる結論の1つは、ALTOを介してネットワークとコストのマップを公開することです。このマップは、ネットワークオペレーターやユーザーの利益に違反しないほど粗いものです。
In other use cases, in more-controlled environments (e.g., in the CDN use case) bilateral agreements, access control (see Section 7.3), and encryption could be used to reduce the risk of information leakage.
他のユースケースでは、より制御された環境（CDNユースケースなど）で、二国間合意、アクセス制御（セクション7.3を参照）、および暗号化を使用して、情報漏えいのリスクを軽減できます。
Depending on the use case of ALTO, it may be desired to apply access restrictions to an ALTO server, i.e., by requiring client authentication. According to [RFC7285], ALTO requires that HTTP Digest Authentication be supported, in order to achieve client authentication and possibly to limit the number of parties with whom ALTO information is directly shared. TLS Client Authentication may also be supported.
ALTOの使用例によっては、クライアント認証を要求するなどして、ALTOサーバーにアクセス制限を適用することが望ましい場合があります。 [RFC7285]によると、クライアント認証を実現し、ALTO情報を直接共有する相手の数を制限するために、ALTOではHTTPダイジェスト認証がサポートされている必要があります。 TLSクライアント認証もサポートされる場合があります。
In general, well-known security management techniques and best current practices [RFC4778] for operational ISP infrastructure also apply to an ALTO service, including functions to protect the system from unauthorized access, key management, reporting security-relevant events, and authorizing user access and privileges.
一般に、運用ISPインフラストラクチャのよく知られたセキュリティ管理手法と現在のベストプラクティス[RFC4778]は、システムを不正アクセスから保護する機能、キー管理、セキュリティ関連イベントの報告、ユーザーアクセスの承認などのALTOサービスにも適用されますと特権。
For peer-to-peer applications, a potential deployment scenario is that an ALTO server is solely accessible by peers from the ISP network (as shown in Figure 21). For instance, the source IP address can be used to grant only access from that ISP network to the server. This will "limit" the number of peers able to attack the server to the user's of the ISP (however, including compromised computers that are part of a botnet).
ピアツーピアアプリケーションの場合、潜在的な展開シナリオは、ALTOサーバーがISPネットワークからピアによってのみアクセス可能であるというものです（図21を参照）。たとえば、送信元IPアドレスを使用して、そのISPネットワークからサーバーへのアクセスのみを許可できます。これにより、サーバーを攻撃できるピアの数がISPのユーザーに "制限"されます（ただし、ボットネットの一部である侵害されたコンピューターを含みます）。
If the ALTO server has to be accessible by parties not located in the ISP's network (see Figure 22), e.g., by a third-party tracker or by a CDN system outside the ISP's network, the access restrictions have to be looser. In the extreme case, i.e., no access restrictions, each and every host in the Internet can access the ALTO server. This might not be the intention of the ISP, as the server is not only subject to more possible attacks, but also the server load could increase, since possibly more ALTO clients have to be served.
サードパーティのトラッカーやISPのネットワーク外のCDNシステムなど、ISPのネットワークにないパーティ（図22を参照）がALTOサーバーにアクセスできるようにする必要がある場合は、アクセス制限を緩和する必要があります。極端な場合、つまりアクセス制限がない場合、インターネット内のすべてのホストがALTOサーバーにアクセスできます。サーバーがより多くの攻撃を受ける可能性があるだけでなく、サーバーの負荷が増加する可能性があるため、これはISPの意図ではない可能性があります。
There are also use cases where the access to the ALTO server has to be much more strictly controlled, i.e., where an authentication and authorization of the ALTO client to the server may be needed. For instance, in case of CDN optimization, the provider of an ALTO service as well as potential users are possibly well-known. Only CDN entities may need ALTO access; access to the ALTO servers by residential users may neither be necessary nor be desired.
ALTOサーバーへのアクセスをより厳密に制御する必要があるユースケースもあります。つまり、サーバーに対するALTOクライアントの認証と承認が必要になる場合があります。たとえば、CDN最適化の場合、ALTOサービスのプロバイダーと潜在的なユーザーがよく知られています。 ALTOアクセスが必要なのはCDNエンティティのみです。住宅ユーザーによるALTOサーバーへのアクセスは、必要でも希望でもありません。
Access control can also help to prevent Denial-of-Service (DoS) attacks by arbitrary hosts from the Internet. DoS can both affect an ALTO server and an ALTO client. A server can get overloaded if too many requests hit the server, or if the query load of the server surpasses the maximum computing capacity. An ALTO client can get overloaded if the responses from the sever are, either intentionally or due to an implementation mistake, too large to be handled by that particular client.
アクセス制御は、インターネットからの任意のホストによるサービス拒否（DoS）攻撃の防止にも役立ちます。 DoSは、ALTOサーバーとALTOクライアントの両方に影響を与える可能性があります。サーバーにヒットする要求が多すぎる場合、またはサーバーのクエリ負荷が最大計算能力を超える場合、サーバーは過負荷になる可能性があります。 ALTOクライアントは、サーバーからの応答が意図的にまたは実装の誤りが原因で大きすぎて、特定のクライアントで処理するには大きすぎる場合、過負荷になる可能性があります。
The ALTO services enables an ALTO service provider to influence the behavior of network applications. An attacker who is able to generate false replies, or e.g. an attacker who can intercept the ALTO server discovery procedure, can provide faked ALTO guidance.
ALTOサービスを使用すると、ALTOサービスプロバイダーはネットワークアプリケーションの動作に影響を与えることができます。偽の応答を生成できる攻撃者、またはALTOサーバーの検出手順を傍受できる攻撃者は、偽のALTOガイダンスを提供できます。
Here is a list of examples of how the ALTO guidance could be faked and what possible consequences may arise:
以下は、ALTOガイダンスがどのように偽造される可能性があり、どのような結果が生じる可能性があるかを示す例のリストです。
Sorting: An attacker could change the sorting order of the ALTO guidance (given that the order is of importance; otherwise, the ranking mechanism is of interest), i.e., declaring peers located outside the ISP as peers to be preferred. This will not pose a big risk to the network or peers, as it would mimic the "regular" peer operation without traffic localization, apart from the communication/processing overhead for ALTO. However, it could mean that ALTO is reaching the opposite goal of shuffling more data across ISP boundaries, incurring more costs for the ISP. In another example, fake guidance could give unrealistically low costs to devices in an ISP's mobile network, thus encouraging other devices to contact them, thereby degrading the ISP's mobile network and causing customer dissatisfaction.
並べ替え：攻撃者は、ALTOガイダンスの並べ替え順序を変更する可能性があります（順序が重要である場合、それ以外の場合は、ランキングメカニズムが重要です）。つまり、ISPの外部にあるピアを優先ピアとして宣言します。これは、ALTOの通信/処理オーバーヘッドを除いて、トラフィックのローカライズなしの「通常の」ピア操作を模倣するため、ネットワークまたはピアに大きなリスクをもたらすことはありません。ただし、ALTOがISPの境界を越えてより多くのデータをシャッフルするという反対の目標に達しており、ISPのコストが増えることを意味している可能性があります。別の例では、偽のガイダンスはISPのモバイルネットワーク内のデバイスに非現実的な低コストをもたらし、他のデバイスがそれらに連絡するように促し、それによってISPのモバイルネットワークを劣化させ、顧客の不満を引き起こす可能性があります。
Preference of a single peer: A single IP address (thus a peer) could be marked as to be preferred over all other peers. This peer can be located within the local ISP or also in other parts of the Internet (e.g., a web server). This could lead to the case that quite a number of peers to trying to contact this IP address, possibly causing a DoS attack.
単一のピアの優先度：単一のIPアドレス（つまり、ピア）は、他のすべてのピアよりも優先されるようにマークできます。このピアは、ローカルISP内、またはインターネットの他の部分（Webサーバーなど）にも配置できます。これにより、かなりの数のピアがこのIPアドレスにアクセスしようとし、DoS攻撃を引き起こす可能性があります。
The ALTO protocol protects the authenticity and integrity of ALTO information while in transit by leveraging the authenticity and integrity protection mechanisms in TLS (see Section 8.3.5 of [RFC7285]). It has not yet been investigated how wrong ALTO guidance given by an authenticated ALTO server can impact the operation of the network and the applications.
ALTOプロトコルは、TLSの信頼性と整合性の保護メカニズムを活用することで、転送中のALTO情報の信頼性と整合性を保護します（[RFC7285]のセクション8.3.5を参照）。認証されたALTOサーバーによって提供される間違ったALTOガイダンスがネットワークとアプリケーションの動作にどのように影響するかはまだ調査されていません。
[ALTO-REG] IANA, "Application-Layer Traffic Optimization (ALTO) Protocol", <http://www.iana.org/assignments/alto-protocol>.
[ALTO-REG] IANA、「Application-Layer Traffic Optimization（ALTO）Protocol」、<http://www.iana.org/assignments/alto-protocol>。
[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic Optimization (ALTO) Problem Statement", RFC 5693, DOI 10.17487/RFC5693, October 2009, <http://www.rfc-editor.org/info/rfc5693>.
[RFC5693] Seedorf、J。およびE. Burger、「Application-Layer Traffic Optimization（ALTO）Problem Statement」、RFC 5693、DOI 10.17487 / RFC5693、2009年10月、<http://www.rfc-editor.org/info / rfc5693>。
[RFC6708] Kiesel, S., Ed., Previdi, S., Stiemerling, M., Woundy, R., and Y. Yang, "Application-Layer Traffic Optimization (ALTO) Requirements", RFC 6708, DOI 10.17487/RFC6708, September 2012, <http://www.rfc-editor.org/info/rfc6708>.
[RFC6708]キーゼル、S。、編、Previdi、S.、Stiemerling、M.、Woundy、R。、およびY. Yang、「Application-Layer Traffic Optimization（ALTO）Requirements」、RFC 6708、DOI 10.17487 / RFC6708 、2012年9月、<http://www.rfc-editor.org/info/rfc6708>。
[RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., Previdi, S., Roome, W., Shalunov, S., and R. Woundy, "Application-Layer Traffic Optimization (ALTO) Protocol", RFC 7285, DOI 10.17487/RFC7285, September 2014, <http://www.rfc-editor.org/info/rfc7285>.
[RFC7285]アリミ、R。、エド、ペンノ、R。、エド、ヤン、Y。、エド、キーゼル、S。、プレビディ、S。、ルーム、W。、シャルノフ、S.、R。 Woundy、「Application-Layer Traffic Optimization（ALTO）Protocol」、RFC 7285、DOI 10.17487 / RFC7285、2014年9月、<http://www.rfc-editor.org/info/rfc7285>。
[RFC7286] Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., and H. Song, "Application-Layer Traffic Optimization (ALTO) Server Discovery", RFC 7286, DOI 10.17487/RFC7286, November 2014, <http://www.rfc-editor.org/info/rfc7286>.
[RFC7286]キーゼル、S。、スティームリング、M。、シュワン、N。、シャーフ、M。、およびH.ソング、「アプリケーション層トラフィック最適化（ALTO）サーバーの発見」、RFC 7286、DOI 10.17487 / RFC7286、11月2014、<http://www.rfc-editor.org/info/rfc7286>。
[ALTO-CDN] Penno, R., Medved, J., Alimi, R., Yang, R., and S. Previdi, "ALTO and Content Delivery Networks", Work in Progress, draft-penno-alto-cdn-03, March 2011.
[ALTO-CDN] Penno、R.、Medved、J.、Alimi、R.、Yang、R.、and S. Previdi、 "ALTO and Content Delivery Networks"、Work in Progress、draft-penno-alto-cdn- 2011年3月3日。
[ALTO-H12] Kiesel, S. and M. Stiemerling, "ALTO H12", Work in Progress, draft-kiesel-alto-h12-02, March 2010.
[ALTO-H12]キーゼル、S。、およびM.スティーマーリング、「ALTO H12」、作業中、draft-kiesel-alto-h12-02、2010年3月。
[ALTO-P2PCACHE] Lingli, D., Chen, W., Yi, Q., and Y. Zhang, "Considerations for ALTO with network-deployed P2P caches", Work in Progress, draft-deng-alto-p2pcache-03, February 2014.
[ALTO-P2PCACHE] Lingli、D.、Chen、W.、Yi、Q。、およびY. Zhang、「ネットワークにデプロイされたP2Pキャッシュを使用したALTOに関する考慮事項」、進行中の作業、draft-deng-alto-p2pcache-03 、 2014年2月。
[CDN-USE] Niven-Jenkins, B., Watson, G., Bitar, N., Medved, J., and S. Previdi, "Use Cases for ALTO within CDNs", Work in Progress, draft-jenkins-alto-cdn-use-cases-03, June 2012.
[CDN-USE] Niven-Jenkins、B.、Watson、G.、Bitar、N.、Medved、J。、およびS. Previdi、「CDN内のALTOの使用例」、Work in Progress、draft-jenkins-alto -cdn-use-cases-03、2012年6月。
[CDNI-FCI] Seedorf, J., Yang, Y., and J. Peterson, "CDNI Footprint and Capabilities Advertisement using ALTO", Work in Progress, draft-seedorf-cdni-request-routing-alto-08, March 2015.
[CDNI-FCI] Seedorf、J.、Yang、Y.、J。Peterson、「CDNI Footprint and Capabilities Advertisement using ALTO」、Work in Progress、draft-seedorf-cdni-request-routing-alto-08、2015年3月。
[CHINA-TRIAL] Li, K. and G. Jian, "ALTO and DECADE service trial within China Telecom", Work in Progress, draft-lee-alto-chinatelecom-trial-04, March 2012.
[CHINA-TRIAL] Li、K。およびG. Jian、「China Telecom内のALTOおよびDECADEサービス裁判」、Work in Progress、draft-lee-alto-chinatelecom-trial-04、2012年3月。
[MAP-CALC] Seidel, H., "ALTO map calculation from live network data", Work in Progress, draft-seidel-alto-map-calculation-00, October 2015.
[MAP-CALC] Seidel、H.、「ライブネットワークデータからのALTOマップ計算」、Work in Progress、draft-seidel-alto-map-calculation-00、2015年10月。
[NETWORK-TOPO] Clemm, A., Medved, J., Varga, R., Tkacik, T., Bahadur, N., Ananthakrishnan, H., and X. Liu, "A Data Model for Network Topologies", Work in Progress, draft-ietf-i2rs-yang-network-topo-06, September 2016.
[NETWORK-TOPO] Clemm、A.、Medved、J.、Varga、R.、Tkacik、T.、Bahadur、N.、Ananthakrishnan、H。、およびX. Liu、「ネットワークトポロジのデータモデル」、Work進行中、draft-ietf-i2rs-yang-network-topo-06、2016年9月。
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, DOI 10.17487/RFC3411, December 2002, <http://www.rfc-editor.org/info/rfc3411>.
[RFC3411] Harrington、D.、Presuhn、R。、およびB. Wijnen、「単純なネットワーク管理プロトコル（SNMP）管理フレームワークを記述するためのアーキテクチャ」、STD 62、RFC 3411、DOI 10.17487 / RFC3411、2002年12月、<http ：//www.rfc-editor.org/info/rfc3411>。
[RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known Content Network (CN) Request-Routing Mechanisms", RFC 3568, DOI 10.17487/RFC3568, July 2003, <http://www.rfc-editor.org/info/rfc3568>.
[RFC3568] Barbir、A.、Cain、B.、Nair、R。、およびO. Spatscheck、「既知のコンテンツネットワーク（CN）要求ルーティングメカニズム」、RFC 3568、DOI 10.17487 / RFC3568、2003年7月、<http： //www.rfc-editor.org/info/rfc3568>。
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, DOI 10.17487/RFC4026, March 2005, <http://www.rfc-editor.org/info/rfc4026>.
[RFC4026] Andersson、L。およびT. Madsen、「Provider Provisioned Virtual Private Network（VPN）Terminology」、RFC 4026、DOI 10.17487 / RFC4026、2005年3月、<http://www.rfc-editor.org/info/ rfc4026>。
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, <http://www.rfc-editor.org/info/rfc4655>.
[RFC4655] Farrel、A.、Vasseur、J。、およびJ. Ash、「A Path Computation Element（PCE）-Based Architecture」、RFC 4655、DOI 10.17487 / RFC4655、2006年8月、<http：//www.rfc -editor.org/info/rfc4655>。
[RFC4778] Kaeo, M., "Operational Security Current Practices in Internet Service Provider Environments", RFC 4778, DOI 10.17487/RFC4778, January 2007, <http://www.rfc-editor.org/info/rfc4778>.
[RFC4778] Kaeo、M。、「インターネットサービスプロバイダー環境における運用上のセキュリティの現在の実践」、RFC 4778、DOI 10.17487 / RFC4778、2007年1月、<http://www.rfc-editor.org/info/rfc4778>。
[RFC5594] Peterson, J. and A. Cooper, "Report from the IETF Workshop on Peer-to-Peer (P2P) Infrastructure, May 28, 2008", RFC 5594, DOI 10.17487/RFC5594, July 2009, <http://www.rfc-editor.org/info/rfc5594>.
[RFC5594] Peterson、J。およびA. Cooper、「ピアツーピア（P2P）インフラストラクチャに関するIETFワークショップからのレポート、2008年5月28日」、RFC 5594、DOI 10.17487 / RFC5594、2009年7月、<http：/ /www.rfc-editor.org/info/rfc5594>。
[RFC5632] Griffiths, C., Livingood, J., Popkin, L., Woundy, R., and Y. Yang, "Comcast's ISP Experiences in a Proactive Network Provider Participation for P2P (P4P) Technical Trial", RFC 5632, DOI 10.17487/RFC5632, September 2009, <http://www.rfc-editor.org/info/rfc5632>.
[RFC5632] Griffiths、C.、Livingood、J.、Popkin、L.、Woundy、R。、およびY. Yang、「ComcastのISPエクスペリエンスにおけるP2P（P4P）テクニカルトライアルのプロアクティブネットワークプロバイダー参加」、RFC 5632、 DOI 10.17487 / RFC5632、2009年9月、<http://www.rfc-editor.org/info/rfc5632>。
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, <http://www.rfc-editor.org/info/rfc6020>.
[RFC6020] Bjorklund、M。、編、「YANG-ネットワーク構成プロトコル（NETCONF）のデータモデリング言語」、RFC 6020、DOI 10.17487 / RFC6020、2010年10月、<http：//www.rfc-editor。 org / info / rfc6020>。
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <http://www.rfc-editor.org/info/rfc6241>.
[RFC6241] Enns、R。、編、Bjorklund、M。、編、Schoenwaelder、J。、編、およびA. Bierman、編、「Network Configuration Protocol（NETCONF）」、RFC 6241、DOI 10.17487 / RFC6241、2011年6月、<http://www.rfc-editor.org/info/rfc6241>。
[RFC6875] Kamei, S., Momose, T., Inoue, T., and T. Nishitani, "The P2P Network Experiment Council's Activities and Experiments with Application-Layer Traffic Optimization (ALTO) in Japan", RFC 6875, DOI 10.17487/RFC6875, February 2013, <http://www.rfc-editor.org/info/rfc6875>.
[RFC6875]カメイS.、モモセT.、イノウエT.、およびニシタニT.「日本におけるP2Pネットワーク実験評議会の活動とアプリケーション層トラフィック最適化（ALTO）の実験」、RFC 6875、DOI 10.17487 / RFC6875、2013年2月、<http://www.rfc-editor.org/info/rfc6875>。
[RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for Application-Based Network Operations", RFC 7491, DOI 10.17487/RFC7491, March 2015, <http://www.rfc-editor.org/info/rfc7491>.
[RFC7491]キング、D。、およびA.ファレル、「アプリケーションベースのネットワーク操作のためのPCEベースのアーキテクチャ」、RFC 7491、DOI 10.17487 / RFC7491、2015年3月、<http://www.rfc-editor.org/ info / rfc7491>。
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10.17487/RFC7752, March 2016, <http://www.rfc-editor.org/info/rfc7752>.
[RFC7752] Gredler、H.、Ed。、Medved、J.、Previdi、S.、Farrel、A.、and S. Ray、 "North-bound Distribution of Link-State and Traffic Engineering（TE）Information using BGP" 、RFC 7752、DOI 10.17487 / RFC7752、2016年3月、<http://www.rfc-editor.org/info/rfc7752>。
[RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. Kumari, "Client Subnet in DNS Queries", RFC 7871, DOI 10.17487/RFC7871, May 2016, <http://www.rfc-editor.org/info/rfc7871>.
[RFC7871] Contavalli、C.、van der Gaast、W.、Lawrence、D。、およびW. Kumari、「DNSクエリのクライアントサブネット」、RFC 7871、DOI 10.17487 / RFC7871、2016年5月、<http：// www .rfc-editor.org / info / rfc7871>。
[RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. Nadeau, "An Architecture for the Interface to the Routing System", RFC 7921, DOI 10.17487/RFC7921, June 2016, <http://www.rfc-editor.org/info/rfc7921>.
[RFC7921] Atlas、A.、Halpern、J.、Hares、S.、Ward、D。、およびT. Nadeau、「An Routing for the Interface to the Routing System」、RFC 7921、DOI 10.17487 / RFC7921、2016年6月、<http://www.rfc-editor.org/info/rfc7921>。
[RFC7922] Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to the Routing System (I2RS) Traceability: Framework and Information Model", RFC 7922, DOI 10.17487/RFC7922, June 2016, <http://www.rfc-editor.org/info/rfc7922>.
[RFC7922] Clarke、J.、Salgueiro、G。、およびC. Pignataro、「Interface to the Routing System（I2RS）Traceability：Framework and Information Model」、RFC 7922、DOI 10.17487 / RFC7922、June 2016、<http：/ /www.rfc-editor.org/info/rfc7922>。
[UPDATE-SSE] Roome, W. and Y. Yang, "ALTO Incremental Updates Using Server-Sent Events (SSE)", Work in Progress, draft-ietf-alto-incr-update-sse-03, September 2016.
[UPDATE-SSE] Roome、W。およびY. Yang、「ALTOインクリメンタルアップデート（サーバー送信イベント（SSE）を使用）」、作業中、draft-ietf-alto-incr-update-sse-03、2016年9月。
[VPN-SERVICE] Scharf, M., Gurbani, V., Soprovich, G., and V. Hilt, "The Virtual Private Network (VPN) Service in ALTO: Use Cases, Requirements and Extensions", Work in Progress, draft-scharf-alto-vpn-service-02, February 2014.
[VPN-SERVICE] Scharf、M.、Gurbani、V.、Soprovich、G。、およびV. Hilt、「ALTOの仮想プライベートネットワーク（VPN）サービス：使用例、要件、拡張」、進行中の作業、ドラフト-scharf-alto-vpn-service-02、2014年2月。
[XDOM-DISC] Kiesel, S. and M. Stiemerling, "Application Layer Traffic Optimization (ALTO) Cross-Domain Server Discovery", Work in Progress, draft-kiesel-alto-xdom-disc-02, July 2016.
[XDOM-DISC]キーゼル、S。およびM.スティーマーリング、「アプリケーションレイヤートラフィック最適化（ALTO）クロスドメインサーバーディスカバリー」、作業中、draft-kiesel-alto-xdom-disc-02、2016年7月。
Acknowledgments
謝辞
This memo is the result of contributions made by several people:
このメモは、いくつかの人々による貢献の結果です：
o Xianghue Sun, Lee Kai, and Richard Yang contributed text on ISP deployment requirements and monitoring.
o Xianghue Sun、Lee Kai、およびRichard Yangは、ISPの展開要件と監視に関するテキストを寄稿しました。
o Rich Woundy contributed text to Section 3.3.
o Rich Woundyがセクション3.3にテキストを寄稿しました。
o Lingli Deng, Wei Chen, Qiuchao Yi, and Yan Zhang contributed Section 6.2.
o Lin glide ng、Wei Chen、Q IU朝Y i、Zhangのセクション6.2によるAndyの貢献。
Thomas-Rolf Banniza, Vinayak Hegde, Qin Wu, Wendy Roome, and Sabine Randriamasy provided very useful comments and reviewed the document.
Thomas-Rolf Banniza、Vinayak Hegde、Qin Wu、Wendy Roome、およびSabine Randriamasyは、非常に役立つコメントを提供し、ドキュメントをレビューしました。
Authors' Addresses
著者のアドレス
Martin Stiemerling Hochschule Darmstadt
ダルムシュタットのマーティンスティーマーリング大学
Email: mls.ietf@gmail.com
URI: http://ietf.stiemerling.org
Sebastian Kiesel University of Stuttgart Information Center Networks and Communication Systems Department Allmandring 30 Stuttgart 70550 Germany
セバスチャンキーゼルシュトゥットガルト大学情報センターネットワークおよび通信システム学科Allmandring 30シュトゥットガルト70550ドイツ
Email: ietf-alto@skiesel.de
Michael Scharf Nokia Lorenzstrasse 10 Stuttgart 70435 Germany
Michael Scharf Nokia Lorenzstrasse 10シュトゥットガルト70435ドイツ
Email: michael.scharf@nokia.com
Hans Seidel BENOCS GmbH Winterfeldtstrasse 21 Berlin 10781 Germany
Hans Seidel BENOCS GmbH Winterfeldtstrasse 21ベルリン10781ドイツ
Email: hseidel@benocs.com
Stefano Previdi Cisco Systems, Inc. Via Del Serafico 200 Rome 00191 Italy
Stefano Previdi Cisco Systems、Inc. Via Del Serafico 200 Rome 00191 Italy
Email: sprevidi@cisco.com