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).
低消費電力とロッシーネットワーク（LLNs）が新しいルーティングメトリックと制約の仕様を必要とする従来の有線およびアドホックネットワークと比較してユニークな特性を持っています。対照的に、ホップカウントまたはリンク・メトリックを使用する典型的なインテリアゲートウェイプロトコル（IGP）ルーティング・メトリックを用いて、この文書は、低電力およびロッシーネットワークのためのルーティングプロトコルが使用するLLNsに適したリンクとノードのルーティング・メトリックおよび制約のセットを指定します（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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2012 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of
この文書では、BCP 78との日に有効な（http://trustee.ietf.org/license-info）IETFドキュメントに関連IETFトラストの法律の規定に従うもの
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および簡体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].
この文書では、[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].
低消費電力とロッシーネットワーク（LLNs）[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などのIGP、（[RFC2328]）及びIS-IS（[RFC1195]）、定量的な静的リンク・メトリックを使用してきました。ほとんどの時間、このようなマルチプロトコルラベルスイッチング（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.
この文書の主要な目的の一つは、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パラメータの特定のセットがROLLワーキンググループによって作成適用性プロファイル文書に準拠プロファイルとして指定されます。 RPLも[RFC6552]で定義された目的関数を使用して、例えば、無メトリックを利用することができることに留意されたいです。
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宛先指向有向非循環グラフ（DODAG）ルートは、[RFC6550]で定義されるように、特定の特性を満たしていないリンクおよびノードを整理するための「フィルター」として使用されるルーティング制約を広告することができます。例えば、それは唯一の商用電源、または少なくとも最小信頼性やユーザ定義のリンク特性反射特定の「色」がリンクされているノード横断する経路のために必要とされてもよい（例えば、リンクレイヤは、暗号化をサポートします） 。
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 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.
LLN内のリンクは、一般的に急速にノードとリンクの特性を変更しています。従って、ルーティングメトリックは動的でなければならず、ルーティングの振動を回避するような技術は、これらのメトリックの動的性を平滑化するために使用されなければなりません。例えば、いくつかのリンク（例えば、無線だけでなく、電力線通信（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.
動的メトリックの使用は新しいものではなく、（[Zinky1989]参照）ARPANET 2で実験されていることに注意しなければなりません。ダイナミックなメトリックを使用することは容易ではありません、それは潜在的なルーティングの不安定性につながる可能性があるため、細心の注意は、動的メトリックの使用に与えられなければなりません。言われていることを、多くの経験は、（非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を構築することが望ましい場合があります。別の例では、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]で示される特定の展開シナリオに適用可能であるオプションを明確にするためにROLLワーキンググループ内で開発されるであろう。
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.
ルーティング-MC-タイプ（ルーティングメトリック/制約タイプ - 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).
ルーティングメトリック/制約フラグフィールドオブジェクトの次のビットが現在定義されている：「P」フラグ（O）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.
'C' フラグO。設定されている場合、これはルーティングメトリック/制約オブジェクトは、ルーティング制約を意味することを示しています。クリアされた場合に、ルーティング・オブジェクトは、ルーティングメトリックを指します。
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.
「R」フラグ（O）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.
フィールド（3ビット）：フィールドは、メトリックにのみ関連し、凝集ルーティングメトリックは、添加剤であるかどうかを示すために使用される、乗法であり、最大値を報告する、または最小値を報告します。
o A=0: The routing metric is additive
O A = 0：ルーティングメトリックは、添加剤であります
o A=1: The routing metric reports a maximum
入出力A = 1：ルーティングメトリックレポート最大
o A=2: The routing metric reports a minimum
入出力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.
フィールドが「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が最も高い優先度を意味し、0〜15の範囲です。
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 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.
実施例1：すべてのノードが電源から電力を供給し、最高のパスでなければならないRPLによって形成されたDAGは、より低い凝集予想伝送カウント（ETX）を有するものです。一つは、ヘッダ（C = O、O = 0、A = 00、R = 0）とETXメトリックオブジェクトであり、もう一つは、ノードエネルギー制約である。この場合、DAGメトリックコンテナは2つのルーティングメトリック/制約は、オブジェクト運びヘッダ（C = 1、O = 0、A = 00、R = 0）を持つオブジェクト。 RPLインスタンスが最大（A = 1）または最小（A = 2）を報告するメトリックオブジェクトを使用してもよいことに留意されたいです。 DIOメッセージはリンク報告：例えば、最良の経路は、低品質リンクを回避する経路ことを特徴とする、場合、パスメトリックが最大（A = 1）（より高いETX、低いリンク品質）を報告します品質メトリック（ETX）が親として広告ノードを選択し、各ノードは、後者が高い場合にのみ、そのローカルリンクのETX値に置き換えることにより、メトリックオブジェクトで運ば値を更新し、ノードによって処理されます。制約が満たされないDIOメッセージにシグナリング場合、広告ノードは単に選択されていない。限り制約に関しては、対象体ノードが電源から電力を供給しなければならないことを示すセクション3.1で定義されたノードのエネルギー制約オブジェクトを伝送します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：リンク・メトリックは、リンク品質レベルであるRPLによって形成されたDAGは、（セクション4で定義される）、リンク品質レベルは、経路に沿って記録されなければなりません。メトリックリンク品質レベル（C = O、O = 0、A = 00、R = 1）複数のサブオブジェクトを含む：この場合、DAGメトリックコンテナルーティングメトリック/制約オブジェクトを運びます。
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.
依然として、受信ノードによって生成されたのDIOに伝播されながら未認識のTLVは、無視されなければなりません。
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つのオクテットを使用して符号化されているので、彼らはまた、DAGメトリックコンテナに適用され、255バイトを超えることはできません。ほとんどの場合、広告を出してルーティングメトリックと制約は、その多くのスペースを必要としません。しかし、例えば、ルーティングメトリックのセットは長いパスに沿って記録されなければならない大きなスペースが必要とされる状況があるかもしれません。この場合には、[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メートルのコンテナオブジェクトであるかのように、この文書の残りの部分では、複数の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は、いくつかのリンクとノードメトリック/制約オブジェクトを指定します。いくつかのケースでは、特定のタイプの複数のオブジェクトがあってはならないことが述べられています。 RPLの実装は、そのタイプの複数のオブジェクトを受信した場合この場合、第二の目的は、無視されなければなりません。
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メトリックコンテナあたり制約として、複数のNSAのオブジェクトがあってはならない、とDAGメトリックコンテナあたりの測定基準として複数の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ビット）：Reservedフィールド。このフィールドは、送信時にゼロに設定しなければならなくて、領収書の上で無視しなければなりません。
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 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.
O「」フラグ：データ集約属性。データ集約は、[RFC5548]のセクション6.2に要件として記載されています。このように、潜在的にバッテリ駆動の環境でその寿命を高め、ネットワーク上のトラフィックの量を最小限にするように一部のアプリケーションでは、自分のルーティング決定で集約ノード属性を利用することができます。指向性の高いデータフローが定期的に期待されているアプリケーションは、データ集約サポートルーティングを利用することができます。設定した場合、このノードは、トラフィックアグリゲータとして働くことができることを示しています。さらに文書は、ノードのトラフィックアグリゲータの機能を記述するために、オプションの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ビットのフラグを使用する「過負荷」と同様の粒度の十分なレベルを提供するビットのようなルーティングプロトコルで使用されている、です。過負荷ビットを設定し、その過負荷ビットが設定されたノードを回避する可能性へのパスを計算するために使用されるアルゴリズムは、この文書の範囲外であるが、ルーティング振動を避けるために、このビットの頻繁な変更を避けることが推奨されます。設定されている場合、これは、ノードが過負荷とトラフィックを処理することができないかもしれないことを示しています。
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ルーティングメトリック/制約オブジェクトのFlagsフィールドは、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 viable when the sun is shining may disappear at night. A pump turning on may connect two previously disconnected sections of a network.
パワーとエネルギーが最もLLNsに明確に重要な資源です。まだ、十分に既存のLLNノードで使用される電源及びエネルギー蓄積デバイスの広い範囲をカバーする単純な抽象化は存在しません。これらは、商用電源式-、一次電池、エネルギースカベンジャー、および二次記憶機構の多様を含みます。スカベンジャーの4-20mAループから利用可能であるかもしれないような、電源の信頼性の低レベルを提供することができます。電源の信頼性が、周期的なストリーム、よく配置太陽電池によって提供されるような。または予測不可能な電源、断続的に電力を供給ポンプの振動エネルギースカベンジャーによって提供されるかもしれないような。太陽が輝いている時に生存しているルートは、夜に消えることがあります。投入ポンプは、ネットワークの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.
定期的に完全放電に使用している場合、このような充電式電池などのストレージシステムは、多くの場合、緊急手術に対して定期的に別の残留エネルギーの番号につながる、かなりの劣化を被ります。緊急時のトラフィックのルートは、定期的な報告のためのものとは異なる最適であってもよいです。
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.
それらの平均消費電流は、彼らが提供できることをピーク電流のごく一部を超える場合LLNsで使用される電池は、多くの場合、実質的に低下します。自立ノードは、プライマリストレージ、エネルギー捕捉、及び二次記憶装置の組み合わせを有することが/的に許容される平均検討された時間枠に応じた電流、例えば、ミリ秒、秒、時間、3つの異なる値をもたらす、珍しいことではありません年。
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.
生のパワーとエネルギーの値は、パケットを送受信するのエネルギーコストの知識がなくても無意味であり、寿命の推定値は、装置の必要な寿命にいくつかの高レベルの制約なしに値を持ちません。いくつかのケースでは、月のベッドテーブルにノードのバッテリーを排気経路10年に壁内のノードの寿命を減少させる経路に好ましいかもしれません。
Given the complexity of trying to address such a broad collection of constraints, this document defines two levels of fidelity in the solution.
制約のこうした幅広いコレクションに対処しようとしているの複雑さを考えると、この文書では、溶液中の忠実度の二つのレベルを定義します。
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 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].
中間複雑溶液はバッテリ駆動と掃気ノードの両方のエネルギー幸福を符号化するために使用することができる単一のパラメータです。ノードを捕捉するために、8ビットの量は、パーセントの単位で、アプリケーションによって消費される電力、E_E = P_IN / P_OUTで割ったスカベンジャーによって提供される電力です。それらがノード上エネルギー貯蔵装置の放電時間に関連し得る100の上方に、この計算に電力を平均化するための良好な時間を登録する消費、これはの範囲外である指定されているよりも多くの電力を捕捉しているノードこのドキュメント。バッテリ駆動デバイスの場合、E_Eは、パーセントの単位で、所望の最小寿命で割った現在の期待寿命です。バッテリ残量と実際の消費電力の推定が困難である可能性があり、この計算の詳細は、この文書の範囲外であるが、二つの例が提示されています。ノードは、その平均消費電力を測定することができる場合、E_Eは、実際の電力に対する所望の最大電力（初期エネルギーE_0は、所望の寿命Tで割った値）、E_E = P_MAX / P_nowの比として計算することができます。 E_E = E_bat / [E_0（TT）：E_batを推定することができる電池のエネルギー、総経過寿命は、tは、利用可能な場合あるいは、その後E_E残り目標エネルギーに対する残りの総蓄積されたエネルギーとして計算することができます。 / 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.
最適化された経路の例は、経路に沿ったすべての捕捉剤のためE_E> = 100制約を受ける経路に沿った全てのバッテリ駆動ノードの最大（MIN（E_E））です。
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メトリックコンテナあたり制約として、複数のNEオブジェクトがあってはならない、とDAGメトリックコンテナあたりメトリックとして、複数のNEオブジェクトがあってはなりません。
The NE object Type has been assigned value 2 by IANA.
NEオブジェクトタイプは、IANAによって値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.
ノードタイプを示す2ビットのフィールド：T（ノードタイプ）O。 T = 0は、主駆動ノード、T = 1バッテリ駆動ノード、及びT = 2エネルギースカベンジャーによって給電ノードを指定します。
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メトリックコンテナあたり制約として、複数のHPオブジェクトがあってはならない、とDAGメトリックコンテナあたりの測定基準として、複数の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ビット）：Reservedフィールド。このフィールドは、送信時にゼロに設定しなければならなくて、領収書の上で無視しなければなりません。
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ホップカウントフィールドの値を設定する必要がありホップカウントメトリックオブジェクトを挿入経路に沿って第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.
多くのLLNsは、スループットの広い範囲をサポートしています。いくつかのリンクの場合、これは変数の符号化に起因する可能性があります。多くのLLNsで見つかっ深くデューティサイクルさリンクの場合、変動はビットレートの取引の消費電力の結果として来ます。消費電力の対応する変化と大きさ以上の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メトリックコンテナあたり制約として、複数のスループットのオブジェクトが存在してはならない、とDAGメトリックコンテナあたりメトリックとして、複数のスループットのオブジェクトがあってはなりません。
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.
スループットオブジェクトは、スループットのサブオブジェクトで作られており、少なくとも一つのスループットサブオブジェクトを含まなければなりません。最初のスループットサブオブジェクトは、最近推定された実際のスループットでなければなりません。スループットの実際の推定は、このドキュメントの範囲外です。
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ビット。スループットは符号なし整数フォーマットで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メトリックコンテナあたり制約として、複数のレイテンシのオブジェクトが存在してはならない、とDAGメトリックコンテナあたりメトリックとして、複数のレイテンシのオブジェクトがあってはなりません。
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.
遅延オブジェクトは、待ち時間のサブオブジェクトで作られており、少なくとも一つのレイテンシサブオブジェクトを含まなければなりません。各遅延サブオブジェクトは、4バイトの固定長を有します。
The Latency object does not contain any additional TLVs.
レイテンシオブジェクトは、追加のTLVが含まれていません。
The Latency object Type has been assigned value 5 by IANA.
レイテンシオブジェクトタイプは、IANAによって値5が割り当てられています。
The Latency object is a metric or constraint.
レイテンシオブジェクトは、メトリックまたは制約です。
The format of the Latency object body is as follows:
次のようにレイテンシ対象体の形式は次のとおりです。
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.
遅延オブジェクトは、制約またはパスメトリックとして使用することができます。例えば、一つは、待ち時間は、いくつかの値を超えない場合があります。この場合、遅延オブジェクト共通ヘッダは、与えられた値が制約に関連することを示しています。別の例では、遅延オブジェクトは、値が、パスの遅延を反映するために経路に沿って更新される凝集添加メトリックとして使用することができます。
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.
LLNsでは、リンクの信頼性は、多くの理由のために分解することができる：時間スケールは、日ミリ秒毎に異なる信号減衰、様々な形態の干渉など、しばしば周期と人間の活動にリンクされています。パケット誤り率は、一般的に直接測定することができ、他の指標（例えば、ビット誤り率、平均故障間隔）は、典型的に由来します。そのような変動は、無線リンクに固有ではなく、また、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リンク品質レベルが不明であることを示し、1が最高のリンク品質レベルを報告0から7までの離散値を用いて、リンクの信頼性を定量化するために使用されます。 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を記録するために、すべての横断のノードを要求することができます。各ノードは、その後、（例えば、何か「ほとんどのリンクが3以下のLQL値を報告してパスを選択」など）いくつかのユーザー定義されたルールに基づいて、その親を選択するために、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メトリックコンテナあたりメトリックとして、複数の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ビット）：Reservedフィールド。このフィールドは、送信時にゼロに設定しなければならなくて、領収書の上で無視しなければなりません。
When the LQL metric is recorded, the LQL object body comprises one or more LQL Type 1 sub-object.
LQLメトリックが記録されている場合、LQL対象体は、一つ以上のLQLタイプ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.
ヴァル：0は未決定手段1が最高のリンク品質を示す0から7までLQL値。
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メトリックは、ノードが正常にパケットを届けるために、先に作ることを期待送信の数です。例えば、実装は、以下の式を使用してもよい：ETX = 1 /（DF * DR）どこLQLメトリックルーティングとは対照的に、ETXは、特定の式に従って計算（整数でなくてもよい）離散的な値を提供しますDFは、パケットが隣人によって受信され、博士は、確認応答パケットが正常に受信されていることを測定した確率であることを測定した確率です。この文書では、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メトリックコンテナあたり制約として、複数のETXオブジェクトがあってはならない、とDAGメトリックコンテナあたりメトリックとして、複数の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のサブオブジェクトで作られており、少なくとも一つの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> 511.9921875は、オブジェクトの値が65535である最大になる場合、例えば、ETX = 3.569場合、オブジェクトの値が457となります。
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を受信した場合DAGルートに広告ノードからトラバースリンク）の全てのリンクのETXが、それはその好ましい親としてそのノードを選択した場合、ノードは、それ自体、好ましい親の間でローカルリンクのETXを追加することによって、経路ETXを更新します潜在的にそれ自体が新しいパスETXを広告する前に、受信した経路コスト（パス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.
リンクの色（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ビットのフィールドは、フラグフィールド、およびいないスカラー値です。各ノードは、（例えば、「彼らの最初のビットが1（例えば、暗号化されたリンク）を設定したリンクの最大数を持つパスを選択」）は、ユーザ定義のルールに基づいて、親を選択するためにLCを使用することができます。 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.
リンクの色（LC）の目的は、DAGメトリックコンテナ中に存在してもよいです。 DAGメトリックコンテナあたり制約として、複数のLCオブジェクトがあってはならない、とDAGメトリックコンテナあたりメトリックとして、複数の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ビット）：Reservedフィールド。このフィールドは、送信時にゼロに設定しなければならなくて、領収書の上で無視しなければなりません。
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対象体は、一つ以上の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対象体は、一つ以上の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ビット）：Reservedフィールド。このフィールドは、送信時にゼロに設定しなければならなくて、領収書の上で無視しなければなりません。
'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.
メトリック更新を最小限にするために、マルチ閾値アルゴリズムは、更新が送信されるべきときを決定するために使用されるかもしれません。実用的な、ローパスフィルタリング及び/又はヒステリシスは、これらの値の急激な変動を回避するために使用されなければならない場合。動的メトリックを使用して経路計算アルゴリズムの仕様はこの文書の範囲外であるが、最終的に、慎重にメトリック値の変更時に新しいルートのあまりに頻繁な計算を回避するために、経路最適化アルゴリズムを設計することが推奨されます。
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レビュープロセスを通じて割り当てられる（[RFC5226]を参照のこと）：それぞれの新しいレジストリの割り当てポリシーは、IETFの見直しによるものです。具体的には、新しい割り当てが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リンクETXこのドキュメント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」と呼ばれるサブレジストリを作成しました。 Typeフィールドは、その値が0〜255の値0の間に含まれる未割り当てである8ビットのフィールドです。 Lengthフィールドは、値が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は、ルーティングメトリック/制約共通ヘッダのフィールドのコードスペースを管理するために、「フィールドルーティングメトリック/制約共通ヘッダ」と呼ばれる、サブレジストリを作成しました。
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
フィールドのコードスペース（ルーティングメトリック/制約共通ヘッダ）値意味リファレンス
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ルーティングメトリックは、この文書1ルーティングメトリックは、このドキュメントでは、2ルーティングメトリックこの文書3ルーティングメトリックは、このドキュメント乗法最小を報告する最大値を報告する添加剤であります
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は、悪意のあるノードが他のノードのトラフィックと切片パケットのための好ましいネクストホップルータとして選択するように、それはルーティングのための良好な指標を有することを偽って宣伝することを可能にするべきではありません。別の攻撃はDODAGの潜在的な変動につながるので、常にリンクの質と結果的に関連するルーティングメトリックを変更しようとする試みには、リンク上の断続的な攻撃を行うことからなるものであってもよいです。したがって、攻撃を受ける可能性が非常に不安定なリンクのための広告のルーティングメトリックを停止するように場所のメカニズムに置くために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.
いくつかのルーティングメトリックは、ネットワーク（等高度に信頼性のないリンク、エネルギー的に低い実行しているノード）の弱点の一部の領域を識別するために使用されてもよいです。そのような情報は、潜在的な攻撃者によって使用されてもよいです。したがって、慎重にそれらがネットワークの状態について提供したり、[RFC6550]で指定されるように、その情報を保護するために、適切なセキュリティ対策を使用することRPL視認性のレベルで使用されるべきメトリクスを検討することが推奨されます。
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.
著者は、ヨンジェキム、Hakjinチョン、デビッド・マイヤー、ミーシャのDohler、アンダース・ブラント、フィリップ・リーバイス、パスカルThubert、リチャード・ケルシー、ジョナサン・ホイ、アレクサンドル・ペトレスク、リチャード・ケルシー、マチルドDurvy、ポイボス・チェン、ティムの貢献を認めるしたいと思います彼らのレビューと貴重なコメントのための冬、ヨアフベン・Yehezkel、マッテオ・パリ、Omprakash Gnawali、マッズWestergreen、Mukul Goyal氏、ジョセフSaloway、デイヴィッドCuller、とヤリArkko。彼の徹底的な見直しのためのエードリアンファレルに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[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]冬、T.、エド。、Thubert、P.、エド。、ブラント、A.、ホイ、J.、ケルシー、R.、リーバイス、P.、ピスター教授、K.、Struik、R.、Vasseur 、JP、およびR.アレクサンダー、 "RPL：低消費電力とロッシーネットワークのためのIPv6ルーティングプロトコル"、RFC 6550、2012月。
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[RFC1195] Callon、R.は、RFC 1195、1990年12月 "OSIの使用は、TCP / IPやデュアル環境でのルーティングのためIS-IS"。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]モイ、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.、マルコム、J.、Agogbua、J.、オデル、M.、およびJ.マクマナス、 "トラフィックエンジニアリングオーバー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.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "RSVP-TE：LSPトンネルのための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.、冬、T.、およびD.バーセル、 "都市の低消費電力とロッシーネットワークのルーティング要件"、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]ピスター教授、K.、Thubert、P.、Dwars、S.、およびT.フィニー、 "低消費電力とロッシーネットワークにおける産業ルーティング要件"、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]ブラント、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.、デ・ミル、P.、Riouの、N.、およびW. Vermeylen、 "低消費電力とロッシーネットワークにおけるビルオートメーションルーティング要件"、RFC 5867、2010年6月。
[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.、エド。、 "低消費電力とロッシーネットワークのルーティングプロトコル（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.カンナ、 "ARPANETとMILNETのために改訂されたルーティングメトリックのパフォーマンス"、軍事通信会議、MILCOM '89、1989年3月。
Authors' Addresses
著者のアドレス
JP. Vasseur (editor) Cisco Systems 11, Rue Camille Desmoulins Issy Les Moulineaux 92782 France
JP。 Vasseur（編集者）、シスコシステムズ11ルーカミーユ・デムーラン92782イシレムリノーフランス
EMail: jpv@cisco.com
メールアドレス：jpv@cisco.com
Mijeom Kim (editor) Corporate Technology Group, KT 17 Woomyeon-dong, Seocho-gu Seoul 137-792 Korea
Mijeomキム（編集者）コーポレート・テクノロジー・グループ、KT 17 Woomyeon洞、瑞草区ソウル137から792韓国
EMail: mjkim@kt.com
メールアドレス：mjkim@kt.com
Kris Pister Dust Networks 30695 Huntwood Ave. Hayward, CA 95544 USA
クリスピスター教授ダストネットワークス30695 Huntwoodアベニュー。ヘイワード、CA 95544 USA
EMail: kpister@dustnetworks.com
メールアドレス：kpister@dustnetworks.com
Nicolas Dejean Elster SAS Espace Concorde, 120 impasse JB Say Perols 34470 France
ニコラスDejeanエルスターSASスペースコンコルド120死んJBセイ34470ペロルフランス
EMail: nicolas.dejean@coronis.com
メールアドレス：nicolas.dejean@coronis.com
Dominique Barthel France Telecom Orange 28 chemin du Vieux Chene, BP 98 Meylan 38243 France
ドミニク・バーセルフランステレコムオレンジ28 CHEMINドゥヴューシュヌ、BP 98 38243メランフランス
EMail: dominique.barthel@orange.com
メールアドレス：dominique.barthel@orange.com