18. 管理性に関する考慮事項

このセクションの目的は、RPL の管理性と、LLN で RPL がどのように運用されるかを検討することです。このセクションの範囲は、[RFC5706] で示された推奨事項に照らして、プロトコルの構成、監視、障害管理、アカウンティング、およびパフォーマンスという管理性の側面を検討することです。

18.1. はじめに

既存の IETF 管理標準のほとんどは、ネットワークデバイスを監視および管理するための MIB モジュール（管理情報構造（SMI）に基づくデータモデル）です。

多くのプロトコルについて、IETF コミュニティは、簡易ネットワーク管理プロトコル [RFC3410]、管理情報構造 [RFC2578]、および新しいプロトコルを管理するための MIB データモデルを含む、IETF 標準管理フレームワークを使用してきました。

[RFC5706] で指摘されているように、運用と管理に関する一般的なポリシーは、SNMP などの単一のプロトコルに厳密に依存するのではなく、一連のツールと管理プロトコルに対してよりオープンなポリシーへと拡大されています。

2003 年、インターネットアーキテクチャ委員会（IAB）はネットワーク管理に関するワークショップ [RFC3535] を開催し、いくつかの IETF ネットワーク管理プロトコルの長所と短所を議論し、運用上のニーズ、特に構成と比較しました。

議論された問題の 1 つは、SNMP [RFC3410] のバイナリ形式のユーザーにとっての使いにくさでした。LLN の場合、執筆時点で CoRE ワーキンググループが LLN 内のデバイスのリソース管理に積極的に取り組んでいることに注意する必要があります。それでも、このセクションは、RPL をどのように展開、運用、および管理すべきかに関する重要なガイダンスを提供すると考えられています。

[RFC5706] で述べられているように：

管理情報モデルには、何が管理可能か、プロトコルのどの側面を構成する必要があるか、どのような種類の操作が許可されるか、どのようなプロトコル固有のイベントが発生する可能性があるか、どのイベントをカウントできるか、どのイベントについてオペレーターに通知する必要があるかについての議論を含める必要があります。

これらの側面については、次のセクションで詳しく説明します。

RPL は、数キロバイトから数百キロバイト、さらにはメガバイトまで変化するメモリなどのリソースを持つさまざまなデバイスで使用されます。メモリが非常に制約されている場合、このセクションに記載されているすべての要件を満たすことはできない可能性があります。それでも、これらすべてを網羅的にリストすることは価値があり、実装者は、デバイス上の利用可能なリソースに従って、これらの要件のうちどれを満たすことができるかを決定します。

18.2. 構成管理

このセクションでは、構成管理に関連するプロトコルパラメータをリストし、構成管理について説明します。

一部の RPL パラメータはオプションです。構成の要件は、使用されるオプションにのみ適用されます。

18.2.1. 初期化モード

「インターネットのアーキテクチャ原則」[RFC1958] のセクション 3.8 には、「可能な限りオプションとパラメータを避ける。オプションとパラメータは、手動ではなく動的に構成またはネゴシエートする必要がある」と記載されています。これは、デバイスの数が多く、手動構成が実行不可能な LLN で特に当てはまります。これは RPL の設計で考慮されており、DODAG ルートは DODAG に参加するデバイスに多数のパラメータを提供し、ルーターでの面倒な構成や構成ミスの潜在的な原因（たとえば、Trickle タイマーの値など）を回避します。それでも、RPL 実装で構成できるようにすべき追加の RPL パラメータがあり、これについてはこのセクションで説明します。

18.2.1.1. 起動時の DIS 動作モード

ノードの電源が最初に入ったとき：

1. ノードは沈黙を守り、関心のある DODAG からの DIO メッセージ（サポートされている OF とメトリック/制約を通知）を受信するのを待ち、DODAG に参加するまでマルチキャスト DIO メッセージを送信しないことを決定する場合があります。

2. ノードは、近くの DODAG の初期プローブとして 1 つ以上の DIS メッセージ（オプションで、特定の DODAG の DIO を要求）を送信することを決定し、設定可能な期間後に DIO メッセージの応答がない場合、ノードはフローティング DODAG をルート化し、マルチキャスト DIO メッセージの送信を開始することを決定する場合があります。

