[要約] RFC 7466は、モバイルアドホックネットワーク（MANET）の近隣発見プロトコル（NHDP）の最適化に関するものであり、NHDPのパフォーマンス向上と効率化を目的としています。
Internet Engineering Task Force (IETF) C. Dearlove
Request for Comments: 7466 BAE Systems ATC
Updates: 6130, 7181 T. Clausen
Category: Standards Track LIX, Ecole Polytechnique
ISSN: 2070-1721 March 2015
An Optimization for the Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)
モバイルアドホックネットワーク（MANET）近隣探索プロトコル（NHDP）の最適化
Abstract
概要
The link quality mechanism of the Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) enables "ignoring" some 1-hop neighbors if the measured link quality from that 1-hop neighbor is below an acceptable threshold while still retaining the corresponding link information as acquired from the HELLO message exchange. This allows immediate reinstatement of the 1-hop neighbor if the link quality later improves sufficiently.
モバイルアドホックネットワーク（MANET）近隣探索プロトコル（NHDP）のリンク品質メカニズムにより、一部の1ホップネイバーからの測定されたリンク品質が対応するリンクを保持しながら許容可能なしきい値を下回る場合、その1ホップネイバーを「無視」することができます。 HELLOメッセージ交換から取得した情報。これにより、リンクの品質が後で十分に向上した場合に、1ホップのネイバーを即座に回復できます。
NHDP also collects information about symmetric 2-hop neighbors. However, it specifies that if a link from a symmetric 1-hop neighbor ceases being symmetric, including while "ignored" (as described above), then corresponding symmetric 2-hop neighbors are removed. This may lead to symmetric 2-hop neighborhood information being permanently removed (until further HELLO messages are received) if the link quality of a symmetric 1-hop neighbor drops below the acceptable threshold, even if only for a moment.
NHDPは、対称2ホップネイバーに関する情報も収集します。ただし、対称1ホップネイバーからのリンクが対称でなくなった場合（前述のように「無視」されている場合を含む）、対応する対称2ホップネイバーが削除されることを指定しています。これにより、たとえ対称の1ホップネイバーのリンク品質が一瞬でも許容しきい値を下回った場合、対称の2ホップの近隣情報が（さらにHELLOメッセージが受信されるまで）永久に削除される可能性があります。
This specification updates RFC 6130 "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)" and RFC 7181 "The Optimized Link State Routing Protocol Version 2 (OLSRv2)" to permit, as an option, retaining, but ignoring, symmetric 2-hop information when the link quality from the corresponding 1-hop neighbor drops below the acceptable threshold. This allows immediate reinstatement of the symmetric 2-hop neighbor if the link quality later improves sufficiently, thus making the symmetric 2-hop neighborhood more "robust".
この仕様は、RFC 6130「モバイルアドホックネットワーク（MANET）近隣探索プロトコル（NHDP）」およびRFC 7181「最適化されたリンクステートルーティングプロトコルバージョン2（OLSRv2）」を更新して、オプションとして対称2を保持するが無視することを許可します。対応する1ホップネイバーからのリンク品質が許容しきい値を下回ったときのホップ情報。これにより、後でリンクの品質が十分に向上した場合に対称2ホップネイバーを即座に復元できるため、対称2ホップネイバーがより「堅牢」になります。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7466.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7466で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Applicability Statement .........................................4
4. Changes to NHDP .................................................4
4.1. Interface Information Bases ................................5
4.2. HELLO Message Processing ...................................5
4.3. Information Base Changes ...................................5
4.4. Constraints ................................................6
5. Changes to OLSRv2 ...............................................6
6. Security Considerations .........................................8
7. References ......................................................8
7.1. Normative References .......................................8
7.2. Informative References .....................................8
Acknowledgements ...................................................9
Authors' Addresses .................................................9
Section 14 of the MANET Neighborhood Discovery Protocol (NHDP) [RFC6130] contains a link admission mechanism known as "link quality" that allows a router using that protocol to "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." Specifically, [RFC6130] permits a router to disallow consideration of some of its 1-hop neighbors for as long as the quality of the link from that 1-hop neighbor is below an acceptable link quality threshold.
MANET Neighborhood Discovery Protocol（NHDP）[RFC6130]のセクション14には、「リンク品質」と呼ばれるリンクアドミッションメカニズムが含まれています。これにより、そのプロトコルを使用するルーターは、メッセージの交換以外の考慮事項を考慮して、リンクがいつであるかを判断できます。 HEARDまたはSYMMETRICと見なされる候補ではありません。」具体的には、[RFC6130]は、1ホップネイバーからのリンクの品質が許容可能なリンク品質しきい値を下回っている限り、ルーターがその1ホップネイバーの一部を検討できないようにします。
A feature of this mechanism is that while the link quality remains too low, the link information, established by the exchange of HELLO messages, is retained. Thus, if the link quality later goes above the required threshold (note that a hysteresis mechanism means that two thresholds are used), then the link is immediately established and will be immediately available for use.
このメカニズムの特徴は、リンク品質が低すぎるままである間、HELLOメッセージの交換によって確立されたリンク情報が保持されることです。したがって、リンクの品質が後で必要なしきい値を超えると（ヒステリシスメカニズムは2つのしきい値が使用されることを意味します）、リンクはすぐに確立され、すぐに使用できるようになります。
[RFC6130] collects not only 1-hop neighbor information, but also information about symmetric 2-hop neighbors. However, [RFC6130] specifies that if a 1-hop neighbor was, but no longer is, considered symmetric, then the corresponding 2-Hop Tuples that may have been recorded for that 2-hop neighbor are to be removed without a retention mechanism for a (possibly temporary) loss due to link quality.
[RFC6130]は、1ホップのネイバー情報だけでなく、対称の2ホップネイバーに関する情報も収集します。ただし、[RFC6130]は、1ホップのネイバーが対称であると見なされたが、もはや対称と見なされなかった場合、その2ホップのネイバーに記録された対応する2ホップのタプルは、保持メカニズムなしで削除されることを指定しています。リンク品質による（おそらく一時的な）損失。
This means that if there is a short period in which link quality is too low, then when the link quality is re-established all 1-hop neighbor information is immediately available for use again. However, the corresponding symmetric 2-hop neighbor information has been removed and is not available for use until restored by receipt of the next corresponding HELLO message.
つまり、リンク品質が低すぎる短い期間がある場合、リンク品質が再確立されると、すべての1ホップネイバー情報がすぐに再び使用できるようになります。ただし、対応する対称2ホップネイバー情報は削除されており、次の対応するHELLOメッセージを受信して復元するまで使用できません。
This specification describes how [RFC6130] can be modified to avoid this situation by retaining (but not using) 2-hop information, similar to what is done with 1-hop information. This modification is strictly optional, and routers that do and do not implement it can interwork entirely successfully (as they also can with different link quality specifications). In addition, by a suitable interpretation (that ignored 2-Hop Tuples are not externally advertised), this change can be invisible to any other protocols using [RFC6130], in particular [RFC7181]. However, the impact on [RFC7181] when 2-Hop Tuples are not so handled is also described (owing to the existence of implementations of that protocol that are not modularly separated from [RFC6130]).
この仕様は、[RFC6130]を変更して、1ホップ情報で行われるのと同様に、2ホップ情報を保持する（ただし使用しない）ことによってこの状況を回避する方法を説明しています。この変更は厳密にオプションであり、それを実装するルータと実装しないルータは、完全に正常に相互動作できます（リンク品質の仕様が異なる場合もあるため）。さらに、適切な解釈（無視された2ホップタプルは外部にアドバタイズされない）により、この変更は、[RFC6130]、特に[RFC7181]を使用する他のプロトコルからは見えなくなります。ただし、2ホップタプルがそのように処理されない場合の[RFC7181]への影響も説明されています（[RFC6130]からモジュール的に分離されていないプロトコルの実装が存在するため）。
This specification therefore updates [RFC6130] and [RFC7181].
したがって、この仕様は[RFC6130]および[RFC7181]を更新します。
This update to [RFC6130] does not change the definition of a symmetric 2-hop neighbor but adds new state information to each 2-Hop Tuple of [RFC6130]. This is to retain some 2-hop neighbor information while recording it as currently not to be used. The new state information and retained 2-Hop Tuples are reflected in the corresponding tables of the updated NHDP-MIB module [NHDP-MIB].
[RFC6130]に対するこの更新では、対称2ホップネイバーの定義は変更されませんが、[RFC6130]の各2ホップタプルに新しい状態情報が追加されます。これは、現在使用されていないものとして記録しながら、2ホップのネイバー情報を保持するためです。新しい状態情報と保持されている2ホップタプルは、更新されたNHDP-MIBモジュール[NHDP-MIB]の対応するテーブルに反映されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこの文書の "は、[RFC2119]で説明されているように解釈されます。
Additionally, this document uses the terminology of [RFC6130] and [RFC7181].
また、このドキュメントでは、[RFC6130]と[RFC7181]の用語を使用しています。
This specification updates [RFC6130]. The optimization presented in this specification is simply permissive, as it allows retaining information that otherwise would have been removed but does not use that information except when it could have been used by [RFC6130].
この仕様は[RFC6130]を更新します。 [RFC6130]で使用できる場合を除いて、そうでなければ削除されていたであろう情報を保持できるため、この仕様で提示されている最適化は単に許容範囲です。
This can, in some cases, ensure that the symmetric 2-hop neighborhood is more robust against temporary link quality changes and consequently yields a more stable network. The only other consequence of this optimization is that state for some otherwise expired 2-Hop Tuples may be maintained for longer.
これにより、場合によっては、対称2ホップ近傍が一時的なリンク品質の変化に対してより堅牢になり、その結果、より安定したネットワークが生成されます。この最適化の他の唯一の結果は、期限切れになった一部の2ホップタプルの状態がより長く維持される可能性があることです。
This specification also updates [RFC7181]. This could have been avoided had instead [RFC6130] been updated so as to make the changes to it invisible to any other protocol using it. However, as it is known that some implementations of [RFC7181] are not independent of the implementation of [RFC6130] that they use, it is useful to indicate the direct impact on [RFC7181].
この仕様は、[RFC7181]も更新します。これを回避するには、代わりに[RFC6130]を更新して、それを使用する他のプロトコルから変更を見えなくするようにしました。ただし、[RFC7181]の一部の実装は、使用する[RFC6130]の実装から独立していないことがわかっているため、[RFC7181]への直接的な影響を示すと便利です。
A router that implements the optimization described in this specification will interoperate successfully with routers that implement [RFC6130] but do not implement this optimization.
この仕様で説明されている最適化を実装するルーターは、[RFC6130]を実装するがこの最適化を実装しないルーターと正常に相互運用します。
The following changes are made to [RFC6130] if using this specification. Note that while this specification is OPTIONAL, if any of these changes are made, then all of these changes MUST be made.
この仕様を使用する場合、[RFC6130]に次の変更が加えられます。この仕様はオプションですが、これらの変更のいずれかが行われた場合は、これらのすべての変更を行わなければならないことに注意してください。
The 2-Hop Set is modified by adding this additional element to each 2-Hop Tuple:
2ホップセットは、次の要素を各2ホップタプルに追加することによって変更されます。
N2_lost is a boolean flag, which indicates the state of the corresponding Link Tuple. If L_status = SYMMETRIC (and thus L_lost = false), then N2_lost = false. If L_SYM_time has not expired, and L_lost = true (and hence L_status = LOST), then N2_lost = true.
N2_lostは、対応するリンクタプルの状態を示すブールフラグです。 L_status = SYMMETRIC（したがって、L_lost = false）の場合、N2_lost = falseです。 L_SYM_timeの有効期限が切れておらず、L_lost = true（したがって、L_status = LOST）の場合、N2_lost = trueです。
In all other cases, including other cases with L_status = LOST, there will be no such 2-Hop Tuples.
L_status = LOSTを含む他のすべてのケースでは、そのような2ホップのタプルはありません。
In Section 12.6 of [RFC6130], make the following changes:
[RFC6130]のセクション12.6で、次の変更を行います。
o In point 2, change "L_status = SYMMETRIC" to "L_SYM_time not expired".
o ポイント2で、「L_status = SYMMETRIC」を「L_SYM_time not expired」に変更します。
o In point 2, point 1, point 1, under "then create a 2-Hop Tuple with:", add a second bullet point "N2_lost: = L_lost". (Note that "2-Hop Neighbor Tuple" has been corrected here to "2-Hop Tuple" per [Err4276].)
o ポイント2、ポイント1、ポイント1の「次に2ホップのタプルを作成する：」の下に、2番目の箇条書きポイント「N2_lost：= L_lost」を追加します。 （「2-Hop Neighbor Tuple」は、[Err4276]に従って「2-Hop Tuple」に修正されていることに注意してください。）
In Section 13, replace the second bullet point with:
セクション13で、2番目の箇条書きを以下に置き換えます。
o A Link Tuple's L_status changes from SYMMETRIC, L_SYM_time expires, or the Link Tuple is removed. In this case, the actions specified in Section 13.2 are performed.
o リンクタプルのL_statusがSYMMETRICから変更されるか、L_SYM_timeが期限切れになるか、リンクタプルが削除されます。この場合、セクション13.2で指定されたアクションが実行されます。
Replace the paragraph after the bullet points with:
箇条書きの後の段落を次のように置き換えます。
If a Link Tuple is removed, or if L_HEARD_time expires and either L_status changes from SYMMETRIC or L_SYM_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がSYMMETRICから変更された場合、またはL_SYM_timeが期限切れになった場合は、セクション13.2で指定されたアクションを実行してから、そのリンクタプルに対してセクション13.3で指定されたアクションを実行する必要があります。
In Section 13.2 of [RFC6130], add the following before all other text:
[RFC6130]のセクション13.2で、他のすべてのテキストの前に次を追加します。
For each Link Tuple that has L_SYM_time not expired:
L_SYM_timeが期限切れでない各リンクタプルについて：
1. If L_SYM_time then expires, or if the Link Tuple is removed:
1. L_SYM_timeが期限切れになった場合、またはリンクタプルが削除された場合：
1. Remove each 2-Hop Tuple for the same MANET interface with:
1. 同じMANETインターフェイスの2ホップタプルをそれぞれ削除します。
+ N2_neighbor_iface_addr_list contains one or more network addresses in L_neighbor_iface_addr_list.
+ N2_neighbor_iface_addr_listには、L_neighbor_iface_addr_list内の1つ以上のネットワークアドレスが含まれています。
2. If L_status then changes from SYMMETRIC to LOST because L_lost is set to true:
2. L_lostがtrueに設定されているため、L_statusがSYMMETRICからLOSTに変わる場合：
1. For each 2-Hop Tuple for the same MANET interface with:
1. 同じMANETインターフェースの2ホップタプルごとに：
+ N2_neighbor_iface_addr_list contains one or more network addresses in L_neighbor_iface_addr_list;
+ N2_neighbor_iface_addr_listには、L_neighbor_iface_addr_listに1つ以上のネットワークアドレスが含まれています。
set N2_lost := true.
N2_lost：= trueを設定します。
Also, in Section 13.2 of [RFC6130], remove point 1 and renumber point 2 as point 1.
また、[RFC6130]のセクション13.2で、ポイント1を削除し、ポイント2の番号をポイント1に変更します。
In Appendix B of [RFC6130], under "In each 2-Hop Tuple:", change the first bullet point to:
[RFC6130]の付録Bの「各2ホップタプル：」の下で、最初の箇条書きを次のように変更します。
o There MUST be a Link Tuple associated with the same MANET interface with:
o 同じMANETインターフェイスに関連付けられたリンクタプルが存在する必要があります。
* L_neighbor_iface_addr_list = N2_neighbor_iface_addr_list; AND
* L_neighbor_iface_addr_list = N2_neighbor_iface_addr_list;そして
* L_SYM_time not expired; AND
* L_SYM_timeは期限切れではありません。そして
* L_lost = N2_lost.
* L_lost = N2_lost。
If the implementation of [RFC6130] conceals from any protocol using it the existence of all 2-Hop Tuples with N2_lost = true, then no changes are required to any protocol using [RFC6130]; in particular, no changes are required to [RFC7181].
[RFC6130]の実装がそれを使用するプロトコルから隠蔽し、N2_lost = trueのすべての2ホップタプルの存在を隠す場合、[RFC6130]を使用するプロトコルへの変更は不要です。特に、[RFC7181]を変更する必要はありません。
However, if instead the implementation of [RFC6130] makes all 2-Hop Tuples visible, including those with N2_lost = true, then protocols using [RFC6130] MUST ignore such 2-Hop Tuples.
ただし、[RFC6130]の実装により、N2_lost = trueを含むすべての2ホップタプルが表示される場合、[RFC6130]を使用するプロトコルは、そのような2ホップタプルを無視する必要があります。
For [RFC7181], given that this protocol uses 2-hop information for Multipoint Relay (MPR) Set and Routing Set calculation but does not include that information in control traffic, this means that an implementation must be behaving (i) as if a 2-Hop Tuple only exists if N2_lost=false and (ii) as if a change of N2_lost (from false to true, or true to false) corresponds to a 2-Hop Tuple appearing or being removed. Specifically, this means behaving as if all of the following changes were to be made to [RFC7181]:
[RFC7181]の場合、このプロトコルはマルチポイントリレー（MPR）セットとルーティングセットの計算に2ホップ情報を使用しますが、その情報を制御トラフィックに含めないため、実装は（i）2のように動作する必要があります。 -ホップタプルは、N2_lost = falseの場合にのみ存在し、（ii）N2_lostの変更（falseからtrue、またはtrueからfalse）が2ホップタプルの出現または削除に対応するかのように存在します。具体的には、これは次の変更がすべて[RFC7181]に対して行われるかのように動作することを意味します。
o In Section 17.6 of [RFC7181], point 1, replace the final two bullet points with:
o [RFC7181]のセクション17.6のポイント1で、最後の2つの箇条書きを次のように置き換えます。
* A 2-Hop Tuple with N2_out_metric != UNKNOWN_METRIC and N2_lost = false is added or removed; OR
* N2_out_metric！= UNKNOWN_METRICおよびN2_lost = falseの2ホップタプルが追加または削除されました。または
* A 2-Hop Tuple with N2_out_metric != UNKNOWN_METRIC has N2_lost changed; OR
* N2_out_metric！= UNKNOWN_METRICの2ホップタプルのN2_lostが変更されました。または
* The N2_out_metric of any 2-Hop Tuple with N2_lost = false changes, and either the flooding MPR selection process uses metric values (see Section 18.4), or the change is to or from UNKNOWN_METRIC.
* N2_lost = falseの2ホップタプルのN2_out_metricが変更され、フラッディングMPR選択プロセスがメトリック値を使用するか（セクション18.4を参照）、またはUNKNOWN_METRICとの間の変更です。
o In Section 17.6 of [RFC7181], point 3, replace the final two bullet points with:
o [RFC7181]のセクション17.6のポイント3で、最後の2つの箇条書きを次のように置き換えます。
* A 2-Hop Tuple with N2_in_metric != UNKNOWN_METRIC and N2_lost = false is added or removed; OR
* N2_in_metric！= UNKNOWN_METRICおよびN2_lost = falseの2ホップタプルが追加または削除されます。または
* A 2-Hop Tuple with N2_in_metric != UNKNOWN_METRIC has N2_lost changed; OR
* N2_in_metric！= UNKNOWN_METRICの2ホップタプルのN2_lostが変更されました。または
* The N2_in_metric of any 2-Hop Tuple with N2_lost = false changes.
* N2_lost = falseの変更がある2ホップタプルのN2_in_metric。
o In Section 17.7 of [RFC7181], in the fifth bullet point, add "and N2_lost = false" after "N2_out_metric != UNKNOWN_METRIC".
o [RFC7181]のセクション17.7の5番目の箇条書きで、「N2_out_metric！= UNKNOWN_METRIC」の後に「and N2_lost = false」を追加します。
o In Section 18.4 of [RFC7181], in the third bullet point, add ", N2_lost = false" after "N2_out_metric != UNKNOWN_METRIC".
o [RFC7181]のセクション18.4の3番目の箇条書きで、「N2_out_metric！= UNKNOWN_METRIC」の後に「、N2_lost = false」を追加します。
o In Section 18.5 of [RFC7181], in the third bullet point, add ", N2_lost = false" after "N2_in_metric != UNKNOWN_METRIC".
o [RFC7181]のセクション18.5の3番目の箇条書きで、「N2_in_metric！= UNKNOWN_METRIC」の後に「、N2_lost = false」を追加します。
o In Section 19.1 of [RFC7181], in the final main bullet point (marked as "(OPTIONAL)"), add "and N2_lost = false" after "N2_out_metric != UNKNOWN_METRIC".
o [RFC7181]のセクション19.1の最後の主要な箇条書き（「（オプション）」とマークされています）で、「N2_out_metric！= UNKNOWN_METRIC」の後に「and N2_lost = false」を追加します。
o In Appendix C.7 of [RFC7181], in point 1, add "and N2_lost = false" after "N2_out_metric != UNKNOWN_METRIC".
o [RFC7181]の付録C.7のポイント1で、「N2_out_metric！= UNKNOWN_METRIC」の後に「and N2_lost = false」を追加します。
The update to [RFC6130] enables the retention and reuse of some information collected by that protocol, for only the duration that it could have been used in any case. As such, this protocol introduces no new security considerations to an implementation of [RFC6130] or of any other protocol that uses it, such as [RFC7181].
[RFC6130]の更新により、そのプロトコルによって収集された一部の情報を、どのような場合でも使用できた期間だけ保持および再利用できるようになります。そのため、このプロトコルは、[RFC6130]または[RFC7181]などのそれを使用する他のプロトコルの実装に新しいセキュリティの考慮事項を導入していません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月、<http://www.rfc-editor.org/info/rfc2119>。
[RFC6130] Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)", RFC 6130, April 2011, <http://www.rfc-editor.org/info/rfc6130>.
[RFC6130] Clausen、T.、Dean、J。、およびC. Dearlove、「モバイルアドホックネットワーク（MANET）近隣探索プロトコル（NHDP）」、RFC 6130、2011年4月、<http：//www.rfc-editor .org / info / rfc6130>。
[RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, "The Optimized Link State Routing Protocol Version 2", RFC 7181, April 2014, <http://www.rfc-editor.org/info/rfc7181>.
[RFC7181] Clausen、T.、Dearlove、C.、Jacquet、P。、およびU. Herberg、「The Optimized Link State Routing Protocol Version 2」、RFC 7181、2014年4月、<http：//www.rfc-editor .org / info / rfc7181>。
[Err4276] RFC Errata, Errata ID 4276, RFC 6130.
[Err4276] RFC Errata、Errata ID 4276、RFC 6130。
[NHDP-MIB] Herberg, U., Cole, R., Chakeres, I., and T. Clausen, "Definition of Managed Objects for the Neighborhood Discovery Protocol", Work in Progress, draft-ietf-manet-rfc6779bis, August 2014.
[NHDP-MIB] Herberg、U.、Cole、R.、Chakeres、I.、T。Clausen、「Definition of Managed Objects for the Neighborhood Discovery Protocol」、Work in Progress、draft-ietf-manet-rfc6779bis、8月2014。
Acknowledgements
謝辞
The authors would like to thank Liz Cullen (BAE Systems) for first illustrating the issue addressed in this specification.
この仕様で扱われている問題を最初に説明してくれたLiz Cullen（BAE Systems）に感謝します。
Authors' Addresses
著者のアドレス
Christopher Dearlove BAE Systems Advanced Technology Centre West Hanningfield Road Great Baddow, Chelmsford United Kingdom
Christopher Dearlove BAE Systems Advanced Technology Center West Hanningfield Roadイギリス、チェルムズフォード、グレートバッドウ
Phone: +44 1245 242194
EMail: chris.dearlove@baesystems.com
URI: http://www.baesystems.com/
Thomas Heide Clausen LIX, Ecole Polytechnique
トーマスハイデクラウセンLIX、エコールポリテクニック
Phone: +33 6 6058 9349
EMail: T.Clausen@computer.org
URI: http://www.ThomasClausen.org/