11. パケット転送とループ回避/検出

11.1. パケット転送の提案

このドキュメントはルーティングプロトコルを規定しています。これらの非規範的な提案は、そのような実装がRPLでどのように機能するかを例示することにより、転送実装の設計を支援するために提供されています。

宛先にパケットを転送する場合、ネクストホップの後継者の選択は次のように優先されます：

1. この仕様は、転送されるパケットのIPv6ヘッダーにマークされたRPLInstanceIDと一致するDODAGバージョンから後継者がどのように選択されるかのみをカバーしています。ループを防ぐためのインスタンスの厳密な順序付けやルーティングプロトコルなどの追加のルールが導入されている限り、インスタンス外のルーティングを行うことができます。そのようなルールは別のドキュメントで定義される場合があります。

2. ローカルの管理設定がRPL以外のルーティングプロトコルから学習されたルートを優先する場合、その後継者を使用します。

3. パケットヘッダーが[RFC6554]で指定されているRH4ヘッダーを含めることによってソースルートを指定する場合、そのルートを使用します。ノードがその指定されたソースルートでパケットを転送できない場合、そのパケットは破棄されるべきです。ノードはエラーをログに記録してもよいです（MAY）。ノードは、パケットの送信元にSource Routing Headerメッセージ内のICMPv6エラーを送信してもよいです（セクション20.18を参照）。

4. マルチキャスト宛先アドバタイズメントから学習された宛先と一致するエントリがルーティングテーブルにある場合（たとえば、宛先が1ホップのネイバーである場合）、その後継者を使用します。

5. ユニキャスト宛先アドバタイズメントから学習された宛先と一致するエントリがルーティングテーブルにある場合（たとえば、宛先がサブDODAGの下方に位置する場合）、その後継者を使用します。複数の後継者に関連付けられたDAOパス制御ビットがある場合、選択時にパス制御ビットを参照して後継者を優先順位で順序付けます。特定のDAOパス制御ビットについて、複数の後継者がそのビットをアサートしたと記録されている場合、そのビットを最も最近アサートした後継者に優先順位を与えるべきです。

6. 宛先と一致するプレフィックスへのルートを提供するDODAGバージョンがある場合、OFとルーティングメトリックに従って、それらのDODAG親の1つを後継者として選択します。

7. より良い一致が存在しない場合、ユニキャストパケットを転送する次の試行のために、他のまだ試行されていないDODAG親を選択できます。

8. 最後に、パケットは破棄されます。ICMP Destination Unreachableが呼び出される場合があります（不整合が検出されます）。

[RFC2460]に従って転送する場合、ホップ制限（Hop Limit）を減らす必要があります（MUST）。

選択された後継者は、パケットの前任者であったネイバーであってはなりません（MUST NOT）（スプリットホライズン）。ただし、変更を行うノードのルーティングテーブルによって決定されるように、パケットが上方から下方への方向に変更されることが意図されている場合を除きます。たとえば、宛先に向かって移動し続けるために、宛先に近づくにつれてDIOルートからDAOルートに切り替える場合などです。

11.2. ループ回避と検出

RPLのループ回避メカニズムはシンプルに保たれ、チャーンと状態を最小限に抑えるように設計されています。ループは、制御パケットの損失など、さまざまな理由で形成される可能性があります。RPLには、メルトダウンから保護し、壊れたパスの修復をトリガーするリアクティブなループ検出手法が含まれています。

RPLループ検出は、データパケット内で転送されるRPLパケット情報を使用し、IPv6ホップバイホップオプションヘッダーにRPLパケット情報を配置する[RFC6553]などの外部メカニズムに依存しています。

RPLパケット情報の内容は次のように定義されています：

• Down 'O': パケットが上方または下方に進行すると予想されるかどうかを示す1ビットのフラグ。ルーターは、パケットが下方に進行すると予想される場合（DAOルートを使用）に'O'フラグを設定し、DODAGルートに向かって（ランクの低いノードへ）転送する場合にクリアします。ホストまたはRPLリーフノードは、'O'フラグを0に設定しなければなりません（MUST）。

• Rank-Error 'R': ランクエラーが検出されたかどうかを示す1ビットのフラグ。ランクエラーは、相対ランクと'O'ビットで示される方向の間に不一致がある場合に検出されます。ホストまたはRPLリーフノードは、'R'ビットを0に設定しなければなりません（MUST）。

• Forwarding-Error 'F': このノードがパケットを宛先に向けてさらに転送できないことを示す1ビットのフラグ。'F'ビットは、Down 'O'ビットが設定されたパケットの宛先へのルートを持たない子ノードによって設定される場合があります。ホストまたはRPLリーフノードは、'F'ビットを0に設定しなければなりません（MUST）。

• RPLInstanceID: パケットが送信されるDODAGインスタンスを示す8ビットのフィールド。

• SenderRank: 送信元によってゼロに設定され、RPLネットワーク内で転送するルーターによってDAGRank(rank)に設定される16ビットのフィールド。

11.2.1. 送信元ノードの動作

送信元がパケットに推奨されるRPLInstanceIDを認識している場合、パケットに関連付けられたRPLInstanceIDフィールドをそれに応じて設定しなければなりません（MUST）。それ以外の場合は、RPL_DEFAULT_INSTANCEに設定しなければなりません（MUST）。

11.2.2. ルーターの動作

11.2.2.1. インスタンス転送

