[要約] OLSRは、モバイルアドホックネットワーク（MANET）での効率的な経路選択を提供するプロトコルです。RFC 3626は、OLSRの仕様と実装に関する情報を提供しています。OLSRの目的は、ノード間の通信を最適化し、ネットワークの信頼性とパフォーマンスを向上させることです。
Network Working Group T. Clausen, Ed.
Request for Comments: 3626 P. Jacquet, Ed.
Category: Experimental Project Hipercom, INRIA
October 2003
Optimized Link State Routing Protocol (OLSR)
最適化されたリンク状態ルーティングプロトコル（OLSR）
Status of this Memo
本文書の位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
Abstract
概要
This document describes the Optimized Link State Routing (OLSR) protocol for mobile ad hoc networks. The protocol is an optimization of the classical link state algorithm tailored to the requirements of a mobile wireless LAN. The key concept used in the protocol is that of multipoint relays (MPRs). MPRs are selected nodes which forward broadcast messages during the flooding process. This technique substantially reduces the message overhead as compared to a classical flooding mechanism, where every node retransmits each message when it receives the first copy of the message. In OLSR, link state information is generated only by nodes elected as MPRs. Thus, a second optimization is achieved by minimizing the number of control messages flooded in the network. As a third optimization, an MPR node may chose to report only links between itself and its MPR selectors. Hence, as contrary to the classic link state algorithm, partial link state information is distributed in the network. This information is then used for route calculation. OLSR provides optimal routes (in terms of number of hops). The protocol is particularly suitable for large and dense networks as the technique of MPRs works well in this context.
このドキュメントでは、モバイルアドホックネットワーク用の最適化されたリンク状態ルーティング（OLSR）プロトコルについて説明します。このプロトコルは、モバイルワイヤレスLANの要件に合わせたクラシックリンク状態アルゴリズムの最適化です。プロトコルで使用される重要な概念は、マルチポイントリレー（MPRS）の概念です。MPRは、洪水プロセス中にブロードキャストメッセージを転送する選択されたノードです。この手法は、すべてのノードがメッセージの最初のコピーを受信したときに各メッセージを再送信する古典的な洪水メカニズムと比較して、メッセージのオーバーヘッドを大幅に削減します。OLSRでは、リンク状態情報は、MPRSとして選出されたノードによってのみ生成されます。したがって、ネットワークにあふれたコントロールメッセージの数を最小化することにより、2番目の最適化が達成されます。3番目の最適化として、MPRノードは、それ自体とそのMPRセレクター間のリンクのみを報告することを選択できます。したがって、古典的なリンク状態アルゴリズムとは反対に、部分リンク状態情報がネットワークに分散されます。この情報は、ルート計算に使用されます。OLSRは最適なルートを提供します（ホップ数の観点から）。このコンテキストでは、MPRSの手法がうまく機能するため、プロトコルは大規模で密なネットワークに特に適しています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. OLSR Terminology. . . . . . . . . . . . . . . . . . . . 5
1.2. Applicability. . . . . . . . . . . . . . . . . . . . . . 7
1.3. Protocol Overview . . . . . . . . . . . . . . . . . . . 8
1.4. Multipoint Relays . . . . . . . . . . . . . . . . . . . 9
2. Protocol Functioning . . . . . . . . . . . . . . . . . . . . 9
2.1. Core Functioning . . . . . . . . . . . . . . . . . . . 10
2.2. Auxiliary Functioning . . . . . . . . . . . . . . . . . 12
3. Packet Format and Forwarding . . . . . . . . . . . . . . . . 13
3.1. Protocol and Port Number. . . . . . . . . . . . . . . . 13
3.2. Main Address . . . . . . . . . . . . . . . . . . . . . 13
3.3. Packet Format . . . . . . . . . . . . . . . . . . . . . 14
3.3.1. Packet Header . . . . . . . . . . . . . . . . . . 14
3.3.2. Message Header . . . . . . . . . . . . . . . . . 15
3.4. Packet Processing and Message Flooding . . . . . . . . . 16
3.4.1. Default Forwarding Algorithm. . . . . . . . . . . 18
3.4.2. Considerations on Processing and Forwarding . . . 20
3.5. Message Emission and Jitter. . . . . . . . . . . . . . . 21
4. Information Repositories . . . . . . . . . . . . . . . . . . 22
4.1. Multiple Interface Association Information Base . . . . 22
4.2. Link sensing: Local Link Information Base. . . . . . . . 22
4.2.1. Link Set. . . . . . . . . . . . . . . . . . . . . 22
4.3. Neighbor Detection: Neighborhood Information Base. . . . 23
4.3.1. Neighbor Set. . . . . . . . . . . . . . . . . . . 23
4.3.2. 2-hop Neighbor Set. . . . . . . . . . . . . . . . 23
4.3.3. MPR Set . . . . . . . . . . . . . . . . . . . . . 23
4.3.4. MPR Selector Set. . . . . . . . . . . . . . . . . 23
4.4. Topology Information Base . . . . . . . . . . . . . . . 24
5. Main Addresses and Multiple Interfaces . . . . . . . . . . . 24
5.1. MID Message Format . . . . . . . . . . . . . . . . . . . 25
5.2. MID Message Generation . . . . . . . . . . . . . . . . . 25
5.3. MID Message Forwarding . . . . . . . . . . . . . . . . . 26
5.4. MID Message Processing . . . . . . . . . . . . . . . . . 26
5.5. Resolving a Main Address from an Interface Address . . . 27
6. HELLO Message Format and Generation . . . . . . . . . . . . . 27
6.1. HELLO Message Format . . . . . . . . . . . . . . . . . . 27
6.1.1. Link Code as Link Type and Neighbor Type. . . . . 29
6.2. HELLO Message Generation . . . . . . . . . . . . . . . . 30
6.3. HELLO Message Forwarding . . . . . . . . . . . . . . . . 33
6.4. HELLO Message Processing . . . . . . . . . . . . . . . . 33
7. Link Sensing . . . . . . . . . . . . . . . . . . . . . . . . 33
7.1. Populating the Link Set . . . . . . . . . . . . . . . . 33
7.1.1. HELLO Message Processing . . . . . . . . . . . . 34
8. Neighbor Detection . . . . . . . . . . . . . . . . . . . . . 35
8.1. Populating the Neighbor Set . . . . . . . . . . . . . . . 35
8.1.1. HELLO Message Processing . . . . . . . . . . . . 37
8.2. Populating the 2-hop Neighbor Set. . . . . . . . . . . . 37
8.2.1. HELLO Message Processing. . . . . . . . . . . . . 37
8.3. Populating the MPR set . . . . . . . . . . . . . . . . . 38
8.3.1. MPR Computation . . . . . . . . . . . . . . . . . 39
8.4. Populating the MPR Selector Set. . . . . . . . . . . . . 41
8.4.1. HELLO Message Processing. . . . . . . . . . . . . 41
8.5. Neighborhood and 2-hop Neighborhood Changes. . . . . . . 42
9. Topology Discovery . . . . . . . . . . . . . . . . . . . . . 43
9.1. TC Message Format. . . . . . . . . . . . . . . . . . . . 43
9.2. Advertised Neighbor Set. . . . . . . . . . . . . . . . . 44
9.3. TC Message Generation. . . . . . . . . . . . . . . . . . 45
9.4. TC Message Forwarding. . . . . . . . . . . . . . . . . . 45
9.5. TC Message Processing. . . . . . . . . . . . . . . . . . 45
10. Routing Table Calculation . . . . . . . . . . . . . . . . . . 47
11. Node Configuration. . . . . . . . . . . . . . . . . . . . . . 50
11.1. Address Assignment. . . . . . . . . . . . . . . . . . . 50
11.2. Routing Configuration . . . . . . . . . . . . . . . . . 51
11.3. Data Packet Forwarding. . . . . . . . . . . . . . . . . 51
12. Non OLSR Interfaces . . . . . . . . . . . . . . . . . . . . . 51
12.1. HNA Message Format. . . . . . . . . . . . . . . . . . . 52
12.2. Host and Network Association Information Base . . . . . 52
12.3. HNA Message Generation. . . . . . . . . . . . . . . . . 53
12.4. HNA Message Forwarding. . . . . . . . . . . . . . . . . 53
12.5. HNA Message Processing. . . . . . . . . . . . . . . . . 53
12.6. Routing Table Calculation . . . . . . . . . . . . . . . 54
12.7. Interoperability Considerations . . . . . . . . . . . . 55
13. Link Layer Notification . . . . . . . . . . . . . . . . . . . 55
13.1. Interoperability Considerations . . . . . . . . . . . . 56
14. Link Hysteresis . . . . . . . . . . . . . . . . . . . . . . . 56
14.1. Local Link Set . . . . . . . . . . . . . . . . . . . . 56
14.2. Hello Message Generation . . . . . . . . . . . . . . . 57
14.3. Hysteresis Strategy . . . . . . . . . . . . . . . . . . 57
14.4. Interoperability Considerations . . . . . . . . . . . . 59
15. Redundant Topology Information. . . . . . . . . . . . . . . . 59
15.1. TC_REDUNDANCY Parameter . . . . . . . . . . . . . . . . 60
15.2. Interoperability Considerations . . . . . . . . . . . . 60
16. MPR Redundancy. . . . . . . . . . . . . . . . . . . . . . . . 60
16.1. MPR_COVERAGE Parameter. . . . . . . . . . . . . . . . . 61
16.2. MPR Computation . . . . . . . . . . . . . . . . . . . . 61
16.3. Interoperability Considerations . . . . . . . . . . . . 62
17. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . . 63
18. Proposed Values for Constants . . . . . . . . . . . . . . . . 63
18.1. Setting emission interval and holding times . . . . . . 63
18.2. Emission Interval . . . . . . . . . . . . . . . . . . . 64
18.3. Holding time . . . . . . . . . . . . . . . . . . . . . 64
18.4. Message Types . . . . . . . . . . . . . . . . . . . . . 65
18.5. Link Types. . . . . . . . . . . . . . . . . . . . . . . 65
18.6. Neighbor Types . . . . . . . . . . . . . . . . . . . . 65
18.7. Link Hysteresis . . . . . . . . . . . . . . . . . . . . 66
18.8. Willingness . . . . . . . . . . . . . . . . . . . . . . 66
18.9. Misc. Constants . . . . . . . . . . . . . . . . . . . . 67
19. Sequence Numbers. . . . . . . . . . . . . . . . . . . . . . . 67
20. Security Considerations . . . . . . . . . . . . . . . . . . . 67
20.1. Confidentiality . . . . . . . . . . . . . . . . . . . . 67
20.2. Integrity . . . . . . . . . . . . . . . . . . . . . . . 68
20.3. Interaction with External Routing Domains . . . . . . . 69
20.4. Node Identity . . . . . . . . . . . . . . . . . . . . . 70
21. Flow and congestion control . . . . . . . . . . . . . . . . . 70
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 70
23. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 71
24. Contributors. . . . . . . . . . . . . . . . . . . . . . . . . 71
25. References. . . . . . . . . . . . . . . . . . . . . . . . . . 73
26. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 74
27. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 75
The Optimized Link State Routing Protocol (OLSR) is developed for mobile ad hoc networks. It operates as a table driven, proactive protocol, i.e., exchanges topology information with other nodes of the network regularly. Each node selects a set of its neighbor nodes as "multipoint relays" (MPR). In OLSR, only nodes, selected as such MPRs, are responsible for forwarding control traffic, intended for diffusion into the entire network. MPRs provide an efficient mechanism for flooding control traffic by reducing the number of transmissions required.
最適化されたリンク状態ルーティングプロトコル（OLSR）は、モバイルアドホックネットワーク向けに開発されています。テーブル駆動型のプロアクティブなプロトコルとして動作します。つまり、ネットワークの他のノードと定期的にトポロジ情報を交換します。各ノードは、近隣ノードのセットを「マルチポイントリレー」（MPR）として選択します。OLSRでは、そのようなMPRとして選択されたノードのみが、ネットワーク全体への拡散を目的とした制御トラフィックを転送する責任があります。MPRは、必要なトランスミッションの数を減らすことにより、洪水制御トラフィックの効率的なメカニズムを提供します。
Nodes, selected as MPRs, also have a special responsibility when declaring link state information in the network. Indeed, the only requirement for OLSR to provide shortest path routes to all destinations is that MPR nodes declare link-state information for their MPR selectors. Additional available link-state information may be utilized, e.g., for redundancy.
MPRSとして選択されたノードは、ネットワーク内のリンク状態情報を宣言する際に特別な責任もあります。実際、OLSRがすべての目的地に最短のパスルートを提供するための唯一の要件は、MPRノードがMPRセレクターのリンク状態情報を宣言することです。追加の利用可能なリンク状態情報は、例えば冗長性のために利用される場合があります。
Nodes which have been selected as multipoint relays by some neighbor node(s) announce this information periodically in their control messages. Thereby a node announces to the network, that it has reachability to the nodes which have selected it as an MPR. In route calculation, the MPRs are used to form the route from a given node to any destination in the network. Furthermore, the protocol uses the MPRs to facilitate efficient flooding of control messages in the network.
一部の隣接ノードによってマルチポイントリレーとして選択されたノードは、制御メッセージで定期的にこの情報を発表します。これにより、ノードがネットワークに発表され、MPRとして選択したノードに到達可能性があります。ルート計算では、MPRSを使用して、特定のノードからネットワーク内の任意の宛先までのルートを形成します。さらに、プロトコルはMPRSを使用して、ネットワーク内の制御メッセージの効率的な洪水を促進します。
A node selects MPRs from among its one hop neighbors with "symmetric", i.e., bi-directional, linkages. Therefore, selecting the route through MPRs automatically avoids the problems associated with data packet transfer over uni-directional links (such as the problem of not getting link-layer acknowledgments for data packets at each hop, for link-layers employing this technique for unicast traffic).
ノードは、「対称」、つまり双方向のリンケージを持つ1つのホップネイバーの中からMPRを選択します。したがって、MPRSを介したルートを選択すると、一方向のリンクを介したデータパケット転送に関連する問題が自動的に回避されます（各ホップでデータパケットのリンクレイヤー謝辞を取得しないという問題、ユニキャストトラフィックのこの手法を使用するリンク層の場合）。
OLSR is developed to work independently from other protocols. Likewise, OLSR makes no assumptions about the underlying link-layer.
OLSRは、他のプロトコルから独立して作業するように開発されています。同様に、OLSRは基礎となるリンク層について仮定しません。
OLSR inherits the concept of forwarding and relaying from HIPERLAN (a MAC layer protocol) which is standardized by ETSI [3]. The protocol is developed in the IPANEMA project (part of the Euclid program) and in the PRIMA project (part of the RNRT program).
OLSRは、ETSI [3]によって標準化されたHiperlan（MACレイヤープロトコル）から転送と中継の概念を継承しています。このプロトコルは、IPANEMAプロジェクト（ユークリッドプログラムの一部）およびPRIMAプロジェクト（RNRTプログラムの一部）で開発されています。
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [5].
キーワードは「必要」、「必要」、「必須」、「shall」、「shall "、" sulld "、" nove "、" becommended "、" "、" optional "は、RFC2119 [5]に記載されているように解釈されます。
Additionally, this document uses the following terminology:
さらに、このドキュメントでは、次の用語を使用しています。
node
ノード節点節
A MANET router which implements the Optimized Link State Routing protocol as specified in this document.
このドキュメントで指定されているように、最適化されたリンク状態ルーティングプロトコルを実装するMANETルーター。
OLSR interface
OLSRインターフェイス
A network device participating in a MANET running OLSR. A node may have several OLSR interfaces, each interface assigned an unique IP address.
OLSRを実行しているマネに参加するネットワークデバイス。ノードにはいくつかのOLSRインターフェイスがあり、各インターフェイスに一意のIPアドレスが割り当てられている場合があります。
non OLSR interface
非OLSRインターフェイス
A network device, not participating in a MANET running OLSR. A node may have several non OLSR interfaces (wireless and/or wired). Routing information from these interfaces MAY be injected into the OLSR routing domain.
OLSRを実行しているマネに参加していないネットワークデバイス。ノードには、いくつかの非OLSRインターフェイス（ワイヤレスおよび/または有線）がある場合があります。これらのインターフェイスからのルーティング情報は、OLSRルーティングドメインに注入される場合があります。
single OLSR interface node
単一のOLSRインターフェイスノード
A node which has a single OLSR interface, participating in an OLSR routing domain.
OLSRルーティングドメインに参加した単一のOLSRインターフェイスを備えたノード。
multiple OLSR interface node
複数のOLSRインターフェイスノード
A node which has multiple OLSR interfaces, participating in an OLSR routing domain.
OLSRルーティングドメインに参加している複数のOLSRインターフェイスを備えたノード。
main address
メインアドレス
The main address of a node, which will be used in OLSR control traffic as the "originator address" of all messages emitted by this node. It is the address of one of the OLSR interfaces of the node.
ノードのメインアドレスは、OLSR制御トラフィックで使用され、このノードによって発したすべてのメッセージの「オリジネーターアドレス」として使用されます。ノードのOLSRインターフェイスの1つのアドレスです。
A single OLSR interface node MUST use the address of its only OLSR interface as the main address.
単一のOLSRインターフェイスノードは、メインアドレスとしてそのみのOLSRインターフェイスのアドレスを使用する必要があります。
A multiple OLSR interface node MUST choose one of its OLSR interface addresses as its "main address" (equivalent of "router ID" or "node identifier"). It is of no importance which address is chosen, however a node SHOULD always use the same address as its main address.
複数のOLSRインターフェイスノードは、OLSRインターフェイスアドレスのいずれかを「メインアドレス」（「ルーターID」または「ノード識別子」に相当）として選択する必要があります。どのアドレスが選択されるかは重要ではありませんが、ノードは常にメインアドレスと同じアドレスを使用する必要があります。
neighbor node
ネイバーノード
A node X is a neighbor node of node Y if node Y can hear node X (i.e., a link exists between an OLSR interface on node X and an OLSR interface on Y).
ノードYがノードYを聞くことができる場合、ノードXはノードYのネイバーノードです（つまり、ノードXのOLSRインターフェイスとYのOLSRインターフェイスの間にリンクが存在します）。
2-hop neighbor
2ホップネイバー
A node heard by a neighbor.
隣人が聞いたノード。
strict 2-hop neighbor
厳格な2ホップ隣人
a 2-hop neighbor which is not the node itself or a neighbor of the node, and in addition is a neighbor of a neighbor, with willingness different from WILL_NEVER, of the node.
ノード自体ではない2ホップの隣人またはノードの隣人であり、さらに、ノードのwill_neverとは異なる意欲を持つ隣人の隣人です。
multipoint relay (MPR)
マルチポイントリレー（MPR）
A node which is selected by its 1-hop neighbor, node X, to "re-transmit" all the broadcast messages that it receives from X, provided that the message is not a duplicate, and that the time to live field of the message is greater than one.
1ホップの隣人であるノードXによって選択されたノードは、メッセージが複製されておらず、メッセージのライブフィールドまでの時間がある場合、Xから受信するすべてのブロードキャストメッセージを「再送信」するようにします。1つ以上です。
multipoint relay selector (MPR selector, MS)
マルチポイントリレーセレクター（MPRセレクター、MS）
A node which has selected its 1-hop neighbor, node X, as its multipoint relay, will be called a multipoint relay selector of node X.
マルチポイントリレーとして1ホップの隣接Xを選択したノードは、ノードXのマルチポイントリレーセレクターと呼ばれます。
link
リンク接続繋がり結ぶつなぎ目連ねる合わせる合わす環併設伝送路連結する関係つける
A link is a pair of OLSR interfaces (from two different nodes) susceptible to hear one another (i.e., one may be able to receive traffic from the other). A node is said to have a link to another node when one of its interface has a link to one of the interfaces of the other node.
リンクは、互いに聞こえる可能性のあるOLSRインターフェイス（2つの異なるノードから）のペアです（つまり、一方が他のトラフィックからトラフィックを受信できる場合があります）。ノードには、そのインターフェイスの1つが他のノードのインターフェイスの1つへのリンクがある場合、別のノードへのリンクがあると言われています。
symmetric link
対称リンク
A verified bi-directional link between two OLSR interfaces.
2つのOLSRインターフェイス間の検証された双方向リンク。
asymmetric link
非対称リンク
A link between two OLSR interfaces, verified in only one direction.
1つの方向のみで検証された2つのOLSRインターフェイス間のリンク。
symmetric 1-hop neighborhood
対称1ホップ近隣
The symmetric 1-hop neighborhood of any node X is the set of nodes which have at least one symmetric link to X.
ノードXの対称1ホップ近傍は、Xへの少なくとも1つの対称リンクを持つノードのセットです。
symmetric 2-hop neighborhood
対称2ホップ近隣
The symmetric 2-hop neighborhood of X is the set of nodes, excluding X itself, which have a symmetric link to the symmetric 1-hop neighborhood of X.
Xの対称2ホップ近傍は、X自体を除くノードのセットで、Xの対称1ホップ近傍への対称リンクがあります。
symmetric strict 2-hop neighborhood
対称的な厳密な2ホップ近隣
The symmetric strict 2-hop neighborhood of X is the set of nodes, excluding X itself and its neighbors, which have a symmetric link to some symmetric 1-hop neighbor, with willingness different of WILL_NEVER, of X.
Xの対称的な厳密な2ホップ近傍は、X自体とその近隣を除くノードのセットであり、対称1ホップネイバーへの対称リンクがあり、意欲がxのwill_neverに違います。
OLSR is a proactive routing protocol for mobile ad-hoc networks (MANETs) [1], [2]. It is well suited to large and dense mobile networks, as the optimization achieved using the MPRs works well in this context. The larger and more dense a network, the more optimization can be achieved as compared to the classic link state algorithm. OLSR uses hop-by-hop routing, i.e., each node uses its local information to route packets.
OLSRは、モバイルアドホックネットワーク（MANETS）[1]、[2]のプロアクティブルーティングプロトコルです。このコンテキストでは、MPRSを使用して達成された最適化がうまく機能するため、大規模で密なモバイルネットワークに適しています。より大きく、より密度の高いネットワークがあるほど、クラシックリンク状態アルゴリズムと比較して、より最適化を実現できます。OLSRはホップバイホップルーティングを使用します。つまり、各ノードはローカル情報を使用してパケットをルーティングします。
OLSR is well suited for networks, where the traffic is random and sporadic between a larger set of nodes rather than being almost exclusively between a small specific set of nodes. As a proactive protocol, OLSR is also suitable for scenarios where the communicating pairs change over time: no additional control traffic is generated in this situation since routes are maintained for all known destinations at all times.
OLSRはネットワークに適しています。ネットワークでは、トラフィックがランダムで、ノードの小さなセットの間ではなく、ノードの大きなセット間で散発的です。プロアクティブなプロトコルとして、OLSRは、通信ペアが時間とともに変化するシナリオにも適しています。この状況では、常にすべての既知の宛先のルートが維持されるため、追加の制御トラフィックは生成されません。
OLSR is a proactive routing protocol for mobile ad hoc networks. The protocol inherits the stability of a link state algorithm and has the advantage of having routes immediately available when needed due to its proactive nature. OLSR is an optimization over the classical link state protocol, tailored for mobile ad hoc networks.
OLSRは、モバイルアドホックネットワーク向けのプロアクティブルーティングプロトコルです。プロトコルは、リンク状態アルゴリズムの安定性を継承し、その積極的な性質のために必要なときにルートをすぐに利用できるという利点があります。OLSRは、モバイルアドホックネットワークに合わせたクラシックリンク状態プロトコルを最適化しています。
OLSR minimizes the overhead from flooding of control traffic by using only selected nodes, called MPRs, to retransmit control messages. This technique significantly reduces the number of retransmissions required to flood a message to all nodes in the network. Secondly, OLSR requires only partial link state to be flooded in order to provide shortest path routes. The minimal set of link state information required is, that all nodes, selected as MPRs, MUST declare the links to their MPR selectors. Additional topological information, if present, MAY be utilized e.g., for redundancy purposes.
OLSRは、制御メッセージを再送信するために、MPRSと呼ばれる選択したノードのみを使用して、制御トラフィックの洪水によるオーバーヘッドを最小限に抑えます。この手法により、ネットワーク内のすべてのノードにメッセージをあふれさせるために必要な再送信の数が大幅に削減されます。第二に、OLSRは、最短経路ルートを提供するために、部分的なリンク状態のみを浸水させる必要があります。必要なリンク状態情報の最小限のセットは、MPRSとして選択されたすべてのノードが、MPRセレクターへのリンクを宣言する必要があることです。追加のトポロジー情報は、存在する場合、冗長性のために使用される場合があります。
OLSR MAY optimize the reactivity to topological changes by reducing the maximum time interval for periodic control message transmission. Furthermore, as OLSR continuously maintains routes to all destinations in the network, the protocol is beneficial for traffic patterns where a large subset of nodes are communicating with another large subset of nodes, and where the [source, destination] pairs are changing over time. The protocol is particularly suited for large and dense networks, as the optimization done using MPRs works well in this context. The larger and more dense a network, the more optimization can be achieved as compared to the classic link state algorithm.
OLSRは、周期制御メッセージ伝達の最大時間間隔を減らすことにより、トポロジーの変化に対する反応性を最適化する場合があります。さらに、OLSRはネットワーク内のすべての目的地へのルートを継続的に維持するため、プロトコルは、ノードの大きなサブセットがノードの別の大きなサブセットと通信し、[ソース、宛先]ペアが時間とともに変化しているトラフィックパターンに有益です。このコンテキストでは、MPRSを使用して行われた最適化がうまく機能するため、このプロトコルは大規模で密なネットワークに特に適しています。より大きく、より密度の高いネットワークがあるほど、クラシックリンク状態アルゴリズムと比較して、より最適化を実現できます。
OLSR is designed to work in a completely distributed manner and does not depend on any central entity. The protocol does NOT REQUIRE reliable transmission of control messages: each node sends control messages periodically, and can therefore sustain a reasonable loss of some such messages. Such losses occur frequently in radio networks due to collisions or other transmission problems.
OLSRは、完全に分散された方法で動作するように設計されており、中央エンティティに依存しません。プロトコルは、制御メッセージの信頼できる送信を必要としません。各ノードは定期的にコントロールメッセージを送信するため、そのようなメッセージの合理的な損失を維持できます。このような損失は、衝突またはその他の送信の問題により、無線ネットワークで頻繁に発生します。
Also, OLSR does not require sequenced delivery of messages. Each control message contains a sequence number which is incremented for each message. Thus the recipient of a control message can, if required, easily identify which information is more recent - even if messages have been re-ordered while in transmission.
また、OLSRはメッセージのシーケンスの配信を必要としません。各コントロールメッセージには、各メッセージに対してインクリメントされるシーケンス番号が含まれています。したがって、コントロールメッセージの受信者は、必要に応じて、送信中にメッセージが再注文された場合でも、より最近の情報を簡単に識別できます。
Furthermore, OLSR provides support for protocol extensions such as sleep mode operation, multicast-routing etc. Such extensions may be introduced as additions to the protocol without breaking backwards compatibility with earlier versions.
さらに、OLSRは、スリープモード操作、マルチキャストルーティングなどのプロトコル拡張機能をサポートします。このような拡張は、以前のバージョンとの逆方向の互換性を破ることなく、プロトコルへの追加として導入される場合があります。
OLSR does not require any changes to the format of IP packets. Thus any existing IP stack can be used as is: the protocol only interacts with routing table management.
OLSRは、IPパケットの形式に変更を必要としません。したがって、既存のIPスタックは次のように使用できます。プロトコルは、ルーティングテーブル管理とのみ相互作用します。
The idea of multipoint relays is to minimize the overhead of flooding messages in the network by reducing redundant retransmissions in the same region. Each node in the network selects a set of nodes in its symmetric 1-hop neighborhood which may retransmit its messages. This set of selected neighbor nodes is called the "Multipoint Relay" (MPR) set of that node. The neighbors of node N which are *NOT* in its MPR set, receive and process broadcast messages but do not retransmit broadcast messages received from node N.
マルチポイントリレーのアイデアは、同じ領域の冗長な再送信を減らすことにより、ネットワーク内のフラッディングメッセージのオーバーヘッドを最小限に抑えることです。ネットワーク内の各ノードは、メッセージを再送信する可能性のある対称1ホップ周辺のノードのセットを選択します。選択した隣接ノードのこのセットは、そのノードの「マルチポイントリレー」（MPR）セットと呼ばれます。MPRセットで *ではないノードNの近隣は、ブロードキャストメッセージを受信、処理しますが、ノードNから受信したブロードキャストメッセージを再送信しません。
Each node selects its MPR set from among its 1-hop symmetric neighbors. This set is selected such that it covers (in terms of radio range) all symmetric strict 2-hop nodes. The MPR set of N, denoted as MPR(N), is then an arbitrary subset of the symmetric 1-hop neighborhood of N which satisfies the following condition: every node in the symmetric strict 2-hop neighborhood of N must have a symmetric link towards MPR(N). The smaller a MPR set, the less control traffic overhead results from the routing protocol. [2] gives an analysis and example of MPR selection algorithms.
各ノードは、1ホップの対称隣接の中からMPRセットを選択します。このセットは、すべての対称的な厳密な2ホップノードをカバーするように選択されます。MPR（n）として示されるnのMPRセットは、次の条件を満たすNの対称1ホップ近傍の任意のサブセットです。Nの対称的な厳密な2ホップ近傍のすべてのノードには対称リンクが必要ですMPR（n）に向かって。A MPRセットが小さいほど、ルーティングプロトコルから制御トラフィックオーバーヘッドが少なくなります。[2]は、MPR選択アルゴリズムの分析と例を示します。
Each node maintains information about the set of neighbors that have selected it as MPR. This set is called the "Multipoint Relay Selector set" (MPR selector set) of a node. A node obtains this information from periodic HELLO messages received from the neighbors.
各ノードは、MPRとして選択した近隣のセットに関する情報を維持しています。このセットは、ノードの「マルチポイントリレーセレクターセット」（MPRセレクターセット）と呼ばれます。ノードは、隣人から受信した定期的なハローメッセージからこの情報を取得します。
A broadcast message, intended to be diffused in the whole network, coming from any of the MPR selectors of node N is assumed to be retransmitted by node N, if N has not received it yet. This set can change over time (i.e., when a node selects another MPR-set) and is indicated by the selector nodes in their HELLO messages.
Node NのMPRセレクターのいずれかからのネットワーク全体で拡散することを目的とした放送メッセージは、Nがまだ受信していない場合、Node Nによって再送信されると想定されています。このセットは、時間の経過とともに変更されます（つまり、ノードが別のMPRセットを選択するとき）、Helloメッセージのセレクターノードによって示されます。
This section outlines the overall protocol functioning.
このセクションでは、全体的なプロトコル機能の概要を説明します。
OLSR is modularized into a "core" of functionality, which is always required for the protocol to operate, and a set of auxiliary functions.
OLSRは機能の「コア」にモジュール化されています。これは、プロトコルが動作するために常に必要な補助機能のセットに必要です。
The core specifies, in its own right, a protocol able to provide routing in a stand-alone MANET.
コアは、それ自体が、スタンドアロンのマネでルーティングを提供できるプロトコルを指定します。
Each auxiliary function provides additional functionality, which may be applicable in specific scenarios, e.g., in case a node is providing connectivity between the MANET and another routing domain.
各補助関数は、特定のシナリオに適用できる追加機能を提供します。たとえば、ノードがMANETと別のルーティングドメイン間の接続性を提供している場合。
All auxiliary functions are compatible, to the extent where any (sub)set of auxiliary functions may be implemented with the core. Furthermore, the protocol allows heterogeneous nodes, i.e., nodes which implement different subsets of the auxiliary functions, to coexist in the network.
すべての補助関数は、補助関数の（サブ）セットがコアで実装できる場合に互換性があります。さらに、このプロトコルにより、不均一なノード、つまり、補助関数の異なるサブセットを実装するノードがネットワークに共存することができます。
The purpose of dividing the functioning of OLSR into a core functionality and a set of auxiliary functions is to provide a simple and easy-to-comprehend protocol, and to provide a way of only adding complexity where specific additional functionality is required.
OLSRの機能をコア機能と一連の補助機能に分割する目的は、シンプルで理解しやすいプロトコルを提供し、特定の追加機能が必要な複雑さのみを追加する方法を提供することです。
The core functionality of OLSR specifies the behavior of a node, equipped with OLSR interfaces participating in the MANET and running OLSR as routing protocol. This includes a universal specification of OLSR protocol messages and their transmission through the network, as well as link sensing, topology diffusion and route calculation.
OLSRのコア機能は、MANETに参加し、ルーティングプロトコルとしてOLSRを実行するOLSRインターフェイスを装備したノードの動作を指定します。これには、OLSRプロトコルメッセージの普遍的な仕様とネットワークを介したそれらの送信、およびリンク検知、トポロジ拡散、ルート計算が含まれます。
Specifically, the core is made up from the following components:
具体的には、コアは次のコンポーネントから構成されています。
Packet Format and Forwarding
パケット形式と転送
A universal specification of the packet format and an optimized flooding mechanism serves as the transport mechanism for all OLSR control traffic.
パケット形式のユニバーサル仕様と最適化された洪水メカニズムは、すべてのOLSR制御トラフィックの輸送メカニズムとして機能します。
Link Sensing
リンクセンシング
Link Sensing is accomplished through periodic emission of HELLO messages over the interfaces through which connectivity is checked. A separate HELLO message is generated for each interface and emitted in correspondence with the provisions in section 7.
リンクセンシングは、接続がチェックされるインターフェイス上のハローメッセージの定期的な放出によって達成されます。インターフェイスごとに別のハローメッセージが生成され、セクション7の規定に対応して放出されます。
Resulting from Link Sensing is a local link set, describing links between "local interfaces" and "remote interfaces" - i.e., interfaces on neighbor nodes.
リンクSensingの結果は、ローカルリンクセットであり、「ローカルインターフェイス」と「リモートインターフェイス」、つまり隣接ノード上のインターフェイスの間のリンクを説明しています。
If sufficient information is provided by the link-layer, this may be utilized to populate the local link set instead of HELLO message exchange.
Link-Layerによって十分な情報が提供されている場合、これはHello Message Exchangeの代わりにローカルリンクセットに入力するために利用できます。
Neighbor detection
隣人の検出
Given a network with only single interface nodes, a node may deduct the neighbor set directly from the information exchanged as part of link sensing: the "main address" of a single interface node is, by definition, the address of the only interface on that node.
単一のインターフェイスノードのみを持つネットワークが与えられた場合、ノードは、リンクセンシングの一部として交換された情報から近隣セットを直接差し引くことができます。単一のインターフェイスノードの「メインアドレス」は、定義上、その上の唯一のインターフェイスのアドレスです。ノード。
In a network with multiple interface nodes, additional information is required in order to map interface addresses to main addresses (and, thereby, to nodes). This additional information is acquired through multiple interface declaration (MID) messages, described in section 5.
複数のインターフェイスノードを備えたネットワークでは、メインアドレス（そしてそれによってノード）にインターフェイスアドレスをマッピングするために追加情報が必要です。この追加情報は、セクション5で説明されている複数のインターフェイス宣言（MID）メッセージを通じて取得されます。
MPR Selection and MPR Signaling
MPR選択とMPRシグナル伝達
The objective of MPR selection is for a node to select a subset of its neighbors such that a broadcast message, retransmitted by these selected neighbors, will be received by all nodes 2 hops away. The MPR set of a node is computed such that it, for each interface, satisfies this condition. The information required to perform this calculation is acquired through the periodic exchange of HELLO messages, as described in section 6. MPR selection procedures are detailed in section 8.3.
MPR選択の目的は、ノードが近隣のサブセットを選択することであり、これらの選択された隣人が再送信するブロードキャストメッセージがすべてのノード2ホップ離れて受信されるようにすることです。ノードのMPRセットは、各インターフェイスについて、この条件を満たすように計算されます。この計算を実行するために必要な情報は、セクション6で説明されているように、Helloメッセージの周期交換を通じて取得されます。MPR選択手順については、セクション8.3で詳しく説明します。
MPR signaling is provided in correspondence with the provisions in the section 6.
MPRシグナル伝達は、セクション6の規定に対応して提供されます。
Topology Control Message Diffusion
トポロジコントロールメッセージ拡散
Topology Control messages are diffused with the purpose of providing each node in the network with sufficient link-state information to allow route calculation. Topology Control messages are diffused in correspondence with the provisions in section 9.
トポロジコントロールメッセージは、ネットワーク内の各ノードに十分なリンク状態情報を提供するための十分なリンク状態情報を提供する目的で拡散します。トポロジコントロールメッセージは、セクション9の規定に対応して拡散されます。
Route Calculation
ルート計算
Given the link state information acquired through periodic message exchange, as well as the interface configuration of the nodes, the routing table for each node can be computed. This is detailed in section 10.
定期的なメッセージ交換を通じて取得したリンク状態情報とノードのインターフェイス構成を考えると、各ノードのルーティングテーブルを計算できます。これはセクション10で詳しく説明されています。
The key notion for these mechanisms is the MPR relationship.
これらのメカニズムの重要な概念は、MPR関係です。
The following table specifies the component of the core functionality of OLSR, as well as their relations to this document.
次の表は、OLSRのコア機能のコンポーネントと、このドキュメントとの関係を指定します。
Feature | Section
------------------------------+--------------
Packet format and forwarding | 3
Information repositories | 4
Main addr and multiple if. | 5
Hello messages | 6
Link sensing | 7
Neighbor detection | 8
Topology discovery | 9
Routing table computation | 10
Node configuration | 11
In addition to the core functioning of OLSR, there are situations where additional functionality is desired. This includes situations where a node has multiple interfaces, some of which participate in another routing domain, where the programming interface to the networking hardware provides additional information in form of link layer notifications and where it is desired to provide redundant topological information to the network on expense of protocol overhead.
OLSRのコア機能に加えて、追加の機能が必要な状況があります。これには、ノードに複数のインターフェイスがある状況が含まれます。その一部は別のルーティングドメインに参加します。ネットワークハードウェアへのプログラミングインターフェイスは、リンクレイヤー通知の形式で追加情報を提供し、冗長なトポロジ情報をネットワークに提供することが望ましい場合プロトコルオーバーヘッドの費用。
The following table specifies auxiliary functions and their relation to this document.
次の表は、補助機能とこのドキュメントとの関係を指定します。
Feature | Section
------------------------------+--------------
Non-OLSR interfaces | 12
Link-layer notifications | 13
Advanced link sensing | 14
Redundant topology | 15
Redundant MPR flooding | 16
The interpretation of the above table is as follows: if the feature listed is required, it SHOULD be provided as specified in the corresponding section.
上記の表の解釈は次のとおりです。リストされている機能が必要な場合は、対応するセクションで指定されているように提供する必要があります。
OLSR communicates using a unified packet format for all data related to the protocol. The purpose of this is to facilitate extensibility of the protocol without breaking backwards compatibility. This also provides an easy way of piggybacking different "types" of information into a single transmission, and thus for a given implementation to optimize towards utilizing the maximal frame-size, provided by the network. These packets are embedded in UDP datagrams for transmission over the network. The present document is presented with IPv4 addresses. Considerations regarding IPv6 are given in section 17.
OLSRは、プロトコルに関連するすべてのデータに対して統一されたパケット形式を使用して通信します。これの目的は、逆方向の互換性を破ることなく、プロトコルの拡張性を促進することです。これはまた、情報のさまざまな「タイプ」を単一の送信に貯める簡単な方法を提供し、したがって、特定の実装がネットワークが提供する最大のフレームサイズを利用するために最適化するための簡単な方法を提供します。これらのパケットは、ネットワークを介して送信するためにUDPデータグラムに埋め込まれています。現在のドキュメントには、IPv4アドレスが付いています。IPv6に関する考慮事項は、セクション17に記載されています。
Each packet encapsulates one or more messages. The messages share a common header format, which enables nodes to correctly accept and (if applicable) retransmit messages of an unknown type.
各パケットは1つ以上のメッセージをカプセル化します。メッセージは共通のヘッダー形式を共有します。これにより、ノードは不明なタイプのメッセージを正しく受け入れ、（該当する場合）再送信できます。
Messages can be flooded onto the entire network, or flooding can be limited to nodes within a diameter (in terms of number of hops) from the originator of the message. Thus transmitting a message to the neighborhood of a node is just a special case of flooding. When flooding any control message, duplicate retransmissions will be eliminated locally (i.e., each node maintains a duplicate set to prevent transmitting the same OLSR control message twice) and minimized in the entire network through the usage of MPRs as described in later sections.
メッセージをネットワーク全体にあふれさせることができます。または、洪水は、メッセージの発信者から直径（ホップ数の観点から）内のノードに制限される可能性があります。したがって、ノードの近隣にメッセージを送信することは、洪水の特別なケースにすぎません。コントロールメッセージに浸水すると、重複した再送信がローカルで排除されます（つまり、各ノードは、同じOLSRコントロールメッセージの送信を2回防止するために重複したセットを維持します）、後のセクションで説明したようにMPRの使用を通じてネットワーク全体で最小化されます。
Furthermore, a node can examine the header of a message to obtain information on the distance (in terms of number of hops) to the originator of the message. This feature may be useful in situations where, e.g., the time information from a received control messages stored in a node depends on the distance to the originator.
さらに、ノードはメッセージのヘッダーを調べて、メッセージのオリジネーターの距離（ホップ数の観点から）に関する情報を取得できます。この機能は、たとえば、ノードに保存されている受信した制御メッセージからの時間情報が、オリジネーターまでの距離に依存する状況で役立つ場合があります。
Packets in OLSR are communicated using UDP. Port 698 has been assigned by IANA for exclusive usage by the OLSR protocol.
OLSRのパケットは、UDPを使用して通信されます。ポート698は、OLSRプロトコルによる排他的使用のためにIANAによって割り当てられています。
For a node with one interface, the main address of a node, as defined in "OLSR Terminology", MUST be set to the address of that interface.
1つのインターフェイスを持つノードの場合、「OLSR用語」で定義されているノードのメインアドレスは、そのインターフェイスのアドレスに設定する必要があります。
The basic layout of any packet in OLSR is as follows (omitting IP and UDP headers):
OLSRのパケットの基本レイアウトは次のとおりです（IPおよびUDPヘッダーを省略します）：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Length | Packet Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Vtime | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time To Live | Hop Count | Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: MESSAGE :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Vtime | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time To Live | Hop Count | Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: MESSAGE :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
(etc.)
Packet Length
パケット長
The length (in bytes) of the packet
パケットの長さ（バイト）
Packet Sequence Number
パケットシーケンス番号
The Packet Sequence Number (PSN) MUST be incremented by one each time a new OLSR packet is transmitted. "Wrap-around" is handled as described in section 19. A separate Packet Sequence Number is maintained for each interface such that packets transmitted over an interface are sequentially enumerated.
パケットシーケンス番号（PSN）は、新しいOLSRパケットが送信されるたびに1つずつ増加する必要があります。「ラップアラウンド」は、セクション19で説明されているように処理されます。インターフェイスを介して送信されたパケットが連続して列挙されるように、各インターフェイスに対して個別のパケットシーケンス番号が維持されます。
The IP address of the interface over which a packet was transmitted is obtainable from the IP header of the packet.
パケットが送信されたインターフェイスのIPアドレスは、パケットのIPヘッダーから取得できます。
If the packet contains no messages (i.e., the Packet Length is less than or equal to the size of the packet header), the packet MUST silently be discarded.
パケットにメッセージが含まれていない場合（つまり、パケットの長さがパケットヘッダーのサイズ以下になる）、パケットを沈黙させる必要があります。
For IPv4 addresses, this implies that packets, where the Packet Length < 16 MUST silently be discarded.
IPv4アドレスの場合、これは、パケットの長さ<16を静かに破棄する必要があることを意味します。
Message Type
メッセージタイプ
This field indicates which type of message is to be found in the "MESSAGE" part. Message types in the range of 0-127 are reserved for messages in this document and in possible extensions.
このフィールドは、「メッセージ」部分にどのタイプのメッセージが見つかるかを示します。0-127の範囲のメッセージタイプは、このドキュメントおよび可能な拡張機能のメッセージ用に予約されています。
Vtime
vtime
This field indicates for how long time after reception a node MUST consider the information contained in the message as valid, unless a more recent update to the information is received. The validity time is represented by its mantissa (four highest bits of Vtime field) and by its exponent (four lowest bits of Vtime field). In other words:
このフィールドは、受信後、ノードがメッセージに含まれる情報を有効であると考慮する必要があることを示しています。有効期間は、そのマンティッサ（VTIMEフィールドの4つのビット）とその指数（VTIMEフィールドの4つの最低ビット）によって表されます。言い換えると：
validity time = C*(1+a/16)* 2^b [in seconds]
where a is the integer represented by the four highest bits of Vtime field and b the integer represented by the four lowest bits of Vtime field. The proposed value of the scaling factor C is specified in section 18.
ここで、aはvtimeフィールドの4つの最高ビットで表される整数と、vtimeフィールドの4つの最低ビットで表される整数です。スケーリング係数Cの提案値は、セクション18で指定されています。
Message Size
メッセージサイズ
This gives the size of this message, counted in bytes and measured from the beginning of the "Message Type" field and until the beginning of the next "Message Type" field (or - if there are no following messages - until the end of the packet).
これにより、このメッセージのサイズが与えられ、バイトでカウントされ、「メッセージタイプ」フィールドの先頭から測定され、次の「メッセージタイプ」フィールドの先頭まで（または - 次のメッセージがない場合 - パケット）。
Originator Address
オリジネーターアドレス
This field contains the main address of the node, which has originally generated this message. This field SHOULD NOT be confused with the source address from the IP header, which is changed each time to the address of the intermediate interface which is re-transmitting this message. The Originator Address field MUST *NEVER* be changed in retransmissions.
このフィールドには、元々このメッセージを生成したノードのメインアドレスが含まれています。このフィールドは、このメッセージを再送信している中間インターフェイスのアドレスに毎回変更されるIPヘッダーのソースアドレスと混同しないでください。オリジネーターアドレスフィールドは、再送信で「決して *変更されない」必要があります。
Time To Live
有効期間
This field contains the maximum number of hops a message will be transmitted. Before a message is retransmitted, the Time To Live MUST be decremented by 1. When a node receives a message with a Time To Live equal to 0 or 1, the message MUST NOT be retransmitted under any circumstances. Normally, a node would not receive a message with a TTL of zero.
このフィールドには、メッセージが送信される最大数のホップ数が含まれています。メッセージが再送信される前に、ライブの時間は1によって減少する必要があります。ノードが0または1に等しい時間でメッセージを受信した場合、どんな状況でもメッセージを再送信してはなりません。通常、ノードはゼロのTTLを含むメッセージを受信しません。
Thus, by setting this field, the originator of a message can limit the flooding radius.
したがって、このフィールドを設定することにより、メッセージの創始者は洪水半径を制限できます。
Hop Count
ホップカウント
This field contains the number of hops a message has attained. Before a message is retransmitted, the Hop Count MUST be incremented by 1.
このフィールドには、メッセージが達成したホップ数が含まれています。メッセージが再送信される前に、ホップカウントを1で増分する必要があります。
Initially, this is set to '0' by the originator of the message.
当初、これはメッセージの発信者によって「0」に設定されています。
Message Sequence Number
メッセージシーケンス番号
While generating a message, the "originator" node will assign a unique identification number to each message. This number is inserted into the Sequence Number field of the message. The sequence number is increased by 1 (one) for each message originating from the node. "Wrap-around" is handled as described in section 19. Message sequence numbers are used to ensure that a given message is not retransmitted more than once by any node.
メッセージを生成している間、「Originator」ノードは各メッセージに一意の識別番号を割り当てます。この番号は、メッセージのシーケンス番号フィールドに挿入されます。ノードから発信される各メッセージに対して、シーケンス番号が1（1）増加します。「ラップアラウンド」はセクション19で説明されているように処理されます。メッセージシーケンス番号は、特定のメッセージがノードによって複数回再送信されないようにするために使用されます。
Upon receiving a basic packet, a node examines each of the "message headers". Based on the value of the "Message Type" field, the node can determine the fate of the message. A node may receive the same message several times. Thus, to avoid re-processing of some messages which were already received and processed, each node maintains a Duplicate Set. In this set, the node records information about the most recently received messages where duplicate processing of a message is to be avoided. For such a message, a node records a "Duplicate Tuple" (D_addr, D_seq_num, D_retransmitted, D_iface_list, D_time), where D_addr is the originator address of the message, D_seq_num is the message sequence number of the message, D_retransmitted is a boolean indicating whether the message has been already retransmitted, D_iface_list is a list of the addresses of the interfaces on which the message has been received and D_time specifies the time at which a tuple expires and *MUST* be removed.
基本的なパケットを受信すると、ノードはそれぞれ「メッセージヘッダー」を調べます。「メッセージタイプ」フィールドの値に基づいて、ノードはメッセージの運命を決定できます。ノードは同じメッセージを数回受信する場合があります。したがって、既に受信および処理されたいくつかのメッセージの再処理を避けるために、各ノードは重複したセットを維持します。このセットでは、ノードは、メッセージの複製処理を避けるために、最近受信したメッセージに関する情報を記録します。このようなメッセージの場合、ノードは「重複したタプル」（D_ADDR、D_SEQ_NUM、D_RETRANSMITTED、D_IFACE_LIST、D_TIME）を記録します。D_ADDRはメッセージのオリジネーターアドレスです。D_SEQ_NUMはメッセージのメッセージシーケンス番号です。メッセージが既に再送信されているかどうかにかかわらず、d_iface_listはメッセージが受信されたインターフェイスのアドレスのリストであり、d_timeはタプルの有効期限が切れ、 *削除されなければならない時間を指定します。
In a node, the set of Duplicate Tuples are denoted the "Duplicate set".
ノードでは、重複したタプルのセットが「複製セット」と表示されます。
In this section, the term "Originator Address" will be used for the main address of the node which sent the message. The term "Sender Interface Address" will be used for the sender address (given in the IP header of the packet containing the message) of the interface which sent the message. The term "Receiving Interface Address" will be used for the address of the interface of the node which received the message.
このセクションでは、「オリジネーターアドレス」という用語は、メッセージを送信したノードのメインアドレスに使用されます。「送信者インターフェイスアドレス」という用語は、メッセージを送信したインターフェイスの送信者アドレス（メッセージを含むパケットのIPヘッダーで指定）に使用されます。「インターフェイスアドレスの受信」という用語は、メッセージを受信したノードのインターフェイスのアドレスに使用されます。
Thus, upon receiving a basic packet, a node MUST perform the following tasks for each encapsulated message:
したがって、基本的なパケットを受信すると、ノードは、カプセル化されたメッセージごとに次のタスクを実行する必要があります。
1 If the packet contains no messages (i.e., the Packet Length is less than or equal to the size of the packet header), the packet MUST silently be discarded.
1パケットにメッセージが含まれていない場合（つまり、パケットの長さがパケットヘッダーのサイズ以下である場合）、パケットを静かに破棄する必要があります。
For IPv4 addresses, this implies that packets, where the Packet Length < 16 MUST silently be discarded.
IPv4アドレスの場合、これは、パケットの長さ<16を静かに破棄する必要があることを意味します。
2 If the time to live of the message is less than or equal to '0' (zero), or if the message was sent by the receiving node (i.e., the Originator Address of the message is the main address of the receiving node): the message MUST silently be dropped.
2メッセージのライブ時間が「0」（ゼロ）以下の場合、または受信ノードによってメッセージが送信された場合（つまり、メッセージのオリジネーターアドレスが受信ノードのメインアドレスである場合）：メッセージは静かにドロップする必要があります。
3 Processing condition:
3処理条件：
3.1 if there exists a tuple in the duplicate set, where:
3.1 複製セットにタプルが存在する場合、ここで：
D_addr == Originator Address, AND
d_addr ==オリジナルアドレス、および
D_seq_num == Message Sequence Number
d_seq_num ==メッセージシーケンス番号
then the message has already been completely processed and MUST not be processed again.
その後、メッセージはすでに完全に処理されており、再度処理してはなりません。
3.2 Otherwise, if the node implements the Message Type of the message, the message MUST be processed according to the specifications for the message type.
3.2 それ以外の場合、ノードがメッセージのメッセージタイプを実装する場合、メッセージタイプの仕様に従ってメッセージを処理する必要があります。
4 Forwarding condition:
4転送条件：
4.1 if there exists a tuple in the duplicate set, where:
4.1 複製セットにタプルが存在する場合、ここで：
D_addr == Originator Address, AND
d_addr ==オリジナルアドレス、および
D_seq_num == Message Sequence Number, AND
d_seq_num ==メッセージシーケンス番号、および
the receiving interface (address) is in D_iface_list
受信インターフェイス（アドレス）はd_iface_listにあります
then the message has already been considered for forwarding and SHOULD NOT be retransmitted again.
その後、メッセージはすでに転送のために検討されており、再度再送信されるべきではありません。
4.2 Otherwise:
4.2 さもないと：
4.2.1 If the node implements the Message Type of the message, the message MUST be considered for forwarding according to the specifications for the message type.
4.2.1 ノードがメッセージのメッセージタイプを実施する場合、メッセージタイプの仕様に従って、メッセージを転送するためにメッセージを考慮する必要があります。
4.2.2 Otherwise, if the node does not implement the Message Type of the message, the message SHOULD be processed according to the default forwarding algorithm described below.
4.2.2 それ以外の場合、ノードがメッセージのメッセージタイプを実装していない場合、メッセージは以下に説明するデフォルトの転送アルゴリズムに従って処理する必要があります。
The default forwarding algorithm is the following:
デフォルトの転送アルゴリズムは次のとおりです。
1 If the sender interface address of the message is not detected to be in the symmetric 1-hop neighborhood of the node, the forwarding algorithm MUST silently stop here (and the message MUST NOT be forwarded).
1メッセージの送信者インターフェイスアドレスがノードの対称1ホップ近傍にあるように検出されない場合、転送アルゴリズムはここで静かに停止する必要があります（メッセージを転送してはなりません）。
2 If there exists a tuple in the duplicate set where:
2重複したセットにタプルが存在する場合：
D_addr == Originator Address
d_addr ==オリジナルアドレス
D_seq_num == Message Sequence Number
d_seq_num ==メッセージシーケンス番号
Then the message will be further considered for forwarding if and only if:
次
D_retransmitted is false, AND the (address of the) interface which received the message is not included among the addresses in D_iface_list
d_retransmittedはfalseであり、メッセージを受信した（アドレスの）インターフェイスはd_iface_listのアドレスに含まれていません
3 Otherwise, if such an entry doesn't exist, the message is further considered for forwarding.
3それ以外の場合、そのようなエントリが存在しない場合、メッセージはさらに転送のために検討されます。
If after those steps, the message is not considered for forwarding, then the processing of this section stops (i.e., steps 4 to 8 are ignored), otherwise, if it is still considered for forwarding then the following algorithm is used:
これらの手順の後、メッセージが転送のために考慮されない場合、このセクションの処理は停止します（つまり、ステップ4〜8は無視されます）。
4 If the sender interface address is an interface address of a MPR selector of this node and if the time to live of the message is greater than '1', the message MUST be retransmitted (as described later in steps 6 to 8).
4送信者インターフェイスアドレスがこのノードのMPRセレクターのインターフェイスアドレスであり、メッセージのライブ時間が「1」より大きい場合、メッセージを再送信する必要があります（手順6〜8で説明するように）。
5 If an entry in the duplicate set exists, with same Originator Address, and same Message Sequence Number, the entry is updated as follows:
5重複セットのエントリが存在する場合、同じオリジネーターアドレスと同じメッセージシーケンス番号がある場合、エントリは次のように更新されます。
D_time = current time + DUP_HOLD_TIME.
d_time =現在の時間dup_hold_time。
The receiving interface (address) is added to D_iface_list.
受信インターフェイス（アドレス）がD_IFACE_LISTに追加されます。
D_retransmitted is set to true if and only if the message will be retransmitted according to step 4.
D_RETRANSTITEDは、メッセージがステップ4に従って再送信される場合にのみTRUEに設定されます。
Otherwise an entry in the duplicate set is recorded with:
それ以外の場合、複製セットのエントリは以下で記録されます。
D_addr = Originator Address
D_seq_num = Message Sequence Number
D_time = current time + DUP_HOLD_TIME.
d_time =現在の時間dup_hold_time。
D_iface_list contains the receiving interface address.
D_IFACE_LISTには、受信インターフェイスアドレスが含まれています。
D_retransmitted is set to true if and only if the message will be retransmitted according to step 4.
D_RETRANSTITEDは、メッセージがステップ4に従って再送信される場合にのみTRUEに設定されます。
If, and only if, according to step 4, the message must be retransmitted then:
ステップ4によると、メッセージを再送信する必要がある場合にのみ：
6 The TTL of the message is reduced by one.
6メッセージのTTLは1つ削減されます。
7 The hop-count of the message is increased by one 8 The message is broadcast on all interfaces (Notice: The remaining fields of the message header SHOULD be left unmodified.)
7メッセージのホップカウントは1つに増加します8メッセージはすべてのインターフェイスでブロードキャストされます（通知：メッセージヘッダーの残りのフィールドは修正されていないままにする必要があります。）
It should be noted that processing and forwarding messages are two different actions, conditioned by different rules. Processing relates to using the content of the messages, while forwarding is related to retransmitting the same message for other nodes of the network.
メッセージの処理と転送は、異なるルールによって条件付けられている2つの異なるアクションであることに注意する必要があります。処理はメッセージのコンテンツの使用に関連し、転送はネットワークの他のノードに対して同じメッセージを再送信することに関連しています。
Notice that this specification includes a description for both the forwarding and the processing of each known message type. Messages with known message types MUST *NOT* be forwarded "blindly" by this algorithm. Forwarding (and setting the correct message header in the forwarded, known, message) is the responsibility of the algorithm specifying how the message is to be handled and, if necessary, retransmitted. This enables a message type to be specified such that the message can be modified while in transit (e.g., to reflect the route the message has taken). It also enables bypassing of the MPR flooding mechanism if for some reason classical flooding of a message type is required, the algorithm which specifies how such messages should be handled will simply rebroadcast the message, regardless of MPRs.
この仕様には、既知の各メッセージタイプの転送と処理の両方の説明が含まれていることに注意してください。既知のメッセージタイプを持つメッセージは、このアルゴリズムによって「盲目的に」転送する必要はありません。転送（および転送された、既知のメッセージに正しいメッセージヘッダーを設定する）は、メッセージの処理方法を指定し、必要に応じて再送信する方法を指定するアルゴリズムの責任です。これにより、メッセージタイプを指定できるようにするため、輸送中にメッセージを変更できるようになります（たとえば、メッセージが行ったルートを反映する）。また、何らかの理由でメッセージタイプの古典的な洪水が必要な場合、そのようなメッセージを処理する方法を指定するアルゴリズムは、MPRに関係なくメッセージを単純に再ロードキャストすることができます。
By defining a set of message types, which MUST be recognized by all implementations of OLSR, it will be possible to extend the protocol through introduction of additional message types, while still being able to maintain compatibility with older implementations. The REQUIRED message types for the core functionality of OLSR are:
OLSRのすべての実装によって認識される必要がある一連のメッセージタイプを定義することにより、追加のメッセージタイプの導入を通じてプロトコルを拡張することが可能になり、古い実装との互換性を維持することができます。OLSRのコア機能に必要なメッセージタイプは次のとおりです。
- HELLO-messages, performing the task of link sensing, neighbor detection and MPR signaling,
- こんにちはメッセージ、リンクセンシング、隣人の検出、MPRシグナリングのタスクの実行、
- TC-messages, performing the task of topology declaration (advertisement of link states).
- TCメッセージ、トポロジ宣言のタスクを実行する（リンク状態の広告）。
- MID-messages, performing the task of declaring the presence of multiple interfaces on a node.
- ミッドメッセージ、ノード上の複数のインターフェイスの存在を宣言するタスクを実行します。
Other message types include those specified in later sections, as well as possible future extensions such as messages enabling power conservation / sleep mode, multicast routing, support for unidirectional links, auto-configuration/address assignment etc.
その他のメッセージタイプには、後のセクションで指定されたものと、電源保存 /睡眠モードを可能にするメッセージ、マルチキャストルーティング、単方向リンクのサポート、自動コンフィギュレーション /アドレスの割り当てなどのメッセージなどの将来の拡張機能が含まれます。
As a basic implementation requirement, synchronization of control messages SHOULD be avoided. As a consequence, OLSR control messages SHOULD be emitted such that they avoid synchronization.
基本的な実装要件として、制御メッセージの同期は避ける必要があります。結果として、同期を避けるようにOLSR制御メッセージを放出する必要があります。
Emission of control traffic from neighboring nodes may, for various reasons (mainly timer interactions with packet processing), become synchronized such that several neighbor nodes attempt to transmit control traffic simultaneously. Depending on the nature of the underlying link-layer, this may or may not lead to collisions and hence message loss - possibly loss of several subsequent messages of the same type.
隣接するノードからの制御トラフィックの排出は、さまざまな理由（主にパケット処理とのタイマーの相互作用）で同期して、いくつかの隣接ノードが制御トラフィックを同時に送信しようとするように同期します。基礎となるリンク層の性質に応じて、これは衝突につながり、したがってメッセージの損失につながる場合とそうでない場合があります。
To avoid such synchronizations, the following simple strategy for emitting control messages is proposed. A node SHOULD add an amount of jitter to the interval at which messages are generated. The jitter must be a random value for each message generated. Thus, for a node utilizing jitter:
このような同期を回避するために、コントロールメッセージを放出するための次の簡単な戦略が提案されています。ノードは、メッセージが生成される間隔にジッターの量を追加する必要があります。ジッターは、生成された各メッセージのランダム値である必要があります。したがって、ジッターを使用するノードの場合：
Actual message interval = MESSAGE_INTERVAL - jitter
実際のメッセージ間隔= message_interval -jitter
Where jitter is a value, randomly selected from the interval [0,MAXJITTER] and MESSAGE_INTERVAL is the value of the message interval specified for the message being emitted (e.g., HELLO_INTERVAL for HELLO messages, TC_INTERVAL for TC-messages etc.).
ここで、ジッターは間隔[0、maxjitter]からランダムに選択され、message_intervalは、排出されるメッセージに対して指定されたメッセージ間隔の値です（たとえば、helloメッセージのhello_interval、tcmessagesなどのtc_interval）。
Jitter SHOULD also be introduced when forwarding messages. The following simple strategy may be adopted: when a message is to be forwarded by a node, it should be kept in the node during a short period of time :
メッセージを転送する際にもジッターを導入する必要があります。次の簡単な戦略を採用することができます。メッセージをノードで転送する場合、短期間はノードに保持する必要があります。
Keep message period = jitter
メッセージの期間を保持=ジッター
Where jitter is a random value in [0,MAXJITTER].
ここで、ジッターは[0、maxjitter]のランダム値です。
Notice that when the node sends a control message, the opportunity to piggyback other messages (before their keeping period is expired) may be taken to reduce the number of packet transmissions.
ノードがコントロールメッセージを送信すると、パケット送信の数を減らすために、他のメッセージ（維持期限が切れる前に）をピギーバックする機会が取られる可能性があることに注意してください。
Notice, that a minimal rate of control messages is imposed. A node MAY send control messages at a higher rate, if beneficial for a specific deployment.
制御メッセージの最小レートが課されることに注意してください。特定の展開に有益な場合、ノードはより高いレートでコントロールメッセージを送信する場合があります。
Through the exchange of OLSR control messages, each node accumulates information about the network. This information is stored according to the descriptions in this section.
OLSR制御メッセージの交換を通じて、各ノードはネットワークに関する情報を蓄積します。この情報は、このセクションの説明に従って保存されます。
For each destination in the network, "Interface Association Tuples" (I_iface_addr, I_main_addr, I_time) are recorded. I_iface_addr is an interface address of a node, I_main_addr is the main address of this node. I_time specifies the time at which this tuple expires and *MUST* be removed.
ネットワーク内の各宛先について、「Interface Association Tulples」（i_iface_addr、i_main_addr、i_time）が記録されます。i_iface_addrはノードのインターフェイスアドレスであり、i_main_addrはこのノードのメインアドレスです。i_timeこのタプルが期限切れになり、 *削除する必要がある時間を指定します。
In a node, the set of Interface Association Tuples is denoted the "Interface Association Set".
ノードでは、インターフェイスアソシエーションのタプルのセットが「インターフェイスアソシエーションセット」と呼ばれます。
The local link information base stores information about links to neighbors.
ローカルリンク情報ベースは、近隣へのリンクに関する情報を保存しています。
A node records a set of "Link Tuples" (L_local_iface_addr, L_neighbor_iface_addr, L_SYM_time, L_ASYM_time, L_time). L_local_iface_addr is the interface address of the local node (i.e., one endpoint of the link), L_neighbor_iface_addr is the interface address of the neighbor node (i.e., the other endpoint of the link), L_SYM_time is the time until which the link is considered symmetric, L_ASYM_time is the time until which the neighbor interface is considered heard, and L_time specifies the time at which this record expires and *MUST* be removed. When L_SYM_time and L_ASYM_time are expired, the link is considered lost.
ノードは、「Link Tulples」のセット（l_local_iface_addr、l_neighbor_iface_addr、l_sym_time、l_asym_time、l_time）を記録します。l_local_iface_addrはローカルノードのインターフェイスアドレス（つまり、リンクの1つのエンドポイント）、l_neighbor_iface_addrは近隣ノードのインターフェイスアドレス（すなわち、リンクのもう1つのエンドポイント）、l_sym_timeはリンクが対称と見なされる時期です、l_asym_timeは、近隣インターフェイスが聞こえると見なされるまでの時間であり、L_TIMEはこのレコードが期限切れになり、 *削除する必要がある時間を指定します。l_sym_timeおよびl_asym_timeの有効期限が切れた場合、リンクは失われたと見なされます。
This information is used when declaring the neighbor interfaces in the HELLO messages.
この情報は、helloメッセージ内の隣のインターフェイスを宣言するときに使用されます。
L_SYM_time is used to decide the Link Type declared for the neighbor interface. If L_SYM_time is not expired, the link MUST be declared symmetric. If L_SYM_time is expired, the link MUST be declared asymmetric. If both L_SYM_time and L_ASYM_time are expired, the link MUST be declared lost.
l_sym_timeは、隣接インターフェイスで宣言されたリンクタイプを決定するために使用されます。L_SYM_TIMEが期限切れになっていない場合、リンクは対称と宣言する必要があります。L_SYM_TIMEの有効期限が切れている場合、リンクは非対称と宣言する必要があります。L_SYM_TIMEとL_ASYM_TIMEの両方が有効期限が切れている場合、リンクを紛失したと宣言する必要があります。
In a node, the set of Link Tuples are denoted the "Link Set".
ノードでは、リンクタプルのセットが「リンクセット」を示します。
The neighborhood information base stores information about neighbors, 2-hop neighbors, MPRs and MPR selectors.
近隣情報ベースには、隣人、2ホップの隣人、MPRS、MPRセレクターに関する情報が保存されています。
A node records a set of "neighbor tuples" (N_neighbor_main_addr, N_status, N_willingness), describing neighbors. N_neighbor_main_addr is the main address of a neighbor, N_status specifies if the node is NOT_SYM or SYM. N_willingness in an integer between 0 and 7, and specifies the node's willingness to carry traffic on behalf of other nodes.
ノードは、隣人を説明する「隣人のタプル」（n_neighbor_main_addr、n_status、n_willingness）のセットを記録します。n_neighbor_main_addrは隣人のメインアドレスです。N_Statusは、ノードがnot_symまたはsymであるかどうかを指定します。0から7の間の整数でのn_willingnessは、他のノードに代わってトラフィックを運ぶというノードの意欲を指定します。
A node records a set of "2-hop tuples" (N_neighbor_main_addr, N_2hop_addr, N_time), describing symmetric (and, since MPR links by definition are also symmetric, thereby also MPR) links between its neighbors and the symmetric 2-hop neighborhood. N_neighbor_main_addr is the main address of a neighbor, N_2hop_addr is the main address of a 2-hop neighbor with a symmetric link to N_neighbor_main_addr, and N_time specifies the time at which the tuple expires and *MUST* be removed.
ノードは、「2ホップタプル」のセット（n_neighbor_main_addr、n_2hop_addr、n_time）を記録し、対称性（および定義上のMPRリンクも対称的であり、MPRもMPR）リンクをその近隣と対称の2ホップ近隣の間のリンクを記述します。n_neighbor_main_addrは隣人のメインアドレスであり、n_2hop_addrはn_neighbor_main_addrへの対称リンクを持つ2ホップネイバーのメインアドレスであり、n_timeはタプルの有効期限が切れ、 *必須 *を削除する時間を指定します。
In a node, the set of 2-hop tuples are denoted the "2-hop Neighbor Set".
ノードでは、2ホップのタプルのセットが「2ホップネイバーセット」と表示されます。
A node maintains a set of neighbors which are selected as MPR. Their main addresses are listed in the MPR Set.
ノードは、MPRとして選択された一連の隣人を維持します。それらのメインアドレスは、MPRセットにリストされています。
A node records a set of MPR-selector tuples (MS_main_addr, MS_time), describing the neighbors which have selected this node as a MPR. MS_main_addr is the main address of a node, which has selected this node as MPR. MS_time specifies the time at which the tuple expires and *MUST* be removed.
ノードは、このノードをMPRとして選択したネイバーを記述するMPRセレクターのタプルのセット（MS_MAIN_ADDR、MS_TIME）を記録します。MS_MAIN_ADDRは、このノードをMPRとして選択したノードのメインアドレスです。MS_TIMEは、タプルの有効期限が切れ、 *削除されなければならない時間を指定します。
In a node, the set of MPR-selector tuples are denoted the "MPR Selector Set".
ノードでは、MPRセレクターのタプルのセットが「MPRセレクターセット」を示します。
Each node in the network maintains topology information about the network. This information is acquired from TC-messages and is used for routing table calculations.
ネットワーク内の各ノードは、ネットワークに関するトポロジ情報を維持しています。この情報はTCメスから取得され、テーブルの計算をルーティングするために使用されます。
Thus, for each destination in the network, at least one "Topology Tuple" (T_dest_addr, T_last_addr, T_seq, T_time) is recorded. T_dest_addr is the main address of a node, which may be reached in one hop from the node with the main address T_last_addr. Typically, T_last_addr is a MPR of T_dest_addr. T_seq is a sequence number, and T_time specifies the time at which this tuple expires and *MUST* be removed.
したがって、ネットワーク内の各宛先について、少なくとも1つの「トポロジタプル」（T_DEST_ADDR、T_LAST_ADDR、T_SEQ、T_TIME）が記録されます。T_DEST_ADDRはノードのメインアドレスであり、メインアドレスT_LAST_ADDRを使用してノードから1つのホップで到達することができます。通常、T_LAST_ADDRはT_DEST_ADDRのMPRです。T_SEQはシーケンス番号であり、T_TIMEは、このタプルが期限切れになり、 *削除する必要がある時間を指定します。
In a node, the set of Topology Tuples are denoted the "Topology Set".
ノードでは、トポロジのタプルのセットが「トポロジセット」と示されています。
For single OLSR interface nodes, the relationship between an OLSR interface address and the corresponding main address is trivial: the main address is the OLSR interface address. For multiple OLSR interface nodes, the relationship between OLSR interface addresses and main addresses is defined through the exchange of Multiple Interface Declaration (MID) messages. This section describes how MID messages are exchanged and processed.
単一のOLSRインターフェイスノードの場合、OLSRインターフェイスアドレスと対応するメインアドレスとの関係は些細なことです。メインアドレスはOLSRインターフェイスアドレスです。複数のOLSRインターフェイスノードの場合、OLSRインターフェイスアドレスとメインアドレスとの関係は、複数のインターフェイス宣言（MID）メッセージの交換によって定義されます。このセクションでは、MIDメッセージの交換と処理方法について説明します。
Each node with multiple interfaces MUST announce, periodically, information describing its interface configuration to other nodes in the network. This is accomplished through flooding a Multiple Interface Declaration message to all nodes in the network through the MPR flooding mechanism.
複数のインターフェイスを備えた各ノードは、ネットワーク内の他のノードへのインターフェイス構成を説明する情報を定期的に発表する必要があります。これは、MPRフラッディングメカニズムを介してネットワーク内のすべてのノードに複数のインターフェイス宣言メッセージを浸水させることで達成されます。
Each node in the network maintains interface information about the other nodes in the network. This information acquired from MID messages, emitted by nodes with multiple interfaces participating in the MANET, and is used for routing table calculations.
ネットワーク内の各ノードは、ネットワーク内の他のノードに関するインターフェイス情報を維持します。この情報は、MIDメッセージから取得され、MANETに参加している複数のインターフェイスを備えたノードで放出され、テーブルの計算に使用されます。
Specifically, multiple interface declaration associates multiple interfaces to a node (and to a main address) through populating the multiple interface association base in each node.
具体的には、複数のインターフェイス宣言は、各ノードの複数のインターフェイスアソシエーションベースを登録することにより、複数のインターフェイスをノード（およびメインアドレス）に関連付けます。
The proposed format of a MID message is as follows:
中間メッセージの提案された形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OLSR Interface Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OLSR Interface Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This is sent as the data-portion of the general packet format described in section 3.4, with the "Message Type" set to MID_MESSAGE. The time to live SHOULD be set to 255 (maximum value) to diffuse the message into the entire network and Vtime set accordingly to the value of MID_HOLD_TIME, as specified in section 18.3.
これは、セクション3.4で説明されている一般的なパケット形式のデータパーティションとして送信され、「メッセージタイプ」がmid_messageに設定されています。セクション18.3で指定されているように、ライブ時間は255（最大値）に設定して、ネットワーク全体に拡散し、MID_HOLD_TIMEの値にそれに応じて設定されたVTIMEを拡散させる必要があります。
OLSR Interface Address
OLSRインターフェイスアドレス
This field contains the address of an OLSR interface of the node, excluding the nodes main address (which already indicated in the originator address).
このフィールドには、ノードのOLSRインターフェイスのアドレスが含まれており、ノードのメインアドレス（オリジネーターアドレスに既に示されている）を除きます。
All interface addresses other than the main address of the originator node are put in the MID message. If the maximum allowed message size (as imposed by the network) is reached while there are still interface addresses which have not been inserted into the MIDmessage, more MID messages are generated until the entire interface addresses set has been sent.
Originatorノードのメインアドレス以外のすべてのインターフェイスアドレスは、中間メッセージに配置されます。最大許可されたメッセージサイズ（ネットワークによって課される）に到達した場合、ミッドメサージに挿入されていないインターフェイスアドレスがまだある場合、インターフェイスアドレスセット全体が送信されるまでより多くのミッドメッセージが生成されます。
A MID message is sent by a node in the network to declare its multiple interfaces (if any). I.e., the MID message contains the list of interface addresses which are associated to its main address. The list of addresses can be partial in each MID message (e.g., due to message size limitations, imposed by the network), but parsing of all MID messages describing the interface set from a node MUST be complete within a certain refreshing period (MID_INTERVAL). The information diffused in the network by these MID messages will help each node to calculate its routing table. A node which has only a single interface address participating in the MANET (i.e., running OLSR), MUST NOT generate any MID message.
ミッドメッセージは、ネットワーク内のノードによって送信され、複数のインターフェイスを宣言します（ある場合）。つまり、MIDメッセージには、メインアドレスに関連付けられているインターフェイスアドレスのリストが含まれています。アドレスのリストは、各ミッドメッセージ（たとえば、ネットワークによって課されるメッセージサイズの制限のために）で部分的にすることができますが、ノードからのインターフェイスセットを説明するすべてのMIDメッセージの解析は、特定のさわやかな期間内に完了する必要があります（Mid_interval）。これらのミッドメッセージによってネットワークに拡散した情報は、各ノードがルーティングテーブルを計算するのに役立ちます。マネに参加する単一のインターフェイスアドレスのみを持つノード（つまり、OLSRの実行）は、中間メッセージを生成してはなりません。
A node with several interfaces, where only one is participating in the MANET and running OLSR (e.g., a node is connected to a wired network as well as to a MANET) MUST NOT generate any MID messages.
MANETに参加してOLSRを実行しているいくつかのインターフェイスを備えたノード（たとえば、ノードが有線ネットワークとMANETに接続されている）は、中間メッセージを生成してはなりません。
A node with several interfaces, where more than one is participating in the MANET and running OLSR MUST generate MID messages as specified.
複数のインターフェイスを備えたノード。複数のインターフェイスがマネに参加し、OLSRを実行する必要があります。
MID messages are broadcast and retransmitted by the MPRs in order to diffuse the messages in the entire network. The "default forwarding algorithm" (described in section 3.4) MUST be used for forwarding of MID messages.
ミッドメッセージは、ネットワーク全体のメッセージを拡散するために、MPRSによってブロードキャストおよび再送信されます。「デフォルトの転送アルゴリズム」（セクション3.4で説明）は、MIDメッセージの転送に使用する必要があります。
The tuples in the multiple interface association set are recorded with the information that is exchanged through MID messages.
Multiple Interface Associationセットのタプルは、Midメッセージを通じて交換される情報に記録されます。
Upon receiving a MID message, the "validity time" MUST be computed from the Vtime field of the message header (as described in section 3.3.2). The Multiple Interface Association Information Base SHOULD then be updated as follows:
中間メッセージを受信すると、「有効性時間」は、メッセージヘッダーのvtimeフィールドから計算する必要があります（セクション3.3.2で説明されています）。次に、複数のインターフェイスアソシエーション情報ベースを更新する必要があります。
1 If the sender interface (NB: not originator) of this message is not in the symmetric 1-hop neighborhood of this node, the message MUST be discarded.
1このメッセージの送信者インターフェイス（NB：元の元）がこのノードの対称1ホップ近傍にない場合、メッセージを破棄する必要があります。
2 For each interface address listed in the MID message:
2ミッドメッセージにリストされている各インターフェイスアドレスについて：
2.1 If there exist some tuple in the interface association set where:
2.1 インターフェイスアソシエーションセットにタプルが存在する場合：
I_iface_addr == interface address, AND
i_iface_addr ==インターフェイスアドレス、および
I_main_addr == originator address,
i_main_addr ==オリジナルアドレス、
then the holding time of that tuple is set to:
その後、そのタプルの保持時間は次のように設定されています。
I_time = current time + validity time.
i_time =現在の時間妥当性時間。
2.2 Otherwise, a new tuple is recorded in the interface association set where:
2.2 それ以外の場合は、新しいタプルがインターフェイスアソシエーションセットに記録されています。
I_iface_addr = interface address,
i_iface_addr =インターフェイスアドレス、
I_main_addr = originator address, I_time = current time + validity time.
i_main_addr = originatorアドレス、i_time =現在の時間妥当性時間。
In general, the only part of OLSR requiring use of "interface addresses" is link sensing. The remaining parts of OLSR operate on nodes, uniquely identified by their "main addresses" (effectively, the main address of a node is its "node id" - which for convenience corresponds to the address of one of its interfaces). In a network with only single interface nodes, the main address of a node will, by definition, be equal to the interface address of the node. In networks with multiple interface nodes operating within a common OLSR area, it is required to be able to map any interface address to the corresponding main address.
一般に、「インターフェイスアドレス」の使用を必要とするOLSRの唯一の部分は、リンクセンシングです。OLSRの残りの部分は、「メインアドレス」によって一意に識別されるノードで動作します（事実上、ノードのメインアドレスは「ノードID」です。単一のインターフェイスノードのみを備えたネットワークでは、ノードのメインアドレスは、定義上、ノードのインターフェイスアドレスに等しくなります。一般的なOLSR領域内で動作する複数のインターフェイスノードを持つネットワークでは、インターフェイスアドレスを対応するメインアドレスにマッピングできる必要があります。
The exchange of MID messages provides a way in which interface information is acquired by nodes in the network. This permits identification of a node's "main address", given one of its interface addresses.
MIDメッセージの交換は、ネットワーク内のノードによってインターフェイス情報が取得される方法を提供します。これにより、インターフェイスアドレスの1つを考えると、ノードの「メインアドレス」の識別が可能になります。
Given an interface address:
インターフェイスアドレスが与えられます：
1 if there exists some tuple in the interface association set where:
1インターフェイスアソシエーションセットにタプルが存在する場合：
I_iface_addr == interface address
i_iface_addr ==インターフェイスアドレス
then the result of the main address search is the originator address I_main_addr of the tuple.
次に、メインアドレス検索の結果は、タプルのオリジネーターアドレスi_main_addrです。
2 Otherwise, the result of the main address search is the interface address itself.
2それ以外の場合、メインアドレス検索の結果は、インターフェイスアドレス自体です。
A common mechanism is employed for populating the local link information base and the neighborhood information base, namely periodic exchange of HELLO messages. Thus this section describes the general HELLO message mechanism, followed by a description of link sensing and topology detection, respectively.
ローカルリンク情報ベースと近隣情報ベース、つまりハローメッセージの定期的な交換に登録するために、共通のメカニズムが採用されています。したがって、このセクションでは、一般的なハローメッセージメカニズムと、それぞれリンク検知とトポロジの検出の説明が続きます。
To accommodate for link sensing, neighborhood detection and MPR selection signalling, as well as to accommodate for future extensions, an approach similar to the overall packet format is taken. Thus the proposed format of a HELLO message is as follows:
リンクセンシング、近隣の検出、MPR選択シグナリングに対応し、将来の拡張に対応するために、全体的なパケット形式と同様のアプローチが取得されます。したがって、Helloメッセージの提案された形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Htime | Willingness |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Code | Reserved | Link Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Interface Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Interface Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: . . . :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Code | Reserved | Link Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Interface Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Interface Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: :
(etc.)
This is sent as the data-portion of the general packet format described in section 3.4, with the "Message Type" set to HELLO_MESSAGE, the TTL field set to 1 (one) and Vtime set accordingly to the value of NEIGHB_HOLD_TIME, specified in section 18.3.
これは、セクション3.4で説明されている一般的なパケット形式のデータパーティションとして送信され、「メッセージタイプ」がhello_messageに設定され、TTLフィールドは1（1）に設定され、vighb_hold_timeの値にそれに応じて設定されています。18.3。
Reserved
予約済み
This field must be set to "0000000000000" to be in compliance with this specification.
この仕様に準拠するには、このフィールドを「0000000000000」に設定する必要があります。
HTime
htime
This field specifies the HELLO emission interval used by the node on this particular interface, i.e., the time before the transmission of the next HELLO (this information may be used in advanced link sensing, see section 14). The HELLO emission interval is represented by its mantissa (four highest bits of Htime field) and by its exponent (four lowest bits of Htime field). In other words:
このフィールドは、この特定のインターフェイスでノードで使用されるハロー排出間隔、つまり次のhelloの送信前の時刻を指定します（この情報は、高度なリンクセンシングで使用できます。セクション14を参照）。Hello Emission間隔は、Mantissa（Hime Fieldの4つのビット）とその指数（HITEフィールドの4つの最低ビット）によって表されます。言い換えると：
HELLO emission interval=C*(1+a/16)*2^b [in seconds]
where a is the integer represented by the four highest bits of Htime field and b the integer represented by the four lowest bits of Htime field. The proposed value of the scaling factor C is specified in section 18.
ここで、aはhtimeフィールドの4つの最高ビットで表される整数とbで、bはhimeフィールドの4つの最低ビットで表される整数です。スケーリング係数Cの提案値は、セクション18で指定されています。
Willingness
意欲
This field specifies the willingness of a node to carry and forward traffic for other nodes.
このフィールドは、他のノードのトラフィックを掲載および転送するためのノードの意欲を指定します。
A node with willingness WILL_NEVER (see section 18.8, for willingness constants) MUST never be selected as MPR by any node. A node with willingness WILL_ALWAYS MUST always be selected as MPR. By default, a node SHOULD advertise a willingness of WILL_DEFAULT.
意欲のあるノードwill_never（意欲定数についてはセクション18.8を参照）は、任意のノードでMPRとして選択してはなりません。意欲のあるノードは、常にMPRとして選択する必要があります。デフォルトでは、ノードはwill_defaultの意欲を宣伝する必要があります。
Link Code
リンクコード
This field specifies information about the link between the interface of the sender and the following list of neighbor interfaces. It also specifies information about the status of the neighbor.
このフィールドは、送信者のインターフェイスと隣接インターフェイスの次のリストとの間のリンクに関する情報を指定します。また、隣人のステータスに関する情報も指定します。
Link codes, not known by a node, are silently discarded.
ノードで知られていないリンクコードは、静かに破棄されます。
Link Message Size
メッセージのサイズをリンクします
The size of the link message, counted in bytes and measured from the beginning of the "Link Code" field and until the next "Link Code" field (or - if there are no more link types - the end of the message).
リンクメッセージのサイズは、バイトでカウントされ、「リンクコード」フィールドの先頭から測定され、次の「リンクコード」フィールド（または - リンクタイプがない場合 - メッセージの終わり）まで測定されます。
Neighbor Interface Address
近隣インターフェイスアドレス
The address of an interface of a neighbor node.
近隣ノードのインターフェイスのアドレス。
This document only specifies processing of Link Codes < 16.
このドキュメントは、リンクコード<16の処理のみを指定します。
If the Link Code value is less than or equal to 15, then it MUST be interpreted as holding two different fields, of two bits each:
リンクコード値が15以下の場合、それぞれ2つのビットの2つの異なるフィールドを保持していると解釈する必要があります。
7 6 5 4 3 2 1 0
+-------+-------+-------+-------+-------+-------+-------+-------+
| 0 | 0 | 0 | 0 | Neighbor Type | Link Type |
+-------+-------+-------+-------+-------+-------+-------+-------+
The following four "Link Types" are REQUIRED by OLSR:
次の4つの「リンクタイプ」がOLSRによって必要です。
- UNSPEC_LINK - indicating that no specific information about the links is given.
- unspec_link-リンクに関する特定の情報が与えられていないことを示します。
- ASYM_LINK - indicating that the links are asymmetric (i.e., the neighbor interface is "heard").
- asym_link-リンクが非対称であることを示します（つまり、隣接インターフェイスは「聞こえる」）。
- SYM_LINK - indicating that the links are symmetric with the interface.
- sym_link-リンクがインターフェイスと対称であることを示します。
- LOST_LINK - indicating that the links have been lost.
- lost_link-リンクが失われたことを示します。
The following three "Neighbor Types" are REQUIRED by OLSR:
次の3つの「隣接タイプ」はOLSRによって必要です。
- SYM_NEIGH - indicating that the neighbors have at least one symmetrical link with this node.
- Sym_neigh-隣人がこのノードと少なくとも1つの対称リンクを持っていることを示します。
- MPR_NEIGH - indicating that the neighbors have at least one symmetrical link AND have been selected as MPR by the sender.
- MPR_NEIGH-隣人が少なくとも1つの対称リンクを持ち、送信者によってMPRとして選択されていることを示します。
- NOT_NEIGH - indicating that the nodes are either no longer or have not yet become symmetric neighbors.
- not_neigh-ノードがもはや対称的な隣人になっていないか、まだ対称的な隣接になっていないことを示します。
Note that an implementation should be careful in confusing neither Link Type with Neighbor Type nor the constants (confusing SYM_NEIGH with SYM_LINK for instance).
リンクタイプと隣接タイプと定数と混同しないことには、実装が注意する必要があることに注意してください（たとえば、sym_neighとsym_neighを混乱させます）。
A link code advertising:
リンクコード広告：
Link Type == SYM_LINK AND
リンクタイプ== sym_linkおよび
Neighbor Type == NOT_NEIGH
ネイバータイプ== not_neigh
is invalid, and any links advertised as such MUST be silently discarded without any processing.
無効であり、そのように宣伝されているリンクは、処理なしで静かに破棄する必要があります。
Likewise a Neighbor Type field advertising a numerical value which is not one of the constants SYM_NEIGH, MPR_NEIGH, NOT_NEIGH, is invalid, and any links advertised as such MUST be silently discarded without any processing.
同様に、定数Sym_neighの1つではない数値を宣伝する近隣型フィールドは、mpr_neigh、not_neigh、Not_neighが無効であり、そのように宣伝されているリンクは、処理なしで静かに破棄する必要があります。
This involves transmitting the Link Set, the Neighbor Set and the MPR Set. In principle, a HELLO message serves three independent tasks:
これには、リンクセット、隣接セット、MPRセットの送信が含まれます。原則として、Helloメッセージは3つの独立したタスクを提供します。
- link sensing
- リンクセンシング
- neighbor detection
- 隣人の検出
- MPR selection signaling
- MPR選択シグナル伝達
Three tasks are all are based on periodic information exchange within a nodes neighborhood, and serve the common purpose of "local topology discovery". A HELLO message is therefore generated based on the information stored in the Local Link Set, the Neighbor Set and the MPR Set from the local link information base.
3つのタスクはすべて、ノード近隣内の定期的な情報交換に基づいており、「ローカルトポロジの発見」の一般的な目的を果たしています。したがって、Helloメッセージは、ローカルリンクセット、neighterセット、およびローカルリンク情報ベースのMPRセットに保存されている情報に基づいて生成されます。
A node must perform link sensing on each interface, in order to detect links between the interface and neighbor interfaces. Furthermore, a node must advertise its entire symmetric 1-hop neighborhood on each interface in order to perform neighbor detection. Hence, for a given interface, a HELLO message will contain a list of links on that interface (with associated link types), as well as a list of the entire neighborhood (with an associated neighbor types).
インターフェイスと隣のインターフェイス間のリンクを検出するために、ノードは各インターフェイスでリンクセンシングを実行する必要があります。さらに、ノードは、隣接検出を実行するために、各インターフェイスに対称1ホップ周辺全体を宣伝する必要があります。したがって、特定のインターフェイスの場合、Helloメッセージには、そのインターフェイス（関連するリンクタイプを使用）のリンクのリストと、近隣全体のリスト（関連する近隣型）が含まれます。
The Vtime field is set such that it corresponds to the value of the node's NEIGHB_HOLD_TIME parameter. The Htime field is set such that it corresponds to the value of the node's HELLO_INTERVAL parameter (see section 18.3).
vtimeフィールドは、ノードのneighb_hold_timeパラメーターの値に対応するように設定されています。HTIMEフィールドは、ノードのhello_intervalパラメーターの値に対応するように設定されています（セクション18.3を参照）。
The Willingness field is set such that it corresponds to the node's willingness to forward traffic on behalf of other nodes (see section 18.8). A node MUST advertise the same willingness on all interfaces.
意欲のフィールドは、他のノードに代わってトラフィックを転送するノードの意欲に対応するように設定されています（セクション18.8を参照）。ノードは、すべてのインターフェイスで同じ意欲を宣伝する必要があります。
The lists of addresses declared in a HELLO message is a list of neighbor interface addresses computed as follows:
Helloメッセージで宣言されたアドレスのリストは、次のように計算された近隣インターフェイスアドレスのリストです。
For each tuple in the Link Set, where L_local_iface_addr is the interface where the HELLO is to be transmitted, and where L_time >= current time (i.e., not expired), L_neighbor_iface_addr is advertised with:
L_LOCAL_IFACE_ADDRは、リンクセットの各タプルについて、Helloが送信されるインターフェイスであり、L_TIME> =現在の時間（つまり、期限切れではない）、L_Neighbor_iface_addrは次のように宣伝されます。
1 The Link Type set according to the following:
1以下に従って設定されたリンクタイプ：
1.1 if L_SYM_time >= current time (not expired)
1.1 l_sym_time> =現在の時間（期限切れではない）
Link Type = SYM_LINK
リンクタイプ= sym_link
1.2 Otherwise, if L_ASYM_time >= current time (not expired) AND
1.2 それ以外の場合、l_asym_time> =現在の時間（期限切れ）と
L_SYM_time < current time (expired)
l_sym_time <現在の時間（期限切れ）
Link Type = ASYM_LINK
リンクタイプ= asym_link
1.3 Otherwise, if L_ASYM_time < current time (expired) AND
1.3 それ以外の場合、l_asym_time <current time（expired）と
L_SYM_time < current time (expired)
l_sym_time <現在の時間（期限切れ）
Link Type = LOST_LINK
リンクタイプ= lost_link
2 The Neighbor Type is set according to the following:
2ネイバータイプは次のことに従って設定されています。
2.1 If the main address, corresponding to L_neighbor_iface_addr, is included in the MPR set:
2.1 l_neighbor_iface_addrに対応するメインアドレスがMPRセットに含まれている場合：
Neighbor Type = MPR_NEIGH
隣人タイプ= mpr_neigh
2.2 Otherwise, if the main address, corresponding to L_neighbor_iface_addr, is included in the neighbor set:
2.2 それ以外の場合、l_neighbor_iface_addrに対応するメインアドレスが近隣セットに含まれている場合：
2.2.1 if N_status == SYM
2.2.1 n_status == sym
Neighbor Type = SYM_NEIGH
ネイバータイプ= sym_neigh
2.2.2 Otherwise, if N_status == NOT_SYM Neighbor Type = NOT_NEIGH
2.2.2 それ以外の場合、n_status == not_sym neighlet type = not_neighの場合
For each tuple in the Neighbor Set, for which no L_neighbor_iface_addr from an associated link tuple has been advertised by the previous algorithm, N_neighbor_main_addr is advertised with:
ネイバーセットの各タプルについて、関連するリンクのタプルからのl_neighbor_iface_addrは以前のアルゴリズムによって宣伝されていません。N_NEIGHBOR_MAIN_ADDRは次のように宣伝されています。
- Link Type = UNSPEC_LINK,
- リンクタイプ= unspec_link、
- Neighbor Type set as described in step 2 above
- 上記のステップ2に記載されているように、隣接タイプセット
For a node with a single OLSR interface, the main address is simply the address of the OLSR interface, i.e., for a node with a single OLSR interface the main address, corresponding to L_neighbor_iface_addr is simply L_neighbor_iface_addr.
単一のOLSRインターフェイスを持つノードの場合、メインアドレスは単にOLSRインターフェイスのアドレスです。つまり、単一のOLSRインターフェイスを持つノードの場合、l_neighbor_iface_addrに対応するメインアドレスはl_neighbor_iface_addrです。
A HELLO message can be partial (e.g., due to message size limitations, imposed by the network), the rule being the following, on each interface: each link and each neighbor node MUST be cited at least once within a predetermined refreshing period, REFRESH_INTERVAL. To keep track of fast connectivity changes, a HELLO message must be sent at least every HELLO_INTERVAL period, smaller than or equal to REFRESH_INTERVAL.
ハローメッセージは部分的になります（例：メッセージサイズの制限により、ネットワークによって課されます）、各インターフェイスでルールは次のとおりです。各リンクと各ネイバーノードは、事前に決められた更新期間で少なくとも1回引用する必要があります。。高速の接続の変更を追跡するには、helloメッセージを少なくともすべてのhello_interval期間をrepread_intervalよりも小さいhello_interval期間ごとに送信する必要があります。
Notice that for limiting the impact from loss of control messages, it is desirable that a message (plus the generic packet header) can fit into a single MAC frame.
コントロールメッセージの喪失による影響を制限するために、メッセージ（および一般的なパケットヘッダー）が単一のMacフレームに適合できることが望ましいことに注意してください。
Each HELLO message generated is broadcast by the node on one interface to its neighbors (i.e. the interface for which the HELLO was generated). HELLO messages MUST never be forwarded.
生成された各helloメッセージは、1つのインターフェイスでノードによって近隣（つまり、helloが生成されたインターフェイス）にブロードキャストされます。こんにちはメッセージを転送してはいけません。
A node processes incoming HELLO messages for the purpose of conducting link sensing (detailed in section 7), neighbor detection and MPR selector set population (detailed in section 8)
リンクセンシング（セクション7で詳細）、隣接検出、およびMPRセレクターセット母集団（セクション8で詳細）を実行する目的で、着信ハローメッセージを処理するノード
Link sensing populates the local link information base. Link sensing is exclusively concerned with OLSR interface addresses and the ability to exchange packets between such OLSR interfaces.
リンクSENSINGは、ローカルリンク情報ベースに入力されます。Link Sensingは、OLSRインターフェイスアドレスと、そのようなOLSRインターフェイス間でパケットを交換する機能にのみ関与しています。
The mechanism for link sensing is the periodic exchange of HELLO messages.
リンクセンシングのメカニズムは、ハローメッセージの周期的な交換です。
The Link Set is populated with information on links to neighbor nodes. The process of populating this set is denoted "link sensing" and is performed using HELLO message exchange, updating a local link information base in each node.
リンクセットには、ネイバーノードへのリンクに関する情報が入力されています。このセットに浸透するプロセスは「リンクセンシング」と表示され、Hello Message Exchangeを使用して実行され、各ノードのローカルリンク情報ベースを更新します。
Each node should detect the links between itself and neighbor nodes. Uncertainties over radio propagation may make some links unidirectional. Consequently, all links MUST be checked in both directions in order to be considered valid.
各ノードは、それ自体と近隣ノードの間のリンクを検出する必要があります。無線伝播に関する不確実性は、いくつかのリンクを一方向にする可能性があります。したがって、有効と見なされるためには、すべてのリンクを両方向にチェックする必要があります。
A "link" is described by a pair of interfaces: a local and a remote interface.
「リンク」は、一対のインターフェイスで説明されています。ローカルとリモートのインターフェイスです。
For the purpose of link sensing, each neighbor node (more specifically, the link to each neighbor) has an associated status of either "symmetric" or "asymmetric". "Symmetric" indicates, that the link to that neighbor node has been verified to be bi-directional, i.e., it is possible to transmit data in both directions. "Asymmetric" indicates that HELLO messages from the node have been heard (i.e., communication from the neighbor node is possible), however it is not confirmed that this node is also able to receive messages (i.e., communication to the neighbor node is not confirmed).
Link Sensingの目的のために、各近隣ノード（より具体的には、各近隣へのリンク）には、「対称」または「非対称」のいずれかの関連状態があります。「対称」は、その隣接ノードへのリンクが双方向であることが確認されていることを示しています。つまり、両方向にデータを送信することが可能です。「非対称」は、ノードからのハローメッセージが聞こえたことを示しています（つまり、近隣ノードからの通信が可能です）が、このノードがメッセージを受信できることも確認されていません（つまり、近隣ノードへの通信が確認されていません）。
The information, acquired through and used by the link sensing, is accumulated in the link set.
リンクセンシングで取得し、使用される情報は、リンクセットに蓄積されます。
The "Originator Address" of a HELLO message is the main address of the node, which has emitted the message.
Helloメッセージの「オリジネーターアドレス」は、ノードのメインアドレスであり、メッセージを放出しました。
Upon receiving a HELLO message, a node SHOULD update its Link Set. Notice, that a HELLO message MUST neither be forwarded nor be recorded in the duplicate set.
ハローメッセージを受信すると、ノードはリンクセットを更新する必要があります。Helloメッセージは、重複セットに転送されたり、記録されたりしてはならないことに注意してください。
Upon receiving a HELLO message, the "validity time" MUST be computed from the Vtime field of the message header (see section 3.3.2). Then, the Link Set SHOULD be updated as follows:
ハローメッセージを受信すると、「有効性時間」はメッセージヘッダーのvtimeフィールドから計算する必要があります（セクション3.3.2を参照）。次に、リンクセットを次のように更新する必要があります。
1 Upon receiving a HELLO message, if there exists no link tuple with
1ハローメッセージを受信すると、リンクのタプルが存在しない場合
L_neighbor_iface_addr == Source Address
l_neighbor_iface_addr ==ソースアドレス
a new tuple is created with
新しいタプルが作成されます
L_neighbor_iface_addr = Source Address
L_local_iface_addr = Address of the interface which received the HELLO message
l_local_iface_addr =ハローメッセージを受信したインターフェイスのアドレス
L_SYM_time = current time - 1 (expired)
l_sym_time =現在の時間-1（期限切れ）
L_time = current time + validity time
L_TIME =現在の時間妥当性時間
2 The tuple (existing or new) with:
2タプル（既存または新しい）：
L_neighbor_iface_addr == Source Address
l_neighbor_iface_addr ==ソースアドレス
is then modified as follows:
次に、次のように変更されます。
2.1 L_ASYM_time = current time + validity time;
2.2 if the node finds the address of the interface which received the HELLO message among the addresses listed in the link message then the tuple is modified as follows: 2.2.1 if Link Type is equal to LOST_LINK then
2.2 ノードがリンクメッセージにリストされているアドレスの間でハローメッセージを受信したインターフェイスのアドレスを見つけた場合、タプルは次のように変更されます：2.2.1リンクタイプがlost_linkに等しい場合then
L_SYM_time = current time - 1 (i.e., expired)
l_sym_time =現在の時間-1（すなわち、期限切れ）
2.2.2 else if Link Type is equal to SYM_LINK or ASYM_LINK then
2.2.2 それ以外の場合は、リンクタイプがsym_linkまたはasym_linkに等しい場合、
L_SYM_time = current time + validity time,
l_sym_time =現在の時間妥当性時間、
L_time = L_SYM_time + NEIGHB_HOLD_TIME
l_time = l_sym_time neighb_hold_time
2.3 L_time = max(L_time, L_ASYM_time)
2.3 l_time = max（l_time、l_asym_time）
The above rule for setting L_time is the following: a link losing its symmetry SHOULD still be advertised during at least the duration of the "validity time" advertised in the generated HELLO. This allows neighbors to detect the link breakage.
L_TIMEの設定に関する上記のルールは次のとおりです。その対称性を失うリンクは、少なくとも生成されたHelloで宣伝されている「有効性時間」の期間中に宣伝する必要があります。これにより、隣人はリンクの破損を検出できます。
Neighbor detection populates the neighborhood information base and concerns itself with nodes and node main addresses. The relationship between OLSR interface addresses and main addresses is described in section 5.
近隣検出は、近隣の情報ベースに浸透し、ノードとノードのメインアドレスに関係しています。OLSRインターフェイスアドレスとメインアドレスの関係については、セクション5で説明します。
The mechanism for neighbor detection is the periodic exchange of HELLO messages.
隣接検出のメカニズムは、Helloメッセージの周期的な交換です。
A node maintains a set of neighbor tuples, based on the link tuples. This information is updated according to changes in the Link Set.
ノードは、リンクタプルに基づいて、隣接タプルのセットを維持します。この情報は、リンクセットの変更に従って更新されます。
The Link Set keeps the information about the links, while the Neighbor Set keeps the information about the neighbors. There is a clear association between those two sets, since a node is a neighbor of another node if and only if there is at least one link between the two nodes.
リンクセットはリンクに関する情報を保持し、隣人セットは隣人に関する情報を保持します。2つのノードの間に少なくとも1つのリンクがある場合にのみ、ノードは別のノードのネイバーであるため、これらの2つのセットには明確な関連性があります。
In any case, the formal correspondence between links and neighbors is defined as follows:
いずれにせよ、リンクと隣人の間の正式な対応は次のように定義されます。
The "associated neighbor tuple" of a link tuple, is, if it exists, the neighbor tuple where:
リンクのタプルの「関連する隣人のタプル」は、それが存在する場合、隣人のタプルです。
N_neighbor_main_addr == main address of L_neighbor_iface_addr
n_neighbor_main_addr == l_neighbor_iface_addrのメインアドレス
The "associated link tuples" of a neighbor tuple, are all the link tuples, where:
隣人のタプルの「関連するリンクタプル」は、すべてリンクのタプルです。
N_neighbor_main_addr == main address of L_neighbor_iface_addr
n_neighbor_main_addr == l_neighbor_iface_addrのメインアドレス
The Neighbor Set MUST be populated by maintaining the proper correspondence between link tuples and associated neighbor tuples, as follows:
隣人セットは、次のように、リンクタプルと関連する隣人のタプルとの間の適切な対応を維持することにより、次のように入力する必要があります。
Creation
創造
Each time a link appears, that is, each time a link tuple is created, the associated neighbor tuple MUST be created, if it doesn't already exist, with the following values:
リンクが表示されるたびに、つまり、リンクタプルが作成されるたびに、関連する隣のタプルを作成する必要があります。
N_neighbor_main_addr = main address of L_neighbor_iface_addr (from the link tuple)
n_neighbor_main_addr = l_neighbor_iface_addrのメインアドレス（リンクtupleから）
In any case, the N_status MUST then be computed as described in the next step
いずれにせよ、次のステップで説明されているように、N_STATUSを計算する必要があります
Update
アップデート
Each time a link changes, that is, each time the information of a link tuple is modified, the node MUST ensure that the N_status of the associated neighbor tuple respects the property:
リンクが変更されるたびに、つまりリンクタプルの情報が変更されるたびに、ノードは、関連する隣のタプルのn_statusがプロパティを尊重することを確認する必要があります。
If the neighbor has any associated link tuple which indicates a symmetric link (i.e., with L_SYM_time >= current time), then
隣人が対称リンクを示す関連リンクタプルを持っている場合（つまり、l_sym_time> =現在の時刻）、次に、
N_status is set to SYM
n_statusはsymに設定されています
else N_status is set to NOT_SYM
それ以外の場合、n_statusはnot_symに設定されています
Removal
除去
Each time a link is deleted, that is, each time a link tuple is removed, the associated neighbor tuple MUST be removed if it has no longer any associated link tuples.
リンクが削除されるたびに、つまりリンクタプルが削除されるたびに、関連するリンクタプルがない場合は、関連する隣のタプルを削除する必要があります。
These rules ensure that there is exactly one associated neighbor tuple for a link tuple, and that every neighbor tuple has at least one associated link tuple.
これらのルールにより、リンクタプルに関連する隣接タプルが1つあり、すべての隣のタプルに少なくとも1つの関連リンクタプルがあることが保証されます。
The "Originator Address" of a HELLO message is the main address of the node, which has emitted the message. Likewise, the "willingness" MUST be computed from the Willingness field of the HELLO message (see section 6.1).
Helloメッセージの「オリジネーターアドレス」は、ノードのメインアドレスであり、メッセージを放出しました。同様に、「意欲」は、Helloメッセージの意欲の分野から計算する必要があります（セクション6.1を参照）。
Upon receiving a HELLO message, a node SHOULD first update its Link Set as described before. It SHOULD then update its Neighbor Set as follows:
ハローメッセージを受信したら、ノードは最初に前述のようにリンクセットを更新する必要があります。次に、次のように近隣セットを更新する必要があります。
- if the Originator Address is the N_neighbor_main_addr from a neighbor tuple included in the Neighbor Set:
- Originatorアドレスが隣人セットに含まれる隣人のタプルからのN_NEIGHBOR_MAIN_ADDRである場合：
then, the neighbor tuple SHOULD be updated as follows:
次に、隣人のタプルを次のように更新する必要があります。
N_willingness = willingness from the HELLO message
The 2-hop neighbor set describes the set of nodes which have a symmetric link to a symmetric neighbor. This information set is maintained through periodic exchange of HELLO messages as described in this section.
2ホップネイバーセットは、対称隣人への対称リンクを持つノードのセットについて説明します。この情報セットは、このセクションで説明されているように、Helloメッセージの定期的な交換を通じて維持されます。
The "Originator Address" of a HELLO message is the main address of the node, which has emitted the message.
Helloメッセージの「オリジネーターアドレス」は、ノードのメインアドレスであり、メッセージを放出しました。
Upon receiving a HELLO message from a symmetric neighbor, a node SHOULD update its 2-hop Neighbor Set. Notice, that a HELLO message MUST neither be forwarded nor be recorded in the duplicate set.
対称隣人からハローメッセージを受信すると、ノードは2ホップの隣人セットを更新する必要があります。Helloメッセージは、重複セットに転送されたり、記録されたりしてはならないことに注意してください。
Upon receiving a HELLO message, the "validity time" MUST be computed from the Vtime field of the message header (see section 3.3.2).
ハローメッセージを受信すると、「有効性時間」はメッセージヘッダーのvtimeフィールドから計算する必要があります（セクション3.3.2を参照）。
If the Originator Address is the main address of a L_neighbor_iface_addr from a link tuple included in the Link Set with
オリジネーターアドレスが、リンクセットに含まれるリンクタプルからのl_neighbor_iface_addrのメインアドレスである場合
L_SYM_time >= current time (not expired)
l_sym_time> =現在の時間（期限切れ）
(in other words: if the Originator Address is a symmetric neighbor) then the 2-hop Neighbor Set SHOULD be updated as follows:
（言い換えれば、オリジネーターアドレスが対称隣接している場合）2ホップネイバーセットは次のように更新する必要があります。
1 for each address (henceforth: 2-hop neighbor address), listed in the HELLO message with Neighbor Type equal to SYM_NEIGH or MPR_NEIGH:
1各アドレスに対して1（以降：2-HOP Neighborアドレス）、sym_neighまたはmpr_neighに等しい隣人タイプを持つハローメッセージにリストされています：
1.1 if the main address of the 2-hop neighbor address = main address of the receiving node:
1.1 2ホップネイバーアドレスのメインアドレス=受信ノードのメインアドレスの場合：
silently discard the 2-hop neighbor address.
2ホップの隣人アドレスを静かに捨てます。
(in other words: a node is not its own 2-hop neighbor).
（言い換えれば、ノードは独自の2ホップの隣人ではありません）。
1.2 Otherwise, a 2-hop tuple is created with:
1.2 それ以外の場合、2ホップのタプルが作成されます。
N_neighbor_main_addr = Originator Address;
n_neighbor_main_addr = originatorアドレス;
N_2hop_addr = main address of the 2-hop neighbor;
N_2HOP_ADDR = 2ホップ隣人のメインアドレス。
N_time = current time + validity time.
n_time =現在の時間妥当性時間。
This tuple may replace an older similar tuple with same N_neighbor_main_addr and N_2hop_addr values.
このタプルは、古い類似のタプルを同じn_neighbor_main_addrおよびn_2hop_addr値に置き換えることができます。
2 For each 2-hop node listed in the HELLO message with Neighbor Type equal to NOT_NEIGH, all 2-hop tuples where:
2 not_neighに等しい近隣タイプを持つハローメッセージにリストされている2ホップノードごとに2、すべての2ホップタプル場所：
N_neighbor_main_addr == Originator Address AND
n_neighbor_main_addr ==オリジナルアドレスと
N_2hop_addr == main address of the 2-hop neighbor
N_2HOP_ADDR == 2ホップ隣人のメインアドレス
are deleted.
削除されます。
MPRs are used to flood control messages from a node into the network while reducing the number of retransmissions that will occur in a region. Thus, the concept of MPR is an optimization of a classical flooding mechanism.
MPRは、ノードからネットワークへのメッセージをflood濫させるために使用され、地域で発生する再送信の数を減らします。したがって、MPRの概念は、古典的な洪水メカニズムの最適化です。
Each node in the network selects, independently, its own set of MPRs among its symmetric 1-hop neighborhood. The symmetric links with MPRs are advertised with Link Type MPR_NEIGH instead of SYM_NEIGH in HELLO messages.
ネットワーク内の各ノードは、独立して独自のMPRのセットを、対称1ホップ近傍の中から選択します。MPRSとの対称リンクは、HelloメッセージのSym_neighの代わりに、リンクタイプmpr_neighで宣伝されます。
The MPR set MUST be calculated by a node in such a way that it, through the neighbors in the MPR-set, can reach all symmetric strict 2-hop neighbors. (Notice that a node, a, which is a direct neighbor of another node, b, is not also a strict 2-hop neighbor of node b). This means that the union of the symmetric 1-hop neighborhoods of the MPR nodes contains the symmetric strict 2-hop neighborhood. MPR set recalculation should occur when changes are detected in the symmetric neighborhood or in the symmetric strict 2-hop neighborhood.
MPRセットは、MPRセットの隣人を介して、すべての対称的な厳密な2ホップネイバーに到達できるように、ノードによって計算する必要があります。（別のノードbの直接隣のノードaは、ノードbの厳密な2ホップ隣人ではないことに注意してください）。これは、MPRノードの対称1ホップ近傍の結合に、対称的な厳密な2ホップ近傍が含まれていることを意味します。MPR SETの再計算は、対称近隣または対称的な厳密な2ホップ近隣で変更が検出されたときに発生する必要があります。
MPRs are computed per interface, the union of the MPR sets of each interface make up the MPR set for the node.
MPRはインターフェイスごとに計算されます。各インターフェイスのMPRセットの結合は、ノードのMPRセットを構成します。
While it is not essential that the MPR set is minimal, it is essential that all strict 2-hop neighbors can be reached through the selected MPR nodes. A node SHOULD select an MPR set such that any strict 2-hop neighbor is covered by at least one MPR node. Keeping the MPR set small ensures that the overhead of the protocol is kept at a minimum.
MPRセットが最小限であることは不可欠ではありませんが、選択したMPRノードを介してすべての厳密な2ホップ近隣に到達できることが不可欠です。ノードは、厳密な2ホップ隣接が少なくとも1つのMPRノードでカバーされるように、MPRセットを選択する必要があります。MPRセットを小さく保つと、プロトコルのオーバーヘッドが最小限に抑えることが保証されます。
The MPR set can coincide with the entire symmetric neighbor set. This could be the case at network initialization (and will correspond to classic link-state routing).
MPRセットは、対称隣接セット全体と一致する可能性があります。これは、ネットワークの初期化の場合になる可能性があります（そして、クラシックリンク状態のルーティングに対応します）。
The following specifies a proposed heuristic for selection of MPRs. It constructs an MPR-set that enables a node to reach any node in the symmetrical strict 2-hop neighborhood through relaying by one MPR node with willingness different from WILL_NEVER. The heuristic MUST be applied per interface, I. The MPR set for a node is the union of the MPR sets found for each interface. The following terminology will be used in describing the heuristics:
以下は、MPRを選択するための提案されたヒューリスティックを指定します。will_neverとは異なる意欲を持つ1つのMPRノードで中継することにより、ノードが対称的な厳密な2ホップ近隣の任意のノードに到達できるようにするMPRセットを構築します。ヒューリスティックは、インターフェイスごとに適用する必要があります。NodeのMPRセットは、各インターフェイスで見つかったMPRセットの結合です。次の用語は、ヒューリスティックの説明に使用されます。
neighbor of an interface
インターフェイスの隣人
a node is a "neighbor of an interface" if the interface (on the local node) has a link to any one interface of the neighbor node.
ノードは、（ローカルノード上の）インターフェイスに近隣ノードの1つのインターフェイスへのリンクがある場合、「インターフェイスの隣」です。
2-hop neighbors reachable from an interface
インターフェイスから到達可能な2ホップの隣人
the list of 2-hop neighbors of the node that can be reached from neighbors of this interface.
このインターフェイスの隣人から到達できるノードの2ホップの隣人のリスト。
MPR set of an interface
インターフェイスのMPRセット
a (sub)set of the neighbors of an interface with a willingness different from WILL_NEVER, selected such that through these selected nodes, all strict 2-hop neighbors reachable from that interface are reachable.
will_neverとは異なる意欲を持つインターフェイスの近隣の（サブ）セットは、選択したノードを介して、そのインターフェイスからすべての厳格な2ホップの隣人が到達可能に到達できるように選択します。
N: N is the subset of neighbors of the node, which are neighbor of the interface I.
n：nは、ノードの近隣のサブセットであり、インターフェイスIの隣です。
N2: The set of 2-hop neighbors reachable from the interface I, excluding:
N2：インターフェイスIから到達可能な2ホップの隣人のセット。
(i) the nodes only reachable by members of N with willingness WILL_NEVER
(i) ノードは、nのメンバーが意欲を持って到達可能ですwill_never
(ii) the node performing the computation
（ii）計算を実行するノード
(iii) all the symmetric neighbors: the nodes for which there exists a symmetric link to this node on some interface.
（iii）すべての対称隣接：あるインターフェイスにこのノードへの対称リンクが存在するノード。
D(y): The degree of a 1-hop neighbor node y (where y is a member of N), is defined as the number of symmetric neighbors of node y, EXCLUDING all the members of N and EXCLUDING the node performing the computation.
d（y）：1ホップ隣接ノードy（yはnのメンバー）の程度は、nのすべてのメンバーを除外し、計算を実行するノードを除外して、ノードyの対称隣接の数として定義されます。。
The proposed heuristic is as follows:
提案されたヒューリスティックは次のとおりです。
1 Start with an MPR set made of all members of N with N_willingness equal to WILL_ALWAYS
1 n_willingnessがwill_alwaysに等しく、nのすべてのメンバーで作られたMPRセットから始めます
2 Calculate D(y), where y is a member of N, for all nodes in N.
2 nのすべてのノードについて、yはnのメンバーであるd（y）を計算します。
3 Add to the MPR set those nodes in N, which are the *only* nodes to provide reachability to a node in N2. For example, if node b in N2 can be reached only through a symmetric link to node a in N, then add node a to the MPR set. Remove the nodes from N2 which are now covered by a node in the MPR set.
3 MPRに追加して、nのノードを設定します。これは、N2のノードに到達可能性を提供する *のみ *ノードです。たとえば、N2のノードBにNode Aへの対称リンクを介してNのNode Aへのみ到達できる場合は、MPRセットにノードAを追加します。MPRセットのノードでカバーされるN2からノードを削除します。
4 While there exist nodes in N2 which are not covered by at least one node in the MPR set: 4.1 For each node in N, calculate the reachability, i.e., the number of nodes in N2 which are not yet covered by at least one node in the MPR set, and which are reachable through this 1-hop neighbor;
4 N2には、MPRセットの少なくとも1つのノードでカバーされないN2にノードが存在するが、Nの各ノードの4.1、つまり、少なくとも1つのノードでまだカバーされていないN2のノードの数を計算します。MPRセットでは、この1ホップの隣人を通じて到達可能です。
4.2 Select as a MPR the node with highest N_willingness among the nodes in N with non-zero reachability. In case of multiple choice select the node which provides reachability to the maximum number of nodes in N2. In case of multiple nodes providing the same amount of reachability, select the node as MPR whose D(y) is greater. Remove the nodes from N2 which are now covered by a node in the MPR set.
4.2 MPRとして選択します。NODEがゼロではないN_WILLINGNESのN_WILLINGNESがNのノードの中で最高です。複数選択の場合、N2の最大数のノードにリーチ性を提供するノードを選択します。同じ量の到達可能性を提供する複数のノードの場合、D（y）が大きいMPRとしてノードを選択します。MPRセットのノードでカバーされるN2からノードを削除します。
5 A node's MPR set is generated from the union of the MPR sets for each interface. As an optimization, process each node, y, in the MPR set in increasing order of N_willingness. If all nodes in N2 are still covered by at least one node in the MPR set excluding node y, and if N_willingness of node y is smaller than WILL_ALWAYS, then node y MAY be removed from the MPR set.
5ノードのMPRセットは、各インターフェイスのMPRセットの結合から生成されます。最適化として、n_willingnessの順序で設定されたMPRで各ノードyを処理します。N2のすべてのノードが、ノードYを除くMPRセットの少なくとも1つのノードでまだカバーされている場合、ノードYのn_willingnessがwill_alwaysよりも小さい場合、ノードyはMPRセットから削除される場合があります。
Other algorithms, as well as improvements over this algorithm, are possible. For example, assume that in a multiple-interface scenario there exists more than one link between nodes 'a' and 'b'. If node 'a' has selected node 'b' as MPR for one of its interfaces, then node 'b' can be selected as MPR without additional performance loss by any other interfaces on node 'a'.
他のアルゴリズムと、このアルゴリズムの改善が可能です。たとえば、複数のインターフェイスシナリオには、ノード「A」と「B」の間に複数のリンクが存在すると仮定します。ノード 'A'がそのインターフェイスの1つのMPRとしてノード 'B'を選択した場合、ノード 'B'は、ノード 'A'の他のインターフェイスによって追加のパフォーマンス損失なしにMPRとして選択できます。
The MPR selector set of a node, n, is populated by the main addresses of the nodes which have selected n as MPR. MPR selection is signaled through HELLO messages.
ノードnのMPRセレクターセットには、nをMPRとして選択したノードのメインアドレスが入力されます。MPR選択は、Helloメッセージを通じて通知されます。
Upon receiving a HELLO message, if a node finds one of its own interface addresses in the list with a Neighbor Type equal to MPR_NEIGH, information from the HELLO message must be recorded in the MPR Selector Set.
Helloメッセージを受信すると、ノードがリスト内の独自のインターフェイスアドレスの1つを見つけた場合、MPR_NEIGHに等しい近隣タイプを使用して、Helloメッセージからの情報をMPRセレクターセットに記録する必要があります。
The "validity time" MUST be computed from the Vtime field of the message header (see section 3.3.2). The MPR Selector Set SHOULD then be updated as follows:
「有効性時間」は、メッセージヘッダーのvtimeフィールドから計算する必要があります（セクション3.3.2を参照）。次に、MPRセレクターセットを次のように更新する必要があります。
1 If there exists no MPR selector tuple with:
1存在する場合、MPRセレクタータプルは次のとおりです。
MS_main_addr == Originator Address
MS_MAIN_ADDR ==オリジナルアドレス
then a new tuple is created with:
次に、新しいタプルが作成されます。
MS_main_addr = Originator Address
2 The tuple (new or otherwise) with
2タプル（新規またはその他）
MS_main_addr == Originator Address
MS_MAIN_ADDR ==オリジナルアドレス
is then modified as follows:
次に、次のように変更されます。
MS_time = current time + validity time.
MS_TIME =現在の時間妥当性時間。
Deletion of MPR selector tuples occurs in case of expiration of the timer or in case of link breakage as described in the "Neighborhood and 2-hop Neighborhood Changes".
MPRセレクタータプルの削除は、タイマーの有効期限が切れた場合、または「近隣および2ホップ近隣の変更」で説明されているように、リンクの破損の場合に発生します。
A change in the neighborhood is detected when:
近隣の変更は、次の場合に検出されます。
- The L_SYM_time field of a link tuple expires. This is considered as a neighbor loss if the link described by the expired tuple was the last link with a neighbor node (on the contrary, a link with an interface may break while a link with another interface of the neighbor node remains without being observed as a neighborhood change).
- リンクタプルのL_SYM_TIMEフィールドが期限切れになります。これは、期限切れのタプルで説明されているリンクが近隣ノードとの最後のリンクである場合、隣接の損失と見なされます（それどころか、インターフェイスとのリンクが破損する可能性がありますが、隣接ノードの別のインターフェイスとのリンクは、としては観察されずに残ります。近所の変更）。
- A new link tuple is inserted in the Link Set with a non expired L_SYM_time or a tuple with expired L_SYM_time is modified so that L_SYM_time becomes non-expired. This is considered as a neighbor appearance if there was previously no link tuple describing a link with the corresponding neighbor node.
- 新しいリンクタプルは、有効期限が切れたL_SYM_TIMEでリンクセットに挿入されているか、L_SYM_TIMEが拡張されないように、有効期限が切れたL_SYM_TIMEを備えたタプルが変更されます。これは、以前に対応する隣接ノードとのリンクを説明するリンクタプルがなかった場合、隣接の外観と見なされます。
A change in the 2-hop neighborhood is detected when a 2-hop neighbor tuple expires or is deleted according to section 8.2.
2ホップの近隣のタプルの有効期限が切れるか、セクション8.2に従って削除されたときに、2ホップ近隣の変更が検出されます。
The following processing occurs when changes in the neighborhood or the 2-hop neighborhood are detected:
次の処理は、近隣または2ホップ近隣の変更が検出されたときに発生します。
- In case of neighbor loss, all 2-hop tuples with N_neighbor_main_addr == Main Address of the neighbor MUST be deleted.
- 隣人の損失の場合、N_NEIGHBOR_MAIN_ADDR ==隣人のメインアドレスを持つすべての2ホップのタプルを削除する必要があります。
- In case of neighbor loss, all MPR selector tuples with MS_main_addr == Main Address of the neighbor MUST be deleted
- 隣人の損失の場合、すべてのMPRセレクターがMS_MAIN_ADDR ==隣人のメインアドレスを削除する必要があります
- The MPR set MUST be re-calculated when a neighbor appearance or loss is detected, or when a change in the 2-hop neighborhood is detected.
- MPRセットは、隣人の外観または損失が検出されたとき、または2ホップ近隣の変更が検出されたときに再計算する必要があります。
- An additional HELLO message MAY be sent when the MPR set changes.
- MPRセットが変更されると、追加のハローメッセージが送信される場合があります。
The link sensing and neighbor detection part of the protocol basically offers, to each node, a list of neighbors with which it can communicate directly and, in combination with the Packet Format and Forwarding part, an optimized flooding mechanism through MPRs. Based on this, topology information is disseminated through the network. The present section describes which part of the information given by the link sensing and neighbor detection is disseminated to the entire network and how it is used to construct routes.
プロトコルのリンク検知と隣接の検出部分は、基本的に、各ノードに、直接通信できる近隣のリストを提供し、パケット形式と転送部分と組み合わせて、MPRを通じて最適化された洪水メカニズムを提供します。これに基づいて、トポロジー情報はネットワークを介して普及しています。本セクションでは、リンクセンシングと隣人検出によって与えられた情報のどの部分がネットワーク全体に広がっているか、およびそれがルートの構築にどのように使用されるかについて説明します。
Routes are constructed through advertised links and links with neighbors. A node must at least disseminate links between itself and the nodes in its MPR-selector set, in order to provide sufficient information to enable routing.
ルートは、広告されたリンクと隣人とのリンクを通じて構築されます。ノードは、ルーティングを有効にするために十分な情報を提供するために、少なくともそれ自体とMPRセレクターセットのノードとの間にリンクを広める必要があります。
The proposed format of a TC message is as follows:
TCメッセージの提案された形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ANSN | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertised Neighbor Main Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertised Neighbor Main Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This is sent as the data-portion of the general message format with the "Message Type" set to TC_MESSAGE. The time to live SHOULD be set to 255 (maximum value) to diffuse the message into the entire network and Vtime set accordingly to the value of TOP_HOLD_TIME, as specified in section 18.3.
これは、TC_Messageに設定された「メッセージタイプ」を使用して、一般的なメッセージ形式のデータパーティションとして送信されます。セクション18.3で指定されているように、ライブ時間は255（最大値）に設定して、メッセージをネットワーク全体に拡散させ、それに応じてTOP_HOLD_TIMEの値にそれに応じて設定されたVTIMEに設定する必要があります。
Advertised Neighbor Sequence Number (ANSN)
宣伝されたネイバーシーケンス番号（ANSN）
A sequence number is associated with the advertised neighbor set. Every time a node detects a change in its advertised neighbor set, it increments this sequence number ("Wraparound" is handled as described in section 19). This number is sent in this ANSN field of the TC message to keep track of the most recent information. When a node receives a TC message, it can decide on the basis of this Advertised Neighbor Sequence Number, whether or not the received information about the advertised neighbors of the originator node is more recent than what it already has.
シーケンス番号は、広告されたネイバーセットに関連付けられています。ノードが広告された近隣セットの変更を検出するたびに、このシーケンス番号を増加させます（「ラップアラウンド」はセクション19で説明されているように処理されます）。この番号は、最新の情報を追跡するためにTCメッセージのこのANSNフィールドに送信されます。ノードがTCメッセージを受信すると、この宣伝されている近隣シーケンス番号に基づいて決定できます。
Advertised Neighbor Main Address
宣伝されたネイバーメインアドレス
This field contains the main address of a neighbor node. All main addresses of the advertised neighbors of the Originator node are put in the TC message. If the maximum allowed message size (as imposed by the network) is reached while there are still advertised neighbor addresses which have not been inserted into the TC-message, more TC messages will be generated until the entire advertised neighbor set has been sent. Extra main addresses of neighbor nodes may be included, if redundancy is desired.
このフィールドには、ネイバーノードのメインアドレスが含まれています。Originatorノードの宣伝されている隣人のすべての主要なアドレスは、TCメッセージに入れられます。最大許可されたメッセージサイズ（ネットワークによって課される）に到達した場合、TCメッサージに挿入されていない隣接アドレスがまだ宣伝されている場合、宣伝されている近隣セット全体が送信されるまでより多くのTCメッセージが生成されます。冗長性が必要な場合、隣接ノードの追加のメインアドレスを含めることができます。
Reserved
予約済み
This field is reserved, and MUST be set to "0000000000000000" for compliance with this document.
このフィールドは予約されており、このドキュメントを順守するために「000000000000000000」に設定する必要があります。
A TC message is sent by a node in the network to declare a set of links, called advertised link set which MUST include at least the links to all nodes of its MPR Selector set, i.e., the neighbors which have selected the sender node as a MPR.
TCメッセージは、ネットワーク内のノードによって送信されて、MPRセレクターセットのすべてのノードへのリンク、つまり送信者ノードを選択したネイバーへのリンクを含める必要がある広告リンクセットと呼ばれるリンクセットを宣言するために送信されます。MPR。
If, for some reason, it is required to distribute redundant TC information, refer to section 15.
何らかの理由で、冗長なTC情報を配布する必要がある場合は、セクション15を参照してください。
The sequence number (ANSN) associated with the advertised neighbor set is also sent with the list. The ANSN number MUST be incremented when links are removed from the advertised neighbor set; the ANSN number SHOULD be incremented when links are added to the advertised neighbor set.
広告された近隣セットに関連付けられているシーケンス番号（ANSN）もリストとともに送信されます。ANSN番号は、宣伝された近隣セットからリンクが削除された場合に増分する必要があります。ANSN番号は、広告されたNeighbor Setにリンクが追加されると、インクリメントする必要があります。
In order to build the topology information base, each node, which has been selected as MPR, broadcasts Topology Control (TC) messages. TC messages are flooded to all nodes in the network and take advantage of MPRs. MPRs enable a better scalability in the distribution of topology information [1].
トポロジー情報ベースを構築するために、MPRとして選択された各ノードは、トポロジコントロール（TC）メッセージを放送します。TCメッセージは、ネットワーク内のすべてのノードにあふれており、MPRSを利用します。MPRは、トポロジー情報の分布においてより良いスケーラビリティを可能にします[1]。
The list of addresses can be partial in each TC message (e.g., due to message size limitations, imposed by the network), but parsing of all TC messages describing the advertised link set of a node MUST be complete within a certain refreshing period (TC_INTERVAL). The information diffused in the network by these TC messages will help each node calculate its routing table.
アドレスのリストは、各TCメッセージ（例：メッセージサイズの制限が原因で、ネットワークによって課されるため）に部分的になりますが、ノードの広告リンクセットを説明するすべてのTCメッセージの解析は、特定の更新期間内に完全でなければなりません）。これらのTCメッセージによってネットワークに拡散された情報は、各ノードがルーティングテーブルを計算するのに役立ちます。
When the advertised link set of a node becomes empty, this node SHOULD still send (empty) TC-messages during the a duration equal to the "validity time" (typically, this will be equal to TOP_HOLD_TIME) of its previously emitted TC-messages, in order to invalidate the previous TC-messages. It SHOULD then stop sending TC-messages until some node is inserted in its advertised link set.
ノードの広告リンクセットが空になった場合、このノードは、以前に放出されたTC-メスの「有効性時間」（通常、これはTOP_HOLD_TIMEに等しくなります）に等しいa期間中に（空の）TCメッセージを送信する必要があります、以前のTCメッセージを無効にするため。その後、広告されたリンクセットにノードが挿入されるまで、TCメッセージの送信を停止する必要があります。
A node MAY transmit additional TC-messages to increase its reactiveness to link failures. When a change to the MPR selector set is detected and this change can be attributed to a link failure, a TC-message SHOULD be transmitted after an interval shorter than TC_INTERVAL.
ノードは、追加のTCメッセージを送信して、リンク障害に対する反応性を高める場合があります。MPRセレクターセットの変更が検出され、この変更がリンク障害に起因する場合、TC_INTERVALよりも短い間隔の後にTCメッセージを送信する必要があります。
TC messages are broadcast and retransmitted by the MPRs in order to diffuse the messages in the entire network. TC messages MUST be forwarded according to the "default forwarding algorithm" (described in section 3.4).
TCメッセージは、ネットワーク全体のメッセージを拡散するために、MPRSによってブロードキャストおよび再送信されます。TCメッセージは、「デフォルトの転送アルゴリズム」（セクション3.4で説明）に従って転送する必要があります。
Upon receiving a TC message, the "validity time" MUST be computed from the Vtime field of the message header (see section 3.3.2). The topology set SHOULD then be updated as follows (using section 19 for comparison of ANSN):
TCメッセージを受信すると、メッセージヘッダーのvtimeフィールドから「有効性時間」を計算する必要があります（セクション3.3.2を参照）。トポロジセットは、次のように更新する必要があります（ANSNの比較のためにセクション19を使用）。
1 If the sender interface (NB: not originator) of this message is not in the symmetric 1-hop neighborhood of this node, the message MUST be discarded.
1このメッセージの送信者インターフェイス（NB：元の元）がこのノードの対称1ホップ近傍にない場合、メッセージを破棄する必要があります。
2 If there exist some tuple in the topology set where:
2トポロジーセットにタプルが存在する場合：
T_last_addr == originator address AND
t_last_addr ==オリジナルアドレスと
T_seq > ANSN,
t_seq> ansn、
then further processing of this TC message MUST NOT be performed and the message MUST be silently discarded (case: message received out of order).
次に、このTCメッセージのさらなる処理を実行する必要はなく、メッセージを静かに破棄する必要があります（ケース：メッセージが故障したメッセージ）。
3 All tuples in the topology set where:
3トポロジセットのすべてのタプルは次の場所です。
T_last_addr == originator address AND
t_last_addr ==オリジナルアドレスと
T_seq < ANSN
t_seq <ansn
MUST be removed from the topology set.
トポロジセットから削除する必要があります。
4 For each of the advertised neighbor main address received in the TC message:
4 TCメッセージで受信した広告された近隣メインアドレスごとに：
4.1 If there exist some tuple in the topology set where:
4.1 トポロジーセットにタプルが存在する場合：
T_dest_addr == advertised neighbor main address, AND
T_DEST_ADDR == Advertided Neighbor Mainアドレス、および
T_last_addr == originator address,
T_LAST_ADDR ==オリジナルアドレス、
then the holding time of that tuple MUST be set to:
次に、そのタプルの保持時間を次のように設定する必要があります。
T_time = current time + validity time.
T_TIME =現在の時間妥当性時間。
4.2 Otherwise, a new tuple MUST be recorded in the topology set where:
4.2 それ以外の場合は、新しいタプルをトポロジセットに記録する必要があります。
T_dest_addr = advertised neighbor main address,
T_DEST_ADDR =宣伝されたネイバーメインアドレス、
T_last_addr = originator address,
T_LAST_ADDR = Originatorアドレス、
T_seq = ANSN,
t_seq = ansn、
T_time = current time + validity time.
T_TIME =現在の時間妥当性時間。
Each node maintains a routing table which allows it to route data, destined for the other nodes in the network. The routing table is based on the information contained in the local link information base and the topology set. Therefore, if any of these sets are changed, the routing table is recalculated to update the route information about each destination in the network. The route entries are recorded in the routing table in the following format:
各ノードは、ネットワーク内の他のノード用に運命づけられたデータをルーティングできるルーティングテーブルを維持します。ルーティングテーブルは、ローカルリンク情報ベースとトポロジセットに含まれる情報に基づいています。したがって、これらのセットのいずれかが変更された場合、ルーティングテーブルは再計算され、ネットワーク内の各宛先に関するルート情報を更新します。ルートエントリは、ルーティングテーブルに次の形式で記録されます。
1. R_dest_addr R_next_addr R_dist R_iface_addr 2. R_dest_addr R_next_addr R_dist R_iface_addr 3. ,, ,, ,, ,,
1. r_dest_addr r_next_addr r_dist r_iface_addr 2. r_dest_addr r_next_addr r_dist r_iface_addr 3.、、、、、、、、,、、
Each entry in the table consists of R_dest_addr, R_next_addr, R_dist, and R_iface_addr. Such entry specifies that the node identified by R_dest_addr is estimated to be R_dist hops away from the local node, that the symmetric neighbor node with interface address R_next_addr is the next hop node in the route to R_dest_addr, and that this symmetric neighbor node is reachable through the local interface with the address R_iface_addr. Entries are recorded in the routing table for each destination in the network for which a route is known. All the destinations, for which a route is broken or only partially known, are not recorded in the table.
テーブル内の各エントリは、r_dest_addr、r_next_addr、r_dist、およびr_iface_addrで構成されています。このようなエントリは、R_DEST_ADDRによって識別されたノードが、ローカルノードから離れたR_DISTホップと推定されること、インターフェイスアドレスR_NEXT_ADDRを持つ対称隣接ノードがR_DEST_ADDRへのルートの次のホップノードであり、この対称的な隣接ノードが到達できることを指定していることを指定しています。アドレスr_iface_addrを使用したローカルインターフェイス。エントリは、ルートが既知のネットワーク内の各宛先のルーティングテーブルに記録されます。ルートが壊れているか、部分的にしか知られていないすべての目的地は、テーブルに記録されていません。
More precisely, the routing table is updated when a change is detected in either:
より正確には、次のいずれかで変更が検出されると、ルーティングテーブルが更新されます。
- the link set,
- リンクセット、
- the neighbor set,
- 隣人セット、
- the 2-hop neighbor set,
- 2ホップネイバーセット、
- the topology set,
- トポロジセット、
- the Multiple Interface Association Information Base,
- 複数のインターフェイスアソシエーション情報ベース、
More precisely, the routing table is recalculated in case of neighbor appearance or loss, when a 2-hop tuple is created or removed, when a topology tuple is created or removed or when multiple interface association information changes. The update of this routing information does not generate or trigger any messages to be transmitted, neither in the network, nor in the 1-hop neighborhood.
より正確には、ルーティングテーブルは、2ホップのタプルが作成または削除されたとき、トポロジータプルが作成または削除されたとき、または複数のインターフェイス関連情報が変更されたとき、隣人の外観または損失の場合、ルーティングテーブルが再計算されます。このルーティング情報の更新は、ネットワークでも1ホップの近隣でも、送信されるメッセージを生成またはトリガーしません。
To construct the routing table of node X, a shortest path algorithm is run on the directed graph containing the arcs X -> Y where Y is any symmetric neighbor of X (with Neighbor Type equal to SYM), the arcs Y -> Z where Y is a neighbor node with willingness different of WILL_NEVER and there exists an entry in the 2-hop Neighbor set with Y as N_neighbor_main_addr and Z as N_2hop_addr, and the arcs U -> V, where there exists an entry in the topology set with V as T_dest_addr and U as T_last_addr.
ノードXのルーティングテーブルを構築するには、アークx - > yを含む指向グラフで最短パスアルゴリズムが実行されます。yは意思が異なる隣のノードであり、will_neverの違いがあり、yをn_neighbor_main_addrとして、zをn_2hop_addrとしてyでセットした2ホップネイバーにエントリが存在します。t_dest_addrとして、uはt_last_addrとして。
The following procedure is given as an example to calculate (or recalculate) the routing table:
以下の手順は、ルーティングテーブルを計算（または再計算）する例として示されています。
1 All the entries from the routing table are removed.
1ルーティングテーブルからのすべてのエントリが削除されます。
2 The new routing entries are added starting with the symmetric neighbors (h=1) as the destination nodes. Thus, for each neighbor tuple in the neighbor set where:
2新しいルーティングエントリは、宛先ノードとして対称的な近隣（h = 1）から追加されます。したがって、隣の隣のタプルについては、次の場所をセットします。
N_status = SYM
(there is a symmetric link to the neighbor), and for each associated link tuple of the neighbor node such that L_time >= current time, a new routing entry is recorded in the routing table with:
（ネイバーへの対称リンクがあります）、および関連する各リンクの隣接ノードのタプルについて、l_time> =現在の時刻では、以下のルーティングテーブルに新しいルーティングエントリが記録されます。
R_dest_addr = L_neighbor_iface_addr, of the associated link tuple;
r_dest_addr = l_neighbor_iface_addr、関連するリンクtupleの。
R_next_addr = L_neighbor_iface_addr, of the associated link tuple;
r_next_addr = l_neighbor_iface_addr、関連するリンクタプルの。
R_dist = 1;
r_dist = 1;
R_iface_addr = L_local_iface_addr of the associated link tuple.
r_iface_addr = l_local_iface_addr関連リンクタプルのaddr。
If in the above, no R_dest_addr is equal to the main address of the neighbor, then another new routing entry with MUST be added, with:
上記で、r_dest_addrが隣人のメインアドレスに等しい場合は、次のような別の新しいルーティングエントリを追加する必要があります。
R_dest_addr = main address of the neighbor;
r_dest_addr =ネイバーのメインアドレス。
R_next_addr = L_neighbor_iface_addr of one of the associated link tuple with L_time >= current time;
r_next_addr = l_neighbor_iface_addr関連リンクの1つの1つのtuple with l_time> = current time;
R_dist = 1;
r_dist = 1;
R_iface_addr = L_local_iface_addr of the associated link tuple.
r_iface_addr = l_local_iface_addr関連リンクタプルのaddr。
3 for each node in N2, i.e., a 2-hop neighbor which is not a neighbor node or the node itself, and such that there exist at least one entry in the 2-hop neighbor set where N_neighbor_main_addr correspond to a neighbor node with willingness different of WILL_NEVER, one selects one 2-hop tuple and creates one entry in the routing table with:
3 N2の各ノード、つまり隣のノードまたはノード自体ではない2ホップ隣人で、N_NEIGHBOR_MAIN_ADDRが隣人ノードに対応する2ホップネイバーセットに少なくとも1つのエントリが存在するようにします。will_neverの違うには、1つの2ホップタプルを選択し、ルーティングテーブルに1つのエントリを作成します。
R_dest_addr = the main address of the 2-hop neighbor;
r_dest_addr = 2ホップ隣人のメインアドレス。
R_next_addr = the R_next_addr of the entry in the routing table with:
r_next_addr =ルーティングテーブルのエントリのr_next_addr：
R_dest_addr == N_neighbor_main_addr of the 2-hop tuple;
r_dest_addr == n_neighbor_main_addrの2ホップタプル;
R_dist = 2;
r_dist = 2;
R_iface_addr = the R_iface_addr of the entry in the routing table with:
r_iface_addr =ルーティングテーブルのエントリのr_iface_addr：
R_dest_addr == N_neighbor_main_addr of the 2-hop tuple;
r_dest_addr == n_neighbor_main_addrの2ホップタプル;
3 The new route entries for the destination nodes h+1 hops away are recorded in the routing table. The following procedure MUST be executed for each value of h, starting with h=2 and incrementing it by 1 each time. The execution will stop if no new entry is recorded in an iteration.
3宛先ノードH 1ホップアウェイの新しいルートエントリは、ルーティングテーブルに記録されます。hの値ごとに、h = 2から始めて、毎回1倍に増分する手順を実行する必要があります。反復に新しいエントリが記録されていない場合、実行は停止します。
3.1 For each topology entry in the topology table, if its T_dest_addr does not correspond to R_dest_addr of any route entry in the routing table AND its T_last_addr corresponds to R_dest_addr of a route entry whose R_dist is equal to h, then a new route entry MUST be recorded in the routing table (if it does not already exist) where:
3.1 トポロジテーブルの各トポロジエントリについて、T_DEST_ADDRがルーティングテーブルのルートエントリのR_DEST_ADDRに対応していない場合、T_LAST_ADDRはR_DISTがHに等しいルートエントリのR_DEST_ADDRに対応する場合、新しいルートエントリを記録する必要があります。ルーティングテーブル（まだ存在していない場合）で：
R_dest_addr = T_dest_addr;
r_dest_addr = t_dest_addr;
R_next_addr = R_next_addr of the recorded route entry where:
r_next_addr = r_next_addr録音されたルートエントリの場所：
R_dest_addr == T_last_addr
r_dest_addr == t_last_addr
R_dist = h+1; and R_iface_addr = R_iface_addr of the recorded route entry where:
r_dist = h 1;およびr_iface_addr = r_iface_addr録音されたルートエントリの場所：
R_dest_addr == T_last_addr.
r_dest_addr == t_last_addr。
3.2 Several topology entries may be used to select a next hop R_next_addr for reaching the node R_dest_addr. When h=1, ties should be broken such that nodes with highest willingness and MPR selectors are preferred as next hop.
3.2 いくつかのトポロジエントリを使用して、ノードr_dest_addrに到達するために次のホップr_next_addrを選択できます。H = 1の場合、次のホップとして最高の意欲とMPRセレクターが優先されるように、ネクタイを破壊する必要があります。
4 For each entry in the multiple interface association base where there exists a routing entry such that:
4ルーティングエントリが存在する複数のインターフェイスアソシエーションベースの各エントリについて：
R_dest_addr == I_main_addr (of the multiple interface association entry)
r_dest_addr == i_main_addr（複数のインターフェイスアソシエーションエントリの）
AND there is no routing entry such that:
そして、次のようなルーティングエントリはありません。
R_dest_addr == I_iface_addr
r_dest_addr == i_iface_addr
then a route entry is created in the routing table with:
次に、ルーティングテーブルにルートエントリが作成されます。
R_dest_addr = I_iface_addr (of the multiple interface association entry)
r_dest_addr = i_iface_addr（複数のインターフェイスアソシエーションエントリの）
R_next_addr = R_next_addr (of the recorded route entry)
r_next_addr = r_next_addr（記録されたルートエントリの）
R_dist = R_dist (of the recorded route entry)
r_dist = r_dist（記録されたルートエントリの）
R_iface_addr = R_iface_addr (of the recorded route entry).
r_iface_addr = r_iface_addr（記録されたルートエントリの）。
This section outlines how a node should be configured, in order to operate in an OLSR MANET.
このセクションでは、OLSRマネで操作するために、ノードの構成方法の概要を説明します。
The nodes in the MANET network SHOULD be assigned addresses within a defined address sequence, i.e., the nodes in the MANET SHOULD be addressable through a network address and a netmask.
MANETネットワーク内のノードには、定義されたアドレスシーケンス内にアドレスを割り当てる必要があります。つまり、マネのノードは、ネットワークアドレスとネットマスクを介してアドレス指定できる必要があります。
Likewise, the nodes in each associated network SHOULD be assigned addresses from a defined address sequence, distinct from that being used in the MANET.
同様に、各関連するネットワークのノードは、MANETで使用されているものとは異なる定義されたアドレスシーケンスからアドレスを割り当てる必要があります。
Any MANET node with associated networks or hosts SHOULD be configured such that it has routes set up to the interfaces with associated hosts or network.
関連するネットワークまたはホストを備えたMANETノードは、関連するホストまたはネットワークを備えたインターフェイスに設定されたルートを持つように構成する必要があります。
OLSR itself does not perform packet forwarding. Rather, it maintains the routing table in the underlying operating system, which is assumed to be forwarding packets as specified in RFC1812.
OLSR自体はパケット転送を実行しません。むしろ、RFC1812で指定されているようにパケットを転送していると想定される、基礎となるオペレーティングシステムのルーティングテーブルを維持しています。
A node MAY be equipped with multiple interfaces, some of which do not participate in the OLSR MANET. These non OLSR interfaces may be point to point connections to other singular hosts or may connect to separate networks.
ノードには複数のインターフェイスが装備されている場合があり、その一部はOLSRマネに参加していません。これらの非OLSRインターフェイスは、他の特異ホストへのポイント接続をポイントするか、個別のネットワークに接続する場合があります。
In order to provide connectivity from the OLSR MANET interface(s) to these non OLSR interface(s), a node SHOULD be able to inject external route information to the OLSR MANET.
OLSR MANETインターフェイスからこれらの非OLSRインターフェイスへの接続を提供するために、ノードはOLSR MANETに外部ルート情報を挿入できる必要があります。
Injecting routing information from the OLSR MANET to non OLSR interfaces is outside the scope of this specification. It should be clear, however, that the routing information for the OLSR MANET can be extracted from the topology table (see section 4.4) or directly from the routing table of OLSR, and SHOULD be injected onto the non OLSR interfaces following whatever mechanism (routing protocol, static configuration etc.) is provided on these interfaces.
OLSR MANETから非OLSRインターフェイスへのルーティング情報を注入することは、この仕様の範囲外です。ただし、OLSRマネのルーティング情報をトポロジテーブルから抽出し（セクション4.4を参照）、またはOLSRのルーティングテーブルから直接抽出し、あらゆるメカニズム（ルーティング）に従って非OLSRインターフェイスに注入する必要があることは明らかです。これらのインターフェイスには、プロトコル、静的構成など）が提供されています。
An example of such a situation could be where a node is equipped with a fixed network (e.g., an Ethernet) connecting to a larger network as well as a wireless network interface running OLSR.
このような状況の例は、ノードに、より大きなネットワークに接続する固定ネットワーク（イーサネットなど）とOLSRを実行しているワイヤレスネットワークインターフェイスを装備している場合です。
Notice that this is a different case from that of "multiple interfaces", where all the interfaces are participating in the MANET through running the OLSR protocol.
これは、すべてのインターフェイスがOLSRプロトコルを実行してMANETに参加している「複数のインターフェイス」のケースとは異なるケースであることに注意してください。
In order to provide this capability of injecting external routing information into an OLSR MANET, a node with such non-MANET interfaces periodically issues a Host and Network Association (HNA) message, containing sufficient information for the recipients to construct an appropriate routing table.
外部ルーティング情報をOLSRマネに注入するこの機能を提供するために、このような非Manetインターフェイスを持つノードは、適切なルーティングテーブルを構築するのに十分な情報を含むホストおよびネットワークアソシエーション（HNA）メッセージを定期的に発行します。
The proposed format of an HNA-message is:
HNAメスの提案された形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Netmask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Netmask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This is sent as the data part of the general packet format with the "Message Type" set to HNA_MESSAGE, the TTL field set to 255 and Vtime set accordingly to the value of HNA_HOLD_TIME, as specified in section 18.3.
これは、セクション18.3で指定されているように、HNA_Messageに設定された「メッセージタイプ」、TTLフィールドが255に設定され、hna_hold_timeの値にそれに応じて設定されたTTLフィールドに設定された一般的なパケット形式のデータ部分として送信されます。
Network Address
ネットワークアドレス
The network address of the associated network
関連するネットワークのネットワークアドレス
Netmask
ネットマスク
The netmask, corresponding to the network address immediately above.
ネットマスクは、上のネットワークアドレスに対応しています。
Each node maintains information concerning which nodes may act as "gateways" to associated hosts and networks by recording "association tuples" (A_gateway_addr, A_network_addr, A_netmask, A_time), where A_gateway_addr is the address of an OLSR interface of the gateway, A_network_addr and A_netmask specify the network address and netmask of a network, reachable through this gateway, and A_time specifies the time at which this tuple expires and hence *MUST* be removed.
各ノードは、「Association Tulples」を記録することにより、関連するホストおよびネットワークへの「ゲートウェイ」として機能するノードに関する情報を保持しています（a_gateway_addr、a_network_addr、a_netmask、a_time）。ネットワークのネットワークアドレスとネットマスクを指定し、このゲートウェイを通じて到達可能であり、A_TIMEはこのタプルが期限切れになる時間を指定し、したがって *削除する必要があります。
The set of all association tuples in a node is called the "association set".
ノード内のすべてのアソシエーションタプルのセットは、「アソシエーションセット」と呼ばれます。
It should be noticed, that the HNA-message can be considered as a "generalized version" of the TC-message: the originator of both the HNA- and TC-messages announce "reachability" to some other host(s).
HNAメスは、TCメッセージの「一般化されたバージョン」と見なすことができることに注意する必要があります。HNA-とTCメッセージの両方の発信者は、他のホストに「到達可能性」を発表します。
In the TC-message, no netmask is required, since all reachability is announced on a per-host basis. In HNA-messages, announcing reachability to an address sequence through a network- and netmask address is typically preferred over announcing reachability to individual host addresses.
TCメッセージでは、すべての到達可能性がHOSTベースで発表されるため、ネットマスクは必要ありません。HNAメスでは、ネットワークおよびネットマスクアドレスを介したアドレスシーケンスへの到達可能性を発表することは、通常、個々のホストアドレスに対する到達可能性を発表するよりも好まれます。
An important difference between TC- and HNA-messages is, that a TC message may have a canceling effect on previous information (if the ANSN is incremented), whereas information in HNA-messages is removed only upon expiration.
TCとHNAのメスの重要な違いは、TCメッセージが以前の情報（ANSNが増加している場合）にキャンセル効果があるのに対し、HNAメッセージの情報は有効期限が切れたときにのみ削除される可能性があることです。
A node with associated hosts and/or networks SHOULD periodically generate a Host and Network Association (HNA) message, containing pairs of (network address, netmask) corresponding to the connected hosts and networks. HNA-messages SHOULD be transmitted periodically every HNA_INTERVAL. The Vtime is set accordingly to the value of HNA_HOLD_TIME, as specified in section 18.3.
関連するホストおよび/またはネットワークを備えたノードは、接続されたホストとネットワークに対応する（ネットワークアドレス、ネットマスク）のペアを含むホストおよびネットワークアソシエーション（HNA）メッセージを定期的に生成する必要があります。HNAメスは、すべてのHNA_INTERVALを定期的に送信する必要があります。vtimeは、セクション18.3で指定されているように、HNA_hold_timeの値にそれに応じて設定されます。
A node without any associated hosts and/or networks SHOULD NOT generate HNA-messages.
関連するホストやネットワークのないノードは、HNAメスを生成してはなりません。
Upon receiving a HNA message, and thus following the rules of section 3, in this version of the specification, the message MUST be forwarded according to section 3.4.
HNAメッセージを受信し、したがってセクション3のルールに従って、このバージョンの仕様では、メッセージをセクション3.4に従って転送する必要があります。
In this section, the term "originator address" is used to designate the main address on the OLSR MANET of the node which originally issued the HNA-message.
このセクションでは、「Originatorアドレス」という用語を使用して、HNAメッセージを最初に発行したノードのOLSRマネのメインアドレスを指定します。
Upon processing a HNA-message, the "validity time" MUST be computed from the Vtime field of the message header (see section 3.3.2). The association base SHOULD then be updated as follows:
HNAメッセージを処理すると、「有効性時間」をメッセージヘッダーのvtimeフィールドから計算する必要があります（セクション3.3.2を参照）。その後、関連付けベースは次のように更新する必要があります。
1 If the sender interface (NB: not originator) of this message is not in the symmetric 1-hop neighborhood of this node, the message MUST be discarded.
1このメッセージの送信者インターフェイス（NB：元の元）がこのノードの対称1ホップ近傍にない場合、メッセージを破棄する必要があります。
2 Otherwise, for each (network address, netmask) pair in the message: 2.1 if an entry in the association set already exists, where:
2それ以外の場合、メッセージ内の各（ネットワークアドレス、ネットマスク）ペアについて：2.1アソシエーションセットのエントリがすでに存在する場合、ここで：
A_gateway_addr == originator address
a_gateway_addr ==オリジナルのアドレス
A_network_addr == network address
a_network_addr ==ネットワークアドレス
A_netmask == netmask
a_netmask == netmask
then the holding time for that tuple MUST be set to:
次に、そのタプルの保持時間を次のように設定する必要があります。
A_time = current time + validity time
A_TIME =現在の時間妥当性時間
2.2 otherwise, a new tuple MUST be recorded with:
2.2 それ以外の場合は、以下で新しいタプルを記録する必要があります。
A_gateway_addr = originator address
A_network_addr = network address
A_netmask = netmask
A_time = current time + validity time
A_TIME =現在の時間妥当性時間
In addition to the routing table computation as described in section 10, the host and network association set MUST be added as follows:
セクション10で説明されているルーティングテーブル計算に加えて、ホストとネットワークの関連付けセットは次のように追加する必要があります。
For each tuple in the association set,
協会セットの各タプルについて、
1 If there is no entry in the routing table with:
1ルーティングテーブルにエントリがない場合：
R_dest_addr == A_network_addr/A_netmask
r_dest_addr == a_network_addr/a_netmask
then a new routing entry is created.
その後、新しいルーティングエントリが作成されます。
2 If a new routing entry was created at the previous step, or else if there existed one with:
2前のステップで新しいルーティングエントリが作成された場合、または以下が存在した場合：
R_dest_addr == A_network_addr/A_netmask
r_dest_addr == a_network_addr/a_netmask
R_dist > dist to A_gateway_addr of current association set tuple,
r_dist>現在の協会セットタプルのa_gateway_addrに留めます。
then the routing entry is modified as follows:
次に、ルーティングエントリは次のように変更されます。
R_dest_addr = A_network_addr/A_netmask R_next_addr = the next hop on the path from the node to A_gateway_addr
r_dest_addr = a_network_addr/a_netmask r_next_addr =ノードからa_gateway_addrへのパスの次のホップ
R_dist = dist to A_gateway_addr
R_next_addr and R_iface_addr MUST be set to the same values as the tuple from the routing set with R_dest_addr == A_gateway_addr.
r_next_addrおよびr_iface_addrは、r_dest_addr == a_gateway_addrを使用してルーティングセットのタプルと同じ値に設定する必要があります。
Nodes, which do not implement support for non OLSR interfaces, can coexist in a network with nodes which do implement support for non OLSR interfaces: the generic packet format and message forwarding (section 3) ensures that HNA messages are correctly forwarded by all nodes. Nodes which implement support for non OLSR interfaces may thus transmit and process HNA messages according to this section.
非OLSRインターフェイスのサポートを実装していないノードは、非OLSRインターフェイスのサポートを実装するノードとネットワークに共存できます。一般的なパケット形式とメッセージ転送（セクション3）は、HNAメッセージがすべてのノードによって正しく転送されることを保証します。したがって、非OLSRインターフェイスのサポートを実装するノードは、このセクションに従ってHNAメッセージを送信および処理する場合があります。
Nodes, which do not implement support for non OLSR interfaces can not take advantage of the functionality specified in this section, however they will forward HNA messages correctly, as specified in section 3.
非OLSRインターフェイスのサポートを実装していないノードは、このセクションで指定された機能を利用できませんが、セクション3で指定されているように、HNAメッセージを正しく転送します。
OLSR is designed not to impose or expect any specific information from the link layer. However, if information from the link-layer describing link breakage is available, a node MAY use this as described in this section.
OLSRは、リンクレイヤーに特定の情報を課したり期待したりしないように設計されています。ただし、リンクの破損を説明するリンク層からの情報が利用可能な場合、このセクションで説明されているようにノードはこれを使用する場合があります。
If link layer information describing connectivity to neighboring nodes is available (i.e., loss of connectivity such as through absence of a link layer acknowledgment), this information is used in addition to the information from the HELLO-messages to maintain the neighbor information base and the MPR selector set.
隣接するノードへの接続性を説明するリンクレイヤー情報が利用可能である場合（つまり、リンクレイヤーの承認がないなどの接続性の損失）、この情報は、隣接情報ベースと次の情報を維持するためのハローメッジからの情報に加えて使用されます。MPRセレクターセット。
Thus, upon receiving a link-layer notification that the link between a node and a neighbor interface is broken, the following actions are taken with respect to link sensing:
したがって、ノードと隣接インターフェイスの間のリンクが壊れているというリンク層通知を受信すると、リンクセンシングに関して次のアクションが実行されます。
Each link tuple in the local link set SHOULD, in addition to what is described in section 4.2, include a L_LOST_LINK_time field. L_LOST_LINK_time is a timer for declaring a link as lost when an established link becomes pending. (Notice, that this is a subset of what is recommended in section 14, thus link hysteresis and link layer notifications can coexist).
ローカルリンクセットの各リンクタプルは、セクション4.2で説明されていることに加えて、l_lost_link_timeフィールドを含める必要があります。l_lost_link_timeは、確立されたリンクが保留されているときに失われたとリンクを宣言するためのタイマーです。（これはセクション14で推奨されるもののサブセットであることに注意してください。したがって、リンクヒステリシスとリンクレイヤー通知は共存できます）。
HELLO message generation should consider those new fields as follows:
こんにちはメッセージ生成は、これらの新しいフィールドを次のように考慮する必要があります。
1 if L_LOST_LINK_time is not expired, the link is advertised with a link type of LOST_LINK. In addition, it is not considered as a symmetric link in the updates of the associated neighbor tuple (see section 8.1).
1 l_lost_link_timeが有効期限が切れない場合、リンクはlose_linkのリンクタイプで宣伝されます。さらに、関連する隣接タプルの更新における対称リンクとは見なされません（セクション8.1を参照）。
2 if the link to a neighboring symmetric or asymmetric interface is broken, the corresponding link tuple is modified: L_LOST_LINK_time and L_time are set to current time + NEIGHB_HOLD_TIME.
2隣接する対称または非対称インターフェイスへのリンクが壊れている場合、対応するリンクタプルが変更されます：l_lost_link_timeおよびl_timeは現在の時刻neighb_hold_timeに設定されます。
3 this is considered as a link loss and the appropriate processing described in section 8.5 should be performed.
3これはリンク損失と見なされ、セクション8.5で説明されている適切な処理を実行する必要があります。
Link layer notifications provide, for a node, an additional criterion by which a node may determine if a link to a neighbor node is lost. Once a link is detected as lost, it is advertised, in accordance with the provisions described in the previous sections of this specification.
リンクレイヤー通知は、ノードに、近隣ノードへのリンクが失われたかどうかをノードが決定できる追加の基準を提供します。この仕様の前のセクションで説明されている規定に従って、リンクが紛失として検出されると、宣伝されます。
Established links should be as reliable as possible to avoid data packet loss. This implies that link sensing should be robust against bursty loss or transient connectivity between nodes. Hence, to enhance the robustness of the link sensing mechanism, the following implementation recommendations SHOULD be considered.
確立されたリンクは、データパケットの損失を避けるために、できるだけ信頼できる必要があります。これは、リンクセンシングがノード間のバースト損失または過渡的な接続に対して堅牢であることを意味します。したがって、リンク検知メカニズムの堅牢性を高めるには、次の実装の推奨事項を考慮する必要があります。
Each link tuple in the local link set SHOULD, in addition to what is described in section 4.2, include a L_link_pending field, a L_link_quality field, and a L_LOST_LINK_time field. L_link_pending is a boolean value specifying if the link is considered pending (i.e., the link is not considered established). L_link_quality is a dimensionless number between 0 and 1 describing the quality of the link. L_LOST_LINK_time is a timer for declaring a link as lost when an established link becomes pending.
ローカルリンクセットの各リンクタプルは、セクション4.2で説明されているものに加えて、l_link_pendingフィールド、l_link_qualityフィールド、l_lost_link_timeフィールドを含める必要があります。L_LINK_PENDINGは、リンクが保留中と見なされるかどうかを指定するブール値です（つまり、リンクは確立されていない）。L_LINK_QUALITYは、リンクの品質を説明する0〜1の間の無次元数です。l_lost_link_timeは、確立されたリンクが保留されているときに失われたとリンクを宣言するためのタイマーです。
HELLO message generation should consider those new fields as follows:
こんにちはメッセージ生成は、これらの新しいフィールドを次のように考慮する必要があります。
1 if L_LOST_LINK_time is not expired, the link is advertised with a link type of LOST_LINK.
1 l_lost_link_timeが有効期限が切れない場合、リンクはlose_linkのリンクタイプで宣伝されます。
2 otherwise, if L_LOST_LINK_time is expired and L_link_pending is set to "true", the link SHOULD NOT be advertised at all;
それ以外の場合、l_lost_link_timeが期限切れになり、l_link_pendingが「true」に設定されている場合、リンクをまったく宣伝しないでください。
3 otherwise, if L_LOST_LINK_time is expired and L_link_pending is set to "false", the link is advertised as described previously in section 6.
3それ以外の場合、l_lost_link_timeが有効期限が切れ、l_link_pendingが「false」に設定されている場合、リンクはセクション6で以前に説明されているように宣伝されます。
A node considers that it has a symmetric link for each link tuple where:
ノードは、各リンクタプルの対称リンクがあることを考慮します。
1 L_LOST_LINK_time is expired, AND
1 L_LOST_LINK_TIMEが期限切れになります
2 L_link_pending is "false", AND
2 l_link_pendingは「false」です
3 L_SYM_time is not expired.
3 l_sym_timeの有効期限はありません。
This definition for "symmetric link" SHOULD be used in updating the associated neighbor tuple (see section 8.1) for computing the N_status of a neighbor node. This definition SHOULD thereby also be used as basis for the symmetric neighborhood when computing the MPR set, as well as for "the symmetric neighbors" in the first steps of the routing table calculation.
「対称リンク」のこの定義は、隣接ノードのN_STATUを計算するために、関連する隣接タプル（セクション8.1を参照）の更新に使用する必要があります。これにより、MPRセットを計算する際の対称近傍の基礎として、およびルーティングテーブル計算の最初のステップで「対称隣接」の基礎としても使用される必要があります。
Apart from the above, what has been described previously does not interfere with the advanced link sensing fields in the link tuples. The L_link_quality, L_link_pending and L_LOST_LINK_time fields are exclusively updated according to the present section. This section does not modify the function of any other fields in the link tuples.
上記とは別に、以前に説明されていることは、リンクタプルの高度なリンクセンシングフィールドに干渉しません。l_link_quality、l_link_pending、l_lost_link_timeフィールドは、本セクションに従ってのみ更新されます。このセクションでは、リンクタプル内の他のフィールドの機能を変更しません。
The link between a node and some of its neighbor interfaces might be "bad", i.e., from time to time let HELLOs pass through only to fade out immediately after. In this case, the neighbor information base would contain a bad link for at least "validity time". The following hysteresis strategy SHOULD be adopted to counter this situation.
ノードとその隣接インターフェイスの一部との間のリンクは「悪い」可能性があります。つまり、時々、Hellosがすぐにフェードアウトするためだけに通過させます。この場合、近隣の情報ベースには、少なくとも「有効期間」の間、悪いリンクが含まれます。この状況に対抗するために、次のヒステリシス戦略を採用する必要があります。
For each neighbor interface NI heard by interface I, the L_link_quality field of the corresponding Link Tuple determines the establishment of the link. The value of L_link_quality is compared to two thresholds HYST_THRESHOLD_HIGH, HYST_THRESHOLD_LOW, fixed between 0 and 1 and such that HYST_THRESHOLD_HIGH >= HYST_THRESHOLD_LOW.
インターフェイスIで聞いた各隣接インターフェイスNiについて、対応するリンクタプルのL_LINK_QUALITYフィールドがリンクの確立を決定します。L_LINK_QUALITYの値は、HYST_THRESHOLD_LOW、HYST_THRESHOLD_LOWの2つのしきい値と比較されます。
The L_link_pending field is set according to the following:
l_link_pendingフィールドは、以下に従って設定されています。
1 if L_link_quality > HYST_THRESHOLD_HIGH:
1 if l_link_quality> hyst_threshold_high：
L_link_pending = false
L_LOST_LINK_time = current time - 1 (expired)
l_lost_link_time =現在の時間-1（期限切れ）
2 otherwise, if L_link_quality < HYST_THRESHOLD_LOW:
2それ以外の場合、l_link_quality <hyst_threshold_low：
L_link_pending = true
L_LOST_LINK_time = min (L_time, current time + NEIGHB_HOLD_TIME)
l_lost_link_time = min（l_time、current time neight_hold_time）
(the link is then considered as lost according to section 8.5 and this may produce a neighbor loss).
（その後、リンクはセクション8.5に従って失われたと見なされ、これは隣人の損失を引き起こす可能性があります）。
3 otherwise, if HYST_THRESHOLD_LOW <= L_link_quality <= HYST_THRESHOLD_HIGH:
3それ以外の場合、hyst_threshold_low <= l_link_quality <= hyst_threshold_high：
L_link_pending and L_LOST_LINK_time remain unchanged.
l_link_pendingおよびl_lost_link_timeは変更されていません。
The condition for considering a link established is thus stricter than the condition for dropping a link. Notice thus, that a link can be dropped based on either timer expiration (as described in section 7) or on L_link_quality dropping below HYST_THRESHOLD_LOW.
したがって、確立されたリンクを考慮する条件は、したがって、リンクを落とす条件よりも厳しいです。したがって、タイマーの有効期限（セクション7で説明されている）またはl_link_qualityのいずれかに基づいてリンクを削除できることに注意してください。
Also notice, that even if a link is not considered as established by the link hysteresis, the link tuples are still updated for each received HELLO message (as described in section 7). Specifically, this implies that, regardless of whether or not the link hysteresis considers a link as "established", tuples in the link set do not expire except as determined by the L_time field of the link tuples.
また、リンクがリンクヒステリシスによって確立されていると見なされていなくても、リンクのタプルは、受信したハローメッセージごとに更新されています（セクション7で説明されています）。具体的には、これは、リンクヒステリシスがリンクを「確立」と見なすかどうかに関係なく、リンクセットのタプルがリンクタプルのL_TIMEフィールドで決定された場合を除き、期限切れにならないことを意味します。
As a basic implementation requirement, an estimation of the link quality must be maintained and stored in the L_link_quality field. If some measure of the signal/noise level on a received message is available (e.g., as a link layer notification), then it can be used as estimation after normalization.
基本的な実装要件として、リンク品質の推定を維持し、l_link_qualityフィールドに保存する必要があります。受信したメッセージの信号/ノイズレベルの何らかの尺度が利用可能である場合（例：リンクレイヤー通知として）、正規化後の推定として使用できます。
If no signal/noise information or other link quality information is available from the link layer, an algorithm such as the following can be utilized (it is an exponentially smoothed moving average of the transmission success rate). The algorithm is parameterized by a scaling parameter HYST_SCALING which is a number fixed between 0 and 1. For each neighbor interface NI heard by interface I, the first time NI is heard by I, L_link_quality is set to HYST_SCALING (L_link_pending is set to true and L_LOST_LINK_time to current time - 1).
リンクレイヤーから信号/ノイズ情報またはその他のリンク品質情報が利用できない場合、次のようなアルゴリズムを利用できます（伝送成功率の指数関数的にスムーズな移動平均です）。アルゴリズムは、0から1の間に固定された数字であるスケーリングパラメーターHyst_scalingによってパラメーター化されます。インターフェイスIによって聞こえる各隣接インターフェイスNiについて、niが初めてniが聞こえます。l_lost_link_time to truent time -1）。
A tuple is updated according to two rules. Every time an OLSR packet emitted by NI is received by I, the stability rule is applied:
タプルは2つのルールに従って更新されます。NIによって放出されたOLSRパケットがIによって受信されるたびに、安定性ルールが適用されます。
L_link_quality = (1-HYST_SCALING)*L_link_quality
+ HYST_SCALING.
When an OLSR packet emitted by NI is lost by I, the instability rule is applied:
NIによって放出されたOLSRパケットがIによって失われると、不安定性ルールが適用されます。
L_link_quality = (1-HYST_SCALING)*L_link_quality.
The loss of OLSR packet is detected by tracking the missing Packet Sequence Numbers on a per interface basis and by "long period of silence" from a node. A "long period of silence may be detected thus: if no OLSR packet has been received on interface I from interface NI during HELLO emission interval of interface NI (computed from the Htime field in the last HELLO message received from NI), a loss of an OLSR packet is detected.
OLSRパケットの損失は、インターフェイスごとに欠落しているパケットシーケンス番号をノードから「長期沈黙の期間」で追跡することにより検出されます。「したがって、長い期間の沈黙が検出される可能性があります。インターフェイスNIからインターフェイスIでOLSRパケットが受信されていない場合、インターフェイスNi（Niから受信した最後のHelloメッセージのHTIMEフィールドから計算）の排出インターバル中に、OLSRパケットが検出されます。
Link hysteresis determines, for a node, the criteria at which a link to a neighbor node is accepted or rejected. Nodes in a network may have different criteria, according to the nature of the media over which they are communicating. Once a link is accepted, it is advertised, in accordance with the provisions described in the previous sections of this specification.
リンクヒステリシスは、ノードの場合、近隣ノードへのリンクが受け入れられるか拒否される基準を決定します。ネットワーク内のノードは、通信しているメディアの性質に応じて、異なる基準を持つ場合があります。この仕様の前のセクションで説明されている規定に従って、リンクが受け入れられると、宣伝されます。
In order to provide redundancy to topology information base, the advertised link set of a node MAY contain links to neighbor nodes which are not in MPR selector set of the node. The advertised link set MAY contain links to the whole neighbor set of the node. The minimal set of links that any node MUST advertise in its TC messages is the links to its MPR selectors. The advertised link set can be built according to the following rule based on a local parameter called TC_REDUNDANCY parameter.
トポロジ情報ベースに冗長性を提供するために、ノードの広告リンクセットには、ノードのMPRセレクターセットにないネイバーノードへのリンクが含まれている場合があります。広告されたリンクセットには、ノードのネイバーセット全体へのリンクが含まれている場合があります。NodeがTCメッセージで宣伝する必要がある最小限のリンクセットは、MPRセレクターへのリンクです。広告されたリンクセットは、TC_Redundancyパラメーターと呼ばれるローカルパラメーターに基づいて、次のルールに従って構築できます。
The parameter TC_REDUNDANCY specifies, for the local node, the amount of information that MAY be included in the TC messages. The parameter SHOULD be interpreted as follows:
パラメーターTC_REDUNDANCYは、ローカルノードに、TCメッセージに含まれる可能性のある情報の量を指定します。パラメーターは次のように解釈する必要があります。
- if the TC_REDUNDANCY parameter of the node is 0, then the advertised link set of the node is limited to the MPR selector set (as described in section 8.3),
- ノードのTC_REDUNDANCYパラメーターが0の場合、ノードの広告リンクセットはMPRセレクターセット（セクション8.3で説明されているように）に制限されます。
- if the TC_REDUNDANCY parameter of the node is 1, then the advertised link set of the node is the union of its MPR set and its MPR selector set,
- ノードのTC_REDUNDANCYパラメーターが1の場合、ノードの広告リンクセットは、MPRセットとMPRセレクターセットの結合です。
- if the TC_REDUNDANCY parameter of the node is 2, then the advertised link set of the node is the full neighbor link set.
- ノードのTC_REDUNDANCYパラメーターが2の場合、ノードの広告リンクセットは完全なネイバーリンクセットです。
A node with willingness equal to WILL_NEVER SHOULD have TC_REDUNDANCY also equal to zero.
will_neverに等しい意欲を持つノードは、ゼロにも等しいtc_redundancyを持つ必要があります。
A TC message is sent by a node in the network to declare a set of links, called advertised link set, which MUST include at least the links to all nodes of its MPR Selector set, i.e., the neighbors which have selected the sender node as a MPR. This is sufficient information to ensure that routes can be computed in accordance with section 10.
TCメッセージは、ネットワーク内のノードによって送信され、Advertidedリンクセットと呼ばれるリンクのセットを宣言します。MPR。これは、セクション10に従ってルートを計算できるようにするのに十分な情報です。
The provisions in this section specifies how additional information may be declared, as specified through a TC_REDUNDANCY parameter. TC_REDUNDANCY = 0 implies that the information declared corresponds exactly to the MPR Selector set, identical to section 9. Other values of TC_REDUNDANCY specifies additional information to be declared, i.e., the contents of the MPR Selector set is always declared. Thus, nodes with different values of TC_REDUNDANCY may coexist in a network: control messages are carried by all nodes in accordance with section 3, and all nodes will receive at least the link-state information required to construct routes as described in section 10.
このセクションの規定では、TC_Redundancyパラメーターを介して指定されているように、追加情報がどのように宣言されるかを指定します。TC_Redundancy = 0は、宣言された情報がMPRセレクターセットに正確に対応することを意味します。セクション9と同一です。TC_RedUndancyのその他の値は、宣言される追加情報、つまりMPRセレクターセットの内容が常に宣言されることを指定します。したがって、TC_Redundancyの異なる値を持つノードはネットワークに共存する場合があります。コントロールメッセージは、セクション3に従ってすべてのノードによって実行され、すべてのノードは、セクション10で説明されているルートを構築するために必要なリンク状態情報を少なくとも受信します。
MPR redundancy specifies the ability for a node to select redundant MPRs. Section 4.5 specifies that a node should select its MPR set to be as small as possible, in order to reduce protocol overhead. The criteria for selecting MPRs is, that all strict 2-hop nodes must be reachable through, at least, one MPR node. Redundancy of the MPR set affects the overhead through affecting the amount of links being advertised, the amount of nodes advertising links and the efficiency of the MPR flooding mechanism. On the other hand, redundancy in the MPR set ensures that reachability for a node is advertised by more nodes, thus additional links are diffused to the network.
MPR冗長性は、ノードが冗長なMPRSを選択する機能を指定します。セクション4.5は、プロトコルオーバーヘッドを減らすために、ノードがMPRセットをできるだけ小さくすることを選択する必要があることを指定します。MPRを選択するための基準は、すべての厳密な2ホップノードが少なくとも1つのMPRノードを通じて到達可能でなければならないことです。MPRセットの冗長性は、宣伝されているリンクの量、ノード広告リンクの量、およびMPRフラッディングメカニズムの効率に影響を与えることにより、オーバーヘッドに影響します。一方、MPRセットの冗長性により、ノードの到達可能性がより多くのノードによって宣伝されるため、追加のリンクがネットワークに拡散されます。
While, in general, a minimal MPR set provides the least overhead, there are situations in which overhead can be traded off for other benefits. For example, a node may decide to increase its MPR coverage if it observes many changes in its neighbor information base caused by mobility, while otherwise keeping a low MPR coverage.
一般に、最小限のMPRセットは最小のオーバーヘッドを提供しますが、他の利点のためにオーバーヘッドをトレードオフできる状況があります。たとえば、ノードは、MPRのカバレッジがモビリティによって引き起こされた近隣情報ベースに多くの変化を観察する場合、MPRカバレッジを増やすことを決定する場合があります。
The MPR coverage is defined by a single local parameter, MPR_COVERAGE, specifying by how many MPR nodes any strict 2-hop node should be covered. MPR_COVERAGE=1 specifies that the overhead of the protocol is kept at a minimum and causes the MPR selection to operate as described in section 8.3.1. MPR_COVERAGE=m ensures that, if possible, a node selects its MPR set such that all strict 2-hop nodes for an interface are reachable through at least m MPR nodes on that interface. MPR_COVERAGE can assume any integer value > 0. The heuristic MUST be applied per interface, I. The MPR set for a node is the union of the MPR sets found for each interface.
MPRカバレッジは、単一のローカルパラメーターMPR_COVERAGEで定義されます。MPR_COVERAGE = 1は、プロトコルのオーバーヘッドが最小限に抑えられ、セクション8.3.1で説明されているようにMPR選択が動作することを指定します。MPR_COVERAGE = Mは、可能であれば、ノードがMPRセットを選択して、インターフェイスのすべての厳密な2ホップノードが、そのインターフェイス上の少なくともM MPRノードを介して到達可能になるようにします。MPR_COVERAGEは、整数値> 0を引き受けることができます。ヒューリスティックはインターフェイスごとに適用する必要があります。I。ノードのMPRセットは、各インターフェイスで見つかったMPRセットの結合です。
Notice that MPR_COVERAGE can be tuned locally without affecting the consistency of the protocol. For example, nodes in a network may operate with different values of MPR_COVERAGE.
MPR_COVERAGEは、プロトコルの一貫性に影響を与えることなくローカルで調整できることに注意してください。たとえば、ネットワーク内のノードは、MPR_COVERAGEの異なる値で動作する場合があります。
Using MPR coverage, the MPR selection heuristics is extended from that described in the section 8.3.1 by one definition:
MPRカバレッジを使用して、MPR選択ヒューリスティックは、1つの定義でセクション8.3.1で説明されているものから拡張されます。
Poorly covered node:
覆われていないノード：
A poorly covered node is a node in N2 which is covered by less than MPR_COVERAGE nodes in N.
覆われていないノードは、N2のMPR_COVERAGEノード未満でカバーされているN2のノードです。
The proposed heuristic for selecting MPRs is then as follows:
MPRを選択するための提案されたヒューリスティックは次のとおりです。
1 Start with an MPR set made of all members of N with willingness equal to WILL_ALWAYS
1は、will_alwaysに等しい意欲で、nのすべてのメンバーで作られたMPRセットから始めます
2 Calculate D(y), where y is a member of N, for all nodes in N.
2 nのすべてのノードについて、yはnのメンバーであるd（y）を計算します。
3 Select as MPRs those nodes in N which cover the poorly covered nodes in N2. The nodes are then removed from N2 for the rest of the computation.
3 n2の覆われていないノードをカバーするnのそれらのノードをmprsとして選択します。次に、ノードは、残りの計算についてN2から削除されます。
4 While there exist nodes in N2 which are not covered by at least MPR_COVERAGE nodes in the MPR set:
4 N2にはノードが存在しますが、MPRセットの少なくともMPR_COVERAGEノードでカバーされていません。
4.1 For each node in N, calculate the reachability, i.e., the number of nodes in N2 which are not yet covered by at least MPR_COVERAGE nodes in the MPR set, and which are reachable through this 1-hop neighbor;
4.1 nの各ノードについて、到達可能性、つまり、MPRセットの少なくともMPR_COVERAGEノードでまだカバーされておらず、この1ホップ隣人を通じて到達可能なN2のノードの数を計算します。
4.2 Select as a MPR the node with highest willingness among the nodes in N with non-zero reachability. In case of multiple choice select the node which provides reachability to the maximum number of nodes in N2. In case of multiple nodes providing the same amount of reachability, select the node as MPR whose D(y) is greater. Remove the nodes from N2 which are now covered by MPR_COVERAGE nodes in the MPR set.
4.2 MPRとして選択します。Nodeは、ゼロの範囲でゼロの到達可能性を備えたNのノードの中で最も意欲が高くなります。複数選択の場合、N2の最大数のノードにリーチ性を提供するノードを選択します。同じ量の到達可能性を提供する複数のノードの場合、D（y）が大きいMPRとしてノードを選択します。MPRセットのMPR_COVERAGEノードでカバーされるN2からノードを削除します。
5 A node's MPR set is generated from the union of the MPR sets for each interface. As an optimization, process each node, y, in the MPR set in increasing order of N_willingness. If all nodes in N2 are still covered by at least MPR_COVERAGE nodes in the MPR set excluding node y, and if N_willingness of node y is smaller than WILL_ALWAYS, then node y MAY be removed from the MPR set.
5ノードのMPRセットは、各インターフェイスのMPRセットの結合から生成されます。最適化として、n_willingnessの順序で設定されたMPRで各ノードyを処理します。N2のすべてのノードが、ノードYを除くMPRセットの少なくともMPR_COVERAGEノードでまだカバーされている場合、ノードYのn_Willingnessがwill_alwaysよりも小さい場合、ノードyはMPRセットから削除される場合があります。
When the MPR set has been computed, all the corresponding main addresses are stored in the MPR Set.
MPRセットが計算されると、対応するすべてのメインアドレスがMPRセットに保存されます。
The MPR set of a node MUST, according to section 8.3, be calculated by a node in such a way that it, through the neighbors in the MPR-set, can reach all symmetric strict 2-hop neighbors. This is achieved by the heuristics in this section, for all values of MPR_COVERAGE > 0. MPR_COVERAGE is a local parameter for each node. Setting this parameter affects only the amount of redundancy in part of the network.
セクション8.3によれば、ノードのMPRセットは、MPRセットの隣人を介して、すべての対称的な厳密な2ホップ近隣に到達できるようにノードによって計算される必要があります。これは、MPR_COVERAGE> 0のすべての値に対して、このセクションのヒューリスティックによって達成されます。MPR_COVERAGEは、各ノードのローカルパラメーターです。このパラメーターの設定は、ネットワークの一部の冗長性の量のみに影響します。
Notice that for MPR_COVERAGE=1, the heuristics in this section is identical to the heuristics specified in the section 8.3.1.
MPR_COVERAGE = 1の場合、このセクションのヒューリスティックは、セクション8.3.1で指定されているヒューリスティックと同一であることに注意してください。
Nodes with different values of MPR_COVERAGE may coexist in a network: control messages are carried by all nodes in accordance with section 3, and all nodes will receive at least the link-state information required to construct routes as described in sections 9 and 10.
MPR_COVERAGEの異なる値を持つノードは、ネットワークに共存できます。コントロールメッセージは、セクション3に従ってすべてのノードによって実行され、すべてのノードは、セクション9および10で説明されているルートを構築するために必要なリンク状態情報を少なくとも受信します。
All the operations and parameters described in this document used by OLSR for IP version 4 are the same as those used by OLSR for IP version 6. To operate with IP version 6, the only required change is to replace the IPv4 addresses with IPv6 address. The minimum packet and message sizes (under which there is rejection) should be adjusted accordingly, considering the greater size of IPv6 addresses.
IPバージョン4のためにOLSRが使用するこのドキュメントで説明されているすべての操作とパラメーターは、IPバージョン6にOLSRが使用するものと同じです。IPバージョン6で動作するために、必要な変更はIPv4アドレスをIPv6アドレスに置き換えることです。IPv6アドレスのサイズが大きいことを考慮して、それに応じて最小パケットサイズとメッセージサイズを調整する必要があります。
This section list the values for the constants used in the description of the protocol.
このセクションには、プロトコルの説明で使用される定数の値がリストされています。
The proposed constant for C is the following:
Cの提案された定数は次のとおりです。
C = 1/16 seconds (equal to 0.0625 seconds)
C = 1/16秒（0.0625秒に等しい）
C is a scaling factor for the "validity time" calculation ("Vtime" and "Htime" fields in message headers, see section 18.3). The "validity time" advertisement is designed such that nodes in a network may have different and individually tuneable emission intervals, while still interoperate fully. For protocol functioning and interoperability to work:
Cは、「有効期間」計算（メッセージヘッダーの「vtime」および「htime」フィールドのスケーリング係数です。セクション18.3を参照）。「有効期間」広告は、ネットワーク内のノードが異なる個別に調整可能な排出間隔を持っている間、完全に相互運用するように設計されています。プロトコルの機能と作業の相互運用性について：
- the advertised holding time MUST always be greater than the refresh interval of the advertised information. Moreover, it is recommended that the relation between the interval (from section 18.2), and the hold time is kept as specified in section 18.3, to allow for reasonable packet loss.
- 広告された保有時間は、常に広告情報の更新間隔よりも大きくなければなりません。さらに、合理的なパケット損失を可能にするために、間隔（セクション18.2から）と保留時間を指定して保持することをお勧めします。
- the constant C SHOULD be set to the suggested value. In order to achieve interoperability, C MUST be the same on all nodes.
- 定数Cを推奨される値に設定する必要があります。相互運用性を実現するには、Cはすべてのノードで同じでなければなりません。
- the emission intervals (section 18.2), along with the advertised holding times (subject to the above constraints) MAY be selected on a per node basis.
- 排出間隔（セクション18.2）と、宣伝された保持時間（上記の制約の対象）とともに、ノードごとに選択できます。
Note that the timer resolution of a given implementation might not be sufficient to wake up the system on precise refresh times or on precise expire times: the implementation SHOULD round up the
特定の実装のタイマー解像度は、正確な更新時間または正確な期限切れにシステムを目覚めさせるのに十分ではないかもしれないことに注意してください。
'validity time' ("Vtime" and "Htime" of packets) to compensate for coarser timer resolution, at least in the case where "validity time" could be shorter than the sum of emission interval and maximum expected timer error.
少なくとも「有効性時間」が排出間隔の合計と最大予想タイマーエラーよりも短くなる場合、「有効性時間」（パケットの「VTIME」および「HTIME」）が粗いタイマー解像度を補正します。
HELLO_INTERVAL = 2 seconds
REFRESH_INTERVAL = 2 seconds
TC_INTERVAL = 5 seconds
MID_INTERVAL = TC_INTERVAL
HNA_INTERVAL = TC_INTERVAL
NEIGHB_HOLD_TIME = 3 x REFRESH_INTERVAL
TOP_HOLD_TIME = 3 x TC_INTERVAL
DUP_HOLD_TIME = 30 seconds
MID_HOLD_TIME = 3 x MID_INTERVAL
HNA_HOLD_TIME = 3 x HNA_INTERVAL
The Vtime in the message header (see section 3.3.2), and the Htime in the HELLO message (see section 6.1) are the fields which hold information about the above values in mantissa and exponent format (rounded up). In other words:
メッセージヘッダーのvtime（セクション3.3.2を参照）、およびHelloメッセージのHtime（セクション6.1を参照）は、マンティッサの上記の値に関する情報と指数形式（丸められた）を保持するフィールドです。言い換えると：
value = C*(1+a/16)*2^b [in seconds]
where a is the integer represented by the four highest bits of the field and b the integer represented by the four lowest bits of the field.
ここで、Aはフィールドの4つの最高ビットで表される整数と、フィールドの4つの最低ビットで表される整数です。
Notice, that for the previous proposed value of C, (1/16 seconds), the values, in seconds, expressed by the formula above can be stored, without loss of precision, in binary fixed point or floating point numbers with at least 8 bits of fractional part. This corresponds with NTP time-stamps and single precision IEEE Standard 754 floating point numbers.
以前の提案されたCの値（1/16秒）については、上記の式で表される値は、精度を損なうことなく、少なくとも8のバイナリ固定点または浮動小数点数に保存できることに注意してください。分数部分のビット。これは、NTPタイムスタンプおよび単一の精度IEEE標準754フローティングポイント番号に対応します。
Given one of the above holding times, a way of computing the mantissa/exponent representation of a number T (of seconds) is the following:
上記の保持時間の1つを考えると、数字（秒）のマンティッサ/指数表現を計算する方法は次のとおりです。
- find the largest integer 'b' such that: T/C >= 2^b
- T/C> = 2^Bのような最大の整数「B」を見つけます
- compute the expression 16*(T/(C*(2^b))-1), which may not be a integer, and round it up. This results in the value for 'a'
- 式16*（t/（c*（2^b））-1）を計算します。これは整数ではない場合があり、丸めます。これにより、「a」の値が得られます
- if 'a' is equal to 16: increment 'b' by one, and set 'a' to 0
- 「a」が16に等しい場合、「b」を1つずつ増加させ、「a」を0に設定します
- now, 'a' and 'b' should be integers between 0 and 15, and the field will be a byte holding the value a*16+b
- 今、「A」と「B」は0から15の間の整数でなければならず、フィールドは値を保持しているバイトA*16 Bになります
For instance, for values of 2 seconds, 6 seconds, 15 seconds, and 30 seconds respectively, a and b would be: (a=0,b=5), (a=8,b=6), (a=14,b=7) and (a=14,b=8) respectively.
たとえば、2秒、6秒、15秒、30秒の値の場合、AとBは次のとおりです。（a = 0、b = 5）、（a = 8、b = 6）、（a = 14、b = 7）および（a = 14、b = 8）。
HELLO_MESSAGE = 1
TC_MESSAGE = 2
MID_MESSAGE = 3
HNA_MESSAGE = 4
UNSPEC_LINK = 0
ASYM_LINK = 1
SYM_LINK = 2
LOST_LINK = 3
NOT_NEIGH = 0
SYM_NEIGH = 1
MPR_NEIGH = 2
HYST_THRESHOLD_HIGH = 0.8
hyst_threshold_high = 0.8
HYST_THRESHOLD_LOW = 0.3
hyst_threshold_low = 0.3
HYST_SCALING = 0.5
hyst_scaling = 0.5
WILL_NEVER = 0
WILL_LOW = 1
WILL_DEFAULT = 3
WILL_HIGH = 6
WILL_ALWAYS = 7
The willingness of a node may be set to any integer value from 0 to 7, and specifies how willing a node is to be forwarding traffic on behalf of other nodes. Nodes will, by default, have a willingness WILL_DEFAULT. WILL_NEVER indicates a node which does not wish to carry traffic for other nodes, for example due to resource constraints (like being low on battery). WILL_ALWAYS indicates that a node always should be selected to carry traffic on behalf of other nodes, for example due to resource abundance (like permanent power supply, high capacity interfaces to other nodes).
ノードの意欲は、0から7までの任意の整数値に設定され、他のノードに代わってトラフィックを転送するノードがどれだけ喜んでいるかを指定します。ノードは、デフォルトでは、意欲を持っています。will_neverは、リソースの制約（バッテリーが低いなど）のために、他のノードにトラフィックを運ぶことを望まないノードを示します。Will_alwaysは、たとえばリソースの豊富さ（永久電源など）のために、他のノードに代わってトラフィックを運ぶためにノードを常に選択する必要があることを示しています。
A node may dynamically change its willingness as its conditions change.
ノードは、条件が変化するにつれて意欲を動的に変更する場合があります。
One possible application would, for example, be for a node, connected to a permanent power supply and with fully charged batteries, to advertise a willingness of WILL_ALWAYS. Upon being disconnected from the permanent power supply (e.g., a PDA being taken out of its charging cradle), a willingness of WILL_DEFAULT is advertised. As battery capacity is drained, the willingness would be further reduced. First to the intermediate value between WILL_DEFAULT and WILL_LOW, then to WILL_LOW and finally to WILL_NEVER, when the battery capacity of the node does no longer support carrying foreign traffic.
たとえば、可能なアプリケーションの1つは、will_alwaysの意欲を宣伝するために、永続的な電源に接続され、完全に充電されたバッテリーを備えたノード用です。恒久的な電源から切断されると（たとえば、PDAが充電されたゆりかごから取り出される）、Will_Defaultの意欲が宣伝されます。バッテリー容量が排出されると、意欲がさらに低下します。最初に、will_defaultとwill_lowの間の中間値に、次にwill_lowに、そして最後にwill_neverに、ノードのバッテリー容量が外交を運ぶことをサポートしなくなります。
TC_REDUNDANCY = 0
MPR COVERAGE = 1
MPRカバレッジ= 1
MAXJITTER = HELLO_INTERVAL / 4
Sequence numbers are used in OLSR with the purpose of discarding "old" information, i.e., messages received out of order. However with a limited number of bits for representing sequence numbers, wrap-around (that the sequence number is incremented from the maximum possible value to zero) will occur. To prevent this from interfering with the operation of the protocol, the following MUST be observed.
シーケンス番号は、「古い」情報、つまり故障したメッセージを破棄する目的でOLSRで使用されます。ただし、シーケンス番号を表すためのビット数が限られていると、ラップアラウンド（シーケンス数が最大値からゼロに増分される）が発生します。これがプロトコルの操作を妨げるのを防ぐには、以下を観察する必要があります。
The term MAXVALUE designates in the following the largest possible value for a sequence number.
MaxValueという用語は、シーケンス番号に対して可能な最大値を以下に指定します。
The sequence number S1 is said to be "greater than" the sequence number S2 if:
シーケンス番号S1は、「シーケンス番号S2よりも「大きい」と言われています。
S1 > S2 AND S1 - S2 <= MAXVALUE/2 OR
S2 > S1 AND S2 - S1 > MAXVALUE/2
Thus when comparing two messages, it is possible - even in the presence of wrap-around - to determine which message contains the most recent information.
したがって、2つのメッセージを比較する場合、ラップアラウンドが存在していても、最新の情報を含むメッセージを決定することが可能です。
Currently, OLSR does not specify any special security measures. As a proactive routing protocol, OLSR makes a target for various attacks. The various possible vulnerabilities are discussed in this section.
現在、OLSRは特別なセキュリティ対策を指定していません。プロアクティブなルーティングプロトコルとして、OLSRはさまざまな攻撃のターゲットを作成します。このセクションでは、さまざまな脆弱性について説明します。
Being a proactive protocol, OLSR periodically diffuses topological information. Hence, if used in an unprotected wireless network, the network topology is revealed to anyone who listens to OLSR control messages.
積極的なプロトコルであるOLSRは、定期的にトポロジー情報を拡散します。したがって、保護されていないワイヤレスネットワークで使用される場合、OLSRコントロールメッセージに耳を傾ける人にはネットワークトポロジが明らかになります。
In situations where the confidentiality of the network topology is of importance, regular cryptographic techniques such as exchange of OLSR control traffic messages encrypted by PGP [9] or encrypted by some shared secret key can be applied to ensure that control traffic can be read and interpreted by only those authorized to do so.
ネットワークトポロジの機密性が重要な状況では、PGPによって暗号化されたOLSR制御トラフィックメッセージの交換[9]または共有されたシークレットキーによって暗号化された状況では、コントロールトラフィックを読み取って解釈できるようにすることができます。そうすることを許可された人だけによって。
In OLSR, each node is injecting topological information into the network through transmitting HELLO messages and, for some nodes, TC messages. If some nodes for some reason, malicious or malfunction, inject invalid control traffic, network integrity may be compromised. Therefore, message authentication is recommended.
OLSRでは、各ノードがHelloメッセージを送信し、一部のノードではTCメッセージを送信することにより、トポロジー情報をネットワークに注入しています。何らかの理由でいくつかのノード、悪意のあるまたは誤動作が無効な制御トラフィックを注入すると、ネットワークの整合性が損なわれる可能性があります。したがって、メッセージ認証をお勧めします。
Different such situations may occur, for instance:
たとえば、このような状況が異なる場合があります。
1 a node generates TC (or HNA) messages, advertising links to non-neighbor nodes:
1ノードはTC（またはHNA）メッセージを生成します。
2 a node generates TC (or HNA) messages, pretending to be another node,
2ノードはTC（またはHNA）メッセージを生成し、別のノードのふりをして、
3 a node generates HELLO messages, advertising non-neighbor nodes,
3ノードはハローメッセージを生成し、非neighborノードを宣伝し、
4 a node generates HELLO messages, pretending to be another node.
4ノードはハローメッセージを生成し、別のノードのふりをします。
5 a node forwards altered control messages,
5ノードは変更された制御メッセージを転送し、
6 a node does not broadcast control messages,
6ノードはコントロールメッセージをブロードキャストしません、
7 a node does not select multipoint relays correctly.
7ノードはマルチポイントリレーを正しく選択しません。
8 a node forwards broadcast control messages unaltered, but does not forward unicast data traffic;
8ノードはブロードキャスト制御メッセージを変更しませんが、ユニキャストデータトラフィックを転送しません。
9 a node "replays" previously recorded control traffic from another node.
9ノード「リプレイ」は、以前に別のノードからの制御トラフィックを記録しました。
Authentication of the originator node for control messages (for situation 2, 4 and 5) and on the individual links announced in the control messages (for situation 1 and 3) may be used as a countermeasure. However to prevent nodes from repeating old (and correctly authenticated) information (situation 9) temporal information is required, allowing a node to positively identify such delayed messages.
コントロールメッセージ（状況2、4、5の場合）およびコントロールメッセージ（状況1および3用）で発表された個々のリンクのオリジナルノードの認証は、対策として使用できます。ただし、ノードが古い（そして正しく認証された）情報を繰り返すのを防ぐために（状況9）時間情報が必要であり、ノードがそのような遅延メッセージを積極的に識別できるようにします。
In general, digital signatures and other required security information may be transmitted as a separate OLSR message type, thereby allowing that "secured" and "unsecured" nodes can coexist in the same network, if desired.
一般に、デジタル署名およびその他の必要なセキュリティ情報は、別のOLSRメッセージタイプとして送信される可能性があり、それにより、必要に応じて、同じネットワークで「セキュリティで保護されている」ノードと「無担保」ノードが共存できることが可能になります。
Specifically, the authenticity of entire OLSR control messages can be established through employing IPsec authentication headers, whereas authenticity of individual links (situation 1 and 3) require additional security information to be distributed.
具体的には、OLSR制御メッセージ全体の信頼性は、IPSEC認証ヘッダーを使用して確立できますが、個々のリンク（状況1および3）の信頼性は追加のセキュリティ情報を配布する必要があります。
An important consideration is, that all control messages in OLSR are transmitted either to all nodes in the neighborhood (HELLO messages) or broadcast to all nodes in the network (e.g., TC messages).
重要な考慮事項は、OLSRのすべての制御メッセージが、近隣のすべてのノード（ハローメッセージ）に送信されるか、ネットワーク内のすべてのノード（TCメッセージなど）にブロードキャストされることです。
For example, a control message in OLSR is always a point-to-multipoint transmission. It is therefore important that the authentication mechanism employed permits that any receiving node can validate the authenticity of a message. As an analogy, given a block of text, signed by a PGP private key, then anyone with the corresponding public key can verify the authenticity of the text.
たとえば、OLSRのコントロールメッセージは、常にポイントツーマルチポイント伝送です。したがって、採用された認証メカニズムが、受信ノードがメッセージの信頼性を検証できることを許可することが重要です。Analogyとして、PGPの秘密鍵で署名されたテキストのブロックを考えると、対応する公開キーを持っている人なら誰でもテキストの信頼性を確認できます。
OLSR does, through the HNA messages specified in section 12, provide a basic mechanism for injecting external routing information to the OLSR domain. Section 12 also specifies that routing information can be extracted from the topology table or the routing table of OLSR and, potentially, injected into an external domain if the routing protocol governing that domain permits.
OLSRは、セクション12で指定されたHNAメッセージを介して、外部ルーティング情報をOLSRドメインに注入するための基本的なメカニズムを提供します。セクション12では、OLSRのトポロジテーブルまたはルーティングテーブルからルーティング情報を抽出できること、およびそのドメインが許可するルーティングプロトコルの場合、外部ドメインに注入される可能性があることも指定しています。
Other than as described in the section 20.2, when operating nodes, connecting OLSR to an external routing domain, care MUST be taken not to allow potentially insecure and un-trustworthy information to be injected from the OLSR domain to external routing domains. Care MUST be taken to validate the correctness of information prior to it being injected as to avoid polluting routing tables with invalid information.
OLSRを外部ルーティングドメインに接続するセクション20.2で説明されているように、セクション20.2で説明されている場合を除き、OLSRドメインから外部ルーティングドメインに潜在的に不安定で信頼できない情報を注入しないように注意する必要があります。情報が無効な情報を使用してルーティングテーブルの汚染を避けるために、情報の正確性を検証するように注意する必要があります。
A recommended way of extending connectivity from an existing routing domain to an OLSR routed MANET is to assign an IP prefix (under the authority of the nodes/gateways connecting the MANET with the exiting routing domain) exclusively to the OLSR MANET area, and to configure the gateways statically to advertise routes to that IP sequence to nodes in the existing routing domain.
既存のルーティングドメインからOLSRルーティングマネに接続性を拡張する推奨される方法は、IPプレフィックスを割り当てることです（MANETを出口ルーティングドメインと接続するノード/ゲートウェイの権限の下で）OLSRマネ領域のみに割り当て、構成ゲートウェイは静的に、既存のルーティングドメインのノードへのそのIPシーケンスへのルートを宣伝します。
OLSR does not make any assumption about node addresses, other than that each node is assumed to have a unique IP address.
OLSRは、各ノードが一意のIPアドレスを持っていると想定されることを除いて、ノードアドレスについて仮定しません。
Due to its proactive nature, the OLSR protocol has a natural control over the flow of its control traffic. Nodes transmits control message at predetermined rates fixed by predefined refresh intervals. Furthermore the MPR optimization greatly saves on control overhead, and this is done on two sides. First, the packets that advertise the topology are much shorter since only MPR selectors may be advertised. Second, the cost of flooding this information is greatly reduced since only MPR nodes forward the broadcast packets. In dense networks, the reduction of control traffic can be of several orders of magnitude compared to routing protocols using classical flooding (such as OSPF) [10]. This feature naturally provides more bandwidth for useful data traffic and pushes further the frontier of congestion. Since the control traffic is continuous and periodic, it keeps more stable the quality of the links used in routing, where reactive protocols, with bursty floodings for route discoveries and repairs, may damage the link qualities for short times by causing numerous collisions on those links, possibly provoking route repair cascades. However, in certain OLSR options, some control messages may be intentionally sent in advance of their deadline(TC or Hello messages) in order to increase the reactiveness of the protocol against topology changes. This may cause a small, temporary and local increase of control traffic.
その積極的な性質のため、OLSRプロトコルは、その制御トラフィックの流れを自然に制御しています。ノードは、事前定義された更新間隔によって修正された所定のレートでコントロールメッセージを送信します。さらに、MPRの最適化はコントロールオーバーヘッドに大幅に節約され、これは両側で行われます。まず、MPRセレクターのみが宣伝される可能性があるため、トポロジを宣伝するパケットははるかに短くなります。第二に、MPRノードのみがブロードキャストパケットを転送するため、この情報の洪水のコストは大幅に削減されます。密なネットワークでは、制御トラフィックの削減は、古典的な洪水（OSPFなど）を使用したルーティングプロトコルと比較して数桁になる可能性があります[10]。この機能は、当然、有用なデータトラフィックのためにより多くの帯域幅を提供し、混雑のフロンティアをさらに押し上げます。制御トラフィックは継続的かつ周期的であるため、ルーティングで使用されるリンクの品質をより安定させます。ルートの発見と修理のためのバーテーション洪水があるリアクティブプロトコルは、これらのリンクに多数の衝突を引き起こすことでリンクの品質を短時間損傷する可能性があります。、おそらく挑発的なルート修理カスケード。ただし、特定のOLSRオプションでは、トポロジーの変化に対するプロトコルの反応性を高めるために、いくつかの制御メッセージを意図的に締め切り（TCまたはHelloメッセージ）の前に送信することができます。これにより、コントロールトラフィックが小さく、一時的かつ局所的な増加が生じる可能性があります。
OLSR defines a "Message Type" field for control messages. A new registry has been created for the values for this Message Type field, and the following values assigned:
OLSRは、コントロールメッセージの「メッセージタイプ」フィールドを定義します。このメッセージタイプフィールドの値に対して新しいレジストリが作成され、次の値が割り当てられています。
Message Type Value
-------------------- -----
HELLO_MESSAGE 1
TC_MESSAGE 2
MID_MESSAGE 3
HNA_MESSAGE 4
Future values in the range 5-127 of the Message Type can be allocated using standards action [7].
メッセージタイプの範囲5〜127の将来の値は、標準アクション[7]を使用して割り当てることができます。
Additionally, values in the range 128-255 are reserved for private/local use.
さらに、範囲128-255の値は、プライベート/ローカル使用のために予約されています。
The authors would like to thank Joseph Macker <macker@itd.nrl.navy.mil> and his team, including Justin Dean <jdean@itd.nrl.navy.mil>, for their valuable suggestions on the advanced neighbor sensing mechanism and other various aspects of the protocol, including careful review of the protocol specification.
著者は、Joseph Macker <macker@itd.nrl.navy.mil>と彼のチームに感謝します。プロトコル仕様の慎重なレビューを含む、プロトコルのさまざまな側面。
The authors would also like to thank Christopher Dearlove <chris.dearlove@baesystems.com> for valuable input on the MPR selection heuristics and for careful reviews of the protocol specification.
著者はまた、MPR選択ヒューリスティックに関する貴重な入力と、プロトコル仕様の慎重なレビューについて、Christopher Dearlove <chris.dearlove@baesystems.com>に感謝します。
During the development of this specification, the following list of people contributed. The contributors are listed alphabetically.
この仕様の開発中、次の人々のリストが貢献しました。貢献者はアルファベット順にリストされています。
Cedric Adjih Project HIPERCOM INRIA Rocquencourt, BP 105 78153 Le Chesnay Cedex, France
セドリックアジフプロジェクトHipercom Inria Rocquencourt、BP 105 78153 Le Chesnay Cedex、フランス
Phone: +33 1 3963 5215
EMail: Cedric.Adjih@inria.fr
Thomas Heide Clausen Project HIPERCOM INRIA Rocquencourt, BP 105 78153 Le Chesnay Cedex, France
Thomas Heide Clausen Project Hipercom Inria Rocquencourt、BP 105 78153 Le Chesnay Cedex、フランス
Phone: +33 1 3963 5133
EMail: T.Clausen@computer.org
Philippe Jacquet Project HIPERCOM INRIA Rocquencourt, BP 105 78153 Le Chesnay Cedex, France
Philippe Jacquet Project Hipercom Inria Rocquencourt、BP 105 78153 Le Chesnay Cedex、フランス
Phone: +33 1 3963 5263 EMail: Philippe.Jacquet@inria.fr Anis Laouiti Project HIPERCOM INRIA Rocquencourt, BP 105 78153 Le Chesnay Cedex, France
電話：33 1 3963 5263メール：Philippe.jacquet@inria.fr anis laouitiプロジェクトHipercom Inria Rocquencourt、BP 105 78153 Le Chesnay Cedex、フランス
Phone: +33 1 3963 5088
EMail: Anis.Laouiti@inria.fr
Pascale Minet Project HIPERCOM INRIA Rocquencourt, BP 105 78153 Le Chesnay Cedex, France
Pascale Minet Project Hipercom Inria Rocquencourt、BP 105 78153 Le Chesnay Cedex、フランス
Phone: +33 1 3963 5233
EMail: Pascale.Minet@inria.fr
Paul Muhlethaler Project HIPERCOM INRIA Rocquencourt, BP 105 78153 Le Chesnay Cedex, France
Paul Muhlethaler Project Hipercom Inria Rocquencourt、BP 105 78153 Le Chesnay Cedex、フランス
Phone: +33 1 3963 5278
EMail: Paul.Muhlethaler@inria.fr
Amir Qayyum Center for Advanced Research in Engineering Pvt. Ltd. 19 Ataturk Avenue Islamabad, Pakistan
Amir Qayyum Advanced Research in Engineering Pvt。Ltd. 19アタチュルクアベニューイスラマバード、パキスタン
Phone: +92-51-2874115
EMail: amir@carepvtltd.com
Laurent Viennot Project HIPERCOM INRIA Rocquencourt, BP 105 78153 Le Chesnay Cedex, France
Laurent Viennot Project Hipercom Inria Rocquencourt、BP 105 78153 Le Chesnay Cedex、フランス
Phone: +33 1 3963 5225
EMail: Laurent.Viennot@inria.fr
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[7] T. Clausen, P. Jacquet, A. Laouiti, P. Muhlethaler, A. Qayyum and L. Viennot. Optimized Link State Routing Protocol. IEEE INMIC Pakistan 2001.
[7] T. Clausen、P。Jacquet、A。Laouiti、P。Muhlethaler、A。QayyumおよびL. Viennot。最適化されたリンク状態ルーティングプロトコル。IEEE Inmic Pakistan 2001。
[1] P. Jacquet, P. Minet, P. Muhlethaler, N. Rivierre. Increasing reliability in cable free radio LANs: Low level forwarding in HIPERLAN. Wireless Personal Communications, 1996.
[1] P. Jacquet、P。Minet、P。Muhlethaler、N。Rivierre。ケーブルフリーラジオランの信頼性の向上：Hiperlanの低レベル転送。ワイヤレスパーソナルコミュニケーション、1996年。
[2] A. Qayyum, L. Viennot, A. Laouiti. Multipoint relaying: An efficient technique for flooding in mobile wireless networks. 35th Annual Hawaii International Conference on System Sciences (HICSS'2001).
[2] A. Qayyum、L。Viennot、A。Laouiti。マルチポイントリレー：モバイルワイヤレスネットワークでの洪水のための効率的な手法。第35回年次システム科学に関する国際会議（HICSS'2001）。
[3] ETSI STC-RES10 Committee. Radio equipment and systems: HIPERLAN type 1, functional specifications ETS 300-652, ETSI, June 1996.
[3] ETSI STC-RES10委員会。無線機器とシステム：Hiperlan Type 1、機能仕様ETS 300-652、ETSI、1996年6月。
[4] P. Jacquet and L. Viennot, Overhead in Mobile Ad-hoc Network Protocols, INRIA research report RR-3965, 2000.
[4] P. JacquetおよびL. Viennot、モバイルアドホックネットワークプロトコルのオーバーヘッド、INRIA Research Report RR-3965、2000。
[6] T. Clausen, G. Hansen, L. Christensen and G. Behrmann. The Optimized Link State Routing Protocol, Evaluation through Experiments and Simulation. IEEE Symposium on "Wireless Personal Mobile Communications", September 2001.
[6] T. Clausen、G。Hansen、L。Christensen、G。Behrmann。最適化されたリンク状態ルーティングプロトコル、実験およびシミュレーションによる評価。2001年9月、「ワイヤレスパーソナルモバイルコミュニケーション」に関するIEEEシンポジウム。
[8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[8] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[9] Atkins, D., Stallings, W. and P. Zimmermann, "PGP Message Exchange Formats", RFC 1991, August 1996.
[9] Atkins、D.、Stallings、W。and P. Zimmermann、「PGPメッセージ交換形式」、RFC 1991、1996年8月。
[10] P. Jacquet, A. Laouiti, P. Minet, L. Viennot. Performance analysis of OLSR multipoint relay flooding in two ad hoc wireless network models, INRIA research report RR-4260, 2001.
[10] P. Jacquet、A。Laouiti、P。Minet、L。Viennot。2つのアドホックワイヤレスネットワークモデルでのOLSRマルチポイントリレーフラッディングのパフォーマンス分析、INRIA Research Report RR-4260、2001。
Thomas Heide Clausen Project HIPERCOM INRIA Rocquencourt, BP 105 78153 Le Chesnay Cedex, France
Thomas Heide Clausen Project Hipercom Inria Rocquencourt、BP 105 78153 Le Chesnay Cedex、フランス
Phone: +33 1 3963 5133
EMail: T.Clausen@computer.org
Philippe Jacquet, Project HIPERCOM, INRIA Rocquencourt, BP 105 78153 Le Chesnay Cedex, France
Philippe Jacquet、Project Hipercom、Inria Rocquencourt、BP 105 78153 Le Chesnay Cedex、フランス
Phone: +33 1 3963 5263,
EMail: Philippe.Jacquet@inria.fr
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上記の限られた許可は永続的であり、インターネット社会やその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。