RFC 6998 - A Mechanism to Measure the Routing Metrics along a Point-to-Point Route in a Low-Power and Lossy Network 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc6998
タイトル : RFC 6998 - 低電力で損失の多いネットワークでポイントツーポイントルートに沿ってルーティングメトリックを測定するメカニズム
翻訳編集 : 自動生成

[要約] RFC 6998は、低消費電力かつ損失の多いネットワーク内のポイントツーポイントルートのルーティングメトリックを測定するためのメカニズムを提案しています。このRFCの目的は、ネットワーク内の通信経路の品質を評価し、最適なルーティングを実現することです。

Internet Engineering Task Force (IETF)                     M. Goyal, Ed.
Request for Comments: 6998                  Univ. of Wisconsin Milwaukee
Category: Experimental                                       E. Baccelli
ISSN: 2070-1721                                                    INRIA
                                                               A. Brandt
                                                           Sigma Designs
                                                             J. Martocci
                                                        Johnson Controls
                                                             August 2013

A Mechanism to Measure the Routing Metrics along a Point-to-Point Route in a Low-Power and Lossy Network

低電力で損失の多いネットワークでポイントツーポイントルートに沿ってルーティングメトリックを測定するメカニズム

Abstract

概要

This document specifies a mechanism that enables a Routing Protocol for Low-power and Lossy Networks (RPL) router to measure the aggregated values of given routing metrics along an existing route towards another RPL router, thereby allowing the router to decide if it wants to initiate the discovery of a better route.

このドキュメントでは、低電力および損失の多いネットワーク（RPL）ルーターのルーティングプロトコルが別のRPLルーターへの既存のルートに沿って所定のルーティングメトリックの集計値を測定できるようにするメカニズムを指定します。これにより、ルーターは開始するかどうかを決定できますより良いルートの発見。

Status of This Memo

本文書の状態

This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.

このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。

This document defines an Experimental Protocol for the Internet community. 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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

このドキュメントでは、インターネットコミュニティの試験運用プロトコルを定義しています。このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 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/rfc6998.

このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6998で入手できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1. Introduction ....................................................4
      1.1. Terminology ................................................5
   2. Overview ........................................................6
   3. The Measurement Object (MO) .....................................7
      3.1. Format of the Base MO ......................................8
      3.2. Secure MO .................................................12
   4. Originating a Measurement Request ..............................13
      4.1. When Measuring a Hop-by-Hop Route with a Global
           RPLInstanceID .............................................14
      4.2. When Measuring a Hop-by-Hop Route with a Local
           RPLInstanceID with Route Accumulation Off .................15
      4.3. When Measuring a Hop-by-Hop Route with a Local
           RPLInstanceID with Route Accumulation On ..................16
      4.4. When Measuring a Source Route .............................17
   5. Processing a Measurement Request at an Intermediate Point ......19
      5.1. When Measuring a Hop-by-Hop Route with a Global
           RPLInstanceID .............................................19
      5.2. When Measuring a Hop-by-Hop Route with a Local
           RPLInstanceID with Route Accumulation Off .................21
      5.3. When Measuring a Hop-by-Hop Route with a Local
           RPLInstanceID with Route Accumulation On ..................21
      5.4. When Measuring a Source Route .............................22
      5.5. Final Processing ..........................................23
   6. Processing a Measurement Request at the End Point ..............23
      6.1. Generating the Measurement Reply ..........................24
   7. Processing a Measurement Reply at the Start Point ..............25
   8. Security Considerations ........................................25
   9. IANA Considerations ............................................27
   10. Acknowledgements ..............................................27
   11. References ....................................................28
      11.1. Normative References .....................................28
      11.2. Informative References ...................................28

1. Introduction

1. はじめに

Point-to-point (P2P) communication between arbitrary routers in a Low-power and Lossy Network (LLN) is a key requirement for many home and commercial building automation applications [RFC5826] [RFC5867]. The IPv6 Routing Protocol for LLNs (RPL) [RFC6550] constrains the LLN topology to a Directed Acyclic Graph (DAG) built to optimize the routing costs to reach the DAG's root. The P2P routing functionality, available under RPL, has the following key limitations:

低電力および損失の多いネットワーク（LLN）内の任意のルーター間のポイントツーポイント（P2P）通信は、多くの家庭用および商用ビルオートメーションアプリケーション[RFC5826] [RFC5867]の主要な要件です。 LLNのIPv6ルーティングプロトコル（RPL）[RFC6550]は、LLNトポロジを、DAGのルートに到達するためのルーティングコストを最適化するために構築された有向非巡回グラフ（DAG）に制限します。 RPLで利用可能なP2Pルーティング機能には、次の重要な制限があります。

o The P2P routes are restricted to use the DAG links only. Such P2P routes may potentially be suboptimal and may lead to traffic congestion near the DAG root.

o P2Pルートは、DAGリンクのみを使用するように制限されています。このようなP2Pルートは最適ではない可能性があり、DAGルートの近くでトラフィックの輻輳を引き起こす可能性があります。

o RPL is a proactive routing protocol and hence requires that all P2P routes be established ahead of the time they are used. Many LLN applications require the ability to establish P2P routes "on demand".

o RPLはプロアクティブルーティングプロトコルであるため、すべてのP2Pルートが使用される前に確立する必要があります。多くのLLNアプリケーションは、「オンデマンド」でP2Pルートを確立する機能を必要とします。

To ameliorate situations where the core RPL's P2P routing functionality does not meet an application's requirements, [RFC6997] describes P2P-RPL, an extension to core RPL. P2P-RPL provides a reactive mechanism to discover P2P routes that meet the specified routing constraints [RFC6551]. In some cases, the application's requirements or the LLN's topological features allow a router to infer these routing constraints implicitly. For example, the application may require that the end-to-end loss rate and/or latency along the route be below certain thresholds, or the LLN topology may be such that a router can safely assume that its destination is less than a certain number of hops away from itself.

コアRPLのP2Pルーティング機能がアプリケーションの要件を満たさない状況を改善するために、[RFC6997]はコアRPLの拡張であるP2P-RPLについて説明しています。 P2P-RPLは、指定されたルーティング制約[RFC6551]を満たすP2Pルートを発見するための反応メカニズムを提供します。場合によっては、アプリケーションの要件またはLLNのトポロジ機能により、ルーターがこれらのルーティング制約を暗黙的に推測できます。たとえば、アプリケーションでは、ルートに沿ったエンドツーエンドの損失率や遅延が特定のしきい値を下回っている必要がある場合や、LLNトポロジが、ルーターが宛先を特定の数よりも少ないと安全に想定できる場合があります。それ自体からホップの。

When the existing routes are deemed unsatisfactory but the router does not implicitly know the routing constraints to be used in P2P-RPL route discovery, it may be necessary for the router to measure the aggregated values of the routing metrics along the existing route. This knowledge will allow the router to frame reasonable routing constraints to discover a better route using P2P-RPL. For example, if the router determines the aggregate ETX (expected transmission count) [RFC6551] along an existing route to be "x", it can use "ETX < x*y", where y is a certain fraction, as the routing constraint for use in P2P-RPL route discovery. Note that it is important that the routing constraints not be overly strict; otherwise, the P2P-RPL route discovery may fail even though a route exists that is much better than the one currently being used.

既存のルートが不十分であると見なされても、ルーターがP2P-RPLルート検出で使用されるルーティング制約を暗黙的に認識していない場合、ルーターが既存のルートに沿ったルーティングメトリックの集約値を測定する必要がある場合があります。この知識により、ルータは適切なルーティング制約をフレーム化して、P2P-RPLを使用してより適切なルートを発見できます。たとえば、ルーターが既存のルートに沿った集約ETX（予想送信数）[RFC6551]を「x」であると決定した場合、ルーティング制約として、「ETX <x * y」を使用できます。 P2P-RPLルートディスカバリで使用するため。ルーティングの制約が厳しすぎないようにすることが重要です。そうでない場合、現在使用されているルートよりもはるかに優れたルートが存在していても、P2P-RPLルートの検出が失敗する可能性があります。

This document specifies a mechanism that enables a RPL router to measure the aggregated values of the routing metrics along an existing route to another RPL router in an LLN, thereby allowing the router to decide if it wants to discover a better route using P2P-RPL and determine the routing constraints to be used for this purpose. Thus, the utility of this mechanism is dependent on the existence of P2P-RPL [RFC6997]. The hope is that experiments with P2P-RPL and the mechanism defined in this document will result in feedback on the utility and benefits of this document, so that a Standards Track version of this document can then be developed.

このドキュメントでは、RPLルーターがLLN内の別のRPLルーターへの既存のルートに沿ってルーティングメトリックの集約値を測定できるようにするメカニズムを指定します。これにより、ルーターはP2P-RPLこの目的で使用するルーティング制約を決定します。したがって、このメカニズムの有用性は、P2P-RPL [RFC6997]の存在に依存しています。 P2P-RPLとこのドキュメントで定義されているメカニズムを使用した実験により、このドキュメントの有用性と利点に関するフィードバックが得られ、このドキュメントのStandards Trackバージョンを開発できることが期待されます。

1.1. Terminology

1.1. 用語

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこの文書の "は、[RFC2119]で説明されているように解釈されます。

Additionally, this document uses terminology from [RFC6550], [RFC6554], and [RFC6997]. Further terminology may be found in [ROLL-TERMS]. This document defines the following terms:

さらに、このドキュメントでは、[RFC6550]、[RFC6554]、および[RFC6997]の用語を使用しています。 [ROLL-TERMS]でさらに用語が見つかる場合があります。このドキュメントでは、次の用語を定義しています。

Start Point: The RPL router that initiates the measurement process defined in this document and that is the start point of the P2P route being measured.

開始点：このドキュメントで定義されている測定プロセスを開始し、測定されるP2Pルートの開始点であるRPLルーター。

End Point: The RPL router at the end point of the P2P route being measured.

エンドポイント：測定対象のP2PルートのエンドポイントにあるRPLルーター。

Intermediate Point: A RPL router, other than the Start Point and the End Point, on the P2P route being measured.

中間ポイント：測定対象のP2Pルート上の、開始ポイントと終了ポイント以外のRPLルーター。

The following terms, as already defined in [RFC6997], are redefined in this document in the following manner:

[RFC6997]ですでに定義されている次の用語は、このドキュメントでは次のように再定義されています。

Forward direction: The direction from the Start Point to the End Point.

順方向：開始点から終了点への方向。

Reverse direction: The direction from the End Point to the Start Point.

逆方向：終点から始点への方向。

2. Overview

2. 概観

