[要約] RFC 6551は、低消費電力かつ損失の多いネットワークでの経路計算に使用されるルーティングメトリックについての要約です。このRFCの目的は、効率的な経路計算を可能にするために、適切なメトリックを定義することです。
Internet Engineering Task Force (IETF) JP. Vasseur, Ed.
Request for Comments: 6551 Cisco Systems
Category: Standards Track M. Kim, Ed.
ISSN: 2070-1721 Corporate Technology Group, KT
K. Pister
Dust Networks
N. Dejean
Elster SAS
D. Barthel
France Telecom Orange
March 2012
Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks
低電力および損失ネットワークでのパス計算に使用されるルーティングメトリック
Abstract
概要
Low-Power and Lossy Networks (LLNs) have unique characteristics compared with traditional wired and ad hoc networks that require the specification of new routing metrics and constraints. By contrast, with typical Interior Gateway Protocol (IGP) routing metrics using hop counts or link metrics, this document specifies a set of link and node routing metrics and constraints suitable to LLNs to be used by the Routing Protocol for Low-Power and Lossy Networks (RPL).
低電力および損失ネットワーク（LLN）は、新しいルーティングメトリックと制約の仕様を必要とする従来の有線およびアドホックネットワークと比較して、独自の特性を持っています。対照的に、ホップカウントまたはリンクメトリックを使用して、典型的なインテリアゲートウェイプロトコル（IGP）ルーティングメトリックを使用して、このドキュメントは、低電力および損失のあるネットワークのルーティングプロトコルで使用されるLLNに適したリンクおよびノードルーティングメトリックと制約のセットを指定します。（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/rfc6551.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6551で取得できます。
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.
この文書の公開。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Requirements Language ......................................6
2. Object Formats ..................................................7
2.1. DAG Metric Container Format ................................7
2.2. Use of Multiple DAG Metric Containers .....................10
2.3. Metric Usage ..............................................10
3. Node Metric/Constraint Objects .................................11
3.1. Node State and Attribute Object ...........................11
3.2. Node Energy Object ........................................12
3.3. Hop Count Object ..........................................16
4. Link Metric/Constraint Objects .................................17
4.1. Throughput ................................................17
4.2. Latency ...................................................18
4.3. Link Reliability ..........................................19
4.3.1. The Link Quality Level Reliability Metric ..........19
4.3.2. The ETX Reliability Object .........................21
4.4. Link Color Object .........................................22
4.4.1. Link Color Object Description ......................22
4.4.2. Mode of Operation ..................................24
5. Computation of Dynamic Metrics and Attributes ..................24
6. IANA Considerations ............................................25
6.1. Routing Metric/Constraint Type ............................25
6.2. Routing Metric/Constraint TLVs ............................25
6.3. Routing Metric/Constraint Common Header Flag Field ........26
6.4. Routing Metric/Constraint Common Header A Field ...........26
6.5. NSA Object Flags Field ....................................26
6.6. Hop-Count Object Flags Field ..............................27
6.7. Node Type Field ...........................................27
7. Security Considerations ........................................27
8. Acknowledgements ...............................................28
9. References .....................................................28
9.1. Normative References ......................................28
9.2. Informative References ....................................28
This document makes use of the terminology defined in [ROLL-TERMS].
このドキュメントでは、[ロールターム]で定義されている用語を使用します。
Low-power and Lossy Networks (LLNs) have specific routing characteristics compared with traditional wired or ad hoc networks that have been spelled out in [RFC5548], [RFC5673], [RFC5826], and [RFC5867].
低電力および損失ネットワーク（LLN）は、[RFC5548]、[RFC5673]、[RFC5826]、および[RFC5867]で綴られている従来の有線またはアドホックネットワークと比較して特定のルーティング特性を持っています。
Historically, IGP, such as OSPF ([RFC2328]) and IS-IS ([RFC1195]), has used quantitative static link metrics. Other mechanisms, such as Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) (see [RFC2702] and [RFC3209]), make use of other link attributes such as the available reserved bandwidth (dynamic) or link affinities (most of the time static) to compute constrained shortest paths for Traffic Engineering Label Switched Paths (TE LSPs).
歴史的に、OSPF（[RFC2328]）やIS-IS（[RFC1195]）などのIGPは、定量的な静的リンクメトリックを使用しています。マルチプロトコルラベルスイッチング（MPLS）トラフィックエンジニアリング（TE）（[RFC2702]および[RFC3209]を参照）などのその他のメカニズムは、利用可能な予約帯域幅（動的）やリンクの親和性などの他のリンク属性（ほとんどの時間の時間（ほとんどの時間）などの他のリンク属性を使用しています。静的）トラフィックエンジニアリングラベルスイッチ付きパス（TE LSP）の制約された最短パスを計算する。
This document specifies routing metrics and constraints to be used in path calculation by the Routing Protocol for Low-Power and Lossy Networks (RPL) specified in [RFC6550].
このドキュメントは、[RFC6550]で指定された低電力および損失ネットワーク（RPL）のルーティングプロトコルによるパス計算で使用されるルーティングメトリックと制約を指定します。
One of the prime objectives of this document is to define a flexible mechanism for the advertisement of routing metrics and constraints used by RPL. Some RPL implementations may elect to adopt an extremely simple approach based on the use of a single metric with no constraint, whereas other implementations may use a larger set of link and node routing metrics and constraints. This specification provides a high degree of flexibility and a set of routing metrics and constraints. New routing metrics and constraints could be defined in the future, as needed.
このドキュメントの主な目的の1つは、RPLが使用するルーティングメトリックと制約の広告のための柔軟なメカニズムを定義することです。一部のRPL実装は、制約のない単一のメトリックの使用に基づいて非常に簡単なアプローチを採用することを選択する場合がありますが、他の実装では、より大きなリンクおよびノードルーティングメトリックと制約を使用する場合があります。この仕様は、高度な柔軟性とルーティングメトリックと制約のセットを提供します。必要に応じて、新しいルーティングメトリックと制約を将来定義できます。
The metrics and constraints defined in this document are carried in objects that are OPTIONAL from the point of view of a RPL implementation. This means that implementations are free to include different subsets of the functions (metric, constraint) defined in this document. Specific sets of metrics/constraints and other optional RPL parameters for use in key environments will be specified as compliance profiles in applicability profile documents produced by the ROLL working group. Note that RPL can even make use of no metric, for example, using the Objective Function defined in [RFC6552].
このドキュメントで定義されているメトリックと制約は、RPLの実装の観点からオプションのオブジェクトに掲載されています。これは、このドキュメントで定義されている機能の異なるサブセット（メトリック、制約）を自由に含めることができることを意味します。主要環境で使用するメトリック/制約およびその他のオプションのRPLパラメーターの特定のセットは、ロールワーキンググループが作成したアプリケーションプロファイルドキュメントのコンプライアンスプロファイルとして指定されます。RPLは、[RFC6552]で定義された目的関数を使用して、NOメトリックを使用することもできます。
RPL is a distance vector routing protocol variant that builds Directed Acyclic Graphs (DAGs) based on routing metrics and constraints. DAG formation rules are defined in [RFC6550]:
RPLは、ルーティングメトリックと制約に基づいて、指示された非環式グラフ（DAG）を構築する距離ベクトルルーティングプロトコルバリアントです。DAG形成ルールは[RFC6550]で定義されています。
o The Destination-Oriented Directed Acyclic Graph (DODAG) root, as defined in [RFC6550], may advertise a routing constraint used as a "filter" to prune links and nodes that do not satisfy specific properties. For example, it may be required for a path only to traverse nodes that are mains-powered or links that have at least a minimum reliability or a specific "color" reflecting a user-defined link characteristic (e.g., the link layer supports encryption).
o [rfc6550]で定義されている宛先指向の向き性環状グラフ（DODAG）ルートは、特定のプロパティを満たさないリンクとノードをプルンするための「フィルター」として使用されるルーティング制約を宣伝する場合があります。たとえば、パスが主電源であるノードをトラバースしたり、少なくとも最小の信頼性を持つリンクまたはユーザー定義のリンク特性を反映した特定の「色」を持つリンクにのみ必要とする場合があります（例えば、リンクレイヤーは暗号化をサポートします）。
o A routing metric is a quantitative value that is used to evaluate the path cost. Link and node metrics are usually (but not always) additive.
o ルーティングメトリックは、パスコストを評価するために使用される定量値です。リンクとノードのメトリックは、通常（常にではない）添加剤です。
The best path is the path that satisfies all supplied constraints (if any) and that has the lowest cost with respect to some specified metrics. It is also called the shortest constrained path (in the presence of constraints).
最良のパスは、提供されたすべての制約（ある場合）を満たし、指定されたメトリックに関して最も低いコストを持っているパスです。また、最短の制約パスとも呼ばれます（制約が存在する場合）。
Routing metrics may be categorized according to the following characteristics:
ルーティングメトリックは、次の特性に従って分類できます。
o Link versus node metrics
o リンク対ノードメトリック
o Qualitative versus quantitative
o 定性的と定量的
o Dynamic versus static
o 動的と静的
Routing requirements documents (see [RFC5673], [RFC5826], [RFC5548], and [RFC5867]) observe that it must be possible to take into account a variety of node constraints/metrics during path computation.
ルーティング要件文書（[RFC5673]、[RFC5826]、[RFC5548]、[RFC5867]を参照）は、パスコンピューテーション中にさまざまなノード制約/メトリックを考慮に入れることができる必要があることを観察します。
Some link or node characteristics (e.g., link reliability, remaining energy on the node) may be used by RPL either as routing constraints or as metrics (or sometimes both). For example, the path may be computed to avoid links that do not provide a sufficient level of reliability (use as a constraint) or as the path offering most links with a specified reliability level (use as a metric). This document provides the flexibility to use link and node characteristics as constraints and/or metrics.
いくつかのリンクまたはノードの特性（例：リンクの信頼性、ノードの残りエネルギー）は、RPLによってルーティング制約またはメトリック（またはその両方）として使用できます。たとえば、パスを計算して、十分なレベルの信頼性（制約として使用）を提供しないリンクを回避するか、指定された信頼性レベル（メトリックとして使用）を備えたほとんどのリンクを提供するパスとしてパスを計算できます。このドキュメントは、制約および/またはメトリックとしてリンクとノードの特性を使用する柔軟性を提供します。
The use of link and node routing metrics and constraints is not exclusive (e.g., it is possible to advertise a "hop count" both as a metric to optimize the computed path and as a constraint (e.g., "Path should not exceed n hops")).
リンクとノードのルーティングメトリックと制約の使用は排他的ではありません（たとえば、計算されたパスを最適化するメトリックとして、また制約として「ホップカウント」を宣伝することができます（例：「パスはnホップを超えてはいけません」））。
Links in LLN commonly have rapidly changing node and link characteristics; thus, routing metrics must be dynamic and techniques must be used to smooth out the dynamicity of these metrics so as to
LLNのリンクは、一般にノードとリンクの特性を急速に変化させます。したがって、ルーティングメトリックは動的でなければならず、これらのメトリックの動的性をスムーズにするために使用するためにテクニックを使用する必要があります。
avoid routing oscillations. For instance, in addition to the dynamic nature of some links (e.g., wireless but also Power Line Communication (PLC) links), nodes' resources, such as residual energy, are changing continuously and may have to be taken into account during the path computation.
振動をルーティングしないでください。たとえば、いくつかのリンクの動的な性質に加えて（例：ワイヤレスだけでなく電力線通信（PLC）リンク）、残留エネルギーなどのノードのリソースは継続的に変化しており、パス中に考慮する必要がある場合があります。計算。
It must be noted that the use of dynamic metrics is not new and has been experimented in ARPANET 2 (see [Zinky1989]). The use of dynamic metrics is not trivial and great care must be given to the use of dynamic metrics since it may lead to potential routing instabilities. That being said, a lot of experience has been gained over the years on the use of dynamic routing metrics, which have been deployed in a number of (non-IP) networks.
動的メトリックの使用は新しいものではなく、Arpanet 2で実験されていることに注意する必要があります（[Zinky1989]を参照）。動的メトリックの使用は些細なことではなく、潜在的なルーティングの不安定性につながる可能性があるため、動的メトリックの使用に細心の注意を払う必要があります。そうは言っても、多くの（非IP）ネットワークで展開されている動的ルーティングメトリックの使用に関する長年にわたって多くの経験が獲得されてきました。
Very careful attention must be given to the pace at which routing metrics and attributes values change in order to preserve routing stability. When using a dynamic routing metric, a RPL implementation should make use of a multi-threshold scheme rather than fine granular metric updates reflecting each individual change to avoid spurious and unnecessary routing changes.
ルーティングの安定性を維持するために、ルーティングメトリックと属性値が変化するペースに非常に注意する必要があります。動的ルーティングメトリックを使用する場合、RPLの実装は、偽りのルーティングの変更を避けるために、個々の変更を反映した細かい粒状メトリック更新ではなく、多科のメートルの更新を使用する必要があります。
The requirements on reporting frequency may differ among metrics; thus, different reporting rates may be used for each metric.
レポート頻度に関する要件は、メトリック間で異なる場合があります。したがって、各メトリックで異なる報告率を使用できます。
The set of routing metrics and constraints used by a RPL deployment is signaled along the DAG that is built according to the Objective Function (rules governing how to build a DAG) and the routing metrics and constraints are advertised in the DODAG Information Object (DIO) message specified in [RFC6550]. RPL may be used to build DAGs with different characteristics. For example, it may be desirable to build a DAG with the goal to maximize reliability by using the link reliability metric to compute the "best" path. Another example might be to use the energy node characteristic (e.g., mains-powered versus battery-operated) as a node constraint when building the DAG so as to avoid battery-powered nodes in the DAG while optimizing the link throughput.
RPL展開で使用されるルーティングメトリックと制約のセットは、目的関数（DAGの構築方法を管理する規則）に従って構築されたDAGに沿って通知され、ルーティングメトリックと制約はDoDAG情報オブジェクト（DIO）に宣伝されています[RFC6550]で指定されたメッセージ。RPLは、異なる特性を持つDAGを構築するために使用できます。たとえば、リンク信頼性メトリックを使用して「最良の」パスを計算することにより、信頼性を最大化するという目標を備えたDAGを構築することが望ましい場合があります。もう1つの例は、リンクスループットを最適化しながらDAGのバッテリー駆動型ノードを避けるために、DAGを構築する際のノードの制約として、エネルギーノードの特性（たとえば、主電源駆動対バッテリー操作）をノードの制約として使用することです。
The specification of Objective Functions used to compute the DAG built by RPL is out of the scope of this document. This document defines routing metrics and constraints that are decoupled from the Objective Function. So a generic Objective Function could, for example, specify the rules to select the best parents in the DAG, the number of backup parents, etc., and it could be used with any routing metrics and/or constraints such as the ones specified in this document.
RPLによって構築されたDAGを計算するために使用される目的関数の仕様は、このドキュメントの範囲外です。このドキュメントでは、目的関数から切り離されたルーティングメトリックと制約を定義します。したがって、一般的な目的関数は、たとえば、DAGの最高の親、バックアップ親の数などを選択するルールを指定し、で指定されたルーティングメトリックおよび/または制約で使用できます。このドキュメント。
Some metrics are either aggregated or recorded. An aggregated metric is adjusted as the DIO message travels along the DAG. For example, if the metric is the number of hops, each node updates the path cost that reflects the number of traversed hops along the DAG. By contrast, for a recorded metric, each node adds a sub-object reflecting the local valuation of the metric. For example, it might be desirable to record the link quality level along a path. In this case, each visited node adds a sub-object recording the local link quality level. In order to limit the number of sub-objects, the use of a counter may be desirable (e.g., record the number of links with a certain link quality level), thus, compressing the information to reduce the message length. Upon receiving the DIO message from a set of parents, a node might decide, according to the OF and local policy, which node to choose as a parent based on the maximum number of links with a specific link reliability level, for example.
一部のメトリックは、集約または記録されています。DIOメッセージがDAGに沿って移動すると、集約されたメトリックが調整されます。たとえば、メトリックがホップ数である場合、各ノードは、DAGに沿ったトラバースホップの数を反映するパスコストを更新します。対照的に、記録されたメトリックの場合、各ノードはメトリックの局所評価を反映したサブオブジェクトを追加します。たとえば、パスに沿ってリンクの品質レベルを記録することが望ましい場合があります。この場合、訪問した各ノードは、ローカルリンクの品質レベルを記録するサブオブジェクトを追加します。サブオブジェクトの数を制限するために、カウンターの使用が望ましい場合があります（たとえば、特定のリンクの品質レベルでリンクの数を記録する）。したがって、情報を圧縮してメッセージの長さを減らします。両親のセットからDIOメッセージを受信すると、ノードは、特定のリンクの信頼性レベルを持つリンクの最大数に基づいて親として選択するノードに従って、ノードを決定する可能性があります。
Note that the routing metrics and constraints specified in this document are not specific to any particular link layer. An internal API between the Medium Access Control (MAC) layer and RPL may be used to accurately reflect the metrics values of the link (wireless, wired, PLC).
このドキュメントで指定されているルーティングメトリックと制約は、特定のリンクレイヤーに固有のものではないことに注意してください。中間アクセス制御（MAC）レイヤーとRPL間の内部APIを使用して、リンクのメトリック値（ワイヤレス、ワイヤード、PLC）を正確に反映できます。
Since a set of metrics and constraints will be used for links and nodes in a LLN, it is critical to ensure the use of consistent metric calculation mechanisms for all links and nodes in the network, similar to the case of inter-domain IP routing.
LLNのリンクとノードに一連のメトリックと制約が使用されるため、ドメイン間IPルーティングの場合と同様に、ネットワーク内のすべてのリンクとノードに一貫したメトリック計算メカニズムを使用することが重要です。
There are many different permutations of options that may be appropriate in different deployments. Implementations must clearly state which options they include, and they must state which are default and which are configurable as options within the implementation. Applicability statements will be developed within the ROLL working group to clarify which options are applicable to the specific deployment scenarios indicated by [RFC5673], [RFC5826], [RFC5548], and [RFC5867].
さまざまな展開で適切なオプションにはさまざまな順列があります。実装は、どのオプションを含めるオプションを明確に述べる必要があり、どのオプションがデフォルトであり、実装内のオプションとして構成可能なものを述べなければなりません。アプリケーションステートメントは、[RFC5673]、[RFC5826]、[RFC5548]、および[RFC5867]で示されている特定の展開シナリオに適用可能なオプションを明確にするために、ロールワーキンググループ内で開発されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 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", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
Routing metrics and constraints are carried within the DAG Metric Container object defined in [RFC6550]. Should multiple metrics and/or constraints be present in the DAG Metric Container, their use to determine the "best" path can be defined by an Objective Function.
ルーティングメトリックと制約は、[RFC6550]で定義されているDAGメトリックコンテナオブジェクト内で運ばれます。DAGメトリックコンテナに複数のメトリックおよび/または制約が存在する場合、「最良の」パスを決定するための使用は、目的関数によって定義できます。
The Routing Metric/Constraint objects represent a metric or a constraint of a particular type. They may appear in any order in the DAG Metric Container (specified in [RFC6550]). They have a common format consisting of one or more bytes with a common header.
ルーティングメトリック/制約オブジェクトは、特定のタイプのメトリックまたは制約を表します。それらは、DAGメトリックコンテナ（[RFC6550]で指定）に任意の順序で表示される場合があります。それらは、共通のヘッダーを備えた1つ以上のバイトで構成される共通の形式を持っています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Routing-MC-Type|Res Flags|P|C|O|R| A | Prec | Length (bytes)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (object body) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Routing Metric/Constraint Object Generic Format
図1：ルーティングメトリック/制約オブジェクト汎用形式
The object body carries one or more sub-objects defined later in this document. Note that an object may carry a TLV, which may itself comprise other TLVs. A TLV carried within a TLV is called a TLV in this specification.
オブジェクト本体には、このドキュメントで定義された1つ以上のサブオブジェクトが含まれています。オブジェクトはTLVを運ぶ場合があることに注意してください。これは、それ自体が他のTLVで構成される場合があります。TLV内で運ばれるTLVは、この仕様でTLVと呼ばれます。
Routing-MC-Type (Routing Metric/Constraint Type - 8 bits): the Routing Metric/Constraint Type field uniquely identifies each Routing Metric/Constraint object and is managed by IANA.
Routing-MC-Type（ルーティングメトリック/制約タイプ-8ビット）：ルーティングメトリック/制約タイプフィールドは、各ルーティングメトリック/制約オブジェクトを一意に識別し、IANAによって管理されます。
Length (8 bits): this field defines the length of the object body, expressed in bytes. It ranges from 0 to 255.
長さ（8ビット）：このフィールドは、バイトで表されるオブジェクト本体の長さを定義します。0から255の範囲です。
Res Flags field (16 bits). The Flag field of the Routing Metric/ Constraint object is managed by IANA. Unassigned bits are considered as reserved. They MUST be set to zero on transmission and MUST be ignored on receipt.
RESフラグフィールド（16ビット）。ルーティングメトリック/制約オブジェクトのフラグフィールドは、IANAによって管理されています。割り当てられていないビットは予約済みと見なされます。それらは送信時にゼロに設定する必要があり、受領時に無視する必要があります。
The following bits of the Routing Metric/Constraint Flag field object are currently defined:
ルーティングメトリック/制約フラグフィールドオブジェクトの次のビットが現在定義されています。
o 'P' flag: the P field is only used for recorded metrics. When cleared, all nodes along the path successfully recorded the corresponding metric. When set, this indicates that one or several nodes along the path could not record the metric of interest (either because of lack of knowledge or because this was prevented by policy).
o 「P」フラグ：Pフィールドは、記録されたメトリックにのみ使用されます。クリアすると、パスに沿ったすべてのノードが対応するメトリックを正常に記録しました。設定すると、これは、パスに沿った1つまたは複数のノードが関心のあるメトリックを記録できないことを示しています（知識不足のため、またはこれがポリシーによって防止されたため）。
o 'C' flag. When set, this indicates that the Routing Metric/ Constraint object refers to a routing constraint. When cleared, the routing object refers to a routing metric.
o 「C」フラグ。設定すると、これはルーティングメトリック/制約オブジェクトがルーティングの制約を指すことを示します。クリアされると、ルーティングオブジェクトはルーティングメトリックを指します。
o 'O' flag: The 'O' flag is used exclusively for routing constraints ('C' flag is set). When set, this indicates that the constraint specified in the body of the object is optional. When cleared, the constraint is mandatory. If the 'C' flag is zero, the 'O' flag MUST be set to zero on transmission and ignored on reception.
o 「O」フラグ：「O」フラグは、ルーティング制約のみに使用されます（「C」フラグが設定されています）。設定すると、これはオブジェクトの本体で指定された制約がオプションであることを示します。クリアされると、制約は必須です。「C」フラグがゼロの場合、「O」フラグを送信時にゼロに設定し、レセプションで無視する必要があります。
o 'R' flag: The 'R' flag is only relevant for a routing metric (C=0) and MUST be cleared for C=1. When set, this indicates that the routing metric is recorded along the path. Conversely, when cleared, the routing metric is aggregated.
o 'r'フラグ： 'r'フラグは、ルーティングメトリック（c = 0）にのみ関連し、c = 1でクリアする必要があります。設定すると、これはルーティングメトリックがパスに沿って記録されていることを示します。逆に、クリアされると、ルーティングメトリックが集約されます。
A Field (3 bits): The A field is only relevant for metrics and is used to indicate whether the aggregated routing metric is additive, is multiplicative, reports a maximum, or reports a minimum.
Aフィールド（3ビット）：Aフィールドはメトリックにのみ関連し、集約されたルーティングメトリックが加算的であるか、乗法的であるか、最大を報告するか、最小を報告するかを示すために使用されます。
o A=0: The routing metric is additive
o a = 0：ルーティングメトリックは追加性です
o A=1: The routing metric reports a maximum
o A = 1：ルーティングメトリックは最大を報告します
o A=2: The routing metric reports a minimum
o a = 2：ルーティングメトリックは最小限に報告します
o A=3: The routing metric is multiplicative
o A = 3：ルーティングメトリックは乗算です
The A field has no meaning when the 'C' flag is set (i.e., when the Routing Metric/Constraint object refers to a routing constraint) and is only valid when the 'R' bit is cleared. Otherwise, the A field MUST be set to 0 and MUST be ignored on receipt.
Aフィールドには、「c」フラグが設定されている場合（つまり、ルーティングメトリック/制約オブジェクトがルーティング制約を参照する場合）、「r」ビットがクリアされた場合にのみ有効である場合の意味がありません。それ以外の場合、Aフィールドは0に設定する必要があり、受信時に無視する必要があります。
Prec field (4 bits): The Prec field indicates the precedence of this Routing Metric/Constraint object relative to other objects in the container. This is useful when a DAG Metric Container contains several Routing Metric objects. Its value ranges from 0 to 15. The value 0 means the highest precedence.
PRECフィールド（4ビット）：PRECフィールドは、コンテナ内の他のオブジェクトに対するこのルーティングメトリック/制約オブジェクトの優先順位を示します。これは、DAGメトリックコンテナにいくつかのルーティングメトリックオブジェクトが含まれている場合に役立ちます。その値は0〜15の範囲です。値0は、最高の優先度を意味します。
Example 1: A DAG formed by RPL where all nodes must be mains-powered and the best path is the one with lower aggregated expected transmission count (ETX). In this case, the DAG Metric Container
例1：すべてのノードが主電源を搭載し、最良のパスは、凝集予想伝送カウント（ETX）が低いものであるRPLによって形成されるDAGです。この場合、DAGメトリックコンテナ
carries two Routing Metric/Constraint objects: one is an ETX metric object with header (C=0, O=0, A=00, R=0) and the second one is a Node Energy constraint object with header (C=1, O=0, A=00, R=0). Note that a RPL Instance may use the metric object to report a maximum (A=1) or a minimum (A=2). If, for example, the best path is characterized by the path avoiding low quality links, then the path metric reports a maximum (A=1) (the higher the ETX, the lower the link quality): when the DIO message reporting the link quality metric (ETX) is processed by a node, each node selecting the advertising node as a parent updates the value carried in the metric object by replacing it with its local link ETX value if and only if the latter is higher. As far as the constraint is concerned, the object body will carry a Node Energy constraint object defined in Section 3.1 indicating that nodes must be mains-powered: if the constraint signaled in the DIO message is not satisfied, the advertising node is just not selected as a parent by the node that processes the DIO message.
2つのルーティングメトリック/制約オブジェクトを搭載しています。1つはヘッダーを備えたETXメトリックオブジェクト（C = 0、O = 0、A = 00、r = 0）で、2つ目はヘッダー付きのノードエネルギー制約オブジェクトです（C = 1、 o = 0、a = 00、r = 0）。 RPLインスタンスは、メトリックオブジェクトを使用して最大（a = 1）または最小（a = 2）を報告する場合があることに注意してください。たとえば、最適なパスが低品質のリンクを回避するパスによって特徴付けられる場合、パスメトリックは最大（a = 1）（ETXが高いほど、リンクの品質が低く）を報告します。品質メトリック（ETX）はノードで処理され、各ノードは広告ノードを選択して、親として広告ノードを選択し、メトリックオブジェクトに配信される値を更新し、後者が高い場合にのみローカルリンクETX値に置き換えます。制約に関する限り、オブジェクト本体はセクション3.1で定義されているノードエネルギー制約オブジェクトを運びます。ノードは主電源である必要があることを示します。DIOメッセージでシグナルが満たされていない場合、広告ノードは選択されていませんDIOメッセージを処理するノードの親として。
Example 2: A DAG formed by RPL where the link metric is the link quality level (defined in Section 4) and link quality levels must be recorded along the path. In this case, the DAG Metric Container carries a Routing Metric/Constraint object: link quality level metric (C=0, O=0, A=00, R=1) containing multiple sub-objects.
例2：リンクメトリックがリンクの品質レベル（セクション4で定義）で、リンクの品質レベルがパスに沿って記録する必要があるRPLによって形成されるDAG。この場合、DAGメトリックコンテナには、ルーティングメトリック/制約オブジェクトが搭載されています。リンク品質レベルメトリック（c = 0、o = 0、a = 00、r = 1）を含む複数のサブオブジェクトが含まれています。
A Routing Metric/Constraint object may also include one or more additional type-length-value (TLV) encoded data sets. Each Routing Metric/Constraint TLV has the same structure:
ルーティングメトリック/制約オブジェクトには、1つ以上の追加のタイプ長価値（TLV）エンコードされたデータセットも含まれる場合があります。各ルーティングメトリック/制約TLVには同じ構造があります。
Type: 1 byte Length: 1 byte Value: variable
タイプ：1バイトの長さ：1バイト値：変数
A Routing Metric/Constraint TLV is comprised of 1 byte for the type, 1 byte specifying the TLV length, and a value field. The TLV length field defines the length of the value field in bytes (from 0 to 255).
ルーティングメトリック/制約TLVは、タイプの1バイト、TLV長さを指定する1バイト、値フィールドで構成されています。TLVの長さフィールドは、バイトフィールドの長さ（0から255）の長さを定義します。
Unrecognized TLVs MUST be silently ignored while still being propagated in DIOs generated by the receiving node.
認識されていないTLVは、受信ノードによって生成されたDIOで伝播されている間、静かに無視する必要があります。
IANA manages the codepoints for all TLVs carried in routing constraint/metric objects.
IANAは、ルーティング制約/メトリックオブジェクトで運ばれるすべてのTLVのコードポイントを管理します。
IANA management of the Routing Metric/Constraint objects identifier codespace is described in Section 6.
ルーティングメトリック/制約オブジェクトのIANA管理識別子コーダースパースについては、セクション6で説明します。
Since the length of RPL options is encoded using 1 octet, they cannot exceed 255 bytes, which also applies to the DAG Metric Container. In the vast majority of cases, the advertised routing metrics and constraints will not require that much space. However, there might be circumstances where larger space is required, should, for example, a set of routing metrics be recorded along a long path. In this case, in order to avoid overflow, as specified in [RFC6550], routing metrics will be carried using multiple DAG Metric Container objects.
RPLオプションの長さは1 Octetを使用してエンコードされるため、255バイトを超えることはできません。これはDAGメトリックコンテナにも適用されます。大多数の場合、広告されたルーティングメトリックと制約には、それほど多くのスペースは必要ありません。ただし、たとえば、より大きなスペースが必要な状況が必要な場合があります。たとえば、長い経路に沿って一連のルーティングメトリックを記録する必要があります。この場合、[RFC6550]で指定されているオーバーフローを回避するために、ルーティングメトリックは複数のDAGメトリックコンテナオブジェクトを使用して運ばれます。
In the rest of this document, this use of multiple DAG Metric Container objects will be considered as if they were actually just one long DAG Metric Container object.
このドキュメントの残りの部分では、この複数のDAGメトリックコンテナオブジェクトの使用は、実際には1つの長いDAGメトリックコンテナオブジェクトであるかのように見なされます。
When the DAG Metric Container contains a single aggregated metric (scalar value), the order relation to select the best path is implicitly derived from the metric type. For example, lower is better for Hop Count, Link Latency, and ETX. Conversely, for Node Energy or Throughput, higher is better.
DAGメトリックコンテナに単一の集約メトリック（スカラー値）が含まれている場合、最適なパスを選択するための順序関係は、メートル法タイプから暗黙的に導出されます。たとえば、ホップカウント、リンクレイテンシ、およびETXには低い方が適しています。逆に、ノードエネルギーまたはスループットの場合、より高い方が優れています。
An example of using such a single aggregated metric is optimizing routing for node energy. The Node Energy metric (E_E field) defined in Section 3.2 is aggregated along paths with an explicit min function (A field), and the best path is selected through an implied Max function because the metric is Energy.
このような単一の集計メトリックを使用する例は、ノードエネルギーのルーティングを最適化することです。セクション3.2で定義されているノードエネルギーメトリック（E_Eフィールド）は、明示的な最小関数（フィールド）のパスに沿って集約され、メトリックがエネルギーであるため、暗黙のMAX関数を介して最適なパスが選択されます。
When the DAG Metric Container contains several aggregated metrics, they are to be used as tiebreakers according to their precedence defined by their Prec field values.
DAGメトリックコンテナにいくつかの集計メトリックが含まれている場合、それらは、PRECフィールド値で定義された優先順位に応じてタイブレーカーとして使用されます。
An example of such use of multiple aggregated metrics is the following: Hop Count as the primary criterion, Link Quality Level (LQL) as the secondary criterion, and Node Energy as the ultimate tiebreaker. In such a case, the Hop Count, LQL, and Node Energy metric objects' Prec fields should bear strictly increasing values such as 0, 1, and 2, respectively.
複数の集約されたメトリックのこのような使用の例は次のとおりです。ホップカウントプライマリ基準としてのホップカウント、二次基準としてのリンク品質レベル（LQL）、究極のタイブレーカーとしてのノードエネルギー。そのような場合、ホップカウント、LQL、およびノードエネルギーメトリックオブジェクトのPRECフィールドは、それぞれ0、1、2などの厳密に増加する値を担います。
If several aggregated metrics happen to bear the same Prec value, the behavior is implementation dependent.
いくつかの集計されたメトリックが同じPREC値を担っている場合、動作は実装に依存します。
Sections 3 and 4 specify several link and node metric/constraint objects. In some cases, it is stated that there must not be more than one object of a specific type. In that case, if a RPL implementation receives more than one object of that type, the second object MUST silently be ignored.
セクション3および4は、いくつかのリンクおよびノードメトリック/制約オブジェクトを指定します。場合によっては、特定のタイプのオブジェクトを1つ以上存在してはならないと述べられています。その場合、RPL実装がそのタイプの複数のオブジェクトを受信する場合、2番目のオブジェクトは静かに無視する必要があります。
In the presence of a constraint, a node MUST include a metric of the same type. That metric is used to check whether or not the constraint is met. In all cases, a node MUST not change the content of the constraint.
制約が存在する場合、ノードには同じタイプのメトリックを含める必要があります。そのメトリックは、制約が満たされているかどうかを確認するために使用されます。すべての場合において、ノードは制約のコンテンツを変更してはなりません。
The Node State and Attribute (NSA) object is used to provide information on node characteristics.
ノード状態と属性（NSA）オブジェクトは、ノード特性に関する情報を提供するために使用されます。
The NSA object MAY be present in the DAG Metric Container. There MUST NOT be more than one NSA object as a constraint per DAG Metric Container, and there MUST NOT be more than one NSA object as a metric per DAG Metric Container.
NSAオブジェクトは、DAGメトリックコンテナに存在する場合があります。DAGメトリックコンテナあたりの制約として1つ以上のNSAオブジェクトが存在してはならず、DAGメトリックコンテナあたりのメトリックとして1つ以上のNSAオブジェクトがないはずです。
The NSA object may also contain a set of TLVs used to convey various node characteristics. No TLV is currently defined.
NSAオブジェクトには、さまざまなノード特性を伝達するために使用されるTLVのセットも含まれている場合があります。現在、TLVは定義されていません。
The NSA Routing Metric/Constraint Type has been assigned value 1 by IANA.
NSAルーティングメトリック/制約タイプには、IANAによって値1が割り当てられています。
The format of the NSA object body is as follows:
NSAオブジェクト本体の形式は次のとおりです。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
| Res | Flags |A|O| Optional TLVs
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
Figure 2: NSA Object Body Format
図2：NSAオブジェクトボディ形式
Res flags (8 bits): Reserved field. This field MUST be set to zero on transmission and MUST be ignored on receipt.
RESフラグ（8ビット）：予約済みフィールド。このフィールドは、送信時にゼロに設定する必要があり、受領時に無視する必要があります。
Flags field (8 bits). The following two bits of the NSA object are currently defined:
フラグフィールド（8ビット）。NSAオブジェクトの次の2つのビットが現在定義されています。
o 'A' flag: data Aggregation Attribute. Data aggregation is listed as a requirement in Section 6.2 of [RFC5548]. Some applications may make use of the aggregation node attribute in their routing
o 「A」フラグ：データ集約属性。データ集約は、[RFC5548]のセクション6.2の要件としてリストされています。一部のアプリケーションは、ルーティングで集約ノード属性を利用する場合があります
decision so as to minimize the amount of traffic on the network, thus, potentially increasing its lifetime in battery operated environments. Applications where highly directional data flow is expected on a regular basis may take advantage of data aggregation supported routing. When set, this indicates that the node can act as a traffic aggregator. Further documents MAY define optional TLVs to describe the node traffic aggregator functionality.
ネットワーク上のトラフィックの量を最小限に抑えるために決定し、したがって、バッテリー動作環境での寿命が増加する可能性があります。高度な方向性のデータフローが定期的に期待されるアプリケーションは、データ集約サポートされたルーティングを利用する場合があります。設定すると、これはノードがトラフィックアグリゲーターとして機能することを示します。さらなるドキュメントは、ノードトラフィックアグリゲーター機能を説明するためにオプションのTLVを定義する場合があります。
o 'O' flag: node workload may be hard to determine and express in some scalar form. However, node workload could be a useful metric to consider during path calculation, in particular when queuing delays must be minimized for highly sensitive traffic considering Medium Access Control (MAC) layer delay. Node workload MAY be set upon CPU overload, lack of memory, or any other node related conditions. Using a simple 1-bit flag to characterize the node workload provides a sufficient level of granularity, similar to the "overload" bit used in routing protocols such as IS-IS. Algorithms used to set the overload bit and to compute paths to potentially avoid nodes with their overload bit set are outside the scope of this document, but it is RECOMMENDED to avoid frequent changes of this bit to avoid routing oscillations. When set, this indicates that the node is overloaded and may not be able to process traffic.
o 'o'フラグ：ノードワークロードは、いくつかのスカラー形式で決定し、表現するのが難しい場合があります。ただし、ノードワークロードは、特に中程度のアクセス制御（MAC）層の遅延を考慮して非常に敏感なトラフィックの場合、キューイングの遅延を最小限に抑える必要がある場合に、パス計算中に考慮するのに役立つメトリックになる可能性があります。ノードワークロードは、CPU過負荷、メモリの不足、またはその他のノード関連条件で設定される場合があります。単純な1ビットフラグを使用してノードワークロードを特徴付けることで、IS-ISなどのルーティングプロトコルで使用される「過負荷」ビットと同様に、十分なレベルの粒度が得られます。オーバーロードビットを設定し、過負荷ビットセットを使用してノードを潜在的に回避するためにパスを計算するために使用されるアルゴリズムは、このドキュメントの範囲外ですが、振動のルーティングを避けるためにこのビットの頻繁な変更を避けることをお勧めします。設定すると、これはノードが過負荷であり、トラフィックを処理できない可能性があることを示します。
The unspecified flag fields MUST be set to zero on transmission and MUST be ignored on receipt.
不特定のフラグフィールドは、送信時にゼロに設定する必要があり、受領時に無視する必要があります。
The Flags field of the NSA Routing Metric/Constraint object is managed by IANA. Unassigned bits are considered as reserved.
NSAルーティングメトリック/制約オブジェクトのフラグフィールドは、IANAによって管理されています。割り当てられていないビットは予約済みと見なされます。
It may sometimes be desirable to avoid selecting a node with low residual energy as a router; thus, the support for constraint-based routing is needed. In such cases, the routing protocol engine may compute a longer path (constraint based) for some traffic in order to increase the network life duration.
ルーターとして残留エネルギーが低いノードを選択しないようにすることが望ましい場合があります。したがって、制約ベースのルーティングのサポートが必要です。そのような場合、ルーティングプロトコルエンジンは、ネットワーク寿命を延ばすために、一部のトラフィックの長いパス（制約ベース）を計算する場合があります。
Power and energy are clearly critical resources in most LLNs. As yet, there is no simple abstraction that adequately covers the broad range of power sources and energy storage devices used in existing LLN nodes. These include mains-powered, primary batteries, energy scavengers, and a variety of secondary storage mechanisms. Scavengers may provide a reliable low level of power, such as might be available from a 4-20 mA loop; a reliable but periodic stream of power, such as provided by a well-positioned solar cell; or unpredictable power, such as might be provided by a vibrational energy scavenger on an intermittently powered pump. Routes that are
パワーとエネルギーは、ほとんどのLLNで明らかに重要なリソースです。まだ、既存のLLNノードで使用される広範な電源とエネルギー貯蔵装置を適切にカバーする単純な抽象化はありません。これらには、主電源駆動型のプライマリバッテリー、エネルギースカベンジャー、およびさまざまな二次貯蔵メカニズムが含まれます。スカベンジャーは、4〜20 mAのループから利用できるような信頼性の高い低レベルの電力を提供する場合があります。適切に位置する太陽電池によって提供されるような、信頼できるが定期的な電力の流れ。または、断続的に駆動したポンプ上の振動エネルギースカベンジャーによって提供される可能性のある予測不可能な電力。あるルート
viable when the sun is shining may disappear at night. A pump turning on may connect two previously disconnected sections of a network.
太陽が輝いているときに生存可能になると、夜は消える可能性があります。ポンプをオンにすると、ネットワークの以前に切断された2つのセクションを接続できます。
Storage systems, such as rechargeable batteries, often suffer substantial degradation if regularly used to full discharge, leading to different residual energy numbers for regular versus emergency operation. A route for emergency traffic may have a different optimum than one for regular reporting.
充電式バッテリーなどの貯蔵システムは、完全に排出するために定期的に使用されている場合、多くの場合、かなりの劣化に苦しみ、定期的な緊急事業と緊急操作のために異なる残留エネルギー数につながります。緊急交通のルートは、定期的なレポート用の1つとは異なる最適である場合があります。
Batteries used in LLNs often degrade substantially if their average current consumption exceeds a small fraction of the peak current that they can deliver. It is not uncommon for self-supporting nodes to have a combination of primary storage, energy scavenging, and secondary storage, leading to three different values for acceptable average current depending on the time frame being considered, e.g., milliseconds, seconds, and hours/years.
LLNで使用されるバッテリーは、現在の平均消費量が提供できるピーク電流のわずかな割合を超えた場合、多くの場合大幅に低下させます。自己サポートノードがプライマリストレージ、エネルギーの清掃、および二次ストレージの組み合わせを持つことは珍しくありません。年。
Raw power and energy values are meaningless without knowledge of the energy cost of sending and receiving packets, and lifetime estimates have no value without some higher-level constraint on the lifetime required of a device. In some cases, the path that exhausts the battery of a node on the bed table in a month may be preferable to a route that reduces the lifetime of a node in the wall to a decade.
生の電力とエネルギーの価値は、パケットの送信と受信のエネルギーコストの知識がなければ意味がありません。また、生涯の推定値は、デバイスに必要な生涯にわたってより高いレベルの制約なしに価値がありません。場合によっては、1か月でベッドテーブルのノードのバッテリーを排出するパスは、壁のノードの寿命を10年に減らすルートよりも好ましい場合があります。
Given the complexity of trying to address such a broad collection of constraints, this document defines two levels of fidelity in the solution.
このような幅広い制約のコレクションに対処しようとする複雑さを考えると、このドキュメントでは、ソリューションの2つのレベルの忠実度を定義します。
The simplest solution relies on a 2-bit field encoding three types of power sources: "powered", "battery", and "scavenger". This simple approach may be sufficient for many applications.
最も単純なソリューションは、「電源」、「バッテリー」、「スカベンジャー」の3種類の電源をエンコードする2ビットフィールドに依存しています。この単純なアプローチは、多くのアプリケーションで十分かもしれません。
The mid-complexity solution is a single parameter that can be used to encode the energetic happiness of both battery-powered and scavenging nodes. For scavenging nodes, the 8-bit quantity is the power provided by the scavenger divided by the power consumed by the application, E_E=P_in/P_out, in units of percent. Nodes that are scavenging more power than they are consuming will register above 100. A good time period for averaging power in this calculation may be related to the discharge time of the energy storage device on the node, but specifying this is out of the scope of this document. For battery-powered devices, E_E is the current expected lifetime divided by the desired minimum lifetime, in units of percent. The estimation of remaining battery energy and actual power consumption can be difficult, and the specifics of this calculation are out of scope of this document, but two examples are presented. If the node can measure its average power consumption, then E_E can be calculated as
Mid複合的なソリューションは、バッテリー駆動型ノードと清掃ノードの両方のエネルギー的な幸福をエンコードするために使用できる単一のパラメーターです。除去ノードの場合、8ビット量は、スカベンジャーによって提供される電力を、アプリケーションで消費する電力であるE_E = P_IN/P_OUTで、単位単位で除算します。消費しているよりも多くのパワーを除去しているノードは100を超えて登録されます。この計算の平均パワーに適した期間は、ノード上のエネルギー貯蔵装置の放電時間に関連している可能性がありますが、これを指定することは、このドキュメント。バッテリーを搭載したデバイスの場合、E_Eは、現在の予想される寿命を、割合の単位単位単位で、目的の最低寿命で割ったものです。残りのバッテリーエネルギーと実際の消費電力の推定は困難な場合があり、この計算の詳細はこのドキュメントの範囲外ですが、2つの例が示されています。ノードがその平均消費電力を測定できる場合、E_Eはとして計算できます
the ratio of desired max power (initial energy E_0 divided by desired lifetime T) to actual power, E_E=P_max/P_now. Alternatively, if the energy in the battery E_bat can be estimated, and the total elapsed lifetime, t, is available, then E_E can be calculated as the total stored energy remaining versus the target energy remaining: E_E= E_bat / [E_0 (T-t)/T].
目的の最大電力（初期エネルギーE_0を希望の寿命tで割った）と実際のパワー、E_E = P_MAX/P_NOWとの比率。あるいは、バッテリーE_BATのエネルギーを推定し、総寿命t、T、T、E_Eは、残りの総エネルギーとして残っているターゲットエネルギーとして計算できます。E_E= E_BAT / [E_0（T-T）/t]。
An example of an optimized route is max(min(E_E)) for all battery-operated nodes along the route, subject to the constraint that E_E>=100 for all scavengers along the route.
最適化されたルートの例は、ルートに沿ったすべてのバッテリー操作ノードの最大（MIN（E_E））です。これは、ルート沿いのすべてのスカベンジャーに対してE_E> = 100であるという制約を条件とします。
Note that the estimated percentage of remaining energy indicated in the E_E field may not be useful in the presence of nodes powered by battery or energy scavengers when the amount of energy accumulated by the device significantly differ. Indeed, X% of remaining energy on a node that can store a large amount of energy cannot be easily compared to the same percentage of remaining energy on a node powered by a tiny source of energy. That being said, in networks where nodes have similar energy storage, such a percentage of remaining energy is useful.
E_Eフィールドに示されている残りのエネルギーの推定割合は、デバイスによって蓄積されたエネルギーの量が大きく異なる場合、バッテリーまたはエネルギースカベンジャーを搭載したノードの存在下では役に立たない場合があることに注意してください。実際、大量のエネルギーを保存できるノード上の残りのエネルギーのx％は、小さなエネルギー源を搭載したノード上の同じ割合の残りのエネルギーと簡単に比較することはできません。そうは言っても、ノードが同様のエネルギー貯蔵を持っているネットワークでは、残りのエネルギーの割合が有用です。
The Node Energy (NE) object is used to provide information related to node energy and may be used as a metric or as constraint.
ノードエネルギー（NE）オブジェクトは、ノードエネルギーに関連する情報を提供するために使用され、メトリックまたは制約として使用できます。
The NE object MAY be present in the DAG Metric Container. There MUST NOT be more than one NE object as a constraint per DAG Metric Container, and there MUST NOT be more than one NE object as a metric per DAG Metric Container.
NEオブジェクトは、DAGメトリックコンテナに存在する場合があります。DAGメトリックコンテナあたりの制約として1つ以上のNEオブジェクトが存在してはならず、DAGメトリックコンテナあたりのメトリックとして1つ以上のNEオブジェクトがある必要があります。
The NE object Type has been assigned value 2 by IANA.
NEオブジェクトタイプには、IANAによってValue 2が割り当てられています。
The format of the NE object body is as follows:
NEオブジェクト本体の形式は次のとおりです。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
| NE Sub-objects
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
Figure 3: NE Sub-Object Format
図3：NEサブオブジェクト形式
The format of the NE sub-object body is as follows:
NEサブオブジェクト本体の形式は次のとおりです。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
| Flags |I| T |E| E_E | Optional TLVs
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
Figure 4: NE Sub-Object Format
図4：NEサブオブジェクト形式
The NE sub-object may also contain a set of TLVs used to convey various nodes' characteristics.
NEサブオブジェクトには、さまざまなノードの特性を伝えるために使用されるTLVのセットも含まれている場合があります。
Flags field (8 bits). The following flags are currently defined:
フラグフィールド（8ビット）。現在、次のフラグが定義されています。
o I (Included): the 'I' bit is only relevant when the node type is used as a constraint. For example, the path must only traverse mains-powered nodes. Conversely, battery-operated nodes must be excluded. The 'I' bit is used to stipulate inclusion versus exclusion. When set, this indicates that nodes of the type specified in the node type field MUST be included. Conversely, when cleared, this indicates that nodes of type specified in the node type field MUST be excluded.
o i（添加）： 'i'ビットは、ノードタイプが制約として使用される場合にのみ関連します。たとえば、パスは主電源駆動のノードのみを通過する必要があります。逆に、バッテリー操作ノードは除外する必要があります。「I」ビットは、包含と除外を規定するために使用されます。設定すると、これはノードタイプフィールドで指定されたタイプのノードを含める必要があることを示します。逆に、クリアされた場合、これは、ノードタイプフィールドで指定されたタイプのノードを除外する必要があることを示します。
o T (node Type): 2-bit field indicating the node type. T=0 designates a mains-powered node, T=1 a battery-powered node, and T=2 a node powered by an energy scavenger.
o T（ノードタイプ）：ノードタイプを示す2ビットフィールド。t = 0は、主電源型ノード、t = 1バッテリー駆動ノード、t = 2 Aノードをエネルギースカベンジャーで駆動するノードを指定します。
o E (Estimation): when the 'E' bit is set for a metric, the estimated percentage of remaining energy on the node is indicated in the E_E 8-bit field. When cleared, the estimated percentage of remaining energy is not provided. When the 'E' bit is set for a constraint, the E_E field defines a threshold for the inclusion/ exclusion: if an inclusion, nodes with values higher than the threshold are to be included; if an exclusion, nodes with values lower than the threshold are to be excluded.
o E（推定）：「e」ビットがメトリックに設定されている場合、ノード上の残りのエネルギーの推定率はE_E 8ビットフィールドに示されます。クリアされた場合、残りのエネルギーの推定割合は提供されません。「E」ビットが制約のために設定されている場合、E_Eフィールドは、包含/除外のしきい値を定義します。包含の場合、しきい値よりも高い値を持つノードを含める必要があります。除外の場合、しきい値よりも低い値を持つノードを除外します。
E_E (Estimated-Energy): 8-bit unsigned integer field indicating an estimated percentage of remaining energy. The E_E field is only relevant when the 'E' flag is set, and it MUST be set to 0 when the 'E' flag is cleared.
E_E（推定エネルギー）：残りのエネルギーの推定割合を示す8ビットの署名されていない整数フィールド。E_Eフィールドは、「E」フラグが設定されている場合にのみ関連性があり、「E」フラグがクリアされている場合は0に設定する必要があります。
If the NE object comprises several sub-objects when used as a constraint, each sub-object adds or subtracts node subsets as the sub-objects are parsed in order. The initial set (full or empty) is defined by the 'I' bit of the first sub-object: full if that 'I' bit is an exclusion, empty if that 'I' bit is an inclusion.
NEオブジェクトが制約として使用された場合、いくつかのサブオブジェクトを含む場合、各サブオブジェクトはサブオブジェクトが順番に解析されるとノードサブセットを追加または減算します。初期セット（フルまたは空）は、最初のサブオブジェクトの「i」ビットによって定義されます。「I」ビットが除外されている場合はフル、「I」ビットが含まれる場合は空です。
No TLV is currently defined.
現在、TLVは定義されていません。
Future documents may define more complex solutions involving TLV parameters representing energy storage, consumption, and generation capabilities of the node, as well as desired lifetime.
将来のドキュメントは、エネルギー貯蔵、消費、およびノードの生成能力、および望ましい寿命を表すTLVパラメーターを含む、より複雑なソリューションを定義する場合があります。
The Hop Count (HP) object is used to report the number of traversed nodes along the path.
ホップカウント（HP）オブジェクトは、パスに沿ったトラバースノードの数を報告するために使用されます。
The HP object MAY be present in the DAG Metric Container. There MUST NOT be more than one HP object as a constraint per DAG Metric Container, and there MUST NOT be more than one HP object as a metric per DAG Metric Container.
HPオブジェクトは、DAGメトリックコンテナに存在する場合があります。DAGメトリックコンテナあたりの制約として1つ以上のHPオブジェクトが存在してはならず、DAGメトリックコンテナあたりのメトリックとして1つ以上のHPオブジェクトがある必要があります。
The HP object may also contain a set of TLVs used to convey various node characteristics. No TLV is currently defined.
HPオブジェクトには、さまざまなノード特性を伝達するために使用されるTLVのセットも含まれている場合があります。現在、TLVは定義されていません。
The HP routing metric object Type has been assigned value 3 by IANA.
HPルーティングメトリックオブジェクトタイプには、IANAによって値3が割り当てられています。
The format of the Hop Count object body is as follows:
ホップカウントオブジェクト本体の形式は次のとおりです。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
| Res | Flags | Hop Count | Optional TLVs
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
Figure 5: Hop Count Object Body Format
図5：ホップカウントオブジェクトボディフォーマット
Res flags (4 bits): Reserved field. This field MUST be set to zero on transmission and MUST be ignored on receipt.
RESフラグ（4ビット）：予約済みフィールド。このフィールドは、送信時にゼロに設定する必要があり、受領時に無視する必要があります。
No Flag is currently defined. Unassigned bits are considered reserved. They MUST be set to zero on transmission and MUST be ignored on receipt.
現在、フラグは定義されていません。割り当てられていないビットは予約されていると見なされます。それらは送信時にゼロに設定する必要があり、受領時に無視する必要があります。
The HP object may be used as a constraint or a metric. When used as a constraint, the DAG root indicates the maximum number of hops that a path may traverse. When that number is reached, no other node can join that path. When used as a metric, each visited node simply increments the Hop Count field.
HPオブジェクトは、制約またはメトリックとして使用できます。制約として使用すると、DAGルートは、パスが横断する可能性のあるホップの最大数を示します。その数に達すると、他のノードがそのパスに参加することはできません。メトリックとして使用すると、訪問した各ノードは、ホップカウントフィールドを単純に増加させます。
Note that the first node along a path inserting a Hop Count metric object MUST set the Hop Count field value to 1.
ホップカウントメトリックオブジェクトを挿入するパスに沿った最初のノードは、ホップカウントフィールド値を1に設定する必要があることに注意してください。
Many LLNs support a wide range of throughputs. For some links, this may be due to variable coding. For the deeply duty-cycled links found in many LLNs, the variability comes as a result of trading power consumption for bit rate. There are several MAC layer protocols that allow for the effective bit rate of a link to vary over more than three orders of magnitude with a corresponding change in power consumption. For efficient operation, it may be desirable for nodes to report the range of throughput that their links can handle in addition to the currently available throughput.
多くのLLNは、幅広いスループットをサポートしています。一部のリンクでは、これは変数コーディングによる可能性があります。多くのLLNに見られる深く義務的なリンクの場合、変動はビットレートで電力消費を取引した結果としてもたらされます。リンクの有効ビットレートを3桁以上にわたって変化させることを可能にするいくつかのMACレイヤープロトコルがあり、それに対応する消費量が変化します。効率的な操作の場合、ノードは、現在利用可能なスループットに加えてリンクが処理できるスループットの範囲を報告することが望ましい場合があります。
The Throughput object MAY be present in the DAG Metric Container. There MUST NOT be more than one Throughput object as a constraint per DAG Metric Container, and there MUST NOT be more than one Throughput object as a metric per DAG Metric Container.
スループットオブジェクトは、DAGメトリックコンテナに存在する場合があります。DAGメトリックコンテナあたりの制約として1つ以上のスループットオブジェクトがないはずであり、DAGメトリックコンテナあたりのメトリックとして1つ以上のスループットオブジェクトがないはずです。
The Throughput object is made of throughput sub-objects and MUST at least comprise one Throughput sub-object. The first Throughput sub-object MUST be the most recently estimated actual throughput. The actual estimation of the throughput is outside the scope of this document.
スループットオブジェクトは、スループットサブオブジェクトで作られており、少なくとも1つのスループットサブオブジェクトで構成される必要があります。最初のスループットサブオブジェクトは、最近推定された実際のスループットでなければなりません。スループットの実際の推定は、このドキュメントの範囲外です。
Each Throughput sub-object has a fixed length of 4 bytes.
各スループットサブオブジェクトの固定長は4バイトです。
The Throughput object does not contain any additional TLVs.
スループットオブジェクトには追加のTLVが含まれていません。
The Throughput object Type has been assigned value 4 by IANA.
スループットオブジェクトタイプには、IANAによって値4が割り当てられています。
The format of the Throughput object body is as follows:
スループットオブジェクト本体の形式は次のとおりです。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (sub-object) .....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Throughput Object Body Format
図6：スループットオブジェクトボディ形式
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Throughput |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Throughput Sub-Object Format
図7：スループットサブオブジェクト形式
Throughput: 32 bits. The Throughput is encoded in 32 bits in unsigned integer format, expressed in bytes per second.
スループット：32ビット。スループットは、1秒あたりのバイトで表される署名されていない整数形式で32ビットでエンコードされます。
Similar to throughput, the latency of many LLN MAC sub-layers can vary over many orders of magnitude, again with a corresponding change in power consumption. Some LLN MAC link layers will allow the latency to be adjusted globally on the subnet, on a link-by-link basis, or not at all. Some will insist that it be fixed for a given link, but allow it to be variable from link to link.
スループットと同様に、多くのLLN MACサブレイヤーの遅延は、消費電力の対応する変化とともに、大幅に大きく異なる場合があります。一部のLLN Macリンクレイヤーにより、リンクごとに、リンクごとにレイテンシをグローバルに調整できます。特定のリンクに対して修正されていると主張する人もいますが、リンクからリンクに変動するようにします。
The Latency object MAY be present in the DAG Metric Container. There MUST NOT be more than one Latency object as a constraint per DAG Metric Container, and there MUST NOT be more than one Latency object as a metric per DAG Metric Container.
レイテンシオブジェクトは、DAGメトリックコンテナに存在する場合があります。DAGメトリックコンテナあたりの制約として1つ以上のレイテンシオブジェクトがある必要があります。また、DAGメトリックコンテナあたりのメトリックとして1つ以上のレイテンシオブジェクトがある必要があります。
The Latency object is made of Latency sub-objects and MUST at least comprise one Latency sub-object. Each Latency sub-object has a fixed length of 4 bytes.
レイテンシオブジェクトは、レイテンシサブオブジェクトで作られており、少なくとも1つのレイテンシサブオブジェクトを含む必要があります。各レイテンシサブオブジェクトの固定長は4バイトです。
The Latency object does not contain any additional TLVs.
Latencyオブジェクトには追加のTLVが含まれていません。
The Latency object Type has been assigned value 5 by IANA.
Latencyオブジェクトタイプには、IANAによって値5が割り当てられています。
The Latency object is a metric or constraint.
レイテンシオブジェクトはメトリックまたは制約です。
The format of the Latency object body is as follows:
Latencyオブジェクト本体の形式は次のとおりです。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (sub-object) .....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Latency Object Body Format
図8：レイテンシオブジェクトボディフォーマット
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Latency |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Latency Sub-Object Format
図9：レイテンシサブオブジェクト形式
Latency: 32 bits. The Latency is encoded in 32 bits in unsigned integer format, expressed in microseconds.
レイテンシ：32ビット。レイテンシは、マイクロ秒で表される署名されていない整数形式で32ビットでエンコードされます。
The Latency object may be used as a constraint or a path metric. For example, one may want the latency not to exceed some value. In this case, the Latency object common header indicates that the provided value relates to a constraint. In another example, the Latency object may be used as an aggregated additive metric where the value is updated along the path to reflect the path latency.
レイテンシオブジェクトは、制約またはパスメトリックとして使用できます。たとえば、レイテンシが何らかの価値を超えないようにしたい場合があります。この場合、Latencyオブジェクト共通ヘッダーは、提供された値が制約に関連していることを示します。別の例では、レイテンシオブジェクトは、パスレイテンシを反映するためにパスに沿って値が更新される集約添加剤メトリックとして使用できます。
In LLNs, link reliability could be degraded for a number of reasons: signal attenuation, interferences of various forms, etc. Time scales vary from milliseconds to days, and are often periodic and linked to human activity. Packet error rates can generally be measured directly, and other metrics (e.g., bit error rate, mean time between failures) are typically derived from that. Note that such variability is not specific to wireless link but also applies to PLC links.
LLNでは、信号減衰、さまざまな形態の干渉など、リンクの信頼性をいくつかの理由で劣化させる可能性があります。時間スケールはミリ秒から数日ごとに異なり、多くの場合、周期的で人間の活動にリンクされています。パケットエラー率は一般に直接測定でき、他のメトリック（たとえば、ビットエラー率、障害間の平均時間）は通常、それから導き出されます。このような変動性はワイヤレスリンクに固有ではなく、PLCリンクにも適用されることに注意してください。
A change in link quality can affect network connectivity; thus, link quality may be taken into account as a critical routing metric.
リンク品質の変化は、ネットワークの接続に影響を与える可能性があります。したがって、リンクの品質は、重要なルーティングメトリックとして考慮される場合があります。
A number of link reliability metrics could be defined reflecting several reliability aspects. Two link reliability metrics are defined in this document: the Link Quality Level (LQL) and the ETX Metric.
いくつかの信頼性の側面を反映して、多くのリンク信頼性メトリックを定義できます。このドキュメントでは、2つのリンク信頼性メトリックが定義されています：リンク品質レベル（LQL）とETXメトリック。
Note that a RPL deployment MAY use the LQL, the ETX, or both.
RPL展開は、LQL、ETX、またはその両方を使用する場合があることに注意してください。
The Link Quality Level (LQL) object is used to quantify the link reliability using a discrete value, from 0 to 7, where 0 indicates that the link quality level is unknown and 1 reports the highest link quality level. The mechanisms and algorithms used to compute the LQL are implementation specific and outside of the scope of this document.
リンク品質レベル（LQL）オブジェクトは、0〜7の離散値を使用してリンクの信頼性を定量化するために使用されます。ここで、0はリンクの品質レベルが不明であることを示し、1は最高のリンク品質レベルを報告します。LQLを計算するために使用されるメカニズムとアルゴリズムは、このドキュメントの範囲外であり、このドキュメントの範囲外です。
The LQL can be used either as a metric or a constraint. When used as a metric, the LQL metric can only be recorded. For example, the DAG Metric object may request all traversed nodes to record the LQL of their incoming link into the LQL object. Each node can then use the LQL record to select its parent based on some user defined rules (e.g., something like "select the path with most links reporting a LQL value of 3 or less").
LQLは、メトリックまたは制約として使用できます。メトリックとして使用する場合、LQLメトリックは記録することのみができます。たとえば、DAGメトリックオブジェクトは、すべてのトラバースノードを要求して、着信リンクのLQLをLQLオブジェクトに記録することができます。各ノードは、LQLレコードを使用して、一部のユーザー定義ルールに基づいて親を選択できます（たとえば、「3以下のLQL値をレポートするほとんどのリンクでパスを選択」など）。
Counters are used to compress the information: for each encountered LQL value, only the number of matching links is reported.
カウンターは情報を圧縮するために使用されます。遭遇する各LQL値について、一致するリンクの数のみが報告されます。
The LQL object MAY be present in the DAG Metric Container. There MUST NOT be more than one LQL object as a constraint per DAG Metric Container, and there MUST NOT be more than one LQL object as a metric per DAG Metric Container.
LQLオブジェクトは、DAGメトリックコンテナに存在する場合があります。DAGメトリックコンテナあたりの制約として複数のLQLオブジェクトが存在してはならず、DAGメトリックコンテナあたりのメトリックとして1つ以上のLQLオブジェクトが必要です。
The LQL object MUST contain one or more sub-object used to report the number of links along with their LQL.
LQLオブジェクトには、LQLとともにリンクの数を報告するために使用される1つ以上のサブオブジェクトを含める必要があります。
The LQL object Type has been assigned value 6 by IANA.
LQLオブジェクトタイプには、IANAによって値6が割り当てられています。
The format of the LQL object body is as follows:
LQLオブジェクト本体の形式は次のとおりです。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
| Res | LQL sub-object
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
Figure 10: LQL Object Body Format
図10：LQLオブジェクトボディ形式
Res flags (8 bits): Reserved field. This field MUST be set to zero on transmission and MUST be ignored on receipt.
RESフラグ（8ビット）：予約済みフィールド。このフィールドは、送信時にゼロに設定する必要があり、受領時に無視する必要があります。
When the LQL metric is recorded, the LQL object body comprises one or more LQL Type 1 sub-object.
LQLメトリックが記録されると、LQLオブジェクトボディは1つ以上のLQL Type 1サブオブジェクトで構成されます。
The format of the LQL Type 1 sub-object is as follows
LQLタイプ1サブオブジェクトの形式は次のとおりです
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Val | Counter |
+-+-+-+-+-+-+-+-+
Figure 11: LQL Type 1 Sub-Object Format
図11：LQLタイプ1サブオブジェクト形式
Val: LQL value from 0 to 7 where 0 means undetermined and 1 indicates the highest link quality.
VAL：0から7のLQL値は未定であり、1は最高のリンクの品質を示します。
Counter: number of links with that value.
カウンター：その値のリンクの数。
The ETX metric is the number of transmissions a node expects to make to a destination in order to successfully deliver a packet. In contrast with the LQL routing metric, the ETX provides a discrete value (which may not be an integer) computed according to a specific formula: for example, an implementation may use the following formula: ETX= 1 / (Df * Dr) where Df is the measured probability that a packet is received by the neighbor and Dr is the measured probability that the acknowledgment packet is successfully received. This document does not mandate the use of a specific formula to compute the ETX value.
ETXメトリックは、ノードがパケットを正常に配信するために宛先に行うことを期待するトランスミッションの数です。LQLルーティングメトリックとは対照的に、ETXは特定の式に従って計算される離散値（整数ではない場合があります）を提供します。たとえば、実装は次の式を使用できます。ETX= 1 /（DF * DR）DFは、パケットが隣人によって受信される測定された確率であり、DRは、確認パケットが正常に受信される測定確率です。このドキュメントは、ETX値を計算するために特定の式を使用することを義務付けていません。
The ETX object MAY be present in the DAG Metric Container. There MUST NOT be more than one ETX object as a constraint per DAG Metric Container, and there MUST NOT be more than one ETX object as a metric per DAG Metric Container.
ETXオブジェクトは、DAGメトリックコンテナに存在する場合があります。DAGメトリックコンテナあたりの制約として1つ以上のETXオブジェクトが存在してはならず、DAGメトリックコンテナあたりのメトリックとして1つ以上のETXオブジェクトがある必要があります。
The ETX object is made of ETX sub-objects and MUST at least comprise one ETX sub-object. Each ETX sub-object has a fixed length of 16 bits.
ETXオブジェクトはETXサブオブジェクトで作られており、少なくとも1つのETXサブオブジェクトを含む必要があります。各ETXサブオブジェクトの固定長は16ビットです。
The ETX object does not contain any additional TLVs.
ETXオブジェクトには追加のTLVは含まれていません。
The ETX object Type has been assigned value 7 by IANA.
ETXオブジェクトタイプには、IANAによって値7が割り当てられています。
The format of the ETX object body is as follows:
ETXオブジェクト本体の形式は次のとおりです。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (sub-object) .....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: ETX Object Body Format
図12：ETXオブジェクトボディ形式
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ETX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: ETX Sub-Object Format
図13：ETXサブオブジェクト形式
ETX: 16 bits. The ETX * 128 is encoded using 16 bits in unsigned integer format, rounded off to the nearest whole number. For example, if ETX = 3.569, the object value will be 457. If ETX > 511.9921875, the object value will be the maximum, which is 65535.
ETX：16ビット。ETX * 128は、署名されていない整数形式で16ビットを使用してエンコードされ、最も近い整数に丸められています。たとえば、ETX = 3.569の場合、オブジェクト値は457になります。ETX> 511.9921875の場合、オブジェクト値は最大値、65535です。
The ETX object may be used as a constraint or a path metric. For example, it may be required that the ETX must not exceed some specified value. In this case, the ETX object common header indicates that the value relates to a constraint. In another example, the ETX object may be used as an aggregated additive metric where the value is updated along the path to reflect the path quality: when a node receives the aggregated additive ETX value of the path (cumulative path ETX calculated as the sum of the link ETX of all of the traversed links from the advertising node to the DAG root), if it selects that node as its preferred parent, the node updates the path ETX by adding the ETX of the local link between itself and the preferred parent to the received path cost (path ETX) before potentially advertising itself the new path ETX.
ETXオブジェクトは、制約またはパスメトリックとして使用できます。たとえば、ETXが指定された値を超えてはならないことが必要になる場合があります。この場合、ETXオブジェクト共通ヘッダーは、値が制約に関連することを示します。別の例では、ETXオブジェクトは、パスの品質を反映するためにパスに沿って値が更新される集約添加剤メトリックとして使用できます。ノードがパスの集約された添加剤ETX値を受信した場合（累積パスETXが合計として計算された累積パスETX広告ノードからDAGルートへのすべてのトラバースリンクのリンクETX）は、そのノードを優先親として選択した場合、ノードはそれ自体と優先親との間のローカルリンクのETXを追加することでパスETXを更新します受信したパスコスト（PATH ETX）は、新しいPATH ETXを潜在的に宣伝する前に。
The Link Color (LC) object is an administrative 10-bit link constraint (which may be either static or dynamically adjusted) used to avoid or attract specific links for specific traffic types.
Link Color（LC）オブジェクトは、特定のトラフィックタイプの特定のリンクを回避または引き付けるために使用される管理10ビットリンク制約（静的または動的に調整される場合があります）です。
The LC object can be used either as a metric or as a constraint. When used as a metric, the LC metric can only be recorded. For example, the DAG may require recording the link colors for all traversed links. A color is defined as a specific set of bit values: in other words, that 10-bit field is a flag field, and not a scalar value. Each node can then use the LC to select the parent based on user defined rules (e.g., "select the path with the maximum number of links having their first bit set 1 (e.g., encrypted links)"). The LC object may also be used as a constraint.
LCオブジェクトは、メトリックまたは制約として使用できます。メトリックとして使用する場合、LCメトリックは記録することのみができます。たとえば、DAGは、すべてのトラバースリンクのリンク色を記録する必要がある場合があります。色はビット値の特定のセットとして定義されます。つまり、10ビットフィールドはフラグフィールドであり、スカラー値ではありません。各ノードは、LCを使用して、ユーザー定義のルールに基づいて親を選択できます（例：「最初のビットセット1（例：暗号化されたリンク）を持つリンクの最大数を選択するパスを選択します」）。LCオブジェクトは、制約として使用することもできます。
When used as a recorded metric, a counter is used to compress the information where the number of links for each Link Color is reported.
記録されたメトリックとして使用される場合、カウンターは、各リンク色のリンク数が報告される情報を圧縮するために使用されます。
The Link Color (LC) object MAY be present in the DAG Metric Container. There MUST NOT be more than one LC object as a constraint per DAG Metric Container, and there MUST NOT be more than one LC object as a metric per DAG Metric Container.
Link Color（LC）オブジェクトは、DAGメトリックコンテナに存在する場合があります。DAGメトリックコンテナあたりの制約として1つ以上のLCオブジェクトが存在してはならず、DAGメトリックコンテナあたりのメトリックとして1つ以上のLCオブジェクトがある必要があります。
There MUST be a at least one LC sub-object per LC object.
LCオブジェクトごとに少なくとも1つのLCサブオブジェクトが必要です。
The LC object does not contain any additional TLVs.
LCオブジェクトには追加のTLVは含まれていません。
The LC object Type has been assigned value 8 by IANA.
LCオブジェクトタイプには、IANAによって値8が割り当てられています。
The format of the LC object body is as follows:
LCオブジェクト本体の形式は次のとおりです。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
| Res | LC sub-objects
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
Figure 14: LC Object Format
図14：LCオブジェクト形式
Res flags (8 bits): Reserved field. This field MUST be set to zero on transmission and MUST be ignored on receipt.
RESフラグ（8ビット）：予約済みフィールド。このフィールドは、送信時にゼロに設定する必要があり、受領時に無視する必要があります。
When the LC object is used as a recorded metric, the LC object body comprises one or more LC Type 1 sub-objects.
LCオブジェクトが記録されたメトリックとして使用される場合、LCオブジェクトボディは1つ以上のLCタイプ1サブオブジェクトで構成されます。
The format of the LC Type 1 sub-object body is as follows:
LCタイプ1サブオブジェクトボディの形式は次のとおりです。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Color | Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: LC Type 1 Sub-Object Format
図15：LCタイプ1サブオブジェクト形式
When the LC object is used as a constraint, the LC object body comprises one or more LC Type 2 sub-objects.
LCオブジェクトが制約として使用される場合、LCオブジェクトボディは1つ以上のLCタイプ2サブオブジェクトを含む。
The format of the LC Type 2 sub-object body is as follows:
LCタイプ2サブオブジェクトボディの形式は次のとおりです。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Color |Reserved |I|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: LC Type 2 Sub-Object Format
図16：LCタイプ2サブオブジェクト形式
Reserved (5 bits): Reserved field. This field MUST be set to zero on transmission and MUST be ignored on receipt.
予約済み（5ビット）：予約フィールド。このフィールドは、送信時にゼロに設定する必要があり、受領時に無視する必要があります。
'I' Bit: The 'I' bit is only relevant when the Link Color is used as a constraint. When set, this indicates that links with the specified color must be included. When cleared, this indicates that links with the specified color must be excluded.
「I」ビット：「I」ビットは、リンク色が制約として使用される場合にのみ関連します。設定すると、これは指定された色とのリンクを含める必要があることを示します。クリアされた場合、これは指定された色とのリンクを除外する必要があることを示します。
It is left to the implementer to define the meaning of each bit of the 10-bit Link Color Flag field.
10ビットリンクカラーフラグフィールドの各ビットの意味を定義することは、実装者に任されています。
The link color may be used as a constraint or a metric.
リンク色は、制約またはメトリックとして使用できます。
o When used as constraint, the LC object may be inserted in the DAG Metric Container to indicate that links with a specific color should be included or excluded from the computed path.
o 制約として使用する場合、LCオブジェクトをDAGメトリックコンテナに挿入して、特定の色のリンクを計算されたパスから含めるか除外する必要があることを示します。
o When used as recorded metric, each node along the path may insert an LC object in the DAG Metric Container to report the color of the local link. If there is already an LC object reporting a similar color, the node MUST NOT add another identical LC sub-object and MUST increment the counter field.
o 記録されたメトリックとして使用すると、パスに沿った各ノードは、DAGメトリックコンテナにLCオブジェクトを挿入して、ローカルリンクの色を報告する場合があります。同様の色を報告するLCオブジェクトが既にある場合、ノードは別の同一のLCサブオブジェクトを追加してはならず、カウンターフィールドをインクリメントする必要があります。
As already pointed out, dynamically calculated metrics are of the utmost importance in many circumstances in LLNs. This is mainly because a variety of metrics change on a frequent basis, thus, implying the need to adapt the routing decisions. That being said, care must be given to the pace at which changes are reported in the network. The attributes will change according to their own time scales. RPL controls the reporting rate.
すでに指摘されているように、LLNSの多くの状況で動的に計算されたメトリックは最も重要です。これは主に、さまざまなメトリックが頻繁に変化するため、ルーティングの決定を適応させる必要性を意味するためです。そうは言っても、ネットワークで変更が報告されるペースに注意を払わなければなりません。属性は、独自の時間スケールに応じて変更されます。RPLは報告率を制御します。
To minimize metric updates, multi-threshold algorithms MAY be used to determine when updates should be sent. When practical, low-pass filtering and/or hysteresis should be used to avoid rapid fluctuations of these values. Finally, although the specification of path computation algorithms using dynamic metrics is out of the scope of this document, it is RECOMMENDED to carefully design the route optimization algorithm to avoid too frequent computation of new routes upon metric values changes.
メトリックの更新を最小限に抑えるために、マルチスレッジホルドアルゴリズムを使用して、更新がいつ送信されるかを判断することができます。実用的な場合は、これらの値の急速な変動を避けるために、ローパスフィルタリングおよび/またはヒステリシスを使用する必要があります。最後に、動的メトリックを使用したPATH計算アルゴリズムの指定はこのドキュメントの範囲外ですが、メトリック値の変更時に新しいルートの頻繁な計算を避けるために、ルート最適化アルゴリズムを慎重に設計することをお勧めします。
Controlled adaptation of the routing metrics and rate at which paths are computed are critical to avoid undesirable routing instabilities resulting in increased latencies and packet loss because of temporary micro-loops. Furthermore, excessive route changes will adversely impact the traffic and power consumption in the network, thus, potentially impacting its scalability.
ルーティングメトリックの制御された適応とパスが計算されるレートの制御された適応は、望ましくないルーティング不安定性を回避するために重要であり、一時的なマイクロループのためにレイテンシーとパケット損失を増加させます。さらに、過度のルートの変化は、ネットワークのトラフィックと消費電力に悪影響を及ぼし、したがって、スケーラビリティに影響を与える可能性があります。
IANA has established a new top-level registry, called "RPL Routing Metric/Constraint", to contain all Routing Metric/Constraint objects codepoints and sub-registries.
IANAは、「RPLルーティングメトリック/制約」と呼ばれる新しいトップレベルのレジストリを確立し、すべてのルーティングメトリック/制約オブジェクトコードポイントとサブレジストリを含んでいます。
The allocation policy for each new registry is by IETF review: new values are assigned through the IETF review process (see [RFC5226]). Specifically, new assignments are made via RFCs approved by the IESG. Typically, the IESG will seek input on prospective assignments from appropriate persons (e.g., a relevant working group if one exists).
各新しいレジストリの割り当てポリシーは、IETFレビューによるものです。新しい値はIETFレビュープロセスを通じて割り当てられます（[RFC5226]を参照）。具体的には、IESGによって承認されたRFCを介して新しい割り当てが行われます。通常、IESGは、適切な人物からの将来の割り当てに関する意見を求めます（たとえば、存在する場合は関連するワーキンググループなど）。
New bit numbers may be allocated only by an IETF Review action. Each bit should be tracked with the following qualities:
新しいビット番号は、IETFレビューアクションによってのみ割り当てられる場合があります。各ビットは、次の品質で追跡する必要があります。
o Bit number
o ビット番号
o Capability Description
o 機能の説明
o Defining RFC
o RFCの定義
IANA has created a sub-registry, called "Routing Metric/Constraint Type", for Routing Metric/Constraint object types, which range from 0 to 255. Value 0 is unassigned.
IANAは、0〜255の範囲のルーティングメトリック/制約オブジェクトタイプの「ルーティングメトリック/制約タイプ」と呼ばれるサブレジストリを作成しました。値0は割り当てられていません。
Value Meaning Reference 1 Node State and Attribute This document 2 Node Energy This document 3 Hop Count This document 4 Link Throughput This document 5 Link Latency This document 6 Link Quality Level This document 7 Link ETX This document 8 Link Color This document
値の意味参照1ノード状態と属性このドキュメント2ノードエネルギーこのドキュメント3ホップカウントこのドキュメント4リンクスループットこのドキュメント5リンクレイテンシーこのドキュメント6リンク品質レベル7リンク7このドキュメント8リンク色このドキュメント
IANA has created a sub-registry, called "Routing Metric/Constraint TLVs", used for all TLVs carried within Routing Metric/Constraint objects. The Type field is an 8-bit field whose value is comprised between 0 and 255. Value 0 is unassigned. The Length field is an 8-bit field whose value ranges from 0 to 255. The Value field has value ranges depending on the Type; therefore, they are not defined here, since no Type is registered at this time.
IANAは、ルーティングメトリック/制約オブジェクト内で運ばれるすべてのTLVに使用される「ルーティングメトリック/制約TLV」と呼ばれるサブレジストリを作成しました。タイプフィールドは8ビットフィールドで、その値は0〜255の間で構成されています。値0は割り当てられていません。長さフィールドは、値の範囲が0〜255の8ビットフィールドです。値フィールドには、タイプに応じて値範囲があります。したがって、現時点では登録されていないため、ここでは定義されていません。
IANA has created a sub-registry, called "Routing Metric/Constraint Common Header Flag field", to manage the 9-bit Flag field of the Routing Metric/Constraint common header.
IANAは、ルーティングメトリック/制約共通ヘッダーの9ビットフラグフィールドを管理するために、「ルーティングメトリック/制約共通ヘッダーフラグフィールド」と呼ばれるサブレジストリを作成しました。
Several bits are defined for the Routing Metric/Constraint common header Flag field in this document. The following values have been assigned:
このドキュメントのルーティングメトリック/制約共通ヘッダーフラグフィールドには、いくつかのビットが定義されています。次の値が割り当てられています。
Codespace of the Flag field (Routing Metric/Constraint common header)
フラグフィールドのコードスペース（ルーティングメトリック/制約共通ヘッダー）
Bit Description Reference
ビット説明リファレンス
8 Recorded/Aggregated This document 7 Optional Constraint This document 6 Constraint/Metric This document 5 P (Partial) This document
8記録/集約このドキュメント7オプションの制約このドキュメント6制約/メトリックこのドキュメント5 p（部分的）このドキュメント
Bits 0-4 are currently reserved.
現在、ビット0-4は予約されています。
IANA has created a sub-registry, called "Routing Metric/Constraint Common Header A field", to manage the codespace of the A field of the Routing Metric/Constraint common header.
IANAは、ルーティングメトリック/制約共通ヘッダーのAフィールドのコーデススペースを管理するために、「ルーティングメトリック/制約共通ヘッダーAフィールド」と呼ばれるサブレジストリを作成しました。
The A field is 3 bits in length, and it has values ranging from 0 to 7.
Aフィールドの長さは3ビットで、0〜7の範囲の値があります。
Codespace of the A field (Routing Metric/Constraint common header) Value Meaning Reference
Aフィールド（ルーティングメトリック/制約共通ヘッダー）のコードスペース値を意味する参照
0 Routing metric is additive This document 1 Routing metric reports a maximum This document 2 Routing metric reports a minimum This document 3 Routing metric is multiplicative This document
0ルーティングメトリックは添加剤です
IANA has created a sub-registry, called "NSA Object Flag field", to manage the codespace of the 8-bit Flag field of the NSA object.
IANAは、NSAオブジェクトの8ビットフラグフィールドのコードスペースを管理するために、「NSAオブジェクトフラグフィールド」と呼ばれるサブレジストリを作成しました。
Several bits are defined for the NSA Object Flag field in this document. The following values have been assigned:
このドキュメントのNSAオブジェクトフラグフィールドには、いくつかのビットが定義されています。次の値が割り当てられています。
Codespace of the Flag field (NSA object)
フラグフィールドのコードスペース（NSAオブジェクト）
Bit Description Reference
ビット説明リファレンス
6 Aggregator This document 7 Overloaded This document
6アグリゲーターこのドキュメント7はこのドキュメントを過負荷にしました
Bits 0-5 are reserved.
ビット0-5は予約されています。
IANA has created a sub-registry, called "Hop-Count Object Flag field", to manage the codespace of the 4-bit Flag field of the Hop Count object.
IANAは、ホップカウントオブジェクトの4ビットフラグフィールドのコードスペースを管理するために、「ホップカウントオブジェクトフラグフィールド」と呼ばれるサブレジストリを作成しました。
No Flag is currently defined.
現在、フラグは定義されていません。
IANA has created a sub-registry, called "Node Type Field", to manage the codespace of the field of the Routing Metric/Constraint common header.
IANAは、ルーティングメトリック/制約の共通ヘッダーのフィールドのコーダースパースを管理するために、「ノードタイプフィールド」と呼ばれるサブレジストリを作成しました。
The T field is 2 bits in length, and it has values ranging from 0 to 3.
Tフィールドの長さは2ビットで、0〜3の範囲の値があります。
Codespace of the T field (Routing Metric/Constraint common header)
Tフィールドのコードスペース（ルーティングメトリック/制約共通ヘッダー）
Value Description Reference 0 a mains-powered node This document 1 a battery-powered node This document 2 a node powered by an energy scavenger This document
値説明リファレンス0メイン駆動型ノードこのドキュメント1バッテリー駆動のノードこのドキュメント2エネルギースカベンジャーを搭載したノードこのドキュメント
Routing metrics should be handled in a secure and trustful manner. For instance, RPL should not allow a malicious node to falsely advertise that it has good metrics for routing so as to be selected as preferred next-hop router for other nodes' traffic and intercept packets. Another attack may consist of making intermittent attacks on a link in an attempt to constantly modify the link quality and consequently the associated routing metric, thus, leading to potential fluctuation in the DODAG. Thus, it is RECOMMENDED for a RPL implementation to put in place mechanisms so as to stop advertising routing metrics for highly unstable links that may be subject to attacks.
ルーティングメトリックは、安全で信頼できる方法で処理する必要があります。たとえば、RPLは、悪意のあるノードが、他のノードのトラフィックおよびインターセプトパケットの優先される次元ルーターとして選択されるように、ルーティングに適したメトリックを備えていることを誤って宣伝することを許可してはなりません。別の攻撃は、リンクの品質を絶えず変更し、結果として関連するルーティングメトリックを常に変更しようとして、リンクに断続的な攻撃を行うことで構成され、したがって、ドーダグの潜在的な変動につながる可能性があります。したがって、RPLの実装が攻撃の対象となる可能性のある非常に不安定なリンクの広告ルーティングメトリックを停止するために、メカニズムを導入することをお勧めします。
Some routing metrics may also be used to identify some areas of weaknesses in the network (a highly unreliable link, a node running low in terms of energy, etc.). Such information may be used by a potential attacker. Thus, it is RECOMMENDED to carefully consider which metrics should be used by RPL and the level of visibility that they provide about the network state or to use appropriate the security measures as specified in [RFC6550] to protect that information.
いくつかのルーティングメトリックを使用して、ネットワークの弱点の一部を特定することもできます（非常に信頼性の低いリンク、エネルギーの点で低いノードなど）。そのような情報は、潜在的な攻撃者が使用する場合があります。したがって、どのメトリックをRPLで使用するか、ネットワーク状態について提供する可視性のレベルを慎重に検討するか、その情報を保護するために[RFC6550]で指定されたセキュリティ対策を適切に使用することをお勧めします。
Since the routing metrics/constraints are carried within RPL message, the security routing mechanisms defined in [RFC6550] apply here.
ルーティングメトリック/制約はRPLメッセージ内で実行されるため、[RFC6550]で定義されているセキュリティルーティングメカニズムがここに適用されます。
The authors would like to acknowledge the contributions of Young Jae Kim, Hakjin Chong, David Meyer, Mischa Dohler, Anders Brandt, Philip Levis, Pascal Thubert, Richard Kelsey, Jonathan Hui, Alexandru Petrescu, Richard Kelsey, Mathilde Durvy, Phoebus Chen, Tim Winter, Yoav Ben-Yehezkel, Matteo Paris, Omprakash Gnawali, Mads Westergreen, Mukul Goyal, Joseph Saloway, David Culler, and Jari Arkko for their review and valuable comments. Special thanks to Adrian Farrel for his thorough review.
著者は、若いジェム、ハクジン・チョン、デビッド・マイヤー、ミーシャ・ドーラー、アンダース・ブラント、フィリップ・レビス、パスカル・ツーバート、リチャード・ケルシー、ジョナサン・ヒュイ、アレクサンドル・ペチュレシュ、リチャード・ケルシー、マツィルド・ドゥービー、プスバス・チェン、プスバス・チーン、プスカル・シュバーズの貢献を認めたいと思います。冬、ヨーブ・ベン・イヘズケル、マッテオ・パリ、オムプラカシュ・グナワリ、マッズ・ウェストエルガリーン、ムクル・ゴイヤル、ジョセフ・サロウェイ、デビッド・カラー、ジャリ・アークコのレビューと貴重なコメント。彼の徹底的なレビューをしてくれたエイドリアン・ファレルに感謝します。
[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月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[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月。
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[RFC1195] Callon、R。、「TCP/IPおよびデュアル環境でのルーティングのためのOSI IS-I-ISの使用」、RFC 1195、1990年12月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月。
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.
[RFC2702] Awduche、D.、Malcolm、J.、Agogbua、J.、O'dell、M。、およびJ. McManus、「MPLS上の交通工学要件」、RFC 2702、1999年9月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、 "RSVP-TE：LSP TunnelsのRSVPへの拡張"、RFC 3209、12月2001年。
[RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, "Routing Requirements for Urban Low-Power and Lossy Networks", RFC 5548, May 2009.
[RFC5548] Dohler、M.、Watteyne、T.、Winter、T.、およびD. Barthel、「都市の低電力と損失ネットワークのルーティング要件」、RFC 5548、2009年5月。
[RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, "Industrial Routing Requirements in Low-Power and Lossy Networks", RFC 5673, October 2009.
[RFC5673] Pister、K.、Thubert、P.、Dwars、S。、およびT. Phinney、「低電力および損失ネットワークの産業ルーティング要件」、RFC 5673、2009年10月。
[RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation Routing Requirements in Low-Power and Lossy Networks", RFC 5826, April 2010.
[RFC5826] Brandt、A.、Buron、J。、およびG. Porcu、「低電力および損失ネットワークのホームオートメーションルーティング要件」、RFC 5826、2010年4月。
[RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, "Building Automation Routing Requirements in Low-Power and Lossy Networks", RFC 5867, June 2010.
[RFC5867] Martocci、J.、De Mil、P.、Riou、N。、およびW. Vermeylen、「低電力および損失ネットワークの自動化ルーティング要件の構築」、2010年6月、RFC 5867。
[RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL)", RFC 6552, March 2012.
[RFC6552] Thubert、P.、ed。、「低電力および損失ネットワーク（RPL）のルーティングプロトコルの目的関数ゼロ」、RFC 6552、2012年3月。
[ROLL-TERMS] Vasseur, JP., "Terminology in Low power And Lossy Networks", Work in Progress, September 2011.
[Roll-Terms] Vasseur、jp。、「低電力と損失ネットワークの用語」、2011年9月、進行中の作業。
[Zinky1989] Zinky, J., Vichniac, G., and A. Khanna, "Performance of the Revised Routing Metric for ARPANET and MILNET", Military Communications Conference, MILCOM '89, March 1989.
[Zinky1989] Zinky、J.、Vichniac、G。、およびA. Khanna、「Arpanet and Milnetの改訂されたルーティングメトリックのパフォーマンス」、Military Communications Conference、Milcom '89、1989年3月。
Authors' Addresses
著者のアドレス
JP. Vasseur (editor) Cisco Systems 11, Rue Camille Desmoulins Issy Les Moulineaux 92782 France
JP。Vasseur（編集者）Cisco Systems 11、Rue Camille Desmoulins Issy Les Moulineaux 92782 France
EMail: jpv@cisco.com
Mijeom Kim (editor) Corporate Technology Group, KT 17 Woomyeon-dong, Seocho-gu Seoul 137-792 Korea
Mijeom Kim（編集者）Corporate Technology Group、KT 17 Woomyon-Dong、Seocho-Gu Seoul 137-792 Korea
EMail: mjkim@kt.com
Kris Pister Dust Networks 30695 Huntwood Ave. Hayward, CA 95544 USA
Kris Pister Dust Networks 30695 Huntwood Ave. Hayward、CA 95544 USA
EMail: kpister@dustnetworks.com
Nicolas Dejean Elster SAS Espace Concorde, 120 impasse JB Say Perols 34470 France
ニコラス・デジャン・エルスター・サス・エスパース・コンコルド、120の行き詰まりjbはperols 34470フランス
EMail: nicolas.dejean@coronis.com
Dominique Barthel France Telecom Orange 28 chemin du Vieux Chene, BP 98 Meylan 38243 France
ドミニクバーセルフランステレコムオレンジ28ケミンデュヴィューチェーン、BP 98メイラン38243フランス
EMail: dominique.barthel@orange.com