[要約] RFC 3684は、逆経路転送（Reverse-Path Forwarding）に基づくトポロジー伝播（Topology Dissemination）を扱っており、ネットワークのトポロジー情報を効率的に伝播するためのプロトコルです。目的は、ネットワークのトポロジー情報を正確かつ迅速に共有することです。
Network Working Group R. Ogier
Request for Comments: 3684 SRI International
Category: Experimental F. Templin
Nokia
M. Lewis
SRI International
February 2004
Topology Dissemination Based on Reverse-Path Forwarding (TBRPF)
リバースパス転送に基づくトポロジの普及（TBRPF）
Status of this Memo
本文書の位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004). All Rights Reserved.
著作権（c）The Internet Society（2004）。無断転載を禁じます。
Abstract
概要
Topology Dissemination Based on Reverse-Path Forwarding (TBRPF) is a proactive, link-state routing protocol designed for mobile ad-hoc networks, which provides hop-by-hop routing along shortest paths to each destination. Each node running TBRPF computes a source tree (providing paths to all reachable nodes) based on partial topology information stored in its topology table, using a modification of Dijkstra's algorithm. To minimize overhead, each node reports only *part* of its source tree to neighbors. TBRPF uses a combination of periodic and differential updates to keep all neighbors informed of the reported part of its source tree. Each node also has the option to report additional topology information (up to the full topology), to provide improved robustness in highly mobile networks. TBRPF performs neighbor discovery using "differential" HELLO messages which report only *changes* in the status of neighbors. This results in HELLO messages that are much smaller than those of other link-state routing protocols such as OSPF.
リバースパス転送（TBRPF）に基づくトポロジの普及は、各宛先への最短パスに沿ってホップバイホップルーティングを提供するモバイルアドホックネットワーク向けに設計されたプロアクティブなリンク状態ルーティングプロトコルです。TBRPFを実行する各ノードは、Dijkstraのアルゴリズムの変更を使用して、トポロジテーブルに保存されている部分トポロジ情報に基づいて、ソースツリー（すべての到達可能なノードへのパスを提供する）を計算します。オーバーヘッドを最小限に抑えるために、各ノードはソースツリーのパーツ *のみをネイバーに報告します。TBRPFは、周期的な更新と微分アップデートの組み合わせを使用して、すべての隣人にそのソースツリーの報告された部分を通知し続けます。各ノードには、追加のトポロジ情報（完全なトポロジーまで）を報告するオプションもあり、高度にモバイルネットワークの堅牢性が向上します。TBRPFは、隣人のステータスを *変更 *のみ *変更 *する「微分」ハローメッセージを使用して、近隣発見を実行します。これにより、OSPFなどの他のリンク状態ルーティングプロトコルのメッセージよりもはるかに小さいハローメッセージが表示されます。
Table of Contents
目次
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements. . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Applicability Section . . . . . . . . . . . . . . . . . . . . 5
5. TBRPF Overview. . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Overview of Neighbor Discovery . . . . . . . . . . . . 6
5.2. Overview of the Routing Module. .. . . . . . . . . . . 8
6. TBRPF Packets . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. TBRPF Packet Header. . . . . . . . . . . . . . . . . . 10
6.2. TBRPF Packet Body. . . . . . . . . . . . . . . . . . . 11
6.2.1. Padding Options (TYPE = 0 thru 1). . . . . . . 12
6.2.2. Messages (TYPE = 2 thru 10). . . . . . . . . . 13
7. TBRPF Neighbor Discovery. . . . . . . . . . . . . . . . . . . 13
7.1. HELLO Message Format . . . . . . . . . . . . . . . . . 13
7.2. Neighbor Table . . . . . . . . . . . . . . . . . . . . 14
7.3. Sending HELLO Messages . . . . . . . . . . . . . . . . 15
7.4. Processing a Received HELLO Message. . . . . . . . . . 16
7.5. Expiration of Timer nbr_life . . . . . . . . . . . . . 18
7.6. Link-Layer Failure Notification. . . . . . . . . . . . 18
7.7. Optional Link Metrics. . . . . . . . . . . . . . . . . 18
7.8. Configurable Parameters. . . . . . . . . . . . . . . . 19
8. TBRPF Routing Module. . . . . . . . . . . . . . . . . . . . . 19
8.1. Conceptual Data Structures . . . . . . . . . . . . . . 19
8.2. TOPOLOGY UPDATE Message Format . . . . . . . . . . . . 21
8.3. Interface, Host, and Network Prefix Association
Message Formats. . . . . . . . . . . . . . . . . . . . 23
8.4. TBRPF Routing Operation. . . . . . . . . . . . . . . . 24
8.4.1. Periodic Processing. . . . . . . . . . . . . . 24
8.4.2. Updating the Source Tree and Topology
Graph. . . . . . . . . . . . . . . . . . . . . 25
8.4.3. Updating the Routing Table . . . . . . . . . . 26
8.4.4. Updating the Reported Node Set . . . . . . . . 27
8.4.5. Generating Periodic Updates. . . . . . . . . . 29
8.4.6. Generating Differential Updates. . . . . . . . 29
8.4.7. Processing Topology Updates. . . . . . . . . . 30
8.4.8. Expiring Topology Information. . . . . . . . . 32
8.4.9. Optional Reporting of Redundant Topology
Information. . . . . . . . . . . . . . . . . . 32
8.4.10. Local Topology Changes . . . . . . . . . . . . 33
8.4.11. Generating Association Messages. . . . . . . . 34
8.4.12. Processing Association Messages. . . . . . . . 36
8.4.13. Non-Relay Operation. . . . . . . . . . . . . . 37
8.5. Configurable Parameters. . . . . . . . . . . . . . . . 38
9. TBRPF Flooding Mechanism. . . . . . . . . . . . . . . . . . . 38
10. Operation of TBRPF in Mobile Ad-Hoc Networks. . . . . . . . . 39
10.1. Data Link Layer Assumptions. . . . . . . . . . . . . . 39
10.2. Network Layer Assumptions. . . . . . . . . . . . . . . 39
10.3. Optional Automatic Address Resolution. . . . . . . . . 40
10.4. Support for Multiple Interfaces and/or
Alias Addresses. . . . . . . . . . . . . . . . . . . . 40
10.5. Support for Network Prefixes . . . . . . . . . . . . . 40
10.6. Support for non-MANET Hosts. . . . . . . . . . . . . . 40
10.7. Internet Protocol Considerations . . . . . . . . . . . 41
10.7.1. IPv4 Operation . . . . . . . . . . . . . . . . 41
10.7.2. IPv6 Operation . . . . . . . . . . . . . . . . 41
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
12. Security Considerations . . . . . . . . . . . . . . . . . . . 42
13. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 42
14. References. . . . . . . . . . . . . . . . . . . . . . . . . . 42
14.1. Normative References . . . . . . . . . . . . . . . . . 42
14.2. Informative References . . . . . . . . . . . . . . . . 43
Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . 45
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 46
Topology Dissemination Based on Reverse-Path Forwarding (TBRPF) is a proactive, link-state routing protocol designed for mobile ad-hoc networks (MANETs), which provides hop-by-hop routing along shortest paths to each destination. Each node running TBRPF computes a source tree (providing shortest paths to all reachable nodes) based on partial topology information stored in its topology table, using a modification of Dijkstra's algorithm. To minimize overhead, each node reports only *part* of its source tree to neighbors.
リバースパス転送（TBRPF）に基づくトポロジの普及は、各宛先への最短パスに沿ってホップバイホップルーティングを提供するモバイルアドホックネットワーク（MANETS）向けに設計されたプロアクティブなリンク状態ルーティングプロトコルです。TBRPFを実行する各ノードは、Dijkstraのアルゴリズムの変更を使用して、トポロジテーブルに保存されている部分トポロジ情報に基づいて、ソースツリー（すべての到達可能なノードへの最短パスを提供する）を計算します。オーバーヘッドを最小限に抑えるために、各ノードはソースツリーのパーツ *のみをネイバーに報告します。
TBRPF uses a combination of periodic and differential updates to keep all neighbors informed of the reported part of its source tree. Each node also has the option to report addition topology information (up to the full topology), to provide improved robustness in highly mobile networks.
TBRPFは、周期的な更新と微分アップデートの組み合わせを使用して、すべての隣人にそのソースツリーの報告された部分を通知し続けます。また、各ノードには、高度にモバイルネットワークの堅牢性が向上するために、追加トポロジ情報（完全なトポロジーまで）を報告するオプションもあります。
TBRPF performs neighbor discovery using "differential" HELLO messages which report only *changes* in the status of neighbors. This results in HELLO messages that are much smaller than those of other link-state routing protocols such as OSPF [6].
TBRPFは、隣人のステータスを *変更 *のみ *変更 *する「微分」ハローメッセージを使用して、近隣発見を実行します。これにより、OSPF [6]などの他のリンク状態ルーティングプロトコルよりもはるかに小さいハローメッセージが表示されます。
TBRPF consists of two modules: the neighbor discovery module and the routing module (which performs topology discovery and route computation). An overview of these modules is given in Section 5.
TBRPFは、近隣発見モジュールとルーティングモジュールの2つのモジュールで構成されています（トポロジの発見とルートの計算を実行します）。これらのモジュールの概要は、セクション5に記載されています。
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL", when they appear in this document, are to be interpreted as described in BCP 14, RFC 2119 [1].
キーワードは「必要」、「必要」、「必須」、「shill」、「shall "、" sulld "、" nove "、" bulsed "、" may "、" optional "が表示されます。このドキュメントは、BCP 14、RFC 2119 [1]に記載されているように解釈されます。
This document also makes use of internal conceptual variables to describe protocol behavior and external variables that an implementation must allow system administrators to change. The specific variable names, how their values change, and how their settings influence protocol behavior are provided to demonstrate protocol behavior. An implementation is not required to have them in the exact form described here, so long as its external behavior is consistent with that described in this document.
また、このドキュメントでは、内部概念変数を使用して、プロトコルの動作と、実装によりシステム管理者が変更できるようにする外部変数を説明しています。特定の変数名、その値の変化方法、およびその設定がプロトコルの動作に提供される方法が提供され、プロトコルの動作を実証します。このドキュメントで説明されているものと外部の動作が一致している限り、実装はここで説明する正確な形式でそれらを使用する必要はありません。
The following terms are used to describe TBRPF:
次の用語は、TBRPFを説明するために使用されます。
node A router that implements TBRPF.
TBRPFを実装するルーターをノードします。
router ID Each node is identified by a unique 32-bit router ID (RID), which for IPv4 is typically equal to the IP address of one of its interfaces. The term "node u" denotes the node whose RID is equal to u.
ルーターID各ノードは、一意の32ビットルーターID（RID）によって識別されます。これは、IPv4の場合は通常、そのインターフェイスの1つのIPアドレスに等しくなります。「ノードu」という用語は、ridがuに等しいノードを示します。
interface A node's attachment to a communication facility or medium through which it can communicate with other nodes. A node can have multiple interfaces. An interface can be wireless or wired, and can be broadcast (e.g., Ethernet) or point-to-point. Each interface is identified by its IP address. The term "interface I" denotes the interface whose IP address is I.
インターフェイス他のノードと通信できる通信施設またはメディアへのノードの添付ファイル。ノードには複数のインターフェイスがあります。インターフェイスはワイヤレスまたは有線であり、ブロードキャスト（イーサネットなど）またはポイントツーポイントを使用できます。各インターフェイスは、IPアドレスによって識別されます。「インターフェイスI」という用語は、IPアドレスがIであるインターフェイスを示します。
link A link is an ordered pair of interfaces (I,J) where I and J are on two different nodes, and where interface I has recently received packets sent from interface J. A link (i,j) from node i to node j is said to exist if node i has an interface I and node j has an interface J such that (I,J) is a link. Nodes i and j are called the "tail" and "head" of the link, respectively.
リンクリンクは、IとJが2つの異なるノード上にあるインターフェイスの順序付きペア（I、j）で、インターフェイスが最近インターフェイスJから送信されたパケットを受け取った場所です。ノードIがインターフェイスIとノードJにインターフェイスjがある場合、（i、j）がリンクである場合、存在すると言われています。ノードIとJは、それぞれリンクの「テール」と「ヘッド」と呼ばれます。
bidirectional link A link (I,J) such that interfaces I and J can both hear each other. Also called a 2-way link.
双方向リンクIとインターフェイスIとJの両方がお互いを聞くことができるようにするリンク（I、J）。2ウェイリンクとも呼ばれます。
neighbor node A node j is said to be a neighbor of node i if node i can hear node j on some interface. Node j is said to be a 2-way neighbor if there is a bidirectional link between i and j.
ネイバーノードAノードJは、ノードIの近隣であると言われています。ノードがインターフェイスでノードJを聞くことができます。IとJの間に双方向のリンクがある場合、ノードJは2ウェイネイバーであると言われています。
MANET interface Any wireless interface such that two neighbor nodes on the interface need not be neighbors of each other. MANET nodes typically have at least one MANET interface, but this is not a requirement.
MANETインターフェイスインターフェイス上の2つの隣接ノードが互いに隣接する必要はないように、ワイヤレスインターフェイスは任意です。MANETノードには通常、少なくとも1つのMANETインターフェイスがありますが、これは要件ではありません。
topology
The topology of the network is described by a graph G = (V, E),
where V is the set of nodes u and E is the set of links (u,v) in
the network.
source tree The directed tree (denoted T) computed by each node that provides shortest paths to all other reachable nodes.
ソースツリー他のすべての到達可能なノードに最短のパスを提供する各ノードで計算された指向ツリー（theded t）。
topology update A message that reports the state of one or more links.
トポロジ1つ以上のリンクの状態を報告するメッセージを更新します。
parent The parent of node i for node u is the next node on the computed shortest path from node i to node u.
親の親は、ノードuのノードIの親は、ノードIからノードuまでの計算された最短パスの次のノードです。
predecessor The predecessor of a node v on the source tree is the node u such that the link (u,v) is in the source tree.
前身ソースツリー上のノードVの前身は、リンク（u、v）がソースツリーにあるようにノードuです。
leaf node A leaf node of the source tree is a node on the source tree that is not the predecessor of any other node on the source tree.
リーフノードソースツリーのリーフノードは、ソースツリー上のノードであり、ソースツリー上の他のノードの前身ではありません。
proactive routing protocol A routing protocol in which each node maintains routes to all reachable destinations at all times, whether or not there is currently any need to deliver packets to those destinations. In contrast, an "on-demand" routing protocol discovers and maintains routes only when they are needed.
プロアクティブルーティングプロトコル各ノードが常にすべての到達可能な目的地へのルートを維持するルーティングプロトコル。現在、それらの宛先にパケットを配信する必要があるかどうか。対照的に、「オンデマンド」ルーティングプロトコルは、必要な場合にのみルートを発見し、維持します。
TBRPF is a proactive routing protocol designed for mobile ad-hoc networks (MANETs). It can support networks with up to a few hundred nodes, and can be combined with hierarchical routing techniques to support much larger networks. Because it employs techniques to greatly reduce control traffic, TBRPF can support much larger and denser networks than routing protocols based on the classical link-state algorithm (e.g., OSPF).
TBRPFは、モバイルアドホックネットワーク（MANET）向けに設計されたプロアクティブルーティングプロトコルです。最大数百ノードのネットワークをサポートでき、階層的なルーティング手法と組み合わせて、はるかに大きなネットワークをサポートできます。制御トラフィックを大幅に削減する手法を使用しているため、TBRPFは、古典的なリンク状態アルゴリズム（例：OSPF）に基づいて、ルーティングプロトコルよりもはるかに大きく密度の高いネットワークをサポートできます。
The number of nodes that can be supported depends on several factors, including the MAC data rate, the rate of topology changes, and the network density (average number of neighbors). Simulations have been reported in which TBRPF has supported as many as 500 nodes. In simulations with 100 nodes and 20 traffic streams (sources), using IEEE 802.11 with a data rate of 2 Mbps, TBRPF was found to generate approximately 80-120 kb/s of routing control traffic for the scenarios considered, which compared favorably with other MANET routing protocols [7][8]. A proof of correctness for TBRPF can be found in references [8] and [9].
サポートできるノードの数は、MACデータレート、トポロジの変化のレート、ネットワーク密度（近隣の平均数）など、いくつかの要因に依存します。TBRPFが最大500のノードをサポートしているシミュレーションが報告されています。2 MbpsのデータレートでIEEE 802.11を使用して、100のノードと20のトラフィックストリーム（ソース）を備えたシミュレーションでは、TBRPFが考慮されるシナリオに対して約80〜120 kb/sのルーティング制御トラフィックを生成することがわかりました。MANETルーティングプロトコル[7] [8]。TBRPFの正しさの証明は、参照[8]および[9]に記載されています。
TBRPF consists of two main modules: the neighbor discovery module, and the routing module (which performs topology discovery and route computation).
TBRPFは、近隣発見モジュールとルーティングモジュールの2つの主要なモジュールで構成されています（トポロジの発見とルートの計算を実行します）。
The TBRPF Neighbor Discovery (TND) protocol allows each node i to quickly detect the neighbor nodes j such that a bidirectional link (I,J) exists between an interface I of node i and an interface J of node j. The protocol also quickly detects when a bidirectional link breaks or becomes unidirectional.
TBRPF Neighbor Discovery（TND）プロトコルにより、各ノードIはNeighterノードJをすばやく検出できるため、ノードIのインターフェイスIとノードJのインターフェイスJの間に双方向リンク（I、J）が存在します。また、プロトコルは、双方向リンクが壊れたり、単方向になったときに迅速に検出します。
The key feature of TND is that it uses "differential" HELLO messages which report only *changes* in the status of links. This results in HELLO messages that are much smaller than those of other link-state routing protocols such as OSPF, in which each HELLO message includes the IDs of *all* neighbors. As a result, HELLO messages can be sent more frequently, which allows faster detection of topology changes.
TNDの重要な特徴は、リンクのステータスに「変更」のみを報告する「微分」ハローメッセージを使用することです。これにより、OSPFなどの他のLink-Stateルーティングプロトコルよりもはるかに小さいHelloメッセージが表示されます。このメッセージには、各Helloメッセージには * All * NeigborsのIDが含まれます。その結果、Helloメッセージをより頻繁に送信でき、トポロジの変更をより速く検出できます。
TND is designed to be fully modular and independent of the routing module. TND performs ONLY neighbor sensing, i.e., it determines which nodes are (1-hop) neighbors. In particular, it does not discover 2-hop neighbors (which is handled by the routing module). As a result, TND can be used by other routing protocols, and TBRPF can use another neighbor discovery protocol in place of TND, e.g., one provided by the link layer.
TNDは、完全にモジュール式であり、ルーティングモジュールから独立するように設計されています。TNDは隣接センシングのみを実行します。つまり、どのノードが（1ホップ）隣接しているかを決定します。特に、2ホップの隣人（ルーティングモジュールによって処理されます）を発見しません。その結果、TNDは他のルーティングプロトコルで使用でき、TBRPFはTNDの代わりに別の隣接ディスカバリープロトコルを使用できます。たとえば、リンクレイヤーによって提供されるものです。
Nodes with multiple interfaces run TND separately on each interface, similar to OSPF. Thus, a neighbor table is maintained for each local interface, and a HELLO sent on a particular interface contains only information regarding neighbors heard on that interface.
複数のインターフェイスを持つノードは、OSPFと同様に、各インターフェイスでTNDを個別に実行します。したがって、ローカルインターフェイスごとに隣のテーブルが維持され、特定のインターフェイスで送信されたHelloには、そのインターフェイスで聞いた隣人に関する情報のみが含まれています。
We note that, in wireless networks, it is possible for a single interface I to receive packets from multiple interfaces J associated with the same neighbor node. This could happen, for example, if the neighbor uses a directional antenna with different interfaces representing different beams. For this reason, TBRPF includes neighbor interface addresses in HELLO messages, unlike OSPF, which includes only router IDs in HELLO packets.
ワイヤレスネットワークでは、単一のインターフェイスIが同じ近隣ノードに関連付けられた複数のインターフェイスjからパケットを受信する可能性があることに注意してください。これは、たとえば、隣人が異なるビームを表す異なる界面を持つ方向アンテナを使用する場合に発生する可能性があります。このため、TBRPFには、Hello PacketにルーターIDのみを含むOSPFとは異なり、Hello MessagesのNeighbor Interfaceアドレスが含まれています。
Each TBRPF node maintains a neighbor table for each local interface I, which stores state information for each neighbor interface J heard on that interface, i.e., for each link (I,J) between interface I and a neighbor interface J. The status of each link can be 1-WAY, 2-WAY, or LOST. The neighbor table for interface I determines the contents of HELLO messages sent on interface I, and is updated based on HELLO messages received on interface I (and possibly on link-layer notifications).
各TBRPFノードは、各ローカルインターフェイスIの近隣テーブルを維持します。各インターフェイスIは、そのインターフェイスで聞いた各隣接インターフェイスJの状態情報、つまりインターフェイスIと隣接インターフェイスJの間の各リンク（I、j）の状態情報を保存します。リンクは、1ウェイ、2ウェイ、または紛失することができます。インターフェースIの隣のテーブルIは、インターフェイスIで送信されたHelloメッセージの内容を決定し、インターフェイスI（および場合によってはリンク層通知）で受信したHelloメッセージに基づいて更新されます。
Each TBRPF node sends (on each interface) at least one HELLO message per HELLO_INTERVAL. Each HELLO message contains three (possibly empty) lists of neighbor interface addresses (which are formatted as three message subtypes): NEIGHBOR REQUEST, NEIGHBOR REPLY, and NEIGHBOR LOST. Each HELLO message also contains the current HELLO sequence number (HSEQ), which is incremented with each transmitted HELLO.
各TBRPFノードは、（各インターフェイスで）Hello_intervalごとに少なくとも1つのハローメッセージを送信します。各helloメッセージには、近隣インターフェイスアドレス（3つのメッセージサブタイプとしてフォーマットされている）の3つの（おそらく空の）リストが含まれています：ネイバーリクエスト、ネイバー返信、および隣人が紛失します。各Helloメッセージには、現在のHello Sequence番号（HSEQ）も含まれています。これは、送信されたHelloで増加します。
In the following overview of the operation of TND, we assume that interface I belongs to node i, and interface J belongs to node j. When a node i changes the status of a link (I,J), it includes the neighbor interface address J in the appropriate list (NEIGHBOR REQUEST/REPLY/LOST) in at most NBR_HOLD_COUNT (typically 3) consecutive HELLOs sent on interface I. This ensures that node j will either receive one of these HELLOs on interface J, or will miss NBR_HOLD_COUNT HELLOs and thus declare the link (J,I) to be LOST. This technique makes it unnecessary for a node to include each 1-WAY or 2-WAY neighbor in HELLOs indefinitely, unlike OSPF.
TNDの操作の次の概要では、インターフェイスIがノードIに属し、インターフェイスjはノードjに属していると仮定します。ノードiがリンクのステータス（i、j）を変更すると、最大のnbr_hold_count（通常3）で適切なリスト（neighbor request/neply/lost）に近隣インターフェイスアドレスjが含まれます。これにより、ノードJがインターフェイスJでこれらのHELLOSの1つを受信するか、NBR_HOLD_COUNT HELLOSを見逃し、リンク（J、I）が失われると宣言されます。この手法により、ノードは、OSPFとは異なり、Hellosにそれぞれの1方向または2方向の隣人を無期限に含める必要がありません。
To avoid establishing a link that is likely to be short lived (i.e., to employ hysteresis), node i must receive (on interface I) at least HELLO_ACQUIRE_COUNT (e.g., 2) of the last HELLO_ACQUIRE_WINDOW (e.g., 3) HELLOs sent from a neighbor interface J, before declaring the link (I,J) to be 1-WAY. When this happens, node i includes J in the NEIGHBOR REQUEST list in each of its next NBR_HOLD_COUNT HELLO messages sent on interface I, or until a NEIGHBOR REPLY message containing I is received on interface I from neighbor interface J.
短命である可能性が高いリンクの確立を避けるため（つまり、ヒステリシスを採用するために）、少なくともインターフェイスIで受け取る必要があるノード（少なくともhello_acquire_count（例えば、2））は、最後のhello_acquire_window（例えば、3）から送信されました。リンク（i、j）が1ウェイであると宣言する前に、隣のインターフェイスj。これが発生した場合、ノードIは、次のNBR_HOLD_COUNT INTERFACE Iで送信された次のNBR_HOLD_COUNT Helloメッセージのそれぞれに、またはINTERFACE IにINTERFACE Iで受信されるようになるまで、次のNBR_hold_Count Helloメッセージにjを含めます。
If node j receives (on interface J) one of the HELLOs sent from interface I that contains J in the NEIGHBOR REQUEST list, then node j declares the link (J,I) to be 2-WAY (unless it is already 2-WAY), and includes I in the NEIGHBOR REPLY list in each of its next NBR_HOLD_COUNT HELLO messages sent on interface J. Upon receiving one of these HELLOs on interface I, node i declares the link (I,J) to be 2-WAY.
Node jが[インターフェイスJで）を受信した場合、インターフェイスIから隣接要求リストにJを含むInterface Iから送信された場合、Node Jはリンク（j、i）を2ウェイであると宣言します（すでに2方向である場合を除きます）、および次のNBR_HOLD_COUNTインターフェイスJに送信された次のNBR_HOLD_COUNT HelloメッセージのそれぞれにIを含めます。インターフェイスIでこれらのHellosの1つを受信すると、Node Iはリンク（i、j）が2方向であると宣言します。
If node i receives a HELLO on interface I, sent from neighbor interface J, whose HSEQ indicates that at least NBR_HOLD_COUNT HELLOs were missed, or if node i receives no HELLO on interface I sent from interface J within NBR_HOLD_TIME seconds, then node i changes the status of link (I,J) to LOST (unless it is already LOST), and includes J in the NEIGHBOR LOST list in each of its next NBR_HOLD_COUNT HELLO messages sent on interface I (unless the link changes status before these transmissions are complete). Node j will either receive one of these HELLOs on interface J or will miss NBR_HOLD_COUNT HELLOs; in either case, node j will declare the link (J,I) to be LOST. In this manner, both nodes will agree that the link between I and J is no longer bidirectional, even if node j can still hear HELLOs from node i.
Node IがインターフェイスIでHelloを受信した場合、HESEQが少なくともNBR_HOLD_COUNT HELLOSが見逃されたことを示すNeighbor Interface Jから送信された場合、またはNBR_HOLD_TIME秒以内にインターフェイスjから送信したインターフェイスでhelloを受信しない場合、ノードIが変更されます。リンクのステータス（i、j）から紛失（既に失われていない限り）、および次のNBR_hold_countの各インターフェイスIで送信された各nbr_hold_countハローメッセージにjを含む（これらの送信が完了する前にリンクが変更されない限り）。Node Jは、インターフェイスJでこれらのHellosの1つを受け取るか、NBR_hold_Count Hellosを見逃します。どちらの場合でも、ノードJはリンク（j、i）が失われると宣言します。この方法で、両方のノードは、ノードJがNode IからHellosを聞くことができる場合でも、IとJの間のリンクが双方向ではなくなったことに同意します。
Each node may maintain and update one or more link metrics for each link (I,J) from a local interface I to a neighbor interface J, representing the quality of the link. Such link metrics can be used as additional conditions for changing the status of a neighbor, based on the link metric going above or below some threshold. TBRPF also allows link metrics to be advertised in topology updates, and to be used for computing shortest paths.
各ノードは、各リンク（i、j）の1つまたは複数のリンクメトリックをローカルインターフェイスIから近隣インターフェイスjに維持および更新し、リンクの品質を表します。このようなリンクメトリックは、一部のしきい値の上または下に移動するリンクメトリックに基づいて、隣人のステータスを変更するための追加条件として使用できます。TBRPFでは、リンクメトリックをトポロジの更新で宣伝し、最短パスの計算に使用することもできます。
Each node running TBRPF maintains a source tree, denoted T, which provides shortest paths to all reachable nodes. Each node computes and updates its source tree based on partial topology information stored in its topology table, using a modification of Dijkstra's algorithm. To minimize overhead, each node reports only part of its source tree to neighbors. The main idea behind the current version of TBRPF came from PTSP [10], another protocol in which each node reports only part of its source tree. (However, TBRPF differs from PTSP in several ways.) The current version of TBRPF should not be confused with its previous version [11], which is a full-topology routing protocol.
TBRPFを実行している各ノードは、すべての到達可能なノードに最短パスを提供するTを示したソースツリーを維持します。各ノードは、Dijkstraのアルゴリズムの変更を使用して、トポロジテーブルに保存されている部分トポロジ情報に基づいてソースツリーを計算および更新します。オーバーヘッドを最小限に抑えるために、各ノードはソースツリーの一部のみを近隣に報告します。TBRPFの現在のバージョンの背後にある主なアイデアは、各ノードがソースツリーの一部のみを報告する別のプロトコルであるPTSP [10]から来ました。（ただし、TBRPFはいくつかの方法でPTSPとは異なります。）TBRPFの現在のバージョンは、フルトポロジールーティングプロトコルである以前のバージョン[11]と混同しないでください。
The part of T that a node reports to neighbors is called the "reported subtree" and is denoted RT. Each node reports RT to neighbors in *periodic* topology updates (e.g., every 5 seconds), and reports changes (additions and deletions) to RT in more frequent *differential* updates (e.g., every 1 second). Periodic updates inform new neighbors of RT, and ensure that each neighbor eventually learns RT even if it does not receive all updates. Differential updates ensure the fast propagation of each topology update to all nodes that are affected by the update. A received topology update is not forwarded, but *may* result in a change to RT, which will be reported in the next differential or periodic update. Whenever possible, topology updates are included in the same packet as a HELLO message, to minimize the number of control packets sent. TBRPF does not require reliable or sequenced delivery of messages, and does not use ACKs or NACKs.
ノードがネイバーに報告するTの部分は「報告されたサブツリー」と呼ばれ、rtと表示されます。各ノードは、 *定期的な *トポロジの更新（5秒ごとに）の近隣にRTを報告し、より頻繁な *差動 *更新（例：1秒ごと）で変更（追加と削除）をRTに報告します。定期的な更新は、RTの新しい隣人に通知し、すべての更新を受け取っていなくても、各隣人がRTを最終的に学習することを確認します。差分更新により、各トポロジアップデートが更新の影響を受けるすべてのノードへの高速伝播が保証されます。受信したトポロジの更新は転送されませんが、 * RTの変更が発生する可能性があります。可能な場合はいつでも、トポロジの更新は、Helloメッセージと同じパケットに含まれており、送信されるコントロールパケットの数を最小限に抑えます。TBRPFは、メッセージの信頼できるまたはシーケンスされた配信を必要とせず、AcksまたはNacksを使用しません。
TBRPF supports multiple interfaces, associated hosts, and network prefixes. Information regarding associated interfaces, hosts, and prefixes is disseminated efficiently in periodic and differential updates, similar to the dissemination of topology updates.
TBRPFは、複数のインターフェイス、関連ホスト、およびネットワークプレフィックスをサポートします。関連するインターフェイス、ホスト、および接頭辞に関する情報は、トポロジの更新の普通と同様に、周期的および微分アップデートで効率的に普及しています。
The reported subtree RT consists of links (u,v) of T such that u is in the "reported node set" RN, which is computed as follows. Node i includes a neighbor j in RN if and only if node i determines that one of its neighbors may select i to be its next hop on its shortest path to j. To make this determination, node i computes the shortest paths, up to 2 hops, from each neighbor to each other neighbor, using only neighbors (or node i itself) as an intermediate node, and using relay priority (included in HELLO messages) and router ID to break ties. After a node determines which neighbors are in RN, each reachable node u is included in RN if and only if the next hop on the shortest path to u is in RN. A node also includes itself in RN. As a result, the reported subtree RT includes the subtrees of T that are rooted at neighbors in RN, and also includes all local links to neighbors.
報告されたサブツリーRTは、uが「報告されたノードセット」RNにあるように、tのリンク（u、v）で構成されています。これは次のように計算されます。ノードIには、Node IがNode Iがjへの最短パスで次のホップになるようにiを選択できると判断した場合にのみ、RNに近隣jが含まれます。この決定を行うために、ノードIは、隣の隣から隣の隣に、最短パス、最大2ホップ、隣の隣に、近隣（またはノードI自体）のみを中間ノードとして使用し、リレーの優先度（ハローメッセージに含まれる）を使用して計算します。ネクタイを破るルーターID。ノードがRNにいる隣接が決定した後、uへの次のホップがRNにある場合にのみ、各到達可能なノードuがRNに含まれます。ノードには、RNにも含まれています。その結果、報告されたサブツリーRTには、RNの近隣に根が張られているTのサブツリーが含まれ、近隣へのすべてのローカルリンクも含まれています。
We note that neighbors in RN are analogous to multipoint relay (MPR) selectors [12]. Thus, if node i selects neighbor j to be in RN, then node i effectively selects itself to be an MPR of node j. This is quite different from [12], in which a node does not select itself to be an MPR, but selects a subset of its neighbors to be MPRs.
RNの近隣は、マルチポイントリレー（MPR）セレクターに類似していることに注意してください[12]。したがって、ノードIがnighbor jをRNに選択する場合、ノードIは効果的にノードjのMPRに選択します。これは[12]とはまったく異なります。この場合、ノードはそれ自体をMPRに選択しませんが、その近隣のサブセットをMPRに選択します。
A node with a larger relay priority reports a larger part of its source tree (on average), and is more likely to be selected as a next-hop relay by its neighbors. A node with relay priority equal to 0 is called a non-relay node, and never forwards packets originating from other nodes.
リレーの優先度が大きいノードは、ソースツリーの大部分を（平均して）報告しており、その近隣者が次のホップリレーとして選択する可能性が高くなります。0に等しいリレーの優先度を持つノードは、非関連ノードと呼ばれ、他のノードから発生するパケットを転送することはありません。
TBRPF does not use sequence numbers for topology updates, thus reducing message overhead and avoiding wraparound problems. Instead, a technique similar to SPTA [13] is used in which, for each link (u,v) reported by one or more neighbors, only the next hop p(u) to u is believed regarding the state of the link. (However, in SPTA each node reports the full topology.) Using this technique, each node maintains a topology graph TG, consisting of links that are believed to be up, and computes T as the shortest-path tree within TG. To allow immediate rerouting, the restriction that each link (u,v) in TG must be reported by p(u) is relaxed temporarily if p(u) changes to a neighbor that is not reporting the link.
TBRPFは、トポロジの更新にシーケンス番号を使用しないため、メッセージのオーバーヘッドを減らし、ラップアラウンドの問題を回避します。代わりに、SPTA [13]に類似した手法が使用されます。この手法では、1つ以上の隣人によって報告された各リンク（u、v）について、リンクの状態に関して次のホップp（u）のみが考えられます。（ただし、SPTAでは、各ノードが完全なトポロジを報告しています。）この手法を使用して、各ノードは、上にあると考えられているリンクで構成されるトポロジグラフTGを維持し、TをTG内で最も短いパスツリーとして計算します。即時の再ルーティングを可能にするために、p（u）によってp（u）によってTGの各リンク（u、v）を報告する必要がある場合、p（u）がリンクを報告していない隣人に変更する場合、一時的に緩和されます。
Each node is required to report RT, but may report additional links, e.g., to provide increased robustness in highly mobile networks. More precisely, a node may maintain any subgraph H of TG that contains T, and report the reported subgraph RH, which consists of links (u,v) of H such that u is in RN. For example, H can equal TG, which would provide each node with the full network topology if this is done by all nodes. H can also be a biconnected subgraph that contains T, which would provide each node with two disjoint paths to each other node, if this is done by all nodes.
各ノードはRTを報告するために必要ですが、高度にモバイルネットワークで堅牢性を高めるために、追加のリンクを報告する場合があります。より正確には、ノードはTを含むTGのサブグラフHを維持し、uがRNにあるようにHのリンク（u、v）で構成されるサブグラフrhを報告することができます。たとえば、HはTGに等しくなります。これは、すべてのノードによって行われた場合、各ノードに完全なネットワークトポロジを提供します。Hは、tを含むバイコン接続サブグラフでもあります。これは、すべてのノードによって行われた場合、各ノードに相互ノードに2つの分離パスを提供します。
TBRPF allows the option to include link metrics in topology updates, and to compute paths that are shortest with respect to the metric. This allows packets to be sent along paths that are higher quality than minimum-hop paths.
TBRPFでは、トポロジの更新にリンクメトリックを含めるオプションを使用し、メトリックに関して最も短いパスを計算することができます。これにより、最小ホップパスよりも高品質のパスに沿ってパケットを送信できます。
TBRPF allows path optimality to be traded off in order to reduce the amount of control traffic in networks with a large diameter, where the degree of approximation is determined by the configurable parameter NON_TREE_PENALTY.
TBRPFを使用すると、パスの最適性をトレードオフにすることができます。ネットワーク内のコントロールトラフィックの量を大きな直径で減らすことができます。ここで、近似の程度は構成可能なパラメーターnon_tree_penaltyによって決定されます。
Nodes send TBRPF protocol data in contiguous units known as packets. Each packet includes a header, optional header extensions, and a body comprising one or more messages and padding options as needed. To facilitate efficient receiver processing, senders SHOULD insert padding options as necessary to align multi-octet words within the TBRPF packet on natural boundaries (i.e., modulo-8/4/2 addresses for 64/32/16-bit words, respectively). Receivers MUST be capable of processing multi-octet words whether or not aligned on natural boundaries. The following sections specify elements of the TBRPF packet in more detail.
ノードは、パケットとして知られている連続ユニットでTBRPFプロトコルデータを送信します。各パケットには、ヘッダー、オプションのヘッダー拡張機能、および必要に応じて1つ以上のメッセージとパディングオプションを含むボディが含まれています。効率的なレシーバー処理を容易にするために、送信者は、TBRPFパケット内のマルチオクテットワードを自然境界に並べるために、必要に応じてパディングオプションを挿入する必要があります（つまり、それぞれ64/32/16ビット単語のModulo-8/4/2アドレス）。受信者は、自然境界に揃っているかどうかにかかわらず、マルチオクターンの単語を処理できる必要があります。次のセクションでは、TBRPFパケットの要素をより詳細に指定します。
TBRPF packet headers are variable-length (minimum one octet). The format for the packet header is as follows:
TBRPFパケットヘッダーは可変（最小1オクテット）です。パケットヘッダーの形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers |L|I|R|R| Reserved | Header Extensions ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version (4 bits)
The TBRPF version number. This specification documents version 4
of the protocol.
Flags (4 bits) Two bits (L,I) specify which header extensions (if any) follow. Two bits (R) are reserved for future use, and MUST be zero. Any extensions specified by these bits MUST appear in the same order as the bits (i.e., first L, then I) as follows:
フラグ（4ビット）2ビット（L、i）どのヘッダー拡張機能（ある場合）が続くかを指定します。2ビット（R）は将来の使用のために予約されており、ゼロでなければなりません。これらのビットで指定された拡張機能は、次のようにビット（つまり、最初のl、i）と同じ順序で表示する必要があります。
L - Length included If the underlying delivery service provides a length field, the sender MAY set L = '0' and omit the length extension. Otherwise, the sender MUST set L = '1' and include a 16-bit unsigned integer length immediately after any previous header field. The length includes all header and data bytes and is written into the length field in network byte order.
l-基礎となる配送サービスが長さフィールドを提供する場合、送信者はl = '0'を設定し、長さの拡張を省略することができます。それ以外の場合、送信者はl = '1'を設定し、以前のヘッダーフィールドの直後に16ビットの符号なし整数長を含める必要があります。長さには、すべてのヘッダーバイトとデータバイトが含まれ、ネットワークバイトの順序で長さフィールドに書き込まれます。
Receivers examine the L bit to determine whether the length field is present. If L = '1', the receiver reads the length field to determine the length of the TBRPF packet, including the TBRPF packet header. Receivers discard any TBRPF packet if neither the underlying delivery service nor the TBRPF packet header provide packet length.
レシーバーはLビットを調べて、長さフィールドが存在するかどうかを判断します。L = '1'の場合、受信機は長さフィールドを読み取り、TBRPFパケットヘッダーを含むTBRPFパケットの長さを決定します。基礎となる配送サービスもTBRPFパケットヘッダーもパケットの長さを提供しない場合、受信機はTBRPFパケットを破棄します。
I - Router ID (RID) included If the underlying delivery service encodes the sender's RID, the sender MAY set I = '0' and omit the RID field. Otherwise, the sender MUST set I = '1' and include a 4-octet RID in network byte order immediately after any previous header fields. The RID option provides a mechanism for implicit network-level address resolution. A receiver that detects a RID option SHOULD create a binding between the RID and the source address that appears in the network-level header.
I -Router ID（RID）が含まれています。基礎となる配送サービスが送信者のRIDをエンコードする場合、送信者はi = '0'を設定し、RIDフィールドを省略します。それ以外の場合、送信者はi = '1'を設定し、以前のヘッダーフィールドの直後にネットワークバイトの順序で4-OCTET RIDを含める必要があります。RIDオプションは、暗黙のネットワークレベルのアドレス解像度のメカニズムを提供します。RIDオプションを検出するレシーバーは、ネットワークレベルのヘッダーに表示されるRIDとソースアドレスの間にバインディングを作成する必要があります。
Reserved Reserved for future use; MUST be zero.
将来の使用のために予約された予約。ゼロでなければなりません。
The TBRPF packet body consists of the concatenation of one or more TBRPF messages (and padding options where necessary). Messages and padding options within the TBRPF packet body are encoded using the following format:
TBRPFパケット本体は、1つ以上のTBRPFメッセージ（および必要に応じてパディングオプション）の連結で構成されています。TBRPFパケット本体内のメッセージとパディングオプションは、次の形式を使用してエンコードされます。
+-+-+-+-+-+-+-+-+- - - - -
|OPTIONS| TYPE | VALUE
+-+-+-+-+-+-+-+-+- - - - -
OPTIONS (4 bits)
Four option bits that depend on TYPE.
TYPE (4 bits) Identifier for message type or padding option.
メッセージタイプまたはパディングオプションのタイプ（4ビット）識別子。
VALUE Variable-length field. (Format and length depend on TYPE, as described in the following sections.)
値変数長フィールド。（次のセクションで説明されているように、形式と長さはタイプに依存します。）
The sequence of elements MUST be processed strictly in the order they appear within the TBRPF packet body; a receiver must not, for example, scan through the packet body looking for a particular type of element prior to processing all preceding elements [2]. TBRPF packet elements include padding options and messages as described below.
一連の要素は、TBRPFパケット本体内に表示される順序で厳密に処理する必要があります。たとえば、すべての前の要素を処理する前に、特定のタイプの要素を探しているパケット本体をスキャンしてはなりません[2]。TBRPFパケット要素には、以下に説明するように、パディングオプションとメッセージが含まれます。
Senders MAY insert two types of padding options where necessary, e.g., to satisfy alignment requirements for other elements [2]. Padding options may occur anywhere within the TBRPF packet body. The following two padding options are defined:
送信者は、必要に応じて2種類のパディングオプションを挿入する場合があります。たとえば、他の要素のアライメント要件を満たすことができます[2]。パディングオプションは、TBRPFパケット本体内のどこでも発生する場合があります。次の2つのパディングオプションが定義されています。
Pad1 option (TYPE = 0)
PAD1オプション（type = 0）
+-+-+-+-+-+-+-+-+
| 0 | 0 |
+-+-+-+-+-+-+-+-+
The Pad1 option inserts one octet of padding into the TBRPF packet body; the VALUE field is omitted. If more than one octet of padding is required, the PadN option (described next) should be used, rather than multiple Pad1 options.
PAD1オプションは、1オクテットのパディングをTBRPFパケットボディに挿入します。値フィールドは省略されています。複数のパディングが必要な場合は、複数のPAD1オプションではなく、PADNオプション（次に説明）を使用する必要があります。
PadN option (TYPE = 1)
PADNオプション（type = 1）
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - - -
| 0 | 1 | LEN | Zero-valued Octets
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - - -
The PadN option inserts two or more octets of padding into the TBRPF packet body. The first octet of the VALUE field contains an 8-bit unsigned integer length containing a value between 0 - 253 which specifies the number of zero-valued octets that immediately follow, yielding a maximum total of 255 padding octets.
PADNオプションは、TBRPFパケット本体に2つ以上のパディングを挿入します。値フィールドの最初のオクテットには、0〜253の間の値を含む8ビットの非署名整数整数長が含まれています。
Additional message types are described as they occur in the following sections. Senders encode messages as specified by the individual message formats. Receivers detect errors in message construction, e.g., messages with unrecognized types, messages with a non-integral number of elements, or with fewer elements than indicated, etc. In all cases, upon detecting an error, the receiver MUST discontinue processing the current TBRPF packet and discard any unprocessed elements.
追加のメッセージタイプは、次のセクションで発生するときに説明されています。送信者は、個々のメッセージ形式で指定されたメッセージをエンコードします。受信者は、メッセージ構築のエラーを検出します。たとえば、認識されていないタイプ、非積分数の要素のメッセージ、または示されているよりも少ない要素などのメッセージなど。すべての場合、エラーを検出すると、受信者は現在のTBRPFの処理を中止する必要があります。処理されていない要素をパケットと破棄します。
This section describes the TBRPF Neighbor Discovery (TND) protocol, which allows each node to quickly detect bidirectional links (I,J) between a local interface I and a neighbor interface J, and to quickly detect the loss of such links. The interface between TND and the routing module is defined by the neighbor table maintained by TND and the three procedures Link_Up(I,J), Link_Down(I,J), and Link_Change(I,J), which are called by TND to announce a new link, the loss of a link, and a change in the metric of a link, respectively.
このセクションでは、TBRPF Neighbor Discovery（TND）プロトコルについて説明します。これにより、各ノードは、ローカルインターフェイスIとNeighborインターフェイスJの間の双方向リンク（I、J）を迅速に検出し、そのようなリンクの損失を迅速に検出できます。TNDとルーティングモジュールの間のインターフェイスは、TNDによって維持されているネイバーテーブルと3つの手順Link_up（i、j）、link_down（i、j）、およびlink_change（i、j）によって定義されます。新しいリンク、リンクの損失、およびリンクのメトリックの変更。
The HELLO message has the following three subtypes:
Helloメッセージには、次の3つのサブタイプがあります。
- NEIGHBOR REQUEST (TYPE = 2) - NEIGHBOR REPLY (TYPE = 3) - NEIGHBOR LOST (TYPE = 4)
- ネイバーリクエスト（タイプ= 2） - ネイバー返信（タイプ= 3） - ネイバーロスト（タイプ= 4）
Each HELLO subtype has the following format:
各hello subtypeには次の形式があります。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | TYPE | HSEQ | Pri | n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Interface Address (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Interface Address (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Interface Address (n) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
HSEQ (8 bits) The HELLO sequence number.
HSEQ（8ビット）ハローシーケンス番号。
Pri (4 bits) This field indicates the sending node's relay priority, which is an integer between 0 and 15. A node with a higher relay priority is more likely to be selected as the next hop on a route. The value 0 is reserved for non-relay nodes, i.e., nodes that should never forward packets originating from other nodes. A router in normal operation SHOULD have a relay priority equal to 7. A router can change its relay priority dynamically, e.g., when its power supply becomes critical.
PRI（4ビット）このフィールドは、送信ノードのリレーの優先度を示します。これは0〜15の間の整数です。リレーの優先度が高いノードは、ルートの次のホップとして選択される可能性が高くなります。値0は、非関連ノード、つまり他のノードから発生したパケットを決して転送しないノードに予約されています。通常の操作のルーターは、7に等しいリレーの優先度を持つ必要があります。ルーターは、電源が重要になったときに、リレーの優先度を動的に変更できます。
n (12 bits) The number of 32-bit neighbor interface addresses in the message.
n（12ビット）メッセージ内の32ビットの隣接インターフェイスアドレスの数。
A HELLO message is the concatenation of a NEIGHBOR REQUEST message, a NEIGHBOR REPLY message, and a NEIGHBOR LOST message, where each of the last two messages is omitted if its list of neighbor interface addresses is empty. Thus, a HELLO message always includes a (possibly empty) NEIGHBOR REQUEST.
Helloメッセージは、Neighbor Requestメッセージ、Neighborの返信メッセージ、および隣人がメッセージを失ったメッセージの連結です。ここでは、近隣インターフェイスアドレスのリストが空の場合、最後の2つのメッセージが省略されます。したがって、ハローメッセージには常に（空の）ネイバーリクエストが含まれます。
Each node maintains, for each of its local interfaces I, a neighbor table, which stores state information for each neighbor interface J from which HELLO messages have recently been received by interface I. The entry for neighbor interface J, in the neighbor table for I, contains the following variables:
各ノードは、各ローカルインターフェイスIの隣接テーブルの各インターフェイスについて維持します。このテーブルは、Interface Iによって最近Helloメッセージが受信された各隣接インターフェイスJの状態情報を保存します。、次の変数が含まれています。
nbr_rid(I,J) - The router ID of the node associated with neighbor interface J.
nbr_rid（i、j） - ネイバーインターフェイスに関連付けられているノードのルーターID
nbr_status(I,J) - The current status of the link (I,J), which can be LOST, 1-WAY, or 2-WAY.
nbr_status（i、j） - リンクの現在のステータス（i、j）は、1方向、または2ウェイを失う可能性があります。
nbr_life(I,J) - The amount of time (in seconds) remaining before nbr_status(I,J) must be changed to LOST if no further HELLO message from interface J is received. Set to NBR_HOLD_TIME whenever a HELLO is received on interface I from interface J.
nbr_life（i、j） - nbr_status（i、j）の前に残っている時間（秒単位）は、インターフェイスjからそれ以上のhelloメッセージが受信されない場合、lostに変更する必要があります。インターフェイスJからインターフェイスIでハローが受信されるたびにnbr_hold_timeに設定します。
nbr_hseq(I,J) - The value of HSEQ in the last HELLO message received on interface I from interface J. Used to determine the number of HELLOs that have been missed.
NBR_HSEQ（I、J） - インターフェイスJからインターフェイスIで受信した最後のハローメッセージのHSEQの値。
nbr_count(I,J) - The remaining number of times a NEIGHBOR REQUEST/ REPLY/LOST message containing J must be sent on interface I.
nbr_count（i、j） - 隣人のリクエスト/返信/紛失メッセージを含む残りの回数は、インターフェイスIで送信する必要があります。
hello_history(I,J) - A list of the sequence numbers of the last HELLO_ACQUIRE_WINDOW HELLO messages received on interface I from interface J.
hello_history（i、j） - 最後のhello_acquire_windowのシーケンス番号のリスト。インターフェイスIでInterface Iで受信したHelloメッセージ
nbr_metric(I,J) - An optional measure of the quality of the link (I,J), represented by an integer between 1 and 255, where smaller values indicate better quality. Defaults to 1 if not used.
NBR_METRIC（I、J） - リンクの品質（I、J）のオプションの尺度。1〜255の間の整数で表されます。使用されていない場合はデフォルトです。
nbr_pri(I,J) - The relay priority of the node associated with interface J.
NBR_PRI（I、J） - インターフェイスJに関連付けられたノードのリレー優先度
The entry for interface J in the neighbor table for interface I may be deleted if no HELLO has been received on interface I from interface J within the last 2*NBR_HOLD_TIME seconds. (It is kept while NEIGHBOR LOST messages containing J are being transmitted.) The absence of an entry for a given interface J is equivalent to an entry with nbr_status(I,J) = LOST and hello_history(I,J) = NULL.
インターフェイスの近隣テーブルでのインターフェイスJのエントリIは、最後の2*NBR_HOLD_TIME秒以内にインターフェイスJからインターフェイスIにHelloが受信されていない場合に削除される場合があります。（Jを含む近隣の紛失したメッセージが送信されている間に保持されます。）特定のインターフェイスjのエントリがないことは、NBR_STATUS（i、j）= lostおよびhello_history（i、j）= nullのエントリに相当します。
The three possible values of nbr_status(I,J) have the following informal meanings (the exact meanings are defined by the protocol):
NBR_STATUS（i、j）の3つの可能な値には、次の非公式の意味があります（正確な意味はプロトコルによって定義されます）。
LOST Interface I has not received a sufficient number of HELLO messages recently from Interface J.
失われたインターフェース私は最近、インターフェイスJから十分な数のハローメッセージを受け取っていません。
1-WAY Interface I has received a sufficient number of HELLO messages recently from Interface J, but the link is not 2-WAY.
1ウェイインターフェースInterface Jから最近、十分な数のハローメッセージを受け取りましたが、リンクは2ウェイではありません。
2-WAY Interfaces I and J have both received a sufficient number of HELLO messages recently from each other.
2ウェイインターフェイスIとJは両方とも、最近互いに十分な数のハローメッセージを受け取りました。
Each node MUST send, on each local interface, at least one HELLO message per HELLO_INTERVAL. HELLO messages MAY be sent more frequently than this (e.g., for faster detection of topology changes). However, to avoid the possibility that HSEQ wraps around to the same number before a neighbor that stops receiving HELLO messages changes the status of the link to LOST, the time between two consecutive HELLO messages (sent on a given interface) MUST be greater than NBR_HOLD_TIME/128 second.
各ノードは、各ローカルインターフェイスで、hello_intervalに少なくとも1つのハローメッセージを送信する必要があります。こんにちはメッセージは、これよりも頻繁に送信される場合があります（たとえば、トポロジの変更をより速く検出するため）。ただし、HSEQがハローメッセージの受信を停止する隣人がリンクのステータスを紛失する前に同じ数に包む可能性を回避するために、2つの連続したハローメッセージ（特定のインターフェイスで送信）の間の時間はNBR_HOLD_TIMEよりも大きくなければなりません/128秒。
To avoid synchronization of control messages, which can result in collisions, HELLO messages SHOULD NOT be transmitted at equal intervals. To achieve this, a node MAY choose the interval between consecutive HELLO messages to be HELLO_INTERVAL - jitter, where jitter is selected randomly from the interval [0, MAX_JITTER].
衝突につながる可能性のある制御メッセージの同期を避けるために、Helloメッセージを等しい間隔で送信するべきではありません。これを達成するために、ノードは、hello_interval -jitterである連続したハローメッセージ間の間隔を選択できます。ここで、ジッターは間隔[0、max_jitter]からランダムに選択されます。
Each HELLO message always includes a NEIGHBOR REQUEST message, even if its list of neighbor addresses is empty. The NEIGHBOR REQUEST message includes the sequence number HSEQ, which is incremented by 1 (modulo 256) each time a HELLO is sent. The HELLO message also includes a NEIGHBOR REPLY message if its list of neighbor addresses is nonempty, and a NEIGHBOR LOST message if its list of neighbor addresses is nonempty. The contents of these three messages are determined by the following steps at node i for each interface I:
Helloの各メッセージには、近隣のアドレスのリストが空であっても、常にNeighborリクエストメッセージが含まれています。近隣リクエストメッセージには、Helloが送信されるたびに1（Modulo 256）で増分されるシーケンス番号HSEQが含まれています。Helloメッセージには、近隣のアドレスのリストが空である場合は隣人の返信メッセージが含まれています。近隣アドレスのリストが空である場合は、隣人が失われたメッセージも含まれています。これら3つのメッセージの内容は、各インターフェイスIのノードIの次の手順によって決定されます。
1. For each interface J such that nbr_status(I,J) = LOST and nbr_count(I,J) > 0, include J in the NEIGHBOR LOST message and decrement nbr_count(I,J).
1. nbr_status（i、j）= lostおよびnbr_count（i、j）> 0がnbr_status（i、j）= nbr_count（i、j）> 0がnbr_count（i、j）にjを含めるようにする各インターフェイスjについて。
2. For each interface J such that nbr_status(I,J) = 1-WAY and nbr_count(I,J) > 0, include J in the NEIGHBOR REQUEST message and decrement nbr_count(I,J).
2. NBR_STATUS（i、j）= 1-wayおよびnbr_count（i、j）> 0がnbr_status（i、j）= 1-way、nbr_count（i、j）にjを含めるようにする各インターフェイスjについて。
3. For each interface J such that nbr_status(I,J) = 2-WAY and nbr_count(I,J) > 0, include J in the NEIGHBOR REPLY message and decrement nbr_count(I,J).
3. nbr_status（i、j）= 2-wayおよびnbr_count（i、j）> 0がnbr_status（i、j）= 2-wayおよびnbr_count（i、j）> 0の各インターフェイスjについて、neighbor ReplyメッセージにJを含め、nbr_count（i、j）を減少させます。
If a node restarts, so that all entries are removed from the neighbor table, then the node MUST ensure that (for each interface) at least one of the following two conditions is satisfied:
ノードが再起動してすべてのエントリがネイバーテーブルから削除されるようにする場合、ノードは（各インターフェイスに対して）次の2つの条件の少なくとも1つが満たされることを確認する必要があります。
1. The difference between the transmission times of the first HELLO sent after restarting and the last HELLO sent before restarting is at least 2*NBR_HOLD_TIME.
1. 再起動後に送信された最初のHelloの送信時間と再起動前に送信された最後のHelloの違いは、少なくとも2*NBR_HOLD_TIMEです。
2. Letting HSEQ_LAST denote the sequence number of the last HELLO that was sent before restarting, the sequence number of the first HELLO sent after restarting is set to HSEQ_LAST + NBR_HOLD_COUNT + 1 (modulo 256).
2. HSEQ_LASTを再起動する前に送信された最後のHelloのシーケンス番号を示します。再起動後に送信された最初のHelloのシーケンス番号は、hseq_last nbr_hold_count 1（modulo 256）に設定されます。
Either of these conditions ensures that, if node i with interface I restarts, then each neighbor of node i that has a link (J,I) to interface I will set the status of the link to LOST.
これらの条件のいずれかが、インターフェイスIを使用してノードIを再起動すると、リンク（j、i）を備えたノードIの各隣接がインターフェイスにlostに設定することを保証します。
When a node receives a HELLO message, it obtains the IP address of the sending interface from the IP header. If the TBRPF packet header of the received HELLO contains the RID option, then the RID of the sending node is obtained from the TBRPF packet header; otherwise it is equal to the IP address of the sending interface. If node i (with RID equal to i) receives a HELLO message on interface I, sent by node j (with RID equal to j) on interface J, with sequence number HSEQ and relay priority PRI, then node i performs the following steps: 1. If the neighbor table for interface I does not contain an entry for interface J, create one with nbr_rid(I,J) = j, nbr_status(I,J) = LOST (temporarily), nbr_count(I,J) = 0, and nbr_hseq(I,J) = HSEQ.
ノードがハローメッセージを受信すると、IPヘッダーから送信インターフェイスのIPアドレスが取得されます。受信したHelloのTBRPFパケットヘッダーにRIDオプションが含まれている場合、送信ノードのRIDはTBRPFパケットヘッダーから取得されます。それ以外の場合は、送信インターフェイスのIPアドレスに等しくなります。ノードI（Iに等しい）がインターフェイスIでハローメッセージを受信した場合、インターフェイスjでノードJ（red等）によって送信され、シーケンス番号HSEQとリレーの優先PRIで、ノードIは次の手順を実行します。1.インターフェイスの隣のテーブルIがインターフェイスjのエントリが含まれていない場合、nbr_rid（i、j）= j、nbr_status（i、j）= lost（一時的）、nbr_count（i、j）= 0で1つを作成します。、およびnbr_hseq（i、j）= hseq。
2. Update hello_history(I,J) to reflect the received HELLO message. If nbr_hseq(I,J) > HSEQ (due to wraparound), set nbr_hseq(I,J) = nbr_hseq(I,J) - 256.
2. hello_history（i、j）を更新して、受信したハローメッセージを反映します。nbr_hseq（i、j）> hseq（ラップアラウンドによる）の場合、nbr_hseq（i、j）= nbr_hseq（i、j）-256を設定します。
3. If nbr_status(I,J) = LOST and hello_history(I,J) indicates that HELLO_ACQUIRE_COUNT of the last HELLO_ACQUIRE_WINDOW HELLO messages from interface J have been received:
3. nbr_status（i、j）= lost and hello_history（i、j）が、インターフェイスjからの最後のhello_acquire_window helloメッセージのhello_acquire_countが受信されたことを示している場合：
a. If interface I does not appear in the NEIGHBOR REQUEST list or the NEIGHBOR REPLY list, set nbr_status(I,J) = 1-WAY and nbr_count(I,J) = NBR_HOLD_COUNT.
a. インターフェイスIがNeighborリクエストリストまたはNeighbor Replyリストに表示されない場合、NBR_STATUS（i、j）= 1-wayおよびnbr_count（i、j）= nbr_hold_countを設定します。
b. Else, set nbr_status(I,J) = 2-WAY and nbr_count(I,J) = NBR_HOLD_COUNT. Call Link_Up(I,J).
b. その他、nbr_status（i、j）= 2-wayおよびnbr_count（i、j）= nbr_hold_countlink_up（i、j）を呼び出します。
4. Else, if nbr_status(I,J) = 1-WAY:
4. それ以外の場合、nbr_status（i、j）= 1-way：
a. If HSEQ - nbr_hseq(I,J) > NBR_HOLD_COUNT, then set nbr_status(I,J) = LOST and nbr_count(I,J) = NBR_HOLD_COUNT.
a. hseq -nbr_hseq（i、j）> nbr_hold_countの場合、nbr_status（i、j）= lost and nbr_count（i、j）= nbr_hold_countを設定します。
b. Else, if interface I appears in the NEIGHBOR REQUEST list, set nbr_status(I,J) = 2-WAY and nbr_count(I,J) = NBR_HOLD_COUNT. Call Link_Up(I,J).
b. それ以外の場合、インターフェイスiがNeighborリクエストリストに表示される場合、nbr_status（i、j）= 2-wayおよびnbr_count（i、j）= nbr_hold_countを設定します。link_up（i、j）を呼び出します。
c. Else, if interface I appears in the NEIGHBOR REPLY list, set nbr_status(I,J) = 2-WAY and nbr_count(I,J) = 0. Call Link_Up(I,J).
c. それ以外の場合、インターフェイスiがNeighbor Replyリストに表示される場合、nbr_status（i、j）= 2-wayおよびnbr_count（i、j）= 0を設定します。
5. Else, if nbr_status(I,J) = 2-WAY:
5. それ以外の場合、nbr_status（i、j）= 2ウェイの場合：
a. If interface I appears in the NEIGHBOR LOST list, set nbr_status(I,J) = LOST and nbr_count(I,J) = 0. Call Link_Down(I,J).
a. インターフェイスiがNeighbor Lostリストに表示される場合、nbr_status（i、j）= lostおよびnbr_count（i、j）= 0を設定します。
b. Else, if HSEQ - nbr_hseq(I,J) > NBR_HOLD_COUNT, set nbr_status(I,J) = LOST and nbr_count(I,J) = NBR_HOLD_COUNT. Call Link_Down(I,J).
b. それ以外の場合、hseq -nbr_hseq（i、j）> nbr_hold_count、set nbr_status（i、j）= lostおよびnbr_count（i、j）= nbr_hold_count。link_down（i、j）を呼び出します。
c. Else, if interface I appears in the NEIGHBOR REQUEST list and nbr_count(I,J) = 0, set nbr_count(I,J) = NBR_HOLD_COUNT.
c. それ以外の場合、インターフェイスIがNeighbor Request Listに表示され、NBR_Count（i、j）= 0に表示され、nbr_count（i、j）= nbr_hold_countを設定します。
6. Set nbr_life(I,J) = NBR_HOLD_TIME, nbr_hseq(I,J) = HSEQ, and nbr_pri(I,J) = PRI.
6. set nbr_life（i、j）= nbr_hold_time、nbr_hseq（i、j）= hseq、およびnbr_pri（i、j）= pri。
Upon expiration of the timer nbr_life(I,J) in the neighbor table for interface I, node i performs the following step:
インターフェイスIの近隣テーブルでタイマーNBR_LIFE（i、j）の有効期限が切れたら、ノードIは次のステップを実行します。
If nbr_status(I,J) = 1-WAY or 2-WAY, set nbr_status(I,J) = LOST and nbr_count(I,J) = NBR_HOLD_COUNT. Call Link_Down(I,J).
nbr_status（i、j）= 1-wayまたは2way、set nbr_status（i、j）= lostおよびnbr_count（i、j）= nbr_hold_countを設定します。link_down（i、j）を呼び出します。
Some link-layer protocols (e.g., IEEE 802.11) provide a notification that the link to a particular neighbor has failed, e.g., after attempting a maximum number of retransmissions. If such an notification is provided by the link layer, then node i SHOULD perform the following step upon receipt of a link-layer failure notification for the link (I,J) from local interface I to neighbor interface J:
一部のリンク層プロトコル（例：IEEE 802.11）は、特定の隣人へのリンクが失敗したという通知を提供します。たとえば、最大数の再送信を試みた後です。このような通知がリンクレイヤーによって提供されている場合、ノードIは、ローカルインターフェイスIからNeighborインターフェイスJへのリンク（i、j）のリンク層障害通知（i、j）の受信時に次のステップを実行する必要があります。
If nbr_status(I,J) = 2-WAY, set nbr_status(I,J) = LOST and nbr_count(I,J) = NBR_HOLD_COUNT. Call Link_Down(I,J).
nbr_status（i、j）= 2-way、set nbr_status（i、j）= lostおよびnbr_count（i、j）= nbr_hold_countの場合。link_down（i、j）を呼び出します。
Each node MAY maintain and update one or more link metrics for each link (I,J), representing the quality of the link, e.g., signal strength, number of HELLOs received over some time interval, reliability, stability, bandwidth, etc. Each node MUST declare a neighbor to be LOST if either NBR_HOLD_COUNT HELLOs are missed or if no HELLO is received within NBR_HOLD_TIME seconds; however, a node MAY also declare a neighbor to be LOST based on a link metric being above or below some threshold. Each node MUST receive at least HELLO_ACQUIRE_COUNT of the last HELLO_ACQUIRE_WINDOW HELLOs from a neighbor before declaring the neighbor 1-WAY or 2-WAY; however, a node MAY require an additional condition based on a link metric being above or below some threshold, before declaring the neighbor 1-WAY or 2-WAY. This document does not specify any particular link metric, but an implementation of TBRPF that uses such metrics is considered to be compliant with this specification.
各ノードは、リンクの品質を表す各リンク（i、j）の1つ以上のリンクメトリックを維持および更新できます。NBR_HOLD_COUNT HELLOSが見逃されている場合、またはnbr_hold_timeの秒以内にhelloが受信されない場合、ノードは隣人を紛失していると宣言する必要があります。ただし、ノードは、リンクメトリックがしきい値の上または下にあることに基づいて、隣人が失われると宣言する場合があります。各ノードは、隣人または2ウェイを宣言する前に、隣人から最後のhello_acquire_window hellosの少なくともhello_acquire_countを受信する必要があります。ただし、ノードには、隣の1方向または2ウェイを宣言する前に、リンクメトリックが閾値の上または下にあることに基づいて追加の条件が必要になる場合があります。このドキュメントでは、特定のリンクメトリックを指定するのではなく、そのようなメトリックを使用するTBRPFの実装は、この仕様に準拠していると見なされます。
The function Link_Change(I,J) is called to alert the routing module whenever nbr_metric(I,J) changes significantly. If the configurable parameter USE_METRICS is equal to 1, then the metrics nbr_metric(I,J) are used by the routing module for route computation, as described in Section 8.
関数link_change（i、j）は、nbr_metric（i、j）が大幅に変化するたびにルーティングモジュールにアラートするために呼び出されます。設定可能なパラメーターuse_metricsが1に等しい場合、セクション8で説明されているように、ルート計算のためにルーティングモジュールでメトリックnbr_metric（i、j）が使用されます。
This section lists the parameters used by the neighbor discovery protocol, and their proposed default values. All nodes MUST be configured to have the same value for all of the following parameters.
このセクションには、Neighbor Discoveryプロトコルで使用されるパラメーターと、提案されたデフォルト値をリストします。すべてのノードは、次のすべてのパラメーターに対して同じ値を持つように構成する必要があります。
Parameter Name Default Value
-------------- -------------
HELLO_INTERVAL 1 second
MAX_JITTER 0.1 second
NBR_HOLD_TIME 3 seconds
NBR_HOLD_COUNT 3
HELLO_ACQUIRE_COUNT 2
HELLO_ACQUIRE_WINDOW 3
This section describes the TBRPF routing module, which performs topology discovery and route computation.
このセクションでは、トポロジの発見とルート計算を実行するTBRPFルーティングモジュールについて説明します。
In addition to the information required by the neighbor discovery protocol, each node running TBRPF maintains a topology table TT, which stores information for each known node and link in the network. Nodes are identified by their RIDs, i.e., node u is the node whose RID is u. The following information is stored in the topology table at node i for each node u and link (u,v):
Neighbor Discoveryプロトコルが必要とする情報に加えて、TBRPFを実行している各ノードはトポロジテーブルTTを維持します。トポロジテーブルTTは、ネットワーク内の各ノードとリンクの情報を保存します。ノードはRIDによって識別されます。つまり、ノードuはridのノードです。次の情報は、各ノードuおよびリンク（u、v）のノードIのトポロジテーブルに保存されています。
T(u,v) - Equal to 1 if (u,v) is in node i's source tree T, and 0 otherwise. The previous source tree is also maintained as old_T.
t（u、v） - 1に等しい（u、v）がノードIのソースツリーtに、それ以外の場合は0です。以前のソースツリーもold_tとして維持されます。
RN(u) - Equal to 1 if u is in node i's reported node set RN, and 0 otherwise. The previous reported node set is also maintained as old_RN.
rn（u） - uがノードIである場合、1に等しいIが報告されたノードセットRN、それ以外の場合は0です。以前の報告されたノードセットもold_rnとして維持されています。
RT(u,v) - Equal to 1 if (u,v) is in node i's reported subtree RT, and 0 otherwise. Since RT is defined as the set of links (u,v) in T such that u is in RN, this variable need not be maintained explicitly.
rt（u、v）-1に等しい（u、v）がノードIで報告されたサブツリーRt、0それ以外の場合は0です。RTは、uがRNにあるようにTのリンクのセット（u、v）として定義されるため、この変数を明示的に維持する必要はありません。
TG(u,v) - Equal to 1 if (u,v) is in node i's topology graph TG, and 0 otherwise.
Tg（u、v） - 1に等しいif（u、v）がノードIのトポロジーグラフTgに、それ以外の場合は0です。
N - The set of 2-way neighbors of node i.
n-ノードiの2ウェイネイバーのセット。
r(u,v) - The list of neighbors that are reporting link (u,v) in their reported subtree RT. The set of links (u,v) reported by neighbor j is denoted RT_j.
r（u、v） - 報告されているサブツリーRtにリンク（u、v）を報告している隣人のリスト。Neighbor jによって報告されたリンクのセット（u、v）はrt_jと記載されています。
r(u) - The list of neighbors that are reporting node u in their reported node set RN.
r（u） - 報告されたノードセットRNにノードuを報告している隣人のリスト。
p(u) - The current parent for node u, equal to the next node on the shortest path to u.
p（u） - uへの最短パスの次のノードに等しいノードuの現在の親。
pred(u) - The node that is the predecessor of node u in the source tree T. Equal to NULL if node u is not reachable.
pred（u） - ソースツリーTのノードuの前身であるノード。ノードuが到達できない場合はnullに等しくなります。
pred(j,u) - The node that is the predecessor of node u in the subtree RT_j reported by neighbor j.
pred（j、u） - ネイバーjによって報告されたサブツリーRT_Jのノードuの前身であるノード。
d(u) - The length of the shortest path to node u. If USE_METRICS = 0, d(u) is the number of hops to node u.
d（u） - ノードuへの最短経路の長さ。use_metrics = 0の場合、d（u）はnode uへのホップ数です。
reported(u,v) - Equal to 1 if link (u,v) in TG is reported by p(u), and 0 otherwise.
報告（u、v） - tgのリンク（u、v）がp（u）で報告され、それ以外の場合は0が報告されます。
tg_expire(u) - Expiration time for links (u,v) in TG.
TG_EXPIRE（U） - TGのリンクの有効期限（U、V）。
rt_expire(j,u) - Expiration time for links (u,v) in RT_j.
rt_expire（j、u） - rt_jのリンク（u、v）の有効期限時間（u、v）。
nr_expire(u,v) - Expiration time for a link (u,v) in TG such that reported(u,v) = 0. Such non-reported links can be used temporarily during rerouting.
nr_expire（u、v） - tgのリンク（u、v）の有効期限（u、v）= 0になります。このような非報告リンクは、再ルーティング中に一時的に使用できます。
metric(j,u,v) - The metric for link (u,v) reported by neighbor j.
メトリック（j、u、v） - 隣接jによって報告されたリンク（u、v）のメトリック。
metric(u,v) - The metric for link (u,v) in TG. For a neighbor j, metric(i,j) is the minimum of nbr_metric(I,J) over all 2-WAY links (I,J) from i to j.
メトリック（u、v） - tgのリンク（u、v）のメトリック。隣接Jの場合、メトリック（i、j）は、iからjへのすべての2方向リンク（i、j）にわたる最小NBR_METRIC（I、J）です。
cost(u,v) - The cost for link (u,v), equal to metric(u,v) if USE_METRICS = 1, and otherwise equal to 1.
cost（u、v） - リンクのコスト（u、v）、use_metrics = 1の場合はメトリック（u、v）に等しく、それ以外の場合は1に等しくなります。
local_if(j) - The address of the preferred local interface for forwarding packets to neighbor j.
local_if（j） - 近隣jにパケットを転送するための優先ローカルインターフェイスのアドレス。
nbr_if(j) - The address of the preferred interface of neighbor j.
nbr_if（j） - 隣接jの優先インターフェイスのアドレス。
The routing table consists of a list of tuples of the form (rt_dest, rt_next, rt_dist, rt_if_id), where rt_dest is the destination IP address or prefix, rt_next is the interface address of the next hop of the route, rt_dist is the length of the route, and rt_if_id is the ID of the local interface through which the next hop can be reached.
ルーティングテーブルは、フォームのタプルのリスト（rt_dest、rt_next、rt_dist、rt_if_id）で構成されています。ここで、rt_destは宛先IPアドレスまたはプレフィックスです。RT_NEXTはルートの次のホップのインターフェイスアドレスです。RT_DISTはの長さですルートとRT_IF_IDは、次のホップに到達できるローカルインターフェイスのIDです。
Each node also maintains three tables that describe associated IP addresses or prefixes: the "interface table", which associates interface IP addresses with router IDs, the "host table", which associates host IP addresses with router IDs, and the "network prefix table", which associates network prefixes with router IDs.
また、各ノードには、関連するIPアドレスまたはプレフィックスを記述する3つのテーブルが維持されます。インターフェイスIPアドレスをルーターIDに関連付ける「インターフェイステーブル」、ホストIPアドレスをルーターIDと関連付ける「ホストテーブル」、および「ネットワークプレフィックステーブル」"、ネットワークのプレフィックスをルーターIDに関連付けます。
The "interface table" consists of tuples of the form (if_addr, if_rid, if_expire), where if_addr is an interface IP address associated with the router with RID = if_rid, and if_expire is the time at which the tuple expires and MUST be removed. The interface table at a node does NOT contain an entry in which if_addr equals the node's own RID; thus, a node does not advertise its own RID as an associated interface.
「インターフェイステーブル」は、フォームのタプル（if_addr、if_rid、if_expire）で構成されています。ここで、if_addrはrouterに関連付けられたインターフェイスIPアドレスです= if_ridを使用します。ノードのインターフェイステーブルには、if_addrがノード自身のRIDに等しいエントリは含まれていません。したがって、ノードは、関連するインターフェイスとして独自のRIDを宣伝しません。
The "host table" consists of tuples of the form (h_addr, h_rid, h_expire), where h_addr is a host IP address associated with the router with RID = h_rid, and h_expire is the time at which the tuple expires and MUST be removed.
「ホストテーブル」は、フォーム（H_ADDR、H_RID、H_EXPIRE）のタプルで構成されています。H_ADDRは、red = h_ridのルーターに関連付けられたホストIPアドレスであり、h_expireはタプルの有効期限が切れ、削除する必要があります。
The "network prefix table" consists of tuples of the form (net_prefix, net_length, net_rid, net_expire), where net_prefix and net_length describe a network prefix associated with the router with RID = net_rid, and net_expire is the time at which the tuple expires and MUST be removed. A MANET may be configured as a "stub" network, in which case one or more gateway routers may announce a default prefix such that net_prefix = net_length = 0. Two copies of each table are kept: an "old" copy that was last reported to neighbors, and the current copy that is updated when association messages are received.
「ネットワークプレフィックステーブル」は、フォームのタプル（net_prefix、net_length、net_rid、net_expire）で構成されています。ここでは、net_prefixとnet_lengthがruterに関連するネットワークのプレフィックスをrid = net_ridで説明しています。削除する必要があります。マネは「スタブ」ネットワークとして構成される場合があります。この場合、1つ以上のゲートウェイルーターがnet_prefix = net_length = 0のようにデフォルトのプレフィックスを発表する場合があります。各テーブルの2つのコピーが保持されます。最後に報告された「古い」コピー隣人、および関連付けメッセージが受信されたときに更新される現在のコピー。
The TOPOLOGY UPDATE message has the two formats, depending on the size of the message. The normal format is as follows, and is used whenever n, NRL, and NRNL all do not exceed 255:
トポロジアップデートメッセージには、メッセージのサイズに応じて2つの形式があります。通常の形式は次のとおりで、n、nrl、およびnrnlがすべて255を超えない場合はいつでも使用されます。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|D|0|0| TYPE | n | NRL | NRNL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID of u |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID of v_1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID of v_n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| metric 1 | metric 2 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The message body contains the n+1 router IDs for nodes u, v_1,...,v_n, which represent the links (u,v_1),..., (u,v_n). The first NRL of the v_k are reported leaf nodes, the next NRNL of the v_k are reported non-leaf nodes, and the last n - (NRL+NRNL) of the v_k are not reported (not in RN).
メッセージ本文には、リンク（u、v_1）、...、（u、v_n）を表すノードu、v_1、...、v_nのn 1ルーターIDが含まれています。V_Kの最初のNRLは葉のノードが報告され、V_Kの次のNRNLは非葉のノードが報告され、V_Kの最後のN-（NRL NRNL）は報告されていません（RNではありません）。
The M bit indicates whether or not link metrics are included in the message. If M = 1, then a 1-octet metric is included for each of the links (u,v_1),..., (u,v_n), following the last router ID.
mビットは、メッセージにリンクメトリックが含まれているかどうかを示します。m = 1の場合、最後のルーターIDに従って、各リンク（u、v_1）、...、（u、v_n）の各リンク（u、v_1）に1-OCTETメトリックが含まれています。
The D bit indicates whether or not implicit deletion is used, and must be set to 1 if and only if IMPLICIT_DELETION = 1.
dビットは、暗黙的な削除が使用されるかどうかを示し、inclicit_deletion = 1の場合にのみ1に設定する必要があります。
The TOPOLOGY UPDATE message has the following three subtypes:
トポロジアップデートメッセージには、次の3つのサブタイプがあります。
FULL (TYPE = 5) A FULL update (FULL, n, NRL, NRNL, u, v_1,..., v_n) reports that the links (u,v_1),..., (u,v_n) belong to the sending router's reported subtree RT, and that RT contains no other links with tail u.
full（type = 5）フルアップデート（full、n、nrl、nrnl、u、v_1、...、v_n）は、リンク（u、v_1）、...、（u、v_n）がRouterの報告されたサブツリーRTを送信し、RTにはTail Uに他のリンクが含まれていません。
ADD (TYPE = 6) An ADD update (ADD, n, NRL, NRNL, u, v_1,..., v_n) reports that the links (u,v_1),..., (u,v_n) have been added to the sending router's reported subtree RT.
追加（type = 6）アップデート（add、in、nrl、nrl、u、v_ 1、...、v_ n）の追加（u、v_1）、...、（u、v_n）が報告しています送信ルーターに報告されたサブツリーRTに追加されました。
DELETE (TYPE = 7) A DELETE update (DELETE, n, NRL, NRNL, u, v_1,..., v_n) reports that the links (u,v_1),..., (u,v_n) have been deleted from the sending router's reported subtree RT.
delete（type = 7）delete update（delete、n、nrl、nrnl、u、v_1、...、v_n）は、リンク（u、v_1）、...、（u、v_n）が削除されていると報告しています送信ルーターの報告されたサブツリーRtから。
If n, NRL, or NRNL is larger than 255, then the long format of the TOPOLOGY UPDATE message is used, in which the first 4 octets of the normal format are replaced by the following 8 octets:
n、nrl、またはnrnlが255を超える場合、トポロジアップアップデートメッセージの長い形式が使用され、通常の形式の最初の4オクテットは次の8オクテットに置き換えられます。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|D|1|0| TYPE | 0 | n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NRL | NRNL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The INTERFACE ASSOCIATION (TYPE = 8) and HOST ASSOCIATION (TYPE = 9) messages have the following format:
インターフェイスアソシエーション（Type = 8）およびホストアソシエーション（Type = 9）メッセージには、次の形式があります。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ST | 0 | TYPE | Reserved | n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The message body contains the router ID of the originating node, and n IP addresses of interfaces (TYPE = 8) or hosts (TYPE = 9) that are associated with the router ID. The ST field is defined below.
メッセージ本文には、元のノードのルーターID、およびルーターIDに関連付けられているインターフェイス（Type = 8）またはホスト（Type = 9）のn IPアドレスが含まれています。STフィールドは以下に定義されています。
The NETWORK PREFIX ASSOCIATION message (TYPE = 10) has the following format:
ネットワークプレフィックスアソシエーションメッセージ（Type = 10）には、次の形式があります。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ST | 0 | TYPE | Reserved | n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | Prefix byte 1 | Prefix byte 2 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | PrefixLength | Prefix byte 1 | Prefix byte 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The message body contains the router ID of the originating node, and
n network prefixes, each specified by a 1-octet prefix length
followed immediately by the prefix, using the minimum number of whole
octets required. To minimize overhead, the prefix lengths and
prefixes are NOT aligned along word boundaries.
The INTERFACE ASSOCIATION, HOST ASSOCIATION, and NETWORK PREFIX ASSOCIATION messages each have the following three subtypes (similar to those for the TOPOLOGY UPDATE message):
インターフェイスアソシエーション、ホストアソシエーション、およびネットワークプレフィックスアソシエーションメッセージには、それぞれ次の3つのサブタイプがあります（トポロジアップデートメッセージと同様）：
FULL (ST = 0) Indicates that this is a FULL update that includes all interface addresses, host addresses, or network prefixes associated with the given router ID.
FULL（ST = 0）は、これが特定のルーターIDに関連付けられたすべてのインターフェイスアドレス、ホストアドレス、またはネットワークプレフィックスを含む完全な更新であることを示しています。
ADD (ST = 1) Indicates that the included IP addresses or network prefixes are associated with the router ID, but may not include all such IP addresses or network prefixes.
追加（ST = 1）は、含まれたIPアドレスまたはネットワークプレフィックスがルーターIDに関連付けられていることを示しますが、そのようなすべてのIPアドレスまたはネットワークプレフィックスが含まれない場合があります。
DELETE (ST = 2) Indicates that the included IP addresses or network prefixes are no longer associated with the router ID.
削除（st = 2）含まれたIPアドレスまたはネットワークプレフィックスがルーターIDに関連付けられなくなったことを示します。
This section describes the operation of the TBRPF routing module. The operation is divided into the following subsections: periodic processing, updating the source tree and topology graph, updating the routing table, updating the reported node set, generating periodic updates, generating differential updates, processing topology updates, expiring topology information, optional reporting of redundant topology information, local topology changes, generating association messages, processing association messages, and non-relay operation. The operation is described in terms of procedures (e.g., Update_All), which may be executed periodically or in response to some event, and may be called by other procedures. In all procedures, node i is the node executing the procedure.
このセクションでは、TBRPFルーティングモジュールの操作について説明します。操作は、次のサブセクションに分割されます。周期処理、ソースツリーとトポロジグラフの更新、ルーティングテーブルの更新、報告されたノードセットの更新、定期的な更新の生成、差分更新の生成、トポロジの更新の処理、トポロジ情報の期限切れ、オプションのレポートの報告冗長なトポロジ情報、ローカルトポロジの変更、関連性メッセージの生成、処理関連メッセージ、および非関連操作。操作は、定期的にまたは一部のイベントに応じて実行される可能性がある手順（update_allなど）の観点から説明され、他の手順で呼び出される場合があります。すべての手順で、ノードIは手順を実行するノードです。
Each node executes the procedure Update_All() periodically, at least once every DIFF_UPDATE_INTERVAL seconds, which is typically equal to HELLO_INTERVAL. This procedure is defined as follows:
各ノードは、通常、hello_intervalに等しい、少なくともすべてのdiff_update_interval秒ごとに、定期的にprocedure updation_all（）を定期的に実行します。この手順は次のように定義されています。
Update_All() 1. For each interface I, create empty message list msg_list(I). 2. For each interface I, generate a HELLO message for interface I and add it to msg_list(I). 3. Expire_Links(). 4. Update_Source_Tree(). 5. Update_Routing_Table(). 6. If REPORT_FULL_TREE = 0, execute Update_RN(); otherwise (the full source tree is reported) Update_RN_Simple(). 7. If current_time >= next_periodic: 7.1. Generate_Periodic_Update(). 7.2. Set next_periodic = current_time + PER_UPDATE_INTERVAL. 8. Else, Generate_Diff_Update(). 9. Generate_Association_Messages(). 10. For each interface I, send the msg_list(I) on interface I. 11. Set old_T = T and old_RN = RN.
update_all（）1。各インターフェイスiについて、空のメッセージリストmsg_list（i）を作成します。2.各インターフェイスiについて、インターフェイスiのハローメッセージを生成し、msg_list（i）に追加します。3. expire_links（）。4. update_source_tree（）。5. update_routing_table（）。6. REPORT_FULL_TREE = 0の場合、update_rn（）を実行します。それ以外の場合は、（完全なソースツリーが報告されています）update_rn_simple（）。7. current_time> = next_periodic：7.1。Generate_periodic_update（）。7.2。next_periodic = current_time per_update_intervalを設定します。8.その他、generate_diff_update（）。9. generate_association_messages（）。10.各インターフェイスIについて、インターフェイスIでmsg_list（i）を送信します。
The procedure Update_Source_Tree() is a variant of Dijkstra's algorithm, which is called periodically and in response to topology changes, to update the source tree T and the topology graph TG. This algorithm computes shortest paths subject to two link cost penalties. The penalty NON_REPORT_PENALTY is added to the cost of links (u,v) that are not currently reported by the parent p(u) so that, whenever possible, a link (u,v) is included in T only if it is currently reported by the parent. To allow immediate rerouting when p(u) changes, it may be necessary to temporarily use a link (u,v) that is not currently reported by the new parent. The penalty NON_TREE_PENALTY is added to the cost of links (u,v) that are not currently in T, to reduce the number of changes to T. When there exist multiple paths of equal cost to a given node, router ID is used to break ties.
手順update_source_tree（）は、定期的かつトポロジの変更に応じて呼ばれるDijkstraのアルゴリズムのバリアントであり、ソースツリーTとトポロジグラフTGを更新します。このアルゴリズムは、2つのリンクコストペナルティを条件として、最短パスを計算します。ペナルティnon_report_penaltyは、親p（u）によって現在報告されていないリンクのコスト（u、v）に追加されます。親によって。p（u）が変更されたときに即時再ルーティングを許可するには、現在新しい親によって報告されていないリンク（u、v）を一時的に使用する必要がある場合があります。ペナルティnon_tree_penaltyは、現在tにないリンクのコスト（u、v）に追加され、Tの変更回数を減らします。特定のノードに等しいコストの複数のパスが存在する場合、ルーターIDは破損するために使用されますネクタイ。
The algorithm is defined as follows (where node i is the node executing the procedure):
アルゴリズムは次のように定義されます（ここで、ノードIは手順を実行するノードです）：
Update_Source_Tree() 1. For each node v in TT, set d(v) = INFINITY, pred(v) = NULL, old_p(v) = p(v), and p(v) = NULL.
update_source_tree（）1。ttの各ノードvについて、d（v）= infinity、pred（v）= null、old_p（v）= p（v）、およびp（v）= null。
2. Set d(i) = 0, p(i) = i, pred(i) = i.
2. d（i）= 0、p（i）= i、pred（i）= iを設定します。
4. For each node j in N, set d(j) = c(i,j), pred(j) = i, and p(j) = j. (If USE_METRICS = 0, then all link costs c(i,j) are 1.)
4. nの各ノードJ、set d（j）= c（i、j）、pred（j）= i、およびp（j）= j。（use_metrics = 0の場合、すべてのリンクコストc（i、j）は1です。）
5. While there exists an unlabeled node u in TT such that d(u) < INFINITY: 5.1. Let u be an unlabeled node in TT with minimum d(u). (A heap should be used to find u efficiently.) 5.2. Add u to S (u becomes labeled). 5.3. If p(u) is not equal to old_p(u) (parent has changed): 5.3.1. For each link (u,v) in TG with tail u, if reported(u,v) = 1, set reported(u,v) = 0 and set nr_expire(u,v) = current_time + PER_UPDATE_INTERVAL. 5.3.2. If p(u) is in r(u) (p(u) is reporting u): 5.3.2.1. Set tg_expire(u) = rt_expire(p(u),u). 5.3.2.2. If p(u) = u (u is a neighbor), remove all links (u,v) with tail u from TG. 5.3.2.3. For each link (u,v) with p(u) in r(u,v): 5.3.2.3.1. Add (u,v) to TG and set reported(u,v) = 1. 5.3.2.3.2. Set metric(u,v) = metric(p(u),u,v). If USE_METRICS=1, set c(u,v)=metric(u,v). 5.4. For each node v such that (u,v) is in TG: 5.4.1. If reported(u,v) = 0, set cost = c(u,v) + NON_REPORT_PENALTY. (This penalizes (u,v) if not reported by p(u).) 5.4.2. Else, if p(u) = u AND u is not in r(v), set cost = c(u,v) + NON_REPORT_PENALTY. (This penalizes (u,v) if u is a neighbor and is not reporting v.) 5.4.3. If (u,v) is not in old_T and p(u) != u, set cost = cost + NON_TREE_PENALTY. 5.4.4. If (d(u) + cost, u) is lexicographically less than (d(v), pred(v)), set d(v) = d(u) + c(u,v), pred(v) = u, and p(v) = p(u).
5. D（u）<infinity：5.1になるように、ttには非標識ノードuが存在しますが。uを最小のd（u）でTTの非標識ノードとします。（ヒープを使用してuを効率的に見つける必要があります。）5.2。uをsに追加します（uはラベルになります）。5.3。p（u）がold_p（u）に等しくない場合（親が変更されました）：5.3.1。taの各リンク（u、v）について、ta uをu、u、v）は、報告された場合（u、v）= 1、報告（u、v）= 0を設定し、nr_expire（u、v）= current_time per_update_intervalを設定します。5.3.2。p（u）がr（u）（p（u）がu）にある場合、u）：5.3.2.1。tg_expire（u）= rt_expire（p（u）、u）を設定します。5.3.2.2。p（u）= u（uが隣接）の場合、tgからtail uを使用してすべてのリンク（u、v）を削除します。5.3.2.3。r（u、v）のp（u）を持つ各リンク（u、v）について：5.3.2.3.1。（u、v）をtgに追加し、報告された（u、v）= 1. 5.3.2.3.2。Metric（u、v）= metric（p（u）、u、v）を設定します。use_metrics = 1の場合、c（u、v）= metric（u、v）を設定します。5.4。（u、v）がtg：5.4.1にあるように各ノードvについて。報告された場合（u、v）= 0、cost = c（u、v）non_report_penaltyを設定します。（これは、p（u）で報告されていない場合（u、v）ペナルティになります。）5.4.2。それ以外の場合、p（u）= uとuがr（v）にない場合、cost = c（u、v）non_report_penaltyを設定します。（これは（u、v）uが隣人であり、報告していない場合（u、v）v。）5.4.3。（u、v）がold_tおよびp（u）！= uではない場合、set cost = cost non_tree_penalty。5.4.4。（d（u）cost、u）が辞書学的に（d（v）、pred（v））、set d（v）= d（u）c（u、v）、pred（v）= u、およびp（v）= p（u）。
6. Update the source tree T as follows: 6.1. Remove all links from T. 6.2. For each node u other than i such that pred(u) is not NULL, add the link (pred(u), u) to T.
6. 次のようにソースツリーtを更新します：6.1。T. 6.2からすべてのリンクを削除します。私以外の各ノードuについて、pred（u）がnullではないように、リンク（pred（u）、u）をTに追加します。
The routing table is updated following any change to the source tree or the association tables (interface table, host table, or network prefix table). The routing table is updated according to procedure Update_Routing_Table(), which is defined as follows:
ルーティングテーブルは、ソースツリーまたはアソシエーションテーブル（インターフェイステーブル、ホストテーブル、またはネットワークプレフィックステーブル）の変更後に更新されます。ルーティングテーブルは、手順update_routing_table（）に従って更新されます。これは次のように定義されています。
Update_Routing_Table()
update_routing_table（）
1. Remove all tuples from the routing table.
1. ルーティングテーブルからすべてのタプルを削除します。
2. For each node u in TT (other than this node) such that p(u) is not NULL, add the tuple (rt_dest, rt_next, rt_dist, rt_if_id) to the routing table, where: rt_dest = u, rt_if_id = local_if(p(u)), rt_next = nbr_if(p(u)), rt_dist = d(u).
2. TTの各ノードu（このノード以外）でp（u）がnullではないように、tuple（rt_dest、rt_next、rt_dist、rt_if_id）をルーティングテーブルに追加します。（u））、rt_next = nbr_if（p（u））、rt_dist = d（u）。
3. For each tuple (if_addr, if_rid, if_expire) in the interface table, if a routing table entry (rt_dest, rt_next, rt_dist, rt_if_id) exists such that rt_dest = if_rid, add the tuple (if_addr, rt_next, rt_dist, rt_if_id) to the routing table.
3. インターフェイステーブルの各タプル（if_addr、if_rid、if_expire）の場合、ルーティングテーブルエントリ（rt_dest、rt_next、rt_dist、rt_if_id）がrt_dest = if_rid、tuple（if_addr、rt_next、rt_dist、rt_if_id）のように存在するように存在します。ルーティングテーブル。
4. For each tuple (h_addr, h_rid, h_expire) in the host table, if there exists a routing table entry (rt_dest, rt_next, rt_dist, rt_if_id) such that rt_dest = h_rid, add the tuple (h_addr, rt_next, rt_dist, rt_if_id) to the routing table, unless an entry already exists with the same value for h_addr and a lexicographically smaller value for (rt_dist, rt_dest).
4. ホストテーブルにタプル（h_addr、h_rid、h_expire）ごとに、ルーティングテーブルエントリ（rt_dest、rt_next、rt_dist、rt_if_id）が存在する場合、rt_dest = h_rid、タプル（h_addr、rt_next、rt_dist、rt_if_id）ルーティングテーブルは、h_addrと同じ値と（rt_dist、rt_dest）に対して辞書的に小さい値を持つエントリが既に存在しない限り。
5. For each tuple (net_prefix, net_length, net_rid, net_expire) in the network prefix table, if there exists a routing table entry (rt_dest, rt_next, rt_dist, rt_if_id) such that rt_dest = net_rid, add the tuple (net_prefix/net_length, rt_next, rt_dist, rt_if_id) to the routing table, unless an entry already exists with the same value for net_prefix/net_length and a lexicographically smaller value for (rt_dist, rt_dest).
5. 各タプル（net_prefix、net_length、net_rid、net_expire）について、ネットワークプレフィックステーブルに、ルーティングテーブルエントリ（rt_dest、rt_next、rt_if_id）が存在する場合、rt_dest = net_rid（net_prefix/net_lents/net_lents）rt_dist、rt_if_id）ルーティングテーブルへ、net_prefix/net_lengthの同じ値と（rt_dist、rt_dest）の辞書版が小さい値で既に存在しない限り。
Recall that the reported subtree RT is defined to be the set of links (u,v) in T such that u is in the reported node set RN. Each node updates its RN immediately before generating periodic or differential topology updates.
報告されたサブツリーRTは、uが報告されたノードセットRNにあるように、tのリンクのセット（u、v）と定義されていることを思い出してください。各ノードは、定期的または微分トポロジの更新を生成する直前にRNを更新します。
If REPORT_FULL_TREE = 1 (so that a node reports its entire source tree), then RN simply consists of all reachable nodes, i.e., all nodes u such that pred(u) is not NULL. The procedure that computes RN in this manner is called Update_RN_Simple(). The rest of this section describes how RN is computed assuming REPORT_FULL_TREE = 0.
Report_full_tree = 1（ノードがソースツリー全体を報告するように）の場合、RNはすべての到達可能なノード、つまりすべてのノードで構成されているため、Pred（U）がnullではないようにuがあります。この方法でRNを計算する手順は、update_rn_simple（）と呼ばれます。このセクションの残りの部分では、RNがREPORT_FULL_TREE = 0を仮定して計算方法について説明します。
A node first determines which of its neighbors belong to RN. Node i includes a neighbor j in RN if and only if node i determines that one of its neighbors may select i to be its next hop on its shortest path to j. To make this determination, node i computes the shortest paths, up to 2 hops, from each neighbor to each other neighbor, using only neighbors (or node i itself) as an intermediate node, and using relay priority and router ID to break ties. If a link metric is used, then shortest paths are computed with respect to the link metric; otherwise min-hop paths are computed.
ノードは、最初にその隣人のどれがRNに属しているかを決定します。ノードIには、Node IがNode Iがjへの最短パスで次のホップになるようにiを選択できると判断した場合にのみ、RNに近隣jが含まれます。この決定を行うために、ノードIは、隣の隣から隣の隣に、隣の最短パスを最大2ホップ、近隣のノードとして（またはNode I自体）のみを中間ノードとして使用し、リレーの優先度とルーターIDを使用してネクタイを破ります。リンクメトリックが使用される場合、リンクメトリックに関して最短パスが計算されます。それ以外の場合は、Min-Hopパスが計算されます。
After a node determines which neighbors are in RN, each node u (other than node i) in the topology table is included in RN if and only if the next hop p(u) to u is in RN. Equivalently, node u is included in RN if and only if u is in the subtree of T rooted at some neighbor j that is in RN. Thus, the reported subtree RT includes the subtrees of T that are rooted at neighbors in RN. Node i also includes itself in RN; thus RT also includes all local links (i,j) to neighbors j.
ノードがRNにいる近隣beが決定した後、トポロジテーブルの各ノードu（ノードI以外）は、次のホップp（u）がRNにある場合にのみRNに含まれます。同等に、uがRNにある隣のJに根付いているTのサブツリーにある場合にのみ、Node UがRNに含まれます。したがって、報告されたサブツリーRTには、RNの近隣に根が張られているTのサブツリーが含まれます。ノードIはRNにも含まれています。したがって、RTには、近隣jへのすべてのローカルリンク（i、j）も含まれます。
The precise procedure for updating RN is defined as follows:
RNを更新するための正確な手順は、次のように定義されています。
Update_RN() 1. Set RN = empty. 2. For each neighbor s in N such that s is in r(s), i.e., such that s is reporting itself: (Initialize to run Dijkstra for source s, for 2 hops.) 2.1. For each node j in N+{i}, set dist(j) = INFINITY and par(j) = NULL. 2.2. Set dist(s) = 0 and par(s) = s. 2.3. For each node j in N+{i} such that (s,j) is in TG: 2.3.1. Set dist(j) = metric(s,j), par(j) = j. 2.3.2. For each node k in N such that (j,k) is in TG: 2.3.2.1. Set cost = metric(j,k). 2.3.2.2. If (dist(j) + cost, nbr_pri(j), j) is lexicographically less than (dist(k), nbr_pri(par(k)), par(k)), set dist(k) = dist(j) + cost and par(k) = j. 2.4. For each neighbor j in N, add j to RN if par(j) = i. 3. Add i to RN. (Node i is always in RN.) 4. For each node u in the topology table, add u to RN if p(u) is in RN.
update_rn（）1。rn = emptを設定します。2. sがr（s）、つまりsがそれ自体を報告するようにnの各隣接sについて：（ソースSのダイクストラを2ホップで実行するために初期化。）2.1。n {i}の各ノードjについて、dist（j）= infinityとpar（j）= nullを設定します。2.2。dist（s）= 0およびpar（s）= sを設定します。2.3。n {i}の各ノードjについて、（s、j）がtg：2.3.1にあるように。set dist（j）= metric（s、j）、par（j）= j。2.3.2。（j、k）がtg：2.3.2.1にあるように、nの各ノードkについて。set cost = metric（j、k）。2.3.2.2。if（dist（j）cost、nbr_pri（j）、j）は、辞書学的に（dist（k）、nbr_pri（par（k））、par（k））、set（k）= dist（j）costおよびpar（k）= j。2.4。nの各隣のjについて、par（j）= iの場合、jをrnに追加します。3.私をRNに追加します。（ノードIは常にRNです。）4。トポロジテーブルの各ノードuについて、p（u）がRNにある場合はuをRNに追加します。
In some cases it may be desirable to limit the radius (number of hops) that topology information is propagated. Since each TBRPF packet is sent only to immediate (1-hop) neighbors, this cannot be achieved by using a time-to-live field. Instead, the propagation of topology information can be limited to a radius of K hops by limiting RN (at all nodes) to include only nodes that are at most K-1 hops away. Assuming min-hop routing is used, so that d(u) is the number of hops to node u, this can be done by modifying Step 4 of Update_RN() as follows:
場合によっては、トポロジ情報が伝播される半径（ホップ数）を制限することが望ましい場合があります。各TBRPFパケットは即時（1ホップ）の隣人にのみ送信されるため、これは時間までのフィールドを使用しては達成できません。代わりに、トポロジー情報の伝播は、RN（すべてのノードで）を制限して、最大のK-1ホップ離れたノードのみを含めることにより、Kホップの半径に制限できます。Min-Hopルーティングが使用されていると仮定すると、D（U）がNode Uのホップ数になるように、これはupdate_rn（）のステップ4を次のように変更することで実行できます。
4. For each node u in the topology table, add u to RN if p(u) is in RN and d(u) <= K-1.
4. トポロジテーブルの各ノードuについて、p（u）がRNおよびd（u）<= k-1である場合、uをRNに追加します。
Every PER_UPDATE_INTERVAL seconds, each node generates and transmits, on all interfaces, a set of FULL TOPOLOGY UPDATE messages (one message for each node in RN that is not a leaf of T), which describes the reported subtree RT. Whenever possible, these messages are included in a single packet, in order to minimize the number of control packets transmitted.
すべてのper_update_interval秒、各ノードは、すべてのインターフェイスで一連の完全なトポロジアップデートメッセージ（tの葉ではないRNの各ノードの1つのメッセージ）を生成および送信し、報告されたサブツリーRTを説明します。可能な限り、これらのメッセージは、送信されるコントロールパケットの数を最小限に抑えるために、単一のパケットに含まれています。
Each topology update message contains the router IDs for n+1 nodes u, v_1,...,v_n, which represent the n links (u,v_1),..., (u,v_n). The n head nodes v_1,..., v_n are divided into three lists in order to convey additional information and thus reduce the number of messages that must be generated. In particular, the first NRL head nodes are leaves of T, thus avoiding the need to generate separate topology update messages for leaf nodes u. Similarly, the last n-(NRL+NRNL) head nodes are not in RN, thus avoiding the need to generate separate topology update messages for nodes u that have been removed from RN.
各トポロジの更新メッセージには、n 1ノードu、v_1、...、v_nのルーターIDが含まれています。これは、nリンク（u、v_1）、...、（u、v_n）を表します。nヘッドノードv_1、...、v_nは、追加情報を伝えるために3つのリストに分割され、生成する必要があるメッセージの数を減らすことができます。特に、最初のNRLヘッドノードはtの葉であるため、葉のノードuの個別のトポロジアップデートメッセージを生成する必要性を回避します。同様に、最後のn-（nrl nrnl）ヘッドノードはRNではないため、RNから削除されたノードuの個別のトポロジアップデートメッセージを生成する必要性を回避します。
Periodic update messages are generated according to procedure Generate_Periodic_Update(), defined as follows (where node i is the node executing the procedure):
定期的な更新メッセージは、プロシージャGenerate_perioDic_update（）に従って生成されます。
Generate_Periodic_Update() For each node u in RN (including node i) that is not a leaf of T, add the update (FULL, n, NRL, NRNL, u, v_1,..., v_n) to msg_list(I) for each interface I, where:
generate_periodic_update（）rn（ノードiを含む）の各ノードuのtの葉ではない、更新（full、n、nrl、nrnl、u、v_1、...、v_n）をmsg_list（i）に追加します。各インターフェイスi、ここで
(a) v_1,..., v_n are the nodes v such that (u,v) is in T, the first NRL of these are nodes in RN that are leaves of T, the next NRNL of these are nodes in RN that are not leaves of T, and the last n-(NRL+NRNL) of these are not in RN.
(a) v_1、...、v_nはノードvであるため、（u、v）はtに、これらの最初のnrlはtの葉であるRNのノードであり、これらの次のnrnlは葉ではないRNのノードですT、およびこれらの最後のn-（nrl nrnl）はRNにはありません。
(b) If USE_METRICS = 1, then the M (metrics) bit is set to 1 and the link metrics metric(u,v_1),..., metric(u,v_n) are included in the message.
(b) use_metrics = 1の場合、m（metrics）ビットは1に設定され、リンクメトリックメトリック（u、v_1）、...、metric（u、v_n）がメッセージに含まれています。
Every DIFF_UPDATE_INTERVAL seconds, if it is not time to generate a periodic update, and if RT has changed since the last time a topology update was generated, a set of TOPOLOGY UPDATE messages describing the changes to RT is generated and transmitted on all interfaces. These messages are constructed according to procedure Generate_Differential_Update(), defined as follows:
すべてのdiff_update_interval秒、定期的な更新を生成する時が来なかった場合、およびトポロジの更新が最後に生成されてからRTが変更された場合、RTの変更を記述するトポロジアップデートメッセージのセットが生成され、すべてのインターフェイスで送信されます。これらのメッセージは、次のように定義されている手順のgenerate_differential_update（）に従って構築されます。
Generate_Differential_Update() For each node u in RN: 1. If u is not in old_RN (u was added to RN) and is not a leaf of T, add the update (FULL, n, NRL, NRNL, u, v_1,..., v_n) to msg_list(I) for each I, where: (a) v_1,..., v_n, NRL, and NRNL are defined as above for periodic updates. (b) If USE_METRICS = 1, then the M (metrics) bit is set to 1 and the link metrics metric(u,v_1),..., metric(u,v_n) are included in the message.
RNの各ノードuのGenerate_differential_update（）：1。uがold_rn（uがrnに追加されていない）であり、tの葉ではない場合は、更新（full、n、nrl、nrnl、u、v_1、。..、v_n）to msg_list（i）各i、ここで、（a）v_1、...、v_n、nrl、およびnrnlは、周期的な更新のために上記のように定義されます。（b）use_metrics = 1の場合、m（metrics）ビットは1に設定され、リンクメトリックメトリック（u、v_1）、...、metric（u、v_n）がメッセージに含まれています。
2. Else, if u is in old_RN and is not a leaf of T: 2.1. Let v_1,..., v_n be the nodes v such that (u,v) is in T AND at least one of the following 3 conditions holds: (a) (u,v) is not in old_T, or (b) v is in old_RN but not in RN, or (c) v is a leaf and is in RN but not in old_RN. 2.2. If this set of nodes is nonempty, add the update (ADD, n, NRL, NRNL, u, v_1,..., v_n) to msg_list(I) for each interface I, where: (a) NRL and NRNL are defined as above. (b) If USE_METRICS = 1, then the M (metrics) bit is set to 1 and the link metrics metric(u,v_1),..., metric(u,v_n) are included in the message.
2. それ以外の場合、uがold_rnにあり、t：2.1の葉ではない場合。v_1、...、v_nはノードvとします。これにより、（u、v）がtになり、少なくとも次の3つの条件の1つが保持されます。（a）（u、v）はold_tではありません、または（b）vはold_rnにありますが、rnではなく、（c）vは葉であり、rnにありますが、old_rnにはありません。2.2。このノードのセットが空でない場合は、更新（追加、n、nrl、nrnl、u、v_1、...、v_n）をmsg_list（i）に追加します。上記のように。（b）use_metrics = 1の場合、m（metrics）ビットは1に設定され、リンクメトリックメトリック（u、v_1）、...、metric（u、v_n）がメッセージに含まれています。
3. If u is in old_RN: 3.1. Let v_1,..., v_n be the nodes v such that (u,v) is in old_T but not in TG, and either IMPLICIT_DELETION = 0 or pred(v) is not in RN (or is NULL). (If IMPLICIT_DELETION = 1 and pred(v) is in RN, then the deletion of (u,v) is implied by an ADD update for another link (w,v).) 3.2. If this set of nodes is nonempty, add the update (DELETE, n, u, v_1,..., v_n) to msg_list(I) for each I.
3. uがold_rnにある場合：3.1。v_1、...、v_nは、（u、v）がold_tではなく、tgではなく、inclicit_deletion = 0またはpred（v）がrn（またはnull）ではないようにノードvとします。（Implicit_Deletion = 1およびPred（v）がRNである場合、（u、v）の削除は、別のリンク（w、v）の追加更新で暗示されます。）3.2。このノードのセットが空でない場合は、更新（delete、n、u、v_1、...、v_n）を各Iのmsg_list（i）に追加します。
When a packet containing a list (msg_list) of TOPOLOGY UPDATE messages is received from node j, the list is processed according to the procedure Process_Updates(j, msg_list), defined as follows. In particular, this procedure updates TT, TG, and the reporting neighbor lists r(u) and r(u,v). If any link in T has been deleted from TG, then Update_Source_Tree() and Update_Routing_Table() are called to provide immediate rerouting.
トポロジアップデートメッセージのリスト（MSG_LIST）を含むパケットがノードJから受信されると、リストは次のように定義された手順Process_Updates（J、MSG_LIST）に従って処理されます。特に、この手順はTT、TG、およびレポートの隣接がR（U）とR（U、V）をリストします。Tのリンクがtgから削除されている場合、update_source_tree（）およびupdate_routing_table（）が呼び出され、即時の再ルーティングが提供されます。
Process_Updates(j, msg_list)
1. For each update = (subtype, n, NRL, NRNL, u, v_1,..., v_n)
in msg_list:
1.1. Create an entry for u in TT if it does not exist.
1.2. If subtype = FULL, Process_Full_Update(j, update).
1.3. If subtype = ADD, Process_Add_Update(j, update).
1.4. If subtype = DELETE, Process_Delete_Update(j, update).
2. If there exists any link in T that is not in TG:
2.1. Update_Source_Tree().
2.2. Update_Routing_Table().
Process_Full_Update(j, update) 1. Add j to r(u). 2. Set rt_expire(j,u) = current_time + TOP_HOLD_TIME. 3. For each link (u,v) s.t. j is in r(u,v): 3.1. Remove j from r(u,v). 3.2. If pred(j,v) = u, set pred(j,v) = NULL. 4. If j = p(u) OR p(u) = NULL: 4.1. Set tg_expire(u) = current_time + TOP_HOLD_TIME. 4.2. For each v s.t. (u,v) is in TG, If reported(u,v) = 1, remove (u,v) from TG. 5. Process_Add_Update(j, update).
process_full_update（j、update）1。jをr（u）に追加します。2. rt_expire（j、u）= current_time top_hold_timeを設定します。3.各リンク（u、v）s.t。jはr（u、v）：3.1です。r（u、v）からjを削除します。3.2。pred（j、v）= u、set pred（j、v）= nullの場合。4. j = p（u）またはp（u）= null：4.1の場合。tg_expire（u）= current_time top_hold_timeを設定します。4.2。各V S.T.（u、v）はtgです。報告されている場合（u、v）= 1、tgから除去（u、v）。5. process_add_update（j、update）。
Process_Add_Update(j, update)
For m = 1,..., n:
((u,v_m) is the mth link in update.)
1. Let v = v_m.
2. Create an entry for v in TT if it does not exist.
3. Add j to r(u,v).
4. If j = p(u) OR p(u) = NULL:
4.1. Add (u,v) to TG.
4.2. Set reported(u,v) = 1.
5. If the M (metrics) bit in update is 1:
5.1. Set metric(j,u,v) to the m-th metric in the update.
5.2. If j = p(u) OR p(u) = NULL:
5.2.1. Set metric(u,v) = metric(j,u,v).
5.2.2. If USE_METRICS = 1, set c(u,v) = metric(u,v).
6. If the D (implicit deletion) bit in update is 1:
6.1. Set w = pred(j,v).
6.2. If (w != NULL AND w != u):
6.2.1. Remove j from r(w,v).
6.2.2. If j = p(w), remove (w,v) from TG.
7. Set pred(j,v) = u. (Set new predecessor.)
8. If m <= NRL (v = v_m is a reported leaf):
8.1. Set leaf_update = (FULL, 0, 0, 0, v).
8.2. Process_Full_Update(j, leaf_update).
9. If m > NRL + NRNL (v = v_m is not reported by j):
9.1. Remove j from r(v).
9.2. Set rt_expire(j,v) = 0.
9.3. For each node w s.t. j is in r(v,w),
remove j from r(v,w).
9.4. If j = p(v), then for each node w s.t. (v,w) is in TG and reported(v,w) = 1, set reported(v,w) = 0 and set nr_expire(v,w) = current_time + PER_UPDATE_INTERVAL.
9.4. j = p（v）の場合、各ノードw s.t.（v、w）はtgで、報告された（v、w）= 1、報告（v、w）= 0を設定し、nr_expire（v、w）= current_time per_update_intervalを設定します。
Process_Delete_Update(j, update) For m = 1,..., n: ((u,v_m) is the mth link in update.) 1. Let v = v_m. 2. Remove j from r(u,v). 3. If pred(j,v) = u, set pred(j,v) = NULL. 4. If j = p(u), remove (u,v) from TG.
m = 1、...、n：（（u、v_m）のprocess_delete_update（j、update）は、更新のmthリンクです。）1。v = v_mとします。2. r（u、v）からjを削除します。3. pred（j、v）= uの場合、pred（j、v）= nullを設定します。4. j = p（u）の場合、tgから（u、v）を削除します。
Each node periodically checks for outdated topology information based on the expiration timers tg_expire(u), rt_expire(j,u), and nr_expire(u,v), and removes any expired entries from TG and from the lists r(u) and r(u,v). This is done according to the following procedure Expire_Links(), which is called periodically just before the source tree is updated.
各ノードは定期的に有効期限タイマーTG_EXPIRE（U）、RT_EXPIRE（J、U）、およびNR_EXPIRE（U、V）に基づいて時代遅れのトポロジ情報をチェックし、TGおよびリストR（U）およびR Rから期限切れのエントリを削除します。（u、v）。これは、次の手順に従って行われます。
Expire_Links() For each node u in TT other than node i: 1. If tg_expire(u) < current_time, then for each v s.t. (u,v) is in TG, remove (u,v) from TG. 2. Else, for each v s.t. (u,v) is in TG, if reported(u,v) = 0 AND nr_expire(u,v) < current_time, remove (u,v) from TG. 3. For each node j in r(u), if rt_expire(j,u) < current_time: 3.1. Remove j from r(u). 3.2. For each link (u,v) s.t. j is in r(u,v), remove j from r(u,v).
Node I以外のTTの各ノードUのExpire_links（）：1。tg_expire（u）<current_timeの場合、各v s.t.（u、v）はtgにあり、tgから除去（u、v）。2.その他、各V S.T.（u、v）はtgで、報告されている場合（u、v）= 0およびnr_expire（u、v）<current_time、tgから削除（u、v）。3. r（u）の各ノードjについて、rt_expire（j、u）<current_time：3.1の場合。r（u）からjを削除します。3.2。各リンク（u、v）s.t。jはr（u、v）で、r（u、v）からjを削除します。
In addition, the following cleanup steps SHOULD be executed periodically to remove unnecessary entries from the topology table TT. A link (u,v) should be removed from TT if it is not in TG and not in old_T. A node u should be removed from TT if all of the following conditions hold: r(u) is empty, r(w,u) is empty for all w, and no link of TG has u as either the head or the tail.
さらに、トポロジテーブルTTから不要なエントリを削除するために、次のクリーンアップ手順を定期的に実行する必要があります。リンク（u、v）は、tgではなく、old_tではなく、TTから削除する必要があります。次のすべての条件が保持されている場合は、ノードuをTTから削除する必要があります。R（u）が空で、r（w、u）はすべてのwに対して空であり、tgのリンクはヘッドまたはテールのいずれかのuを持っていません。
Each node is required to report its reported subtree RT to neighbors. However, each node (independently of the other nodes) MAY report additional links, e.g., to provide increased robustness in highly mobile networks. For example, a node may compute any subgraph H of TG that contains T, and may report the "reported subgraph" RH which consists of links (u,v) of H such that u is in RN. In this case, each periodic update describes RH instead of RT, and each differential update describes changes to RH. If this option is used, then the parameter IMPLICIT_DELETION MUST be set to 0, since the deletion of a link cannot be implied by the addition of another link if redundant topology information is reported.
各ノードは、報告されたサブツリーRTをNeighborに報告する必要があります。ただし、各ノード（他のノードとは独立して）が追加のリンクを報告する場合があります。たとえば、高度にモバイルネットワークで堅牢性を高めることができます。たとえば、ノードはTを含むTGのサブグラフhを計算し、uがRNであるようにHのリンク（u、v）で構成される「報告されたサブグラフ」RHを報告することができます。この場合、各周期的な更新はRTの代わりにRHを記述し、各差更新はRHの変更を記述します。このオプションを使用する場合、冗長トポロジー情報が報告されている場合、別のリンクの追加によってリンクの削除を暗示できないため、パラメーターImplitity_Deletionを0に設定する必要があります。
This section describes the procedures that are followed when the neighbor discovery module detects a new link, the loss of a link, or a change in the metric for a link.
このセクションでは、Neighbor Discoveryモジュールが新しいリンク、リンクの損失、またはリンクのメトリックの変更を検出したときに従う手順について説明します。
When a link (I,J) from a local interface I to a neighbor interface J is discovered via the neighbor discovery module, the procedure Link_Up(I,J) is executed, as defined below. Letting j be the neighbor node associated with interface J, Link_Up(I,J) adds j to N (if it does not already belong), updates the preferred local interface local_if(j) and neighbor interface nbr_if(j) so that the link from local_if(j) to nbr_if(j) has the minimum metric among all links from i to j, and updates metric(i,j) to be this minimum metric.
ローカルインターフェイスIからNeighborインターフェイスjがNeighbor Discoveryモジュールを介して発見されるリンク（i、j）は、以下に定義するように、手順Link_up（i、j）が実行されます。jをインターフェイスj、link_up（i、j）に関連付けられたネイバーノードにします（i、j）はjをn（まだ属していない場合）を追加し、希望するローカルインターフェイスlocal_if（j）およびneighbor interface nbr_if（j）を更新してリンクを更新しますlocal_if（j）からnbr_if（j）まで、iからjへのすべてのリンクの中で最小メトリックがあり、メトリック（i、j）を更新して、この最小メトリックにします。
Link_Up(I,J) 1. Let j = nbr_rid(I,J). 2. If j is not in N: 2.1. Add j to N. 2.2. Add (i,j) to TG. 2.3. Set reported(i,j) = 1. 3. If nbr_metric(I,J) < metric(i,j), set local_if(j) = I, nbr_if(j) = J, and metric(i,j) = nbr_metric(I,J). 4. If USE_METRICS = 1, set cost(i,j) = metric(i,j).
link_up（i、j）1。j = nbr_rid（i、j）とします。2. jがn：2.1にない場合。JをNに追加します。2.2。（i、j）をtgに追加します。2.3。set Report（i、j）= 1. 3. nbr_metric（i、j）<metric（i、j）、set local_if（j）= i、nbr_if（j）= j、およびmetric（i、j）=nbr_metric（i、j）。4. use_metrics = 1の場合、コスト（i、j）= metric（i、j）を設定します。
When the loss of a link (I,J) from a local interface I to a neighbor interface J is detected via the neighbor discovery module, the procedure Link_Down(I,J) is executed, as defined below. Note that routes are updated immediately when a link is lost, and if the lost link is due to a link-layer failure notification, a differential topology update is sent immediately.
ローカルインターフェイスIからNeighborインターフェイスJへのリンク（i、j）の損失がNeighbor Discoveryモジュールを介して検出されると、以下に定義されているように、手順Link_down（i、j）が実行されます。リンクが失われたときにルートはすぐに更新され、失われたリンクがリンク層障害通知によるものである場合、差動トポロジの更新がすぐに送信されます。
Link_Down(I,J) 1. Let j = nbr_rid(I,J). 2. If there does not exist a link (K,L) from node i to node j with nbr_status(K,L) = 2-WAY: 2.1. Remove j from N. 2.2. Remove (i,j) from TG. 3. If j is in N: 3.1. Let (K,L) be a link from i to j such that nbr_metric(K,L) is the minimum metric among all links from i to j.
link_down（i、j）1。j = nbr_rid（i、j）とします。2. NBR_STATUS（k、L）= 2-way：2.1を使用して、ノードIからノードJへのリンク（k、l）が存在しない場合：2.1。NからJを削除します。2.2。tgから（i、j）を削除します。3. jがn：3.1にある場合。NBR_METRIC（K、L）がIからJへのすべてのリンクの中で最小メトリックであるように、（k、l）をiからJへのリンクとします。
3.2. Set local_if(j) = K, nbr_if(j) = L, and metric(i,j) = nbr_metric(K,L). 3.3. If USE_METRICS = 1, set cost(i,j) = metric(i,j). 5. Update_Source_Tree(). 6. Update_Routing_Table(). 7. If j is not in N and lost link is due to link-layer failure notification: 7.1. If (REPORT_FULL_TREE = 0) Update_RN(). 7.2. Else, Update_RN_Simple(). 7.3. Set msg_list = empty. 7.4. Generate_Diff_Update(). 7.5. Send msg_list on all interfaces. 7.6. Set old_T = T and old_RN = RN.
3.2。local_if（j）= k、nbr_if（j）= l、およびmetric（i、j）= nbr_metric（k、l）を設定します。3.3。use_metrics = 1の場合、コスト（i、j）= metric（i、j）を設定します。5. update_source_tree（）。6. update_routing_table（）。7. JがNになく、失われたリンクがリンク層障害通知によるものである場合：7.1。if（report_full_tree = 0）update_rn（）。7.2。その他、update_rn_simple（）。7.3。msg_list = emptを設定します。7.4。Generate_diff_update（）。7.5。すべてのインターフェイスでMSG_LISTを送信します。7.6。Old_t = tおよびold_rn = rnを設定します。
If the metric of a link (I,J) from a local interface I to a neighbor interface J changes via the neighbor discovery module, the following procedure Link_Change(I,J) is executed.
ローカルインターフェイスIからNeighborインターフェイスJへのリンク（i、j）のメトリックがNeighbor Discoveryモジュールを介して変更された場合、次の手順Link_Change（I、J）が実行されます。
Link_Change(I,J) 1. Let j = nbr_rid(I,J). 2. Let (K,L) be a link from i to j such that nbr_metric(K,L) is the minimum metric among all links from i to j. 3. Set local_if(j) = K, nbr_if(j) = L, and metric(i,j) = nbr_metric(K,L). 4. If USE_METRICS = 1, set cost(i,j) = metric(i,j).
link_change（i、j）1。j = nbr_rid（i、j）とします。2.（k、l）をiからjへのリンクとし、nbr_metric（k、l）がiからjへのすべてのリンクの最小メトリックになるようにします。3. local_if（j）= k、nbr_if（j）= l、およびmetric（i、j）= nbr_metric（k、l）を設定します。4. use_metrics = 1の場合、コスト（i、j）= metric（i、j）を設定します。
This section describes the procedures used to generate INTERFACE ASSOCIATION, HOST ASSOCIATION, and NETWORK PREFIX ASSOCIATION messages. Addresses or prefixes in the interface table, host table, and network prefix table are reported to neighbors periodically every IA_INTERVAL, HA_INTERVAL, and NPA_INTERVAL seconds, respectively. In addition, differential changes to the tables are reported every DIFF_UPDATE_INTERVAL seconds if it is not time for a periodic update (similar to differential topology updates). Each node reports only addresses or prefixes that are associated with nodes in the reported node set RN; this ensures the efficient broadcast of all associated addresses and prefixes to all nodes in the network.
このセクションでは、インターフェイスアソシエーション、ホストアソシエーション、ネットワークプレフィックス関連メッセージを生成するために使用される手順について説明します。インターフェイステーブル、ホストテーブル、およびネットワークプレフィックステーブルのアドレスまたはプレフィックスは、それぞれIA_INTERVAL、HA_INTERVAL、およびNPA_INTERVAL秒ごとに定期的に近隣に報告されます。さらに、定期的な更新の時間ではない場合、テーブルの差動の変更は、diff_update_interval秒ごとに報告されます（微分トポロジの更新と同様）。各ノードは、報告されたノードセットRNのノードに関連付けられているアドレスまたはプレフィックスのみを報告します。これにより、ネットワーク内のすべてのノードに関連するすべてのアドレスとプレフィックスの効率的なブロードキャストが保証されます。
The generated messages are sent on each interface. Whenever possible, these messages are combined into the same packet, in order to minimize the number of control packets transmitted.
生成されたメッセージは、各インターフェイスで送信されます。可能な限り、これらのメッセージは、送信されるコントロールパケットの数を最小限に抑えるために、同じパケットに結合されます。
Generate_Association_Messages() 1. Generate_Interface_Association_Messages(). 2. Generate_Host_Association_Messages().
Generate_association_messages（）1。Generate_interface_association_messages（）。2. generate_host_association_messages（）。
3. Generate_Network_Prefix_Association_Messages().
3. Generate_network_prefix_association_messages（）。
Generate_Interface_Association_Messages() 1. If current_time > next_ia_time: 1.1. Set next_ia_time = current_time + IA_INTERVAL. 1.2. For each node u in RN: 1.2.1. Let addr_1,..., addr_n be the interface IP addresses associated with RID u in the current interface table. 1.2.2. If this list is nonempty, add the INTERFACE ASSOCIATION message (FULL, n, u, addr_1,..., addr_n) to msg_list(I) for each I.
Generate_interface_association_messages（）1。if current_time> next_ia_time：1.1。next_ia_time = current_time ia_intervalを設定します。1.2。RNの各ノードuについて：1.2.1。addr_1、...、addr_nを、現在のインターフェイステーブルのrid uに関連付けられたインターフェイスIPアドレスとします。1.2.2。このリストが空でない場合は、インターフェイスアソシエーションメッセージ（Full、n、u、addr_1、...、addr_n）を各Iのmsg_list（i）に追加します。
2. Else, for each node u in RN: 2.1. Add the INTERFACE ASSOCIATION message (ADD, n, u, addr_1,..., addr_n) to msg_list(I) for each I, where addr_1,..., addr_n are the interface IP addresses that are associated with RID u in the current interface table but not in the old interface table. 2.2. Add the INTERFACE ASSOCIATION message (DELETE, n, u, addr_1,..., addr_n) to msg_list(I) for each I, where addr_1,..., addr_n are the interface IP addresses that are associated with RID u in the old interface table but not in the current interface table.
2. それ以外の場合、RNの各ノードuについて：2.1。インターフェイスアソシエーションメッセージ（add、n、u、addr_1、...、addr_n）を各iにmsg_list（i）に追加します。ここで、addr_1、...、addr_nは、現在のインターフェイステーブルは、古いインターフェイステーブルにはありません。2.2。インターフェイスアソシエーションメッセージ（delete、n、u、addr_1、...、addr_n）を各iにmsg_list（i）に追加します。ここで、addr_1、...、addr_nは、古いインターフェイステーブルですが、現在のインターフェイステーブルにはありません。
Generate_Host_Association_Messages() 1. If current_time > next_ha_time: 1.1. Set next_ha_time = current_time + HA_INTERVAL. 1.2. For each node u in RN: 1.2.1. Let addr_1,..., addr_n be the host IP addresses associated with RID u in the current host table. 1.2.2. If this list is nonempty, add the HOST ASSOCIATION message (FULL, n, u, addr_1,..., addr_n) to msg_list(I) for each I.
Generate_host_association_messages（）1。if current_time> next_ha_time：1.1。next_ha_time = current_time ha_intervalを設定します。1.2。RNの各ノードuについて：1.2.1。addr_1、...、addr_nを、現在のホストテーブルのRID Uに関連付けられたホストIPアドレスとします。1.2.2。このリストが空でない場合は、ホストアソシエーションメッセージ（full、n、u、addr_1、...、addr_n）を各Iのmsg_list（i）に追加します。
2. Else, for each node u in RN: 2.1. Add the HOST ASSOCIATION message (ADD, n, u, addr_1,..., addr_n) to msg_list(I) for each I, where addr_1,..., addr_n are the host IP addresses that are associated with RID u in the current host table but not in the old host table. 2.2. Add the HOST ASSOCIATION message (DELETE, n, u, addr_1,..., addr_n) to msg_list(I) for each I, where addr_1,..., addr_n are the host IP addresses that are associated with RID u in the old host table but not in the current host table.
2. それ以外の場合、RNの各ノードuについて：2.1。ホストアソシエーションメッセージ（add、n、u、addr_1、...、addr_n）を各iのmsg_list（i）に追加します。ここで、addr_1、...、addr_nは、現在のホストテーブルですが、古いホストテーブルにはありません。2.2。ホストアソシエーションメッセージ（delete、n、u、addr_1、...、addr_n）を各iにmsg_list（i）に追加します。ここで、addr_1、...、addr_nは、古いホストテーブルですが、現在のホストテーブルにはありません。
Generate_Network_Prefix_Association_Messages() 1. If current_time > next_npa_time: 1.1. Set next_npa_time = current_time + NPA_INTERVAL. 1.2. For each node u in RN: 1.2.1. Let length_1, prefix_1,..., length_n, prefix_n be the network prefix lengths and prefixes associated with RID u in the current network prefix table. 1.2.2. If this list is nonempty, add the NETWORK PREFIX ASSOCIATION message (FULL, n, u, length_1, prefix_1, ..., length_n, prefix_n) to msg_list(I) for each I.
Generate_network_prefix_association_messages（）1。if current_time> next_npa_time：1.1。next_npa_time = current_time npa_intervalを設定します。1.2。RNの各ノードuについて：1.2.1。length_1、prefix_1、...、length_n、prefix_nは、現在のネットワークプレフィックステーブルのRID Uに関連付けられたネットワークプレフィックスの長さとプレフィックスとします。1.2.2。このリストが空でない場合は、ネットワークプレフィックスアソシエーションメッセージ（full、n、u、length_1、prefix_1、...、length_n、prefix_n）を各Iのmsg_list（i）に追加します。
2. Else, for each node u in RN: 2.1. Add the NETWORK PREFIX ASSOCIATION message (ADD, n, u, prefix_1,..., prefix_n) to msg_list(I) for each I, where prefix_1,..., prefix_n are the network prefixes that are associated with RID u in the current prefix table but not in the old prefix table.
2. それ以外の場合、RNの各ノードuについて：2.1。ネットワークプレフィックスアソシエーションメッセージ（add、n、u、u、prefix_1、...、prefix_n）を各iのmsg_list（i）に追加します。ここで、prefix_1、...、prefix_nは、現在のプレフィックステーブルですが、古いプレフィックステーブルにはありません。
2.1. Add the NETWORK PREFIX ASSOCIATION message (DELETE, n, u, prefix_1,..., prefix_n) to msg_list(I) for each I, where prefix_1,..., prefix_n are the network prefixes that are associated with RID u in the old prefix table but not in the current prefix table.
2.1. ネットワークプレフィックスアソシエーションメッセージ（delete、n、u、u、prefix_1、...、prefix_n）を各iのmsg_list（i）に追加します。ここで、prefix_1、...、prefix_nは、古いプレフィックステーブルですが、現在のプレフィックステーブルにはありません。
When an INTERFACE ASSOCIATION, HOST ASSOCIATION, or NETWORK PREFIX ASSOCIATION message is received from node j, the interface table, host table, or network prefix table, respectively, is updated as described in the following three procedures.
インターフェイスアソシエーション、ホストアソシエーション、またはネットワークプレフィックスアソシエーションメッセージがノードJから受信されると、インターフェイステーブル、ホストテーブル、またはネットワークプレフィックステーブルがそれぞれ次の3つの手順で説明されているように更新されます。
Process_Interface_Association_Messages(j, msg_list) For each message (subtype, n, u, addr_1,..., addr_n) in msg_list such that j = p(u): 1. If subtype = FULL, remove all entries with if_rid = u from the interface table. 2. If subtype = FULL or ADD, then for m = 1,..., n, add the tuple (if_addr, if_rid, if_expire) to the interface table, where: if_addr = addr_m, if_rid = u, if_expire = current_time + IA_HOLD_TIME. 3. If subtype = DELETE, then for m = 1,..., n, remove the tuple (if_addr, if_rid, if_expire) from the interface table, where if_addr = addr_m and if_rid = u.
MSG_LISTの各メッセージ（subtype、n、u、addr_1、...、addr_n）のprocess_interface_associationages（j、msg_list）j = p（u）：1。subtype = fullの場合、if_rid = uを使用してすべてのエントリを削除します。インターフェイステーブル。2. subtype = fullまたはaddの場合、m = 1、...、nの場合、tuple（if_addr、if_rid、if_expire）をインターフェイステーブルに追加します。。3. subtype = deleteの場合、m = 1、...、nの場合、インターフェイステーブルからtuple（if_addr、if_rid、if_expire）を削除します。
Process_Host_Association_Messages(j, msg_list) For each message (subtype, n, u, addr_1,..., addr_n) in msg_list such that j = p(u): 1. If subtype = FULL, remove all entries with h_rid = u from the host table. 2. If subtype = FULL or ADD, then for m = 1,..., n, add the tuple (h_addr, h_rid, h_expire) to the host table, where: h_addr = addr_m, h_rid = u, h_expire = current_time + HA_HOLD_TIME. 3. If subtype = DELETE, then for m = 1,..., n, remove the tuple (h_addr, h_rid, h_expire) from the host table, where h_addr = addr_m and h_rid = u.
各メッセージ（subtype、n、u、addr_1、...、addr_n）のmsg_listの各メッセージのprocess_host_association_messages（j、msg_list）j = p（u）：1。subtype = fullの場合、h_rid = uを使用してすべてのエントリを削除します。ホストテーブル。2. subtype = fullまたはaddの場合、m = 1、...、nの場合、タプル（h_addr、h_rid、h_expire）をホストテーブルに追加します。。3. subtype = deleteの場合、m = 1、...、nの場合、ホストテーブルからタプル（h_addr、h_rid、h_expire）を削除します。ここで、h_addr = addr_mおよびh_rid = u。
Process_Network_Prefix_Association_Messages(j, msg_list) For each message (subtype, n, u, length_1, prefix_1, ..., length_n, prefix_n) in msg_list such that j = p(u): 1. If subtype = FULL, remove all entries with net_rid = u from the prefix table. 2. If subtype = FULL or ADD, then for m = 1,..., n, add the tuple (net_prefix, net_length, net_rid, net_expire) to the network prefix table, where: net_prefix = prefix_m, net_length = length_m, net_rid = u, net_expire = current_time + NPA_HOLD_TIME. 3. If subtype = DELETE, then for m = 1,..., n, remove the tuple (net_prefix, net_length, net_rid, net_expire) from the network prefix table, where net_prefix = prefix_m, net_length = length_m, and net_rid = u.
j = p（u）の各メッセージ（subtype、n、u、ush_1、prefix_1、...、length_n、prefix_n）の各メッセージ（subtype、n、u、ush_1、prefix_1、...、subtype = fullの場合、subtype = fullの場合、すべてのエントリーを削除して、すべてのエントリーを削除する各メッセージ（subtype、n、u、u、ush_1、prefix_1、...、length_n、prefix_n）のprocess_network_prefix_associations_messages（j、msg_list）net_rid = uプレフィックステーブルから。2. subtype = fullまたはaddの場合、m = 1、...、nの場合、tuple（net_prefix、net_length、net_rid、net_expire）をネットワークプレフィックステーブルに追加します。= u、net_expire = current_time npa_hold_time。3. subtype = deleteの場合、m = 1、...、nの場合、ネットワークプレフィックステーブルからtuple（net_prefix、net_length、net_rid、net_expire）を削除します。。
Nodes with relay priority equal to zero are called non-relay nodes, and do not forward packets (of any type) that are received from other nodes. A non-relay node is implemented simply by not generating or transmitting any TOPOLOGY UPDATE messages. A non-relay node may report (in association messages) addresses or prefixes that are associated with itself, but not those associated with other nodes. HELLO messages must be transmitted in order to establish links with neighbor nodes. The following procedures can be omitted in non-relay nodes: Update_RN(), Generate_Periodic_Update(), and Generate_Diff_Update().
ゼロに等しいリレーの優先度を持つノードは、非関連ノードと呼ばれ、他のノードから受信された（任意のタイプの）パケットを転送しません。非関連ノードは、トポロジの更新メッセージを生成または送信しないだけで実装されます。非関連ノードは、他のノードに関連付けられているものではなく、それ自体に関連付けられているアドレスまたはプレフィックスを（関連メッセージ内）報告する場合があります。近隣ノードとのリンクを確立するには、こんにちはメッセージを送信する必要があります。以下の手順は、非関連ノードで省略できます：update_rn（）、generate_periodic_update（）、およびgenerate_diff_update（）。
This section lists the configurable parameters used by the routing module, and their proposed default values. All nodes MUST have the same value for all of the following parameters except REPORT_FULL_TREE and IMPLICIT_DELETION.
このセクションには、ルーティングモジュールで使用される構成可能なパラメーターと、提案されたデフォルト値をリストします。すべてのノードは、REPORT_FULL_TREEとImplicit_DELETIONを除き、次のすべてのパラメーターに対して同じ値を持つ必要があります。
Parameter Name Default Value
-------------- -------------
DIFF_UPDATE_INTERVAL 1 second
PER_UPDATE_INTERVAL 5 seconds
TOP_HOLD_TIME 15 seconds
NON_REPORT_PENALTY 1.01
NON_TREE_PENALTY 0.01
IA_INTERVAL 10 seconds
IA_HOLD_TIME 3 * IA_INTERVAL
HA_INTERVAL 10 seconds
HA_HOLD_TIME 3 * HA_INTERVAL
NPA_INTERVAL 10 seconds
NPA_HOLD_TIME 3 * NPA_INTERVAL
USE_METRICS 0
REPORT_FULL_TREE 0
IMPLICIT_DELETION 1
This section describes a mechanism for the efficient best-effort flooding (or network-wide broadcast) of packets to all nodes of a connected ad-hoc network. This mechanism can be considered an optimization of the classical flooding algorithm in which each packet is transmitted by every node of the network. In TBRPF flooding, information provided by TBRPF is used to decide whether a given received flooded packet should be forwarded. As a result, each packet is transmitted by only a relatively small subset of nodes, thus consuming much less bandwidth than classical flooding.
このセクションでは、接続されたアドホックネットワークのすべてのノードへのパケットの効率的なベストエフォルトフラッディング（またはネットワーク全体のブロードキャスト）のメカニズムについて説明します。このメカニズムは、各パケットがネットワークのすべてのノードによって送信される古典的なフラッディングアルゴリズムの最適化と見なすことができます。TBRPF洪水では、TBRPFが提供する情報を使用して、与えられた受信した浸水パケットを転送する必要があるかどうかを決定します。その結果、各パケットはノードの比較的小さなサブセットのみで送信されるため、古典的な洪水よりもはるかに少ない帯域幅を消費します。
This document specifies that the flooding mechanism use the IPv4 multicast address 224.0.1.20 (currently assigned by IANA for "any private experiment"). Every node maintains a duplicate cache to keep track of which flooded packets have already been received. The duplicate cache contains, for each received flooded packet, the flooded packet identifier (FPI), which for IPv4 is composed of the source IP address, the IP identification, and the fragment offset values obtained from the IP header [14].
このドキュメントは、フラッディングメカニズムがIPv4マルチキャストアドレス224.0.1.20（現在は「任意のプライベート実験」にIANAによって割り当てられている）を使用することを指定しています。すべてのノードは、重複したキャッシュを維持し、浸水したパケットがすでに受信されていることを追跡します。重複したキャッシュには、受信した各浸水パケット、IPv4の場合はIPv4のIPアドレス、IP識別、およびIPヘッダーから得られたフラグメントオフセット値で構成されている浸水パケット識別子（FPI）が含まれます[14]。
When a node receives a packet whose destination IP address is the flooding address (224.0.1.20), it checks its duplicate cache for an entry that matches the packet. If such an entry exists, the node silently discards the flooded packet since it has already been received. Otherwise, the node retransmits the packet on all interfaces (see the exception below) if and only if the following conditions hold:
宛先IPアドレスがフラッドアドレス（224.0.1.20）であるパケットをノードが受信すると、重複したキャッシュがパケットに一致するエントリをチェックします。そのようなエントリが存在する場合、ノードはすでに受信されているため、浸水したパケットを静かに破棄します。それ以外の場合、ノードは、すべてのインターフェイスのパケットを再送信します（以下の例外を参照）。
1. The TBRPF node associated with the source IP address of the packet belongs to the set RN of reported nodes computed by TBRPF.
1. パケットのソースIPアドレスに関連付けられたTBRPFノードは、TBRPFによって計算された報告されたノードのセットRNに属します。
2. When decremented, the 'ip_ttl' in the IPv4 packet header (respectively, the 'hop_count' in the IPv6 packet header) is greater than zero.
2. 減少すると、IPv4パケットヘッダーの「IP_TTL」（それぞれIPv6パケットヘッダーの「hop_count」）はゼロより大きくなります。
If the packet is to be retransmitted, it is sent after a small random time interval in order to avoid collisions. If the interface on which the packet was received is not a MANET interface (see the Terminology section), then the packet should not be retransmitted on that interface.
パケットを再送信する場合、衝突を避けるために、小さなランダムな時間間隔の後に送信されます。パケットが受信されたインターフェイスがMANETインターフェイスではない場合（用語セクションを参照）、パケットをそのインターフェイスで再送信しないでください。
TBRPF is particularly well suited to MANETs consisting of mobile nodes with wireless network interfaces operating in peer-to-peer fashion over a multiple access communications channel. Although applicable across a much broader field of use, TBRPF is particularly well suited for supporting the standard DARPA Internet protocols [3][2]. In the following sections, we discuss practical considerations for the operation of TBRPF on MANETs.
TBRPFは、複数のアクセス通信チャネルでピアツーピアファッションで動作するワイヤレスネットワークインターフェイスを備えたモバイルノードで構成されるマネットに特に適しています。はるかに広い使用分野で適用可能ですが、TBRPFは標準のDARPAインターネットプロトコルをサポートするのに特に適しています[3] [2]。以下のセクションでは、MANETSでのTBRPFの操作に関する実用的な考慮事項について説明します。
We assume a MANET data link layer that supports broadcast, multicast and unicast addressing with best-effort (not guaranteed) delivery services between neighbors (i.e., a pair of nodes within operational communications range of one another). We further assume that each interface belonging to a node in the MANET is assigned a unicast data link layer address that is unique within the MANET's scope. While such uniqueness is not strictly guaranteed, the assumption of uniqueness is consistent with current practices for deployment of the Internet protocols on specific link layers. Methods for duplicate link layer address detection and deconfliction are beyond the scope of this document.
近隣の間のベストエフォルト（保証されていない）配信サービスを使用した放送、マルチキャスト、ユニキャストのアドレス指定をサポートするMANETデータリンクレイヤー（つまり、互いの運用通信範囲内のノードのペア）を想定しています。さらに、マネのノードに属する各インターフェイスには、マネの範囲内で一意のユニカストデータリンクレイヤーアドレスが割り当てられていると仮定します。このような独自性は厳密に保証されていませんが、一意性の仮定は、特定のリンクレイヤー上のインターネットプロトコルの展開に関する現在の慣行と一致しています。重複するリンクレイヤーアドレスの検出とデコンフリクションの方法は、このドキュメントの範囲を超えています。
MANETs are formed as collections of routers and non-routing nodes that use network layer addresses when calculating the MANET topology. We assume that each node has at least one data link layer interface (described above) and that each such interface is assigned a network layer address that is unique within the MANET. (Methods for network layer address assignment and duplicate address detection are beyond the scope of this document.) We further assume that each node will select a unique Router ID (RID) for use in TBRPF protocol messages, whether or not the node acts as a MANET router. Finally, we assume that each MANET router supports the multi-hop relay paradigm at the network layer; i.e., each router provides an inter-node forwarding service via network layer host routes which reflect the current MANET topology as perceived by TBRPF.
マネは、マネトポロジを計算するときにネットワークレイヤーアドレスを使用するルーターと非ルーティングノードのコレクションとして形成されます。各ノードには、少なくとも1つのデータリンクレイヤーインターフェイス（上記）があり、そのような各インターフェイスにはマネ内で一意のネットワークレイヤーアドレスが割り当てられていると想定しています。（ネットワークレイヤーアドレスの割り当てのメソッドおよびアドレスの検出の重複は、このドキュメントの範囲を超えています。）さらに、各ノードは、ノードが機能するかどうかにかかわらず、TBRPFプロトコルメッセージで使用するために一意のルーターID（RID）を選択すると仮定します。マネルーター。最後に、各MANETルーターがネットワークレイヤーでマルチホップリレーパラダイムをサポートしていると仮定します。つまり、各ルーターは、TBRPFによって知覚される現在のMANETトポロジを反映するネットワークレイヤーホストルートを介してノード間転送サービスを提供します。
TBRPF employs a proactive neighbor discovery protocol at the network layer that maintains bi-directional link state for neighboring nodes through the periodic transmission of messages. Since TBRPF neighbor discovery messages contain both the data link and network layer address of the sender, implementations MAY perform automatic network-to-data link layer address resolution for the nodes with which they form links. An implementation may use such a mechanism to avoid additional message overhead and potential for packet loss associated with on-demand address resolution mechanisms such as ARP [15] or IPv6 Neighbor Discovery [16]. Implementations MUST respond to on-demand address resolution requests in the normal manner.
TBRPFは、メッセージの周期的な送信を通じて隣接するノードの双方向リンク状態を維持するネットワークレイヤーでプロアクティブな隣接ディスカバリープロトコルを採用しています。TBRPFネイバーディスカバリーメッセージには、送信者のデータリンクとネットワークレイヤーアドレスの両方が含まれているため、実装はリンクを形成するノードの自動ネットワーク間リンクレイヤーアドレス解像度を実行できます。実装は、そのようなメカニズムを使用して、ARP [15]やIPv6 Neighbor Discovery [16]などのオンデマンドアドレス解像度メカニズムに関連する追加のメッセージオーバーヘッドとパケット損失の可能性を回避する場合があります。実装は、通常の方法でオンデマンドのアドレス解決要求に応答する必要があります。
MANET nodes may comprise multiple interfaces; each with a unique network layer address. Additionally, MANET nodes may wish to publish alias addresses such as when multiple network layer addresses are assigned to the same interface or when the MANET node is serving as a Mobile IP [17] home agent. Multiple interfaces and alias addresses are advertised in INTERFACE ASSOCIATION messages, which bind each such address to the node's RID.
MANETノードは、複数のインターフェイスで構成される場合があります。それぞれが一意のネットワークレイヤーアドレスを備えています。さらに、MANETノードは、複数のネットワークレイヤーアドレスが同じインターフェイスに割り当てられている場合、またはMANETノードがモバイルIP [17]ホームエージェントとして機能している場合など、エイリアスアドレスを公開したい場合があります。複数のインターフェイスとエイリアスアドレスがインターフェイスアソシエーションメッセージに宣伝されており、そのような各アドレスをノードのRIDに結合します。
MANET routers may advertise network prefixes which the router discovered via attached networks, external routes advertised by other protocols, or other means. Network prefixes are advertised in NETWORK PREFIX ASSOCIATION messages, which bind each such prefix to the node's RID.
MANETルーターは、添付のネットワーク、他のプロトコルによって宣伝された外部ルート、またはその他の手段を介してルーターが発見したネットワークプレフィックスを宣伝する場合があります。ネットワークのプレフィックスは、ネットワークプレフィックスアソシエーションメッセージに宣伝されており、そのような各プレフィックスをノードのRIDにバインドします。
Non-MANET hosts may establish connections to MANET routers through on-demand mechanisms such as ARP or IPv6 Neighbor Discovery. Such connections do not constitute a MANET link and therefore are not reported in TBRPF topology updates. Non-MANET hosts are advertised in HOST ASSOCIATION messages, which bind the IP address of each host to the node's RID.
非Manetホストは、ARPやIPv6 Neighbor Discoveryなどのオンデマンドメカニズムを介してMANETルーターへの接続を確立する場合があります。このような接続はMANETリンクを構成するものではないため、TBRPFトポロジの更新では報告されません。非Manetホストは、各ホストのIPアドレスをノードのRIDにバインドするホストアソシエーションメッセージに宣伝されます。
TBRPF packets are communicated using UDP/IP. Port 712 has been assigned by IANA for exclusive use by TBRPF. Implementations in private networks MAY employ alternate data delivery services (i.e., raw IP or local data-link encapsulation). The selection of an alternate data delivery service MUST be consistent among all MANET routers in the private network. In all implementations, the data delivery service MUST provide a checksum facility.
TBRPFパケットは、UDP/IPを使用して通信されます。ポート712は、TBRPFが排他的に使用するためにIANAによって割り当てられています。プライベートネットワークの実装では、代替データ配信サービス（つまり、生のIPまたはローカルデータリンクカプセル化）を採用する場合があります。代替データ配信サービスの選択は、プライベートネットワーク内のすべてのMANETルーターの間で一貫している必要があります。すべての実装において、データ配信サービスはチェックサム機能を提供する必要があります。
The following sections specify the operation of TBRPF over UDP/IP.
次のセクションでは、UDP/IPを介したTBRPFの操作を指定します。
When IPv4 is used, TBRPF nodes obey IPv4 host and router requirements [4][5]. TBRPF packets are sent to the multicast address 224.0.0.2 (All Routers) and thus reach all TBRPF routers within single-hop transmission range of the sender. TBRPF routers MUST NOT forward packets sent to this multicast address.
IPv4を使用すると、TBRPFノードはIPv4ホストとルーターの要件に従います[4] [5]。TBRPFパケットは、マルチキャストアドレス224.0.0.2（すべてのルーター）に送信されるため、送信者のシングルホップ伝送範囲内のすべてのTBRPFルーターに到達します。TBRPFルーターは、このマルチキャストアドレスに送信されたパケットを転送してはなりません。
Since non-negligible packet loss due to link failure, interference, etc. can occur, implementations SHOULD avoid IPv4 fragmentation/ reassembly whenever possible, by splitting large TBRPF protocol packets into multiple smaller packets at the application layer. When fragmentation is unavoidable, senders SHOULD NOT send TBRPF packets that exceed the minimum reassembly buffer size ([4], section 3.3.2) for all receivers in the network.
リンクの障害、干渉などによる交渉不可能なパケット損失が発生する可能性があるため、大規模なTBRPFプロトコルパケットをアプリケーションレイヤーの複数の小さなパケットに分割することにより、可能な限りIPv4断片化/再組み立てを実装する必要があります。断片化が避けられない場合、送信者は、ネットワーク内のすべての受信機の最小再組み立てバッファサイズ（[4]、セクション3.3.2）を超えるTBRPFパケットを送信しないでください。
The specification of TBRPF for IPv6 is the same as for IPv4, except that 32-bit IPv4 addresses are replaced by 128-bit IPv6 addresses. However, to minimize overhead, router IDs remain at 32 bits, similar to OSPF for IPv6 [18].
IPv6用のTBRPFの仕様は、32ビットIPv4アドレスが128ビットIPv6アドレスに置き換えられていることを除いて、IPv4の場合と同じです。ただし、オーバーヘッドを最小限に抑えるために、ルーターIDはIPv6のOSPFと同様に32ビットのままです[18]。
The IANA has assigned port number 712 for TBRPF.
IANAは、TBRPFにポート番号712を割り当てました。
The TBRPF flooding mechanism specified in this document uses the IPv4 multicast address 224.0.1.20, which is currently assigned by IANA for "any private experiment". In the event that this specification is advanced to standards track, a new multicast address assignment would be requested for this purpose.
このドキュメントで指定されているTBRPFフラッディングメカニズムでは、IPv4マルチキャストアドレス224.0.1.20を使用しています。この仕様が標準追跡に進出した場合、この目的のために新しいマルチキャストアドレスの割り当てが要求されます。
Wireless networks are vulnerable to a variety of attacks, including denial-of-service attacks (e.g., flooding and jamming), man-in-the-middle attacks (e.g., interception, insertion, deletion, modification, replaying) and service theft. To counter such attacks, it is important to prevent the spoofing (impersonation) of TBRPF nodes, and to prevent unauthorized nodes from joining the network via neighbor discovery. To achieve this, TBRPF packets can be authenticated using the IP Authentication Header [19][20]. In addition, the Encapsulating Security Payload (ESP) header [21] can be used to provide confidentiality (encryption) of TBRPF packets.
ワイヤレスネットワークは、サービス拒否攻撃（洪水や妨害など）、中間の攻撃（傍受、挿入、削除、修正、再生、リプレイなど）、サービス盗難など、さまざまな攻撃に対して脆弱です。このような攻撃に対抗するには、TBRPFノードのスプーフィング（なりすまし）を防ぎ、不正なノードが近隣発見を介してネットワークに参加するのを防ぐことが重要です。これを達成するために、IP認証ヘッダー[19] [20]を使用してTBRPFパケットを認証できます。さらに、セキュリティペイロード（ESP）ヘッダー[21]を使用して、TBRPFパケットの機密性（暗号化）を提供できます。
The IETF SEcuring Neighbor Discovery (SEND) Working Group analyzes trust models and threats for ad hoc networks [22]. TBRPF can be extended in a straightforward manner to use SEND mechanisms, e.g., [23].
近隣の発見（送信）を保護するIETFは、ワーキンググループを分析し、アドホックネットワークの信頼モデルと脅威を分析します[22]。TBRPFは、送信メカニズムを使用するために簡単な方法で拡張できます[23]。
The authors would like to thank the Army Systems Engineering Office (ASEO) for funding part of this work.
著者は、この作業の一部に資金を提供してくれた陸軍システムエンジニアリングオフィス（ASEO）に感謝したいと思います。
The authors would like to thank several members of the MANET working group for many helpful comments and suggestions, including Thomas Clausen, Philippe Jacquet, and Joe Macker.
著者は、Thomas Clausen、Philippe Jacquet、Joe Mackerなど、多くの有益なコメントや提案について、Manetワーキンググループの数人のメンバーに感謝したいと思います。
The authors would like to thank Bhargav Bellur for major contributions to the original (full-topology) version of TBRPF, Ambatipudi Sastry for his support and advice, and Julie S. Wong for developing a new implementation of TBRPF and suggesting several clarifications to the TBRPF Routing Operation section.
著者は、TBRPFのオリジナル（フルトポロジー）バージョンへの主要な貢献、彼のサポートとアドバイスについてのAmbatipudi Sastry、およびTBRPFの新しい実装を開発し、TBRPFのいくつかの明確化を提案してくれたBhargav Bellurに感謝します。ルーティング操作セクション。
[1] Bradner, S., "Key words 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] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[2] Deering、S。and R. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[3] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[3] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[4] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[4] Braden、R.、ed。、「インターネットホストの要件 - 通信レイヤー」、STD 3、RFC 1122、1989年10月。
[5] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[5] Baker、F.、ed。、「IPバージョン4ルーターの要件」、RFC 1812、1995年6月。
[6] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[6] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月。
[7] Ogier, R., Message in IETF email archive for MANET, ftp://ftp.ietf.org/ietf-mail-archive/manet/2002-02.mail, February 2002.
[7] Ogier、R.、ManetのIETFメールアーカイブのメッセージ、ftp：//ftp.ietf.org/ietf-mail-archive/manet/2002-02.mail、2002年2月。
[8] Ogier, R., "Topology Dissemination Based on Reverse-Path Forwarding (TBRPF): Correctness and Simulation Evaluation", Technical Report, SRI International, October 2003.
[8] Ogier、R。、「リバースパス転送（TBRPF）に基づくトポロジの普及：正確性とシミュレーション評価」、テクニカルレポート、SRI International、2003年10月。
[9] Ogier, R., Message in IETF email archive for MANET, ftp://ftp.ietf.org/ietf-mail-archive/manet/2002-03.mail, March 2002.
[9] Ogier、R.、ManetのIETF電子メールアーカイブのメッセージ、ftp：//ftp.ietf.org/ietf-mail-archive/manet/2002-03.mail、2002年3月。
[10] Ogier, R., "Efficient Routing Protocols for Packet-Radio Networks Based on Tree Sharing", Proc. Sixth IEEE Intl. Workshop on Mobile Multimedia Communications (MOMUC'99), November 1999.
[10] Ogier、R。、「ツリー共有に基づくパケットラジオネットワークの効率的なルーティングプロトコル」、Proc。6番目のIEEE INTL。1999年11月、モバイルマルチメディアコミュニケーション（MOMUC'99）に関するワークショップ。
[11] Bellur, B. and R. Ogier, "A Reliable, Efficient Topology Broadcast Protocol for Dynamic Networks", Proc. IEEE INFOCOM '99, New York", March 1999.
[11] Bellur、B。およびR. Ogier、「動的ネットワークのための信頼できる効率的なトポロジブロードキャストプロトコル」、Proc。IEEE Infocom '99、ニューヨーク」、1999年3月。
[12] Clausen, T. and P. Jacquet, Eds., "Optimized Link State Routing Protocol (OLSR)", RFC 3626, October 2003.
[12] Clausen、T。およびP. Jacquet、eds。、「最適化されたリンク状態ルーティングプロトコル（OLSR）」、RFC 3626、2003年10月。
[13] Bertsekas, D. and R. Gallager, "Data Networks", Prentice-Hall, 1987.
[13] Bertsekas、D。およびR. Gallager、「Data Networks」、Prentice-Hall、1987。
[14] Perkins, C., Belding-Royer, E. and S. Das, "IP Flooding in Ad Hoc Mobile Networks", Work in Progress, November 2001.
[14] Perkins、C.、Belding-Royer、E。and S. Das、「アドホックモバイルネットワークでのIP洪水」、2001年11月、進行中の作業。
[15] Plummer, D., "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware", STD 37, RFC 826, November 1982.
[15] Plummer、D。、「イーサネットアドレス解像度プロトコル：または、ネットワークプロトコルアドレスをイーサネットハードウェア上の送信用のビットイーサネットアドレスに変換する」、STD 37、RFC 826、1982年11月。
[16] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[16] Narten、T.、Nordmark、E。およびW. Simpson、「IPバージョン6（IPv6）の近隣発見」、RFC 2461、1998年12月。
[17] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[17] Perkins、C.、ed。、「IPv4のIPモビリティサポート」、RFC 3344、2002年8月。
[18] Coltun, R., Ferguson, D. and J. Moy, "OSPF for IPv6", RFC 2740, December 1999.
[18] Coltun、R.、Ferguson、D。、およびJ. Moy、「IPv6のOSPF」、RFC 2740、1999年12月。
[19] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[19] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[20] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[20] Kent、S。およびR. Atkinson、「IP Authentication Header」、RFC 2402、1998年11月。
[21] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[21] Kent、S。およびR. Atkinson、「IPカプセル化セキュリティペイロード（ESP）」、RFC 2406、1998年11月。
[22] Nikander, P., "IPv6 Neighbor Discovery Trust Models and Threats", Work in Progress, April 2003.
[22] Nikander、P。、「IPv6 Neighbor Discovery Trustモデルと脅威」、2003年4月、進行中の作業。
[23] Arkko, J., "SEcure Neighbor Discovery (SEND)", Work in Progress, June 2003.
[23] Arkko、J。、「Secure Neighbor Discovery（send）」、2003年6月、進行中の作業。
Authors' Addresses
著者のアドレス
Richard G. Ogier SRI International 333 Ravenswood Ave. Menlo Park, CA 94025 USA
リチャードG.オギエスリインターナショナル333レイヴンズウッドアベニュー。メンロパーク、カリフォルニア94025アメリカ
Phone: +1 650 859-4216
Fax: +1 650 859-4812
EMail: ogier@erg.sri.com
Fred L. Templin Nokia 313 Fairchild Drive Mountain View, CA 94043 USA
フレッドL.テンプリンノキア313フェアチャイルドドライブマウンテンビュー、CA 94043 USA
Phone: +1 650 625 2331
Fax: +1 650 625 2502
EMail: ftemplin@iprg.nokia.com
Mark G. Lewis SRI International 333 Ravenswood Ave. Menlo Park, CA 94025 USA
マークG.ルイススリインターナショナル333レイヴンズウッドアベニュー。メンロパーク、カリフォルニア94025アメリカ
Phone: +1 650 859-4302
Fax: +1 650 859-4812
EMail: lewis@erg.sri.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights.
著作権（c）The Internet Society（2004）。この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となりますが、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。