9. 下向きルート
本セクションでは、RPL がどのように下向きルートを発見し、維持するかについて説明します。RPL は、Destination Advertisement Object (DAO) メッセージを使用して下向きルートを構築および維持します。下向きルートは、DODAG ルートからリーフへの P2MP フローをサポートします。下向きルートは P2P フローもサポートします。P2P メッセージは、上向きルートを通って DODAG ルート(または共通の祖先)に向かって流れ、その後、下向きルートを通って DODAG ルートから宛先に流れることができます。
本仕様では、RPL インスタンスが下向きルートを維持するために選択できる 2 つのモードについて説明します。最初のモードは「Storing (格納)」と呼ばれ、ノードはサブ DODAG の下向きルーティングテーブルを格納します。格納ネットワーク内の下向きルート上の各ホップは、次のホップを決定するためにルーティングテーブルを調べます。2 番目のモードは「Non-Storing (非格納)」と呼ばれ、ノードは下向きルーティングテーブルを格納しません。下向きパケットは、DODAG ルートによって入力されたソースルートを使用してルーティングされます [RFC6554]。
RPL は、格納ネットワークと非格納ネットワークの両方に対して、単純な 1 ホップ P2P 最適化を可能にします。ノードは、1 ホップの近隣ノード宛ての P2P パケットをそのノードに直接送信できます。
9.1. 宛先アドバタイズメント親 (Destination Advertisement Parents)
下向きルートを確立するために、RPL ノードは DAO メッセージを上向きに送信します。これらの DAO メッセージのネクストホップ宛先は「DAO 親」と呼ばれます。ノードの DAO 親のコレクションは「DAO 親セット」と呼ばれます。
-
ノードは、全 RPL ノードマルチキャストアドレスを使用して DAO メッセージを送信してもかまいません (MAY)。これは、1 ホップルーティングをプロビジョニングするための最適化です。マルチキャスト DAO の送信時には、'K' ビットをクリアしなければなりません (MUST)。
-
ノードの DAO 親セットは、その DODAG 親セットのサブセットでなければなりません (MUST)。
-
Storing モード動作では、ノードは、DAO 親ではないノードにユニキャスト DAO メッセージを宛ててはなりません (MUST NOT)。
-
Storing モード動作では、DAO メッセージの IPv6 送信元アドレスおよび宛先アドレスは、リンクローカルアドレスでなければなりません (MUST)。
-
Non-Storing モード動作では、ノードは、DODAG ルートではないノードにユニキャスト DAO メッセージを宛ててはなりません (MUST NOT)。
-
Non-Storing モード動作では、DAO メッセージの IPv6 送信元アドレスおよび宛先アドレスは、ユニークローカルまたはグローバルアドレスでなければなりません (MUST)。
DAO 親の選択は、実装および目的関数に固有です。
9.2. 下向きルートの発見と維持
宛先アドバタイズメントは、完全に無効にするか、DIO メッセージ内の MOP で報告されるように、Storing モードまたは Non-Storing モードのいずれかで動作するように構成できます。
-
DODAG に参加するすべてのノードは、ルートからの MOP 設定に従わなければなりません (MUST)。ルータとして完全に参加する能力を持たないノード(例:アドバタイズされた MOP に一致しないノード)は、リーフとして DODAG に参加してもかまいません (MAY)。
-
MOP が 0 の場合(下向きルーティングがないことを示す)、ノードは DAO メッセージを送信してはならず (MUST NOT)、DAO メッセージを無視してもかまいません (MAY)。
-
Non-Storing モードでは、DODAG ルートは、DAO から学習した宛先のソースルーティングテーブルエントリを格納すべきです (SHOULD)。DODAG ルートは、格納された DAO から学習したそれらの宛先のソースルートを生成できなければなりません (MUST)。
-
Storing モードでは、すべての非ルート、非リーフノードは、DAO から学習した宛先のルーティングテーブルエントリを格納しなければなりません (MUST)。
DODAG は、MOP フィールドによって定義されるように、いくつかの可能な動作モードのいずれかを持つことができます。下向きルートをサポートしないか、DODAG ルートからのソースルーティングを通じて下向きルートをサポートするか、またはネットワーク内ルーティングテーブルを通じて下向きルートをサポートするかのいずれかです。
DODAG ルートからのソースルーティングを通じて下向きルートがサポートされる場合、DODAG ルートは、ソースルートを構築するために DAO から学習したソースルーティング情報を格納していることが一般的に期待されます。DODAG ルートが一部の情報を格納できない場合、一部の宛先が到達不能になる可能性があります。
ネットワーク内ルーティングテーブルを通じて下向きルートがサポートされる場合、本仕様で定義されているマルチキャスト動作は、MOP フィールドによって示されるように、サポートされる場合とサポートされない場合があります。
本仕様で説明されているように、ネットワーク内ルーティングテーブルを通じて下向きルートがサポートされる場合、ルータとして動作するノードは、必要なルーティングテーブル状態を保持するために十分にプロビジョニングされていることが期待されます。ルータとして動作するノードが完全なルーティングテーブル状態を保持できない場合、ルーティング状態は完全ではなく、結果としてメッセージが破棄される可能性があり、障害がログに記録される可能性があります(セクション 18.5)。RPL への将来の拡張では、このケースを管理するための洗練されたアクション/動作について詳しく説明する可能性があります。
本仕様の執筆時点では、RPL は混合モード動作(一部のノードがソースルートを行い、他のノードがルーティングテーブルを格納する)をサポートしていません。RPL への将来の拡張では、この動作モードをサポートする可能性があります。
9.2.1. パスシーケンスの維持
ノードに関連付けられている(所有されている)各ターゲットについて、そのノードは下向きルートをプロビジョニングするために DAO メッセージを発行する責任があります。それらの DAO メッセージに含まれるターゲット+トランジット情報は、その後 DODAG を上向きに伝播します。トランジット情報オプション内のパスシーケンスカウンタは、セクション 7 で説明されているように、鮮度を示し、古い下向きルーティング情報を更新するために使用されます。
ノードに関連付けられている(所有されている)ターゲットについて、そのノードは、以下の場合にパスシーケンスカウンタをインクリメントし、新しい DAO メッセージを生成しなければなりません (MUST)。
-
パスライフタイムが更新される場合(例:リフレッシュまたは No-Path)。
-
DODAG 親アドレスサブフィールドリストが変更される場合。
ノードに関連付けられている(所有されている)ターゲットについて、そのノードは、下向きルーティング情報をリフレッシュするために、時折パスシーケンスカウンタをインクリメントし、新しい DAO メッセージを生成してもかまいません (MAY)。Storing モードでは、ノードはマルチパスを有効にするために、各 DAO 親に対してそのような DAO を生成します。同じターゲットに対して同時に生成されたすべての DAO は、トランジット情報内で同じパスシーケンスを使用して送信されなければなりません (MUST)。
9.2.2. DAO メッセージの生成
ノードは、DAO メッセージを受信したとき、DAO 親セットの変更の結果として、または関連するプレフィックスライフタイムの満了などの別のイベントに応答して、DAO メッセージを送信する場合があります。DAO を受信する場合、DAO メッセージが「新しい」か、または新しい情報を含んでいるかが重要です。Non-Storing モードでは、ノードが受信するすべての DAO メッセージは「新しい」です。Storing モードでは、含まれるターゲットについて以下の基準のいずれかを満たす場合、DAO メッセージは「新しい」です。
-
より新しいパスシーケンス番号を持っている、
-
追加のパス制御ビットを持っている、または
-
プレフィックスへの最後の下向きルートを削除する No-Path DAO メッセージである。
サブ DODAG から DAO メッセージを受信したノードは、その DAO メッセージが新しくない場合、DAO メッセージ送信のスケジューリングを抑制してもかまいません (MAY)。
9.3. DAO 基本ルール
-
ノードが、以前の DAO メッセージ送信よりも新しい情報または異なる情報を含む DAO メッセージを送信する場合、DAOSequence フィールドを少なくとも 1 つインクリメントしなければなりません (MUST)。以前の DAO メッセージ送信と同一の DAO メッセージ送信は、DAOSequence フィールドをインクリメントしてもかまいません (MAY)。
-
DAO メッセージの RPLInstanceID および DODAGID フィールドは、ノードの親セットのメンバーおよびノードが送信する DIO と同じ値でなければなりません (MUST)。
-
ノードは、試行を確認するために、応答としてユニキャスト DAO-ACK を要請するために、ユニキャスト DAO メッセージに 'K' フラグを設定してもかまいません (MAY)。
-
'K' フラグが設定されたユニキャスト DAO メッセージを受信したノードは、DAO-ACK で応答すべきです (SHOULD)。'K' フラグが設定されていない DAO メッセージを受信したノードは、特にエラー状態を報告するために、DAO-ACK で応答してもかまいません (MAY)。
-
ユニキャスト DAO メッセージに 'K' フラグを設定したが、応答として DAO-ACK を受信しないノードは、実装固有の再試行回数まで、別の試行のために DAO メッセージ送信を再スケジュールしてもかまいません (MAY)。
-
ノードは、より新しいシーケンス番号のない DAO を無視すべきであり (SHOULD)、それ以上処理してはなりません (MUST NOT)。
DODAG ルートによってのみインクリメントされ、他のノードによって変更されずに繰り返される DIO のバージョンフィールドとは異なり、DAOSequence 値は各ノードに固有です。ユニキャストおよびマルチキャスト DAO メッセージのシーケンス番号空間は、同じでも異なっていてもかまいません。同じシーケンス番号空間を使用することが推奨されます (RECOMMENDED)。
9.4. DAO メッセージの構造
DAO は、格納ネットワークと非格納ネットワークの両方で共通の構造に従います。最も一般的な形式では、DAO メッセージにはいくつかのオプションのグループが含まれる場合があり、各グループは 1 つ以上のターゲットオプションとそれに続く 1 つ以上のトランジット情報オプションで構成されます。
トランジット情報オプションのグループ全体が、ターゲットオプションのグループ全体に適用されます。後のセクションでは、各動作モードの詳細について説明します。
-
RPL ノードは、送信する各 DAO メッセージに 1 つ以上の RPL ターゲットオプションを含めなければなりません (MUST)。ノードがそのノードへの下向きルートをプロビジョニングするために DODAG を必要とする場合、1 つの RPL ターゲットオプションは、ノードの IPv6 アドレスを含むプレフィックスを持たなければなりません (MUST)。RPL ターゲットオプションの直後に、それを修飾する不透明な RPL ターゲット記述子オプションが続く場合があります (MAY)。
-
ノードが、そのアドレスの 1 つをカバーするターゲットオプションのトランジット情報オプション内の情報を更新する場合、そのトランジット情報オプション内のパスシーケンス番号をインクリメントしなければなりません (MUST)。パスシーケンス番号は、下向きルートのリフレッシュを引き起こすために時折インクリメントされる場合があります (MAY)。
-
ユニキャスト DAO メッセージ内の 1 つ以上の RPL ターゲットオプションの直後に、1 つ以上のトランジット情報オプションが続かなければなりません (MUST)。すべてのトランジットオプションは、それらの直前にあるすべてのターゲットオプションに適用されます。
-
マルチキャスト DAO は、トランジット情報オプションに DODAG 親アドレスサブフィールドを含めてはなりません (MUST NOT)。
-
特定のターゲットの情報を含む DAO メッセージを受信して処理し、そのターゲットの以前の情報を持っているノードは、セクション 7 に従って DAO メッセージに更新された情報が含まれているかどうかを判断するために、そのターゲットに関連付けられたトランジット情報オプション内のパスシーケンス番号を使用しなければなりません (MUST)。
-
上記のルールに従わない DAO メッセージを受信したノードは、それ以上の処理を行わずに DAO メッセージを破棄しなければなりません (MUST)。
Non-Storing モードでは、ルートは、ターゲット(アドレスまたはプレフィックス)とトランジットアドレスを結び付ける 1 ホップ情報を再帰的に検索することによって、厳密なソースルーティングヘッダーをホップバイホップで構築します。場合によっては、子アドレスが親によって所有およびアドバタイズされたプレフィックスから派生している場合、その親子関係は、ソースルーティングヘッダーを構築する目的でルートによって推論される場合があります。その他のすべての場合において、後でルーティングヘッダーの再帰的な構築を可能にするために、到達可能なターゲットからトランジット-ターゲット関係をルートに通知する必要があります。DAO メッセージでターゲットとしてアドバタイズされるアドレスは、同じルータに配置されているか、または関連するトランジット情報に示されているアドレスを所有するルータによってリンク上で到達可能でなければなりません (MUST)。エンドツーエンドのソースルートパスの連続性を確保するために、以下の追加ルールが適用されます。
-
トランジットオプションで使用される親のアドレスは、その親からの 'R' フラグが設定された PIO から取得されなければなりません (MUST)。PIO 内の 'R' フラグは、プレフィックスフィールドに実際に完全な親アドレスが含まれていることを示しますが、子は親アドレスがリンク上にあると想定すべきではありません (SHOULD NOT)。
-
'A' フラグが設定された PIO は、RPL 子ノードがプレフィックスを使用してアドレスを自動構成できることを示します。'A' フラグが設定された PIO でプレフィックスをアドバタイズする親は、それを DAO ターゲットとしてアドバタイズすることによって、PIO 内のアドレスまたはプレフィックス全体がルートから到達可能であることを保証しなければなりません (MUST)。親が、プレフィックスがリンク上にあることを示す 'L' フラグも設定している場合、親はプレフィックス全体を DAO メッセージ内のターゲットとしてアドバタイズしなければなりません (MUST)。'L' フラグがクリアされ、'R' フラグが設定されている場合(親が PIO で自身のアドレスを提供することを示す)、親はそのアドレスを DAO ターゲットとしてアドバタイズしなければなりません (MUST)。
-
DAO メッセージでターゲットとしてアドバタイズされるアドレスは、同じルータに配置されているか、または関連するトランジット情報に示されているアドレスを所有するルータによってリンク上で到達可能でなければなりません (MUST)。
-
ルーティングヘッダーの最適な圧縮を可能にするために、親は、'A' フラグが設定され 'L' フラグがクリアされたすべての PIO で 'R' フラグを設定すべきであり (SHOULD)、子は、DAO メッセージでターゲットとしてアドバタイズされるアドレスを自動構成するために使用される PIO で見つかった親のアドレスをトランジットとして使用することを優先すべきです (SHOULD)。
-
ルータは、代替インターフェースにあるアドレスであるため、または接続されたホストなどの RPL 外部のノードに属しているため、親にとってリンク上にあることが知られていないターゲットを持っている場合があります。このようなターゲットを RPL ネットワークに注入するために、ルータは、そのノードの DAO 親にとってリンク上にあるアドレスを使用して、そのターゲットのトランジット情報オプション内の DODAG 親アドレスサブフィールドとして自身をアドバタイズしなければなりません (MUST)。ターゲットが外部ノードに属している場合、ルータはトランジット情報内の外部 'E' フラグを設定しなければなりません (MUST)。
'L' フラグが設定された親 PIO からアドレスを自動構成した子ノードは、親がプレフィックス全体がすでにルートから到達可能であることを保証するため、そのアドレスを DAO ターゲットとしてアドバタイズする必要はありません。ただし、'L' フラグが設定されていない場合、Non-Storing モードでは、子ノードは、ルーティングヘッダーの再帰的な構築を可能にするために、親の到達可能なアドレスを使用して、親子関係をルートに通知する必要があります。これは、DAO メッセージ内で親のアドレスをトランジットとして、子のアドレスをターゲットとして関連付けることによって行われます。
9.5. DAO 送信スケジューリング
DAO は上向きに流れるため、ユニキャスト DAO を受信すると、DAO 親へのユニキャスト DAO の送信がトリガーされる可能性があります。
-
新しいパスシーケンスを持つトランジット情報オプションを含むなど、更新された情報を含むユニキャスト DAO メッセージを受信すると、ノードは DAO を送信すべきです (SHOULD)。この DAO メッセージを直ちに送信すべきではありません (SHOULD NOT)。自身が DAO 親である他のノードからの DAO 情報を集約するために、DAO メッセージの送信を遅延させるべきです (SHOULD)。
-
ノードは、タイマー (DelayDAO) を使用して DAO メッセージの送信を遅延させるべきです (SHOULD)。DAO メッセージを受信すると、DelayDAO タイマーが開始されます。DelayDAO タイマーがアクティブな間に受信された DAO メッセージは、タイマーをリセットしません。DelayDAO タイマーが満了すると、ノードは DAO を送信します。
-
ノードがその DAO 親セットにノードを追加する場合、DAO メッセージ送信をスケジュールすべきです (SHOULD)。
DelayDAO の値と計算は実装依存です。本仕様では、デフォルト値 DEFAULT_DAO_DELAY が定義されています。
9.6. DAO メッセージのトリガー
ノードは、サブ DODAG に DAO メッセージを送信するようにトリガーできます。各ノードは DAO トリガーシーケンス番号 (DTSN) を維持し、DIO メッセージを通じて通信します。
-
ノードがその DAO 親の 1 つが DTSN をインクリメントするのを聞いた場合、ノードはセクション 9.3 および 9.5 のルールを使用して DAO メッセージ送信をスケジュールしなければなりません (MUST)。
-
Non-Storing モードでは、ノードがその DAO 親の 1 つが DTSN をインクリメントするのを聞いた場合、ノードは自身の DTSN をインクリメントしなければなりません (MUST)。
Storing モードの動作では、定期的なルーティングテーブルの更新とメンテナンスの一環として、格納ノードは、直下の子からの DAO 更新のセットを確実にトリガーするために DTSN をインクリメントしてもかまいません (MAY)。
Storing モードの動作では、その状態情報は DODAG をホップバイホップで上向きに伝播するため、サブ DODAG 全体からの DAO 更新をトリガーする必要はありません。
Non-Storing モードの動作では、DTSN のインクリメントにより、ノードの直下の子も順番に DTSN をインクリメントし、サブ DODAG 全体からの DAO 更新のセットがトリガーされます。通常、Non-Storing モードの動作では、DAO リフレッシュが必要であるがグローバル修復(DODAGVersionNumber のインクリメントなどによる)が望ましくない場合にのみ、ルートが独立して DTSN をインクリメントします。通常、Non-Storing モードの動作では、すべての非ルートノードは、親がそうするのを観察した場合にのみ DTSN をインクリメントします。
一般に、ノードは、下向きルートの不整合の検出に基づく場合や、内部タイマーに基づいて時折など、実装固有のロジックに従って DAO 更新をトリガーする場合があります。
格納ネットワークでは、トリガーされた DAO に適切な DelayDAO を選択することで、送信される DAO の数を大幅に減らすことができます。トリガーは DODAG を下向きに流れます。最良の場合、DAO は DODAG を上向きに流れ、リーフが最初に DAO を送信し、各ノードが DAO メッセージを 1 回だけ送信します。このようなスケジューリングは、DelayDAO をランクに反比例するように設定することで近似できます。この提案は、効率的な集約を可能にするための最適化として意図されていることに注意してください(一般的な場合の正しい動作には必須ではありません)。
9.7. Non-Storing モード
Non-Storing モードでは、RPL は IP ソースルーティングを使用してメッセージを下向きにルーティングします。以下のルールは、Non-Storing モードのノードに適用されます。Storing モードには、セクション 9.8 で説明されている別のルールセットがあります。
-
トランジット情報オプションの DODAG 親アドレスサブフィールドには、1 つ以上のアドレスが含まれていなければなりません (MUST)。これらのアドレスはすべて、送信者の DAO 親のアドレスでなければなりません (MUST)。
-
DAO は、親選択の一部としてインストールされたデフォルトルートに沿って、ルートに直接送信されます。
-
ノードがその DAO 親セットからノードを削除する場合、更新されたトランジット情報オプションを含む新しい DAO メッセージを生成してもかまいません (MAY)。
Non-Storing モードでは、ノードは DAO を使用してその DAO 親を DODAG ルートに報告します。DODAG ルートは、ルート内の各ノードからの DAO 親セットを使用して、ノードへの下向きルートをつなぎ合わせることができます。パスシーケンス情報は、古い DAO 情報を検出するために使用される場合があります。このホップごとのルート計算の目的は、DAO 親が変更されたときのトラフィックを最小限に抑えることです。ノードが完全なソースルートを報告した場合、DAO 親の変更時に、サブ DODAG 全体が新しい DAO を DODAG ルートに送信する必要があります。したがって、Non-Storing モードでは、ノードは単一の DAO を送信できますが、複数の DAO 親のそれぞれに複数の DAO メッセージを送信することを選択する場合もあります。
ノードは、複数の RPL ターゲットオプションを含む単一の DAO メッセージを送信することによって DAO をパックします。各 RPL ターゲットオプションには、独自の、直後に続くトランジット情報オプションがあります。
9.8. Storing モード
Storing モードでは、RPL は IPv6 宛先アドレスによってメッセージを下向きにルーティングします。以下のルールは、Storing モードのノードに適用されます。
-
トランジット情報オプションの DODAG 親アドレスサブフィールドは空でなければなりません (MUST)。
-
ユニキャスト DAO を受信すると、ノードは、DAO がノード自体がアドバタイズするプレフィックスのセットを変更するかどうかを計算しなければなりません (MUST)。この計算には、DAO メッセージに、ノードにすでに格納されている情報に取って代わる新しい情報が含まれているかどうかを判断するために、DAO に関連付けられたトランジット情報オプション内のパスシーケンス情報の参照を含めるべきです (SHOULD)。その場合、ノードは新しい DAO メッセージを生成し、セクション 9.5 のルールに従ってそれを送信しなければなりません (MUST)。このような変更には、No-Path DAO の受信が含まれます。
-
ノードが新しい DAO を生成する場合、その各 DAO 親にそれをユニキャストすべきです (SHOULD)。DAO 親ではないノードに DAO メッセージをユニキャストしてはなりません (MUST NOT)。
-
ノードがその DAO 親セットからノードを削除する場合、既存のルートを無効にするために、その削除された DAO 親に No-Path DAO メッセージ(セクション 6.4.3)を送信すべきです (SHOULD)。
-
アドバタイズされた下向きアドレスへのメッセージが転送エラー、近隣不到達検出 (NUD)、または同様の障害に見舞われた場合、ノードはアドレスを到達不能としてマークし、適切な No-Path DAO を生成してもかまいません (MAY)。
DAO は、ノードがどのアドレスおよびプレフィックスへのルートを持っているかをアドバタイズします。Non-Storing モードとは異なり、これらの DAO はルート自体に関する情報を通信しません。その情報はネットワーク内に格納され、IPv6 送信元アドレスから暗黙的に示されます。格納ノードが DAO を生成する場合、受信した DAO の格納された状態を使用して、RPL ターゲットオプションとその関連するトランジット情報オプションのセットを生成します。
この情報は各ノードのルーティングテーブル内に格納されるため、Storing モードでは、DAO はこの情報を格納する DAO 親に直接通信されます。
9.9. パス制御 (Path Control)
ノードからの DAO メッセージには、1 つ以上のターゲットオプションが含まれています。各ターゲットオプションは、ノードによってアドバタイズされたプレフィックス、LLN の外部で到達可能なアドレスのプレフィックス、ノードのサブ DODAG 内の宛先のアドレス、またはサブ DODAG 内のノードがリッスンしているマルチキャストグループのいずれかを指定します。トランジット情報オプションのパス制御フィールドにより、ノードは複数の下向きルートを要求または許可できます。ノードは、以下のようにトランジット情報オプションのパス制御フィールドを構築します。
-
パス制御フィールドのビット幅は、値 (PCS + 1) に等しくなければなりません (MUST)。ここで、PCS は DODAG 構成オプションの制御フィールドで指定されます。値 (PCS + 1) 以上のビットは、送信時にクリアされなければならず (MUST)、受信時には無視されなければなりません (MUST)。その値未満のビットは「アクティブ」ビットと見なされます。
-
ノードは、パス制御フィールドに入力する際に、DAO 親のグループ化を論理的に構築しなければなりません (MUST)。ここで、各グループは同等の優先度の DAO 親で構成されます。それらのグループは、優先度に従って順序付けられなければならず (MUST)、これにより DAO 親のパス制御サブフィールドへの論理マッピングが可能になります(図 27 を参照)。グループは、パス制御フィールドのビット幅全体に拡張するために繰り返される場合がありますが (MAY)、優先度が適切に通信されるように、繰り返されるグループを含む順序は保持されなければなりません (MUST)。
-
ノード自身のアドレスまたは LLN 外部のプレフィックスを記述する RPL ターゲットオプションの場合、パス制御フィールドの少なくとも 1 つのアクティブビットが設定されなければなりません (MUST)。パス制御フィールドのより多くのアクティブビットが設定される場合があります (MAY)。
-
ノードが同じ RPL ターゲットオプションを持つ複数の DAO を受信した場合、受信したパス制御フィールドをビット単位で OR 演算しなければなりません (MUST)。この集約されたビット単位の OR は、プレフィックスが要求する下向きルートの数を表します。
-
ノードがその DAO 親の 1 つに DAO メッセージを送信する場合、集約されたパス制御フィールドから、その DAO 親を含むグループにマップされているサブフィールドでアクティブに設定されているビットの 1 つ以上を選択しなければなりません (MUST)。特定のビットは、1 つの親に対してのみアクティブとして提示できます。親に送信する DAO メッセージでは、これらのアクティブビットが設定され、他のすべてのアクティブビットがクリアされていなければなりません (MUST)。
-
RPL ターゲットオプションと DAOSequence 番号について、ノードが異なる DAO 親に送信する DAO は、互いに素なアクティブパス制御ビットのセットを持たなければなりません (MUST)。ノードは、2 つの異なる DAO 親への DAO で同じアクティブビットを設定してはなりません (MUST NOT)。
-
パス制御ビットは、特定のパス制御サブフィールドに属するアクティブなパス制御ビットまたはビットのグループ化が、そのサブフィールドにマップされたグループ内の DAO 親に割り当てられるように、DAO 親のパス制御サブフィールドへの優先度マッピングに従って割り当てられるべきです (SHOULD)。
-
Non-Storing モードの動作では、ノードは、パス制御フィールドでそれ以上の処理を行わずに DAO を通過させてもかまいません (MAY)。
-
ノードは、パス制御フィールドにアクティブビットが設定されていない DAO メッセージをユニキャストしてはなりません (MUST NOT)。特定のターゲットオプションについて、ノードがそのターゲットを含む DAO メッセージを各 DAO 親に送信するのに十分な集約パス制御ビットを持っていない可能性があり、その場合、それらの最も優先度の低い DAO 親はそのターゲットの DAO メッセージを受け取らない可能性があります。
パス制御フィールドにより、ノードは、自身に対して生成される下向きルートの数を制限できます。これは、パス制御フィールドに、優先する下向きルートの最大数に等しい数のビットを設定します。各ビットは最大でも 1 つの DAO 親に送信されます。ビットのクラスターは、単一の DAO 親に送信され、その親が自身の DAO 親間で分割することができます。
関連するパス制御フィールドを持つターゲットの DAO ルートをプロビジョニングするノードは、そのターゲットの複数の代替 DAO ルート間の優先順序を決定するために、そのパス制御フィールドの内容を使用すべきです (SHOULD)。パス制御フィールドの割り当ては、目的関数に従った下向き方向の「エンドツーエンド」集約メトリックに関するこのノードの最良の知識に基づいて決定される(DAO 親の)優先度から派生します。Non-Storing モードでは、ルートは、優先 DAO 親のパス制御指示を含む、受信した各 DAO からの情報を集約することによって、下向きルートを決定できます。
9.9.1. パス制御の例
4 つの親 P1、P2、P3、および P4 を持つノード N を含む、Storing モードで動作している LLN があるとします。N は、そのサブ DODAG に 3 つの子 C1、C2、および C3 を持つとします。PCS を 7 とし、パス制御フィールドに 8 つのアクティブビットがあるようにします:11111111b。以下の例を考えてみましょう。
パス制御フィールドは、図 27 に従い、それら 4 つのサブフィールドが 4 つの異なる優先度レベルを表すように、4 つのサブフィールド PC1 (11000000b)、PC2 (00110000b)、PC3 (00001100b)、および PC4 (00000011b) に分割されます。この例では、ノード N での実装は、{P1, P2} を互いに同等の優先度であり、全体として最も優先されるグループとしてグループ化します。{P3} は {P1, P2} よりも優先度が低く、{P4} よりも優先度が高くなります。ノード N に、以下のようにパス制御マッピングを実行させます。
{P1, P2} -> パス制御フィールドの PC1 (11000000b)
{P3} -> パス制御フィールドの PC2 (00110000b)
{P4} -> パス制御フィールドの PC3 (00001100b)
{P4} -> パス制御フィールドの PC4 (00000011b)
実装は、パス制御フィールドを完全にカバーするために {P4} を繰り返したことに注意してください。
-
C1 が、パス制御 10000000b でターゲット T を含む DAO を送信するとします。ノード N は、10000000b を C1 およびターゲット T のパス制御フィールドに関連付けるエントリを格納します。
-
C2 が、パス制御 00010000b でターゲット T を含む DAO を送信するとします。ノード N は、00010000b を C1 およびターゲット T のパス制御フィールドに関連付けるエントリを格納します。
-
C3 が、パス制御 00001100b でターゲット T を含む DAO を送信するとします。ノード N は、00001100b を C1 およびターゲット T のパス制御フィールドに関連付けるエントリを格納します。
-
その後ある時点で、ノード N はターゲット T の DAO を生成します。ノード N は、ターゲット T の DAO を提供した各子からの寄与を OR 演算することによって、集約パス制御フィールドを構築します。したがって、集約パス制御フィールドのアクティブビットは次のように設定されます:10011100b。
-
次に、ノード N は、DAO メッセージを準備するために、集約パス制御ビットを親 P1、P2、P3、および P4 に分配します。
-
P1 と P2 は、最も優先されるサブフィールド (11000000b) からアクティブビットを受信する資格があります。これらのビットは、集約パス制御フィールドでは 10000000b です。ノード N は、ビットを 2 つの親のうちの 1 つだけに設定しなければなりません。この場合、ノード P1 にビットが割り当てられ、その DAO のパス制御フィールド 10000000b を取得します。ノード P2 に割り当てるビットは残っていません。したがって、ノード P2 は 00000000b のパス制御フィールドを持ち、アクティブビットがないため、ノード P2 への DAO は生成できません。
-
2 番目に優先されるサブフィールド (00110000b) には、アクティブビット 00010000b があります。ノード N は P3 をこのサブフィールドにマップしています。ノード N はアクティブビットを P3 に割り当て、パス制御 00010000b でターゲット T を含む P3 用の DAO を構築できます。
-
3 番目に優先されるサブフィールド (00001100b) には、アクティブビット 00001100b があります。ノード N は P4 をこのサブフィールドにマップしています。ノード N は両方のビットを P4 に割り当て、パス制御 00001100b でターゲット T を含む P4 用の DAO を構築できます。
-
最も優先度の低いサブフィールド (00000011b) にはアクティブビットがありません。アクティブビットがあった場合、それらのビットは P4 用に構築された DAO のパス制御フィールドに追加されていたでしょう。
-
P1、P2、P3、P4 宛ての DAO メッセージに他のターゲット(T 以外)を入力するプロセスは、それらのターゲットについて収集された集約パス制御フィールドに従って進行します。
9.10. マルチキャスト宛先アドバタイズメントメッセージ
ユニキャスト DAO 動作とは異なる DAO 動作の特別なケースは、マルチキャスト DAO 動作であり、これは「1 ホップ」ルーティングテーブルエントリを入力するために使用される場合があります。
-
ノードは、リンクローカルスコープの全 RPL ノードマルチキャストアドレスに DAO メッセージをマルチキャストしてもかまいません (MAY)。
-
マルチキャスト DAO メッセージは、ノード自体に関する情報、つまり、ノードがサブスクライブしているマルチキャストグループやノードが所有するグローバルアドレスなど、ノードに直接接続されているか所有されているプレフィックスをアドバタイズするためにのみ使用されなければなりません (MUST)。
-
マルチキャスト DAO メッセージは、別のノードから学習した(例:ユニキャスト DAO を通じて)接続情報をリレーするために使用されてはなりません (MUST NOT)。
-
ノードは、受信したマルチキャスト DAO メッセージに対して他の DAO 関連の処理を実行してはなりません (MUST NOT)。特に、ノードは、マルチキャスト DAO の受信時に DAO 親のアクションを実行してはなりません (MUST NOT)。
- マルチキャスト DAO は、DODAG がパケットをリレーする必要なく、直接 P2P 通信を可能にするために使用される場合があります。