[要約] RFC 6552は、低消費電力かつ損失の多いネットワーク（RPL）のためのルーティングプロトコルのゼロ目的関数に関するものです。このRFCの目的は、RPLノードが最適な経路を選択するための目的関数の定義と動作を提供することです。
Internet Engineering Task Force (IETF) P. Thubert, Ed.
Request for Comments: 6552 Cisco Systems
Category: Standards Track March 2012
ISSN: 2070-1721
Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL)
低電力および損失ネットワークのルーティングプロトコルの目的関数ゼロ（RPL）
Abstract
概要
The Routing Protocol for Low-Power and Lossy Networks (RPL) specification defines a generic Distance Vector protocol that is adapted to a variety of network types by the application of specific Objective Functions (OFs). An OF states the outcome of the process used by a RPL node to select and optimize routes within a RPL Instance based on the Information Objects available; an OF is not an algorithm.
低電力および損失ネットワーク（RPL）仕様のルーティングプロトコルは、特定の目的関数（OF）を適用することにより、さまざまなネットワークタイプに適合した一般的な距離ベクトルプロトコルを定義します。ANは、利用可能な情報オブジェクトに基づいてRPLインスタンス内のルートを選択および最適化するためにRPLノードによって使用されるプロセスの結果を述べています。のはアルゴリズムではありません。
This document specifies a basic Objective Function that relies only on the objects that are defined in the RPL and does not use any protocol extensions.
このドキュメントは、RPLで定義され、プロトコル拡張機能を使用しないオブジェクトにのみ依存する基本的な目的関数を指定します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6552.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6552で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントは必須です
include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、簡素化されたBSDライセンスに記載されている保証なしで提供される簡略化されたBSDライセンステキストを含めます。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................4
3. Objective Function Zero Overview ................................4
4. OF0 Operations ..................................................5
4.1. Computing Rank .............................................5
4.2. Parent Selection ...........................................7
4.2.1. Selection of the Preferred Parent ...................7
4.2.2. Selection of the Backup Feasible Successor ..........8
5. Abstract Interface to OF0 .......................................9
6. OF0 Operands ....................................................9
6.1. Variables ..................................................9
6.2. Configurable Parameters ...................................10
6.3. Constants .................................................10
7. Manageability Considerations ...................................10
7.1. Device Configuration ......................................11
7.2. Device Monitoring .........................................11
8. IANA Considerations ............................................12
9. Security Considerations ........................................12
10. Acknowledgements ..............................................12
11. References ....................................................13
11.1. Normative References .....................................13
11.2. Informative References ...................................13
The Routing Protocol for Low-Power and Lossy Networks (RPL) specification [RFC6550] defines a generic Distance Vector protocol that is adapted to a variety of Low-Power and Lossy Network (LLN) types by the application of specific Objective Functions (OFs).
低電力および損失ネットワーク（RPL）仕様のルーティングプロトコル[RFC6550]は、特定の目的関数（OFS）の適用により、さまざまな低電力および損失のあるネットワーク（LLN）タイプに適合した一般的な距離ベクトルプロトコルを定義します。。
A RPL OF states the outcome of the process used by a RPL node to select and optimize routes within a RPL Instance based on the Information Objects available. As a general concept, an OF is not an algorithm. For example, outside RPL, "shortest path first" is an OF where the least cost path between two points is derived as an outcome; there are a number of algorithms that can be used to satisfy the OF, of which the well-known Dijkstra algorithm is an example.
RPLのRPLは、RPLノードで使用されるプロセスの結果を、利用可能な情報オブジェクトに基づいてRPLインスタンス内でルートを選択および最適化するために使用されます。一般的な概念として、OFはアルゴリズムではありません。たとえば、RPLの外側では、「最短パスファースト」とは、2つのポイント間の最小コストパスが結果として導出される場合です。よく知られているDijkstraアルゴリズムがその例であることを満たすために使用できる多くのアルゴリズムがあります。
The separation of OFs from the core protocol specification allows RPL to be adapted to meet the different optimization criteria required by the wide range of deployments, applications, and network designs.
コアプロトコル仕様からのOFSの分離により、RPLは、幅広い展開、アプリケーション、およびネットワーク設計に必要なさまざまな最適化基準を満たすように適合させることができます。
RPL forms Directed Acyclic Graphs (DAGs) as collections of Destination-Oriented DAGs (DODAGs) within instances of the protocol. Each instance is associated with a specialized Objective Function. A DODAG is periodically reconstructed as a new DODAG Version to enable a global reoptimization of the graph.
RPLは、プロトコルのインスタンス内で、宛先指向のDAG（DODAG）のコレクションとして、非環式グラフ（DAG）を形成します。各インスタンスは、特殊な目的関数に関連付けられています。ドーダグは、グラフのグローバルな再最適化を有効にするために、新しいDODAGバージョンとして定期的に再構築されます。
An instance of RPL running on a device uses an Objective Function to help it determine which DODAG and which Version of that DODAG it should join. The OF is also used by the RPL Instance to select a number of routers within the DODAG current and subsequent Versions to serve as parents or as feasible successors.
デバイスで実行されているRPLのインスタンスは、目的関数を使用して、どのドーダグとそのドーダグのバージョンを結合するかを判断するのに役立ちます。OFは、RPLインスタンスでも使用され、DODAG電流および後続のバージョン内の多くのルーターを選択して、親として、または実行可能な後継者として機能します。
The RPL Instance uses the OF to compute a Rank for the device. This value represents an abstract distance to the root of the DODAG within the DODAG Version. The Rank is exchanged between nodes using RPL and allows other RPL nodes to avoid loops and verify forward progression toward the destination, as specified in [RFC6550]. Regardless of the particular OF used by a node, Rank will always increase; thus, post convergence, loop-free paths are always formed.
RPLインスタンスは、OFを使用してデバイスのランクを計算します。この値は、DODAGバージョン内のドーダグのルートまでの抽象的な距離を表します。ランクはRPLを使用してノード間で交換され、[RFC6550]で指定されているように、他のRPLノードがループを回避し、宛先への前方進行を検証することができます。ノードで使用される特定に関係なく、ランクは常に増加します。したがって、収束後、ループフリーパスは常に形成されます。
The Objective Function Zero (OF0) operates on parameters that are obtained from provisioning, the RPL DODAG Configuration option and the RPL DODAG Information Object (DIO) base container [RFC6550].
目的関数ゼロ（OF0）は、プロビジョニング、RPL DODAG構成オプション、およびRPL DODAG情報オブジェクト（DIO）ベースコンテナ[RFC6550]から取得されるパラメーターで動作します。
The Rank of a node is obtained by adding a strictly positive, indirectly normalized scalar, rank_increase (Section 6.1), to the Rank of a selected preferred parent. The rank_increase is based on a step_of_rank (Section 6.1) normalized scalar that can vary with a ratio from 1 (excellent) to 9 (worst acceptable) to represent the link properties. The step_of_rank can be multiplied by a configurable factor called rank_factor (Section 6.2) that amplifies the rank_increase to reflect the relative preferences between different link types that would be used in the same RPL Instance. The rank_increase can be further adapted as detailed in Section 4.1. By default, OF0 encodes the 2-octet Rank in units of 256, and the default settings allow for the encoding of a minimum of 28 (worst acceptable) hops and a maximum of 255 (excellent) hops.
ノードのランクは、選択された優先親のランクに、厳密に正の正規化されたスカラー（セクション6.1）を追加することによって取得されます。rank_increaseは、リンクプロパティを表すために1（優れた）から9（最悪の許容可能）までの比率で変化する可能性のあるstep_of_rank（セクション6.1）正規化されたスカラーに基づいています。STEP_OF_RANKは、同じRPLインスタンスで使用される異なるリンクタイプ間の相対的な好みを反映するために、rank_factor（セクション6.2）と呼ばれる構成可能な係数（セクション6.2）を掛けることができます。RANK_INCREASEは、セクション4.1で詳述されているようにさらに調整できます。デフォルトでは、OF0は256のユニットで2-OCTETランクをエンコードし、デフォルト設定では、最低28（最悪の許容）ホップと最大255（優れた）ホップのエンコードが可能になります。
The RPL specification [RFC6550] requires the use of a common OF by all nodes in a network. The possible use of multiple OFs with a single network is for further study.
RPL仕様[RFC6550]には、ネットワーク内のすべてのノードによって共通の使用が必要です。単一のネットワークで複数のオブスを使用する可能性は、さらなる研究のためです。
The RPL specification [RFC6550] does not include any OF definitions. This is left for other documents specific to different deployments and application environments. Since there is no default OF or metric container in the RPL main specification, it might happen that, unless
RPL仕様[RFC6550]には、定義のいずれも含まれていません。これは、さまざまな展開とアプリケーション環境に固有の他のドキュメントに残されています。RPLメイン仕様にはデフォルトまたはメトリックコンテナがないため、それが起こる可能性があります。
two given implementations follow the same guidance for a specific problem or environment, those implementations will not support a common OF with which they could interoperate.
特定の問題や環境の同じガイダンスに従っている2つの実装は、それらの実装が相互運用できる共通点をサポートしません。
OF0 is designed as a default OF that will allow interoperation between implementations in a wide spectrum of use cases. This is why OF0 does not specify how the link properties are transformed into a rank_increase and leaves that responsibility to the implementation; rather, OF0 enforces the values for the rank_increase by normalizing the step_of_rank for a normal link and its acceptable range, as opposed to formulating the details of the step_of_rank computation. This is also why OF0 ignores metric containers.
OF0は、デフォルトとして設計されており、幅広いユースケースでの実装間の相互操作を可能にします。これが、OF0がリンクプロパティがRANK_INCREASEにどのように変換され、その責任を実装に任せる方法を指定しない理由です。むしろ、OF0は、step_of_rank計算の詳細を策定するのではなく、通常のリンクとその許容範囲のstep_of_rankを正規化することにより、rank_increaseの値を強制します。これが、OF0がメトリックコンテナを無視する理由でもあります。
The terminology used in this document is consistent with and incorporates that described in "Terminology in Low power And Lossy Networks" [ROLL-TERMS] and [RFC6550].
このドキュメントで使用されている用語は、「低電力および損失ネットワークの用語」[Roll-Terms]および[RFC6550]と一致し、組み込まれています。
The term "feasible successor" is used to refer to a neighbor that can possibly be used as a next hop for Upward traffic following the loop avoidance and forwarding rules that the nodes implement and that are defined in the RPL specification [RFC6550].
「実行可能な後継者」という用語は、ループの回避および転送ルールに続く上向きのトラフィックの次のホップとして使用できる隣人を指すために使用され、ノードがRPL仕様[RFC6550]で定義されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
キーワードは「必須」、「必要」、「必須」、「shall」、「shall "、" bood "、" low "of" bould "、" becommended "、" bodement "、" may "、" optional「この文書では、RFC 2119 [RFC2119]に記載されているように解釈されます。
The RPL specification describes constraints on how nodes select potential parents, called a parent set, from their neighbors. All parents are feasible successors for upward traffic (towards the root). Additionally, RPL allows the use of parents in a subsequent Version of a same DODAG as feasible successors, in which case this node acts as a leaf in the subsequent DODAG Version.
RPL仕様は、隣人から親セットと呼ばれる潜在的な親を選択する方法の制約を説明しています。すべての親は、上向きのトラフィック（ルートに向かって）の後継者です。さらに、RPLは、実行可能な後継者と同じDODAGの後続バージョンで親を使用できます。この場合、このノードはその後のDODAGバージョンでリーフとして機能します。
The Goal of the OF0 is for a node to join a DODAG Version that offers good enough connectivity to a specific set of nodes or to a larger routing infrastructure though there is no guarantee that the path will be optimized according to a specific metric. This validation process for the connectivity is implementation and link type dependent and is out of scope. The validation involves but is not limited to application of [RFC6550], Sections 3.2.3 and 13, as appropriate and may involve deployment specific policies as well.
OF0の目標は、特定のメトリックに従ってパスが最適化されるという保証はありませんが、特定のノードまたはより大きなルーティングインフラストラクチャに十分な接続を提供するドーダグバージョンに参加するノードです。接続のためのこの検証プロセスは、実装とリンクタイプの依存であり、範囲外です。検証には、必要に応じて[RFC6550]、セクション3.2.3および13、およびセクション3.2.3および13の適用が含まれますが、これらに限定されません。
Thus, for the purpose of OF0, the term "Grounded" [RFC6550] means that the DODAG root provides such connectivity. How that connectivity is asserted and maintained is out of scope.
したがって、OF0の目的のために、「接地」[RFC6550]という用語は、DODAGルートがそのような接続を提供することを意味します。その接続がどのように主張され、維持されるかは範囲外です。
Objective Function Zero is designed to find the nearest Grounded root. This can be achieved if the Rank of a node is very close to an abstract function of its distance to the root. This need is balanced with the other need of maintaining some path diversity, which may be achieved by increasing the Rank. In the absence of a Grounded root, inner connectivity within the LLN is still desirable and floating DAGs will form, rooted at the nodes with the highest administrative preference.
目的関数ゼロは、最も近い接地されたルートを見つけるように設計されています。これは、ノードのランクがルートまでの距離の抽象関数に非常に近い場合に達成できます。このニーズは、ランクを上げることで達成される可能性のあるパスの多様性を維持する他のニーズとバランスが取れています。接地されたルートがない場合、LLN内の内部接続性が依然として望ましく、浮動的なダグが形成され、最も高い管理選好のノードに根付いています。
OF0 selects a preferred parent and a backup feasible successor if one is available. All the upward traffic is normally routed via the preferred parent with no attempt to perform any load balancing. When the link conditions do not let an upward packet through the preferred parent, the packet is passed to the backup feasible successor.
OF0は、利用可能な場合、優先親とバックアップの実行可能な後継者を選択します。すべての上向きのトラフィックは、通常、荷物のバランスを実行しようとすることなく、優先親を介してルーティングされます。リンク条件が優先親を介して上向きのパケットを許可しない場合、パケットはバックアップの実行可能な後継者に渡されます。
A RPL node monitors links to a number of neighbor nodes and can use OF0 to assign a rank_increase to each link. Though the exact method for computing the rank_increase is implementation dependent, the computation must follow the rules that are specified in Section 4.1.
RPLノードモニターは、多数の隣接ノードにリンクし、各リンクにrank_increaseを割り当てるために0を使用できます。rank_increaseを計算する正確な方法は実装依存ですが、計算はセクション4.1で指定されているルールに従う必要があります。
An OF0 implementation first computes a variable step_of_rank (Section 6.1) associated with a given parent from relevant link properties and metrics. The step_of_rank is used to compute the amount by which to increase the rank along a particular link, as explained later in this section.
OF0の実装は、最初に、関連するリンクプロパティとメトリックから特定の親に関連付けられた変数step_of_rank（セクション6.1）を計算します。STEP_OF_RANKは、このセクションで後で説明するように、特定のリンクに沿ったランクを増やす量を計算するために使用されます。
Computing a step_of_rank based on a static metric such as an administrative cost implies that the OF0 implementation only considers parents with good enough connectivity, and results in a Rank that is analogous to hop-count. In most LLNs, this favors paths with fewer but longer hops of poorer connectivity; it is thus RECOMMENDED to base the computation of the step_of_rank on dynamic link properties such as the expected transmission count (ETX) metric as introduced in [DeCouto03] and discussed in [RFC6551]. "Minimum Rank Objective Function with Hysteresis" [HYSTERESIS] provides guidance on how link cost can be computed and on how hysteresis can improve Rank stability.
管理コストなどの静的メトリックに基づいてSTEP_OF_RANKを計算すると、OF0の実装は、親が十分に接続されていることのみを考慮し、ホップカウントに類似したランクになることを意味します。ほとんどのLLNでは、これは接続性の低下のホップが少ないが長いパスを好みます。したがって、[deCouto03]で導入され、[RFC6551]で説明されている予想伝送カウント（ETX）メトリックなどの動的リンクプロパティのSTEP_OF_RANKの計算を基にすることをお勧めします。「ヒステリシスを備えた最小ランク目標関数」[ヒステリシス]は、リンクコストの計算方法と、ヒステリシスがランクの安定性を改善する方法に関するガイダンスを提供します。
OF0 allows an implementation to stretch the step_of_rank in order to enable the selection of at least one feasible successor and thus maintain path diversity. Stretching the step_of_rank is NOT RECOMMENDED, because it augments the apparent distance from the node to the root, distorts the DODAG from the optimal shape and may cause instabilities due to greedy behaviors whereby depending nodes augment their Ranks to use each other as parents in a loop. Still, an implementation may stretch the step_of_rank with at most a configurable stretch_of_rank (Section 6.2) of any value between 0 (no stretch) and the fixed constant MAXIMUM_RANK_STRETCH (Section 6.3).
OF0を使用すると、実装がSTEP_OF_RANKを伸ばして、少なくとも1つの実行可能な後継者の選択を可能にし、パスの多様性を維持することができます。step_of_rankを伸ばすことは推奨されません。ノードからルートまでの見かけの距離を補強し、ドーダグを最適な形状から歪め、ノードが互いに並んで互いに互いに互いに使用しているのかをループの親として使用する貪欲な行動のために不安定性を引き起こす可能性があるため。それでも、実装は、最大で0（ストレッチなし）と固定定数の最大_rank_stretch（セクション6.3）の間の任意の値の構成可能なstretch_of_rank（セクション6.2）でstep_of_rankを拡張する場合があります。
An implementation MUST maintain the stretched step_of_rank between the fixed constants MINIMUM_STEP_OF_RANK and MAXIMUM_STEP_OF_RANK (Section 6.3). This range allows the reflection of a large variation of link quality.
実装では、固定定数の最小限のstep_of_of_rankとmaximion_step_of_rank（セクション6.3）の間の伸びたstep_of_rankを維持する必要があります。この範囲により、リンク品質の大きなバリエーションを反映できます。
The gap between MINIMUM_STEP_OF_RANK and MAXIMUM_RANK_STRETCH may not be sufficient in every case to strongly distinguish links of different types or categories in order to favor, say, powered over battery-operated or high-speed (wired) over lower-speed (wireless) links, within the same DAG. An implementation SHOULD allow the operator to configure a factor called rank_factor (Section 6.2) and to apply the factor on all links and peers to multiply the effect of the stretched step_of_rank in the rank_increase computation as further detailed below.
Minimum_Step_OF_RANKとMaximing_Rank_Stretchの間のギャップは、あらゆる場合に、バッテリー式または高速（ワイヤレス）リンクよりもバッテリー操作または高速（有線）を支持するために、さまざまなタイプまたはカテゴリのリンクを強く区別するのに十分ではない場合があります。同じダグ内。実装により、オペレーターはrank_factor（セクション6.2）と呼ばれる係数を構成し、すべてのリンクとピアに係数を適用して、以下に詳細に詳述するように、rank_increase計算の伸縮済みstep_of_rankの効果を掛けることができます。
Additionally, an implementation MAY recognize categories of peers and links, such as different link types, in which case it SHOULD be able to configure a more specific rank_factor to those categories. The rank_factor MUST be set between the fixed constants MINIMUM_RANK_FACTOR and MAXIMUM_RANK_FACTOR (Section 6.3).
さらに、実装は、さまざまなリンクタイプなどのピアやリンクのカテゴリを認識する場合があります。RANK_FACTORは、固定定数の最小限_RANK_FACTORとMaximine_Rank_Factor（セクション6.3）の間で設定する必要があります。
The variable rank_increase is represented in units expressed by the variable MinHopRankIncrease, which defaults to the fixed constant DEFAULT_MIN_HOP_RANK_INCREASE ([RFC6550]); with that setting, the least significant octet in the RPL Rank field in the DIO Base Object is not used.
変数rank_increaseは、変数minhoprankincreaseで表される単位で表されます。その設定では、DIOベースオブジェクトのRPLランクフィールドの最も重要なオクテットは使用されません。
The step_of_rank Sp that is computed for that link is multiplied by the rank_factor Rf and then possibly stretched by a term Sr that is less than or equal to the configured stretch_of_rank. The resulting rank_increase is added to the Rank of preferred parent R(P) to obtain that of this node R(N):
そのリンクに対して計算されたstep_of_rank SPには、rank_factor rfを掛け、設定されたstretent_of_rank以下の用語srを拡張する可能性があります。結果のRANK_INCREASEが優先親r（P）のランクに追加され、このノードr（n）のランクを取得します。
R(N) = R(P) + rank_increase where:
r（n）= r（p）rank_increase where：
rank_increase = (Rf*Sp + Sr) * MinHopRankIncrease
Optionally, the administrative preference of a root MAY be configured to supersede the goal to join a Grounded DODAG. In that case, nodes will associate with the root with the highest preference available, regardless of whether or not that root is Grounded. Compared to a deployment with a multitude of Grounded roots that would result in the same multitude of DODAGs, such a configuration may result in possibly less but larger DODAGs, as many as roots configured with the highest priority in the reachable vicinity.
オプションで、ルートの管理選好は、接地されたドーダグに参加するという目標に取って代わるように構成されている場合があります。その場合、ノードは、そのルートが接地されているかどうかに関係なく、利用可能な最高の優先度とルートに関連付けられます。同じ多数のドーダグをもたらす多数の接地された根を持つ展開と比較すると、そのような構成は、到達可能な近くで最高の優先度で構成された根と同じくらい、おそらくより少ないが大きなドーダグをもたらす可能性があります。
As it scans all the candidate neighbors, OF0 keeps the parent that is the best for the following criteria (in order):
すべての候補者の隣人をスキャンすると、OF0は、次の基準に最適な親を保持します（順序で）。
1. [RFC6550], Section 8, spells out the generic rules for a node to re-parent and in particular the boundaries to augment its Rank within a DODAG Version. A candidate that would not satisfy those rules MUST NOT be considered.
1. [RFC6550]、セクション8は、再利用するためのノードの一般的なルール、特にドーダグバージョン内のランクを増強する境界を綴ります。これらのルールを満たさない候補者を考慮してはなりません。
2. Prior to selecting a router as the preferred parent, an implementation SHOULD validate the connectivity and suitability of the router as discussed in Section 3. This validation involves checking the Layer 2 connectivity to the router, the Layer 3 connectivity offered by the router, and may involve examination of other factors such as locally or globally configured policies.
2. ルーターを優先親として選択する前に、実装はセクション3で説明したようにルーターの接続と適合性を検証する必要があります。この検証では、ルーターへのレイヤー2接続、ルーターが提供するレイヤー3接続、および5月に確認することが含まれます。ローカルまたはグローバルに構成されたポリシーなどの他の要因の調査を含みます。
In most cases, a router that does not succeed in the validation process cannot be further considered for selection as preferred parent. In any case, a router that succeeded in that validation process SHOULD be preferred over one that did not succeed.
ほとんどの場合、検証プロセスで成功しないルーターは、優先親として選択のためにさらに考慮することはできません。いずれにせよ、その検証プロセスに成功したルーターは、成功しなかったものよりも優先されるべきです。
3. When multiple interfaces are available, a policy might be locally configured to order them and that policy applies first; that is, a router on a higher-order interface in the policy is preferable.
3. 複数のインターフェイスが利用可能な場合、ポリシーをローカルに構成するように構成されている可能性があり、そのポリシーは最初に適用されます。つまり、ポリシーの高次インターフェイスのルーターが望ましいです。
4. If the administrative preference of the root is configured to supersede the goal to join a Grounded DODAG, a router that offers connectivity to a more preferable root SHOULD be preferred.
4. ルートの管理選好が、接地されたドーダグに参加するという目標に取って代わるように構成されている場合、より好ましいルートへの接続を提供するルーターを優先する必要があります。
5. A router that offers connectivity to a grounded DODAG Version SHOULD be preferred over one that does not.
5. 接地されたドーダグバージョンへの接続を提供するルーターは、そうでないものよりも優先される必要があります。
6. A router that offers connectivity to a more preferable root SHOULD be preferred.
6. より好ましいルートへの接続を提供するルーターを優先する必要があります。
7. When comparing two parents that belong to the same DODAG, a router that offers connectivity to the most recent DODAG Version SHOULD be preferred.
7. 同じドーダグに属する2人の親を比較する場合、最新のドーダグバージョンへの接続を提供するルーターをお勧めします。
8. The parent that causes the lesser resulting Rank for this node, as specified in Section 4.1, SHOULD be preferred.
8. セクション4.1で指定されているように、このノードの結果として生じるランクが少ない親が推奨される必要があります。
9. A DODAG Version for which there is an alternate parent SHOULD be preferred. This check is OPTIONAL. It is performed by computing the backup feasible successor while assuming that the router that is currently examined is finally selected as preferred parent.
9. 代替親が存在するドーダグバージョンを好む必要があります。このチェックはオプションです。現在検査されているルーターが最終的に優先親として選択されていると仮定しながら、バックアップの実行可能な後継者を計算することにより実行されます。
10. The preferred parent that was in use already SHOULD be preferred.
10. すでに使用されていた優先親が推奨されるべきです。
11. A router that has announced a DIO message more recently SHOULD be preferred.
11. 最近DIOメッセージを発表したルーターが優先されるべきです。
These rules and their order MAY be varied by an implementation according to configured policy.
これらのルールとその順序は、構成されたポリシーに従って実装によって変化する場合があります。
When selecting a backup feasible successor, the OF performs in order the following checks:
バックアップの実現可能な後継者を選択するとき、次のチェックを順に実行するものを実行します。
1. The backup feasible successor MUST NOT be the preferred parent.
1. バックアップの実行可能な後継者は、優先親であってはなりません。
2. The backup feasible successor MUST be either in the same DODAG Version as this node or in an subsequent DODAG Version.
2. バックアップの実行可能な後継者は、このノードと同じドーダグバージョンまたは後続のDoDagバージョンのいずれかでなければなりません。
3. Along with RPL rules, a Router in the same DODAG Version as this node and with a Rank that is higher than the Rank computed for this node MUST NOT be selected as a feasible successor.
3. RPLルールに加えて、このノードと同じドーダグバージョンのルーターと、このノードで計算されたランクよりも高いランクを使用して、実行可能な後継者として選択してはなりません。
4. A router with a lesser Rank SHOULD be preferred.
4. より低いランクのルーターが優先される必要があります。
5. A router that has been validated as usable by an implementation-dependent validation process SHOULD be preferred.
5. 実装依存の検証プロセスによって使用可能であると検証されたルーターを優先する必要があります。
6. When multiple interfaces are available, a router on a higher order interface is preferable.
6. 複数のインターフェイスが利用可能な場合、高次インターフェイスのルーターが望ましいです。
7. The backup feasible successor that was in use already SHOULD be preferred.
7. すでに使用されていたバックアップの実行可能な後継者が推奨されるべきです。
These rules and their order MAY be varied by an implementation according to configured policy.
これらのルールとその順序は、構成されたポリシーに従って実装によって変化する場合があります。
Objective Function Zero interacts for its management and operations in the following ways:
目的関数ゼロは、次の方法で管理と運用のために対話します。
Processing DIO: When a new DIO is received, the OF that corresponds to the Objective Code Point (OCP) in the DIO is triggered with the content of the DIO. OF0 is identified by OCP 0 (see Section 8).
処理DIO：新しいDIOが受信されると、DIOの客観的なコードポイント（OCP）に対応します。DIOのコンテンツでトリガーされます。OF0はOCP 0で識別されます（セクション8を参照）。
Providing DAG Information: The OF0 support provides an interface that returns information about a given instance. This includes material from the DIO base header, the role (router, leaf), and the Rank of this node.
DAG情報の提供：OF0サポートは、特定のインスタンスに関する情報を返すインターフェイスを提供します。これには、DIOベースヘッダー、役割（ルーター、葉）、およびこのノードのランクからの素材が含まれます。
Providing a Parent List: The OF0 support provides an interface that returns the ordered list of the parents and feasible successors for a given instance to the RPL core. This includes the material that is contained in the transit option for each entry.
親リストの提供：OF0サポートは、RPLコアに特定のインスタンスに対して、親の順序付けられたリストと実行可能な後継者を返すインターフェイスを提供します。これには、各エントリのトランジットオプションに含まれる資料が含まれます。
Triggered Updates: The OF0 support provides events to inform it that a change in DAG information or Parent List has occurred. This can be caused by an interaction with another system component such as configuration, timers, and device drivers, and the change may cause the RPL core to fire a new DIO or reset Trickle timers.
トリガーされた更新：OF0サポートは、DAG情報または親リストの変更が発生したことを通知するイベントを提供します。これは、構成、タイマー、デバイスドライバーなどの別のシステムコンポーネントとの相互作用によって引き起こされる可能性があり、変更によりRPLコアが新しいDIOを発射したり、トリクルタイマーをリセットしたりする可能性があります。
On top of variables and constants defined in [RFC6550], this specification introduces the following variables and constants:
[RFC6550]で定義されている変数と定数の上に、この仕様には次の変数と定数が導入されています。
OF0 uses the following variables:
OF0は次の変数を使用します。
step_of_rank (strictly positive integer): an intermediate computation based on the link properties with a certain neighbor.
step_of_rank（厳密に正の整数）：特定の隣接とのリンクプロパティに基づく中間計算。
rank_increase (strictly positive integer): delta between the Rank of the preferred parent and self
rank_increase（厳密に肯定的な整数）：優先親のランクと自己の間のデルタ
OF0 can use the following optional configurable values that are used as parameters to the rank_increase computation:
OF0は、RANK_INCREASE計算のパラメーターとして使用される次のオプションの構成可能な値を使用できます。
stretch_of_rank (unsigned integer): the maximum augmentation to the step_of_rank of a preferred parent to allow the selection of an additional feasible successor. If none is configured to the device, then the step_of_rank is not stretched.
Stretch_of_rank（unsigned Integer）：優先親のSTEP_OF_RANKの最大増加により、追加の実行可能な後継者の選択が可能になります。デバイスに構成されていない場合、step_of_rankは伸びません。
rank_factor (strictly positive integer): A configurable factor that is used to multiply the effect of the link properties in the rank_increase computation. If none is configured, then a rank_factor of 1 is used.
rank_factor（厳密に正の整数）：rank_increase計算のリンクプロパティの効果を増やすために使用される構成可能な因子。構成されていない場合、1のrank_factorが使用されます。
Section 17 of [RFC6550] defines RPL constants. OF0 fixes the values of the following constants:
[RFC6550]のセクション17は、RPL定数を定義しています。OF0は、次の定数の値を修正します。
DEFAULT_STEP_OF_RANK: 3
default_step_of_rank：3
MINIMUM_STEP_OF_RANK: 1
Minimum_Step_OF_RANK：1
MAXIMUM_STEP_OF_RANK: 9
Maximum_step_of_rank：9
DEFAULT_RANK_STRETCH: 0
default_rank_stretch：0
MAXIMUM_RANK_STRETCH: 5
Maximing_rank_stretch：5
DEFAULT_RANK_FACTOR: 1
default_rank_factor：1
MINIMUM_RANK_FACTOR: 1
Minimum_rank_factor：1
MAXIMUM_RANK_FACTOR: 4
Maximing_rank_factor：4
Section 18 of [RFC6550] depicts the management of the protocol. This specification inherits from that section and its subsections, with the exception that metrics as specified in [RFC6551] are not used and do not require management.
[RFC6550]のセクション18は、プロトコルの管理を示しています。この仕様は、[RFC6551]で指定されているメトリックは使用されず、管理を必要としないことを除いて、そのセクションとそのサブセクションから継承します。
An implementation SHOULD allows the configuration of at least a global rank_factor that applies to all links. Additionally, the implementation may allow the grouping of interfaces, links, and/or neighbors and configure a more specific rank_factor to such groups.
実装を使用すると、すべてのリンクに適用される少なくともグローバルRANK_FACTORの構成を可能にする必要があります。さらに、実装により、インターフェイス、リンク、および/または近隣のグループ化が可能になり、そのようなグループに対してより具体的なrank_factorを構成することができます。
An implementation MAY allow the configuration of a maximum stretch_of_rank that MUST be less than or equal to MAXIMUM_RANK_STRETCH as discussed in Section 4.1. If none is configured, a value of 0 is assumed and the step_of_rank is not stretched.
実装により、セクション4.1で説明されているように、最大_RANK_STRETCH以下でなければならない最大STREATE_OF_RANKの構成を可能にする場合があります。構成されていない場合、0の値が想定され、step_of_rankは伸びません。
An OF0 implementation SHOULD support the DODAG Configuration option as specified in Section 6.7.6 of [RFC6550] and apply the parameters contained therein. As discussed in Section 16 of [RFC6550], this requirement might be overridden by further guidance for certain application scenarios. When the option is used, the parameters are configured to the nodes that may become DODAG roots, and the nodes are configured to redistribute the information using the DODAG Configuration option. In particular, the value of MinHopRankIncrease can be distributed with that option and override the fixed constant of DEFAULT_MIN_HOP_RANK_INCREASE that is defined in Section 17 of [RFC6550] with a fixed value of 256.
OF0実装は、[RFC6550]のセクション6.7.6で指定されているDoDAG構成オプションをサポートし、そこに含まれるパラメーターを適用する必要があります。[RFC6550]のセクション16で説明したように、この要件は、特定のアプリケーションシナリオのさらなるガイダンスによってオーバーライドされる可能性があります。オプションを使用すると、パラメーターはドーダグルーツになる可能性のあるノードに設定され、ノードはDoDag構成オプションを使用して情報を再配布するように構成されています。特に、Minhoprankincreaseの値は、そのオプションで配布し、固定値256で[RFC6550]のセクション17で定義されているDefault_MIN_HOP_RANK_INCREASEの固定定数をオーバーライドできます。
Out of the box, that is at initial factory time, the default constant values SHOULD be used, that is:
箱から出して、それは初期工場の時間であるため、デフォルトの定数値を使用する必要があります。つまり、次のとおりです。
the rank_factor is set to the fixed constant DEFAULT_RANK_FACTOR (Section 6.3).
rank_factorは、固定定数default_rank_factor（セクション6.3）に設定されます。
the maximum stretch_of_rank is set to the fixed constant DEFAULT_RANK_STRETCH (Section 6.3).
最大Stretch_OF_RANKは、固定定数default_rank_stretch（セクション6.3）に設定されます。
the MinHopRankIncrease is set to the fixed constant DEFAULT_MIN_HOP_RANK_INCREASE ([RFC6550]).
minhoprankincreaseは、固定定数default_min_hop_rank_increase（[rfc6550]）に設定されます。
The values can be overridden at any time and apply at the next Version of the DODAG. As discussed in Section 16 of [RFC6550], this requirement might be overridden by further guidance for certain application scenarios.
値はいつでもオーバーライドし、ドーダグの次のバージョンで適用できます。[RFC6550]のセクション16で説明したように、この要件は、特定のアプリケーションシナリオのさらなるガイダンスによってオーバーライドされる可能性があります。
As discussed in Section 5, the OF support must be able to provide information about its operations and trigger events when that information changes. At a minimum, the information should include:
セクション5で説明したように、OFサポートは、その操作に関する情報を提供し、その情報が変更されたときにイベントをトリガーすることができなければなりません。少なくとも、情報には以下を含める必要があります。
DAG information as specified in Section 6.3.1 of [RFC6550], and including the DODAGID, the RPLInstanceID, the Mode of Operation, the Rank of this node, the current Version Number, and the value of the Grounded flag.
[RFC6550]のセクション6.3.1で指定されているDAG情報、およびDodagid、RplinstanceID、動作モード、このノードのランク、現在のバージョン番号、および接地フラグの値を含むDAG情報。
A list of neighbors indicating the preferred parent and an alternate feasible if available. For each neighbor, the Rank, the current Version Number, and the value of the Grounded flag should be indicated.
優先親を示す隣人のリストと、利用可能な場合は実現可能な代替のリスト。各隣接、ランク、現在のバージョン番号、および接地フラグの値を示す必要があります。
Per this specification, an Objective Code Point (OCP) for OF0 has been assigned in the Objective Code Point Registry as described in Section 20.5 of [RFC6550].
この仕様に従って、OF0の客観的なコードポイント（OCP）は、[RFC6550]のセクション20.5で説明されているように、客観的なコードポイントレジストリに割り当てられています。
OCP code: 0
OCPコード：0
Description: A basic Objective Function that relies only on the objects that are defined in [RFC6550].
説明：[RFC6550]で定義されているオブジェクトにのみ依存する基本的な目的関数。
Defining RFC: RFC 6552
RFCの定義：RFC 6552
This specification makes simple extensions to RPL and so is vulnerable to and benefits from the security issues and mechanisms described in [RFC6550] and [ROLL-SECURITY]. This document does not introduce new flows or new messages; thus, it requires no specific mitigation for new threats.
この仕様により、RPLへの単純な拡張機能が作成されるため、[RFC6550]および[ロールセキュリティ]で説明されているセキュリティの問題とメカニズムの脆弱性と利点があります。このドキュメントでは、新しいフローや新しいメッセージを導入しません。したがって、新しい脅威には特定の緩和を必要としません。
OF0 depends on information exchanged in the Rank and OCP protocol elements. If those elements were compromised, then an implementation of OF0 might generate the wrong path for a packet, resulting in it being misrouted. Therefore, deployments are RECOMMENDED to use RPL security mechanisms if there is a risk that routing information might be modified or spoofed.
OF0は、ランクおよびOCPプロトコル要素で交換される情報に依存します。これらの要素が侵害された場合、OF0の実装はパケットの間違ったパスを生成する可能性があり、その結果、誤って誤って行われます。したがって、ルーティング情報が変更またはスプーフィングされる可能性があるというリスクがある場合、RPLセキュリティメカニズムを使用するには展開が推奨されます。
Specific thanks to Philip Levis and Phoebus Chen for their help in finalizing this document.
この文書の最終決定に支援してくれたフィリップ・レビスとフィーバス・チェンに具体的に感謝します。
Many thanks also to Adrian Farrel, Tim Winter, JP. Vasseur, Julien Abeille, Mathilde Durvy, Teco Boot, Navneet Agarwal, Meral Shirazipour, and Henning Rogge for in-depth review and first-hand implementers' feedback.
エイドリアン・ファレル、ティム・ウィンター、JPにも感謝します。Vasseur、Julien Abeille、Mathilde Durvy、Teco Boot、Navneet Agarwal、Meral Shirazipour、Henning Roggeは、詳細なレビューと直接の実装者のフィードバックについて。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, March 2012.
[RFC6550] Winter、T.、Ed。、Thubert、P.、Ed。、Brandt、A.、Hui、J.、Kelsey、R.、Levis、P.、Pister、K.、Struik、R.、Vasseur、JP。、およびR. Alexander、「RPL：IPv6 Routing Protocol for Low-Power and Losy Networks」、RFC 6550、2012年3月。
[DeCouto03] De Couto, D., Aguayo, D., Bicket, J., and R. Morris, "A High-Throughput Path Metric for Multi-Hop Wireless Routing", MobiCom '03, The 9th ACM International Conference on Mobile Computing and Networking, San Diego, California, 2003, <http://pdos.csail.mit.edu/papers/grid:mobicom03/ paper.pdf>.
[Decouto03] de Couto、D.、Aguayo、D.、Bicket、J。、およびR. Morris、「マルチホップワイヤレスルーティングのハイスループットパスメトリック」、Mobicom '03、第9回ACM国際モバイル会議コンピューティングとネットワーキング、カリフォルニア州サンディエゴ、2003年、<http://pdos.csail.mit.edu/papers/grid:mobicom03/ paper.pdf>。
[HYSTERESIS] Gnawali, O. and P. Levis, "The Minimum Rank Objective Function with Hysteresis", Work in Progress, May 2011.
[ヒステリシス] Gnawali、O。およびP. Levis、「ヒステリシスを伴う最小ランク目標関数」、2011年5月の進行中。
[RFC6551] Vasseur, J., Ed., Kim, M., Ed., Pister, K., Dejean, N., and D. Barthel, "Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks", RFC 6551, March 2012.
[RFC6551] Vasseur、J.、Ed。、Kim、M.、Ed。、Pister、K.、Dejean、N.、およびD. Barthel、「低電力および損失ネットワークのパス計算に使用されるルーティングメトリック」、RFC 6551、2012年3月。
[ROLL-SECURITY] Tsao, T., Alexander, R., Dohler, M., Daza, V., and A. Lozano, "A Security Framework for Routing over Low Power and Lossy Networks", Work in Progress, March 2012.
[ロールセキュリティ] Tsao、T.、Alexander、R.、Dohler、M.、Daza、V。、およびA. Lozano、「低電力と損失のあるネットワークをルーティングするためのセキュリティフレームワーク」、2012年3月の作業。
[ROLL-TERMS] Vasseur, JP., "Terminology in Low power And Lossy Networks", Work in Progress, September 2011.
[Roll-Terms] Vasseur、jp。、「低電力と損失ネットワークの用語」、2011年9月、進行中の作業。
Author's Address
著者の連絡先
Pascal Thubert (editor) Cisco Systems Village d'Entreprises Green Side 400, Avenue de Roumanille Batiment T3 Biot - Sophia Antipolis 06410 FRANCE
Pascal Thubert（編集者）Cisco Systems Village D'Entreprises Green Side 400、Avenue de Roumanille Batiment T3 Biot -Sophia Antipolis 06410 France
Phone: +33 497 23 26 34
EMail: pthubert@cisco.com