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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版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ホップ近隣情報は、隣接ルータに直接（1ホップ）の接続性を決定するために、MANETルーティングプロトコルによって使用するために記録されています。効率的なネットワーク全体のトラフィックの普及のために減少中継セットを選択するために、例えば、フラッディング低減技術を採用するMANETルーティングプロトコルをイネーブルにするように、2ホップ対称近隣情報が記録されています。
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).
アドホックネットワークにおける、より挑戦的な通信チャネル（例えば、無線、損失、他のネットワークデバイスから中等度及び共有帯域幅、隠れ露出端子、及び干渉の放送チャンネル、上、それらの想定される適用に、より伝統的な有線インフラベースの無線ネットワークとは異なります環境）、より挑戦的な構造条件（例えば、迅速かつ予測不可能なモビリティで、ダイナミックかつ非所定のネットワーク会員）。
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.
無線伝送の特性のため、二つの隣接ルータ間の通信は、双方向でなくてもよいです。ルータ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内の各ルータは、複数の通信チャネルを使用することができます。具体的には、ルータの同一の対の間に、複数の異なる通信チャネルは、それぞれ異なる特性を有する、存在してもよいです。これは、例えば、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.
与えられたMANETルータの隣接ルータのセットは、連続しばしばルータの移動やMANETが配置されている変化する物理的環境に、変更することができます。検出するための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.
MANETルーティングプロトコルは、例えば、[RFC3626]及び[RFC5449]のために、多くの場合、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].
キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "SHALL"、 "SHOULD"、 "ないもの"、 "推奨" "ない（SHOULD NOT）"、 "MAY"、 "推奨NOT"、および「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」、「住所」、「アドレスプレフィックス」、及び「アドレスオブジェクトは」として解釈されるべきですそこに記載されています。
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.
ルータ：この近所の発見プロトコルを実装MANETルータ。
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に参加し、この辺の発見プロトコルを使用して。ルータは、いくつかの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のMANETインタフェースは、後者が前者から、本明細書によれば、制御メッセージを受信することができる場合、ルータYのMANETインタフェースに聞こえると考えられます。
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のMANETインタフェースがルータYのMANETインタフェースによって聞かれた場合、ルータ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とルータY.にMANETインタフェース上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ルータXは、ルータYの1ホップネイバーの1ホップネイバーであるが、Y自体をルータされていない場合、ルータYの2ホップネイバーです。
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ルータXは、ルータYの対称の1ホップ隣人の対称の1ホップネイバーであるが、Y自体をルータされていない場合、ルータ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.
定数：常時、MANET内のすべてのルータのすべてのMANETインターフェイスで同じでなければなりません数値。
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が含まれている場合trueを返し、そうでなければfalseを返します。
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を返します。
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は、ネットワークアドレスである場合、AはBと重複し、Aで表されるアドレスの範囲及びBで表されるアドレスの範囲は、両方の少なくとも一つの共通のアドレスを含みます。 （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）の値に等しい場合にtrueを返し、C = D比較演算子、。 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）がtrueを返すにはfalseを返されたであろう、そしてここで、（E = F）はfalseを返すことがtrueを返したでしょう。
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インタフェースを持つルータをサポートします。ルータのインターフェイスのセットは、時間の経過とともに変化することがあります。各インタフェースは、一つ以上の関連するネットワークアドレスを有していてもよく、これらはまた、動的に変化することができます。
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]で指定されたパケット及びメッセージフォーマットを使用します。これは、ローカルトポロジ情報をシグナリングするために使用されるHELLOメッセージタイプの定義を含みます。
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メッセージに含まれた場合に、着信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.
情報ベースの情報の一部からのHELLOメッセージの生成、O。
o The updating of the Information Bases according to received HELLO messages and other events.
受け取ったHELLOメッセージやその他のイベントに応じた情報ベースの更新O。
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.
MANETに参加するルータのためには、少なくとも1つ、おそらくはより多くの、MANETインタフェースを持たなければなりません。
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.
他のMANETインタフェースに割り当てられた場合、O、同じルータに、これら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が生成し、HELLOメッセージを処理します。
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.
このルータのインタフェース（MANETおよび非MANET）のネットワークアドレスを含むローカル情報ベース、O。この情報ベースの内容は、シグナリングによって変更されません。
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.
このプロトコルの実装は、指示された形でこの情報を維持する、またはその情報へのアクセスを提供しています他の組織でもよい（MAY）。具体的には、唯一のプロトコルタプルはその時点で除去されたかのように動作するために、示された正確な時間に設定し、プロトコルからプロトコルタプルを除去する必要はないことに注意してください。
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メッセージに含まれていてもよいです。このような情報は、それが有効と見なされている限られた期間を有します。この期間は、次に、対応するインターフェースパラメータH_HOLD_TIMEを使用して、HELLOメッセージを発信したルータによって設定された情報を受信したHELLOメッセージにVALIDITY_TIME TLVから決定されます。
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は、メッセージ受信との間の関係を示し、VALIDITY_TIMEのTLV、及びHELLOメッセージで受信された情報が有効と考えられるため持続時間が含まれます。付録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.
ルータのインタフェース（MANETまたは非MANET）を表すそれぞれがローカル・インタフェースタプルから成り、ローカル・インタフェース設定、O。
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.
ルータのインタフェース（MANETまたは非MANET）の最近使用されたネットワークアドレスを記録その各々が除去インターフェイスアドレスタプルから成り削除さインターフェイスアドレスセット、O。
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ホップ隣接及び特にこのMANETインタフェースから収集対称の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.
1ホップ隣人のこのMANETインタフェースとMANETインタフェース間の電流と最近失われたリンクに関する情報を記録リンクセット、O。リンクセットは、単一のリンクに関する情報が含まれ、それぞれがリンクタプル、から構成されています。リンク品質情報を使用する場合、（セクション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.
このMANETインタフェース及び他のルータ（対称の2ホップネイバー）の対称の1ホップ隣人との間の対称なリンクの存在を記録する2ホップセット、O。 2ホップセットは、対称2ホップネイバーのネットワークアドレス、および、対応する対称の1ホップ隣人のすべてのネットワーク・アドレスを記録各々が2ホップタプルからなります。
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ホップセットを移入することを可能にします。彼らはHELLOメッセージでアドバタイズできるように、最近失われたリンクは、関連する1ホップ隣人のリンクセットからのそれらの除去を加速し、MANETインタフェースのためのリンクセットに記録されています。
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インターフェイスの設定されたリンクは、それ自体が上記のように対称的なリンクを記録するなど、Helloメッセージを受信すると更新されます。 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ホップ隣人のすべてのネットワークアドレスを記録し、それぞれが隣接タプル、から構成されています。近隣タプルはリンクタプルを対応がある限り維持されています。
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.
隣接セットは各1ホップネイバーのすべてのネットワークアドレスを関連付けます。他の対称的な1ホップネイバーが2ホップセットにこの情報を記録することができるように、Helloメッセージを生成する際に、これらのネットワークアドレスが含まれていてもよいです。隣接セットは、HELLOメッセージを受信した上で更新することができます。
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.
ロスト隣接セットは、アドレスが（最近対称の1ホップ隣接の）が失われているとしてHELLOメッセージに含まれるべきであるネットワークを決定するために使用されます。ロスト隣接セット自体が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インタフェースのそれぞれでHELLOメッセージを生成します。 helloメッセージは、MANETルータの各MANETインタフェース上で独立して生成されます。所与のHELLOメッセージの内容は、それが生成されたMANETインタフェースに依存します。
Each HELLO message:
各HELLOメッセージ：
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および非MANET）を報告します。これは、HELLOメッセージの受信者は、単一の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.
ハローメッセージ生成、及びHELLOメッセージの処理の結果として記録された情報の妥当性は、TLVを介して、HELLOメッセージに含まれるタイマーと有効性情報に影響されます。メッセージタイマーと間隔との関係は、付録Eに示されています
HELLO messages are generated by a router for each of its MANET interfaces, and MAY be sent:
ハローメッセージはそのMANETインタフェースの各ルータによって生成され、送信され得ます。
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.
ルータ自体の変化、またはその1ホップ近傍に応答するように、例えば、最初にアクティブになるか、または新しい、失われた、または変更されたステータスリンクに応答して、O。
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メッセージの生成および送信のジッタを使用すべきです。
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.
ハロールータの全てのMANETインターフェイスの同じスケジュールを使用して、メッセージが各MANETインタフェースごとに独立にスケジュールされてもよく、又は、インタフェースパラメータが許します。
The content of a HELLO message MUST satisfy the following:
HELLOメッセージの内容は、次のことを満たす必要があります。
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.
ルータの各MANETインタフェースのOの少なくとも一つのネットワーク・アドレス。
o Network addresses that include all source addresses of any IP datagrams sent by the router on any MANET interface.
任意のMANETインタフェース上でルータによって送信されたIPデータグラムのすべての送信元アドレスが含まOネットワークアドレス。
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メッセージは、対応するリンクセットの関連情報と隣接情報ベースのすべてを含まなければなりませんまとめて送りました。 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メッセージは、対応するリンクセットの関連情報と隣接情報ベースのすべてを含まなければなりませんまとめて送りました。
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)).
HELLOメッセージで隣接情報の所定の部分を含めるかどうかを決定するとき、O、その情報が現在の時刻までの長さREFRESH_INTERVALの間隔で送信されたかどうかを検討するのに十分ではありません。代わりに、ルータは次のHELLOメッセージは、このMANETインターフェイス上で送信される時に、最新の可能な時間で終了します長REFRESH_INTERVALの間隔を考慮しなければなりません。 （通常、これは現在の時刻を過ぎてHELLO_INTERVALになりますが、このルータがHELLOメッセージのサイズを小さくするために複数のHELLOメッセージの中でそのネイバー情報を分割することを選択した場合、以前の場合があります。）すべてのネイバー情報を送らなければなりませんこの間隔は、すなわち、ルータはこのHELLOメッセージは既にこの期間の開始（ - （REFRESH_INTERVAL - HELLO_INTERVAL）は通常、現在の時刻）以降送信されたすべてのHELLOメッセージには含まれていないすべてのネイバーの情報が含まれていることを確認しなければなりません。
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.
HELLOメッセージO [RFC5497]で指定されるように、そのメッセージの内容が有効とみなされるべきであり、受信ルータのインタフェース情報ベース内に含まれることがある時間の長さを示し、正確に一つVALIDITY_TIMEメッセージTLVを含まなければなりません。
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.
すなわち、さらにHELLOメッセージがその上で送信されることが保証されている期間は、そのMANETインターフェイスのHELLO_INTERVALの現在の値を示していると、[RFC5497]で指定されるように周期的に生成されたハローメッセージは、正確に一つINTERVAL_TIMEメッセージTLVを含むべきであるoをMANETインタフェース。
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メッセージを受信した上MANETインタフェース、並びに隣接ルータの情報ベースのためのインターフェース情報ベースを更新するために使用されます。具体的に：
o The router ensures that there is a single Neighbor Tuple corresponding to the originator of that HELLO message.
Oルータは、HELLOメッセージの発信者に対応する単一の隣接タプルが存在することを保証します。
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.
HELLOメッセージを送信し、受信したMANETのインターフェイスとの間のリンクが対称である場合、O、ルータは適切な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.
本明細書で定義された処理は、付録Bに指定された情報ベースの内容の制約を維持し、HELLOメッセージで予期しないと誤った情報を処理します
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
MANET内の一部のリンクが原因の有害な無線伝搬に、例えば、限界であってもよいです。このような不完全なリンクを使用しないようにするためには、リンク品質値は、各リンクのタプルに記録されています。 MANETルータは、失われたとして不十分なリンク品質が記録されているリンクを検討します。リンクタプルに記録されているリンク品質を変更することです
OPTIONAL. If link quality is not to be modified, it MUST be set to indicate an always usable quality link.
オプション。リンク品質が変更されるようにされていない場合、常に使用可能な質の高いリンクを示すために設定しなければなりません。
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.
そのリンク品質が与えられたリンクにも使用するため検討するにはあまりにも不安定であることを決定するようにルータをできるように、「リンクアドミタンス」のメカニズムであることに注意してください。それは、具体的リンクメトリックではありませんまた、それは1の代わりです。
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.
リンクの品質情報は、ゼロ包括一、より良い、値が大きいリンク品質に間隔で正規化された、無次元の値として本明細書に定義されています。詳細については、セクション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]で指定されるように、リンクローカルマルチキャストアドレス「LL-MANETルーター」を使用して送信されてもよいです。
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:
helloメッセージは、二つの主要な機能を果たします。
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メッセージの周期的送信を使用する場合、これらは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つの連続したHELLOメッセージの送信間の最小間隔。 （[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：各1ホップ近隣ネットワークアドレスとそのステータスのこのMANETインタフェース上のハローメッセージ内の広告との間の最大間隔、。長REFRESH_INTERVALのすべての間隔において、ルータは、各1ホップ近隣ネットワークアドレスと、このMANETインタフェース上の少なくとも一つのHELLOメッセージでそのステータスを含まなければなりません。 （これは、同じまたは異なるHELLOメッセージであってもよいです。）
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は、このような情報の一部の周波数を表し、HELLOメッセージで受信されるように、リフレッシュすることが期待できます。したがって、REFRESH_INTERVALは、そのような情報は、ルータの受信に満了するときを決定するための基礎として使用される（セクション5.3.2参照）。 HELLO_INTERVALは、HELLOメッセージの排出の頻度を表します。論理的には、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メッセージを送信するための可能な使用は、部分的なHELLOメッセージを送信することを含む（例えば、下にある媒体からパケットサイズの制約を収容する）各HELLOメッセージ中の情報の一部のみをリフレッシュします。別の用途は、HELLOメッセージ交換の成功率は、リンク品質の推定に使用されている、またはで新しいルータによる迅速な検出を可能にする場合には、例えば小さなHELLOメッセージ（で頻繁に自身の存在を広告し、「空の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 REFRESH_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].
[RFC5497]で定義されるようINTERVAL_TIMEメッセージTLVは、HELLOメッセージに含まれている場合、[RFC5497]に記載されているようにO、次いで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.
REFRESH_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インタフェースにHELLOメッセージを送信します。 MANETインタフェース上純粋に応じた方法で、このプロトコルを使用するルータの場合、すなわち、唯一の外部イベントに対する応答として、そのMANETインタフェース上でハローメッセージを送信するルータのために、HELLO_INTERVAL（したがってもREFRESH_INTERVAL）を十分に大きく設定されてください、すなわち、応答HELLOメッセージは、常にこの値よりも短い周期で期待されるようになっています。
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ホップネイバーが最新の2ホップ近傍情報を維持できるように、1つのMANETインタフェース上で観察された変化は、他のMANETインタフェースで報告されていることを確実にします。）
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：これらのHELLOメッセージの受信者がそのリンクセットからこの情報の除去を促進することができ、HELLOメッセージに失われたとして、元1ホップネイバーのネットワークアドレスのこのMANETインタフェース上の広告の期間、。加速情報の除去が必要とされない場合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：VALIDITY_TIMEメッセージTLVに値としては、このMANETインターフェイス上のすべてのHELLOメッセージに含まれています。次いで、それを受信ルータの情報ベースにそのHELLOメッセージから取り出され、記録された情報の有効性を示すために、そのようなHelloメッセージを受信する各ルータが使用されます。
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上の制約がREFRESH_INTERVALではなく、HELLO_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.
HELLOメッセージが失われる可能性がある場合は、O、その後、両方のパラメータがREFRESH_INTERVALよりもかなり大きいはずです。
o H_HOLD_TIME MUST be representable as described in [RFC5497].
[RFC5497]に記載されているようにO H_HOLD_TIMEは表現していなければなりません。
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
0 <= HYST_REJECT <= HYST_ACCEPT <= 1
o 0 <= INITIAL_QUALITY <= 1.
0 <= INITIAL_QUALITY <= 1。
o If link quality is not updated, then INITIAL_QUALITY >= HYST_ACCEPT.
Oリンク品質が更新されていない場合は、INITIAL_QUALITY> = HYST_ACCEPT。
o If INITIAL_QUALITY >= HYST_ACCEPT, then INITIAL_PENDING := false.
INITIAL_QUALITY> = HYST_ACCEPT場合はO、そしてINITIAL_PENDING：= falseを。
o If INITIAL_QUALITY < HYST_REJECT, then INITIAL_PENDING := true.
O INITIAL_QUALITY <HYST_REJECTは、その後、INITIAL_PENDING場合：=真。
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：このMANETインタフェースに定期ハロー生成されたメッセージのために[RFC5148]で使用MAXJITTERの値を表します。
HT_MAXJITTER: Represents the value of MAXJITTER used in [RFC5148] for externally triggered HELLO messages on this MANET interface.
HT_MAXJITTERは：外部このMANETインタフェースにHELLOメッセージをトリガするために[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メッセージの受信者はその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_INTERVALに従って生成されなければならない場合。後続のHELLOメッセージの数が、以前より短く、HELLO_INTERVALに従って生成されてもよい（しかし、現在のパラメータに応じて時間を含まなければなりません）。これは、これらの以前の約束の期限が切れてしまうまで、将来のHELLOメッセージをタイムリーに伝達するなど、「約束」が保持されることが保証されます。
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.
MANETインターフェイスのHELLO_INTERVALが減少する場合、O、このMANETインタフェース上ハロー次のメッセージはHELLO_INTERVAL、短く、この電流に応じて生成されなければなりません。
REFRESH_INTERVAL
REFRESH_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.
MANETインタフェース増加のためREFRESH_INTERVAL場合はO、その後のHELLOメッセージの内容は、REFRESH_INTERVALの古い値の仕様は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.
MANETインターフェイスのREFRESH_INTERVALが減少する場合、O、REFRESH_INTERVALの仕様が変化した時点から成立しているために、そのMANETインタフェースにHELLOメッセージの生成を再スケジュールする必要があるかもしれません。
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.
HYST_ACCEPTまたはHYST_REJECT変更された場合、O、その後、リンク品質の変化のための適切なアクションは、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.
L_HOLD_TIMEが変化した場合、O、その後、全ての関連リンクタプルの有効期限時間を変更する必要があります。
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.
N_HOLD_TIMEが変更された場合、O、その後、関連するすべての失われた近隣の満了時間は、タプルを変更する必要があります。
HP_MAXJITTER
HP_MAXJITTER
o If HP_MAXJITTER changes, then the periodic HELLO message schedule on this MANET interface MAY be changed.
HP_MAXJITTERが変更された場合、O、このMANETインタフェース上の周期的なHELLOメッセージスケジュールを変更してもよいです。
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インタフェースにHELLOメッセージをトリガーは再スケジュールされるかもしれません。
The constant C (time granularity) is used as specified in [RFC5497].
[RFC5497]で指定されるように定数C（時間粒度）が使用されます。
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を同じアドレスがMANETインタフェースを（次の条件も適用される場合、またはそれ以上）の非MANETが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.
これら二つのMANETインタフェースがに通信できない場合、O同じアドレスから、2つ（またはそれ以上の各場合はペアこの条件を満たす）MANETインターフェイスに割り当てることができる、または別のルータの任意の他のMANETインターフェースから1へと一つ。
A router's Local Interface Set records its local interfaces. It consists of Local Interface Tuples, one per interface:
ルータのローカル・インタフェースの設定は、そのローカルインターフェイスを記録します。これは、ローカル・インタフェースタプル、インターフェイスごとに1つから構成されています。
(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.
ルータは、そのMANETインタフェースのそれぞれのためのインターフェース情報ベースを維持します。これは、最初のホップとして、これらのリンクを使用して、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.
現在時刻がその時間以上であれば、時間を指定する要素が期限切れになったと考えられています。有効期限が切れたときに、ほとんどのタプルに存在するそのような要素は、タプル自体が期限切れとみなされ、除去されなければならないことを、示しています。指定されているような時間要素を持っていないタプルは、他の回で除去されます。たとえば、すべてのリンクタプルを対応するタプルが削除されたネイバーが削除されました。
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メッセージ交換により得られ、リンク品質を使用するなど、L_status示されます。 L_statusは値PENDING、HEARD、SYMMETRIC、およびLOSTを取ることができます。値LOST、SYMMETRIC、およびHEARDは、セクション18.5で定義されています。値PENDINGがHELLOメッセージで使用されることはない、それだけルータによって局所的に使用され、LOST、SYMMETRIC、及びHEARDは異なる任意の値が使用されてもよいです。
L_status is defined by:
L_statusは以下のように定義されています。
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。
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ホップネイバーのアドレス、およびこれらの対称2ホップネイバーが到達できる対称1ホップネイバーに左右対称のリンクを記録します。これは、2ホップタプル、対称の2ホップネイバーの単一のネットワークアドレスを表すそれぞれ、対称の1ホップ隣人の単一MANETインタフェースから成ります。
(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ホップ隣人に（任意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ホップ隣人から構成されています。
(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:
失われたとして、最近、対称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.
ルータは、これらの変化に応じて、HELLOメッセージを送信してもよいです。
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インタフェースである場合は、最初は空のインタフェース情報ベースは、この新しいMANETインターフェイスのために作成されなければなりません。 9.3節のアクションは、この追加インタフェースの各ネットワークアドレスに注意しなければなりません。 HELLOメッセージは、すべてのMANETのインターフェイス上で送信され得ることは、Aである場合、それは新しいインターフェイス上で送信されてください
MANET interface. If using scheduled messages, then a message schedule MUST be established on the new MANET interface.
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:
そのローカルインタフェースタプルのI_local_iface_addr_list内の各ネットワークアドレス（以下、除去アドレス）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：=現在の時刻+ I_HOLD_TIME。
4. If the interface to be removed is a MANET interface (i.e., with I_manet = true), then:
4.インタフェースが削除される場合、（すなわち、真I_manet =付き）MANETインタフェースです。
1. Remove the Interface Information Base for that MANET
interface;
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.
インターフェイスを除去し、これらの変更を行った後、HELLOメッセージは、すべての残りのMANETのインターフェイス上で送信され得ます。
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:
ネットワークアドレスは、インターフェイスに追加された場合、これは適切なI_local_iface_addr_listにネットワークアドレスを添加することによって示されています。次の変更は、情報ベースに作らなければなりません：
1. Remove any Removed Interface Address Tuple whose IR_local_iface_addr is the added network address.
1.そのIR_local_iface_addr追加のネットワークアドレスである取り外したインタフェースアドレスタプルを削除します。
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追加ネットワークアドレスと重複ネットワークアドレスを含む任意の隣接タプルを削除します。
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 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.
ネットワークアドレスを追加し、これらの変更を行った後、HELLOメッセージは、すべてのMANETのインターフェイス上で送信され得ます。
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で指定されるように、そのインターフェイスを削除します。
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：=現在の時刻+ I_HOLD_TIME。
After removing the network address and making these changes, a HELLO message MAY be sent on all MANET interfaces.
ネットワークアドレスを削除し、これらの変更を行った後、HELLOメッセージは、すべての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メッセージが存在する場合、値1を持つ必要があり、<MSGホップリミット>、すなわち、転送されてはいけません。
o HELLO messages MAY be included in multi-message packets as specified in [RFC5444].
[RFC5444]で指定されるように、O、HELLOメッセージは、マルチメッセージ・パケットに含まれるかもしれ。
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]に準拠していないHELLOメッセージは処理されずに廃棄されなければなりません。 HELLOメッセージはまた、セクション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と、これらのタイプの唯一の定義されていますが、種類拡張子= 0なしで、このプロトコルでは無視されます。この明細書における全ての参考文献は、例えば、タイプ= LINK_STATUSとアドレスブロックTLVは、タイプ= LINK_STATUSとタイプ拡張子= 0のアドレスブロックTLVを指すと考えられるべきです。
A HELLO message MUST contain:
HELLOメッセージが含まれていなければなりません：
o Exactly one VALIDITY_TIME Message TLV as specified in [RFC5497], representing H_HOLD_TIME for the transmitting MANET interface.
Oちょうど1 VALIDITY_TIMEメッセージTLV [RFC5497]で指定されるように、送信MANETインターフェイスのH_HOLD_TIMEを表します。
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:
周期的なタイマーに送信HELLOメッセージを含むべきであり、そうでなければ（すなわち、任意の情報ベースの変化に応じて、特に、他の理由のために送信）を含んでいてもよいです。
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ちょうど1 INTERVAL_TIMEメッセージTLV [RFC5497]で指定されるように、送信MANETインターフェイスのHELLO_INTERVALを表します。ゼロを表す、無限回[RFC5497]に含まれるオプションを使用してはいけません。
A HELLO message MAY contain:
HELLOメッセージが含まれる場合があります。
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.
一個の以上のアドレスブロック、他のアドレスブロックTLVを含むかもしれ関連付けられたアドレスブロックTLVブロック、各O。
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]を参照）のアドレスオブジェクトとして表現されなければならないし、次の許可例外を除いて、すべてのHELLO生成されるメッセージでアドレスブロックに含ま：
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.
HELLOメッセージが送信されるにMANETインタフェースは最大プレフィックス長（IPv6の場合、すなわち、/ IPv4の32/128）を有する単一のアドレスがある場合、O、そのアドレスは、任意のアドレスブロックに含まれているから省略されるかもしれませんこのアドレスは、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で定義されるように、タイプ= 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.
アドレスブロックは、一つに関連付けられているまたは表2に記載されているように、両方のブロックTLVをアドレスする（[RFC5444]）、その各々のアドレスオブジェクトとして表される現在または最近失われた1ホップ隣人のネットワークアドレスを含んでいてもよいです。
+--------------+---------+------------------------------------------+
| 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.
タイプ= LINK_STATUSとValue = SYMMETRIC又は値とアドレスブロックTLVは= LOSTはまた、タイプ= OTHER_NEIGHBと同じ値とアドレスブロックTLVの機能を実行します。同じアドレスオブジェクトは効率上の理由から推奨されているに関連付けられ、後者を含みます。タイプ= LINK_STATUSとValue = SYMMETRICとアドレスブロックTLVのタイプ= OTHER_NEIGHBと値とアドレスブロックTLV =同一のアドレスオブジェクトに関連付けられたLOSTと組み合わされる場合、後者は無視しなければならなくて、含めるべきではありません。付録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インタフェースは、このセクションの仕様に従ってHELLOメッセージを生成しなければなりません。 helloメッセージは、それぞれ独立しMANETインタフェース用に生成されます。ハローメッセージ生成及びスケジューリングは、MANETインタフェースが同じスケジュールを使用することができるが、その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.
周期的なHELLOメッセージを送信した場合、その後、MANETインタフェースにHELLOメッセージの送信後、別のHELLOメッセージはHELLO_INTERVALより大きくない間隔の後に同じMANETインタフェース上で送信されなければなりません。同じMANETインタフェース上の2つの連続したHELLOメッセージの送信は、第11.2.1項で述べたように除き、少なくともHELLO_MIN_INTERVALによって分離されなければなりません。
HELLO messages are generated independently on each MANET interface.
helloメッセージは、各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.
HELLOメッセージが送信されるインターフェイスは、最大プレフィックス長（すなわち、IPv4用/ 32、IPv6の/ 128）、そのアドレスを省略してもよいと単一のアドレスを持っている場合、O、このアドレスは以下のように含まれていることを条件とします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.
= THIS_IF：Oアドレスオブジェクトは、その後、値送信MANETインタフェースのネットワークアドレスを表す場合。
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を使用してのみつの値に関連付けられていることを奨励される：= LOCAL_IF。これは、値でなければならない：= 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]）として表され、そのMANETインターフェイスの各関連のパラメータREFRESH_INTERVALを尊重し、以下に従って、任意のHELLOメッセージに含まれることがあります。
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.
L_status = PENDINGとリンクタプルからのもの以外（すなわち、L_neighbor_iface_addr_listから）このMANETインタフェースのためのインタフェース情報ベースのリンクセットから1ホップ隣人のMANETインタフェースのOネットワーク・アドレス。
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).
このルータの近隣（すなわち、N_neighbor_addr_listから）情報ベースの隣接セットから対称の1ホップ隣接の他のネットワークアドレス、O。
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).
（すなわち、L_status = LOSTとL_neighbor_iface_addr_listから）このMANETインターフェイスのインターフェイス情報ベースのリンクセットからこのMANETインタフェースに接続された以前に対称または聞いた1ホップネイバーのMANETインタフェースのOネットワーク・アドレス。
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).
このルータの近隣（すなわち、NL_neighbor_addrから）情報ベースの失われた近隣セットから以前に対称の1ホップ隣人の他のネットワークアドレス、O。
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:
このMANETインタフェース用L_statusのリンクセット内のリンクタプルのL_neighbor_iface_addr_listに含まれるネットワークアドレスを表す各アドレスオブジェクト（以下、リンク先アドレス）1.！=係属中の関連するアドレスブロック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:
真N_symmetric =有する隣接タプルのN_neighbor_addr_listに含まれるネットワークアドレスを表し、それは既にタイプ= LINK_STATUSおよび値= SYMMETRICに関連付けられたアドレスブロックTLVに含まれていない各アドレスオブジェクト（以下、隣接アドレス）について2.関連付けられたアドレスブロックTLVと隣接ネットワークアドレスが含まれています。
o Type := OTHER_NEIGHB; AND
Oタイプ：= OTHER_NEIGHB。そして
o Value := SYMMETRIC.
O値：= SYMMETRIC。
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:
NL_neighbor_addr（以下ロストアドレス）が既にアドレスオブジェクトとして表され、含まれていない各ロスト隣接タプルに対して3は、関連付けられたアドレスブロックTLVでアドレスを失ったものが含まれます：
o Type := OTHER_NEIGHB; AND
Oタイプ：= OTHER_NEIGHB。そして
o Value := LOST.
O値：= LOST。
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.
最後のHELLOメッセージは、この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は、独立して含まれるか、または各HELLOメッセージから除外することができます。各そのようなアドレスブロックTLVは、MANETインタフェースのパラメータREFRESH_INTERVALに等しい長さの間隔ごとにそのMANETのインターフェイス上で送信されたハローメッセージ内のそのネットワークアドレスのアドレスオブジェクト表現に関連付け含まなければなりません。同じHELLOメッセージに含まれる同じアドレスオブジェクトに関連付けられたブロックの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メッセージで送信することができます。
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.
helloメッセージを転送してはならないので、メッセージ転送ジッタは、HELLOメッセージには適用されません。
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メッセージ生成がHELLOメッセージは、同じMANETインタフェース上の前ハローメッセージのHELLO_MIN_INTERVAL内に送信されないようにするために遅れている場合、[RFC5148]に記載されているように、次にHELLO_MIN_INTERVALは、最大縮小HP_MAXJITTERと、ジッタによって低減されるべきです。この場合、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.6に12.3節で指定されるようにそうでなければ、各受信され、有効なHELLOメッセージのために、受信ルータは適切なインタフェース情報ベース及びその隣接情報ベースを更新する必要があります。これらのアップデートは、それらが本明細書中で提示された順序で実行しなければなりません。変更は、セクション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を持つ唯一のTLVを考慮する。すべての参照は、例えば、タイプ= LINK_STATUSとのTLVは、Type = LINK_STATUSと種類拡張子= 0でTLVを参照してください。
A received HELLO message is invalid for processing by this router if any of the following conditions are true:
以下の条件のいずれかに該当する場合、受け取ったHELLOメッセージは、このルータによる処理のために無効です。
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メッセージは、1以外の値とのメッセージヘッダに<MSGホップリミット>フィールドを有しています。 （メッセージは<MSGホップリミット>フィールドを有する必要がないことに注意してください。）
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メッセージは、ゼロ以外の値とのメッセージヘッダに<MSGホップカウント>フィールドを有しています。 （メッセージは<MSG-ホップカウント>フィールドを持つ必要がないことに注意してください。）
o The message does not have a Message TLV with Type = VALIDITY_TIME in its Message TLV Block.
Oメッセージは、そのメッセージTLVブロックでタイプ= VALIDITY_TIMEでのメッセージTLVを持っていません。
o The message has more than one Message TLV with Type = VALIDITY_TIME in its Message TLV Block.
Oメッセージは、そのメッセージTLVブロックタイプを有する複数のメッセージTLV = VALIDITY_TIMEを有しています。
o The message has more than one Message TLV with Type = INTERVAL_TIME in its Message TLV Block.
Oメッセージは、そのメッセージTLVブロックでタイプ= 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をタイプ= LOCAL_IFと任意の単一値vようにvで任意のアドレスブロックTLV（複数可）を持っている！= THIS_IFとV！= OTHER_IF。
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（同じまたは異なるアドレスブロック内の同一のネットワークアドレスを表す異なるアドレス・オブジェクトを含む）任意のアドレスオブジェクトは、タイプ= LOCAL_IFで一つ以上のアドレスブロックTLV（S）によって複数の値に関連付けられます。
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型とアドレスブロックTLVに関連した任意のアドレスオブジェクト（以下、ローカルアドレス）= LOCAL_IFは、受信側ルータの現在または最近使用したネットワークアドレス（すなわち、ローカルアドレスは、ローカル・インタフェースの設定、または任意のいずれかのI_local_iface_addr_list内の任意のネットワークアドレスと重複するのかを表します取り外したインターフェイスアドレスセットでIR_local_iface_addr）。
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をタイプ= LINK_STATUSを持つ任意のアドレスブロックTLV（複数可）を持っている任意の単一の値を持つVように、V！= LOST、V！= SYMMETRIC、およびV！= HEARD。
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とタイプ= OTHER_NEIGHBを持つ任意のアドレスブロックTLV（s）は、このようなことVを持っている！= LOSTとV！= SYMMETRIC。
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（同じまたは異なるアドレスブロック内のアドレス・オブジェクトの異なるコピーを含む）任意のアドレスオブジェクトは、タイプ= LOCAL_IFでおよびType = LINK_STATUSとアドレスブロックTLVとアドレスブロック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（同じまたは異なるアドレスブロック内のアドレス・オブジェクトの異なるコピーを含む）任意のアドレスオブジェクトは、タイプ= LOCAL_IFでおよびType = OTHER_NEIGHBとアドレスブロックTLVとアドレスブロック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（同じまたは異なるアドレスブロック内のアドレス・オブジェクトの異なるコピーを含む）任意のアドレスオブジェクトは、タイプ= 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（同じまたは異なるアドレスブロック内のアドレス・オブジェクトの異なるコピーを含む）任意のアドレスオブジェクトは、タイプ= 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.
ルータは、このプロトコルによって検証できないHELLOメッセージの処理をHELLOメッセージの署名の検証を実行し、防止するために、セクション17に示唆されるようにセキュリティプロトコルを可能にするために、例えば、メッセージがひどく形成されていることを識別し、処理のために、したがって、無効のための追加的な理由を認識することができます。
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]で指定されるようにHELLOメッセージの= VALIDITY_TIMEタイプのメッセージTLVから計算されます。 （セクション12.1で指定され、HELLOメッセージに正確に一つのそのようなメッセージTLVが存在しなければならない、ということに注意してください。）本明細書で使用される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 I_local_iface_addr_listはHELLOメッセージを受信したMANETインタフェースに対応しています
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メッセージに含まれるアドレス・オブジェクトによって表されるネットワークアドレスの順序なしリストでありますタイプ= LOCAL_IFとValue = THIS_IFと。送信アドレス一覧が他の空の場合、送信アドレス一覧内のIPデータグラムの送信アドレスと同じアドレスを持つ最大プレフィックス長（IPv6の場合、すなわち、/ IPv4の32/128）を有する単一のネットワークアドレスが含まれていますHELLOメッセージが含まれていました。
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「ネイバーアドレス一覧」HELLOメッセージを生成したルータのすべてのインターフェイスのすべてのネットワーク・アドレスの順不同のリストである、すなわち、送信アドレス一覧で、プラスアドレスオブジェクトによって表されるネットワークアドレスが持つ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メッセージを発信側ルータではなく、近隣アドレスリストに含まれていないことをローカルとして報告されたこの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「失われたアドレス一覧は、」以前は対称であると考えられたネットワークアドレスを含む削除アドレス一覧のサブセットです。このリストは空として初期化されます。
On receiving a HELLO message, the router MUST update its Neighbor Set and populate the Removed Address List and Lost Address List:
HELLOメッセージを受信すると、ルータはその隣接セットを更新し、削除されたアドレス一覧と失われたアドレス一覧を移入しなければなりません：
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が近隣アドレスリストの任意のネットワークアドレスと重複する任意のネットワークアドレスが含まれているすべてのネイバータプル（以下、マッチング隣人タプル）を検索します。
o N_neighbor_addr_list := Neighbor Address List;
N_neighbor_addr_list O：=ネイバーアドレス一覧。
o N_symmetric := false.
O N_symmetric：= falseを。
1. If the matching Neighbor Tuple's N_neighbor_addr_list !=
Neighbor Address List, then:
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:
2. If N_symmetric = true, then add the removed address to the Lost Address List.
2. N_symmetric = trueが、その後、失われたアドレス一覧に、取り外したアドレスを追加する場合。
o N_neighbor_addr_list := Neighbor Address List.
N_neighbor_addr_list O：=ネイバーアドレス一覧。
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:
2. If N_symmetric = true, then add removed address to the Lost Address List.
2.真N_symmetric =場合は、失われたアドレス一覧に、取り外したアドレスを追加します。
2. Replace the matching Neighbor Tuples by a single Neighbor Tuple with:
2とシングル近隣タプルによってマッチング隣接タプルを置き換えます。
o N_neighbor_addr_list := Neighbor Address List;
N_neighbor_addr_list O：=ネイバーアドレス一覧。
o N_symmetric := false
O N_symmetric：=偽
On receiving a HELLO message, a router MUST update its Lost Neighbor Set:
HELLOメッセージを受信すると、ルータは、その失われた隣接セットを更新する必要があります。
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:
とNL_neighbor_addr =失われたアドレスとは失われた近隣タプルは、失わ隣接タプルを追加していない存在する場合、失われたアドレスリストに含まれる各ネットワークアドレス（以下ロストアドレス）について1.
o NL_neighbor_addr := lost address;
NL_neighbor_addr O：失われたアドレスを=。
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:
HELLOメッセージを受信すると、ルータはそのリンクセットを更新する必要があります。
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インターフェイスのためにそのリンクセットを更新する必要があります。
o L_neighbor_iface_addr_list contains one or more network
addresses in the Sending Address List.
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;
L_neighbor_iface_addr_list O：=エンプティ。
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;
L_lost O：= 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. 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:
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メッセージ内の任意の受信アドレスをタイプとアドレスブロックTLVに関連付けられている場合= LINK_STATUSとValue = LOST、その後：
o L_time := current time + L_HOLD_TIME.
O L_time：=現在の時刻+ L_HOLD_TIME。
3. L_HEARD_time := max(current time + validity time, L_SYM_time).
3. L_HEARD_time：= MAX（現在の時間+正当性時間、L_SYM_time）。
o L_time := max(L_time, L_HEARD_time).
O L_time：= MAX（L_time、L_HEARD_time）。
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 =アドレス一覧を送信するリンクタプルが、L_status = SYMMETRICを持っている場合は、次のようになります。
1. For each network address (henceforth 2-hop address) in an
Address Block of the HELLO message, where:
o a 2-hop address is not contained in the Neighbor Address
List;
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型= LINK_STATUSと値= 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ホップアドレス、
then create a 2-Hop Neighbor Tuple with:
次いで2ホップネイバータプルを作成します。
o N2_2hop_addr := 2-hop address.
O N2_2hop_addr：= 2ホップアドレス。
This 2-Hop Tuple (existing or new) is then modified as follows:
この2ホップタプル（既存または新規）次のように修正されます。
o N2_neighbor_iface_addr_list := Sending Address List;
N2_neighbor_iface_addr_list O：=アドレス一覧を送信します。
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 = OTHER_NEIGHB and Value = LOST;
O型= OTHER_NEIGHBと値= 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ホップアドレス。
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メッセージの処理から生じ得るか、またはそうでなければ生成することができる（例えば、タイマー又はリンク品質の変化の終了）。
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リンクタプルの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.
SYMMETRIC、またはリンクタプルからOリンクタプルの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リンクタプルの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_HEARD_timeからL_statusの変更が満了した場合、セクション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メッセージ（s）は、これらの変化のいずれかに応じて更新された情報を報告することがあります。
A router that transmits HELLO messages in response to such changes SHOULD transmit a HELLO message:
このような変化に応答して、HELLOメッセージを送信するルータは、HELLOメッセージを送信しなければなりません。
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).
ネイバーは、（付加または対称の1ホップ隣接の除去を含む）任意の1ホップ隣人の対称性の変化を指示するなどの変更を設定した場合、全てのMANETインターフェイスでO。
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それ以外の場合は、そのリンクセットそのような（保留中の考え以外の任意の1ホップ隣人の追加または除去を含む）の任意の1ホップ隣人のL_statusの変化を示すよう変更すべてのそれらのMANETインターフェイス上。
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:
N_neighbor_addr_list L_neighbor_iface_addr_listが含まれ、設定隣人タプルに対して1：
o N_symmetric := true.
O N_symmetric：=真。
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が対称ではありませんが、リンクタプルがすぐリンクタプルの作成は、このようなリンクタプルのL_statusことを原因と同じHELLOメッセージの後続の処理によって更新することができるように作成されることに注意してくださいSYMMETRICへの変更。）
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:
その後：
o N2_neighbor_iface_addr_list contains one or more network
addresses in L_neighbor_iface_addr_list;
are removed.
削除されます。
2. For the Neighbor Tuple whose N_neighbor_addr_list contains L_neighbor_iface_addr_list:
N_neighbor_addr_list L_neighbor_iface_addr_listが含まれている近隣のタプルに対して2：
1. If there are no remaining Link Tuples for any MANET interface
where:
o L_neighbor_iface_addr_list is contained in
N_neighbor_addr_list; AND
o L_status = SYMMETRIC;
Symmetrics = O L_status。
then modify the Neighbor Tuple by:
それまでに近隣タプルを変更します。
2. For each network address (henceforth neighbor address) in N_neighbor_addr_list, add a Lost Neighbor Tuple with:
N_neighbor_addr_list内の各ネットワークアドレス（以下、隣接アドレス）2.とロスト隣接タプルを追加します。
o NL_neighbor_addr := neighbor address;
O NL_neighbor_addr：=ネイバーアドレス。
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:
N_neighbor_addr_list L_neighbor_iface_addr_listが含まれている、任意のMANETインタフェースのためのリンクタプルが残っていない場合は近隣タプルに対して1：
o L_neighbor_iface_addr_list is contained in
N_neighbor_addr_list; AND
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.
リンク品質は、ルータがリンクであるとHEARDまたは対称とみなされるための候補ではない場合を決定するために、アカウントにメッセージ交換以外の考慮を取るできる機構です。このように、それは、「リンクの入場」のメカニズムです。
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.
リンクのリンク品質情報（例えば、アクセスを介してリンク層からノイズ比、パケット損失率、または他の情報を知らせるために）生成してローカルでのみ使用され、すなわち、シグナリングに含まれていない場合、ルータは、かどうかを相互運用することができるされ、それら同じ、異なる、または全く、リンク品質情報を使用しています。リンクの品質情報は、いずれかの間隔ゼロで正規化された、無次元図形として指定含め、より良いリンク品質を示す高い値です。
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).
INITIAL_QUALITY> = HYST_REJECT O（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値は、そのリンクタプルのフラグL_pendingとL_lostを設定するために、二つの閾値、HYST_ACCEPTとHYST_REJECTと組み合わせて使用されます。セクション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.
HYST_REJECTは<= L_quality <HYST_ACCEPTが承認または拒否することができるしているいずれかのリンクは、（いずれも、パラメータINITIAL_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:
L_qualityが許容されるまで、ルータはどのような状態で近接インターフェイスを広告しません○：
o If INITIAL_PENDING = true, then the link is advertised when link L_quality >= HYST_ACCEPT.
INITIAL_PENDING = trueの場合、O、その後、リンクをする際、リンク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.
そのL_qualityがHYST_REJECTを下回るまでL_pending = falseを宣伝されているリンク、O。
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.
リンクはL_pending =偽とL_quality <HYST_REJECTを持っている場合は、O、リンクが失われ、そのように宣伝されています。このリンクはL_quality> = HYST_ACCEPTまで候補HEARDもしくはSYMMETRICリンクとして見直されていません。
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メッセージの交換に応じて聞いて、SYMMETRICとしてアドバタイズまたは失われる可能性があります。
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 =偽とINITIAL_QUALITY <HYST_REJECT。または
o INITIAL_PENDING = true and INITIAL_QUALITY >= HYST_ACCEPT.
真INITIAL_PENDING =とINITIAL_QUALITY> = HYST_ACCEPT O。
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、対応するリンクタプルはによって変更された場合：
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、それに対応するリンクタプルがで修正されました！
o L_lost := true;
L_lost O：=はtrue。
o L_time := min(L_time, current time + L_HOLD_TIME).
O L_time：=分（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メッセージを含むパケットの受信時に更新される場合、次いでL_quality（セクション12に記載のHELLOメッセージの処理前に更新しなければならない場合、HELLOメッセージの受信、又はそれを含むパケットは、リンクタプルを作成し、その後、リンクタプルが適宜更新L_quality値ではなく、L_qualityで作成する必要があります。= INITIAL_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]で定義されるように制御パケットを受信したとき、次にリンク品質は、Helloメッセージを含むか否か、更新することができます。リンク品質は、その後、例えば、最後のNは、リンク上のM個の制御パケットのうち、受信されたかどうかに基づいてもよいし、「漏洩積分器」トラッキングパケット受信及び損失を使用することができます。
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.
HELLOメッセージのOの領収書または損失。 HELLOメッセージとの間の最大間隔が既知である場合（このようなタイプのメッセージTLVのhelloメッセージに含めることなどによって：= INTERVAL_TIME [RFC5497]で定義されるように）、次いで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
HELLO_MIN_INTERVAL O：= HELLO_INTERVAL / 4
o REFRESH_INTERVAL := HELLO_INTERVAL
O REFRESH_INTERVAL：= HELLO_INTERVAL
o H_HOLD_TIME := 3 x REFRESH_INTERVAL
H_HOLD_TIME O：= 3×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 INITIAL_QUALITY := 1
O INITIAL_QUALITY：= 1
o INITIAL_PENDING := false
O INITIAL_PENDING：=偽
o HP_MAXJITTER := HELLO_INTERVAL/4
HP_MAXJITTER O：= HELLO_INTERVAL / 4
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]で指定された情報（例えば、TLVを）を追加する前に、それが任意のMANETインタフェースを介して送信されるまで送信HELLOメッセージにアクセスし、スルー。これは、例えば、にTLVを追加することにより、HELLOメッセージに中継選択情報を挿入可能にするためにメッセージに暗号署名を含むTLVを追加し、又はあると、セクション17で示唆したように、セキュリティプロトコルを可能にすることができます前それに発信ハローメッセージが送信されます。
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着信HELLOメッセージにアクセスし、そして潜在的にこのプロトコルによって処理の前に、それを廃棄スルー。このプロトコルによって検証できないHELLOメッセージの処理をHELLOメッセージの署名の検証を実行し、防止するために、セクション17で示唆したように、これは、例えば、セキュリティプロトコルを可能にすることができます。
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それは完全にこのプロトコルによって処理された後、着信HELLOメッセージへのアクセスを通じ。これは、特に、適切な更新は、このプロトコルで情報ベースに記録された後、適切なの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 HELLOメッセージは、特定の時間に発生することを要求スルー。その場合に、ハローメッセージ生成は、依然として付録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.
HELLOメッセージのアドレスオブジェクトは、それに関連付けられたアドレスブロックの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メッセージに情報を追加する必要があるかもしれません。これは、既に本明細書に含まオブジェクトに対処する（LOCAL_IF、OTHER_NEIGHB、又はLINK_STATUS以外のタイプの）TLVを関連付けるの形態であってもよいです。
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メッセージ生成のおかげで既に存在するブロックのアドレスに加算することができる、または新しいアドレスブロックに表示されてもよいです。どちらの場合も、次のことが認められなければなりません：
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挿入されたアドレスは、Type 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:
非公式に言えば、ブロックのTLVは、アドレスブロック内のアドレスオブジェクトのセマンティクスを定義するアドレス。アドレスブロック内のアドレスオブジェクトが関連付けられている任意のアドレスブロック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は、無視されなければならない任意のアドレスに関連付けられていないアドレスブロック内のアドレスオブジェクト。 HELLOメッセージ内の関連アドレスブロック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.
いくつかの場合において、本明細書中で定義されたプロトコルと対話プロトコルは、HELLOメッセージを処理するために、どのハローメッセージを廃棄するかを認識する必要があるかもしれません。そのようなメッセージは、メッセージTLVを含めることによって、または（例えば、アドレス範囲など）管理構成を認識を通じて、例えば、適当に識別可能であることを保証するために、そのプロトコルの責任です。このプロトコルと相互作用するようなプロトコルは、メッセージを廃棄するための追加の理由を認識することにより、このような相互作用を指定してもよいです。セクション17で示唆したように、これは、例えば、暗号化署名を含むメッセージTLVを運ばないメッセージを廃棄するセキュリティプロトコルであるかもしれません。
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ホップ近隣を記述する情報を取得できるようにすることです。これは、隣接ルータ間でHELLOメッセージ交換を介して獲得されます。この情報は、ルータの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.
何らかの理由で、ルータは、悪意や誤動作か、無効なHELLOメッセージを送信した場合、誤った情報を他のルータの情報ベースに記録することができます。このプロトコル仕様では、しかし、情報の不正確の正確な結果は、これらの情報ベースの使用に依存付録Bで制約を維持する所定の処理を介して情報ベースに含まれているから、一貫性のない情報を防ぐず、従って反映されるべきですこの近隣発見プロトコルによって提供される情報を使用するプロトコルの仕様です。
This section, therefore, firstly outlines the ways in which correctly formed, but still invalid, HELLO messages may appear, in Section 17.1.
このセクションでは、そのためには、まず正確に形成する方法の概要を説明し、それでも無効、helloメッセージは、セクション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メッセージの注入は、多くの方法で防止することができます。例えば、ネットワークが厳しく規制されているアクセスするためのサイトで展開され、場合、ネットワークへの物理アクセスと接近が防止されるように、その後、ハロー無効なメッセージを注入する悪質なルータから保護するために、更なるセキュリティメカニズムが必要とされないことがあります。ネットワークが形成されたリンク層が適切な機密性、認証、完全性を提供する場合も同様に、これは、所与の配備のために、適切盗聴者への情報の開示から保護するのに十分で、かつ悪意のあるルータに対して、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件のサイズのセキュリティはすべてに合う」というケースではないこと、である上記の議論から、次の。さまざまな展開が異なる要件を有することができます。例えば、低値センサーネットワークの展開で、シンプルなメッセージ認証コードと共有対称鍵を使用して認証が十分であり、それを超えた何かが実行可能であることをあまりにも多くの計算資源を必要とするかもしれません。逆に、で、例えば、検証コミュニティネットワークだけでなく、HELLOメッセージの発信者はなく、証明するために必要とされる発信者の正確な身元、「右キーを持っている」と計算リソースを作るために利用可能であり得ることそのような要件可能。
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.
正確に形成され、まだ無効、ハローメッセージには、次のいずれかの形式を取ってもよいです。アドレスブロックに存在するか又は存在しないアドレスオブジェクトは、それ自体で問題が発生しないことに注意してください。これは、問題を引き起こし関連する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メッセージを送信するルータのインタフェースのアドレスに対応していない関連LOCAL_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メッセージが伝送されるMANETインタフェースのみローカルインターフェース・ネットワーク・アドレスの許可省略以外（HELLOメッセージを送信するルータのインターフェイスを、ネットワークアドレス、またはそれらに関連するLOCAL_IFアドレスブロックTLVを省略してもよいです、その場合は）。
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メッセージが誤ってそれらがHELLOメッセージが伝送されるMANETインタフェースに関連付けられている間違っているかどうかを示す、1つまたは複数のローカルインタフェースのネットワークアドレスに関連付けられたLOCAL_IFアドレスブロックTLV値を指定することができます。
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.
一貫して存在しないLINK_STATUSアドレスブロックTLV O、不正確であるか、HELLOメッセージが伝送される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ホップ隣人からのリンクの状態（LOST、対称またはHEARD）を示すことができるアドレス。
o The Value of an OTHER_NEIGHB Address Block TLV may incorrectly indicate the status (LOST or SYMMETRIC) of a symmetric 1-hop neighbor.
OTHER_NEIGHBアドレスの値Oブロック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]のセキュリティ提案は、このプロトコルに適用することができます。暗号署名のいずれかの形式を確認するために失敗すると、HELLOメッセージが処理されずに拒否させなければなりません。
The following simplification of the suggestions for end-to-end authentication for integrity in [RFC5444] may be applied to HELLO messages:
[RFC5444]で整合性のためのエンドツーエンド認証のための提案を以下の簡略化は、HELLOメッセージに適用することができます。
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のホップカウント>と<MSGホップリミット>のいずれか省略されているか、常に値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：ハローメッセージタイプ固有のメッセージ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：ハローメッセージタイプ固有のアドレスブロック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の範囲で配分してきました。表6,7に指定され、かつこれらのアドレスブロックのTLVの8仕様は、セクション18.5で定義された値の定数で、10.1.1項である。として三つの新しいタイプの拡張レジストリは割り当てて、作成されています
+----------+------+-----------+------------------------+------------+
| 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：LINK_STATUS：ブロックTLVタイプの割り当てアドレス
+--------------+------+-----------+--------------------+------------+
| 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 LOST：= 0
o SYMMETRIC := 1
OのSYMMETRIC：= 1
o HEARD := 2
O HEARD：= 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 LOST：= 0 O SYMMETRIC：= 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、USA、<adamson@itd.nrl.navy.mil>
o Cedric Adjih, INRIA, France, <Cedric.Adjih@inria.fr>
OセドリックAdjih、INRIA、フランス、<Cedric.Adjih@inria.fr>
o Thomas Heide Clausen, LIX, France, <T.Clausen@computer.org>
Oトーマス・ハイデクラウゼン、LIX、フランス、<T.Clausen@computer.org>
o Justin Dean, NRL, USA, <jdean@itd.nrl.navy.mil>
Oジャスティン・ディーン、NRL、USA、<jdean@itd.nrl.navy.mil>
o Christopher Dearlove, BAE Systems ATC, UK, <chris.dearlove@baesystems.com>
OクリストファーDearlove、BAEシステムズATC、英国、<chris.dearlove@baesystems.com>
o Philippe Jacquet, INRIA, France, <Philippe.Jacquet@inria.fr>
Oフィリップジャケ、INRIA、フランス、<Philippe.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システムズ）、ウルリッヒHerberg（LIX）、佐藤弘樹（日立）ジョー・Macker：著者は感謝の仕様とそのコンポーネント（アルファベット順に記載）に強烈な技術的な議論、早期のレビューやコメントのために以下の方々に感謝します（NRL）、チャールズE.パーキンス（WiChorus）、ローランViennot（INRIA）、及び全体IETF MANETワーキンググループ。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.アダムソン、RFC 5148、2008年2月 "モバイルアドホックネットワーク（MANET）におけるジッタの考慮事項"。
[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.、ディーン、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]クラウゼン、T.とC. Dearlove、 "アドホックネットワークにおけるマルチバリュー時刻を表す（アドホックネットワークにおける）"、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]コルソン、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]クラウゼン、T.およびP.ジャケ、 "最適化されたリンクステートルーティングプロトコル（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.、ジャケ、P.、グエン、D.、およびT.クラウゼン、 "アドホックネットワークのためのOSPFマルチリレー（MPR）拡張"、RFC 5449、2009年2月。
Appendix A. Address Block TLV Combinations
付録A.アドレスブロックTLVの組み合わせ
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.
ハロー1ホップネイバーのネットワークアドレスはアドレスブロックで、かつ関連するアドレスブロックのTLVに含まれてもよい項11の指定でメッセージを生成するアルゴリズム。これらは、ブロックのTLVはタイプ= LINK_STATUSまたはタイプ= OTHER_NEIGHBを持っている、またはその両方かもしれアドレス。タイプ= LINK_STATUSは、3つの値（値=聞いて、値= SYMMETRIC、または値= LOST）を有し、そしてTYPE = OTHER_NEIGHBのブロックのTLVに対処することができるとブロックTLVを対処する2つの可能な値（値= SYMMETRICまたは値= LOST）を有していてもよいです。両方が同じネットワークアドレスに関連付けられているブロックTLVをアドレスするとき、これらの特定の組み合わせのみが、ブロックTLV値が必要とされるアドレス、及びこれらの組み合わせが表9に示されている第11のアルゴリズムによって生成された唯一の組み合わせです。
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の細胞を生成している可能性のある組み合わせが正しく解析され、セクション12でアルゴリズムによって解釈され、セクション11が、内アルゴリズムによって生成されていない組合せを示す示します。 「いいえ*」で標識された細胞は、実際には矛盾している、それがタイプ= 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とOTHER_NEIGHB TLVの組み合わせ
Appendix B. Constraints
付録B.制約
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.
I_manet = trueの場合、対応するMANETインタフェースが常にMANETの別個のセットと通信することが知られていない限り、O、次いでI_local_iface_addr_listは真I_manet =、を有する他の任意のローカルインタフェースタプルのI_local_iface_addr_listにおける任意のネットワークアドレスと重複任意のネットワークアドレスを含んではいけません他のルータのインターフェイス。
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は、任意のローカル・インタフェースタプルのI_local_iface_addr_listまたは取り外したインターフェイスアドレスのタプルの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.
L_HEARD_timeの有効期限が切れていない場合は、O、その後、その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は保留中またはLOSTなければならない場合。
o L_pending MUST NOT be set to true if it is currently false.
それが現在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は、任意のローカル・インタフェースタプルの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:
N_symmetricが= trueの場合、O、次いで一個の以上のリンクタプルがなければなりません。
o L_neighbor_iface_addr_list contained in N_neighbor_addr_list; AND
N_neighbor_addr_listに含まO L_neighbor_iface_addr_list。そして
o L_status = SYMMETRIC.
Symmetrics = O L_status。
o If N_symmetric is = false, then there MUST be one or more Link Tuples with:
N_symmetricが= falseの場合、O、次いで一個の以上のリンクタプルがなければなりません。
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 = SYMMETRICを持ってはいけません。少なくとも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 =との任意の近隣タプルの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
L_neighbor_iface_addr_list = N2_neighbor_iface_addr_list O。そして
o L_status = SYMMETRIC.
Symmetrics = 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は、任意のローカル・インタフェースタプルの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中であってはなりません。
Appendix C. HELLO Message Example
付録C.ハローメッセージの例
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]で有効にメッセージヘッダ・オプションとアドレスエンコーディングの任意の組み合わせをサポートします。その結果、すべてのHELLOメッセージがどのように見えるかを表すための単一の方法はありません。この付録では、同様の内容を有する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メッセージの4ビットのメッセージフラグ（MF）フィールド、メッセージヘッダは、ホップリミット、ホップカウント、およびメッセージシーケンス番号フィールドを含んでいることを示す値7を有しています。その4ビットメッセージのアドレス長（MAL）フィールドは、4つのオクテットの長さを有し、ここで、メッセージ内のアドレスを示すのIPv4アドレスである、値3を有しています。 1のホップリミットと全体的なメッセージの長さは45オクテットである0のホップ数と、送信されたようなメッセージです。
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
メッセージはタイプVALIDITY_TIMEとINTERVAL_TIMEの2つのメッセージのTLVを含むコンテンツ長8つのオクテットとメッセージTLVブロックを含みます。それぞれは、それぞれの値を有することを示す、フラグオクテット（MTLVF）値16を持つメッセージTLVを使用し、それぞれの値を有します
Length of 1 octet. The Values included are time codes (as defined in [RFC5497]) representing the parameters H_HOLD_TIME and HELLO_INTERVAL, respectively.
1つのオクテットの長さ。含まれる値は、それぞれ、パラメータ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つのオクテットのヘッドの長さ（中間4にミッド0）1つのオクテットそれぞれのアドレス中間セクションを示しています。
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を含みます。最初のインデックス0で、単一アドレスことを示すLOCAL_IFアドレスフラグオクテットとブロックTLV（ATLVF）値80である（すなわち、アドレス先頭：ミッド0）このルータの単一のローカルインタフェースのアドレスである（1つのオクテット値THIS_IF）は、このアドレスは、このインターフェイスであることを示しています。第二は、フラグオクテット（ATLVF）4にインデックス1でアドレスをカバーする単一の多値アドレスブロックTLVに報告されたすべてのネイバーのリンク状態値を指定する値52、包括的でブロックTLVアドレスLINK_STATUSあります。 4つのオクテットのアドレスブロックTLV値の長さは、アドレスごとに値ごとに1つのオクテットを示しています。第一及び第二聞いて、第三のSYMMETRIC、及び第四のLOST：最後の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:
この例は、例示目的のためであることに注意してください。重要な情報は、29個のオクテット（ローカルインタフェースアドレスは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（16進数64）のタイムコードをもたらします。
Appendix D. Flow and Congestion Control
付録D.フローおよび輻輳制御
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ホップ隣接の大きさに比例します。 helloメッセージを転送してはなりません。
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.
ルータは、そのMANETインタフェースのそれぞれにHELLOメッセージ中のその1ホップ隣接少なくとも各REFRESH_INTERVAL報告しなければなりません。これは、このプロトコルを使用するネットワーク内の各ルータによって生成される制御トラフィックに関する下限を置きます。
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インタフェース上で送信された二つの連続HELLOメッセージは、少なくともHELLO_MIN_INTERVALによって分離されていることを確認しなければなりません。 （ジッターを使用する場合、これはHELLO_MIN_INTERVALの平均最小値まで減少させることができる - 。HP_MAXJITTER / 2）となり、これは、このプロトコルを採用するネットワーク内の各ルータによって生成された制御トラフィックの上限を置きます。
Appendix E. Interval and Timer Illustrations
付録E.間隔とタイマーイラスト
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]で定義されるように、図示されていません。）
E.1. HELLO Message Generation Timing
E.1。ハローメッセージ発生タイミング
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メッセージスケジュールを示します。ルータは、HELLOメッセージ各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.
ルータは、パラメータH_HOLD_TIME、HELLOメッセージで受信した情報がルータを受信することによって有効とみなされるべき期間をコードする、各HELLOメッセージでVALIDITY_TIME TLVを含みます。 HELLOメッセージで受信した情報を記録する際に受信ルータは、各々がそれぞれのネットワークアドレスに対応する2ホップタプルのそれらの対応するリンクタプル、及びN2_timeのL_HEARD_time、L_SYM_timeとL_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は、ルータは、追加のHELLOメッセージを送信することにより、より頻繁に、それ自身の存在を通知ここで、図1と同様のメッセージスケジュールを示します。 helloメッセージはまだHELLO_INTERVALの新しい値によって定義された間隔で減少し、定期的に送信されます。しかし、REFRESH_INTERVALが減少していません。これらのhelloメッセージに含まれる各1ホップネイバーのネットワークアドレスは、各REFRESH_INTERVAL内に一度だけ宣伝される必要があります。従って、原因HELLO_INTERVALの減少値に追加のHELLOメッセージは、したがって、空であってもよいです。 （これは、1ホップネイバーのネットワークアドレスのみ許可さ分布ではなく、それらは、例えば、交互に、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.
helloメッセージは、イベントに応答して送信することができます。ルータによって2つの連続したHELLOメッセージの送信間の最小間隔は、HELLOメッセージ放出速度の上限を設定し、HELLO_MIN_INTERVALあります。したがって、各HELLOメッセージの送信のために、ルータは次のHELLOメッセージの送信前に少なくともHELLO_MIN_INTERVALを待たなければなりません。同様に、2つの連続したHELLOメッセージの送信間の最大間隔は、メッセージ送信レートに下限を設定し、HELLO_INTERVALあります。したがって、各HELLOメッセージの送信のために、ルータは次のHELLOメッセージの送信が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メッセージで、新たな1ホップ隣人のネットワークアドレスは、最後のHELLOメッセージを送信してから発生した変更を反映して、添加されます。ハローメッセージは、可能な限り迅速に、これらの変更を通知するために、最大許容レートで送信されます。
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と同じ例を示しており、唯一の必要なネットワークアドレスを含む部分HELLOメッセージを示します。
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: |---|
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：ハローメッセージ生成間隔
E.2. HELLO Message Processing Timing
E.2。ハローメッセージ処理のタイミング
Figure 6 illustrates the Link Set timers when receiving a HELLO message not including the network address of the receiving MANET interface.
受信MANETインタフェースのネットワークアドレスを含まないHelloメッセージを受信した場合図6は、リンクセットのタイマーを示します。
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は、図6に示す受信HELLOメッセージに続いて、ルータはリンクステータス= HEARD（又はSYM）と受信インタフェースのネットワークアドレス（A）を含むHelloメッセージを受信した場合、リンクセットタイマーを示します。
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に示す受信HELLOメッセージに続いて、ルータはリンクステータス= LOSTと受信インタフェースのネットワークアドレス（A）を含むHelloメッセージを受信した場合、リンクセットタイマーを示します。
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：ハローメッセージ処理：ネットワークが失われたアドレス
E.3. Other HELLO Message Timing
E.3。その他のHELLOメッセージのタイミング
There are three other timing parameters that are used by a router to control HELLO message generation and processing.
HELLOメッセージの生成および処理を制御するためにルータにより使用される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は、持続期間L_HOLD_TIMEと、以前の間に適切なネットワーク・アドレスを時間を示していないが、もはや、このMANETインタフェースによって接続されるように対称の1ホップ隣人は、これにHELLOメッセージでLINK_STATUS TLVを使用して、LOSTとして宣伝されていますこのように1ホップネイバーがそれに応じてそのリンクセットを更新することを可能にするMANETインタフェース。
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は、継続時間N_HOLD_TIMEと、以前の間にすべてのネットワーク・アドレスを時間を示していないが、もはや、対称の1ホップ隣人も使用報告されていない場合（OTHER_NEIGHB TLVを使用して、すべてのMANETインターフェイスにhelloメッセージで失わとして宣伝されていますLINK_STATUS TLV）ので、その2ホップに応じて設定し更新するために、他のすべての対称の1ホップ隣人を可能にします。
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は、その間に、以前、期間I_HOLD_TIMEと、時間を示していないが、もはや使用するローカルインタフェースのネットワークアドレスは、ルータが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：ローカル・インタフェースを削除ネットワークアドレス
Appendix F. Topology Pictures
付録F.トポロジの写真
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.
この付録では、物理的なトポロジの様々な例を示し、ならびにこれらを論理的にこの表現は、NHDPが稼働してきた後にAさんの様々な情報ベース内に含まれることになる情報の複合体であるルータAの観点からNHDPによって記録されていますか状態が収束するのに十分に長い時間のために。
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.
この付録で与えられた例は網羅されないが、物理的なMANETトポロジの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.
提示された例トポロジは、これらの各ルータは、1つのまたは2つの異なるインターフェイス、示される「上部」及び「底部」を有する3つの物理ルータA、B、およびCを含みます。各インターフェイスは、1つのまたは2つのアドレスを有し、インターフェイスのペア間の対称的な接続を線で接続され、これらにより示されています。
In all examples, the topology is described as it is recorded by NHDP in router A.
全ての実施例においては、トポロジーは、それがルータAにNHDPによって記録されるように記載されています
F.1. Example 1: Standard Single Interface Topology
F.1。例1：スタンダードシングルインタフェーストポロジ
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)
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}を表す唯一のリンクセットを有しています。このリンクセットの唯一のリンクタプルは{2}を含むL_neighbor_iface_addr_listを有します。図12. 2ホップセットN2_neighbor_iface_addr_listは{2}とN2_2hop_addr {3}であることで、単2ホップタプルを含んで、これは{1}から{2}の右側に破線に対応します。これは、図12の右側に{2} {3}への破線に対応します。
The descriptions of the following examples in this appendix will be derived similarly, and use the same notational conventions.
この付録の次の例の説明は同様に導出され、同じ表記規則を使用します。
F.2. Example 2: Dual Addressed Interface on 1-Hop Neighbor
F.2。実施例2：デュアル1ホップネイバーのインターフェイスを対処しました
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に、ネットワークは、中間ルータ、Bは、その単一のインターフェイス上の2つのIPアドレスを持っていることを除いて、実施例1と同じです。
__________ __________
| | |
{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は二つのアドレス（左）を有し、対応する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}.
インタフェース情報ベースの内容はL_neighbor_iface_addr_listは{2,4}であり、N2_neighbor_iface_addr_listは{2,4}であることを除いて、この場合には実施例1と同一です。
F.3. Example 3: Dual Addressed Interface on 2-Hop Neighbor
F.3。実施例3：デュアル2ホップネイバーのインターフェイスを対処しました
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において、ネットワークは、右端のルータ、Cは、そのインターフェイス上の2つのIPアドレスを持っていることを除いて、実施例1と同じです。
__________ __________
| | |
{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は二つのアドレス（左）を有する単一のインターフェイス、および対応する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}までから二線で示されています。
F.4. Example 4: Dual Addressed Interfaces
F.4。実施例4：デュアルインタフェースのアドレス指定しました
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において、ネットワークは、すべてのルータがそのインターフェイス上の2つのIPアドレスを持っていることを除いて、実施例1と同じです。ルータ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からインタフェース情報ベースの組み合わせです。
F.5. Example 5: Dual Interface on 2-Hop Neighbor
F.5。実施例5：2ホップネイバーでデュアルインターフェイス
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との間に位相的に区別しません。
F.6. Example 6: Dual interface on 1-Hop Neighbor
F.6。実施例6：1ホップネイバーでデュアルインターフェース
In Figure 17, all routers have a single IP address on each interface, and with the 1-hop neighbor having two interfaces.
図17においては、すべてのルータが、各インターフェイス上の単一のIPアドレスを持っていると、2つのインターフェースを有する1ホップ隣人を持ちます。
__________
| |
{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：2つのインタフェース（左）を有する1ホップの近隣B、および対応する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は{2}であると一つのリンク組を含む1つのリンクのみが設定されています。 2ホップセットN2_neighbor_iface_addr_listは{2}であるとN2_2hop_addrは{4}であると、単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がただしCをルータに接続されたルータBのインターフェイスのかを示す情報を有していません、ルータAはアドレス{4}（従って、ルータC）はネクストホップとして{2}を使用して到達可能であることを知っています。
F.7. Example 7: Dual Interface on 1-Hop and 2-Hop Neighbors
F.7。実施例7：デュアルインタフェース1ホップ及び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は、情報は、ルータCのインターフェースこれに接続されているルータBのインターフェイスのどの記述していない、またはアドレス{3}とのインターフェイスとは{4}、同一ルータのインタフェースでもあることに注意してください。しかし、ルータAは{2}として次のホップを使用してアドレス{3}及び{4}（従って、ルータC）が到達可能であることを知っています。
F.8. Example 8: Dual Interface Locally and on 1-Hop Neighbor
F.8。実施例8：デュアルインターフェイスローカル及び1ホップネイバーで
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と2つのインタフェースを持つ1ホップネイバーB（左）、および対応NHDP表示（右）の両方を有する単一のアドレス
The Local Information Set contains two Local Interface Tuples, with I_local_iface_addr_list of {1} and {6}, respectively.
ローカル情報セットは、それぞれ、{1}のI_local_iface_addr_listと{6}を用いて、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}、それぞれ。インターフェイスのための2ホップセット{1} N2_neighbor_iface_addr_listは{2}であるとN2_2hop_addrが{3}であると、単2ホップタプルを含んでいます。インターフェイスのための2ホップセット{6} 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}で表されます。
F.9. Example 9: Dual Interface on All Routers
F.9。例9：すべてのルータでのデュアルインターフェイス
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アドレスを持ち、すべてのルータは、二つのインターフェースを有しています。また、異なるインターフェイスペア上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}.
ローカル情報セットA内の各インターフェイスの例8.インタフェース情報ベースのものと同一である追加の2ホップタプルがそれぞれ2ホップセットに存在することを除いて、また、実施例8と同一である、それぞれ表しますルータBとアドレス{4}を持つルータCのインターフェースとの間のリンク。
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はアドレス{3}及び{4}（およびルータC）はネクストホップとして{2}または{5}（そのローカルインタフェースのそれを介してに応じて）を使用して到達可能であることを知っています。
F.10. Example 10: Dual Addressed Dual Interfaces on All Routers
F.10。実施例10：二重はすべてのルータでデュアルインターフェイスを対処しました
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アドレスを持ち、すべてのルータは、二つのインターフェースを有しています。また、異なるインターフェイスペア上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}、それぞれ。ネイバー（ネイバー情報ベースで）セット、すなわち、{5,6,7,8}、ルータBとそのすべてのインターフェース上のアドレスのすべての存在を記録します。
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の各インターフェイスアドレスは、これらのアドレスのそれぞれにルータBからのリンクとして各インタフェース情報ベースの2ホップセットで表現されています。ルータAは、Cのインタフェースこれに接続されており、またアドレス{9}、{10}、{11}ということ、及び、{12}が同じルータのアドレス（またはいくつかのことであるルータBのインターフェイスのどの記述情報を有していませんこれらのような{9}と{10}、ルータの同じインタフェース）上のアドレスです。
F.11. Example 11: Single Addressed Dual Interface Locally
F.11。実施例11：シングルはローカルデュアルインターフェイスを対処
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においては、すべてのルータは、二つを有するルータAを除いて、単一のインターフェースを有しています。 Aの二つのインターフェースのそれぞれは、すべてのインターフェイスは、単一のアドレスを持つルータ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：シングルアドレス、持つ2つのインタフェースでは、どちらもBの単一インターフェイス（左）、および対応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}.
これは、単一のアドレスは{2}、アドレス{5}を置き換えることを除いて、実施例8と同様です。具体的には、両方のリンクタプル（各リンクセット内の1つ、それに対応するインターフェイス情報Baseの各）は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
トーマス・ハイデクラウゼンLIX、エコールポリテクニック
Phone: +33 6 6058 9349 EMail: T.Clausen@computer.org URI: http://www.ThomasClausen.org/
電話：+33 6 6058 9349 Eメール：T.Clausen@computer.org URI：http://www.ThomasClausen.org/
Christopher Dearlove BAE Systems ATC
クリストファーDearlove BAEシステムズATC
Phone: +44 1245 242194 EMail: chris.dearlove@baesystems.com URI: http://www.baesystems.com/
電話：+44 1245 242194 Eメール：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/
電話：+1 202 767 3397 Eメール：URI jdean@itd.nrl.navy.mil：http://pf.itd.nrl.navy.mil/