[要約] RFC 3219は、Telephony Routing over IP（TRIP）プロトコルに関する仕様です。TRIPは、IPネットワーク上での電話ルーティングを可能にするためのプロトコルであり、効率的な通信とネットワークリソースの最適化を目的としています。
Network Working Group J. Rosenberg
Request for Comments: 3219 dynamicsoft
Category: Standards Track H. Salama
Cisco Systems
M. Squire
Hatteras Networks
January 2002
Telephony Routing over IP (TRIP)
IPを介したテレフォニールーティング（旅行）
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.
Copyright（c）The Internet Society（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の操作はシグナリングプロトコルとは無関係であるため、旅行はシグナリングプロトコルのテレフォニールーティングプロトコルとして機能します。
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.
Border Gatewayプロトコル（BGP-4）は、管理ドメイン間でルーティング情報を配布するために使用されます。旅行は、テレフォニールーティング情報をテレフォニー管理ドメイン間で配布するために使用されます。2つのプロトコル間の類似性は明らかであるため、旅行は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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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）：旅行への参加の結果として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.
集約：集約とは、複数のルートが同じ宛先のセットをカバーする単一の低いルートに結合するプロセスです。集約は、輸出旅行ルートの数を減らすことにより、ピアLSSと同期する部族のサイズを縮小するために使用されます。
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。LSSが同じITADにある場合、それらは内部ピアです。そうでなければ、彼らは外部の仲間です。2つのピアLSS間の論理的関連は、ピアリングセッションと呼ばれます。
Telephony Routing Information Protocol (TRIP): The protocol defined in this specification. The function of TRIP is to advertise the reachability of telephony destinations, attributes associated with the destinations, as well as the attributes of the path towards those destinations.
テレフォニールーティング情報プロトコル（TRIP）：この仕様で定義されているプロトコル。旅行の機能は、テレフォニーの目的地の到達可能性、目的地に関連する属性、およびそれらの目的地へのパスの属性を宣伝することです。
TRIP 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).
旅行先：旅行を使用して、複数のプロトコル（SIP、H323など）のルーティングテーブルを管理できます。旅行では、宛先は（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テレフォニーでより困難な問題の1つと考えられています。テレフォニーコール用の出口ゲートウェイの選択、PSTNの最終的な目的地に向かってIPネットワークを横断することは、大部分がパスに沿ったさまざまな関係者のポリシーと、これらの関係者間で確立された関係によって推進されます。そのため、ユーザーが目的地の電話番号を調べるEugressゲートウェイのグローバルディレクトリは、実行可能なソリューションではありません。むしろ、出力ゲートウェイの可用性に関する情報は、プロバイダー間で交換され、ポリシーの対象となり、ローカルで利用可能になり、他のITADの他のプロバイダーに伝播されるため、これらの出力ゲートウェイに向かってルートを作成します。これにより、各プロバイダーは到達可能な電話番号と関連するルートの独自のデータベースを作成できます。このようなデータベースは、ポリシーに応じて各プロバイダーで非常に異なる場合があります。
TRIP is an inter-domain (i.e., inter-ITAD) gateway location and routing protocol. The primary function of a TRIP speaker, called a location server (LS), is to exchange information with other LSs. This information includes the reachability of telephony destinations, the routes towards these destinations, and information about gateways towards those telephony destinations residing in the PSTN. The TRIP requirements are set forth in [2].
旅行は、ドメイン間（すなわち、インタータッド）ゲートウェイの位置とルーティングプロトコルです。ロケーションサーバー（LS）と呼ばれるトリップスピーカーの主な機能は、他のLSSと情報を交換することです。この情報には、テレフォニーの目的地の到達可能性、これらの目的地へのルート、PSTNに居住するテレフォニーの目的地へのゲートウェイに関する情報が含まれます。旅行要件は[2]に記載されています。
LSs exchange sufficient routing information to construct a graph of ITAD connectivity so that routing loops may be prevented. In addition, TRIP can be used to exchange attributes necessary to enforce policies and to select routes based on path or gateway characteristics. This specification defines TRIP's transport and synchronization mechanisms, its finite state machine, and the TRIP data. This specification defines the basic attributes of TRIP. The TRIP attribute set is extendible, so additional attributes may be defined in future documents.
LSSは、ルーティングループが防止されるように、ITAD接続のグラフを構築するのに十分なルーティング情報を交換します。さらに、トリップは、ポリシーを実施するために必要な属性を交換し、パスまたはゲートウェイの特性に基づいてルートを選択するために必要な属性を交換するために使用できます。この仕様では、Tripの輸送および同期メカニズム、その有限状態マシン、および旅行データを定義します。この仕様は、旅行の基本属性を定義します。トリップ属性セットは拡張可能であるため、将来のドキュメントで追加の属性を定義できます。
TRIP 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].
トリップは、Border Gateway Protocol 4（BGP-4）[3]をモデルにし、いくつかのリンク状態機能で強化されます。キャッシュ同期プロトコル（SCSP）[6]。Tripは、BGPのドメイン間輸送メカニズム、BGPのピアコミュニケーション、BGPの有限状態マシン、およびBGPと同様の形式と属性を使用します。ただし、BGPとは異なり、TRIPは一般的なドメイン内LSトポロジーを許可します。これにより、構成が簡素化され、内部BGPスピーカーのBGPの完全なメッシュ要件とは対照的にスケーラビリティが向上します。Tripは、OSPF [4]、IS-IS [5]、およびSCSP [6]で使用されているものと同様のドメイン内洪水メカニズムを使用しています。
TRIP permits aggregation of routes as they are advertised through the network. TRIP does not define a specific route selection algorithm.
トリップは、ネットワークを介して宣伝されているルートの集約を許可します。旅行は、特定のルート選択アルゴリズムを定義しません。
TRIP 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'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の操作は、特定のテレフォニーシグナリングプロトコルとは無関係です。したがって、旅行は、これらのプロトコルのいずれかのルーティングプロトコルとして使用できます。たとえば、H.323 [7]およびSIP [8]。
The LS peering topology is independent of the physical topology of the network. In addition, the boundaries of an ITAD are independent of the boundaries of the layer 3 routing autonomous systems. Neither internal nor external TRIP peers need to be physically adjacent.
LSピアリングトポロジーは、ネットワークの物理的トポロジーとは無関係です。さらに、ITADの境界は、レイヤー3ルーティング自律システムの境界とは無関係です。内部または外部のトリップピアも物理的に隣接する必要はありません。
This section summarizes the operation of TRIP. Details are provided in later sections.
このセクションでは、旅行の操作をまとめます。詳細については、後のセクションに記載されています。
Two peer LSs form a transport protocol connection between one another. They exchange messages to open and confirm the connection parameters, and to negotiate the capabilities of each LS as well as the type of information to be advertised over this connection.
2つのピアLSSは、互いに輸送プロトコル接続を形成します。メッセージを交換して、接続パラメーターを開いて確認し、各LSの機能と、この接続で宣伝される情報の種類をネゴシエートします。
KeepAlive messages are sent periodically to ensure adjacent peers are operational. Notification messages are sent in response to errors or special conditions. If a connection encounters an error condition, a Notification message is sent and the connection is closed.
キープライブメッセージは、隣接するピアが運用可能になるように定期的に送信されます。通知メッセージは、エラーまたは特別な条件に応じて送信されます。接続がエラー条件に遭遇した場合、通知メッセージが送信され、接続が閉じられます。
Once the peer connection has been established, the initial data flow is a dump of all routes relevant to the new peer (In the case of an external peer, all routes in the LS's Adj-TRIB-Out for that external peer. In the case of an internal peer, all routes in the Ext-TRIB and all Adj-TRIBs-In). Note that the different TRIBs are defined in Section 3.5.
ピア接続が確立されると、初期データフローは新しいピアに関連するすべてのルートのダンプです（外部ピアの場合、その外部ピアのLSのadj-tributのすべてのルート。内部のピアの、ext-tribとすべてのadj-tribs-in）のすべてのルート）。さまざまな部族がセクション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.
旅行ルーティングテーブル（部族）が変更されると、増分更新が送信されます。旅行では、ルートの定期的な更新は必要ありません。したがって、LSはすべてのルーティングエントリの現在のバージョンを保持する必要があります。
If a particular ITAD has multiple LSs and is providing transit service for other ITADs, then care must be taken to ensure a consistent view of routing within the ITAD. When synchronized the TRIP routing tables, i.e., the Loc-TRIBs, of all internal peers are identical.
特定のITADに複数のLSSがあり、他のITADにトランジットサービスを提供している場合、ITAD内のルーティングの一貫したビューを確保するために注意する必要があります。すべての内部ピアのトリップルーティングテーブル、つまりloc-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と同様に、旅行は内部のピアと外部のピアを区別します。ITAD内で、内部トリップはリンク状態のメカニズムを使用して、任意のトポロジを介してデータベースの更新をフラッディングします。外部的には、TRIPはポイントツーポイントのピアリング関係を使用して、データベース情報を交換します。
To achieve internal synchronization, internal peer connections are configured between LSs of the same ITAD such that the resulting intra-domain LS topology is connected and sufficiently redundant. This is different from BGP's approach that requires all internal peers to be connected in a full mesh topology, which may result in scaling problems. When an update is received from an internal peer, the routes in the update are checked to determine if they are newer than the version already in the database. Newer routes are then flooded to all other peers in the same domain.
内部同期を実現するために、同じITADのLSS間に内部ピア接続が構成され、結果として生じるドメイン内LSトポロジーが接続され、十分に冗長になります。これは、すべての内部ピアを完全なメッシュトポロジに接続する必要があるBGPのアプローチとは異なり、スケーリングの問題を引き起こす可能性があります。内部ピアから更新が受信されると、更新のルートがチェックされ、データベースに既に既にバージョンよりも新しいかどうかが判断されます。その後、新しいルートは、同じドメインの他のすべての仲間に浸水します。
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).
旅行では、ルートは（a）宛先アドレスのセット（アドレスファミリインジケーターとアドレスプレフィックスによって与えられる）の組み合わせとして定義され、（b）アプリケーションプロトコル（SIP、H323など）の組み合わせとして定義されます。一般に、各ルートに関連付けられた追加の属性があります（たとえば、Next-Hopサーバーなど）。
TRIP routes are advertised between a pair of LSs in UPDATE messages. The destination addresses are included in the ReachableRoutes attribute of the UPDATE, while other attributes describe things like the path or egress gateway.
トリップルートは、更新メッセージのLSSのペア間で宣伝されています。宛先アドレスはアップデートのReachableroutes属性に含まれていますが、他の属性はパスや出口ゲートウェイなどのものを説明しています。
If an LS chooses to advertise a TRIP route, it may add to or modify the attributes of the route before advertising it to a peer. TRIP provides mechanisms by which an LS can inform its peer that a previously advertised route is no longer available for use. There are three methods by which a given LS can indicate that a route has been withdrawn from service:
LSが旅行ルートを宣伝することを選択した場合、それをピアに宣伝する前に、ルートの属性に追加または変更することがあります。旅行は、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.
- Retwemroutes属性のルートを更新メッセージに含めるため、関連する宛先を使用できなくなったとマークします。 - Reachableroutes属性に同じ一連の宛先を備えた交換ルートを宣伝します。 - 洪水が使用されていない外部ピアの場合、LS-to-LSピア接続を閉じることができます。これは、LSSのペアがそのピアセッションで互いに宣伝していたすべてのルートから暗黙的に削除されます。内部ピアリングセッションを終了すると、洪水のために同じルートが複数の内部ピアから受け取られた可能性があるため、ピアLSによって宣伝されているルートを必ずしも削除しないことに注意してください。LSが別の内部LSがもはやアクティブではないと判断した場合（他の内部ピアからの更新メッセージのITADトポロジー属性から）、そのLSによってLSに由来するすべてのルートを削除し、決定プロセスを再実行する必要があります。
A TRIP LS processes three types of routes:
旅行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から受信したルートです。 - ローカルルート：ローカルルートは、旅行にローカルに注入されたルートです。構成によって、または別のルーティングプロトコルからのルート再配布によって。
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.
- adj-tribs-in：インバウンドアップデートメッセージから学習されたadj-tribs-inストアルーティング情報。それらの内容は、意思決定プロセスへの入力として利用可能なトリップルートを表しています。これらは、受け取った「未加工の」ルートです。各外部ピアLSおよび各内部LSからのルートは、このデータベースで独立して維持されているため、あるピアからの更新は、別のLSから受け取ったルートに影響しません。ドメイン内のすべてのLSにadj-trib-inがあることに注意してください。これは、LSが直接ピアリングされていないものでもあります。-Ext-Trib：LSごとに1つのExt-Tribデータベースのみがあります。LSは、ルート選択アルゴリズムをすべての外部ルート（外部ピアのadj-tribs-inに保存）およびローカルルート（ローカルLSを表すadj-trib-inに保存することができます）で実行し、最適なルートを選択します。特定の目的地で、それをext-tribに保管します。ext-tribの使用については、セクション10.3.1-loc-trib：loc-tribには、adj-tribsに含まれるルーティング情報にローカルポリシーを適用することにより、LSが選択したローカルトリップルーティング情報が含まれています。 - 内部LSSおよびext-Tribの。 - adj-tribs-out：adj-tribs-outは、地元のLSが外部のピアへの広告のために選択した情報を保存します。adj-tribs-outに保存されているルーティング情報は、ローカルLSの更新メッセージに掲載され、同僚に宣伝されます。
Figure 1 illustrates the relationship between the four parts of the routing information base.
図1は、ルーティング情報ベースの4つの部分の関係を示しています。
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：部族関係
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-in、ext-trib、loc-trib、およびadj-tribs-outを区別しますが、これは、実装がルーティング情報の4つの個別のコピーを維持する必要があることを暗示したり要求したりすることはありません。実装の選択（たとえば、情報の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.
旅行中のルートは、これらの数値の接頭辞になることにより、さまざまな数字を指定します（ルートの正確な定義と構文は5.1.1です）。数字の任意の範囲は、旅行中のルートによって原子的に表現できません。プレフィックス範囲は、原子的にサポートされる範囲の唯一のタイプです。Reachableroutes属性で複数のプレフィックスを使用することで、任意の範囲を実現できます（セクション5.1および5.2を参照）。たとえば、222-XXXXから999-XXXXを通じて、ReachAbleroutes属性にプレフィックス222、223、224、...、23,24、...、3,4、...、9を含めることで表すことができます。
Aggregation is a scaling enhancement used by an LS to reduce the number of routing entries that it has to synchronize with its peers. Aggregation may be performed by an LS when there is a set of routes {R1, R2, ...} in its TRIB such that there exists a less specific route R where every valid destination in R is also a valid destination in {R1, R2, ...} and vice-versa. Section 5 includes a description of how to combine each attribute (by type) on the {R1, R2, ...} routes into an attribute for R.
集約は、LSが使用するスケーリングの強化であり、同業者と同期する必要があるルーティングエントリの数を減らします。集約は、部族に一連のルート{r1、r2、...}のセットがある場合、lsによって実行される場合があります。これにより、Rのすべての有効な宛先が{r1、の有効な宛先でもある特定のルートRが存在するようになります。R2、...}、そしてその逆。セクション5には、{r1、r2、...}ルートの各属性（タイプ別）をRの属性に結合する方法の説明が含まれています。
Note that there is no mechanism within TRIP to communicate that a particular address prefix is not used or valid within a particular address family, and thus that these addresses could be skipped during aggregation. LSs may use methods outside of TRIP to learn of invalid prefixes that may be ignored during aggregation.
特定のアドレスのプレフィックスが特定のアドレスファミリ内で使用または有効ではないことを通知するためのトリップ内にメカニズムがないため、これらのアドレスは集約中にスキップできることに注意してください。LSSは、旅行以外の方法を使用して、集約中に無視される可能性のある無効な接頭辞を知ることができます。
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は集約を実行するために必要はありませんが、小さな部族を維持することが重要な場合はいつでもお勧めします。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.
このセクションでは、旅行で使用されるメッセージ形式について説明します。メッセージは、信頼できる輸送プロトコル接続を介して送信されます。メッセージは、完全に受信した後にのみ処理する必要があります。最大メッセージサイズは4096オクテットです。すべての実装は、この最大メッセージサイズをサポートする必要があります。送信される可能性のある最小のメッセージは、データ部分のないトリップヘッダー、または3オクテットで構成されています。
Each message has a fixed-size header. There may or may not be a data portion following the header, depending on the message type. The layout of the header fields is shown in Figure 2.
各メッセージには固定サイズのヘッダーがあります。メッセージタイプに応じて、ヘッダーに続くデータ部分がある場合とない場合があります。ヘッダーフィールドのレイアウトを図2に示します。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+--------------+----------------+---------------+
| Length | Type |
+--------------+----------------+---------------+
Figure 2: TRIP Header
図2：トリップヘッダー
Length: This 2-octet unsigned integer indicates the total length of the message, including the header, in octets. Thus, it allows one to locate, in the transport-level stream, the beginning of the next message. The value of the Length field must always be at least 3 and no greater than 4096, and may be further constrained depending on the message type. No padding of extra data after the message is allowed, so the Length field must have the smallest value possible given the rest of the message.
長さ：この2-OCTET符号なし整数は、オクテットのヘッダーを含むメッセージの全長を示します。したがって、トランスポートレベルのストリームで、次のメッセージの始まりを見つけることができます。長さフィールドの値は、常に少なくとも3つ、4096以下でなければならず、メッセージの種類に応じてさらに制約される場合があります。メッセージが許可された後に追加データのパディングはないため、メッセージの残りの部分を考慮して、長さフィールドは可能な限り最小の値を持たなければなりません。
Type: This 1-octet unsigned integer indicates the type code of the message. The following type codes are defined:
タイプ：この1-OCTET Unsigned Integerは、メッセージのタイプコードを示します。次のタイプコードが定義されています。
1 - OPEN 2 - UPDATE 3 - NOTIFICATION 4 - KEEPALIVE
1-オープン2-更新3-通知4-キープライブ
After a transport protocol connection is established, the first message sent by each side is an OPEN message. If the OPEN message is acceptable, a KEEPALIVE message confirming the OPEN is sent back. Once the OPEN is confirmed, UPDATE, KEEPALIVE, and NOTIFICATION messages may be exchanged.
トランスポートプロトコル接続が確立された後、各側から送信された最初のメッセージは開かれたメッセージです。オープンメッセージが許容できる場合、オープンを確認するキープライブメッセージが返送されます。オープンが確認されると、更新、KeepAlive、および通知メッセージが交換される場合があります。
The minimum length of the OPEN message is 17 octets (including message header). OPEN messages not meeting this minimum requirement are handled as defined in Section 6.2.
開いたメッセージの最小長は17オクテット（メッセージヘッダーを含む）です。この最小要件を満たしていないオープンメッセージは、セクション6.2で定義されているように処理されます。
In addition to the fixed-size TRIP header, the OPEN message contains the following fields:
固定サイズのトリップヘッダーに加えて、開くメッセージには次のフィールドが含まれています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+--------------+----------------+
| Version | Reserved | Hold Time |
+---------------+---------------+--------------+----------------+
| My ITAD |
+---------------+---------------+--------------+----------------+
| TRIP Identifier |
+---------------+---------------+--------------+----------------+
| Optional Parameters Len |Optional Parameters (variable)...
+---------------+---------------+--------------+----------------+
Figure 3: TRIP OPEN Header
図3：トリップオープンヘッダー
Version: This 1-octet unsigned integer indicates the protocol version of the message. The current TRIP version number is 1.
バージョン：この1-OCTET Unsigned Integerは、メッセージのプロトコルバージョンを示します。現在の旅行バージョン番号は1です。
Hold Time: This 2-octet unsigned integer indicates the number of seconds that the sender proposes for the value of the Hold Timer. Upon receipt of an OPEN message, an LS MUST calculate the value of the Hold Timer by using the smaller of its configured Hold Time and the Hold Time received in the OPEN message. The Hold Time MUST be either zero or at least three seconds. An implementation MAY reject connections on the basis of the Hold Time. The calculated value indicates the maximum number of seconds that may elapse between the receipt of successive KEEPALIVE and/or UPDATE messages by the sender.
ホールド時間：この2-OCTETの署名されていない整数は、送信者がホールドタイマーの値を提案する秒数を示します。開いたメッセージを受信すると、LSは、構成された保留時間の小さいと開いたメッセージで受信された保留時間を使用して、保留タイマーの値を計算する必要があります。保留時間はゼロまたは少なくとも3秒でなければなりません。実装は、保留時間に基づいて接続を拒否する場合があります。計算された値は、送信者による連続したキープライブおよび/または更新メッセージの受領の間に経過する可能性のある最大秒数を示します。
This 4-octet unsigned integer indicates the ITAD number of the sender. The ITAD number must be unique for this domain within this confederation of cooperating LSs.
この4-OCTET符号なし整数は、送信者のITAD番号を示します。ITAD番号は、この協力LSSの連合内でこのドメインにとって一意でなければなりません。
ITAD numbers are assigned by IANA as specified in Section 13. This document reserves ITAD number 0. ITAD numbers from 1 to 255 are designated for private use.
ITAD番号は、セクション13で指定されているIANAによって割り当てられます。このドキュメントはITAD番号0を留保します。
TRIP Identifier: This 4-octet unsigned integer indicates the TRIP Identifier of the sender. The TRIP Identifier MUST uniquely identify this LS within its ITAD. A given LS MAY set the value of its TRIP Identifier to an IPv4 address assigned to that LS. The value of the TRIP Identifier is determined on startup and MUST be the same for all peer connections. When comparing two TRIP identifiers, the TRIP Identifier is interpreted as a numerical 4-octet unsigned integer.
トリップ識別子：この4-OCTET Unsigned Integerは、送信者のトリップ識別子を示します。トリップ識別子は、このLSをITAD内で一意に識別する必要があります。特定のLSは、トリップ識別子の値をそのLSに割り当てられたIPv4アドレスに設定する場合があります。旅行識別子の値は起動時に決定され、すべてのピア接続で同じでなければなりません。2つのトリップ識別子を比較すると、トリップ識別子は数値4-OCTET unsigned整合体として解釈されます。
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-OCTET Unsigned Integerは、オクテットのオプションパラメーターフィールドの全長を示します。このフィールドの値がゼロの場合、オプションのパラメーターは存在しません。
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.
このドキュメントでは、オープンメッセージの次のオプションパラメーターを定義します。
Capability Information uses Optional Parameter type 1. This is an optional parameter used by an LS to convey to its peer the list of capabilities supported by the LS. This permits an LS to learn of the capabilities of its peer LSs. Capability negotiation is defined in Section 8.
機能情報は、オプションのパラメータータイプ1を使用します。これは、LSがサポートする機能のリストをピアに伝えるためにLSが使用するオプションのパラメーターです。これにより、LSはピアLSSの機能を学ぶことができます。能力交渉はセクション8で定義されています。
The parameter contains one or more triples <Capability Code, Capability Length, Capability Value>, where each triple is encoded as shown below:
パラメーターには、1つ以上のトリプル<機能コード、機能の長さ、機能値>が含まれています。各トリプルは、以下に示すようにエンコードされます。
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
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属性内）。アプリケーションプロトコルには、ルートが適用されるアプリケーションをリストします。例として、旅行のルートタイプは<E.164、SIP>であり、SIPプロトコルのE.164宛先のセットを示しています。
The Route Types Supported Capability MAY contain multiple route types in the capability. The number of route types within the capability is the maximum number that can fit given the capability length. The Capability Code is 1 and the length is variable.
ルートタイプサポート機能には、機能に複数のルートタイプが含まれる場合があります。機能内のルートタイプの数は、機能の長さを考慮して適合できる最大数です。機能コードは1で、長さは可変です。
This capability specifies the mode in which the LS will operate with this particular peer. The possible modes are: Send Only mode, Receive Only mode, or Send Receive mode. The default mode is Send Receive mode.
この機能は、LSがこの特定のピアで動作するモードを指定します。可能なモードは、次のようです。モードのみ、受信モードのみ、または受信モードを送信します。デフォルトモードは受信モードの送信です。
In Send Only mode, an LS transmits UPDATE messages to its peer, but the peer MUST NOT transmit UPDATE messages to that LS. If an LS in Send Only mode receives an UPDATE message from its peer, it MUST discard that message, but no further action should be taken.
送信マードのみで、LSは更新メッセージをピアに送信しますが、ピアはそのLSに更新メッセージを送信してはなりません。LS in Send Modeがピアから更新メッセージを受信する場合、そのメッセージを破棄する必要がありますが、それ以上のアクションは実行されません。
The UPDATE messages sent by an LS in Send Only mode to its intra-domain peer MUST include the ITAD Topology attribute whenever the topology changes. A useful application of an LS in Send Only mode with an external peer is to enable gateway registration services.
LSが送信のみモードで送信した更新メッセージは、ドメイン内ピアに送信モードを送信する必要があります。トポロジが変更されるたびにITADトポロジー属性を含める必要があります。外部ピアを使用した送信唯一のモードでのLSの有用なアプリケーションは、ゲートウェイ登録サービスを有効にすることです。
If a service provider terminates calls to a set of gateways it owns, but never initiates calls, it can set its LSs to operate in Send Only mode, since they only ever need to generate UPDATE messages, not receive them. If an LS in Send Receive mode has a peering session with a peer in Send Only mode, that LS MUST set its route dissemination policy such that it does not send any UPDATE messages to its peer.
サービスプロバイダーが所有するゲートウェイのセットへの呼び出しを終了するが、通話を開始することはない場合、LSSはメッセージを受信せずに更新メッセージを生成する必要があるため、送信モードで動作するように設定できます。送信モードのLSがピアインセンドロードモードを使用したピアリングセッションを持っている場合、そのLSは、そのピアに更新メッセージを送信しないようにルート普及ポリシーを設定する必要があります。
In Receive Only mode, the LS acts as a passive TRIP listener. It receives and processes UPDATE messages from its peer, but it MUST NOT transmit any UPDATE messages to its peer. This is useful for management stations that wish to collect topology information for display purposes.
受信のみモードでは、LSはパッシブトリップリスナーとして機能します。ピアから更新メッセージを受信および処理しますが、更新メッセージをピアに送信してはなりません。これは、表示目的でトポロジ情報を収集したい管理ステーションに役立ちます。
The behavior of an LS in Send Receive mode is the default TRIP operation specified throughout this document.
送信モードでのLSの動作は、このドキュメント全体で指定されたデフォルトのトリップ操作です。
The Send Receive capability is a 4-octet unsigned numeric value. It can only take one of the following three values:
送信受信機能は、4-OCTETの符号なしの数値です。次の3つの値のうちの1つだけを取ることができます。
1 - Send Receive mode 2 - Send only mode 3 - Receive Only mode
1-受信モード2の送信2-モードのみを送信 - 受信モードのみモード
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の間にピアリングセッションを確立する必要はありません。Peer LSがオープンメッセージを処理するときにそのような機能の不一致を検出する場合、通知メッセージで応答し、ピアセッションを閉じる必要があります。通知メッセージのエラーコードは、「機能の不一致」に設定する必要があります。
An LS MUST be configured in the same Send Receive mode for all peers.
LSは、すべてのピアに対して同じ送信受信モードで構成する必要があります。
UPDATE messages are used to transfer routing information between LSs. The information in the UPDATE packet can be used to construct a graph describing the relationships between the various ITADs. By applying rules to be discussed, routing information loops and some other anomalies can be prevented.
更新メッセージは、LSS間でルーティング情報を転送するために使用されます。更新パケットの情報は、さまざまなITADの関係を説明するグラフを構築するために使用できます。議論するルールを適用することにより、情報ループとその他のいくつかの異常をルーティングすることを防ぐことができます。
An UPDATE message is used to both advertise and withdraw routes from service. An UPDATE message may simultaneously advertise and withdraw TRIP routes.
更新メッセージは、サービスからルートを宣伝および撤回するために使用されます。更新メッセージは、同時にトリップルートを宣伝および撤回する場合があります。
In addition to the TRIP header, the TRIP UPDATE contains a list of routing attributes as shown in Figure 7. There is no padding between routing attributes.
旅行ヘッダーに加えて、旅行の更新には、図7に示すようにルーティング属性のリストが含まれています。ルーティング属性間にパディングはありません。
+------------------------------------------------+--...
| First Route Attribute | Second Route Attribute | ...
+------------------------------------------------+--...
Figure 7: TRIP UPDATE Format
図7：更新形式をトリップします
The minimum length of an UPDATE message is 3 octets (there are no mandatory attributes in TRIP).
更新メッセージの最小長さは3オクテットです（旅行には必須の属性はありません）。
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.
すべての更新メッセージには、ルーティング属性の変数長シーケンスが存在します。各属性は、変数長のトリプル<属性タイプ、属性長、属性値>です。
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.
属性タイプコードは、属性のタイプを定義します。基本的なトリップ定義属性タイプコードについては、このセクションの後半で説明します。属性は、属性タイプコードの数値順序で更新メッセージに表示する必要があります。属性は、同じ更新メッセージに複数回含めてはなりません。属性フラグは、属性タイプが不明の場合の属性処理を制御するために使用されます。属性フラグは、セクション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を留保します（これらは、コードの最初の3ビットが1に等しいコードです）。このドキュメントは価値0を留保します。属性タイプコード（ベンダー固有の使用のために予約されているもの以外）は、IANAによって制御されます。IANAの考慮事項については、セクション13を参照してください。
The third and the fourth octets of the route attribute contain the length of the attribute value field in octets.
ルート属性の3番目と4番目のオクテットには、オクテットの属性値フィールドの長さが含まれています。
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.
属性の残りのオクテットは属性値を表し、属性フラグと属性タイプコードに従って解釈されます。基本的なサポートされた属性タイプ、その値、およびその用途は、この仕様で定義されています。これらは、ドメイン間とドメイン内の両方のトリップの適切なループフリー操作に必要な属性です。追加の属性は、将来のドキュメントで定義される場合があります。
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.
旅行の属性のセットが時間とともに進化することは明らかです。したがって、認識されていないタイプの属性を処理するためにメカニズムを提供することが不可欠です。認識されていない属性の処理は、属性のフラグフィールドを介して制御されます。認識された属性は、特定の定義に従って処理する必要があります。
The following are the attribute flags defined by this specification: Bit Flag 0 Well-Known Flag 1 Transitive Flag 2 Dependent Flag 3 Partial Flag 4 Link-state Encapsulated Flag
この仕様で定義された属性フラグは次のとおりです。ビットフラグ0有名なフラグ1トランジティブフラグ2依存フラグ3部分フラグ4リンク状態のカプセル化フラグ
The high-order bit (bit 0) of the Attribute Flags octet is the Well-Known Bit. It defines whether the attribute is not well-known (if set to 1) or well-known (if set to 0). Implementations are not required to support not well-known attributes, but MUST support well-known attributes.
属性フラグの高次ビット（ビット0）は、よく知られているビットです。属性がよく知られていない（1に設定されている場合）またはよく知られている（0に設定されている場合）かどうかを定義します。有名な属性をサポートするためには実装は必要ありませんが、よく知られている属性をサポートする必要があります。
The second high-order bit (bit 1) of the Attribute Flags octet is the Transitive bit. It defines whether a not well-known attribute is transitive (if set to 1) or non-transitive (if set to 0). For well-known attributes, the Transitive bit MUST be zero on transmit and MUST be ignored on receipt.
属性フラグの2番目の高次ビット（ビット1）は、推移的なビットです。よく知られていない属性が推移的であるか（1に設定されている場合）か、非転写（0に設定されている場合）かを定義します。よく知られている属性の場合、送信時に推移的なビットはゼロである必要があり、受信時に無視する必要があります。
The third high-order bit (bit 2) of the Attribute Flags octet is the Dependent bit. It defines whether a transitive attribute is 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.
属性フラグの3番目の高次ビット（ビット2）は、依存ビットです。推移的な属性が依存しているか（1に設定されている場合）か（0に設定されている場合）かどうかを定義します。よく知られている属性および非転換属性の場合、依存ビットは無関係であり、送信時にゼロに設定する必要があり、受領時に無視する必要があります。
The fourth high-order bit (bit 3) of the Attribute Flags octet is the Partial bit. It defines whether the information contained in the not well-known transitive attribute is partial (if set to 1) or complete (if set to 0). For well-known attributes and for non-transitive attributes the Partial bit MUST be set to 0 on transmit and MUST be ignored on receipt.
属性フラグの4番目の高次ビット（ビット3）は、部分的なビットです。よく知られていない推移的属性に含まれる情報が部分的であるか（1に設定されている場合）か（0に設定されている場合）かどうかを定義します。よく知られている属性および非転換属性の場合、部分的なビットは送信時に0に設定する必要があり、受領時に無視する必要があります。
The fifth high-order bit (bit 4) of the Attribute Flags octet is the Link-state Encapsulation bit. This bit is only applicable to certain attributes (ReachableRoutes and WithdrawnRoutes) and determines the encapsulation of the routes within those attributes. If this bit is set, link-state encapsulation is used within the attribute. Otherwise, standard encapsulation is used within the attribute. The Link-state Encapsulation technique is described in Section 4.3.2.4. This flag is only valid on the ReachableRoutes and WithdrawnRoutes attributes. It MUST be cleared on transmit and MUST be ignored on receipt for all other attributes.
属性フラグの5番目の高次ビット（ビット4）は、リンク状態のカプセル化ビットです。このビットは、特定の属性（ReachableroutesおよびRetwardroutes）にのみ適用され、それらの属性内のルートのカプセル化を決定します。このビットが設定されている場合、リンク状態のカプセル化は属性内で使用されます。それ以外の場合、標準のカプセル化は属性内で使用されます。リンク状態のカプセル化手法については、セクション4.3.2.4で説明しています。このフラグは、ReachableroutesおよびRetwardroutes属性でのみ有効です。送信時にクリアする必要があり、他のすべての属性に対して受領時に無視する必要があります。
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.
旅行は、中間LSSがルートを伝播する際に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がNext-Hopサーバーを変更していない場合にのみ、認識されていない依存性推移的属性が伝播される場合があります。推移性のバリエーションにより、一部の認識されていない属性がエンドツーエンド（独立した推移的）、一部は隣接するネクストホップサーバー（依存する推移的）の間で運ばれ、その他はピアLSSに制限されることができます。
An LS that passes an unrecognized transitive attribute to a peer MUST set the Partial flag on that attribute. Any LS along a path MAY insert a transitive attribute into a route. If any LS except the originating LS inserts a new independent transitive attribute into a route, then it MUST set the Partial flag on that attribute. If any LS except an LS that modifies the NextHopServer inserts a new dependent transitive attribute into a route, then it MUST set the Partial flag on that attribute. The Partial flag indicates that not every LS along the relevant path has processed and understood the attribute. For independent transitive attributes, the "relevant path" is the path given in the AdvertisementPath attribute. For dependent transitive attributes, the relevant path consists only of those domains thru which this object has passed since the NextHopServer was last modified. The Partial flag in an independent transitive attribute MUST NOT be unset by any other LS along the path. The Partial flag in a dependent transitive attribute MUST be reset whenever the NextHopServer is changed, but MUST NOT be unset by any LS that is not changing the NextHopServer.
ピアに認識されていない推移的な属性を渡すLSは、その属性に部分的なフラグを設定する必要があります。パスに沿ったLSは、推移的な属性をルートに挿入する場合があります。発信元のLSを除くLSが新しい独立したトランシティブ属性をルートに挿入する場合、その属性に部分フラグを設定する必要があります。NexThopserverを変更するLSを除くLSが新しい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.
オリジネータートリップIDとシーケンス番号は、サーバーのコレクション内のルーティング更新の洪水を制御するために使用されます。これらのフィールドは、重複したルートと古いルートを検出するために使用され、他のLSSにさらに伝播されないようにします。これらのフィールドの使用は、セクション10.1で定義されています。
There are no Mandatory attributes in TRIP. However, there are Conditional Mandatory attributes. A conditional mandatory attribute is an attribute, which MUST be included in an UPDATE message if another attribute is included in that message. For example, if an UPDATE message includes a ReachableRoutes attribute, it MUST include an AdvertisementPath attribute as well.
旅行には必須の属性はありません。ただし、条件付き必須属性があります。条件付き必須属性は属性であり、そのメッセージに別の属性が含まれている場合は、更新メッセージに含める必要があります。たとえば、更新メッセージに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.
旅行中の3つのベース属性は、撤回、Reachableroutes、およびITADトポロジーです。更新メッセージにおけるそれらの存在は完全にオプションであり、他の属性から独立しています。
This section summarizes the attributes that may be carried in an UPDATE message. Attributes MUST appear in the UPDATE message in increasing order of the Attribute Type Code. Additional details are provided in Section 5.
このセクションでは、更新メッセージに掲載される属性を要約します。属性は、属性タイプコードの順序を増やして更新メッセージに表示する必要があります。追加の詳細については、セクション5に記載されています。
This attribute lists a set of routes that are being withdrawn from service. The transmitting LS has determined that these routes should no longer be advertised, and is propagating this information to its peers.
この属性には、サービスから撤回されているルートのセットがリストされています。送信LSは、これらのルートが宣伝されなくなったことを決定し、この情報を同僚に伝播しています。
This attribute lists a set of routes that are being added to service. These routes will have the potential to be inserted into the Adj-TRIBs-In of the receiving LS and the route selection process will be applied to them.
この属性には、サービスに追加されているルートのセットがリストされています。これらのルートは、受信LSのadj-tribs-inに挿入される可能性があり、ルート選択プロセスが適用されます。
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.
この属性は、このルーティングされたパスに沿ってメッセージを送信する必要があるエンティティのIDを与えます。次のホップサーバーのIDをホストドメイン名またはIPアドレスとして指定します。次のホップシグナリングサーバーの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は、BGP4のAS_Pathに類似しています[3]。属性は、この広告が通過したドメインのシーケンスを記録します。属性は、ルーティング広告がループしているときに検出するために使用されます。この属性は、このルートに続くメッセージが通過するパスを反映していません。次のホップを各LSによって変更する必要はないため、宛先への実際のパスは、AdvertisementPathのすべてのドメインを通過する必要がない場合があります。
The RoutedPath attribute is analogous to the AdvertisementPath attribute, except that it records the actual path (given by the list of domains) *to* the destinations. Unlike AdvertisementPath, which is modified each time the route is propagated, RoutedPath is only modified when the NextHopServer attribute changes. Thus, it records the subset of the AdvertisementPath which signaling messages following this particular route would traverse.
RoutedPath属性は、実際のパス（ドメインのリストで与えられた） *から *宛先を記録することを除いて、AdvertisementPath属性に類似しています。ルートが伝播されるたびに変更されるAdvertisementPathとは異なり、RoutedPathはNexThopserver属性が変更された場合にのみ変更されます。したがって、この特定のルートに従ってメッセージを信号する広告パスのサブセットを記録します。
The AtomicAggregate attribute indicates that a route may actually include domains not listed in the RoutedPath. If an LS, when presented with a set of overlapping routes from a peer LS, selects a less specific route without selecting the more specific route, then the LS MUST include the AtomicAggregate attribute with the route. An LS receiving a route with an AtomicAggregate attribute MUST NOT make the set of destinations more specific when advertising it to other LSs.
AtomicGregate属性は、ルートにRoutedPathにリストされていないドメインが実際に含まれることを示しています。LSが、ピアLSからのオーバーラップルートのセットが提示された場合、より特定のルートを選択せずに特定のルートを選択する場合、LSにはルートにAtomicAgggregate属性を含める必要があります。AtomicAggregate属性を使用してルートを受信するLSは、他のLSSに宣伝する際に、一連の宛先をより具体的にする必要はありません。
The LocalPreference attribute is an intra-domain attribute used to inform other LSs of the local LS's preference for a given route. The preference of a route is calculated at the ingress to a domain and passed as an attribute with that route throughout the domain. Other LSs within the same ITAD use this attribute in their route selection process. This attribute has no significance between domains.
LocalPreference属性は、特定のルートに対するローカルLSの好みを他のLSSに通知するために使用されるドメイン内属性です。ルートの選好は、イングレス時にドメインへの属性で計算され、ドメイン全体にそのルートを使用して属性として渡されます。同じITAD内の他のLSSは、ルート選択プロセスでこの属性を使用します。この属性は、ドメイン間で重要ではありません。
There may be more than one LS peering relationship between neighboring domains. The MultiExitDisc attribute is used by an LS to express a preference for one link between the domains over another link between the domains. The use of the MultiExitDisc attribute is controlled by local policy.
近隣のドメイン間に複数のLSピアリング関係がある場合があります。MultiExitDisc属性は、LSによって使用され、ドメイン間の別のリンクを介したドメイン間の1つのリンクの好みを表現します。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トポロジー属性は、ドメイン内トポロジーをドメイン内の他のLSSに示すためにLSSが使用するドメイン内属性です。
The ConvertedRoute attribute indicates that an intermediate LS has altered the route by changing the route's Application Protocol.
convertedroute属性は、中間LSがルートのアプリケーションプロトコルを変更することによりルートを変更したことを示しています。
TRIP does not use any transport-based keep-alive mechanism to determine if peers are reachable. Instead, KEEPALIVE messages are exchanged between peers often enough as not to cause the Hold Timer to expire. A reasonable maximum time between KEEPALIVE messages would be one third of the Hold Time interval. KEEPALIVE messages MUST NOT be sent more than once every 3 seconds. An implementation SHOULD adjust the rate at which it sends KEEPALIVE messages as a function of the negotiated Hold Time interval.
旅行では、輸送ベースのキープアライブメカニズムを使用して、ピアが到達可能かどうかを判断しません。代わりに、ホールドタイマーを期限切れにしないように、keepAliveメッセージはピア間で十分なほど十分に交換されます。KeepAliveメッセージ間の合理的な最大時間は、保留時間間隔の3分の1になります。KeepAliveメッセージは、3秒ごとに1回以上送信してはなりません。実装では、交渉された保留時間間隔の関数としてKeepaliveメッセージを送信するレートを調整する必要があります。
If the negotiated Hold Time interval is zero, then periodic KEEPALIVE messages MUST NOT be sent.
ネゴシエートされた保持時間間隔がゼロの場合、定期的なkeepAliveメッセージを送信する必要はありません。
The KEEPALIVE message consists of only a message header and has a length of 3 octets.
KeepAliveメッセージは、メッセージヘッダーのみで構成され、3オクテットの長さがあります。
A NOTIFICATION message is sent when an error condition is detected. The TRIP transport connection is closed immediately after sending a NOTIFICATION message.
エラー条件が検出されたときに通知メッセージが送信されます。トリップトランスポート接続は、通知メッセージを送信した直後に閉じられます。
In addition to the fixed-size TRIP header, the NOTIFICATION message contains the following fields:
固定サイズのトリップヘッダーに加えて、通知メッセージには次のフィールドが含まれています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+--------------+----------------+
| Error Code | Error Subcode | Data... (variable)
+---------------+---------------+--------------+----------------+
Figure 10: TRIP NOTIFICATION Format
図10：トリップ通知形式
Error Code: This 1-octet unsigned integer indicates the type of NOTIFICATION. The following Error Codes have been defined:
エラーコード：この1-OCTET Unsigned Integerは、通知のタイプを示します。次のエラーコードが定義されています。
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
Error Subcode: This 1-octet unsigned integer provides more specific information about the nature of the reported error. Each Error Code may have one or more Error Subcodes associated with it. If no appropriate Error Subcode is defined, then a zero (Unspecific) value is used for the Error Subcode field.
エラーサブコード：この1-OCTET Unsigned Integerは、報告されたエラーの性質に関するより具体的な情報を提供します。各エラーコードには、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-悪い旅行識別子。4-サポートされていないオプションパラメーター。5-許容できない保留時間。6-サポートされていない機能。7-機能の不一致。
UPDATE Message Error Subcodes: 1 - Malformed Attribute List. 2 - Unrecognized Well-known Attribute. 3 - Missing Well-known Mandatory Attribute. 4 - Attribute Flags Error. 5 - Attribute Length Error. 6 - Invalid Attribute.
メッセージエラーサブコードを更新：1-奇形属性リスト。2-認識されていない有名な属性。3-有名な必須属性がありません。4-属性フラグエラー。5-属性長エラー。6-無効な属性。
Data: This variable-length field is used to diagnose the reason for the NOTIFICATION. The contents of the Data field depend upon the Error Code and Error Subcode.
データ：この可変長フィールドは、通知の理由を診断するために使用されます。データフィールドの内容は、エラーコードとエラーサブコードによって異なります。
Note that the length of the data can be determined from the message length field by the formula:
データの長さは、式でメッセージの長さフィールドから決定できることに注意してください。
Data Length = Message Length - 5
データの長さ=メッセージ長-5
The minimum length of the NOTIFICATION message is 5 octets (including message header).
通知メッセージの最小長は5オクテット（メッセージヘッダーを含む）です。
This section provides details on the syntax and semantics of each TRIP UPDATE attribute.
このセクションでは、各旅行更新属性の構文とセマンティクスの詳細を説明します。
Conditional Mandatory: False. Required Flags: Well-known. Potential Flags: Link-State Encapsulation (when flooding). TRIP Type Code: 1
条件付き必須：FALSE。必須フラグ：よく知られています。潜在的なフラグ：リンク状態のカプセル化（洪水時の場合）。トリップタイプコード：1
The WithdrawnRoutes specifies a set of routes that are to be removed from service by the receiving LS(s). The set of routes MAY be empty, indicated by a length field of zero.
撤回されたルートは、受信LSによってサービスから削除されるルートのセットを指定します。ルートのセットは空で、ゼロの長さフィールドで示されている場合があります。
The WithdrawnRoutes Attribute encodes a sequence of routes in its value field. The format for individual routes is given in Section 5.1.1.1. The WithdrawnRoutes Attribute lists the individual routes sequentially with no padding as shown in Figure 11. Each route includes a length field so that the individual routes within the attribute can be delineated.
retureadroutes属性は、その値フィールドの一連のルートをエンコードします。個々のルートの形式は、セクション5.1.1.1に記載されています。returedroutes属性は、図11に示すように、パディングなしで個々のルートを順番にリストします。各ルートには、属性内の個々のルートを描写できるように長さフィールドが含まれています。
+---------------------+---------------------+...
| WithdrawnRoute1... | WithdrawnRoute2... |...
+---------------------+---------------------+...
Figure 11: WithdrawnRoutes Format
図11：撤回されたルート形式
The generic format for a TRIP route is given in Figure 12.
旅行ルートの汎用形式を図12に示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+--------------+----------------+
| Address Family | Application Protocol |
+---------------+---------------+--------------+----------------+
| Length | Address (variable) ...
+---------------+---------------+--------------+----------------+
Figure 12: Generic TRIP Route Format
図12：一般的なトリップルート形式
Address Family: The address family field gives the type of address for the route. Three address families are defined in this Section:
アドレスファミリ：アドレスファミリフィールドは、ルートのアドレスの種類を提供します。このセクションでは、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を留保します。このドキュメントは、ベンダー固有のアプリケーション用のアドレスファミリーコード32768-65535を留保します（これらは1に等しいコード値の最初のビットを持つコードです）。追加の住所ファミリは、将来定義される場合があります。住所ファミリコードの割り当ては、IANAによって制御されます。IANAの考慮事項については、セクション13を参照してください。
Application Protocol: The application protocol gives the protocol for which this routing table is maintained. The currently defined application protocols are:
アプリケーションプロトコル：アプリケーションプロトコルは、このルーティングテーブルが維持されるプロトコルを提供します。現在定義されているアプリケーションプロトコルは次のとおりです。
Code Protocol
1 SIP
2 H.323-H.225.0-Q.931
3 H.323-H.225.0-RAS
4 H.323-H.225.0-Annex-G
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番号、国家数、ローカル番号、および個人番号のスーパーセットです。また、一部の国/地域での数の移植性と組み合わせて使用される小数点以下のルーティング数を表すためにも使用できます。一連の電話番号は、10進ルーティング番号のプレフィックスで指定されます。10進ルーティング番号のプレフィックスは、各数字がASCII文字表現によってエンコードされた一連の数字で表されます。このルーティングオブジェクトは、このプレフィックスから始まるすべての電話番号をカバーします。10進ルーティング番号のプレフィックスの構文は次のとおりです。
Decimal-routing-number = *decimal-digit
decimal-digit = DECIMAL-DIGIT
DECIMAL-DIGIT = "0"|"1"|"2"|"3"|"4"|"5"|"6"|"7"|"8"|"9"
This DECIMAL Routing Number prefix is not bound in length. This format is similar to the format for a global telephone number as defined in SIP [8] without visual separators and without the "+" prefix for international numbers. This format facilitates efficient comparison when using TRIP to route SIP or H323, both of which use character based representations of phone numbers. The prefix length 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.
この10進ルーティング番号のプレフィックスは、長さがバインドされていません。この形式は、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"
Note the difference in alphabets between Decimal Routing Numbers and PentaDecimal Routing Numbers. A PentaDecimal Routing Number prefix is not bound in length.
10進ルーティング数と五角形のルーティング番号の間のアルファベットの違いに注意してください。五角形のルーティング番号のプレフィックスの長さはバインドされていません。
Note that the address family, which suits the routing numbers of a specific country/region depends on the alphabets used for routing numbers in that country/region. For example, North American routing numbers SHOULD use the Decimal Routing Numbers address family, because their alphabet is limited to the digits "0" through "9". Another example, in most European countries routing numbers use the alphabet "0" through "9" and "A" through "E", and hence these countries SHOULD use the PentaDecimal Routing Numbers address family.
特定の国/地域のルーティング番号に適した住所ファミリは、その国/地域のルーティング番号に使用されるアルファベットに依存することに注意してください。たとえば、北米のルーティング番号は、アルファベットが「0」から「9」までの数字「0」に制限されているため、小数点以下のルーティング番号を使用する必要があります。別の例として、ほとんどのヨーロッパ諸国では、ルーティング数がアルファベット「0」から「9」と「a」を「e」を使用しているため、これらの国は五角形のルーティング番号を使用する必要があります。
The E.164 Numbers address family is dedicated to fully qualified E.164 numbers. A set of telephone numbers is specified by a E.164 prefix. E.164 prefixes are represented by a string of digits, each digit encoded by its ASCII character representation. This routing object covers all phone numbers starting with this prefix. The syntax for the E.164 prefix is:
e.164番号アドレスファミリは、完全に資格のあるE.164番号に専念しています。一連の電話番号は、E.164プレフィックスによって指定されています。E.164プレフィックスは、各数字がASCII文字表現によってエンコードされた一連の数字で表されます。このルーティングオブジェクトは、このプレフィックスから始まるすべての電話番号をカバーします。E.164プレフィックスの構文は次のとおりです。
E164-number = *e164-digit
E164-digit = E164-DIGIT
E164-DIGIT = "0"|"1"|"2"|"3"|"4"|"5"|"6"|"7"|"8"|"9"
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番号アドレスファミリは、可能な限り使用する必要があります。小数点以下のルーティング番号アドレスファミリは、完全に拡張された完全に資格のある電話番号を宣伝したくないプライベート番号の計画またはアプリケーションの場合に使用できます。10進ルーティング番号を使用して、非適格なプレフィックスを宣伝するために、ITADの境界でプレフィックスを操作する（拡張された）必要がある場合があります。これにより、ITADボーダーLSに大きな複雑さが追加されます。これは、独自のITADで使用されている形式からピアITADで使用される形式に接頭辞をマッピングする必要があるためです。
Conditional Mandatory: False. Required Flags: Well-known. Potential Flags: Link-State Encapsulation (when flooding). TRIP Type Code: 2
条件付き必須：FALSE。必須フラグ：よく知られています。潜在的なフラグ：リンク状態のカプセル化（洪水時の場合）。トリップタイプコード：2
The ReachableRoutes attribute specifies a set of routes that are to be added to service by the receiving LS(s). The set of routes MAY be empty, as indicated by setting the length field to zero.
Reachableroutes属性は、受信LSによってサービスに追加されるルートのセットを指定します。長さフィールドをゼロに設定することで示されるように、ルートのセットは空になる場合があります。
The ReachableRoutes Attribute has the same syntax as the WithdrawnRoutes Attribute. See Section 5.1.1.
ReachablerOutes属性は、Retwedroutes属性と同じ構文を持っています。セクション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.
この仕様の範囲外の方法により、ルートが旅行に注入されます。考えられる方法には、フロントエンドプロトコル、ドメイン内ルーティングプロトコル、または静的構成が含まれます。
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.
複数のルートを集約するには、集約するリーチアブラウトのセットを組み合わせて、より特定のセットを形成する必要があります。
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.
旅行内には、特定のアドレスプレフィックスが使用されていないため、これらのアドレスを集約中にスキップできることを伝えるためのメカニズムはありません。LSSは、旅行以外の方法を使用して、集約中に無視される可能性のある無効な接頭辞を知ることができます。
If an LS advertises an aggregated route, it MUST include the AtomicAggregate attribute.
LSが集約されたルートを宣伝する場合、AtomicGregate属性を含める必要があります。
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が宣伝するルートのアプリケーションプロトコルを変更する場合、更新メッセージに変換された属性を含める必要があります。
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の10進ルーティング/E.164プレフィックス、または長さnの15の五ペンタ測量ルーティングプレフィックスが必要です。ただし、LSが接頭辞が無効な小数ルーティング/E.164プレフィックス、または五角形ルーティングプレフィックスであることを認識している場合、LSはこのプレフィックスをスキップすることで集約することができます。たとえば、10進ルーティングのプレフィックス19191が存在しないことがわかっている場合、LSは19191なしで1919年まで集約できます。LSがブラックホールを認識している方法は、旅行の範囲内ではありませんが、LSがそのような知識を持っている場合、集約するときに知識を使用できます。
Conditional Mandatory: True (if ReachableRoutes and/or WithdrawnRoutes attribute is present). Required Flags: Well-known. Potential Flags: None. TRIP Type Code: 3.
条件付き必須：true（reachableroutesおよび/またはretureadroutes属性が存在する場合）。必須フラグ：よく知られています。潜在的なフラグ：なし。トリップタイプコード：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.
一般性については、Next-Hopサーバーのアドレスにはさまざまなタイプ（ドメイン名、IPv4、IPv6など）があります。Nexthopserver属性には、ITAD番号のNext-Hopサーバー、長さフィールド、およびNext-Hopの名前または住所が含まれます。
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は、次のホップのドメインを示します。長さフィールドは、サーバーフィールドにオクテットの数を与え、サーバーフィールドには次のホップサーバーの名前またはアドレスが含まれています。サーバーフィールドは、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
If the port is empty or not given, the default port is assumed (e.g., port 5060 if the application protocol is SIP).
ポートが空であるか、指定されていない場合、デフォルトのポートが想定されます（アプリケーションプロトコルがSIPの場合、ポート5060など）。
When an LS originates a routing object into TRIP, it MUST include a NextHopServer within its domain. The NextHopServer could be an address of the egress gateway or of a signaling proxy.
LSがルーティングオブジェクトをトリップに発信する場合、ドメイン内にnexthopserverを含める必要があります。nexthopserverは、出力ゲートウェイまたはシグナル伝達プロキシのアドレスである可能性があります。
LS policy may prefer certain next-hops or next-hop domains over others.
LSポリシーは、他の人よりも特定のNext-HopまたはNext-Hopドメインを好む場合があります。
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.
条件付き必須：true（reachableroutesおよび/またはretureadroutes属性が存在する場合）。必須フラグ：よく知られています。潜在的なフラグ：なし。トリップタイプコード：4。
This attribute identifies the ITADs through which routing information carried in an advertisement has passed. The AdvertisementPath attribute is analogous to the AS_PATH attribute in BGP. The attributes differ in that BGP's AS_PATH also reflects the path to the destination. In TRIP, not every domain need modify the next-hop, so the AdvertisementPath may include many more hops than the actual path to the destination. The RoutedPath attribute (Section 5.5) reflects the actual signaling path to the destination.
この属性は、広告に掲載されたルーティング情報が通過したITADを識別します。AdvertisementPath属性は、BGPのAS_PATH属性に類似しています。属性は、BGPのAS_Pathが宛先へのパスを反映しているという点で異なります。旅行では、すべてのドメインが次のホップを変更する必要があるわけではないため、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
The path segment length is a 1-octet long field containing the number of ITADs in the path segment value field.
パスセグメントの長さは、パスセグメント値フィールドにITADの数を含む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.
パスセグメント値フィールドには、1つ以上のITAD番号が含まれており、それぞれが4オクテットの長いフィールドとしてエンコードされています。ITAD番号は、インターネットテレフォニー管理ドメインを独自に識別し、IANAから取得する必要があります。IANAからITAD番号を取得する手順については、セクション13を参照してください。
When an LS originates a route then:
LSがルートを発信する場合、
- The originating LS shall include its own ITAD number in the AdvertisementPath attribute of all advertisements sent to LSs located in neighboring ITADs. In this case, the ITAD number of the originating LS's ITAD will be the only entry in the AdvertisementPath attribute. - The originating LS shall include an empty AdvertisementPath attribute in all advertisements sent to LSs located in its own ITAD. An empty AdvertisementPath attribute is one whose length field contains the value zero.
- 生まれたLSには、隣接するITADにあるLSSに送信されたすべての広告のAdvertisementPath属性に独自のITAD番号を含めるものとします。この場合、発生するLSのITADのITAD番号は、AdvertisementPath属性の唯一のエントリになります。 - 発生するLSには、独自のITADにあるLSSに送信されるすべての広告に空のAdvertisementPath属性を含めるものとします。空のAdvertisementPath属性は、長さフィールドに値ゼロが含まれるものです。
The AdvertisementPath may be used for route selection. Possible criteria to be used are the number of hops on the path and the presence or absence of particular ITADs on the path.
AdvertisementPathは、ルートの選択に使用できます。使用される可能性のある基準は、パス上のホップ数と、パス上の特定のITADの存在または不在です。
As discussed in Section 10, the AdvertisementPath is used to prevent routing information from looping. If an LS receives a route with its own ITAD already in the AdvertisementPath, the route MUST be discarded.
セクション10で説明したように、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番号です。対応する<タイプ、値>が同じ場合、2つのITADが同じと言われています。
If the routes to be aggregated have different path attributes, then the aggregated path attribute shall satisfy all of the following conditions:
集約されるルートに異なるパス属性がある場合、集約されたパス属性は次のすべての条件を満たすものとします。
- All pairs of the type AP_SEQUENCE in the aggregated path MUST appear in all of the paths of routes to be aggregated. - All pairs of the type AP_SET in the aggregated path MUST appear in at least one of the paths of the initial set (they may appear as either AP_SET or AP_SEQUENCE types). - For any pair X of the type AP_SEQUENCE that precedes pair Y in the aggregated path, X precedes Y in each path of the initial set that contains Y, regardless of the type of Y. - No pair with the same value shall appear more than once in the aggregated path, regardless of the pair's type.
- 集約されたパスのタイプAP_シーケンスのすべてのペアは、集約するルートのすべてのパスに表示される必要があります。 - 集約されたパスのタイプAP_SETのすべてのペアは、初期セットの少なくとも1つのパスの1つに表示される必要があります（AP_SETまたはAP_Sequenceタイプのいずれかとして表示される場合があります）。 - 集約されたパスのペアyに先行するタイプap_シーケンスの任意のペア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:
2つのパスを集約するためのアルゴリズムの例は、次のように機能します。
- Identify the ITADs (as defined in Section 5.4.1) within each path attribute that are in the same relative order within both path attributes. Two ITADs, X and Y, are said to be in the same order if either X precedes Y in both paths, or if Y precedes X in both paths. - The aggregated path consists of ITADs identified in (a) in exactly the same order as they appear in the paths to be aggregated. If two consecutive ITADs identified in (a) do not immediately follow each other in both of the paths to be aggregated, then the intervening ITADs (ITADs that are between the two consecutive ITADs that are the same) in both attributes are combined into an AP_SET path segment that consists of the intervening ITADs from both paths; this segment is then placed in between the two consecutive ITADs identified in (a) of the aggregated attribute. If two consecutive ITADs identified in (a) immediately follow each other in one attribute, but do not follow in another, then the intervening ITADs of the latter are combined into an AP_SET path segment; this segment is then placed in between the two consecutive ITADs identified in (a) of the aggregated path.
- 両方のパス属性内で同じ相対順序である各パス属性内のITAD（セクション5.4.1で定義されている）を識別します。2つのITAD、xとyは、どちらかのxが両方のパスでyに先行する場合、または両方のパスでyの前にyの場合、同じ順序であると言われています。 - 集約されたパスは、（a）で識別されたITADで構成されています。（a）で識別された2つの連続したITADが両方のパスを集約する両方のパスですぐに互いに続かない場合、両方の属性の介在性ITAD（同じ2つの連続したITADの間にあるITAD）がAP_SETに結合されます。両方のパスから介在するITADで構成されるパスセグメント。このセグメントは、集約された属性の（a）で特定された2つの連続したITADの間に配置されます。（a）で2つの連続したITADが識別された場合、1つの属性ですぐに互いに続きますが、別の属性に従わない場合、後者の介在するITADはAP_SETパスセグメントに結合されます。このセグメントは、集約された経路の（a）で特定された2つの連続したITADの間に配置されます。
If as a result of the above procedure a given ITAD number appears more than once within the aggregated path, all but the last instance (rightmost occurrence) of that ITAD number should be removed from the aggregated path.
上記の手順の結果として、特定のITAD数が集約されたパス内に複数回表示される場合、そのITAD番号を除く最後のインスタンス（右端の発生）を除くすべてが集約パスから削除される必要があります。
When an LS propagates a route which it has learned from another LS, it shall modify the route's AdvertisementPath attribute based on the location of the LS to which the route will be sent.
LSが別のLSから学んだルートを伝播する場合、ルートが送信されるLSの場所に基づいて、ルートのAdvertisementPath属性を変更するものとします。
- When a LS advertises a route to another LS located in its own ITAD, the advertising LS MUST NOT modify the AdvertisementPath attribute associated with the route. - When a LS advertises a route to an LS located in a neighboring ITAD, then the advertising LS MUST update the AdvertisementPath attribute as follows:
- LSが独自のITADにある別のLSへのルートを広告する場合、広告LSはルートに関連付けられたAdvertisementPath属性を変更してはなりません。-LSが隣接するITADにあるLSへのルートを広告する場合、広告LSは次のようにAdvertisementPath属性を更新する必要があります。
* If the first path segment of the AdvertisementPath is of type AP_SEQUENCE, the local system shall prepend its own ITAD number as the last element of the sequence (put it in the leftmost position).
* AdvertisementPathの最初のパスセグメントがタイプAP_シーケンスである場合、ローカルシステムは、シーケンスの最後の要素として独自のITAD番号をプレイしなければなりません（左端の位置に置きます）。
* If the first path segment of the AdvertisementPath is of type AP_SET, the local system shall prepend a new path segment of type AP_SEQUENCE to the AdvertisementPath, including its own ITAD number in that segment.
* AdvertisementPathの最初のパスセグメントがタイプAP_SETの場合、ローカルシステムは、そのセグメントの独自のITAD番号を含むAdvertisementPathのタイプAP_シーケンスの新しいパスセグメントを事前に事前にプレイしなければなりません。
Conditional Mandatory: True (if ReachableRoutes attribute is present). Required Flags: Well-known. Potential Flags: None. TRIP Type Code: 5.
条件付き必須：true（reachableroutes属性が存在する場合）。必須フラグ：よく知られています。潜在的なフラグ：なし。トリップタイプコード：5。
This attribute identifies the ITADs through which messages sent using this route would pass. The ITADs in this path are a subset of those in the AdvertisementPath.
この属性は、このルートを使用して送信されたメッセージが通過するITADを識別します。このパスの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には、隣接するITADにあるLSSに送信されるすべての広告のRoutedPath属性に独自のITAD番号を含めるものとします。この場合、RoutedPath属性の唯一のエントリの発信元LSのITADのITAD番号が発生します。 - 発生するLSには、独自のITADにあるLSSに送信されるすべての広告に空のRoutedPath属性を含めるものとします。空のRoutedPath属性は、長さフィールドに値ゼロを含むものです。
The RoutedPath MAY be used for route selection, and in most cases is preferred over the AdvertisementPath for this role. Some possible criteria to be used are the number of hops on the path and the presence or absence of particular ITADs on the path.
RoutedPathはルートの選択に使用される場合があり、ほとんどの場合、この役割に対してAdvertisementPathよりも好まれます。使用される可能性のある基準は、パス上のホップ数と、パス上の特定のITADの存在または不在です。
The rules for aggregating RoutedPath attributes are given in Section 5.4.4.1 and 5.4.4.2, where the term "path" used in Section 5.4.4.1 and 5.4.4.2 is understood to mean RoutedPath.
RoutedPath属性を集約するためのルールは、セクション5.4.4.1および5.4.4.2に記載されています。ここで、セクション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の位置に基づいてルートルートパス属性を変更します。
- 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の最初のパスセグメントがタイプAP_シーケンスである場合、ローカルシステムは、シーケンスの最後の要素として独自のITAD番号を前提とします（左端の位置に置きます）。
* If the first path segment of the RoutedPath is of type AP_SET, the local system shall prepend a new path segment of type AP_SEQUENCE to the RoutedPath, including its own ITAD number in that segment.
* RoutedPathの最初のパスセグメントがタイプAP_SETの場合、ローカルシステムは、そのセグメントの独自のITAD番号を含む、RoutedPathへのタイプAP_シーケンスの新しいパスセグメントを準備するものとします。
Conditional Mandatory: False. Required Flags: Well-known. Potential Flags: None. TRIP Type Code: 6.
条件付き必須：FALSE。必須フラグ：よく知られています。潜在的なフラグ：なし。トリップタイプコード：6。
The AtomicAggregate attribute indicates that a route may traverse domains not listed in the RoutedPath. If an LS, when presented with a set of overlapping routes from a peer LS, selects the less specific route without selecting the more specific route, then the LS includes the AtomicAggregate attribute with the routing object.
AtomicGregate属性は、ルートがRoutedPathにリストされていないドメインを横断する可能性があることを示します。LSが、ピアLSからの重複ルートのセットが表示された場合、より特定のルートを選択せずに特定のルートを選択する場合、LSにはRoutingオブジェクトのAtomicAggregate属性が含まれます。
This attribute has length zero (0); the value field is empty.
この属性には長さゼロ（0）があります。値フィールドは空です。
Routes are never originated with the AtomicAggregate attribute.
ルートは、Atomic Aggregate属性から発生することはありません。
The AtomicAggregate attribute may be used in route selection - it indicates that the RoutedPath may be incomplete.
AtomicGregate属性は、ルート選択に使用できます - ルーティングパスが不完全である可能性があることを示しています。
If any of the routes to aggregate has the AtomicAggregate attribute, then so MUST the resultant aggregate.
集合体へのルートのいずれかがAtomicGgregate属性を持っている場合、結果の集合体も必要です。
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にはルーティングオブジェクトにAtomicAgggregate属性を含める必要があります（まだ存在していません）。
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.
AtomicGregate属性を使用してルーティングオブジェクトを受信するLSは、他のLSSに宣伝する際に一連の宛先をより具体的にする必要はなく、このオブジェクトをピアLSに伝播するときに属性を削除してはなりません。
Conditional Mandatory: False. Required Flags: Well-known. Potential Flags: None. TRIP Type Code: 7.
条件付き必須：FALSE。必須フラグ：よく知られています。潜在的なフラグ：なし。トリップタイプコード：7。
The LocalPreference attribute is only used intra-domain, it indicates the local LS's preference for the routing object to other LSs within the same domain. This attribute MUST NOT be included when communicating to an LS in another domain, and MUST be included over intra-domain links.
LocalPreference属性はドメイン内のみ使用され、同じドメイン内の他のLSSに対するルーティングオブジェクトに対するローカルLSの好みを示します。この属性は、別のドメインのLSと通信するときに含めることはできず、ドメイン内リンクに含める必要があります。
The LocalPreference attribute is a 4-octet unsigned numeric value. A higher value indicates a higher preference.
LocalPreference属性は、4-OCTETの符号なしの数値です。より高い値は、より高い好みを示します。
Routes MUST NOT be originated with the LocalPreference attribute to inter-domain peers. Routes to intra-domain peers MUST be originated with the LocalPreference attribute.
ルートは、ドメイン間のピアへのLocalPreference属性から発信してはなりません。ドメイン内ピアへのルートは、LocalPreference属性から発信する必要があります。
The LocalPreference attribute allows one LS in a domain to calculate a preference for a route, and to communicate this preference to other LSs within the domain.
LocalPreference属性により、ドメイン内の1つのLSがルートの好みを計算し、この設定をドメイン内の他のLSSに伝えることができます。
The LocalPreference attribute is not affected by aggregation.
LocalPreference属性は、集約の影響を受けません。
An LS MUST include the LocalPreference attribute when communicating with peer LSs within its own domain. An LS MUST NOT include the LocalPreference attribute when communicating with LSs in other domains. LocalPreference attributes received from inter-domain peers MUST be ignored.
LSには、独自のドメイン内でピアLSSと通信する際に、LocalPreference属性を含める必要があります。LSは、他のドメインでLSSと通信するときにLocalPreference属性を含めてはなりません。ドメイン間のピアから受け取ったLocalPreference属性は無視する必要があります。
Conditional Mandatory: False. Required Flags: Well-known. Potential Flags: None. TRIP Type Code: 8.
条件付き必須：FALSE。必須フラグ：よく知られています。潜在的なフラグ：なし。トリップタイプコード：8。
When two ITADs are connected by more than one set of peers, the MultiExitDisc attribute may be used to specify preferences for routes received over one of those links versus routes received over other links. The MultiExitDisc parameter is used only for route selection.
2つのITADが複数のピアセットで接続されている場合、MultiEXITDISC属性を使用して、他のリンクで受信したリンクのいずれかで受信したルートの設定を指定できます。MultiExitDiscパラメーターは、ルート選択にのみ使用されます。
The MultiExitDisc attribute carries a 4-octet unsigned numeric value. A higher value represents a more preferred routing object.
MultiExitDisc属性には、4-OCTETの符号なし数値値があります。より高い値は、より好ましいルーティングオブジェクトを表します。
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属性は、2つのドメイン間に複数のリンクがある場合に好みを表すために使用されます。他のすべての要因が等しい場合、より高い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はマルチXitdiscをそのドメイン内の他のLSSに伝播する場合があります。MultiExitDisc属性は、他のドメインのLSSに伝播してはなりません。
An LS may add the MultiExitDisc attribute when propagating routing objects to an LS in another domain. The inclusion of the MultiExitDisc attribute is a matter of policy, as is the value of the attribute.
LSは、ルーティングオブジェクトを別のドメイン内のLSに伝播するときに、MultiExitDisc属性を追加する場合があります。属性の値と同様に、MultiExitDisc属性を含めることはポリシーの問題です。
Conditional Mandatory: False. Required Flags: Not Well-Known, Independent Transitive. Potential Flags: None. TRIP Type Code: 9.
条件付き必須：FALSE。必要なフラグ：よく知られていない、独立した推移的。潜在的なフラグ：なし。トリップタイプコード：9。
A community is a group of destinations that share some common property.
コミュニティは、共通の財産を共有する目的地のグループです。
The Communities attribute is used to group destinations so that the routing decision can be based on the identity of the group. Using the Communities attribute should significantly simplify the distribution of routing information by providing an administratively defined aggregation unit.
コミュニティ属性は、ルーティングの決定がグループの身元に基づいているように、目的地をグループ化するために使用されます。コミュニティ属性を使用すると、管理上定義された集約ユニットを提供することにより、ルーティング情報の分布を大幅に簡素化する必要があります。
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.
コミュニティの別の使用例属性は、集約を使用することです。多くの場合、集約ルートと、骨材を形成するために使用されたコンポーネントのより特異的ルートの両方を宣伝することが役立ちます。これらの情報コンポーネントは、近隣の旅行ピア、そしておそらく隣接するトリップピアの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の数が予約されています。
The following communities have global significance and their operation MUST be implemented in any Community attribute-aware TRIP LS.
以下のコミュニティには世界的な重要性があり、その運用はコミュニティ属性を認識している旅行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）。この値を含むコミュニティ属性を備えた受信ルートは、受信旅行の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.
条件付き必須：FALSE。必要なフラグ：よく知られているリンク状態がカプセル化されています。潜在的なフラグ：なし。トリップタイプコード：10。
Within an ITAD, each LS must know the status of other LSs so that LS failure can be detected. To do this, each LS advertises its internal topology to other LSs within the domain. When an LS detects that another LS is no longer active, the information sourced by that LS can be deleted (the Adj-TRIB-In for that peer may be cleared). The ITAD Topology attribute is used to communicate this information to other LSs within the domain.
ITAD内では、各LSは、LS障害を検出できるように、他のLSSの状態を知っている必要があります。これを行うために、各LSは内部トポロジをドメイン内の他のLSSに宣伝します。LSが別のLSがもはやアクティブではないことを検出すると、そのLSによって供給される情報は削除できます（そのピアのadj-trib-inはクリアされる可能性があります）。ITADトポロジー属性は、この情報をドメイン内の他のLSSに伝えるために使用されます。
An LS MUST send a topology update each time it detects a change in its internal peer set. The topology update may be sent in an UPDATE message by itself or it may be piggybacked on an UPDATE message which includes ReachableRoutes and/or WithdrawnRoutes information.
LSは、内部ピアセットの変更を検出するたびにトポロジアップデートを送信する必要があります。トポロジの更新は、更新メッセージでそれ自体で送信される場合があります。または、ReachablerOutesおよび/またはreturedRoutes情報を含む更新メッセージで豚バックされる場合があります。
When an LS receives a topology update from an internal LS, it MUST recalculate which LSs are active within the ITAD via a connectivity algorithm on the topology.
LSが内部LSからトポロジアップデートを受信した場合、トポロジの接続アルゴリズムを介してITAD内でアクティブなLSSを再計算する必要があります。
The ITAD Topology attribute indicates the LSs with which the LS is currently peering. The attribute consists of a list of the TRIP Identifiers with which the LS is currently peering, the format is given in Figure 15. This attribute MUST use the link-state encapsulation as defined in Section 4.3.2.4.
ITADトポロジー属性は、LSが現在ピアリングしているLSSを示しています。属性は、LSが現在ピアリングしているトリップ識別子のリストで構成されており、形式を図15に示します。この属性は、セクション4.3.2.4で定義されているリンク状態のカプセル化を使用する必要があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+--------------+----------------+
| TRIP Identifier 1 |
+---------------+---------------+--------------+----------------+
| TRIP Identifier 2 ... |
+---------------+---------------+--------------+----------------+
Figure 15: ITAD Topology Syntax
図15：ITADトポロジー構文
The ITAD Topology attribute is independent of any routes in the UPDATE. Whenever the set of internal peers of an LS changes, it MUST create an UPDATE with the ITAD Topology Attribute included listing the current set of internal peers. The LS MUST include this attribute in the first UPDATE it sends to a peer after the peering session is established.
ITADトポロジー属性は、アップデート内の任意のルートとは無関係です。LSの内部ピアのセットが変更されるたびに、ITADトポロジ属性を使用して更新を作成する必要があります。LSは、ピアリングセッションが確立された後、ピアに送信する最初のアップデートにこの属性を含める必要があります。
This attribute is independent of any routing information in the UPDATE. When an LS receives an UPDATE with an ITAD Topology attribute, it MUST compute the set of LSs currently active in the domain by performing a connectivity test on the ITAD topology as given by the set of originated ITAD Topology attributes. The LS MUST locally purge the Adj-TRIB-In for any LS that is no longer active in the domain. The LS MUST NOT propagate this purging information to other LSs as they will make a similar decision.
この属性は、アップデート内のルーティング情報に依存しません。LSがITADトポロジー属性を使用して更新を受信する場合、Originated ITADトポロジ属性のセットで与えられたITADトポロジの接続性テストを実行することにより、現在ドメインで現在アクティブなLSSのセットを計算する必要があります。LSは、ドメインでアクティブではなくなったLSについて、Adj-Trib-inをローカルにパージする必要があります。LSは、同様の決定を下すため、このパージ情報を他のLSSに伝播してはなりません。
This information is not aggregated.
この情報は集約されていません。
An LS MUST ignore the attribute if received from a peer in another domain. An LS MUST NOT send this attribute to an inter-domain peer.
LSは、別のドメインのピアから受信した場合、属性を無視する必要があります。LSは、この属性をドメイン間ピアに送信してはなりません。
Conditional Mandatory: False. Required Flags: Well-known. Potential Flags: None. TRIP Type Code: 12.
条件付き必須：FALSE。必須フラグ：よく知られています。潜在的なフラグ：なし。トリップタイプコード：12。
The ConvertedRoute attribute indicates that an intermediate LS has altered the route by changing the route's Application Protocol. For example, if an LS receives a route with Application Protocol X and changes the Application Protocol to Y before advertising the route to an external peer, the LS MUST include the ConvertedRoute attribute. The attribute is an indication that the advertised application protocol will not be used end-to-end, i.e., the information advertised about this route is not complete.
convertedroute属性は、中間LSがルートのアプリケーションプロトコルを変更することによりルートを変更したことを示しています。たとえば、LSがアプリケーションプロトコルXを使用してルートを受信し、外部ピアへのルートを宣伝する前にアプリケーションプロトコルをYに変更する場合、LSには変換された属性を含める必要があります。属性は、広告されたアプリケーションプロトコルがエンドツーエンドでは使用されないことを示しています。つまり、このルートについて宣伝されている情報は完全ではありません。
This attribute has length zero (0); the value field is empty.
この属性には長さゼロ（0）があります。値フィールドは空です。
Routes are never originated with the ConvertedRoute attribute.
ルートは、変換された属性に由来することはありません。
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.
集約するルートのいずれかに変換された属性がある場合、結果の集合体も必要です。
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には変換された属性を含める必要があります。
Any proposal for defining new TRIP attributes should specify the following:
新しい旅行属性を定義するための提案は、以下を指定する必要があります。
- the use of this attribute, - the attribute's flags, - the attribute's syntax, - how the attribute works with route origination, - how the attribute works with route aggregation, and - how the attribute works with route dissemination and the attribute's scope (e.g., intra-domain only like LocalPreference)
- この属性の使用 - 属性のフラグ、 - 属性の構文、 - 属性がルートのオリジネーションでどのように機能するか、 - 属性がルート集約でどのように機能するか、および - 属性がルート普及と属性の範囲でどのように機能するか（例えば、ドメイン内局所的なもののみが好きです）
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.
このセクションでは、検出されるエラーと、トリップメッセージの処理中に実行されるアクションについて説明します。
When any of the conditions described here are detected, a NOTIFICATION message with the indicated Error Code, Error Subcode, and Data fields MUST be sent, and the TRIP connection MUST be closed. If no Error Subcode is specified, then a zero Subcode MUST be used.
ここで説明した条件のいずれかが検出された場合、指定されたエラーコード、エラーサブコード、およびデータフィールドを含む通知メッセージを送信する必要があり、トリップ接続を閉じる必要があります。エラーサブコードが指定されていない場合は、ゼロサブコードを使用する必要があります。
The phrase "the TRIP connection is closed" means that the transport protocol connection has been closed and that all resources for that TRIP connection have been de-allocated. If the connection was inter-domain, then routing table entries associated with the remote peer MUST be marked as invalid. Routing table entries MUST NOT be marked as invalid if an internal peering session is terminated. The fact that the routes have been marked as invalid is passed to other TRIP peers before the routes are deleted from the system.
「トリップ接続が閉じられている」というフレーズは、輸送プロトコル接続が閉じられており、その旅行接続のすべてのリソースが脱退していることを意味します。接続がドメイン間の場合、リモートピアに関連付けられたテーブルエントリをルーティングすることは無効であるとマークする必要があります。ルーティングテーブルエントリは、内部ピアリングセッションが終了した場合、無効としてマークされてはなりません。ルートが無効であるとマークされているという事実は、システムからルートが削除される前に他の旅行仲間に渡されます。
Unless specified explicitly, the Data field of the NOTIFICATION message that is sent to indicate an error MUST be empty.
明示的に指定されていない限り、エラーが空でなければならないことを示すために送信される通知メッセージのデータフィールドは空でなければなりません。
All errors detected while processing the Message Header are indicated by sending the NOTIFICATION message with the Error Code Message Header Error. The Error Subcode elaborates on the specific nature of the error. The error checks in this section MUST be performed by each LS upon receipt of every message.
メッセージヘッダーの処理中に検出されたすべてのエラーは、エラーコードメッセージヘッダーエラーを使用して通知メッセージを送信することにより示されます。エラーサブコードは、エラーの特定の性質について詳しく説明します。このセクションでのエラーチェックは、すべてのメッセージを受信したときに各LSによって実行する必要があります。
If the Length field of the message header is less than 3 or greater than 4096, or if the Length field of an OPEN message is less than the minimum length of the OPEN message, or if the Length field of an UPDATE message is less than the minimum length of the UPDATE message, or if the Length field of a KEEPALIVE message is not equal to 3, or if the Length field of a NOTIFICATION message is less than the minimum length of the NOTIFICATION message, then the Error Subcode MUST be set to Bad Message Length. The Data field contains the erroneous Length field.
メッセージヘッダーの長さフィールドが4096未満または4096を超えている場合、または開いたメッセージの長さフィールドが開いているメッセージの最小長より少ない場合、または更新メッセージの長さフィールドがより少ない場合更新メッセージの最小長さ、または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.
メッセージヘッダーのタイプフィールドが認識されていない場合、エラーサブコードを「悪いメッセージタイプ」に設定する必要があります。データフィールドには、誤ったタイプフィールドが含まれています。
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メッセージエラー」を使用して通知メッセージを送信することにより示されます。エラーサブコードは、エラーの特定の性質について詳しく説明します。このセクションでのエラーチェックは、すべての開いたメッセージを受信したときに各LSによって実行する必要があります。
If the version number contained in the Version field of the received OPEN message is not supported, then the Error Subcode MUST be set to "Unsupported Version Number." The Data field is a 1-octet unsigned integer, which indicates the largest locally supported version number, which is less than the version of the remote TRIP peer bid (as indicated in the received OPEN message).
受信したオープンメッセージのバージョンフィールドに含まれるバージョン番号がサポートされていない場合、エラーサブコードは「サポートされていないバージョン番号」に設定する必要があります。データフィールドは、1オクテストの署名されていない整数です。これは、最大のローカルでサポートされているバージョン番号を示しています。
If the ITAD field of the OPEN message is unacceptable, then the Error Subcode MUST be set to "Bad Peer ITAD." The determination of acceptable ITAD numbers is outside the scope of this protocol.
開いたメッセージのITADフィールドが受け入れられない場合、エラーサブコードは「悪いピアITAD」に設定する必要があります。許容可能なITAD数の決定は、このプロトコルの範囲外です。
If the Hold Time field of the OPEN message is unacceptable, then the Error Subcode MUST be set to "Unacceptable Hold Time." An implementation MUST reject Hold Time values of one or two seconds. An implementation MAY reject any proposed Hold Time. An implementation that accepts a Hold Time MUST use the negotiated value for the Hold Time.
開いたメッセージの保持時間フィールドが受け入れられない場合、エラーサブコードは「容認できない保留時間」に設定する必要があります。実装は、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.
オープンメッセージのトリップ識別子フィールドが有効でない場合、エラーサブコードは「悪いトリップ識別子」に設定する必要があります。トリップ識別子の長さは4オクテットで、あらゆる価値を取ることができます。LSは、同じITADとトリップ識別子を持つ別のピアLSとのオープンな接続が既にある場合、トリップ識別子が無効であると考慮します。
Any two LSs within the same ITAD MUST NOT have equal TRIP Identifier values. This restriction does not apply to LSs in different ITADs since the purpose is to uniquely identify an LS using its TRIP Identifier and its ITAD number.
同じITAD内の2つのLSSは、等しいトリップ識別子値を持たないはずです。この制限は、さまざまなITADSのLSSには適用されません。これは、トリップ識別子とITAD番号を使用してLSを一意に識別することであるためです。
If one of the Optional Parameters in the OPEN message is not recognized, then the Error Subcode MUST be set to "Unsupported Optional Parameters."
オープンメッセージのオプションパラメーターの1つが認識されていない場合、エラーサブコードは「サポートされていないオプションパラメーター」に設定する必要があります。
If the Optional Parameters of the OPEN message include Capability Information with an unsupported capability (unsupported in either capability type or value), then the Error Subcode MUST be set to "Unsupported Capability," and the entirety of the unsupported capabilities MUST be listed in the Data field of the NOTIFICATION message.
オープンメッセージのオプションのパラメーターに、サポートされていない機能（機能タイプまたは値のいずれかのサポートされていない）を持つ機能情報が含まれている場合、エラーサブコードは「サポートされていない機能」に設定する必要があります。通知メッセージのデータフィールド。
If the Optional Parameters of the OPEN message include Capability Information which does not match the receiving LS's capabilities, then the Error Subcode MUST be set to "Capability Mismatch," and the entirety of the mismatched capabilities MUST be listed in the Data field of the NOTIFICATION message.
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.
更新メッセージの処理中に検出されたすべてのエラーは、エラーコード「更新メッセージエラー」を使用して通知メッセージを送信することにより示されます。エラーサブコードは、エラーの特定の性質について詳しく説明します。このセクションでのエラーチェックは、すべての更新メッセージを受信したときに各LSによって実行する必要があります。これらのエラーチェックは、洪水手順が内部ピアで呼び出される前に発生する必要があります。
If any recognized attribute has Attribute Flags that conflict with the Attribute Type Code, then the Error Subcode MUST be set to "Attribute Flags Error." The Data field contains the erroneous attribute (type, length and value).
認識された属性に属性タイプコードと競合する属性フラグがある場合、エラーサブコードは「属性フラグエラー」に設定する必要があります。データフィールドには、誤った属性（タイプ、長さ、値）が含まれています。
If any recognized attribute has an Attribute Length that conflicts with the expected length (based on the attribute type code), then the Error Subcode MUST be set to "Attribute Length Error." The Data field contains the erroneous attribute (type, length and value).
認識された属性に、予想される長さ（属性タイプコードに基づく）と競合する属性長がある場合、エラーサブコードは「属性長エラー」に設定する必要があります。データフィールドには、誤った属性（タイプ、長さ、値）が含まれています。
If any of the mandatory (i.e., conditional mandatory attribute and the conditions for including it in the UPDATE message are fulfilled) well-known attributes are not present, then the Error Subcode MUST be set to "Missing Well-known Mandatory Attribute." The Data field contains the Attribute Type Code of the missing well-known conditional mandatory attributes.
必須のいずれかのいずれかのいずれか（条件付き必須属性と更新メッセージに含める条件が満たされている場合）は、よく知られている属性が存在しない場合、エラーサブコードは「よく知られている必須属性を欠いている」に設定する必要があります。データフィールドには、欠落しているよく知られている条件付き必須属性の属性タイプコードが含まれています。
If any of the well-known attributes are not recognized, then the Error Subcode MUST be set to "Unrecognized Well-known Attribute." The Data field contains the unrecognized attribute (type, length and value).
よく知られている属性のいずれかが認識されていない場合、エラーサブコードは「認識されていないよく知られている属性」に設定する必要があります。データフィールドには、認識されていない属性（タイプ、長さ、値）が含まれています。
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に表示されないことを確認することにより行われます。AdvertisementPathにローカルITAD番号が表示される場合、ルートはadj-trib-inに保存される場合があります。ただし、LSが広告パスに独自のITADを使用してルートを受け入れるように構成されていない限り、ルートを旅行決定プロセスに渡すことはできません。広告パスに独自のITAD番号を持つルートを受け入れるように構成されているLSの操作は、このドキュメントの範囲外です。
If the UPDATE message was received from an internal peer and either the WithdrawnRoutes, ReachableRoutes, or ITAD Topology attribute does not have the Link-State Encapsulation flag set, then the Error Subcode is set to "Invalid Attribute" and the data field contains the attribute. Likewise, the attribute is invalid if received from an external peer and the Link-State Flag is set.
更新メッセージが内部ピアから受信され、撤回されたルート、Reachableroutes、またはITADトポロジー属性がリンク状態のカプセル化フラグセットがない場合、エラーサブコードは「無効な属性」に設定され、データフィールドに属性が含まれます。。同様に、外部ピアから受信し、リンク状態フラグが設定されている場合、属性は無効です。
If any attribute appears more than once in the UPDATE message, then the Error Subcode is set to "Malformed Attribute List."
更新メッセージに属性が複数回表示される場合、エラーサブコードは「奇形属性リスト」に設定されます。
If a peer sends a NOTIFICATION message, and there is an error in that message, there is unfortunately no means of reporting this error via a subsequent NOTIFICATION message. Any such error, such as an unrecognized Error Code or Error Subcode, should be noticed, logged locally, and brought to the attention of the administration of the peer. The means to do this, however, are outside the scope of this document.
ピアが通知メッセージを送信し、そのメッセージにエラーがある場合、残念ながら後続の通知メッセージを介してこのエラーを報告する手段はありません。認識されていないエラーコードやエラーサブコードなどのこのようなエラーは、注意し、ローカルにログに記録し、ピアの管理に注意を払う必要があります。ただし、これを行う手段は、このドキュメントの範囲外です。
If a system does not receive successive messages within the period specified by the negotiated Hold Time, then a NOTIFICATION message with a "Hold Timer Expired" Error Code MUST be sent and the TRIP connection MUST be closed.
システムが交渉された保留時間で指定された期間内に連続したメッセージを受信しない場合、「ホールドタイマーの有効期限が切れた」エラーコードを含む通知メッセージを送信する必要があり、トリップ接続を閉じる必要があります。
An error detected by the TRIP Finite State Machine (e.g., receipt of an unexpected event) MUST result in sending a NOTIFICATION message with the Error Code "Finite State Machine Error" and the TRIP connection MUST be closed.
旅行の有限状態マシンによって検出されたエラー（予期しないイベントの受領など）は、エラーコード「有限状態マシンエラー」を使用して通知メッセージを送信する必要があり、トリップ接続を閉じる必要があります。
In the absence of any fatal errors (that are indicated in this section), a TRIP peer MAY choose at any given time to close its TRIP connection by sending the NOTIFICATION message with the Error Code "Cease." However, the Cease NOTIFICATION message MUST NOT be used when a fatal error indicated by this section exists.
致命的なエラー（このセクションで示されている）がない場合、旅行ピアは、エラーコード「停止」で通知メッセージを送信することにより、いつでも旅行接続を閉じることを選択できます。ただし、このセクションで示された致命的なエラーが存在する場合、停止通知メッセージは使用しないでください。
If a pair of LSs try simultaneously to establish a transport connection to each other, then two parallel connections between this pair of speakers might well be formed. We refer to this situation as connection collision. Clearly, one of these connections must be closed.
LSSのペアが互いに輸送接続を確立するために同時に試みる場合、このスピーカーのペア間の2つの並列接続が形成される可能性があります。この状況を接続衝突と呼びます。明らかに、これらの接続の1つを閉じる必要があります。
Based on the value of the TRIP Identifier, a convention is established for detecting which TRIP connection is to be preserved when a collision occurs. The convention is to compare the TRIP Identifiers of the peers involved in the collision and to retain only the connection initiated by the LS with the higher-valued TRIP Identifier.
旅行識別子の価値に基づいて、衝突が発生したときにどの旅行接続を保存するかを検出するための条約が確立されます。条約は、衝突に関与するピアのトリップ識別子を比較し、LSによって開始された接続のみを保持することです。
Upon receipt of an OPEN message, the local LS MUST examine all of its connections that are in the OpenConfirm state. An LS MAY also examine connections in an OpenSent state if it knows the TRIP Identifier of the peer by means outside of the protocol. If among these connections there is a connection to a remote LS, whose TRIP Identifier equals the one in the OPEN message, then the local LS MUST perform the following collision resolution procedure:
オープンメッセージを受信すると、ローカルLSは、OpenConfirm状態にあるすべての接続を調べなければなりません。LSは、プロトコルの外側にあるピアのトリップ識別子を知っている場合、開閉状態での接続を調べることもできます。これらの接続の中にリモートLSへの接続がある場合、そのトリップ識別子がオープンメッセージのものと等しい場合、ローカルLSは次の衝突解像度手順を実行する必要があります。
The TRIP Identifier and ITAD of the local LS is compared to the TRIP Identifier and ITAD of the remote LS (as specified in the OPEN message). TRIP Identifiers are treated as 4-octet unsigned integers for comparison.
ローカルLSのトリップ識別子とITADは、リモートLSのトリップ識別子とITADと比較されます（オープンメッセージで指定されています）。トリップ識別子は、比較のために4-OCTETの符号なし整数として扱われます。
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:
ローカルトリップ識別子の値がリモートのものよりも小さい場合、または2つのトリップ識別子が等しく、ローカルLSのITADの値がリモートLSのITADの値よりも少ない場合、ローカルLSはすでに存在する旅行接続（すでにOpenConfirm状態にあるもの）を閉じ、リモートLSによって開始された旅行接続を受け入れます。
1. Otherwise, the local LS closes the newly created TRIP connection and continues to use the existing one (the one that is already in the OpenConfirm state). 2. If a connection collision occurs with an existing TRIP connection that is in the Established state, then the LS MUST unconditionally close off the newly created connection. Note that a connection collision cannot be detected with connections in Idle, Connect, or Active states. 3. To close the TRIP connection (that results from the collision resolution procedure), an LS MUST send a NOTIFICATION message with the Error Code "Cease" and the TRIP connection MUST be closed.
1. それ以外の場合、ローカルLSは新しく作成された旅行接続を閉じ、既存の旅行（すでにOpenConfirm状態にあるもの）を使用し続けています。2.確立された状態にある既存のトリップ接続で接続衝突が発生した場合、LSは新しく作成された接続を無条件に閉じる必要があります。IDLE、接続、またはアクティブ状態の接続で接続衝突を検出できないことに注意してください。3.トリップ接続を閉じる（衝突解決手続きの結果）、LSはエラーコード「停止」で通知メッセージを送信する必要があり、トリップ接続を閉じる必要があります。
Peer LSs may negotiate the version of the protocol by making multiple attempts to open a TRIP connection, starting with the highest version number each supports. If an open attempt fails with an Error Code "OPEN Message Error" and an Error Subcode "Unsupported Version Number," then the LS has available the version number it tried, the version number its peer tried, the version number passed by its peer in the NOTIFICATION message, and the version numbers that it supports. If the two peers support one or more common versions, then this will allow them to rapidly determine the highest common version. In order to support TRIP version negotiation, future versions of TRIP must retain the format of the OPEN and NOTIFICATION messages.
ピアLSSは、各サポートの最高版番号から始めて、旅行接続を開くために複数の試みを行うことにより、プロトコルのバージョンをネゴシエートする場合があります。オープン試行がエラーコード「Openメッセージエラー」とエラーサブコード「サポートされていないバージョン番号」で失敗した場合、LSは試したバージョン番号、ピアを試したバージョン番号、ピアによって渡されたバージョン番号を使用できます。通知メッセージ、およびサポートするバージョン番号。2人のピアが1つ以上の一般的なバージョンをサポートしている場合、これにより、最高の一般的なバージョンを迅速に決定できます。旅行バージョンの交渉をサポートするために、将来のバージョンの旅行は、オープンおよび通知メッセージの形式を保持する必要があります。
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には、PEERへの開かれたメッセージに機能オプションを含めることができ、LSがサポートする機能を示します。オープンメッセージを受信するLSは、そのピアと通信するときにピアの開かれたメッセージに含まれていない機能を使用してはなりません。
This section specifies TRIP operation in terms of a Finite State Machine (FSM). Following is a brief summary and overview of TRIP operations by state as determined by this FSM. A condensed version of the TRIP FSM is found in Appendix 1. There is one TRIP FSM per peer and these FSMs operate independently.
このセクションでは、有限状態マシン（FSM）の観点からトリップ操作を指定します。以下は、このFSMによって決定された州による旅行運用の簡単な要約と概要です。旅行FSMの凝縮バージョンは、付録1にあります。ピアごとに1つの旅行FSMがあり、これらのFSMは独立して動作します。
Idle state: Initially TRIP is in the Idle state for each peer. In this state, TRIP refuses all incoming connections. No resources are allocated to the peer. In response to the Start event (initiated by either the system or the operator), the local system initializes all TRIP resources, starts the ConnectRetry timer, initiates a transport connection to the peer, starts listening for a connection that may be initiated by the remote TRIP peer, and changes its state to Connect. The exact value of the ConnectRetry timer is a local matter, but should be sufficiently large to allow TCP initialization.
アイドル状態：最初はピアごとにアイドル状態にあります。この状態では、旅行はすべての着信接続を拒否します。ピアに割り当てられたリソースはありません。開始イベント（システムまたはオペレーターのいずれかによって開始された）に応じて、ローカルシステムはすべてのトリップリソースを初期化し、ConnectRetryタイマーを開始し、ピアへのトランスポート接続を開始し、リモートによって開始される接続のリスニングを開始しますピアを旅し、その状態を変えて接続します。ConnectRetryタイマーの正確な値はローカルな問題ですが、TCPの初期化を可能にするには十分に大きくなければなりません。
If an LS detects an error, it closes the transport connection and changes its state to Idle. Transitioning from the Idle state requires generation of the Start event. If such an event is generated automatically, then persistent TRIP errors may result in persistent flapping of the LS. To avoid such a condition, Start events MUST NOT be generated immediately for a peer that was previously transitioned to Idle due to an error. For a peer that was previously transitioned to Idle due to an error, the time between consecutive Start events, if such events are generated automatically, MUST exponentially increase. The value of the initial timer SHOULD be 60 seconds, and the time SHOULD be at least doubled for each consecutive retry up to some maximum value.
LSがエラーを検出した場合、輸送接続を閉じ、状態をアイドル状態に変更します。アイドル状態からの移行には、開始イベントの生成が必要です。このようなイベントが自動的に生成された場合、永続的なトリップエラーにより、LSが永続的な羽ばたきになる場合があります。このような状態を回避するには、エラーのために以前にアイドル状態に移行していたピアについて、開始イベントをすぐに生成してはなりません。エラーのために以前にアイドル状態に移行したピアの場合、そのようなイベントが自動的に生成された場合、連続した開始イベント間の時間は指数関数的に増加する必要があります。初期タイマーの値は60秒でなければならず、連続するたびに最大値までの再試行ごとに時間を少なくとも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.
Connect State：この状態では、LSが輸送プロトコル接続がピアに完了するのを待っており、ピアからのインバウンド輸送接続を聞いています。
If the transport protocol connection succeeds, the local LS clears the ConnectRetry timer, completes initialization, sends an OPEN message to its peer, sets its Hold Timer to a large value, and changes its state to OpenSent. A Hold Timer value of 4 minutes is suggested.
トランスポートプロトコル接続が成功した場合、ローカルLSはConnectRetryタイマーをクリアし、初期化を完了し、ピアに開かれたメッセージを送信し、ホールドタイマーを大きな価値に設定し、状態をオープンに変えます。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.
Transport Protocol Connectが失敗した場合（たとえば、再送信タイムアウトなど）、ローカルシステムはConnectRetryタイマーを再起動し、リモートLSによって開始される可能性のある接続を聞き続け、その状態をアクティブ状態に変更します。
In response to the ConnectRetry timer expired event, the local LS cancels any outstanding transport connection to the peer, restarts the ConnectRetry timer, initiates a transport connection to the remote LS, continues to listen for a connection that may be initiated by the remote LS, and stays in the Connect state.
ConnectRetryタイマーの期限切れイベントに応じて、ローカルLSはピアへの未解決の輸送接続をキャンセルし、ConnectRetryタイマーを再起動し、リモートLSへの輸送接続を開始し、リモートLSによって開始される可能性のある接続を聞き続けます。接続状態にとどまります。
If the local LS detects that a remote peer is trying to establish a connection to it and the IP address of the peer is not an expected one, then the local LS rejects the attempted connection and continues to listen for a connection from its expected peers without changing state.
ローカルLSがリモートピアがそれへの接続を確立しようとしていることを検出し、ピアのIPアドレスが予想されるものではない場合、ローカルLSは試行された接続を拒否し、予想されるピアからの接続を聞き続けます状態を変える。
If an inbound transport protocol connection succeeds, the local LS clears the ConnectRetry timer, completes initialization, sends an OPEN message to its peer, sets its Hold Timer to a large value, and changes its state to OpenSent. A Hold Timer value of 4 minutes is suggested.
インバウンドトランスポートプロトコル接続が成功した場合、ローカルLSはConnectRetryタイマーをクリアし、初期化を完了し、ピアに開かれたメッセージを送信し、ホールドタイマーを大きな価値に設定し、状態を開くように変更します。4分の保留タイマー値が提案されています。
The Start event is ignored in the Connect state.
開始イベントは、接続状態では無視されます。
In response to any other event (initiated by either the system or the operator), the local system releases all TRIP resources associated with this connection and changes its state to Idle.
他のイベント（システムまたはオペレーターのいずれかによって開始される）に応じて、ローカルシステムはこの接続に関連するすべてのトリップリソースをリリースし、その状態をアイドル状態に変更します。
Active state: In this state, an LS is listening for an inbound connection from the peer, but is not in the process of initiating a connection to the peer.
アクティブ状態：この状態では、LSはピアからのインバウンド接続を聞いていますが、ピアとの接続を開始する過程ではありません。
If an inbound transport protocol connection succeeds, the local LS clears the ConnectRetry timer, completes initialization, sends an OPEN message to its peer, sets its Hold Timer to a large value, and changes its state to OpenSent. A Hold Timer value of 4 minutes is suggested.
インバウンドトランスポートプロトコル接続が成功した場合、ローカルLSはConnectRetryタイマーをクリアし、初期化を完了し、ピアに開かれたメッセージを送信し、ホールドタイマーを大きな価値に設定し、状態を開くように変更します。4分の保留タイマー値が提案されています。
In response to the ConnectRetry timer expired event, the local system restarts the ConnectRetry timer, initiates a transport connection to the TRIP peer, continues to listen for a connection that may be initiated by the remote TRIP peer, and changes its state to Connect.
ConnectRetryタイマーの期限切れイベントに応じて、ローカルシステムはConnectRetryタイマーを再起動し、旅行ピアへの輸送接続を開始し、リモートトリップピアによって開始される可能性のある接続を聴き続け、状態を接続します。
If the local LS detects that a remote peer is trying to establish a connection to it and the IP address of the peer is not an expected one, then the local LS rejects the attempted connection and continues to listen for a connection from its expected peers without changing state.
ローカルLSがリモートピアがそれへの接続を確立しようとしていることを検出し、ピアのIPアドレスが予想されるものではない場合、ローカルLSは試行された接続を拒否し、予想されるピアからの接続を聞き続けます状態を変える。
Start event is ignored in the Active state.
アクティブな状態では、開始イベントが無視されます。
In response to any other event (initiated by either the system or the operator), the local system releases all TRIP resources associated with this connection and changes its state to Idle.
他のイベント（システムまたはオペレーターのいずれかによって開始される）に応じて、ローカルシステムはこの接続に関連するすべてのトリップリソースをリリースし、その状態をアイドル状態に変更します。
OpenSent state: In this state, an LS has sent an OPEN message to its peer and is waiting for an OPEN message from its peer. When an OPEN message is received, all fields are checked for correctness. If the TRIP message header checking or OPEN message checking detects an error (see Section 6.2) or a connection collision (see Section 6.8), the local system sends a NOTIFICATION message and changes its state to Idle.
オープンセント状態：この状態では、LSがピアに開かれたメッセージを送信し、ピアからの開かれたメッセージを待っています。開いたメッセージが受信されると、すべてのフィールドに正確さが確認されます。トリップメッセージヘッダーチェックまたは開くメッセージチェックがエラー（セクション6.2を参照）または接続衝突（セクション6.8を参照）を検出すると、ローカルシステムは通知メッセージを送信し、状態をアイドル状態に変更します。
If there are no errors in the OPEN message, TRIP sends a KEEPALIVE message and sets a KeepAlive timer. The Hold Timer, which was originally set to a large value (see above), is replaced with the negotiated Hold Time value (see Section 4.2). If the negotiated Hold Time value is zero, then the Hold Time timer and KeepAlive timers are not started. If the value of the ITAD field is the same as the local ITAD number, then the connection is an "internal" connection; otherwise, it is "external" (this will affect UPDATE processing). Finally, the state is changed to OpenConfirm.
開いたメッセージにエラーがない場合、TripはKeepAliveメッセージを送信し、KeepAliveタイマーを設定します。もともと大きな値（上記参照）に設定されていたホールドタイマーは、交渉された保留時間値に置き換えられます（セクション4.2を参照）。ネゴシエートされた保持時間値がゼロの場合、ホールドタイムタイマーとキープライブタイマーは開始されません。ITADフィールドの値がローカルITAD番号と同じ場合、接続は「内部」接続です。それ以外の場合は、「外部」です（これは更新処理に影響します）。最後に、状態はOpenConfirmに変更されます。
If the local LS detects that a remote peer is trying to establish a connection to it and the IP address of the peer is not an expected one, then the local LS rejects the attempted connection and continues to listen for a connection from its expected peers without changing state.
ローカルLSがリモートピアがそれへの接続を確立しようとしていることを検出し、ピアのIPアドレスが予想されるものではない場合、ローカルLSは試行された接続を拒否し、予想されるピアからの接続を聞き続けます状態を変える。
If a disconnect notification is received from the underlying transport protocol, the local LS closes the transport connection, restarts the ConnectRetry timer, continues to listen for a connection that may be initiated by the remote TRIP peer, and goes into the Active state.
基礎となる輸送プロトコルから切断通知が受信された場合、ローカルLSは輸送接続を閉じ、ConnectRetryタイマーを再起動し、リモートトリップピアによって開始される可能性のある接続を聞き続け、アクティブ状態に入ります。
If the Hold Timer expires, the local LS sends a NOTIFICATION message with the Error Code "Hold Timer Expired" and changes its state to Idle.
ホールドタイマーの有効期限が切れると、ローカルLSはエラーコード「ホールドタイマーの有効期限が切れ」を含む通知メッセージを送信し、状態をアイドル状態に変更します。
In response to the Stop event (initiated by either system or operator) the local LS sends a NOTIFICATION message with the Error Code "Cease" and changes its state to Idle.
STOPイベント（システムまたはオペレーターのいずれかによって開始された）に応じて、ローカルLSはエラーコード「停止」で通知メッセージを送信し、状態をアイドル状態に変更します。
The Start event is ignored in the OpenSent state.
開始イベントは、オープンな状態で無視されます。
In response to any other event the local LS sends a NOTIFICATION message with the Error Code "Finite State Machine Error" and changes its state to Idle.
他のイベントに応じて、ローカルLSはエラーコード「有限状態マシンエラー」を含む通知メッセージを送信し、その状態をアイドル状態に変更します。
Whenever TRIP changes its state from OpenSent to Idle, it closes the transport connection and releases all resources associated with that connection.
旅行が状態をオープンでアイドル状態からアイドル状態に変更するたびに、輸送接続を閉じて、その接続に関連するすべてのリソースをリリースします。
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がピアにオープンを送り、ピアからオープンを受け取り、オープンに応じてキープライブを送信しました。LSは、オープンに応じてキープライブまたは通知メッセージを待っています。
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.
キープライブメッセージが受信される前にホールドタイマーが期限切れになった場合、ローカルLSはエラーコード「ホールドタイマーの有効期限が切れ」で通知メッセージを送信し、状態をアイドル状態に変更します。
If the local LS receives a NOTIFICATION message, it changes its state to Idle.
ローカルLSが通知メッセージを受信した場合、状態をアイドル状態に変更します。
If the KeepAlive timer expires, the local LS sends a KEEPALIVE message and restarts its KeepAlive timer.
Keepalive Timerが期限切れになった場合、ローカルLSはKeepAliveメッセージを送信し、KeepAliveタイマーを再起動します。
If a disconnect notification is received from the underlying transport protocol, the local LS closes the transport connection, restarts the ConnectRetry timer, continues to listen for a connection that may be initiated by the remote TRIP peer, and goes into the Active state.
基礎となる輸送プロトコルから切断通知が受信された場合、ローカルLSは輸送接続を閉じ、ConnectRetryタイマーを再起動し、リモートトリップピアによって開始される可能性のある接続を聞き続け、アクティブ状態に入ります。
In response to the Stop event (initiated by either the system or the operator) the local LS sends NOTIFICATION message with the Error Code "Cease" and changes its state to Idle.
STOPイベント（システムまたはオペレーターのいずれかによって開始される）に応じて、ローカルLSはエラーコード「停止」で通知メッセージを送信し、状態をアイドル状態に変更します。
The Start event is ignored in the OpenConfirm state.
OpenConfirm状態では、開始イベントは無視されます。
In response to any other event the local LS sends a NOTIFICATION message with the Error Code "Finite State Machine Error" and changes its state to Idle.
他のイベントに応じて、ローカルLSはエラーコード「有限状態マシンエラー」を含む通知メッセージを送信し、その状態をアイドル状態に変更します。
Whenever TRIP changes its state from OpenConfirm to Idle, it closes the transport connection and releases all resources associated with that connection.
旅行がOpenConfirmからアイドル状態に状態を変更するたびに、輸送接続を閉じて、その接続に関連するすべてのリソースをリリースします。
Established state: In the Established state, an LS can exchange UPDATE, NOTIFICATION, and KEEPALIVE messages with its peer.
確立された状態：確立された状態では、LSはそのピアとの更新、通知、およびキープレジャーを交換できます。
If the negotiated Hold Timer is zero, then no procedures are necessary for keeping a peering session alive. If the negotiated Hold Time value is non-zero, the procedures of this paragraph apply. If the Hold Timer expires, the local LS sends a NOTIFICATION message with the Error Code "Hold Timer Expired" and changes its state to Idle. If the KeepAlive Timer expires, then the local LS sends a KeepAlive message and restarts the KeepAlive Timer. If the local LS receives an UPDATE or KEEPALIVE message, then it restarts its Hold Timer. Each time the LS sends an UPDATE or KEEPALIVE message, it restarts its KeepAlive Timer.
ネゴシエートされたホールドタイマーがゼロの場合、ピアリングセッションを生かし続けるための手順は必要ありません。交渉された保持時間値がゼロではない場合、この段落の手順が適用されます。ホールドタイマーの有効期限が切れると、ローカルLSはエラーコード「ホールドタイマーの有効期限が切れ」を含む通知メッセージを送信し、状態をアイドル状態に変更します。Keepalive Timerが期限切れになった場合、ローカルLSはKeepAliveメッセージを送信し、KeepAliveタイマーを再起動します。ローカルLSが更新またはKeepAliveメッセージを受信した場合、ホールドタイマーを再起動します。LSが更新またはKeepAliveメッセージを送信するたびに、KeepAliveタイマーを再起動します。
If the local LS receives a NOTIFICATION message, it changes its state to Idle.
ローカルLSが通知メッセージを受信した場合、状態をアイドル状態に変更します。
If the local LS receives an UPDATE message and the UPDATE message error handling procedure (see Section6.3) detects an error, the local LS sends a NOTIFICATION message and changes its state to Idle.
ローカルLSが更新メッセージを受信し、更新メッセージエラー処理手順（セクション6.3を参照）がエラーを検出すると、ローカルLSは通知メッセージを送信し、状態をアイドル状態に変更します。
If a disconnect notification is received from the underlying transport protocol, the local LS changes its state to Idle.
基礎となる輸送プロトコルから切断通知が受信された場合、ローカルLSはその状態をアイドル状態に変更します。
In response to the Stop event (initiated by either the system or the operator), the local LS sends a NOTIFICATION message with the Error Code "Cease" and changes its state to Idle.
STOPイベント（システムまたはオペレーターのいずれかによって開始される）に応じて、ローカルLSはエラーコード「停止」を含む通知メッセージを送信し、状態をアイドル状態に変更します。
The Start event is ignored in the Established state.
開始イベントは、確立された状態では無視されます。
In response to any other event, the local LS sends a NOTIFICATION message with Error Code "Finite State Machine Error" and changes its state to Idle.
他のイベントに応じて、ローカルLSはエラーコード「有限状態マシンエラー」を使用して通知メッセージを送信し、その状態をアイドル状態に変更します。
Whenever TRIP changes its state from Established to Idle, it closes the transport connection and releases all resources associated with that connection. Additionally, if the peer is an external peer, the LS deletes all routes derived from that connection.
旅行を確立された状態からアイドル状態に変えるたびに、輸送接続を閉じ、その接続に関連するすべてのリソースをリリースします。さらに、ピアが外部ピアである場合、LSはその接続から派生したすべてのルートを削除します。
An UPDATE message may be received only in the Established state. When an UPDATE message is received, each field is checked for validity as specified in Section 6.3. The rest of this section presumes that the UPDATE message has passed the error-checking procedures of Section 6.3.
更新メッセージは、確立された状態でのみ受信される場合があります。更新メッセージが受信されると、セクション6.3で指定されているように、各フィールドに有効性が確認されます。このセクションの残りの部分では、更新メッセージがセクション6.3のエラーチェック手順に渡されたと推定しています。
If the UPDATE message was received from an internal peer, the flooding procedures of Section 10.1 MUST be applied. The flooding process synchronizes the Loc-TRIBs of all LSs within the domain. Certain routes within the UPDATE may be marked as old or duplicates by the flooding process and are ignored during the rest of the UPDATE processing.
更新メッセージが内部ピアから受信された場合、セクション10.1の洪水手順を適用する必要があります。洪水プロセスは、ドメイン内のすべてのLSSのloc-tribsを同期させます。更新内の特定のルートは、洪水プロセスによって古いまたは重複としてマークされ、残りの更新処理中に無視されます。
If the UPDATE message contains withdrawn routes, then the corresponding previously advertised routes shall be removed from the Adj-TRIB-In. This LS MUST rerun its Decision Process since the previously advertised route is no longer available for use.
更新メッセージに撤回されたルートが含まれている場合、対応する以前に宣伝されたルートは、adj-trib-inから削除されます。このLSは、以前に宣伝されていたルートが使用できなくなったため、決定プロセスを再実行する必要があります。
If the UPDATE message contains a route, then the route MUST be placed in the appropriate Adj-TRIB-In, and the following additional actions MUST be taken:
更新メッセージにルートが含まれている場合、ルートを適切なadj-trib-inに配置する必要があり、次の追加アクションを実行する必要があります。
1. If its destinations are identical to those of a route currently stored in the Adj-TRIB-In, then the new route MUST replace the older route in the Adj-TRIB-In, thus implicitly withdrawing the older route from service. The LS MUST rerun its Decision Process since the older route is no longer available for use. 2. If the new route is more specific than an earlier route contained in the Adj-TRIB-In and has identical attributes, then no further actions are necessary. 3. If the new route is more specific than an earlier route contained in the Adj-TRIB-In but does not have identical attributes, then the LS MUST run its Decision Process since the more specific route has implicitly made a portion of the less specific route unavailable for use. 4. If the new route has destinations that are not present in any of the routes currently stored in the Adj-TRIB-In, then the LS MUST run its Decision Process. 5. If the new route is less specific than an earlier route contained in the Adj-TRIB-In, the LS MUST run its Decision Process on the set of destinations that are described only by the less specific route.
1. その目的地が現在adj-trib-inに保存されているルートの宛先と同一である場合、新しいルートはadj-trib-inの古いルートを置き換える必要があり、したがって、古いルートをサービスから暗黙的に引き出します。LSは、古いルートが使用できなくなったため、決定プロセスを再実行する必要があります。2.新しいルートが、adj-trib-inに含まれる以前のルートよりも具体的で、同一の属性がある場合、それ以上のアクションは必要ありません。3.新しいルートがadj-trib-inに含まれる以前のルートよりも具体的であるが、同一の属性がない場合、より具体的なルートが暗黙的に具体的にはあまり具体的ではないため、LSは決定プロセスを実行する必要があります使用することはできません。4.新しいルートに、Adj-Trib-inに現在保存されているルートのいずれにも存在しない目的地がある場合、LSは決定プロセスを実行する必要があります。5.新しいルートがadj-trib-inに含まれる以前のルートよりも具体的ではない場合、LSは、あまり特定のルートでのみ記述される宛先のセットで決定プロセスを実行する必要があります。
When an LS receives an UPDATE message from an internal peer, the LS floods the new information from that message to all of its other internal peers. Flooding is used to efficiently synchronize all of the LSs within a domain without putting any constraints on the domain's internal topology. The flooding mechanism is based on the techniques used in OSPF [4] and SCSP [6]. One may argue that TRIP's flooding process is in reality a controlled broadcast mechanism.
LSが内部ピアから更新メッセージを受信すると、LSはそのメッセージから新しい情報を他のすべての内部ピアにflood濫させます。洪水は、ドメインの内部トポロジに制約をかけることなく、ドメイン内のすべてのLSSを効率的に同期するために使用されます。洪水メカニズムは、OSPF [4]およびSCSP [6]で使用される手法に基づいています。旅行の洪水プロセスは実際には制御された放送メカニズムであると主張するかもしれません。
The LS MUST maintain the sequence number and originating TRIP identifier for each link-state encapsulated attribute in an internal Adj-TRIB-In. These values are included with the route in the ReachableRoutes, WithdrawnRoutes, and ITAD Topology attributes. The originating TRIP identifier gives the internal LS that originated this route into the ITAD, the sequence number gives the version of this route at the originating LS.
LSは、内部adj-trib-inで各リンク状態のカプセル化された属性のシーケンス番号と発信トリップ識別子を維持する必要があります。これらの値は、Reachableroutes、Retwardroutes、およびITADトポロジー属性のルートに含まれています。発信トリップ識別子は、このルートをITADに登録した内部LSを与えます。シーケンス番号は、このルートのバージョンを発信するLSで提供します。
For each route in the ReachableRoutes or WithdrawnRoutes field, the LS decides if the route is new or old. This is determined by comparing the Sequence Number of the route in the UPDATE with the Sequence Number of the route saved in the Adj-TRIB-In. The route is new if either the route does not exist in the Adj-TRIB-In for the originating LS, or if the route does exist in the Adj-TRIB-In but the Sequence Number in the UPDATE is greater than the Sequence Number saved in the Adj-TRIBs-In. Note that the newness test is independently applied to each link-state encapsulated attribute in the UPDATE (WithdrawnRoutes or ReachableRoutes or ITAD Topology).
ReachableroutesまたはRetwardroutesフィールドの各ルートについて、LSはルートが新品または古いかどうかを決定します。これは、アップデート内のルートのシーケンス番号を、adj-trib-inで保存されたルートのシーケンス番号を比較することによって決定されます。ルートは、元のLSのアジュトリブインにルートが存在しない場合、またはルートがadj-trib-inに存在するが、更新のシーケンス番号が保存されたシーケンス番号よりも大きい場合、ルートは新しいものです。adj-tribs-inで。新しさテストは、アップデート内の各リンク状態のカプセル化された属性（Recturelawroutesまたは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.
ReachablerOutesまたはRectrownroutesフィールドの各ルートは、さらに処理する際に無視されます。ルートが新しいと判断された場合、次のアクションが発生します。
If the route is being withdrawn, then the LS MUST flood the withdrawn route to all other internal peers, and MUST mark the route as withdrawn. An LS MUST maintain routes marked as withdrawn in its databases for MaxPurgeTime seconds.
ルートが撤回されている場合、LSは撤回されたルートを他のすべての内部ピアへのルートに浸水させ、撤回されたルートをマークする必要があります。LSは、MaxPurgetime秒間、データベースで撤回されたとマークされたルートを維持する必要があります。
If the route is being updated, then the LS MUST update the route in the Adj-TRIB-In and MUST flood it to all other internal peers.
ルートが更新されている場合、LSはadj-trib-inのルートを更新し、他のすべての内部ピアにあふれさせる必要があります。
If these procedures result in changes to the Adj-TRIB-In, then the route is also made available for local route processing as described early in Section 10.
これらの手順により、adj-trib-inが変更された場合、セクション10の早い段階で説明されているように、ルートはローカルルート処理にも利用可能になります。
To implement flooding, the following is recommended. All routes received in a single UPDATE message that are determined to be new should be forwarded to all other internal peers in a single UPDATE message. Other variations of flooding are possible, but the local LS MUST ensure that each new route (and any associated attributes) received from an internal peer get forwarded to every other internal peer.
洪水を実装するには、以下をお勧めします。新しいと判断された単一の更新メッセージで受信したすべてのルートは、単一の更新メッセージで他のすべての内部ピアに転送する必要があります。他の洪水のバリエーションは可能ですが、ローカルLSは、内部ピアから受け取った各新しいルート（および関連する属性）が他のすべての内部ピアに転送されることを保証する必要があります。
The Sequence Number is used to determine when one version of a Route is newer than another version of a route. A larger Sequence Number indicates a newer version. The Sequence Number is assigned by the LS originating the route into the local ITAD. The Sequence Number is an unsigned 4-octet integer in the range of 1 thru 2^31-1 MinSequenceNum thru MaxSequenceNum). The value 0 is reserved. When an LS first originates a route (including when the LS restarts/reboots) into its ITAD, it MUST originate it with a Sequence Number of MinSequenceNum. Each time the route is updated within the ITAD by the originator, the Sequence Number MUST be increased.
シーケンス番号は、ルートの1つのバージョンが別のバージョンのルートよりも新しい時期を決定するために使用されます。シーケンス番号が大きいと、新しいバージョンが示されます。シーケンス番号は、ルートをローカルITADに発信するLSによって割り当てられます。シーケンス番号は、1から2^31-1分のsequencenumからマックスセクセンセナムの範囲の署名されていない4オクテット整数です。値0は予約されています。LSが最初にルート（LSが再起動/再起動を再起動するときを含む）をITADに発信する場合、シーケンス数のMin Sequencenumで発生する必要があります。Oringatorによってルートが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.
シーケンス番号が最大seceshencenum-1であり、それを増やす必要がある場合は、LSのトリップモジュールをトリップ分離の期間無効にする必要があります。削除。
To withdraw a route that it originated within the ITAD, an LS includes the route in the WithdrawnRoutes field of an UPDATE message. The Sequence Number MUST be greater than the last valid version of the route. The LS MAY choose to use a sequence number of MaxSequenceNum when withdrawing routes within its ITAD, but this is not required.
ITAD内で発生したルートを引き出すために、LSには、更新メッセージの撤回されたルートフィールドにルートが含まれます。シーケンス番号は、ルートの最後の有効なバージョンよりも大きくなければなりません。LSは、ITAD内のルートを引き出すときに、最大順番のシーケンス数を使用することを選択できますが、これは必須ではありません。
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が、LSSの現在のバージョンよりも新しい（シーケンス数が高い）が発生したルートの更新を受信した場合、特別なアクションを実行する必要があります。これは比較的まれな発生である必要があり、LSSが最後に再起動/再起動するため、ITAD内にルートがまだ存在することを示しています。
If an LS receives a self-originated route update that is newer than the current version of the route at the LS, then the following actions MUST be taken. If the LS still wishes to advertise the information in the route, then the LS MUST increase the Sequence Number of the route to a value greater than that received in the UPDATE and re-originate the route. If the LS does not wish to continue to advertise the route, then it MUST purge the route as described in Section 10.1.5.
LSがLSの現在のバージョンのルートよりも新しい自己序的ルートアップデートを受信した場合、次のアクションを実行する必要があります。LSがまだルート内の情報を宣伝したい場合、LSはルートのシーケンス番号をアップデートで受信した値よりも大きい値まで増やし、ルートを再起動する必要があります。LSがルートを宣伝し続けたくない場合は、セクション10.1.5で説明されているようにルートをパージする必要があります。
An LS SHOULD ensure that routes marked as withdrawn are removed from the database in a timely fashion after the MaxPurgeTime has expired. This could be done, for example, by periodically sweeping the database, and deleting those entries that were withdrawn more than MaxPurgeTime seconds ago.
LSは、MaxPurgetimeの有効期限が切れた後、撤回されたルートがデータベースからタイムリーに削除されるようにする必要があります。これは、たとえば、データベースを定期的にスイープし、数秒前にMaxpurgetimeが撤回されたエントリを削除することで実行できます。
The Decision Process selects routes for subsequent advertisement by applying the policies in the local Policy Information Base (PIB) to the routes stored in its Adj-TRIBs-In. The output of the Decision process is the set of routes that will be advertised to all peers; the selected routes will be stored in the local LS's Adj-TRIBs-Out.
決定プロセスは、Adj-Tribs-inに保存されているルートにローカルポリシー情報ベース（PIB）にポリシーを適用することにより、後続の広告のルートを選択します。決定プロセスの出力は、すべてのピアに宣伝されるルートのセットです。選択したルートは、ローカルLSのadj-tribs-outに保存されます。
The selection process is formalized by defining a function that takes the attributes of a given route as an argument and returns a non-negative integer denoting the degree of preference for the route. The function that calculates the degree of preference for a given route shall not use as its inputs any of the following: the existence of other routes, the non-existence of other routes, or the attributes of other routes. Route selection then consists of an individual application of the degree of preference function to each feasible route, followed by the choice of the one with the highest degree of preference.
選択プロセスは、特定のルートの属性を引数として取得し、ルートの好みの程度を示す非陰性整数を返す関数を定義することにより形式化されます。特定のルートの優先度を計算する関数は、他のルートの存在、他のルートの存在、または他のルートの属性の存在として、その入力として使用してはなりません。ルートの選択は、各実行可能なルートへの優先関数の程度の個別の適用で構成され、その後、優先度が最も高いものを選択します。
All internal LSs in an ITAD MUST run the Decision Process and apply the same decision criteria, otherwise it will not be possible to synchronize their Loc-TRIBs.
ITAD内のすべての内部LSSは、決定プロセスを実行し、同じ決定基準を適用する必要があります。そうしないと、loc-tribを同期することはできません。
The Decision Process operates on routes contained in each Adj-TRIBs-In, and is responsible for:
決定プロセスは、各adj-tribs-inに含まれるルートで動作し、以下の責任があります。
- 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は、フェーズ1の完了時に呼び出されます。それは、それぞれの異なる目的地で利用可能なすべてのルートから最適なルートを選択し、選択した各ルートをloc-tribに設置する責任があります。 - フェーズ3は、loc-tribが変更された後に呼び出されます。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がピアから新しいルート、交換ルート、または撤回されたルートを宣伝する更新メッセージを受け取るたびに呼び出されるものとします。
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-inをロックし、その中に含まれるすべての新しいまたは交換ルートで操作した後にロックを解除するものとします。
The local LS MUST determine a degree of preference for each newly received or replacement route. If the route is learned from an internal peer, the value of the LocalPreference attribute MUST be taken as the degree of preference. If the route is learned from an external peer, then the degree of preference MUST be computed based on pre-configured policy information and used as the LocalPreference value in any intra-domain TRIP advertisement. The exact nature of this policy information and the computation involved is a local matter.
ローカルLSは、新しく受信または交換する各ルートの程度の優先度を決定する必要があります。ルートが内部ピアから学習された場合、localpreference属性の値を優先度として取得する必要があります。ルートが外部ピアから学習された場合、優先度を事前に構成されたポリシー情報に基づいて計算し、ドメイン内旅行広告のローカルプレーファレンス値として使用する必要があります。このポリシー情報の正確な性質と関連する計算は、ローカルな問題です。
The output of the degree of preference determination process is the local preference of a route. The local LS computes the local preference of routes learned from external peers or originated internally at that LS. The local preference of a route learned from an internal peer is included in the LocalPreference attribute associated with that route.
優先決定プロセスの程度の出力は、ルートの局所選好です。ローカルLSは、外部のピアから学んだルートのローカル選好を計算するか、そのLSで内部で発信されます。内部ピアから学んだルートのローカル選好は、そのルートに関連付けられたLocalPreference属性に含まれています。
The Phase 2 decision function shall be invoked on completion of Phase 1. The Phase 2 function is a separate process that completes when it has no further work to do. Phase 2 consists of two sub-phases: 2a and 2b. The same route selection function is applied in both sub-phases, but the inputs to each phase are different. The Phase 2a process MUST consider as inputs all external routes, that are present in the Adj-TRIBs-In of external peers, and all local routes. The output of Phase 2a is inserted into the Ext-TRIB. The Phase 2b process shall be invoked upon completion of Phase 2a and it MUST consider as inputs all routes in the Ext-TRIB and all routes that are present in the Adj-TRIBs-In of internal LSs. The output of Phase 2b is stored in the Loc-TRIB.
フェーズ2の決定関数は、フェーズ1の完了時に呼び出されるものとします。フェーズ2関数は、それ以上の作業がない場合に完了する個別のプロセスです。フェーズ2は、2aと2bの2つのサブフェーズで構成されています。同じルート選択関数は両方のサブフェーズに適用されますが、各フェーズへの入力は異なります。フェーズ2Aプロセスは、外部ピアの調整中に存在するすべての外部ルート、およびすべてのローカルルートに存在する入力として考慮する必要があります。フェーズ2Aの出力はext-Tribに挿入されます。フェーズ2Bプロセスは、フェーズ2Aの完了時に呼び出され、内部LSSのadj-tribs-inに存在するすべてのルートのすべてのルートを入力として考慮する必要があります。フェーズ2Bの出力はloc-tribに保存されます。
The Phase 2 decision function MUST be blocked from running while the Phase 3 decision function is in process. The Phase 2 function MUST lock all Adj-TRIBs-In and the Ext-TRIB prior to commencing its function, and MUST unlock them on completion.
フェーズ3の決定関数がプロセス中に、フェーズ2の決定関数は実行をブロックする必要があります。フェーズ2関数は、その機能を開始する前にすべてのadj-tribs-inとext-tribをロックする必要があり、完了時にそれらをロック解除する必要があります。
If the LS determines that the NextHopServer listed in a route is unreachable, then the route MAY be excluded from the Phase 2 decision function. The means by which such a determination is made is not mandated here.
LSがルートにリストされている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-inから削除する必要があります。
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は、これらのルートの1つのみを選択して、関連する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のより大きな値を持つルートを選択します。 - 少なくとも1つのルートが内部LSによって発信された場合、最低のトリップIDを持つ内部LSによって宣伝されたルートルートを選択します。 - それ以外の場合は、ITAD数が最も少ないネイバードメインによって宣伝されたルートを選択します。
The Phase 3 decision function MUST be invoked upon completion of Phase 2 if Phase 2 results in changes to the Loc-TRIB or when a new LS-to-LS peer session is established.
フェーズ2の決定関数は、フェーズ2がloc-tribの変更をもたらす場合、または新しいLS-to-LSピアセッションが確立された場合に、フェーズ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関数は、それ以上の作業がないときに完了する別のプロセスです。フェーズ2の決定関数がプロセス中に、フェーズ3ルーティング決定関数は実行をブロックする必要があります。
All routes in the Loc-TRIB shall be processed into a corresponding entry in the associated Adj-TRIBs-Out. Route aggregation and information reduction techniques (see 10.3.4) MAY optionally be applied.
loc-trib内のすべてのルートは、関連するadj-tribs-outの対応するエントリに処理されます。ルート集約と情報削減手法（10.3.4を参照）がオプションで適用される場合があります。
When the updating of the Adj-TRIBs-Out is complete, the local LS MUST run the external update process of 10.3.2.
adj-tribs-outの更新が完了した場合、ローカルLSは10.3.2の外部更新プロセスを実行する必要があります。
When overlapping routes are present in the same Adj-TRIB-In, the more specific route shall take precedence, in order, from most specific to least specific.
オーバーラップルートが同じadj-trib-inに存在する場合、より具体的なルートは、最も具体的なものから最も具体的なものまで優先されます。
The set of destinations described by the overlap represents a portion of the less specific route that is feasible, but is not currently in use. If a more specific route is later withdrawn, the set of destinations described by the more specific route will still be reachable using the less specific route.
オーバーラップで記述された目的地のセットは、実行可能ではないが現在使用されていない特定のルートの一部を表しています。より具体的なルートが後で撤回された場合、より具体的なルートで説明されている目的地のセットは、それほど具体的ではないルートを使用して到達可能になります。
If an LS receives overlapping routes, the Decision Process MUST take into account the semantics of the overlapping routes. In particular, if an LS accepts the less specific route while rejecting the more specific route from the same peer, then the destinations represented by the overlap may not forward along the domains listed in the AdvertisementPath attribute of that route. Therefore, an LS has the following choices:
LSが重複するルートを受信した場合、決定プロセスは、重複するルートのセマンティクスを考慮する必要があります。特に、LSが同じピアからより具体的なルートを拒否しながら、あまり特定のルートを受け入れる場合、オーバーラップで表される目的地は、そのルートのAdvertisementPath属性にリストされているドメインに沿って転送されない場合があります。したがって、LSには次の選択肢があります。
1. Install both the less and the more specific routes 2. Install the more specific route only 3. Install the non-overlapping part of the less specific route only (that implies disaggregation of the less-specific route) 4. Aggregate the two routes and install the aggregated route 5. Install the less specific route only 6. Install neither route
1. より具体的なルートとより特定のルートの両方をインストールする2.より特定のルートのみをインストールします。3。非特定のルートのみの重複部分をインストールします（これは、それほど特異的でないルートの分解を意味します）4。2つのルートを集約してインストールします集約されたルート5。特定のルートのみをインストールします。6。どちらのルートもインストールしません
If an LS chooses 5), then it SHOULD add AtomicAggregate attribute to the route. A route that carries AtomicAggregate attribute MUST NOT be de-aggregated. That is, the route cannot be made more specific. Forwarding along such a route does not guarantee that route traverses only domains listed in the RoutedPath of the route. If an LS chooses 1), then it MUST NOT advertise the less specific route without the more specific route.
LSが5）を選択した場合、それはルートにAtomicGgregate属性を追加する必要があります。AtomicGregate属性を運ぶルートは、凝集してはなりません。つまり、ルートをより具体的にすることはできません。このようなルートに沿って転送することは、ルートのルーティングパスにリストされているドメインのみを通過することを保証するものではありません。LSが1）を選択した場合、より具体的なルートなしであまり特定のルートを宣伝してはなりません。
The Update-Send process is responsible for advertising UPDATE messages to all peers. For example, it distributes the routes chosen by the Decision Process to other LSs that may be located in either the same ITAD or a neighboring ITAD. Rules for information exchange between peer LSs located in different ITADs are given in 10.3.2; rules for information exchange between peer LSs located in the same ITAD are given in 10.3.1.
更新センドプロセスは、すべてのピアへの更新メッセージの広告を担当します。たとえば、意思決定プロセスによって選択されたルートを、同じITADまたは隣接ITADのいずれかに配置できる他のLSSに分配します。異なるITADにあるピアLS間の情報交換の規則は、10.3.2に与えられます。同じITADにあるピアLSS間の情報交換の規則は、10.3.1に与えられます。
Before forwarding routes to peers, an LS MUST determine which attributes should be forwarded along with that route. If a not well-known non-transitive attribute is unrecognized, it is quietly ignored. If a not well-known dependent-transitive attribute is unrecognized, and the NextHopServer attribute has been changed by the LS, the unrecognized attribute is quietly ignored. If a not well-known dependent-transitive attribute is unrecognized, and the NextHopServer attribute has not been modified by the LS, the Partial bit in the attribute flags octet is set to 1, and the attribute is retained for propagation to other TRIP speakers. Similarly, if an not well-known independent-transitive attribute is unrecognized, the Partial bit in the attribute flags octet is set to 1, and the attribute is retained for propagation to other TRIP speakers.
ルートをピアに転送する前に、LSはそのルートとともにどの属性を転送するかを決定する必要があります。よく知られていない非転倒属性が認識されていない場合、それは静かに無視されます。よく知られていない依存性誘導属性が認識されず、nexthopserver属性がLSによって変更された場合、認識されていない属性は静かに無視されます。よく知られていない依存性誘導属性が認識されず、nexthopserver属性がLSによって変更されていない場合、属性フラグの部分ビットは1に設定され、属性は他のトリップスピーカーへの伝播のために保持されます。同様に、よく知られていない独立した移動属性が認識されていない場合、属性フラグの部分的なビットは1に設定され、属性は他のトリップスピーカーへの伝播のために保持されます。
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.
よく知られていない属性が認識され、有効な値がある場合、有名な属性のタイプに応じて、他のトリップスピーカーへの伝播の可能性について、必要に応じて更新されます。
The Internal update process is concerned with the distribution of routing information to internal peers.
内部更新プロセスは、内部ピアへのルーティング情報の配布に関係しています。
When an LS receives an UPDATE message from another TRIP LS located in its own ITAD, it is flooded as described in Section 10.1.
LSが独自のITADにある別の旅行LSから更新メッセージを受信すると、セクション10.1で説明されているように浸水します。
When an LS receives a new route from an LS in a neighboring ITAD, or if a local route is injected into TRIP, the LS determines the preference of that route. If the new route has the highest degree of preference for all external routes and local routes to a given destination (or if the route was selected via a tie-breaking procedure as specified in 10.3.1.1), the LS MUST insert that new route into the Ext-TRIB database and the LS MUST advertise that route to all other LSs in its ITAD by means of an UPDATE message. The LS MUST advertise itself as the Originator of that route within the ITAD.
LSが隣接するITADのLSから新しいルートを受け取る場合、またはローカルルートが旅行に注入された場合、LSはそのルートの好みを決定します。新しいルートが特定の宛先へのすべての外部ルートとローカルルートに対して最も優先度が高い場合（または、10.3.1.1で指定されたタイブレイク手順でルートが選択された場合、LSはその新しいルートを挿入する必要があります。Ext-TribデータベースとLSは、更新メッセージを使用して、ITADの他のすべてのLSSへのそのルートを宣伝する必要があります。LSは、ITAD内のそのルートの創始者として自分自身を宣伝する必要があります。
When an LS receives an UPDATE message with a non-empty WithdrawnRoutes attribute from an external peer, or if a local route is withdrawn from TRIP, the LS MUST remove from its Adj-TRIB-In all routes whose destinations were carried in this field. If the withdrawn route was previously selected into the Ext-TRIB, the LS MUST take the following additional steps:
LSが外部のピアから空ではない撤回された撤回属性を持つ更新メッセージを受信した場合、またはローカルルートが旅行から撤回された場合、LSはこのフィールドで目的地が運ばれたすべてのルートからadj-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は交換ルートをext-Tribに挿入して、撤回したルートを交換し、すべての内部LSSに宣伝する必要があります。 - 交換ルートが広告に使用できない場合、LSは更新メッセージの撤回されたルート属性のルートの宛先を含める必要があり、このメッセージを各内部ピアに送信する必要があります。LSは、ext-tribから撤回されたルートも削除する必要があります。
If an LS has connections to several external peers, there will be multiple Adj-TRIBs-In associated with these peers. These databases might contain several equally preferable routes to the same destination, all of which were advertised by external peers. The local LS shall select one of these routes according to the following rules:
LSが複数の外部ピアに接続している場合、これらのピアに関連付けられた複数のアジュトリブインがあります。これらのデータベースには、同じ目的地へのいくつかの同様に好ましいルートが含まれている場合があり、そのすべてが外部のピアによって宣伝されていました。ローカルLSは、次のルールに従ってこれらのルートのいずれかを選択するものとします。
- If the LS is configured to use the MultiExitDisc attribute to break ties, and the candidate routes differ in the value of the MultiExitDisc attribute, then select the route that has the lowest value of MultiExitDisc, else - Select the route that was advertised by the external LS that has the lowest TRIP Identifier.
- LSがMultiExitDisc属性を使用してタイを破るように構成されている場合、候補ルートのMultiExitDisc属性の値が異なる場合、MultiExitDiscの最低値を持つルートを選択します。最低のトリップ識別子を持つLS。
The external update process is concerned with the distribution of routing information to external peers. As part of the Phase 3 route selection process, the LS has updated its Adj-TRIBs-Out. All newly installed routes and all newly unfeasible routes for which there is no replacement route MUST be advertised to external peers by means of UPDATE messages.
外部更新プロセスは、外部ピアへのルーティング情報の配布に関係しています。フェーズ3ルート選択プロセスの一部として、LSはそのadj-tribs-outを更新しました。新しく設置されたすべてのルートと、交換ルートがないすべての新しく実行不可能なルートは、更新メッセージを使用して外部のピアに宣伝する必要があります。
Any routes in the Loc-TRIB marked as withdrawn MUST be removed. Changes to the reachable destinations within its own ITAD SHALL also be advertised in an UPDATE message.
撤回されたとマークされたloc-trib内のルートは削除する必要があります。独自のITAD内の到達可能な目的地の変更は、更新メッセージにも宣伝されなければなりません。
The TRIP protocol constrains the amount of routing traffic (that is, UPDATE messages) in order to limit both the link bandwidth needed to advertise UPDATE messages and the processing power needed by the Decision Process to digest the information contained in the UPDATE messages.
トリッププロトコルは、更新メッセージを宣伝するために必要なリンク帯域幅と、更新メッセージに含まれる情報を消化するために必要な処理能力の両方を制限するために、ルーティングトラフィックの量（つまり、更新メッセージ）を制約します。
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.
パラメーターminrouteadedisementementIntervalは、単一のLSから特定の宛先へのルートの広告間で経過しなければならない最小時間を決定します。このレートの制限手順は、命令ごとに適用されますが、MinrouteadEdvertisementIntervalの値は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つの更新メッセージ間の間隔が少なくともMinRouteAdvertisementEntervalになり、間隔の一定の上限が許容されることを保証する手法。
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つの更新メッセージは、内部ピアから受け取ったいくつかの一般的な宛先セットへの実行可能なルートを宣伝するものを、少なくともminrouteadevertementementIntervalによって分離する必要があります。
Since fast convergence is needed within an ITAD, this rate limiting procedure does not apply to routes received from internal peers and being broadcast to other internal peers. To avoid long-lived black holes, the procedure does not apply to the explicit withdrawal of routes (that is, routes whose destinations explicitly withdrawn by UPDATE messages).
ITAD内で高速収束が必要であるため、このレート制限手順は、内部のピアから受け取ったルートや他の内部ピアに放送されるルートには適用されません。長寿命のブラックホールを避けるために、手順はルートの明示的な撤回（つまり、更新メッセージによって明示的に撤回されたルート）には適用されません。
This procedure does not limit the rate of route selection, but only the rate of route advertisement. If new routes are selected multiple times while awaiting the expiration of MinRouteAdvertisementInterval, the last route selected shall be advertised at the end of MinRouteAdvertisementInterval.
この手順は、ルート選択の速度を制限するのではなく、ルート広告の速度のみを制限します。MinrouteadedvertisementIntervalの有効期限を待っている間に新しいルートが複数回選択された場合、選択した最後のルートは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内の変更を報告する更新メッセージの連続的な広告間で経過しなければならない最小時間を決定します。
To minimize the likelihood that the distribution of TRIP messages by a given LS will contain peaks, jitter should be applied to the timers associated with MinITADOriginationInterval, KeepAlive, and MinRouteAdvertisementInterval. A given LS shall apply the same jitter to each of these quantities regardless of the destinations to which the updates are being sent; that is, jitter will not be applied on a "per peer" basis.
特定のLSによるトリップメッセージの分布がピークを含む可能性を最小限に抑えるために、ジッターはMinitadoriginationInterval、Keepalive、およびMinrouteadedivementementIntervalに関連するタイマーに適用する必要があります。与えられたLSは、更新が送信されている宛先に関係なく、これらのそれぞれに同じジッターを適用するものとします。つまり、ジッターは「ピアごと」ベースで適用されません。
The amount of jitter to be introduced shall be determined by multiplying the base value of the appropriate timer by a random factor that is uniformly distributed in the range from 0.75 to 1.0.
導入されるジッターの量は、適切なタイマーの基本値に0.75から1.0の範囲で均一に分布するランダム係数を掛けることにより決定するものとします。
Having selected the routing information that it will advertise, a TRIP speaker may use methods to organize this information in an efficient manner. These methods are discussed in the following sections.
宣伝するルーティング情報を選択した場合、旅行スピーカーは方法を使用してこの情報を効率的に整理することができます。これらの方法については、次のセクションで説明します。
Information reduction may imply a reduction in granularity of policy control - after information has collapsed, the same policies will apply to all destinations and paths in the equivalence class.
情報の削減は、政策管理の粒度の削減を意味する場合があります - 情報が崩壊した後、同等のクラスのすべての目的地とパスに同じポリシーが適用されます。
The Decision Process may optionally reduce the amount of information that it will place in the Adj-TRIBs-Out by any of the following methods:
決定プロセスは、オプションで、次の方法のいずれかによってadj-tribs-outに配置される情報の量を削減する場合があります。
- ReachableRoutes: A set of destinations can be usually represented in compact form. For example, a set of E.164 phone numbers can be represented in more compact form using E.164 prefixes. - AdvertisementPath: AdvertisementPath information can be represented as ordered AP_SEQUENCEs or unordered AP_SETs. AP_SETs are used in the route aggregation algorithm described in Section 5.4.4. They reduce the size of the AP_PATH information by listing each ITAD number only once, regardless of how many times it may have appeared in multiple advertisement paths that were aggregated.
- REACHABLEROUTES：通常、一連の宛先はコンパクトな形で表現できます。たとえば、E.164の電話番号のセットは、E.164プレフィックスを使用して、よりコンパクトな形式で表現できます。 - AdvertisementPath：AdvertisementPath情報は、順序付けられたAP_シーケンスまたは順序付けられていないAP_SETSとして表すことができます。AP_SETSは、セクション5.4.4で説明されているルート集約アルゴリズムで使用されます。集約された複数の広告パスに表示される回数に関係なく、各ITAD番号を1回だけリストすることにより、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は、更新メッセージに宣伝されている宛先が、少なくとも一部の構成要素ITADを横断するパスを介して到達できることを意味します。AP_SETSは、ルートループを避けるのに十分な情報を提供します。ただし、そのようなパスはAP_シーケンスの形のように個別にリストされなくなったため、それらの使用は潜在的に実行可能なパスを剪定する可能性があります。実際には、これは問題になる可能性は低いです。コールが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-outに配置されたルーティング情報の量を減らすための決定プロセスの一部として発生する可能性があります。
Aggregation reduces the amount of information an LS must store and exchange with other LSs. Routes can be aggregated by applying the following procedure separately to attributes of like type.
集約により、LSが保存して他のLSSと交換する必要がある情報の量が減少します。ルートは、次の手順を個別に同種の属性に個別に適用することで集約できます。
Routes that have the following attributes shall not be aggregated unless the corresponding attributes of each route are identical: MultiExitDisc, NextHopServer.
次の属性を持つルートは、各ルートの対応する属性が同一でない限り、集約されません：MultiExitDisc、Nexthopserver。
Attributes that have different type codes cannot be aggregated. Attributes of the same type code may be aggregated. The rules for aggregating each attribute MUST be provided together with attribute definition. For example, aggregation rules for TRIP's basic attributes, e.g., ReachableRoutes and AdvertisementPath, are given in Section 5.
異なるタイプコードを持つ属性を集約することはできません。同じタイプコードの属性を集計することができます。各属性を集約するためのルールは、属性定義とともに提供する必要があります。たとえば、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.
- 検討中の新しいルートのAdvertisementPathにローカルITADが表示されている場合、その新しいルートは他のどのルートよりも優れていると見なすことができません。そのようなルートが使用された場合、ルーティングループが生じる可能性があります（セクション6.3を参照）。 - 分散操作を成功させるために、安定性の可能性があるルートのみを選択できます。したがって、ITADは不安定なルートの使用を避けなければならず、ルートの選択に急速な自発的な変更を加えてはなりません。前の文の「不安定」と「迅速」という用語を定量化するには、経験が必要ですが、原則は明らかです。
An LS may originate local routes by injecting routing information acquired by some other means (e.g. via an intra-domain routing protocol or through manual configuration or some dynamic registration mechanism/protocol) into TRIP. An LS that originates TRIP routes shall assign the degree of preference to these routes by passing them through the Decision Process (see Section 10.2). To TRIP, local routes are identical to external routes and are subjected to the same two phase route selection mechanism. A local route which is selected into the Ext-TRIB MUST be advertised to all internal LSs. The decision whether to distribute non-TRIP acquired routes within an ITAD via TRIP or not depends on the environment within the ITAD (e.g. type of intra-domain routing protocol) and should be controlled via configuration.
LSは、他の手段によって取得されたルーティング情報を注入することにより、ドメイン内ルーティングプロトコルを介して、または手動構成または動的登録メカニズム/プロトコルを介して）を旅行に注入することにより、ローカルルートを発信する場合があります。トリップルートを発信するLSは、これらのルートを決定プロセスに渡すことにより、これらのルートに対する優先度の程度を割り当てるものとします（セクション10.2を参照）。旅行するには、ローカルルートは外部ルートと同一であり、同じ2位のルート選択メカニズムにさらされます。ext-Tribに選択されたローカルルートは、すべての内部LSSに宣伝する必要があります。旅行を介してITAD内で非訓練後のルートを配布するかどうかは、ITAD内の環境（例えば、ドメイン内ルーティングプロトコルの種類）に依存し、構成を介して制御する必要があります。
This specification defines the use of TCP as the transport layer for TRIP. TRIP uses TCP port 6069. Running TRIP over other transport protocols is for further study.
この仕様では、TCPの使用を旅行の輸送層として定義しています。Tripは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.
旅行LSSのドメイン内トポロジーに制限はありません。たとえば、ITADのLSSは、フルメッシュ、星、またはその他の接続されたトポロジーで構成できます。同様に、Trip ITADSのトポロジーに制限はありません。たとえば、ITADは、フラットトポロジー（メッシュまたはリング）またはマルチレベルの階層またはその他のトポロジーで編成できます。
The border between two TRIP ITADs may be located either on the link between two TRIP LSs or it may coincide on a TRIP LS. In the latter case, the same TRIP LS will be member in more than one ITAD, and it appears to be an internal peer to LSs in each ITAD it is member of.
2つのトリップITADの境界線は、2つのトリップLSSの間のリンクに配置されているか、旅行LSに一致する可能性があります。後者の場合、同じ旅行LSは複数のITADのメンバーになり、各ITADの内部ピアのLSSのメンバーであるように見えます。
This document creates a new IANA registry for TRIP parameters. The following TRIP parameters are included in the registry:
このドキュメントでは、旅行パラメーター用の新しいIANAレジストリを作成します。次の旅行パラメーターはレジストリに含まれています。
- TRIP Capabilities - TRIP Attributes - TRIP Address Families - TRIP Application Protocols - TRIP ITAD Numbers
- トリップ機能 - トリップ属性 - トリップアドレスファミリー - トリップアプリケーションプロトコル - トリップITAD番号
Protocol parameters are frequently initialized/reset to 0. This document reserves the value 0 of each of the above TRIP parameters in order to clearly distinguish between an unset parameter and any other registered values for that parameter.
プロトコルパラメーターは頻繁に初期化/リセットされます。このドキュメントは、上記の各トリップパラメーターの値0を留保し、そのパラメーターの非ステットパラメーターとその他の登録値を明確に区別します。
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 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.
セクション4.2.1.1で定義されているもの以外の旅行機能を追加するリクエストは、iana@iana.orgに提出する必要があります。[11]で概説されている割り当てられた番号ポリシーに続いて、範囲32768-65535の機能コードはプライベート使用のために予約されています（これらは、コード値の最初のビットが1に等しいコードを持つコードです）。このドキュメントは、値0を留保します。機能コード1と2は、セクション4.2.1.1に割り当てられています。範囲2-32767の機能コードはIANAによって制御され、必要な仕様（IETF RFCまたは同等の）条件の対象となります。仕様には、機能の説明、取る可能性のある値、および機能の不一致を構成するものを含める必要があります。
This document reserves Attribute Type Codes 224-255 for Private Use (these are the codes with the first three bits of the code equal to 1). This document reserves the value 0. Attribute Type Codes 1 through 11 have already been allocated by this document. Attribute Type Codes 1 through 11 are defined in Sections 5.1 through 5.11.
このドキュメントは、プライベート使用のために属性タイプコード224-255を留保します（これらは、コードの最初の3ビットが1に等しいコードです）。このドキュメントは、値0を留保します。属性タイプコード1〜11は、このドキュメントによってすでに割り当てられています。属性タイプコード1〜11は、セクション5.1〜5.11で定義されています。
Attribute Type Codes in the range 12-223 are controlled by IANA, and require a Specification document (RFC or equivalent). The specification MUST provide all information required in Section 5.12 of this document.
範囲12-223の属性タイプコードはIANAによって制御されており、仕様文書（RFCまたは同等）が必要です。仕様は、このドキュメントのセクション5.12で必要なすべての情報を提供する必要があります。
Attribute Type Code registration requests must be sent to iana@iana.org. In addition to the specification requirement, the request MUST include an indication of who has change control over the attribute and contact information (postal and email address).
属性タイプコード登録リクエストは、iana@iana.orgに送信する必要があります。仕様要件に加えて、要求には、属性と連絡先情報（郵便および電子メールアドレス）に対する変更制御が誰があるかを示すことを要求する必要があります。
This document reserves address family 0. Requests to add TRIP address families other than those defined in Section 5.1.1.1 ( address families 1, 2, and 3), i.e., in the range 4-32767, must be submitted to iana@iana.org. The request MUST include a brief description of the address family, its alphabet, and special processing rules and guidelines, such as guidelines for aggregation, if any. The requests are subject to Expert Review. This document reserves the address family codes 32768-65535 for vendor-specific applications.
このドキュメントは、住所ファミリー0を留保します。セクション5.1.1.1（住所ファミリー1、2、および3）で定義されているファミリー以外のトリップアドレスファミリを追加するリクエスト、つまり4〜32767の範囲で、IANA@IANAに提出する必要があります。組織。リクエストには、住所ファミリ、そのアルファベット、特別な処理ルールと、集約のガイドラインなどのガイドラインの簡単な説明を含める必要があります。リクエストは専門家のレビューの対象となります。このドキュメントでは、ベンダー固有のアプリケーションについては、住所ファミリコード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.
このドキュメントは、旅行アプリケーションプロトコル用の新しいIANAレジストリを作成します。このドキュメントは、アプリケーションプロトコルコード0を留保します。セクション5.1.1.1（アプリケーションプロトコル1〜4）で定義されているもの以外のトリップアプリケーションプロトコルを追加するリクエスト、つまり5-32767の範囲では、iana@iana.orgに提出する必要があります。。リクエストには、アプリケーションプロトコルの簡単な背景と、そのプロトコルのルートを宣伝するために旅行を使用する方法の説明を含める必要があります。リクエストは専門家のレビューの対象となります。このドキュメントは、ベンダー固有のアプリケーションについて、アプリケーションプロトコルコード32768-65535を留保します。
This document reserves the ITAD number 0. ITAD numbers in the range 1-255 are designated for Private Use. ITAD numbers in the range from 256 to (2**32)-1 are allocated by IANA on a First-Come-First-Serve basis. Requests for ITAD numbers must be submitted to iana@iana.org. The requests MUST include the following:
このドキュメントは、ITAD番号0を留保します。1〜255の範囲のITAD番号は、私的使用のために指定されています。256〜（2 ** 32）-1の範囲のITAD数は、最初のCome-First-Serveベースで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.
このセクションでは、IP環境で旅行がTCPを介して行われたときに、ピアトリップLSS間のセキュリティをカバーしています。
A security mechanism is clearly needed to prevent unauthorized entities from using the protocol defined in this document for setting up unauthorized peer sessions with other TRIP LSs or interfering with authorized peer sessions. The security mechanism for the protocol, when transported over TCP in an IP network, is IPsec [12]. IPsec uses two protocols to provide traffic security: Authentication Header (AH) [13] and Encapsulating Security Payload (ESP) [14].
このドキュメントで定義されているプロトコルを使用して、他の旅行LSSとの不正なピアセッションを設定したり、認定ピアセッションを妨害したりするために、不正なエンティティがこのドキュメントで定義されているプロトコルを使用しないようにするために、セキュリティメカニズムが明らかに必要です。IPネットワークでTCPを介して輸送されるプロトコルのセキュリティメカニズムはIPSECです[12]。IPSECは、2つのプロトコルを使用してトラフィックセキュリティを提供します：認証ヘッダー（AH）[13]とセキュリティペイロードのカプセル化（ESP）[14]。
The AH header affords data origin authentication, connectionless integrity and optional anti-replay protection of messages passed between the peer LSs. The ESP header provides origin authentication, connectionless integrity, anti-replay protection, and confidentiality of messages.
AHヘッダーは、ピアLSS間に渡されたメッセージのデータオリジン認証、コネクションレスの完全性、およびオプションのレプレイ防止保護を提供します。ESPヘッダーは、Origin Authentication、Connectionless Integrity、Anti Replay保護、およびメッセージの機密性を提供します。
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に提供されますが、両方ではありません。2種類のSASが定義されています：輸送モードとトンネルモード[12]。トランスポートモードSAは、2つのホスト間のセキュリティアソシエーションであり、2つのピアLSS間の旅行セッションを保護するのに適しています。
A1. Appendix 1: TRIP FSM State Transitions and Actions
A1。付録1：FSM状態の移行とアクションをトリップします
This Appendix discusses the transitions between states in the TRIP FSM in response to TRIP events. The following is the list of these states and events when the negotiated Hold Time value is non-zero.
この付録では、旅行イベントに対応した旅行FSMの州間の移行について説明しています。以下は、交渉された保持時間値がゼロでない場合のこれらの州とイベントのリストです。
TRIP States: 1 - Idle 2 - Connect 3 - Active 4 - OpenSent 5 - OpenConfirm 6 - Established
旅行状態：1-アイドル2-接続3-アクティブ4-オープンセント5-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
トリップイベント：1-旅行開始2-旅行停止3-トリップトランスポート接続オープン4-トリップトランスポート接続閉鎖5-トリップトランスポート接続オープン6-トリップトランスポートエラー7-コネクトレトリタイマーの期限切れ8-ホールドタイマーの期限切れ有効期限10-オープンメッセージ11-キープライブメッセージを受信12-更新メッセージを受信13-通知メッセージを受信
The following table describes the state transitions of the TRIP FSM and the actions triggered by these transitions.
次の表は、旅行FSMの州の遷移と、これらの遷移によって引き起こされたアクションについて説明しています。
Event Actions Message Sent Next State
--------------------------------------------------------------------
Idle (1)
1 Initialize resources none 2
Start ConnectRetry timer
Initiate a transport connection
others none none 1
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
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
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
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
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.
トリッププロトコルでは、同じ広告パスと次のホップサーバーを備えた複数のアドレスプレフィックスを1つのメッセージで指定できます。この機能を利用することを強くお勧めします。メッセージごとに1つのアドレスプレフィックスを使用すると、受信機のオーバーヘッドが大幅に増加します。複数のメッセージの受信によりシステムのオーバーヘッドが増加するだけでなく、ピアをトリップするための更新のためにルーティングテーブルをスキャンするオーバーヘッドも複数回発生します。広告パスごとに多くのアドレスプレフィックスを含むメッセージを構築する1つの方法と、広告パスごとに編成されていないルーティングテーブルから次のホップは、ルーティングテーブルがスキャンされるため、多くのメッセージを作成することです。各アドレスのプレフィックスが処理されると、関連する広告パスと次のホップが存在しない場合は割り当てられ、新しいアドレスプレフィックスが追加されます。そのようなメッセージが存在する場合、新しいアドレスのプレフィックスはそれに追加されます。メッセージに新しいアドレスプレフィックスを保持するスペースがない場合、それは送信され、新しいメッセージが割り当てられ、新しいアドレスプレフィックスが新しいメッセージに挿入されます。ルーティングテーブル全体がスキャンされると、すべての割り当てられたメッセージが送信され、リソースがリリースされます。アドレスプレフィックスで覆われたすべての宛先が同じ次のホップサーバーと共通属性を共有している場合、最大圧縮が達成され、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.
複数のアドレスのプレフィックスを1つのメッセージに圧縮しない旅行実装で覗く場合、ピアが取得されたときに受け取ったデータの洪水または重要なネットワークトポロジの変更が発生したときに、オーバーヘッドを減らすための措置を講じる必要がある場合があります。これを行う1つの方法は、更新レートを制限することです。これにより、ルーティングテーブルの冗長なスキャンが排除され、トリップピアのフラッシュ更新が提供されます。このアプローチの欠点は、ルーティング情報の伝播潜時を増加させることです。複数のメッセージを処理するのにかかる時間よりもはるかに大きくない最小フラッシュ更新間隔を選択することにより、このレイテンシを最小限に抑える必要があります。より良い方法は、更新を送信する前に受信したすべてのメッセージを読み取ることです。
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メッセージタイプの場合、これは完全なメッセージです。他のメッセージタイプの場合、ヘッダーはまず、特に全長を検証する必要があります。すべてのチェックが成功した場合、指定された長さは、メッセージヘッダーのサイズを差し引いて、読み取るデータの量です。ピアから読み取ろうとしながらルーティング情報プロセスを「ハング」する実装では、ピアごとにメッセージバッファー（4096バイト）を設定し、完全なメッセージが受信されるまで利用可能なデータを入力することができます。
A.2.3: Reducing Route Flapping
A.2.3：ルート羽ばたきの削減
To avoid excessive route flapping an LS which needs to withdraw a destination and send an update about a more specific or less specific route SHOULD combine them into the same UPDATE message.
宛先を引き出し、より具体的または具体的でないルートに関する更新を送信する必要があるLSを過度に羽ばたかないようにするために、それらを同じ更新メッセージに結合する必要があります。
A.2.4: TRIP Timers
A.2.4：トリップタイマー
TRIP employs seven timers: ConnectRetry, Hold Time, KeepAlive, MaxPurgeTime, TripDisableTime, MinITADOriginationInterval, and MinRouteAdvertisementInterval. The suggested value for the ConnectRetry timer is 120 seconds. The suggested value for the Hold Time is 90 seconds. The suggested value for the KeepAlive timer is 30 seconds. The suggested value for the MaxPurgeTime timer is 10 seconds. The suggested value for the TripDisableTime timer is 180 seconds. The suggested value for the MinITADOriginationInterval is 30 seconds. The suggested value for the MinRouteAdvertisementInterval is 30 seconds.
Tripは7つのタイマーを雇用しています：ConnectRetry、Hold Time、Keepalive、MaxPurgetime、TripDisabletime、MinitadoriginationInterval、およびMinrouteadedvertisementInterval。ConnectRetryタイマーの推奨値は120秒です。保留時間の推奨値は90秒です。KeepAliveタイマーの推奨値は30秒です。MaxPurgetimeタイマーの推奨値は10秒です。TripDisableTimeタイマーの推奨値は180秒です。MinitadoriginationIntervalの推奨値は30秒です。minrouteadvertisementIntervalの推奨値は30秒です。
An implementation of TRIP MUST allow these timers to be configurable.
旅行の実装では、これらのタイマーを構成可能にする必要があります。
A.2.5: AP_SET Sorting
A.2.5：ap_set sorting
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.
この状況を簡素化するために行うことができるもう1つの有用な最適化は、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Rosenberg, J. and H. Schulzrinne, "A Framework for a Gateway Location Protocol", RFC 2871, June 2000.
[2] Rosenberg、J。およびH. Schulzrinne、「ゲートウェイロケーションプロトコルのフレームワーク」、RFC 2871、2000年6月。
[3] Rekhter, Y. and T. Li, "Border Gateway Protocol 4 (BGP-4)," RFC 1771, March 1995.
[3] Rekhter、Y。およびT. Li、「Border Gateway Protocol 4（BGP-4）」、RFC 1771、1995年3月。
[4] Moy, J., "Open Shortest Path First Version 2", STD 54, RFC 2328, April 1998.
[4] Moy、J。、「Open Shortest Path First Version 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] 「Connectionless-Mode Network Service（ISO 8473）を提供するためのプロトコルと併せて使用するための中間システムへの中間システムイントラドメインルーティング交換プロトコル」、ISO DP 10589、1990年2月。
[6] Luciani, J., Armitage, G., Halpern, J. and N. Doraswamy, "Server Cache Synchronization Protocol (SCSP)", RFC 2334, April 1998.
[6] Luciani、J.、Armitage、G.、Halpern、J。およびN. Doraswamy、「サーバーキャッシュ同期プロトコル（SCSP）」、RFC 2334、1998年4月。
[7] International Telecommunication Union, "Packet-Based Multimedia Communication Systems," Recommendation H.323, Version 3 Telecommunication Standardization Sector of ITU, Geneva, Switzerland, November 2000.
[7] 2000年11月、スイス、ジュネーブのITUのバージョン3テレコミュニケーション標準化セクター、「パケットベースのマルチメディア通信システム」、「パケットベースのマルチメディア通信システム」、推奨事項H.323、バージョン3テレコミュニケーション標準化セクター。
[8] Handley, H., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[8] Handley、H.、Schulzrinne、H.、Schooler、E。and J. Rosenberg、「SIP：セッション開始プロトコル」、RFC 2543、1999年3月。
[9] Braden, R., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989.
[9] Braden、R。、「インターネットホストの要件 - アプリケーションとサポート」、STD 3、RFC 1123、1989年10月。
[10] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[10] Hinden、R。and S. Deering、「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.
[11] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[12] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[12] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[13] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[13] Kent、S。およびR. Atkinson、「IP Authentication Header」、RFC 2402、1998年11月。
[14] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[14] Kent、S。およびR. Atkinson、「IPカプセル化セキュリティペイロード（ESP）」、RFC 2406、1998年11月。
[15] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[15] Harkins、D。およびD. Carrel、「The Internet Key Exchange（IKE）」、RFC 2409、1998年11月。
Intellectual Property Notice
知的財産通知
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP 11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat.
IETFは、知的財産またはその他の権利の有効性または範囲に関して、この文書に記載されているテクノロジーの実装または使用に関連すると主張される可能性のある他の権利、またはそのような権利に基づくライセンスがどの程度であるかについての程度に関連する可能性があるという立場はありません。利用可能;また、そのような権利を特定するために努力したことも表明していません。標準トラックおよび標準関連のドキュメントの権利に関するIETFの手順に関する情報は、BCP 11に記載されています。この仕様の実装者またはユーザーによるそのような独自の権利を使用するための一般的なライセンスまたは許可を取得するために作成されたのは、IETF事務局から取得できます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、関心のある当事者に、この基準を実践するために必要な技術をカバーする可能性のある著作権、特許、または特許出願、またはその他の独自の権利を注意深く招待するよう招待しています。情報をIETFエグゼクティブディレクターに宛ててください。
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.
IETFは、このドキュメントに含まれる仕様の一部またはすべてに関して請求された知的財産権について通知されています。詳細については、請求権のオンラインリストを参照してください。
Authors' Addresses
著者のアドレス
Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936
ジョナサンローゼンバーグダイナミクスソフト72イーグルロックアベニュー1階イーストハノーバー、ニュージャージー07936
Phone: 973-952-5000 EMail: jdrosen@dynamicsoft.com
電話：973-952-5000メール：jdrosen@dynamicsoft.com
Hussein F. Salama Cisco Systems 170 W. Tasman Drive San Jose, CA 95134
フセインF.サラマシスコシステム170 W.タスマンドライブサンノゼ、カリフォルニア95134
Phone: 408-527-7147 EMail: hsalama@cisco.com
電話：408-527-7147メール：hsalama@cisco.com
Matt Squire Hatteras Networks 639 Davis Drive Suite 200 Durham, NC 27713
Matt Squire Hatteras Networks 639 Davis Drive Suite 200 Durham、NC 27713
EMail: mattsquire@acm.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。