[要約] RFC 6130は、Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)に関する仕様です。NHDPは、MANET内のノード間での隣接関係の発見と維持を目的としています。
Internet Engineering Task Force (IETF) T. Clausen
Request for Comments: 6130 LIX, Ecole Polytechnique
Category: Standards Track C. Dearlove
ISSN: 2070-1721 BAE Systems ATC
J. Dean
Naval Research Laboratory
April 2011
Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)
モバイルアドホックネットワーク（MANET）近隣発見プロトコル（NHDP）
Abstract
概要
This document describes a 1-hop and symmetric 2-hop neighborhood discovery protocol (NHDP) for mobile ad hoc networks (MANETs).
このドキュメントでは、モバイルアドホックネットワーク（MANET）用の1ホップおよび対称2ホップ近隣発見プロトコル（NHDP）について説明します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
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）の製品です。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/rfc6130.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6130で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
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標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction .....................................................4
1.1. Motivation .................................................5
2. Terminology .....................................................6
3. Applicability Statement .........................................9
4. Protocol Overview and Functioning ..............................10
4.1. Routers and Interfaces ....................................11
4.2. Information Base Overview .................................12
4.2.1. Local Information Base .............................13
4.2.2. Interface Information Bases ........................13
4.2.3. Neighbor Information Base ..........................14
4.3. Signaling Overview ........................................14
4.3.1. HELLO Message Generation ...........................15
4.3.2. HELLO Message Content ..............................16
4.3.3. HELLO Message Processing ...........................17
4.4. Link Quality ..............................................17
5. Protocol Parameters and Constants ..............................18
5.1. Protocol and Port Numbers .................................18
5.2. Multicast Address .........................................18
5.3. Interface Parameters ......................................18
5.3.1. Message Intervals ..................................19
5.3.2. Information Validity Times .........................21
5.3.3. Link Quality .......................................22
5.3.4. Jitter .............................................22
5.4. Router Parameters .........................................23
5.4.1. Information Validity Time ..........................23
5.5. Parameter Change Constraints ..............................23
5.6. Constants .................................................24
6. Local Information Base .........................................24
6.1. Local Interface Set .......................................25
6.2. Removed Interface Address Set .............................26
7. Interface Information Bases ....................................26
7.1. Link Set ..................................................27
7.2. 2-Hop Set .................................................28
8. Neighbor Information Base ......................................28
8.1. Neighbor Set ..............................................28
8.2. Lost Neighbor Set .........................................29
9. Local Information Base Changes .................................29
9.1. Adding an Interface .......................................29
9.2. Removing an Interface .....................................30
9.3. Adding a Network Address to an Interface ..................30
9.4. Removing a Network Address from an Interface ..............31
10. Packets and Messages ..........................................32
10.1. HELLO Messages ...........................................32
10.1.1. Address Blocks ....................................33
11. HELLO Message Generation ......................................34
11.1. HELLO Message Specification ..............................35
11.2. HELLO Message Transmission ...............................37
11.2.1. HELLO Message Jitter ..............................37
12. HELLO Message Processing ......................................38
12.1. Invalid Message ..........................................38
12.2. Definitions ..............................................40
12.3. Updating the Neighbor Set ................................41
12.4. Updating the Lost Neighbor Set ...........................42
12.5. Updating the Link Sets ...................................42
12.6. Updating the 2-Hop Set ...................................44
13. Other Information Base Changes ................................45
13.1. Link Tuple Symmetric .....................................46
13.2. Link Tuple Not Symmetric .................................47
13.3. Link Tuple Heard Timeout .................................48
14. Link Quality ..................................................48
14.1. Deployment without Link Quality ..........................49
14.2. Basic Principles of Link Quality .........................49
14.3. When Link Quality Changes ................................50
14.4. Updating Link Quality ....................................51
15. Proposed Values for Parameters and Constants ..................51
15.1. Message Interval Interface Parameters ....................51
15.2. Information Validity Time Interface Parameters ...........51
15.3. Information Validity Time Router Parameters ..............52
15.4. Link Quality Interface Parameters ........................52
15.5. Jitter Interface Parameters ..............................52
15.6. Constants ................................................52
16. Usage with Other Protocols ....................................52
17. Security Considerations .......................................54
17.1. Invalid HELLO Messages ...................................56
17.2. Authentication, Integrity, and Confidentiality
Suggestions ..............................................57
18. IANA Considerations ...........................................57
18.1. Expert Review: Evaluation Guidelines .....................58
18.2. Message Types ............................................58
18.3. Message-Type-Specific TLV Type Registries ................58
18.4. Address Block TLV Types ..................................59
18.5. LOCAL_IF, LINK_STATUS, and OTHER_NEIGHB Values ...........60
19. Contributors ..................................................61
20. Acknowledgments ...............................................61
21. References ....................................................62
21.1. Normative References .....................................62
21.2. Informative References ...................................62
Appendix A. Address Block TLV Combinations ........................63
Appendix B. Constraints ...........................................64
Appendix C. HELLO Message Example .................................66
Appendix D. Flow and Congestion Control ...........................69
Appendix E. Interval and Timer Illustrations ......................70
E.1. HELLO Message Generation Timing ..........................70
E.2. HELLO Message Processing Timing ..........................76
E.3. Other HELLO Message Timing ...............................77
Appendix F. Topology Pictures ....................................79
F.1. Example 1: Standard Single Interface Topology ............79
F.2. Example 2: Dual Addressed Interface on 1-Hop Neighbor ....80
F.3. Example 3: Dual Addressed Interface on 2-Hop Neighbor ....81
F.4. Example 4: Dual Addressed Interfaces .....................81
F.5. Example 5: Dual Interface on 2-Hop Neighbor ..............82
F.6. Example 6: Dual interface on 1-Hop Neighbor ..............82
F.7. Example 7: Dual Interface on 1-Hop and 2-Hop Neighbors ...83
F.8. Example 8: Dual Interface Locally and on 1-Hop Neighbor ..84
F.9. Example 9: Dual Interface on All Routers .................85
F.10. Example 10: Dual Addressed Dual Interfaces on All
Routers ......................................86
F.11. Example 11: Single Addressed Dual Interface Locally ......87
This document describes a neighborhood discovery protocol (NHDP) for a mobile ad hoc network (MANET) [RFC2501]. This protocol uses a local exchange of HELLO messages so that each router can determine the presence of, and connectivity to, its 1-hop and symmetric 2-hop neighbors. Messages are defined and sent in packets according to the specification [RFC5444].
このドキュメントでは、モバイルアドホックネットワーク（MANET）[RFC2501]の近隣発見プロトコル（NHDP）について説明しています。このプロトコルでは、各ルーターが1ホップおよび対称の2ホップネイバーの存在と接続を決定できるように、Helloメッセージのローカル交換を使用します。メッセージは定義され、仕様[RFC5444]に従ってパケットに送信されます。
1-hop neighborhood information is recorded for use by MANET routing protocols to determine direct (1-hop) connectivity to neighboring routers. 2-hop symmetric neighborhood information is recorded so as to enable MANET routing protocols to employ flooding reduction techniques, e.g., to select reduced relay sets for efficient network-wide traffic dissemination.
1-HOP近隣情報は、MANETルーティングプロトコルで使用するために記録され、隣接するルーターへの直接（1ホップ）接続を決定します。2ホップ対称近隣情報は、MANETルーティングプロトコルが洪水削減技術を採用できるように記録されています。
1-hop and symmetric 2-hop neighborhood information is recorded in the form of Information Bases. These are available for use by other protocols, such as MANET routing protocols, that require information regarding the local network connectivity. This protocol is designed to maintain the information in these Information Bases even in the presence of a dynamic network topology and wireless communication channel characteristics.
1ホップと対称の2ホップ近隣情報は、情報ベースの形で記録されます。これらは、ローカルネットワーク接続に関する情報を必要とするMANETルーティングプロトコルなど、他のプロトコルで使用できます。このプロトコルは、動的なネットワークトポロジとワイヤレス通信チャネルの特性が存在する場合でも、これらの情報ベースに情報を維持するように設計されています。
This protocol makes no assumptions about the underlying link layer, other than support of local broadcast or multicast for communication to 1-hop neighbor routers. Link-layer information may be used if available and applicable.
このプロトコルは、ローカル放送のサポートまたは1ホップの隣接ルーターへの通信のためのマルチキャストのサポートを除いて、基礎となるリンクレイヤーについて仮定しません。リンク層情報は、利用可能で適用可能な場合は使用できます。
This protocol is based on the neighborhood discovery process contained in the Optimized Link State Routing (OLSR) Protocol [RFC3626].
このプロトコルは、最適化されたリンク状態ルーティング（OLSR）プロトコル[RFC3626]に含まれる近隣発見プロセスに基づいています。
MANETs differ from more traditional wired and infrastructure-based wireless networks due to their envisioned applicability over more challenging communication channels (e.g., wireless, lossy, broadcast channels with moderate and shared bandwidth, hidden and exposed terminals, and interference from other network devices and the environment) and in more challenging topological conditions (e.g., rapid and unpredictable mobility, dynamic and non-predetermined network membership).
MANETは、より挑戦的な通信チャネル（例：中程度で共有された帯域幅、非表示、露出したターミナル、および他のネットワークデバイスからの干渉を備えた、より困難な通信チャネルに対する想定されている適用可能性により、より従来の有線およびインフラストラクチャベースのワイヤレスネットワークとは異なります。環境）そして、より挑戦的なトポロジー条件（例えば、迅速かつ予測不可能なモビリティ、動的および非予定されていないネットワークメンバーシップ）。
Due to the properties of wireless transmissions, communication between two neighboring routers may not be bi-directional; even if router A is able to receive packets from router B, the converse is not guaranteed to be true. Furthermore, because of the localized nature of wireless broadcast communication, neighboring routers within the same communications channel may have different sets of neighbors. That is, when using the same communication channel, even if router A is able to exchange packets with router B, and router B is able to exchange packets with router C, this does not guarantee that router A and router C can exchange packets directly.
ワイヤレス送信の特性により、2つの隣接するルーター間の通信は双方向ではない場合があります。ルーターAがルーターBからパケットを受信できる場合でも、コンバースは真実であることを保証されていません。さらに、ワイヤレスブロードキャスト通信の局所的な性質のため、同じ通信チャネル内の隣接するルーターには、異なる隣接セットがある場合があります。つまり、同じ通信チャネルを使用する場合、ルーターAがパケットをルーターBと交換でき、ルーターBがルーターCとパケットを交換できる場合でも、ルーターAとルーターCがパケットを直接交換できることを保証しません。
Each router in a MANET may use more than one communication channel. In particular, between the same pair of routers, more than one distinct communication channel may exist, each with different properties. This may, for example, be the case where MANET routers are equipped with multiple distinct wireless interfaces, operating at different frequencies.
マネの各ルーターは、複数の通信チャネルを使用する場合があります。特に、同じペアのルーターの間で、それぞれが異なる特性を持つ複数の異なる通信チャネルが存在する可能性があります。たとえば、これは、MANETルーターに異なる周波数で動作する複数の異なるワイヤレスインターフェイスを装備している場合です。
For use by MANET routing protocols, as well as for establishing a router's neighbors, a router may also need to determine whether each communication channel with that neighbor is bi-directional.
MANETルーティングプロトコルで使用するだけでなく、ルーターの隣人を確立するためにも、ルーターは、その隣人との各通信チャネルが双方向であるかどうかを判断する必要があります。
The set of neighbor routers of a given MANET router may be continuously changing, often due to router mobility or a changing physical environment in which the MANET is located. There is typically no information from lower layers that would enable an IP routing protocol to detect and, as appropriate, react to such changes. Such changes can often take place on a short timescale, such as of the order of seconds, requiring MANET routing protocols to act rapidly to ensure suitable convergence properties.
多くの場合、ルーターの移動度やマネが配置されている物理的環境の変化により、特定のマネルーターの隣接ルーターのセットが継続的に変化している可能性があります。通常、IPルーティングプロトコルがそのような変更を検出し、反応することを可能にする下位層からの情報はありません。このような変更は、多くの場合、数秒のような短いタイムスケールで行われる可能性があり、適切な収束特性を確保するためにMANETルーティングプロトコルを迅速に動作させる必要があります。
MANET routing protocols, for example [RFC3626] and [RFC5449], often employ relay set reductions in order to conserve network capacity when maintaining network-wide topological information, with calculation of these reduced relay sets employing up to two hop information.
たとえば[RFC3626]および[RFC5449]などのMANETルーティングプロトコルは、ネットワーク全体のトポロジ情報を維持する際にネットワーク容量を節約するためにリレーセットの削減を使用し、これらの削減されたリレーセットを最大2つのホップ情報を使用して計算します。
The neighborhood discovery protocol specified in this document provides continued tracking of neighborhood changes, link bi-directionality, and local topological information up to two hops. Combined, this allows a MANET routing protocol access to information describing link establishment/disappearance and provides the necessary topological information for reduced relay set selection and other purposes.
このドキュメントで指定されている近隣発見プロトコルは、近隣の変更、双方向性、および最大2ホップまでのローカルトポロジー情報の継続的な追跡を提供します。組み合わせて、これにより、リンクの確立/消失を説明する情報へのMANETルーティングプロトコルアクセスが可能になり、リレーセットの選択やその他の目的を削減するために必要なトポロジー情報が提供されます。
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].
キーワードは「必須」、「必要」、「必須」、「shall」、「shall "、" bood "、" low "of" bould "、" becommended "、" bodement "、" may "、" optional「このドキュメントでは、[RFC2119]に記載されているように解釈されます。
All terms introduced in [RFC5444], including "packet", "message", "Address Block", "TLV Block", "TLV", "address", "address prefix", and "address object" are to be interpreted as described therein.
[RFC5444]で「パケット」、「メッセージ」、「アドレスブロック」、「TLVブロック」、「TLV」、「アドレス」、「アドレスプレフィックス」、「アドレスオブジェクト」など、[RFC5444]で導入されたすべての用語は、として解釈されると解釈されます。そこに記述されています。
Additionally, this document uses the following terminology:
さらに、このドキュメントでは、次の用語を使用しています。
Network Address: An address plus an associated prefix length. This may be an address with an associated maximum prefix length or an address prefix including a prefix length. A network address thus represents a range of addresses.
ネットワークアドレス：アドレスと関連するプレフィックス長。これは、関連する最大プレフィックスの長さを持つアドレスまたはプレフィックス長を含むアドレスプレフィックスです。したがって、ネットワークアドレスは、一連のアドレスを表します。
Router: A MANET router that implements this neighborhood discovery protocol.
ルーター：この近隣ディスカバリープロトコルを実装するマネルーター。
Interface: A router's attachment to a communications medium. An interface is assigned one or more addresses.
インターフェイス：通信媒体へのルーターのアタッチメント。インターフェイスには1つ以上のアドレスが割り当てられます。
MANET interface: An interface participating in a MANET and using this neighborhood discovery protocol. A router may have several MANET interfaces.
MANETインターフェイス：MANETに参加し、この近隣発見プロトコルを使用するインターフェイス。ルーターには、いくつかのマネインターフェイスがある場合があります。
Heard: A MANET interface of router X is considered heard on a MANET interface of a router Y if the latter can receive control messages, according to this specification, from the former.
聞いた：ルーターXのマネインターフェイスは、前者からこの仕様に従ってコントロールメッセージを受信できる場合、ルーターYのマネインターフェイスで聞こえると見なされます。
Link: A link between two MANET interfaces exists if either can be heard by the other.
リンク：2つのMANETインターフェイス間のリンクが、どちらかが他のもので聞くことができる場合に存在します。
Symmetric link: A symmetric link between two MANET interfaces exists if both can be heard by the other.
対称リンク：2つのMANETインターフェイス間の対称リンクが、両方が他のもので聞こえる場合に存在します。
1-hop neighbor: A router X is a 1-hop neighbor of a router Y if a MANET interface of router X is heard by a MANET interface of router Y.
1ホップネイバー：ルーターXのマネインターフェイスがルーターYのマネインターフェイスによって聞こえる場合、ルーターXはルーターYの1ホップネイバーです。
Symmetric 1-hop neighbor: A router X is a symmetric 1-hop neighbor of a router Y if a symmetric link exists between a MANET interface on router X and a MANET interface on router Y.
対称1ホップネイバー：ルーターXの対称リンクがルーターXのMANETインターフェイスとルーターYのMANETインターフェイスの間に対称リンクが存在する場合、ルーターXはルーターYの対称1ホップ隣接です。
2-hop neighbor: A router X is a 2-hop neighbor of a router Y if router X is a 1-hop neighbor of a 1-hop neighbor of router Y, but is not router Y itself.
2ホップネイバー：ルーターXがルーターYの1ホップネイバーの1ホップネイバーである場合、ルーターXはルーターYの2ホップネイバーですが、ルーターY自体ではありません。
Symmetric 2-hop neighbor: A router X is a symmetric 2-hop neighbor of a router Y if router X is a symmetric 1-hop neighbor of a symmetric 1-hop neighbor of router Y, but is not router Y itself.
対称2ホップネイバー：ルーターXがルーターYの対称1ホップネイバーの対称1ホップネイバーであるが、ルーターY自体ではない場合、ルーターXはルーターYの対称2ホップネイバーです。
1-hop neighborhood: The 1-hop neighborhood of a router X is the set of the 1-hop neighbors of router X.
1ホップ近隣：ルーターXの1ホップ近隣は、ルーターXの1ホップ近隣のセットです。
Symmetric 1-hop neighborhood: The symmetric 1-hop neighborhood of a router X is the set of the symmetric 1-hop neighbors of router X.
対称1ホップ近傍：ルーターXの対称1ホップ近傍は、ルーターXの対称1ホップネイバーのセットです。
2-hop neighborhood: The 2-hop neighborhood of a router X is the set of the 2-hop neighbors of router X. (This may include routers in the 1-hop neighborhood of router X.)
2ホップ近隣：ルーターXの2ホップ近隣は、ルーターXの2ホップ近隣のセットです（これには、ルーターXの1ホップ近隣にルーターが含まれる場合があります。）
Symmetric 2-hop neighborhood: The symmetric 2-hop neighborhood of a router X is the set of the symmetric 2-hop neighbors of router X. (This may include routers in the 1-hop neighborhood, or even in the symmetric 1-hop neighborhood, of router X.)
対称2ホップ近隣：ルーターXの対称2ホップ近周辺は、ルーターXの対称2ホップネイバーのセットです（これには、1ホップ近隣、または対称1ホップのルーターが含まれる場合があります。ルーターXの近所。）
Constant: A numerical value that MUST be the same for all MANET interfaces of all routers in the MANET, at all times.
定数：常に、マネのすべてのルーターのすべてのマネ界面で同じでなければならない数値。
Interface parameter: A boolean or numerical value, specified separately for each MANET interface of each router. A router MAY change interface parameter values at any time, subject to some constraints.
インターフェイスパラメーター：各ルーターの各MANETインターフェイスに対して個別に指定されたブール値または数値。ルーターは、いくつかの制約を条件として、いつでもインターフェイスパラメーター値を変更する場合があります。
Router parameter: A boolean or numerical value, specified for each router, and not specific to an interface. A router MAY change router parameter values at any time, subject to some constraints.
ルーターパラメーター：各ルーターに指定されたブール値または数値値。インターフェイスに固有ではありません。ルーターは、いくつかの制約を条件として、ルーターパラメーター値をいつでも変更する場合があります。
Information Base: A collection of information maintained by this protocol and which is to be made available to MANET routing protocols. An Information Base may be associated with a MANET interface or with a router.
情報ベース：このプロトコルによって維持されている情報のコレクション。これは、MANETルーティングプロトコルで利用可能になります。情報ベースは、MANETインターフェイスまたはルーターに関連付けられている場合があります。
Furthermore, this document uses the following notational conventions:
さらに、このドキュメントでは、次の表記規則を使用しています。
X contains y, or y is contained in X An unordered list membership operator. X is an unordered list and y is an element. "X contains y" or "y is contained in X" returns true if the unordered list X includes the element y, and returns false otherwise.
xがyを含む、またはyはxに含まれています。xは順序付けられていないリストであり、yは要素です。「xはyを含む」または「yはxに含まれます」は、順序付けられていないリストxに要素yが含まれ、それ以外の場合はfalseを返す場合、trueを返します。
X contains Y, or Y is contained in X An unordered list inclusion operator. X and Y are both unordered lists. "X contains Y" or "Y is contained in X" returns true if the unordered list X contains all elements y which are contained in Y, and returns false otherwise.
xがyを含む、またはyはxに含まれています。xとyはどちらも順序付けられていないリストです。「xがyを含む」または「yはxに含まれます」は、順序付けられていないリストxにyに含まれるすべての要素yを含み、それ以外の場合はfalseを返す場合、trueを返します。
A overlaps B If A and B are network addresses, and the range of addresses represented by A and the range of addresses represented by B both contain at least one common address. (This is only possible if one range is a sub-range of the other.)
aとbがネットワークアドレスである場合、bはbを重複させ、aで表されるアドレスの範囲とbで表されるアドレスの範囲には、両方とも少なくとも1つの共通アドレスが含まれています。（これは、1つの範囲が他の範囲の範囲である場合にのみ可能です。）
a := b An assignment operator, whereby the left side (a) is assigned the value of the right side (b). a and b may be values, network addresses, or unordered lists (they must be of the same type).
a：= b割り当て演算子。左側（a）に右側の値が割り当てられます（b）。AおよびBは、値、ネットワークアドレス、または順序付けられていないリスト（同じタイプである必要があります）です。
c = d A comparison operator, returning true if the value of the left side (c) is equal to the value of the right side (d). c and d may be values, network addresses, or unordered lists (they must be of the same type). If c and d are unordered lists, then they are considered to be equal if c contains d and d contains c (i.e., they contain the same set of elements, regardless of the order in which they are recorded in the lists). If c and d are network addresses, they are considered equal only if both addresses and prefix lengths are equal (i.e., they represent the same).
c = d比較演算子、左側（c）の値が右側（d）の値に等しい場合、trueを返します。CおよびDは、値、ネットワークアドレス、または順序付けられていないリスト（同じタイプである必要があります）である場合があります。CとDが順序付けられていないリストである場合、cがdとdにCが含まれている場合、それらは等しいと見なされます（つまり、リストに記録されている順序に関係なく、同じ要素のセットが含まれています）。CとDがネットワークアドレスである場合、アドレスとプレフィックスの長さの両方が等しい場合にのみ等しいと見なされます（つまり、同じものを表します）。
e != f A comparison operator, returning not (e = f), i.e., returning true where (e = f) would have returned false, and returning false where (e = f) would have returned true.
e！= f比較演算子、（e = f）を返します。つまり、（e = f）がfalseを返した場合、真の返品を返し、（e = f）がtrueを返した場合にfalseを返します。
This protocol:
このプロトコル：
o Is applicable to networks, especially wireless networks, in which unknown neighbors can be reached by local broadcast or multicast packets.
o ネットワーク、特にワイヤレスネットワークに適用できます。ワイヤレスネットワークでは、地元のブロードキャストまたはマルチキャストパケットで未知の隣人にアクセスできます。
o Is designed to work in networks with a dynamic topology, and in which messages may be lost, such as due to collisions in wireless networks.
o 動的なトポロジーを備えたネットワークで動作するように設計されており、ワイヤレスネットワークの衝突によりメッセージが失われる可能性があります。
o Supports routers that each have one or more participating MANET interfaces. The set of a router's interfaces may change over time. Each interface may have one or more associated network addresses, and these may also be dynamically changing.
o それぞれが1つ以上の参加MANETインターフェイスを持っているルーターをサポートします。ルーターのインターフェイスのセットは、時間とともに変化する場合があります。各インターフェイスには、1つ以上の関連するネットワークアドレスがある場合があり、これらも動的に変化する場合があります。
o Provides each router with current local topology information up to two hops away, and makes this local topology information available to MANET routing protocols in Information Bases.
o 各ルーターに現在のローカルトポロジー情報を最大2ホップ離れて提供し、情報ベースのMANETルーティングプロトコルでこのローカルトポロジー情報を利用できるようにします。
o Uses the packet and message formats specified in [RFC5444]. This includes the definition of a HELLO Message Type, used for signaling local topology information.
o [RFC5444]で指定されたパケット形式とメッセージ形式を使用します。これには、ローカルトポロジー情報のシグナリングに使用されるハローメッセージタイプの定義が含まれます。
o Allows "external" and "internal" extensibility as enabled by [RFC5444].
o [RFC5444]によって有効にされている「外部」および「内部」の拡張性を許可します。
o May interact with, and be extended by, other protocols, such as MANET routing protocols, see Section 16.
o MANETルーティングプロトコルなど、他のプロトコルと対話し、拡張される場合があります。セクション16を参照してください。
o Can use relevant link-layer information if it is available.
o 利用可能な場合は、関連するリンク層情報を使用できます。
o Is designed to work in a completely distributed manner, and does not depend on any central entity.
o 完全に分散された方法で動作するように設計されており、中央エンティティに依存しません。
The objective of this protocol is, for each router:
このプロトコルの目的は、各ルーターに対してです。
o To identify 1-hop neighbors and symmetric 1-hop neighbors of this router.
o このルーターの1ホップの隣人と対称1ホップの隣人を識別します。
o To find the interface network addresses of the router's symmetric 2-hop neighbors.
o ルーターの対称2ホップネイバーのインターフェイスネットワークアドレスを見つける。
o To record this information in Information Bases and thus make this information available to other protocols that use this neighborhood discovery protocol.
o この情報を情報ベースに記録し、この近隣発見プロトコルを使用する他のプロトコルでこの情報を利用できるようにします。
o To be available for use by other protocols, which MAY extend the information in these Information Bases, including adding new Sets to Information Bases, new elements to protocol Tuples and new TLVs to be included in outgoing HELLO messages and processed when in incoming HELLO messages.
o 他のプロトコルで使用できるようにするために、これらの情報ベースに情報を拡張することができます。これには、情報ベースに新しいセットを追加し、プロトコルタプルに新しい要素を追加し、Helloメッセージの発信に含まれ、処理される新しいTLVが含まれます。
These objectives are achieved using local (1-hop) signaling that:
これらの目的は、次のようなローカル（1ホップ）シグナルを使用して達成されます。
o Advertises the presence of a router and its interface network addresses.
o ルーターとそのインターフェイスネットワークアドレスの存在を宣伝します。
o Discovers links from neighboring routers.
o 隣接するルーターからのリンクを発見します。
o Performs bi-directionality checks on the discovered links.
o 発見されたリンクで双方向性チェックを実行します。
o Advertises discovered links, and whether each is symmetric, to its 1-hop neighbors, and hence discovers symmetric 2-hop neighbors.
o 発見されたリンク、およびそれぞれが1ホップの隣人に対称的であるかどうかを宣伝し、したがって対称の2ホップの隣人を発見します。
This specification defines, in turn:
この仕様は次のように定義されています。
o Parameters and constants used by the protocol. Parameters used by this protocol may, where appropriate, be specific to a given MANET interface or to a MANET router. This protocol allows all parameters to be changed dynamically, and to be set independently for each MANET router or MANET interface, as appropriate.
o プロトコルで使用されるパラメーターと定数。このプロトコルで使用されるパラメーターは、必要に応じて、特定のMANETインターフェイスまたはMANETルーターに固有の場合があります。このプロトコルにより、すべてのパラメーターを動的に変更し、必要に応じて各MANETルーターまたはMANETインターフェイスに対して独立して設定できます。
o The Information Bases describing local interfaces, discovered links and their status, current and former 1-hop neighbors, and symmetric 2-hop neighbors.
o ローカルインターフェイス、発見されたリンクとそのステータス、現在および以前の1ホップの隣人、対称2ホップ隣人を説明する情報ベース。
o The format of the HELLO message that is used for local signaling.
o ローカル信号に使用されるハローメッセージの形式。
o The generation of HELLO messages from some of the information in the Information Bases.
o 情報ベースの情報の一部からのハローメッセージの生成。
o The updating of the Information Bases according to received HELLO messages and other events.
o Helloメッセージやその他のイベントを受け取った情報に基づいた情報ベースの更新。
o The response to other events, such as the expiration of information in the Information Bases.
o 情報ベースでの情報の有効期限など、他のイベントへの応答。
In order for a router to participate in a MANET, it MUST have at least one, and possibly more, MANET interfaces.
ルーターがマネに参加するためには、少なくとも1つ、場合によってはマネのインターフェイスが必要です。
Each MANET interface:
各MANETインターフェイス：
o Is configured with one or more network addresses. Each address in the range of addresses represented by that network address MUST satisfy the following properties:
o 1つ以上のネットワークアドレスで構成されています。そのネットワークアドレスで表されるアドレスの範囲内の各アドレスは、次のプロパティを満たす必要があります。
o It MUST be unique to this router, i.e., it MUST NOT be assigned to any interface of any other router.
o このルーターに固有のものでなければなりません。つまり、他のルーターのインターフェイスに割り当ててはなりません。
o If assigned to other MANET interfaces, on the same router, these MANET interfaces MUST be isolated, i.e., addresses may only be assigned to different interfaces on the same router if no MANET interface on another router can communicate with both. For example, interfaces using distinct radio "channels" MAY be assigned the same address.
o 同じルーターで他のMANETインターフェイスに割り当てられた場合、これらのMANETインターフェイスは分離する必要があります。つまり、別のルーターのMANETインターフェイスが両方と通信できない場合、アドレスは同じルーターの異なるインターフェイスにのみ割り当てられます。たとえば、個別の無線「チャネル」を使用したインターフェイスに同じアドレスが割り当てられる場合があります。
o Has a set of interface parameters, defining the behavior of this MANET interface. Each MANET interface MAY be individually parameterized.
o このMANETインターフェイスの動作を定義する一連のインターフェイスパラメーターがあります。各MANETインターフェイスは、個別にパラメーター化される場合があります。
o Has an Interface Information Base, recording information regarding links to this MANET interface and symmetric 2-hop neighbors that can be reached through such links.
o インターフェイス情報ベースがあり、このMANETインターフェイスへのリンクに関する情報を記録し、そのようなリンクを通じて到達できる対称2ホップネイバーがあります。
o Generates and processes HELLO messages.
o こんにちはメッセージを生成して処理します。
In addition to a set of MANET interfaces as described above, each router has:
上記のように一連のMANETインターフェイスに加えて、各ルーターには以下があります。
o A Local Information Base, containing the network addresses of the interfaces (MANET and non-MANET) of this router. The contents of this Information Base are not changed by signaling.
o このルーターのインターフェイスのネットワークアドレス（MANETおよび非MANET）を含むローカル情報ベース。この情報ベースの内容は、シグナリングによって変更されません。
o A Neighbor Information Base, recording information regarding current and recently lost 1-hop neighbors of this router.
o 近隣の情報ベース、このルーターの現在および最近失われた1ホップの隣人に関する情報を記録します。
A router may have both MANET interfaces and non-MANET interfaces. Interfaces of both of these types are recorded in a router's Local Information Base, which is used, but not updated, by the signaling of this protocol.
ルーターには、MANETインターフェイスと非MANETインターフェイスの両方がある場合があります。これらの両方のタイプのインターフェイスは、このプロトコルの信号によって使用されますが、更新されないルーターのローカル情報ベースに記録されます。
Each router maintains protocol state using Information Bases, described in the following sections. Each Information Base consists of a number of Protocol Sets. Each Protocol Set contains a number of Protocol Tuples.
各ルーターは、以下のセクションで説明する情報ベースを使用してプロトコル状態を維持します。各情報ベースは、多くのプロトコルセットで構成されています。各プロトコルセットには、多くのプロトコルタプルが含まれています。
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 Protocol Tuples from Protocol Sets at the exact time indicated, only to behave as if the Protocol Tuples were removed at that time.
このプロトコルの実装は、この情報を指定された形式、またはこの情報へのアクセスを提供する他の組織で維持する場合があります。特に、その時点でプロトコルタプルが削除されたかのように振る舞うためにのみ、示された正確な時間にプロトコルセットからプロトコルタプルを削除する必要はないことに注意してください。
Information in the Local Information Base is defined locally and included in HELLO messages. Information in the Interface Information Base and the Neighbor Information Base is determined from received HELLO messages; some of this information may also be included in transmitted HELLO messages. Such information has a limited duration in which it is considered valid. This duration is determined from the VALIDITY_TIME TLV in the HELLO message in which the information is received, which in turn is set by the router that originated the HELLO message, using its corresponding interface parameter H_HOLD_TIME.
ローカル情報ベースの情報はローカルで定義され、Helloメッセージに含まれています。インターフェイス情報ベースと近隣情報ベースの情報は、受信したハローメッセージから決定されます。この情報の一部は、送信されたHelloメッセージにも含まれる場合があります。このような情報には、有効と見なされる期間が限られています。この期間は、情報が受信されるHelloメッセージの有効性_Time TLVから決定されます。これは、対応するインターフェイスパラメーターh_hold_timeを使用して、helloメッセージを発信するルーターによって設定されます。
Appendix E illustrates the relationship between message reception, included VALIDITY_TIME TLVs, and the duration for which information received in a HELLO message is considered valid. Appendix F illustrates some example topologies and how they correspond to information in the Information Bases.
付録Eは、exが含まれているメッセージ受信の関係を示しています。付録Fは、いくつかの例のトポロジーと、それらが情報ベースの情報にどのように対応するかを示しています。
Each router maintains a Local Information Base, which contains the router's local configuration information, specifically:
各ルーターは、ルーターのローカル構成情報を含むローカル情報ベースを維持しています。
o The Local Interface Set, which consists of Local Interface Tuples, each of which represents an interface (MANET or non-MANET) of the router.
o ローカルインターフェイスセットは、ローカルインターフェイスタプルで構成されており、それぞれがルーターのインターフェイス（MANETまたは非マネット）を表します。
o The Removed Interface Address Set, which consists of Removed Interface Address Tuples, each of which records a recently used network address of an interface (MANET or non-MANET) of the router.
o 削除されたインターフェイスアドレスセットは、削除されたインターフェイスアドレスタプルで構成されており、それぞれがルーターのインターフェイスの最近使用されたネットワークアドレス（MANETまたは非マネット）を記録します。
The Local Interface Set is used for generating HELLO messages, specifically for determining which interface network addresses are to be included and identified as local interfaces. The Removed Interface Address Set is used to avoid incorrectly recording a formerly used network address as a symmetric 2-hop neighbor's network address.
ローカルインターフェイスセットは、特にどのインターフェイスネットワークアドレスを含めるかを決定し、ローカルインターフェイスとして識別するハローメッセージの生成に使用されます。削除されたインターフェイスアドレスセットは、以前に使用されていたネットワークアドレスを対称の2ホップ隣のネットワークアドレスとして誤って記録しないように使用します。
The Local Information Base is used for generating signaling, but is not itself updated by signaling specified in this document. Updates to the Local Information Base are due to changes of the router configuration, and may be allowed to trigger signaling.
ローカル情報ベースはシグナリングの生成に使用されますが、このドキュメントで指定されたシグナリングによってそれ自体が更新されるわけではありません。ローカル情報ベースの更新は、ルーター構成の変更によるものであり、シグナリングをトリガーすることが許可される場合があります。
Each router maintains, for each of its MANET interfaces, an Interface Information Base, which contains 1-hop neighborhood and symmetric 2-hop neighborhood information collected from this MANET interface, specifically:
各ルーターは、その各マネのインターフェイスについて、このMANETインターフェイスから収集された1ホップ近隣および対称2ホップ近隣情報を含むインターフェイス情報ベースを維持しています。
o A Link Set, which records information about current and recently lost links between this MANET interface and MANET interfaces of 1-hop neighbors. The Link Set consists of Link Tuples, each of which contains information about a single link. Link quality information (see Section 14), when used, is recorded in Link Tuples.
o このMANETインターフェイスと1ホップの隣人のMANETインターフェイスとの間の現在および最近失われたリンクに関する情報を記録するリンクセット。リンクセットはリンクタプルで構成されており、それぞれには単一のリンクに関する情報が含まれています。リンクの品質情報（セクション14を参照）は、使用する場合、リンクタプルに記録されます。
o A 2-Hop Set, which records the existence of symmetric links between symmetric 1-hop neighbors of this MANET interface and other routers (symmetric 2-hop neighbors). The 2-Hop Set consists of 2-Hop Tuples, each of which records a network address of a symmetric 2-hop neighbor, and all network addresses of the corresponding symmetric 1-hop neighbor.
o このMANETインターフェイスの対称1ホップネイバーと他のルーター（対称2ホップネイバー）の対称リンクの存在を記録する2ホップセット。2ホップセットは2ホップタプルで構成され、それぞれが対称2ホップ隣接のネットワークアドレスと、対応する対称1ホップ隣接のすべてのネットワークアドレスを記録します。
The Link Set for a MANET interface is used for generating HELLO messages. Specifically, the Link Set information is included to both allow other routers to identify symmetric links and to populate the 2-Hop Set. Recently lost links are recorded in the Link Set for a MANET interface so that they can be advertised in HELLO messages, accelerating their removal from relevant 1-hop neighbors' Link Sets.
MANETインターフェイスのリンクセットは、Helloメッセージの生成に使用されます。具体的には、リンクセット情報が含まれており、他のルーターが対称リンクを識別し、2ホップセットを入力できるようにします。最近失われたリンクは、Manetインターフェイスのリンクセットに記録されているため、Helloメッセージで宣伝され、関連する1ホップNeighborsのリンクセットからの削除を加速します。
The Link Set for a MANET interface is itself updated on receiving a HELLO message, including recording symmetric links as indicated above. The 2-Hop Set for a MANET interface is updated as indicated above, and is not itself used in generating HELLO messages.
MANETインターフェイスのリンクセットは、上記のように対称リンクを記録するなど、ハローメッセージの受信時に更新されます。MANETインターフェイス用の2ホップセットは、上記のように更新されており、Helloメッセージの生成にはそれ自体が使用されていません。
Each router maintains a Neighbor Information Base, which contains collected information about current and recently lost 1-hop neighbors, specifically:
各ルーターには、現在および最近失われた1ホップの隣人に関する収集された情報が含まれている隣接情報ベースを維持します。
o The Neighbor Set consists of Neighbor Tuples, each of which records all network addresses of a single 1-hop neighbor. Neighbor Tuples are maintained as long as there are corresponding Link Tuples.
o ネイバーセットは隣のタプルで構成されており、それぞれが1つの1ホップ隣人のすべてのネットワークアドレスを記録します。近隣のタプルは、対応するリンクタプルがある限り維持されます。
o The Lost Neighbor Set consists of Lost Neighbor Tuples, each of which records a network address of a recently lost symmetric 1-hop neighbor.
o 失われた隣人セットは、失われた隣人のタプルで構成されており、それぞれが最近失われた対称1ホップ隣人のネットワークアドレスを記録します。
The Neighbor Set associates all network addresses of each 1-hop neighbor. These network addresses may be included when generating a HELLO message, so that other symmetric 1-hop neighbors can record this information in a 2-Hop Set. The Neighbor Set can be updated on receiving a HELLO message.
Neighbor Setは、各1ホップ隣接のすべてのネットワークアドレスを結合します。これらのネットワークアドレスは、Helloメッセージを生成するときに含まれる場合があります。そのため、他の対称1ホップネイバーがこの情報を2ホップセットに記録できます。ネイバーセットは、ハローメッセージの受信時に更新できます。
The Lost Neighbor Set is used to determine which network addresses are to be included in a HELLO message as being lost (of a recently symmetric 1-hop neighbor). The Lost Neighbor Set can itself be updated on receiving a HELLO message.
Lost Neighbor Setは、（最近対称的な1ホップ隣人の）紛失しているとHelloメッセージに含まれるネットワークアドレスを決定するために使用されます。Lost Neighbor Setは、Helloメッセージを受信することで更新できます。
This protocol contains a signaling mechanism for maintaining the Interface Information Bases and the Neighbor Information Base. If information from the link layer, or any other source, is available and appropriate, it may also be used to update these Information Bases. Such updates are subject to the constraints specified in Appendix B.
このプロトコルには、インターフェイス情報ベースと隣接情報ベースを維持するためのシグナル伝達メカニズムが含まれています。リンクレイヤーまたはその他のソースからの情報が利用可能かつ適切である場合、これらの情報ベースを更新するためにも使用できます。このような更新は、付録Bで指定された制約の対象となります。
Signaling consists of a single type of message, known as a HELLO message. Each router generates HELLO messages on each of its MANET interfaces. HELLO messages are generated independently on each MANET interface of a MANET router; the content of a given HELLO message depends on the MANET interface for which it has been generated.
シグナリングは、Helloメッセージとして知られる単一のタイプのメッセージで構成されています。各ルーターは、各マネのインターフェイスでハローメッセージを生成します。こんにちはメッセージは、MANETルーターの各MANETインターフェイスで個別に生成されます。特定のハローメッセージの内容は、生成されたMANETインターフェイスによって異なります。
Each HELLO message:
各ハローメッセージ：
o Identifies, as far as is required, the MANET interface for which it is generated and transmitted; this allows recipients of that HELLO message to identify that MANET interface from among those it may hear.
o 必要な限り、生成および送信されるMANETインターフェイスを識別します。これにより、そのHelloメッセージの受信者は、耳にする可能性のある人の中からMANETインターフェイスを識別できます。
o Reports the network addresses of other interfaces (MANET and non-MANET) of the router; this allows recipients of that HELLO message to associate a set of network addresses with a single 1-hop neighbor.
o ルーターの他のインターフェイス（MANETおよび非マネット）のネットワークアドレスを報告します。これにより、そのHelloメッセージの受信者がネットワークアドレスのセットを1つの1ホップ隣人に関連付けることができます。
o Includes 1-hop neighbor information from the Information Bases; this allows detection of local symmetric links, and symmetric 2-hop neighbors.
o 情報ベースからの1ホップの隣接情報が含まれています。これにより、ローカル対称リンクと対称の2ホップネイバーの検出が可能になります。
HELLO message generation, and the validity of the information recorded as a consequence of processing a HELLO message, is affected by timers and validity information included in HELLO messages through TLVs. The relationship between message timers and intervals is illustrated in Appendix E.
こんにちはメッセージの生成、およびハローメッセージの処理の結果として記録された情報の有効性は、TLVを介したハローメッセージに含まれるタイマーと有効性情報の影響を受けます。メッセージタイマーと間隔の関係は、付録Eに示されています。
HELLO messages are generated by a router for each of its MANET interfaces, and MAY be sent:
こんにちはメッセージは、そのマネの各インターフェイスのルーターによって生成され、送信される場合があります。
o Proactively, at a regular interval, known as HELLO_INTERVAL. HELLO_INTERVAL may be fixed, or may be dynamic. For example, HELLO_INTERVAL may be backed off due to congestion or network stability.
o 積極的に、hello_intervalとして知られる通常の間隔で。hello_intervalが修正される場合もあれば、動的である場合もあります。たとえば、hello_intervalは、混雑やネットワークの安定性のために後退する可能性があります。
o As a response to a change in the router itself, or its 1-hop neighborhood, for example, on first becoming active or in response to a new, lost, or changed status link.
o 例えば、ルーター自体、またはその1ホップの近隣の変更に対する応答として、たとえば、最初にアクティブになったり、新しい、失われた、または変更されたステータスリンクに応じて。
o In a combination of these proactive and responsive mechanisms.
o これらの積極的で応答性の高いメカニズムの組み合わせ。
Jittering of HELLO message generation and transmission SHOULD be used as described in Section 11.2, unless the medium access control mechanism in use prevents any simultaneous transmissions by potentially interfering routers.
ハローメッセージの生成と送信のジッタリングは、使用中の中程度のアクセス制御メカニズムが潜在的に干渉するルーターによる同時送信を防止しない限り、セクション11.2に記載されているように使用する必要があります。
HELLO messages MAY be scheduled independently for each MANET interface, or, interface parameters permitting, using the same schedule for all MANET interfaces of a router.
Helloメッセージは、各MANETインターフェイス、またはルーターのすべてのMANETインターフェイスに対して同じスケジュールを使用して許可するインターフェイスパラメーターについて個別にスケジュールされる場合があります。
The content of a HELLO message MUST satisfy the following:
ハローメッセージの内容は、次のことを満たす必要があります。
o A HELLO message MUST contain all of the network addresses in the Local Interface Set of the router on which the HELLO message is being generated. This includes:
o Helloメッセージには、Helloメッセージが生成されているルーターのローカルインターフェイスセットのすべてのネットワークアドレスを含める必要があります。これも：
o At least one network address of each MANET interface of the router.
o ルーターの各MANETインターフェイスの少なくとも1つのネットワークアドレス。
o Network addresses that include all source addresses of any IP datagrams sent by the router on any MANET interface.
o MANETインターフェイスでルーターによって送信されたIPデータグラムのすべてのソースアドレスを含むネットワークアドレス。
o All other network addresses of the router that are to be made known to any other router for any reason.
o 何らかの理由で他のルーターに知られるようにされるルーターの他のすべてのネットワークアドレス。
o For each MANET interface, within every time interval equal to the corresponding REFRESH_INTERVAL, sent HELLO messages MUST collectively include all of the relevant information in the corresponding Link Set and the Neighbor Information Base. Note that when determining whether to include information in a HELLO message, the sender MUST consider all times up to the latest time when it may send its next HELLO message on this MANET interface.
o 各MANETインターフェイスについて、対応するREFRESH_INTERVALに等しい間隔内で、送信されたHelloメッセージは、対応するリンクセットとNeighbor情報ベースに関連するすべての情報を集合的に含める必要があります。Helloメッセージに情報を含めるかどうかを決定するとき、送信者は、このMANETインターフェイスで次のHelloメッセージを送信する可能性がある最新の時間まで常に考慮する必要があることに注意してください。
o For each MANET interface, within every time interval equal to the corresponding REFRESH_INTERVAL, sent HELLO messages MUST collectively include all of the relevant information in the corresponding Link Set and the Neighbor Information Base.
o 各MANETインターフェイスについて、対応するREFRESH_INTERVALに等しい間隔内で、送信されたHelloメッセージは、対応するリンクセットとNeighbor情報ベースに関連するすべての情報を集合的に含める必要があります。
o When determining whether to include a given piece of neighbor information in a HELLO message, it is not sufficient to consider whether that information has been sent in the interval of length REFRESH_INTERVAL up to the current time. Instead, the router MUST consider the interval of length REFRESH_INTERVAL that will end at the latest possible time at which the next HELLO message will be sent on this MANET interface. (Normally, this will be HELLO_INTERVAL past the current time, but MAY be earlier if this router elects to divide its neighbor information among more than one HELLO message in order to reduce the size of its HELLO messages.) All neighbor information MUST be sent in this interval, i.e., the router MUST ensure that this HELLO message includes all neighbor information that has not already been included in any HELLO messages sent since the start of this interval (normally, the current time - (REFRESH_INTERVAL - HELLO_INTERVAL)).
o Helloメッセージに特定の隣接情報を含めるかどうかを判断するとき、その情報が長さのrefresh_intervalの間隔で現在まで送信されたかどうかを考慮するだけでは十分ではありません。代わりに、ルーターは、次のハローメッセージがこのMANETインターフェイスで送信される可能性のある最新の時間に終了する長さrefresh_intervalの間隔を考慮する必要があります。（通常、これは現在のhello_intervalになりますが、このルーターがハローメッセージのサイズを減らすために、このルーターが近隣情報を複数のハローメッセージに分割することを選択した場合に早くなる場合があります。）すべての近隣情報を送信する必要があります。この間隔、つまり、ルーターは、このハローメッセージに、この間隔の開始以来送信されたHelloメッセージにまだ含まれていないすべての近隣情報が含まれていることを確認する必要があります（通常、現在の時刻 - （refresh_interval -hello_interval））。
o A HELLO message MUST include exactly one VALIDITY_TIME Message TLV, as specified in [RFC5497], that indicates the length of time for which the message content is to be considered valid, and is therefore to be included in the receiving router's Interface Information Base.
o Helloメッセージには、[RFC5497]で指定されているように、1つの有効性_TIMEメッセージTLVを1つに含める必要があります。これには、メッセージコンテンツが有効であると見なされる時間の長さを示し、したがってRouterのインターフェイス情報ベースに含まれる必要があります。
o A periodically generated HELLO message SHOULD include exactly one INTERVAL_TIME Message TLV, as specified in [RFC5497], that indicates the current value of HELLO_INTERVAL for that MANET interface, i.e., the period within which a further HELLO message is guaranteed to be sent on that MANET interface.
o 定期的に生成されたHelloメッセージには、[RFC5497]で指定されているように、そのMANETインターフェイスのHello_Intervalの現在の値、つまりさらにHellaメッセージがそのMANETに送信される期間を示す[RFC5497]で指定されているように、正確に1つのinterval_timeメッセージTLVを含める必要があります。インターフェース。
HELLO messages received by a router are used to update the Interface Information Base for the MANET interface over which that HELLO message was received, as well as the Neighbor Information Base of the router. Specifically:
ルーターが受信したHelloメッセージは、そのHelloメッセージが受信されたMANETインターフェイスのインターフェイス情報ベースと、ルーターの隣接情報ベースを更新するために使用されます。具体的には：
o The router ensures that there is a single Neighbor Tuple corresponding to the originator of that HELLO message.
o ルーターは、そのhelloメッセージの創始者に対応する1人の隣のタプルがあることを保証します。
o The router ensures that there is a Link Tuple, with appropriate status (heard or symmetric) and advertised duration, corresponding to the link between the MANET interfaces on which that HELLO message was sent and received. One or more Lost Neighbor Tuples may be created if the HELLO message reports that the link was lost.
o ルーターは、Helloメッセージが送信されて受信されたMANETインターフェイス間のリンクに対応する、適切なステータス（聞こえるまたは対称）のリンクタプルがあることを保証します。Helloメッセージがリンクが失われたことを報告した場合、1つ以上の失われた隣人のタプルが作成される場合があります。
o If the link between the MANET interfaces on which the HELLO message was sent and received is symmetric, then the router ensures that there are the appropriate 2-Hop Tuples, with advertised duration.
o Helloメッセージが送信されて受信されたMANETインターフェイス間のリンクが対称である場合、ルーターは適切な2ホップタプルがあり、宣伝された期間があることを保証します。
The processing defined in this specification handles any unexpected and erroneous information in a HELLO message, maintaining the constraints on Information Base contents specified in Appendix B.
この仕様で定義されている処理は、Helloメッセージの予期しない誤った情報を処理し、付録Bで指定された情報ベースの内容の制約を維持します。
Some links in a MANET may be marginal, e.g., due to adverse wireless propagation. In order to avoid using such marginal links, a link quality value is recorded in each Link Tuple. A MANET router considers links for which an insufficient link quality is recorded as lost. Modifying the recorded link quality in a Link Tuple is OPTIONAL. If link quality is not to be modified, it MUST be set to indicate an always usable quality link.
マネのいくつかのリンクは、例えば、無線の伝播のために、たとえばわずかなものである可能性があります。このような限界リンクの使用を避けるために、各リンクタプルにリンクの品質値が記録されます。MANETルーターは、不十分なリンク品質が失われたと記録されるリンクを考慮します。リンクタプルで記録されたリンク品質を変更することはオプションです。リンクの品質を変更しない場合は、常に使用可能な品質リンクを示すように設定する必要があります。
Note that link quality is a "link admittance" mechanism, allowing a router to determine that a given link is too unstable to even consider for use. It is specifically not a link metric nor is it a substitute for one.
リンク品質は「リンクの入場」メカニズムであり、ルーターが特定のリンクが不安定すぎて使用を検討することさえできないと判断できることに注意してください。特にリンクメトリックではなく、代替品でもありません。
Link quality information is only used locally and is not used in signaling. Routers may interoperate whether they are using the same, different, or no link quality information. Link quality information is thus not equivalent to a link metric.
リンク品質情報はローカルでのみ使用され、シグナリングには使用されません。ルーターは、同じ、異なる、またはリンクの品質情報を使用していないかどうかを相互運用する場合があります。したがって、リンクの品質情報は、リンクメトリックと同等ではありません。
Link quality information is defined in this specification as a normalized, dimensionless value in the interval zero to one, inclusive, where the greater the value, the better the link quality. See Section 14 for further details.
この仕様では、リンクの品質情報は、ゼロから1つの間隔の正規化された無次元値として定義されています。詳細については、セクション14を参照してください。
The parameters and constants used in this specification are described in this section.
この仕様で使用されるパラメーターと定数については、このセクションで説明します。
This protocol specifies HELLO messages, which are included in packets as defined by [RFC5444]. These packets may be sent using either the "manet" protocol number or the "manet" well-known UDP port number, as specified in [RFC5498].
このプロトコルは、[RFC5444]で定義されているパケットに含まれるHelloメッセージを指定します。これらのパケットは、[RFC5498]で指定されているように、「MANET」プロトコル番号または「MANET」よく知られているUDPポート番号のいずれかを使用して送信できます。
This protocol specifies HELLO messages, which are included in packets as defined by [RFC5444]. These packets may be locally transmitted using the link-local multicast address "LL-MANET-Routers", as specified in [RFC5498].
このプロトコルは、[RFC5444]で定義されているパケットに含まれるHelloメッセージを指定します。これらのパケットは、[RFC5498]で指定されているように、Link-Local Multicastアドレス「LL-Manet-Routers」を使用してローカルに送信できます。
The interface parameters used by this specification may be classified into the following four categories:
この仕様で使用されるインターフェイスパラメーターは、次の4つのカテゴリに分類できます。
o Message intervals
o メッセージ間隔
o Information validity times
o 情報の妥当性時間
o Link quality o Jitter
o リンク品質Oジッター
These are detailed in the following sections.
これらについては、次のセクションで詳しく説明しています。
Different MANET interfaces (on the same or on different routers) MAY employ different interface parameter values and MAY change their interface parameter values dynamically, subject to the constraints given in this section. A particular case is where all MANET interfaces on all MANET routers within a given MANET employ the same set of interface parameter values.
異なるMANETインターフェイス（同じルーターまたは異なるルーター）は、異なるインターフェイスパラメーター値を使用する場合があり、このセクションで与えられた制約を条件として、インターフェイスパラメーター値を動的に変更する場合があります。特定のケースは、特定のMANET内のすべてのMANETルーターのすべてのMANETインターフェイスが、同じインターフェイスパラメーター値のセットを使用する場合です。
HELLO messages serve two principal functions:
こんにちはメッセージは2つの主要な機能を提供します。
o To advertise network addresses of this router's interface to its 1-hop neighbors. The frequency of these advertisements is regulated by the interface parameters HELLO_INTERVAL and HELLO_MIN_INTERVAL.
o このルーターのインターフェイスのネットワークアドレスを1ホップの隣人に宣伝する。これらの広告の頻度は、インターフェイスパラメーターhello_intervalおよびhello_min_intervalによって規制されています。
o To advertise this router's knowledge of each of its 1-hop neighbors. The frequency of the advertisement of each such neighbor is regulated by the interface parameter REFRESH_INTERVAL.
o このルーターのそれぞれの1ホップの隣人に関する知識を宣伝するため。そのような各隣接の広告の頻度は、インターフェイスパラメーターREFRESH_INTERVALによって規制されています。
Specifically, these parameters are as follows:
具体的には、これらのパラメーターは次のとおりです。
HELLO_INTERVAL: The maximum time between the transmission of two successive HELLO messages on this MANET interface. If using periodic transmission of HELLO messages, these SHOULD be at a separation of HELLO_INTERVAL, possibly modified by jitter as specified in [RFC5148].
hello_interval：このMANETインターフェイスに2つの連続したハローメッセージの送信間の最大時間。Helloメッセージの定期的な送信を使用する場合、これらは[RFC5148]で指定されているようにジッターによって変更される可能性があるHello_intervalの分離にある必要があります。
HELLO_MIN_INTERVAL: The minimum interval between transmission of two successive HELLO messages on this MANET interface. (This minimum interval MAY be modified by jitter, as defined in [RFC5148].)
hello_min_interval：このMANETインターフェイスでの2つの連続したハローメッセージの送信間の最小間隔。（この最小間隔は、[RFC5148]で定義されているように、ジッターによって変更される場合があります。）
REFRESH_INTERVAL: The maximum interval between advertisements, in a HELLO message on this MANET interface, of each 1-hop neighbor network address and its status. In all intervals of length REFRESH_INTERVAL, a router MUST include each 1-hop neighbor network address and its status in at least one HELLO message on this MANET interface. (This may be in the same or in different HELLO messages.)
refresh_interval：広告間の最大間隔、このMANETインターフェイスのハローメッセージ、各1ホップネイターンネットワークアドレスとそのステータス。LESHNESH_INTERVALのすべての間隔で、ルーターには、このMANETインターフェイスに少なくとも1つのHelloメッセージに、各1ホップNeighborネットワークアドレスとそのステータスを含める必要があります。（これは同じまたは異なるハローメッセージにある場合があります。）
REFRESH_INTERVAL thus represents the frequency at which a piece of information, as received in HELLO messages, can be expected to be refreshed. Thus, the REFRESH_INTERVAL is used as a basis for determining when such information expires in receiving routers (see Section 5.3.2). HELLO_INTERVAL represents the frequency of HELLO message emissions. Logically, HELLO_INTERVAL cannot be greater than the REFRESH_INTERVAL; otherwise, information cannot be refreshed in a timely manner.
したがって、refresh_intervalは、ハローメッセージで受信した情報が更新されると予想される頻度を表します。したがって、REFRESH_INTERVALは、そのような情報がルーターを受信する際にいつ期限切れになるかを判断するための基礎として使用されます（セクション5.3.2を参照）。hello_intervalは、hello message emissionsの頻度を表します。論理的には、hello_intervalはrefresh_intervalよりも大きくすることはできません。それ以外の場合、情報をタイムリーに更新することはできません。
HELLO messages can, however, be sent with a higher frequency. A possible use for sending HELLO messages at such a higher frequency includes sending partial HELLO messages (e.g., accommodating constraints on packet sizes from the underlying medium) refreshing only part of the information in each HELLO message. Another use is for a router to send "empty HELLO messages", advertising its own presence frequently in smaller HELLO messages (e.g., in case HELLO message exchange success rates are used for link quality estimation, or to enable rapid detection by new routers in the neighborhood) in between HELLO messages refreshing neighbor information in other routers.
ただし、こんにちはメッセージはより高い頻度で送信できます。このようなより高い頻度でHelloメッセージを送信するための使用の可能性は、部分的なHelloメッセージ（たとえば、基礎となるメディアからのパケットサイズの制約に対応する）を送信することを含みます。別の用途は、ルーターが「空のハローメッセージ」を送信したり、小さなハローメッセージで頻繁に独自の存在を宣伝することです（例えば、ハローメッセージ交換の成功率がリンクの品質推定に使用されたり、新しいルーターによる新しいルーターによる迅速な検出を可能にするために、近所）他のルーターで近隣情報を更新するハローメッセージの間。
The following constraints apply to these interface parameters:
これらのインターフェイスパラメーターには、次の制約が適用されます。
o HELLO_INTERVAL > 0
o hello_interval> 0
o HELLO_MIN_INTERVAL >= 0
o hello_min_interval> = 0
o HELLO_INTERVAL >= HELLO_MIN_INTERVAL
o hello_interval> = hello_min_interval
o REFRESH_INTERVAL >= HELLO_INTERVAL
o refress_interval> = hello_interval
o If an INTERVAL_TIME Message TLV as defined in [RFC5497] is included in a HELLO message, then HELLO_INTERVAL MUST be representable as described in [RFC5497].
o [RFC5497]で定義されているinterval_timeメッセージTLVがHelloメッセージに含まれている場合、[RFC5497]で説明されているようにHello_intervalを表現できる必要があります。
If REFRESH_INTERVAL > HELLO_INTERVAL, then a router may distribute its neighbor advertisements between HELLO messages in any manner, subject to the constraints above.
respread_interval> hello_intervalの場合、ルーターは上記の制約を条件として、あらゆる方法で近隣の広告をHelloメッセージ間で配布することができます。
In the absence of any changes to the local neighborhood, a router will send a HELLO message on a MANET interface after an (possibly jittered) interval of length HELLO_INTERVAL. For a router to employ this protocol in a purely responsive manner on a MANET interface, i.e., for the router to only send HELLO messages on that MANET interface as a response to external events, HELLO_INTERVAL (and hence also REFRESH_INTERVAL) SHOULD be set sufficiently large, i.e., such that a responsive HELLO message is always expected with a shorter period than this value.
地元の近隣に変更がない場合、ルーターは、長さのhello_intervalの（おそらくジッタリングされた）間隔の後にマネのインターフェイスにハローメッセージを送信します。ルーターがこのプロトコルをManetインターフェイスで純粋に応答する方法で使用するため、つまり、ルーターが外部イベントへの応答としてそのMANETインターフェイス上のハローメッセージのみを送信するために、hello_interval（したがってrefresh_interval）は十分に大きく設定する必要があります、つまり、この値よりも短い期間で応答性の高いハローメッセージが常に期待されるように。
If a router has more than one MANET interface, then, even if the router configures different values of HELLO_INTERVAL on each MANET interface, the router SHOULD configure the same value of HELLO_MIN_INTERVAL on all MANET interfaces on which responsive HELLO messages may be sent. (This ensures that changes observed on one MANET interface are reported on other MANET interfaces, so that 1-hop neighbors connected to the latter can maintain up-to-date 2-hop neighborhood information.)
ルーターに複数のMANETインターフェイスがある場合、ルーターが各MANETインターフェイスでhello_intervalの異なる値を構成している場合でも、ルーターは、レスポンシブなhelloメッセージを送信するすべてのMANETインターフェイスでhello_min_intervalの同じ値を構成する必要があります。（これにより、1つのMANETインターフェイスで観察された変化が他のMANETインターフェイスで報告され、後者に接続された1ホップの隣接が最新の2ホップ近隣情報を維持できるようになります。）
The following interface parameters manage the validity time of link information:
次のインターフェイスパラメーターは、リンク情報の有効期間を管理します。
L_HOLD_TIME: The period of advertisement, on this MANET interface, of former 1-hop neighbor network addresses as lost in HELLO messages, allowing recipients of these HELLO messages to accelerate removal of this information from their Link Sets. L_HOLD_TIME MAY be set to zero, if accelerated information removal is not required.
L_HOLD_TIME：このMANETインターフェイスの広告の期間は、以前の1ホップネイバーネットワークのHelloメッセージで失われたものとしてアドレス指定され、これらのHelloメッセージの受信者がリンクセットからこの情報の削除を加速させることができます。加速された情報削除が不要な場合、L_HOLD_TIMEはゼロに設定される場合があります。
H_HOLD_TIME: Used as the Value in the VALIDITY_TIME Message TLV included in all HELLO messages on this MANET interface. It is then used by each router receiving such a HELLO message to indicate the validity of the information taken from that HELLO message and recorded in the receiving router's Information Bases.
h_hold_time：このMANETインターフェイスのすべてのHelloメッセージに含まれる妥当性_TIMEメッセージTLVの値として使用されます。次に、そのようなハローメッセージを受信する各ルーターが使用して、そのハローメッセージから取得した情報の有効性を示し、受信ルーターの情報ベースに記録されます。
Note that as each item of neighbor information is included in HELLO messages within an interval of length REFRESH_INTERVAL, constraints on H_HOLD_TIME are based on REFRESH_INTERVAL, not on HELLO_INTERVAL.
近隣情報の各項目が長さのrefresh_intervalの間隔内のhelloメッセージに含まれているため、h_hold_timeの制約はhello_intervalではなくrefresh_intervalに基づいていることに注意してください。
The following constraints apply to these interface parameters:
これらのインターフェイスパラメーターには、次の制約が適用されます。
o L_HOLD_TIME >= 0
o l_hold_time> = 0
o H_HOLD_TIME >= REFRESH_INTERVAL
o h_hold_time> = refresh_interval
o If HELLO messages can be lost, then both parameters SHOULD be significantly greater than REFRESH_INTERVAL.
o Helloメッセージを失う可能性がある場合、両方のパラメーターはrefresh_intervalよりも大幅に大きくする必要があります。
o H_HOLD_TIME MUST be representable as described in [RFC5497].
o h_hold_timeは[RFC5497]で説明されているように表現できる必要があります。
The following interface parameters manage the usage of link quality (see Section 14):
次のインターフェイスパラメーターは、リンク品質の使用を管理します（セクション14を参照）。
HYST_ACCEPT: The link quality threshold at or above which a link becomes usable, if it was not already so.
hyst_accept：リンクの品質しきい値以下は、リンクがまだ使用できない場合は使用可能になります。
HYST_REJECT: The link quality threshold below which a link becomes unusable, if it was not already so.
HYST_REJECT：リンクのしきい値は、リンクが使用できなくなった場合です。
INITIAL_QUALITY: The initial quality of a newly identified link.
Initial_Quality：新しく識別されたリンクの初期品質。
INITIAL_PENDING: If true, then a newly identified link is considered pending, and is not usable until the link quality has reached or exceeded the HYST_ACCEPT threshold.
initial_pending：trueの場合、新しく識別されたリンクは保留中と見なされ、リンクの品質がHYST_ACCEPTしきい値に達するか、それを超えるまで使用できません。
The following constraints apply to these interface parameters:
これらのインターフェイスパラメーターには、次の制約が適用されます。
o 0 <= HYST_REJECT <= HYST_ACCEPT <= 1
o 0 <= INITIAL_QUALITY <= 1.
o 0 <= initial_quality <= 1。
o If link quality is not updated, then INITIAL_QUALITY >= HYST_ACCEPT.
o リンクの品質が更新されていない場合は、intiality_quality> = hyst_accept。
o If INITIAL_QUALITY >= HYST_ACCEPT, then INITIAL_PENDING := false.
o initial_quality> = hyst_acceptの場合、initial_pending：= false。
o If INITIAL_QUALITY < HYST_REJECT, then INITIAL_PENDING := true.
o initial_quality <hyst_rejectの場合、initial_pending：= true。
If jitter, as defined in [RFC5148], is used, then these parameters are as follows:
[RFC5148]で定義されているジッターが使用される場合、これらのパラメーターは次のとおりです。
HP_MAXJITTER: Represents the value of MAXJITTER used in [RFC5148] for periodically generated HELLO messages on this MANET interface.
HP_MAXJITTER：[RFC5148]で使用されているMaxjitterの値を表します。
HT_MAXJITTER: Represents the value of MAXJITTER used in [RFC5148] for externally triggered HELLO messages on this MANET interface.
HT_MAXJITTER：[RFC5148]で使用されているMaxjitterの値を表します。
For constraints on these interface parameters, see [RFC5148].
これらのインターフェイスパラメーターの制約については、[RFC5148]を参照してください。
The two router parameters defined by this specification are in the category of information validity time.
この仕様で定義された2つのルーターパラメーターは、情報の妥当性時間のカテゴリにあります。
The following router parameter manages the validity time of lost symmetric 1-hop neighbor information:
次のルーターパラメーターは、失われた対称1ホップ隣接情報の有効期間を管理します。
N_HOLD_TIME: Used as the period during which former 1-hop neighbor network addresses are advertised as lost in HELLO messages, allowing recipients of these HELLO messages to accelerate removal of this information from their 2-Hop Sets. N_HOLD_TIME MAY be set to zero, if accelerated information removal is not required.
N_HOLD_TIME：以前の1ホップ近隣ネットワークアドレスがHelloメッセージで失われたと宣伝される期間として使用され、これらのHelloメッセージの受信者が2ホップセットからこの情報の削除を加速させることができます。加速された情報削除が不要な場合、N_hold_timeはゼロに設定される場合があります。
I_HOLD_TIME: The period for which a recently used local interface network address is recorded.
i_hold_time：最近使用されたローカルインターフェイスネットワークアドレスが記録されている期間。
The following constraints apply to these router parameters:
これらのルーターパラメーターには、次の制約が適用されます。
o N_HOLD_TIME >= 0
o n_hold_time> = 0
o I_HOLD_TIME >= 0
o i_hold_time> = 0
If protocol parameters are changed dynamically, the constraints in this section apply.
プロトコルパラメーターが動的に変更された場合、このセクションの制約が適用されます。
HELLO_INTERVAL
hello_interval
o If the HELLO_INTERVAL for a MANET interface increases, then the next HELLO message on this MANET interface MUST be generated according to the previous, shorter, HELLO_INTERVAL. A number of subsequent HELLO messages MAY be generated according to the previous, shorter, HELLO_INTERVAL (but MUST include times according to current parameters). This ensures that "promises" as to timely transmission of a future HELLO message are kept until these previous promises have expired.
o Manetインターフェイスのhello_intervalが増加する場合、このMANETインターフェイスの次のHelloメッセージは、以前の短いHello_intervalに従って生成する必要があります。以前の短い、hello_intervalに従って、その後の多くのハローメッセージを生成することができます（ただし、現在のパラメーターに応じて時間を含める必要があります）。これにより、これらの以前の約束が期限切れになるまで、将来のハローメッセージのタイムリーな送信に関する「約束」が保証されます。
o If the HELLO_INTERVAL for a MANET interface decreases, then the following HELLO messages on this MANET interface MUST be generated according to this current, shorter, HELLO_INTERVAL.
o Manetインターフェイスのhello_intervalが減少する場合、このMANETインターフェイスの次のHelloメッセージは、この電流、短いHello_intervalに従って生成する必要があります。
REFRESH_INTERVAL
refress_interval
o If the REFRESH_INTERVAL for a MANET interface increases, then the content of subsequent HELLO messages must be organized such that the specification of the old value of REFRESH_INTERVAL is satisfied for a further period equal to the old value of REFRESH_INTERVAL.
o MANETインターフェイスのrefresh_intervalが増加する場合、refferevalの古い値の仕様がrefresh_intervalの古い値に等しい場合に満たされるように、後続のハローメッセージの内容を編成する必要があります。
o If the REFRESH_INTERVAL for a MANET interface decreases, then it MAY be necessary to reschedule HELLO message generation on that MANET interface, in order for the specification of REFRESH_INTERVAL is satisfied from the time of change.
o MANETインターフェイスのrefresh_intervalが減少した場合、refferese_intervalの仕様が変更時から満たされるために、そのmanetインターフェイスでハローメッセージ生成を再スケジュールする必要がある場合があります。
HYST_ACCEPT and HYST_REJECT
hyst_acceptおよびhyst_reject
o If HYST_ACCEPT or HYST_REJECT changes, then the appropriate actions for link quality change, as specified in Section 14.3, MUST be taken.
o HYST_ACCEPTまたはHYST_REJECTが変更された場合、セクション14.3で指定されているように、リンクの品質変更の適切なアクションを取得する必要があります。
L_HOLD_TIME
l_hold_time
o If L_HOLD_TIME changes, then the expiry times of all relevant Link Tuples MUST be changed.
o l_hold_timeが変更された場合、関連するリンクタプルの有効期限を変更する必要があります。
N_HOLD_TIME
n_hold_time
o If N_HOLD_TIME changes, then the expiry times of all relevant Lost Neighbor Tuples MUST be changed.
o n_hold_timeが変更された場合、関連する失われた隣人タプルの有効期限を変更する必要があります。
HP_MAXJITTER
hp_maxjitter
o If HP_MAXJITTER changes, then the periodic HELLO message schedule on this MANET interface MAY be changed.
o hp_maxjitterが変更された場合、このMANETインターフェイスの定期的なハローメッセージスケジュールが変更される場合があります。
HT_MAXJITTER
ht_maxjitter
o If HT_MAXJITTER changes, then externally triggered HELLO messages on this MANET interface MAY be rescheduled.
o HT_MAXJITTERが変更された場合、このMANETインターフェイスで外部からトリガーされたハローメッセージが再スケジュールされる場合があります。
The constant C (time granularity) is used as specified in [RFC5497].
定数C（時間の粒度）は、[RFC5497]で指定されているように使用されます。
A router maintains a Local Information Base that records information about its interfaces (MANET and non-MANET). Each interface of a router MUST be identified by at least one network address. Such network addresses MAY be specific to that interface, or MAY in some circumstances be used by more than one interface as specified below.
ルーターは、そのインターフェイスに関する情報（MANETおよび非MANET）に関する情報を記録するローカル情報ベースを維持します。ルーターの各インターフェイスは、少なくとも1つのネットワークアドレスで識別する必要があります。このようなネットワークアドレスは、そのインターフェイスに固有の場合があります。または、状況によっては、以下に指定されているように複数のインターフェイスで使用される場合があります。
The Local Information Base is not modified by signaling. If a router's interface configuration changes, then the Local Information Base MUST reflect these changes. This MAY also result in signaling to advertise these changes.
ローカル情報ベースは、シグナリングによって変更されません。ルーターのインターフェイス構成が変更された場合、ローカル情報ベースはこれらの変更を反映する必要があります。これにより、これらの変更を宣伝するシグナリングが発生する可能性があります。
It is not necessary to include all addresses of an interface in the Local Information Base, and hence in HELLO messages. However, any address that may be the source address of an IP datagram sent from that interface MUST be included (and at least one address MUST be included). A protocol using this specification MAY add additional requirements to these, e.g., that any address that may be the destination address of an IP datagram is also included.
インターフェイスのすべてのアドレスをローカル情報ベース、したがってHelloメッセージに含める必要はありません。ただし、そのインターフェイスから送信されたIPデータグラムのソースアドレスである可能性のあるアドレスを含める必要があります（そして、少なくとも1つのアドレスを含める必要があります）。この仕様を使用するプロトコルは、これらに追加の要件を追加する場合があります。たとえば、IPデータグラムの宛先アドレスである可能性のあるアドレスも含まれています。
The addresses assigned to an interface are "owned" by the router, and MUST NOT be used by any other router as an interface address. If an address has a prefix length and represents a range of addresses, this applies to all addresses in that range (i.e., such ranges MUST NOT overlap).
インターフェイスに割り当てられたアドレスは、ルーターによって「所有」されており、他のルーターがインターフェイスアドレスとして使用してはなりません。アドレスに接頭辞の長さがあり、アドレスの範囲を表す場合、これはその範囲のすべてのアドレスに適用されます（つまり、そのような範囲は重複してはなりません）。
The addresses assigned to different interfaces on the same router MUST be distinct (hence, network address ranges MUST NOT overlap) except that:
同じルーター上の異なるインターフェイスに割り当てられたアドレスは、次のことを除いて異なる必要があります（したがって、ネットワークアドレス範囲は重複してはなりません）。
o The same address MAY be assigned to any number of non-MANET interfaces as well as to one (or more if the following condition also applies) MANET interface.
o 同じアドレスが、任意の数の非マネットインターフェイスと、1つ（または次の条件も適用される場合はそれ以上）に割り当てられる場合があります。
o The same address MAY be assigned to two (or more if each pair satisfies this condition) MANET interfaces if those two MANET interfaces cannot communicate to, from, or one to and one from any other MANET interface of another router.
o これらの2つのMANETインターフェイスが別のルーターの他のMANETインターフェイスから、1つに通信できない場合、同じアドレスが2つのマネインターフェイスに2つの（または各ペアがこの条件を満たす場合）に割り当てることができます。
A router's Local Interface Set records its local interfaces. It consists of Local Interface Tuples, one per interface:
ルーターのローカルインターフェイスセットは、ローカルインターフェイスを記録します。インターフェイスごとに、ローカルインターフェイスタプルで構成されています。
(I_local_iface_addr_list, I_manet)
（i_local_iface_addr_list、i_manet）
where:
ただし：
I_local_iface_addr_list is an unordered list of the network addresses of this interface.
i_local_iface_addr_listは、このインターフェイスのネットワークアドレスの順序付けられていないリストです。
I_manet is a boolean flag, describing if this interface is a MANET interface.
I_Manetはブールフラグであり、このインターフェイスがMANETインターフェイスであるかどうかを説明しています。
Local Interface Tuples are removed from the Local Interface Set only when the routers' interface configuration changes, subject to Section 9, i.e., they are not subject to timer-based expiration.
ローカルインターフェイスタプルは、セクション9の対象となるルーターのインターフェイス構成が変更された場合にのみ、ローカルインターフェイスセットから削除されます。つまり、タイマーベースの有効期限の対象ではありません。
A router's Removed Interface Address Set records network addresses that were recently used as local interface network addresses. If a router's interface network addresses are immutable, then the Removed Interface Address Set is always empty and MAY be omitted. It consists of Removed Interface Address Tuples, one per network address:
ローカルインターフェイスネットワークアドレスとして最近使用されたルーターの削除インターフェイスアドレスセットレコードネットワークアドレス。ルーターのインターフェイスネットワークアドレスが不変の場合、削除されたインターフェイスアドレスセットは常に空で、省略される場合があります。削除されたインターフェイスアドレスタプルで構成されています。1つはネットワークアドレスです。
(IR_local_iface_addr, IR_time)
（IR_LOCAL_IFACE_ADDR、IR_TIME）
where:
ただし：
IR_local_iface_addr is a recently used network address of an interface of this router.
IR_LOCAL_IFACE_ADDRは、このルーターのインターフェイスの最近使用されたネットワークアドレスです。
IR_time specifies when this Tuple expires and MUST be removed.
IR_TIMEは、このタプルが期限切れになり、削除する必要がある場合を指定します。
A router maintains an Interface Information Base for each of its MANET interfaces. This records information about links to that MANET interface and symmetric 2-hop neighbors that can be reached in two hops using those links as the first hop. Each Interface Information Base includes a Link Set and a 2-Hop Set.
ルーターは、各マネインターフェイスのインターフェイス情報ベースを維持します。これは、それらのリンクを最初のホップとして使用して2つのホップで到達できる、そのMANETインターフェイスと対称の2ホップネイバーへのリンクに関する情報を記録します。各インターフェイス情報ベースには、リンクセットと2ホップセットが含まれています。
A network address of a symmetric 2-hop neighbor can also be present as the network address of a 1-hop neighbor. This allows the router using this network address to be immediately considered as a symmetric 2-hop neighbor if it fails to be a symmetric 1-hop neighbor.
対称2ホップネイバーのネットワークアドレスは、1ホップ隣人のネットワークアドレスとして存在することもできます。これにより、このネットワークアドレスを使用するルーターは、対称1ホップ隣人ではない場合、直ちに対称2ホップネイバーと見なすことができます。
An element that specifies a time is considered expired if the current time is greater than or equal to that time. One such element, present in most Tuples, indicates, when expired, that the Tuple itself is considered expired and MUST be removed. Tuples that do not have such a time element are removed at other times as specified; for example, a Neighbor Tuple is removed when all corresponding Link Tuples have been removed.
現在の時間がその時間以上である場合、時間を指定する時間を指定する要素は有効期限が切れると見なされます。ほとんどのタプルに存在するそのような要素の1つは、期限切れになった場合、タプル自体が期限切れと見なされ、除去する必要があることを示します。そのような時間要素を持っていないタプルは、指定された他の時間で削除されます。たとえば、対応するすべてのリンクタプルが削除されたときに、隣のタプルが削除されます。
An interface's Link Set records links from other routers that are, or recently were, 1-hop neighbors. It consists of Link Tuples, each representing a single link:
インターフェイスのリンクは、1ホップの隣人である、または最近の他のルーターからのリンクを記録します。それはリンクのタプルで構成され、それぞれが単一のリンクを表します。
(L_neighbor_iface_addr_list, L_HEARD_time, L_SYM_time, L_quality, L_pending, L_lost, L_time)
（l_neighbor_iface_addr_list、l_heard_time、l_sym_time、l_quality、l_pending、l_lost、l_time）
where:
ただし：
L_neighbor_iface_addr_list is an unordered list of the network addresses of the MANET interface of the 1-hop neighbor;
L_NEIGHBOR_IFACE_ADDR_LISTは、1ホップ隣人のMANETインターフェイスのネットワークアドレスの順序付けられていないリストです。
L_HEARD_time is the time up to which the MANET interface of the 1-hop neighbor would be considered heard if not considering link quality;
L_HEARD_TIMEは、リンクの品質を考慮しないと、1ホップ隣人のMANETインターフェイスが聞こえると見なされる時間です。
L_SYM_time is the time up to which the link to the 1-hop neighbor would be considered symmetric if not considering link quality;
L_SYM_TIMEは、リンクの品質を考慮しない場合、1ホップの隣人へのリンクが対称と見なされる時間です。
L_quality is a dimensionless number between 0 (inclusive) and 1 (inclusive) describing the quality of a link; a greater value of L_quality indicating a higher quality link;
L_Qualityは、リンクの品質を説明する0（包括的）と1（包括的）の間の無次元数です。高品質のリンクを示すL_Qualityのより大きな値。
L_pending is a boolean flag, describing if a link is considered pending (i.e., a candidate, but not yet established, link);
l_pendingはブールフラグであり、リンクが保留中と見なされるかどうかを説明します（つまり、候補者ですが、まだ確立されていないリンク）。
L_lost is a boolean flag, describing if a link is considered lost due to low link quality;
L_Lostはブールフラグであり、リンクの品質が低いためにリンクが失われたと見なされるかどうかを説明しています。
L_time specifies when this Tuple expires and MUST be removed.
L_TIMEは、このタプルが期限切れになり、削除する必要がある場合を指定します。
The status of the link, as obtained through HELLO message exchange and using link quality, is denoted L_status. L_status can take the Values PENDING, HEARD, SYMMETRIC, and LOST. The values LOST, SYMMETRIC, and HEARD are defined in Section 18.5. The Value PENDING is never used in a HELLO message, it is only used locally by a router, and any Value distinct from LOST, SYMMETRIC, and HEARD may be used.
Hello Message ExchangeおよびLink Qualityを使用して得られたリンクのステータスは、L_STATUSで示されています。l_statusは、保留中、聞かれ、対称的で、失われた価値をとることができます。失われた、対称、および聞かれる値は、セクション18.5で定義されています。保留中の値はハローメッセージでは使用されません。ルーターによってローカルでのみ使用され、紛失、対称、および聞かれる値とは異なる値を使用できます。
L_status is defined by:
l_statusは次のように定義されています。
1. If L_pending = true, then L_status := PENDING;
1. l_pending = trueの場合、l_status：= pending;
2. otherwise, if L_lost = true, then L_status := LOST;
2. それ以外の場合、l_lost = trueの場合、l_status：= lost;
3. otherwise, if L_SYM_time is not expired, then L_status := SYMMETRIC;
3. それ以外の場合、l_sym_timeが有効期限が切れない場合、l_status：= symmetric;
4. otherwise, if L_HEARD_time is not expired, then L_status := HEARD;
4. それ以外の場合、l_heard_timeが期限切れになっていない場合、l_status：= heard;
5. otherwise, L_status := LOST.
5. それ以外の場合、l_status：= lost。
An interface's 2-Hop Set records network addresses of symmetric 2-hop neighbors, and the symmetric links to symmetric 1-hop neighbors through which these symmetric 2-hop neighbors can be reached. It consists of 2-Hop Tuples, each representing a single network address of a symmetric 2-hop neighbor, and a single MANET interface of a symmetric 1-hop neighbor.
対称2ホップネイバーのインターフェイスの2ホップセットレコードネットワークアドレス、および対称1ホップネイバーへの対称リンクにより、これらの対称2ホップネイバーに到達できます。これは、対称2ホップネイバーの単一のネットワークアドレスと、対称1ホップ隣人の単一のMANETインターフェイスを表す2ホップタプルで構成されています。
(N2_neighbor_iface_addr_list, N2_2hop_addr, N2_time)
（n2_neighbor_iface_addr_list、n2_2hop_addr、n2_time）
where:
ただし：
N2_neighbor_iface_addr_list is an unordered list of the network addresses of the MANET interface of the symmetric 1-hop neighbor from which this information was received;
N2_NEIGHBOR_IFACE_ADDR_LISTは、この情報が受信された対称1ホップ隣接のMANETインターフェイスのネットワークアドレスの順序付けられていないリストです。
N2_2hop_addr is a network address of a symmetric 2-hop neighbor that has a symmetric link (using any MANET interface) to the indicated symmetric 1-hop neighbor;
N2_2HOP_ADDRは、指定された対称1-HOP隣人への対称リンク（任意のMANETインターフェイスを使用）を持つ対称2ホップ隣人のネットワークアドレスです。
N2_time specifies when this Tuple expires and MUST be removed.
N2_TIMEは、このタプルが期限切れになり、削除する必要があるときに指定します。
Each router maintains a Neighbor Information Base that records information about network addresses of current and recently symmetric 1-hop neighbors.
各ルーターは、現在および最近対称の1ホップ近隣のネットワークアドレスに関する情報を記録する隣接情報ベースを維持しています。
A router's Neighbor Set records all network addresses of each 1-hop neighbor. It consists of Neighbor Tuples, each representing a single 1-hop neighbor:
ルーターのネイバーセットは、各1ホップネイバーのすべてのネットワークアドレスを記録します。それは隣人のタプルで構成されており、それぞれが1つの1ホップ隣人を表しています。
(N_neighbor_addr_list, N_symmetric)
（n_neighbor_addr_list、n_symmetric）
where:
ただし：
N_neighbor_addr_list is an unordered list of the network addresses of a 1-hop neighbor;
n_neighbor_addr_listは、1ホップの隣人のネットワークアドレスの順序付けられていないリストです。
N_symmetric is a boolean flag, describing if this is a symmetric 1-hop neighbor.
N_Symmetricはブールフラグであり、これが対称1ホップ隣人かどうかを説明しています。
Neighbor Tuples are removed from the Neighbor Set only when corresponding Link Tuples expire from the routers' Link Set, i.e., Neighbor Tuples are not directly subject to timer-based expiration.
近隣のタプルは、対応するリンクのタプルがルーターのリンクセットから期限切れになる場合にのみ、ネイバーセットから削除されます。つまり、隣接タプルはタイマーベースの有効期限に直接対象となりません。
A router's Lost Neighbor Set records network addresses of routers that recently were symmetric 1-hop neighbors but that are now advertised as lost. It consists of Lost Neighbor Tuples, each representing a single such network address:
ルーターのLost Neighbor Set Record Networkアドレスは、最近対称的な1ホップの隣人でしたが、現在は失われたと宣伝されています。それは失われた隣人のタプルで構成されており、それぞれがそのような単一のネットワークアドレスを表しています。
(NL_neighbor_addr, NL_time)
（nl_neighbor_addr、nl_time）
where:
ただし：
NL_neighbor_addr is a network address of a router that recently was a symmetric 1-hop neighbor of this router;
nl_neighbor_addrは、最近このルーターの対称1ホップ隣人だったルーターのネットワークアドレスです。
NL_time specifies when this Tuple expires and MUST be removed.
NL_TIMEは、このタプルが期限切れになり、削除する必要があるときに指定します。
The Local Information Base MUST be updated in response to changes in the router's local interface configuration. These MAY also change the Interface Information Base and the Neighbor Information Base. If any changes to the latter Information Bases satisfy any of the conditions described in Section 13, then those changes MUST be applied immediately, unless noted otherwise below.
ローカル情報ベースは、ルーターのローカルインターフェイス構成の変更に応じて更新する必要があります。これらは、インターフェイス情報ベースと近隣情報ベースを変更する場合があります。後者の情報ベースに変更がある場合、セクション13で説明されている条件のいずれかを満たしている場合、以下で説明しない限り、これらの変更はすぐに適用する必要があります。
A router MAY transmit HELLO messages in response to these changes.
ルーターは、これらの変更に応じてハローメッセージを送信する場合があります。
If an interface is added to the router, then this is indicated by the addition of a Local Interface Tuple to the Local Interface Set. If the new interface is a MANET interface, then an initially empty Interface Information Base MUST be created for this new MANET interface. The actions in Section 9.3 MUST be taken for each network address of this added interface. A HELLO message MAY be sent on all MANET interfaces, it SHOULD be sent on the new interface if it is a MANET interface. If using scheduled messages, then a message schedule MUST be established on the new MANET interface.
インターフェイスがルーターに追加された場合、これはローカルインターフェイスセットにローカルインターフェイスタプルを追加することによって示されます。新しいインターフェイスがMANETインターフェイスである場合、この新しいMANETインターフェイスには、最初に空のインターフェイス情報ベースを作成する必要があります。セクション9.3のアクションは、この追加されたインターフェイスの各ネットワークアドレスに対して実行する必要があります。ハローメッセージはすべてのMANETインターフェイスで送信される場合があります。これは、MANETインターフェイスの場合は、新しいインターフェイスに送信する必要があります。スケジュールされたメッセージを使用する場合、新しいMANETインターフェイスでメッセージスケジュールを確立する必要があります。
If an interface is removed from the router, then this MUST result in changes to the Local Information Base and to the Neighbor Information Base as follows:
インターフェイスがルーターから削除された場合、これにより、次のようにローカル情報ベースと隣接情報ベースに変更される必要があります。
1. Identify the Local Interface Tuple that corresponds to the interface to be removed.
1. 削除するインターフェイスに対応するローカルインターフェイスタプルを識別します。
2. For each network address (henceforth removed address) in the I_local_iface_addr_list of that Local Interface Tuple, if that network address is not in the I_local_iface_addr_list of any other Local Interface Tuple, then create a Removed Interface Address Tuple with:
2. そのローカルインターフェイスタプルのi_local_iface_addr_listの各ネットワークアドレス（以下の削除アドレス）について、そのネットワークアドレスが他のローカルインターフェイスタプルのi_local_iface_addr_listにない場合、削除されたインターフェイスアドレスタプルを作成します：
o IR_local_iface_addr := removed address;
o IR_LOCAL_IFACE_ADDR：=削除アドレス;
o IR_time := current time + I_HOLD_TIME.
o IR_TIME：= Current Time I_HOLD_TIME。
3. Remove that Local Interface Tuple from the Local Interface Set.
3. ローカルインターフェイスセットからローカルインターフェイスタプルを削除します。
4. If the interface to be removed is a MANET interface (i.e., with I_manet = true), then:
4. 削除するインターフェイスがMANETインターフェイスである場合（つまり、i_manet = true）、次のとおりです。
1. Remove the Interface Information Base for that MANET interface;
1. そのMANETインターフェイスのインターフェイス情報ベースを削除します。
2. All Neighbor Tuples for which none of the network addresses in its N_neighbor_addr_list are contained in any L_neighbor_iface_addr_list in any remaining Link Tuple are removed.
2. N_NEIGHBOR_ADDR_LISTのネットワークアドレスのいずれも、残りのリンクタプルの任意のL_NEIGHBOR_IFACE_ADDR_LISTに含まれていないすべての隣接タプルは削除されます。
If the removed interface is the last MANET interface of the router, then there will be no remaining Interface Information Bases, and the router will no longer participate in this protocol.
削除されたインターフェイスがルーターの最後のMANETインターフェイスである場合、残りのインターフェイス情報ベースはなく、ルーターはこのプロトコルに参加しなくなります。
After removing the interface and making these changes, a HELLO message MAY be sent on all remaining MANET interfaces.
インターフェイスを削除してこれらの変更を加えた後、残りのすべてのMANETインターフェイスでHelloメッセージを送信できます。
If a network address is added to an interface, then this is indicated by the addition of a network address to the appropriate I_local_iface_addr_list. The following changes MUST be made to the Information Bases: 1. Remove any Removed Interface Address Tuple whose IR_local_iface_addr is the added network address.
ネットワークアドレスがインターフェイスに追加された場合、これは適切なi_local_iface_addr_listにネットワークアドレスを追加することによって示されます。情報ベースに次の変更を加える必要があります。1。IR_LOCAL_IFACE_ADDRが追加されたネットワークアドレスである削除されたインターフェイスアドレスTupleを削除します。
2. Remove any Neighbor Tuples whose N_neighbor_addr_list contains a network address that overlaps the added network address.
2. N_NEIGHBOR_ADDR_LISTに追加されたネットワークアドレスが重複するネットワークアドレスが含まれている隣接タプルを削除します。
3. Remove any Link Tuples, in any Link Set, for which either:
3. リンクセットでリンクタプルを削除します。
o L_neighbor_iface_addr_list contains any network address in the N_neighbor_addr_list of any removed Neighbor Tuple; OR
o l_neighbor_iface_addr_list削除された隣接タプルのn_neighbor_addr_listのネットワークアドレスが含まれています。また
o L_neighbor_iface_addr_list contains a network address that overlaps the added network address.
o l_neighbor_iface_addr_listには、追加されたネットワークアドレスが重複するネットワークアドレスが含まれています。
Apply Section 13.2 but not Section 13.3.
セクション13.2を適用しますが、セクション13.3には適用しません。
4. Remove any Lost Neighbor Tuples whose NL_neighbor_addr overlaps the added network address.
4. NL_NEIGHBOR_ADDRが追加されたネットワークアドレスが重複している、失われた隣接タプルを削除します。
5. Remove any 2-Hop Tuples whose N2_2hop_addr overlaps the added network address.
5. N2_2HOP_ADDRが追加されたネットワークアドレスが重複している2ホップタプルを削除します。
After adding the network address and making these changes, a HELLO message MAY be sent on all MANET interfaces.
ネットワークアドレスを追加してこれらの変更を加えた後、すべてのMANETインターフェイスでHelloメッセージを送信できます。
These changes, other than to the appropriate I_local_iface_addr_list, are made in order to maintain consistency of the Information Bases. Specifically, these changes remove any record of any use of this network address by routers in the 1-hop neighborhood or in the symmetric 2-hop neighborhood of this router.
これらの変更は、適切なi_local_iface_addr_listを除いて、情報ベースの一貫性を維持するために作成されます。具体的には、これらの変更は、1ホップ近隣またはこのルーターの対称2ホップ近隣のルーターによるこのネットワークアドレスの使用の記録を削除します。
If a network address (henceforth removed address) is removed from an interface, then:
ネットワークアドレス（以降、アドレスを削除した）がインターフェイスから削除された場合、次のとおりです。
1. Identify the Local Interface Tuple that corresponds to the removed address.
1. 削除されたアドレスに対応するローカルインターフェイスタプルを特定します。
2. If this is the only network address of that interface (the only network address in the corresponding I_local_iface_addr_list), then remove that interface as specified in Section 9.2.
2. これがそのインターフェイスの唯一のネットワークアドレスである場合（対応するi_local_iface_addr_listの唯一のネットワークアドレス）、セクション9.2で指定されているようにそのインターフェイスを削除します。
3. Otherwise:
3. さもないと：
1. Remove the removed address from this I_local_iface_addr_list.
1. このi_local_iface_addr_listから削除されたアドレスを削除します。
2. If the removed address is not in the I_local_iface_addr_list of any other Local Interface Tuple, then create a Removed Interface Address Tuple with:
2. 削除されたアドレスが他のローカルインターフェイスタプルのi_local_iface_addr_listにない場合は、削除されたインターフェイスアドレスタプルを作成します。
o IR_local_iface_addr := removed address;
o IR_LOCAL_IFACE_ADDR：=削除アドレス;
o IR_time := current time + I_HOLD_TIME.
o IR_TIME：= Current Time I_HOLD_TIME。
After removing the network address and making these changes, a HELLO message MAY be sent on all MANET interfaces.
ネットワークアドレスを削除してこれらの変更を加えた後、すべてのMANETインターフェイスでハローメッセージを送信できます。
The packet and message format used by this protocol is defined in [RFC5444], which is used with the following considerations:
このプロトコルで使用されるパケットとメッセージの形式は、[RFC5444]で定義されています。これは、次の考慮事項で使用されます。
o This protocol specifies one Message Type, the HELLO message.
o このプロトコルは、1つのメッセージタイプ、Helloメッセージを指定します。
o A HELLO message MAY use any combination of Message Header options specified in [RFC5444].
o Helloメッセージは、[RFC5444]で指定されたメッセージヘッダーオプションの任意の組み合わせを使用する場合があります。
o HELLO messages MUST NOT be forwarded, i.e., a <msg-hop-limit>, if present, MUST have the value 1.
o こんにちはメッセージを転送する必要はありません。つまり、a <msg-hop-limit>は、存在する場合は、値1を持っている必要があります。
o HELLO messages MAY be included in multi-message packets as specified in [RFC5444].
o こんにちはメッセージは、[RFC5444]で指定されているように、マルチメッセージパケットに含まれる場合があります。
o Received HELLO messages MUST be parsed in accordance with [RFC5444]. A HELLO message that is not in conformance with [RFC5444] MUST be discarded without being processed. A HELLO message can also be discarded without being processed for other reasons, see Section 12.1.
o 受信したハローメッセージは、[RFC5444]に従って解析する必要があります。[RFC5444]に準拠していないハローメッセージは、処理されずに破棄する必要があります。ハローメッセージは、他の理由で処理されることなく破棄することもできます。セクション12.1を参照してください。
o This protocol specifies three Address Block TLVs. It also uses two Message TLVs defined in [RFC5497]. These five TLV Types are all defined only with Type Extension = 0. TLVs of other types, and of these types but without Type Extension = 0, are ignored by this protocol. All references in this specification to, for example, an Address Block TLV with Type = LINK_STATUS, are to be considered as referring to an Address Block TLV with Type = LINK_STATUS and Type Extension = 0.
o このプロトコルは、3つのアドレスブロックTLVを指定します。また、[RFC5497]で定義された2つのメッセージTLVを使用します。これらの5つのTLVタイプはすべて、タイプ拡張= 0でのみ定義されます。他のタイプのTLV、およびこれらのタイプのTLVは、このプロトコルによって無視されます。この仕様のすべての参照は、たとえば、type = link_statusのアドレスブロックTLVでは、type = link_statusおよびtype endix = 0のアドレスブロックTLVを参照すると見なされます。
A HELLO message MUST contain:
ハローメッセージには次のことが含まれている必要があります。
o Exactly one VALIDITY_TIME Message TLV as specified in [RFC5497], representing H_HOLD_TIME for the transmitting MANET interface.
o [RFC5497]で指定されている1つの有効性_タイムメッセージTLV。
The options included in [RFC5497] for representing zero and infinite times MUST NOT be used.
ゼロと無限の時間を表すための[RFC5497]に含まれるオプションを使用しないでください。
A HELLO message transmitted due to a periodic timer SHOULD contain, and otherwise (i.e., transmitted for any other reason, in particular in response to any Information Base changes) MAY contain:
定期的なタイマーが含まれる必要があるために送信されるハローメッセージは、それ以外の場合は（つまり、特に情報ベースの変更に応じて、他の理由で送信されます）が含まれる場合があります。
o Exactly one INTERVAL_TIME Message TLV as specified in [RFC5497], representing HELLO_INTERVAL for the transmitting MANET interface. The options included in [RFC5497] for representing zero and infinite times MUST NOT be used.
o [RFC5497]で指定されている1つのinterval_timeメッセージTLV。ゼロと無限の時間を表すための[RFC5497]に含まれるオプションを使用しないでください。
A HELLO message MAY contain:
ハローメッセージには：
o Other Message TLVs.
o その他のメッセージTLV。
o One or more Address Blocks, each with an associated Address Block TLV Block, which MAY contain other Address Block TLVs.
o 1つ以上のアドレスブロックは、それぞれ関連するアドレスブロックTLVブロックを備えており、他のアドレスブロックTLVを含む場合があります。
All network addresses in a router's Local Interface Set (i.e., in any I_local_iface_addr_list) MUST be represented as address objects (see [RFC5444]), and included in the Address Blocks in all generated HELLO messages, with the following permitted exception:
ルーターのローカルインターフェイスセットのすべてのネットワークアドレス（つまり、任意のI_LOCAL_IFACE_ADDR_LIST）はアドレスオブジェクトとして表され（[rfc5444]を参照）、生成されたすべてのハローメッセージのアドレスブロックに含まれています。
o If the MANET interface on which the HELLO message is to be sent has a single address with maximum prefix length (i.e., /32 for IPv4, /128 for IPv6), then that address MAY be omitted from being included in any Address Block, provided that this address is included as the sending address of the IP datagram in which the HELLO message is included.
o Helloメッセージが送信されるMANETインターフェイスに、最大プレフィックス長（つまり、IPv4の場合 /32、IPv6で /128）の単一のアドレスがある場合、そのアドレスは、任意のアドレスブロックに含まれることから省略できます。このアドレスは、Helloメッセージが含まれているIPデータグラムの送信アドレスとして含まれていること。
All network addresses of the router's interfaces included in any Address Block(s) MUST be associated with an Address Block TLV with Type = LOCAL_IF, as defined in Table 1.
任意のアドレスブロックに含まれるルーターのインターフェイスのすべてのネットワークアドレスは、表1で定義されているように、Type = local_ifのアドレスブロックTLVに関連付けられている必要があります。
+----------+---------+----------------------------------------------+
| Name | Value | Description |
| | Length | |
+----------+---------+----------------------------------------------+
| LOCAL_IF | 1 octet | Specifies that the network address is |
| | | associated with the MANET interface on which |
| | | the message was sent (THIS_IF) or another |
| | | interface of the sending router (OTHER_IF). |
+----------+---------+----------------------------------------------+
Table 1: LOCAL_IF TLV Definition
表1：local_if tlv定義
Address Blocks MAY contain current or recently lost 1-hop neighbors' network addresses, represented as address objects (see [RFC5444]), each of which is associated with one or both Address Block TLVs as described in Table 2.
アドレスブロックには、アドレスオブジェクトとして表される現在または最近紛失した1ホップの近隣ネットワークアドレス（[RFC5444]を参照）が含まれている場合があります。それぞれは、表2に記載されている1つまたは両方のアドレスブロックTLVに関連付けられています。
+--------------+---------+------------------------------------------+
| Name | Value | Description |
| | Length | |
+--------------+---------+------------------------------------------+
| LINK_STATUS | 1 octet | Specifies the status of the link from |
| | | the indicated network address and to the |
| | | MANET interface over which the HELLO |
| | | message is transmitted (LOST, SYMMETRIC, |
| | | or HEARD). |
| OTHER_NEIGHB | 1 octet | Specifies that the network address is |
| | | (SYMMETRIC) or was (LOST) of a MANET |
| | | interface of a symmetric 1-hop neighbor |
| | | of the router transmitting the HELLO |
| | | message. |
+--------------+---------+------------------------------------------+
Table 2: LINK_STATUS and OTHER_NEIGHB TLV Definition
表2：link_statusおよびother_neighb tlv定義
An Address Block TLV with Type = LINK_STATUS and Value = SYMMETRIC or Value = LOST also performs the function of an Address Block TLV with Type = OTHER_NEIGHB and the same Value. Including the latter associated with the same address object is discouraged for efficiency reasons. If an Address Block TLV with Type = LINK_STATUS and Value = SYMMETRIC is combined with an Address Block TLV with Type = OTHER_NEIGHB and Value = LOST associated with the same address object, then the latter MUST be ignored and SHOULD NOT be included. See Appendix A.
Type = link_statusおよびvalue = semmetricまたはlost = lostのアドレスブロックTLVは、Type = other_neighbと同じ値を持つアドレスブロックTLVの関数も実行します。同じアドレスオブジェクトに関連付けられた後者を含めることは、効率的な理由で落胆します。Type = link_statusおよびvalue = symmetricを備えたアドレスブロックTLVが、型= other_neighbと同じアドレスオブジェクトに関連付けられているアドレスブロックTLVと組み合わされている場合、後者は無視する必要があります。付録Aを参照してください。
Other network addresses MAY be represented as address objects (see [RFC5444]) and included in Address Blocks, but MUST NOT be associated with any of the Address Block TLVs specified in this specification.
他のネットワークアドレスは、アドレスオブジェクトとして表され（[RFC5444]を参照）、アドレスブロックに含まれている場合がありますが、この仕様で指定されたアドレスブロックTLVに関連付けられてはなりません。
Each MANET interface MUST generate HELLO messages according to the specification in this section. HELLO messages are generated for each MANET interface independently. HELLO message generation and scheduling MUST be according to the interface parameters for that MANET interface, and MAY be independent for each MANET interface or, interface parameters permitting, MANET interfaces MAY use the same schedule.
各MANETインターフェイスは、このセクションの仕様に従ってハローメッセージを生成する必要があります。こんにちはメッセージは、各MANETインターフェイスに対して独立して生成されます。Helloメッセージの生成とスケジューリングは、そのMANETインターフェイスのインターフェイスパラメーターに従って、MANETインターフェイスごとに独立している場合があります。
If transmitting periodic HELLO messages, then, following a HELLO message transmission on a MANET interface, another HELLO message MUST be transmitted on the same MANET interface after an interval not greater than HELLO_INTERVAL. Two successive HELLO message transmissions on the same MANET interface MUST be separated by at least HELLO_MIN_INTERVAL, except as noted in Section 11.2.1.
定期的なハローメッセージを送信する場合、ManetインターフェイスでHelloメッセージの送信に続いて、Hello_intervalより大きくない間隔の後に同じMANETインターフェイスに別のHelloメッセージを送信する必要があります。セクション11.2.1に記載されている場合を除き、同じMANETインターフェイス上の2つの連続したハローメッセージ送信は、少なくともhello_min_intervalによって分離する必要があります。
HELLO messages are generated independently on each MANET interface.
こんにちはメッセージは、各MANETインターフェイスで個別に生成されます。
All network addresses in any I_local_iface_addr_list MUST be included, represented as address objects (see [RFC5444]), except that:
任意のi_local_iface_addr_listのすべてのネットワークアドレスは、アドレスオブジェクトとして表される必要があります（[rfc5444]を参照）。
o If the interface on which the HELLO message is to be sent has a single address with maximum prefix length (i.e., /32 for IPv4, /128 for IPv6), then that address MAY be omitted, provided that this address is included as the sending address of the IP datagram in which the HELLO message is included.
o Helloメッセージが送信されるインターフェイスに最大プレフィックス長（つまり、IPv4の場合 /32、IPv6の場合 /128）の単一のアドレスがある場合、このアドレスが送信として含まれている場合、そのアドレスは省略できます。Helloメッセージが含まれているIPデータグラムのアドレス。
All such included address objects MUST be associated with an Address Block TLV with Type := LOCAL_IF and Value according to the following:
そのようなすべてのアドレスオブジェクトは、タイプ：= local_ifと次の場合のアドレスブロックTLVに関連付けられている必要があります。
o If the address object represents a network address of the sending MANET interface, then Value := THIS_IF.
o アドレスオブジェクトが送信MANETインターフェイスのネットワークアドレスを表している場合、値：= this_if。
o Otherwise, Value := OTHER_IF.
o それ以外の場合、値：= other_if。
If such a network address is included in more than one I_local_iface_addr_list, then, for efficiency reasons, it is encouraged that the corresponding address object is associated with only one Value using an Address Block TLV with Type := LOCAL_IF; this MUST be Value := THIS_IF if the address object represents a network address of the sending MANET interface.
このようなネットワークアドレスが複数のi_local_iface_addr_listに含まれている場合、効率的な理由で、対応するアドレスオブジェクトは、タイプのアドレスブロックTLVを使用して1つの値のみに関連付けられることが推奨されます。これは値でなければなりません：= this_ifアドレスオブジェクトが送信manetインターフェイスのネットワークアドレスを表している場合。
The following network addresses of current or former 1-hop neighbors MAY be represented as address objects (see [RFC5444]) and included in any HELLO message, respecting the parameter REFRESH_INTERVAL for each association for that MANET interface, and according to the following:
現在または以前の1ホップ隣接の以下のネットワークアドレスは、アドレスオブジェクトとして表され（[RFC5444]を参照）、Helloメッセージに含まれ、そのMANETインターフェイスの各関連性のパラメーターREFREFINT_INTERVALを尊重し、以下に従って、次のことを尊重します。
o Network addresses of MANET interfaces of 1-hop neighbors from the Link Set of the Interface Information Base for this MANET interface (i.e., from an L_neighbor_iface_addr_list), other than those from Link Tuples with L_status = PENDING.
o このMANETインターフェイスのインターフェイス情報ベースのリンクセットからの1ホップ近隣のMANETインターフェイスのネットワークアドレス（つまり、L_NEIGHBOR_IFACE_ADDR_LISTから）。
o Other network addresses of symmetric 1-hop neighbors from the Neighbor Set of this router's Neighbor Information Base (i.e., from an N_neighbor_addr_list).
o このルーターの隣接情報ベースの隣接セットからの対称1ホップネイバーの他のネットワークアドレス（つまり、n_neighbor_addr_listから）。
o Network addresses of MANET interfaces of previously symmetric or heard 1-hop neighbors connected on this MANET interface from the Link Set of the Interface Information Base for this MANET interface (i.e., from an L_neighbor_iface_addr_list with L_status = LOST).
o このMANETインターフェイスのインターフェイス情報ベースのリンクセットからこのMANETインターフェイスで接続されている以前に対称または聞こえる1ホップの近隣のMANETインターフェイスのネットワークアドレス（つまり、l_neighbor_iface_addr_listを使用したl_status = lostから）。
o Other network addresses of previously symmetric 1-hop neighbors from the Lost Neighbor Set of this router's Neighbor Information Base (i.e., from an NL_neighbor_addr).
o このルーターの隣接情報ベースの失われた隣接セットからの以前の対称1ホップ隣接の他のネットワークアドレス（つまり、NL_NEIGHBOR_ADDRから）。
Each such address object (see [RFC5444]) MUST be associated with one or more appropriate Address Block TLVs. Specifically:
そのような各アドレスオブジェクト（[RFC5444]を参照）は、1つ以上の適切なアドレスブロックTLVに関連付けられている必要があります。具体的には：
1. For each address object (henceforth linked address) that represents a network address contained in an L_neighbor_iface_addr_list of a Link Tuple in the Link Set for this MANET interface, for which L_status != PENDING, include the linked address with an associated Address Block TLV with:
1. このMANETインターフェイスのリンクセットのリンクタプルのL_NEIGHBOR_IFACE_ADDR_LISTに含まれるネットワークアドレスを表す各アドレスオブジェクト（以下リンクアドレス）について、L_STATUS！=保留には、関連するアドレスブロックTLVを含むリンクアドレスを含みます。
o Type := LINK_STATUS; AND
o タイプ：= link_status;と
o Value := L_status.
o 値：= l_status。
2. For each address object (henceforth neighbor address) that represents a network address contained in an N_neighbor_addr_list in a Neighbor Tuple with N_symmetric = true and that has not already been included with an associated Address Block TLV with Type = LINK_STATUS and Value = SYMMETRIC, include the neighbor network address with an associated Address Block TLV with:
2. N_Symmetric = trueを持つネイバータプルのn_neighbor_addr_listに含まれるネットワークアドレスを表す各アドレスオブジェクト（以下の隣のアドレス）について、タイプ= link_statusおよびvalue =対称の関連するアドレスブロックTLVにまだ含まれていません。関連するアドレスブロックTLVを備えた近隣ネットワークアドレス：
o Type := OTHER_NEIGHB; AND
o タイプ：= other_neighb;と
o Value := SYMMETRIC.
o 値：=対称。
3. For each Lost Neighbor Tuple whose NL_neighbor_addr (henceforth lost address) has not already been represented as an address object and included, include lost address with an associated Address Block TLV with:
3. nl_neighbor_addr（以下で失われたアドレス）が住所オブジェクトとしてまだ表されておらず、関連するアドレスを含む紛失アドレスを含む隣人の故人タプルごとに、次のことを含めます。
o Type := OTHER_NEIGHB; AND
o タイプ：= other_neighb;と
o Value := LOST.
o 値：=紛失。
If any such network addresses have been added to these Information Bases since the last HELLO message was sent on this MANET interface, or if their status (as indicated by these TLVs and the Values they associate with that network address) have changed since that network address was last reported on this MANET interface, then that network address, and the indicated TLVs, SHOULD be included in the HELLO message.
このようなネットワークアドレスがこれらの情報ベースに追加されている場合、最後のハローメッセージがこのMANETインターフェイスに送信されてから、またはそのステータス（これらのTLVとそのネットワークアドレスに関連付けられている値で示されているように）がそのネットワークアドレス以来変更されている場合このMANETインターフェイスで最後に報告され、その後、ネットワークアドレスと示されたTLVをHelloメッセージに含める必要があります。
If the address object (see [RFC5444]) representing a network address of a 1-hop neighbor is specified with more than one associated Address Block TLV, then these Address Block TLVs MAY be independently included or excluded from each HELLO message. Each such Address Block TLV MUST be included associated with the address object representation of that network address in a HELLO message sent on that MANET interface in every interval of length equal to that MANET interface's parameter REFRESH_INTERVAL. Address Block TLVs associated with the same address object included in the same HELLO message MAY be applied to the same or different copies of that address object.
1ホップ隣接のネットワークアドレスを表すアドレスオブジェクト（[RFC5444]を参照）が複数の関連アドレスブロックTLVで指定されている場合、これらのアドレスブロックTLVは、各ハローメッセージから独立して含まれるか、除外される場合があります。このようなアドレスブロックTLVは、そのマネインターフェイスのパラメーターREFRESH_INTERVALに等しいすべての長さのすべての間隔で、そのMALEメッセージインターフェイスに送信されたハローメッセージのアドレスオブジェクト表現に関連付けられている必要があります。同じアドレスメッセージに含まれる同じアドレスオブジェクトに関連付けられたアドレスブロックTLVは、そのアドレスオブジェクトの同じまたは異なるコピーに適用される場合があります。
An implementation of this protocol MAY limit the information included in each HELLO message, for example, to accommodate smaller MTU sizes. HELLO messages remain constrained by the above requirements, in particular, that all local interface information MUST be included in all HELLO messages, and that all neighbor information MUST be sent within each interval of length REFRESH_INTERVAL. This neighbor information MAY, however, be sent in the same or in different HELLO messages.
このプロトコルの実装により、たとえば、より小さなMTUサイズに対応するために、各Helloメッセージに含まれる情報が制限される場合があります。Helloメッセージは、特に上記の要件、特にすべてのローカルインターフェイス情報をすべてのhelloメッセージに含める必要があり、すべての近隣情報を長さのrefresh_intervalの各間隔内で送信する必要があることを制約したままです。ただし、この近隣情報は、同じまたは異なるハローメッセージで送信される場合があります。
HELLO messages are transmitted in the format specified by [RFC5444].
こんにちはメッセージは、[RFC5444]で指定された形式で送信されます。
HELLO messages MAY be sent using periodic message generation or externally triggered message generation. If using data link and physical layers that are subject to packet loss due to collisions, HELLO messages SHOULD be jittered as described in [RFC5148].
Helloメッセージは、定期的なメッセージ生成または外部からトリガーされたメッセージ生成を使用して送信できます。衝突によるパケット損失の対象となるデータリンクと物理レイヤーを使用する場合、[RFC5148]に記載されているように、ハローメッセージをジッタ化する必要があります。
Internally triggered message generation (such as due to a change in local interfaces) MAY be treated as if externally generated message generation or MAY be not jittered.
内部的にトリガーされたメッセージ生成（ローカルインターフェイスの変更によるなど）は、外部から生成されたメッセージ生成がジッタ化されていないかのように扱われる場合があります。
HELLO messages MUST NOT be forwarded, and thus message forwarding jitter does not apply to HELLO messages.
こんにちはメッセージを転送してはならないため、メッセージ転送ジッターはハローメッセージには適用されません。
Each form of jitter described in [RFC5148] requires a parameter MAXJITTER. These interface parameters may be dynamic and are specified by:
[RFC5148]で説明されている各形式のジッターには、パラメーターmaxjitterが必要です。これらのインターフェイスパラメーターは動的であり、次のように指定されている場合があります。
o For periodic message generation: HP_MAXJITTER.
o 定期的なメッセージ生成の場合：hp_maxjitter。
o For externally triggered message generation: HT_MAXJITTER.
o 外部からトリガーされたメッセージ生成の場合：ht_maxjitter。
When HELLO message generation is delayed in order that a HELLO message is not sent within HELLO_MIN_INTERVAL of the previous HELLO message on the same MANET interface, then HELLO_MIN_INTERVAL SHOULD be reduced by jitter, with maximum reduction HP_MAXJITTER, as described in [RFC5148]. In this case, HP_MAXJITTER MUST NOT be greater than HELLO_MIN_INTERVAL.
Hello Message Generationが、同じManetインターフェイス上の前のHelloメッセージのHello_min_interval内にHelloメッセージが送信されないために遅延が遅れた場合、[RFC5148]に記載されているように、HP_MAXJITTERを最大削減するために、Hello_min_intervalをジッターで削減する必要があります。この場合、hp_maxjitterはhello_min_intervalよりも大きくなければなりません。
On receiving a HELLO message, a router MUST first check if the message is invalid for processing by this router, as defined in Section 12.1 and, if so, discard the message without further processing. Otherwise, for each received and valid HELLO message, the receiving router MUST update its appropriate Interface Information Base and its Neighbor Information Base as specified in Section 12.3 to Section 12.6. These updates MUST be performed in the order in which they are presented in this specification. If any changes satisfy any of the conditions described in Section 13, then the indicated consequences in that section MUST be applied immediately, unless noted otherwise.
Helloメッセージを受信すると、ルーターは、セクション12.1で定義されているように、このルーターによるメッセージが無効であるかどうかを最初に確認する必要があります。それ以外の場合、受信した有効なハローメッセージごとに、受信ルーターは、セクション12.3からセクション12.6で指定されている適切なインターフェイス情報ベースと隣接情報ベースを更新する必要があります。これらの更新は、この仕様で提示される順序で実行する必要があります。セクション13で説明されている条件のいずれかを満たしている変更がある場合、特に明記しない限り、そのセクションで示された結果はすぐに適用されなければなりません。
All message processing, including determination of whether a message is invalid, considers only TLVs with Type Extension = 0. TLVs with any other type extension are ignored. All references to, for example, a TLV with Type = LINK_STATUS refer to a TLV with Type = LINK_STATUS and Type Extension = 0.
メッセージが無効であるかどうかの決定を含むすべてのメッセージ処理は、タイプ拡張= 0のTLVのみを考慮します。たとえば、type = link_statusのTLVへのすべての参照は、type = link_statusとtype endix = 0のTLVを参照しています。
A received HELLO message is invalid for processing by this router if any of the following conditions are true:
以下の条件のいずれかが真である場合、受信したハローメッセージは、このルーターによる処理に無効です。
o The address length as specified in the Message Header is not equal to the length of the addresses used by this router.
o メッセージヘッダーで指定されているアドレスの長さは、このルーターで使用されるアドレスの長さに等しくありません。
o The message has a <msg-hop-limit> field in its Message Header with a value other than one. (Note that the message does not need to have a <msg-hop-limit> field.)
o メッセージには、メッセージヘッダーに<msg-hop-limit>フィールドがあり、1以外の値があります。（メッセージには<MSG-HOP-LIMIT>フィールドが必要ではないことに注意してください。）
o The message has a <msg-hop-count> field in its Message Header with a value other than zero. (Note that the message does not need to have a <msg-hop-count> field.)
o メッセージには、ゼロ以外の値を持つメッセージヘッダーに<sg-hop-count>フィールドがあります。（メッセージには<sg-hop-count>フィールドが必要ではないことに注意してください。）
o The message does not have a Message TLV with Type = VALIDITY_TIME in its Message TLV Block.
o メッセージには、メッセージTLVブロックにtype = vuricidity_timeを持つメッセージTLVがありません。
o The message has more than one Message TLV with Type = VALIDITY_TIME in its Message TLV Block.
o メッセージには、メッセージTLVブロックにtype = culidity_timeを備えた複数のメッセージTLVがあります。
o The message has more than one Message TLV with Type = INTERVAL_TIME in its Message TLV Block.
o メッセージには、メッセージTLVブロックにType = interval_timeを備えた複数のメッセージTLVがあります。
o The message has any Address Block TLV(s) with Type = LOCAL_IF and any single Value v such that v != THIS_IF and v != OTHER_IF.
o メッセージには、inpthers = the_if and v！= other_ifなどのType = local_ifと任意の単一値Vを備えたアドレスブロックTLVがあります。
o Any address object (including different address objects representing the same network address, in the same or different Address Blocks) is associated with more than one Value by one or more Address Block TLV(s) with Type = LOCAL_IF.
o 任意のアドレスオブジェクト（同じネットワークアドレスを表す異なるアドレスオブジェクトを含む、同じまたは異なるアドレスブロックで）は、type = local_ifを使用して1つ以上のアドレスブロックTLVによって複数の値に関連付けられています。
o Any address object (henceforth local address) associated with an Address Block TLV with Type = LOCAL_IF represents one of the receiving router's current or recently used network addresses (i.e., local address overlaps any network address in any I_local_iface_addr_list in the Local Interface Set or any IR_local_iface_addr in the Removed Interface Address Set).
o Addressオブジェクト（以下ローカルアドレス）は、type = local_ifを備えたアドレスブロックTLVに関連付けられています。受信ルーターの現在または最近使用されているネットワークアドレスの1つを表します（つまり、ローカルアドレスは、ローカルインターフェイスセットまたはir_local_iface_addrddrddrddrddrddrの任意のi_local_iface_addr_listのネットワークアドレスを重複しています。削除されたインターフェイスアドレスセット）。
o The message has any Address Block TLV(s) with Type = LINK_STATUS with any single Value v such that v != LOST, v != SYMMETRIC, and v != HEARD.
o メッセージには、v！= lost、v！= symmetric、v！= heardのように、type = link_statusを備えた任意の単一値Vを持つアドレスブロックTLVがあります。
o The message has any Address Block TLV(s) with Type = OTHER_NEIGHB with any single Value v such that v != LOST and v != SYMMETRIC.
o メッセージには、v！= lostおよびv！= symmetricであるような、ingle_neighbを使用して、type = other_neighbを備えたアドレスブロックtlv（s）があります。
o Any address object (including different copies of an address object, in the same or different Address Blocks) is associated with an Address Block TLV with Type = LOCAL_IF and with an Address Block TLV with Type = LINK_STATUS.
o アドレスオブジェクト（同じまたは異なるアドレスブロック内のアドレスオブジェクトの異なるコピーを含む）は、Type = local_ifのアドレスブロックTLVおよびtype = link_statusのアドレスブロックTLVに関連付けられています。
o Any address object (including different copies of an address object, in the same or different Address Blocks) is associated with an Address Block TLV with Type = LOCAL_IF and with an Address Block TLV with Type = OTHER_NEIGHB.
o アドレスオブジェクト（同じまたは異なるアドレスブロック内のアドレスオブジェクトの異なるコピーを含む）は、Type = local_ifのアドレスブロックTLVおよびtype = other_neighbのアドレスブロックTLVに関連付けられています。
o Any address object (including different copies of an address object, in the same or different Address Blocks) is associated with more than one Value by one or more Address Block TLVs with Type = LINK_STATUS.
o 任意のアドレスオブジェクト（同じまたは異なるアドレスブロック内のアドレスオブジェクトの異なるコピーを含む）は、type = link_statusの1つ以上のアドレスブロックTLVによって複数の値に関連付けられています。
o Any address object (including different copies of an address object, in the same or different Address Blocks) is associated with more than one Value by one or more Address Block TLVs with Type = OTHER_NEIGHB.
o 任意のアドレスオブジェクト（同じまたは異なるアドレスブロック内のアドレスオブジェクトの異なるコピーを含む）は、type = other_neighbを使用して1つ以上のアドレスブロックTLVによって複数の値に関連付けられています。
A router MAY recognize additional reasons for identifying that a message is badly formed and therefore invalid for processing, e.g., to allow a security protocol as suggested in Section 17 to perform verification of HELLO message signatures and prevent processing of unverifiable HELLO messages by this protocol.
ルーターは、セクション17で提案されているセキュリティプロトコルがHelloメッセージ署名の検証を実行し、このプロトコルによる未検証のHelloメッセージの処理を防ぐために、メッセージがひどく形成されているため、処理に無効であることを特定する追加の理由を認識する場合があります。
An invalid message MUST be silently discarded, without updating the router's Information Bases.
ルーターの情報ベースを更新せずに、無効なメッセージを静かに破棄する必要があります。
For the purpose of this section, note the following definitions:
このセクションの目的のために、次の定義に注意してください。
o "validity time" is calculated from the Message TLV with Type = VALIDITY_TIME of the HELLO message as specified in [RFC5497]. (Note that, as specified by Section 12.1, there must be exactly one such Message TLV in the HELLO message.) All information in the HELLO message used by this specification has the same validity time.
o 「有効性時間」は、[rfc5497]で指定されているように、型= culidity_ helloメッセージのtype = quality_timeでメッセージtlvから計算されます。（セクション12.1で指定されているように、HelloメッセージにはそのようなメッセージTLVが1つある必要があります。）この仕様で使用されているHelloメッセージのすべての情報には、同じ有効期間があります。
o "Receiving Address List" is the I_local_iface_addr_list corresponding to the MANET interface on which the HELLO message was received
o 「アドレスリストの受信」は、Helloメッセージが受信されたMANETインターフェイスに対応するi_local_iface_addr_listです
o "Sending Address List" is an unordered list of network addresses of the MANET interface over which the HELLO message was sent, i.e., is an unordered list of the network addresses represented by address objects contained in the HELLO message with an associated Address Block TLV with Type = LOCAL_IF and Value = THIS_IF. If the Sending Address List is otherwise empty, then the Sending Address List contains a single network address with maximum prefix length (i.e., /32 for IPv4, /128 for IPv6) with an address equal to the sending address of the IP datagram in which the HELLO message was included.
o 「アドレスリストの送信」は、Helloメッセージが送信されたMANETインターフェイスのネットワークアドレスの順序付けられていないリストです。つまり、関連するアドレスブロックTLVを持つHello Messageに含まれるアドレスオブジェクトに表されるネットワークアドレスの順序付けられていないリストです。type = local_ifおよびvalue = this_if。送信アドレスリストが空になる場合、送信アドレスリストには、最大プレフィックス長（つまり、IPv4の場合 /32、IPv6の場合は /128）の単一のネットワークアドレスが含まれています。こんにちはメッセージが含まれていました。
o "Neighbor Address List" is an unordered list of all the network addresses of all the interfaces of the router that generated the HELLO message, i.e., is the Sending Address List, plus the network addresses represented by address objects contained in the HELLO message with an associated Address Block TLV with Type = LOCAL_IF and Value = OTHER_IF.
o 「neighborアドレスリスト」は、ハローメッセージを生成したルーターのすべてのインターフェイスのすべてのネットワークアドレスの順序付けられていないリストです。つまり、送信アドレスリストと、helloメッセージに含まれるアドレスオブジェクトで表されるネットワークアドレスは、型= local_ifおよびvalue = other_ifで関連するアドレスブロックTLV。
o "EXPIRED" indicates that a timer is set to a value clearly preceding the current time (e.g., current time - 1).
o 「期限切れ」は、タイマーが現在の時刻の前に明確に値に設定されていることを示します（例：現在の時刻-1）。
o "Removed Address List" is a list of network addresses created by this HELLO message processing that were formerly reported as local by the router originating the HELLO message but that are not included in the Neighbor Address List. This list is initialized as empty.
o 「削除されたアドレスリスト」は、このハローメッセージ処理によって作成されたネットワークアドレスのリストです。これは、以前はHelloメッセージを発信するルーターによってローカルとして報告されていましたが、ネイバーアドレスリストには含まれていません。このリストは空として初期化されます。
o "Lost Address List" is a subset of the Removed Address List containing network addresses that were formerly considered as symmetric. This list is initialized as empty.
o 「Lost Address List」は、以前は対称と見なされていたネットワークアドレスを含む削除されたアドレスリストのサブセットです。このリストは空として初期化されます。
On receiving a HELLO message, the router MUST update its Neighbor Set and populate the Removed Address List and Lost Address List:
ハローメッセージを受信すると、ルーターは近隣セットを更新し、削除されたアドレスリストと紛失したアドレスリストを入力する必要があります。
1. Find all Neighbor Tuples (henceforth matching Neighbor Tuples) where N_neighbor_addr_list contains any network address that overlaps with any network address in the Neighbor Address List.
1. N_NEIGHBOR_ADDR_LISTには、N_NEIGHBOR_ADDR_LISTが近隣アドレスリストのネットワークアドレスと重複するネットワークアドレスが含まれている場合、すべての近隣のタプル（今後は近隣のタプルと一致する）を見つけます。
2. If there are no matching Neighbor Tuples, then:
2. 隣人のタプルが一致していない場合は、
1. Create a new Neighbor Tuple with:
1. 次のような新しい隣人のタプルを作成します
o N_neighbor_addr_list := Neighbor Address List;
o n_neighbor_addr_list：= neighborアドレスリスト;
o N_symmetric := false.
o n_symmetric：= false。
3. If there is one matching Neighbor Tuple, then:
3. 一致する隣人のタプルが1つある場合、次のようになります。
1. If the matching Neighbor Tuple's N_neighbor_addr_list != Neighbor Address List, then:
1. 一致する隣のTupleのN_NEIGHBOR_ADDR_LIST！= Neighborアドレスリストの場合、次のとおりです。
1. For each network address (henceforth removed address) that is contained in that N_neighbor_addr_list but that is not contained in the Neighbor Address List:
1. そのn_neighbor_addr_listに含まれる各ネットワークアドレス（以下削除されたアドレス）については、近隣のアドレスリストには含まれていません。
1. Add the removed address to the Removed Address List.
1. 削除されたアドレスを削除したアドレスリストに追加します。
2. If N_symmetric = true, then add the removed address to the Lost Address List.
2. n_symmetric = trueの場合、削除されたアドレスを紛失アドレスリストに追加します。
2. Update the matching Neighbor Tuple by:
2. 一致する隣人のタプルを更新してください：
o N_neighbor_addr_list := Neighbor Address List.
o n_neighbor_addr_list：=隣のアドレスリスト。
4. If there are two or more matching Neighbor Tuples, then:
4. 2つ以上の一致する隣人のタプルがある場合、：
1. For each network address (henceforth removed address) that is contained in the N_neighbor_addr_list of any of the matching Neighbor Tuples but is not contained in the Neighbor Address List:
1. 一致する近隣のタプルのいずれかのn_neighbor_addr_listに含まれるネットワークアドレス（以下削除されたアドレス）については、近隣のアドレスリストには含まれていません。
1. Add removed address to the Removed Address List.
1. 削除されたアドレスを削除したアドレスリストに追加します。
2. If N_symmetric = true, then add removed address to the Lost Address List.
2. n_symmetric = trueの場合、削除されたアドレスを紛失アドレスリストに追加します。
2. Replace the matching Neighbor Tuples by a single Neighbor Tuple with:
2. 一致する隣人のタプルを単一の隣人のタプルに置き換えます。
o N_neighbor_addr_list := Neighbor Address List;
o n_neighbor_addr_list：= neighborアドレスリスト;
o N_symmetric := false
o n_symmetric：= false
On receiving a HELLO message, a router MUST update its Lost Neighbor Set:
ハローメッセージを受信すると、ルーターは失われた隣人セットを更新する必要があります。
1. For each network address (henceforth lost address) that is contained in the Lost Address List, if no Lost Neighbor Tuple with NL_neighbor_addr = lost address exists, then add a Lost Neighbor Tuple with:
1. 失われたアドレスリストに含まれる各ネットワークアドレス（以下の失われたアドレス）について、nl_neighbor_addrの失われた隣人のタプルが存在しない場合、失われたアドレスが存在する場合、次のように紛失した隣人タプルを追加します。
o NL_neighbor_addr := lost address;
o nl_neighbor_addr：=紛失アドレス;
o NL_time := current time + N_HOLD_TIME.
o nl_time：=現在の時間n_hold_time。
On receiving a HELLO message, a router MUST update its Link Sets:
ハローメッセージを受信すると、ルーターはリンクセットを更新する必要があります。
1. Remove all network addresses in the Removed Address List from the L_neighbor_iface_addr_list of all Link Tuples.
1. すべてのリンクタプルのl_neighbor_iface_addr_listから削除されたアドレスリストのすべてのネットワークアドレスを削除します。
2. Remove all Link Tuples whose L_neighbor_iface_addr_list is now empty; apply Section 13.2 but not Section 13.3.
2. l_neighbor_iface_addr_listが空になるすべてのリンクタプルを削除します。セクション13.2を適用しますが、セクション13.3には適用しません。
The router MUST then update its Link Set for the MANET interface on which the HELLO message is received:
ルーターは、Helloメッセージが受信されるMANETインターフェイスのリンクセットを更新する必要があります。
1. Find all Link Tuples (henceforth matching Link Tuples) where:
1. すべてのリンクタプル（今後はリンクのタプルの一致するタプル）を見つける場所：
o L_neighbor_iface_addr_list contains one or more network addresses in the Sending Address List.
o l_neighbor_iface_addr_list送信アドレスリストに1つ以上のネットワークアドレスが含まれています。
2. If there is more than one matching Link Tuple, then remove them all; apply Section 13.2 but not Section 13.3.
2. 複数のマッチングリンクタプルがある場合は、それらをすべて削除します。セクション13.2を適用しますが、セクション13.3には適用しません。
3. If no matching Link Tuples remain, then create a new matching Link Tuple with:
3. 一致するリンクタプルが残っていない場合は、次のような新しいマッチングリンクタプルを作成します。
o L_neighbor_iface_addr_list := empty;
o l_neighbor_iface_addr_list：= empty;
o L_HEARD_time := EXPIRED;
o l_heard_time：= expired;
o L_SYM_time := EXPIRED;
o l_sym_time：= expired;
o L_quality := INITIAL_QUALITY;
o l_quality：= initial_quality;
o L_pending := INITIAL_PENDING;
o l_pending：= initial_pending;
o L_lost := false;
o l_lost：= false;
o L_time := current time + validity time.
o L_TIME：=現在の時間妥当性時間。
4. The matching Link Tuple, existing or new, is then modified as follows:
4. 既存または新規のマッチングリンクタプルは、次のように変更されます。
1. If the router finds any network address (henceforth receiving address) in the Receiving Address List in an Address Block in the HELLO message, then the Link Tuple is modified as follows:
1. ルーターがHelloメッセージのアドレスブロックで受信アドレスリストにネットワークアドレス（以下のアドレス）を見つけた場合、リンクタプルは次のように変更されます。
1. If any receiving address in the HELLO message is associated with an Address Block TLV with Type = LINK_STATUS and with Value = HEARD or Value = SYMMETRIC, then:
1. helloメッセージの受信アドレスが、type = link_statusおよびvalue = heardまたはvalue = symmetricでアドレスブロックTLVに関連付けられている場合、：
o L_SYM_time := current time + validity time.
o L_SYM_TIME：=現在の時間妥当性時間。
2. Otherwise, if any receiving address in the HELLO message is associated with an Address Block TLV with Type = LINK_STATUS and Value = LOST, then:
2. それ以外の場合は、Helloメッセージの受信アドレスが型= link_statusおよびlost = lostでアドレスブロックTLVに関連付けられている場合、：
1. if L_SYM_time has not expired, then:
1. L_SYM_TIMEが期限切れになっていない場合、
1. L_SYM_time := EXPIRED.
1. l_sym_time：=有効期限。
2. if L_status = HEARD, then:
2. l_status =聞いた場合、
o L_time := current time + L_HOLD_TIME.
o l_time：=現在の時間l_hold_time。
2. L_neighbor_iface_addr_list := Sending Address List.
2. l_neighbor_iface_addr_list：=アドレスリストの送信。
3. L_HEARD_time := max(current time + validity time, L_SYM_time).
3. l_heard_time：= max（現在の時間妥当性時間、l_sym_time）。
4. If L_status = PENDING, then:
4. l_status =保留中の場合、次のとおりです。
o L_time := max(L_time, L_HEARD_time).
o l_time：= max（l_time、l_heard_time）。
5. Otherwise, if L_status = HEARD or L_status = SYMMETRIC, then:
5. それ以外の場合、l_status = heardまたはl_status =対称の場合、次のとおりです。
o L_time := max(L_time, L_HEARD_time + L_HOLD_TIME).
o l_time：= max（l_time、l_heard_time l_hold_time）。
On receiving a HELLO message, a router MUST update its 2-Hop Set for the MANET interface on which the HELLO message was received:
Helloメッセージを受信すると、ルーターはHelloメッセージが受信されたMANETインターフェイスの2ホップセットを更新する必要があります。
1. Remove all network addresses in the Removed Address List from the N2_neighbor_iface_addr_list of all 2-Hop Tuples.
1. すべての2ホップタプルのn2_neighbor_iface_addr_listから削除されたアドレスリストのすべてのネットワークアドレスを削除します。
2. If the Link Tuple whose L_neighbor_iface_addr_list = Sending Address List, has L_status = SYMMETRIC, then:
2. l_neighbor_iface_addr_list =アドレスリストを送信するリンクtupleの場合、l_status = symmetricを持っている場合、次のとおりです。
1. For each network address (henceforth 2-hop address) in an Address Block of the HELLO message, where:
1. Helloメッセージのアドレスブロック内の各ネットワークアドレス（今後2-HOPアドレス）について、ここで：
o a 2-hop address is not contained in the Neighbor Address List;
o 2ホップアドレスは、近隣のアドレスリストに含まれていません。
o a 2-hop address is not contained in any I_local_iface_addr_list; AND
o 2ホップアドレスは、i_local_iface_addr_listに含まれていません。と
o a 2-hop address != any IR_local_iface_addr
o 2ホップアドレス！=任意のIR_LOCAL_IFACE_ADDR
perform the following processing:
次の処理を実行します。
1. If the 2-hop address has an associated Address Block TLV with:
1. 2ホップアドレスに関連するアドレスブロックTLVがある場合：
o Type = LINK_STATUS and Value = SYMMETRIC; OR o Type = OTHER_NEIGHB and Value = SYMMETRIC,
o type = link_statusおよびvalue = symmetric;またはoタイプ= other_neighbおよびvalue = symmetric、
then, if there is no 2-Hop Tuple such that:
次に、次のような2ホップのタプルがない場合
o N2_neighbor_iface_addr_list contains one or more network addresses in the Sending Address List; AND
o N2_NEIGHBOR_IFACE_ADDR_LIST送信アドレスリストに1つ以上のネットワークアドレスが含まれています。と
o N2_2hop_addr = 2-hop address,
o N2_2HOP_ADDR = 2-HOPアドレス、
then create a 2-Hop Neighbor Tuple with:
次に、次のように2ホップの隣人のタプルを作成します。
o N2_2hop_addr := 2-hop address.
o N2_2HOP_ADDR：= 2-HOPアドレス。
This 2-Hop Tuple (existing or new) is then modified as follows:
この2ホップのタプル（既存または新しい）は、次のように変更されます。
o N2_neighbor_iface_addr_list := Sending Address List;
o n2_neighbor_iface_addr_list：=アドレスリストの送信。
o N2_time := current time + validity time.
o N2_TIME：=現在の時間妥当性時間。
2. Otherwise, if a 2-hop address has an Address Block TLV with:
2. それ以外の場合、2ホップアドレスにアドレスブロックTLVがある場合：
o Type = LINK_STATUS and Value = LOST or Value = HEARD; OR
o type = link_statusおよびvalue = lostまたはvalue = heard;また
o Type = OTHER_NEIGHB and Value = LOST;
o type = other_neighbおよびvalue = lost;
then remove all 2-Hop Tuples with:
次に、次のすべての2ホップタプルを削除します。
o N2_neighbor_iface_addr_list containing one or more network addresses in the Sending Address List; AND
o N2_NEIGHBOR_IFACE_ADDR_LIST送信アドレスリストに1つ以上のネットワークアドレスを含む。と
o N2_2hop_addr = 2-hop address.
o N2_2HOP_ADDR = 2-HOPアドレス。
The Interface and Neighbor Information Bases MUST be changed when certain events occur. These events may result from HELLO message processing or may be otherwise generated (e.g., expiry of timers or link quality changes).
特定のイベントが発生したときに、インターフェイスと隣接の情報ベースを変更する必要があります。これらのイベントは、Hello Message Processingから生成されるか、そうでなければ生成される場合があります（たとえば、タイマーの有効期限やリンクの品質変更）。
Events that cause changes in the Information Bases are:
情報ベースの変更を引き起こすイベントは次のとおりです。
o A Link Tuple's L_status changes to SYMMETRIC. In this case, the actions specified in Section 13.1 are performed.
o リンクTupleのL_Statusは対称に変わります。この場合、セクション13.1で指定されたアクションが実行されます。
o A Link Tuple's L_status changes from SYMMETRIC, or the Link Tuple is removed. In this case, the actions specified in Section 13.2 are performed.
o リンクTupleのL_Statusは対称性から変化するか、リンクタプルが削除されます。この場合、セクション13.2で指定されたアクションが実行されます。
o A Link Tuple's L_HEARD_time expires, or the Link Tuple is removed. In this case, the actions specified in Section 13.3 are performed.
o リンクTupleのL_HEARD_TIMEが期限切れになるか、リンクタプルが削除されます。この場合、セクション13.3で指定されたアクションが実行されます。
o Local interface network address changes. In this case, the actions specified in Section 9 are performed.
o ローカルインターフェイスネットワークアドレスの変更。この場合、セクション9で指定されたアクションが実行されます。
o Link quality changes. In this case, the actions specified in Section 14 are performed.
o リンク品質の変更。この場合、セクション14で指定されたアクションが実行されます。
If a Link Tuple is removed, or if L_status changes from SYMMETRIC and L_HEARD_time expires, then the actions specified in Section 13.2 MUST be performed before the actions specified in Section 13.3 are performed for that Link Tuple.
リンクタプルが削除された場合、またはl_statusが対称およびl_heard_timeから変更された場合、セクション13.3で指定されたアクションがそのリンクタプルに対して実行される前に、セクション13.2で指定されたアクションを実行する必要があります。
A router MAY report updated information in response to any of these changes in HELLO message(s), subject to the constraints in Section 11.
ルーターは、セクション11の制約を条件として、Helloメッセージのこれらの変更に応じて更新された情報を報告する場合があります。
A router that transmits HELLO messages in response to such changes SHOULD transmit a HELLO message:
このような変更に応じてハローメッセージを送信するルーターは、ハローメッセージを送信する必要があります。
o On all MANET interfaces, if the Neighbor Set changes such as to indicate the change in symmetry of any 1-hop neighbors (including addition or removal of symmetric 1-hop neighbors).
o すべてのMANETインターフェイスで、隣接が変更された場合、1ホップの隣人の対称性の変化を示すように変更されます（対称1ホップ隣接の追加または除去を含む）。
o Otherwise, on all those MANET interfaces whose Link Set changes such as to indicate a change in L_status of any 1-hop neighbors (including the addition or removal of any 1-hop neighbors, other than those considered pending).
o それ以外の場合、リンクセットが変更されたすべてのMANETインターフェイスで、1ホップの隣人のl_statusの変化を示すなどの変更（保留中と見なされるもの以外の1ホップ隣人の追加または除去を含む）。
If, for any Link Tuple that does not have L_status = SYMMETRIC:
L_Status = symmetricを持たないリンクタプルの場合：
o L_status changes to SYMMETRIC;
o l_statusは対称に変更されます。
then:
それから：
1. For the Neighbor Tuple whose N_neighbor_addr_list contains L_neighbor_iface_addr_list, set:
1. n_neighbor_addr_listがL_neighbor_iface_addr_listを含む隣人のタプルの場合、set：
o N_symmetric := true.
o n_symmetric：= true。
2. Remove all Lost Neighbor Tuples whose NL_neighbor_addr is contained in that N_neighbor_addr_list.
2. nl_neighbor_addrがそのn_neighbor_addr_listに含まれているすべての失われた隣人のタプルを削除します。
This includes any newly created Link Tuples whose status is immediately updated such that L_status = SYMMETRIC. (Note that in this specification, all Link Tuples are created such that their L_status is not SYMMETRIC, but a Link Tuple may be immediately updated by subsequent processing of the same HELLO message that caused the creation of the Link Tuple such that the Link Tuple's L_status changes to SYMMETRIC.)
これには、l_status = symmetricになるようにステータスがすぐに更新される新しく作成されたリンクタプルが含まれます。（この仕様では、L_STATUSが対称ではないようにすべてのリンクタプルが作成されますが、リンクTupleのL_STATUSがリンクタプルの作成を引き起こした同じハローメッセージの後続の処理によって、リンクタプルがすぐに更新される可能性があることに注意してください。対称への変更。）
If for any Link Tuple with L_status = SYMMETRIC:
L_STATUS = symmetricを使用したリンクタプルの場合：
o L_status changes to any other value; OR
o l_statusは他の値に変更されます。また
o the Link Tuple is removed;
o リンクタプルが削除されます。
then:
それから：
1. All 2-Hop Tuples for the same MANET interface with:
1. 次のようなMANETインターフェイスのためのすべての2ホップタプル
o N2_neighbor_iface_addr_list contains one or more network addresses in L_neighbor_iface_addr_list;
o n2_neighbor_iface_addr_list l_neighbor_iface_addr_listに1つ以上のネットワークアドレスが含まれています。
are removed.
削除されます。
2. For the Neighbor Tuple whose N_neighbor_addr_list contains L_neighbor_iface_addr_list:
2. n_neighbor_addr_listがL_neighbor_iface_addr_listを含む隣人のタプルの場合：
1. If there are no remaining Link Tuples for any MANET interface where:
1. MANETインターフェイスに残りのリンクタプルがない場合：
o L_neighbor_iface_addr_list is contained in N_neighbor_addr_list; AND
o l_neighbor_iface_addr_listはn_neighbor_addr_listに含まれています。と
o L_status = SYMMETRIC;
o l_status = symmetric;
then modify the Neighbor Tuple by:
次に、次のように隣人のタプルを変更します。
1. N_symmetric := false.
1. n_symmetric：= false。
2. For each network address (henceforth neighbor address) in N_neighbor_addr_list, add a Lost Neighbor Tuple with:
2. n_neighbor_addr_listの各ネットワークアドレス（以下の近隣アドレス）について、紛失したネイバータプルを追加します。
o NL_neighbor_addr := neighbor address;
o nl_neighbor_addr：= neighborアドレス;
o NL_time := current time + N_HOLD_TIME.
o nl_time：=現在の時間n_hold_time。
If, for any Link Tuple:
リンクのタプルの場合：
o L_HEARD_time expires; OR
o l_heard_timeの有効期限。また
o the Link Tuple is removed;
o リンクタプルが削除されます。
then:
それから：
1. For the Neighbor Tuple whose N_neighbor_addr_list contains L_neighbor_iface_addr_list, if no Link Tuples for any MANET interface remain where:
1. n_neighbor_addr_listにl_neighbor_iface_addr_listが含まれている隣人のタプルの場合、manetインターフェイスのリンクタプルが残っていない場合：
o L_neighbor_iface_addr_list is contained in N_neighbor_addr_list; AND
o l_neighbor_iface_addr_listはn_neighbor_addr_listに含まれています。と
o L_HEARD_time is not expired;
o L_HEARD_TIMEは期限切れではありません。
then remove the Neighbor Tuple.
次に、隣人のタプルを取り外します。
Link quality is a mechanism whereby a router MAY take considerations other than message exchange into account for determining when a link is and is not a candidate for being considered as HEARD or SYMMETRIC. As such, it is a "link admission" mechanism.
リンクの品質は、ルーターがメッセージ交換以外の考慮事項を、リンクがいつであるか、または対称と見なされる候補ではないことを考慮するために考慮事項をとることができるメカニズムです。そのため、「リンク入場」メカニズムです。
Link quality information for a link is generated (e.g., through access to signal to noise ratio, packet loss rate, or other information from the link layer) and used only locally, i.e., is not included in signaling, and routers may interoperate whether they are using the same, different, or no, link quality information. Link quality information is specified as a normalized, dimensionless figure in the interval zero to one, inclusive, a higher value indicating a better link quality.
リンクのリンク品質情報は生成されます（たとえば、シグナルとノイズ比、パケット損失率、またはリンクレイヤーからのその他の情報へのアクセスを介して）。同じ、異なる、またはno、リンク品質情報を使用しています。リンク品質情報は、間隔ゼロから1つの間隔の正規化された無次元の数値として指定されており、より高い値を示し、より良いリンク品質を示しています。
For deployments where no link quality is used, the considerations in Section 14.1 apply. For deployments where link quality is used, the general principles of link quality usage are described in Section 14.2. Sections 14.3 and 14.4 detail link quality functioning.
リンク品質が使用されない展開には、セクション14.1の考慮事項が適用されます。リンク品質が使用される展開については、リンクの品質使用量の一般原則について説明します。セクション14.2で説明します。セクション14.3および14.4の詳細リンク品質機能。
In order for a router to not employ link quality, the router MUST define:
ルーターがリンク品質を使用しないためには、ルーターが定義する必要があります。
o INITIAL_PENDING := false;
o initial_pending：= false;
o INITIAL_QUALITY >= HYST_REJECT (there is no reason not to define INITIAL_QUALITY := 1).
o initial_quality> = hyst_reject（initial_quality：= 1を定義しない理由はありません）。
To enable link quality usage, the L_quality value of a Link Tuple is used in conjunction with two thresholds, HYST_ACCEPT and HYST_REJECT, to set the flags L_pending and L_lost of that Link Tuple. Based on these flags, the link status to advertise for that Link Tuple is determined as described in Section 7.1.
リンクの品質使用量を有効にするために、リンクタプルのl_quality値は、2つのしきい値、Hyst_acceptとhyst_rejectと組み合わせて使用され、そのリンクタプルのフラグl_lostとl_lostを設定します。これらのフラグに基づいて、そのリンクタプルの広告へのリンクステータスは、セクション7.1で説明されているように決定されます。
The use of two thresholds implements link hysteresis, whereby a link that has HYST_REJECT <= L_quality < HYST_ACCEPT may be either accepted or rejected (depending on which threshold it has most recently crossed, or, if neither, on the value of parameter INITIAL_PENDING). With appropriate values of these parameters, this prevents overly rapid changes of link status.
2つのしきい値を使用すると、ヒステリシスがリンクされます。これにより、hyst_reject <= l_quality <hyst_acceptが受け入れられるか拒否される可能性があります（最近の接続されたしきい値に応じて、またはパラメーター初期_pendingの値に応じて）。これらのパラメーターの適切な値を使用すると、これにより、リンクステータスの過度に急速な変化が防止されます。
The basic principles of link quality usage are as follows:
リンクの品質使用量の基本原則は次のとおりです。
o A router does not advertise a neighbor interface in any state until L_quality is acceptable:
o ルーターは、l_qualityが許容されるまで、どの状態で隣接インターフェイスを宣伝しません。
o If INITIAL_PENDING = true, then the link is advertised when link L_quality >= HYST_ACCEPT.
o initial_pending = trueの場合、リンクl_quality> = hyst_acceptの場合、リンクが宣伝されます。
o Otherwise, the link is advertised when L_quality >= HYST_REJECT.
o それ以外の場合、リンクはl_quality> = hyst_rejectのときに宣伝されます。
A link that is not yet advertised has L_pending = true.
まだ宣伝されていないリンクには、l_pending = trueがあります。
o Once L_quality >= HYST_ACCEPT, the router sets L_pending := false, indicating that the link can be advertised.
o l_quality> = hyst_acceptを使用すると、ルーターはl_pending：= falseを設定し、リンクを宣伝できることを示します。
o A link for which L_pending = false is advertised until its L_quality drops below HYST_REJECT.
o l_pending = falseがl_qualityがhyst_rejectを下回るまで宣伝されるリンク。
o If a link has L_pending = false and L_quality < HYST_REJECT, the link is LOST and is advertised as such. This link is not reconsidered as a candidate HEARD or SYMMETRIC link until L_quality >= HYST_ACCEPT.
o リンクにl_pending = falseおよびl_quality <hyst_rejectがある場合、リンクは失われ、そのように宣伝されています。このリンクは、L_Quality> = hyst_acceptまで、候補者の聞き取りまたは対称リンクとして再考されません。
o A link that has an acceptable quality may be advertised as HEARD, SYMMETRIC or LOST according to the exchange of HELLO messages.
o 許容可能な品質を持つリンクは、Helloメッセージの交換に応じて、聞かれる、対称的、または失われたように宣伝される場合があります。
In order that these principles can all hold, a router MUST NOT define:
これらの原則がすべて保持できるために、ルーターが定義してはなりません。
o INITIAL_PENDING = false and INITIAL_QUALITY < HYST_REJECT; OR
o initial_pending = falseおよびinitial_quality <hyst_reject;また
o INITIAL_PENDING = true and INITIAL_QUALITY >= HYST_ACCEPT.
o initial_pending = true and initial_quality> = hyst_accept。
If L_quality for a link changes, then the following actions MUST be taken:
リンクのL_Qualityが変更された場合、次のアクションを実行する必要があります。
1. If L_quality >= HYST_ACCEPT, then the corresponding Link Tuple is modified by:
1. l_quality> = hyst_acceptの場合、対応するリンクタプルは次のように変更されます。
1. L_pending := false;
1. l_pending：= false;
2. L_lost := false;
2. l_lost：= false;
3. If L_status = HEARD or L_status = SYMMETRIC, then:
3. l_status = heardまたはl_status =対称の場合、次の場合：
o L_time := max(L_time, L_HEARD_time + L_HOLD_TIME).
o l_time：= max（l_time、l_heard_time l_hold_time）。
2. If L_status != PENDING, and L_quality < HYST_REJECT, then the corresponding Link Tuple is modified by:
2. l_status！= pending、およびl_quality <hyst_rejectの場合、対応するリンクタプルは次のように変更されます。
1. If L_lost = false, then:
1. l_lost = falseの場合、次の場合：
o L_lost := true;
o l_lost：= true;
o L_time := min(L_time, current time + L_HOLD_TIME).
o l_time：= min（l_time、現在の時間l_hold_time）。
As a result of this processing, the L_STATUS of a Link Tuple may change. In this case, the processing actions corresponding to this change, as specified in Section 13, MUST also be taken.
この処理の結果、リンクタプルのl_statusが変更される場合があります。この場合、セクション13で指定されているように、この変更に対応する処理アクションも取得する必要があります。
If L_quality for a link is updated based on HELLO message reception, or on reception of a packet including a HELLO message, then L_quality MUST be updated prior to the HELLO message processing described in Section 12. (If the receipt of the HELLO message, or the packet containing it, creates the Link Tuple, then the Link Tuple MUST be created with the appropriately updated L_quality value, rather than with L_quality := INITIAL_QUALITY.)
リンクのL_QualityがHelloメッセージの受信に基づいて更新される場合、またはHelloメッセージを含むパケットの受信に基づいて更新される場合、セクション12で説明されているHelloメッセージ処理の前にL_Qualityを更新する必要があります（Helloメッセージの受信、またはそれを含むパケットは、リンクタプルを作成し、リンクタプルは、l_quality：= initial_qualityではなく、適切に更新されたl_quality値で作成する必要があります。
A router MAY update link quality based on any information available to it. Particular cases that MAY be used include:
ルーターは、利用可能な情報に基づいてリンク品質を更新する場合があります。使用できる特定のケースには次のものがあります。
o Information from the link layer, such as signal-to-noise ratio or packet acknowledgment reception and loss information.
o 信号対雑音の比率やパケットの確認受信および損失情報など、リンクレイヤーからの情報。
o Receipt or loss of control packets. If control packets include a sequential packet sequence number, as defined in [RFC5444], then link quality can be updated when a control packet is received, whether or not it contains a HELLO message. The link quality may then, for example, be based on whether the last N out of M control packets on the link were received, or may use a "leaky integrator" tracking packet reception and loss.
o 制御パケットの領収書または損失。[RFC5444]で定義されているように、コントロールパケットにシーケンシャルパケットシーケンス番号が含まれている場合、ハローメッセージが含まれているかどうかにかかわらず、コントロールパケットが受信されたときにリンク品質を更新できます。たとえば、リンクの品質は、リンク上のMコントロールパケットの最後のnが受信されたかどうかに基づいているか、パケットの受信と損失を追跡する「漏れやすいインテグレーター」を使用するかどうかに基づいている場合があります。
o Receipt or loss of HELLO messages. If the maximum interval between HELLO messages is known (such as by inclusion in HELLO messages of a Message TLV with Type := INTERVAL_TIME, as defined in [RFC5497]), then the loss of HELLO messages can be determined without the need to receive a later HELLO message. Note that if this case is combined with the previous case, then care must be taken to avoid "double counting" a lost HELLO message in a lost packet.
o ハローメッセージの領収書または損失。Helloメッセージ間の最大間隔が既知である場合（[RFC5497]で定義されているように、TLVのメッセージTLVのHelloメッセージに含めるなど）、Helloメッセージの損失は、受信する必要なく決定できます。後でこんにちはメッセージ。このケースが以前のケースと組み合わされている場合、失われたパケットで失われたハローメッセージを「二重カウント」することを避けるために注意する必要があることに注意してください。
This section lists the parameters and constants used in the specification of the protocol, and proposed values of each that MAY be used when a single value of each is used.
このセクションには、プロトコルの仕様で使用されるパラメーターと定数をリストし、それぞれの単一の値を使用したときに使用できる各値の提案された値をリストします。
o HELLO_INTERVAL := 2 seconds
o hello_interval：= 2秒
o HELLO_MIN_INTERVAL := HELLO_INTERVAL/4
o hello_min_interval：= hello_interval/4
o REFRESH_INTERVAL := HELLO_INTERVAL
o refress_interval：= hello_interval
o H_HOLD_TIME := 3 x REFRESH_INTERVAL
o h_hold_time：= 3 x refresh_interval
o L_HOLD_TIME := H_HOLD_TIME
o l_hold_time：= H_HOLD_TIME
o N_HOLD_TIME := L_HOLD_TIME
o n_hold_time：= l_hold_time
o I_HOLD_TIME := N_HOLD_TIME
o i_hold_time：= n_hold_time
If link quality is changed, then parameter values will depend on the link quality process. If link quality is not changed, then:
リンクの品質が変更された場合、パラメーター値はリンクの品質プロセスに依存します。リンクの品質が変更されていない場合は、
o HYST_ACCEPT := 1
o hyst_accept：= 1
o HYST_REJECT := 0
o hyst_reject：= 0
o INITIAL_QUALITY := 1
o initial_quality：= 1
o INITIAL_PENDING := false
o initial_pending：= false
o HP_MAXJITTER := HELLO_INTERVAL/4
o hp_maxjitter：= hello_interval/4
o HT_MAXJITTER := HP_MAXJITTER
o ht_maxjitter：= hp_maxjitter
o C := 1/1024 second
o C：= 1/1024秒
Other protocols, such as MANET routing protocols, that use neighborhood discovery, may need to interact with this protocol. This protocol is designed to permit such interactions, in particular:
近隣発見を使用するMANETルーティングプロトコルなどの他のプロトコルは、このプロトコルと対話する必要がある場合があります。このプロトコルは、特に次のような相互作用を可能にするように設計されています。
o Through accessing, and possibly extending, the information in the Local Information Base (Section 6), the Interface Information Base (Section 7), and the Neighbor Information Base (Section 8). These Information Bases record the interface configuration of the router, as well as the local connectivity, up to two hops away. All updates to the elements specified in this document are subject to the constraints specified in Appendix B.
o ローカル情報ベース（セクション6）、インターフェイス情報ベース（セクション7）、および隣接情報ベース（セクション8）の情報にアクセスし、場合によっては拡張することにより。これらの情報ベースでは、ルーターのインターフェイス構成とローカル接続を記録し、最大2ホップ離れています。このドキュメントで指定された要素のすべての更新は、付録Bで指定された制約の対象となります。
o Through accessing an outgoing HELLO message prior to it being transmitted over any MANET interface, and to add information (e.g., TLVs) as specified in [RFC5444]. This may, for example, be to allow a security protocol, as suggested in Section 17, to add a TLV containing a cryptographic signature to the message, or be to allow inserting relay selection information into a HELLO message by way of adding a TLV to an outgoing HELLO message prior to it being transmitted.
o [RFC5444]で指定されているように、任意のMANETインターフェイスを介して送信される前に、発信ハローメッセージにアクセスし、情報（TLVなど）を追加します。たとえば、セクション17で提案されているように、セキュリティプロトコルがメッセージに暗号化署名を含むTLVを追加するか、TLVを追加することによりリレー選択情報をハローメッセージに挿入できるようにすることができます。送信される前の発信ハローメッセージ。
o Through accessing an incoming HELLO message, and potentially discarding it prior to processing by this protocol. This may, for example, allow a security protocol as suggested in Section 17 to perform verification of HELLO message signatures and prevent processing of unverifiable HELLO messages by this protocol.
o 着信ハローメッセージにアクセスし、このプロトコルで処理する前に潜在的に破棄する可能性があります。これにより、たとえば、セクション17で提案されているセキュリティプロトコルがHelloメッセージ署名の検証を実行し、このプロトコルによる検証不可能なHelloメッセージの処理を防ぐことができます。
o Through accessing an incoming HELLO message after it has been completely processed by this protocol. This may, in particular, allow a protocol that has added information, such as relay selection information by way of inclusion of appropriate TLVs, access to such information after appropriate updates have been recorded in the Information Bases in this protocol.
o このプロトコルによって完全に処理された後、着信ハローメッセージにアクセスすることにより。これにより、特に、適切なTLVを含めることによるリレー選択情報などの情報が追加されたプロトコルが、このプロトコルの情報ベースに適切な更新が記録された後、そのような情報へのアクセスが追加されます。
o Through requesting that a HELLO message be generated at a specific time. In that case, HELLO message generation MUST still respect the constraints in Appendix B.
o 特定の時間にハローメッセージを生成するように要求することにより。その場合、ハローメッセージの生成は、付録Bの制約を引き続き尊重する必要があります。
Address objects in HELLO messages are processed according to their associated Address Block TLVs. All such address objects are to be processed according to this specification are associated with Address Block TLVs with Type of LOCAL_IF, OTHER_NEIGHB, or LINK_STATUS (and type extension zero). Address objects not associated with an Address Block TLV of any of these Types are therefore not processed by the protocol described in this specification.
ハローメッセージのアドレスオブジェクトは、関連するアドレスブロックTLVに従って処理されます。このようなアドレスオブジェクトはすべて、この仕様に従って処理され、local_if、other_neighb、またはlink_status（およびタイプ拡張ゼロ）のタイプのアドレスブロックTLVに関連付けられます。したがって、これらのタイプのいずれかのアドレスブロックTLVに関連付けられていないアドレスオブジェクトは、この仕様で説明されているプロトコルによって処理されません。
A protocol, such as a MANET routing protocol, interacting with this protocol may need to add information to HELLO messages. This may be in the form of associating TLVs (of Type other than LOCAL_IF, OTHER_NEIGHB, or LINK_STATUS) to address objects already included by this specification.
このプロトコルと対話するMANETルーティングプロトコルなどのプロトコルは、Helloメッセージに情報を追加する必要がある場合があります。これは、この仕様に既に含まれているオブジェクトに対処するために、TLVを関連付けて（local_if、other_neighb、またはlink_status以外のタイプの）関連の形式である可能性があります。
A protocol, such as a MANET routing protocol, interacting with this protocol may also add information to HELLO messages by inserting address objects not already included by this specification. Such address objects are in the following called "inserted addresses". These inserted addresses may added to Address Blocks already present by virtue of the HELLO message generation in this specification, or may appear in new Address Blocks. In both cases, the following MUST be observed:
このプロトコルと対話するMANETルーティングプロトコルなどのプロトコルは、この仕様にまだ含まれていないアドレスオブジェクトを挿入することにより、Helloメッセージに情報を追加する場合もあります。このようなアドレスオブジェクトは、「挿入アドレス」と呼ばれる以下にあります。これらの挿入されたアドレスは、この仕様にHello Message生成のおかげで既に存在するアドレスブロックに追加される可能性があります。または、新しいアドレスブロックに表示される場合があります。どちらの場合も、以下を観察する必要があります。
o An inserted address MUST NOT be associated with an Address Block TLV of Type LOCAL_IF, OTHER_NEIGHB, or LINK_STATUS. Consequently, the processing in this specification will ignore such address objects.
o 挿入されたアドレスは、型local_if、other_neighb、またはlink_statusのタイプのアドレスブロックTLVに関連付けてはなりません。したがって、この仕様の処理は、そのようなアドレスオブジェクトを無視します。
o Each inserted address MUST be associated with an Address Block TLV, to be defined by the specification of the protocol inserting the address object. In this way, all addresses present in a HELLO message are associated with an Address Block TLV defining their semantics.
o 挿入された各アドレスは、アドレスオブジェクトを挿入するプロトコルの仕様によって定義するために、アドレスブロックTLVに関連付けられている必要があります。このように、Helloメッセージに存在するすべてのアドレスは、セマンティクスを定義するアドレスブロックTLVに関連付けられています。
Informally speaking, Address Block TLVs define the semantics of address objects in an Address Block. If an address object in an Address Block does not have any Address Block TLVs associated, that address object has no semantics. Consequently, all protocols using the protocol defined in this specification MUST respect the following:
非公式に言えば、アドレスブロックTLVSは、アドレスブロック内のアドレスオブジェクトのセマンティクスを定義します。アドレスブロック内のアドレスオブジェクトにアドレスブロックTLVが関連付けられていない場合、そのアドレスオブジェクトにはセマンティクスがありません。したがって、この仕様で定義されているプロトコルを使用したすべてのプロトコルは、以下を尊重する必要があります。
o An address object in an Address Block, which is not associated with any Address Block TLV, MUST be silently ignored; the mere presence of an address object without an associated Address Block TLV in a HELLO message MUST NOT cause any processing.
o アドレスブロックに関連付けられていないアドレスブロック内のアドレスオブジェクトは、静かに無視する必要があります。ハローメッセージに関連するアドレスブロックTLVを持たないアドレスオブジェクトの単なる存在は、処理を引き起こしてはなりません。
A protocol interacting with this protocol MAY also add an originator address to HELLO messages, as specified in [RFC5444]. Such an originator address MUST be unique to the originating router, it MAY be a local interface address of the router. It SHOULD be used consistently, but SHOULD NOT be constrained in any other way.
このプロトコルと相互作用するプロトコルは、[RFC5444]で指定されているように、Helloメッセージにオリジネーターアドレスを追加する場合があります。このようなオリジネーターのアドレスは、原産地のルーターに固有のものでなければなりません。ルーターのローカルインターフェイスアドレスである可能性があります。一貫して使用する必要がありますが、他の方法で制約されるべきではありません。
Strict adherence to these points will enable unambiguous coexistence of future "extensions" to HELLO messages.
これらのポイントを厳密に順守することで、将来の「拡張」をHelloメッセージに明確に共存することができます。
In some cases, a protocol interacting with the protocol defined in this specification, may need to recognize which HELLO messages to process and which HELLO messages to discard. It is the responsibility of that protocol to ensure that such messages are suitably identifiable, e.g., through inclusion of a Message TLV or through recognizing an administrative configuration (such as address ranges). Note that such a protocol interacting with this protocol MAY specify such interaction by recognizing an additional reason for discarding a message. As suggested in Section 17 this might, for example, be a security protocol discarding a message that does not carry a Message TLV containing a cryptographic signature.
場合によっては、この仕様で定義されているプロトコルと相互作用するプロトコルは、どのハローメッセージを処理するか、どのハローメッセージを破棄するかを認識する必要がある場合があります。そのようなメッセージが適切に識別可能であることを保証することは、そのプロトコルの責任です。たとえば、メッセージTLVを含めるか、管理構成を認識することで（アドレス範囲など）。このプロトコルと相互作用するこのようなプロトコルは、メッセージを破棄する追加の理由を認識することにより、そのような相互作用を指定する可能性があることに注意してください。セクション17で示唆されているように、これは、たとえば、暗号化署名を含むメッセージを伝えないメッセージを破棄するセキュリティプロトコルである可能性があります。
The objective of this protocol is to allow each router in the network to acquire information describing its 1-hop neighborhood and symmetric 2-hop neighborhood. This is acquired through HELLO message exchange between neighboring routers. This information is made available through the Interface Information Bases and Neighbor Information Base, describing the router's 1-hop neighborhood and symmetric 2-hop neighborhood.
このプロトコルの目的は、ネットワーク内の各ルーターが1ホップ近隣と対称の2ホップ近隣を説明する情報を取得できるようにすることです。これは、隣接するルーター間のハローメッセージ交換を通じて取得されます。この情報は、インターフェイス情報ベースとネイバー情報ベースを通じて利用可能になり、ルーターの1ホップ近隣と対称2ホップ近隣を説明しています。
Under normal circumstances, the information recorded in these Information Bases is correct, i.e., corresponds to the actual network topology, apart from any changes that have not (yet) been tracked by the HELLO message exchanges.
通常の状況では、これらの情報ベースに記録された情報は正しいです。つまり、Helloメッセージ交換によって（まだ）追跡されていない変更とは別に、実際のネットワークトポロジに対応しています。
If a router for some reason, whether malice or malfunction, transmits invalid HELLO messages, incorrect information may be recorded in other routers' Information Bases. This protocol specification does, however, prevent inconsistent information from being included in the Information Bases through the specified processing, which maintains the constraints in Appendix B. The exact consequence of information inexactness depends on the use of these Information Bases, and SHOULD therefore be reflected in the specification of protocols that use information provided by this neighborhood discovery protocol.
何らかの理由でルーターが悪意または誤動作であろうと、無効なハローメッセージを送信する場合、他のルーターの情報ベースに誤った情報が記録される場合があります。ただし、このプロトコル仕様は、付録Bの制約を維持する指定された処理を通じて、一貫性のない情報が情報ベースに含まれることを防ぎます。この近隣発見プロトコルによって提供される情報を使用するプロトコルの仕様。
This section, therefore, firstly outlines the ways in which correctly formed, but still invalid, HELLO messages may appear, in Section 17.1.
したがって、このセクションでは、最初に、セクション17.1に、正しく形成されたが無効な方法の概要を説明します。
Injection of invalid HELLO messages into a network may be prevented in a number of ways. If, for example, a network is deployed in a site to which access is strictly regulated, so that physical access and proximity to the network is prevented, then further security mechanisms to protect against malicious routers injecting invalid HELLO messages may not be required. Similarly, if the link layer over which the network is formed provides appropriate confidentiality, authentication, and integrity, then this may, for a given deployment, suffice to appropriately protect against disclosure of information to an eavesdropper, and against a malicious router injecting invalid HELLO messages. In the latter case, the link layer would discard frames that fail the link-layer checks, without attempting to deliver such frames to IP. Finally, certain usage may be of a nature where disruption of service is of no consequence, or at least not of sufficient consequence to warrant deployment of additional security mechanisms.
ネットワークへの無効なHelloメッセージの注入は、さまざまな方法で防止される場合があります。たとえば、アクセスが厳密に規制されているサイトにネットワークが展開されているため、ネットワークへの物理的アクセスと近接性が防止される場合、無効なハローメッセージを注入する悪意のあるルーターから保護するためのさらなるセキュリティメカニズムは必要ありません。同様に、ネットワークが形成されたリンクレイヤーが適切な機密性、認証、および整合性を提供する場合、これは特定の展開に対して、盗聴者への情報の開示と悪意のあるルーターに対して適切に保護するのに十分な場合があります。メッセージ。後者の場合、リンクレイヤーは、そのようなフレームをIPに配信しようとせずに、リンク層チェックに失敗するフレームを破棄します。最後に、特定の使用法は、サービスの混乱が結果にならない性質であるか、少なくとも追加のセキュリティメカニズムの展開を保証するために十分な結果ではない場合があります。
A further point to stress, and which follows from the discussions above is, that it will not be the case that "one size security fits all". Different deployments may have different requirements. For example, in a deployment of a low-value sensor network, authentication using a simple message authentication code and shared symmetric keys may suffice, while anything beyond that may require too many computational resources to be viable. Conversely, in, for example, a community network, verifying not only that the originator of a HELLO message "has the right key" but also the precise identity of the originator may be required to be proved, and computational resources may be available to make such a requirement feasible.
上記の議論から続くストレスへのさらなるポイントは、「1つのサイズのセキュリティがすべてに適合する」という場合ではないということです。展開が異なると、要件が異なる場合があります。たとえば、低価値センサーネットワークの展開では、シンプルなメッセージ認証コードと共有対称キーを使用した認証で十分である可能性がありますが、それ以上のものはあまりにも多くの計算リソースを必要とする可能性があります。逆に、たとえば、コミュニティネットワークでは、ハローメッセージのオリジネーターが「正しいキーを持っている」だけでなく、オリジネーターの正確なアイデンティティを証明する必要があることを確認し、計算リソースが利用可能である可能性があります。このような要件は実行可能です。
Section 17.2, therefore, does not specify a single "one-size-fits-all" mechanism, but rather details how the security suggestions in [RFC5444] are considered for applicability within the context of this protocol, and with the purpose of aiding deployment-specific security mechanisms to be developed.
したがって、セクション17.2は、単一の「ワンサイズフィット」メカニズムを指定するのではなく、[RFC5444]のセキュリティ提案が、このプロトコルのコンテキスト内での適用性のために、および展開を支援する目的でどのように考慮されているかを詳述しています。 - 開発される固有のセキュリティメカニズム。
A correctly formed, but still invalid, HELLO message may take any of the following forms. Note that a present or absent address object in an Address Block, does not by itself cause a problem. It is the presence, absence, or incorrectness of associated LOCAL_IF, LINK_STATUS, and OTHER_NEIGHB Address Block TLVs that causes problems.
正しく形成されているが、まだ無効であるHelloメッセージは、次のフォームのいずれかをとることがあります。アドレスブロック内の現在または存在しないアドレスオブジェクトは、それ自体が問題を引き起こしていないことに注意してください。関連するLocal_if、link_status、およびother_neighbアドレスブロックTLVの存在、不在、または不正確さが問題を引き起こします。
A router may provide false information about its own identity:
ルーターは、独自のアイデンティティに関する誤った情報を提供する場合があります。
o The HELLO message may contain address objects with an associated LOCAL_IF Address Block TLV that do not correspond to addresses of interfaces of the router transmitting the HELLO message.
o Helloメッセージには、Helloメッセージを送信するルーターのインターフェイスのアドレスに対応しない関連Rocal_ifアドレスブロックTLVを持つアドレスオブジェクトが含まれている場合があります。
o The HELLO message may omit network addresses, or their associated LOCAL_IF Address Block TLV, of interfaces of the router transmitting the HELLO message (other than the allowed omission of the only local interface network address of the MANET interface over which the HELLO message is transmitted, if that is the case).
o Helloメッセージは、Helloメッセージを送信するルーターのインターフェイスのネットワークアドレス、または関連するLocal_ifアドレスブロックTLVを省略する場合があります（Helloメッセージが送信されるMANETインターフェイスの唯一のローカルインターフェイスネットワークアドレスの許可された省略を除いて、その場合）。
o The HELLO message may incorrectly specify the LOCAL_IF Address Block TLV Value associated with one or more local interface network addresses, indicating incorrectly whether they are associated with the MANET interface over which the HELLO message is transmitted.
o Helloメッセージは、1つ以上のローカルインターフェイスネットワークアドレスに関連付けられたLocal_ifアドレスブロックTLV値を誤って指定する場合があり、Helloメッセージが送信されるMANETインターフェイスに関連付けられているかどうかを誤って示します。
A router may provide false information about the identity of other routers:
ルーターは、他のルーターのアイデンティティに関する誤った情報を提供する場合があります。
o A present LINK_STATUS Address Block TLV may, incorrectly, identify a network address as being of a MANET interface that is or was heard on the MANET interface over which the HELLO message is transmitted.
o 現在のlink_statusアドレスブロックTLVは、誤って、ネットワークアドレスを、Helloメッセージが送信されるMANETインターフェイスで聞かれたMANETインターフェイスであると識別します。
o A consistently absent LINK_STATUS Address Block TLV may, incorrectly, fail to identify a network address as being of a MANET interface that is or was heard on the MANET interface over which the HELLO message is transmitted.
o 一貫して存在しないLINK_STATUSアドレスブロックTLV TLVは、誤って、ネットワークアドレスをMALLメッセージが送信されるMANETインターフェイスで聞かれたMANETインターフェイスであると識別できません。
o A present OTHER_NEIGHB Address Block TLV may, incorrectly, identify a network address as being of a router that is or was in the sending router's symmetric 1-hop neighborhood.
o 現在のother_neighbアドレスブロックTLVは、誤って、ネットワークアドレスを、送信ルーターの対称1ホップ近隣にあるルーターであるか、またはあったルーターであると識別します。
o A consistently absent OTHER_NEIGHB Address Block TLV may, incorrectly, fail to identify a network address as being of a router that is or was in the sending router's symmetric 1-hop neighborhood.
o 一貫して存在しないother_neighbアドレスブロックTLVは、誤って、ネットワークアドレスを送信ルーターの対称1ホップ近隣にあるルーターであるか、またはあったルーターであると識別できません。
o The Value of a LINK_STATUS Address Block TLV may incorrectly indicate the status (LOST, SYMMETRIC or HEARD) of the link from a 1-hop neighbor.
o Link_StatusアドレスブロックTLVの値は、1ホップの隣人からのリンクのステータス（失われた、対称的または聞こえる）を誤って示す場合があります。
o The Value of an OTHER_NEIGHB Address Block TLV may incorrectly indicate the status (LOST or SYMMETRIC) of a symmetric 1-hop neighbor.
o other_neighbアドレスブロックTLVの値は、対称1ホップ隣接のステータス（失われたまたは対称）を誤って示す場合があります。
The security suggestions in [RFC5444] regarding inclusion of a cryptographic signature in a Message TLV or a Packet TLV can be applied to this protocol. Failure to verify either form of cryptographic signature should cause a HELLO message to be rejected without being processed.
メッセージTLVまたはパケットTLVに暗号化署名を含めることに関する[RFC5444]のセキュリティ提案は、このプロトコルに適用できます。いずれかの形式の暗号化署名を確認できないと、処理されずにハローメッセージが拒否されるようにする必要があります。
The following simplification of the suggestions for end-to-end authentication for integrity in [RFC5444] may be applied to HELLO messages:
[RFC5444]の整合性のためのエンドツーエンド認証のための提案の以下の簡素化は、ハローメッセージに適用できます。
o As the Message Header fields <msg-hop-count> and <msg-hop-limit> are either omitted or will always have the values 0 and 1, respectively, an end to end cryptographic signature can be calculated based on the entire HELLO message, including its unmodified Message Header.
o メッセージヘッダーフィールド<msg-hop-count>および<msg-hop-limit>が省略されるか、それぞれ値0と1を常に持つため、エンドツーエンドの暗号署名は、Helloメッセージ全体に基づいて計算できます。、変更されていないメッセージヘッダーを含む。
The security mechanisms suggested in [RFC5444] with respect to confidentiality can be directly applied to this protocol.
機密性に関して[RFC5444]で提案されているセキュリティメカニズムは、このプロトコルに直接適用できます。
This specification defines one Message Type, which has been allocated from the "Message Types" registry of [RFC5444], and three Address Block TLV Types, which have been allocated from the "Address Block TLV Types" registry of [RFC5444].
この仕様では、[RFC5444]の「メッセージタイプ」レジストリから割り当てられた1つのメッセージタイプと、[RFC5444]の「アドレスブロックTLVタイプ」レジストリから割り当てられた3つのアドレスブロックTLVタイプを定義します。
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]で指定されているのと同じ一般的な推奨事項を考慮に入れる必要があります。
This specification defines one Message Type, which has been allocated from the 0-223 range of the "Message Types" namespace defined in [RFC5444], as specified in Table 3.
この仕様では、表3に指定されているように、[RFC5444]で定義された「メッセージタイプ」名の0-223範囲から割り当てられた1つのメッセージタイプを定義します。
+------+-------------------------+
| Type | Description |
+------+-------------------------+
| 0 | HELLO : Local signaling |
+------+-------------------------+
Table 3: Message Type Assignment
表3：メッセージタイプの割り当て
IANA has created a registry for Message-Type-specific Message TLVs for HELLO messages, in accordance with Section 6.2.1 of [RFC5444], and with initial assignments and allocation policies as specified in Table 4.
IANAは、[RFC5444]のセクション6.2.1、および表4に指定された初期割り当ておよび割り当てポリシーに従って、Helloメッセージ用のメッセージタイプ固有のメッセージTLVのレジストリを作成しました。
+---------+-------------+-------------------+
| Type | Description | Allocation Policy |
+---------+-------------+-------------------+
| 128-223 | Unassigned | Expert Review |
+---------+-------------+-------------------+
Table 4: HELLO Message-Type-specific Message TLV Types
表4：Hello Message-Type固有のメッセージTLVタイプ
IANA has created a registry for Message-Type-specific Address Block TLVs for HELLO messages, in accordance with Section 6.2.1 of [RFC5444], and with initial assignments and allocation policies as specified in Table 5.
IANAは、[RFC5444]のセクション6.2.1、および表5に指定された初期割り当ておよび割り当てポリシーに従って、Helloメッセージのメッセージタイプ固有のアドレスブロックTLVのレジストリを作成しました。
+---------+-------------+-------------------+
| Type | Description | Allocation Policy |
+---------+-------------+-------------------+
| 128-223 | Unassigned | Expert Review |
+---------+-------------+-------------------+
Table 5: HELLO Message-Type-specific Address Block TLV Types
表5：Hello Message-Type固有のアドレスブロックTLVタイプ
This specification defines three Address Block TLV Types, which have been allocated from the "Address Block TLV Types" namespace defined in [RFC5444]. IANA has made allocations in the 0-127 range for these types. Three new type extension registries have been created, with assignments as specified in Tables 6, 7, and 8. Specifications of these Address Block TLVs are in Section 10.1.1, with Value Constants defined in Section 18.5.
この仕様では、[RFC5444]で定義されている「アドレスブロックTLVタイプ」名から割り当てられた3つのアドレスブロックTLVタイプを定義します。IANAは、これらのタイプの0-127範囲で割り当てを行いました。3つの新しいタイプ拡張レジストリが作成され、表6、7、および8で指定されている割り当てがあります。これらのアドレスブロックTLVの仕様はセクション10.1.1にあり、値定数はセクション18.5で定義されています。
+----------+------+-----------+------------------------+------------+
| Name | Type | Type | Description | Allocation |
| | | extension | | policy |
+----------+------+-----------+------------------------+------------+
| LOCAL_IF | 2 | 0 | Specifies that the | |
| | | | network address is | |
| | | | associated with this | |
| | | | local interface of the | |
| | | | sending router | |
| | | | (THIS_IF = 0) or | |
| | | | another local | |
| | | | interface of the | |
| | | | sending router | |
| | | | (OTHER_IF = 1) | |
| LOCAL_IF | 2 | 1-255 | Unassigned | Expert |
| | | | | Review |
+----------+------+-----------+------------------------+------------+
Table 6: Address Block TLV Type Assignment: LOCAL_IF
表6：アドレスブロックTLVタイプの割り当て：local_if
+-------------+------+-----------+---------------------+------------+
| Name | Type | Type | Description | Allocation |
| | | extension | | policy |
+-------------+------+-----------+---------------------+------------+
| LINK_STATUS | 3 | 0 | Specifies the | |
| | | | status of the link | |
| | | | from the indicated | |
| | | | network address | |
| | | | (LOST = 0, | |
| | | | SYMMETRIC = 1, or | |
| | | | HEARD = 2) | |
| LINK_STATUS | 3 | 1-255 | Unassigned | Expert |
| | | | | Review |
+-------------+------+-----------+---------------------+------------+
Table 7: Address Block TLV Type Assignment: LINK_STATUS
表7：アドレスブロックTLVタイプの割り当て：link_status
+--------------+------+-----------+--------------------+------------+
| Name | Type | Type | Description | Allocation |
| | | extension | | policy |
+--------------+------+-----------+--------------------+------------+
| OTHER_NEIGHB | 4 | 0 | Specifies the | |
| | | | status of the | |
| | | | relationship with | |
| | | | the router that | |
| | | | uses the indicated | |
| | | | network address on | |
| | | | one or more | |
| | | | interfaces (LOST = | |
| | | | 0, or SYMMETRIC = | |
| | | | 1) | |
| OTHER_NEIGHB | 4 | 1-255 | Unassigned | Expert |
| | | | | Review |
+--------------+------+-----------+--------------------+------------+
Table 8: Address Block TLV Type Assignment: OTHER_NEIGHB
表8：アドレスブロックTLVタイプの割り当て：other_neighb
Note: This information is recorded here for clarity and for use elsewhere in this specification. The information required by IANA is included in the descriptions of the Address Block TLVs allocated in Section 18.4.
注：この情報は、明確にし、この仕様の他の場所で使用するためにここに記録されています。IANAが必要とする情報は、セクション18.4に割り当てられたアドレスブロックTLVの説明に含まれています。
The Values that the LOCAL_IF Address Block TLV can use are the following:
Local_ifアドレスブロックTLVが使用できる値は、次のとおりです。
o THIS_IF := 0
o this_if：= 0
o OTHER_IF := 1
o other_if：= 1
The Values that the LINK_STATUS Address Block TLV can use are the following:
Link_StatusアドレスブロックTLVが使用できる値は次のとおりです。
o LOST := 0
o 紛失：= 0
o SYMMETRIC := 1
o 対称：= 1
o HEARD := 2
o 聞いた：= 2
The Values that the OTHER_NEIGHB Address Block TLV can use are the following:
other_neighbアドレスブロックTLVが使用できる値は次のとおりです。
o LOST := 0 o SYMMETRIC := 1
o 紛失：= 0 o対称：= 1
This specification is the result of the joint efforts of the following contributors from the OLSRv2 Design Team, listed alphabetically:
この仕様は、OLSRV2設計チームの次の貢献者の共同努力の結果であり、アルファベット順にリストされています。
o Brian Adamson, NRL, USA, <adamson@itd.nrl.navy.mil>
o ブライアン・アダムソン、NRL、米国、<adamson@itd.nrl.navy.mil>
o Cedric Adjih, INRIA, France, <Cedric.Adjih@inria.fr>
o セドリック・アジェイ、フランス、インリア、<cedric.adjih@inria.fr>
o Thomas Heide Clausen, LIX, France, <T.Clausen@computer.org>
o Thomas Heide Clausen、Lix、France、<T.Clausen@computer.org>
o Justin Dean, NRL, USA, <jdean@itd.nrl.navy.mil>
o ジャスティンディーン、NRL、米国、<jdean@itd.nrl.navy.mil>
o Christopher Dearlove, BAE Systems ATC, UK, <chris.dearlove@baesystems.com>
o Christopher Dearlove、Bae Systems ATC、英国、<chris.dearlove@baesystems.com>
o Philippe Jacquet, INRIA, France, <Philippe.Jacquet@inria.fr>
o フィリップ・ジャケット、フランス、インリア、<フィリップ。Jacquet@inria.fr>
The authors would like to acknowledge the team behind OLSRv1, specified in RFC3626 for their contributions.
著者は、RFC3626で指定されたOLSRV1の背後にあるチームの貢献を承認したいと考えています。
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): Alan Cullen (BAE Systems), Ulrich Herberg (LIX), Satoh Hiroki (Hitachi) Joe Macker (NRL), Charles E. Perkins (WiChorus), Laurent Viennot (INRIA), and the entire IETF MANET working group.
著者は、激しい技術的な議論、仕様とそのコンポーネント（アルファベット順にリストされている）に関する激しい技術的議論、早期レビュー、コメントについて、次の人々に感謝したいと思います：アラン・カレン（BAEシステム）、ウルリッヒ・ヘルバーグ（LIX）、佐藤hiroki（hitachi）ジョー・マッカー（NRL）、Charles E. Perkins（Wichorus）、Laurent Viennot（INRIA）、およびIETF MANETワーキンググループ全体。
[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、「モバイルアドホックネットワーク（MANETS）におけるジッター考慮事項」、RFC 5148、2008年2月。
[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、「一般化されたモバイルアドホックネットワーク（MANET）パケット/メッセージ形式」、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、「モバイルアドホックネットワーク（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月。
[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月。
[RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing Protocol (OLSR)", RFC 3626, October 2003.
[RFC3626] Clausen、T。およびP. Jacquet、「最適化されたリンク状態ルーティングプロトコル（OLSR）」、RFC 3626、2003年10月。
[RFC5449] Baccelli, E., Jacquet, P., Nguyen, D., and T. Clausen, "OSPF Multipoint Relay (MPR) Extension for Ad Hoc Networks", RFC 5449, February 2009.
[RFC5449] Baccelli、E.、Jacquet、P.、Nguyen、D。、およびT. Clausen、「OSPF Multipoint Relay（MPR）アドホックネットワークの拡張」、RFC 5449、2009年2月。
The algorithm for generating HELLO messages in Section 11 specifies which 1-hop neighbor network addresses may be included in the Address Blocks, and with which associated Address Block TLVs. These Address Block TLVs may have Type = LINK_STATUS or Type = OTHER_NEIGHB, or both. Address Block TLVs with Type = LINK_STATUS may have three possible Values (Value = HEARD, Value = SYMMETRIC, or Value = LOST), and Address Block TLVs of TYPE = OTHER_NEIGHB may have two possible Values (Value = SYMMETRIC or Value = LOST). When both Address Block TLVs are associated with the same network address only certain combinations of these Address Block TLV Values are necessary, and are the only combinations generated by the algorithm in Section 11. These combinations are indicated in Table 9.
セクション11でHelloメッセージを生成するためのアルゴリズムは、1ホップの近隣ネットワークアドレスがアドレスブロックに含まれる可能性があり、関連するアドレスブロックTLVを指定します。これらのアドレスブロックTLVには、type = link_statusまたはtype = other_neighb、またはその両方がある場合があります。型= link_statusのアドレスブロックTLVには3つの可能な値（値= heard、value = symmetric、またはlost = lost）があり、type = other_neighbのアドレスブロックtlvには2つの可能な値（value = symmetricまたはvalue = lost）があります。両方のアドレスブロックTLVが同じネットワークアドレスに関連付けられている場合、これらのアドレスブロックTLV値の特定の組み合わせのみが必要であり、セクション11のアルゴリズムによって生成される唯一の組み合わせです。これらの組み合わせは表9に示されています。
Cells labeled with "Yes" indicate the possible combinations that are generated by the algorithm in Section 11. Cells labeled with "No" indicate combinations not generated by the algorithm in Section 11 but that are correctly parsed and interpreted by the algorithm in Section 12. The cell labeled with "No*" is actually inconsistent, it is handled by ignoring the Address Block TLV with Type = OTHER_NEIGHB, but SHOULD NOT be used.
「はい」で標識されたセルは、セクション11のアルゴリズムによって生成される可能性のある組み合わせを示しています。「NO」とラベル付けされたセルは、セクション11のアルゴリズムによって生成されない組み合わせを示しますが、セクション12のアルゴリズムによって正しく解析され、解釈されます。「no*」でラベル付けされたセルは実際には一貫性がなく、型= other_neighbを使用してアドレスブロックTLVを無視することで処理されますが、使用しないでください。
+----------------+----------------+----------------+----------------+
| | Type = | Type = | Type = |
| | OTHER_NEIGHB | OTHER_NEIGHB, | OTHER_NEIGHB, |
| | (absent) | Value = | Value = LOST |
| | | SYMMETRIC | |
+----------------+----------------+----------------+----------------+
| Type = | No | Yes | Yes |
| LINK_STATUS | | | |
| (absent) | | | |
| Type = | Yes | Yes | Yes |
| LINK_STATUS, | | | |
| Value = HEARD | | | |
| Type = | Yes | No | No* |
| LINK_STATUS, | | | |
| Value = | | | |
| SYMMETRIC | | | |
| Type = | Yes | Yes | No |
| LINK_STATUS, | | | |
| Value = LOST | | | |
+----------------+----------------+----------------+----------------+
Table 9: LINK_STATUS and OTHER_NEIGHB TLV Combinations
表9：link_statusおよびその他の_neighbtlvの組み合わせ
Any process that updates the Local Information Base or the Neighbor Information Base MUST ensure that all constraints specified in this appendix are maintained.
ローカル情報ベースまたは近隣情報ベースを更新するプロセスは、この付録で指定されたすべての制約が維持されることを確認する必要があります。
In each Local Interface Tuple:
各ローカルインターフェイスタプル：
o I_local_iface_addr_list MUST NOT be empty.
o i_local_iface_addr_listは空でなければなりません。
o I_local_iface_addr_list MUST NOT contain any duplicated network addresses.
o i_local_iface_addr_list複製されたネットワークアドレスを含めてはなりません。
o If I_manet = true, then I_local_iface_addr_list MUST NOT contain any network address that overlaps any network address in the I_local_iface_addr_list of any other Local Interface Tuple with I_manet = true, unless it is known that the corresponding MANET interfaces will always communicate with separate sets of MANET interfaces on other routers.
o i_manet = trueの場合、i_local_iface_addr_listは、対応するマネットインターフェイスが常にManetインターフェースの個別のセットと通信することがわかっていない場合を除き、他のローカルインターフェイスタプルのi_local_iface_addr_listのネットワークアドレスをi_manet = trueと重複するネットワークアドレスを含める必要があります。他のルーターで。
In each Removed Interface Address Tuple:
削除された各インターフェイスアドレスタプルで：
o IR_local_iface_addr MUST NOT contain any network address that is in the I_local_iface_addr_list of any Local Interface Tuple.
o IR_LOCAL_IFACE_ADDRは、ローカルインターフェイスタプルのi_local_iface_addr_listにあるネットワークアドレスを含めてはなりません。
o IR_local_iface_addr MUST NOT equal the IR_local_iface_addr of any other Removed Interface Address Tuple.
o IR_LOCAL_IFACE_ADDRは、他の削除されたインターフェイスアドレスタプルのIR_LOCAL_IFACE_ADDRに等しくないはずです。
In each Link Tuple:
各リンクのタプル：
o L_neighbor_iface_addr_list MUST NOT be empty.
o l_neighbor_iface_addr_listは空でなければなりません。
o L_neighbor_iface_addr_list MUST NOT contain any network address that overlaps any network address in the I_local_iface_addr_list of any Local Interface Tuple or the IR_local_iface_addr of any Removed Interface Address Tuple.
o l_neighbor_iface_addr_listは、ローカルインターフェイスTupleのi_local_iface_addr_listまたは削除されたインターフェイスアドレスTupleのIR_LOCAL_IFACE_ADDRを重複させるネットワークアドレスを含める必要があります。
o L_neighbor_iface_addr_list MUST NOT contain any duplicated network addresses.
o l_neighbor_iface_addr_list複製されたネットワークアドレスを含めてはなりません。
o L_neighbor_iface_addr_list MUST NOT contain any network address which is in the L_neighbor_iface_addr_list of any other Link Tuple in the same Link Set.
o l_neighbor_iface_addr_list同じリンクセットの他のリンクタプルのl_neighbor_iface_addr_listにあるネットワークアドレスを含める必要があります。
o If L_HEARD_time has not expired, then there MUST be a Neighbor Tuple whose N_neighbor_addr_list contains L_neighbor_iface_addr_list.
o L_HEARD_TIMEが期限切れになっていない場合、N_NEIGHBOR_ADDR_LISTにL_NEIGHBOR_IFACE_ADDR_LISTが含まれている隣人のタプルがなければなりません。
o L_HEARD_time MUST NOT be greater than L_time.
o L_HEARD_TIMEはL_TIMEよりも大きくてはなりません。
o L_SYM_time MUST NOT be greater than L_HEARD_time (unless both are expired).
o L_SYM_TIMEはL_HEARD_TIMEよりも大きくてはなりません（両方が期限切れにならない限り）。
o L_quality MUST NOT be less than 0 or greater than 1.
o L_Qualityは、0以下または1を超えてはなりません。
o If L_quality >= HYST_ACCEPT, then L_pending MUST be false.
o l_quality> = hyst_acceptの場合、l_pendingはfalseでなければなりません。
o If L_quality < HYST_REJECT, then L_status MUST be PENDING or LOST.
o l_quality <hyst_rejectの場合、l_statusは保留中または紛失する必要があります。
o L_pending MUST NOT be set to true if it is currently false.
o l_pendingが現在偽である場合は、trueに設定してはなりません。
In each Neighbor Tuple:
それぞれの隣人のタプル：
o N_neighbor_addr_list MUST NOT contain any network address that overlaps any network address in the I_local_iface_addr_list of any Local Interface Tuple or the IR_local_iface_addr of any Removed Interface Address Tuple.
o n_neighbor_addr_listは、ローカルインターフェイスtupleのi_local_iface_addr_listまたは削除されたインターフェイスアドレスタプルのir_local_iface_addrの任意のネットワークアドレスを重複させるネットワークアドレスを含めてはなりません。
o N_neighbor_addr_list MUST NOT contain any duplicated network addresses.
o n_neighbor_addr_listは、重複したネットワークアドレスを含めてはなりません。
o N_neighbor_addr_list MUST NOT contain any network address that is in the N_neighbor_addr_list of any other Neighbor Tuple.
o N_NEIGHBOR_ADDR_LISTは、他の隣接タプルのn_neighbor_addr_listにあるネットワークアドレスを含めてはなりません。
o If N_symmetric is = true, then there MUST be one or more Link Tuples with:
o n_symmetricが= trueの場合、次の1つ以上のリンクタプルが必要です。
o L_neighbor_iface_addr_list contained in N_neighbor_addr_list; AND
o l_neighbor_iface_addr_list n_neighbor_addr_list;と
o L_status = SYMMETRIC.
o l_status =対称。
o If N_symmetric is = false, then there MUST be one or more Link Tuples with:
o n_symmetricがfalseである場合、次の1つ以上のリンクタプルが必要です。
o L_neighbor_iface_addr_list contained in N_neighbor_addr_list.
o l_neighbor_iface_addr_list n_neighbor_addr_listに含まれる。
All such Link Tuples MUST NOT have L_status = SYMMETRIC. At least one such Link Tuple MUST have L_HEARD_time not expired.
そのようなリンクのタプルはすべて、l_status =対称であってはなりません。少なくとも1つのそのようなリンクタプルは、l_heard_timeが期限切れになっている必要があります。
In each Lost Neighbor Tuple:
失われた隣人のタプルで：
o NL_neighbor_addr MUST NOT overlap any network address in the I_local_iface_addr_list of any Local Interface Tuple or the IR_local_iface_addr of any Removed Interface Address Tuple.
o nl_neighbor_addrローカルインターフェイスタプルのi_local_iface_addr_listまたは削除されたインターフェイスアドレスタプルのir_local_iface_addrのネットワークアドレスをオーバーラップしてはなりません。
o NL_neighbor_addr MUST NOT equal the NL_neighbor_addr of any other Lost Neighbor Tuple.
o nl_neighbor_addrは、他の失われた隣人のタプルのnl_neighbor_addrと等しくてはなりません。
o NL_neighbor_addr MUST NOT be in the N_neighbor_addr_list of any Neighbor Tuple with N_symmetric = true.
o nl_neighbor_addrは、n_symmetric = trueを持つ隣のタプルのn_neighbor_addr_listに存在してはなりません。
In each 2-Hop Tuple:
各2ホップタプル：
o There MUST be a Link Tuple associated with the same MANET interface with:
o 次のようなMANETインターフェイスに関連付けられたリンクタプルが必要です。
o L_neighbor_iface_addr_list = N2_neighbor_iface_addr_list; AND
o l_neighbor_iface_addr_list = n2_neighbor_iface_addr_list;と
o L_status = SYMMETRIC.
o l_status =対称。
o N2_2hop_addr MUST NOT overlap any network address in the I_local_iface_addr_list of any Local Interface Tuple or the IR_local_iface_addr of any Removed Interface Address Tuple.
o N2_2HOP_ADDRは、ローカルインターフェイスTupleのi_local_iface_addr_listまたは削除されたインターフェイスアドレスタプルのIR_LOCAL_IFACE_ADDRのネットワークアドレスをオーバーラップしてはなりません。
o N2_2hop_addr MUST NOT be the N2_2hop_addr of any other 2-Hop Tuple in the same 2-Hop Set and with the same N2_neighbor_iface_addr_list.
o N2_2HOP_ADDRは、同じ2ホップセットと同じN2_NEIGHBOR_IFACE_ADDR_LISTで、他の2ホップタプルのN2_2HOP_ADDRである必要があります。
o N2_2hop_addr MUST NOT be in the N2_neighbor_iface_addr_list of the same 2-Hop Tuple.
o n2_2hop_addrは、同じ2ホップタプルのn2_neighbor_iface_addr_listに存在してはなりません。
HELLO messages are instances of [RFC5444] messages, and this protocol supports any combination of 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 HELLO messages look. This appendix illustrates two HELLO message with similar content, the exact values included are explained in the following text.
Helloメッセージは[RFC5444]メッセージのインスタンスであり、このプロトコルは、必要な情報を伝える[RFC5444]で有効になっているメッセージヘッダーオプションとアドレスエンコーディングの任意の組み合わせをサポートしています。結果として、すべてのハローメッセージがどのように見えるかを表す単一の方法はありません。この付録は、同様のコンテンツを持つ2つのHelloメッセージを示しています。含まれる正確な値は、次のテキストで説明されています。
The HELLO message's four bit Message Flags (MF) field has value 7 indicating that the message header contains 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 message is as transmitted, with a hop limit of 1 and a hop count of 0. The overall message length is 45 octets.
Hello Messageの4ビットメッセージフラグ（MF）フィールドには、メッセージヘッダーにホップ制限、ホップカウント、およびメッセージシーケンス番号フィールドが含まれていることを示します。その4ビットメッセージアドレスの長さ（MAL）フィールドには値3があり、メッセージのアドレスの長さは4オクターの長さを示しています。ここではIPv4アドレスです。メッセージは送信され、ホップ制限は1、ホップカウント0です。全体のメッセージの長さは45オクテットです。
The message contains a Message TLV Block with content length 8 octets containing two Message TLVs, of types VALIDITY_TIME and INTERVAL_TIME. Each uses a Message TLV with Flags octet (MTLVF) value 16, indicating that each has a Value, and each has a Value Length of 1 octet. The Values included are time codes (as defined in [RFC5497]) representing the parameters H_HOLD_TIME and HELLO_INTERVAL, respectively.
このメッセージには、2つのメッセージTLVを含むコンテンツ長さ8オクテットのメッセージTLVブロックが含まれています。それぞれがFlags Octet（MTLVF）値16を持つメッセージTLVを使用します。含まれる値は、それぞれパラメーターh_hold_timeとhello_intervalを表すタイムコード（[RFC5497]で定義されている）です。
The message has a single Address Block containing 5 addresses. The Address Block Flags octet (ABF) value 128 indicates an address Head but no address Tail, and no address prefixes. The Head Length of 3 octets indicates address Mid sections of one octet each (Mid 0 to Mid 4).
メッセージには、5つのアドレスを含む単一のアドレスブロックがあります。アドレスブロックフラグのオクテット（ABF）値128は、アドレスヘッドを示しますが、アドレステールはなく、アドレスのプレフィックスはありません。3オクテットの頭の長さは、それぞれ1オクテットのアドレス中央セクションを示します（0時から4時半から4時半まで）。
The following Address Block TLV Block (content length 14 octets) includes two Address Block TLVs. The first is a LOCAL_IF Address Block TLV with Flags octet (ATLVF) value 80, which indicates that a single address, with index 0 (i.e., the address Head:Mid 0) is the single local interface address of this router (the one octet Value THIS_IF indicates that this address is of this interface). The second is a LINK_STATUS Address Block TLV with Flags octet (ATLVF) value 52, which specifies the link status values of all reported neighbors in a single multivalue Address Block TLV that covers the addresses with indexes 1 to 4, inclusive. The Address Block TLV Value Length of 4 octets indicates one octet per Value per address. The last four addresses thus are of neighbors, each an with associated link status: the first and second HEARD, the third SYMMETRIC, and the fourth LOST.
次のアドレスブロックTLVブロック（コンテンツ長14オクテット）には、2つのアドレスブロックTLVが含まれています。1つ目はローカル_ifアドレスブロックTLVフラグoctet（atlvf）値80を備えたものです。これは、インデックス0（つまり、アドレスヘッド：Mid 0）の単一アドレスがこのルーターの単一のローカルインターフェイスアドレス（1つのオクテットの単一のローカルインターフェイスアドレスであることを示します。値this_ifは、このアドレスがこのインターフェイスのものであることを示します）。2番目は、Flags Octet（ATLVF）値52を備えたLink_StatusアドレスブロックTLVです。これは、インデックス1〜4のインデックスでアドレスをカバーする単一のマルチバリューアドレスブロックTLVで、報告されたすべての近隣のリンクステータス値を指定します。アドレスブロックTLV値4オクテットの長さは、アドレスごとに1オクターごとに1オクテットを示します。したがって、最後の4つのアドレスは隣人のもので、それぞれ関連するリンクステータスがあります。1回目と2番目の聞こえ、3番目の対称、4番目のアドレスが失われました。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HELLO | MF=7 | MAL=3 | Message Length = 45 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit = 1 | Hop Count = 0 | Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message TLV Block Length = 8 | VALIDITY_TIME | MTLVF = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value Len = 1 | Value (Time) | INTERVAL_TIME | MTLVF = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value Len = 1 | Value (Time) | Num Addrs = 5 | ABF = 128 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head Len = 3 | Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid 0 | Mid 1 | Mid 2 | Mid 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid 4 | Address TLV Block Length = 14 | LOCAL_IF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ATLVF = 80 | Index = 0 | Value Len = 1 | THIS_IF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LINK_STATUS | ATLV = 52 | Strt Indx = 1 | Stop Indx = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value Len = 4 | HEARD | HEARD | SYMMETRIC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LOST |
+-+-+-+-+-+-+-+-+
Note that this example is for illustrative purposes. The essential information can be conveyed, more efficiently (assuming that the local interface address will be supplied by IP, and that the INTERVAL_TIME TLV is not needed) by the 29 octets:
この例は、説明のためのものであることに注意してください。より効率的に、より効率的に伝えることができます（ローカルインターフェイスアドレスがIPによって提供され、interval_time TLVが必要ないと仮定します）。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HELLO |0 0 0 0 0 0 1 1|0 0 0 0 0 0 0 0 0 0 0 1 1 1 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0| VALIDITY_TIME |0 0 0 1 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1|0 1 1 0 0 1 0 0|0 0 0 0 0 1 0 0|1 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 1| Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid 1 | Mid 2 | Mid 3 | Mid 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1| LINK_STATUS |0 0 0 1 0 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 0 0| HEARD | HEARD | SYMMETRIC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LOST |
+-+-+-+-+-+-+-+-+
Note that the above example assumes that H_HOLD_TIME and C have their default values of 6 seconds and 1/1024 second, and thus result in a time code of 100 (hexadecimal 64).
上記の例では、H_HOLD_TIMEとCのデフォルト値は6秒と1/1024秒であり、したがってタイムコードが100になることに注意してください。
This protocol specifies one Message Type, the HELLO message. The maximum size of a HELLO message is proportional to the size of the originating router's 1-hop neighborhood. HELLO messages MUST NOT be forwarded.
このプロトコルは、1つのメッセージタイプ、Helloメッセージを指定します。Helloメッセージの最大サイズは、発生するルーターの1ホップ近隣のサイズに比例します。こんにちはメッセージを転送してはいけません。
A router MUST report its 1-hop neighborhood in HELLO messages on each of its MANET interfaces at least each REFRESH_INTERVAL. This puts a lower bound on the control traffic generated by each router in the network employing this protocol.
ルーターは、少なくとも各refresh_intervalの各MANETインターフェイスのHelloメッセージで1ホップの近隣を報告する必要があります。これにより、このプロトコルを採用しているネットワーク内の各ルーターによって生成される制御トラフィックの下限が設定されます。
A router MUST ensure that two successive HELLO messages sent on the same MANET interface are separated by at least HELLO_MIN_INTERVAL. (If using jitter, then this may be reduced to a mean minimum value of HELLO_MIN_INTERVAL - HP_MAXJITTER/2.) Thus, this puts an upper bound on the control traffic generated by each router in the network employing this protocol.
ルーターは、同じMANETインターフェイスで送信された2つの連続したハローメッセージが、少なくともhello_min_intervalによって区切られていることを確認する必要があります。（ジッターを使用する場合、これはhello_min_interval -hp_maxjitter/2の平均最小値に削減される場合があります。）したがって、これにより、このプロトコルを使用しているネットワーク内の各ルーターによって生成される制御トラフィックに上限があります。
This informative appendix illustrates the relationship between message timers and intervals. (The adjustments to this timing when using timing jitter, as defined in [RFC5148], are not shown.)
この有益な付録は、メッセージタイマーと間隔の関係を示しています。（[RFC5148]で定義されているタイミングジッターを使用する場合のこのタイミングの調整は示されていません。）
Figure 1 illustrates a basic HELLO message schedule for a router, on a MANET interface, employing strictly periodic transmission of HELLO messages. The router transmits a HELLO message each HELLO_INTERVAL. Each HELLO message contains all 1-hop neighbor network addresses of the router that are to be reported in any such HELLO message. (The parameter REFRESH_INTERVAL, not shown, is in this example equal to the parameter HELLO_INTERVAL.)
図1は、Helloメッセージの厳密に定期的な送信を使用して、Manetインターフェイス上のルーターの基本的なハローメッセージスケジュールを示しています。ルーターは、各hello_intervalにハローメッセージを送信します。各Helloメッセージには、そのようなHelloメッセージで報告されるルーターのすべての1ホップ近隣ネットワークアドレスが含まれています。（パラメーターrefresh_intervalは、示されていないが、この例にはパラメーターhello_intervalに等しい。）
The router includes a VALIDITY_TIME TLV in each HELLO message, encoding the parameter H_HOLD_TIME, the duration for which information received in the HELLO message should be considered valid by receiving routers. Receiving routers will, when recording the information received in the HELLO message, each use this for setting the L_HEARD_time, L_SYM_time and L_time elements of their corresponding Link Tuple, and the N2_time in the corresponding 2-Hop Tuple for each network address. Only L_time is illustrated in Figure 1.
ルーターには、各helloメッセージに有効性_time TLVが含まれており、パラメーターh_hold_timeをエンコードします。ハローメッセージで受信した情報は、ルーターを受信して有効と見なされるべきです。受信ルーターは、Helloメッセージで受信した情報を記録すると、それぞれこれを使用して、対応するリンクタプルのL_HEARD_TIME、L_SYM_TIME、L_TIME要素、および各ネットワークアドレスの対応する2ホップタプルのN2_TIMEを設定します。L_TIMEのみを図1に示します。
H_HOLD_TIME: |-----------------------------| ...
HELLO_INTERVAL: |---------|---------|---------| ...
Time: ---*---------*---------*---------*------>
^ ^ ^ ^
| | | |
HELLO (a, b, c, d) | | |
| | |
HELLO (a, b, c, d) | | ...
| |
HELLO (a, b, c, d) |
|
HELLO (a, b, c, d)
L_time: |-----------------------------|
|-------------------- ...
|---------- ...
| ...
Figure 1: HELLO Message Generation: Regular Schedule
図1：こんにちはメッセージ生成：通常のスケジュール
Figure 2 illustrates a message schedule similar to Figure 1, where the router announces its own presence more frequently by sending additional HELLO messages. HELLO messages are still sent regularly, at a reduced interval defined by a new value of HELLO_INTERVAL. However, REFRESH_INTERVAL has not been reduced. Each 1-hop neighbor network address included in these HELLO messages need be advertised only once within each REFRESH_INTERVAL. Consequently, the additional HELLO messages due to the reduced value of HELLO_INTERVAL may therefore be empty. (This is not the only allowed distribution of 1-hop neighbor network addresses, they could, for example, be sent alternately a, b and c, d.)
図2は、図1と同様のメッセージスケジュールを示しています。ここでは、ルーターが追加のハローメッセージを送信することにより、独自の存在をより頻繁に発表します。helloメッセージは、hello_intervalの新しい値によって定義された縮小間隔で、まだ定期的に送信されます。ただし、refresh_intervalは削減されていません。これらのHelloメッセージに含まれる各1ホップNeighbor Networkアドレスは、各reffery_interval内で1回だけ宣伝する必要があります。したがって、hello_intervalの値が低下したための追加のhelloメッセージは空になる可能性があります。（これは、1ホップ近隣ネットワークアドレスの分布唯一の分布ではありません。たとえば、a、b、c、d。の交互に送信できます。）
H_HOLD_TIME: |-----------------------------| ...
REFRESH_INTERVAL: |---------|---------|---------| ...
HELLO_INTERVAL: |----|----|----|----|----|----| ...
Time: ---*---------*---------*---------*------>
^ ^ ^ ^ ^ ^ ^
| | | | | | |
HELLO (a, b, c, d) | | | | | |
| | | | | |
HELLO () | | | | |
| | | | |
HELLO (a, b, c, d) | | | |
| | | | ...
HELLO () | | |
| | |
HELLO (a, b, c, d) | |
| |
HELLO () |
|
HELLO (a, b, c, d)
L_time: |-----------------------------|
|------------------------- ...
|-------------------- ...
|--------------- ...
|---------- ...
|----- ...
| ...
Figure 2: HELLO Message Generation: Regular Schedule with Different HELLO_INTERVAL and REFRESH_INTERVAL
図2：こんにちはメッセージ生成：異なるhello_intervalとrefresh_intervalの定期的なスケジュール
HELLO messages may also be sent in response to events. The minimal interval between two successive HELLO message transmissions by a router is HELLO_MIN_INTERVAL, setting an upper bound of the HELLO message emission rate. Hence, for each HELLO message transmission, a router must wait at least HELLO_MIN_INTERVAL before the next HELLO message transmission. Similarly, the maximum interval between two successive HELLO message transmissions is HELLO_INTERVAL, setting a lower bound on the message transmission rate. Hence, for each HELLO message transmission, the router must ensure that the next HELLO message transmission must not wait more than HELLO_INTERVAL.
こんにちはメッセージは、イベントに応じて送信される場合があります。ルーターによる2つの連続したハローメッセージ送信の間の最小間隔はhello_min_intervalで、helloメッセージ排出率の上限を設定します。したがって、Helloメッセージ送信ごとに、ルーターは次のHelloメッセージ送信の前に、少なくともhello_min_intervalを待つ必要があります。同様に、2つの連続したHelloメッセージ送信の最大間隔はhello_intervalであり、メッセージ送信レートに下限を設定します。したがって、各ハローメッセージ伝送ごとに、ルーターは次のハローメッセージ送信がhello_intervalよりも待ってはならないことを確認する必要があります。
Figure 3 illustrates a message schedule similar to Figure 1, but with HELLO messages responding to events at maximum rate, i.e., with HELLO messages being sent each HELLO_MIN_INTERVAL. Note that when a HELLO message is sent, it is assumed that the following messages may all be scheduled at an interval of HELLO_INTERVAL, and hence each HELLO message contains all 1-hop neighbor network addresses. In each HELLO message in this example, a new 1-hop neighbor network address is added, reflecting the changes occurring since the last HELLO message was sent. HELLO messages are sent at the maximum allowed rate in order to signal these changes as rapidly as possible.
図3は、図1と同様のメッセージスケジュールを示していますが、Helloメッセージが最大レートでイベントに応答することを示しています。つまり、Helloメッセージが各hello_min_intervalに送信されます。Helloメッセージが送信されると、次のメッセージがすべてhello_intervalの間隔でスケジュールされる可能性があるため、各helloメッセージにはすべての1ホップ近隣ネットワークアドレスが含まれていると想定されることに注意してください。この例の各Helloメッセージには、最後のHelloメッセージが送信されてから発生する変更を反映して、新しい1ホップネイバーネットワークアドレスが追加されています。ハローメッセージは、これらの変更をできるだけ早く合図するために、最大許可レートで送信されます。
H_HOLD_TIME: |-----------------------------| ...
HELLO_INTERVAL: |---------|---------|---------| ...
HELLO_MIN_INTERVAL: |----|----|----|----|----|----| ...
Time: ---*---------*---------*---------*------>
^ ^ ^ ^ ^ ^ ^
| | | | | | |
HELLO () | | | | | |
| | | | | |
HELLO (a) | | | | |
| | | | |
HELLO (a, b) | | | |
| | | | ...
HELLO (a, b, c) | | |
| | |
HELLO (a, b, c, d) | |
| |
HELLO (a, b, c, d, e) |
|
HELLO (a, b, c, d, e, f)
L_time: |-----------------------------|
|------------------------- ...
|-------------------- ...
|--------------- ...
|---------- ...
|----- ...
| ...
Figure 3: HELLO Message Generation: Regular Schedule with Responsive Messages
図3：こんにちはメッセージの生成：レスポンシブメッセージ付きの通常のスケジュール
Figure 4 shows the same example as Figure 3, but with an increased REFRESH_INTERVAL, and showing partial HELLO messages that include only the necessary network addresses.
図4は、図3と同じ例を示していますが、refresh_intervalの増加と、必要なネットワークアドレスのみを含む部分的なハローメッセージを示しています。
H_HOLD_TIME: |-----------------------------| ...
REFRESH_INTERVAL: |-------------------|---------- ...
|-------------------|----- ...
|-------------------| ...
|--------------- ...
|---------- ...
|----- ...
| ...
HELLO_INTERVAL: |---------|---------|---------| ...
HELLO_MIN_INTERVAL: |----|----|----|----|----|----| ...
Time: ---*---------*---------*---------*------>
^ ^ ^ ^ ^ ^ ^
| | | | | | |
HELLO () | | | | | |
| | | | | |
HELLO (a) | | | | |
| | | | |
HELLO (b) | | | |
| | | | ...
HELLO (c) | | |
| | |
HELLO (a, d) | |
| |
HELLO (b, e) |
|
HELLO (c, f)
L_time: |-----------------------------|
|------------------------- ...
|-------------------- ...
|--------------- ...
|---------- ...
|----- ...
| ...
Figure 4: HELLO Message Generation: Regular Schedule with Responsive Messages and Different HELLO_INTERVAL and REFRESH_INTERVAL
図4：こんにちはメッセージ生成：レスポンシブメッセージと異なるhello_intervalとrefresh_intervalを備えた通常のスケジュール
Figure 5 summarizes the overall relationship between the intervals governing HELLO message transmissions by a router.
図5は、ルーターによるHelloメッセージの送信を管理する間隔の全体的な関係をまとめたものです。
H_HOLD_TIME: |------------------------------------|
REFRESH_INTERVAL: |----------------|
HELLO_INTERVAL: |----------|
HELLO_MIN_INTERVAL: |---|
hello_min_interval：| --- |
Time: ----------------------------------------------->
^ ^ ^ ^ ^
| | | | |
| | | | Time up to which
HELLO message | | | received HELLO
transmission | | | message content
| | | is valid.
| | |
| | Time before which all
| | neighbor information must
| | be transmitted in HELLO
| | messages (one or more)
| |
| Latest time for next HELLO message
| transmission
|
Earliest time for next HELLO message
transmission
Figure 5: HELLO Message Generation Intervals
図5：こんにちはメッセージ生成間隔
Figure 6 illustrates the Link Set timers when receiving a HELLO message not including the network address of the receiving MANET interface.
図6は、受信MANETインターフェイスのネットワークアドレスを含まないハローメッセージを受信するときのリンクセットタイマーを示しています。
VALIDITY_TIME: |--------------------------|
L_time: |--------------------------|
L_HEARD_time: |--------------------------|
L_SYM_time: *-| (i.e., expired)
l_sym_time： * - |（つまり、期限切れ）
Time: ---*-------------------------------->
^
|
HELLO () received
Figure 6: HELLO Message Processing: Network Address Not Present
図6：こんにちはメッセージ処理：ネットワークアドレスは存在しません
Figure 7 illustrates the Link Set timers when, following the received HELLO message illustrated in Figure 6, a router receives a HELLO message including the network address (a) of the receiving interface with link status = HEARD (or SYM).
図7は、Link Status = heard（またはsym）を含む受信インターフェイスのネットワークアドレス（a）を含むハローメッセージをルーターが受信した場合、受信したハローメッセージに続いて、受信したハローメッセージに続いてリンクセットタイマーを示しています。
VALIDITY_TIME: |--------------------------|
|--------------------------|
L_time: |--------------------------|
|--------------------------|
L_HEARD_time: |--------------------------|
|--------------------------|
L_SYM_time: *-| (i.e., expired)
L_SYM_time: |--------------------------|
Time: -*-----*--------------------------------->
^ ^
| |
HELLO () received |
|
HELLO (a:HEARD) received
Figure 7: HELLO Message Processing: Network Address Present
図7：こんにちはメッセージ処理：ネットワークアドレスが存在する
Figure 8 illustrates the Link Set timers when, following the received HELLO messages illustrated in Figure 7, a router receives a HELLO message including the network address (a) of the receiving interface with link status = LOST.
図8は、図7に示されている受信したハローメッセージに続いて、ルーターがリンクステータス= lostを含む受信インターフェイスのネットワークアドレス（a）を含むハローメッセージを受信した場合のリンクセットタイマーを示しています。
VALIDITY_TIME: |--------------------------|
|--------------------------|
|--------------------------|
L_time: |--------------------------|
|--------------------------|
|--------------------------|
L_HEARD_time: |--------------------------|
|--------------------------|
|--------------------------|
L_SYM_time: *-| (i.e., expired)
|--------------------------|
*-| (i.e., expired)
Time: -*-----*-----*--------------------------------->
^ ^ ^
| | |
HELLO () received | |
| |
HELLO (a:HEARD) received |
|
HELLO (a:LOST) received
Figure 8: HELLO Message Processing: Network Address Lost
図8：こんにちはメッセージ処理：ネットワークアドレスが失われました
There are three other timing parameters that are used by a router to control HELLO message generation and processing.
ハローメッセージの生成と処理を制御するためにルーターによって使用される他の3つのタイミングパラメーターがあります。
Figure 9 illustrates the time, with duration L_HOLD_TIME, during which the appropriate network addresses of a formerly, but no longer, symmetric 1-hop neighbor, as connected by this MANET interface, are advertised as LOST using a LINK_STATUS TLV in HELLO messages on this MANET interface, thus allowing that 1-hop neighbor to update its Link Set accordingly.
図9は、このMANETインターフェイスで接続されているように、以前の対称1ホップ隣人の適切なネットワークアドレスが、これのHelloメッセージのLink_Status TLVを使用して失われたと宣伝されている、l_hold_timeの期間を示しています。MANETインターフェイスにより、1ホップの隣人がそれに応じてリンクセットを更新できるようになります。
L_HOLD_TIME: |----------------------------|
Time: ---*---------------------------------->
^ ^
| |
Formerly symmetric 1-hop neighbor |
ceases to be symmetric on this |
MANET interface |
|
Time up to which network addresses of
this neighbor connected using this MANET
interface are advertised in HELLO
messages on this MANET interface
using a LINK_STATUS TLV, Value = LOST
Figure 9: HELLO Message Generation: Advertisement of Formerly Symmetric 1-Hop Neighbor on This MANET Interface as Lost
図9：こんにちはメッセージ生成：このMANETインターフェースでの以前の対称1ホップ隣人の広告が失われました
Figure 10 illustrates the time, with duration N_HOLD_TIME, during which all network addresses of a formerly, but no longer, symmetric 1-hop neighbor, are advertised as LOST in HELLO messages on all MANET interfaces using an OTHER_NEIGHB TLV (if not also reported using a LINK_STATUS TLV) thus allowing all other symmetric 1-hop neighbors to update their 2-Hop Sets accordingly.
図10は、期間を示しています。これは、以前は対称1ホップ隣人のすべてのネットワークアドレスが、other_neighb TLVを使用してすべてのMANETインターフェイスでハローメッセージで紛失したとして宣伝されていると宣伝されています（したがって、link_status tlv）したがって、他のすべての対称1ホップネイバーがそれに応じて2ホップセットを更新できるようにします。
L_HOLD_TIME: |----------------------------|
Time: ---*---------------------------------->
^ ^
| |
Formerly symmetric 1-hop neighbor |
ceases to be symmetric |
|
Time up to which network addresses of
this neighbor are advertised in HELLO
messages on all MANET interfaces
using an OTHER_NEIGHB TLV,
Value = LOST
Figure 10: HELLO Message Generation: Advertisement of Formerly Symmetric 1-Hop Neighbor on Any MANET Interface as Lost
図10：こんにちはメッセージ生成：失われたMANETインターフェイス上の以前の対称1ホップ隣人の広告
Figure 11 illustrates the time, with duration I_HOLD_TIME, during which a formerly, but no longer, used local interface network address is excluded from being considered as a 2-hop neighbor network address (in order that a router is not recorded as its own 2-hop neighbor during that period).
図11は、期間の時間を示しています。その間、以前は使用されていないローカルインターフェイスネットワークアドレスは、2ホップのネイットネットワークアドレスと見なされることから除外されます（ルーターが独自の2として記録されないために - その期間中に隣人をhop）。
I_HOLD_TIME: |----------------------------|
Time: ---*----------------------------------->
^ ^
| |
Formerly used local interface |
network address ceases to be |
assigned to a local interface |
|
Time up to which this network
address is excluded from being
included in this router's 2-Hop Set
Figure 11: Local Interface Removed Network Address
図11：ローカルインターフェイス削除ネットワークアドレス
This appendix illustrates various examples of physical topologies, as well as how these are logically recorded by NHDP from the point of view of the router A. This representation is a composite of information that would be contained within A's various Information Bases after NHDP has been running for sufficiently long time for the state to converge.
この付録は、物理的なトポロジのさまざまな例と、ルーターAの観点からNHDPによって論理的に記録される方法を示しています。この表現は、NHDPが実行された後にAのさまざまな情報ベースに含まれる情報の複合です。州が収束するのに十分な長い時間。
Note that the examples given in this appendix are NOT exhaustive, but are selected to be illustrative of NHDP neighborhood representations of physical MANET topologies.
この付録に記載されている例は網羅的ではありませんが、物理的なマネトポロジのNHDP近隣表現を示すように選択されていることに注意してください。
The example topologies presented contain 3 physical routers A, B, and C. Each of these routers has one or two distinct interfaces, denoted "top" and "bottom". Each interface has one or two addresses, and symmetric connectivity between a pair of interfaces is illustrated by these being connected by a line.
提示されたトポロジの例には、3つの物理ルーターA、B、およびCが含まれています。これらのルーターにはそれぞれ、「上」と「下」と示された1つまたは2つの異なるインターフェイスがあります。各インターフェイスには1つまたは2つのアドレスがあり、インターフェイスのペア間の対称接続性は、これらが線で接続されていることによって示されています。
In all examples, the topology is described as it is recorded by NHDP in router A.
すべての例では、トポロジーはルーターAのNHDPによって記録されているときに説明されています。
In Figure 12, each router has a single interface, each with a single IP address. This is the simplest possible network, and the resulting representation is given to the right in Figure 12.
図12では、各ルーターには単一のインターフェイスがあり、それぞれに単一のIPアドレスがあります。これは可能な限り単純なネットワークであり、結果の表現は図12の右側に与えられます。
__________ __________
| | |
{1} {2} {3}
| | | {1}--------{2}--------{3}
+--'--+ +--'--+ +--'--+
| A | | B | | C |
+-----+ +-----+ +-----+
Figure 12: Standard Single Interface Topology (Left), and Corresponding NHDP Representation (Right)
図12：標準の単一インターフェイストポロジ（左）、および対応するNHDP表現（右）
The Local Information Set in A contains a single Local Interface Tuple that has an I_local_iface_addr_list of {1}. This value is denoted with a {1} on the leftmost part of the resulting representation.
Aに設定されたローカル情報には、{1}のi_local_iface_addr_listを持つ単一のローカルインターフェイスタプルが含まれています。この値は、結果の表現の左側の部分に{1}で示されます。
The Interface Information Base has only one Link Set, which represents the "top" interface of A, or {1}. This Link Set's only Link Tuple has an L_neighbor_iface_addr_list containing {2}; this corresponds to the dashed line from {1} to {2} to the right in Figure 12. The 2-Hop Set contains a single 2-Hop Tuple, with N2_neighbor_iface_addr_list being {2} and N2_2hop_addr being {3}; this corresponds to the dashed line from {2} to {3} to the right in Figure 12.
インターフェイス情報ベースには、aまたは{1}の「上部」インターフェイスを表すリンクセットが1つしかありません。このリンクセットの唯一のリンクTupleには、{2}を含むl_neighbor_iface_addr_listがあります。これは、図12の{1}から{2}から{2}までの破線に対応します。2ホップセットには、n2_neighbor_iface_addr_listが{2}およびn2_2hop_addrが{3}である単一の2ホップタプルが含まれています。これは、図12の{2}から{3}までの破線に対応します。
The descriptions of the following examples in this appendix will be derived similarly, and use the same notational conventions.
この付録の次の例の説明も同様に導き出され、同じ表記規則を使用します。
In Figure 13, the network is identical to that in Example 1, except that the middle router, B, has two IP addresses on its single interface.
図13では、ネットワークは例1のネットワークと同じですが、中央のルーターbには単一のインターフェイスに2つのIPアドレスがあることを除きます。
__________ __________
| | |
{1} {2,4} {3}
| | | {1}-------{2,4}-------{3}
+--'--+ +--'--+ +--'--+
| A | | B | | C |
+-----+ +-----+ +-----+
Figure 13: Single Interfaces, with 1-Hop Neighbor B Having Two Addresses (Left), and Corresponding NHDP Representation (Right)
図13：1ホップの隣接Bに2つのアドレス（左）と対応するNHDP表現（右）がある単一のインターフェイス
The content of the Interface Information Base is in this case identical to Example 1, except that L_neighbor_iface_addr_list is {2,4} and N2_neighbor_iface_addr_list is {2,4}.
この場合、インターフェイス情報ベースの内容は例1と同じですが、L_NEIGHBOR_IFACE_ADDR_LISTは{2,4}およびN2_NEIGHBOR_IFACE_ADDR_LISTが{2,4}です。
In Figure 14, the network is identical to that in Example 1, except that the rightmost router, C, has two IP addresses on its interface.
図14では、ネットワークは例1のネットワークと同じですが、右端のルーターCがインターフェイスに2つのIPアドレスがあることを除きます。
__________ __________
| | |
{1} {2} {3,4} +----{3}
| | | {1}--------{2}---+
+--'--+ +--'--+ +--'--+ +----{4}
| A | | B | | C |
+-----+ +-----+ +-----+
Figure 14: Single Interfaces, with 2-Hop Neighbor C Having Two Addresses (Left), and Corresponding NHDP Representation (Right)
図14：2ホップ近隣Cが2つのアドレス（左）と対応するNHDP表現（右）を持つ単一のインターフェイス
The content of the Interface Information Base is in this case identical to than in Example 1, except that the 2-Hop Set contains an extra 2-Hop Tuple with N2_neighbor_iface_addr_list being {2} and N2_2hop_addr being {4}. These two 2-Hop Tuples are illustrated by the two lines from {2} to {3} and (2) to {4}, respectively.
この場合、インターフェイス情報ベースの内容は、2ホップセットには、N2_NEIGHBOR_IFACE_ADDR_LISTが{2}およびN2_2HOP_ADDRが{4}である追加の2ホップタプルが含まれていることを除いて、例1と同じ場合と同じです。これらの2つの2ホップのタプルは、{2}から{3}、および（2）から{4}から{3}、および（2）までの2つの線によって示されています。
In Figure 15, the network is identical to that in Example 1, except that all routers have two IP addresses on their interface. The Local Information Base in router A is the same as in Example 1, except that I_local_iface_addr_list is {1,5}.
図15では、ネットワークは例1のネットワークと同じですが、すべてのルーターにはインターフェイスに2つのIPアドレスがあることを除きます。ルーターAのローカル情報ベースは、i_local_iface_addr_listが{1,5}であることを除いて、例1と同じです。
__________ __________
| | |
{1,5} {2,6} {3,4} +----{3}
| | | {1,5}------{2,6}--+
+--'--+ +--'--+ +--'--+ +----{4}
| A | | B | | C |
+-----+ +-----+ +-----+
Figure 15: Single interfaces, all routers having two addresses (left), and corresponding NHDP representation (right)
図15：単一のインターフェイス、2つのアドレス（左）、および対応するNHDP表現（右）を持つすべてのルーター
The content of the Interface Information Base is in this case a combination of the Interface Information Bases from Examples 1, 2, and 3.
この場合、インターフェイス情報ベースの内容は、例1、2、および3のインターフェイス情報ベースの組み合わせです。
In Figure 16, all routers have a single IP address on each interface, and with the 2-hop neighbor having two interfaces.
図16では、すべてのルーターには各インターフェイスに単一のIPアドレスがあり、2ホップの隣人に2つのインターフェイスがあります。
__________ __________
| | |
{1} {2} {3} +----{3}
| | | {1}--------{2}---+
+--'--+ +--'--+ +-----+ +----{4}
| A | | B | | C |
+-----+ +-----+ +-----+
|
{4}
Figure 16: Single Addresses, with 2-Hop Neighbor C Having Two Interfaces (Left), and Corresponding NHDP Representation (Right)
図16：2ホップの隣接Cが2つのインターフェイス（左）と対応するNHDP表現（右）を持つ単一のアドレス。
The Interface Information Base is identical to that in Example 3; NHDP does not distinguish topologically between this example and Example 3.
インターフェイス情報ベースは、例3の情報と同じです。NHDPは、この例と例3をトポロジー的に区別しません。
In Figure 17, all routers have a single IP address on each interface, and with the 1-hop neighbor having two interfaces.
図17では、すべてのルーターには各インターフェイスに単一のIPアドレスがあり、1ホップの近隣には2つのインターフェイスがあります。
__________
| |
{1} {2} +-----+
| | {1}-------| {2} |------{4}
+--'--+ +--'--+ +-----+ | {5} |
| A | | B | | C | +-----+
+-----+ +-----+ +-----+
| |
{5} {4}
|__________|
Figure 17: Single Addresses, with 1-Hop Neighbor B Having Two Interfaces (Left), and Corresponding NHDP Representation (Right)
図17：1ホップの隣接Bに2つのインターフェイス（左）があり、対応するNHDP表現（右）があります。
The Local Information Base is identical to that in Example 1.
ローカル情報ベースは、例1のそれと同じです。
The Interface Information Base has only one Link Set containing one Link Tuple with L_neighbor_iface_addr_list being {2}. The 2-Hop Set contains a single 2-Hop Tuple, with N2_neighbor_iface_addr_list being {2} and N2_2hop_addr being {4}.
インターフェイス情報ベースには、l_neighbor_iface_addr_listの1つのリンクタプルを含む1つのリンクセットのみが{2}です。2ホップセットには、n2_neighbor_iface_addr_listが{2}、n2_2hop_addrは{4}である1つの2ホップタプルが含まれています。
The Neighbor Information Base contains a Neighbor Set containing a single Neighbor Tuple, which represents router B, with N_neighbor_addr_list being {2,5}. This entry is represented on the right of Figure 17 by boxing {2} with {5}.
隣接情報ベースには、n_neighbor_addr_listが{2,5}であるルーターBを表す単一の隣のタプルを含む隣接セットが含まれています。このエントリは、{5}でボクシング{2}によって図17の右側に表されています。
Note that router A does not have information indicating which of router B's interfaces is connected to router C. However, router A knows that the address {4} (and thus router C) is reachable by using {2} as next hop.
ルーターAには、ルーターBのインターフェイスのどれがルーターCに接続されているかを示す情報がないことに注意してください。ただし、ルーターAは、アドレス{4}（したがってルーターC）が{2}を次のホップとして使用して到達可能であることを知っています。
In Figure 18, all routers have a single IP address on each interface, and both the 1-hop and 2-hop neighbors have two interfaces. Furthermore, there are now two physical links between routers B and C, over distinct interface pairs.
図18では、すべてのルーターには各インターフェイスに単一のIPアドレスがあり、1ホップと2ホップの両方の近隣には2つのインターフェイスがあります。さらに、ルーターBとCの間には、異なるインターフェイスペア上に2つの物理リンクがあります。
__________ __________
| | |
{1} {2} {3} +-----+ +----{3}
| | | {1}-------| {2} |---+
+--'--+ +--'--+ +-----+ | {5} | +----{4}
| A | | B | | C | +-----+
+-----+ +-----+ +-----+
| |
{5} {4}
|__________|
Figure 18: Single Addresses, with 1-Hop and 2-Hop Neighbors B and C Having Two Interfaces (Left), and Corresponding NHDP Representation (Right)
図18：1ホップと2ホップの隣人BとCが2つのインターフェイス（左）と対応するNHDP表現（右）を持つ単一のアドレス
The Local Information Base is identical to that in Example 1.
ローカル情報ベースは、例1のそれと同じです。
The Link Set is identical to that in Example 6, and the 2-Hop Set contains, as in Example 5 (and similarly to Examples 3 and 4), two 2-Hop Tuples representing the two links between routers B and C.
リンクセットは例6のものと同じであり、2ホップセットには、例5（および例3および4と同様）のように、ルーターBとCの間の2つのリンクを表す2つの2ホップタプルが含まれています。
Note that router A does not have information describing which of router B's interfaces is connected to which interfaces of router C, or even that the interfaces with addresses {3} and {4} are interfaces of the same router. However, router A knows that the addresses {3} and {4} (and thus router C) are reachable using {2} as next hop.
ルーターAには、ルーターBのどのインターフェイスがルーターCのインターフェイスに接続されているか、あるいはアドレス{3}および{4}のインターフェイスが同じルーターのインターフェイスであることを説明する情報がないことに注意してください。ただし、ルーターAは、アドレス{3}と{4}（したがってルーターC）が次のホップとして{2}を使用して到達可能であることを知っています。
In Figure 19, all routers have a single IP address on each interface, and both A and its the 1-hop neighbor B have two interfaces. Furthermore, there are now two physical links between routers A and B, over distinct interface pairs.
図19では、すべてのルーターには各インターフェイスに単一のIPアドレスがあり、Aと1ホップの隣接Bの両方に2つのインターフェイスがあります。さらに、ルーターAとBの間には、異なるインターフェイスペア上に2つの物理リンクがあります。
__________ __________
| | | +-----+
{1} {2} {3} {1}-------| {2} |--------{3}
| | | | {5} |
+--'--+ +--'--+ +-----+ +-----+
| A | | B | | C |
+-----+ +-----+ +-----+ +-----+
| | | {2} |
{6} {5} {6}-------| {5} |--------{3}
|__________| +-----+
Figure 19: Single Addresses, with Both A and 1-Hop Neighbor B Having Two Interfaces (Left), and Corresponding NHDP Representation (Right)
図19：Aと1ホップの両方の隣接Bに2つのインターフェイス（左）と対応するNHDP表現（右）があります。
The Local Information Set contains two Local Interface Tuples, with I_local_iface_addr_list of {1} and {6}, respectively.
ローカル情報セットには、{1}と{6}のi_local_iface_addr_listを使用して、2つのローカルインターフェイスタプルが含まれています。
Each Interface Information Base's Link Set contains one Link Tuple, representing the links between {1} and {2}, and between {6} and {5}, respectively. The 2-Hop Set for interface {1} contains a single 2-Hop Tuple, with N2_neighbor_iface_addr_list being {2} and N2_2hop_addr being {3}. The 2-Hop Set for interface {6} contains a single 2-Hop Tuple, with N2_neighbor_iface_addr_list being {5} and N2_2hop_addr being {3}.
各インターフェイス情報ベースのリンクセットには、{1}と{2}と{6}と{5}の間のリンクを表す1つのリンクタプルが含まれています。インターフェイス{1}用の2ホップセットには、N2_NEIGHBOR_IFACE_ADDR_LISTが{2}、N2_2HOP_ADDRは{3}である単一の2ホップタプルが含まれています。インターフェイス{6}用の2ホップセットには、N2_NEIGHBOR_IFACE_ADDR_LISTが{5}とN2_2HOP_ADDRが{3}である単一の2ホップタプルが含まれています。
The Neighbor Information Base contains a Neighbor Set containing a single Neighbor Tuple, which represents router B, with N_neighbor_addr_list being {2,5}. This entry is denoted by boxing {2} with {5}.
隣接情報ベースには、n_neighbor_addr_listが{2,5}であるルーターBを表す単一の隣のタプルを含む隣接セットが含まれています。このエントリは、{5}のボクシング{2}で示されます。
In Figure 20, all routers have a single IP address on each interface, and all routers have two interfaces. Furthermore, there are now two physical links between A and B, over distinct interface pairs, and two physical links between B and C, also over distinct interface pairs.
図20では、すべてのルーターには各インターフェイスに単一のIPアドレスがあり、すべてのルーターには2つのインターフェイスがあります。さらに、AとBの間には、異なるインターフェイスペアを介して2つの物理的リンクがあり、BとCの間に2つの物理リンクがあり、個別のインターフェイスペア上にもあります。
__________ __________
| | | +-----+ +----{3}
{1} {2} {3} {1}-------| {2} |---+
| | | | {5} | +----{4}
+--'--+ +--'--+ +-----+ +-----+
| A | | B | | C |
+-----+ +-----+ +-----+ +-----+
| | | | {2} | +----{3}
{6} {5} {4} {6}-------| {5} |---+
|__________|__________| +-----+ +----{4}
Figure 20: Single Addresses, with All Routers Having Two Interfaces (Left), and Corresponding NHDP Representation (Right)
図20：すべてのルーターが2つのインターフェイス（左）と対応するNHDP表現（右）を持つ単一のアドレス。
The Local Information Set is identical to that in Example 8. The Interface Information Base for each interface in A is also identical to that in Example 8, except that an additional 2-Hop Tuple is present in each 2-Hop Set, each representing the link between router B and the interface of router C with address {4}.
ローカル情報セットは、例8のそれと同じです。Aの各インターフェイスのインターフェイス情報ベースも例8のインターフェース情報ベースと同じです。ルーターBとルーターCのインターフェイスとアドレス{4}との間のリンク。
As in Example 7, router A does not have information describing which of router B's interfaces is connected to which interface of C, or even that the interfaces with addresses {3} and {4} are interfaces of the same router. However, router A knows that the addresses {3} and {4} (and router C) are reachable by using {2} or {5} (depending on via which of its local interfaces) as next hop.
例7のように、ルーターAには、ルーターBのインターフェイスがCのインターフェイスに接続されているか、アドレス{3}および{4}を持つインターフェイスが同じルーターのインターフェイスであることを説明する情報がありません。ただし、ルーターAは、次のホップとして{2}または{5}（ローカルインターフェイスのどれによって）を使用して{3}および{4}（およびルーターC）が到達可能であることを知っています。
In Figure 21, all routers have two IP addresses on each interface, and all routers have two interfaces. Furthermore, there are now two physical links between A and B, over distinct interface pairs, and two physical links between B and C, also over distinct interface pairs.
図21では、すべてのルーターには各インターフェイスに2つのIPアドレスがあり、すべてのルーターには2つのインターフェイスがあります。さらに、AとBの間には、異なるインターフェイスペアを介して2つの物理的リンクがあり、BとCの間に2つの物理リンクがあり、個別のインターフェイスペア上にもあります。
+--{9}
__________ __________ +------|
| | | +-----+ | +--{10}
{1,2} {5,6} {9,10} {1,2}--|{5,6}|---+
| | | |{7,8}| | +--{11}
+--'--+ +--'--+ +-----+ +-----+ +------|
| A | | B | | C | +--{12}
+-----+ +-----+ +-----+
| | | +--{9}
| | | +-----+ +------|
| | | |{5,6}| | +--{10}
{3,4} {7,8} {11,12} {3,4}--|{7,8}|---+
|__________|__________| +-----+ | +--{11}
+------|
+--{12}
Figure 21: Dual Addresses, with All Routers Having Two Interfaces (Left) and Corresponding NHDP Representation (Right)
図21：デュアルアドレス、すべてのルーターに2つのインターフェイス（左）と対応するNHDP表現（右）があります
This example is the combination of all the preceding examples in this appendix. The Local Information Set in A contains Local Information Tuples for each of its interfaces, and each Interface Information Base contains in its Link Set a representation of links {1,2}-{5,6} or {3,4}-{7,8}, respectively. The Neighbor Set (in the Neighbor Information Base) records the existence of router B and all of its addresses on all its interfaces, i.e., {5,6,7,8}.
この例は、この付録の前述のすべての例の組み合わせです。Aに設定されたローカル情報には、各インターフェイスのローカル情報タプルが含まれています。各インターフェイス情報ベースには、リンクセットがリンク{1,2} - {5,6}または{3,4} - {7の表現が含まれています。、8}、それぞれ。近隣セット（隣の情報ベース）は、ルーターBとそのすべてのアドレスの存在を、そのすべてのインターフェイス、つまり{5,6,7,8}の存在を記録します。
As in Example 9, each interface address of router C is represented in the 2-Hop Set of each Interface Information Base as a link from router B to each of these addresses. Router A does not have information describing which of router B's interfaces is connected to which interface of C, nor that the addresses {9}, {10}, {11}, and {12} are addresses of the same router (or that some of these, such as {9} and {10}, are addresses on the same interface of the router).
例9のように、ルーターCの各インターフェイスアドレスは、各インターフェイス情報ベースの2ホップセットで、ルーターBからこれらの各アドレスへのリンクとして表されます。ルーターAには、ルーターBのインターフェイスがCのインターフェイスに接続されているか、アドレス{9}、{10}、{11}、および{12}が同じルーターのアドレスであることを説明する情報がありません。{9}や{10}などのこれらのうち、ルーターの同じインターフェイスのアドレスです）。
In Figure 22, all routers have a single interface, except for router A which has two. Each of A's two interfaces has a link with the single interface of router B. All interfaces have a single address.
図22では、2つのルーターAを除き、すべてのルーターには単一のインターフェイスがあります。Aの2つのインターフェイスには、ルーターBの単一インターフェイスとのリンクがあります。すべてのインターフェイスには単一のアドレスがあります。
__________ __________
| _____| |
{1} | {2} {3} {1}--------{2}---------{3}
| | | |
+--'--+ | +--'--+ +-----+
| A | | | B | | C |
+-----+ | +-----+ +-----+
| |
{6} | {6}--------{2}---------{3}
|____|
Figure 22: Single Addresses, with A Having Two Interfaces, Both Linked to the Single Interface of B (Left), and Corresponding NHDP Representation (Right)
図22：Bの単一インターフェイス（左）にリンクされた2つのインターフェイスを持つAがあり、対応するNHDP表現（右）があります。
This is similar to Example 8, except that the single address {2} also replaces the address {5}. In particular, both Link Tuples (one in each Link Set, each in its corresponding Interface Information Base) have L_neighbor_iface_addr_list being {2}, the Neighbor Set (in the Neighbor Information Base) contains a single Neighbor Tuple with N_neighbor_addr_list being {2}, and both 2-Hop Tuples (one in each 2-Hop Set, each in its corresponding Interface Information Base) have N2_neighbor_iface_addr_list being {2} and N2_2hop_addr being {3}.
これは例8に似ていますが、単一のアドレス{2}がアドレス{5}も置き換えることを除きます。特に、両方のリンクタプル（各リンクセットに1つ、対応するインターフェイス情報ベースにそれぞれ）がl_neighbor_iface_addr_list {2}であり、隣接セット（隣の情報ベース）には、n_neighbor_addr_listの単一の隣のタプルが含まれています{2}、両方の2ホップタプル（各2ホップセットに1つ、それぞれ対応するインターフェイス情報ベースに）は、n2_neighbor_iface_addr_listが{2}とn2_2hop_addr {3}です。
Authors' Addresses
著者のアドレス
Thomas Heide Clausen LIX, Ecole Polytechnique
Thomas Heide Clausen Lix、Ecole Polytechnique
Phone: +33 6 6058 9349
EMail: T.Clausen@computer.org
URI: http://www.ThomasClausen.org/
Christopher Dearlove BAE Systems ATC
クリストファー・ディアローブ・ベイ・システムATC
Phone: +44 1245 242194
EMail: chris.dearlove@baesystems.com
URI: http://www.baesystems.com/
Justin W. Dean Naval Research Laboratory
ジャスティン・W・ディーン海軍研究所
Phone: +1 202 767 3397
EMail: jdean@itd.nrl.navy.mil
URI: http://pf.itd.nrl.navy.mil/