RPL 実装は、必要なパラメータ（2 番目のモードの場合：DIS メッセージの数と関連タイマー）とともに、上記の優先動作モードを構成できるようにすべきです（SHOULD）。

18.2.2. DIO および DAO 基本メッセージとオプションの構成

RPL は、使用されるアプリケーションの広いスペクトルを考慮して、多数のプロトコルパラメータを指定します。そうは言っても、各 RPL ルーターで構成する必要があるこれらのパラメータの数を制限することに特に注意が払われています。代わりに、多数のデフォルト値を使用でき、必要に応じてこれらのパラメータを DODAG ルートから提供できるため、動的なパラメータ設定が可能になります。

RPL 実装は、次のルーティングプロトコルパラメータを構成できるようにすべきです（SHOULD）。上記のように、DODAG ルートには多数のパラメータセットが構成されていることに注意してください。

18.2.3. LLN 内のすべてのルーターで構成されるプロトコルパラメータ

RPL 実装は、次の RPL パラメータを構成できるようにしなければなりません（MUST）：

• RPLInstanceID [DIO メッセージ、DIO 基本メッセージ内]。RPLInstanceID は DODAG ルートで構成する必要がありますが、ノードが特定の DODAG に参加すべきかどうかを判断するために、すべてのノードでポリシーとして構成する必要もあります。ノードがフローティング DODAG のルートになる場合に備えて、2 つ目の RPLInstanceID をノードで構成できることに注意してください。

• サポートされている目的コードポイント（OCP）のリスト

• サポートされているメトリックのリスト：[RFC6551] は、DODAG 形成に使用される多数のメトリックと制約を指定しています。したがって、RPL 実装は、ノードが受け入れて理解できるメトリックのリストを構成できるようにすべきです。セクション 8.5 で指定されているように、理解またはサポートされていないメトリックや制約を含む DIO を受信した場合、ノードはリーフノードとして参加します。

• プレフィックス情報、および有効寿命と推奨寿命、'L' フラグと 'A' フラグ。[DIO メッセージ、プレフィックス情報オプション]。RPL 実装は、自動構成のためにプレフィックス情報を配布するために、プレフィックス情報オプションを DIO メッセージと一緒に運ぶ必要があるかどうかを構成できるようにすべきです（SHOULD）。その場合、RPL 実装は、対応するフラグとともに PIO で通知されるプレフィックスのリストを許可しなければなりません（MUST）。

• 要請情報 [DIS メッセージ、要請情報オプション内]。RPL 実装は、そのようなメッセージをいつ、どのような状況で送信するか、および RPLInstance ID、'V'/'I'/'D' フラグの値を構成できるようにすべきであることに注意してください（SHOULD）。

• 'K' フラグ：ノードが DAO メッセージで 'K' フラグを設定すべき場合 [DAO メッセージ、DAO 基本メッセージ内]。

• MOP（動作モード）[DIO メッセージ、DIO 基本メッセージ内]。

• ルート情報（および優先度）[DIO メッセージ、ルート情報オプション内]

18.2.4. LLN 内のすべての非 DODAG ルートルーターで構成されるプロトコルパラメータ

RPL 実装は、ターゲットプレフィックス [DAO メッセージ、RPL ターゲットオプション内] を構成できるようにしなければなりません（MUST）。

さらに、ノードがターゲットの特定の処理（優先順位付けなど）を可能にするためにターゲットを指定したい状況があります。このような処理ルールは、この仕様の範囲外です。使用する場合、RPL 実装は、ターゲットごとのベースで（たとえば、アクセスリストを使用して）ターゲット記述子を構成できるようにすべきです（SHOULD）。

DODAG 親セットが空のノードは、フローティング DODAG の DODAG ルートになる場合があります。また、DAGPreference を設定して、優先順位を低くすることもできます。したがって、RPL 実装は、この場合にノードが開始すべきアクションのセットを構成できるようにしなければなりません（MUST）：

• 独自の（フローティング）DODAG を開始する：DAGPreference に加えて、新しい DODAGID を構成する必要があります。

• 壊れたパスをポイズニングする（セクション 8.2.2.5 の手順を参照）。

• ローカル修復をトリガーする。

18.2.5. DODAG ルートで構成されるパラメータ

さらに、他のいくつかのパラメータは DODAG ルートでのみ構成され、DIO メッセージで運ばれるオプションで通知されます。

