[要約] このRFCは、低消費電力かつ損失の多いネットワーク（LLN）のルーティング（RPL）で使用される各種メトリックと制約条件を定義しています。スループットや遅延といった一般的な指標に加え、ノードの残りエネルギー（バッテリー状態）やホップカウント、リンク信頼性などを考慮した柔軟な経路選択を可能にします。
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）は、従来の有線ネットワークやアドホックネットワークとは異なる特性を持つため、新しいルーティングメトリックと制約が必要です。ホップ数やリンクメトリックを用いる一般的なInterior Gateway Protocol（IGP）とは異なり、本書はRouting Protocol for Low-Power and Lossy Networks（RPL）で使用する、LLN向けのリンクおよびノードのルーティングメトリックと制約を規定します。
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.
本書はInternet Engineering Task Force（IETF）が作成したもので、IETFコミュニティの合意を示しています。公開レビューを経て、Internet Engineering Steering Group（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.
著作権 © 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.
本書の公開時点で適用されます。各文書は本書に関する権利と制限を説明しているため、注意深く確認してください。本書から抽出したコードコンポーネントには、Trustの法的条項のセクション4.eで定めるSimplified BSD Licenseの文面を含める必要があります。また、Simplified BSD Licenseに記載されているとおり、保証なしで提供されます。
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
1. Introduction ....................................................3
1. はじめに ........................................................3
1.1. Requirements Language ......................................6
1.1. 要件表現の規則 .............................................6
2. Object Formats ..................................................7
2. オブジェクト形式 ................................................7
2.1. DAG Metric Container Format ................................7
2.1. DAGメトリックコンテナの形式 ................................7
2.2. Use of Multiple DAG Metric Containers .....................10
2.2. 複数のDAG Metric Containerの使用 ..........................10
2.3. Metric Usage ..............................................10
2.3. メトリックの使用 ..........................................10
3. Node Metric/Constraint Objects .................................11
3. ノードのメトリック／制約オブジェクト ...........................11
3.1. Node State and Attribute Object ...........................11
3.1. ノード状態および属性オブジェクト ..........................11
3.2. Node Energy Object ........................................12
3.2. ノードエネルギーオブジェクト ..............................12
3.3. Hop Count Object ..........................................16
3.3. ホップカウントオブジェクト ................................16
4. Link Metric/Constraint Objects .................................17
4. リンクのメトリック／制約オブジェクト ...........................17
4.1. Throughput ................................................17
4.1. スループット ..............................................17
4.2. Latency ...................................................18
4.2. 遅延 ......................................................18
4.3. Link Reliability ..........................................19
4.3. リンク信頼性 ..............................................19
4.3.1. The Link Quality Level Reliability Metric ..........19
4.3.1. Link Quality Level信頼性メトリック .................19
4.3.2. The ETX Reliability Object .........................21
4.3.2. ETX信頼性オブジェクト ..............................21
4.4. Link Color Object .........................................22
4.4. Link Colorオブジェクト ....................................22
4.4.1. Link Color Object Description ......................22
4.4.1. Link Colorオブジェクトの説明 .......................22
4.4.2. Mode of Operation ..................................24
4.4.2. 動作モード .........................................24
5. Computation of Dynamic Metrics and Attributes ..................24
5. 動的メトリックと属性の計算 .....................................24
6. IANA Considerations ............................................25
6. IANAに関する考慮事項 ...........................................25
6.1. Routing Metric/Constraint Type ............................25
6.1. ルーティングメトリック／制約タイプ ........................25
6.2. Routing Metric/Constraint TLVs ............................25
6.2. ルーティングメトリック／制約TLV ...........................25
6.3. Routing Metric/Constraint Common Header Flag Field ........26
6.3. ルーティングメトリック／制約共通ヘッダーのFlagフィールド ..26
6.4. Routing Metric/Constraint Common Header A Field ...........26
6.4. ルーティングメトリック／制約共通ヘッダーのAフィールド .....26
6.5. NSA Object Flags Field ....................................26
6.5. NSAオブジェクトのFlagsフィールド ..........................26
6.6. Hop-Count Object Flags Field ..............................27
6.6. Hop CountオブジェクトのFlagsフィールド ....................27
6.7. Node Type Field ...........................................27
6.7. Node Typeフィールド .......................................27
7. Security Considerations ........................................27
7. セキュリティに関する考慮事項 ...................................27
8. Acknowledgements ...............................................28
8. 謝辞 ...........................................................28
9. References .....................................................28
9. 参考文献 .......................................................28
9.1. Normative References ......................................28
9.1. 規範的な参考文献 ..........................................28
9.2. Informative References ....................................28
9.2. 参考情報文献 ..............................................28
This document makes use of the terminology defined in [ROLL-TERMS].
本書では[ROLL-TERMS]で定義されている用語を使用します。
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).
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]で規定されるRouting Protocol for Low-Power and Lossy Networks（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実装にとって任意であり、実装はそれらを含めてもかまいません (MAY)。つまり、実装は本書で定義する機能（メトリック、制約）のうち、異なる部分集合を自由に含められます。特定の環境で使用するメトリック／制約の組み合わせやその他の任意のRPLパラメーターは、ROLLワーキンググループが作成する適用プロファイル文書で適合プロファイルとして規定されます。RPLでは、たとえば[RFC6552]で定義されるObjective Functionを使い、メトリックを一切使わないこともできます。
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]で定義されるDestination-Oriented Directed Acyclic Graph（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 動的メトリックと静的メトリック
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.
動的メトリックの使用は新しいものではなく、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の配備で使用するルーティングメトリックと制約の集合は、Objective Function（DAGの構築規則）に従って構築されるDAGに沿って通知されます。ルーティングメトリックと制約は、[RFC6550]で規定されるDODAG Information Object（DIO）メッセージで広告されます。RPLでは、特性の異なる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の計算に使用するObjective Functionの仕様は、本書の範囲外です。本書は、Objective Functionから独立したルーティングメトリックと制約を定義します。たとえば汎用のObjective Functionは、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メッセージを受信したノードは、Objective Functionとローカルポリシーに従い、特定の信頼性レベルを持つリンクの数が最大となる親ノードを選ぶことがあります。
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].
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 Metric Containerオブジェクトに格納されます。複数のメトリックや制約が含まれる場合、それらを使って最良の経路を決定する方法はObjective Functionで定義できます。
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.
Routing Metric/Constraintオブジェクトは、特定の種類のメトリックまたは制約を表します。これらは、DAG Metric Container（[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：Routing Metric/Constraintオブジェクトの汎用形式
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も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（Routing Metric/Constraint Type、8ビット）：このフィールドは各Routing Metric/Constraintオブジェクトを一意に識別します。値はIANAが管理します。
Length (8 bits): this field defines the length of the object body, expressed in bytes. It ranges from 0 to 255.
Length（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 Flagsフィールド（16ビット）：Routing Metric/ConstraintオブジェクトのFlagフィールドはIANAが管理します。未割り当てのビットは予約済みとみなします。これらのビットは送信時に0に設定しなければならず (MUST)、受信時に無視しなければなりません (MUST)。
The following bits of the Routing Metric/Constraint Flag field object are currently defined:
Routing Metric/Constraint Flagフィールドでは、現在、次のビットが定義されています。
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」フラグ：セットされている場合、Routing Metric/Constraintオブジェクトがルーティング制約を表すことを示します。クリアされている場合、オブジェクトはルーティングメトリックを表します。
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」フラグが0の場合、「O」フラグは送信時に0に設定し、受信時に無視しなければなりません (MUST)。
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の場合はクリアしなければなりません (MUST)。セットされている場合、経路に沿ってルーティングメトリックを記録することを示します。クリアされている場合、メトリックを集約します。
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.
「C」フラグがセットされている場合（つまりRouting Metric/Constraintオブジェクトがルーティング制約を表す場合）、Aフィールドに意味はありません。また、Aフィールドが有効なのは「R」ビットがクリアされている場合だけです。それ以外の場合、Aフィールドは0に設定しなければならず (MUST)、受信時に無視しなければなりません (MUST)。
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ビット）：このフィールドは、コンテナ内の他のオブジェクトに対する当該Routing Metric/Constraintオブジェクトの優先順位を示します。DAG Metric Containerに複数のRouting Metricオブジェクトが含まれる場合に有用です。値の範囲は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 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）が最小の経路です。この場合、DAG Metric ContainerにはRouting Metric/Constraintオブジェクトが2つ格納されます。1つはヘッダー（C=0, O=0, A=00, R=0）のETXメトリックオブジェクト、もう1つはヘッダー（C=1, O=0, A=00, R=0）のNode Energy制約オブジェクトです。RPLインスタンスは、メトリックオブジェクトを使って最大値（A=1）または最小値（A=2）を報告することもできます。たとえば、最良経路が低品質リンクを避ける経路である場合、経路メトリックでは最大値（A=1）を報告します（ETXが高いほどリンク品質は低くなります）。リンク品質メトリック（ETX）を報告するDIOメッセージをノードが処理するとき、その広告ノードを親として選ぶ各ノードは、メトリックオブジェクト内の値をローカルリンクのETX値で更新します。ただし、ローカル値が既存値より大きい場合に限ります。制約については、オブジェクト本体にセクション3.1で定義するNode Energy制約オブジェクトを格納し、ノードが商用電源で駆動していることを指定します。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で定義）であり、経路に沿って記録します。この場合、DAG Metric Containerには、複数のサブオブジェクトを含むリンク品質レベルメトリック（C=0, O=0, A=00, R=1）のRouting Metric/Constraintオブジェクトが格納されます。
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:
Routing Metric/Constraintオブジェクトには、追加のType-Length-Value（TLV）エンコードデータセットを1つ以上含めることもできます。各Routing Metric/Constraint TLVは、次の構造を持ちます。
Type: 1 byte Length: 1 byte Value: variable
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).
Routing Metric/Constraint TLVは、Type用の1バイト、TLV長を示す1バイト、およびValueフィールドで構成されます。TLV LengthフィールドはValueフィールドの長さをバイト単位（0～255）で示します。
Unrecognized TLVs MUST be silently ignored while still being propagated in DIOs generated by the receiving node.
認識できないTLVは、受信ノードが生成するDIO内で伝播したまま、黙って無視しなければなりません (MUST)。
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.
Routing Metric/Constraintオブジェクトの識別子コード空間に対する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オクテットで符号化されるため、最大255バイトです。この制限はDAG Metric Containerにも適用されます。ほとんどの場合、広告されるルーティングメトリックと制約はこれほどの領域を必要としません。ただし、長い経路に沿って複数のメトリックを記録する場合など、より大きな領域が必要になることがあります。この場合、[RFC6550]の規定に従って、複数のDAG Metric Containerオブジェクトを使い、オーバーフローを避けます。
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 Metric Containerオブジェクトを、実際には1つの長いDAG Metric Containerオブジェクトであるかのように扱います。
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 Metric Containerに集約型メトリック（スカラー値）が1つ含まれる場合、最良経路を選ぶ際の順序関係はメトリックの種類から暗黙的に決まります。たとえば、Hop Count、Link Latency、ETXでは値が小さい方が優れています。Node EnergyやThroughputでは、値が大きい方が優れています。
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で定義するNode Energyメトリック（E_Eフィールド）は、Aフィールドで指定する明示的なmin関数により経路に沿って集約されます。メトリックがエネルギーであるため、最良経路は暗黙的な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 Metric Containerに複数の集約型メトリックが含まれる場合、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.
複数の集約型メトリックの使用例として、Hop Countを第一基準、Link Quality Level（LQL）を第二基準、Node Energyを最終的なタイブレーカーにする方法があります。この場合、Hop Count、LQL、Node Energyの各メトリックオブジェクトの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つ目以降のオブジェクトは黙って無視しなければなりません (MUST)。
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.
制約がある場合、ノードは同じ種類のメトリックを含めなければなりません (MUST)。そのメトリックを使って制約を満たしているか確認します。いかなる場合も、ノードは制約の内容を変更してはなりません (MUST NOT)。
The Node State and Attribute (NSA) object is used to provide information on node characteristics.
Node State and Attribute（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 Metric Containerに含めてもかまいません (MAY)。DAG Metric Container内では、制約としてのNSAオブジェクトを複数含めてはならず (MUST NOT)、メトリックとしてのNSAオブジェクトも複数含めてはなりません (MUST NOT)。
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 Routing Metric/Constraint Typeには、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 Flags（8ビット）：予約フィールドです。このフィールドは送信時に0に設定しなければならず (MUST)、受信時に無視しなければなりません (MUST)。
Flags field (8 bits). The following two bits of the NSA object are currently defined:
Flagsフィールド（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 「A」フラグ：データ集約属性。データ集約は[RFC5548]のセクション6.2で要件として挙げられています。アプリケーションによっては、ネットワーク上のトラフィック量を減らし、バッテリー駆動環境での稼働期間を延ばすためのルーティング判断に、集約ノード属性を利用できます。定期的に指向性の高いデータフローが発生するアプリケーションでは、データ集約に対応したルーティングが有用な場合があります。セットされている場合、ノードがトラフィック集約器として動作できることを示します。後続の文書で、ノードのトラフィック集約機能を記述する任意のTLVを定義してもかまいません (MAY)。
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の過負荷、メモリ不足、その他のノード関連の状態に応じて、ノード負荷を示すフラグをセットしてもかまいません (MAY)。ノード負荷を単純な1ビットのフラグで表せば、IS-ISなどのルーティングプロトコルで使われる「過負荷」ビットと同程度の粒度を確保できます。過負荷ビットの設定方法や、そのビットがセットされたノードを避ける経路の計算方法は本書の範囲外ですが、ルーティングの振動を避けるため、このビットを頻繁に変更しないことが推奨されます (SHOULD)。セットされている場合、ノードが過負荷であり、トラフィックを処理できないことがあると示します。
The unspecified flag fields MUST be set to zero on transmission and MUST be ignored on receipt.
未指定のフラグビットは送信時に0に設定しなければならず (MUST)、受信時に無視しなければなりません (MUST)。
The Flags field of the NSA Routing Metric/Constraint object is managed by IANA. Unassigned bits are considered as reserved.
NSA Routing Metric/Constraintオブジェクトの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.
電力とエネルギーは、ほとんどのLLNで明らかに重要な資源です。現行のLLNノードで使われる多様な電源や蓄電装置を十分に表せる単純な抽象化は、まだありません。電源や蓄電方式には、商用電源、一次電池、エネルギーハーベスタ、さまざまな二次蓄電方式があります。エネルギーハーベスタは、4～20 mAループから得られるような安定した低電力、適切な位置に設置した太陽電池から得られるような安定して周期的な電力、または間欠的に動作するポンプの振動発電器から得られるような予測困難な電力を供給します。日照中は利用可能な経路が夜間には使えなくなることがあります。ポンプが動作を始めることで、それまで分断されていたネットワークの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.
LLNで使う電池は、平均消費電流が供給可能なピーク電流のごく一部を超えると、大きく劣化することがあります。自立型ノードでは、一次電池、エネルギーハーベスティング、二次蓄電を組み合わせることも珍しくありません。その場合、ミリ秒、秒、時間／年など、対象とする時間尺度に応じて、許容できる平均電流値が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.
電力やエネルギーの生の値は、パケットの送受信に必要なエネルギーが分からなければ意味を持ちません。また、機器に求める稼働期間という上位の制約がなければ、稼働期間の推定値にも意味がありません。場合によっては、ベッド脇のテーブル上のノードの電池を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.
最も単純な方式では、電源の種類「powered」（外部電源駆動）、「battery」（電池）、「scavenger」（エネルギーハーベスティング）の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は現在の予想稼働期間を希望する最低稼働期間で割った値で、単位はパーセントです。残存電池エネルギーや実際の消費電力の推定は難しい場合があります。この計算の詳細は本書の範囲外ですが、2つの例を示します。ノードが平均消費電力を測定できる場合、E_Eは、希望最大電力（初期エネルギーE_0を希望稼働期間Tで割った値）と実際の消費電力P_nowとの比として計算できます。E_E=P_max/P_nowです。あるいは、バッテリー内のエネルギーE_batを推定でき、経過稼働期間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.
Node Energy（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 Metric Containerに含めてもかまいません (MAY)。DAG Metric Container内では、制約としてのNEオブジェクトを複数含めてはならず (MUST NOT)、メトリックとしてのNEオブジェクトも複数含めてはなりません (MUST NOT)。
The NE object Type has been assigned value 2 by IANA.
NEオブジェクトのTypeには、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:
Flagsフィールド（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（Included、包含）：Iビットは、ノードタイプを制約として使う場合にのみ関係します。たとえば、経路を商用電源駆動ノードだけに通し、電池駆動ノードを除外する指定ができます。Iビットで包含か除外かを指定します。セットされている場合、ノードタイプフィールドで指定された種類のノードを経路に含めなければなりません (MUST)。クリアされている場合、その種類のノードを経路から除外しなければなりません (MUST)。
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（node Type）：ノードの種類を示す2ビットフィールドです。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（Estimation、推定）：メトリックで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（Estimated-Energy、推定エネルギー）：残存エネルギーの推定割合を示す8ビット符号なし整数フィールドです。E_Eフィールドは「E」フラグがセットされている場合にのみ関係し、「E」フラグがクリアされている場合は0に設定しなければなりません (MUST)。
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.
Hop Count（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 Metric Containerに含めてもかまいません (MAY)。DAG Metric Container内では、制約としてのHPオブジェクトを複数含めてはならず (MUST NOT)、メトリックとしてのHPオブジェクトも複数含めてはなりません (MUST NOT)。
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ルーティングメトリックオブジェクトのTypeには、IANAによって値3が割り当てられています。
The format of the Hop Count object body is as follows:
Hop Countオブジェクト本体の形式は次のとおりです。
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：Hop Countオブジェクト本体の形式
Res flags (4 bits): Reserved field. This field MUST be set to zero on transmission and MUST be ignored on receipt.
Res Flags（4ビット）：予約フィールドです。このフィールドは送信時に0に設定しなければならず (MUST)、受信時に無視しなければなりません (MUST)。
No Flag is currently defined. Unassigned bits are considered reserved. They MUST be set to zero on transmission and MUST be ignored on receipt.
現時点で定義されているFlagはありません。未割り当てのビットは予約済みとみなします。これらのビットは送信時に0に設定しなければならず (MUST)、受信時に無視しなければなりません (MUST)。
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ルートは経路が通過できるホップ数の上限を示します。上限に達すると、その経路に他のノードは参加できません。メトリックとして使う場合、経路を通過する各ノードがHop Countフィールドを1つ増やします。
Note that the first node along a path inserting a Hop Count metric object MUST set the Hop Count field value to 1.
経路上で最初にHop Countメトリックオブジェクトを挿入するノードは、Hop Countフィールドの値を1に設定しなければなりません (MUST)。
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でよく使われる低デューティ比のリンクでは、消費電力とビットレートのトレードオフによってスループットが変わります。MAC層プロトコルの中には、消費電力を対応して変化させながら、リンクの実効ビットレートを3桁以上の範囲で調整できるものがあります。効率的な運用のため、ノードは現在利用可能なスループットに加え、リンクが対応できるスループットの範囲も報告するとよい場合があります。
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.
ThroughputオブジェクトはDAG Metric Containerに含めてもかまいません (MAY)。DAG Metric Container内では、制約としてのThroughputオブジェクトを複数含めてはならず (MUST NOT)、メトリックとしてのThroughputオブジェクトも複数含めてはなりません (MUST NOT)。
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.
ThroughputオブジェクトはThroughputサブオブジェクトで構成され、少なくとも1つのThroughputサブオブジェクトを含まなければなりません (MUST)。最初のThroughputサブオブジェクトには、直近に推定した実効スループットを格納しなければなりません (MUST)。スループットの具体的な推定方法は本書の範囲外です。
Each Throughput sub-object has a fixed length of 4 bytes.
各Throughputサブオブジェクトの長さは固定で4バイトです。
The Throughput object does not contain any additional TLVs.
Throughputオブジェクトに追加のTLVは含まれません。
The Throughput object Type has been assigned value 4 by IANA.
ThroughputオブジェクトのTypeには、IANAによって値4が割り当てられています。
The format of the Throughput object body is as follows:
Throughputオブジェクト本体の形式は次のとおりです。
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：Throughputオブジェクト本体の形式
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サブオブジェクトの形式
Throughput: 32 bits. The Throughput is encoded in 32 bits in unsigned integer format, expressed in bytes per second.
Throughput（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.
LatencyオブジェクトはDAG Metric Containerに含めてもかまいません (MAY)。DAG Metric Container内では、制約としてのLatencyオブジェクトを複数含めてはならず (MUST NOT)、メトリックとしてのLatencyオブジェクトも複数含めてはなりません (MUST NOT)。
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.
LatencyオブジェクトはLatencyサブオブジェクトで構成され、少なくとも1つのLatencyサブオブジェクトを含まなければなりません (MUST)。各Latencyサブオブジェクトの長さは固定で4バイトです。
The Latency object does not contain any additional TLVs.
Latencyオブジェクトに追加のTLVは含まれません。
The Latency object Type has been assigned value 5 by IANA.
LatencyオブジェクトのTypeには、IANAによって値5が割り当てられています。
The Latency object is a metric or constraint.
Latencyオブジェクトはメトリックまたは制約です。
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：Latencyオブジェクト本体の形式
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サブオブジェクトの形式
Latency: 32 bits. The Latency is encoded in 32 bits in unsigned integer format, expressed in microseconds.
Latency（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オブジェクトは制約または経路メトリックとして使用できます。たとえば、遅延が指定値を超えないよう制約できます。その場合、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.
信頼性のさまざまな側面を表すリンク信頼性メトリックを複数定義できます。本書では、Link Quality Level（LQL）とETX Metricの2つを定義します。
Note that a RPL deployment MAY use the LQL, the ETX, or both.
RPLの配備では、LQL、ETX、または両方を使用してもかまいません (MAY)。
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.
Link Quality Level（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 Metricオブジェクトは、経路を通るすべてのノードに対し、進入リンクのLQLをLQLオブジェクトに記録するよう求めることができます。各ノードはその記録を使い、ユーザー定義の規則（例：「LQL値が3以下と報告されたリンク数が最も多い経路を選ぶ」）に基づいて親ノードを選べます。
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 Metric Containerに含めてもかまいません (MAY)。DAG Metric Container内では、制約としてのLQLオブジェクトを複数含めてはならず (MUST NOT)、メトリックとしてのLQLオブジェクトも複数含めてはなりません (MUST NOT)。
The LQL object MUST contain one or more sub-object used to report the number of links along with their LQL.
LQLオブジェクトには、各LQL値とともにリンク数を報告するサブオブジェクトを1つ以上含めなければなりません (MUST)。
The LQL object Type has been assigned value 6 by IANA.
LQLオブジェクトのTypeには、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 Flags（8ビット）：予約フィールドです。このフィールドは送信時に0に設定しなければならず (MUST)、受信時に無視しなければなりません (MUST)。
When the LQL metric is recorded, the LQL object body comprises one or more LQL Type 1 sub-object.
LQLメトリックを記録する場合、LQLオブジェクト本体はLQL Type 1サブオブジェクトを1つ以上含みます。
The format of the LQL Type 1 sub-object is as follows
LQL Type 1サブオブジェクトの形式は次のとおりです。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Val | Counter |
+-+-+-+-+-+-+-+-+
Figure 11: LQL Type 1 Sub-Object Format
図11：LQL Type 1サブオブジェクトの形式
Val: LQL value from 0 to 7 where 0 means undetermined and 1 indicates the highest link quality.
Val：LQL値（0～7）です。0は未判定、1は最も高いリンク品質を示します。
Counter: number of links with that value.
Counter：その値を持つリンクの数です。
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 Metric Containerに含めてもかまいません (MAY)。DAG Metric Container内では、制約としてのETXオブジェクトを複数含めてはならず (MUST NOT)、メトリックとしてのETXオブジェクトも複数含めてはなりません (MUST NOT)。
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サブオブジェクトを含まなければなりません (MUST)。各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オブジェクトのTypeには、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値（広告元ノードからDAGルートまでの各通過リンクの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.
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.
記録型メトリックとして使用する場合、カウンターで情報を圧縮し、各Link Colorについて、その色を持つリンク数を報告します。
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 Metric Containerに含めてもかまいません (MAY)。DAG Metric Container内では、制約としてのLCオブジェクトを複数含めてはならず (MUST NOT)、メトリックとしてのLCオブジェクトも複数含めてはなりません (MUST NOT)。
There MUST be a at least one LC sub-object per LC object.
各LCオブジェクトには、LCサブオブジェクトを少なくとも1つ含めなければなりません (MUST)。
The LC object does not contain any additional TLVs.
LCオブジェクトに追加のTLVは含まれません。
The LC object Type has been assigned value 8 by IANA.
LCオブジェクトのTypeには、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 Flags（8ビット）：予約フィールドです。このフィールドは送信時に0に設定しなければならず (MUST)、受信時に無視しなければなりません (MUST)。
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 Type 1サブオブジェクトを1つ以上含めます。
The format of the LC Type 1 sub-object body is as follows:
LC Type 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 Type 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 Type 2サブオブジェクトを1つ以上含めます。
The format of the LC Type 2 sub-object body is as follows:
LC Type 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 Type 2サブオブジェクトの形式
Reserved (5 bits): Reserved field. This field MUST be set to zero on transmission and MUST be ignored on receipt.
Reserved（5ビット）：予約フィールドです。このフィールドは送信時に0に設定しなければならず (MUST)、受信時に無視しなければなりません (MUST)。
'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」ビット：Link Colorを制約として使用する場合にのみ関係します。セットされている場合、指定色のリンクを経路に含めることを示します。クリアされている場合、指定色のリンクを経路から除外することを示します。
It is left to the implementer to define the meaning of each bit of the 10-bit Link Color Flag field.
10ビットのLink Color Flagフィールドの各ビットの意味は、実装者が定義します。
The link color may be used as a constraint or a metric.
Link Colorは制約またはメトリックとして使用できます。
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 Metric Containerに挿入し、特定の色のリンクを計算した経路に含めるか除外するかを示せます。
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 Metric ContainerにLCオブジェクトを挿入し、ローカルリンクの色を報告できます。同じ色を報告するLCオブジェクトがすでにある場合、ノードは同一のLCサブオブジェクトを重複して追加してはならず (MUST NOT)、Counterフィールドを増分しなければなりません (MUST)。
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.
すでに述べたように、LLNでは多くの状況で動的に計算されるメトリックが極めて重要です。これは、さまざまなメトリックが頻繁に変化し、それに応じてルーティング判断を調整する必要があるためです。一方、ネットワークで変更を報告する頻度には注意が必要です。属性はそれぞれ固有の時間尺度で変化します。報告頻度は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.
メトリックの更新を最小限にするため、更新を送信するタイミングの判定に複数閾値アルゴリズムを使用してもかまいません (MAY)。実用上可能であれば、値の急激な変動を避けるためにローパスフィルターやヒステリシスを使用するとよいです。最後に、動的メトリックを使った経路計算アルゴリズムの仕様は本書の範囲外ですが、メトリック値の変化に応じて経路を頻繁に再計算しないよう、経路最適化アルゴリズムを慎重に設計することが推奨されます (SHOULD)。
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は、すべてのRouting Metric/Constraintオブジェクトのコードポイントとサブレジストリを収録する「RPL Routing Metric/Constraint」という新しい最上位レジストリを設けました。
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 Reviewです。新しい値は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 Reviewの措置が必要です。各ビットは、次の項目とともに管理します。
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はRouting Metric/ConstraintオブジェクトのType用に「Routing Metric/Constraint Type」サブレジストリを作成しました。値の範囲は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
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は、Routing Metric/Constraintオブジェクト内に格納するすべてのTLV用に「Routing Metric/Constraint TLVs」サブレジストリを作成しました。Typeフィールドは8ビットで、値の範囲は0～255です。値0は未割り当てです。Lengthフィールドも8ビットで、値の範囲は0～255です。Valueフィールドの値の範囲はTypeによって異なります。現時点ではTypeが登録されていないため、ここでは範囲を定義しません。
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は、Routing Metric/Constraint共通ヘッダーの9ビットFlagフィールドを管理する「Routing Metric/Constraint Common Header Flag field」サブレジストリを作成しました。
Several bits are defined for the Routing Metric/Constraint common header Flag field in this document. The following values have been assigned:
本書ではRouting Metric/Constraint共通ヘッダーのFlagフィールドに複数のビットを定義しています。次の値が割り当てられています。
Codespace of the Flag field (Routing Metric/Constraint common header)
Flagフィールドのコード空間（Routing Metric/Constraint共通ヘッダー）
Bit Description Reference
8 Recorded/Aggregated This document
7 Optional Constraint This document
6 Constraint/Metric This document
5 P (Partial) This document
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はRouting Metric/Constraint共通ヘッダーのAフィールドのコード空間を管理するため、「Routing Metric/Constraint Common Header A field」サブレジストリを作成しました。
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
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ビットFlagsフィールドのコード空間を管理するため、「NSA Object Flag field」サブレジストリを作成しました。
Several bits are defined for the NSA Object Flag field in this document. The following values have been assigned:
本書ではNSA Object Flagフィールドの複数のビットを定義し、次の値を割り当てています。
Codespace of the Flag field (NSA object)
Flagフィールドのコード空間（NSAオブジェクト）
Bit Description Reference
6 Aggregator This document
7 Overloaded This document
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はHop Countオブジェクトの4ビットFlagsフィールドのコード空間を管理するため、「Hop-Count Object Flag field」サブレジストリを作成しました。
No Flag is currently defined.
現時点で定義されているFlagはありません。
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はRouting Metric/Constraint共通ヘッダーのNode Typeフィールドのコード空間を管理するため、「Node Type Field」サブレジストリを作成しました。
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フィールドのコード空間（Routing Metric/Constraint共通ヘッダー）
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
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実装に設けることが推奨されます (SHOULD)。
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]で規定された適切なセキュリティ対策を使うことが推奨されます (SHOULD)。
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.
この文書のレビューと有益なコメントを寄せた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、Jari Arkkoに感謝します。詳細なレビューを行ったAdrian Farrelにも特に感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[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., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, March 2012.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[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., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.
[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., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 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., and D. Barthel, "Routing Requirements for Urban Low-Power and Lossy Networks", RFC 5548, May 2009.
[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., and T. Phinney, "Industrial Routing Requirements in Low-Power and Lossy Networks", RFC 5673, October 2009.
[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., and G. Porcu, "Home Automation Routing Requirements in Low-Power and Lossy Networks", RFC 5826, April 2010.
[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., and W. Vermeylen, "Building Automation Routing Requirements in Low-Power and Lossy Networks", RFC 5867, June 2010.
[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., "Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL)", RFC 6552, March 2012.
[ROLL-TERMS] Vasseur, JP., "Terminology in Low power And Lossy Networks", Work in Progress, September 2011.
[ROLL-TERMS] Vasseur, JP., "Terminology in Low power And Lossy Networks", Work in Progress, September 2011.
[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., and A. Khanna, "Performance of the Revised Routing Metric for ARPANET and MILNET", Military Communications Conference, MILCOM '89, March 1989.
Authors' Addresses
著者の連絡先
JP. Vasseur (editor) Cisco Systems 11, Rue Camille Desmoulins Issy Les Moulineaux 92782 France
JP. Vasseur (editor) 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 (editor) Corporate Technology Group, KT 17 Woomyeon-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
Nicolas Dejean Elster SAS Espace Concorde, 120 impasse JB Say Perols 34470 France
EMail: nicolas.dejean@coronis.com
Dominique Barthel France Telecom Orange 28 chemin du Vieux Chene, BP 98 Meylan 38243 France
Dominique Barthel France Telecom Orange 28 chemin du Vieux Chene, BP 98 Meylan 38243 France
EMail: dominique.barthel@orange.com