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)
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.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004). All Rights Reserved.
著作権（C）インターネット協会（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を実行する各ノードは、ダイクストラのアルゴリズムの変形を使用して、トポロジテーブルに格納されている部分的なトポロジー情報に基づいて、ソースツリーを（すべての到達可能なノードへの経路を提供する）を算出します。オーバーヘッド最小にするために、各ノードレポートのみ*ネイバーにそのソースツリーの一部を*。 TBRPFは、そのソースツリーの報告一部の通知をすべてのネイバーを保つために、定期的および差動更新の組み合わせを使用しています。各ノードはまた、高度モバイルネットワークにおいて改善されたロバスト性を提供するために、（完全なトポロジまで）追加のトポロジー情報を報告するオプションを有します。 TBRPFは隣人の状態に*のみ*変更を報告「差分」HELLOメッセージを使用して近隣探索を行います。これは、OSPFなどの他のリンクステートルーティングプロトコルのものよりもはるかに小さいHELLOメッセージをもたらします。
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）に基づくトポロジー普及は、各宛先に沿って最短経路をホップバイホップルーティングを提供するモバイルアドホックネットワーク（MANET）のために設計されたプロアクティブ、リンクステートルーティングプロトコルです。 TBRPFを実行する各ノードは、ダイクストラのアルゴリズムの変形を使用して、トポロジテーブルに格納されている部分的なトポロジー情報に基づいて、ソースツリーを（すべての到達可能なノードへの最短経路を提供する）を算出します。オーバーヘッド最小にするために、各ノードレポートのみ*ネイバーにそのソースツリーの一部を*。
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は隣人の状態に*のみ*変更を報告「差分」HELLOメッセージを使用して近隣探索を行います。これは、[6] OSPFなどの他のリンクステートルーティングプロトコルのものよりもはるかに小さいHELLOメッセージをもたらします。
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].
キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、彼らが表示されたときに、 "NOT SHALL" "ものとし"、、、 "SHOULD"、 "推奨" "NOT SHOULD"、 "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は、各ノードはIPv4のために、そのインターフェイスのいずれかのIPアドレスに典型的に等しくなる（RID）のユニークな32ビットのルータIDによって識別されます。用語「ノード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アドレスで識別されます。 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、j）を送信インターフェイスIは最近受信したパケットは、iがjでどこノードしますノードiはIとノードjが（I、J）がリンクであること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と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.
近隣には、ノードjはノードi私はいくつかのインターフェイス上のノードjを聞くことができるかどうかのノードの隣人であると言われているノード。ノードjはiと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ノードは、典型的には、少なくとも一つの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.
トポロジは、ネットワークのトポロジーは、Vはノードの集合Uであり、Eは、ネットワーク内のリンクの組（U、V）であり、グラフG =（V、E）によって記載されています。
source tree The directed tree (denoted T) computed by each node that provides shortest paths to all other reachable nodes.
他のすべての到達可能なノードへの最短経路を提供する各ノードによって計算されたソースツリー向けツリー（示さ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が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リンク（u、v）はソースツリー内にあるように。
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キロバイト/秒を生成することが見出されました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近隣探索（TND）プロトコルが可能私はすぐ隣を検出するために、各ノードは、双方向リンク（i、j）はノード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の重要な特徴は、それが唯一のリンクの状態の変化* *を報告し、「差分」HELLOメッセージを使用していることです。これは、各HELLOメッセージは、*全て*ネイバーのIDが含まれているOSPFのような他のリンクステートルーティングプロトコルのものよりもはるかに小さいHELLOメッセージをもたらします。その結果、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ホップ）ネイバーであるかを決定する、すなわちただ1つの隣の検知を行います。特に、（ルーティングモジュールによって処理される）、2ホップネイバーを発見しません。結果として、TNDは、他のルーティングプロトコルによって使用することができ、TBRPFは、リンク層により提供例えば、1つ、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パケットで唯一のルータIDが含まOSPFとは異なり、HELLOメッセージで隣接インターフェイスアドレスが含まれています。
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、J）のために、すなわち、Jがそのインターフェイス上で聞いた各隣接インタフェースの状態情報を格納し、各ローカルインターフェースI、のためのネイバーテーブルを維持Iおよび隣接インタフェースJ.それぞれのステータスリンクは、1-WAY、2-WAY、または失われる可能性があります。私はインターフェイスIに送信されたHELLOメッセージの内容を決定し、HELLOメッセージに基づいて更新されるインターフェイスのためのネイバーテーブルは、I（およびおそらくリンク層通知の）インターフェイスで受信しました。
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あたり少なくとも一つのHELLOメッセージ（各インターフェイスに）送信します。隣接REQUEST、隣接REPLY、およびNEIGHBOR LOST：各HELLOメッセージは、（3つのメッセージのサブタイプとしてフォーマットされている）隣接インターフェイスアドレスの三（おそらく空の）リストを含んでいます。各HELLOメッセージは、各送信されたハローでインクリメントされ、現在、HELLOシーケンス番号（HSEQ）を含みます。
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に属し、インタフェースJがJノードに属していることをインタフェースを想定しています。ノードiがリンク（I、J）のステータスを変更すると、それはインタフェースI.上で送信された最もNBR_HOLD_COUNT（典型的には3）連続ハローズにおける内の適切なリスト内の隣接インタフェースアドレスJ（隣接REQUEST / REPLY / LOST）を含みますこれは、ノードjは、インターフェースJ上のこれらのハローズの1を受け取るか、NBR_HOLD_COUNT helloを逃すので、失われたように、リンク（J、I）を宣言することを保証します。ノードは、OSPFと異なり、無期限にハローズの各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.
短命である可能性が高いリンクを確立避けるために（例えば、2）最後のHELLO_ACQUIRE_WINDOWの（例えば、3）ハローズから送信され、ノードiが（インターフェースI上で）少なくともHELLO_ACQUIRE_COUNTを受けなければならない（すなわち、ヒステリシスを使用すること）隣人インタフェースJは、リンク（I、J）を宣言する前に1-WAYされるように。これが起こると、ノードiが隣接インタフェースJ.からI、またはIを含むNEIGHBOR応答メッセージまでインターフェイスIで受信されたインターフェイス上で送信され、その次NBR_HOLD_COUNT HELLOメッセージの各々に隣接REQUESTリストに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.
ノードjがNEIGHBOR要求リストにJが含まれているインタフェースIから送られたハローズの1（インタフェースJに）受信した場合、その後、ノードjは、それがすでに2-WAYでない限り、（2-WAYであることを（J、I）のリンクを宣言します）、およびIインターフェースIにこれらハローズのいずれかを受信するインタフェースJ.上で送信され、その次NBR_HOLD_COUNT HELLOメッセージの各々に隣接応答リストに、ノード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.
ノードiは、私は、そのHSEQ少なくともNBR_HOLD_COUNT helloパケットを逃した、またはノード私はNBR_HOLD_TIME秒以内にインターフェースJから送られたインターフェイスにはハローを受信しない場合、ノードiの変化したことを示している隣人インタフェースJから送信され、インターフェイス上でハローを受信した場合（これらの送信が完了する前に、リンクのステータスを変更しない限り）NEIGHBORでLOSTへのリンク（I、J）の状態（それはすでに失われていない限り）、およびJを含んは私がインターフェイス上で送信され、その次のNBR_HOLD_COUNT HELLOメッセージの各リストをLOST 。ノードJは、インターフェースJ上のこれらのハローズのいずれかを受け取ることになりますいずれかまたはNBR_HOLD_COUNT helloを欠場します。いずれの場合も、ノードjは、リンク（J、I）が失われることを宣言する。このように、両方のノードは、ノードjがまだ私はノードからhelloを聞くことができたとしても、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.
各ノードは、私はリンクの品質を表す隣接インタフェースJ、ローカルインタフェースから各リンク（I、J）ための1つまたは複数のリンクメトリックを維持および更新することができます。このようなリンクメトリックは、ある閾値の上または下に行くのリンクメトリックに基づいて、ネイバーの状態を変更するための追加の条件として使用することができます。 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は、で示さ。各ノードは、計算しダイクストラのアルゴリズムの変形を使用して、そのトポロジーテーブルに格納されている部分的なトポロジー情報に基づいて、そのソースツリーを更新します。 、オーバーヘッド各ノードレポート隣人へのソースツリーの一部だけを最小限に抑えるために。 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.
隣人へのノードのレポートは、「報告サブツリー」と呼ばれ、RTで示されるTの一部。各ノードは、*周期*トポロジー更新（例えば、5秒ごと）、およびレポートの変更より頻繁*差動*更新（例えば、1秒毎）にRTに（付加および欠失）でネイバーにRTを報告します。定期的な更新は、RTの新しい隣人を通知し、そしてそれはすべての更新を受信しない場合でも、各隣人が結局RTを学習していることを確認します。差分更新は、更新によって影響を受けるすべてのノードに各トポロジ更新の高速伝搬を保証します。受信トポロジー更新が転送されていませんが、* *次の差動または定期的なアップデートで報告されるRTに変化をもたらす可能性があります。可能な限り、トポロジー更新が送信される制御パケットの数を最小限にするために、HELLOメッセージと同じパケットに含まれています。 TBRPFは、メッセージの信頼性や、配列決定の配信を必要としない、とのACKまたはNACKを使用していません。
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のリンク（V U）から成ります。ノードのみならiはその隣接の一つはiがjへの最短経路上の次のホップであることを選択することができると判断した場合、ノードiがRNに隣接jを含みます。この決意をするために、ノードiは中間ノードとしてのみ近隣（又はノードI自体）を用いて、各ネイバーから、互いに隣接する、2つのホップまでの最短経路を計算し、（HELLOメッセージに含まれる）、中継優先順位を使用してネクタイを破るルータ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はRNであると隣接jを選択した場合従って、そのノード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] Uに（U、V）は、1つまたは複数の近隣によって報告された、唯一の次ホップP（U）は、リンクの状態に関すると信じられている各リンクについて、ここで使用されています。 （ただし、SPTAの各ノードは、完全なトポロジを報告している。）この技術を用いて、各ノードは最大であると考えられているリンクから成る、トポロジ・グラフTGを維持し、TG内の最短パス木としてTを計算します。 P（u）は、リンクを報告していない隣人に変更した場合の即時再ルーティングを可能にするには、各リンク（u、v）はTGの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を維持し、リンクから成る報告サブグラフRH、（u、v）はuがRNにHであるようなことを報告してもよいです。例えば、Hは、これはすべてのノードによって行われている場合、完全なネットワークトポロジと、各ノードを提供するTGを等しくすることができます。 Hは、また、これは、すべてのノードによって行われる場合には、各別のノードへの2つの互いに素な経路で各ノードを提供する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つ以上のメッセージとパディングオプションを含む本体を含みます。効率的な受信処理を容易にするために、送信者（それぞれ、32分の64/16ビット・ワードのために、すなわち、モジュロ-8/4月2日アドレス）自然境界上でTBRPFパケット内のマルチオクテットワードを整列させるために、必要に応じてパディングオプションを挿入する必要があります。受信機は、自然境界上でアラインか否かをマルチオクテットワードを処理できなければなりません。次のセクションでは、より詳細に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.
バージョン（4ビット）TBRPFバージョン番号。このプロトコルの仕様書バージョン4。
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」を設定し、長さの拡張子を省略することができ、長さフィールドを提供した場合の長さは含まれています。そうでなければ、送信者は「1」= Lを設定し、以前のヘッダーフィールドの直後の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 - ルータID（RID）は、基礎となる配信サービスは、送信者のRIDをコードする場合、送信者は、私が「0」=セットとRIDフィールドを省略するかもしれ含まれていました。そうでなければ、送信者は「1」= Iを設定し、直ちに以前のヘッダフィールドの後にネットワークバイト順にRID 4オクテットを含まなければなりません。 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パケット体は、一つ以上のTBRPFメッセージ（及び必要に応じてパディングオプション）の連結から成ります。 TBRPFパケット本体内のメッセージとパディングのオプションは次の形式を使用してエンコードされています。
+-+-+-+-+-+-+-+-+- - - - -
|OPTIONS| TYPE | VALUE
+-+-+-+-+-+-+-+-+- - - - -
OPTIONS (4 bits) Four option bits that depend on TYPE.
OPTIONS（4ビット）タイプに依存フォーオプションビット。
TYPE (4 bits) Identifier for message type or padding option.
メッセージタイプ又はパディングオプションのTYPE（4ビット）識別子。
VALUE Variable-length field. (Format and length depend on TYPE, as described in the following sections.)
VALUE可変長フィールド。 （次のセクションで説明したようにフォーマットと長さは、タイプに依存します）。
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パケット本体内のどこにでも発生する可能性があります。次の二つのパディングオプションが定義されています。
Pad1 option (TYPE = 0)
パッド1オプション（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.
パッド1オプションはTBRPFパケット本体内にパディングの1つのオクテットを挿入します。 VALUEフィールドが省略されています。パディングの複数のオクテットが必要な場合、（次に説明する）パッドNオプションではなく、複数のパッド1オプションよりも、使用されるべきです。
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.
パッドNオプションはTBRPFパケット本体内にパディングの2つの以上のオクテットを挿入します。 255パディングオクテットの最大合計を得、直後にゼロ値のオクテットの数を指定する253 - VALUEフィールドの最初のオクテットは0の値を含む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.
このセクションでは、各ノードが迅速にローカルインターフェースIと隣接インタフェースJとの間の双方向リンク（I、J）を検出することができ、かつ迅速にそのようなリンクの損失を検出するTBRPF近隣探索（TND）プロトコルを記述する。 TND及びルーティングモジュール間のインタフェースはTNDとの3つの手順LINK_UP（I、J）、LINK_DOWN（I、J）、および発表するTNDによって呼び出される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)
- 隣接REQUEST（TYPE = 2） - 隣接REPLY（TYPE = 3） - NEIGHBOR LOST（TYPE = 4）
Each HELLO subtype has the following format:
各ハローサブタイプの形式は次のとおりです。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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ビット）、HELLOシーケンス番号。
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応答メッセージ、および隣接インターフェイスアドレスのリストが空の場合、最後の二つのメッセージのそれぞれが省略さNEIGHBOR LOSTメッセージの連結です。したがって、HELLOメッセージは、常に、（おそらく空の）ネイバー要求を含みます。
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、Iためネイバーテーブルに、HELLOメッセージは最近インタフェースIによって隣接インタフェースJのエントリを受信されているから、各隣接インタフェースJの状態情報を記憶する隣接テーブル、 、次の変数が含まれています。
nbr_rid(I,J) - The router ID of the node associated with neighbor interface J.
nbr_rid（I、J） - 近隣インタフェース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-WAY。
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） - インタフェースJからさらなるHELLOメッセージが受信されない場合nbr_status（I、J）までの残り時間（秒）の量が失わに変更されなければなりません。 NBR_HOLD_TIMEに設定こんにちはインターフェイスJ.から界面Iで受信されたとき
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） - 最後のHELLOメッセージでHSEQの値は、Jが見逃されてきたハローズの数を決定するために使用されるIインターフェースからインターフェース上で受信しました。
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） - 残り回数Jを含む隣接REQUEST / REPLY / LOSTメッセージインターフェイス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 HELLOメッセージのシーケンス番号のリストをインターフェースJ.からインターフェイス上でIを受け
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） - 小さな値は、より良い品質を示す1〜255の整数、で表されるリンク（I、J）の品質の任意の尺度、。使用されていない場合は1にデフォルト設定。
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.
何こんにちは、私は最後の2 * NBR_HOLD_TIME秒以内にインターフェースJからインターフェイスで受信されていない場合のインタフェースのためのネイバーテーブル内のインタフェースJのエントリは、私が削除されることがあります。 （NEIGHBORがJを含むメッセージが送信されているLOSTながらそれは維持される。）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.
LOSTインターフェイス私はインターフェイスJ.から最近HELLOメッセージの十分な数を受信していません
1-WAY Interface I has received a sufficient number of HELLO messages recently from Interface J, but the link is not 2-WAY.
1-WAYインターフェイス私はインターフェイスJから最近HELLOメッセージの十分な数を受け取ったが、リンクは2-WAYではありません。
2-WAY Interfaces I and J have both received a sufficient number of HELLO messages recently from each other.
2-WAYインターフェイスIおよびJは、両者から最近HELLOメッセージの十分な数を受けています。
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つのHELLOメッセージを送信しなければなりません。ハローメッセージ（例えば、トポロジー変化の迅速な検出のために）このより頻繁に送信されるかもしれません。しかし、HSEQがNBR_HOLD_TIMEより大きくなければならないLOST、（所定のインターフェイス上で送信された）は、2つの連続したHELLOメッセージの間の時間へのリンクの状態を変更HELLOメッセージの受信を停止隣接前に、同じ番号にラップアラウンドする可能性を避けるために/ 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].
衝突をもたらすことができる制御メッセージの同期化を避けるために、ハローメッセージが等間隔で送信されるべきではありません。ジッタが区間[0、MAX_JITTER]からランダムに選択されたジッタ、 - これを達成するために、ノードはHELLO_INTERVALことが連続HELLOメッセージとの間の間隔を選択することができます。
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 REQUESTメッセージを含んでいます。 NEIGHBOR REQUESTメッセージは、1（モジュロ256）ハローが送信されるたびにインクリメントされるシーケンス番号HSEQを含みます。隣人アドレスのリストが空でない、と隣人アドレスのリストが空でない場合NEIGHBORがメッセージを失ったらHELLOメッセージもNEIGHBORのREPLYメッセージを含んでいます。これらの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).
各インタフェースJようnbr_status（I、J）= LOSTとnbr_count（I、J）> 0、1.ネイバーでJは、メッセージ及びデクリメントnbr_count（I、J）をLOST含みます。
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).
各インタフェースJ 2.ようnbr_status（I、J）= 1-WAYとnbr_count（I、J）> 0、NEIGHBOR REQUESTメッセージ及びデクリメントnbr_count（I、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).
各インタフェースJ 3.ようnbr_status（I、J）= 2-WAYとnbr_count（I、J）> 0、NEIGHBOR応答メッセージとデクリメントnbr_count（I、J）で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. 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（モジュロ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がリンクを持つI（J、I）Iが失わへのリンクの状態を設定するインターフェイスする場合。
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:
ノードは、Helloメッセージを受信すると、IPヘッダから送信インターフェースのIPアドレスを取得します。受信したハローのTBRPFパケットヘッダは、RIDオプションが含まれている場合、送信ノードのRIDはTBRPFパケットヘッダから取得されます。それ以外の場合は、送信インタフェースのIPアドレスと同じです。 （iをRID等しいと）ノードiがインターフェイスIにHelloメッセージを受信した場合、シーケンス番号HSEQと中継優先PRIと、インターフェースJ上の（jへRID等しいと）、ノードjによって送信され、ノードiは、以下のステップを実行します。
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.
1.場合、私はnbr_rid（I、J）= J、nbr_status（I、J）とのいずれかを、インタフェースJのエントリを含んで作成されないインターフェイスのためのネイバーテーブル= LOST（一時的に）、nbr_count（I、J）= 0 、および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）は、受信したHELLOメッセージを反映します。 256 - nbr_hseq（I、J）（によるラップアラウンドへ）> HSEQは、（I、J）= nbr_hseq（I、J）nbr_hseqを設定した場合。
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とhello_history（I、J）は、インターフェースJからHELLO_ACQUIRE_COUNTハロー最後HELLO_ACQUIRE_WINDOWのメッセージが受信されたことを示している場合：
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は、隣接要求リスト又は隣接応答リスト、設定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_COUNT。 LINK_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と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。そうでなければ、私は近隣REPLYリストに表示されるインタフェース場合、設定nbr_status（I、J）= 2-WAYとnbr_count（I、J）= 0のコールLINK_UP（I、J）。
5. Else, if nbr_status(I,J) = 2-WAY:
そうでない場合5. nbr_status（I、J）= 2-WAY場合：
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。 NEIGHBORで私が表示されたインターフェイスがリストを失ったら、設定nbr_status（I、J）= LOSTとnbr_count（I、J）が0コールLINK_DOWN（I、J）=。
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は、（I、J）= LOSTとnbr_count（I、J）= NBR_HOLD_COUNTをnbr_statusを設定します。 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。インタフェースあればそうでない場合、私はNEIGHBOR要求リストと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.セット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:
インターフェイスのためのネイバーテーブルのタイマnbr_life（I、J）の満了I、ノード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又は2ウェイセットnbr_status（I、J）が失われ、nbr_count（I、J）= NBR_HOLD_COUNT IF =。 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）は、特定の隣接へのリンクが最大再送回数を試みた後、例えば、失敗したという通知を提供します。そのような通知は、リンク層により提供される場合、私は隣人インタフェース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ウェイセットnbr_status（I、J）が失われ、nbr_count（I、J）= NBR_HOLD_COUNT IF =。 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）、リンクの品質を示す、例えば、信号強度、いくつかの時間間隔にわたって受信されたHelloパケットの数、信頼性、安定性、帯域幅、等の各リンクのための1つ以上のリンクメトリックを維持および更新することができますどちらかNBR_HOLD_COUNTのhelloが失われる場合、または全くハローがNBR_HOLD_TIME秒以内に受信されない場合のノードが失われたように隣人を宣言しなければなりません。しかし、ノードはまた、いくつかの閾値の上または下にあるリンク・メトリックに基づいて失われる隣人を宣言することができます。各ノードは、隣接1-WAY又は2-WAYを宣言する前に、ネイバーから最後HELLO_ACQUIRE_WINDOWのhelloの少なくとも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.
このセクションでは、近隣探索プロトコル、およびその提案されたデフォルト値が使用するパラメータを示します。すべてのノードは、次のパラメータのすべてに同じ値を持つように設定する必要があります。
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):
近隣探索プロトコルによって必要とされる情報に加えて、TBRPFを実行する各ノードは、ネットワーク内の既知の各ノードとリンクのための情報を格納するトポロジテーブルTTを、維持します。ノードは、すなわち、ノードは、Uは、そのRIDあるUノードであり、それらのRIDによって識別されます。以下の情報は、各ノードのノードiにおけるトポロジーテーブルに格納されているUリンク（U、V）：
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） - （u、v）はノードで特にIのソースツリーT、0であれば1に等しいです。前のソースツリーも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は私の報告ノードがそうでなければRNを設定し、0ノードである場合に1に等しいです。以前報告されたノードのセットも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）は私の報告サブツリーRT、および0それ以外のノードです。 RTは、リンクの集合として定義されているので、（u、v）はuがRNであるようにTで、この変数は、明示的に維持する必要はありません。
TG(u,v) - Equal to 1 if (u,v) is in node i's topology graph TG, and 0 otherwise.
TGが（u、v）は - あれば1に等しい（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）を報告しているネイバーのリスト。リンクのセット（U、V）隣人jで報告されたが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） - uは到達できないノード場合はNULLに等しいソースツリーTにおけるノードUの前身であるノード。
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）はuのノードまでのホップ数です。
reported(u,v) - Equal to 1 if link (u,v) in TG is reported by p(u), and 0 otherwise.
報告された（U、V） - リンク（U、V）であれば1に等しいTGには、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）の有効期限。
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）は - リンクの有効期限（u、v）はTGに報告することを（u、v）は= 0このような非報告リンクが再ルーティングの間に一時的に使用することができます。
metric(j,u,v) - The metric for link (u,v) reported by neighbor j.
メトリック（J、U、V） - リンクのメトリックは（U、V）隣人jで報告しました。
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-WAYリンク（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.
コスト（U、V） - メトリックに等しいリンクのコスト（U、V）、（U、V）USE_METRICS = 1の場合、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宛先IPアドレスまたはプレフィックスである形態（rt_dest、rt_next、rt_dist、rt_if_id）のタプルのリストから成る、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.
ルータID、ルータIDを持つホストのIPアドレスを関連付け、「ホストテーブル」、および「ネットワーク・プリフィックス・テーブルとのインターフェイスのIPアドレスを関連付け「インタフェーステーブル」：各ノードは、関連するIPアドレスまたはプレフィックスを記述する3つのテーブルを維持します」、ルータ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はRID = if_rid有するルータに関連付けられたインターフェイスのIPアドレスであるフォーム（if_addr、if_rid、if_expire）のタプルから成り、そしてif_expireタプルの有効期限が切れて除去されなければならない時間です。ノードのインタフェーステーブルは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はRID = h_ridでルータに関連付けられたホストのIPアドレスであるフォーム（h_addr、h_rid、h_expire）のタプルから成り、そして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_rid = RID、及びnet_expireとルータに関連付けられたネットワークプレフィックスを記載net_lengthタプルが期限切れになる時刻である形（net_prefix、net_length、net_rid、net_expire）のタプルから成り削除する必要があります。最後に報告された「古い」コピー：MANETは、一つ以上のゲートウェイ・ルータが各テーブルの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).
メッセージ本体は、n +ノード1つのルータIDリンク（U、V_1）、···、（U、v_n）を表し、U、V_1、...、v_nを含んでいます。 （NRL + NRNL）V_Kの（ないRNに）報告されていない - V_Kの最初のNRLがリーフノードに報告されている、V_Kの次NRNLは、非リーフノード、及び最後のNが報告されています。
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の場合は、1オクテットのメトリックは、最後のルータID、次のリンク（U、V_1）、···、（U、v_n）、のそれぞれのために含まれています。
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ビットは暗黙的削除が使用され、1の場合にのみIMPLICIT_DELETIONなら= 1に設定されなければならないか否かを示します。
The TOPOLOGY UPDATE message has the following three subtypes:
トポロジーUPDATEメッセージは、次の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が）に属していることを報告してFULL更新ルータの報告サブツリーRTを送信し、そしてRTは尾の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.
ADD（TYPE = 6）ADD更新（ADD、nは、NRL、NRNL、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.
（TYPE = 7）（DELETE、nは、NRL、NRNL、U、V_1、...、v_n）は、リンク（U、V_1）、...、（U、v_n）が削除されたことを報告してDELETE更新をDELETE送信ルータの報告サブツリー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に関連付けられているインターフェイス（TYPE = 8）またはホスト（TYPE = 9）のIPアドレスを発信元ノードのルータIDを含み、N。 STフィールドが以下に定義されます。
The NETWORK PREFIX ASSOCIATION message (TYPE = 10) has the following format:
NETWORK PREFIX ASSOCIATIONメッセージ（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.
メッセージ本体は、発信元ノードのルータIDを含み、nは1オクテットのプレフィックス長で指定されたネットワークプレフィックス、それぞれが必要全体オクテットの最小数を使用して、接頭辞直後。オーバーヘッドを最小限にするために、プレフィックス長とプレフィックスは、ワード境界に沿って整列されていません。
The INTERFACE ASSOCIATION, HOST ASSOCIATION, and NETWORK PREFIX ASSOCIATION messages each have the following three subtypes (similar to those for the TOPOLOGY UPDATE message):
INTERFACE ASSOCIATION、親子結合、およびNETWORK PREFIX ASSOCIATIONメッセージはそれぞれ（TOPOLOGY UPDATEメッセージと同様の）次の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秒Update_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（）各インタフェースIについて1は、空のメッセージリストmsg_list（I）を作成します。 2.各インタフェースI、インターフェースIのためのHelloメッセージを生成して（I）をmsg_listに追加します。 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. 11セットold_T = Tとold_RN = RNに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（）は、ソース木Tとトポロジ・グラフTGを更新するために、定期的にトポロジ変化に応じて呼び出されているダイクストラのアルゴリズムの変形です。このアルゴリズムは、2つのリンクコストの罰則の対象に最短経路を計算します。ペナルティNON_REPORT_PENALTYは、リンク（U、V）は、それが現在報告されている場合にのみ、Tに含まれ、可能な限り、そのように現在の親P（U）によって報告されていないリンク（U、V）のコストに追加され親によります。 P（u）の変更は、一時的にリンクを使用する必要があるかもしれないすぐに再ルーティングを可能にするには（u、v）は現在、新しい親によって報告されていないこと。ペナルティNON_TREE_PENALTYは同じコストの複数の経路が所与のノードに存在し、ルータIDを破壊するために使用される場合T.への変更の数を減らすために、T現在ないリンクのコスト（U、V）に添加しますネクタイ。
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（）TT内の各ノードvについて1は、（V）INFINITY、predを（V）= NULL、old_p（V）= P（V）、及びP（V）= NULLを= Dを設定します。
2. Set d(i) = 0, p(i) = i, pred(i) = i.
2.セットD（I）= 0、P（1）= I、predを（I）= I。
3. Set S = {i}. (S is the set of labeled nodes.)
3.集合S = {I}。 （Sは、標識されたノードのセットです。）
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.)
Nの各ノードjに対して4、セット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. TTようにD（U）<INFINITYで標識されていないノードUが存在するものの：5.1。 uが最小D（U）とTTで標識されていないノードとします。 （ヒープを効率的にUを見つけるために使用されるべきである。）5.2。 （uはラベルになります）SにUを追加します。 5.3。 P（u）はold_pに等しくない場合（u）は（親が変更されています）：5.3.1。報告されたセットのテールU、報告された場合には（U、V）= 1（u、v）はTG内の各リンクについては（U、V）= 0と設定nr_expire（U、V）= CURRENT_TIME + PER_UPDATE_INTERVAL。 5.3.2。 5.3.2.1：P（u）は、R（U）（P（u）はuのを報告している）である場合。 tg_expireを設定（U）= rt_expire（P（u）は、uの）。 5.3.2.2。 P（u）はU（uは隣人であるが）=場合は、TGから尾のuと（V、U）をすべてのリンクを削除します。 5.3.2.3。 5.3.2.3.1：RにおけるP（U）（U、V）との各リンク（U、V）のために。追加（u、v）はTGとセットに報告（U、V）= 1. 5.3.2.3.2。メトリックセット（U、V）=メトリック（P（u）は、U、V）。 USE_METRICS = 1、Cを設定した場合（u、v）はメトリック=（U、V）。 5.4。 5.4.1：（u、v）はTGであるように、各ノードvについて。報告された場合には（u、v）は0、設定コスト= Cの（U、V）+ NON_REPORT_PENALTYを=。 5.4.2（これは（U、V）P（U）によって報告されていない場合。不利）。そうでなければ、もしP（U）= U、UはR（v）は、設定コスト= Cの（U、V）+ NON_REPORT_PENALTYではありません。 （これは、uは隣人であり、Vを報告していないのu、v）の場合（ペナルティを課す。）5.4.3。 （u、v）はold_Tではなく、場合P（U）！= U、設定されたコスト=コスト+ NON_TREE_PENALTY。 5.4.4。 IF（D（U）+コスト、u）はより辞書小さい（D（V）、predを（V））、セット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からのすべてのリンクを削除します。 PRED（u）がNULLでないことを私はそのようなよりuが他の各ノードに対して、T.へのリンク（predを（U）、U）を追加
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).
TTの各ノードuの2.（このノード以外の）P（u）がNULLでないように、ここで、ルーティングテーブルにタプル（rt_dest、rt_next、rt_dist、rt_if_id）を追加：rt_dest = U、rt_if_id = local_if （P（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.
インタフェーステーブル内の各タプル（if_addr、if_rid、if_expire）3.は、ルーティングテーブルエントリ（rt_dest、rt_next、rt_dist、rt_if_id）はrt_dest = if_rid、タプルを追加するように存在する場合（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).
ホストテーブル内の各タプル（h_addr、h_rid、h_expire）4.、ルーティングテーブルエントリが存在する場合（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).
rt_dest = net_rid、タプル（net_prefix / net_lengthを追加するように、ネットワーク・プリフィックス・テーブル内の各タプル（net_prefix、net_length、net_rid、net_expire）5.、ルーティングテーブルエントリ（rt_dest、rt_next、rt_dist、rt_if_id）が存在する場合rt_nextルーティングテーブルに、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、v）がTにuが報告されたノードセットRNになるようにセットであると定義されることを想起されたいです。各ノードは、定期的または差動トポロジーの更新を生成する前に、すぐにその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すべてのノードU（U）PREDがNULLでないようにします。このようにして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はその隣接の一つはiがjへの最短経路上の次のホップであることを選択することができると判断した場合、ノードiがRNに隣接jを含みます。この決意をするために、ノードiは中間ノードとしてのみ近隣（又はノードI自体）を使用し、そして関係を破壊する中継優先とルータIDを使用して、各ネイバーから、互いに隣接する、2つのホップまでの最短経路を計算します。リンクメトリックが使用される場合、最短経路は、リンクメトリックに対して計算されます。そうでなければ最小ホップ経路が計算されます。
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でである隣人決定した後、トポロジーテーブル内の各ノード（ノードI以外の）UがあればRNに含まれるとUに次のホップP（u）はRNである場合にのみれます。等価的に、ノードuはRNに含まれている場合にのみuがRNであるいくつかの隣接JをルートとTのサブツリー内にある場合。したがって、報告されたサブツリーRTはRNで隣人に根ざしているTのサブツリーが含まれています。また、RN自体に含まれるノードi;これ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 =空。 （2つのホップのために、ソースsのダイクストラを実行する初期化します。）2.1：Nの各ネイバーのように秒間2.すなわち、その結果Sは自身が報告され、R（S）です。 N + {I}内の各ノードjに対して、設定DIST（j）はINFINITYおよびPAR（J）= NULLを=。 2.2。設定しDIST（S）= 0とパー（S）= sで。 2.3。 N + {I}内の各ノードjの（S、j）はTGであるように：2.3.1。設定しDIST（J）=メトリック（S、j）は、額面（J）= J。 2.3.2。 2.3.2.1：（J、K）はTGであるようなNの各ノードkについて。設定されたコスト=メトリック（J、K）。 2.3.2.2。 （DIST（J）+コスト、nbr_pri（j）は、j）は（DIST（K）、nbr_pri（PAR（K））、PAR（k））を、設定DIST（K）= DIST（J）より辞書小さい場合+コストおよびPAR（K）= J。 2.4。 Nの各隣人jに対して、額面場合RNにJを追加（J）= I。 3.私はRNに追加します。 （ノードiはRNに常にある。）トポロジーテーブル内の各ノードU 4.、P（u）はRNである場合RNにUを加えます。
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ホップ）隣人にのみ送信されるので、これは生存時間フィールドを使用することによって達成することができません。代わりに、トポロジ情報の伝播は、Kの半径に制限することができるK-1離れホップ最大であるノードだけを含むように（すべてのノードに）RNを制限することによりホップ。 D（u）は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.
トポロジーテーブル内の各ノードuのために4、P（u）はRN及びd（U）<= K-1である場合にRNにUを追加は。
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秒、各ノードは、すべてのインターフェイス上で、報告されたサブツリーRTを説明FULLトポロジー更新メッセージ（Tの葉はないRN内の各ノードに対して1つのメッセージ）のセットを生成して送信します。可能な限り、これらのメッセージは、送信制御パケットの数を最小限に抑えるために、単一のパケットに含まれています。
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、n個のリンクを表すためのルータIDが含まれている（U、V_1）、···、（U、v_n）。 n個のヘッドノードV_1は、...、追加的な情報を伝えるため、生成されなければならないメッセージの数を減らすために、3つのリストにv_n分割されています。特に、第1 NRLヘッドノードは、このようにリーフノードuのための別個のトポロジー更新メッセージを生成する必要性を回避するTの葉は、です。同様に、最後のN-（NRL + NRNL）ヘッドノードは、従ってRNから削除されたノードuのための別個のトポロジー更新メッセージを生成する必要性を回避する、RNでありません。
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（）、（ノードiがプロシージャを実行するノードである）に従って生成されます。
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:
（ノードを含むi）はRNの各ノードuのためGenerate_Periodic_Update（）（FULL、N、NRL、NRNL、U、V_1、...、v_n）更新を追加し、Tの葉ではないため（I）のmsg_listします各インタフェース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（指標）ビットが1に設定され、メトリックリンクメトリックは（Uは、V_1）、...、メトリック（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への変更を記述するトポロジUPDATEメッセージのセットを作成した場合。これらのメッセージは、次のように定義された手順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.
Generate_Differential_Update（）RN内の各ノードuの場合：1. uはold_RNでない（uはRNに添加した）とTの葉でない場合、更新を追加する（FULL、N、NRL、NRNL、U、V_1 ,. （A）V_1、...、v_n、NRL、及びNRNLは、定期的な更新のために上記のように定義される：各Iのための（I）をmsg_listする..、v_n）。 （B）USE_METRICS = 1の場合、M（指標）ビットが1に設定され、メトリックリンクメトリックは（Uは、V_1）、...、メトリック（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。 （A）（U、V）old_Tにない、または（b）：V_1は、···、（u、v）はTであり、以下の3つの条件の少なくとも一方が成立するVようなノードであるv_nましょうV old_RNではなく、RNである、または（c）vが葉であるとRNではなくold_RNです。 2.2。 （a）は、NRLとNRNLが定義されている：ノードのこのセットが空でない場合、各インタフェースI、のために（I）msg_listする（NRLが、NRNLは、uは、V_1、...、v_n、ADD、n）の更新を追加します上記のように。 （B）USE_METRICS = 1の場合、M（指標）ビットが1に設定され、メトリックリンクメトリックは（Uは、V_1）、...、メトリック（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は、···、（u、v）はold_TでなくTGであり、いずれかIMPLICIT_DELETION = 0又はpredを（V）RNでない（またはNULLである）ことVようなノードであるv_nましょう。 3.2（IMPLICIT_DELETION = 1とPRED（v）はRNである場合、その後の欠失は、（u、v）は（W v）である。別のリンクのためのADD更新によって暗示されています）。ノードのこのセットが空でない場合、各Iについて（I）msg_listする（uは、V_1、...、v_n、DELETE、n）の更新を追加します
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:
Process_Updates msg_listの各更新について（J、msg_list）1 =（サブタイプ、N、NRL、NRNL、U、V_1、...、v_n）。
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().
1.1. それが存在しない場合はTTでのuのためのエントリを作成します。 1.2。サブタイプ= FULL、Process_Full_Update（J、更新）の場合。 1.3。亜型場合は=、Process_Add_Update（J、更新）を追加します。 1.4。サブタイプは=削除した場合、Process_Delete_Update（J、更新）。 2. TGにないTにおける任意のリンクが存在する場合：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、更新）1. R（U）にJを追加します。 2.設定rt_expire（J、U）= CURRENT_TIME + TOP_HOLD_TIME。各リンク（U、V）S。T. 3. jはRである（U、V）：3.1。 R（U、V）からJを削除します。 3.2。 predは（J、V）= uは、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、更新）。
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).
Process_Add_Update M = 1の場合（J、更新は）、...、N（（U、V_M）更新におけるm番目のリンクである。）1のlet V = V_M。それが存在しない場合は2 TTでVのエントリを作成します。 3. R（U、V）にJを追加します。 4. J = P（U）またはP（U）= NULLの場合：4.1。 TGに（U、V）を追加します。 4.2。 5.1：更新にM（指標）ビットが1である場合に報告組は、（u、v）は1 5. =。メトリック設定（J、U、V）更新におけるm番目のメトリックです。 5.2。もしJ = P（U）またはP（U）= NULL：5.2.1。メトリックセット（U、V）=メトリック（J、U、V）。 5.2.2。 USE_METRICS = 1、Cを設定した場合（u、v）はメトリック=（U、V）。前記更新にD（暗黙削除）ビットが1である場合：6.1。集合W = predは（J、v）です。 6.2。 （！！W = NULLであり、w = u）の場合：6.2.1。 （V、W）rからJを削除します。 6.2.2。もしJ = P（W）、TGから（V、W）を除去します。 predは7.セット（J、V）= U。 （新しい前身を設定します。）8. M場合<= NRL（V = V_M報告葉である）：8.1。設定しleaf_update =（FULL、0、0、0、V）。 8.2。 Process_Full_Update（J、leaf_update）。 9. M> NRL + NRNL（V = V_Mがjで報告されていない）の場合：9.1。 R（V）からJを削除します。 9.2。設定しrt_expire（J、V）= 0 9.3。 S。T. Wの各ノードのためのjは、R（V、W）からJを削除し、（W V）Rです。
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.
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.
Process_Delete_Update M = 1の場合（J、更新は）、...、N（（U、V_M）更新におけるm番目のリンクである。）1のlet V = V_M。 2. R（U、V）からJを削除します。 3. predを場合（J、V）= U、設定PRED（J、V）= NULL。 4. J = P（u）は、削除した場合（U、V）からTG。
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 （U、V）。これは、定期的にソースツリーが更新される直前に呼び出され、次の手順をExpire_Links（）、に従って行われます。
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).
ノード以外の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 AND nr_expireを=（u、v）は<CURRENT_TIME、削除（U、V）からTG。 R（U）内の各ノードjに対して3、もし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から不要なエントリを削除するために定期的に実行されるべきです。それはTGでなくold_Tでない場合、リンクは、（u、v）はTTから除去されるべきです。以下の条件の全てが成立した場合uはTTから除去されるべきであるノード：R（u）は空であるが、R（U、W）は、全ての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を報告することが必要です。しかし、（独立して他のノードの）各ノードは、移動性の高いネットワークで増加ロバスト性を提供するために、例えば、追加のリンクを報告することができます。例えば、ノードは、Tが含まれているTGの任意の部分グラフHを計算することができる、と報告することができるリンク（U、V）HのuがRNであるようで構成さRH「サブグラフを報告しました」。この場合、各周期的更新ではなく、RTのRHを記述し、各差分更新はRHへの変更を記載しています。このオプションを使用する場合は冗長トポロジ情報が報告されている場合、リンクの削除は別のリンクの追加によって暗示することができないので、その後、パラメータIMPLICIT_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.
このセクションでは、近隣探索モジュールは、新たなリンク、リンクの喪失、またはリンクのメトリックの変化を検出した場合に続いている手順を説明します。
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、J）、IがJに隣接発見モジュールを介して発見された場合、以下に定義されるように、手順LINK_UP（I、J）は、実行されます。 jは、インタフェースJに関連した隣接ノードとすると、LINK_UP（I、J）は、N（それがまだない場合は所属）にJを追加好適ローカルインタフェースlocal_if（j）とリンクするように隣人インタフェースnbr_if（j）を更新しますlocal_if（J）からこの最小メトリックであることを（j）のメトリック（i、j）をiからjへのすべてのリンクの中で最小のメトリックがあり、アップデートnbr_ifします。
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。 N. 2.2にJを追加します。 TGに（i、j）を追加します。 2.3。セットの報告（i、j）は= nbr_metricの場合1. 3.（I、J）<メトリック（i、j）は、local_ifセット（J）= I、nbr_if（J）= J、およびメトリック（i、j）は= nbr_metric（I、J）。 4. USE_METRICS = 1、設定されたコスト（i、j）は=メトリック（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隣人インタフェースJへのローカルインタフェースからのリンク（I、J）の損失は、近隣探索モジュールを介して検出された場合、以下に定義されるように、手順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.1：ノードからのリンク（K、L）が存在しない場合2. iがnbr_status（K、L）= 2-WAYとjはノードに。 N. 2.2からJを削除します。 TGから（i、j）を取り外します。 3. jがNである場合：3.1。 （K、L）は私からnbr_metric（K、L）はiからjへのすべてのリンクの中で最小のメトリックであるような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、及びメトリック（I、J）= nbr_metric（K、L）。 3.3。 USE_METRICS = 1、設定されたコスト（i、j）は=メトリック（i、j）の場合は。 5. Update_Source_Tree（）。 6. Update_Routing_Table（）。 7. jがNではなく、失われたリンクは、リンク層の障害通知による場合：7.1。もし（REPORT_FULL_TREE = 0）Update_RN（）。 7.2。そうでなければ、Update_RN_Simple（）。 7.3。空= msg_listを設定します。 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.
近隣探索モジュールを介して隣接インタフェースJ変化へのローカルインタフェースからのリンク（I、J）のメトリックIの場合、以下の手順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）からnbr_metric（K、L）はiからjへのすべてのリンクのうち最小メトリックとなるようにjへのリンクです。 3.セットlocal_if（J）= K、nbr_if（J）= L、及びメトリック（I、J）= nbr_metric（K、L）。 4. USE_METRICS = 1、設定されたコスト（i、j）は=メトリック（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.
このセクションでは、INTERFACE ASSOCIATION、親子結合、およびNETWORK PREFIX ASSOCIATIONメッセージを生成するために使用する手順を説明します。インタフェーステーブル、ホストテーブル、およびネットワークプレフィックステーブル内のアドレスまたはプレフィックスは、それぞれ、隣人毎に周期的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. CURRENT_TIME> next_ia_timeの場合：1.1。 next_ia_time = CURRENT_TIME + IA_INTERVALを設定します。 1.2。 1.2.1：RN内の各ノードuのため。 ADDR_1は、...、addr_nは現在のインタフェーステーブルでRID uのに関連付けられたインターフェイスのIPアドレスとします。 1.2.2。このリストが空でない場合は、各I.のインタフェースASSOCIATIONメッセージ（FULL、N、U、ADDR_1、...、addr_n）（I）msg_listするを追加
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）ADDR_1、...、addr_nは内RID Uに関連付けられたインターフェイスのIPアドレスは、それぞれI、のために（I）msg_listに現在のインタフェーステーブルではなく、古いインタフェーステーブルインチ2.2。 ADDR_1、...、addr_nはでRID Uに関連付けられたインターフェースIPアドレスである各Iについてmsg_listするインターフェイスアソシエーションメッセージ（DELETE、N、U、ADDR_1、...、addr_n）（I）を追加古いインタフェーステーブルではなく、現在のインタフェーステーブルインチ
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. CURRENT_TIME> next_ha_timeの場合：1.1。 next_ha_time = CURRENT_TIME + HA_INTERVALを設定します。 1.2。 1.2.1：RN内の各ノードuのため。 ADDR_1は、...、addr_nは、現在のホストテーブルでRID uのに関連付けられているホストのIPアドレスとします。 1.2.2。このリストが空でない場合は、各I.のホストASSOCIATIONメッセージ（FULL、N、U、ADDR_1、...、addr_n）（I）msg_listするを追加
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）ADDR_1、...、addr_nは中RIDのuに関連付けられているホストのIPアドレスはそれぞれI、のために（I）msg_listへ現在のホストテーブルではなく、古いホストテーブルインチ2.2。 ADDR_1、...、addr_nがでRIDのuに関連付けられているホストのIPアドレスである各I、についてmsg_listする親子結合メッセージ（DELETE、N、U、ADDR_1、...、addr_n）（I）を追加古いホストテーブルではなく、現在のホストテーブルインチ
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. CURRENT_TIME> next_npa_timeの場合：1.1。 next_npa_time = CURRENT_TIME + NPA_INTERVALを設定します。 1.2。 1.2.1：RN内の各ノードuのため。 length_1、prefix_1、...、length_nは、prefix_n現在のネットワークプレフィックステーブルのRIDのuに関連するネットワークプレフィックス長とプレフィックスとします。 1.2.2。このリストが空でない場合は、各Iについて（I）msg_listする（uは、length_1、prefix_1、...、length_n、prefix_n、FULL、n）のNETWORK PREFIX ASSOCIATIONメッセージを追加
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。 prefix_1、...、prefix_nはでRID Uに関連付けられているネットワークプレフィックスそれぞれI、のために（I）をmsg_listする（ADD、N、U、prefix_1、...、prefix_n）NETWORK PREFIX ASSOCIATIONメッセージを追加現在の接頭辞テーブルではなく、古いプレフィックステーブルインチ
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. prefix_1、...、prefix_nは内RID Uに関連付けられているネットワークプレフィックスは、それぞれI、のために（I）msg_listする（uはprefix_1、...、prefix_n、DELETE、N）NETWORK PREFIX ASSOCIATIONメッセージを追加古いプレフィックステーブルではなく、現在の接頭辞テーブルインチ
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.
インターフェイスアソシエーション、親子結合、又はNETWORK PREFIX ASSOCIATIONメッセージがノード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の各メッセージ（サブタイプ、N、U、ADDR_1、...、addr_n）についてProcess_Interface_Association_Messages（J、msg_list）J = P（u）のように：1.サブタイプ= FULLは、からif_rid = Uを持つすべてのエントリを削除する場合インタフェーステーブル。 ADD 2サブタイプ= FULLまたは場合は、M = 1、...、nは、インタフェーステーブルにタプル（if_addr、if_rid、if_expire）を追加ここでif_addr = addr_m、if_rid = U、if_expire = CURRENT_TIME + IA_HOLD_TIME。 3.サブタイプが= DELETE場合、M = 1、...、nは、インタフェーステーブル、if_addr = addr_mとif_rid = Uからタプルを（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.
msg_listの各メッセージ（サブタイプ、N、U、ADDR_1、...、addr_n）についてProcess_Host_Association_Messages（J、msg_list）J = P（u）のように：1.サブタイプ= FULLは、からh_rid = Uを持つすべてのエントリを削除する場合ホストテーブル。 ADD 2サブタイプ= FULLまたは場合は、M = 1、...、N、ホストテーブルにタプルを（h_addr、h_rid、h_expire）を追加ここでh_addr = addr_m、h_rid = U、h_expire = CURRENT_TIME + HA_HOLD_TIME。 3.サブタイプが= DELETE場合、M = 1、...、N、ホストテーブル、h_addr = addr_mとh_rid = Uからタプル（h_addr、h_rid、h_expire）を除去します。
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.
msg_listの各メッセージ（サブタイプ、N、U、length_1、prefix_1、...、length_n、prefix_n）についてProcess_Network_Prefix_Association_Messages（J、msg_list）J = P（u）のように：1.サブタイプ= FULLは、ですべてのエントリを削除する場合net_rid = uのプレフィックステーブルから。 ADD 2サブタイプ= FULLまたは場合は、M = 1、...、N、ネットワーク・プリフィックス・テーブルにタプル（net_prefix、net_length、net_rid、net_expire）を追加ここでnet_prefix = prefix_m、net_length = length_m、net_rid = U、net_expire = CURRENT_TIME + NPA_HOLD_TIME。 3.サブタイプが= DELETE場合、M = 1、...、N、ネットワーク・プリフィックス・テーブルからタプル（net_prefix、net_length、net_rid、net_expire）を除去ここnet_prefix = prefix_m、net_length = length_m、及びnet_rid = U 。
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().
ゼロに等しい中継優先度を持つノードは、非中継ノードと呼ばれ、他のノードから受信される（任意の型の）パケットを転送しません。非中継ノードは、生成または任意のトポロジー更新メッセージを送信しないことにより簡単に実現されます。非中継ノードは、自身に関連付けられている（関連メッセージで）アドレスまたはプレフィックスを報告するが、他のノードに関連付けられていないものもよいです。 helloメッセージは、隣接ノードとのリンクを確立するために送信する必要があります。以下の手順は、非中継ノードでは省略することができる。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の送信元IPアドレス、IP識別情報、およびIPヘッダ[14]から得られたフラグメントオフセット値で構成されたフラッディングパケット識別子（FPI）のために、含まれています。
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]。次のセクションでは、アドホックネットワークにおける上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データリンク層を仮定する（すなわち、互いの動作の通信範囲内のノードのペア）。私たちは、さらにMANET内のノードに属する各インタフェースはMANETの範囲内で一意であるユニキャストデータリンク層アドレスが割り当てられていることを前提としています。こうした一意性が厳密に保証されていないものの、一意性の仮定は、特定のリンク層上のインターネット・プロトコルを展開するための現在の慣行と一致しています。重複したリンク層アドレスの検出とdeconflictionための方法は、このドキュメントの範囲を超えています。
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.
アドホックネットワークにおけるルータは、とMANETトポロジを計算する際にネットワーク層アドレスを使用し、非ルーティング・ノードの集合として形成されています。我々は、各ノードは少なくとも一つのデータリンク層インターフェース（上記）とを有していることを前提とし、このような各インタフェースはMANET内で一意のネットワーク層アドレスが割り当てられていること。 （ネットワーク層アドレスの割り当てのための方法およびアドレスの重複検出は、この文書の範囲を超えています。）我々はさらにノードとして機能するか否かを、各ノードはTBRPFプロトコルメッセージで使用するために（RID）固有のルータIDを選択することを前提とMANETルータ。最後に、私たちは、それぞれの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近隣探索[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に、このような各アドレスをバインドINTERFACE ASSOCIATIONメッセージにアドバタイズされます。
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に、このような各プレフィックスをバインドNETWORK PREFIX ASSOCIATIONメッセージでアドバタイズされます。
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近隣探索などのメカニズムを介してルータに非MANETホストは接続を確立することができます。このような接続は、MANETリンクを構成するものではありませんので、TBRPFトポロジーアップデートで報告されていません。非MANETホストは、ノードのRIDに各ホストのIPアドレスをバインドHOST協会メッセージ、でアドバタイズされています。
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氾濫メカニズムは現在「プライベート実験」のためにIANAによって割り当てられた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.
無線ネットワーク（例えば、傍受、挿入、削除、修正、再生）及びサービス窃盗、man-in-the-middle攻撃、サービス拒否攻撃（例えば、洪水やジャミング）を含む、さまざまな攻撃に対して脆弱です。このような攻撃に対抗するために、TBRPFノードのスプーフィング（なりすまし）を防止するために、および近隣探索を介してネットワークに参加する不正ノードを防止することが重要です。これを達成するために、TBRPFパケットはIP認証ヘッダ[19] [20]を使用して認証することができます。加えて、カプセル化セキュリティペイロード（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確保近隣探索（SEND）ワーキンググループは、[22]アドホックネットワークのための信頼モデルと脅威を分析します。 TBRPFは、[23]、例えば、SENDメカニズムを使用する簡単な方法で拡張することができます。
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.
作者はトーマス・クラウゼン、フィリップジャケ、ジョー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の新しい実装を開発し、TBRPFにいくつかの明確化を示唆するために彼のサポートやアドバイスをTBRPFのオリジナル（フルトポロジ）バージョン、Ambatipudi Sastryへの主要な貢献のためBhargav Bellur、とジュリーS.ウォンに感謝したいと思いますルーティング操作の項。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[2]デアリング、S.とR. Hindenと "インターネットプロトコル、バージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[3] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[3]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[4] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[4]ブレーデン、R.、エド、 "インターネットホストのための要件 - 通信層"。、STD 3、RFC 1122、1989年10月。
[5] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[5]ベイカー、F.、エド。、RFC 1812、1995年6月 "IPバージョン4つのルータのための要件"。
[6] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[6]モイ、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]オジェ、R.、ftp://ftp.ietf.org/ietf-mail-archive/manet/2002-02.mail MANET、2002年2月のためのIETFのメールアーカイブ内のメッセージを。
[8] Ogier, R., "Topology Dissemination Based on Reverse-Path Forwarding (TBRPF): Correctness and Simulation Evaluation", Technical Report, SRI International, October 2003.
[8]オジェ、R.、「トポロジリバースパス転送（TBRPF）に基づいて普及：精度とシミュレーション評価」、テクニカルレポート、SRIインターナショナル、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]オジェ、R.、ftp://ftp.ietf.org/ietf-mail-archive/manet/2002-03.mail MANET、2002年3月のためのIETFのメールアーカイブ内のメッセージを。
[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]オジェ、R.、PROC「ツリーの共有に基づくパケット無線ネットワークの効率的なルーティングプロトコル」。第六IEEE国際空港。モバイルマルチメディア通信（MOMUC'99）、1999年11月のワークショップ。
[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.オジェ、 "動的ネットワークの信頼性、効率的なトポロジブロードキャストプロトコル"、PROC。 IEEE INFOCOM '99、ニューヨーク」、1999年3月。
[12] Clausen, T. and P. Jacquet, Eds., "Optimized Link State Routing Protocol (OLSR)", RFC 3626, October 2003.
[12]クラウゼン、T.およびP.ジャケ、編、 "最適化されたリンクステートルーティングプロトコル（OLSR）"、RFC 3626、2003年10月。
[13] Bertsekas, D. and R. Gallager, "Data Networks", Prentice-Hall, 1987.
[13] Bertsekas、D.およびR. Gallagerの、 "データネットワーク"、プレンティス・ホール、1987。
[14] Perkins, C., Belding-Royer, E. and S. Das, "IP Flooding in Ad Hoc Mobile Networks", Work in Progress, November 2001.
[14]パーキンス、C.、ベルディング・ロイヤー、E.およびS.ダス、「アドホックモバイルネットワークにおける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]プラマー、D.、「イーサネットアドレス解決プロトコル：またはイーサネットハードウェア上での送信のためにイーサネット（登録商標）アドレスを48ビットに、ネットワーク・プロトコル・アドレス変換」、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.シンプソン、 "IPバージョン6のための近隣探索（IPv6）の"、RFC 2461、1998年12月。
[17] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[17]パーキンス、C.、エド。、 "IPv4のIPモビリティサポート"、RFC 3344、2002年8月。
[18] Coltun, R., Ferguson, D. and J. Moy, "OSPF for IPv6", RFC 2740, December 1999.
[18] Coltun、R.、ファーガソン、D.およびJ.モイ、 "IPv6のためのOSPF"、RFC 2740、1999年12月。
[19] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[19]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[20] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[20]ケント、S.とR.アトキンソン、 "IP認証ヘッダ"、RFC 2402、1998年11月。
[21] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[21]ケント、S.とR.アトキンソン、 "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の近隣探索信頼モデルと脅威"、進歩、2003年4月の作業。
[23] Arkko, J., "SEcure Neighbor Discovery (SEND)", Work in Progress, June 2003.
[23] Arkko、J.は、進歩、2003年6月に、ワークを "セキュア近隣探索は、（SEND）"。
Authors' Addresses
著者のアドレス
Richard G. Ogier SRI International 333 Ravenswood Ave. Menlo Park, CA 94025 USA
リチャード・G・オジェSRIインターナショナル333レーヴンズウッドアベニュー。メンロパーク、CA 94025 USA
Phone: +1 650 859-4216 Fax: +1 650 859-4812 EMail: ogier@erg.sri.com
電話：+1 650 859-4216ファックス：+1 650 859-4812 Eメール：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
電話：+1 650 625 2331ファックス：+1 650 625 2502 Eメール：ftemplin@iprg.nokia.com
Mark G. Lewis SRI International 333 Ravenswood Ave. Menlo Park, CA 94025 USA
マーク・G.ルイスSRIインターナショナル333レーヴンズウッドアベニュー。メンロパーク、CA 94025 USA
Phone: +1 650 859-4302 Fax: +1 650 859-4812 EMail: lewis@erg.sri.com
電話：+1 650 859-4302ファックス：+1 650 859-4812 Eメール：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）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。