セクション 8.3 で指定されているように、RPL 実装は Trickle タイマーを使用して DIO メッセージの送信を制御します。Trickle アルゴリズムの動作は、構成可能なパラメータのセットによって決定されます。これらのパラメータは構成可能でなければならず（MUST）、DODAG ルートによって DIO メッセージで DODAG に沿って通知されます。

• DIOIntervalDoublings [DIO メッセージ、DODAG 構成オプション内]

• DIOIntervalMin [DIO メッセージ、DODAG 構成オプション内]

• DIORedundancyConstant [DIO メッセージ、DODAG 構成オプション内]

さらに、RPL 実装は、次の RPL パラメータセットの構成を可能にすべきです（SHOULD）：

• パス制御サイズ [DIO メッセージ、DODAG 構成オプション内]

• MinHopRankIncrease [DIO メッセージ、DODAG 構成オプション内]

• DODAGPreference フィールド [DIO メッセージ、DIO 基本オブジェクト]

• DODAGID [DIO メッセージ、DIO 基本オプション内] および [DAO メッセージ、DAO メッセージの 'D' フラグが設定されている場合]

DAG ルートの動作：場合によっては、ノードが接地 DODAG に参加できない場合、フローティング DODAG ルートとして永続的に機能したくないことがあります。たとえば、バッテリー駆動のノードは、長期間フローティング DODAG ルートとして機能したくない場合があります。したがって、RPL 実装は、構成された期間、ノードがフローティング DODAG ルートとして機能できるかどうかを構成する機能をサポートしてもよいです（MAY）。

DAG バージョン番号の増分：RPL 実装では、DODAG ルートでの構成により、DODAGVersionNumber を更新することで DODAG 状態を更新できる場合があります。RPL 実装は、DODAG ルートが DODAGVersionNumber の変更（セクション 3.2.2 で指定されているグローバル修復をトリガーする）を制御するために周期的またはイベントトリガーメカニズムを使用するかどうかを構成できるようにすべきです（SHOULD）。

18.2.6. DAO ベースのメカニズムに関連する RPL パラメータの構成

DAO メッセージはオプションであり、下向きルーティング操作を必要とする DODAG で使用されます。このセクションでは、DAO メッセージに関連するパラメータのセットを扱い、その構成に関する推奨事項を提供します。

セクション 9.5 で述べられているように、ルート集約を実行する機会を最大化するために、DAO 親への DAO メッセージの送信を遅らせることをお勧めします。DAO メッセージを受信すると、ノードは DelayDAO タイマーを開始する必要があります。デフォルト値は DEFAULT_DAO_DELAY です。RPL 実装は、DelayDAO タイマーの構成を許可してもよいです（MAY）。

格納モードの動作では、格納ノードは、ルーチンルーティングテーブルの更新とメンテナンスの一部として、直下の子供からの DAO 更新のセットを確実にトリガーするために DTSN をインクリメントする場合があります。RPL 実装は、DTSN インクリメントのトリガー（手動またはイベントベース）を指定するルールのセットの構成を許可してもよいです（MAY）。

DAO エントリがタイムアウトまたは無効になった場合、ノードは各 DAO 親に No-Path を報告するための合理的な試みを行うべきです（SHOULD）。その試行回数は構成可能であってもよいです（MAY）。

実装は、DAO メッセージの送信のレート制限をサポートする必要があります。関連するパラメータは構成可能であってもよいです（MAY）。

18.2.7. セキュリティメカニズムに関連する RPL パラメータの構成

セクション 10 で説明されているように、このドキュメントで説明されているセキュリティ機能の実装はオプションであり、特定の実装は、説明されているセキュリティ機能のサブセット（空のセットを含む）をサポートする場合があります。

この目的のために、説明されているセキュリティ機能をサポートする実装は、概念的にセキュリティポリシーデータベースを実装する場合があります。セキュリティメカニズムをサポートするために、RPL 実装は、次のパラメータのサブセットの構成を許可すべきです（SHOULD）：

• 受け入れられるセキュリティモード [非セキュアモード、プレインストールモード、認証モード]

• 受け入れられる KIM 値 [セキュア RPL 制御メッセージ、セキュリティセクション内]

• 受け入れられるレベル値 [セキュア RPL 制御メッセージ、セキュリティセクション内]

