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
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.
许多Internet应用程序用于访问资源，如在不同主机上的多个等效副本中可用的信息片段或服务器进程。这包括但不限于对等文件共享应用程序。应用层流量优化（ALTO）的目标是为那些必须从一组能够提供所需资源的候选主机中选择一个或多个主机的应用程序提供指导。本备忘录讨论了ALTO的部署相关问题。它解决了ALTO的不同用例，如对等文件共享和内容交付网络（CDN），并给出了相应的示例。该文档还包括对计划部署ALTO的网络管理员和应用程序设计人员的建议，例如关于如何生成ALTO地图信息的建议。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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）的产品。它代表了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.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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
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].
许多Internet应用程序用于访问资源，如在不同主机上的多个等效副本中可用的信息片段或服务器进程。这包括但不限于对等（P2P）文件共享应用程序和内容交付网络（CDN）。应用层流量优化（ALTO）的目标是为那些必须从一组能够提供所需资源的候选主机中选择一个或多个主机的应用程序提供指导。[RFC5693]中描述了ALTO的基本思想和问题空间，[RFC6708]中讨论了需求集。[RFC7285]中规定了ALTO协议。[RFC7286]中定义了ALTO服务器发现过程。
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]是一种客户端/服务器协议，在多个ALTO客户端和一个ALTO服务器之间运行，如图1所示。下面，首先独立于实际用例审查ALTO实体的基线部署场景。具体示例将在本文档的其余部分中讨论。
+----------+
| ALTO |
| Server |
+----------+
^
_.-----|------.
,-'' | `--.
,' | `.
( Network | )
`. | ,'
`--. | _.-'
`------|-----''
v
+----------+ +----------+ +----------+
| ALTO | | ALTO |...| ALTO |
| Client | | Client | | Client |
+----------+ +----------+ +----------+
+----------+
| 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 server与使用单个物理服务器混淆。
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]中定义的术语“资源目录”。不得将该术语及其含义与“信息资源目录（IRD）”混淆，后者定义为ALTO协议[RFC7285]的一部分，即特定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
+--------------+
| 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。此外，同级ALTO客户端也可以类似方式使用，即使有跟踪器，如第4.1.2节所述。
+-----+
**| App |****
** +-----+ *
** * *
** * *
+-------+ +-------+ +--------------+ * *
| | | | | | +-----+ *
| |.....| | +-----------+ |*****| App | *
| | | |<===>|ALTO Client| | +-----+ *
+-------+ +-------+ +-----------+--+ * *
Source of ALTO Resource ** * *
topological Server directory ** * *
information ** +-----+ *
**| App |****
+-----+
Application
Legend:
=== ALTO protocol
*** Application protocol
... Provisioning protocol
+-----+
**| 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]。CDN实体还可以查询ALTO服务器，以获得有关访问CDN中数据的特定客户端在Internet服务提供商网络中的位置的指导，如第5节所述。
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
ALTO是一种通用协议，旨在广泛应用。在不同的用例中，应用程序、资源目录等可以对应不同的功能。本文档中列出的用例并不全面。这也意味着存在不同的问题
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服务器是否在同一互联网服务提供商（ISP）域中，或者客户端和ALTO服务器是否在不同域中管理/拥有/位于不同域中。
An ALTO deployment involves four kinds of entities:
ALTO部署涉及四种实体：
1. Source of topological information
1. 拓扑信息源
2. ALTO server
2. 中音服务器
3. ALTO client
3. 中音客户端
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服务的一个关键设计目标是，这四个角色中的每一个都可以分离，即它们可以由不同的组织或不相交的系统组件实现。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]中所述，由此可知，至少有三种不同类型的实体可以操作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. 网络运营商。网络服务提供商（NSP），如ISP，可能对其网络拓扑和策略有详细的了解。在这种情况下，拓扑信息的来源和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. 第三方。拓扑信息也可由不同于网络运营商的公司或组织收集，但已与一家或多家网络运营商签订了关于访问其拓扑信息和/或在其网络中进行测量的特定法律协议。此类实体的例子可以是CDN运营商或专门代表ISP提供ALTO服务的公司。
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服务器的运营商是一家网络运营商（例如，ISP或大型企业的网络部门），该运营商尤其为该网络的用户提供ALTO指导。
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服务器，或者由于连接问题或过载情况（另请参见[RFC6708]），没有收到对ALTO查询的响应，则使用ALTO的任何应用程序也必须工作。
There are basically two different approaches to how an ALTO server can provide network information and guidance:
对于ALTO服务器如何提供网络信息和指导，基本上有两种不同的方法：
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中，这种方法可以通过端点成本服务（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-ful（表示状态传输）协议，因此ALTO的操作员可以使用众所周知的技术来服务大型网站，例如负载平衡器，以便服务大量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独立运行ALTO服务器，而不考虑其他ISP。对于大多数设想中的ALTO部署来说，这可能是正确的，但某些部署可能具有不同的设置。图4显示了连接到两个上游提供商的大学网络的这种设置。NREN是一个国家研究和教育网络，提供到特定目的地（如其他大学）的廉价高速连接。ISP是一家商业上游提供商，该大学向其购买连接到所有无法通过NREN到达的目的地的连接。这所大学和ISP都在运营自己的ALTO服务器。位于大学网络中对等网络上的ALTO客户端将联系位于大学的ALTO服务器。
+-----------+
| ISP |
| ALTO |<==========================++
| Server | ||
+-----------+ ||
,-------. ,------. ||
,-' `-. ,-' `-. ||
/ Commercial \ / \ ||
( Upstream ) ( NREN ) ||
\ ISP / \ / ||
`-. ,-' `-. ,-' ||
`---+---' `+------' ||
| | ||
| | ||
|,-------------. | \/
,-+ `-+ +-----------+
,' University `. |University |
( Network ) | ALTO |
`. / | Server |
`-. +--' +-----------+
`+------------'| /\ /\
| | || ||
+--------+-+ +-+--------+ || ||
| Peer1 | | PeerN |<====++ ||
+----------+ +----------+ ||
/\ ||
|| ||
++======================================++
+-----------+
| ISP |
| ALTO |<==========================++
| Server | ||
+-----------+ ||
,-------. ,------. ||
,-' `-. ,-' `-. ||
/ Commercial \ / \ ||
( Upstream ) ( NREN ) ||
\ ISP / \ / ||
`-. ,-' `-. ,-' ||
`---+---' `+------' ||
| | ||
| | ||
|,-------------. | \/
,-+ `-+ +-----------+
,' University `. |University |
( Network ) | ALTO |
`. / | Server |
`-. +--' +-----------+
`+------------'| /\ /\
| | || ||
+--------+-+ +-+--------+ || ||
| Peer1 | | PeerN |<====++ ||
+----------+ +----------+ ||
/\ ||
|| ||
++======================================++
Legend:
=== ALTO protocol
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服务器也可能在回复ALTO客户端时包含ISP 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有助于减少域间流量。不同网络运营商的网络通过对等点互连。从业务角度来看，这些网络之间的流量交换需要网络间结算。这些对等协议可能代价高昂。为了降低这些成本，一个简单的目标是减少对等点之间的流量交换，从而尽可能将流量保持在自己的网络或自治系统中。
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. 网络内流量定位：对于大型网络运营商，网络可分为多个网络、域或ASE。核心网络包括一个或多个骨干网络，这些骨干网络连接到多个聚合、城域和接入网络。如果流量可以限制在某些区域，如接入网络，这将减少骨干网的使用，从而有助于节省资源和成本。
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
3. 网络卸载：与固定网络相比，移动网络具有一些特殊特性，包括较低的链路带宽、较高的成本、有限的射频资源和有限的终端电池。在移动网络中，应该有效地使用无线链路。例如，在P2P的情况下
service, it is likely that hosts should prefer retrieving data from hosts in fixed networks, and avoid retrieving data from mobile hosts.
服务，主机可能更喜欢从固定网络中的主机检索数据，而避免从移动主机检索数据。
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|
`-. ,-' +-----------+
`-------'
,-------. +-----------+
,---. ,-' `-. | 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"
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.
第3.5节中提供了相应ALTO地图的示例。根据应用特点，可能不可能或甚至不希望完全本地化所有流量。
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提供了在单个网络（例如，一个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"
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的这种使用尤其有益于移动网络。网络运营商可能希望引导其移动网络中的主机使用该移动网络之外的主机。一个原因可能是无线网络或移动主机不是为移动主机之间的直接对等通信而设计的，因此，对等方从互联网其他部分的远程对等方获取内容是有意义的。
,-------. +-----------+
,---. ,-' `-. | Host 1 |
,-' `-. / ISP 1 +-------|ALTO Client|
/ \ / (Mobile | \ +-----------+
/ ISP X \ | network) | | +-----------+
/ \ \ +-------| Host 2 |
; #############################|ALTO Client|
| # | `-. ,-' +-----------+
| # | `-------'
| # | ,-------.
: # ; ,-' `-.
\ # / / ISP 2 \
\ # / / (Fixed \
\ #/ | network) | +-----------+
`-. ,-# \ / | Host 3 |
`---' #############################|ALTO Client|
`-. ,-' +-----------+
`-------'
,-------. +-----------+
,---. ,-' `-. | 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"
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显示了这样一个指导过程的结果，其中主机2更喜欢与主机3连接，而不是与主机1连接，如图5所示。
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).
这种情况的实现可能有一定的局限性，并且不可能在所有情况下都实现。例如，它可能要求ALTO服务器根据其IP地址区分移动主机和非移动主机。这可能取决于移动性解决方案，可能不可能或不准确。一般来说，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
ALTO还可以提供优化网络应用程序的应用程序级拓扑的指导，例如，通过公开网络性能信息。应用程序通常可以运行自己的测量来确定网络性能，例如，通过主动延迟测量或带宽探测，但这种测量会导致开销和复杂性。访问ALTO服务器可能更简单
alternative. In addition, an ALTO server may also expose network information that applications cannot easily measure or reverse-engineer.
可供替代的此外，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 Network and Cost Map服务公开了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的网络拓扑，该拓扑表示使用ALTO服务（例如，网络和成本映射服务或ECS）的端点处的应用程序（资源消费者）应该理解和使用的网络。一个基本数据集可以通过从网络上获得的许多其他信息进行扩展。
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 abstract网络拓扑可以从网络的物理或逻辑拓扑自动生成，例如，使用“实时”网络数据。生成通常基于网络运营商设置的策略和规则。根据使用案例、网络体系结构、ALTO server和ALTO client之间的信任关系等，地图和指南可能会有显著差异。除了安全要求外，安全要求包括不提供任何有关基础设施的机密或关键信息，对于给定用例和/或应用程序可见和需要的网络方面，存在效率要求。
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无意将原始内部网关协议（IGP）或边界网关协议（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.
+--------+ +--------+
| 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扬声器进行对等来获取网络路由信息。对于数据收集，链路状态协议更合适，因为每个路由器都在整个网络中传播其信息。因此，可以从网络中的一个路由器获取关于所有路由器及其邻居的信息。相比之下，距离向量协议不太合适，因为路由信息只在邻居之间共享。为了使用距离向量路由协议获得整个拓扑，需要从网络中的每个路由器检索路由信息。
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
o [RFC7752]描述了一种机制，通过该机制，可以从网络收集链路状态和流量工程（TE）信息，并使用BGP路由协议与外部组件共享。这是通过使用新的BGP网络层可达性实现的
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.
信息（NLRI）编码格式。该机制适用于物理和虚拟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客户端来观察路由相关信息。随着软件定义网络（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）的提供商定义的网络位置标识符，以聚合地图服务中的网络端点。一个PID内的端点可以视为单个实体，假设基于网络拓扑或其他相似性的接近度。PIDs的一个关键用例是指定PIDs之间的网络首选项（成本），而不是单个端点。如何对端点进行分组以及如何分配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
例如，ALTO服务器可以利用网络的服务提供商网络层中可用的BGP信息，并计算前缀组。例如，BGP社区，在MPLS/IP网络中用作聚合和分组前缀的通用机制。BGP社区是一个属性，用于标记前缀，以根据大多数标准对前缀进行分组（例如，大多数ISP网络使用社区来创建BGP前缀，社区标识前缀的出现点（PoP））。这些BGP社区可用于将IP地址范围映射到PID。通过附加策略，ALTO服务器运营商可以决定
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协议本身独立于此类算法和策略。
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成本图在PIDs定义的一组源和目标网络位置之间成对定义方向成本。
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]将“路由成本”成本度量定义为一组基本的评级标准，所有实现都必须支持该标准。此成本度量传达了将流量从源路由到目的地的成本的通用度量。较低的值表示对从源发送到目标的流量的偏好较高。如何计算该指标取决于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.
可以根据实际路由协议信息计算“路由成本”成本度量。通常，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
为了能够使用扩展信息，有一个协议扩展过程来添加新的ALTO成本类型。下表概述了已提出的或ALTO相关原型实现正在使用的进一步评级标准。本清单不作为规范性文本。相反，它的唯一目的是记录和讨论迄今为止提出的评级标准。这些评级标准是否有用，以及
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].
ISP实际提供的相应信息也取决于ALTO的使用情况。存在规范性规范且已成功通过IETF审查流程的评级标准列表可在IANA的“ALTO成本度量注册表”中找到，可从[ALTO-REG]获得。
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客户不会被告知计算的性质。确定相对拓扑距离的一种方法可能是计算跳数，但在查询此参数时，ALTO客户端不得假设这些数字实际上是跳数。除了AS路径之外，还可以考虑其他路由协议参数（例如BGP本地偏好或多出口鉴别器（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子网范围的策略确定，而无需详细说明成本函数。根据[RFC7285]，抽象度量“路由成本”是不必公开成本函数的度量的示例。
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服务器公开的内容不同。特别是，阿尔托客户机不必考虑吞吐量参数作为在不使用拥塞控制机制的情况下以指示速率发送数据的许可。
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服务可能不知道候选端点是否会限制它发送给客户端的数据（例如，由于某些公平算法，例如以牙还牙）。
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 抽象：ALTO服务（如网络和成本地图服务或ECS）仅提供网络的抽象视图。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]更详细地讨论了元件管理系统（EMS）、网络管理系统（NMS）、操作支持系统（OSS）、流量工程数据库（TED）、标签交换路径数据库（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]中地图服务的规范基于网络地图的概念。网络映射将网络划分为PID，PID将一个或多个端点（例如，子网络）分组为单个聚合。各种PID之间的“成本”存储在成本图中。基于地图的方法（如ALTO网络和Cost Map服务）降低了服务器上的信令负载，因为只有地图发生变化时才需要检索地图。
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:
基于地图的方法的一个主要假设是，这些地图中提供的信息在很长一段时间内是静态的。只要网络运营商不改变任何参数（例如，网络内的路由和到上游对等点的路由），并且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子网的子分配往往会降低IP地址分配的效率，特别是对于IPv4。需要保持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前缀中的一个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].
处理地图更改的一个解决方案是使用增量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客户端可以向ALTO服务器请求特定IP地址的指导，从而避免处理地图的需要。这可以缓解上一节中提到的一些问题。
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配置的调整是否有用。这种洞察可以从监控基础设施中获得。提供阿尔托的ISP可以考虑影响（或整合）流量工程和监视服务的部署，以观察阿尔托业务的影响。影响的测量可能具有挑战性，因为启用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 中音地图更新
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].
该数据描述了工作负载、系统性能以及map数据。显然，这些数据将取决于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的好处的一种方法是在启用ALTO服务之前和之后进行测量。除了被动监测，一些数据也可以通过主动测量获得，但由于由此产生的开销，应谨慎使用后者。然而，在所有监控活动中，ALTO服务提供商必须考虑到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可以定义两个“优化区域”：一个是自己的网络，另一个由所有其他网络目的地组成。成本图可以定义如下：内部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是一个只有一个接入网的小型ISP。作为ALTO服务的运营商，ISP A可以将其网络定义为一个优化区域，命名为PID1，并将其他网络定义为另一个优化区域，命名为PID2。C1表示ISP A网络内部的成本。C2表示从PID2到PID1的成本，C3表示从PID1到PID2的成本。在下文中，为了简单起见，假定C2=C3。为了保持ISPA内的本地通信量，定义C1<C2是有意义的。
-----------
//// \\\\
// \\
// \\ /-----------\
| +---------+ | //// \\\\
| | ALTO | ISP A | C2 | Other Networks |
| | Service | PID 1 <----------- PID 2
| +---------+ C1 |----------->| |
| | C3 (=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地址范围2001:db8:100:：/48，相应ALTO网络和成本图的简化摘录如图10和图11所示。在该示例中，成本值C1和C2可以设置为任何数字C1<C2。
HTTP/1.1 200 OK ... Content-Type: application/alto-networkmap+json
HTTP/1.1200OK。。。内容类型：应用程序/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"
]
}
}
}
{
...
"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.1200OK。。。内容类型：应用程序/alto costmap+json
{
...
"cost-type" : {"cost-mode" : "numerical",
"cost-metric": "routingcost"
}
},
"cost-map" : {
"PID1": { "PID1": C1, "PID2": C2 },
"PID2": { "PID1": C2, "PID2": 0 },
}
}
{
...
"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应用程序流量优化用例，该ISP具有由多个接入网络和一个核心网络组成的固定网络。流量优化的目标包括：（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可能希望根据其接入网络的网络拓扑优化其流量。例如，可以将每个接入网络定义为一个优化区域，即，如果可能，流量应保持在该区域的本地。这可以通过将每个区域映射到PID来实现。然后，这些接入网络之间的成本可以根据该ISP相应的流量优化要求来定义。下面进一步描述了一个示例设置，并在图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有一个主干网和三个接入网，分别命名为A、B和C。本例中使用了P2P应用程序。对于合理的应用程序级流量优化，第一个要求可能是减少AS内部骨干网络上的P2P流量，第二个要求可能是减少到其他ISP（即其他ASE）的P2P流量。可以假定第二个需求优先于第一个需求。此外，我们假设ISP B的结算率低于其他ISP。ISPA可以部署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服务器的操作员可以将每个接入网络定义为一个优化区域，并为每个接入网络分配一个PID，例如PID 1、PID 2和PID 3。由于不同外部ISP的不同对等，可以将ISP B定义为一个额外的优化区域，并为其分配PID 4。所有其他网络都可以添加到PID中，成为一个进一步的优化区域（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
在设置中，可以分配成本（C1、C2、C3、C4、C5、C6、C7、C8），如图12所示。成本C1在内部AN A（PID 1）中表示为链路成本，并且C2和C3被相应地定义。C4表示从PID 1到PID 2的链路成本，C5表示从PID 3得到的相应成本，假设其具有类似的值。C6是PID 1和PID 3之间的成本。为简单起见，此场景假设
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.
在这个例子中，企业与企业之间的成本是对称的。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)
根据前面对第一项要求和第二项要求的讨论，这些费用的关系将定义为：（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 | | |
+------------------------------------+ +----------------+
+------------------------------------+ +----------------+
| 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操作一个移动网络，该网络连接到主干网。ISP还运行两个固定接入网络A和B，它们也连接到主干网。在这种网络结构中，可以将移动网络定义为一个优化区域，并为其分配PID 1。接入网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。这意味着移动网络中需要来自其他客户端的数据资源的客户端将比移动网络中的客户端更喜欢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.
从A的角度来看：C2<C6，C5=最大成本。这意味着其他优化区域的客户端将避免从移动网络检索数据。
From view of AN B: Analog to the view of AN A, C3 < C8 and C9 = maximum cost.
从B视图：模拟到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 |----------+ |
| +------------------+ |
+-----------------------------------------------------------------+
+-----------------------------------------------------------------+
| |
| 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.
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|
+-------------------+ +-----+ +-------------------+
+-------------------+ +-----+ +-----+ +-------------------+
|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路由。所使用的IGP是一种链路状态协议，如is-is。应用的链接权重在图中注释，并在图15中另外显示。所有链接都是双向的，其权重是对称的。要从网络获取拓扑和路由信息，拓扑数据源必须直接连接到其中一个路由器（R1…R9）。此外，拓扑数据源必须能够与路由器通信，反之亦然。
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在两个边界路由器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
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：前缀、数字、距离或其他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.
由于网络中可用的数据源多种多样，因此可能有必要汇总信息并定义适当的数据模型，以有效且易于访问地保存信息。一个潜在模型是表示拓扑的带注释的有向图。可以在图形中的相应位置对属性进行注释。下面显示了这样的拓扑图如何描述示例拓扑。
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 端点：已连接端点的列表。根据网络和地址类型，端点本身也可能具有更多属性。这些潜在属性是从路由器到达端点的成本，如数字或距离。
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表示节点，它们之间的连接是链路。例如，R2有一个直接连接的IPv6端点，它属于自己的AS，如图16所示。
ID: 2
身份证号码：2
Neighbor IDs: 1,3 (R1, R3)
邻居ID:1,3（R1，R3）
Endpoints:
端点：
Endpoint: 2001:db8:1:100::/56
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
距离：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.
路由器R8有两个连接的IPv6端点，如图17所示。第一个属于与数字3直接相邻的。从我们的网络到AS3的AS距离为1。第二个端点属于AS（AS4），它不是直接邻居，而是直接连接到AS3。要到达AS4中的端点，必须穿过AS3，这会将AS距离增加1。
ID: 8
身份证号码：8
Neighbor IDs: 5,9 (R5, R9)
邻居ID:5,9（R5，R9）
Endpoints:
端点：
Endpoint: 2001:db8:3::/48
Endpoint: 2001:db8:3::/48
Weight: 100
体重：100
ASNumber: 3
电话号码：3
ASDistance: 1
距离：1
Endpoint: 2001:db8:4::/48
Endpoint: 2001:db8:4::/48
Weight: 200
体重：200
ASNumber: 4
电话号码：4
ASDistance: 2
距离：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 Source ID：链接的源路由器的ID。
o Destination ID: ID of the destination router of the link.
o Destination 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
来源编号：1
Destination ID: 2
目的地编号：2
Weight: 15
体重：15
Bandwidth: 10 Gbit/s
带宽：10 Gbit/s
Utilization: 0.1
利用率：0.1
Latency: 2 ms
延迟：2毫秒
R2->R1:
R2->R1：
Source ID: 2
来源编号：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毫秒
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 map计算过程的目标是从网络的图形表示到更粗粒度和抽象的矩阵表示。第一步是生成网络图。只有在生成网络图之后，才能计算成本图，因为它依赖于网络图。
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
要生成ALTO网络图，需要使用分组功能。分组函数处理来自网络图的信息，将端点分组到PID中。分组的方式是多种多样的，算法可以利用网络图提供的任何信息来执行分组。这些函数可能会忽略中的某些端点
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网络地图中发布的有关网络的详细信息。
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）地址或前缀，[RFC7285]需要使用最长前缀匹配算法将IP映射到PID。该要求导致了每个IP必须映射到一个PID，并且同一前缀或地址不能映射到多个PID的约束。要满足第一个约束，每个计算的映射必须提供一个默认PID，该PID包含IPv4的前缀0.0.0.0/0和IPv6的前缀：：/0。这两个前缀都覆盖了它们的整个地址空间，如果没有其他PID与IP端点匹配，则将使用默认PID。将端点指定给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
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]只允许两个PID之间有一个成本值，因此需要一个分阶段功能来确定结果成本值。这样的分界点可以是一个简单的函数，如最小值、最大值或平均值。
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.
无论成本函数使用何种度量，从源到目标的路径通常由具有最小权重的路径定义。当链接权重由加法度量表示时，路径权重是所有已遍历链接的链接权重之和。例如，可以使用Bellman-Ford或Dijkstra算法来确定路径。后者根据累积链路长度逐步建立最短路径。在我们的示例中，链接长度是链接权重，其值如图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中的端点所需的最小跳数。当cost函数返回多个值时，我们选择的tiebreaker选择最小跳数。
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 |
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-Hop计数成本图示例
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。由于最小跃点计数值tiebreaker，路径R1->R4->R9选择了3个跃点作为值。此外，由于“默认”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协议有多个可互操作的实现。[MAP-CALC]中记录了在大规模网络中实施和使用ALTO的一些经验，总结如下：
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
o 数据处理：处理网络信息可能非常复杂，而且需要大量资源。从连接到Internet的自治系统收集信息可能意味着服务器每分钟必须存储和处理数十万个前缀、数百兆字节的IPFIX/Netflow信息，以及来自数百个路由器的信息和数千条链路的属性。需要大量的磁盘内存、RAM和CPU周期以及高效的算法来处理数据
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.
信息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的大型网络由数十万个前缀组成，在网络地图计算过程中，这些前缀必须映射到PIDs。因此，网络映射变得非常大（高达数十兆字节）。但是，根据网络设计和选择的分组功能，计算出的网络映射包含可以删除的冗余。至少有两种方法可以通过消除冗余来减小大小。首先，可以合并相邻的IP前缀。当PID有两个相邻的前缀项时，它可以将它们合并为一个较大的前缀。两个前缀必须位于同一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 成本图计算：成本图计算的一个已知实现挑战是计算大型网络中的成本可能需要大量的CPU周期。如果在每个源-目标PID对的端点之间计算成本，这尤其有问题。通常，PID的多个端点连接到同一节点，因此会多次计算相同的路径成本。这显然是低效的。补救方法可能是更复杂的算法，例如在我们的网络图中查找每个PID的端点连接到的路由器，并根据路由器之间的成本计算成本图。在部署和配置阿尔托服务器时，管理员应考虑巨大成本图的影响，并可能确保地图大小不会太大。
In addition, further deployment experiences have been documented. One real example is described in greater detail in reference [CHINA-TRIAL].
此外，还记录了进一步的部署经验。参考文献[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使用提示服务器实现和虚拟节点执行测试，以了解类似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
,-------. +-----------+
,---. ,-' ========>| 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外部的跟踪器可能是一个典型的用例。例如，像海盗湾这样的追踪者可以为全球的BitTorrent同行提供服务。该图仅显示了一个跟踪器实例，但也可以使用多个跟踪器进行部署。
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
图21所示的场景允许对等方直接与其ISP的ALTO服务器（即嵌入在对等方中的ALTO客户端）通信，从而使对等方能够最大程度地控制其查询的信息，因为他们可以整合从一个或多个跟踪器接收到的信息，并通过直接的点对点知识交换。例如，后一种方法
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]).
在BitTorrent中称为对等交换（PEX）。在此部署场景中，对等方必须发现合适的ALTO服务器（例如，由其ISP提供，如[RFC7286]中所述）。
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的使用，它们的部署类似于图21，因为ALTO客户端也将嵌入到对等机中。本备忘录未进一步考虑此选项。
,-------.
,---. ,-' `-. +-----------+
,-' `-. / 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
,-------.
,---. ,-' `-. +-----------+
,-' `-. / 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:Global Tracker在各种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
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.
有一些尝试让ISP部署自己的跟踪器，如图23所示。在这种情况下，客户端只能通过与ISP的跟踪器通信，而ISP的跟踪器又使用ALTO协议与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服务器的指导信息并接收相应的回复。在对等网络的情况下，可以使用两种不同的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的其他用例，特别是在更受控的环境中，cost map服务和ECS都可能是可行的；使用基于地图还是基于查询的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客户端：
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 |
|<----------------------------------------------|
| | |
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
==== 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).
在第二个场景中（参见图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 | |
|<======================| |
| | |
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
==== 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
注：图24和图25所示的消息序列可能出现在目标感知和目标独立查询模式（参见[RFC6708]）中。在独立于目标的查询模式下，跟踪后可能不需要与ALTO服务器交换消息
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.
查询，因为候选资源提供程序可以使用本地缓存的“映射”进行评估，该映射不久前已从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.
第一种方法存在以下问题：虽然资源目录可能知道数千个参与群集的对等方，但出于效率原因，返回给资源使用者的列表通常会缩短。因此，“最好的”（在阿尔托意义上）潜在的资源提供者可能不再被包含在该列表中，甚至在阿尔托可以考虑它们之前。
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评估所有已知的对等点，则可以实现更好的流量优化。这个名单将包括一个明显更高比例的“好”同龄人。如果跟踪器只返回“良好”的对等点，则可能存在群集断开连接并分裂为多个不相交分区的风险。然而，找到中音偏向和随机对等选择的正确组合超出了本文档的范围。
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客户端嵌入到资源目录中）是有利的，因为它确保了“最佳”资源提供者的地址实际交付给资源使用者。这一见解的架构含义是，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
本节简要介绍了ALTO对CDN的使用，如[CDN-USE]中所述。CDN用于从更靠近用户位置的位置交付某些互联网服务（例如，网站交付、软件更新和视频交付）。CDN通常由通常连接到的服务器网络组成
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.
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中的请求路由功能负责接收来自用户代理的内容请求，获取和维护关于一组候选代理的必要信息，并选择用户代理并将其重定向到适当的代理。一种常见的方法是依赖DNS系统，但还有许多其他方法，请参见[RFC3568]。
+--------------------+
| CDN Request Router |
| with ALTO Client |
+--------------------+
/\
|| ALTO protocol
||
\/
+---------+
| ALTO |
| Server |
+---------+
:
: Provisioning protocol
:
,-----------.
,-' Source of `-.
( topological )
`-. information ,-'
`-----------'
+--------------------+
| 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：使用ALTO信息进行CDN请求路由
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 |
|<--------------------------------------------------------+
| | |
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请求。在第二步骤（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
CDN上下文中ALTO最简单的用例是改进CDN代理或源的选择。在这种情况下，CDN使用ALTO服务器来选择比其他情况更好的CDN代理或源。尽管可以通过其他方式获得原始网络图和成本信息，例如，被动地侦听ISP的路由协议或使用主动探测，但是使用ALTO服务来公开该信息可以向ISP提供关于如何公开其网络图/成本的额外控制。此外，它还可以使ISP保持
functional separation between their routing plane and network map computation functions. This may be attractive for a number of reasons, for example:
它们的路由平面和网络地图计算功能之间的功能分离。这可能是有吸引力的，原因有很多，例如：
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网络内的少量中心位置时，ISP拓扑的简化视图或接近度的近似值通常足以使CDN从最佳服务器/位置为最终用户提供服务。随着CDN服务器在ISP网络中的部署越来越深入，CDN有必要更详细地了解底层网络拓扑和网络位置之间的成本，以便使CDN能够从ISP的最佳服务器为最终用户提供服务。
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原始请求者的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].
除了由单个CDN使用外，ALTO还可用于互连多个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服务器将为ISP提供向CDN提供服务的能力，该CDN提供网络地图和成本信息。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请求路由器会发出一个ECS请求，其中包含最终用户（内容请求者）的端点地址（IPv4/IPv6）和代理（内容目标）的端点地址集。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 Network and Cost Map Service和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查询的结果，以供以后使用，从而解决ECS的可扩展性限制，减少CDN和ALTO服务器之间的事务数量。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.
在一种部署场景中，ALTO可以向CDN公开ISP最终用户的可达性。请求路由器需要有关于哪些最终用户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].
[CDN-USE]和[ALTO-CDN]中还列出了部署ALTO的其他更高级方案。
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的具体部署。例如，其代理仅部署在Internet主干网内的“over-the-top”CDN可能只需要知道哪些最终用户IP子网可通过哪个ISP网络访问，而部署在特定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中的距离表示抽象的“路由成本”，例如，可以根据路由协议信息计算。但ALTO服务器也可以考虑其他标准或其他政策、状态和性能信息的信息源（如地理位置），如第3.2.2节所述。
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
ALTO服务器计算拓扑信息和排名所使用的不同方法和算法不在本文档范围内。如果排名是基于路由协议信息，很明显，网络事件可能会影响排名
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.
计算由于当前网络内部的内部冗余和恢复机制，基础设施中发生的大多数网络事件将在网络内部处理，它们对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客户端的状态，以便在发生重大网络事件时（例如，通过通知机制）通知并向这些客户端发送信号。在CDN/ALTO互通体系结构中，与任何互联网用户的ALTO指南相比，很少有CDN组件与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拓扑公开和指导中获益。在一般的互联网上，一个优点是应用程序不必自己执行过多的测量。例如，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
o 私有云计算解决方案：企业客户可以在多个站点运行自己的数据中心。云管理
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.
系统可能希望了解不同站点之间的网络成本，以便在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 云爆发：一个或多个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用例类似，NSP提供的ALTO服务器将启用优于随机应用程序级别的决策，如图28所示。
+---------------+
| 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 |
+-------+ +-------+
+---------------+
| 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不一定是静态的。客户可以通过门户网站、网络管理系统或其他OSS解决方案修改VPN并添加新的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|
+-----+ +-----+ +-----+ +-----+ +-----+
+--------------+ +------+
| 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描述了ISP2中具有各种访问网络类型的潜在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。[RFC7491]中解释了一些如何利用ALTO进行联合网络和应用层优化的用例。
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]中详细考虑了这些问题。两个主要的安全问题涉及通过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用例。特别注意两个主要的安全问题。
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
如第4.1.1节所述，对于ALTO信息的发布者（即ALTO服务器运营商），谁负责P2P应用程序覆盖可能并不明显。一些P2P应用程序没有任何中央控制实体，整个覆盖层仅由节点组成，这些节点由单个用户控制。其他P2P应用程序可能有一些控制实体，如超级对等点或跟踪器，但这些控制实体可能位于
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.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网络基础设施和一个或多个“非受管理”应用程序覆盖之间架起了桥梁，即很难判断谁负责覆盖。这不同于更受控的环境（例如，在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地址发布该属性。该信息不仅可用于流量优化，还可用于针对具有异常良好（或不良）连接的住宅用户的定向广告，如特殊横幅广告。对于广告系统，以其他方式（例如，通过带宽探测）获取此类信息将更为复杂。
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].
RFC 6708第5.2.1节，案例（1）-（3）[RFC6708]中详细列出了与意外披露ALTO服务器信息相关的不同场景，并对其进行了分类。
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
在某些用例中，不可能使用访问控制（参见第7.3节）将ALTO知识的分发限制在一小部分受信任的客户机上。在这些场景中，似乎根本不使用网络图和成本图，而是完全依赖网络图
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]).
ALTO服务器中的ECS和端点排名。虽然这种做法可能确实会减少向单个ALTO客户披露的信息量，但应考虑一些问题：首先，在使用基于地图的方法时，分析可向客户披露的最大信息量（完整地图）并不重要。相反，当仅提供端点成本服务时，ALTO服务器运营商可能会产生错误的安全感，而客户使用重复查询和/或协作来收集比预期更多的信息（参见[RFC6708]第5.2.1节案例（3））。其次，ECS向ALTO服务器透露更多关于用户或应用程序行为的信息，例如，哪些其他主机被视为交换大量数据的对等主机（参见[RFC6708]第5.2.1节，案例（4）-（6））。
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.
因此，如果ALTO服务基于ECS而不是提供网络和成本地图，用户可能更不愿意使用它。鉴于一些流行的P2P应用程序有时用于诸如未经版权所有者明确许可的文件分发等目的，ALTO服务器无法推断待优化应用程序的行为也可能符合ALTO服务器运营商的利益。一个可能的结论是通过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要求支持HTTP摘要身份验证，以实现客户端身份验证，并可能限制与ALTO信息直接共享的参与方数量。也可以支持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网络中的各方（见图22）必须访问ALTO服务器，例如，通过第三方跟踪器或ISP网络外的CDN系统，则访问限制必须更加宽松。在极端情况下，即没有访问限制，Internet中的每台主机都可以访问ALTO服务器。这可能不是ISP的意图，因为服务器不仅会受到更多可能的攻击，而且服务器负载可能会增加，因为可能需要服务更多的ALTO客户端。
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服务的提供者以及潜在用户可能是众所周知的。只有CDN实体可能需要ALTO访问；住宅用户对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.
访问控制还有助于防止来自Internet的任意主机的拒绝服务（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
排序：攻击者可以更改ALTO指南的排序顺序（考虑到顺序很重要；否则，排名机制很重要），即将位于ISP之外的对等点声明为首选对等点。这不会构成威胁
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的通信/处理开销外，它将模拟“常规”对等方操作而不进行流量本地化。然而，这可能意味着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内，也可以位于Internet的其他部分（例如，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，“应用层流量优化（ALTO）协议”<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，“应用层流量优化（ALTO）问题陈述”，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]Kiesel，S.，Ed.，Previdi，S.，Stiemerling，M.，Woundy，R.，和Y.Yang，“应用层流量优化（ALTO）要求”，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]Alimi，R.，Ed.，Penno，R.，Ed.，Yang，Y.，Ed.，Kiesel，S.，Previdi，S.，Room，W.，Shalunov，S.，和R.Woundy，“应用层流量优化（ALTO）协议”，RFC 7285，DOI 10.17487/RFC7285，2014年9月<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]Kiesel，S.，Stiemering，M.，Schwan，N.，Scharf，M.，和H.Song，“应用层流量优化（ALTO）服务器发现”，RFC 7286，DOI 10.17487/RFC7286，2014年11月<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.，和S.Previdi，“ALTO和内容交付网络”，正在进行的工作，草稿-Penno-ALTO-CDN-032011年3月。
[ALTO-H12] Kiesel, S. and M. Stiemerling, "ALTO H12", Work in Progress, draft-kiesel-alto-h12-02, March 2010.
[ALTO-H12]Kiesel，S.和M.Stiemerling，“ALTO H12”，正在进行的工作，草稿-Kiesel-ALTO-H12-022010年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考虑因素”，正在进行的工作，草稿-deng-ALTO-P2PCACHE-032014年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的用例”，正在进行的工作，草稿-Jenkins-ALTO-CDN-USE-Cases-032012年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，“使用ALTO的CDNI足迹和能力广告”，正在进行的工作，草稿-Seedorf-CDNI-request-routing-ALTO-082015年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，“中国电信内部的ALTO和十年服务试验”，正在进行的工作，草稿-lee-ALTO-chinatelecom-TRIAL-042012年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地图”，正在进行的工作，草稿-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，“网络拓扑的数据模型”，正在进行的工作，草稿-ietf-i2rs-yang-NETWORK-TOPO-062016年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.，Presohn，R.，和B.Wijnen，“描述简单网络管理协议（SNMP）管理框架的体系结构”，STD 62，RFC 3411，DOI 10.17487/RFC34112002年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，“提供商提供的虚拟专用网络（VPN）术语”，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，“基于路径计算元素（PCE）的体系结构”，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，“IETF对等（P2P）基础设施研讨会报告，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，“康卡斯特在主动网络提供商参与P2P（P4P）技术试验中的ISP经验”，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.，Ed.“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.，Ed.，Bjorklund，M.，Ed.，Schoenwaeld，J.，Ed.，和A.Bierman，Ed.，“网络配置协议（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]Kamei，S.，Momose，T.，Inoue，T.，和T.Nishitani，“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]King，D.和A.Farrel，“基于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.，和S.Ray，“使用BGP的链路状态和流量工程（TE）信息的北向分布”，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，“路由系统接口架构”，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，“路由系统接口（I2RS）可追溯性：框架和信息模型”，RFC 7922，DOI 10.17487/RFC7922，2016年6月<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，“使用服务器发送事件（SSE）的ALTO增量更新”，正在进行的工作，草稿-ietf-ALTO-incr-UPDATE-SSE-032016年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-022014年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]Kiesel，S.和M.Stiemerling，“应用层流量优化（ALTO）跨域服务器发现”，正在进行的工作，草稿-Kiesel-ALTO-XDOM-DISC-022016年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 孙向旭、李凯和理查德·杨提供了关于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 邓凌丽、陈伟、易秋超和张燕参与了第6.2节。
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
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
塞巴斯蒂安KIESEL斯图加特大学信息中心网络与通信系统系ALMANDRIN 30斯图加特70550德国
Email: ietf-alto@skiesel.de
Email: ietf-alto@skiesel.de
Michael Scharf Nokia Lorenzstrasse 10 Stuttgart 70435 Germany
Michael Scharf诺基亚Lorenzstrasse 10斯图加特70435德国
Email: michael.scharf@nokia.com
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
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罗马00191意大利
Email: sprevidi@cisco.com
Email: sprevidi@cisco.com