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)
Status of this Memo
このメモの位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（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の要件に合わせて調整古典リンク状態アルゴリズムの最適化です。プロトコルで使用される重要な概念は、マルチポイントリレー（のMPR）のことです。 MPRは、順方向フラッディング処理中にメッセージをブロードキャストするノードを選択しています。この技術は、実質的に、メッセージの最初のコピーを受信した場合、すべてのノードが各メッセージを再送信する古典的なフラッディングメカニズムと比較してメッセージオーバーヘッドを減少させます。 OLSRでは、リンク状態情報のみのMPRとして選定ノードによって生成されます。したがって、第2の最適化は、ネットワークにフラッディング制御メッセージの数を最小化することによって達成されます。第三の最適化として、MPRノードは、それ自体とそのMPRセレクタとの間のリンクのみを報告することを選択してもよいです。従って、古典的なリンクステートアルゴリズムに反したように、部分的なリンクステート情報は、ネットワーク内に分散されています。この情報は、その後、ルート計算のために使用されています。 OLSRは、（ホップ数の観点で）最適なルートを提供します。 MPRの技術は、この文脈でうまく機能するようなプロトコルは、大規模かつ緻密なネットワークのために特に適しています。
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.
ネットワーク内のリンク状態情報を宣言するときのMPRとして選択されたノードは、また、特別な責任を負っています。実際、すべての宛先への最短パス経路を提供する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.
いくつかの隣接ノード（S）でマルチリレーとして選択されたノードは、その制御メッセージに定期的にこの情報を発表します。これにより、ノードは、MPRとして選択したノードへの到達可能性を有していることを、ネットワークにアナウンスします。経路計算において、のMPRは、ネットワーク内の任意の宛先に指定されたノードからの経路を形成するために使用されます。さらに、プロトコルは、ネットワークにおける制御メッセージの効率的なフラッディングを容易にするためのMPRを使用します。
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を選択します。したがって、のMPRを通るルートを選択すると、自動的にユニキャストトラフィックのためにこの技術を採用し、リンク層のために、そのような各ホップでデータパケットのリンク層肯定応答を取得していないという問題として一方向リンク（上のデータパケットの転送に関連する問題を回避します）。
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層プロトコル）からの中継の概念を継承します。プロトコルはイパネマプロジェクト（ユークリッドプログラムの一部）および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].
キーワード "MUST"、 "MUST NOT"、 "REQUIRED" は、 "NOT SHALL" "ものと" この文書では、 "SHOULD"、 "推奨" "NOT SHOULD"、 "MAY"、 "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を実行するMANETに参加するネットワークデバイス。ノードは、各インターフェイスが固有のIPアドレスを割り当て、いくつかのOLSRインタフェースを有することができます。
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.
ネットワークデバイスは、MANET走行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インタフェースの一つのアドレスです。
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インタフェースノードは、その「主アドレス」（「ルータID」または「ノード識別子」に相当）としてのOLSRインタフェースのアドレスのいずれかを選択しなければなりません。これは、アドレスが選択されている重要ではない、しかし、ノードは常にメインアドレスと同じアドレスを使用する必要があります。
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は、（すなわち、リンクは、ノードXとY上のOLSRインタフェース上OLSRインタフェースの間に存在する）ノードXを聞くことができる場合、ノードXはノードYの近隣ノードです。
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.
自ノードまたはノードの近隣ではなく、加えて、ノードのWILL_NEVER異なる意欲と、近隣の近隣である2ホップネイバー。
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.
リンクは、互いを聞くこと感受性（2つの異なるノードからの）OLSRインタフェース（すなわち、一方が他方からのトラフィックを受信することであってもよい）の組です。ノードは、そのインタフェースの一方が他方のノードのインタフェースのいずれかへのリンクを有する場合、別のノードへのリンクを有すると言われています。
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.
一方向にのみ検証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に少なくとも一つの対称のリンクを有するノードのセットであります
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の対称の1ホップ隣接に対称のリンクを有するX自体を除いたノードのセットであります
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の、意欲と、X自体といくつかの対称的な1ホップ隣人に対して対称のリンクを有するその近隣を除いた、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は、モバイルアドホックネットワーク（MANET）のためのプロアクティブルーティングプロトコルである[1]、[2]。 MPRを使用して達成最適化は、この文脈でうまく機能としては、大規模かつ緻密なモバイルネットワークに適しています。より大きく、より密なネットワークは、より多くの最適化は、古典的なリンクステートアルゴリズムと比較して達成することができます。 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は、制御メッセージを再送信するためにのみ選択されたノードと呼ばれるのMPRを、使用して制御トラフィックの洪水からのオーバーヘッドを最小限に抑えます。この技術は大幅にネットワーク内のすべてのノードにメッセージをあふれさせるために必要な再送信の数を減らします。第二に、OLSRは最短パス経路を提供するためにフラッディングされる部分的にしかリンク状態を必要とします。必要なリンク状態情報の最小セットはのMPRとして選択されたすべてのノードが、その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は、連続的にネットワーク内のすべての宛先へのルートを維持するようにさらに、プロトコルは、ノードの大部分集合は、ノードの別の大規模なサブセットと通信している、そしてここで、[ソース、宛先]ペアが時間の経過とともに変化しているトラフィックパターンのために有益です。 MPRを使用して行う最適化は、この文脈でうまく機能するようなプロトコルは、大きく、緻密なネットワークに特に適しています。より大きく、より密なネットワークは、より多くの最適化は、古典的なリンクステートアルゴリズムと比較して達成することができます。
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）に向けました。小さな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セレクタのセット）と呼ばれます。ノードがネイバーから受信した定期的なHELLOメッセージからこの情報を取得します。
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.
Nは、まだそれを受信していない場合、ノードNのMPRセレクタのいずれかから来るネットワーク全体に拡散することを意図するものでブロードキャストメッセージは、ノード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.
コアは、独自の権利、スタンドアロン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のコア機能は、OLSRインタフェースMANETに参加し、ルーティングプロトコルとして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.
リンクセンシング接続がチェックされ、それを通してインターフェース上HELLOメッセージの周期的な放出によって達成されます。別々のHELLOメッセージは、各インターフェイスのために生成され、セクション7の規定に対応して放出されます。
Resulting from Link Sensing is a local link set, describing links between "local interfaces" and "remote interfaces" - i.e., interfaces on neighbor nodes.
すなわち、隣接ノード上のインターフェイス - リンクセンシングに起因する「ローカルインターフェース」と「リモートインタフェース」との間のリンクを記述する、ローカルリンクセットです。
If sufficient information is provided by the link-layer, this may be utilized to populate the local link set instead of HELLO message exchange.
十分な情報がリンク層によって提供される場合、これは代わりにHELLOメッセージ交換セットローカルリンクを移入するために利用することができます。
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.
ノードは、これらの選択された隣人によって再送信、ブロードキャストメッセージは、2ホップ離れたすべてのノードによって受信されるように、その近隣のサブセットを選択するためのMPR選択の目的です。ノードのMPRセットは、それが、各インターフェイスに、この条件を満たすように計算されます。セクション8.3に詳述されているセクション6 MPR選択手順に記載したようにこの計算を実行するために必要な情報は、HELLOメッセージの定期的な交換を介して獲得されます。
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の制御メッセージを送信する防ぐために重複セットを維持）し、後のセクションで説明したようにの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.
「OLSR用語」で定義されたような1つのインタフェース、ノードのメインアドレスを持つノードについては、そのインターフェイスのアドレスに設定しなければなりません。
The basic layout of any packet in OLSR is as follows (omitting IP and UDP headers):
（IP及びUDPヘッダを省略）を以下のようにOLSRにおける任意のパケットの基本的なレイアウトです。
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パケットが送信されるたびにインクリメントされなければなりません。別々のパケットシーケンス番号は、インターフェースを介して送信されたパケットを順次列挙されるように各インターフェイスのために維持されているセクション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.
このフィールドは、メッセージのタイプは「MESSAGE」の部分で発見されるかを示します。 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]
有効時間= C *（1 + / 16）[秒] * 2 ^ B
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フィールドのとVTIMEフィールドの4最下位ビットで表される整数B 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.
このフィールドは、メッセージが送信されるホップの最大数が含まれています。メッセージが再送信される前に、ノードは、0または1に等しい生存時間を有するメッセージを受信すると、ライブまでの時間が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.
メッセージを生成しながら、「発信元」ノードは、各メッセージに固有の識別番号が割り当てられます。この数は、メッセージのシーケンス番号フィールドに挿入されます。シーケンス番号は、ノードから発信メッセージごとに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_addr、D_seq_num、D_retransmitted、D_iface_list、D_time）を、記録し、D_seq_numメッセージのメッセージシーケンス番号であり、D_retransmittedを示すブール値でありますメッセージが既に再送されたか否か、D_iface_listは、メッセージが受信されたとD_timeタプルが期限切れになる時刻を指定し、* MUST *除去されたインターフェイスのアドレスのリストです。
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.
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.
メッセージの有効期間が「0」（ゼロ）以下である場合は、メッセージが受信ノードによって送信された場合2、または（すなわち、メッセージの発信元アドレスは、受信ノードのメインアドレスです） ：メッセージは静かに下げなければなりません。
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
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.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
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_retransmittedはtrueに設定されている場合、メッセージは、ステップ4に従って再送する場合にのみ。
Otherwise an entry in the duplicate set is recorded with:
それ以外の場合は、重複セット内のエントリをして記録されます。
D_addr = Originator Address
D_addr =差出人アドレス
D_seq_num = Message Sequence Number
D_seq_num =メッセージシーケンス番号
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_retransmittedはtrueに設定されている場合、メッセージは、ステップ4に従って再送する場合にのみ。
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
7メッセージのホップカウントが1だけ増加されます
8 The message is broadcast on all interfaces (Notice: The remaining fields of the message header SHOULD be left unmodified.)
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.
処理および転送メッセージは異なるルールで条件付け二つの異なるアクションが、あることに留意すべきです。転送がネットワークの他のノードに対して同じメッセージを再送信に関連しながら、処理は、メッセージの内容を使用することに関する。
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の、メッセージを再ブロードキャストされます場合にも、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.
- MID - メッセージ、ノード上の複数のインターフェイスの存在を宣言するのタスクを実行します。
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 - ジッタ
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_INTERVALハローメッセージのため、TC-メッセージ等のため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.
ネットワーク内の各宛先に対して、「インタフェース協会タプル」（I_iface_addr、I_main_addr、I_time）が記録されています。 I_iface_addrはI_main_addrこのノードのメインアドレスであり、ノードのインタフェースアドレスです。 I_timeはこのタプルの有効期限が切れると* MUST *削除された時刻を指定します。
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.
ノードは、 "リンクタプル"（L_local_iface_addr、L_neighbor_iface_addr、L_SYM_time、L_ASYM_time、L_time）のセットを記録します。 L_local_iface_addrローカル・ノード（すなわち、リンクの一方のエンドポイント）のインタフェースアドレスである、L_neighbor_iface_addrは隣接ノード（すなわち、リンクの他のエンドポイント）のインタフェースアドレスである、L_SYM_timeは、リンクが対称であると考えられるまでの時間であります、L_ASYM_timeは、近接インターフェイスが聞いたと見なされ、L_timeはこのレコードの有効期限が切れる時刻を指定し、* MUST *が削除されるまでの時間です。 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ホップ隣人、のMPRと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は、ノードがNOT_SYMまたはSYMの場合N_statusが指定した、隣人の主なアドレスです。 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.
（定義によりMPRリンクも対称であるので、それによってもMPR、など）ノードは、その近隣と対称の2ホップ近隣との間のリンクを対称記述、「2ホップタプル」（N_neighbor_main_addr、N_2hop_addr、N_time）のセットを記録します。 N_neighbor_main_addrネイバーのメインアドレスであり、N_2hop_addrはN_neighbor_main_addr対称のリンクを有する2ホップネイバーのメインアドレスであり、そしてN_timeタプルが満了すると* MUST *除去される時刻を指定します。
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はタプルの有効期限が切れると* MUST *削除された時刻を指定します。
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はこのタプルの有効期限が切れると* MUST *削除された時刻を指定します。
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:
次のようにMIDメッセージの提案されたフォーマットです。
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.
これはMID_MESSAGEに設定された「メッセージタイプ」と、セクション3.4に記載された一般的パケットフォーマットのデータ部分として送信されます。生存時間は、ネットワーク全体にメッセージを拡散する255（最大値）に設定されるべきであり、セクション18.3で指定されるようにVTIMEは、MID_HOLD_TIMEの値に応じて設定します。
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).
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.
発信元ノードのメインアドレス以外のすべてのインターフェイスアドレスはMIDメッセージに入れています。依然としてMIDmessageに挿入されていないアドレスがインターフェースしている間、最大許容メッセージサイズが（ネットワークによって課される）に達した場合、全体のインタフェースアドレスが送信された設定するまで、より多くのMIDメッセージが生成されます。
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メッセージ内の部分とすることができるが、ノードから設定インターフェースを記述する全MIDメッセージの構文解析は、特定のリフレッシュ期間内に完了しなければなりません（MID_INTERVAL） 。これらのMIDメッセージによってネットワーク内で拡散した情報は、そのルーティングテーブルを計算するために、各ノードに役立ちます。 MANETに参加して単一のインタフェースアドレスを持つノード（すなわち、OLSRを実行する）、任意のMIDメッセージを生成してはいけません。
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を実行している複数のインターフェイスを有するノードは、任意のMIDメッセージを生成してはいけません（例えば、ノードは、有線ネットワークに、ならびにMANETに接続されています）。
A node with several interfaces, where more than one is participating in the MANET and running OLSR MUST generate MID messages as specified.
複数のMANETに参加し、指定されOLSRはMIDメッセージを生成しなければなりません実行している複数のインターフェイスを有するノード。
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.
MIDメッセージが放送され、ネットワーク全体でメッセージを拡散させるためにのMPRによって再送されています。 （セクション3.4を参照）、「デフォルトの転送アルゴリズムは、」MIDメッセージの転送に使用しなければなりません。
The tuples in the multiple interface association set are recorded with the information that is exchanged through MID messages.
複数のインタフェース協会セット内のタプルは、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:
（セクション3.3.2で説明したように）MIDメッセージを受信すると、「有効期限」は、メッセージヘッダーのVTIMEフィールドから計算されなければなりません。次のように複数のインタフェース協会情報ベースは、更新する必要があります。
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:
MIDメッセージにリストされた各インタフェースアドレスのための2：
2.1 If there exist some tuple in the interface association
set where:
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_main_addr =発信元アドレス、
I_time = current time + validity time.
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.
共通の機構は、ローカルリンク情報ベースと近隣情報ベース、HELLOメッセージの、すなわち周期交換を取り込むために用いられます。したがって、このセクションは、それぞれ、リンク感知およびトポロジ検出の説明に続いて、一般的なHELLOメッセージ機構を記載しています。
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.
これはHELLO_MESSAGEに設定された「メッセージタイプ」、1に設定されたTTLフィールド（1）と、セクション3.4に記載された一般的パケットフォーマットのデータ部分として送信され、VTIMEはNEIGHB_HOLD_TIMEの値に応じて設定され、セクションで指定されています18.3。
Reserved
予約済み
This field must be set to "0000000000000" to be in compliance with this specification.
このフィールドは、この仕様に準拠するために、「0000000000000」に設定する必要があります。
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を参照します）。ハロー発光間隔は、その仮数（HTIMEフィールドの4最高ビット）によって、その指数（HTIMEフィールドの4最下位ビット）で表現されます。言い換えると：
HELLO emission interval=C*(1+a/16)*2^b [in seconds]
ハロー発光間隔[秒] = C *（1 + / 16）* 2 ^ B
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フィールドのとHTIMEフィールドの4最下位ビットで表される整数B 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として選択してはなりません。意欲WILL_ALWAYS有するノードは、常に、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つのビットそれぞれの二つの異なるフィールドを保持するように解釈されなければなりません。
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:
以下の三つの「隣人の種類は、」OLSRにより必要とされています。
- SYM_NEIGH - indicating that the neighbors have at least one symmetrical link with this node.
- SYM_NEIGH - 隣人がこのノードを有する少なくとも一つの対称のリンクを持っていることを示します。
- MPR_NEIGH - indicating that the neighbors have at least one symmetrical link AND have been selected as MPR by the sender.
- MPR_NEIGH - 隣人が少なくとも一つの対称のリンクを持っており、送信者が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_LINKで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、MPR_NEIGHの一つではない数値を広告近隣Typeフィールドは、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メッセージは、したがって、ローカルリンク情報ベースからローカルリンクセット、隣接セットおよび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こんにちはが送信されるインタフェース、及びここ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> =現在の時刻（有効期限が切れていない）AND
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 <現在の時刻（期限切れ）とIF
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:
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
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ネイバータイプの場合= 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インタフェースを備えたノードのために、主アドレスがL_neighbor_iface_addrに対応するL_neighbor_iface_addr単に、単に単一のOLSRインタフェースを有するノードのメインアドレスのOLSRインタフェース、即ち、のアドレスです。
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.
HELLOメッセージは、部分的であってもよい（例えば、原因ネットワークによって課されるメッセージサイズの制限、に）、ルールは、各インターフェイスに、以下である：各リンク及び各隣接ノードが所定のリフレッシュ期間、REFRESH_INTERVAL内に少なくとも一度引用しなければなりません。高速な接続の変更を追跡するために、HELLOメッセージは、少なくともより小さいかREFRESH_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セレクタのセット集団を行うために、着信HELLOメッセージを処理する（セクション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.
リンク・センシングは、ローカルリンク情報ベースに移入されます。リンク検出は、OLSRインタフェースのアドレスと、そのようなOLSRインタフェースの間でパケットを交換する能力を持つ排他関係です。
The mechanism for link sensing is the periodic exchange of HELLO messages.
リンク検出のためのメカニズムはHELLOメッセージの定期的な交換です。
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.
リンクセットは、隣接ノードへのリンクに関する情報が移入されます。このセットをポピュレートするプロセスは、「リンク・センシング」で示され、各ノード内のローカルリンク情報ベースを更新し、ハローメッセージ交換を使用して行われます。
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).
リンク検出の目的のために、各隣接ノード（より具体的には、各ネイバーへのリンク）、「対称」または「非対称」のいずれかの関連した状態を有します。 「対称」は隣接ノードへのリンク、すなわち、両方向にデータを送信することが可能で、双方向であることが検証されたことを、示しています。 「非対称は、」ノードからのHELLOメッセージが聞こえてきたことを示している（すなわち、隣接ノードからの通信が可能である）、しかし、このノードが、メッセージを受信することが可能であることが確認できていない（すなわち、隣接ノードへの通信が確認されていません）。
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メッセージを受信したノードは、そのリンクセットを更新する必要があります。 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:
Helloメッセージを受信すると、「有効期限」は、メッセージヘッダーのVTIMEフィールドから計算されなければならない（セクション3.3.2を参照）。その後、次のようにリンクセットを更新する必要があります。
1 Upon receiving a HELLO message, if there exists no link tuple with
1とはリンクタプルが存在しない場合は、Helloメッセージを受信します
L_neighbor_iface_addr == Source Address
L_neighbor_iface_addr ==送信元アドレス
a new tuple is created with
新しいタプルを使用して作成されました
L_neighbor_iface_addr = Source Address
L_neighbor_iface_addr =送信元アドレス
L_local_iface_addr = Address of the interface which received the HELLO message
Helloメッセージを受信したインタフェースの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.1 L_ASYM_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ノードは次のようにタプルが変更されたリンク・メッセージにリストされているアドレスのうちHelloメッセージを受信したインタフェースのアドレスを発見した場合。
2.2.1
if Link Type is equal to 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
リンクタイプは、その後SYM_LINKまたはASYM_LINKと等しい場合、他の2.2.2
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を設定するための上記のルールは次のようです。これは、隣人がリンク切れを検出することができます。
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つのリンクがある場合にのみので、これら二組の間の明確な関連があります。
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
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
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)
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:
If the neighbor has any associated link tuple which
indicates a symmetric link (i.e., with L_SYM_time >=
current time), then
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つの関連付けられたリンクタプルを持っていること。
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:
前述したようにHelloメッセージを受信すると、ノードはまず、そのリンクセットを更新する必要があります。これは次のようにその隣接セットを更新する必要があります：
- if the Originator Address is the N_neighbor_main_addr from a neighbor tuple included in the Neighbor Set:
- 発信元アドレスは、ネイバーセットに含ま隣接タプルからN_neighbor_main_addrの場合：
then, the neighbor tuple SHOULD be updated as follows:
次のように、隣のタプルを更新する必要があります。
N_willingness = willingness from the HELLO message
HELLOメッセージからN_willingness =意欲
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.
対称ネイバーからHelloメッセージを受信すると、ノードは、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).
Helloメッセージを受信すると、「有効期限」は、メッセージヘッダーの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：SYM_NEIGH又はMPR_NEIGHに等しい隣接タイプでHELLOメッセージに記載されている（以下、2ホップネイバーアドレス）：
1.1 if the main address of the 2-hop neighbor address = main
address of the receiving node:
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 =差出人アドレス。
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:
NOT_NEIGHに等しい隣接タイプでHELLOメッセージにリストされた各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は、領域内で発生する再送回数を削減しつつ、ネットワーク内のノードからの制御メッセージをフラッディングするために使用されます。このように、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.
それぞれ独立にネットワークが選択中のノード、その対称の1ホップ隣接間のMPRの独自のセット。 MPR対称のリンクがHELLOメッセージでリンクタイプMPR_NEIGHの代わりSYM_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ホップネイバーに到達できるようにノードによって計算しなければなりません。 （ノードは、別のノードの直接隣接している、A、B、また、ノードBの厳密な2ホップネイバーではないことに注意してください）。これは、MPRノードの対称の1ホップ近隣の組合が対称厳密2ホップ隣接を含むことを意味します。 MPRは、変更が対称周辺にまたは対称厳密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セットが最小であることは必須ではないが、すべて厳格2ホップネイバーが選択したMPRノードを介して到達できることが不可欠です。ノードは、任意の厳しい2ホップネイバーは、少なくとも一つの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異なる意欲と、ワンMPRノードによって中継を介して対称厳密2ホップ近傍内の任意のノードに到達するためにノードを可能MPRセットを構築します。ヒューリスティックは、インターフェイスごとに適用されなければならない、ノードのI.ザ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.
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.
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.
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
(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 WILL_ALWAYSに等しいN_willingnessとNのすべてのメンバーからなるMPRセットで開始
2 Calculate D(y), where y is a member of N, for all nodes in N.
YがNのすべてのノードのために、Nのメンバーである2計算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がNでノード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は、MPRセットにおける少なくとも1つのノードによって覆われていないN2のノードが存在する中：
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.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として非ゼロ到達可能性のあるN個のノードの中で最高N_willingness有するノードを選択します。複数の選択肢の場合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の結合から生成されるインタフェースごとに設定します。最適化プロセスの各ノード、Y、N_willingnessの昇順に設定MPRです。 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」との間の複数のリンクが存在すると仮定する。 「」のいずれかのインターフェイスのためのMPRとしてのノードBを選択しているノードの場合、ノードbは、ノード上の他のインタフェースによって追加の性能損失「」なし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.
ノードのMPRセレクタのセットは、N、MPRとしてNを選択しているノードのメインアドレスによって取り込まれます。 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.
ノードが見つかった場合MPR_NEIGHに等しい隣接タイプのリストに、それ自身のインタフェースアドレスのいずれかをHelloメッセージを受信すると、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:
「有効時間」メッセージヘッダ（セクション3.3.2を参照）のVTIMEフィールドから計算されなければなりません。次のように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
MS_main_addr =差出人アドレス
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".
「周辺に位置し、2ホップ近隣変更」に記載されているようにMPRセレクタタプルの削除タイマーが満了した場合にリンクの破損の場合に発生します。
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
- 隣人の損失の場合には、隣のMS_main_addr ==主なアドレスを持つすべてのMPRセレクタのタプルを削除する必要があります
- 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.
- 隣接外観または損失が検出された場合、または2ホップの近傍の変化が検出された場合MPRセットが再計算されなければなりません。
- An additional HELLO message MAY be sent when the MPR set changes.
- MPRが変更を設定すると、追加のHELLOメッセージを送るかもしれません。
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に設定された「メッセージタイプ」の一般的なメッセージフォーマットのデータ部分として送信されます。生存時間は、ネットワーク全体にメッセージを拡散する255（最大値）に設定されるべきであり、セクション18.3で指定されるようにVTIMEは、TOP_HOLD_TIMEの値に応じて設定します。
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.
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.
Reserved
予約済み
This field is reserved, and MUST be set to "0000000000000000"
for compliance with this document.
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の数が増加しているはずです。
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メッセージは、ネットワーク内のすべてのノードにフラッディングとのMPRを利用しています。 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_INTERVAL内に完了していなければなりません）。これらの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-メッセージの「有効時間」に等しい期間中（空）TC-メッセージ（典型的には、これはTOP_HOLD_TIMEに等しいであろう）を送信すべきです、前回の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.
ノードは、リンク障害へのreactivenessを高めるために、追加のTC-のメッセージを送信してもよいです。 MPRセレクタセットへの変更が検出されると、この変更は、リンク障害に起因することができたとき、TCメッセージはTC_INTERVALよりも短い間隔の後に送信されるべきです。
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メッセージは、ネットワーク全体でメッセージを拡散させるためにのMPRで放送され、再送信されます。 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:
TCメッセージで受信アドバタイズネイバーメインアドレスの各4：
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 ==宣伝隣人主なアドレスと、
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 =発信元アドレス、
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. ,, ,, ,, ,,
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_next_addr対称隣接ノードがR_dest_addrへのルート内の次ホップノードであることを、この対称的な隣接ノードを介して到達可能であること、離れてローカルノードからのホップR_dest_addrによって識別されるノードをR_distと推定されることを指定しますアドレス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は、（SYMに等しい隣接タイプの）Xの任意の対称の隣人、円弧であるY Y - > Z場合YはWILL_NEVERの異なる意欲を持つ隣接ノードであり、N_2hop_addrとしてN_neighbor_main_addr及びZとしてYで設定2ホップネイバーにエントリが存在し、そしてアークU - Vで設定トポロジにエントリが存在する> V、 T_last_addrとしてT_dest_addrやUなど。
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
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_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。
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;
L_time> =現在時刻に関連付けられたリンクタプルの一つの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。
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:
N2の各ノードのための3、すなわち、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_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;
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 + 1ホップ離れルーティングテーブルに記録されている宛先ノードの時間のための新しいルートエントリ。以下の手順は、h = 2で開始し、1ずつそれをインクリメント、hの各値に対して実行されなければなりません。新しいエントリが反復に記録されていない場合、実行が停止します。
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:
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_dist =さh + 1。そして
R_iface_addr = R_iface_addr of the recorded route entry where:
ここで、記録されたルートエントリの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)
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_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のMANETで動作するために、構成する方法を概説します。
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ネットワークのノード、すなわち、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 MANETに参加していないいくつかは、複数のインタフェースを備えていてもよいです。これらの非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インタフェース（複数可）へのOLSR MANETインタフェース（S）からの接続を提供するために、ノードは、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インタフェースにOLSR MANETからルーティング情報を注入することは、この明細書の範囲外です。これは、ルーティング（OLSR MANETのためのルーティング情報がトポロジテーブルから抽出された（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に外部ルーティング情報を注入するこの能力を提供するために、このような非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.
これはHNA_MESSAGE、TTLフィールド255に設定され、セクション18.3で指定されるようにVTIMEは、HNA_HOLD_TIMEの値に応じて設定するために設定された「メッセージタイプ」の一般的なパケットフォーマットのデータの一部として送信されます。
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.
各ノードは、ノードが記録することで関連するホストとネットワークへの「ゲートウェイ」「会合タプル」A_gateway_addrゲートウェイ、A_network_addrとA_netmaskのOLSRインタフェースのアドレスである（A_gateway_addr、A_network_addr、A_netmask、A_time）として作用することができるに関する情報を維持しますこのゲートウェイを介して到達可能な、ネットワークのネットワークアドレスとネットマスクを指定し、A_timeこのタプルの有効期限が切れ、したがって* MUST *除去される時刻を指定します。
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-のメッセージでは、ネットマスクは、必要ありません。 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-メッセージとの間の重要な違いは、（ANSNがインクリメントされている場合）HNA-メッセージ内の情報のみ満了すると除去され、一方、TCメッセージは、以前の情報に相殺効果を有し得ること、です。
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を送信するべきです。セクション18.3で指定されるようにVTIMEは、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.
このセクションでは、用語「発信元アドレスが」元々HNAメッセージを発行したノードのOLSR MANETのメインアドレスを指定するために使用されます。
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そうでない場合は、メッセージ内の各（ネットワークアドレス、ネットマスク）対について：
2.1 if an entry in the association set already exists, where:
2.1既に設定関連のエントリは、ここで、存在する場合：
A_gateway_addr == originator address
A_gateway_addr ==発信元アドレス
A_network_addr == network address
A_network_addr ==ネットワークアドレス
A_netmask == netmask
A_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_gateway_addr =発信元アドレス
A_network_addr = network address
A_network_addr =ネットワークアドレス
A_netmask = netmask
A_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にDIST、
then the routing entry is modified as follows:
次のようにルーティングエントリが変更されます。
R_dest_addr = A_network_addr/A_netmask
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_next_addrはA_gateway_addrのノードから経路上の次のホップを=
R_dist = dist to A_gateway_addr
A_gateway_addrにR_dist = DIST
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).
L_LOST_LINK_timeの有効期限が切れていない1場合は、リンクがLOST_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.
L_LOST_LINK_timeの有効期限が切れていない1場合は、リンクがLOST_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が「真」に設定されている場合、2はそうでない場合は、リンクがすべてで宣伝すべきではありません。
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はセクション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は「偽」であり、
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_statusを計算する（セクション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.
ノードとその隣接インターフェイスの一部との間のリンク、すなわち、随時のhelloが直後にフェードアウトすることのみを通過させ、「不良」であるかもしれません。この場合、隣接情報ベースは、少なくとも「有効期限」のための悪いリンクが含まれます。以下のヒステリシス戦略は、このような状況に対抗するために採用されるべきです。
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の値は、0と1とHYST_THRESHOLD_HIGH> = HYST_THRESHOLD_LOWように間に固定された2つの閾値HYST_THRESHOLD_HIGH、HYST_THRESHOLD_LOW、と比較されます。
The L_link_pending field is set according to the following:
L_link_pendingフィールドは、以下に従って設定されます。
1 if L_link_quality > HYST_THRESHOLD_HIGH:
1 L_link_quality> HYST_THRESHOLD_HIGH場合：
L_link_pending = false
偽L_link_pending =
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_link_pending =真
L_LOST_LINK_time = min (L_time, current time + NEIGHB_HOLD_TIME)
L_LOST_LINK_time =分（L_time、現在時刻+ NEIGHB_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にHYST_THRESHOLD_LOW下回ることができ、このように注意してください。
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で説明したように）Helloメッセージを受信しました。具体的には、これは関係なく、リンクヒステリシスは「確立」などのリンクを考慮するか否かの、リンクセット内のタプルがリンクタプルの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).
無信号/ノイズ情報又は他のリンク品質情報は、以下の（それは送信成功率の指数関数的平滑移動平均である）を利用することができるように、リンク層、アルゴリズムから利用できない場合。アルゴリズムは、I、NIはI、L_link_qualityによって聞かれる最初の時間がHYST_SCALINGに設定されているインタフェースに聞こえる各隣接インターフェースNIは0と1の間に固定された数（L_link_pendingがtrueに設定されているスケーリングパラメータHYST_SCALINGによってパラメータ化され現在の時刻にL_LOST_LINK_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:
タプルは、二つのルールに従って更新されます。 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.
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パケットのロスは、インタフェースごとに欠落したパケットのシーケンス番号を追跡することによって、ノードからの「沈黙の長い期間」によって検出されます。沈黙の「長い期間は、このように検出することができる：NO OLSRパケット（NIから受信した最後のHELLOメッセージでHTIMEフィールドから計算された）インターフェイスNIのハロー発光間隔の間にインターフェイスNIから界面Iで受信されていない場合、損失を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セレクタのセットに含まれていない隣接ノードへのリンクを含むかもしれません。宣伝リンクセットは、ノードの全体の隣接セットへのリンクを含むことができます。いずれかのノードがその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である場合には（セクション8.3で説明したように）、そのノードのアドバタイズリンクセットはMPRセレクタのセットに制限され、
- 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メッセージは次のように送信ノードを選択している隣人、そのMPRセレクタセットのすべてのノードに、少なくともリンクを含まなければならない広告を出してリンク集合、すなわちと呼ばれる、リンクのセットを宣言するために、ネットワーク内のノードによって送信されます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 TC_REDUNDANCYの= 0のセクションと同じ、情報宣言がMPRセレクタのセットに正確に対応することを意味9.その他の値は、宣言する追加情報を指定し、すなわち、MPRセレクタのセットの内容は常に宣言されます。制御メッセージは、セクション3に従って、すべてのノードによって運ばれ、そして全てのノードは、セクション10で説明したようにルートを構築するために必要とされる少なくともリンクステート情報を受信する。したがって、TC_REDUNDANCYの異なる値を持つノードがネットワークに共存させてもよいです。
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の冗長性は冗長のMPRを選択するノードのための能力を指定します。 4.5節では、ノードがプロトコルのオーバーヘッドを削減するために、可能な限り小さくするために、そのMPRセットを選択する必要があることを指定します。 MPRを選択するための基準は全て、厳密な2ホップノードは、少なくとも一つ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は、任意の厳しい2ホップノードがカバーされるべきノードの数により指定して、単一のローカルパラメータ、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選択ヒューリスティックは、一つの定義によってセクション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.
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.
YがNのすべてのノードのために、Nのメンバーである2計算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のMPR N2に難覆われたノードを覆うNにおけるそれらのノードとして選択します。ノードは、次に、計算の残りのN2から除去されます。
4 While there exist nodes in N2 which are not covered by at least MPR_COVERAGE nodes in the MPR set:
4 MPRセットに少なくともMPR_COVERAGEノードによって覆われていないN2のノードが存在するが：
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.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として非ゼロ到達可能性のある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の結合から生成されるインタフェースごとに設定します。最適化プロセスの各ノード、Y、N_willingnessの昇順に設定MPRです。 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.
ノードのMPRセットは、セクション8.3によると、それは、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.
制御メッセージは、セクション3に従って、すべてのノードによって運ばれ、そしてすべてのノードは、セクション9及び10に記載したようにルートを構築するために必要とされる少なくともリンクステート情報を受信する。MPR_COVERAGEの異なる値を持つノードがネットワークに共存させてもよいです。
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で動作するIPバージョン6のOLSRで使用されるものと同じであり、唯一の必要な変更は、IPv6アドレスとIPv4アドレスを交換することです。最小パケットおよびメッセージサイズは（その下拒絶がある）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)
（0.0625秒に等しい）Cは、= 1/16秒
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.3で指定されるように（セクション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
HELLO_INTERVAL = 2秒
REFRESH_INTERVAL = 2 seconds
REFRESH_INTERVAL = 2秒
TC_INTERVAL = 5 seconds
TC_INTERVAL = 5秒
MID_INTERVAL = TC_INTERVAL
MID INTERVAL = TV_INTERVAL
HNA_INTERVAL = TC_INTERVAL
HNA INTERVAL = TV_INTERVAL
NEIGHB_HOLD_TIME = 3 x REFRESH_INTERVAL
NEIGHB_HOLD_TIME = 3×REFRESH_INTERVAL
TOP_HOLD_TIME = 3 x TC_INTERVAL
TOP_HOLD_TIME = 3×TC_INTERVAL
DUP_HOLD_TIME = 30 seconds
DUP_HOLD_TIME = 30秒
MID_HOLD_TIME = 3 x MID_INTERVAL
MID_HOLD_TIME = 3×MID_INTERVAL
HNA_HOLD_TIME = 3 x HNA_INTERVAL
HNA_HOLD_TIME = 3×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]
[秒]の値= C *（1 + / 16）* 2 ^ B
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最下位ビットで表される整数B 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:
上記保持時間のいずれかの、数T（秒）の仮数/指数表現を計算する方法与えられた以下の通りです。
- 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 *（1 T /（C×（2 ^ B））を）計算します。これは、「A」の値になり
- if 'a' is equal to 16: increment 'b' by one, and set 'a' to 0
- 「16」に等しい場合：つによってインクリメント「B」、及び '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は次のようになります（= 0、B = 5）、（= 8、B = 6）、（A = 14 、B = 7）及び（A = 14、B = 8）でした。
HELLO_MESSAGE = 1
HELLO_MESSAGE = 1
TC_MESSAGE = 2
TC_MESSAGE = 2
MID_MESSAGE = 3
MID_MESSAGE = 3
HNA_MESSAGE = 4
Hnamsj = 4
UNSPEC_LINK = 0
UNSPEC_LINK = 0
ASYM_LINK = 1
ASYM_LINK = 1
SYM_LINK = 2
SYM_LINK = 2
LOST_LINK = 3
LOST_LINK = 3
NOT_NEIGH = 0
NOT_NEIGH = 0
SYM_NEIGH = 1
SYM_NEIGH = 1
MPR_NEIGH = 2
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_NEVER = 0
WILL_LOW = 1
WILL_LOW = 1
WILL_DEFAULT = 3
WILL_DEFAULT = 3
WILL_HIGH = 6
WILL_HIGH = 6
WILL_ALWAYS = 7
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_DEFAULTを持つことになります。 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.
一つの可能なアプリケーションは、例えば、WILL_ALWAYSの意欲をアドバタイズするために、永久電源に完全に充電されたバッテリーに接続されたノードのためであろう。永久電源から切断されるとWILL_DEFAULTの意欲がアドバタイズされ、（例えば、PDAは、その充電クレードルから取り出されます）。バッテリ容量が排出されると、意欲がさらに減少するであろう。まずWILL_DEFAULTとWILL_LOW間の中間値に、ノードのバッテリ容量は、もはや外国トラフィックを運ぶサポートしない場合、WILL_NEVERにようやくWILL_LOWないとします。
TC_REDUNDANCY = 0
TC_REDUNDANCY = 0
MPR COVERAGE = 1
MPRカバレッジ= 1
MAXJITTER = HELLO_INTERVAL / 4
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
S1> S2とS1 - S2 <= MAXVALUE / 2 OR
S2 > S1 AND S2 - S1 > MAXVALUE/2
S2> S1と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.
ネットワークトポロジの機密性が重要である状況では、そのようないくつかの共有秘密鍵で[9] PGPによって暗号化または暗号化されたOLSR制御トラフィックメッセージの交換などの定期的な暗号技術を読み出して解釈することができる制御トラフィックを確実にするために適用することができますものだけでそうすることを承認しました。
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は、各ノードは、いくつかのノード、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ノードは、HELLOメッセージ、広告非隣接ノードを生成し、
4 a node generates HELLO messages, pretending to be another node.
4ノードが別のノードになりすまし、HELLOメッセージを生成します。
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.
個々のリンク（状況1及び3）の真正性を配布する追加のセキュリティ情報を必要とするのに対し、具体的には、全体のOLSR制御メッセージの信憑性は、使用するIPsec認証ヘッダを介して確立することができます。
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におけるすべての制御メッセージは、近隣内のすべてのノードのいずれかを送信し（helloメッセージ）またはネットワーク（例えば、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における制御メッセージは、常に、ポイント・ツー・マルチポイント送信です。認証機構は、任意の受信ノードがメッセージの真正性を検証する許可を用いることが重要です。アナロジーとして、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.
ノードを操作する際のセクション20.2に記載されているよう以外の、外部ルーティングドメインにOLSRを接続、注意が外部ルーティングドメインに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の既存のルーティングドメインからの接続を拡張する推奨される方法は、MANETは、排他的にOLSR MANET領域に（出ルーティングドメインとMANETを接続するノード/ゲートウェイの権限の下で）IPプレフィックスを割り当てること、および構成するルーティングゲートウェイは、静的に、既存のルーティングドメイン内のノードにその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オプションで、いくつかの制御メッセージは、意図的にトポロジの変更に対するプロトコルのreactivenessを増加させるためにそれらのデッドライン（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.
著者は、ジャスティン・ディーンを含め、ジョセフMacker <macker@itd.nrl.navy.mil>と彼のチームに感謝したいと思います<jdean@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選択ヒューリスティックに貴重な入力のために、プロトコル仕様の慎重なレビューのためにクリストファー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
セドリックAdjihプロジェクトHIPERCOM INRIA Rocquencourt BP 105 78153シェズネーセデックス、フランス
Phone: +33 1 3963 5215 EMail: Cedric.Adjih@inria.fr
電話：+33 1 3963 5215 Eメール：Cedric.Adjih@inria.fr
Thomas Heide Clausen Project HIPERCOM INRIA Rocquencourt, BP 105 78153 Le Chesnay Cedex, France
トーマス・ハイデクラウゼンプロジェクトHIPERCOM INRIA Rocquencourt BP 105 78153シェズネーセデックス、フランス
Phone: +33 1 3963 5133 EMail: T.Clausen@computer.org
電話：+33 1 3963 5133 Eメール：T.Clausen@computer.org
Philippe Jacquet Project HIPERCOM INRIA Rocquencourt, BP 105 78153 Le Chesnay Cedex, France
フィリップジャケプロジェクトHIPERCOM INRIA Rocquencourt BP 105 78153シェズネーセデックス、フランス
Phone: +33 1 3963 5263 EMail: Philippe.Jacquet@inria.fr
電話：+33 1 3963 5263 Eメール：Philippe.Jacquet@inria.fr
Anis Laouiti Project HIPERCOM INRIA Rocquencourt, BP 105 78153 Le Chesnay Cedex, France
アニスLaouitiプロジェクトHIPERCOM INRIA Rocquencourt BP 105 78153シェズネーセデックス、フランス
Phone: +33 1 3963 5088 EMail: Anis.Laouiti@inria.fr
電話：+33 1 3963 5088 Eメール：Anis.Laouiti@inria.fr
Pascale Minet Project HIPERCOM INRIA Rocquencourt, BP 105 78153 Le Chesnay Cedex, France
パスカルMINETプロジェクトHIPERCOM INRIA Rocquencourt BP 105 78153シェズネーセデックス、フランス
Phone: +33 1 3963 5233 EMail: Pascale.Minet@inria.fr
電話：+33 1 3963 5233 Eメール：Pascale.Minet@inria.fr
Paul Muhlethaler Project HIPERCOM INRIA Rocquencourt, BP 105 78153 Le Chesnay Cedex, France
ポールMuhlethalerプロジェクトHIPERCOM INRIA Rocquencourt BP 105 78153シェズネーセデックス、フランス
Phone: +33 1 3963 5278 EMail: Paul.Muhlethaler@inria.fr
電話：+33 1 3963 5278 Eメール：Paul.Muhlethaler@inria.fr
Amir Qayyum Center for Advanced Research in Engineering Pvt. Ltd. 19 Ataturk Avenue Islamabad, Pakistan
エンジニアリングのPVTの高度な研究のためのアミール・ケイアムセンター。 （株）19アタチュルク大通りイスラマバード、パキスタン
Phone: +92-51-2874115 EMail: amir@carepvtltd.com
電話：+ 92-51-2874115電子メール：amir@carepvtltd.com
Laurent Viennot Project HIPERCOM INRIA Rocquencourt, BP 105 78153 Le Chesnay Cedex, France
ローランViennotプロジェクトHIPERCOM INRIA Rocquencourt BP 105 78153シェズネーセデックス、フランス
Phone: +33 1 3963 5225 EMail: Laurent.Viennot@inria.fr
電話：+33 1 3963 5225 Eメール：Laurent.Viennot@inria.fr
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[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.ジャケ、A. Laouiti、P. Muhlethaler、A. Qayyum及びL. Viennot。リンクステートルーティングプロトコルは、最適化されています。 IEEE INMICパキスタン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.ジャケ、P. MINET、P. Muhlethaler、N. Rivierre。ケーブルの自由ラジオのLANでの信頼性の向上：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タイプ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.ジャケとL. Viennot、モバイルアドホックネットワークプロトコル、INRIAの研究報告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.ハンセン、L.クリステンセン及びG. Behrmann。実験とシミュレーションによる最適化されたリンクステートルーティングプロトコル、評価。 「無線パーソナル・モバイルコミュニケーションズ」のIEEEシンポジウム、2001年9月。
[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]アトキンス、D.、ストーリングス、W.およびP.ツィンマーマン、 "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.ジャケ、A. Laouiti、P. MINET、L. Viennot。 OLSRのパフォーマンス分析は、2つのアドホック無線ネットワークモデルでINRIAの研究報告RR-4260、2001年の洪水を中継マルチポイント。
Thomas Heide Clausen Project HIPERCOM INRIA Rocquencourt, BP 105 78153 Le Chesnay Cedex, France
トーマス・ハイデクラウゼンプロジェクトHIPERCOM INRIA Rocquencourt BP 105 78153シェズネーセデックス、フランス
Phone: +33 1 3963 5133 EMail: T.Clausen@computer.org
電話：+33 1 3963 5133 Eメール：T.Clausen@computer.org
Philippe Jacquet, Project HIPERCOM, INRIA Rocquencourt, BP 105 78153 Le Chesnay Cedex, France
フィリップジャケ、HIPERCOMプロジェクト、INRIA Rocquencourt、BP 105 78153シェズネーセデックス、フランス
Phone: +33 1 3963 5263, EMail: Philippe.Jacquet@inria.fr
電話：+33 1 3963 5263、Eメール：Philippe.Jacquet@inria.fr
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。