[要約] RFC 7181は、Optimized Link State Routing Protocol Version 2（OLSRv2）に関する仕様書であり、OLSRv2の概要、機能、および目的を提供しています。OLSRv2は、無線アドホックネットワークでの効率的な経路選択を可能にするために設計されています。
Internet Engineering Task Force (IETF) T. Clausen
Request for Comments: 7181 LIX, Ecole Polytechnique
Category: Standards Track C. Dearlove
ISSN: 2070-1721 BAE Systems ATC
P. Jacquet
Alcatel-Lucent Bell Labs
U. Herberg
Fujitsu Laboratories of America
April 2014
The Optimized Link State Routing Protocol Version 2
最適化されたリンク状態ルーティングプロトコルバージョン2
Abstract
概要
This specification describes version 2 of the Optimized Link State Routing Protocol (OLSRv2) for Mobile Ad Hoc Networks (MANETs).
この仕様は、モバイルアドホックネットワーク（MANET）用の最適化リンクステートルーティングプロトコル（OLSRv2）のバージョン2について説明しています。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7181.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7181で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。 IETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得せずに、このドキュメントをIETF標準プロセス外で変更したり、その派生物をIETF標準プロセス外で作成したりすることはできません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction ....................................................5
2. Terminology .....................................................6
3. Applicability Statement .........................................9
4. Protocol Overview and Functioning ..............................10
4.1. Overview ..................................................10
4.2. Routers and Interfaces ....................................12
4.3. Information Base Overview .................................13
4.3.1. Local Information Base .............................13
4.3.2. Interface Information Base .........................14
4.3.3. Neighbor Information Base ..........................14
4.3.4. Topology Information Base ..........................14
4.3.5. Received Message Information Base ..................16
4.4. Signaling Overview ........................................16
4.5. Link Metrics ..............................................17
4.6. Flooding MPRs and Routing MPR .............................18
4.7. Routing Set Use ...........................................19
5. Protocol Parameters and Constants ..............................19
5.1. Protocol and Port Numbers .................................19
5.2. Multicast Address .........................................20
5.3. Interface Parameters ......................................20
5.3.1. Received Message Validity Time .....................20
5.4. Router Parameters .........................................20
5.4.1. Local History Times ................................20
5.4.2. Link Metric Parameters .............................21
5.4.3. Message Intervals ..................................21
5.4.4. Advertised Information Validity Times ..............22
5.4.5. Processing and Forwarding Validity Times ...........22
5.4.6. Jitter .............................................23
5.4.7. Hop Limit ..........................................23
5.4.8. Willingness ........................................24
5.5. Parameter Change Constraints ..............................25
5.6. Constants .................................................27
5.6.1. Link Metric Constants ..............................27
5.6.2. Willingness Constants ..............................28
5.6.3. Time Constant ......................................28
6. Link Metric Values .............................................28
6.1. Link Metric Representation ................................28
6.2. Link Metric Compressed Form ...............................29
7. Local Information Base .........................................29
7.1. Originator Set ............................................30
7.2. Local Attached Network Set ................................30
8. Interface Information Base .....................................31
8.1. Link Set ..................................................31
8.2. 2-Hop Set .................................................32
9. Neighbor Information Base ......................................32
10. Topology Information Base .....................................34
10.1. Advertising Remote Router Set ............................34
10.2. Router Topology Set ......................................35
10.3. Routable Address Topology Set ............................35
10.4. Attached Network Set .....................................36
10.5. Routing Set ..............................................37
11. Received Message Information Base .............................37
11.1. Received Set .............................................38
11.2. Processed Set ............................................38
11.3. Forwarded Set ............................................39
12. Information Base Properties ...................................39
12.1. Corresponding Protocol Tuples ............................39
12.2. Address Ownership ........................................40
13. Packets and Messages ..........................................41
13.1. Messages .................................................41
13.2. Packets ..................................................41
13.3. TLVs .....................................................42
13.3.1. Message TLVs ......................................42
13.3.2. Address Block TLVs ................................42
14. Message Processing and Forwarding .............................45
14.1. Actions When Receiving a Message .........................45
14.2. Message Considered for Processing ........................46
14.3. Message Considered for Forwarding ........................47
15. HELLO Messages ................................................49
15.1. HELLO Message Generation .................................49
15.2. HELLO Message Transmission ...............................51
15.3. HELLO Message Processing .................................51
15.3.1. HELLO Message Discarding ..........................51
15.3.2. HELLO Message Usage ...............................52
16. TC Messages ...................................................56
16.1. TC Message Generation ....................................56
16.2. TC Message Transmission ..................................58
16.3. TC Message Processing ....................................59
16.3.1. TC Message Discarding .............................59
16.3.2. TC Message Processing Definitions .................61
16.3.3. Initial TC Message Processing .....................61
16.3.4. Completing TC Message Processing ..................65
17. Information Base Changes ......................................66
17.1. Originator Address Changes ...............................66
17.2. Link State Changes .......................................66
17.3. Neighbor State Changes ...................................67
17.4. Advertised Neighbor Changes ..............................67
17.5. Advertising Remote Router Tuple Expires ..................68
17.6. Neighborhood Changes and MPR Updates .....................68
17.7. Routing Set Updates ......................................70
18. Selecting MPRs ................................................71
18.1. Overview .................................................72
18.2. Neighbor Graph ...........................................72
18.3. MPR Properties ...........................................73
18.4. Flooding MPRs ............................................74
18.5. Routing MPRs .............................................76
18.6. Calculating MPRs .........................................77
19. Routing Set Calculation .......................................78
19.1. Network Topology Graph ...................................78
19.2. Populating the Routing Set ...............................80
20. Proposed Values for Parameters ................................81
20.1. Local History Time Parameters ............................82
20.2. Message Interval Parameters ..............................82
20.3. Advertised Information Validity Time Parameters ..........82
20.4. Received Message Validity Time Parameters ................82
20.5. Jitter Time Parameters ...................................82
20.6. Hop Limit Parameter ......................................82
20.7. Willingness Parameters ...................................82
21. Sequence Numbers ..............................................83
22. Extensions ....................................................83
23. Security Considerations .......................................84
23.1. Security Architecture ....................................84
23.2. Integrity ................................................85
23.3. Confidentiality ..........................................86
23.4. Interaction with External Routing Domains ................87
23.5. Mandatory Security Mechanisms ............................87
23.6. Key Management ...........................................88
24. IANA Considerations ...........................................90
24.1. Expert Review: Evaluation Guidelines .....................91
24.2. Message Types ............................................91
24.3. Message-Type-Specific TLV Type Registries ................91
24.4. Message TLV Types ........................................92
24.5. Address Block TLV Types ..................................93
24.6. NBR_ADDR_TYPE and MPR Values .............................96
25. Contributors ..................................................96
26. Acknowledgments ...............................................97
27. References ....................................................97
27.1. Normative References .....................................97
27.2. Informative References ...................................98
Appendix A. Constraints .........................................100
Appendix B. Example Algorithm for Calculating MPRs ..............104
B.1. Additional Notation ......................................104
B.2. MPR Selection Algorithm ................................. 105
Appendix C. Example Algorithm for Calculating the Routing Set ...105
C.1. Local Interfaces and Neighbors ...........................106
C.2. Add Neighbor Routers .....................................107
C.3. Add Remote Routers .......................................107
C.4. Add Neighbor Addresses ...................................108
C.5. Add Remote Routable Addresses ............................109
C.6. Add Attached Networks ....................................110
C.7. Add 2-Hop Neighbors ......................................110
Appendix D. TC Message Example ..................................111
Appendix E. Flow and Congestion Control .........................114
The Optimized Link State Routing Protocol version 2 (OLSRv2) is the successor to OLSR (version 1) as published in [RFC3626]. Compared to [RFC3626], OLSRv2 retains the same basic mechanisms and algorithms, enhanced by the ability to use a link metric other than hop count in the selection of shortest routes. OLSRv2 also uses a more flexible and efficient signaling framework and includes some simplification of the messages being exchanged.
最適化リンクステートルーティングプロトコルバージョン2（OLSRv2）は、[RFC3626]で公開されているOLSR（バージョン1）の後継です。 [RFC3626]と比較して、OLSRv2は同じ基本メカニズムとアルゴリズムを保持し、最短ルートの選択でホップカウント以外のリンクメトリックを使用する機能によって強化されています。 OLSRv2はまた、より柔軟で効率的なシグナリングフレームワークを使用し、交換されるメッセージの簡略化を含みます。
OLSRv2 is developed for Mobile Ad Hoc Networks (MANETs). It operates as a table-driven, proactive protocol, i.e., it exchanges topology information with other routers in the network regularly. OLSRv2 is an optimization of the classic link state routing protocol. Its key concept is that of multipoint relays (MPRs). Each router selects two sets of MPRs, each being a set of its neighbor routers that "cover" all of its symmetrically connected 2-hop neighbor routers. These two sets are "flooding MPRs" and "routing MPRs", which are used to achieve flooding reduction and topology reduction, respectively.
OLSRv2は、モバイルアドホックネットワーク（MANET）用に開発されています。テーブル駆動型のプロアクティブなプロトコルとして動作します。つまり、ネットワーク内の他のルーターと定期的にトポロジー情報を交換します。 OLSRv2は、従来のリンクステートルーティングプロトコルを最適化したものです。その主要な概念は、マルチポイントリレー（MPR）の概念です。各ルーターは2組のMPRを選択します。各MPRは、対称的に接続された2ホップの隣接ルーターをすべて「カバー」する隣接ルーターのセットです。これらの2つのセットは、「フラッディングMPR」と「ルーティングMPR」であり、それぞれフラッディングの削減とトポロジの削減を実現するために使用されます。
Flooding reduction is achieved by control traffic being flooded through the network using hop-by-hop forwarding, but with a router only needing to forward control traffic that is first received directly from one of the routers that have selected it as a flooding MPR (its "flooding MPR selectors"). This mechanism, denoted "MPR flooding", provides an efficient mechanism for information distribution within the MANET by reducing the number of transmissions required [MPR].
フラッディングの削減は、ホップバイホップ転送を使用してネットワークを介してフラッディングされる制御トラフィックによって達成されますが、ルーターでは、フラッディングMPRとして選択したルーターの1つから直接受信した制御トラフィックを直接転送するだけで済みます（そのルーター「フラッディングMPRセレクター」）。 「MPRフラッディング」と呼ばれるこのメカニズムは、必要な送信数を削減することにより、MANET内で情報を配信するための効率的なメカニズムを提供します[MPR]。
Topology reduction is achieved by assigning a special responsibility to routers selected as routing MPRs when declaring link state information. A sufficient requirement for OLSRv2 to provide shortest routes to all destinations is that routers declare link state information for their routing MPR selectors, if any. Routers that are not selected as routing MPRs need not send any link state information. Based on this reduced link state information, routing MPRs are used as intermediate routers in multi-hop routes.
トポロジーの削減は、リンク状態情報を宣言するときにルーティングMPRとして選択されたルーターに特別な責任を割り当てることで実現されます。 OLSRv2がすべての宛先への最短ルートを提供するための十分な要件は、ルーターがルーティングMPRセレクター（存在する場合）のリンク状態情報を宣言することです。ルーティングMPRとして選択されていないルーターは、リンク状態情報を送信する必要はありません。この削減されたリンク状態情報に基づいて、ルーティングMPRはマルチホップルートの中間ルーターとして使用されます。
Thus, the use of MPRs allows reduction of the number and the size of link state messages and reduction in the amount of link state information maintained in each router. When possible (in particular if using a hop count metric), the same routers may be picked as both flooding MPRs and routing MPRs.
したがって、MPRを使用すると、リンク状態メッセージの数とサイズを削減し、各ルーターで維持されるリンク状態情報の量を削減できます。可能であれば（特にホップカウントメトリックを使用している場合）、同じルーターがフラッディングMPRとルーティングMPRの両方として選択されることがあります。
A router selects both routing and flooding MPRs from among its one-hop neighbors connected by "symmetric", i.e., bidirectional, links. Therefore, selecting routes through routing MPRs avoids the problems associated with data packet transfer over unidirectional links (e.g., the problem of not getting link-layer acknowledgments at each hop, for link layers employing this technique).
ルータは、ルーティングとフラッディングの両方のMPRを、「対称」、つまり双方向リンクで接続された1ホップのネイバーから選択します。したがって、ルーティングMPRを介してルートを選択すると、単方向リンクを介したデータパケット転送に関連する問題（たとえば、この手法を使用するリンクレイヤーの場合、各ホップでリンクレイヤーの確認応答が取得されない問題）が回避されます。
OLSRv2 uses and extends the MANET Neighborhood Discovery Protocol (NHDP) defined in [RFC6130] and also uses the Generalized MANET Packet/Message Format [RFC5444], the TLVs specified in [RFC5497] and, optionally, message jitter as specified in [RFC5148]. These four other protocols and specifications were all originally created as part of OLSRv2 but have been specified separately for wider use.
OLSRv2は、[RFC6130]で定義されたMANET Neighborhood Discovery Protocol（NHDP）を使用および拡張し、一般化MANETパケット/メッセージフォーマット[RFC5444]、[RFC5497]で指定されたTLV、およびオプションで[RFC5148]で指定されたメッセージジッタを使用します。 。これら4つの他のプロトコルと仕様は、元々すべてOLSRv2の一部として作成されましたが、より広く使用するために個別に指定されています。
OLSRv2 makes no assumptions about the underlying link layer. OLSRv2, through its use of [RFC6130], may use link-layer information and notifications when available and applicable. In addition, OLSRv2 uses link metrics that may be derived from link layer or any other information. OLSRv2 does not specify the physical meaning of link metrics but specifies a means by which new types of link metrics may be specified in the future but used by OLSRv2 without modification.
OLSRv2は、基礎となるリンクレイヤーを想定していません。 OLSRv2は、[RFC6130]を使用することにより、利用可能かつ適用可能な場合、リンク層情報と通知を使用する場合があります。さらに、OLSRv2は、リンクレイヤーまたはその他の情報から導出されるリンクメトリックを使用します。 OLSRv2はリンクメトリックの物理的な意味を指定しませんが、新しいタイプのリンクメトリックが将来指定される可能性がある手段を指定しますが、OLSRv2によって変更なしで使用されます。
OLSRv2, like OLSR [RFC3626], inherits its concept of forwarding and relaying from the High Performance Radio Local Area Network (HIPERLAN) (a MAC-layer protocol), which is standardized by ETSI [HIPERLAN] [HIPERLAN2]. This document does not obsolete [RFC3626], which is left in place for further experimentation.
OLSRv2は、OLSR [RFC3626]と同様に、ETSI [HIPERLAN] [HIPERLAN2]によって標準化されている高性能無線ローカルエリアネットワーク（HIPERLAN）（MAC層プロトコル）から転送および中継の概念を継承しています。このドキュメントは廃止されていません[RFC3626]。今後の実験のために残されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこの文書の "は、[RFC2119]で説明されているように解釈されます。
All terms introduced in [RFC5444], including "packet", "Packet Header", "message", "Message Header", "Message Body", "Message Type", "message sequence number", "hop limit", "hop count", "Address Block",
[RFC5444]で導入されたすべての用語。「パケット」、「パケットヘッダー」、「メッセージ」、「メッセージヘッダー」、「メッセージ本文」、「メッセージタイプ」、「メッセージシーケンス番号」、「ホップリミット」、「ホップ」 count "、" Address Block "、
"TLV Block", "TLV", "Message TLV", "Address Block TLV", "type" (of TLV), "type extension" (of TLV), "value" (of TLV), "address", "address prefix", and "address object" are to be interpreted as described there.
「TLVブロック」、「TLV」、「メッセージTLV」、「アドレスブロックTLV」、「タイプ」（TLVの）、「タイプ拡張」（TLVの）、「値」（TLVの）、「アドレス」、「 「アドレスプレフィックス」および「アドレスオブジェクト」は、そこで説明されているように解釈されます。
All terms introduced in [RFC6130], including "interface", "MANET interface", "network address", "link", "symmetric link", "symmetric 1-hop neighbor", "symmetric 2-hop neighbor", "symmetric 1-hop neighborhood" "constant", "interface parameter", "router parameter", "Information Base", and "HELLO message" are to be interpreted as described there.
[インターフェイス]、[MANETインターフェイス]、[ネットワークアドレス]、[リンク]、[対称リンク]、[対称1ホップネイバー]、[対称2ホップネイバー]、[対称]など、[RFC6130]で導入されたすべての用語1ホップ近傍」、「定数」、「インターフェースパラメーター」、「ルーターパラメーター」、「情報ベース」、および「HELLOメッセージ」は、そこで説明されているとおりに解釈されます。
Additionally, this specification uses the following terminology:
さらに、この仕様では次の用語を使用しています。
Router: A MANET router that implements this protocol.
ルーター：このプロトコルを実装するMANETルーター。
OLSRv2 interface: A MANET interface running this protocol. A router running this protocol MUST have at least one OLSRv2 interface.
OLSRv2インターフェイス：このプロトコルを実行するMANETインターフェイス。このプロトコルを実行するルーターには、少なくとも1つのOLSRv2インターフェイスが必要です。
Routable address: A network address that may be used as the destination of a data packet. A router that implements this protocol will need to distinguish a routable address from a non-routable address by direct inspection of the network address, based on global-scope address allocations by IANA and/or administrative configuration (consistently across the MANET). Broadcast and multicast addresses, and addresses that are limited in scope to less than the entire MANET, MUST NOT be considered as routable addresses. Anycast addresses may be considered as routable addresses.
ルーティング可能なアドレス：データパケットの宛先として使用できるネットワークアドレス。このプロトコルを実装するルーターは、IANAによるグローバルスコープのアドレス割り当てや管理構成（MANET全体で一貫した）に基づいて、ネットワークアドレスを直接検査して、ルーティング可能なアドレスとルーティング不可能なアドレスを区別する必要があります。ブロードキャストアドレスとマルチキャストアドレス、および範囲がMANET全体未満に制限されているアドレスは、ルーティング可能なアドレスと見なしてはなりません。エニーキャストアドレスは、ルーティング可能なアドレスと見なされます。
Originator address: An address that is unique (within the MANET) to a router. A router MUST select an originator address; it MAY choose one of its interface addresses as its originator address; and it MAY select either a routable or non-routable address. A broadcast, multicast, or anycast address MUST NOT be chosen as an originator address. If the router selects a routable address, then it MUST be one that the router will accept as destination. An originator address MUST NOT have a prefix length, except when included in an Address Block where it MAY be associated with a prefix of maximum prefix length (e.g., if the originator address is an IPv6 address, it MUST have either no prefix length or have a prefix length of 128).
発信元アドレス：（MANET内で）ルーターに固有のアドレス。ルーターは発信元アドレスを選択する必要があります。発信元アドレスとしてインターフェースアドレスの1つを選択してもよい（MAY）。また、ルーティング可能なアドレスまたはルーティング不可能なアドレスのいずれかを選択する場合があります。ブロードキャスト、マルチキャスト、またはエニーキャストアドレスは、発信元アドレスとして選択してはなりません。ルーターがルーティング可能なアドレスを選択する場合、ルーターが宛先として受け入れるアドレスでなければなりません。発信者アドレスは、最大プレフィックス長のプレフィックスに関連付けることができるアドレスブロックに含まれている場合を除いて、プレフィックス長を持たないものとします（たとえば、発信者アドレスがIPv6アドレスの場合、プレフィックス長がないか、プレフィックス長は128）。
Message originator address: The originator address of the router that created a message, as deduced from that message by its recipient. For all messages used in this specification, including HELLO messages defined in [RFC6130], the recipient MUST be able to deduce an originator address. The message originator address will usually be included in the message as its <msg-orig-addr> element as defined in [RFC5444]. However, an exceptional case, which does not add a <msg-orig-addr> element to a HELLO message, may be used by a router that only has a single address.
メッセージの発信元アドレス：受信者がそのメッセージから推定した、メッセージを作成したルーターの発信元アドレス。 [RFC6130]で定義されているHELLOメッセージを含め、この仕様で使用されるすべてのメッセージについて、受信者は発信者アドレスを推測できなければなりません（MUST）。メッセージ発信者アドレスは通常、[RFC5444]で定義されているように、その<msg-orig-addr>要素としてメッセージに含まれます。ただし、HELLOメッセージに<msg-orig-addr>要素を追加しない例外的なケースは、単一のアドレスしか持たないルーターで使用される場合があります。
Willingness: A numerical value between WILL_NEVER and WILL_ALWAYS (both inclusive) that represents the router's willingness to be selected as an MPR. A router has separate willingness values to be a flooding MPR and a routing MPR.
意欲：MPRとして選択されるルーターの意欲を表す、WILL_NEVERとWILL_ALWAYS（両方を含む）の間の数値。ルーターには、フラッディングMPRとルーティングMPRになる独立した値があります。
Willing symmetric 1-hop neighbor: A symmetric 1-hop neighbor that has willingness not equal to WILL_NEVER.
ウィリング対称1ホップネイバー：ウィルネスがWILL_NEVERと等しくない対称1ホップネイバー。
Multipoint relay (MPR): A router, X, is an MPR for a router, Y, if router Y has indicated its selection of router X as an MPR in a recent HELLO message. Router X may be a flooding MPR for Y if it is indicated to participate in the flooding process of messages received from router Y, or it may be a routing MPR for Y if it is indicated to declare link state information for the link from X to Y. It may also be both at the same time.
マルチポイントリレー（MPR）：最近のHELLOメッセージでルーターXがMPRとしてルーターXの選択を示した場合、ルーターXはルーターYのMPRです。ルータXは、ルータYから受信したメッセージのフラッディングプロセスに参加するように指示されている場合、YのフラッディングMPRであるか、Xからへのリンクのリンク状態情報を宣言するように指示されている場合、YのルーティングMPRである可能性があります。 Y.同時に両方になることもあります。
MPR selector: A router, Y, is a flooding/routing MPR selector of router X if router Y has selected router X as a flooding/routing MPR.
MPRセレクター：ルーターYがルーターXをフラッディング/ルーティングMPRとして選択した場合、ルーターYはルーターXのフラッディング/ルーティングMPRセレクターです。
MPR flooding: The optimized MANET-wide information distribution mechanism, employed by this protocol, in which a message is relayed by only a reduced subset of the routers in the network. MPR flooding is the mechanism by which flooding reduction is achieved.
MPRフラッディング：このプロトコルで採用されている、最適化されたMANET全体の情報配信メカニズム。メッセージは、ネットワーク内の一部のルーターのサブセットのみによってリレーされます。 MPRフラッディングは、フラッディングを削減するメカニズムです。
EXPIRED: Indicates that a timer is set to a value clearly preceding the current time (e.g., current time - 1).
EXPIRED：タイマーが現在の時刻よりも明らかに前の値に設定されていることを示します（現在の時刻-1など）。
This specification employs the same notational conventions as [RFC5444] and [RFC6130].
この仕様は、[RFC5444]および[RFC6130]と同じ表記規則を採用しています。
This document specifies OLSRv2, a proactive routing protocol intended for use in Mobile Ad Hoc Networks (MANETs) [RFC2501]. The protocol's applicability is determined by its characteristics, which are that this protocol:
このドキュメントでは、モバイルアドホックネットワーク（MANET）[RFC2501]での使用を目的としたプロアクティブルーティングプロトコルであるOLSRv2を指定しています。プロトコルの適用性は、このプロトコルであるという特性によって決定されます。
o Is designed to work in networks with a dynamic topology and in which messages may be lost, such as due to collisions over wireless media.
o 動的トポロジーのあるネットワークで動作するように設計されており、ワイヤレスメディアでの衝突などによりメッセージが失われる可能性があります。
o Supports routers that each have one or more participating OLSRv2 interfaces, which will consist of some or all of its MANET interfaces using [RFC6130]. The set of a router's OLSRv2 interfaces, and the sets of its other MANET and non-MANET interfaces, may change over time. Each interface may have one or more network addresses (which may have prefix lengths), and these may also be dynamically changing.
o [RFC6130]を使用するMANETインターフェイスの一部またはすべてで構成される、1つ以上の参加OLSRv2インターフェイスを持つルーターをサポートします。ルーターのOLSRv2インターフェイスのセット、および他のMANETインターフェイスと非MANETインターフェイスのセットは、時間の経過とともに変化する可能性があります。各インターフェイスには1つ以上のネットワークアドレス（プレフィックス長がある場合があります）があり、これらも動的に変化する場合があります。
o Enables hop-by-hop routing, i.e., each router can use its local information provided by this protocol to route packets.
o ホップバイホップルーティングを有効にします。つまり、各ルーターは、このプロトコルによって提供されるローカル情報を使用してパケットをルーティングできます。
o Continuously maintains routes to all destinations in the network, i.e., routes are instantly available and data traffic is subject to no delays due to route discovery. Consequently, no data traffic buffering is required.
o ネットワーク内のすべての宛先へのルートを継続的に維持します。つまり、ルートは即座に利用可能であり、データトラフィックはルート検出による遅延の影響を受けません。したがって、データトラフィックのバッファリングは必要ありません。
o Supports routers that have non-OLSRv2 interfaces that may be local to a router or that can serve as gateways towards other networks.
o ルーターに対してローカルであるか、他のネットワークへのゲートウェイとして機能できる非OLSRv2インターフェイスを持つルーターをサポートします。
o Enables the use of bidirectional additive link metrics to use shortest distance routes (i.e., routes with smallest total of link metrics). Incoming link metric values are to be determined by a process outside this specification.
o 双方向の追加リンクメトリックを使用して、最短距離のルート（つまり、リンクメトリックの合計が最小のルート）を使用できるようにします。着信リンクメトリック値は、この仕様外のプロセスによって決定されます。
o Is optimized for large and dense networks; the larger and more dense a network, the more optimization can be achieved by using MPRs, compared to the classic link state algorithm [MPR].
o 大規模で高密度のネットワーク用に最適化されています。従来のリンクステートアルゴリズム[MPR]と比較して、ネットワークが大きく、密度が高いほど、MPRを使用してより多くの最適化を実現できます。
o Uses [RFC5444] as described in its "Intended Usage" appendix and by [RFC5498].
o [RFC5498]の付録「使用目的」に記載されている[RFC5444]を使用します。
o Allows "external" and "internal" extensibility (adding new Message Types and adding information to existing messages) as enabled by [RFC5444].
o [RFC5444]で有効になっている「外部」および「内部」の拡張性（新しいメッセージタイプの追加と既存のメッセージへの情報の追加）を許可します。
o Is designed to work in a completely distributed manner and does not depend on any central entity.
o 完全に分散した方法で機能するように設計されており、中心的なエンティティに依存しません。
The objectives of this protocol are for each router to:
このプロトコルの目的は、各ルーターが以下を行うことです。
o Identify all destinations in the network.
o ネットワーク内のすべての宛先を識別します。
o Identify a sufficient subset of links in the network, in order that shortest routes can be calculated to all available destinations.
o 利用可能なすべての宛先への最短ルートを計算できるように、ネットワーク内のリンクの十分なサブセットを特定します。
o Provide a Routing Set containing these shortest routes from this router to all destinations (routable addresses and local links).
o このルーターからすべての宛先（ルーティング可能なアドレスとローカルリンク）へのこれらの最短ルートを含むルーティングセットを提供します。
These objectives are achieved, for each router, by:
これらの目的は、ルーターごとに、次のことによって達成されます。
o Using NHDP [RFC6130] to identify symmetric 1-hop neighbors and symmetric 2-hop neighbors.
o NHDP [RFC6130]を使用して、対称1ホップネイバーと対称2ホップネイバーを識別する。
o Reporting its participation in OLSRv2, and its willingness to be a flooding MPR and to be a routing MPR, by extending the HELLO messages defined in [RFC6130] by the addition of an MPR_WILLING Message TLV. The router's "flooding willingness" indicates how willing it is to participate in MPR flooding. The router's "routing willingness" indicates how willing it is to be an intermediate router for routing. Note that a router is still able to be a routing source or destination, even if unwilling to perform either function.
o MPR_WILLINGメッセージTLVを追加して[RFC6130]で定義されているHELLOメッセージを拡張することにより、OLSRv2への参加、およびフラッディングMPRとルーティングMPRへの積極性を報告します。ルーターの「フラッディングの意欲」は、MPRフラッディングに参加する意欲を示します。ルーターの「ルーティングの意欲」は、ルーターがルーティングの中間ルーターになる意欲を示します。ルーターは、どちらの機能も実行したくない場合でも、ルーティングの送信元または宛先になることができることに注意してください。
o Extending the HELLO messages defined in [RFC6130] to allow the addition of directional link metrics to advertised links with other routers participating in OLSRv2 and to indicate which link metric type is being used by those routers. Both incoming and outgoing link metrics may be reported, the former determined by the advertising router.
o [RFC6130]で定義されているHELLOメッセージを拡張して、OLSRv2に参加している他のルーターとのアドバタイズされたリンクに方向性リンクメトリックを追加し、これらのルーターで使用されているリンクメトリックタイプを示す。着信と発信の両方のリンクメトリックが報告される場合があり、前者はアドバタイジングルータによって決定されます。
o Selecting flooding MPRs and routing MPRs from among its willing symmetric 1-hop neighbors such that, for each set of MPRs, all symmetric 2-hop neighbors are reachable either directly or via at least one selected MPR, using a path of appropriate minimum total metric for at least routing MPR selection. An analysis and examples of MPR selection algorithms are given in [MPR]; a suggested algorithm, appropriately adapted for each set of MPRs, is included in Appendix B of this specification. Note that it is not necessary for routers to use the same algorithm in order to interoperate in the same MANET, but each such algorithm must have the appropriate properties, described in Section 18.
o MPRのセットごとに、適切な最小合計メトリックのパスを使用して、すべての対称2ホップネイバーに直接または少なくとも1つの選択されたMPRを介して到達できるように、対称的な1ホップネイバーからフラッディングMPRとルーティングMPRを選択します。少なくともルーティングMPR選択。 MPR選択アルゴリズムの分析と例は、[MPR]に記載されています。 MPRの各セットに適切に適応された推奨アルゴリズムは、この仕様の付録Bに含まれています。ルーターが同じMANETで相互運用するために同じアルゴリズムを使用する必要はないことに注意してください。ただし、そのような各アルゴリズムには、セクション18で説明する適切なプロパティが必要です。
o Signaling its flooding MPR and routing MPR selections, by extending the HELLO messages defined in [RFC6130] to report this information by the addition of MPR Address Block TLV(s) associated with the appropriate network addresses.
o [RFC6130]で定義されているHELLOメッセージを拡張して、適切なネットワークアドレスに関連付けられたMPRアドレスブロックTLVを追加することにより、このフラッディングMPRとルーティングMPR選択をシグナリングし、この情報を報告します。
o Extracting its flooding MPR selectors and routing MPR selectors from received HELLO messages, using the included MPR Address Block TLV(s).
o 含まれているMPRアドレスブロックTLVを使用して、受信したHELLOメッセージからフラッディングMPRセレクターとルーティングMPRセレクターを抽出します。
o Defining a TC (Topology Control) Message Type using the message format specified in [RFC5444]. TC messages are used to periodically signal links between routing MPR selectors and itself throughout the MANET. This signaling includes suitable directional neighbor metrics (the best link metric in that direction between those routers).
o [RFC5444]で指定されたメッセージ形式を使用して、TC（トポロジコントロール）メッセージタイプを定義します。 TCメッセージは、ルーティングMPRセレクターとMANET全体との間のリンクを定期的に通知するために使用されます。このシグナリングには、適切な方向性ネイバーメトリック（それらのルータ間のその方向の最良のリンクメトリック）が含まれています。
o Allowing its TC messages, as well as HELLO messages, to be included in packets specified in [RFC5444], using the "manet" IP protocol or UDP port as specified in [RFC5498].
o [RFC5498]で指定された「manet」IPプロトコルまたはUDPポートを使用して、そのTCメッセージおよびHELLOメッセージを[RFC5444]で指定されたパケットに含めることを許可します。
o Diffusing TC messages by using a flooding reduction mechanism, denoted "MPR flooding"; only the flooding MPRs of a router will retransmit messages received from (i.e., originated or last relayed by) that router.
o 「MPRフラッディング」と呼ばれるフラッディング削減メカニズムを使用してTCメッセージを拡散する。ルータのフラッディングMPRのみが、そのルータから受信した（つまり、発信または最後にリレーされた）メッセージを再送信します。
Note that the indicated extensions to [RFC6130] are of forms permitted by that specification.
[RFC6130]に示された拡張は、その仕様で許可されている形式であることに注意してください。
This specification defines:
この仕様は以下を定義します：
o The requirement to use [RFC6130], its parameters, constants, HELLO messages, and Information Bases, each as extended in this specification.
o [RFC6130]を使用するための要件、そのパラメーター、定数、HELLOメッセージ、および情報ベース。それぞれ、この仕様で拡張されています。
o Two new Information Bases: the Topology Information Base and the Received Message Information Base.
o 2つの新しい情報ベース：トポロジ情報ベースと受信メッセージ情報ベース。
o TC messages, which are used for MANET wide signaling (using MPR flooding) of selected topology (link state) information.
o 選択したトポロジ（リンク状態）情報のMANETワイドシグナリング（MPRフラッディングを使用）に使用されるTCメッセージ。
o A requirement for each router to have an originator address to be included in, or deducible from, HELLO messages and TC messages.
o 各ルーターがHELLOメッセージとTCメッセージに含まれる、またはHELLOメッセージから推測できる発信元アドレスを持つ必要がある。
o The specification of new Message TLVs and Address Block TLVs that are used in HELLO messages and TC messages, including for reporting neighbor status, MPR selection, external gateways, link metrics, willingness to be an MPR, and content sequence numbers. Note that the generation of (incoming) link metric values is to be undertaken by a process outside this specification; this specification concerns only the distribution and use of those metrics.
o HELLOメッセージおよびTCメッセージで使用される新しいメッセージTLVおよびアドレスブロックTLVの仕様。これには、ネイバーステータス、MPR選択、外部ゲートウェイ、リンクメトリック、MPRへの意欲、およびコンテンツシーケンス番号の報告が含まれます。 （着信）リンクメトリック値の生成は、この仕様外のプロセスによって行われることに注意してください。この仕様は、それらのメトリックの分布と使用のみに関係します。
o The generation of TC messages from the appropriate information in the Information Bases.
o 情報ベースの適切な情報からのTCメッセージの生成。
o The updating of the Topology Information Base according to received TC messages.
o 受信したTCメッセージに基づくトポロジー情報ベースの更新。
o The MPR flooding mechanism, including the inclusion of message originator address and sequence number to manage duplicate messages, using information recorded in the Received Message Information Base.
o 受信メッセージ情報ベースに記録された情報を使用して、重複メッセージを管理するためのメッセージ発信者アドレスとシーケンス番号を含めることを含む、MPRフラッディングメカニズム。
o The response to other events, such as the expiration of information in the Information Bases.
o 情報ベースの情報の期限切れなど、他のイベントへの応答。
This 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.
このプロトコルは、リンク状態アルゴリズムの安定性を継承し、そのプロアクティブな性質により、必要なときにルートをすぐに利用できるという利点があります。
This protocol only interacts with IP through routing table management and the use of the sending IP address for IP datagrams containing messages used by this specification.
このプロトコルは、ルーティングテーブル管理と、この仕様で使用されるメッセージを含むIPデータグラムの送信IPアドレスの使用を通じてのみ、IPと対話します。
In order for a router to participate in a MANET using this protocol, it must have at least one, and possibly more, OLSRv2 interfaces. Each OLSRv2 interface:
ルータがこのプロトコルを使用してMANETに参加するには、少なくとも1つ、場合によってはそれ以上のOLSRv2インターフェイスが必要です。各OLSRv2インターフェイス：
o Is a MANET interface, as specified in [RFC6130]. In particular, it must be configured with one or more network addresses; these addresses must each be specific to this router and must include any address that will be used as the sending address of any IP packet sent on this OLSRv2 interface.
o [RFC6130]で指定されているMANETインターフェイスです。特に、1つ以上のネットワークアドレスで構成する必要があります。これらのアドレスはそれぞれこのルーターに固有である必要があり、このOLSRv2インターフェイスで送信されるIPパケットの送信アドレスとして使用されるアドレスを含める必要があります。
o Has a number of interface parameters, adding to those specified in [RFC6130].
o [RFC6130]で指定されているものに加えて、いくつかのインターフェイスパラメータがあります。
o Has an Interface Information Base, extending that specified in [RFC6130].
o [RFC6130]で指定されたものを拡張したインターフェイス情報ベースがあります。
o Generates and processes HELLO messages according to [RFC6130], extended as specified in Section 15.
o セクション15で指定されているように拡張された[RFC6130]に従ってHELLOメッセージを生成して処理します。
In addition to a set of OLSRv2 interfaces as described above, each router:
上記のOLSRv2インターフェイスのセットに加えて、各ルーターは次のことを行います。
o May have one or more non-OLSRv2 interfaces (which may include MANET interfaces and/or non-MANET interfaces) and/or local attached networks for which this router can accept IP packets. All routable addresses for which the router is to accept IP packets must be used as an (OLSRv2 or non-OLSRv2) interface network address or as an address of a local attached network of the router.
o 1つ以上の非OLSRv2インターフェイス（MANETインターフェイスや非MANETインターフェイスを含む場合があります）や、このルーターがIPパケットを受け入れることができるローカル接続ネットワークがある場合があります。ルーターがIPパケットを受け入れるすべてのルーティング可能なアドレスは、（OLSRv2または非OLSRv2）インターフェイスネットワークアドレスとして、またはルーターのローカル接続ネットワークのアドレスとして使用する必要があります。
o Has a number of router parameters, adding to those specified in [RFC6130].
o [RFC6130]で指定されているものに加えて、いくつかのルーターパラメーターがあります。
o Has a Local Information Base, extending that specified in [RFC6130], including selection of an originator address and recording any locally attached networks.
o [RFC6130]で指定されたものを拡張したローカル情報ベースがあり、発信者アドレスの選択やローカルに接続されたネットワークの記録が含まれます。
o Has a Neighbor Information Base, extending that specified in [RFC6130] to record MPR selection and advertisement information.
o [RFC6130]で指定されたネイバー情報ベースを拡張して、MPR選択およびアドバタイズメント情報を記録します。
o Has a Topology Information Base, recording information received in TC messages.
o トポロジー情報ベースがあり、TCメッセージで受信した情報を記録します。
o Has a Received Message Information Base, recording information about received messages to ensure that each TC message is only processed once, and forwarded at most once on each OLSRv2 interface, by a router.
o 受信メッセージ情報ベースがあり、受信メッセージに関する情報を記録して、各TCメッセージが1回だけ処理され、ルーターによって各OLSRv2インターフェイスで最大1回転送されるようにします。
o Generates, receives, and processes TC messages.
o TCメッセージを生成、受信、処理します。
Each router maintains the Information Bases described in the following sections. These are used for describing the protocol in this specification. An implementation of this protocol may maintain this information in the indicated form or in any other organization that offers access to this information. In particular, note that it is not necessary to remove Tuples from Sets at the exact time indicated, only to behave as if the Tuples were removed at that time.
各ルーターは、次のセクションで説明する情報ベースを保持しています。これらは、この仕様でプロトコルを説明するために使用されます。このプロトコルの実装は、指定された形式で、またはこの情報へのアクセスを提供する他の組織でこの情報を維持できます。特に、示された正確な時間にセットからタプルを削除する必要はなく、そのときにタプルが削除されたかのように動作するだけであることに注意してください。
The Local Information Base is specified in [RFC6130] and contains a router's local configuration. It is extended in this specification to also record an originator address and to include a router's: o Originator Set, containing addresses that were recently used as this router's originator address, that is used, together with the router's current originator address, to enable a router to recognize and discard control traffic that was originated by the router itself.
ローカル情報ベースは[RFC6130]で指定されており、ルーターのローカル構成が含まれています。この仕様では、発信元アドレスを記録し、ルーターのアドレスを含めるように拡張されています。o発信元セット。このルーターの発信元アドレスとして最近使用されたアドレスを含み、ルーターの現在の発信元アドレスと一緒に使用され、ルーターを有効にします。ルータ自体から発信された制御トラフィックを認識して破棄します。
o Local Attached Network Set, containing network addresses of networks to which this router can act as a gateway, that it advertises in its TC messages.
o このルーターがTCメッセージで通知するゲートウェイとして機能できるネットワークのネットワークアドレスを含むローカル接続ネットワークセット。
The Interface Information Base for each OLSRv2 interface is as specified in [RFC6130], extended to also record, in each Link Set, link metric values (incoming and outgoing) and flooding MPR selector information.
各OLSRv2インターフェイスのインターフェイス情報ベースは、[RFC6130]で指定されているとおり、各リンクセットにリンクメトリック値（着信および発信）とフラッディングMPRセレクター情報も記録するように拡張されています。
The Neighbor Information Base is specified in [RFC6130] and is extended to also record, in the Neighbor Tuple for each neighbor:
ネイバー情報ベースは[RFC6130]で指定されており、各ネイバーのネイバータプルに記録するように拡張されています。
o Its originator address.
o その発信元アドレス。
o Neighbor metric values, these being the minimum of the link metric values in the indicated direction for all symmetric 1-hop links with that neighbor.
o ネイバーメトリック値。これらは、そのネイバーとのすべての対称1ホップリンクの示された方向のリンクメトリック値の最小値です。
o Its willingness to be a flooding MPR and to be a routing MPR.
o フラッディングMPRであり、ルーティングMPRであるというその意欲。
o Whether it has been selected by this router as a flooding MPR or as a routing MPR and whether it is a routing MPR selector of this router. (Whether it is a flooding MPR selector of this neighbor is recorded in the Interface Information Base.)
o このルーターによってフラッディングMPRとして選択されたか、ルーティングMPRとして選択されたか、およびこのルーターのルーティングMPRセレクターであるかどうか。 （このネイバーのフラッディングMPRセレクタであるかどうかは、インターフェイス情報ベースに記録されます）。
o Whether it is to be advertised in TC messages sent by this router.
o このルータによって送信されたTCメッセージでアドバタイズされるかどうか。
The Topology Information Base in each router contains:
各ルーターのトポロジ情報ベースには、次のものが含まれています。
o An Advertising Remote Router Set, recording each remote router from which TC messages have been received. This is used in order to determine if a received TC message contains fresh or outdated information; a received TC message is ignored in the latter case.
o TCメッセージが受信された各リモートルーターを記録する、アドバタイズリモートルーターセット。これは、受信したTCメッセージに最新の情報または古い情報が含まれているかどうかを判断するために使用されます。後者の場合、受信したTCメッセージは無視されます。
o A Router Topology Set, recording links between routers in the MANET, as described by received TC messages.
o 受信したTCメッセージによって記述される、MANET内のルーター間のリンクを記録するルータートポロジセット。
o A Routable Address Topology Set, recording routable addresses in the MANET (available as IP packet destinations) and from which remote router these routable addresses can be directly reached (i.e., in a single IP hop from that remote router), as reported by received TC messages.
o ルーティング可能なアドレストポロジーセット。MANETのルーティング可能なアドレス（IPパケットの宛先として利用可能）を記録し、受信したTCによって報告されるように、これらのルーティング可能なアドレスに直接到達できるリモートルーター（つまり、そのリモートルーターからの単一のIPホップ）。メッセージ。
o An Attached Network Set, recording networks to which a remote router has advertised that it may act as a gateway. These networks may be reached in one or more IP hops from that remote router.
o リモートルーターがゲートウェイとして機能する可能性があることをアドバタイズしたネットワークを記録した接続ネットワークセット。これらのネットワークは、そのリモートルータから1つ以上のIPホップで到達する可能性があります。
o A Routing Set, recording routes from this router to all available destinations. The IP routing table is to be updated using this Routing Set. (A router may choose to use any or all destination network addresses in the Routing Set to update the IP routing table. This selection is outside the scope of this specification.)
o このルーターからすべての利用可能な宛先へのルートを記録するルーティングセット。 IPルーティングテーブルは、このルーティングセットを使用して更新されます。 （ルーターは、ルーティングセット内の一部またはすべての宛先ネットワークアドレスを使用してIPルーティングテーブルを更新することを選択できます。この選択は、この仕様の範囲外です。）
The purpose of the Topology Information Base is to record information used, in addition to that in the Local Information Base, the Interface Information Bases, and the Neighbor Information Base, to construct the Routing Set (which is also included in the Topology Information Base).
トポロジ情報ベースの目的は、ローカル情報ベース、インターフェース情報ベース、およびネイバー情報ベースの情報に加えて、ルーティングセット（トポロジ情報ベースにも含まれています）を構築するために使用された情報を記録することです。 。
This specification describes the calculation of the Routing Set based on a Topology Graph constructed in two phases. First, a "backbone" graph representing the routers in the MANET, and the connectivity between them, is constructed from the Local Information Base, the Neighbor Information Base, and the Router Topology Set. Second, this graph is "decorated" with additional destination network addresses using the Local Information Base, the Routable Address Topology Set, and the Attached Network Set.
この仕様は、2つのフェーズで構築されたトポロジグラフに基づくルーティングセットの計算について説明しています。まず、MANET内のルーターとそれらの間の接続を表す「バックボーン」グラフが、ローカル情報ベース、ネイバー情報ベース、およびルータートポロジーセットから構築されます。次に、このグラフは、ローカル情報ベース、ルーティング可能なアドレストポロジセット、および接続されたネットワークセットを使用して、追加の宛先ネットワークアドレスで「装飾」されています。
The Topology Graph does not need to be recorded in the Topology Information Base; it can either be constructed as required when the Routing Set is to be changed or need not be explicitly constructed (as illustrated in Appendix C). An implementation may, however, construct and retain the Topology Graph if preferred.
トポロジグラフをトポロジ情報ベースに記録する必要はありません。ルーティングセットを変更する場合、必要に応じて作成することも、明示的に作成する必要がない場合もあります（付録Cを参照）。ただし、実装によっては、必要に応じてトポロジグラフを作成して保持できます。
The Received Message Information Base in each router contains:
各ルーターの受信メッセージ情報ベースには以下が含まれます。
o A Received Set for each OLSRv2 interface, describing TC messages received by this router on that OLSRv2 interface.
o 各OLSRv2インターフェイスの受信セット。このOLSRv2インターフェイスでこのルーターが受信したTCメッセージを記述します。
o A Processed Set, describing TC messages processed by this router.
o このルーターによって処理されたTCメッセージを記述するプロセスセット。
o A Forwarded Set, describing TC messages forwarded by this router.
o このルーターによって転送されたTCメッセージを記述する転送セット。
The Received Message Information Base serves the MPR flooding mechanism by ensuring that received messages are forwarded at most once by a router and also ensures that received messages are processed exactly once by a router. The Received Message Information Base may also record information about other Message Types that use the MPR flooding mechanism.
受信メッセージ情報ベースは、受信メッセージがルーターによって最大で1回転送されることを保証することによってMPRフラッディングメカニズムを提供し、受信メッセージがルーターによって正確に1回処理されることを保証します。受信メッセージ情報ベースは、MPRフラッディングメカニズムを使用する他のメッセージタイプに関する情報も記録する場合があります。
This protocol generates and processes HELLO messages according to [RFC6130]. HELLO messages transmitted on OLSRv2 interfaces are extended according to Section 15 of this specification to include an originator address, link metrics, and MPR selection information.
このプロトコルは、[RFC6130]に従ってHELLOメッセージを生成して処理します。 OLSRv2インターフェイスで送信されるHELLOメッセージは、この仕様のセクション15に従って拡張され、発信元アドレス、リンクメトリック、およびMPR選択情報が含まれます。
This specification defines a single Message Type, the TC message. TC messages are sent by their originating router proactively, at a regular interval, on all OLSRv2 interfaces. This interval may be fixed or dynamic, for example, it may be backed off due to congestion or network stability. TC messages may also be sent as a response to a change in the router itself, or its advertised symmetric 1-hop neighborhood, for example, on first being selected as a routing MPR.
この仕様では、TCメッセージという単一のメッセージタイプを定義しています。 TCメッセージは、すべてのOLSRv2インターフェイスで、発信元ルーターから定期的に定期的に送信されます。この間隔は、固定または動的である場合があります。たとえば、輻輳またはネットワークの安定性のために、バックオフされる場合があります。 TCメッセージは、ルーター自体の変更に対する応答として、または最初にルーティングMPRとして選択されたときに、そのアドバタイズされた対称1ホップ近隣として送信することもできます。
Because TC messages are sent periodically, this protocol is tolerant of unreliable transmissions of TC messages. Message losses may occur more frequently in wireless networks due to collisions or other transmission problems. This protocol may use "jitter", randomized adjustments to message transmission times, to reduce the incidence of collisions, as specified in [RFC5148].
TCメッセージは定期的に送信されるため、このプロトコルはTCメッセージの信頼できない送信を許容します。メッセージの損失は、衝突やその他の送信の問題が原因で、ワイヤレスネットワークでより頻繁に発生する可能性があります。このプロトコルは、[RFC5148]で指定されているように、衝突の発生を減らすために、メッセージの送信時間をランダムに調整する「ジッター」を使用する場合があります。
This protocol is tolerant of out-of-sequence delivery of TC messages due to in-transit message reordering. Each router maintains an Advertised Neighbor Sequence Number (ANSN) that is incremented when its recorded neighbor information that is to be included in its TC messages changes. This ANSN is included in the router's TC messages. The recipient of a TC message can use this included ANSN to identify which of the information it has received is most recent, even if messages have been reordered while in transit. Only the most recent information received is used; older information received later is discarded.
このプロトコルは、転送中のメッセージの並べ替えによるTCメッセージの順序外の配信を許容します。各ルータは、TCメッセージに含まれる記録されたネイバー情報が変更されると増分されるAdvertised Neighbor Sequence Number（ANSN）を維持します。このANSNは、ルーターのTCメッセージに含まれています。 TCメッセージの受信者は、含まれているこのANSNを使用して、メッセージが転送中に並べ替えられた場合でも、受信した情報のうち最新のものを特定できます。受信した最新の情報のみが使用されます。後で受信した古い情報は破棄されます。
TC messages may be "complete" or "incomplete". A complete TC message advertises all of the originating router's routing MPR selectors; it may also advertise other symmetric 1-hop neighbors. Complete TC messages are generated periodically (and also, optionally, in response to symmetric 1-hop neighborhood changes). Incomplete TC messages may be used to report additions to advertised information, without repeating unchanged information.
TCメッセージは「完全」または「不完全」の場合があります。完全なTCメッセージは、発信元ルーターのルーティングMPRセレクターのすべてを通知します。また、他の対称1ホップネイバーをアドバタイズする場合もあります。完全なTCメッセージが定期的に生成されます（また、オプションで、対称1ホップ近隣変更に応答して）。不完全なTCメッセージを使用して、変更されていない情報を繰り返すことなく、アドバタイズされた情報への追加を報告できます。
TC messages, and HELLO messages as extended by this specification, define (by inclusion or by deduction when having a single address) an originator address for the router that created the message. A TC message reports both the originator addresses and routable addresses of its advertised neighbors, distinguishing the two using an Address Block TLV (an address may be both routable and an originator address). TC messages also report the originator's locally attached networks.
TCメッセージ、およびこの仕様によって拡張されたHELLOメッセージは、メッセージを作成したルーターの発信元アドレスを定義します（単一のアドレスを持つ場合は含めるか、または差し引くことによって）。 TCメッセージは、アドバタイズされたネイバーの発信元アドレスとルーティング可能なアドレスの両方を報告し、アドレスブロックTLVを使用して2つを区別します（アドレスはルーティング可能アドレスと発信元アドレスの両方である場合があります）。 TCメッセージは、発信者のローカル接続ネットワークも報告します。
TC messages are MPR flooded throughout the MANET. A router retransmits a TC message received on an OLSRv2 interface if and only if the message did not originate at this router and has not been previously forwarded by this router, this is the first time the message has been received on this OLSRv2 interface, and the message is received from (i.e., originated from or was last relayed by) one of this router's flooding MPR selectors.
TCメッセージはMANET全体にMPRフラッディングされます。メッセージがこのルーターから発信されておらず、このルーターによって以前に転送されていない場合にのみ、ルーターはOLSRv2インターフェイスで受信したTCメッセージを再送信します。これは、このOLSRv2インターフェイスでメッセージを受信したのが初めてであり、メッセージは、このルーターのフラッディングMPRセレクターの1つから受信された（つまり、発信された、または最後にリレーされた）ものです。
Some TC messages may be MPR flooded over only part of the network, e.g., allowing a router to ensure that nearer routers are kept more up to date than distant routers, such as is used in Fisheye State Routing [FSR] and Fuzzy Sighted Link State routing [FSLS]. This is enabled using [RFC5497].
一部のTCメッセージはネットワークの一部のみでMPRフラッディングされる可能性があります。たとえば、Fisheye State Routing [FSR]やFuzzy Sighted Link Stateで使用されているように、ルーターが近くのルーターを遠くのルーターよりも最新に保つことができます。ルーティング[FSLS]。これは[RFC5497]を使用して有効になります。
TC messages include outgoing neighbor metrics that will be used in the selection of routes.
TCメッセージには、ルートの選択に使用される発信ネイバーメトリックが含まれます。
OLSRv1 [RFC3626] created minimum hop routes to destinations. However, in many, if not most, circumstances, better routes (in terms of quality of service for end users) can be created by use of link metrics.
OLSRv1 [RFC3626]は、宛先への最小ホップルートを作成しました。ただし、ほとんどではありませんが、多くの状況では、リンクメトリックを使用することで（エンドユーザーのサービス品質の観点から）より良いルートを作成できます。
OLSRv2, as defined in this specification, supports metric-based routing, i.e., it allows links to each have a chosen metric. Link metrics as defined in OLSRv2 are additive, and the routes that are to be created are those with the minimum sum of the link metrics along that route.
この仕様で定義されているOLSRv2は、メトリックベースのルーティングをサポートします。つまり、それぞれにリンクが選択されたメトリックを持つことを許可します。 OLSRv2で定義されているリンクメトリックは付加的であり、作成されるルートは、そのルートに沿ったリンクメトリックの合計が最小のルートです。
Link metrics are defined to be directional; the link metric from one router to another may be different from that on the reverse link. The link metric is assessed at the receiver, as on a (typically) wireless link, that is the better informed as to link information. Both incoming and outgoing link information is used by OLSRv2; the distinctions in this specification must be clearly followed.
リンクメトリックは方向性を持つように定義されています。あるルータから別のルータへのリンクメトリックは、逆方向リンクのそれとは異なる場合があります。リンクメトリックは、（通常は）ワイヤレスリンクの場合と同様に、受信側で評価されます。これは、リンク情報に関してよりよく通知されます。着信リンク情報と発信リンク情報の両方がOLSRv2によって使用されます。この仕様の違いは明確に従う必要があります。
This specification also defines both incoming and outgoing neighbor metrics for each symmetric 1-hop neighbor, these being the minimum value of the link metrics in the same direction for all symmetric links with that neighbor. Note that this means that all neighbor metric values are link metric values and that specification of, for example, link metric value encoding also includes encoding of neighbor metric values.
この仕様では、各対称1ホップネイバーの着信および発信ネイバーメトリックも定義します。これらは、そのネイバーとのすべての対称リンクの同じ方向のリンクメトリックの最小値です。これは、すべてのネイバーメトリック値がリンクメトリック値であり、たとえば、リンクメトリック値エンコーディングの指定にはネイバーメトリック値のエンコーディングも含まれることを意味することに注意してください。
This specification does not define the nature of the link metric. However, this specification allows, through use of the type extension of a defined Address Block TLV, for link metrics with specific meanings to be defined and either allocated by IANA or privately used. Each HELLO or TC message carrying link (or neighbor) metrics thus indicates which link metric information it is carrying, allowing routers to determine if they can interoperate. If link metrics require additional signaling to determine their values, whether in HELLO messages or otherwise, then this is permitted but is outside the scope of this specification.
この仕様は、リンクメトリックの性質を定義していません。ただし、この仕様では、定義されたアドレスブロックTLVのタイプ拡張を使用して、特定の意味を持つリンクメトリックを定義し、IANAによって割り当てられるか、個人的に使用することができます。したがって、リンク（またはネイバー）メトリックを運ぶ各HELLOまたはTCメッセージは、それが運ぶリンクメトリック情報を示し、ルーターが相互運用できるかどうかをルーターが判断できるようにします。 HELLOメッセージであるかどうかにかかわらず、リンクメトリックが値を決定するために追加のシグナリングを必要とする場合、これは許可されますが、この仕様の範囲外です。
Careful consideration should be given to how to use link metrics. In particular, it is advisable to not simply default to use of all links with equal metrics (i.e., hop count) for routing without careful consideration of whether that is appropriate or not.
リンクメトリックの使用方法を慎重に検討する必要があります。特に、適切なメトリックであるかどうかを慎重に考慮せずに、ルーティングに同じメトリック（つまり、ホップカウント）を持つすべてのリンクをデフォルトで使用するのではなく、単に推奨します。
This specification uses two sets of MPRs: flooding MPRs and routing MPRs. These are selected separately, because:
この仕様では、フラッディングMPRとルーティングMPRの2セットのMPRを使用します。次の理由により、これらは別々に選択されます。
o Flooding MPRs may use metrics; routing MPRs must use metrics.
o フラッディングMPRはメトリックを使用する場合があります。ルーティングMPRはメトリックを使用する必要があります。
o When flooding MPRs use metrics, these are outgoing link metrics; routing MPRs use incoming neighbor metrics.
o フラッディングMPRがメトリックを使用する場合、これらは発信リンクメトリックです。ルーティングMPRは、着信ネイバーメトリックを使用します。
o Flooding MPRs must be selected per OLSRv2 interface; routing MPRs need not be selected per OLSRv2 interface.
o フラッディングMPRは、OLSRv2インターフェイスごとに選択する必要があります。ルーティングMPRは、OLSRv2インターフェイスごとに選択する必要はありません。
The purpose of the Routing Set is to determine and record routes (local interface network address and next-hop interface network address) to all possible routable addresses advertised by this protocol as well as all destinations that are local, i.e., within one hop, to the router (whether using routable addresses or not). Only symmetric links are used in such routes.
ルーティングセットの目的は、このプロトコルによってアドバタイズされるすべての可能なルーティング可能なアドレスへのルート（ローカルインターフェースネットワークアドレスおよびネクストホップインターフェースネットワークアドレス）を決定し、記録することです。ルーター（ルーティング可能なアドレスを使用するかどうかにかかわらず）。このようなルートでは対称リンクのみが使用されます。
It is intended that the Routing Set can be used for IP packet routing, by using its contents to update the IP routing table. That update, and whether any Routing Tuples are not used when updating the IP routing table, is outside the scope of this specification.
ルーティングセットは、その内容を使用してIPルーティングテーブルを更新することにより、IPパケットルーティングに使用できることを目的としています。その更新、およびIPルーティングテーブルの更新時にルーティングタプルが使用されないかどうかは、この仕様の範囲外です。
The signaling in this specification has been designed so that a "backbone" Topology Graph of routers, each identified by its originator address, with at most one direct connection between any pair of routers, can be constructed (from the Neighbor Set and the Router Topology Set) using a suitable minimum path length algorithm. This Topology Graph can then have other network addresses (routable or of symmetric 1-hop neighbors) added to it (using the Interface Information Bases, the Routable Address Topology Set, and the Attached Network Set).
この仕様のシグナリングは、ルーターの「バックボーン」トポロジグラフが作成されるように設計されており、それぞれが発信元アドレスによって識別され、ルーターのペア間で最大1つの直接接続を使用して（隣接セットとルータートポロジから）セット）適切な最小パス長アルゴリズムを使用します。このトポロジグラフには、他のネットワークアドレス（ルーティング可能または対称1ホップネイバー）を追加できます（インターフェイス情報ベース、ルーティング可能なアドレストポロジセット、および接続されたネットワークセットを使用）。
The parameters and constants used in this specification are those defined in [RFC6130] plus those defined in this section. The separation in [RFC6130] into interface parameters, router parameters, and constants is also used in this specification.
この仕様で使用されるパラメータと定数は、[RFC6130]で定義されたものと、このセクションで定義されたものです。 [RFC6130]でのインターフェイスパラメータ、ルータパラメータ、および定数への分離は、この仕様でも使用されます。
Similarly to the parameters in [RFC6130], parameters defined in this specification MAY be changed dynamically by a router and need not be the same on different routers, even in the same MANET, or, for interface parameters, on different interfaces of the same router.
[RFC6130]のパラメーターと同様に、この仕様で定義されているパラメーターは、ルーターによって動的に変更される場合があり、同じルーターでも、同じMANETでも、同じルーターの異なるインターフェースでも同じである必要はありません。 。
This protocol specifies TC messages, which are included in packets as defined by [RFC5444]. These packets MUST be sent either using the "manet" protocol number or the "manet" UDP well-known port number, as specified in [RFC5498].
このプロトコルは、[RFC5444]で定義されているようにパケットに含まれるTCメッセージを指定します。これらのパケットは、[RFC5498]で指定されているように、「manet」プロトコル番号または「manet」UDPウェルノウンポート番号を使用して送信する必要があります。
TC messages and HELLO messages [RFC6130] MUST, in a given MANET, either both use IP or both use UDP, in order for it to be possible to combine messages of both protocols into the same [RFC5444] packet for transmission.
TCメッセージとHELLOメッセージ[RFC6130]は、両方のプロトコルのメッセージを同じ[RFC5444]パケットに結合して送信できるようにするために、特定のMANETで両方ともIPを使用するか、両方ともUDPを使用する必要があります。
This protocol specifies TC messages, which are included in packets as defined by [RFC5444]. These packets MAY be transmitted using the Link-Local multicast address "LL-MANET-Routers", as specified in [RFC5498].
このプロトコルは、[RFC5444]で定義されているようにパケットに含まれるTCメッセージを指定します。これらのパケットは、[RFC5498]で指定されているように、リンクローカルマルチキャストアドレス "LL-MANET-Routers"を使用して送信される場合があります。
A single additional interface parameter is specified for OLSRv2 interfaces only.
単一の追加のインターフェイスパラメータは、OLSRv2インターフェイスに対してのみ指定されます。
The following parameter manages the validity time of recorded received message information:
次のパラメータは、記録された受信メッセージ情報の有効期間を管理します。
RX_HOLD_TIME: The period after receipt of a message by the appropriate OLSRv2 interface of this router for which that information is recorded, in order that the message is recognized as having been previously received on this OLSRv2 interface.
RX_HOLD_TIME：メッセージがこのOLSRv2インターフェイスで以前に受信されたことが認識されるために、その情報が記録されているこのルーターの適切なOLSRv2インターフェイスがメッセージを受信してからの期間。
The following constraints apply to this parameter:
このパラメーターには次の制約が適用されます。
o RX_HOLD_TIME > 0
o RX_HOLD_TIME> 0
o RX_HOLD_TIME SHOULD be greater than the maximum difference in time that a message may take to traverse the MANET, taking into account any message forwarding jitter as well as propagation, queuing, and processing delays.
o RX_HOLD_TIMEは、メッセージ転送ジッター、伝播、キューイング、および処理遅延を考慮に入れて、メッセージがMANETを通過するのにかかる時間の最大差よりも大きい必要があります（SHOULD）。
The following router parameters are specified for routers.
ルーターには、次のルーターパラメーターが指定されています。
The following router parameter manages the time for which local information is retained: O_HOLD_TIME: The time for which a recently used and replaced originator address is used to recognize the router's own messages.
次のルーターパラメータは、ローカル情報が保持される時間を管理します。O_HOLD_TIME：最近使用されて置き換えられた発信元アドレスがルーター自身のメッセージを認識するために使用される時間。
The following constraint applies to this parameter:
このパラメーターには次の制約が適用されます。
o O_HOLD_TIME > 0
o O_HOLD_TIME> 0
All routes found using this specification use a single link metric type that is specified by the router parameter LINK_METRIC_TYPE, which may take any value from 0 to 255, both inclusive.
この仕様を使用して見つかったすべてのルートは、ルーターパラメーターLINK_METRIC_TYPEで指定された単一のリンクメトリックタイプを使用します。これは、0から255までの任意の値を取ることができます。
The following parameters regulate TC message transmissions by a router. TC messages are usually sent periodically but MAY also be sent in response to changes in the router's Neighbor Set and/or Local Attached Network Set. In a highly dynamic network, and with a larger value of the parameter TC_INTERVAL and a smaller value of the parameter TC_MIN_INTERVAL, TC messages MAY be transmitted more often in response to changes than periodically. However, because a router has no knowledge of, for example, routers remote to it (i.e., beyond two hops away) joining the network, TC messages MUST NOT be sent purely responsively.
以下のパラメーターは、ルーターによるTCメッセージの送信を規制します。 TCメッセージは通常定期的に送信されますが、ルーターのネイバーセットやローカル接続ネットワークセットの変更に応じて送信される場合もあります。非常に動的なネットワークでは、パラメーターTC_INTERVALの値が大きく、パラメーターTC_MIN_INTERVALの値が小さいため、TCメッセージは、定期的によりも頻繁に変更に応じて送信される場合があります。ただし、ルーターは、ネットワークに参加しているルーター（たとえば、2ホップ以上離れている）にリモートのルーターを認識していないため、TCメッセージを純粋に応答して送信してはなりません（MUST NOT）。
TC_INTERVAL: The maximum time between the transmission of two successive TC messages by this router. When no TC messages are sent in response to local network changes (by design or because the local network is not changing), then TC messages MUST be sent at a regular interval TC_INTERVAL, possibly modified by jitter, as specified in [RFC5148].
TC_INTERVAL：このルーターによる2つの連続したTCメッセージの送信間の最大時間。ローカルネットワークの変更（設計上またはローカルネットワークが変更されていないため）に応答してTCメッセージが送信されない場合、TCメッセージは、[RFC5148]で指定されているように、ジッタによって変更される可能性のある定期的な間隔TC_INTERVALで送信する必要があります。
TC_MIN_INTERVAL: The minimum interval between transmission of two successive TC messages by this router. (This minimum interval MAY be modified by jitter, as specified in [RFC5148].)
TC_MIN_INTERVAL：このルーターによる2つの連続したTCメッセージの送信間の最小間隔。 （この最小間隔は、[RFC5148]で指定されているように、ジッターによって変更される場合があります。）
The following constraints apply to these parameters:
これらのパラメーターには、次の制約が適用されます。
o TC_INTERVAL > 0
o TC_INTERVAL> 0
o 0 <= TC_MIN_INTERVAL <= TC_INTERVAL o If TLVs with Type = INTERVAL_TIME, as defined in [RFC5497], are included in TC messages, then TC_INTERVAL MUST be representable by way of the exponent-mantissa notation described in Section 5 of [RFC5497].
o 0 <= TC_MIN_INTERVAL <= TC_INTERVAL o Type = INTERVAL_TIMEのTLVが[RFC5497]で定義されているようにTCメッセージに含まれている場合、TC_INTERVALは、[RFC5497]のセクション5で説明されている指数仮数表記法で表現できる必要があります。 。
The following parameters manage the validity time of information advertised in TC messages:
次のパラメータは、TCメッセージでアドバタイズされる情報の有効期間を管理します。
T_HOLD_TIME: Used as the minimum value in the TLV with Type = VALIDITY_TIME included in all TC messages sent by this router. If a single value of parameter TC_HOP_LIMIT (see Section 5.4.7) is used, then this will be the only value in that TLV.
T_HOLD_TIME：このルーターが送信するすべてのTCメッセージに含まれるType = VALIDITY_TIMEのTLVの最小値として使用されます。パラメータTC_HOP_LIMIT（セクション5.4.7を参照）の単一の値が使用される場合、これがそのTLVの唯一の値になります。
A_HOLD_TIME: The period during which TC messages are sent after they no longer have any advertised information to report but are sent in order to accelerate outdated information removal by other routers.
A_HOLD_TIME：報告するアドバタイズされた情報がなくなった後、他のルーターによる古い情報の削除を加速するために送信された後、TCメッセージが送信される期間。
The following constraints apply to these parameters:
これらのパラメーターには、次の制約が適用されます。
o T_HOLD_TIME > 0
o T_HOLD_TIME> 0
o A_HOLD_TIME >= 0
o A_HOLD_TIME> = 0
o T_HOLD_TIME >= TC_INTERVAL
o T_HOLD_TIME> = TC_INTERVAL
o If TC messages can be lost, then both T_HOLD_TIME and A_HOLD_TIME SHOULD be significantly greater than TC_INTERVAL; a value >= 3 x TC_INTERVAL is RECOMMENDED.
o TCメッセージが失われる可能性がある場合、T_HOLD_TIMEとA_HOLD_TIMEの両方がTC_INTERVALより大幅に大きい必要があります（SHOULD）。値> = 3 x TC_INTERVALが推奨されます。
o T_HOLD_TIME MUST be representable by way of the exponent-mantissa notation described in Section 5 of [RFC5497].
o T_HOLD_TIMEは、[RFC5497]のセクション5で説明されている指数仮数表記法で表現できる必要があります。
The following parameters manage the processing and forwarding validity time of recorded message information:
次のパラメータは、録音されたメッセージ情報の処理および転送の有効期間を管理します。
P_HOLD_TIME: The period after receipt of a message that is processed by this router for which that information is recorded, in order that the message is not processed again if received again.
P_HOLD_TIME：このルーターによって処理されるメッセージを受信してから、その情報が記録されている期間。メッセージが再度受信された場合、メッセージは再度処理されません。
F_HOLD_TIME: The period after receipt of a message that is forwarded by this router for which that information is recorded, in order that the message is not forwarded again if received again.
F_HOLD_TIME：このルーターによって転送されたメッセージの受信後、その情報が記録されている期間。メッセージが再度受信された場合に、メッセージが再度転送されないようにします。
The following constraints apply to these parameters:
これらのパラメーターには、次の制約が適用されます。
o P_HOLD_TIME > 0
o P_HOLD_TIME> 0
o F_HOLD_TIME > 0
o F_HOLD_TIME> 0
o Both of these parameters SHOULD be greater than the maximum difference in time that a message may take to traverse the MANET, taking into account any message forwarding jitter as well as propagation, queuing, and processing delays.
o これらのパラメーターは両方とも、メッセージ転送ジッター、伝播、キューイング、および処理遅延を考慮に入れて、メッセージがMANETを通過するのにかかる時間の最大差よりも大きい必要があります（SHOULD）。
If jitter, as defined in [RFC5148], is used, then the governing jitter parameters are as follows:
[RFC5148]で定義されているジッターを使用する場合、管理ジッターパラメーターは次のようになります。
TP_MAXJITTER: Represents the value of MAXJITTER used in [RFC5148] for periodically generated TC messages sent by this router.
TP_MAXJITTER：このルーターによって送信される定期的に生成されるTCメッセージの[RFC5148]で使用されるMAXJITTERの値を表します。
TT_MAXJITTER: Represents the value of MAXJITTER used in [RFC5148] for externally triggered TC messages sent by this router.
TT_MAXJITTER：[RFC5148]でこのルーターによって送信された外部トリガーTCメッセージに使用されるMAXJITTERの値を表します。
F_MAXJITTER: Represents the default value of MAXJITTER used in [RFC5148] for messages forwarded by this router. However, before using F_MAXJITTER, a router MAY attempt to deduce a more appropriate value of MAXJITTER, for example, based on any TLVs with Type = INTERVAL_TIME or Type = VALIDITY_TIME contained in the message to be forwarded.
F_MAXJITTER：このルーターによって転送されるメッセージの[RFC5148]で使用されるMAXJITTERのデフォルト値を表します。ただし、F_MAXJITTERを使用する前に、ルーターは、たとえば、転送されるメッセージに含まれるType = INTERVAL_TIMEまたはType = VALIDITY_TIMEのTLVに基づいて、MAXJITTERのより適切な値を推測しようとします（MAY）。
For constraints on these parameters, see [RFC5148].
これらのパラメータの制約については、[RFC5148]を参照してください。
The parameter TC_HOP_LIMIT is the hop limit set in each TC message. TC_HOP_LIMIT MAY be a single fixed value or MAY be different in TC messages sent by the same router. However, each other router, at any hop count distance, MUST see a regular pattern of TC messages in order that meaningful values of TLVs with Type = INTERVAL_TIME and Type = VALIDITY_TIME at each hop count distance can be included as defined in [RFC5497]. Thus, the pattern of TC_HOP_LIMIT MUST be defined to have this property. For example, the repeating pattern (255 4 4) satisfies this property (having period TC_INTERVAL at hop counts up to 4, inclusive, and 3 x TC_INTERVAL at hop counts greater than 4), but the repeating pattern (255 255 4 4) does not satisfy this property because at hop counts greater than 4, message intervals are alternately TC_INTERVAL and 3 x TC_INTERVAL.
パラメータTC_HOP_LIMITは、各TCメッセージに設定されたホップ制限です。 TC_HOP_LIMITは、単一の固定値である場合と、同じルーターから送信されるTCメッセージで異なる場合があります。ただし、[RFC5497]で定義されているように、各ホップカウント距離でType = INTERVAL_TIMEおよびType = VALIDITY_TIMEのTLVの意味のある値を含めることができるように、他の各ルーターは、任意のホップカウント距離で、TCメッセージの通常のパターンを参照する必要があります。したがって、このプロパティを持つようにTC_HOP_LIMITのパターンを定義する必要があります。たとえば、繰り返しパターン（255 4 4）はこのプロパティを満たします（ホップカウントでの期間TC_INTERVALは最大4を含み、ホップカウントが4より大きい場合は3 x TC_INTERVALです）が、繰り返しパターン（255 255 4 4）はそうですホップカウントが4を超えると、メッセージ間隔がTC_INTERVALと3 x TC_INTERVALになるため、このプロパティは満たされません。
The following constraints apply to this parameter:
このパラメーターには次の制約が適用されます。
o The maximum value of TC_HOP_LIMIT >= the network diameter in hops; a value of 255 is RECOMMENDED. Note that if using a pattern of different values of TC_HOP_LIMIT as described above, then only the maximum value in the pattern is so constrained.
o TC_HOP_LIMITの最大値> =ホップ単位のネットワーク直径。 255の値が推奨されます。上記のようにTC_HOP_LIMITの異なる値のパターンを使用する場合、パターンの最大値のみがそのように制約されることに注意してください。
o All values of TC_HOP_LIMIT >= 2.
o TC_HOP_LIMITのすべての値> = 2。
Each router has two willingness parameters: WILL_FLOODING and WILL_ROUTING, each of which MUST be in the range WILL_NEVER to WILL_ALWAYS, inclusive.
各ルーターには、WILL_FLOODINGとWILL_ROUTINGの2つの意欲パラメーターがあります。それぞれのパラメーターは、WILL_NEVERからWILL_ALWAYSまでの範囲内でなければなりません。
WILL_FLOODING represents the router's willingness to be selected as a flooding MPR and hence to participate in MPR flooding, in particular of TC messages.
WILL_FLOODINGは、フラッディングMPRとして選択され、特にTCメッセージのMPRフラッディングに参加するルーターの意思を表します。
WILL_ROUTING represents the router's willingness to be selected as a routing MPR and hence to be an intermediate router on routes.
WILL_ROUTINGは、ルーターがルーティングMPRとして選択され、ルートの中間ルーターになる意思を表します。
In either case, the higher the value, the greater the router's willingness to be a flooding or routing MPR, as appropriate. If a router has a willingness value of WILL_NEVER (the lowest possible value), it does not perform the corresponding task. A MANET using this protocol with too many routers having either of the willingness parameters WILL_FLOODING or WILL_ROUTING equal to WILL_NEVER will not function; it MUST be ensured, by administrative or other means, that this does not happen.
どちらの場合も、値が大きいほど、ルーターのフラッディングMPRまたはルーティングMPRへの意欲が高くなります。ルーターの意欲値がWILL_NEVER（最低値）の場合、対応するタスクは実行されません。このプロトコルを使用するMANETは、WILL_FLOODINGまたはWILL_ROUTINGのいずれかの意欲パラメーターがWILL_NEVERに等しいルーターが多すぎると機能しません。これが発生しないように、管理上またはその他の手段で保証する必要があります。
Note that the proportion at which the routers having a willingness value equal to WILL_NEVER is "too many" depends on the network topology -- which, in a MANET, may change dynamically. Willingness is intended to enable that certain routers (e.g., routers that have generous resources, such as a permanent power supply) can be configured to assume more of the network operation, while others (e.g., routers that have lesser resources, such as are battery operated) can avoid such tasks. A general guideline would be that only if a router is not actually able to assume the task (flooding or routing) should it be configured with the corresponding willingness WILL_NEVER.
WILL_NEVERに等しい値をもつルーターが "多すぎる"割合は、ネットワークトポロジに依存します。これは、MANETでは動的に変化する可能性があります。意欲は、特定のルーター（たとえば、永続的な電源などの十分なリソースを持つルーター）がより多くのネットワーク操作を引き受けるように構成できるようにすることを目的としていますが、他のルーター（たとえば、バッテリーなどのリソースが少ないルーター）そのようなタスクを回避することができます）。一般的なガイドラインとしては、ルーターが実際にタスク（フラッディングまたはルーティング）を引き受けることができない場合にのみ、対応する意欲をWILL_NEVERに設定する必要があります。
If a router has a willingness value equal to WILL_ALWAYS (the highest possible value), then it will always be selected as a flooding or routing MPR, as appropriate, by all symmetric 1-hop neighbors.
ルーターの意欲値がWILL_ALWAYS（考えられる最も高い値）に等しい場合、すべての対称1ホップネイバーによって、適切なフラッディングまたはルーティングMPRとして常に選択されます。
In a MANET in which all routers have WILL_FLOODING = WILL_ALWAYS, flooding reduction will effectively be disabled, and flooding will perform as blind flooding.
すべてのルーターにWILL_FLOODING = WILL_ALWAYSが設定されているMANETでは、フラッディングの削減は事実上無効になり、フラッディングはブラインドフラッディングとして実行されます。
In a MANET in which all routers have WILL_ROUTING = WILL_ALWAYS, topology reduction will effectively be disabled, and all routers will advertise all of their links in TC messages.
すべてのルーターにWILL_ROUTING = WILL_ALWAYSが設定されているMANETでは、トポロジの削減は事実上無効になり、すべてのルーターがTCメッセージですべてのリンクをアドバタイズします。
A router that has WILL_ROUTING = WILL_NEVER will not act as an intermediate router in the MANET. Such a router can act as a source, destination, or gateway to another routing domain.
WILL_ROUTING = WILL_NEVERのルーターは、MANETの中間ルーターとして機能しません。このようなルーターは、別のルーティングドメインへの送信元、宛先、またはゲートウェイとして機能できます。
Different routers MAY have different values for WILL_FLOODING and/or WILL_ROUTING.
ルーターによって、WILL_FLOODINGやWILL_ROUTINGの値が異なる場合があります。
The following constraints apply to these parameters:
これらのパラメーターには、次の制約が適用されます。
o WILL_NEVER <= WILL_FLOODING <= WILL_ALWAYS
o WILL_NEVER <= WILL_FLOODING <= WILL_ALWAYS
o WILL_NEVER <= WILL_ROUTING <= WILL_ALWAYS
o WILL_NEVER <= WILL_ROUTING <= WILL_ALWAYS
If protocol parameters are changed dynamically, then the constraints in this section apply.
プロトコルパラメータが動的に変更される場合、このセクションの制約が適用されます。
RX_HOLD_TIME
RX_HOLD_TIME
* If RX_HOLD_TIME for an OLSRv2 interface changes, then the expiry time for all Received Tuples for that OLSRv2 interface MAY be changed.
* OLSRv2インターフェイスのRX_HOLD_TIMEが変更された場合、そのOLSRv2インターフェイスのすべての受信タプルの有効期限が変更される場合があります。
O_HOLD_TIME
O_HOLD_TIME
* If O_HOLD_TIME changes, then the expiry time for all Originator Tuples MAY be changed.
* O_HOLD_TIMEが変更されると、すべてのオリジネータータプルの有効期限が変更される場合があります。
TC_INTERVAL
TC_INTERVAL
* If TC_INTERVAL increases, then the next TC message generated by this router MUST be generated according to the previous, shorter TC_INTERVAL. Additional subsequent TC messages MAY be generated according to the previous, shorter, TC_INTERVAL.
* TC_INTERVALが増加する場合、このルーターによって生成される次のTCメッセージは、以前のより短いTC_INTERVALに従って生成される必要があります。追加の後続のTCメッセージは、以前のより短いTC_INTERVALに従って生成される場合があります。
* If TC_INTERVAL decreases, then the following TC messages from this router MUST be generated according to the current, shorter, TC_INTERVAL.
* TC_INTERVALが減少する場合、このルーターからの次のTCメッセージは、現在のより短いTC_INTERVALに従って生成される必要があります。
P_HOLD_TIME
P_HOLD_TIME
* If P_HOLD_TIME changes, then the expiry time for all Processed Tuples MAY be changed.
* P_HOLD_TIMEが変更されると、すべての処理済みタプルの有効期限が変更される場合があります。
F_HOLD_TIME
F_HOLD_TIME
* If F_HOLD_TIME changes, then the expiry time for all Forwarded Tuples MAY be changed.
* F_HOLD_TIMEが変更されると、すべての転送タプルの有効期限が変更される場合があります。
TP_MAXJITTER
TP_MAXJITTER
* If TP_MAXJITTER changes, then the periodic TC message schedule on this router MAY be changed immediately.
* TP_MAXJITTERが変更された場合、このルーターの定期的なTCメッセージのスケジュールはすぐに変更される場合があります。
TT_MAXJITTER
TT_MAXJITTER
* If TT_MAXJITTER changes, then externally triggered TC messages on this router MAY be rescheduled.
* TT_MAXJITTERが変更された場合、このルーターで外部からトリガーされたTCメッセージが再スケジュールされる場合があります。
F_MAXJITTER
F_MAXJITTER
* If F_MAXJITTER changes, then TC messages waiting to be forwarded with a delay based on this parameter MAY be rescheduled.
* F_MAXJITTERが変更された場合、このパラメーターに基づいて遅延して転送を待機しているTCメッセージが再スケジュールされる場合があります。
TC_HOP_LIMIT
TC_HOP_LIMIT
* If TC_HOP_LIMIT changes, and the router uses multiple values after the change, then message intervals and validity times included in TC messages MUST be respected. The simplest way to do this is to start any new repeating pattern of TC_HOP_LIMIT values with its largest value.
* TC_HOP_LIMITが変更され、ルーターが変更後に複数の値を使用する場合、TCメッセージに含まれるメッセージ間隔と有効時間を尊重する必要があります。これを行う最も簡単な方法は、最大の値でTC_HOP_LIMIT値の新しい繰り返しパターンを開始することです。
LINK_METRIC_TYPE
LINK_METRIC_TYPE
* If LINK_METRIC_TYPE changes, then all link metric information recorded by the router is invalid. The router MUST take the following actions and all consequent actions described in Section 17 and [RFC6130].
* LINK_METRIC_TYPEが変更されると、ルーターによって記録されたすべてのリンクメトリック情報が無効になります。ルーターは、以下のアクションと、セクション17と[RFC6130]で説明されているすべての結果的なアクションを実行する必要があります。
+ For each Link Tuple in any Link Set for an OLSRv2 interface, either update L_in_metric (the value MAXIMUM_METRIC MAY be used) or remove the Link Tuple from the Link Set.
+ OLSRv2インターフェイスの任意のリンクセットの各リンクタプルについて、L_in_metric（値MAXIMUM_METRICを使用できます）を更新するか、リンクセットからリンクタプルを削除します。
+ For each Link Tuple that is not removed, set:
+ 削除されないリンクタプルごとに、次のように設定します。
- L_out_metric := UNKNOWN_METRIC;
- L_out_metric：= UNKNOWN_METRIC;
- L_SYM_time := EXPIRED;
- L_SYM_time：= EXPIRED;
- L_MPR_selector := false.
- L_MPR_selector：= false。
+ Remove all Router Topology Tuples, Routable Address Topology Tuples, Attached Network Tuples, and Routing Tuples from their respective Protocol Sets in the Topology Information Base.
+ すべてのルータートポロジタプル、ルーティング可能なアドレストポロジタプル、接続されたネットワークタプル、およびルーティングタプルを、トポロジ情報ベースのそれぞれのプロトコルセットから削除します。
The following constants are specified for routers. Unlike router parameters, constants MUST NOT change and MUST be the same on all routers.
以下の定数がルーターに指定されています。ルーターパラメータとは異なり、定数は変更してはならず、すべてのルーターで同じである必要があります。
The constant minimum and maximum link metric values are defined by:
一定の最小および最大リンクメトリック値は、以下によって定義されます。
o MINIMUM_METRIC := 1
o MINIMUM_METRIC：= 1
o MAXIMUM_METRIC := 16776960
o MAXIMUM_METRIC：= 16776960
The symbolic value UNKNOWN_METRIC is defined in Section 6.1.
シンボリック値UNKNOWN_METRICはセクション6.1で定義されています。
The constant minimum, RECOMMENDED default, and maximum willingness values are defined by:
一定の最小値、推奨されるデフォルト値、および最大の意欲値は、次のように定義されます。
o WILL_NEVER := 0
o WILL_NEVER：= 0
o WILL_DEFAULT := 7
o WILL_DEFAULT：= 7
o WILL_ALWAYS := 15
o WILL_ALWAYS：= 15
The constant C (time granularity) is used as specified in [RFC5497]. It MUST be the same as is used by [RFC6130], with RECOMMENDED value:
定数C（時間粒度）は、[RFC5497]で指定されているとおりに使用されます。 [RFC6130]で使用されているものと同じであり、推奨値が必要です。
o C := 1/1024 second
o C：= 1/1024秒
Note that this constant is used in the representation of time intervals. Time values (such as are stored in Protocol Tuples) are not so represented. A resolution of C in such values is sufficient (but not necessary) for such values.
この定数は時間間隔の表現で使用されることに注意してください。時間値（プロトコルタプルに格納されているような）は、そのように表現されていません。そのような値のCの分解能は、そのような値には十分です（ただし必須ではありません）。
A router records a link metric value for each direction of a link of which it has knowledge. These link metric values are used to create metrics for routes by the addition of link metric values.
ルーターは、知っているリンクの各方向のリンクメトリック値を記録します。これらのリンクメトリック値は、リンクメトリック値を追加することにより、ルートのメトリックを作成するために使用されます。
Link metrics are reported in messages using a compressed representation that occupies 12 bits, consisting of a 4-bit field and an 8-bit field. The compressed representation represents positive integer values with a minimum value of 1 and a maximum value that is slightly smaller than the maximum 24-bit value. Only those values that have exact representation in the compressed form are used. Route metrics are the summation of no more than 256 link metric values and can therefore be represented using no more than 32 bits.
リンクメトリックは、4ビットフィールドと8ビットフィールドで構成される12ビットを占める圧縮表現を使用してメッセージで報告されます。圧縮表現は、最小値が1で、最大値が24ビットの最大値よりわずかに小さい正の整数値を表します。圧縮形式で正確に表現されている値のみが使用されます。ルートメトリックは、256以下のリンクメトリック値の合計であるため、32ビット以下を使用して表すことができます。
Link and route metrics used in the Information Bases defined in this specification refer to the uncompressed values, and arithmetic involving them does likewise and assumes full precision in the result. (How an implementation records the values is not part of this specification, as long as it behaves as if recording uncompressed values. An implementation can, for example, use 32-bit values for all link and route metrics.) In some cases, a link metric value may be unknown. This is indicated in this specification by the symbolic value UNKNOWN_METRIC. An implementation may use any representation of UNKNOWN_METRIC as it is never included in messages or used in any computation. (Possible representations are zero or any value greater than the maximum representable metric value.)
この仕様で定義されている情報ベースで使用されるリンクとルートのメトリックは、非圧縮値を参照し、それらを含む算術は同様に、結果の完全な精度を想定しています。 （実装が値を記録する方法は、圧縮されていない値を記録するかのように動作する限り、この仕様の一部ではありません。たとえば、実装は、すべてのリンクおよびルートメトリックに32ビット値を使用できます。）場合によっては、リンクメトリック値が不明である可能性があります。これは、この仕様では記号値UNKNOWN_METRICで示されています。実装はUNKNOWN_METRICの任意の表現を使用できます。これは、メッセージに含まれることも、計算で使用されることもないためです。 （可能な表現は、ゼロまたは表現可能な最大メトリック値より大きい値です。）
The 12-bit compressed form of a link metric uses a modified form of a representation with an 8-bit mantissa (denoted a) and a 4-bit exponent (denoted b). Note that if represented as the 12-bit value 256b+a, then the ordering of those 12-bit values is identical to the ordering of the represented values.
リンクメトリックの12ビットの圧縮形式は、8ビットの仮数（aで示される）と4ビットの指数（bで示される）を持つ表現の変更された形式を使用します。 12ビット値256b + aとして表される場合、それらの12ビット値の順序は、表された値の順序と同じであることに注意してください。
The value so represented is (257+a)2^b - 256, where ^ denotes exponentiation. This has a minimum value (when a = 0 and b = 0) of MINIMUM_METRIC = 1 and a maximum value (when a = 255 and b = 15) of MAXIMUM_METRIC = 2^24 - 256.
そのように表される値は（257 + a）2 ^ b-256です。ここで、^はべき乗を示します。これには、MINIMUM_METRIC = 1の最小値（a = 0およびb = 0の場合）およびMAXIMUM_METRIC = 2 ^ 24-256の最大値（a = 255およびb = 15の場合）があります。
An algorithm for computing a and b for the smallest representable value not less than a link metric value v such that MINIMUM_METRIC <= v <= MAXIMUM_METRIC is:
MINIMUM_METRIC <= v <= MAXIMUM_METRICとなるようなリンクメトリック値v以上の最小の表現可能な値のaおよびbを計算するためのアルゴリズム：
1. Find the smallest integer b such that v + 256 <= 2^(b + 9).
1. v + 256 <= 2 ^（b + 9）となるような最小の整数bを見つけます。
2. Set a := (v - 256(2^b - 1)) / (2^b) - 1, rounded up to the nearest integer.
2. a：=（v-256（2 ^ b-1））/（2 ^ b）-1を設定し、最も近い整数に切り上げます。
The Local Information Base, as defined for each router in [RFC6130], is extended by this protocol by:
[RFC6130]で各ルーターに対して定義されているローカル情報ベースは、このプロトコルによって次のように拡張されます。
o Recording the router's originator address. The originator address MUST be unique to this router. It MUST NOT be used by any other router as an originator address. It MAY be included in any network address in any I_local_iface_addr_list of this router; it MUST NOT be included in any network address in any I_local_iface_addr_list of any other router. It MAY be included in, but MUST NOT be equal to, the AL_net_addr in any Local Attached Network Tuple in this or any other router.
o ルーターの発信元アドレスを記録します。発信元アドレスは、このルーターに固有でなければなりません。他のルーターが発信元アドレスとして使用してはなりません。これは、このルーターのI_local_iface_addr_listのネットワークアドレスに含めることができます。他のルーターのI_local_iface_addr_listのネットワークアドレスに含めることはできません。このルーターまたは他のルーターのローカル接続ネットワークタプルのAL_net_addrに含めることはできますが、同じにすることはできません。
o The addition of an Originator Set, defined in Section 7.1, and a Local Attached Network Set, defined in Section 7.2.
o セクション7.1で定義されたオリジネーターセットと、セクション7.2で定義されたローカル接続ネットワークセットの追加。
All routable addresses of the router for which it is to accept IP packets as destination MUST be included in the Local Interface Set or the Local Attached Network Set.
宛先としてIPパケットを受け入れるルーターのすべてのルーティング可能なアドレスは、ローカルインターフェイスセットまたはローカル接続ネットワークセットに含まれている必要があります。
A router's Originator Set records addresses that were recently used as originator addresses by this router. If a router's originator address is immutable, then the Originator Set is always empty and MAY be omitted. It consists of Originator Tuples:
ルーターの発信元セットは、このルーターによって発信元アドレスとして最近使用されたアドレスを記録します。ルーターのオリジネーターアドレスが不変の場合、オリジネーターセットは常に空であり、省略してもかまいません。それはオリジネータータプルで構成されています：
(O_orig_addr, O_time)
（O_orig_addr、O_time）
where:
ただし：
O_orig_addr is a recently used originator address; note that this does not include a prefix length.
O_orig_addrは、最近使用された発信元アドレスです。これにはプレフィックス長が含まれていないことに注意してください。
O_time specifies the time at which this Tuple expires and MUST be removed.
O_timeは、このタプルの有効期限が切れる時刻を指定し、削除する必要があります。
A router's Local Attached Network Set records its local non-OLSRv2 interfaces via which it can act as a gateway to other networks. The Local Attached Network Set MUST be provided to this protocol and MUST reflect any changes in the router's status. (In cases where the router's configuration is static, the Local Attached Network Set will be constant; in cases where the router has no such non-OLSRv2 interfaces, the Local Attached Network Set will be empty.) The Local Attached Network Set is not modified by this protocol. This protocol will respond to (externally provided) changes to the Local Attached Network Set. It consists of Local Attached Network Tuples:
ルーターのローカル接続ネットワークセットは、他のネットワークへのゲートウェイとして機能できるローカルの非OLSRv2インターフェイスを記録します。ローカル接続ネットワークセットはこのプロトコルに提供する必要があり、ルーターのステータスの変更を反映する必要があります。 （ルーターの構成が静的である場合、ローカル接続ネットワークセットは一定になります。ルーターにそのような非OLSRv2インターフェイスがない場合、ローカル接続ネットワークセットは空になります。）ローカル接続ネットワークセットは変更されません。このプロトコルによる。このプロトコルは、ローカル接続ネットワークセットへの（外部から提供された）変更に応答します。ローカル接続ネットワークタプルで構成されています。
(AL_net_addr, AL_dist, AL_metric)
（AL_net_addr、AL_dist、AL_metric）
where:
ただし：
AL_net_addr is the network address of an attached network that can be reached via this router. This SHOULD be a routable address. It is constrained as described below.
AL_net_addrは、このルーターを介して到達できる接続ネットワークのネットワークアドレスです。これはルーティング可能なアドレスである必要があります。以下のように制約されます。
AL_dist is the number of hops to the network with network address AL_net_addr from this router.
AL_distは、このルーターからネットワークアドレスAL_net_addrを持つネットワークへのホップ数です。
AL_metric is the metric of the link to the attached network with address AL_net_addr from this router.
AL_metricは、このルーターからのアドレスAL_net_addrを持つ接続ネットワークへのリンクのメトリックです。
Attached networks local to this router only (i.e., not reachable except via this router) SHOULD be treated as local non-MANET interfaces and added to the Local Interface Set, as specified in [RFC6130], rather than added to the Local Attached Network Set.
このルーターにのみローカルな接続ネットワーク（つまり、このルーター経由でのみ到達可能でない）は、ローカル非MANETインターフェイスとして扱われ、ローカル接続ネットワークセットに追加されるのではなく、[RFC6130]で指定されているように、ローカルインターフェイスセットに追加されるべきです（SHOULD）。 。
Because an attached network is not specific to the router and may be outside the MANET, an attached network MAY also be attached to other routers. Routing to an AL_net_addr will use maximum prefix length matching; consequently, an AL_net_addr MAY include, but MUST NOT equal or be included in, any network address that is of any interface of any router (i.e., is included in any I_local_iface_addr_list) or equal any router's originator address.
接続ネットワークはルーターに固有ではなく、MANETの外部にある可能性があるため、接続ネットワークは他のルーターにも接続できます（MAY）。 AL_net_addrへのルーティングでは、最大プレフィックス長のマッチングが使用されます。その結果、AL_net_addrは、ルーターの任意のインターフェースのネットワークアドレス（つまり、I_local_iface_addr_listに含まれている）またはルーターの発信元アドレスに等しい、または含まれてはいけません（MAY）。
It is not the responsibility of this protocol to maintain routes from this router to networks recorded in the Local Attached Network Set.
このルーターからローカル接続ネットワークセットに記録されているネットワークへのルートを維持することは、このプロトコルの責任ではありません。
Local Attached Network Tuples are removed from the Local Attached Network Set only when the router's local attached network configuration changes, i.e., they are not subject to timer-based expiration or changes due to received messages.
ローカル接続ネットワークタプルがローカル接続ネットワークセットから削除されるのは、ルーターのローカル接続ネットワーク構成が変更された場合、つまり、タイマーベースの期限切れやメッセージの受信による変更の影響を受けない場合のみです。
An Interface Information Base, as defined in [RFC6130], is maintained for each MANET interface. The Link Set and 2-Hop Set in the Interface Information Base for an OLSRv2 interface are modified by this protocol. In some cases, it may be convenient to consider these Sets as also containing these additional elements for other MANET interfaces, taking the indicated values on creation but never being updated.
[RFC6130]で定義されているインターフェイス情報ベースは、各MANETインターフェイスに対して維持されます。 OLSRv2インターフェイスのインターフェイス情報ベースのリンクセットと2ホップセットは、このプロトコルによって変更されます。場合によっては、これらのセットを他のMANETインターフェースのこれらの追加要素も含むものと見なし、作成時に示された値を取得するが、決して更新されないことが便利な場合があります。
The Link Set is modified by adding these additional elements to each Link Tuple:
リンクセットは、これらの追加要素を各リンクタプルに追加することによって変更されます。
L_in_metric is the metric of the link from the OLSRv2 interface with addresses L_neighbor_iface_addr_list to this OLSRv2 interface;
L_in_metricは、アドレスがL_neighbor_iface_addr_listのOLSRv2インターフェイスからこのOLSRv2インターフェイスへのリンクのメトリックです。
L_out_metric is the metric of the link to the OLSRv2 interface with addresses L_neighbor_iface_addr_list from this OLSRv2 interface;
L_out_metricは、このOLSRv2インターフェイスからのアドレスL_neighbor_iface_addr_listを持つOLSRv2インターフェイスへのリンクのメトリックです。
L_mpr_selector is a boolean flag, describing if this neighbor has selected this router as a flooding MPR, i.e., is a flooding MPR selector of this router.
L_mpr_selectorはブールフラグであり、このネイバーがこのルータをフラッディングMPRとして選択したかどうか、つまり、このルータのフラッディングMPRセレクタであるかどうかを示します。
L_in_metric will be specified by a process that is external to this specification. Any Link Tuple with L_status = HEARD or L_status = SYMMETRIC MUST have a specified value of L_in_metric if it is to be used by this protocol.
L_in_metricは、この仕様の外部にあるプロセスによって指定されます。 L_status = HEARDまたはL_status = SYMMETRICのリンクタプルは、このプロトコルで使用される場合、L_in_metricの指定された値を持っている必要があります。
A Link Tuple created (but not updated) by [RFC6130] MUST set:
[RFC6130]によって作成された（ただし更新されていない）リンクタプルは、以下を設定する必要があります。
o L_in_metric := UNKNOWN_METRIC;
o L_in_metric：= UNKNOWN_METRIC;
o L_out_metric := UNKNOWN_METRIC;
o L_out_metric：= UNKNOWN_METRIC;
o L_mpr_selector := false.
o L_mpr_selector：= false。
The 2-Hop Set is modified by adding these additional elements to each 2-Hop Tuple:
2ホップセットは、各2ホップタプルに次の追加要素を追加することによって変更されます。
N2_in_metric is the neighbor metric from the router with address N2_2hop_iface_addr to the router with OLSRv2 interface addresses N2_neighbor_iface_addr_list;
N2_in_metricは、アドレスN2_2hop_iface_addrのルーターからOLSRv2インターフェイスアドレスN2_neighbor_iface_addr_listのルーターへのネイバーメトリックです。
N2_out_metric is the neighbor metric to the router with address N2_2hop_iface_addr from the router with OLSRv2 interface addresses N2_neighbor_iface_addr_list.
N2_out_metricは、OLSRv2インターフェイスアドレスN2_neighbor_iface_addr_listを持つルーターからアドレスN2_2hop_iface_addrを持つルーターへのネイバーメトリックです。
A 2-Hop Tuple created (but not updated) by [RFC6130] MUST set:
[RFC6130]によって作成された（ただし更新されていない）2ホップのタプルは、以下を設定する必要があります。
o N2_in_metric := UNKNOWN_METRIC;
o N2_in_metric：= UNKNOWN_METRIC;
o N2_out_metric := UNKNOWN_METRIC.
o N2_out_metric：= UNKNOWN_METRIC。
A Neighbor Information Base, as defined in [RFC6130], is maintained for each router. It is modified by this protocol by adding these additional elements to each Neighbor Tuple in the Neighbor Set. In some cases, it may be convenient to consider these Sets as also containing these additional elements for other MANET interfaces, taking the indicated values on creation but never being updated.
[RFC6130]で定義されているように、近隣情報ベースは各ルーターに対して維持されます。これは、これらの追加要素を近隣セット内の各近隣タプルに追加することにより、このプロトコルによって変更されます。場合によっては、これらのセットを他のMANETインターフェースのこれらの追加要素も含むものと見なし、作成時に示された値を取得するが、決して更新されないことが便利な場合があります。
N_orig_addr is the neighbor's originator address, which may be unknown. Note that this originator address does not include a prefix length;
N_orig_addrは、不明である可能性があるネイバーの発信元アドレスです。この発信元アドレスにはプレフィックス長が含まれていないことに注意してください。
N_in_metric is the neighbor metric of any link from this neighbor to an OLSRv2 interface of this router, i.e., the minimum of all corresponding L_in_metric with L_status = SYMMETRIC and L_in_metric != UNKNOWN_METRIC, UNKNOWN_METRIC if there are no such Link Tuples;
N_in_metricは、このネイバーからこのルーターのOLSRv2インターフェイスへのリンクのネイバーメトリックです。つまり、L_status = SYMMETRICおよびL_in_metric！= UNKNOWN_METRIC、UNKNOWN_METRICを持つすべての対応するL_in_metricの最小値は、そのようなリンクタプルがない場合です。
N_out_metric is the neighbor metric of any link from an OLSRv2 interface of this router to this neighbor, i.e., the minimum of all corresponding L_out_metric with L_status = SYMMETRIC and L_out_metric != UNKNOWN_METRIC, UNKNOWN_METRIC if there are no such Link Tuples;
N_out_metricは、このルーターのOLSRv2インターフェースからこのネイバーへのリンクのネイバーメトリックです。つまり、L_status = SYMMETRICおよびL_out_metric！= UNKNOWN_METRIC、UNKNOWN_METRICを持つすべての対応するL_out_metricの最小値は、そのようなリンクタプルがない場合です。
N_will_flooding is the neighbor's willingness to be selected as a flooding MPR, in the range from WILL_NEVER to WILL_ALWAYS, both inclusive, taking the value WILL_NEVER if no OLSRv2-specific information is received from this neighbor;
N_will_floodingは、WILL_NEVERからWILL_ALWAYSまでの範囲でフラッディングMPRとして選択されるネイバーの意思であり、OLSRv2固有の情報がこのネイバーから受信されない場合は、WILL_NEVERの値を取ります。
N_will_routing is the neighbor's willingness to be selected as a routing MPR, in the range from WILL_NEVER to WILL_ALWAYS, both inclusive, taking the value WILL_NEVER if no OLSRv2-specific information is received from this neighbor;
N_will_routingは、ルーティングMPRとして選択されるネイバーの意欲であり、WILL_NEVERからWILL_ALWAYSまでの範囲で、このネイバーからOLSRv2固有の情報が受信されない場合はWILL_NEVERの値を取ります。
N_flooding_mpr is a boolean flag, describing if this neighbor is selected as a flooding MPR by this router;
N_flooding_mprはブールフラグで、このネイバーがこのルータによってフラッディングMPRとして選択されているかどうかを示します。
N_routing_mpr is a boolean flag, describing if this neighbor is selected as a routing MPR by this router;
N_routing_mprはブールフラグであり、このネイバーがこのルータによってルーティングMPRとして選択されているかどうかを示します。
N_mpr_selector is a boolean flag, describing if this neighbor has selected this router as a routing MPR, i.e., is a routing MPR selector of this router.
N_mpr_selectorはブールフラグで、このネイバーがこのルータをルーティングMPRとして選択したかどうか、つまり、このルータのルーティングMPRセレクタであるかどうかを示します。
N_advertised is a boolean flag, describing if this router has elected to advertise a link to this neighbor in its TC messages.
N_advertisedはブールフラグで、このルーターがTCメッセージでこのネイバーへのリンクをアドバタイズすることを選択したかどうかを示します。
A Neighbor Tuple created (but not updated) by [RFC6130] MUST set:
[RFC6130]によって作成された（ただし更新されていない）隣接タプルは、以下を設定する必要があります。
o N_orig_addr := unknown;
o N_orig_addr：=不明;
o N_in_metric := UNKNOWN_METRIC;
o N_in_metric：= UNKNOWN_METRIC;
o N_out_metric := UNKNOWN_METRIC;
o N_out_metric：= UNKNOWN_METRIC;
o N_will_flooding := WILL_NEVER;
o N_will_flooding：= WILL_NEVER;
o N_will_routing := WILL_NEVER;
o N_will_routing：= WILL_NEVER;
o N_routing_mpr := false;
o N_routing_mpr：= false;
o N_flooding_mpr := false;
o N_flooding_mpr：= false;
o N_mpr_selector := false;
o N_mpr_selector：= false;
o N_advertised := false.
o N_advertised：= false。
The Neighbor Information Base also includes a variable, the Advertised Neighbor Sequence Number (ANSN), whose value is included in TC messages to indicate the freshness of the information transmitted. The ANSN is incremented whenever advertised information (the originator and routable addresses included in Neighbor Tuples with N_advertised = true and local attached networks recorded in the Local Attached Network Set in the Local Information Base) changes, including addition or removal of such information.
ネイバー情報ベースには、変数、アドバタイズされたネイバーシーケンス番号（ANSN）も含まれます。この値は、送信された情報の鮮度を示すためにTCメッセージに含まれています。アドバタイズされた情報（N_advertised = trueのネイバータプルに含まれる発信元とルーティング可能なアドレス、およびローカル情報ベースのローカル接続ネットワークセットに記録されたローカル接続ネットワーク）が変更されると、そのような情報の追加や削除など、ANSNが増加します。
The Topology Information Base, defined for each router by this specification, stores information received in TC messages in the Advertising Remote Router Set, the Router Topology Set, the Routable Address Topology Set, and the Attached Network Set.
この仕様で各ルーターに対して定義されたトポロジ情報ベースは、アドバタイジングリモートルーターセット、ルータートポロジセット、ルーティング可能なアドレストポロジセット、および接続されたネットワークセットのTCメッセージで受信した情報を格納します。
Additionally, a Routing Set is maintained, derived from the information recorded in the Local Information Base, the Interface Information Bases, the Neighbor Information Base, and the rest of the Topology Information Base.
さらに、ルーティングセットは、ローカル情報ベース、インターフェース情報ベース、ネイバー情報ベース、およびトポロジ情報ベースの残りの部分に記録された情報から派生して維持されます。
A router's Advertising Remote Router Set records information describing each remote router in the network that transmits TC messages, allowing outdated TC messages to be recognized and discarded. It consists of Advertising Remote Router Tuples:
ルーターのアドバタイジングリモートルーターセットは、TCメッセージを送信するネットワーク内の各リモートルーターを説明する情報を記録し、古いTCメッセージを認識して破棄できるようにします。これは、リモートルータタプルのアドバタイズで構成されています。
(AR_orig_addr, AR_seq_number, AR_time)
（AR_orig_addr、AR_seq_number、AR_time）
where:
ただし：
AR_orig_addr is the originator address of a received TC message, note that this does not include a prefix length;
AR_orig_addrは、受信したTCメッセージの発信元アドレスです。これにはプレフィックス長が含まれていないことに注意してください。
AR_seq_number is the greatest ANSN in any TC message received that originated from the router with originator address AR_orig_addr (i.e., that contributed to the information contained in this Tuple);
AR_seq_numberは、発信元アドレスAR_orig_addrを持つルーターから発信された（つまり、このタプルに含まれる情報に貢献した）受信したTCメッセージ内の最大のANSNです。
AR_time is the time at which this Tuple expires and MUST be removed.
AR_timeは、このタプルの有効期限が切れた時刻であり、削除する必要があります。
A router's Topology Set records topology information about the links between routers in the MANET. It consists of Router Topology Tuples:
ルータのトポロジセットは、MANET内のルータ間のリンクに関するトポロジ情報を記録します。これは、ルータートポロジタプルで構成されています。
(TR_from_orig_addr, TR_to_orig_addr, TR_seq_number, TR_metric, TR_time)
（TR_from_orig_addr、TR_to_orig_addr、TR_seq_number、TR_metric、TR_time）
where:
ただし：
TR_from_orig_addr is the originator address of a router that can reach the router with originator address TR_to_orig_addr in one hop (note that this does not include a prefix length);
TR_from_orig_addrは、1ホップで発信元アドレスTR_to_orig_addrを持つルーターに到達できるルーターの発信元アドレスです（これにはプレフィックス長が含まれないことに注意してください）。
TR_to_orig_addr is the originator address of a router that can be reached by the router with originator address TR_from_orig_addr in one hop (note that this does not include a prefix length);
TR_to_orig_addrは、1つのホップで発信元アドレスTR_from_orig_addrを持つルーターが到達できるルーターの発信元アドレスです（これにはプレフィックス長が含まれないことに注意してください）。
TR_seq_number is the greatest ANSN in any TC message received that originated from the router with originator address TR_from_orig_addr (i.e., that contributed to the information contained in this Tuple);
TR_seq_numberは、発信元アドレスTR_from_orig_addrを持つルーターから発信された（つまり、このタプルに含まれる情報に貢献した）受信したTCメッセージ内の最大のANSNです。
TR_metric is the neighbor metric from the router with originator address TR_from_orig_addr to the router with originator address TR_to_orig_addr;
TR_metricは、発信元アドレスTR_from_orig_addrを持つルーターから発信元アドレスTR_to_orig_addrを持つルーターへのネイバーメトリックです。
TR_time specifies the time at which this Tuple expires and MUST be removed.
TR_timeは、このタプルの有効期限が切れる時刻を指定し、削除する必要があります。
A router's Routable Address Topology Set records topology information about the routable addresses within the MANET, including via which routers they may be reached. It consists of Routable Address Topology Tuples:
ルーターのルーティング可能なアドレストポロジーセットは、MANET内のルーティング可能なアドレスに関するトポロジー情報を記録します。ルーティング可能なアドレストポロジタプルで構成されます。
(TA_from_orig_addr, TA_dest_addr, TA_seq_number, TA_metric, TA_time)
（TA_from_orig_addr、TA_dest_addr、TA_seq_number、TA_metric、TA_time）
where:
ただし：
TA_from_orig_addr is the originator address of a router that can reach the router with routable address TA_dest_addr in one hop (note that this does not include a prefix length);
TA_from_orig_addrは、1ホップでルーティング可能なアドレスTA_dest_addrを持つルーターに到達できるルーターの発信元アドレスです（これにはプレフィックス長が含まれないことに注意してください）。
TA_dest_addr is a routable address of a router that can be reached by the router with originator address TA_from_orig_addr in one hop;
TA_dest_addrは、ルーターのルーティング可能なアドレスであり、1つのホップで発信元アドレスTA_from_orig_addrを使用してルーターから到達できます。
TA_seq_number is the greatest ANSN in any TC message received that originated from the router with originator address TA_from_orig_addr (i.e., that contributed to the information contained in this Tuple);
TA_seq_numberは、発信元アドレスがTA_from_orig_addrのルーターから発信された（つまり、このタプルに含まれる情報に貢献した）受信したTCメッセージ内の最大のANSNです。
TA_metric is the neighbor metric from the router with originator address TA_from_orig_addr to the router with OLSRv2 interface address TA_dest_addr;
TA_metricは、発信元アドレスTA_from_orig_addrを持つルーターからOLSRv2インターフェイスアドレスTA_dest_addrを持つルーターへのネイバーメトリックです。
TA_time specifies the time at which this Tuple expires and MUST be removed.
TA_timeは、このタプルの有効期限が切れる時刻を指定し、削除する必要があります。
A router's Attached Network Set records information about networks (which may be outside the MANET) attached to other routers and their routable addresses. It consists of Attached Network Tuples:
ルーターの接続ネットワークセットは、他のルーターに接続されているネットワーク（MANETの外部にある場合があります）とそのルーティング可能なアドレスに関する情報を記録します。アタッチされたネットワークタプルで構成されています。
(AN_orig_addr, AN_net_addr, AN_seq_number, AN_dist, AN_metric, AN_time)
（AN_orig_addr、AN_net_addr、AN_seq_number、AN_dist、AN_metric、AN_time）
where:
ただし：
AN_orig_addr is the originator address of a router that can act as gateway to the network with network address AN_net_addr (note that this does not include a prefix length);
AN_orig_addrは、ネットワークアドレスAN_net_addrを持つネットワークへのゲートウェイとして機能できるルーターの発信元アドレスです（これにはプレフィックス長が含まれないことに注意してください）。
AN_net_addr is the network address of an attached network that may be reached via the router with originator address AN_orig_addr;
AN_net_addrは、オリジネーターアドレスAN_orig_addrを使用してルーター経由で到達できる接続されたネットワークのネットワークアドレスです。
AN_seq_number is the greatest ANSN in any TC message received that originated from the router with originator address AN_orig_addr (i.e., that contributed to the information contained in this Tuple);
AN_seq_numberは、発信元アドレスがAN_orig_addrのルーターから発信された（つまり、このタプルに含まれる情報に貢献した）受信したTCメッセージ内の最大のANSNです。
AN_dist is the number of hops to the network with network address AN_net_addr from the router with originator address AN_orig_addr;
AN_distは、発信元アドレスAN_orig_addrを持つルーターからネットワークアドレスAN_net_addrを持つネットワークへのホップ数です。
AN_metric is the metric of the link from the router with originator address AN_orig_addr to the attached network with address AN_net_addr;
AN_metricは、発信元アドレスがAN_orig_addrのルーターから、アドレスがAN_net_addrの接続ネットワークへのリンクのメトリックです。
AN_time specifies the time at which this Tuple expires and MUST be removed.
AN_timeは、このタプルの有効期限が切れる時刻を指定し、削除する必要があります。
A router's Routing Set records the first hop along a selected path to each destination for which any such path is known. It consists of Routing Tuples:
ルーターのルーティングセットは、選択されたパスに沿って、そのようなパスが既知である各宛先への最初のホップを記録します。ルーティングタプルで構成されています。
(R_dest_addr, R_next_iface_addr, R_local_iface_addr, R_dist, R_metric)
（R_dest_addr、R_next_iface_addr、R_local_iface_addr、R_dist、R_metric）
where:
ただし：
R_dest_addr is the network address of the destination, either the network address of an interface of a destination router or the network address of an attached network;
R_dest_addrは、宛先のネットワークアドレスであり、宛先ルーターのインターフェイスのネットワークアドレスまたは接続されたネットワークのネットワークアドレスです。
R_next_iface_addr is the network address of the "next hop" on the selected path to the destination;
R_next_iface_addrは、宛先への選択されたパス上の「次のホップ」のネットワークアドレスです。
R_local_iface_addr is an address of the local interface over which an IP packet MUST be sent to reach the destination by the selected path.
R_local_iface_addrは、選択されたパスで宛先に到達するためにIPパケットを送信する必要があるローカルインターフェイスのアドレスです。
R_dist is the number of hops on the selected path to the destination;
R_distは、宛先への選択されたパス上のホップの数です。
R_metric is the metric of the route to the destination with address R_dest_addr.
R_metricは、アドレスR_dest_addrを持つ宛先へのルートのメトリックです。
The Routing Set for a router is derived from the contents of other Protocol Sets of the router (the Link Sets, the Neighbor Set, the Router Topology Set, the Routable Address Topology Set, the Attached Network Set, and OPTIONAL use of the 2-Hop Sets). The Routing Set is updated (Routing Tuples added or removed, or the complete Routing Set recalculated) when routing paths are calculated, based on changes to these other Protocol Sets. Routing Tuples are not subject to timer-based expiration.
ルーターのルーティングセットは、ルーターの他のプロトコルセット（リンクセット、ネイバーセット、ルータートポロジーセット、ルーティング可能なアドレストポロジーセット、接続されたネットワークセット、およびオプションの2ホップセット）。これらの他のプロトコルセットへの変更に基づいてルーティングパスが計算されると、ルーティングセットは更新されます（ルーティングタプルが追加または削除されるか、ルーティングセット全体が再計算されます）。ルーティングタプルは、タイマーベースの有効期限の対象ではありません。
The Received Message Information Base, defined by this specification, records information required to ensure that a message is processed at most once and is forwarded at most once per OLSRv2 interface of a router, using MPR flooding. Messages are recorded using their "signature", consisting of their type, originator address, and message sequence number.
この仕様で定義されている受信メッセージ情報ベースは、MPRフラッディングを使用して、メッセージが最大で1回処理され、ルーターのOLSRv2インターフェイスごとに最大1回転送されるようにするために必要な情報を記録します。メッセージは、タイプ、発信元アドレス、メッセージシーケンス番号で構成される「署名」を使用して記録されます。
A router has a Received Set per OLSRv2 interface. Each Received Set records the signatures of messages that have been received over that OLSRv2 interface. Each consists of Received Tuples:
ルーターには、OLSRv2インターフェイスごとに受信セットがあります。各受信セットは、そのOLSRv2インターフェイスを介して受信されたメッセージの署名を記録します。それぞれは受信したタプルで構成されています：
(RX_type, RX_orig_addr, RX_seq_number, RX_time)
（RX_type、RX_orig_addr、RX_seq_number、RX_time）
where:
ただし：
RX_type is the received Message Type;
RX_typeは受信したメッセージタイプです。
RX_orig_addr is the originator address of the received message (note that this does not include a prefix length);
RX_orig_addrは、受信したメッセージの発信元アドレスです（これにはプレフィックス長が含まれていないことに注意してください）。
RX_seq_number is the message sequence number of the received message;
RX_seq_numberは、受信したメッセージのメッセージシーケンス番号です。
RX_time specifies the time at which this Tuple expires and MUST be removed.
RX_timeは、このタプルの有効期限が切れる時刻を指定し、削除する必要があります。
A router has a single Processed Set that records signatures of messages that have been processed by the router. It consists of Processed Tuples:
ルーターには、ルーターによって処理されたメッセージの署名を記録する単一の処理済みセットがあります。処理されたタプルで構成されています。
(P_type, P_orig_addr, P_seq_number, P_time)
（P_type、P_orig_addr、P_seq_number、P_time）
where:
ただし：
P_type is the processed Message Type;
P_typeは処理されたメッセージタイプです。
P_orig_addr is the originator address of the processed message (note that this does not include a prefix length);
P_orig_addrは、処理されたメッセージの発信元アドレスです（これにはプレフィックス長が含まれていないことに注意してください）。
P_seq_number is the message sequence number of the processed message;
P_seq_numberは、処理されたメッセージのメッセージシーケンス番号です。
P_time specifies the time at which this Tuple expires and MUST be removed.
P_timeは、このタプルの有効期限が切れる時刻を指定し、削除する必要があります。
A router has a single Forwarded Set that records signatures of messages that have been forwarded by the router. It consists of Forwarded Tuples:
ルーターには、ルーターによって転送されたメッセージの署名を記録する単一の転送セットがあります。転送されたタプルで構成されています。
(F_type, F_orig_addr, F_seq_number, F_time)
（F_type、F_orig_addr、F_seq_number、F_time）
where:
ただし：
F_type is the forwarded Message Type;
F_typeは転送されるメッセージタイプです。
F_orig_addr is the originator address of the forwarded message (note that this does not include a prefix length);
F_orig_addrは、転送されるメッセージの発信元アドレスです（これにはプレフィックス長が含まれないことに注意してください）。
F_seq_number is the message sequence number of the forwarded message;
F_seq_numberは、転送されたメッセージのメッセージシーケンス番号です。
F_time specifies the time at which this Tuple expires and MUST be removed.
F_timeは、このタプルの有効期限が切れる時刻を指定し、削除する必要があります。
This section describes some additional properties of Information Bases and their contents.
このセクションでは、情報ベースのいくつかの追加プロパティとその内容について説明します。
As part of this specification, in a number of cases, there is a natural correspondence from a Protocol Tuple in one Protocol Set to a single Protocol Tuple in another Protocol Set, in the same or another Information Base. The latter Protocol Tuple is referred to as "corresponding" to the former Protocol Tuple.
この仕様の一部として、多くの場合、1つのプロトコルセットのプロトコルタプルから、同じまたは別の情報ベースの別のプロトコルセットの単一のプロトコルタプルに自然に対応しています。後者のプロトコルタプルは、前者のプロトコルタプルに「対応する」と呼ばれます。
Specific examples of corresponding Protocol Tuples include:
対応するプロトコルタプルの具体例は次のとおりです。
o There is a Local Interface Tuple corresponding to each Link Tuple, where the Link Tuple is in the Link Set for a MANET interface and the Local Interface Tuple represents that MANET interface.
o 各リンクタプルに対応するローカルインターフェイスタプルがあり、リンクタプルはMANETインターフェイスのリンクセットにあり、ローカルインターフェイスタプルはそのMANETインターフェイスを表します。
o There is a Neighbor Tuple corresponding to each Link Tuple that has L_HEARD_time not EXPIRED, such that N_neighbor_addr_list contains L_neighbor_iface_addr_list.
o N_neighbor_addr_listにL_neighbor_iface_addr_listが含まれるように、L_HEARD_timeがEXPIREDではない各リンクタプルに対応するネイバータプルがあります。
o There is a Link Tuple (in the Link Set in the same Interface Information Base) corresponding to each 2-Hop Tuple such that L_neighbor_iface_addr_list = N2_neighbor_iface_addr_list.
o L_neighbor_iface_addr_list = N2_neighbor_iface_addr_listのように、各2ホップタプルに対応するリンクタプル（同じインターフェイス情報ベースのリンクセット内）があります。
o There is a Neighbor Tuple corresponding to each 2-Hop Tuple, such that N_neighbor_addr_list contains N2_neighbor_iface_addr_list. (This is the Neighbor Tuple corresponding to the Link Tuple corresponding to the 2-Hop Tuple.)
o N_neighbor_addr_listにN2_neighbor_iface_addr_listが含まれるように、各2ホップタプルに対応するネイバータプルがあります。 （これは、2ホップタプルに対応するリンクタプルに対応するネイバータプルです。）
o There is an Advertising Remote Router Tuple corresponding to each Router Topology Tuple such that AR_orig_addr = TR_from_orig_addr.
o AR_orig_addr = TR_from_orig_addrのように、各ルータートポロジタプルに対応するアドバタイズリモートルータータプルがあります。
o There is an Advertising Remote Router Tuple corresponding to each Routable Address Topology Tuple such that AR_orig_addr = TA_from_orig_addr.
o AR_orig_addr = TA_from_orig_addrのような各ルーティング可能なアドレストポロジタプルに対応するアドバタイズリモートルータタプルがあります。
o There is an Advertising Remote Router Tuple corresponding to each Attached Network Tuple such that AR_orig_addr = AN_orig_addr.
o AR_orig_addr = AN_orig_addrのように、接続された各ネットワークタプルに対応するアドバタイズリモートルータタプルがあります。
o There is a Neighbor Tuple corresponding to each Routing Tuple such that N_neighbor_addr_list contains R_next_iface_addr.
o N_neighbor_addr_listにR_next_iface_addrが含まれるように、各ルーティングタプルに対応するネイバータプルがあります。
Addresses or network addresses with the following properties are considered as "fully owned" by a router when processing a received message:
次のプロパティを持つアドレスまたはネットワークアドレスは、受信したメッセージを処理するときに、ルーターによって「完全に所有されている」と見なされます。
o Equaling its originator address; OR
o 発信元アドレスと等しい。または
o Equaling the O_orig_addr in an Originator Tuple; OR
o オリジネータータプルのO_orig_addrと同等。または
o Equaling or being a sub-range of the I_local_iface_addr_list in a Local Interface Tuple; OR
o ローカルインターフェースタプル内のI_local_iface_addr_listのサブ範囲と等しいか、それである。または
o Equaling or being a sub-range of the IR_local_iface_addr in a Removed Interface Address Tuple; OR
o 削除されたインターフェイスアドレスタプル内のIR_local_iface_addrのサブレンジと等しいか、またはサブレンジであること。または
o Equaling an AL_net_addr in a Local Attached Network Tuple.
o ローカル接続ネットワークタプルのAL_net_addrと同等。
Addresses or network addresses with the following properties are considered as "partially owned" (which may include being fully owned) by a router when processing a received message:
次のプロパティを持つアドレスまたはネットワークアドレスは、受信したメッセージを処理するときに、ルーターによって「完全に所有されている」（完全に所有されている場合もある）と見なされます。
o Overlapping (equaling or containing) its originator address; OR
o 発信元アドレスの重複（等しいまたは含む）。または
o Overlapping (equaling or containing) the O_orig_addr in an Originator Tuple; OR
o Originator TupleのO_orig_addrの重複（等しいまたは含む）。または
o Overlapping the I_local_iface_addr_list in a Local Interface Tuple; OR
o ローカルインターフェイスタプル内のI_local_iface_addr_listの重複。または
o Overlapping the IR_local_iface_addr in a Removed Interface Address Tuple; OR
o 削除されたインターフェイスアドレスタプルのIR_local_iface_addrの重複。または
o Equaling or having as a sub-range an AL_net_addr in a Local Attached Network Tuple.
o ローカル接続ネットワークタプルのAL_net_addrと等しいか、サブ範囲として持つ。
The packet and message format used by this protocol is defined in [RFC5444]. Except as otherwise noted, options defined in [RFC5444] may be freely used, in particular alternative formats defined by packet, message, Address Block, and TLV flags.
このプロトコルで使用されるパケットとメッセージのフォーマットは[RFC5444]で定義されています。特に明記しない限り、[RFC5444]で定義されたオプション、特にパケット、メッセージ、アドレスブロック、TLVフラグで定義された代替フォーマットを自由に使用できます。
This section describes the usage of the packets and messages defined in [RFC5444] by this specification and the TLVs defined by, and used in, this specification.
このセクションでは、この仕様で[RFC5444]で定義されているパケットとメッセージの使用法と、この仕様で定義され使用されているTLVについて説明します。
Routers using this protocol exchange information through messages. The Message Types used by this protocol are the HELLO message and the TC message. The HELLO message is defined by [RFC6130] and extended by this specification (see Section 15). The TC message is defined by this specification (see Section 16).
このプロトコルを使用するルーターは、メッセージを通じて情報を交換します。このプロトコルで使用されるメッセージタイプは、HELLOメッセージとTCメッセージです。 HELLOメッセージは[RFC6130]によって定義され、この仕様によって拡張されます（セクション15を参照）。 TCメッセージはこの仕様で定義されています（セクション16を参照）。
One or more messages sent by a router at the same time SHOULD be combined into a single packet, subject to any constraints on maximum packet size (such as derived from the MTU over a local single hop) that MAY be imposed. These messages may have originated at the sending router or at another router and are being forwarded by the sending router. Messages with different originating routers MAY be combined for transmission within the same packet. Messages from other protocols defined using [RFC5444], including but not limited to NHDP [RFC6130], MAY be combined for transmission within the same packet. This specification does not define or use any contents of the Packet Header.
ルーターによって同時に送信された1つ以上のメッセージは、最大パケットサイズ（ローカルシングルホップ上のMTUから導出されるなど）に課せられる可能性のある制約に従って、単一のパケットに結合する必要があります（SHOULD）。これらのメッセージは、送信元ルーターまたは別のルーターから発信され、送信元ルーターによって転送されている可能性があります。発信元ルーターが異なるメッセージは、同じパケット内で送信するために結合される場合があります。 NHDP [RFC6130]を含むがこれに限定されない[RFC5444]を使用して定義された他のプロトコルからのメッセージは、同じパケット内の送信のために結合される場合があります。この仕様では、パケットヘッダーの内容を定義または使用していません。
Forwarded messages MAY be jittered as described in [RFC5148], including the observation that the forwarding jitter of all messages received in a single packet SHOULD be the same. The value of MAXJITTER used in jittering a forwarded message MAY be based on information in that message (in particular any Message TLVs with Type = INTERVAL_TIME or Type = VALIDITY_TIME) or otherwise SHOULD be with a maximum delay of F_MAXJITTER. A router MAY modify the jitter applied to a message in order to more efficiently combine messages in packets, as long as the maximum jitter is not exceeded.
転送されたメッセージは、[RFC5148]で説明されているようにジッターされる可能性があり、単一のパケットで受信されたすべてのメッセージの転送ジッターは同じである必要がある（SHOULD）。転送されたメッセージのジッタリングに使用されるMAXJITTERの値は、そのメッセージの情報（特に、Type = INTERVAL_TIMEまたはType = VALIDITY_TIMEのメッセージTLV）に基づく場合があり、そうでなければF_MAXJITTERの最大遅延を持つ必要があります。最大ジッターを超えない限り、ルーターはメッセージに適用されたジッターを変更して、メッセージをパケットでより効率的に組み合わせることができます。
This specification defines two Message TLVs and four Address Block TLVs.
この仕様では、2つのメッセージTLVと4つのアドレスブロックTLVを定義しています。
All references in this specification to TLVs that do not indicate a type extension assume Type Extension = 0. TLVs in processed messages with a type extension that is neither zero as so assumed, nor a specifically indicated non-zero type extension, are ignored.
タイプ拡張を示さないTLVへのこの仕様のすべての参照は、タイプ拡張= 0を想定しています。想定されたゼロではないタイプ拡張、または明確に示された非ゼロタイプ拡張の処理済みメッセージのTLVは無視されます。
Note that, following [RFC5444] and network byte order, bits in an octet are numbered from 0 (most significant) to 7 (least significant).
[RFC5444]とネットワークバイトオーダーに従って、オクテットのビットには0（最上位）から7（最下位）までの番号が付けられていることに注意してください。
The MPR_WILLING TLV is used in HELLO messages. A message MUST NOT contain more than one MPR_WILLING TLV.
MPR_WILLING TLVは、HELLOメッセージで使用されます。メッセージに複数のMPR_WILLING TLVを含めることはできません。
+-------------+--------------+--------------------------------------+
| Type | Value Length | Value |
+-------------+--------------+--------------------------------------+
| MPR_WILLING | 1 octet | Bits 0-3 encode the parameter |
| | | WILL_FLOODING; bits 4-7 encode the |
| | | parameter WILL_ROUTING. |
+-------------+--------------+--------------------------------------+
Table 1: MPR_WILLING TLV Definition
表1：MPR_WILLING TLV定義
The CONT_SEQ_NUM TLV is used in TC messages. A message MUST NOT contain more than one CONT_SEQ_NUM TLV.
CONT_SEQ_NUM TLVはTCメッセージで使用されます。メッセージには、複数のCONT_SEQ_NUM TLVを含めることはできません。
+--------------+--------------+-------------------------------------+
| Type | Value Length | Value |
+--------------+--------------+-------------------------------------+
| CONT_SEQ_NUM | 2 octets | The ANSN contained in the Neighbor |
| | | Information Base. |
+--------------+--------------+-------------------------------------+
Table 2: CONT_SEQ_NUM TLV Definition
表2：CONT_SEQ_NUM TLV定義
The LINK_METRIC TLV is used in HELLO messages and TC messages. It MAY use any type extension; only LINK_METRIC TLVs with type extension equal to LINK_METRIC_TYPE will be used by this specification. An address MUST NOT be associated with more than one link metric value for any given type extension, kind (link or neighbor), and direction using this TLV.
LINK_METRIC TLVは、HELLOメッセージとTCメッセージで使用されます。任意の型拡張を使用できます。この仕様では、タイプの拡張子がLINK_METRIC_TYPEと等しいLINK_METRIC TLVのみが使用されます。アドレスは、このTLVを使用して、特定のタイプ拡張、種類（リンクまたはネイバー）、および方向の複数のリンクメトリック値に関連付けられてはなりません（MUST NOT）。
+-------------+--------------+--------------------------------------+
| Type | Value Length | Value |
+-------------+--------------+--------------------------------------+
| LINK_METRIC | 2 octets | Bits 0-3 indicate kind(s) and |
| | | direction(s); bits 4-7 indicate |
| | | exponent (b); and bits 8-15 indicate |
| | | mantissa (a). |
+-------------+--------------+--------------------------------------+
Table 3: LINK_METRIC TLV Definition
表3：LINK_METRIC TLVの定義
The exponent and mantissa use the representation defined in Section 6. Each bit of the types and directions sub-field, if set ('1'), indicates that the link metric is of the indicated kind and direction. Any combination of these bits MAY be used.
指数と仮数は、セクション6で定義された表現を使用します。タイプと方向のサブフィールドの各ビットが設定されている場合（「1」）、リンクメトリックが指定された種類と方向であることを示します。これらのビットの任意の組み合わせを使用できます。
+-----+-----------------+-----------+
| Bit | Kind | Direction |
+-----+-----------------+-----------+
| 0 | Link metric | Incoming |
| 1 | Link metric | Outgoing |
| 2 | Neighbor metric | Incoming |
| 3 | Neighbor metric | Outgoing |
+-----+-----------------+-----------+
Table 4: LINK_METRIC TLV Types and Directions
表4：LINK_METRIC TLVのタイプと方向
The MPR TLV is used in HELLO messages and indicates that an address with which it is associated is of a symmetric 1-hop neighbor that has been selected as an MPR.
MPR TLVはHELLOメッセージで使用され、それが関連付けられているアドレスが、MPRとして選択された対称1ホップネイバーのものであることを示します。
+------+--------------+---------------------------------------------+
| Type | Value Length | Value |
+------+--------------+---------------------------------------------+
| MPR | 1 octet | FLOODING indicates that the corresponding |
| | | address is of a neighbor selected as a |
| | | flooding MPR; ROUTING indicates that the |
| | | corresponding address is of a neighbor |
| | | selected as a routing MPR; and FLOOD_ROUTE |
| | | indicates both (see Section 24.6). |
+------+--------------+---------------------------------------------+
Table 5: MPR TLV Definition
表5：MPR TLV定義
The NBR_ADDR_TYPE TLV is used in TC messages.
NBR_ADDR_TYPE TLVはTCメッセージで使用されます。
+---------------+--------------+------------------------------------+
| Type | Value Length | Value |
+---------------+--------------+------------------------------------+
| NBR_ADDR_TYPE | 1 octet | ORIGINATOR indicates that the |
| | | corresponding address (which MUST |
| | | have maximum prefix length) is an |
| | | originator address; ROUTABLE |
| | | indicates that the corresponding |
| | | network address is a routable |
| | | address of an interface; and |
| | | ROUTABLE_ORIG indicates that the |
| | | corresponding address is both (see |
| | | Section 24.6). |
+---------------+--------------+------------------------------------+
Table 6: NBR_ADDR_TYPE TLV Definition
表6：NBR_ADDR_TYPE TLV定義
If an address is both an originator address and a routable address, then it may be associated with either one Address Block TLV with Type := NBR_ADDR_TYPE and Value := ROUTABLE_ORIG, or with two Address Block TLVs with Type:= NBR_ADDR_TYPE, one with Value := ORIGINATOR and one with Value := ROUTABLE.
アドレスが発信元アドレスとルーティング可能なアドレスの両方である場合、Type：= NBR_ADDR_TYPEおよびValue：= ROUTABLE_ORIGの1つのアドレスブロックTLV、またはType：= NBR_ADDR_TYPEの2つのアドレスブロックTLV、1つは値を持つ：= ORIGINATORおよび値：= ROUTABLEを持つもの。
The GATEWAY TLV is used in TC messages. An address MUST NOT be associated with more than one hop count value using this TLV.
ゲートウェイTLVはTCメッセージで使用されます。このTLVを使用して、アドレスを複数のホップカウント値に関連付けることはできません。
+---------+--------------+-------------------------------------+
| Type | Value Length | Value |
+---------+--------------+-------------------------------------+
| GATEWAY | 1 octet | Number of hops to attached network. |
+---------+--------------+-------------------------------------+
Table 7: GATEWAY TLV Definition
表7：ゲートウェイTLV定義
All address objects included in a TC message according to this specification MUST be associated either with at least one TLV with Type := NBR_ADDR_TYPE or with a TLV with Type := GATEWAY, but not both. Any other address objects MAY be included in Address Blocks in a TC message but are ignored by this specification.
この仕様に従ってTCメッセージに含まれるすべてのアドレスオブジェクトは、Type：= NBR_ADDR_TYPEの少なくとも1つのTLVまたはType：= GATEWAYのTLVのいずれかに関連付ける必要がありますが、両方に関連付けることはできません。他のアドレスオブジェクトは、TCメッセージのアドレスブロックに含めることができますが、この仕様では無視されます。
This section describes the optimized flooding operation (MPR flooding) used when control messages, as instances of [RFC5444], are intended for MANET-wide distribution. This flooding mechanism defines when a received message is, or is not, processed and/or forwarded.
このセクションでは、[RFC5444]のインスタンスとして、制御メッセージがMANET全体の配布を目的としている場合に使用される最適化されたフラッディング操作（MPRフラッディング）について説明します。このフラッディングメカニズムは、受信したメッセージがいつ処理または転送されるか、または処理されないかを定義します。
This flooding mechanism is used by this protocol and MAY be used by extensions to this protocol that define, and hence own, other Message Types, to manage processing and/or forwarding of these messages. This specification contains elements (P_type, RX_type, F_type) required only for such usage.
このフラッディングメカニズムは、このプロトコルで使用されます。また、これらのメッセージの処理や転送を管理するために、他のメッセージタイプを定義して所有するこのプロトコルの拡張機能で使用される場合があります。この仕様には、このような使用にのみ必要な要素（P_type、RX_type、F_type）が含まれています。
This flooding mechanism is always used for TC messages (see Section 16). Received HELLO messages (see Section 15) are, unless invalid, always processed and never forwarded by this flooding mechanism. They thus do not need to be recorded in the Received Message Information Base.
このフラッディングメカニズムは常にTCメッセージに使用されます（セクション16を参照）。受信したHELLOメッセージ（セクション15を参照）は、無効でない限り、常に処理され、このフラッディングメカニズムによって転送されることはありません。したがって、受信メッセージ情報ベースに記録する必要はありません。
The processing selection and forwarding mechanisms are designed to only need to parse the Message Header in order to determine whether a message is to be processed and/or forwarded and not to have to parse the Message Body even if the message is forwarded (but not processed). An implementation MAY only parse the Message Body if necessary or MAY always parse the Message Body and reject the message if it cannot be so parsed or any other error is identified.
処理の選択と転送のメカニズムは、メッセージが処理または転送されるかどうかを判断するためにメッセージヘッダーを解析するだけでよく、メッセージが転送されても（処理されない）メッセージ本文を解析する必要がないように設計されています。 ）。実装は、必要な場合にのみメッセージ本文を解析するか、メッセージ本文を常に解析して、解析できない場合やその他のエラーが識別された場合にメッセージを拒否する場合があります。
An implementation MUST discard the message silently if it is unable to parse the Message Header or (if attempted) the Message Body, or if a message (other than a HELLO message) does not include a message sequence number.
実装は、メッセージヘッダーまたは（試行された場合）メッセージ本文を解析できない場合、またはメッセージ（HELLOメッセージ以外）にメッセージシーケンス番号が含まれていない場合、メッセージをサイレントに破棄する必要があります。
On receiving, on an OLSRv2 interface, a message of a type specified to be using this mechanism, which includes the TC messages defined in this specification, a router MUST perform the following:
この仕様で定義されているTCメッセージを含む、このメカニズムを使用するように指定されたタイプのメッセージをOLSRv2インターフェイスで受信すると、ルーターは次を実行する必要があります。
1. If the router recognizes from the originator address of the message that the message is one that the receiving router itself originated (i.e., the message originator address is the originator address of this router or is an O_orig_addr in an Originator Tuple), then the message MUST be silently discarded.
1. ルーターがメッセージの発信者アドレスから、メッセージが受信ルーター自体が発信したものであることを認識する場合（つまり、メッセージ発信者アドレスは、このルーターの発信者アドレスであるか、発信者タプルのO_orig_addrである）、メッセージは静かに捨てられる。
2. Otherwise:
2. さもないと：
1. If the message is of a type that may be processed, then the message is considered for processing according to Section 14.2.
1. メッセージが処理可能なタイプである場合、メッセージはセクション14.2に従って処理対象と見なされます。
2. If the message is of a type that may be forwarded, AND:
2. メッセージが転送可能なタイプである場合、かつ：
+ <msg-hop-limit> is present and <msg-hop-limit> > 1; AND
+ <msg-hop-count> is not present or <msg-hop-count> < 255,
+ <msg-hop-count>が存在しないか、<msg-hop-count> <255、
then the message is considered for forwarding according to Section 14.3.
その後、メッセージはセクション14.3に従って転送対象と見なされます。
If a message (the "current message") is considered for processing, then the following tasks MUST be performed:
メッセージ（「現在のメッセージ」）の処理が検討されている場合は、次のタスクを実行する必要があります。
1. If the sending address (i.e., the source address of the IP datagram containing the current message) does not match (taking into account any address prefix) a network address in an L_neighbor_iface_addr_list of a Link Tuple, with L_status = SYMMETRIC, in the Link Set for the OLSRv2 interface on which the current message was received (the "receiving interface"), then processing the current message is OPTIONAL. If the current message is not processed, then the following steps are not carried out.
1. 送信アドレス（つまり、現在のメッセージを含むIPデータグラムのソースアドレス）が（アドレスプレフィックスを考慮に入れて）リンクセットのL_status = SYMMETRICであるリンクタプルのL_neighbor_iface_addr_listのネットワークアドレスと一致しない場合現在のメッセージが受信されたOLSRv2インターフェイス（「受信インターフェイス」）の場合、現在のメッセージの処理はオプションです。現在のメッセージが処理されない場合、次の手順は実行されません。
2. If a Processed Tuple exists with:
2. 処理されたタプルが存在する場合：
* P_type = the Message Type of the current message; AND
* P_type =現在のメッセージのメッセージタイプ。そして
* P_orig_addr = the originator address of the current message; AND
* P_orig_addr =現在のメッセージの発信者アドレス。そして
* P_seq_number = the message sequence number of the current message,
* P_seq_number =現在のメッセージのメッセージシーケンス番号
then the current message MUST NOT be processed.
次に、現在のメッセージを処理してはなりません（MUST NOT）。
3. Otherwise:
3. さもないと：
1. Create a Processed Tuple in the Processed Set with:
1. 以下を使用して、処理済みセットに処理済みタプルを作成します。
+ P_type := the Message Type of the current message;
+ P_type：=現在のメッセージのメッセージタイプ。
+ P_orig_addr := the originator address of the current message;
+ P_orig_addr：=現在のメッセージの発信元アドレス。
+ P_seq_number := the sequence number of the current message;
+ P_seq_number：=現在のメッセージのシーケンス番号。
+ P_time := current time + P_HOLD_TIME.
+ P_time：=現在の時間+ P_HOLD_TIME。
2. Process the current message according to its Message Type. For a TC message, this is as defined in Section 16.3.
2. メッセージタイプに従って現在のメッセージを処理します。 TCメッセージの場合、これはセクション16.3で定義されています。
If a message (the "current message") is considered for forwarding, then the following tasks MUST be performed:
メッセージ（「現在のメッセージ」）の転送が検討されている場合は、次のタスクを実行する必要があります。
1. If the sending address (i.e., the source address of the IP datagram containing the current message) does not match (taking into account any address prefix) a network address in an L_neighbor_iface_addr_list of a Link Tuple, with L_status = SYMMETRIC, in the Link Set for the OLSRv2 interface on which the current message was received (the "receiving interface"), then the current message MUST be silently discarded.
1. 送信アドレス（つまり、現在のメッセージを含むIPデータグラムのソースアドレス）が（アドレスプレフィックスを考慮に入れて）リンクセットのL_status = SYMMETRICであるリンクタプルのL_neighbor_iface_addr_listのネットワークアドレスと一致しない場合現在のメッセージが受信されたOLSRv2インターフェイス（「受信インターフェイス」）の場合、現在のメッセージは通知なく破棄される必要があります。
2. Otherwise:
2. さもないと：
1. If a Received Tuple exists in the Received Set for the receiving interface, with:
1. 受信インターフェースの受信セットに受信タプルが存在する場合、次のようになります。
+ RX_type = the Message Type of the current message; AND
+ RX_type =現在のメッセージのメッセージタイプ。そして
+ RX_orig_addr = the originator address of the current message; AND
+ RX_orig_addr =現在のメッセージの発信元アドレス。そして
+ RX_seq_number = the sequence number of the current message,
+ RX_seq_number =現在のメッセージのシーケンス番号、
then the current message MUST be silently discarded.
その後、現在のメッセージは黙って破棄されなければなりません。
2. Otherwise:
2. さもないと：
1. Create a Received Tuple in the Received Set for the receiving interface with:
1. 以下を使用して、受信インターフェースの受信セットに受信タプルを作成します。
- RX_type := the Message Type of the current message;
- RX_type：=現在のメッセージのメッセージタイプ。
- RX_orig_addr := originator address of the current message;
- RX_orig_addr：=現在のメッセージの発信元アドレス。
- RX_seq_number := sequence number of the current message;
- RX_seq_number：=現在のメッセージのシーケンス番号。
- RX_time := current time + RX_HOLD_TIME.
- RX_time：=現在時刻+ RX_HOLD_TIME。
2. If a Forwarded Tuple exists with:
2. 転送されたタプルが存在する場合：
- F_type = the Message Type of the current message; AND
- F_type =現在のメッセージのメッセージタイプ。そして
- F_orig_addr = the originator address of the current message; AND
- F_orig_addr =現在のメッセージの発信者アドレス。そして
- F_seq_number = the sequence number of the current message,
- F_seq_number =現在のメッセージのシーケンス番号、
then the current message MUST be silently discarded.
その後、現在のメッセージは黙って破棄されなければなりません。
3. Otherwise, if the sending address matches (taking account of any address prefix), any network address in an L_neighbor_iface_addr_list of a Link Tuple in the Link Set for the receiving OLSRv2 interface that has L_status = SYMMETRIC and L_mpr_selector = true, then:
3. それ以外の場合、送信アドレスが一致すると（任意のアドレスプレフィックスを考慮に入れて）、L_status = SYMMETRICおよびL_mpr_selector = trueである受信OLSRv2インターフェイスのリンクセット内のリンクタプルのL_neighbor_iface_addr_list内の任意のネットワークアドレス、次に：
1. Create a Forwarded Tuple in the Forwarded Set with:
1. 次のコマンドを使用して、転送セットに転送タプルを作成します。
o F_type := the Message Type of the current message;
o F_type：=現在のメッセージのメッセージタイプ。
o F_orig_addr := originator address of the current message;
o F_orig_addr：=現在のメッセージの発信元アドレス。
o F_seq_number := sequence number of the current message;
o F_seq_number：=現在のメッセージのシーケンス番号。
o F_time := current time + F_HOLD_TIME.
o F_time：=現在時刻+ F_HOLD_TIME。
2. The Message Header of the current message is modified by:
2. 現在のメッセージのメッセージヘッダーは、次のように変更されます。
o Decrement <msg-hop-limit> in the Message Header by 1; AND
o メッセージヘッダーの<msg-hop-limit>を1減らします。そして
o If present, increment <msg-hop-count> in the Message Header by 1.
o 存在する場合、メッセージヘッダーの<msg-hop-count>を1増やします。
3. The message is transmitted over all OLSRv2 interfaces, as described in Section 13.
3. セクション13で説明するように、メッセージはすべてのOLSRv2インターフェイスを介して送信されます。
4. Otherwise, the current message MUST be silently discarded.
4. そうでなければ、現在のメッセージは黙って破棄されなければなりません（MUST）。
The HELLO Message Type is owned by NHDP [RFC6130], and HELLO messages are thus generated, transmitted, received, and processed by NHDP. This protocol, as permitted by [RFC6130], also uses HELLO messages, including adding to HELLO message generation and implementing additional processing based on received HELLO messages. HELLO messages are not forwarded by NHDP [RFC6130] or by OLSRv2.
HELLOメッセージタイプはNHDP [RFC6130]が所有しているため、NHDPによってHELLOメッセージが生成、送信、受信、処理されます。このプロトコルは、[RFC6130]で許可されているように、HELLOメッセージ生成への追加や、受信したHELLOメッセージに基づく追加処理の実装など、HELLOメッセージも使用します。 HELLOメッセージは、NHDP [RFC6130]またはOLSRv2によって転送されません。
HELLO messages sent over OLSRv2 interfaces are generated as defined in [RFC6130] and then modified as described in this section. HELLO messages sent on other MANET interfaces are not modified by this specification.
OLSRv2インターフェイスを介して送信されるHELLOメッセージは、[RFC6130]の定義に従って生成され、このセクションで説明するように変更されます。他のMANETインターフェイスで送信されるHELLOメッセージは、この仕様では変更されません。
HELLO messages sent over OLSRv2 interfaces are extended by adding the following elements:
OLSRv2インターフェイスを介して送信されるHELLOメッセージは、次の要素を追加することによって拡張されます。
o A message originator address, recording this router's originator address. This MUST use a <msg-orig-addr> element, unless:
o このルーターの発信元アドレスを記録するメッセージ発信元アドレス。次の場合を除き、これは<msg-orig-addr>要素を使用する必要があります。
* The message specifies only a single local interface address (i.e., contains only one address object that is associated with an Address Block TLV with Type = LOCAL_IF and that has no prefix length or a maximum prefix length) that will then be used as the message originator address; OR
* メッセージは、メッセージ発信元として使用される単一のローカルインターフェイスアドレスのみを指定します（つまり、Type = LOCAL_IFのアドレスブロックTLVに関連付けられ、プレフィックス長または最大プレフィックス長を持たないアドレスオブジェクトを1つだけ含みます）。住所;または
* The message does not include any local interface network addresses (i.e., has no address objects associated with an Address Block TLV with Type = LOCAL_IF), as permitted by the specification in [RFC6130], when the router that generated the HELLO message has only one interface address and will use that as the sending address of the IP datagram in which the HELLO message is contained. In this case, that address will be used as the message originator address.
* [RFC6130]の仕様で許可されているように、HELLOメッセージを生成したルータに1つしかない場合、メッセージにはローカルインターフェイスネットワークアドレスは含まれません（つまり、Type = LOCAL_IFのアドレスブロックTLVに関連付けられたアドレスオブジェクトはありません）。インターフェイスアドレス。これを、HELLOメッセージが含まれるIPデータグラムの送信アドレスとして使用します。この場合、そのアドレスがメッセージの発信元アドレスとして使用されます。
o A Message TLV with Type := MPR_WILLING MUST be included.
o Type：= MPR_WILLINGのメッセージTLVを含める必要があります。
o The following cases associate Address Block TLVs with one or more addresses from a Link Tuple or a Neighbor Tuple if these are included in the HELLO message. In each case, the TLV MUST be associated with at least one address object for an address from the relevant Tuple; the TLV MAY be associated with more such addresses (including a copy of that address object, possibly not itself associated with any other indicated TLVs, in the same or a different Address Block). These additional TLVs MUST NOT be associated with any other addresses in a HELLO message that will be processed by NHDP [RFC6130].
o次のケースでは、アドレスブロックTLVがリンクタプルまたはネイバータプルからの1つ以上のアドレスに関連付けられます（これらのアドレスがHELLOメッセージに含まれている場合）。いずれの場合も、TLVは関連するタプルからのアドレスの少なくとも1つのアドレスオブジェクトに関連付けられている必要があります。 TLVは、より多くのそのようなアドレスに関連付けられている可能性があります（そのアドレスオブジェクトのコピーを含み、それ自体が同じまたは異なるアドレスブロック内の他の示されたTLVに関連付けられていない可能性があります）。これらの追加のTLVは、NHDP [RFC6130]によって処理されるHELLOメッセージ内の他のアドレスと関連付けてはいけません（MUST NOT）。
* For each Link Tuple for which L_in_metric != UNKNOWN_METRIC and for which one or more addresses in its L_neighbor_iface_addr_list are included as address objects with an associated Address Block TLV with Type = LINK_STATUS and Value = HEARD or Value = SYMMETRIC, at least one of these addresses MUST be associated with an Address Block TLV with Type := LINK_METRIC indicating an incoming link metric with value L_in_metric.
* L_in_metric！= UNKNOWN_METRICであり、そのL_neighbor_iface_addr_listの1つ以上のアドレスが、タイプ= LINK_STATUSおよび値= HEARDまたは値= SYMMETRICの関連付けられたアドレスブロックTLVを持つアドレスオブジェクトとして含まれているリンクタプルごとに、これらのアドレスの少なくとも1つType：= LINK_METRICのアドレスブロックTLVに関連付けられ、値がL_in_metricの着信リンクメトリックを示す必要があります。
* For each Link Tuple for which L_out_metric != UNKNOWN_METRIC and for which one or more addresses in its L_neighbor_iface_addr_list are included as address objects with an associated Address Block TLV with Type = LINK_STATUS and Value = SYMMETRIC, at least one of these addresses MUST be associated with an Address Block TLV with Type := LINK_METRIC indicating an outgoing link metric with value L_out_metric.
* L_out_metric！= UNKNOWN_METRICであり、そのL_neighbor_iface_addr_list内の1つ以上のアドレスが、タイプ= LINK_STATUSおよび値= SYMMETRICの関連付けられたアドレスブロックTLVを持つアドレスオブジェクトとして含まれているリンクタプルごとに、これらのアドレスの少なくとも1つが関連付けられている必要があります。 Type：= LINK_METRICのアドレスブロックTLV。値がL_out_metricの発信リンクメトリックを示します。
* For each Neighbor Tuple for which N_symmetric = true and for which one or more addresses in its N_neighbor_addr_list are included as address objects with an associated Address Block TLV with Type = LINK_STATUS or Type = OTHER_NEIGHB and Value = SYMMETRIC, at least one of these addresses MUST be associated with an Address Block TLV with Type := LINK_METRIC indicating an incoming neighbor metric with value N_in_metric.
* N_symmetric = trueであり、そのN_neighbor_addr_list内の1つ以上のアドレスが、Type = LINK_STATUSまたはType = OTHER_NEIGHBおよびValue = SYMMETRICの関連付けられたアドレスブロックTLVを持つアドレスオブジェクトとして含まれているネイバータプルごとに、これらのアドレスの少なくとも1つType：= LINK_METRICのアドレスブロックTLVに関連付けられ、値がN_in_metricの着信ネイバーメトリックを示します。
* For each Neighbor Tuple for which N_symmetric = true and for which one or more addresses in its N_neighbor_addr_list are included as address objects with an associated Address Block TLV with Type = LINK_STATUS or Type = OTHER_NEIGHB and Value = SYMMETRIC, at least one of these addresses MUST be associated with an Address Block TLV with Type := LINK_METRIC indicating an outgoing neighbor metric with value N_out_metric.
* N_symmetric = trueであり、そのN_neighbor_addr_list内の1つ以上のアドレスが、Type = LINK_STATUSまたはType = OTHER_NEIGHBおよびValue = SYMMETRICの関連付けられたアドレスブロックTLVを持つアドレスオブジェクトとして含まれているネイバータプルごとに、これらのアドレスの少なくとも1つType：= LINK_METRICのアドレスブロックTLVに関連付けられ、値がN_out_metricの発信ネイバーメトリックを示します。
* For each Neighbor Tuple with N_flooding_mpr = true and for which one or more network addresses in its N_neighbor_addr_list are included as address objects in the HELLO message with an associated Address Block TLV with Type = LINK_STATUS and Value = SYMMETRIC, at least one of these addresses MUST be associated with an Address Block TLV with Type := MPR and Value := FLOODING or Value := FLOOD_ROUTE.
* N_flooding_mpr = trueであり、N_neighbor_addr_listの1つ以上のネットワークアドレスが、タイプ= LINK_STATUSおよび値= SYMMETRICの関連付けられたアドレスブロックTLVを持つHELLOメッセージのアドレスオブジェクトとして含まれているネイバータプルごとに、これらのアドレスの少なくとも1つが必須タイプ：= MPRおよび値：= FLOODINGまたは値：= FLOOD_ROUTEのアドレスブロックTLVに関連付けられている。
* For each Neighbor Tuple with N_routing_mpr = true and for which one or more network addresses in its N_neighbor_addr_list are included as address objects in the HELLO message with an associated Address Block TLV with Type = LINK_STATUS and Value = SYMMETRIC, at least one of these addresses MUST be associated with an Address Block TLV with Type := MPR and Value := ROUTING or Value := FLOOD_ROUTE.
* N_routing_mpr = trueであり、N_neighbor_addr_listの1つ以上のネットワークアドレスが、タイプ= LINK_STATUSおよび値= SYMMETRICの関連付けられたアドレスブロックTLVを持つHELLOメッセージのアドレスオブジェクトとして含まれているネイバータプルごとに、これらのアドレスの少なくとも1つタイプ：= MPRおよび値：= ROUTINGまたは値：= FLOOD_ROUTEのアドレスブロックTLVに関連付けられている。
HELLO messages are scheduled and transmitted by NHDP [RFC6130]. This protocol MAY require that an additional HELLO message be sent on each OLSRv2 interface when either of the router's sets of MPRs changes, in addition to the cases specified in [RFC6130] and subject to the constraints specified in [RFC6130] (notably on minimum HELLO message transmission intervals).
HELLOメッセージは、NHDP [RFC6130]によってスケジュールされ、送信されます。このプロトコルでは、[RFC6130]で指定されたケースに加えて、[RFC6130]で指定された制約（特に最小HELLO）に加えて、ルーターのMPRのいずれかのセットが変更されたときに、各OLSRv2インターフェイスで追加のHELLOメッセージを送信する必要がありますメッセージ送信間隔）。
When received on an OLSRv2 interface, HELLO messages are made available to this protocol in two ways, both as permitted by [RFC6130]:
OLSRv2インターフェイスで受信されると、HELLOメッセージはこのプロトコルで2つの方法で利用可能になります。どちらも[RFC6130]で許可されています。
o Such received HELLO messages MUST be made available to this protocol on reception, which allows them to be discarded before being processed by NHDP [RFC6130], for example, if the information added to the HELLO message by this specification is inconsistent.
o そのような受信されたHELLOメッセージは、受信時にこのプロトコルで利用可能にする必要があります。これにより、たとえば、この仕様によってHELLOメッセージに追加された情報に一貫性がない場合、NHDP [RFC6130]によって処理される前にそれらを破棄できます。
o Such received HELLO messages MUST be made available to OLSRv2 after NHDP [RFC6130] has completed its processing thereof, unless discarded as malformed by NHDP, for processing by OLSRv2.
o そのような受信されたHELLOメッセージは、NHDP [RFC6130]がその処理を完了した後、OLSRv2による処理のためにNHDPによって不正な形式として破棄されない限り、OLSRv2で利用可能にする必要があります。
In addition to the reasons specified in [RFC6130] for discarding a HELLO message on reception, a HELLO message received on an OLSRv2 interface MUST be discarded before processing by NHDP [RFC6130] or this specification if it:
[RFC6130]で指定されている、受信時にHELLOメッセージを破棄する理由に加えて、OLSRv2インターフェイスで受信したHELLOメッセージは、NHDP [RFC6130]またはこの仕様で処理する前に破棄する必要があります。
o Has more than one Message TLV with Type = MPR_WILLING.
o Type = MPR_WILLINGのメッセージTLVが複数あります。
o Has a message originator address, or a network address corresponding to an address object associated with an Address Block TLV with Type = LOCAL_IF, that is partially owned by this router. (Some of these cases are already excluded by [RFC6130].)
o このルーターによって部分的に所有されているメッセージ発信元アドレス、またはType = LOCAL_IFのアドレスブロックTLVに関連付けられたアドレスオブジェクトに対応するネットワークアドレスを持っている（これらのケースのいくつかはすでに[RFC6130]によって除外されています。）
o Includes any address object associated with an Address Block TLV with Type = LINK_STATUS or Type = OTHER_NEIGHB that overlaps the message's originator address.
o Type = LINK_STATUSまたはType = OTHER_NEIGHBのアドレスブロックTLVに関連付けられた、メッセージの発信者アドレスと重複するアドレスオブジェクトが含まれます。
o Contains any address that will be processed by NHDP [RFC6130] that is associated, using the same or different address objects, with two different values of link metric with the same kind and direction using a TLV with Type = LINK_METRIC and Type Extension = LINK_METRIC_TYPE. This also applies to different addresses that are both of the OLSRv2 interface on which the HELLO message was received.
o 同じまたは異なるアドレスオブジェクトを使用して、Type = LINK_METRICおよびType Extension = LINK_METRIC_TYPEのTLVを使用する同じ種類と方向のリンクメトリックの2つの異なる値に関連付けられたNHDP [RFC6130]によって処理されるアドレスが含まれます。これは、HELLOメッセージが受信されたOLSRv2インターフェイスの両方である異なるアドレスにも適用されます。
o Contains any address object associated with an Address Block TLV with Type = MPR that is not also associated with an Address Block TLV with Type = LINK_STATUS and Value = SYMMETRIC (including using a different copy of that address object in the same or a different Address Block).
o タイプ= LINK_STATUSおよび値= SYMMETRICのアドレスブロックTLVにも関連付けられていない、タイプ= MPRのアドレスブロックTLVに関連付けられたアドレスオブジェクトが含まれます（同じまたは異なるアドレスブロックでそのアドレスオブジェクトの別のコピーを使用することを含む） ）。
HELLO messages are first processed as specified in [RFC6130]. That processing includes identifying (or creating) a Link Tuple and a Neighbor Tuple corresponding to the originator of the HELLO message (the "current Link Tuple" and the "current Neighbor Tuple"). After this, the following processing MUST also be performed if the HELLO message is received on an OLSRv2 interface and contains a TLV with Type = MPR_WILLING:
HELLOメッセージは最初に[RFC6130]で指定されているように処理されます。その処理には、HELLOメッセージの発信者に対応するリンクタプルとネイバータプル（「現在のリンクタプル」と「現在のネイバータプル」）の識別（または作成）が含まれます。この後、HELLOメッセージがOLSRv2インターフェイスで受信され、Type = MPR_WILLINGのTLVが含まれている場合は、次の処理も実行する必要があります。
1. If the HELLO message has a well-defined message originator address, i.e., has an <msg-orig-addr> element or has zero or one network addresses associated with a TLV with Type = LOCAL_IF:
1. HELLOメッセージに明確に定義されたメッセージ発信者アドレスがある場合、つまり<msg-orig-addr>要素があるか、Type = LOCAL_IFのTLVに関連付けられているネットワークアドレスが0個または1個ある場合：
1. Remove any Neighbor Tuple, other than the current Neighbor Tuple, with N_orig_addr = message originator address, taking any consequent action (including removing one or more Link Tuples) as specified in [RFC6130].
1. [RFC6130]で指定されている結果のアクション（1つ以上のリンクタプルの削除を含む）を実行し、N_orig_addr =メッセージの発信元アドレスを使用して、現在のネイバータプル以外のネイバータプルを削除します。
2. The current Link Tuple is then updated according to:
2. 現在のリンクタプルは、次のように更新されます。
1. Update L_in_metric and L_out_metric as described in Section 15.3.2.1;
1. セクション15.3.2.1の説明に従って、L_in_metricおよびL_out_metricを更新します。
2. Update L_mpr_selector as described in Section 15.3.2.3.
2. セクション15.3.2.3の説明に従って、L_mpr_selectorを更新します。
3. The current Neighbor Tuple is then updated according to:
3. 現在のネイバータプルは、次のように更新されます。
1. N_orig_addr := message originator address;
1. N_orig_addr：=メッセージの発信元アドレス。
2. Update N_in_metric and N_out_metric as described in Section 15.3.2.1;
2. セクション15.3.2.1の説明に従って、N_in_metricおよびN_out_metricを更新します。
3. Update N_will_flooding and N_will_routing as described in Section 15.3.2.2;
3. セクション15.3.2.2の説明に従って、N_will_floodingおよびN_will_routingを更新します。
4. Update N_mpr_selector as described in Section 15.3.2.3.
4. セクション15.3.2.3の説明に従って、N_mpr_selectorを更新します。
4. All 2-Hop Tuples that were updated as described in [RFC6130] are then updated according to:
4. [RFC6130]で説明されているように更新されたすべての2ホップタプルは、以下に従って更新されます。
1. Update N2_in_metric and N2_out_metric as described in Section 15.3.2.1.
1. セクション15.3.2.1の説明に従って、N2_in_metricおよびN2_out_metricを更新します。
2. If there are any changes to the router's Information Bases, then perform the processing defined in Section 17.
2. ルーターの情報ベースに変更がある場合は、セクション17で定義されている処理を実行します。
For each address in a received HELLO message with an associated TLV with Type = LINK_STATUS and Value = HEARD or Value = SYMMETRIC, an incoming (to the message originator) link metric value is defined. If the HELLO message contains a TLV with Type = LINK_METRIC and Type Extension = LINK_METRIC_TYPE that associates that address value with a metric value of the appropriate kind (link) and direction (incoming) of metric, then the incoming link metric is that metric value; otherwise, the incoming link metric is defined as UNKNOWN_METRIC.
Type = LINK_STATUSおよびValue = HEARDまたはValue = SYMMETRICのTLVが関連付けられている受信したHELLOメッセージの各アドレスに対して、（メッセージの発信者への）着信リンクメトリック値が定義されます。 HELLOメッセージにType = LINK_METRICおよびType Extension = LINK_METRIC_TYPEのTLVが含まれ、そのアドレス値が適切な種類（リンク）および方向（受信）のメトリック値に関連付けられている場合、着信リンクメトリックはそのメトリック値です。それ以外の場合、着信リンクメトリックはUNKNOWN_METRICとして定義されます。
For each address in a received HELLO message with an associated TLV with Type = LINK_STATUS and Value = SYMMETRIC, an outgoing (from the message originator) link metric value is defined. If the HELLO message contains a TLV with Type = LINK_METRIC and Type Extension = LINK_METRIC_TYPE that associates that address value with a metric value of the appropriate kind (link) and direction (outgoing) of metric, then the outgoing link metric is that metric value; otherwise, the outgoing link metric is defined as UNKNOWN_METRIC.
Type = LINK_STATUSおよびValue = SYMMETRICのTLVが関連付けられている受信したHELLOメッセージの各アドレスに対して、（メッセージの発信者からの）発信リンクメトリック値が定義されます。 HELLOメッセージにType = LINK_METRICおよびType Extension = LINK_METRIC_TYPEのTLVが含まれ、そのアドレス値を適切な種類（リンク）および方向（送信）のメトリック値に関連付ける場合、送信リンクメトリックはそのメトリック値です。それ以外の場合、発信リンクメトリックはUNKNOWN_METRICとして定義されます。
For each address in a received HELLO message with an associated TLV with Type = LINK_STATUS or Type = OTHER_NEIGHB and Value = SYMMETRIC, an incoming (to the message originator) neighbor metric value is defined. If the HELLO message contains a TLV with Type = LINK_METRIC and Type Extension = LINK_METRIC_TYPE that associates that address value with a metric value of the appropriate kind (neighbor) and direction (incoming) of metric, then the incoming neighbor metric is that metric value; otherwise, the incoming neighbor metric is defined as UNKNOWN_METRIC.
Type = LINK_STATUSまたはType = OTHER_NEIGHBおよびValue = SYMMETRICのTLVが関連付けられている受信したHELLOメッセージの各アドレスに対して、（メッセージの発信元への）着信ネイバーメトリック値が定義されます。 HELLOメッセージにType = LINK_METRICおよびType Extension = LINK_METRIC_TYPEのTLVが含まれ、そのアドレス値が適切な種類（ネイバー）および方向（受信）のメトリック値に関連付けられている場合、着信ネイバーメトリックはそのメトリック値です。それ以外の場合、着信ネイバーメトリックはUNKNOWN_METRICとして定義されます。
For each address in a received HELLO message with an associated TLV with Type = LINK_STATUS or Type = OTHER_NEIGHB and Value = SYMMETRIC, an outgoing (from the message originator) neighbor metric value is defined. If the HELLO message contains a TLV with Type = LINK_METRIC and Type Extension = LINK_METRIC_TYPE that associates that address value with a metric value of the appropriate kind (neighbor) and direction (outgoing) of metric, then the outgoing neighbor metric is that metric value; otherwise, the outgoing neighbor metric is defined as UNKNOWN_METRIC.
Type = LINK_STATUSまたはType = OTHER_NEIGHBおよびValue = SYMMETRICのTLVが関連付けられている受信したHELLOメッセージの各アドレスに対して、（メッセージの発信元からの）発信ネイバーメトリック値が定義されます。 HELLOメッセージにType = LINK_METRICおよびType Extension = LINK_METRIC_TYPEのTLVが含まれ、そのアドレス値を適切な種類（ネイバー）および方向（送信）のメトリック値に関連付ける場合、送信ネイバーメトリックはそのメトリック値です。それ以外の場合、発信ネイバーメトリックはUNKNOWN_METRICとして定義されます。
The link metric elements L_in_metric and L_out_metric in a Link Tuple are updated according to the following:
リンクタプル内のリンクメトリック要素L_in_metricおよびL_out_metricは、以下に従って更新されます。
o For any Link Tuple, L_in_metric MAY be set to any representable value by a process outside this specification at any time. L_in_metric MUST be so set whenever L_status becomes equal to HEARD or SYMMETRIC (if no other value is available, then the value MAXIMUM_METRIC MUST be used). Setting L_in_metric MAY use information based on the receipt of a packet including a HELLO message that causes the creation or updating of the Link Tuple.
o リンクタプルの場合、L_in_metricは、この仕様外のプロセスによっていつでも表現可能な値に設定できます（MAY）。 L_in_metricは、L_statusがHEARDまたはSYMMETRICと等しくなるたびに設定する必要があります（他に使用できる値がない場合は、値MAXIMUM_METRICを使用する必要があります）。 L_in_metricの設定は、リンクタプルの作成または更新を引き起こすHELLOメッセージを含むパケットの受信に基づく情報を使用する場合があります。
o When, as specified in [RFC6130], a Link Tuple is updated (possibly immediately after being created) due to the receipt of a HELLO message, if L_status = SYMMETRIC, then L_out_metric is set equal to the incoming link metric for any included address of the interface on which the HELLO message was received. (Note that the rules for discarding HELLO messages in Section 15.3.1 make this value unambiguous.) If there is any such address, but no such link metric, then L_out_metric is set to UNKNOWN_METRIC.
o [RFC6130]で指定されているように、HELLOメッセージの受信が原因でリンクタプルが更新された場合（おそらく作成直後）、L_status = SYMMETRICの場合、L_out_metricは、含まれているすべてのアドレスの受信リンクメトリックに等しく設定されます。 HELLOメッセージが受信されたインターフェース。 （セクション15.3.1のHELLOメッセージを破棄するための規則により、この値は明確になります。）そのようなアドレスはあるが、そのようなリンクメトリックがない場合、L_out_metricはUNKNOWN_METRICに設定されます。
The neighbor metric elements N_in_metric and N_out_metric in a Neighbor Tuple are updated according to Section 17.3.
近隣タプルの近隣メトリック要素N_in_metricおよびN_out_metricは、セクション17.3に従って更新されます。
The metric elements N2_in_metric and N2_out_metric in any 2-Hop Tuple updated as defined in [RFC6130] are updated to equal the incoming neighbor metric and outgoing neighbor metric, respectively, associated with the corresponding N2_2hop_addr. If there are no such metrics, then these elements are set to UNKNOWN_METRIC.
[RFC6130]で定義されているように更新された2ホップタプル内のメトリック要素N2_in_metricおよびN2_out_metricは、対応するN2_2hop_addrに関連付けられた着信ネイバーメトリックおよび発信ネイバーメトリックにそれぞれ等しくなるように更新されます。そのようなメトリックがない場合、これらの要素はUNKNOWN_METRICに設定されます。
N_will_flooding and N_will_routing in the current Neighbor Tuple are updated using the Message TLV with Type = MPR_WILLING (note that this must be present) as follows: o N_will_flooding := bits 0-3 of the value of that TLV; AND
現在の近隣タプルのN_will_floodingとN_will_routingは、Type = MPR_WILLINGのメッセージTLVを使用して更新されます（これは存在する必要があることに注意してください）。o N_will_flooding：=そのTLVの値のビット0〜3。そして
o N_will_routing := bits 4-7 of the value of that TLV.
o N_will_routing：=そのTLVの値のビット4〜7。
(Each being in the range 0 to 15, i.e., WILL_NEVER to WILL_ALWAYS.)
（それぞれ0から15の範囲、つまり、WILL_NEVERからWILL_ALWAYSです。）
L_mpr_selector is updated as follows:
L_mpr_selectorは次のように更新されます。
1. If a router finds an address object representing any of its relevant local interface network addresses (i.e., those contained in the I_local_iface_addr_list of an OLSRv2 interface) with an associated Address Block TLV with Type = MPR and Value = FLOODING or Value = FLOOD_ROUTE in the HELLO message (indicating that the originating router has selected the receiving router as a flooding MPR), then, for the current Link Tuple:
1. ルーターが、関連するローカルインターフェイスネットワークアドレス（つまり、OLSRv2インターフェイスのI_local_iface_addr_listに含まれるアドレス）を表すアドレスオブジェクトを、HELLOのタイプ= MPRおよび値= FLOODINGまたは値= FLOOD_ROUTEのアドレスブロックTLVに関連付けて検出した場合メッセージ（送信元ルーターが受信ルーターをフラッディングMPRとして選択したことを示します）、現在のリンクタプルの場合：
* L_mpr_selector := true.
* L_mpr_selector：= true。
2. Otherwise (i.e., if no such address object and Address Block TLV was found), if a router finds an address object representing any of its relevant local interface network addresses (i.e., those contained in the I_local_iface_addr_list of an OLSRv2 interface) with an associated Address Block TLV with Type = LINK_STATUS and Value = SYMMETRIC in the HELLO message, then, for the current Link Tuple:
2. それ以外の場合（つまり、そのようなアドレスオブジェクトとアドレスブロックTLVが見つからなかった場合）、ルーターが、関連するローカルインターフェイスネットワークアドレス（OLSRv2インターフェイスのI_local_iface_addr_listに含まれるアドレス）を表すアドレスオブジェクトと、関連付けられたアドレスを見つけた場合HELLOメッセージでType = LINK_STATUSおよびValue = SYMMETRICのTLVをブロックしてから、現在のリンクタプルについて次のようにします。
* L_mpr_selector := false.
* L_mpr_selector：= false。
N_mpr_selector is updated as follows:
N_mpr_selectorは次のように更新されます。
1. If a router finds an address object representing any of its relevant local interface network addresses (those contained in the I_local_iface_addr_list of an OLSRv2 interface) with an associated Address Block TLV with Type = MPR and Value = ROUTING or Value = FLOOD_ROUTE in the HELLO message (indicating that the originating router has selected the receiving router as a routing MPR), then, for the current Neighbor Tuple:
1. ルーターが、関連するローカルインターフェイスネットワークアドレス（OLSRv2インターフェイスのI_local_iface_addr_listに含まれるもの）を表すアドレスオブジェクトを見つけ、HELLOメッセージでType = MPRおよびValue = ROUTINGまたはValue = FLOOD_ROUTEのアドレスブロックTLVが関連付けられている場合（発信元ルーターが受信側ルーターをルーティングMPRとして選択したことを示します）、現在のネイバータプルの場合：
* N_mpr_selector := true;
* N_mpr_selector：= true;
* N_advertised := true.
* N_advertised：= true。
2. Otherwise (i.e., if no such address object and Address Block TLV was found), if a router finds an address object representing any of its relevant local interface network addresses (those contained in the I_local_iface_addr_list of an OLSRv2 interface) with an associated Address Block TLV with Type = LINK_STATUS and Value = SYMMETRIC in the HELLO message, then, for the current Neighbor Tuple:
2.それ以外の場合（つまり、そのようなアドレスオブジェクトとアドレスブロックTLVが見つからなかった場合）、ルーターが関連するローカルインターフェイスネットワークアドレス（OLSRv2インターフェイスのI_local_iface_addr_listに含まれるもの）を表すアドレスオブジェクトを、関連付けられたアドレスとともに見つけた場合HELLOメッセージでType = LINK_STATUSおよびValue = SYMMETRICのTLVをブロックしてから、現在のネイバータプルについて次のようにします。
* N_mpr_selector := false;
* N_mpr_selector：= false;
* The router MAY also set N_advertised := false.
* ルーターはN_advertised：= falseも設定できます（MAY）。
This protocol defines, and hence owns, the TC Message Type (see Section 24). Thus, as specified in [RFC5444], this protocol generates and transmits all TC messages, receives all TC messages, and is responsible for determining whether and how each TC message is to be processed (updating the Topology Information Base) and/or forwarded, according to this specification.
このプロトコルは、TCメッセージタイプを定義し、したがって所有します（セクション24を参照）。したがって、[RFC5444]で指定されているように、このプロトコルはすべてのTCメッセージを生成して送信し、すべてのTCメッセージを受信し、各TCメッセージを処理する（トポロジ情報ベースを更新する）か、転送するかを決定します。この仕様によると。
A TC message is a message as defined in [RFC5444]. A generated TC message MUST contain the following elements as defined in [RFC5444]:
TCメッセージは、[RFC5444]で定義されているメッセージです。生成されたTCメッセージには、[RFC5444]で定義されている次の要素を含める必要があります。
o A message originator address, recording this router's originator address. This MUST use a <msg-orig-addr> element.
o このルーターの発信元アドレスを記録するメッセージ発信元アドレス。 <msg-orig-addr>要素を使用する必要があります。
o <msg-seq-num> element containing the message sequence number.
o メッセージのシーケンス番号を含む<msg-seq-num>要素。
o A <msg-hop-limit> element, containing TC_HOP_LIMIT. A router MAY use the same or different values of TC_HOP_LIMIT in its TC messages (see Section 5.4.7).
o TC_HOP_LIMITを含む<msg-hop-limit>要素。ルーターは、TCメッセージでTC_HOP_LIMITの同じ値または異なる値を使用できます（セクション5.4.7を参照）。
o A <msg-hop-count> element, containing zero, if the message contains a TLV with either Type = VALIDITY_TIME or Type = INTERVAL_TIME (as specified in [RFC5497]) indicating more than one time value according to distance. A TC message MAY contain such a <msg-hop-count> element even if it does not need to.
o 距離に応じて複数の時間値を示すType = VALIDITY_TIMEまたはType = INTERVAL_TIME（[RFC5497]で指定）のいずれかのTLVがメッセージに含まれている場合、ゼロを含む<msg-hop-count>要素。 TCメッセージには、必要がない場合でも、そのような<msg-hop-count>要素が含まれる場合があります。
o A single Message TLV with Type := CONT_SEQ_NUM and Value := ANSN from the Neighbor Information Base. If the TC message is complete, then this Message TLV MUST have Type Extension := COMPLETE; otherwise, it MUST have Type Extension := INCOMPLETE. (Exception: a TC message MAY omit such a Message TLV if the TC message does not include any address objects with an associated Address Block TLV with Type = NBR_ADDR_TYPE or Type = GATEWAY.)
o タイプ：= CONT_SEQ_NUMおよび値：= ANSNの単一のメッセージTLVがネイバー情報ベースから取得されます。 TCメッセージが完了している場合、このメッセージTLVにはType Extension：= COMPLETE;が必要です。それ以外の場合は、Type Extension：= INCOMPLETEが必要です。 （例外：TCメッセージに、Type = NBR_ADDR_TYPEまたはType = GATEWAYのアドレスブロックTLVが関連付けられているアドレスオブジェクトが含まれていない場合、そのようなメッセージTLVは省略できます。）
o A single Message TLV with Type := VALIDITY_TIME, as specified in [RFC5497]. If all TC messages are sent with the same hop limit, then this TLV MUST have a value encoding the period T_HOLD_TIME.
o [RFC5497]で指定されている、タイプ：= VALIDITY_TIMEの単一のメッセージTLV。すべてのTCメッセージが同じホップ制限で送信される場合、このTLVは期間T_HOLD_TIMEをエンコードする値を持つ必要があります。
If TC messages are sent with different hop limits (more than one value of TC_HOP_LIMIT), then this TLV MUST specify times that vary with the number of hops appropriate to the chosen pattern of TC message hop limits, as specified in [RFC5497]; these times SHOULD be appropriate multiples of T_HOLD_TIME. The options included in [RFC5497] for representing zero and infinite times MUST NOT be used.
TCメッセージが異なるホップ制限（TC_HOP_LIMITの複数の値）で送信される場合、このTLVは、[RFC5497]で指定されているように、選択されたTCメッセージホップ制限のパターンに適切なホップ数によって異なる時間を指定する必要があります。これらの時間は、T_HOLD_TIMEの適切な倍数である必要があります（SHOULD）。 [RFC5497]に含まれる、ゼロおよび無限の時間を表すオプションは使用してはなりません（MUST NOT）。
o If the TC message is complete, all network addresses that are the N_orig_addr of a Neighbor Tuple with N_advertised = true, MUST be represented by address objects in one or more Address Blocks. If the TC message is incomplete, then any such address objects MAY be included. At least one copy of each such address object that is included MUST be associated with an Address Block TLV with Type := NBR_ADDR_TYPE and Value := ORIGINATOR or with Value := ROUTABLE_ORIG if that address object is also to be associated with Value = ROUTABLE.
o TCメッセージが完了している場合、N_advertised = trueのネイバータプルのN_orig_addrであるすべてのネットワークアドレスは、1つ以上のアドレスブロックのアドレスオブジェクトで表す必要があります。 TCメッセージが不完全な場合、そのようなアドレスオブジェクトが含まれる場合があります。含まれるそのような各アドレスオブジェクトの少なくとも1つのコピーは、Type：= NBR_ADDR_TYPEおよびValue：= ORIGINATORまたはそのアドレスオブジェクトがValue = ROUTABLEにも関連付けられる場合はValue：= ROUTABLE_ORIGを持つアドレスブロックTLVに関連付けられている必要があります。
o If the TC message is complete, all routable addresses that are in the N_neighbor_addr_list of a Neighbor Tuple with N_advertised = true MUST be represented by address objects in one or more Address Blocks. If the TC message is incomplete, then any such address objects MAY be included. At least one copy of each such address object MUST be associated with an Address Block TLV with Type = NBR_ADDR_TYPE and Value = ROUTABLE or with Value = ROUTABLE_ORIG if also to be associated with Value = ORIGINATOR. At least one copy of each such address object MUST be associated with an Address Block TLV with Type = LINK_METRIC and Type Extension = LINK_METRIC_TYPE indicating an outgoing neighbor metric with value equal to the corresponding N_out_metric.
o TCメッセージが完了している場合、N_advertised = trueのネイバータプルのN_neighbor_addr_listにあるすべてのルーティング可能なアドレスは、1つ以上のアドレスブロックのアドレスオブジェクトで表す必要があります。 TCメッセージが不完全な場合、そのようなアドレスオブジェクトが含まれる場合があります。そのような各アドレスオブジェクトの少なくとも1つのコピーは、Type = NBR_ADDR_TYPEおよびValue = ROUTABLE、またはValue = ORIGINATORにも関連付けられる場合はValue = ROUTABLE_ORIGを持つアドレスブロックTLVに関連付ける必要があります。このような各アドレスオブジェクトの少なくとも1つのコピーは、Type = LINK_METRICおよびType Extension = LINK_METRIC_TYPEのアドレスブロックTLVに関連付けられている必要があります。これは、対応するN_out_metricに等しい値を持つ発信ネイバーメトリックを示します。
o If the TC message is complete, all network addresses that are the AL_net_addr of a Local Attached Network Tuple MUST be represented by address objects in one or more Address Blocks. If the TC message is incomplete, then any such address objects MAY be included. At least one copy of each such address object MUST be associated with an Address Block TLV with Type := GATEWAY and Value := AN_dist. At least one copy of each such address object MUST be associated with an Address Block TLV with Type = LINK_METRIC and Type Extension = LINK_METRIC_TYPE indicating an outgoing neighbor metric equal to the corresponding AL_metric.
o TCメッセージが完了している場合、ローカル接続ネットワークタプルのAL_net_addrであるすべてのネットワークアドレスは、1つまたは複数のアドレスブロックのアドレスオブジェクトで表す必要があります。 TCメッセージが不完全な場合、そのようなアドレスオブジェクトが含まれる場合があります。このような各アドレスオブジェクトの少なくとも1つのコピーは、Type：= GATEWAYおよびValue：= AN_distのアドレスブロックTLVに関連付けられている必要があります。このような各アドレスオブジェクトの少なくとも1つのコピーは、Type = LINK_METRICおよびType Extension = LINK_METRIC_TYPEのアドレスブロックTLVに関連付けられている必要があります。これは、対応するAL_metricに等しい発信ネイバーメトリックを示します。
A TC message MAY contain:
TCメッセージは以下を含むことができます：
o A single Message TLV with Type := INTERVAL_TIME, as specified in [RFC5497]. If all TC messages are sent with the same hop limit, then this TLV MUST have a value encoding the period TC_INTERVAL. If TC messages are sent with different hop limits, then this TLV MUST specify times that vary with the number of hops appropriate to the chosen pattern of TC message hop limits, as specified in [RFC5497]; these times MUST be appropriate multiples of TC_INTERVAL. The options included in [RFC5497] for representing zero and infinite times MUST NOT be used.
o [RFC5497]で指定されている、Type：= INTERVAL_TIMEの単一のメッセージTLV。すべてのTCメッセージが同じホップ制限で送信される場合、このTLVは期間TC_INTERVALをエンコードする値を持つ必要があります。 TCメッセージが異なるホップ制限で送信される場合、このTLVは、[RFC5497]で指定されているように、選択されたTCメッセージホップ制限のパターンに適切なホップ数によって異なる時間を指定する必要があります。これらの時間は、TC_INTERVALの適切な倍数でなければなりません。 [RFC5497]に含まれる、ゼロおよび無限の時間を表すオプションは使用してはなりません（MUST NOT）。
A router with one or more OLSRv2 interfaces, and with any Neighbor Tuples with N_advertised = true, or with a non-empty Local Attached Network Set MUST generate TC messages. A router that does not have such information to advertise MUST also generate "empty" TC messages for a period A_HOLD_TIME after it last generated a non-empty TC message.
1つ以上のOLSRv2インターフェイスを備え、N_advertised = true、または空でないローカル接続ネットワークセットを備えたネイバータプルを持つルーターは、TCメッセージを生成する必要があります。広告するそのような情報を持たないルータは、空でないTCメッセージを最後に生成した後、期間A_HOLD_TIMEの「空の」TCメッセージを生成しなければなりません（MUST）。
Complete TC messages are generated and transmitted periodically on all OLSRv2 interfaces, with a default interval between two consecutive TC message transmissions by the same router of TC_INTERVAL.
完全なTCメッセージが生成され、すべてのOLSRv2インターフェイスで定期的に送信されます。TC_INTERVALの同じルーターによる2つの連続したTCメッセージ送信のデフォルトの間隔があります。
TC messages MAY be generated in response to a change in the information that they are to advertise, indicated by a change in the ANSN in the Neighbor Information Base. In this case, a router MAY send a complete TC message and, if so, MAY restart its TC message schedule. Alternatively, a router MAY send an incomplete TC message with at least the newly advertised network addresses (i.e., not previously, but now, an N_orig_addr or in an N_neighbor_addr_list in a Neighbor Tuple with N_advertised = true or an AL_net_addr) in its Address Blocks, with associated Address Block TLV(s). Note that a router cannot report removal of advertised content using an incomplete TC message.
TCメッセージは、Neighbor Information BaseのANSNの変更によって示される、アドバタイズする情報の変更に応答して生成される場合があります。この場合、ルーターは完全なTCメッセージを送信してもよい（MAY）、もしそうであれば、TCメッセージのスケジュールを再開してもよい（MAY）。または、ルーターは、少なくとも新しくアドバタイズされたネットワークアドレス（つまり、以前ではなく、現在はN_orig_addr、またはN_advertised = trueまたはAL_net_addrのネイバータプルのN_neighbor_addr_list）をアドレスブロックに含む不完全なTCメッセージを送信する場合があります。関連付けられたアドレスブロックTLV。ルーターは、不完全なTCメッセージを使用して、アドバタイズされたコンテンツの削除を報告できないことに注意してください。
When sending a TC message in response to a change of advertised network addresses, a router MUST respect a minimum interval of TC_MIN_INTERVAL between sending TC messages (complete or incomplete) and a maximum interval of TC_INTERVAL between sending complete TC messages. Thus, a router MUST NOT send an incomplete TC message if within TC_MIN_INTERVAL of the next scheduled time to send a complete TC message.
アドバタイズされたネットワークアドレスの変更に応答してTCメッセージを送信する場合、ルーターは、TCメッセージの送信間の最小間隔TC_MIN_INTERVAL（完全または不完全）と、完全なTCメッセージの送信間の最大間隔TC_INTERVALを尊重する必要があります。したがって、完全なTCメッセージを送信するために次のスケジュールされた時間のTC_MIN_INTERVAL内にある場合、ルーターは不完全なTCメッセージを送信してはなりません（MUST NOT）。
The generation of TC messages, whether scheduled or triggered by a change of contents, MAY be jittered as described in [RFC5148]. The values of MAXJITTER used MUST be:
TCメッセージの生成は、スケジュールされているか、コンテンツの変更によってトリガーされたかに関係なく、[RFC5148]で説明されているようにジッターが発生する場合があります。使用するMAXJITTERの値は、次のようにする必要があります。
o TP_MAXJITTER for periodic TC message generation;
o TC_MAXJITTERは、定期的なTCメッセージを生成します。
o TT_MAXJITTER for responsive TC message generation.
o TT_MAXJITTERは、応答性の高いTCメッセージ生成用です。
On receiving a TC message on an OLSRv2 interface, the receiving router MUST then follow the processing and forwarding procedures defined in Section 14.
OLSRv2インターフェイスでTCメッセージを受信すると、受信側ルーターはセクション14で定義された処理および転送手順に従う必要があります。
If the message is considered for processing (Section 14.2), then a router MUST first check if the message is invalid for processing by this router, as defined in Section 16.3.1. A router MAY make a similar check before considering a message for forwarding; it MUST check the aspects that apply to elements in the Message Header.
メッセージが処理対象と見なされる場合（セクション14.2）、ルーターは、メッセージがこのルーターによる処理に無効かどうかを最初にチェックする必要があります（セクション16.3.1で定義）。ルーターは、転送するメッセージを検討する前に、同様のチェックを行うことができます。メッセージヘッダーの要素に適用される側面をチェックする必要があります。
If the TC message is not invalid, then the processing specific to TC Message Type, described in Section 16.3.2, MUST be applied. This will update its appropriate Interface Information Bases and its Router Information Base. Following this, if there are any changes in these Information Bases, then the processing in Section 17 MUST be performed.
TCメッセージが無効でない場合は、セクション16.3.2で説明されているTCメッセージタイプに固有の処理を適用する必要があります。これにより、適切なインターフェイス情報ベースとルーター情報ベースが更新されます。この後、これらの情報ベースに変更がある場合は、セクション17の処理を実行する必要があります。
A received TC message is invalid for processing by this router if the message:
受信したTCメッセージは、次の場合にこのルーターでの処理には無効です。
o Has an address length specified in the Message Header that is not equal to the length of the addresses used by this router.
o メッセージヘッダーに指定されているアドレス長が、このルーターで使用されているアドレスの長さと等しくありません。
o Does not include a message originator address and a message sequence number.
o メッセージの発信元アドレスとメッセージのシーケンス番号は含まれません。
o Does not include a hop count and contains a multi-value TLV with Type = VALIDITY_TIME or Type = INTERVAL_TIME, as defined in [RFC5497].
o [RFC5497]で定義されているように、ホップカウントは含まれず、Type = VALIDITY_TIMEまたはType = INTERVAL_TIMEの複数値TLVが含まれます。
o Does not have exactly one Message TLV with Type = VALIDITY_TIME.
o Type = VALIDITY_TIMEのメッセージTLVが1つだけではありません。
o Has more than one Message TLV with Type = INTERVAL_TIME.
o Type = INTERVAL_TIMEのメッセージTLVが複数あります。
o Does not have a Message TLV with Type = CONT_SEQ_NUM and Type Extension = COMPLETE or Type Extension = INCOMPLETE and contains at least one address object associated with an Address Block TLV with Type = NBR_ADDR_TYPE or Type = GATEWAY.
o Type = CONT_SEQ_NUMおよびType Extension = COMPLETEまたはType Extension = INCOMPLETEのメッセージTLVがなく、Type = NBR_ADDR_TYPEまたはType = GATEWAYのアドレスブロックTLVに関連付けられたアドレスオブジェクトが少なくとも1つ含まれています。
o Has more than one Message TLV with Type = CONT_SEQ_NUM and Type Extension = COMPLETE or Type Extension = INCOMPLETE.
o Type = CONT_SEQ_NUMおよびType Extension = COMPLETEまたはType Extension = INCOMPLETEのメッセージTLVが複数あります。
o Has a message originator address that is partially owned by this router.
o このルーターによって部分的に所有されているメッセージ発信元アドレスがあります。
o Includes any address object with a prefix length that is not maximal (equal to the address length, in bits), associated with an Address Block TLV with Type = NBR_ADDR_TYPE and Value = ORIGINATOR or Value = ROUTABLE_ORIG.
o タイプがNBR_ADDR_TYPEおよび値= ORIGINATORまたは値= ROUTABLE_ORIGのアドレスブロックTLVに関連付けられている、最大ではない（ビット単位のアドレス長と等しい）プレフィックス長を持つアドレスオブジェクトを含みます。
o Includes any address object that represents a non-routable address, associated with an Address Block TLV with Type = NBR_ADDR_TYPE and Value = ROUTABLE or Value = ROUTABLE_ORIG.
o タイプ= NBR_ADDR_TYPEおよび値= ROUTABLEまたは値= ROUTABLE_ORIGのアドレスブロックTLVに関連付けられた、ルーティング不可能なアドレスを表すアドレスオブジェクトが含まれます。
o Includes any address object associated with an Address Block TLV with Type = NBR_ADDR_TYPE or Type = GATEWAY that also represents the message's originator address.
o Type = NBR_ADDR_TYPEまたはType = GATEWAYのアドレスブロックTLVに関連付けられたアドレスオブジェクトを含み、メッセージの発信元アドレスも表します。
o Includes any address object (including different copies of an address object in the same or different Address Blocks) that is associated with an Address Block TLV with Type = NBR_ADDR_TYPE or Type = GATEWAY that is also associated with more than one outgoing neighbor metric using a TLV with Type = LINK_METRIC and Type Extension = LINK_METRIC_TYPE.
o Type = NBR_ADDR_TYPEまたはType = GATEWAYのアドレスブロックTLVに関連付けられているアドレスオブジェクト（同じまたは異なるアドレスブロックのアドレスオブジェクトの異なるコピーを含む）を含み、TLVを使用して複数の発信ネイバーメトリックにも関連付けられていますType = LINK_METRICおよびType Extension = LINK_METRIC_TYPE。
o Associates any address object (including different copies of an address object in the same or different Address Blocks) with more than one single hop count value using one or more Address Block TLV(s) with Type = GATEWAY.
o Type = GATEWAYの1つ以上のアドレスブロックTLVを使用して、任意のアドレスオブジェクト（同じまたは異なるアドレスブロック内のアドレスオブジェクトの異なるコピーを含む）を複数の単一ホップカウント値に関連付けます。
o Associates any address object (including different copies of an address object in the same or different Address Blocks) with Address Block TLVs with Type = NBR_ADDR_TYPE and Type = GATEWAY.
o 任意のアドレスオブジェクト（同じまたは異なるアドレスブロック内のアドレスオブジェクトの異なるコピーを含む）を、Type = NBR_ADDR_TYPEおよびType = GATEWAYのアドレスブロックTLVに関連付けます。
A router MAY recognize additional reasons for identifying that a message is invalid. An invalid message MUST be silently discarded, without updating the router's Information Bases.
ルーターは、メッセージが無効であることを識別するための追加の理由を認識してもよい（MAY）。無効なメッセージは、ルーターの情報ベースを更新せずに、警告なしで破棄する必要があります。
Note that a router that acts inconsistently, for example, rejecting TC messages "at random", may cause parts of the network to not be able to communicate with other parts of the network. It is RECOMMENDED that such "additional reasons for identifying that a message is invalid" be a consistent network-wide policy (e.g., as part of a security policy), implemented on all participating routers.
TCメッセージを「ランダムに」拒否するなど、一貫性のない動作をするルーターは、ネットワークの一部がネットワークの他の部分と通信できなくなる可能性があることに注意してください。このような「メッセージが無効であることを識別するための追加の理由」は、参加しているすべてのルーターに実装されている一貫したネットワーク全体のポリシー（セキュリティポリシーの一部など）であることが推奨されます。
When, according to Section 14.2, a TC message is to be "processed according to its type", this means that:
セクション14.2に従って、TCメッセージが「そのタイプに従って処理される」場合、これは次のことを意味します。
o If the TC message contains a Message TLV with Type = CONT_SEQ_NUM and Type Extension = COMPLETE, then processing according to Section 16.3.3 and then according to Section 16.3.4 is carried out.
o TCメッセージにType = CONT_SEQ_NUMおよびType Extension = COMPLETEのメッセージTLVが含まれている場合、セクション16.3.3に従って、そしてセクション16.3.4に従って処理が実行されます。
o If the TC message contains a Message TLV with Type = CONT_SEQ_NUM and Type Extension = INCOMPLETE, then only processing according to Section 16.3.3 is carried out.
o TCメッセージにType = CONT_SEQ_NUMおよびType Extension = INCOMPLETEのメッセージTLVが含まれている場合、セクション16.3.3による処理のみが実行されます。
For the purposes of the TC message processing in Section 16.3.3 and Section 16.3.4:
セクション16.3.3およびセクション16.3.4のTCメッセージ処理の目的：
o "validity time" is calculated from a VALIDITY_TIME Message TLV in the TC message according to the specification in [RFC5497]. All information in the TC message has the same validity time.
o 「有効期間」は、[RFC5497]の仕様に従って、TCメッセージのVALIDITY_TIMEメッセージTLVから計算されます。 TCメッセージのすべての情報の有効期間は同じです。
o "received ANSN" is defined as being the value of a Message TLV with Type = CONT_SEQ_NUM.
o 「受信したANSN」は、タイプがCONT_SEQ_NUMのメッセージTLVの値として定義されます。
o "associated metric value" is defined for any address in the TC message as being either the outgoing neighbor metric value indicated by a TLV with Type = LINK_METRIC and Type Extension = LINK_METRIC_TYPE that is associated with any address object in the TC message that is equal to that address or as UNKNOWN_METRIC otherwise. (Note that the rules in Section 16.3.1 make this definition unambiguous.)
o 「関連するメトリック値」は、TCメッセージ内の任意のアドレスに対して、以下に等しいTCメッセージ内のアドレスオブジェクトに関連付けられているType = LINK_METRICおよびType Extension = LINK_METRIC_TYPEのTLVによって示される発信ネイバーメトリック値のいずれかとして定義されます。そのアドレス、またはそれ以外の場合はUNKNOWN_METRICとして。 （セクション16.3.1の規則により、この定義は明確になります。）
o Comparisons of sequence numbers are carried out as specified in Section 21.
o シーケンス番号の比較は、セクション21の指定に従って実行されます。
The TC message is processed as follows:
TCメッセージは次のように処理されます。
1. The Advertising Remote Router Set is updated according to Section 16.3.3.1. If the TC message is indicated as discarded in that processing, then the following steps are not carried out.
1. アドバタイジングリモートルーターセットは、セクション16.3.3.1に従って更新されます。その処理でTCメッセージが破棄されたと示されている場合、以下のステップは実行されません。
2. The Router Topology Set is updated according to Section 16.3.3.2.
2. ルータートポロジセットは、セクション16.3.3.2に従って更新されます。
3. The Routable Address Topology Set is updated according to Section 16.3.3.3.
3. ルーティング可能なアドレストポロジセットは、セクション16.3.3.3に従って更新されます。
4. The Attached Network Set is updated according to Section 16.3.3.4.
4. アタッチされたネットワークセットは、セクション16.3.3.4に従って更新されます。
The router MUST update its Advertising Remote Router Set as follows:
ルーターは次のようにそのアドバタイジングリモートルーターセットを更新する必要があります。
1. If there is an Advertising Remote Router Tuple with:
1. 次のアドバタイズリモートルータタプルがある場合：
* AR_orig_addr = message originator address; AND
* AR_orig_addr =メッセージの発信者アドレス;そして
* AR_seq_number > received ANSN,
* AR_seq_number>受信したANSN、
then the TC message MUST be discarded.
次に、TCメッセージを破棄する必要があります。
2. Otherwise:
2. さもないと：
1. If there is no Advertising Remote Router Tuple such that:
1. 次のようなアドバタイズリモートルータタプルがない場合：
+ AR_orig_addr = message originator address;
+ AR_orig_addr =メッセージの発信者アドレス;
then create an Advertising Remote Router Tuple with:
次に、以下を使用してアドバタイズリモートルータタプルを作成します。
+ AR_orig_addr := message originator address.
+ AR_orig_addr：=メッセージの発信元アドレス。
2. This Advertising Remote Router Tuple (existing or new) is then modified as follows:
2. このアドバタイジングリモートルータータプル（既存または新規）は、次のように変更されます。
+ AR_seq_number := received ANSN;
+ AR_seq_number：=受信したANSN;
+ AR_time := current time + validity time.
+ AR_time：=現在の時間+有効時間。
The router MUST update its Router Topology Set as follows:
ルーターは、次のようにルータートポロジセットを更新する必要があります。
1. For each address (henceforth, advertised address) that corresponds to one or more address objects with an associated Address Block TLV with Type = NBR_ADDR_TYPE and Value = ORIGINATOR or Value = ROUTABLE_ORIG and that is not partially owned by this router, perform the following processing:
1. Type = NBR_ADDR_TYPEおよびValue = ORIGINATORまたはValue = ROUTABLE_ORIGの関連付けられたアドレスブロックTLVを持つ1つ以上のアドレスオブジェクトに対応し、このルーターによって部分的に所有されていない各アドレス（以下、アドバタイズされたアドレス）について、次の処理を実行します。
1. If the associated metric is UNKNOWN_METRIC, then remove any Router Topology Tuple such that:
1. 関連するメトリックがUNKNOWN_METRICの場合、次のようなルータートポロジタプルを削除します。
+ TR_from_orig_addr = message originator address; AND
+ TR_from_orig_addr =メッセージの発信者アドレス。そして
+ TR_to_orig_addr = advertised address.
+ TR_to_orig_addr =アドバタイズされたアドレス。
2. Otherwise, if there is no Router Topology Tuple such that:
2. それ以外の場合、次のようなルータートポロジタプルがない場合：
+ TR_from_orig_addr = message originator address; AND
+ TR_from_orig_addr =メッセージの発信者アドレス。そして
+ TR_to_orig_addr = advertised address,
+ TR_to_orig_addr =アドバタイズされたアドレス、
then create a new Router Topology Tuple with:
次に、以下を使用して新しいルータートポロジタプルを作成します。
+ TR_from_orig_addr := message originator address;
+ TR_from_orig_addr：=メッセージの発信者アドレス。
+ TR_to_orig_addr := advertised address.
+ TR_to_orig_addr：=アドバタイズされたアドレス。
3. This Router Topology Tuple (existing or new) is then modified as follows:
3. このルータートポロジタプル（既存または新規）は、次のように変更されます。
+ TR_seq_number := received ANSN;
+ TR_seq_number：=受信したANSN;
+ TR_metric := associated link metric;
+ TR_metric：=関連付けられたリンクメトリック。
+ TR_time := current time + validity time.
+ TR_time：=現在の時間+有効時間。
The router MUST update its Routable Address Topology Set as follows:
ルータは次のようにルーティング可能なアドレストポロジセットを更新する必要があります。
1. For each network address (henceforth, advertised address) that corresponds to one or more address objects with an associated Address Block TLV with Type = NBR_ADDR_TYPE and Value = ROUTABLE or Value = ROUTABLE_ORIG and that is not partially owned by this router, perform the following processing:
1. Type = NBR_ADDR_TYPEおよびValue = ROUTABLEまたはValue = ROUTABLE_ORIGの関連付けられたアドレスブロックTLVを持つ1つ以上のアドレスオブジェクトに対応し、このルーターによって部分的に所有されていない各ネットワークアドレス（以下、アドバタイズアドレス）について、次の処理を実行します：
1. If the associated metric is UNKNOWN_METRIC, then remove any Routable Address Topology Tuple such that:
1. 関連するメトリックがUNKNOWN_METRICの場合、次のようなルーティング可能なアドレストポロジのタプルを削除します。
+ TA_from_orig_addr = message originator address; AND
+ TA_from_orig_addr =メッセージの発信者アドレス。そして
+ TA_dest_addr = advertised address.
+ TA_dest_addr =アドバタイズされたアドレス。
2. Otherwise, if there is no Routable Address Topology Tuple such that:
2. それ以外の場合、次のようなルーティング可能なアドレストポロジタプルがない場合：
+ TA_from_orig_addr = message originator address; AND
+ TA_from_orig_addr =メッセージの発信者アドレス。そして
+ TA_dest_addr = advertised address, then create a new Routable Address Topology Tuple with:
+ TA_dest_addr =アドバタイズされたアドレス。次に、以下を使用して新しいルーティング可能なアドレストポロジタプルを作成します。
+ TA_from_orig_addr := message originator address;
+ TA_from_orig_addr：=メッセージの発信元アドレス。
+ TA_dest_addr := advertised address.
+ TA_dest_addr：=アドバタイズされたアドレス。
3. This Routable Address Topology Tuple (existing or new) is then modified as follows:
3. このルーティング可能なアドレストポロジタプル（既存または新規）は、次のように変更されます。
+ TA_seq_number := received ANSN;
+ TA_seq_number：=受信したANSN;
+ TA_metric := associated link metric;
+ TA_metric：=関連付けられたリンクメトリック。
+ TA_time := current time + validity time.
+ TA_time：=現在の時間+有効時間。
The router MUST update its Attached Network Set as follows:
ルーターは、接続されているネットワークセットを次のように更新する必要があります。
1. For each network address (henceforth, attached address) that corresponds to one or more address objects with an associated Address Block TLV with Type = GATEWAY and that is not fully owned by this router, perform the following processing:
1. Type = GATEWAYのアドレスブロックTLVが関連付けられた1つ以上のアドレスオブジェクトに対応し、このルーターが完全には所有していないネットワークアドレス（以下、接続されたアドレス）ごとに、次の処理を実行します。
1. If the associated metric is UNKNOWN_METRIC, then remove any Attached Network Tuple such that:
1. 関連するメトリックがUNKNOWN_METRICの場合は、次のような接続ネットワークタプルを削除します。
+ AN_net_addr = attached address; AND
+ AN_net_addr =添付アドレス;そして
+ AN_orig_addr = message originator address.
+ AN_orig_addr =メッセージの発信者アドレス。
2. Otherwise, if there is no Attached Network Tuple such that:
2. それ以外の場合、次のような接続されたネットワークタプルがない場合：
+ AN_net_addr = attached address; AND
+ AN_net_addr =添付アドレス;そして
+ AN_orig_addr = message originator address,
+ AN_orig_addr =メッセージの発信者アドレス、
then create a new Attached Network Tuple with:
次に、以下を使用して新しい接続ネットワークタプルを作成します。
+ AN_net_addr := attached address;
+ AN_net_addr：=添付アドレス;
+ AN_orig_addr := message originator address.
+ AN_orig_addr：=メッセージの発信元アドレス。
3. This Attached Network Tuple (existing or new) is then modified as follows:
3. この接続されたネットワークタプル（既存または新規）は、次のように変更されます。
+ AN_seq_number := received ANSN;
+ AN_seq_number：=受信したANSN;
+ AN_dist := the Value of the associated GATEWAY TLV;
+ AN_dist：=関連するゲートウェイTLVの値。
+ AN_metric := associated link metric;
+ AN_metric：=関連付けられたリンクメトリック。
+ AN_time := current time + validity time.
+ AN_time：=現在の時間+有効時間。
The TC message is processed as follows:
TCメッセージは次のように処理されます。
1. The Router Topology Set is updated according to Section 16.3.4.1.
1. ルータートポロジセットは、セクション16.3.4.1に従って更新されます。
2. The Routable Address Topology Set is updated according to Section 16.3.4.2.
2. ルーティング可能なアドレストポロジセットは、セクション16.3.4.2に従って更新されます。
3. The Attached Network Set is updated according to Section 16.3.4.3.
3. アタッチされたネットワークセットは、セクション16.3.4.3に従って更新されます。
The Router Topology Set MUST be updated as follows:
ルータトポロジセットは、次のように更新する必要があります。
1. Any Router Topology Tuples with:
1. 以下のルータートポロジータプル：
* TR_from_orig_addr = message originator address; AND
* TR_from_orig_addr =メッセージの発信者アドレス。そして
* TR_seq_number < received ANSN,
* TR_seq_number <受信したANSN、
MUST be removed.
削除する必要があります。
The Routable Address Topology Set MUST be updated as follows:
ルーティング可能なアドレストポロジセットは、次のように更新する必要があります。
1. Any Routable Address Topology Tuples with:
1. 以下のルーティング可能なアドレストポロジタプル：
* TA_from_orig_addr = message originator address; AND
* TA_from_orig_addr =メッセージの発信者アドレス。そして
* TA_seq_number < received ANSN,
* TA_seq_number <受信したANSN、
MUST be removed.
削除する必要があります。
The Attached Network Set MUST be updated as follows:
接続されたネットワークセットは、次のように更新する必要があります。
1. Any Attached Network Tuples with:
1. 接続されているすべてのネットワークタプル：
* AN_orig_addr = message originator address; AND
* AN_orig_addr =メッセージの発信元アドレス。そして
* AN_seq_number < received ANSN,
* AN_seq_number <受信したANSN、
MUST be removed.
削除する必要があります。
The changes described in the following sections MUST be carried out when any Information Base changes as indicated.
次のセクションで説明する変更は、情報ベースが指示どおりに変更されたときに実行する必要があります。
If the router changes its originator address, then:
ルータが発信元アドレスを変更した場合、次のようになります。
1. If there is no Originator Tuple with:
1. 以下の発信元タプルがない場合：
* O_orig_addr = old originator address
* O_orig_addr =古い発信者アドレス
then create an Originator Tuple with:
次に、次のようにして発信者タプルを作成します。
* O_orig_addr := old originator address
* O_orig_addr：=古い発信者アドレス
The Originator Tuple (existing or new) with:
オリジネータータプル（既存または新規）：
* O_orig_addr = new originator address
* O_orig_addr =新しい発信者アドレス
is then modified as follows:
次に、次のように変更されます。
* O_time := current time + O_HOLD_TIME
* O_time：=現在時刻+ O_HOLD_TIME
The consistency of a Link Tuple MUST be maintained according to the following rules, in addition to those in [RFC6130]:
リンクタプルの一貫性は、[RFC6130]の規則に加えて、次の規則に従って維持されなければなりません（MUST）。
o If L_status = HEARD or L_status = SYMMETRIC, then L_in_metric MUST be set (by a process outside this specification).
o L_status = HEARDまたはL_status = SYMMETRICの場合、L_in_metricを設定する必要があります（この仕様外のプロセスによって）。
o If L_status != SYMMETRIC, then set L_mpr_selector := false.
o L_status！= SYMMETRICの場合、L_mpr_selector：= falseを設定します。
o If L_out_metric = UNKNOWN_METRIC, then L_status MUST NOT equal SYMMETRIC; set L_SYM_time := EXPIRED if this would otherwise be the case.
o L_out_metric = UNKNOWN_METRICの場合、L_statusはSYMMETRICと等しくてはなりません。そうでない場合は、L_SYM_time：= EXPIREDを設定します。
The consistency of a Neighbor Tuple MUST be maintained according to the following rules, in addition to those in [RFC6130]:
[RFC6130]の規則に加えて、次の規則に従って隣接タプルの一貫性を維持する必要があります。
1. If N_symmetric = true, then N_in_metric MUST equal the minimum value of all L_in_metric of corresponding Link Tuples with L_status = SYMMETRIC and L_in_metric != UNKNOWN_METRIC. If there are no such Link Tuples, then N_in_metric MUST equal UNKNOWN_METRIC.
1. N_symmetric = trueの場合、N_in_metricは、L_status = SYMMETRICおよびL_in_metric！= UNKNOWN_METRICの対応するリンクタプルのすべてのL_in_metricの最小値と等しくなければなりません（MUST）。そのようなリンクタプルがない場合、N_in_metricはUNKNOWN_METRICと等しくなければなりません。
2. If N_symmetric = true, then N_out_metric MUST equal the minimum value of all L_out_metric of corresponding Link Tuples with L_status = SYMMETRIC and L_out_metric != UNKNOWN_METRIC. If there are no such Link Tuples, then N_out_metric MUST equal UNKNOWN_METRIC.
2. N_symmetric = trueの場合、N_out_metricは、L_status = SYMMETRICおよびL_out_metric！= UNKNOWN_METRICの対応するリンクタプルのすべてのL_out_metricの最小値と等しくなければなりません（MUST）。そのようなリンクタプルがない場合、N_out_metricはUNKNOWN_METRICと等しくなければなりません。
3. If N_symmetric = false, then N_flooding_mpr, N_routing_mpr, N_mpr_selector, and N_advertised MUST all be equal to false.
3. N_symmetric = falseの場合、N_flooding_mpr、N_routing_mpr、N_mpr_selector、およびN_advertisedはすべてfalseに等しい必要があります。
4. If N_mpr_selector = true, then N_advertised MUST be equal to true.
4. N_mpr_selector = trueの場合、N_advertisedはtrueに等しくなければなりません。
5. If N_symmetric = true, N_out_metric != UNKNOWN_METRIC and N_mpr_selector = false, then a router MAY select N_advertised = true or N_advertised = false. The more neighbors that are advertised, the larger TC messages become, but the more redundancy is available for routing. A router SHOULD consider the nature of its network in making such a decision and SHOULD avoid unnecessary changes in advertising status, which may result in unnecessary changes to routing.
5. N_symmetric = true、N_out_metric！= UNKNOWN_METRIC、N_mpr_selector = falseの場合、ルーターはN_advertised = trueまたはN_advertised = falseを選択できます（MAY）。アドバタイズされるネイバーが多いほど、TCメッセージは大きくなりますが、ルーティングにより多くの冗長性を利用できます。ルーターは、そのような決定を行う際にそのネットワークの性質を考慮すべきであり（SHOULD）、ルーティングに不必要な変更をもたらす可能性があるアドバタイジングステータスの不必要な変更を回避する必要があります。
The router MUST increment the ANSN in the Neighbor Information Base whenever:
ルータは、次の場合は常に、ネイバーインフォメーションベースのANSNをインクリメントする必要があります。
1. Any Neighbor Tuple changes its N_advertised value, or any Neighbor Tuple with N_advertised = true is removed.
1. ネイバータプルがN_advertised値を変更するか、N_advertised = trueのネイバータプルが削除されます。
2. Any Neighbor Tuple with N_advertised = true changes its N_orig_addr or has any routable address added to or removed from N_neighbor_addr_list.
2. N_advertised = trueのネイバータプルは、N_orig_addrを変更するか、N_neighbor_addr_listにルーティングアドレスを追加または削除します。
3. Any Neighbor Tuple with N_advertised = true has N_out_metric changed.
3. N_advertised = trueのネイバータプルは、N_out_metricが変更されています。
4. There is any change to the Local Attached Network Set.
4. ローカル接続ネットワークセットに変更があります。
The Router Topology Set, the Routable Address Topology Set, and the Attached Network Set MUST be changed when an Advertising Remote Router Tuple expires (AR_time is reached). The following changes are required before the Advertising Remote Router Tuple is removed:
ルータートポロジセット、ルーティング可能なアドレストポロジセット、および接続されたネットワークセットは、アドバタイジングリモートルータータプルの期限が切れた（AR_timeに達した）ときに変更する必要があります。 Advertising Remote Router Tupleを削除する前に、次の変更が必要です。
1. All Router Topology Tuples with:
1. 次のすべてのルータートポロジタプル：
* TR_from_orig_addr = AR_orig_addr of the Advertising Remote Router Tuple
* TR_from_orig_addr =アドバタイジングリモートルータータプルのAR_orig_addr
are removed.
削除されます。
2. All Routable Address Topology Tuples with:
2. 次のすべてのルーティング可能なアドレストポロジタプル：
* TA_from_orig_addr = AR_orig_addr of the Advertising Remote Router Tuple
* TA_from_orig_addr =アドバタイズリモートルータタプルのAR_orig_addr
are removed.
削除されます。
3. All Attached Network Tuples with:
3. 接続されているすべてのネットワークタプル：
* AN_orig_addr = AR_orig_addr of the Advertising Remote Router Tuple
* AN_orig_addr =アドバタイズリモートルータタプルのAR_orig_addr
are removed.
削除されます。
The sets of symmetric 1-hop neighbors selected as flooding MPRs and routing MPRs MUST satisfy the conditions defined in Section 18. To ensure this:
フラッディングMPRおよびルーティングMPRとして選択された対称1ホップネイバーのセットは、セクション18で定義された条件を満たす必要があります。
1. The set of flooding MPRs of a router MUST be recalculated if:
1. ルータのフラッディングMPRのセットは、次の場合に再計算する必要があります。
* A Link Tuple is added with L_status = SYMMETRIC and L_out_metric != UNKNOWN_METRIC; OR
* リンクタプルは、L_status = SYMMETRICおよびL_out_metric！= UNKNOWN_METRICで追加されます。または
* A Link Tuple with L_status = SYMMETRIC and L_out_metric != UNKNOWN_METRIC is removed; OR
* L_status = SYMMETRICおよびL_out_metric！= UNKNOWN_METRICのリンクタプルは削除されました。または
* A Link Tuple with L_status = SYMMETRIC and L_out_metric != UNKNOWN_METRIC changes to having L_status = HEARD, L_status = LOST, or L_out_metric = UNKNOWN_METRIC; OR
* L_status = SYMMETRICおよびL_out_metric！= UNKNOWN_METRICのリンクタプルは、L_status = HEARD、L_status = LOST、またはL_out_metric = UNKNOWN_METRICを持つように変更されます。または
* A Link Tuple with L_status = HEARD or L_status = LOST changes to having L_status = SYMMETRIC and L_out_metric != UNKNOWN_METRIC; OR
* L_status = HEARDまたはL_status = LOSTのリンクタプルは、L_status = SYMMETRICおよびL_out_metric！= UNKNOWN_METRICに変更されます。または
* The flooding MPR selection process uses metric values (see Section 18.4) and the L_out_metric of any Link Tuple with L_status = SYMMETRIC changes; OR
* フラッディングMPR選択プロセスでは、メトリック値（セクション18.4を参照）と、L_status = SYMMETRICが変更されたリンクタプルのL_out_metricを使用します。または
* The N_will_flooding of a Neighbor Tuple with N_symmetric = true and N_out_metric != UNKNOWN_METRIC changes from WILL_NEVER to any other value; OR
* N_symmetric = trueおよびN_out_metric！= UNKNOWN_METRICを使用した隣接タプルのN_will_floodingは、WILL_NEVERから他の値に変更されます。または
* The N_will_flooding of a Neighbor Tuple with N_flooding_mpr = true changes to WILL_NEVER from any other value; OR
* N_flooding_mpr = trueのネイバータプルのN_will_floodingは、他の値からWILL_NEVERに変わります。または
* The N_will_flooding of a Neighbor Tuple with N_symmetric = true, N_out_metric != UNKNOWN_METRIC, and N_flooding_mpr = false changes to WILL_ALWAYS from any other value; OR
* N_symmetric = true、N_out_metric！= UNKNOWN_METRIC、およびN_flooding_mpr = falseのネイバータプルのN_will_floodingは、他の値からWILL_ALWAYSに変わります。または
* A 2-Hop Tuple with N2_out_metric != UNKNOWN_METRIC is added or removed; OR
* N2_out_metric！= UNKNOWN_METRICの2ホップタプルが追加または削除されました。または
* The N2_out_metric of any 2-Hop Tuple changes and either the flooding MPR selection process uses metric values (see Section 18.4) or the change is to or from UNKNOWN_METRIC.
* 2ホップタプルのN2_out_metricが変更され、フラッディングMPR選択プロセスがメトリック値を使用するか（セクション18.4を参照）、変更がUNKNOWN_METRICとの間で行われる。
2. Otherwise, the set of flooding MPRs of a router MAY be recalculated if the N_will_flooding of a Neighbor Tuple with N_symmetric = true changes in any other way; it SHOULD be recalculated if N_flooding_mpr = false and this is an increase in N_will_flooding or if N_flooding_mpr = true and this is a decrease in N_will_flooding.
2. それ以外の場合、N_symmetric = trueのネイバータプルのN_will_floodingが他の方法で変更された場合、ルーターのフラッディングMPRのセットが再計算される場合があります。 N_flooding_mpr = falseであり、これがN_will_floodingの増加である場合、またはN_flooding_mpr = trueであり、これがN_will_floodingの減少である場合は、再計算する必要があります。
3. The set of routing MPRs of a router MUST be recalculated if:
3. ルーターのルーティングMPRのセットは、次の場合に再計算する必要があります。
* A Neighbor Tuple is added with N_symmetric = true and N_in_metric != UNKNOWN_METRIC; OR
* ネイバータプルは、N_symmetric = trueおよびN_in_metric！= UNKNOWN_METRICで追加されます。または
* A Neighbor Tuple with N_symmetric = true and N_in_metric != UNKNOWN_METRIC is removed; OR
* N_symmetric = trueおよびN_in_metric！= UNKNOWN_METRICの隣接タプルは削除されました。または
* A Neighbor Tuple with N_symmetric = true and N_in_metric != UNKNOWN_METRIC changes to having N_symmetric = false; OR
* N_symmetric = trueかつN_in_metric！= UNKNOWN_METRICの近傍タプルは、N_symmetric = falseに変更されます。または
* A Neighbor Tuple with N_symmetric = false changes to having N_symmetric = true and N_in_metric != UNKNOWN_METRIC; OR
* N_symmetric = falseの隣接タプルは、N_symmetric = trueおよびN_in_metric！= UNKNOWN_METRICを持つように変更されます。または
* The N_in_metric of any Neighbor Tuple with N_symmetric = true changes; OR
* N_symmetric = trueの変更がある近隣タプルのN_in_metricは変更されます。または
* The N_will_routing of a Neighbor Tuple with N_symmetric = true and N_in_metric != UNKNOWN_METRIC changes from WILL_NEVER to any other value; OR
* N_symmetric = trueおよびN_in_metric！= UNKNOWN_METRICを使用したネイバータプルのN_will_routingは、WILL_NEVERから他の値に変更されます。または
* The N_will_routing of a Neighbor Tuple with N_routing_mpr = true changes to WILL_NEVER from any other value; OR
* N_routing_mpr = trueの隣接タプルのN_will_routingは、他の値からWILL_NEVERに変わります。または
* The N_will_routing of a Neighbor Tuple with N_symmetric = true, N_in_metric != UNKNOWN_METRIC and N_routing_mpr = false changes to WILL_ALWAYS from any other value; OR
* N_symmetric = true、N_in_metric！= UNKNOWN_METRICおよびN_routing_mpr = falseのネイバータプルのN_will_routingは、他の値からWILL_ALWAYSに変更されます。または
* A 2-Hop Tuple with N2_in_metric != UNKNOWN_METRIC is added or removed; OR
* N2_in_metric！= UNKNOWN_METRICの2ホップタプルが追加または削除されました。または
* The N2_in_metric of any 2-Hop Tuple changes.
* 2ホップタプルの変更のN2_in_metric。
4. Otherwise, the set of routing MPRs of a router MAY be recalculated if the N_will_routing of a Neighbor Tuple with N_symmetric = true changes in any other way; it SHOULD be recalculated if N_routing_mpr = false and this is an increase in N_will_routing or if N_routing_mpr = true and this is a decrease in N_will_routing.
4. それ以外の場合、N_symmetric = trueの近隣タプルのN_will_routingが他の方法で変更された場合、ルーターのルーティングMPRのセットが再計算される場合があります。 N_routing_mpr = falseであり、これがN_will_routingの増加である場合、またはN_routing_mpr = trueであり、これがN_will_routingの減少である場合は、再計算する必要があります。
If either set of MPRs of a router is recalculated, this MUST be as described in Section 18.
ルータのいずれかのMPRのセットが再計算される場合、これはセクション18で説明されているとおりでなければなりません。
The Routing Set MUST be updated, as described in Section 19, when changes in the Local Information Base, the Neighborhood Information Base, or the Topology Information Base indicate a change (including of any potentially used outgoing neighbor metric values) of the known symmetric links and/or attached networks in the MANET, hence changing the Topology Graph. It is sufficient to consider only changes that affect at least one of:
ローカル情報ベース、ネイバーフッド情報ベース、またはトポロジー情報ベースの変更が既知の対称リンクの変更（潜在的に使用される発信ネイバーメトリック値を含む）を示す場合、セクション19で説明されているように、ルーティングセットを更新する必要があります。および/またはMANET内の接続されたネットワーク、したがってトポロジグラフを変更します。以下の少なくとも1つに影響する変更のみを考慮するだけで十分です。
o The Local Interface Set for an OLSRv2 interface, if the change removes any network address in an I_local_iface_addr_list. In this case, unless the OLSRv2 interface is removed, it may not be necessary to do more than replace such network addresses, if used, by an alternative network address from the same I_local_iface_addr_list.
o 変更によりI_local_iface_addr_listのネットワークアドレスが削除された場合の、OLSRv2インターフェイスのローカルインターフェイスセット。この場合、OLSRv2インターフェイスが削除されない限り、そのようなネットワークアドレスを使用する場合は、同じI_local_iface_addr_listからの代替ネットワークアドレスで置き換える以上のことを行う必要はないかもしれません。
o The Local Attached Set, if the change removes any AL_net_addr that is also an AN_net_addr. In this case, it may not be necessary to do more than add Routing Tuples with R_dest_addr equal to that AN_net_addr.
o ローカル接続セット（AN_net_addrでもあるAL_net_addrを変更により削除した場合）。この場合、R_dest_addrがそのAN_net_addrと等しいルーティングタプルを追加するだけでよい場合があります。
o The Link Set of any OLSRv2 interface, considering only Link Tuples that have, or just had, L_status = SYMMETRIC and L_out_metric != UNKNOWN_METRIC (including removal of such Link Tuples).
o L_status = SYMMETRICおよびL_out_metric！= UNKNOWN_METRICを持っている、または持っていたリンクタプルのみを考慮した、OLSRv2インターフェイスのリンクセット（そのようなリンクタプルの削除を含む）。
o The Neighbor Set of the router, considering only Neighbor Tuples that have, or just had, N_symmetric = true and N_out_metric != UNKNOWN_METRIC and do not have N_orig_addr = unknown.
o N_symmetric = trueおよびN_out_metric！= UNKNOWN_METRICがあり、N_orig_addr = unknownがないネイバータプルのみを考慮した、ルーターのネイバーセット。
o The 2-Hop Set of any OLSRv2 interface, if used in the creation of the Routing Set and if the change affects any 2-Hop Tuples with N2_out_metric != UNKNOWN_METRIC.
o ルーティングセットの作成に使用され、変更がN2_out_metric！= UNKNOWN_METRICの2ホップタプルに影響を与える場合、OLSRv2インターフェイスの2ホップセット。
o The Router Topology Set of the router.
o ルーターのルータートポロジセット。
o The Routable Address Topology Set of the router.
o ルーターのルーティング可能なアドレストポロジセット。
o The Attached Network Set of the router.
o ルーターの接続ネットワークセット。
Each router MUST select, from among its willing symmetric 1-hop neighbors, two subsets of these routers, as flooding and routing MPRs. This selection is recorded in the router's Neighbor Set and reported in the router's HELLO messages. Routers MAY select their MPRs by any process that satisfies the conditions that follow, which may, but need not, use the organization of the data described. Routers can freely interoperate whether they use the same or different MPR selection algorithms.
各ルーターは、自発的な対称1ホップネイバーの中から、これらのルーターの2つのサブセットをフラッディングおよびルーティングMPRとして選択する必要があります。この選択はルーターのネイバーセットに記録され、ルーターのHELLOメッセージで報告されます。ルーターは、以下の条件を満たすプロセスによってMPRを選択してもよい（MAY）。これは、説明されているデータの編成を使用する必要はないが、使用してもよい。ルーターは、同じまたは異なるMPR選択アルゴリズムを使用するかどうかに関係なく、自由に相互運用できます。
Only flooding MPRs forward control messages flooded through the MANET, thus effecting a flooding reduction, an optimization of the flooding mechanism, known as MPR flooding. Routing MPRs are used to effect a topology reduction in the MANET. (If no such reduction is required, then a router can select all of its relevant neighbors as routing MPRs.) Consequently, while it is not essential that these two sets of MPRs are minimal, keeping the numbers of MPRs small ensures that the overhead of this protocol is kept to a minimum.
フラッディングMPRのみがMANETを介してフラッディングされた制御メッセージを転送し、フラッディングの削減、つまりMPRフラッディングと呼ばれるフラッディングメカニズムの最適化に影響を与えます。ルーティングMPRを使用して、MANETのトポロジを削減します。 （このような削減が必要ない場合、ルーターは関連するすべてのネイバーをルーティングMPRとして選択できます。）したがって、これら2つのMPRのセットが最小限である必要はありませんが、MPRの数を少なく保つことで、このプロトコルは最小限に抑えられています。
MPRs are selected according to the following steps, defined in the following sections:
MPRは、次のセクションで定義されている次の手順に従って選択されます。
o A data structure known as a Neighbor Graph is defined.
o 近隣グラフと呼ばれるデータ構造が定義されています。
o The properties of an MPR Set derived from a Neighbor Graph are defined. Any algorithm that creates an MPR Set that satisfies these properties is a valid MPR selection algorithm. An example algorithm that creates such an MPR Set is given in Appendix B.
o ネイバーグラフから派生したMPRセットのプロパティが定義されます。これらのプロパティを満たすMPRセットを作成するアルゴリズムは、有効なMPR選択アルゴリズムです。そのようなMPRセットを作成するアルゴリズムの例を付録Bに示します。
o How to create a Neighbor Graph for each interface based on the corresponding Interface Information Base is defined, and how to combine the resulting MPR Sets to determine the router's flooding MPRs and record those in the router's Neighbor Set are described.
o 対応するインターフェイス情報ベースに基づいて各インターフェイスのネイバーグラフを作成する方法が定義され、結果のMPRセットを組み合わせてルーターのフラッディングMPRを決定し、ルーターのネイバーセットにそれらを記録する方法が説明されています。
o How to create a single Neighbor Graph based on all Interface Information Bases and the Neighbor Information Base is defined, and how to record the resulting MPR Set as the router's routing MPRs in the router's Neighbor Set is described.
o すべてのインターフェイス情報ベースとネイバー情報ベースに基づいて単一のネイバーグラフを作成する方法を定義し、結果のMPRセットをルーターのルーティングMPRとしてルーターのネイバーセットに記録する方法について説明します。
o A specification as to when MPRs MUST be calculated is given.
o MPRをいつ計算しなければならないかに関する仕様が記載されています。
When a router selects its MPRs, it MAY consider any characteristics of its neighbors that it is aware of. In particular, it SHOULD consider the willingness of the neighbor, as recorded by the corresponding N_will_flooding or N_will_routing value, as appropriate, preferring neighbors with higher values. (Note that willingness values equal to WILL_NEVER and WILL_ALWAYS are always considered, as described.) However, a router MAY consider other characteristics to have a greater significance.
ルーターがそのMPRを選択するとき、それが認識しているネイバーの特性を考慮してもよい（MAY）。特に、対応するN_will_floodingまたはN_will_routing値によって記録されたネイバーの意欲を適切に考慮し、より高い値のネイバーを優先する必要があります。 （説明したように、WILL_NEVERおよびWILL_ALWAYSに等しい意欲値は常に考慮されることに注意してください。）ただし、ルーターは他の特性をより重要であると見なす場合があります。
Each router MAY select its flooding and routing MPRs independently of each other or coordinate its selections. A router MAY make its MPR selections independently of the MPR selection by other routers, or it MAY, for example, give preference to routers that either are, or are not, already selected as MPRs by other routers.
各ルーターは、フラッディングMPRとルーティングMPRを互いに独立して選択するか、選択を調整できます（MAY）。ルーターは、他のルーターによるMPR選択とは無関係にMPR選択を行うことができます。たとえば、他のルーターによってMPRとしてすでに選択されているか、または選択されていないルーターを優先することもできます（MAY）。
A Neighbor Graph is a structure defined here as consisting of sets N1 and N2 and some associated metric and willingness values. Elements of set N1 represent willing symmetric 1-hop neighbors, and elements of set N2 represent addresses of a symmetric 2-hop neighbor.
ネイバーグラフは、N1とN2のセットと、いくつかの関連するメトリックと意欲値で構成されるものとして、ここで定義されている構造です。セットN1の要素は、対象となる対称1ホップネイバーを表し、セットN2の要素は、対称2ホップネイバーのアドレスを表します。
A Neighbor Graph has the following properties:
ネイバーグラフには次のプロパティがあります。
o It contains two disjoint sets N1 and N2.
o 2つの互いに素なセットN1とN2が含まれています。
o For each element x in N1, there is an associated willingness value W(x) such that WILL_NEVER < W(x) <= WILL_ALWAYS.
o N1の各要素xには、WILL NEVER <We）<= WILL ALWAYSとなるような関連する意欲値WITH（x）があります。
o For each element x in N1, there is an associated metric d1(x) > 0.
o N1の各要素xには、関連するメトリックd1（x）> 0があります。
o For some elements y in N2, there is an associated metric d1(y) > 0. (Other elements y in N2 have undefined d1(y); this may be considered to be infinite.)
o N2の一部の要素yには、関連するメトリックd1（y）> 0があります（N2の他の要素yは未定義のd1（y）を持っています。これは無限と見なされる場合があります）。
o For each element x in N1, there is a subset N2(x) of elements of N2; this subset may be empty. For each x in N1 and each y in N2(x), there is an associated metric d2(x,y) > 0. (For other x in N1 and y in N2, d2(x,y) is undefined and may be considered infinite.)
o N1の各要素xには、N2の要素のサブセットN2（x）があります。このサブセットは空の場合があります。 N1の各xとN2（x）の各yには、関連するメトリックd2（x、y）> 0があります（N1の他のxとN2のyの場合、d2（x、y）は未定義であり、無限と見なされます。）
o N2 is equal to the union of all the N2(x) for all x in N1, i.e., for each y in N2, there is at least one x in N1 such that y is in N2(x).
o N2は、N1のすべてのxのすべてのN2（x）の和集合に等しい、つまり、N2の各yについて、yがN2（x）にあるように、N1には少なくとも1つのxがあります。
It is convenient to also define:
以下も定義すると便利です。
o For each y in N2, the set N1(y) that contains x in N1 if and only if y is in N2(x). From the final property above, N1(y) is not empty.
o N2の各yについて、yがN2（x）にある場合に限り、N1にxを含むセットN1（y）。上記の最後のプロパティから、N1（y）は空ではありません。
o For each x in N1 and y in N2, if d2(x,y) is defined, then d(x,y) := d1(x)+d2(x,y); otherwise, d(x,y) is not defined. (Thus, d(x,y) is defined if y is in N2(x) or, equivalently, if x is in N1(y).)
o N1の各xとN2のyについて、d2（x、y）が定義されている場合、d（x、y）：= d1（x）+ d2（x、y）;それ以外の場合、d（x、y）は定義されません。 （したがって、yがN2（x）にある場合、または同等にxがN1（y）にある場合、d（x、y）が定義されます。）
o For any subset S of N1 and for each y in N2, the metric d(y,S) is the minimum value of d1(y), if defined, and of all d(x,y) for x in N1(y) and in S. If there are no such metrics to take the minimum value of, then d(y,S) is undefined (may be considered to be infinite). From the final property above, d(y,N1) is defined for all y.
o N1のサブセットSとN2の各yについて、メトリックd（y、S）は、定義されている場合、d1（y）の最小値であり、N1（y）のxのすべてのd（x、y）の最小値です。最小値をとるそのようなメトリクスがない場合、d（y、S）は未定義です（無限と見なされる場合があります）。上記の最後のプロパティから、すべてのyに対してd（y、N1）が定義されます。
Given a Neighbor Graph as defined in Section 18.2, an MPR Set for that Neighbor Graph is a subset M of the set N1 that satisfies the following properties: o If x in N1 has W(x) = WILL_ALWAYS, then x is in M.
セクション18.2で定義されている隣接グラフを考えると、その隣接グラフのMPRセットは、次のプロパティを満たすセットN1のサブセットMです。o N1のxがW（x）= WILL_ALWAYSの場合、xはMになります。
o For any y in N2 that does not have a defined d1(y), there is at least one element in M that is also in N1(y). This is equivalent to the requirement that d(y,M) is defined.
o 定義されたd1（y）を持たないN2のyの場合、N1（y）にもあるMに少なくとも1つの要素があります。これは、d（y、M）が定義されているという要件と同等です。
o For any y in N2, d(y,M) = d(y,N1).
o N2の任意のyについて、d（y、M）= d（y、N1）。
These properties reflect that the MPR Set consists of a set of symmetric 1-hop neighbors that cover all the symmetric 2-hop neighbors and that they do so retaining a minimum distance route (1-hop, if present, or 2-hop) to each symmetric 2-hop neighbor.
これらのプロパティは、MPRセットがすべての対称2ホップネイバーをカバーする対称1ホップネイバーのセットで構成され、最小距離のルート（存在する場合は1ホップ、または2ホップ）を維持することを反映していることを反映しています各対称2ホップネイバー。
Note that if M is an MPR Set, then so is any subset of N1 that contains M; also note that N1 is always an MPR Set. An MPR Set may be empty but cannot be empty if N2 contains any elements y that do not have a defined d1(y).
MがMPRセットの場合、Mを含むN1のサブセットも同様であることに注意してください。また、N1は常にMPRセットです。 MPRセットは空でもかまいませんが、d1（y）が定義されていない要素yがN2に含まれている場合は空にできません。
Whenever flooding MPRs are to be calculated, an implementation MUST determine and record a set of flooding MPRs that is equivalent to one calculated as described in this section.
フラッディングMPRを計算する場合は常に、実装は、このセクションで説明されているように計算されたフラッディングMPRと同等の一連のフラッディングMPRを決定して記録する必要があります。
The calculation of flooding MPRs need not use link metrics or, equivalently, may use link metrics with a fixed value, here taken to be 1. However, links with unknown metric (L_out_metric = UNKNOWN_METRIC) MUST NOT be used even if link metrics are otherwise not used.
フラッディングMPRの計算では、リンクメトリックを使用する必要はありません。同等に、固定値のリンクメトリックを使用できます。ここでは1とします。ただし、リンクメトリックが他の場合でも、未知のメトリック（L_out_metric = UNKNOWN_METRIC）のリンクは使用しないでください。使用されていない。
Routers MAY make individual decisions as to whether to use link metrics for the calculation of flooding MPRs. A router MUST use the same approach to the choice of whether to use link metrics for all links, i.e., in the cases indicated by A or B, the same choice MUST be made in each case.
ルーターは、フラッディングMPRの計算にリンクメトリックを使用するかどうかについて個別に決定を行う場合があります。ルータは、すべてのリンクにリンクメトリックを使用するかどうかの選択に同じアプローチを使用する必要があります。つまり、AまたはBで示されるケースでは、それぞれのケースで同じ選択を行う必要があります。
For each OLSRv2 interface (the "current interface"), define a Neighbor Graph as defined in Section 18.2 according to the following:
各OLSRv2インターフェイス（「現在のインターフェイス」）について、次に従ってセクション18.2で定義されているように隣接グラフを定義します。
o Define a reachable Link Tuple to be a Link Tuple in the Link Set for the current interface with L_status = SYMMETRIC and L_out_metric != UNKNOWN_METRIC.
o L_status = SYMMETRICおよびL_out_metric！= UNKNOWN_METRICを使用して、現在のインターフェースのリンクセット内のリンクタプルとして到達可能なリンクタプルを定義します。
o Define an allowed Link Tuple to be a reachable Link Tuple whose corresponding Neighbor Tuple has N_will_flooding > WILL_NEVER.
o 許可されたリンクタプルを、対応するネイバータプルがN_will_flooding> WILL_NEVERである到達可能なリンクタプルになるように定義します。
o Define an allowed 2-Hop Tuple to be a 2-Hop Tuple in the 2-Hop Set for the current interface for which N2_out_metric != UNKNOWN_METRIC and there is an allowed Link Tuple with L_neighbor_iface_addr_list = N2_neighbor_iface_addr_list.
o N2_out_metric！= UNKNOWN_METRICで、L_neighbor_iface_addr_list = N2_neighbor_iface_addr_listの許可されたリンクタプルが存在する現在のインターフェースの2ホップセットで、許可された2ホップタプルを2ホップタプルとして定義します。
o Define an element of N1 for each allowed Link Tuple. This then defines the corresponding Link Tuple for each element of N1 and the corresponding Neighbor Tuple for each element of N1, being the Neighbor Tuple corresponding to that Link Tuple.
o 許可されたリンクタプルごとにN1の要素を定義します。次に、N1の各要素に対応するリンクタプルと、N1の各要素に対応する隣接タプルを、そのリンクタプルに対応する隣接タプルとして定義します。
o For each element x in N1, define W(x) := N_will_flooding of the corresponding Neighbor Tuple.
o N1の各要素xに対して、対応する近傍タプルのW（x）：= N_will_floodingを定義します。
o For each element x in N1, define d1(x) as either:
o N1の要素xごとに、d1（x）を次のいずれかとして定義します。
A. L_out_metric of the corresponding Link Tuple; OR
A.対応するリンクタプルのL_out_metric。または
B. 1.
B. 1。
o Define an element of N2 for each network address that is the N2_2hop_addr of one or more allowed 2-Hop Tuples. This then defines the corresponding address for each element of N2.
o 1つ以上の許可された2ホップタプルのN2_2hop_addrであるネットワークアドレスごとにN2の要素を定義します。次に、N2の各要素に対応するアドレスを定義します。
o For each element y in N2, if the corresponding address is in the N_neighbor_addr_list of a Neighbor Tuple that corresponds to one or more reachable Link Tuples, then define d1(y) as either:
o N2の各要素yについて、対応するアドレスが、1つ以上の到達可能なリンクタプルに対応するネイバータプルのN_neighbor_addr_listにある場合、d1（y）を次のいずれかとして定義します。
A. the minimum value of the L_out_metric of those Link Tuples; OR
A.それらのリンクタプルのL_out_metricの最小値。または
B. 1.
B. 1。
Otherwise, d1(y) is not defined. In the latter case, where d1(y) := 1, all such y in N2 may instead be removed from N2.
それ以外の場合、d1（y）は定義されません。後者の場合、d1（y）：= 1の場合、N2内のそのようなすべてのyが代わりにN2から削除されます。
o For each element x in N1, define N2(x) as the set of elements y in N2 whose corresponding address is the N2_2hop_addr of an allowed 2-Hop Tuple that has N2_neighbor_iface_addr_list = L_neighbor_iface_addr_list of the Link Tuple corresponding to x. For all such x and y, define d2(x,y) as either:
o N1の各要素xについて、対応するアドレスが、xに対応するリンクタプルのN2_neighbor_iface_addr_list = L_neighbor_iface_addr_listを持つ許可された2ホップタプルのN2_2hop_addrであるN2の要素yのセットとしてN2（x）を定義します。このようなすべてのxおよびyについて、d2（x、y）を次のいずれかとして定義します。
A. N2_out_metric of that 2-Hop Tuple; OR
A.その2ホップタプルのN2_out_metric;または
B. 1.
B. 1。
It is up to an implementation to decide how to label each element of N1 or N2. For example, an element of N1 may be labeled with one or more addresses from the corresponding L_neighbor_iface_addr_list or with a pointer or reference to the corresponding Link Tuple.
N1またはN2の各要素にラベルを付ける方法を決定するのは実装次第です。たとえば、N1の要素は、対応するL_neighbor_iface_addr_listからの1つ以上のアドレス、または対応するリンクタプルへのポインタまたは参照でラベル付けできます。
Using these Neighbor Graphs, flooding MPRs are selected and recorded by:
これらのネイバーグラフを使用して、フラッディングMPRが選択および記録されます。
o For each OLSRv2 interface, determine an MPR Set as specified in Section 18.3.
o 各OLSRv2インターフェイスについて、セクション18.3で指定されているMPRセットを決定します。
o A Neighbor Tuple represents a flooding MPR and has N_flooding_mpr := true (otherwise, N_flooding_mpr := false) if and only if that Neighbor Tuple corresponds to an element in an MPR Set created for any interface as described above. That is, the overall set of flooding MPRs is the union of the sets of flooding MPRs for all OLSRv2 interfaces.
o ネイバータプルはフラッディングMPRを表し、N_flooding_mpr：= true（そうでなければ、N_flooding_mpr：= false）を持ちます。そのネイバータプルが、上記のように任意のインターフェイス用に作成されたMPRセットの要素に対応する場合に限ります。つまり、フラッディングMPRの全体的なセットは、すべてのOLSRv2インターフェイスのフラッディングMPRのセットの和集合です。
A router MAY select its flooding MPRs for each OLSRv2 interface independently, or it MAY coordinate its MPR selections across its OLSRv2 interfaces, as long as the required condition is satisfied for each OLSRv2 interface. One such coordinated approach is to process the OLSRv2 interfaces sequentially and, for each OLSRv2 interface, start with flooding MPRs selected (and not removable) if the neighbor has been already selected as an MPR for an OLSRv2 interface that has already been processed. The algorithm specified in Appendix B can be used in this way.
ルーターは、各OLSRv2インターフェイスのフラッディングMPRを個別に選択するか、または各OLSRv2インターフェイスで必要な条件が満たされている限り、OLSRv2インターフェイス全体でMPRの選択を調整できます（MAY）。このような調整されたアプローチの1つは、OLSRv2インターフェイスを順次処理し、処理済みのOLSRv2インターフェイスのMPRとしてネイバーがすでに選択されている場合は、各OLSRv2インターフェイスについて、フラッディングMPRが選択されている（削除できない）ことから始めます。付録Bで指定されたアルゴリズムは、この方法で使用できます。
Whenever routing MPRs are to be calculated, an implementation MUST determine and record a set of routing MPRs that is equivalent to one calculated as described in this section.
ルーティングMPRを計算する場合は常に、実装は、このセクションで説明されているように計算されたものと同等のルーティングMPRのセットを決定して記録する必要があります。
Define a single Neighbor Graph as defined in Section 18.2 according to the following:
次に従って、セクション18.2で定義されているように単一の隣接グラフを定義します。
o Define a reachable Neighbor Tuple to be a Neighbor Tuple with N_symmetric = true and N_in_metric != UNKNOWN_METRIC.
o 到達可能なネイバータプルをN_symmetric = trueおよびN_in_metric！= UNKNOWN_METRICのネイバータプルとして定義します。
o Define an allowed Neighbor Tuple to be a reachable Neighbor Tuple with N_will_routing > WILL_NEVER.
o N_will_routing> WILL_NEVERを使用して、許可されたネイバータプルを到達可能なネイバータプルとして定義します。
o Define an allowed 2-Hop Tuple to be a 2-Hop Tuple in the 2-Hop Set for any OLSRv2 interface with N2_in_metric != UNKNOWN_METRIC and for which there is an allowed Neighbor Tuple with N_neighbor_addr_list containing N2_neighbor_iface_addr_list.
o N2_in_metric！= UNKNOWN_METRICを使用し、N2_neighbor_addr_listにN2_neighbor_iface_addr_listを含む許可されたネイバータプルが存在するOLSRv2インターフェイスの2ホップセットで、許可された2ホップタプルを2ホップタプルとして定義します。
o Define an element of N1 for each allowed Neighbor Tuple. This then defines the corresponding Neighbor Tuple for each element of N1.
o 許可された隣接タプルごとにN1の要素を定義します。次に、N1の各要素に対応する隣接タプルを定義します。
o For each element x in N1, define W(x) := N_will_routing of the corresponding Neighbor Tuple.
o N1の各要素xに対して、対応する近傍タプルのW（x）：= N_will_routingを定義します。
o For each element x in N1, define d1(x) := N_in_metric of the corresponding Neighbor Tuple.
o N1の各要素xに対して、対応する近傍タプルのd1（x）：= N_in_metricを定義します。
o Define an element of N2 for each network address that is the N2_2hop_addr of one or more allowed 2-Hop Tuples. This then defines the corresponding address for each element of N2.
o 1つ以上の許可された2ホップタプルのN2_2hop_addrであるネットワークアドレスごとにN2の要素を定義します。次に、N2の各要素に対応するアドレスを定義します。
o For each element y in N2, if the corresponding address is in the N_neighbor_addr_list of a reachable Neighbor Tuple, then define d1(y) to be the N_in_metric of that Neighbor Tuple; otherwise, d1(y) is not defined.
o N2の各要素yについて、対応するアドレスが到達可能な近隣タプルのN_neighbor_addr_listにある場合、d1（y）をその近隣タプルのN_in_metricとして定義します。それ以外の場合、d1（y）は定義されません。
o For each element x in N1, define N2(x) as the set of elements y in N2 whose corresponding address is the N2_2hop_addr of an allowed 2-Hop Tuple that has N2_neighbor_iface_addr_list contained in N_neighbor_addr_list of the Neighbor Tuple corresponding to x. For all such x and y, define d2(x,y) := N2_out_metric of that 2-Hop Tuple.
o N1の各要素xに対して、N2（x）をN2の要素yのセットとして定義します。対応するアドレスは、xに対応する近隣タプルのN_neighbor_addr_listに含まれるN2_neighbor_iface_addr_listを持つ許可された2ホップタプルのN2_2hop_addrです。そのようなすべてのxおよびyについて、その2ホップタプルのd2（x、y）：= N2_out_metricを定義します。
It is up to an implementation to decide how to label each element of N1 or N2. For example, an element of N1 may be labeled with one or more addresses from the corresponding N_neighbor_addr_list or with a pointer or reference to the corresponding Neighbor Tuple.
N1またはN2の各要素にラベルを付ける方法を決定するのは実装次第です。たとえば、N1の要素は、対応するN_neighbor_addr_listからの1つ以上のアドレス、または対応するネイバータプルへのポインターまたは参照でラベル付けされます。
Using these Neighbor Graphs, routing MPRs are selected and recorded according to the following:
これらの隣接グラフを使用して、ルーティングMPRが選択され、以下に従って記録されます。
o Determine an MPR Set as specified in Section 18.3.
o セクション18.3で指定されているMPRセットを決定します。
o A Neighbor Tuple represents a routing MPR and has N_routing_mpr := true (otherwise, N_routing_mpr := false) if and only if that Neighbor Tuple corresponds to an element in the MPR Set created as described above.
o ネイバータプルはルーティングMPRを表し、そのネイバータプルが上記のように作成されたMPRセットの要素に対応する場合に限り、N_routing_mpr：= true（そうでなければ、N_routing_mpr：= false）を持ちます。
A router MUST recalculate each of its sets of MPRs whenever the currently selected set of MPRs does not still satisfy the required conditions. It MAY recalculate its MPRs if the current set of MPRs is still valid but could be more efficient. Sufficient conditions to recalculate a router's sets of MPRs are given in Section 17.6.
A router MUST recalculate each of its sets of MPRs whenever the currently selected set of MPRs does not still satisfy the required conditions. It MAY recalculate its MPRs if the current set of MPRs is still valid but could be more efficient. Sufficient conditions to recalculate a router's sets of MPRs are given in Section 17.6.
The Routing Set of a router is populated with Routing Tuples that represent paths from that router to all destinations in the network. These paths are calculated based on the Network Topology Graph, which is constructed from information in the Information Bases, obtained via HELLO and TC message exchange.
ルーターのルーティングセットには、そのルーターからネットワーク内のすべての宛先へのパスを表すルーティングタプルが読み込まれます。これらのパスは、HELLOおよびTCメッセージ交換を介して取得される情報ベースの情報から構成されるネットワークトポロジグラフに基づいて計算されます。
Changes to the Routing Set do not require any messages to be transmitted. The state of the Routing Set SHOULD, however, be reflected in the IP routing table by adding and removing entries from that routing table as appropriate. Only appropriate Routing Tuples (in particular only those that represent local links or paths to routable addresses) need be reflected in the IP routing table.
ルーティングセットを変更しても、メッセージを送信する必要はありません。ただし、ルーティングセットの状態は、必要に応じてルーティングテーブルにエントリを追加および削除することにより、IPルーティングテーブルに反映する必要があります（SHOULD）。適切なルーティングタプル（特に、ルーティング可能なアドレスへのローカルリンクまたはパスを表すもののみ）をIPルーティングテーブルに反映する必要があります。
The Network Topology Graph is formed from information from the router's Local Interface Set, Link Sets for OLSRv2 interfaces, Neighbor Set, Router Topology Set, Routable Address Topology Set, and Attached Network Set. The Network Topology Graph MAY also use information from the router's 2-Hop Sets for OLSRv2 interfaces. The Network Topology Graph forms the router's topological view of the network in the form of a directed graph. Each edge in that graph has a metric value. The Network Topology Graph has a "backbone" (within which minimum total metric routes will be constructed) containing the following edges:
ネットワークトポロジグラフは、ルータのローカルインターフェイスセット、OLSRv2インターフェイスのリンクセット、ネイバーセット、ルータトポロジセット、ルーティング可能なアドレストポロジセット、および接続されたネットワークセットからの情報から形成されます。ネットワークトポロジグラフは、ルータの2ホップセットからの情報をOLSRv2インターフェイスに使用する場合もあります。ネットワークトポロジグラフは、ルータのネットワークのトポロジビューを有向グラフの形式で形成します。そのグラフの各エッジにはメトリック値があります。ネットワークトポロジグラフには、次のエッジを含む「バックボーン」（その中に最小合計メトリックルートが構築されます）があります。
o Edges X -> Y for all possible Y, and one X per Y, such that:
o エッジX->可能なすべてのYのY、およびYごとに1つのX。
* Y is the N_orig_addr of a Neighbor Tuple; AND
* YはネイバータプルのN_orig_addrです。そして
* N_orig_addr is not unknown; AND
* N_orig_addrは不明ではありません。そして
* X is in the I_local_iface_addr_list of a Local Interface Tuple; AND
* Xは、ローカルインターフェイスタプルのI_local_iface_addr_listにあります。そして
* There is a Link Tuple with L_status = SYMMETRIC and L_out_metric != UNKNOWN_METRIC such that this Neighbor Tuple and this Local Interface Tuple correspond to it. A network address from L_neighbor_iface_addr_list will be denoted R in this case.
* L_status = SYMMETRICおよびL_out_metric！= UNKNOWN_METRICのリンクタプルがあり、このネイバータプルとこのローカルインターフェースタプルが対応しています。この場合、L_neighbor_iface_addr_listからのネットワークアドレスはRで示されます。
It SHOULD be preferred, where possible, to select R = Y and to select X from the Local Interface Tuple corresponding to the Link Tuple from which R was selected. The metric for such an edge is the corresponding N_out_metric.
可能な場合、R = Yを選択し、Rが選択されたリンクタプルに対応するローカルインターフェースタプルからXを選択することが推奨されます。このようなエッジのメトリックは、対応するN_out_metricです。
o All edges W -> U such that:
o 次のようなすべてのエッジW-> U
* W is the TR_from_orig_addr of a Router Topology Tuple; AND
* WはルータートポロジタプルのTR_from_orig_addrです。そして
* U is the TR_to_orig_addr of the same Router Topology Tuple.
* Uは、同じルータートポロジタプルのTR_to_orig_addrです。
The metric of such an edge is the corresponding TR_metric.
The metric of such an edge is the corresponding TR_metric.
The Network Topology Graph is further "decorated" with the following edges. If a network address S, V, Z, or T equals a network address Y or W, then the edge terminating in the network address S, V, Z, or T MUST NOT be used in any path.
ネットワークトポロジグラフは、次のエッジでさらに「装飾」されています。ネットワークアドレスS、V、Z、またはTがネットワークアドレスYまたはWと等しい場合、ネットワークアドレスS、V、Z、またはTで終端するエッジをどのパスでも使用してはなりません（MUST NOT）。
o Edges X -> S for all possible S, and one X per S, such that:
o エッジX-> Sはすべての可能なSに対応し、Sごとに1つのXとなります。
* S is in the N_neighbor_addr_list of a Neighbor Tuple; AND
* SはネイバータプルのN_neighbor_addr_listにあります。そして
* X is in the I_local_iface_addr_list of a Local Interface Tuple; AND
* Xは、ローカルインターフェイスタプルのI_local_iface_addr_listにあります。そして
* There is a Link Tuple with L_status = SYMMETRIC and L_out_metric != UNKNOWN_METRIC such that this Neighbor Tuple and this Local Interface Tuple correspond to it. A network address from L_neighbor_iface_addr_list will be denoted R in this case.
* L_status = SYMMETRICおよびL_out_metric！= UNKNOWN_METRICのリンクタプルがあり、このネイバータプルとこのローカルインターフェースタプルが対応しています。この場合、L_neighbor_iface_addr_listからのネットワークアドレスはRで示されます。
It SHOULD be preferred, where possible, to select R = S and to select X from the Local Interface Tuple corresponding to the Link Tuple from which R was selected. The metric for such an edge is the corresponding N_out_metric.
可能であれば、R = Sを選択し、Rが選択されたリンクタプルに対応するローカルインターフェースタプルからXを選択することが推奨されます。このようなエッジのメトリックは、対応するN_out_metricです。
o All edges W -> V such that:
o 次のようなすべてのエッジW-> V
* W is the TA_from_orig_addr of a Routable Address Topology Tuple; AND
* Wは、ルーティング可能なアドレストポロジタプルのTA_from_orig_addrです。そして
* V is the TA_dest_addr of the same Routable Address Topology Tuple.
* Vは、同じルーティング可能なアドレストポロジタプルのTA_dest_addrです。
The metric for such an edge is the corresponding TA_metric.
このようなエッジのメトリックは、対応するTA_metricです。
o All edges W -> T such that:
o 次のすべてのエッジW-> T
* W is the AN_orig_addr of an Attached Network Tuple; AND
* Wは、接続されたネットワークタプルのAN_orig_addrです。そして
* T is the AN_net_addr of the same Attached Network Tuple.
* T is the AN_net_addr of the same Attached Network Tuple.
The metric for such an edge is the corresponding AN_metric.
このようなエッジのメトリックは、対応するAN_metricです。
o (OPTIONAL) All edges Y -> Z such that:
o （オプション）次のようなすべてのエッジY-> Z
* Z is a routable address and is the N2_2hop_addr of a 2-Hop Tuple with N2_out_metric != UNKNOWN_METRIC; AND
* Zはルーティング可能なアドレスであり、N2_out_metric！= UNKNOWN_METRICの2ホップタプルのN2_2hop_addrです。そして
* Y is the N_orig_addr of the corresponding Neighbor Tuple; AND
* Yは、対応する近隣タプルのN_orig_addrです。そして
* This Neighbor Tuple has N_will_routing not equal to WILL_NEVER.
* このネイバータプルのN_will_routingはWILL_NEVERと等しくありません。
A path terminating with such an edge MUST NOT be used in preference to any other path. The metric for such an edge is the corresponding N2_out_metric.
そのようなエッジで終了するパスは、他のどのパスよりも優先して使用してはなりません。このようなエッジのメトリックは、対応するN2_out_metricです。
Any part of the Topology Graph that is not connected to a local network address X is not used. Only one selection X SHOULD be made from each I_local_iface_addr_list, and only one selection R SHOULD be made from any L_neighbor_iface_addr_list. All edges have a hop count of 1, except edges W -> T that have a hop count of the corresponding value of AN_dist.
ローカルネットワークアドレスXに接続されていないトポロジグラフの部分は使用されません。各I_local_iface_addr_listから1つだけ選択Xを行う必要があり（SHOULD）、任意のL_neighbor_iface_addr_listから1つだけ選択Rを行う必要があります。 AN_distの対応する値のホップカウントを持つエッジW-> Tを除いて、すべてのエッジのホップカウントは1です。
The Routing Set MUST contain the shortest paths for all destinations from all local OLSRv2 interfaces using the Network Topology Graph. This calculation MAY use any algorithm, including any means of choosing between paths of equal total metric. (In the case of two paths of equal total metric but differing hop counts, the path with the lower hop count SHOULD be used.)
The Routing Set MUST contain the shortest paths for all destinations from all local OLSRv2 interfaces using the Network Topology Graph. This calculation MAY use any algorithm, including any means of choosing between paths of equal total metric. (In the case of two paths of equal total metric but differing hop counts, the path with the lower hop count SHOULD be used.)
Using the notation of Section 19.1, initially "backbone" paths using only edges X -> Y and W -> U need be constructed (using a minimum distance algorithm). Then paths using only a final edge of the other types may be added. These MUST NOT replace backbone paths with the same destination (and paths terminating in an edge Y -> Z SHOULD NOT replace paths with any other form of terminating edge).
セクション19.1の表記を使用して、最初にエッジX-> YおよびW-> Uのみを使用する「バックボーン」パスを構築する必要があります（最小距離アルゴリズムを使用）。次に、他のタイプの最終エッジのみを使用するパスを追加できます。これらは、同じ宛先のバックボーンパスを置き換えてはなりません（および、エッジY-> Zで終端するパスは、パスを他の形式の終端エッジで置き換えないでください）。
Each path will correspond to a Routing Tuple. These will be of two types. The first type will represent single edge paths, of type X -> S or X -> Y, by:
各パスはルーティングタプルに対応します。これらは2つのタイプになります。最初のタイプは、タイプX-> SまたはX-> Yの単一エッジパスを次のように表します。
o R_local_iface_addr := X;
o R_local_iface_addr：= X;
o R_next_iface_addr := R;
o R_next_iface_addr：= R;
o R_dest_addr := S or Y;
o R_dest_addr：= SまたはY;
o R_dist := 1;
o R_dist：= 1;
o R_metric := edge metric,
o R_metric：=エッジメトリック、
where R is as defined in Section 19.1 for these types of edge.
ここで、Rは、これらのタイプのエッジについてセクション19.1で定義されたものです。
The second type will represent a multiple edge path, which will always have first edge of type X -> Y, and will have final edge of type W -> U, W -> V, W -> T, or Y -> Z. The Routing Tuple will be:
2番目のタイプは、常にタイプX-> Yの最初のエッジを持ち、タイプW-> U、W-> V、W-> T、またはY-> Zの最終エッジを持つ複数のエッジパスを表します。ルーティングタプルは次のようになります。
o R_local_iface_addr := X;
o R_local_iface_addr：= X;
o R_next_iface_addr := Y;
o R_next_iface_addr：= Y;
o R_dest_addr := U, V, T or Z;
o R_dest_addr：= U、V、T、またはZ;
o R_dist := the total hop count of all edges in the path;
o R_dist：=パス内のすべてのエッジの合計ホップカウント。
o R_metric := the total metric of all edges in the path.
o R_metric：=パス内のすべてのエッジの合計メトリック。
Finally, Routing Tuples of the second type whose R_dest_addr is not routable MAY be discarded.
最後に、R_dest_addrがルーティングできない2番目のタイプのルーティングタプルは破棄される場合があります。
An example algorithm for calculating the Routing Set of a router is given in Appendix C.
ルーターのルーティングセットを計算するためのアルゴリズムの例を付録Cに示します。
This protocol uses all parameters defined in [RFC6130] and additional parameters defined in this specification. All but one (RX_HOLD_TIME) of these additional parameters are router parameters as defined in [RFC6130]. The proposed values of the additional parameters defined in the following sections are appropriate to the case where all parameters (including those defined in [RFC6130]) have a single value. Proposed values for parameters defined in [RFC6130] are given in that specification.
このプロトコルは、[RFC6130]で定義されているすべてのパラメーターと、この仕様で定義されている追加のパラメーターを使用します。これらの追加パラメーターの1つ（RX_HOLD_TIME）を除くすべてが、[RFC6130]で定義されているルーターパラメーターです。以下のセクションで定義される追加パラメーターの提案された値は、すべてのパラメーター（[RFC6130]で定義されているものを含む）が単一の値を持つ場合に適しています。 [RFC6130]で定義されているパラメータの提案された値は、その仕様に示されています。
The following proposed values are based on experience with [RFC3626] deployments (such as documented in [McCabe]) and are considered typical. They can be changed to accommodate different deployment requirements -- for example, a network with capacity-limited network interfaces would be expected to use greater values for message intervals, whereas a highly mobile network would be expected to use lower values for message intervals. When determining these values, the constraints specified in Section 5 MUST be respected.
次の提案された値は、[RFC3626]展開の経験（[McCabe]に文書化されているなど）に基づいており、典型的な値と見なされています。それらは、さまざまな展開要件に対応するように変更できます。たとえば、容量が制限されたネットワークインターフェイスを備えたネットワークでは、メッセージ間隔に大きな値を使用することが予想されますが、モバイル性の高いネットワークでは、メッセージ間隔に低い値を使用することが予想されます。これらの値を決定するとき、セクション5で指定された制約を尊重する必要があります。
Note that routers in a MANET need not all use the same set of parameters, and those parameters that are indicated as interface parameters need not be the same on all OLSRv2 interfaces of a single router.
MANETのルーターはすべて同じパラメーターセットを使用する必要はなく、インターフェイスパラメーターとして示されているパラメーターは、単一のルーターのすべてのOLSRv2インターフェイスで同じである必要はないことに注意してください。
o O_HOLD_TIME := 30 seconds
o O_hold_time：= 30秒
o TC_INTERVAL := 5 seconds
o TC_INTERVAL：= 5秒
o TC_MIN_INTERVAL := TC_INTERVAL/4
o TC_MIN_INTERVAL：= TC_INTERVAL / 4
o T_HOLD_TIME := 3 x TC_INTERVAL
o T_HOLD_TIME：= 3 x TC_INTERVAL
o A_HOLD_TIME := T_HOLD_TIME
o A_HOLD_TIME：= T_HOLD_TIME
o RX_HOLD_TIME := 30 seconds
o RX_HOLD_TIME：= 30秒
o P_HOLD_TIME := 30 seconds
o P_HOLD_TIME：= 30秒
o F_HOLD_TIME := 30 seconds
o F_HOLD_TIME：= 30秒
o TP_MAXJITTER := HP_MAXJITTER
o TP_MAXJITTER：= HP_MAXJITTER
o TT_MAXJITTER := HT_MAXJITTER
o TT_MAXJITTER：= HT_MAXJITTER
o F_MAXJITTER := TT_MAXJITTER
o F_MAXJITTER：= TT_MAXJITTER
o TC_HOP_LIMIT := 255
o TC_HOP_LIMIT：= 255
o WILL_FLOODING := WILL_DEFAULT
o WILL_FLOODING：= WILL_DEFAULT
o WILL_ROUTING := WILL_DEFAULT
o WILL_ROUTING：= WILL_DEFAULT
Sequence numbers are used in this specification for the purpose of discarding "old" information, i.e., messages received out of order. However, with a limited number of bits for representing sequence numbers, wraparound (in which the sequence number is incremented from the maximum possible value to zero) will occur. To prevent this from interfering with the operation of this protocol, the following MUST be observed when determining the ordering of sequence numbers.
この仕様では、シーケンス番号は、「古い」情報、つまり順不同で受信されたメッセージを破棄する目的で使用されます。ただし、シーケンス番号を表すビット数が限られているため、ラップアラウンド（シーケンス番号が可能な最大値からゼロに増分される）が発生します。これがこのプロトコルの動作を妨げないようにするために、シーケンス番号の順序を決定するときは、以下を遵守する必要があります。
The term MAXVALUE designates in the following one more than the largest possible value for a sequence number. For a 16-bit sequence number (like those defined in this specification), MAXVALUE is 65536.
MAXVALUEという用語は、シーケンス番号の最大可能値よりも1つ多い数を以下に示します。 （この仕様で定義されているような）16ビットのシーケンス番号の場合、MAXVALUEは65536です。
The sequence number S1 is said to be "greater than" the sequence number S2 if:
The sequence number S1 is said to be "greater than" the sequence number S2 if:
o S1 > S2 AND S1 - S2 < MAXVALUE/2, OR
o S1> S2 AND S1-S2 <MAXVALUE / 2、または
o S2 > S1 AND S2 - S1 > MAXVALUE/2
o S2> S1 AND S2-S1> MAXVALUE / 2
When sequence numbers S1 and S2 differ by MAXVALUE/2, their ordering cannot be determined. In this case, which should not occur, either ordering may be assumed.
シーケンス番号S1とS2がMAXVALUE / 2異なる場合、それらの順序を決定できません。この場合、これは発生しないはずですが、どちらの順序でも想定できます。
Thus, when comparing two messages, it is possible -- even in the presence of wraparound -- to determine which message contains the most recent information.
したがって、2つのメッセージを比較する場合、ラップアラウンドがあっても、どのメッセージに最新の情報が含まれているかを判別できます。
An extension to this protocol will need to interact with this specification and possibly also with [RFC6130]. This protocol is designed to permit such interactions, in particular:
このプロトコルの拡張は、この仕様と、そしておそらく[RFC6130]とも相互作用する必要があります。このプロトコルは、特に次のような相互作用を可能にするように設計されています。
o Through accessing, and possibly extending, the information in the Information Bases. All updates to the elements specified in this specification are subject to the normative constraints specified in [RFC6130] and Appendix A. Note that the processing specified in this document ensures that these constraints are satisfied.
o 情報ベースの情報にアクセスし、場合によっては拡張することによって。この仕様で指定された要素に対するすべての更新は、[RFC6130]と付録Aで指定された規範的な制約の対象となります。このドキュメントで指定された処理により、これらの制約が確実に満たされることに注意してください。
o Through accessing an outgoing message prior to it being transmitted over any OLSRv2 interface and adding information to it as specified in [RFC5444]. This MAY include Message TLVs and/or network addresses with associated Address Block TLVs. (Network addresses without new associated TLVs SHOULD NOT be added to messages.) This may, for example, be to allow a security protocol, as suggested in Section 23, to add a TLV containing a cryptographic signature to the message.
o OLSRv2インターフェイスを介して送信される前に発信メッセージにアクセスし、[RFC5444]で指定されているように情報を追加する。これには、メッセージTLVやネットワークアドレス、および関連するアドレスブロックTLVが含まれる場合があります。 （新しく関連付けられたTLVのないネットワークアドレスはメッセージに追加しないでください。）これは、たとえば、セクション23で提案されているように、セキュリティプロトコルが暗号署名を含むTLVをメッセージに追加できるようにするためです。
o Through accessing an incoming message and potentially discarding it prior to processing by this protocol. This may, for example, allow a security protocol, as suggested in Section 23, to perform verification of message signatures and prevent processing and/or forwarding of unverifiable messages by this protocol.
o 着信メッセージにアクセスし、このプロトコルで処理する前にメッセージを破棄する可能性があります。これにより、たとえば、セクション23で提案されているように、セキュリティプロトコルでメッセージ署名の検証を実行し、このプロトコルによる検証不可能なメッセージの処理や転送を防ぐことができます。
o Through accessing an incoming message after it has been completely processed by this protocol. In particular, this may allow a protocol that has added information, by way of inclusion of appropriate TLVs or of network addresses associated with new TLVs, access to such information after appropriate updates have been recorded in the Information Bases in this protocol.
o このプロトコルによって完全に処理された後、着信メッセージにアクセスする。特に、これにより、適切なTLVまたは新しいTLVに関連付けられたネットワークアドレスを含めることによって情報を追加したプロトコルは、適切な更新がこのプロトコルの情報ベースに記録された後、そのような情報にアクセスできます。
o Through requesting that a message be generated at a specific time. In that case, message generation MUST still respect the constraints in [RFC6130] and Section 5.4.3.
o 特定の時間にメッセージを生成するよう要求する。その場合、メッセージ生成は、[RFC6130]とセクション5.4.3の制約を依然として尊重しなければなりません（MUST）。
As a proactive routing protocol, OLSRv2 is a potential target for various attacks. This section presents the envisioned security architecture for OLSRv2 and gives guidelines on how to provide integrity, confidentiality, and integration into external routing domains. Separately specified mandatory security mechanisms are summarized, and some observations on key management are given.
As a proactive routing protocol, OLSRv2 is a potential target for various attacks. This section presents the envisioned security architecture for OLSRv2 and gives guidelines on how to provide integrity, confidentiality, and integration into external routing domains. Separately specified mandatory security mechanisms are summarized, and some observations on key management are given.
OLSRv2 integrates into the architecture specified in Appendix A of [RFC5444], in [RFC5498], and in Section 16 of [RFC6130], the latter by using and extending its messages and Information Bases.
OLSRv2は、[RFC5444]の付録A、[RFC5498]、[RFC6130]のセクション16で指定されているアーキテクチャに統合されています。後者は、メッセージと情報ベースを使用および拡張しています。
As part of this architecture, OLSRv2 and NHDP [RFC6130] recognize that there may be external reasons for rejecting messages that would be considered "badly formed" or "insecure", e.g., if an Integrity Check Value (ICV) included in a message by an external mechanism cannot be verified. This architecture allows options as to whether and how to implement security features, reflecting the situation that MANET routing protocol deployment domains have varying security requirements, ranging from "practically unbreakable" to "virtually none". This approach allows MANET routing protocol specifications to remain generic, with extensions to them and/or extensions to the multiplexing and demultiplexing process described in Appendix A of [RFC5444], providing security mechanisms appropriate to a given deployment domain.
このアーキテクチャの一部として、OLSRv2とNHDP [RFC6130]は、「不正な形式」または「安全でない」と見なされるメッセージを拒否する外部の理由が存在する可能性があることを認識します。たとえば、整合性チェック値（ICV）が外部メカニズムは検証できません。このアーキテクチャにより、セキュリティ機能を実装するかどうか、および実装する方法に関するオプションが可能になります。これは、MANETルーティングプロトコル展開ドメインのセキュリティ要件が「実質的に壊れない」から「実質的にない」までさまざまであるという状況を反映しています。このアプローチにより、MANETルーティングプロトコル仕様を汎用のままにして、それらの拡張や、[RFC5444]の付録Aで説明されている多重化および逆多重化プロセスの拡張を使用して、特定のデプロイメントドメインに適切なセキュリティメカニズムを提供できます。
The following sections provide guidelines on how to provide integrity, confidentiality, and integration with external routing domains in such extensions.
次のセクションでは、整合性、機密性、およびそのような拡張機能の外部ルーティングドメインとの統合を提供する方法に関するガイドラインを示します。
Each router injects topological information into the network by transmitting HELLO messages and, for some routers, also TC messages. If some routers for some reason (malice or malfunction) inject invalid control traffic, network integrity may be compromised. Therefore, message, or packet, authentication is strongly advised.
各ルーターは、HELLOメッセージを送信することでトポロジー情報をネットワークに注入し、一部のルーターではTCメッセージも送信します。一部のルーターが何らかの理由（悪意または誤動作）で無効な制御トラフィックを注入すると、ネットワークの整合性が損なわれる可能性があります。したがって、メッセージまたはパケットの認証を強くお勧めします。
Different such situations may occur, for example:
たとえば、次のようなさまざまな状況が発生する可能性があります。
1. A router generates TC messages, advertising links to non-neighbor routers;
1. ルーターはTCメッセージを生成し、非隣接ルーターへのリンクをアドバタイズします。
2. A router generates TC messages, pretending to be another router;
2. A router generates TC messages, pretending to be another router;
3. A router generates HELLO messages, advertising non-neighbor routers;
3. ルーターはHELLOメッセージを生成し、非隣接ルーターを通知します。
4. A router generates HELLO messages, pretending to be another router;
4. ルーターは別のルーターになりすましてHELLOメッセージを生成します。
5. A router forwards altered control messages;
5. ルーターは変更された制御メッセージを転送します。
6. A router does not forward control messages;
6. ルーターは制御メッセージを転送しません。
7. A router does not select multipoint relays correctly;
7. ルーターはマルチポイントリレーを正しく選択しません。
8. A router forwards broadcast control messages unaltered but does not forward unicast data traffic;
8. ルーターは、ブロードキャスト制御メッセージを変更せずに転送しますが、ユニキャストデータトラフィックは転送しません。
9. A router "replays" previously recorded control traffic from another router.
9. ルーターは、別のルーターから以前に記録された制御トラフィックを「リプレイ」します。
Authentication of the originator router for control messages (for situations 2, 4, and 5) and of the individual links announced in the control messages (for situations 1 and 3) may be used as a countermeasure. However, to prevent routers from repeating old (and correctly authenticated) information (situation 9), additional information is required (e.g., a timestamp or sequence number), allowing a router to positively identify such replayed messages.
制御メッセージの発信元ルーター（状況2、4、および5の場合）および制御メッセージで通知された個々のリンク（状況1および3の場合）の認証は、対策として使用できます。ただし、ルーターが古い（そして正しく認証された）情報を繰り返さないようにする（状況9）には、追加情報（タイムスタンプやシーケンス番号など）が必要で、ルーターがそのような再生されたメッセージを確実に識別できるようにします。
In general, ICVs (e.g., digital signatures) and other required security information can be transmitted within the HELLO and TC messages or within a packet header using the TLV mechanism. Either option permits different levels of protection to coexist in the same network, if desired.
一般に、ICV（デジタル署名など）およびその他の必要なセキュリティ情報は、HELLOおよびTCメッセージ内、またはTLVメカニズムを使用したパケットヘッダー内で送信できます。どちらのオプションでも、必要に応じて、異なるレベルの保護を同じネットワークに共存させることができます。
An important consideration is that all control messages (HELLO messages and TC messages) are transmitted to all routers in the 1-hop neighborhood and some control messages (TC messages) are flooded to all routers in the network. This is done in a packet that is transmitted to all routers in the 1-hop neighborhood, the current set of which may not be known. Thus, a control message or packet used by this protocol is always contained in a transmission destined for multiple destinations, and it is important that the authentication mechanism employed permits any receiving router to validate the authenticity of a message or packet.
重要な考慮事項は、すべての制御メッセージ（HELLOメッセージとTCメッセージ）が1ホップ近隣のすべてのルーターに送信され、一部の制御メッセージ（TCメッセージ）がネットワーク内のすべてのルーターにフラッディングされることです。これは、1ホップの近隣にあるすべてのルーターに送信されるパケットで行われ、現在のセットは不明である可能性があります。したがって、このプロトコルで使用される制御メッセージまたはパケットは、常に複数の宛先を宛先とする伝送に含まれます。採用されている認証メカニズムにより、受信ルーターがメッセージまたはパケットの信頼性を検証できることが重要です。
[RFC7182] specifies a common exchange format for cryptographic information in the form of Packet TLVs, Message TLVs, and Address Block TLVs, as specified in [RFC5444]. These may be used (and shared) among MANET routing protocol security extensions. In particular, [RFC7182] specifies the format of TLVs for containing Integrity Check Values (ICVs), i.e., signatures, for providing integrity, as well as TLVs for containing temporal information for preventing replay attacks. [RFC7182] specifies registries for using different ciphers and formats of temporal information. When using ICV TLVs in an OLSRv2 deployment, failure to verify an included ICV mandates rejection of an incoming message or packet as "invalid", according to Section 12.1 of [RFC6130] and according to Section 16.3.1 of this specification when using the multiplexing and demultiplexing process described in Appendix A of [RFC5444].
[RFC7182]は、[RFC5444]で指定されているように、パケットTLV、メッセージTLV、およびアドレスブロックTLVの形式で暗号情報の一般的な交換形式を指定します。これらはMANETルーティングプロトコルセキュリティ拡張機能間で使用（および共有）できます。特に、[RFC7182]は、完全性を提供するための完全性チェック値（ICV）、つまりシグネチャを含むためのTLVの形式と、リプレイ攻撃を防ぐための一時的な情報を含むためのTLVを指定します。 [RFC7182]は、さまざまな暗号と形式の時間情報を使用するためのレジストリを指定します。 OLSRv2展開でICV TLVを使用する場合、含まれているICVの検証に失敗すると、[RFC6130]のセクション12.1および多重化を使用するときのこの仕様のセクション16.3.1に従って、着信メッセージまたはパケットの拒否が「無効」として要求されます。 [RFC5444]の付録Aで説明されている逆多重化プロセス。
[RFC7182] specifies how to insert ICVs into generated messages, how to verify incoming messages, and to reject "insecure" messages (i.e., messages without an ICV or with an ICV that cannot be verified). Different MANET deployments may, as a result of the purpose for which they are used and the possibility and nature of their configuration, require different ICV algorithms and timestamps or multiple keys, and thus, a security extension may use any of the different options provided in [RFC7182].
[RFC7182]は、生成されたメッセージにICVを挿入する方法、着信メッセージを確認する方法、および「安全でない」メッセージ（つまり、ICVがない、またはICVが確認できないメッセージ）を拒否する方法を指定します。さまざまなMANET展開では、それらが使用される目的とその構成の可能性と性質の結果として、さまざまなICVアルゴリズムとタイムスタンプまたは複数のキーが必要になる場合があるため、セキュリティ拡張機能では、 [RFC7182]。
OLSRv2 periodically MPR floods topological information to all routers in the network. Hence, if used in an unprotected network, in particular, an unprotected wireless network, the network topology is revealed to anyone who successfully listens to the control messages. This information may serve an attacker to acquire details about the topology and therefore to initiate more effective attacks against routers in the routing domain, e.g., by spoofing addresses of routers in the network and attracting traffic for these addresses. Note that this is independent of the data traffic and purely protects the control traffic, i.e., information about the network topology.
OLSRv2は定期的にトポロジ情報をネットワーク内のすべてのルーターにフラッディングします。したがって、保護されていないネットワーク、特に保護されていないワイヤレスネットワークで使用すると、制御メッセージを正常にリッスンするすべての人にネットワークトポロジが明らかになります。この情報は、攻撃者がトポロジーの詳細を取得し、ルーティングドメイン内のルーターに対してより効果的な攻撃を開始するのに役立つ可能性があります。たとえば、ネットワーク内のルーターのアドレスを偽装し、これらのアドレスのトラフィックを引き付けます。これはデータトラフィックとは無関係であり、制御トラフィック、つまりネットワークトポロジに関する情報を純粋に保護します。
In situations where the confidentiality of the network topology is of importance, regular cryptographic techniques, such as use of OLSRv2 multicast control packets encrypted using IPsec (e.g., with a shared secret key), can be applied to ensure that control traffic can be read and interpreted by only those authorized to do so. Alternatively, a security extension may specify a mechanism to provide confidentiality for control messages and/or packets. However, unless the information about the network topology itself is confidential, integrity of control messages (as specified in Section 23.2) is sufficient to admit only trusted routers (i.e., routers with valid credentials) to the network.
ネットワークトポロジの機密性が重要である状況では、IPsecを使用して暗号化されたOLSRv2マルチキャスト制御パケット（共有秘密鍵など）の使用などの通常の暗号化技術を適用して、制御トラフィックを確実に読み取って、許可された人だけが解釈します。あるいは、セキュリティ拡張機能は、制御メッセージやパケットに機密性を提供するメカニズムを指定する場合があります。ただし、ネットワークトポロジ自体に関する情報が機密情報である場合を除き、制御メッセージの整合性（セクション23.2で指定）は、信頼できるルーター（つまり、有効な資格情報を持つルーター）のみをネットワークに許可するのに十分です。
This protocol provides a basic mechanism for injecting external routing information into this protocol's routing domain. Routing information can also be extracted from this protocol's Information Bases, in particular the Routing Set, and injected into an external routing domain, if the routing protocol governing that routing domain permits this.
このプロトコルは、外部ルーティング情報をこのプロトコルのルーティングドメインに挿入するための基本的なメカニズムを提供します。ルーティング情報は、このルーティングドメインを管理するルーティングプロトコルで許可されている場合、このプロトコルの情報ベース、特にルーティングセットから抽出して、外部ルーティングドメインに挿入することもできます。
When operating routers connecting a routing domain using this protocol to an external routing domain, care MUST be taken not to allow potentially insecure and untrustworthy information to be injected from this routing domain to an external routing domain. Care MUST also be taken to validate the correctness of information prior to it being injected, so as to avoid polluting routing tables with invalid information.
このプロトコルを使用してルーティングドメインを外部ルーティングドメインに接続するルーターを操作する場合、このルーティングドメインから外部ルーティングドメインに安全でない可能性のある信頼できない情報が挿入されないように注意する必要があります。また、無効な情報でルーティングテーブルを汚染しないように、注入前に情報の正確さを検証するように注意する必要があります。
A recommended way of extending connectivity from an external routing domain to this routing domain, which is routed using this protocol, is to assign an IP prefix (under the authority of the routers/ gateways connecting this routing domain with the external routing domain) exclusively to this routing domain and to configure the gateways to advertise routes for that IP prefix into the external routing domain.
このプロトコルを使用してルーティングされる外部ルーティングドメインからこのルーティングドメインへの接続を拡張する推奨される方法は、（このルーティングドメインを外部ルーティングドメインに接続するルーター/ゲートウェイの権限の下で）排他的にIPプレフィックスを割り当てることですこのルーティングドメインと、ゲートウェイを構成して、そのIPプレフィックスのルートを外部ルーティングドメインにアドバタイズします。
A conformant implementation of OLSRv2 MUST, at minimum, implement the security mechanisms specified in [RFC7183], providing integrity and replay protection of OLSRv2 control messages, including of HELLO messages specified by [RFC6130] and used by OLSRv2, by inclusion of a timestamp TLV and an Integrity Check Value (ICV) TLV. This ICV TLV uses a SHA-256-based HMAC and one or more manually managed shared secret keys. The timestamp TLV is based on Portable Operating System Interface (POSIX) time, assuming router time synchronization.
OLSRv2の適合実装は、少なくとも[RFC7183]で指定されたセキュリティメカニズムを実装する必要があり、[RFC6130]で指定され、OLSRv2で使用されるHELLOメッセージを含め、OLSRv2制御メッセージの整合性と再生保護を提供し、タイムスタンプTLVを含める必要があります。完全性チェック値（ICV）TLV。このICV TLVは、SHA-256ベースのHMACと1つ以上の手動で管理された共有秘密鍵を使用します。タイムスタンプTLVは、ルーター時間の同期を想定して、ポータブルオペレーティングシステムインターフェイス（POSIX）時間に基づいています。
The baseline use case, for which this security mechanism provides adequate integrity protection without rekeying, is for short-lived (for example, up to a couple of months) OLSRv2 deployments.
このセキュリティメカニズムが鍵の再生成なしで適切な整合性保護を提供するベースラインユースケースは、存続期間が短い（たとえば、数か月まで）OLSRv2展開用です。
Any deployment of OLSRv2 SHOULD use the security mechanism specified in [RFC7183] but MAY use another mechanism if more appropriate in an OLSRv2 deployment. For example, for longer-term OLSRv2 deployments, alternative security mechanisms (e.g., rekeying) SHOULD be considered.
OLSRv2の展開では、[RFC7183]で指定されているセキュリティメカニズムを使用する必要があります（SHOULD）が、OLSRv2の展開でより適切な場合は、別のメカニズムを使用できます。たとえば、長期間のOLSRv2展開では、代替のセキュリティメカニズム（たとえば、キーの再生成）を検討する必要があります（SHOULD）。
This specification, as well as [RFC7183], does not mandate automated key management (AKM) as part of the security architecture for OLSRv2. While some use cases for OLSRv2 may require AKM, the baseline assumption is that many use cases do not, for the reasons detailed below.
この仕様と[RFC7183]は、自動鍵管理（AKM）をOLSRv2のセキュリティアーキテクチャの一部として義務付けていません。 OLSRv2の一部のユースケースではAKMが必要になる場合がありますが、ベースラインの想定では、以下に詳述する理由により、多くのユースケースでは不要であるとされています。
Bootstrapping a key is hard in a radio network, where it is, in general, not possible to determine from where a received signal was transmitted or if two transmissions come from the same or from different sources.
無線ネットワークでは、キーのブートストラップは困難です。無線ネットワークでは、一般に、受信信号がどこから送信されたか、または2つの送信が同じまたは異なるソースからのものであるかどうかを判別することはできません。
The widespread use of radio networks and mobile phone networks works under the assumptions that (i) secret information is embedded in mobile phones at manufacture, and (ii) a centralized database of this is accessible during the network lifetime.
The widespread use of radio networks and mobile phone networks works under the assumptions that (i) secret information is embedded in mobile phones at manufacture, and (ii) a centralized database of this is accessible during the network lifetime.
As a primary use case of a MANET is to provide connectivity without centralized entities and with minimal management, a solution such as described in the previous paragraph is not feasible. In many instances, a cryptographic authority may not be present in the MANET at all, since such a cryptographic authority would be too vulnerable. Due to the potentially dynamic topology of a MANET, a cryptographic authority may also become unreachable (to some or all of the MANET routers) without prior warning.
MANETの主な使用例は、一元化されたエンティティを使用せず、最小限の管理で接続を提供することであるため、前の段落で説明したようなソリューションは現実的ではありません。多くの場合、暗号化機関は脆弱すぎるため、MANETにはまったく存在しない可能性があります。 MANETの動的トポロジの可能性があるため、事前の警告なしに、暗号機関が（一部またはすべてのMANETルーターに）到達できなくなる可能性もあります。
[BCP107] provides guidelines for cryptographic key management. Specifically, Section 2.1 sets forth requirements for when AKM is required, and Section 2.2 sets forth conditions under which manual key management is acceptable.
[BCP107]は、暗号化キー管理のガイドラインを提供します。具体的には、2.1項ではAKMが必要な場合の要件を示し、2.2項では手動による鍵管理が許容される条件を示します。
Section 2.1 of [BCP107] stipulates that "Automated key management MUST be used if any of [a set of given] conditions hold". These conditions are listed below, and arguments for each are provided in regard to their applicability for the baseline use case of OLSRv2.
[BCP107]のセクション2.1は、「[一連の所定の]条件のいずれかが満たされた場合、自動キー管理を使用する必要がある」と規定しています。これらの条件を以下にリストし、OLSRv2のベースラインユースケースへの適用性に関して、それぞれの引数を示します。
o A party will have to manage n^2 static keys, where n may become large.
o パーティはn ^ 2個の静的キーを管理する必要があります。nは大きくなる可能性があります。
The baseline use case of OLSRv2 uses only one or a small set of manually managed shared secrets in the whole MANET.
OLSRv2のベースラインユースケースでは、MANET全体で手動で管理された共有秘密の1つまたは少数のセットのみを使用します。
o Any stream cipher (such as RC4 [RFC6229][RC4], AES-CTR [RFC3610][NIST-SP-800-38A], or AES-CCM [RFC3686][NIST-SP-800-38C]) is used.
o 任意のストリーム暗号（RC4 [RFC6229] [RC4]、AES-CTR [RFC3610] [NIST-SP-800-38A]、またはAES-CCM [RFC3686] [NIST-SP-800-38C]など）が使用されます。
A stream cipher is not envisioned for use to generate ICVs for OLSRv2 control messages.
ストリーム暗号は、OLSRv2制御メッセージのICVを生成するために使用することは想定されていません。
o An initialization vector (IV) might be reused, especially an implicit IV. Note that random or pseudo-random explicit IVs are not a problem unless the probability of repetition is high.
o An initialization vector (IV) might be reused, especially an implicit IV. Note that random or pseudo-random explicit IVs are not a problem unless the probability of repetition is high.
An IV is not envisioned for use to generate ICVs for OLSRv2 control messages.
IVは、OLSRv2制御メッセージのICVを生成するために使用することは想定されていません。
o Large amounts of data might need to be encrypted in a short time, causing frequent change of the short-term session key.
o 大量のデータを短時間で暗号化する必要があり、短期間のセッションキーが頻繁に変更される可能性があります。
Integrity Check Values (ICVs) are required only for OLSRv2 control messages, which are low-volume messages.
整合性チェック値（ICV）は、少量のメッセージであるOLSRv2制御メッセージにのみ必要です。
o Long-term session keys are used by more than two parties. Multicast is a necessary exception, but multicast key management standards are emerging in order to avoid this in the future. Sharing long-term session keys should generally be discouraged.
o 長期セッションキーは、3つ以上の当事者によって使用されます。マルチキャストは必要な例外ですが、将来これを回避するために、マルチキャストキー管理標準が登場しています。長期間のセッションキーを共有することは、一般的にお勧めできません。
OLSRv2 control messages are all sent using link-local multicast.
OLSRv2制御メッセージはすべて、リンクローカルマルチキャストを使用して送信されます。
o The likely operational environment is one where personnel (or device) turnover is frequent, causing frequent change of the short-term session key.
o 考えられる運用環境は、人員（またはデバイス）の入れ替わりが頻繁で、短期間のセッションキーが頻繁に変更される環境です。
This is not an intended deployment of OLSRv2. For longer-term OLSRv2 deployments, alternative security mechanisms (e.g., including rekeying) SHOULD be considered.
これは、OLSRv2の意図された展開ではありません。長期間のOLSRv2展開では、代替のセキュリティメカニズム（例：鍵の再生成を含む）を検討する必要があります（SHOULD）。
Section 2.2 of [BCP107] stipulates that "Manual key management may be a reasonable approach in any of [a given set of] situations". These situations are listed below, and arguments for each are provided in regard to their applicability for the baseline use case of OLSRv2.
[BCP107]のセクション2.2は、「手動の鍵管理は、[特定の一連の]状況のいずれにおいても、合理的なアプローチである可能性がある」と規定しています。これらの状況を以下に示し、OLSRv2のベースラインユースケースへの適用性に関して、それぞれの引数を示します。
o The environment has very limited available bandwidth or very high round-trip times. Public key systems tend to require long messages and lots of computation; symmetric key alternatives, such as Kerberos, often require several round trips and interaction with third parties.
o 環境で使用可能な帯域幅が非常に制限されているか、ラウンドトリップ時間が非常に長い。公開鍵システムは、長いメッセージと多くの計算を必要とする傾向があります。 Kerberosなどの対称キーの代替では、多くの場合、いくつかのラウンドトリップとサードパーティとの対話が必要です。
As previously noted, there may not be the required infrastructure (cryptographic authority) present (or, if present, may not be reachable) in the MANET. Bandwidth in a MANET is commonly limited, both by being a radio environment and by the need for any signaling to consume a minimal proportion thereof, and round trip times may also be significant.
前述のように、MANETに必要なインフラストラクチャ（暗号化機関）が存在しない（または存在する場合は到達できない）場合があります。 MANETの帯域幅は、通常、無線環境であることと、信号の最小比率を消費する必要があることの両方によって制限され、往復時間も重要になる場合があります。
o The information being protected has low value.
o 保護されている情報の価値は低いです。
This depends on the OLSRv2 use case, but the information being protected is OLSRv2 control traffic, which is of at least moderate value; thus, this case does not apply.
これはOLSRv2の使用例に依存しますが、保護される情報はOLSRv2制御トラフィックであり、少なくとも中程度の値です。したがって、このケースは適用されません。
o The total volume of traffic over the entire lifetime of the long-term session key will be very low.
o 長期セッションキーのライフタイム全体にわたるトラフィックの総量は非常に少なくなります。
Integrity Check Values (ICVs) are required only for OLSRv2 control messages, which are low-volume messages.
整合性チェック値（ICV）は、少量のメッセージであるOLSRv2制御メッセージにのみ必要です。
o The scale of each deployment is very limited.
o 各展開の規模は非常に限られています。
A typical use case for OLSRv2 may involve only tens of devices -- with even the largest use cases for OLSRv2 being small by Internet standards.
OLSRv2の一般的なユースケースには数十のデバイスしか含まれない場合があります-OLSRv2の最大のユースケースでさえインターネット標準では小さいです。
This specification defines one Message Type, which has been allocated from the "Message Types" registry of [RFC5444], two Message TLV Types, which have been allocated from the "Message TLV Types" registry of [RFC5444], and four Address Block TLV Types, which have been allocated from the "Address Block TLV Types" registry of [RFC5444].
この仕様は、[RFC5444]の「メッセージタイプ」レジストリから割り当てられた1つのメッセージタイプ、[RFC5444]の「メッセージTLVタイプ」レジストリから割り当てられた2つのメッセージTLVタイプ、および4つのアドレスブロックTLVを定義します。 [RFC5444]の「Address Block TLV Types」レジストリから割り当てられたタイプ。
For the registries where an Expert Review is required, the designated expert SHOULD take the same general recommendations into consideration as are specified by [RFC5444].
専門家レビューが必要なレジストリの場合、指定された専門家は、[RFC5444]で指定されているものと同じ一般的な推奨事項を考慮する必要があります（SHOULD）。
This specification defines one Message Type, allocated from the 0-223 range of the "Message Types" namespace defined in [RFC5444], as specified in Table 8.
この仕様は、[RFC5444]で定義されている「メッセージタイプ」名前空間の0〜223の範囲から割り当てられた1つのメッセージタイプを定義します（表8を参照）。
+------+----------------------------------------------+
| Type | Description |
+------+----------------------------------------------+
| 1 | TC : Topology Control (MANET-wide signaling) |
+------+----------------------------------------------+
Table 8: Message Type Assignment
表8：メッセージタイプの割り当て
IANA has created a registry for Message-Type-specific Message TLVs for TC messages, in accordance with Section 6.2.1 of [RFC5444] and with initial assignments and allocation policies as specified in Table 9.
IANAは、[RFC5444]のセクション6.2.1に従い、表9に指定されている初期割り当てと割り当てポリシーに従って、TCメッセージのメッセージタイプ固有のメッセージTLVのレジストリを作成しました。
+---------+-------------+-------------------+
| Type | Description | Allocation Policy |
+---------+-------------+-------------------+
| 128-223 | Unassigned | Expert Review |
+---------+-------------+-------------------+
Table 9: TC Message-Type-Specific Message TLV Types
表9：TCメッセージタイプ固有のメッセージTLVタイプ
IANA has created a registry for Message-Type-specific Address Block TLVs for TC messages, in accordance with Section 6.2.1 of [RFC5444] and with initial assignments and allocation policies as specified in Table 10.
IANA has created a registry for Message-Type-specific Address Block TLVs for TC messages, in accordance with Section 6.2.1 of [RFC5444] and with initial assignments and allocation policies as specified in Table 10.
+---------+-------------+-------------------+
| Type | Description | Allocation Policy |
+---------+-------------+-------------------+
| 128-223 | Unassigned | Expert Review |
+---------+-------------+-------------------+
Table 10: TC Message-Type-Specific Address Block TLV Types
表10：TCメッセージタイプ固有のアドレスブロックTLVタイプ
This specification defines two Message TLV Types, which have been allocated from the "Message TLV Types" namespace defined in [RFC5444]. IANA has made allocations in the 0-127 range for these types. Two new Type Extension registries have been created with assignments as specified in Table 11 and Table 12. Specifications of these TLVs are in Section 13.3.1. Each of these TLVs MUST NOT be included more than once in a Message TLV Block.
この仕様は、[RFC5444]で定義されている「メッセージTLVタイプ」名前空間から割り当てられた2つのメッセージTLVタイプを定義します。 IANAは、これらのタイプに0〜127の範囲で割り当てを行いました。表11および表12で指定された割り当てを使用して、2つの新しいタイプ拡張レジストリが作成されました。これらのTLVの仕様は、セクション13.3.1にあります。これらの各TLVは、メッセージTLVブロックに2回以上含めることはできません。
+-------------+------+-----------+---------------------+------------+
| Name | Type | Type | Description | Allocation |
| | | Extension | | Policy |
+-------------+------+-----------+---------------------+------------+
| MPR_WILLING | 7 | 0 | Bits 0-3 specify | |
| | | | the originating | |
| | | | router's | |
| | | | willingness to act | |
| | | | as a flooding MPR; | |
| | | | bits 4-7 specify | |
| | | | the originating | |
| | | | router's | |
| | | | willingness to act | |
| | | | as a routing MPR. | |
| MPR_WILLING | 7 | 1-255 | Unassigned. | Expert |
| | | | | Review |
+-------------+------+-----------+---------------------+------------+
Table 11: Message TLV Type Assignment: MPR_WILLING
表11：メッセージTLVタイプの割り当て：MPR_WILLING
+--------------+------+-----------+--------------------+------------+
| Name | Type | Type | Description | Allocation |
| | | Extension | | Policy |
+--------------+------+-----------+--------------------+------------+
| CONT_SEQ_NUM | 8 | 0 | COMPLETE: | |
| | | | Specifies a | |
| | | | content sequence | |
| | | | number for this | |
| | | | complete message. | |
| CONT_SEQ_NUM | 8 | 1 | INCOMPLETE: | |
| | | | Specifies a | |
| | | | content sequence | |
| | | | number for this | |
| | | | incomplete | |
| | | | message. | |
| CONT_SEQ_NUM | 8 | 2-255 | Unassigned. | Expert |
| | | | | Review |
+--------------+------+-----------+--------------------+------------+
Table 12: Message TLV Type Assignment: CONT_SEQ_NUM
表12：メッセージTLVタイプの割り当て：CONT_SEQ_NUM
Type extensions indicated as Expert Review SHOULD be allocated as described in [RFC5444], based on Expert Review as defined in [RFC5226].
[RFC5226]で定義されているエキスパートレビューに基づいて、[RFC5444]で説明されているように、エキスパートレビューとして示される型拡張を割り当てる必要があります。
This specification defines four Address Block TLV Types, which have been allocated from the "Address Block TLV Types" namespace defined in [RFC5444]. IANA has made allocations in the 8-127 range for these types. Four new Type Extension registries have been created with assignments as specified in Tables 13, 14, 15, and 16. Specifications of these TLVs are in Section 13.3.2.
この仕様は、[RFC5444]で定義されている「アドレスブロックTLVタイプ」名前空間から割り当てられた4つのアドレスブロックTLVタイプを定義しています。 IANAは、これらのタイプに8〜127の範囲で割り当てを行いました。表13、14、15、および16で指定された割り当てで、4つの新しいタイプ拡張レジストリが作成されました。これらのTLVの仕様は、セクション13.3.2にあります。
The registration procedure for the "LINK_METRIC Address Block TLV Type Extensions" registry is Expert Review.
「LINK_METRICアドレスブロックTLVタイプ拡張」レジストリの登録手順は、エキスパートレビューです。
+-------------+------+-----------+----------------------------------+
| Name | Type | Type | Description |
| | | Extension | |
+-------------+------+-----------+----------------------------------+
| LINK_METRIC | 7 | 0 | Link metric meaning assigned by |
| | | | administrative action. |
| LINK_METRIC | 7 | 1-223 | Unassigned. |
| LINK_METRIC | 7 | 224-255 | Reserved for Experimental Use |
+-------------+------+-----------+----------------------------------+
Table 13: Address Block TLV Type Assignment: LINK_METRIC
表13：アドレスブロックTLVタイプの割り当て：LINK_METRIC
All LINK_METRIC TLVs, whatever their type extension, MUST use their value field to encode the kind and value (in the interval MINIMUM_METRIC to MAXIMUM_METRIC, inclusive) of a link metric as specified in Sections 6 and 13.3.2. An assignment of a LINK_METRIC TLV type extension MUST specify the physical meaning of the link metric and the mapping of that physical meaning to the representable values in the indicated interval.
All LINK_METRIC TLVs, whatever their type extension, MUST use their value field to encode the kind and value (in the interval MINIMUM_METRIC to MAXIMUM_METRIC, inclusive) of a link metric as specified in Sections 6 and 13.3.2. An assignment of a LINK_METRIC TLV type extension MUST specify the physical meaning of the link metric and the mapping of that physical meaning to the representable values in the indicated interval.
+------+------+-----------+----------------------------+------------+
| Name | Type | Type | Description | Allocation |
| | | Extension | | Policy |
+------+------+-----------+----------------------------+------------+
| MPR | 8 | 0 | Specifies that a given | |
| | | | network address is of a | |
| | | | router selected as a | |
| | | | flooding MPR (FLOODING = | |
| | | | 1), that a given network | |
| | | | address is of a router | |
| | | | selected as a routing MPR | |
| | | | (ROUTING = 2), or both | |
| | | | (FLOOD_ROUTE = 3). | |
| MPR | 8 | 1-255 | Unassigned. | Expert |
| | | | | Review |
+------+------+-----------+----------------------------+------------+
Table 14: Address Block TLV Type Assignment: MPR
表14：アドレスブロックTLVタイプの割り当て：MPR
+---------------+------+-----------+-------------------+------------+
| Name | Type | Type | Description | Allocation |
| | | Extension | | Policy |
+---------------+------+-----------+-------------------+------------+
| NBR_ADDR_TYPE | 9 | 0 | Specifies that a | |
| | | | given network | |
| | | | address is of a | |
| | | | neighbor reached | |
| | | | via the | |
| | | | originating | |
| | | | router, if it is | |
| | | | an originator | |
| | | | address | |
| | | | (ORIGINATOR = 1), | |
| | | | is a routable | |
| | | | address (ROUTABLE | |
| | | | = 2), or if it is | |
| | | | both | |
| | | | (ROUTABLE_ORIG = | |
| | | | 3). | |
| NBR_ADDR_TYPE | 9 | 1-255 | Unassigned. | Expert |
| | | | | Review |
+---------------+------+-----------+-------------------+------------+
Table 15: Address Block TLV Type Assignment: NBR_ADDR_TYPE
表15：アドレスブロックTLVタイプの割り当て：NBR_ADDR_TYPE
+---------+------+-----------+-------------------------+------------+
| Name | Type | Type | Description | Allocation |
| | | extension | | Policy |
+---------+------+-----------+-------------------------+------------+
| GATEWAY | 10 | 0 | Specifies that a given | |
| | | | network address is | |
| | | | reached via a gateway | |
| | | | on the originating | |
| | | | router, with value | |
| | | | equal to the number of | |
| | | | hops. | |
| GATEWAY | 10 | 1-255 | | Expert |
| | | | | Review |
+---------+------+-----------+-------------------------+------------+
Table 16: Address Block TLV Type Assignment: GATEWAY
表16：アドレスブロックTLVタイプの割り当て：ゲートウェイ
Type extensions indicated as Expert Review SHOULD be allocated as described in [RFC5444], based on Expert Review as defined in [RFC5226].
[RFC5226]で定義されているエキスパートレビューに基づいて、[RFC5444]で説明されているように、エキスパートレビューとして示される型拡張を割り当てる必要があります。
Note: This section does not require any IANA action, as the required information is included in the descriptions of the MPR and NBR_ADDR_TYPE Address Block TLVs allocated in Section 24.5. This information is recorded here for clarity and for use elsewhere in this specification.
注：必要な情報はセクション24.5で割り当てられたMPRおよびNBR_ADDR_TYPEアドレスブロックTLVの説明に含まれているため、このセクションではIANAアクションは必要ありません。この情報は、明確にするため、およびこの仕様の他の場所で使用するためにここに記録されています。
The Values that the MPR Address Block TLV can use are as follows:
MPRアドレスブロックTLVが使用できる値は次のとおりです。
o FLOODING := 1;
o フラッディング：= 1;
o ROUTING := 2;
o ROUTING := 2;
o FLOOD_ROUTE := 3.
o FLOOD_ROUTE：= 3。
The Values that the NBR_ADDR_TYPE Address Block TLV can use are follows:
NBR_ADDR_TYPEアドレスブロックTLVが使用できる値は次のとおりです。
o ORIGINATOR := 1;
o ORIGINATOR：= 1;
o ROUTABLE := 2;
o ルーティング可能：= 2;
o ROUTABLE_ORIG := 3.
o ROUTABLE_ORIG：= 3。
This specification is the result of the joint efforts of the following contributors, listed alphabetically.
この仕様は、アルファベット順にリストされた以下の貢献者の共同の努力の結果です。
o Cedric Adjih, INRIA, France, <Cedric.Adjih@inria.fr>
o Cedric Adjih、INRIA、フランス、<Cedric.Adjih@inria.fr>
o Emmanuel Baccelli, INRIA , France, <Emmanuel.Baccelli@inria.fr>
o Emmanuel Baccelli、INRIA、フランス、<Emmanuel.Baccelli@inria.fr>
o Thomas Heide Clausen, LIX, France, <T.Clausen@computer.org>
o Thomas Heide Clausen、LIX、フランス、<T.Clausen@computer.org>
o Justin Dean, NRL, USA, <jdean@itd.nrl.navy.mil>
o Justin Dean、NRL、USA、<jdean@itd.nrl.navy.mil>
o Christopher Dearlove, BAE Systems, UK, <chris.dearlove@baesystems.com>
o Christopher Dearlove、BAE Systems、英国、<chris.dearlove@baesystems.com>
o Ulrich Herberg, Fujitsu Laboratories of America, USA, <ulrich@herberg.name>
o うｌりｃｈ へｒべｒｇ、 ふじつ ぁぼらとりえｓ おｆ あめりか、 うさ、 ＜うｌりｃｈ＠へｒべｒｇ。なめ＞
o Satoh Hiroki, Hitachi SDL, Japan, <hiroki.satoh.yj@hitachi.com>
o Satoh Hiroki, Hitachi SDL, Japan, <hiroki.satoh.yj@hitachi.com>
o Philippe Jacquet, Alcatel Lucent Bell Labs, France, <philippe.jacquet@alcatel-lucent.fr>
o Philippe Jacquet、アルカテルルーセントベルラボ、フランス、<philippe.jacquet@alcatel-lucent.fr>
o Monden Kazuya, Hitachi SDL, Japan, <kazuya.monden.vw@hitachi.com>
o もんでん かずや、 ひたち ＳＤＬ、 じゃぱん、 ＜かずや。もんでん。ｖｗ＠ひたち。こｍ＞
o Kenichi Mase, Niigata University, Japan, <mase@ie.niigata-u.ac.jp>
o けにち ませ、 にいがた うにゔぇｒしｔｙ、 じゃぱん、 ＜ませ＠いえ。にいがたーう。あｃ。ｊｐ＞
o Ryuji Wakikawa, Toyota, Japan, <ryuji@sfc.wide.ad.jp>
o りゅじ わきかわ、 とよた、 じゃぱん、 ＜りゅじ＠ｓｆｃ。うぃで。あｄ。ｊｐ＞
The authors would like to acknowledge the team behind OLSRv1, as listed in RFC 3626, including Anis Laouiti (INT), Pascale Minet (INRIA), Paul Muhlethaler (INRIA), Amir Qayyum (M.A. Jinnah University), and Laurent Viennot (INRIA) for their contributions.
著者は、RFS 3626にリストされているOLSRv1の背後にあるチームを認めたいと思います。これには、アニスラウイティ（INT）、パスカルミネット（INRIA）、ポールミューレターラー（INRIA）、アミールカイユム（MAジンナー大学）、およびローランヴィエノット（INRIA）が含まれます。彼らの貢献のために。
The authors would like to gratefully acknowledge the following people for intense technical discussions, early reviews, and comments on the specification and its components (listed alphabetically): Khaldoun Al Agha (LRI), Teco Boot (Infinity Networks), Ross Callon (Juniper), Song-Yean Cho (Samsung), Alan Cullen (BAE Systems), Louise Lamont (CRC), Li Li (CRC), Joseph Macker (NRL), Richard Ogier (SRI), Charles E. Perkins (Futurewei), Henning Rogge (Frauenhofer FKIE), and the entire IETF MANET Working Group.
著者は、仕様とそのコンポーネント（アルファベット順）に関する激しい技術的な議論、初期のレビュー、コメントについて、以下の人々に感謝の意を表します：Khaldoun Al Agha（LRI）、Teco Boot（Infinity Networks）、Ross Callon（Juniper） 、Song-Yean Cho（Samsung）、Alan Cullen（BAE Systems）、Louise Lamont（CRC）、Li Li（CRC）、Joseph Macker（NRL）、Richard Ogier（SRI）、Charles E. Perkins（Futurewei）、Henning Rogge （フラウエンホーファーFKIE）、およびIETF MANETワーキンググループ全体。
Finally, the authors would like to express their gratitude to the Area Directors for providing valuable review comments during the IESG evaluation, in particular (listed alphabetically) Benoit Claise, Adrian Farrel, Stephen Farrell, Barry Leiba, Pete Resnick, and Martin Stiemerling.
最後に、著者はIESG評価中に貴重なレビューコメントを提供してくれたエリアディレクター、特にBenoit Claise、Adrian Farrel、Stephen Farrell、Stephen Farrell、Barry Leiba、Pete Resnick、Martin Stiemerlingに感謝の意を表します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter Considerations in Mobile Ad Hoc Networks (MANETs)", RFC 5148, February 2008.
[RFC5148] Clausen、T.、Dearlove、C。、およびB. Adamson、「モバイルアドホックネットワーク（MANET）におけるジッタの考慮事項」、RFC 5148、2008年2月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, "Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format", RFC 5444, February 2009.
[RFC5444] Clausen、T.、Dearlove、C.、Dean、J。、およびC. Adjih、「Generalized Mobile Ad Hoc Network（MANET）Packet / Message Format」、RFC 5444、2009年2月。
[RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, March 2009.
[RFC5497] Clausen、T.およびC. Dearlove、「Representing Multi-Value Time in Mobile Ad Hoc Networks（MANETs）」、RFC 5497、2009年3月。
[RFC5498] Chakeres, I., "IANA Allocations for Mobile Ad Hoc Network (MANET) Protocols", RFC 5498, March 2009.
[RFC5498] Chakeres、I。、「モバイルアドホックネットワーク（MANET）プロトコルのIANA割り当て」、RFC 5498、2009年3月。
[RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)", RFC 6130, April 2011.
[RFC6130] Clausen、T.、Dearlove、C。、およびJ. Dean、「Mobile Ad Hoc Network（MANET）Neighborhood Discovery Protocol（NHDP）」、RFC 6130、2011年4月。
[RFC7182] Herberg, U., Clausen, T., and C. Dearlove, "Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)", RFC 7182, April 2014.
[RFC7182] Herberg、U.、Clauseen、T。、およびC. Dearlove、「Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks（MANETs）」、RFC 7182、2014年4月。
[RFC7183] Herberg, U., Dearlove, C., and T. Clausen, "Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2)", RFC 7183, April 2014.
[RFC7183] Herberg、U.、Dearlove、C。、およびT. Clausen、「Integrity Protection for the Neighborhood Discovery Protocol（NHDP）and Optimized Link State Routing Protocol Version 2（OLSRv2）」、RFC 7183、2014年4月。
[BCP107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005.
[BCP107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005.
[FSLS] Santivanez, C., Ramanathan, R., and I. Stavrakakis, "Making Link-State Routing Scale for Ad Hoc Networks", MobiHoc '01, Proceedings of the 2nd ACM International Symposium on Mobile Ad Hoc Networking & Computing, 2001.
[FSLS] Santivanez、C.、Ramanathan、R。、およびI. Stavrakakis、「Making Link-State Routing Scale for Ad Hoc Networks」、MobiHoc '01、Proceedings of the 2nd ACM International Symposium on Mobile Ad Hoc Networking＆Computing、 2001年。
[FSR] Pei, G., Gerla, M., and T. Chen, "Fisheye State Routing in Mobile Ad Hoc Networks", ICDCS Workshop on Wireless Networks and Mobile Computing, 2000.
[FSR] Pei、G.、Gerla、M。、およびT. Chen、「モバイルアドホックネットワークにおけるフィッシュアイステートルーティング」、ワイヤレスネットワークとモバイルコンピューティングに関するICDCSワークショップ、2000年。
[HIPERLAN] ETSI, "Radio Equipment and Systems (RES); HIgh PErformance Radio Local Area Network (HIPERLAN) Type 1; Functional Specification", ETSI 300-652, June 1996.
[HIPERLAN] ETSI、「無線機器とシステム（RES）、高性能無線ローカルエリアネットワーク（HIPERLAN）タイプ1、機能仕様」、ETSI 300-652、1996年6月。
[HIPERLAN2] Jacquet, P., Minet, P., Muhlethaler, P., and N. Rivierre, "Increasing Reliability in Cable-Free Radio LANs: Low Level Forwarding in HIPERLAN", Wireless Personal Communications, Volume 4, Issue 1, 1997.
[HIPERLAN2] Jacquet、P.、Minet、P.、Muhlethaler、P。、およびN. Rivierre、「ケーブルフリー無線LANの信頼性の向上：HIPERLANでの低レベル転送」、ワイヤレスパーソナルコミュニケーション、第4巻、第1号1997年
[MPR] Qayyum, A., Viennot, L., and A. Laouiti, "Multipoint relaying: An efficient technique for flooding in mobile wireless Networks", INRIA, No. 3898, March 2000.
[MPR] Qayyum、A.、Viennot、L。、およびA. Laouiti、「マルチポイントリレー：モバイルワイヤレスネットワークにおけるフラッディングのための効率的な手法」、INRIA、No。3898、2000年3月。
[McCabe] McCabe, A., Dearlove, C., Fredin, M., and L. Axelsson, "Scalability modelling of ad hoc routing protocols - a comparison of OLSR and DSR", Scandinavian Wireless Adhoc Networks '04, 2004.
[McCabe] McCabe、A.、Dearlove、C.、Fredin、M。、およびL. Axelsson、「アドホックルーティングプロトコルのスケーラビリティモデリング-OLSRとDSRの比較」、スカンジナビアワイヤレスアドホックネットワーク'04、2004。
[NIST-SP-800-38A] National Institute of Standards and Technology, "Recommendation for Block Cipher Modes of Operation: Methods and Techniques", Special Publication 800-38A, December 2001.
[NIST-SP-800-38A]米国国立標準技術研究所、「ブロック暗号の動作モードの推奨：方法と手法」、特別刊行物800-38A、2001年12月。
[NIST-SP-800-38C] National Institute of Standards and Technology, "Recommendation for Block Cipher Modes of Operation: The CCM Mode for Authentication and Confidentiality", Special Publication 800-38C, May 2004.
[NIST-SP-800-38C]米国国立標準技術研究所、「ブロック暗号化動作モードの推奨：認証と機密性のためのCCMモード」、特別刊行物800-38C、2004年5月。
[RC4] Schneier, B., "Applied Cryptography: Protocols, Algorithms, and Source Code in C", Second Edition, John Wiley and Sons, New York, 1996.
[RC4] Schneier、B。、「Applied Cryptography：Protocols、Algorithms、and Source Code in C」、Second Edition、John Wiley and Sons、ニューヨーク、1996。
[RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations", RFC 2501, January 1999.
[RFC2501] Corson、M.およびJ. Macker、「モバイルアドホックネットワーキング（MANET）：ルーティングプロトコルのパフォーマンスの問題と評価に関する考慮事項」、RFC 2501、1999年1月。
[RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with CBC-MAC (CCM)", RFC 3610, September 2003.
[RFC3610] Whiting、D.、Housley、R。、およびN. Ferguson、「Counter with CBC-MAC（CCM）」、RFC 3610、2003年9月。
[RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing Protocol (OLSR)", RFC 3626, October 2003.
[RFC3626] Clausen、T。およびP. Jacquet、「Optimized Link State Routing Protocol（OLSR）」、RFC 3626、2003年10月。
[RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686, January 2004.
[RFC3686] Housley、R。、「IPsecカプセル化セキュリティペイロード（ESP）でのAdvanced Encryption Standard（AES）カウンターモードの使用」、RFC 3686、2004年1月。
[RFC6229] Strombergson, J. and S. Josefsson, "Test Vectors for the Stream Cipher RC4", RFC 6229, May 2011.
[RFC6229] Strombergson、J。およびS. Josefsson、「Test Vectors for the Stream Cipher RC4」、RFC 6229、2011年5月。
Updates to the Local Information Base, the Neighborhood Information Base, or the Topology Information Base MUST ensure that all constraints specified in this appendix are maintained, as well as those specified in [RFC6130]. This is the case for the processing, specified in this document. Any protocol extension or outside process, which updates the Neighborhood Information Base or the Topology Information Base, MUST also ensure that these constraints are maintained.
Local Information Base、Neighborhood Information Base、またはTopology Information Baseの更新は、この付録で指定されているすべての制約、および[RFC6130]で指定されている制約が維持されていることを確認する必要があります。これは、このドキュメントで指定されている処理の場合です。 Neighborhood Information BaseまたはTopology Information Baseを更新するプロトコル拡張または外部プロセスも、これらの制約が確実に維持されるようにする必要があります。
In each Originator Tuple:
各オリジネータータプルで：
o O_orig_addr MUST NOT equal any other O_orig_addr.
o O_orig_addrは、他のO_orig_addrと等しくてはいけません。
o O_orig_addr MUST NOT equal this router's originator address.
o O_orig_addrは、このルーターの発信元アドレスと同じであってはなりません（MUST NOT）。
In each Local Attached Network Tuple:
各ローカル接続ネットワークタプル：
o AL_net_addr MUST NOT equal any other AL_net_addr.
o AL_net_addrは、他のAL_net_addrと同じであってはなりません。
o AL_net_addr MUST NOT equal or be a sub-range of any network address in the I_local_iface_addr_list of any Local Interface Tuple.
o AL_net_addr MUST NOT equal or be a sub-range of any network address in the I_local_iface_addr_list of any Local Interface Tuple.
o AL_net_addr MUST NOT equal this router's originator address or equal the O_orig_addr in any Originator Tuple.
o AL_net_addrは、このルーターの発信元アドレスと等しくないか、どの発信元タプルのO_orig_addrとも等しくてはなりません（MUST NOT）。
o AL_dist MUST NOT be less than zero.
o AL_distはゼロ未満であってはなりません。
In each Link Tuple:
各リンクタプル：
o L_neighbor_iface_addr_list MUST NOT contain any network address that AL_net_addr of any Local Attached Network Tuple equals or is a sub-range of.
o L_neighbor_iface_addr_listには、ローカル接続ネットワークタプルのAL_net_addrが等しいか、そのサブ範囲であるネットワークアドレスを含めてはなりません。
o If L_in_metric != UNKNOWN_METRIC, then L_in_metric MUST be representable in the defined compressed form.
o L_in_metric！= UNKNOWN_METRICの場合、L_in_metricは定義された圧縮形式で表現できる必要があります。
o If L_out_metric != UNKNOWN_METRIC, then L_out_metric MUST be representable in the defined compressed form.
o L_out_metric！= UNKNOWN_METRICの場合、L_out_metricは定義された圧縮形式で表現できる必要があります。
o If L_mpr_selector = true, then L_status = SYMMETRIC.
o L_mpr_selector = trueの場合、L_status = SYMMETRIC。
In each Neighbor Tuple:
各ネイバータプルで：
o N_orig_addr MUST NOT be changed to unknown.
o N_orig_addrを不明に変更してはなりません（MUST NOT）。
o N_orig_addr MUST NOT equal this router's originator address or equal O_orig_addr in any Originator Tuple.
o N_orig_addrは、このルーターの発信元アドレスまたは発信元タプルのO_orig_addrと等しくてはなりません（MUST NOT）。
o N_orig_addr MUST NOT equal the AL_net_addr in any Local Attached Network Tuple.
o N_orig_addrは、ローカル接続ネットワークタプルのAL_net_addrと等しくてはなりません。
o If N_orig_addr != unknown, then N_orig_addr MUST NOT equal the N_orig_addr in any other Neighbor Tuple.
o N_orig_addr！=が不明の場合、N_orig_addrは、他の近隣タプルのN_orig_addrと等しくてはなりません（MUST NOT）。
o N_neighbor_addr_list MUST NOT contain any network address that includes this router's originator address, the O_orig_addr in any Originator Tuple, or equal or have as a sub-range the AL_net_addr in any Local Attached Network Tuple.
o N_neighbor_addr_listには、このルーターのオリジネーターアドレスを含むネットワークアドレス、Originator TupleのO_orig_addr、またはローカル接続ネットワークタプルのAL_net_addrと等しいか、サブレンジとして持つことはできません。
o If N_orig_addr = unknown, then N_will_flooding = WILL_NEVER, N_will_routing = WILL_NEVER, N_flooding_mpr = false, N_routing_mpr = false, N_mpr_selector = false, and N_advertised = false.
o N_orig_addr =不明の場合、N_will_flooding = WILL_NEVER、N_will_routing = WILL_NEVER、N_flooding_mpr = false、N_routing_mpr = false、N_mpr_selector = false、N_advertised = false。
o N_in_metric MUST equal the minimum value of the L_in_metric values of all corresponding Link Tuples with L_status = SYMMETRIC and L_in_metric != UNKNOWN_METRIC, if any; otherwise, N_in_metric = UNKNOWN_METRIC.
o N_in_metricは、L_status = SYMMETRICおよびL_in_metric！= UNKNOWN_METRICがある場合、対応するすべてのリンクタプルのL_in_metric値の最小値と一致する必要があります。それ以外の場合、N_in_metric = UNKNOWN_METRIC。
o N_out_metric MUST equal the minimum value of the L_out_metric values of all corresponding Link Tuples with L_status = SYMMETRIC and L_out_metric != UNKNOWN_METRIC, if any; otherwise, N_out_metric = UNKNOWN_METRIC.
o N_out_metricは、L_status = SYMMETRICおよびL_out_metric！= UNKNOWN_METRICがある場合、対応するすべてのリンクタプルのL_out_metric値の最小値と等しくなければなりません（MUST）。それ以外の場合、N_out_metric = UNKNOWN_METRIC。
o N_will_flooding and N_will_routing MUST be in the range from WILL_NEVER to WILL_ALWAYS, inclusive.
o N_will_floodingとN_will_routingは、WILL_NEVERからWILL_ALWAYSまでの範囲でなければなりません。
o If N_flooding_mpr = true, then N_symmetric MUST be true, N_out_metric MUST NOT equal UNKNOWN_METRIC, and N_will_flooding MUST NOT equal WILL_NEVER.
o N_flooding_mpr = trueの場合、N_symmetricはtrueでなければならず、N_out_metricはUNKNOWN_METRICと等しくてはならず、N_will_floodingはWILL_NEVERと等しくてはなりません（MUST NOT）。
o If N_routing_mpr = true, then N_symmetric MUST be true, N_in_metric MUST NOT equal UNKNOWN_METRIC, and N_will_routing MUST NOT equal WILL_NEVER.
o N_routing_mpr = trueの場合、N_symmetricはtrueでなければならず、N_in_metricはUNKNOWN_METRICに等しくてはならず、N_will_routingはWILL_NEVERに等しくてはなりません。
o If N_symmetric = true and N_flooding_mpr = false, then N_will_flooding MUST NOT equal WILL_ALWAYS.
o N_symmetric = trueおよびN_flooding_mpr = falseの場合、N_will_floodingはWILL_ALWAYSと等しくてはなりません。
o If N_symmetric = true and N_routing_mpr = false, then N_will_routing MUST NOT equal WILL_ALWAYS.
o N_symmetric = trueおよびN_routing_mpr = falseの場合、N_will_routingはWILL_ALWAYSと等しくてはなりません。
o If N_mpr_selector = true, then N_advertised MUST be true.
o N_mpr_selector = trueの場合、N_advertisedはtrueでなければなりません。
o If N_advertised = true, then N_symmetric MUST be true and N_out_metric MUST NOT equal UNKNOWN_METRIC.
o N_advertised = trueの場合、N_symmetricはtrueでなければならず、N_out_metricはUNKNOWN_METRICと等しくてはなりません（MUST NOT）。
In each Lost Neighbor Tuple:
Lost Neighbor Tupleごとに：
o NL_neighbor_addr MUST NOT include this router's originator address, the O_orig_addr in any Originator Tuple, or equal or have as a sub-range the AL_net_addr in any Local Attached Network Tuple.
o NL_neighbor_addrには、このルーターのオリジネーターアドレス、O_orig_addrを任意のオリジネータータプルに含めたり、ローカル接続ネットワークタプルのAL_net_addrと同じか、サブ範囲として含めたりしてはなりません（MUST NOT）。
In each 2-Hop Tuple:
各2ホップのタプル：
o N2_2hop_addr MUST NOT equal this router's originator address, equal the O_orig_addr in any Originator Tuple, or equal or have as a sub-range the AL_net_addr in any Local Attached Network Tuple.
o N2_2hop_addrは、このルーターの発信元アドレスと等しいか、任意の発信元タプルのO_orig_addrと等しいか、またはローカル接続ネットワークタプルのAL_net_addrと等しいか、サブ範囲として持つ必要があります。
o If N2_in_metric != UNKNOWN_METRIC, then N2_in_metric MUST be representable in the defined compressed form.
o N2_in_metric！= UNKNOWN_METRICの場合、N2_in_metricは定義された圧縮形式で表現できる必要があります。
o If N2_out_metric != UNKNOWN_METRIC, then N2_out_metric MUST be representable in the defined compressed form.
o N2_out_metric！= UNKNOWN_METRICの場合、N2_out_metricは定義された圧縮形式で表現できる必要があります。
In each Advertising Remote Router Tuple:
各アドバタイジングリモートルータタプルで：
o AR_orig_addr MUST NOT be in any network address in the I_local_iface_addr_list in any Local Interface Tuple or be in the IR_local_iface_addr in any Removed Interface Address Tuple.
o AR_orig_addrは、ローカルインターフェイスタプル内のI_local_iface_addr_list内のネットワークアドレス内、または削除されたインターフェイスアドレスタプル内のIR_local_iface_addr内に存在してはなりません（MUST NOT）。
o AR_orig_addr MUST NOT equal this router's originator address or equal the O_orig_addr in any Originator Tuple.
o AR_orig_addrは、このルーターのオリジネーターアドレスと等しくないか、任意のオリジネータータプルのO_orig_addrと等しくてはなりません（MUST NOT）。
o AR_orig_addr MUST NOT be in the AL_net_addr in any Local Attached Network Tuple.
o AR_orig_addrは、ローカル接続ネットワークタプルのAL_net_addrに存在してはなりません（MUST NOT）。
o AR_orig_addr MUST NOT equal the AR_orig_addr in any other Advertising Remote Router Tuple.
o AR_orig_addrは、他のアドバタイジングリモートルータタプルのAR_orig_addrと等しくてはなりません。
In each Router Topology Tuple:
各ルータートポロジタプルで：
o There MUST be an Advertising Remote Router Tuple with AR_orig_addr = TR_from_orig_addr.
o AR_orig_addr = TR_from_orig_addrを使用してアドバタイズリモートルータタプルが存在する必要があります。
o TR_to_orig_addr MUST NOT be in any network address in the I_local_iface_addr_list in any Local Interface Tuple or be in the IR_local_iface_addr in any Removed Interface Address Tuple.
o TR_to_orig_addrは、ローカルインターフェイスタプルのI_local_iface_addr_listのネットワークアドレスに含めたり、削除されたインターフェイスアドレスタプルのIR_local_iface_addrに含めたりしてはなりません。
o TR_to_orig_addr MUST NOT equal this router's originator address or equal the O_orig_addr in any Originator Tuple.
o TR_to_orig_addr MUST NOT equal this router's originator address or equal the O_orig_addr in any Originator Tuple.
o TR_to_orig_addr MUST NOT be in the AL_net_addr in any Local Attached Network Tuple.
o TR_to_orig_addrは、ローカル接続ネットワークタプルのAL_net_addrに存在してはなりません（MUST NOT）。
o The ordered pair (TR_from_orig_addr, TR_to_orig_addr) MUST NOT equal the corresponding pair for any other Router Topology Tuple.
o 順序付けられたペア（TR_from_orig_addr、TR_to_orig_addr）は、他のルータートポロジータプルの対応するペアと一致してはなりません（MUST NOT）。
o TR_seq_number MUST NOT be greater than AR_seq_number in the Advertising Remote Router Tuple with AR_orig_addr = TR_from_orig_addr.
o TR_seq_numberは、AR_orig_addr = TR_from_orig_addrを使用してアドバタイズリモートルータタプルのAR_seq_numberより大きくしてはなりません（MUST NOT）。
o TR_metric MUST be representable in the defined compressed form.
o TR_metricは、定義された圧縮形式で表現できる必要があります。
In each Routable Address Topology Tuple:
各ルーティング可能なアドレストポロジタプルでは、
o There MUST be an Advertising Remote Router Tuple with AR_orig_addr = TA_from_orig_addr.
o AR_orig_addr = TA_from_orig_addrを使用してアドバタイズリモートルータタプルが存在する必要があります。
o TA_dest_addr MUST be routable.
o TA_dest_addrはルーティング可能でなければなりません。
o TA_dest_addr MUST NOT overlap any network address in the I_local_iface_addr_list in any Local Interface Tuple or overlap the IR_local_iface_addr in any Removed Interface Address Tuple.
o TA_dest_addrは、ローカルインターフェイスタプルのI_local_iface_addr_listのネットワークアドレスと重複したり、削除されたインターフェイスアドレスタプルのIR_local_iface_addrと重複したりしてはなりません。
o TA_dest_addr MUST NOT include this router's originator address or include the O_orig_addr in any Originator Tuple.
o TA_dest_addrは、このルーターの発信元アドレスを含めたり、O_orig_addrをどの発信元タプルにも含めてはなりません（MUST NOT）。
o TA_dest_addr MUST NOT equal or have as a sub-range the AL_net_addr in any Local Attached Network Tuple.
o TA_dest_addrは、ローカル接続ネットワークタプルのAL_net_addrと等しいか、サブ範囲として持つことはできません。
o The ordered pair (TA_from_orig_addr, TA_dest_addr) MUST NOT equal the corresponding pair for any other Attached Network Tuple.
o 順序付けられたペア（TA_from_orig_addr、TA_dest_addr）は、他の接続されたネットワークタプルの対応するペアと等しくてはなりません（MUST NOT）。
o TA_seq_number MUST NOT be greater than AR_seq_number in the Advertising Remote Router Tuple with AR_orig_addr = TA_from_orig_addr.
o TA_seq_numberは、AR_orig_addr = TA_from_orig_addrを使用して、アドバタイズリモートルータタプルのAR_seq_numberより大きくしてはなりません（MUST NOT）。
o TA_metric MUST be representable in the defined compressed form.
o TA_metricは、定義された圧縮形式で表現できる必要があります。
In each Attached Network Tuple:
In each Attached Network Tuple:
o There MUST be an Advertising Remote Router Tuple with AR_orig_addr = AN_orig_addr.
o AR_orig_addr = AN_orig_addrのアドバタイズリモートルータタプルが存在する必要があります。
o AN_net_addr MUST NOT equal or be a sub-range of any network address in the I_local_iface_addr_list in any Local Interface Tuple or equal or be a sub-range of the IR_local_iface_addr in any Removed Interface Address Tuple.
o AN_net_addrは、ローカルインターフェイスタプル内のI_local_iface_addr_list内のネットワークアドレスのサブ範囲と同じか、それ以外であってはならず、削除されたインターフェイスアドレスタプル内のIR_local_iface_addrのサブ範囲と同じか、それ以外であってはなりません。
o AN_net_addr MUST NOT equal this router's originator address or equal the O_orig_addr in any Originator Tuple.
o AN_net_addrは、このルーターの発信元アドレスと等しくないか、または発信元タプル内のO_orig_addrと等しくてはなりません（MUST NOT）。
o The ordered pair (AN_orig_addr, AN_net_addr) MUST NOT equal the corresponding pair for any other Attached Network Tuple.
o 順序付けられたペア（AN_orig_addr、AN_net_addr）は、他の接続されたネットワークタプルの対応するペアと同じであってはなりません（MUST NOT）。
o AN_seq_number MUST NOT be greater than AR_seq_number in the Advertising Remote Router Tuple with AR_orig_addr = AN_orig_addr.
o AN_seq_numberは、AR_orig_addr = AN_orig_addrを使用して、アドバタイズリモートルータタプルのAR_seq_numberより大きくしてはなりません（MUST NOT）。
o AN_dist MUST NOT be less than zero.
o AN_distはゼロ未満であってはなりません。
o AN_metric MUST be representable in the defined compressed form.
o AN_metricは、定義された圧縮形式で表現できる必要があります。
The following specifies an algorithm that MAY be used to select an MPR Set given a Neighbor Graph, as defined in Section 18.2 and Section 18.3.
以下は、セクション18.2およびセクション18.3で定義されているように、ネイバーグラフが与えられたMPRセットを選択するために使用できるアルゴリズムを指定します。
This algorithm selects an MPR Set M that is a subset of the set N1 that is part of the Neighbor Graph. This algorithm assumes that a subset I of N1 is pre-selected as MPRs, i.e., that M will contain I.
このアルゴリズムは、ネイバーグラフの一部であるセットN1のサブセットであるMPRセットMを選択します。このアルゴリズムは、N1のサブセットIがMPRとして事前に選択されていること、つまりMがIを含むことを前提としています。
The following additional notation, in addition to that in Section 18.2, will be used by this algorithm:
このアルゴリズムでは、セクション18.2に加えて、次の追加表記が使用されます。
N: A subset of N2, consisting of those elements y in N2 such that either d1(y) is not defined, or there is at least one x in N1 such that d(x,y) is defined and d(x,y) < d1(y).
N：d1（y）が定義されていない、またはd（x、y）が定義され、d（x、y）が定義されているN1に少なくとも1つのxがあるN2の要素yで構成されるN2のサブセット）<d1（y）。
D(x): For an element x in N1, the number of elements y in N for which d(x,y) is defined and has minimal value among the d(z,y) for all z in N1.
D（x）：N1の要素xの場合、d（x、y）が定義され、N1のすべてのzのd（z、y）の中で最小値を持つNの要素yの数。
R(x,M): For an element x in N1, the number of elements y in N for which d(x,y) is defined has minimal value among the d(z,y) for all z in N1 and no such minimal values have z in M. (Note that, denoting the empty set by 0, D(x) = R(x,0).)
R（x、M）：N1の要素xの場合、d（x、y）が定義されているNの要素yの数は、N1のすべてのzのd（z、y）の中で最小値であり、そのようなものはありません最小値はMにzがあります（0で空のセットを表すことに注意してください、D（x）= R（x、0））。
To create the MPR Set M, starting with M := I:
M：= I：で始まるMPRセットMを作成するには
1. Add all elements x in N1 that have W(x) = WILL_ALWAYS to M.
1. W（x）= WILL_ALWAYSであるN1のすべての要素xをMに追加します。
2. For each element y in N for which there is only one element x in N1 such that d2(x,y) is defined, add that element x to M.
2. N1に要素xが1つだけあり、d2（x、y）が定義されているNの各要素yについて、その要素xをMに追加します。
3. While there exists any element x in N1 with R(x,M) > 0:
3. R（x、M）> 0のN1に要素xが存在する場合：
1. Select an element x in N1 with R(x,M) > 0 in the following order of priority, and then add to M:
1. 次の優先順位でR（x、M）> 0のN1の要素xを選択し、Mに追加します。
+ greatest W(x), THEN
+ 最大のW（x）、その後
+ greatest R(x,M), THEN
+ 最大のR（x、M）、THEN
+ greatest D(x), THEN
+ 最大D（x）、その後
+ any choice, which MAY be based on other criteria (for example, a router MAY choose to prefer a neighbor as an MPR if that neighbor has already selected the router as an MPR of the same type, MAY prefer a neighbor based on information freshness, or MAY prefer a neighbor based on length of time previously selected as an MPR) or MAY be random.
+ 他の基準に基づく可能性のある任意の選択（たとえば、ルーターが同じタイプのMPRとしてルーターをすでに選択している場合、ルーターはMPRとして隣接を優先することを選択できます。情報の鮮度に基づいて隣接を優先する可能性があります。または、以前にMPRとして選択された時間の長さに基づいてネイバーを優先する場合があります）またはランダムである場合があります。
4. OPTIONAL: consider each element x in M, but not in I, in turn and if x can be removed from M while still leaving it satisfying the definition of an MPR Set, then remove that element x from M. Elements MAY be considered in any order, e.g., in order of increasing W(x).
4. オプション：Mでは各要素xを考慮しますが、Iでは考慮しません。MPRセットの定義を満たしたまま、xをMから削除できる場合は、その要素xをMから削除します。要素は、たとえば、W（x）の増加順。
The following procedure is given as an example for calculating the Routing Set using a variation of Dijkstra's algorithm. First, all Routing Tuples are removed, and then, using the selections and definitions in Appendix C.1, the procedures in the following sections (each considered a "stage" of the processing) are applied in turn.
次の手順は、ダイクストラのアルゴリズムのバリエーションを使用してルーティングセットを計算する例として示されています。まず、すべてのルーティングタプルが削除され、次に付録C.1の選択と定義を使用して、次のセクションの手順（それぞれが処理の「段階」と見なされます）が順番に適用されます。
The following selections and definitions are made:
次の選択と定義が行われます。
1. For each Local Interface Tuple, select a network address from its I_local_iface_addr_list. This is defined as the selected address for this Local Interface Tuple.
1. ローカルインターフェイスタプルごとに、I_local_iface_addr_listからネットワークアドレスを選択します。これは、このローカルインターフェイスタプルの選択されたアドレスとして定義されます。
2. For each Link Tuple, the selected address of its corresponding Local Interface Tuple is defined as the selected local address for this Link Tuple.
2. 各リンクタプルについて、対応するローカルインターフェースタプルの選択されたアドレスは、このリンクタプルの選択されたローカルアドレスとして定義されます。
3. For each Neighbor Tuple with N_symmetric = true and N_out_metric != UNKNOWN_METRIC, select a Link Tuple with L_status = SYMMETRIC for which this is the corresponding Neighbor Tuple and has L_out_metric = N_out_metric. This is defined as the selected Link Tuple for this Neighbor Tuple.
3. N_symmetric = trueおよびN_out_metric！= UNKNOWN_METRICの各ネイバータプルについて、これが対応するネイバータプルであり、L_out_metric = N_out_metricを持つL_status = SYMMETRICのリンクタプルを選択します。これは、このネイバータプルの選択されたリンクタプルとして定義されます。
4. For each network address (N_orig_addr or in N_neighbor_addr_list, the "neighbor address") from a Neighbor Tuple with N_symmetric = true and N_out_metric != UNKNOWN_METRIC, select a Link Tuple (the "selected Link Tuple") from those for which this is the corresponding Neighbor Tuple, have L_status = SYMMETRIC, and have L_out_metric = N_out_metric, by:
4. N_symmetric = trueおよびN_out_metric！= UNKNOWN_METRICの近隣タプルからの各ネットワークアドレス（N_orig_addrまたはN_neighbor_addr_list内の「近隣アドレス」）に対して、これが対応するリンクタプル（「選択されたリンクタプル」）を選択します。ネイバータプル、L_status = SYMMETRIC、L_out_metric = N_out_metric
1. If there is such a Link Tuple whose L_neighbor_iface_addr_list contains the neighbor address, select that Link Tuple.
1. L_neighbor_iface_addr_listにネイバーアドレスが含まれるリンクタプルがある場合は、そのリンクタプルを選択します。
2. Otherwise, select the selected Link Tuple for this Neighbor Tuple.
2. それ以外の場合は、このネイバータプルに選択したリンクタプルを選択します。
Then for this neighbor address:
次に、このネイバーアドレスの場合：
3. The selected local address is defined as the selected local address for the selected Link Tuple.
3. The selected local address is defined as the selected local address for the selected Link Tuple.
4. The selected link address is defined as an address from the L_neighbor_iface_addr_list of the selected Link Tuple, if possible equal to this neighbor address.
4. 選択されたリンクアドレスは、選択されたリンクタプルのL_neighbor_iface_addr_listからのアドレスとして定義されます。可能な場合、このネイバーアドレスと同じです。
5. Routing Tuple preference is decided by preference for minimum R_metric, then for minimum R_dist, and then for preference for corresponding Neighbor Tuples in this order:
5. Routing Tuple preference is decided by preference for minimum R_metric, then for minimum R_dist, and then for preference for corresponding Neighbor Tuples in this order:
* For greater N_will_routing.
* より大きなN_will_routing。
* For N_mpr_selector = true over N_mpr_selector = false.
* N_mpr_selector = falseよりもN_mpr_selector = trueの場合。
Note that preferred Routing Tuples SHOULD be used. Routing Tuples with minimum R_metric MUST be used; this is specified outside the definition of preference. An implementation MAY modify this definition of preference (including for minimum R_dist) without otherwise affecting this algorithm.
優先ルーティングタプルを使用する必要があることに注意してください。 R_metricが最小のルーティングタプルを使用する必要があります。これは、プリファレンスの定義外で指定されています。実装は、このアルゴリズムに影響を与えることなく、この設定の定義（最小R_distを含む）を変更できます（MAY）。
The following procedure is executed once.
以下の手順は一度実行されます。
1. For each Neighbor Tuple with N_symmetric = true and N_out_metric != UNKNOWN_METRIC, add a Routing Tuple with:
1. N_symmetric = trueおよびN_out_metric！= UNKNOWN_METRICの各ネイバータプルに対して、次のルーティングタプルを追加します。
* R_dest_addr := N_orig_addr;
* R_dest_addr：= N_orig_addr;
* R_next_iface_addr := selected link address for N_orig_addr;
* R_next_iface_addr：= N_orig_addrの選択されたリンクアドレス。
* R_local_iface_addr := selected local address for N_orig_addr;
* R_local_iface_addr := selected local address for N_orig_addr;
* R_metric := N_out_metric;
* R_metric：= N_out_metric;
* R_dist := 1.
* R_dist：= 1。
The following procedure is executed once.
以下の手順は一度実行されます。
1. Add a label that may be "used" or "unused" to each Routing Tuple, with all initial values equal to unused. (Note that this label is only required during this algorithm.)
1. すべての初期値が未使用に等しい、「使用済み」または「未使用」のラベルを各ルーティングタプルに追加します。 （このラベルはこのアルゴリズムでのみ必要であることに注意してください。）
2. If there are no unused Routing Tuples, then this stage is complete; otherwise, repeat the following until that is the case.
2. 未使用のルーティングタプルがない場合、この段階は完了です。それ以外の場合は、そうなるまで以下を繰り返します。
1. Find the unused Routing Tuple with minimum R_metric (if more than one, pick any) and denote it the "current Routing Tuple".
1. R_metricが最小の未使用のルーティングタプルを見つけ（複数ある場合はどれかを選択）、それを「現在のルーティングタプル」と示します。
2. Mark the current Routing Tuple as used.
2. 現在のルーティングタプルを使用済みとしてマークします。
3. For each Router Topology Tuple, with TR_from_orig_addr = R_dest_addr of the current Routing Tuple:
3. 各ルータートポロジタプルについて、現在のルーティングタプルのTR_from_orig_addr = R_dest_addrを使用します。
1. Define:
1. 定義：
- new_metric := R_metric of the current Routing Tuple + TR_metric;
- new_metric：=現在のルーティングタプルのR_metric + TR_metric;
- new_dist := R_dist of the current Routing Tuple + 1.
- new_dist：=現在のルーティングタプルのR_dist + 1。
2. If there is no Routing Tuple with R_dest_addr = TR_to_orig_addr, then create an unused Routing Tuple with:
2. R_dest_addr = TR_to_orig_addrのルーティングタプルがない場合は、次のようにして未使用のルーティングタプルを作成します。
- R_dest_addr := TR_to_orig_addr;
- R_dest_addr：= TR_to_orig_addr;
- R_next_iface_addr := R_next_iface_addr of the current Routing Tuple;
- R_next_iface_addr：=現在のルーティングタプルのR_next_iface_addr。
- R_local_iface_addr := R_local_iface_addr of the current Routing Tuple;
- R_local_iface_addr：=現在のルーティングタプルのR_local_iface_addr。
- R_metric := new_metric;
- R_metric：= new_metric;
- R_dist := new_dist.
- R_dist：= new_dist。
3. Otherwise, if there is an unused Routing Tuple with R_dest_addr = TR_to_orig_addr, and either new_metric < R_metric or (new_metric = R_metric and the updated Routing Tuple would be preferred), then update this Routing Tuple to have:
3. それ以外の場合、R_dest_addr = TR_to_orig_addrの未使用のルーティングタプルがあり、new_metric <R_metricまたは（new_metric = R_metricおよび更新されたルーティングタプルが推奨されます）の場合、このルーティングタプルを更新して次のようにします。
- R_next_iface_addr := R_next_iface_addr of the current Routing Tuple;
- R_next_iface_addr：=現在のルーティングタプルのR_next_iface_addr。
- R_local_iface_addr := R_local_iface_addr of the current Routing Tuple;
- R_local_iface_addr：=現在のルーティングタプルのR_local_iface_addr。
- R_metric := new_metric;
- R_metric：= new_metric;
- R_dist := new_dist.
- R_dist：= new_dist。
The following procedure is executed once.
以下の手順は一度実行されます。
1. For each Neighbor Tuple with N_symmetric = true and N_out_metric != UNKNOWN_METRIC:
1. N_symmetric = trueおよびN_out_metric！= UNKNOWN_METRICの各隣接タプルについて：
1. For each network address (the "neighbor address") in N_neighbor_addr_list, if the neighbor address is not equal to the R_dest_addr of any Routing Tuple, then add a new Routing Tuple, with:
1. N_neighbor_addr_listの各ネットワークアドレス（「ネイバーアドレス」）について、ネイバーアドレスがルーティングタプルのR_dest_addrと等しくない場合は、次のように新しいルーティングタプルを追加します。
+ R_dest_addr := neighbor address;
+ R_dest_addr：=ネイバーアドレス;
+ R_next_iface_addr := selected link address for the neighbor address;
+ R_next_iface_addr := selected link address for the neighbor address;
+ R_local_iface_addr := selected local address for the neighbor address;
+ R_local_iface_addr：=ネイバーアドレス用に選択されたローカルアドレス。
+ R_metric := N_out_metric;
+ R_metric：= N_out_metric;
+ R_dist := 1.
+ R_dist：= 1。
The following procedure is executed once.
以下の手順は一度実行されます。
1. For each Routable Address Topology Tuple, if:
1. 各ルーティング可能なアドレストポロジタプルについて、次の場合：
* TA_dest_addr is not equal to the R_dest_addr of any Routing Tuple added in an earlier stage; AND
* TA_dest_addrは、前の段階で追加されたルーティングタプルのR_dest_addrと等しくありません。そして
* TA_from_orig_addr is equal to the R_dest_addr of a Routing Tuple (the "previous Routing Tuple"),
* TA_from_orig_addrは、ルーティングタプル（「以前のルーティングタプル」）のR_dest_addrと同じです。
then add a new Routing Tuple, with:
次に、以下を使用して新しいルーティングタプルを追加します。
* R_dest_addr := TA_dest_addr;
* R_dest_addr：= TA_dest_addr;
* R_next_iface_addr := R_next_iface_addr of the previous Routing Tuple;
* R_next_iface_addr：=前のルーティングタプルのR_next_iface_addr。
* R_local_iface_addr := R_local_iface_addr of the previous Routing Tuple;
* R_local_iface_addr：=前のルーティングタプルのR_local_iface_addr;
* R_metric := R_metric of the previous Routing Tuple + TA_metric;
* R_metric：=前のルーティングタプルのR_metric + TA_metric;
* R_dist := R_dist of the previous Routing Tuple + 1.
* R_dist：=前のルーティングタプルのR_dist + 1。
There may be more than one Routing Tuple that may be added for an R_dest_addr in this stage. If so, then for each such R_dest_addr, a Routing Tuple with minimum R_metric MUST be added; otherwise, a Routing Tuple that is preferred SHOULD be added.
この段階では、R_dest_addrに追加できるルーティングタプルが複数存在する場合があります。その場合、そのような各R_dest_addrに対して、最小のR_metricを持つルーティングタプルを追加する必要があります。それ以外の場合は、推奨されるルーティングタプルを追加する必要があります。
The following procedure is executed once.
以下の手順は一度実行されます。
1. For each Attached Network Tuple, if:
1. 接続されているネットワークタプルごとに、次の場合：
* AN_net_addr is not equal to the R_dest_addr of any Routing Tuple added in an earlier stage; AND
* AN_net_addrは、前の段階で追加されたルーティングタプルのR_dest_addrと等しくありません。そして
* AN_orig_addr is equal to the R_dest_addr of a Routing Tuple (the "previous Routing Tuple"),
* AN_orig_addrは、ルーティングタプル（「以前のルーティングタプル」）のR_dest_addrと同じです。
then add a new Routing Tuple, with:
次に、以下を使用して新しいルーティングタプルを追加します。
* R_dest_addr := AN_net_addr;
* R_dest_addr：= AN_net_addr;
* R_next_iface_addr := R_next_iface_addr of the previous Routing Tuple;
* R_next_iface_addr：=前のルーティングタプルのR_next_iface_addr。
* R_local_iface_addr := R_local_iface_addr of the previous Routing Tuple;
* R_local_iface_addr：=前のルーティングタプルのR_local_iface_addr;
* R_metric := R_metric of the previous Routing Tuple + AN_metric;
* R_metric：=前のルーティングタプルのR_metric + AN_metric;
* R_dist := R_dist of the previous Routing Tuple + AN_dist.
* R_dist：=前のルーティングタプルのR_dist + AN_dist。
There may be more than one Routing Tuple that may be added for an R_dest_addr in this stage. If so, then for each such R_dest_addr, a Routing Tuple with minimum R_metric MUST be added; otherwise, a Routing Tuple that is preferred SHOULD be added.
この段階では、R_dest_addrに追加できるルーティングタプルが複数存在する場合があります。その場合、そのような各R_dest_addrに対して、最小のR_metricを持つルーティングタプルを追加する必要があります。それ以外の場合は、推奨されるルーティングタプルを追加する必要があります。
The following procedure is OPTIONAL according to Section 19.1 and MAY be executed once.
次の手順は、セクション19.1によるオプションであり、1回だけ実行できます。
1. For each 2-Hop Tuple with N2_out_metric != UNKNOWN_METRIC, if:
1. N2_out_metric！= UNKNOWN_METRICの2ホップタプルごとに、次の場合
* N2_2hop_addr is a routable address; AND
* N2_2hop_addrはルーティング可能なアドレスです。そして
* N2_2hop_addr is not equal to the R_dest_addr of any Routing Tuple added in an earlier stage; AND
* N2_2hop_addrは、前の段階で追加されたルーティングタプルのR_dest_addrと等しくありません。そして
* the Routing Tuple with R_dest_addr = N_orig_addr of the corresponding Neighbor Tuple (the "previous Routing Tuple") has R_dist = 1,
* R_dest_addr = N_orig_addrのルーティングタプル（対応する隣接タプル（「以前のルーティングタプル」））のR_dist = 1
then add a new Routing Tuple, with:
次に、以下を使用して新しいルーティングタプルを追加します。
* R_dest_addr := N2_2hop_addr;
* R_dest_addr：= N2_2hop_addr;
* R_next_iface_addr := R_next_iface_addr of the previous Routing Tuple;
* R_next_iface_addr：=前のルーティングタプルのR_next_iface_addr。
* R_local_iface_addr := R_local_iface_addr of the previous Routing Tuple;
* R_local_iface_addr：=前のルーティングタプルのR_local_iface_addr;
* R_metric := R_metric of the previous Routing Tuple + N_out_metric of the corresponding Neighbor Tuple;
* R_metric：=前のルーティングタプルのR_metric +対応するネイバータプルのN_out_metric;
* R_dist := 2.
* R_dist：= 2。
There may be more than one Routing Tuple that may be added for an R_dest_addr in this stage. If so, then for each such R_dest_addr, a Routing Tuple with minimum R_metric MUST be added; otherwise, a Routing Tuple that is preferred SHOULD be added.
この段階では、R_dest_addrに追加できるルーティングタプルが複数存在する場合があります。その場合、そのような各R_dest_addrに対して、最小のR_metricを持つルーティングタプルを追加する必要があります。それ以外の場合は、推奨されるルーティングタプルを追加する必要があります。
TC messages are instances of [RFC5444] messages. This specification requires that TC messages contain <msg-hop-limit> and <msg-orig-addr> fields. It supports TC messages with any combination of remaining message header options and address encodings enabled by [RFC5444] that convey the required information. As a consequence, there is no single way to represent how all TC messages look. This appendix illustrates a TC message; the exact values and content included are explained in the following text.
TCメッセージは[RFC5444]メッセージのインスタンスです。この仕様では、TCメッセージに<msg-hop-limit>および<msg-orig-addr>フィールドが含まれている必要があります。必要な情報を伝える[RFC5444]によって有効化された残りのメッセージヘッダーオプションとアドレスエンコーディングの任意の組み合わせでTCメッセージをサポートします。結果として、すべてのTCメッセージがどのように見えるかを表す単一の方法はありません。この付録では、TCメッセージについて説明します。含まれる正確な値と内容は、次のテキストで説明されています。
The TC message's four-bit Message Flags (MF) field has a value of 15, indicating that the message header contains originator address, hop limit, hop count, and message sequence number fields. Its four-bit Message Address Length (MAL) field has value 3, indicating addresses in the message have a length of four octets, here being IPv4 addresses. The overall message length is 75 octets.
TCメッセージの4ビットメッセージフラグ（MF）フィールドの値は15で、メッセージヘッダーに発信者アドレス、ホップ制限、ホップカウント、およびメッセージシーケンス番号フィールドが含まれていることを示します。その4ビットのメッセージアドレス長（MAL）フィールドの値は3で、メッセージ内のアドレスが4オクテットの長さであることを示します。ここではIPv4アドレスです。メッセージ全体の長さは75オクテットです。
The message has a Message TLV Block with a content length of 17 octets containing four TLVs. The first two TLVs are validity and interval times for the message. The third TLV is the content sequence number TLV used to carry the 2-octet ANSN and (with default type extension zero, i.e., COMPLETE) indicates that the TC message is complete. The fourth TLV contains forwarding and routing willingness values for the originating router (FWILL and RWILL, respectively). Each TLV uses a TLV with Flags octet (MTLVF) value 16, indicating that it has a Value, but no type extension or start and stop indexes. The first two TLVs have a Value Length of 1 octet; the last has a Value Length of 2 octets.
メッセージには、4つのTLVを含む17オクテットのコンテンツ長のメッセージTLVブロックがあります。最初の2つのTLVは、メッセージの有効期間と間隔時間です。 3番目のTLVは、2オクテットのANSNを伝送するために使用されるコンテンツシーケンス番号TLVであり、（デフォルトのタイプ拡張ゼロ、つまりCOMPLETEを使用して）TCメッセージが完了したことを示します。 4番目のTLVには、発信元ルーターの転送およびルーティングの意欲値（それぞれFWILLおよびRWILL）が含まれています。各TLVは、フラグオクテット（MTLVF）値16のTLVを使用します。これは、値があることを示しますが、タイプ拡張または開始インデックスと停止インデックスはありません。最初の2つのTLVの値の長さは1オクテットです。最後の値の長さは2オクテットです。
The message has two Address Blocks. (This is not necessary. The information could be conveyed using a single Address Block; the use of two Address Blocks, which is also allowed, is illustrative only.) The first Address Block contains 3 addresses, with Flags octet (ABF) value 128, hence with a Head section (with length 2 octets) but no Tail section and with Mid sections with length two octets. The following TLV Block (content length 13 octets) contains two TLVs. The first TLV is a NBR_ADDR_TYPE TLV with Flags octet (ATLVF) value 16, indicating a single Value but no indexes. Thus, all these addresses are associated with the Value (with Value Length 1 octet) ROUTABLE_ORIG, i.e., they are originator addresses of advertised neighbors that are also routable addresses. The second TLV is a LINK_METRIC TLV with Flags octet (ATLVF) value 20, indicating a Value for each address, i.e., as the total Value Length is 6 octets, each address is associated with a Value with length two octets. These Value fields are each shown as having four bits indicating that they are outgoing neighbor metric values and as having twelve bits that represent the metric value (the first four bits being the exponent, the remaining eight bits the mantissa).
メッセージには2つのアドレスブロックがあります。 （これは必須ではありません。情報は単一のアドレスブロックを使用して伝達できます。許可されている2つのアドレスブロックの使用は単なる例です。）最初のアドレスブロックには3つのアドレスが含まれ、フラグオクテット（ABF）値は128です。 、したがって、Headセクション（長さ2オクテット）がありますが、Tailセクションはなく、Midセクションは長さ2オクテットです。次のTLVブロック（コンテンツ長13オクテット）には、2つのTLVが含まれています。最初のTLVは、フラグオクテット（ATLVF）値16のNBR_ADDR_TYPE TLVであり、単一の値を示しますが、インデックスは示しません。したがって、これらのアドレスはすべて、値（値の長さが1オクテット）ROUTABLE_ORIGに関連付けられています。つまり、これらはルーティング可能なアドレスでもある、アドバタイズされたネイバーの発信元アドレスです。 2番目のTLVは、フラグオクテット（ATLVF）値20のLINK_METRIC TLVであり、各アドレスの値を示します。つまり、値の長さの合計が6オクテットであるため、各アドレスは長さが2オクテットの値に関連付けられます。これらの値フィールドはそれぞれ、発信ネイバーメトリック値であることを示す4ビットと、メトリック値を表す12ビット（最初の4ビットは指数、残りの8ビットは仮数）として示されています。
The second Address Block contains 1 address, with Flags octet (ATLVF) 176, indicating that there is a Head section (with length 2 octets), that the Tail section (with length 2 octets) consists of zero valued octets (not included), and that there is a single prefix length, which is 16. The network address is thus Head.0.0/16. The following TLV Block (content length 9 octets) includes two TLVs. The first has a Flags octet (ATLVF) of 16, again indicating that no indexes are needed, but that a Value (with Value Length 1 octet) is present, indicating the address distance as a number of hops. The second TLV is another LINK_METRIC TLV, as in the first Address TLV Block except with a Flags octet (ATLVF) value 16, indicating that a single Value is present.
2番目のアドレスブロックには1つのアドレスが含まれ、フラグオクテット（ATLVF）176で、ヘッドセクション（長さ2オクテット）があり、テールセクション（長さ2オクテット）がゼロの値のオクテット（含まれていない）で構成されていることを示します。また、プレフィックス長は1つで、16です。ネットワークアドレスはHead.0.0 / 16です。次のTLVブロック（コンテンツ長9オクテット）には、2つのTLVが含まれています。最初のフラグFlagsオクテット（ATLVF）は16で、インデックスは不要ですが、値（値の長さ1オクテット）が存在し、ホップ数としてアドレス距離を示します。 2番目のTLVは、最初のアドレスTLVブロックと同様に、別のLINK_METRIC TLVです。ただし、フラグオクテット（ATLVF）値16を除き、単一の値が存在することを示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TC | MF=15 | MAL=3 | Message Length = 75 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | Hop Count | Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message TLV Block Length = 17 | VALIDITY_TIME | MTLVF = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value Len = 1 | Value (Time) | INTERVAL_TIME | MTLVF = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value Len = 1 | Value (Time) | CONT_SEQ_NUM | MTLVF = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value Len = 2 | Value (ANSN) | MPR_WILLING |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTLVF = 16 | Value Len = 1 | FWILL | RWILL | Num Addrs = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ABF = 128 | Head Len = 2 | Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid | Address TLV Block Length = 13 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NBR_ADDR_TYPE | ATLVF = 16 | Value Len = 1 | ROUTABLE_ORIG |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LINK_METRIC | ATLVF = 20 | Value Len = 6 |0|0|0|1|Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric (cont) |0|0|0|1| Metric |0|0|0|1|Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric (cont) | Num Addrs = 1 | ABF = 176 | Head Len = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head | Tail Len = 2 | Pref Len = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address TLV Block Length = 9 | GATEWAY | ATLVF = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value Len = 1 | Value (Hops) | LINK_METRIC | ATLVF = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value Len = 2 |0|0|0|1| Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Due to its proactive nature, this protocol has a natural control over the flow of its control traffic. Routers transmit control messages at predetermined rates specified and bounded by message intervals.
このプロアクティブな性質により、このプロトコルは制御トラフィックのフローを自然に制御します。ルーターは、メッセージ間隔によって指定および制限された所定のレートで制御メッセージを送信します。
This protocol employs [RFC6130] for local signaling, embedding MPR selection advertisement through a simple Address Block TLV and router willingness advertisement (if any) as a single Message TLV. Local signaling, therefore, shares the characteristics and constraints of [RFC6130].
このプロトコルは、ローカルシグナリングに[RFC6130]を採用し、単純なアドレスブロックTLVとルーターの意欲広告（存在する場合）を介してMPR選択広告を単一のメッセージTLVとして埋め込みます。したがって、ローカルシグナリングは、[RFC6130]の特性と制約を共有します。
Furthermore, the use of MPRs can greatly reduce the signaling overhead from link state information dissemination in two ways, attaining both flooding reduction and topology reduction. First, using MPR flooding, the cost of distributing link state information throughout the network is reduced, as compared to when using blind flooding, since only MPRs need to forward link state declaration messages. Second, the amount of link state information for a router to declare is reduced; it only needs to contain that router's MPR selectors. This reduces the size of a link state declaration as compared to declaring full link state information. In particular, some routers may not need to declare any such information. In dense networks, the reduction of control traffic can be of several orders of magnitude compared to routing protocols using blind flooding [MPR]. This feature naturally provides more bandwidth for useful data traffic and further pushes the frontier of congestion.
Furthermore, the use of MPRs can greatly reduce the signaling overhead from link state information dissemination in two ways, attaining both flooding reduction and topology reduction. First, using MPR flooding, the cost of distributing link state information throughout the network is reduced, as compared to when using blind flooding, since only MPRs need to forward link state declaration messages. Second, the amount of link state information for a router to declare is reduced; it only needs to contain that router's MPR selectors. This reduces the size of a link state declaration as compared to declaring full link state information. In particular, some routers may not need to declare any such information. In dense networks, the reduction of control traffic can be of several orders of magnitude compared to routing protocols using blind flooding [MPR]. This feature naturally provides more bandwidth for useful data traffic and further pushes the frontier of congestion.
Since the control traffic is continuous and periodic, it keeps the quality of the links used in routing more stable. However, using some options, some control messages (HELLO messages or TC messages) may be intentionally sent in advance of their deadline in order to increase the responsiveness of the protocol to topology changes. This may cause a small, temporary, and local increase of control traffic; however, this is at all times bounded by the use of minimum message intervals.
制御トラフィックは継続的かつ定期的であるため、ルーティングで使用されるリンクの品質をより安定させます。ただし、一部のオプションを使用すると、トポロジの変更に対するプロトコルの応答性を高めるために、一部の制御メッセージ（HELLOメッセージまたはTCメッセージ）が意図的に期限前に送信される場合があります。これにより、制御トラフィックが一時的にローカルでわずかに増加する場合があります。ただし、これは常に最小メッセージ間隔の使用によって制限されます。
A router that recognizes that the network is suffering from congestion can increase its message interval parameters. If this is done by most or all routers in the network, then the overall control traffic in the network will be reduced. When using this capability, routers will have to take care not to increase message interval parameters such that they cannot cope with network topology changes. Note that routers can make such decisions independently; it is not necessary for all routers to be using the same parameter values, nor is it necessary that all routers decide to change their intervals at the same time.
ネットワークが輻輳していることを認識するルーターは、メッセージ間隔パラメーターを増やすことができます。これがネットワーク内のほとんどまたはすべてのルーターによって行われる場合、ネットワーク内の全体的な制御トラフィックが削減されます。この機能を使用する場合、ルーターは、ネットワークトポロジの変更に対応できないようにメッセージ間隔パラメーターを増加させないように注意する必要があります。ルーターはこのような決定を個別に行うことができることに注意してください。すべてのルーターが同じパラメーター値を使用する必要はなく、すべてのルーターが同時に間隔を変更することを決定する必要はありません。
Authors' Addresses
著者のアドレス
Thomas Heide Clausen LIX, Ecole Polytechnique
トーマスハイデクラウセンLIX、エコールポリテクニック
Phone: +33 6 6058 9349
EMail: T.Clausen@computer.org
URI: http://www.ThomasClausen.org/
Christopher Dearlove BAE Systems Advanced Technology Centre West Hanningfield Road Great Baddow, Chelmsford United Kingdom
Christopher Dearlove BAE Systems Advanced Technology Center West Hanningfield Roadイギリス、チェルムズフォード、グレートバッドウ
Phone: +44 1245 242194
EMail: chris.dearlove@baesystems.com
URI: http://www.baesystems.com/
Philippe Jacquet Alcatel-Lucent Bell Labs
フィリップジャケアルカテルルーセントベルラボ
Phone: +33 6 7337 1880
EMail: philippe.jacquet@alcatel-lucent.com
Ulrich Herberg Fujitsu Laboratories of America 1240 E. Arques Ave. Sunnyvale, CA 94085 USA
うｌりｃｈ へｒべｒｇ ふじつ ぁぼらとりえｓ おｆ あめりか １２４０ え。 あｒくえｓ あゔぇ。 すんｙゔぁぇ、 か ９４０８５ うさ
EMail: ulrich@herberg.name
URI: http://www.herberg.name/