3. プロトコルの概要

このセクションの目的は、[RFC4101]の精神に基づいてRPLを説明することです。プロトコルの詳細は、以降のセクションに記載されています。

3.1. トポロジ

このセクションでは、形成される可能性のある基本的なRPLトポロジと、それらが構築されるルール、つまりDODAG形成を管理するルールについて説明します。

3.1.1. トポロジの構築

無線ネットワークなどのLLNは、通常、ポイントツーポイントのワイヤによって課されるような事前定義されたトポロジを持たないため、RPLはリンクを発見し、ピアを慎重に選択する必要があります。

多くの場合、レイヤー2の範囲は部分的にしか重複しないため、RPLは非推移的/非ブロードキャストマルチアクセス（NBMA）ネットワークトポロジを形成し、その上でルートを計算します。

RPLルートは、トポロジのシンクとして機能する1つ以上のルートへの、またはルートからのトラフィック用に最適化されています。その結果、RPLはトポロジを有向非巡回グラフ（DAG）として編成し、シンクごとに1つのDODAGとなる、1つ以上の宛先指向DAG（DODAG）に分割されます。DAGに複数のルートがある場合、ルートはトランジットリンクなどの共通のバックボーンによって連合されることが期待されます。

3.1.2. RPL識別子

RPLは、トポロジを識別および維持するために4つの値を使用します。

• 1つ目はRPLInstanceIDです。RPLInstanceIDは、1つ以上の宛先指向DAG（DODAG）のセットを識別します。ネットワークには複数のRPLInstanceIDが存在する場合があり、それぞれが独立したDODAGのセットを定義します。これらは、異なる目的関数（OF）やアプリケーション用に最適化される場合があります。RPLInstanceIDによって識別されるDODAGのセットは、RPLインスタンスと呼ばれます。同じRPLインスタンス内のすべてのDODAGは、同じOFを使用します。

• 2つ目はDODAGIDです。DODAGIDのスコープはRPLインスタンスです。RPLInstanceIDとDODAGIDの組み合わせは、ネットワーク内の単一のDODAGを一意に識別します。RPLインスタンスには複数のDODAGが存在する場合があり、それぞれに一意のDODAGIDがあります。

• 3つ目はDODAGVersionNumberです。DODAGVersionNumberのスコープはDODAGです。DODAGは、DODAGVersionNumberをインクリメントすることにより、DODAGルートから再構築されることがあります。RPLInstanceID、DODAGID、およびDODAGVersionNumberの組み合わせは、DODAGバージョンを一意に識別します。

• 4つ目はランク（Rank）です。ランクのスコープはDODAGバージョンです。ランクはDODAGバージョン上の半順序を確立し、DODAGルートに対する個々のノードの位置を定義します。

3.1.3. インスタンス、DODAG、およびDODAGバージョン

RPLインスタンスには、1つ以上のDODAGルートが含まれます。RPLインスタンスは、DODAGルートまたはDODAG内の代替パスを介して到達可能な、特定の宛先プレフィックスへのルートを提供する場合があります。これらのルートは独立して動作する場合もあれば、LLNほど制約があるとは限らないネットワーク上で調整する場合もあります。

RPLインスタンスは、以下で構成される場合があります。

• 単一のルートを持つ単一のDODAG

  • たとえば、ホームオートメーションアプリケーションの単一の中央照明コントローラーをルートとする、遅延を最小限に抑えるように最適化されたDODAG。

• 独立したルート（異なるDODAGID）を持つ複数の調整されていないDODAG

  • たとえば、相互に調整するための適切な接続がない都市データ収集アプリケーションの複数のデータ収集ポイント、またはネットワークを動的かつ自律的に分割する手段として複数のDODAGの形成を使用する場合。

• バックボーンネットワーク上でLLNシンク（同じDODAGIDを持つ）を調整する仮想ルートを持つ単一のDODAG。

  • たとえば、信頼できるトランジットリンクで動作する複数の境界ルーター（たとえば、IPv6低電力無線パーソナルエリアネットワーク（6LoWPAN）アプリケーションをサポートする場合）で、同じDODAGのシンクへの論理的に同等のインターフェースとして機能できるもの。

• アプリケーションシナリオに適した上記の組み合わせ。

