8.2.2. Neighbors and Parents across DODAG Versions (DODAGバージョンを跨ぐネイバーとペアレント)

上記のルールは単一のDODAGバージョンを規定するものです。本節のルールは、複数のDODAGバージョンが存在する場合のRPLの動作を定義します。

8.2.2.1. DODAG Version (DODAGバージョン)

1. タプル (RPLInstanceID, DODAGID, DODAGVersionNumber) は、DODAGバージョンを一意に定義します。各DODAGペアレントから最後に受信したDIOメッセージによって伝えられるノードのDODAGペアレントセットのすべての要素は、同じDODAGバージョンに属さなければなりません（MUST）。ノードの候補ネイバーセットの要素は、異なるDODAGバージョンに属してもよいです（MAY）。

2. ノードのDODAGペアレントセットのすべての要素がそのDODAGバージョンに属している場合、またはそのノードが対応するDODAGのルートである場合、そのノードはそのDODAGバージョンのメンバーです。

3. ノードは、自身がメンバーではないDODAGバージョンのDIOを送信してはなりません（MUST NOT）。

4. DODAGルートは、自身が通知するDODAGVersionNumberをインクリメントし、新しいDODAGバージョンに移行してもよいです（MAY）。DODAGルートがDODAGVersionNumberをインクリメントする場合、セクション 7 で説明されているシリアル番号算術（Serial Number Arithmetic）の慣例に従わなければなりません（MUST）。DODAGVersionNumberのインクリメントをトリガーするイベントについては、本節の後半およびセクション 18 で説明します。

5. 特定のDODAG内において、ルートではないノードは、自身が受信した最高のDODAGVersionNumberよりも高いDODAGVersionNumberを通知してはなりません（MUST NOT）。「より高い」は、セクション 7 の「より大きい」演算子として定義されます。

6. ノードがDIOを送信してDODAGバージョンを通知した後は、同じDODAGの以前のDODAGバージョン（すなわち、同じRPLInstanceID、同じDODAGID、およびより低いDODAGVersionNumberを持つもの）のメンバーであってはなりません（MUST NOT）。「より低い」は、セクション 7 の「より小さい」演算子として定義されます。

ルートではないノードでDODAGペアレントセットが空になった場合（すなわち、最後のペアレントが削除され、ノードがそのDODAGに関連付けられなくなった場合）、実装固有のローカルタイマーが満了するまでDODAG情報を抑制すべきではありません。 「古い」DODAG状態の抑制前の間隔中に、新しいペアレントが現れた場合にDODAGVersionNumberがインクリメントされたかどうかをノードが観察できるようになります。これにより、そのノードが自身の以前のサブDODAG内の古いDODAGバージョンに誤って再参加した場合に発生する可能性のあるループを防ぐのに役立ちます。

DODAGVersionNumberがインクリメントされると、新しいDODAGバージョンがDODAGルートから外側へ広がります。新しいDODAGVersionNumberを通知するペアレントは、古いDODAGVersionNumberを通知しているノードのサブDODAGに属することはできません。したがって、ノードはループを形成することなく、新しいDODAGVersionNumberを持つ任意のRankのペアレントを安全に追加できます。

例えば、ノードがDODAGVersionNumber NのDODAGを離れたとします。そのノードがサブDODAGを持っており、Rank INFINITE_RANKを通知してそのサブDODAGをポイズニング（poisoning）しようとしたが、それらの通知がLLNで失われた可能性があるとします。その後、そのノードが元のDODAGVersionNumber NのDODAG内の位置を通知している候補ネイバーを観察した場合、その候補ネイバーはそのノードの以前のサブDODAGに属していた可能性があり、その候補ネイバーをペアレントとして追加するとループが発生する可能性があります。この場合、その候補ネイバーがDODAGVersionNumber N+1を通知しているのが観察されれば、その候補ネイバーは元のノードのサブDODAGに属していないことが確実であるため（元のノードがデタッチされている間にDODAGルートからの通知を聞いてDODAGVersionNumberをインクリメントできたため）、安全であることが確実です。このため、デタッチされたノードがDODAGVersionNumber Nを含む元のDODAG情報を記憶しておくことは有用です。

