RFC3626 日本語訳
3626 Optimized Link State Routing Protocol (OLSR). T. Clausen, Ed., P.Jacquet, Ed.. October 2003. (Format: TXT=161265 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group T. Clausen, Ed.
Request for Comments: 3626 P. Jacquet, Ed.
Category: Experimental Project Hipercom, INRIA
October 2003
エド、ワーキンググループT.クローゼンをネットワークでつないでください。コメントのために以下を要求してください。 3626 エドP.ジャケ、カテゴリ: 実験的な計画Hipercom、INRIA2003年10月
Optimized Link State Routing Protocol (OLSR)
最適化されたリンク州のルーティング・プロトコル(OLSR)
Status of this Memo
この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.
Copyright(C)インターネット協会(2003)。 All rights reserved。
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.
このドキュメントは可動の臨時のネットワークのためにOptimized Link州ルート設定(OLSR)プロトコルについて説明します。 プロトコルは可動の無線LANの要件に適合した古典的なリンク州のアルゴリズムの最適化です。 プロトコルに使用される重要な考えは多点リレー(MPRs)のものです。 MPRsは氾濫の過程の間に同報メッセージを転送する選択されたノードです。 古典的な氾濫メカニズム(メッセージの第一刷を受けるとき、あらゆるノードが各メッセージを再送する)と比べて、このテクニックはかなりメッセージオーバーヘッドを下げます。 OLSRでは、リンク州の情報はMPRsとして選出されたノードだけで発生します。 したがって、2番目の最適化は、ネットワークで水につかっているコントロールメッセージの数を最小にすることによって、達成されます。 3番目の最適化として、MPRノードは選ぶかもしれません。それ自体とそのMPRセレクタとのリンクだけを報告するのを選びました。 したがって、古典的なリンク州のアルゴリズムとは逆に、部分的なリンク州の情報はネットワークで分配されます。 そして、この情報はルート計算に使用されます。 OLSRは最適のルート(ホップの数に関する)を提供します。 MPRsのテクニックがこのような関係においてはうまくいくとき、プロトコルは特に大きくて濃いネットワークに適しています。
Clausen & Jacquet Experimental [Page 1] RFC 3626 Optimized Link State Routing October 2003
[1ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . 4 1.1。 OLSR用語。 . . . . . . . . . . . . . . . . . . . 5 1.2. 適用性。 . . . . . . . . . . . . . . . . . . . . . 7 1.3. 概観. . . . . . . . . . . . . . . . . . . 8 1.4について議定書の中で述べてください。 多点リレー. . . . . . . . . . . . . . . . . . . 9 2。 機能. . . . . . . . . . . . . . . . . . . . 9 2.1について議定書の中で述べてください。 コア機能. . . . . . . . . . . . . . . . . . . 10 2.2。 補助の機能. . . . . . . . . . . . . . . . . 12 3。 パケット・フォーマットと推進. . . . . . . . . . . . . . . . 13 3.1。 数を議定書の中で述べて、移植してください。 . . . . . . . . . . . . . . . 13 3.2. 主なアドレス. . . . . . . . . . . . . . . . . . . . . 13 3.3。 パケット・フォーマット. . . . . . . . . . . . . . . . . . . . . 14 3.3.1。 パケットのヘッダー. . . . . . . . . . . . . . . . . . 14 3.3.2。 メッセージヘッダー. . . . . . . . . . . . . . . . . 15 3.4。 パケット処理とメッセージ氾濫. . . . . . . . . 16 3.4.1。 アルゴリズムを進めて、デフォルトとしてください。 . . . . . . . . . . 18 3.4.2. 処理と推進. . . 20 3.5での問題。 メッセージ放出とジター。 . . . . . . . . . . . . . . 21 4. 情報倉庫. . . . . . . . . . . . . . . . . . 22 4.1。 複数のインタフェース協会情報が.224.2を基礎づけます。 感じをリンクしてください: 地方のリンク情報基地。 . . . . . . . 22 4.2.1. リンクはセットしました。 . . . . . . . . . . . . . . . . . . . . 22 4.3. 隣人検出: 近所Information基地。 . . . 23 4.3.1. 隣人はセットしました。 . . . . . . . . . . . . . . . . . . 23 4.3.2. 2ホップの隣人はセットしました。 . . . . . . . . . . . . . . . 23 4.3.3. MPRセット. . . . . . . . . . . . . . . . . . . . . 23 4.3.4。 MPRセレクタはセットしました。 . . . . . . . . . . . . . . . . 23 4.4. トポロジー情報基地. . . . . . . . . . . . . . . 24 5。 主なアドレスと倍数インタフェース. . . . . . . . . . . 24 5.1。 中間のメッセージ・フォーマット. . . . . . . . . . . . . . . . . . . 25 5.2。 中間のメッセージ世代. . . . . . . . . . . . . . . . . 25 5.3。 中間のメッセージ推進. . . . . . . . . . . . . . . . . 26 5.4。 中間のメッセージ処理. . . . . . . . . . . . . . . . . 26 5.5。 インターフェース・アドレス. . . 27 6からの主なアドレスを決議します。 こんにちは、メッセージ・フォーマットと世代. . . . . . . . . . . . . 27 6.1 こんにちは、メッセージ・フォーマット. . . . . . . . . . . . . . . . . . 27 6.1.1 リンク型と隣人がタイプするようにコードをリンクしてください。 . . . . 29 6.2. こんにちは、メッセージ世代. . . . . . . . . . . . . . . . 30 6.3 こんにちは、メッセージ推進. . . . . . . . . . . . . . . . 33 6.4 こんにちは、メッセージ処理. . . . . . . . . . . . . . . . 33 7 感じ. . . . . . . . . . . . . . . . . . . . . . . . 33 7.1をリンクしてください。 リンクセット. . . . . . . . . . . . . . . . 33 7.1.1に居住します。 こんにちは、メッセージ処理. . . . . . . . . . . . 34 8 隣人検出. . . . . . . . . . . . . . . . . . . . . 35 8.1。 隣人セット. . . . . . . . . . . . . . . 35 8.1.1に居住します。 こんにちは、メッセージ処理. . . . . . . . . . . . 37
Clausen & Jacquet Experimental [Page 2] RFC 3626 Optimized Link State Routing October 2003
[2ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
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
8.2. 2ホップの隣人に居住するのはセットしました。 . . . . . . . . . . . 37 8.2.1. こんにちは、メッセージ処理。 . . . . . . . . . . . . 37 8.3. MPRセット. . . . . . . . . . . . . . . . . 38 8.3.1に居住します。 MPR計算. . . . . . . . . . . . . . . . . 39 8.4。 MPRセレクタに居住するのはセットしました。 . . . . . . . . . . . . 41 8.4.1. こんにちは、メッセージ処理。 . . . . . . . . . . . . 41 8.5. 近所と2ホップの近所変化。 . . . . . . 42 9. トポロジー発見. . . . . . . . . . . . . . . . . . . . . 43 9.1。 Tcメッセージ・フォーマット。 . . . . . . . . . . . . . . . . . . . 43 9.2. 広告を出している隣人はセットしました。 . . . . . . . . . . . . . . . . 44 9.3. Tcメッセージ世代。 . . . . . . . . . . . . . . . . . 45 9.4. Tcメッセージ推進。 . . . . . . . . . . . . . . . . . 45 9.5. Tcメッセージ処理。 . . . . . . . . . . . . . . . . . 45 10. テーブル計算. . . . . . . . . . . . . . . . . . 47 11を発送します。 ノード構成。 . . . . . . . . . . . . . . . . . . . . . 50 11.1. 課題を記述してください。 . . . . . . . . . . . . . . . . . . 50 11.2. 構成. . . . . . . . . . . . . . . . . 51 11.3を発送します。 データ・パケット推進。 . . . . . . . . . . . . . . . . 51 12. 非OLSRは.51 12.1を連結します。 HNAメッセージ・フォーマット。 . . . . . . . . . . . . . . . . . . 52 12.2. 協会情報基地. . . . . 52 12.3を接待して、ネットワークでつないでください。 HNAメッセージ世代。 . . . . . . . . . . . . . . . . 53 12.4. HNAメッセージ推進。 . . . . . . . . . . . . . . . . 53 12.5. HNAメッセージ処理。 . . . . . . . . . . . . . . . . 53 12.6. テーブル計算. . . . . . . . . . . . . . . 54 12.7を発送します。 相互運用性問題. . . . . . . . . . . . 55 13。 層の通知. . . . . . . . . . . . . . . . . . . 55 13.1をリンクしてください。 相互運用性問題. . . . . . . . . . . . 56 14。 ヒステリシス. . . . . . . . . . . . . . . . . . . . . . . 56 14.1をリンクしてください。 地方のリンクセット. . . . . . . . . . . . . . . . . . . . 56 14.2。 こんにちは、メッセージ世代. . . . . . . . . . . . . . . 57 14.3 ヒステリシス戦略. . . . . . . . . . . . . . . . . . 57 14.4。 相互運用性問題. . . . . . . . . . . . 59 15。 余分なトポロジー情報。 . . . . . . . . . . . . . . . 59 15.1. Tc_冗長パラメタ. . . . . . . . . . . . . . . . 60 15.2。 相互運用性問題. . . . . . . . . . . . 60 16。 MPR冗長。 . . . . . . . . . . . . . . . . . . . . . . . 60 16.1. MPR_適用範囲パラメタ。 . . . . . . . . . . . . . . . . 61 16.2. MPR計算. . . . . . . . . . . . . . . . . . . . 61 16.3。 相互運用性問題. . . . . . . . . . . . 62 17。 IPv6問題. . . . . . . . . . . . . . . . . . . . . 63 18。 定数. . . . . . . . . . . . . . . . 63 18.1のために値を提案しました。 放出間隔を設定して、.63 18.2に回を保持します。 放出間隔. . . . . . . . . . . . . . . . . . . 64 18.3。 把持時間. . . . . . . . . . . . . . . . . . . . . 64 18.4。 メッセージは.65 18.5をタイプします。 タイプをリンクしてください。 . . . . . . . . . . . . . . . . . . . . . . 65 18.6. 隣人タイプ. . . . . . . . . . . . . . . . . . . . 65
Clausen & Jacquet Experimental [Page 3] RFC 3626 Optimized Link State Routing October 2003
[3ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
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
18.7. ヒステリシス. . . . . . . . . . . . . . . . . . . . 66 18.8をリンクしてください。 意欲. . . . . . . . . . . . . . . . . . . . . . 66 18.9。 ミスク 定数. . . . . . . . . . . . . . . . . . . . 67 19。 一連番号。 . . . . . . . . . . . . . . . . . . . . . . 67 20. セキュリティ問題. . . . . . . . . . . . . . . . . . . 67 20.1。 秘密性. . . . . . . . . . . . . . . . . . . . 67 20.2。 保全. . . . . . . . . . . . . . . . . . . . . . . 68 20.3。 外部の経路ドメイン. . . . . . . 69 20.4との相互作用。 ノードのアイデンティティ. . . . . . . . . . . . . . . . . . . . . 70 21。 流れと混雑は.70 22を制御します。 IANA問題. . . . . . . . . . . . . . . . . . . . . 70 23。 承認. . . . . . . . . . . . . . . . . . . . . . . 71 24。 貢献者。 . . . . . . . . . . . . . . . . . . . . . . . . 71 25. 参照。 . . . . . . . . . . . . . . . . . . . . . . . . . 73 26. 作者のアドレス。 . . . . . . . . . . . . . . . . . . . . . 74 27. 完全な著作権宣言文。 . . . . . . . . . . . . . . . . . . 75
1. Introduction
1. 序論
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.
Optimized Link州ルート設定プロトコル(OLSR)は可動の臨時のネットワークのために開発されます。 それはすなわち、動かされたテーブル、先を見越すプロトコル、交換として定期的にネットワークの他のノードでトポロジー情報を操作します。 各ノードは「多点リレー」(MPR)として隣人ノードの1セットを選定します。 OLSRでは、そのようなMPRsとして選定される唯一のノードが、推進コントロール交通に責任があって、拡散のために全体のネットワークに意図しています。 MPRsはトランスミッションの数を減少させるのによる交通が必要とした氾濫コントロールに効率的なメカニズムを提供します。
Nodes, selected as MPRs, also have a special responsibility when declaring link state information in the network. Indeed, the only requirement for OLSR to provide shortest path routes to all destinations is that MPR nodes declare link-state information for their MPR selectors. Additional available link-state information may be utilized, e.g., for redundancy.
また、リンク状態が情報であるとネットワークで宣言するとき、MPRsとして選定されるノードは特別な責任を持っています。 本当に、OLSRが最短パスルートをすべての目的地に提供するという唯一の要件はMPRノードがそれらのMPRセレクタのためのリンク州の情報を宣言するということです。 追加利用可能なリンク州の情報は例えば、冗長に利用されるかもしれません。
Nodes which have been selected as multipoint relays by some neighbor node(s) announce this information periodically in their control messages. Thereby a node announces to the network, that it has reachability to the nodes which have selected it as an MPR. In route calculation, the MPRs are used to form the route from a given node to any destination in the network. Furthermore, the protocol uses the MPRs to facilitate efficient flooding of control messages in the network.
多点リレーとして何らかの隣人ノードによって選定されたノードはそれらのコントロールメッセージで定期的にこの情報を発表します。 その結果、ノードはネットワークに知らせて、それはMPRとしてそれを選定したノードに可到達性を持っています。 ルート計算では、MPRsは、ネットワークでルートを与えられたノードからどんな目的地までも形成するのに使用されます。 その上、プロトコルは、ネットワークでのコントロールメッセージの効率的な氾濫を容易にするのにMPRsを使用します。
A node selects MPRs from among its one hop neighbors with "symmetric", i.e., bi-directional, linkages. Therefore, selecting the route through MPRs automatically avoids the problems associated
ノードは「左右対称」の、そして、すなわち、双方向のリンケージでワンバウンドの隣人からMPRsを選択します。 したがって、MPRsを通して自動的にルートを選択すると、関連づけられた問題は避けられます。
Clausen & Jacquet Experimental [Page 4] RFC 3626 Optimized Link State Routing October 2003
[4ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
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).
データ・パケットと共にuni方向のリンクの上に移してください(各ホップのデータ・パケット、リンクレイヤのためのリンクレイヤを手に入れないという問題などの承認がユニキャスト交通のためのこのテクニックを使って)。
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はHIPERLANからETSI[3]によって標準化される(MAC層のプロトコル)を進めて、リレーする概念を引き継ぎます。 プロトコルはイパネマプロジェクト(ユークリッドプログラムの一部)とPRIMAプロジェクト(RNRTプログラムの一部)で開発されます。
1.1. OLSR Terminology
1.1. OLSR用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは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.
本書では指定されるとしてのOptimized Link州ルート設定プロトコルを実行するマネルータ。
OLSR interface
OLSRインタフェース
A network device participating in a MANET running OLSR. A node
may have several OLSR interfaces, each interface assigned an
unique IP address.
マネ走行OLSRに参加するネットワーク装置。 ノードには、いくつかのOLSRインタフェース、固有のIPアドレスが割り当てられた各インタフェースがあるかもしれません。
non OLSR interface
非OLSRインタフェース
A network device, not participating in a MANET running OLSR. A
node may have several non OLSR interfaces (wireless and/or
wired). Routing information from these interfaces MAY be
injected into the OLSR routing domain.
マネ走行OLSRに参加するのではなく、ネットワーク装置。 ノードには、いくつかの非OLSRインタフェース(無線の、そして/または、ワイヤードな)があるかもしれません。 これらのインタフェースからのルート設定情報はOLSR経路ドメインに注がれるかもしれません。
single OLSR interface node
ただ一つのOLSRインタフェースノード
A node which has a single OLSR interface, participating in an
OLSR routing domain.
OLSR経路ドメインに参加して、単一のOLSRインタフェースがあるノード。
multiple OLSR interface node
複数のOLSRインタフェースノード
A node which has multiple OLSR interfaces, participating in an
OLSR routing domain.
OLSR経路ドメインに参加して、複数のOLSRを持っているノードは連結します。
Clausen & Jacquet Experimental [Page 5] RFC 3626 Optimized Link State Routing October 2003
[5ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
main address
主なアドレス
The main address of a node, which will be used in OLSR control
traffic as the "originator address" of all messages emitted by
this node. It is the address of one of the OLSR interfaces of
the node.
ノードの主なアドレス。(それは、このノードによって放たれたすべてのメッセージの「創始者アドレス」としてOLSRコントロール交通で使用されるでしょう)。 それはノードのOLSRインタフェースの1つのアドレスです。
A single OLSR interface node MUST use the address of its only
OLSR interface as the main address.
ただ一つのOLSRインタフェースノードは主なアドレスとして唯一のOLSRインタフェースのアドレスを使用しなければなりません。
A multiple OLSR interface node MUST choose one of its OLSR
interface addresses as its "main address" (equivalent of
"router ID" or "node identifier"). It is of no importance
which address is chosen, however a node SHOULD always use the
same address as its main address.
OLSRインタフェースノードがOLSRインタフェースの1つを選ばなければならない倍数は「主なアドレス」として(「ルータID」か「ノード識別子」の同等物)を記述します。 それは全く重要でなく、アドレスが選ばれているしかしながら、ノードSHOULDはいつも主なアドレスと同じアドレスを使用します。
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を聞くことができるなら(すなわち、リンクはノードXの上のOLSRインタフェースとYのOLSRインタフェースの間に存在しています)、ノード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.
ノード自体でないノードの隣人でなく、ノードさらに、決してウィルと異なった意欲を伴う隣人の隣人でない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の多点リレーセレクタと呼ばれるでしょう。
Clausen & Jacquet Experimental [Page 6] RFC 3626 Optimized Link State Routing October 2003
[6ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
link
リンク
A link is a pair of OLSR interfaces (from two different nodes)
susceptible to hear one another (i.e., one may be able to
receive traffic from the other). A node is said to have a link
to another node when one of its interface has a link to one of
the interfaces of the other node.
リンクはお互いの声を聞くのにおいて影響されやすいOLSRインタフェース(2つの異なったノードからの)の1組(すなわち、もう片方からの交通を受けることができるかもしれない)です。 ノードはインタフェースの1つがもう片方のノードのインタフェースの1つにリンクを持っているとき、別のノードにリンクを持っていると言われています。
symmetric link
左右対称のリンク
A verified bi-directional link between two OLSR interfaces.
2つのOLSRインタフェースの間の確かめられた双方向のリンク。
asymmetric link
非対称のリンク
A link between two OLSR interfaces, verified in only one
direction.
一方向だけに確かめられた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ホップの地域も少なくとも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自体を除いたXの左右対称の1ホップの地域に左右対称のリンクを持っているノードのセットです。
symmetric strict 2-hop neighborhood
左右対称の厳しい2ホップの地域
The symmetric strict 2-hop neighborhood of X is the set of
nodes, excluding X itself and its neighbors, which have a
symmetric link to some symmetric 1-hop neighbor, with
willingness different of WILL_NEVER, of X.
Xの左右対称の厳しい2ホップの地域はノードのセットです、XのX自体とその隣人を除いて。その隣人は、ウィルにおいて異なった意欲と共に左右対称の1ホップの隣人に左右対称のリンクを決して持っていません。
1.2. Applicability
1.2. 適用性
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は可動の臨時のネットワーク[1]、[2](MANETs)のための先を見越すルーティング・プロトコルです。 それは大きくて濃いモバイルネットワークによく合っています、MPRsを使用することで達成された最適化がこのような関係においてはうまくいくとき。 ネットワークが、より大きくて、濃ければ濃いほど、古典的なリンク州のアルゴリズムと比べて、より多くの最適化を達成できます。 OLSRはホップごとのルーティングを使用します、すなわち、各ノードがパケットを発送するのにローカルの情報を使用します。
OLSR is well suited for networks, where the traffic is random and sporadic between a larger set of nodes rather than being almost exclusively between a small specific set of nodes. As a proactive
OLSRはネットワークによく合っています。そこでは、交通は、専ら小さい特定のセットのノードの間には、あるよりむしろさらに大きいセットのノードの間で無作為であって、過疎です。 aとして、予測してください。
Clausen & Jacquet Experimental [Page 7] RFC 3626 Optimized Link State Routing October 2003
[7ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
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も交信が時間がたつにつれて変化を対にするシナリオに適しています: ルートがいつもすべての知られている目的地に維持されるので、どんな追加コントロール交通もこの状況で発生しません。
1.3. Protocol Overview
1.3. プロトコル概観
OLSR is a proactive routing protocol for mobile ad hoc networks. The protocol inherits the stability of a link state algorithm and has the advantage of having routes immediately available when needed due to its proactive nature. OLSR is an optimization over the classical link state protocol, tailored for mobile ad hoc networks.
OLSRは可動の臨時のネットワークのための先を見越すルーティング・プロトコルです。 プロトコルは、リンク州のアルゴリズムの安定性を引き継いで、先を見越す本質のため必要であると、ルートを持つすぐに利用可能な利点を持っています。 OLSRは可動の臨時のネットワークのために合わせた古典的なリンク州のプロトコルの上の最適化です。
OLSR minimizes the overhead from flooding of control traffic by using only selected nodes, called MPRs, to retransmit control messages. This technique significantly reduces the number of retransmissions required to flood a message to all nodes in the network. Secondly, OLSR requires only partial link state to be flooded in order to provide shortest path routes. The minimal set of link state information required is, that all nodes, selected as MPRs, MUST declare the links to their MPR selectors. Additional topological information, if present, MAY be utilized e.g., for redundancy purposes.
OLSRは、コントロール交通の氾濫からコントロールメッセージを再送するのにMPRsと呼ばれる選択されたノードだけを使用することによって、オーバーヘッドを最小にします。 このテクニックはネットワークにおけるすべてのノードへメッセージをあふれさせなければならなかった「再-トランスミッション」の数をかなり減少させます。 第二に、OLSRは、最短パスルートを提供するために部分的なリンク状態だけが水につかっているのを必要とします。 情報が必要としたリンク状態の極小集合はそうであり、それはMPRsとして選定されるノードがそれらのMPRセレクタへのリンクであると宣言しなければならないすべてです。 存在しているなら、追加位相的な情報は例えば、冗長目的に利用されるかもしれません。
OLSR MAY optimize the reactivity to topological changes by reducing the maximum time interval for periodic control message transmission. Furthermore, as OLSR continuously maintains routes to all destinations in the network, the protocol is beneficial for traffic patterns where a large subset of nodes are communicating with another large subset of nodes, and where the [source, destination] pairs are changing over time. The protocol is particularly suited for large and dense networks, as the optimization done using MPRs works well in this context. The larger and more dense a network, the more optimization can be achieved as compared to the classic link state algorithm.
OLSR MAYは、周期的なコントロールメッセージ送信のために最大の時間間隔を短縮することによって、位相的な変化に反動を最適化します。 その上、OLSRが絶え間なくネットワークにおけるすべての目的地にルートを維持するとき、ノードの大きい部分集合がノードの別の大きい部分集合で交信していて、[ソース、目的地]組が時間がたつにつれて変化するトラフィック・パターンに、プロトコルは有益です。 プロトコルは特に大きくて濃いネットワークに合っています、MPRsを使用し終わっている最適化がこのような関係においてはうまくいくとき。 ネットワークが、より大きくて、濃ければ濃いほど、古典的なリンク州のアルゴリズムと比べて、より多くの最適化を達成できます。
OLSR is designed to work in a completely distributed manner and does not depend on any central entity. The protocol does NOT REQUIRE reliable transmission of control messages: each node sends control messages periodically, and can therefore sustain a reasonable loss of some such messages. Such losses occur frequently in radio networks due to collisions or other transmission problems.
OLSRは完全に分配された方法で働くように設計されていて、どんな中央の実体にもよりません。 プロトコルはコントロールメッセージの信頼できる伝達をどんなREQUIREにもしません: 各ノードは、定期的にコントロールメッセージを送って、したがって、そのようないくつかのメッセージの手頃な損失を被ることができます。 衝突か他のトランスミッション問題のため、そのような損失はラジオ放送網で頻出します。
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はメッセージの配列された配送を必要としません。 それぞれのコントロールメッセージは各メッセージのために増加される一連番号を含んでいます。 したがって、必要なら、トランスミッションにはある間、コントロールメッセージの受取人は、メッセージが再注文されたとしてもどちらの情報が、より最近であるかを容易に特定できます。
Clausen & Jacquet Experimental [Page 8] RFC 3626 Optimized Link State Routing October 2003
[8ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
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スタックも使用できます: プロトコルは経路指定テーブル管理と対話するだけです。
1.4. Multipoint Relays
1.4. 多点リレー
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ホップの近所で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としてそれを選定した隣人のセットの情報を保守します。 このセットはノードについて「多点Relay Selectorはセットした」(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がまだそれを受けていないなら。 このセットは、時間がたつにつれて(すなわち、ノードはいつもう1MPR-セットを選択しますか)、変化できて、それらのHELLOメッセージのセレクタノードによって示されます。
2. Protocol Functioning
2. プロトコル機能
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はプロトコルが作動するのにいつも必要である機能性と1セットの補助の機能の「コア」にmodularizedされます。
Clausen & Jacquet Experimental [Page 9] RFC 3626 Optimized Link State Routing October 2003
[9ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
The core specifies, in its own right, a protocol able to provide routing in a stand-alone MANET.
コアはそれ自身の権利でスタンドアロンのマネにルーティングを提供できるプロトコルを指定します。
Each auxiliary function provides additional functionality, which may be applicable in specific scenarios, e.g., in case a node is providing connectivity between the MANET and another routing domain.
それぞれの補助の機能は追加機能性を提供します、例えば、ノードがマネと別の経路ドメインの間に接続性を備えているといけないので。(追加機能性は特定のシナリオで適切であるかもしれません)。
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の機能を中心となる機能性に分割する目的と1セットの補助の機能は、簡単、そして、理解しやすいプロトコルを提供して、特定の追加機能性が必要であるところに複雑さを加えるだけの方法を提供することです。
2.1. Core Functioning
2.1. コア機能
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インタフェースを備えて、ルーティング・プロトコルとして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.
リンクSensingは接続性がチェックされるインタフェースの上で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.
Link Sensingから生じるのは、地方のリンクセットです、「局所界面」と「リモートインタフェース」とのリンクについて説明して--すなわち、隣人ノードの上のインタフェース。
Clausen & Jacquet Experimental [Page 10] RFC 3626 Optimized Link State Routing October 2003
[10ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
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.
MPR選択の目的はノードが遠くにすべてのノード2ホップでこれらの選択された隣人によって再送された同報メッセージを受け取るように隣人の部分集合を選択することです。 ノードのMPRセットが計算されるので、それは各インタフェースにこの状態を満たします。 HELLOメッセージの周期的な交換を通してこの計算を実行するのに必要である情報を取得します、セクション6で説明されるように。 MPR選択手順はセクション8.3で詳細です。
MPR signaling is provided in correspondence with the provisions
in the section 6.
セクション6の条項との通信にMPRシグナリングを提供します。
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.
トポロジーControlメッセージはルート計算を許容できるくらいのリンク州の情報をネットワークにおける各ノードに提供する目的で拡散します。 トポロジーControlメッセージはセクション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で詳細です。
Clausen & Jacquet Experimental [Page 11] RFC 3626 Optimized Link State Routing October 2003
[11ページ]RFC3626の最適化されたリンク州のルート設定2003年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
特徴| セクション------------------------------+-------------- パケット・フォーマットと推進| 3 情報倉庫| 4の主なaddrと倍数 | 5、こんにちは、メッセージ| 6 リンクの感じ| 7 隣人検出| 8 トポロジー発見| 9経路指定テーブル計算| 10ノード構成| 11
2.2. Auxiliary Functioning
2.2. 補助の機能
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
特徴| セクション------------------------------+-------------- 非OLSRインタフェース| 12 リンクレイヤ通知| 13 高度なリンクの感じ| 14 余分なトポロジー| 15 余分なMPR氾濫| 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.
上のテーブルの解釈は以下の通りです: リストアップされた特徴が必要であり、それはSHOULDです。指定されるとして、該当箇所に供給してください。
Clausen & Jacquet Experimental [Page 12] RFC 3626 Optimized Link State Routing October 2003
[12ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
3. Packet Format and Forwarding
3. パケット・フォーマットと推進
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アドレスを現在のドキュメントに与えます。 セクション17でIPv6に関する問題を与えます。
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コントロールメッセージを送るのを防ぐためにセットしたと主張する)に排除されて、全体のネットワークでMPRsの使用法で最小にされるでしょう。
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.
その上、ノードは距離(ホップの数に関する)の情報をメッセージの創始者に得るメッセージのヘッダーを調べることができます。 この特徴は例えばメッセージがノードに保存した容認されたコントロールからの時間情報を創始者への距離に依存する状況で役に立つかもしれません。
3.1. Protocol and Port Number
3.1. プロトコルとポートナンバー
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によって割り当てられました。
3.2. Main Address
3.2. 主なアドレス
For a node with one interface, the main address of a node, as defined in "OLSR Terminology", MUST be set to the address of that interface.
1つのインタフェースがあるノードにおいて、「OLSR用語」で定義されるノードの主なアドレスをそのインタフェースのアドレスに設定しなければなりません。
Clausen & Jacquet Experimental [Page 13] RFC 3626 Optimized Link State Routing October 2003
[13ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
3.3. Packet Format
3.3. パケット・フォーマット
The basic layout of any packet in OLSR is as follows (omitting IP and UDP headers):
OLSRのどんなパケットの基本的なレイアウトも以下の通りです(IPとUDPヘッダーを省略して):
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Length | Packet Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Vtime | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time To Live | Hop Count | Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: MESSAGE :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Vtime | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time To Live | Hop Count | Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: MESSAGE :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
(etc.)
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | パケット長| パケット一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メッセージタイプ| Vtime| メッセージサイズ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 創始者アドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 生きる時間| ホップカウント| メッセージ通番| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : メッセージ: | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メッセージタイプ| Vtime| メッセージサイズ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 創始者アドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 生きる時間| ホップカウント| メッセージ通番| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : メッセージ: | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : (など)
3.3.1. Packet Header
3.3.1. パケットのヘッダー
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.
新しいOLSRパケットが伝えられるたびにPacket Sequence Number(PSN)を1つ増加しなければなりません。 「巻きつけて着るドレス」はセクション19で説明されるように扱われます。 別々のPacket Sequence Numberが各インタフェースに維持されるので、インタフェースの上に伝えられたパケットは連続して数え上げられます。
Clausen & Jacquet Experimental [Page 14] RFC 3626 Optimized Link State Routing October 2003
[14ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
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.
パケットがメッセージを全く含んでいないなら(すなわち、Packet Lengthはパケットのヘッダーの、よりサイズ以下です)、静かにパケットを捨てなければなりません。
For IPv4 addresses, this implies that packets, where the Packet Length < 16 MUST silently be discarded.
IPv4アドレスのために、これは静かにPacket Length<16を捨てなければならないところでそのパケットを含意します。
3.3.2. Message Header
3.3.2. メッセージヘッダー
Message Type
メッセージタイプ
This field indicates which type of message is to be found in
the "MESSAGE" part. Message types in the range of 0-127 are
reserved for messages in this document and in possible
extensions.
この分野は、どのタイプに関するメッセージが「メッセージ」部分で見つけられるかことであるかを示します。 0-127の範囲のメッセージタイプはこのドキュメントと可能な拡大におけるメッセージのために予約されます。
Vtime
Vtime
This field indicates for how long time after reception a node
MUST consider the information contained in the message as
valid, unless a more recent update to the information is
received. The validity time is represented by its mantissa
(four highest bits of Vtime field) and by its exponent (four
lowest bits of Vtime field). In other words:
この分野は、どれくらい長い間、レセプションの後の時にノードが、メッセージに含まれた情報が有効であるとみなさなければならないのを示すか、情報への、より最近のアップデートが受け取られていない場合。 正当性時間は仮数(Vtimeの最も高いビットがさばく4)とその解説者(Vtimeの最も低いビットがさばく4)によって表されます。 言い換えれば:
validity time = C*(1+a/16)* 2^b [in seconds]
C*(+ /16あたり1)正当性時間=*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分野とbの最も高い4ビットによって表された整数であるところでは、整数はVtimeの最も低いビットがさばく4を表しました。 けた移動子Cの提案された値はセクション18で指定されます。
Message Size
メッセージサイズ
This gives the size of this message, counted in bytes and
measured from the beginning of the "Message Type" field and
until the beginning of the next "Message Type" field (or - if
there are no following messages - until the end of the packet).
または、これがバイトで数えられて、「メッセージタイプ」分野の始まりと次の「メッセージタイプ」分野の始まりまで測定されたこのメッセージのサイズを与える、(パケットの端まで次のメッセージが全くない、)
Originator Address
創始者アドレス
This field contains the main address of the node, which has
originally generated this message. This field SHOULD NOT be
confused with the source address from the IP header, which is
changed each time to the address of the intermediate interface
この分野はノードの主なアドレスを含んでいます。(ノードは元々、このメッセージを生成しました)。 この分野SHOULD NOTがIPヘッダーからのソースアドレスに混乱して、どれによる変えて、それぞれが調節されるという中間介在物のアドレスへのことであるかは連結します。
Clausen & Jacquet Experimental [Page 15] RFC 3626 Optimized Link State Routing October 2003
[15ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
which is re-transmitting this message. The Originator Address
field MUST *NEVER* be changed in retransmissions.
このメッセージを再送しています。 Originator Address分野は*変えられたコネが「再-トランスミッション」であったなら決してそうしてはいけません。
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.
この分野はホップの最大数を含んでいます。メッセージは送られるでしょう。 メッセージが再送される前に、Time To Liveは1つ減少しなければなりません。 ノードが0か1と等しいTime To Liveと共にメッセージを受け取るとき、どうあってもメッセージを再送してはいけません。 通常、ノードはゼロの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.
この分野はメッセージが達したホップの数を含んでいます。 メッセージが再送される前に、Hop Countを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.
メッセージを生成している間、「創始者」ノードはユニークな識別番号を各メッセージに割り当てるでしょう。 この数はメッセージのSequence Number分野に挿入されます。 一連番号はノードから発する各メッセージあたり1つ(1)増強されます。 「巻きつけて着るドレス」はセクション19で説明されるように扱われます。 メッセージ通番は、与えられたメッセージがどんなノードによる一度ほども再送されていないのを保証するのに使用されます。
3.4. Packet Processing and Message Flooding
3.4. パケット処理とメッセージ氾濫
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
基本的なパケットを受けると、ノードはそれぞれの「メッセージヘッダー」を調べます。 「メッセージタイプ」分野の値に基づいて、ノードはメッセージの運命を決定できます。 ノードは何度か同じメッセージを受け取るかもしれません。 したがって、既に受け取られて、処理されたいくつかのメッセージの再処理を避けるために、各ノードはDuplicate Setを維持します。 このセットでは、ノード記録情報は最も最近頃に避けられるメッセージの写し処理がことであるメッセージを受け取りました。 そのようなメッセージ、D_addrが創始者である「写しTuple」(D_addr、_D seq_num、D_は再送されました、D_iface_リスト、D_時間)という記録が扱うメッセージのノードに関しては、D_seq_numがメッセージのメッセージ通番である、再送されたD_はメッセージがあったかどうかを示す論理演算子です。
Clausen & Jacquet Experimental [Page 16] RFC 3626 Optimized Link State Routing October 2003
[16ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
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_iface_リストはメッセージを受け取って、D_時間がtupleが期限が切れる時を指定するインタフェースのアドレスのリストです、そして、*を取り除かなければなりませんか?
In a node, the set of Duplicate Tuples are denoted the "Duplicate set".
ノードでは、Duplicate Tuplesのセットは指示されます。「写しセット。」
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 パケットがメッセージを全く含んでいないなら(すなわち、Packet Lengthはパケットのヘッダーの、よりサイズ以下です)、静かにパケットを捨てなければなりません。
For IPv4 addresses, this implies that packets, where the
Packet Length < 16 MUST silently be discarded.
IPv4アドレスのために、これは静かにPacket Length<16を捨てなければならないところでそのパケットを含意します。
2 If the time to live of the message is less than or equal to
'0' (zero), or if the message was sent by the receiving node
(i.e., the Originator Address of the message is the main
address of the receiving node): the message MUST silently be
dropped.
2 メッセージを住ませる時間が'0'より(ゼロ)以下である、または受信ノードでメッセージを送ったなら(すなわち、メッセージのOriginator Addressは受信ノードの主なアドレスです): 静かにメッセージを下げなければなりません。
3 Processing condition:
3処理状態:
3.1 if there exists a tuple in the duplicate set, where:
3.1 tupleが写しセット、どこに存在しているかなら:
D_addr == Originator Address, AND
創始者アドレス、D_addr=AND
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 さもなければ、ノードがメッセージのMessage Typeを実装するなら、仕様通りにメッセージタイプのためにメッセージを処理しなければなりません。
Clausen & Jacquet Experimental [Page 17] RFC 3626 Optimized Link State Routing October 2003
[17ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
4 Forwarding condition:
4推進状態:
4.1 if there exists a tuple in the duplicate set, where:
4.1 tupleが写しセット、どこに存在しているかなら:
D_addr == Originator Address, AND
創始者アドレス、D_addr=AND
D_seq_num == Message Sequence Number,
AND
メッセージ通番、_D seq_num=AND
the receiving interface (address) is
in D_iface_list
受信インタフェース(アドレス)がD_iface_リストにあります。
then the message has already been considered for
forwarding and SHOULD NOT be retransmitted again.
次に、メッセージのために推進とSHOULD NOTであると既に考えられました。再び再送されます。
4.2 Otherwise:
4.2 そうでなければ:
4.2.1
If the node implements the Message Type of the
message, the message MUST be considered for
forwarding according to the specifications for
the message type.
4.2.1 ノードがメッセージの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 さもなければ、ノードが、メッセージ、メッセージのMessage TypeがSHOULDであると実装しないなら、以下で説明されたデフォルト推進アルゴリズムに従って、処理されてください。
3.4.1. Default Forwarding Algorithm
3.4.1. デフォルト推進アルゴリズム
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 tupleが存在するなら、写しで、どこを設定してくださいか:
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
再送されたD_は偽、ANDです。
Clausen & Jacquet Experimental [Page 18] RFC 3626 Optimized Link State Routing October 2003
[18ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
the (address of the) interface which received the message
is not included among the addresses in D_iface_list
(アドレス、)、メッセージを受け取ったインタフェースがD_iface_リストのアドレスの中に含まれていません。
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 写しセットにおけるエントリーが同じOriginator Address、および同じMessage Sequence Numberと共に存在しているなら、以下の通りエントリーをアップデートします:
D_time = current time + DUP_HOLD_TIME.
D_時間は現在の時間+DUP_HOLD_タイム誌と等しいです。
The receiving interface (address) is added to
D_iface_list.
受信インタフェース(アドレス)はD_iface_リストに追加されます。
D_retransmitted is set to true if and only if the message
will be retransmitted according to step 4.
再送されたD_が本当に用意ができている、ステップ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_時間は現在の時間+DUP_HOLD_タイム誌と等しいです。
D_iface_list contains the receiving interface address.
D_iface_リストは受信インターフェース・アドレスを含んでいます。
D_retransmitted is set to true if and only if the message
will be retransmitted according to step 4.
再送されたD_が本当に用意ができている、ステップ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つ増強されます。
Clausen & Jacquet Experimental [Page 19] RFC 3626 Optimized Link State Routing October 2003
[19ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
8 The message is broadcast on all interfaces (Notice: The
remaining fields of the message header SHOULD be left
unmodified.)
8 メッセージはすべてのインタフェースで放送されます。(: メッセージヘッダーSHOULDの残っているフィールドが変更されていないままにされるのに注意してください。)
3.4.2. Considerations on Processing and Forwarding
3.4.2. 処理と推進での問題
It should be noted that processing and forwarding messages are two different actions, conditioned by different rules. Processing relates to using the content of the messages, while forwarding is related to retransmitting the same message for other nodes of the network.
処理とメッセージを転送するのが、異なった規則で条件とする2つの異なった動作であることに注意されるべきです。 処理はメッセージの内容を使用するのに関係します、推進がネットワークの他のノードへの同じメッセージを再送すると関連しますが。
Notice that this specification includes a description for both the forwarding and the processing of each known message type. Messages with known message types MUST *NOT* be forwarded "blindly" by this algorithm. Forwarding (and setting the correct message header in the forwarded, known, message) is the responsibility of the algorithm specifying how the message is to be handled and, if necessary, retransmitted. This enables a message type to be specified such that the message can be modified while in transit (e.g., to reflect the route the message has taken). It also enables bypassing of the MPR flooding mechanism if for some reason classical flooding of a message type is required, the algorithm which specifies how such messages should be handled will simply rebroadcast the message, regardless of MPRs.
この仕様が推進とそれぞれの知られているメッセージタイプの処理の両方のための記述を含んでいるのに注意してください。 このアルゴリズムで「盲目的に」知られているメッセージタイプがあるメッセージを転送してはいけません。 推進(進められて、知られているメッセージに正しいメッセージヘッダーをはめ込んで)はアルゴリズムが、メッセージがどのように扱われて、必要なら、再送されるかことであると指定する責任です。 これは、トランジットにはある間、メッセージを変更できる(例えばルートを反映するために、メッセージは取った)ようにメッセージタイプが指定されるのを可能にします。 また、そのようなメッセージがどう扱われるべきであるかを指定するアルゴリズムがメッセージタイプの古典的な氾濫が必要である何らかの理由で単にメッセージを再放送するなら、それはMPR氾濫メカニズムの迂回を可能にします、MPRsにかかわらず。
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に関する中心となる機能性のためのREQUIREDメッセージタイプは以下の通りです。
- HELLO-messages, performing the task of link sensing, neighbor
detection and MPR signaling,
- HELLO-メッセージ、リンクの感じに関するタスクを実行する、隣人検出、および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.
他のメッセージタイプは後のセクションで指定されたものを入れます、パワー保護/スリープモード、マルチキャストルーティング、単方向のリンクの自動構成/アドレス課題サポートなどを可能にするメッセージなどの可能な今後の拡大と同様に
Clausen & Jacquet Experimental [Page 20] RFC 3626 Optimized Link State Routing October 2003
[20ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
3.5. Message Emission and Jitter
3.5. メッセージ放出とジター
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.
基本の実装要件、コントロールの同期がSHOULDを通信させるように、避けられてください。 結果、OLSRがメッセージSHOULDを制御するように、同期を避けるように、放たれてください。
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:
そのような連動を避けるために、コントロールメッセージを放つための以下の簡単な戦略は提案されます。 SHOULDが間隔へのジターの量を加えるそれのメッセージが発生しているノード。 ジターは生成された各メッセージのための無作為の値でなければなりません。 このようにして、ジターを利用するノードのために:
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メッセージのための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 :
ジターSHOULD、また、メッセージを転送するときには、導入してください。 以下の簡単な戦略は採用されるかもしれません: メッセージがノードで進めることであるときに、短期間の間、ノードにそれを保つべきです:
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.
注意してください、そして、コントロールメッセージのそのa最小量のレートは課されます。 特定の展開に有益であるなら、ノードは、より高いレートでコントロールメッセージを送るかもしれません。
Clausen & Jacquet Experimental [Page 21] RFC 3626 Optimized Link State Routing October 2003
[21ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
4. Information Repositories
4. 情報倉庫
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コントロールメッセージの交換を通して、各ノードはネットワークの情報を蓄積します。 記述によると、この情報はこのセクションに保存されます。
4.1. Multiple Interface Association Information Base
4.1. 複数のインタフェース協会Information基地
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.
ネットワークにおける各目的地に関しては、「インタフェース協会Tuples」は記録されています(I_は、I_が__addr、Iメイン_addrをifaceするように調節します)。 _I_iface_はaddrにノードのインターフェース・アドレスであり、私は主な_です。addrはこのノードの主なアドレスです。 *I_時間はこのtupleが期限が切れる時を指定します、そして、*を取り除かなければなりませんか?
In a node, the set of Interface Association Tuples is denoted the "Interface Association Set".
ノードでは、Interface Association Tuplesのセットは指示されます。「インタフェース協会セット。」
4.2. Link Sensing: Local Link Information Base
4.2. 感じをリンクしてください: 地方のリンク情報基地
The local link information base stores information about links to neighbors.
地方のリンク情報ベースは隣人へのリンクの情報を保存します。
4.2.1. Link Set
4.2.1. リンクセット
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.
ノードは「リンクTuples」(_L地方の_iface_addr、_L_隣人iface_addr、L_SYM_時間、L_ASYM_時間、L_時間)の1セットを記録します。 *_の地方の_L iface_addrはローカルのノード(すなわち、リンクのある終点)のインターフェース・アドレスです、そして、L_隣人_iface_はaddrに隣人ノード(すなわち、リンクのもう片方の終点)のインターフェース・アドレスです、そして、L_SYM_時間はリンクが左右対称であると考えられる時間です、そして、L_ASYM_時間は隣人インタフェースが聞かれると考えられる時間です、そして、L_時間はこの記録が期限が切れる時を指定します、そして、*を取り除かなければなりませんか? L_SYM_時間とL_ASYM_時間が満期であるとき、リンクは無くなると考えられます。
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_時間は、Link Typeが隣人インタフェースについて賛成を表明したと決めるために費やされます。 L_SYM_時間が満期でないなら、左右対称であるとリンクを申告しなければなりません。 L_SYM_時間が満期であるなら、非対称であるとリンクを申告しなければなりません。 L_SYM_時間とL_ASYM_時間の両方が満期であるなら、無くなるとリンクを申告しなければなりません。
In a node, the set of Link Tuples are denoted the "Link Set".
ノードでは、Link Tuplesのセットは指示されます。「リンクセット。」
Clausen & Jacquet Experimental [Page 22] RFC 3626 Optimized Link State Routing October 2003
[22ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
4.3. Neighbor Detection: Neighborhood Information Base
4.3. 隣人検出: 近所Information基地
The neighborhood information base stores information about neighbors, 2-hop neighbors, MPRs and MPR selectors.
近所情報ベースは隣人、2ホップの隣人、MPRs、およびMPRセレクタの情報を保存します。
4.3.1. Neighbor Set
4.3.1. 隣人セット
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.
隣人について説明して、ノードは「隣人tuples」(_N_隣人_メインaddr、N_状態、N_意欲)の1セットを記録します。 N_隣人_メイン_がaddrに隣人の主なアドレスである、N_状態はノードがNOT_SYMかそれともSYMであるかを指定します。 0〜7の整数におけるN_意欲、他のノードを代表してトラフィックを運ぶノードの意欲を指定します。
4.3.2. 2-hop Neighbor Set
4.3.2. 2ホップの隣人セット
A node records a set of "2-hop tuples" (N_neighbor_main_addr, N_2hop_addr, N_time), describing symmetric (and, since MPR links by definition are also symmetric, thereby also MPR) links between its neighbors and the symmetric 2-hop neighborhood. N_neighbor_main_addr is the main address of a neighbor, N_2hop_addr is the main address of a 2-hop neighbor with a symmetric link to N_neighbor_main_addr, and N_time specifies the time at which the tuple expires and *MUST* be removed.
ノードは「2ホップのtuples」(_N_隣人メイン_addr、N_2hop_addr、N_時間)の1セットを記録します、隣人と左右対称の2ホップの地域との左右対称(その結果、また、定義上MPRリンクも左右対称でありMPRも)のリンクについて説明して。 *N_隣人_メイン_はaddrに隣人の主なアドレスです、そして、N_2hop_はaddrに_N_隣人メイン_addrへの左右対称のリンクをもっている2ホップの隣人の主なアドレスです、そして、N_時間はtupleが期限が切れる時を指定します、そして、*を取り除かなければなりませんか?
In a node, the set of 2-hop tuples are denoted the "2-hop Neighbor Set".
ノードでは、2ホップのtuplesのセットは指示されます。「隣人が設定する2ホップ。」
4.3.3. MPR Set
4.3.3. MPRはセットしました。
A node maintains a set of neighbors which are selected as MPR. Their main addresses are listed in the MPR Set.
ノードは1セットの隣人を維持します(MPRとして選定されます)。 それらの主なアドレスはMPR Setに記載されています。
4.3.4. MPR Selector Set
4.3.4. 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-セレクタtuples(_MSメイン_addr、MS_時間)の1セットを記録します、MPRとしてこのノードを選定した隣人について説明して。 MS_メイン_addrはMPRとしてこのノードを選定したノードの主なアドレスです。 *MS_時間はtupleが期限が切れる時を指定します、そして、*を取り除かなければなりませんか?
In a node, the set of MPR-selector tuples are denoted the "MPR Selector Set".
ノードでは、MPR-セレクタtuplesのセットは指示されます。「MPRセレクタセット。」
Clausen & Jacquet Experimental [Page 23] RFC 3626 Optimized Link State Routing October 2003
[23ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
4.4. Topology Information Base
4.4. トポロジーInformation基地
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「トポロジーTuple」(_T dest_addr、T_は_addr、T_seq、T_時間続く)が記録されています。 T_dest_addrはノードの主なアドレスです。(それは、ノードからの_主なアドレスT最終_addrによるワンバウンドで達するかもしれません)。 T_最終_addrは通常、_T dest_addrのMPRです。 *T_seqは一連番号です、そして、T_時間はこのtupleが期限が切れる時を指定します、そして、*を取り除かなければなりませんか?
In a node, the set of Topology Tuples are denoted the "Topology Set".
ノードでは、Topology Tuplesのセットは指示されます。「トポロジーセット。」
5. Main Addresses and Multiple Interfaces
5. 主なアドレスと複数のインタフェース
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インターフェース・アドレスと主なアドレスとの関係はMultiple Interface Declaration(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氾濫メカニズムを通してネットワークにおけるすべてのノードへMultiple Interface Declarationメッセージをあふれさせることで達成されます。
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から複数のインタフェースがマネに参加しているノードによって放たれたメッセージを取得して、経路指定テーブル計算に使用されます。
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.
明確に、複数のインタフェース宣言が、各ノードの複数のインタフェース協会ベースに居住することでノード(そして主なアドレスに)に複数のインタフェースを関連づけます。
Clausen & Jacquet Experimental [Page 24] RFC 3626 Optimized Link State Routing October 2003
[24ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
5.1. MID Message Format
5.1. 中間のメッセージ・フォーマット
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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インターフェース・アドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OLSRインターフェース・アドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This is sent as the data-portion of the general packet format described in section 3.4, with the "Message Type" set to MID_MESSAGE. The time to live SHOULD be set to 255 (maximum value) to diffuse the message into the entire network and Vtime set accordingly to the value of MID_HOLD_TIME, as specified in section 18.3.
一般的なパケット・フォーマットのデータ部がセクション3.4で説明したようにこれを送ります、MID_MESSAGEに設定された「メッセージタイプ」で。 セクション18.3で指定されるようなSHOULDを住ませるために、255(最大値)に全体のネットワークにメッセージを拡散させるように設定されてください。そうすれば、Vtimeがそれに従って、_HOLD_タイム誌をMIDの値に設定する時。
OLSR Interface Address
OLSRインターフェース・アドレス
This field contains the address of an OLSR interface of the
node, excluding the nodes main address (which already
indicated in the originator address).
この分野はノード、ノードメインが扱う除外(創始者で既にアドレスを示した)のOLSRインタフェースのアドレスを含んでいます。
All interface addresses other than the main address of the originator node are put in the MID message. If the maximum allowed message size (as imposed by the network) is reached while there are still interface addresses which have not been inserted into the MIDmessage, more MID messages are generated until the entire interface addresses set has been sent.
創始者ノードの主なアドレス以外のすべてのインターフェース・アドレスがMIDメッセージに入れられます。 MIDmessageに挿入されていないインターフェース・アドレスがまだある間、メッセージサイズ(ネットワークによって課されるように)が許容された最大に達しているなら、より多くのMIDメッセージが全体のインターフェース・アドレスセットを送るまで発生しています。
5.2. MID Message Generation
5.2. 中間のメッセージ世代
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メッセージによってネットワークで拡散させられる情報は、各ノードが経路指定テーブルについて計算するのを助けるでしょう。 ただ一つのインターフェース・アドレスしか持っていないノードは、マネ(すなわち、実行しているOLSR)に参加して、どんなMIDメッセージも生成してはいけません。
Clausen & Jacquet Experimental [Page 25] RFC 3626 Optimized Link State Routing October 2003
[25ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
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.
いくつかのインタフェースがあるノード、1つだけがどこでマネに参加しているか、そして、実行しているOLSR(例えばノードはマネに関してまた、有線ネットワークに接続される)はどんなMIDメッセージも生成してはいけません。
A node with several interfaces, where more than one is participating in the MANET and running OLSR MUST generate MID messages as specified.
いくつかのインタフェースがあるノード、1つ以上がどこでマネに参加しているか、そして、実行しているOLSR MUSTは指定されるとしてMIDにメッセージを生成します。
5.3. MID Message Forwarding
5.3. 中間のメッセージ推進
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メッセージは、全体のネットワークでメッセージを拡散させるようにMPRsによって放送されて、再送されます。 MIDメッセージの推進に、「デフォルト推進アルゴリズム」(セクション3.4で、説明される)を使用しなければなりません。
5.4. MID Message Processing
5.4. 中間のメッセージ処理
The tuples in the multiple interface association set are recorded with the information that is exchanged through MID messages.
複数のインタフェース協会セットにおけるtuplesは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:
MIDメッセージを受け取ると、メッセージヘッダーのVtime分野から「正当性時間」を計算しなければなりません(セクション3.3.2で説明されるように)。 そしてMultiple Interface Association情報基地のSHOULD、以下の通りアップデートしてください:
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 このメッセージの送付者インタフェース(ネブラスカ: 創始者でない)がこのノードの左右対称の1ホップの近所にないなら、メッセージを捨てなければなりません。
2 For each interface address listed in the MID message:
各インターフェース・アドレスあたり2はMIDメッセージに記載しました:
2.1 If there exist some tuple in the interface association
set where:
2.1 何かが存在しているなら、インタフェース協会におけるtupleはどこを設定したか:
I_iface_addr == interface address, AND
インターフェース・アドレス、_I iface_addr=AND
I_main_addr == originator address,
I主な_addr=創始者_アドレス
then the holding time of that tuple is set to:
そして、そのtupleの把持時間による以下のことように設定されます。
I_time = current time + validity time.
I_時間は現在の時間+正当性時間と等しいです。
2.2 Otherwise, a new tuple is recorded in the interface
association set where:
2.2 さもなければ、記録された新しいtupleはインタフェース協会でどこを設定したか:
I_iface_addr = interface address,
I_は_addr=インターフェース・アドレスをifaceします。
I_main_addr = originator address,
I主な_addr=創始者_アドレス
Clausen & Jacquet Experimental [Page 26] RFC 3626 Optimized Link State Routing October 2003
[26ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
I_time = current time + validity time.
I_時間は現在の時間+正当性時間と等しいです。
5.5. Resolving a Main Address from an Interface Address
5.5. インターフェース・アドレスからの主なアドレスを決議します。
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の残存部分はそれらの「主なアドレス」によって唯一特定されたノードを作動させます(事実上、ノードの主なアドレスは「ノードイド」便宜のために(インタフェースの1つのアドレスに対応する)です)。 ただ一つのインタフェースノードだけのネットワークでは、ノードの主なアドレスは定義上ノードのインターフェース・アドレスと等しくなるでしょう。 複数のインタフェースノードが一般的な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 インタフェース協会におけるいくらかのtupleが存在するなら、どこを設定してくださいか:
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主な_がtupleのaddrであると扱います。
2 Otherwise, the result of the main address search is the
interface address itself.
2 さもなければ、主なアドレス検索の結果はインターフェース・アドレス自体です。
6. HELLO Message Format and Generation
6. こんにちは、メッセージ・フォーマットと世代
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メッセージメカニズムについて説明します、続いて、それぞれリンクの感じとトポロジー検出の記述について説明します。
6.1. HELLO Message Format
6.1. こんにちは、メッセージ・フォーマット
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メッセージの提案された形式は以下の通りです:
Clausen & Jacquet Experimental [Page 27] RFC 3626 Optimized Link State Routing October 2003
[27ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
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
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.)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| Htime| 意欲| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | リンクコード| 予約されます。| リンクメッセージサイズ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 隣人インターフェース・アドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 隣人インターフェース・アドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : . . . : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | リンクコード| 予約されます。| リンクメッセージサイズ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 隣人インターフェース・アドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 隣人インターフェース・アドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : : (など)
This is sent as the data-portion of the general packet format described in section 3.4, with the "Message Type" set to HELLO_MESSAGE, the TTL field set to 1 (one) and Vtime set accordingly to the value of NEIGHB_HOLD_TIME, specified in section 18.3.
一般的なパケット・フォーマットのデータ部がセクション3.4で説明したようにこれを送ります、そして、HELLO_MESSAGEに設定された「メッセージタイプ」でTTL分野は1(1)にセットしました、そして、Vtimeはそれに従って、_セクション18.3で指定されたHOLD_タイム誌をNEIGHBの値に設定します。
Reserved
予約されます。
This field must be set to "0000000000000" to be in compliance
with this specification.
「この仕様に従ってある0インチ」にこの分野を設定しなければなりません。
HTime
HTime
This field specifies the HELLO emission interval used by the
node on this particular interface, i.e., the time before the
transmission of the next HELLO (this information may be used in
advanced link sensing, see section 14). The HELLO emission
interval is represented by its mantissa (four highest bits of
Htime field) and by its exponent (four lowest bits of Htime
field). In other words:
この分野はこの特定のインタフェース(すなわち、次のHELLO(この情報は高度なリンクの感じに使用されるかもしれません、とセクション14は見る)のトランスミッションの前の時間)のノードによって費やされたHELLO放出間隔を指定します。 HELLO放出間隔は仮数(Htimeの最も高いビットがさばく4)とその解説者(Htimeの最も低いビットがさばく4)によって表されます。 言い換えれば:
HELLO emission interval=C*(1+a/16)*2^b [in seconds]
HELLO放出間隔=C*(+ /16あたり1)*2^b[秒の]
Clausen & Jacquet Experimental [Page 28] RFC 3626 Optimized Link State Routing October 2003
[28ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
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分野とbの最も高い4ビットによって表された整数であるところでは、整数はHtimeの最も低いビットがさばく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.
意欲ウィル_に伴うノードはMPRとしてどんなノードによっても決して選定されてはいけません(意欲定数に関してセクション18.8を見ます)。 意欲ウィル_ALWAYS MUSTがMPRとしていつも選定されているノード。 デフォルトで、SHOULDが意欲の広告を出すノードは_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.
隣人ノードのインタフェースのアドレス。
6.1.1. Link Code as Link Type and Neighbor Type
6.1.1. リンク型と隣人がタイプするようにコードをリンクしてください。
This document only specifies processing of Link Codes < 16.
このドキュメントはLink Codes<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:
Link Code値が15以下であるなら、それぞれ2ビットの2つの異なった分野を保持して、それを解釈しなければなりません:
7 6 5 4 3 2 1 0
+-------+-------+-------+-------+-------+-------+-------+-------+
| 0 | 0 | 0 | 0 | Neighbor Type | Link Type |
+-------+-------+-------+-------+-------+-------+-------+-------+
7 6 5 4 3 2 1 0 +-------+-------+-------+-------+-------+-------+-------+-------+ | 0 | 0 | 0 | 0 | 隣人タイプ| リンク型| +-------+-------+-------+-------+-------+-------+-------+-------+
Clausen & Jacquet Experimental [Page 29] RFC 3626 Optimized Link State Routing October 2003
[29ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
The following four "Link Types" are REQUIRED by OLSR:
以下の4「リンク型」がOLSRによるREQUIREDです:
- UNSPEC_LINK - indicating that no specific information about
the links is given.
- UNSPEC_LINK--リンクに関する特殊情報が全く与えられていないのを示します。
- ASYM_LINK - indicating that the links are asymmetric (i.e.,
the neighbor interface is "heard").
- ASYM_LINK--リンクが非対称であることを(すなわち、隣人インタフェースは「聞かれる」)示します。
- SYM_LINK - indicating that the links are symmetric with the
interface.
- SYM_LINK--リンクがインタフェースで左右対称であることを示します。
- LOST_LINK - indicating that the links have been lost.
- LOST_LINK--リンクがなくされたのを示します。
The following three "Neighbor Types" are REQUIRED by OLSR:
以下の3「隣人タイプ」がOLSRによるREQUIREDです:
- SYM_NEIGH - indicating that the neighbors have at least one
symmetrical link with this node.
- SYM_NEIGH--隣人が少なくとも1つを対称にするのを示して、このノードにリンクしてください。
- MPR_NEIGH - indicating that the neighbors have at least one
symmetrical link AND have been selected as MPR by the sender.
- MPR_NEIGH--隣人が少なくとも1個の対称のリンクを持って、MPRとして送付者によって選定されたのを示します。
- NOT_NEIGH - indicating that the nodes are either no longer or
have not yet become symmetric neighbors.
- _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).
実装がNeighbor TypeとLink Typeも定数(例えば、SYM_LINKにSYM_NEIGHを間違える)も混乱させないのにおいて慎重であるはずであることに注意してください。
A link code advertising:
リンクコード広告:
Link Type == SYM_LINK AND
リンク型=SYM_リンクAND
Neighbor Type == NOT_NEIGH
どんな隣人タイプ=_もいななきません。
is invalid, and any links advertised as such MUST be silently discarded without any processing.
病人、および何か少しも処理なしでそのようなものを静かに捨てなければならないので広告に掲載されたリンクがそうですか?
Likewise a Neighbor Type field advertising a numerical value which is not one of the constants SYM_NEIGH, MPR_NEIGH, NOT_NEIGH, is invalid, and any links advertised as such MUST be silently discarded without any processing.
同様に定数SYM_NEIGHの1つでない数値の広告を出すNeighbor Type分野(_NEIGHではなく、MPR_NEIGH)は無効です、そして、少しも処理なしでそういうものとして広告に掲載されたどんなリンクも静かに捨てなければなりません。
6.2. HELLO Message Generation
6.2. こんにちは、メッセージ世代
This involves transmitting the Link Set, the Neighbor Set and the MPR Set. In principle, a HELLO message serves three independent tasks:
これは、Link Set、Neighbor Set、およびMPR Setを伝えることを伴います。 原則として、HELLOメッセージは3つの独立しているタスクを受けます:
- link sensing
- リンクの感じ
Clausen & Jacquet Experimental [Page 30] RFC 3626 Optimized Link State Routing October 2003
[30ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
- 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メッセージはLocal Link Set、Neighbor Set、およびMPR Setに地方のリンク情報ベースから保存された情報に基づいて生成されます。
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_タイム誌パラメタの値に対応しています。 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.
Willingness分野が設定されるので、それは他のノードを代表してトラフィックを進めるノードの意欲に対応しています(セクション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 iface_addrがHELLOが伝えられることになっていて、L_時間>が現在の時間と等しいインタフェースであるLink Setの各tupleに関しては、以下で(すなわち、満期でない)の__L隣人_iface addrの広告を出します。
1 The Link Type set according to the following:
1 以下に従って、Link Typeはセットしました:
1.1 if L_SYM_time >= current time (not expired)
1.1 _L_SYMであるなら、時間>は現在の時間と等しいです。(満期でない)です。
Link Type = SYM_LINK
リンク型=SYM_はリンクします。
1.2 Otherwise, if L_ASYM_time >= current time (not expired)
AND
1.2 _さもなければ、L_ASYMであるなら、時間>は現在の時間(期限が切れない)ANDと等しいです。
L_SYM_time < current time (expired)
L_SYMの_の時間の<の現在の時間(満期)です。
Link Type = ASYM_LINK
リンク型=ASYM_はリンクします。
Clausen & Jacquet Experimental [Page 31] RFC 3626 Optimized Link State Routing October 2003
[31ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
1.3 Otherwise, if L_ASYM_time < current time (expired) AND
1.3 L_ASYM_が<電流を調節するなら、さもなければ、ANDを調節してください(吐き出されます)。
L_SYM_time < current time (expired)
L_SYMの_の時間の<の現在の時間(満期)です。
Link Type = LOST_LINK
リンク型=は_リンクをなくしました。
2 The Neighbor Type is set according to the following:
2 以下に従って、Neighbor Typeは用意ができています:
2.1 If the main address, corresponding to
L_neighbor_iface_addr, is included in the MPR set:
主な_L_隣人iface_addrにおいて、対応するアドレスがMPRに含まれているなら、2.1はセットしました:
Neighbor Type = MPR_NEIGH
隣人タイプ=MPR_はいななきます。
2.2 Otherwise, if the main address, corresponding to
L_neighbor_iface_addr, is included in the neighbor set:
2.2 さもなければ、主な_L_隣人iface_addrにおいて、対応するアドレスが隣人に含まれているなら、セットしてください:
2.2.1
if N_status == SYM
2.2.1 N_状態=SYMです。
Neighbor Type = SYM_NEIGH
隣人タイプ=SYM_はいななきます。
2.2.2
Otherwise, if N_status == NOT_SYM
Neighbor Type = NOT_NEIGH
2.2.2 さもなければ、_SYM隣人N_状態=タイプでないのがどんな_とも等しくないなら、いなないてください。
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_隣人がない_iface_addrが前のアルゴリズム、N_によって関連リンクtupleから広告に掲載されるNeighbor Setの各tupleに関しては、以下で隣人_メイン_addrの広告を出します。
- Link Type = UNSPEC_LINK,
- リンク型=UNSPEC_はリンクします。
- Neighbor Type set as described in step 2 above
- 隣人Typeは上のステップ2で説明されるようにセットしました。
For a node with a single OLSR interface, the main address is simply the address of the OLSR interface, i.e., for a node with a single OLSR interface the main address, corresponding to L_neighbor_iface_addr is simply L_neighbor_iface_addr.
_単一のOLSRインタフェースがあるノードに関しては、主なアドレスは単にOLSRインタフェースのアドレスであり、すなわち、シングルがあるノードに関して、OLSRは主なアドレスを連結して、_L_隣人iface_addrにおいて対応しているのは、単にL_隣人iface_addrです。
A HELLO message can be partial (e.g., due to message size limitations, imposed by the network), the rule being the following, on each interface: each link and each neighbor node MUST be cited at least once within a predetermined refreshing period, REFRESH_INTERVAL. To keep track of fast connectivity changes, a HELLO message must be sent at least every HELLO_INTERVAL period, smaller than or equal to REFRESH_INTERVAL.
HELLOメッセージは部分的である場合があります(例えばネットワークによって課されたメッセージサイズ制限による)、規則が以下であり、各インタフェースで: REFRESH_INTERVAL、予定された壮快な期間以内に少なくとも一度各リンクとそれぞれの隣人ノードを引用しなければなりません。 速い接続性変化の動向をおさえるために、いつも少なくともHELLO_INTERVALの期間にHELLOメッセージを送らなければなりません、よりREFRESH_INTERVAL。
Clausen & Jacquet Experimental [Page 32] RFC 3626 Optimized Link State Routing October 2003
[32ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
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フレームに収まることができるのが、望ましいのに注意してください。
6.3. HELLO Message Forwarding
6.3. こんにちは、メッセージ推進
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メッセージが発生させたそれぞれが隣人(すなわち、HELLOが発生したインタフェース)への1つのインタフェースのノードによって放送されます。 HELLOメッセージを決して転送してはいけません。
6.4. HELLO Message Processing
6.4. こんにちは、メッセージ処理
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で詳細)です。
7. Link Sensing
7. リンクの感じ
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メッセージの周期的な交換です。
7.1. Populating the Link Set
7.1. リンクに居住するのはセットしました。
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.
Link Setは隣人ノードへのリンクの情報で居住されます。 このセットに居住する過程は、指示された「リンクの感じであり」、HELLO交換処理を使用することで実行されます、各ノードの地方のリンク情報ベースをアップデートして。
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.
「リンク」は1組のインタフェースによって説明されます: 地方のインタフェースとリモートインタフェース。
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
リンクの感じの目的、それぞれの隣人ノード、(より明確に、各隣人へのリンク) 「左右対称である」か「非対称」にどちらかの関連状態を持っています。 「左右対称」はそれへのリンクがノードを近所付き合いさせるのが双方向であるために確かめられて、すなわち、両方の指示のデータを送るのが可能であることを示します。 「非対称」は、ノードからのHELLOメッセージがあったのを示します。
Clausen & Jacquet Experimental [Page 33] RFC 3626 Optimized Link State Routing October 2003
[33ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
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).
しかしながら、聞かれて(すなわち、隣人ノードからのコミュニケーションは可能です)、また、このノードがメッセージを受け取ることができる(すなわち、隣人ノードへのコミュニケーションは確認されない)と確認されません。
The information, acquired through and used by the link sensing, is accumulated in the link set.
感じがを通して取得されて、リンクによって使用される情報はリンクセットで蓄積されます。
7.1.1. HELLO Message Processing
7.1.1. こんにちは、メッセージ処理
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メッセージ、ノードSHOULD最新版を受けるときのそのLink Set。 HELLOメッセージを転送しないで、写しで記録してはいけないのがセットしたのに注意してください。
Upon receiving a HELLO message, the "validity time" MUST be computed from the Vtime field of the message header (see section 3.3.2). Then, the Link Set SHOULD be updated as follows:
HELLOメッセージを受け取ると、メッセージヘッダーのVtime分野から「正当性時間」を計算しなければなりません(セクション3.3.2を見てください)。 次に、Link Set SHOULD、以下の通りアップデートしてください:
1 Upon receiving a HELLO message, if there exists no link tuple
with
1 いいえがリンクがtupleする存在しているならHELLOメッセージを受け取ることに関して
L_neighbor_iface_addr == Source Address
L_隣人_iface_addr=ソースアドレス
a new tuple is created with
新しいtupleは作成されます。
L_neighbor_iface_addr = Source Address
L_隣人_iface_addr=ソースアドレス
L_local_iface_addr = Address of the interface
which received the
HELLO message
HELLOメッセージを受け取ったインタフェースのL_ローカルの_iface_addr=アドレス
L_SYM_time = current time - 1 (expired)
現在のL_SYM_時間=時間--1(満期)です。
L_time = current time + validity time
L_時間は現在の時間+正当性時間と等しいです。
2 The tuple (existing or new) with:
2 以下があるtuple(既存の、または、新しい)
L_neighbor_iface_addr == Source Address
L_隣人_iface_addr=ソースアドレス
is then modified as follows:
次に、以下の通り変更されます:
2.1 L_ASYM_time = current time + validity time;
2.1 L_ASYM_時間は現在の時間+正当性時間と等しいです。
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メッセージを受け取ったインタフェースのアドレスを見つけるなら、tupleは以下の通り変更されます:
Clausen & Jacquet Experimental [Page 34] RFC 3626 Optimized Link State Routing October 2003
[34ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
2.2.1
if Link Type is equal to LOST_LINK then
そして、2.2.1 Link Typeであるなら、LOST_LINKには同輩がいますか?
L_SYM_time = current time - 1 (i.e., expired)
現在のL_SYM_時間=時間--1(すなわち、満期)です。
2.2.2
else if Link Type is equal to SYM_LINK or ASYM_LINK
then
2.2.2ほか、Link Typeはその時、SYM_LINKかASYM_LINKと等しいです。
L_SYM_time = current time + validity time,
L_SYM_時間は現在の時間+正当性時間と等しいです。
L_time = L_SYM_time + NEIGHB_HOLD_TIME
L_時間=L_SYM_時間+NEIGHB_保持_時間
2.3 L_time = max(L_time, L_ASYM_time)
2.3 L_時間は最大と等しいです。(L_時間、L_ASYM_時間)
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_時間を決めるための上の規則は以下です: 対称SHOULDをなくしながら、aをリンクします、それでも、少なくとも発生しているHELLOの広告に掲載された「正当性時間」の持続時間の間、広告を出してください。 これで、隣人はリンク折損を検出できます。
8. Neighbor Detection
8. 隣人検出
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メッセージの周期的な交換です。
8.1. Populating the Neighbor Set
8.1. 隣人に居住するのはセットしました。
A node maintains a set of neighbor tuples, based on the link tuples. This information is updated according to changes in the Link Set.
ノードはリンクtuplesに基づいて隣人tuplesの1セットを維持します。 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.
Link Setはリンクの情報を保ちますが、Neighbor Setは隣人の情報を保ちます。 そして、それらの2セットの間には、明確な協会があります、ノードが別のノードの隣接物であるので少なくとも1つがある場合にだけ、2つのノードの間でリンクしてください。
In any case, the formal correspondence between links and neighbors is defined as follows:
どのような場合でも、リンクと隣人との正式な通信は以下の通り定義されます:
The "associated neighbor tuple" of a link tuple, is, if it
exists, the neighbor tuple where:
存在しているなら、リンクtupleの「関連隣人tuple」があって、隣人tupleはどこです:
Clausen & Jacquet Experimental [Page 35] RFC 3626 Optimized Link State Routing October 2003
[35ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
N_neighbor_main_addr == main address of
L_neighbor_iface_addr
_L_隣人iface_addrのN_隣人主な_addr=主な_アドレス
The "associated link tuples" of a neighbor tuple, are all the
link tuples, where:
隣人tupleの「関連リンクtuples」はすべてのリンクtuples、どこです:
N_neighbor_main_addr == main address of
L_neighbor_iface_addr
_L_隣人iface_addrのN_隣人主な_addr=主な_アドレス
The Neighbor Set MUST be populated by maintaining the proper correspondence between link tuples and associated neighbor tuples, as follows:
以下の通りリンクtuplesと関連隣人tuplesとの適切な通信を維持することによって、Neighbor Setに居住しなければなりません:
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:
その都度、リンクは現れます、リンクtupleが作成されて、関連隣人tupleを作成しなければならないすなわち各回、既に存在していないなら、以下の値で:
N_neighbor_main_addr = main address of
L_neighbor_iface_addr
(from the link tuple)
_L_隣人iface_addrの主な_N_隣人メイン_addr=アドレス(リンクtupleからの)
In any case, the N_status MUST then be computed as described
in the next step
どんなケース、状態がそしてときにそうしなければならないN_ではも、次のステップで説明されるように計算されてください。
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:
その都度、リンクは変化します、リンクtupleの情報が変更されているすなわち各回ノードは、関連隣人tupleのN_状態が特性を尊敬するのを確実にしなければなりません:
If the neighbor has any associated link tuple which
indicates a symmetric link (i.e., with L_SYM_time >=
current time), then
隣人が何か関連リンクtupleを持っているなら、どれがその時、左右対称のリンク(すなわち、現在のL_SYM_時間>=時間がある)を示しますか?
N_status is set to SYM
N_状態はSYMに設定されます。
else N_status is set to NOT_SYM
ほかのN_状態は_どんな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.
その都度、リンクは削除されます、リンクtupleが取り外されて、もう少しの関連リンクtuplesも持っていないなら関連隣人tupleを取り外さなければならないすなわち各回。
Clausen & Jacquet Experimental [Page 36] RFC 3626 Optimized Link State Routing October 2003
[36ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
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.
これらの規則はリンクtupleのための1関連隣人tupleがまさにあって、あらゆる隣人tupleには少なくとも1関連リンクtupleがあるのを確実にします。
8.1.1. HELLO Message Processing
8.1.1. こんにちは、メッセージ処理
The "Originator Address" of a HELLO message is the main address of the node, which has emitted the message. Likewise, the "willingness" MUST be computed from the Willingness field of the HELLO message (see section 6.1).
HELLOメッセージの「創始者アドレス」はノードの主なアドレスです。(それは、メッセージを放ちました)。 同様に、HELLOメッセージのWillingness分野から「意欲」を計算しなければなりません(セクション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メッセージ、SHOULDが最初にアップデートするノードを受け取るときの以前説明されるLink Set。 それ、次に、SHOULDは以下のNeighbor Setをアップデートします:
- if the Originator Address is the N_neighbor_main_addr from a
neighbor tuple included in the Neighbor Set:
- _Neighbor Setに隣人tupleからのメイン_addrを含んでいて、Originator AddressがN_隣接物であるなら:
then, the neighbor tuple SHOULD be updated as follows:
tuple SHOULDを近所付き合いさせてください。そして、以下の通りアップデートしてください:
N_willingness = willingness from the HELLO message
N_意欲はHELLOメッセージからの意欲と等しいです。
8.2. Populating the 2-hop Neighbor Set
8.2. 2ホップの隣人に居住するのはセットしました。
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メッセージの周期的な交換を通して維持されます。
8.2.1. HELLO Message Processing
8.2.1. こんにちは、メッセージ処理
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メッセージ、ノードSHOULD最新版を受けるときの2ホップのNeighbor Set。 HELLOメッセージを転送しないで、写しで記録してはいけないのがセットしたのに注意してください。
Upon receiving a HELLO message, the "validity time" MUST be computed from the Vtime field of the message header (see section 3.3.2).
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
Originator Addressが_隣人_がLink Setにリンクtupleを含んでいるので_addrにifaceするLの主なアドレスであるなら
L_SYM_time >= current time (not expired)
L_SYM_時間>は現在の時間と等しいです。(満期でない)です。
(in other words: if the Originator Address is a symmetric neighbor) then the 2-hop Neighbor Set SHOULD be updated as follows:
Originator Addressであるなら、左右対称の隣人) 次に、2ホップがNeighbor Set SHOULDです。(言い換えれば:、以下の通りアップデートしてください:
Clausen & Jacquet Experimental [Page 37] RFC 3626 Optimized Link State Routing October 2003
[37ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
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と等しいNeighbor Typeと共にHELLOメッセージに記載された各アドレス(今後は、: 2ホップがアドレスを近所付き合いさせる)のために:
1.1 if the main address of the 2-hop neighbor address = main
address of the receiving node:
1.1 2ホップの隣人アドレスの主なアドレスが受信ノードの主なアドレスと等しいなら:
silently discard the 2-hop neighbor address.
静かに2ホップの隣人アドレスを捨ててください。
(in other words: a node is not its own 2-hop neighbor).
(言い換えれば、: ノードはそれ自身の2ホップの隣接物ではありません。)
1.2 Otherwise, a 2-hop tuple is created with:
1.2 さもなければ、2ホップのtupleは以下で作成されます。
N_neighbor_main_addr = Originator Address;
N_隣人主な_addr=創始者_アドレス。
N_2hop_addr = main address of the
2-hop neighbor;
N_2hop_addrは2ホップの隣人の主なアドレスと等しいです。
N_time = current time
+ validity time.
N_時間は現在の時間+正当性時間と等しいです。
This tuple may replace an older similar tuple with same
N_neighbor_main_addr and N_2hop_addr values.
このtupleは_同じN_隣人メイン_addrと、より古い同様のtupleと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:
Neighbor Typeと共にHELLOメッセージにリストアップされたそれぞれの2ホップのノードあたり2は_NEIGH、すべての2ホップのtuplesとどんなどこと等しくないか:
N_neighbor_main_addr == Originator Address AND
主なN_隣人_addr=創始者アドレス_AND
N_2hop_addr == main address of the
2-hop neighbor
2ホップの隣人のN_2hop_addr=主なアドレス
are deleted.
削除されます。
8.3. Populating the MPR set
8.3. MPRに居住するのはセットしました。
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.
MPRsは、領域に現れる「再-トランスミッション」の数を減少させている間、ノードからネットワークへコントロールメッセージをあふれさせるのに使用されます。 したがって、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ホップの地域で独自にそれ自身のMPRsのセットを選択します。 HELLOメッセージのSYM_NEIGHの代わりにLink Type MPR_NEIGHと共にMPRsとの左右対称のリンクの広告を出します。
Clausen & Jacquet Experimental [Page 38] RFC 3626 Optimized Link State Routing October 2003
[38ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
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-セットにおける隣人を通してすべての左右対称の厳しい2ホップの隣人に届くことができるような方法でMPRセットについて計算しなければなりません。 (そのaノード、aに気付きます。)(aはまた、別のノードのダイレクト隣人(b)がノードbの厳しい2ホップの隣人でないということです)。 これは、MPRノードの左右対称の1ホップの近所の組合が左右対称の厳しい2ホップの地域を含むことを意味します。 変化が左右対称の近所か左右対称の厳しい2ホップの近所に検出されるとき、MPRセット再計算は起こるべきです。
MPRs are computed per interface, the union of the MPR sets of each interface make up the MPR set for the node.
MPRsはインタフェース(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ノードをを通して連絡できるのは不可欠です。 ノードSHOULDがMPRセットを選択するので、どんな厳しい2ホップの隣人も少なくとも1つの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セットは全体の左右対称の隣人セットと同時に起こることができます。 これはネットワーク初期化(そして、古典的なLinkState方式に対応する)でそうであるかもしれません。
8.3.1. MPR Computation
8.3.1. 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:
以下はMPRsの品揃えに提案されたヒューリスティックを指定します。 それはノードが対称の厳しい2ホップの近所の1つのMPRノードによる意欲がウィルと異なっているリレーによるどんなノードにも達するのを決して可能にしないMPR-セットを構成します。インタフェース単位でヒューリスティックを適用しなければならなくて、MPRがノードに設定するI.は各インタフェースに見つけられた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.
このインタフェースの隣人から達することができるノードの2ホップの隣人のリスト。
Clausen & Jacquet Experimental [Page 39] RFC 3626 Optimized Link State Routing October 2003
[39ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
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.
(潜水艦)はウィルと異なった意欲とのインタフェースの隣人に決してセットしませんでした、そのインタフェースから届いているすべての厳しい2ホップの隣人がこれらの選択されたノードを通して届くように選択されて。
N:
N is the subset of neighbors of the node, which are
neighbor of the interface I.
N: Nはノードの隣人の部分集合です。(その隣人は、インタフェースIの隣人です)。
N2:
The set of 2-hop neighbors reachable from the interface
I, excluding:
N2: 以下を除いてインタフェースIから届いている2ホップの隣人のセット
(i) the nodes only reachable by members of N with
willingness WILL_NEVER
(i) 単に意欲を伴うNのメンバーで届いているノードは決してそうしないでしょう。
(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のメンバーであるところ)を近所付き合いさせて、ノードyの左右対称の隣人の数と定義されて、NとEXCLUDINGのすべてのメンバーのEXCLUDINGは計算を実行するノードです。
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
1MPRセットがウィル_ALWAYSと等しいN_意欲でNのすべてのメンバーから作られている始め
2 Calculate D(y), where y is a member of N, for all nodes in N.
2はD(y)について計算します。そこでは、yがNのすべてのノードのためのNのメンバーです。
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は、N2のノードに可到達性を提供するためにNのそれらのノードをMPRセットに追加します。(Nは唯一の**ノードです)。 例えば、N2のノードbがノードへの左右対称のリンクだけを通してコネNで達していて、次に、ノードを加えることができるなら、MPRへのaはセットしました。 現在MPRセットにおけるノードで覆われているN2からノードを取り除いてください。
4 While there exist nodes in N2 which are not covered by at
least one node in the MPR set:
MPRの少なくとも1つのノードで覆われていないN2のノードは存在しますが、4はセットしました:
Clausen & Jacquet Experimental [Page 40] RFC 3626 Optimized Link State Routing October 2003
[40ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
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.1 Nの各ノードに関しては、可到達性、すなわち、MPRセットにおける少なくとも1つのノードでまだ覆われなかった、この1ホップの隣人を通して届いているN2のノードの数について計算してください。
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.
ノードの中に最も高いN_意欲がある状態で、4.2はMPRとしてNで非ゼロの可到達性でノードを選定します。 選択式の場合には、N2のノードの最大数に可到達性を備えるノードを選択してください。 同じ量の可到達性を備える複数のノードの場合には、D(y)が、よりすばらしいMPRとしてノードを選定してください。 現在MPRセットにおけるノードで覆われているN2からノードを取り除いてください。
5 A node's MPR set is generated from the union of the MPR sets
for each interface. As an optimization, process each node, y,
in the MPR set in increasing order of N_willingness. If all
nodes in N2 are still covered by at least one node in the MPR
set excluding node y, and if N_willingness of node y is
smaller than WILL_ALWAYS, then node y MAY be removed from the
MPR set.
5 ノードのMPRセットはMPRセットの組合から各インタフェースに発生します。 最適化として、N_意欲の増加する注文で用意ができているMPRで各ノード、yを処理してください。 N2のすべてのノードがノードyを除くのを用意ができているMPRの少なくとも1つのノードでまだカバーされていて、ノードyのN_意欲がウィル_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'の間の1個以上のリンクが存在していると仮定してください。 ノード'a'がインタフェースの1つのMPRとしてノード'b'を選定したなら、MPRとしてノード'a'で追加性能の損失なしでいかなる他のインタフェースによってもノード'b'を選定されることができます。
8.4. Populating the MPR Selector Set
8.4. 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メッセージを通して合図されます。
8.4.1. HELLO Message Processing
8.4.1. こんにちは、メッセージ処理
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.
Neighbor Typeとのリストのそれ自身のインターフェース・アドレスの1つがMPR_NEIGHと等しいのがノードによってわかるならHELLOメッセージを受け取ると、HELLOメッセージからの情報をMPR Selector Setに記録しなければなりません。
The "validity time" MUST be computed from the Vtime field of the message header (see section 3.3.2). The MPR Selector Set SHOULD then be updated as follows:
メッセージヘッダーのVtime分野から「正当性時間」を計算しなければなりません(セクション3.3.2を見てください)。 MPR Selector Set SHOULD、次に、以下の通りアップデートしてください:
Clausen & Jacquet Experimental [Page 41] RFC 3626 Optimized Link State Routing October 2003
[41ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
1 If there exists no MPR selector tuple with:
1 いいえ、以下があるMPRセレクタtuple存在しているなら
MS_main_addr == Originator Address
MS主な_addr=創始者_アドレス
then a new tuple is created with:
そして、新しいtupleは以下で作成されます。
MS_main_addr = Originator Address
MS主な_addr=創始者_アドレス
2 The tuple (new or otherwise) with
2、tupleします(新しいかそうでない)。
MS_main_addr == Originator Address
MS主な_addr=創始者_アドレス
is then modified as follows:
次に、以下の通り変更されます:
MS_time = current time + validity time.
MS_時間は現在の時間+正当性時間と等しいです。
Deletion of MPR selector tuples occurs in case of expiration of the timer or in case of link breakage as described in the "Neighborhood and 2-hop Neighborhood Changes".
MPRセレクタtuplesの削除はタイマの満了の場合にリンク折損の場合に「近所と2ホップの近所変化」で説明されるように起こります。
8.5. Neighborhood and 2-hop Neighborhood Changes
8.5. 近所と2ホップの近所変化
A change in the neighborhood is detected when:
近所の変化が検出される、いつ:
- The L_SYM_time field of a link tuple expires. This is
considered as a neighbor loss if the link described by the
expired tuple was the last link with a neighbor node (on the
contrary, a link with an interface may break while a link with
another interface of the neighbor node remains without being
observed as a neighborhood change).
- リンクtupleのL_SYM_時間分野は期限が切れます。 これは満期のtupleによって説明されたリンクが隣人ノードとの最後のリンク(これに反して、隣人ノードの別のインタフェースとのリンクが近所が変化するので観測されないで残っている間、インタフェースとのリンクは壊れるかもしれない)であったなら隣人の損失であるとみなされます。
- 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.
- 新しいリンクtupleが非満期のL_SYM_時間があるLink Setに挿入されるか、または満期のL_SYM_時間があるtupleが変更されているので、L_SYM_時間は非満期になります。 対応する隣人ノードとのリンクについて説明するリンクtupleが全く以前になかったなら、これは隣人外観であるとみなされます。
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ホップの近所の変化は2ホップであるときに、検出されて、隣人tupleが期限が切れるか、またはセクション8.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_隣人の_の主な_addr=Main Addressとすべての2ホップのtuplesを削除しなければなりません。
Clausen & Jacquet Experimental [Page 42] RFC 3626 Optimized Link State Routing October 2003
[42ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
- In case of neighbor loss, all MPR selector tuples with
MS_main_addr == Main Address of the neighbor MUST be deleted
- 隣人の損失の場合には、隣人のMSの_の主な_addr=Main AddressとすべてのMPRセレクタtuplesを削除しなければなりません。
- 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メッセージを送るかもしれません。
9. Topology Discovery
9. トポロジー発見
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.
プロトコルのリンクの感じと隣人検出部分はMPRsを通して基本的にそれが直接交信できる隣人のリストとPacket FormatとForwarding部分と組み合わせた最適化された氾濫メカニズムを各ノードに提供します。 これに基づいて、トポロジー情報はネットワークを通して広められます。 現在のセクションは、リンクの感じと隣人検出で与えられた情報のどの部分が全体のネットワークに広められるか、そして、それがルートを構成するのにどのように使用されるかを説明します。
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-セレクタセットでそれ自体とノードとのリンクを少なくとも広めなければなりません、ルーティングを可能にするために十分な情報を提供するために。
9.1. TC Message Format
9.1. Tcメッセージ・フォーマット
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 広告を出している隣人主なアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 広告を出している隣人主なアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This is sent as the data-portion of the general message format with the "Message Type" set to TC_MESSAGE. The time to live SHOULD be set to 255 (maximum value) to diffuse the message into the entire network and Vtime set accordingly to the value of TOP_HOLD_TIME, as specified in section 18.3.
「メッセージタイプ」がある一般的なメッセージ・フォーマットのデータ部がTC_MESSAGEにセットしたので、これを送ります。 セクション18.3で指定されるようなSHOULDを住ませるために、255(最大値)に全体のネットワークにメッセージを拡散させるように設定されてください。そうすれば、Vtimeがそれに従って、_HOLD_タイム誌をTOPの値に設定する時。
Clausen & Jacquet Experimental [Page 43] RFC 3626 Optimized Link State Routing October 2003
[43ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
Advertised Neighbor Sequence Number (ANSN)
広告を出している隣人一連番号(ANSN)
A sequence number is associated with the advertised neighbor
set. Every time a node detects a change in its advertised
neighbor set, it increments this sequence number ("Wraparound"
is handled as described in section 19). This number is sent
in this ANSN field of the TC message to keep track of the most
recent information. When a node receives a TC message, it can
decide on the basis of this Advertised Neighbor Sequence
Number, whether or not the received information about the
advertised neighbors of the originator node is more recent
than what it already has.
一連番号は広告を出している隣人セットに関連しています。 ノードが広告を出している隣人セットにおける変化を検出するときはいつも、それはこの一連番号を増加します(「巻きつけて着るドレス」はセクション19で説明されるように扱われます)。 最新の情報の動向をおさえるTCメッセージのこのANSN分野でこの数を送ります。 ノードがTCメッセージを受け取るとき、このAdvertised Neighbor Sequence Numberに基づいて決めることができます、創始者ノードの広告を出している隣人の受信された情報がそれには何が既にあるかより最近であるか否かに関係なく。
Advertised Neighbor Main Address
広告を出している隣人主なアドレス
This field contains the main address of a neighbor node. All
main addresses of the advertised neighbors of the Originator
node are put in the TC message. If the maximum allowed
message size (as imposed by the network) is reached while
there are still advertised neighbor addresses which have not
been inserted into the TC-message, more TC messages will be
generated until the entire advertised neighbor set has been
sent. Extra main addresses of neighbor nodes may be included,
if redundancy is desired.
この分野は隣人ノードの主なアドレスを含んでいます。 Originatorノードの広告を出している隣人のすべての主なアドレスがTCメッセージに入れられます。 TC-メッセージに挿入されていないまだ広告を出した隣人アドレスがある間、メッセージサイズ(ネットワークによって課されるように)が許容された最大に達していると、より多くのTCメッセージが全体の広告を出している隣人セットを送るまで発生するでしょう。 冗長が望まれているなら、隣人ノードの余分な主なアドレスは含まれるかもしれません。
Reserved
予約されます。
This field is reserved, and MUST be set to "0000000000000000"
for compliance with this document.
この分野を予約されていて、「このドキュメントへの承諾のための0インチ」に設定しなければなりません。
9.2. Advertised Neighbor Set
9.2. 広告を出している隣人セット
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メッセージを送って、1セットのリンクを申告して、呼ばれた広告を出しているリンクはセットしました(少なくともすなわち、MPR Selectorセット、隣人すべてのノードへのリンクを含まなければなりません)(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はSHOULDに付番します。
Clausen & Jacquet Experimental [Page 44] RFC 3626 Optimized Link State Routing October 2003
[44ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
9.3. TC Message Generation
9.3. Tcメッセージ世代
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として選定された)をTopology Control(TC)メッセージを放送します。 TCメッセージは、ネットワークにおけるすべてのノードへあふれて、MPRsを利用します。 MPRsはトポロジー情報[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.
ノードの広告を出しているリンクセットが空になると、このノードSHOULDは以前に放たれたTC-メッセージの「正当性時間」(これはTOP_HOLD_タイム誌と通常、等しくなる)と等しいa持続時間の間、まだ(空)のTC-メッセージを送ります、前のTC-メッセージを無効にするために。 それ、そして、SHOULDは、何らかのノードが広告を出しているリンクセットに挿入されるまでTC-メッセージを送るのを止めます。
A node MAY transmit additional TC-messages to increase its reactiveness to link failures. When a change to the MPR selector set is detected and this change can be attributed to a link failure, a TC-message SHOULD be transmitted after an interval shorter than TC_INTERVAL.
ノードは失敗をリンクするために反動性を増加させる追加TC-メッセージを送るかもしれません。 MPRセレクタへの変化がいつセットしたか検出します、そして、この変化をリンクの故障の結果と考えることができます、TC-メッセージSHOULD。TC_INTERVALより短い間隔の後に伝えられてください。
9.4. TC Message Forwarding
9.4. Tcメッセージ推進
TC messages are broadcast and retransmitted by the MPRs in order to diffuse the messages in the entire network. TC messages MUST be forwarded according to the "default forwarding algorithm" (described in section 3.4).
TCメッセージは、全体のネットワークでメッセージを拡散させるようにMPRsによって放送されて、再送されます。 「デフォルト推進アルゴリズム」(セクション3.4で、説明される)に応じて、TCメッセージを転送しなければなりません。
9.5. TC Message Processing
9.5. Tcメッセージ処理
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を見てください)。 トポロジーはSHOULDを設定しました、次に、以下の通りアップデートしてください(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 このメッセージの送付者インタフェース(ネブラスカ: 創始者でない)がこのノードの左右対称の1ホップの近所にないなら、メッセージを捨てなければなりません。
Clausen & Jacquet Experimental [Page 45] RFC 3626 Optimized Link State Routing October 2003
[45ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
2 If there exist some tuple in the topology set where:
2 何かが存在しているなら、トポロジーのtupleはどこを設定したか:
T_last_addr == originator address AND
T_は創始者アドレス_addr=ANDを持続します。
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 トポロジーのすべてのtuplesがどこを設定するか:
T_last_addr == originator address AND
T_は創始者アドレス_addr=ANDを持続します。
T_seq < ANSN
T_seq<ANSN
MUST be removed from the topology set.
トポロジーセットから取り除かなければなりません。
4 For each of the advertised neighbor main address received in
the TC message:
4 広告を出している隣人各人に関しては、主なアドレスはTCメッセージで受信されました:
4.1 If there exist some tuple in the topology set where:
4.1 何かが存在しているなら、トポロジーのtupleはどこを設定したか:
T_dest_addr == advertised neighbor main address, AND
広告を出している隣人主な_T dest_addr=アドレス、AND
T_last_addr == originator address,
T_は創始者_addr=アドレスを持続します。
then the holding time of that tuple MUST be set to:
そして、以下のことようにそのtupleの把持時間を設定しなければなりません。
T_time = current time + validity time.
T_時間は現在の時間+正当性時間と等しいです。
4.2 Otherwise, a new tuple MUST be recorded in the topology
set where:
4.2 さもなければ、新しいtupleによる記録されて、トポロジーでは、どこがセットしていたかということでなければなりません:
T_dest_addr = advertised neighbor main address,
T_dest_addrは広告を出している隣人主なアドレスと等しいです。
T_last_addr = originator address,
T_は創始者_addr=アドレスを持続します。
T_seq = ANSN,
T_seqはANSNと等しいです。
T_time = current time + validity time.
T_時間は現在の時間+正当性時間と等しいです。
Clausen & Jacquet Experimental [Page 46] RFC 3626 Optimized Link State Routing October 2003
[46ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
10. Routing Table Calculation
10. 経路指定テーブル計算
Each node maintains a routing table which allows it to route data, destined for the other nodes in the network. The routing table is based on the information contained in the local link information base and the topology set. Therefore, if any of these sets are changed, the routing table is recalculated to update the route information about each destination in the network. The route entries are recorded in the routing table in the following format:
各ノードはそれがネットワークにおける他のノードのために運命づけられたデータを発送できる経路指定テーブルを維持します。 経路指定テーブルは地方のリンク情報ベースに保管されていた情報に基づきました、そして、トポロジーはセットしました。 したがって、これらのセットのどれかを変えるなら、ネットワークにおける各目的地に関する経由地案内をアップデートするために経路指定テーブルについて再計算します。 ルートエントリーは以下の形式で経路指定テーブルに記録されます:
1. R_dest_addr R_next_addr R_dist R_iface_addr
2. R_dest_addr R_next_addr R_dist R_iface_addr
3. ,, ,, ,, ,,
1. R_dest_addr R次の__addr R_dist R_iface_addr2。 R_dest_addr R次の__addr R_dist R_iface_addr3。 ,, ,, ,, ,,
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_addr、_R dist、および_R iface_addrから成ります。 そのようなエントリーは_R dest_addrによって特定されたノードがdistがローカルのノードから遠くを飛び越すR_であると見積もられていて、_次のインターフェース・アドレスR_addrがある左右対称の隣人ノードが_R dest_addrへのルートで次のホップノードであり、この左右対称の隣人ノードに_アドレスR iface_addrとの局所界面を通して届いていると指定します。 エントリーはルートが知られているネットワークにおける各目的地のために経路指定テーブルに記録されます。 すべての目的地(ルートは、壊れるか部分的に知られているだけである)がテーブルに記録されるというわけではありません。
More precisely, the routing table is updated when a change is detected in either:
どちらかに変化を検出するとき、より正確に、経路指定テーブルをアップデートします:
- the link set,
- リンクはセットしました。
- the neighbor set,
- 隣人はセットしました。
- the 2-hop neighbor set,
- 2ホップの隣人はセットしました。
- the topology set,
- トポロジーはセットしました。
- the Multiple Interface Association Information Base,
- 複数のインタフェース協会Information基地
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ホップのtupleが作成されるか、または取り外されるとき、トポロジーtupleが作成されるか、取り外される、または複数のインタフェース協会情報が変化すると。 このルーティング情報のアップデートは、どんな伝えられるべきメッセージも、発生もしませんし、引き金となりもしません、ネットワークも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
ノードXの経路指定テーブルを組み立てるために、最短パスアルゴリズムはYがX(SYMと等しいNeighbor Typeと)のあらゆる左右対称の隣人であるところにアークX->Yを保管している有向グラフにおける走行です。
Clausen & Jacquet Experimental [Page 47] RFC 3626 Optimized Link State Routing October 2003
[47ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
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.
T_としてのT_dest_addrとUが_addrを持続している間、ウィルにおいて異なった意欲と共にYが決して隣人ノードでなく、Neighborが_N_隣人メイン_addrとしてのYとN_2hop_addrとしてのZ、およびエントリーがトポロジーに存在するアークU->Vで設定する2ホップのエントリーが存在するアークY->ZはVと共にセットしました。
The following procedure is given as an example to calculate (or recalculate) the routing table:
経路指定テーブルは例として以下の手順について計算させられます(または、recalculate):
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)から始めて、新しいルーティングエントリーは加えられます。 したがって、各隣人のために、隣人のtupleはどこを設定したか:
N_status = SYM
N_状態は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:
(隣人への左右対称のリンクがあります)、隣人ノードのそれぞれの関連リンクtupleに関して、L_が>を調節するようなものは現在の時間と等しく、新しいルーティングエントリーは以下で経路指定テーブルに記録されます。
R_dest_addr = L_neighbor_iface_addr, of the
associated link tuple;
R_dest_addrは_関連リンクtupleのL_隣人iface_addrと等しいです。
R_next_addr = L_neighbor_iface_addr, of the
associated link tuple;
次のR__addrは_関連リンクtupleのL_隣人iface_addrと等しいです。
R_dist = 1;
R_dist=1。
R_iface_addr = L_local_iface_addr of the
associated link tuple.
R_iface_addrは_関連リンクtupleのL地方の_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;
次のR__addrは_現在のL_時間>=時間がある関連リンクtupleの1つのL_隣人iface_addrと等しいです。
R_dist = 1;
R_dist=1。
R_iface_addr = L_local_iface_addr of the
associated link tuple.
R_iface_addrは_関連リンクtupleのL地方の_iface_addrと等しいです。
Clausen & Jacquet Experimental [Page 48] RFC 3626 Optimized Link State Routing October 2003
[48ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
3 for each node in N2, i.e., a 2-hop neighbor which is not a
neighbor node or the node itself, and such that there exist at
least one entry in the 2-hop neighbor set where
N_neighbor_main_addr correspond to a neighbor node with
willingness different of WILL_NEVER, one selects one 2-hop
tuple and creates one entry in the routing table with:
3 N2の各ノード、すなわち、2ホップの隣人ノードかノード自体ではなく、そうする隣人、およびそのようなものに関しては、2ホップの隣人セットにおける意欲が異なっていた状態で隣人_メイン_addrが隣人ノードに対応するN_が決してそうしない少なくとも1つのエントリー、1が存在しているのが、1 2ホップのtupleを選択して、経路指定テーブルで以下で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__addrは経路指定テーブルで以下で_エントリーの次のR_addrと等しいです。
R_dest_addr == N_neighbor_main_addr
of the 2-hop tuple;
_2ホップのtupleのR_dest_addr=N_隣人メイン_addr。
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;
_2ホップのtupleのR_dest_addr=N_隣人メイン_addr。
3 The new route entries for the destination nodes h+1 hops away
are recorded in the routing table. The following procedure
MUST be executed for each value of h, starting with h=2 and
incrementing it by 1 each time. The execution will stop if no
new entry is recorded in an iteration.
3 h+1が遠くを飛び越す目的地ノードのための新しいルートエントリーは経路指定テーブルに記録されます。 hの各値のために以下の手順を実行しなければなりません、h=2から始まって、その都度それを1つ増加して。 どんな新しいエントリーも繰り返しに記録されないと、実行は止まるでしょう。
3.1 For each topology entry in the topology table, if its
T_dest_addr does not correspond to R_dest_addr of any
route entry in the routing table AND its T_last_addr
corresponds to R_dest_addr of a route entry whose R_dist
is equal to h, then a new route entry MUST be recorded in
the routing table (if it does not already exist) where:
3.1 トポロジーテーブルのそれぞれのトポロジーエントリーに、T_dest_addrが_経路指定テーブルのどんなルートエントリーのR dest_addrにも対応していない、T_最終_addrが_R dest_addrに対応するなら、R_distによるhと等しいです、次に、新しいルートエントリーをルーティングに記録しなければならないということであるルートエントリーでは、どこをテーブルの上に置いてくださいか(既に存在していないなら):
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__addr=R_addr、どこ:
R_dest_addr == T_last_addr
R T_dest_addr=_は_addrを持続します。
R_dist = h+1; and
R_distはh+1と等しいです。 そして
Clausen & Jacquet Experimental [Page 49] RFC 3626 Optimized Link State Routing October 2003
[49ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
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 T_dest_addr=_は_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_addrを選択するのに使用されるかもしれません。 h=1であるときに、結びつきが壊れるべきであるので、最も高い意欲とMPRセレクタがあるノードは次のホップとして好まれます。
4 For each entry in the multiple interface association base
where there exists a routing entry such that:
ルーティングエントリーが存在する複数のインタフェース協会ベースにおける各エントリーあたり4、以下のことのようなもの
R_dest_addr == I_main_addr (of the multiple interface
association entry)
_R_dest_addr=Iメイン_addr(複数のインタフェース協会エントリーの)
AND there is no routing entry such that:
そこではどんなルーティングエントリーもそのようなものでないので:
R_dest_addr == I_iface_addr
_R_dest_addr=I iface_addr
then a route entry is created in the routing table with:
そして、ルートエントリーは経路指定テーブルで以下で作成されます。
R_dest_addr = I_iface_addr (of the multiple interface
association entry)
_R_dest_addr=I iface_addr(複数のインタフェース協会エントリーの)
R_next_addr = R_next_addr (of the recorded
route entry)
_次の次のR__addr=R_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(記録されたルートエントリーの)と等しいです。
11. Node Configuration
11. ノード構成
This section outlines how a node should be configured, in order to operate in an OLSR MANET.
このセクションはノードがOLSR MANETで作動するためにどう構成されるべきであるかを概説します。
11.1. Address Assignment
11.1. アドレス課題
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.
マネのノードは定義されたアドレスの中の割り当てられたアドレスが系列であったならSHOULDをネットワークでつなぎます、すなわち、ノード。MANET SHOULDでは、ネットワーク・アドレスとネットマスクを通してアドレス可能であってください。
Clausen & Jacquet Experimental [Page 50] RFC 3626 Optimized Link State Routing October 2003
[50ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
Likewise, the nodes in each associated network SHOULD be assigned addresses from a defined address sequence, distinct from that being used in the MANET.
同様に、それぞれのノードは定義されたアドレスからの割り当てられたアドレスが系列であったならネットワークSHOULDを関連づけました、マネで中古のその存在と、異なります。
11.2. Routing Configuration
11.2. ルーティング設定
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.
どんなマネノード、も関連ネットワークかホストSHOULDが構成にされているので、それにはルートがあるようなものは関連ホストかネットワークとのインタフェースにセットしました。
11.3. Data Packet Forwarding
11.3. データ・パケット推進
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の指定されるとしてのパケットを進めていると思われます)。
12. Non OLSR Interfaces
12. 非OLSRインタフェース
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インタフェース、ノードSHOULDをOLSR MANETインタフェースからこれらまでの接続性に提供するには、外部経路情報をOLSR MANETに注入できてください。
Injecting routing information from the OLSR MANET to non OLSR interfaces is outside the scope of this specification. It should be clear, however, that the routing information for the OLSR MANET can be extracted from the topology table (see section 4.4) or directly from the routing table of OLSR, and SHOULD be injected onto the non OLSR interfaces following whatever mechanism (routing protocol, static configuration etc.) is provided on these interfaces.
この仕様の範囲の外にOLSR MANETから非OLSRインタフェースまでルーティング情報を注入するのがあります。 しかしながら、これらのインタフェースで提供されるどんなメカニズム(構成の静的なルーティング・プロトコルなど)にも従って、OLSR MANETのためのルーティング情報をトポロジーテーブル(セクション4.4を見る)から抜粋するか、または直接OLSR、およびSHOULDの経路指定テーブルから非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プロトコルを走らせることで異なったそうであるのに注意してください。
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に注ぐこの能力を提供するために、そのような非マネインタフェースがあるノードは定期的にHostとNetwork Association(HNA)メッセージを発行します、受取人が適切な経路指定テーブルを組み立てることができるくらいの情報を含んでいて。
Clausen & Jacquet Experimental [Page 51] RFC 3626 Optimized Link State Routing October 2003
[51ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
12.1. HNA Message Format
12.1. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ネットワーク・アドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ネットマスク| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ネットワーク・アドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ネットマスク| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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にセットして、Vtimeがそれに従って、_HOLD_タイム誌をHNAの値に設定するとき、これを送ります、セクション18.3で指定されるように。
Network Address
ネットワーク・アドレス
The network address of the associated network
関連ネットワークのネットワーク・アドレス
Netmask
ネットマスク
The netmask, corresponding to the network address immediately
above.
すぐに上でネットワーク・アドレスに対応するネットマスク。
12.2. Host and Network Association Information Base
12.2. 協会Information基地を接待して、ネットワークでつないでください。
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_ゲートウェイ_addrがゲートウェイのOLSRインタフェースのアドレスである、A_ネットワーク_addrとA_ネットマスクがネットワークを指定するこのtupleが吐き出すこのゲートウェイ、およびA_を通って時間が時間を指定する届いているネットワークとしたがって、*に関するアドレスとネットマスクがそうしなければならない「協会tuples」(_ゲートウェイ_addr、A_は_addrをネットワークでつなぎます、A_ネットマスク、A_時間)*を記録することによって機能するかもしれない情報が取り除かれると主張します。
The set of all association tuples in a node is called the "association set".
ノードのすべての協会tuplesのセットは「協会セット」と呼ばれます。
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).
気付かれて、aであるとHNA-メッセージをみなすことができるのがTC-メッセージについて「バージョンを広めた」ということであるべきです: HNAとTC-メッセージの両方の創始者は「可到達性」をある他のホストに発表します。
Clausen & Jacquet Experimental [Page 52] RFC 3626 Optimized Link State Routing October 2003
[52ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
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-メッセージでは、すべての可到達性が1ホストあたり1個のベースで発表されるので、ネットマスクは全く必要ではありません。 HNA-メッセージでは、ネットワークとネットマスクアドレスを通ってアドレス系列に可到達性を発表するのは個々のホスト・アドレスに可到達性を発表するより通常好まれます。
An important difference between TC- and HNA-messages is, that a TC message may have a canceling effect on previous information (if the ANSN is incremented), whereas information in HNA-messages is removed only upon expiration.
TCとHNA-メッセージの重要な違いはそうです、そして、TCメッセージは前の情報に取り消し影響を与えるかもしれませんが(ANSNが増加されているなら)、HNA-メッセージの情報は単に満了のときに取り除かれます。
12.3. HNA Message Generation
12.3. HNAメッセージ世代
A node with associated hosts and/or networks SHOULD periodically generate a Host and Network Association (HNA) message, containing pairs of (network address, netmask) corresponding to the connected hosts and networks. HNA-messages SHOULD be transmitted periodically every HNA_INTERVAL. The Vtime is set accordingly to the value of HNA_HOLD_TIME, as specified in section 18.3.
関連ホスト、そして/または、ネットワークSHOULDとのノードはHostとNetwork Association(HNA)メッセージを定期的に発生させます、接続ホストとネットワークに対応する(ネットワーク・アドレス、ネットマスク)の組を含んでいて。 定期的に伝えられてください。HNA-メッセージSHOULD、あらゆるHNA_INTERVAL。 Vtimeはセクション18.3で指定されるようにそれに従って、HNA_HOLD_タイム誌の値に用意ができています。
A node without any associated hosts and/or networks SHOULD NOT generate HNA-messages.
ノードはいずれなしでもホストを関連づけました、そして、ネットワークSHOULD NOTはHNA-メッセージを発生させます。
12.4. HNA Message Forwarding
12.4. 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に応じて、メッセージを転送しなければなりません。
12.5. HNA Message Processing
12.5. HNAメッセージ処理
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を見てください)。 協会はSHOULDを基礎づけます、次に、以下の通りアップデートしてください、:
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 このメッセージの送付者インタフェース(ネブラスカ: 創始者でない)がこのノードの左右対称の1ホップの近所にないなら、メッセージを捨てなければなりません。
2 Otherwise, for each (network address, netmask) pair in the
message:
2 さもなければ、それぞれ(ネットワーク・アドレス、ネットマスク)に関して、メッセージで対にしてください:
Clausen & Jacquet Experimental [Page 53] RFC 3626 Optimized Link State Routing October 2003
[53ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
2.1 if an entry in the association set already exists, where:
2.1 協会セットにおけるエントリーが既に存在しているならどこ:
A_gateway_addr == originator address
_ゲートウェイ_addr=創始者アドレス
A_network_addr == network address
_ネットワーク_addr=ネットワーク・アドレス
A_netmask == netmask
_ネットマスク=ネットマスク
then the holding time for that tuple MUST be set to:
そして、以下のことようにそのtupleのための把持時間を設定しなければなりません。
A_time = current time + validity time
_時間は現在の時間+正当性時間と等しいです。
2.2 otherwise, a new tuple MUST be recorded with:
2.2 さもなければ、以下で新しいtupleを記録しなければなりません。
A_gateway_addr = originator address
_ゲートウェイ_addr=創始者アドレス
A_network_addr = network address
_ネットワーク_addr=ネットワーク・アドレス
A_netmask = netmask
_ネットマスク=ネットマスク
A_time = current time + validity time
_時間は現在の時間+正当性時間と等しいです。
12.6. Routing Table Calculation
12.6. 経路指定テーブル計算
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,
協会における各tupleに関しては、セットしてください。
1 If there is no entry in the routing table with:
そこであるなら、1は経路指定テーブルで以下があるエントリーではありません。
R_dest_addr == A_network_addr/A_netmask
_ネットワーク_addr_R dest_addr=/は_ネットマスクです。
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:
前のステップかそれとも以下がある1つが存在したかどうかで2は新しいルーティングエントリーであるなら作成されました。
R_dest_addr == A_network_addr/A_netmask
_ネットワーク_addr_R dest_addr=/は_ネットマスクです。
R_dist > dist to A_gateway_addr of
current association set tuple,
_現在の協会のAゲートウェイ_addrへのR_dist>distはtupleを設定しました。
then the routing entry is modified as follows:
次に、ルーティングエントリーは以下の通り変更されます:
R_dest_addr = A_network_addr/A_netmask
_ネットワーク_addr_R dest_addr=/は_ネットマスクです。
Clausen & Jacquet Experimental [Page 54] RFC 3626 Optimized Link State Routing October 2003
[54ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
R_next_addr = the next hop on the path
from the node to A_gateway_addr
_ノードからAゲートウェイ_addrまでの経路の次の_次のR_addr=ホップ
R_dist = dist to A_gateway_addr
R_distは_Aゲートウェイ_addrへの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.
ルーティングからのtupleが_R_dest_addr=Aゲートウェイ_addrでセットしたので次の_addrとR_iface_addrが同じくらいへのセットが値であったならそうしなければならないR_。
12.7. Interoperability Considerations
12.7. 相互運用性問題
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インタフェースのサポートを実行しないかがこのセクションで指定された機能性を利用できないで、正しくメッセージをHNAに転送するでしょう、セクション3で指定されるように。
13. Link Layer Notification
13. リンクレイヤ通知
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セレクタがセットしたと主張するHELLO-メッセージからの情報に加えて使用されます。
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).
地方のリンクセットSHOULDセクション4.2で説明されることに加えたそれぞれのリンクtupleはL_LOST_LINK_時間分野を含んでいます。 L_LOST_LINK_時間は、確立したリンクが未定になるとき、失われているようにリンクを申告するためのタイマです。 (通知、これがことに関する部分集合であることがセクション14でお勧めである、その結果、リンクヒステリシスとリンクレイヤ通知は共存できます。)
Clausen & Jacquet Experimental [Page 55] RFC 3626 Optimized Link State Routing October 2003
[55ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
HELLO message generation should consider those new fields as follows:
HELLOメッセージ世代は、それらが以下の新しい分野であると考えるべきです:
1 if L_LOST_LINK_time is not expired, the link is advertised
with a link type of LOST_LINK. In addition, it is not
considered as a symmetric link in the updates of the
associated neighbor tuple (see section 8.1).
1 L_LOST_LINK_時間が満期でないなら、LOST_LINKのリンク型でリンクの広告を出します。 さらに、それは関連隣人tupleのアップデートにおける左右対称のリンクであるとみなされません(セクション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 隣接している左右対称の、または、非対称のインタフェースへのリンクが壊れているなら、対応するリンクtupleは変更されています: L_LOST_LINK_時間とL_時間は現在の時間+NEIGHB_HOLD_タイム誌に決められます。
3 this is considered as a link loss and the appropriate
processing described in section 8.5 should be
performed.
3 これはリンクの損失であるとみなされて、セクション8.5で説明された適切な処理は実行されるべきです。
13.1. Interoperability Considerations
13.1. 相互運用性問題
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.
リンクレイヤ通知は提供されます、ノードのために、ノードが隣人ノードへのリンクが無くなるかどうか決定するかもしれない追加評価基準。 失われているようにいったんリンクを検出すると、それの広告を出します、この仕様の前項で説明された条項によると。
14. Link Hysteresis
14. リンクヒステリシス
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.
確立したリンクはできるだけデータパケット損失を避けるのにおいて信頼できるべきです。 これは、リンクの感じがノードの間のburstyの損失か一時的な接続性に対して強健であるべきであることを含意します。 したがって、リンク感受性機構、以下の実現推薦SHOULDの丈夫さを高めるには、考えられてください。
14.1. Local Link Set
14.1. 地方のリンクセット
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.
地方のリンクセットSHOULDセクション4.2で説明されることに加えたそれぞれのリンクtupleは分野、L_リンク_品質分野、およびL_LOST_LINK_時間分野までL_リンク_を含んでいます。 未定のL_リンク_はリンクが未定であると考えられるかどうか(すなわち、リンクは確立していると考えられません)指定するブール値です。 L_リンク_品質はリンクの品質について説明する0〜1の無次元数です。 L_LOST_LINK_時間は、確立したリンクが未定になるとき、失われているようにリンクを申告するためのタイマです。
Clausen & Jacquet Experimental [Page 56] RFC 3626 Optimized Link State Routing October 2003
[56ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
14.2. Hello Message Generation
14.2. こんにちは、メッセージ世代
HELLO message generation should consider those new fields as follows:
HELLOメッセージ世代は、それらが以下の新しい分野であると考えるべきです:
1 if L_LOST_LINK_time is not expired, the link is advertised
with a link type of LOST_LINK.
1 L_LOST_LINK_時間が満期でないなら、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_時間が満期であり、L_がリンクするなら、未定であるのは、「本当」へのセット、リンクSHOULD NOTです。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_時間が満期であり、未定のL_リンク_が「誤ること」に用意ができているなら、以前にセクション6で説明されるようにリンクの広告を出します。
A node considers that it has a symmetric link for each link tuple where:
ノードは、各リンクへの左右対称のリンクがそれでどこをtupleするかと考えます:
1 L_LOST_LINK_time is expired, AND
1 吐き出されたL_LOST_LINK_時間、AND
2 L_link_pending is "false", AND
未定の2L_リンク_は「誤る」ANDです。
3 L_SYM_time is not expired.
3 L_SYM_時間は満期ではありません。
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.
この定義、「左右対称のリンク」SHOULDのために、隣人ノードのN_状態を計算するために、関連隣人tuple(セクション8.1を見る)をアップデートする中古のコネはそうです。 その結果、また、MPRを計算するとき、左右対称の地域の基礎がセットしたのでこの定義SHOULDが使用されて、よくルーティングの第一歩における「左右対称の隣人」のように計算を見送ってください。
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.
上記は別として、以前に説明されることは、リンクtuplesの分野を感じながら、高度なリンクを妨げません。 L_は_品質をリンクします、そして、L_は未定の_をリンクします、そして、現在のセクションによると、排他的にL_LOST_LINK_時間分野をアップデートします。 このセクションはリンクtuplesのいかなる他の分野の関数も変更しません。
14.3. Hysteresis Strategy
14.3. ヒステリシス戦略
The link between a node and some of its neighbor interfaces might be "bad", i.e., from time to time let HELLOs pass through only to fade out immediately after. In this case, the neighbor information base would contain a bad link for at least "validity time". The following hysteresis strategy SHOULD be adopted to counter this situation.
ノードと隣人インタフェースのいくつかとのリンクは直後の次第にぼんやりするためだけに終えた「悪く」て、すなわち、時々貸されたHELLOsパスであるかもしれません。 この場合、隣人情報ベースは少なくとも「正当性時間」に悪いリンクを含むでしょう。 以下のヒステリシス戦略SHOULD、採用されて、この状況を打ち返してください。
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
NIが聞いたそれぞれの隣人インタフェースと、私は連結して、対応するLink TupleのL_リンク_品質分野はリンクの設立を決定します。 L_リンク_品質の値は、2敷居HYST_THRESHOLD_HIGH、HYST_THRESHOLD_LOWと比較されて、固定されています。
Clausen & Jacquet Experimental [Page 57] RFC 3626 Optimized Link State Routing October 2003
[57ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
between 0 and 1 and such that HYST_THRESHOLD_HIGH >= HYST_THRESHOLD_LOW.
0〜1とHYST_THRESHOLD_HIGH>がHYST_THRESHOLD_LOWと等しいようなもの。
The L_link_pending field is set according to the following:
以下に従って、分野までL_リンク_は用意ができています:
1 if L_link_quality > HYST_THRESHOLD_HIGH:
1 L_が_品質>HYST_敷居を_高くリンクするなら:
L_link_pending = false
L_は未定の_を= 虚偽でリンクします。
L_LOST_LINK_time = current time - 1 (expired)
現在のL_LOST_LINK_時間=時間--1(満期)です。
2 otherwise, if L_link_quality < HYST_THRESHOLD_LOW:
2 _さもなければ、Lであるなら、_品質<HYST_THRESHOLD_LOWをリンクしてください:
L_link_pending = true
L_は= 本当に未定の_をリンクします。
L_LOST_LINK_time = min (L_time, current time +
NEIGHB_HOLD_TIME)
L_LOST_LINK_時間=分(L_時間、現在の時間+NEIGHB_HOLD_タイム誌)
(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_がリンクするなら、品質<はHYST_THRESHOLD_HIGHと等しいです:
L_link_pending and L_LOST_LINK_time remain unchanged.
未定のL_リンク_とL_LOST_LINK_時間は変わりがありません。
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.
その結果、リンクが確立していると考えるための状態はリンクを落とすための状態より厳しいです。 その結果、HYST_THRESHOLD_LOWの下に低下しながらタイマ満了(セクション7で説明されるように)に基づいたL_リンク_品質の上でリンクを落とすことができるのに注意してください。
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.
通知も、リンクがあっても、それはそれぞれの受信されたHELLOメッセージのためにリンクヒステリシスによって設立されるようにまだリンクtuplesをアップデートしている(セクション7で説明されるように)と考えませんでした。 明確に、これは、リンクヒステリシスが、リンクが「確立している」とみなすかどうかにかかわらずリンクtuplesのL_時間分野で決定する以外に、リンクセットにおけるtuplesが期限が切れないのを含意します。
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_リンク_品質分野にリンク品質に関する見積りを維持されて、格納しなければなりません。 受信されたメッセージの信号/騒音レベルがある程度の利用可能であるなら(例えば、リンクレイヤ通知としての)、正常化の後に見積りとしてそれを使用できます。
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
信号/雑音情報か他のどんなリンク品質情報も利用可能でないなら、リンクレイヤ、以下はそうすることができるアルゴリズムから、利用されてください(それはトランスミッション成功率の指数関数的に平坦な移動平均線です)。 アルゴリズムはparameterizedされます。
Clausen & Jacquet Experimental [Page 58] RFC 3626 Optimized Link State Routing October 2003
[58ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
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).
数であるスケーリングパラメータHYST_SCALINGは0〜1を修理しました。 インタフェースIによって聞かれたそれぞれの隣人インタフェースNIに関しては、初めてのNIはIによって聞かれて、L_リンク_品質はHYST_SCALING(未定の_が本当に設定しているL_リンクとL_LOST_LINK_時間から現在の時間--1)に設定されます。
A tuple is updated according to two rules. Every time an OLSR packet emitted by NI is received by I, the stability rule is applied:
2つの規則に従って、tupleをアップデートします。 IでNIによって放たれたOLSRパケットを受け取るときはいつも、安定性規則は適用されています:
L_link_quality = (1-HYST_SCALING)*L_link_quality
+ HYST_SCALING.
L_リンク_品質は(1-HYST_スケーリング)*L_リンク_品質+HYST_スケーリングと等しいです。
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_リンク_品質は(1-HYST_スケーリング)*L_リンク_品質と等しいです。
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パケットの損失はインタフェース基礎あたりのaでなくなったPacket Sequence民数記を追跡して、ノードからの「長期の沈黙」によって検出されます。 「長期の沈黙はこのようにして検出されるかもしれません」 インタフェースNI(NIから受け取られた最後のHELLOメッセージのHtime分野から、計算される)のHELLO放出間隔の間、インタフェースIにインタフェースNIからOLSRパケットを全く受け取っていないなら、OLSRパケットの損失を検出します。
14.4. Interoperability Considerations
14.4. 相互運用性問題
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.
リンクヒステリシスはノードのために、隣人ノードへのリンクを受け入れるか、または拒絶する評価基準を決定します。 ネットワークにおけるノードには、それらが交信する予定であるメディアの本質によると、異なった評価基準があるかもしれません。 いったんリンクを受け入れると、それの広告を出します、この仕様の前項で説明された条項によると。
15. Redundant Topology Information
15. 余分なトポロジー情報
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パラメタと呼ばれるローカルのパラメタに基づく以下の規則に従って、広告を出しているリンクセットを造ることができます。
Clausen & Jacquet Experimental [Page 59] RFC 3626 Optimized Link State Routing October 2003
[59ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
15.1. TC_REDUNDANCY Parameter
15.1. Tc_冗長パラメタ
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メッセージに含まれるかもしれない情報量をローカルのノードに指定します。 パラメタSHOULD、以下の通り解釈されてください:
- if the TC_REDUNDANCY parameter of the node is 0, then the
advertised link set of the node is limited to the MPR
selector set (as described in section 8.3),
- ノードのTC_REDUNDANCYパラメタが0であるなら、ノードの広告を出しているリンクセットはMPRセレクタセットに制限されます(セクション8.3で説明されるように)。
- if the TC_REDUNDANCY parameter of the node is 1, then the
advertised link set of the node is the union of its MPR set
and its MPR selector set,
- ノードのTC_REDUNDANCYパラメタが1であるなら、ノードの広告を出しているリンクセットはMPRセットの組合です、そして、MPRセレクタはセットしました。
- if the TC_REDUNDANCY parameter of the node is 2, then the
advertised link set of the node is the full neighbor link set.
- ノードのTC_REDUNDANCYパラメタが2であるなら、ノードの広告を出しているリンクセットは完全な隣人リンクセットです。
A node with willingness equal to WILL_NEVER SHOULD have TC_REDUNDANCY also equal to zero.
またNEVER SHOULDがTC_REDUNDANCYにゼロと等しくさせるウィル_と等しい意欲に伴うノード。
15.2. Interoperability Considerations
15.2. 相互運用性問題
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メッセージを送って、1セットのリンクを申告して、呼ばれた広告を出しているリンク(少なくともすなわち、MPR Selectorセット、隣人すべてのノードへのリンクを含まなければならない)はセットしました(MPRとして送付者ノードを選定しました)。 これはセクション10によると、ルートを計算できるのを保証できるくらいの情報です。
The provisions in this section specifies how additional information may be declared, as specified through a TC_REDUNDANCY parameter. TC_REDUNDANCY = 0 implies that the information declared corresponds exactly to the MPR Selector set, identical to section 9. Other values of TC_REDUNDANCY specifies additional information to be declared, i.e., the contents of the MPR Selector set is always declared. Thus, nodes with different values of TC_REDUNDANCY may coexist in a network: control messages are carried by all nodes in accordance with section 3, and all nodes will receive at least the link-state information required to construct routes as described in section 10.
このセクションの条項は追加情報がTC_REDUNDANCYパラメタを通して指定されるようにどう宣言されるかもしれないかを指定します。 TC_REDUNDANCY=0は、宣言された情報がちょうどセクション9と同じMPR Selectorセットに対応するのを含意します。 TC_REDUNDANCYの他の値は宣言されるために追加情報を指定して、すなわち、MPR Selectorセットのコンテンツはいつも宣言されます。 したがって、TC_REDUNDANCYの異価があるノードはネットワークで共存するかもしれません: セクション3に従って、コントロールメッセージはすべてのノードによって伝えられます、そして、すべてのノードが少なくとも情報がセクション10で説明されるようにルートを構成するのを必要としたリンク状態を受けるでしょう。
16. MPR Redundancy
16. MPR冗長
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
MPR冗長はノードが余分なMPRsを選択する能力を指定します。 セクション4.5は、ノードが、MPRセットができるだけ小さいのを選択するはずであると指定します、プロトコルオーバーヘッドを下げるために。 MPRsがそうであり、すべての厳しい2ホップのノードが少なくとも1つのMPRノードを通して届くに違いないように選択する評価基準。 MPRの冗長はセットしました。
Clausen & Jacquet Experimental [Page 60] RFC 3626 Optimized Link State Routing October 2003
[60ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
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セットにおける冗長は、より多くのノードでノードのための可到達性の広告を出して、その結果、追加リンクをネットワークに拡散させるのを確実にします。
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適用範囲を増加させると決めるかもしれません。
16.1. MPR_COVERAGE Parameter
16.1. MPR_適用範囲パラメタ
The MPR coverage is defined by a single local parameter, MPR_COVERAGE, specifying by how many MPR nodes any strict 2-hop node should be covered. MPR_COVERAGE=1 specifies that the overhead of the protocol is kept at a minimum and causes the MPR selection to operate as described in section 8.3.1. MPR_COVERAGE=m ensures that, if possible, a node selects its MPR set such that all strict 2-hop nodes for an interface are reachable through at least m MPR nodes on that interface. MPR_COVERAGE can assume any integer value > 0. The heuristic MUST be applied per interface, I. The MPR set for a node is the union of the MPR sets found for each interface.
MPR適用範囲はただ一つのローカルのパラメタによって定義されます、MPR_COVERAGE、何か厳しい2ホップのノードがいくつのMPRノードでカバーされているべきであるかを指定して。 MPR_COVERAGE=1はプロトコルのオーバーヘッドが最小限で保たれると指定して、セクション8.3.1で説明されるようにMPR選択を作動させます。 MPR_COVERAGE=mはそれを確実にします、可能です、ノードがMPRセットを選択するのでインタフェースのためのすべての厳しい2ホップのノードが少なくともそれのMPRノードが連結するmを通して届くなら。 MPR_COVERAGEは、どんな整数も値の>0であると仮定できます。 インタフェース単位でヒューリスティックを適用しなければならなくて、MPRがノードに設定するI.は各インタフェースに見つけられた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の異価で作動するかもしれません。
16.2. MPR Computation
16.2. MPR計算
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で1つの定義で説明されたそれから広げられます:
Poorly covered node:
ノードを不十分にカバーしています:
A poorly covered node is a node in N2 which is covered by less
than MPR_COVERAGE nodes in N.
不十分に覆われたノードはMPR_COVERAGEノードNにおける以下で覆われているN2のノードです。
The proposed heuristic for selecting MPRs is then as follows:
次に、MPRsを選択するための提案されたヒューリスティックは以下の通りです:
1 Start with an MPR set made of all members of N with
willingness equal to WILL_ALWAYS
1MPRセットがウィル_ALWAYSと等しい意欲でNのすべてのメンバーから作られている始め
2 Calculate D(y), where y is a member of N, for all nodes in N.
2はD(y)について計算します。そこでは、yがNのすべてのノードのためのNのメンバーです。
Clausen & Jacquet Experimental [Page 61] RFC 3626 Optimized Link State Routing October 2003
[61ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
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はMPRsとして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で覆われていないN2のノードは存在しますが、MPRのCOVERAGEノードはセットしました:
4.1 For each node in N, calculate the reachability, i.e.,
the number of nodes in N2 which are not yet covered
by at least MPR_COVERAGE nodes in the MPR set, and
which are reachable through this 1-hop neighbor;
4.1 Nの各ノードに関しては、可到達性、すなわち、少なくともMPRのCOVERAGEノードが設定するMPR_でまだ覆われなかった、この1ホップの隣人を通して届いているN2のノードの数について計算してください。
4.2 Select as a MPR the node with highest willingness among
the nodes in N with non-zero reachability. In case of
multiple choice select the node which provides
reachability to the maximum number of nodes in N2. In
case of multiple nodes providing the same amount of
reachability, select the node as MPR whose D(y) is
greater. Remove the nodes from N2 which are now covered
by MPR_COVERAGE nodes in the MPR set.
ノードの中に最も高い意欲がある状態で、4.2はMPRとしてNで非ゼロの可到達性でノードを選定します。 選択式の場合には、N2のノードの最大数に可到達性を備えるノードを選択してください。 同じ量の可到達性を備える複数のノードの場合には、D(y)が、よりすばらしいMPRとしてノードを選定してください。 現在MPRのCOVERAGEノードが設定する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 MPR_COVERAGE nodes
in the MPR set excluding node y, and if N_willingness of node
y is smaller than WILL_ALWAYS, then node y MAY be removed from
the MPR set.
5 ノードのMPRセットはMPRセットの組合から各インタフェースに発生します。 最適化として、N_意欲の増加する注文で用意ができているMPRで各ノード、yを処理してください。 N2のすべてのノードがノードyを除きながら少なくともMPRのCOVERAGEノードが設定するMPR_でまだカバーされていて、ノードyのN_意欲がウィル_ALWAYSより小さいなら、ノードyはMPRセットから取り除かれるかもしれません。
When the MPR set has been computed, all the corresponding main addresses are stored in the MPR Set.
MPRセットを計算してあるとき、すべての対応する主なアドレスがMPR Setに格納されます。
16.3. Interoperability Considerations
16.3. 相互運用性問題
The MPR set of a node MUST, according to section 8.3, be calculated by a node in such a way that it, through the neighbors in the MPR- set, can reach all symmetric strict 2-hop neighbors. This is achieved by the heuristics in this section, for all values of MPR_COVERAGE > 0. MPR_COVERAGE is a local parameter for each node. Setting this parameter affects only the amount of redundancy in part of the network.
セクション8.3によると、ノードはMPRセットにおける隣人を通してすべての左右対称の厳しい2ホップの隣人に届くことができるような方法でノードのMPRセットについて計算しなければなりません。 これは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で指定された発見的教授法と同じであるのに注意してください。
Clausen & Jacquet Experimental [Page 62] RFC 3626 Optimized Link State Routing October 2003
[62ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
Nodes with different values of MPR_COVERAGE may coexist in a network: control messages are carried by all nodes in accordance with section 3, and all nodes will receive at least the link-state information required to construct routes as described in sections 9 and 10.
MPR_COVERAGEの異価があるノードはネットワークで共存するかもしれません: セクション3に従って、コントロールメッセージはすべてのノードによって伝えられます、そして、すべてのノードが少なくとも情報がセクション9と10で説明されるようにルートを構成するのを必要としたリンク状態を受けるでしょう。
17. IPv6 Considerations
17. IPv6問題
All the operations and parameters described in this document used by OLSR for IP version 4 are the same as those used by OLSR for IP version 6. To operate with IP version 6, the only required change is to replace the IPv4 addresses with IPv6 address. The minimum packet and message sizes (under which there is rejection) should be adjusted accordingly, considering the greater size of IPv6 addresses.
IPバージョン4にOLSRによって使用されたこのドキュメントで説明されたすべての操作とパラメタがIPバージョン6にOLSRによって使用されたものと同じです。 IPバージョン6で作動するために、唯一の必要な変化がIPv4アドレスをIPv6アドレスに取り替えることになっています。 最小のパケットとメッセージサイズ(そこに拒絶がある)はそれに従って、調整されるべきです、IPv6アドレスの、より大きいサイズを考える場合。
18. Proposed Values for Constants
18. 定数のための提案された値
This section list the values for the constants used in the description of the protocol.
このセクションはプロトコルの記述に使用される定数のために値を記載します。
18.1. Setting emission intervals and holding times
18.1. 放出間隔を設定して、回を保持します。
The proposed constant for C is the following:
C提案された定数は以下です:
C = 1/16 seconds (equal to 0.0625 seconds)
1/16C=秒(0.0625秒と等しい)です。
C is a scaling factor for the "validity time" calculation ("Vtime"
and "Htime" fields in message headers, see section 18.3). The
"validity time" advertisement is designed such that nodes in a
network may have different and individually tuneable emission
intervals, while still interoperate fully. For protocol functioning
and interoperability to work:
Cは「正当性時間」計算のためのけた移動子(セクション18.3は、"Vtime"と"Htime"が中でメッセージヘッダーをさばくのを見る)です。 「正当性時間」広告はネットワークにおけるノードが異なるようにするかもしれない設計されたそのようなものです、そして、個別に、まだ間の同調可能放出間隔は完全に共同利用します。 プロトコル機能と相互運用性が扱うように:
- the advertised holding time MUST always be greater than the
refresh interval of the advertised information. Moreover, it
is recommended that the relation between the interval (from
section 18.2), and the hold time is kept as specified
in section 18.3, to allow for reasonable packet loss.
- 広告を出している把持時間がいつもより大きいに違いない、広告を出している情報の間隔をリフレッシュしてください。 そのうえ、間隔(セクション18.2からの)と、保持時間との関係がそうであることはお勧めです。指定されるとして、セクション18.3では、手頃なパケット損失を考慮するために、保たれます。
- the constant C SHOULD be set to the suggested value. In order
to achieve interoperability, C MUST be the same on all nodes.
- 一定のC SHOULD、提案された値に設定されてください。 相互運用性を達成するために、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.
- 広告を出している把持に伴う回(上の規制を条件とした)がノード基礎あたりのaに選択されるかもしれない放出間隔(セクション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
与えられた実現のタイマ解決が正確でシステムを起こすことができないかもしれないくらいのメモは、回をリフレッシュするか、または正確に回を吐き出します: 実現SHOULDは切り上げます。
Clausen & Jacquet Experimental [Page 63] RFC 3626 Optimized Link State Routing October 2003
[63ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
'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")。
18.2. Emission Intervals
18.2. 放出間隔
HELLO_INTERVAL = 2 seconds
2HELLO_INTERVAL=秒
REFRESH_INTERVAL = 2 seconds
2REFRESH_INTERVAL=秒
TC_INTERVAL = 5 seconds
5TC_INTERVAL=秒
MID_INTERVAL = TC_INTERVAL
中間の_間隔=Tc_間隔
HNA_INTERVAL = TC_INTERVAL
HNA_間隔=Tc_間隔
18.3. Holding Time
18.3. 把持時間
NEIGHB_HOLD_TIME = 3 x REFRESH_INTERVAL
NEIGHB_HOLD_タイム誌=3x REFRESH_INTERVAL
TOP_HOLD_TIME = 3 x TC_INTERVAL
TOP_HOLD_タイム誌=3x TC_INTERVAL
DUP_HOLD_TIME = 30 seconds
30_タイム誌=秒のDUP_HOLD
MID_HOLD_TIME = 3 x MID_INTERVAL
MID_HOLD_タイム誌=3x MID_INTERVAL
HNA_HOLD_TIME = 3 x HNA_INTERVAL
HNA_HOLD_タイム誌=3x 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*(+ /16あたり1)値=*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が分野とbの最も高い4ビットによって表された整数であるところでは、整数は分野の最も低い4ビットを表しました。
Notice, that for the previous proposed value of C, (1/16 seconds), the values, in seconds, expressed by the formula above can be stored, without loss of precision, in binary fixed point or floating point numbers with at least 8 bits of fractional part. This corresponds with NTP time-stamps and single precision IEEE Standard 754 floating point numbers.
通知、Cの前の提案された値、(1/16秒)、秒の上の公式によって言い表された値のためのそれを格納できます、2進の定点の精度の損失も断片的な部分の少なくとも8ビットがある浮動小数点なしで。 これはNTPタイムスタンプと単精度IEEE Standard754浮動小数点に対応しています。
Clausen & Jacquet Experimental [Page 64] RFC 3626 Optimized Link State Routing October 2003
[64ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
Given one of the above holding times, a way of computing the mantissa/exponent representation of a number T (of seconds) is the following:
上の把持回の1つを考えて、数T(秒の)の仮数/解説者表現を計算する方法は以下です:
- find the largest integer 'b' such that: T/C >= 2^b
- 最も大きい整数'b'に以下のことのようなものを見つけてください。 T/C>は2^bと等しいです。
- compute the expression 16*(T/(C*(2^b))-1), which may not be a
integer, and round it up. This results in the value for 'a'
- 式16の*(T/(C*(2^b))-1)を計算してください。(それは、整数であって、それの周りで上がっていないかもしれません)。 これは'a'のための値をもたらします。
- if 'a' is equal to 16: increment 'b' by one, and set 'a' to 0
- 'a'が16と等しいなら: 'b'を1つ増加してください、そして、0に'a'を設定してください。
- 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の整数であるべきです、そして、分野は値が*16+bであることを保持する1バイトになるでしょう。
For instance, for values of 2 seconds, 6 seconds, 15 seconds, and 30 seconds respectively, a and b would be: (a=0,b=5), (a=8,b=6), (a=14,b=7) and (a=14,b=8) respectively.
例えば、2秒、6秒、15秒、および30秒の値のために、それぞれ、aとbは以下の通りでしょう。 (a=0、b=5), (a=8、b=6), (a=14、b=7) そして、(a=14、b=8) それぞれ。
18.4. Message Types
18.4. メッセージタイプ
HELLO_MESSAGE = 1
こんにちは、_メッセージ=1
TC_MESSAGE = 2
Tc_メッセージ=2
MID_MESSAGE = 3
中間の_メッセージ=3
HNA_MESSAGE = 4
HNA_メッセージ=4
18.5. Link Types
18.5. リンク型
UNSPEC_LINK = 0
UNSPEC_リンク=0
ASYM_LINK = 1
ASYM_リンク=1
SYM_LINK = 2
SYM_リンク=2
LOST_LINK = 3
無くなっている_リンク=3
18.6. Neighbor Types
18.6. 隣人タイプ
NOT_NEIGH = 0
_いななき=0でない
SYM_NEIGH = 1
SYM_いななき=1
MPR_NEIGH = 2
MPR_いななき=2
Clausen & Jacquet Experimental [Page 65] RFC 3626 Optimized Link State Routing October 2003
[65ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
18.7. Link Hysteresis
18.7. リンクヒステリシス
HYST_THRESHOLD_HIGH = 0.8
HYST_敷居_高値は0.8と等しいです。
HYST_THRESHOLD_LOW = 0.3
HYST_敷居_安値は0.3と等しいです。
HYST_SCALING = 0.5
HYST_スケーリング=0.5
18.8. Willingness
18.8. 意欲
WILL_NEVER = 0
_は0と決して等しくないでしょうか?
WILL_LOW = 1
ウィル_安値=1
WILL_DEFAULT = 3
ウィル_デフォルト=3
WILL_HIGH = 6
ウィル_高値=6
WILL_ALWAYS = 7
_はいつも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までどんな整数値にも設定されるかもしれなくて、他のノードを代表してどれくらい望んでいるノードが交通を進めているかことであるかと指定します。 ノードには、意欲ウィル_DEFAULTがデフォルトであるでしょう。 ウィル_は他のノードのための交通を運びたがっていないノードを決して示しません、例えば、リソース規制(バッテリーで低いような)のため。 ウィル_ALWAYSは、いつもノードが他のノードを代表して交通を運ぶのが選択されるべきであるのを示します、例えば、リソース豊富のため(永久的な電源のように、高容量は他のノードに連結します)。
A node may dynamically change its willingness as its conditions change.
状態が変化するのに従って、ノードはダイナミックに意欲を変えるかもしれません。
One possible application would, for example, be for a node, connected to a permanent power supply and with fully charged batteries, to advertise a willingness of WILL_ALWAYS. Upon being disconnected from the permanent power supply (e.g., a PDA being taken out of its charging cradle), a willingness of WILL_DEFAULT is advertised. As battery capacity is drained, the willingness would be further reduced. First to the intermediate value between WILL_DEFAULT and WILL_LOW, then to WILL_LOW and finally to WILL_NEVER, when the battery capacity of the node does no longer support carrying foreign traffic.
例えば、1つの可能な利用がウィル_ALWAYSの意欲の広告を出すために永久的な電源と、そして、完全に請求されたバッテリーに接続されたノードのためのものでしょう。 永久的な電源(例えば充電揺りかごから取り出されるPDA)から外されるとき、ウィル_DEFAULTの意欲の広告を出します。 バッテリー容量が汁気を切ったであるのに従って、意欲はさらに減少するでしょう。 ウィル_DEFAULTとウィル_LOWの間の中間的値と、そして、そして、ウィル_LOWと、そして、最終的なウィルへの1番目_ノードのバッテリー容量が、もう外国交通を運ぶのを決して支持しないと。
Clausen & Jacquet Experimental [Page 66] RFC 3626 Optimized Link State Routing October 2003
[66ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
18.9. Misc. Constants
18.9. ミスク 定数
TC_REDUNDANCY = 0
Tc_冗長=0
MPR COVERAGE = 1
MPR適用範囲=1
MAXJITTER = HELLO_INTERVAL / 4
MAXJITTERが等しい、こんにちは、_間隔/4
19. Sequence Numbers
19. 一連番号
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/2ORと等しいです。
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つのメッセージを比較するとき、したがって、それは巻きつけて着るドレスがあるときさえ可能です--どのメッセージが最新の情報を含むかを決定するために。
20. Security Considerations
20. セキュリティ問題
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は様々な攻撃のための目標を作ります。 このセクションで様々な可能な脆弱性について議論します。
20.1. Confidentiality
20.1. 秘密性
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コントロールメッセージを聞くだれにも明らかにされます。
Clausen & Jacquet Experimental [Page 67] RFC 3626 Optimized Link State Routing October 2003
[67ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
In situations where the confidentiality of the network topology is of importance, regular cryptographic techniques such as exchange of OLSR control traffic messages encrypted by PGP [9] or encrypted by some shared secret key can be applied to ensure that control traffic can be read and interpreted by only those authorized to do so.
ネットワーク形態の秘密性が重要である状況で、そうするのが認可されたものだけがコントロール交通を読んで、解釈できるのを保証するためにPGP[9]によってコード化されるか、またはいくらかの共有された秘密鍵によってコード化されたOLSRコントロール交通メッセージの交換などの通常の暗号のテクニックを適用できます。
20.2. Integrity
20.2. 保全
In OLSR, each node is injecting topological information into the network through transmitting HELLO messages and, for some nodes, TC messages. If some nodes for some reason, malicious or malfunction, inject invalid control traffic, network integrity may be compromised. Therefore, message authentication is recommended.
OLSRでは、各ノードは、HELLOメッセージといくつかのノードへのTCメッセージを送ることで位相的な情報をネットワークに注いでいます。 いくつかにおいて、理由の、そして、悪意があるいくつかのノードか不調であるなら、無効のコントロール交通を注入してください、そして、ネットワーク保全は妥協してもよいです。 したがって、通報認証はお勧めです。
Different such situations may occur, for instance:
例えば、異なったそのような状況は起こるかもしれません:
1 a node generates TC (or HNA) messages, advertising links to
non-neighbor nodes:
1 非隣人ノードへのリンクの広告を出して、ノードはTC(または、HNA)メッセージを発生させます:
2 a node generates TC (or HNA) messages, pretending to be
another node,
2 別のノードであるふりをして、ノードはTC(または、HNA)メッセージを発生させます。
3 a node generates HELLO messages, advertising non-neighbor
nodes,
3 非隣人ノードの広告を出して、ノードは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)の時の情報を繰り返すのを防ぐのがどのように必要であっても、ノードが明確にそのようなものを特定するのを許容するのがメッセージを遅らせました。
Clausen & Jacquet Experimental [Page 68] RFC 3626 Optimized Link State Routing October 2003
[68ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
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.
明確に、IPsec認証ヘッダーを雇うことで全体のOLSRコントロールメッセージの信憑性を確立できて、個人の信憑性はリンクされますが、(状況1と3)は、追加担保情報が分配されるのを必要とします。
An important consideration is, that all control messages in OLSR are transmitted either to all nodes in the neighborhood (HELLO messages) or broadcast to all nodes in the network (e.g., TC messages).
重要な考慮すべき事柄はそうであり、OLSRのすべてのコントロールメッセージがネットワーク(例えば、TCメッセージ)におけるすべてのノードへの近所(HELLOメッセージ)か放送ですべてのノードに送られます。
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秘密鍵によってサインされた1ブロックのテキストを考えて、そして、対応する公開鍵をもっているだれでもテキストの信憑性について確かめることができます。
20.3. Interaction with External Routing Domains
20.3. 外部の経路ドメインとの相互作用
OLSR does, through the HNA messages specified in section 12, provide a basic mechanism for injecting external routing information to the OLSR domain. Section 12 also specifies that routing information can be extracted from the topology table or the routing table of OLSR and, potentially, injected into an external domain if the routing protocol governing that domain permits.
OLSRはセクション12で指定されたHNAメッセージを通して外部のルーティング情報をOLSRドメインに注入するのに基本的機構を提供します。 また、セクション12はそのドメインを治めるルーティング・プロトコルが可能にするなら、ルーティング情報をトポロジーテーブルかOLSRの経路指定テーブルから抜粋して、潜在的に外部のドメインに注入できると指定します。
Other than as described in the section 20.2, when operating nodes, connecting OLSR to an external routing domain, care MUST be taken not to allow potentially insecure and un-trustworthy information to be injected from the OLSR domain to external routing domains. Care MUST be taken to validate the correctness of information prior to it being injected as to avoid polluting routing tables with invalid information.
外部の経路ドメインにOLSRを接続して、ノードを操作するとき、セクション20.2で説明されるのを除いて、潜在的に不安定で信頼できない情報がOLSRドメインから外部の経路ドメインまで注入されるのを許容しないように注意しなければなりません。 それの前に無効の情報で経路指定テーブルを汚染するのを避けるほど注入されながら情報の正当性を有効にするために注意しなければなりません。
A recommended way of extending connectivity from an existing routing domain to an OLSR routed MANET is to assign an IP prefix (under the authority of the nodes/gateways connecting the MANET with the exiting routing domain) exclusively to the OLSR MANET area, and to configure the gateways statically to advertise routes to that IP sequence to nodes in the existing routing domain.
既存の経路ドメインからOLSRまで発送された接続性を広げるお勧めの方法で、マネは、IP接頭語(出る経路ドメインにマネを接続するノード/ゲートウェイの権威の下における)を排他的にOLSR MANET領域に割り当てて、既存の経路ドメインのノードへのそのIP系列にルートの広告を出すために静的にゲートウェイを構成することになっています。
Clausen & Jacquet Experimental [Page 69] RFC 3626 Optimized Link State Routing October 2003
[69ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
20.4. Node Identity
20.4. ノードのアイデンティティ
OLSR does not make any assumption about node addresses, other than that each node is assumed to have a unique IP address.
OLSRはノードアドレスに関する少しの仮定もしません、各ノードには固有のIPアドレスがあると思われるのを除いて。
21. Flow and congestion control
21. 流れと輻輳制御
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最適化はコントロールオーバーヘッドで大いに節約されます、そして、2つの側でこれをします。 まず最初に、トポロジーの広告を出すパケットは、MPRセレクタだけを広告に掲載してもよいので、はるかに脆いです。 2番目に、MPRノードだけが放送パケットを進めるので、この情報をあふれさせるコストは大いに削減されます。 濃いネットワークでは、古典的な氾濫(OSPFなどの)[10]を使用することでルーティング・プロトコルと比べて、コントロール交通の減少は数桁のものであることができます。 この特徴は、自然により多くの帯域幅を役に立つデータ通信量に供給して、さらに混雑の国境を押します。 コントロール交通が連続していて周期的であるので、反応プロトコルが短い回のためにルート発見と修理のためのbursty氾濫でそれらのリンクで頻繁な衝突を引き起こすことによってリンク品質を破損するかもしれないルーティングで使用されるリンクの品質をより安定しているように保ちます、ことによるとルート修理滝を引き起こして。 しかしながら、あるOLSRオプションでは、彼らの締め切り(TCかHelloメッセージ)の前にトポロジー変化に対してプロトコルの反動性を増加させるように故意にいくつかのコントロールメッセージを送るかもしれません。 これはコントロール交通の小さくて、一時的で地方の増加を引き起こすかもしれません。
22. IANA Considerations
22. IANA問題
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分野、および割り当てられた以下の値のための値のために新しい登録を作成してあります:
Message Type Value
-------------------- -----
HELLO_MESSAGE 1
TC_MESSAGE 2
MID_MESSAGE 3
HNA_MESSAGE 4
メッセージタイプ価値-------------------- ----- こんにちは、_メッセージ1Tc_メッセージ2の中間の_メッセージ3HNA_メッセージ4
Future values in the range 5-127 of the Message Type can be allocated using standards action [7].
規格動作[7]を使用することでMessage Typeの範囲5-127の将来価値を割り当てることができます。
Additionally, values in the range 128-255 are reserved for private/local use.
さらに、範囲128-255の値は個人的であるか地方の使用のために予約されます。
Clausen & Jacquet Experimental [Page 70] RFC 3626 Optimized Link State Routing October 2003
[70ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
23. Acknowledgments
23. 承認
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 に感謝したがっている、gt;、ジャスティン Dean <jdean@itd.nrl.navy.mil を含む彼のチーム、gt;、プロトコル仕様の慎重なレビューを含むプロトコルの高度な隣人感受性機構と他の種々相における彼らの貴重な提案
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.
また、作者がクリストファー Dearlove <chris.dearlove@baesystems.com に感謝したがっている、gt;、MPR選択発見的教授法に関する貴重な入力とプロトコル仕様の慎重なレビューのために。
24. Contributors
24. 貢献者
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、78153Le Chesnay Cedex、BP105フランス
Phone: +33 1 3963 5215 EMail: Cedric.Adjih@inria.fr
以下に電話をしてください。 +33 1 3963 5215はメールされます: Cedric.Adjih@inria.fr
Thomas Heide Clausen Project HIPERCOM INRIA Rocquencourt, BP 105 78153 Le Chesnay Cedex, France
トーマスハイデクローゼンプロジェクトHIPERCOM INRIA Rocquencourt、78153Le Chesnay Cedex、BP105フランス
Phone: +33 1 3963 5133 EMail: T.Clausen@computer.org
以下に電話をしてください。 +33 1 3963 5133はメールされます: T.Clausen@computer.org
Philippe Jacquet Project HIPERCOM INRIA Rocquencourt, BP 105 78153 Le Chesnay Cedex, France
フィリップジャケプロジェクトHIPERCOM INRIA Rocquencourt、78153Le Chesnay Cedex、BP105フランス
Phone: +33 1 3963 5263 EMail: Philippe.Jacquet@inria.fr
以下に電話をしてください。 +33 1 3963 5263はメールされます: Philippe.Jacquet@inria.fr
Clausen & Jacquet Experimental [Page 71] RFC 3626 Optimized Link State Routing October 2003
[71ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
Anis Laouiti Project HIPERCOM INRIA Rocquencourt, BP 105 78153 Le Chesnay Cedex, France
アニスLaouitiプロジェクトHIPERCOM INRIA Rocquencourt、78153Le Chesnay Cedex、BP105フランス
Phone: +33 1 3963 5088 EMail: Anis.Laouiti@inria.fr
以下に電話をしてください。 +33 1 3963 5088はメールされます: Anis.Laouiti@inria.fr
Pascale Minet Project HIPERCOM INRIA Rocquencourt, BP 105 78153 Le Chesnay Cedex, France
パスカルMinetプロジェクトHIPERCOM INRIA Rocquencourt、78153Le Chesnay Cedex、BP105フランス
Phone: +33 1 3963 5233 EMail: Pascale.Minet@inria.fr
以下に電話をしてください。 +33 1 3963 5233はメールされます: Pascale.Minet@inria.fr
Paul Muhlethaler Project HIPERCOM INRIA Rocquencourt, BP 105 78153 Le Chesnay Cedex, France
ポールMuhlethalerプロジェクトHIPERCOM INRIA Rocquencourt、78153Le Chesnay Cedex、BP105フランス
Phone: +33 1 3963 5278 EMail: Paul.Muhlethaler@inria.fr
以下に電話をしてください。 +33 1 3963 5278はメールされます: Paul.Muhlethaler@inria.fr
Amir Qayyum Center for Advanced Research in Engineering Pvt. Ltd. 19 Ataturk Avenue Islamabad, Pakistan
アミールQayyumは先端研究のために工学でPvtを中心に置きます。 株式会社19Ataturk Avenueイスラマバード(パキスタン)
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、78153Le Chesnay Cedex、BP105フランス
Phone: +33 1 3963 5225 EMail: Laurent.Viennot@inria.fr
以下に電話をしてください。 +33 1 3963 5225はメールされます: Laurent.Viennot@inria.fr
Clausen & Jacquet Experimental [Page 72] RFC 3626 Optimized Link State Routing October 2003
[72ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
25. References
25. 参照
25.1. Normative References
25.1. 引用規格
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[5] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[7] T. Clausen, P. Jacquet, A. Laouiti, P. Muhlethaler, A.
Qayyum and L. Viennot. Optimized Link State Routing Protocol.
IEEE INMIC Pakistan 2001.
[7] T.クローゼン、P.ジャケ、A.Laouiti、P.Muhlethaler、A.Qayyum、およびL.Viennot。 最適化されたリンク州のルーティング・プロトコル。 IEEE INMICパキスタン2001。
25.2. Informative References
25.2. 有益な参照
[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。 多点リレー: 可動のワイヤレス・ネットワークでの氾濫のための効率的なテクニック。 システム科学(HICSS'2001)に関する第35年に一度のハワイ国際会議、'
[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は1996年6月に1、機能的な仕様エッツ300-652、ETSIをタイプします。
[4] P. Jacquet and L. Viennot, Overhead in Mobile Ad-hoc Network
Protocols, INRIA research report RR-3965, 2000.
[4] モバイルAd-hoc Networkプロトコル、INRIAのP.ジャケとL.Viennot、Overheadはレポート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.クローゼン、G.ハンセン、L.クリステンセン、およびG.Behrmann。 実験とシミュレーションでプロトコル、評価を発送する最適化されたリンク州。 2001年9月の「無線の個人的な移動通信」に関するIEEEシンポジウム。
[8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October
1998.
[8]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[9] Atkins, D., Stallings, W. and P. Zimmermann, "PGP Message
Exchange Formats", RFC 1991, August 1996.
[9] アトキンスとD.とストーリングズとW.とP.Zimmermann、「PGP交換処理形式」、RFC1991、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。 2の臨時のワイヤレス・ネットワークでのOLSR多点リレー氾濫の機能解析はモデル化されて、INRIAはレポートRR-4260、2001について研究します。
Clausen & Jacquet Experimental [Page 73] RFC 3626 Optimized Link State Routing October 2003
[73ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
26. Authors' Addresses
26. 作者のアドレス
Thomas Heide Clausen Project HIPERCOM INRIA Rocquencourt, BP 105 78153 Le Chesnay Cedex, France
トーマスハイデクローゼンプロジェクトHIPERCOM INRIA Rocquencourt、78153Le Chesnay Cedex、BP105フランス
Phone: +33 1 3963 5133 EMail: T.Clausen@computer.org
以下に電話をしてください。 +33 1 3963 5133はメールされます: T.Clausen@computer.org
Philippe Jacquet, Project HIPERCOM, INRIA Rocquencourt, BP 105 78153 Le Chesnay Cedex, France
フィリップ・ジャケ、プロジェクトHIPERCOM、INRIA Rocquencourt、78153Le Chesnay Cedex、BP105フランス
Phone: +33 1 3963 5263, EMail: Philippe.Jacquet@inria.fr
以下に電話をしてください。 +33 1 3963 5263、メール: Philippe.Jacquet@inria.fr
Clausen & Jacquet Experimental [Page 74] RFC 3626 Optimized Link State Routing October 2003
[74ページ]RFC3626の最適化されたリンク州のルート設定2003年10月に実験しているクローゼンとジャケ
27. Full Copyright Statement
27. 完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Clausen & Jacquet Experimental [Page 75]
クローゼンとジャケExperimentalです。[75ページ]
一覧
スポンサーリンク