各RPLパケットは、特定のRPLInstanceID（セクション11.2を参照）に関連付けられているため、RPLインスタンス（セクション5）に関連付けられています。RPLInstanceIDとアプリケーションのタイプまたはサービスの間のマッピングのプロビジョニングまたは自動検出は、この仕様の範囲外です（将来のコンパニオン仕様で定義されます）。

図1は、DODAGルートR1、R2、およびR3を持つ3つのDODAGで構成されるRPLインスタンスの例を示しています。これらの各DODAGルートは、同じRPLInstanceIDをアドバタイズします。線は、親と子の間の接続を示しています。

図2は、DODAGVersionNumberのインクリメントが新しいDODAGバージョンにどのようにつながるかを示しています。この図は、異なるDODAGトポロジをもたらすDODAGVersionNumberのインクリメントを示しています。新しいDODAGバージョンが常に異なるDODAGトポロジを意味するわけではないことに注意してください。この仕様の後半で説明するように、特定のトポロジ変更に対応するには、新しいDODAGバージョンが必要です。

以下の例では、DODAG構造では接続がサポートされている場合に各ノードが複数の親を持つことができますが、簡単にするためにツリーのような構造が描かれていることに注意してください。

     +----------------------------------------------------------------+
     |                                                                |
     | +--------------+                                               |
     | |              |                                               |
     | |     (R1)     |            (R2)                   (R3)        |
     | |     /  \     |            /| \                  / |  \       |
     | |    /    \    |           / |  \                /  |   \      |
     | |  (A)    (B)  |         (C) |  (D)     ...    (F) (G)  (H)    |
     | |  /|\     |\  |         /   | / |\             |\  |    |     |
     | | : : :    : : |        :   (E)  : :            :  `:    :     |
     | |              |            / \                                |
     | +--------------+           :   :                               |
     |      DODAG                                                     |
     |                                                                |
     +----------------------------------------------------------------+
                                RPL インスタンス

                          図 1: RPL インスタンス

            +----------------+                +----------------+
            |                |                |                |
            |      (R1)      |                |      (R1)      |
            |      /  \      |                |      /         |
            |     /    \     |                |     /          |
            |   (A)    (B)   |         \      |   (A)          |
            |   /|\   / |\   |    ------\     |   /|\          |
            |  : : (C)  : :  |           \    |  : : (C)       |
            |                |           /    |        \       |
            |                |    ------/     |         \      |
            |                |         /      |         (B)    |
            |                |                |          |\    |
            |                |                |          : :   |
            |                |                |                |
            +----------------+                +----------------+
                バージョン N                     バージョン N+1

                          図 2: DODAG バージョン

3.2. 上向きルートとDODAG構築

RPLは、DODAGルートに向かう上向き（Up）のルートをプロビジョニングし、目的関数（OF）に従って最適化されたDODAGを形成します。RPLノードは、DODAG情報オブジェクト（DIO）メッセージを通じてこれらのDODAGを構築および維持します。

3.2.1. 目的関数 (OF)

目的関数（OF）は、RPLノードがRPLインスタンス内のルートを選択および最適化する方法を定義します。OFは、DIO構成オプション内の目的コードポイント（OCP）によって識別されます。OFは、ノードが1つ以上のメトリックと制約（それ自体は[RFC6551]で定義されています）をランク（Rank）と呼ばれる値に変換する方法を定義します。ランクは、DODAGルートからのノードの距離を概算します。OFは、ノードが親を選択する方法も定義します。詳細は、セクション14、[RFC6551]、[RFC6552]、および関連するコンパニオン仕様に記載されています。

3.2.2. DODAG修復

DODAGルートは、DODAGVersionNumberをインクリメントすることにより、グローバル修復操作を開始します。これにより、新しいDODAGバージョンが開始されます。新しいDODAGバージョンのノードは、古いDODAGバージョン内のランクに制約されない新しい位置を選択できます。

RPLは、DODAGバージョン内でのローカル修復に使用できるメカニズムもサポートしています。DIOメッセージは、DODAGルートのポリシーから構成および制御される必要なパラメーターを指定します。

3.2.3. セキュリティ

RPLは、メッセージの機密性と整合性をサポートします。リンク層メカニズムが利用可能で適切な場合に使用できるように設計されていますが、それらがない場合、RPLは独自のメカニズムを使用できます。RPLには3つの基本的なセキュリティモードがあります。

1つ目は「非セキュア（unsecured）」と呼ばれ、RPL制御メッセージは追加のセキュリティメカニズムなしで送信されます。非セキュアモードは、RPLネットワークが安全でないことを意味するものではありません。アプリケーションのセキュリティ要件を満たすために、他の既存のセキュリティプリミティブ（リンク層セキュリティなど）を使用している可能性があります。

2つ目は「プリインストール（preinstalled）」と呼ばれ、RPLインスタンスに参加するノードには、セキュアなRPLメッセージを処理および生成できるキーがプリインストールされています。

3つ目のモードは「認証済み（authenticated）」と呼ばれます。認証済みモードでは、ノードはプリインストールモードと同様にキーをプリインストールしていますが、プリインストールされたキーは、リーフとしてRPLインスタンスに参加するためにのみ使用できます。ルーターとして認証済みRPLインスタンスに参加するには、認証局からキーを取得する必要があります。このキーを取得するプロセスは、この仕様の範囲外です。この仕様だけでは、RPL実装が認証済みモードで安全に動作するための十分な詳細は提供されないことに注意してください。RPL実装が認証済みモードで安全に動作するには、将来のコンパニオン仕様で、ノードが認証マテリアル（キー、証明書など）を取得/要求するメカニズムを詳述し、そのマテリアルをどこから取得すべきかを決定する必要があります。セクション10.3も参照してください。

3.2.4. 接地および浮動DODAG

DODAGは接地（grounded）または浮動（floating）にすることができます。DODAGルートは、どちらであるかをアドバタイズします。接地DODAGは、アプリケーション定義のゴールを満たすために必要なホストへの接続を提供します。浮動DODAGはゴールを満たすことは期待されていません。ほとんどの場合、DODAG内のノードへのルートのみを提供します。浮動DODAGは、たとえば、修復中の相互接続を維持するために使用される場合があります。

3.2.5. ローカルDODAG

RPLノードは、DODAGルートが目的の宛先であるローカルDODAGを形成することにより、LLN内の宛先へのルートを最適化できます。複数のDODAGで構成できるグローバルDAGとは異なり、ローカルDAGには1つのDODAGしかなく、したがって1つのDODAGルートしかありません。ローカルDODAGはオンデマンドで構築できます。

3.2.6. 管理上の優先設定

実装/展開では、管理上の優先設定（Administrative Preference）を通じて、一部のDODAGルートを他のルートよりも優先して使用するように指定できます。管理上の優先設定は、アプリケーションの要件やニーズをより適切にサポートするために、トラフィックを制御し、DODAG形成を設計する方法を提供します。

3.2.7. データパス検証とループ検出

LLNの低電力で損失の多い性質は、RPLがデータパケットを使用したオンデマンドループ検出を使用する動機となります。データトラフィックは頻繁ではない可能性があるため、物理トポロジで常に最新のルーティングトポロジを維持すると、エネルギーが無駄になる可能性があります。一般的なLLNは、一時的でトラフィックに無害な物理的接続の変動を示しますが、コントロールプレーンから厳密に追跡するにはコストがかかります。接続の一時的で頻繁でない変更は、送信するデータがあるまでRPLで対処する必要はありません。RPLの設計のこの側面は、既存の頻繁に使用されるLLNプロトコルと、その有効性に関する広範な実験および展開の証拠に基づいています。

データパケットと共に転送されるRPLパケット情報には、送信機のランクが含まれます。パケットのルーティング決定（上向きまたは下向き）と2つのノード間のランク関係の不整合は、ループの可能性を示します。そのようなパケットを受信すると、ノードはローカル修復操作を開始します。

たとえば、ノードが上向き方向に移動しているとフラグが立てられたパケットを受信し、そのパケットが送信機のランクを受信ノードよりも低い（小さい）と記録している場合、受信ノードは、パケットが上向き方向に進行しておらず、DODAGに不整合があると結論付けることができます。

3.2.8. 分散アルゴリズムの動作

DODAGを構築する分散アルゴリズムの概要は次のとおりです。

• 一部のノードは、関連するDODAG構成を持つDODAGルートになるように構成されます。

• ノードは、リンクローカルマルチキャストDIOメッセージをall-RPL-nodesに送信することにより、プレゼンス、DODAGとの提携、ルーティングコスト、および関連するメトリックをアドバタイズします。

• ノードはDIOをリッスンし、その情報を使用して、指定された目的関数とネイバーのランクに従って、新しいDODAGに参加する（したがって、DODAG親を選択する）か、既存のDODAGを維持します。

• ノードは、DODAGバージョンのDODAG親を介して、DIOメッセージで指定された宛先のルーティングテーブルエントリをプロビジョニングします。DODAGに参加することを決定したノードは、デフォルトルートのネクストホップとして1つ以上のDODAG親と、関連するインスタンスの他のいくつかの外部ルートをプロビジョニングできます。

3.3. 下向きルートと宛先アドバタイズメント

RPLは、宛先アドバタイズメントオブジェクト（DAO）メッセージを使用して下向き（Downward）ルートを確立します。DAOメッセージは、ポイントツーマルチポイント（P2MP）またはポイントツーポイント（P2P）トラフィックを必要とするアプリケーション向けのオプション機能です。RPLは、格納モード（完全なステートフル）または非格納モード（完全なソースルーティング）の2つの下向きトラフィックモードをサポートしています。セクション9を参照してください。特定のRPLインスタンスは、格納または非格納のいずれかです。どちらの場合も、P2PパケットはDODAGルートに向かって上向きに移動し、次に最終的な宛先に向かって下向きに移動します（宛先が上向きルート上にない場合）。非格納の場合、パケットは下向きに移動する前にDODAGルートまで移動します。格納の場合、パケットはDODAGルートに到達する前に、ソースと宛先の共通の祖先によって宛先に向かって下向きに転送される場合があります。

この仕様の執筆時点では、格納モードと非格納モードの両方の動作をサポートする実装は期待されていません。ほとんどの実装は、下向きルートなし、非格納モードのみ、または格納モードのみのいずれかをサポートすることが期待されています。格納モードと非格納モードのハイブリッドミックスなどの他の動作モードは、この仕様の範囲外であり、他のコンパニオン仕様で説明される場合があります。

この仕様では、P2Pトラフィックをサポートする基本的な動作モードについて説明します。より最適化されたP2Pソリューションは、コンパニオン仕様で説明される場合があることに注意してください。

3.4. ローカルDODAGルート検出

オプションで、RPLネットワークは、LLN内の特定の宛先へのDODAGのオンデマンド検出をサポートできます。このようなローカルDODAGは、グローバルDODAGとは少し異なる動作をします。DODAGIDとRPLInstanceIDの組み合わせによって一意に定義されます。RPLInstanceIDは、DODAGがローカルDODAGであるかどうかを示します。

3.5. ランクのプロパティ

ノードのランクは、DODAGバージョン内のそのノードの位置のスカラー表現です。ランクはループを回避および検出するために使用されるため、特定のプロパティを示す必要があります。ランクの正確な計算は目的関数に任されています。ランクの具体的な計算は目的関数に任されていますが、ランクは目的関数に関係なく一般的なプロパティを実装する必要があります。

特に、ノードのランクは、DODAGバージョンがDODAG宛先に向かって進むにつれて単調に減少する必要があります。その点で、ランクは、DODAGバージョン内のノードの位置または半径のスカラー表現と見なすことができます。

目的関数がランクを計算する方法の詳細は、この仕様の範囲外ですが、その計算は、たとえば、親、リンクメトリック、ノードメトリック、およびノード構成とポリシーに依存する場合があります。詳細については、セクション14を参照してください。

ランクはパスコストではありませんが、その値はパスメトリックから導出され、影響を受ける可能性があります。ランクには、必ずしもすべてのメトリックのプロパティではない独自のプロパティがあります。

タイプ (Type): : ランクは抽象的な数値です。

関数 (Function): : ランクは、ネイバーに関するDODAGバージョン内の相対位置の表現であり、必ずしもルートへの距離またはパスコストの適切な指標または適切な表現ではありません。

安定性 (Stability): : ランクの安定性は、ルーティングトポロジの安定性を決定します。トポロジを安定させるために、ある程度の減衰またはフィルタリングが推奨されます。したがって、ランクは、一部のリンクまたはノードメトリックほど速く変化するとは限りません。新しいDODAGバージョンは、DODAGバージョン内のメトリックとランクの間に時間の経過とともに形成される可能性のある不一致を調整する良い機会になります。

プロパティ (Properties): : ランクは厳密に単調な方法でインクリメントされ、ルートから、またはルートへの進行を検証するために使用できます。帯域幅やジッターなどのメトリックは、必ずしもこのプロパティを示すわけではありません。

抽象 (Abstract): : ランクには物理的な単位はなく、ホップごとの増分の範囲があり、各増分の割り当ては目的関数によって決定されます。

ランク値は、RPLループ回避戦略に従って、DODAG親の選択に反映されます。親が追加され、DODAG内のノードのランク値がアドバタイズされると、DODAG親の選択とDODAG内の移動に関するノードのさらなるオプションは、ループ回避のために制限されます。

3.5.1. ランク比較 (DAGRank())

ランクは固定小数点数と考えることができ、整数部分と小数部分の間の基数点の位置はMinHopRankIncreaseによって決定されます。MinHopRankIncreaseは、ノードとそのDODAG親のいずれかとの間のランクの最小増加です。DODAGルートはMinHopRankIncreaseをプロビジョニングします。MinHopRankIncreaseは、ホップコストの精度とネットワークがサポートできる最大ホップ数の間のトレードオフを作成します。たとえば、非常に大きなMinHopRankIncreaseは、ランクに対する特定のホップの影響を正確に特徴付けることができますが、多くのホップをサポートすることはできません。

目的関数がランクを計算する場合、目的関数は全体（つまり、16ビット）のランク量に対して動作します。ランクが比較される場合、たとえば、親関係の決定やループ検出のために、ランクの整数部分が使用されます。ランクの整数部分は、DAGRank()マクロによって次のように計算されます。ここで、floor(x)はx以下の最大の整数を評価する関数です。

           DAGRank(rank) = floor(rank/MinHopRankIncrease)

たとえば、16ビットのランク量が10進数27で、MinHopRankIncreaseが10進数16の場合、DAGRank(27) = floor(1.6875) = 1になります。ランクの整数部分は1で、小数部分は11/16です。

このドキュメントの規則に従って、マクロDAGRank(node)を使用することは、DAGRank(node.rank)と解釈できます。ここで、node.rankはノードによって維持されるランク値です。

DAGRank(A)がDAGRank(B)より小さい場合、ノードAのランクはノードBのランクより小さくなります。

DAGRank(A)がDAGRank(B)と等しい場合、ノードAのランクはノードBのランクと等しくなります。

DAGRank(A)がDAGRank(B)より大きい場合、ノードAのランクはノードBのランクより大きくなります。

3.5.2. ランク関係

ランク計算は、LLN内のネイバーであるノードMおよびNに対して次のプロパティを維持します。

DAGRank(M) が DAGRank(N) より小さい:

: この場合、Mの位置はNの位置よりもDODAGルートに近くなります。ノードMは、ループを作成するリスクなしに、ノードNのDODAG親に安全になることができます。さらに、ノードNの場合、DODAG親セット内のすべての親は、DAGRank(N)より小さいランクである必要があります。つまり、ノードNによって提示されるランクは、その親のいずれかによって提示されるランクよりも大きくなければなりません（MUST）。

DAGRank(M) が DAGRank(N) と等しい:

: この場合、DODAG内およびDODAGルートに関するMとNの位置は類似しているか、同一です。等しいランクを持つノードを介したルーティングは、ルーティングループを引き起こす可能性があります（つまり、そのノードも等しいランクを持つノードを介してルーティングすることを選択した場合）。

DAGRank(M) が DAGRank(N) より大きい:

: この場合、Mの位置はNの位置よりもDODAGルートから遠くなります。さらに、ノードMは実際にはノードNのサブDODAGにある可能性があります。ノードNがノードMをDODAG親として選択した場合、ループを作成するリスクがあります。

例として、ランクは、目的関数が最小化するメトリックがETXまたは遅延である場合に、ETX（予想送信回数、LLNで使用され[RFC6551]で定義されているかなり一般的なルーティングメトリック）を綿密に追跡するように計算したり、DODAG内で使用されている目的関数に適切なより複雑な方法で計算したりできます。

3.6. RPLで使用されるルーティングメトリックと制約

ルーティングメトリックは、最短パスを計算するためにルーティングプロトコルによって使用されます。IS-IS（[RFC5120]）やOSPF（[RFC4915]）などの内部ゲートウェイプロトコル（IGP）は、静的リンクメトリックを使用します。このようなリンクメトリックは、単に帯域幅を反映することも、さまざまなリンク特性を定義するいくつかのメトリックの多項式関数に従って計算することもできます。一部のルーティングプロトコルは複数のメトリックをサポートしています。ほとんどの場合、（サブ）トポロジごとに1つのメトリックが使用されます。まれに、等コストマルチパス（ECMP）が存在する場合に、タイブレーカーとして2番目のメトリックが使用されることがあります。複数のメトリックの最適化はNP完全問題として知られており、一部の集中型パス計算エンジンによってサポートされる場合があります。

対照的に、LLNは静的メトリックと動的メトリックの両方のサポートを必要とします。さらに、リンクメトリックとノードメトリックの両方が必要です。RPLの場合、すべてのユースケースを満たす単一のメトリック、または複合メトリックを定義することは事実上不可能です。

さらに、RPLは制約ベースのルーティングをサポートしており、制約をリンクとノードの両方に適用できます。リンクまたはノードが必要な制約を満たさない場合、候補ネイバーセットから「プルーニング（剪定）」され、制約付きの最短パスになります。

目的関数は、この（制約付き）パスを計算するために使用される目的を指定します。さらに、ノードは一連のメトリックと制約をサポートするように構成され、DIOメッセージでアドバタイズされたメトリックと制約に従ってDODAG内の親を選択します。アップストリームとダウンストリームのメトリックは、OFとメトリックに応じて、マージされるか、個別にアドバタイズされる場合があります。個別にアドバタイズされる場合、DIO親のセットがDAO親のセット（ユニキャストDAOメッセージが送信されるノード）とは異なる場合があります。ただし、ランク計算のルールに関しては、すべてDODAG親です。

目的関数は、RPLで使用されるルーティングメトリックと制約から切り離されています。OFはDODAG親の選択、負荷分散などのルールを指示しますが、使用されるメトリックや制約のセット、したがって優先パスを決定するものは、DIOメッセージ内のDAGコンテナーオプション内で運ばれる情報に基づいています。

サポートされるリンク/ノードの制約とメトリックのセットは、[RFC6551]で指定されています。

例1: 最短パス: 最短のエンドツーエンド遅延を提供するパス。

例2: 最短制約付きパス: バッテリー駆動ノードを通過せず、パスの信頼性を最適化するパス。

3.7. ループ回避

RPLは、トポロジ変更を受ける際にループの作成を回避しようとし、ループが発生した場合に検出するためのランクベースのデータパス検証メカニズムを含みます（詳細はセクション11を参照）。実際には、これはRPLがループフリーパスの選択も厳密な遅延収束時間も保証しないことを意味しますが、ループが使用されるとすぐに検出して修復できます。RPLはこのループ検出を使用して、パケットがDODAGバージョン内で前進することを確認し、必要に応じて修復をトリガーします。

3.7.1. 貪欲さと不安定性

親セットのサイズを大きくしたり、他のメトリックを改善したりするために、DODAGバージョン内でより深く（ランクを上げる）移動しようとする場合、ノードは貪欲（greedy）です。ノードがDODAGバージョンに参加すると、RPLはDODAGバージョンでの結果としての不安定性を防ぐために、貪欲さを含む特定の動作を禁止します。

ノードが、自身のサブDODAG内のノード、および一般的に自身よりも深いノードからのDIOメッセージを受信して処理することをいとわないとします。この場合、フィードバックループが作成される可能性があり、2つ以上のノードが互いに最適化しようとしながら、DODAGバージョン内を移動し続けようとします。場合によっては、これにより不安定になります。このため、RPLは、ノードがより深いノードからのDIOメッセージを処理できるケースを、ある種のローカル修復に制限しています。このアプローチは「事象の地平線（event horizon）」を作成し、ノードが自身のサブDODAGにある可能性のあるノードのアクションによって、ある制限を超えて不安定になるのを防ぎます。

3.7.1.1. 例: 貪欲な親選択と不安定性

         (A)                    (A)                    (A)
          |\                     |\                     |\
          | `-----.              | `-----.              | `-----.
          |        \             |        \             |        \
         (B)       (C)          (B)        \            |        (C)
                                  \        |            |        /
                                   `-----. |            | .-----'
                                          \|            |/
                                          (C)          (B)

              -1-                    -2-                    -3-

                  図 3: 貪欲なDODAG親選択

図3は、3つの異なる構成のDODAGを示しています。(B)と(C)の間の使用可能なリンクは、3つの構成すべてに存在します。図3-1では、ノード(A)はノード(B)と(C)のDODAG親です。図3-2では、ノード(A)はノード(B)と(C)のDODAG親であり、ノード(B)はノード(C)のDODAG親でもあります。図3-3では、ノード(A)はノード(B)と(C)のDODAG親であり、ノード(C)はノード(B)のDODAG親でもあります。

RPLノードがあまりにも貪欲で、最も優先される親を超えて追加の数の親を最適化しようとすると、不安定になる可能性があります。図3-1に示されているDODAGを検討してください。この例では、ノード(B)と(C)はノード(A)をDODAG親として最も好む可能性がありますが、2つの親を最適化しようとする貪欲な条件下で動作している場合を検討します。

• 図3-1を初期状態とします。

• ノード(C)が最初にDODAGを離れ、より低いランクで再参加し、図3-2に示すようにノード(A)と(B)の両方をDODAG親として取得できたとします。これで、ノード(C)はノード(A)と(B)の両方よりも深くなり、ノード(C)は2つのDODAG親を持つことに満足しています。

• ノード(B)が貪欲さのために、ノード(C)からのDIOメッセージを受信して処理することをいとわない（RPLのルールに反する）と仮定します。その後、ノード(B)はDODAGを離れ、より低いランクで再参加し、ノード(A)と(C)の両方をDODAG親として取得します。これで、ノード(B)はノード(A)と(C)の両方よりも深くなり、2つのDAG親に満足しています。

• 次に、ノード(C)も貪欲であるため、離れてより深く再参加し、再び2つの親を取得して、両方よりも低いランクになります。

• 次に、ノード(B)は再び離れてより深く再参加し、再び2つの親を取得します。

• 再び、ノード(C)は離れてより深く再参加します。

• プロセスは繰り返され、DODAGは図3-2と図3-3の間で振動し、ノードが無限大にカウントしてサイクルを再開するまで続きます。

• このサイクルは、RPLのメカニズムを通じて回避できます。

  • ノード(B)と(C)は、最も優先される親(A)に接続するのに十分なランクに留まり、より深い（より悪い）代替親に行かない（ノードは貪欲ではない）。

  • ノード(B)と(C)は、自分よりも深いノードからのDIOメッセージを処理しない（そのようなノードは自身のサブDODAGにある可能性があるため）。

これらのメカニズムについては、セクション8.2.2.4でさらに説明します。

3.7.2. DODAGループ

DODAGループは、ノードがDODAGから分離し、以前のサブDODAG内のデバイスに再接続するときに発生する可能性があります。特に、DIOメッセージが見逃された場合に発生する可能性があります。DODAGVersionNumberを厳密に使用することでこのタイプのループを排除できますが、一部のローカル修復メカニズムを使用しているときにこのタイプのループが発生する可能性があります。

たとえば、ノードがDODAGから分離し、INFINITE_RANKのランクをアドバタイズし（ルートを汚染する/サブDODAGに通知するため）、その後DODAGに再接続できるようにするローカル修復メカニズムを検討してください。これらのケースの一部では、ノードが自身の以前のサブDODAGに再接続し、DODAGループを引き起こす可能性があります。これは、LLN環境でINFINITE_RANKアドバタイズメントが失われた場合、汚染が失敗する可能性があるためです。（この場合、ランクベースのデータパス検証メカニズムが最終的にループを検出し、修正をトリガーします）。

3.7.3. DAOループ

DAOループは、親が子からのDAOメッセージを受信して処理したときにルートをインストールしたが、子がその後関連するDAO状態をクリーンアップした場合に発生する可能性があります。このループは、No-Path（以前にアナウンスされたプレフィックスを無効にするDAOメッセージ、セクション6.4.3を参照）が見逃され、すべての状態がクリーンアップされるまで持続する場合に発生します。RPLには、DAOメッセージを確認応答するオプションのメカニズムが含まれており、単一のDAOメッセージが見逃された場合の影響を軽減できます。RPLには、DAOループの影響を軽減し、その修復をトリガーするループ検出メカニズムが含まれています。（セクション11.2.2.3を参照）。