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)
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）を適用することによって、ネットワークの種類の多様に適応された一般的な距離ベクトルプロトコルを定義します。状態の情報が利用可能オブジェクトに基づいRPLインスタンス内のルートを選択し、最適化するために、RPLノードによって使用されるプロセスの結果。 OFは、アルゴリズムではありません。
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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2012 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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 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.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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]は、特定の目的関数を適用することによって、一般的な距離ベクトルの低消費電力とロッシーネットワーク（LLN）の様々な適合されたプロトコルタイプを定義（のOF） 。
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のノードによって使用されるプロセスの結果。一般的な概念として、OFは、アルゴリズムではありません。例えば、RPLの外部に、「第一の最短経路」は、2つのポイント間の最小コスト経路を結果として導出される場合です。周知のダイクストラのアルゴリズムは一例となっているのを満たすために使用することができる多数のアルゴリズムが存在します。
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.
コアプロトコル仕様からのOFの分離は、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（DODAGs）の集合として有向非巡回グラフ（DAGの）を形成します。各インスタンスは、特殊な目的関数に関連付けられています。 DODAGは、定期的にグラフのグローバルな再最適化を可能にするために、新しい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のインスタンスは、それがDODAGとバージョンは、そのDODAGのそれは参加するべきかを判断するために目的関数を使用しています。 OFはまた、親又は実現可能な後継として機能するDODAG現在及び後続のバージョン内のルータの数を選択するために、RPLインスタンスによって使用されます。
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インスタンスは、デバイスのランクを計算するのに使用します。この値は、DODAGバージョン内DODAGのルートに抽象的距離を表します。ランクは、[RFC6550]で指定されるように、ループを回避して目的地に向かって前進を確認するために他のRPLノードを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.
ノードのランクは、選択された好ましい親のランクに、厳密に正で、間接的に正規化されたスカラー、rank_increase（6.1節）を追加したものです。 rank_increaseは、リンク特性を表すために、図9（最悪許容される）にstep_of_rank（セクション6.1）1（最高）からの比に応じて変化することができ、正規化スカラーに基づいています。 step_of_rankは同じRPLインスタンスで使用される異なるリンクタイプとの間の相対的な好みを反映するrank_increaseを増幅rank_factor（セクション6.2）と呼ばれる構成可能な係数で乗算することができます。 rank_increaseはさらに、セクション4.1に詳述されるように適合させることができます。デフォルトによって、OF0 256の単位で2オクテットのランクを符号化し、デフォルト設定は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]は、ネットワーク内のすべてのノードによって共通OFの使用を必要とします。単一のネットワークで複数のOFの使用の可能性は、今後の検討課題です。
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 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.
RPL仕様[RFC6550]は定義のいずれかを含んでいません。これは、異なる展開とアプリケーション環境に固有の他の文書のために残されています。 RPL主な仕様には、デフォルトまたはメトリックのコンテナが存在しないので、与えられた二つの実装が特定の問題や環境のために同じガイダンスに従う場合を除き、これらの実装は、彼らが相互運用可能性があるとの共通をサポートしていないだろう、ということが起こるかもしれません。
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].
キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "SHALL"、 "SHOULD"、 "ないもの"、 "推奨" "ない（SHOULD NOT）"、 "MAY"、 "推奨NOT"、および「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の目標は、パスが特定のメトリックに応じて最適化されるという保証はありませんけれども、ノードの特定のセットに以上のルーティングインフラストラクチャに優れ、十分な接続性を提供していますDODAGバージョンに参加するノードのためです。接続のためのこの検証プロセスを実装し、リンクタイプに依存しており、範囲外です。検証が必要とするが、[RFC6550]のアプリケーションに限定されるものではなく、必要に応じてセクション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内の内部接続が依然として望ましいとフローティングのDAGは、最高管理者嗜好を持つノードをルートと、形成されます。
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.
1が利用可能な場合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を割り当てるOF0使用することができます。 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第1の関連リンクの特性とメトリックから指定された親に関連付けられた変数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実装が唯一の良い十分な接続性を持つ親、およびカウントをホップに似てランクで結果を考慮することを意味します。最もLLNsでは、これは貧しい接続の少ないが、より長いホップを持つパスを好みます。 【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を伸ばすことを可能にします。それは、ノードからルートに明らか距離を増大させる最適な形状からDODAGを歪まとによってノードは、ループ内の親としてお互いを使用するそれらのランクを増やすことにより、貪欲な行動による不安定性を引き起こす可能性があるためstep_of_rank延伸する、推奨されていません。依然として、実装は多くとも0の間の任意の値の設定stretch_of_rank（6.2）（NOストレッチ）と固定定数MAXIMUM_RANK_STRETCH（セクション6.3）と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.
実装は、固定された定数MINIMUM_STEP_OF_RANKとMAXIMUM_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とMAXIMUM_RANK_STRETCHとの間のギャップを強く好むために、異なるタイプまたはカテゴリのリンクを区別するために、すべての場合に十分ではないかもしれない、たとえば、同じDAG内。実装は、オペレータが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は固定定数MINIMUM_RANK_FACTORとMAXIMUM_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、で表さ単位で表されている固定定数DEFAULT_MIN_HOP_RANK_INCREASEデフォルト（[RFC6550]）。その設定で、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で乗算し、次いでおそらくは構成stretch_of_rank以下で用語SRで延伸されます。得rank_increaseこのノードR（N）のそれを得るための好ましい親R（P）のランクに追加されます。
R(N) = R(P) + rank_increase where:
R（N）は、R（P）+ rank_increase =。
rank_increase = (Rf*Sp + Sr) * MinHopRankIncrease
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.
必要に応じて、ルートの管理好みは接地DODAGに参加することを目標に取って代わるように構成することができます。その場合、ノードは関係なく、そのルートが接地されているか否かを、利用可能な最高優先してルートに関連付けるであろう。 DODAGsの同じ多数をもたらす接地根の多数と配備に比べ、このような構成は、おそらくより少ないが、より大きなDODAGs、到達可能な近傍で最も高い優先度で設定根限り多くをもたらすことができます。
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は、DODAG版以内にランクを増強するために再親のノードのための一般的なルール、特に境界を綴ります。これらのルールを満たさないと候補者が考慮されてはなりません。
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.
セクション3で説明したように【0002】【従来の好適な親としてのルータを選択し、実装はルータの接続性と適合性を検証する必要があり、この検証は、ルータへのレイヤ2接続、ルータによって提供されるレイヤ3接続を確認することを含みますそして、このようなローカルまたはグローバルに設定されたポリシーのような他の要因の検討を含むことができます。
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.
ルートの管理好みが接地DODAGに参加することを目標に優先するように設定されている場合は4、より好ましくルートへの接続を提供していますルータが優先されるべきである（SHOULD）。
5. A router that offers connectivity to a grounded DODAG Version SHOULD be preferred over one that does not.
5.接地DODAGバージョンへの接続を提供していますルータがないものよりも優先されるべきである（SHOULD）。
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.同じDODAGに属する2人の両親を比較すると、最新のDODAGバージョンへの接続を提供していますルータが優先されるべきである（SHOULD）。
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. A DODAG版れる代替親が好まれるべきです。このチェックはオプションです。現在検討されているルータは、最終的に好ましい親として選択されていることを想定し、それをバックアップ可能後継を計算することによって行われます。
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.
最近でDIOメッセージを発表した11ルータが優先されるべきである（SHOULD）。
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:
バックアップ実行可能な後継者を選択する場合、次のチェックの順序で行うOF：
2. The backup feasible successor MUST be either in the same DODAG Version as this node or in an subsequent DODAG Version.
2.バックアップ実行可能な後継者は、このノードと同じDODAGバージョンまたは後続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.
RPLルールとともに3は、このノードと同じDODAGバージョンで、このノードに対して計算ランクよりも高いランクを持つルータが可能後継として選択してはいけません。
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（符号なし整数）：好適な親の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
MAXIMUM_RANK_STRETCH：5
DEFAULT_RANK_FACTOR: 1
DEFAULT_RANK_FACTOR：1
MINIMUM_RANK_FACTOR: 1
MINIMUM_RANK_FACTOR：1
MAXIMUM_RANK_FACTOR: 4
MAXIMUM_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.
実装SHOULDは、すべてのリンクに適用され、少なくともグローバル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で説明したように以下MAXIMUM_RANK_STRETCHに等しくなければならない最大stretch_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根になることができるノードに構成され、ノードは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.
値は、任意の時点で無効とDODAGの次のバージョンで申請することができます。 [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で論じたように、支持体のその情報が変化した場合、その操作およびトリガイベントについての情報を提供することができなければなりません。最低でも、情報が含まれている必要があります
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で指定され、そして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].
[RFC6550]のセクション20.5で説明したように、本明細書あたり、OF0対物コードポイント（OCP）は、目的コードポイントレジストリに割り当てられています。
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]と[ROLL-SECURITY]で説明したメカニズムから恩恵を受けています。この文書は、新しいフローまたは新しいメッセージを導入しません。したがって、それは新たな脅威のための具体的な緩和策を必要としません。
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、ジュリアンラベイユ、マチルドDurvy、テコブーツ、Navneet Agarwalさん、Meral Shirazipour、およびヘニング・ロゲで詳細なレビューと最初の手の実装者のフィードバックのために。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]冬、T.、エド。、Thubert、P.、エド。、ブラント、A.、ホイ、J.、ケルシー、R.、リーバイス、P.、ピスター教授、K.、Struik、R.、Vasseur 、JP、およびR.アレクサンダー、 "RPL：低消費電力とロッシーネットワークのためのIPv6ルーティングプロトコル"、RFC 6550、2012月。
[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]デ・クート、D.、Aguayo、D.、Bicket、J.、およびR.モリス、「マルチホップ無線ルーティングのためのハイスループットパスメトリック」、モビコム'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.リーバイス、「ヒステリシスと最低ランク目的関数」、進歩、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.、エド。、キム、M.、エド。、ピスター教授、K.、Dejean、N.、およびD.バーセル、 "ルーティングメトリック低消費電力とロッシーネットワークにおける経路計算に使用"、 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.
[ROLL-SECURITY] Tsaoさん、T.、アレクサンダー、R.、のDohler、M.、ダサ、V.、およびA.ロサノ、 "低消費電力とロッシーネットワーク経由のルーティングのためのセキュリティフレームワーク" が進歩、2012月での作業。
[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
Thubertパスカル（編集者）、シスコシステムズエンタープライズヴィレッジグリーンサイド400アベニューRoumanilleビルT3ビオ - ソフィアアンティポリス06410 FRANCE
Phone: +33 497 23 26 34 EMail: pthubert@cisco.com
電話：+33 497 23 26 34 Eメール：pthubert@cisco.com