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)
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は、電話管理ドメイン間の電話ルーティング情報を配布するために使用されます。 2つのプロトコル間の類似性は明白であるので、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
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
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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].
オーバーIPテレフォニールーティングのためのフレームワーク（TRIP）を[2]に記載されています。我々は、読者がフレームワークと[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）：TRIPへの参加の結果としてLSに構築され、維持到達電話先のデータベース。
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.
以下/より特定の経路：経路XがY内のすべての宛先はまた、Xの宛先であり、そしてXおよびYが等しくない場合、ルート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.
集合：集合は、複数のルートが目的地の同じセットをカバーする単一の少ない特定のルートに結合されるプロセスです。凝集はエクスポートTRIPルートの数を減らすことによって、ピアのLSに同期し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.
ピア：論理的な関連付け（トランスポート接続）を共有する2つのLS。 LSは同じITADである場合、それらは内部ピアです。そうでなければ、彼らは外部ピアです。 2つのピアのLSとの間の論理的関連付けは、ピアリング・セッションと呼ばれます。
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先：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テレフォニーでは、より困難な問題の一つと考えられています。電話コールの出口ゲートウェイの選択は、PSTNにおける最終的な宛先に向けてIPネットワークを横断する、経路に沿った様々な関係者の政策によって、これらの当事者間で確立された関係によって大部分駆動されます。そのため、ユーザーが送信先の電話番号を検索する出口ゲートウェイのグローバルディレクトリが実行可能な解決策ではありません。むしろ、出口ゲートウェイの可用性に関する情報をプロバイダ間で交換され、ポリシーが適用され、局所的に利用可能にした後、このようにして、これらの出口のゲートウェイに向けてルートを作成し、他のITADsに他のプロバイダに伝播。これは、各プロバイダが到達可能な電話番号および関連経路の独自のデータベースを作成することを可能にする - そのようなデータベースは、ポリシーに応じて、各プロバイダのための非常に異なる可能性があります。
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）と呼ばれるTRIPスピーカの主な機能は、他のLSと情報を交換することです。この情報は、電話先、これらの目的地へのルート、およびPSTNに存在するそれらの電話の目的地へのゲートウェイに関する情報の到達可能性を含んでいます。 TRIP要件は、[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属性セットはので、追加の属性は将来の文書で定義されるかもしれ、拡張可能です。
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（Open Shortest Path First）のプロトコルは、[4]、IS-IS [5]のように、いくつかのリンク状態機能が強化され、サーバーの後にモデル化されていますキャッシュ同期プロトコル（SCSP）[6]。 TRIPは、BGPのドメイン間搬送機構、BGPのピア通信、BGPの有限状態マシン、および同様のフォーマットを使用し、BGPなどの属性。 BGPとは異なりしかし、TRIPは、構成が簡素化され、内部BGPスピーカのBGPのフルメッシュの要件とは対照的に、スケーラビリティを向上させる一般的なドメイン内のLSトポロジを可能にします。 TRIP [4]は、IS-IS、OSPFに使用されるものと同様のドメイン内フラッディングメカニズムを使用し[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 [8] [7]とSIP、例えば、これらのプロトコルのいずれかのためのルーティングプロトコルとして使用することができます。
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の境界とは無関係です。内部も外部もないTRIPピアは、物理的に隣接する必要があります。
This section summarizes the operation of TRIP. Details are provided in later sections.
このセクションでは、TRIPの動作をまとめました。詳細については、後のセクションで提供されています。
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.
2つのピアのLSは、互いの間トランスポートプロトコル接続を形成します。彼らは開いて、接続パラメータを確認し、各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.
キープアライブメッセージは、隣接ピアが動作していることを確認するために定期的に送信されます。通知メッセージは、エラーや特殊な状態に応答して送信されます。接続がエラー状態が発生した場合、通知メッセージが送信され、接続が閉じられます。
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の調整] - TRIBアウト内のすべてのルートに関連するすべてのルートのダンプです。場合内部ピアの、EXT-TRIB及び全てのAdj-TRIBsイン）内のすべてのルート。異なるTRIBsは、3.5節で定義されていることに注意してください。
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.
増分更新は、TRIPルーティングテーブル（TRIBs）変化として送信されます。 TRIPは、ルートの定期的な更新を必要としません。したがって、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は、複数のLSを有し、他のITADsの中継サービスを提供している場合、注意がITAD内ルーティングの一貫したビューを保証するために注意しなければなりません。すべての内部ピアのTRIPルーティングテーブル、即ち、のLoc-TRIBsを同期するときに同一です。
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.
内部同期を達成するために、内部ピア接続が得られたドメイン内LSトポロジが接続され、十分に冗長であるように、同じITADののLSとの間に構成されています。これは、問題のスケーリングをもたらすことができるフルメッシュトポロジで接続されるすべての内部ピアを、必要と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.
TRIPルートはUPDATEメッセージ中のLSの対の間にアドバタイズされます。他の属性は、パスまたは出口ゲートウェイのようなものを記述しながら、宛先アドレスは、UPDATEの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のルートをアドバタイズすることを選択した場合、それは追加またはピアにそれを広告する前に、ルートの属性を変更することがあります。 TRIPは、LSは、以前にアドバタイズルートがもはや使用可能であるピアに知らせることができるメカニズムを提供します。与えられたLSは、ルートのサービスが撤回されたことを示すことが可能な3つの方法があります。
- 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.
- WithdrawnRoutesは、このように、もはや使用可能であるとして関連付けられた目的地をマーク、UPDATEメッセージ内の属性にルートを含めます。 - ReachableRoutes属性で目的地の同じセットとの交換ルートをアドバタイズします。 - フラッディングが使用されていない外部ピアに対して、LS-に-LSピア接続を暗黙的にサービスからのLSの対がそのピアセッションを介して相互にアドバタイズしたすべてのルートが削除され、閉じることができます。同一のルートがあるため、フラッディングの複数の内部ピアから受信されていてもよいように、内部ピアリング・セッションを終了しても、必ずしもピアLSによってアドバタイズされたルートを削除しないことに留意されたいです。 LSは、別の内部LSと判断した場合（他の内部ピアからのUPDATEメッセージのITADトポロジ属性から）もはやアクティブで、それは、そのLSによりLSに発信し、その決定プロセスを再実行するすべてのルートを削除してはなりません。
A TRIP LS processes three types of routes:
TRIP LSは、ルートの3種類を処理します。
- 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）は、4つの別個の部分からなります：
- 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.
- 調整] - TRIBsイン：調整]-TRIBsインストアルーティング情報インバウンドUPDATEメッセージから学習されました。その内容は、決定プロセスへの入力として利用可能であるTRIPルートを表します。これらは、受信した「未処理」ルートです。一方のピアからの更新が別のLSから受信したルートに影響を及ぼさないように、各外部ピアLS及び各内部LSからのルートは、独立して、このデータベース内に維持されます。 LSは直接ピア接続されていないものも含めするドメイン内のすべてのLS用の調整] - TRIBインがあることに注意してください。 - EXT-TRIB：LSごとに1つだけのExt-TRIBデータベースがあります。 LSは、すべての（外部ピアの調整] - TRIBsインに格納されている）外部ルートとローカルルート上の経路選択アルゴリズムを実行する（ADJ-TRIBインローカルLSを表すに格納されてもよい）とするための最良の経路を選択します所定の宛先とEXT-TRIBに格納します。 EXT-TRIBの使用は、セクション10.3.1でさらに説明される - のLoc-TRIB：のLoc-TRIBはLSは、その調整] - TRIBsに含まれるルーティング情報にローカルポリシーを適用することによって、選択したルーティング情報をローカルTRIPが含ま内部のLSとEXT-TRIBの-In。 - 調整] - TRIBsアウト：調整] - TRIBsアウトストアローカルLSは、その外部ピアに広告するために選択した情報。調整] - TRIBsアウトに格納されているルーティング情報は、ローカルLSのUPDATEメッセージで運ばれ、そのピアにアドバタイズされます。
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)
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-TRIBs-において、EXT-TRIB、のLoc-TRIBとのAdj-TRIBsアウト区別しているが、これが意味することも、実装は、ルーティング情報の4つの別々のコピーを維持しなければならないことを要求どちら。実装の選択は、（例えば、ポインタを持つ情報対1コピーの4コピー）のプロトコルによって拘束されません。
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.
TRIPルートは、（5.1.1にある経路の正確な定義および構文）これらの数字の接頭辞であることにより、数値の範囲を指定します。数字の任意の範囲がTRIP内経路によってアトミックに表現できません。プレフィックス範囲はアトミックにサポートされている範囲の唯一のタイプです。任意の範囲がReachableRoutes属性に複数のプレフィックスを使用することによって達成することができる（セクション5.1および5.2を参照）。例えば、999-xxxxはプレフィックス222、223、224、...、23,24、...、3,4を含むことによって表すことができる222-XXXXスルー、...、ReachableRoutes 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によって使用されるスケーリング拡張です。経路R内のすべての有効な宛先はまた、{R1に有効な宛先であるより少ない特定のルートRが存在するように、そのTRIBに{R1、R2、...}のセットが存在する場合、凝集は、LSによって実行することができますR2、...}及びその逆。セクション5はRの属性に{R1、R2、...}の経路上（タイプによって）各属性を結合する方法の説明が含まれ
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内の機構がないことに注意してください。 LSは、集計時に無視される無効な接頭語を学習するために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は、単一の集約経路へのルートのセットを集約するかどうか、ローカルポリシーに基づいて決定します。
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は、任意の経路のNextHopServerをリセットし、このため、凝集または他の理由で実行されてもよい場合は、これらの宛先へのシグナリングパスに沿って別のシグナリング・サーバを追加する効果を有します。最終結果は、2つの宛先間のシグナリングパスが複数のドメインにわたる複数のシグナリングサーバから構成されてもよいということです。
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つのオクテットなしTRIPヘッダから成ります。
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 |
+--------------+----------------+---------------+
Figure 2: TRIP Header
図2：TRIPヘッダー
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オクテットの符号なし整数をオクテット単位で、ヘッダを含むメッセージの全長を示します。したがって、それは1つが、トランスポートレベルのストリームに、次のメッセージの始まりを突き止めることを可能にします。 Lengthフィールドの値は常に4096よりも少なくとも3と大きくないなければならず、さらにメッセージのタイプに応じて拘束されてもよいです。 Lengthフィールドは、最小値の可能なメッセージの残りの部分を与えられている必要がありますので、メッセージの後に余分なデータのパディングは、許可されていません。
Type: This 1-octet unsigned integer indicates the type code of the message. The following type codes are defined:
タイプ：この1オクテットの符号なし整数は、メッセージのタイプコードを示します。以下のタイプコードが定義されています。
1 - OPEN 2 - UPDATE 3 - NOTIFICATION 4 - KEEPALIVE
1 - OPEN 2 - UPDATE 3 - NOTIFICATION 4 - KEEPALIVE
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.
トランスポートプロトコル接続が確立された後、それぞれの側によって送信された最初のメッセージはオープンメッセージです。 OPENメッセージが許容される場合は、OPENを確認するKEEPALIVEメッセージが返送されます。 OPENが確認されると、UPDATE、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.
OPENメッセージの最小の長さは、（メッセージヘッダーを含む）17オクテットです。セクション6.2で定義された、この最小要件を満たしていないOPENメッセージが処理されます。
In addition to the fixed-size TRIP header, the OPEN message contains the following fields:
固定サイズのTRIPヘッダに加えて、OPENメッセージは、次のフィールドが含まれています。
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：TRIP OPENヘッダー
Version: This 1-octet unsigned integer indicates the protocol version of the message. The current TRIP version number is 1.
バージョン：この1オクテットの符号なし整数メッセージのプロトコルバージョンを示しています。現在TRIPのバージョン番号は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オクテットの符号なし整数は、送信者がホールドタイマーの値を提案している秒数を示します。 OPENメッセージを受信すると、LSは、その構成ホールド時間の小さく、OPENメッセージで受信されたホールド時間を使用して、ホールドタイマーの値を計算しなければなりません。ホールド時間がゼロまたは少なくとも3秒のいずれかでなければなりません。実装は、ホールド時間に基づいて接続を拒否するかもしれません。算出された値は、送信者によって連続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オクテットの符号なし整数は、送信者のITAD番号を示します。 ITAD番号のLSの協力のこの連合内でのこのドメインに対して一意でなければなりません。
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.
1から255までこの文書の埋蔵ITAD番号0 ITAD番号は私的使用のために指定されている。セクション13で指定されているようITAD番号は、IANAによって割り当てられます。
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.
TRIP識別子：4オクテットの符号なし整数は、送信者のTRIP識別子を示します。 TRIP識別子は、これがそのITAD内LS識別しなければなりません。所与LSは、LSに割り当てられたIPv4アドレスへのTRIP識別子の値を設定してもよいです。 TRIP識別子の値は、起動時に決定され、すべてのピア接続で同じでなければなりません。 2つのTRIP識別子を比較すると、TRIP識別子は、数値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)...
+---------------+---------------+--------------+----------------+
Figure 4: Optional Parameter Encoding
図4：オプションのパラメータのエンコーディング
Parameter Type: This is a 2-octet field that unambiguously identifies individual parameters.
パラメータタイプ：これは明確に個々のパラメータを特定する2オクテットのフィールドです。
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.
この文書では、OPENメッセージのために、次のオプションパラメータを定義します。
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.
Capability情報は、これはそのピアにLSでサポートされている機能のリストを伝えるためにLSが使用するオプションのパラメータですオプションのパラメータタイプ1を使用しています。これは、そのピアのLSの能力を知るためにLSを可能にします。能力交渉は、第8節で定義されています。
The parameter contains one or more triples <Capability Code, Capability Length, Capability Value>, where each triple is encoded as shown below:
パラメーターは、一つ以上のトリプル以下に示すように、各トリプルが符号化された<機能コード、機能長、能力値>を、含まれています。
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オクテットのフィールドです。
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 |
+---------------+---------------+--------------+----------------+
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項で定義した通りです。アドレスファミリは、（ReachableRoutes属性内）ルーティングされるアドレスファミリを提供します。アプリケーションプロトコルはルートが適用されるアプリケーションを示しています。一例として、TRIPのルートタイプは、SIPプロトコルのE.164先のセットを表す、<E.164、SIP>とすることができます。
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は、この特定のピアで動作するモードを指定します。可能なモードは以下のとおりです。受信専用モード、Onlyモードの送信、または受信モード送信します。デフォルトのモードは受信モード送信です。
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は、そのピアにUPDATEメッセージを送信しますが、ピアがそのLSにUPDATEメッセージを送信してはなりません。送信中のLSのみのモードがピアからのUPDATEメッセージを受信した場合、そのメッセージを捨てなければなりませんが、それ以上のアクションがとられるべきではありません。
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によって送信されたUPDATEメッセージは、いつでも、トポロジの変更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.
サービスプロバイダは、それが所有しているゲートウェイのセットへの通話を終了しますが、通話を開始したことがない場合、それはそれらを受信しない、彼らは唯一のこれまでのUPDATEメッセージを生成する必要があるため、専用モードの送信で動作させるためにそののLSを設定することができます。送信中にLSモードを受信した場合LSは、そのピアに任意のUPDATEメッセージを送信しないように、そのルートの普及ポリシーを設定しなければならないことを、送信専用モードでのピアとのピアリングセッションを持っています。
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はパッシブTRIPリスナーとして機能します。これは、受信して、そのピアからのUPDATEメッセージを処理し、それはそのピアに任意のUPDATEメッセージを送信してはなりません。これは、表示のためのトポロジー情報を収集したい管理ステーションに便利です。
The behavior of an LS in Send Receive mode is the default TRIP operation specified throughout this document.
送信中にLSの動作モードは本書で指定されたデフォルトのTRIP操作で受信します。
The Send Receive capability is a 4-octet unsigned numeric value. It can only take one of the following three values:
送信、受信機能は、4オクテット符号なしの数値です。それだけで、次の3つの値のいずれかを取ることができます。
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."
両者が専用モードで送信されているか、それらの両方の場合は専用モードで受信している場合ピアリングセッションが2つのLSの間で確立されてはなりません。 OPENメッセージを処理するときに、ピア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.
UPDATEメッセージは、のLSとの間でルーティング情報を転送するために使用されます。更新パケット内の情報は、様々なITADs間の関係を説明するグラフを構築することができます。議論されるようにルールを適用することによって、ルーティング情報には、ループやその他の異常を防止することができます。
An UPDATE message is used to both advertise and withdraw routes from service. An UPDATE message may simultaneously advertise and withdraw TRIP routes.
UPDATEメッセージは、宣伝やサービスからのルートを引き出すの両方に使用されています。 UPDATEメッセージが同時にTRIPルートをアドバタイズし、撤回することができます。
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 | ...
+------------------------------------------------+--...
Figure 7: TRIP UPDATE Format
図7：TRIPのUPDATEフォーマット
The minimum length of an UPDATE message is 3 octets (there are no mandatory attributes in TRIP).
UPDATEメッセージの最小の長さは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.
ルーティング属性の可変長配列は、すべてのUPDATEメッセージ中に存在しています。各属性は可変長の三重<属性タイプ、属性長さ、属性値>です。
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.
属性タイプは、属性タイプコードオクテットに続く属性フラグオクテットで構成されて2オクテットフィールドです。
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.
属性タイプコードは、属性のタイプを定義します。基本的なTRIP定義の属性タイプコードは、このセクションで後述します。属性は属性タイプコードの番号順にUPDATEメッセージに表示される必要があります。属性には、複数回同じUPDATEメッセージよりも含んではいけません。属性フラグは、属性タイプが不明な場合、属性処理を制御するために使用されています。属性フラグは、さらに、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に等しいコードの最初の3ビットを有するコードである）属性タイプ。 （ベンダー固有の使用のために予約以外）この文書準備値0属性タイプコードはIANAによって制御されます。 IANAの考慮事項については、セクション13を参照してください。
The third and the fourth octets of the route attribute contain the length of the attribute value field in octets.
経路の第三及び第四オクテットがオクテットの属性値フィールドの長さを含む属性。
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の属性のセットが時間をかけて進化していくことは明らかです。したがって、メカニズムが認識されていない種類の属性を処理するために提供されることが不可欠です。認識されていない属性の取り扱いは、属性のフラグフィールドを介して制御されます。認識された属性は、その具体的な定義に従って処理されるべきです。
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
以下は、この仕様で定義された属性フラグです：ビットフラグフラグ1推移旗2依存旗3部分的な旗4リンクステートカプセル化フラッグよく知られている0
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）がよく知られているビットです。これは、（0に設定されている場合）、属性（1に設定されている場合）は、周知のまたはよく知られていないかどうかを定義します。実装は、よく知られていない属性をサポートする必要はありませんが、よく知られている属性をサポートしなければなりません。
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）は推移ビットです。これは、（0に設定されている場合）がよく知られている属性が推移（1に設定されている場合）、または非推移的であるかどうかを定義します。よく知られている属性の場合、推移ビットが送信にゼロでなければならない、領収書の上で無視しなければなりません。
The third high-order bit (bit 2) of the Attribute Flags octet is the Dependent bit. It defines whether a transitive attribute is 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.
属性フラグオクテットの第三の上位ビット（ビット2）は、従属ビットです。これは、（0に設定されている場合）（1に設定されている場合）、または独立推移属性が依存しているかどうかを定義します。よく知られている属性の非推移属性に依存ビットは無関係であり、送信時にゼロに設定しなければならなくて、領収書の上で無視しなければなりません。
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）は、部分ビットです。これはよく知られていない推移属性に含まれる情報は、（0に設定されている場合）の部分（1に設定されている場合）、または完了しているかどうかを定義します。よく知られている属性については非推移属性の部分ビットは、送信時に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）は、リンクステートカプセル化ビットです。このビットは、特定の属性（ReachableRoutesとWithdrawnRoutes）にのみ適用可能であり、それらの属性内のルートのカプセル化を決定します。このビットがセットされている場合は、リンクステートのカプセル化は、属性内で使用されます。それ以外の場合は、標準のカプセル化は、属性内で使用されます。リンクステートカプセル化技術は、セクション4.3.2.4に記載されています。このフラグはReachableRoutesとWithdrawnRoutes属性にのみ有効です。これは、送信時にクリアされなければならないし、他のすべての属性のための領収書で無視しなければなりません。
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起因経路を伝搬する際の中間のLSはNextHopServerを変更する必要がないという事実のために推移の2つのバリエーションを提供します。属性は非推移、依存推移、または独立した推移かもしれません。属性には、依存推移し、独立した推移の両方にすることはできません。
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は、ネクストホップサーバを変更されていない場合は認識されない依存推移属性にのみ増殖させることができます。推移変動は、いくつかの隣接するネクストホップサーバ（依存推移）との間に運ばれ、そしてもう一方はのLSを（非推移）ピアに限定される、いくつかの認識されていない属性は、エンドツーエンドの（独立の推移）を実施することを可能にします。
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は、ルートに新しい依存推移属性を挿入した場合、それはその属性に部分的なフラグを設定しなければなりません。部分的なフラグは、関連するパスに沿っていないすべての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項で説明したように通常の属性は、単純な形式を持っています。リンクステートカプセル化フラグがセットされている場合は、図9に示すように、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
+---------------+---------------+--------------+----------------+
| 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及びシーケンス番号は、サーバのコレクション内のルーティングアップデートの洪水を制御するために使用されています。これらのフィールドは、それらがさらに他のLSに伝播されないように、重複し、古いルートを検出するために使用されています。これらのフィールドの使用は、セクション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には必須の属性はありません。ただし、条件付き必須属性があります。条件付き必須の属性が別の属性は、そのメッセージに含まれている場合、UPDATEメッセージに含まれなければならない属性です。 UPDATEメッセージは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中3つのベースの属性はWithdrawnRoutes、ReachableRoutes、及びITADトポロジーです。 UPDATEメッセージにおけるそれらの存在は完全にオプションと他の属性とは無関係です。
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.
このセクションでは、UPDATEメッセージの中で行うことができる属性をまとめたものです。属性は属性タイプコードの昇順でUPDATEメッセージに表示される必要があります。更なる詳細は、第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の調整] - TRIBsインに挿入する可能性を有し、経路選択プロセスは、それらに適用されます。
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アドレスのいずれかのように次のホップサーバーのIDを指定します。それは、必要に応じて、次のホップのシグナリング・サーバのUDP / TCPポート番号を指定するかもしれません。指定しない場合、デフォルトのポートを使用する必要があります。 NextHopServerはReachableRoutes属性で定義された宛先とアプリケーションプロトコルのセットに固有のものです。 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.
AdvertisementPath [3] BGP4にAS_PATHに類似しています。属性は、この広告が通過したドメインの配列を記録します。属性は、ルーティング広告がループしているときを検出するために使用されます。この属性は、このルートを次のメッセージが通過することになる通るパスを反映するものではありません。次のホップは、それぞれ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属性に似ています。 NextHopServer属性の変更をする際の経路を伝播されるたびに変更されAdvertisementPathとは異なり、RoutedPathのみが変更されます。従って、トラバースなるこの特定のルート以下のシグナリングメッセージAdvertisementPathのサブセットを記録します。
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.
他のLSにそれを通知するときにAtomicAggregate属性を持つルートを受けたLSは、目的地のセットは、より具体的なてはなりません。
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属性が与えられたルートに対するローカルLSの好みの他のLSを通知するために使用したドメイン内の属性です。ルートの嗜好は、ドメインへの入口で計算し、ドメイン全体にその経路を持つ属性として渡されます。同じITAD内の他のLSは、その経路選択プロセスでは、この属性を使用します。この属性は、ドメイン間の意味はありません。
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があるかもしれません。 MultiExitDisc属性は、ドメイン間の別のリンクを介してドメイン間の1つのリンクのための好みを表現するためにLSによって使用されます。 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.
コミュニティ属性は、よく知られている属性ではありません。コミュニティ内の宛先をグループ化することによって、ルーティング情報の制御を容易にし、単純化するために使用されます。
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トポロジー属性は、ドメイン内の他のLSへのドメイン内のトポロジを示すためのLSが使用しているドメイン内の属性です。
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は、ピアが到達可能であるかどうかを判断するために、任意のトランスポートベースのキープアライブメカニズムを使用していません。代わりに、キープアライブメッセージは、ホールドタイマーが期限切れに生じないよう十分な頻度でピア間で交換されています。キープアライブメッセージの間の合理的な最大時間はホールド時間間隔の三分の一になります。キープアライブメッセージは、3秒に1回以上送ってはいけません。実装は、それが交渉保持時間間隔の関数として、キープアライブメッセージを送信する速度を調整する必要があります。
If the negotiated Hold Time interval is zero, then periodic KEEPALIVE messages MUST NOT be sent.
ネゴシエートされた保留時間間隔がゼロであれば、定期的にキープアライブメッセージを送ってはいけません。
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.
エラー状態が検出されたときに通知メッセージが送信されます。 TRIPのトランスポート接続は、通知メッセージを送信した直後に閉じられています。
In addition to the fixed-size TRIP header, the NOTIFICATION message contains the following fields:
固定サイズのTRIPヘッダに加えて、通知メッセージは、次のフィールドが含まれています。
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：TRIP通知フォーマット
Error Code: This 1-octet unsigned integer indicates the type of NOTIFICATION. The following Error Codes have been defined:
エラーコード：この1オクテットの符号なし整数は、通知の種類を示します。以下のエラーコードが定義されています。
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 OPENメッセージのエラー6.2節3 UPDATEメッセージエラー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オクテットの符号なし整数は、報告されたエラーの性質についてのより具体的な情報を提供します。各エラーコードは、それに関連する1つのまたは複数のエラーサブコードを有することができます。いかなる適切なエラーサブコードが定義されていない場合、ゼロ（非特異的）値は、エラーサブコードフィールドに使用されます。
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.
OPENメッセージエラーサブコード：1 - サポートされていないバージョン番号。 2 - バートピアITAD。 3 - バートTRIP識別子。 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.
UPDATEメッセージエラーサブコード：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.
このセクションでは、各TRIPのUPDATE属性の構文とセマンティクスの詳細を提供します。
Conditional Mandatory: False. Required Flags: Well-known. Potential Flags: Link-State Encapsulation (when flooding). TRIP Type Code: 1
必須条件：偽。必要なフラグ：よく知られています。潜在的なフラグ：リンクステートカプセル化（フラッディング）。 TRIPタイプコード：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.
WithdrawnRoutesは、受信LS（S）でサービスから削除されるべきルートのセットを指定します。ルートのセットは、ゼロの長さフィールドによって示され、空であってもよいです。
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.
WithdrawnRoutes属性は、その値フィールドの経路の配列をコードします。個々のルートの形式はセクション5.1.1.1に記載されています。属性内の個々の経路を描写することができるように、各ルートの長さフィールドを含む図11に示すようにWithdrawnRoutes項目なしパディングで順次個々のルートを示しています。
+---------------------+---------------------+...
| WithdrawnRoute1... | WithdrawnRoute2... |...
+---------------------+---------------------+...
Figure 11: WithdrawnRoutes Format
図11：WithdrawnRoutesフォーマット
The generic format for a TRIP route is given in Figure 12.
TRIP経路のための一般的なフォーマットは図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) ...
+---------------+---------------+--------------+----------------+
Figure 12: Generic TRIP Route Format
図12：一般的なTRIPルートフォーマット
Address Family: The address family field gives the type of address for the route. Three address families are defined in this Section:
家族アドレス：アドレスファミリフィールドルートのアドレスの種類を提供します。 3つのアドレスファミリーは、この節で定義されています。
Code Address Family
1 Decimal Routing Numbers
2 PentaDecimal Routing Numbers
3 E.164 Numbers
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この文書準備家族コードベンダー固有のアプリケーション（これらは1に等しい符号値の最初のビットを有するコードである）のための32768から65535をアドレス。追加のアドレスファミリは、将来的に定義されてもよいです。アドレスファミリコードの割り当ては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
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"
小数ルーティング番号= *小数桁の10進ディジット= DECIMAL桁の10進桁= "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 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.
このDECIMALルーティング番号のプレフィックスは、長さにバインドされていません。 SIPで定義されたように、このフォーマットは、[8]の視覚セパレータなしおよび国際番号の「+」プレフィックスなしでグローバル電話番号のフォーマットと同様です。電話番号の文字ベースの表現を使用して両方とも、ルートSIPまたはH323への旅行を使用する場合、この形式は、効率的な比較を容易にします。プレフィックス長は、経路の長さフィールドから決定されます。小数ルーティング番号（プライベート地方、国、または国際）のタイプは、プレフィックスの最初の数桁から推定することができます。
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"
十五進法ルーティング番号= *十五進法桁の十五進法ルーティング桁=十五進法桁の十五進法桁=「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.
特定の国/地域のルーティング番号に合ったアドレスファミリは、その国/地域でのルーティング番号に使用アルファベットに依存することに注意してください。彼らのアルファベットが「9」の数字「0」に限定されているので、例えば、北アメリカのルーティング番号は、小数点ルーティング番号アドレスファミリを使用すべきです。番号をルーティングほとんどのヨーロッパ諸国でのもう一つの例は、「E」から「9」と「A」を通じてアルファベット「0」を使用し、従って、これらの国は十五進法のルーティング番号のアドレスファミリを使用すべきです。
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番号= * E164桁E164桁= 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.
電話番号の文字ベースの表現を使用して両方とも、ルート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番号のアドレスファミリは、可能な限り使用されるべきです。小数点ルーティング番号アドレスファミリは、完全に拡張し、完全修飾された電話番号を宣伝することを望んでいないプライベート番号計画や用途の場合に使用することができます。小数点ルーティング番号は非完全修飾プレフィックスを広告するために使用される場合、プレフィックスはITADsの境界で（例えば、拡大）操作しなければならないかもしれません。それはピアITADで使用されるフォーマットに独自のITADで使用されるフォーマットから接頭辞をマップする必要があり、これは、ITADボーダーLSに重要な複雑さを追加します。
Conditional Mandatory: False. Required Flags: Well-known. Potential Flags: Link-State Encapsulation (when flooding). TRIP Type Code: 2
必須条件：偽。必要なフラグ：よく知られています。潜在的なフラグ：リンクステートカプセル化（フラッディング）。 TRIPタイプコード：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（S）でサービスに追加されるルートのセットを指定する属性。ゼロ長さフィールドを設定することによって示されるように、ルートのセットは、空であってもよいです。
The ReachableRoutes Attribute has the same syntax as the WithdrawnRoutes Attribute. See Section 5.1.1.
ReachableRoutes属性はWithdrawnRoutes属性と同じ構文を持っています。 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.
ReachableRoutes内のルートは、ルート選択のために必要です。
To aggregate multiple routes, the set of ReachableRoutes to be aggregated MUST combine to form a less specific set.
複数の経路を集約するために、集約するReachableRoutesのセットは、以下の特定のセットを形成するように結合しなければなりません。
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.
これらのアドレスは、集計中にスキップすることができることをこのように特定のアドレスプレフィックスが使用されていないことを伝え、旅行中のメカニズムはありません。 LSは、集計時に無視される無効な接頭語を学習するために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.
ReachableRoutesフラッディング（例えば、ドメイン内で）使用されている場合を除き、各LSに再計算された属性。 LSは、外部ピアにそのルートを広告する前に、ルートのアプリケーションプロトコルフィールドを変更することがことが可能です。
If an LS changes the Application Protocol of a route it advertises, it MUST include the ConvertedRoute attribute in the UPDATE message.
LSは、それがアドバタイズルートのアプリケーションプロトコルを変更する場合は、UPDATEメッセージに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に存在しない複数の特定のプレフィックスがあっても、ReachableRoutesように、そのプレフィックスを通知すべきです。一般に、長さn-1のプレフィックスに集約する長さnの、10進数ルーティング/ E.164プレフィックス、又は15十五進法ルーティングプレフィックスをとります。 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.
条件付き必須：真（ReachableRoutesおよび/またはWithdrawnRoutesが存在している属性場合）。必要なフラグ：よく知られています。潜在的なフラグ：なし。 TRIPタイプコード：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.
NextHopServerための構文は、図13に示されています。
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は、ネクストホップのドメインを示します。 Lengthフィールドは、Serverフィールドにオクテットの数を与え、およびサーバーフィールドは、ネクストホップサーバの名前またはアドレスが含まれています。サーバーフィールドは、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
サーバ=ホスト[「：」ポート]ホスト= <法的インターネットホストのドメイン名またはRFC 1123のセクション2.1で定義されたテキスト表現を使用して、IPv4アドレス[9]又はRFCのセクション2.2で定義されたテキスト表現を使用してIPv6アドレス2373 [10]。 IPv6アドレスは、「[」と「]」の文字で囲む必要があります。>ポート= * DIGIT
If the port is empty or not given, the default port is assumed (e.g., port 5060 if the application protocol is SIP).
ポートが指定された空であるかどうか、デフォルトのポート（例えば、ポート5060アプリケーションプロトコルがSIPである場合）を想定します。
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を含まなければなりません。 NextHopServerは出口ゲートウェイまたはシグナリングプロキシのアドレスであってもよいです。
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は、新しいNextHopServerとしてそのドメイン内から新しいシグナリングサーバを挿入する必要があります。
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は、新しいネクストホップとしてそのドメイン内シグナリングプロキシを挿入することを選択することができる、又はそれは不変のネクストホップを残すことができます。新しいネクストホップを挿入するシグナリングメッセージがそのアドレスに送信されます、とシグナリングパスをより細かく制御を提供します。不変のネクストホップを残すことは、より効率的なシグナリングパス（より少ないホップ数）をもたらします。 NextHopServerを伝播または変更するかどうかを決定するためにLSの局所的な政策決定です。
Conditional Mandatory: True (if ReachableRoutes and/or WithdrawnRoutes attribute is present). Required Flags: Well-known. Potential Flags: None. TRIP Type Code: 4.
条件付き必須：真（ReachableRoutesおよび/またはWithdrawnRoutesが存在している属性場合）。必要なフラグ：よく知られています。潜在的なフラグ：なし。 TRIPタイプコード：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.
この属性は、広告で運ばれたルーティング情報が通過したITADsを識別します。 AdvertisementPath属性は、BGPでAS_PATH属性に似ています。属性は、BGPのAS_PATHは、宛先へのパスを反映しているという点で異なります。 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オクテット長のフィールドです。
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_SET：広告メッセージ内の経路は2 AP_SEQUENCEを横断したITADsの順序付けられていないセットは：ITADsの順序集合広告メッセージ内の経路が横断しました
The path segment length is a 1-octet long field containing the number of ITADs in the path segment value field.
経路セグメントの長さは経路セグメント値フィールドのITADsの数を含む1オクテット長フィールドです。
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は、隣接ITADsにあるのLSに送信されたすべての広告のAdvertisementPath属性に独自のITAD番号を含まなければなりません。この場合、元のLSのITADのITAD数はAdvertisementPath属性で唯一のエントリになります。 - 元のLSは、独自のITADに位置のLSに送信されたすべての広告に空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.
AdvertisementPathは経路選択のために使用することができます。使用される可能な基準は、パスとパス上の特定ITADsの存在下または非存在下におけるホップ数です。
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で説明したように、AdvertisementPathはループからルーティング情報を防ぐために使用されます。 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番号である経路セグメントのタイプ（AP_SEQUENCE又はAP_SET）、および「値」を特定対<タイプ、値>のように、パス内の各ITADをモデル化属性。二つITADsは、それらの対応する<タイプ、値>が同じであれば同じであると言われます。
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_SEQUENCEのすべての対が集約される経路の経路のすべてに表示されなければなりません。 - 凝集経路における型AP_SETのすべての対が（それらがAP_SET又はAP_SEQUENCEタイプのいずれかとして表示されること）初期設定の経路の少なくとも一方に表示する必要があります。 - 集約経路に対Yに先行型AP_SEQUENCEの任意の対Xの場合、Xは関係なく、Yのタイプの、Yを含有する初期セットの各パスにおいて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_SETに集約するルートのパスからのタプルの残りのタイプを設定し、集約パスにそれらを追加します。 - 凝集経路は（かかわらず、タプルの型の）同じ値の複数の組がある場合、集約パスから型AP_SETのタプルを削除することによってこのような一組が、全てを排除します。
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.
- （セクション5.4.1で定義されるように）両方のパス属性内の同じ相対順序である各パス属性内ITADsを識別する。二つITADs、X及びYは、Yは、両方のパスにXに先行する場合のいずれか、Xが両方のパスでYに先行する場合、または同じ順序であると言われます。 - 凝集経路は、これらが集約される経路に現れるとまったく同じ順序で（A）において同定ITADsから成ります。で同定された二つの連続ITADs（a）は直ちに凝集するパスの両方で互いに従わない場合、両方の属性に介在ITADs（同一である二つの連続ITADs間にあるITADs）はAP_SETに結合され両方のパスから介在ITADsから成る経路セグメント。このセグメントは、次に、（A）の集約属性で識別された二つの連続ITADs間に配置されます。で同定された二つの連続ITADs（a）は直ちに一つの属性で互いに従うが、別に従わない場合は、後者の介在ITADsはAP_SET経路セグメントに結合されます。このセグメントは、次に、（a）は、集約パスの中で同定された二つの連続ITADs間に配置されます。
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の第1の経路セグメントがタイプAP_SEQUENCEである場合、ローカル・システムがシーケンスの最後の要素（左端位置にそれを置く）として独自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の第1の経路セグメントがタイプAP_SETである場合*、ローカルシステムは、そのセグメント内の独自ITAD番号を含む、AdvertisementPathに型AP_SEQUENCEの新たな経路セグメントを付加しなければなりません。
Conditional Mandatory: True (if ReachableRoutes attribute is present). Required Flags: Well-known. Potential Flags: None. TRIP Type Code: 5.
必須条件：真（ReachableRoutesが存在する属性場合）。必要なフラグ：よく知られています。潜在的なフラグ：なし。 TRIPタイプコード：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.
この属性は、このルートを使用して送信されたメッセージが通過する、それを通してITADsを識別します。このパスでITADsはAdvertisementPathのもののサブセットです。
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は、隣接ITADsにあるのLSに送信されたすべての広告のRoutedPath属性に独自のITAD番号を含まなければなりません。この場合、元のLSのITADのITAD数はRoutedPath属性で唯一のエントリになります。 - 元のLSは、独自のITADに位置のLSに送信されたすべての広告に空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よりも好ましいです。使用されるいくつかの可能な基準は、パスとパス上の特定ITADsの存在下または非存在下におけるホップ数です。
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.
RoutedPath属性を集約するための規則は、セクション5.4.4.1および5.4.4.2で使用される用語「経路」はRoutedPathを意味すると理解されるセクション5.4.4.1と5.4.4.2、で与えられます。
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はNextHopServerを変更し、別の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の第1の経路セグメントがタイプAP_SEQUENCEである場合*、ローカルシステムは、シーケンスの最後の要素（左端位置にそれを置く）として独自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.
RoutedPathの第1の経路セグメントがタイプAP_SETである場合*、ローカルシステムは、そのセグメント内の独自ITAD番号を含む、RoutedPathに型AP_SEQUENCEの新たな経路セグメントを付加しなければなりません。
Conditional Mandatory: False. Required Flags: Well-known. Potential Flags: None. TRIP Type Code: 6.
必須条件：偽。必要なフラグ：よく知られています。潜在的なフラグ：なし。 TRIPタイプコード：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属性を持っている場合は、そのように結果の集計をしなければなりません。
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は、他のLSにそれを通知するときに、より具体的な目的地のセットしてはならない、とピアLSにこのオブジェクトを伝播する際に、属性を削除してはなりません。
Conditional Mandatory: False. Required Flags: Well-known. Potential Flags: None. TRIP Type Code: 7.
必須条件：偽。必要なフラグ：よく知られています。潜在的なフラグ：なし。 TRIPタイプコード：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へのルーティング・オブジェクトのローカルLSの好みを示し、ドメイン内で使用されています。この属性は、別のドメイン内のLSに通信するときに含んではいけませんし、ドメイン内のリンクの上に含まれなければなりません。
The LocalPreference attribute is a 4-octet unsigned numeric value. A higher value indicates a higher preference.
LocalPreference属性は4オクテット符号なしの数値です。より高い値は、より高い優先度を示しています。
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属性は、ドメイン内の1つのLSは、ルートの嗜好を算出するために、ドメイン内の他のLSにこの設定を通信することを可能にします。
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との通信時LSはLocalPreference属性を含まなければなりません。他のドメインに1つのLSSと通信するときにLSはLocalPreference属性を含んではいけません。ドメイン間のピアから受信したLocalPreference属性を無視しなければなりません。
Conditional Mandatory: False. Required Flags: Well-known. Potential Flags: None. TRIP Type Code: 8.
必須条件：偽。必要なフラグ：よく知られています。潜在的なフラグ：なし。 TRIPタイプコード：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.
2 ITADsは、ピアの複数のセットによって接続されている場合、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は、そのドメイン内の他のLSにMultiExitDiscを伝搬することができます。 MultiExitDisc属性は、他のドメインに1つの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.
必須条件：偽。必要なフラグ：よく知られていない、独立した推移。潜在的なフラグ：なし。 TRIPタイプコード：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.
ルーティングの決定は、グループのアイデンティティに基づくことができるように、コミュニティ属性は、グループ宛先に使用されています。コミュニティ属性を使用すると、大幅に管理者が定義集合部を設けることにより、ルーティング情報の配布を簡素化すべきです。
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管理者は、特定のルートが属するコミュニティを定義することができます。デフォルトでは、すべてのルートは、一般的なインターネット電話のコミュニティに属しています。
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 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.
コミュニティ属性の別の使用例は、集約しています。集約経路と凝集体を形成するために使用された成分より具体的なルートの両方をアドバタイズすることがしばしば有用です。これらの情報要素は、隣接するTRIPピアに対してのみ有用であり、隣接するTRIPピアの多分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 |
+---------------+---------------+--------------+----------------+
| . . . . . . . . .
+---------------+---------------+--------------+----------------+
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.
0x00000000のコミュニティのITAD番号から始まるコミュニティ属性値は、ここに予約されています。
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.
- NO_EXPORT（コミュニティITAD数= 0x00000000のコミュニティID = 0xFFFFFF01）。この値を含むコミュニティ属性を持つ任意の受信した経路は、受信TRIPの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).
他のコミュニティ値は、最も重要な4つのオクテットでITAD番号を使用してエンコードする必要があります。最後の4つのオクテット（コミュニティIDオクテット）のセマンティクスがITADによって定義することができる（例えば、ITAD 690は、研究、教育、およびそのITADのオペレータにより定義されたポリシールーティングのために使用することができる、市販のコミュニティIDを定義する場合があります） 。
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.
コミュニティ属性は、よく知られていません。ルートは、それに関連したコミュニティ属性を持っている場合、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.
ルートのセットが集約されると、その結果の集計がATOMIC_AGGREGATE属性を有していない場合には、その結果の集計は、集約されたルートのコミュニティ属性の和集合が含まれているコミュニティ属性を持つ必要があります。
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は、ピアへのルートを広める前に、コミュニティ属性を操作することができます。コミュニティ属性操作等、コミュニティを追加コミュニティを除去し、コミュニティ属性を追加する（いずれも存在しない場合）、コミュニティ属性を削除含んでいてもよいです
Conditional Mandatory: False. Required Flags: Well-known, Link-State encapsulated. Potential Flags: None. TRIP Type Code: 10.
必須条件：偽。必要なフラグ：よく知られている、リンクステートは、カプセル化されました。潜在的なフラグ：なし。 TRIPタイプコード：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.
LSの故障を検出することができるようにITAD内で、各LSは、他のLSの状態を知っていなければなりません。これを行うには、各LSは、ドメイン内の他のLSへの内部トポロジをアドバタイズします。 LSは、別のLSがもはやアクティブであることを検出しない場合、そのLSによって供給情報を削除することができる（そのピアの調整] - TRIBインがクリアされてもよいです）。 ITADトポロジー属性は、ドメイン内の他のLSにこの情報を通信するために使用されます。
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は、トポロジーの更新プログラムを、その内部ピアセットの変化を検出するたびに送らなければなりません。トポロジー更新は、それ自体でUPDATEメッセージで送信されてもよく、またはそれはReachableRoutes及び/又はWithdrawnRoutes情報を含むUPDATEメッセージにピギーバックされてもよいです。
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からトポロジ更新を受信すると、それはのLSトポロジに接続アルゴリズムによってITAD内でアクティブである再計算しなければなりません。
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が現在ピアリングしているのLSを示しています。セクション4.3.2.4で定義された属性は、LSが現在ピアリングしているTRIP識別子のリストで構成され、フォーマットは、図15のリンクステートカプセル化を使用する必要があり、この属性に与えられています。
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トポロジー属性がUPDATEで任意のルートとは無関係です。 LSの変化の内部ピアのセットが、それはITADトポロジー属性を持つUPDATEを作成する必要がありますたびに内部ピアの現在のセットをリスト含まれていました。 LSは、ピアリングセッションが確立された後、それはピアに送信する最初のUPDATEでこの属性を含まなければなりません。
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.
この属性は、UPDATE内の任意のルーティング情報とは無関係です。 LSはITADトポロジ属性を持つUPDATEを受信すると、ITADトポロジ属性起源のセットによって与えられるITADトポロジに接続テストを実行することによって、ドメイン内で現在アクティブのLSのセットを計算しなければなりません。 LSは、ローカルドメイン内でアクティブでなくなった任意のLS用の調整]-TRIBインを削除する必要があります。彼らは同様の決定を下しますようLSは、他のLSにこのパージ情報を伝播してはなりません。
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.
必須条件：偽。必要なフラグ：よく知られています。潜在的なフラグ：なし。 TRIPタイプコード：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属性を持っている場合は、そのように結果の集計をしなければなりません。
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:
新しいTRIP属性を定義するための任意の提案は、次のように指定する必要があります。
- 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は新しい属性にTRIP属性タイプコードの割り当てを管理します。
This section describes errors to be detected and the actions to be taken while processing TRIP messages.
このセクションでは、検出されるエラーを説明し、TRIPメッセージの処理中のアクションが取られます。
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.
ここに記載のいずれかの条件が検出された場合、示されたエラーコード、エラーサブコード、及びデータフィールドを持つ通知メッセージが送信されなければならない、とTRIP接続が閉じられなければなりません。何のエラーサブコードが指定されていない場合は、ゼロサブコードを使用しなければなりません。
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.
「TRIP接続が閉じられる」というフレーズは、トランスポートプロトコル接続が閉じられたことを意味し、そのTRIP接続用のすべてのリソースが割り当て解除されていること。接続は、ドメイン間であった場合には、リモートピアに関連付けられたルーティングテーブルエントリは無効とマークされなければなりません。内部ピアリングセッションが終了した場合、ルーティングテーブルエントリは無効としてマークされてはなりません。ルートがシステムから削除される前に、ルートが無効とマークされているという事実は、他のTRIPピアに渡されます。
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.
メッセージヘッダを処理している間に検出されたすべてのエラーは、エラーコードメッセージヘッダエラーでNOTIFICATIONメッセージを送ることによって示されています。エラーサブコードはエラーの特定の性質について詳しく説明します。このセクションのエラーチェックは、すべてのメッセージを受信すると、各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.
メッセージヘッダの長さフィールドには4096より3以上よりも小さい場合、またはOPENメッセージの長さフィールドは、オープンメッセージの最小長さより小さい場合、又はUPDATEメッセージの長さフィールドがより小さい場合UPDATEメッセージの最小の長さ、またはKEEPALIVEメッセージの長さフィールドが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.
メッセージヘッダのTypeフィールドが認識されない場合は、エラーサブコードに設定する必要があり、「不正なメッセージタイプ。」データフィールドは誤ったTypeフィールドが含まれています。
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.
OPENメッセージの処理中に検出されたすべてのエラーはエラーコードでNOTIFICATIONメッセージを送ることによって示され、「OPENメッセージエラー。」エラーサブコードはエラーの特定の性質について詳しく説明します。このセクションのエラーチェックは、すべてのオープンメッセージを受信すると、各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).
受信OPENメッセージのバージョンフィールドに含まれているバージョン番号がサポートされていない場合は、エラーサブコードは、に設定しなければならない「サポートされていないバージョン番号。」データフィールドは、リモートTRIPピア入札（受信したオープンメッセージに示されるように）のバージョンよりも小さい最大の局所的サポートされているバージョン番号を示す1オクテットの符号なし整数です。
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.
OPENメッセージの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.
OPENメッセージのホールドタイムフィールドが受け入れられない場合は、エラーサブコードに設定する必要があり、「容認できないホールド時間。」実装では、1または2秒のホールド時間値を拒絶しなければなりません。実装は、任意の提案ホールド時間を拒否することがあります。ホールド時間を受け入れる実装は、ホールド時間のために交渉した値を使用しなければなりません。
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.
OPENメッセージのTRIP識別子フィールドが有効でない場合は、エラーサブコードは、に設定しなければならない「悪いTRIP識別子。」 TRIP識別子は長さが4オクテットであり、任意の値をとることができます。それはすでに同じITADとTRIP識別子を持つ別のピアLSとのオープンな接続を持っている場合LSはTRIP識別子が無効と見なします。
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内の任意の二つのLSは等しいTRIP識別子の値を有してはなりません。目的が一意にTRIP識別子とそのITAD番号を使用してLSを同定することであるので、この制限は、異なるITADsに1つのLSSには適用されません。
If one of the Optional Parameters in the OPEN message is not recognized, then the Error Subcode MUST be set to "Unsupported Optional Parameters."
OPENメッセージ内のオプションパラメータの一つが認識されない場合は、エラーサブコードは、に設定しなければならない「サポートされていないオプションのパラメータ。」
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.
OPENメッセージのオプションパラメータは、（機能タイプまたは値のいずれかでサポートされていない）、サポートされていない機能を備えた能力情報が含まれている場合、エラーサブコードは「サポートされていない機能」に設定しなければならなくて、サポートされていない機能の全体はに記載されている必要があり通知メッセージのデータフィールド。
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.
OPENメッセージのオプションパラメータは、受信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メッセージの処理中に検出されたすべてのエラーはエラーコードでNOTIFICATIONメッセージを送ることによって示され、「UPDATEメッセージエラー。」エラーサブコードはエラーの特定の性質について詳しく説明します。このセクションのエラーチェックは、すべてのUPDATEメッセージを受信すると、各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.
必須のいずれか（すなわち、条件付き必須属性およびUPDATEメッセージの中に含めるための条件が満たされている）のよく知られた属性が存在しない場合は、エラーサブコードは、「よく知られている必須属性がありません。」に設定する必要がありますデータフィールドが欠落している、よく知られた条件付き必須属性の属性タイプコードが含まれています。
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).
よく知られている属性のいずれかが認識されない場合は、エラーサブコードは、に設定しなければならない「認識されないよく知られている属性。」データフィールドは認識されない属性（タイプ、長さ、および値）が含まれています。
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に表示されている場合、ルートが調整] - TRIBインに保存することができます。 LSは、広告経路に独自ITAD持つルートを受け入れるように構成されていない限りしかし、ルートがTRIP意思決定プロセスに渡さあってはなりません。広告パスに独自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.
UPDATEメッセージはリンクステートカプセル化フラグが設定されていない内部ピアとのいずれかWithdrawnRoutes、ReachableRoutes、またはITADトポロジー属性から受信された場合は、エラーサブコードは、「無効な属性」に設定され、データフィールドには属性が含まれています。外部ピアから受信したリンクステートフラグが設定されている場合同様に、属性が無効です。
If any attribute appears more than once in the UPDATE message, then the Error Subcode is set to "Malformed Attribute List."
いずれかの属性がUPDATEメッセージに複数回表示される場合は、エラーサブコードは次のように設定され、「不正な形式の属性リスト。」
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.
ピアが通知メッセージを送信し、そのメッセージにエラーがある場合には、残念ながらその後のNOTIFICATIONメッセージを介してこのエラーを報告する手段がありません。こうした認識できないエラーコードまたはエラーサブコードなどの任意のこのようなエラーは、ローカルログオン、およびピアの管理の注意を喚起、留意すべきです。これを行うための手段が、しかし、この文書の範囲外です。
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.
システムが交渉保持時間で指定された期間内に連続したメッセージを受信しない場合は、との通知メッセージ「ホールドタイマーが期限切れ」エラーコードを送らなければなりませんし、TRIP接続が閉じていなければなりません。
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.
TRIP有限状態マシンによって検出されたエラー（例えば、予期しないイベントの受信）はエラーコード「有限状態機械エラー」とTRIP接続を閉じなければならないとの通知メッセージを送信することをもたらさなければなりません。
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.
（このセクションで示されている）任意の致命的なエラーが存在しない状態で、TRIPピアはエラーコードでNOTIFICATIONメッセージを送ることによって、そのTRIP接続閉じるために、任意の所与の時間に選ぶかもしれ「やめ」をこのセクションで示される致命的なエラーが存在する場合しかし、シーズ通知メッセージを使用してはいけません。
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.
LSのペアが互いへのトランスポート接続を確立するために同時にしようとすると、スピーカーのこのペアの間に2つの並列接続がうまく形成される可能性があります。私たちは、接続衝突とこのような状況を参照してください。明らかに、これらの接続の一つが閉じなければなりません。
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.
TRIP識別子の値に基づいて、大会は衝突が発生したときに保存されるべきTRIP接続検出のために確立されています。規則は、衝突に関与するピアのTRIP識別子を比較し、より高い値のTRIP識別子と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:
OPENメッセージを受信すると、ローカルLSはOpenConfirm状態にあるそのすべての接続を調べる必要があります。それはプロトコルの外部手段によってピアのTRIP識別子を知っている場合LSはまたOpenSent状態の接続を検査することができます。これらの接続のうちTRIP識別子がOPENメッセージで1に等しいリモート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.
（OPENメッセージで指定されるように）ローカルLSのTRIP識別子及びITADは、リモートLSのTRIP識別子及びITADと比較されます。 TRIP識別子は、比較のために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:
ローカルTRIP識別子の値は、リモート1未満である場合、2つのTRIP識別子が等しく、ローカルLSのITADの値は、リモートLSのITADの値未満である場合、または、ローカルLSは必須すでに存在するTRIP接続（OpenConfirm状態に既にあるもの）を閉じ、リモートLSによって開始されたTRIP接続を受け入れます。
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は、新しく作成されたTRIP接続を閉じ、既存のもの（OpenConfirm状態に既にあるもの）を使用し続けています。 2.接続衝突が設立された状態にある既存のTRIP接続で発生した場合、LSは、無条件に新しく作成された接続を閉鎖しなければなりません。接続衝突は、アイドル接続、またはActive状態での接続を検出できないことに注意してください。 3. LSは、エラーコード「やめ」とTRIP接続を閉じなければならないとの通知メッセージを送信しなければならない、（すなわち、衝突解決手順から生じる）TRIP接続を閉じます。
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.
LSが最も高いバージョン番号を各サポートを開始、TRIP接続を開くために複数の試行を行うことで、プロトコルのバージョンを交渉することができるピア。オープン試みがエラーコード「OPENメッセージエラー」とエラーサブコードで失敗した場合、「サポートされていないバージョン番号、」その後、LSはそれがしようとした利用できるバージョン番号、そのピアが試みたバージョン番号、内のピアから渡されたバージョン番号を持っています通知メッセージ、およびそれがサポートするバージョン番号。 2つのピアが1つの以上の共通のバージョンをサポートしている場合、これは彼らが急速に最高の共通のバージョンを確認することができます。 TRIPバージョンネゴシエーションをサポートするために、TRIPの将来のバージョンでは、OPENおよび通知メッセージの形式を保持しなければなりません。
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はLSでサポートされている機能を示すために、ピアへのOPENメッセージで機能オプションを含むかもしれません。 OPENメッセージを受信したLSは、そのピアと通信するときに、ピアのOPENメッセージに含まれていない任意の機能を使用してはいけません。
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）の観点でTRIP操作を指定します。以下は、このFSMによって決定されるような状態によるTRIP操作の概要と概要です。 TRIPのFSMの要約版があり、ピアごとに1つのTRIPのFSMであり、これらのFSMは独立して動作し、付録1に発見されました。
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は、各ピアのためにアイドル状態になっています。この状態では、TRIPは、すべての着信接続を拒否します。何リソースがピアに割り当てられません。 （システムまたはオペレータのいずれかによって開始される）開始イベントに応答して、ローカルシステムは、すべてのTRIPリソースを初期化接続リトライタイマを開始し、ピアへのトランスポート接続を開始し、遠隔によって開始することができる接続のリスニングを開始しますTRIPピア、およびConnectにその状態を変更します。接続リトライタイマの正確な値は、ローカルの問題であるが、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がエラーを検出した場合、それはトランスポート接続を閉じ、Idleにその状態を変更します。アイドル状態からの移行は開始イベントの生成を必要とします。このようなイベントが自動的に生成された場合、永続的なTRIPエラーがLSの永続的なばたつきをもたらすことができます。このような状態を回避するために、開始イベントは、以前のエラーが原因Idleに移行したピアのためにすぐに生成してはなりません。以前のエラーに起因Idleに移行したピアに対して、連続スタートイベント間の時間は、このようなイベントが自動的に生成された場合に、指数関数的に増加しなければなりません。初期タイマ値は60秒であるべきであり、時間は、少なくともいくつかの最大値まで連続した各再試行アップのために2倍にする必要があります。
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は、接続リトライタイマをクリアし、初期化を完了し、OPENメッセージをピアに送信し、そのホールドタイマが大きな値に設定し、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.
トランスポート・プロトコル（例えば、再送タイムアウト）失敗、ローカルシステムに接続リトライタイマを再起動接続した場合、リモート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.
接続リトライタイマ期限切れのイベントに応答して、ローカルLSは、ピアへの未処理のトランスポート接続をキャンセル接続リトライタイマを再起動し、リモート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は、接続リトライタイマをクリアして初期化を完了し、そのピアにOPENメッセージを送信し、大きな値にそのホールドタイマーを設定し、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.
（システムまたはオペレータのいずれかによって開始される）他のイベントに応答して、ローカルシステムは、この接続に関連付けられたすべてのTRIPリソースを解放し、アイドルために、その状態を変化させます。
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は、接続リトライタイマをクリアして初期化を完了し、そのピアにOPENメッセージを送信し、大きな値にそのホールドタイマーを設定し、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.
接続リトライタイマ期限切れのイベントに応答して、ローカルシステムは、接続リトライタイマを再開TRIPピアへのトランスポート接続を開始し、リモートTRIPピアによって開始され、そして接続するために、その状態を変化させることができる接続を待機し続けます。
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.
（システムまたはオペレータのいずれかによって開始される）他のイベントに応答して、ローカルシステムは、この接続に関連付けられたすべてのTRIPリソースを解放し、アイドルために、その状態を変化させます。
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は、そのピアにOPENメッセージを送信し、そのピアからOPENメッセージを待っています。 OPENメッセージを受信すると、すべてのフィールドが正しいかどうかチェックされます。 TRIPメッセージヘッダチェックまたはOPENメッセージチェックがエラーまたは接続衝突（セクション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.
OPENメッセージでエラーがない場合は、TRIPはKEEPALIVEメッセージを送信し、キープアライブタイマーを設定します。元々大きな値に設定されたホールドタイマは、（上記参照）、（セクション4.2を参照）ネゴシエートホールド時間値に置き換えられます。ネゴシエートされた保留時間値がゼロの場合は、ホールド時間タイマーおよびキープアライブタイマーが開始されていません。 ITADフィールドの値がローカルITAD番号と同じである場合、接続は「内部」接続です。そうでない場合、それは「外部」である（これはUPDATE処理に影響を与えます）。最後に、状態が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は、トランスポート接続をクローズ接続リトライタイマを再起動し、リモートTRIPピアによって開始され、アクティブ状態に入ることも接続を待機し続けます。
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は「タイマーが満了ホールド」とIdleにその状態を変更するエラーコードで通知メッセージを送信します。
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エラーコード「シーズ」の通知メッセージを送信し、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は、エラーコード「有限状態マシンエラー」と通知メッセージを送信し、Idleにその状態を変更します。
Whenever TRIP changes its state from OpenSent to Idle, it closes the transport connection and releases all resources associated with that connection.
TRIPはIdleにOpenSentからその状態を変更するたびに、トランスポート接続を解放、その接続に関連付けられているすべてのリソースを閉じます。
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を受信し、そしてOPENに応答してキープアライブを送信しました。 LSは現在、OPENに応じてKEEPALIVEまたは通知メッセージを待っています。
If the local LS receives a KEEPALIVE message, it changes its state to Established.
ローカルLSがキープアライブメッセージを受信した場合、それは設立にその状態を変更します。
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は「タイマーが満了ホールド」とIdleにその状態を変更するエラーコードで通知メッセージを送信します。
If the local LS receives a NOTIFICATION message, it changes its state to Idle.
ローカルLSは、通知メッセージを受信した場合、それはIdleにその状態を変更します。
If the KeepAlive timer expires, the local LS sends a KEEPALIVE message and restarts its KeepAlive timer.
キープアライブタイマーが満了した場合は、ローカルLSは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は、トランスポート接続をクローズ接続リトライタイマを再起動し、リモートTRIPピアによって開始され、アクティブ状態に入ることも接続を待機し続けます。
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は、エラーコード「シーズ」の通知メッセージを送信し、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は、エラーコード「有限状態マシンエラー」と通知メッセージを送信し、Idleにその状態を変更します。
Whenever TRIP changes its state from OpenConfirm to Idle, it closes the transport connection and releases all resources associated with that connection.
TRIPはIdleにOpenConfirmからその状態を変更するたびに、トランスポート接続を解放、その接続に関連付けられているすべてのリソースを閉じます。
Established state: In the Established state, an LS can exchange UPDATE, NOTIFICATION, and KEEPALIVE messages with its peer.
確立された状態：確立された状態で、LSは、そのピアとUPDATE、NOTIFICATION、およびKEEPALIVEメッセージを交換することができます。
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は「タイマーが満了ホールド」とIdleにその状態を変更するエラーコードで通知メッセージを送信します。キープアライブタイマーが満了した場合、ローカルLSは、キープアライブメッセージを送信し、キープアライブタイマーを再起動します。ローカルLSは、UPDATEまたはKEEPALIVEメッセージを受信した場合、それはそのホールドタイマーを再起動します。 LSは、UPDATEまたはKEEPALIVEメッセージを送るたびに、そのキープアライブタイマーを再起動します。
If the local LS receives a NOTIFICATION message, it changes its state to Idle.
ローカルLSは、通知メッセージを受信した場合、それはIdleにその状態を変更します。
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は、UPDATEメッセージとUPDATEメッセージエラー処理手順を（Section6.3参照）エラーを検出し受信した場合、ローカルLSは、通知メッセージを送信し、アイドルために、その状態を変化させます。
If a disconnect notification is received from the underlying transport protocol, the local LS changes its state to Idle.
切断通知が、基礎となるトランスポートプロトコルから受信された場合、ローカルLSはIdleにその状態を変化させます。
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はエラーコード「シーズ」の通知メッセージを送信し、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はエラーコード「有限状態マシンエラー」と通知メッセージを送信し、Idleにその状態を変更します。
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はIdleに設立さから、その状態を変更するたびに、それはトランスポート接続を解放、その接続に関連付けられているすべてのリソースを閉じます。ピアが外部ピアである場合に加えて、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.
UPDATEメッセージは、確立された状態で受信することができます。 UPDATEメッセージが受信されると、セクション6.3で指定されるように、各フィールドは、有効性についてチェックされます。このセクションの残りの部分は、UPDATEメッセージは、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.
UPDATEメッセージが内部ピアから受信した場合、10.1節のフラッディング手順が適用されなければなりません。フラッディングプロセスは、ドメイン内のすべてのLSののLoc-TRIBsを同期します。 UPDATE内の特定のルートが氾濫プロセスによって、古いまたは重複としてマークされると、更新処理の残りの中に無視されます。
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.
UPDATEメッセージが撤回経路が含まれている場合、対応する以前にアドバタイズされたルートは、調整] - 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:
UPDATEメッセージはルートが含まれている場合、ルートが適切なのAdj-TRIBインに配置する必要があり、そして次の追加アクションがとられなければなりません。
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.
その先は現在調整]-TRIBインに保存された経路と同一である場合、新しいルートは、このように暗黙的にサービスから古いルートを引き出す、調整] - TRIBインで古いルートを交換する必要があります1.。古いルートがもはや使用可能であるため、LSは、その決定プロセスを再実行してはなりません。 2.新しいルートはのAdj-TRIBインに含まれている以前の経路よりも特異的であり、同一の属性を有し、それ以上のアクションは必要ない場合。 3.新しいルートが調整] - TRIBインに含まれている以前の経路よりも特異的であるが、同一の属性を持っていない場合、より具体的なルートが暗黙少ない特定の部分を作っているので、その後、LSは、その意思決定プロセスを実行する必要があります使用できなくルート。 4.新しいルートが現在のAdj-TRIBインに格納された経路のいずれかに存在しない目的地がある場合、LSは、その意思決定プロセスを実行する必要があります。 5.新しいルートのAdj-TRIBインに含まれている以前の経路よりも少ない特定の場合、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は、内部ピアからのUPDATEメッセージを受信すると、LSは、そのほかの内部ピアのすべてにそのメッセージから新しい情報をフラッディングします。フラッディングを効率的にドメインの内部トポロジ上の任意の制約をかけることなく、ドメイン内のLSのすべてを同期させるために使用されます。フラッディングメカニズムは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インの各リンクステートカプセル化された属性のシーケンス番号と発信TRIP識別子を維持しなければなりません。これらの値はReachableRoutes、WithdrawnRoutesルートに含まれており、ITADトポロジー属性されています。発信TRIP識別子が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).
ルートが新しいか古い場合ReachableRoutesまたはWithdrawnRoutesフィールド内の各ルートについて、LSが決定しました。これは、のAdj-TRIBインに保存された経路のシーケンス番号を持つUPDATEに経路のシーケンス番号を比較することによって決定されます。ルートは、ルートが元のLSのための調整]-TRIBインには存在しないか場合は、新規であるか、ルートが調整] - TRIBインには存在しないが、UPDATEでのシーケンス番号が保存されたシーケンス番号よりも大きい場合調整] - TRIBsインインチ新しさのテストは、独立してUPDATE（WithdrawnRoutes又はReachableRoutes又は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は調整] - TRIBインでルートを更新しなければならなくて、他のすべての内部ピアにそれをあふれさせる必要があります。
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.
これらの手順は調整] - TRIBインに変化をもたらす場合、早期項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.
洪水を実装するには、以下のことが推奨されます。新規であると判断された単一のUPDATEメッセージで受信したすべてのルートは、単一のUPDATEメッセージ内の他のすべての内部ピアに転送されなければなりません。洪水の他の変形が可能であるが、ローカル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.
シーケンス番号は、ルートの1つのバージョンの経路の別のバージョンよりも新しい時期を決定するために使用されます。より大きなシーケンス番号は、新しいバージョンを示します。シーケンス番号は、ローカルITADにルートを発信するLSによって割り当てられます。シーケンス番号はMaxSequenceNumスルー1 31-1 ^ 2スルーMinSequenceNum）の範囲の符号なしの4オクテットの整数です。値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であることを、これまでの場合であり、それが増加する必要がある場合、これは高いシーケンス番号とLSによって発信すべてのルートができるように、その後、LSのTRIPモジュールはTripDisableTimeの期間を無効にする必要があり削除しました。
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はUPDATEメッセージのWithdrawnRoutesフィールドの経路を含みます。シーケンス番号は、ルートの最後の有効なバージョンよりも大きくなければなりません。 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がされるまで待つことに使用されるものよりも大きいシーケンス番号を使用してルートを再発信することができますルートは撤回されたため、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はのLS現在のバージョンよりも、それはそれの方が新しい発信ルートを更新する（より高いシーケンス番号を有する）を受信する場合には、特別なアクションがとられなければなりません。これは比較的まれなるとルートがまだのLS最後の再起動/再起動以降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はUPDATEで受信よりも大きい値にルートのシーケンス番号を増やす必要があり、経路を再発信します。 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.
意思決定プロセスは、のAdj-TRIBsインに格納されたルートに、ローカルポリシー情報ベース（PIB）でポリシーを適用することによって、後続の広告のための経路を選択します。決定プロセスの出力は、すべてのピアにアドバタイズされるルートのセットです。選択されたルートは、ローカルLSの調整]-TRIBsアウトに保存されます。
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のすべての内部のLSは、それ以外の場合は、そののLoc-TRIBsを同期することはできません。
The Decision Process operates on routes contained in each Adj-TRIBs-In, and is responsible for:
決定プロセスは、それぞれのAdj-TRIBsインに含まれるルートで動作し、責任があります。
- 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:
決定プロセスは、3つの異なる段階、異なるイベントによってトリガされる毎に行われます。
- 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は、それがそれぞれ異なる宛先に対して、および、Loc-TRIBにそれぞれ選択されたルートをインストールするための利用可能なすべてのもののうち、最適なルートを選択する責任があるフェーズ1の完了時に呼び出されます。 - の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.
フェーズ1の決定機能は、ローカルLSがピア新しい経路、代替経路、または取り下げルートをアドバタイズUPDATEメッセージから受信するたびに呼び出されなければなりません。
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インをロックしなければならない、そしてその中に含まれるすべての新しいまたは交換経路上で動作後にロックを解除しなければなりません。
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属性の値は、優先度として払わなければなりません。ルートは、外部ピアから学習されている場合、優先度は、予め設定されたポリシー情報に基づいて計算され、任意のドメイン内TRIP広告に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の機能は、それが行うには、さらに仕事を持っていないときに完了し、別のプロセスです。図2A及び図2B：フェーズ2は、2つのサブフェーズから成ります。同じ経路選択機能は、両方のサブフェーズで適用されるが、各フェーズへの入力が異なっています。フェーズ2aプロセスは、入力として外部ピアの調整] - TRIBsインに存在するすべての外部経路、およびすべてのローカルルートを考慮しなければなりません。フェーズ2aの出力は、EXT-TRIBに挿入されます。フェーズ2bプロセスは、フェーズ2aの完了時に呼び出されなければならない、それは入力としてEXT-TRIB及び内部のLSの調整] - TRIBsインに存在するすべての経路内のすべてのルートを考慮しなければなりません。フェーズ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.
フェーズ2の決定機能は、フェーズ3の決定機能の処理中に実行されているからブロックされなければなりません。フェーズ2の機能は、従来の機能を開始するすべてのAdj-TRIBsインと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は、経路に記載されているNextHopServerが到達不能であると判断した場合、ルートは、フェーズ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:
1つまたは複数のルートが存在するために目的地のセットごとに、ローカル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-TRIBsインから除去されなければなりません。
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 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.
嗜好の同一度を有する同じ宛先へのいくつかの経路は、フェーズ2の経路選択関数に入力してもよいです。ローカルLSは、関連EXT-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によって発信された場合、最小のTRIP 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.
Loc-TRIBの変更又は場合におけるフェーズ2つの結果は、新たなLS対LSピアセッションが確立されている場合、フェーズ3の決定機能は、フェーズ2の完了時に呼び出されなければなりません。
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の機能は、それが行うには、さらに仕事を持っていないときに終了し、別のプロセスです。フェーズ3ルーティング決定機能は、フェーズ2の決定機能の処理中に実行されているからブロックされなければなりません。
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-TRIBsアウトの対応するエントリに加工しなければなりません。ルート集約及び情報低減技術は、（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.
調整] - TRIBsアウトの更新が完了すると、ローカル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インに存在するとき、より具体的な経路は、特定の最小の最も特定の順番に優先しなければなりません。
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が重複したルートを受信した場合、決定プロセスは、アカウントに重複したルートの意味を取る必要があります。具体的には、その後の重複によって表される宛先がドメインは、その経路のAdvertisementPath属性に記載されていないかもしれ前方に沿って、同じピアからより具体的なルートを拒絶しながら、LSは、より特定のルートを受け入れる場合。したがって、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.骨二つの経路（すなわち、より少ない固有の経路の脱凝集を意味します）そして唯一6.どちらのルートをインストール少なく特定のルートをインストール集約ルート5をインストール
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.
更新-送信プロセスは、すべてのピアへの広告UPDATEメッセージを担当しています。例えば、それは同じITAD又は隣接ITADのいずれかに配置することができる他のLSの決定処理によって選択されたルートを分配します。 10.3.2に記載されている異なるITADsに位置するピアのLSとの間の情報交換のためのルール。同じITADに位置するピアのLSとの間の情報交換のためのルールは、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は、そのルートに沿って転送されるべき属性を決定しなければなりません。よく知られていない非推移属性が認識されない場合、それは静かに無視されます。よく知られていない依存-推移属性が認識されない、とNextHopServer属性はLSによって変更された場合は、認識されていない属性は静かに無視されます。よく知られていない依存-推移属性が認識され、そしてNextHopServer属性はLSによって変更されていない場合は、属性フラグオクテットの部分ビットは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に位置する別のTRIPのLSからUPDATEメッセージを受信した場合、セクション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-サブ・データベースとLSは、UPDATEメッセージにより、そのITAD内の他のすべてのLSへのルートをアドバタイズしなければなりません。 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が空WithdrawnRoutesとUPDATEメッセージを受信したときに外部ピアから属性、または局所経路がTRIPから引き抜かれた場合、LSは、その調整] - TRIB-Inからその目的地この分野で行われたすべてのルートを削除する必要があります。撤退ルートが以前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は撤退ルートを交換し、すべての内部のLSにそれを宣伝するためにEXT-TRIBに代替ルートを挿入しなければなりません。 - 代替ルートが広告のために利用できない場合、LSは、UPDATEメッセージのWithdrawnRoutes属性にルートの宛先を含まなければならない、とそれぞれの内部ピアにこのメッセージを送らなければなりません。 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 destination, all of which were advertised by external peers. The local LS shall select one of these routes according to the following rules:
LSは、いくつかの外部ピアへの接続を持っている場合は、複数の調整] - TRIBs-でこれらのピアに関連付けられているが存在します。これらのデータベースは、外部ピアによってアドバタイズされたすべてが同じ宛先へのいくつかの等しく好ましい経路が、含まれている場合があります。ローカル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の最低値を持つ経路を選択 - によってアドバタイズされたルートを選択最低TRIP識別子を持つ外部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は、その調整] - TRIBsアウトを更新しました。すべての新しくインストールされたルートと代替はありません。ルートが存在しないするすべての新規実行不可能なルートがUPDATEメッセージによって、外部ピアにアドバタイズされなければなりません。
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内で到達可能な目的地の変更はまた、UPDATEメッセージでアドバタイズするものとします。
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プロトコルは、UPDATEメッセージをアドバタイズするために必要なリンク帯域幅とUPDATEメッセージに含まれる情報を消化するための決定プロセスが必要とする処理能力の両方を制限するためにトラフィックをルーティング量（つまり、UPDATEメッセージ）を拘束します。
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.
パラメータMinRouteAdvertisementInterval単一LSから特定の宛先へのルートの広告の間に経過しなければならない時間の最小量を決定します。 MinRouteAdvertisementIntervalの値を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 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.
外部ピアから受信した目的地のいくつかの一般的なセットに実現可能なルートをアドバタイズシングルLSから送信された2つの更新メッセージは、少なくともMinRouteAdvertisementIntervalで区切らなければなりません。明らかに、これが唯一の目的地の各共通セットに個別のタイマーを維持することによって、正確に達成することができます。これは不当なオーバーヘッドになります。外部ピアから受信した目的地のいくつかの一般的なセットに実現可能ルートをアドバタイズ単一LSから送信された2つのUPDATEメッセージ間の間隔は、少なくともMinRouteAdvertisementIntervalなり、また間隔に一定の上限が許容可能であることを確実にすることを確実にする任意の技術。
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から送信された2つの更新メッセージは、少なくともMinRouteAdvertisementIntervalによって分離されなければなりません。
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内で必要とされるので、手順を制限このレートは、内部ピアから受信したルートには適用されず、他の内部ピアにブロードキャストされます。長寿命のブラックホールを避けるために、手順は（つまり、その送信先を明示的UPDATEメッセージによって撤回ルート）ルートの明示的な撤退には適用されません。
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.
この手順は、ルート選択の割合が、ルート広告の唯一のレートを制限しません。 MinRouteAdvertisementIntervalの満了を待っている間に、新たなルートが複数回選択している場合は、最後に選択した経路は、MinRouteAdvertisementIntervalの最後に宣伝されなければなりません。
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内で変更を報告したUPDATEメッセージの連続した広告の間で経過しなければならない時間の最小量を決定します。
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によるTRIPメッセージの分布がピークを含有する可能性を最小限に抑えるために、ジッタがMinITADOriginationInterval、キープアライブ、およびMinRouteAdvertisementIntervalに関連付けられたタイマーに適用すべきです。所与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.
それが宣伝することルーティング情報を選択すると、TRIPスピーカは、効率的な方法でこの情報を整理する方法を使用してもよいです。これらのメソッドは、次のセクションで説明されています。
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:
決定プロセスは、必要に応じて、それは次のいずれかの方法により調整] - TRIBsアウトに配置すること情報の量を減らすことができます。
- 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.
- ReachableRoutes：目的地のセットは、通常、コンパクトな形で表現することができます。例えば、E.164電話番号のセットは、E.164プレフィックスを使用して、よりコンパクトな形で表現することができます。 - AdvertisementPath：AdvertisementPath情報は、注文したAP_SEQUENCEsまたは順不同AP_SETsとして表すことができます。 AP_SETsはセクション5.4.4に記載した経路集約アルゴリズムで使用されています。彼らは関係なく、それが集約された複数の広告・パスに登場したかもしれない何回の、それぞれ一度だけITAD番号を一覧表示することでAP_PATH情報のサイズを小さくします。
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_SETはUPDATEメッセージでアドバタイズ宛先が構成ITADsの少なくとも一部を横切るパスを介して到達することができることを意味します。 AP_SETsは、経路のループを回避するために十分な情報を提供します。そのような経路がもはやAP_SEQUENCEsの形態のように個別に記載されているので、それらの使用は、潜在的に実現可能な経路を剪定なくてもよいです。実際には、これは一度呼がITADsのグループの縁に到達するので、その点での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-TRIBsアウトに配置されているルーティング情報の量を減らすために決定プロセスの一部として生じ得ます。
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とLSが保管しなければならない情報の量や交換を低減します。ルートのようなタイプの属性とは別に、以下の手順を適用することによって凝集させることができます。
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.
異なるタイプのコードを有する属性は集約することができません。同じタイプのコードの属性は集約されてもよいです。各属性を集約するためのルールは、属性の定義と一緒に提供されなければなりません。例えば、TRIPの基本的な属性の集計規則は、例えば、ReachableRoutesとAdvertisementPathは、セクション5に記載されています。
Generally speaking, additional rules for comparing routes among several alternatives are outside the scope of this document. There are two exceptions:
一般的に言って、いくつかの選択肢の中でルートを比較するための追加ルールは、この文書の範囲外です。 2つの例外があります。
- 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は、新しいルートのAdvertisementPathに表示された場合、その新しいルートは他のルートよりも良いとみなすことはできません。そのような経路がこれまで使用された場合、ルーティンは（セクション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に他の何らかの手段により取得されたルーティング情報を注入することにより局所ルートを発信することができます。 TRIPルートを発信LS（セクション10.2を参照）を決定プロセスを介してそれらを通過させることにより、これらの経路に優先度を割り当てなければなりません。旅行に、ローカルルートは、外部ルートと同一であり、同じ2つの位相経路選択機構に供されます。 EXT-TRIBに選択されているローカルルートは、すべての内部のLSに通知しなければなりません。 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.
この仕様は、TRIPのためのトランスポート層としてTCPを使用することを定義します。 TRIPは、今後の検討課題である他のトランスポートプロトコルを介してTRIPを実行しているTCPポート6069.を使用しています。
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のLSのドメイン内のトポロジに制限はありません。例えば、ITAD内のLSは、フルメッシュ、スター、または任意の他の接続トポロジで構成することができます。同様に、TRIPのITADsのトポロジーに制限はありません。例えば、ITADsは平坦トポロジー（メッシュまたは環）または多レベルの階層または他の任意のトポロジーに編成することができます。
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.
2つのトリップのITADsの境界のいずれか2つのトリップするのLSとの間のリンク上に位置してもよく、またはそれはTRIPのLSに一致してもよいです。後者の場合には、同一のTRIP LSは、複数のITADのメンバーになり、そしてのメンバーである各ITAD内のLSに内部ピアであるように見えます。
This document creates a new IANA registry for TRIP parameters. The following TRIP parameters are included in the registry:
この文書では、TRIPパラメータのための新しいIANAレジストリを作成します。次TRIPパラメータがレジストリに含まれています：
- TRIP Capabilities - TRIP Attributes - TRIP Address Families - TRIP Application Protocols - TRIP ITAD Numbers
- TRIP機能 - TRIP属性 - TRIPアドレスファミリ - TRIPのアプリケーションプロトコル - TRIPの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.
プロトコル・パラメータは、頻繁にこの文書では、明らかに未設定パラメータとそのパラメータの任意の他の登録された値とを区別するために、上記TRIPパラメータのそれぞれの値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で定義されたもの以外のTRIP機能を追加するための要求は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.
この文書準備プライベート使用（これらが1に等しいコードの最初の3ビットを有するコードである）をコードする224から255の属性タイプ。この文書では、1〜11がすでにこの文書によって割り当てられた値0属性タイプコードを留保します。属性タイプ・コードは、1〜11が5.11を通じて、セクション5.1で定義されています。
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.
IANAによって制御される範囲12から223にタイプコード属性、及び仕様文書（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.
このドキュメントの埋蔵量は、セクション5.1.1.1で定義されたもの以外のTRIPアドレスファミリ追加する0要求家族に対処（アドレスファミリ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レジストリを作成します。この文書は5から32767の範囲内、すなわち（1〜4のアプリケーション・プロトコル）、5.1.1.1節に定義されたもの以外のTRIPアプリケーションプロトコルを追加する0要求するアプリケーション・プロトコル・コードを予約、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:
この文書では、1から255の範囲のITAD数0 ITAD番号はプライベート用に指定されている留保します。 256から（2 ** 32）の範囲のITAD番号-1先着順でIANAによって割り当てられます。 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.
TRIPは、IP環境でTCP上で実行されるときに、このセクションでは、ピアTRIPのLS間のセキュリティをカバーしています。
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のLSで不正ピアセッションを設定するか、許可されたピアセッションに干渉するため、この文書で定義されたプロトコルを使用して、権限のないエンティティを防止するために必要とされます。 IPネットワークでTCPを介して転送プロトコルのためのセキュリティメカニズム、IPsecの[12]です。認証ヘッダー（AH）[13]とカプセル化セキュリティペイロード（ESP）[14]：IPsecはトラフィックセキュリティを提供するために、2つのプロトコルを使用しています。
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ヘッダは、データ発信元認証、コネクションレス完全性およびピアのLSの間で渡されるメッセージのオプションのアンチリプレイ保護を与えます。 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は、2つのホスト間のセキュリティアソシエーションであり、2つのピア間のLS TRIPセッションを保護するために適切です。
A1. Appendix 1: TRIP FSM State Transitions and Actions
A1。付録1：TRIP 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.
この付録では、イベントを旅行に応じて、TRIPのFSMの状態間の遷移について説明します。ネゴシエートされた保留時間値がゼロでない場合は、次のは、これらの状態とイベントのリストです。
TRIP States: 1 - Idle 2 - Connect 3 - Active 4 - OpenSent 5 - OpenConfirm 6 - Established
TRIPアメリカ：1 - アイドル2から3を接続 - アクティブ4 - OpenSent 5 - OpenConfirm 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
TRIPイベント：1から5閉じTRIPトランスポート接続 - - TRIPスタート2 - TRIP停止3 - TRIPトランスポート接続オープン4 TRIPトランスポート致命的なエラー7 - - タイマは9期限切れホールド - - キープアライブタイマー接続リトライタイマ8を満了しTRIPトランスポート接続のオープンは6に失敗しました10期限切れ - OPENメッセージ11を受信 - KEEPALIVEメッセージ12を受信 - UPDATEメッセージ13を受信 - 通知メッセージを受信
The following table describes the state transitions of the TRIP FSM and the actions triggered by these transitions.
次の表は、TRIPの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
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）1なしなし2 3コンプリート初期OPEN 4クリア接続リトライタイマ5再始動ConnectRetryタイマーなし3~7再始動接続リトライタイマを接続
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 3コンプリート初期OPEN 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 4閉じるトランスポート接続なし3再始動接続リトライタイマ6つのリリースリソースなし1~10プロセスOPENがOK KEEPALIVE 5プロセスOPENで閉じる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
OpenConfirm（5）1つのなしなし5つの4リリースリソースなし1~6リリースリソースなし1~9再始動キープアライブタイマーキープアライブ5つの11完全初期化なし6再起動タイマホールド13件のを閉じるトランスポート接続1発売リソースその他閉じるトランスポート接続NOTIFICATION 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
-----------------------------------------------------------------
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
| | | | | |
--------------------------------------------------------------
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 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.
TRIPプロトコルは、同じ広告パスと一つのメッセージで指定される次のホップサーバと複数のアドレスプレフィックスを可能にします。この機能を利用することを強くお勧めします。メッセージごとにアドレスプレフィックスを有する受信機におけるオーバーヘッドの大幅な増加があります。複数のメッセージの受信によるシステムのオーバーヘッドの増加を行いますが、ピアをトリップする更新のためのルーティングテーブルをスキャンするオーバーヘッドは、同様に複数回発生しただけでなく。広告パスごとに整理されていないルーティングテーブルから広告パスと次のホップごとに多数のアドレスプレフィックスを含むメッセージを構築する一つの方法は、ルーティングテーブルがスキャンされると多くのメッセージを構築することです。各アドレスプレフィックスが処理されるように、それが存在しない場合、関連する広告パスと次のホップのメッセージは、割り当てられ、新しいアドレスプレフィックスが追加されています。そのようなメッセージが存在する場合は、新しいアドレスプレフィックスはそれに追加されます。メッセージは、新しいアドレスプレフィックスを保持するためのスペースがない場合は、新しいメッセージが割り当てられ、送信され、新しいアドレスプレフィックスは、新しいメッセージに挿入されます。ルーティングテーブル全体がスキャンされた場合は、割り当てられたすべてのメッセージが送信され、そのリソースが解放されます。アドレス接頭語でカバーすべての宛先が、それが可能1 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実装とのピアリング場合には、ピアが取得されるか、または有意なネットワークトポロジの変更が発生した場合、受信したデータの洪水からのオーバーヘッドを低減するための手順を実行する必要があるかもしれません。これを行う1つの方法は、アップデートの速度を制限することです。これは、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.
このような状況で使用することができる1つの方法は、最初だけメッセージヘッダを読み込むしようとすることです。 KEEPALIVEメッセージタイプの場合、これは完全なメッセージです。他のメッセージタイプのために、ヘッダは、第1の特定の全長に、検証されるべきです。全てのチェックが成功した場合、指定された長さ、マイナスメッセージヘッダのサイズは、データの量を読み取るために残されます。ピアから読み取るしようとしたとき、ルーティング情報プロセスを「ハング」なる実装は、ピアあたりのメッセージバッファ（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.
目的地を撤回し、同じUPDATEメッセージにそれらを結合する必要があり、より具体的な以下の特定のルートについてのアップデートを送信する必要があるLS羽ばたき、過剰なルートを避けるために。
A.2.4: TRIP Timers
A.2.4：TRIPタイマー
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.
ConnectRetry、ホールド時間、キープアライブ、MaxPurgeTime、TripDisableTime、MinITADOriginationInterval、およびMinRouteAdvertisementInterval：TRIPは7つのタイマーを採用しています。接続リトライタイマの推奨値は120秒です。ホールド時間の推奨値は90秒です。キープアライブタイマーの推奨値は30秒です。 MaxPurgeTimeタイマーの推奨値は10秒です。 TripDisableTimeタイマーの推奨値は180秒です。 MinITADOriginationIntervalの推奨値は30秒です。 MinRouteAdvertisementIntervalの推奨値は30秒です。
An implementation of TRIP MUST allow these timers to be configurable.
TRIPの実装は、これらのタイマーを設定できるように許容しなければなりません。
A.2.5: AP_SET Sorting
A.2.5：AP_SETソート
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_SETで見つかったITAD番号をソートすることです。この最適化は完全にオプションです。
Acknowledgments
謝辞
We wish to thank Dave Oran for his insightful comments and suggestions.
私たちは、彼の洞察に満ちたコメントと提案のためのデイブオランに感謝したいです。
References
リファレンス
[1] Bradner, S., "Keywords for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーの、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]ローゼンバーグ、J.、およびH. Schulzrinneと、 "ゲートウェイロケーションプロトコルの枠組み"、RFC 2871、2000年6月。
[3] Rekhter, Y. and T. Li, "Border Gateway Protocol 4 (BGP-4)," RFC 1771, March 1995.
[3] Rekhter、Y.、およびT.リーを、 "ボーダーゲートウェイプロトコル4（BGP-4）"、RFC 1771、1995年3月。
[4] Moy, J., "Open Shortest Path First Version 2", STD 54, RFC 2328, April 1998.
[4]モイ、J.、 "オープン最短パスファーストバージョン2"、STD 54、RFC 2328、1998年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]ルチアーニ、J.、アーミテージ、G.、アルペルン、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、ジュネーブ、スイス、2000年11月のバージョン3電気通信標準化部門。
[8] Handley, H., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[8]ハンドレー、H.、Schulzrinneと、H.、学生はE.およびJ.ローゼンバーグ、 "SIP：セッション開始プロトコル"、RFC 2543、1999年3月。
[9] Braden, R., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989.
[9]ブレーデン、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.デアリング、 "IPバージョン6アドレッシング体系"、RFC 2373、1998年7月。
[11] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
、BCP 26、RFC 2434、1998年10月[11] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"。
[12] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[12]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[13] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[13]ケント、S.とR.アトキンソン、 "IP認証ヘッダ"、RFC 2402、1998年11月。
[14] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[14]ケント、S.とR.アトキンソン、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 2406、1998年11月。
[15] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[15]ハーキンズ、D.とD.カレル、 "インターネットキー交換（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の手順に関する情報は、11の出版物のために利用可能となる権利の主張のコピーやライセンスの保証が利用できるようにするBCPで見つかった、または試みの結果することができます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
72イーグルロックアベニューまず階イーストハノーバー、NJ 07936 dynamicsoftジョナサン・ローゼンバーグ
Phone: 973-952-5000 EMail: jdrosen@dynamicsoft.com
電話：973-952-5000 Eメール：jdrosen@dynamicsoft.com
Hussein F. Salama Cisco Systems 170 W. Tasman Drive San Jose, CA 95134
フセインF.サラマシスコシステムズ170 W.タスマン・ドライブサンノゼ、CA 95134
Phone: 408-527-7147 EMail: hsalama@cisco.com
電話：408-527-7147 Eメール：hsalama@cisco.com
Matt Squire Hatteras Networks 639 Davis Drive Suite 200 Durham, NC 27713
マット・スクワイアハッテラスネットワーク639デイビスドライブスイート200ダーラム、ノースカロライナ27713
EMail: mattsquire@acm.org
メールアドレス：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 Editor機能のための基金は現在、インターネット協会によって提供されます。