RPLInstanceIDは、送信元によってパケットに関連付けられます。このRPLInstanceIDは、ホストであろうとルーターであろうと、任意のノードによってパケットが配置されるRPLインスタンスと一致しなければなりません（MUST）。RPLInstanceIDはRPLパケット情報の一部です。

RPLネットワーク内でパケットを転送するRPLルーターは、パケットにRPLパケット情報が含まれているかどうかを確認しなければなりません（MUST）。含まれていない場合、RPLルーターはRPLパケット情報を挿入しなければなりません（MUST）。ルーターがパケットをRPLネットワークに注入するイングレスルーターである場合、ルーターはRPLパケット情報のRPLInstanceIDフィールドを設定しなければなりません（MUST）。そのルーターがRPLInstanceIDへのマッピングをどのように決定するかの詳細は、この仕様の範囲外であり、将来の仕様に委ねられます。

RPLネットワーク外にパケットを転送するルーターは、RPLパケット情報を削除しなければなりません（MUST）。

ルーターが特定のRPLInstanceIDを指定するパケットを受信し、ノードがそのインスタンスに関連付けられたDODAGに沿ってパケットを転送できる場合、ルーターはそうしなければならず（MUST）、RPLInstanceID値を変更しないままにしなければなりません。

ノードがRPLInstanceIDに関連付けられたDODAGに沿ってパケットを転送できない場合、ノードはパケットを破棄し、ICMPエラーメッセージを送信すべきです（SHOULD）。

11.2.2.2. DAG不整合ループ検出

パケットの方向がランク関係と一致しない場合、DODAGは不整合です。受信者は、次のいずれかのパケットを受信した場合に不整合を検出します：

• ランクの高いノードから'O'ビットが設定されている（Downへ）。

• ランクの低いノードから'O'ビットがクリアされている（Upへ）。

DODAGルートがDODAGVersionNumberをインクリメントすると、次のDODAGバージョンと前のDODAGバージョンの間に一時的なランクの不連続性が形成される可能性があります。特に、ノードが次のDODAGバージョンでランクを調整し、次のDODAGバージョンへの移行を延期している場合にそうです。まだ前のDODAGバージョンのメンバーであるルーターは、次のDODAGバージョンにある（将来の）親にパケットを転送することを選択する場合があります。場合によっては、これにより親が不整合を検出する可能性があります。これは、前のDODAGバージョンでのランク順序が次のDODAGバージョンと同じであるとは限らず、パケットが前方に進行していないと判断される可能性があるためです。送信ルーターが、選択された後継者がすでに次のDODAGバージョンに参加していることを認識している場合、送信ルーターは、ランク不整合の誤検出を避けるために、不連続性を越えて次のDODAGバージョンにパケットを転送する際に、SenderRankをINFINITE_RANKに更新しなければなりません（MUST）。

パスに沿った1つの不整合は重大なエラーとは見なされず、パケットは続行できます。ただし、同じパケットのパスに沿った2回目の検出は発生すべきではなく、パケットは破棄されなければなりません（MUST）。

このプロセスは、パケットに関連付けられたRank-Errorビットによって制御されます。パケットで不整合が検出されたときに、Rank-Errorビットが設定されていなかった場合、Rank-Errorビットが設定されます。設定されていた場合、パケットは破棄されなければならず（MUST）、Trickleタイマーはリセットされなければなりません（MUST）。

11.2.2.3. DAO不整合検出と回復

DAO不整合ループ回復は、Storingモードの動作にのみ適用されるメカニズムです。

Non-Storingモードでは、パケットは宛先にソースルーティングされ、DAOの不整合はローカルで修正されません。代わりに、新しいコード「ソースルーティングヘッダーのエラー」を持つICMPエラーがルートに送り返されます。「ソースルーティングヘッダーのエラー」メッセージは、[RFC4443]で指定されている「宛先到達不能メッセージ」と同じ形式です。ICMPメッセージで送り返される呼び出しパケットの部分は、少なくともルーティングヘッダーまで記録する必要があり、ルーティングヘッダーはこのノードによって消費され、IPv6ヘッダーの宛先がこのノードが到達できなかったネクストホップになるようにする必要があります。

DAOの不整合は、ルーターが以前に子を介してDAOメッセージから学習した下方ルートを持っているが、その下方ルートが子で無効になった場合（たとえば、子内の関連状態がクリーンアップされたため）に発生します。DAO不整合ループ回復を使用すると、パケットを使用して、サブDODAGに沿った古いDAO状態を再帰的に探索およびクリーンアップできます。

一般的な方法として、下に行くパケットは二度と上に行くべきではありません。DAO不整合ループ回復が適用される場合、ルーターは、Forwarding-Error 'F'ビットを設定し、'O'ビットを変更せずに、パケットを渡した親にパケットを送り返すべきです（SHOULD）。それ以外の場合、ルーターはパケットを黙って破棄しなければなりません（MUST）。

Forwarding-Errorビットが設定されたパケットを受信すると、ノードはそのネイバーへの転送を引き起こしたルーティング状態を削除し、Forwarding-Errorビットをクリアして、パケットの送信を再試行しなければなりません（MUST）。ユーザー設定可能な実装固有のタイマーが満了した後、パケットは代替ネイバーに送信される場合があります。その代替ネイバーがこのノードを介して依然として不整合なDAO状態を持っている場合、プロセスは再帰し、このノードはForwarding-Error 'F'ビットを設定し、代替ネイバーのルーティング状態も同様にクリーンアップされます。