• 受け入れられるアルゴリズム値 [セキュア RPL 制御メッセージ、セキュリティセクション内]

• 認証モードまたはプレインストールキーモードをサポートするキーマテリアル。

さらに、RPL 実装は、次のパラメータのサブセットを使用して DODAG ルートを構成できるようにすべきです（SHOULD）：

• 通知されるレベル値 [セキュア DIO メッセージ、セキュリティセクション内]

• 通知される KIM 値 [セキュア DIO メッセージ、セキュリティセクション内]

• 通知されるアルゴリズム値 [セキュア DIO メッセージ、セキュリティセクション内]

18.2.8. デフォルト値

このドキュメントでは、次の RPL 変数のセットのデフォルト値を指定しています：

• DEFAULT_PATH_CONTROL_SIZE
• DEFAULT_DIO_INTERVAL_MIN
• DEFAULT_DIO_INTERVAL_DOUBLINGS
• DEFAULT_DIO_REDUNDANCY_CONSTANT
• DEFAULT_MIN_HOP_RANK_INCREASE
• DEFAULT_DAO_DELAY

プロトコルでデフォルト値を指定することをお勧めします。そうは言っても、[RFC5706] で説明されているように、デフォルト値はますます意味をなさなくなる可能性があります。RPL は、ノードの数やリンク、ノードの種類などのネットワーク特性が大幅に異なると予想される多くのコンテキストで使用されることが予想されるルーティングプロトコルです。したがって、これらのデフォルト値は、コンテキストやテクノロジーの進化とともに変化する可能性があります。実際、LLN 関連のテクノロジー（ハードウェア、リンク層など）は過去数年間で劇的に進化しており、そのようなテクノロジーは今後数年間で大幅に変化および進化すると予想されます。

提案された値は、広範な現在のベストプラクティスに基づいているわけではなく、保守的であると考えられています。

18.3. RPL 動作の監視

ルーティングプロトコルとネットワーク自体の正しい動作を確認するために、いくつかの RPL パラメータを監視する必要があります。このセクションでは、関心のある監視パラメータのセットをリストします。

18.3.1. DODAG パラメータの監視

RPL 実装は、次のパラメータに関する情報を提供すべきです（SHOULD）：

• DODAG バージョン番号 [DIO メッセージ、DIO 基本メッセージ内]

• 'G' フラグのステータス [DIO メッセージ、DIO 基本メッセージ内]

• MOP フィールドのステータス [DIO メッセージ、DIO 基本メッセージ内]

• DTSN の値 [DIO メッセージ、DIO 基本メッセージ内]

• ランクの値 [DIO メッセージ、DIO 基本メッセージ内]

• DAOSequence：一意の DAO メッセージごとにインクリメントされ、DAO-ACK メッセージでエコーされます [DAO および DAO-ACK メッセージ]

• ルート情報 [DIO メッセージ、ルート情報オプション]（寿命と優先度を含む親ごとの IPv6 プレフィックスのリスト]

• Trickle パラメータ：

  • DIOIntervalDoublings [DIO メッセージ、DODAG 構成オプション内]
  • DIOIntervalMin [DIO メッセージ、DODAG 構成オプション内]
  • DIORedundancyConstant [DIO メッセージ、DODAG 構成オプション内]

• パス制御サイズ [DIO メッセージ、DODAG 構成オプション内]

• MinHopRankIncrease [DIO メッセージ、DODAG 構成オプション内]

DODAG ルートでのみ監視できる値：

• 転送情報 [DAO、転送情報オプション]：RPL 実装は、受信した転送情報オプションのセットを DODAG ルートに表示するかどうかを構成できるようにすべきです（SHOULD）。この場合、受信した転送情報の RPL データベースには、パスシーケンス、パス制御、パス寿命、および親アドレスも含める必要があります。

18.3.2. DODAG の不整合とループ検出の監視

DODAG の不整合の検出は、RPL ネットワークにおいて特に重要です。したがって、RPL 実装には適切な監視ツールを提供することをお勧めします。RPL 実装は、ノードが DODAG 親に関して不整合を検出した回数（たとえば、DODAGID が変更された場合など）を報告するカウンターを提供すべきです（SHOULD）。

可能であれば、不整合検出に関するより詳細な情報を提供する必要があります。RPL 実装は、次の不整合の数を報告するカウンターを提供してもよいです（MAY）：

