Internet Engineering Task Force (IETF) C.E. Perkins
Request for Comments: 9854 Blue Meadow Networks
Category: Standards Track S.V.R. Anand
ISSN: 2070-1721 Indian Institute of Science
S. Anamalamudi
SRM University-AP
B. Liu
Huawei Technologies
October 2025
Route discovery for symmetric and asymmetric Peer-to-Peer (P2P) traffic flows is a desirable feature in Low-Power and Lossy Networks (LLNs). For that purpose, this document specifies AODV-RPL -- the Routing Protocol for Low-Power and Lossy Networks (RPL) based on Ad hoc On-demand Distance Vector (AODV) routing. AODV-RPL is a reactive P2P route discovery mechanism for both hop-by-hop routes and source routing. Paired instances are used to construct directional paths for cases where there are asymmetric links between source and target nodes.
対称および非対称のピアツーピア (P2P) トラフィック フローのルート検出は、低電力および損失の多いネットワーク (LLN) で望ましい機能です。この目的のために、この文書では AODV-RPL (アドホック オンデマンド ディスタンス ベクトル (AODV) ルーティングに基づく低電力および損失の多いネットワーク (RPL) 用のルーティング プロトコル) を規定します。AODV-RPL は、ホップバイホップ ルートとソース ルーティングの両方に対するリアクティブな P2P ルート検出メカニズムです。ペアのインスタンスは、ソース ノードとターゲット ノードの間に非対称リンクがある場合に方向性パスを構築するために使用されます。
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 7841.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。インターネット標準の詳細については、RFC 7841 のセクション 2 を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9854.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9854 で入手できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2025 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
2. Terminology
3. Overview of AODV-RPL
4. AODV-RPL DIO Options
4.1. AODV-RPL RREQ Option
4.2. AODV-RPL RREP Option
4.3. AODV-RPL Target Option
5. Symmetric and Asymmetric Routes
6. AODV-RPL Operation
6.1. Generating RREQ
6.2. Receiving and Forwarding RREQ Messages
6.2.1. Step 1: RREQ Reception and Evaluation
6.2.2. Step 2: TargNode and Intermediate Router Determination
6.2.3. Step 3: Intermediate Router RREQ Processing
6.2.4. Step 4: Symmetric Route Processing at an Intermediate
Router
6.2.5. Step 5: RREQ Propagation at an Intermediate Router
6.2.6. Step 6: RREQ Reception at TargNode
6.3. Generating RREP at TargNode
6.3.1. RREP-DIO for Symmetric Route
6.3.2. RREP-DIO for Asymmetric Route
6.3.3. RPLInstanceID Pairing
6.4. Receiving and Forwarding RREP
6.4.1. Step 1: Receiving and Evaluation
6.4.2. Step 2: OrigNode or Intermediate Router
6.4.3. Step 3: Build Route to TargNode
6.4.4. Step 4: RREP Propagation
7. Gratuitous RREP
8. Operation of Trickle Timer
9. IANA Considerations
10. Security Considerations
11. References
11.1. Normative References
11.2. Informative References
Appendix A. Example: Using ETX/RSSI Values to Determine Value of S
Bit
Appendix B. Some Example AODV-RPL Message Flows
B.1. Example Control Message Flows in Symmetric and Asymmetric
Networks
B.2. Example RREP_WAIT Handling
B.3. Example G-RREP Handling
Acknowledgements
Contributors
Authors' Addresses
The Routing Protocol for Low-Power and Lossy Networks (RPL) [RFC6550] is an IPv6 distance vector routing protocol designed to support multiple traffic flows through a root-based Destination-Oriented Directed Acyclic Graph (DODAG). Typically, a router does not have routing information for destinations attached to most other routers. Consequently, for traffic between routers within the DODAG (i.e., P2P traffic), data packets either have to traverse the root in non-storing mode or traverse a common ancestor in storing mode. Such P2P traffic is thereby likely to traverse longer routes and may suffer severe congestion near the root (for more information, see [RFC6687], [RFC6997], [RFC6998], and [RFC9010]). The network environment that is considered in this document is assumed to be the same as that described in Section 1 of [RFC6550]. Each radio interface/link and the associated address should be treated as an independent intermediate router. Such routers have different links, and the rules for link symmetry apply independently for each of these.
低電力および損失の多いネットワーク用ルーティング プロトコル (RPL) [RFC6550] は、ルートベースの宛先指向有向非巡回グラフ (DODAG) を介して複数のトラフィック フローをサポートするように設計された IPv6 距離ベクトル ルーティング プロトコルです。通常、ルーターには、他のほとんどのルーターに接続されている宛先のルーティング情報がありません。したがって、DODAG 内のルーター間のトラフィック (つまり、P2P トラフィック) の場合、データ パケットは非保存モードでルートを通過するか、保存モードで共通の祖先を通過する必要があります。そのため、このような P2P トラフィックはより長いルートを通過する可能性が高く、ルート付近で深刻な輻輳が発生する可能性があります (詳細については、[RFC6687]、[RFC6997]、[RFC6998]、および [RFC9010] を参照)。この文書で考慮されるネットワーク環境は、[RFC6550] のセクション 1 で説明されているものと同じであると想定されます。各無線インターフェイス/リンクおよび関連するアドレスは、独立した中間ルーターとして扱われる必要があります。このようなルータには異なるリンクがあり、リンク対称性のルールがこれらのそれぞれに独立して適用されます。
The route discovery process in AODV-RPL is modeled on the analogous P2P procedure specified in AODV [RFC3561]. The on-demand property of AODV route discovery is useful for the needs of routing in RPL-based LLNs when routes are needed but aren't yet established. P2P routing is desirable to discover shorter routes, especially when it is desired to avoid directing additional traffic through a root or gateway node of the network. It may happen that some routes need to be established proactively when known beforehand and when AODV-RPL's route discovery process introduces unwanted delay when the application is launched.
AODV-RPL のルート発見プロセスは、AODV [RFC3561] で指定されている類似の P2P プロシージャに基づいてモデル化されています。AODV ルート検出のオンデマンド プロパティは、ルートが必要だがまだ確立されていない場合に、RPL ベースの LLN でのルーティングのニーズに役立ちます。P2P ルーティングは、特にネットワークのルート ノードまたはゲートウェイ ノードを介して追加のトラフィックを送信することを避けたい場合に、より短いルートを発見するのに適しています。事前にわかっている場合や、アプリケーションの起動時に AODV-RPL のルート検出プロセスにより望ましくない遅延が発生する場合、一部のルートを事前に確立する必要がある場合があります。
AODV terminology has been adapted for use with AODV-RPL messages, namely "RREQ" for "Route Request", and "RREP" for "Route Reply". AODV-RPL currently omits some features compared to AODV -- in particular, flagging route errors, blocking the use of unidirectional links [RFC3561], multihoming, and handling unnumbered interfaces.
AODV 用語は、AODV-RPL メッセージでの使用に合わせて調整されています。つまり、「RREQ」は「ルート要求」、「RREP」は「ルート応答」です。AODV-RPL は現在、AODV と比較していくつかの機能、特にルート エラーのフラグ付け、単方向リンク [RFC3561] の使用のブロック、マルチホーミング、番号なしインターフェイスの処理を省略しています。
AODV-RPL reuses and extends the core RPL functionality to support routes with bidirectional asymmetric links. It retains RPL's DODAG formation, RPL Instance and the associated Objective Function (OF) (defined in [RFC6551]), Trickle timers, and support for storing and non-storing modes. AODV-RPL adds the basic messages RREQ and RREP as part of the RPL DODAG Information Object (DIO) control message, which go in separate (paired) RPL Instances. AODV-RPL does not utilize the Destination Advertisement Object (DAO) control message of RPL. AODV-RPL uses the "P2P Route Discovery Mode of Operation" (MOP == 4) with three new options for the DIO message, dedicated to discovering P2P routes. These P2P routes may differ from routes discoverable by RPL [RFC6550]. Since AODV-RPL uses newly defined options and a newly allocated multicast group (see Section 9), there is no conflict with P2P-RPL [RFC6997], a previous document using the same MOP. AODV-RPL can be operated whether or not P2P-RPL or RPL [RFC6550] is also running. AODV-RPL could be used for networks in which routes are needed with OFs that cannot be satisfied by routes that are constrained to traverse the root of the network or other common ancestors. P2P routes often require fewer hops and therefore consume less resources than routes that traverse the root or other common ancestors. Similar in cost to base RPL [RFC6550], the cost will depend on many factors such as the proximity of the OrigNode and TargNodes and distribution of symmetric/asymmetric P2P links. Experience with AODV [aodv-tot] suggests that AODV-RPL will often find routes with improved Rank compared to routes constrained to traverse a common ancestor of the source and destination nodes.
AODV-RPL は、コア RPL 機能を再利用および拡張して、双方向の非対称リンクを持つルートをサポートします。RPL の DODAG 形成、RPL インスタンスおよび関連する目的関数 (OF) ([RFC6551] で定義)、トリクル タイマー、および保存モードと非保存モードのサポートは保持されます。AODV-RPL は、RPL DIO (DODAG 情報オブジェクト) 制御メッセージの一部として基本メッセージ RREQ および RREP を追加し、これらは別個の (ペアになった) RPL インスタンスに入ります。AODV-RPL は、RPL の宛先広告オブジェクト (DAO) 制御メッセージを利用しません。AODV-RPL は、P2P ルートの検出専用の DIO メッセージの 3 つの新しいオプションを備えた「P2P ルート検出動作モード」(MOP == 4) を使用します。これらの P2P ルートは、RPL [RFC6550] によって検出可能なルートとは異なる場合があります。AODV-RPL は新しく定義されたオプションと新しく割り当てられたマルチキャスト グループを使用するため (セクション 9 を参照)、同じ MOP を使用する以前の文書である P2P-RPL [RFC6997] との競合はありません。AODV-RPL は、P2P-RPL または RPL [RFC6550] が実行されているかどうかに関係なく動作できます。AODV-RPL は、ネットワークのルートまたは他の共通の祖先を通過するように制約されているルートでは満足できない OF を持つルートが必要なネットワークに使用できます。P2P ルートは多くの場合、必要なホップが少ないため、ルートや他の共通祖先を通過するルートよりも消費するリソースが少なくなります。基本 RPL [RFC6550] のコストと同様に、コストは OrigNode と TargNode の近さ、対称/非対称 P2P リンクの分散などの多くの要因に依存します。AODV [aodv-tot] の経験から、AODV-RPL は、送信元ノードと宛先ノードの共通の祖先を通過するように制約されたルートと比較して、ランクが向上したルートを見つけることが多いことが示唆されています。
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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
AODV-RPL reuses names for messages and data structures, including Rank, DODAG, and DODAGID, as defined in RPL [RFC6550].
AODV-RPL は、RPL [RFC6550] で定義されているように、Rank、DODAG、DODAGID などのメッセージとデータ構造の名前を再利用します。
This document also uses the following terms:
このドキュメントでは次の用語も使用します。
AODV
AODV
Ad hoc On-Demand Distance Vector [RFC3561].
アドホック オンデマンド ディスタンス ベクトル [RFC3561]。
ART option
ARTオプション
The AODV-RPL Target option defined in this document.
このドキュメントで定義されている AODV-RPL ターゲット オプション。
Asymmetric route
非対称ルート
The route from the OrigNode to the TargNode can traverse different nodes than the route from the TargNode to the OrigNode. An asymmetric route may result from the asymmetry of links, such that only one direction of the series of links satisfies the OF during route discovery.
OrigNode から TargNode へのルートは、TargNode から OrigNode へのルートとは異なるノードを通過できます。非対称ルートは、リンクの非対称性から生じる可能性があり、ルート検出中に一連のリンクの 1 方向のみが OF を満たすことになります。
Bidirectional asymmetric link
双方向非対称リンク
A link that can be used in both directions but with different link characteristics.
双方向で使用できますが、異なるリンク特性を持つリンク。
DIO
ディオ
DODAG Information Object (as defined in [RFC6550]).
DODAG 情報オブジェクト ([RFC6550] で定義)。
DODAG RREQ-Instance (or simply RREQ-Instance)
DODAG RREQ インスタンス (または単に RREQ インスタンス)
A RPL Instance built using the DIO with RREQ option; used for transmission of control messages from OrigNode to TargNode, thus enabling data transmission from TargNode to OrigNode.
RREQ オプションを備えた DIO を使用して構築された RPL インスタンス。OrigNode から TargNode への制御メッセージの送信に使用され、TargNode から OrigNode へのデータ送信が可能になります。
DODAG RREP-Instance (or simply RREP-Instance)
DODAG RREP インスタンス (または単に RREP インスタンス)
A RPL Instance built using the DIO with RREP option; used for transmission of control messages from TargNode to OrigNode, thus enabling data transmission from OrigNode to TargNode.
RREP オプションを備えた DIO を使用して構築された RPL インスタンス。TargNode から OrigNode への制御メッセージの送信に使用され、OrigNode から TargNode へのデータ送信が可能になります。
Downward direction
下方向
The direction from the OrigNode to the TargNode.
OrigNode から TargNode への方向。
Downward route
下りルート
A route in the downward direction.
下向きのルートです。
Hop-by-hop route
ホップバイホップルート
A route for which each router along the routing path stores routing information about the next hop. A hop-by-hop route is created using RPL's "storing mode".
ルーティング パス上の各ルーターがネクスト ホップに関するルーティング情報を保存するルート。ホップバイホップ ルートは、RPL の「保存モード」を使用して作成されます。
OF
の
Objective Function (as defined in [RFC6550]).
目的関数 ([RFC6550] で定義)。
OrigNode
オリグノード
The IPv6 router (originating node) initiating the AODV-RPL route discovery to obtain a route to TargNode.
IPv6 ルーター (発信元ノード) は、AODV-RPL ルート検出を開始して、TargNode へのルートを取得します。
Paired DODAGs
ペアになった DODAG
Two DODAGs for a single route discovery process between OrigNode and TargNode.
OrigNode と TargNode 間の 1 つのルート検出プロセス用の 2 つの DODAG。
P2P
P2P
Peer-to-Peer (in other words, not constrained a priori to traverse a common ancestor).
ピアツーピア (言い換えれば、共通の祖先を横断するようにアプリオリに制約されない)。
REJOIN_REENABLE
REJOIN_REENABLE
The duration during which a node is prohibited from joining a DODAG with a particular RREQ-InstanceID, after it has left a DODAG with the same RREQ-InstanceID. The default value of REJOIN_REENABLE is 15 minutes.
ノードが同じ RREQ-InstanceID を持つ DODAG を離れた後、特定の RREQ-InstanceID を持つ DODAG に参加することが禁止される期間。REJOIN_REENABLE のデフォルト値は 15 分です。
RREQ
RREQ
Route Request.
ルートリクエスト。
RREQ-DIO message
RREQ-DIOメッセージ
A DIO message containing the RREQ option. The RPLInstanceID in RREQ-DIO is assigned locally by the OrigNode. The RREQ-DIO message has a secure variant as noted in [RFC6550].
RREQ オプションを含む DIO メッセージ。RREQ-DIO の RPLInstanceID は、OrigNode によってローカルに割り当てられます。[RFC6550] に記載されているように、RREQ-DIO メッセージには安全なバリアントがあります。
RREQ-InstanceID
RREQ-インスタンスID
The RPLInstanceID for the RREQ-Instance. The RREQ-InstanceID is formed as the ordered pair (Orig_RPLInstanceID, OrigNode-IPaddr), where Orig_RPLInstanceID is the local RPLInstanceID allocated by OrigNode and OrigNode-IPaddr is an IP address of OrigNode. The RREQ-InstanceID uniquely identifies the RREQ-Instance.
RREQ インスタンスの RPLInstanceID。RREQ-InstanceID は順序付きペア (Orig_RPLInstanceID、OrigNode-IPaddr) として形成されます。ここで、Orig_RPLInstanceID は OrigNode によって割り当てられたローカル RPLInstanceID であり、OrigNode-IPaddr は OrigNode の IP アドレスです。RREQ-InstanceID は、RREQ-Instance を一意に識別します。
RREP
RREP
Route Reply.
ルート応答。
RREP-DIO message
RREP-DIOメッセージ
A DIO message containing the RREP option. OrigNode pairs the RPLInstanceID in RREP-DIO to the one in the associated RREQ-DIO message (i.e., the RREQ-InstanceID) as described in Section 6.3.2. The RREP-DIO message has a secure variant as noted in [RFC6550].
RREP オプションを含む DIO メッセージ。OrigNode は、セクション 6.3.2 で説明されているように、RREP-DIO 内の RPLInstanceID を、関連する RREQ-DIO メッセージ内の RPLInstanceID (つまり、RREQ-InstanceID) とペアにします。[RFC6550] に記載されているように、RREP-DIO メッセージには安全なバリアントがあります。
RREP-InstanceID
RREP-インスタンスID
The RPLInstanceID for the RREP-Instance. The RREP-InstanceID is formed as the ordered pair (Targ_RPLInstanceID, TargNode-IPaddr), where Targ_RPLInstanceID is the local RPLInstanceID allocated by TargNode and TargNode-IPaddr is an IP address of TargNode. The RREP-InstanceID uniquely identifies the RREP-Instance. The RPLInstanceID in the RREP message along with the Delta value indicates the associated RREQ-InstanceID. The InstanceIDs are matched by the mechanism explained in Section 6.3.3.
RREP インスタンスの RPLInstanceID。RREP-InstanceID は順序ペア (Targ_RPLInstanceID、TargNode-IPaddr) として形成されます。Targ_RPLInstanceID は TargNode によって割り当てられたローカル RPLInstanceID、TargNode-IPaddr は TargNode の IP アドレスです。RREP-InstanceID は、RREP-Instance を一意に識別します。RREP メッセージ内の RPLInstanceID とデルタ値は、関連付けられた RREQ-InstanceID を示します。InstanceID は、セクション 6.3.3 で説明されているメカニズムによって照合されます。
Source routing
ソースルーティング
A mechanism by which the source supplies a vector of addresses towards the destination node along with each data packet [RFC6550].
ソースが各データ パケットとともにアドレスのベクトルを宛先ノードに供給するメカニズム [RFC6550]。
Symmetric route
対称ルート
The upstream and downstream routes traverse the same routers and over the same links.
アップストリーム ルートとダウンストリーム ルートは、同じルーターと同じリンクを通過します。
TargNode
ターゲットノード
The IPv6 router (target node) for which OrigNode requires a route and initiates route discovery within the LLN.
OrigNode がルートを必要とし、LLN 内でルート検出を開始する IPv6 ルーター (ターゲット ノード)。
Upward direction
上方向
The direction from the TargNode to the OrigNode.
TargNode から OrigNode への方向。
Upward route
上りルート
A route in the upward direction.
上向きのルートです。
With AODV-RPL, routes from OrigNode to TargNode within the LLN do not become established until they are needed. The route discovery mechanism in AODV-RPL is invoked when OrigNode has data for delivery to a TargNode, but existing routes do not satisfy the application's requirements. For this reason, AODV-RPL is considered to be an example of an "on-demand" routing protocol. Such protocols are also known as "reactive" routing protocols since their operations are triggered in reaction to a determination that a new route is needed. AODV-RPL works without requiring the use of RPL or any other routing protocol.
AODV-RPL では、LLN 内の OrigNode から TargNode へのルートは、必要になるまで確立されません。AODV-RPL のルート検出メカニズムは、OrigNode が TargNode に配信するデータを持っているが、既存のルートがアプリケーションの要件を満たしていない場合に呼び出されます。このため、AODV-RPL は「オンデマンド」ルーティング プロトコルの一例とみなされます。このようなプロトコルは、新しいルートが必要であるという決定に反応して動作が開始されるため、「リアクティブ」ルーティング プロトコルとしても知られています。AODV-RPL は、RPL やその他のルーティング プロトコルを使用する必要なく機能します。
The routes discovered by AODV-RPL are not constrained to traverse a common ancestor. AODV-RPL can enable asymmetric communication paths in networks with bidirectional asymmetric links. For this purpose, AODV-RPL enables discovery of two routes: namely, one from OrigNode to TargNode and another from TargNode to OrigNode. AODV-RPL also enables discovery of symmetric routes along paired DODAGs, when symmetric routes are possible (see Section 5).
AODV-RPL によって検出されたルートは、共通の祖先を通過するように制約されません。AODV-RPL は、双方向の非対称リンクを備えたネットワークで非対称通信パスを有効にすることができます。この目的のために、AODV-RPL は 2 つのルートの検出を可能にします。つまり、1 つは OrigNode から TargNode へ、もう 1 つは TargNode から OrigNode です。AODV-RPL は、対称ルートが可能な場合、ペアの DODAG に沿った対称ルートの検出も可能にします (セクション 5 を参照)。
In AODV-RPL, routes are discovered by first forming a temporary Directed Acyclic Graph (DAG) rooted at the OrigNode. Paired DODAGs (Instances) are constructed during route formation between the OrigNode and TargNode. The RREQ-Instance is formed by route control messages from OrigNode to TargNode, whereas the RREP-Instance is formed by route control messages from TargNode to OrigNode. The route discovered in the RREQ-Instance is used for transmitting data from TargNode to OrigNode, and the route discovered in RREP-Instance is used for transmitting data from OrigNode to TargNode.
AODV-RPL では、最初に OrigNode をルートとする一時的な有向非巡回グラフ (DAG) を形成することによってルートが検出されます。ペアの DODAG (インスタンス) は、OrigNode と TargNode 間のルート形成中に構築されます。RREQ インスタンスは、OrigNode から TargNode へのルート制御メッセージによって形成され、RREP インスタンスは、TargNode から OrigNode へのルート制御メッセージによって形成されます。RREQ-Instance で発見されたルートは TargNode から OrigNode へのデータ送信に使用され、RREP-Instance で発見されたルートは OrigNode から TargNode へのデータ送信に使用されます。
Intermediate routers join the DODAGs based on the Rank [RFC6550] as calculated from the DIO messages. AODV-RPL uses the same notion of Rank as defined in [RFC6550]:
中間ルーターは、DIO メッセージから計算されたランク [RFC6550] に基づいて DODAG に参加します。AODV-RPL は、[RFC6550] で定義されているのと同じランクの概念を使用します。
The Rank is the expression of a relative position within a DODAG Version with regard to neighbors, and it is not necessarily a good indication or a proper expression of a distance or a path cost to the root.
ランクは、隣接するものに関する DODAG バージョン内の相対位置を表すものであり、ルートまでの距離やパス コストの適切な表示や適切な表現であるとは限りません。
The Rank measurements provided in AODV messages do not indicate a distance or a path cost to the root.
AODV メッセージで提供されるランク測定値は、ルートまでの距離やパス コストを示しません。
Henceforth in this document, "RREQ-DIO message" means the DIO message from OrigNode toward TargNode, containing the RREQ option as specified in Section 4.1. The RREQ-InstanceID is formed as the ordered pair (Orig_RPLInstanceID, OrigNode-IPaddr), where Orig_RPLInstanceID is the local RPLInstanceID allocated by OrigNode and OrigNode-IPaddr is the IP address of OrigNode. A node receiving the RREQ-DIO can use the RREQ-InstanceID to identify the proper OF whenever that node receives a data packet with Source Address == OrigNode-IPaddr and IPv6 RPL Option having the RPLInstanceID == Orig_RPLInstanceID. The D bit of the RPLInstanceID field is set to 0 to indicate that the source address of the IPv6 packet is the DODAGID.
以降、このドキュメントでは、「RREQ-DIO メッセージ」とは、セクション 4.1 で指定されている RREQ オプションを含む、OrigNode から TargNode への DIO メッセージを意味します。RREQ-InstanceID は順序付きペア (Orig_RPLInstanceID、OrigNode-IPaddr) として形成されます。ここで、Orig_RPLInstanceID は OrigNode によって割り当てられたローカル RPLInstanceID であり、OrigNode-IPaddr は OrigNode の IP アドレスです。RREQ-DIO を受信するノードは、ソース アドレス == OrigNode-IPaddr および RPLInstanceID == Orig_RPLInstanceID を持つ IPv6 RPL オプションを持つデータ パケットを受信するたびに、RREQ-InstanceID を使用して適切な OF を識別できます。RPLInstanceID フィールドの D ビットは 0 に設定され、IPv6 パケットの送信元アドレスが DODAGID であることを示します。
Similarly, "RREP-DIO message" means the DIO message from TargNode toward OrigNode, containing the RREP option as specified in Section 4.2. The RREP-InstanceID is formed as the ordered pair (Targ_RPLInstanceID, TargNode-IPaddr), where Targ_RPLInstanceID is the local RPLInstanceID allocated by TargNode and TargNode-IPaddr is the IP address of TargNode. A node receiving the RREP-DIO can use the RREP-InstanceID to identify the proper OF whenever that node receives a data packet with Source Address == TargNode-IPaddr and IPv6 RPL Option having the RPLInstanceID == Targ_RPLInstanceID along with D == 0 as above.
同様に、「RREP-DIO メッセージ」とは、セクション 4.2 で指定されている RREP オプションを含む、TargNode から OrigNode への DIO メッセージを意味します。RREP-InstanceID は順序付きペア (Targ_RPLInstanceID、TargNode-IPaddr) として形成されます。Targ_RPLInstanceID は TargNode によって割り当てられたローカル RPLInstanceID、TargNode-IPaddr は TargNode の IP アドレスです。RREP-DIO を受信するノードは、上記のようにソース アドレス == TargNode-IPaddr および RPLInstanceID == Targ_RPLInstanceID と D == 0 を持つ IPv6 RPL オプションを持つデータ パケットを受信するたびに、RREP-InstanceID を使用して適切な OF を識別できます。
OrigNode selects one of its IPv6 addresses and sets it in the DODAGID field of the RREQ-DIO message. The address scope of the selected address MUST encompass the domain where the route is built (e.g, not link-local); otherwise, the route discovery will fail. Exactly one RREQ option MUST be present in an RREQ-DIO message; otherwise, the message MUST be dropped.
OrigNode は、IPv6 アドレスの 1 つを選択し、それを RREQ-DIO メッセージの DODAGID フィールドに設定します。選択したアドレスのアドレス スコープは、ルートが構築されるドメインを包含しなければなりません (リンクローカルではないなど)。そうしないと、ルート検出が失敗します。RREQ-DIO メッセージには RREQ オプションが 1 つだけ存在する必要があります。それ以外の場合、メッセージは削除されなければなりません。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |S|H|X| Compr | L | RankLimit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Orig SeqNo | |
+-+-+-+-+-+-+-+-+ |
| |
| Address Vector (Optional, Variable Length) |
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . .
Figure 1: Format for AODV-RPL RREQ Option
図 1: AODV-RPL RREQ オプションのフォーマット
OrigNode supplies the following information in the RREQ option:
OrigNode は、RREQ オプションで次の情報を提供します。
Option Type
オプションの種類
8-bit unsigned integer specifying the type of the option (0x0B).
オプションのタイプを指定する 8 ビットの符号なし整数 (0x0B)。
Option Length
オプションの長さ
8-bit unsigned integer specifying the length of the option in octets, excluding the Option Type and Option Length fields. It is variable due to the presence of the Address Vector and the number of octets elided according to the Compr value.
オプションの長さをオクテット単位で指定する 8 ビットの符号なし整数 (オプション タイプ フィールドとオプション長フィールドを除く)。これは、アドレス ベクトルの存在と、Compr 値に応じて省略されるオクテットの数により変動します。
S
S
Symmetric bit indicating a symmetric route from the OrigNode to the router transmitting this RREQ-DIO. See Section 5.
OrigNode からこの RREQ-DIO を送信するルーターまでの対称ルートを示す対称ビット。セクション 5 を参照してください。
H
H
Set to one for a hop-by-hop route. Set to zero for a source route. This flag controls both the downstream route and upstream route.
ホップバイホップ ルートの場合は 1 に設定します。ソースルートの場合はゼロに設定します。このフラグは、下流ルートと上流ルートの両方を制御します。
X
×
Reserved. This field MUST be initialized to zero and ignored upon reception.
予約済み。このフィールドはゼロに初期化され、受信時に無視されなければなりません (MUST)。
Compr
比較
4-bit unsigned integer. When Compr is nonzero, exactly that number of prefix octets MUST be elided from each address before storing it in the Address Vector. The octets elided are shared with the IPv6 address in the DODAGID. This field is only used in source routing mode (H=0). In hop-by-hop mode (H=1), this field MUST be set to zero and ignored upon reception.
4 ビットの符号なし整数。Compr がゼロ以外の場合、アドレス ベクトルに格納する前に、正確にその数のプレフィックス オクテットを各アドレスから削除しなければなりません (MUST)。省略されたオクテットは、DODAGID の IPv6 アドレスと共有されます。このフィールドは、ソース ルーティング モード (H=0) でのみ使用されます。ホップバイホップ モード (H=1) では、このフィールドはゼロに設定され、受信時に無視されなければなりません (MUST)。
L
L
2-bit unsigned integer determining the time duration that a node is able to belong to the RREQ-Instance (a temporary DAG including the OrigNode and the TargNode). Once the time is reached, a node SHOULD leave the RREQ-Instance and stop sending or receiving any more DIOs for the RREQ-Instance; otherwise, memory and network resources are likely to be consumed unnecessarily. This naturally depends on the node's ability to keep track of time. Once a node leaves an RREQ-Instance, it MUST NOT rejoin the same RREQ-Instance for at least the time interval specified by the configuration variable REJOIN_REENABLE. L is independent from the route lifetime, which is defined in the DODAG configuration option.
ノードが RREQ インスタンス (OrigNode と TargNode を含む一時的な DAG) に属することができる期間を決定する 2 ビットの符号なし整数。時間に達したら、ノードは RREQ インスタンスを離れ、RREQ インスタンスに対するそれ以上の DIO の送受信を停止する必要があります (SHOULD)。そうしないと、メモリとネットワーク リソースが不必要に消費される可能性があります。これは当然、時間を追跡するノードの能力に依存します。ノードが RREQ インスタンスから離れると、少なくとも構成変数 REJOIN_REENABLE で指定された時間間隔は同じ RREQ インスタンスに再参加してはなりません。L は、DODAG 構成オプションで定義されるルートの存続期間から独立しています。
* 0x00: No time limit imposed
* 0x00: 時間制限なし
* 0x01: 16 seconds
* 0x01: 16秒
* 0x02: 64 seconds
* 0x02: 64秒
* 0x03: 256 seconds
* 0x03: 256 秒
RankLimit
ランク制限
8-bit unsigned integer specifying the upper limit on the integer portion of the Rank (calculated using the DAGRank() macro defined in [RFC6550]). A value of 0 in this field indicates the limit is infinity.
Rank の整数部分の上限を指定する 8 ビットの符号なし整数 ([RFC6550] で定義されている DAGRank() マクロを使用して計算)。このフィールドの値 0 は、制限が無限大であることを示します。
Orig SeqNo
元のシーケンス番号
8-bit unsigned integer specifying the Sequence Number of OrigNode. See Section 6.1.
OrigNode のシーケンス番号を指定する 8 ビットの符号なし整数。セクション 6.1 を参照してください。
Address Vector
アドレスベクトル
A vector of IPv6 addresses representing the route that the RREQ-DIO has passed. It is only present when the H bit is set to 0. The prefix of each address is elided according to the Compr field.
RREQ-DIO が通過したルートを表す IPv6 アドレスのベクトル。これは、H ビットが 0 に設定されている場合にのみ存在します。各アドレスのプレフィックスは、Compr フィールドに従って省略されます。
TargNode can join the RREQ-Instance at a Rank whose integer portion is less than or equal to the RankLimit. Any other node MUST NOT join an RREQ-Instance if its own Rank would be equal to or higher than the RankLimit. A router MUST discard a received RREQ if the integer part of the advertised Rank equals or exceeds the RankLimit.
TargNode は、整数部分が RankLimit 以下のランクで RREQ インスタンスに参加できます。他のノードは、自身のランクが RankLimit 以上である場合、RREQ インスタンスに参加してはなりません (MUST NOT)。ルータは、アドバタイズされた Rank の整数部分が RankLimit 以上の場合、受信した RREQ を破棄しなければなりません (MUST)。
TargNode sets one of its IPv6 addresses in the DODAGID field of the RREP-DIO message. The address scope of the selected address must encompass the domain where the route is built (e.g, not link-local). Exactly one RREP option MUST be present in an RREP-DIO message, otherwise, the message MUST be dropped. TargNode supplies the following information in the RREP option:
TargNode は、RREP-DIO メッセージの DODAGID フィールドに IPv6 アドレスの 1 つを設定します。選択したアドレスのアドレス スコープは、ルートが構築されるドメインを包含する必要があります (リンクローカルではないなど)。RREP-DIO メッセージには RREP オプションが 1 つだけ存在しなければなりません (MUST)。それ以外の場合、メッセージは削除されなければなりません (MUST)。TargNode は、RREP オプションで次の情報を提供します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |G|H|X| Compr | L | RankLimit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delta |X X| |
+-+-+-+-+-+-+-+-+ |
| |
| |
| Address Vector (Optional, Variable Length) |
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . .
Figure 2: Format for AODV-RPL RREP Option
図 2: AODV-RPL RREP オプションのフォーマット
Option Type
オプションの種類
8-bit unsigned integer specifying the type of the option (0x0C).
オプションのタイプを指定する 8 ビットの符号なし整数 (0x0C)。
Option Length
オプションの長さ
8-bit unsigned integer specifying the length of the option in octets, excluding the Option Type and Option Length fields. It is variable due to the presence of the Address Vector and the number of octets elided according to the Compr value.
オプションの長さをオクテット単位で指定する 8 ビットの符号なし整数 (オプション タイプ フィールドとオプション長フィールドを除く)。これは、アドレス ベクトルの存在と、Compr 値に応じて省略されるオクテットの数により変動します。
G
G
Gratuitous RREP (see Section 7).
無償の RREP (セクション 7 を参照)。
H
H
The H bit in the RREP option MUST be set to be the same as the H bit in the RREQ option. It requests either source routing (H=0) or hop-by-hop (H=1) for the downstream route.
RREP オプションの H ビットは、RREQ オプションの H ビットと同じに設定する必要があります。ダウンストリーム ルートに対してソース ルーティング (H=0) またはホップバイホップ (H=1) のいずれかを要求します。
X
×
1-bit Reserved field. This field MUST be initialized to zero and ignored upon reception.
1 ビットの予約済みフィールド。このフィールドはゼロに初期化され、受信時に無視されなければなりません (MUST)。
Compr
比較
4-bit unsigned integer. This field has the same definition as in the RREQ option.
4 ビットの符号なし整数。このフィールドには、RREQ オプションと同じ定義があります。
L
L
2-bit unsigned integer defined as in the RREQ option. The lifetime of the RREP-Instance SHOULD be no greater than the lifetime of the RREQ-Instance to which it is paired, so that the memory required to store the RREP-Instance can be reclaimed when no longer needed.
RREQ オプションで定義された 2 ビットの符号なし整数。RREP インスタンスの保存に必要なメモリが不要になったときに再利用できるように、RREP インスタンスの存続期間は、ペアになっている RREQ インスタンスの存続期間を超えてはなりません (SHOULD)。
RankLimit
ランク制限
8-bit unsigned integer specifying the upper limit on the integer portion of the Rank, similarly to RankLimit in the RREQ message. A value of 0 in this field indicates the limit is infinity.
RREQ メッセージの RankLimit と同様に、ランクの整数部分の上限を指定する 8 ビットの符号なし整数。このフィールドの値 0 は、制限が無限大であることを示します。
Delta
デルタ
6-bit unsigned integer. TargNode uses the Delta field so that nodes receiving its RREP message can identify the RREQ-InstanceID of the RREQ message that triggered the transmission of the RREP (see Section 6.3.3).
6 ビットの符号なし整数。TargNode は、RREP メッセージを受信するノードが RREP の送信をトリガーした RREQ メッセージの RREQ-InstanceID を識別できるように、Delta フィールドを使用します (セクション 6.3.3 を参照)。
X X
X X
2-bit Reserved field. This field MUST be initialized to zero and ignored upon reception.
2 ビットの予約済みフィールド。このフィールドはゼロに初期化され、受信時に無視されなければなりません (MUST)。
Address Vector
アドレスベクトル
Only present when the H bit is set to 0. The prefix of each address is elided according to the Compr field. For an asymmetric route, the Address Vector represents the IPv6 addresses of the path through the network the RREP-DIO has passed. In contrast, for a symmetric route, it is the Address Vector when the RREQ-DIO arrives at the TargNode, unchanged during the transmission to the OrigNode.
H ビットが 0 に設定されている場合にのみ存在します。各アドレスのプレフィックスは Compr フィールドに従って省略されます。非対称ルートの場合、アドレス ベクトルは、RREP-DIO が通過したネットワーク内のパスの IPv6 アドレスを表します。対照的に、対称ルートの場合、RREQ-DIO が TargNode に到着するときのアドレス ベクトルであり、OrigNode への送信中に変更されません。
The AODV-RPL Target (ART) option is based on the Target option in the core RPL specification [RFC6550]. The Flags field is replaced by the Destination Sequence Number of the TargNode, and the Prefix Length field is reduced to 7 bits so that the value is limited to be no greater than 127.
AODV-RPL ターゲット (ART) オプションは、コア RPL 仕様 [RFC6550] のターゲット オプションに基づいています。Flags フィールドは TargNode の Destination Sequence Number に置き換えられ、Prefix Length フィールドは 7 ビットに削減され、値が 127 以下に制限されます。
An RREQ-DIO message MUST carry at least one ART option. An RREP-DIO message MUST carry exactly one ART option. Otherwise, the message MUST be dropped.
RREQ-DIO メッセージには、少なくとも 1 つの ART オプションを含める必要があります。RREP-DIO メッセージには、ART オプションを 1 つだけ含める必要があります。それ以外の場合、メッセージは削除されなければなりません。
OrigNode can include multiple TargNode addresses via multiple ART options in the RREQ-DIO, for routes that share the same requirement on metrics. This reduces the cost to building only one DODAG for multiple targets.
OrigNode には、メトリックに関する同じ要件を共有するルートに対して、RREQ-DIO の複数の ART オプションを介して複数の TargNode アドレスを含めることができます。これにより、複数のターゲットに対して DODAG を 1 つだけ構築するコストが削減されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length | Dest SeqNo |X|Prefix Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ |
| Target Prefix / Address (Variable Length) |
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . .
Figure 3: ART Option Format for AODV-RPL
図 3: AODV-RPL の ART オプション フォーマット
Option Type
オプションの種類
8-bit unsigned integer specifying the type of the option (0x0D).
オプションのタイプを指定する 8 ビットの符号なし整数 (0x0D)。
Option Length
オプションの長さ
8-bit unsigned integer specifying the length of the option in octets, excluding the Option Type and Option Length fields.
オプションの長さをオクテット単位で指定する 8 ビットの符号なし整数 (オプション タイプ フィールドとオプション長フィールドを除く)。
Dest SeqNo
宛先シーケンス番号
8-bit unsigned integer. In RREQ-DIO, if nonzero, it is the Sequence Number for the last route that OrigNode stored to the TargNode for which a route is desired. In RREP-DIO, it is the Destination Sequence Number associated to the route. Zero is used if there is no known information about the Sequence Number of TargNode and not used otherwise.
8 ビットの符号なし整数。RREQ-DIO では、ゼロ以外の場合、OrigNode がルートを必要とする TargNode に保存した最後のルートのシーケンス番号になります。RREP-DIO では、ルートに関連付けられた宛先シーケンス番号です。TargNode のシーケンス番号に関する既知の情報がない場合は 0 が使用され、それ以外の場合は使用されません。
X
×
1-bit Reserved field. This field MUST be initialized to zero by the sender and MUST be ignored by the receiver.
1 ビットの予約済みフィールド。このフィールドは送信者によってゼロに初期化されなければならず、受信者によって無視されなければなりません。
Prefix Length
プレフィックスの長さ
7-bit unsigned integer. The Prefix Length field contains the number of valid leading bits in the prefix. If Prefix Length is 0, then the value in the Target Prefix / Address field represents an IPv6 address, not a prefix.
7 ビットの符号なし整数。プレフィックス長フィールドには、プレフィックス内の有効な先頭ビットの数が含まれます。[プレフィックス長] が 0 の場合、[ターゲット プレフィックス / アドレス] フィールドの値はプレフィックスではなく IPv6 アドレスを表します。
Target Prefix / Address
ターゲットのプレフィックス/アドレス
A variable-length field with an IPv6 destination address or prefix. The length of the Target Prefix / Address field is the least number of octets that can represent all of the bits of the Prefix, in other words, Ceil(Prefix Length/8) octets. When Prefix Length is not equal to 8*Ceil(Prefix Length/8) and nonzero, the Target Prefix / Address field will contain some initial bits that are not part of the Target Prefix. Those initial bits (if any) MUST be set to zero on transmission and MUST be ignored on receipt. If Prefix Length is zero, the Address field is 128 bits.
IPv6 宛先アドレスまたはプレフィックスを含む可変長フィールド。ターゲット プレフィックス / アドレス フィールドの長さは、プレフィックスのすべてのビットを表すことができる最小オクテット数、つまり Ceil(プレフィックス長/8) オクテットです。プレフィックス長が 8*Ceil(プレフィックス長/8) に等しくなく、ゼロ以外の場合、ターゲット プレフィックス / アドレス フィールドには、ターゲット プレフィックスの一部ではないいくつかの初期ビットが含まれます。これらの初期ビット (存在する場合) は送信時にゼロに設定されなければならず、受信時には無視されなければなりません。プレフィックス長が 0 の場合、アドレス フィールドは 128 ビットです。
Links are considered symmetric until indication to the contrary is received. In Figures 4 and 5, BR is the Border Router, O is the OrigNode, each R is an intermediate router, and T is the TargNode. In these examples, the use of BR is only for illustrative purposes; AODV does not depend on the use of border routers for its operation. If the RREQ-DIO arrives over an interface that is known to be symmetric and the S bit is set to 1, then it remains as 1, as illustrated in Figure 4. If an intermediate router sends out RREQ-DIO with the S bit set to 1, then each link en route from the OrigNode O to this router has met the requirements of route discovery, and the route can be used symmetrically.
リンクは、反対の指示が受信されるまで対称であるとみなされます。図 4 と 5 では、BR はボーダー ルーター、O は OrigNode、各 R は中間ルーター、T は TargNode です。これらの例では、BR の使用は説明のみを目的としています。AODV は、その動作において境界ルーターの使用に依存しません。RREQ-DIO が対称であることがわかっているインターフェイス経由で到着し、S ビットが 1 に設定されている場合、図 4 に示すように、1 のままになります。中間ルーターが S ビットを 1 に設定して RREQ-DIO を送信する場合、OrigNode O からこのルーターに向かう途中の各リンクはルート検出の要件を満たしており、ルートは対称的に使用できます。
BR
/----+----\
/ | \
/ | \
R R R
_/ \ | / \
/ \ | / \
/ \ | / \
R -------- R --- R ----- R -------- R
/ \ <--S=1--> / \ <--S=1--> / \
<--S=1--> \ / \ / <--S=1-->
/ \ / \ / \
O ---------- R ------ R------ R ----- R ----------- T
/ \ / \ / \ / \
/ \ / \ / \ / \
/ \ / \ / \ / \
R ----- R ----------- R ----- R ----- R ----- R ---- R----- R
>---- RREQ-Instance (Control: O-->T; Data: T-->O) ------->
<---- RREP-Instance (Control: T-->O; Data: O-->T) -------<
Figure 4: AODV-RPL with Symmetric Instances
図 4: 対称インスタンスを使用した AODV-RPL
Upon receiving an RREQ-DIO with the S bit set to 1, a node determines whether the link over which it was received can be used symmetrically, i.e., both directions meet the requirements of data transmission. If the RREQ-DIO arrives over an interface that is not known to be symmetric or is known to be asymmetric, the S bit is set to 0. If the S bit arrives already set to be 0, then it is set to be 0 when the RREQ-DIO is propagated (Figure 5). For an asymmetric route, there is at least one hop that doesn't satisfy the OF. Based on the S bit received in RREQ-DIO, TargNode T determines whether or not the route is symmetric before transmitting the RREP-DIO message upstream towards the OrigNode O.
S ビットが 1 に設定された RREQ-DIO を受信すると、ノードは受信したリンクが対称的に使用できるかどうか、つまり両方向がデータ送信の要件を満たしているかどうかを判断します。RREQ-DIO が対称であるかどうかが不明なインターフェイス、または非対称であることがわかっているインターフェイス経由で到着した場合、S ビットは 0 に設定されます。S ビットがすでに 0 に設定されて到着した場合は、RREQ-DIO が伝播されるときに 0 に設定されます (図 5)。非対称ルートの場合、OF を満たさないホップが少なくとも 1 つあります。TargNode T は、RREQ-DIO で受信した S ビットに基づいて、RREP-DIO メッセージを OrigNode O に向けてアップストリームに送信する前に、ルートが対称かどうかを判断します。
It is beyond the scope of this document to specify the criteria used when determining whether or not each link is symmetric. As an example, intermediate routers can use local information (e.g., bit rate, bandwidth, number of cells used in 6TiSCH [RFC9030]), a priori knowledge (e.g., link quality according to previous communication), or averaging techniques as appropriate to the application. Other link metric information can be acquired before AODV-RPL operation, by executing evaluation procedures; for instance, test traffic can be generated between nodes of the deployed network. During AODV-RPL operation, Operations, Administration, and Maintenance (OAM) techniques for evaluating link state (see [RFC7548], [RFC7276], and [co-ioam]) MAY be used (at regular intervals appropriate for the LLN). The evaluation procedures are out of scope for AODV-RPL. For further information on this topic, see [Link_Asymmetry], [low-power-wireless], and [empirical-study].
各リンクが対称かどうかを判断するときに使用される基準を指定することは、このドキュメントの範囲を超えています。一例として、中間ルータは、アプリケーションに応じて、ローカル情報（ビットレート、帯域幅、6TiSCH [RFC9030]で使用されるセルの数など）、事前知識（以前の通信によるリンク品質など）、または平均化技術を使用できます。他のリンク メトリック情報は、評価手順を実行することによって、AODV-RPL の動作前に取得できます。たとえば、展開されたネットワークのノード間でテスト トラフィックを生成できます。AODV-RPL の動作中、リンク状態を評価するための運用、管理、保守 (OAM) 技術 ([RFC7548]、[RFC7276]、および [co-ioam] を参照) を (LLN に適した定期的な間隔で) 使用してもよい(MAY)。評価手順は AODV-RPL の範囲外です。このトピックの詳細については、[Link_Asymmetry]、[low-power-wireless]、[empirical-study] を参照してください。
Appendix A describes an example method using the upstream Expected Transmission Count (ETX) and downstream Received Signal Strength Indicator (RSSI) to estimate whether the link is symmetric in terms of link quality using an averaging technique.
付録 A では、アップストリームの予想送信数 (ETX) とダウンストリームの受信信号強度インジケーター (RSSI) を使用して、平均化手法を使用してリンク品質の点でリンクが対称であるかどうかを推定する方法の例について説明します。
BR
/----+----\
/ | \
/ | \
R R R
/ \ | / \
/ \ | / \
/ \ | / \
R --------- R --- R ---- R --------- R
/ \ --S=1--> / \ --S=0--> / \
--S=1--> \ / \ / --S=0-->
/ \ / \ / \
O ---------- R ------ R------ R ----- R ----------- T
/ \ / \ / \ / \
/ <--S=0-- / \ / \ / <--S=0--
/ \ / \ / \ / \
R ----- R ----------- R ----- R ----- R ----- R ---- R----- R
<--S=0-- <--S=0-- <--S=0-- <--S=0-- <--S=0--
>---- RREQ-Instance (Control: O-->T; Data: T-->O) ------->
<---- RREP-Instance (Control: T-->O; Data: O-->T) -------<
Figure 5: AODV-RPL with Asymmetric Paired Instances
図 5: 非対称ペアインスタンスを使用した AODV-RPL
As illustrated in Figure 5, an intermediate router determines the S bit value that the RREQ-DIO should carry using link asymmetry detection methods as discussed earlier in this section. In many cases, the intermediate router has already made the link asymmetry decision by the time RREQ-DIO arrives.
図 5 に示すように、中間ルーターは、このセクションで前述したリンク非対称検出方法を使用して、RREQ-DIO が伝送する必要がある S ビット値を決定します。多くの場合、RREQ-DIO が到着するまでに、中間ルーターはリンクの非対称性をすでに決定しています。
See Appendix B for examples illustrating RREQ and RREP transmissions in some networks with symmetric and asymmetric links.
対称リンクと非対称リンクを備えた一部のネットワークにおける RREQ および RREP 送信を示す例については、付録 B を参照してください。
The route discovery process is initiated when an application at the OrigNode has data to be transmitted to the TargNode but does not have a route that satisfies the OF for the target of the application's data. In this case, the OrigNode builds a local RPL Instance and a DODAG rooted at itself. Then, it transmits a DIO message containing exactly one RREQ option (see Section 4.1) to multicast group all-AODV-RPL-nodes. The RREQ-DIO MUST contain at least one ART option (see Section 4.3), which indicates the TargNode. The S bit in RREQ-DIO sent out by the OrigNode is set to 1.
ルート発見プロセスは、OrigNode のアプリケーションが TargNode に送信するデータを持っているが、アプリケーションのデータのターゲットの OF を満たすルートを持っていない場合に開始されます。この場合、OrigNode はローカル RPL インスタンスとそれ自体をルートとする DODAG を構築します。次に、RREQ オプション (セクション 4.1 を参照) を 1 つだけ含む DIO メッセージをマルチキャスト グループの全 AODV-RPL ノードに送信します。RREQ-DIO には、TargNode を示す ART オプション (セクション 4.3 を参照) が少なくとも 1 つ含まれていなければなりません (MUST)。OrigNode によって送信される RREQ-DIO の S ビットは 1 に設定されます。
Each node maintains a Sequence Number; the operation is specified in Section 7.2 of [RFC6550]. When the OrigNode initiates a route discovery process, it MUST increase its own Sequence Number to avoid conflicts with previously established routes. The Sequence Number is carried in the Orig SeqNo field of the RREQ option.
各ノードはシーケンス番号を維持します。この操作は [RFC6550] のセクション 7.2 で規定されています。OrigNode がルート検出プロセスを開始するとき、以前に確立されたルートとの競合を避けるために、自身のシーケンス番号を増加しなければなりません (MUST)。シーケンス番号は、RREQ オプションの Orig SeqNo フィールドで伝えられます。
The Target Prefix / Address in the ART option can be a unicast IPv6 address or a prefix. The OrigNode can initiate the route discovery process for multiple targets simultaneously by including multiple ART options. Within an RREQ-DIO, the OF for the routes to different TargNodes MUST be the same.
ART オプションのターゲット プレフィックス / アドレスは、ユニキャスト IPv6 アドレスまたはプレフィックスにすることができます。OrigNode は、複数の ART オプションを含めることで、複数のターゲットのルート検出プロセスを同時に開始できます。RREQ-DIO 内では、異なる TargNode へのルートの OF は同じでなければなりません (MUST)。
OrigNode can maintain different RPL Instances to discover routes with different requirements to the same targets. Using the RPLInstanceID pairing mechanism (see Section 6.3.3), route replies (RREP-DIOs) for different RPL Instances can be generated.
OrigNode は、異なる RPL インスタンスを維持して、同じターゲットへの異なる要件を持つルートを検出できます。RPLInstanceID ペアリング メカニズム (セクション 6.3.3 を参照) を使用すると、さまざまな RPL インスタンスのルート応答 (RREP-DIO) を生成できます。
The transmission of RREQ-DIO obeys the Trickle timer [RFC6206]. If the duration specified by the L field has elapsed, the OrigNode MUST leave the DODAG and stop sending RREQ-DIOs in the related RPL Instance. OrigNode needs to set the L field such that the DODAG will not prematurely timeout during data transfer with the TargNode. For setting this value, it has to consider factors such as the Trickle timer, TargNode hop distance, network size, link behavior, expected data usage time, and so on.
RREQ-DIO の送信は Trickle タイマー [RFC6206] に従います。L フィールドで指定された期間が経過した場合、OrigNode は DODAG を離れ、関連する RPL インスタンスでの RREQ-DIO の送信を停止しなければなりません (MUST)。OrigNode は、TargNode とのデータ転送中に DODAG が早期にタイムアウトしないように、L フィールドを設定する必要があります。この値を設定するには、Trickle タイマー、TargNode ホップ距離、ネットワーク サイズ、リンク動作、予想されるデータ使用時間などの要素を考慮する必要があります。
When a router X receives an RREQ message over a link from a neighbor Y, X first determines whether or not the RREQ is valid. If valid, X then determines whether or not it has sufficient resources available to maintain the RREQ-Instance and the value of the S bit needed to process an eventual RREP, if the RREP were to be received. If not valid, then X MUST either free up sufficient resources (the means for this are beyond the scope of this document), or drop the packet and discontinue processing of the RREQ. Otherwise, X next determines whether the RREQ advertises a usable route to OrigNode, by checking whether the link to Y can be used to transmit packets to OrigNode.
ルータ X が近隣 Y からリンクを介して RREQ メッセージを受信すると、X はまず RREQ が有効かどうかを判断します。有効な場合、X は、RREQ インスタンスを維持するために利用可能な十分なリソースがあるかどうか、および RREP が受信された場合に最終的な RREP を処理するために必要な S ビットの値があるかどうかを判断します。有効でない場合、X は十分なリソースを解放するか (その手段はこの文書の範囲外です)、パケットをドロップして RREQ の処理を中止しなければなりません。それ以外の場合、X は次に、Y へのリンクを使用して OrigNode にパケットを送信できるかどうかを確認することにより、RREQ が OrigNode に使用可能なルートをアドバタイズするかどうかを判断します。
When H=0 in the incoming RREQ, the router MUST drop the RREQ-DIO if one of its addresses is present in the Address Vector. When H=1 in the incoming RREQ, the router MUST drop the RREQ message if the Orig SeqNo field of the RREQ is older than the SeqNo value that X has stored for a route to OrigNode. Otherwise, the router determines whether to propagate the RREQ-DIO. It does this by determining whether or not a route to OrigNode using the upstream direction of the incoming link satisfies the Objective Function (OF). In order to evaluate the OF, the router first determines the maximum useful Rank (MaxUsefulRank). If the router has previously joined the RREQ-Instance associated with the RREQ-DIO, then MaxUsefulRank is set to be the Rank value that was stored when the router processed the best previous RREQ for the DODAG with the given RREQ-Instance. Otherwise, MaxUsefulRank is set to be RankLimit. If OF cannot be satisfied (i.e., the Rank evaluates to a value greater than MaxUsefulRank), the RREQ-DIO MUST be dropped, and the following steps are not processed. Otherwise, the router MUST join the RREQ-Instance and prepare to propagate the RREQ-DIO, as follows. The upstream neighbor router that transmitted the received RREQ-DIO is selected as the preferred parent in the RREQ-Instance.
受信 RREQ で H=0 の場合、ルータは、そのアドレスの 1 つがアドレス ベクトルに存在する場合、RREQ-DIO をドロップしなければなりません (MUST)。受信 RREQ で H=1 のとき、RREQ の Orig SeqNo フィールドが OrigNode へのルート用に X が保存した SeqNo 値よりも古い場合、ルータは RREQ メッセージをドロップしなければなりません (MUST)。それ以外の場合、ルーターは RREQ-DIO を伝播するかどうかを決定します。これは、受信リンクの上流方向を使用した OrigNode へのルートが目的関数 (OF) を満たすかどうかを判断することによって行われます。OF を評価するために、ルーターは最初に最大有用ランク (MaxUsefulRank) を決定します。ルータが以前に RREQ-DIO に関連付けられた RREQ インスタンスに参加している場合、MaxUsefulRank は、ルータが指定された RREQ インスタンスで DODAG の以前の最良の RREQ を処理したときに保存されたランク値に設定されます。それ以外の場合、MaxUsefulRank は RankLimit に設定されます。OF が満たされない場合 (つまり、Rank が MaxUsefulRank より大きい値に評価される場合)、RREQ-DIO は削除されなければならず、次のステップは処理されません。それ以外の場合、ルータは次のように RREQ インスタンスに参加し、RREQ-DIO を伝播する準備をしなければなりません (MUST)。受信した RREQ-DIO を送信した上流の隣接ルータが、RREQ-Instance の優先親として選択されます。
After determining that a received RREQ provides a usable route to OrigNode, a router determines whether it is a TargNode, a possible intermediate router between OrigNode and a TargNode, or both. The router is a TargNode if it finds one of its own addresses in a Target option in the RREQ. After possibly propagating the RREQ according to the procedures in Steps 3, 4, and 5, the TargNode generates an RREP as specified in Section 6.3. If S=0, the determination of TargNode status and determination of a usable route to OrigNode is the same.
受信した RREQ が OrigNode への使用可能なルートを提供していると判断した後、ルーターは、それが TargNode、OrigNode と TargNode の間の可能な中間ルーター、またはその両方であるかどうかを判断します。ルーターは、RREQ のターゲット オプションで独自のアドレスの 1 つを見つけた場合、TargNode になります。おそらくステップ 3、4、および 5 の手順に従って RREQ を伝播した後、TargNode はセクション 6.3 で指定されているように RREP を生成します。S=0 の場合、TargNode ステータスの決定と OrigNode までの使用可能なルートの決定は同じです。
If the OrigNode tries to reach multiple TargNodes in a single RREQ-Instance, one of the TargNodes can be an intermediate router to other TargNodes. In this case, before transmitting the RREQ-DIO to multicast group all-AODV-RPL-nodes, a TargNode MUST delete the Target option encapsulating its own address, so that downstream routers with higher Rank values do not try to create a route to this TargNode.
OrigNode が 1 つの RREQ インスタンス内の複数の TargNode に到達しようとすると、TargNode の 1 つが他の TargNode への中間ルーターになる可能性があります。この場合、RREQ-DIO をマルチキャスト グループの全 AODV-RPL ノードに送信する前に、TargNode は自身のアドレスをカプセル化している Target オプションを削除し、より高い Rank 値を持つダウンストリーム ルーターがこの TargNode へのルートを作成しようとしないようにしなければなりません (MUST)。
An intermediate router could receive several RREQ-DIOs from routers with lower Rank values in the same RREQ-Instance with different lists of Target options. For the purposes of determining the intersection with previous incoming RREQ-DIOs, the intermediate router maintains a record of the targets that have been requested for a given RREQ-Instance. An incoming RREQ-DIO message having multiple ART options coming from a router with higher Rank than the Rank of the stored targets is ignored. When transmitting the RREQ-DIO, the intersection of all received lists MUST be included if it is nonempty after TargNode has deleted the Target option encapsulating its own address. If the intersection is empty, it means that all the targets have been reached, and the router MUST NOT transmit any RREQ-DIO. Otherwise, it proceeds to Section 6.2.3.
中間ルーターは、ターゲット オプションの異なるリストを持つ同じ RREQ インスタンス内のランク値が低いルーターから複数の RREQ-DIO を受信する可能性があります。以前に受信した RREQ-DIO との交差を判断するために、中間ルーターは、特定の RREQ インスタンスに対して要求されたターゲットの記録を保持します。格納されたターゲットのランクよりも高いランクを持つルータからの複数の ART オプションを持つ着信 RREQ-DIO メッセージは無視されます。RREQ-DIO を送信するとき、TargNode が自身のアドレスをカプセル化する Target オプションを削除した後、空でない場合は、受信したすべてのリストの共通部分を含める必要があります。交差点が空の場合は、すべてのターゲットに到達したことを意味し、ルータは RREQ-DIO を送信してはなりません (MUST NOT)。それ以外の場合は、セクション 6.2.3 に進みます。
For example, suppose two RREQ-DIOs are received with the same RPL Instance and OrigNode. Suppose further that the first RREQ has (T1, T2) as the targets, and the second one has (T2, T4) as targets. Then, only T2 needs to be included in the generated RREQ-DIO.
たとえば、2 つの RREQ-DIO が同じ RPL インスタンスと OrigNode で受信されたとします。さらに、最初の RREQ がターゲットとして (T1、T2) を持ち、2 番目の RREQ がターゲットとして (T2、T4) を持っているとします。したがって、生成される RREQ-DIO には T2 のみが含まれる必要があります。
The reasoning for using the intersection of the lists in the RREQs is as follows. When two or more RREQs are received with the same Orig SeqNo, they were transmitted by OrigNode with the same destinations and OF. When an intermediate node receives two RREQs with the same Orig SeqNo but different lists of destinations, that means that some intermediate nodes retransmitting the RREQs have already deleted themselves from the list of destinations before they retransmitted the RREQ. Those deleted nodes are not to be reinserted back into the list of destinations.
RREQ でリストの共通部分を使用する理由は次のとおりです。2 つ以上の RREQ が同じ Orig SeqNo で受信された場合、それらは同じ宛先と OF で OrigNode によって送信されました。中間ノードが、Orig SeqNo は同じだが宛先リストが異なる 2 つの RREQ を受信した場合、RREQ を再送信する一部の中間ノードが、RREQ を再送信する前に宛先リストからすでに自身を削除していることを意味します。削除されたノードは宛先リストに再挿入されません。
The intermediate router establishes itself as a viable node for a route to OrigNode as follows. If the H bit is set to 1, for a hop-by-hop route, then the router MUST build or update its upward route entry towards OrigNode, which includes at least the following items: Source Address, RPLInstanceID, Destination Address, Next Hop, Lifetime, and Sequence Number. The Destination Address and the RPLInstanceID can be learned from the DODAGID and the RPLInstanceID of the RREQ-DIO, respectively. The Source Address is the address used by the router to send data to the Next Hop, i.e., the preferred parent. The lifetime is set according to DODAG configuration (not the L field) and can be extended when the route is actually used. The Sequence Number represents the freshness of the route entry; it is copied from the Orig SeqNo field of the RREQ option. A route entry with the same source and destination address and the same RPLInstanceID, but a stale Sequence Number (i.e., incoming Sequence Number is less than the currently stored Sequence Number of the route entry), MUST be deleted.
中間ルーターは、次のように、OrigNode へのルートの実行可能なノードとして自身を確立します。ホップバイホップ ルートの場合、H ビットが 1 に設定されている場合、ルータは、少なくとも次の項目を含む、OrigNode への上向きルート エントリを構築または更新しなければなりません (MUST)。送信元アドレス、RPLInstanceID、宛先アドレス、ネクスト ホップ、ライフタイム、およびシーケンス番号。宛先アドレスと RPLInstanceID は、それぞれ RREQ-DIO の DODAGID と RPLInstanceID から知ることができます。送信元アドレスは、ルーターが次のホップ、つまり優先される親にデータを送信するために使用するアドレスです。ライフタイムは DODAG 設定 (L フィールドではなく) に従って設定され、ルートが実際に使用されるときに延長できます。シーケンス番号はルート エントリの新鮮さを表します。これは、RREQ オプションの Orig SeqNo フィールドからコピーされます。送信元アドレスと宛先アドレスが同じで、RPLInstanceID が同じであるが、シーケンス番号が古い (つまり、受信したシーケンス番号が現在保存されているルート エントリのシーケンス番号より小さい) ルート エントリは、削除しなければなりません (MUST)。
If the S bit of the incoming RREQ-DIO is 0, then the route cannot be symmetric, and the S bit of the RREQ-DIO to be transmitted is set to 0. Otherwise, the router MUST determine whether the downward direction (i.e., towards the TargNode) of the incoming link satisfies the OF. If it does, the S bit of the RREQ-DIO to be transmitted is set to 1. Otherwise, the S bit of the RREQ-DIO to be transmitted is set to 0.
着信 RREQ-DIO の S ビットが 0 の場合、ルートは対称であることができず、送信される RREQ-DIO の S ビットは 0 に設定されます。そうでない場合、ルータは着信リンクの下向き方向 (つまり、TargNode に向かう方向) が OF を満たすかどうかを判断しなければなりません (MUST)。そうである場合、送信される RREQ-DIO の S ビットは 1 に設定されます。そうでない場合、送信される RREQ-DIO の S ビットは 0 に設定されます。
When a router joins the RREQ-Instance, it also associates within its data structure for the RREQ-Instance the information about whether or not the RREQ-DIO to be transmitted has the S bit set to 1. This information associated to RREQ-Instance is known as the S bit of the RREQ-Instance. It will be used later during the RREP-DIO message processing (see Section 6.3.2).
ルーターが RREQ インスタンスに参加すると、RREQ インスタンスのデータ構造内で、送信される RREQ-DIO の S ビットが 1 に設定されているかどうかに関する情報も関連付けられます。RREQ インスタンスに関連付けられたこの情報は、RREQ インスタンスの S ビットとして知られています。これは、後の RREP-DIO メッセージ処理中に使用されます (セクション 6.3.2 を参照)。
Suppose a router has joined the RREQ-Instance, the H bit is set to 0, and the S bit of the RREQ-Instance is set to 1. In this case, the router MAY optionally include the Address Vector of the symmetric route back to OrigNode as part of the RREQ-Instance data. This is useful if the router later receives an RREP-DIO that is paired with the RREQ-Instance. If the router does NOT include the Address Vector, then it has to rely on multicast for the RREP. The multicast can impose a substantial performance penalty.
ルーターが RREQ インスタンスに参加し、RREQ インスタンスの H ビットが 0 に設定され、S ビットが 1 に設定されているとします。この場合、ルーターは、RREQ インスタンス データの一部として、OrigNode に戻る対称ルートのアドレス ベクトルをオプションで含めてもよい(MAY)。これは、ルーターが RREQ インスタンスとペアになっている RREP-DIO を後で受信する場合に便利です。ルータにアドレス ベクトルが含まれていない場合、RREP にはマルチキャストに依存する必要があります。マルチキャストはパフォーマンスに大幅なペナルティを課す可能性があります。
If the router is an intermediate router, then it transmits the RREQ-DIO to the multicast group all-AODV-RPL-nodes; if the H bit is set to 0, the intermediate router MUST append the address of its interface receiving the RREQ-DIO into the Address Vector. In addition, if the address of the router's interface transmitting the RREQ-DIO is not the same as the address of the interface receiving the RREQ-DIO, the router MUST also append the transmitting interface address into the Address Vector.
ルータが中間ルータの場合、RREQ-DIO をマルチキャスト グループ all-AODV-RPL-nodes に送信します。H ビットが 0 に設定されている場合、中間ルータは RREQ-DIO を受信するインターフェイスのアドレスをアドレス ベクトルに追加しなければなりません (MUST)。さらに、RREQ-DIO を送信するルータのインターフェイスのアドレスが RREQ-DIO を受信するインターフェイスのアドレスと同じでない場合、ルータは送信インターフェイスのアドレスもアドレス ベクトルに追加しなければなりません (MUST)。
If the router is a TargNode and was already associated with the RREQ-Instance, it takes no further action and does not send an RREP-DIO. If TargNode is not already associated with the RREQ-Instance, it prepares and transmits an RREP-DIO, possibly after waiting for RREP_WAIT_TIME, as detailed in (Section 6.3).
ルーターが TargNode であり、既に RREQ インスタンスに関連付けられている場合、それ以上のアクションは実行されず、RREP-DIO は送信されません。TargNode がまだ RREQ-Instance に関連付けられていない場合、(セクション 6.3) で詳しく説明されているように、おそらく RREP_WAIT_TIME を待った後、RREP-DIO を準備して送信します。
When a TargNode receives an RREQ message over a link from a neighbor Y, TargNode first follows the procedures in Section 6.2. If the link to Y can be used to transmit packets to OrigNode, TargNode generates an RREP according to Sections 6.3.1 and 6.3.2. Otherwise, TargNode drops the RREQ and does not generate an RREP.
TargNode が近隣 Y からリンクを介して RREQ メッセージを受信すると、TargNode はまずセクション 6.2 の手順に従います。Y へのリンクを使用して OrigNode にパケットを送信できる場合、TargNode はセクション 6.3.1 および 6.3.2 に従って RREP を生成します。それ以外の場合、TargNode は RREQ をドロップし、RREP を生成しません。
If the L field is not 0, the TargNode MAY delay transmitting the RREP-DIO for the duration RREP_WAIT_TIME to await a route with a lower Rank. The value of RREP_WAIT_TIME is set by default to 1/4 of the duration determined by the L field. For L == 0, RREP_WAIT_TIME is set by default to 0. Depending upon the application, RREP_WAIT_TIME may be set to other values. Smaller values enable quicker formation for the P2P route. Larger values enable formation of P2P routes with better Rank values.
L フィールドが 0 でない場合、TargNode は、より低いランクのルートを待つために、RREP_WAIT_TIME の間、RREP-DIO の送信を遅延してもよい(MAY)。RREP_WAIT_TIME の値は、デフォルトでは、L フィールドによって決定される期間の 1/4 に設定されます。L == 0 の場合、RREP_WAIT_TIME はデフォルトで 0 に設定されます。アプリケーションによっては、RREP_WAIT_TIME が他の値に設定される場合があります。値が小さいほど、P2P ルートの形成が速くなります。値を大きくすると、より良いランク値で P2P ルートを形成できます。
The address of the OrigNode MUST be encapsulated in the ART option and included in this RREP-DIO message along with the SeqNo of TargNode.
OrigNode のアドレスは ART オプションにカプセル化され、TargNode の SeqNo とともにこの RREP-DIO メッセージに含まれなければなりません (MUST)。
If the RREQ-Instance corresponding to the RREQ-DIO that arrived at TargNode has the S bit set to 1, there is a symmetric route, both of whose directions satisfy the OF. Other RREQ-DIOs might later provide better upward routes. The method of selection between a qualified symmetric route and an asymmetric route that might have better performance is implementation specific and out of scope.
TargNode に到着した RREQ-DIO に対応する RREQ-Instance の S ビットが 1 に設定されている場合、対称ルートが存在し、その両方の方向が OF を満たします。他の RREQ-DIO は、後でより優れた上向きルートを提供する可能性があります。適格な対称ルートとパフォーマンスが向上する可能性のある非対称ルートの間で選択する方法は実装固有であり、範囲外です。
For a symmetric route, the RREP-DIO message is unicast to the Next Hop according to the Address Vector (H=0) or the route entry (H=1); the DODAG in RREP-Instance does not need to be built. The RPLInstanceID in the RREP-Instance is paired as defined in Section 6.3.3. If the H bit is set to 0, the Address Vector from the RREQ-DIO MUST be included in the RREP-DIO.
対称ルートの場合、RREP-DIO メッセージは、アドレス ベクトル (H=0) またはルート エントリ (H=1) に従ってネクスト ホップにユニキャストされます。RREP インスタンスの DODAG を構築する必要はありません。RREP-Instance 内の RPLInstanceID は、セクション 6.3.3 で定義されているようにペアになっています。H ビットが 0 に設定されている場合、RREQ-DIO からのアドレス ベクトルが RREP-DIO に含まれなければなりません。
When an RREQ-DIO arrives at a TargNode with the S bit set to 0, the TargNode MUST build a DODAG in the RREP-Instance corresponding to the RREQ-DIO rooted at itself, in order to provide OrigNode with a downstream route to the TargNode. The RREP-DIO message is transmitted to multicast group all-AODV-RPL-nodes.
S ビットが 0 に設定された RREQ-DIO が TargNode に到着すると、TargNode は、OrigNode に TargNode へのダウンストリーム ルートを提供するために、それ自体をルートとする RREQ-DIO に対応する RREP-Instance 内に DODAG を構築しなければなりません (MUST)。RREP-DIO メッセージは、マルチキャスト グループの全 AODV-RPL ノードに送信されます。
Since the RPLInstanceID is assigned locally (i.e., there is no coordination between routers in the assignment of RPLInstanceID), the tuple (OrigNode, TargNode, RPLInstanceID) is needed to uniquely identify a discovered route. It is possible that multiple route discoveries with dissimilar OFs are initiated simultaneously. Thus, between the same pair of OrigNode and TargNode, there can be multiple AODV-RPL route discovery instances. So that OrigNode and TargNode can avoid any mismatch, they MUST pair the RREQ-Instance and the RREP-Instance in the same route discovery by using the RPLInstanceID.
RPLInstanceID はローカルに割り当てられるため (つまり、RPLInstanceID の割り当てにおいてルーター間で調整がありません)、検出されたルートを一意に識別するにはタプル (OrigNode、TargNode、RPLInstanceID) が必要です。異なる OF による複数のルート検出が同時に開始される可能性があります。したがって、OrigNode と TargNode の同じペアの間に、複数の AODV-RPL ルート検出インスタンスが存在する可能性があります。OrigNode と TargNode が不一致を回避できるように、RPLInstanceID を使用して、同じルート検出で RREQ インスタンスと RREP インスタンスをペアにしなければなりません。
When preparing the RREP-DIO, a TargNode could find the RPLInstanceID candidate for the RREP-Instance is already occupied by another RPL Instance from an earlier route discovery operation that is still active. This unlikely case might happen if two distinct OrigNodes need routes to the same TargNode, and they happen to use the same RPLInstanceID for RREQ-Instance. In such cases, the RPLInstanceID of an already active RREP-Instance MUST NOT be used again for assigning RPLInstanceID for the later RREP-Instance. If the same RPLInstanceID were reused for two distinct DODAGs originated with the same DODAGID (TargNode address), intermediate routers could not distinguish between these DODAGs (and their associated OFs). Instead, the RPLInstanceID MUST be replaced by another value so that the two RREP-Instances can be distinguished. In the RREP-DIO option, the Delta field of the RREP-DIO message (Figure 2) indicates the value that TargNode adds to the RPLInstanceID in the RREQ-DIO that it received, to obtain the value of the RPLInstanceID it uses in the RREP-DIO message. 0 indicates that the RREQ-InstanceID has the same value as the RPLInstanceID of the RREP message. When the new RPLInstanceID after incrementation exceeds 255, it rolls over starting at 0. For example, if the RREQ-InstanceID is 252 and incremented by 6, the new RPLInstanceID will be 2. Related operations can be found in Section 6.4. RPLInstanceID collisions do not occur across RREQ-DIOs; the DODAGID equals the OrigNode address and is sufficient to disambiguate between DODAGs.
RREP-DIO を準備するときに、TargNode は、RREP-Instance の RPLInstanceID 候補が、まだアクティブである以前のルート検出操作からの別の RPL インスタンスによってすでに占有されていることに気付く可能性があります。このまれなケースは、2 つの異なる OrigNode が同じ TargNode へのルートを必要とし、それらがたまたま RREQ-Instance に同じ RPLInstanceID を使用している場合に発生する可能性があります。このような場合、すでにアクティブな RREP インスタンスの RPLInstanceID を、後の RREP インスタンスに RPLInstanceID を割り当てるために再度使用してはなりません (MUST NOT)。同じ DODAGID (TargNode アドレス) から発信された 2 つの異なる DODAG に対して同じ RPLInstanceID が再利用された場合、中間ルーターはこれらの DODAG (およびそれに関連付けられた OF) を区別できません。代わりに、2 つの RREP インスタンスを区別できるように、RPLInstanceID を別の値に置き換えなければなりません (MUST)。RREP-DIO オプションでは、RREP-DIO メッセージの Delta フィールド (図 2) は、RREP-DIO メッセージで使用する RPLInstanceID の値を取得するために、TargNode が受信した RREQ-DIO の RPLInstanceID に追加する値を示します。0 は、RREQ-InstanceID が RREP メッセージの RPLInstanceID と同じ値を持つことを示します。インクリメント後の新しい RPLInstanceID が 255 を超えると、0 からロールオーバーされます。たとえば、RREQ-InstanceID が 252 で 6 ずつ増分される場合、新しい RPLInstanceID は 2 になります。関連する操作はセクション 6.4 にあります。RPLInstanceID の衝突は、RREQ-DIO 間では発生しません。DODAGID は OrigNode アドレスと等しく、DODAG 間の曖昧さを解消するには十分です。
Upon receiving an RREP-DIO, a router that already belongs to the RREP-Instance SHOULD drop the RREP-DIO. Otherwise, the router performs the steps in the following subsections.
RREP-DIO を受信すると、すでに RREP-Instance に属しているルーターは RREP-DIO をドロップする必要があります (SHOULD)。それ以外の場合、ルーターは次のサブセクションの手順を実行します。
If the OF is not satisfied, the router MUST NOT join the DODAG; the router MUST discard the RREP-DIO and does not execute the remaining steps in this section. An intermediate router MUST discard an RREP if one of its addresses is present in the Address Vector and does not execute the remaining steps in this section.
OF が満たされない場合、ルータは DODAG に参加してはなりません。ルータは RREP-DIO を破棄しなければならず、このセクションの残りの手順は実行しません。中間ルータは、そのアドレスの 1 つがアドレス ベクトルに存在し、このセクションの残りの手順を実行しない場合、RREP を破棄しなければなりません (MUST)。
If the S bit of the associated RREQ-Instance is set to 1, the router MUST proceed to Section 6.4.2.
関連する RREQ インスタンスの S ビットが 1 に設定されている場合、ルータはセクション 6.4.2 に進まなければなりません (MUST)。
If the S bit of the RREQ-Instance is set to 0, the router MUST determine whether the downward direction of the link (towards the TargNode) over which the RREP-DIO is received satisfies the OF and whether the router's Rank would not exceed the RankLimit. If these are true, the router joins the DODAG of the RREP-Instance. The router that transmitted the received RREP-DIO is selected as the preferred parent. Afterwards, other RREP-DIO messages can be received; AODV-RPL does not specify any action to be taken in such cases.
RREQ-Instance の S ビットが 0 に設定されている場合、ルータは、RREP-DIO が受信されるリンクの下方向 (TargNode に向かう) が OF を満たすかどうか、またルータの Rank が RankLimit を超えないかどうかを判断しなければなりません (MUST)。これらが真の場合、ルーターは RREP インスタンスの DODAG に参加します。受信した RREP-DIO を送信したルータが優先親として選択されます。その後、他の RREP-DIO メッセージを受信できるようになります。AODV-RPL では、そのような場合にとるべきアクションは指定されていません。
The router updates its stored value of the TargNode's Sequence Number according to the value provided in the ART option. The router next checks if one of its addresses is included in the ART option. If it is included, this router is the OrigNode of the route discovery. Otherwise, it is an intermediate router.
ルーターは、ART オプションで指定された値に従って、保存されている TargNode のシーケンス番号の値を更新します。次にルーターは、そのアドレスの 1 つが ART オプションに含まれているかどうかを確認します。含まれている場合、このルーターはルート検出の OrigNode になります。それ以外の場合は、中間ルーターです。
If the H bit is set to 1, then the router (OrigNode or intermediate) MUST build a downward route entry towards TargNode that includes at least the following items: OrigNode Address, RPLInstanceID, TargNode Address as destination, Next Hop, Lifetime, and Sequence Number. For a symmetric route, the Next Hop in the route entry is the router from which the RREP-DIO is received. For an asymmetric route, the Next Hop is the preferred parent in the DODAG of RREP-Instance. The RPLInstanceID in the route entry MUST be the RREQ-InstanceID (i.e., after subtracting the Delta field value from the value of the RPLInstanceID). The source address is learned from the ART option, and the destination address is learned from the DODAGID. The lifetime is set according to DODAG configuration (i.e., not the L field) and can be extended when the route is actually used. The Sequence Number represents the freshness of the route entry and is copied from the Dest SeqNo field of the ART option of the RREP-DIO. A route entry with the same source and destination address and the same RPLInstanceID, but a stale Sequence Number, MUST be deleted.
H ビットが 1 に設定されている場合、ルータ (OrigNode または中間) は、少なくとも次の項目を含む TargNode への下向きルート エントリを構築しなければなりません: OrigNode アドレス、RPLInstanceID、宛先としての TargNode アドレス、ネクスト ホップ、ライフタイム、およびシーケンス番号。対称ルートの場合、ルート エントリのネクスト ホップは、RREP-DIO の受信元のルーターです。非対称ルートの場合、ネクスト ホップは RREP インスタンスの DODAG 内の優先親です。ルート エントリの RPLInstanceID は、RREQ-InstanceID (つまり、RPLInstanceID の値から Delta フィールド値を減算した後) でなければなりません。送信元アドレスは ART オプションから学習され、宛先アドレスは DODAGID から学習されます。ライフタイムは DODAG 設定に従って (つまり、L フィールドではなく) 設定され、ルートが実際に使用されるときに延長できます。シーケンス番号はルート エントリの鮮度を表し、RREP-DIO の ART オプションの Dest SeqNo フィールドからコピーされます。送信元アドレスと宛先アドレスが同じで、RPLInstanceID が同じであるが、シーケンス番号が古いルート エントリは削除しなければなりません (MUST)。
If the receiver is the OrigNode, it can start transmitting the application data to TargNode along the path as provided in RREP-Instance, and processing for the RREP-DIO is complete. Otherwise, the RREP will be propagated towards OrigNode. If H=0, the intermediate router MUST include the address of the interface receiving the RREP-DIO into the Address Vector. If H=1, according to the previous step, the intermediate router has set up a route entry for TargNode. If the intermediate router has a route to OrigNode, it uses that route to unicast the RREP-DIO to OrigNode. Otherwise, in the case of a symmetric route, the RREP-DIO message is unicast to the Next Hop according to the Address Vector in the RREP-DIO (H=0) or the local route entry (H=1). Otherwise, in the case of an asymmetric route, the intermediate router transmits the RREP-DIO to multicast group all-AODV-RPL-nodes. The RPLInstanceID in the transmitted RREP-DIO is the same as the value in the received RREP-DIO.
受信者が OrigNode の場合、RREP-Instance で指定されたパスに沿ってアプリケーション データの TargNode への送信を開始でき、RREP-DIO の処理が完了します。それ以外の場合、RREP は OrigNode に向かって伝播されます。H=0 の場合、中間ルータは RREP-DIO を受信するインターフェイスのアドレスをアドレス ベクトルに含めなければなりません (MUST)。H=1 の場合、前のステップに従って、中間ルータは TargNode のルート エントリをセットアップしています。中間ルーターに OrigNode へのルートがある場合、そのルートを使用して RREP-DIO を OrigNode にユニキャストします。それ以外の場合、対称ルートの場合、RREP-DIO メッセージは、RREP-DIO (H=0) またはローカル ルート エントリ (H=1) のアドレス ベクトルに従ってネクスト ホップにユニキャストされます。それ以外の非対称ルートの場合、中間ルータは RREP-DIO をマルチキャスト グループの全 AODV-RPL ノードに送信します。送信された RREP-DIO の RPLInstanceID は、受信した RREP-DIO の値と同じです。
In some cases, an intermediate router that receives an RREQ-DIO message MAY unicast a Gratuitous RREP-DIO (G-RREP-DIO) message back to OrigNode before continuing the transmission of the RREQ-DIO towards TargNode. The Gratuitous RREP (G-RREP) allows the OrigNode to start transmitting data to TargNode sooner. The G bit of the RREP option is provided to distinguish the G-RREP-DIO (G=1) sent by the intermediate router from the RREP-DIO sent by TargNode (G=0).
場合によっては、RREQ-DIO メッセージを受信する中間ルータは、TargNode への RREQ-DIO の送信を続行する前に、Gratuitous RREP-DIO (G-RREP-DIO) メッセージを OrigNode にユニキャストで返送してもよい(MAY)。Gratuitous RREP (G-RREP) を使用すると、OrigNode が TargNode へのデータ送信をより早く開始できるようになります。RREP オプションの G ビットは、中間ルータによって送信される G-RREP-DIO (G=1) と TargNode によって送信される RREP-DIO (G=0) を区別するために提供されます。
The G-RREP-DIO MAY be sent out when the intermediate router receives an RREQ-DIO for a TargNode and the router has a pair of downward and upward routes to the TargNode that also satisfy the OF and for which the Destination Sequence Number is at least as large as the Sequence Number in the RREQ-DIO message. After unicasting the G-RREP to the OrigNode, the intermediate router then unicasts the RREQ towards TargNode, so that TargNode will have the advertised route towards OrigNode along with the RREQ-InstanceID for the RREQ-Instance. An upstream intermediate router that receives such a G-RREP MUST also generate a G-RREP and send it further upstream towards OrigNode.
G-RREP-DIO は、中間ルータが TargNode の RREQ-DIO を受信し、ルータが OF を満たし、宛先シーケンス番号が RREQ-DIO メッセージのシーケンス番号と少なくとも同じである TargNode への下向きルートと上向きルートのペアを持っている場合に送信されてもよい(MAY)。G-RREP を OrigNode にユニキャストした後、中間ルーターは RREQ を TargNode に向けてユニキャストします。これにより、TargNode は、RREQ インスタンスの RREQ-InstanceID とともに、OrigNode へのアドバタイズされたルートを持つようになります。そのような G-RREP を受信する上流の中間ルータも G-RREP を生成し、それをさらに上流の OrigNode に向けて送信しなければなりません (MUST)。
In case of source routing, the intermediate router MUST include the Address Vector between the OrigNode and itself in the G-RREP. It also includes the Address Vector in the unicast RREQ-DIO towards TargNode. Upon reception of the unicast RREQ-DIO, the TargNode will have a route Address Vector from itself to the OrigNode. Then, the router MUST include the Address Vector from the TargNode to the router itself in the G-RREP-DIO to be transmitted.
ソースルーティングの場合、中間ルータは、G-RREP 内の OrigNode とそれ自体の間のアドレス ベクトルを含めなければなりません (MUST)。また、TargNode へのユニキャスト RREQ-DIO のアドレス ベクトルも含まれます。ユニキャスト RREQ-DIO を受信すると、TargNode はそれ自体から OrigNode へのルート アドレス ベクトルを持ちます。次に、ルータは、TargNode からルータ自体へのアドレス ベクトルを G-RREP-DIO に含めて送信しなければなりません (MUST)。
For establishing hop-by-hop routes, the intermediate router MUST unicast the received RREQ-DIO to the Next Hop on the route. The Next Hop router along the route MUST build new route entries with the related RPLInstanceID and DODAGID in the downward direction. This process repeats at each node until the RREQ-DIO arrives at the TargNode. Then, the TargNode and each router along the path towards OrigNode MUST unicast the RREP-DIO hop-by-hop towards OrigNode as specified in Section 6.3.
ホップバイホップルートを確立するために、中間ルーターは受信した RREQ-DIO をルート上のネクストホップにユニキャストしなければなりません (MUST)。ルートに沿ったネクスト ホップ ルーターは、関連する RPLInstanceID と DODAGID を使用して下方向に新しいルート エントリを構築しなければなりません (MUST)。このプロセスは、RREQ-DIO が TargNode に到着するまで各ノードで繰り返されます。次に、TargNode と OrigNode へのパスに沿った各ルーターは、セクション 6.3 で指定されているように、OrigNode に向けて RREP-DIO をホップバイホップでユニキャストしなければなりません (MUST)。
RREQ-Instance/RREP-Instance multicast uses Trickle timer operations [RFC6206] to control RREQ-DIO and RREP-DIO transmissions. The Trickle control of these DIO transmissions follows the procedures described in Section 8.3 of [RFC6550] entitled "DIO Transmission". If the route is symmetric, the RREP-DIO does not need the Trickle timer mechanism.
RREQ-Instance/RREP-Instance マルチキャストは、Trickle タイマー操作 [RFC6206] を使用して、RREQ-DIO および RREP-DIO 送信を制御します。これらの DIO 送信のトリクル制御は、「DIO 送信」と題された [RFC6550] のセクション 8.3 に記載されている手順に従います。ルートが対称である場合、RREP-DIO はトリクル タイマー メカニズムを必要としません。
AODV-RPL uses the "P2P Route Discovery Mode of Operation" (MOP == 4), with new options as specified in this document. This document has been added as an additional reference for "P2P Route Discovery Mode of Operation" in the "Mode of Operation" registry within the "Routing Protocol for Low Power and Lossy Networks (RPL)" registry group.
AODV-RPL は、このドキュメントで指定されている新しいオプションを備えた「P2P ルート検出動作モード」(MOP == 4) を使用します。このドキュメントは、「低電力および損失の多いネットワーク用ルーティング プロトコル (RPL)」レジストリ グループ内の「動作モード」レジストリの「P2P ルート検出動作モード」の追加参考資料として追加されました。
IANA has assigned the three new AODV-RPL options described in Table 1 in the "RPL Control Message Options" registry within the "Routing Protocol for Low Power and Lossy Networks (RPL)" registry group.
IANA は、「Routing Protocol for Low Power and Lossy Networks (RPL)」レジストリ グループ内の「RPL Control Message Options」レジストリに、表 1 に示す 3 つの新しい AODV-RPL オプションを割り当てました。
+=======+=========+===========+
| Value | Meaning | Reference |
+=======+=========+===========+
| 0x0B | RREQ | RFC 9854 |
+-------+---------+-----------+
| 0x0C | RREP | RFC 9854 |
+-------+---------+-----------+
| 0x0D | ART | RFC 9854 |
+-------+---------+-----------+
Table 1: AODV-RPL Options
表 1: AODV-RPL オプション
IANA has allocated the permanent multicast address with link-local scope in Table 2 for nodes implementing this specification. This allocation has been made in the "Local Network Control Block (224.0.0.0 - 224.0.0.255 (224.0.0/24))" registry within the "IPv4 Multicast Address Space Registry" registry group.
IANA は、この仕様を実装するノードに対して、表 2 のリンクローカル範囲を持つ永続的なマルチキャスト アドレスを割り当てました。この割り当ては、「IPv4 マルチキャスト アドレス スペース レジストリ」レジストリ グループ内の「ローカル ネットワーク コントロール ブロック (224.0.0.0 - 224.0.0.255 (224.0.0/24))」レジストリで行われます。
+=============+====================+============+
| Address(es) | Description | References |
+=============+====================+============+
| 224.0.0.69 | all-AODV-RPL-nodes | RFC 9854 |
+-------------+--------------------+------------+
Table 2: Permanent Multicast Address with Link-Local Scope
表 2: リンクローカル範囲の永続的マルチキャスト アドレス
The security considerations for the operation of AODV-RPL are similar to those for the operation of RPL (as described in Section 19 of the RPL specification [RFC6550]). Sections 6.1 and 10 of [RFC6550] describe RPL's optional security framework, which AODV-RPL relies on to provide data confidentiality, authentication, replay protection, and delay protection services. Additional analysis for the security threats to RPL can be found in [RFC7416].
AODV-RPL の動作に関するセキュリティ上の考慮事項は、(RPL 仕様 [RFC6550] のセクション 19 に記載されている) RPL の動作に関するものと同様です。[RFC6550] のセクション 6.1 および 10 では、RPL のオプションのセキュリティ フレームワークについて説明しています。AODV-RPL は、データの機密性、認証、リプレイ保護、および遅延保護サービスを提供するためにこのフレームワークに依存しています。RPL に対するセキュリティ脅威に関する追加の分析は [RFC7416] にあります。
A router can join a temporary DAG created for a secure AODV-RPL route discovery only if it can support the security configuration in use (see Section 6.1 of [RFC6550]), which also specifies the key in use. It does not matter whether the key is preinstalled or dynamically acquired. The router must have the key in use before it can join the DAG being created for secure route discovery.
ルータは、使用中のセキュリティ設定 ([RFC6550] のセクション 6.1 を参照) をサポートできる場合にのみ、安全な AODV-RPL ルート検出用に作成された一時 DAG に参加できます。この設定では、使用中のキーも指定されています。キーがプリインストールされているか、動的に取得されているかは関係ありません。ルーターは、安全なルート検出のために作成されている DAG に参加する前に、キーを使用しておく必要があります。
If a rogue router knows the key for the security configuration in use, it can join the secure AODV-RPL route discovery and cause various types of damage. Such a rogue router could advertise false information in its DIOs in order to include itself in the discovered route(s). It could generate bogus RREQ-DIO and RREP-DIO messages carrying bad routes or maliciously modify genuine RREP-DIO messages it receives. A rogue router acting as the OrigNode could launch denial-of-service attacks against the LLN deployment by initiating fake AODV-RPL route discoveries. When rogue routers might be present, RPL's preinstalled mode of operation, where the key to use for route discovery is preinstalled, SHOULD be used.
不正ルータが使用中のセキュリティ設定のキーを知っている場合、安全な AODV-RPL ルート検出に参加し、さまざまな種類の損害を引き起こす可能性があります。このような不正ルーターは、発見されたルートに自分自身を含めるために、DIO で虚偽の情報をアドバタイズする可能性があります。不正なルートを運ぶ偽の RREQ-DIO および RREP-DIO メッセージを生成したり、受信した本物の RREP-DIO メッセージを悪意を持って変更したりする可能性があります。OrigNode として動作する不正ルーターは、偽の AODV-RPL ルート検出を開始することにより、LLN 導入に対してサービス拒否攻撃を開始する可能性があります。不正なルータが存在する可能性がある場合は、ルート検出に使用するキーがプリインストールされている RPL のプリインストール動作モードを使用する必要があります (SHOULD)。
When an RREQ-DIO message uses the source routing option by setting the H bit to 0, a rogue router may populate the Address Vector field with a set of addresses that may result in the RREP-DIO traveling in a routing loop.
RREQ-DIO メッセージが H ビットを 0 に設定してソース ルーティング オプションを使用すると、不正ルーターがアドレス ベクトル フィールドに一連のアドレスを入力する可能性があり、その結果、RREP-DIO がルーティング ループ内を移動する可能性があります。
If a rogue router is able to forge a G-RREP, it could mount denial-of-service attacks.
不正なルータが G-RREP を偽造できる場合、サービス拒否攻撃を開始する可能性があります。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,
"The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206,
March 2011, <https://www.rfc-editor.org/info/rfc6206>.
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012,
<https://www.rfc-editor.org/info/rfc6550>.
[RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N.,
and D. Barthel, "Routing Metrics Used for Path Calculation
in Low-Power and Lossy Networks", RFC 6551,
DOI 10.17487/RFC6551, March 2012,
<https://www.rfc-editor.org/info/rfc6551>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[aodv-tot] Perkins, C.E. and E.M. Royer, "Ad-hoc On-demand Distance
Vector Routing", Proceedings WMCSA'99. Second IEEE
Workshop on Mobile Computing Systems and Applications, pp.
90-100, DOI 10.1109/MCSA.1999.749281, February 1999,
<https://ieeexplore.ieee.org/document/749281>.
[co-ioam] Ballamajalu, R., Anand, S.V.R., and M. Hegde, "Co-iOAM:
In-situ Telemetry Metadata Transport for Resource
Constrained Networks within IETF Standards Framework",
2018 10th International Conference on Communication
Systems & Networks (COMSNETS), pp. 573-576,
DOI 10.1109/COMSNETS.2018.8328276, January 2018,
<https://ieeexplore.ieee.org/document/8328276>.
[contiki] "The Contiki Open Source OS for the Internet of Things
(Contiki Version 2.7)", commit 7635906, November 2013,
<https://github.com/contiki-os/contiki>.
[Contiki-ng]
"Contiki-NG: The OS for Next Generation IoT Devices
(Contiki-NG Version 4.6)", commit 3b0bc6a, December 2020,
<https://github.com/contiki-ng/contiki-ng>.
[cooja] "Cooja Simulator for Wireless Sensor Networks (Contiki/
Cooja Version 2.7)", commit 7635906, November 2013,
<https://github.com/contiki-os/contiki/tree/master/tools/
cooja>.
[empirical-study]
Misra, P., Ahmed, N., and S. Jha, "An empirical study of
asymmetry in low-power wireless links", IEEE
Communications Magazine, vol. 50, no. 7, pp. 137-146,
DOI 10.1109/MCOM.2012.6231290, July 2012,
<https://ieeexplore.ieee.org/document/6231290>.
[Link_Asymmetry]
Sang, L., Arora, A., and H. Zhang, "On Link Asymmetry and
One-way Estimation in Wireless Sensor Networks", ACM
Transactions on Sensor Networks, vol. 6, no. 2, pp. 1-25,
DOI 10.1145/1689239.1689242, March 2010,
<https://doi.org/10.1145/1689239.1689242>.
[low-power-wireless]
Srinivasan, K., Dutta, P., Tavakoli, A., and P. Levis, "An
empirical study of low-power wireless", ACM Transactions
on Sensor Networks, vol. 6, no. 2, pp. 1-49,
DOI 10.1145/1689239.1689246, March 2010,
<https://doi.org/10.1145/1689239.1689246>.
[RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On-
Demand Distance Vector (AODV) Routing", RFC 3561,
DOI 10.17487/RFC3561, July 2003,
<https://www.rfc-editor.org/info/rfc3561>.
[RFC6687] Tripathi, J., Ed., de Oliveira, J., Ed., and JP. Vasseur,
Ed., "Performance Evaluation of the Routing Protocol for
Low-Power and Lossy Networks (RPL)", RFC 6687,
DOI 10.17487/RFC6687, October 2012,
<https://www.rfc-editor.org/info/rfc6687>.
[RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and
J. Martocci, "Reactive Discovery of Point-to-Point Routes
in Low-Power and Lossy Networks", RFC 6997,
DOI 10.17487/RFC6997, August 2013,
<https://www.rfc-editor.org/info/rfc6997>.
[RFC6998] Goyal, M., Ed., Baccelli, E., Brandt, A., and J. Martocci,
"A Mechanism to Measure the Routing Metrics along a Point-
to-Point Route in a Low-Power and Lossy Network",
RFC 6998, DOI 10.17487/RFC6998, August 2013,
<https://www.rfc-editor.org/info/rfc6998>.
[RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y.
Weingarten, "An Overview of Operations, Administration,
and Maintenance (OAM) Tools", RFC 7276,
DOI 10.17487/RFC7276, June 2014,
<https://www.rfc-editor.org/info/rfc7276>.
[RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A.,
and M. Richardson, Ed., "A Security Threat Analysis for
the Routing Protocol for Low-Power and Lossy Networks
(RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015,
<https://www.rfc-editor.org/info/rfc7416>.
[RFC7548] Ersue, M., Ed., Romascanu, D., Schoenwaelder, J., and A.
Sehgal, "Management of Networks with Constrained Devices:
Use Cases", RFC 7548, DOI 10.17487/RFC7548, May 2015,
<https://www.rfc-editor.org/info/rfc7548>.
[RFC9010] Thubert, P., Ed. and M. Richardson, "Routing for RPL
(Routing Protocol for Low-Power and Lossy Networks)
Leaves", RFC 9010, DOI 10.17487/RFC9010, April 2021,
<https://www.rfc-editor.org/info/rfc9010>.
[RFC9030] Thubert, P., Ed., "An Architecture for IPv6 over the Time-
Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)",
RFC 9030, DOI 10.17487/RFC9030, May 2021,
<https://www.rfc-editor.org/info/rfc9030>.
The combination of the downstream Received Signal Strength Indicator (RSSI) and the upstream Expected Transmission Count (ETX) has been tested to determine whether a link is symmetric or asymmetric at intermediate routers. We present two methods to obtain an ETX value from RSSI measurement.
中間ルーターでリンクが対称か非対称かを判断するために、ダウンストリームの受信信号強度インジケーター (RSSI) とアップストリームの予想送信数 (ETX) の組み合わせがテストされています。RSSI 測定から ETX 値を取得する 2 つの方法を紹介します。
Method 1:
方法 1:
In the first method, we constructed a table measuring RSSI versus ETX using the Cooja simulation [cooja] setup in the Contiki OS environment [contiki]. We used Contiki-2.7 running the 6LoWPAN/RPL protocol stack for the simulations. For approximating the number of packet drops based on the RSSI values, we implemented simple logic that drops transmitted packets with certain predefined ratios before handing over the packets to the receiver. The packet drop ratio is implemented as a table lookup of RSSI ranges mapping to different packet drop ratios with lower RSSI ranges resulting in higher values. While this table has been defined for the purpose of capturing the overall link behavior, in general, it is highly recommended to conduct physical radio measurement experiments. By keeping the receiving node at different distances, we let the packets experience different packet drops as per the described method. The ETX value computation is done by another module that is part of RPL OF implementation. Since the ETX value is reflective of the extent of packet drops, it allowed us to prepare a useful table correlating ETX and RSSI values (see Table 3). ETX and RSSI values obtained in this way may be used as explained below:
最初の方法では、Contiki OS 環境 [contiki] の Cooja シミュレーション [cooja] セットアップを使用して、RSSI と ETX を測定するテーブルを作成しました。シミュレーションには 6LoWPAN/RPL プロトコル スタックを実行する Contiki-2.7 を使用しました。RSSI 値に基づいてパケット ドロップの数を概算するために、パケットを受信機に渡す前に、送信されたパケットを特定の事前定義された比率でドロップする単純なロジックを実装しました。パケット ドロップ率は、RSSI 範囲が低いほど値が高くなる、さまざまなパケット ドロップ率にマッピングする RSSI 範囲のテーブル ルックアップとして実装されています。このテーブルはリンク全体の動作を把握する目的で定義されていますが、一般に、物理的な無線測定実験を実施することを強くお勧めします。受信ノードをさまざまな距離に保つことで、説明した方法に従ってパケットにさまざまなパケット ドロップが発生するようにします。ETX 値の計算は、RPL OF 実装の一部である別のモジュールによって実行されます。ETX 値はパケット ドロップの程度を反映しているため、ETX 値と RSSI 値を相関させる便利なテーブルを準備することができました (表 3 を参照)。この方法で取得された ETX および RSSI 値は、以下で説明するように使用できます。
Source -------> NodeA -------> NodeB -----> Destination
Figure 6: Communication Link from Source to Destination
図 6: 送信元から宛先までの通信リンク
+=========================+=======================+
| RSSI at NodeA for NodeB | Expected ETX at NodeA |
| | for NodeB->NodeA |
+=========================+=======================+
| > -60 | 150 |
+-------------------------+-----------------------+
| -70 to -60 | 192 |
+-------------------------+-----------------------+
| -80 to -70 | 226 |
+-------------------------+-----------------------+
| -90 to -80 | 662 |
+-------------------------+-----------------------+
| -100 to -90 | 3840 |
+-------------------------+-----------------------+
Table 3: Selection of S Bit Based on Expected ETX Value
表 3: 期待される ETX 値に基づく S ビットの選択
Method 2:
方法 2:
One could also make use of the function guess_etx_from_rssi() defined in the 6LoWPAN/RPL protocol stack of Contiki-ng OS [Contiki-ng] to obtain RSSI-ETX mapping. This function outputs an ETX value ranging between 128 and 3840 for -60 <= rssi <= -89. The function description is beyond the scope of this document.
RSSI-ETX マッピングを取得するために、Contiki-ng OS [Contiki-ng] の 6LoWPAN/RPL プロトコル スタックで定義されている関数guess_etx_from_rssi() を利用することもできます。この関数は、-60 <= rssi <= -89 の場合、128 ～ 3840 の範囲の ETX 値を出力します。関数の説明はこのドキュメントの範囲外です。
We tested the operations in this specification by making the following experiment, using the above parameters. In our experiment, a communication link is considered as symmetric if the ETX value of NodeA->NodeB and NodeB->NodeA (see Figure 6) are within, say, a 1:3 ratio. This ratio should be understood as determining the link's symmetric/asymmetric nature. NodeA can typically know the ETX value in the direction of NodeA->NodeB, but it has no direct way of knowing the value of ETX from NodeB->NodeA. Using physical testbed experiments and realistic wireless channel propagation models, one can determine a relationship between RSSI and ETX representable as an expression or a mapping table. Such a relationship, in turn, can be used to estimate the ETX value at NodeA for link NodeB->NodeA from the received RSSI from NodeB. Whenever NodeA determines that the link towards the NodeB is bidirectional asymmetric, then the S bit is set to 0. Afterwards, the link from NodeA to Destination remains designated as asymmetric, and the S bit remains set to 0.
上記のパラメータを使用して次の実験を行うことにより、この仕様の動作をテストしました。私たちの実験では、NodeA->NodeB および NodeB->NodeA (図 6 を参照) の ETX 値が、たとえば 1:3 の比率内にある場合、通信リンクは対称であると見なされます。この比率は、リンクの対称/非対称の性質を決定するものとして理解されるべきです。通常、NodeA は NodeA->NodeB の方向の ETX 値を知ることができますが、NodeB->NodeA の ETX 値を直接知る方法はありません。物理的なテストベッド実験と現実的な無線チャネル伝播モデルを使用すると、式またはマッピング テーブルとして表現できる RSSI と ETX の間の関係を決定できます。このような関係を使用して、ノード B から受信した RSSI からリンク NodeB->NodeA のノード A での ETX 値を推定することができます。NodeA が NodeB へのリンクが双方向非対称であると判断すると、S ビットは 0 に設定されます。その後、NodeA から宛先へのリンクは非対称として指定されたままになり、S ビットは 0 に設定されたままになります。
Determination of asymmetry versus bidirectionality remains a topic of lively discussion in the IETF.
非対称性と双方向性の決定は、IETF で依然として活発な議論のテーマとなっています。
This appendix provides some example message flows showing RREQ and RREP establishing symmetric and asymmetric routes. Also, examples for the use of RREP_WAIT and G-RREP are included. In the examples, router (O) is to be understood as performing the role of OrigNode. Router (T) is to be understood as performing the role of TargNode. Routers (R) are intermediate routers that are performing AODV-RPL functions in order to discover one or more suitable routes between (O) and (T).
この付録では、対称および非対称ルートを確立する RREQ および RREP を示すメッセージ フローの例をいくつか示します。また、RREP_WAIT と G-RREP の使用例も含まれています。この例では、ルーター (O) は OrigNode の役割を実行するものとして理解されます。ルーター (T) は、TargNode の役割を実行するものとして理解されます。ルーター (R) は、(O) と (T) の間の 1 つ以上の適切なルートを発見するために AODV-RPL 機能を実行する中間ルーターです。
In the following diagram, RREQ messages are multicast from router (O) in order to discover routes to and from router (T). The RREQ control messages flow outward from (O). Each router along the way establishes a single RREQ-Instance identified by RREQ-InstanceID even if multiple RREQs are received with the same RREQ-InstanceID. In the top half of the diagram, the routers are able to offer a symmetric route at each hop of the path from (O) to (T). When (T) receives an RREQ, it is then able to transmit data packets to (O). Router (T) then prepares to send an RREP along the symmetric path that would enable router (O) to send packets to router (T).
次の図では、ルーター (T) との間のルートを検出するために、ルーター (O) から RREQ メッセージがマルチキャストされます。RREQ 制御メッセージは (O) から外向きに流れます。途中の各ルーターは、同じ RREQ-InstanceID を持つ複数の RREQ を受信した場合でも、RREQ-InstanceID で識別される単一の RREQ インスタンスを確立します。図の上半分では、ルーターは (O) から (T) までのパスの各ホップで対称ルートを提供できます。(T) が RREQ を受信すると、データ パケットを (O) に送信できるようになります。次に、ルーター (T) は、ルーター (O) がルーター (T) にパケットを送信できるようにする対称パスに沿って RREP を送信する準備をします。
(R) ---RREQ(S=1)--->(R) ---RREQ(S=1)--->(R)
^ |
| |
RREQ(S=1) RREQ(S=1)
| |
| v
(O) --------->(R) --------->(R)-------->(T)
/ \ RREQ RREQ RREQ ^
| \ (S=1) (S=0) (S=0) |
| \ /
RREQ | \ RREQ (S=1) RREQ (S=0)
(S=0) | \ /
v \ RREQ (S=0) /
(R) ---->(R)------>(R)----.....--->(R)
Figure 7: AODV-RPL RREQ Message Flow Example When Symmetric Path Available
図 7: 対称パスが使用可能な場合の AODV-RPL RREQ メッセージ フローの例
In the following diagram, which results from the above RREQ message transmission, a symmetric route is available from (T) to router (O) via the routers in the top half of the diagram. RREP messages are sent via unicast along the symmetric route. Since the RREP message is transmitted via unicast, no RREP messages are sent by router (T) to the routers in the bottom half of the diagram.
上記の RREQ メッセージ送信の結果として得られる次の図では、(T) から図の上半分のルーターを経由してルーター (O) までの対称ルートが利用可能です。RREP メッセージは、対称ルートに沿ってユニキャスト経由で送信されます。RREP メッセージはユニキャスト経由で送信されるため、ルーター (T) から図の下半分のルーターに RREP メッセージは送信されません。
(R)<------RREP----- (R)<------RREP----- (R)
| ^
| |
RREP RREP
| |
v |
(O) ----------(R) ----------(R) --------(T)
/ \ |
| \ |
| \ (no RREP messages sent) /
| \ /
| \ /
| \ /
(R) -----(R)-------(R)----.....----(R)
Figure 8: AODV-RPL RREP Message Flow Example When Symmetric Path Available
図 8: 対称パスが使用可能な場合の AODV-RPL RREP メッセージ フローの例
In the following diagram, RREQ messages are multicast from router (O) in order to discover routes to and from router (T) as before. As shown, no symmetric route is available from (O) to (T).
次の図では、以前と同様に、ルータ (T) との間のルートを検出するために、RREQ メッセージがルータ (O) からマルチキャストされます。示されているように、(O) から (T) までに利用できる対称ルートはありません。
(R) ---RREQ(S=0)--->(R) ---RREQ(S=0)--->(R)
^ |
| |
RREQ(S=1) RREQ(S=0)
| |
| v
(O) --------->(R) --------->(R)-------->(T)
^ \ RREQ RREQ RREQ | \
| \ (S=1) (S=0) (S=0) | |
| \ / |
| RREQ (S=1) RREQ (S=0) / (R)
| \ / |
| \ RREQ (S=0) / /
(R) ---->(R)------>(R)----.....----->(R)---
Figure 9: AODV-RPL RREQ Message Flow When Symmetric Path Unavailable
図 9: 対称パスが使用できない場合の AODV-RPL RREQ メッセージ フロー
Upon receiving the RREQ in Figure 9, router (T) then prepares to send an RREP that would enable router (O) to send packets to router (T). In Figure 9, since no symmetric route is available from (T) to router (O), RREP messages are sent via multicast to all neighboring routers.
図 9 の RREQ を受信すると、ルーター (T) は、ルーター (O) がルーター (T) にパケットを送信できるようにする RREP を送信する準備をします。図 9 では、(T) からルーター (O) への対称ルートが利用できないため、RREP メッセージはマルチキャスト経由ですべての隣接ルーターに送信されます。
(R)<------RREP----- (R)<------RREP----- (R)
| |
| |
RREP RREP
| |
| |
v v
(O)<--------- (R)<--------- (R)<------- (T)
^ \ RREP RREP RREP | \
| \ | |RREP
| \ / |
RREP | \ RREP RREP / (R)
| \ / |
| \ / /
(R)<----- (R)<----- (R)<---.....---- (R)< - RREP
RREP RREP RREP
Figure 10: AODV-RPL RREQ and RREP-Instances for Asymmetric Links
図 10: 非対称リンクの AODV-RPL RREQ および RREP インスタンス
In Figure 11, the first RREQ arrives at (T). This triggers TargNode to start the RREP_WAIT_TIME timer.
図 11 では、最初の RREQ が (T) に到着します。これにより、TargNode が RREP_WAIT_TIME タイマーを開始します。
(O) --------->(R) --------->(R)-------->(T)
RREQ RREQ RREQ
(S=1) (S=0) (S=0)
Figure 11: TargNode Starts RREP_WAIT
図 11: TargNode による RREP_WAIT の開始
In Figure 12, another RREQ arrives before the RREP_WAIT_TIME timer is expired. It could be preferable compared the previously received RREP that caused the RREP_WAIT_TIME timer to be set.
図 12 では、RREP_WAIT_TIME タイマーが期限切れになる前に別の RREQ が到着します。RREP_WAIT_TIME タイマーを設定する原因となった、以前に受信した RREP と比較する方が好ましい可能性があります。
(O) (T)
/ \ ^
| \ |
| \ /
RREQ | \ RREQ (S=1) RREQ (S=0)
(S=0) | \ /
v \ RREQ (S=0) /
(R) ---->(R)------>(R)----.....--->(R)
Figure 12: Waiting TargNode Receives Preferable RREQ
図 12: 待機中の TargNode が優先 RREQ を受信する
In Figure 13, the RREP_WAIT_TIME timer expires. TargNode selects the path with S=1.
図 13 では、RREP_WAIT_TIME タイマーが期限切れになります。TargNode は S=1 のパスを選択します。
(R) ---RREQ(S=1)--->(R) ---RREQ(S=1)--->(R)
^ |
| |
RREQ(S=1) RREQ(S=1)
| |
| v
(O) (T)
Figure 13: RREP_WAIT Expires at TargNode
図 13: RREP_WAIT が TargNode で期限切れになる
In Figure 14, R* has upward and downward routes to TargNode (T) that satisfy the OF of the RPL Instance originated by OrigNode (O), and the Destination Sequence Number is at least as large as the Sequence Number in the RREQ message.
図 14 では、R* には、OrigNode (O) によって発信された RPL インスタンスの OF を満たす TargNode (T) への上向きおよび下向きのルートがあり、宛先シーケンス番号は少なくとも RREQ メッセージ内のシーケンス番号と同じ大きさです。
(R) ---RREQ(S=1)--->(R) ---RREQ(S=0)--->(R)
^ |
| |
RREQ(S=1) RREQ(S=0)
| |
| v
(O) --------->(R) --------->(R)-------->(T)
/ \ RREQ RREQ RREQ ^
| \ (S=1) (S=0) (S=0) |
| \ /
RREQ | \ RREQ (S=1) /
(S=0) | \ /
v \ v
(R) ---->(R*)<------>(R)<----....--->(R)
Figure 14: RREP Triggers G-RREP at Intermediate Node
図 14: RREP が中間ノードで G-RREP をトリガーする
In Figure 15, R* transmits the G-RREP-DIO back to OrigNode (O) and forwards the incoming RREQ towards (T).
図 15 では、R* は G-RREP-DIO を OrigNode (O) に送り返し、受信 RREQ を (T) に向けて転送します。
(O) (T)
\ ^
\ |
\ (RREQ) /
\ G-RREP-DIO /
\ /
\ (RREQ) (RREQ) /
(R*)------>(R)----....--->(R)
Figure 15: Intermediate Node Initiates G-RREP
図 15: 中間ノードが G-RREP を開始する
The authors thank Pascal Thubert, Rahul Jadhav, and Lijo Thomas for their support and valuable input. The authors specially thank Lavanya H.M. for implementing AODV-RPL in Contiki and conducting extensive simulation studies.
著者らは、Pascal Thubert、Rahul Jadhav、および Lijo Thomas の支援と貴重な意見に感謝します。著者らは特に Lavanya H.M. に感謝します。Contiki での AODV-RPL の実装と広範なシミュレーション研究の実施に対して。
The authors would like to acknowledge the reviews, feedback, and comments from the following people, in alphabetical order: Roman Danyliw, Lars Eggert, Benjamin Kaduk, Tero Kivinen, Erik Kline, Murray Kucherawy, Warren Kumari, Francesca Palombini, Alvaro Retana, Ines Robles, John Scudder, Meral Shirazipour, Peter Van der Stok, Éric Vyncke, and Robert Wilton.
著者は、アルファベット順に、Roman Danyliw、Lars Eggert、Benjamin Kaduk、Tero Kivinen、Erik Kline、Murray Kucherawy、Warren Kumari、Francesca Palombini、Alvaro Retana、Ines Robles、John Scudder、Meral Srizipour、Peter Van der Stok、Éric からのレビュー、フィードバック、およびコメントに感謝の意を表します。ヴィンケとロバート・ウィルトン。
Abdur Rashid Sangi
Wenzhou-Kean University
88 Daxue Rd, Ouhai
Wenzhou
Zhejiang Province, 325060
Kean University
1000 Morris Avenue
Union, New Jersey 07083
United States of America
China
Email: sangi_bahrian@yahoo.com
Malati Hegde
Indian Institute of Science
Bangalore 560012
India
Email: malati@iisc.ac.in
Mingui Zhang
Huawei Technologies
No. 156 Beiqing Rd.
Haidian District
Beijing
100095
China
Email: zhangmingui@huawei.com
Charles E. Perkins
Blue Meadow Networks
Saratoga, CA 95070
United States of America
Email: charliep@lupinlodge.com
S.V.R. Anand
Indian Institute of Science
Bangalore 560012
India
Email: anandsvr@iisc.ac.in
Satish Anamalamudi
SRM University-AP
Amaravati Campus
Amaravati, Andhra Pradesh 522 502
India
Email: satishnaidu80@gmail.com
Bing Liu
Huawei Technologies
No. 156 Beiqing Rd.
Haidian District
Beijing
100095
China
Email: remy.liubing@huawei.com