DODAGルートがいつDODAGVersionNumberをインクリメントするかは実装に依存し、本仕様の範囲外です。例としては、定期的なインクリメント、管理者による介入、または接続の喪失やDODAGの非効率性のアプリケーションレベルでの検出などが挙げられます。

ノードが新しいDODAGバージョンに移行して通知した後は、上記のルールにより、新しいDODAGバージョンの通知をコミットした時点で以前のDODAGバージョン（以前のDODAGVersionNumber）を通知できなくなります。

8.2.2.2. DODAG Roots (DODAGルート)

1. アプリケーション定義の目標を満たす可能性がないDODAGルートは、Groundedビットを設定してはなりません（MUST NOT）。

2. DODAGルートは、ROOT_RANKのRankを通知しなければなりません（MUST）。

3. DODAGペアレントセットが空のノードは、フローティングDODAGのルートになってもよいです（MAY）。また、DAGPreferenceを低く設定してもよいです（MAY）。

非LLNリンクを使用して多数のLLNルートを統合する展開では、それらの非RPLリンク上でRPLを実行し、1つのルーターを「バックボーンルート（backbone root）」として使用することが可能です。バックボーンルートはDODAGの仮想的なルートであり、バックボーン上でBASE_RANKのRankを公開します。そのバックボーンルートをペアレントとするすべてのLLNルート（バックボーンルート自身がLLNルートとしても機能する場合はそれを含む）は、LLNに対してROOT_RANKのRankを公開します。これらの仮想ルートは同じDODAGの一部であり、同じDODAGIDを通知します。これらはバックボーンを介して仮想ルートとDODAGVersionNumberやその他のDODAGパラメータを調整します。調整の方法は本仕様の範囲外です（将来の関連仕様で定義される予定です）。

8.2.2.3. DODAG Selection (DODAG選択)

DAGの目的関数（OF）と通知されたルーティングメトリクスおよび制約のセットによって、ノードがネイバーセット、ペアレントセット、および優先ペアレントをどのように選択するかが決まります。この選択は、暗黙的にDAG内のDODAGも決定します。このような選択には、管理的優先度（Prf）やメトリクス、その他の考慮事項を含めることができます。

他の最適化目標を満たしつつ、より優先度の高いDODAGに参加するオプションがある場合、ノードは通常、OFによって決定されるより優先度の高いDODAGへの参加を試みます。他の条件がすべて同じであれば、どのDODAGが最も優先されるかを決定するのは実装に委ねられます（リマインダーとして、ノードはRPLインスタンスごとに1つのDODAGにのみ参加しなければなりません）。

8.2.2.4. Rank and Movement within a DODAG Version (DODAGバージョン内でのRankと移動)

1. ノードは、DODAGバージョン内の自身のペアレントセットのどのメンバーよりも低いか等しいRankを通知してはなりません（MUST NOT）。

2. ノードは、DODAGバージョン内での以前の通知よりも低いRankを通知してもよいです（MAY）。

3. Lを、特定のノードが通知したDODAGバージョン内での最低のRankとします。同じDODAGバージョン内において、そのノードは L + DAGMaxRankIncrease より高い実効Rankを通知してはなりません（MUST NOT）。INFINITE_RANKはこのルールの例外です。ノードはDODAGバージョン内で制限なくINFINITE_RANKを通知してもよいです（MAY）。ノードのRankが L + DAGMaxRankIncrease で許可される値よりも高くなる場合、Rankを通知する際には、そのRankをINFINITE_RANKとして通知しなければなりません（MUST）。

4. ノードは、いつでもRPLインスタンス内の別のDODAGへの参加を選択してもよいです（MAY）。このような参加にはRankの制限はありません。ただし、その別のDODAGがそのノードが以前メンバーであったDODAGバージョンである場合は、前述の項目(3)のルールを遵守しなければなりません。ノードが新しいDODAGメンバーシップを示すDIOを送信するまでは、以前のDODAGに沿ってパケットを転送しなければなりません（MUST）。