• ランクが高いノードから 'O' ビットが設定された（下向き）パケットを受信

• ランクが低いノードから 'O' ビットがクリアされた（上向き）パケットを受信

• 'F' ビットが設定されたパケットの数

• 'R' ビットが設定されたパケットの数

18.4. RPL データ構造の監視

18.4.1. 候補ネイバーデータ構造

候補ネイバーリスト内のノードは、同じ手段で発見され、（十分に高いローカル信頼度で）潜在的に親になる資格のあるノードです。RPL 実装は、いくつかのメトリックによって測定されるローカル信頼度（ネイバーの安定度）を反映するいくつかのメトリックを使用して、候補ネイバーリストを監視できるようにする方法を提供すべきです（SHOULD）。

RPL 実装は、候補ネイバーの数が最大許可値を超えた場合に、候補ネイバーが無視された回数を報告するカウンターを提供してもよいです（MAY）。

18.4.2. 宛先指向有向非巡回グラフ（DODAG）テーブル

各 DODAG について、RPL 実装は次の DODAG テーブル値を追跡することが期待されます：

• RPLInstanceID

• DODAGID

• DODAGVersionNumber

• ランク

• 目的コードポイント

• DODAG 親のセット

• DODAG に沿って上向きに提供されるプレフィックスのセット

• DODAG の DIO メッセージの送信を制御するために使用される Trickle タイマー

• DAO 親のリスト

• DTSN

• ノードステータス（ルーター対リーフ）

RPL 実装は、上記のパラメータセットの監視を許可すべきです（SHOULD）。

18.4.3. ルーティングテーブルと DAO ルーティングエントリ

RPL 実装は、DODAG および DAO エントリ（格納ノード用）に関連するいくつかの情報要素を維持します。非格納ノードの場合、維持される情報の量は限られています（ルーティングテーブルは、上記のように DODAG の特性とともに DODAG 親のセットにほぼ縮小されます）。一方、格納ノードの場合、この情報はルーティングエントリで拡張されます。

RPL 実装は、次のパラメータを監視できるようにすべきです（SHOULD）：

• ネクストホップ（DODAG 親）

• ネクストホップインターフェイス

• 各 DODAG 親のパスメトリック値

DAO ルーティングテーブルエントリには、概念的に次の要素が含まれています（格納ノードのみ）：

• 広告ネイバー情報

• IPv6 アドレス

• このエントリが報告された DAO 親のインターフェイス ID

• 再試行カウンター

• DAO コンテンツの論理的等価物：

  • DAO-Sequence
  • パスシーケンス
  • DAO 寿命
  • DAO パス制御

• 宛先プレフィックス（またはアドレスまたはマルチキャストグループ）

RPL 実装は、各 DAO ルーティングテーブルエントリの状態に関する情報を提供すべきです（SHOULD）。

18.5. 障害管理

障害管理は、トラブルシューティング、プロトコルの正しい動作モードの検証、およびネットワーク設計に使用される重要なコンポーネントです。また、ネットワークパフォーマンス監視の重要なコンポーネントでもあります。RPL 実装は、障害管理に関連する次の情報の提供を許可すべきです（SHOULD）：

• メモリオーバーフローと原因（ルーティングテーブルのオーバーフローなど）

• 有効としてフラグが立てられた DODAG 親にパケットを送信できなかった回数

• ルーターが対応する RPLInstanceID を持っていないパケットを受信した回数

• ローカル修復手順がトリガーされた回数

• DODAG ルートによってグローバル修復がトリガーされた回数

• 受信した不正なメッセージの数

• 転送するパケットがあるがネクストホップ（DODAG 親）がない秒数

• ネクストホップ（DODAG 親）がない秒数

• 理解できないメトリック/制約を含む DIO を受信し、この場合にリーフノードとして参加するように構成されていたために、ノードがリーフとして DODAG に参加した回数（セクション 18.6 を参照）

少なくともエラーログメッセージを介して障害を報告することをお勧めします。他のプロトコルを使用して、そのような障害を報告することもできます。

18.6. ポリシー

ポリシー・ルールは、ノードが DIO メッセージによってネイバーによって通知された特定の DODAG に参加することを許可されるかどうかを判断するために、RPL 実装によって使用できます。