The mechanism described in this document can be used by a Start Point in an LLN to measure the aggregated values of selected routing metrics along a P2P route to an End Point within the LLN. The route is measured in the Forward direction. Such a route could be a Source Route or a Hop-by-hop Route established using RPL [RFC6550] or P2P-RPL [RFC6997]. Such a route could also be a "mixed" route, with the initial part consisting of hop-by-hop ascent to the root of a non-storing DAG [RFC6550] and the final part consisting of a source-routed descent to the End Point. The Start Point decides what metrics to measure and sends a Measurement Request message, carrying the desired routing metric objects, along the route. If a Source Route is being measured, the Measurement Request carries the route inside an Address vector. If a Hop-by-hop Route is being measured, the Measurement Request identifies the route by its RPLInstanceID [RFC6550] (and, if the RPLInstanceID is a local value, the Start Point's IPv6 address associated with the route). On receiving a Measurement Request, an Intermediate Point updates the routing metric values inside the message and forwards it to the next hop on the route. Thus, the Measurement Request accumulates the values of the routing metrics for the complete route as it travels towards the End Point. Upon receiving the Measurement Request, the End Point unicasts a Measurement Reply message, carrying the accumulated values of the routing metrics, back to the Start Point. Optionally, the Start Point may allow an Intermediate Point to generate the Measurement Reply if the Intermediate Point already knows the relevant routing metric values along the rest of the route.

このドキュメントで説明されているメカニズムをLLNのスタートポイントで使用して、LLN内のエンドポイントへのP2Pルートに沿って選択されたルーティングメトリックの集約値を測定できます。ルートは順方向で測定されます。そのようなルートは、RPL [RFC6550]またはP2P-RPL [RFC6997]を使用して確立されたソースルートまたはホップバイホップルートである可能性があります。このようなルートは、「混合」ルートにすることもできます。最初の部分は、非保存DAG [RFC6550]のルートへのホップバイホップの上昇で構成され、最後の部分は、ソースルートでの最後への降下で構成されます。ポイント。スタートポイントは、測定するメトリックを決定し、ルートに沿って目的のルーティングメトリックオブジェクトを含むMeasurement Requestメッセージを送信します。ソースルートが測定されている場合、測定リクエストはアドレスベクタ内のルートを伝送します。ホップバイホップルートが測定されている場合、Measurement RequestはそのRPLInstanceID [RFC6550]によってルートを識別します（RPLInstanceIDがローカル値の場合、ルートに関連付けられているスタートポイントのIPv6アドレス）。中間ポイントは、測定要求を受信すると、メッセージ内のルーティングメトリック値を更新し、ルート上の次のホップに転送します。したがって、Measurement Requestは、エンドポイントに向かうルート全体のルーティングメトリックの値を蓄積します。測定要求を受信すると、エンドポイントは測定応答メッセージをユニキャストして、ルーティングメトリックの累積値を送信し、スタートポイントに戻します。オプションで、中間ポイントがルートの残りに沿って関連するルーティングメトリック値をすでに知っている場合、開始ポイントは中間ポイントが測定応答を生成することを許可する場合があります。

The Measurement Request may include an Address vector that serves one of the following functions:

測定要求には、次の機能のいずれかを提供するアドレスベクタが含まれる場合があります。

o To accumulate a Source Route for the End Point's use: If a Hop-by-hop Route with a local RPLInstanceID is being measured, the Start Point may require that each Intermediate Point add its global or unique-local IPv6 address to an Address vector inside the Measurement Request. The Source Route, thus accumulated, can be used by the End Point to reach the Start Point. In particular, the End Point may use the accumulated Source Route to send the Measurement Reply back to the Start Point. In this case, the Start Point includes a suitably sized Address vector in the Measurement Request. The size of the Address vector puts a hard limit on the length of the accumulated route. An Intermediate Point is not allowed to modify the size of the Address vector and must discard a received Measurement Request if the Address vector is not large enough to contain the complete route.

o エンドポイントで使用するためのソースルートを蓄積するには：ローカルRPLInstanceIDを使用したホップバイホップルートが測定されている場合、スタートポイントは、各中間ポイントがグローバルまたは一意のローカルIPv6アドレスを内部のアドレスベクトルに追加することを要求する場合があります。測定リクエスト。このようにして蓄積されたソースルートは、エンドポイントがスタートポイントに到達するために使用できます。特に、エンドポイントは、蓄積されたソースルートを使用して、測定応答をスタートポイントに送り返すことができます。この場合、スタートポイントには、適切なサイズのアドレスベクタが測定リクエストに含まれています。アドレスベクタのサイズにより、累積ルートの長さが厳しく制限されます。中間ポイントは、アドレスベクタのサイズを変更することはできません。また、アドレスベクタがルート全体を含めるのに十分な大きさでない場合は、受信した測定リクエストを破棄する必要があります。

o To carry the Source Route being measured: The Start Point may insert an Address vector inside the Measurement Request to carry the Source Route being measured. Also, the root of a global non-storing DAG may insert an Address vector, carrying a Source Route from itself to the End Point, inside a Measurement Request message if this message had been traveling along this DAG so far. This Source Route must consist of global or unique-local IPv6 addresses. An Intermediate Point is not allowed to modify an existing Address vector before forwarding the Measurement Request further. In other words, an Intermediate Point must not modify the Source Route along which the Measurement Request is currently traveling.

o 測定中のソースルートを伝送するには、スタートポイントは測定リクエスト内にアドレスベクトルを挿入して、測定中のソースルートを伝送します。また、このメッセージがこのDAGに沿って移動している場合、グローバルな非保存DAGのルートは、測定要求メッセージ内にソースルートを自身からエンドポイントに運ぶアドレスベクタを挿入する場合があります。このソースルートは、グローバルまたは一意のローカルIPv6アドレスで構成する必要があります。中間ポイントは、測定要求をさらに転送する前に既存のアドレスベクタを変更できません。言い換えると、中間ポイントは、測定要求が現在移動しているソースルートを変更してはなりません。

3. The Measurement Object (MO)

3. 測定オブジェクト（MO）

This document defines two new RPL control message types: the Measurement Object (MO), with code 0x06; and the Secure MO, with code 0x86. An MO serves as both Measurement Request and Measurement Reply.

このドキュメントでは、2つの新しいRPL制御メッセージタイプを定義しています。コード0x06のMeasurement Object（MO）です。セキュアMO、コード0x86。 MOは測定要求と測定応答の両方として機能します。

3.1. Format of the Base MO

3.1. ベースMOのフォーマット

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | RPLInstanceID | Compr |T|H|A|R|B|I|   SeqNo   |  Num  | Index |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                       Start Point Address                     .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                       End Point Address                       .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                       Address[0..Num-1]                       .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                   Metric Container Option(s)                  .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1: Format of the Base Measurement Object (MO)

図1：ベース測定オブジェクト（MO）のフォーマット

The format of a base MO is shown in Figure 1. A base MO consists of the following fields:

ベースMOのフォーマットを図1に示します。ベースMOは次のフィールドで構成されています。

o RPLInstanceID: This field specifies the RPLInstanceID of the Hop-by-hop Route along which the Measurement Request travels (or traveled initially until it switched over to a Source Route).

o RPLInstanceID：このフィールドは、測定要求が移動する（またはソースルートに切り替わるまで最初に移動する）ホップバイホップルートのRPLInstanceIDを指定します。

o Compr: In many LLN deployments, IPv6 addresses share a well-known, common prefix. In such cases, the common prefix can be elided when specifying IPv6 addresses in the Start Point/End Point Address fields and the Address vector. The "Compr" field, a 4-bit unsigned integer, is set by the Start Point to specify the number of prefix octets that are elided from the IPv6 addresses in Start Point/End Point Address fields and the Address vector. The Start Point will set the Compr value to zero if full IPv6 addresses are to be carried in the Start Point Address/End Point Address fields and the Address vector.

o Compr：多くのLLN展開では、IPv6アドレスはよく知られている共通のプレフィックスを共有します。このような場合、開始ポイント/終了ポイントアドレスフィールドとアドレスベクタでIPv6アドレスを指定するときに、共通のプレフィックスを省略できます。「Compr」フィールドは4ビットの符号なし整数で、開始点によって設定され、開始点/終了点のアドレスフィールドとアドレスベクトルのIPv6アドレスから除外されるプレフィックスオクテットの数を指定します。開始ポイントは、完全なIPv6アドレスが[開始ポイントアドレス] / [終了ポイントアドレス]フィールドとアドレスベクタで運ばれる場合、Compr値をゼロに設定します。

o Type (T): This flag is set to one if the MO represents a Measurement Request. The flag is set to zero if the MO is a Measurement Reply.

o タイプ（T）：MOが測定要求を表す場合、このフラグは1に設定されます。 MOが測定応答の場合、フラグはゼロに設定されます。

o Hop-by-hop (H): The Start Point MUST set this flag to one if (at least the initial part of) the route being measured is hop by hop. In that case, the Hop-by-hop Route is identified by the RPLInstanceID, the End Point Address, and, if the RPLInstanceID is a local value, the Start Point Address fields inside the Measurement Request. Here, the Start Point Address field is required to be the same as the DODAGID (the identifier of the Destination-Oriented DAG (DODAG) root) [RFC6550] of the route being measured. The Start Point MUST set the H flag to zero if the route being measured is a Source Route specified in the Address vector. An Intermediate Point MUST set the H flag in an outgoing Measurement Request to the same value that it had in the corresponding incoming Measurement Request, except under the following circumstance: If the Intermediate Point is the root of the non-storing global DAG along which the Measurement Request had been traveling so far and it intends to insert a Source Route inside the Address vector to direct the Measurement Request towards the End Point, then it MUST set the H flag to zero.

o ホップバイホップ（H）：測定対象のルートが（少なくとも最初の部分で）ホップバイホップである場合、開始ポイントはこのフラグを1に設定する必要があります。その場合、ホップバイホップルートは、RPLInstanceID、エンドポイントアドレス、およびRPLInstanceIDがローカル値の場合、測定リクエスト内のスタートポイントアドレスフィールドによって識別されます。ここで、開始ポイントアドレスフィールドは、測定されるルートのDODAGID（宛先指向DAG（DODAG）ルートの識別子）[RFC6550]と同じである必要があります。測定されるルートがアドレスベクトルで指定されたソースルートである場合、開始点はHフラグをゼロに設定する必要があります。中間ポイントは、次の状況を除いて、送信測定リクエストのHフラグを対応する受信測定リクエストのHフラグと同じ値に設定する必要があります：中間ポイントが非保存グローバルDAGのルートである場合、 Measurement Requestはこれまでに移動しており、エンドポイントに向けてMeasurement Requestを送信するためにアドレスベクトル内にソースルートを挿入するつもりである場合、Hフラグをゼロに設定する必要があります。

o Accumulate Route (A): A value of 1 in this flag indicates that the Measurement Request is accumulating a Source Route for use by the End Point to send the Measurement Reply back to the Start Point. Route accumulation MUST NOT be used (i.e., this flag MUST NOT be set to one) inside a Measurement Request, unless it travels along a Hop-by-hop Route represented by a local RPLInstanceID (i.e., H = 1 and RPLInstanceID has a local value). Route accumulation MAY be used (i.e., this flag MAY be set to one) if the Measurement Request is traveling along a Hop-by-hop Route with a local RPLInstanceID. In this case, if the route accumulation is on, an Intermediate Point adds its unicast global/unique-local IPv6 address (after eliding Compr number of prefix octets) to the Address vector in the manner specified in Section 5.3. In other cases, this flag MUST be set to zero on transmission and ignored on reception. Route accumulation is not allowed when the Measurement Request travels along a Hop-by-hop Route with a global RPLInstanceID, i.e., along a global DAG, because:

o ルートの累積（A）：このフラグの値が1の場合、測定要求がソースルートを累積して、エンドポイントが測定応答を開始ポイントに送り返すために使用します。ローカルRPLInstanceIDで表されるホップバイホップルートに沿って移動しない限り（つまり、H = 1で、RPLInstanceIDにローカル値）。ローカルRPLInstanceIDを使用してホップバイホップルートに沿って測定リクエストが移動している場合は、ルートの累積を使用できます（つまり、このフラグを1に設定できます）。この場合、ルートの累積がオンの場合、中間ポイントは、ユニキャストグローバル/ユニークローカルIPv6アドレス（接頭辞オクテットのCompr番号を削除した後）を、セクション5.3で指定された方法でアドレスベクトルに追加します。他の場合では、このフラグは送信時にゼロに設定されなければならず、受信時に無視されなければなりません。次の理由により、測定リクエストがグローバルRPLInstanceIDを持つホップバイホップルートに沿って、つまりグローバルDAGに沿って移動する場合、ルートの累積は許可されません。

* The DAG's root may need the Address vector to insert a Source Route to the End Point; and

* DAGのルートには、エンドポイントへのソースルートを挿入するためのアドレスベクタが必要な場合があります。そして

* The End Point can presumably reach the Start Point along this global DAG (identified by the RPLInstanceID field).

* エンドポイントは、おそらくこのグローバルDAG（RPLInstanceIDフィールドで識別）に沿ってスタートポイントに到達できます。

o Reverse (R): A value of 1 in this flag inside a Measurement Request indicates that the Address vector contains a complete Source Route from the Start Point to the End Point, which can be used, after reversal, by the End Point to send the Measurement Reply back to the Start Point. This flag MAY be set to one inside a Measurement Request only if a Source Route, from the Start Point to the End Point, is being measured. Otherwise, this flag MUST be set to zero on transmission and ignored on reception.

o リバース（R）：測定リクエスト内のこのフラグの値1は、アドレスベクトルに開始ポイントから終了ポイントまでの完全なソースルートが含まれていることを示します。これは、反転後にエンドポイントで使用して、測定開始点に返信します。このフラグは、始点から終点までのソースルートが測定されている場合にのみ、測定リクエスト内で1に設定できます。それ以外の場合、このフラグは送信時にゼロに設定し、受信時には無視する必要があります。

o Back Request (B): A value of 1 in this flag serves as a request to the End Point to send a Measurement Request towards the Start Point. On receiving a Measurement Request with the B flag set to one, the End Point SHOULD generate a Measurement Request to measure the cost of its current (or the most preferred) route to the Start Point. Receipt of this Measurement Request would allow the Start Point to know the cost of the back route from the End Point to itself and thus determine the round-trip cost of reaching the End Point.

o バックリクエスト（B）：このフラグの値が1の場合、エンドポイントがスタートポイントに向けて測定リクエストを送信するためのリクエストとして機能します。エンドポイントは、Bフラグが1に設定された測定リクエストを受信すると、測定リクエストを生成して、スタートポイントへの現在の（または最も好ましい）ルートのコストを測定する必要があります（SHOULD）。この測定要求を受信すると、開始ポイントは、終了ポイントからそれ自体へのバックルートのコストを認識できるため、終了ポイントに到達するための往復コストを決定できます。

o Intermediate Reply (I): A value of 1 in this flag serves as permission to an Intermediate Point to generate a Measurement Reply if it knows the aggregated values of the routing metrics being measured for the rest of the route. Setting this flag to one may be useful in scenarios where the Hop Count [RFC6551] is the routing metric of interest and an Intermediate Point (e.g., the root of a non-storing global DAG or a common ancestor of the Start Point and the End Point in a storing global DAG) may know the Hop Count of the remainder of the route to the End Point. This flag MAY be set to one only if a Hop-by-hop Route with a global RPLInstanceID is being measured (i.e., H = 1 and RPLInstanceID has a global value). Otherwise, this flag MUST be set to zero on transmission and ignored on reception.

o 中間応答（I）：このフラグの値が1の場合、ルートの残りの部分で測定されているルーティングメトリックの集計値がわかっている場合、中間ポイントが測定応答を生成するための許可として機能します。このフラグを1に設定すると、ホップカウント[RFC6551]が目的のルーティングメトリックであり、中間ポイント（たとえば、非保存グローバルDAGのルートまたは開始ポイントと終了の共通の祖先）であるシナリオで役立つ場合があります。格納グローバルDAG内のポイント）は、エンドポイントへのルートの残りのホップカウントを知っている場合があります。このフラグは、グローバルRPLInstanceIDを持つホップバイホップルートが測定されている場合（つまり、H = 1であり、RPLInstanceIDがグローバル値を持つ場合）にのみ1に設定できます（MAY）。それ以外の場合、このフラグは送信時にゼロに設定し、受信時には無視する必要があります。

o SeqNo: This is a 6-bit sequence number, assigned by the Start Point, that allows the Start Point to uniquely identify a Measurement Request and the corresponding Measurement Reply.

o SeqNo：これは、開始ポイントによって割り当てられる6ビットのシーケンス番号であり、これにより、開始ポイントは測定要求と対応する測定応答を一意に識別できます。

o Num: This field indicates the number of elements, each (16 - Compr) octets in size, inside the Address vector. If the value of this field is zero, the Address vector is not present in the MO.

o Num：このフィールドは、アドレスベクトル内の各要素のサイズ（16-Compr）のオクテット数を示します。このフィールドの値がゼロの場合、アドレスベクタはMOに存在しません。

o Index: If the Measurement Request is traveling along a Source Route contained in the Address vector (i.e., H = 0), this field indicates the index in the Address vector of the next hop on the route. If the Measurement Request is traveling along a Hop-by-hop Route with a local RPLInstanceID and the route accumulation is on (i.e., H = 1, RPLInstanceID has a local value, and A = 1), this field indicates the index in the Address vector where an Intermediate Point receiving the Measurement Request must store its IPv6 address. Otherwise, this field MUST be set to zero on transmission and ignored on reception.

oインデックス：測定要求がアドレスベクトルに含まれるソースルート（つまり、H = 0）に沿って移動している場合、このフィールドはルートの次のホップのアドレスベクトルのインデックスを示します。 Measurement RequestがローカルRPLInstanceIDを持つホップバイホップルートに沿って移動し、ルートの累積がオンの場合（つまり、H = 1、RPLInstanceIDはローカル値、A = 1）、このフィールドはインデックスを示します測定要求を受信する中間ポイントがそのIPv6アドレスを格納する必要があるアドレスベクトル。それ以外の場合、このフィールドは送信時にゼロに設定し、受信時には無視する必要があります。

o Start Point Address: This is a unicast global or unique-local IPv6 address of the Start Point after eliding Compr number of prefix octets. If the Measurement Request is traveling along a Hop-by-hop Route and the RPLInstanceID field indicates a local value, the Start Point Address field MUST specify the DODAGID value that, along with the RPLInstanceID and the End Point Address, uniquely identifies the Hop-by-hop Route being measured.

o 開始点アドレス：これは、接頭辞オクテットのCompr数を省略した後の開始点のユニキャストグローバルまたは一意ローカルIPv6アドレスです。 Measurement Requestがホップバイホップルートに沿って移動し、RPLInstanceIDフィールドがローカル値を示している場合、開始点アドレスフィールドは、RPLInstanceIDおよび終了点アドレスとともに、ホップを一意に識別するDODAGID値を指定する必要があります。測定中のホップバイルート。

o End Point Address: This is a unicast global or unique-local IPv6 address of the End Point after eliding Compr number of prefix octets.

o エンドポイントアドレス：これは、プレフィックスオクテットのCompr番号を省略した後のエンドポイントのユニキャストグローバルまたはユニークローカルIPv6アドレスです。

o Address[0..Num-1]: This field is a vector of unicast global or unique-local IPv6 addresses (with Compr number of prefix octets elided) representing a Source Route:

o Address [0..Num-1]：このフィールドは、ソースルートを表すユニキャストグローバルまたは一意ローカルIPv6アドレス（プレフィックスオクテットのCompr番号が省略されている）のベクトルです。

* Each element in the vector has size (16 - Compr) octets.

* ベクトルの各要素には、サイズ（16-Compr）オクテットがあります。

* The total number of elements inside the Address vector is given by the Num field.

* Addressベクトル内の要素の総数は、Numフィールドで指定されます。

* The Start Point and End Point addresses MUST NOT be included in the Address vector.

* 開始点と終了点のアドレスは、アドレスベクタに含めることはできません。

* The Address vector MUST NOT contain any multicast addresses.

* アドレスベクトルには、マルチキャストアドレスを含めてはなりません。

* If the Start Point wants to measure a Hop-by-hop Route with a local RPLInstanceID and accumulate a Source Route for the End Point's use (i.e., the Measurement Request has the H flag set to one, RPLInstanceID set to a local value, and the A flag set to one), it MUST include a suitably sized Address vector in the Measurement Request. As the Measurement Request travels over the route being measured, the Address vector accumulates a Source Route that can be used by the End Point, after reversal, to reach (and, in particular, to send the Measurement Reply back to) the Start Point. The route MUST be accumulated in the Forward direction, but the IPv6 addresses in the accumulated route MUST be reachable in the Reverse direction. An Intermediate Point MUST add only a global or unique-local IPv6 address to the Address vector and MUST NOT modify the size of the Address vector.

* スタートポイントがローカルRPLInstanceIDでホップバイホップルートを測定し、エンドポイントで使用するためにソースルートを累積する場合（つまり、測定リクエストでHフラグを1に設定し、RPLInstanceIDをローカル値に設定し、 1に設定されたAフラグ）、適切なサイズのアドレスベクタを測定リクエストに含める必要があります。測定リクエストが測定中のルートを移動するとき、アドレスベクトルは、反転後、開始ポイントに到達する（特に測定応答を送信する）ために、エンドポイントで使用できるソースルートを蓄積します。ルートは順方向に蓄積する必要がありますが、蓄積されたルートのIPv6アドレスは逆方向に到達可能でなければなりません（MUST）。中間ポイントは、アドレスベクトルにグローバルまたは一意のローカルIPv6アドレスのみを追加する必要があり、アドレスベクトルのサイズを変更してはなりません。

* If the Start Point wants to measure a Source Route, it MUST include an Address vector, containing the route being measured, inside the Measurement Request. Similarly, if the Measurement Request had been traveling along a global non-storing DAG so far, the root of this DAG may insert an Address vector, containing a Source Route from itself to the End Point, inside the Measurement Request. In both cases, the Source Route inside the Address vector MUST consist only of global or unique-local IPv6 addresses that are reachable in the Forward direction. Further, in both cases, an Intermediate Point MUST NOT modify the contents of the existing Address vector before forwarding the Measurement Request further. In other words, an Intermediate Point MUST NOT modify the Source Route along which the Measurement Request is currently traveling. The Start Point MAY set the R flag in the Measurement Request to one if the Source Route inside the Address vector can be used by the End Point, after reversal, to reach (and, in particular, to send the Measurement Reply back to) the Start Point. In other words, the Start Point MAY set the R flag to one only if all the IPv6 addresses in the Address vector are reachable in the Reverse direction.

* スタートポイントがソースルートを測定する場合、測定リクエスト内に、測定されるルートを含むアドレスベクトルを含める必要があります。同様に、これまでに測定リクエストがグローバルな非保存DAGに沿って移動していた場合、このDAGのルートは、それ自体からエンドポイントへのソースルートを含むアドレスベクトルを測定リクエスト内に挿入する場合があります。どちらの場合も、アドレスベクトル内のソースルートは、順方向に到達可能なグローバルまたは一意のローカルIPv6アドレスのみで構成されている必要があります。さらに、どちらの場合も、中間ポイントは、測定要求をさらに転送する前に、既存のアドレスベクトルの内容を変更してはなりません。言い換えると、中間ポイントは、測定要求が現在移動しているソースルートを変更してはなりません。開始ポイントは、アドレスベクタ内のソースルートが終了後に到達後に到達する（特に、測定応答を送信する）ために終了ポイントで使用できる場合、測定要求のRフラグを1に設定できます（MAY）。出発地点。言い換えると、アドレスベクタのすべてのIPv6アドレスが逆方向に到達可能な場合にのみ、開始点がRフラグを1に設定してもよい（MAY）。

o Metric Container Options: A Measurement Request MUST contain one or more Metric Container options [RFC6550] to accumulate the values of the selected routing metrics in the manner described in [RFC6551] for the route being measured.

o メトリックコンテナオプション：測定リクエストには、1つ以上のメトリックコンテナオプション[RFC6550]を含めて、[RFC6551]で説明されている方法で、選択されたルーティングメトリックの値を、測定対象のルートについて蓄積する必要があります。

Section 4 describes how a Start Point sets various fields inside a Measurement Request in different cases. Section 5 describes how an Intermediate Point processes a received Measurement Request before forwarding it further. Section 6 describes how the End Point processes a received Measurement Request and generates a Measurement Reply. Finally, Section 7 describes how the Start Point processes a received Measurement Reply. In the following discussion, any reference to discarding a received Measurement Request/Reply with "no further processing" does not preclude updating the appropriate error counters or any similar actions.

セクション4では、開始点がさまざまなケースで測定リクエスト内のさまざまなフィールドを設定する方法について説明します。セクション5では、中間ポイントが受信した測定要求を処理してから、それをさらに転送する方法について説明します。セクション6では、エンドポイントが受信した測定要求を処理し、測定応答を生成する方法について説明します。最後に、セクション7では、開始ポイントが受信した測定応答をどのように処理するかについて説明します。以下の説明では、「それ以上の処理なし」で受信した測定要求/応答を破棄することへの言及は、適切なエラーカウンタまたは同様のアクションの更新を妨げるものではありません。

3.2. Secure MO

3.2. せくれも

A Secure MO follows the format shown in Figure 7 of [RFC6550], where the base format is the base MO shown in Figure 1. Sections 6.1, 10, and 19 of [RFC6550] describe the RPL security framework. These sections are applicable to the use of Secure MO messages as well, except as constrained in this section. An LLN deployment MUST support the use of Secure MO messages so that it has the ability to invoke RPL-provided security mechanisms and prevent misuse of the measurement mechanism by unauthorized routers.

セキュアMOは、[RFC6550]の図7に示すフォーマットに従います。基本フォーマットは、図1に示すベースMOです。[RFC6550]のセクション6.1、10、および19は、RPLセキュリティフレームワークについて説明しています。これらのセクションは、このセクションで制限されている場合を除き、セキュアMOメッセージの使用にも適用されます。 LLN展開は、セキュアなMOメッセージの使用をサポートする必要があるため、RPLが提供するセキュリティメカニズムを呼び出し、不正なルーターによる測定メカニズムの誤用を防ぐことができます。

The Start Point determines whether Secure MO messages are to be used in a particular route measurement and, if yes, the Security Configuration (see definition in [RFC6997]) to be used for that purpose. The Start Point MUST NOT set the "Key Identifier Mode" field to a value of 1 inside this Security Configuration, since this setting indicates the use of a per-pair key, which is not suitable for securing the Measurement Request messages that travel over multiple hops. A router (an Intermediate Point or the End Point) participating in a particular route measurement

開始ポイントは、特定のルート測定でセキュアMOメッセージを使用するかどうかを決定し、使用する場合は、その目的で使用するセキュリティ構成（[RFC6997]の定義を参照）を決定します。この設定はペアごとのキーの使用を示すため、開始ポイントは「キー識別子モード」フィールドを値1に設定してはなりません。これは、ペアごとのキーの使用を示します。ホップ。特定のルート測定に参加しているルーター（中間ポイントまたはエンドポイント）

o MUST generate a Secure MO message (a Measurement Request or a Measurement Reply) if the received Measurement Request is a Secure MO. The Security Configuration used in generating a Secure MO message MUST be the same as the one used in the received message.

o 受信した測定要求がセキュアMOの場合、セキュアMOメッセージ（測定要求または測定応答）を生成する必要があります。セキュアMOメッセージの生成に使用されるセキュリティ構成は、受信メッセージで使用されるものと同じである必要があります。

o MUST NOT generate a Secure MO message if the received Measurement Request is not a Secure MO.

o 受信したMeasurement RequestがセキュアMOではない場合、セキュアMOメッセージを生成してはなりません（MUST NOT）。

A router MUST discard a received Measurement Request if it cannot follow the above-mentioned rules. If the Start Point sends a Measurement Request in a Secure MO message using a particular Security Configuration, it MUST discard the corresponding Measurement Reply it receives with no further processing, unless the Measurement Reply is received in a Secure MO message generated with the same Security Configuration as the one used in the Measurement Request.

ルーターは、上記のルールに従うことができない場合、受信したMeasurement Requestを破棄する必要があります。スタートポイントが特定のセキュリティ構成を使用してセキュアMOメッセージで測定要求を送信する場合、同じセキュリティ構成で生成されたセキュアMOメッセージで測定応答が受信されない限り、受信した対応する測定応答をそれ以上処理せずに破棄する必要があります。 Measurement Requestで使用されるものと同じです。

In the following discussion, any reference to an MO message is also applicable to a Secure MO message, unless noted otherwise.

以下の説明では、特に明記しない限り、MOメッセージへの言及はすべてセキュアMOメッセージにも適用されます。

4. Originating a Measurement Request

4. 測定要求の発信

A Start Point sets various fields inside the Measurement Request it generates in the manner described below. The Start Point MUST also include the routing metric objects [RFC6551] of interest inside one or more Metric Container options inside the Measurement Request. The Start Point then determines the next hop on the route being measured. If a Hop-by-hop Route is being measured (i.e., H = 1), the next hop is determined using the RPLInstanceID, the End Point Address, and, if RPLInstanceID is a local value, the Start Point Address fields in the Measurement Request. If a Source Route is being measured (i.e., H = 0), the Address[0] element inside the Measurement Request contains the next-hop address. The Start Point MUST ensure that

開始点は、以下で説明する方法で生成する測定リクエスト内のさまざまなフィールドを設定します。開始点には、Measurement Request内の1つ以上のメトリックコンテナオプション内に、対象のルーティングメトリックオブジェクト[RFC6551]も含める必要があります。次に、開始ポイントは、測定対象のルートの次のホップを決定します。ホップバイホップルートが測定されている場合（つまり、H = 1）、ネクストホップはRPLInstanceID、エンドポイントアドレスを使用して決定され、RPLInstanceIDがローカル値の場合、測定のスタートポイントアドレスフィールドリクエスト。ソースルートが測定されている場合（つまり、H = 0）、測定リクエスト内のAddress [0]要素にはネクストホップアドレスが含まれます。開始点は、

o the next-hop address is a unicast address, and

o ネクストホップアドレスはユニキャストアドレスであり、

o the next hop is on-link, and o the next hop is in the same RPL routing domain [RFC6554] as the Start Point,

oネクストホップがオンリンクであり、oネクストホップが開始点と同じRPLルーティングドメイン[RFC6554]にある、

failing which the Start Point MUST discard the Measurement Request without sending. Depending on the routing metrics, the Start Point must initiate the routing metric objects inside the Metric Container options by including the routing metric values for the first hop on the route being measured. Finally, the Start Point MUST unicast the Measurement Request to the next hop on the route being measured.

どの開始ポイントが失敗しても、送信せずに測定リクエストを破棄する必要があります。ルーティングメトリックに応じて、開始ポイントは、測定対象のルートの最初のホップのルーティングメトリック値を含めることにより、メトリックコンテナーオプション内でルーティングメトリックオブジェクトを開始する必要があります。最後に、開始点は、測定されているルート上の次のホップに測定要求をユニキャストしなければなりません（MUST）。

The Start Point MUST maintain state for a just-transmitted Measurement Request, for a lifetime duration that is large enough to allow the corresponding Measurement Reply to return. This state consists of the RPLInstanceID, the SeqNo, and the End Point Address fields of the Measurement Request. The lifetime duration for this state is locally determined by the Start Point and may be deployment specific. This state expires when the corresponding Measurement Reply is received or when the lifetime is over, whichever occurs first. Failure to receive the corresponding Measurement Reply before the expiry of a state may occur due to a number of reasons, including the unwillingness on the part of an Intermediate Point or the End Point to process the Measurement Request. The Start Point should take such possibilities into account when deciding whether to generate another Measurement Request for this route. The Start Point MUST discard a received Measurement Reply with no further processing if the state for the corresponding Measurement Request has already expired.

開始点は、送信されたばかりの測定要求の状態を、対応する測定応答が戻るのに十分な大きさの存続期間の間維持しなければなりません（MUST）。この状態は、測定要求のRPLInstanceID、SeqNo、およびEnd Point Addressフィールドで構成されています。この状態の存続期間は、開始点によってローカルで決定され、デプロイメント固有である場合があります。この状態は、対応するMeasurement Replyを受信したとき、またはライフタイムが終了したときのいずれか早い方で終了します。中間ポイントまたはエンドポイントの一部が測定リクエストを処理したくないなど、いくつかの理由により、状態の期限が切れる前に対応する測定応答を受信できない場合があります。開始点は、このルートの別の測定リクエストを生成するかどうかを決定するときに、そのような可能性を考慮に入れるべきです。対応する測定要求の状態がすでに期限切れになっている場合、開始点は、それ以上の処理を行わずに受信した測定応答を破棄する必要があります。

4.1. When Measuring a Hop-by-Hop Route with a Global RPLInstanceID

4.1. グローバルRPLInstanceIDを使用してホップバイホップルートを測定する場合

If a Hop-by-hop Route with a global RPLInstanceID is being measured (i.e., H = 1 and RPLInstanceID has a global value), the MO MUST NOT contain an Address vector, and various MO fields MUST be set in the following manner:

グローバルRPLInstanceIDを持つホップバイホップルートが測定されている場合（つまり、H = 1であり、RPLInstanceIDがグローバル値を持っている場合）、MOにはアドレスベクトルを含めてはならず（MUST NOT）、さまざまなMOフィールドを次のように設定する必要があります。

o RPLInstanceID: This field MUST be set to the RPLInstanceID of the route being measured.

o RPLInstanceID：このフィールドは、測定されるルートのRPLInstanceIDに設定する必要があります。

o Compr: This field MUST be set to specify the number of prefix octets that are elided from the IPv6 addresses in Start Point/ End Point Address fields.

o Compr：このフィールドは、IPv6アドレスから除外されるプレフィックスオクテットの数を指定するために、開始点/終了点アドレスフィールドで設定する必要があります。

o Type (T): This flag MUST be set to one, since the MO represents a Measurement Request.

o タイプ（T）：MOは測定要求を表すため、このフラグは1に設定する必要があります。

o Hop-by-hop (H): This flag MUST be set to one.

o ホップバイホップ（H）：このフラグは1に設定する必要があります。

o Accumulate Route (A): This flag MUST be set to zero.

o ルートの蓄積（A）：このフラグはゼロに設定する必要があります。

o Reverse (R): This flag MUST be set to zero.

o リバース（R）：このフラグはゼロに設定する必要があります。

o Back Request (B): This flag MAY be set to one to request that the End Point send a Measurement Request to the Start Point.

o バックリクエスト（B）：このフラグを1に設定すると、エンドポイントが測定リクエストをスタートポイントに送信するように要求できます。

o Intermediate Reply (I): This flag MAY be set to one if the Start Point expects an Intermediate Point to know the values of the routing metrics being measured for the remainder of the route.

o 中間応答（I）：開始ポイントが中間ポイントがルートの残りの部分について測定されているルーティングメトリックの値を知ることを期待している場合、このフラグを1に設定できます（MAY）。

o SeqNo: This is assigned by the Start Point so that it can uniquely identify the Measurement Request and the corresponding Measurement Reply.

o SeqNo：これは開始点によって割り当てられるため、測定要求と対応する測定応答を一意に識別できます。

o Num: This field MUST be set to zero.

o Num：このフィールドはゼロに設定する必要があります。

o Index: This field MUST be set to zero.

o インデックス：このフィールドはゼロに設定する必要があります。

o Start Point Address: This field MUST be set to a unicast global/unique-local IPv6 address of the Start Point after eliding Compr number of prefix octets.

o 開始点アドレス：このフィールドは、Comprの接頭辞オクテット数を省略した後、開始点のユニキャストグローバル/一意ローカルIPv6アドレスに設定する必要があります。

o End Point Address: This field MUST be set to a unicast global/unique-local IPv6 address of the End Point after eliding Compr number of prefix octets.

o エンドポイントアドレス：このフィールドは、Comprのプレフィックスオクテット数を省略した後、エンドポイントのユニキャストグローバル/ユニークローカルIPv6アドレスに設定する必要があります。

4.2. When Measuring a Hop-by-Hop Route with a Local RPLInstanceID with Route Accumulation Off

4.2. ルートの累積がオフのローカルRPLInstanceIDでホップバイホップルートを測定する場合

If a Hop-by-hop Route with a local RPLInstanceID is being measured and the Start Point does not want the MO to accumulate a Source Route for the End Point's use, the MO MUST NOT contain the Address vector, and various MO fields MUST be set in the following manner:

ローカルRPLInstanceIDを持つホップバイホップルートが測定されており、スタートポイントがMOにエンドポイントの使用のためのソースルートを蓄積させたくない場合、MOはアドレスベクタを含んではならず（MUST NOT）、さまざまなMOフィールドは次のように設定します。

o RPLInstanceID: This field MUST be set to the RPLInstanceID of the route being measured.

o RPLInstanceID：このフィールドは、測定されるルートのRPLInstanceIDに設定する必要があります。

o Compr: This field MUST be set to specify the number of prefix octets that are elided from the IPv6 addresses in Start Point/ End Point Address fields.

o Type (T): This flag MUST be set to one, since the MO represents a Measurement Request.

o タイプ（T）：MOは測定要求を表すため、このフラグは1に設定する必要があります。

o Hop-by-hop (H): This flag MUST be set to one.

o ホップバイホップ（H）：このフラグは1に設定する必要があります。

o Accumulate Route (A): This flag MUST be set to zero.

o ルートの蓄積（A）：このフラグはゼロに設定する必要があります。

o Reverse (R): This flag MUST be set to zero.

o リバース（R）：このフラグはゼロに設定する必要があります。

o Back Request (B): This flag MAY be set to one to request that the End Point send a Measurement Request to the Start Point.

o バックリクエスト（B）：このフラグを1に設定すると、エンドポイントが測定リクエストをスタートポイントに送信することをリクエストできます。

o Intermediate Reply (I): This flag MUST be set to zero.

o 中間応答（I）：このフラグはゼロに設定する必要があります。

o SeqNo: This is assigned by the Start Point so that it can uniquely identify the Measurement Request and the corresponding Measurement Reply.

o SeqNo：これは開始点によって割り当てられるため、測定要求と対応する測定応答を一意に識別できます。

o Num: This field MUST be set to zero.

o Num：このフィールドはゼロに設定する必要があります。

o Index: This field MUST be set to zero.

o インデックス：このフィールドはゼロに設定する必要があります。

o Start Point Address: This field MUST contain the DODAGID value (after eliding Compr number of prefix octets) associated with the route being measured. This DODAGID MUST also be a global or unique-local IPv6 address of the Start Point.

o 開始点アドレス：このフィールドには、測定対象のルートに関連付けられたDODAGID値（接頭辞オクテットのCompr番号を省略した後）を含める必要があります。このDODAGIDは、スタートポイントのグローバルまたは一意のローカルIPv6アドレスでもある必要があります。

o End Point Address: This field MUST be set to a unicast global or unique-local IPv6 address of the End Point after eliding Compr number of prefix octets.

o エンドポイントアドレス：このフィールドは、Comprのプレフィックスオクテット数を省略した後、エンドポイントのユニキャストグローバルまたはユニークローカルIPv6アドレスに設定する必要があります。

4.3. When Measuring a Hop-by-Hop Route with a Local RPLInstanceID with Route Accumulation On

4.3. ルートの蓄積がオンになっているローカルRPLInstanceIDでホップバイホップルートを測定する場合

If a Hop-by-hop Route with a local RPLInstanceID is being measured and the Start Point desires the MO to accumulate a Source Route for the End Point to send the Measurement Reply message back, the MO MUST contain a suitably sized Address vector, and various MO fields MUST be set in the following manner:

ローカルRPLInstanceIDを持つホップバイホップルートが測定されており、スタートポイントがMOにエンドポイントのソースルートを蓄積して測定応答メッセージを返送することを望む場合、MOは適切なサイズのアドレスベクトルを含んでいる必要があります。さまざまなMOフィールドを次のように設定する必要があります。

o RPLInstanceID: This field MUST be set to the RPLInstanceID of the route being measured.

o RPLInstanceID：このフィールドは、測定されるルートのRPLInstanceIDに設定する必要があります。

o Compr: This field MUST be set to specify the number of prefix octets that are elided from the IPv6 addresses in Start Point/ End Point Address fields and the Address vector.

o Compr：このフィールドは、開始点/終了点アドレスフィールドとアドレスベクトルのIPv6アドレスから省略されるプレフィックスオクテットの数を指定するために設定する必要があります。

o Type (T): This flag MUST be set to one, since the MO represents a Measurement Request.

o タイプ（T）：MOは測定要求を表すため、このフラグは1に設定する必要があります。

o Hop-by-hop (H): This flag MUST be set to one.

o ホップバイホップ（H）：このフラグは1に設定する必要があります。

o Accumulate Route (A): This flag MUST be set to one.

o ルートの蓄積（A）：このフラグは1に設定する必要があります。

o Reverse (R): This flag MUST be set to zero.

o リバース（R）：このフラグはゼロに設定する必要があります。

o Back Request (B): This flag MAY be set to one to request that the End Point send a Measurement Request to the Start Point.

o Intermediate Reply (I): This flag MUST be set to zero.

o 中間応答（I）：このフラグはゼロに設定する必要があります。

o SeqNo: This is assigned by the Start Point so that it can uniquely identify the Measurement Request and the corresponding Measurement Reply.

o SeqNo：これは開始点によって割り当てられるため、測定要求と対応する測定応答を一意に識別できます。

o Num: This field MUST specify the number of address elements, each (16 - Compr) octets in size, that can fit inside the Address vector.

o Num：このフィールドは、アドレス要素の数を指定する必要があります。各（16-Compr）オクテットのサイズで、アドレスベクトル内に収まります。

o Index: This field MUST be set to zero to indicate the position in the Address vector where the next hop must store its IPv6 address.

o インデックス：このフィールドは、ネクストホップがIPv6アドレスを格納する必要があるアドレスベクトル内の位置を示すためにゼロに設定する必要があります。

o End Point Address: This field MUST be set to a unicast global or unique-local IPv6 address of the End Point after eliding Compr number of prefix octets.

o Address vector: The Address vector must be large enough to accommodate a complete Source Route from the End Point to the Start Point. All the bits in the Address vector field MUST be set to zero.

o アドレスベクトル：アドレスベクトルは、エンドポイントからスタートポイントまでの完全なソースルートに対応するのに十分な大きさである必要があります。アドレスベクトルフィールドのすべてのビットはゼロに設定する必要があります。

4.4. When Measuring a Source Route

4.4. ソースルートを測定するとき

If a Source Route is being measured, the Start Point MUST set various MO fields in the following manner:

ソースルートが測定されている場合、開始ポイントはさまざまなMOフィールドを次のように設定する必要があります。

o RPLInstanceID: This field does not have any significance when a Source Route is being measured and hence can be set to any value.

o RPLInstanceID：このフィールドは、ソースルートが測定されているときには重要ではないため、任意の値に設定できます。

o Compr: This field MUST be set to specify the number of prefix octets that are elided from the IPv6 addresses in Start Point/ End Point Address fields and the Address vector.

o Type (T): This flag MUST be set to one, since the MO represents a Measurement Request.

o タイプ（T）：MOは測定要求を表すため、このフラグは1に設定する必要があります。

o Hop-by-hop (H): This flag MUST be set to zero.

o ホップバイホップ（H）：このフラグはゼロに設定する必要があります。

o Accumulate Route (A): This flag MUST be set to zero.

o ルートの蓄積（A）：このフラグはゼロに設定する必要があります。

o Reverse (R): This flag SHOULD be set to one if the Source Route in the Address vector can be reversed and used by the End Point to send the Measurement Reply message back to the Start Point. Otherwise, this flag MUST be set to zero.

o リバース（R）：このフラグは、アドレスベクタのソースルートをリバースして、エンドポイントが測定応答メッセージをスタートポイントに送り返すために使用できる場合、1に設定する必要があります（SHOULD）。それ以外の場合、このフラグはゼロに設定する必要があります。

o Back Request (B): This flag MAY be set to one to request that the End Point send a Measurement Request to the Start Point.

o Intermediate Reply (I): This flag MUST be set to zero.

o 中間応答（I）：このフラグはゼロに設定する必要があります。

o SeqNo: This is assigned by the Start Point so that it can uniquely identify the Measurement Request and the corresponding Measurement Reply.

o SeqNo：これは開始点によって割り当てられるため、測定要求と対応する測定応答を一意に識別できます。

o Num: This field MUST specify the number of address elements, each (16 - Compr) octets in size, inside the Address vector.

o Num：このフィールドは、アドレスエレメントの数を指定する必要があります。各（16-Compr）オクテットのサイズで、アドレスベクトル内にあります。

o Index: This field MUST be set to zero to indicate the position in the Address vector of the next hop on the route.

o インデックス：このフィールドは、ルート上の次のホップのアドレスベクタ内の位置を示すためにゼロに設定する必要があります。

o Start Point Address: This field MUST be set to a unicast global or unique-local IPv6 address of the Start Point after eliding Compr number of prefix octets.

o 開始点アドレス：このフィールドは、Compr数の接頭辞オクテットを省略した後、開始点のユニキャストグローバルまたは一意のローカルIPv6アドレスに設定する必要があります。

o End Point Address: This field MUST be set to a unicast global or unique-local IPv6 address of the End Point after eliding Compr number of prefix octets.

o Address vector:

o アドレスベクトル：

* The Address vector MUST contain a complete Source Route from the Start Point to the End Point (excluding the Start Point and the End Point).

* アドレスベクトルには、始点から終点（始点と終点を除く）への完全なソースルートが含まれている必要があります。

* Each address appearing in the Address vector MUST be a unicast global or unique-local IPv6 address. Further, each address MUST have the same prefix as the Start Point Address and the End Point Address. This prefix, whose length in octets is specified in the Compr field, MUST be elided from each address.

* アドレスベクトルに現れる各アドレスは、ユニキャストグローバルまたはユニークローカルIPv6アドレスである必要があります。さらに、各アドレスには、開始ポイントアドレスおよび終了ポイントアドレスと同じプレフィックスが必要です。オクテット単位の長さがComprフィールドで指定されているこの接頭辞は、各アドレスから削除する必要があります。

* The IPv6 addresses in the Address vector MUST be reachable in the Forward direction.

* アドレスベクタのIPv6アドレスは、順方向に到達可能でなければなりません。

* If the R flag is set to one, the IPv6 addresses in the Address vector MUST also be reachable in the Reverse direction.

* Rフラグが1に設定されている場合、アドレスベクタのIPv6アドレスは逆方向にも到達可能でなければなりません（MUST）。

5. Processing a Measurement Request at an Intermediate Point

5. 中間点での測定要求の処理

A router (an Intermediate Point or the End Point) MAY discard a received MO with no processing, in order to meet any policy-related goals. Such policy goals may include the need to reduce the router's CPU load, or to enhance its battery life, or to prevent the misuse of this mechanism by unauthorized nodes.

ルーター（中間ポイントまたはエンドポイント）は、ポリシー関連の目的を満たすために、処理せずに受信したMOを破棄できます（MAY）。このようなポリシーの目標には、ルーターのCPU負荷を減らす必要があるか、そのバッテリー寿命を延ばす必要があるか、または権限のないノードによるこのメカニズムの誤用を防ぐ必要があります。

A router MUST discard a received MO with no further processing if the value in the Compr field inside the received message is more than what the router considers to be the length of the common prefix used in IPv6 addresses in the LLN.

受信したメッセージ内のComprフィールドの値が、ルーターがLLNのIPv6アドレスで使用されている共通のプレフィックスの長さであると見なす値より大きい場合、ルーターは受信したMOを破棄せずに処理する必要があります。

On receiving an MO, if a router chooses to process the packet further, it MUST determine whether or not one of its IPv6 addresses is listed as either the Start Point or the End Point Address. If not, the router considers itself an Intermediate Point and MUST process the received MO in the following manner.

MOの受信時に、ルーターがさらにパケットを処理することを選択した場合、ルーターはそのIPv6アドレスの1つが開始点または終了点アドレスとしてリストされているかどうかを判断する必要があります。そうでない場合、ルータは自身を中間ポイントと見なし、受信したMOを次の方法で処理する必要があります。

An Intermediate Point MUST discard the packet with no further processing if the received MO is not a Measurement Request (i.e., T = 0). This is because the End Point unicasts a Measurement Reply directly to the Start Point. So, the Intermediate Point treats a transiting Measurement Reply as a data packet and not a RPL control message.

受信したMOが測定要求でない場合（つまり、T = 0）、中間ポイントはパケットを破棄し、それ以上処理する必要はありません（MUST）。これは、エンドポイントが測定応答を開始ポイントに直接ユニキャストするためです。したがって、中間ポイントは、通過する測定応答をRPL制御メッセージではなく、データパケットとして扱います。

Next, the Intermediate Point determines the type of the route being measured (by checking the values of the H flag and the RPLInstanceID field) and processes the received MO accordingly, in the manner specified next.

次に、中間ポイントは（HフラグとRPLInstanceIDフィールドの値をチェックすることにより）測定中のルートのタイプを決定し、それに応じて、次に指定された方法で受信したMOを処理します。

5.1. When Measuring a Hop-by-Hop Route with a Global RPLInstanceID

5.1. グローバルRPLInstanceIDを使用してホップバイホップルートを測定する場合

If a Hop-by-hop Route with a global RPLInstanceID is being measured (i.e., H = 1 and RPLInstanceID has a global value), the Intermediate Point MUST process the received Measurement Request in the following manner.

グローバルRPLInstanceIDを持つホップバイホップルートが測定されている場合（つまり、H = 1であり、RPLInstanceIDがグローバル値を持つ場合）、中間ポイントは受信した測定要求を次の方法で処理する必要があります。

If the Num field inside the received Measurement Request is not set to zero, thereby implying that an Address vector is present, the Intermediate Point MUST discard the received message with no further processing.

受信したMeasurement Request内のNumフィールドがゼロに設定されていない場合、つまり、アドレスベクトルが存在することを意味する場合、中間ポイントは、それ以上の処理を行わずに受信したメッセージを破棄する必要があります。

If the Intermediate Reply (I) flag is set to one in the received Measurement Request and the Intermediate Point knows the values of the routing metrics (as specified in the Metric Container options) for the remainder of the route, it MAY generate a Measurement Reply on the End Point's behalf in the manner specified in Section 6.1

受信した測定要求で中間応答（I）フラグが1に設定されていて、中間ポイントがルートの残りの部分のルーティングメトリックの値（メトリックコンテナーオプションで指定されている）を知っている場合、測定応答を生成できます（MAY）セクション6.1で指定された方法でエンドポイントに代わって

(after including in the Measurement Reply the relevant routing metric values for the complete route being measured). Otherwise, the Intermediate Point MUST process the received message in the following manner.

（測定応答に含めた後、測定される完全なルートに関連するルーティングメトリック値）。それ以外の場合、中間ポイントは受信したメッセージを次の方法で処理する必要があります。

The Intermediate Point MUST determine the next hop on the route being measured using the RPLInstanceID and the End Point Address. If the Intermediate Point is the root of the non-storing global DAG along which the received Measurement Request had been traveling so far, it MUST process the received Measurement Request in the following manner:

中間ポイントは、RPLInstanceIDとエンドポイントアドレスを使用して、測定されているルートの次のホップを決定する必要があります。中間ポイントが、受信した測定リクエストがこれまで移動してきた非ストレージグローバルDAGのルートである場合、受信した測定リクエストを次の方法で処理する必要があります。

o If the router does not know how to reach the End Point, it MUST discard the Measurement Request with no further processing and MAY send an ICMPv6 Destination Unreachable (with Code 0 -- No Route To Destination) error message [RFC4443] to the Start Point.

o ルーターがエンドポイントに到達する方法を知らない場合、それ以上の処理なしで測定リクエストを破棄する必要があり、ICMPv6宛先到達不能（コード0-宛先へのルートなし）エラーメッセージ[RFC4443]をスタートポイントに送信することができます。

o Otherwise, unless the router determines the End Point itself to be the next hop, the router MUST make the following changes in the received Measurement Request:

o それ以外の場合、ルーターがエンドポイント自体をネクストホップであると判断しない限り、ルーターは受信した測定要求に次の変更を加える必要があります。

* Set the H, A, R, and I flags to zero (the A and R flags should already be zero in the received message).

* H、A、R、およびIフラグをゼロに設定します（受信したメッセージでは、AおよびRフラグはすでにゼロになっているはずです）。

* Leave the remaining fields unchanged (the Num field would be modified in the next steps). Note that the RPLInstanceID field identifies the non-storing global DAG along which the Measurement Request traveled so far. This information MUST be preserved so that the End Point may use this DAG to send the Measurement Reply back to the Start Point.

* 残りのフィールドは変更しないでください（Numフィールドは次の手順で変更します）。 RPLInstanceIDフィールドは、測定リクエストがこれまでに移動した非保存グローバルDAGを識別することに注意してください。エンドポイントがこのDAGを使用して測定応答をスタートポイントに送り返すことができるように、この情報を保持する必要があります。

* Insert a new Address vector inside the Measurement Request, and specify a Source Route to the End Point inside the Address vector as per the following rules:

* 次のルールに従って、測定リクエスト内に新しいアドレスベクトルを挿入し、アドレスベクトル内のエンドポイントへのソースルートを指定します。

+ The Address vector MUST contain a complete route from the router to the End Point (excluding the router and the End Point).

+ アドレスベクターには、ルーターからエンドポイントへの完全なルートが含まれている必要があります（ルーターとエンドポイントを除く）。

+ Each address appearing in the Address vector MUST be a unicast global or unique-local IPv6 address. Further, each address MUST have the same prefix as the Start Point Address and the End Point Address. This prefix, whose length in octets is specified in the Compr field, MUST be elided from each address.

+ アドレスベクトルに現れる各アドレスは、ユニキャストグローバルまたはユニークローカルIPv6アドレスである必要があります。さらに、各アドレスには、開始ポイントアドレスおよび終了ポイントアドレスと同じプレフィックスが必要です。オクテット単位の長さがComprフィールドで指定されているこの接頭辞は、各アドレスから削除する必要があります。

+ The IPv6 addresses in the Address vector MUST be reachable in the Forward direction.

+ アドレスベクタのIPv6アドレスは、順方向に到達可能でなければなりません。

If the router cannot insert an Address vector satisfying the rules mentioned above, it MUST discard the Measurement Request with no further processing and MAY send an ICMPv6 Destination Unreachable (with Code 0 -- No Route To Destination) error message [RFC4443] to the Start Point.

ルーターが上記のルールを満たすアドレスベクトルを挿入できない場合は、それ以上の処理を行わずに測定要求を破棄する必要があり、ICMPv6宛先到達不能（コード0-宛先へのルートなし）エラーメッセージ[RFC4443]を開始に送信する必要がありますポイント。

* Specify in the Num field the number of address elements in the Address vector.

* [Num]フィールドで、アドレスベクトルのアドレス要素の数を指定します。

* Set the Index field to zero to indicate the position in the Address vector of the next hop on the route. Thus, the Address[0] element contains the address of the next hop on the route.

* [インデックス]フィールドをゼロに設定して、ルート上の次のホップのアドレスベクタ内の位置を示します。したがって、Address [0]要素には、ルート上のネクストホップのアドレスが含まれています。

The Intermediate Point MUST then complete the processing of the received Measurement Request as specified in Section 5.5.

中間ポイントは、セクション5.5で指定されているように、受信した測定リクエストの処理を完了しなければなりません（MUST）。

5.2. When Measuring a Hop-by-Hop Route with a Local RPLInstanceID with Route Accumulation Off

5.2. ルートの蓄積がオフのローカルRPLInstanceIDを使用してホップバイホップルートを測定する場合

If a Hop-by-hop Route with a local RPLInstanceID is being measured and the route accumulation is off (i.e., H = 1, RPLInstanceID has a local value, and A = 0), the Intermediate Point MUST process the received Measurement Request in the following manner.

ローカルRPLInstanceIDを持つホップバイホップルートが測定され、ルートの累積がオフの場合（つまり、H = 1、RPLInstanceIDはローカル値、およびA = 0）、中間ポイントは受信した測定リクエストを次のように。

5.3. When Measuring a Hop-by-Hop Route with a Local RPLInstanceID with Route Accumulation On

5.3. ルートの蓄積がオンになっているローカルRPLInstanceIDでホップバイホップルートを測定する場合

If a Hop-by-hop Route with a local RPLInstanceID is being measured and the route accumulation is on (i.e., H = 1, RPLInstanceID has a local value, and A = 1), the Intermediate Point MUST process the received Measurement Request in the following manner.

ローカルRPLInstanceIDを持つホップバイホップルートが測定されており、ルートの累積がオンの場合（つまり、H = 1、RPLInstanceIDはローカル値、およびA = 1）、中間ポイントは受信した測定要求を次のように。

If the Num field inside the received Measurement Request is set to zero, thereby implying that an Address vector is not present, the Intermediate Point MUST discard the received message with no further processing.

受信したMeasurement Request内のNumフィールドがゼロに設定されていて、それによりアドレスベクトルが存在しないことを意味する場合、中間ポイントは、それ以上の処理を行わずに受信したメッセージを破棄する必要があります。

The Intermediate Point MUST then determine the next hop on the route being measured using the RPLInstanceID, the End Point Address, and the Start Point Address (which represents the DODAGID of the route being measured). If the Intermediate Point cannot determine the next hop, it MUST discard the Measurement Request with no further processing and MAY send an ICMPv6 Destination Unreachable (with Code 0 -- No Route To Destination) error message [RFC4443] to the Start Point. If the index field has value Num - 1 and the next hop is not the same as the End Point, the Intermediate Point MUST drop the received Measurement Request with no further processing. In this case, the next hop would have no space left in the Address vector to store its address. Otherwise, the router MUST store one of its IPv6 addresses at location Address[Index] and then increment the Index field. The IPv6 address added to the Address vector MUST have the following properties:

次に、中間ポイントは、RPLInstanceID、エンドポイントアドレス、およびスタートポイントアドレス（測定されるルートのDODAGIDを表す）を使用して、測定されるルートのネクストホップを決定する必要があります。中間ポイントが次のホップを決定できない場合、それはそれ以上の処理なしで測定要求を破棄しなければならず、ICMPv6宛先到達不能（コード0-宛先へのルートなし）エラーメッセージ[RFC4443]を開始ポイントに送信してもよい（MAY）。インデックスフィールドの値がNum-1で、ネクストホップがエンドポイントと同じでない場合、中間ポイントは、それ以上の処理を行わずに、受信したMeasurement Requestをドロップする必要があります。この場合、ネクストホップには、アドレスを格納するためのアドレスベクトルのスペースが残っていません。それ以外の場合、ルーターはIPv6アドレスの1つをアドレス[インデックス]に格納してから、インデックスフィールドをインクリメントする必要があります。アドレスベクターに追加されたIPv6アドレスには、次のプロパティが必要です。

o This address MUST be a unicast global or unique-local address.

o このアドレスは、ユニキャストのグローバルアドレスまたは一意のローカルアドレスである必要があります。

o This address MUST have the same prefix as the Start Point Address and the End Point Address. This prefix, whose length in octets is specified in the Compr field, MUST be elided before the address is added to the Address vector.

o このアドレスには、開始点アドレスおよび終了点アドレスと同じプレフィックスが必要です。オクテット単位の長さがComprフィールドで指定されているこの接頭辞は、アドレスがアドレスベクタに追加される前に省略される必要があります。

o This address MUST be reachable in the Reverse direction.

o このアドレスは逆方向に到達可能でなければなりません。

If the router does not have an IPv6 address that satisfies the properties mentioned above, it MUST discard the Measurement Request with no further processing.

上記のプロパティを満たすIPv6アドレスがルーターにない場合、ルーターはそれ以上の処理をせずに測定要求を破棄する必要があります。

The Intermediate Point MUST then complete the processing of the received Measurement Request as specified in Section 5.5.

中間ポイントは、セクション5.5で指定されているように、受信した測定リクエストの処理を完了しなければなりません（MUST）。

5.4. When Measuring a Source Route

5.4. ソースルートを測定するとき

If a Source Route is being measured (i.e., H = 0), the Intermediate Point MUST process the received Measurement Request in the following manner.

ソースルートが測定されている場合（つまり、H = 0）、中間ポイントは受信した測定要求を次の方法で処理する必要があります。

受信したMeasurement Request内のNumフィールドがゼロに設定されていて、アドレスベクトルが存在しないことを意味する場合、中間ポイントは、それ以上の処理を行わずに受信したメッセージを破棄する必要があります。

The Intermediate Point MUST verify that the Address[Index] element lists one of its unicast global or unique-local IPv6 addresses (minus the prefix whose length in octets is specified in the Compr field), failing which it MUST discard the Measurement Request with no further processing. The Intermediate Point MUST then increment the Index field and use the Address[Index] element as the next hop (unless the Index value is now Num). If the Index value is now Num, the Intermediate Point MUST use the End Point Address as the next hop.

中間ポイントは、Address [Index]要素がそのユニキャストグローバルまたは一意ローカルIPv6アドレス（オクテット単位の長さがComprフィールドで指定されているプレフィックスを除く）の1つをリストしていることを確認する必要があります。さらなる処理。次に中間ポイントは、インデックスフィールドをインクリメントし、Address [Index]要素を次のホップとして使用する必要があります（インデックス値がNumでない場合）。インデックス値がNumになった場合、中間ポイントはエンドポイントアドレスをネクストホップとして使用する必要があります。

The Intermediate Point MUST then complete the processing of the received Measurement Request as specified in Section 5.5.

中間ポイントは、セクション5.5で指定されているように、受信した測定リクエストの処理を完了しなければなりません（MUST）。

5.5. Final Processing

5.5. 最終処理

The Intermediate Point MUST drop the received Measurement Request with no further processing:

中間ポイントは、それ以上の処理を行わずに、受信した測定リクエストをドロップする必要があります：

o if the next-hop address is not a unicast address; or

o ネクストホップアドレスがユニキャストアドレスでない場合。または

o if the next hop is not on-link; or

o ネクストホップがリンク上にない場合。または

o if the next hop is not in the same RPL routing domain as the Intermediate Point.

o ネクストホップが中間ポイントと同じRPLルーティングドメインにない場合。

Next, the Intermediate Point MUST update the routing metric objects, inside the Metric Container option(s) inside the Measurement Request, either by updating the aggregated value for the routing metric or by attaching the local values for the metric inside the object. An Intermediate Point can only update the existing metric objects and MUST NOT add any new routing metric objects to the Metric Container. An Intermediate Point MUST drop the Measurement Request with no further processing if it cannot update a routing metric object specified inside the Metric Container.

次に、中間ポイントは、ルーティングメトリックの集約値を更新するか、オブジェクト内のメトリックのローカル値をアタッチすることにより、Measurement Request内のMetric Containerオプション内のルーティングメトリックオブジェクトを更新する必要があります。中間ポイントは既存のメトリックオブジェクトのみを更新でき、メトリックコンテナーに新しいルーティングメトリックオブジェクトを追加してはなりません。中間ポイントは、メトリックコンテナー内で指定されたルーティングメトリックオブジェクトを更新できない場合、それ以上の処理なしで測定リクエストをドロップする必要があります。

Finally, the Intermediate Point MUST unicast the Measurement Request to the next hop.

最後に、中間ポイントは次のホップに測定要求をユニキャストする必要があります。

6. Processing a Measurement Request at the End Point

6. エンドポイントでの測定リクエストの処理

On receiving an MO, if a router chooses to process the message further and finds one of its unicast global or unique-local IPv6 addresses (minus the prefix whose length in octets is specified in the Compr field) listed as the End Point Address, the router considers itself the End Point and MUST process the received MO in the following manner.

MOを受信すると、ルータがメッセージをさらに処理することを選択し、エンドポイントアドレスとしてリストされているユニキャストグローバルまたは一意ローカルIPv6アドレス（オクテットの長さがComprフィールドで指定されているプレフィックスを除く）の1つを見つけた場合、ルータは自身をエンドポイントと見なし、次の方法で受信したMOを処理する必要があります。

The End Point MUST discard the received message with no further processing if it is not a Measurement Request (i.e., T = 0).

エンドポイントは、それが測定要求でない場合（つまり、T = 0）、受信したメッセージをそれ以上処理せずに破棄する必要があります。

If the received Measurement Request traveled on a Hop-by-hop Route with a local RPLInstanceID with route accumulation on (i.e., H = 1, RPLInstanceID has a local value, and A = 1), elements Address[0] through Address[Index - 1] in the Address vector contain a complete Source Route from the Start Point to the End Point, which the End Point MAY use, after reversal, to reach the Start Point. Note that the Source Route in the Address vector does not include the Start Point and the End Point addresses, and that the individual addresses do not include the common prefix whose length in octets is specified in the Compr field.

受信したMeasurement Requestが、ルートの累積がオンになっているローカルRPLInstanceID（つまり、H = 1、RPLInstanceIDがローカル値、A = 1）のホップバイホップルートを移動した場合、要素Address [0]からAddress [Index -[1]アドレスベクトルには、開始ポイントから終了ポイントまでの完全なソースルートが含まれます。終了ポイントは、反転後に開始ポイントに到達するために使用できます（MAY）。アドレスベクトルのソースルートには、開始点と終了点のアドレスが含まれておらず、個々のアドレスには、オクテット単位の長さがComprフィールドで指定されている共通のプレフィックスが含まれていないことに注意してください。

If the received Measurement Request traveled on a Source Route and the Reverse flag is set to one (i.e., H = 0 and R = 1), elements Address[0] through Address[Num - 1] in the Address vector contain a complete Source Route from the Start Point to the End Point, which the End Point MAY use, after reversal, to reach the Start Point. Again, the Source Route in the Address vector does not include the Start Point and the End Point addresses, and the individual addresses do not include the common prefix whose length in octets is specified in the Compr field.

受信した測定リクエストがソースルートを移動し、Reverseフラグが1に設定されている場合（つまり、H = 0およびR = 1）、アドレスベクトルのエレメントAddress [0]からAddress [Num-1]には完全なソースが含まれます。始点から終点へのルート。終点は、反転後に始点に到達するために使用できます（MAY）。繰り返しになりますが、アドレスベクトルのソースルートには、開始ポイントと終了ポイントのアドレスは含まれていません。また、個々のアドレスには、Comprフィールドでオクテット単位の長さが指定されている共通のプレフィックスは含まれていません。

The End Point MUST update the routing metric objects in the Metric Container options if required and MAY note the measured values for the complete route (especially if the received Measurement Request is likely a response to an earlier Measurement Request that the End Point had sent to the Start Point with the B flag set to one).

エンドポイントは、必要に応じてメトリックコンテナオプションのルーティングメトリックオブジェクトを更新する必要があり、完全なルートの測定値を記録する必要があります（特に、受信した測定要求が、エンドポイントが送信した以前の測定要求に対する応答である可能性がある場合Bフラグを1に設定した開始点）。

The End Point MUST generate a Measurement Reply message as specified in Section 6.1. If the B flag is set to one in the received Measurement Request, the End Point SHOULD generate a new Measurement Request to measure the cost of its current (or the most preferred) route to the Start Point. The routing metrics used in the new Measurement Request MUST include the routing metrics specified in the received Measurement Request.

エンドポイントは、セクション6.1で指定されているようにMeasurement Replyメッセージを生成する必要があります。受信したMeasurement RequestでBフラグが1に設定されている場合、End Pointは、新しいMeasurement Requestを生成して、開始点への現在の（または最も好ましい）ルートのコストを測定する必要があります。新しい測定リクエストで使用されるルーティングメトリックには、受信した測定リクエストで指定されたルーティングメトリックが含まれている必要があります。

6.1. Generating the Measurement Reply

6.1. 測定応答の生成

A Measurement Reply MUST have the Type (T) flag set to zero and need not contain the Address vector. The following fields inside a Measurement Reply MUST have the same values as they had inside the corresponding Measurement Request: RPLInstanceID, Compr, SeqNo, Start Point Address, End Point Address, and Metric Container option(s). The remaining fields inside a Measurement Reply may have any value and MUST be ignored on reception at the Start Point; the received Measurement Request can, therefore, trivially be converted into a Measurement Reply by setting the Type (T) flag to zero.

Measurement Replyでは、タイプ（T）フラグをゼロに設定する必要があり、アドレスベクタを含める必要はありません。 Measurement Reply内の次のフィールドは、対応するMeasurement Request内にあるものと同じ値である必要があります：RPLInstanceID、Compr、SeqNo、開始点アドレス、終了点アドレス、およびメトリックコンテナーオプション。 Measurement Reply内の残りのフィールドには任意の値を含めることができ、開始ポイントでの受信時に無視する必要があります。したがって、受信した測定要求は、タイプ（T）フラグをゼロに設定することによって、簡単に測定応答に変換できます。

A Measurement Reply MUST be unicast back to the Start Point:

Measurement Replyは、開始点にユニキャストで返される必要があります。

o If the Measurement Request traveled along a global DAG, identified by the RPLInstanceID field, the Measurement Reply MAY be unicast back to the Start Point along the same DAG.

o RPLInstanceIDフィールドで識別されるグローバルDAGに沿って測定リクエストが移動した場合、測定応答は同じDAGに沿って開始ポイントにユニキャストで返される場合があります。

o If the Measurement Request traveled along a Hop-by-hop Route with a local RPLInstanceID and accumulated a Source Route from the Start Point to the End Point, this Source Route MAY be used after reversal to send the Measurement Reply back to the Start Point.

o 測定リクエストがローカルRPLInstanceIDを使用してホップバイホップルートに沿って移動し、開始ポイントから終了ポイントへのソースルートを蓄積した場合、このソースルートは、反転後に測定応答を開始ポイントに送信するために使用できます。

o If the Measurement Request traveled along a Source Route and the R flag inside the received message is set to one, the End Point MAY reverse the Source Route contained in the Address vector and use it to send the Measurement Reply back to the Start Point.

o 測定リクエストがソースルートに沿って移動し、受信したメッセージ内のRフラグが1に設定されている場合、エンドポイントはアドレスベクトルに含まれるソースルートを逆にし、それを使用して測定応答を開始ポイントに送り返すことができます。

7. Processing a Measurement Reply at the Start Point

7. 開始点での測定応答の処理

When a router receives an MO, it examines the MO to see if one of its unicast IPv6 addresses is listed as the Start Point Address. If yes, the router is the Start Point and MUST process the received message in the following manner.

ルータはMOを受信すると、MOを調べて、そのユニキャストIPv6アドレスの1つが開始点アドレスとしてリストされているかどうかを確認します。はいの場合、ルーターは開始点であり、受信したメッセージを次の方法で処理する必要があります。

If the Start Point discovers that the received MO is not a Measurement Reply, or if it no longer maintains state for the corresponding Measurement Request, it MUST discard the received message with no further processing.

受信したMOが測定応答ではないことを開始点が発見した場合、または対応する測定要求の状態を維持しなくなった場合、それ以上の処理を行わずに受信メッセージを破棄する必要があります。

The Start Point can use the routing metric objects inside the Metric Container to evaluate the metrics for the measured P2P route. If a routing metric object contains local metric values recorded by routers on the route, the Start Point can make use of these local values by aggregating them into an end-to-end metric, according to the aggregation rules for the specific metric. A Start Point is then free to interpret the metrics for the route, according to its local policy.

スタートポイントは、メトリックコンテナ内のルーティングメトリックオブジェクトを使用して、測定されたP2Pルートのメトリックを評価できます。ルーティングメトリックオブジェクトに、ルート上のルーターによって記録されたローカルメトリック値が含まれている場合、スタートポイントは、特定のメトリックの集約ルールに従って、それらをエンドツーエンドメトリックに集約することにより、これらのローカル値を利用できます。開始ポイントは、ローカルポリシーに従って、ルートのメトリックを自由に解釈できます。

8. Security Considerations

8. セキュリティに関する考慮事項

In general, the security considerations for the route measurement mechanism described in this document are similar to those for RPL (as described in Section 19 of the RPL specification [RFC6550]). Sections 6.1 and 10 of [RFC6550] describe RPL's security framework, which provides data confidentiality, authentication, replay protection, and delay protection services. This security framework is applicable to the route measurement mechanism described here as well, after taking into account the constraints specified in Section 3.2.

一般に、このドキュメントで説明されているルート測定メカニズムのセキュリティに関する考慮事項は、RPLの場合と同様です（RPL仕様[RFC6550]のセクション19で説明されています）。 [RFC6550]のセクション6.1と10は、データの機密性、認証、再生保護、および遅延保護サービスを提供するRPLのセキュリティフレームワークについて説明しています。このセキュリティフレームワークは、セクション3.2で指定された制約を考慮した後、ここで説明するルート測定メカニズムにも適用できます。

This document requires that all routers participating in a secure invocation of the route measurement process use the Security Configuration chosen by the Start Point. The intention is to avoid compromising the overall security of the route measurement due to some routers using a weaker Security Configuration. A router is allowed to participate in a "secure" route measurement only if it can support the Security Configuration in use, which also specifies the key in use. It does not matter whether the key is preinstalled or dynamically acquired after proper authentication. The router must have the key in use before it can process or generate Secure MO messages. Hence, from the perspective of the route measurement mechanism, there is no distinction between the "preinstalled" and "authenticated" security modes described in the RPL specification [RFC6550]. Of course, if a compromised router has the key being used, it could cause the route measurement to fail, or worse, insert wrong information in Secure MO messages.

このドキュメントでは、ルート測定プロセスの安全な呼び出しに参加しているすべてのルーターが、スタートポイントで選択されたセキュリティ構成を使用する必要があります。これは、一部のルーターがより弱いセキュリティ構成を使用しているために、ルート測定の全体的なセキュリティが損なわれないようにするためです。ルーターは、使用中のキーを指定する使用中のセキュリティ構成をサポートできる場合にのみ、「安全な」ルート測定に参加できます。キーが事前にインストールされているか、適切な認証後に動的に取得されるかは関係ありません。ルーターは、セキュアMOメッセージを処理または生成する前に、キーを使用している必要があります。したがって、ルート測定メカニズムの観点からは、RPL仕様[RFC6550]で説明されている「プリインストール」と「認証」のセキュリティモードの違いはありません。もちろん、危険にさらされたルーターがキーを使用していると、ルート測定が失敗したり、さらに悪いことに、セキュアMOメッセージに誤った情報が挿入されたりする可能性があります。

A rogue router acting as the Start Point could use the route measurement mechanism defined in this document to measure routes from itself to other routers and thus find out key information about the LLN, e.g., the topological features of the LLN (such as the identity of the key routers in the topology) or the remaining energy levels [RFC6551] in the routers. This information can potentially be used to attack the LLN. A rogue router could also use this mechanism to send bogus Measurement Requests to arbitrary End Points. If sufficient Measurement Requests are sent, then it may cause CPU overload in the routers in the network, drain their batteries, and cause traffic congestion in the network. Note that some of these problems would occur even if the compromised router were to generate bogus data traffic to arbitrary destinations.

開始点として機能する不正なルーターは、このドキュメントで定義されているルート測定メカニズムを使用して、それ自体から他のルーターへのルートを測定し、LLNのトポロジー機能（たとえば、トポロジーの主要なルーター）またはルーターの残りのエネルギーレベル[RFC6551]。この情報は、LLNを攻撃するために使用される可能性があります。不正ルーターもこのメカニズムを使用して、任意のエンドポイントに偽の測定要求を送信できます。十分な測定要求が送信されると、ネットワーク内のルーターでCPU過負荷が発生し、バッテリーが消耗し、ネットワークでトラフィックが輻輳する可能性があります。侵害されたルーターが任意の宛先への偽のデータトラフィックを生成したとしても、これらの問題の一部が発生することに注意してください。

To protect against such misuse, this document allows RPL routers implementing this mechanism to not process MO messages (or process such messages selectively), based on a local policy. For example, an LLN deployment might require the use of Secure MO messages generated using a key that could be obtained only after proper authentication. Note that this document requires that an LLN deployment support Secure MO messages so that such policies can be enforced where considered essential.

このような誤用を防ぐために、このドキュメントでは、このメカニズムを実装するRPLルーターがローカルポリシーに基づいてMOメッセージを処理しない（またはそのようなメッセージを選択的に処理しない）ようにします。たとえば、LLN展開では、適切な認証後にのみ取得できるキーを使用して生成されたセキュアMOメッセージの使用が必要になる場合があります。このドキュメントでは、LLNの展開でセキュアMOメッセージがサポートされている必要があることに注意してください。そうすることで、そのようなポリシーを必須と見なされる場所に適用できます。

Since a Measurement Request can travel along a Source Route specified in the Address vector, some of the security concerns that led to the deprecation of Type 0 routing headers [RFC5095] may be valid here. To address such concerns, the mechanism described in this document includes several remedies, in the form of the following requirements:

測定リクエストはアドレスベクトルで指定されたソースルートに沿って移動できるため、タイプ0ルーティングヘッダー[RFC5095]の廃止につながったセキュリティ上の懸念の一部がここで有効になる場合があります。このような懸念に対処するために、このドキュメントで説明するメカニズムには、次の要件の形でいくつかの救済策が含まれています。

o A route inserted inside the Address vector must be a strict Source Route and must not include any multicast addresses.

o アドレスベクター内に挿入されるルートは、厳密なソースルートである必要があり、マルチキャストアドレスを含めないでください。

o An MO message must not cross the boundaries of the RPL routing domain where it originated. A router must not forward a received MO message further if the next hop belongs to a different RPL routing domain. Hence, any security problems associated with the mechanism would be limited to one RPL routing domain.

o MOメッセージは、発信元のRPLルーティングドメインの境界を越えてはなりません。ネクストホップが別のRPLルーティングドメインに属している場合、ルーターは受信したMOメッセージをさらに転送してはなりません。したがって、このメカニズムに関連するセキュリティの問題は、1つのRPLルーティングドメインに限定されます。

o A router must drop a received Measurement Request if the next-hop address is not on-link or if it is not a unicast address.

o ネクストホップアドレスがオンリンクでない場合、またはユニキャストアドレスでない場合、ルータは受信したMeasurement Requestをドロップする必要があります。

9. IANA Considerations

9. IANAに関する考慮事項

This document defines two new RPL messages:

このドキュメントでは、2つの新しいRPLメッセージを定義します。

o "Measurement Object" (see Section 3.1), assigned a value of 0x06 from the "RPL Control Codes" space [RFC6550].

o 「測定オブジェクト」（セクション3.1を参照）、「RPL制御コード」スペース[RFC6550]から0x06の値を割り当てました。

o "Secure Measurement Object" (see Section 3.2), assigned a value of 0x86 from the "RPL Control Codes" space [RFC6550].

o 「Secure Measurement Object」（セクション3.2を参照）、「RPL Control Codes」スペース[RFC6550]から0x86の値を割り当てました。

             +------+---------------------------+---------------+
             | Code |        Description        |   Reference   |
             +------+---------------------------+---------------+
             | 0x06 |     Measurement Object    | This document |
             | 0x86 | Secure Measurement Object | This document |
             +------+---------------------------+---------------+

RPL Control Codes

RPL制御コード

10. Acknowledgements

10. 謝辞

The authors gratefully acknowledge the contributions of Ralph Droms, Adrian Farrel, Joel Halpern, Matthias Philipp, Pascal Thubert, Richard Kelsey, and Zach Shelby in the development of this document.

著者は、このドキュメントの開発におけるラルフドロムス、エイドリアンファレル、ジョエルハルパーン、マティアスフィリップ、パスカルチューバート、リチャードケルシー、およびザックシェルビーの貢献に感謝します。

11. References

11. 参考文献

11.1. Normative References

11.1. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。

[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.

[RFC4443] Conta、A.、Deering、S。、およびM. Gupta、「インターネット制御メッセージプロトコル（ICMPv6）、インターネットプロトコルバージョン6（IPv6）仕様」、RFC 4443、2006年3月。

[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, March 2012.

[RFC6550]冬、T.、Thubert、P.、Brandt、A.、Hui、J.、Kelsey、R.、Levis、P.、Pister、K.、Struik、R.、Vasseur、JP。、およびR 。Alexander、「RPL：低電力および損失の多いネットワーク用のIPv6ルーティングプロトコル」、RFC 6550、2012年3月。

[RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL)", RFC 6554, March 2012.

[RFC6554] Hui、J.、Vasseur、JP。、Culler、D.、and V. Manral、 "An IPv6 Routing Header for Source Routes with the Routing Protocol for Routing-Power and Lossy Networks（RPL）"、RFC 6554、 2012年3月。

[RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and J. Martocci, "Reactive Discovery of Point-to-Point Routes in Low-Power and Lossy Networks", RFC 6997, August 2013.

[RFC6997] Goyal、M.、Ed。、Baccelli、E.、Philipp、M.、Brandt、A。、およびJ. Martocci、「低電力および損失の多いネットワークにおけるポイントツーポイントルートのリアクティブディスカバリ」、 RFC 6997、2013年8月。

11.2. Informative References

11.2. 参考引用

[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation of Type 0 Routing Headers in IPv6", RFC 5095, December 2007.

[RFC5095] Abley、J.、Savola、P。、およびG. Neville-Neil、「Deprecation of Type 0 Routing Headers in IPv6」、RFC 5095、2007年12月。

[RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation Routing Requirements in Low-Power and Lossy Networks", RFC 5826, April 2010.

[RFC5826] Brandt、A.、Buron、J。、およびG. Porcu、「低電力および損失の多いネットワークにおけるホームオートメーションルーティング要件」、RFC 5826、2010年4月。

[RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, "Building Automation Routing Requirements in Low-Power and Lossy Networks", RFC 5867, June 2010.

[RFC5867] Martocci、J.、De Mil、P.、Riou、N。、およびW. Vermeylen、「Building Automation Routing Requirements in Low-Power and Lossy Networks」、RFC 5867、2010年6月。

[RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D. Barthel, "Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks", RFC 6551, March 2012.

[RFC6551] Vasseur、JP。、Kim、M.、Pister、K.、Dejean、N。、およびD. Barthel、「低電力および損失の多いネットワークでのパス計算に使用されるルーティングメトリック」、RFC 6551、2012年3月。

[ROLL-TERMS] Vasseur, JP., "Terminology in Low power And Lossy Networks", Work in Progress, March 2013.

[ロール用語] Vasseur、JP、「低電力および損失の多いネットワークの用語」、作業中、2013年3月。

Authors' Addresses

著者のアドレス

Mukul Goyal (editor) University of Wisconsin Milwaukee 3200 N. Cramer St. Milwaukee, WI 53201 USA

Mukul Goyal（編集者）ウィスコンシン大学ミルウォーキー3200 N. Cramer St.ミルウォーキー、WI 53201米国

   Phone: +1-414-229-5001
   EMail: mukul@uwm.edu

Emmanuel Baccelli INRIA

エマニュエルバチェリINRIA

   Phone: +33-169-335-511
   EMail: Emmanuel.Baccelli@inria.fr
   URI:   http://www.emmanuelbaccelli.org/

Anders Brandt Sigma Designs Emdrupvej 26A, 1. Copenhagen, Dk-2100 Denmark

Anders Brandt Sigma Designs Emdrupvej 26A、1. Copenhagen、Dk-2100 Denmark

   Phone: +45-29609501
   EMail: abr@sdesigns.dk

Jerald Martocci Johnson Controls 507 E. Michigan Street Milwaukee, WI 53202 USA

じぇらｌｄまｒとっしじょｈんそんこんｔろｌｓ５０７え。みちがんＳｔれえｔみゎうけえ、うぃ５３２０２うさ

   Phone: +1-414-524-4010
   EMail: jerald.p.martocci@jci.com

RFC 6998 - A Mechanism to Measure the Routing Metrics along a Point-to-Point Route in a Low-Power and Lossy Network 日本語訳

1. Introduction

1. はじめに

1.1. Terminology

1.1. 用語

2. Overview

2. 概観

3. The Measurement Object (MO)

3. 測定オブジェクト（MO）

3.1. Format of the Base MO

3.1. ベースMOのフォーマット

3.2. Secure MO

3.2. せくれ も

4. Originating a Measurement Request

4. 測定要求の発信

4.1. When Measuring a Hop-by-Hop Route with a Global RPLInstanceID

4.1. グローバルRPLInstanceIDを使用してホップバイホップルートを測定する場合

4.4. When Measuring a Source Route

4.4. ソースルートを測定するとき

5. Processing a Measurement Request at an Intermediate Point

5. 中間点での測定要求の処理

5.1. When Measuring a Hop-by-Hop Route with a Global RPLInstanceID

5.1. グローバルRPLInstanceIDを使用してホップバイホップルートを測定する場合

5.4. When Measuring a Source Route

5.4. ソースルートを測定するとき

5.5. Final Processing

5.5. 最終処理

6. Processing a Measurement Request at the End Point

6. エンドポイントでの測定リクエストの処理

6.1. Generating the Measurement Reply

6.1. 測定応答の生成

7. Processing a Measurement Reply at the Start Point

7. 開始点での測定応答の処理

8. Security Considerations

8. セキュリティに関する考慮事項

9. IANA Considerations

9. IANAに関する考慮事項

10. Acknowledgements

10. 謝辞

11. References

11. 参考文献

11.1. Normative References

11.1. 引用文献

11.2. Informative References

11.2. 参考引用

3.2. せくれも