1. はじめに
低電力で損失の多いネットワーク（LLN）は、主に制約のあるノード（処理能力、メモリが限られており、バッテリー駆動またはエネルギー収穫の場合はエネルギーも限られている）で構成されています。これらのルーターは、通常、低いデータレートのみをサポートし、パケット配信率が比較的低く不安定な損失の多いリンクによって相互接続されています。このようなネットワークのもう1つの特徴は、トラフィックパターンが単純なポイントツーポイントではなく、多くの場合、ポイントツーマルチポイントまたはマルチポイントツーポイントであることです。さらに、このようなネットワークは、最大数千のノードで構成される可能性があります。これらの特性は、ルーティングソリューションに独自の課題をもたらします。IETF ROLLワーキンググループは、[RFC5867]、[RFC5826]、[RFC5673]、および[RFC5548]で指定されているように、低電力で損失の多いネットワーク（LLN）ルーティングプロトコルのアプリケーション固有のルーティング要件を定義しました。
このドキュメントでは、LLN用のIPv6ルーティングプロトコル（RPL）を指定します。RPLは前述の要件ドキュメントに記載されている要件に従って指定されましたが、その使用はこれらのアプリケーションに限定されるものではないことに注意してください。
1.1. 設計原則
RPLは、[RFC5867]、[RFC5826]、[RFC5673]、および[RFC5548]に記載されている要件を満たすことを目的として設計されました。
ネットワークは、複数のRPLインスタンスを同時に実行できます。そのような各インスタンスは、異なる、場合によっては相反する制約またはパフォーマンス基準に役立つ場合があります。このドキュメントでは、単一のインスタンスがどのように動作するかを定義します。
幅広いLLNアプリケーションドメインで役立つように、RPLはパケット処理と転送をルーティング最適化の目的から分離します。このような目的の例には、エネルギーの最小化、遅延の最小化、または制約の充足が含まれます。このドキュメントでは、RPLの動作モードについて説明します。他のコンパニオンドキュメントでは、ルーティング目的関数を指定しています。特定のLLNアプリケーションをサポートするRPL実装には、アプリケーションの必要に応じて必要な目的関数が含まれます。
RPL操作には双方向リンクが必要です。一部のLLNシナリオでは、これらのリンクが非対称のプロパティを示す場合があります。ルーターを親として使用する前に、ルーターの到達可能性を確認する必要があります。RPLは、リンクプロパティとネイバーの到達可能性を確認するために、親の選択フェーズ中に外部メカニズムがトリガーされることを期待しています。近隣到達不能検出（NUD）はそのようなメカニズムですが、双方向転送検出（BFD）[RFC5881]や[RFC5184]のようなレイヤー2（L2）トリガーによる下位レイヤーからのヒントなど、代替手段も可能です。一般的に、使用されていないリンクを監視するコストを最小限に抑えるために、トラフィックに反応する検出メカニズムが推奨されます。
RPLはまた、データパケット内の「RPLパケット情報」と呼ばれるいくつかの制御情報にアクセスして転送するための外部メカニズムを期待しています。RPLパケット情報はセクション11.2で定義されており、データパケットをRPLインスタンスに関連付け、RPLルーティング状態を検証できます。RPLオプション[RFC6553]は、そのようなメカニズムの例です。厳密なソースルーティングが使用される場合（つまり、セクション9で詳しく説明されている非格納モードで下向きに移動するパケットの場合）を除き、すべてのパケットにメカニズムが必要です。これは本質的に無限ループを防ぎ、RPLパケット情報の必要性を軽減します。将来のコンパニオン仕様では、IPv6パケットでRPLパケット情報を運ぶための代替方法が提案され、RPLパケット情報を拡張して追加機能をサポートする可能性があります。
RPLは、動的に形成されたネットワークトポロジ全体に情報を配布するメカニズムを提供します。この配布により、ノードでの構成が最小限に抑えられ、ノードがほぼ自律的に動作できるようになります。このメカニズムは、セクション8.3で説明されているように、Trickle [RFC6206]を使用して配布を最適化します。
一部のアプリケーションでは、RPLは独立したプレフィックスを所有するルーターのトポロジを組み立てます。これらのプレフィックスは、ルーターの起源に応じて集約可能な場合とそうでない場合があります。ルーターが所有するプレフィックスは、オンリンクとしてアドバタイズされます。
RPLは、サブネットを共通のプレフィックスと結合し、そのサブネット内でルーティングする機能も導入しています。ソースは、RPLによって配布されるサブネットに関する情報を注入でき、そのソースはそのサブネットに対して権威があります。多くのLLNリンクには非推移的なプロパティがあるため、RPLがサブネット全体に配布する共通プレフィックスは、オンリンクとしてアドバタイズしてはなりません。
特に、RPLは、[RFC4861]プレフィックス情報オプション（PIO）や[RFC4191]ルート情報オプション（RIO）などのIPv6近隣探索（ND）情報を配布する場合があります。RPLによって配布されるND情報は、ルーターからホストへの元のセマンティクスをすべて保持し、ルーターからルーターへの拡張は制限されていますが、ルーティングアドバタイズメントと混同してはならず、別のルーティングプロトコルで直接再配布してはなりません。RPLノードは、多くの場合、ホストとルーターの動作を組み合わせます。ホストとして、[RFC4191]、[RFC4861]、[RFC4862]、および[RFC6275]で指定されているオプションを処理します。ルーターとして、RPLノードは、特定のリンクに必要なオプションからの情報をアドバタイズする場合があります。たとえば、NDルーターアドバタイズメント（RA）メッセージなどですが、正確な操作は範囲外です。
この仕様の一連のコンパニオンドキュメントは、ビルディングオートメーション、ホームオートメーション、産業、および都市のアプリケーションシナリオに適した一連の動作点を指定する適用性ステートメントの形式で、さらなるガイダンスを提供します。
1.2. リンク層タイプへの期待
IPの階層化アーキテクチャに準拠して、RPLは特定のリンク層技術の特定の機能に依存しません。RPLは、低電力無線やPLC（電力線通信）技術など、制約のある、潜在的に損失のある、または通常は高度に制約のあるホストまたはルーターデバイスと組み合わせて利用されるものを含む、さまざまな異なるリンク層で動作するように設計されています。
実装者は、RPLと特定のリンク層技術の間のリンク層インターフェースを設計する際に、[RFC3819]が有用なリファレンスであることに気付くかもしれません。