[要約] RFC 6719は、ヒステリシス目的関数を持つ最小ランクに関するものであり、ネットワークのリンク状態を評価するための新しいアルゴリズムを提案しています。このRFCの目的は、ネットワークのパフォーマンスを向上させるために、リンクの状態をより正確に評価することです。
Internet Engineering Task Force (IETF) O. Gnawali
Request for Comments: 6719 University of Houston
Category: Standards Track P. Levis
ISSN: 2070-1721 Stanford University
September 2012
The Minimum Rank with Hysteresis Objective Function
ヒステリシス目的関数を使用した最小ランク
Abstract
概要
The Routing Protocol for Low-Power and Lossy Networks (RPL) constructs routes by using Objective Functions that optimize or constrain the routes it selects and uses. This specification describes the Minimum Rank with Hysteresis Objective Function (MRHOF), an Objective Function that selects routes that minimize a metric, while using hysteresis to reduce churn in response to small metric changes. MRHOF works with additive metrics along a route, and the metrics it uses are determined by the metrics that the RPL Destination Information Object (DIO) messages advertise.
Low-Power and Lossy Networks（RPL）のルーティングプロトコルは、選択して使用するルートを最適化または制約する目的関数を使用してルートを構築します。この仕様は、ヒステリシスを使用して小さなメトリックの変化に応じてチャーンを削減しながら、メトリックを最小化するルートを選択する目的関数であるヒステリシス目的関数（MRHOF）の最小ランクについて説明します。 MRHOFはルートに沿った追加のメトリックで機能し、それが使用するメトリックは、RPL宛先情報オブジェクト（DIO）メッセージがアドバタイズするメトリックによって決定されます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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/rfc6719.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6719で入手できます。
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 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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The Minimum Rank with Hysteresis Objective Function . . . . . 4
3.1. Computing the Path Cost . . . . . . . . . . . . . . . . . 4
3.2. Parent Selection . . . . . . . . . . . . . . . . . . . . . 5
3.2.1. When Parent Selection Runs . . . . . . . . . . . . . . 6
3.2.2. Parent Selection Algorithm . . . . . . . . . . . . . . 6
3.3. Computing Rank . . . . . . . . . . . . . . . . . . . . . . 7
3.4. Advertising the Path Cost . . . . . . . . . . . . . . . . 8
3.5. Working without Metric Containers . . . . . . . . . . . . 8
4. Using MRHOF for Metric Maximization . . . . . . . . . . . . . 9
5. MRHOF Variables and Parameters . . . . . . . . . . . . . . . . 9
6. Manageability . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Device Configuration . . . . . . . . . . . . . . . . . . . 10
6.2. Device Monitoring . . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . . 13
An Objective Function specifies how RPL [RFC6550] selects paths. For example, if an RPL instance uses an Objective Function that minimizes hop count, RPL will select paths with a minimum hop count. RPL requires that all nodes in a network use a common Objective Function; relaxing this requirement may be a subject of future study.
目的関数は、RPL [RFC6550]がパスを選択する方法を指定します。たとえば、RPLインスタンスがホップカウントを最小化する目的関数を使用する場合、RPLはホップカウントが最小のパスを選択します。 RPLでは、ネットワーク内のすべてのノードが共通の目的関数を使用する必要があります。この要件を緩和することは、将来の研究の主題になるかもしれません。
The nodes running RPL might use a number of metrics to describe a link or a node [RFC6551] and make these metrics available for route selection. RPL advertises metrics in RPL Destination Information Object (DIO) messages with a Metric Container suboption. An Objective Function can use these metrics to choose routes.
RPLを実行するノードは、リンクまたはノード[RFC6551]を記述するためにいくつかのメトリックを使用し、これらのメトリックをルート選択に使用できるようにする場合があります。 RPLは、メトリックコンテナーサブオプションを使用して、RPL宛先情報オブジェクト（DIO）メッセージでメトリックをアドバタイズします。目的関数はこれらのメトリックを使用してルートを選択できます。
To decouple the details of an individual metric or Objective Function from forwarding and routing, RPL describes routes through a value called Rank. Rank, roughly speaking, corresponds to the distance associated with a route. RPL defines how nodes decide on paths based on Rank and advertise their Rank. An Objective Function defines how nodes calculate Rank, based on the Rank of its potential parents, metrics, and other network properties.
個々のメトリックまたは目的関数の詳細を転送およびルーティングから切り離すために、RPLはルートと呼ばれる値を介してルートを記述します。ランクは、大まかに言えば、ルートに関連付けられた距離に対応します。 RPLは、ノードがランクに基づいてパスを決定し、そのランクをアドバタイズする方法を定義します。目的関数は、潜在的な親のランク、メトリック、およびその他のネットワークプロパティに基づいて、ノードがランクを計算する方法を定義します。
This specification describes the Minimum Rank with Hysteresis Objective Function (MRHOF), an Objective Function for RPL, which uses hysteresis while selecting the path with the smallest metric value. The metric that MRHOF uses is determined by the metrics in the DIO Metric Container. For example, the use of MRHOF with the latency metric allows RPL to find stable minimum-latency paths from the nodes to a root in the Directed Acyclic Graph (DAG) instance [RFC6550]. The use of MRHOF with the Expected Transmission Count (ETX) metric [RFC6551] allows RPL to find the stable minimum-ETX paths from the nodes to a root in the DAG instance. In the absence of a metric in the DIO Metric Container or of a DIO Metric Container, MRHOF defaults to using ETX to compute Rank, as described in Section 3.5.
この仕様は、最小のメトリック値を持つパスを選択する際にヒステリシスを使用するRPLの目的関数であるヒステリシス目的関数（MRHOF）を持つ最小ランクについて説明しています。 MRHOFが使用するメトリックは、DIOメトリックコンテナ内のメトリックによって決定されます。たとえば、レイテンシメトリックでMRHOFを使用すると、RPLは、ノードからルートへの有向非巡回グラフ（DAG）インスタンス[RFC6550]で安定した最小レイテンシパスを見つけることができます。予想伝送数（ETX）メトリック[RFC6551]でMRHOFを使用すると、RPLはノードからDAGインスタンスのルートへの安定した最小ETXパスを見つけることができます。 DIOメトリックコンテナまたはDIOメトリックコンテナにメトリックがない場合、MRHOFは、セクション3.5で説明されているように、デフォルトでETXを使用してランクを計算します。
Because MRHOF seeks to minimize path costs as described by metrics, it can only be used with additive metrics. MRHOF does not support metrics that are not additive.
MRHOFは、メトリックによって記述されるパスコストを最小限に抑えることを目的としているため、追加のメトリックでのみ使用できます。 MRHOFは、加算的でないメトリックをサポートしていません。
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」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの "は、RFC 2119 [RFC2119]で説明されているように解釈されます。
The terminologies used in this document are consistent with the terminologies described in [ROLL-TERM] and [RFC6551].
このドキュメントで使用されている用語は、[ROLL-TERM]および[RFC6551]で説明されている用語と一致しています。
The terminologies used in this document are also consistent with the terminologies described in [RFC6550], except the term Rank. In this document, Rank refers to the value of the Rank field, not DAGRank as in [RFC6550].
このドキュメントで使用される用語は、ランクという用語を除いて、[RFC6550]で説明されている用語とも一致しています。このドキュメントでは、ランクは[RFC6550]のようにDAGRankではなく、ランクフィールドの値を指します。
This document introduces three terms:
このドキュメントでは、3つの用語を紹介します。
Selected metric: The metric chosen for path selection by the network operator. MRHOF supports using a single metric for path selection. The decision to use a metric (other than ETX) as the selected metric is indicated by the presence of the chosen metric in the DIO Metric Container. The selection of the ETX metric is indicated by the absence of the Metric Container, in which case ETX is advertised as Rank.
選択されたメトリック：ネットワークオペレーターがパスを選択するために選択したメトリック。 MRHOFは、パス選択に単一のメトリックの使用をサポートします。選択したメトリックとしてメトリック（ETX以外）を使用する決定は、DIOメトリックコンテナー内の選択したメトリックの存在によって示されます。 ETXメトリックの選択は、メトリックコンテナーがないことによって示されます。この場合、ETXはランクとしてアドバタイズされます。
Path cost: Path cost quantifies a property of an end-to-end path. Path cost is obtained by each node summing up the selected link metric to the path cost advertised by the parent. Path cost can be used by RPL to compare different paths.
パスコスト：パスコストは、エンドツーエンドパスのプロパティを数量化します。パスコストは、選択したリンクメトリックを親によってアドバタイズされたパスコストに合計した各ノードによって取得されます。 RPLはパスコストを使用して、異なるパスを比較できます。
Worst parent: The node in the parent set with the largest path cost.
最悪の親：最大のパスコストを持つ親セット内のノード。
The Minimum Rank with Hysteresis Objective Function, MRHOF, is designed to find the paths with the smallest path cost while preventing excessive churn in the network. It does so by using two mechanisms. First, it finds the minimum cost path, i.e., path with the minimum Rank. Second, it switches to that minimum Rank path only if it is shorter (in terms of path cost) than the current path by at least a given threshold. This second mechanism is called "hysteresis".
ヒステリシス目的関数を備えた最小ランクMRHOFは、ネットワークでの過剰なチャーンを防ぎながら、パスコストが最小のパスを見つけるように設計されています。これは、2つのメカニズムを使用して行われます。最初に、最小コストパス、つまり最小ランクのパスを見つけます。第2に、現在のパスよりも少なくとも所定のしきい値だけ短い場合（パスコストの観点から）、その最小ランクパスに切り替えます。この2番目のメカニズムは「ヒステリシス」と呼ばれます。
MRHOF may be used with any additive metric listed in [RFC6551] as long as the routing objective is to minimize the given routing metric. Nodes MUST support at least one of these metrics: hop count, latency, or ETX. Nodes SHOULD support the ETX metric. MRHOF does not support non-additive metrics.
MRHOFは、ルーティングの目的が特定のルーティングメトリックを最小化することである限り、[RFC6551]にリストされている追加のメトリックとともに使用できます。ノードは、これらのメトリックのうち少なくとも1つをサポートする必要があります：ホップカウント、レイテンシ、またはETX。ノードはETXメトリックをサポートする必要があります（SHOULD）。 MRHOFは非追加メトリックをサポートしていません。
Root nodes (Grounded or Floating) set the variable cur_min_path_cost to the metric value that computes to a Rank of MinHopRankIncrease.
ルートノード（接地または浮動）は、変数cur_min_path_costを、MinHopRankIncreaseのランクに計算されるメトリック値に設定します。
If a non-root node does not have metrics to compute the path cost through any of the candidate neighbors, it MUST join one of the candidate neighbors as a RPL Leaf.
非ルートノードに候補ネイバーのいずれかを通るパスコストを計算するメトリックがない場合、RPLリーフとして候補ネイバーの1つに参加する必要があります。
Otherwise, nodes compute the path cost for each candidate neighbor reachable on an interface. The path cost of a neighbor represents the cost of the path, in terms of the selected metric, from a node to the root of the Destination-Oriented DAG (DODAG) through that neighbor. A non-root node computes a neighbor's path cost by adding two components:
それ以外の場合、ノードは、インターフェイスで到達可能な各候補ネイバーのパスコストを計算します。ネイバーのパスコストは、ノードからそのネイバーを介して宛先指向DAG（DODAG）のルートまでの、選択されたメトリックの観点からのパスのコストを表します。非ルートノードは、次の2つのコンポーネントを追加して、ネイバーのパスコストを計算します。
1. If the selected metric is a link metric, the selected metric for the link to the candidate neighbor. If the selected metric is a node metric, the selected metric for the node.
1. 選択されたメトリックがリンクメトリックの場合、候補ネイバーへのリンクに対して選択されたメトリック。選択したメトリックがノードメトリックの場合、ノードの選択したメトリック。
2. The value of the selected metric in the Metric Container in the DIO sent by that neighbor. In case the Metric Container is empty, ETX is the selected metric -- use the Rank advertised by that neighbor as the second component. See Section 3.5 for details on how an ETX metric is used in MRHOF.
2. そのネイバーによって送信されたDIOのメトリックコンテナで選択されたメトリックの値。メトリックコンテナが空の場合、ETXが選択されたメトリックです。そのネイバーによってアドバタイズされたランクを2番目のコンポーネントとして使用します。 MRHOFでのETXメトリックの使用方法の詳細については、セクション3.5を参照してください。
A node SHOULD compute the path cost for the path through each candidate neighbor reachable through an interface. If a node cannot compute the path cost for the path through a candidate neighbor, the node MUST NOT select the candidate neighbor as its preferred parent. However, if the node cannot compute the path cost through any neighbor, it may join the candidate neighbor as a Leaf, as described above.
ノードは、インターフェイスを介して到達可能な各候補ネイバーを経由するパスのパスコストを計算する必要があります。ノードが候補ネイバーを通るパスのパスコストを計算できない場合、ノードは候補ネイバーをその優先親として選択してはなりません（MUST NOT）。ただし、ノードがネイバーを経由するパスコストを計算できない場合は、上記のように、候補ネイバーをリーフとして結合できます。
If the selected metric is a link metric and the metric of the link to a neighbor is not available, the path cost for the path through that neighbor SHOULD be set to MAX_PATH_COST. This cost value will prevent this path from being considered for path selection.
選択されたメトリックがリンクメトリックであり、ネイバーへのリンクのメトリックが使用できない場合、そのネイバーを経由するパスのパスコストはMAX_PATH_COSTに設定する必要があります。このコスト値は、このパスがパス選択の対象となるのを防ぎます。
If the selected metric is a node metric, and the metric is not available, the path cost through all the neighbors SHOULD be set to MAX_PATH_COST.
選択されたメトリックがノードメトリックであり、メトリックが使用できない場合、すべてのネイバーを通るパスコストはMAX_PATH_COSTに設定する必要があります。
The path cost corresponding to a neighbor SHOULD be recomputed each time any of the following conditions are met:
ネイバーに対応するパスコストは、次のいずれかの条件が満たされるたびに再計算する必要があります。
1. The selected metric of the link to the candidate neighbor is updated.
1. 候補ネイバーへのリンクの選択されたメトリックが更新されます。
2. The selected metric is a node metric and the metric is updated.
2. 選択したメトリックはノードメトリックであり、メトリックが更新されます。
3. A node receives a new metric advertisement from the candidate neighbor.
3. ノードは候補ネイバーから新しいメトリックアドバタイズを受信します。
This computation SHOULD also be performed periodically. While it is harmless to delay this computation up to a minimum Trickle interval [RFC6550], longer delays in updating the path cost after the metric is updated or a new metric advertisement is received can lead to stale information.
この計算も定期的に実行する必要があります。この計算を最小のトリクル間隔[RFC6550]まで遅らせることは無害ですが、メトリックが更新された後、または新しいメトリックアドバタイズメントが受信された後のパスコストの更新の遅延が長くなると、情報が古くなる可能性があります。
After computing the path cost for all the candidate neighbors reachable through an interface for the current DODAG iteration [RFC6550], a node selects the preferred parent. This process is called "parent selection". To allow hysteresis, parent selection maintains a variable, cur_min_path_cost, which is the path cost of the current preferred parent.
現在のDODAG反復[RFC6550]のインターフェースを介して到達可能なすべての候補近傍のパスコストを計算した後、ノードは優先される親を選択します。このプロセスは「親の選択」と呼ばれます。ヒステリシスを可能にするために、親の選択では、現在の優先される親のパスコストであるcur_min_path_cost変数が維持されます。
A MRHOF implementation SHOULD perform Parent Selection each time:
MRHOF実装は、毎回親の選択を実行する必要があります（SHOULD）。
1. The path cost for an existing candidate neighbor, including the preferred parent, changes. This condition can be checked immediately after the path cost is computed.
1. 優先される親を含む、既存の候補ネイバーのパスコストが変更されます。この状態は、パスコストが計算された直後に確認できます。
2. A new candidate neighbor is inserted into the neighbor table.
2. 新しい候補ネイバーがネイバーテーブルに挿入されます。
If, despite the above, it is necessary to defer the parent selection until a later time (e.g., up to the Trickle minimum interval [RFC6550]), note that doing so can delay the use of better paths available in the network.
上記にもかかわらず、親の選択を後で（たとえば、トリクルの最小間隔[RFC6550]まで）延期する必要がある場合は、そうすることで、ネットワークで利用できるより適切なパスの使用が遅れることがあることに注意してください。
If the selected metric for a link is greater than MAX_LINK_METRIC, the node SHOULD exclude that link from consideration during parent selection.
リンクに対して選択されたメトリックがMAX_LINK_METRICより大きい場合、ノードは親の選択時にそのリンクを考慮から除外する必要があります（SHOULD）。
A node MUST select the candidate neighbor with the lowest path cost as its preferred parent, except as indicated below:
ノードは、以下に示す場合を除き、パスコストが最小の候補ネイバーを優先親として選択する必要があります。
1. A node MAY declare itself as a Floating root, and hence have no preferred parent, depending on system configuration.
1. システム構成によっては、ノードが自身をフローティングルートとして宣言する場合があり、優先する親がない場合があります。
2. If cur_min_path_cost is greater than MAX_PATH_COST, the node MAY declare itself as a Floating root.
2. cur_min_path_costがMAX_PATH_COSTより大きい場合、ノードは自身をフローティングルートとして宣言できます（MAY）。
3. If the smallest path cost for paths through the candidate neighbors is smaller than cur_min_path_cost by less than PARENT_SWITCH_THRESHOLD, the node MAY continue to use the current preferred parent. This is the hysteresis component of MRHOF.
3. 候補の近傍を通るパスの最小パスコストがcur_min_path_costよりもPARENT_SWITCH_THRESHOLD未満の場合、ノードは現在の優先される親を引き続き使用できます（MAY）。これはMRHOFのヒステリシス成分です。
4. If ALLOW_FLOATING_ROOT is 0 and no neighbors are discovered, the node does not have a preferred parent and MUST set cur_min_path_cost to MAX_PATH_COST.
4. ALLOW_FLOATING_ROOTが0でネイバーが検出されない場合、ノードには優先される親がなく、cur_min_path_costをMAX_PATH_COSTに設定する必要があります。
If there are multiple neighbors that share the smallest path cost, a node MAY use a different selection criteria to select which of these neighbors should be considered to have the lowest cost.
最小のパスコストを共有するネイバーが複数ある場合、ノードは、異なる選択基準を使用して、これらのネイバーのうちどれが最もコストが低いと見なすべきかを選択できます。
A node MAY include up to PARENT_SET_SIZE-1 additional candidate neighbors in its parent set. The cost of the path through the nodes in the parent set is smaller than or equal to the cost of the paths through any of the nodes that are not in the parent set. If the cost of the path through the preferred parent and the worst parent is too large, a node MAY keep a smaller parent set than PARENT_SET_SIZE.
ノードは、その親セットに最大PARENT_SET_SIZE-1までの追加の隣接候補を含めることができます（MAY）。親セットのノードを通るパスのコストは、親セットにないノードのいずれかを通るパスのコスト以下です。優先される親と最悪の親を通るパスのコストが大きすぎる場合、ノードはPARENT_SET_SIZEよりも小さい親セットを保持できます（MAY）。
Once the preferred parent is selected, the node sets its cur_min_path_cost variable to the path cost corresponding to the preferred parent. The value of the cur_min_path_cost is carried in the Metric Container corresponding to the selected metric when DIO messages are sent.
優先される親が選択されると、ノードはそのcur_min_path_cost変数を優先される親に対応するパスコストに設定します。 cur_min_path_costの値は、DIOメッセージが送信されるときに、選択されたメトリックに対応するメトリックコンテナーに含まれます。
DAG roots set their Rank to MinHopRankIncrease.
DAGルートは、ランクをMinHopRankIncreaseに設定します。
Once a non-root node selects its parent set, it can use the following table to covert the path cost of a parent (written as Cost in the table) to a Rank value:
非ルートノードが親セットを選択すると、次の表を使用して、親のパスコスト（表ではCostとして記述）をランク値に変換できます。
+------------------+------------+
| Node/link Metric | Rank |
+------------------+------------+
| Hop-Count | Cost |
| Latency | Cost/65536 |
| ETX | Cost |
+------------------+------------+
Table 1: Conversion of Metric to Rank
表1：メトリックのランクへの変換
If MRHOF is used with other metrics, the Rank is undefined. If the Rank is undefined, the node must join one of the neighbors as a RPL Leaf node according to [RFC6550].
MRHOFが他のメトリックと共に使用される場合、ランクは未定義です。ランクが定義されていない場合、ノードは[RFC6550]に従ってRPLリーフノードとしてネイバーの1つに参加する必要があります。
MRHOF uses this Rank value to compute the Rank it associates with the path through each member of the parent set. The Rank associated with a path through a member of the parent set is the maximum of two values. The first is the corresponding Rank value calculated with the table above, the second is that nodes' advertised Rank plus MinHopRankIncrease.
MRHOFはこのランク値を使用して、親セットの各メンバーを通るパスに関連付けるランクを計算します。親セットのメンバーを通るパスに関連付けられたランクは、2つの値の最大値です。 1つ目は、上記の表で計算された対応するランク値です。2つ目は、ノードのアドバタイズされたランクとMinHopRankIncreaseです。
A node sets its Rank to the maximum of three values:
ノードは、ランクを3つの値の最大値に設定します。
1. The Rank calculated for the path through the preferred parent.
1. 優先される親を通るパスに対して計算されたランク。
2. The Rank of the member of the parent set with the highest advertised Rank, rounded to the next higher integral Rank, i.e., to MinHopRankIncrease * (1 + floor(Rank/MinHopRankIncrease)).
2. アドバタイズされたランクが最も高い親セットのメンバーのランク。次に高い整数ランクに丸められます。つまり、MinHopRankIncrease *（1 + floor（Rank / MinHopRankIncrease））に丸められます。
3. The largest calculated Rank among paths through the parent set, minus MaxRankIncrease.
3. 親セットを通るパスの中で計算された最大ランクからMaxRankIncreaseを引いたもの。
The first case is the Rank associated with the path through the preferred parent. The second case covers requirement 5 of Rank advertisements in Section 8.2.1 of [RFC6550]. The third case ensures that a node does not advertise a Rank, which then precludes it from using members of its parent set.
最初のケースは、優先される親を通るパスに関連付けられたランクです。 2番目のケースは、[RFC6550]のセクション8.2.1のランク広告の要件5をカバーしています。 3番目のケースでは、ノードがランクをアドバタイズしないようにします。これにより、ノードはその親セットのメンバーを使用できなくなります。
Note that the third case means that a node advertises a conservative Rank value based on members of its parent set. This conservative value might be significantly higher than the Rank calculated for the path through the preferred parent. Accordingly, picking a parent set whose paths have a large range of Ranks will likely result in subptimal routing: nodes might not choose good paths because they are advertised as much worse than they actually are. The exact selection of a parent set is an implementation decision.
3番目のケースは、ノードがその親セットのメンバーに基づいて保守的なランク値をアドバタイズすることを意味することに注意してください。この控えめな値は、優先される親を通るパスに対して計算されたランクよりも大幅に高くなる可能性があります。したがって、パスのランクの範囲が広い親セットを選択すると、ルーティングがサブプライマルになる可能性があります。ノードは、実際よりもはるかに悪い状態でアドバタイズされるため、適切なパスを選択できない場合があります。親セットの正確な選択は、実装の決定です。
Once the preferred parent is selected, the node sets its cur_min_path_cost variable to the path cost corresponding to its preferred parent. It then calculates the metric it will advertise in its metric container. This value is the path cost of the member of the parent set with the highest path cost. Thus, while cur_min_path_cost is the cost through the preferred parent, a node advertises the highest cost path from the node to the root through a member of the parent set. The value of the highest cost path is carried in the metric container corresponding to the selected metric when DIO messages are sent.
優先される親が選択されると、ノードはcur_min_path_cost変数をその優先される親に対応するパスコストに設定します。次に、メトリックコンテナでアドバタイズするメトリックを計算します。この値は、パスコストが最も高い親セットのメンバーのパスコストです。したがって、cur_min_path_costは優先される親を介したコストですが、ノードは親セットのメンバーを介してノードからルートへの最高コストパスをアドバタイズします。最高コストパスの値は、DIOメッセージが送信されるときに、選択されたメトリックに対応するメトリックコンテナーに入れられます。
If ETX is the selected metric, a node MUST NOT advertise it in a metric container. Instead, a node MUST advertise an approximation of its ETX in its advertised Rank value, following the rules described in Section 3.3. If a node receives a DIO with a Metric Container holding an ETX metric, MRHOF MUST ignore the ETX metric value in its Rank calculations.
ETXが選択されたメトリックである場合、ノードはそれをメトリックコンテナーでアドバタイズしてはなりません（MUST NOT）。代わりに、ノードは、セクション3.3で説明されているルールに従って、アドバタイズされたランク値でETXの概算をアドバタイズする必要があります。ノードがETXメトリックを保持するメトリックコンテナーを含むDIOを受信した場合、MRHOFはランク計算でETXメトリック値を無視する必要があります。
DODAG Roots advertise a metric value that computes to a Rank value of MinHopRankIncrease.
DODAG Rootは、MinHopRankIncreaseのランク値を計算するメトリック値をアドバタイズします。
In the absence of a Metric Container, MRHOF uses ETX as its metric. It locally computes the ETX of links to its neighbors and adds this value to their advertised Rank to compute the associated Rank of routes. Once parent selection and rank computation is performed using the ETX metric, the node advertises the Rank and MUST NOT include a metric container in its DIO messages. While assigning Rank in this case, use the representation of ETX described in [RFC6551], i.e., assign Rank equal to ETX * 128.
メトリックコンテナがない場合、MRHOFはメトリックとしてETXを使用します。ローカルで近隣へのリンクのETXを計算し、この値をアドバタイズされたランクに追加して、関連するルートのランクを計算します。 ETXメトリックを使用して親の選択とランクの計算が実行されると、ノードはランクをアドバタイズし、DIOメッセージにメトリックコンテナーを含めてはなりません（MUST NOT）。この場合にランクを割り当てるときは、[RFC6551]で説明されているETXの表現を使用します。つまり、ランクをETX * 128に割り当てます。
MRHOF cannot be directly used for parent selection using metrics that require finding paths with a maximum value of the selected metric, such as path reliability. It is possible to convert such a metric maximization problem to a metric minimization problem for some metrics and use MRHOF provided:
MRHOFは、パスの信頼性など、選択したメトリックの最大値を持つパスを見つける必要があるメトリックを使用して、親の選択に直接使用することはできません。このようなメトリック最大化問題を一部のメトリックのメトリック最小化問題に変換し、提供されているMRHOFを使用することができます。
There is a fixed and well-known maximum metric value corresponding to the best path. This is the path cost for the DAG root. For example, the logarithm of the best link reliability has a value of 0.
最適なパスに対応する固定された既知の最大メトリック値があります。これは、DAGルートのパスコストです。たとえば、最高のリンク信頼性の対数の値は0です。
The metrics in the maximization problem are all negative. The logarithm of the link reliability is always negative.
最大化問題のメトリックはすべて負です。リンクの信頼性の対数は常に負です。
For metrics meeting the above conditions, the problem of maximizing the metric value is equivalent to minimizing the modified metric value, e.g., logarithm of link reliability. MRHOF is not required to work with these metrics.
上記の条件を満たすメトリックの場合、メトリック値を最大化する問題は、変更されたメトリック値（リンクの信頼性の対数など）を最小化することと同じです。 MRHOFは、これらのメトリックを処理する必要はありません。
MRHOF uses the following variable:
MRHOFは次の変数を使用します。
cur_min_path_cost: The cost of the path from a node through its preferred parent to the root computed at the last parent selection.
cur_min_path_cost：ノードからその優先親を経由して、最後の親選択で計算されたルートまでのパスのコスト。
MRHOF uses the following parameters:
MRHOFは以下のパラメーターを使用します。
MAX_LINK_METRIC: Maximum allowed value for the selected link metric for each link on the path.
MAX_LINK_METRIC：パス上の各リンクの選択されたリンクメトリックの最大許容値。
MAX_PATH_COST: Maximum allowed value for the path metric of a selected path.
MAX_PATH_COST：選択したパスのパスメトリックの最大許容値。
PARENT_SWITCH_THRESHOLD: The difference between the cost of the path through the preferred parent and the minimum cost path in order to trigger the selection of a new preferred parent.
PARENT_SWITCH_THRESHOLD：優先される親を通るパスのコストと、新しい優先される親の選択をトリガーするための最小コストパスとの差。
PARENT_SET_SIZE: The number of candidate parents, including the preferred parent, in the parent set.
PARENT_SET_SIZE：親セット内の優先親を含む候補親の数。
ALLOW_FLOATING_ROOT: If set to 1, allows a node to become a floating root.
ALLOW_FLOATING_ROOT：1に設定すると、ノードをフローティングルートにすることができます。
The parameter values are assigned depending on the selected metric. The best values for these parameters are determined by the requirement of the specific RPL deployment. For instance, if we use ETX as the selected metric and UDP as the transport protocol, we should use a small MAX_LINK_METRIC (e.g., ETX of 1.1) so that link-layer retransmissions are sufficient to provide a good chance of end-to-end reliability.
パラメータ値は、選択したメトリックに応じて割り当てられます。これらのパラメーターの最適な値は、特定のRPLデプロイメントの要件によって決まります。たとえば、選択したメトリックとしてETXを使用し、トランスポートプロトコルとしてUDPを使用する場合は、小さなMAX_LINK_METRIC（たとえば、ETX 1.1）を使用して、リンク層の再送信がエンドツーエンドの十分な機会を提供できるようにする必要があります信頼性。
The working group has extensive experience routing with the ETX metric [Hui08b]. Based on those experiences, the following values are RECOMMENDED when ETX is the selected metric:
ワーキンググループは、ETXメトリック[Hui08b]を使用したルーティングの経験が豊富です。これらの経験に基づいて、ETXが選択されたメトリックである場合、以下の値が推奨されます。
MAX_LINK_METRIC: 512. Disallow links with greater than 4 expected transmission counts on the selected path.
MAX_LINK_METRIC：512。選択したパス上で4を超えると予想される送信カウントを持つリンクを許可しません。
MAX_PATH_COST: 32768. Disallow paths with greater than 256 expected transmission counts.
MAX_PATH_COST：32768。256を超えると予想される送信カウントを持つパスを禁止します。
PARENT_SWITCH_THRESHOLD: 192. Switch to a new path only if it is expected to require at least 1.5 fewer transmissions than the current path.
PARENT_SWITCH_THRESHOLD：192.現在のパスより少なくとも1.5少ない送信が必要と予想される場合にのみ、新しいパスに切り替えます。
PARENT_SET_SIZE: 3. If the preferred parent is not available, two candidate parents are still available without triggering a new round of route discovery.
PARENT_SET_SIZE：3.優先される親が利用できない場合、ルート探索の新しいラウンドをトリガーすることなく、2つの候補の親がまだ利用可能です。
ALLOW_FLOATING_ROOT: 0. Do not allow a node to become a floating root.
ALLOW_FLOATING_ROOT：0。ノードがフローティングルートになることを許可しません。
Section 18 of [RFC6550] depicts the management of RPL. 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は、RPLの管理を示しています。この仕様はそのセクションとそのサブセクションから継承されますが、[RFC6551]で指定されているメトリックは使用されず、管理を必要としません。
An implementation SHOULD allow the following parameters to be configured at installation time: MAX_LINK_METRIC, MAX_PATH_COST, PARENT_SWITCH_THRESHOLD, PARENT_SET_SIZE, and ALLOW_FLOATING_ROOT. An implementation MAY allow these parameters to be configured dynamically at run time once a network has been deployed.
実装では、インストール時に次のパラメーターを構成できるようにする必要があります：MAX_LINK_METRIC、MAX_PATH_COST、PARENT_SWITCH_THRESHOLD、PARENT_SET_SIZE、およびALLOW_FLOATING_ROOT。実装では、ネットワークが展開された後、これらのパラメーターを実行時に動的に構成できます。
A MRHOF implementation MUST support the DODAG Configuration option as described in [RFC6550] and apply the parameters it specifies. Care should be taken in the relationship between the MRHOF PARENT_SWITCH_THRESHOLD parameter and the RPL MaxRankIncrease parameter. For example, if MaxRankIncrease is smaller than PARENT_SWITCH_THRESHOLD, a RPL node using MRHOF could enter a situation in which its current preferred parent causes the node's Rank to increase more than MaxRankIncrease but MRHOF does not change preferred parents. This could cause the node to leave the routing topology even though there may be other members of the parent set that would allow the node's Rank to remain within MaxRankIncrease.
MRHOF実装は、[RFC6550]で説明されているDODAG構成オプションをサポートし、それが指定するパラメーターを適用する必要があります。 MRHOF PARENT_SWITCH_THRESHOLDパラメーターとRPL MaxRankIncreaseパラメーターの関係には注意が必要です。たとえば、MaxRankIncreaseがPARENT_SWITCH_THRESHOLDより小さい場合、MRHOFを使用するRPLノードは、現在の優先親がノードのランクをMaxRankIncreaseよりも高くするが、MRHOFは優先親を変更しないという状況に入る可能性があります。これにより、ノードのランクがMaxRankIncrease内に留まることを可能にする親セットの他のメンバーが存在する場合でも、ノードがルーティングトポロジーを離れる可能性があります。
Unless configured otherwise, a MRHOF implementation SHOULD use the default parameters as specified in Section 5.
特に設定されていない限り、MRHOF実装では、セクション5で指定されているデフォルトのパラメーターを使用する必要があります（SHOULD）。
Because of the partially coupled relationship between Rank and metric values, networks using MRHOF require care in setting MinHopRankIncrease. A large MinHopRankIncrease will cause MRHOF to be unable to select paths with different hop counts but similar metric values. If MinHopRankIncrease is large enough that its increment is greater than that caused by link cost, then metrics will be used to select a preferred parent, but the advertised Rank will be a simple hop count. This behavior might be desirable, but it also might be unintended; care is recommended.
ランクとメトリック値の間には部分的に結合された関係があるため、MRHOFを使用するネットワークでは、MinHopRankIncreaseの設定に注意が必要です。 MinHopRankIncreaseが大きいと、MRHOFは、ホップカウントが異なるがメトリック値が類似しているパスを選択できなくなります。 MinHopRankIncreaseが十分に大きく、その増分がリンクコストによって引き起こされるものより大きい場合、メトリックは優先される親を選択するために使用されますが、アドバタイズされるランクは単純なホップカウントになります。この動作は望ましいかもしれませんが、意図されていない場合もあります。お手入れをお勧めします。
With ETX as the selected metric, RPL's Rank advertisement rules can require a DODAG Root to advertise a Rank higher than its corresponding ETX value, as a DODAG Root advertises a Rank of MinHopRankIncrease. Because all DODAG Roots within a DODAG Version advertise the same Rank, this constant value typically does not affect route selection. Nevertheless, it means that if a DODAG Version has a MinHopRankIncrease of M and a path has an advertised ETX of E, then the actual ETX of the path is likely closer to a value of E-M than a value of E.
ETXを選択したメトリックとして、RPLのランクアドバタイズメントルールは、DODAGルートがMinHopRankIncreaseのランクをアドバタイズするため、DODAGルートが対応するETX値よりも高いランクをアドバタイズすることを要求できます。 DODAGバージョン内のすべてのDODAGルートは同じランクをアドバタイズするため、この定数値は通常、ルートの選択に影響を与えません。それでも、DODAGバージョンのMのMinHopRankIncreaseがあり、パスにEのETXがアドバタイズされている場合、パスの実際のETXはEの値よりもE-Mの値に近い可能性が高いことを意味します。
A MRHOF implementation should provide an interface for monitoring its operation. At a minimum, the information provided should include:
MRHOF実装は、その動作を監視するためのインターフェイスを提供する必要があります。提供される情報には、少なくとも次のものが含まれている必要があります。
DAG information as specified in Section 6.3.1 of [RFC6550], 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、操作モード、このノードのランク、現在のバージョン番号、固定フラグの値など。
A list of neighbors indicating the preferred parent. The list should indicate, for each neighbor, the Rank, the current Version Number, the value of the Grounded flag, and associated metrics.
優先される親を示すネイバーのリスト。リストには、各ネイバーのランク、現在のバージョン番号、固定フラグの値、および関連するメトリックが示されているはずです。
Thanks to Antonio Grilo, Nicolas Tsiftes, Matteo Paris, JP Vasseur, and Phoebus Chen for their comments. Thanks to Barry Leiba, Brian Haberman, Martin Stiemerling, Ralph Droms, Robert Sparks, Russ Housley, Stephen Farrell, Wesley Eddy, Miguel A. Garcia, Mukul Goyal, and Michael Richardson for their feedback during the publication phase of this document.
Antonio Grilo、Nicolas Tsiftes、Matteo Paris、JP Vasseur、およびPhoebus Chenのコメントに感謝します。このドキュメントの公開段階でのフィードバックを提供してくれたBarry Leiba、Brian Haberman、Martin Stiemerling、Ralph Droms、Robert Sparks、Russ Housley、Stephen Farrell、Wesley Eddy、Miguel A. Garcia、Mukul Goyal、Michael Richardsonに感謝します。
Per this document, IANA has allocated value 1 from the "Objective Code Point (OCP)" sub-registry of the "Routing Protocol for Low Power and Lossy Networks (RPL)" registry.
このドキュメントに従って、IANAは「低電力および損失の多いネットワーク（RPL）のルーティングプロトコル」レジストリの「Objective Code Point（OCP）」サブレジストリから値1を割り当てました。
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-SEC]. This document does not introduce new flows or new messages, and thus requires no specific mitigation for new threats.
この仕様はRPLを単純に拡張するため、[RFC6550]と[ROLL-SEC]で説明されているセキュリティの問題とメカニズムに対して脆弱であり、その恩恵を受けます。このドキュメントでは、新しいフローや新しいメッセージを紹介していないため、新しい脅威に対する特別な緩和策は必要ありません。
MRHOF depends on information exchanged in a number of RPL protocol elements. If those elements were compromised, then an implementation of MRHOF 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.
MRHOFは、多くのRPLプロトコル要素で交換される情報に依存しています。これらの要素が危険にさらされた場合、MRHOFの実装により、パケットに対して誤ったパスが生成され、ルーティングが誤って行われる可能性があります。したがって、ルーティング情報が変更またはスプーフィングされるリスクがある場合は、RPLセキュリティメカニズムを使用することをお勧めします。
[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., Thubert, P., 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.、Brandt、A.、Hui、J.、Kelsey、R.、Levis、P.、Pister、K.、Struik、R.、Vasseur、JP、およびR 。Alexander、「RPL：低電力および損失の多いネットワーク用のIPv6ルーティングプロトコル」、RFC 6550、2012年3月。
[RFC6551] Vasseur, JP., Kim, M., 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、JP。、Kim、M.、Pister、K.、Dejean、N。、およびD. Barthel、「低電力および損失の多いネットワークでのパス計算に使用されるルーティングメトリック」、RFC 6551、2012年3月。
[Hui08b] Hui, J. and D. Culler, "IP is dead, long live IP for wireless sensor networks", Proceedings of the 6th ACM Conference on Embedded Networked Systems SenSys 2008, November 2008, <http://portal.acm.org/citation.cfm?id=1460412.1460415>.
[Hui08b] Hui、J。およびD. Culler、「IPは死んでいる、ワイヤレスセンサーネットワークにとって長生きするIP」、第6回ACM会議の議事録、組み込みネットワークシステムSenSys 2008、2008年11月、<http：//portal.acm .org / citation.cfm？id = 1460412.1460415>。
[ROLL-SEC] 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, January 2012.
[ROLL-SEC] Tsao、T.、Alexander、R.、Dohler、M.、Daza、V。、およびA. Lozano、「低電力および損失の多いネットワークを介したルーティングのためのセキュリティフレームワーク」、作業中、2012年1月。
[ROLL-TERM] Vasseur, J., "Terminology in Low power And Lossy Networks", Work in Progress, September 2011.
[ロールターム] Vasseur、J。、「低電力および損失の多いネットワークの用語」、作業中、2011年9月。
Authors' Addresses
著者のアドレス
Omprakash Gnawali University of Houston PGH 577, University of Houston Houston, TX 77204 USA
Omprakash Gnawaliヒューストン大学PGH 577、ヒューストン大学ヒューストン、テキサス77204米国
Phone: +1 713 743 3356
EMail: gnawali@cs.uh.edu
Philip Levis Stanford University 412 Gates Hall, Stanford University Stanford, CA 94305 USA
フィリップ・リーバイススタンフォード大学412ゲイツホール、スタンフォード大学スタンフォード、カリフォルニア94305アメリカ
EMail: pal@cs.stanford.edu