5. ノードは、適切なDODAGペアレントから通知された次のDODAGVersionNumberを聞いた後、いつでもDODAG内の次のDODAGバージョンへの移行を選択してもよいです（MAY）。

概念的には、実装はDODAGバージョン内でDODAGペアレントセットを維持しています。移動はDODAGペアレントセットの変更を伴います。上への移動（Moving Up）はループを作成するリスクはありませんが、下への移動（Moving Down）はリスクがあるため、その操作には追加の制約が適用されます。

ノードが次のDODAGバージョンに移行する場合、新しいバージョンのためにDODAGペアレントセットを再構築する必要があります。実装は、より良いメトリクスを持つがより高いRankを持つ他のネイバーが自身を通知するかどうかを確認するために、妥当な時間だけ移行を遅らせることができます。同様に、ノードが新しいDODAGにジャンプする場合、この新しいDODAGのために新しいDODAGペアレントセットを構築する必要があります。

ノードがアタッチされているDODAGを下（Down）に移動し、Rankを増やす必要がある場合、セクション 8.2.2.5 で説明されているように、ルートをポイズニングし、移動前に遅延させてもよいです（MAY）。

ノードは、以前にメンバーであったことがない任意のDODAGバージョンには制限なく参加することが許可されますが、以前にそのDODAGバージョンのメンバーであった場合は、DODAGバージョンの存続期間中のいかなる時点においても、 L+DAGMaxRankIncrease より高いRankを通知してはならないというルールを引き続き遵守しなければなりません。このルールは、ノードが自身のRankを事実上INFINITE_RANKまでインクリメントし続けることを可能にする抜け穴を作らないために遵守されなければなりません。これは他のノードに影響を与え、リソースを浪費する「無限カウント（count-to-infinity）」シナリオを引き起こす可能性があるためです。

8.2.2.5. Poisoning (ポイズニング)

1. ノードは、INFINITE_RANKのRankを通知することによってルートをポイズニングします。

2. ノードは、ペアレントセットにINFINITE_RANKのRankを持つノードを持ってはなりません（MUST NOT）。

実装はポイズニングの目的でINFINITE_RANKを通知することがありますが、そうすることはRankをINFINITE_RANKに設定することと同じではありません。例えば、ノードはRPLパケット情報にINFINITE_RANKではないRankが含まれるデータパケットを送信し続けながら、DIOではINFINITE_RANKを通知し続けることができます。

（以前の）ペアレントがINFINITE_RANKのRankを通知しているのが観察された場合、その（以前の）ペアレントはDODAGからデタッチされており、もはやペアレントとして機能することはできず、また他のノードがINFINITE_RANKより大きいRankを持つと見なされる方法もありません。したがって、その（以前の）ペアレントはもはやペアレントとして機能することはできず、ペアレントセットから削除されます。

8.2.2.6. Detaching (デタッチ)

1. 特定のDODAGバージョン内でDODAGへの接続を維持できないノード、すなわち本仕様のルールに違反せずに空でないペアレントセットを保持できないノードは、このDODAGバージョンからデタッチしてもよいです（MAY）。デタッチしたノードは自身のフローティングDODAGのルートになり、ポイズニングの代替として、この新しい状況を直ちにDIOで通知すべきです（SHOULD）。

8.2.2.7. Following a Parent (ペアレントへの追随)

1. ノードがDODAGペアレントの1つから、そのペアレントがDODAGを離脱したことを示すDIOを受信した場合、そのノードは可能であれば代替のDODAGペアレントを介して現在のDODAGに留まるべきです（SHOULD）。離脱するペアレントに追随してもよいです（MAY）。

DODAGペアレントは、移動、次のDODAGバージョンへの移行、または別のDODAGへのジャンプを行った可能性があります。ノードは、可能であれば代替ペアレントを介して現在のDODAGに留まることを優先すべきですが、他に選択肢がない場合はペアレントに追随すべきです。