このドキュメントでは、単一の DODAG 内の動作を指定します。DODAG は、次のタプル (RPLInstanceID, DODAGID) によって特徴付けられます。さらに、上記のように、DIO メッセージは、DODAG の構築に使用されるルーティングメトリックと制約、および使用中の目的関数（OCP で指定）など、他の DODAG 特性を通知するために使用されます。

最初のポリシールールは、RPL ノードが DODAG に参加するために満たす必要がある次の条件を指定することで構成されます：

• RPLInstanceID

• サポートされているルーティングメトリックと制約のリスト

• 目的関数（OCP 値）

RPL 実装は、これらのパラメータを構成できるようにしなければならず（MUST）、通知された DODAG がローカルポリシーに準拠していない場合にノードが DIO を単に無視すべきか、それともサポートされているルーティングメトリックと制約のリストのみ、および OF がサポートされていない場合にノードがリーフノードとして参加すべきかを指定すべきです（SHOULD）。さらに、RPL 実装は、ポリシーの一部として DODAGID の追加を許可すべきです（SHOULD）。

RPL 実装は、ノードが DODAG に参加するために、目的コードポイント（OCP）によって参照される許容または優先される目的関数（OF）のセットを構成できるようにすべきであり（SHOULD）、ノードの候補ネイバーのいずれも構成された許容目的関数の 1 つを通知しない場合、または通知されたメトリック/制約が理解/サポートされていない場合にどのようなアクションを取るべきかを構成できるようにすべきです。この場合、次の 2 つのアクションを取ることができます：

• ノードは、セクション 8.5 で指定されているように、リーフノードとして DODAG に参加します。

• ノードは DODAG に参加しません。

LLN 内のノードは、RPL を含むさまざまなルーティングプロトコルからルーティング情報を学習する場合があります。この場合、管理上の優先順位によって、どのルートを優先するかを制御することが望ましいです。実装は、ルートが学習されたルーティングプロトコルの管理上の優先順位の指定を許可すべきです（SHOULD）。

内部データ構造：一部の RPL 実装では、メモリ使用量を制限するために候補ネイバーリストのサイズを制限する場合があります。その場合、実行可能な候補ネイバーが考慮されず、候補ネイバーリストから単に削除される場合があります。

RPL 実装は、候補ネイバーリストのサイズのインジケーターを提供してもよいです（MAY）。

18.7. 障害分離

不正なメッセージを許容できないレートで放出し始めたネイバーを隔離することをお勧めします。

18.8. 他のプロトコルへの影響

RPL は、他のプロトコルへの影響が非常に限られています。LBR など、ルーターで複数のルーティングプロトコルが必要な場合、デバイスは、2 つのルーティングドメイン間の到達可能性を可能にするために、ルーティングプロトコル間のルーティング再配布機能をサポートすることが期待されます。このような再配布は、ユーザー構成可能なポリシーの使用によって管理されるべきです（SHOULD）。

ネットワーク上のトラフィックへの影響に関しては、RPL は、Trickle タイマー（セクション 8.3）などのメカニズムのおかげで制御トラフィックを制限するように設計されています。したがって、RPL が他のプロトコルに与える影響は極めて限定的であるはずです。

18.9. パフォーマンス管理

パフォーマンス管理は常にプロトコルの重要な側面であり、RPL も例外ではありません。IP パフォーマンス監視（IPPM）ワーキンググループによって、いくつかの関心のあるメトリックが指定されています。そうは言っても、デバイス上のリソースと必要な帯域幅の観点からこれらのメトリックを監視するコストを考慮すると、LLN に適用することはほとんどありません。それでも、RPL 実装はこれらのいくつかをサポートしてもよく（MAY）、その他の関心のあるパラメータを以下に示します：

• 修復の数と修復時間（秒）（平均、分散）

• ルーティングテーブルに到達可能なネイバーがないためにデバイスがパケットを転送できなかった回数と期間

• 帯域幅と必要なメモリの観点からの RPL によるリソース消費の監視

• 送受信された RPL 制御メッセージの数

18.10. 診断

診断を改善するために、ノードを「詳細」モードにする必要がある状況がある場合があります。したがって、RPL 実装は、追加の診断情報を取得するために、ノードを詳細モードにしたり、詳細モードから解除したりする機能を提供すべきです（SHOULD）。