Internet Engineering Task Force (IETF) K. Iwanicki
Request for Comments: 9866 University of Warsaw
Category: Standards Track October 2025
ISSN: 2070-1721
By and large, correct operation of a network running the Routing Protocol for Low-Power and Lossy Networks (RPL) requires border routers to be up. In many applications, it is beneficial for the nodes to detect a failure of a border router as soon as possible to trigger fallback actions. This document specifies the Root Node Failure Detector (RNFD), an extension to RPL that expedites detection of border router crashes by having nodes collaboratively monitor the status of a given border router. The extension introduces an additional state at each node, a new type of RPL Control Message Option for synchronizing this state among different nodes, and the coordination algorithm itself.
一般に、低電力および損失の多いネットワーク用のルーティング プロトコル (RPL) を実行しているネットワークが正しく動作するには、境界ルーターが稼働している必要があります。多くのアプリケーションでは、ノードがボーダー ルーターの障害をできるだけ早く検出してフォールバック アクションをトリガーすることが有益です。この文書では、ノードが連携して特定の境界ルータのステータスを監視することで、境界ルータのクラッシュの検出を迅速化する RPL の拡張機能である、ルート ノード障害検出器 (RNFD) を指定します。この拡張機能では、各ノードでの追加の状態、異なるノード間でこの状態を同期するための新しいタイプの RPL 制御メッセージ オプション、および調整アルゴリズム自体が導入されます。
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/rfc9866.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9866 で入手できます。
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
1.1. Effects of LBR Crashes
1.2. Design Principles
1.3. Other Solutions
2. Terminology
3. Overview
3.1. Protocol State Machine
3.2. Counters and Communication
4. The RNFD Option
4.1. General CFRC Requirements
4.2. Format of the Option
5. RPL Router Behavior
5.1. Joining a DODAG Version and Changing the RNFD Role
5.2. Detecting and Verifying Problems with the DODAG Root
5.3. Disseminating Observations and Reaching Agreement
5.4. DODAG Root's Behavior
5.5. Activating and Deactivating the Protocol on Demand
5.6. Processing CFRCs of Incompatible Lengths
5.7. Summary of RNFD's Interactions with RPL
5.8. Summary of RNFD's Constants
6. Manageability Considerations
6.1. Role Assignment and CFRC Size Adjustment
6.2. Virtual DODAG Roots
6.3. Monitoring
7. Security Considerations
8. IANA Considerations
9. References
9.1. Normative References
9.2. Informative References
Acknowledgements
Author's Address
RPL is an IPv6 routing protocol for Low-Power and Lossy Networks (LLNs) [RFC6550]. Such networks are usually constrained in device energy and channel capacity. They are formed largely of nodes that offer little processing power and memory, and links that are of variable qualities and support low data rates. Therefore, a significant challenge that a routing protocol for LLNs has to address is minimizing resource consumption without sacrificing reaction time to network changes.
RPL は、低電力および損失の多いネットワーク (LLN) 用の IPv6 ルーティング プロトコル [RFC6550] です。このようなネットワークは通常、デバイスのエネルギーとチャネル容量に制約があります。これらは主に、処理能力とメモリがほとんどないノードと、品質が変動し、低いデータ レートをサポートするリンクで構成されています。したがって、LLN のルーティング プロトコルが対処しなければならない重要な課題は、ネットワークの変更に対する反応時間を犠牲にすることなくリソースの消費を最小限に抑えることです。
One of the main design principles adopted in RPL to minimize node resource consumption is delegating much of the responsibility for routing to LLN Border Routers (LBRs). A network is organized into Destination-Oriented Directed Acyclic Graphs (DODAGs), each corresponding to an LBR and having all its paths terminate at the LBR. To this end, every node is dynamically assigned a Rank representing its distance to a given LBR, measured in some metric, with the LBR having the minimal Rank, which reflects its role as the DODAG root. The Ranks allow each non-LBR node to select from among its neighbors (i.e., nodes to which the node has links) those that are closer to the LBR than the node itself (i.e., the node's parents in the graph). The resulting DODAG paths, consisting of the node-parent links, are utilized for routing packets upward to the LBR and outside the LLN. They are also used by nodes to periodically report their connectivity upward to the LBR, which allows for directing packets downward from the LBR to these nodes (e.g., by means of source routing [RFC6554]). All in all, not only do LBRs participate in routing, but they also drive the process of DODAG construction and maintenance underlying the protocol.
ノード リソースの消費を最小限に抑えるために RPL で採用されている主な設計原則の 1 つは、ルーティングの責任の多くを LLN ボーダー ルーター (LBR) に委任することです。ネットワークは、Destination-Oriented Directed Acyclic Graphs (DODAG) に編成され、各 DODAG は LBR に対応し、すべてのパスが LBR で終端します。この目的を達成するために、すべてのノードには、特定のメトリックで測定された特定の LBR までの距離を表すランクが動的に割り当てられます。LBR は、DODAG ルートとしての役割を反映する最小ランクを持ちます。ランクにより、各非 LBR ノードは、その隣接ノード (つまり、ノードがリンクを持つノード) の中から、ノード自体 (つまり、グラフ内のノードの親) よりも LBR に近いものを選択できます。結果として生じる DODAG パスは、ノードと親のリンクで構成され、LBR および LLN の外側へ上向きにパケットをルーティングするために利用されます。これらは、ノードが LBR に上向きの接続を定期的に報告するためにも使用され、これにより、LBR からこれらのノードにパケットを下向きに送信することが可能になります (たとえば、ソース ルーティング [RFC6554] によって)。全体として、LBR はルーティングに参加するだけでなく、プロトコルの基礎となる DODAG 構築および保守のプロセスも推進します。
To play this central role, LBRs are expected to be more capable than regular LLN nodes. They are assumed not to be constrained in computing power, memory, and energy, which often entails a more involved hardware-software architecture and tethered power supply. However, this also makes them prone to failures, especially since it is often difficult to ensure a backup power supply for every LBR in large deployments.
この中心的な役割を果たすために、LBR には通常の LLN ノードよりも高い能力が期待されます。これらは、コンピューティング能力、メモリ、エネルギーの制約を受けないと想定されており、多くの場合、より複雑なハードウェア/ソフトウェア アーキテクチャと接続された電源が必要になります。ただし、特に大規模な導入ではすべての LBR にバックアップ電源を確保することが困難な場合が多いため、これにより障害が発生しやすくなります。
When an LBR crashes, or more generally, fails in a way that prevents other nodes in its DODAG from communicating with it, the nodes also lose the ability to communicate with other Internet hosts. In addition, a significant fraction of DODAG paths interconnecting the nodes become invalid, as they pass through the dead LBR. The others also degenerate as a result of DODAG repair attempts, which are bound to fail. In effect, routing inside the DODAG also becomes largely impossible. Consequently, it is desirable that an LBR crash be detected by the nodes fast, so that they can leave the broken DODAG and join another one or trigger additional application- or deployment-dependent fallback mechanisms, thereby minimizing the negative impact of the disconnection.
LBR がクラッシュすると、より一般的には、DODAG 内の他のノードが LBR と通信できなくなるような障害が発生すると、ノードは他のインターネット ホストと通信する能力も失います。さらに、ノードを相互接続する DODAG パスのかなりの部分が、デッド LBR を通過するため無効になります。他のものも DODAG 修復試行の結果として縮退しますが、失敗することは間違いありません。実際、DODAG 内のルーティングもほとんど不可能になります。したがって、LBR クラッシュがノードによって迅速に検出され、壊れた DODAG を離れて別の DODAG に参加したり、追加のアプリケーション依存またはデプロイメント依存のフォールバック メカニズムをトリガーしたりして、切断による悪影響を最小限に抑えることができることが望ましいです。
Since all DODAG paths lead to the corresponding LBR, detecting its crash by a node entails dropping all parents and adopting an infinite Rank, which reflects the node's inability to reach the dead LBR. Depending on the deployment settings, the node can then remain in such a state, join a different DODAG, or even become the root of a floating DODAG. In any case, however, achieving this state for all nodes is slow, can generate heavy traffic, and is difficult to implement correctly [Iwanicki16] [Paszkowska19] [Ciolkosz19].
すべての DODAG パスは対応する LBR につながるため、ノードによってそのクラッシュを検出するには、すべての親を削除し、ノードがデッド LBR に到達できないことを反映する無限ランクを採用する必要があります。デプロイメント設定に応じて、ノードはそのような状態を維持したり、別の DODAG に参加したり、フローティング DODAG のルートになることもあります。ただし、いずれの場合も、すべてのノードでこの状態を達成するには時間がかかり、大量のトラフィックが発生する可能性があり、正しく実装するのが困難です [Iwanicki16] [Paszkowska19] [Ciolkosz19]。
To start with, tearing down all DODAG paths requires each of the dead LBR's neighbors to detect that its link with the LBR is no longer up. Otherwise, any of the neighbors unaware of this fact can keep advertising a finite Rank and can thus be other nodes' parent or ancestor in the DODAG; such nodes will incorrectly believe they have a valid path to the dead LBR. Detecting a crash of a link by a node normally happens when the node has observed a sufficient number of forwarding failures over the link. Therefore, considering the low-data-rate applications of LLNs, the period from the crash to the moment of eliminating the last link to the dead LBR from the DODAG may be long. Subsequently, learning by all nodes that none of their links can form any path leading to the dead LBR also adds latency, partly due to parent changes that the nodes independently perform in attempts to repair their broken paths locally. Since a non-LBR node has only local knowledge of the network, potentially inconsistent with that of other nodes, such parent changes often produce paths containing loops, which have to be broken before all nodes can conclude that no path to the dead LBR exists globally. Even with RPL's dedicated loop detection mechanisms [RFC6553], this also requires traffic and hence time. Finally, switching a parent or discovering a loop can also generate cascaded bursts of control traffic, owing to the adaptive Trickle algorithm for exchanging DODAG information [RFC6206]. Overall, the behavior of the network when handling an LBR crash is highly suboptimal, thereby not being in line with RPL's goals of minimizing resource consumption and reaction latencies.
まず、すべての DODAG パスを切断するには、停止した LBR の各隣接ノードが、その LBR とのリンクがもうアップしていないことを検出する必要があります。そうしないと、この事実に気づかない近隣ノードが有限のランクをアドバタイズし続ける可能性があり、DODAG 内の他のノードの親または祖先になる可能性があります。このようなノードは、デッド LBR への有効なパスがあると誤って信じてしまいます。ノードによるリンクのクラッシュの検出は、通常、ノードがリンク上で十分な数の転送障害を観察した場合に発生します。したがって、LLN の低データ レートのアプリケーションを考慮すると、クラッシュから、DODAG からデッド LBR への最後のリンクが削除されるまでの期間が長くなる可能性があります。その後、すべてのノードが、どのリンクもデッド LBR につながるパスを形成できないことを学習すると、遅延が増加します。これは、ノードが壊れたパスをローカルで修復しようとして独自に実行する親の変更が部分的に原因です。非 LBR ノードはネットワークについてローカルな情報しか持たず、他のノードの情報と矛盾する可能性があるため、このような親の変更によりループを含むパスが生成されることが多く、すべてのノードが無効な LBR へのパスがグローバルに存在しないと結論付ける前にループを解除する必要があります。RPL の専用ループ検出メカニズム [RFC6553] を使用しても、これにはトラフィックが必要となり、時間がかかります。最後に、DODAG 情報を交換するための適応トリクル アルゴリズム [RFC6206] により、親を切り替えるかループを発見すると、制御トラフィックのカスケード バーストが生成される可能性があります。全体として、LBR クラッシュを処理するときのネットワークの動作は非常に最適ではないため、リソース消費と反応遅延を最小限に抑えるという RPL の目標とは一致しません。
To address this issue, this document proposes an extension to RPL, dubbed the "Root Node Failure Detector (RNFD)". To minimize the time and traffic required to handle an LBR crash, the RNFD algorithm adopts the following design principles, derived directly from the previous observations:
この問題に対処するために、この文書では「Root Node Failure Detector (RNFD)」と呼ばれる RPL の拡張機能を提案します。LBR クラッシュの処理に必要な時間とトラフィックを最小限に抑えるために、RNFD アルゴリズムは、以前の観察から直接導き出された次の設計原則を採用しています。
1. Explicitly coordinating LBR monitoring between nodes instead of relying only on the emergent behavior resulting from their independent operation.
1. ノードの独立した動作から生じる緊急の動作のみに依存するのではなく、ノード間の LBR 監視を明示的に調整します。
2. Avoiding probing all links to the dead LBR so as to reduce the tail latency when eliminating these links from the DODAG.
2. DODAG からこれらのリンクを削除するときに、デッド LBR へのすべてのリンクをプローブすることを回避し、テール レイテンシを短縮します。
3. Exploiting concurrency by prompting proactive checking for a possible LBR crash when some nodes suspect such a failure may have taken place, which aims to further reduce the overall latency.
3. 一部のノードで LBR クラッシュの可能性が疑われる場合に、そのような障害が発生した可能性があることを事前にチェックすることで同時実行性を利用し、全体的なレイテンシーをさらに短縮することを目的としています。
4. Minimizing changes to RPL's existing algorithms by operating in parallel and largely independently (in the background) and by introducing few additional assumptions.
4. 並行してほぼ独立して (バックグラウンドで) 動作し、追加の仮定をいくつか導入することにより、RPL の既存のアルゴリズムへの変更を最小限に抑えます。
While these principles do improve RPL's performance under a wide range of LBR crashes, their probabilistic nature precludes hard guarantees for all possible corner cases. In particular, in some scenarios, RNFD's operation may result in false negatives, but these situations are peculiar and will eventually be handled by RPL's own aforementioned mechanisms. Likewise, in some scenarios, notably involving highly unstable links, false positives may occur, but they can be alleviated as well. In any case, the principles also guarantee that RNFD can be deactivated at any time if needed, in which case RPL's operation is unaffected.
これらの原則は、広範囲の LBR クラッシュの下で RPL のパフォーマンスを向上させますが、その確率的な性質により、考えられるすべての例外的なケースに対する確実な保証は不可能です。特に、一部のシナリオでは、RNFD の操作により偽陰性が発生する可能性がありますが、これらの状況は特殊であり、最終的には RPL 独自の前述のメカニズムによって処理されます。同様に、一部のシナリオでは、特に非常に不安定なリンクが関係する場合、誤検知が発生する可能性がありますが、同様に軽減することができます。いずれの場合でも、この原則は、必要に応じていつでも RNFD を非アクティブ化できることも保証しており、その場合でも RPL の動作は影響を受けません。
Given the consequences of LBR failures, it is also worth considering other solutions to the problem. More specifically, power outages can be alleviated by provisioning redundant power sources or emergency batteries. Likewise, RPL's so-called virtual DODAG roots can help tolerate some failures of individual LBRs.
LBR 障害の影響を考慮すると、この問題に対する他の解決策を検討する価値もあります。具体的には、冗長電源や非常用バッテリーを設置することで停電を軽減できます。同様に、RPL のいわゆる仮想 DODAG ルートは、個々の LBR の一部の障害を許容するのに役立ちます。
As mentioned previously, RNFD has been designed to be largely independent of those solutions; that is, rather than aiming to be their replacement, RNFD can complement them. In particular, the operation of RNFD with different variants of virtual DODAG roots is covered in Section 6.2.
前述したように、RNFD はこれらのソリューションからほとんど独立するように設計されています。つまり、RNFD はそれらの代替となることを目指すのではなく、それらを補完することができます。特に、仮想 DODAG ルートのさまざまなバリアントを使用した RNFD の操作については、セクション 6.2 で説明します。
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] で説明されているように解釈されます。
The terminology used in this document is consistent with and incorporates that described in "Terms Used in Routing for Low-Power and Lossy Networks" [RFC7102], "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks" [RFC6550], and "The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams" [RFC6553]. Other terms used in LLNs can be found in "Terminology for Constrained-Node Networks" [RFC7228].
この文書で使用される用語は、「低電力および損失の多いネットワークのルーティングで使用される用語」[RFC7102]、「RPL: 低電力および損失の多いネットワークのための IPv6 ルーティング プロトコル」[RFC6550]、および「データプレーン データグラムで RPL 情報を搬送するための低電力および損失の多いネットワーク用のルーティング プロトコル (RPL) オプション」と一致しており、それらを組み込んでいます。
[RFC6553]。LLN で使用されるその他の用語は、「Terminology for Constrained-Node Networks」[RFC7228] に記載されています。
In particular, the following acronyms appear in the document:
特に、この文書には次の頭字語が使用されます。
DIO:
DIO:
DODAG Information Object (a RPL message)
DODAG 情報オブジェクト (RPL メッセージ)
DIS:
DIS:
DODAG Information Solicitation (a RPL message)
DODAG 情報要請 (RPL メッセージ)
DODAG:
ドーダグ:
Destination-Oriented Directed Acyclic Graph
宛先指向の有向非巡回グラフ
LLN:
LLN:
Low-Power and Lossy Network
低電力で損失の多いネットワーク
LBR:
LBR:
LLN Border Router
LLN ボーダールーター
In addition, the document introduces the following concepts:
さらに、このドキュメントでは次の概念が紹介されています。
Sentinel:
センチネル:
One of the two roles that a node can play in RNFD. For a given DODAG Version, a Sentinel node is a DODAG root's neighbor that monitors the DODAG root's status. There are normally multiple Sentinels for a DODAG root. However, being the DODAG root's neighbor need not imply being a Sentinel.
RNFD でノードが果たせる 2 つの役割の 1 つ。特定の DODAG バージョンの場合、Sentinel ノードは DODAG ルートのステータスを監視する DODAG ルートの近隣ノードです。通常、DODAG ルートには複数の Sentinel が存在します。ただし、DODAG ルートのネイバーであることは、センチネルであることを意味する必要はありません。
Acceptor:
アクセプター:
The other of the two roles that a node can play in RNFD. For a given DODAG Version, an Acceptor node is a node that is not a Sentinel.
RNFD でノードが果たせる 2 つの役割のうちのもう 1 つ。特定の DODAG バージョンの場合、アクセプター ノードはセンチネルではないノードです。
Locally Observed DODAG Root's State (LORS):
ローカルで観測された DODAG ルート状態 (LORS):
A node's local knowledge of the DODAG root's status, specifying in particular whether the DODAG root is up.
DODAG ルートのステータスに関するノードのローカル情報。特に、DODAG ルートが稼働しているかどうかを指定します。
Conflict-Free Replicated Counter (CFRC):
競合のない複製カウンター (CFRC):
Conceptually represents a dynamic set whose cardinality can be estimated. It defines a partial order on its values and supports element addition and union. The union operation is order- and duplicate-insensitive, that is, idempotent, commutative, and associative.
カーディナリティを推定できる動的セットを概念的に表します。値の半順序を定義し、要素の追加と結合をサポートします。結合演算は順序や重複に影響されません。つまり、冪等、可換、結合です。
As mentioned previously, LBRs are DODAG roots in RPL; hence, a crash of an LBR is global in that it affects all nodes in the corresponding DODAG. Therefore, each node running RNFD for a given DODAG explicitly tracks the DODAG root's current condition, which is referred to as Locally Observed DODAG Root's State (LORS), and synchronizes its local knowledge with other nodes.
前述したように、LBR は RPL の DODAG ルートです。したがって、LBR のクラッシュは、対応する DODAG 内のすべてのノードに影響するという点でグローバルです。したがって、特定の DODAG に対して RNFD を実行している各ノードは、ローカルで観察された DODAG ルートの状態 (LORS) と呼ばれる DODAG ルートの現在の状態を明示的に追跡し、そのローカルな情報を他のノードと同期します。
Since monitoring the condition of the DODAG root is performed by tracking the status of its links (i.e., whether they are up or down), it can only be done by the root's neighbors; other nodes must accept their observations. Consequently, depending on their roles, non-root nodes are divided in RNFD into two disjoint groups: Sentinels and Acceptors. A Sentinel node is a DODAG root's neighbor that monitors its link with the root. Thus, the DODAG root normally has multiple Sentinels, but being its neighbor need not imply being a Sentinel. An Acceptor node is a node that is not a Sentinel. Acceptors thus mainly collect and propagate Sentinels' observations. More information on Sentinel selection can be found in Section 6.1.
DODAG ルートの状態の監視は、そのリンクのステータス (つまり、アップかダウンか) を追跡することによって実行されるため、ルートの近隣者によってのみ実行できます。他のノードはその観察を受け入れる必要があります。その結果、RNFD では、その役割に応じて、ルート以外のノードが 2 つの独立したグループ (センチネルとアクセプター) に分割されます。Sentinel ノードは、ルートとのリンクを監視する DODAG ルートの近隣ノードです。したがって、DODAG ルートには通常複数の Sentinel がありますが、その近隣であることは Sentinel であることを意味する必要はありません。アクセプター ノードはセンチネルではないノードです。したがって、アクセプターは主にセンチネルの観察を収集し、広めます。Sentinel の選択の詳細については、セクション 6.1 を参照してください。
The possible values of LORS and transitions between them are depicted in Figure 1. States "UP" and "GLOBALLY DOWN" can be attained by both Sentinels and Acceptors; states "SUSPECTED DOWN" and "LOCALLY DOWN" can be attained by Sentinels only.
LORS の可能な値とそれらの間の遷移を図 1 に示します。状態「UP」と「GLOBALLY DOWN」はセンチネルとアクセプターの両方で達成できます。「SUSPECTED DOWN」と「LOCALLY DOWN」はセンチネルのみが達成できると述べています。
+---------------------------------------------------------+
| |---------------------------+ 3a |
| +-----------------+---------+ 3b | |
| | 2b | v v v
+-+----+-+ 1 +---------+-+ +-----------+ +-+------+-+
| UP +---->+ SUSPECTED +---->+ LOCALLY +---->+ GLOBALLY |
| +<----+ DOWN | 2a | DOWN | 3c | DOWN |
+-+----+-+ 4a +-----------+ +-+---------+ +-+--------+
^ ^ | |
| | 4b | |
| +---------------------------+ 5 |
+--------------------------------------------------+
Figure 1: RNFD States and Transitions
図 1: RNFD の状態と遷移
To begin with, when any node joins a DODAG Version, the DODAG root must appear alive, so the node initializes RNFD with its LORS equal to "UP". For a properly working DODAG root, the node remains in state "UP".
まず、いずれかのノードが DODAG バージョンに参加すると、DODAG ルートが生きているように見える必要があるため、ノードは LORS を「UP」に設定して RNFD を初期化します。DODAG ルートが適切に動作している場合、ノードは「UP」状態のままです。
However, when a node acting as a Sentinel starts suspecting that the root may have crashed, it changes its LORS to "SUSPECTED DOWN" (transition 1 in Figure 1). The transition from "UP" to "SUSPECTED DOWN" can happen based on the node's observations at either the data plane (e.g., link-layer triggers about missing hop-by-hop acknowledgments for packets forwarded over the node's link to the root) or at the control plane (e.g., a significant growth in the number of Sentinels already suspecting the root to be dead). In state "SUSPECTED DOWN", the Sentinel node may verify its suspicion and/or inform other nodes about the suspicion. When this has been done, it changes its LORS to "LOCALLY DOWN" (transition 2a). In some cases, the verification need not be performed, and as an optimization, a direct transition from "UP" to "LOCALLY DOWN" (transition 2b) can be done instead.
ただし、Sentinel として機能するノードがルートがクラッシュした可能性があると疑い始めると、LORS を「SUSPECTED DOWN」に変更します (図 1 の遷移 1)。「UP」から「SUSPECTED DOWN」への遷移は、データ プレーン (例: ノードのリンクを介してルートに転送されたパケットのホップバイホップ確認応答の欠落に関するリンク層トリガー) またはコントロール プレーン (例: ルートが停止していると既に疑っているセンチネルの数の大幅な増加) でのノードの観察に基づいて発生する可能性があります。「SUSPECTED DOWN」状態では、Sentinel ノードはその疑いを検証し、および/またはその疑いについて他のノードに通知することができます。これが完了すると、LORS が「LOCALLY DOWN」に変更されます (遷移 2a)。場合によっては、検証を実行する必要がなく、最適化として、代わりに「UP」から「LOCALLY DOWN」への直接遷移 (遷移 2b) を実行できます。
If a sufficient number of Sentinels have their LORS equal to "LOCALLY DOWN", all nodes (Sentinels and Acceptors) consent globally that the DODAG root must have crashed and set their LORS to "GLOBALLY DOWN", irrespective of the previous value (transitions 3a, 3b, and 3c). State "GLOBALLY DOWN" is terminal in that the only transition any node can perform from this to another state (transition 5) takes place when the node joins a new DODAG Version. When a node is in state "GLOBALLY DOWN", RNFD forces RPL to maintain an infinite Rank and no parent, thereby preventing routing packets upward in the DODAG. In other words, this state represents a situation in which all non-root nodes agree that the current DODAG Version is unusable; hence, to recover, the root has to give a proof of being alive by initiating a new DODAG Version.
十分な数の Sentinel の LORS が「LOCALLY DOWN」に等しい場合、すべてのノード (Sentinel と Acceptor) は、DODAG ルートがクラッシュし、以前の値に関係なく LORS を「GLOBALLY DOWN」に設定する必要があることにグローバルに同意します (遷移 3a、3b、および 3c)。「GLOBALLY DOWN」状態は、ノードが新しい DODAG バージョンに参加するときに、ノードが実行できる唯一の状態から別の状態への遷移 (遷移 5) が発生するという点で終端です。ノードが「GLOBALLY DOWN」状態にある場合、RNFD は RPL に無限ランクを維持させ、親を持たないよう強制するため、パケットが DODAG 内で上向きにルーティングされるのを防ぎます。言い換えれば、この状態は、ルート以外のすべてのノードが現在の DODAG バージョンが使用できないことに同意している状況を表します。したがって、回復するには、ルートが新しい DODAG バージョンを開始して生存の証明を提供する必要があります。
In contrast, if a node (either a Sentinel or Acceptor) is in state "UP", RNFD does not influence RPL's packet forwarding; a node can route packets upward if it has a parent. The same is true for states "SUSPECTED DOWN" and "LOCALLY DOWN", attainable only by Sentinels. Finally, while in any of the two states, a Sentinel node may observe some activity of the DODAG root and hence decide that its suspicion is a mistake. In such a case, it returns to state "UP" (transitions 4a and 4b).
対照的に、ノード (センチネルまたはアクセプター) が状態「UP」にある場合、RNFD は RPL のパケット転送に影響を与えません。ノードに親がある場合、ノードはパケットを上向きにルーティングできます。「SUSPECTED DOWN」および「LOCALLY DOWN」状態についても同様であり、センチネルのみが到達できます。最後に、2 つの状態のいずれかにあるときに、Sentinel ノードが DODAG ルートのアクティビティを観察し、その疑いが間違いであると判断する可能性があります。このような場合には、状態「ＵＰ」に戻る（遷移４ａおよび４ｂ）。
To enable arriving at a global conclusion that the DODAG root has crashed (i.e., transiting to state "GLOBALLY DOWN"), all nodes count locally and synchronize among each other the number of Sentinels considering the root to be dead (i.e., those in state "LOCALLY DOWN"). This process employs structures referred to as Conflict-Free Replicated Counters (CFRCs). They are stored and modified independently by each node and are disseminated throughout the network in options added to RPL link-local control messages: DODAG Information Objects (DIOs) and DODAG Information Solicitations (DISs). Upon reception of such an option from its neighbor, a node merges the received counter with its local one, thereby obtaining a new content for its local counter.
DODAG ルートがクラッシュした (つまり、「GLOBALLY DOWN」状態に移行した) というグローバルな結論に達することを可能にするために、すべてのノードがローカルでカウントし、ルートが停止しているとみなされるセンチネル (つまり、「LOCALLY DOWN」状態にあるセンチネル) の数を相互に同期します。このプロセスでは、Conflict-Free Replicated Counters (CFRC) と呼ばれる構造が使用されます。これらは、各ノードによって個別に保存および変更され、RPL リンクローカル制御メッセージに追加されるオプションである DODAG Information Object (DIO) および DODAG Information Solicitations (DIS) でネットワーク全体に配布されます。近隣ノードからそのようなオプションを受信すると、ノードは受信したカウンタをローカルのカウンタとマージし、それによってローカル カウンタの新しい内容を取得します。
The merging operation is idempotent, commutative, and associative. Moreover, all possible counter values are partially ordered. This enables ensuring eventual consistency of the counters across all nodes, irrespective of the particular sequence of merges, shape of the DODAG, or general network topology. In effect, as long as the network is connected, all nodes will be able to arrive at the same conclusion regarding the DODAG root, in particular when no two Sentinels have a direct link with each other.
マージ操作は冪等性、可換性、結合性があります。さらに、すべての可能なカウンタ値は部分的に順序付けされています。これにより、マージの特定のシーケンス、DODAG の形状、または一般的なネットワーク トポロジに関係なく、すべてのノードにわたるカウンターの最終的な一貫性を確保できます。実際、ネットワークが接続されている限り、特に 2 つの Sentinel が互いに直接リンクしていない場合、すべてのノードは DODAG ルートに関して同じ結論に達することができます。
Each node in RNFD maintains two CFRCs for a DODAG:
RNFD の各ノードは、DODAG に対して 2 つの CFRC を維持します。
PositiveCFRC:
ポジティブCFRC:
Counts Sentinels that consider or have previously considered the root node as alive in the current DODAG Version.
現在の DODAG バージョンでルート ノードが生きているとみなしている、または以前にみなしていたセンチネルをカウントします。
NegativeCFRC:
ネガティブCFRC:
Counts Sentinels that consider or have previously considered the root node as dead in the current DODAG Version.
現在の DODAG バージョンでルート ノードが停止しているとみなしている、または以前にルート ノードが停止しているとみなしたセンチネルをカウントします。
The PositiveCFRC is always greater than or equal to the NegativeCFRC in terms of the partial order defined for the counters. The difference between the value of the PositiveCFRC and the value of the NegativeCFRC is thus nonnegative and estimates the number of Sentinels that still consider the DODAG root node as alive.
PositiveCFRC は、カウンタに定義された半順序の点で常に NegativeCFRC 以上です。したがって、PositiveCFRC の値と NegativeCFRC の値の差は負ではなく、DODAG ルート ノードがまだ生きているとみなしているセンチネルの数を推定します。
RNFD state synchronization between nodes takes place through the RNFD Option. It is a new type of RPL Control Message Option that is carried in link-local RPL control messages, notably DIOs and DISs. Its main task is allowing the receivers to merge their two CFRCs with the sender's CFRCs.
ノード間の RNFD 状態の同期は、RNFD オプションを通じて行われます。これは、リンクローカル RPL 制御メッセージ、特に DIO および DIS で伝送される新しいタイプの RPL 制御メッセージ オプションです。その主なタスクは、受信者が 2 つの CFRC を送信者の CFRC とマージできるようにすることです。
CFRCs in RNFD MUST support the following operations:
RNFD の CFRC は、次の操作をサポートしなければなりません。
value(c)
値(c)
Returns a nonnegative integer value corresponding to the number of nodes counted by a given CFRC, c.
指定された CFRC によってカウントされたノードの数に対応する非負の整数値を返します。 c.
zero()
ゼロ（）
Returns a CFRC that counts no nodes, that is, has its value equal to 0.
ノードをカウントしない、つまり値が 0 に等しい CFRC を返します。
self()
自己（）
Returns a CFRC that counts only the node executing the operation.
操作を実行しているノードのみをカウントする CFRC を返します。
infinity()
無限大()
Returns a CFRC that counts all possible nodes and represents a special value, infinity.
考えられるすべてのノードをカウントし、特別な値である無限大を表す CFRC を返します。
merge(c1, c2)
マージ(c1, c2)
Returns a CFRC that is a union of c1 and c2 (i.e., counts all nodes that are counted by either c1, c2, or both c1 and c2).
c1 と c2 の和集合である CFRC を返します (つまり、c1、c2、または c1 と c2 の両方によってカウントされるすべてのノードをカウントします)。
compare(c1, c2)
比較(c1, c2)
Returns the result of comparing c1 to c2.
c1 と c2 を比較した結果を返します。
saturated(c)
飽和(c)
Returns TRUE if a given CFRC, c, is saturated (i.e., no more new nodes should be counted by it); returns FALSE otherwise.
指定された CFRC c が飽和している (つまり、これ以上新しいノードをカウントする必要がない) 場合は TRUE を返します。それ以外の場合は FALSE を返します。
The partial ordering of CFRCs implies that the result of compare(c1, c2) can be either:
CFRC の部分的な順序付けは、compare(c1, c2) の結果が次のいずれかになることを意味します。
* smaller, if c1 is ordered before c2 (i.e., c2 counts all nodes that c1 counts and at least one node that c1 does not count);
* c1 が c2 より前に順序付けされている場合 (つまり、c2 は、c1 がカウントするすべてのノードと、c1 がカウントしない少なくとも 1 つのノードをカウントします) の場合は小さくなります。
* greater, if c1 is ordered after c2 (i.e., c1 counts all nodes that c2 counts and at least one node that c2 does not count);
* c1 が c2 の後に順序付けされている場合は大きくなります (つまり、c1 は、c2 がカウントするすべてのノードと、c2 がカウントしない少なくとも 1 つのノードをカウントします)。
* equal, if c1 and c2 are the same (i.e., they count the same nodes); or
* c1 と c2 が同じ (つまり、同じノードを数える) 場合は等しい。または
* incomparable, otherwise.
* そうでなければ、比類のないもの。
In particular, zero() is smaller than all other values, and infinity() is greater than any other value.
特に、zero() は他のすべての値より小さく、infinity() は他のどの値よりも大きくなります。
The properties of merging can be formalized as follows for any c1, c2, and c3:
マージのプロパティは、c1、c2、および c3 について次のように形式化できます。
* idempotence: c1 = merge(c1, c1);
* べき等: c1 = merge(c1, c1);
* commutativity: merge(c1, c2) = merge(c2, c1); and
* 可換性: マージ(c1, c2) = マージ(c2, c1);そして
* associativity: merge(c1, merge(c2, c3)) = merge(merge(c1, c2), c3).
* 結合性: マージ(c1, マージ(c2, c3)) = マージ(マージ(c1, c2), c3)。
In particular, merge(c, zero()) always equals c, while merge(c, infinity()) always equals infinity().
特に、merge(c, zero()) は常に c と等しくなりますが、merge(c, infinity()) は常に infinity() と等しくなります。
There are many algorithmic structures that can provide the aforementioned properties of CFRC. Although in principle RNFD does not rely on any specific one, the option adopts so-called linear counting [Whang90].
前述の CFRC の特性を提供できるアルゴリズム構造は数多くあります。原則として RNFD は特定のものに依存しませんが、このオプションはいわゆる線形カウンティングを採用しています [Whang90]。
The format of the RNFD Option conforms to the generic format of RPL Control Message Options (see Section 6.7.1 of [RFC6550]):
RNFD オプションの形式は、RPL 制御メッセージ オプションの一般的な形式に準拠しています ([RFC6550] のセクション 6.7.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x0E | Option Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| PosCFRC, NegCFRC (Variable Length*) |
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Format of the RNFD Option
図 2: RNFD オプションのフォーマット
The "*" denotes that, if present, the fields have equal lengths.
「*」は、存在する場合、フィールドの長さが等しいことを示します。
Option Type:
オプションの種類:
0x0E
0x0E
Option Length:
オプションの長さ:
8-bit unsigned integer. Denotes the length of the option in octets, excluding the Option Type and Option Length fields. Its value MUST be even. A value of 0 denotes that RNFD is disabled in the current DODAG Version.
8 ビットの符号なし整数。「オプション タイプ」フィールドと「オプション長」フィールドを除く、オプションの長さをオクテット単位で示します。その値は偶数でなければなりません。値 0 は、RNFD が現在の DODAG バージョンで無効になっていることを示します。
PosCFRC, NegCFRC:
PosCFRC、NegCFRC:
Two variable-length, octet-aligned bit arrays carrying the sender's PositiveCFRC and NegativeCFRC, respectively.
送信者の PositiveCFRC と NegativeCFRC をそれぞれ伝送する 2 つの可変長の、オクテットに位置合わせされたビット配列。
The length of the arrays constituting the PosCFRC and NegCFRC fields is the same and is derived from Option Length as follows. The value of Option Length is divided by 2 to obtain the number of octets each of the two arrays occupies. The resulting number of octets is multiplied by 8, which yields an upper bound on the number of bits in each array. As the actual bit length of each of the arrays, the largest prime number less than the upper bound is assumed. For example, if the value of Option Length is 16, then each array occupies 8 octets, and its actual bit length is 61, as this is the largest prime number less than 64.
PosCFRC フィールドと NegCFRC フィールドを構成する配列の長さは同じであり、次のように Option Length から導出されます。Option Length の値を 2 で割ると、2 つの配列がそれぞれ占有するオクテット数が得られます。結果のオクテット数は 8 倍され、各配列のビット数の上限が決まります。各配列の実際のビット長としては、上限値以下の最大の素数を仮定する。たとえば、オプションの長さの値が 16 の場合、各配列は 8 オクテットを占有し、実際のビット長は 61 になります。これは、64 未満の最大の素数であるためです。
Furthermore, for any bit equal to 1 in the NegCFRC, the bit with the same index MUST also be equal to 1 in the PosCFRC. Any unused bits (i.e., the bits beyond the actual bit length of each of the arrays) MUST be equal to 0. Finally, if PosCFRC has all its bits equal to 1, then NegCFRC MUST also have all its bits equal to 1.
さらに、NegCFRC で 1 に等しいビットについては、同じインデックスを持つビットも PosCFRC で 1 に等しくなければなりません (MUST)。未使用のビット (つまり、各配列の実際のビット長を超えるビット) は 0 に等しくなければなりません (MUST)。 最後に、PosCFRC のすべてのビットが 1 に等しい場合、NegCFRC もすべてのビットが 1 に等しくなければなりません (MUST)。
The CFRC operations are defined for such bit arrays of a given length as follows:
CFRC 演算は、指定された長さのビット配列に対して次のように定義されます。
value(c)
値(c)
Returns the smallest integer value not less than -LT*ln(L0/LT), where ln() is the natural logarithm function, L0 is the number of bits equal to 0 in the array corresponding to c, and LT is the bit length of the array.
-LT*ln(L0/LT) 以上の最小の整数値を返します。ここで、ln() は自然対数関数、L0 は c に対応する配列内の 0 に等しいビット数、LT は配列のビット長です。
zero()
ゼロ（）
Returns an array with all bits equal to 0.
すべてのビットが 0 に等しい配列を返します。
self()
自己（）
Returns an array with a single bit, selected uniformly at random, equal to 1.
均一にランダムに選択された 1 に等しい単一ビットの配列を返します。
infinity()
無限大()
Returns an array with all bits equal to 1.
すべてのビットが 1 に等しい配列を返します。
merge(c1, c2)
マージ(c1, c2)
Returns a bit array that constitutes a bitwise OR of c1 and c2. That is, a bit in the resulting array is equal to 0 only if the same bit is equal to 0 in both c1 and c2.
c1 と c2 のビット単位の OR を構成するビット配列を返します。つまり、結果の配列内のビットが 0 になるのは、c1 と c2 の両方で同じビットが 0 に等しい場合のみです。
compare(c1, c2)
比較(c1, c2)
Returns:
戻り値:
* equal, if each bit of c1 is equal to the corresponding bit of c2;
* c1 の各ビットが c2 の対応するビットと等しい場合は等しい。
* less, if c1 and c2 are not equal, and for each bit equal to 1 in c1, the corresponding bit in c2 is also equal to 1;
* 以下、c1 と c2 が等しくなく、c1 の各ビットが 1 に等しい場合、c2 の対応するビットも 1 に等しくなります。
* greater, if c1 and c2 are not equal, and for each bit equal to 1 in c2, the corresponding bit in c1 is also equal to 1; or
* より大きい場合、c1 と c2 が等しくなく、c2 の各ビットが 1 に等しい場合、c1 の対応するビットも 1 に等しくなります。または
* incomparable, otherwise.
* そうでなければ、比類のないもの。
saturated(c)
飽和(c)
Returns TRUE if more than RNFD_CFRC_SATURATION_THRESHOLD of the bits in c are equal to 1; returns FALSE otherwise.
c のビットのうち RNFD_CFRC_SATURATION_THRESHOLD を超えるビットが 1 に等しい場合は TRUE を返します。それ以外の場合は FALSE を返します。
Although RNFD operates largely independently of RPL, it does need to interact with RPL and the overall protocol stack. These interactions are described next and can be realized, for instance, by means of event triggers.
RNFD は主に RPL とは独立して動作しますが、RPL およびプロトコル スタック全体と対話する必要があります。これらの対話については次に説明しますが、たとえばイベント トリガーによって実現できます。
Whenever RPL is running at a node and joins a DODAG Version, RNFD (if active) MUST assume the role of Acceptor for the node. Accordingly, it MUST set its LORS to "UP" and its PositiveCFRC and NegativeCFRC to zero().
RPL がノードで実行され、DODAG バージョンに参加するときは常に、RNFD (アクティブな場合) がノードのアクセプターの役割を引き受けなければなりません (MUST)。したがって、LORS を「UP」に設定し、PositiveCFRC と NegativeCFRC を zero() に設定しなければなりません。
The role may then change between Acceptor and Sentinel at any time. However, while a switch from Sentinel to Acceptor has no preconditions, in order for a switch from Acceptor to Sentinel to be possible, _all_ of the following conditions MUST hold:
その後、役割はいつでもアクセプターとセンチネルの間で変更される可能性があります。ただし、Sentinel から Acceptor への切り替えには前提条件がありませんが、Acceptor から Sentinel への切り替えを可能にするためには、次の条件のすべてが満たされなければなりません。
1. LORS is "UP";
1. LORS は「アップ」です。
2. saturated(PositiveCFRC) is FALSE;
2. 飽和(PositiveCFRC) は FALSE です。
3. a neighbor entry for the DODAG root is present in RPL's DODAG parent set; and
3. DODAG ルートの隣接エントリが RPL の DODAG 親セットに存在します。そして
4. the neighbor is considered reachable via its link-local IPv6 address.
4. 近隣ノードは、そのリンクローカル IPv6 アドレスを介して到達可能であるとみなされます。
A role change also requires appropriate updates to LORS and CFRCs, so that the node is properly accounted for. More specifically, when changing its role from Acceptor to Sentinel, the node MUST add itself to its PositiveCFRC as follows. It MUST generate a new CFRC value, selfc = self(), and it MUST replace its PositiveCFRC, denoted oldpc, with newpc = merge(oldpc, selfc). In contrast, the effects of a switch from Sentinel to Acceptor vary depending on the node's value of LORS before the switch:
ロールの変更には、ノードが適切に考慮されるように、LORS と CFRC に対する適切な更新も必要です。より具体的には、その役割をアクセプターからセンチネルに変更するとき、ノードは次のように自身をその PositiveCFRC に追加しなければなりません (MUST)。新しい CFRC 値 selfc = self() を生成しなければならず、oldpc で示される PositiveCFRC を newpc = merge(oldpc, selfc) に置き換えなければなりません。対照的に、Sentinel から Acceptor への切り替えの効果は、切り替え前のノードの LORS の値に応じて異なります。
* For "GLOBALLY DOWN", the node MUST NOT modify its LORS, PositiveCFRC, and NegativeCFRC.
* 「GLOBALLY DOWN」の場合、ノードは LORS、PositiveCFRC、および NegativeCFRC を変更してはなりません (MUST NOT)。
* For "LOCALLY DOWN", the node MUST set its LORS to "UP" but MUST NOT modify its PositiveCFRC and NegativeCFRC.
* 「LOCALLY DOWN」の場合、ノードは LORS を「UP」に設定しなければなりませんが、PositiveCFRC と NegativeCFRC を変更してはなりません。
* For "UP" and "SUSPECTED DOWN", the node MUST set its LORS to "UP" and MUST NOT modify its PositiveCFRC, but the node MUST add itself to NegativeCFRC, by replacing its NegativeCFRC, denoted oldnc, with newnc = merge(oldnc, selfc), where selfc is the counter generated with self() when the node last added itself to its PositiveCFRC.
* 「UP」および「SUSPECTED DOWN」の場合、ノードは LORS を「UP」に設定しなければならず、PositiveCFRC を変更してはなりません。ただし、ノードは、oldnc で示される NegativeCFRC を newnc = merge(oldnc, selfc) に置き換えることによって、自身を NegativeCFRC に追加しなければなりません。ここで、selfc は、ノードが最後に自身を PositiveCFRC に追加したときに self() で生成されたカウンターです。
Only nodes that are Sentinels take an active part in detecting crashes of the DODAG root; Acceptors just disseminate their observations, reflected in the CFRCs.
Sentinel であるノードのみが、DODAG ルートのクラッシュの検出に積極的に関与します。受け入れ者は、CFRC に反映された観察結果を広めるだけです。
The DODAG root monitoring SHOULD be based on both internal inputs, notably the values of CFRCs and LORS, and external inputs, such as triggers from RPL and other protocols. External input monitoring SHOULD be performed preferably in a reactive fashion, also independently of RPL, and at both the data plane and control plane. In particular, it is RECOMMENDED that RNFD be directly notified of events relevant to the routing adjacency maintenance mechanisms on which RPL relies, such as Layer 2 (L2) triggers [RFC5184] or the Neighbor Unreachability Detection [RFC4861] mechanism. In addition, depending on the underlying protocol stack, there may be other potential sources of such events, for instance, neighbor communication overhearing. In any case, only events concerning the DODAG root need to be monitored. For example, RNFD can conclude that there may be problems with the DODAG root if it observes a lack of multiple consecutive L2 acknowledgments for packets transmitted by the node via the link to the DODAG root. Internally, in turn, it is RECOMMENDED that RNFD take action whenever there is a change to its local CFRCs, so that a node can have a chance to participate in detecting potential problems even when normally it would not exchange packets over the link with the DODAG root during some period. In particular, RNFD SHOULD conclude that there may be problems with the DODAG root when the fraction value(NegativeCFRC)/value(PositiveCFRC) has grown by at least RNFD_SUSPICION_GROWTH_THRESHOLD since the node last set its LORS to "UP".
DODAG ルート監視は、内部入力、特に CFRC と LORS の値と、RPL や他のプロトコルからのトリガーなどの外部入力の両方に基づくべきです(SHOULD)。外部入力モニタリングは、RPL とは独立して、データ プレーンとコントロール プレーンの両方で事後対応的に実行することが望ましいです (SHOULD)。特に、レイヤ 2 (L2) トリガー [RFC5184] や近隣到達不能検出 [RFC4861] メカニズムなど、RPL が依存するルーティング隣接関係維持メカニズムに関連するイベントを RNFD に直接通知することが推奨されます。さらに、基礎となるプロトコル スタックによっては、近隣通信の傍聴など、このようなイベントの潜在的な原因が他にも存在する可能性があります。いずれの場合も、DODAG ルートに関するイベントのみを監視する必要があります。たとえば、RNFD は、ノードによって DODAG ルートへのリンクを介して送信されたパケットに対する複数の連続した L2 確認応答の欠如を観察した場合、DODAG ルートに問題がある可能性があると結論付けることができます。内部的には、ローカル CFRC に変更があるたびに RNFD がアクションを起こすことが推奨されます。これにより、ノードは、通常は一定期間 DODAG ルートとのリンク上でパケットを交換しない場合でも、潜在的な問題の検出に参加する機会を得ることができます。特に、RNFD は、ノードが最後に LORS を「UP」に設定してから、端数の値 (NegativeCFRC)/値 (PositiveCFRC) が少なくとも RNFD_SUSPICION_GROWTH_THRESHOLD だけ増加した場合、DODAG ルートに問題がある可能性があると結論付ける必要があります (SHOULD)。
Whenever, having its LORS set to "UP", RNFD concludes (based on either external or internal inputs) that there may be problems with the link with the DODAG root, it MUST set its LORS either to "SUSPECTED DOWN" or, as an optimization, to "LOCALLY DOWN".
LORS が「UP」に設定されている場合、RNFD は、DODAG ルートとのリンクに問題がある可能性があると (外部入力または内部入力に基づいて) 結論付けるたびに、LORS を「SUSPECTED DOWN」、または最適化として「LOCALLY DOWN」に設定しなければなりません。
The "SUSPECTED DOWN" value of LORS is temporary: its aim is to give RNFD an additional opportunity to verify whether the link with the DODAG root is indeed down. Depending on the outcome of such verification, RNFD MUST set its LORS to either "UP", if the link has been confirmed not to be down, or "LOCALLY DOWN", otherwise. The verification can be performed, for example, by transmitting RPL DIS or ICMPv6 Echo Request messages to the DODAG root's link-local IPv6 address and expecting replies confirming that the root is up and reachable through the link. Care should be taken not to overload the DODAG root with traffic due to simultaneous probes, for instance, random backoffs can be employed to this end. It is RECOMMENDED that the "SUSPECTED DOWN" value of LORS be attained and verification take place if RNFD's conclusion on the state of the DODAG root is based only on indirect observations, for example, the aforementioned growth of the CFRC values. In contrast, for direct observations, such as missing L2 acknowledgments, the verification MAY be skipped, with the node's LORS effectively changing from "UP" directly to "LOCALLY DOWN".
LORS の「SUSPECTED DOWN」値は一時的なものです。その目的は、RNFD に DODAG ルートとのリンクが実際にダウンしているかどうかを確認する追加の機会を与えることです。そのような検証の結果に応じて、RNFD はリンクがダウンしていないことが確認された場合は LORS を「UP」に設定し、そうでない場合は「LOCALLY DOWN」に設定しなければなりません。検証は、たとえば、RPL DIS または ICMPv6 Echo Request メッセージを DODAG ルートのリンクローカル IPv6 アドレスに送信し、ルートが稼働中でリンク経由で到達可能であることを確認する応答を期待することによって実行できます。同時プローブにより DODAG ルートにトラフィックが過負荷にならないように注意する必要があります。たとえば、この目的のためにランダム バックオフを使用できます。DODAG ルートの状態に関する RNFD の結論が間接的な観察、たとえば、前述の CFRC 値の増加のみに基づいている場合、LORS の「SUSPECTED DOWN」値に達し、検証が行われることが推奨されます。対照的に、L2 確認応答の欠落などの直接観察の場合、ノードの LORS が事実上「UP」から直接「LOCALLY DOWN」に変更されるため、検証がスキップされてもよい(MAY)。
For consistency with RPL, when detecting potential problems with the DODAG root, RNFD also must make use of RPL's independent knowledge. More specifically, a node MUST switch its LORS from "UP" or "SUSPECTED DOWN" directly to "LOCALLY DOWN" if a neighbor entry for the DODAG root is removed from RPL's DODAG parent set or the neighbor ceases to be considered reachable via its link-local IPv6 address.
RPL との一貫性を保つために、DODAG ルートの潜在的な問題を検出する場合、RNFD は RPL の独立した知識も利用する必要があります。より具体的には、DODAG ルートの隣接エントリが RPL の DODAG 親セットから削除された場合、または隣接ノードがそのリンクローカル IPv6 アドレス経由で到達可能であると見なされなくなった場合、ノードはその LORS を「UP」または「SUSPECTED DOWN」から「LOCALLY DOWN」に直接切り替えなければなりません (MUST)。
Finally, while having its LORS already equal to "LOCALLY DOWN", a node may make an observation confirming that its link with the DODAG root is actually up. In such a case, it SHOULD set its LORS back to "UP" but MUST NOT do this before conditions 2-4 in Section 5.1, which are necessary for a node to change its role from Acceptor to Sentinel, all hold.
最後に、LORS がすでに「LOCALLY DOWN」に等しい場合、ノードは、DODAG ルートとのリンクが実際にアップしていることを確認する観察を行うことができます。このような場合、LORS を「UP」に戻す必要があります (SHOULD) が、ノードがその役割をアクセプターからセンチネルに変更するために必要なセクション 5.1 の条件 2 ～ 4 がすべて成立する前にこれを行ってはなりません (MUST NOT)。
To appropriately account for the node's observations on the state of the DODAG root, the aforementioned LORS transitions are accompanied by changes to the node's local CFRCs as follows. Transitions between "UP" and "SUSPECTED DOWN" do not affect either of the two CFRCs. In contrast, during a switch from "UP" or "SUSPECTED DOWN" to "LOCALLY DOWN", the node MUST add itself to its NegativeCFRC, as explained previously. By symmetry, if there is a transition from "LOCALLY DOWN" to "UP", the node MUST add itself to its PositiveCFRC, as explained previously.
DODAG ルートの状態に関するノードの観察を適切に説明するために、前述の LORS 遷移には、次のようにノードのローカル CFRC への変更が伴います。「UP」と「SUSPECTED DOWN」の間の遷移は、2 つの CFRC のどちらにも影響しません。対照的に、「UP」または「SUSPECTED DOWN」から「LOCALLY DOWN」への切り替え中は、前に説明したように、ノードは自身を NegativeCFRC に追加しなければなりません (MUST)。対称性により、「LOCALLY DOWN」から「UP」への遷移がある場合、前に説明したように、ノードは自身を PositiveCFRC に追加しなければなりません (MUST)。
Such changes to a node's local CFRCs, if performed repeatedly due to incorrect decisions regarding the status of the node's link with the DODAG root, may lead to those CFRCs becoming saturated. An implementation should thus try to minimize false-positive transitions from "UP" and "SUSPECTED DOWN" to "LOCALLY DOWN". The exact approach depends on the specific solutions employed for assessing the state of a link. For instance, one can utilize additional mechanisms for increasing the confidence of individual decisions, such as during the aforementioned verification in the "SUSPECTED DOWN" state, or can limit the number of transitions per node, possibly in an adaptive fashion.
DODAG ルートとのノードのリンクのステータスに関する誤った決定により、ノードのローカル CFRC に対するこのような変更が繰り返し実行されると、それらの CFRC が飽和状態になる可能性があります。したがって、実装では、「UP」および「SUSPECTED DOWN」から「LOCALLY DOWN」への誤検知遷移を最小限に抑えるように努める必要があります。正確なアプローチは、リンクの状態を評価するために採用される特定のソリューションによって異なります。たとえば、前述の「SUSPECTED DOWN」状態での検証中など、個々の決定の信頼性を高めるための追加メカニズムを利用したり、場合によっては適応的な方法でノードごとの遷移数を制限したりできます。
Nodes disseminate their observations by exchanging CFRCs in the RNFD Options embedded in link-local RPL control messages, notably DIOs and DISs. When processing such a received option, a node (acting as a Sentinel or Acceptor) MUST update its PositiveCFRC and NegativeCFRC to newpc = merge(oldpc, recvpc) and newnc = merge(oldnc, recvnc), respectively. Here, oldpc and oldnc are the values of the node's PositiveCFRC and NegativeCFRC before the update, while recvpc and recvnc are the received values of option fields PosCFRC and NegCFRC, respectively.
ノードは、リンクローカル RPL 制御メッセージ (特に DIO と DIS) に埋め込まれた RNFD オプションの CFRC を交換することによって、観測結果を広めます。このような受信したオプションを処理するとき、ノード (センチネルまたはアクセプターとして機能する) は、その PositiveCFRC と NegativeCFRC をそれぞれ newpc = merge(oldpc, recvpc) と newnc = merge(oldnc, recvnc) に更新しなければなりません (MUST)。ここで、oldpc と oldnc は更新前のノードの PositiveCFRC と NegativeCFRC の値であり、recvpc と recvnc はそれぞれオプション フィールド PosCFRC と NegCFRC の受信値です。
In effect, the node's value of the fraction value(NegativeCFRC)/value(PositiveCFRC) may change. If the fraction reaches at least RNFD_CONSENSUS_THRESHOLD (with value(PositiveCFRC) being greater than zero), then the node consents on the DODAG root being down. Accordingly, it MUST change its LORS to "GLOBALLY DOWN" and set its PositiveCFRC and NegativeCFRC both to infinity().
実際には、ノードの分数値 (NegativeCFRC)/値 (PositiveCFRC) の値が変更される可能性があります。この割合が少なくとも RNFD_CONSENSUS_THRESHOLD (value(PositiveCFRC) がゼロより大きい場合) に達すると、ノードは DODAG ルートがダウンしていることに同意します。したがって、LORS を「GLOBALLY DOWN」に変更し、PositiveCFRC と NegativeCFRC の両方を infinity() に設定しなければなりません。
The "GLOBALLY DOWN" value of LORS is terminal; the node MUST NOT change it and MUST NOT modify its CFRCs until it joins a new DODAG Version. With this value of LORS, RNFD at the node MUST also prevent RPL from having any DODAG parent and advertising any Rank other than INFINITE_RANK.
LORS の「GLOBALLY DOWN」値は最終的なものです。ノードは新しい DODAG バージョンに参加するまで、それを変更してはならず、CFRC を変更してはなりません。LORS のこの値により、ノードの RNFD は、RPL が DODAG 親を持ち、INFINITE_RANK 以外のランクをアドバタイズすることも防止しなければなりません (MUST)。
Since the RNFD Option is embedded, among others, in RPL DIO control messages, updates to a node's CFRCs may affect the sending schedule of these messages, which is driven by the DIO Trickle timer [RFC6206]. It is RECOMMENDED to use a dedicated Trickle timer for RNFD that is different from RPL's original DIO Trickle timer. In such a setting, whenever the dedicated timer fires and no DIO message containing the RNFD Option has been sent to the link-local all-RPL-nodes multicast IPv6 address since the previous firing, the node sends a DIO message containing the RNFD Option to the address. The minimal and maximal interval sizes of the dedicated timer SHOULD NOT be smaller than those of RPL's original DIO Trickle timer. In contrast, in the absence of the dedicated Trickle timer for RNFD, an implementation SHOULD ensure that the RNFD Option is present in multicast DIO messages sufficiently often to quickly propagate changes to the node's CFRCs and, notably, as soon as possible after a reset of the timer triggered by RNFD. In the remainder of this document, we will refer to the Trickle timer utilized by RNFD (either the dedicated one or RPL's original one, depending on the implementation) simply as "Trickle timer". In particular, a node MUST reset its Trickle timer when it changes its LORS to "GLOBALLY DOWN", so that information about the detected crash of the DODAG root is disseminated in the DODAG fast. Likewise, a node SHOULD reset its Trickle timer when any of its local CFRCs change significantly.
RNFD オプションは特に RPL DIO 制御メッセージに埋め込まれているため、ノードの CFRC の更新は、DIO Trickle タイマー [RFC6206] によって駆動されるこれらのメッセージの送信スケジュールに影響を与える可能性があります。RPL のオリジナルの DIO トリクル タイマーとは異なる、RNFD 専用のトリクル タイマーを使用することをお勧めします。このような設定では、専用タイマーが起動し、前回の起動以降、RNFD オプションを含む DIO メッセージがリンクローカルの全 RPL ノードのマルチキャスト IPv6 アドレスに送信されていない場合、ノードは RNFD オプションを含む DIO メッセージをそのアドレスに送信します。専用タイマーの最小間隔サイズと最大間隔サイズは、RPL のオリジナルの DIO Trickle タイマーの間隔サイズより小さくてはいけません (SHOULD NOT)。対照的に、RNFD 専用の Trickle タイマーが存在しない場合、実装では、変更をノードの CFRC に迅速に伝播するのに十分な頻度で、特に RNFD によってトリガーされたタイマーのリセット後できるだけ早く、RNFD オプションがマルチキャスト DIO メッセージに存在することを保証する必要があります (SHOULD)。このドキュメントの残りの部分では、RNFD によって利用されるトリクル タイマー (実装に応じて、専用のものまたは RPL のオリジナルのもの) を単に「トリクル タイマー」と呼びます。特に、ノードは LORS を「GLOBALLY DOWN」に変更するときにトリクル タイマーをリセットし、DODAG ルートの検出されたクラッシュに関する情報が DODAG ファストで広められるようにしなければなりません。同様に、ノードは、ローカル CFRC のいずれかが大幅に変化したときに、その Trickle タイマーをリセットする必要があります (SHOULD)。
The DODAG root node MUST assume the role of Acceptor in RNFD and MUST NOT ever switch this role. It MUST also monitor its LORS and local CFRCs, so that it can react to various events.
DODAG ルート ノードは、RNFD でのアクセプターの役割を引き受けなければならず、この役割を決して切り替えてはなりません。また、さまざまなイベントに対応できるように、LORS とローカル CFRC を監視しなければなりません。
To start with, the DODAG root MUST generate a new DODAG Version, thereby restarting the protocol, if it changes its LORS to "GLOBALLY DOWN", which may happen when the root has restarted after a crash or the nodes have falsely detected its crash. It MAY also generate a new DODAG Version if the fraction value(NegativeCFRC)/value(PositiveCFRC) approaches RNFD_CONSENSUS_THRESHOLD, so as to avoid potential interruptions to routing.
まず、DODAG ルートは、LORS を「GLOBALLY DOWN」に変更する場合、新しい DODAG バージョンを生成し、それによってプロトコルを再起動しなければなりません。これは、ルートがクラッシュ後に再起動した場合、またはノードがクラッシュを誤って検出した場合に発生する可能性があります。また、ルーティングの潜在的な中断を避けるために、小数値 (NegativeCFRC)/値 (PositiveCFRC) が RNFD_CONSENSUS_THRESHOLD に近づいた場合、新しい DODAG バージョンを生成してもよい (MAY)。
Furthermore, the DODAG root SHOULD either generate a new DODAG Version or increase the bit length of its CFRCs if saturated(PositiveCFRC) becomes TRUE. This is a self-regulation mechanism that helps adjust the CFRCs to a potentially large number of Sentinels (see Section 6.1).
さらに、DODAG ルートは、saturated(PositiveCFRC) が TRUE になった場合、新しい DODAG バージョンを生成するか、その CFRC のビット長を増やす必要があります (SHOULD)。これは、潜在的に多数のセンチネルに合わせて CFRC を調整するのに役立つ自己調整メカニズムです (セクション 6.1 を参照)。
In general, issuing a new DODAG Version effectively restarts RNFD. Thus, the DODAG root MAY also perform this operation in other situations.
一般に、新しい DODAG バージョンを発行すると、実質的に RNFD が再起動されます。したがって、DODAG ルートは他の状況でもこの操作を実行してもよい(MAY)。
RNFD can be activated and deactivated on demand, once per DODAG Version. The particular policies for activating and deactivating the protocol are outside the scope of this document. However, the activation and deactivation MUST be done at the DODAG root node; other nodes MUST comply.
RNFD は、DODAG バージョンごとに 1 回、オンデマンドでアクティブ化および非アクティブ化できます。プロトコルをアクティブ化および非アクティブ化するための特定のポリシーは、このドキュメントの範囲外です。ただし、アクティブ化と非アクティブ化は DODAG ルート ノードで行う必要があります。他のノードも従わなければなりません。
More specifically, when a non-root node joins a DODAG Version, RNFD at the node is initially inactive. The node MUST NOT activate the protocol unless it receives for this DODAG Version a valid RNFD Option containing some CFRCs, that is, having its Option Length field positive. In particular, if the option accompanies the message that causes the node to join the DODAG Version, the protocol MUST be active from the moment of the joining. RNFD then remains active at the node until it is explicitly deactivated or the node joins a new DODAG Version. An explicit deactivation MUST take place when the node receives an RNFD Option for the DODAG Version with no CFRCs, that is, having its Option Length field equal to zero. When explicitly deactivated, RNFD MUST NOT be reactivated unless the node joins a new DODAG Version. In particular, when the first RNFD Option received by the node has its Option Length field equal to zero, the protocol MUST remain deactivated for the entire time the node belongs to the current DODAG Version.
より具体的には、非ルート ノードが DODAG バージョンに参加すると、ノードの RNFD は最初は非アクティブになります。ノードは、この DODAG バージョンに対して、いくつかの CFRC を含む有効な RNFD オプション、つまり、オプション長フィールドが正のものを受信しない限り、プロトコルをアクティブにしてはなりません (MUST NOT)。特に、オプションがノードを DODAG バージョンに参加させるメッセージを伴う場合、プロトコルは参加の瞬間からアクティブでなければなりません (MUST)。RNFD は、明示的に非アクティブ化されるか、ノードが新しい DODAG バージョンに参加するまで、ノードでアクティブなままになります。ノードが CFRC のない DODAG バージョンの RNFD オプションを受信したとき、つまりオプション長フィールドがゼロに等しいとき、明示的な非アクティブ化が行われなければなりません (MUST)。明示的に非アクティブ化された場合、ノードが新しい DODAG バージョンに参加しない限り、RNFD を再アクティブ化してはなりません (MUST NOT)。特に、ノードが受信した最初の RNFD オプションのオプション長フィールドが 0 に等しい場合、そのノードが現在の DODAG バージョンに属している間、プロトコルは非アクティブのままでなければなりません (MUST)。
When RNFD at a node is initially inactive for a DODAG Version, the node MUST NOT attach any RNFD Option to the messages it sends (in particular, because it may not know the desired CFRC length; see Section 5.6). When the protocol has been explicitly deactivated, the node MAY also decide not to attach the option to its outgoing messages. However, it is RECOMMENDED that it send a sufficient number of messages with the option to the link-local all-RPL-nodes multicast IPv6 address to allow its neighbors to learn that RNFD has been deactivated in the current DODAG Version. In particular, it MAY reset its Trickle timer to this end but MAY also use some reactive mechanisms. For example, it might reply with a unicast DIO or DIS containing the RNFD Option with no CFRCs to a message from a neighbor that contains the option with some CFRCs, as such a neighbor appears not to have learned about the deactivation of RNFD.
ノードの RNFD が最初に DODAG バージョンに対して非アクティブである場合、ノードは送信するメッセージに RNFD オプションを付加してはなりません (特に、必要な CFRC 長がわからない可能性があるため、セクション 5.6 を参照)。プロトコルが明示的に非アクティブ化されている場合、ノードは発信メッセージにオプションを付加しないことを決定してもよい(MAY)。ただし、現在の DODAG バージョンで RNFD が非アクティブ化されていることを近隣のルータが認識できるように、リンク ローカルの全 RPL ノードのマルチキャスト IPv6 アドレスにオプション付きで十分な数のメッセージを送信することが推奨されます。特に、この目的のために Trickle タイマーをリセットしてもよい (MAY) が、いくつかの反応メカニズムを使用してもよい (MAY)。たとえば、一部の CFRC を含むオプションを含むネイバーからのメッセージに対して、CFRC を含まない RNFD オプションを含むユニキャスト DIO または DIS で応答する可能性があります。これは、そのようなネイバーが RNFD の非アクティブ化について学習していないように見えるためです。
The merge() and compare() operations on CFRCs require both arguments to be compatible, that is, to have the same bit length. However, the processing rules for the RNFD Option (see Section 4.2) do not necessitate this. This fact is made use of not only in the mechanisms for activating and deactivating the protocol (see Section 5.5), but also in mechanisms for dynamic adjustments of CFRCs, which aim to enable deployment-specific policies (see Section 6.1). A node thus must be prepared to receive the RNFD Option with fields PosCFRC and NegCFRC of a different bit length than the node's own PositiveCFRC and NegativeCFRC. Assuming that it has RNFD active and that fields PosCFRC and NegCFRC in the option have a positive length, the node MUST react as follows.
CFRC の merge() および Compare() 操作では、両方の引数に互換性があること、つまり同じビット長であることが必要です。ただし、RNFD オプションの処理規則 (セクション 4.2 を参照) ではこれは必要ありません。この事実は、プロトコルをアクティブ化および非アクティブ化するメカニズム (セクション 5.5 を参照) だけでなく、展開固有のポリシーを有効にすることを目的とした CFRC の動的調整のメカニズム (セクション 6.1 を参照) でも利用されます。したがって、ノードは、ノード自身の PositiveCFRC および NegativeCFRC とは異なるビット長のフィールド PosCFRC および NegCFRC を含む RNFD オプションを受信できるように準備する必要があります。RNFD がアクティブであり、オプションの PosCFRC フィールドと NegCFRC フィールドが正の長さを持っていると仮定すると、ノードは次のように反応しなければなりません (MUST)。
If the bit length of fields PosCFRC and NegCFRC is the same as that of the node's local PositiveCFRC and NegativeCFRC, then the node MUST perform the merges, as detailed previously (see Section 5.3).
フィールド PosCFRC および NegCFRC のビット長がノードのローカル PositiveCFRC および NegativeCFRC のビット長と同じである場合、ノードは以前に詳述したようにマージを実行しなければなりません (セクション 5.3 を参照)。
If the bit length of fields PosCFRC and NegCFRC is smaller than that of the node's local PositiveCFRC and NegativeCFRC, then the node MUST ignore the option and MAY reset its Trickle timer.
フィールド PosCFRC および NegCFRC のビット長がノードのローカル PositiveCFRC および NegativeCFRC のビット長より小さい場合、ノードはオプションを無視しなければならず (MUST)、トリクル タイマーをリセットしてもよい (MAY)。
If the bit length of fields PosCFRC and NegCFRC is greater than that of the node's local PositiveCFRC and NegativeCFRC, then the node MUST extend the bit length of its local CFRCs to be equal to that in the option and set the CFRCs as follows:
フィールド PosCFRC および NegCFRC のビット長がノードのローカル PositiveCFRC および NegativeCFRC のビット長より大きい場合、ノードはローカル CFRC のビット長をオプションのビット長と等しくなるように拡張し、CFRC を次のように設定しなければなりません。
* If the node's LORS is "GLOBALLY DOWN", then both of its local CFRCs MUST be set to infinity().
* ノードの LORS が「GLOBALLY DOWN」の場合、そのローカル CFRC の両方を infinity() に設定しなければなりません。
* Otherwise, they both MUST be set to zero(), and the node MUST account for itself in so initialized CFRCs. More specifically, if the node is a Sentinel, then it MUST add itself to its PositiveCFRC, as detailed previously. In addition, if its LORS is "LOCALLY DOWN", then it MUST also add itself to its NegativeCFRC, as explained previously. Finally, the node MUST perform merges of its local CFRCs and the ones received in the option (see Section 5.3) and MAY reset its Trickle timer.
* それ以外の場合、それらは両方とも zero() に設定されなければならず、ノードはそのように初期化された CFRC 内でそれ自体を考慮しなければなりません。より具体的には、ノードが Sentinel の場合、前に説明したように、ノード自体を PositiveCFRC に追加しなければなりません (MUST)。さらに、LORS が「LOCALLY DOWN」の場合は、前に説明したように、自身を NegativeCFRC に追加しなければなりません。最後に、ノードはローカル CFRC とオプション (セクション 5.3 を参照) で受信した CFRC のマージを実行しなければならず (MUST)、トリクル タイマーをリセットしてもよい (MAY)。
In contrast, if the node is unable to extend its local CFRCs, for example, because it lacks resources, then it MUST stop participating in RNFD. That is, until it joins a new DODAG Version, it MUST NOT send the RNFD Option and MUST ignore this option in received messages.
対照的に、ノードがリソース不足などの理由でローカル CFRC を拡張できない場合は、RNFD への参加を停止しなければなりません。つまり、新しい DODAG バージョンに参加するまで、RNFD オプションを送信してはならず、受信メッセージ内のこのオプションを無視しなければなりません (MUST)。
A DODAG root node can be requested to increase the bit length of its CFRCs externally, as part of the management policies (see Section 6.1). If it cannot fulfill such a request, then it MUST NOT stop participating in RNFD and SHOULD return an error to the requester instead. Otherwise, since it is always an Acceptor, the above rules require it to extend both CFRCs to the requested length and to set them both to either zero() or infinity(), depending on whether its LORS is different from or equal to "GLOBALLY DOWN", respectively. In the latter case, given the earlier rules governing the root's behavior upon reaching the "GLOBALLY DOWN" state (cf. Section 5.4), the root is also bound to eventually set its CFRCs to zero() and, in addition, generate a new DODAG Version and change its LORS back to "UP". Therefore, these two steps can be optimized into one, meaning that effectively, irrespective of its LORS, when increasing the bit length of its CFRCs in response to an external request, the root also sets the CFRCs to zero().
DODAG ルート ノードは、管理ポリシーの一環として、外部から CFRC のビット長を増やすように要求できます (セクション 6.1 を参照)。そのような要求を満たすことができない場合、RNFD への参加を停止してはならず、代わりに要求者にエラーを返す必要があります (SHOULD)。それ以外の場合、常にアクセプターであるため、上記のルールでは、両方の CFRC を要求された長さまで拡張し、LORS が「GLOBALLY DOWN」と異なるか等しいかに応じて両方を zero() または infinity() に設定する必要があります。後者の場合、「GLOBALLY DOWN」状態に達したときのルートの動作を管理する以前のルール (セクション 5.4 を参照) を考慮すると、ルートは最終的に CFRC を zero() に設定し、さらに新しい DODAG バージョンを生成して LORS を「UP」に戻すことになります。したがって、これらの 2 つのステップは 1 つに最適化できます。つまり、LORS に関係なく、外部要求に応じて CFRC のビット長を増やすときに、ルートは CFRC を zero() に設定することになります。
In summary, RNFD interacts with RPL in the following manner:
要約すると、RNFD は次の方法で RPL と対話します。
* While having its LORS equal to "GLOBALLY DOWN", RNFD prevents RPL from routing packets and advertising upward routes in the corresponding DODAG (see Section 5.3).
* LORS を「GLOBALLY DOWN」に設定している間、RNFD は、RPL がパケットをルーティングし、対応する DODAG 内で上向きルートをアドバタイズすることを防ぎます (セクション 5.3 を参照)。
* In some scenarios, RNFD triggers RPL to issue a new DODAG Version (see Section 5.4).
* 一部のシナリオでは、RNFD が RPL をトリガーして新しい DODAG バージョンを発行します (セクション 5.4 を参照)。
* Depending on the implementation, RNFD may cause RPL's DIO Trickle timer resets (see Sections 5.3, 5.5, and 5.6).
* 実装によっては、RNFD が RPL の DIO Trickle タイマー リセットを引き起こす可能性があります (セクション 5.3、5.5、および 5.6 を参照)。
* RNFD monitors events relevant to routing adjacency maintenance as well as those affecting RPL's DODAG parent set (see Sections 5.1 and 5.2).
* RNFD は、ルーティング隣接関係の維持に関連するイベントと、RPL の DODAG 親セットに影響を与えるイベントを監視します (セクション 5.1 および 5.2 を参照)。
* Using RNFD entails embedding the RNFD Option into link-local RPL control messages (see Section 4.2).
* RNFD を使用するには、RNFD オプションをリンクローカル RPL 制御メッセージに埋め込む必要があります (セクション 4.2 を参照)。
The following is a summary of RNFD's constants:
以下は RNFD の定数の概要です。
RNFD_CONSENSUS_THRESHOLD:
RNFD_CONSENSUS_THRESHOLD:
A threshold concerning the value of the fraction value(NegativeCFRC)/value(PositiveCFRC). If the value at a Sentinel or Acceptor node reaches the threshold, then the node's LORS is set to "GLOBALLY DOWN", which implies that consensus has been reached on the DODAG root node being down (see Section 5.3). The default value of the threshold is 0.51, which indicates that a majority of Sentinels must consider the root to be down to reach the consensus. In general, when the value is higher, the detection period is longer, but the risk of false positives is lower.
端数値(NegativeCFRC)/値(PositiveCFRC)の値に関する閾値。Sentinel または Acceptor ノードの値がしきい値に達すると、ノードの LORS は「GLOBALLY DOWN」に設定されます。これは、DODAG ルート ノードがダウンしていることについて合意が得られたことを意味します (セクション 5.3 を参照)。しきい値のデフォルト値は 0.51 で、これは、コンセンサスに達するには、大多数の Sentinel がルートがダウンしていると見なす必要があることを示します。一般に、値が高いほど検出期間は長くなりますが、誤検知のリスクは低くなります。
RNFD_SUSPICION_GROWTH_THRESHOLD:
RNFD_SUSPICION_GROWTH_THRESHOLD:
A threshold concerning the value of the fraction value(NegativeCFRC)/value(PositiveCFRC). If the value at a Sentinel node grows at least by this threshold since the time the node's LORS was last set to "UP", then the node's LORS is set to "SUSPECTED DOWN" or "LOCALLY DOWN", which implies that the node starts suspecting or assumes a crash of the DODAG root (see Section 5.2). When the value is higher, the duration of detecting true crashes is longer, but the risk of increased traffic due to verifying false suspicions is lower. The default value of the threshold is 0.12, which in sparse networks (up to 8 neighbors per node) triggers a suspicion at a Sentinel node after just one other Sentinel starts considering the root as dead, while being gradually more conservative in denser networks.
端数値(NegativeCFRC)/値(PositiveCFRC)の値に関する閾値。ノードの LORS が最後に「UP」に設定されてから、Sentinel ノードの値が少なくともこのしきい値だけ増加した場合、ノードの LORS は「SUSPECTED DOWN」または「LOCALLY DOWN」に設定されます。これは、ノードが DODAG ルートのクラッシュを疑うか、または想定し始めることを意味します (セクション 5.2 を参照)。値が大きいほど、本当のクラッシュを検出するまでの時間は長くなりますが、誤った疑いの検証によってトラフィックが増加するリスクは低くなります。しきい値のデフォルト値は 0.12 で、疎なネットワーク (ノードごとに最大 8 つの隣接ノード) では、他の 1 つの Sentinel がルートをデッドとみなし始めると、Sentinel ノードで疑わしい値がトリガーされますが、高密度のネットワークでは徐々に保守的になります。
RNFD_CFRC_SATURATION_THRESHOLD:
RNFD_CFRC_SATURATION_THRESHOLD:
A threshold concerning the percentage of bits set to 1 in a CFRC, c. If the percentage for c is equal to or greater than this threshold, then saturated(c) returns TRUE, which hints the DODAG root to generate a new DODAG Version or increase the bit length of the CFRCs (see Section 5.4). The default value of the threshold is 0.63. When the value is higher, the probability of bit collisions is higher, and the results of function value(c) may thus be more erratic.
ＣＦＲＣにおいて１に設定されるビットのパーセンテージに関する閾値、 ｃ．c のパーセンテージがこのしきい値以上の場合、saturated(c) は TRUE を返し、DODAG ルートに新しい DODAG バージョンを生成するか、CFRC のビット長を増やすよう示唆します (セクション 5.4 を参照)。しきい値のデフォルト値は 0.63 です。値が大きいほど、ビット衝突の確率が高くなるため、関数 value(c) の結果がより不安定になる可能性があります。
The means of configuring the constants at individual nodes are outside the scope of this document.
個々のノードで定数を設定する方法は、このドキュメントの範囲外です。
RNFD is largely self-managed, with the exception of protocol activation and deactivation, as well as node role assignment and the related CFRC size adjustment, for which only the aforementioned mechanisms are defined, so as to enable adopting deployment-specific policies. This section discusses the manageability issues.
RNFD は、プロトコルのアクティブ化と非アクティブ化、ノードの役割の割り当て、および関連する CFRC サイズの調整を除いて、大部分が自己管理されます。これらについては、展開固有のポリシーの採用を可能にするために、前述のメカニズムのみが定義されています。このセクションでは、管理性の問題について説明します。
One approach to node role and CFRC size selection is to manually designate specific nodes as Sentinels in RNFD, assuming that they will have chances to satisfy the necessary conditions for attaining this role (see Section 5.1), and to fix the CFRC bit length to accommodate these nodes.
ノードの役割と CFRC サイズの選択に対する 1 つのアプローチは、特定のノードがこの役割を達成するために必要な条件を満たす機会があると仮定して (セクション 5.1 を参照)、特定のノードを RNFD のセンチネルとして手動で指定し、これらのノードに対応するために CFRC ビット長を固定することです。
Another approach is to automate the selection process. In principle, any node satisfying the necessary conditions for becoming a Sentinel (see Section 5.1) can attain this role. However, in networks where the DODAG root node has many neighbors, this approach may lead to saturated(PositiveCFRC) quickly becoming TRUE, which may degrade RNFD's performance without additional measures. This issue can be handled with a probabilistic solution: if PositiveCFRC becomes saturated with little or no increase in NegativeCFRC, then a new DODAG Version can be issued, and a node satisfying the necessary conditions can become a Sentinel in this version only with probability 1/2. This process can be continued with the probability being halved in each new DODAG Version until PositiveCFRC is no longer quickly saturated. Another solution is to increase, potentially multiple times, the bit length of the CFRCs by the DODAG root if PositiveCFRC becomes saturated with little or no growth in NegativeCFRC. This does not require issuing a new DODAG Version but lengthens the RNFD Option. In this way, a sufficient bit length can be dynamically discovered, or the root can conclude that a given bit length is excessive for (some) nodes and resort to the previous solution. Increasing the bit length can be done, for instance, by doubling it, respecting the condition that it has to be a prime number (see Section 4.2).
もう 1 つのアプローチは、選択プロセスを自動化することです。原則として、センチネルになるために必要な条件 (セクション 5.1 を参照) を満たすノードは、この役割を達成できます。ただし、DODAG ルート ノードに多くの隣接ノードがあるネットワークでは、このアプローチでは飽和(PositiveCFRC) がすぐに TRUE になり、追加の対策がなければ RNFD のパフォーマンスが低下する可能性があります。この問題は確率論的な解決策で処理できます。つまり、NegativeCFRC がほとんどまたはまったく増加せずに PositiveCFRC が飽和状態になった場合、新しい DODAG バージョンを発行することができ、必要な条件を満たすノードはこのバージョンで確率 1/2 でのみ Sentinel になることができます。このプロセスは、PositiveCFRC が急速に飽和しなくなるまで、新しい DODAG バージョンごとに確率を半分にして継続できます。もう 1 つの解決策は、PositiveCFRC が飽和し、NegativeCFRC がほとんどまたはまったく増加しない場合に、DODAG ルートによって CFRC のビット長をおそらく複数倍に増やすことです。これには新しい DODAG バージョンを発行する必要はありませんが、RNFD オプションが長くなります。このようにして、十分なビット長を動的に見つけることができます。あるいは、ルートは、特定のビット長が (一部の) ノードにとって過剰であると結論付け、前の解決策に頼ることもできます。ビット長を増やすには、たとえば、ビット長が素数である必要があるという条件を考慮してビット長を 2 倍にすることができます (セクション 4.2 を参照)。
In either of the solutions, Sentinel nodes should preferably be stable themselves and have stable links to the DODAG root. Otherwise, they may often exhibit LORS transitions between "UP" and "LOCALLY DOWN" or switches between Acceptor and Sentinel roles, which gradually saturates CFRCs. As a mitigation, the number of such transitions and switches per node MAY be limited; however, having Sentinels be stable SHOULD be preferred.
どちらのソリューションでも、Sentinel ノード自体が安定しており、DODAG ルートへの安定したリンクを持つことが望ましいです。それ以外の場合は、「UP」と「LOCALLY DOWN」の間で LORS 遷移が発生したり、アクセプターとセンチネルの役割が切り替わったりすることが多く、これにより CFRC が徐々に飽和状態になります。緩和策として、ノードごとのそのような遷移とスイッチの数を制限してもよい(MAY)。ただし、Sentinel を安定させることが好ましいはずです。
RPL allows a DODAG to have a so-called "virtual root", that is, a collection of nodes coordinating to act as a single root of the DODAG. The details of the coordination process are left open in [RFC6550], but from RNFD's perspective, two possible realizations are worth consideration:
RPL を使用すると、DODAG はいわゆる「仮想ルート」、つまり、DODAG の単一のルートとして機能するように調整するノードの集合を持つことができます。調整プロセスの詳細は [RFC6550] で未公開のままですが、RNFD の観点からは、次の 2 つの実現可能性を検討する価値があります。
* Just a single (primary) node of the nodes comprising the virtual root acts as the actual root of the DODAG. Only when this node fails does another (backup) node take over. As a result, at any time, at most one of the nodes comprising the virtual root is the actual root.
* 仮想ルートを構成するノードのうちの 1 つの (プライマリ) ノードだけが、DODAG の実際のルートとして機能します。このノードに障害が発生した場合にのみ、別の (バックアップ) ノードが引き継ぎます。その結果、いつでも、仮想ルートを構成するノードのうち最大 1 つが実際のルートになります。
* More than one of the nodes comprising the virtual root act as actual roots of the DODAG, all advertising the same Rank in the DODAG. When some of the nodes fail, the other nodes may or may not react in any specific way. In other words, at any time, more than one node can be the actual root.
* 仮想ルートを構成する複数のノードが DODAG の実際のルートとして機能し、すべて DODAG 内の同じランクをアドバタイズします。一部のノードに障害が発生した場合、他のノードは特定の方法で反応する場合もあれば、反応しない場合もあります。言い換えれば、いつでも複数のノードが実際のルートになる可能性があります。
In the first realization, RNFD's operation is largely unaffected. The necessary conditions for a node to become a Sentinel (Section 5.1) guarantee that only the current primary root node is monitored by the protocol. This SHOULD be taken into account in the policies for node role assignment, CFRC size selection, and, possibly, the setting of the three thresholds (Section 5.8). Moreover, when a new primary has been elected, a new DODAG Version MUST be issued to avoid polluting CFRCs with observations on the previous primary.
最初の実現では、RNFD の動作はほとんど影響を受けません。ノードが Sentinel になるための必要条件 (セクション 5.1) により、現在のプライマリ ルート ノードのみがプロトコルによって監視されることが保証されます。これは、ノードの役割の割り当て、CFRC サイズの選択、および場合によっては 3 つのしきい値の設定 (セクション 5.8) のポリシーで考慮されるべきです (SHOULD)。さらに、新しい予備選挙が選出された場合、以前の予備選挙に関する観察結果によって CFRC が汚染されるのを避けるために、新しい DODAG バージョンを発行しなければなりません (MUST)。
In the second realization, the fact that the virtual root consists of multiple nodes is transparent to RNFD. Therefore, employing RNFD in such a setting can be beneficial only if the nodes comprising the virtual root may suffer from correlated crashes, for instance, due to global power outages.
2 番目の実現では、仮想ルートが複数のノードで構成されているという事実は、RNFD に対して透過的です。したがって、このような設定で RNFD を採用することは、仮想ルートを構成するノードが、たとえば世界規模の停電によって相関クラッシュに見舞われる可能性がある場合にのみ有益となり得ます。
For monitoring the operation of RNFD, its implementation SHOULD provide the following information about a node:
RNFD の動作を監視するために、その実装はノードに関する次の情報を提供する必要があります (SHOULD)。
* whether the protocol is active, and
* プロトコルがアクティブかどうか、および
* whether LORS is "GLOBALLY DOWN".
* LORS が「世界的にダウン」しているかどうか。
This information MUST be accompanied by the monitoring parameters defined by RPL [RFC6550], including at least the DODAG Version Number and the Rank. To offer even finer-grained visibility into RNFD's state at the node, the implementation MAY also provide:
この情報には、少なくとも DODAG バージョン番号とランクを含む、RPL [RFC6550] で定義された監視パラメータが伴わなければなりません (MUST)。ノードでの RNFD の状態に対するさらにきめ細かい可視性を提供するために、実装は以下を提供してもよい (MAY)。
* the assigned role (i.e., Sentinel or Acceptor),
* 割り当てられた役割 (つまり、センチネルまたはアクセプター)、
* the exact value of LORS (i.e., "UP", "SUSPECTED DOWN", "LOCALLY DOWN", or "GLOBALLY DOWN"),
* LORS の正確な値 (つまり、「UP」、「SUSPECTED DOWN」、「LOCALLY DOWN」、または「GLOBALLY DOWN」)、
* the two CFRCs (i.e., PositiveCFRC and NegativeCFRC), and
* 2 つの CFRC (つまり、ポジティブ CFRC とネガティブ CFRC)、および
* the constants listed in Section 5.8.
* セクション 5.8 にリストされている定数。
RNFD is an extension to RPL and thus is vulnerable to and benefits from the security issues and solutions described in [RFC6550] and [RFC7416]. Its specification in this document does not introduce new traffic patterns or new messages, for which specific mitigation techniques would be required beyond what can already be adopted for RPL.
RNFD は RPL の拡張であるため、[RFC6550] および [RFC7416] で説明されているセキュリティ問題と解決策に対して脆弱ですが、その恩恵を受けます。このドキュメントの仕様では、RPL に既に採用されているものを超えた特定の緩和手法が必要となる新しいトラフィック パターンや新しいメッセージは導入されていません。
In particular, RNFD depends on information exchanged in the RNFD Option. If the contents of this option were compromised, then failure misdetection may occur. One possibility is that the DODAG root may be falsely detected as crashed, which would result in an inability of the nodes to route packets, at least until a new DODAG Version is issued by the root. Another possibility is that a crash of the DODAG root may not be detected by RNFD, in which case RPL would have to rely on its own mechanisms. Moreover, compromising the contents of the RNFD Option may also lead to increased DIO traffic due to Trickle timer resets. Consequently, RNFD deployments are RECOMMENDED to use RPL security mechanisms if there is a risk that control information might be modified or spoofed.
特に、RNFD は RNFD オプションで交換される情報に依存します。このオプションの内容が侵害された場合、障害の誤検出が発生する可能性があります。可能性の 1 つは、DODAG ルートがクラッシュしていると誤って検出される可能性であり、その結果、少なくともルートによって新しい DODAG バージョンが発行されるまで、ノードはパケットをルーティングできなくなります。もう 1 つの可能性としては、DODAG ルートのクラッシュが RNFD によって検出されない可能性があり、その場合、RPL は独自のメカニズムに依存する必要があります。さらに、RNFD オプションの内容が侵害されると、トリクル タイマーのリセットにより DIO トラフィックが増加する可能性もあります。したがって、制御情報が変更またはなりすましされるリスクがある場合、RNFD 導入では RPL セキュリティ メカニズムを使用することが推奨されます。
In this context, two features of RNFD are worth highlighting. First, unless all neighbors of a DODAG root are compromised, a false positive can always be detected by the root based on its local CFRCs. If the frequency of such false positives becomes problematic, RNFD can be disabled altogether, for instance, until the problem has been diagnosed. This procedure can be largely automated at LBRs. Second, some types of false negatives can also be detected this way. Those that do pass undetected are likely not to have major negative consequences on RPL apart from the lack of improvement to its performance upon a DODAG root's crash, at least if RPL's other components are not attacked as well.
これに関連して、RNFD の 2 つの機能は強調する価値があります。まず、DODAG ルートの近隣すべてが侵害されない限り、ルートはローカル CFRC に基づいて誤検知を常に検出できます。このような誤検知の頻度が問題になる場合は、たとえば、問題が診断されるまで RNFD を完全に無効にすることができます。この手順は、LBR で大部分が自動化できます。第 2 に、一部のタイプの偽陰性もこの方法で検出できます。検出されずに通過するコンポーネントは、少なくとも RPL の他のコンポーネントが同様に攻撃されない限り、DODAG ルートのクラッシュ時にパフォーマンスが改善されないことを除けば、RPL に大きな悪影響を与えることはないと考えられます。
IANA has allocated the following value in the "RPL Control Message Options" registry within the "Routing Protocol for Low Power and Lossy Networks (RPL)" registry group (https://www.iana.org/assignments/rpl).
IANA は、「Routing Protocol for Low Power and Lossy Networks (RPL)」レジストリ グループ (https://www.iana.org/assignments/rpl) 内の「RPL Control Message Options」レジストリに次の値を割り当てました。
+=======+=============+===========+
| Value | Meaning | Reference |
+=======+=============+===========+
| 0x0E | RNFD Option | RFC 9866 |
+-------+-------------+-----------+
Table 1
[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>.
[RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low-
Power and Lossy Networks (RPL) Option for Carrying RPL
Information in Data-Plane Datagrams", RFC 6553,
DOI 10.17487/RFC6553, March 2012,
<https://www.rfc-editor.org/info/rfc6553>.
[RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6
Routing Header for Source Routes with the Routing Protocol
for Low-Power and Lossy Networks (RPL)", RFC 6554,
DOI 10.17487/RFC6554, March 2012,
<https://www.rfc-editor.org/info/rfc6554>.
[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>.
[Ciolkosz19]
Ciolkosz, P., "Integration of the RNFD Algorithm for
Border Router Failure Detection with the RPL Standard for
Routing IPv6 Packets", Master's Thesis, University of
Warsaw, 2019.
[Iwanicki16]
Iwanicki, K., "RNFD: Routing-Layer Detection of DODAG
(Root) Node Failures in Low-Power Wireless Networks", 2016
15th ACM/IEEE International Conference on Information
Processing in Sensor Networks (IPSN), pp. 1-12,
DOI 10.1109/IPSN.2016.7460720, 2016,
<https://doi.org/10.1109/IPSN.2016.7460720>.
[Paszkowska19]
Paszkowska, A. and K. Iwanicki, "Failure Handling in RPL
Implementations: An Experimental Qualitative Study",
Mission-Oriented Sensor Networks and Systems: Art and
Science, Springer International Publishing, pp. 49-95,
DOI 10.1007/978-3-319-91146-5_3, 2019,
<https://doi.org/10.1007/978-3-319-91146-5_3>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>.
[RFC5184] Teraoka, F., Gogo, K., Mitsuya, K., Shibui, R., and K.
Mitani, "Unified Layer 2 (L2) Abstractions for Layer 3
(L3)-Driven Fast Handover", RFC 5184,
DOI 10.17487/RFC5184, May 2008,
<https://www.rfc-editor.org/info/rfc5184>.
[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and
Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January
2014, <https://www.rfc-editor.org/info/rfc7102>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014,
<https://www.rfc-editor.org/info/rfc7228>.
[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>.
[Whang90] Whang, K.-Y., Vander-Zanden, B.T., and H.M. Taylor, "A
Linear-time Probabilistic Counting Algorithm for Database
Applications", ACM Transactions on Database Systems
(TODS), vol. 15, no. 2, pp. 208-229,
DOI 10.1145/78922.78925, 1990,
<https://doi.org/10.1145/78922.78925>.
The author would like to acknowledge Piotr Ciolkosz and Agnieszka Paszkowska. Agnieszka contributed to deeper understanding and formally proving various aspects of RPL's behavior upon an LBR crash. Piotr developed a prototype implementation of RNFD dedicated for RPL to verify earlier performance claims.
著者は、ピョートル・チョルコシュとアグニエシュカ・パスコウスカに感謝したいと思います。アグニエシュカは、LBR 墜落時の RPL の動作のさまざまな側面についての理解を深め、正式に証明することに貢献しました。Piotr は、以前のパフォーマンス主張を検証するために、RPL 専用の RNFD のプロトタイプ実装を開発しました。
Konrad Iwanicki
University of Warsaw
Banacha 2
02-097 Warszawa
Poland
Phone: +48 22 55 44 428
Email: iwanicki@mimuw.edu.pl