Network Working Group J. Rosenberg
Request for Comments: 3219 dynamicsoft
Category: Standards Track H. Salama
Cisco Systems
M. Squire
Hatteras Networks
January 2002
Network Working Group J. Rosenberg
Request for Comments: 3219 dynamicsoft
Category: Standards Track H. Salama
Cisco Systems
M. Squire
Hatteras Networks
January 2002
Telephony Routing over IP (TRIP)
IP电话路由（TRIP）
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
This document presents the Telephony Routing over IP (TRIP). TRIP is a policy driven inter-administrative domain protocol for advertising the reachability of telephony destinations between location servers, and for advertising attributes of the routes to those destinations. TRIP's operation is independent of any signaling protocol, hence TRIP can serve as the telephony routing protocol for any signaling protocol.
本文档介绍IP电话路由（TRIP）。TRIP是一种策略驱动的跨管理域协议，用于在位置服务器之间公布电话目的地的可达性，以及公布到这些目的地的路由属性。TRIP的操作独立于任何信令协议，因此TRIP可以作为任何信令协议的电话路由协议。
The Border Gateway Protocol (BGP-4) is used to distribute routing information between administrative domains. TRIP is used to distribute telephony routing information between telephony administrative domains. The similarity between the two protocols is obvious, and hence TRIP is modeled after BGP-4.
边界网关协议（BGP-4）用于在管理域之间分发路由信息。TRIP用于在电话管理域之间分发电话路由信息。两个协议之间的相似性是显而易见的，因此TRIP是按照BGP-4建模的。
Table of Contents
目录
1 Terminology and Definitions .............................. 3
2 Introduction ............................................. 4
3 Summary of Operation ..................................... 5
3.1 Peering Session Establishment and Maintenance ............ 5
3.2 Database Exchanges ....................................... 6
3.3 Internal Versus External Synchronization ................. 6
3.4 Advertising TRIP Routes .................................. 6
1 Terminology and Definitions .............................. 3
2 Introduction ............................................. 4
3 Summary of Operation ..................................... 5
3.1 Peering Session Establishment and Maintenance ............ 5
3.2 Database Exchanges ....................................... 6
3.3 Internal Versus External Synchronization ................. 6
3.4 Advertising TRIP Routes .................................. 6
3.5 Telephony Routing Information Bases ...................... 7
3.6 Routes in TRIP ........................................... 9
3.7 Aggregation .............................................. 9
4 Message Formats .......................................... 10
4.1 Message Header Format .................................... 10
4.2 OPEN Message Format ...................................... 11
4.3 UPDATE Message Format .................................... 15
4.4 KEEPALIVE Message Format ................................ 22
4.5 NOTIFICATION Message Format ............................. 23
5 TRIP Attributes ......................................... 24
5.1 WithdrawnRoutes .......................................... 24
5.2 ReachableRoutes .......................................... 28
5.3 NextHopServer ........................................... 29
5.4 AdvertisementPath ....................................... 31
5.5 RoutedPath ............................................... 35
5.6 AtomicAggregate ......................................... 36
5.7 LocalPreference ......................................... 37
5.8 MultiExitDisc ............................................ 38
5.9 Communities .............................................. 39
5.10 ITAD Topology .......................................... 41
5.11 ConvertedRoute ........................................... 43
5.12 Considerations for Defining New TRIP Attributes ......... 44
6 TRIP Error Detection and Handling ....................... 44
6.1 Message Header Error Detection and Handling ............. 45
6.2 OPEN Message Error Detection and Handling ............... 45
6.3 UPDATE Message Error Detection and Handling ............. 46
6.4 NOTIFICATION Message Error Detection and Handling ....... 48
6.5 Hold Timer Expired Error Handling ....................... 48
6.6 Finite State Machine Error Handling ..................... 48
6.7 Cease ................................................... 48
6.8 Connection Collision Detection .......................... 48
7 TRIP Version Negotiation ................................ 49
8 TRIP Capability Negotiation ............................. 50
9 TRIP Finite State Machine ............................... 50
10 UPDATE Message Handling ................................. 55
10.1 Flooding Process ........................................ 56
10.2 Decision Process ........................................ 58
10.3 Update-Send Process ..................................... 62
10.4 Route Selection Criteria ................................ 67
10.5 Originating TRIP Routes ................................. 67
11 TRIP Transport .......................................... 68
12 ITAD Topology ........................................... 68
13 IANA Considerations ...................................... 68
13.1 TRIP Capabilities ....................................... 68
13.2 TRIP Attributes ........................................ 69
13.3 Destination Address Families ............................ 69
13.4 TRIP Application Protocols .............................. 69
13.5 ITAD Numbers ............................................ 70
3.5 Telephony Routing Information Bases ...................... 7
3.6 Routes in TRIP ........................................... 9
3.7 Aggregation .............................................. 9
4 Message Formats .......................................... 10
4.1 Message Header Format .................................... 10
4.2 OPEN Message Format ...................................... 11
4.3 UPDATE Message Format .................................... 15
4.4 KEEPALIVE Message Format ................................ 22
4.5 NOTIFICATION Message Format ............................. 23
5 TRIP Attributes ......................................... 24
5.1 WithdrawnRoutes .......................................... 24
5.2 ReachableRoutes .......................................... 28
5.3 NextHopServer ........................................... 29
5.4 AdvertisementPath ....................................... 31
5.5 RoutedPath ............................................... 35
5.6 AtomicAggregate ......................................... 36
5.7 LocalPreference ......................................... 37
5.8 MultiExitDisc ............................................ 38
5.9 Communities .............................................. 39
5.10 ITAD Topology .......................................... 41
5.11 ConvertedRoute ........................................... 43
5.12 Considerations for Defining New TRIP Attributes ......... 44
6 TRIP Error Detection and Handling ....................... 44
6.1 Message Header Error Detection and Handling ............. 45
6.2 OPEN Message Error Detection and Handling ............... 45
6.3 UPDATE Message Error Detection and Handling ............. 46
6.4 NOTIFICATION Message Error Detection and Handling ....... 48
6.5 Hold Timer Expired Error Handling ....................... 48
6.6 Finite State Machine Error Handling ..................... 48
6.7 Cease ................................................... 48
6.8 Connection Collision Detection .......................... 48
7 TRIP Version Negotiation ................................ 49
8 TRIP Capability Negotiation ............................. 50
9 TRIP Finite State Machine ............................... 50
10 UPDATE Message Handling ................................. 55
10.1 Flooding Process ........................................ 56
10.2 Decision Process ........................................ 58
10.3 Update-Send Process ..................................... 62
10.4 Route Selection Criteria ................................ 67
10.5 Originating TRIP Routes ................................. 67
11 TRIP Transport .......................................... 68
12 ITAD Topology ........................................... 68
13 IANA Considerations ...................................... 68
13.1 TRIP Capabilities ....................................... 68
13.2 TRIP Attributes ........................................ 69
13.3 Destination Address Families ............................ 69
13.4 TRIP Application Protocols .............................. 69
13.5 ITAD Numbers ............................................ 70
14 Security Considerations ................................. 70
A1 Appendix 1: TRIP FSM State Transitions and Actions ...... 71
A2 Appendix 2: Implementation Recommendations .............. 73
Acknowledgments ................................................ 75
References ..................................................... 75
Intellectual Property Notice ................................... 77
Authors' Addresses ............................................. 78
Full Copyright Statement ....................................... 79
14 Security Considerations ................................. 70
A1 Appendix 1: TRIP FSM State Transitions and Actions ...... 71
A2 Appendix 2: Implementation Recommendations .............. 73
Acknowledgments ................................................ 75
References ..................................................... 75
Intellectual Property Notice ................................... 77
Authors' Addresses ............................................. 78
Full Copyright Statement ....................................... 79
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 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[1]中所述进行解释。
A framework for Telephony Routing over IP (TRIP) is described in [2]. We assume the reader is familiar with the framework and terminology of [2]. We define and use the following terms in addition to those defined in [2].
[2]中描述了IP电话路由（TRIP）的框架。我们假设读者熟悉[2]的框架和术语。除了[2]中定义的术语外，我们还定义和使用了以下术语。
Telephony Routing Information Base (TRIB): The database of reachable telephony destinations built and maintained at an LS as a result of its participation in TRIP.
电话路由信息库（TRIB）：LS因参与TRIP而建立和维护的可到达电话目的地数据库。
IP Telephony Administrative Domain (ITAD): The set of resources (gateways, location servers, etc.) under the control of a single administrative authority. End users are customers of an ITAD.
IP电话管理域（ITAD）：由单个管理机构控制的一组资源（网关、位置服务器等）。最终用户是ITAD的客户。
Less/More Specific Route: A route X is said to be less specific than a route Y if every destination in Y is also a destination in X, and X and Y are not equal. In this case, Y is also said to be more specific than X.
更少/更具体的路线：如果Y中的每个目的地也是X中的目的地，且X和Y不相等，则称路线X比路线Y更具体。在这种情况下，Y也被认为比X更具体。
Aggregation: Aggregation is the process by which multiple routes are combined into a single less specific route that covers the same set of destinations. Aggregation is used to reduce the size of the TRIB being synchronized with peer LSs by reducing the number of exported TRIP routes.
聚合：聚合是将多条路由组合成一条不太特定的路由，覆盖同一组目的地的过程。聚合用于通过减少导出旅行路线的数量来减少与对等LSs同步的TRIB的大小。
Peers: Two LSs that share a logical association (a transport connection). If the LSs are in the same ITAD, they are internal peers. Otherwise, they are external peers. The logical association between two peer LSs is called a peering session.
对等点：共享逻辑关联（传输连接）的两个LSs。如果LSs位于同一ITAD中，则它们是内部对等点。否则，它们是外部对等体。两个对等LSs之间的逻辑关联称为对等会话。
Telephony Routing Information Protocol (TRIP): The protocol defined in this specification. The function of TRIP is to advertise the reachability of telephony destinations, attributes associated with the destinations, as well as the attributes of the path towards those destinations.
电话路由信息协议（TRIP）：本规范中定义的协议。TRIP的功能是宣传电话目的地的可达性、与目的地相关的属性以及通往这些目的地的路径属性。
TRIP destination: TRIP can be used to manage routing tables for multiple protocols (SIP, H323, etc.). In TRIP, a destination is the combination of (a) a set of addresses (given by an address family and address prefix), and (b) an application protocol (SIP, H323, etc).
TRIP destination：TRIP可用于管理多个协议（SIP、H323等）的路由表。在TRIP中，目的地是（a）一组地址（由地址族和地址前缀给出）和（b）应用协议（SIP、H323等）的组合。
The gateway location and routing problem has been introduced in [2]. It is considered one of the more difficult problems in IP telephony. The selection of an egress gateway for a telephony call, traversing an IP network towards an ultimate destination in the PSTN, is driven in large part by the policies of the various parties along the path, and by the relationships established between these parties. As such, a global directory of egress gateways in which users look up destination phone numbers is not a feasible solution. Rather, information about the availability of egress gateways is exchanged between providers, and subject to policy, made available locally and then propagated to other providers in other ITADs, thus creating routes towards these egress gateways. This would allow each provider to create its own database of reachable phone numbers and the associated routes - such a database could be very different for each provider depending on policy.
[2]中介绍了网关位置和路由问题。它被认为是IP电话中比较困难的问题之一。为电话呼叫选择出口网关，穿过IP网络到达PSTN中的最终目的地，在很大程度上是由路径上各方的策略以及这些各方之间建立的关系驱动的。因此，用户在其中查找目的地电话号码的全球出口网关目录不是一个可行的解决方案。相反，有关出口网关可用性的信息在提供商之间交换，并根据策略，在本地可用，然后传播到其他ITAD中的其他提供商，从而创建通向这些出口网关的路由。这将允许每个提供商创建自己的数据库，其中包含可访问的电话号码和相关路由——根据策略，每个提供商的数据库可能会非常不同。
TRIP is an inter-domain (i.e., inter-ITAD) gateway location and routing protocol. The primary function of a TRIP speaker, called a location server (LS), is to exchange information with other LSs. This information includes the reachability of telephony destinations, the routes towards these destinations, and information about gateways towards those telephony destinations residing in the PSTN. The TRIP requirements are set forth in [2].
TRIP是一种域间（即ITAD间）网关位置和路由协议。称为定位服务器（LS）的行程扬声器的主要功能是与其他LSs交换信息。该信息包括电话目的地的可达性、到这些目的地的路由以及关于到驻留在PSTN中的那些电话目的地的网关的信息。[2]中规定了跳闸要求。
LSs exchange sufficient routing information to construct a graph of ITAD connectivity so that routing loops may be prevented. In addition, TRIP can be used to exchange attributes necessary to enforce policies and to select routes based on path or gateway characteristics. This specification defines TRIP's transport and synchronization mechanisms, its finite state machine, and the TRIP data. This specification defines the basic attributes of TRIP. The TRIP attribute set is extendible, so additional attributes may be defined in future documents.
LSs交换足够的路由信息以构建ITAD连接图，从而防止路由循环。此外，TRIP还可用于交换实施策略所需的属性，并根据路径或网关特征选择路由。本规范定义了TRIP的传输和同步机制、有限状态机和TRIP数据。本规范定义了TRIP的基本属性。行程属性集是可扩展的，因此可以在将来的文档中定义其他属性。
TRIP is modeled after the Border Gateway Protocol 4 (BGP-4) [3] and enhanced with some link state features, as in the Open Shortest Path First (OSPF) protocol [4], IS-IS [5], and the Server Cache Synchronization Protocol (SCSP) [6]. TRIP uses BGP's inter-domain transport mechanism, BGP's peer communication, BGP's finite state machine, and similar formats and attributes as BGP. Unlike BGP however, TRIP permits generic intra-domain LS topologies, which simplifies configuration and increases scalability in contrast to BGP's full mesh requirement of internal BGP speakers. TRIP uses an intra-domain flooding mechanism similar to that used in OSPF [4], IS-IS [5], and SCSP [6].
TRIP按照边界网关协议4（BGP-4）[3]进行建模，并通过一些链路状态功能进行增强，如开放最短路径优先（OSPF）协议[4]、is-is[5]和服务器缓存同步协议（SCSP）[6]。TRIP使用BGP的域间传输机制、BGP的对等通信、BGP的有限状态机以及与BGP类似的格式和属性。然而，与BGP不同，TRIP允许通用域内LS拓扑，这与BGP对内部BGP扬声器的全网状要求相比，简化了配置并提高了可扩展性。TRIP使用域内泛洪机制，类似于OSPF[4]、IS-IS[5]和SCSP[6]中使用的机制。
TRIP permits aggregation of routes as they are advertised through the network. TRIP does not define a specific route selection algorithm.
TRIP允许通过网络发布路线的聚合。TRIP未定义特定的路线选择算法。
TRIP runs over a reliable transport protocol. This eliminates the need to implement explicit fragmentation, retransmission, acknowledgment, and sequencing. The error notification mechanism used in TRIP assumes that the transport protocol supports a graceful close, i.e., that all outstanding data will be delivered before the connection is closed.
TRIP通过可靠的传输协议运行。这消除了实现显式分段、重传、确认和排序的需要。TRIP中使用的错误通知机制假设传输协议支持正常关闭，即所有未完成的数据都将在连接关闭之前交付。
TRIP's operation is independent of any particular telephony signaling protocol. Therefore, TRIP can be used as the routing protocol for any of these protocols, e.g., H.323 [7] and SIP [8].
TRIP的操作独立于任何特定的电话信令协议。因此，TRIP可以用作这些协议中任何一个的路由协议，例如H.323[7]和SIP[8]。
The LS peering topology is independent of the physical topology of the network. In addition, the boundaries of an ITAD are independent of the boundaries of the layer 3 routing autonomous systems. Neither internal nor external TRIP peers need to be physically adjacent.
LS对等拓扑独立于网络的物理拓扑。此外，ITAD的边界独立于第3层路由自治系统的边界。内部或外部跳闸对等点都不需要物理相邻。
This section summarizes the operation of TRIP. Details are provided in later sections.
本节总结了跳闸的操作。详情将在后面的章节中提供。
Two peer LSs form a transport protocol connection between one another. They exchange messages to open and confirm the connection parameters, and to negotiate the capabilities of each LS as well as the type of information to be advertised over this connection.
两个对等LSs在彼此之间形成传输协议连接。它们交换消息以打开和确认连接参数，并协商每个LS的功能以及通过此连接发布的信息类型。
KeepAlive messages are sent periodically to ensure adjacent peers are operational. Notification messages are sent in response to errors or special conditions. If a connection encounters an error condition, a Notification message is sent and the connection is closed.
KeepAlive消息会定期发送，以确保相邻对等方可以正常工作。通知消息是针对错误或特殊情况发送的。如果连接遇到错误情况，将发送通知消息并关闭连接。
Once the peer connection has been established, the initial data flow is a dump of all routes relevant to the new peer (In the case of an external peer, all routes in the LS's Adj-TRIB-Out for that external peer. In the case of an internal peer, all routes in the Ext-TRIB and all Adj-TRIBs-In). Note that the different TRIBs are defined in Section 3.5.
一旦建立了对等连接，初始数据流就是与新对等相关的所有路由的转储（对于外部对等，LS的Adj TRIB中的所有路由对于该外部对等。对于内部对等，外部TRIB中的所有路由和所有Adj TRIB In）。请注意，第3.5节定义了不同的TRIB。
Incremental updates are sent as the TRIP routing tables (TRIBs) change. TRIP does not require periodic refresh of the routes. Therefore, an LS must retain the current version of all routing entries.
行程路由表（TRIB）更改时，会发送增量更新。行程不需要定期刷新路线。因此，LS必须保留所有路由条目的当前版本。
If a particular ITAD has multiple LSs and is providing transit service for other ITADs, then care must be taken to ensure a consistent view of routing within the ITAD. When synchronized the TRIP routing tables, i.e., the Loc-TRIBs, of all internal peers are identical.
如果一个特定的ITAD有多个LSs，并为其他ITAD提供中转服务，则必须注意确保ITAD内的路由视图一致。同步时，所有内部对等方的行程路由表（即Loc TRIB）相同。
As with BGP, TRIP distinguishes between internal and external peers. Within an ITAD, internal TRIP uses link-state mechanisms to flood database updates over an arbitrary topology. Externally, TRIP uses point-to-point peering relationships to exchange database information.
与BGP一样，TRIP区分内部和外部对等点。在ITAD中，内部TRIP使用链路状态机制在任意拓扑上大量更新数据库。在外部，TRIP使用点对点对等关系来交换数据库信息。
To achieve internal synchronization, internal peer connections are configured between LSs of the same ITAD such that the resulting intra-domain LS topology is connected and sufficiently redundant. This is different from BGP's approach that requires all internal peers to be connected in a full mesh topology, which may result in scaling problems. When an update is received from an internal peer, the routes in the update are checked to determine if they are newer than the version already in the database. Newer routes are then flooded to all other peers in the same domain.
为了实现内部同步，在同一ITAD的LSs之间配置内部对等连接，从而连接产生的域内LS拓扑并充分冗余。这与BGP的方法不同，BGP的方法要求所有内部对等点在全网状拓扑中连接，这可能导致缩放问题。当从内部对等方接收到更新时，将检查更新中的路由，以确定它们是否比数据库中已有的版本更新。较新的路由随后被淹没到同一域中的所有其他对等方。
In TRIP, a route is defined as the combination of (a) a set of destination addresses (given by an address family indicator and an address prefix), and (b) an application protocol (e.g. SIP, H323, etc.). Generally, there are additional attributes associated with each route (for example, the next-hop server).
在TRIP中，路由被定义为（a）一组目的地地址（由地址族指示符和地址前缀给出）和（b）应用协议（例如SIP、H323等）的组合。通常，存在与每个路由相关联的附加属性（例如，下一跳服务器）。
TRIP routes are advertised between a pair of LSs in UPDATE messages. The destination addresses are included in the ReachableRoutes attribute of the UPDATE, while other attributes describe things like the path or egress gateway.
行程路线在更新消息中的一对LSs之间公布。目标地址包含在更新的ReachableRoutes属性中，而其他属性则描述路径或出口网关等内容。
If an LS chooses to advertise a TRIP route, it may add to or modify the attributes of the route before advertising it to a peer. TRIP provides mechanisms by which an LS can inform its peer that a previously advertised route is no longer available for use. There are three methods by which a given LS can indicate that a route has been withdrawn from service:
如果LS选择公布行程路线，则在向对等方公布之前，它可能会添加或修改路线的属性。TRIP提供了一种机制，通过该机制，LS可以通知其对等方先前公布的路由不再可用。给定LS可通过三种方法指示路线已退出服务：
- Include the route in the WithdrawnRoutes Attribute in an UPDATE message, thus marking the associated destinations as being no longer available for use. - Advertise a replacement route with the same set of destinations in the ReachableRoutes Attribute. - For external peers where flooding is not in use, the LS-to-LS peer connection can be closed, which implicitly removes from service all routes which the pair of LSs had advertised to each other over that peer session. Note that terminating an internal peering session does not necessarily remove the routes advertised by the peer LS as the same routes may have been received from multiple internal peers because of flooding. If an LS determines that another internal LS is no longer active (from the ITAD Topology attributes of the UPDATE messages from other internal peers), then it MUST remove all routes originated into the LS by that LS and rerun its decision process.
- 将路由包括在更新消息的“撤回路由”属性中，从而将关联的目的地标记为不再可用。-在ReachableRoutes属性中公布具有相同目的地集的替换路由。-对于不使用泛洪的外部对等点，可以关闭LS到LS对等点连接，这会隐式地从服务中删除LSs对在该对等会话上相互通告的所有路由。请注意，终止内部对等会话并不一定会删除对等LS播发的路由，因为由于泛洪，可能已从多个内部对等接收到相同的路由。如果一个LS确定另一个内部LS不再处于活动状态（来自其他内部对等方的更新消息的ITAD拓扑属性），则它必须删除该LS发起到LS的所有路由，并重新运行其决策过程。
A TRIP LS processes three types of routes:
行程LS处理三种类型的路线：
- External routes: An external route is a route received from an external peer LS - Internal routes: An internal route is a route received from an internal LS in the same ITAD. - Local routes: A local route is a route locally injected into TRIP, e.g. by configuration or by route redistribution from another routing protocol.
- 外部路由：外部路由是从外部对等LS接收的路由-内部路由：内部路由是从同一ITAD中的内部LS接收的路由。-本地路由：本地路由是本地注入TRIP的路由，例如通过配置或通过从另一个路由协议重新分配路由。
The Telephony Routing Information Base (TRIB) within an LS consists of four distinct parts:
LS中的电话路由信息库（TRIB）由四个不同的部分组成：
- Adj-TRIBs-In: The Adj-TRIBs-In store routing information that has been learned from inbound UPDATE messages. Their contents represent TRIP routes that are available as an input to the Decision Process. These are the "unprocessed" routes received. The routes from each external peer LS and each internal LS are maintained in this database independently, so that updates from one peer do not affect the routes received from another LS. Note that there is an Adj-TRIB-In for every LS within the domain, even those with which the LS is not directly peered. - Ext-TRIB: There is only one Ext-TRIB database per LS. The LS runs the route selection algorithm on all external routes (stored in the Adj-TRIBs-In of the external peers) and local routes (may be stored in an Adj-TRIB-In representing the local LS) and selects the best route for a given destination and stores it in the Ext-TRIB. The use of Ext-TRIB will be explained further in Section 10.3.1 - Loc-TRIB: The Loc-TRIB contains the local TRIP routing information that the LS has selected by applying its local policies to the routing information contained in its Adj-TRIBs-In of internal LSs and the Ext-TRIB. - Adj-TRIBs-Out: The Adj-TRIBs-Out store the information that the local LS has selected for advertisement to its external peers. The routing information stored in the Adj-TRIBs-Out will be carried in the local LS's UPDATE messages and advertised to its peers.
- Adj TRIBs In：从入站更新消息中学习的Adj TRIBs In存储路由信息。其内容表示可作为决策过程输入的出行路线。这些是收到的“未处理”路线。来自每个外部对等LS和每个内部LS的路由在该数据库中独立维护，因此来自一个对等LS的更新不会影响从另一个LS接收的路由。请注意，域中的每个LS都有一个Adj TRIB In，即使是那些LS没有直接对等的LS。-Ext-TRIB：每个LS只有一个Ext-TRIB数据库。LS在所有外部路由（存储在外部对等方的Adj TRIB中）和本地路由（可以存储在代表本地LS的Adj TRIB中）上运行路由选择算法，并为给定目的地选择最佳路由，并将其存储在Ext TRIB中。Ext TRIB的使用将在第10.3.1节-Loc TRIB中进一步解释：Loc TRIB包含本地行程路由信息，LS通过将其本地策略应用于内部LSs和Ext TRIB的Adj TRIB中包含的路由信息来选择本地行程路由信息。-Adj TRIBs Out：Adj TRIBs Out存储本地LS选择用于向其外部对等方发布的信息。存储在Adj TRIB Out中的路由信息将在本地LS的更新消息中携带，并向其对等方发布。
Figure 1 illustrates the relationship between the four parts of the routing information base.
图1说明了路由信息库的四个部分之间的关系。
Loc-TRIB
^
|
Decision Process
^ ^ |
| | |
Adj-TRIBs-In | V
(Internal LSs) | Adj-TRIBs-Out
|
|
|
Ext-TRIB
^ ^
| |
Adj-TRIB-In Local Routes
(External Peers)
Loc-TRIB
^
|
Decision Process
^ ^ |
| | |
Adj-TRIBs-In | V
(Internal LSs) | Adj-TRIBs-Out
|
|
|
Ext-TRIB
^ ^
| |
Adj-TRIB-In Local Routes
(External Peers)
Figure 1: TRIB Relationships
图1:TRIB关系
Although the conceptual model distinguishes between Adj-TRIBs-In, Ext-TRIB, Loc-TRIB, and Adj-TRIBs-Out, this neither implies nor requires that an implementation must maintain four separate copies of the routing information. The choice of implementation (for example, 4 copies of the information vs. 1 copy with pointers) is not constrained by the protocol.
尽管概念模型区分了Adj TRIB In、Ext TRIB、Loc TRIB和Adj TRIB Out，但这并不意味着也不要求实现必须维护路由信息的四个单独副本。实现的选择（例如，信息的4个副本与带指针的1个副本）不受协议的限制。
A route in TRIP specifies a range of numbers by being a prefix of those numbers (the exact definition & syntax of route are in 5.1.1). Arbitrary ranges of numbers are not atomically representable by a route in TRIP. A prefix range is the only type of range supported atomically. An arbitrary range can be accomplished by using multiple prefixes in a ReachableRoutes attribute (see Section 5.1 & 5.2). For example, 222-xxxx thru 999-xxxx could be represented by including the prefixes 222, 223, 224,...,23,24,...,3,4,...,9 in a ReachableRoutes attribute.
行程中的路线通过这些数字的前缀来指定一系列数字（路线的确切定义和语法见5.1.1）。任意范围的数字不能通过TRIP中的路线原子表示。前缀范围是原子支持的唯一范围类型。任意范围可通过在“可达路由”属性中使用多个前缀来实现（参见第5.1和5.2节）。例如，222 xxxx到999 xxxx可以通过在可到达路由属性中包括前缀222、223、224、…、23、24、…、3、4、…、9来表示。
Aggregation is a scaling enhancement used by an LS to reduce the number of routing entries that it has to synchronize with its peers. Aggregation may be performed by an LS when there is a set of routes {R1, R2, ...} in its TRIB such that there exists a less specific route R where every valid destination in R is also a valid destination in {R1, R2, ...} and vice-versa. Section 5 includes a description of how to combine each attribute (by type) on the {R1, R2, ...} routes into an attribute for R.
聚合是LS使用的一种扩展增强功能，用于减少必须与其对等方同步的路由条目的数量。当LS的TRIB中存在一组路由{R1，R2，…}时，可以由LS执行聚合，从而存在一个不太特定的路由R，其中R中的每个有效目的地也是{R1，R2，…}中的有效目的地，反之亦然。第5节描述了如何将{R1，R2，…}路由上的每个属性（按类型）组合为R的属性。
Note that there is no mechanism within TRIP to communicate that a particular address prefix is not used or valid within a particular address family, and thus that these addresses could be skipped during aggregation. LSs may use methods outside of TRIP to learn of invalid prefixes that may be ignored during aggregation.
请注意，TRIP中没有任何机制来传达特定地址前缀在特定地址族中未使用或无效，因此在聚合期间可以跳过这些地址。LSs可以使用TRIP之外的方法来了解聚合过程中可能忽略的无效前缀。
An LS is not required to perform aggregation, however it is recommended whenever maintaining a smaller TRIB is important. An LS decides based on its local policy whether or not to aggregate a set of routes into a single aggregate route.
LS不需要执行聚合，但只要维护较小的TRIB很重要，建议使用LS。LS根据其本地策略决定是否将一组路由聚合为单个聚合路由。
Whenever an LS aggregates multiple routes where the NextHopServer is not identical in all aggregated routes, the NextHopServer attribute of the aggregate route must be set to a signalling server in the aggregating LS's domain.
当LS聚合多个路由时，如果所有聚合路由中的NextHopServer不相同，则必须将聚合路由的NextHopServer属性设置为聚合LS域中的信令服务器。
When an LS resets the NextHopServer of any route, and this may be performed because of aggregation or other reasons, it has the effect of adding another signalling server along the signalling path to these destinations. The end result is that the signalling path between two destinations may consist of multiple signalling servers across multiple domains.
当LS重置任何路由的下一个ThopServer时，这可能是由于聚合或其他原因而执行的，其效果是沿到这些目的地的信令路径添加另一个信令服务器。最终结果是，两个目的地之间的信令路径可能由跨多个域的多个信令服务器组成。
This section describes message formats used by TRIP. Messages are sent over a reliable transport protocol connection. A message MUST be processed only after it is entirely received. The maximum message size is 4096 octets. All implementations MUST support this maximum message size. The smallest message that MAY be sent consists of a TRIP header without a data portion, or 3 octets.
本节介绍TRIP使用的消息格式。消息通过可靠的传输协议连接发送。只有在完全接收到消息后才能对其进行处理。最大消息大小为4096个八位字节。所有实现都必须支持此最大消息大小。可发送的最小消息由一个不带数据部分的跳闸报头或3个八位字节组成。
Each message has a fixed-size header. There may or may not be a data portion following the header, depending on the message type. The layout of the header fields is shown in Figure 2.
每封邮件都有一个固定大小的标题。根据消息类型，报头后面可能有数据部分，也可能没有数据部分。标题字段的布局如图2所示。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+--------------+----------------+---------------+
| Length | Type |
+--------------+----------------+---------------+
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+--------------+----------------+---------------+
| Length | Type |
+--------------+----------------+---------------+
Figure 2: TRIP Header
图2：行程总管
Length: This 2-octet unsigned integer indicates the total length of the message, including the header, in octets. Thus, it allows one to locate, in the transport-level stream, the beginning of the next message. The value of the Length field must always be at least 3 and no greater than 4096, and may be further constrained depending on the message type. No padding of extra data after the message is allowed, so the Length field must have the smallest value possible given the rest of the message.
长度：这个2-octet无符号整数表示消息的总长度，包括消息头，以八位字节为单位。因此，它允许在传输级流中定位下一条消息的开头。长度字段的值必须始终至少为3且不大于4096，并且可以根据消息类型进行进一步约束。不允许在消息之后填充额外数据，因此在给定消息其余部分的情况下，长度字段必须具有尽可能最小的值。
Type: This 1-octet unsigned integer indicates the type code of the message. The following type codes are defined:
类型：此1-octet无符号整数表示消息的类型代码。定义了以下类型代码：
1 - OPEN 2 - UPDATE 3 - NOTIFICATION 4 - KEEPALIVE
1-打开2-更新3-通知4-保留
After a transport protocol connection is established, the first message sent by each side is an OPEN message. If the OPEN message is acceptable, a KEEPALIVE message confirming the OPEN is sent back. Once the OPEN is confirmed, UPDATE, KEEPALIVE, and NOTIFICATION messages may be exchanged.
建立传输协议连接后，各方发送的第一条消息是开放消息。如果打开的消息是可接受的，则返回确认打开的KEEPALIVE消息。确认打开后，可以交换更新、保留和通知消息。
The minimum length of the OPEN message is 17 octets (including message header). OPEN messages not meeting this minimum requirement are handled as defined in Section 6.2.
打开消息的最小长度为17个八位字节（包括消息头）。未满足此最低要求的开放消息将按照第6.2节的规定进行处理。
In addition to the fixed-size TRIP header, the OPEN message contains the following fields:
除了固定大小的行程标题外，“打开”消息还包含以下字段：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+--------------+----------------+
| Version | Reserved | Hold Time |
+---------------+---------------+--------------+----------------+
| My ITAD |
+---------------+---------------+--------------+----------------+
| TRIP Identifier |
+---------------+---------------+--------------+----------------+
| Optional Parameters Len |Optional Parameters (variable)...
+---------------+---------------+--------------+----------------+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+--------------+----------------+
| Version | Reserved | Hold Time |
+---------------+---------------+--------------+----------------+
| My ITAD |
+---------------+---------------+--------------+----------------+
| TRIP Identifier |
+---------------+---------------+--------------+----------------+
| Optional Parameters Len |Optional Parameters (variable)...
+---------------+---------------+--------------+----------------+
Figure 3: TRIP OPEN Header
图3：跳闸打开收割台
Version: This 1-octet unsigned integer indicates the protocol version of the message. The current TRIP version number is 1.
版本：此1-octet无符号整数表示消息的协议版本。当前跳闸版本号为1。
Hold Time: This 2-octet unsigned integer indicates the number of seconds that the sender proposes for the value of the Hold Timer. Upon receipt of an OPEN message, an LS MUST calculate the value of the Hold Timer by using the smaller of its configured Hold Time and the Hold Time received in the OPEN message. The Hold Time MUST be either zero or at least three seconds. An implementation MAY reject connections on the basis of the Hold Time. The calculated value indicates the maximum number of seconds that may elapse between the receipt of successive KEEPALIVE and/or UPDATE messages by the sender.
保持时间：这个2-octet无符号整数表示发送方为保持计时器的值建议的秒数。收到打开消息后，LS必须使用其配置的保持时间和打开消息中接收到的保持时间中的较小者来计算保持计时器的值。保持时间必须为零或至少三秒。实现可以基于保持时间拒绝连接。计算出的值表示发送方收到连续的KEEPALIVE和/或UPDATE消息之间可能经过的最大秒数。
This 4-octet unsigned integer indicates the ITAD number of the sender. The ITAD number must be unique for this domain within this confederation of cooperating LSs.
这个4-octet无符号整数表示发送方的ITAD号。在合作LSs联盟内，此域的ITAD编号必须是唯一的。
ITAD numbers are assigned by IANA as specified in Section 13. This document reserves ITAD number 0. ITAD numbers from 1 to 255 are designated for private use.
ITAD编号由IANA按照第13节的规定分配。本文件保留ITAD编号0。从1到255的ITAD编号指定为私人使用。
TRIP Identifier: This 4-octet unsigned integer indicates the TRIP Identifier of the sender. The TRIP Identifier MUST uniquely identify this LS within its ITAD. A given LS MAY set the value of its TRIP Identifier to an IPv4 address assigned to that LS. The value of the TRIP Identifier is determined on startup and MUST be the same for all peer connections. When comparing two TRIP identifiers, the TRIP Identifier is interpreted as a numerical 4-octet unsigned integer.
行程标识符：这个4个八位无符号整数表示发送方的行程标识符。跳闸标识符必须在其ITAD内唯一标识此LS。给定的LS可以将其行程标识符的值设置为分配给该LS的IPv4地址。跳闸标识符的值在启动时确定，并且对于所有对等连接必须相同。比较两个行程标识符时，行程标识符被解释为一个数字4八位无符号整数。
Optional Parameters Length: This 2-octet unsigned integer indicates the total length of the Optional Parameters field in octets. If the value of this field is zero, no Optional Parameters are present.
可选参数长度：此2个八位无符号整数表示可选参数字段的总长度（以八位字节为单位）。如果此字段的值为零，则不存在可选参数。
Optional Parameters: This field may contain a list of optional parameters, where each parameter is encoded as a <Parameter Type, Parameter Length, Parameter Value> triplet.
可选参数：此字段可能包含可选参数列表，其中每个参数编码为<参数类型，参数长度，参数值>三元组。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+--------------+----------------+
| Parameter Type | Parameter Length |
+---------------+---------------+--------------+----------------+
| Parameter Value (variable)...
+---------------+---------------+--------------+----------------+
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+--------------+----------------+
| Parameter Type | Parameter Length |
+---------------+---------------+--------------+----------------+
| Parameter Value (variable)...
+---------------+---------------+--------------+----------------+
Figure 4: Optional Parameter Encoding
图4：可选参数编码
Parameter Type: This is a 2-octet field that unambiguously identifies individual parameters.
参数类型：这是一个2-octet字段，明确标识各个参数。
Parameter Length: This is a 2-octet field that contains the length of the Parameter Value field in octets.
参数长度：这是一个2个八位字节的字段，包含参数值字段的长度（以八位字节为单位）。
Parameter Value: This is a variable length field that is interpreted according to the value of the Parameter Type field.
参数值：这是一个可变长度字段，根据参数类型字段的值进行解释。
This document defines the following Optional Parameters for the OPEN message.
本文档为打开的消息定义了以下可选参数。
Capability Information uses Optional Parameter type 1. This is an optional parameter used by an LS to convey to its peer the list of capabilities supported by the LS. This permits an LS to learn of the capabilities of its peer LSs. Capability negotiation is defined in Section 8.
能力信息使用可选的参数类型1。这是LS使用的可选参数，用于向其对等方传递LS支持的功能列表。这允许LS了解其对等LSs的能力。第8节定义了能力协商。
The parameter contains one or more triples <Capability Code, Capability Length, Capability Value>, where each triple is encoded as shown below:
该参数包含一个或多个三元组<Capability Code，Capability Length，Capability Value>，其中每个三元组的编码如下所示：
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+--------------+----------------+
| Capability Code | Capability Length |
+---------------+---------------+--------------+----------------+
| Capability Value (variable)...
+---------------+---------------+--------------+----------------+
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+--------------+----------------+
| Capability Code | Capability Length |
+---------------+---------------+--------------+----------------+
| Capability Value (variable)...
+---------------+---------------+--------------+----------------+
Figure 5: Capability Optional Parameter
图5：能力可选参数
Capability Code: Capability Code is a 2-octet field that unambiguously identifies individual capabilities.
能力代码：能力代码是一个2-octet字段，明确标识单个能力。
Capability Length: Capability Length is a 2-octet field that contains the length of the Capability Value field in octets.
能力长度：能力长度是一个2个八位字节的字段，包含能力值字段的长度（以八位字节为单位）。
Capability Value: Capability Value is a variable length field that is interpreted according to the value of the Capability Code field.
能力值：能力值是根据能力代码字段的值解释的可变长度字段。
Any particular capability, as identified by its Capability Code, may appear more than once within the Optional Parameter.
任何由其能力代码标识的特定能力都可能在可选参数中出现多次。
This document reserves Capability Codes 32768-65535 for vendor-specific applications (these are the codes with the first bit of the code value equal to 1). This document reserves value 0. Capability Codes (other than those reserved for vendor specific use) are controlled by IANA. See Section 13 for IANA considerations.
本文件为供应商特定应用保留能力代码32768-65535（这些代码的第一位代码值等于1）。此文档保留值0。能力代码（为供应商特定用途保留的代码除外）由IANA控制。IANA注意事项见第13节。
The following Capability Codes are defined by this specification:
本规范定义了以下能力代码：
Code Capability 1 Route Types Supported 2 Send Receive Capability
代码功能1支持的路由类型2发送接收功能
The Route Types Supported Capability Code lists the route types supported in this peering session by the transmitting LS. An LS MUST NOT use route types that are not supported by the peer LS in any particular peering session. If the route types supported by a peer are not satisfactory, an LS SHOULD terminate the peering session. The format for a Route Type is:
支持的路由类型功能代码列出了传输LS在此对等会话中支持的路由类型。LS不得使用对等LS在任何特定对等会话中不支持的路由类型。如果对等方支持的路由类型不令人满意，LS应终止对等会话。管线类型的格式为：
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+--------------+----------------+
| Address Family | Application Protocol |
+---------------+---------------+--------------+----------------+
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+--------------+----------------+
| Address Family | Application Protocol |
+---------------+---------------+--------------+----------------+
Figure 6: Route Types Supported Capability
图6：支持能力的路由类型
The Address Family and Application Protocol are as defined in Section 5.1.1. Address Family gives the address family being routed (within the ReachableRoutes attribute). The application protocol lists the application for which the routes apply. As an example, a route type for TRIP could be <E.164, SIP>, indicating a set of E.164 destinations for the SIP protocol.
地址系列和应用协议如第5.1.1节所述。Address Family提供正在路由的地址族（在“可访问路由”属性中）。应用程序协议列出路由适用的应用程序。例如，TRIP的路由类型可以是<E.164，SIP>，表示SIP协议的一组E.164目的地。
The Route Types Supported Capability MAY contain multiple route types in the capability. The number of route types within the capability is the maximum number that can fit given the capability length. The Capability Code is 1 and the length is variable.
支持的路由类型功能中可能包含多个路由类型。能力范围内的路由类型数量是给定能力长度可容纳的最大数量。能力代码为1，长度可变。
This capability specifies the mode in which the LS will operate with this particular peer. The possible modes are: Send Only mode, Receive Only mode, or Send Receive mode. The default mode is Send Receive mode.
此功能指定LS将与此特定对等机一起运行的模式。可能的模式有：仅发送模式、仅接收模式或发送-接收模式。默认模式为发送-接收模式。
In Send Only mode, an LS transmits UPDATE messages to its peer, but the peer MUST NOT transmit UPDATE messages to that LS. If an LS in Send Only mode receives an UPDATE message from its peer, it MUST discard that message, but no further action should be taken.
在仅发送模式下，LS向其对等方发送更新消息，但对等方不得向该LS发送更新消息。如果处于仅发送模式的LS从其对等方接收到更新消息，则必须放弃该消息，但不应采取进一步的操作。
The UPDATE messages sent by an LS in Send Only mode to its intra-domain peer MUST include the ITAD Topology attribute whenever the topology changes. A useful application of an LS in Send Only mode with an external peer is to enable gateway registration services.
LS在仅发送模式下向其域内对等方发送的更新消息必须包含ITAD拓扑属性，只要拓扑发生更改。LS在仅发送模式下与外部对等机的一个有用应用是启用网关注册服务。
If a service provider terminates calls to a set of gateways it owns, but never initiates calls, it can set its LSs to operate in Send Only mode, since they only ever need to generate UPDATE messages, not receive them. If an LS in Send Receive mode has a peering session with a peer in Send Only mode, that LS MUST set its route dissemination policy such that it does not send any UPDATE messages to its peer.
如果服务提供商终止对其拥有的一组网关的呼叫，但从不发起呼叫，则可以将其LSs设置为仅发送模式，因为它们只需要生成更新消息，而不需要接收更新消息。如果处于发送-接收模式的LS与处于仅发送模式的对等方具有对等会话，则该LS必须设置其路由分发策略，以便不会向其对等方发送任何更新消息。
In Receive Only mode, the LS acts as a passive TRIP listener. It receives and processes UPDATE messages from its peer, but it MUST NOT transmit any UPDATE messages to its peer. This is useful for management stations that wish to collect topology information for display purposes.
在仅接收模式下，LS充当被动跳闸侦听器。它接收并处理来自其对等方的更新消息，但不得向其对等方发送任何更新消息。这对于希望收集拓扑信息以进行显示的管理工作站非常有用。
The behavior of an LS in Send Receive mode is the default TRIP operation specified throughout this document.
LS在发送-接收模式下的行为是本文档中指定的默认跳闸操作。
The Send Receive capability is a 4-octet unsigned numeric value. It can only take one of the following three values:
发送-接收功能是一个4-octet无符号数值。它只能采用以下三个值之一：
1 - Send Receive mode 2 - Send only mode 3 - Receive Only mode
1-发送-接收模式2-仅发送模式3-仅接收模式
A peering session MUST NOT be established between two LSs if both of them are in Send Only mode or if both of them are in Receive Only mode. If a peer LS detects such a capability mismatch when processing an OPEN message, it MUST respond with a NOTIFICATION message and close the peer session. The error code in the NOTIFICATION message must be set to "Capability Mismatch."
如果两个LSs都处于仅发送模式或均处于仅接收模式，则不得在两个LSs之间建立对等会话。如果对等LS在处理打开的消息时检测到这种能力不匹配，它必须以通知消息响应并关闭对等会话。通知消息中的错误代码必须设置为“功能不匹配”
An LS MUST be configured in the same Send Receive mode for all peers.
必须为所有对等方在相同的发送-接收模式下配置LS。
UPDATE messages are used to transfer routing information between LSs. The information in the UPDATE packet can be used to construct a graph describing the relationships between the various ITADs. By applying rules to be discussed, routing information loops and some other anomalies can be prevented.
更新消息用于在LSs之间传输路由信息。更新包中的信息可用于构建描述各种ITAD之间关系的图。通过应用要讨论的规则，可以防止路由信息循环和一些其他异常。
An UPDATE message is used to both advertise and withdraw routes from service. An UPDATE message may simultaneously advertise and withdraw TRIP routes.
更新消息用于通告和从服务中撤回路由。更新消息可同时公布和撤回行程路线。
In addition to the TRIP header, the TRIP UPDATE contains a list of routing attributes as shown in Figure 7. There is no padding between routing attributes.
除了TRIP头之外，TRIP更新还包含一个路由属性列表，如图7所示。路由属性之间没有填充。
+------------------------------------------------+--...
| First Route Attribute | Second Route Attribute | ...
+------------------------------------------------+--...
+------------------------------------------------+--...
| First Route Attribute | Second Route Attribute | ...
+------------------------------------------------+--...
Figure 7: TRIP UPDATE Format
图7：行程更新格式
The minimum length of an UPDATE message is 3 octets (there are no mandatory attributes in TRIP).
更新消息的最小长度为3个八位字节（TRIP中没有强制属性）。
A variable length sequence of routing attributes is present in every UPDATE message. Each attribute is a triple <attribute type, attribute length, attribute value> of variable length.
每个更新消息中都存在一个长度可变的路由属性序列。每个属性都是长度可变的三重<attribute type，attribute length，attribute value>。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+--------------+----------------+
| Attr. Flags |Attr. Type Code| Attr. Length |
+---------------+---------------+--------------+----------------+
| Attribute Value (variable) |
+---------------+---------------+--------------+----------------+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+--------------+----------------+
| Attr. Flags |Attr. Type Code| Attr. Length |
+---------------+---------------+--------------+----------------+
| Attribute Value (variable) |
+---------------+---------------+--------------+----------------+
Figure 8: Routing Attribute Format
图8：路由属性格式
Attribute Type is a two-octet field that consists of the Attribute Flags octet followed by the Attribute Type Code octet.
属性类型是一个两个八位字节字段，由属性标志八位字节和属性类型代码八位字节组成。
The Attribute Type Code defines the type of attribute. The basic TRIP-defined Attribute Type Codes are discussed later in this section. Attributes MUST appear in the UPDATE message in numerical order of the Attribute Type Code. An attribute MUST NOT be included more than once in the same UPDATE message. Attribute Flags are used to control attribute processing when the attribute type is unknown. Attribute Flags are further defined in Section 4.3.2.
属性类型代码定义属性的类型。本节后面将讨论基本行程定义属性类型代码。属性必须以属性类型代码的数字顺序出现在更新消息中。同一更新消息中不得多次包含属性。属性标志用于在属性类型未知时控制属性处理。第4.3.2节进一步定义了属性标志。
This document reserves Attribute Type Codes 224-255 for vendor-specific applications (these are the codes with the first three bits of the code equal to 1). This document reserves value 0. Attribute Type Codes (other than those reserved for vendor specific use) are controlled by IANA. See Section 13 for IANA considerations.
本文档为特定于供应商的应用程序保留属性类型代码224-255（这些代码的前三位等于1）。此文档保留值0。属性类型代码（为供应商特定用途保留的代码除外）由IANA控制。IANA注意事项见第13节。
The third and the fourth octets of the route attribute contain the length of the attribute value field in octets.
route属性的第三个和第四个八位字节包含属性值字段的长度（以八位字节为单位）。
The remaining octets of the attribute represent the Attribute Value and are interpreted according to the Attribute Flags and the Attribute Type Code. The basic supported attribute types, their values, and their uses are defined in this specification. These are the attributes necessary for proper loop free operation of TRIP, both inter-domain and intra-domain. Additional attributes may be defined in future documents.
属性的其余八位字节表示属性值，并根据属性标志和属性类型代码进行解释。本规范中定义了受支持的基本属性类型、它们的值及其用途。这些是域间和域内TRIP正确无环运行所必需的属性。其他属性可能在将来的文档中定义。
It is clear that the set of attributes for TRIP will evolve over time. Hence it is essential that mechanisms be provided to handle attributes with unrecognized types. The handling of unrecognized attributes is controlled via the flags field of the attribute. Recognized attributes should be processed according to their specific definition.
很明显，TRIP的属性集将随着时间的推移而变化。因此，必须提供机制来处理具有无法识别类型的属性。无法识别属性的处理通过属性的flags字段进行控制。应根据其特定定义处理已识别的属性。
The following are the attribute flags defined by this specification: Bit Flag 0 Well-Known Flag 1 Transitive Flag 2 Dependent Flag 3 Partial Flag 4 Link-state Encapsulated Flag
以下是本规范定义的属性标志：位标志0已知标志1传递标志2依赖标志3部分标志4链路状态封装标志
The high-order bit (bit 0) of the Attribute Flags octet is the Well-Known Bit. It defines whether the attribute is not well-known (if set to 1) or well-known (if set to 0). Implementations are not required to support not well-known attributes, but MUST support well-known attributes.
属性标志八位字节的高阶位（位0）是众所周知的位。它定义属性是不为人所知（如果设置为1）还是为人所知（如果设置为0）。实现不需要支持非已知属性，但必须支持已知属性。
The second high-order bit (bit 1) of the Attribute Flags octet is the Transitive bit. It defines whether a not well-known attribute is transitive (if set to 1) or non-transitive (if set to 0). For well-known attributes, the Transitive bit MUST be zero on transmit and MUST be ignored on receipt.
属性标志八位字节的第二高位（第1位）是可传递位。它定义了未知属性是可传递的（如果设置为1）还是不可传递的（如果设置为0）。对于众所周知的属性，传递位在传输时必须为零，在接收时必须忽略。
The third high-order bit (bit 2) of the Attribute Flags octet is the Dependent bit. It defines whether a transitive attribute is
属性标志八位字节的第三高位（第2位）为从属位。它定义传递属性是否为
dependent (if set to 1) or independent (if set to 0). For well-known attributes and for non-transitive attributes, the Dependent bit is irrelevant, and MUST be set to zero on transmit and MUST be ignored on receipt.
从属（如果设置为1）或独立（如果设置为0）。对于已知属性和非传递属性，依赖位是无关的，在传输时必须设置为零，在接收时必须忽略。
The fourth high-order bit (bit 3) of the Attribute Flags octet is the Partial bit. It defines whether the information contained in the not well-known transitive attribute is partial (if set to 1) or complete (if set to 0). For well-known attributes and for non-transitive attributes the Partial bit MUST be set to 0 on transmit and MUST be ignored on receipt.
属性标志八位字节的第四高位（第3位）是部分位。它定义了未知可传递属性中包含的信息是部分的（如果设置为1）还是完整的（如果设置为0）。对于已知属性和非传递属性，部分位在传输时必须设置为0，在接收时必须忽略。
The fifth high-order bit (bit 4) of the Attribute Flags octet is the Link-state Encapsulation bit. This bit is only applicable to certain attributes (ReachableRoutes and WithdrawnRoutes) and determines the encapsulation of the routes within those attributes. If this bit is set, link-state encapsulation is used within the attribute. Otherwise, standard encapsulation is used within the attribute. The Link-state Encapsulation technique is described in Section 4.3.2.4. This flag is only valid on the ReachableRoutes and WithdrawnRoutes attributes. It MUST be cleared on transmit and MUST be ignored on receipt for all other attributes.
属性标志八位字节的第五高位（第4位）是链路状态封装位。此位仅适用于某些属性（可达路由和取回路由），并确定这些属性中路由的封装。如果设置了此位，则在属性中使用链接状态封装。否则，在属性中使用标准封装。链路状态封装技术见第4.3.2.4节。此标志仅对“可访问路由”和“撤回路由”属性有效。对于所有其他属性，在传输时必须清除该属性，在接收时必须忽略该属性。
The other bits of the Attribute Flags octet are unused. They MUST be zeroed on transmit and ignored on receipt.
属性标志八位字节的其他位未使用。它们必须在传输时归零，在接收时忽略。
Any recognized attribute can be used as input to the route selection process, although the utility of some attributes in route selection is minimal.
任何已识别的属性都可以用作路线选择过程的输入，尽管某些属性在路线选择中的效用最小。
TRIP provides for two variations of transitivity due to the fact that intermediate LSs need not modify the NextHopServer when propagating routes. Attributes may be non-transitive, dependent transitive, or independent transitive. An attribute cannot be both dependent transitive and independent transitive.
TRIP提供了两种传递性变体，因为中间LSs在传播路由时不需要修改NextHopServer。属性可以是非传递的、依赖传递的或独立传递的。属性不能同时是依赖传递和独立传递。
Unrecognized independent transitive attributes may be propagated by any intermediate LS. Unrecognized dependent transitive attributes MAY only be propagated if the LS is NOT changing the next-hop server. The transitivity variations permit some unrecognized attributes to be carried end-to-end (independent transitive), some to be carried between adjacent next-hop servers (dependent transitive), and other to be restricted to peer LSs (non-transitive).
无法识别的独立可传递属性可能由任何中间LS传播。仅当LS未更改下一跳服务器时，才能传播无法识别的依赖传递属性。传递性变体允许端到端（独立传递）携带一些无法识别的属性，允许在相邻的下一跳服务器之间携带一些属性（依赖传递），允许将其他属性限制在对等LSs（非传递）。
An LS that passes an unrecognized transitive attribute to a peer MUST set the Partial flag on that attribute. Any LS along a path MAY insert a transitive attribute into a route. If any LS except the originating LS inserts a new independent transitive attribute into a route, then it MUST set the Partial flag on that attribute. If any LS except an LS that modifies the NextHopServer inserts a new dependent transitive attribute into a route, then it MUST set the Partial flag on that attribute. The Partial flag indicates that not every LS along the relevant path has processed and understood the attribute. For independent transitive attributes, the "relevant path" is the path given in the AdvertisementPath attribute. For dependent transitive attributes, the relevant path consists only of those domains thru which this object has passed since the NextHopServer was last modified. The Partial flag in an independent transitive attribute MUST NOT be unset by any other LS along the path. The Partial flag in a dependent transitive attribute MUST be reset whenever the NextHopServer is changed, but MUST NOT be unset by any LS that is not changing the NextHopServer.
将无法识别的可传递属性传递给对等方的LS必须在该属性上设置部分标志。路径上的任何LS都可以将可传递属性插入路由。如果原始LS以外的任何LS将新的独立可传递属性插入路由，则必须在该属性上设置部分标志。如果除修改NextHopServer的LS之外的任何LS将新的依赖传递属性插入路由，则必须在该属性上设置部分标志。Partial标志表示相关路径上并非每个LS都已处理并理解该属性。对于独立的可传递属性，“相关路径”是AdvertisementPath属性中给定的路径。对于依赖传递属性，相关路径仅包含自上次修改NextHopServer以来此对象通过的那些域。独立可传递属性中的部分标志不能由路径上的任何其他LS取消设置。无论何时更改NextHopServer，都必须重置依赖传递属性中的部分标志，但任何未更改NextHopServer的LS都不能取消设置该标志。
The rules governing the addition of new non-transitive attributes are defined independently for each non-transitive attribute. Any attribute MAY be updated by an LS in the path.
控制添加新的非传递属性的规则是为每个非传递属性独立定义的。路径中的LS可以更新任何属性。
Each attribute defines how it is to be handled during route aggregation.
每个属性定义在路由聚合期间如何处理它。
The rules governing the handling of unknown attributes are guided by the Attribute Flags. Unrecognized transitive attributes are dropped during aggregation. There should be no unrecognized non-transitive attributes during aggregation because non-transitive attributes must be processed by the local LS in order to be propagated.
控制未知属性处理的规则由属性标志指导。聚合过程中会删除无法识别的可传递属性。聚合期间不应存在无法识别的非传递属性，因为非传递属性必须由本地LS处理才能传播。
Normally attributes have the simple format as described in Section 4.3.1. If the Link-state Encapsulation Flag is set, then the two additional fields are added to the attribute header as shown in Figure 9.
通常，属性具有第4.3.1节所述的简单格式。如果设置了linkstate封装标志，那么这两个附加字段将添加到属性头中，如图9所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+--------------+----------------+
| Attr. Flags |Attr. Type Code| Attr. Length |
+---------------+---------------+--------------+----------------+
| Originator TRIP Identifier |
+---------------+---------------+--------------+----------------+
| Sequence Number |
+---------------+---------------+--------------+----------------+
| Attribute Value (variable) |
+---------------+---------------+--------------+----------------+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+--------------+----------------+
| Attr. Flags |Attr. Type Code| Attr. Length |
+---------------+---------------+--------------+----------------+
| Originator TRIP Identifier |
+---------------+---------------+--------------+----------------+
| Sequence Number |
+---------------+---------------+--------------+----------------+
| Attribute Value (variable) |
+---------------+---------------+--------------+----------------+
Figure 9: Link State Encapsulation
图9：链接状态封装
The Originator TRIP ID and Sequence Number are used to control the flooding of routing updates within a collection of servers. These fields are used to detect duplicate and old routes so that they are not further propagated to other LSs. The use of these fields is defined in Section 10.1.
发起者TRIP ID和序列号用于控制服务器集合中路由更新的泛滥。这些字段用于检测重复和旧路由，以便它们不会进一步传播到其他LSs。第10.1节定义了这些字段的使用。
There are no Mandatory attributes in TRIP. However, there are Conditional Mandatory attributes. A conditional mandatory attribute is an attribute, which MUST be included in an UPDATE message if another attribute is included in that message. For example, if an UPDATE message includes a ReachableRoutes attribute, it MUST include an AdvertisementPath attribute as well.
TRIP中没有强制属性。但是，存在条件强制属性。条件强制属性是一个属性，如果更新消息中包含另一个属性，则该属性必须包含在该消息中。例如，如果更新消息包含ReachableRoutes属性，则它还必须包含AdvertisementPath属性。
The three base attributes in TRIP are WithdrawnRoutes, ReachableRoutes, and ITAD Topology. Their presence in an UPDATE message is entirely optional and independent of any other attributes.
TRIP中的三个基本属性是提取路由、可到达路由和ITAD拓扑。它们在更新消息中的存在是完全可选的，与任何其他属性无关。
This section summarizes the attributes that may be carried in an UPDATE message. Attributes MUST appear in the UPDATE message in increasing order of the Attribute Type Code. Additional details are provided in Section 5.
本节总结了更新消息中可能包含的属性。属性必须按属性类型代码的递增顺序出现在更新消息中。第5节提供了其他详细信息。
This attribute lists a set of routes that are being withdrawn from service. The transmitting LS has determined that these routes should no longer be advertised, and is propagating this information to its peers.
此属性列出了一组正在退出服务的路由。发射LS已确定这些路由不应再被通告，并且正在向其对等方传播该信息。
This attribute lists a set of routes that are being added to service. These routes will have the potential to be inserted into the Adj-TRIBs-In of the receiving LS and the route selection process will be applied to them.
此属性列出要添加到服务的一组路由。这些路线有可能被插入到接收LS的Adj TRIB中，路线选择过程将应用于它们。
This attribute gives the identity of the entity to which messages should be sent along this routed path. It specifies the identity of the next hop server as either a host domain name or an IP address. It MAY optionally specify the UDP/TCP port number for the next hop signaling server. If not specified, then the default port SHOULD be used. The NextHopServer is specific to the set of destinations and application protocol defined in the ReachableRoutes attribute. Note that this is NOT necessarily the address to which media (voice, video, etc.) should be transmitted, it is only for the application protocol as given in the ReachableRoutes attribute.
此属性提供沿此路由路径向其发送消息的实体的标识。它将下一跳服务器的标识指定为主机域名或IP地址。它可以选择指定下一跳信令服务器的UDP/TCP端口号。如果未指定，则应使用默认端口。NextHopServer特定于在ReachableRoutes属性中定义的目标集和应用程序协议。请注意，这不一定是媒体（语音、视频等）应传输到的地址，它仅适用于可访问路由属性中给出的应用协议。
The AdvertisementPath is analogous to the AS_PATH in BGP4 [3]. The attribute records the sequence of domains through which this advertisement has passed. The attribute is used to detect when the routing advertisement is looping. This attribute does NOT reflect the path through which messages following this route would traverse. Since the next-hop need not be modified by each LS, the actual path to the destination might not have to traverse every domain in the AdvertisementPath.
广告路径类似于BGP4[3]中的AS_路径。该属性记录此播发通过的域序列。该属性用于检测路由播发何时循环。此属性不反映遵循此路由的消息将通过的路径。由于每个LS不需要修改下一个跃点，因此到达目的地的实际路径可能不必遍历AdvertisementPath中的每个域。
The RoutedPath attribute is analogous to the AdvertisementPath attribute, except that it records the actual path (given by the list of domains) *to* the destinations. Unlike AdvertisementPath, which is modified each time the route is propagated, RoutedPath is only modified when the NextHopServer attribute changes. Thus, it records the subset of the AdvertisementPath which signaling messages following this particular route would traverse.
RoutedPath属性类似于AdvertisementPath属性，只是它记录了到*目的地的实际路径（由域列表给出）。与每次传播路由时都会修改的AdvertisementPath不同，RoutedPath仅在NextHopServer属性更改时才会修改。因此，它记录了遵循此特定路由的信令消息将要穿越的广告路径的子集。
The AtomicAggregate attribute indicates that a route may actually include domains not listed in the RoutedPath. If an LS, when presented with a set of overlapping routes from a peer LS, selects a less specific route without selecting the more specific route, then the LS MUST include the AtomicAggregate attribute with the route. An
AtomicAggregate属性表示路由实际上可能包括RoutedPath中未列出的域。如果一个LS在显示一组来自对等LS的重叠路由时，选择了一个不太特定的路由，而没有选择更特定的路由，那么LS必须在路由中包含AtomicAggregate属性。一
LS receiving a route with an AtomicAggregate attribute MUST NOT make the set of destinations more specific when advertising it to other LSs.
接收具有AtomicAggregate属性的路由的LS在向其他LSs播发时，不得使目的地集更具体。
The LocalPreference attribute is an intra-domain attribute used to inform other LSs of the local LS's preference for a given route. The preference of a route is calculated at the ingress to a domain and passed as an attribute with that route throughout the domain. Other LSs within the same ITAD use this attribute in their route selection process. This attribute has no significance between domains.
LocalPreference属性是一个域内属性，用于通知其他LSs本地LS对给定路由的偏好。路由的首选项在域的入口处计算，并作为该路由在整个域中的属性传递。同一ITAD中的其他LSs在其路由选择过程中使用此属性。此属性在域之间没有意义。
There may be more than one LS peering relationship between neighboring domains. The MultiExitDisc attribute is used by an LS to express a preference for one link between the domains over another link between the domains. The use of the MultiExitDisc attribute is controlled by local policy.
相邻域之间可能存在多个LS对等关系。LS使用MultiExitDisc属性表示域之间的一个链接优于域之间的另一个链接。MultiExitDisc属性的使用由本地策略控制。
The Communities attribute is not a well-known attribute. It is used to facilitate and simplify the control of routing information by grouping destinations into communities.
Communities属性不是众所周知的属性。它通过将目的地分组到社区中来促进和简化路由信息的控制。
The ITAD topology attribute is an intra-domain attribute that is used by LSs to indicate their intra-domain topology to other LSs in the domain.
ITAD拓扑属性是域内属性，LSs使用该属性向域中的其他LSs指示其域内拓扑。
The ConvertedRoute attribute indicates that an intermediate LS has altered the route by changing the route's Application Protocol.
ConvertedRoute属性表示中间LS通过更改路由的应用协议更改了路由。
TRIP does not use any transport-based keep-alive mechanism to determine if peers are reachable. Instead, KEEPALIVE messages are exchanged between peers often enough as not to cause the Hold Timer to expire. A reasonable maximum time between KEEPALIVE messages would be one third of the Hold Time interval. KEEPALIVE messages MUST NOT be sent more than once every 3 seconds. An implementation SHOULD adjust the rate at which it sends KEEPALIVE messages as a function of the negotiated Hold Time interval.
TRIP不使用任何基于传输的保持活动机制来确定对等点是否可访问。相反，在对等方之间交换KEEPALIVE消息的频率足够高，不会导致保持计时器过期。KEEPALIVE消息之间合理的最长时间是保持时间间隔的三分之一。KEEPALIVE消息不能每3秒发送一次以上。实现应该根据协商的保持时间间隔调整发送KEEPALIVE消息的速率。
If the negotiated Hold Time interval is zero, then periodic KEEPALIVE messages MUST NOT be sent.
如果协商的保持时间间隔为零，则不得发送定期的KEEPALIVE消息。
The KEEPALIVE message consists of only a message header and has a length of 3 octets.
KEEPALIVE消息只包含一个消息头，长度为3个八位字节。
A NOTIFICATION message is sent when an error condition is detected. The TRIP transport connection is closed immediately after sending a NOTIFICATION message.
当检测到错误情况时，将发送通知消息。发送通知消息后，行程传输连接立即关闭。
In addition to the fixed-size TRIP header, the NOTIFICATION message contains the following fields:
除了固定大小的行程标题外，通知消息还包含以下字段：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+--------------+----------------+
| Error Code | Error Subcode | Data... (variable)
+---------------+---------------+--------------+----------------+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+--------------+----------------+
| Error Code | Error Subcode | Data... (variable)
+---------------+---------------+--------------+----------------+
Figure 10: TRIP NOTIFICATION Format
图10：行程通知格式
Error Code: This 1-octet unsigned integer indicates the type of NOTIFICATION. The following Error Codes have been defined:
错误代码：此1-octet无符号整数表示通知的类型。已定义以下错误代码：
Error Code Symbolic Name Reference 1 Message Header Error Section 6.1 2 OPEN Message Error Section 6.2 3 UPDATE Message Error Section 6.3 4 Hold Timer Expired Section 6.5 5 Finite State Machine Error Section 6.6 6 Cease Section 6.7
错误代码符号名称参考1消息头错误第6.1节2打开消息错误第6.2节3更新消息错误第6.3节4保持计时器过期第6.5节5有限状态机错误第6.6节6停止第6.7节
Error Subcode: This 1-octet unsigned integer provides more specific information about the nature of the reported error. Each Error Code may have one or more Error Subcodes associated with it. If no appropriate Error Subcode is defined, then a zero (Unspecific) value is used for the Error Subcode field.
错误子代码：此1-octet无符号整数提供有关报告错误性质的更具体信息。每个错误代码可能有一个或多个与之关联的错误子代码。如果未定义适当的错误子代码，则错误子代码字段将使用零（非特定）值。
Message Header Error Subcodes: 1 - Bad Message Length. 2 - Bad Message Type.
消息头错误子代码：1-错误消息长度。2-错误消息类型。
OPEN Message Error Subcodes: 1 - Unsupported Version Number. 2 - Bad Peer ITAD. 3 - Bad TRIP Identifier. 4 - Unsupported Optional Parameter. 5 - Unacceptable Hold Time. 6 - Unsupported Capability. 7 - Capability Mismatch.
打开消息错误子代码：1-不支持的版本号。2-坏同伴ITAD。3-错误行程标识符。4-不支持的可选参数。5-不可接受的保持时间。6-不支持的功能。7-能力不匹配。
UPDATE Message Error Subcodes: 1 - Malformed Attribute List. 2 - Unrecognized Well-known Attribute. 3 - Missing Well-known Mandatory Attribute. 4 - Attribute Flags Error. 5 - Attribute Length Error. 6 - Invalid Attribute.
更新消息错误子代码：1-属性列表格式不正确。2-无法识别的已知属性。3-缺少众所周知的强制属性。4-属性标志错误。5-属性长度错误。6-无效属性。
Data: This variable-length field is used to diagnose the reason for the NOTIFICATION. The contents of the Data field depend upon the Error Code and Error Subcode.
数据：此可变长度字段用于诊断通知的原因。数据字段的内容取决于错误代码和错误子代码。
Note that the length of the data can be determined from the message length field by the formula:
请注意，数据的长度可以通过以下公式从消息长度字段确定：
Data Length = Message Length - 5
数据长度=消息长度-5
The minimum length of the NOTIFICATION message is 5 octets (including message header).
通知消息的最小长度为5个八位字节（包括消息头）。
This section provides details on the syntax and semantics of each TRIP UPDATE attribute.
本节详细介绍了每个行程更新属性的语法和语义。
Conditional Mandatory: False. Required Flags: Well-known. Potential Flags: Link-State Encapsulation (when flooding). TRIP Type Code: 1
条件强制：False。所需标志：众所周知。潜在标志：链接状态封装（泛洪时）。行程类型代码：1
The WithdrawnRoutes specifies a set of routes that are to be removed from service by the receiving LS(s). The set of routes MAY be empty, indicated by a length field of zero.
取款路由指定接收LS将从服务中删除的一组路由。路由集可能为空，由零长度字段表示。
The WithdrawnRoutes Attribute encodes a sequence of routes in its value field. The format for individual routes is given in Section 5.1.1.1. The WithdrawnRoutes Attribute lists the individual routes sequentially with no padding as shown in Figure 11. Each route includes a length field so that the individual routes within the attribute can be delineated.
“提取路由”属性在其值字段中对路由序列进行编码。单独路线的格式见第5.1.1.1节。DrawnRoutes属性按顺序列出各个路由，没有填充，如图11所示。每个管线都包含一个长度字段，以便可以描绘属性中的各个管线。
+---------------------+---------------------+...
| WithdrawnRoute1... | WithdrawnRoute2... |...
+---------------------+---------------------+...
+---------------------+---------------------+...
| WithdrawnRoute1... | WithdrawnRoute2... |...
+---------------------+---------------------+...
Figure 11: WithdrawnRoutes Format
图11：取款路由格式
The generic format for a TRIP route is given in Figure 12.
出行路线的通用格式如图12所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+--------------+----------------+
| Address Family | Application Protocol |
+---------------+---------------+--------------+----------------+
| Length | Address (variable) ...
+---------------+---------------+--------------+----------------+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+--------------+----------------+
| Address Family | Application Protocol |
+---------------+---------------+--------------+----------------+
| Length | Address (variable) ...
+---------------+---------------+--------------+----------------+
Figure 12: Generic TRIP Route Format
图12：一般出行路线格式
Address Family: The address family field gives the type of address for the route. Three address families are defined in this Section:
地址族：“地址族”字段提供路线的地址类型。本节定义了三个地址族：
Code Address Family 1 Decimal Routing Numbers 2 PentaDecimal Routing Numbers 3 E.164 Numbers
代码地址系列1十进制路由编号2五进制路由编号3 E.164编号
This document reserves address family code 0. This document reserves address family codes 32768-65535 for vendor-specific applications (these are the codes with the first bit of the code value equal to 1). Additional address families may be defined in the future. Assignment of address family codes is controlled by IANA. See Section 13 for IANA considerations.
此文档保留地址族代码0。本文件为供应商特定应用保留地址系列代码32768-65535（这些代码的第一位代码值等于1）。将来可能会定义其他地址族。地址族代码的分配由IANA控制。IANA注意事项见第13节。
Application Protocol: The application protocol gives the protocol for which this routing table is maintained. The currently defined application protocols are:
应用协议：应用协议给出维护此路由表的协议。当前定义的应用程序协议包括：
Code Protocol 1 SIP 2 H.323-H.225.0-Q.931 3 H.323-H.225.0-RAS 4 H.323-H.225.0-Annex-G
代码协议1 SIP 2 H.323-H.225.0-Q.931 3 H.323-H.225.0-RAS 4 H.323-H.225.0-附录G
This document reserves application protocol code 0. This document reserves application protocol codes 32768-65535 for vendor-specific applications (these are the codes with the first bit of the code value equal to 1). Additional application protocols may be defined in the future. Assignment of application protocol codes is controlled by IANA. See Section 13 for IANA considerations.
本文档保留应用程序协议代码0。本文件为供应商特定应用保留应用协议代码32768-65535（这些代码的第一位代码值等于1）。将来可能会定义其他应用程序协议。应用协议代码的分配由IANA控制。IANA注意事项见第13节。
Length: The length of the address field, in bytes.
长度：地址字段的长度，以字节为单位。
Address: This is an address (prefix) of the family type given by Address Family. The octet length of the address is variable and is determined by the length field of the route.
地址：这是地址族给定的族类型的地址（前缀）。地址的八位字节长度是可变的，由路由的长度字段决定。
The Decimal Routing Numbers address family is a super set of all E.164 numbers, national numbers, local numbers, and private numbers. It can also be used to represent the decimal routing numbers used in conjunction with Number Portability in some countries/regions. A set of telephone numbers is specified by a Decimal Routing Number prefix. Decimal Routing Number prefixes are represented by a string of digits, each digit encoded by its ASCII character representation. This routing object covers all phone numbers starting with this prefix. The syntax for the Decimal Routing Number prefix is:
十进制路由号码地址族是所有E.164号码、国家号码、本地号码和私人号码的超集。它还可用于表示在某些国家/地区与号码可移植性结合使用的十进制路由号码。一组电话号码由十进制路由号码前缀指定。十进制路由号码前缀由一个数字字符串表示，每个数字由其ASCII字符表示形式编码。此路由对象覆盖以此前缀开头的所有电话号码。十进制路由编号前缀的语法为：
Decimal-routing-number = *decimal-digit
decimal-digit = DECIMAL-DIGIT
DECIMAL-DIGIT = "0"|"1"|"2"|"3"|"4"|"5"|"6"|"7"|"8"|"9"
Decimal-routing-number = *decimal-digit
decimal-digit = DECIMAL-DIGIT
DECIMAL-DIGIT = "0"|"1"|"2"|"3"|"4"|"5"|"6"|"7"|"8"|"9"
This DECIMAL Routing Number prefix is not bound in length. This format is similar to the format for a global telephone number as defined in SIP [8] without visual separators and without the "+" prefix for international numbers. This format facilitates efficient comparison when using TRIP to route SIP or H323, both of which use character based representations of phone numbers. The prefix length
此十进制路由号码前缀的长度未绑定。此格式类似于SIP[8]中定义的全球电话号码格式，没有可视分隔符，也没有国际号码的“+”前缀。这种格式有助于在使用TRIP-to-route SIP或H323时进行有效比较，这两种协议都使用基于字符的电话号码表示。前缀长度
is determined from the length field of the route. The type of Decimal Routing Number (private, local, national, or international) can be deduced from the first few digits of the prefix.
由路线的长度字段确定。十进制路由号码的类型（专用、本地、国家或国际）可以从前缀的前几个数字推断出来。
This address family is used to represent PentaDecimal Routing Numbers used in conjunction with Number Portability in some countries/regions. PentaDecimal Routing Number prefixes are represented by a string of digits, each digit encoded by its ASCII character representation. This routing object covers all routing numbers starting with this prefix. The syntax for the PentaDecimal Routing Number prefix is:
此地址族用于表示在某些国家/地区与号码可移植性结合使用的五进制路由号码。五进制路由号码前缀由一个数字字符串表示，每个数字由其ASCII字符表示进行编码。此路由对象覆盖以此前缀开头的所有路由编号。五进制路由编号前缀的语法为：
PentaDecimal-routing-number = *pentadecimal-digit
pentadecimal-routing-digit = PENTADECIMAL-DIGIT
PENTADECIMAL-DIGIT = "0"|"1"|"2"|"3"|"4"|"5"|"6"|"7"|
"8"|"9"|"A"|"B"|"C"|"D"|"E"
PentaDecimal-routing-number = *pentadecimal-digit
pentadecimal-routing-digit = PENTADECIMAL-DIGIT
PENTADECIMAL-DIGIT = "0"|"1"|"2"|"3"|"4"|"5"|"6"|"7"|
"8"|"9"|"A"|"B"|"C"|"D"|"E"
Note the difference in alphabets between Decimal Routing Numbers and PentaDecimal Routing Numbers. A PentaDecimal Routing Number prefix is not bound in length.
请注意十进制路由编号和五进制路由编号之间的字母差异。五进制路由号码前缀的长度不受限制。
Note that the address family, which suits the routing numbers of a specific country/region depends on the alphabets used for routing numbers in that country/region. For example, North American routing numbers SHOULD use the Decimal Routing Numbers address family, because their alphabet is limited to the digits "0" through "9". Another example, in most European countries routing numbers use the alphabet "0" through "9" and "A" through "E", and hence these countries SHOULD use the PentaDecimal Routing Numbers address family.
请注意，适合特定国家/地区路由号码的地址系列取决于该国家/地区路由号码所使用的字母。例如，北美路由号码应使用十进制路由号码地址族，因为其字母表仅限于数字“0”到“9”。另一个例子是，在大多数欧洲国家，路由号码使用字母“0”到“9”和“A”到“E”，因此这些国家应使用五进制路由号码地址族。
The E.164 Numbers address family is dedicated to fully qualified E.164 numbers. A set of telephone numbers is specified by a E.164 prefix. E.164 prefixes are represented by a string of digits, each digit encoded by its ASCII character representation. This routing object covers all phone numbers starting with this prefix. The syntax for the E.164 prefix is:
E.164号码地址系列专用于完全合格的E.164号码。一组电话号码由E.164前缀指定。E.164前缀由一串数字表示，每个数字由其ASCII字符表示编码。此路由对象覆盖以此前缀开头的所有电话号码。E.164前缀的语法为：
E164-number = *e164-digit
E164-digit = E164-DIGIT
E164-DIGIT = "0"|"1"|"2"|"3"|"4"|"5"|"6"|"7"|"8"|"9"
E164-number = *e164-digit
E164-digit = E164-DIGIT
E164-DIGIT = "0"|"1"|"2"|"3"|"4"|"5"|"6"|"7"|"8"|"9"
This format facilitates efficient comparison when using TRIP to route SIP or H323, both of which use character based representations of phone numbers. The prefix length is determined from the length field of the route.
这种格式有助于在使用TRIP-to-route SIP或H323时进行有效比较，这两种协议都使用基于字符的电话号码表示。前缀长度由路由的长度字段确定。
The E.164 Numbers address family and the Decimal Routing Numbers address family have the same alphabet. The E.164 Numbers address family SHOULD be used whenever possible. The Decimal Routing Numbers address family can be used in case of private numbering plans or applications that do not desire to advertise fully expanded, fully qualified telephone numbers. If Decimal Routing Numbers are used to advertise non-fully qualified prefixes, the prefixes may have to be manipulated (e.g. expanded) at the boundary between ITADs. This adds significant complexity to the ITAD-Border LS, because, it has to map the prefixes from the format used in its own ITAD to the format used in the peer ITAD.
E.164编号地址族和十进制路由编号地址族具有相同的字母表。应尽可能使用E.164数字地址系列。十进制路由号码地址系列可用于不希望公布完全扩展、完全限定电话号码的专用编号计划或应用程序。如果使用十进制路由号码公布非完全限定前缀，则可能必须在ITAD之间的边界处对前缀进行操作（例如扩展）。这给ITAD边界LS增加了极大的复杂性，因为它必须将前缀从其自身ITAD中使用的格式映射到对等ITAD中使用的格式。
Conditional Mandatory: False. Required Flags: Well-known. Potential Flags: Link-State Encapsulation (when flooding). TRIP Type Code: 2
条件强制：False。所需标志：众所周知。潜在标志：链接状态封装（泛洪时）。行程类型代码：2
The ReachableRoutes attribute specifies a set of routes that are to be added to service by the receiving LS(s). The set of routes MAY be empty, as indicated by setting the length field to zero.
ReachableRoutes属性指定接收LS将添加到服务中的一组路由。路由集可能为空，如将长度字段设置为零所示。
The ReachableRoutes Attribute has the same syntax as the WithdrawnRoutes Attribute. See Section 5.1.1.
“可访问路由”属性的语法与“撤回路由”属性的语法相同。见第5.1.1节。
Routes are injected into TRIP by a method outside the scope of this specification. Possible methods include a front-end protocol, an intra-domain routing protocol, or static configuration.
路线通过本规范范围外的方法注入TRIP。可能的方法包括前端协议、域内路由协议或静态配置。
The routes in ReachableRoutes are necessary for route selection.
可达路由中的路由对于路由选择是必需的。
To aggregate multiple routes, the set of ReachableRoutes to be aggregated MUST combine to form a less specific set.
若要聚合多个路由，要聚合的可访问路由集必须合并以形成一个不太特定的集。
There is no mechanism within TRIP to communicate that a particular address prefix is not used and thus that these addresses could be skipped during aggregation. LSs MAY use methods outside of TRIP to learn of invalid prefixes that may be ignored during aggregation.
TRIP中没有任何机制可以传达未使用特定地址前缀的信息，因此在聚合期间可以跳过这些地址。LSs可以使用TRIP之外的方法来了解聚合过程中可能忽略的无效前缀。
If an LS advertises an aggregated route, it MUST include the AtomicAggregate attribute.
如果LS播发聚合路由，则它必须包含AtomicAggregate属性。
The ReachableRoutes attribute is recomputed at each LS except where flooding is being used (e.g., within a domain). It is therefore possible for an LS to change the Application Protocol field of a route before advertising that route to an external peer.
在每个LS处重新计算ReachableRoutes属性，除非正在使用泛洪（例如，在域内）。因此，LS可以在向外部对等方公布路由之前更改该路由的应用协议字段。
If an LS changes the Application Protocol of a route it advertises, it MUST include the ConvertedRoute attribute in the UPDATE message.
如果LS更改其播发的路由的应用程序协议，则必须在更新消息中包含ConvertedRoute属性。
5.2.6. Aggregation Specifics for Decimal Routing Numbers, E.164 Numbers, and PentaDecimal Routing Numbers
5.2.6. 十进制路由编号、E.164编号和五进制路由编号的聚合规范
An LS that has routes to all valid numbers in a specific prefix SHOULD advertise that prefix as the ReachableRoutes, even if there are more specific prefixes that do not actually exist on the PSTN. Generally, it takes 10 Decimal Routing/E.164 prefixes, or 15 PentaDecimal Routing prefixes, of length n to aggregate into a prefix of length n-1. However, if an LS is aware that a prefix is an invalid Decimal Routing/E.164 prefix, or PentaDecimal Routing prefix, then the LS MAY aggregate by skipping this prefix. For example, if the Decimal Routing prefix 19191 is known not to exist, then an LS can aggregate to 1919 without 19191. A prefix representing an invalid set of PSTN destinations is sometimes referred to as a "black-hole." The method by which an LS is aware of black-holes is not within the scope of TRIP, but if an LS has such knowledge, it can use the knowledge when aggregating.
在特定前缀中具有指向所有有效号码的路由的LS应将该前缀作为可到达路由进行公告，即使PSTN上实际上不存在更多特定前缀。通常，长度为n的10个十进制路由/E.164前缀或15个五进制路由前缀聚合为长度为n-1的前缀。但是，如果LS知道某个前缀是无效的十进制路由/E.164前缀或五进制路由前缀，则LS可能会跳过该前缀进行聚合。例如，如果已知十进制路由前缀19191不存在，则LS可以聚合到1919而不使用19191。表示一组无效PSTN目的地的前缀有时被称为“黑洞”。LS识别黑洞的方法不在TRIP范围内，但如果LS具有此类知识，则可以在聚合时使用这些知识。
Conditional Mandatory: True (if ReachableRoutes and/or WithdrawnRoutes attribute is present). Required Flags: Well-known. Potential Flags: None. TRIP Type Code: 3.
条件强制：True（如果存在可访问路由和/或撤回路由属性）。所需标志：众所周知。潜在标志：无。行程类型代码：3。
Given a route with application protocol A and destinations D, the NextHopServer indicates to the next-hop that messages of protocol A destined for D should be sent to it. This may or may not represent the ultimate destination of those messages.
给定具有应用程序协议a和目的地D的路由，NextHopServer向下一个跃点指示应该向其发送以D为目的地的协议a的消息。这可能表示也可能不表示这些消息的最终目的地。
For generality, the address of the next-hop server may be of various types (domain name, IPv4, IPv6, etc). The NextHopServer attribute includes the ITAD number of next-hop server, a length field, and a next-hop name or address.
为了一般性，下一跳服务器的地址可以是各种类型（域名、IPv4、IPv6等）。NextHopServer属性包括下一跳服务器的ITAD编号、长度字段和下一跳名称或地址。
The syntax for the NextHopServer is given in Figure 13.
图13给出了NextHopServer的语法。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+--------------+----------------+
| Next Hop ITAD |
+---------------+---------------+--------------+----------------+
| Length | Server (variable) ...
+---------------+---------------+--------------+----------------+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+--------------+----------------+
| Next Hop ITAD |
+---------------+---------------+--------------+----------------+
| Length | Server (variable) ...
+---------------+---------------+--------------+----------------+
Figure 13: NextHopServer Syntax
图13:NextHopServer语法
The Next-Hop ITAD indicates the domain of the next-hop. Length field gives the number of octets in the Server field, and the Server field contains the name or address of the next-hop server. The server field is represented as a string of ASCII characters. It is defined as follows:
下一跳ITAD表示下一跳的域。长度字段给出服务器字段中的八位字节数，服务器字段包含下一跳服务器的名称或地址。服务器字段表示为ASCII字符字符串。其定义如下：
Server = host [":" port ]
host = < A legal Internet host domain name
or an IPv4 address using the textual representation
defined in Section 2.1 of RFC 1123 [9]
or an IPv6 address using the textual representation
defined in Section 2.2 of RFC 2373 [10]. The IPv6
address MUST be enclosed in "[" and "]"
characters.>
port = *DIGIT
Server = host [":" port ]
host = < A legal Internet host domain name
or an IPv4 address using the textual representation
defined in Section 2.1 of RFC 1123 [9]
or an IPv6 address using the textual representation
defined in Section 2.2 of RFC 2373 [10]. The IPv6
address MUST be enclosed in "[" and "]"
characters.>
port = *DIGIT
If the port is empty or not given, the default port is assumed (e.g., port 5060 if the application protocol is SIP).
如果端口为空或未给定，则假定默认端口（例如，如果应用协议为SIP，则端口5060）。
When an LS originates a routing object into TRIP, it MUST include a NextHopServer within its domain. The NextHopServer could be an address of the egress gateway or of a signaling proxy.
当LS将路由对象发起到TRIP中时，它必须在其域中包含一个NextHopServer。下一个ThopServer可以是出口网关或信令代理的地址。
LS policy may prefer certain next-hops or next-hop domains over others.
LS策略可能更喜欢某些下一跳或下一跳域而不是其他域。
When aggregating multiple routing objects into a single routing object, an LS MUST insert a new signaling server from within its domain as the new NextHopServer unless all of the routes being aggregated have the same next-hop.
当将多个路由对象聚合到一个路由对象中时，LS必须在其域内插入一个新的信令服务器作为新的下一跳服务器，除非所有被聚合的路由具有相同的下一跳。
When propagating routing objects to peers, an LS may choose to insert a signaling proxy within its domain as the new next-hop, or it may leave the next-hop unchanged. Inserting a new next-hop will cause the signaling messages to be sent to that address, and will provide finer control over the signaling path. Leaving the next-hop unchanged will yield a more efficient signaling path (fewer hops). It is a local policy decision of the LS to decide whether to propagate or change the NextHopServer.
当向对等方传播路由对象时，LS可以选择在其域内插入信令代理作为新的下一跳，也可以保持下一跳不变。插入新的下一跳将导致信令消息被发送到该地址，并将提供对信令路径的更好控制。保持下一跳不变将产生更有效的信令路径（更少的跳数）。LS的本地策略决定是传播还是更改下一个ThopServer。
Conditional Mandatory: True (if ReachableRoutes and/or WithdrawnRoutes attribute is present). Required Flags: Well-known. Potential Flags: None. TRIP Type Code: 4.
条件强制：True（如果存在可访问路由和/或撤回路由属性）。所需标志：众所周知。潜在标志：无。行程类型代码：4。
This attribute identifies the ITADs through which routing information carried in an advertisement has passed. The AdvertisementPath attribute is analogous to the AS_PATH attribute in BGP. The attributes differ in that BGP's AS_PATH also reflects the path to the destination. In TRIP, not every domain need modify the next-hop, so the AdvertisementPath may include many more hops than the actual path to the destination. The RoutedPath attribute (Section 5.5) reflects the actual signaling path to the destination.
此属性标识播发中承载的路由信息通过的ITAD。AdvertisementPath属性类似于BGP中的AS_PATH属性。这些属性的不同之处在于，BGP的AS_路径也反映了到目标的路径。在TRIP中，并非每个域都需要修改下一跳，因此AdvertisementPath可能包含比到达目的地的实际路径多得多的跳。RoutedPath属性（第5.5节）反映到目的地的实际信令路径。
AdvertisementPath is a variable length attribute that is composed of a sequence of ITAD path segments. Each ITAD path segment is represented by a type-length-value triple.
AdvertisementPath是一个可变长度属性，由一系列ITAD路径段组成。每个ITAD路径段由类型长度值三元组表示。
The path segment type is a 1-octet long field with the following values defined:
路径段类型是一个1-octet长字段，定义了以下值：
Value Segment Type 1 AP_SET: unordered set of ITADs a route in the advertisement message has traversed 2 AP_SEQUENCE: ordered set of ITADs a route in the advertisement message has traversed
值段类型1 AP_集：未排序的ITAD集广告消息中的路由已遍历2 AP_序列：已排序的ITAD集广告消息中的路由已遍历
The path segment length is a 1-octet long field containing the number of ITADs in the path segment value field.
路径段长度是一个1-octet长的字段，包含路径段值字段中的ITAD数。
The path segment value field contains one or more ITAD numbers, each encoded as a 4-octets long field. ITAD numbers uniquely identify an Internet Telephony Administrative Domain, and must be obtained from IANA. See Section 13 for procedures to obtain an ITAD number from IANA.
路径段值字段包含一个或多个ITAD编号，每个编号编码为4个八位字节长的字段。ITAD编号唯一标识互联网电话管理域，必须从IANA获得。有关从IANA获取ITAD编号的程序，请参见第13节。
When an LS originates a route then:
当LS发起路由时，则：
- The originating LS shall include its own ITAD number in the AdvertisementPath attribute of all advertisements sent to LSs located in neighboring ITADs. In this case, the ITAD number of the originating LS's ITAD will be the only entry in the AdvertisementPath attribute. - The originating LS shall include an empty AdvertisementPath attribute in all advertisements sent to LSs located in its own ITAD. An empty AdvertisementPath attribute is one whose length field contains the value zero.
- 发起的LS应在发送到位于相邻ITAD中的LSs的所有广告的AdvertisementPath属性中包含其自身的ITAD号。在这种情况下，发起LS的ITAD的ITAD号将是AdvertisementPath属性中的唯一条目。-始发LS应在发送至位于其自身ITAD中的LSs的所有广告中包含空AdvertisementPath属性。空的AdvertisementPath属性是其长度字段包含值零的属性。
The AdvertisementPath may be used for route selection. Possible criteria to be used are the number of hops on the path and the presence or absence of particular ITADs on the path.
广告路径可用于路线选择。可能使用的标准是路径上的跳数以及路径上是否存在特定的ITAD。
As discussed in Section 10, the AdvertisementPath is used to prevent routing information from looping. If an LS receives a route with its own ITAD already in the AdvertisementPath, the route MUST be discarded.
如第10节所述，广告路径用于防止路由信息循环。如果LS接收到的路由在AdvertisementPath中已经有自己的ITAD，则必须放弃该路由。
The rules for aggregating AdvertisementPath attributes are given in the following sections, where the term "path" used in Section 5.4.4.1 and 5.4.4.2 is understood to mean AdvertisementPath.
以下各节给出了聚合AdvertisementPath属性的规则，其中第5.4.4.1节和第5.4.4.2节中使用的术语“路径”被理解为是指AdvertisementPath。
If all routes to be aggregated have identical path attributes, then the aggregated route has the same path attribute as the individual routes.
如果要聚合的所有路由都具有相同的路径属性，则聚合的路由与单个路由具有相同的路径属性。
For the purpose of aggregating path attributes we model each ITAD within the path as a pair <type, value>, where "type" identifies a type of the path segment (AP_SEQUENCE or AP_SET), and "value" is the ITAD number. Two ITADs are said to be the same if their corresponding <type, value> are the same.
为了聚合路径属性，我们将路径中的每个ITAD建模为一对<type，value>，其中“type”标识路径段的类型（AP_序列或AP_集），“value”是ITAD编号。如果两个ITAD对应的<type，value>相同，则称其为相同。
If the routes to be aggregated have different path attributes, then the aggregated path attribute shall satisfy all of the following conditions:
如果要聚合的路由具有不同的路径属性，则聚合的路径属性应满足以下所有条件：
- All pairs of the type AP_SEQUENCE in the aggregated path MUST appear in all of the paths of routes to be aggregated. - All pairs of the type AP_SET in the aggregated path MUST appear in at least one of the paths of the initial set (they may appear as either AP_SET or AP_SEQUENCE types). - For any pair X of the type AP_SEQUENCE that precedes pair Y in the aggregated path, X precedes Y in each path of the initial set that contains Y, regardless of the type of Y. - No pair with the same value shall appear more than once in the aggregated path, regardless of the pair's type.
- 聚合路径中类型AP_序列的所有对必须出现在要聚合的路由的所有路径中。-聚合路径中类型AP_集的所有对必须至少出现在初始集的一个路径中（它们可以显示为AP_集或AP_序列类型）。-对于聚合路径中位于对Y之前的AP_序列类型的任何对X，无论Y的类型如何，在包含Y的初始集合的每个路径中，X都位于Y之前。无论对的类型如何，具有相同值的对在聚合路径中不得出现一次以上。
An implementation may choose any algorithm that conforms to these rules. At a minimum, a conformant implementation MUST be able to perform the following algorithm that meets all of the above conditions:
实现可以选择符合这些规则的任何算法。至少，一致性实现必须能够执行满足上述所有条件的以下算法：
- Determine the longest leading sequence of tuples (as defined above) common to all the paths of the routes to be aggregated. Make this sequence the leading sequence of the aggregated path. - Set the type of the rest of the tuples from the paths of the routes to be aggregated to AP_SET, and append them to the aggregated path. - If the aggregated path has more than one tuple with the same value (regardless of tuple's type), eliminate all but one such tuple by deleting tuples of the type AP_SET from the aggregated path.
- 确定要聚合的路由的所有路径共有的元组的最长前导序列（如上定义）。使此序列成为聚合路径的前导序列。-从要聚合到AP_集的路由路径中设置其余元组的类型，并将它们附加到聚合路径中。-如果聚合路径有多个具有相同值的元组（无论元组的类型如何），则通过从聚合路径中删除类型为AP_集的元组来消除除一个元组以外的所有元组。
An implementation that chooses to provide a path aggregation algorithm that retains significant amounts of path information may wish to use the procedure of Section 5.4.4.3.
选择提供保留大量路径信息的路径聚合算法的实现可能希望使用第5.4.4.3节的程序。
An example algorithm to aggregate two paths works as follows:
聚合两条路径的示例算法如下所示：
- Identify the ITADs (as defined in Section 5.4.1) within each path attribute that are in the same relative order within both path attributes. Two ITADs, X and Y, are said to be in the same order if either X precedes Y in both paths, or if Y precedes X in both paths. - The aggregated path consists of ITADs identified in (a) in exactly the same order as they appear in the paths to be aggregated. If two consecutive ITADs identified in (a) do not immediately follow each other in both of the paths to be aggregated, then the intervening ITADs (ITADs that are between the two consecutive ITADs that are the same) in both attributes are combined into an AP_SET path segment that consists of the intervening ITADs from both paths; this segment is then placed in between the two consecutive ITADs identified in (a) of the aggregated attribute. If two consecutive ITADs identified in (a) immediately follow each other in one attribute, but do not follow in another, then the intervening ITADs of the latter are combined into an AP_SET path segment; this segment is then placed in between the two consecutive ITADs identified in (a) of the aggregated path.
- 识别每个路径属性中的ITAD（定义见第5.4.1节），这些ITAD在两个路径属性中的相对顺序相同。如果X在两条路径中都在Y之前，或者Y在两条路径中都在X之前，那么两个ITAD，X和Y，被称为顺序相同。-聚合路径由（a）中标识的ITAD组成，其顺序与它们在要聚合的路径中出现的顺序完全相同。如果（a）中标识的两个连续ITAD在要聚合的两条路径中没有立即相互跟随，则两个属性中的介入ITAD（位于两个相同的连续ITAD之间的ITAD）组合成一个AP_集合路径段，该路径段由两条路径中的介入ITAD组成；然后将该段置于聚合属性（a）中标识的两个连续ITAD之间。如果（a）中标识的两个连续ITAD在一个属性中紧随其后，但在另一个属性中不紧随其后，则后者的中间ITAD组合成AP_集路径段；然后将该段置于聚合路径（a）中标识的两个连续ITAD之间。
If as a result of the above procedure a given ITAD number appears more than once within the aggregated path, all but the last instance (rightmost occurrence) of that ITAD number should be removed from the aggregated path.
如果由于上述过程，某个给定的ITAD号在聚合路径中出现了不止一次，则除了该ITAD号的最后一个实例（最右边的实例）之外，其他所有实例都应从聚合路径中删除。
When an LS propagates a route which it has learned from another LS, it shall modify the route's AdvertisementPath attribute based on the location of the LS to which the route will be sent.
当一个LS传播它从另一个LS学到的路由时，它应根据路由将发送到的LS的位置修改路由的AdvertisementPath属性。
- When a LS advertises a route to another LS located in its own ITAD, the advertising LS MUST NOT modify the AdvertisementPath attribute associated with the route. - When a LS advertises a route to an LS located in a neighboring ITAD, then the advertising LS MUST update the AdvertisementPath attribute as follows:
- 当LS向位于其自身ITAD中的另一LS播发路由时，播发LS不得修改与该路由关联的AdvertisementPath属性。-当LS向位于相邻ITAD中的LS播发路由时，播发LS必须更新AdvertisementPath属性，如下所示：
* If the first path segment of the AdvertisementPath is of type AP_SEQUENCE, the local system shall prepend its own ITAD number as the last element of the sequence (put it in the leftmost position).
* 如果AdvertisementPath的第一个路径段为AP_序列类型，则本地系统应将其自身的ITAD编号作为序列的最后一个元素（将其置于最左侧位置）。
* If the first path segment of the AdvertisementPath is of type AP_SET, the local system shall prepend a new path segment of type AP_SEQUENCE to the AdvertisementPath, including its own ITAD number in that segment.
* 如果AdvertisementPath的第一个路径段为AP_SET类型，则本地系统应将AP_序列类型的新路径段预先添加到AdvertisementPath，包括该段中自己的ITAD号。
Conditional Mandatory: True (if ReachableRoutes attribute is present). Required Flags: Well-known. Potential Flags: None. TRIP Type Code: 5.
条件强制：True（如果存在可访问路由属性）。所需标志：众所周知。潜在标志：无。行程类型代码：5。
This attribute identifies the ITADs through which messages sent using this route would pass. The ITADs in this path are a subset of those in the AdvertisementPath.
此属性标识使用此路由发送的消息将通过的ITAD。此路径中的ITAD是AdvertisementPath中ITAD的子集。
The syntax of the RoutedPath attribute is the same as that of the AdvertisementPath attribute. See Section 5.4.1.
RoutedPath属性的语法与AdvertisementPath属性的语法相同。见第5.4.1节。
When an LS originates a route it MUST include the RoutedPath attribute.
LS发起路由时，必须包含RoutedPath属性。
- The originating LS shall include its own ITAD number in the RoutedPath attribute of all advertisements sent to LSs located in neighboring ITADs. In this case, the ITAD number of the originating LS's ITAD will be the only entry in the RoutedPath attribute. - The originating LS shall include an empty RoutedPath attribute in all advertisements sent to LSs located in its own ITAD. An empty RoutedPath attribute is one whose length field contains the value zero.
- 发起的LS应在发送到位于相邻ITAD中的LSs的所有广告的RoutedPath属性中包含其自身的ITAD号。在这种情况下，发起LS的ITAD的ITAD号将是RoutedPath属性中的唯一条目。-始发LS应在发送至位于其自身ITAD中的LSs的所有广告中包含空RoutedPath属性。空RoutedPath属性的长度字段包含值零。
The RoutedPath MAY be used for route selection, and in most cases is preferred over the AdvertisementPath for this role. Some possible criteria to be used are the number of hops on the path and the presence or absence of particular ITADs on the path.
RoutedPath可用于路由选择，在大多数情况下，此角色优先于AdvertisementPath。使用的一些可能标准是路径上的跳数以及路径上是否存在特定的ITAD。
The rules for aggregating RoutedPath attributes are given in Section 5.4.4.1 and 5.4.4.2, where the term "path" used in Section 5.4.4.1 and 5.4.4.2 is understood to mean RoutedPath.
第5.4.4.1节和第5.4.4.2节给出了聚合RoutedPath属性的规则，其中第5.4.4.1节和第5.4.4.2节中使用的术语“path”被理解为RoutedPath。
When an LS propagates a route that it learned from another LS, it modifies the route's RoutedPath attribute based on the location of the LS to which the route is sent.
当一个LS传播它从另一个LS学到的路由时，它会根据路由发送到的LS的位置修改路由的RoutedPath属性。
- When an LS advertises a route to another LS located in its own ITAD, the advertising LS MUST NOT modify the RoutedPath attribute associated with the route. - If the LS has not changed the NextHopServer attribute, then the LS MUST NOT change the RoutedPath attribute. - Otherwise, the LS changed the NextHopServer and is advertising the route to an LS in another ITAD. The advertising LS MUST update the RoutedPath attribute as follows:
- 当LS向位于其自身ITAD中的另一LS播发路由时，播发LS不得修改与路由关联的RoutedPath属性。-如果LS未更改NextHopServer属性，则LS不得更改RoutedPath属性。-否则，LS会更改下一个路径服务器，并在另一个ITAD中公布到LS的路由。播发LS必须更新RoutedPath属性，如下所示：
* If the first path segment of the RoutedPath is of type AP_SEQUENCE, the local system shall prepend its own ITAD number as the last element of the sequence (put it in the leftmost position).
* 如果RoutedPath的第一个路径段为AP_序列类型，则本地系统应将其自身的ITAD编号作为序列的最后一个元素（将其置于最左侧位置）。
* If the first path segment of the RoutedPath is of type AP_SET, the local system shall prepend a new path segment of type AP_SEQUENCE to the RoutedPath, including its own ITAD number in that segment.
* 如果路由路径的第一个路径段为AP_SET类型，则本地系统应将AP_序列类型的新路径段预先添加到路由路径，包括该段中自己的ITAD号。
Conditional Mandatory: False. Required Flags: Well-known. Potential Flags: None. TRIP Type Code: 6.
条件强制：False。所需标志：众所周知。潜在标志：无。行程类型代码：6。
The AtomicAggregate attribute indicates that a route may traverse domains not listed in the RoutedPath. If an LS, when presented with a set of overlapping routes from a peer LS, selects the less specific route without selecting the more specific route, then the LS includes the AtomicAggregate attribute with the routing object.
AtomicAggregate属性表示路由可以遍历RoutedPath中未列出的域。如果一个LS在显示一组来自对等LS的重叠路由时，选择了不太特定的路由，而没有选择更特定的路由，则LS将AtomicAggregate属性与路由对象一起包含。
This attribute has length zero (0); the value field is empty.
此属性的长度为零（0）；值字段为空。
Routes are never originated with the AtomicAggregate attribute.
路由从不使用AtomicAggregate属性发起。
The AtomicAggregate attribute may be used in route selection - it indicates that the RoutedPath may be incomplete.
AtomicAggregate属性可用于路由选择-它表示RoutedPath可能不完整。
If any of the routes to aggregate has the AtomicAggregate attribute, then so MUST the resultant aggregate.
如果要聚合的任何路由都具有AtomicAggregate属性，则结果聚合也必须具有AtomicAggregate属性。
If an LS, when presented with a set of overlapping routes from a peer LS, selects the less specific route (see Section 0) without selecting the more specific route, then the LS MUST include the AtomicAggregate attribute with the routing object (if it is not already present).
如果一个LS在显示一组来自对等LS的重叠路由时，选择了不太具体的路由（参见第0节），而没有选择更具体的路由，则LS必须将AtomicAggregate属性与路由对象一起包含（如果它还不存在）。
An LS receiving a routing object with an AtomicAggregate attribute MUST NOT make the set of destinations more specific when advertising it to other LSs, and MUST NOT remove the attribute when propagating this object to a peer LS.
接收具有AtomicAggregate属性的路由对象的LS在向其他LSs播发时不得使目的地集更具体，并且在向对等LS传播此对象时不得删除该属性。
Conditional Mandatory: False. Required Flags: Well-known. Potential Flags: None. TRIP Type Code: 7.
条件强制：False。所需标志：众所周知。潜在标志：无。行程类型代码：7。
The LocalPreference attribute is only used intra-domain, it indicates the local LS's preference for the routing object to other LSs within the same domain. This attribute MUST NOT be included when communicating to an LS in another domain, and MUST be included over intra-domain links.
LocalPreference属性仅在域内使用，它指示本地LS对路由对象的首选项，以便路由到同一域中的其他LSs。在与另一个域中的LS通信时，不得包含此属性，必须通过域内链接包含此属性。
The LocalPreference attribute is a 4-octet unsigned numeric value. A higher value indicates a higher preference.
LocalPreference属性是一个4-octet无符号数值。值越大表示首选项越高。
Routes MUST NOT be originated with the LocalPreference attribute to inter-domain peers. Routes to intra-domain peers MUST be originated with the LocalPreference attribute.
路由不得使用LocalPreference属性发起到域间对等方。到域内对等方的路由必须使用LocalPreference属性发起。
The LocalPreference attribute allows one LS in a domain to calculate a preference for a route, and to communicate this preference to other LSs within the domain.
LocalPreference属性允许域中的一个LSs计算路由的首选项，并将此首选项传递给域中的其他LSs。
The LocalPreference attribute is not affected by aggregation.
LocalPreference属性不受聚合的影响。
An LS MUST include the LocalPreference attribute when communicating with peer LSs within its own domain. An LS MUST NOT include the LocalPreference attribute when communicating with LSs in other domains. LocalPreference attributes received from inter-domain peers MUST be ignored.
LS在其自己的域内与对等LSs通信时必须包含LocalPreference属性。与其他域中的LSs通信时，LS不得包含LocalPreference属性。必须忽略从域间对等方接收的LocalPreference属性。
Conditional Mandatory: False. Required Flags: Well-known. Potential Flags: None. TRIP Type Code: 8.
条件强制：False。所需标志：众所周知。潜在标志：无。行程类型代码：8。
When two ITADs are connected by more than one set of peers, the MultiExitDisc attribute may be used to specify preferences for routes received over one of those links versus routes received over other links. The MultiExitDisc parameter is used only for route selection.
当两个ITAD由一组以上的对等点连接时，MultiExitDisc属性可用于指定通过其中一个链路接收的路由相对于通过其他链路接收的路由的首选项。MultiExitDisc参数仅用于路线选择。
The MultiExitDisc attribute carries a 4-octet unsigned numeric value. A higher value represents a more preferred routing object.
MultiExitDisc属性携带一个4个八位组的无符号数值。值越大，表示首选的路由对象越多。
Routes originated to intra-domain peers MUST NOT be originated with the MultiExitDisc attribute. When originating a route to an inter-domain peer, the MultiExitDisc attribute may be included.
起源于域内对等方的路由不得使用MultiExitDisc属性起源。当发起到域间对等方的路由时，可以包括MultiExitDisc属性。
The MultiExitDisc attribute is used to express a preference when there are multiple links between two domains. If all other factors are equal, then a route with a higher MultiExitDisc attribute is preferred over a route with a lower MultiExitDisc attribute.
当两个域之间存在多个链接时，MultiExitDisc属性用于表示首选项。如果所有其他因素相等，则具有较高MultiExitDisc属性的路由优于具有较低MultiExitDisc属性的路由。
Routes with differing MultiExitDisc parameters MUST NOT be aggregated. Routes with the same value in the MultiExitDisc attribute MAY be aggregated and the same MultiExitDisc attribute attached to the aggregated object.
不得聚合具有不同MultiExitDisc参数的路由。可以聚合在MultiExitDisc属性中具有相同值的路由，并将相同的MultiExitDisc属性附加到聚合对象。
If received from a peer LS in another domain, an LS MAY propagate the MultiExitDisc to other LSs within its domain. The MultiExitDisc attribute MUST NOT be propagated to LSs in other domains.
如果从另一个域中的对等LS接收，则LS可以将MultiExitDisc传播到其域中的其他LSs。MultiExitDisc属性不得传播到其他域中的LSs。
An LS may add the MultiExitDisc attribute when propagating routing objects to an LS in another domain. The inclusion of the MultiExitDisc attribute is a matter of policy, as is the value of the attribute.
LS可以在将路由对象传播到另一个域中的LS时添加MultiExitDisc属性。包含MultiExitDisc属性是一个策略问题，属性的值也是一个策略问题。
Conditional Mandatory: False. Required Flags: Not Well-Known, Independent Transitive. Potential Flags: None. TRIP Type Code: 9.
条件强制：False。所需标志：不知名，独立传递。潜在标志：无。行程类型代码：9。
A community is a group of destinations that share some common property.
社区是一组共享某些公共属性的目的地。
The Communities attribute is used to group destinations so that the routing decision can be based on the identity of the group. Using the Communities attribute should significantly simplify the distribution of routing information by providing an administratively defined aggregation unit.
Communities属性用于将目的地分组，以便路由决策可以基于组的标识。通过提供管理定义的聚合单元，使用Communities属性可以显著简化路由信息的分发。
Each ITAD administrator may define the communities to which a particular route belongs. By default, all routes belong to the general Internet Telephony community.
每个ITAD管理员可以定义特定路由所属的社区。默认情况下，所有路由都属于通用Internet电话社区。
As an example, the Communities attribute could be used to define an alliance between a group of Internet Telephony service providers for a specific subset of routing information. In this case, members of
例如，Communities属性可用于为路由信息的特定子集定义一组Internet电话服务提供商之间的联盟。在这种情况下
that alliance would accept only routes for destinations in this group that are advertised by other members of the alliance. Other destinations would be more freely accepted. To achieve this, a member would tag each route with a designated Community attribute value before disseminating it. This relieves the members of such an alliance, from the responsibility of keeping track of the identities of all other members of that alliance.
该联盟将只接受该组中由联盟其他成员发布广告的目的地的路线。其他目的地将被更自由地接受。为了实现这一点，成员将在传播之前为每条路线添加指定的社区属性值。这就免除了这样一个联盟的成员跟踪该联盟所有其他成员身份的责任。
Another example use of the Communities attribute is with aggregation. It is often useful to advertise both the aggregate route and the component more-specific routes that were used to form the aggregate. These information components are only useful to the neighboring TRIP peer, and perhaps the ITAD of the neighboring TRIP peer, so it is desirable to filter out the component routes. This can be achieved by specifying a Community attribute value that the neighboring peers will match and filter on. That way it can be assured that the more specific routes will not propagate beyond their desired scope.
Communities属性的另一个示例是聚合。通常，公布聚合路由和用于形成聚合的组件更具体的路由是有用的。这些信息组件仅对相邻的TRIP peer有用，并且可能对相邻TRIP peer的ITAD有用，因此需要过滤掉组件路由。这可以通过指定一个社区属性值来实现，相邻的对等方将匹配该属性值并进行过滤。这样就可以确保更具体的路由不会超出其预期范围。
The Communities attribute is of variable length. It consists of a set of 8-octet values, each of which specifies a community. The first 4 octets of the Community value are the Community ITAD Number and the next 4 octets are the Community ID.
“社区”属性的长度可变。它由一组8个八进制值组成，每个值指定一个社区。社区值的前4个八位字节是社区ITAD号，接下来的4个八位字节是社区ID。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+--------------+----------------+
| Community ITAD Number 1 |
+---------------+---------------+--------------+----------------+
| Community ID 1 |
+---------------+---------------+--------------+----------------+
| . . . . . . . . .
+---------------+---------------+--------------+----------------+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+--------------+----------------+
| Community ITAD Number 1 |
+---------------+---------------+--------------+----------------+
| Community ID 1 |
+---------------+---------------+--------------+----------------+
| . . . . . . . . .
+---------------+---------------+--------------+----------------+
Figure 14: Communities Syntax
图14：社区语法
For administrative assignment, the following assumptions may be made:
对于行政委派，可作出以下假设：
The Community attribute values starting with a Community ITAD Number of 0x00000000 are hereby reserved.
特此保留以社区ITAD编号0x00000000开始的社区属性值。
The following communities have global significance and their operation MUST be implemented in any Community attribute-aware TRIP LS.
以下社区具有全球意义，它们的操作必须在任何社区属性感知的TRIP LS中实现。
- NO_EXPORT (Community ITAD Number = 0x00000000 and Community ID = 0xFFFFFF01). Any received route with a community attribute containing this value MUST NOT be advertised outside of the receiving TRIP ITAD.
- 无导出（社区ITAD编号=0x00000000，社区ID=0xFFFF01）。任何具有包含此值的社区属性的接收路线不得在接收行程ITAD之外播发。
Other community values MUST be encoded using an ITAD number in the four most significant octets. The semantics of the final four octets (the Community ID octets) may be defined by the ITAD (e.g., ITAD 690 may define research, educational, and commercial community IDs that may be used for policy routing as defined by the operators of that ITAD).
其他社区值必须使用四个最重要的八位字节中的ITAD编号进行编码。最后四个八位字节（社区ID八位字节）的语义可由ITAD定义（例如，ITAD 690可定义研究、教育和商业社区ID，可用于ITAD运营商定义的策略路由）。
The Communities attribute is not well-known. If a route has a Communities attribute associated with it, the LS MUST include that attribute in the advertisement it originates.
“社区”属性不是众所周知的。如果路由具有与其关联的Communities属性，则LS必须在其发起的播发中包含该属性。
The Communities attribute may be used for route selection. A route that is a member of a certain community may be preferred over another route that is not a member of that community. Likewise, routes without a certain community value may be excluded from consideration.
“社区”属性可用于路线选择。作为某个社区成员的路线可能比不是该社区成员的另一条路线更可取。同样，没有特定社区价值的路线也可能被排除在考虑范围之外。
If a set of routes is to be aggregated and the resultant aggregate does not carry an Atomic_Aggregate attribute, then the resulting aggregate should have a Communities attribute that contains the union of the Community attributes of the aggregated routes.
如果要聚合一组路由，且生成的聚合不包含原子聚合属性，则生成的聚合应具有包含聚合路由的社区属性的并集的社区属性。
An LS may manipulate the Communities attribute before disseminating a route to a peer. Community attribute manipulation may include adding communities, removing communities, adding a Communities attribute (if none exists), deleting the Communities attribute, etc.
LS可以在向对等方传播路由之前操作Communities属性。社区属性操作可能包括添加社区、删除社区、添加社区属性（如果不存在）、删除社区属性等。
Conditional Mandatory: False. Required Flags: Well-known, Link-State encapsulated. Potential Flags: None. TRIP Type Code: 10.
条件强制：False。所需标志：众所周知，链接状态已封装。潜在标志：无。行程类型代码：10。
Within an ITAD, each LS must know the status of other LSs so that LS failure can be detected. To do this, each LS advertises its internal topology to other LSs within the domain. When an LS detects that another LS is no longer active, the information sourced by that LS can be deleted (the Adj-TRIB-In for that peer may be cleared). The ITAD Topology attribute is used to communicate this information to other LSs within the domain.
在ITAD中，每个LS必须知道其他LSs的状态，以便可以检测到LS故障。为此，每个LS向域内的其他LSs播发其内部拓扑。当一个LS检测到另一个LS不再处于活动状态时，可以删除该LS提供的信息（该对等方的Adj TRIB In可能会被清除）。ITAD拓扑属性用于将此信息传递给域内的其他LSs。
An LS MUST send a topology update each time it detects a change in its internal peer set. The topology update may be sent in an UPDATE message by itself or it may be piggybacked on an UPDATE message which includes ReachableRoutes and/or WithdrawnRoutes information.
LS必须在每次检测到其内部对等集的更改时发送拓扑更新。拓扑更新可以在更新消息中单独发送，也可以在更新消息上附带，更新消息包括可到达的路由和/或提取路由信息。
When an LS receives a topology update from an internal LS, it MUST recalculate which LSs are active within the ITAD via a connectivity algorithm on the topology.
当LS从内部LS接收到拓扑更新时，必须通过拓扑上的连接算法重新计算ITAD中哪些LSs处于活动状态。
The ITAD Topology attribute indicates the LSs with which the LS is currently peering. The attribute consists of a list of the TRIP Identifiers with which the LS is currently peering, the format is given in Figure 15. This attribute MUST use the link-state encapsulation as defined in Section 4.3.2.4.
ITAD拓扑属性表示LS当前与之对等的LSs。该属性由LS当前正在与其对等的跳闸标识符列表组成，格式如图15所示。此属性必须使用第4.3.2.4节中定义的链接状态封装。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+--------------+----------------+
| TRIP Identifier 1 |
+---------------+---------------+--------------+----------------+
| TRIP Identifier 2 ... |
+---------------+---------------+--------------+----------------+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+--------------+----------------+
| TRIP Identifier 1 |
+---------------+---------------+--------------+----------------+
| TRIP Identifier 2 ... |
+---------------+---------------+--------------+----------------+
Figure 15: ITAD Topology Syntax
图15:ITAD拓扑语法
The ITAD Topology attribute is independent of any routes in the UPDATE. Whenever the set of internal peers of an LS changes, it MUST create an UPDATE with the ITAD Topology Attribute included listing the current set of internal peers. The LS MUST include this attribute in the first UPDATE it sends to a peer after the peering session is established.
ITAD拓扑属性独立于更新中的任何路由。每当LS的内部对等点集发生更改时，它必须创建一个更新，其中包含ITAD拓扑属性，列出当前的内部对等点集。LS必须在对等会话建立后发送给对等方的第一次更新中包含此属性。
This attribute is independent of any routing information in the UPDATE. When an LS receives an UPDATE with an ITAD Topology attribute, it MUST compute the set of LSs currently active in the domain by performing a connectivity test on the ITAD topology as given by the set of originated ITAD Topology attributes. The LS MUST locally purge the Adj-TRIB-In for any LS that is no longer active in the domain. The LS MUST NOT propagate this purging information to other LSs as they will make a similar decision.
此属性独立于更新中的任何路由信息。当LS接收到具有ITAD拓扑属性的更新时，它必须根据原始ITAD拓扑属性集给出的ITAD拓扑执行连接测试，从而计算域中当前活动的LSs集。对于域中不再活动的任何LS，LS必须本地清除Adj TRIB In。LS不得将此清除信息传播给其他LSs，因为他们将做出类似的决定。
This information is not aggregated.
此信息不是聚合的。
An LS MUST ignore the attribute if received from a peer in another domain. An LS MUST NOT send this attribute to an inter-domain peer.
如果从另一个域中的对等方接收，LS必须忽略该属性。LS不得将此属性发送到域间对等方。
Conditional Mandatory: False. Required Flags: Well-known. Potential Flags: None. TRIP Type Code: 12.
条件强制：False。所需标志：众所周知。潜在标志：无。行程类型代码：12。
The ConvertedRoute attribute indicates that an intermediate LS has altered the route by changing the route's Application Protocol. For example, if an LS receives a route with Application Protocol X and changes the Application Protocol to Y before advertising the route to an external peer, the LS MUST include the ConvertedRoute attribute. The attribute is an indication that the advertised application protocol will not be used end-to-end, i.e., the information advertised about this route is not complete.
ConvertedRoute属性表示中间LS通过更改路由的应用协议更改了路由。例如，如果LS接收到具有应用程序协议X的路由，并在向外部对等方公布该路由之前将应用程序协议更改为Y，则LS必须包含ConvertedRoute属性。该属性表示不会端到端使用公布的应用程序协议，即，关于该路由的公布信息不完整。
This attribute has length zero (0); the value field is empty.
此属性的长度为零（0）；值字段为空。
Routes are never originated with the ConvertedRoute attribute.
从不使用ConvertedRoute属性创建路由。
The ConvertedRoute attribute may be used in route selection - it indicates that advertised routing information is not complete.
ConvertedRoute属性可用于路由选择-它表示播发的路由信息不完整。
If any of the routes to aggregate has the ConvertedRoute attribute, then so MUST the resultant aggregate.
如果要聚合的任何路由具有ConvertedRoute属性，则结果聚合也必须具有ConvertedRoute属性。
If an LS changes the Application Protocol of a route before advertising the route to an external peer, the LS MUST include the ConvertedRoute attribute.
如果LS在向外部对等方公布路由之前更改了路由的应用协议，则LS必须包含ConvertedRoute属性。
Any proposal for defining new TRIP attributes should specify the following:
定义新出行属性的任何建议应规定以下内容：
- the use of this attribute, - the attribute's flags, - the attribute's syntax, - how the attribute works with route origination, - how the attribute works with route aggregation, and - how the attribute works with route dissemination and the attribute's scope (e.g., intra-domain only like LocalPreference)
- 此属性的使用，-属性的标志，-属性的语法，-属性如何与路由发起一起工作，-属性如何与路由聚合一起工作，以及-属性如何与路由传播和属性的范围一起工作（例如，仅域内，如LocalPreference）
IANA will manage the assignment of TRIP attribute type codes to new attributes.
IANA将管理新属性的出行属性类型代码分配。
This section describes errors to be detected and the actions to be taken while processing TRIP messages.
本节描述了在处理跳闸信息时要检测到的错误以及要采取的措施。
When any of the conditions described here are detected, a NOTIFICATION message with the indicated Error Code, Error Subcode, and Data fields MUST be sent, and the TRIP connection MUST be closed. If no Error Subcode is specified, then a zero Subcode MUST be used.
当检测到此处描述的任何情况时，必须发送带有指示错误代码、错误子代码和数据字段的通知消息，并且必须关闭跳闸连接。如果未指定错误子代码，则必须使用零子代码。
The phrase "the TRIP connection is closed" means that the transport protocol connection has been closed and that all resources for that TRIP connection have been de-allocated. If the connection was inter-domain, then routing table entries associated with the remote peer MUST be marked as invalid. Routing table entries MUST NOT be
短语“跳闸连接已关闭”表示传输协议连接已关闭，且该跳闸连接的所有资源已取消分配。如果连接是域间连接，则与远程对等方关联的路由表项必须标记为无效。路由表项不能为空
marked as invalid if an internal peering session is terminated. The fact that the routes have been marked as invalid is passed to other TRIP peers before the routes are deleted from the system.
如果内部对等会话终止，则标记为无效。在从系统中删除路由之前，将路由标记为无效的事实传递给其他行程对等方。
Unless specified explicitly, the Data field of the NOTIFICATION message that is sent to indicate an error MUST be empty.
除非明确指定，否则发送用于指示错误的通知消息的数据字段必须为空。
All errors detected while processing the Message Header are indicated by sending the NOTIFICATION message with the Error Code Message Header Error. The Error Subcode elaborates on the specific nature of the error. The error checks in this section MUST be performed by each LS upon receipt of every message.
处理消息头时检测到的所有错误都通过发送带有错误代码消息头错误的通知消息来指示。错误子代码详细说明了错误的具体性质。每个LS必须在收到每条消息后执行本节中的错误检查。
If the Length field of the message header is less than 3 or greater than 4096, or if the Length field of an OPEN message is less than the minimum length of the OPEN message, or if the Length field of an UPDATE message is less than the minimum length of the UPDATE message, or if the Length field of a KEEPALIVE message is not equal to 3, or if the Length field of a NOTIFICATION message is less than the minimum length of the NOTIFICATION message, then the Error Subcode MUST be set to Bad Message Length. The Data field contains the erroneous Length field.
如果消息头的长度字段小于3或大于4096，或者如果打开消息的长度字段小于打开消息的最小长度，或者如果更新消息的长度字段小于更新消息的最小长度，或者如果保留消息的长度字段不等于3，或者，如果通知消息的长度字段小于通知消息的最小长度，则必须将错误子代码设置为错误消息长度。数据字段包含错误的长度字段。
If the Type field of the message header is not recognized, then the Error Subcode MUST be set to "Bad Message Type." The Data field contains the erroneous Type field.
如果无法识别消息头的类型字段，则必须将错误子代码设置为“错误消息类型”。数据字段包含错误类型字段。
All errors detected while processing the OPEN message are indicated by sending the NOTIFICATION message with the Error Code "OPEN Message Error." The Error Subcode elaborates on the specific nature of the error. The error checks in this section MUST be performed by each LS upon receipt of every OPEN message.
处理打开的消息时检测到的所有错误都通过发送带有错误代码“打开消息错误”的通知消息来表示。错误子代码详细说明了错误的具体性质。每个LS必须在收到每个打开的消息后执行本节中的错误检查。
If the version number contained in the Version field of the received OPEN message is not supported, then the Error Subcode MUST be set to "Unsupported Version Number." The Data field is a 1-octet unsigned integer, which indicates the largest locally supported version number, which is less than the version of the remote TRIP peer bid (as indicated in the received OPEN message).
如果接收到的开放消息的版本字段中包含的版本号不受支持，则必须将错误子代码设置为“不支持的版本号”。数据字段为1-octet无符号整数，表示本地支持的最大版本号，该版本号小于远程跳闸对等bid的版本（如收到的打开消息所示）。
If the ITAD field of the OPEN message is unacceptable, then the Error Subcode MUST be set to "Bad Peer ITAD." The determination of acceptable ITAD numbers is outside the scope of this protocol.
如果打开消息的ITAD字段不可接受，则必须将错误子代码设置为“坏对等ITAD”。可接受ITAD编号的确定超出本协议的范围。
If the Hold Time field of the OPEN message is unacceptable, then the Error Subcode MUST be set to "Unacceptable Hold Time." An implementation MUST reject Hold Time values of one or two seconds. An implementation MAY reject any proposed Hold Time. An implementation that accepts a Hold Time MUST use the negotiated value for the Hold Time.
如果打开消息的保持时间字段不可接受，则错误子代码必须设置为“不可接受的保持时间”。实现必须拒绝一秒或两秒的保持时间值。实施可以拒绝任何提议的保持时间。接受保留时间的实现必须使用保留时间的协商值。
If the TRIP Identifier field of the OPEN message is not valid, then the Error Subcode MUST be set to "Bad TRIP Identifier." A TRIP identifier is 4-octets in length and can take any value. An LS considers the TRIP Identifier invalid if it already has an open connection with another peer LS that has the same ITAD and TRIP Identifier.
如果打开消息的行程标识符字段无效，则必须将错误子代码设置为“错误行程标识符”。行程标识符的长度为4个八位字节，可以取任何值。如果LS已与另一个具有相同ITAD和跳闸标识符的对等LS建立开放连接，则LS认为跳闸标识符无效。
Any two LSs within the same ITAD MUST NOT have equal TRIP Identifier values. This restriction does not apply to LSs in different ITADs since the purpose is to uniquely identify an LS using its TRIP Identifier and its ITAD number.
同一ITAD内的任何两个LSs不得具有相同的行程标识符值。此限制不适用于不同ITAD中的LSs，因为其目的是使用其行程标识符和ITAD号唯一标识LS。
If one of the Optional Parameters in the OPEN message is not recognized, then the Error Subcode MUST be set to "Unsupported Optional Parameters."
如果无法识别打开消息中的一个可选参数，则必须将错误子代码设置为“不支持的可选参数”
If the Optional Parameters of the OPEN message include Capability Information with an unsupported capability (unsupported in either capability type or value), then the Error Subcode MUST be set to "Unsupported Capability," and the entirety of the unsupported capabilities MUST be listed in the Data field of the NOTIFICATION message.
如果打开消息的可选参数包括具有不支持功能的功能信息（功能类型或值均不支持），则必须将错误子代码设置为“不支持的功能”，并且必须在通知消息的数据字段中列出所有不支持的功能。
If the Optional Parameters of the OPEN message include Capability Information which does not match the receiving LS's capabilities, then the Error Subcode MUST be set to "Capability Mismatch," and the entirety of the mismatched capabilities MUST be listed in the Data field of the NOTIFICATION message.
如果打开消息的可选参数包括与接收LS的能力不匹配的能力信息，则必须将错误子代码设置为“能力不匹配”，并且必须在通知消息的数据字段中列出所有不匹配的能力。
All errors detected while processing the UPDATE message are indicated by sending the NOTIFICATION message with the Error Code "UPDATE Message Error." The Error Subcode elaborates on the specific nature of the error. The error checks in this section MUST be performed by each LS upon receipt of every UPDATE message. These error checks MUST occur before flooding procedures are invoked with internal peers.
处理更新消息时检测到的所有错误都通过发送带有错误代码“UPDATE message Error”的通知消息来表示。错误子代码详细说明了错误的具体性质。每个LS必须在收到每个更新消息后执行本节中的错误检查。这些错误检查必须在使用内部对等方调用泛洪过程之前进行。
If any recognized attribute has Attribute Flags that conflict with the Attribute Type Code, then the Error Subcode MUST be set to "Attribute Flags Error." The Data field contains the erroneous attribute (type, length and value).
如果任何已识别的属性具有与属性类型代码冲突的属性标志，则错误子代码必须设置为“属性标志错误”。数据字段包含错误的属性（类型、长度和值）。
If any recognized attribute has an Attribute Length that conflicts with the expected length (based on the attribute type code), then the Error Subcode MUST be set to "Attribute Length Error." The Data field contains the erroneous attribute (type, length and value).
如果任何已识别属性的属性长度与预期长度冲突（基于属性类型代码），则错误子代码必须设置为“属性长度错误”。数据字段包含错误属性（类型、长度和值）。
If any of the mandatory (i.e., conditional mandatory attribute and the conditions for including it in the UPDATE message are fulfilled) well-known attributes are not present, then the Error Subcode MUST be set to "Missing Well-known Mandatory Attribute." The Data field contains the Attribute Type Code of the missing well-known conditional mandatory attributes.
如果任何强制（即，条件强制属性以及将其包含在更新消息中的条件已满足）已知属性不存在，则必须将错误子代码设置为“缺少已知强制属性”数据字段包含缺少的已知条件强制属性的属性类型代码。
If any of the well-known attributes are not recognized, then the Error Subcode MUST be set to "Unrecognized Well-known Attribute." The Data field contains the unrecognized attribute (type, length and value).
如果无法识别任何已知属性，则错误子代码必须设置为“Unrecogned well known Attribute”。数据字段包含无法识别的属性（类型、长度和值）。
If any attribute has a syntactically incorrect value, or an undefined value, then the Error Subcode is set to "Invalid Attribute." The Data field contains the incorrect attribute (type, length and value). Such a NOTIFICATION message is sent, for example, when a NextHopServer attribute is received with an invalid address.
如果任何属性具有语法错误的值或未定义的值，则错误子代码将设置为“无效属性”。数据字段包含错误的属性（类型、长度和值）。例如，当接收到带有无效地址的NextHopServer属性时，将发送此类通知消息。
The information carried by the AdvertisementPath attribute is checked for ITAD loops. ITAD loop detection is done by scanning the full AdvertisementPath, and checking that the ITAD number of the local ITAD does not appear in the AdvertisementPath. If the local ITAD number appears in the AdvertisementPath, then the route MAY be stored in the Adj-TRIB-In. However unless the LS is configured to accept routes with its own ITAD in the advertisement path, the route MUST not be passed to the TRIP Decision Process. The operation of an LS that is configured to accept routes with its own ITAD number in the advertisement path are outside the scope of this document.
检查AdvertisementPath属性携带的信息是否存在ITAD循环。ITAD循环检测是通过扫描整个AdvertisementPath，并检查本地ITAD的ITAD编号是否未出现在AdvertisementPath中来完成的。如果本地ITAD编号出现在AdvertisementPath中，则路由可能存储在Adj TRIB in中。但是，除非LS配置为接受在播发路径中具有自己ITAD的路由，否则不得将路由传递到行程决策过程。配置为接受播发路径中具有自身ITAD号的路由的LS的操作不在本文档的范围内。
If the UPDATE message was received from an internal peer and either the WithdrawnRoutes, ReachableRoutes, or ITAD Topology attribute does not have the Link-State Encapsulation flag set, then the Error Subcode is set to "Invalid Attribute" and the data field contains the attribute. Likewise, the attribute is invalid if received from an external peer and the Link-State Flag is set.
如果从内部对等方接收到更新消息，并且“撤回路由”、“可到达路由”或“ITAD拓扑”属性未设置链路状态封装标志，则错误子代码将设置为“无效属性”，并且数据字段包含该属性。同样，如果从外部对等方接收到该属性，并且设置了链接状态标志，则该属性无效。
If any attribute appears more than once in the UPDATE message, then the Error Subcode is set to "Malformed Attribute List."
如果任何属性在更新消息中出现多次，则错误子代码将设置为“格式不正确的属性列表”
If a peer sends a NOTIFICATION message, and there is an error in that message, there is unfortunately no means of reporting this error via a subsequent NOTIFICATION message. Any such error, such as an unrecognized Error Code or Error Subcode, should be noticed, logged locally, and brought to the attention of the administration of the peer. The means to do this, however, are outside the scope of this document.
如果对等方发送通知消息，并且该消息中存在错误，则很遗憾，无法通过后续通知消息报告此错误。应注意任何此类错误，例如无法识别的错误代码或错误子代码，并在本地记录，并提请对等方管理层注意。但是，执行此操作的方法不在本文件的范围内。
If a system does not receive successive messages within the period specified by the negotiated Hold Time, then a NOTIFICATION message with a "Hold Timer Expired" Error Code MUST be sent and the TRIP connection MUST be closed.
如果系统在协商等待时间指定的时间内未收到连续消息，则必须发送带有“等待计时器已过期”错误代码的通知消息，并且必须关闭跳闸连接。
An error detected by the TRIP Finite State Machine (e.g., receipt of an unexpected event) MUST result in sending a NOTIFICATION message with the Error Code "Finite State Machine Error" and the TRIP connection MUST be closed.
跳闸有限状态机检测到的错误（例如，接收到意外事件）必须导致发送带有错误代码“有限状态机错误”的通知消息，并且必须关闭跳闸连接。
In the absence of any fatal errors (that are indicated in this section), a TRIP peer MAY choose at any given time to close its TRIP connection by sending the NOTIFICATION message with the Error Code "Cease." However, the Cease NOTIFICATION message MUST NOT be used when a fatal error indicated by this section exists.
在没有任何致命错误（本节中指出）的情况下，跳闸对等方可在任何给定时间通过发送带有错误代码“STOP”的通知消息来选择关闭其跳闸连接。但是，当存在本节中指出的致命错误时，不得使用STOP通知消息。
If a pair of LSs try simultaneously to establish a transport connection to each other, then two parallel connections between this pair of speakers might well be formed. We refer to this situation as connection collision. Clearly, one of these connections must be closed.
如果一对LSs同时尝试建立彼此的传输连接，那么这对扬声器之间可能会形成两个并行连接。我们将这种情况称为连接冲突。显然，其中一个连接必须关闭。
Based on the value of the TRIP Identifier, a convention is established for detecting which TRIP connection is to be preserved when a collision occurs. The convention is to compare the TRIP Identifiers of the peers involved in the collision and to retain only the connection initiated by the LS with the higher-valued TRIP Identifier.
基于行程标识符的值，建立了一种约定，用于在发生碰撞时检测要保留的行程连接。约定是比较冲突中涉及的对等方的跳闸标识符，并仅保留由LS启动的连接和较高值的跳闸标识符。
Upon receipt of an OPEN message, the local LS MUST examine all of its connections that are in the OpenConfirm state. An LS MAY also examine connections in an OpenSent state if it knows the TRIP Identifier of the peer by means outside of the protocol. If among these connections there is a connection to a remote LS, whose TRIP Identifier equals the one in the OPEN message, then the local LS MUST perform the following collision resolution procedure:
收到打开的消息后，本地LS必须检查其处于OpenConfirm状态的所有连接。如果LS通过协议之外的方式知道对等方的跳闸标识符，则LS也可以在OpenSent状态下检查连接。如果在这些连接中有到远程LS的连接，其跳闸标识符等于打开消息中的标识符，则本地LS必须执行以下冲突解决程序：
The TRIP Identifier and ITAD of the local LS is compared to the TRIP Identifier and ITAD of the remote LS (as specified in the OPEN message). TRIP Identifiers are treated as 4-octet unsigned integers for comparison.
将本地LS的跳闸标识符和ITAD与远程LS的跳闸标识符和ITAD进行比较（如打开消息中所述）。跳闸标识符被视为4个八位无符号整数进行比较。
If the value of the local TRIP Identifier is less than the remote one, or if the two TRIP Identifiers are equal and the value of the ITAD of the local LS is less than value of the ITAD of the remote LS, then the local LS MUST close the TRIP connection that already exists (the one that is already in the OpenConfirm state), and accept the TRIP connection initiated by the remote LS:
如果本地跳闸标识符的值小于远程跳闸标识符的值，或者如果两个跳闸标识符相等且本地LS的ITAD值小于远程LS的ITAD值，则本地LS必须关闭已经存在的跳闸连接（已经处于OpenConfirm状态的跳闸连接），并接受远程LS启动的跳闸连接：
1. Otherwise, the local LS closes the newly created TRIP connection and continues to use the existing one (the one that is already in the OpenConfirm state). 2. If a connection collision occurs with an existing TRIP connection that is in the Established state, then the LS MUST unconditionally close off the newly created connection. Note that a connection collision cannot be detected with connections in Idle, Connect, or Active states. 3. To close the TRIP connection (that results from the collision resolution procedure), an LS MUST send a NOTIFICATION message with the Error Code "Cease" and the TRIP connection MUST be closed.
1. 否则，本地LS将关闭新创建的跳闸连接，并继续使用现有的跳闸连接（已处于OpenConfirm状态的跳闸连接）。2.如果与处于已建立状态的现有跳闸连接发生连接冲突，则LS必须无条件关闭新创建的连接。请注意，当连接处于空闲、连接或活动状态时，无法检测到连接冲突。3.要关闭跳闸连接（由冲突解决程序产生），LS必须发送带有错误代码“STOP”的通知消息，并且跳闸连接必须关闭。
Peer LSs may negotiate the version of the protocol by making multiple attempts to open a TRIP connection, starting with the highest version number each supports. If an open attempt fails with an Error Code "OPEN Message Error" and an Error Subcode "Unsupported Version Number," then the LS has available the version number it tried, the version number its peer tried, the version number passed by its peer in the NOTIFICATION message, and the version numbers that it supports. If the two peers support one or more common versions, then this will allow them to rapidly determine the highest common version. In order to support TRIP version negotiation, future versions of TRIP must retain the format of the OPEN and NOTIFICATION messages.
对等LSs可以通过多次尝试打开跳闸连接来协商协议的版本，从每个LSs支持的最高版本号开始。如果打开尝试失败，错误代码为“open Message Error”且错误子代码为“Unsupported Version Number”，则LS已提供其尝试的版本号、其对等方尝试的版本号、其对等方在通知消息中传递的版本号以及其支持的版本号。如果两个对等方支持一个或多个通用版本，那么这将允许它们快速确定最高的通用版本。为了支持TRIP版本协商，TRIP的未来版本必须保留开放和通知消息的格式。
An LS MAY include the Capabilities Option in its OPEN message to a peer to indicate the capabilities supported by the LS. An LS receiving an OPEN message MUST NOT use any capabilities that were not included in the OPEN message of the peer when communicating with that peer.
LS可以在其向对等方发送的开放消息中包括Capabilities选项，以指示LS支持的功能。在与对等方通信时，接收开放消息的LS不得使用对等方开放消息中未包含的任何功能。
This section specifies TRIP operation in terms of a Finite State Machine (FSM). Following is a brief summary and overview of TRIP operations by state as determined by this FSM. A condensed version of the TRIP FSM is found in Appendix 1. There is one TRIP FSM per peer and these FSMs operate independently.
本节规定了有限状态机（FSM）的跳闸操作。以下是本FSM确定的各州跳闸操作的简要总结和概述。TRIP FSM的浓缩版本见附录1。每个对等机有一个跳闸FSM，这些FSM独立运行。
Idle state: Initially TRIP is in the Idle state for each peer. In this state, TRIP refuses all incoming connections. No resources are allocated to the peer. In response to the Start event (initiated by either the system or the operator), the local system initializes all TRIP resources, starts the ConnectRetry timer, initiates a transport connection to the peer, starts listening for a connection that may be initiated by the remote TRIP peer, and changes its state to Connect. The exact value of the ConnectRetry timer is a local matter, but should be sufficiently large to allow TCP initialization.
空闲状态：每个对等机的初始跳闸处于空闲状态。在此状态下，TRIP拒绝所有传入连接。没有资源分配给对等方。响应启动事件（由系统或操作员启动），本地系统初始化所有跳闸资源，启动ConnectRetry定时器，启动到对等机的传输连接，开始侦听可能由远程跳闸对等机启动的连接，并将其状态更改为连接。ConnectRetry计时器的确切值是本地问题，但应该足够大，以允许TCP初始化。
If an LS detects an error, it closes the transport connection and changes its state to Idle. Transitioning from the Idle state requires generation of the Start event. If such an event is generated automatically, then persistent TRIP errors may result in persistent flapping of the LS. To avoid such a condition, Start events MUST NOT be generated immediately for a peer that was previously transitioned to Idle due to an error. For a peer that was previously transitioned to Idle due to an error, the time between consecutive Start events, if such events are generated automatically, MUST exponentially increase. The value of the initial timer SHOULD be 60 seconds, and the time SHOULD be at least doubled for each consecutive retry up to some maximum value.
如果LS检测到错误，它将关闭传输连接并将其状态更改为空闲。从空闲状态转换需要生成启动事件。若此类事件是自动生成的，则持续跳闸错误可能导致LS持续拍打。为了避免这种情况，对于先前由于错误而转换为空闲的对等方，不能立即生成启动事件。对于之前由于错误而转换为空闲的对等机，如果自动生成连续启动事件，则连续启动事件之间的时间必须呈指数增长。初始计时器的值应为60秒，并且每次连续重试的时间应至少加倍，直至达到某个最大值。
Any other event received in the Idle state is ignored.
在空闲状态下接收到的任何其他事件都将被忽略。
Connect State: In this state, an LS is waiting for a transport protocol connection to be completed to the peer, and is listening for inbound transport connections from the peer.
连接状态：在此状态下，LS正在等待与对等方的传输协议连接完成，并正在侦听来自对等方的入站传输连接。
If the transport protocol connection succeeds, the local LS clears the ConnectRetry timer, completes initialization, sends an OPEN message to its peer, sets its Hold Timer to a large value, and changes its state to OpenSent. A Hold Timer value of 4 minutes is suggested.
如果传输协议连接成功，本地LS将清除ConnectRetry计时器，完成初始化，向其对等方发送打开消息，将其保持计时器设置为大值，并将其状态更改为OpenSent。建议保持计时器值为4分钟。
If the transport protocol connect fails (e.g., retransmission timeout), the local system restarts the ConnectRetry timer, continues to listen for a connection that may be initiated by the remote LS, and changes its state to Active state.
如果传输协议连接失败（例如，重传超时），本地系统将重新启动ConnectRetry计时器，继续侦听可能由远程LS启动的连接，并将其状态更改为活动状态。
In response to the ConnectRetry timer expired event, the local LS cancels any outstanding transport connection to the peer, restarts the ConnectRetry timer, initiates a transport connection to the remote LS, continues to listen for a connection that may be initiated by the remote LS, and stays in the Connect state.
作为对ConnectRetry timer expired事件的响应，本地LS取消到对等方的任何未完成的传输连接，重新启动ConnectRetry timer，启动到远程LS的传输连接，继续侦听可能由远程LS启动的连接，并保持连接状态。
If the local LS detects that a remote peer is trying to establish a connection to it and the IP address of the peer is not an expected one, then the local LS rejects the attempted connection and continues to listen for a connection from its expected peers without changing state.
如果本地LS检测到远程对等方正试图与其建立连接，并且该对等方的IP地址不是预期的，则本地LS拒绝尝试的连接，并继续侦听来自其预期对等方的连接，而不更改状态。
If an inbound transport protocol connection succeeds, the local LS clears the ConnectRetry timer, completes initialization, sends an OPEN message to its peer, sets its Hold Timer to a large value, and changes its state to OpenSent. A Hold Timer value of 4 minutes is suggested.
如果入站传输协议连接成功，本地LS将清除ConnectRetry计时器，完成初始化，向其对等方发送打开消息，将其保持计时器设置为大值，并将其状态更改为OpenSent。建议保持计时器值为4分钟。
The Start event is ignored in the Connect state.
在连接状态下忽略启动事件。
In response to any other event (initiated by either the system or the operator), the local system releases all TRIP resources associated with this connection and changes its state to Idle.
响应任何其他事件（由系统或操作员启动），本地系统释放与此连接相关的所有跳闸资源，并将其状态更改为空闲。
Active state: In this state, an LS is listening for an inbound connection from the peer, but is not in the process of initiating a connection to the peer.
活动状态：在此状态下，LS正在侦听来自对等方的入站连接，但不在启动到对等方的连接的过程中。
If an inbound transport protocol connection succeeds, the local LS clears the ConnectRetry timer, completes initialization, sends an OPEN message to its peer, sets its Hold Timer to a large value, and changes its state to OpenSent. A Hold Timer value of 4 minutes is suggested.
如果入站传输协议连接成功，本地LS将清除ConnectRetry计时器，完成初始化，向其对等方发送打开消息，将其保持计时器设置为大值，并将其状态更改为OpenSent。建议保持计时器值为4分钟。
In response to the ConnectRetry timer expired event, the local system restarts the ConnectRetry timer, initiates a transport connection to the TRIP peer, continues to listen for a connection that may be initiated by the remote TRIP peer, and changes its state to Connect.
为响应ConnectRetry timer expired事件，本地系统重新启动ConnectRetry timer，启动到TRIP peer的传输连接，继续侦听可能由远程TRIP peer启动的连接，并将其状态更改为Connect。
If the local LS detects that a remote peer is trying to establish a connection to it and the IP address of the peer is not an expected one, then the local LS rejects the attempted connection and continues to listen for a connection from its expected peers without changing state.
如果本地LS检测到远程对等方正试图与其建立连接，并且该对等方的IP地址不是预期的，则本地LS拒绝尝试的连接，并继续侦听来自其预期对等方的连接，而不更改状态。
Start event is ignored in the Active state.
启动事件在活动状态下被忽略。
In response to any other event (initiated by either the system or the operator), the local system releases all TRIP resources associated with this connection and changes its state to Idle.
响应任何其他事件（由系统或操作员启动），本地系统释放与此连接相关的所有跳闸资源，并将其状态更改为空闲。
OpenSent state: In this state, an LS has sent an OPEN message to its peer and is waiting for an OPEN message from its peer. When an OPEN message is received, all fields are checked for correctness. If the TRIP message header checking or OPEN message checking detects an error (see Section 6.2) or a connection collision (see Section 6.8), the local system sends a NOTIFICATION message and changes its state to Idle.
OpenSent状态：在此状态下，LS已向其对等方发送打开的消息，并正在等待来自其对等方的打开的消息。当收到打开的消息时，将检查所有字段的正确性。如果跳闸消息头检查或打开消息检查检测到错误（参见第6.2节）或连接冲突（参见第6.8节），本地系统将发送通知消息并将其状态更改为空闲。
If there are no errors in the OPEN message, TRIP sends a KEEPALIVE message and sets a KeepAlive timer. The Hold Timer, which was originally set to a large value (see above), is replaced with the negotiated Hold Time value (see Section 4.2). If the negotiated Hold Time value is zero, then the Hold Time timer and KeepAlive timers are not started. If the value of the ITAD field is the same as the local ITAD number, then the connection is an "internal" connection; otherwise, it is "external" (this will affect UPDATE processing). Finally, the state is changed to OpenConfirm.
如果打开消息中没有错误，TRIP将发送KEEPALIVE消息并设置KEEPALIVE计时器。最初设置为大值（见上文）的保持计时器将替换为协商的保持时间值（见第4.2节）。如果协商的保持时间值为零，则保持时间计时器和保留时间计时器不会启动。如果ITAD字段的值与本地ITAD编号相同，则该连接为“内部”连接；否则，它是“外部的”（这将影响更新处理）。最后，状态更改为OpenConfirm。
If the local LS detects that a remote peer is trying to establish a connection to it and the IP address of the peer is not an expected one, then the local LS rejects the attempted connection and continues to listen for a connection from its expected peers without changing state.
如果本地LS检测到远程对等方正试图与其建立连接，并且该对等方的IP地址不是预期的，则本地LS拒绝尝试的连接，并继续侦听来自其预期对等方的连接，而不更改状态。
If a disconnect notification is received from the underlying transport protocol, the local LS closes the transport connection, restarts the ConnectRetry timer, continues to listen for a connection that may be initiated by the remote TRIP peer, and goes into the Active state.
如果从基础传输协议接收到断开连接通知，本地LS将关闭传输连接，重新启动ConnectRetry计时器，继续侦听可能由远程跳闸对等方启动的连接，并进入活动状态。
If the Hold Timer expires, the local LS sends a NOTIFICATION message with the Error Code "Hold Timer Expired" and changes its state to Idle.
如果保持计时器过期，本地LS将发送一条错误代码为“保持计时器过期”的通知消息，并将其状态更改为空闲。
In response to the Stop event (initiated by either system or operator) the local LS sends a NOTIFICATION message with the Error Code "Cease" and changes its state to Idle.
为响应停止事件（由系统或操作员启动），本地LS发送带有错误代码“Stop”的通知消息，并将其状态更改为Idle。
The Start event is ignored in the OpenSent state.
在OpenSent状态下忽略启动事件。
In response to any other event the local LS sends a NOTIFICATION message with the Error Code "Finite State Machine Error" and changes its state to Idle.
为了响应任何其他事件，本地LS发送一条带有错误代码“有限状态机错误”的通知消息，并将其状态更改为空闲。
Whenever TRIP changes its state from OpenSent to Idle, it closes the transport connection and releases all resources associated with that connection.
每当TRIP将其状态从OpenSent更改为Idle时，它都会关闭传输连接并释放与该连接相关的所有资源。
OpenConfirm state: In this state, an LS has sent an OPEN to its peer, received an OPEN from its peer, and sent a KEEPALIVE in response to the OPEN. The LS is now waiting for a KEEPALIVE or NOTIFICATION message in response to its OPEN.
OpenConfirm状态：在此状态下，LS向其对等方发送了一个OPEN，从其对等方接收到一个OPEN，并发送了一个KEEPALIVE以响应该OPEN。LS现在正在等待一条KEEPALIVE或通知消息，以响应其打开状态。
If the local LS receives a KEEPALIVE message, it changes its state to Established.
如果本地LS接收到KEEPALIVE消息，它会将其状态更改为已建立。
If the Hold Timer expires before a KEEPALIVE message is received, the local LS sends NOTIFICATION message with the Error Code "Hold Timer Expired" and changes its state to Idle.
如果在收到KEEPALIVE消息之前保持计时器过期，本地LS将发送错误代码为“保持计时器已过期”的通知消息，并将其状态更改为空闲。
If the local LS receives a NOTIFICATION message, it changes its state to Idle.
如果本地LS接收到通知消息，它会将其状态更改为空闲。
If the KeepAlive timer expires, the local LS sends a KEEPALIVE message and restarts its KeepAlive timer.
如果KeepAlive计时器过期，本地LS将发送KeepAlive消息并重新启动其KeepAlive计时器。
If a disconnect notification is received from the underlying transport protocol, the local LS closes the transport connection, restarts the ConnectRetry timer, continues to listen for a connection that may be initiated by the remote TRIP peer, and goes into the Active state.
如果从基础传输协议接收到断开连接通知，本地LS将关闭传输连接，重新启动ConnectRetry计时器，继续侦听可能由远程跳闸对等方启动的连接，并进入活动状态。
In response to the Stop event (initiated by either the system or the operator) the local LS sends NOTIFICATION message with the Error Code "Cease" and changes its state to Idle.
响应停止事件（由系统或操作员启动），本地LS发送带有错误代码“Stop”的通知消息，并将其状态更改为Idle。
The Start event is ignored in the OpenConfirm state.
在OpenConfirm状态下忽略启动事件。
In response to any other event the local LS sends a NOTIFICATION message with the Error Code "Finite State Machine Error" and changes its state to Idle.
为了响应任何其他事件，本地LS发送一条带有错误代码“有限状态机错误”的通知消息，并将其状态更改为空闲。
Whenever TRIP changes its state from OpenConfirm to Idle, it closes the transport connection and releases all resources associated with that connection.
每当TRIP将其状态从OpenConfirm更改为Idle时，它都会关闭传输连接并释放与该连接相关的所有资源。
Established state: In the Established state, an LS can exchange UPDATE, NOTIFICATION, and KEEPALIVE messages with its peer.
已建立状态：在已建立状态下，LS可以与其对等方交换更新、通知和保留消息。
If the negotiated Hold Timer is zero, then no procedures are necessary for keeping a peering session alive. If the negotiated Hold Time value is non-zero, the procedures of this paragraph apply. If the Hold Timer expires, the local LS sends a NOTIFICATION message with the Error Code "Hold Timer Expired" and changes its state to Idle. If the KeepAlive Timer expires, then the local LS sends a KeepAlive message and restarts the KeepAlive Timer. If the local LS receives an UPDATE or KEEPALIVE message, then it restarts its Hold Timer. Each time the LS sends an UPDATE or KEEPALIVE message, it restarts its KeepAlive Timer.
如果协商保持计时器为零，则无需执行任何过程来保持对等会话处于活动状态。如果协商的等待时间值不为零，则适用本段的程序。如果保持计时器过期，本地LS将发送一条错误代码为“保持计时器过期”的通知消息，并将其状态更改为空闲。如果KeepAlive计时器过期，则本地LS发送KeepAlive消息并重新启动KeepAlive计时器。如果本地LS收到UPDATE或KEEPALIVE消息，则它将重新启动保持计时器。每次LS发送更新或KEEPALIVE消息时，它都会重新启动其KEEPALIVE计时器。
If the local LS receives a NOTIFICATION message, it changes its state to Idle.
如果本地LS接收到通知消息，它会将其状态更改为空闲。
If the local LS receives an UPDATE message and the UPDATE message error handling procedure (see Section6.3) detects an error, the local LS sends a NOTIFICATION message and changes its state to Idle.
如果本地LS接收到更新消息，且更新消息错误处理程序（参见第6.3节）检测到错误，则本地LS发送通知消息并将其状态更改为空闲。
If a disconnect notification is received from the underlying transport protocol, the local LS changes its state to Idle.
如果从基础传输协议接收到断开连接通知，则本地LS将其状态更改为空闲。
In response to the Stop event (initiated by either the system or the operator), the local LS sends a NOTIFICATION message with the Error Code "Cease" and changes its state to Idle.
为响应停止事件（由系统或操作员启动），本地LS发送带有错误代码“Stop”的通知消息，并将其状态更改为Idle。
The Start event is ignored in the Established state.
在已建立状态下忽略启动事件。
In response to any other event, the local LS sends a NOTIFICATION message with Error Code "Finite State Machine Error" and changes its state to Idle.
作为对任何其他事件的响应，本地LS发送错误代码为“有限状态机错误”的通知消息，并将其状态更改为空闲。
Whenever TRIP changes its state from Established to Idle, it closes the transport connection and releases all resources associated with that connection. Additionally, if the peer is an external peer, the LS deletes all routes derived from that connection.
每当TRIP将其状态从已建立更改为空闲时，它都会关闭传输连接并释放与该连接相关的所有资源。此外，如果对等方是外部对等方，LS将删除从该连接派生的所有路由。
An UPDATE message may be received only in the Established state. When an UPDATE message is received, each field is checked for validity as specified in Section 6.3. The rest of this section presumes that the UPDATE message has passed the error-checking procedures of Section 6.3.
只能在已建立状态下接收更新消息。当收到更新消息时，按照第6.3节的规定检查每个字段的有效性。本节其余部分假定更新消息已通过第6.3节的错误检查程序。
If the UPDATE message was received from an internal peer, the flooding procedures of Section 10.1 MUST be applied. The flooding process synchronizes the Loc-TRIBs of all LSs within the domain. Certain routes within the UPDATE may be marked as old or duplicates by the flooding process and are ignored during the rest of the UPDATE processing.
如果从内部对等方收到更新消息，则必须应用第10.1节中的泛洪程序。泛洪过程同步域内所有LSs的Loc TRIB。更新中的某些路由可能被泛洪过程标记为旧路由或重复路由，并在其余更新过程中被忽略。
If the UPDATE message contains withdrawn routes, then the corresponding previously advertised routes shall be removed from the Adj-TRIB-In. This LS MUST rerun its Decision Process since the previously advertised route is no longer available for use.
如果更新消息包含撤回的路由，则应将先前公布的相应路由从中的Adj TRIB中删除。此LS必须重新运行其决策过程，因为以前公布的路由不再可用。
If the UPDATE message contains a route, then the route MUST be placed in the appropriate Adj-TRIB-In, and the following additional actions MUST be taken:
如果更新消息包含路由，则必须将路由放置在相应的Adj TRIB in中，并且必须采取以下附加操作：
1. If its destinations are identical to those of a route currently stored in the Adj-TRIB-In, then the new route MUST replace the older route in the Adj-TRIB-In, thus implicitly withdrawing the older route from service. The LS MUST rerun its Decision Process since the older route is no longer available for use. 2. If the new route is more specific than an earlier route contained in the Adj-TRIB-In and has identical attributes, then no further actions are necessary. 3. If the new route is more specific than an earlier route contained in the Adj-TRIB-In but does not have identical attributes, then the LS MUST run its Decision Process since the more specific route has implicitly made a portion of the less specific route unavailable for use. 4. If the new route has destinations that are not present in any of the routes currently stored in the Adj-TRIB-In, then the LS MUST run its Decision Process. 5. If the new route is less specific than an earlier route contained in the Adj-TRIB-In, the LS MUST run its Decision Process on the set of destinations that are described only by the less specific route.
1. 如果其目的地与Adj TRIB in中当前存储的路线的目的地相同，则新路线必须替换Adj TRIB in中的旧路线，从而隐式地将旧路线从服务中撤回。LS必须重新运行其决策过程，因为旧路由不再可用。2.如果新路由比中Adj TRIB中包含的早期路由更具体，并且具有相同的属性，则无需采取进一步的操作。3.如果新路由比Adj TRIB in中包含的早期路由更具体，但没有相同的属性，则LS必须运行其决策过程，因为更具体的路由隐式地使不太具体的路由的一部分不可用。4.如果新路线的目的地不在当前存储在Adj TRIB in中的任何路线中，则LS必须运行其决策过程。5.如果新路线没有Adj TRIB in中包含的早期路线具体，则LS必须在仅由不太具体的路线描述的目的地集上运行其决策过程。
When an LS receives an UPDATE message from an internal peer, the LS floods the new information from that message to all of its other internal peers. Flooding is used to efficiently synchronize all of the LSs within a domain without putting any constraints on the domain's internal topology. The flooding mechanism is based on the techniques used in OSPF [4] and SCSP [6]. One may argue that TRIP's flooding process is in reality a controlled broadcast mechanism.
当LS接收到来自内部对等方的更新消息时，LS会将该消息中的新信息发送到其所有其他内部对等方。泛洪用于高效地同步域内的所有LSs，而无需对域的内部拓扑施加任何约束。泛洪机制基于OSPF[4]和SCSP[6]中使用的技术。有人可能会说TRIP的泛滥过程实际上是一种受控的广播机制。
The LS MUST maintain the sequence number and originating TRIP identifier for each link-state encapsulated attribute in an internal Adj-TRIB-In. These values are included with the route in the ReachableRoutes, WithdrawnRoutes, and ITAD Topology attributes. The originating TRIP identifier gives the internal LS that originated this route into the ITAD, the sequence number gives the version of this route at the originating LS.
LS必须在内部Adj TRIB in中维护每个链路状态封装属性的序列号和起始跳闸标识符。这些值包含在“可到达路由”、“撤回路由”和“ITAD拓扑”属性中的路由中。始发行程标识符给出了将该路线发送至ITAD的内部LS，序列号给出了始发LS处该路线的版本。
For each route in the ReachableRoutes or WithdrawnRoutes field, the LS decides if the route is new or old. This is determined by comparing the Sequence Number of the route in the UPDATE with the Sequence Number of the route saved in the Adj-TRIB-In. The route is new if either the route does not exist in the Adj-TRIB-In for the originating LS, or if the route does exist in the Adj-TRIB-In but the Sequence Number in the UPDATE is greater than the Sequence Number saved in the Adj-TRIBs-In. Note that the newness test is independently applied to each link-state encapsulated attribute in the UPDATE (WithdrawnRoutes or ReachableRoutes or ITAD Topology).
对于“可到达路由”或“撤回路由”字段中的每个路由，LS决定该路由是新路由还是旧路由。这是通过比较更新中路由的序列号与中Adj TRIB中保存的路由序列号来确定的。如果原始LS的Adj TRIB in中不存在路由，或者如果Adj TRIB in中确实存在路由，但更新中的序列号大于Adj TRIB in中保存的序列号，则路由为新路由。请注意，新性测试独立应用于更新中封装的每个链路状态属性（撤回路由或可到达路由或ITAD拓扑）。
Each route in the ReachableRoutes or WithdrawnRoutes field that is determined to be old is ignored in further processing. If the route is determined to be new then the following actions occur.
在进一步的处理中，将忽略“可到达路由”或“撤回路由”字段中确定为旧的每条路由。如果确定路线为新路线，则会发生以下操作。
If the route is being withdrawn, then the LS MUST flood the withdrawn route to all other internal peers, and MUST mark the route as withdrawn. An LS MUST maintain routes marked as withdrawn in its databases for MaxPurgeTime seconds.
如果正在撤回路由，则LS必须将撤回的路由泛洪到所有其他内部对等方，并且必须将路由标记为撤回。LS必须在其数据库中维护标记为撤回的路由MaxPurgeTime秒。
If the route is being updated, then the LS MUST update the route in the Adj-TRIB-In and MUST flood it to all other internal peers.
如果正在更新路由，则LS必须在Adj TRIB in中更新路由，并且必须将其应用到所有其他内部对等方。
If these procedures result in changes to the Adj-TRIB-In, then the route is also made available for local route processing as described early in Section 10.
如果这些程序导致Adj TRIB in发生变化，则该路线也可用于第10节前面所述的本地路线处理。
To implement flooding, the following is recommended. All routes received in a single UPDATE message that are determined to be new should be forwarded to all other internal peers in a single UPDATE message. Other variations of flooding are possible, but the local LS MUST ensure that each new route (and any associated attributes) received from an internal peer get forwarded to every other internal peer.
要实施泛洪，建议采取以下措施。在单个更新消息中接收到的所有被确定为新的路由应在单个更新消息中转发给所有其他内部对等方。泛洪的其他变化是可能的，但是本地LS必须确保从内部对等接收到的每个新路由（以及任何相关属性）被转发到每个其他内部对等。
The Sequence Number is used to determine when one version of a Route is newer than another version of a route. A larger Sequence Number indicates a newer version. The Sequence Number is assigned by the LS originating the route into the local ITAD. The Sequence Number is an unsigned 4-octet integer in the range of 1 thru 2^31-1 MinSequenceNum thru MaxSequenceNum). The value 0 is reserved. When an LS first originates a route (including when the LS restarts/reboots) into its ITAD, it MUST originate it with a Sequence Number of MinSequenceNum. Each time the route is updated within the ITAD by the originator, the Sequence Number MUST be increased.
序列号用于确定一个版本的路由何时比另一个版本的路由更新。序列号越大表示版本越新。序列号由发送路由到本地ITAD的LS分配。序列号是一个无符号的4八位整数，范围为1到2^31-1分钟SequenceNum到MaxSequenceNum）。值0是保留的。当LS首次向其ITAD发起路由（包括LS重新启动/重新启动时）时，它必须以MinSequenceNum的序列号发起路由。每次发起者在ITAD内更新路由时，必须增加序列号。
If it is ever the case that the sequence number is MaxSequenceNum-1 and it needs to be increased, then the TRIP module of the LS MUST be disabled for a period of TripDisableTime so that all routes originated by this LS with high sequence numbers can be removed.
如果序列号为MaxSequenceNum-1且需要增加，则必须在TripDisableTime一段时间内禁用LS的跳闸模块，以便删除该LS发出的所有具有高序列号的路由。
To withdraw a route that it originated within the ITAD, an LS includes the route in the WithdrawnRoutes field of an UPDATE message. The Sequence Number MUST be greater than the last valid version of the route. The LS MAY choose to use a sequence number of MaxSequenceNum when withdrawing routes within its ITAD, but this is not required.
要撤回其在ITAD中发起的路由，LS将该路由包括在更新消息的“撤回路由”字段中。序列号必须大于路由的最后有效版本。LS在其ITAD内提取路由时，可以选择使用MaxSequenceNum的序列号，但这不是必需的。
After withdrawing a route, an LS MUST mark the route as "withdrawn" in its database, and maintain the withdrawn route in its database for MaxPurgeTime seconds. If the LS needs to re-originate a route that had been purged but is still in its database, it can either re-originate the route immediately using a Sequence Number that is greater than that used in the withdraw, or the LS may wait until MaxPurgeTime seconds have expired since the route was withdrawn.
撤回路由后，LS必须在其数据库中将路由标记为“撤回”，并在其数据库中维护撤回的路由MaxPurgeTime秒。如果LS需要重新发起已清除但仍在其数据库中的路由，则LS可以立即使用大于撤回中使用的序列号重新发起路由，或者LS可以等到路由撤回后MaxPurgeTime秒已过期。
It is common for an LS to receive UPDATES for routes that it originated within the ITAD via the flooding procedure. If the LS receives an UPDATE for a route that it originated that is newer (has a higher sequence number) than the LSs current version, then special actions must be taken. This should be a relatively rare occurrence and indicates that a route still exists within the ITAD since the LSs last restart/reboot.
LS通常会通过泛洪程序接收ITAD中发起的路由更新。如果LS接收到其发起的路由更新（序列号高于LSs当前版本），则必须采取特殊措施。这应该是一种相对罕见的情况，表明自LSs上次重新启动/重新启动以来，ITAD中仍存在路由。
If an LS receives a self-originated route update that is newer than the current version of the route at the LS, then the following actions MUST be taken. If the LS still wishes to advertise the information in the route, then the LS MUST increase the Sequence Number of the route to a value greater than that received in the UPDATE and re-originate the route. If the LS does not wish to continue to advertise the route, then it MUST purge the route as described in Section 10.1.5.
如果LS接收到比LS处路由的当前版本更新的自源路由更新，则必须采取以下操作。如果LS仍希望公布路由中的信息，则LS必须将路由的序列号增加到大于更新中接收到的值，并重新发起路由。如果LS不希望继续公布路线，则必须按照第10.1.5节所述清除路线。
An LS SHOULD ensure that routes marked as withdrawn are removed from the database in a timely fashion after the MaxPurgeTime has expired. This could be done, for example, by periodically sweeping the database, and deleting those entries that were withdrawn more than MaxPurgeTime seconds ago.
LS应确保在MaxPurgeTime过期后及时从数据库中删除标记为撤回的路由。例如，可以通过定期扫描数据库并删除那些在超过MaxPurgeTime秒前提取的条目来实现。
The Decision Process selects routes for subsequent advertisement by applying the policies in the local Policy Information Base (PIB) to the routes stored in its Adj-TRIBs-In. The output of the Decision process is the set of routes that will be advertised to all peers; the selected routes will be stored in the local LS's Adj-TRIBs-Out.
决策过程通过将本地策略信息库（PIB）中的策略应用于存储在中的Adj TRIB中的路由来选择用于后续广告的路由。决策过程的输出是将向所有对等方通告的路由集；选定的路线将存储在本地LS的Adj TRIBs Out中。
The selection process is formalized by defining a function that takes the attributes of a given route as an argument and returns a non-negative integer denoting the degree of preference for the route. The function that calculates the degree of preference for a given route shall not use as its inputs any of the following: the existence of other routes, the non-existence of other routes, or the attributes of other routes. Route selection then consists of an individual application of the degree of preference function to each feasible route, followed by the choice of the one with the highest degree of preference.
选择过程通过定义一个函数形式化，该函数将给定路由的属性作为参数，并返回一个非负整数，表示对路由的偏好程度。计算给定路线偏好度的函数不得使用以下任何一项作为其输入：存在其他路线、不存在其他路线或其他路线的属性。然后，路线选择包括对每个可行路线单独应用偏好度函数，然后选择偏好度最高的路线。
All internal LSs in an ITAD MUST run the Decision Process and apply the same decision criteria, otherwise it will not be possible to synchronize their Loc-TRIBs.
ITAD中的所有内部LSs必须运行决策流程并应用相同的决策标准，否则无法同步其Loc TRIB。
The Decision Process operates on routes contained in each Adj-TRIBs-In, and is responsible for:
决策过程在中的每个Adj TRIB中包含的路线上运行，并负责：
- selection of routes to be advertised to internal peers - selection of routes to be advertised to external peers - route aggregation and route information reduction
- 选择要通告给内部对等方的路由-选择要通告给外部对等方的路由-路由聚合和路由信息缩减
The Decision Process takes place in three distinct phases, each triggered by a different event:
决策过程分为三个不同的阶段，每个阶段由不同的事件触发：
- Phase 1 is responsible for calculating the degree of preference for each route received from an external peer. - Phase 2 is invoked on completion of phase 1. It is responsible for choosing the best route out of all those available for each distinct destination, and for installing each chosen route into the Loc-TRIB. - Phase 3 is invoked after the Loc-TRIB has been modified. It is responsible for disseminating routes in the Loc-TRIB to each external peer, according to the policies contained in the PIB. Route aggregation and information reduction can optionally be performed within this phase.
- 阶段1负责计算从外部对等方接收到的每个路由的偏好程度。-阶段2在阶段1完成时调用。它负责从每个不同目的地的所有可用路线中选择最佳路线，并将每个选择的路线安装到Loc TRIB中。-修改Loc TRIB后调用阶段3。它负责根据PIB中包含的政策，向每个外部对等方传播Loc TRIB中的路由。路由聚合和信息缩减可以选择在此阶段中执行。
The Phase 1 decision function shall be invoked whenever the local LS receives from a peer an UPDATE message that advertises a new route, a replacement route, or a withdrawn route.
当本地LS从对等方接收到播发新路由、替换路由或撤销路由的更新消息时，应调用阶段1决策功能。
The Phase 1 decision function is a separate process that is completed when it has no further work to do.
第1阶段决策功能是一个单独的过程，在没有其他工作要做时完成。
The Phase 1 decision function shall lock an Adj-TRIB-In prior to operating on any route contained within it, and shall unlock it after operating on all new or replacement routes contained within it.
第1阶段决策功能应在对包含在其中的任何路线进行操作之前锁定Adj TRIB，并在对包含在其中的所有新路线或替换路线进行操作之后解锁Adj TRIB。
The local LS MUST determine a degree of preference for each newly received or replacement route. If the route is learned from an internal peer, the value of the LocalPreference attribute MUST be taken as the degree of preference. If the route is learned from an external peer, then the degree of preference MUST be computed based on pre-configured policy information and used as the LocalPreference value in any intra-domain TRIP advertisement. The exact nature of this policy information and the computation involved is a local matter.
本地LS必须确定每个新接收或更换路线的优先程度。如果路由是从内部对等方学习的，则必须将LocalPreference属性的值作为首选程度。如果路由是从外部对等方学习的，则必须根据预先配置的策略信息计算偏好度，并将其用作任何域内旅行公告中的本地偏好值。该政策信息的确切性质和涉及的计算是一个局部问题。
The output of the degree of preference determination process is the local preference of a route. The local LS computes the local preference of routes learned from external peers or originated internally at that LS. The local preference of a route learned from an internal peer is included in the LocalPreference attribute associated with that route.
偏好度确定过程的输出是路线的局部偏好。本地LS计算从外部对等点学习或在该LS内部发起的路由的本地偏好。从内部对等方学习的路由的本地首选项包含在与该路由关联的LocalPreference属性中。
The Phase 2 decision function shall be invoked on completion of Phase 1. The Phase 2 function is a separate process that completes when it has no further work to do. Phase 2 consists of two sub-phases: 2a and 2b. The same route selection function is applied in both sub-phases, but the inputs to each phase are different. The Phase 2a process MUST consider as inputs all external routes, that are present in the Adj-TRIBs-In of external peers, and all local routes. The output of Phase 2a is inserted into the Ext-TRIB. The Phase 2b process shall be invoked upon completion of Phase 2a and it MUST consider as inputs all routes in the Ext-TRIB and all routes that are present in the Adj-TRIBs-In of internal LSs. The output of Phase 2b is stored in the Loc-TRIB.
第2阶段决策功能应在第1阶段完成时调用。第2阶段功能是一个单独的过程，在没有其他工作要做时完成。第2阶段包括两个子阶段：2a和2b。两个子阶段采用相同的路线选择功能，但每个阶段的输入不同。阶段2a过程必须考虑作为输入的所有外部路由，存在于外部节点的ADJ分支中，以及所有本地路由。相位2a的输出插入到外部TRIB中。阶段2b过程应在完成第2A阶段时调用，并且必须考虑作为输入的EXT TIB中的所有路由和内部LSs中的ADJ分支中存在的所有路由。相位2b的输出存储在Loc TRIB中。
The Phase 2 decision function MUST be blocked from running while the Phase 3 decision function is in process. The Phase 2 function MUST lock all Adj-TRIBs-In and the Ext-TRIB prior to commencing its function, and MUST unlock them on completion.
当第3阶段决策功能正在运行时，必须阻止第2阶段决策功能运行。第2阶段功能必须在开始其功能之前锁定所有Adj TRIB In和Ext TRIB，并且必须在完成时解锁它们。
If the LS determines that the NextHopServer listed in a route is unreachable, then the route MAY be excluded from the Phase 2 decision function. The means by which such a determination is made is not mandated here.
如果LS确定某个路由中列出的下一个ThopServer不可访问，则该路由可能被排除在第2阶段决策功能之外。此处未规定作出此类决定的方法。
For each set of destinations for which one or more routes exist, the local LS's route selection function MUST identify the route that has:
对于存在一条或多条路线的每组目的地，本地LS的路线选择功能必须识别具有以下功能的路线：
- the highest degree of preference, or - is selected as a result of the tie breaking rules specified in 10.2.2.1.
- 根据10.2.2.1中规定的打破领带规则，选择最高偏好度，或-作为结果。
Withdrawn routes MUST be removed from the Loc-TRIB, Ext-TRIB, and the Adj-TRIBs-In.
撤回的路线必须从Loc TRIB、Ext TRIB和Adj TRIB中移除。
Several routes to the same destination that have the same degree of preference may be input to the Phase 2 route selection function. The local LS can select only one of these routes for inclusion in the
到同一目的地且具有相同偏好程度的多条路线可输入至阶段2路线选择功能。本地LS只能选择其中一条路由以包含在
associated Ext-TRIB (Phase 2a) or Loc-TRIB (Phase 2b). The local LS considers all routes with the same degrees of preference. The following algorithm shall be used to break ties.
相关外部TRIB（阶段2a）或Loc TRIB（阶段2b）。本地LS考虑具有相同偏好程度的所有路线。应使用以下算法断开连接。
- If the local LS is configured to use the MultiExitDisc attribute to break ties, and candidate routes received from the same neighboring ITAD differ in the value of the MultiExitDisc attribute, then select the route that has the larger value of MultiExitDisc. - If at least one of the routes was originated by an internal LS, select the route route that was advertised by the internal LS that has the lowest TRIP ID. - Otherwise, select the route that was advertised by the neighbor domain that has the lowest ITAD number.
- 如果本地LS配置为使用MultiExitDisc属性断开连接，并且从同一相邻ITAD接收的候选路由的MultiExitDisc属性值不同，则选择MultiExitDisc值较大的路由。-如果至少有一条路由由内部LS发起，请选择由具有最低行程ID的内部LS播发的路由。否则，请选择由具有最低ITAD号的邻居域播发的路由。
The Phase 3 decision function MUST be invoked upon completion of Phase 2 if Phase 2 results in changes to the Loc-TRIB or when a new LS-to-LS peer session is established.
如果第2阶段导致Loc TRIB发生变化或建立新的LS-to-LS对等会话，则必须在第2阶段完成后调用第3阶段决策功能。
The Phase 3 function is a separate process that is completed when it has no further work to do. The Phase 3 routing decision function MUST be blocked from running while the Phase 2 decision function is in process.
第3阶段功能是一个单独的过程，在没有其他工作要做时完成。当第2阶段决策功能正在运行时，必须阻止第3阶段路由决策功能运行。
All routes in the Loc-TRIB shall be processed into a corresponding entry in the associated Adj-TRIBs-Out. Route aggregation and information reduction techniques (see 10.3.4) MAY optionally be applied.
Loc TRIB中的所有路线应处理为相关Adj TRIB Out中的相应条目。可选择应用路由聚合和信息缩减技术（见10.3.4）。
When the updating of the Adj-TRIBs-Out is complete, the local LS MUST run the external update process of 10.3.2.
当Adj TRIB Out的更新完成时，本地LS必须运行10.3.2的外部更新过程。
When overlapping routes are present in the same Adj-TRIB-In, the more specific route shall take precedence, in order, from most specific to least specific.
当重叠路线出现在同一Adj TRIB in中时，更具体的路线应按从最具体到最不具体的顺序优先。
The set of destinations described by the overlap represents a portion of the less specific route that is feasible, but is not currently in use. If a more specific route is later withdrawn, the set of destinations described by the more specific route will still be reachable using the less specific route.
重叠描述的目的地集表示不太具体的路线中可行但当前未使用的一部分。如果以后撤销了更具体的路由，则仍然可以使用不太具体的路由访问由更具体的路由描述的目的地集。
If an LS receives overlapping routes, the Decision Process MUST take into account the semantics of the overlapping routes. In particular, if an LS accepts the less specific route while rejecting the more specific route from the same peer, then the destinations represented by the overlap may not forward along the domains listed in the AdvertisementPath attribute of that route. Therefore, an LS has the following choices:
如果LS接收到重叠路由，则决策过程必须考虑重叠路由的语义。特别是，如果LS接受不太特定的路由，同时拒绝来自同一对等方的更特定的路由，则由重叠表示的目的地可能不会沿着该路由的AdvertisementPath属性中列出的域转发。因此，LS有以下选择：
1. Install both the less and the more specific routes 2. Install the more specific route only 3. Install the non-overlapping part of the less specific route only (that implies disaggregation of the less-specific route) 4. Aggregate the two routes and install the aggregated route 5. Install the less specific route only 6. Install neither route
1. 安装更少和更具体的管线2。仅安装更具体的路线3。仅安装不太特定的路线的非重叠部分（这意味着分解不太特定的路线）4。聚合两条路由并安装聚合路由5。仅安装不太特定的管线6。两条路线都不安装
If an LS chooses 5), then it SHOULD add AtomicAggregate attribute to the route. A route that carries AtomicAggregate attribute MUST NOT be de-aggregated. That is, the route cannot be made more specific. Forwarding along such a route does not guarantee that route traverses only domains listed in the RoutedPath of the route. If an LS chooses 1), then it MUST NOT advertise the less specific route without the more specific route.
如果LS选择5），则应向路由添加AtomicAggregate属性。不能对带有AtomicAggregate属性的路由进行反聚合。也就是说，路线不能更具体。沿着这样的路由转发并不保证路由只遍历路由的RoutedPath中列出的域。如果LS选择1），则它不得在没有更具体的路由的情况下公布不太具体的路由。
The Update-Send process is responsible for advertising UPDATE messages to all peers. For example, it distributes the routes chosen by the Decision Process to other LSs that may be located in either the same ITAD or a neighboring ITAD. Rules for information exchange between peer LSs located in different ITADs are given in 10.3.2; rules for information exchange between peer LSs located in the same ITAD are given in 10.3.1.
更新发送过程负责向所有对等方发布更新消息。例如，它将决策过程选择的路由分配给可能位于同一ITAD或相邻ITAD中的其他LSs。位于不同ITAD中的对等LSs之间的信息交换规则见10.3.2；位于同一ITAD中的对等LSs之间的信息交换规则见10.3.1。
Before forwarding routes to peers, an LS MUST determine which attributes should be forwarded along with that route. If a not well-known non-transitive attribute is unrecognized, it is quietly ignored. If a not well-known dependent-transitive attribute is unrecognized, and the NextHopServer attribute has been changed by the LS, the unrecognized attribute is quietly ignored. If a not well-known dependent-transitive attribute is unrecognized, and the NextHopServer attribute has not been modified by the LS, the Partial bit in the attribute flags octet is set to 1, and the attribute is retained for propagation to other TRIP speakers. Similarly, if an not well-known independent-transitive attribute is unrecognized, the Partial bit in the attribute flags octet is set to 1, and the attribute is retained for propagation to other TRIP speakers.
在将路由转发给对等方之前，LS必须确定哪些属性应与该路由一起转发。如果一个不知名的非传递属性无法识别，它将被悄悄地忽略。如果不知名的依赖传递属性无法识别，并且LS更改了NextHopServer属性，则会悄悄忽略无法识别的属性。如果未知的从属传递属性无法识别，且LS未修改NextHopServer属性，则属性标志八位字节中的部分位将设置为1，并保留该属性以传播到其他TRIP扬声器。类似地，如果未知的独立传递属性无法识别，则属性标志八位字节中的部分位将设置为1，并保留该属性以传播到其他TRIP扬声器。
If a not well-known attribute is recognized, and has a valid value, then, depending on the type of the not well-known attribute, it is updated, if necessary, for possible propagation to other TRIP speakers.
如果识别出一个不知名的属性，并且该属性具有有效值，则根据该不知名属性的类型，该属性会在必要时进行更新，以便可能传播到其他TRIP扬声器。
The Internal update process is concerned with the distribution of routing information to internal peers.
内部更新过程涉及将路由信息分发给内部对等方。
When an LS receives an UPDATE message from another TRIP LS located in its own ITAD, it is flooded as described in Section 10.1.
当LS从位于其自身ITAD中的另一个跳闸LS接收到更新消息时，其将被淹没，如第10.1节所述。
When an LS receives a new route from an LS in a neighboring ITAD, or if a local route is injected into TRIP, the LS determines the preference of that route. If the new route has the highest degree of preference for all external routes and local routes to a given destination (or if the route was selected via a tie-breaking procedure as specified in 10.3.1.1), the LS MUST insert that new route into the Ext-TRIB database and the LS MUST advertise that route to all other LSs in its ITAD by means of an UPDATE message. The LS MUST advertise itself as the Originator of that route within the ITAD.
当LS从相邻ITAD中的LS接收到新路由时，或者如果将本地路由注入TRIP，LS将确定该路由的首选项。如果新路线对到给定目的地的所有外部路线和本地路线具有最高的偏好程度（或者如果路线是通过10.3.1.1中规定的平局中断程序选择的），LS必须将该新路由插入Ext TRIB数据库，并且LS必须通过更新消息向ITAD中的所有其他LSs公布该路由。LS必须在ITAD中宣传自己是该路由的发起人。
When an LS receives an UPDATE message with a non-empty WithdrawnRoutes attribute from an external peer, or if a local route is withdrawn from TRIP, the LS MUST remove from its Adj-TRIB-In all routes whose destinations were carried in this field. If the withdrawn route was previously selected into the Ext-TRIB, the LS MUST take the following additional steps:
当LS从外部对等方接收到具有非空取款路由属性的更新消息时，或者如果本地路由从TRIP中取款，则LS必须从其Adj TRIB中删除此字段中携带目的地的所有路由。如果先前已将撤回的路线选择到Ext TRIB中，则LS必须采取以下附加步骤：
- If a new route is selected for advertisement for those destinations, then the LS MUST insert the replacement route into Ext-TRIB to replace the withdrawn route and advertise it to all internal LSs. - If a replacement route is not available for advertisement, then the LS MUST include the destinations of the route in the WithdrawnRoutes attribute of an UPDATE message, and MUST send this message to each internal peer. The LS MUST also remove the withdrawn route from the Ext-TRIB.
- 如果为这些目的地选择了一条新路线进行播发，则LS必须将替换路线插入Ext TRIB，以替换撤回的路线，并将其播发给所有内部LSs。-如果替换路由不可用于播发，则LS必须在更新消息的“撤回路由”属性中包含路由的目的地，并且必须将此消息发送给每个内部对等方。LS还必须从Ext TRIB中删除撤回的路线。
If an LS has connections to several external peers, there will be multiple Adj-TRIBs-In associated with these peers. These databases might contain several equally preferable routes to the same
如果LS连接到多个外部对等点，则将有多个Adj TRIB与这些对等点关联。这些数据库可能包含到同一数据库的多条同样可取的路由
destination, all of which were advertised by external peers. The local LS shall select one of these routes according to the following rules:
目的地，所有这些都由外部对等方发布广告。当地LS应根据以下规则选择其中一条路线：
- If the LS is configured to use the MultiExitDisc attribute to break ties, and the candidate routes differ in the value of the MultiExitDisc attribute, then select the route that has the lowest value of MultiExitDisc, else - Select the route that was advertised by the external LS that has the lowest TRIP Identifier.
- 如果LS配置为使用MultiExitDisc属性断开连接，且候选路线的MultiExitDisc属性值不同，则选择MultiExitDisc值最低的路线，否则-选择由具有最低行程标识符的外部LS播发的路线。
The external update process is concerned with the distribution of routing information to external peers. As part of the Phase 3 route selection process, the LS has updated its Adj-TRIBs-Out. All newly installed routes and all newly unfeasible routes for which there is no replacement route MUST be advertised to external peers by means of UPDATE messages.
外部更新过程涉及将路由信息分发给外部对等方。作为第3阶段路线选择过程的一部分，LS已更新其Adj TRIB Out。所有新安装的路由和所有没有替换路由的新不可行路由必须通过更新消息通知外部对等方。
Any routes in the Loc-TRIB marked as withdrawn MUST be removed. Changes to the reachable destinations within its own ITAD SHALL also be advertised in an UPDATE message.
必须删除Loc TRIB中标记为撤回的任何路线。对其自身ITAD内可到达目的地的更改也应在更新消息中公布。
The TRIP protocol constrains the amount of routing traffic (that is, UPDATE messages) in order to limit both the link bandwidth needed to advertise UPDATE messages and the processing power needed by the Decision Process to digest the information contained in the UPDATE messages.
TRIP协议限制路由通信量（即更新消息），以限制播发更新消息所需的链路带宽和决策过程消化更新消息中包含的信息所需的处理能力。
The parameter MinRouteAdvertisementInterval determines the minimum amount of time that must elapse between advertisements of routes to a particular destination from a single LS. This rate limiting procedure applies on a per-destination basis, although the value of MinRouteAdvertisementInterval is set on a per LS peer basis.
参数MinRoutedVertisementerval确定从单个LS到特定目的地的路由播发之间必须经过的最小时间量。此速率限制程序适用于每个目的地，尽管MinRoutedVertisementInterval的值是基于每个LS对等点设置的。
Two UPDATE messages sent from a single LS that advertise feasible routes to some common set of destinations received from external peers MUST be separated by at least MinRouteAdvertisementInterval. Clearly, this can only be achieved precisely by keeping a separate timer for each common set of destinations. This would be unwarranted overhead. Any technique which ensures that the interval between two UPDATE messages sent from a single LS that advertise feasible routes
从一个LS发送的两条更新消息（向从外部对等方接收的某个公共目的地集播发可行路由）必须至少用MinRoutedVertisementerval分隔。显然，这只能通过为每个公共目的地设置单独的计时器来精确实现。这将是不必要的开销。任何一种技术，确保从一个播发可行路由的LS发送的两个更新消息之间的间隔
to some common set of destinations received from external peers will be at least MinRouteAdvertisementInterval, and will also ensure that a constant upper bound on the interval is acceptable.
从外部对等方接收到的一些公共目的地集将至少为MinRoutedVertisementInterval，并且还将确保间隔上的恒定上限是可接受的。
Two UPDATE messages, sent from a single LS to an external peer, that advertise feasible routes to some common set of destinations received from internal peers MUST be separated by at least MinRouteAdvertisementInterval.
从单个LS发送到外部对等方的两条更新消息（向从内部对等方接收到的某个公共目的地集播发可行路由）必须至少由MinRouteAdVertiseMintServal分隔。
Since fast convergence is needed within an ITAD, this rate limiting procedure does not apply to routes received from internal peers and being broadcast to other internal peers. To avoid long-lived black holes, the procedure does not apply to the explicit withdrawal of routes (that is, routes whose destinations explicitly withdrawn by UPDATE messages).
由于ITAD内需要快速收敛，该速率限制程序不适用于从内部对等点接收并广播到其他内部对等点的路由。为了避免长寿命黑洞，该过程不适用于路由的显式撤回（即，其目的地通过更新消息显式撤回的路由）。
This procedure does not limit the rate of route selection, but only the rate of route advertisement. If new routes are selected multiple times while awaiting the expiration of MinRouteAdvertisementInterval, the last route selected shall be advertised at the end of MinRouteAdvertisementInterval.
此过程不限制路线选择的速率，只限制路线广告的速率。如果在等待MinRoutedVertisementerval到期时多次选择新路线，则最后选择的路线应在MinRoutedVertisementerval结束时公布。
The parameter MinITADOriginationInterval determines the minimum amount of time that must elapse between successive advertisements of UPDATE messages that report changes within the advertising LS's own ITAD.
参数MinITADOriginationInterval确定在报告播发LS自身ITAD内更改的更新消息的连续播发之间必须经过的最小时间量。
To minimize the likelihood that the distribution of TRIP messages by a given LS will contain peaks, jitter should be applied to the timers associated with MinITADOriginationInterval, KeepAlive, and MinRouteAdvertisementInterval. A given LS shall apply the same jitter to each of these quantities regardless of the destinations to which the updates are being sent; that is, jitter will not be applied on a "per peer" basis.
为使给定LS的跳闸信息分布包含峰值的可能性降至最低，应将抖动应用于与MinITADOriginationInterval、KeepAlive和MinRoutedVertisementInterval相关的计时器。给定的LS应将相同的抖动应用于这些量中的每一个，无论更新发送到哪个目的地；也就是说，抖动不会在“每个对等点”的基础上应用。
The amount of jitter to be introduced shall be determined by multiplying the base value of the appropriate timer by a random factor that is uniformly distributed in the range from 0.75 to 1.0.
应通过将适当计时器的基准值乘以均匀分布在0.75至1.0范围内的随机因子来确定要引入的抖动量。
Having selected the routing information that it will advertise, a TRIP speaker may use methods to organize this information in an efficient manner. These methods are discussed in the following sections.
在选择了将公布的路由信息后，旅行演讲者可以使用各种方法以有效的方式组织这些信息。这些方法将在以下章节中讨论。
Information reduction may imply a reduction in granularity of policy control - after information has collapsed, the same policies will apply to all destinations and paths in the equivalence class.
信息缩减可能意味着策略控制粒度的缩减——在信息崩溃后，相同的策略将应用于等价类中的所有目的地和路径。
The Decision Process may optionally reduce the amount of information that it will place in the Adj-TRIBs-Out by any of the following methods:
决策过程可以通过以下任一方法选择性地减少其将放入Adj TRIB Out中的信息量：
- ReachableRoutes: A set of destinations can be usually represented in compact form. For example, a set of E.164 phone numbers can be represented in more compact form using E.164 prefixes. - AdvertisementPath: AdvertisementPath information can be represented as ordered AP_SEQUENCEs or unordered AP_SETs. AP_SETs are used in the route aggregation algorithm described in Section 5.4.4. They reduce the size of the AP_PATH information by listing each ITAD number only once, regardless of how many times it may have appeared in multiple advertisement paths that were aggregated.
- 可达路线：一组目的地通常可以用紧凑的形式表示。例如，一组E.164电话号码可以使用E.164前缀以更紧凑的形式表示。-AdvertisementPath：AdvertisementPath信息可以表示为有序AP_序列或无序AP_集。AP_集合用于第5.4.4节所述的路由聚合算法。它们通过只列出每个ITAD编号一次来减少AP_路径信息的大小，而不管它在聚合的多个广告路径中出现了多少次。
An AP_SET implies that the destinations advertised in the UPDATE message can be reached through paths that traverse at least some of the constituent ITADs. AP_SETs provide sufficient information to avoid route looping; however their use may prune potentially feasible paths, since such paths are no longer listed individually as in the form of AP_SEQUENCEs. In practice this is not likely to be a problem, since once a call arrives at the edge of a group of ITADs, the LS at that point is likely to have more detailed path information and can distinguish individual paths to destinations.
AP_集合意味着更新消息中公布的目的地可以通过至少穿过部分组成ITAD的路径到达。AP_集合提供足够的信息以避免路由循环；然而，它们的使用可能会删减潜在的可行路径，因为这样的路径不再以AP_序列的形式单独列出。实际上，这不太可能是一个问题，因为一旦呼叫到达一组ITAD的边缘，该点的LS可能具有更详细的路径信息，并且可以区分到目的地的各个路径。
Aggregation is the process of combining the characteristics of several different routes in such a way that a single route can be advertised. Aggregation can occur as part of the decision process to reduce the amount of routing information that is placed in the Adj-TRIBs-Out.
聚合是将多个不同路由的特征组合在一起的过程，从而可以发布单个路由。聚合可以作为决策过程的一部分发生，以减少Adj TRIB Out中放置的路由信息量。
Aggregation reduces the amount of information an LS must store and exchange with other LSs. Routes can be aggregated by applying the following procedure separately to attributes of like type.
聚合减少了LS必须存储并与其他LSs交换的信息量。通过将以下过程分别应用于类似类型的属性，可以聚合路由。
Routes that have the following attributes shall not be aggregated unless the corresponding attributes of each route are identical: MultiExitDisc, NextHopServer.
具有以下属性的路由不得聚合，除非每个路由的相应属性相同：MultiExitDisc、NextHopServer。
Attributes that have different type codes cannot be aggregated. Attributes of the same type code may be aggregated. The rules for aggregating each attribute MUST be provided together with attribute definition. For example, aggregation rules for TRIP's basic attributes, e.g., ReachableRoutes and AdvertisementPath, are given in Section 5.
无法聚合具有不同类型代码的属性。可以聚合相同类型代码的属性。聚合每个属性的规则必须与属性定义一起提供。例如，第5节给出了行程基本属性的聚合规则，例如可达路线和广告路径。
Generally speaking, additional rules for comparing routes among several alternatives are outside the scope of this document. There are two exceptions:
一般来说，在多个备选方案之间比较路线的附加规则不在本文件范围内。有两个例外：
- If the local ITAD appears in the AdvertisementPath of the new route being considered, then that new route cannot be viewed as better than any other route. If such a route were ever used, a routing loop could result (see Section 6.3). - In order to achieve successful distributed operation, only routes with a likelihood of stability can be chosen. Thus, an ITAD must avoid using unstable routes, and it must not make rapid spontaneous changes to its choice of route. Quantifying the terms "unstable" and "rapid" in the previous sentence will require experience, but the principle is clear.
- 如果本地ITAD出现在正在考虑的新路由的广告路径中，则该新路由不能被视为比任何其他路由更好。如果曾经使用过此类路由，则可能会产生路由环路（见第6.3节）。-为了实现成功的分布式操作，只能选择具有稳定可能性的路由。因此，ITAD必须避免使用不稳定的路由，并且不得对其路由选择进行快速自发更改。量化前一句中的“不稳定”和“快速”需要经验，但原则是明确的。
An LS may originate local routes by injecting routing information acquired by some other means (e.g. via an intra-domain routing protocol or through manual configuration or some dynamic registration mechanism/protocol) into TRIP. An LS that originates TRIP routes shall assign the degree of preference to these routes by passing them through the Decision Process (see Section 10.2). To TRIP, local routes are identical to external routes and are subjected to the same two phase route selection mechanism. A local route which is selected into the Ext-TRIB MUST be advertised to all internal LSs. The decision whether to distribute non-TRIP acquired routes within an ITAD via TRIP or not depends on the environment within the ITAD (e.g. type of intra-domain routing protocol) and should be controlled via configuration.
LS可通过将通过某些其他方式（例如通过域内路由协议或通过手动配置或某些动态注册机制/协议）获得的路由信息注入TRIP来发起本地路由。发起出行路线的LS应通过决策过程（见第10.2节）为这些路线分配优惠度。为了跳闸，本地路由与外部路由相同，并且受相同的两阶段路由选择机制的约束。必须向所有内部LSs通告选择到Ext TRIB中的本地路由。是否通过TRIP在ITAD内分配非TRIP获取的路由取决于ITAD内的环境（例如域内路由协议的类型），并应通过配置进行控制。
This specification defines the use of TCP as the transport layer for TRIP. TRIP uses TCP port 6069. Running TRIP over other transport protocols is for further study.
本规范规定使用TCP作为TRIP的传输层。TRIP使用TCP端口6069。在其他传输协议上运行TRIP有待进一步研究。
There are no restrictions on the intra-domain topology of TRIP LSs. For example, LSs in an ITAD can be configured in a full mesh, star, or any other connected topology. Similarly, there are no restrictions on the topology of TRIP ITADs. For example, the ITADs can be organized in a flat topology (mesh or ring) or in multi-level hierarchy or any other topology.
TRIP LSs的域内拓扑没有限制。例如，ITAD中的LSs可以配置为全网状、星形或任何其他连接拓扑。同样，对跳闸ITAD的拓扑结构也没有限制。例如，ITAD可以按平面拓扑（网格或环形）或多级层次结构或任何其他拓扑进行组织。
The border between two TRIP ITADs may be located either on the link between two TRIP LSs or it may coincide on a TRIP LS. In the latter case, the same TRIP LS will be member in more than one ITAD, and it appears to be an internal peer to LSs in each ITAD it is member of.
两个跳闸ITAD之间的边界可以位于两个跳闸LSs之间的链路上，也可以在跳闸LSs上重合。在后一种情况下，同一行程LS将是多个ITAD中的成员，并且似乎是其所属每个ITAD中LSs的内部对等点。
This document creates a new IANA registry for TRIP parameters. The following TRIP parameters are included in the registry:
本文档为行程参数创建一个新的IANA注册表。注册表中包括以下跳闸参数：
- TRIP Capabilities - TRIP Attributes - TRIP Address Families - TRIP Application Protocols - TRIP ITAD Numbers
- 跳闸能力-跳闸属性-跳闸地址系列-跳闸应用协议-跳闸ITAD编号
Protocol parameters are frequently initialized/reset to 0. This document reserves the value 0 of each of the above TRIP parameters in order to clearly distinguish between an unset parameter and any other registered values for that parameter.
协议参数经常初始化/重置为0。本文件保留上述每个跳闸参数的值0，以便清楚区分未设置参数和该参数的任何其他注册值。
The sub-registries for each of the above parameters are discussed in the sections below.
以下各节将讨论上述每个参数的子注册表。
Requests to add TRIP capabilities other than those defined in Section 4.2.1.1 must be submitted to iana@iana.org. Following the assigned number policies outlined in [11], Capability Codes in the range 32768-65535 are reserved for Private Use (these are the codes with the first bit of the code value equal to 1). This document reserves value 0. Capability Codes 1 and 2 have been assigned in Section 4.2.1.1. Capability Codes in the range 2-32767 are controlled by
除第4.2.1.1节中定义的跳闸能力外，增加跳闸能力的请求必须提交给iana@iana.org. 按照[11]中概述的分配编号策略，32768-65535范围内的能力代码保留供私人使用（这些代码的第一位代码值等于1）。此文档保留值0。能力代码1和2已在第4.2.1.1节中分配。2-32767范围内的能力代码由
IANA, and are allocated subject to the Specification Required (IETF RFC or equivalent) condition. The specification MUST include a description of the capability, the possible values it may take, and what constitutes a capability mismatch.
IANA，并根据所需规范（IETF RFC或同等）条件进行分配。规范必须包括对能力的描述、可能采用的值以及构成能力不匹配的因素。
This document reserves Attribute Type Codes 224-255 for Private Use (these are the codes with the first three bits of the code equal to 1). This document reserves the value 0. Attribute Type Codes 1 through 11 have already been allocated by this document. Attribute Type Codes 1 through 11 are defined in Sections 5.1 through 5.11.
本文档保留属性类型代码224-255供私人使用（这些代码的前三位等于1）。此文档保留值0。本文件已分配属性类型代码1至11。属性类型代码1至11在第5.1至5.11节中定义。
Attribute Type Codes in the range 12-223 are controlled by IANA, and require a Specification document (RFC or equivalent). The specification MUST provide all information required in Section 5.12 of this document.
12-223范围内的属性类型代码由IANA控制，需要规范文件（RFC或同等文件）。本规范必须提供本文件第5.12节要求的所有信息。
Attribute Type Code registration requests must be sent to iana@iana.org. In addition to the specification requirement, the request MUST include an indication of who has change control over the attribute and contact information (postal and email address).
属性类型代码注册请求必须发送到iana@iana.org. 除了规范要求外，请求还必须包括谁对属性和联系信息（邮政和电子邮件地址）具有变更控制权的指示。
This document reserves address family 0. Requests to add TRIP address families other than those defined in Section 5.1.1.1 ( address families 1, 2, and 3), i.e., in the range 4-32767, must be submitted to iana@iana.org. The request MUST include a brief description of the address family, its alphabet, and special processing rules and guidelines, such as guidelines for aggregation, if any. The requests are subject to Expert Review. This document reserves the address family codes 32768-65535 for vendor-specific applications.
此文档保留地址族0。除第5.1.1.1节（地址系列1、2和3）中定义的以外，添加行程地址系列的请求，即范围为4-32767，必须提交给iana@iana.org. 请求必须包括对地址族、其字母表的简要描述，以及特殊处理规则和准则，如聚合准则（如有）。这些请求须经专家审查。本文件保留供应商特定应用的地址系列代码32768-65535。
This document creates a new IANA registry for TRIP application protocols. This document reserves the application protocol code 0. Requests to add TRIP application protocols other than those defined in Section 5.1.1.1 (application protocols 1 through 4), i.e., in the range 5-32767, must be submitted to iana@iana.org. The request MUST include a brief background on the application protocol, and a description of how TRIP can be used to advertise routes for that protocol. The requests are subject to Expert Review. This document reserves the application protocol codes 32768-65535 for vendor-specific applications.
本文档为TRIP应用程序协议创建了一个新的IANA注册表。本文档保留应用程序协议代码0。除第5.1.1.1节（应用协议1至4）中定义的协议外，添加跳闸应用协议的请求，即范围为5-32767，必须提交给iana@iana.org. 请求必须包括应用协议的简要背景，以及如何使用TRIP为该协议公布路由的描述。这些请求须经专家审查。本文件保留供应商特定应用的应用协议代码32768-65535。
This document reserves the ITAD number 0. ITAD numbers in the range 1-255 are designated for Private Use. ITAD numbers in the range from 256 to (2**32)-1 are allocated by IANA on a First-Come-First-Serve basis. Requests for ITAD numbers must be submitted to iana@iana.org. The requests MUST include the following:
本文件保留ITAD编号0。范围为1-255的ITAD编号指定为私人使用。IANA按照先到先得的原则分配256至（2**32）-1范围内的ITAD编号。申请ITAD编号必须提交至iana@iana.org. 请求必须包括以下内容：
- Information about the organization that will administer the ITAD. - Contact information (postal and email address).
- 有关将管理ITAD的组织的信息。-联系信息（邮政和电子邮件地址）。
This section covers security between peer TRIP LSs when TRIP runs over TCP in an IP environment.
本节介绍在IP环境中通过TCP运行TRIP时对等TRIP LSs之间的安全性。
A security mechanism is clearly needed to prevent unauthorized entities from using the protocol defined in this document for setting up unauthorized peer sessions with other TRIP LSs or interfering with authorized peer sessions. The security mechanism for the protocol, when transported over TCP in an IP network, is IPsec [12]. IPsec uses two protocols to provide traffic security: Authentication Header (AH) [13] and Encapsulating Security Payload (ESP) [14].
显然需要一种安全机制来防止未经授权的实体使用本文件中定义的协议与其他TRIP LSs建立未经授权的对等会话或干扰授权的对等会话。当在IP网络中通过TCP传输时，协议的安全机制是IPsec[12]。IPsec使用两种协议来提供流量安全性：身份验证头（AH）[13]和封装安全负载（ESP）[14]。
The AH header affords data origin authentication, connectionless integrity and optional anti-replay protection of messages passed between the peer LSs. The ESP header provides origin authentication, connectionless integrity, anti-replay protection, and confidentiality of messages.
AH报头为对等LSs之间传递的消息提供数据源身份验证、无连接完整性和可选的防重放保护。ESP报头提供源身份验证、无连接完整性、防重放保护和消息机密性。
Implementations of the protocol defined in this document employing the ESP header SHALL comply with section 5 of [14], which defines a minimum set of algorithms for integrity checking and encryption. Similarly, implementations employing the AH header SHALL comply with section 5 of [13], which defines a minimum set of algorithms for integrity checking using manual keys.
采用ESP报头的本文件中定义的协议实施应符合[14]第5节的规定，该节规定了完整性检查和加密的最小算法集。同样，采用AH报头的实施应符合[13]第5节的规定，该节定义了使用手动键进行完整性检查的最小算法集。
Implementations SHOULD use IKE [15] to permit more robust keying options. Implementations employing IKE SHOULD support authentication with RSA signatures and RSA public key encryption.
实现应该使用IKE[15]来允许更健壮的键控选项。采用IKE的实现应该支持使用RSA签名和RSA公钥加密的身份验证。
A Security Association (SA) [12] is a simplex "connection" that affords security services to the traffic carried by it. Security services are afforded to a SA by the use of AH, or ESP, but not both. Two types of SAs are defined: transport mode and tunnel mode [12]. A transport mode SA is a security association between two hosts, and is appropriate for protecting the TRIP session between two peer LSs.
安全关联（SA）[12]是一个单一的“连接”，为其承载的流量提供安全服务。通过使用AH或ESP向SA提供安全服务，但不能同时使用两者。定义了两种类型的SA：传输模式和隧道模式[12]。传输模式SA是两台主机之间的安全关联，适用于保护两个对等LSs之间的TRIP会话。
A1. Appendix 1: TRIP FSM State Transitions and Actions
A1。附录1：跳闸FSM状态转换和动作
This Appendix discusses the transitions between states in the TRIP FSM in response to TRIP events. The following is the list of these states and events when the negotiated Hold Time value is non-zero.
本附录讨论了跳闸FSM中响应跳闸事件的状态转换。以下是协商保持时间值为非零时的这些状态和事件的列表。
TRIP States: 1 - Idle 2 - Connect 3 - Active 4 - OpenSent 5 - OpenConfirm 6 - Established
跳闸状态：1-怠速2-连接3-激活4-打开发送5-打开确认6-已建立
TRIP Events: 1 - TRIP Start 2 - TRIP Stop 3 - TRIP Transport connection open 4 - TRIP Transport connection closed 5 - TRIP Transport connection open failed 6 - TRIP Transport fatal error 7 - ConnectRetry timer expired 8 - Hold Timer expired 9 - KeepAlive timer expired 10 - Receive OPEN message 11 - Receive KEEPALIVE message 12 - Receive UPDATE messages 13 - Receive NOTIFICATION message
行程事件：1-行程开始2-行程停止3-行程运输连接打开4-行程运输连接关闭5-行程运输连接打开失败6-行程运输致命错误7-连接重试计时器过期8-保持计时器过期9-保持计时器过期10-接收打开消息11-接收保持消息12-接收更新消息13-接收通知消息
The following table describes the state transitions of the TRIP FSM and the actions triggered by these transitions.
下表描述了跳闸FSM的状态转换以及这些转换触发的动作。
Event Actions Message Sent Next State
--------------------------------------------------------------------
Idle (1)
1 Initialize resources none 2
Start ConnectRetry timer
Initiate a transport connection
others none none 1
Event Actions Message Sent Next State
--------------------------------------------------------------------
Idle (1)
1 Initialize resources none 2
Start ConnectRetry timer
Initiate a transport connection
others none none 1
Connect(2) 1 none none 2 3 Complete initialization OPEN 4 Clear ConnectRetry timer 5 Restart ConnectRetry timer none 3 7 Restart ConnectRetry timer none 2 Initiate a transport connection others Release resources none 1
连接（2）1无无无2 3完成初始化打开4清除连接重试计时器5重新启动连接重试计时器无3 7重新启动连接重试计时器无2启动传输连接其他释放资源无1
Active (3) 1 none none 3 3 Complete initialization OPEN 4 Clear ConnectRetry timer 5 Close connection 3 Restart ConnectRetry timer 7 Restart ConnectRetry timer none 2 Initiate a transport connection others Release resources none 1
活动（3）1无无无3完成初始化打开4清除连接重试计时器5关闭连接3重新启动连接重试计时器7重新启动连接重试计时器无2启动传输连接其他释放资源无1
OpenSent(4) 1 none none 4 4 Close transport connection none 3 Restart ConnectRetry timer 6 Release resources none 1 10 Process OPEN is OK KEEPALIVE 5 Process OPEN failed NOTIFICATION 1 others Close transport connection NOTIFICATION 1 Release resources
OpenSent（4）1无无4关闭传输连接无3重新启动连接重试计时器6释放资源无1 10进程打开正常保留5进程打开失败通知1其他关闭传输连接通知1释放资源
OpenConfirm (5) 1 none none 5 4 Release resources none 1 6 Release resources none 1 9 Restart KeepAlive timer KEEPALIVE 5 11 Complete initialization none 6 Restart Hold Timer 13 Close transport connection 1 Release resources others Close transport connection NOTIFICATION 1 Release resources
打开确认（5）1无无5 4释放资源无1 6释放资源无1 9重新启动保留计时器保留5 11完成初始化无6重新启动保留计时器13关闭传输连接1释放资源其他关闭传输连接通知1释放资源
Established (6)
1 none none 6
4 Release resources none 1
6 Release resources none 1
9 Restart KeepAlive timer KEEPALIVE 6
11 Restart Hold Timer none 6
12 Process UPDATE is OK UPDATE 6
Process UPDATE failed NOTIFICATION 1
13 Close transport connection 1
Release resources
others Close transport connection NOTIFICATION 1
Release resources
-----------------------------------------------------------------
Established (6)
1 none none 6
4 Release resources none 1
6 Release resources none 1
9 Restart KeepAlive timer KEEPALIVE 6
11 Restart Hold Timer none 6
12 Process UPDATE is OK UPDATE 6
Process UPDATE failed NOTIFICATION 1
13 Close transport connection 1
Release resources
others Close transport connection NOTIFICATION 1
Release resources
-----------------------------------------------------------------
The following is a condensed version of the above state transition table.
以下是上述状态转换表的精简版本。
Events| Idle | Connect | Active | OpenSent | OpenConfirm | Estab
| (1) | (2) | (3) | (4) | (5) | (6)
|----------------------------------------------------------
1 | 2 | 2 | 3 | 4 | 5 | 6
| | | | | |
2 | 1 | 1 | 1 | 1 | 1 | 1
| | | | | |
3 | 1 | 4 | 4 | 1 | 1 | 1
| | | | | |
4 | 1 | 1 | 1 | 3 | 1 | 1
| | | | | |
5 | 1 | 3 | 3 | 1 | 1 | 1
| | | | | |
6 | 1 | 1 | 1 | 1 | 1 | 1
| | | | | |
7 | 1 | 2 | 2 | 1 | 1 | 1
| | | | | |
8 | 1 | 1 | 1 | 1 | 1 | 1
| | | | | |
9 | 1 | 1 | 1 | 1 | 5 | 6
| | | | | |
10 | 1 | 1 | 1 | 1 or 5 | 1 | 1
| | | | | |
11 | 1 | 1 | 1 | 1 | 6 | 6
| | | | | |
12 | 1 | 1 | 1 | 1 | 1 | 1 or 6
| | | | | |
13 | 1 | 1 | 1 | 1 | 1 | 1
| | | | | |
--------------------------------------------------------------
Events| Idle | Connect | Active | OpenSent | OpenConfirm | Estab
| (1) | (2) | (3) | (4) | (5) | (6)
|----------------------------------------------------------
1 | 2 | 2 | 3 | 4 | 5 | 6
| | | | | |
2 | 1 | 1 | 1 | 1 | 1 | 1
| | | | | |
3 | 1 | 4 | 4 | 1 | 1 | 1
| | | | | |
4 | 1 | 1 | 1 | 3 | 1 | 1
| | | | | |
5 | 1 | 3 | 3 | 1 | 1 | 1
| | | | | |
6 | 1 | 1 | 1 | 1 | 1 | 1
| | | | | |
7 | 1 | 2 | 2 | 1 | 1 | 1
| | | | | |
8 | 1 | 1 | 1 | 1 | 1 | 1
| | | | | |
9 | 1 | 1 | 1 | 1 | 5 | 6
| | | | | |
10 | 1 | 1 | 1 | 1 or 5 | 1 | 1
| | | | | |
11 | 1 | 1 | 1 | 1 | 6 | 6
| | | | | |
12 | 1 | 1 | 1 | 1 | 1 | 1 or 6
| | | | | |
13 | 1 | 1 | 1 | 1 | 1 | 1
| | | | | |
--------------------------------------------------------------
A2. Appendix 2: Implementation Recommendations
A2。附录2：实施建议
This section presents some implementation recommendations.
本节介绍了一些实施建议。
A.2.1: Multiple Networks Per Message
A.2.1：每条消息有多个网络
The TRIP protocol allows for multiple address prefixes with the same advertisement path and next-hop server to be specified in one message. Making use of this capability is highly recommended. With one address prefix per message there is a substantial increase in overhead in the receiver. Not only does the system overhead increase due to the reception of multiple messages, but the overhead of scanning the routing table for updates to TRIP peers is incurred multiple times as well. One method of building messages containing
TRIP协议允许在一条消息中指定具有相同播发路径和下一跳服务器的多个地址前缀。强烈建议使用此功能。如果每条消息有一个地址前缀，则接收器中的开销会大幅增加。由于接收到多条消息，不仅系统开销增加，而且扫描路由表以更新到TRIP对等方的开销也会多次发生。构建包含以下内容的消息的一种方法
many address prefixes per advertisement path and next hop from a routing table that is not organized per advertisement path is to build many messages as the routing table is scanned. As each address prefix is processed, a message for the associated advertisement path and next hop is allocated, if it does not exist, and the new address prefix is added to it. If such a message exists, the new address prefix is just appended to it. If the message lacks the space to hold the new address prefix, it is transmitted, a new message is allocated, and the new address prefix is inserted into the new message. When the entire routing table has been scanned, all allocated messages are sent and their resources released. Maximum compression is achieved when all the destinations covered by the address prefixes share the same next hop server and common attributes, making it possible to send many address prefixes in one 4096-byte message.
每个播发路径有许多地址前缀，而路由表的下一个跃点（未按播发路径组织）将在扫描路由表时生成许多消息。在处理每个地址前缀时，如果关联的播发路径和下一个跃点不存在，则为其分配一条消息，并向其添加新的地址前缀。如果存在这样的消息，则只需将新地址前缀附加到该消息。如果消息缺少容纳新地址前缀的空间，则会传输该消息，分配新消息，并将新地址前缀插入新消息中。扫描完整个路由表后，将发送所有分配的邮件并释放其资源。当地址前缀覆盖的所有目的地共享相同的下一跳服务器和公共属性时，可以实现最大压缩，从而可以在一条4096字节的消息中发送多个地址前缀。
When peering with a TRIP implementation that does not compress multiple address prefixes into one message, it may be necessary to take steps to reduce the overhead from the flood of data received when a peer is acquired or a significant network topology change occurs. One method of doing this is to limit the rate of updates. This will eliminate the redundant scanning of the routing table to provide flash updates for TRIP peers. A disadvantage of this approach is that it increases the propagation latency of routing information. By choosing a minimum flash update interval that is not much greater than the time it takes to process the multiple messages, this latency should be minimized. A better method would be to read all received messages before sending updates.
当使用不会将多个地址前缀压缩到一条消息中的TRIP实现进行对等时，可能需要采取措施减少在获取对等方或发生重大网络拓扑变化时接收到的大量数据带来的开销。一种方法是限制更新的速率。这将消除对路由表的冗余扫描，为行程对等方提供闪存更新。这种方法的缺点是增加了路由信息的传播延迟。通过选择不大于处理多条消息所需时间的最小闪存更新间隔，应将此延迟降至最低。更好的方法是在发送更新之前读取所有收到的消息。
A.2.2: Processing Messages on a Stream Protocol
A.2.2：在流协议上处理消息
TRIP uses TCP as a transport mechanism. Due to the stream nature of TCP, all the data of a received message does not necessarily arrive at the same time. This can make it difficult to process the data as messages, especially on systems where it is not possible to determine how much data has been received but not yet processed.
TRIP使用TCP作为传输机制。由于TCP的流性质，接收到的消息的所有数据不一定同时到达。这会使数据作为消息处理变得困难，尤其是在无法确定已接收但尚未处理多少数据的系统上。
One method that can be used in this situation is to first try to read just the message header. For the KEEPALIVE message type, this is a complete message; for other message types, the header should first be verified, in particular the total length. If all checks are successful, the specified length, minus the size of the message header is the amount of data left to read. An implementation that would "hang" the routing information process while trying to read from a peer could set up a message buffer (4096 bytes) per peer and fill it with data as available until a complete message has been received.
在这种情况下可以使用的一种方法是首先尝试只读取消息头。对于KEEPALIVE消息类型，这是一条完整的消息；对于其他消息类型，应首先验证报头，尤其是总长度。如果所有检查都成功，则指定的长度减去消息头的大小即为剩余要读取的数据量。在尝试从对等方读取时“挂起”路由信息进程的实现可以为每个对等方设置消息缓冲区（4096字节），并在接收到完整消息之前用可用数据填充该缓冲区。
A.2.3: Reducing Route Flapping
A.2.3：减少路线摆动
To avoid excessive route flapping an LS which needs to withdraw a destination and send an update about a more specific or less specific route SHOULD combine them into the same UPDATE message.
为了避免过度的路由抖动，需要撤回目的地并发送关于更具体或不太具体的路由的更新的LS应将它们合并到同一个更新消息中。
A.2.4: TRIP Timers
A.2.4：行程计时器
TRIP employs seven timers: ConnectRetry, Hold Time, KeepAlive, MaxPurgeTime, TripDisableTime, MinITADOriginationInterval, and MinRouteAdvertisementInterval. The suggested value for the ConnectRetry timer is 120 seconds. The suggested value for the Hold Time is 90 seconds. The suggested value for the KeepAlive timer is 30 seconds. The suggested value for the MaxPurgeTime timer is 10 seconds. The suggested value for the TripDisableTime timer is 180 seconds. The suggested value for the MinITADOriginationInterval is 30 seconds. The suggested value for the MinRouteAdvertisementInterval is 30 seconds.
TRIP使用了七个计时器：连接重试、保持时间、保持有效、MaxPurgeTime、TripDisableTime、MinITADOriginationInterval和MinRouteAdvertisementInterval。ConnectRetry计时器的建议值为120秒。保持时间的建议值为90秒。KeepAlive计时器的建议值为30秒。MaxPurgeTime计时器的建议值为10秒。TripDisableTime计时器的建议值为180秒。MinITADOriginationInterval的建议值为30秒。MinRouteAdVertisementerval的建议值为30秒。
An implementation of TRIP MUST allow these timers to be configurable.
TRIP的实现必须允许配置这些计时器。
A.2.5: AP_SET Sorting
A.2.5：AP_集排序
Another useful optimization that can be done to simplify this situation is to sort the ITAD numbers found in an AP_SET. This optimization is entirely optional.
为了简化这种情况，可以进行的另一个有用的优化是对AP_集合中的ITAD编号进行排序。这种优化完全是可选的。
Acknowledgments
致谢
We wish to thank Dave Oran for his insightful comments and suggestions.
我们要感谢Dave Oran提出的见解和建议。
References
工具书类
[1] Bradner, S., "Keywords for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于指示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Rosenberg, J. and H. Schulzrinne, "A Framework for a Gateway Location Protocol", RFC 2871, June 2000.
[2] Rosenberg，J.和H.Schulzrinne，“网关位置协议框架”，RFC 28712000年6月。
[3] Rekhter, Y. and T. Li, "Border Gateway Protocol 4 (BGP-4)," RFC 1771, March 1995.
[3] Rekhter，Y.和T.Li，“边境网关协议4（BGP-4）”，RFC 1771，1995年3月。
[4] Moy, J., "Open Shortest Path First Version 2", STD 54, RFC 2328, April 1998.
[4] Moy，J.，“开放最短路径第一版2”，STD 54，RFC 23281998年4月。
[5] "Intermediate System to Intermediate System Intra-Domain Routing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)," ISO DP 10589, February 1990.
[5] “与提供无连接模式网络服务的协议一起使用的中间系统到中间系统域内路由交换协议（ISO 8473），”ISO DP 10589，1990年2月。
[6] Luciani, J., Armitage, G., Halpern, J. and N. Doraswamy, "Server Cache Synchronization Protocol (SCSP)", RFC 2334, April 1998.
[6] Luciani，J.，Armitage，G.，Halpern，J.和N.Doraswamy，“服务器缓存同步协议（SCSP）”，RFC 2334，1998年4月。
[7] International Telecommunication Union, "Packet-Based Multimedia Communication Systems," Recommendation H.323, Version 3 Telecommunication Standardization Sector of ITU, Geneva, Switzerland, November 2000.
[7] 国际电信联盟，“基于分组的多媒体通信系统”，建议H.323，ITU第3版电信标准化部门，瑞士日内瓦，2000年11月。
[8] Handley, H., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[8] Handley，H.，Schulzrinne，H.，Schooler，E.和J.Rosenberg，“SIP：会话启动协议”，RFC 25431999年3月。
[9] Braden, R., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989.
[9] Braden，R.，“互联网主机的要求——应用和支持”，STD 3，RFC 1123，1989年10月。
[10] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[10] Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 23731998年7月。
[11] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[11] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[12] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[12] Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[13] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[13] Kent，S.和R.Atkinson，“IP认证头”，RFC 2402，1998年11月。
[14] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[14] Kent，S.和R.Atkinson，“IP封装安全有效载荷（ESP）”，RFC 2406，1998年11月。
[15] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[15] Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
Intellectual Property Notice
知识产权公告
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP 11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何努力来确定任何此类权利。有关IETF在标准跟踪和标准相关文件中权利的程序信息，请参见BCP 11。可从IETF秘书处获得可供发布的权利声明副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涉及实施本标准所需技术的专有权利。请将信息发送给IETF执行董事。
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.
IETF已收到关于本文件所含部分或全部规范的知识产权声明。有关更多信息，请查阅在线权利主张列表。
Authors' Addresses
作者地址
Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936
Jonathan Rosenberg dynamicsoft 72 Eagle Rock大道一楼东汉诺威，NJ 07936
Phone: 973-952-5000 EMail: jdrosen@dynamicsoft.com
电话：973-952-5000电子邮件：jdrosen@dynamicsoft.com
Hussein F. Salama Cisco Systems 170 W. Tasman Drive San Jose, CA 95134
美国加利福尼亚州圣何塞塔斯曼大道西170号，邮编95134
Phone: 408-527-7147 EMail: hsalama@cisco.com
电话：408-527-7147电子邮件：hsalama@cisco.com
Matt Squire Hatteras Networks 639 Davis Drive Suite 200 Durham, NC 27713
马特·斯奎尔·哈特拉斯网络公司，地址：北卡罗来纳州达勒姆市戴维斯大道200号639室，邮编：27713
EMail: mattsquire@acm.org
EMail: mattsquire@acm.org
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。