Internet Engineering Task Force (IETF) R. Alimi, Ed.
Request for Comments: 7285 Google
Category: Standards Track R. Penno, Ed.
ISSN: 2070-1721 Cisco Systems, Inc.
Y. Yang, Ed.
Yale University
S. Kiesel
University of Stuttgart
S. Previdi
Cisco Systems, Inc.
W. Roome
Alcatel-Lucent
S. Shalunov
Open Garden
R. Woundy
Comcast
September 2014
Internet Engineering Task Force (IETF) R. Alimi, Ed.
Request for Comments: 7285 Google
Category: Standards Track R. Penno, Ed.
ISSN: 2070-1721 Cisco Systems, Inc.
Y. Yang, Ed.
Yale University
S. Kiesel
University of Stuttgart
S. Previdi
Cisco Systems, Inc.
W. Roome
Alcatel-Lucent
S. Shalunov
Open Garden
R. Woundy
Comcast
September 2014
Application-Layer Traffic Optimization (ALTO) Protocol
应用层流量优化（ALTO）协议
Abstract
摘要
Applications using the Internet already have access to some topology information of Internet Service Provider (ISP) networks. For example, views to Internet routing tables at Looking Glass servers are available and can be practically downloaded to many network application clients. What is missing is knowledge of the underlying network topologies from the point of view of ISPs. In other words, what an ISP prefers in terms of traffic optimization -- and a way to distribute it.
使用Internet的应用程序已经可以访问Internet服务提供商（ISP）网络的一些拓扑信息。例如，可以在Looking Glass服务器上查看Internet路由表，实际上可以下载到许多网络应用程序客户端。缺少的是从ISP的角度了解底层网络拓扑。换言之，ISP在流量优化方面的偏好——以及分配流量的方式。
The Application-Layer Traffic Optimization (ALTO) services defined in this document provide network information (e.g., basic network location structure and preferences of network paths) with the goal of modifying network resource consumption patterns while maintaining or improving application performance. The basic information of ALTO is based on abstract maps of a network. These maps provide a simplified view, yet enough information about a network for applications to effectively utilize them. Additional services are built on top of the maps.
本文档中定义的应用层流量优化（ALTO）服务提供网络信息（例如，基本网络位置结构和网络路径的首选项），目的是在维护或改进应用程序性能的同时修改网络资源消耗模式。ALTO的基本信息基于网络的抽象地图。这些地图提供了一个简化的视图，同时也提供了足够的网络信息供应用程序有效利用。其他服务建立在地图之上。
This document describes a protocol implementing the ALTO services. Although the ALTO services would primarily be provided by ISPs, other entities, such as content service providers, could also provide ALTO services. Applications that could use the ALTO services are those that have a choice to which end points to connect. Examples of such applications are peer-to-peer (P2P) and content delivery networks.
本文档描述了实现ALTO服务的协议。虽然ALTO服务主要由ISP提供，但内容服务提供商等其他实体也可以提供ALTO服务。可以使用ALTO服务的应用程序可以选择连接到哪个端点。此类应用程序的示例是对等（P2P）和内容交付网络。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7285.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7285.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 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 ....................................................6
1.1. Problem Statement ..........................................6
1.1.1. Requirements Language ...............................7
1.2. Design Overview ............................................7
2. Terminology .....................................................7
2.1. Endpoint ...................................................8
2.2. Endpoint Address ...........................................8
2.3. Network Location ...........................................8
2.4. ALTO Information ...........................................8
2.5. ALTO Information Base ......................................8
3. Architecture ....................................................8
3.1. ALTO Services and Protocol Scope ...........................9
3.2. ALTO Information Reuse and Redistribution .................11
4. ALTO Information Service Framework .............................11
4.1. ALTO Information Services .................................12
4.1.1. Map Service ........................................12
4.1.2. Map-Filtering Service ..............................12
1. Introduction ....................................................6
1.1. Problem Statement ..........................................6
1.1.1. Requirements Language ...............................7
1.2. Design Overview ............................................7
2. Terminology .....................................................7
2.1. Endpoint ...................................................8
2.2. Endpoint Address ...........................................8
2.3. Network Location ...........................................8
2.4. ALTO Information ...........................................8
2.5. ALTO Information Base ......................................8
3. Architecture ....................................................8
3.1. ALTO Services and Protocol Scope ...........................9
3.2. ALTO Information Reuse and Redistribution .................11
4. ALTO Information Service Framework .............................11
4.1. ALTO Information Services .................................12
4.1.1. Map Service ........................................12
4.1.2. Map-Filtering Service ..............................12
4.1.3. Endpoint Property Service ..........................12
4.1.4. Endpoint Cost Service ..............................13
5. Network Map ....................................................13
5.1. Provider-Defined Identifier (PID) .........................13
5.2. Endpoint Addresses ........................................14
5.3. Example Network Map .......................................14
6. Cost Map .......................................................15
6.1. Cost Types ................................................16
6.1.1. Cost Metric ........................................16
6.1.2. Cost Mode ..........................................17
6.2. Cost Map Structure ........................................18
6.3. Network Map and Cost Map Dependency .......................18
6.4. Cost Map Update ...........................................19
7. Endpoint Properties ............................................19
7.1. Endpoint Property Type ....................................19
7.1.1. Endpoint Property Type: pid ........................19
8. Protocol Specification: General Processing .....................19
8.1. Overall Design ............................................19
8.2. Notation ..................................................20
8.3. Basic Operations ..........................................21
8.3.1. Client Discovering Information Resources ...........21
8.3.2. Client Requesting Information Resources ............22
8.3.3. Server Responding to Information Resource Request ..22
8.3.4. Client Handling Server Response ....................23
8.3.5. Authentication and Encryption ......................23
8.3.6. Information Refreshing .............................24
8.3.7. Parsing of Unknown Fields ..........................24
8.4. Server Response Encoding ..................................24
8.4.1. Meta Information ...................................24
8.4.2. Data Information ...................................25
8.5. Protocol Errors ...........................................25
8.5.1. Media Type .........................................25
8.5.2. Response Format and Error Codes ....................25
8.5.3. Overload Conditions and Server Unavailability ......28
9. Protocol Specification: Information Resource Directory .........28
9.1. Information Resource Attributes ...........................29
9.1.1. Resource ID ........................................29
9.1.2. Media Type .........................................29
9.1.3. Capabilities .......................................29
9.1.4. Accepts Input Parameters ...........................29
9.1.5. Dependent Resources ................................30
9.2. Information Resource Directory (IRD) ......................30
9.2.1. Media Type .........................................30
9.2.2. Encoding ...........................................30
9.2.3. Example ............................................32
9.2.4. Delegation Using IRD ...............................35
9.2.5. Considerations of Using IRD ........................37
10. Protocol Specification: Basic Data Types ......................38
4.1.3. Endpoint Property Service ..........................12
4.1.4. Endpoint Cost Service ..............................13
5. Network Map ....................................................13
5.1. Provider-Defined Identifier (PID) .........................13
5.2. Endpoint Addresses ........................................14
5.3. Example Network Map .......................................14
6. Cost Map .......................................................15
6.1. Cost Types ................................................16
6.1.1. Cost Metric ........................................16
6.1.2. Cost Mode ..........................................17
6.2. Cost Map Structure ........................................18
6.3. Network Map and Cost Map Dependency .......................18
6.4. Cost Map Update ...........................................19
7. Endpoint Properties ............................................19
7.1. Endpoint Property Type ....................................19
7.1.1. Endpoint Property Type: pid ........................19
8. Protocol Specification: General Processing .....................19
8.1. Overall Design ............................................19
8.2. Notation ..................................................20
8.3. Basic Operations ..........................................21
8.3.1. Client Discovering Information Resources ...........21
8.3.2. Client Requesting Information Resources ............22
8.3.3. Server Responding to Information Resource Request ..22
8.3.4. Client Handling Server Response ....................23
8.3.5. Authentication and Encryption ......................23
8.3.6. Information Refreshing .............................24
8.3.7. Parsing of Unknown Fields ..........................24
8.4. Server Response Encoding ..................................24
8.4.1. Meta Information ...................................24
8.4.2. Data Information ...................................25
8.5. Protocol Errors ...........................................25
8.5.1. Media Type .........................................25
8.5.2. Response Format and Error Codes ....................25
8.5.3. Overload Conditions and Server Unavailability ......28
9. Protocol Specification: Information Resource Directory .........28
9.1. Information Resource Attributes ...........................29
9.1.1. Resource ID ........................................29
9.1.2. Media Type .........................................29
9.1.3. Capabilities .......................................29
9.1.4. Accepts Input Parameters ...........................29
9.1.5. Dependent Resources ................................30
9.2. Information Resource Directory (IRD) ......................30
9.2.1. Media Type .........................................30
9.2.2. Encoding ...........................................30
9.2.3. Example ............................................32
9.2.4. Delegation Using IRD ...............................35
9.2.5. Considerations of Using IRD ........................37
10. Protocol Specification: Basic Data Types ......................38
10.1. PID Name .................................................38
10.2. Resource ID ..............................................38
10.3. Version Tag ..............................................38
10.4. Endpoints ................................................39
10.4.1. Typed Endpoint Addresses ..........................39
10.4.2. Address Type ......................................39
10.4.3. Endpoint Address ..................................40
10.4.4. Endpoint Prefixes .................................40
10.4.5. Endpoint Address Group ............................41
10.5. Cost Mode ................................................41
10.6. Cost Metric ..............................................42
10.7. Cost Type ................................................42
10.8. Endpoint Property ........................................42
10.8.1. Resource-Specific Endpoint Properties .............43
10.8.2. Global Endpoint Properties ........................43
11. Protocol Specification: Service Information Resources .........43
11.1. Meta Information .........................................43
11.2. Map Service ..............................................43
11.2.1. Network Map .......................................44
11.2.2. Mapping IP Addresses to PIDs for
'ipv4'/'ipv6' Network Maps ........................46
11.2.3. Cost Map ..........................................47
11.3. Map-Filtering Service ....................................50
11.3.1. Filtered Network Map ..............................50
11.3.2. Filtered Cost Map .................................53
11.4. Endpoint Property Service ................................57
11.4.1. Endpoint Property .................................58
11.5. Endpoint Cost Service ....................................61
11.5.1. Endpoint Cost .....................................61
12. Use Cases .....................................................64
12.1. ALTO Client Embedded in P2P Tracker ......................65
12.2. ALTO Client Embedded in P2P Client: Numerical Costs ......66
12.3. ALTO Client Embedded in P2P Client: Ranking ..............67
13. Discussions ...................................................68
13.1. Discovery ................................................68
13.2. Hosts with Multiple Endpoint Addresses ...................68
13.3. Network Address Translation Considerations ...............69
13.4. Endpoint and Path Properties .............................69
14. IANA Considerations ...........................................70
14.1. application/alto-* Media Types ...........................70
14.2. ALTO Cost Metric Registry ................................71
14.3. ALTO Endpoint Property Type Registry .....................73
14.4. ALTO Address Type Registry ...............................75
14.5. ALTO Error Code Registry .................................76
15. Security Considerations .......................................76
15.1. Authenticity and Integrity of ALTO Information ...........77
15.1.1. Risk Scenarios ....................................77
15.1.2. Protection Strategies .............................77
10.1. PID Name .................................................38
10.2. Resource ID ..............................................38
10.3. Version Tag ..............................................38
10.4. Endpoints ................................................39
10.4.1. Typed Endpoint Addresses ..........................39
10.4.2. Address Type ......................................39
10.4.3. Endpoint Address ..................................40
10.4.4. Endpoint Prefixes .................................40
10.4.5. Endpoint Address Group ............................41
10.5. Cost Mode ................................................41
10.6. Cost Metric ..............................................42
10.7. Cost Type ................................................42
10.8. Endpoint Property ........................................42
10.8.1. Resource-Specific Endpoint Properties .............43
10.8.2. Global Endpoint Properties ........................43
11. Protocol Specification: Service Information Resources .........43
11.1. Meta Information .........................................43
11.2. Map Service ..............................................43
11.2.1. Network Map .......................................44
11.2.2. Mapping IP Addresses to PIDs for
'ipv4'/'ipv6' Network Maps ........................46
11.2.3. Cost Map ..........................................47
11.3. Map-Filtering Service ....................................50
11.3.1. Filtered Network Map ..............................50
11.3.2. Filtered Cost Map .................................53
11.4. Endpoint Property Service ................................57
11.4.1. Endpoint Property .................................58
11.5. Endpoint Cost Service ....................................61
11.5.1. Endpoint Cost .....................................61
12. Use Cases .....................................................64
12.1. ALTO Client Embedded in P2P Tracker ......................65
12.2. ALTO Client Embedded in P2P Client: Numerical Costs ......66
12.3. ALTO Client Embedded in P2P Client: Ranking ..............67
13. Discussions ...................................................68
13.1. Discovery ................................................68
13.2. Hosts with Multiple Endpoint Addresses ...................68
13.3. Network Address Translation Considerations ...............69
13.4. Endpoint and Path Properties .............................69
14. IANA Considerations ...........................................70
14.1. application/alto-* Media Types ...........................70
14.2. ALTO Cost Metric Registry ................................71
14.3. ALTO Endpoint Property Type Registry .....................73
14.4. ALTO Address Type Registry ...............................75
14.5. ALTO Error Code Registry .................................76
15. Security Considerations .......................................76
15.1. Authenticity and Integrity of ALTO Information ...........77
15.1.1. Risk Scenarios ....................................77
15.1.2. Protection Strategies .............................77
15.1.3. Limitations .......................................77
15.2. Potential Undesirable Guidance from Authenticated ALTO
Information ..............................................78
15.2.1. Risk Scenarios ....................................78
15.2.2. Protection Strategies .............................78
15.3. Confidentiality of ALTO Information ......................79
15.3.1. Risk Scenarios ....................................79
15.3.2. Protection Strategies .............................79
15.3.3. Limitations .......................................80
15.4. Privacy for ALTO Users ...................................80
15.4.1. Risk Scenarios ....................................80
15.4.2. Protection Strategies .............................80
15.5. Availability of ALTO Services ............................81
15.5.1. Risk Scenarios ....................................81
15.5.2. Protection Strategies .............................81
16. Manageability Considerations ..................................81
16.1. Operations ...............................................82
16.1.1. Installation and Initial Setup ....................82
16.1.2. Migration Path ....................................82
16.1.3. Dependencies on Other Protocols and
Functional Components .............................83
16.1.4. Impact and Observation on Network Operation .......83
16.2. Management ...............................................84
16.2.1. Management Interoperability .......................84
16.2.2. Management Information ............................84
16.2.3. Fault Management ..................................84
16.2.4. Configuration Management ..........................84
16.2.5. Performance Management ............................85
16.2.6. Security Management ...............................85
17. References ....................................................85
17.1. Normative References .....................................85
17.2. Informative References ...................................86
Appendix A. Acknowledgments .......................................89
Appendix B. Design History and Merged Proposals ...................90
15.1.3. Limitations .......................................77
15.2. Potential Undesirable Guidance from Authenticated ALTO
Information ..............................................78
15.2.1. Risk Scenarios ....................................78
15.2.2. Protection Strategies .............................78
15.3. Confidentiality of ALTO Information ......................79
15.3.1. Risk Scenarios ....................................79
15.3.2. Protection Strategies .............................79
15.3.3. Limitations .......................................80
15.4. Privacy for ALTO Users ...................................80
15.4.1. Risk Scenarios ....................................80
15.4.2. Protection Strategies .............................80
15.5. Availability of ALTO Services ............................81
15.5.1. Risk Scenarios ....................................81
15.5.2. Protection Strategies .............................81
16. Manageability Considerations ..................................81
16.1. Operations ...............................................82
16.1.1. Installation and Initial Setup ....................82
16.1.2. Migration Path ....................................82
16.1.3. Dependencies on Other Protocols and
Functional Components .............................83
16.1.4. Impact and Observation on Network Operation .......83
16.2. Management ...............................................84
16.2.1. Management Interoperability .......................84
16.2.2. Management Information ............................84
16.2.3. Fault Management ..................................84
16.2.4. Configuration Management ..........................84
16.2.5. Performance Management ............................85
16.2.6. Security Management ...............................85
17. References ....................................................85
17.1. Normative References .....................................85
17.2. Informative References ...................................86
Appendix A. Acknowledgments .......................................89
Appendix B. Design History and Merged Proposals ...................90
This document defines the ALTO Protocol, which provides a solution for the problem stated in [RFC5693]. Specifically, in today's networks, network information such as network topologies, link availability, routing policies, and path costs are hidden from the application layer, and many applications benefited from such hiding of network complexity. However, new applications, such as application-layer overlays, can benefit from information about the underlying network infrastructure. In particular, these new network applications can be adaptive; hence, they can become more network efficient (e.g., reduce network resource consumption) and achieve better application performance (e.g., accelerated download rate), by leveraging network-provided information.
本文件定义了ALTO协议，该协议为[RFC5693]中所述的问题提供了解决方案。具体地说，在当今的网络中，诸如网络拓扑、链路可用性、路由策略和路径成本等网络信息从应用层隐藏，并且许多应用程序受益于这种网络复杂性的隐藏。但是，新的应用程序（如应用程序层覆盖）可以受益于有关底层网络基础设施的信息。特别是，这些新的网络应用可以是自适应的；因此，通过利用网络提供的信息，他们可以提高网络效率（例如，减少网络资源消耗）并实现更好的应用程序性能（例如，加快下载速度）。
At a high level, the ALTO Protocol specified in this document is an information-publishing interface that allows a network to publish its network information such as network locations, costs between them at configurable granularities, and endhost properties to network applications. The information published by the ALTO Protocol should benefit both the network and the applications (i.e., the consumers of the information). Either the operator of the network or a third party (e.g., an information aggregator) can retrieve or derive related information of the network and publish it using the ALTO Protocol.
在较高的层次上，本文档中指定的ALTO协议是一个信息发布接口，允许网络向网络应用程序发布其网络信息，如网络位置、网络位置之间的成本以及终端主机属性。ALTO协议发布的信息应该对网络和应用程序（即信息的消费者）都有利。网络运营商或第三方（例如，信息聚合器）可以检索或导出网络的相关信息，并使用ALTO协议发布。
To allow better understanding of the goal of the ALTO Protocol, this document provides a short, non-normative overview of the benefits of ALTO to both networks and applications:
为了更好地理解ALTO协议的目标，本文件对ALTO对网络和应用的好处进行了简短的非规范性概述：
o A network that provides ALTO information can achieve better utilization of its networking infrastructure. For example, by using ALTO as a tool to interact with applications, a network is able to provide network information to applications so that the applications can better manage traffic on more expensive or difficult-to-provision links such as long-distance, transit, or backup links. During the interaction, the network can choose to protect its sensitive and confidential network state information, by abstracting real metric values into non-real numerical scores or ordinal ranking.
o 提供ALTO信息的网络可以更好地利用其网络基础设施。例如，通过使用ALTO作为与应用程序交互的工具，网络能够向应用程序提供网络信息，以便应用程序能够更好地管理更昂贵或难以提供的链路上的通信量，例如长途、中转或备份链路。在交互过程中，网络可以选择保护其敏感和机密的网络状态信息，方法是将真实的度量值抽象为非真实的数字分数或顺序排序。
o An application that uses ALTO information can benefit from better knowledge of the network to avoid network bottlenecks. For example, an overlay application can use information provided by the ALTO services to avoid selecting peers connected via high-delay links (e.g., some intercontinental links). Using ALTO to
o 使用ALTO信息的应用程序可以通过更好地了解网络来避免网络瓶颈。例如，覆盖应用程序可以使用ALTO服务提供的信息来避免选择通过高延迟链路（例如，一些洲际链路）连接的对等方。使用ALTO来
initialize each node with promising ("better-than-random") peers, an adaptive peer-to-peer overlay may achieve faster, better convergence.
使用有希望的（“优于随机的”）对等点初始化每个节点，自适应对等覆盖可以实现更快、更好的收敛。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
The ALTO Protocol specified in this document meets the ALTO requirements specified in [RFC5693], and unifies multiple protocols previously designed with similar intentions. See Appendix A for a list of people and Appendix B for a list of proposals that have made significant contributions to this effort.
本文件中规定的ALTO协议符合[RFC5693]中规定的ALTO要求，并统一了先前设计意图类似的多个协议。参见附录A中的人员名单，以及附录B中对这项工作做出重大贡献的提案名单。
The ALTO Protocol uses a REST-ful (Representational State Transfer (REST)) design [Fielding-Thesis], and encodes its requests and responses using JSON [RFC7159]. These designs are chosen because of their flexibility and extensibility. In addition, these designs make it possible for ALTO to be deployed at scale by leveraging existing HTTP [RFC7230] implementations, infrastructures and deployment experience.
ALTO协议使用REST-ful（Representational State Transfer（REST））设计[Fielding Thesis]，并使用JSON[RFC7159]对其请求和响应进行编码。选择这些设计是因为它们具有灵活性和可扩展性。此外，这些设计通过利用现有的HTTP[RFC7230]实现、基础设施和部署经验，使ALTO能够大规模部署。
The ALTO Protocol uses a modular design by dividing ALTO information publication into multiple ALTO services (e.g., the Map service, the Map-Filtering Service, the Endpoint Property Service, and the Endpoint Cost Service). Each ALTO service provides a given set of functionalities and is realized by a set of information resources, which are announced by information resource directories, to guide ALTO clients.
ALTO协议采用模块化设计，将ALTO信息发布划分为多个ALTO服务（例如，地图服务、地图过滤服务、端点属性服务和端点成本服务）。每个ALTO服务都提供一组给定的功能，并由一组信息资源实现，这些信息资源由信息资源目录公布，用于指导ALTO客户端。
This document uses the following terms defined in [RFC5693]: Application, Overlay Network, Peer, Resource, Resource Identifier, Resource Provider, Resource Consumer, Resource Directory, Transport Address, ALTO Server, ALTO Client, ALTO Query, ALTO Response, ALTO Transaction, Local Traffic, Peering Traffic, and Transit Traffic.
本文档使用[RFC5693]中定义的以下术语：应用程序、覆盖网络、对等、资源、资源标识符、资源提供者、资源使用者、资源目录、传输地址、ALTO服务器、ALTO客户端、ALTO查询、ALTO响应、ALTO事务、本地通信、对等通信和传输通信。
This document extends the term "ALTO Service" defined in [RFC5693]. In particular, by adopting a modular design, this document allows the ALTO Protocol to provide multiple ALTO services.
本文件扩展了[RFC5693]中定义的术语“ALTO服务”。特别是，通过采用模块化设计，本文件允许ALTO协议提供多个ALTO服务。
This document also uses the following additional terms: Endpoint Address, Network Location, ALTO Information, and ALTO Information Base.
本文档还使用以下附加术语：端点地址、网络位置、ALTO信息和ALTO信息库。
An endpoint is an application or host that is capable of communicating (sending and/or receiving messages) on a network.
端点是能够在网络上进行通信（发送和/或接收消息）的应用程序或主机。
An endpoint is typically either a resource provider or a resource consumer.
端点通常是资源提供者或资源使用者。
An endpoint address represents the communication address of an endpoint. Common forms of endpoint addresses include IP addresses, Media Access Control (MAC) addresses, and overlay IDs. An endpoint address can be network-attachment based (e.g., IP address) or network-attachment agnostic (e.g., MAC address).
端点地址表示端点的通信地址。端点地址的常见形式包括IP地址、媒体访问控制（MAC）地址和覆盖ID。端点地址可以是基于网络附件的（例如，IP地址）或与网络附件无关的（例如，MAC地址）。
Each endpoint address has an associated address type, which indicates both its syntax and semantics.
每个端点地址都有一个关联的地址类型，指示其语法和语义。
This document uses network location as a generic term to denote a single endpoint or a group of endpoints. For instance, it can be a single IPv4 or IPv6 address, an IPv4 or IPv6 prefix, or a set of prefixes.
本文档使用网络位置作为通用术语来表示单个端点或一组端点。例如，它可以是单个IPv4或IPv6地址、IPv4或IPv6前缀或一组前缀。
This document uses ALTO information as a generic term to refer to the network information provided by an ALTO server.
本文档使用ALTO信息作为泛指ALTO服务器提供的网络信息的术语。
This document uses the term ALTO information base to refer to the internal representation of ALTO information maintained by an ALTO server. Note that the structure of this internal representation is not defined by this document.
本文档使用术语ALTO信息库来表示ALTO服务器维护的ALTO信息的内部表示。请注意，本文档未定义此内部表示的结构。
This section defines the ALTO architecture and the ALTO Protocol's place in the overall architecture.
本节定义了ALTO体系结构和ALTO协议在整个体系结构中的位置。
Each network region in the global Internet can provide its ALTO services, which convey network information from the perspective of that network region. A network region in this context can be an Autonomous System (AS), an ISP, a region smaller than an AS or ISP, or a set of ISPs. The specific network region that an ALTO service represents will depend on the ALTO deployment scenario and ALTO service discovery mechanism.
全球互联网中的每个网络区域都可以提供其ALTO服务，从该网络区域的角度传送网络信息。在此上下文中，网络区域可以是自治系统（AS）、ISP、小于AS或ISP的区域或一组ISP。ALTO服务所代表的特定网络区域将取决于ALTO部署场景和ALTO服务发现机制。
The ALTO services specified in this document define network endpoints (and aggregations thereof) and generic costs amongst them from the region's perspective. The network endpoints may include all endpoints in the global Internet. We say that the network information provided by the ALTO services of a network region represents the "my-Internet view" of the network region.
本文件中规定的ALTO服务从地区角度定义了网络端点（及其聚合）和它们之间的一般成本。网络端点可以包括全球因特网中的所有端点。我们说，网络区域的ALTO服务提供的网络信息代表网络区域的“我的互联网视图”。
The "my-Internet view" defined in this document does not specify the internal topology of a network, and hence, it is said to provide a "single-node" abstract topology. Extensions to this document may provide topology details in "my-Internet view".
本文档中定义的“我的Internet视图”没有指定网络的内部拓扑，因此，据说它提供了“单节点”抽象拓扑。本文档的扩展可能会在“我的Internet视图”中提供拓扑详细信息。
Figure 1 provides an overall picture of ALTO's system architecture, so that one can better understand the ALTO services and the role of the ALTO Protocol. In this architecture, an ALTO server prepares ALTO information, an ALTO client uses ALTO service discovery to identify an appropriate ALTO server, and the ALTO client requests available ALTO information from the ALTO server using the ALTO Protocol.
图1提供了ALTO系统架构的总体图，以便更好地了解ALTO服务和ALTO协议的作用。在此体系结构中，ALTO服务器准备ALTO信息，ALTO客户端使用ALTO服务发现来识别适当的ALTO服务器，ALTO客户端使用ALTO协议从ALTO服务器请求可用的ALTO信息。
The ALTO information provided by the ALTO server can be updated dynamically based on network conditions, or they can be seen as a policy that is updated on a longer time scale.
ALTO服务器提供的ALTO信息可以根据网络条件动态更新，也可以将其视为在较长时间范围内更新的策略。
+-------------------------------------------------------------------+
| Network Region |
| |
| +-----------+ |
| | Routing | |
| +--------------+ | Protocols | |
| | Provisioning | +-----------+ |
| | Policy | | |
| +--------------+\ | |
| \ | |
| \ | |
| +-----------+ \+---------+ +--------+ |
| |Dynamic | | ALTO | ALTO Protocol | ALTO | |
| |Network |.......| Server | ==================== | Client | |
| |Information| +---------+ +--------+ |
| +-----------+ / / |
| / ALTO SD Query/Response / |
| / / |
| +----------+ +----------------+ |
| | External | | ALTO Service | |
| | Interface| | Discovery (SD) | |
| +----------+ +----------------+ |
| | |
+-------------------------------------------------------------------+
|
+------------------+
| Third Parties |
| |
| Content Providers|
+------------------+
+-------------------------------------------------------------------+
| Network Region |
| |
| +-----------+ |
| | Routing | |
| +--------------+ | Protocols | |
| | Provisioning | +-----------+ |
| | Policy | | |
| +--------------+\ | |
| \ | |
| \ | |
| +-----------+ \+---------+ +--------+ |
| |Dynamic | | ALTO | ALTO Protocol | ALTO | |
| |Network |.......| Server | ==================== | Client | |
| |Information| +---------+ +--------+ |
| +-----------+ / / |
| / ALTO SD Query/Response / |
| / / |
| +----------+ +----------------+ |
| | External | | ALTO Service | |
| | Interface| | Discovery (SD) | |
| +----------+ +----------------+ |
| | |
+-------------------------------------------------------------------+
|
+------------------+
| Third Parties |
| |
| Content Providers|
+------------------+
Figure 1: Basic ALTO Architecture
图1：基本ALTO架构
Figure 1 illustrates that the ALTO information provided by an ALTO server may be influenced (at the service provider's discretion) by other systems. In particular, the ALTO server can aggregate information from multiple systems to provide an abstract and unified view that can be more useful to applications. Examples of other systems include (but are not limited to) static network configuration databases, dynamic network information, routing protocols, provisioning policies, and interfaces to outside parties. These components are shown in the figure for completeness but are outside the scope of this specification. Recall that while the ALTO Protocol may convey dynamic network information, it is not intended to replace near-real-time congestion control protocols.
图1说明了ALTO服务器提供的ALTO信息可能会受到其他系统的影响（由服务提供商自行决定）。特别是，ALTO服务器可以聚合来自多个系统的信息，以提供对应用程序更有用的抽象和统一视图。其他系统的示例包括（但不限于）静态网络配置数据库、动态网络信息、路由协议、供应策略以及与外部各方的接口。图中显示了这些组件的完整性，但不在本规范的范围内。回想一下，虽然ALTO协议可以传送动态网络信息，但它并不打算取代近实时拥塞控制协议。
It may also be possible for an ALTO server to exchange network information with other ALTO servers (either within the same administrative domain or another administrative domain with the consent of both parties) in order to adjust exported ALTO information. Such a protocol is also outside the scope of this specification.
ALTO服务器也可以与其他ALTO服务器（在同一管理域内或双方同意的另一管理域内）交换网络信息，以调整导出的ALTO信息。此类协议也不在本规范的范围内。
ALTO information may be useful to a large number of applications and users. At the same time, distributing ALTO information must be efficient and not become a bottleneck.
ALTO信息可能对大量应用程序和用户有用。同时，分发ALTO信息必须高效，而不是成为瓶颈。
The design of the ALTO Protocol allows integration with the existing HTTP caching infrastructure to redistribute ALTO information. If caching or redistribution is used, the response message to an ALTO client may be returned from a third party.
ALTO协议的设计允许与现有HTTP缓存基础架构集成，以重新分发ALTO信息。如果使用缓存或重新分发，则可能会从第三方返回到ALTO客户端的响应消息。
Application-dependent mechanisms, such as P2P Distributed Hash Tables (DHTs) or P2P file sharing, may be used to cache and redistribute ALTO information. This document does not define particular mechanisms for such redistribution.
依赖于应用程序的机制，如P2P分布式哈希表（DHT）或P2P文件共享，可用于缓存和重新分发ALTO信息。本文件未定义此类再分配的特定机制。
Additional protocol mechanisms (e.g., expiration times and digital signatures for returned ALTO information) are left for future investigation.
其他协议机制（例如，返回的ALTO信息的过期时间和数字签名）留作将来调查。
The ALTO Protocol conveys network information through ALTO information services (services for short), where each service defines a set of related functionalities. An ALTO client can request each service individually. All of the services defined in ALTO are said to form the ALTO service framework and are provided through a common transport protocol; messaging structure and encoding; and transaction model. Functionalities offered in different services can overlap.
ALTO协议通过ALTO信息服务（简称服务）传递网络信息，其中每个服务定义一组相关功能。ALTO客户端可以单独请求每个服务。ALTO中定义的所有服务被称为构成ALTO服务框架，并通过公共传输协议提供；消息结构和编码；以及交易模型。不同服务中提供的功能可能重叠。
The goals of the ALTO information services defined in this document are to convey (1) network locations, which denote the locations of endpoints at a network, (2) provider-defined costs for paths between pairs of network locations, and (3) network-related properties of endpoints. The aforementioned goals are achieved by defining the Map Service, which provides the core ALTO information to clients, and three additional information services: the Map-Filtering Service, the Endpoint Property Service (EPS), and the Endpoint Cost Service (ECS). Additional information services can be defined in companion documents. Figure 2 gives an overview of the information services. Details of the services are presented in subsequent sections.
本文件中定义的ALTO信息服务的目标是传达（1）网络位置，表示网络中端点的位置，（2）提供商定义的成对网络位置之间路径的成本，以及（3）端点的网络相关属性。通过定义向客户端提供核心ALTO信息的Map服务和三个附加信息服务（Map Filtering Service、Endpoint Property Service（EPS）和Endpoint Cost Service（ECS））实现上述目标。附加信息服务可在附带文档中定义。图2给出了信息服务的概述。服务详情将在后续章节中介绍。
.-----------------------------------------.
| ALTO Information Services |
| .-----------. .----------. .----------. |
| | Map- | | Endpoint | | Endpoint | |
| | Filtering | | Property | | Cost | |
| | Service | | Service | | Service | |
| `-----------' `----------' `----------' |
| .-------------------------------------. |
| | Map Service | |
| | .-------------. .--------------. | |
| | | Network Map | | Cost Map | | |
| | `-------------' `--------------' | |
| `-------------------------------------' |
`-----------------------------------------'
.-----------------------------------------.
| ALTO Information Services |
| .-----------. .----------. .----------. |
| | Map- | | Endpoint | | Endpoint | |
| | Filtering | | Property | | Cost | |
| | Service | | Service | | Service | |
| `-----------' `----------' `----------' |
| .-------------------------------------. |
| | Map Service | |
| | .-------------. .--------------. | |
| | | Network Map | | Cost Map | | |
| | `-------------' `--------------' | |
| `-------------------------------------' |
`-----------------------------------------'
Figure 2: ALTO Information Service Framework
图2:ALTO信息服务框架
The Map Service provides batch information to ALTO clients in the forms of ALTO network maps (network maps for short) and ALTO cost maps (cost maps for short). An ALTO network map (See Section 5) provides a full set of network location groupings defined by the ALTO server and the endpoints contained within each grouping. An ALTO cost map (see Section 6) provides costs between defined groupings.
地图服务以ALTO网络地图（简称网络地图）和ALTO成本地图（简称成本地图）的形式向ALTO客户端提供批量信息。ALTO网络图（见第5节）提供了一整套由ALTO服务器定义的网络位置分组以及每个分组中包含的端点。ALTO成本图（见第6节）提供了定义分组之间的成本。
These two maps can be thought of (and implemented) as simple files with appropriate encoding provided by the ALTO server.
这两个映射可以看作（并实现）简单的文件，由ALTO服务器提供适当的编码。
Resource-constrained ALTO clients may benefit from the filtering of query results at the ALTO server. This avoids the situation in which an ALTO client first spends network bandwidth and CPU cycles to collect results and then performs client-side filtering. The Map-Filtering Service allows ALTO clients to query an ALTO server on ALTO network maps and/or cost maps based on additional parameters.
资源受限的ALTO客户端可以从ALTO服务器上的查询结果过滤中获益。这避免了ALTO客户端首先花费网络带宽和CPU周期来收集结果，然后执行客户端过滤的情况。地图过滤服务允许ALTO客户端根据其他参数在ALTO网络地图和/或成本地图上查询ALTO服务器。
This service allows ALTO clients to look up properties for individual endpoints. An example property of an endpoint is its network location (i.e., its grouping defined by the ALTO server). Another example property is its connectivity type such as ADSL (Asymmetric Digital Subscriber Line), Cable, or FTTH (Fiber To The Home).
此服务允许ALTO客户端查找各个端点的属性。端点的一个示例属性是其网络位置（即ALTO服务器定义的分组）。另一个示例属性是其连接类型，如ADSL（非对称数字用户线）、电缆或FTTH（光纤到家）。
Some ALTO clients may also benefit from querying for costs and rankings based on endpoints. The Endpoint Cost Service allows an ALTO server to return costs directly amongst endpoints.
一些ALTO客户还可以从基于端点的成本和排名查询中获益。端点成本服务允许ALTO服务器直接在端点之间返回成本。
An ALTO network map defines a grouping of network endpoints. This document uses ALTO network map to refer to the syntax and semantics of how an ALTO server defines the grouping. This document does not discuss the internal representation of this data structure within an ALTO server.
ALTO网络映射定义了一组网络端点。本文档使用ALTO网络图来参考ALTO服务器如何定义分组的语法和语义。本文档不讨论ALTO服务器中此数据结构的内部表示。
The definition of ALTO network maps is based on the observation that, in reality, many endpoints are near by to one another in terms of network connectivity. By treating a group of nearby endpoints together as a single entity, an ALTO server indicates aggregation of these endpoints due to their proximity. This aggregation can also lead to greater scalability without losing critical information when conveying other network information (e.g., when defining cost maps).
ALTO网络地图的定义基于这样一个观察结果：实际上，许多端点在网络连通性方面彼此相邻。通过将附近的一组端点视为一个单独的实体，ALTO服务器表示这些端点由于其邻近性而聚集在一起。这种聚合还可以在传输其他网络信息时（例如，在定义成本映射时），在不丢失关键信息的情况下实现更大的可扩展性。
One issue is that proximity varies depending on the granularity of the ALTO information configured by the provider. In one deployment, endpoints on the same subnet may be considered close; while in another deployment, endpoints connected to the same Point of Presence (POP) may be considered close.
一个问题是，接近度取决于提供商配置的ALTO信息的粒度。在一次部署中，同一子网上的端点可能被视为已关闭；在另一个部署中，连接到同一存在点（POP）的端点可能被视为接近。
ALTO introduces provider-defined network location identifiers called Provider-defined Identifiers (PIDs) to provide an indirect and network-agnostic way to specify an aggregation of network endpoints that may be treated similarly, based on network topology, type, or other properties. Specifically, a PID is a string of type PIDName (see Section 10.1) and its associated set of endpoint addresses. As discussed above, there can be many different ways of grouping the endpoints and assigning PIDs. For example, a PID may denote a subnet, a set of subnets, a metropolitan area, a POP, an autonomous system, or a set of autonomous systems. Interpreting the PIDs defined in an ALTO network map using the "single-node" abstraction, one can consider that each PID represents an abstract port (POP) that connects a set of endpoints.
ALTO引入了称为提供商定义标识符（PID）的提供商定义的网络位置标识符，以提供一种间接的、与网络无关的方式来指定网络端点的聚合，这些端点可以根据网络拓扑、类型或其他属性进行类似处理。具体而言，PID是PIDName类型的字符串（参见第10.1节）及其关联的端点地址集。如上所述，可以有许多不同的方法来分组端点和分配PID。例如，PID可以表示子网、一组子网、城域、POP、自治系统或一组自治系统。使用“单节点”抽象来解释在阿尔托网络地图中定义的PID，可以考虑每个PID代表连接端点集的抽象端口（POP）。
A key use case of PIDs is to specify network preferences (costs) between PIDs instead of individual endpoints. This allows cost information to be more compactly represented and updated at a faster time scale than the network aggregations themselves. For example, an
PIDs的一个关键用例是指定PIDs之间的网络首选项（成本），而不是单个端点。这使得成本信息能够以比网络聚合本身更快的时间尺度更紧凑地表示和更新。例如，一个
ISP may prefer that endpoints associated with the same POP in a P2P application communicate locally instead of communicating with endpoints in other POPs. The ISP may aggregate endpoints within a POP into a single PID in a network map. The cost may be encoded to indicate that network locations within the same PID are preferred; for example, cost(PID_i, PID_i) == c and cost(PID_i, PID_j) > c for i != j. Section 6 provides further details on using PIDs to represent costs in an ALTO cost map.
ISP可能更希望与P2P应用程序中的同一POP关联的端点在本地通信，而不是与其他POP中的端点通信。ISP可以将POP中的端点聚合到网络映射中的单个PID中。成本可被编码以指示相同PID内的网络位置是优选的；例如，cost（PID_i，PID_i）==c，cost（PID_i，PID_j）>c表示i！=J第6节提供了有关使用PID在ALTO成本图中表示成本的更多详细信息。
The endpoints aggregated into a PID are denoted by endpoint addresses. There are many types of addresses, such as IP addresses, MAC addresses, or overlay IDs. This document specifies (in Section 10.4) how to specify IPv4/IPv6 addresses or prefixes. Extension documents may define further address types; Section 14.4 of this document provides an IANA registry for endpoint address types.
聚合到PID中的端点由端点地址表示。有许多类型的地址，例如IP地址、MAC地址或覆盖ID。本文档指定（第10.4节）如何指定IPv4/IPv6地址或前缀。扩展文档可以定义更多的地址类型；本文档第14.4节提供了端点地址类型的IANA注册表。
This document uses the ALTO network map shown in Figure 3 in most examples.
本文档在大多数示例中使用图3所示的ALTO网络图。
.------------------------------------------------------------.
| An ALTO Network Map |
| |
| .-----------------------------------. .----------------. |
| | NetLoc: PID-1 | | NetLoc: PID-3 | |
| | .------------------------------. | | | |
| | | 192.0.2.0/24 | | | .-----------. | |
| | | .--------------------------. | | | | 0.0.0.0/0 | | |
| | | | Endpoint: 192.0.2.34 | | | | `-----------` | |
| | | `--------------------------` | | | | |
| | `------------------------------` | | | |
| | .------------------------------. | | | |
| | | 198.51.100.0/25 | | | | |
| | | .--------------------------. | | | | |
| | | | Endpoint: 198.51.100.100 | | | | | |
| | | `--------------------------` | | | | |
| | `------------------------------` | | | |
| `-----------------------------------` | | |
| | | |
| .-----------------------------------. | | |
| | NetLoc: PID-2 | | | |
| | .------------------------------. | | | |
| | | 198.51.100.128/25 | | | | |
| | `------------------------------` | | | |
| `-----------------------------------` `----------------` |
`------------------------------------------------------------`
.------------------------------------------------------------.
| An ALTO Network Map |
| |
| .-----------------------------------. .----------------. |
| | NetLoc: PID-1 | | NetLoc: PID-3 | |
| | .------------------------------. | | | |
| | | 192.0.2.0/24 | | | .-----------. | |
| | | .--------------------------. | | | | 0.0.0.0/0 | | |
| | | | Endpoint: 192.0.2.34 | | | | `-----------` | |
| | | `--------------------------` | | | | |
| | `------------------------------` | | | |
| | .------------------------------. | | | |
| | | 198.51.100.0/25 | | | | |
| | | .--------------------------. | | | | |
| | | | Endpoint: 198.51.100.100 | | | | | |
| | | `--------------------------` | | | | |
| | `------------------------------` | | | |
| `-----------------------------------` | | |
| | | |
| .-----------------------------------. | | |
| | NetLoc: PID-2 | | | |
| | .------------------------------. | | | |
| | | 198.51.100.128/25 | | | | |
| | `------------------------------` | | | |
| `-----------------------------------` `----------------` |
`------------------------------------------------------------`
Figure 3: Example Network Map
图3：示例网络图
An ALTO server indicates preferences amongst network locations in the form of path costs. Path costs are generic costs and can be internally computed by a network provider according to its own policy.
ALTO服务器以路径成本的形式表示网络位置之间的首选项。路径成本是一般成本，可由网络提供商根据其自身的策略在内部计算。
For a given ALTO network map, an ALTO cost map defines path costs pairwise amongst the set of source and destination network locations defined by the PIDs contained in the network map. Each path cost is the end-to-end cost when a unit of traffic goes from the source to the destination.
对于给定的ALTO网络图，ALTO成本图在网络图中包含的PID定义的源和目标网络位置集合中成对定义路径成本。当一个单位的流量从源到目的地时，每个路径成本都是端到端成本。
Since cost is directional from the source to the destination, an application, when using ALTO information, may independently determine how the resource consumer and resource provider are designated as the source or destination in an ALTO query and, hence, how to utilize the path cost provided by ALTO information. For example, if the cost is
由于成本是从源到目的地的定向成本，应用程序在使用ALTO信息时，可以独立地确定如何在ALTO查询中将资源使用者和资源提供者指定为源或目的地，从而确定如何利用ALTO信息提供的路径成本。例如，如果成本是
expected to be correlated with throughput, a typical application concerned with bulk data retrieval may use the resource provider as the source and the resource consumer as the destination.
预期与吞吐量相关，与批量数据检索相关的典型应用程序可能将资源提供者用作源，将资源使用者用作目标。
One advantage of separating ALTO information into network maps and cost maps is that the two types of maps can be updated at different time scales. For example, network maps may be stable for a longer time while cost maps may be updated to reflect more dynamic network conditions.
将ALTO信息分为网络地图和成本地图的一个优点是，这两种类型的地图可以在不同的时间尺度上更新。例如，网络图可能在较长时间内保持稳定，而成本图可能会更新以反映更动态的网络状况。
As used in this document, an ALTO cost map refers to the syntax and semantics of the information distributed by the ALTO server. This document does not discuss the internal representation of this data structure within the ALTO server.
如本文所用，ALTO成本图指的是ALTO服务器分发的信息的语法和语义。本文档不讨论ALTO服务器中此数据结构的内部表示。
Path costs have attributes:
路径成本具有以下属性：
o Cost Metric: identifies what the costs represent;
o 成本指标：确定成本所代表的内容；
o Cost Mode: identifies how the costs should be interpreted.
o 成本模式：确定应如何解释成本。
The combination of a cost metric and a cost mode defines an ALTO cost type. Certain queries for ALTO cost maps allow the ALTO client to indicate the desired cost type. For a given ALTO server, the combination of cost type and network map defines a key. In other words, an ALTO server MUST NOT define two ALTO cost maps with the same cost type \ network map pair.
成本度量和成本模式的组合定义了ALTO成本类型。ALTO成本图的某些查询允许ALTO客户机指示所需的成本类型。对于给定的ALTO服务器，成本类型和网络映射的组合定义了一个密钥。换句话说，ALTO服务器不得使用相同的成本类型\网络映射对定义两个ALTO成本映射。
The cost metric attribute indicates what the cost represents. For example, an ALTO server could define costs representing air miles, hop-counts, or generic routing costs.
“成本度量”属性指示成本所代表的内容。例如，ALTO服务器可以定义表示航空里程、跳数或一般路由成本的成本。
Cost metrics are indicated in protocol messages as strings.
成本指标在协议消息中表示为字符串。
An ALTO server MUST offer the "routingcost" cost metric.
ALTO服务器必须提供“路由成本”成本指标。
This cost metric conveys a generic measure for the cost of routing traffic from a source to a destination. A lower value indicates a higher preference for traffic to be sent from a source to a destination.
此成本度量传达了将流量从源路由到目的地的成本的通用度量。较低的值表示对从源发送到目标的流量的偏好较高。
Note that an ISP may internally compute routing cost using any method that it chooses (e.g., air miles or hop-count) as long as it conforms to the semantics.
请注意，ISP可以使用其选择的任何方法（例如，航空里程或跳数）在内部计算路由成本，只要它符合语义。
The cost mode attribute indicates how costs should be interpreted. Specifically, the cost mode attribute indicates whether returned costs should be interpreted as numerical values or ordinal rankings.
“成本模式”属性指示应如何解释成本。具体来说，成本模式属性指示返回的成本应解释为数值还是顺序排名。
It is important to communicate such information to ALTO clients, as certain operations may not be valid on certain costs returned by an ALTO server. For example, it is possible for an ALTO server to return a set of IP addresses with costs indicating a ranking of the IP addresses. Arithmetic operations that would make sense for numerical values, do not make sense for ordinal rankings. ALTO clients may handle such costs differently.
将此类信息传达给ALTO客户端非常重要，因为某些操作可能对ALTO服务器返回的某些成本无效。例如，ALTO服务器可以返回一组IP地址，其成本表示IP地址的排名。对数值有意义的算术运算对顺序排名没有意义。ALTO客户可能会以不同的方式处理此类成本。
Cost modes are indicated in protocol messages as strings.
成本模式在协议消息中表示为字符串。
An ALTO server MUST support at least one of the following modes: numerical and ordinal. An ALTO client needs to be cognizant of operations when its desired cost mode is not supported. Specifically, an ALTO client desiring numerical costs MAY adjust its behaviors if only the ordinal cost mode is available. Alternatively, an ALTO client desiring ordinal costs MAY construct ordinal costs from retrieved numerical values, if only the numerical cost mode is available.
ALTO服务器必须至少支持以下模式之一：数字模式和顺序模式。当所需的成本模式不受支持时，ALTO客户需要了解运营情况。具体而言，如果只有序数成本模式可用，则需要数字成本的ALTO客户可以调整其行为。或者，如果只有数字成本模式可用，则希望顺序成本的ALTO客户可以从检索到的数字值构建顺序成本。
This cost mode is indicated by the string "numerical". This mode indicates that it is safe to perform numerical operations (e.g., normalization or computing ratios for weighted load-balancing) on the returned costs. The values are floating-point numbers.
此成本模式由字符串“数字”表示。此模式表示对返回的成本执行数字操作（例如，标准化或计算加权负载平衡的比率）是安全的。这些值是浮点数。
This cost mode is indicated by the string "ordinal". This mode indicates that the cost values in a cost map represent ranking (relative to all other values in a cost map), not actual costs. The values are non-negative integers, with a lower value indicating a higher preference. Ordinal cost values in a cost map need not be unique or contiguous. In particular, it is possible that two entries in a cost map have an identical rank (ordinal cost value). This document does not specify any behavior by an ALTO client in this case; an ALTO client may decide to break ties by random selection, other application knowledge, or some other means.
此成本模式由字符串“序号”表示。此模式表示成本图中的成本值表示排名（相对于成本图中的所有其他值），而不是实际成本。这些值是非负整数，值越小表示偏好越高。成本映射中的序数成本值不必是唯一的或连续的。特别是，成本图中的两个条目可能具有相同的等级（顺序成本值）。本文件未规定ALTO客户在这种情况下的任何行为；ALTO客户可能决定通过随机选择、其他应用程序知识或其他方式打破联系。
A request for an ALTO cost map will either explicitly or implicitly include a list of source network locations and a list of destination network locations. (Recall that a network location can be an endpoint address or a PID.)
对ALTO成本图的请求将显式或隐式地包括源网络位置列表和目标网络位置列表。（回想一下，网络位置可以是端点地址或PID。）
Specifically, assume that a request specifies a list of source network locations, say [Src_1, Src_2, ..., Src_m], and a list of destination network locations, say [Dst_1, Dst_2, ..., Dst_n].
具体地说，假设请求指定源网络位置列表，例如[Src_1，Src_2，…，Src_m]，以及目标网络位置列表，例如[Dst_1，Dst_2，…，Dst_n]。
The ALTO server will return the path cost for each of the m*n communicating pairs (i.e., Src_1 -> Dst_1, ..., Src_1 -> Dst_n, ..., Src_m -> Dst_1, ..., Src_m -> Dst_n). If the ALTO server does not define the path cost for a particular pair, that cost may be omitted. This document refers to this structure as a cost map.
ALTO服务器将返回每个m*n通信对的路径成本（即，Src_1->Dst_1，…，Src_1->Dst_n，…，Src_m->Dst_1，…，Src_m->Dst_n）。如果ALTO服务器未定义特定对的路径成本，则可以忽略该成本。本文件将此结构称为成本图。
If the cost mode is ordinal, the path cost of each communicating pair is relative to the m*n entries.
如果成本模式为序号，则每个通信对的路径成本相对于m*n条目。
An ALTO cost map gives path costs between the PIDs defined in an ALTO network map. An ALTO server may modify an ALTO network map at any time, say by adding or deleting PIDs, or even redefining them. Hence, to effectively use an instance of an ALTO cost map, an ALTO client must know which version of the network map defined the PIDs in that cost map. Version tags allow an ALTO client to correlate cost map instances with the corresponding versions of the network maps.
ALTO成本图给出了ALTO网络图中定义的PID之间的路径成本。ALTO服务器可以随时修改ALTO网络图，例如添加或删除PID，甚至重新定义PID。因此，为了有效地使用ALTO成本图的实例，ALTO客户端必须知道哪个版本的网络图定义了该成本图中的PID。版本标记允许ALTO客户端将成本映射实例与网络映射的相应版本关联起来。
Specifically, a version tag is a tuple of (1) an ID for the resource (e.g., an ALTO network map) and (2) a tag (an opaque string) associated with the version of that resource. An ALTO network map distributed by an ALTO server includes its version tag. An ALTO cost map referring to PIDs also includes the version tag for the network map on which it is based.
具体地说，版本标记是（1）资源的ID（例如，ALTO网络映射）和（2）与该资源的版本相关联的标记（不透明字符串）的元组。ALTO服务器分发的ALTO网络地图包含其版本标签。参考PIDs的ALTO成本图还包括其所基于的网络图的版本标签。
Two ALTO network maps are the same if they have the same version tag. Whenever the content of an ALTO network map maintained by an ALTO server changes, the tag MUST also be changed. Possibilities of setting the tag component include the last-modified timestamp for the network map, or a hash of its contents, where the collision probability is considered zero in practical deployment scenarios.
如果两个ALTO网络地图具有相同的版本标记，则它们是相同的。每当ALTO服务器维护的ALTO网络地图的内容发生更改时，标签也必须更改。设置标记组件的可能性包括网络映射的最后修改时间戳，或其内容的散列，在实际部署场景中，冲突概率被视为零。
An ALTO server can update an ALTO cost map at any time. Hence, the same cost map retrieved from the same ALTO server but from different requests can be inconsistent.
ALTO服务器可以随时更新ALTO成本图。因此，从同一ALTO服务器但从不同请求检索到的相同成本映射可能不一致。
An endpoint property defines a network-aware property of an endpoint.
端点属性定义端点的网络感知属性。
For each endpoint and an endpoint property type, there can be a value for the property. The type of an endpoint property is indicated in protocol messages as a string. The value depends on the specific property. For example, for a property such as whether an endpoint is metered, the value is a true or false value. See Section 10.8 for more details on specifying endpoint properties.
对于每个端点和端点属性类型，该属性可以有一个值。端点属性的类型在协议消息中表示为字符串。该值取决于特定属性。例如，对于端点是否已计量等属性，该值为true或false值。有关指定端点属性的详细信息，请参见第10.8节。
An ALTO server MUST define the "pid" endpoint property type for each ALTO network map that it provides. Specifically, each ALTO network map defines multiple PIDs. For an "ipv4"/"ipv6" network map, given an endpoint's IP address, the ALTO server uses the algorithm specified in Section 11.2.2 to look up the PID of the endpoint. This PID is the "pid" property of the endpoint for the network map. See Section 11.4.1.7 for an example.
ALTO服务器必须为其提供的每个ALTO网络映射定义“pid”端点属性类型。具体而言，每个ALTO网络图定义了多个PID。对于“ipv4”/“ipv6”网络映射，给定端点的IP地址，ALTO服务器使用第11.2.2节中指定的算法查找端点的PID。此PID是网络映射端点的“PID”属性。示例见第11.4.1.7节。
This section first specifies general client and server processing. The details of specific services will be covered in the following sections.
本节首先指定常规客户端和服务器处理。具体服务的细节将在以下章节中介绍。
The ALTO Protocol uses a REST-ful design. There are two primary components to this design:
ALTO协议使用REST-ful设计。此设计有两个主要组件：
o Information Resources: Each ALTO service is realized by a set of network information resources. Each information resource has a media type [RFC2046]. An ALTO client may construct an HTTP request for a particular information resource (including any parameters, if necessary), and the ALTO server returns the requested information resource in an HTTP response.
o 信息资源：每个ALTO服务都是通过一套网络信息资源来实现的。每个信息资源都有一个媒体类型[RFC2046]。ALTO客户端可以为特定信息资源构造HTTP请求（必要时包括任何参数），ALTO服务器在HTTP响应中返回请求的信息资源。
o Information Resource Directory (IRD): An ALTO server uses an IRD to inform an ALTO client about a list of available information resources and the URI at which each can be accessed. ALTO clients consult the IRDs to determine the services provided by ALTO servers.
o 信息资源目录（IRD）：ALTO服务器使用IRD通知ALTO客户端可用信息资源的列表以及可以访问每个资源的URI。ALTO客户咨询税务局，以确定ALTO服务器提供的服务。
This document uses JSONString, JSONNumber, and JSONBool to indicate the JSON string, number, and boolean types, respectively. The type JSONValue indicates a JSON value, as specified in Section 3 of [RFC7159].
本文档使用JSONString、JSONNumber和JSONBool分别表示JSON字符串、数字和布尔类型。JSONValue类型表示JSON值，如[RFC7159]第3节所述。
This document uses an adaptation of the C-style struct notation to define JSON objects. A JSON object consists of name/value pairs. This document refers to each pair as a field. In some context, this document also refers to a field as an attribute. The name of a field/attribute may be referred to as the key. An optional field is enclosed by [ ]. In the definitions, the JSON names of the fields are case sensitive. An array is indicated by two numbers in angle brackets, <m..n>, where m indicates the minimal number of values and n is the maximum. When this document uses * for n, it means no upper bound.
本文档使用C风格的结构表示法来定义JSON对象。JSON对象由名称/值对组成。本文档将每对引用为一个字段。在某些上下文中，此文档还将字段作为属性引用。字段/属性的名称可以称为键。可选字段由[]括起。在定义中，字段的JSON名称区分大小写。一个数组由尖括号中的两个数字表示，<m..n>，其中m表示最小值，n表示最大值。当本文档使用*表示n时，表示没有上限。
For example, the definition below defines a new type Type4, with three fields named "name1", "name2", and "name3", respectively. The field named "name3" is optional, and the field named "name2" is an array of at least one value.
例如，下面的定义定义了一个新的类型Type4，其中有三个字段分别命名为“name1”、“name2”和“name3”。名为“name3”的字段是可选的，名为“name2”的字段是至少一个值的数组。
object { Type1 name1; Type2 name2<1..*>; [Type3 name3;]
} Type4;
object { Type1 name1; Type2 name2<1..*>; [Type3 name3;]
} Type4;
This document also defines dictionary maps (or maps for short) from strings to JSON values. For example, the definition below defines a Type3 object as a map. Type1 must be defined as string, and Type2 can be defined as any type.
本文档还定义了从字符串到JSON值的字典映射（简称映射）。例如，下面的定义将Type3对象定义为映射。Type1必须定义为字符串，Type2可以定义为任何类型。
object-map { Type1 -> Type2; } Type3;
object-map { Type1 -> Type2; } Type3;
This document uses subtyping to denote that one type is derived from another type. The example below denotes that TypeDerived is derived from TypeBase. TypeDerived includes all fields defined in TypeBase. If TypeBase does not have a field named "name1", TypeDerived will have a new field named "name1". If TypeBase already has a field named "name1" but with a different type, TypeDerived will have a field named "name1" with the type defined in TypeDerived (i.e., Type1 in the example).
本文档使用子类型表示一个类型派生自另一个类型。下面的示例表示TypeDerived是从TypeBase派生的。Type派生包括TypeBase中定义的所有字段。如果TypeBase没有名为“name1”的字段，则TypeDevertive将有一个名为“name1”的新字段。如果TypeBase已经有一个名为“name1”的字段，但其类型不同，那么TypeDerivated将有一个名为“name1”的字段，其类型在TypeDerivated中定义（即示例中的Type1）。
object { Type1 name1; } TypeDerived : TypeBase;
object { Type1 name1; } TypeDerived : TypeBase;
Note that, despite the notation, no standard, machine-readable interface definition or schema is provided in this document. Extension documents may describe these as necessary.
请注意，尽管使用了符号，但本文档中未提供标准的机器可读接口定义或模式。必要时，扩展文件可对其进行描述。
The ALTO Protocol employs standard HTTP [RFC7230]. It is used for discovering available information resources at an ALTO server and retrieving Information Resources. ALTO clients and ALTO servers use HTTP requests and responses carrying ALTO-specific content with encoding as specified in this document, and they MUST be compliant with [RFC7230].
ALTO协议采用标准HTTP[RFC7230]。它用于发现ALTO服务器上的可用信息资源并检索信息资源。ALTO客户端和ALTO服务器使用HTTP请求和响应，这些请求和响应带有本文档中指定的编码的ALTO特定内容，并且它们必须符合[RFC7230]。
Instead of specifying the generic application/json media type for all ALTO request parameters (if any) and responses, ALTO clients and servers use multiple, specific JSON-based media types (e.g., application/alto-networkmap+json, application/alto-costmap+json) to indicate content types; see Table 2 for a list of media types defined in this document. This allows easy extensibility while maintaining clear semantics and versioning. For example, a new version of a component of the ALTO Protocol (e.g., a new version of ALTO network maps) can be defined by simply introducing a new media type (e.g., application/alto-networkmap-v2+json).
ALTO客户端和服务器没有为所有ALTO请求参数（如果有）和响应指定通用应用程序/json媒体类型，而是使用多个基于json的特定媒体类型（例如，应用程序/ALTO networkmap+json、应用程序/ALTO costmap+json）来指示内容类型；有关本文档中定义的媒体类型列表，请参见表2。这允许轻松扩展，同时保持清晰的语义和版本控制。例如，只需引入新的媒体类型（例如，应用程序/ALTO-networkmap-v2+json），即可定义ALTO协议组件的新版本（例如，ALTO网络地图的新版本）。
To discover available information resources provided by an ALTO server, an ALTO client requests its IRD(s).
为了发现ALTO服务器提供的可用信息资源，ALTO客户端请求其IRD。
Specifically, using an ALTO service discovery protocol, an ALTO client obtains a URI through which it can request an information resource directory (IRD). This document refers to this IRD as the Root IRD of the ALTO client. Each entry in an IRD indicates a URI at which an ALTO server accepts requests, and returns either an information resource or an information resource directory that references additional information resources. Beginning with its Root IRD and following links to IRDs recursively, an ALTO client can discover all information resources available to it. This set of information resources is referred to as the information resource closure of the ALTO client. By inspecting its information resource closure, an ALTO client can determine whether an ALTO server supports the desired information resource, and if it is supported, the URI at which it is available.
具体地说，使用ALTO服务发现协议，ALTO客户机获得一个URI，通过该URI可以请求信息资源目录（IRD）。本文件将此IRD称为ALTO客户的根IRD。IRD中的每个条目都表示一个URI，ALTO服务器在该URI上接受请求，并返回一个信息资源或一个引用其他信息资源的信息资源目录。从根IRD开始，然后递归地链接到IRD，ALTO客户端可以发现所有可用的信息资源。这组信息资源称为ALTO客户端的信息资源关闭。通过检查其信息资源关闭情况，ALTO客户端可以确定ALTO服务器是否支持所需的信息资源，如果支持，还可以确定其可用的URI。
See Section 9.2 for a detailed specification of IRDs.
有关IRD的详细规范，请参见第9.2节。
Where possible, the ALTO Protocol uses the HTTP GET method to request resources. However, some ALTO services provide information resources that are the function of one or more input parameters. Input parameters are encoded in the HTTP request's entity body, and the ALTO client MUST use the HTTP POST method to send the parameters.
在可能的情况下，ALTO协议使用HTTPGET方法来请求资源。然而，一些ALTO服务提供的信息资源是一个或多个输入参数的函数。输入参数编码在HTTP请求的实体体中，ALTO客户端必须使用HTTP POST方法发送参数。
When requesting an ALTO information resource that requires input parameters specified in a HTTP POST request, an ALTO client MUST set the Content-Type HTTP header to the media type corresponding to the format of the supplied input parameters.
当请求需要HTTP POST请求中指定的输入参数的ALTO信息资源时，ALTO客户端必须将内容类型HTTP头设置为与所提供输入参数的格式相对应的媒体类型。
An ALTO client MUST NOT assume that the HTTP GET and POST methods are interchangeable. In particular, for an information resource that uses the HTTP GET method, an ALTO client MUST NOT assume that the information resource will accept a POST request as equivalent to a GET request.
ALTO客户端不能假定HTTP GET和POST方法是可互换的。特别是，对于使用HTTP GET方法的信息资源，ALTO客户机不能假设该信息资源将接受POST请求作为GET请求的等价物。
Upon receiving a request for an information resource that the ALTO server can provide, the ALTO server normally returns the requested information resource. In other cases, to be more informative ([RFC7231]), the ALTO server either provides the ALTO client with an information resource directory indicating how to reach the desired information resource, or it returns an ALTO error object; see Section 8.5 for more details on ALTO error handling.
收到ALTO服务器可以提供的信息资源请求后，ALTO服务器通常会返回请求的信息资源。在其他情况下，为了提供更多信息（[RFC7231]），ALTO服务器要么向ALTO客户端提供信息资源目录，指示如何到达所需的信息资源，要么返回ALTO错误对象；有关ALTO错误处理的更多详细信息，请参见第8.5节。
It is possible for an ALTO server to leverage caching HTTP intermediaries to respond to both GET and POST requests by including explicit freshness information (see Section 14 of [RFC7230]). Caching of POST requests is not widely implemented by HTTP intermediaries; however, an alternative approach is for an ALTO server, in response to POST requests, to return an HTTP 303 status code ("See Other") indicating to the ALTO client that the resulting information resource is available via a GET request to an alternate URL. HTTP intermediaries that do not support caching of POST requests could then cache the response to the GET request from the ALTO client following the alternate URL in the 303 response if the response to the subsequent GET request contains explicit freshness information.
ALTO服务器可以利用缓存HTTP中介来响应GET和POST请求，包括显式的新鲜度信息（参见[RFC7230]的第14节）。HTTP中介没有广泛实现POST请求的缓存；然而，另一种方法是，ALTO服务器响应POST请求，返回HTTP 303状态代码（“参见其他”），指示ALTO客户端结果信息资源可通过对备用URL的GET请求获得。如果对后续GET请求的响应包含明确的新鲜度信息，则不支持缓存POST请求的HTTP中介可以在303响应中的备选URL之后缓存来自ALTO客户端的GET请求响应。
The ALTO server MUST indicate the type of its response using a media type (i.e., the Content-Type HTTP header of the response).
ALTO服务器必须使用媒体类型（即响应的内容类型HTTP头）指示其响应的类型。
This specification does not indicate any required actions taken by ALTO clients upon successfully receiving an information resource from an ALTO server. Although ALTO clients are suggested to interpret the received ALTO information and adapt application behavior, ALTO clients are not required to do so.
本规范未指明ALTO客户端在成功从ALTO服务器接收信息资源时所需采取的任何操作。虽然建议ALTO客户机解释收到的ALTO信息并调整应用程序行为，但并不要求ALTO客户机这样做。
After receiving an information resource directory, the client can consult it to determine if any of the offered URIs contain the desired information resource. However, an ALTO client MUST NOT assume that the media type returned by the ALTO server for a request to a URI is the media type advertised in the IRD or specified in its request (i.e., the client must still check the Content-Type header). The expectation is that the media type returned should normally be the media type advertised and requested, but, in some cases, it may legitimately not be so.
在收到信息资源目录后，客户机可以查阅该目录，以确定所提供的URI中是否包含所需的信息资源。但是，ALTO客户端不得假设ALTO服务器为URI请求返回的媒体类型是IRD中公布的或在其请求中指定的媒体类型（即，客户端仍必须检查内容类型标头）。我们期望返回的媒体类型通常应该是广告和请求的媒体类型，但在某些情况下，可能并非如此。
In particular, it is possible for an ALTO client to receive an information resource directory from an ALTO server as a response to its request for a specific information resource. In this case, the ALTO client may ignore the response or still parse the response. To indicate that an ALTO client will always check if a response is an information resource directory, the ALTO client can indicate in the "Accept" header of a HTTP request that it can accept information resource directory; see Section 9.2.1 for the media type.
特别地，ALTO客户端可以从ALTO服务器接收信息资源目录，作为对其特定信息资源请求的响应。在这种情况下，ALTO客户端可能会忽略响应或仍然解析响应。为了指示ALTO客户端将始终检查响应是否为信息资源目录，ALTO客户端可以在HTTP请求的“接受”头中指示它可以接受信息资源目录；介质类型见第9.2.1节。
If an ALTO client does not successfully receive a desired information resource from a particular ALTO server (i.e., server response indicates error or there is no response), the client can either choose another server (if one is available) or fall back to a default behavior (e.g., perform peer selection without the use of ALTO information, when used in a peer-to-peer system).
如果ALTO客户端未成功从特定ALTO服务器接收到所需的信息资源（即，服务器响应指示错误或无响应），则客户端可以选择另一台服务器（如果有）或返回默认行为（例如，在对等系统中使用时，在不使用ALTO信息的情况下执行对等选择）。
ALTO server implementations as well as ALTO client implementations MUST support the "https" URI scheme [RFC2818] and Transport Layer Security (TLS) [RFC5246]. See Section 15.1.2 for security considerations and Section 16 for manageability considerations regarding the usage of HTTPS/TLS.
ALTO服务器实现以及ALTO客户端实现必须支持“https”URI方案[RFC2818]和传输层安全性（TLS）[RFC5246]。有关使用HTTPS/TLS的安全注意事项，请参见第15.1.2节，有关可管理性注意事项，请参见第16节。
For deployment scenarios where client authentication is desired, HTTP Digest Authentication MUST be supported. TLS Client Authentication is the preferred mechanism if it is available.
对于需要客户端身份验证的部署场景，必须支持HTTP摘要身份验证。TLS客户端身份验证是首选机制（如果可用）。
An ALTO client can determine the frequency at which ALTO information is refreshed based on information made available via HTTP.
ALTO客户端可以根据通过HTTP提供的信息确定刷新ALTO信息的频率。
This document only details object fields used by this specification. Extensions may include additional fields within JSON objects defined in this document. ALTO implementations MUST ignore unknown fields when processing ALTO messages.
本文档仅详细说明本规范使用的对象字段。扩展可能包括本文档中定义的JSON对象中的其他字段。在处理ALTO消息时，ALTO实现必须忽略未知字段。
Though each type of ALTO server response (i.e., an information resource directory, an individual information resource, or an error message) has its distinct syntax and, hence, its unique media type, they are designed to have a similar structure: a field named "meta" to provide meta definitions, and another field named "data" to contain the data, if needed.
尽管每种类型的ALTO server响应（即信息资源目录、单个信息资源或错误消息）都有其独特的语法，因此也有其独特的媒体类型，但它们的设计结构类似：一个名为“meta”的字段提供元定义，另一个名为“data”的字段包含数据，如果需要的话。
Specifically, this document defines the base type of each ALTO server response as ResponseEntityBase:
具体而言，本文档将每个ALTO服务器响应的基本类型定义为ResponseEntityBase：
object { ResponseMeta meta; } ResponseEntityBase;
object { ResponseMeta meta; } ResponseEntityBase;
with field:
带字段：
meta: meta information pertaining to the response.
meta：与响应相关的元信息。
Meta information is encoded as a map object for flexibility. Specifically, ResponseMeta is defined as:
为了灵活性，元信息被编码为映射对象。具体而言，ResponseMeta的定义如下：
object-map { JSONString -> JSONValue } ResponseMeta;
object-map { JSONString -> JSONValue } ResponseMeta;
The data component of the response encodes the response-specific data. This document derives five types from ResponseEntityBase to add different types of data component: InfoResourceDirectory (Section 9.2.2), InfoResourceNetworkMap (Section 11.2.1.6), InfoResourceCostMap (Section 11.2.3.6), InfoResourceEndpointProperties (Section 11.4.1.6), and InfoResourceEndpointCostMap (Section 11.5.1.6).
响应的数据组件对响应特定的数据进行编码。本文档从ResponseEntityBase派生出五种类型来添加不同类型的数据组件：InfoResourceDirectory（第9.2.2节）、InfoResourceNetworkMap（第11.2.1.6节）、InfoResourceConstMap（第11.2.3.6节）、InfoResourceEndpointProperties（第11.4.1.6节）和InfoResourceEndpointCostMap（第11.5.1.6节）。
If an ALTO server encounters an error while processing a request, the ALTO server SHOULD return additional ALTO-layer information, if it is available, in the form of an ALTO error resource encoded in the HTTP response' entity body. If no ALTO-layer information is available, an ALTO server may omit the ALTO error resource from the response.
如果ALTO服务器在处理请求时遇到错误，ALTO服务器应以HTTP响应“实体体”中编码的ALTO错误资源的形式返回额外的ALTO层信息（如果可用）。如果没有可用的ALTO层信息，ALTO服务器可能会从响应中忽略ALTO错误资源。
With or without additional ALTO-layer error information, an ALTO server MUST set an appropriate HTTP status code. It is important to note that the HTTP status code and ALTO error resource have distinct roles. An ALTO error resource provides detailed information about why a particular request for an ALTO information resource was not successful. The HTTP status code, on the other hand, indicates to HTTP processing elements (e.g., intermediaries and clients) how the response should be treated.
无论是否有其他ALTO层错误信息，ALTO服务器都必须设置适当的HTTP状态代码。需要注意的是，HTTP状态代码和ALTO错误资源具有不同的角色。ALTO error resource提供有关为什么对ALTO信息资源的特定请求未成功的详细信息。另一方面，HTTP状态代码向HTTP处理元素（例如，中介和客户端）指示应如何处理响应。
The media type for an ALTO error response is "application/ alto-error+json".
ALTO错误响应的媒体类型为“应用程序/ALTO错误+json”。
An ALTO error response MUST include a field named "code" in the "meta" field of the response. The value MUST be an ALTO error code, encoded in string, defined in Table 1. Note that the ALTO error codes defined in Table 1 are limited to support the error conditions needed for purposes of this document. Additional status codes may be defined in companion or extension documents.
ALTO错误响应必须在响应的“meta”字段中包含一个名为“code”的字段。该值必须是表1中定义的以字符串编码的ALTO错误代码。注意，表1中定义的ALTO错误代码仅限于支持本文件所需的错误条件。附加状态代码可在配套文件或扩展文件中定义。
+-----------------------+-------------------------------------------+
| ALTO Error Code | Description |
+-----------------------+-------------------------------------------+
| E_SYNTAX | Parsing error in request (including |
| | identifiers) |
| E_MISSING_FIELD | A required JSON field is missing |
| E_INVALID_FIELD_TYPE | The type of the value of a JSON field is |
| | invalid |
| E_INVALID_FIELD_VALUE | The value of a JSON field is invalid |
+-----------------------+-------------------------------------------+
+-----------------------+-------------------------------------------+
| ALTO Error Code | Description |
+-----------------------+-------------------------------------------+
| E_SYNTAX | Parsing error in request (including |
| | identifiers) |
| E_MISSING_FIELD | A required JSON field is missing |
| E_INVALID_FIELD_TYPE | The type of the value of a JSON field is |
| | invalid |
| E_INVALID_FIELD_VALUE | The value of a JSON field is invalid |
+-----------------------+-------------------------------------------+
Table 1: Defined ALTO Error Codes
表1：定义的ALTO错误代码
After an ALTO server receives a request, it needs to verify the syntactic and semantic validity of the request. The following paragraphs in this section are intended to illustrate the usage of the error codes defined above during the verification. An individual implementation may define its message processing in a different order.
ALTO服务器收到请求后，需要验证请求的语法和语义有效性。本节中的以下段落旨在说明验证期间上述错误代码的使用。单个实现可以以不同的顺序定义其消息处理。
In the first step after an ALTO server receives a request, it checks the syntax of the request body (i.e., whether the JSON structure can be parsed), and indicates a syntax error using the error code E_SYNTAX. For an E_SYNTAX error, the ALTO server MAY provide an optional field named "syntax-error" in the "meta" field of the error response. The objective of providing "syntax-error" is to provide technical debugging information to developers, not end users. Hence, it should be a human-readable, free-form text describing the syntax error. If possible, the text should include position information about the syntax error, such as line number and offset within the line. If nothing else, the value of the field named "syntax-error" could include just the position. If a syntax error occurs in a production environment, the ALTO client could inform the end user that there was an error communicating with the ALTO server, and suggest that the user submit the error information, which includes "syntax-error", to the developers.
在ALTO服务器收到请求后的第一步中，它检查请求主体的语法（即，是否可以解析JSON结构），并使用错误代码e_语法指示语法错误。对于E_语法错误，ALTO服务器可以在错误响应的“meta”字段中提供一个名为“SYNTAX error”的可选字段。提供“语法错误”的目的是向开发人员而不是最终用户提供技术调试信息。因此，它应该是描述语法错误的可读、自由格式的文本。如果可能，文本应包括有关语法错误的位置信息，例如行号和行内的偏移量。如果没有其他内容，则名为“syntax error”的字段的值可能只包含位置。如果生产环境中出现语法错误，ALTO客户端可以通知最终用户与ALTO服务器通信时出错，并建议用户向开发人员提交错误信息，其中包括“语法错误”。
A request without syntax errors may still be invalid. An error case is that the request misses a required field. The server indicates such an error using the error code E_MISSING_FIELD. This document defines required fields for Filtered Network Map (Section 11.3.1.3),
没有语法错误的请求可能仍然无效。一种错误情况是请求遗漏了一个必填字段。服务器使用错误代码E_MISSING_字段指示此类错误。本文件定义了过滤网络图所需的字段（第11.3.1.3节），
Filtered Cost Map (Section 11.3.2.3), Endpoint Properties (Section 11.4.1.3), and Endpoint Cost (Section 11.5.1.3) services. For an E_MISSING_FIELD error, the server may include an optional field named "field" in the "meta" field of the error response, to indicate the missing field. "field" should be a JSONString indicating the full path of the missing field. For example, assume that a Filtered Cost Map request (see Section 11.3.2.3) omits the "cost-metric" field. The error response from the ALTO server may specify the value of "field" as "cost-type/cost-metric".
过滤成本图（第11.3.2.3节）、端点属性（第11.4.1.3节）和端点成本（第11.5.1.3节）服务。对于E_MISSING_字段错误，服务器可以在错误响应的“meta”字段中包含一个名为“FIELD”的可选字段，以指示缺少的字段。“field”应该是一个JSONString，指示缺少的字段的完整路径。例如，假设过滤后的成本映射请求（见第11.3.2.3节）忽略了“成本度量”字段。ALTO服务器的错误响应可能会将“字段”的值指定为“成本类型/成本度量”。
A request with the correct fields might use a wrong type for the value of a field. For example, the value of a field could be a JSONString when a JSONNumber is expected. The server indicates such an error using the error code E_INVALID_FIELD_TYPE. The server may include an optional field named "field" in the "meta" field of the response, to indicate the field that contains the wrong type.
具有正确字段的请求可能会使用错误的字段值类型。例如，当需要JSONNumber时，字段的值可以是JSONString。服务器使用错误代码E_INVALID_FIELD_TYPE指示此类错误。服务器可能会在响应的“meta”字段中包含一个名为“field”的可选字段，以指示包含错误类型的字段。
A request with the correct fields and types of values for the fields may specify a wrong value for a field. For example, a Filtered Cost Map request may specify a wrong value for CostMode in the "cost-type" field (Section 11.3.2.3). The server indicates such an error with the error code E_INVALID_FIELD_VALUE. For an E_INVALID_FIELD_VALUE error, the server may include an optional field named "field" in the "meta" field of the response, to indicate the field that contains the wrong value. The server may also include an optional field named "value" in the "meta" field of the response to indicate the wrong value that triggered the error. If the "value" field is specified, the "field" field MUST be specified. The "value" field MUST have a JSONString value. If the invalid value is not a string, the ALTO server MUST convert it to a string. Below are the rules to specify the "value" key:
具有正确字段和字段值类型的请求可能会为字段指定错误的值。例如，过滤后的成本映射请求可能会在“成本类型”字段中为CostMode指定错误的值（第11.3.2.3节）。服务器用错误代码E_INVALID_FIELD_VALUE指示此类错误。对于E_INVALID_FIELD_VALUE错误，服务器可能会在响应的“meta”字段中包含一个名为“FIELD”的可选字段，以指示包含错误值的字段。服务器还可以在响应的“meta”字段中包含一个名为“value”的可选字段，以指示触发错误的错误值。如果指定了“值”字段，则必须指定“字段”。“value”字段必须具有JSONString值。如果无效值不是字符串，ALTO服务器必须将其转换为字符串。以下是指定“值”键的规则：
o If the invalid value is a string, "value" is that string;
o 如果无效值是字符串，“value”是该字符串；
o If the invalid value is a number, "value" must be the invalid number as a string;
o 如果无效值是数字，“value”必须是字符串形式的无效数字；
o If the invalid value is a subfield, the server must set the "field" key to the full path of the field name and "value" to the invalid subfield value, converting it to a string if needed. For example, if the "cost-mode" subfield of the "cost-type" field is an invalid mode "foo", the server should set "value" to "foo", and "field" to "cost-mode/cost-type";
o 如果无效值是子字段，服务器必须将“字段”键设置为字段名的完整路径，将“值”设置为无效子字段值，并根据需要将其转换为字符串。例如，如果“成本类型”字段的“成本模式”子字段是无效模式“foo”，则服务器应将“值”设置为“foo”，将“字段”设置为“成本模式/成本类型”；
o If an element of a JSON array has an invalid value, the server sets "value" to the value of the invalid element, as a string, and "field" to the name of the array. An array element of the wrong type (e.g., a number in what is supposed to be an array of
o 如果JSON数组的元素具有无效值，服务器将“value”作为字符串设置为无效元素的值，并将“field”设置为数组的名称。错误类型的数组元素（例如，应该是数组中的数字）
strings) is an invalid value error, not an invalid type error. The server sets "value" to the string version of the incorrect element, and "field" to the name of the array.
字符串）是无效值错误，而不是无效类型错误。服务器将“value”设置为不正确元素的字符串版本，将“field”设置为数组的名称。
If multiple errors are present in a single request (e.g., a request uses a JSONString when a JSONNumber is expected and a required field is missing), then the ALTO server MUST return exactly one of the detected errors. However, the reported error is implementation defined, since specifying a particular order for message processing encroaches needlessly on implementation techniques.
如果单个请求中存在多个错误（例如，当需要JSONNumber且缺少必填字段时，请求使用JSONString），则ALTO服务器必须仅返回一个检测到的错误。但是，报告的错误是由实现定义的，因为为消息处理指定特定顺序会不必要地侵犯实现技术。
If an ALTO server detects that it cannot handle a request from an ALTO client due to excessive load, technical problems, or system maintenance, it SHOULD do one of the following:
如果ALTO服务器检测到由于负载过大、技术问题或系统维护而无法处理ALTO客户端的请求，则应执行以下操作之一：
o Return an HTTP 503 ("Service Unavailable") status code to the ALTO client. As indicated by [RFC7230], the Retry-After HTTP header may be used to indicate when the ALTO client should retry the request.
o 向ALTO客户端返回HTTP 503（“服务不可用”）状态代码。如[RFC7230]所示，HTTP头后重试可用于指示ALTO客户端何时应重试请求。
o Return an HTTP 307 ("Temporary Redirect") status code indicating an alternate ALTO server that may be able to satisfy the request. Using Temporary Redirect may generate infinite redirection loops. Although [RFC7231] Section 6.4 specifies that an HTTP client SHOULD detect infinite redirection loops, it is more desirable that multiple ALTO servers be configured not to form redirection loops.
o 返回HTTP 307（“临时重定向”）状态代码，指示可能能够满足请求的备用ALTO服务器。使用临时重定向可能会生成无限重定向循环。尽管[RFC7231]第6.4节规定HTTP客户机应检测无限重定向循环，但更可取的是将多个ALTO服务器配置为不形成重定向循环。
The ALTO server MAY also terminate the connection with the ALTO client.
ALTO服务器还可以终止与ALTO客户端的连接。
The particular policy applied by an ALTO server to determine that it cannot service a request is outside of the scope of this document.
ALTO服务器为确定其无法为请求提供服务而应用的特定策略超出了本文档的范围。
As already discussed, an ALTO client starts by retrieving an information resource directory, which specifies the attributes of individual information resources that an ALTO server provides.
如前所述，ALTO客户端首先检索信息资源目录，该目录指定ALTO服务器提供的各个信息资源的属性。
In this document, each information resource has up to five attributes associated with it, including its assigned ID, its response format, its capabilities, its accepted input parameters, and other resources on which it may depend. The function of an information resource directory is to publishes these attributes.
在本文档中，每个信息资源最多有五个相关属性，包括其分配的ID、响应格式、功能、可接受的输入参数以及它可能依赖的其他资源。信息资源目录的功能是发布这些属性。
Each information resource that an ALTO client can request MUST be assigned a resource ID attribute that is unique amongst all information resources in the information resource closure of the client. The resource ID SHOULD remain stable even when the data provided by that resource changes. For example, even though the number of PIDs in an ALTO network map may be adjusted, its resource ID should remain the same. Similarly, if the entries in an ALTO cost map are updated, its resource ID should remain the same. IDs SHOULD NOT be reused for different resources over time.
ALTO客户端可以请求的每个信息资源都必须分配一个资源ID属性，该属性在客户端信息资源闭包中的所有信息资源中是唯一的。即使资源提供的数据发生变化，资源ID也应保持稳定。例如，即使可以调整ALTO网络图中的PID数量，其资源ID也应保持不变。同样，如果ALTO成本图中的条目被更新，则其资源ID应保持不变。随着时间的推移，不应将ID重新用于不同的资源。
ALTO uses media types [RFC2046] to uniquely indicate the data format used to encode the content to be transmitted between an ALTO server and an ALTO client in the HTTP entity body.
ALTO使用媒体类型[RFC2046]唯一地指示用于编码HTTP实体主体中ALTO服务器和ALTO客户端之间传输的内容的数据格式。
The Capabilities attribute of an information resource indicates specific capabilities that the server can provide. For example, if an ALTO server allows an ALTO client to specify cost constraints when the client requests a cost map information resource, then the server advertises the "cost-constraints" capability of the cost map information resource.
信息资源的Capabilities属性表示服务器可以提供的特定功能。例如，如果ALTO服务器允许ALTO客户端在客户端请求成本映射信息资源时指定成本约束，则服务器会公布成本映射信息资源的“成本约束”功能。
An ALTO server may allow an ALTO client to supply input parameters when requesting certain information resources. The associated "accepts" attribute of such an information resource specifies a media type, which indicates how the client specifies the input parameters as contained in the entity body of the HTTP POST request.
ALTO服务器可允许ALTO客户端在请求某些信息资源时提供输入参数。此类信息资源的关联“accepts”属性指定媒体类型，该类型指示客户端如何指定HTTP POST请求的实体体中包含的输入参数。
The information provided in an information resource may use information provided in some other resources (e.g., a cost map uses the PIDs defined in a network map). The "uses" attribute conveys such information.
信息资源中提供的信息可以使用一些其他资源中提供的信息（例如，成本图使用网络图中定义的pid）。“uses”属性传递此类信息。
An ALTO server uses the information resource directory to publish available information resources and their aforementioned attributes. Since resource selection happens after consumption of the information resource directory, the format of the information resource directory is designed to be simple with the intention of future ALTO Protocol versions maintaining backwards compatibility. Future extensions or versions of the ALTO Protocol SHOULD be accomplished by extending existing media types or adding new media types but retaining the same format for the Information Resource Directory.
ALTO服务器使用信息资源目录发布可用信息资源及其上述属性。由于资源选择发生在信息资源目录使用之后，因此信息资源目录的格式设计为简单，目的是使未来的ALTO协议版本保持向后兼容性。ALTO协议的未来扩展或版本应通过扩展现有媒体类型或添加新媒体类型来完成，但信息资源目录应保留相同的格式。
An ALTO server MUST make one information resource directory available via the HTTP GET method to a URI discoverable by an ALTO client. Discovery of this URI is out of scope of this document, but it could be accomplished by manual configuration or by returning the URI of an information resource directory from the ALTO Discovery Protocol [ALTO-SERVER-DISC]. For recommendations on what the URI may look like, see [ALTO-SERVER-DISC].
ALTO服务器必须通过HTTP GET方法使一个信息资源目录可用于ALTO客户端可发现的URI。此URI的发现不在本文档的范围内，但可以通过手动配置或从ALTO发现协议[ALTO-SERVER-DISC]返回信息资源目录的URI来完成。有关URI外观的建议，请参阅[ALTO-SERVER-DISC]。
The media type to indicate an information resource directory is "application/alto-directory+json".
指示信息资源目录的媒体类型为“应用程序/alto目录+json”。
An information resource directory response may include in the "meta" field the "cost-types" field, whose value is of type IRDMetaCostTypes defined below, where CostType is defined in Section 10.7:
信息资源目录响应可在“元”字段中包含“成本类型”字段，其值为下文定义的元成本类型，其中成本类型在第10.7节中定义：
object-map {
JSONString -> CostType;
} IRDMetaCostTypes;
object-map {
JSONString -> CostType;
} IRDMetaCostTypes;
The function of "cost-types" is to assign names to a set of CostTypes that can be used in one or more "resources" entries in the IRD to simplify specification. The names defined in "cost-types" in an IRD are local to the IRD.
“成本类型”的功能是为一组成本类型分配名称，这些成本类型可用于IRD中的一个或多个“资源”条目，以简化规范。IRD中“成本类型”中定义的名称是IRD的本地名称。
For a Root IRD, "meta" MUST include a field named "default-alto-network-map", which value specifies the resource ID of an ALTO network map. When there are multiple network maps defined in an IRD (e.g., with different levels of granularity), the "default-alto-network-map" field provides a guideline to simple clients that use only one network map.
对于根IRD，“meta”必须包含一个名为“default alto network map”的字段，该值指定alto network map的资源ID。当IRD中定义了多个网络映射（例如，具有不同的粒度级别）时，“默认alto网络映射”字段为仅使用一个网络映射的简单客户端提供指导。
The data component of an information resource directory response is named "resources", which is a JSON object of type IRDResourceEntries:
信息资源目录响应的数据组件名为“resources”，这是一个IRDROURCEENTERIERS类型的JSON对象：
object {
IRDResourceEntries resources;
} InfoResourceDirectory : ResponseEntityBase;
object {
IRDResourceEntries resources;
} InfoResourceDirectory : ResponseEntityBase;
object-map {
ResourceID -> IRDResourceEntry;
} IRDResourceEntries;
object-map {
ResourceID -> IRDResourceEntry;
} IRDResourceEntries;
object {
JSONString uri;
JSONString media-type;
[JSONString accepts;]
[Capabilities capabilities;]
[ResourceID uses<0..*>;]
} IRDResourceEntry;
object {
JSONString uri;
JSONString media-type;
[JSONString accepts;]
[Capabilities capabilities;]
[ResourceID uses<0..*>;]
} IRDResourceEntry;
object {
...
} Capabilities;
object {
...
} Capabilities;
An IRDResourceEntries object is a dictionary map keyed by ResourceIDs, where ResourceID is defined in Section 10.2. The value of each entry specifies:
IRDResourceEntries对象是由ResourceID设置关键字的字典映射，其中ResourceID在第10.2节中定义。每个条目的值指定：
uri: A URI at which the ALTO server provides one or more information resources, or an information resource directory indicating additional information resources. URIs can be relative to the URI of the IRD and MUST be resolved according to Section 5 of [RFC3986].
uri：ALTO服务器提供一个或多个信息资源的uri，或指示其他信息资源的信息资源目录。URI可以与IRD的URI相关，必须根据[RFC3986]第5节进行解析。
media-type: The media type of the information resource (see Section 9.1.2) available via GET or POST requests to the corresponding URI. A value of "application/ alto-directory+json" indicates that the response for a
媒体类型：信息资源的媒体类型（见第9.1.2节），可通过对相应URI的GET或POST请求获得。值“application/alto directory+json”表示
request to the URI will be an information resource directory defining additional information resources in the information resource closure.
对URI的请求将是一个信息资源目录，定义信息资源闭包中的其他信息资源。
accepts: The media type of input parameters (see Section 9.1.4) accepted by POST requests to the corresponding URI. If this field is not present, it MUST be assumed to be empty.
accepts：输入参数的媒体类型（见第9.1.4节），由对相应URI的POST请求接受。如果此字段不存在，则必须假定为空。
capabilities: A JSON object enumerating capabilities of an ALTO server in providing the information resource at the corresponding URI and information resources discoverable via the URI. If this field is not present, it MUST be assumed to be an empty object. If a capability for one of the offered information resources is not explicitly listed here, an ALTO client may either issue an OPTIONS HTTP request to the corresponding URI to determine if the capability is supported or assume its default value documented in this specification or an extension document describing the capability.
capabilities：一个JSON对象，枚举ALTO服务器在相应URI处提供信息资源以及可通过URI发现的信息资源的能力。如果此字段不存在，则必须假定它是空对象。如果此处未明确列出所提供信息资源之一的功能，ALTO客户端可能会向相应的URI发出选项HTTP请求，以确定该功能是否受支持，或假定其默认值记录在本规范或描述该功能的扩展文档中。
uses: A list of resource IDs, defined in the same IRD, that define the resources on which this resource directly depends. An ALTO server SHOULD include in this list any resources that the ALTO client would need to retrieve in order to interpret the contents of this resource. For example, an ALTO cost map resource should include in this list the network map on which it depends. ALTO clients may wish to consult this list in order to pre-fetch necessary resources.
用法：在同一IRD中定义的资源ID列表，用于定义此资源直接依赖的资源。ALTO服务器应在此列表中包含ALTO客户端为解释此资源的内容而需要检索的任何资源。例如，ALTO cost map资源应在此列表中包含其所依赖的网络地图。ALTO客户可能希望查阅此列表，以便预先获取必要的资源。
If an entry has an empty list for "accepts", then the corresponding URI MUST support GET requests. If an entry has a non-empty "accepts", then the corresponding URI MUST support POST requests. If an ALTO server wishes to support both GET and POST on a single URI, it MUST specify two entries in the information resource directory.
如果条目的“accepts”列表为空，则相应的URI必须支持GET请求。如果条目具有非空的“accepts”，则相应的URI必须支持POST请求。如果ALTO服务器希望在单个URI上同时支持GET和POST，则必须在信息资源目录中指定两个条目。
The following is an example information resource directory returned by an ALTO server to an ALTO client. Assume it is the Root IRD of the client.
以下是ALTO服务器返回给ALTO客户端的示例信息资源目录。假设它是客户端的根IRD。
GET /directory HTTP/1.1
Host: alto.example.com
Accept: application/alto-directory+json,application/alto-error+json
GET /directory HTTP/1.1
Host: alto.example.com
Accept: application/alto-directory+json,application/alto-error+json
HTTP/1.1 200 OK
Content-Length: 2333
Content-Type: application/alto-directory+json
HTTP/1.1 200 OK
Content-Length: 2333
Content-Type: application/alto-directory+json
{
"meta" : {
"cost-types": {
"num-routing": {
"cost-mode" : "numerical",
"cost-metric": "routingcost",
"description": "My default"
},
"num-hop": {
"cost-mode" : "numerical",
"cost-metric": "hopcount"
},
"ord-routing": {
"cost-mode" : "ordinal",
"cost-metric": "routingcost"
},
"ord-hop": {
"cost-mode" : "ordinal",
"cost-metric": "hopcount"
}
},
"default-alto-network-map" : "my-default-network-map"
},
"resources" : {
"my-default-network-map" : {
"uri" : "http://alto.example.com/networkmap",
"media-type" : "application/alto-networkmap+json"
},
"numerical-routing-cost-map" : {
"uri" : "http://alto.example.com/costmap/num/routingcost",
"media-type" : "application/alto-costmap+json",
"capabilities" : {
"cost-type-names" : [ "num-routing" ]
},
"uses": [ "my-default-network-map" ]
},
"numerical-hopcount-cost-map" : {
"uri" : "http://alto.example.com/costmap/num/hopcount",
"media-type" : "application/alto-costmap+json",
"capabilities" : {
{
"meta" : {
"cost-types": {
"num-routing": {
"cost-mode" : "numerical",
"cost-metric": "routingcost",
"description": "My default"
},
"num-hop": {
"cost-mode" : "numerical",
"cost-metric": "hopcount"
},
"ord-routing": {
"cost-mode" : "ordinal",
"cost-metric": "routingcost"
},
"ord-hop": {
"cost-mode" : "ordinal",
"cost-metric": "hopcount"
}
},
"default-alto-network-map" : "my-default-network-map"
},
"resources" : {
"my-default-network-map" : {
"uri" : "http://alto.example.com/networkmap",
"media-type" : "application/alto-networkmap+json"
},
"numerical-routing-cost-map" : {
"uri" : "http://alto.example.com/costmap/num/routingcost",
"media-type" : "application/alto-costmap+json",
"capabilities" : {
"cost-type-names" : [ "num-routing" ]
},
"uses": [ "my-default-network-map" ]
},
"numerical-hopcount-cost-map" : {
"uri" : "http://alto.example.com/costmap/num/hopcount",
"media-type" : "application/alto-costmap+json",
"capabilities" : {
"cost-type-names" : [ "num-hop" ]
},
"uses": [ "my-default-network-map" ]
},
"custom-maps-resources" : {
"uri" : "http://custom.alto.example.com/maps",
"media-type" : "application/alto-directory+json"
},
"endpoint-property" : {
"uri" : "http://alto.example.com/endpointprop/lookup",
"media-type" : "application/alto-endpointprop+json",
"accepts" : "application/alto-endpointpropparams+json",
"capabilities" : {
"prop-types" : [ "my-default-network-map.pid",
"priv:ietf-example-prop" ]
},
},
"endpoint-cost" : {
"uri" : "http://alto.example.com/endpointcost/lookup",
"media-type" : "application/alto-endpointcost+json",
"accepts" : "application/alto-endpointcostparams+json",
"capabilities" : {
"cost-constraints" : true,
"cost-type-names" : [ "num-routing", "num-hop",
"ord-routing", "ord-hop"]
}
}
}
}
"cost-type-names" : [ "num-hop" ]
},
"uses": [ "my-default-network-map" ]
},
"custom-maps-resources" : {
"uri" : "http://custom.alto.example.com/maps",
"media-type" : "application/alto-directory+json"
},
"endpoint-property" : {
"uri" : "http://alto.example.com/endpointprop/lookup",
"media-type" : "application/alto-endpointprop+json",
"accepts" : "application/alto-endpointpropparams+json",
"capabilities" : {
"prop-types" : [ "my-default-network-map.pid",
"priv:ietf-example-prop" ]
},
},
"endpoint-cost" : {
"uri" : "http://alto.example.com/endpointcost/lookup",
"media-type" : "application/alto-endpointcost+json",
"accepts" : "application/alto-endpointcostparams+json",
"capabilities" : {
"cost-constraints" : true,
"cost-type-names" : [ "num-routing", "num-hop",
"ord-routing", "ord-hop"]
}
}
}
}
Specifically, the "cost-types" field of "meta" of the example IRD defines names for four cost types in this IRD. For example, "num-routing" in the example is the name that refers to a cost type with cost mode being "numerical" and cost metric being "routingcost". This name is used in the second entry of "resources", which defines a cost map. In particular, the "cost-type-names" of its "capabilities" specifies that this resource supports a cost type named as "num-routing". The ALTO client looks up the name "num-routing" in "cost-types" of the IRD to obtain the cost type named as "num-routing". The last entry of "resources" uses all four names defined in "cost-types".
具体而言，示例IRD的“元”的“成本类型”字段定义了该IRD中四种成本类型的名称。例如，示例中的“num routing”是指成本模式为“数字”且成本度量为“routingcost”的成本类型的名称。此名称用于“资源”的第二个条目，该条目定义了成本图。特别是，其“功能”的“成本类型名称”指定此资源支持名为“num路由”的成本类型。ALTO客户端在IRD的“成本类型”中查找名称“num routing”，以获得名为“num routing”的成本类型。“资源”的最后一项使用“成本类型”中定义的所有四个名称。
Another field defined in "meta" of the example IRD is "default-alto-network-map", which has value "my-default-network-map", which is the resource ID of an ALTO network map that will be defined in "resources".
示例IRD的“meta”中定义的另一个字段是“default alto network map”，其值为“my default network map”，这是将在“resources”中定义的alto network map的资源ID。
The "resources" field of the example IRD defines six information resources. For example, the second entry, which is assigned a resource ID "numerical-routing-cost-map", provides a cost map, as indicated by the media-type "application/alto-costmap+json". The cost map is based on the network map defined with resource ID "my-default-network-map". As another example, the last entry, which is assigned resource ID "endpoint-cost", provides the Endpoint Cost Service, which is indicated by the media-type "application/ alto-endpointcost+json". An ALTO client should use uri "http://alto.example.com/endpointcost/lookup" to access the service.
示例IRD的“资源”字段定义了六种信息资源。例如，第二个条目被分配了一个资源ID“数字路由成本图”，它提供了一个成本图，如媒体类型“application/alto costmap+json”所示。成本图基于使用资源ID“我的默认网络图”定义的网络图。作为另一个示例，最后一个条目被分配了资源ID“endpoint cost”，它提供端点成本服务，该服务由媒体类型“application/alto endpointcost+json”表示。ALTO客户端应使用uri“http://alto.example.com/endpointcost/lookup“访问该服务。
The ALTO client should format its request body to be the "application/alto-endpointcostparams+json" media type, as specified by the "accepts" attribute of the information resource. The "cost-type-names" field of the "capabilities" attribute of the information resource includes four defined cost types specified in the "cost-types" field of "meta" of the IRD. Hence, an ALTO client can verify that the Endpoint Cost information resource supports both cost metrics "routingcost" and "hopcount", each available for both "numerical" and "ordinal" cost modes. When requesting the information resource, an ALTO client can specify cost constraints, as indicated by the "cost-constraints" field of the "capabilities" attribute.
ALTO客户端应将其请求正文格式化为“application/ALTO endpointcostparams+json”媒体类型，如信息资源的“accepts”属性所指定。信息资源“能力”属性的“成本类型名称”字段包括IRD“元”的“成本类型”字段中指定的四种定义成本类型。因此，ALTO客户端可以验证端点成本信息资源是否支持成本度量“routingcost”和“hopcount”，每种成本度量都可用于“数字”和“顺序”成本模式。当请求信息资源时，ALTO客户端可以指定成本约束，如“能力”属性的“成本约束”字段所示。
ALTO IRDs provide the flexibility to define a set of information resources that are provided by ALTO servers running in multiple domains. Consider the preceding example. Assume that the ALTO server running at alto.example.com wants to delegate some information resources to a separate subdomain: "custom.alto.example.com". In particular, assume that the maps available via this subdomain are filtered network maps, filtered cost maps, and some pre-generated maps for the "hopcount" and "routingcost" cost metrics in the "ordinal" cost mode. The fourth entry of "resources" in the preceding example IRD implements the delegation. The entry has a media-type of "application/alto-directory+json", and an ALTO client can discover the information resources available at "custom.alto.example.com" if its request to "http://custom.alto.example.com/maps" is successful:
ALTO IRD提供了定义一组信息资源的灵活性，这些信息资源由运行在多个域中的ALTO服务器提供。考虑前面的例子。假设运行在ALTO.example.com上的ALTO服务器希望将一些信息资源委托给一个单独的子域：“custom.ALTO.example.com”。特别是，假设通过该子域可用的映射是过滤的网络映射、过滤的成本映射，以及“顺序”成本模式下“hopcount”和“routingcost”成本度量的一些预生成映射。上例IRD中的第四个“资源”条目实现委托。该条目的媒体类型为“application/alto directory+json”，如果alto客户端请求http://custom.alto.example.com/maps“成功：
GET /maps HTTP/1.1
Host: custom.alto.example.com
Accept: application/alto-directory+json,application/alto-error+json
GET /maps HTTP/1.1
Host: custom.alto.example.com
Accept: application/alto-directory+json,application/alto-error+json
HTTP/1.1 200 OK
Content-Length: 1900
Content-Type: application/alto-directory+json
HTTP/1.1 200 OK
Content-Length: 1900
Content-Type: application/alto-directory+json
{
"meta" : {
"cost-types": {
"num-routing": {
"cost-mode" : "numerical",
"cost-metric": "routingcost",
"description": "My default"
},
"num-hop": {
"cost-mode" : "numerical",
"cost-metric": "hopcount"
},
"ord-routing": {
"cost-mode" : "ordinal",
"cost-metric": "routingcost"
},
"ord-hop": {
"cost-mode" : "ordinal",
"cost-metric": "hopcount"
}
}
},
"resources" : {
"filtered-network-map" : {
"uri" : "http://custom.alto.example.com/networkmap/filtered",
"media-type" : "application/alto-networkmap+json",
"accepts" : "application/alto-networkmapfilter+json",
"uses": [ "my-default-network-map" ]
},
"filtered-cost-map" : {
"uri" : "http://custom.alto.example.com/costmap/filtered",
"media-type" : "application/alto-costmap+json",
"accepts" : "application/alto-costmapfilter+json",
"capabilities" : {
"cost-constraints" : true,
"cost-type-names" : [ "num-routing", "num-hop",
"ord-routing", "ord-hop" ]
},
"uses": [ "my-default-network-map" ]
},
{
"meta" : {
"cost-types": {
"num-routing": {
"cost-mode" : "numerical",
"cost-metric": "routingcost",
"description": "My default"
},
"num-hop": {
"cost-mode" : "numerical",
"cost-metric": "hopcount"
},
"ord-routing": {
"cost-mode" : "ordinal",
"cost-metric": "routingcost"
},
"ord-hop": {
"cost-mode" : "ordinal",
"cost-metric": "hopcount"
}
}
},
"resources" : {
"filtered-network-map" : {
"uri" : "http://custom.alto.example.com/networkmap/filtered",
"media-type" : "application/alto-networkmap+json",
"accepts" : "application/alto-networkmapfilter+json",
"uses": [ "my-default-network-map" ]
},
"filtered-cost-map" : {
"uri" : "http://custom.alto.example.com/costmap/filtered",
"media-type" : "application/alto-costmap+json",
"accepts" : "application/alto-costmapfilter+json",
"capabilities" : {
"cost-constraints" : true,
"cost-type-names" : [ "num-routing", "num-hop",
"ord-routing", "ord-hop" ]
},
"uses": [ "my-default-network-map" ]
},
"ordinal-routing-cost-map" : {
"uri" : "http://custom.alto.example.com/ord/routingcost",
"media-type" : "application/alto-costmap+json",
"capabilities" : {
"cost-type-names" : [ "ord-routing" ]
},
"uses": [ "my-default-network-map" ]
},
"ordinal-hopcount-cost-map" : {
"uri" : "http://custom.alto.example.com/ord/hopcount",
"media-type" : "application/alto-costmap+json",
"capabilities" : {
"cost-type-names" : [ "ord-hop" ]
},
"uses": [ "my-default-network-map" ]
}
}
}
"ordinal-routing-cost-map" : {
"uri" : "http://custom.alto.example.com/ord/routingcost",
"media-type" : "application/alto-costmap+json",
"capabilities" : {
"cost-type-names" : [ "ord-routing" ]
},
"uses": [ "my-default-network-map" ]
},
"ordinal-hopcount-cost-map" : {
"uri" : "http://custom.alto.example.com/ord/hopcount",
"media-type" : "application/alto-costmap+json",
"capabilities" : {
"cost-type-names" : [ "ord-hop" ]
},
"uses": [ "my-default-network-map" ]
}
}
}
Note that the subdomain does not define any network maps, and uses the network map with resource ID "my-default-network-map" defined in the Root IRD.
请注意，子域不定义任何网络映射，而是使用根IRD中定义的资源ID为“我的默认网络映射”的网络映射。
This document specifies no requirements or constraints on ALTO clients with regard to how they process an information resource directory to identify the URI corresponding to a desired information resource. However, some advice is provided for implementers.
本文档对ALTO客户端如何处理信息资源目录以识别与所需信息资源对应的URI没有规定任何要求或约束。但是，为实现者提供了一些建议。
It is possible that multiple entries in the directory match a desired information resource. For instance, in the example in Section 9.2.3, a full cost map with the "numerical" cost mode and the "routingcost" cost metric could be retrieved via a GET request to "http://alto.example.com/costmap/num/routingcost" or via a POST request to "http://custom.alto.example.com/costmap/filtered".
目录中的多个条目可能与所需的信息资源相匹配。例如，在第9.2.3节中的示例中，可以通过GET请求检索具有“数字”成本模式和“路由成本”成本度量的完整成本映射http://alto.example.com/costmap/num/routingcost“或通过POST请求发送到”http://custom.alto.example.com/costmap/filtered".
In general, it is preferred for ALTO clients to use GET requests where appropriate, since it is more likely for responses to be cacheable. However, an ALTO client may need to use POST, for example, to get ALTO costs or properties that are for a restricted set of PIDs or endpoints or to update cached information previously acquired via GET requests.
一般来说，ALTO客户端最好在适当的地方使用GET请求，因为响应更有可能是可缓存的。但是，ALTO客户端可能需要使用POST，例如，获取一组受限PID或端点的ALTO成本或属性，或者更新先前通过get请求获取的缓存信息。
This document indicates that an ALTO server may or may not provide the information resources specified in the Map-Filtering Service. If these resources are not provided, it is indicated to an ALTO client by the absence of a network map or cost map with any media types listed under "accepts".
本文档说明ALTO服务器可能提供也可能不提供地图筛选服务中指定的信息资源。如果未提供这些资源，则向ALTO客户端表明，没有“接受”下列出的任何媒体类型的网络图或成本图。
This section details the format of basic data types.
本节详细介绍基本数据类型的格式。
A PID Name is encoded as a JSON string. The string MUST be no more than 64 characters, and it MUST NOT contain characters other than US-ASCII alphanumeric characters (U+0030-U+0039, U+0041-U+005A, and U+0061-U+007A), the hyphen ('-', U+002D), the colon (':', U+003A), the at sign ('@', code point U+0040), the low line ('_', U+005F), or the '.' separator (U+002E). The '.' separator is reserved for future use and MUST NOT be used unless specifically indicated in this document, or an extension document.
PID名称编码为JSON字符串。字符串不得超过64个字符，且不得包含除US-ASCII字母数字字符（U+0030-U+0039、U+0041-U+005A和U+0061-U+007A）、连字符（“-”、U+002D）、冒号（“：”、U+003A）、at符号（“@”、代码点U+0040）、低端（“、U+005F）或“.”分隔符（U+002E）以外的字符。“.”分隔符保留供将来使用，除非本文档或扩展文档中明确说明，否则不得使用。
The type PIDName is used in this document to indicate a string of this format.
此文档中使用类型PIDName来指示此格式的字符串。
A resource ID uniquely identifies a particular resource (e.g., an ALTO network map) within an ALTO server (see Section 9.2).
资源ID唯一标识ALTO服务器内的特定资源（例如ALTO网络地图）（参见第9.2节）。
A resource ID is encoded as a JSON string with the same format as that of the type PIDName.
资源ID被编码为JSON字符串，格式与PIDName类型相同。
The type ResourceID is used in this document to indicate a string of this format.
此文档中使用ResourceID类型来指示此格式的字符串。
A version tag is defined as:
版本标记定义为：
object {
ResourceID resource-id;
JSONString tag;
} VersionTag;
object {
ResourceID resource-id;
JSONString tag;
} VersionTag;
As described in Section 6.3, the "resource-id" field provides the resource ID of a resource (e.g., a network map) defined in the information resource directory, and "tag" provides an identifier string.
如第6.3节所述，“资源id”字段提供信息资源目录中定义的资源（如网络地图）的资源id，“标签”提供标识符字符串。
Two version tags are equal if and only if both the "resource-id" fields are byte-for-byte equal and the "tag" fields are byte-for-byte equal.
两个版本标记相等当且仅当“资源id”字段是逐字节相等且“标记”字段是逐字节相等时。
A string representing the "tag" field MUST be no more than 64 characters, and it MUST NOT contain any character below U+0021 or above U+007E. It is RECOMMENDED that the "tag" string have a low collision probability with other tags. One suggested mechanism is to compute it using a hash of the data contents of the resource.
表示“标记”字段的字符串不得超过64个字符，且不得包含U+0021以下或U+007E以上的任何字符。建议“标签”字符串与其他标签的碰撞概率较低。一种建议的机制是使用资源的数据内容的散列来计算它。
This section defines formats used to encode addresses for endpoints. In a case that multiple textual representations encode the same endpoint address or prefix (within the guidelines outlined in this document), the ALTO Protocol does not require ALTO clients or ALTO servers to use a particular textual representation, nor does it require that ALTO servers reply to requests using the same textual representation used by requesting ALTO clients. ALTO clients must be cognizant of this.
本节定义用于对端点地址进行编码的格式。如果多个文本表示编码相同的端点地址或前缀（在本文档概述的指导原则范围内），ALTO协议不要求ALTO客户端或ALTO服务器使用特定的文本表示，它也不要求ALTO服务器使用与请求ALTO客户端相同的文本表示来回复请求。ALTO客户必须意识到这一点。
When an endpoint address is used, an ALTO implementation must be able to determine its type. For this purpose, the ALTO Protocol allows endpoint addresses to also explicitly indicate their types. This document refers to such addresses as "Typed Endpoint Addresses".
使用端点地址时，ALTO实现必须能够确定其类型。为此，ALTO协议允许端点地址也显式指示其类型。本文档将此类地址称为“类型化端点地址”。
Typed endpoint addresses are encoded as strings of the format AddressType:EndpointAddr, with the ':' character as a separator. The type TypedEndpointAddr is used to indicate a string of this format.
类型化端点地址编码为AddressType:EndpointAddr格式的字符串，并以“：”字符作为分隔符。TypedEndpointAddr类型用于指示此格式的字符串。
The AddressType component of TypedEndPointAddr is defined as a string consisting of only US-ASCII alphanumeric characters (U+0030-U+0039, U+0041-U+005A, and U+0061-U+007A). The type AddressType is used in this document to indicate a string of this format.
TypedEndPointAddr的AddressType组件定义为仅由US-ASCII字母数字字符（U+0030-U+0039、U+0041-U+005A和U+0061-U+007A）组成的字符串。类型AddressType在本文档中用于指示此格式的字符串。
This document defines two values for AddressType: "ipv4" to refer to IPv4 addresses and "ipv6" to refer to IPv6 addresses. All AddressType identifiers appearing in an HTTP request or response with an "application/alto-*" media type MUST be registered in the "ALTO Address Type Registry" (see Section 14.4).
本文档为AddressType定义了两个值：“ipv4”表示ipv4地址，“ipv6”表示ipv6地址。HTTP请求或响应中出现的具有“应用程序/alto-*”媒体类型的所有地址类型标识符必须在“alto地址类型注册表”中注册（见第14.4节）。
The EndpointAddr component of TypedEndPointAddr is also encoded as a string. The exact characters and format depend on AddressType. This document defines EndpointAddr when AddressType is "ipv4" or "ipv6".
TypedEndPointAddr的EndpointAddr组件也被编码为字符串。确切的字符和格式取决于AddressType。当AddressType为“ipv4”或“ipv6”时，本文档定义EndpointAddr。
IPv4 Endpoint Addresses are encoded as specified by the IPv4address rule in Section 3.2.2 of [RFC3986].
IPv4端点地址按照[RFC3986]第3.2.2节中的IPv4address规则进行编码。
IPv6 endpoint addresses are encoded as specified in Section 4 of [RFC5952].
IPv6端点地址按照[RFC5952]第4节的规定进行编码。
For efficiency, it is useful to denote a set of endpoint addresses using a special notation (if one exists). This specification makes use of the prefix notations for both IPv4 and IPv6 for this purpose.
为了提高效率，使用特殊符号（如果存在）表示一组端点地址是很有用的。本规范为此目的同时使用IPv4和IPv6的前缀符号。
Endpoint prefixes are encoded as strings. The exact characters and format depend on the type of endpoint address.
端点前缀编码为字符串。确切的字符和格式取决于端点地址的类型。
The type EndpointPrefix is used in this document to indicate a string of this format.
此文档中使用EndpointPrefix类型来指示此格式的字符串。
IPv4 endpoint prefixes are encoded as specified in Section 3.1 of [RFC4632].
IPv4端点前缀按照[RFC4632]第3.1节的规定进行编码。
IPv6 endpoint prefixes are encoded as specified in Section 7 of [RFC5952].
IPv6端点前缀按照[RFC5952]第7节的规定进行编码。
The ALTO Protocol includes messages that specify potentially large sets of endpoint addresses. Endpoint address groups provide a more efficient way to encode such sets, even when the set contains endpoint addresses of different types.
ALTO协议包含指定可能大量端点地址集的消息。端点地址组提供了一种更有效的方式来编码这些集合，即使集合包含不同类型的端点地址。
An endpoint address group is defined as:
端点地址组定义为：
object-map {
AddressType -> EndpointPrefix<0..*>;
} EndpointAddrGroup;
object-map {
AddressType -> EndpointPrefix<0..*>;
} EndpointAddrGroup;
In particular, an endpoint address group is a JSON object representing a map, where each key is the string corresponding to an address type, and the corresponding value is an array listing prefixes of addresses of that type.
特别是，端点地址组是表示映射的JSON对象，其中每个键是对应于地址类型的字符串，对应的值是列出该类型地址前缀的数组。
The following is an example with both IPv4 and IPv6 endpoint addresses:
以下是IPv4和IPv6端点地址的示例：
{
"ipv4": [
"192.0.2.0/24",
"198.51.100.0/25"
],
"ipv6": [
"2001:db8:0:1::/64",
"2001:db8:0:2::/64"
]
}
{
"ipv4": [
"192.0.2.0/24",
"198.51.100.0/25"
],
"ipv6": [
"2001:db8:0:1::/64",
"2001:db8:0:2::/64"
]
}
A cost mode is encoded as a string. The string MUST have a value of either "numerical" or "ordinal".
成本模式编码为字符串。字符串的值必须为“数字”或“序号”。
The type CostMode is used in this document to indicate a string of this format.
此文档中使用CostMode类型来指示此格式的字符串。
A cost metric is encoded as a string. The string MUST be no more than 32 characters, and it MUST NOT contain characters other than US-ASCII alphanumeric characters (U+0030-U+0039, U+0041-U+005A, and U+0061-U+007A), the hyphen ('-', U+002D), the colon (':', U+003A), the low line ('_', U+005F), or the '.' separator (U+002E). The '.' separator is reserved for future use and MUST NOT be used unless specifically indicated by a companion or extension document.
成本指标编码为字符串。字符串不得超过32个字符，且不得包含除US-ASCII字母数字字符（U+0030-U+0039、U+0041-U+005A和U+0061-U+007A）、连字符（“-”、U+002D）、冒号（“：”、U+003A）、低端（“，”U+005F）或“.”分隔符（U+002E）以外的字符。“.”分隔符保留供将来使用，除非附带文档或扩展文档中明确指出，否则不得使用。
Identifiers prefixed with "priv:" are reserved for Private Use [RFC5226] without a need to register with IANA. All other identifiers that appear in an HTTP request or response with an "application/alto-*" media type and indicate cost metrics MUST be registered in the "ALTO Cost Metric Registry" Section 14.2. For an identifier with the "priv:" prefix, an additional string (e.g., company identifier or random string) MUST follow (i.e., "priv:" only is not a valid identifier) to reduce potential collisions.
前缀为“priv:”的标识符保留供私人使用[RFC5226]，无需向IANA注册。所有出现在HTTP请求或响应中且具有“应用程序/alto-*”媒体类型并指示成本指标的其他标识符必须在“alto成本指标注册表”第14.2节中注册。对于前缀为“priv:”的标识符，必须在其后附加一个字符串（例如，公司标识符或随机字符串）（即，“priv:”only不是有效标识符）以减少潜在冲突。
The type CostMetric is used in this document to indicate a string of this format.
在本文档中，CostMetric类型用于指示此格式的字符串。
The combination of CostMetric and CostMode defines the type CostType:
CostMetric和CostMode的组合定义了类型CostType：
object {
CostMetric cost-metric;
CostMode cost-mode;
[JSONString description;]
} CostType;
object {
CostMetric cost-metric;
CostMode cost-mode;
[JSONString description;]
} CostType;
The "description" field, if present, MUST provide a string value with a human-readable description of the cost-metric and cost-mode. An ALTO client MAY present this string to a developer, as part of a discovery process; however, the field is not intended to be interpreted by an ALTO client.
“description”字段（如果存在）必须提供一个字符串值，该字符串值具有成本度量和成本模式的可读描述。作为发现过程的一部分，ALTO客户端可以向开发人员呈现该字符串；但是，该字段不打算由ALTO客户机解释。
This document distinguishes two types of endpoint properties: resource-specific endpoint properties and global endpoint properties. The type EndpointPropertyType is used in this document to indicate a string denoting either a resource-specific endpoint property or a global endpoint property.
本文档区分两种类型的端点属性：特定于资源的端点属性和全局端点属性。此文档中使用EndpointPropertyType类型来指示表示特定于资源的端点属性或全局端点属性的字符串。
The name of resource-specific endpoint property MUST follow this format: a resource ID, followed by the '.' separator (U+002E), followed by a name obeying the same rules as for global endpoint property names (Section 10.8.2).
特定于资源的终结点属性的名称必须遵循以下格式：资源ID，后跟“.”分隔符（U+002E），后跟与全局终结点属性名称遵循相同规则的名称（第10.8.2节）。
This document defines only one resource-specific endpoint property: pid. An example is "my-default-networkmap.pid".
此文档仅定义一个特定于资源的端点属性：pid。例如“我的默认networkmap.pid”。
A global endpoint property is encoded as a string. The string MUST be no more than 32 characters, and it MUST NOT contain characters other than US-ASCII alphanumeric characters (U+0030-U+0039, U+0041-U+005A, and U+0061-U+007A), the hyphen ('-', U+002D), the colon (':', U+003A), or the low line ('_', U+005F). Note that the '.' separator is not allowed so that there is no ambiguity on whether an endpoint property is global or resource specific.
全局终结点属性编码为字符串。字符串不得超过32个字符，且不得包含除US-ASCII字母数字字符（U+0030-U+0039、U+0041-U+005A和U+0061-U+007A）、连字符（“-”、U+002D）、冒号（“：”、U+003A）或低端（“，”U+005F）以外的字符。请注意，不允许使用“.”分隔符，因此端点属性是全局的还是特定于资源的没有歧义。
Identifiers prefixed with "priv:" are reserved for Private Use [RFC5226] without a need to register with IANA. All other identifiers for endpoint properties appearing in an HTTP request or response with an "application/alto-*" media type MUST be registered in the "ALTO Endpoint Property Type Registry" Section 14.3. For an endpoint property identifier with the "priv:" prefix, an additional string (e.g., company identifier or random string) MUST follow (i.e., "priv:" only is not a valid endpoint property identifier) to reduce potential collisions.
前缀为“priv:”的标识符保留供私人使用[RFC5226]，无需向IANA注册。具有“应用程序/alto-*”媒体类型的HTTP请求或响应中出现的端点属性的所有其他标识符必须在“alto端点属性类型注册表”第14.3节中注册。对于前缀为“priv:”的端点属性标识符，必须在其后添加一个字符串（例如，公司标识符或随机字符串）（即，“priv:”only不是有效的端点属性标识符）以减少潜在冲突。
This section documents the individual information resources defined to provide the services defined in this document.
本节记录了为提供本文档中定义的服务而定义的各个信息资源。
For the "meta" field of the response to an individual information resource, this document defines two generic fields: the "vtag" field, which provides the version tag (see Section 10.3) of the current information resource, and the "dependent-vtags" field, which is an array of version tags, to indicate the version tags of the resources on which this resource depends.
对于单个信息资源响应的“meta”字段，本文档定义了两个通用字段：“vtag”字段，提供当前信息资源的版本标签（见第10.3节），以及“dependent vtags”字段，它是一个版本标签数组，指示此资源所依赖的资源的版本标记。
The Map Service provides batch information to ALTO clients in the form of two types of maps: ALTO network maps and ALTO cost maps.
地图服务以两种地图的形式向ALTO客户端提供批量信息：ALTO网络地图和ALTO成本地图。
An ALTO network map information resource defines a set of PIDs, and for each PID, lists the network locations (endpoints) within the PID. An ALTO server MUST provide at least one network map.
ALTO网络地图信息资源定义一组PID，并为每个PID列出PID中的网络位置（端点）。ALTO服务器必须至少提供一个网络映射。
The media type of ALTO network maps is "application/alto-networkmap+json".
ALTO网络地图的媒体类型为“应用程序/ALTO网络地图+json”。
An ALTO network map resource is requested using the HTTP GET method.
使用HTTP GET方法请求ALTO网络映射资源。
None.
没有一个
None.
没有一个
None.
没有一个
The "meta" field of an ALTO network map response MUST include the "vtag" field, which provides the version tag of the retrieved network map.
ALTO网络地图响应的“meta”字段必须包括“vtag”字段，该字段提供检索到的网络地图的版本标签。
The data component of an ALTO network map response is named "network-map", which is a JSON object of type NetworkMapData:
ALTO network map响应的数据组件名为“network map”，它是NetworkMapData类型的JSON对象：
object {
NetworkMapData network-map;
} InfoResourceNetworkMap : ResponseEntityBase;
object {
NetworkMapData network-map;
} InfoResourceNetworkMap : ResponseEntityBase;
object-map {
PIDName -> EndpointAddrGroup;
} NetworkMapData;
object-map {
PIDName -> EndpointAddrGroup;
} NetworkMapData;
Specifically, a NetworkMapData object is a dictionary map keyed by PIDs. The value of each PID is the associated set of endpoint addresses for the PID.
具体来说，NetworkMapData对象是由PIDs键控的字典映射。每个PID的值是PID的端点地址的关联集。
The returned network map MUST include all PIDs known to the ALTO server.
返回的网络映射必须包括ALTO服务器已知的所有PID。
GET /networkmap HTTP/1.1
Host: alto.example.com
Accept: application/alto-networkmap+json,application/alto-error+json
GET /networkmap HTTP/1.1
Host: alto.example.com
Accept: application/alto-networkmap+json,application/alto-error+json
HTTP/1.1 200 OK
Content-Length: 449
Content-Type: application/alto-networkmap+json
HTTP/1.1 200 OK
Content-Length: 449
Content-Type: application/alto-networkmap+json
{
"meta" : {
"vtag": {
"resource-id": "my-default-network-map",
"tag": "da65eca2eb7a10ce8b059740b0b2e3f8eb1d4785"
}
},
"network-map" : {
"PID1" : {
"ipv4" : [
"192.0.2.0/24",
"198.51.100.0/25"
]
},
"PID2" : {
"ipv4" : [
"198.51.100.128/25"
]
},
"PID3" : {
"ipv4" : [
"0.0.0.0/0"
],
"ipv6" : [
"::/0"
]
}
}
}
{
"meta" : {
"vtag": {
"resource-id": "my-default-network-map",
"tag": "da65eca2eb7a10ce8b059740b0b2e3f8eb1d4785"
}
},
"network-map" : {
"PID1" : {
"ipv4" : [
"192.0.2.0/24",
"198.51.100.0/25"
]
},
"PID2" : {
"ipv4" : [
"198.51.100.128/25"
]
},
"PID3" : {
"ipv4" : [
"0.0.0.0/0"
],
"ipv6" : [
"::/0"
]
}
}
}
When parsing an ALTO network map, an ALTO client MUST ignore any EndpointAddressGroup whose address type it does not recognize. If as a result a PID does not have any address types known to the client, the client still MUST recognize that PID name as valid, even though the PID then contains no endpoints.
解析ALTO网络映射时，ALTO客户端必须忽略其地址类型无法识别的任何EndpointAddressGroup。如果PID没有客户端已知的任何地址类型，则客户端仍必须将该PID名称识别为有效，即使PID不包含端点。
Note that the encoding of an ALTO network map response was chosen for readability and compactness. If lookup efficiency at runtime is crucial, then the returned network map can be transformed into data structures offering more efficient lookup. For example, one may store an ALTO network map as a trie-based data structure, which may allow efficient longest-prefix matching of IP addresses.
注意，选择ALTO网络映射响应的编码是为了可读性和紧凑性。如果运行时的查找效率至关重要，那么可以将返回的网络映射转换为提供更高效查找的数据结构。例如，可以将ALTO网络映射存储为基于trie的数据结构，这可以允许IP地址的有效最长前缀匹配。
A key usage of an ALTO network map is to map endpoint addresses to PIDs. For network maps containing the "ipv4" and "ipv6" address types defined in this document, when either an ALTO client or an ALTO server needs to compute the mapping from IP addresses to PIDs, the longest-prefix matching algorithm (Longest Match in Section 5.2.4.3 of [RFC1812]) MUST be used.
ALTO网络映射的一个关键用途是将端点地址映射到PID。对于包含本文档中定义的“ipv4”和“ipv6”地址类型的网络映射，当ALTO客户端或ALTO服务器需要计算从IP地址到PID的映射时，必须使用最长前缀匹配算法（最长匹配见[RFC1812]第5.2.4.3节）。
To ensure that the longest-prefix matching algorithm yields one and only one PID, an ALTO network map containing the "ipv4"/"ipv6" address types MUST satisfy the following two requirements.
为确保最长前缀匹配算法产生一个且仅产生一个PID，包含“ipv4”/“ipv6”地址类型的ALTO网络映射必须满足以下两个要求。
First, such a network map MUST define a PID for each possible address in the IP address space for all of the address types contained in the map. This is defined as the completeness property of an ALTO network map. A RECOMMENDED way to satisfy this property is to define a PID with the shortest enclosing prefix of the addresses provided in the map. For a map with full IPv4 reachability, this would mean including the 0.0.0.0/0 prefix in a PID; for full IPv6 reachability, this would be the ::/0 prefix.
首先，这样的网络映射必须为IP地址空间中包含的所有地址类型的每个可能地址定义一个PID。这被定义为ALTO网络图的完整性属性。满足此属性的推荐方法是使用映射中提供的地址的最短封闭前缀定义PID。对于具有完全IPv4可达性的映射，这意味着在PID中包含0.0.0.0/0前缀；对于完全IPv6可达性，这将是：：/0前缀。
Second, such a network map MUST NOT define two or more PIDs that contain an identical IP prefix, in order to ensure that the longest-prefix matching algorithm maps each IP addresses into exactly one PID. This is defined as the non-overlapping property of an ALTO network map. Specifically, to map an IP address to its PID in a non-overlapping network map, one considers the set S, which consists of all prefixes defined in the network map, applies the longest-prefix mapping algorithm to S to identify the longest prefix containing the IP address and assigns that prefix the IP address belonging to the PID containing the identified longest prefix.
其次，这样的网络映射不能定义两个或多个包含相同IP前缀的PID，以确保最长前缀匹配算法将每个IP地址映射为一个PID。这被定义为ALTO网络地图的非重叠属性。具体来说，要将IP地址映射到非重叠网络映射中的PID，需要考虑集合S，该集合由网络映射中定义的所有前缀组成，将最长前缀映射算法应用于S，以标识包含IP地址的最长前缀，并为该前缀分配属于包含标识的最长前缀的PID的IP地址。
The following example shows a complete and non-overlapping ALTO network map:
以下示例显示了完整且不重叠的ALTO网络图：
"network-map" : {
"PID0" : { "ipv6" : [ "::/0" ] },
"PID1" : { "ipv4" : [ "0.0.0.0/0" ] },
"PID2" : { "ipv4" : [ "192.0.2.0/24", "198.51.100.0/24" ] },
"PID3" : { "ipv4" : [ "192.0.2.0/25", "192.0.2.128/25" ] }
}
"network-map" : {
"PID0" : { "ipv6" : [ "::/0" ] },
"PID1" : { "ipv4" : [ "0.0.0.0/0" ] },
"PID2" : { "ipv4" : [ "192.0.2.0/24", "198.51.100.0/24" ] },
"PID3" : { "ipv4" : [ "192.0.2.0/25", "192.0.2.128/25" ] }
}
The IP address 192.0.2.1 should be mapped to PID3.
IP地址192.0.2.1应映射到PID3。
If, however, the two adjacent prefixes in PID3 were combined as a single prefix, then PID3 was changed to:
但是，如果将PID3中的两个相邻前缀合并为一个前缀，则PID3将更改为：
"PID3" : { "ipv4" : [ "192.0.2.0/24" ] }
"PID3" : { "ipv4" : [ "192.0.2.0/24" ] }
The new map is no longer non-overlapping, and 192.0.2.1 could no longer be mapped unambiguously to a PID by means of longest-prefix matching.
新映射不再是非重叠的，192.0.2.1不能再通过最长前缀匹配明确地映射到PID。
Extension documents may define techniques to allow a single IP address being mapped to multiple PIDs, when a need is identified.
扩展文档可以定义一些技术，以便在确定需求时将单个IP地址映射到多个PID。
An ALTO cost map resource lists the path cost for each pair of source/destination PIDs defined by the ALTO server for a given cost metric and cost mode. This resource MUST be provided for at least the "routingcost" cost metric.
ALTO cost map资源列出ALTO服务器为给定成本度量和成本模式定义的每对源/目标PID的路径成本。必须至少为“routingcost”成本指标提供此资源。
The media type of ALTO cost maps is "application/alto-costmap+json".
ALTO cost maps的媒体类型为“应用程序/ALTO costmap+json”。
An ALTO cost map resource is requested using the HTTP GET method.
使用HTTP GET方法请求ALTO cost map资源。
None.
没有一个
The capabilities of an ALTO server URI providing an unfiltered cost map is a JSON object of type CostMapCapabilities:
提供未过滤成本映射的ALTO服务器URI的功能是CostMapCapabilities类型的JSON对象：
object {
JSONString cost-type-names<1..1>;
} CostMapCapabilities;
object {
JSONString cost-type-names<1..1>;
} CostMapCapabilities;
with field:
带字段：
cost-type-names: Note that the array MUST include a single CostType name defined by the "cost-types" field in the "meta" field of the IRD. This is because an unfiltered cost map (accept == "") is requested via an HTTP GET that accepts no input parameters. As a contrast, for filtered cost maps (see Section 11.3.2), the array can have multiple elements.
成本类型名称：请注意，数组必须包含由IRD的“元”字段中的“成本类型”字段定义的单个成本类型名称。这是因为通过不接受输入参数的HTTP GET请求未筛选的成本映射（accept==“”）。相反，对于过滤后的成本图（见第11.3.2节），阵列可以有多个元素。
The resource ID of the network map based on which the cost map will be defined. Recall (Section 6) that the combination of a network map and a cost type defines a key. In other words, an ALTO server MUST NOT define two cost maps with the same cost type / network map pair.
将根据其定义成本图的网络图的资源ID。回想一下（第6节），网络图和成本类型的组合定义了一个键。换句话说，ALTO服务器不得使用相同的成本类型/网络映射对定义两个成本映射。
The "meta" field of a cost map response MUST include the "dependent-vtags" field, whose value is a single-element array to indicate the version tag of the network map used, where the network map is specified in "uses" of the IRD. The "meta" MUST also include the "cost-type" field, whose value indicates the cost type (Section 10.7) of the cost map.
成本图响应的“meta”字段必须包括“dependent vtags”字段，其值是一个单元素数组，用于指示所用网络图的版本标签，其中网络图在IRD的“uses”中指定。“元”还必须包括“成本类型”字段，其值表示成本图的成本类型（第10.7节）。
The data component of a cost map response is named "cost-map", which is a JSON object of type CostMapData:
cost map响应的数据组件名为“cost map”，它是CostMapData类型的JSON对象：
object {
CostMapData cost-map;
} InfoResourceCostMap : ResponseEntityBase;
object {
CostMapData cost-map;
} InfoResourceCostMap : ResponseEntityBase;
object-map {
PIDName -> DstCosts;
} CostMapData;
object-map {
PIDName -> DstCosts;
} CostMapData;
object-map {
PIDName -> JSONValue;
} DstCosts;
object-map {
PIDName -> JSONValue;
} DstCosts;
Specifically, a CostMapData object is a dictionary map object, with each key being the PIDName string identifying the corresponding source PID, and value being a type of DstCosts, which denotes the associated costs from the source PID to a set of destination PIDs (Section 6.2). An implementation of the protocol in this document SHOULD assume that the cost is a JSONNumber and fail to parse if it is not, unless the implementation is using an extension to this document that indicates when and how costs of other data types are signaled.
具体而言，CostMapData对象是字典映射对象，每个键是标识相应源PID的PIDName字符串，值是DstCosts类型，表示从源PID到一组目标PID的相关成本（第6.2节）。本文档中协议的实现应假设成本是一个JSONNumber，如果不是，则无法解析，除非该实现使用本文档的扩展，该扩展指示其他数据类型的成本何时以及如何发出信号。
The returned cost map MUST include the path cost for each (source PID, destination PID) pair for which a path cost is defined. An ALTO server MAY omit entries for which path costs are not defined (e.g., either the source or the destination PIDs contain addresses outside of the network provider's administrative domain).
返回的成本映射必须包括为其定义路径成本的每个（源PID、目标PID）对的路径成本。ALTO服务器可能会忽略未定义路径成本的条目（例如，源或目标PID包含网络提供商管理域之外的地址）。
Similar to the encoding of ALTO network maps, the encoding of ALTO cost maps was chosen for readability and compactness. If lookup efficiency at runtime is crucial, then the returned cost map can be transformed into data structures offering more efficient lookup. For example, one may store a cost map as a matrix.
与ALTO网络地图的编码类似，选择ALTO成本地图的编码是为了可读性和紧凑性。如果运行时的查找效率至关重要，那么可以将返回的成本映射转换为提供更高效查找的数据结构。例如，可以将成本图存储为矩阵。
GET /costmap/num/routingcost HTTP/1.1
Host: alto.example.com
Accept: application/alto-costmap+json,application/alto-error+json
GET /costmap/num/routingcost HTTP/1.1
Host: alto.example.com
Accept: application/alto-costmap+json,application/alto-error+json
HTTP/1.1 200 OK
Content-Length: 435
Content-Type: application/alto-costmap+json
HTTP/1.1 200 OK
Content-Length: 435
Content-Type: application/alto-costmap+json
{
"meta" : {
"dependent-vtags" : [
{"resource-id": "my-default-network-map",
"tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e"
}
],
"cost-type" : {"cost-mode" : "numerical",
"cost-metric": "routingcost"
}
},
"cost-map" : {
"PID1": { "PID1": 1, "PID2": 5, "PID3": 10 },
"PID2": { "PID1": 5, "PID2": 1, "PID3": 15 },
"PID3": { "PID1": 20, "PID2": 15 }
}
}
{
"meta" : {
"dependent-vtags" : [
{"resource-id": "my-default-network-map",
"tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e"
}
],
"cost-type" : {"cost-mode" : "numerical",
"cost-metric": "routingcost"
}
},
"cost-map" : {
"PID1": { "PID1": 1, "PID2": 5, "PID3": 10 },
"PID2": { "PID1": 5, "PID2": 1, "PID3": 15 },
"PID3": { "PID1": 20, "PID2": 15 }
}
}
Similar to the network map case, array-based encoding for "map" was considered, but the current encoding was chosen for clarity.
与网络地图的情况类似，考虑了“地图”的基于数组的编码，但为了清晰起见选择了当前编码。
The Map-Filtering Service allows ALTO clients to specify filtering criteria to return a subset of a full map available in the Map Service.
地图过滤服务允许ALTO客户端指定过滤条件，以返回地图服务中可用的完整地图的子集。
A filtered ALTO network map is an ALTO network map information resource (Section 11.2.1) for which an ALTO client may supply a list of PIDs to be included. A filtered ALTO network map MAY be provided by an ALTO server.
过滤后的ALTO网络地图是ALTO网络地图信息资源（第11.2.1节），ALTO客户可以为其提供要包括的PID列表。过滤后的ALTO网络图可由ALTO服务器提供。
Since a filtered ALTO network map is still an ALTO network map, it uses the media type defined for ALTO network maps at Section 11.2.1.1.
由于过滤后的ALTO网络图仍然是ALTO网络图，因此它使用第11.2.1.1节中为ALTO网络图定义的媒体类型。
A filtered ALTO network map is requested using the HTTP POST method.
使用HTTP POST方法请求过滤的ALTO网络映射。
An ALTO client supplies filtering parameters by specifying media type "application/alto-networkmapfilter+json" with HTTP POST body containing a JSON object of type ReqFilteredNetworkMap, where:
ALTO客户端通过使用包含ReqFilteredNetworkMap类型json对象的HTTP POST正文指定媒体类型“application/ALTO networkmapfilter+json”来提供过滤参数，其中：
object {
PIDName pids<0..*>;
[AddressType address-types<0..*>;]
} ReqFilteredNetworkMap;
object {
PIDName pids<0..*>;
[AddressType address-types<0..*>;]
} ReqFilteredNetworkMap;
with fields:
带字段：
pids: Specifies list of PIDs to be included in the returned filtered network map. If the list of PIDs is empty, the ALTO server MUST interpret the list as if it contained a list of all currently defined PIDs. The ALTO server MUST interpret entries appearing multiple times as if they appeared only once.
PID：指定要包含在返回的过滤网络映射中的PID列表。如果PID列表为空，ALTO服务器必须将该列表解释为包含当前定义的所有PID的列表。ALTO服务器必须解释多次出现的条目，就像它们只出现一次一样。
address-types: Specifies a list of address types to be included in the returned filtered network map. If the "address-types" field is not specified, or the list of address types is empty, the ALTO server MUST interpret the list as if it contained a list of all address types known to the ALTO server. The ALTO server MUST interpret entries appearing multiple times as if they appeared only once.
地址类型：指定要包含在返回的过滤网络映射中的地址类型列表。如果未指定“地址类型”字段，或地址类型列表为空，ALTO服务器必须将该列表解释为包含ALTO服务器已知的所有地址类型的列表。ALTO服务器必须解释多次出现的条目，就像它们只出现一次一样。
None.
没有一个
The resource ID of the network map based on which the filtering is performed.
根据其执行过滤的网络映射的资源ID。
The format is the same as unfiltered network maps. See Section 11.2.1.6 for the format.
格式与未过滤的网络地图相同。格式见第11.2.1.6节。
The ALTO server MUST only include PIDs in the response that were specified (implicitly or explicitly) in the request. If the input parameters contain a PID name that is not currently defined by the ALTO server, the ALTO server MUST behave as if the PID did not appear in the input parameters. Similarly, the ALTO server MUST only enumerate addresses within each PID that have types specified (implicitly or explicitly) in the request. If the input parameters contain an address type that is not currently known to the ALTO server, the ALTO server MUST behave as if the address type did not appear in the input parameters.
ALTO服务器只能在响应中包含请求中指定（隐式或显式）的PID。如果输入参数包含当前未由ALTO服务器定义的PID名称，ALTO服务器的行为必须与输入参数中未出现PID一样。类似地，ALTO服务器必须仅枚举每个PID中的地址，这些地址在请求中指定了（隐式或显式）类型。如果输入参数包含ALTO服务器当前未知的地址类型，则ALTO服务器的行为必须与输入参数中未显示地址类型一样。
The version tag included in the "vtag" field of the response MUST correspond to the full (unfiltered) network map information resource from which the filtered information is provided. This ensures that a single, canonical version tag is used independent of any filtering that is requested by an ALTO client.
响应的“vtag”字段中包含的版本标签必须对应于提供过滤信息的完整（未过滤）网络地图信息资源。这确保使用单个规范版本标记，而不受ALTO客户端请求的任何筛选的影响。
POST /networkmap/filtered HTTP/1.1
Host: custom.alto.example.com
Content-Length: 33
Content-Type: application/alto-networkmapfilter+json
Accept: application/alto-networkmap+json,application/alto-error+json
POST /networkmap/filtered HTTP/1.1
Host: custom.alto.example.com
Content-Length: 33
Content-Type: application/alto-networkmapfilter+json
Accept: application/alto-networkmap+json,application/alto-error+json
{
"pids": [ "PID1", "PID2" ]
}
{
"pids": [ "PID1", "PID2" ]
}
HTTP/1.1 200 OK
Content-Length: 342
Content-Type: application/alto-networkmap+json
HTTP/1.1 200 OK
Content-Length: 342
Content-Type: application/alto-networkmap+json
{
"meta" : {
"vtag" : {
"resource-id": "my-default-network-map",
"tag": "c0ce023b8678a7b9ec00324673b98e54656d1f6d"
}
},
"network-map" : {
"PID1" : {
"ipv4" : [
"192.0.2.0/24",
"198.51.100.0/24"
]
},
"PID2" : {
"ipv4": [
"198.51.100.128/24"
]
}
}
}
{
"meta" : {
"vtag" : {
"resource-id": "my-default-network-map",
"tag": "c0ce023b8678a7b9ec00324673b98e54656d1f6d"
}
},
"network-map" : {
"PID1" : {
"ipv4" : [
"192.0.2.0/24",
"198.51.100.0/24"
]
},
"PID2" : {
"ipv4": [
"198.51.100.128/24"
]
}
}
}
A filtered ALTO cost map is a cost map information resource (Section 11.2.3) for which an ALTO client may supply additional parameters limiting the scope of the resulting cost map. A filtered ALTO cost map MAY be provided by an ALTO server.
过滤后的ALTO成本图是成本图信息资源（第11.2.3节），ALTO客户可为其提供限制生成成本图范围的额外参数。ALTO服务器可以提供过滤后的ALTO成本图。
Since a filtered ALTO cost map is still an ALTO cost map, it uses the media type defined for ALTO cost maps at Section 11.2.3.1.
由于过滤后的ALTO成本图仍然是ALTO成本图，因此它使用第11.2.3.1节中为ALTO成本图定义的媒体类型。
A filtered ALTO cost map is requested using the HTTP POST method.
使用HTTP POST方法请求过滤的ALTO成本映射。
The input parameters for a filtered cost map are supplied in the entity body of the POST request. This document specifies the input parameters with a data format indicated by the media type "application/alto-costmapfilter+json", which is a JSON object of type ReqFilteredCostMap, where:
过滤后的成本映射的输入参数在POST请求的实体主体中提供。本文档使用“application/alto costmapfilter+json”媒体类型指示的数据格式指定输入参数，该媒体类型是ReqFilteredCostMap类型的json对象，其中：
object {
CostType cost-type;
[JSONString constraints<0..*>;]
[PIDFilter pids;]
} ReqFilteredCostMap;
object {
CostType cost-type;
[JSONString constraints<0..*>;]
[PIDFilter pids;]
} ReqFilteredCostMap;
object {
PIDName srcs<0..*>;
PIDName dsts<0..*>;
} PIDFilter;
object {
PIDName srcs<0..*>;
PIDName dsts<0..*>;
} PIDFilter;
with fields:
带字段：
cost-type: The CostType (Section 10.7) for the returned costs. The "cost-metric" and "cost-mode" fields MUST match one of the supported cost types indicated in this resource's "capabilities" field (Section 11.3.2.4). The ALTO client SHOULD omit the "description" field, and if present, the ALTO server MUST ignore the "description" field.
成本类型：返回成本的成本类型（第10.7节）。“成本度量”和“成本模式”字段必须与此资源的“能力”字段（第11.3.2.4节）中指示的支持的成本类型之一相匹配。ALTO客户端应省略“描述”字段，如果存在，ALTO服务器必须忽略“描述”字段。
constraints: Defines a list of additional constraints on which elements of the cost map are returned. This parameter MUST NOT be specified if this resource's "capabilities" field (Section 11.3.2.4) indicate that constraint support is not available. A constraint contains two entities separated by whitespace: (1) an operator, "gt" for greater than, "lt" for less than, "ge" for greater than or equal to, "le" for less than or equal to, or "eq" for equal to and (2) a target cost value. The cost value is a number that MUST be defined in the same units as
约束：定义返回成本映射元素的附加约束列表。如果此资源的“能力”字段（第11.3.2.4节）指示约束支持不可用，则不得指定此参数。约束包含两个由空格分隔的实体：（1）运算符，“gt”表示大于，“lt”表示小于，“ge”表示大于或等于，“le”表示小于或等于，或“eq”表示等于；（2）目标成本值。成本值是一个数字，必须以与成本值相同的单位定义
the cost metric indicated by the "cost-metric" parameter. ALTO servers SHOULD use at least IEEE 754 double-precision floating point [IEEE.754.2008] to store the cost value, and SHOULD perform internal computations using double-precision floating-point arithmetic. If multiple "constraint" parameters are specified, they are interpreted as being related to each other with a logical AND.
“成本度量”参数指示的成本度量。ALTO服务器应至少使用IEEE 754双精度浮点[IEEE.754.2008]来存储成本值，并应使用双精度浮点算法执行内部计算。如果指定了多个“约束”参数，则它们将被解释为通过逻辑AND相互关联。
pids: A list of source PIDs and a list of destination PIDs for which path costs are to be returned. If a list is empty, the ALTO server MUST interpret it as the full set of currently defined PIDs. The ALTO server MUST interpret entries appearing in a list multiple times as if they appeared only once. If the "pids" field is not present, both lists MUST be interpreted by the ALTO server as containing the full set of currently defined PIDs.
PID：要返回路径成本的源PID列表和目标PID列表。如果列表为空，ALTO服务器必须将其解释为当前定义的完整PID集。ALTO服务器必须多次解释列表中出现的条目，就像它们只出现一次一样。如果“pids”字段不存在，ALTO服务器必须将这两个列表解释为包含当前定义的完整pids集。
The URI providing this resource supports all capabilities documented in Section 11.2.3.4 (with identical semantics), plus additional capabilities. In particular, the capabilities are defined by a JSON object of type FilteredCostMapCapabilities:
提供此资源的URI支持第11.2.3.4节中记录的所有功能（具有相同的语义）以及其他功能。具体而言，这些功能由FilteredCostMapCapabilities类型的JSON对象定义：
object {
JSONString cost-type-names<1..*>;
JSONBool cost-constraints;
} FilteredCostMapCapabilities;
object {
JSONString cost-type-names<1..*>;
JSONBool cost-constraints;
} FilteredCostMapCapabilities;
with fields:
带字段：
cost-type-names: See Section 11.2.3.4 and note that the array can have one to many cost types.
成本类型名称：请参阅第11.2.3.4节，并注意数组可以有一对多的成本类型。
cost-constraints: If true, then the ALTO server allows cost constraints to be included in requests to the corresponding URI. If not present, this field MUST be interpreted as if it specified false. ALTO clients should be aware that constraints may not have the intended effect for cost maps with the ordinal cost mode since ordinal costs are not restricted to being sequential integers.
成本约束：如果为true，则ALTO服务器允许在对相应URI的请求中包含成本约束。如果不存在，则必须将此字段解释为指定为false。ALTO客户应注意，约束可能不会对顺序成本模式下的成本映射产生预期效果，因为顺序成本不限于顺序整数。
The resource ID of the network map based on which the cost map will be filtered.
网络映射的资源ID，将根据该ID筛选成本映射。
The format is the same as an unfiltered ALTO cost map. See Section 11.2.3.6 for the format.
格式与未过滤的ALTO成本图相同。格式见第11.2.3.6节。
The "dependent-vtags" field in the "meta" field provides an array consisting of a single element, which is the version tag of the network map used in filtering. ALTO clients should verify that the version tag included in the response is equal to the version tag of the network map used to generate the request (if applicable). If it is not, the ALTO client may wish to request an updated network map, identify changes, and consider requesting a new filtered cost map.
“meta”字段中的“dependent vtags”字段提供了一个由单个元素组成的数组，该元素是过滤中使用的网络映射的版本标记。ALTO客户端应验证响应中包含的版本标记是否等于用于生成请求的网络映射的版本标记（如果适用）。如果不是，阿尔托客户端可能希望请求更新的网络地图，识别更改，并考虑请求新的过滤成本映射。
The returned cost map MUST contain only source/destination pairs that have been indicated (implicitly or explicitly) in the input parameters. If the input parameters contain a PID name that is not currently defined by the ALTO server, the ALTO server MUST behave as if the PID did not appear in the input parameters.
返回的成本映射必须仅包含输入参数中已指示（隐式或显式）的源/目标对。如果输入参数包含当前未由ALTO服务器定义的PID名称，ALTO服务器的行为必须与输入参数中未出现PID一样。
If any constraints are specified, source/destination pairs for which the path costs do not meet the constraints MUST NOT be included in the returned cost map. If no constraints were specified, then all path costs are assumed to meet the constraints.
如果指定了任何约束，则返回的成本映射中不得包含路径成本不满足约束的源/目标对。如果未指定约束，则假定所有路径成本都满足约束。
POST /costmap/filtered HTTP/1.1
Host: custom.alto.example.com
Content-Type: application/alto-costmapfilter+json
Content-Length: 181
Accept: application/alto-costmap+json,application/alto-error+json
POST /costmap/filtered HTTP/1.1
Host: custom.alto.example.com
Content-Type: application/alto-costmapfilter+json
Content-Length: 181
Accept: application/alto-costmap+json,application/alto-error+json
{
"cost-type" : {"cost-mode": "numerical",
"cost-metric": "routingcost"
},
"pids" : {
"srcs" : [ "PID1" ],
"dsts" : [ "PID1", "PID2", "PID3" ]
}
}
{
"cost-type" : {"cost-mode": "numerical",
"cost-metric": "routingcost"
},
"pids" : {
"srcs" : [ "PID1" ],
"dsts" : [ "PID1", "PID2", "PID3" ]
}
}
HTTP/1.1 200 OK
Content-Length: 341
Content-Type: application/alto-costmap+json
HTTP/1.1 200 OK
Content-Length: 341
Content-Type: application/alto-costmap+json
{
"meta" : {
"dependent-vtags" : [
{"resource-id": "my-default-network-map",
"tag": "75ed013b3cb58f896e839582504f622838ce670f"
}
],
"cost-type": {"cost-mode" : "numerical",
"cost-metric" : "routingcost"
}
},
"cost-map" : {
"PID1": { "PID1": 0, "PID2": 1, "PID3": 2 }
}
}
{
"meta" : {
"dependent-vtags" : [
{"resource-id": "my-default-network-map",
"tag": "75ed013b3cb58f896e839582504f622838ce670f"
}
],
"cost-type": {"cost-mode" : "numerical",
"cost-metric" : "routingcost"
}
},
"cost-map" : {
"PID1": { "PID1": 0, "PID2": 1, "PID3": 2 }
}
}
The Endpoint Property Service provides information about endpoint properties to ALTO clients.
端点属性服务向ALTO客户端提供有关端点属性的信息。
An endpoint property resource provides information about properties for individual endpoints. In addition to the required "pid" endpoint property (see Sections 7.1.1 and 11.4.1.4), further endpoint properties MAY be provided by an ALTO server.
端点属性资源提供有关各个端点的属性的信息。除了所需的“pid”端点属性（参见第7.1.1节和第11.4.1.4节），ALTO服务器还可以提供其他端点属性。
The media type of an endpoint property resource is "application/ alto-endpointprop+json".
端点属性资源的媒体类型为“application/alto endpointprop+json”。
The endpoint property resource is requested using the HTTP POST method.
端点属性资源是使用HTTP POST方法请求的。
The input parameters for an endpoint property request are supplied in the entity body of the POST request. This document specifies the input parameters with a data format indicated by the media type "application/alto-endpointpropparams+json", which is a JSON object of type ReqEndpointProp:
端点属性请求的输入参数在POST请求的实体体中提供。本文档使用“application/alto endpointpropparams+json”媒体类型指示的数据格式指定输入参数，该媒体类型是ReqEndpointProp类型的json对象：
object {
EndpointPropertyType properties<1..*>;
TypedEndpointAddr endpoints<1..*>;
} ReqEndpointProp;
object {
EndpointPropertyType properties<1..*>;
TypedEndpointAddr endpoints<1..*>;
} ReqEndpointProp;
with fields:
带字段：
properties: List of endpoint properties to be returned for each endpoint. Each specified property MUST be included in the list of supported properties indicated by this resource's "capabilities" field (Section 11.4.1.4). The ALTO server MUST interpret entries appearing multiple times as if they appeared only once.
属性：要为每个端点返回的端点属性列表。每个指定的属性必须包含在此资源的“能力”字段（第11.4.1.4节）所指示的支持属性列表中。ALTO服务器必须解释多次出现的条目，就像它们只出现一次一样。
endpoints: List of endpoint addresses for which the specified properties are to be returned. The ALTO server MUST interpret entries appearing multiple times as if they appeared only once.
端点：要为其返回指定属性的端点地址列表。ALTO服务器必须解释多次出现的条目，就像它们只出现一次一样。
The capabilities of an ALTO server URI providing endpoint properties are defined by a JSON object of type EndpointPropertyCapabilities:
提供端点属性的ALTO server URI的功能由EndpointPropertyCapabilities类型的JSON对象定义：
object {
EndpointPropertyType prop-types<1..*>;
} EndpointPropertyCapabilities;
object {
EndpointPropertyType prop-types<1..*>;
} EndpointPropertyCapabilities;
with field:
带字段：
prop-types: The endpoint properties (see Section 10.8) supported by the corresponding URI.
道具类型：对应URI支持的端点属性（参见第10.8节）。
In particular, the information resource closure MUST provide the lookup of pid for every ALTO network map defined.
特别是，信息资源关闭必须为每个定义的ALTO网络图提供pid查找。
None.
没有一个
The "dependent-vtags" field in the "meta" field of the response MUST be an array that includes the version tags of all ALTO network maps whose "pid" is queried.
响应“meta”字段中的“dependent vtags”字段必须是一个数组，其中包含所有ALTO网络地图的版本标签，其“pid”被查询。
The data component of an endpoint properties response is named "endpoint-properties", which is a JSON object of type EndpointPropertyMapData, where:
endpoint properties响应的数据组件名为“endpoint properties”，它是EndpointPropertyMapData类型的JSON对象，其中：
object {
EndpointPropertyMapData endpoint-properties;
} InfoResourceEndpointProperties : ResponseEntityBase;
object {
EndpointPropertyMapData endpoint-properties;
} InfoResourceEndpointProperties : ResponseEntityBase;
object-map {
TypedEndpointAddr -> EndpointProps;
} EndpointPropertyMapData;
object-map {
TypedEndpointAddr -> EndpointProps;
} EndpointPropertyMapData;
object {
EndpointPropertyType -> JSONValue;
} EndpointProps;
object {
EndpointPropertyType -> JSONValue;
} EndpointProps;
Specifically, an EndpointPropertyMapData object has one member for each endpoint indicated in the input parameters (with the name being the endpoint encoded as a TypedEndpointAddr). The requested properties for each endpoint are encoded in a corresponding EndpointProps object, which encodes one name/value pair for each requested property, where the property names are encoded as strings of type EndpointPropertyType. An implementation of the protocol in
具体来说，EndpointPropertyMapData对象对于输入参数中指示的每个端点都有一个成员（名称是编码为TypedEndpointAddr的端点）。每个端点的请求属性编码在对应的EndpointProps对象中，该对象为每个请求的属性编码一个名称/值对，其中属性名称编码为EndpointPropertyType类型的字符串。协议的一种实现
this document SHOULD assume that the property value is a JSONString and fail to parse if it is not, unless the implementation is using an extension to this document that indicates when and how property values of other data types are signaled.
此文档应假定属性值是JSONString，如果不是，则无法解析，除非实现使用此文档的扩展，该扩展指示其他数据类型的属性值何时以及如何被标记。
The ALTO server returns the value for each of the requested endpoint properties for each of the endpoints listed in the input parameters.
ALTO服务器为输入参数中列出的每个端点返回每个请求的端点属性的值。
If the ALTO server does not define a requested property's value for a particular endpoint, then it MUST omit that property from the response for only that endpoint.
如果ALTO服务器没有为特定端点定义请求的属性值，则必须仅从该端点的响应中忽略该属性。
POST /endpointprop/lookup HTTP/1.1
Host: alto.example.com
Content-Length: 181
Content-Type: application/alto-endpointpropparams+json
Accept: application/alto-endpointprop+json,application/alto-error+json
POST /endpointprop/lookup HTTP/1.1
Host: alto.example.com
Content-Length: 181
Content-Type: application/alto-endpointpropparams+json
Accept: application/alto-endpointprop+json,application/alto-error+json
{
"properties" : [ "my-default-networkmap.pid",
"priv:ietf-example-prop" ],
"endpoints" : [ "ipv4:192.0.2.34",
"ipv4:203.0.113.129" ]
}
{
"properties" : [ "my-default-networkmap.pid",
"priv:ietf-example-prop" ],
"endpoints" : [ "ipv4:192.0.2.34",
"ipv4:203.0.113.129" ]
}
HTTP/1.1 200 OK
Content-Length: 396
Content-Type: application/alto-endpointprop+json
HTTP/1.1 200 OK
Content-Length: 396
Content-Type: application/alto-endpointprop+json
{
"meta" : {
"dependent-vtags" : [
{"resource-id": "my-default-network-map",
"tag": "7915dc0290c2705481c491a2b4ffbec482b3cf62"
}
]
},
"endpoint-properties": {
"ipv4:192.0.2.34" : { "my-default-network-map.pid": "PID1",
"priv:ietf-example-prop": "1" },
"ipv4:203.0.113.129" : { "my-default-network-map.pid": "PID3" }
}
}
{
"meta" : {
"dependent-vtags" : [
{"resource-id": "my-default-network-map",
"tag": "7915dc0290c2705481c491a2b4ffbec482b3cf62"
}
]
},
"endpoint-properties": {
"ipv4:192.0.2.34" : { "my-default-network-map.pid": "PID1",
"priv:ietf-example-prop": "1" },
"ipv4:203.0.113.129" : { "my-default-network-map.pid": "PID3" }
}
}
The Endpoint Cost Service provides information about costs between individual endpoints.
端点成本服务提供有关各个端点之间成本的信息。
In particular, this service allows lists of endpoint prefixes (and addresses, as a special case) to be ranked (ordered) by an ALTO server.
特别是，该服务允许ALTO服务器对端点前缀（和地址，作为特殊情况）列表进行排序（排序）。
An endpoint cost resource provides information about costs between individual endpoints. It MAY be provided by an ALTO server.
端点成本资源提供有关各个端点之间成本的信息。它可以由ALTO服务器提供。
How an ALTO server provides the endpoint cost resource is implementation dependent. An ALTO server may use either fine-grained costs among individual endpoints or coarse-grained costs based on the costs between the PIDs corresponding to the endpoints. See Section 15.3 for additional details.
ALTO服务器如何提供端点成本资源取决于实现。ALTO服务器可以在各个端点之间使用细粒度成本，也可以基于与端点对应的PID之间的成本使用粗粒度成本。更多详情见第15.3节。
The media type of the endpoint cost resource is "application/alto-endpointcost+json".
端点成本资源的媒体类型为“application/alto endpointcost+json”。
The endpoint cost resource is requested using the HTTP POST method.
端点成本资源是使用HTTP POST方法请求的。
An ALTO client supplies the endpoint cost parameters through a media type "application/alto-endpointcostparams+json", with an HTTP POST entity body of a JSON object of type ReqEndpointCostMap:
ALTO客户端通过媒体类型“application/ALTO endpointcostparams+json”提供端点成本参数，该媒体类型具有ReqEndpointCostMap类型json对象的HTTP POST实体体：
object {
CostType cost-type;
[JSONString constraints<0..*>;]
EndpointFilter endpoints;
} ReqEndpointCostMap;
object {
CostType cost-type;
[JSONString constraints<0..*>;]
EndpointFilter endpoints;
} ReqEndpointCostMap;
object {
[TypedEndpointAddr srcs<0..*>;]
[TypedEndpointAddr dsts<0..*>;]
} EndpointFilter;
object {
[TypedEndpointAddr srcs<0..*>;]
[TypedEndpointAddr dsts<0..*>;]
} EndpointFilter;
with fields:
带字段：
cost-type: The cost type (Section 10.7) to use for returned costs. The "cost-metric" and "cost-mode" fields MUST match one of the supported cost types indicated in this resource's "capabilities" fields (Section 11.5.1.4). The ALTO client SHOULD omit the "description" field, and if present, the ALTO server MUST ignore the "description" field.
成本类型：用于返回成本的成本类型（第10.7节）。“成本度量”和“成本模式”字段必须与此资源的“能力”字段（第11.5.1.4节）中指示的支持的成本类型之一相匹配。ALTO客户端应省略“描述”字段，如果存在，ALTO服务器必须忽略“描述”字段。
constraints: Defined equivalently to the "constraints" input parameter of a filtered cost map (see Section 11.3.2).
约束：与过滤成本图的“约束”输入参数等效定义（见第11.3.2节）。
endpoints: A list of source endpoints and destination endpoints for which path costs are to be returned. If the list of source or destination endpoints is empty (or not included), the ALTO server MUST interpret it as if it contained the endpoint address corresponding to the client IP address from the incoming connection (see Section 13.3 for discussion and considerations regarding this mode). The source and destination endpoint lists MUST NOT be both empty. The ALTO server MUST interpret entries appearing multiple times in a list as if they appeared only once.
端点：要返回其路径成本的源端点和目标端点的列表。如果源或目标端点列表为空（或未包含），ALTO服务器必须将其解释为包含与传入连接的客户端IP地址相对应的端点地址（有关此模式的讨论和注意事项，请参阅第13.3节）。源和目标终结点列表不能同时为空。ALTO服务器必须将列表中多次出现的条目解释为只出现一次。
This document defines EndpointCostCapabilities as the same as FilteredCostMapCapabilities. See Section 11.3.2.4.
本文档将EndpointCostCapabilities定义为与FilteredCostMapCapabilities相同的功能。见第11.3.2.4节。
It is important to note that although this resource allows an ALTO server to reveal costs between individual endpoints, the ALTO server is not required to do so. A simple implementation of ECS may compute the cost between two endpoints as the cost between the PIDs corresponding to the endpoints, using one of the exposed network and cost maps defined by the server. ECS MUST NOT specify the "use" field to indicate a network or cost map. Hence, the ECS cost is the cost from the source endpoint to the destination endpoint. A future extension may allow ECS to state that it "uses" a network map. The extension then will need to define the semantics.
需要注意的是，尽管此资源允许ALTO服务器显示各个端点之间的成本，但ALTO服务器不需要这样做。ECS的简单实现可以使用服务器定义的公开网络和成本映射之一，将两个端点之间的成本计算为与端点对应的PID之间的成本。ECS不得指定“使用”字段来表示网络或成本映射。因此，ECS成本是从源端点到目标端点的成本。未来的扩展可能允许ECS声明它“使用”了网络地图。然后，扩展需要定义语义。
The "meta" field of an endpoint cost response MUST include the "cost-type" field, to indicate the cost type used.
端点成本响应的“元”字段必须包括“成本类型”字段，以指示使用的成本类型。
The data component of an endpoint cost response is named "endpoint-cost-map", which is a JSON object of type EndpointCostMapData:
端点成本响应的数据组件名为“端点成本映射”，它是EndpointCostMapData类型的JSON对象：
object {
EndpointCostMapData endpoint-cost-map;
} InfoResourceEndpointCostMap : ResponseEntityBase;
object {
EndpointCostMapData endpoint-cost-map;
} InfoResourceEndpointCostMap : ResponseEntityBase;
object-map {
TypedEndpointAddr -> EndpointDstCosts;
} EndpointCostMapData;
object-map {
TypedEndpointAddr -> EndpointDstCosts;
} EndpointCostMapData;
object-map {
TypedEndpointAddr -> JSONValue;
} EndpointDstCosts;
object-map {
TypedEndpointAddr -> JSONValue;
} EndpointDstCosts;
Specifically, an EndpointCostMapData object is a dictionary map with each key representing a TypedEndpointAddr string identifying the source endpoint specified in the input parameters. For each source endpoint, an EndpointDstCosts dictionary map object denotes the associated cost to each destination endpoint specified in input parameters. An implementation of the protocol in this document SHOULD assume that the cost value is a JSONNumber and fail to parse if it is not, unless the implementation is using an extension to this document that indicates when and how costs of other data types are signaled. If the ALTO server does not define a cost value from a source endpoint to a particular destination endpoint, it MAY be omitted from the response.
具体来说，EndpointCostMapData对象是一个字典映射，每个键表示一个TypedEndpointAddr字符串，该字符串标识输入参数中指定的源端点。对于每个源端点，EndpointDSTCOSS字典映射对象表示输入参数中指定的每个目标端点的关联成本。本文档中协议的实现应假设成本值为JSONNumber，如果不是，则无法解析，除非该实现使用本文档的扩展，该扩展指示其他数据类型的成本何时以及如何发出信号。如果ALTO服务器没有定义从源端点到特定目标端点的成本值，则可以从响应中忽略该成本值。
POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com
Content-Length: 248
Content-Type: application/alto-endpointcostparams+json
Accept: application/alto-endpointcost+json,application/alto-error+json
POST /endpointcost/lookup HTTP/1.1
Host: alto.example.com
Content-Length: 248
Content-Type: application/alto-endpointcostparams+json
Accept: application/alto-endpointcost+json,application/alto-error+json
{
"cost-type": {"cost-mode" : "ordinal",
"cost-metric" : "routingcost"},
"endpoints" : {
"srcs": [ "ipv4:192.0.2.2" ],
"dsts": [
"ipv4:192.0.2.89",
"ipv4:198.51.100.34",
"ipv4:203.0.113.45"
]
}
}
{
"cost-type": {"cost-mode" : "ordinal",
"cost-metric" : "routingcost"},
"endpoints" : {
"srcs": [ "ipv4:192.0.2.2" ],
"dsts": [
"ipv4:192.0.2.89",
"ipv4:198.51.100.34",
"ipv4:203.0.113.45"
]
}
}
HTTP/1.1 200 OK
Content-Length: 274
Content-Type: application/alto-endpointcost+json
HTTP/1.1 200 OK
Content-Length: 274
Content-Type: application/alto-endpointcost+json
{
"meta" : {
"cost-type": {"cost-mode" : "ordinal",
"cost-metric" : "routingcost"
}
},
"endpoint-cost-map" : {
"ipv4:192.0.2.2": {
"ipv4:192.0.2.89" : 1,
"ipv4:198.51.100.34" : 2,
"ipv4:203.0.113.45" : 3
}
}
}
{
"meta" : {
"cost-type": {"cost-mode" : "ordinal",
"cost-metric" : "routingcost"
}
},
"endpoint-cost-map" : {
"ipv4:192.0.2.2": {
"ipv4:192.0.2.89" : 1,
"ipv4:198.51.100.34" : 2,
"ipv4:203.0.113.45" : 3
}
}
}
The sections below depict typical use cases. While these use cases focus on peer-to-peer applications, ALTO can be applied to other environments such as Content Distribution Networks (CDNs) [ALTO-USE-CASES].
下面的部分描述了典型的用例。虽然这些用例侧重于对等应用程序，但ALTO可以应用于其他环境，如内容分发网络（CDN）[ALTO用例]。
Many deployed P2P systems use a tracker to manage swarms and perform peer selection. Such a P2P tracker can already use a variety of information to perform peer selection to meet application-specific goals. By acting as an ALTO client, the P2P tracker can use ALTO information as an additional information source to enable more network-efficient traffic patterns and improve application performance.
许多部署的P2P系统使用跟踪器来管理群集和执行对等选择。这样的P2P跟踪器已经可以使用各种信息来执行对等选择，以满足特定于应用程序的目标。通过充当ALTO客户端，P2P跟踪器可以使用ALTO信息作为附加信息源，以实现更高效的网络流量模式并提高应用程序性能。
A particular requirement of many P2P trackers is that they must handle a large number of P2P clients. A P2P tracker can obtain and locally store ALTO information (e.g., ALTO network maps and cost maps) from the ISPs containing the P2P clients, and benefit from the same aggregation of network locations done by ALTO servers.
许多P2P跟踪器的一个特殊要求是，它们必须处理大量的P2P客户端。P2P跟踪器可以从包含P2P客户端的ISP获取并本地存储ALTO信息（例如，ALTO网络地图和成本地图），并从ALTO服务器完成的相同网络位置聚合中获益。
.---------. (1) Get Network Map .---------------.
| | <----------------------> | |
| ALTO | | P2P Tracker |
| Server | (2) Get Cost Map | (ALTO client) |
| | <----------------------> | |
`---------' `---------------'
^ |
(3) Get Peers | | (4) Selected Peer
| v List
.---------. .-----------.
| Peer 1 | <-------------- | P2P |
`---------' | Client |
. (5) Connect to `-----------'
. Selected Peers /
.---------. /
| Peer 50 | <------------------
`---------'
.---------. (1) Get Network Map .---------------.
| | <----------------------> | |
| ALTO | | P2P Tracker |
| Server | (2) Get Cost Map | (ALTO client) |
| | <----------------------> | |
`---------' `---------------'
^ |
(3) Get Peers | | (4) Selected Peer
| v List
.---------. .-----------.
| Peer 1 | <-------------- | P2P |
`---------' | Client |
. (5) Connect to `-----------'
. Selected Peers /
.---------. /
| Peer 50 | <------------------
`---------'
Figure 4: ALTO Client Embedded in P2P Tracker
图4：嵌入P2P跟踪器的ALTO客户端
Figure 4 shows an example use case where a P2P tracker is an ALTO client and applies ALTO information when selecting peers for its P2P clients. The example proceeds as follows:
图4显示了一个示例用例，其中P2P跟踪器是ALTO客户端，在为其P2P客户端选择对等点时应用ALTO信息。示例如下所示：
1. The P2P tracker requests from the ALTO server a network map, so that it locally map P2P clients into PIDs.
1. P2P跟踪器从ALTO服务器请求一个网络映射，以便它将P2P客户端本地映射到PID中。
2. The P2P tracker requests from the ALTO server the cost map amongst all PIDs identified in the preceding step.
2. P2P跟踪器从ALTO服务器请求上一步中确定的所有PID之间的成本映射。
3. A P2P client joins the swarm, and requests a peer list from the P2P tracker.
3. P2P客户端加入swarm，并从P2P跟踪器请求对等列表。
4. The P2P tracker returns a peer list to the P2P client. The returned peer list is computed based on the network map and the cost map returned by the ALTO server, and possibly other information sources. Note that it is possible that a tracker may use only the network map to implement hierarchical peer selection by preferring peers within the same PID and ISP.
4. P2P跟踪器将对等点列表返回给P2P客户端。返回的对等列表是基于ALTO服务器返回的网络映射和成本映射以及可能的其他信息源计算的。注意，跟踪器可能仅使用网络映射来通过优先选择相同PID和ISP内的对等点来实现分层对等选择。
5. The P2P client connects to the selected peers.
5. P2P客户端连接到选定的对等方。
Note that the P2P tracker may provide peer lists to P2P clients distributed across multiple ISPs. In such a case, the P2P tracker may communicate with multiple ALTO servers.
注意，P2P跟踪器可以向分布在多个isp上的P2P客户端提供对等列表。在这种情况下，P2P跟踪器可以与多个ALTO服务器通信。
P2P clients may also utilize ALTO information themselves when selecting from available peers. It is important to note that not all P2P systems use a P2P tracker for peer discovery and selection. Furthermore, even when a P2P tracker is used, the P2P clients may rely on other sources, such as peer exchange and DHTs, to discover peers.
P2P客户端在从可用的对等点进行选择时也可以利用ALTO信息。需要注意的是，并非所有P2P系统都使用P2P跟踪器进行对等点发现和选择。此外，即使在使用P2P跟踪器时，P2P客户端也可以依赖其他源（例如对等交换和DHTs）来发现对等点。
When a P2P client uses ALTO information, it typically queries only the ALTO server servicing its own ISP. The "my-Internet view" provided by its ISP's ALTO server can include preferences to all potential peers.
当P2P客户端使用ALTO信息时，它通常只查询为自己的ISP服务的ALTO服务器。ISP的ALTO服务器提供的“我的互联网视图”可以包括所有潜在对等方的首选项。
.---------. (1) Get Network Map .---------------.
| | <----------------------> | |
| ALTO | | P2P Client |
| Server | (2) Get Cost Map | (ALTO client) |
| | <----------------------> | | .---------.
`---------' `---------------' <- | P2P |
.---------. / | ^ ^ | Tracker |
| Peer 1 | <-------------- | | \ `---------'
`---------' | (3) Gather Peers
. (4) Select Peers | | \
. and Connect / .--------. .--------.
.---------. / | P2P | | DHT |
| Peer 50 | <---------------- | Client | `--------'
`---------' | (PEX) |
`--------'
.---------. (1) Get Network Map .---------------.
| | <----------------------> | |
| ALTO | | P2P Client |
| Server | (2) Get Cost Map | (ALTO client) |
| | <----------------------> | | .---------.
`---------' `---------------' <- | P2P |
.---------. / | ^ ^ | Tracker |
| Peer 1 | <-------------- | | \ `---------'
`---------' | (3) Gather Peers
. (4) Select Peers | | \
. and Connect / .--------. .--------.
.---------. / | P2P | | DHT |
| Peer 50 | <---------------- | Client | `--------'
`---------' | (PEX) |
`--------'
Figure 5: ALTO Client Embedded in P2P Client
图5：嵌入P2P客户端的ALTO客户端
Figure 5 shows an example use case where a P2P client locally applies ALTO information to select peers. The use case proceeds as follows:
图5显示了一个示例用例，其中P2P客户端在本地应用ALTO信息来选择对等点。用例如下所示：
1. The P2P client requests the network map covering all PIDs from the ALTO server servicing its own ISP.
1. P2P客户端从为其ISP提供服务的ALTO服务器请求覆盖所有PID的网络地图。
2. The P2P client requests the cost map providing path costs amongst all PIDs from the ALTO server. The cost map by default specifies numerical costs.
2. P2P客户端从ALTO服务器请求成本映射，提供所有PID之间的路径成本。默认情况下，成本图指定数字成本。
3. The P2P client discovers peers from sources such as peer exchange (PEX) from other P2P clients, distributed hash tables (DHT), and P2P trackers.
3. P2P客户端从其他P2P客户端的对等交换（PEX）、分布式哈希表（DHT）和P2P跟踪器等来源发现对等点。
4. The P2P client uses ALTO information as part of the algorithm for selecting new peers and connects to the selected peers.
4. P2P客户端使用ALTO信息作为选择新对等点的算法的一部分，并连接到所选对等点。
It is also possible for a P2P client to offload the selection and ranking process to an ALTO server. In this use case, the ALTO client embedded in the P2P client gathers a list of known peers in the swarm, and asks the ALTO server to rank them. This document limits the use case to when the P2P client and the ALTO server are deployed by the same entity; hence, the P2P client uses the ranking provided by the ALTO server directly.
P2P客户端也可以将选择和排名过程卸载到ALTO服务器。在这个用例中，嵌入在P2P客户端中的ALTO客户端收集群中已知对等点的列表，并要求ALTO服务器对它们进行排序。本文档将用例限制为P2P客户端和ALTO服务器由同一实体部署时；因此，P2P客户端直接使用ALTO服务器提供的排名。
As in the use case using numerical costs, the P2P client typically only queries the ALTO server servicing its own ISP.
与使用数字成本的用例一样，P2P客户端通常只查询为其自己的ISP服务的ALTO服务器。
.---------. .---------------.
| | | |
| ALTO | (2) Get Endpoint Ranking | P2P Client |
| Server | <----------------------> | (ALTO client) |
| | | | .---------.
`---------' `---------------' <- | P2P |
.---------. / | ^ ^ | Tracker |
| Peer 1 | <-------------- | | \ `---------'
`---------' | (1) Gather Peers
. (3) Connect to | | \
. Selected Peers / .--------. .--------.
.---------. / | P2P | | DHT |
| Peer 50 | <---------------- | Client | `--------'
`---------' | (PEX) |
`--------'
.---------. .---------------.
| | | |
| ALTO | (2) Get Endpoint Ranking | P2P Client |
| Server | <----------------------> | (ALTO client) |
| | | | .---------.
`---------' `---------------' <- | P2P |
.---------. / | ^ ^ | Tracker |
| Peer 1 | <-------------- | | \ `---------'
`---------' | (1) Gather Peers
. (3) Connect to | | \
. Selected Peers / .--------. .--------.
.---------. / | P2P | | DHT |
| Peer 50 | <---------------- | Client | `--------'
`---------' | (PEX) |
`--------'
Figure 6: ALTO Client Embedded in P2P Client: Ranking
图6：嵌入P2P客户端的ALTO客户端：排名
Figure 6 shows an example of this scenario. The use case proceeds as follows:
图6显示了此场景的一个示例。用例如下所示：
1. The P2P client discovers peers from sources such as Peer Exchange (PEX) from other P2P clients, Distributed Hash Tables (DHT), and P2P trackers.
1. P2P客户端从其他P2P客户端的对等交换（PEX）、分布式哈希表（DHT）和P2P跟踪器等来源发现对等点。
2. The P2P client queries the ALTO server's ranking service (i.e., the ECS Service), by including the discovered peers as the set of destination endpoints, and indicating the "ordinal" cost mode. The response indicates the ranking of the candidate peers.
2. P2P客户端通过将发现的对等点包括为目标端点集并指示“顺序”成本模式来查询ALTO服务器的排名服务（即ECS服务）。该响应表示候选对等点的排名。
3. The P2P client connects to the peers in the order specified in the ranking.
3. P2P客户端按照排名中指定的顺序连接到对等方。
The discovery mechanism by which an ALTO client locates an appropriate ALTO server is out of scope for this document. This document assumes that an ALTO client can discover an appropriate ALTO server. Once it has done so, the ALTO client may use the information resource directory (see Section 9.2) to locate an information resource with the desired ALTO information.
ALTO客户端用于查找适当ALTO服务器的发现机制不在本文档的范围内。本文档假设ALTO客户端可以发现适当的ALTO服务器。完成后，ALTO客户端可使用信息资源目录（见第9.2节）查找具有所需ALTO信息的信息资源。
In practical deployments, a particular host can be reachable using multiple addresses (e.g., a wireless IPv4 connection, a wireline IPv4 connection, and a wireline IPv6 connection). In general, the particular network path followed when sending packets to the host will depend on the address that is used. Network providers may prefer one path over another. An additional consideration may be how to handle private address spaces (e.g., behind carrier-grade NATs).
在实际部署中，可以使用多个地址（例如，无线IPv4连接、有线IPv4连接和有线IPv6连接）访问特定主机。通常，向主机发送数据包时遵循的特定网络路径将取决于所使用的地址。网络提供商可能更喜欢一条路径而不是另一条路径。另外一个考虑因素可能是如何处理私有地址空间（例如，在载波级NAT后面）。
To support such behavior, this document allows multiple endpoint addresses and address types. With this support, the ALTO Protocol allows an ALTO service provider the flexibility to indicate preferences for paths from an endpoint address of one type to an endpoint address of a different type.
为了支持这种行为，本文档允许使用多个端点地址和地址类型。通过这种支持，ALTO协议允许ALTO服务提供商灵活地指示从一种类型的端点地址到另一种类型的端点地址的路径首选项。
In this day and age of NAT v4<->v4, v4<->v6 [RFC6144], and possibly v6<->v6 [RFC6296], a protocol should strive to be NAT friendly and minimize carrying IP addresses in the payload or provide a mode of operation where the source IP address provides the information necessary to the server.
在NAT v4<->v4、v4<->v6[RFC6144]和可能的v6<->v6[RFC6296]的今天和时代，协议应力求NAT友好，并尽量减少负载中的承载IP地址，或提供源IP地址向服务器提供必要信息的操作模式。
The protocol specified in this document provides a mode of operation where the source network location is computed by the ALTO server (i.e., the Endpoint Cost Service) from the source IP address found in the ALTO client query packets. This is similar to how some P2P trackers (e.g., BitTorrent trackers -- see "Tracker HTTP/HTTPS Protocol" in [BitTorrent]) operate.
本文档中指定的协议提供了一种操作模式，其中ALTO服务器（即端点成本服务）根据ALTO客户端查询数据包中的源IP地址计算源网络位置。这类似于一些P2P跟踪器（例如BitTorrent跟踪器——请参阅[BitTorrent]中的“跟踪器HTTP/HTTPS协议”）的操作方式。
There may be cases in which an ALTO client needs to determine its own IP address, such as when specifying a source endpoint address in the Endpoint Cost Service. It is possible that an ALTO client has multiple network interface addresses, and that some or all of them may require NAT for connectivity to the public Internet.
在某些情况下，ALTO客户端可能需要确定自己的IP地址，例如在端点成本服务中指定源端点地址时。ALTO客户端可能有多个网络接口地址，其中一些或全部可能需要NAT才能连接到公共互联网。
If a public IP address is required for a network interface, the ALTO client SHOULD use the Session Traversal Utilities for NAT (STUN) [RFC5389]. If using this method, the host MUST use the "Binding Request" message and the resulting "XOR-MAPPED-ADDRESS" parameter that is returned in the response. Using STUN requires cooperation from a publicly accessible STUN server. Thus, the ALTO client also requires configuration information that identifies the STUN server, or a domain name that can be used for STUN server discovery. To be selected for this purpose, the STUN server needs to provide the public reflexive transport address of the host.
如果网络接口需要公共IP地址，ALTO客户端应使用NAT（STUN）会话遍历实用程序[RFC5389]。如果使用此方法，主机必须使用“Binding Request”消息和响应中返回的结果“XOR-MAPPED-ADDRESS”参数。使用STUN需要来自可公开访问的STUN服务器的合作。因此，ALTO客户端还需要标识STUN服务器的配置信息，或者可以用于STUN服务器发现的域名。要选择用于此目的，STUN服务器需要提供主机的公共自反传输地址。
ALTO clients should be cognizant that the network path between endpoints can depend on multiple factors, e.g., source address and destination address used for communication. An ALTO server provides information based on endpoint addresses (more generally, network locations), but the mechanisms used for determining existence of connectivity or usage of NAT between endpoints are out of scope of this document.
ALTO客户端应认识到，端点之间的网络路径可能取决于多个因素，例如，用于通信的源地址和目标地址。ALTO服务器提供基于端点地址（更一般地说，是网络位置）的信息，但用于确定端点之间是否存在连接或NAT使用情况的机制不在本文档的范围内。
An ALTO server could make available many properties about endpoints beyond their network location or grouping. For example, connection type, geographical location, and others may be useful to applications. This specification focuses on network location and grouping, but the protocol may be extended to handle other endpoint properties.
ALTO服务器可以在端点的网络位置或分组之外提供有关端点的许多属性。例如，连接类型、地理位置等可能对应用程序有用。该规范侧重于网络位置和分组，但该协议可以扩展以处理其他端点属性。
This document defines registries for application/alto-* media types, ALTO cost metrics, ALTO endpoint property types, ALTO address types, and ALTO error codes. Initial values for the registries and the process of future assignments are given below.
本文档定义了应用程序/alto-*媒体类型、alto成本指标、alto端点属性类型、alto地址类型和alto错误代码的注册表。登记处的初始值和未来转让过程如下所示。
This document registers multiple media types, listed in Table 2.
本文件登记了多种介质类型，如表2所示。
+-------------+------------------------------+-------------------+
| Type | Subtype | Specification |
+-------------+------------------------------+-------------------+
| application | alto-directory+json | Section 9.2.1 |
| application | alto-networkmap+json | Section 11.2.1.1 |
| application | alto-networkmapfilter+json | Section 11.3.1.1 |
| application | alto-costmap+json | Section 11.2.3.1 |
| application | alto-costmapfilter+json | Section 11.3.2.1 |
| application | alto-endpointprop+json | Section 11.4.1.1 |
| application | alto-endpointpropparams+json | Section 11.4.1.1 |
| application | alto-endpointcost+json | Section 11.5.1.1 |
| application | alto-endpointcostparams+json | Section 11.5.1.1 |
| application | alto-error+json | Section 8.5.1 |
+-------------+------------------------------+-------------------+
+-------------+------------------------------+-------------------+
| Type | Subtype | Specification |
+-------------+------------------------------+-------------------+
| application | alto-directory+json | Section 9.2.1 |
| application | alto-networkmap+json | Section 11.2.1.1 |
| application | alto-networkmapfilter+json | Section 11.3.1.1 |
| application | alto-costmap+json | Section 11.2.3.1 |
| application | alto-costmapfilter+json | Section 11.3.2.1 |
| application | alto-endpointprop+json | Section 11.4.1.1 |
| application | alto-endpointpropparams+json | Section 11.4.1.1 |
| application | alto-endpointcost+json | Section 11.5.1.1 |
| application | alto-endpointcostparams+json | Section 11.5.1.1 |
| application | alto-error+json | Section 8.5.1 |
+-------------+------------------------------+-------------------+
Table 2: ALTO Protocol Media Types
表2:ALTO协议介质类型
Type name: application
类型名称：应用程序
Subtype name: This documents registers multiple subtypes, as listed in Table 2.
子类型名称：此文档注册多个子类型，如表2所示。
Required parameters: n/a
所需参数：不适用
Optional parameters: n/a
可选参数：不适用
Encoding considerations: Encoding considerations are identical to those specified for the "application/json" media type. See [RFC7159].
编码注意事项：编码注意事项与为“application/json”媒体类型指定的注意事项相同。见[RFC7159]。
Security considerations: Security considerations relating to the generation and consumption of ALTO Protocol messages are discussed in Section 15.
安全注意事项：第15节讨论了与ALTO协议消息的生成和使用相关的安全注意事项。
Interoperability considerations: This document specifies format of conforming messages and the interpretation thereof.
互操作性注意事项：本文件规定了一致性消息的格式及其解释。
Published specification: This document is the specification for these media types; see Table 2 for the section documenting each media type.
已发布规范：本文件是这些媒体类型的规范；有关记录每种介质类型的部分，请参见表2。
Applications that use this media type: ALTO servers and ALTO clients either stand alone or are embedded within other applications.
使用此媒体类型的应用程序：ALTO服务器和ALTO客户端可以独立运行，也可以嵌入到其他应用程序中。
Additional information:
其他信息：
Magic number(s): n/a
Magic number(s): n/a
File extension(s): This document uses the mime type to refer to protocol messages and thus does not require a file extension.
文件扩展名：此文档使用mime类型引用协议消息，因此不需要文件扩展名。
Macintosh file type code(s): n/a
Macintosh file type code(s): n/a
Person & email address to contact for further information: See Authors' Addresses section.
联系人和电子邮件地址以了解更多信息：请参阅作者地址部分。
Intended usage: COMMON
预期用途：普通
Restrictions on usage: n/a
使用限制：不适用
Author: See Authors' Addresses section.
作者：参见作者地址部分。
Change controller: Internet Engineering Task Force (mailto:iesg@ietf.org).
变更控制员：互联网工程任务组（邮寄：iesg@ietf.org).
IANA has created and now maintains the "ALTO Cost Metric Registry", listed in Table 3.
IANA已经创建并维护了表3中所列的“ALTO成本计量注册表”。
+-------------+---------------------+
| Identifier | Intended Semantics |
+-------------+---------------------+
| routingcost | See Section 6.1.1.1 |
| priv: | Private use |
+-------------+---------------------+
+-------------+---------------------+
| Identifier | Intended Semantics |
+-------------+---------------------+
| routingcost | See Section 6.1.1.1 |
| priv: | Private use |
+-------------+---------------------+
Table 3: ALTO Cost Metrics
表3：ALTO成本指标
This registry serves two purposes. First, it ensures uniqueness of identifiers referring to ALTO cost metrics. Second, it provides references to particular semantics of allocated cost metrics to be applied by both ALTO servers and applications utilizing ALTO clients.
这个登记处有两个目的。首先，它确保参考ALTO成本指标的标识符的唯一性。其次，它提供了对ALTO服务器和使用ALTO客户端的应用程序应用的分配成本度量的特定语义的引用。
New ALTO cost metrics are assigned after IETF Review [RFC5226] to ensure that proper documentation regarding ALTO cost metric semantics and security considerations has been provided. The RFCs documenting the new metrics should be detailed enough to provide guidance to both ALTO service providers and applications utilizing ALTO clients as to how values of the registered ALTO cost metric should be interpreted. Updates and deletions of ALTO cost metrics follow the same procedure.
在IETF审查[RFC5226]后分配新的ALTO成本指标，以确保提供了关于ALTO成本指标语义和安全注意事项的适当文档。记录新指标的RFC应足够详细，以便向ALTO服务提供商和使用ALTO客户的应用程序提供有关如何解释已注册ALTO成本指标值的指导。ALTO成本指标的更新和删除遵循相同的程序。
Registered ALTO cost metric identifiers MUST conform to the syntactical requirements specified in Section 10.6. Identifiers are to be recorded and displayed as strings.
注册的ALTO成本指标标识符必须符合第10.6节规定的语法要求。标识符将被记录并显示为字符串。
As specified in Section 10.6, identifiers prefixed with "priv:" are reserved for Private Use.
如第10.6节所述，前缀为“priv:”的标识符保留供私人使用。
Requests to add a new value to the registry MUST include the following information:
向注册表添加新值的请求必须包括以下信息：
o Identifier: The name of the desired ALTO cost metric.
o 标识符：所需ALTO成本指标的名称。
o Intended Semantics: ALTO costs carry with them semantics to guide their usage by ALTO clients. For example, if a value refers to a measurement, the measurement units must be documented. For proper implementation of the ordinal cost mode (e.g., by a third-party service), it should be documented whether higher or lower values of the cost are more preferred.
o 预期语义：ALTO成本附带语义，用于指导ALTO客户使用它们。例如，如果某个值涉及测量值，则必须记录测量单位。为了正确实施顺序成本模式（例如，通过第三方服务），应记录成本的高值或低值是否更可取。
o Security Considerations: ALTO costs expose information to ALTO clients. As such, proper usage of a particular cost metric may require certain information to be exposed by an ALTO service provider. Since network information is frequently regarded as proprietary or confidential, ALTO service providers should be made aware of the security ramifications related to usage of a cost metric.
o 安全注意事项：ALTO成本向ALTO客户端公开信息。因此，正确使用特定成本指标可能需要ALTO服务提供商公开某些信息。由于网络信息通常被视为专有或机密信息，ALTO服务提供商应了解与使用成本指标相关的安全后果。
This specification requests registration of the identifier "routingcost". Semantics for the this cost metric are documented in Section 6.1.1.1, and security considerations are documented in Section 15.3.
本规范要求注册标识符“routingcost”。第6.1.1.1节记录了该成本指标的语义，第15.3节记录了安全注意事项。
IANA has created and now maintains the "ALTO Endpoint Property Type Registry", listed in Table 4.
IANA已经创建并维护了“ALTO端点属性类型注册表”，如表4所示。
+------------+--------------------+
| Identifier | Intended Semantics |
+------------+--------------------+
| pid | See Section 7.1.1 |
| priv: | Private use |
+------------+--------------------+
+------------+--------------------+
| Identifier | Intended Semantics |
+------------+--------------------+
| pid | See Section 7.1.1 |
| priv: | Private use |
+------------+--------------------+
Table 4: ALTO Endpoint Property Types
表4：ALTO端点属性类型
The maintenance of this registry is similar to that of the preceding ALTO cost metrics. That is, the registry is maintained by IANA, subject to the description in Section 10.8.2.
该注册表的维护与之前的ALTO成本指标类似。也就是说，根据第10.8.2节的说明，注册中心由IANA维护。
New endpoint property types are assigned after IETF Review [RFC5226] to ensure that proper documentation regarding ALTO endpoint property type semantics and security considerations has been provided. Updates and deletions of ALTO endpoint property types follow the same procedure.
在IETF审查[RFC5226]后分配新的端点属性类型，以确保提供了关于ALTO端点属性类型语义和安全注意事项的适当文档。ALTO端点属性类型的更新和删除遵循相同的过程。
Registered ALTO endpoint property type identifiers MUST conform to the syntactical requirements specified in Section 10.8.1. Identifiers are to be recorded and displayed as strings.
注册的ALTO端点属性类型标识符必须符合第10.8.1节中规定的语法要求。标识符将被记录并显示为字符串。
As specified in Section 10.8.1, identifiers prefixed with "priv:" are reserved for Private Use.
如第10.8.1节所述，前缀为“priv:”的标识符保留供私人使用。
Requests to add a new value to the registry MUST include the following information:
向注册表添加新值的请求必须包括以下信息：
o Identifier: The name of the desired ALTO endpoint property type.
o 标识符：所需ALTO端点属性类型的名称。
o Intended Semantics: ALTO endpoint properties carry with them semantics to guide their usage by ALTO clients. Hence, a document defining a new type should provide guidance to both ALTO service providers and applications utilizing ALTO clients as to how values of the registered ALTO endpoint property should be interpreted. For example, if a value refers to a measurement, the measurement units must be documented.
o 预期语义：ALTO端点属性附带语义以指导ALTO客户端使用它们。因此，定义新类型的文档应向ALTO服务提供商和使用ALTO客户端的应用程序提供有关如何解释已注册ALTO endpoint属性值的指导。例如，如果某个值涉及测量值，则必须记录测量单位。
o Security Considerations: ALTO endpoint properties expose information to ALTO clients. ALTO service providers should be made aware of the security ramifications related to the exposure of an endpoint property.
o 安全注意事项：ALTO端点属性向ALTO客户端公开信息。ALTO服务提供商应了解与端点属性暴露相关的安全后果。
In particular, the request should discuss the sensitivity of the information, and why such sensitive information is required for ALTO-based operations. It may recommend that ISP provide mechanisms for users to grant or deny consent to such information sharing. Limitation to a trust domain being a type of consent bounding.
特别是，请求应讨论信息的敏感性，以及为什么基于ALTO的运营需要此类敏感信息。它可能会建议ISP为用户提供允许或拒绝此类信息共享的机制。对作为一种同意边界的信任域的限制。
A request defining new endpoint properties should focus on exposing attributes of endpoints that are related to the goals of ALTO -- optimization of application-layer traffic -- as opposed to more general properties of endpoints. Maintaining this focus on technical, network-layer data will also help extension developers avoid the privacy concerns associated with publishing information about endpoints. For example:
定义新端点属性的请求应该关注于公开与ALTO目标相关的端点属性——应用层流量的优化——而不是端点的更一般属性。保持对技术、网络层数据的关注也将有助于扩展开发人员避免与发布端点信息相关的隐私问题。例如：
o An extension to indicate the capacity of a server would likely be appropriate, since server capacities can be used by a client to choose between multiple equivalent servers. In addition, these properties are unlikely to be viewed as private information.
o 指示服务器容量的扩展可能是合适的，因为客户端可以使用服务器容量在多个等效服务器之间进行选择。此外，这些属性不太可能被视为私人信息。
o An extension to indicate the geolocation of endpoints might be appropriate. In some cases, a certain level of geolocation (e.g., to the country level) can be useful for selecting content sources. More precise geolocation, however, is not relevant to content delivery, and is typically considered private.
o 可以使用一个扩展来指示端点的地理位置。在某些情况下，特定级别的地理位置（例如，国家级别）可用于选择内容源。然而，更精确的地理位置与内容交付无关，通常被认为是私有的。
o An extension indicating demographic attributes of the owner of an endpoint (e.g., age, sex, income) would not be appropriate, because these attributes are not related to delivery optimization, and because they are clearly private data.
o 表示终点所有者的人口统计属性（例如，年龄、性别、收入）的扩展不合适，因为这些属性与交付优化无关，而且它们显然是私有数据。
This specification requests registration of the identifier "pid". Semantics for this property are documented in Section 7.1.1, and security considerations are documented in Section 15.4.
本规范要求注册标识符“pid”。第7.1.1节记录了该属性的语义，第15.4节记录了安全注意事项。
IANA has created and now maintains the "ALTO Address Type Registry", listed in Table 5.
IANA已经创建并维护了“ALTO地址类型注册表”，如表5所示。
+------------+-----------------+-----------------+------------------+
| Identifier | Address | Prefix Encoding | Mapping to/from |
| | Encoding | | IPv4/v6 |
+------------+-----------------+-----------------+------------------+
| ipv4 | See Section | See Section | Direct mapping |
| | 10.4.3 | 10.4.4 | to IPv4 |
| ipv6 | See Section | See Section | Direct mapping |
| | 10.4.3 | 10.4.4 | to IPv6 |
+------------+-----------------+-----------------+------------------+
+------------+-----------------+-----------------+------------------+
| Identifier | Address | Prefix Encoding | Mapping to/from |
| | Encoding | | IPv4/v6 |
+------------+-----------------+-----------------+------------------+
| ipv4 | See Section | See Section | Direct mapping |
| | 10.4.3 | 10.4.4 | to IPv4 |
| ipv6 | See Section | See Section | Direct mapping |
| | 10.4.3 | 10.4.4 | to IPv6 |
+------------+-----------------+-----------------+------------------+
Table 5: ALTO Address Types
表5：ALTO地址类型
This registry serves two purposes. First, it ensures uniqueness of identifiers referring to ALTO address types. Second, it states the requirements for allocated address type identifiers.
这个登记处有两个目的。首先，它确保引用ALTO地址类型的标识符的唯一性。其次，它说明了对分配的地址类型标识符的要求。
New ALTO address types are assigned after IETF Review [RFC5226] to ensure that proper documentation regarding the new ALTO address types and their security considerations has been provided. RFCs defining new address types should indicate how an address of a registered type is encoded as an EndpointAddr and, if possible, a compact method (e.g., IPv4 and IPv6 prefixes) for encoding a set of addresses as an EndpointPrefix. Updates and deletions of ALTO address types follow the same procedure.
IETF审查[RFC5226]后分配新的ALTO地址类型，以确保提供了关于新ALTO地址类型及其安全注意事项的适当文件。定义新地址类型的RFC应指明如何将注册类型的地址编码为EndpointAddr，如果可能，还应指明将一组地址编码为EndpointPrefix的压缩方法（例如IPv4和IPv6前缀）。ALTO地址类型的更新和删除遵循相同的过程。
Registered ALTO address type identifiers MUST conform to the syntactical requirements specified in Section 10.4.2. Identifiers are to be recorded and displayed as strings.
注册的ALTO地址类型标识符必须符合第10.4.2节规定的语法要求。标识符将被记录并显示为字符串。
Requests to add a new value to the registry MUST include the following information:
向注册表添加新值的请求必须包括以下信息：
o Identifier: The name of the desired ALTO address type.
o 标识符：所需ALTO地址类型的名称。
o Endpoint Address Encoding: The procedure for encoding an address of the registered type as an EndpointAddr (see Section 10.4.3).
o 端点地址编码：将注册类型的地址编码为EndpointAddr的过程（参见第10.4.3节）。
o Endpoint Prefix Encoding: The procedure for encoding a set of addresses of the registered type as an EndpointPrefix (see Section 10.4.4). If no such compact encoding is available, the same encoding used for a singular address may be used. In such a case, it must be documented that sets of addresses of this type always have exactly one element.
o 端点前缀编码：将注册类型的一组地址编码为端点前缀的过程（参见第10.4.4节）。如果没有这样的压缩编码可用，则可以使用用于单数地址的相同编码。在这种情况下，必须记录这种类型的地址集始终只有一个元素。
o Mapping to/from IPv4/IPv6 Addresses: If possible, a mechanism to map addresses of the registered type to and from IPv4 or IPv6 addresses should be specified.
o 映射到IPv4/IPv6地址/从IPv4/IPv6地址映射：如果可能，应指定将注册类型的地址映射到IPv4或IPv6地址的机制。
o Security Considerations: In some usage scenarios, endpoint addresses carried in ALTO Protocol messages may reveal information about an ALTO client or an ALTO service provider. Applications and ALTO service providers using addresses of the registered type should be made aware of how (or if) the addressing scheme relates to private information and network proximity.
o 安全注意事项：在某些使用场景中，ALTO协议消息中包含的端点地址可能会显示有关ALTO客户端或ALTO服务提供商的信息。使用注册类型地址的应用程序和ALTO服务提供商应了解寻址方案与私人信息和网络邻近性的关系。
This specification requests registration of the identifiers "ipv4" and "ipv6", as shown in Table 5.
本规范要求注册标识符“ipv4”和“ipv6”，如表5所示。
IANA has created and now maintains the "ALTO Error Code Registry". Initial values are listed in Table 1, and recommended usage of the error codes is specified in Section 8.5.2.
IANA已经创建并维护了“ALTO错误代码注册表”。表1列出了初始值，第8.5.2节规定了错误代码的建议用法。
Although the error codes defined in Table 1 are already quite complete, future extensions may define new error codes. The "ALTO Error Code Registry" ensures the uniqueness of error codes when new error codes are added.
虽然表1中定义的错误代码已经相当完整，但未来的扩展可能会定义新的错误代码。“ALTO错误代码注册表”确保添加新错误代码时错误代码的唯一性。
New ALTO error codes are assigned after IETF Review [RFC5226] to ensure that proper documentation regarding the new ALTO error codes and their usage has been provided.
IETF审查[RFC5226]后分配新的ALTO错误代码，以确保提供了关于新ALTO错误代码及其使用的适当文件。
A request to add a new ALTO error code to the registry MUST include the following information:
向注册表添加新ALTO错误代码的请求必须包括以下信息：
o Error Code: A string starting with E_ to indicate the error.
o 错误代码：以E_u开头的字符串，用于指示错误。
o Intended Usage: ALTO error codes carry with them semantics to guide their usage by ALTO servers and clients. In particular, if a new error code indicates conditions that overlap with those of an existing ALTO error code, recommended usage of the new error code should be specified.
o 预期用途：ALTO错误代码附带语义，用于指导ALTO服务器和客户端使用它们。特别是，如果新错误代码指示与现有ALTO错误代码重叠的情况，则应指定新错误代码的建议用法。
Some environments and use cases of ALTO require consideration of security attacks on ALTO servers and clients. In order to support those environments interoperably, the ALTO requirements document [RFC6708] outlines minimum-to-implement authentication and other security requirements. This document considers the following threats and protection strategies.
ALTO的某些环境和用例需要考虑对ALTO服务器和客户端的安全攻击。为了互操作地支持这些环境，ALTO需求文档[RFC6708]概述了实现身份验证和其他安全需求的最低要求。本文件考虑了以下威胁和保护策略。
An attacker may want to provide false or modified ALTO information resources or an information resource directory to ALTO clients to achieve certain malicious goals. As an example, an attacker may provide false endpoint properties. For example, suppose that a network supports an endpoint property named "hasQuota", which reports whether an endpoint has usage quota. An attacker may want to generate a false reply to lead to unexpected charges to the endpoint. An attack may also want to provide a false cost map. For example, by faking a cost map that highly prefers a small address range or a single address, the attacker may be able to turn a distributed application into a Distributed-Denial-of-Service (DDoS) tool.
攻击者可能希望向ALTO客户端提供虚假或修改的ALTO信息资源或信息资源目录，以实现某些恶意目标。例如，攻击者可能提供虚假的端点属性。例如，假设网络支持名为“hasQuota”的端点属性，该属性报告端点是否具有使用配额。攻击者可能希望生成错误回复，从而导致对端点的意外费用。攻击可能还希望提供错误的成本图。例如，通过伪造高度偏好小地址范围或单个地址的成本图，攻击者可能能够将分布式应用程序转化为分布式拒绝服务（DDoS）工具。
Depending on the network scenario, an attacker can attack authenticity and integrity of ALTO information resources using various techniques, including, but not limited to, sending forged DHCP replies in an Ethernet, DNS poisoning, and installing a transparent HTTP proxy that does some modifications.
根据网络场景，攻击者可以使用各种技术攻击ALTO信息资源的真实性和完整性，包括但不限于在以太网中发送伪造的DHCP回复、DNS中毒以及安装进行某些修改的透明HTTP代理。
ALTO protects the authenticity and integrity of ALTO information (both information directory and individual information resources) by leveraging the authenticity and integrity mechanisms in TLS (see Section 8.3.5).
ALTO通过利用TLS中的真实性和完整性机制（见第8.3.5节），保护ALTO信息（信息目录和个人信息资源）的真实性和完整性。
ALTO service providers who request server certificates and certification authorities who issue ALTO-specific certificates SHOULD consider the recommendations and guidelines defined in [RFC6125].
请求阿尔托证书和颁发阿尔托特定证书的证书颁发机构的服务提供商应该考虑在[RCF6125]中定义的建议和指南。
Software engineers developing and service providers deploying ALTO should make themselves familiar with possibly updated standards documents as well as up-to-date Best Current Practices on configuring HTTP over TLS.
开发和部署ALTO的软件工程师和服务提供商应熟悉可能更新的标准文档，以及关于通过TLS配置HTTP的最新最佳实践。
The protection of HTTP over TLS for ALTO depends on that the domain name in the URI for the information resources is not comprised. This will depend on the protection implemented by service discovery.
ALTO对HTTP over TLS的保护取决于信息资源URI中的域名不包含在内。这将取决于服务发现实现的保护。
A deployment scenario may require redistribution of ALTO information to improve scalability. When authenticity and integrity of ALTO information are still required, then ALTO clients obtaining ALTO information through redistribution must be able to validate the
部署场景可能需要重新分发ALTO信息以提高可伸缩性。当仍然需要ALTO信息的真实性和完整性时，通过重新分发获得ALTO信息的ALTO客户必须能够验证
received ALTO information. Support for this validation is not provided in this document, but it may be provided by extension documents.
收到中音信息。本文档中未提供对此验证的支持，但可以通过扩展文档提供。
15.2. Potential Undesirable Guidance from Authenticated ALTO Information
15.2. 来自已认证ALTO信息的潜在不良指导
The ALTO services make it possible for an ALTO service provider to influence the behavior of network applications. An ALTO service provider may be hostile to some applications and, hence, try to use ALTO information resources to achieve certain goals [RFC5693]:
ALTO服务使ALTO服务提供商能够影响网络应用程序的行为。ALTO服务提供商可能对某些应用程序怀有敌意，因此，尝试使用ALTO信息资源来实现某些目标[RFC5693]：
...redirecting applications to corrupted mediators providing malicious content, or applying policies in computing cost maps based on criteria other than network efficiency.
…将应用程序重定向到提供恶意内容的损坏中介，或基于网络效率以外的标准在计算成本映射中应用策略。
See [ALTO-DEPLOYMENT] for additional discussions on faked ALTO guidance.
请参阅[ALTO-DEPLOYMENT]，了解有关伪造ALTO指南的更多讨论。
A related scenario is that an ALTO server could unintentionally give "bad" guidance. For example, if many ALTO clients follow the cost map or the Endpoint Cost Service guidance without doing additional sanity checks or adaptation, more preferable hosts and/or links could get overloaded while less preferable ones remain idle; see AR-14 of [RFC6708] for related application considerations.
一个相关的场景是ALTO服务器可能会无意中给出“错误”的指导。例如，如果许多ALTO客户端遵循成本图或端点成本服务指南，而不进行额外的健全性检查或调整，则更可取的主机和/或链路可能过载，而不可取的主机和/或链路则保持空闲；有关应用注意事项，请参见[RFC6708]中的AR-14。
To protect applications from undesirable ALTO information resources, it is important to note that there is no protocol mechanism to require conforming behaviors on how applications use ALTO information resources. An application using ALTO may consider including a mechanism to detect misleading or undesirable results from using ALTO information resources. For example, if throughput measurements do not show "better-than-random" results when using an ALTO cost map to select resource providers, the application may want to disable ALTO usage or switch to an external ALTO server provided by an "independent organization" (see AR-20 and AR-21 in [RFC6708]). If the first ALTO server is provided by the access network service provider and the access network service provider tries to redirect access to the external ALTO server back to the provider's ALTO server or try to tamper with the responses, the preceding authentication and integrity protection can detect such a behavior.
为了保护应用程序不受不需要的ALTO信息资源的影响，需要注意的是，没有协议机制要求应用程序如何使用ALTO信息资源的一致性行为。使用阿尔托的应用程序可以考虑包括使用阿尔托信息资源来检测误导或不希望的结果的机制。例如，如果在使用ALTO成本图选择资源提供商时，吞吐量测量没有显示“优于随机”的结果，则应用程序可能希望禁用ALTO使用或切换到“独立组织”提供的外部ALTO服务器（参见[RFC6708]中的AR-20和AR-21）。如果第一个ALTO服务器由接入网络服务提供商提供，并且接入网络服务提供商尝试将对外部ALTO服务器的访问重定向回提供商的ALTO服务器或尝试篡改响应，则前面的身份验证和完整性保护可以检测到此类行为。
In many cases, although ALTO information resources may be regarded as non-confidential information, there are deployment cases in which ALTO information resources can be sensitive information that can pose risks if exposed to unauthorized parties. This document discusses the risks and protection strategies for such deployment scenarios.
在许多情况下，尽管ALTO信息资源可能被视为非机密信息，但在某些部署情况下，ALTO信息资源可能是敏感信息，如果暴露给未经授权的方，可能会带来风险。本文档讨论了此类部署场景的风险和保护策略。
For example, an attacker may infer details regarding the topology, status, and operational policies of a network through its ALTO network and cost maps. As a result, a sophisticated attacker may be able to infer more fine-grained topology information than an ISP hosting an ALTO server intends to disclose. The attacker can leverage the information to mount effective attacks such as focusing on high-cost links.
例如，攻击者可以通过其ALTO网络和成本图推断有关网络拓扑、状态和操作策略的详细信息。因此，与托管ALTO服务器的ISP打算披露的信息相比，老练的攻击者可能能够推断出更多细粒度的拓扑信息。攻击者可以利用这些信息发动有效的攻击，例如重点攻击高成本链接。
Revealing some endpoint properties may also reveal additional information than the provider intended. For example, when adding the line bitrate as one endpoint property, such information may be potentially linked to the income of the habitants at the network location of an endpoint.
显示某些端点属性也可能会显示超出提供程序预期的其他信息。例如，当添加线比特率作为一个端点属性时，此类信息可能与端点的网络位置处的居住者的收入相关联。
In Section 5.2.1 of [RFC6708], three types of risks associated with the confidentiality of ALTO information resources are identified: risk type (1) Excess disclosure of the ALTO service provider's data to an authorized ALTO client; risk type (2) Disclosure of the ALTO service provider's data (e.g., network topology information or endpoint addresses) to an unauthorized third party; and risk type (3) Excess retrieval of the ALTO service provider's data by collaborating ALTO clients. [ALTO-DEPLOYMENT] also discusses information leakage from ALTO.
在[RFC6708]第5.2.1节中，确定了与ALTO信息资源保密性相关的三类风险：风险类型（1）向授权ALTO客户过度披露ALTO服务提供商的数据；风险类型（2）向未经授权的第三方披露ALTO服务提供商的数据（例如，网络拓扑信息或端点地址）；和风险类型（3）合作ALTO客户过度检索ALTO服务提供商的数据。[ALTO-DEPLOYMENT]还讨论了来自ALTO的信息泄漏。
To address risk types (1) and (3), the provider of an ALTO server must be cognizant that the network topology and provisioning information provided through ALTO may lead to attacks. ALTO does not require any particular level of details of information disclosure; hence, the provider should evaluate how much information is revealed and the associated risks.
为了解决风险类型（1）和（3），ALTO服务器的提供商必须认识到通过ALTO提供的网络拓扑和配置信息可能导致攻击。ALTO不要求任何特定级别的信息披露细节；因此，供应商应评估披露了多少信息以及相关风险。
To address risk type (2), the ALTO Protocol needs confidentiality. Since ALTO requires that HTTP over TLS must be supported, the confidentiality mechanism is provided by HTTP over TLS.
为了解决风险类型（2），ALTO协议需要保密。由于ALTO要求必须支持HTTP over TLS，因此机密性机制由HTTP over TLS提供。
For deployment scenarios where client authentication is desired to address risk type (2), ALTO requires that HTTP Digestion Authentication is supported to achieve ALTO client authentication to limit the number of parties with whom ALTO information is directly shared. TLS client authentication may also be supported. Depending on the use case and scenario, an ALTO server may apply other access control techniques to restrict access to its services. Access control can also help to prevent Denial-of-Service attacks by arbitrary hosts from the Internet. See [ALTO-DEPLOYMENT] for a more detailed discussion on this issue.
对于需要客户端身份验证来解决风险类型（2）的部署场景，ALTO要求支持HTTP身份验证来实现ALTO客户端身份验证，以限制与ALTO信息直接共享的参与方的数量。也可以支持TLS客户端身份验证。根据用例和场景，ALTO服务器可以应用其他访问控制技术来限制对其服务的访问。访问控制还有助于防止来自Internet的任意主机的拒绝服务攻击。有关此问题的更详细讨论，请参阅[ALTO-DEPLOYMENT]。
See Section 14.3 on guidelines when registering endpoint properties to protect endpoint privacy.
有关注册端点属性以保护端点隐私的指南，请参见第14.3节。
ALTO information providers should be cognizant that encryption only protects ALTO information until it is decrypted by the intended ALTO client. Digital Rights Management (DRM) techniques and legal agreements protecting ALTO information are outside of the scope of this document.
ALTO信息提供商应认识到，加密仅在ALTO信息被预期的ALTO客户端解密之前保护ALTO信息。保护ALTO信息的数字版权管理（DRM）技术和法律协议不在本文档范围内。
The ALTO Protocol provides mechanisms in which the ALTO client serving a user can send messages containing network location identifiers (IP addresses or fine-grained PIDs) to the ALTO server. This is particularly true for the Endpoint Property, the Endpoint Cost, and the fine-grained Filtered Map services. The ALTO server or a third party who is able to intercept such messages can store and process obtained information in order to analyze user behaviors and communication patterns. The analysis may correlate information collected from multiple clients to deduce additional application/ content information. Such analysis can lead to privacy risks. For a more comprehensive classification of related risk scenarios, see cases 4, 5, and 6 in [RFC6708], Section 5.2.
ALTO协议提供了一种机制，在该机制中，服务于用户的ALTO客户端可以向ALTO服务器发送包含网络位置标识符（IP地址或细粒度PID）的消息。这对于端点属性、端点成本和细粒度过滤映射服务尤其如此。ALTO服务器或能够拦截此类消息的第三方可以存储和处理获得的信息，以便分析用户行为和通信模式。该分析可以关联从多个客户端收集的信息，以推断附加的应用程序/内容信息。这种分析可能导致隐私风险。有关相关风险情景的更全面分类，请参见[RFC6708]第5.2节中的案例4、5和6。
To protect user privacy, an ALTO client should be cognizant about potential ALTO server tracking through client queries, e.g., by using HTTP cookies. The ALTO Protocol as defined by this document does not rely on HTTP cookies. ALTO clients MAY decide not to return cookies received from the server, in order to make tracking more difficult. However, this might break protocol extensions that are beyond the scope of this document.
为了保护用户隐私，ALTO客户端应了解通过客户端查询（例如，通过使用HTTP cookie）进行的潜在ALTO服务器跟踪。本文档定义的ALTO协议不依赖HTTP cookies。ALTO客户端可能会决定不返回从服务器收到的Cookie，以使跟踪更加困难。但是，这可能会破坏超出本文档范围的协议扩展。
An ALTO client may consider the possibility of relying only on ALTO network maps for PIDs and cost maps amongst PIDs to avoid passing IP addresses of other endpoints (e.g., peers) to the ALTO server. When specific IP addresses are needed (e.g., when using the Endpoint Cost Service), an ALTO client SHOULD minimize the amount of information sent in IP addresses. For example, the ALTO client may consider obfuscation techniques such as specifying a broader address range (i.e., a shorter prefix length) or by zeroing out or randomizing the last few bits of IP addresses. Note that obfuscation may yield less accurate results.
阿尔托客户端可以考虑在PID之间仅依赖阿尔托网络地图来进行PID和成本映射，以避免将其他端点（例如，对等点）的IP地址传递到阿尔托服务器。当需要特定的IP地址时（例如，在使用端点成本服务时），ALTO客户端应尽量减少在IP地址中发送的信息量。例如，阿尔托客户端可以考虑混淆技术，例如指定更广泛的地址范围（即，较短的前缀长度），或者通过对IP地址的最后几位进行零化或随机化。请注意，模糊处理可能会产生不太准确的结果。
An attacker may want to disable the ALTO services of a network as a way to disable network guidance to large scale applications. In particular, queries that can be generated with low effort but result in expensive workloads at the ALTO server could be exploited for Denial-of-Service attacks. For instance, a simple ALTO query with n source network locations and m destination network locations can be generated fairly easily but results in the computation of n*m path costs between pairs by the ALTO server (see Section 5.2).
攻击者可能希望禁用网络的ALTO服务，以此禁用对大规模应用程序的网络引导。特别是，可以轻松生成但在ALTO服务器上产生昂贵工作负载的查询可能会被用于拒绝服务攻击。例如，可以相当容易地生成具有n个源网络位置和m个目标网络位置的简单ALTO查询，但会导致ALTO服务器计算对之间的n*m路径成本（参见第5.2节）。
The ALTO service provider should be cognizant of the workload at the ALTO server generated by certain ALTO Queries, such as certain queries to the Map Service, the Map-Filtering Service and the Endpoint Cost (Ranking) Service. One way to limit Denial-of-Service attacks is to employ access control to the ALTO server. The ALTO server can also indicate overload and reject repeated requests that can cause availability problems. More advanced protection schemes such as computational puzzles [SIP] may be considered in an extension document.
ALTO服务提供商应了解ALTO服务器上由某些ALTO查询生成的工作负载，例如对地图服务、地图过滤服务和端点成本（排名）服务的某些查询。限制拒绝服务攻击的一种方法是对ALTO服务器进行访问控制。ALTO服务器还可以指示过载并拒绝可能导致可用性问题的重复请求。可以在扩展文档中考虑更高级的保护方案，例如计算谜题[SIP]。
An ALTO service provider should also leverage the fact that the Map Service allows ALTO servers to pre-generate maps that can be distributed to many ALTO clients.
ALTO服务提供商还应利用地图服务允许ALTO服务器预生成可分发给许多ALTO客户端的地图这一事实。
This section details operations and management considerations based on existing deployments and discussions during protocol development. It also indicates where extension documents are expected to provide appropriate functionality discussed in [RFC5706] as additional deployment experience becomes available.
本节根据协议开发期间的现有部署和讨论，详细介绍操作和管理注意事项。它还指出了随着更多部署经验的增加，[RFC5706]中讨论的扩展文档将提供适当功能的地方。
The ALTO Protocol is based on HTTP. Thus, configuring an ALTO server may require configuring the underlying HTTP server implementation to define appropriate security policies, caching policies, performance settings, etc.
ALTO协议基于HTTP。因此，配置ALTO服务器可能需要配置底层HTTP服务器实现以定义适当的安全策略、缓存策略、性能设置等。
Additionally, an ALTO service provider will need to configure the ALTO information to be provided by the ALTO server. The granularity of the topological map and the cost maps is left to the specific policies of the ALTO service provider. However, a reasonable default may include two PIDs, one to hold the endpoints in the provider's network and the second PID to represent full IPv4 and IPv6 reachability (see Section 11.2.2), with the cost between each source/ destination PID set to 1. Another operational issue that the ALTO service provider needs to consider is that the filtering service can degenerate into a full map service when the filtering input is empty. Although this choice as the degeneration behavior provides continuity, the computational and network load of serving full maps to a large number of ALTO clients should be considered.
此外，ALTO服务提供商需要配置ALTO服务器提供的ALTO信息。拓扑图和成本图的粒度由ALTO服务提供商的特定策略决定。但是，合理的默认值可能包括两个PID，一个用于保存提供商网络中的端点，第二个PID用于表示完整的IPv4和IPv6可达性（请参见第11.2.2节），每个源/目标PID之间的成本设置为1。阿尔托服务提供商需要考虑的另一个操作问题是，当过滤输入为空时，过滤服务可以退化为全地图服务。尽管这种选择作为退化行为提供了连续性，但应考虑为大量ALTO客户端提供完整地图的计算和网络负载。
Implementers employing an ALTO client should attempt to automatically discover an appropriate ALTO server. Manual configuration of the ALTO server location may be used where automatic discovery is not appropriate. Methods for automatic discovery and manual configuration are discussed in [ALTO-SERVER-DISC].
使用ALTO客户端的实现者应该尝试自动发现适当的ALTO服务器。在不适合自动查找的情况下，可以使用ALTO服务器位置的手动配置。[ALTO-SERVER-DISC]中讨论了自动发现和手动配置的方法。
Specifications for underlying protocols (e.g., TCP, HTTP, TLS) should be consulted for their available settings and proposed default configurations.
应参考底层协议（如TCP、HTTP、TLS）的规范，了解其可用设置和建议的默认配置。
This document does not detail a migration path for ALTO servers since there is no previous standard protocol providing the similar functionality.
本文档没有详细说明ALTO服务器的迁移路径，因为以前没有提供类似功能的标准协议。
There are existing applications making use of network information discovered from other entities such as whois, geo-location databases, or round-trip time measurements, etc. Such applications should consider using ALTO as an additional source of information; ALTO need not be the sole source of network information.
现有的应用程序利用从其他实体发现的网络信息，如WHOIS、地理位置数据库或往返时间测量等。这样的应用应该考虑使用ALTO作为附加信息源；ALTO不一定是网络信息的唯一来源。
The ALTO Protocol assumes that HTTP client and server implementations exist. It also assumes that JSON encoder and decoder implementations exist.
ALTO协议假定存在HTTP客户端和服务器实现。它还假设存在JSON编码器和解码器实现。
An ALTO server assumes that it can gather sufficient information to populate Network and Cost maps. "Sufficient information" is dependent on the information being exposed, but likely includes information gathered from protocols such as IGP and EGP Routing Information Bases (see Figure 1). Specific mechanisms have been proposed (e.g., [ALTO-SVR-APIS]) and are expected to be provided in extension documents.
ALTO服务器假定它可以收集足够的信息来填充网络和成本图。“充分信息”取决于公开的信息，但可能包括从协议（如IGP和EGP路由信息库）收集的信息（见图1）。已经提出了具体的机制（例如，[ALTO-SVR-API]），预计将在扩展文档中提供。
ALTO presents a new opportunity for managing network traffic by providing additional information to clients. In particular, the deployment of an ALTO server may shift network traffic patterns, and the potential impact to network operation can be large. An ALTO service provider should ensure that appropriate information is being exposed. Privacy implications for ISPs are discussed in Section 15.3.
ALTO presents a new opportunity for managing network traffic by providing additional information to clients. In particular, the deployment of an ALTO server may shift network traffic patterns, and the potential impact to network operation can be large. An ALTO service provider should ensure that appropriate information is being exposed. Privacy implications for ISPs are discussed in Section 15.3.translate error, please retry
An ALTO service provider should consider how to measure impacts on (or integration with) traffic engineering, in addition to monitoring correctness and responsiveness of ALTO servers. The measurement of impacts can be challenging because ALTO-enabled applications may not provide related information back to the ALTO service provider. Furthermore, the measurement of an ALTO service provider may show that ALTO clients are not bound to ALTO server guidance as ALTO is only one source of information.
除了监控阿尔托服务器的正确性和响应性之外，阿尔托服务提供商还应考虑如何测量对流量工程的影响（或与流量工程的集成）。影响的测量可能具有挑战性，因为启用ALTO的应用程序可能不会向ALTO服务提供商提供相关信息。此外，对ALTO服务提供商的测量可能表明，ALTO客户端不受ALTO服务器指南的约束，因为ALTO只是一个信息源。
While it can be challenging to measure the impact of ALTO guidance, there exist some possible techniques. In certain trusted deployment environments, it may be possible to collect information directly from ALTO clients. It may also be possible to vary or selectively disable ALTO guidance for a portion of ALTO clients either by time, geographical region, or some other criteria to compare the network traffic characteristics with and without ALTO.
虽然测量ALTO制导的影响可能具有挑战性，但存在一些可能的技术。在某些受信任的部署环境中，可以直接从ALTO客户端收集信息。还可以根据时间、地理区域或一些其他标准改变或选择性地禁用部分ALTO客户端的ALTO引导，以比较有和没有ALTO的网络流量特征。
Both ALTO service providers and those using ALTO clients should be aware of the impact of incorrect or faked guidance (see [ALTO-DEPLOYMENT]).
ALTO服务提供商和使用ALTO客户端的服务提供商都应意识到错误或伪造指导的影响（参见[ALTO-DEPLOYMENT]）。
A common management API would be desirable given that ALTO servers may typically be configured with dynamic data from various sources, and ALTO servers are intended to scale horizontally for fault-tolerance and reliability. A specific API or protocol is outside the scope of this document, but may be provided by an extension document.
鉴于ALTO服务器通常可以配置来自不同来源的动态数据，并且ALTO服务器旨在水平扩展以实现容错性和可靠性，因此需要一个通用的管理API。特定API或协议不在本文档范围内，但可以通过扩展文档提供。
Logging is an important functionality for ALTO servers and, depending on the deployment, ALTO clients. Logging should be done via syslog [RFC5424].
日志记录是ALTO服务器和ALTO客户端（取决于部署）的一项重要功能。应通过syslog[RFC5424]进行日志记录。
A Management Information Model (see Section 3.2 of [RFC5706]) is not provided by this document, but should be included or referenced by any extension documenting an ALTO-related management API or protocol.
本文件未提供管理信息模型（见[RFC5706]第3.2节），但任何扩展文件均应包含或引用与ALTO相关的管理API或协议。
An ALTO service provider should monitor whether any ALTO servers have failed. See Section 16.2.5 for related metrics that may indicate server failures.
ALTO服务提供商应监控是否有任何ALTO服务器出现故障。有关可能指示服务器故障的相关指标，请参见第16.2.5节。
Standardized approaches and protocols to configuration management for ALTO are outside the scope of this document, but this document does outline high-level principles suggested for future standardization efforts.
ALTO配置管理的标准化方法和协议不在本文件范围内，但本文件确实概述了为未来标准化工作建议的高级原则。
An ALTO server requires at least the following logical inputs:
ALTO服务器至少需要以下逻辑输入：
o Data sources from which ALTO information resources is derived. This can be either raw network information (e.g., from routing elements) or pre-processed ALTO-level information in the forms of network maps, cost maps, etc.
o 从中派生ALTO信息资源的数据源。这可以是原始网络信息（例如，来自路由元素）或以网络图、成本图等形式预处理的ALTO级别信息。
o Algorithms for computing the ALTO information returned to clients. These could return either information from a database or information customized for each client.
o 用于计算返回给客户端的ALTO信息的算法。它们可以返回数据库中的信息，也可以返回为每个客户机定制的信息。
o Security policies mapping potential clients to the information that they have privilege to access.
o 将潜在客户端映射到其有权访问的信息的安全策略。
Multiple ALTO servers can be deployed for scalability. A centralized configuration database may be used to ensure they are providing the desired ALTO information with appropriate security controls. The ALTO information (e.g., network maps and cost maps) being served by each ALTO server, as well as security policies (HTTP authentication, TLS client and server authentication, TLS encryption parameters) intended to serve the same information should be monitored for consistency.
可以部署多个ALTO服务器以实现可扩展性。可以使用集中配置数据库，以确保它们提供所需的ALTO信息和适当的安全控制。应监控每个ALTO服务器提供的ALTO信息（如网络图和成本图）以及用于提供相同信息的安全策略（HTTP身份验证、TLS客户端和服务器身份验证、TLS加密参数）的一致性。
An exhaustive list of desirable performance information from ALTO servers and ALTO clients are outside of the scope of this document. The following is a list of suggested ALTO-specific metrics to be monitored based on the existing deployment and protocol development experience:
来自ALTO服务器和ALTO客户端的理想性能信息的详尽列表不在本文档范围内。以下是根据现有部署和协议开发经验监控的建议ALTO特定指标列表：
o Requests and responses for each service listed in an information directory (total counts and size in bytes);
o 信息目录中列出的每个服务的请求和响应（总计数和大小，以字节为单位）；
o CPU and memory utilization;
o CPU和内存利用率；
o ALTO map updates;
o 中音地图更新；
o Number of PIDs;
o PID的数量；
o ALTO map sizes (in-memory size, encoded size, number of entries).
o ALTO映射大小（内存大小、编码大小、条目数）。
Section 15 documents ALTO-specific security considerations. Operators should configure security policies with those in mind. Readers should refer to HTTP [RFC7230] and TLS [RFC5246] and related documents for mechanisms available for configuring security policies. Other appropriate security mechanisms (e.g., physical security, firewalls, etc.) should also be considered.
第15节记录了ALTO特定的安全注意事项。操作员应在配置安全策略时牢记这些原则。读者应参考HTTP[RFC7230]和TLS[RFC5246]以及相关文档，了解可用于配置安全策略的机制。还应考虑其他适当的安全机制（如物理安全、防火墙等）。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]Baker，F.，“IP版本4路由器的要求”，RFC1812，1995年6月。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC2046]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, August 2006.
[RFC4632]Fuller，V.和T.Li，“无类域间路由（CIDR）：互联网地址分配和聚合计划”，BCP 122，RFC 4632，2006年8月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[RFC5389]Rosenberg，J.，Mahy，R.，Matthews，P.，和D.Wing，“NAT的会话遍历实用程序（STUN）”，RFC 5389，2008年10月。
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[RFC5424]Gerhards，R.，“系统日志协议”，RFC 54242009年3月。
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010.
[RFC5952]Kawamura，S.和M.Kawashima，“IPv6地址文本表示的建议”，RFC 59522010年8月。
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, March 2011.
[RFC6125]Saint Andre，P.和J.Hodges，“在传输层安全（TLS）环境下使用X.509（PKIX）证书在互联网公钥基础设施中表示和验证基于域的应用程序服务标识”，RFC 61252011年3月。
[RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 2014.
[RFC7230]Fielding，R.和J.Reschke，“超文本传输协议（HTTP/1.1）：消息语法和路由”，RFC 7230，2014年6月。
[ALTO-DEPLOYMENT] Stiemerling, M., Ed., Kiesel, S., Ed., Previdi, S., and M. Scharf, "ALTO Deployment Considerations", Work in Progress, February 2014.
[ALTO-DEPLOYMENT]Stieemerling，M.，Ed.，Kiesel，S.，Ed.，Previdi，S.，和M.Scharf，“ALTO-DEPLOYMENT注意事项”，进展中的工作，2014年2月。
[ALTO-INFOEXPORT] Shalunov, S., Penno, R., and R. Woundy, "ALTO Information Export Service", Work in Progress, October 2008.
[ALTO-INFOEXPORT]Shalunov，S.，Penno，R.，和R.Woundy，“ALTO信息出口服务”，正在进行的工作，2008年10月。
[ALTO-MULTI-PS] Das, S., Narayanan, V., and L. Dondeti, "ALTO: A Multi Dimensional Peer Selection Problem", Work in Progress, October 2008.
[ALTO-MULTI-PS]Das，S.，Narayanan，V.，和L.Dondeti，“ALTO:多维对等选择问题”，正在进行的工作，2008年10月。
[ALTO-QUERYRESPONSE] Das, S. and V. Narayanan, "A Client to Service Query Response Protocol for ALTO", Work in Progress, March 2009.
[ALTO-QUERYRESPONSE]Das，S.和V.Narayanan，“ALTO的客户到服务查询响应协议”，正在进行的工作，2009年3月。
[ALTO-SERVER-DISC] Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., and H. Song, "ALTO Server Discovery", Work in Progress, September 2013.
[ALTO-SERVER-DISC]Kiesel，S.，Stiemerling，M.，Schwan，N.，Scharf，M.，和H.Song，“ALTO服务器发现”，正在进行的工作，2013年9月。
[ALTO-SVR-APIS] Medved, J., Ward, D., Peterson, J., Woundy, R., and D. McDysan, "ALTO Network-Server and Server-Server APIs", Work in Progress, March 2011.
[ALTO-SVR-API]Medved，J.，Ward，D.，Peterson，J.，Woundy，R.，和D.McDysan，“ALTO网络服务器和服务器服务器API”，正在进行的工作，2011年3月。
[ALTO-USE-CASES] Niven-Jenkins, B., Watson, G., Bitar, N., Medved, J., and S. Previdi, "Use Cases for ALTO within CDNs", Work in Progress, June 2012.
[ALTO-用例]Niven Jenkins，B.，Watson，G.，Bitar，N.，Medved，J.，和S.Previdi，“CDN中ALTO的用例”，正在进行的工作，2012年6月。
[BitTorrent] "Bittorrent Protocol Specification v1.0", <http://wiki.theory.org/BitTorrentSpecification>.
[BitTorrent]“BitTorrent协议规范v1.0”<http://wiki.theory.org/BitTorrentSpecification>.
[Fielding-Thesis] Fielding, R., "Architectural Styles and the Design of Network-based Software Architectures", University of California, Irvine, Dissertation 2000, 2000.
Frand，R，“Architectural Styles和基于网络的软件体系结构设计”，加利福尼亚大学，尔湾，论文2000, 2000。
[IEEE.754.2008] Institute of Electrical and Electronics Engineers, "Standard for Binary Floating-Point Arithmetic", IEEE Standard 754, August 2008.
[IEEE.754.2008]电气和电子工程师协会，“二进制浮点算法标准”，IEEE标准754，2008年8月。
[P4P-FRAMEWORK] Alimi, R., Pasko, D., Popkin, L., Wang, Y., and Y. Yang, "P4P: Provider Portal for P2P Applications", Work in Progress, November 2008.
[P4P-FRAMEWORK]Alimi，R.，Pasko，D.，Popkin，L.，Wang，Y.，和Y.Yang，“P4P：P2P应用程序提供商门户”，正在进行的工作，2008年11月。
[P4P-SIGCOMM08] Xie, H., Yang, Y., Krishnamurthy, A., Liu, Y., and A. Silberschatz, "P4P: Provider Portal for (P2P) Applications", SIGCOMM 2008, August 2008.
[P4P-SIGCOM08]Xie，H.，Yang，Y.，Krishnamurthy，A.，Liu，Y.，和A.Silberschatz，“P4P：P2P应用程序提供商门户”，SIGCOM2008，2008年8月。
[P4P-SPEC] Wang, Y., Alimi, R., Pasko, D., Popkin, L., and Y. Yang, "P4P Protocol Specification", Work in Progress, March 2009.
[P4P-SPEC]Wang，Y.，Alimi，R.，Pasko，D.，Popkin，L.，和Y.Yang，“P4P协议规范”，正在进行的工作，2009年3月。
[PROXIDOR] Akonjang, O., Feldmann, A., Previdi, S., Davie, B., and D. Saucez, "The PROXIDOR Service", Work in Progress, March 2009.
[PROXIDOR]Akonjang，O.，Feldmann，A.，Previdi，S.，Davie，B.，和D.Saucez，“PROXIDOR服务”，在建工程，2009年3月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC2818，2000年5月。
[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic Optimization (ALTO) Problem Statement", RFC 5693, October 2009.
[RFC5693]Seedorf，J.和E.Burger，“应用层流量优化（ALTO）问题陈述”，RFC 5693，2009年10月。
[RFC5706] Harrington, D., "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions", RFC 5706, November 2009.
[RFC5706]Harrington，D.，“考虑新协议和协议扩展的操作和管理指南”，RFC 5706，2009年11月。
[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", RFC 6144, April 2011.
[RFC6144]Baker，F.，Li，X.，Bao，C.，和K.Yin，“IPv4/IPv6转换框架”，RFC 61442011年4月。
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix Translation", RFC 6296, June 2011.
[RFC6296]Wasserman，M.和F.Baker，“IPv6到IPv6网络前缀转换”，RFC 62962011年6月。
[RFC6708] Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and Y. Yang, "Application-Layer Traffic Optimization (ALTO) Requirements", RFC 6708, September 2012.
[RFC6708]Kiesel，S.，Previdi，S.，Stiemering，M.，Woundy，R.，和Y.Yang，“应用层流量优化（ALTO）要求”，RFC 67082012年9月。
[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, March 2014.
[RFC7159]Bray，T.，“JavaScript对象表示法（JSON）数据交换格式”，RFC 7159，2014年3月。
[RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, June 2014.
[RFC7231]Fielding，R.和J.Reschke，“超文本传输协议（HTTP/1.1）：语义和内容”，RFC 72312014年6月。
[SIP] Jennings, C., "Computational Puzzles for SPAM Reduction in SIP", Work in Progress, July 2007.
[SIP]Jennings，C.，“SIP中减少垃圾邮件的计算难题”，进展中的工作，2007年7月。
Thank you to Jan Seedorf (NEC) for substantial contributions to the Security Considerations section. Ben Niven-Jenkins (Velocix), Michael Scharf, and Sabine Randriamasy (Alcatel-Lucent) gave substantial feedback and suggestions on the protocol design.
感谢Jan Sedorf（NEC）对安全注意事项部分的重要贡献。Ben Niven Jenkins（Velocix）、Michael Scharf和Sabine Randriamasy（阿尔卡特朗讯）就协议设计给出了大量反馈和建议。
We would like to thank the following people whose input and involvement was indispensable in achieving this merged proposal:
我们要感谢以下人员，他们的投入和参与对实现这一合并提案必不可少：
Obi Akonjang (DT Labs/TU Berlin),
Obi Akonjang（DT实验室/柏林交通大学），
Saumitra M. Das (Qualcomm Inc.),
Saumitra M.Das（高通公司），
Syon Ding (China Telecom),
丁锡安（中国电信），
Doug Pasko (Verizon),
道格·帕斯科（Verizon），
Laird Popkin (Pando Networks),
莱尔德·波普金（潘多网络公司），
Satish Raghunath (Juniper Networks),
Satish Raghunath（Juniper Networks），
Albert Tian (Ericsson/Redback),
田伟业（爱立信/红背公司），
Yu-Shun Wang (Microsoft),
王宇顺（微软），
David Zhang (PPLive),
张大卫（PPLive），
Yunfei Zhang (China Mobile).
张云飞（中国移动）。
We would also like to thank the following additional people who were involved in the projects that contributed to this merged document: Alex Gerber (ATT), Chris Griffiths (Comcast), Ramit Hora (Pando Networks), Arvind Krishnamurthy (University of Washington), Marty Lafferty (DCIA), Erran Li (Bell Labs), Jin Li (Microsoft), Y. Grace Liu (IBM Watson), Jason Livingood (Comcast), Michael Merritt (ATT), Ingmar Poese (DT Labs/TU Berlin), James Royalty (Pando Networks), Damien Saucez (UCL), Thomas Scholl (ATT), Emilio Sepulveda (Telefonica), Avi Silberschatz (Yale University), Hassan Sipra (Bell Canada), Georgios Smaragdakis (DT Labs/TU Berlin), Haibin Song (Huawei), Oliver Spatscheck (ATT), See-Mong Tang (Microsoft), Jia Wang (ATT), Hao Wang (Yale University), Ye Wang (Yale University), Haiyong Xie (Yale University).
我们还要感谢以下参与本合并文档项目的其他人员：Alex Gerber（ATT）、Chris Griffiths（Comcast）、Ramit Hora（Pando Networks）、Arvind Krishnamurthy（华盛顿大学）、Marty Lafferty（DCIA）、Erna Li（贝尔实验室）、Jin Li（微软）、Y.Grace Liu（IBM Watson）、杰森·利文戈德（Comcast）、迈克尔·梅里特（ATT）、英格玛·坡（DT实验室/柏林大学）、詹姆斯·罗雅特（Pando Networks）、达米恩·索切斯（UCL）、托马斯·斯科尔（ATT）、埃米利奥·塞普尔维达（Telefonica）、阿维·西尔伯沙茨（耶鲁大学）、哈桑·西普拉（加拿大贝尔大学）、乔治·斯马拉达基斯（DT实验室/柏林大学）、海滨松（华为）、奥利弗·斯帕切克（ATT），见Mong Tang（微软）、Jia Wang（ATT）、Hao Wang（耶鲁大学）、Ye Wang（耶鲁大学）、Haiyong Xie（耶鲁大学）。
Stanislav Shalunov would like to thank BitTorrent, where he worked while contributing to ALTO development.
Stanislav Shalunov感谢BitTorrent，他在那里工作，同时为ALTO开发做出了贡献。
The ALTO Protocol specified in this document consists of contributions from
本文件中规定的ALTO协议由以下各方提供：
o P4P [P4P-FRAMEWORK], [P4P-SIGCOMM08], [P4P-SPEC];
o P4P[P4P-FRAMEWORK]、[P4P-SIGCOM08]、[P4P-SPEC]；
o ALTO Info-Export [ALTO-INFOEXPORT];
o 中音信息输出[中音信息输出]；
o Query/Response [ALTO-QUERYRESPONSE], [ALTO-MULTI-PS]; and
o 查询/响应[ALTO-QUERYRESPONSE]，[ALTO-MULTI-PS]；和
o Proxidor [PROXIDOR].
o Proxidor[Proxidor]。
Authors' Addresses
作者地址
Richard Alimi (editor) Google 1600 Amphitheatre Parkway Mountain View, CA 94043 USA
理查德·阿利米（编辑）谷歌1600圆形剧场公园道山景，加利福尼亚州94043
EMail: ralimi@google.com
EMail: ralimi@google.com
Reinaldo Penno (editor) Cisco Systems, Inc. 170 West Tasman Dr San Jose, CA 95134 USA
雷纳尔多·佩诺（编辑）思科系统公司，美国加利福尼亚州圣何塞市西塔斯曼博士170号，邮编95134
EMail: repenno@cisco.com
EMail: repenno@cisco.com
Y. Richard Yang (editor) Yale University 51 Prospect St New Haven, CT 06511 USA
Y.Richard Yang（编辑）美国康涅狄格州纽黑文前景街51号耶鲁大学06511
EMail: yry@cs.yale.edu
EMail: yry@cs.yale.edu
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
Stefano Previdi Cisco Systems, Inc. Via Del Serafico, 200 Rome 00142 Italy
Stefano Previdi Cisco Systems，Inc.Via Del Serafico，200罗马00142意大利
EMail: sprevidi@cisco.com
EMail: sprevidi@cisco.com
Wendy Roome Alcatel-Lucent 600 Mountain Ave. Murray Hill, NJ 07974 USA
Wendy Roome Alcatel-Lucent美国新泽西州默里山山地大道600号，邮编：07974
EMail: w.roome@alcatel-lucent.com
EMail: w.roome@alcatel-lucent.com
Stanislav Shalunov Open Garden 751 13th St San Francisco, CA 94130 USA
斯坦尼斯拉夫沙拉诺夫开放花园751，第十三旧金山，CA，美国94130
EMail: shalunov@shlang.com
EMail: shalunov@shlang.com
Richard Woundy Comcast Cable Communications One Comcast Center 1701 John F. Kennedy Boulevard Philadelphia, PA 19103 USA
Richard Woundy Comcast有线通信一号Comcast中心美国宾夕法尼亚州费城肯尼迪大道1701号，邮编：19103
EMail: Richard_Woundy@cable.comcast.com
EMail: Richard_Woundy@cable.comcast.com