[要約] RFC 8180は、6TiSCH（IPv6 over the TSCH Mode of IEEE 802.15.4e）の設定に関する要件を定義しています。このRFCの目的は、IPv6を使用してIEEE 802.15.4eのTSCHモードで通信するための最小限の設定を提供することです。
Internet Engineering Task Force (IETF) X. Vilajosana, Ed.
Request for Comments: 8180 Universitat Oberta de Catalunya
BCP: 210 K. Pister
Category: Best Current Practice University of California Berkeley
ISSN: 2070-1721 T. Watteyne
Analog Devices
May 2017
Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration
IEEE 802.15.4e（6TiSCH）構成のTSCHモードでの最小限のIPv6
Abstract
概要
This document describes a minimal mode of operation for an IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH) network. This minimal mode of operation specifies the baseline set of protocols that need to be supported and the recommended configurations and modes of operation sufficient to enable a 6TiSCH functional network. 6TiSCH provides IPv6 connectivity over a Time-Slotted Channel Hopping (TSCH) mesh composed of IEEE Std 802.15.4 TSCH links. This minimal mode uses a collection of protocols with the respective configurations, including the IPv6 Low-Power Wireless Personal Area Network (6LoWPAN) framework, enabling interoperable IPv6 connectivity over IEEE Std 802.15.4 TSCH. This minimal configuration provides the necessary bandwidth for network and security bootstrapping and defines the proper link between the IETF protocols that interface to IEEE Std 802.15.4 TSCH. This minimal mode of operation should be implemented by all 6TiSCH-compliant devices.
このドキュメントでは、IEEE 802.15.4e（6TiSCH）ネットワークのTSCHモードでのIPv6の最小動作モードについて説明します。この最小動作モードは、サポートする必要があるプロトコルのベースラインセットと、6TiSCH機能ネットワークを有効にするのに十分な推奨構成と動作モードを指定します。 6TiSCHは、IEEE Std 802.15.4 TSCHリンクで構成されるタイムスロットチャネルホッピング（TSCH）メッシュを介したIPv6接続を提供します。この最小モードは、IPv6低電力ワイヤレスパーソナルエリアネットワーク（6LoWPAN）フレームワークを含む、それぞれの構成を持つプロトコルのコレクションを使用し、IEEE Std 802.15.4 TSCHを介した相互運用可能なIPv6接続を可能にします。この最小限の構成は、ネットワークとセキュリティのブートストラップに必要な帯域幅を提供し、IEEE Std 802.15.4 TSCHにインターフェースするIETFプロトコル間の適切なリンクを定義します。この最小動作モードは、すべての6TiSCH準拠デバイスで実装する必要があります。
Status of This Memo
本文書の状態
This memo documents an Internet Best Current Practice.
このメモは、インターネットの現在のベストプラクティスを文書化したものです。
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 BCPs is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 BCPの詳細については、RFC 7841のセクション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/rfc8180.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8180で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. IEEE Std 802.15.4 Settings . . . . . . . . . . . . . . . . . 5
4.1. TSCH Schedule . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Cell Options . . . . . . . . . . . . . . . . . . . . . . 8
4.3. Retransmissions . . . . . . . . . . . . . . . . . . . . . 8
4.4. Timeslot Timing . . . . . . . . . . . . . . . . . . . . . 8
4.5. Frame Contents . . . . . . . . . . . . . . . . . . . . . 8
4.5.1. IEEE Std 802.15.4 Header . . . . . . . . . . . . . . 8
4.5.2. Enhanced Beacon Frame . . . . . . . . . . . . . . . . 9
4.5.3. Acknowledgment Frame . . . . . . . . . . . . . . . . 10
4.6. Link-Layer Security . . . . . . . . . . . . . . . . . . . 10
5. RPL Settings . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Objective Function . . . . . . . . . . . . . . . . . . . 11
5.1.1. Rank Computation . . . . . . . . . . . . . . . . . . 11
5.1.2. Rank Computation Example . . . . . . . . . . . . . . 13
5.2. Mode of Operation . . . . . . . . . . . . . . . . . . . . 14
5.3. Trickle Timer . . . . . . . . . . . . . . . . . . . . . . 14
5.4. Packet Contents . . . . . . . . . . . . . . . . . . . . . 14
6. Network Formation and Lifetime . . . . . . . . . . . . . . . 14
6.1. Value of the Join Metric Field . . . . . . . . . . . . . 14
6.2. Time-Source Neighbor Selection . . . . . . . . . . . . . 15
6.3. When to Start Sending EBs . . . . . . . . . . . . . . . . 15
6.4. Hysteresis . . . . . . . . . . . . . . . . . . . . . . . 15
7. Implementation Recommendations . . . . . . . . . . . . . . . 16
7.1. Neighbor Table . . . . . . . . . . . . . . . . . . . . . 16
7.2. Queues and Priorities . . . . . . . . . . . . . . . . . . 16
7.3. Recommended Settings . . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 23
A.1. Example: EB with Default Timeslot Template . . . . . . . 23
A.2. Example: EB with Custom Timeslot Template . . . . . . . . 25
A.3. Example: Link-layer Acknowledgment . . . . . . . . . . . 27
A.4. Example: Auxiliary Security Header . . . . . . . . . . . 27
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
A 6TiSCH network provides IPv6 connectivity [RFC2460] over a Time-Slotted Channel Hopping (TSCH) mesh [RFC7554] composed of IEEE Std 802.15.4 TSCH links [IEEE.802.15.4]. IPv6 connectivity is obtained by the use of the 6LoWPAN framework ([RFC4944], [RFC6282], [RFC8025],[RFC8138], and [RFC6775]), RPL [RFC6550], and the RPL Objective Function 0 (OF0) [RFC6552].
6TiSCHネットワークは、IEEE Std 802.15.4 TSCHリンク[IEEE.802.15.4]で構成されるタイムスロットチャネルホッピング（TSCH）メッシュ[RFC7554]を介してIPv6接続[RFC2460]を提供します。 IPv6接続は、6LoWPANフレームワーク（[RFC4944]、[RFC6282]、[RFC8025]、[RFC8138]、および[RFC6775]）、RPL [RFC6550]、およびRPL目的関数0（OF0）[RFC6552 ]。
This specification defines operational parameters and procedures for a minimal mode of operation to build a 6TiSCH network. Any 6TiSCH-compliant device should implement this mode of operation. This operational parameter configuration provides the necessary bandwidth for nodes to bootstrap the network. The bootstrap process includes initial network configuration and security bootstrapping. In this specification, the 802.15.4 TSCH mode, the 6LoWPAN framework, RPL [RFC6550], and the RPL Objective Function 0 (OF0) [RFC6552] are used unmodified. Parameters and particular operations of TSCH are specified to guarantee interoperability between nodes in a 6TiSCH network.
この仕様は、6TiSCHネットワークを構築するための最小動作モードの動作パラメーターと手順を定義しています。 6TiSCH準拠のデバイスはすべて、この動作モードを実装する必要があります。この操作パラメーター構成は、ノードがネットワークをブートストラップするために必要な帯域幅を提供します。ブートストラッププロセスには、初期ネットワーク構成とセキュリティブートストラップが含まれます。この仕様では、802.15.4 TSCHモード、6LoWPANフレームワーク、RPL [RFC6550]、およびRPL目的関数0（OF0）[RFC6552]を変更せずに使用します。 6TiSCHネットワーク内のノード間の相互運用性を保証するために、TSCHのパラメータと特定の操作が指定されています。
In a 6TiSCH network, nodes follow a communication schedule as per 802.15.4 TSCH. Nodes learn the communication schedule upon joining the network. When following this specification, the learned schedule is the same for all nodes and does not change over time. Future specifications may define mechanisms for dynamically managing the communication schedule. Dynamic scheduling solutions are out of scope of this document.
6TiSCHネットワークでは、ノードは802.15.4 TSCHに従って通信スケジュールに従います。ノードは、ネットワークに参加すると通信スケジュールを学習します。この仕様に従う場合、学習したスケジュールはすべてのノードで同じであり、時間の経過とともに変化しません。将来の仕様では、通信スケジュールを動的に管理するためのメカニズムが定義される可能性があります。動的スケジューリングソリューションは、このドキュメントの範囲外です。
IPv6 addressing and compression are achieved by the 6LoWPAN framework. The framework includes [RFC4944], [RFC6282], [RFC8025], the 6LoWPAN Routing Header dispatch [RFC8138] for addressing and header compression, and [RFC6775] for Duplicate Address Detection (DAD) and address resolution.
IPv6アドレッシングと圧縮は、6LoWPANフレームワークによって実現されます。フレームワークには、[RFC4944]、[RFC6282]、[RFC8025]、アドレス指定とヘッダー圧縮用の6LoWPANルーティングヘッダーディスパッチ[RFC8138]、重複アドレス検出（DAD）とアドレス解決用の[RFC6775]が含まれています。
More advanced work is expected in the future to complement the minimal configuration with dynamic operations that can adapt the schedule to the needs of the traffic at run time.
将来的には、実行時のトラフィックのニーズにスケジュールを適合させることができる動的な操作で最小限の構成を補完する、より高度な作業が期待されます。
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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
This document uses terminology from [TERMS-6TiSCH]. The following concepts are used in this document:
このドキュメントでは、[TERMS-6TiSCH]の用語を使用しています。このドキュメントでは、次の概念が使用されています。
802.15.4: We use "802.15.4" as a short version of "IEEE Std 802.15.4" in this document.
802.15.4：このドキュメントでは、「IEEE Std 802.15.4」の短縮版として「802.15.4」を使用しています。
SFD: Start of Frame Delimiter
SFD：フレーム区切りの開始
RX: Reception
RX：レセプション
TX: Transmission
TX：送信
IE: Information Element
IE：情報要素
EB: Enhanced Beacon
EB：拡張ビーコン
ASN: Absolute Slot Number
ASN：絶対スロット番号
Join Metric: Field in the TSCH Synchronization IE representing the topological distance between the node sending the EB and the PAN coordinator.
結合メトリック：EBを送信するノードとPANコーディネーター間のトポロジー距離を表すTSCH Synchronization IEのフィールド。
PAN: Personal Area Network
PAN：パーソナルエリアネットワーク
MLME: MAC Layer Management Entity
MLME：MACレイヤー管理エンティティ
An implementation compliant with this specification MUST implement IEEE Std 802.15.4 [IEEE.802.15.4] in Time-Slotted Channel Hopping (TSCH) mode.
この仕様に準拠した実装は、IEEE Std 802.15.4 [IEEE.802.15.4]をタイムスロットチャネルホッピング（TSCH）モードで実装する必要があります。
The remainder of this section details the RECOMMENDED TSCH settings, which are summarized in Figure 1. Any of the properties marked in the EB column are announced in the EBs the nodes send [IEEE.802.15.4] and learned by those joining the network. Changing their value means changing the contents of the EB.
このセクションの残りの部分では、図1に要約されている推奨TSCH設定について詳しく説明します。EB列にマークされているプロパティは、ノードが送信するEBでアナウンスされ[IEEE.802.15.4]、ネットワークに参加するEBによって学習されます。それらの値を変更することは、EBの内容を変更することを意味します。
In case of discrepancy between the values in this specification and IEEE Std 802.15.4 [IEEE.802.15.4], the IEEE standard has precedence.
この仕様とIEEE Std 802.15.4 [IEEE.802.15.4]の値が一致しない場合は、IEEE標準が優先されます。
+--------------------------------+------------------------------+---+
| Property | Recommended Setting |EB*|
+--------------------------------+------------------------------+---+
| Slotframe Size | Tunable. Trades off | X |
| | bandwidth against energy. | |
+--------------------------------+------------------------------+---+
| Number of scheduled cells** | 1 | X |
| (active) | Timeslot 0x0000 | |
| | Channel Offset 0x0000 | |
| | Link Options = (TX Link = 1, | |
| | RX Link = 1, Shared Link = 1,| |
| | Timekeeping = 1) | |
+--------------------------------+------------------------------+---+
| Number of unscheduled cells | All remaining cells in the | X |
| (off) | slotframe. | |
+--------------------------------+------------------------------+---+
| Max Number MAC retransmissions | 3 (4 transmission attempts) | |
+--------------------------------+------------------------------+---+
| Timeslot template | IEEE Std 802.15.4 default | X |
| | (macTimeslotTemplateId=0) | |
+--------------------------------+------------------------------+---+
| Enhanced Beacon Period | Tunable. Trades off join | |
| (EB_PERIOD) | time against energy. | |
+--------------------------------+------------------------------+---+
| Number used frequencies | IEEE Std 802.15.4 default | X |
| (2.4 GHz O-QPSK PHY) | (16) | |
+--------------------------------+------------------------------+---+
| Channel Hopping sequence | IEEE Std 802.15.4 default | X |
| (2.4 GHz O-QPSK PHY) | (macHoppingSequenceID = 0) | |
+--------------------------------+------------------------------+---+
* An "X" in this column means this property's value is announced
in the EB; hence, a new node learns it when joining.
** This cell LinkType is set to ADVERTISING.
Figure 1: Recommended IEEE Std 802.15.4 TSCH Settings
図1：推奨されるIEEE Std 802.15.4 TSCH設定
This minimal mode of operation uses a single slotframe. The TSCH slotframe is composed of a tunable number of timeslots. The slotframe size (i.e., the number of timeslots it contains) trades off bandwidth for energy consumption. The slotframe size needs to be tuned; the way of tuning it is out of scope of this specification. The slotframe size is announced in the EB. The RECOMMENDED value for the slotframe handle (macSlotframeHandle) is 0x00. An implementation MAY choose to use a different slotframe handle, for example, to add other slotframes with higher priority. The use of other slotframes is out of the scope of this document.
この最小動作モードでは、単一のスロットフレームを使用します。 TSCHスロットフレームは、調整可能な数のタイムスロットで構成されています。スロットフレームのサイズ（つまり、スロットフレームに含まれるタイムスロットの数）は、エネルギー消費と帯域幅のトレードオフです。スロットフレームのサイズを調整する必要があります。チューニングの方法はこの仕様の範囲外です。スロットフレームサイズはEBで発表されています。スロットフレームハンドル（macSlotframeHandle）の推奨値は0x00です。実装は、たとえば、より高い優先度を持つ他のスロットフレームを追加するために、別のスロットフレームハンドルを使用することを選択できます。他のスロットフレームの使用は、このドキュメントの範囲外です。
There is only a single scheduled cell in the slotframe. This cell MAY be scheduled at any slotOffset/channelOffset within the slotframe. The location of that cell in the schedule is announced in the EB. The LinkType of the scheduled cell is ADVERTISING to allow EBs to be sent on it.
スロットフレームには、スケジュールされたセルが1つだけあります。このセルは、スロットフレーム内の任意のslotOffset / channelOffsetでスケジュールできます。スケジュール内のそのセルの場所は、EBで発表されます。スケジュールされたセルのLinkTypeは、EBを送信できるようにするADVERTISINGです。
Figure 2 shows an example of a slotframe of length 101 timeslots, resulting in a radio duty cycle below 0.99%.
図2は、長さが101タイムスロットのスロットフレームの例を示しています。その結果、0.99％未満の無線デューティサイクルになります。
Chan. +----------+----------+ +----------+
Off.0 | TxRxS/EB | OFF | | OFF |
Chan. +----------+----------+ +----------+
Off.1 | OFF | OFF | ... | OFF |
+----------+----------+ +----------+
.
.
.
Chan. +----------+----------+ +----------+
Off.15 | OFF | OFF | | OFF |
+----------+----------+ +----------+
slotOffset 0 1 100
slotOffset 0 1 100
EB: Enhanced Beacon Tx: Transmit Rx: Receive S: Shared OFF: Unscheduled by this specification
EB：拡張ビーコンTx：送信Rx：受信S：共有OFF：この仕様により予定外
Figure 2: Example Slotframe of Length 101 Timeslots
図2：長さ101タイムスロットのスロットフレームの例
A node MAY use the scheduled cell to transmit/receive all types of link-layer frames. EBs are sent to the link-layer broadcast address and are not acknowledged. Data frames are sent unicast and are acknowledged by the receiving neighbor.
ノードは、スケジュールされたセルを使用して、すべてのタイプのリンク層フレームを送受信できます。 EBはリンク層ブロードキャストアドレスに送信され、確認されません。データフレームはユニキャストで送信され、受信ネイバーによって確認されます。
All remaining cells in the slotframe are unscheduled. Dynamic scheduling solutions may be defined in the future that schedule those cells. One example is the 6top Protocol (6P) [PROTO-6P]. Dynamic scheduling solutions are out of scope of this document.
スロットフレームの残りのすべてのセルはスケジュールされていません。これらのセルをスケジュールする動的スケジューリングソリューションが将来定義される可能性があります。 1つの例は6topプロトコル（6P）[PROTO-6P]です。動的スケジューリングソリューションは、このドキュメントの範囲外です。
The default values of the TSCH timeslot template (defined in Section 8.4.2.2.3 of [IEEE.802.15.4]) and channel hopping sequence (defined in Section 6.2.10 of [IEEE.802.15.4]) SHOULD be used. A node MAY use different values by properly announcing them in its EB.
TSCHタイムスロットテンプレート（[IEEE.802.15.4]のセクション8.4.2.2.3で定義）とチャネルホッピングシーケンス（[IEEE.802.15.4]のセクション6.2.10で定義）のデフォルト値を使用する必要があります。ノードは、EBで適切に通知することにより、異なる値を使用できます。
In the scheduled cell, a node transmits if there is a packet to transmit and listens otherwise (both "TX" and "RX" bits are set). When a node transmits, requesting a link-layer acknowledgment per [IEEE.802.15.4], and does not receive the requested acknowledgement, it uses a back-off mechanism to resolve possible collisions ("Shared" bit is set). A node joining the network maintains time synchronization to its initial time-source neighbor using that cell ("Timekeeping" bit is set).
スケジュールされたセルでは、ノードは送信するパケットがある場合は送信し、そうでない場合はリッスンします（「TX」と「RX」の両方のビットが設定されます）。ノードが送信し、[IEEE.802.15.4]に従ってリンク層確認応答を要求し、要求された確認応答を受信しない場合、ノードはバックオフメカニズムを使用して衝突の可能性を解決します（「共有」ビットが設定されます）。ネットワークに参加しているノードは、そのセルを使用して初期のタイムソースネイバーへの時間同期を維持します（「タイムキーピング」ビットが設定されています）。
This translates into a Link Option for this cell:
これは、このセルのリンクオプションに変換されます。
b0 = TX Link = 1 (set)
b1 = RX Link = 1 (set)
b2 = Shared Link = 1 (set)
b3 = Timekeeping = 1 (set)
b4 = Priority = 0 (clear)
b5-b7 = Reserved = 0 (clear)
Per Figure 1, the RECOMMENDED maximum number of link-layer retransmissions is 3. This means that, for packets requiring an acknowledgment, if none are received after a total of 4 attempts, the transmission is considered failed and the link layer MUST notify the upper layer. Packets not requiring an acknowledgment (including EBs) are not retransmitted.
図1によると、リンク層再送信の推奨最大数は3です。これは、確認を必要とするパケットの場合、合計4回の試行後に何も受信されない場合、送信は失敗したと見なされ、リンク層は上位に通知する必要があることを意味します層。確認応答を必要としないパケット（EBを含む）は再送信されません。
Per Figure 1, the RECOMMENDED timeslot template is the default one (macTimeslotTemplateId=0) defined in [IEEE.802.15.4].
図1によれば、推奨されるタイムスロットテンプレートは、[IEEE.802.15.4]で定義されているデフォルトのテンプレート（macTimeslotTemplateId = 0）です。
[IEEE.802.15.4] defines the format of frames. Through a set of flags, [IEEE.802.15.4] allows for several fields to be present (or not), to have different lengths, and to have different values. This specification details the RECOMMENDED contents of 802.15.4 frames, while strictly complying with [IEEE.802.15.4].
[IEEE.802.15.4]は、フレームのフォーマットを定義しています。フラグのセットを通じて、[IEEE.802.15.4]は、いくつかのフィールドが存在する（または存在しない）こと、異なる長さを持つこと、および異なる値を持つことを可能にします。この仕様は、[IEEE.802.15.4]に厳密に準拠しながら、802.15.4フレームの推奨コンテンツを詳述しています。
The Frame Version field MUST be set to 0b10 (Frame Version 2). The Sequence Number field MAY be elided.
フレームバージョンフィールドは0b10（フレームバージョン2）に設定する必要があります。シーケンス番号フィールドは省略できます。
The EB Destination Address field MUST be set to 0xFFFF (short broadcast address). The EB Source Address field SHOULD be set as the node's short address if this is supported. Otherwise, the long address MUST be used.
EB宛先アドレスフィールドは、0xFFFF（短いブロードキャストアドレス）に設定する必要があります。 EB Source Addressフィールドは、サポートされている場合、ノードのショートアドレスとして設定する必要があります（SHOULD）。それ以外の場合は、長いアドレスを使用する必要があります。
The PAN ID Compression bit SHOULD indicate that the Source PAN ID is "Not Present" and the Destination PAN ID is "Present". The value of the PAN ID Compression bit is specified in Table 7-2 of the IEEE Std 802.15.4-2015 specification and depends on the type of the destination and source link-layer addresses (e.g., short, extended, not present).
PAN ID圧縮ビットは、ソースPAN IDが「存在しない」であり、宛先PAN IDが「存在する」ことを示す必要があります（SHOULD）。 PAN ID圧縮ビットの値は、IEEE Std 802.15.4-2015仕様の表7-2で指定されており、宛先と送信元のリンク層アドレスのタイプ（たとえば、短い、拡張、存在しない）によって異なります。
Nodes follow the reception and rejection rules as per Section 6.7.2 of [IEEE.802.15.4].
ノードは、[IEEE.802.15.4]のセクション6.7.2に基づく受信と拒否のルールに従います。
The nonce is formatted according to [IEEE.802.15.4]. In the IEEE Std 802.15.4 specification [IEEE.802.15.4], nonce generation is described in Section 9.3.2.2, and byte ordering is described in Section 9.3.1, Annex B.2, and Annex B.2.2.
nonceは[IEEE.802.15.4]に従ってフォーマットされます。 IEEE Std 802.15.4仕様[IEEE.802.15.4]では、ノンスの生成はセクション9.3.2.2で説明されており、バイト順序はセクション9.3.1、付録B.2、および付録B.2.2で説明されています。
After booting, a TSCH node starts in an unsynchronized, unjoined state. Initial synchronization is achieved by listening for EBs. EBs from multiple networks may be heard. Many mechanisms exist for discrimination between networks, the details of which are out of scope.
起動後、TSCHノードは非同期で未参加の状態で起動します。初期同期は、EBをリッスンすることで実現されます。複数のネットワークからのEBが聞こえる場合があります。ネットワーク間の識別には多くのメカニズムが存在しますが、その詳細は範囲外です。
The IEEE Std 802.15.4 specification does not define how often EBs are sent, nor their contents [IEEE.802.15.4]. In a minimal TSCH configuration, a node SHOULD send an EB every EB_PERIOD. Tuning EB_PERIOD allows a trade-off between joining time and energy consumption.
IEEE Std 802.15.4仕様は、EBが送信される頻度とその内容を定義していません[IEEE.802.15.4]。最小限のTSCH構成では、ノードはEB_PERIODごとにEBを送信する必要があります（SHOULD）。 EB_PERIODを調整することで、参加時間とエネルギー消費の間のトレードオフが可能になります。
EBs should be used to obtain information about local networks and to synchronize ASN and time offset of the specific network that the node decides to join. Once joined to a particular network, a node MAY choose to continue to listen for EBs, to gather more information about other networks, for example. During the joining process, before secure connections to time parents have been created, a node MAY maintain synchronization using EBs. [RFC7554] discusses different time synchronization approaches.
EBは、ローカルネットワークに関する情報を取得し、ノードが参加することを決定した特定のネットワークのASNと時間オフセットを同期するために使用する必要があります。特定のネットワークに参加すると、ノードは、EBをリッスンし続けることを選択して、たとえば他のネットワークに関する詳細情報を収集できます。参加プロセス中、時間の親への安全な接続が作成される前に、ノードはEBを使用して同期を維持できます。 [RFC7554]は、さまざまな時間同期アプローチについて説明しています。
The IEEE Std 802.15.4 specification requires EBs to be sent in order to enable nodes to join the network. The EBs SHOULD carry the Information Elements (IEs) listed below [IEEE.802.15.4].
IEEE Std 802.15.4仕様では、ノードがネットワークに参加できるようにするには、EBを送信する必要があります。 EBは、以下にリストされている情報要素（IE）を運ぶ必要があります[IEEE.802.15.4]。
TSCH Synchronization IE: Contains synchronization information such as ASN and Join Metric. The value of the Join Metric field is discussed in Section 6.1.
TSCH Synchronization IE：ASNやJoin Metricなどの同期情報が含まれています。 「結合メトリック」フィールドの値については、セクション6.1で説明します。
TSCH Timeslot IE: Contains the timeslot template identifier. This template is used to specify the internal timing of the timeslot. This specification RECOMMENDS the default timeslot template.
TSCHタイムスロットIE：タイムスロットテンプレート識別子が含まれます。このテンプレートは、タイムスロットの内部タイミングを指定するために使用されます。この仕様は、デフォルトのタイムスロットテンプレートを推奨しています。
Channel Hopping IE: Contains the channel hopping sequence identifier. This specification RECOMMENDS the default channel hopping sequence.
チャネルホッピングIE：チャネルホッピングシーケンス識別子が含まれています。この仕様では、デフォルトのチャネルホッピングシーケンスを推奨しています。
TSCH Slotframe and Link IE: Enables joining nodes to learn the initial schedule to be used as they join the network. This document RECOMMENDS the use of a single cell.
TSCHスロットフレームおよびリンクIE：参加ノードがネットワークに参加するときに使用される初期スケジュールを学習できるようにします。このドキュメントでは、単一のセルの使用を推奨しています。
If a node strictly follows the recommended setting from Figure 1, the EB it sends has the exact same contents as an EB it received when joining, except for the Join Metric field in the TSCH Synchronization IE.
ノードが図1の推奨設定に厳密に従う場合、送信するEBの内容は、TSCH同期IEの[Join Metric]フィールドを除いて、参加時に受信したEBとまったく同じです。
When a node has already joined a network (i.e., it has received an EB) synchronized to the EB sender and configured its schedule following this specification, the node SHOULD ignore subsequent EBs that try to change the configured parameters. This does not preclude listening to EBs from other networks.
ノードがすでにEB送信者に同期されてネットワークに参加している（つまり、EBを受信している）場合、この仕様に従ってスケジュールを構成すると、ノードは、構成されたパラメーターを変更しようとする後続のEBを無視する必要があります（SHOULD）。これは、他のネットワークからのEBのリスニングを排除するものではありません。
Per [IEEE.802.15.4], each acknowledgment contains an ACK/NACK Time Correction IE.
[IEEE.802.15.4]に従い、各確認応答にはACK / NACK Time Correction IEが含まれています。
When securing link-layer frames, link-layer frames MUST be secured by the link-layer security mechanisms defined in IEEE Std 802.15.4 [IEEE.802.15.4]. Link-layer authentication MUST be applied to the entire frame, including the 802.15.4 header. Link-layer encryption MAY be applied to 802.15.4 Payload IEs and the 802.15.4 payload.
リンク層フレームを保護する場合、リンク層フレームは、IEEE Std 802.15.4 [IEEE.802.15.4]で定義されているリンク層セキュリティメカニズムによって保護する必要があります。リンク層認証は、802.15.4ヘッダーを含むフレーム全体に適用する必要があります。リンク層暗号化は、802.15.4ペイロードIEおよび802.15.4ペイロードに適用される場合があります。
This specification assumes the existence of two cryptographic keys:
この仕様では、2つの暗号化キーが存在することを前提としています。
Key K1 is used to authenticate EBs. EBs MUST be authenticated only (no encryption); their contents are defined in Section 4.5.2.
キーK1は、EBの認証に使用されます。 EBは認証のみが必要です（暗号化は不可）。それらの内容はセクション4.5.2で定義されています。
Key K2 is used to authenticate and encrypt DATA and ACKNOWLEDGMENT frames.
キーK2は、DATAフレームとACKNOWLEDGMENTフレームの認証と暗号化に使用されます。
These keys can be pre-configured or learned during a key distribution phase. Key distribution mechanisms are defined, for example, in [SEC-6TISCH] and [SEC-JOIN-6TISCH]. Key distribution is out of scope of this document.
これらのキーは、事前に構成するか、キー配布フェーズで学習できます。鍵配布メカニズムは、たとえば[SEC-6TISCH]および[SEC-JOIN-6TISCH]で定義されています。キーの配布はこのドキュメントの範囲外です。
The behavior of a Joining Node (JN) is different depending on which key(s) are pre-configured:
結合ノード（JN）の動作は、事前設定されているキーによって異なります。
If both keys K1 and K2 are pre-configured, the JN does not rely on a key distribution phase to learn K1 or K2.
キーK1とK2の両方が事前設定されている場合、JNはキー配布フェーズに依存せずにK1またはK2を学習します。
If key K1 is pre-configured but not key K2, the JN authenticates EBs using K1 and relies on the key distribution phase to learn K2.
キーK1が事前構成されているがキーK2は構成されていない場合、JNはK1を使用してEBを認証し、キー配布フェーズに依存してK2を学習します。
If neither key K1 nor key K2 is pre-configured, the JN accepts EBs as defined in Section 6.3.1.2 of IEEE Std 802.15.4 [IEEE.802.15.4], i.e., they are passed forward even "if the status of the unsecuring process indicated an error". The JN then runs the key distribution phase to learn K1 and K2. During that process, the node that JN is talking to uses the secExempt mechanism (see Section 9.2.4 of [IEEE.802.15.4]) to process frames from JN. Once the key distribution phase is done, the node that has installed secExempts for the JN MUST clear the installed exception rules.
キーK1もキーK2も事前設定されていない場合、JNは、IEEE Std 802.15.4 [IEEE.802.15.4]のセクション6.3.1.2で定義されているようにEBを受け入れます。安全でないプロセスはエラーを示しました。」次に、JNはキー配布フェーズを実行してK1とK2を学習します。そのプロセス中に、JNが通信しているノードは、secExemptメカニズム（[IEEE.802.15.4]のセクション9.2.4を参照）を使用してJNからのフレームを処理します。キー配布フェーズが完了すると、JNのsecExemptsをインストールしたノードは、インストールされた例外ルールをクリアする必要があります。
In the event of a network reset, the new network MUST either use new cryptographic keys or ensure that the ASN remains monotonically increasing.
ネットワークがリセットされた場合、新しいネットワークは新しい暗号鍵を使用するか、ASNが単調に増加し続けることを保証する必要があります。
In a multi-hop topology, the RPL routing protocol [RFC6550] MAY be used.
マルチホップトポロジでは、RPLルーティングプロトコル[RFC6550]を使用できます。
If RPL is used, nodes MUST implement the RPL Objective Function Zero (OF0) [RFC6552].
RPLを使用する場合、ノードはRPL目的関数ゼロ（OF0）[RFC6552]を実装する必要があります。
The Rank computation is described in Section 4.1 of [RFC6552]. A node's Rank (see Figure 4 for an example) is computed by the following equations:
ランクの計算は、[RFC6552]のセクション4.1で説明されています。ノードのランク（例については、図4を参照）は、次の方程式で計算されます。
R(N) = R(P) + rank_increment
rank_increment = (Rf*Sp + Sr) * MinHopRankIncrease
Figure 3 lists the OF0 parameter values that MUST be used if RPL is used.
図3に、RPLを使用する場合に使用する必要があるOF0パラメータ値を示します。
+----------------------+-------------------------------------+
| OF0 Parameters | Value |
+----------------------+-------------------------------------+
| Rf | 1 |
+----------------------+-------------------------------------+
| Sp | (3*ETX)-2 |
+----------------------+-------------------------------------+
| Sr | 0 |
+----------------------+-------------------------------------+
| MinHopRankIncrease | DEFAULT_MIN_HOP_RANK_INCREASE (256) |
+----------------------+-------------------------------------+
| MINIMUM_STEP_OF_RANK | 1 |
+----------------------+-------------------------------------+
| MAXIMUM_STEP_OF_RANK | 9 |
+----------------------+-------------------------------------+
| ETX limit to select | 3 |
| a parent | |
+----------------------+-------------------------------------+
Figure 3: OF0 Parameters
図3：OF0パラメータ
The step_of_rank (Sp) uses the Expected Transmission Count (ETX) [RFC6551].
step_of_rank（Sp）はExpected Transmission Count（ETX）[RFC6551]を使用します。
An implementation MUST follow OF0's normalization guidance as discussed in Sections 1 and 4.1 of [RFC6552]. Sp SHOULD be calculated as (3*ETX)-2. The minimum value of Sp (MINIMUM_STEP_OF_RANK) indicates a good quality link. The maximum value of Sp (MAXIMUM_STEP_OF_RANK) indicates a poor quality link. The default value of Sp (DEFAULT_STEP_OF_RANK) indicates an average quality link. Candidate parents with ETX greater than 3 SHOULD NOT be selected. This avoids having ETX values on used links that are larger that the maximum allowed transmission attempts.
[RFC6552]のセクション1および4.1で説明されているように、実装はOF0の正規化ガイダンスに従う必要があります。 Spは（3 * ETX）-2として計算する必要があります。 Spの最小値（MINIMUM_STEP_OF_RANK）は、高品質のリンクを示します。 Spの最大値（MAXIMUM_STEP_OF_RANK）は、低品質のリンクを示します。 Sp（DEFAULT_STEP_OF_RANK）のデフォルト値は、平均品質のリンクを示します。 ETXが3より大きい親候補は選択しないでください。これにより、使用可能なリンクに、許可される最大送信試行回数よりも大きなETX値が設定されるのを回避できます。
This section illustrates the use of OF0 (see Figure 4). We have:
このセクションでは、OF0の使用法を示します（図4を参照）。我々は持っています：
rank_increment = ((3*numTx/numTxAck)-2)*minHopRankIncrease = 512
+-------+
| 0 | R(minHopRankIncrease) = 256
| | DAGRank(R(0)) = 1
+-------+
|
|
+-------+
| 1 | R(1)=R(0) + 512 = 768
| | DAGRank(R(1)) = 3
+-------+
|
|
+-------+
| 2 | R(2)=R(1) + 512 = 1280
| | DAGRank(R(2)) = 5
+-------+
|
|
+-------+
| 3 | R(3)=R(2) + 512 = 1792
| | DAGRank(R(3)) = 7
+-------+
|
|
+-------+
| 4 | R(4)=R(3) + 512 = 2304
| | DAGRank(R(4)) = 9
+-------+
|
|
+-------+
| 5 | R(5)=R(4) + 512 = 2816
| | DAGRank(R(5)) = 11
+-------+
Figure 4: Rank computation example for a 5-hop network where numTx=100 and numTxAck=75 for all links.
図4：すべてのリンクでnumTx = 100およびnumTxAck = 75の5ホップネットワークのランク計算の例
When RPL is used, nodes MUST implement the non-storing mode of operation (see Section 9.7 of [RFC6550]). The storing mode of operation (see Section 9.8 of [RFC6550]) SHOULD be implemented by nodes with enough capabilities. Nodes not implementing RPL MUST join as leaf nodes.
RPLを使用する場合、ノードは非保存動作モードを実装する必要があります（[RFC6550]のセクション9.7を参照）。保存の動作モード（[RFC6550]のセクション9.8を参照）は、十分な機能を持つノードによって実装する必要があります（SHOULD）。 RPLを実装していないノードは、リーフノードとして参加する必要があります。
RPL signaling messages such as DODAG Information Objects (DIOs) are sent using the Trickle algorithm (see Section 8.3.1 of [RFC6550] and Section 4.2 of [RFC6206]). For this specification, the Trickle timer MUST be used with the RPL-defined default values (see Section 8.3.1 of [RFC6550]).
DODAG情報オブジェクト（DIO）などのRPLシグナリングメッセージは、トリクルアルゴリズムを使用して送信されます（[RFC6550]のセクション8.3.1および[RFC6206]のセクション4.2を参照）。この仕様では、トリクルタイマーをRPLで定義されたデフォルト値で使用する必要があります（[RFC6550]のセクション8.3.1を参照）。
RPL information and hop-by-hop extension headers MUST follow [RFC6553] and [RFC6554]. For cases in which the packets formed at the Low-Power and Lossy Network (LLN) need to cross through intermediate routers, these MUST follow the IP-in-IP encapsulation requirement specified by [RFC6282] and [RFC2460]. Routing extension headers such as RPL Packet Information (RPI) [RFC6550] and Source Routing Header (SRH) [RFC6554], and outer IP headers in case of encapsulation, MUST be compressed according to [RFC8138] and [RFC8025].
RPL情報とホップバイホップ拡張ヘッダーは、[RFC6553]と[RFC6554]に続く必要があります。低電力および損失の多いネットワーク（LLN）で形成されたパケットが中間ルーターを通過する必要がある場合、これらは[RFC6282]および[RFC2460]で指定されたIP-in-IPカプセル化要件に従う必要があります。 RPLパケット情報（RPI）[RFC6550]やソースルーティングヘッダー（SRH）[RFC6554]などのルーティング拡張ヘッダー、およびカプセル化の場合の外部IPヘッダーは、[RFC8138]および[RFC8025]に従って圧縮する必要があります。
The Join Metric of the TSCH Synchronization IE in the EB MUST be calculated based on the routing metric of the node, normalized to a value between 0 and 255. A lower value of the Join Metric indicates the node sending the EB is topologically "closer" to the root of the network. A lower value of the Join Metric hence indicates higher preference for a joining node to synchronize to that neighbor.
EB内のTSCH同期IEの結合メトリックは、ノードのルーティングメトリックに基づいて計算されなければならず、0から255の値に正規化されます。結合メトリックの値が小さいほど、EBを送信するノードがトポロジ的に「近い」ことを示しますネットワークのルートに。したがって、Join Metricの値が小さいほど、参加ノードがそのネイバーと同期する優先度が高いことを示します。
In case the network uses RPL, the Join Metric of any node (including the Directed Acyclic Graph (DAG) root) MUST be set to DAGRank(rank)-1. According to Section 5.1.1, DAGRank(rank(0)) = 1. DAGRank(rank(0))-1 = 0 is compliant with 802.15.4's requirement of having the root use Join Metric = 0.
ネットワークがRPLを使用する場合、任意のノード（有向非巡回グラフ（DAG）ルートを含む）の結合メトリックをDAGRank（rank）-1に設定する必要があります。セクション5.1.1によると、DAGRank（rank（0））= 1です。DAGRank（rank（0））-1 = 0は、ルートに結合メトリックを使用させるという802.15.4の要件に準拠しています= 0。
In case the network does not use RPL, the Join Metric value MUST follow the rules specified by [IEEE.802.15.4].
ネットワークがRPLを使用しない場合、Join Metric値は[IEEE.802.15.4]で指定されたルールに従う必要があります。
When a node joins a network, it may hear EBs sent by different nodes already in the network. The decision of which neighbor to synchronize to (e.g., which neighbor becomes the node's initial time-source neighbor) is implementation specific. For example, after having received the first EB, a node MAY listen for at most MAX_EB_DELAY seconds until it has received EBs from NUM_NEIGHBOURS_TO_WAIT distinct neighbors. Recommended values for MAX_EB_DELAY and NUM_NEIGHBOURS_TO_WAIT are defined in Figure 5. When receiving EBs from distinct neighbors, the node MAY use the Join Metric field in each EB to select the initial time-source neighbor, as described in Section 6.3.6 of IEEE Std 802.15.4 [IEEE.802.15.4].
ノードがネットワークに参加すると、ネットワーク内の別のノードから送信されたEBが聞こえる場合があります。どのネイバーと同期するか（たとえば、どのネイバーがノードの最初のタイムソースネイバーになるか）の決定は、実装固有です。たとえば、最初のEBを受信した後、ノードは、NUM_NEIGHBOURS_TO_WAITの異なるネイバーからEBを受信するまで、最大MAX_EB_DELAY秒リッスンできます（MAY）。 MAX_EB_DELAYおよびNUM_NEIGHBOURS_TO_WAITの推奨値は、図5で定義されています。IEEEStd 802.15のセクション6.3.6で説明されているように、ノードは、個別のネイバーからEBを受信するときに、各EBのJoin Metricフィールドを使用して初期タイムソースネイバーを選択できます。 .4 [IEEE.802.15.4]。
At any time, a node MUST maintain synchronization to at least one time-source neighbor. A node's time-source neighbor MUST be chosen among the neighbors in its RPL routing parent set when RPL is used. In the case a node cannot maintain connectivity to at least one time-source neighbor, the node looses synchronization and needs to join the network again.
いつでも、ノードは少なくとも1つのタイムソースネイバーとの同期を維持する必要があります。 RPLを使用する場合、ノードのタイムソースネイバーは、そのRPLルーティング親セットのネイバーから選択する必要があります。ノードが少なくとも1つのタイムソースネイバーへの接続を維持できない場合、ノードは同期を失い、ネットワークに再び参加する必要があります。
When a RPL node joins the network, it MUST NOT send EBs before having acquired a RPL Rank to avoid inconsistencies in the time synchronization structure. This applies to other routing protocols with their corresponding routing metrics. As soon as a node acquires routing information (e.g., a RPL Rank, see Section 5.1.1), it SHOULD start sending EBs.
RPLノードがネットワークに参加するとき、時間同期構造の不整合を回避するために、RPLランクを取得する前にEBを送信してはなりません（MUST NOT）。これは、対応するルーティングメトリックを持つ他のルーティングプロトコルに適用されます。ノードがルーティング情報（RPLランクなど、セクション5.1.1を参照）を取得するとすぐに、EBの送信を開始する必要があります（SHOULD）。
Per [RFC6552] and [RFC6719], the specification RECOMMENDS the use of a boundary value (PARENT_SWITCH_THRESHOLD) to avoid constant changes of the parent when ranks are compared. When evaluating a parent that belongs to a smaller path cost than the current minimum path, the candidate node is selected as the new parent only if the difference between the new path and the current path is greater than the defined PARENT_SWITCH_THRESHOLD. Otherwise, the node MAY continue to use the current preferred parent. Per [RFC6719], the PARENT_SWITCH_THRESHOLD SHOULD be set to 192 when the ETX metric is used (in the form 128*ETX); the recommendation for this document is to use PARENT_SWITCH_THRESHOLD equal to 640 if the metric being used is ((3*ETX)-2)*minHopRankIncrease or a proportional value. This deals with hysteresis both for routing parent and time-source neighbor selection.
[RFC6552]と[RFC6719]によると、仕様は、ランクを比較するときに親の定数の変更を避けるために境界値（PARENT_SWITCH_THRESHOLD）の使用を推奨しています。現在の最小パスよりも小さいパスコストに属する親を評価する場合、新しいパスと現在のパスの差が定義されたPARENT_SWITCH_THRESHOLDより大きい場合にのみ、候補ノードが新しい親として選択されます。それ以外の場合、ノードは現在の優先される親を引き続き使用できます。 [RFC6719]に従い、ETXメトリックが（128 * ETXの形式で）使用される場合、PARENT_SWITCH_THRESHOLDを192に設定する必要があります（SHOULD）。このドキュメントの推奨事項は、使用されているメトリックが（（3 * ETX）-2）* minHopRankIncreaseまたは比例値である場合、640に等しいPARENT_SWITCH_THRESHOLDを使用することです。これは、ルーティングの親とタイムソースのネイバー選択の両方のヒステリシスを扱います。
The exact format of the neighbor table is implementation specific. The RECOMMENDED per-neighbor information is (taken from the [openwsn] implementation):
ネイバーテーブルの正確な形式は、実装によって異なります。近隣ごとの推奨情報は（[openwsn]実装から取得）：
identifier: Identifier(s) of the neighbor (e.g., EUI-64).
identifier：ネイバーの識別子（EUI-64など）。
numTx: Number of link-layer transmission attempts to that neighbor.
numTx：そのネイバーへのリンク層送信試行の数。
numTxAck: Number of transmitted link-layer frames that have been link-layer acknowledged by that neighbor.
numTxAck：そのネイバーによってリンク層が確認応答された送信済みリンク層フレームの数。
numRx: Number of link-layer frames received from that neighbor.
numRx：そのネイバーから受信したリンク層フレームの数。
timestamp: When the last frame was received from that neighbor. This can be based on the ASN counter or any other time base. It can be used to trigger a keep-alive message.
タイムスタンプ：そのネイバーから最後のフレームが受信されたとき。これは、ASNカウンターまたはその他のタイムベースに基づくことができます。キープアライブメッセージをトリガーするために使用できます。
routing metric: The RPL Rank of that neighbor, for example.
ルーティングメトリック：たとえば、そのネイバーのRPLランク。
time-source neighbor: A flag indicating whether this neighbor is a time-source neighbor.
time-source neighbor：このネイバーがtime-sourceネイバーであるかどうかを示すフラグ。
The IEEE Std 802.15.4 specification [IEEE.802.15.4] does not define the use of queues to handle upper-layer data (either application or control data from upper layers). The following rules are RECOMMENDED:
IEEE Std 802.15.4仕様[IEEE.802.15.4]は、上位層データ（アプリケーションまたは上位層からの制御データ）を処理するためのキューの使用を定義していません。以下のルールが推奨されます：
A node is configured to keep in the queues a configurable number of upper-layer packets per link (default NUM_UPPERLAYER_PACKETS) for a configurable time that should cover the join process (default MAX_JOIN_TIME).
ノードは、結合プロセスをカバーする必要がある構成可能な時間（デフォルトはMAX_JOIN_TIME）の間、リンクごとに構成可能な数の上位層パケット（デフォルトはNUM_UPPERLAYER_PACKETS）をキューに保持するように構成されます。
Frames generated by the 802.15.4 layer (including EBs) are queued with a priority higher than frames coming from higher layers.
802.15.4レイヤー（EBを含む）によって生成されたフレームは、上位レイヤーからのフレームよりも高い優先度でキューに入れられます。
A frame type BEACON is queued with higher priority than frame types DATA.
フレームタイプBEACONは、フレームタイプDATAよりも高い優先度でキューに入れられます。
Figure 5 lists RECOMMENDED values for the settings discussed in this specification.
図5は、この仕様で説明されている設定の推奨値を示しています。
+-------------------------+-------------------+
| Parameter | RECOMMENDED Value |
+-------------------------+-------------------+
| MAX_EB_DELAY | 180 |
+-------------------------+-------------------+
| NUM_NEIGHBOURS_TO_WAIT | 2 |
+-------------------------+-------------------+
| PARENT_SWITCH_THRESHOLD | 640 |
+-------------------------+-------------------+
| NUM_UPPERLAYER_PACKETS | 1 |
+-------------------------+-------------------+
| MAX_JOIN_TIME | 300 |
+-------------------------+-------------------+
Figure 5: Recommended Settings
図5：推奨設定
This document is concerned only with link-layer security.
このドキュメントは、リンク層のセキュリティにのみ関係しています。
By their nature, many Internet of Things (IoT) networks have nodes in physically vulnerable locations. We should assume that nodes will be physically compromised, their memories examined, and their keys extracted. Fixed secrets will not remain secret. This impacts the node-joining process. Provisioning a network with a fixed link key K2 is not secure. For most applications, this implies that there will be a joining phase during which some level of authorization will be allowed for nodes that have not been authenticated. Details are out of scope, but the link layer must provide some flexibility here.
その性質上、多くのモノのインターネット（IoT）ネットワークには、物理的に脆弱な場所にノードがあります。ノードが物理的に危険にさらされ、それらのメモリが調査され、それらのキーが抽出されると想定する必要があります。固定された秘密は秘密のままではありません。これはノード参加プロセスに影響します。固定リンクキーK2でネットワークをプロビジョニングすることは安全ではありません。ほとんどのアプリケーションの場合、これは、認証されていないノードに対して許可の一部のレベルが許可される参加フェーズがあることを意味します。詳細は範囲外ですが、リンク層はここである程度の柔軟性を提供する必要があります。
If an attacker has obtained K1, it can generate fake EBs to attack a whole network by sending authenticated EBs. The attacker can cause the joining node to initiate the joining process to the attacker. In the case that the joining process includes authentication and distribution of a K2, then the joining process will fail and the JN will notice the attack. If K2 is also compromised, the JN will not notice the attack and the network will be compromised.
攻撃者がK1を取得した場合、認証されたEBを送信することにより、偽のEBを生成してネットワーク全体を攻撃できます。攻撃者は、参加ノードに攻撃者への参加プロセスを開始させることができます。参加プロセスに認証とK2の配布が含まれている場合、参加プロセスは失敗し、JNが攻撃に気づきます。 K2も侵害された場合、JNは攻撃に気付かず、ネットワークが侵害されます。
Even if an attacker does not know the value of K1 and K2 (Section 4.6), it can still generate fake EB frames authenticated with an arbitrary key. Here we discuss the impact these fake EBs can have, depending on what key(s) are pre-provisioned.
攻撃者がK1およびK2（セクション4.6）の値を知らなくても、任意のキーで認証された偽のEBフレームを生成する可能性があります。ここでは、事前にプロビジョニングされているキーに応じて、これらの偽のEBが及ぼす影響について説明します。
If both K1 and K2 are pre-provisioned; a joining node can distinguish legitimate from fake EBs and join the legitimate network. The fake EBs have no impact.
K1とK2の両方が事前にプロビジョニングされている場合。参加ノードは、正当なEBと偽のEBを区別し、正当なネットワークに参加できます。偽のEBは影響を与えません。
The same holds if K1 is pre-provisioned but not K2.
K1が事前にプロビジョニングされているがK2がプロビジョニングされていない場合も同様です。
If neither K1 nor K2 is pre-provisioned, a joining node may mistake a fake EB for a legitimate one and initiate a joining process to the attacker. That joining process will fail, as the joining node will not be able to authenticate the attacker during the security handshake. This will force the joining node to start over listening for an EB. So while the joining node never joins the attacker, this costs the joining node time and energy and is a vector of attack.
K1もK2も事前プロビジョニングされていない場合、参加ノードは偽のEBを正当なEBと間違え、攻撃者への参加プロセスを開始する可能性があります。参加ノードはセキュリティハンドシェイク中に攻撃者を認証できないため、その参加プロセスは失敗します。これにより、参加ノードがEBのリッスンを最初からやり直すようになります。そのため、参加ノードが攻撃者に参加することはありませんが、これは参加ノードの時間とエネルギーを消費し、攻撃の媒介となります。
Choosing what key(s) to pre-provision needs to balance the different discussions above.
事前プロビジョニングするキーを選択することで、上記のさまざまな議論のバランスをとる必要があります。
Once the joining process is over, the node that has joined can authenticate EBs (it knows K1). This means it can process their contents and use EBs for synchronization.
参加プロセスが終了すると、参加したノードはEBを認証できます（K1を認識しています）。つまり、コンテンツを処理し、同期にEBを使用できます。
ASN provides a nonce for security operations in a slot. Any re-use of ASN with a given key exposes information about encrypted packet contents and risks replay attacks. Replay attacks are prevented because, when the network resets, either the new network uses new cryptographic key(s) or ensures that the ASN increases monotonically (Section 4.6).
ASNはスロットでのセキュリティ操作にナンスを提供します。特定のキーでASNを再利用すると、暗号化されたパケットの内容に関する情報が公開され、リプレイアタックの危険性があります。ネットワークがリセットされると、新しいネットワークが新しい暗号化キーを使用するか、ASNが確実に単調に増加するため（セクション4.6）、リプレイ攻撃が防止されます。
Maintaining accurate time synchronization is critical for network operation. Accepting timing information from unsecured sources MUST be avoided during normal network operation, as described in Section 4.5.2. During joining, a node may be susceptible to timing attacks before key K1 and K2 are learned. During network operation, a node MAY maintain statistics on time updates from neighbors and monitor for anomalies.
正確な時刻同期を維持することは、ネットワーク操作にとって重要です。セクション4.5.2で説明されているように、セキュリティ保護されていないソースからのタイミング情報の受け入れは、通常のネットワーク操作中は回避する必要があります。参加中、キーK1とK2が学習される前に、ノードがタイミング攻撃の影響を受ける可能性があります。ネットワーク操作中、ノードはネイバーからの時間更新に関する統計を維持し、異常を監視してもよい（MAY）。
Denial-of-Service (DoS) attacks at the Media Access Control (MAC) layer in an LLN are easy to achieve simply by Radio Frequency (RF) jamming. This is the base case against which more sophisticated DoS attacks should be judged. For example, sending fake EBs announcing a very low Join Metric may cause a node to waste time and energy trying to join a fake network even when legitimate EBs are being heard. Proper join security will prevent the node from joining the false flag, but by then the time and energy will have been wasted. However, the energy cost to the attacker would be lower and the energy cost to the joining node would be higher if the attacker simply sent loud short packets in the middle of any valid EB that it hears.
LLNのメディアアクセスコントロール（MAC）層でのサービス拒否（DoS）攻撃は、無線周波数（RF）妨害によって簡単に達成できます。これは、より高度なDoS攻撃を判断する基本的なケースです。たとえば、非常に低いJoinメトリックを通知する偽のEBを送信すると、正当なEBが聞こえている場合でも、ノードが偽のネットワークに参加しようとして時間とエネルギーを浪費する可能性があります。適切な結合セキュリティは、ノードが誤ったフラグに結合するのを防ぎますが、それまでに時間とエネルギーが浪費されます。ただし、攻撃者が聞く有効なEBの真ん中に大きな短いパケットを送信しただけの場合、攻撃者へのエネルギーコストは低くなり、参加ノードへのエネルギーコストは高くなります。
ACK reception probability is less than 100% due to changing channel conditions and unintentional or intentional jamming. This will cause the sending node to retransmit the same packet until it is acknowledged or a retransmission limit is reached. Upper-layer protocols should take this into account, possibly using a sequence number to match retransmissions.
チャネル状態の変化と意図的または意図的な妨害のため、ACK受信確率は100％未満です。これにより、送信ノードは、確認されるか、再送信の制限に達するまで、同じパケットを再送信します。上位層のプロトコルでは、これを考慮に入れる必要があります。シーケンス番号を使用して、再送信を照合する可能性があります。
The 6TiSCH layer SHOULD keep track of anomalous events and report them to a higher authority. For example, EBs reporting low Join Metrics for networks that cannot be joined, as described above, may be a sign of attack. Additionally, in normal network operation, message integrity check failures on packets with a valid Cyclic Redundancy Check (CRC) will occur at a rate on the order of once per million packets. Any significant deviation from this rate may be a sign of a network attack. Along the same lines, time updates in ACKs or EBs that are inconsistent with the MAC-layer's sense of time and its own plausible time-error drift rate may also be a result of network attack.
6TiSCHレイヤーは、異常なイベントを追跡し、それらを上位の機関に報告する必要があります（SHOULD）。たとえば、前述のように、結合できないネットワークの結合メトリックが低いことを報告するEBは、攻撃の兆候である可能性があります。さらに、通常のネットワーク操作では、有効な巡回冗長検査（CRC）を持つパケットのメッセージ整合性チェックの失敗は、100万パケットに1回程度の割合で発生します。この速度からの大幅な逸脱は、ネットワーク攻撃の兆候である可能性があります。同じように、MAC層の時間感覚と一致しないACKまたはEBの時間更新と、それ自体の考えられる時間誤差ドリフト率も、ネットワーク攻撃の結果である可能性があります。
This document does not require any IANA actions.
このドキュメントでは、IANAアクションは必要ありません。
[IEEE.802.15.4] IEEE, "IEEE Standard for Low-Rate Wireless Networks", IEEE 802.15.4, <http://ieeexplore.ieee.org/document/7460875/>.
[IEEE.802.15.4] IEEE、「IEEE Standard for Low-Rate Wireless Networks」、IEEE 802.15.4、<http://ieeexplore.ieee.org/document/7460875/>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、DOI 10.17487 / RFC2460、1998年12月、<http://www.rfc-editor.org/info/ rfc2460>。
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, <http://www.rfc-editor.org/info/rfc4944>.
[RFC4944]モンテネグロ、G。、クシャルナガル、N。、ホイ、J。、およびD.クララー、「IEEE 802.15.4ネットワークを介したIPv6パケットの送信」、RFC 4944、DOI 10.17487 / RFC4944、2007年9月、<http： //www.rfc-editor.org/info/rfc4944>。
[RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206, March 2011, <http://www.rfc-editor.org/info/rfc6206>.
[RFC6206] Levis、P.、Clauseen、T.、Hui、J.、Gnawali、O。、およびJ. Ko、「The Trickle Algorithm」、RFC 6206、DOI 10.17487 / RFC6206、2011年3月、<http：// www.rfc-editor.org/info/rfc6206>。
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, DOI 10.17487/RFC6282, September 2011, <http://www.rfc-editor.org/info/rfc6282>.
[RFC6282]ホイ、J、エド。およびP. Thubert、「IEEE 802.15.4ベースのネットワーク上のIPv6データグラムの圧縮形式」、RFC 6282、DOI 10.17487 / RFC6282、2011年9月、<http://www.rfc-editor.org/info/rfc6282>。
[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, DOI 10.17487/RFC6550, March 2012, <http://www.rfc-editor.org/info/rfc6550>.
[RFC6550]冬、T。、編、Thubert、P。、編、Brandt、A。、ホイ、J。、ケルシー、R。、リーバイス、P。、ピスター、K。、ストルーク、R。、ヴァッサー、JP、およびR.アレクサンダー、「RPL：低電力および損失の多いネットワーク用のIPv6ルーティングプロトコル」、RFC 6550、DOI 10.17487 / RFC6550、2012年3月、<http://www.rfc-editor.org/info/ rfc6550>。
[RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., and D. Barthel, "Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks", RFC 6551, DOI 10.17487/RFC6551, March 2012, <http://www.rfc-editor.org/info/rfc6551>.
[RFC6551] Vasseur、JP。、Ed。、Kim、M.、Ed。、Pister、K.、Dejean、N.、and D. Barthel、 "Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks"、 RFC 6551、DOI 10.17487 / RFC6551、2012年3月、<http://www.rfc-editor.org/info/rfc6551>。
[RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL)", RFC 6552, DOI 10.17487/RFC6552, March 2012, <http://www.rfc-editor.org/info/rfc6552>.
[RFC6552] Thubert、P。、編、「低電力および損失の多いネットワーク（RPL）のルーティングプロトコルの目的関数ゼロ」、RFC 6552、DOI 10.17487 / RFC6552、2012年3月、<http：//www.rfc -editor.org/info/rfc6552>。
[RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams", RFC 6553, DOI 10.17487/RFC6553, March 2012, <http://www.rfc-editor.org/info/rfc6553>.
[RFC6553] Hui、J.、JP。 Vasseur、「データプレーンデータグラムでRPL情報を伝送するための低電力および損失の多いネットワーク（RPL）オプションのルーティングプロトコル」、RFC 6553、DOI 10.17487 / RFC6553、2012年3月、<http：//www.rfc-editor。 org / info / rfc6553>。
[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, DOI 10.17487/RFC6554, March 2012, <http://www.rfc-editor.org/info/rfc6554>.
[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、 DOI 10.17487 / RFC6554、2012年3月、<http://www.rfc-editor.org/info/rfc6554>。
[RFC6719] Gnawali, O. and P. Levis, "The Minimum Rank with Hysteresis Objective Function", RFC 6719, DOI 10.17487/RFC6719, September 2012, <http://www.rfc-editor.org/info/rfc6719>.
[RFC6719] Gnawali、O。およびP. Levis、「最小ヒステリシス目的関数のランク」、RFC 6719、DOI 10.17487 / RFC6719、2012年9月、<http://www.rfc-editor.org/info/rfc6719> 。
[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, DOI 10.17487/RFC6775, November 2012, <http://www.rfc-editor.org/info/rfc6775>.
[RFC6775] Shelby、Z.、Ed。、Chakrabarti、S.、Nordmark、E。、およびC. Bormann、「低電力ワイヤレスパーソナルエリアネットワーク（6LoWPANs）上のIPv6のネイバー探索最適化」、RFC 6775、DOI 10.17487 / RFC6775、2012年11月、<http://www.rfc-editor.org/info/rfc6775>。
[RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Paging Dispatch", RFC 8025, DOI 10.17487/RFC8025, November 2016, <http://www.rfc-editor.org/info/rfc8025>.
[RFC8025] Thubert、P.、Ed。およびR. Cragie、「IPv6 over Low-Power Wireless Personal Area Network（6LoWPAN）Paging Dispatch」、RFC 8025、DOI 10.17487 / RFC8025、2016年11月、<http://www.rfc-editor.org/info/rfc8025> 。
[RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, "IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, April 2017, <http://www.rfc-editor.org/info/rfc8138>.
[RFC8138] Thubert、P。、編、Bormann、C.、Toutain、L。、およびR. Cragie、「IPv6 over Low-Power Wireless Personal Area Network（6LoWPAN）Routing Header」、RFC 8138、DOI 10.17487 / RFC8138 、2017年4月、<http://www.rfc-editor.org/info/rfc8138>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <http://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<http://www.rfc-editor.org/info/ rfc8174>。
[openwsn] Watteyne, T., Vilajosana, X., Kerkez, B., Chraim, F., Weekly, K., Wang, Q., Glaser, S., and K. Pister, "OpenWSN: a standards-based low-power wireless development environment", Transactions on Emerging Telecommunications Technologies, Volume 23 Issue 5, pages 480-493, DOI 10.1002/ett.2558, August 2012.
[openwsn] Watteyne、T.、Vilajosana、X.、Kerkez、B.、Chraim、F.、Weekly、K.、Wang、Q.、Glaser、S。、およびK. Pister、「OpenWSN：標準ベース低電力ワイヤレス開発環境」、Emerging Telecommunications Technologiesのトランザクション、23巻5号、480〜493ページ、DOI 10.1002 / ett.2558、2012年8月。
[PROTO-6P] Wang, Q., Vilajosana, X., and T. Watteyne, "6top Protocol (6P)", Work in Progress, draft-ietf-6tisch-6top-protocol-05, May 2017.
[PROTO-6P] Wang、Q.、Vilajosana、X。、およびT. Watteyne、「6top Protocol（6P）」、Work in Progress、draft-ietf-6tisch-6top-protocol-05、2017年5月。
[RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement", RFC 7554, DOI 10.17487/RFC7554, May 2015, <http://www.rfc-editor.org/info/rfc7554>.
[RFC7554] Watteyne、T。、編、Palattella、M。、およびL. Grieco、「モノのインターネット（IoT）でのIEEE 802.15.4eタイムスロットチャネルホッピング（TSCH）の使用：問題ステートメント」、RFC 7554 、DOI 10.17487 / RFC7554、2015年5月、<http://www.rfc-editor.org/info/rfc7554>。
[SEC-6TISCH] Vucinic, M., Simon, J., Pister, K., and M. Richardson, "Minimal Security Framework for 6TiSCH", Work in Progress, draft-ietf-6tisch-minimal-security-02, March 2017.
[SEC-6TISCH] Vucinic、M.、Simon、J.、Pister、K。、およびM. Richardson、「6TiSCHの最小限のセキュリティフレームワーク」、作業中、draft-ietf-6tisch-minimal-security-02、3月2017。
[SEC-JOIN-6TISCH] Richardson, M., "6tisch Secure Join protocol", Work in Progress, draft-ietf-6tisch-dtsecurity-secure-join-01, February 2017.
[SEC-JOIN-6TISCH] Richardson、M。、「6tisch Secure Join protocol」、Work in Progress、draft-ietf-6tisch-dtsecurity-secure-join-01、2017年2月。
[TERMS-6TiSCH] Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, "Terminology in IPv6 over the TSCH mode of IEEE 802.15.4e", Work in Progress, draft-ietf-6tisch-terminology-08, December 2016.
[TERMS-6TiSCH] Palattella、M.、Thubert、P.、Wattyne、T。、およびQ. Wang、「IEEE 802.15.4eのTSCHモードでのIPv6の用語」、作業中、draft-ietf-6tisch-用語集-2016年12月8日。
This section contains several example packets. Each example contains (1) a schematic header diagram, (2) the corresponding bytestream, and (3) a description of each of the IEs that form the packet. Packet formats are specific for the [IEEE.802.15.4] revision and may vary in future releases of the IEEE standard. In case of differences between the packet content presented in this section and [IEEE.802.15.4], the latter has precedence.
このセクションには、いくつかのパケット例が含まれています。各例には、（1）概略ヘッダー図、（2）対応するバイトストリーム、および（3）パケットを形成する各IEの説明が含まれています。パケット形式は[IEEE.802.15.4]リビジョンに固有であり、IEEE標準の将来のリリースでは異なる可能性があります。このセクションと[IEEE.802.15.4]で提示されているパケットの内容が異なる場合は、後者が優先されます。
The MAC header fields are described in a specific order. All field formats in this example are depicted in the order in which they are transmitted, from left to right, where the leftmost bit is transmitted first. Bits within each field are numbered from 0 (leftmost and least significant) to k - 1 (rightmost and most significant), where the length of the field is k bits. Fields that are longer than a single octet are sent to the PHY in the order from the octet containing the lowest numbered bits to the octet containing the highest numbered bits (little endian).
MACヘッダーフィールドは、特定の順序で説明されています。この例のすべてのフィールド形式は、左から右に送信される順序で示されています。左端のビットが最初に送信されます。各フィールド内のビットには、0（左端および最下位）からk-1（右端および最上位）までの番号が付けられ、フィールドの長さはkビットです。単一のオクテットより長いフィールドは、最小番号のビットを含むオクテットから最大番号のビットを含むオクテット（リトルエンディアン）の順にPHYに送信されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Len1 = 0 |Element ID=0x7e|0| Len2 = 26 |GrpId=1|1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Len3 = 6 |Sub ID = 0x1a|0| ASN
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ASN | Join Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Len4 = 0x01 |Sub ID = 0x1c|0| TT ID = 0x00 | Len5 = 0x01
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ID=0x9 |1| CH ID = 0x00 | Len6 = 0x0A |Sub ID = 0x1b|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| #SF = 0x01 | SF ID = 0x00 | SF LEN = 0x65 (101 slots) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| #Links = 0x01 | SLOT OFFSET = 0x0000 | CHANNEL
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OFF = 0x0000 |Link OPT = 0x0F| NO MAC PAYLOAD
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bytestream:
バイトストリーム：
00 3F 1A 88 06 1A ASN#0 ASN#1 ASN#2 ASN#3 ASN#4 JP 01 1C 00
01 C8 00 0A 1B 01 00 65 00 01 00 00 00 00 0F
Description of the IEs:
IEの説明：
#Header IE Header Len1 = Header IE Length (0) Element ID = 0x7e - termination IE indicating Payload IE coming next Type 0
#Header IEヘッダーLen1 =ヘッダーIEの長さ（0）要素ID = 0x7e-ペイロードIEが次に来るタイプ0を示す終了IE
#Payload IE Header (MLME) Len2 = Payload IE Len (26 bytes) Group ID = 1 MLME (Nested) Type = 1
#Payload IEヘッダー（MLME）Len2 =ペイロードIE Len（26バイト）グループID = 1 MLME（ネスト）タイプ= 1
#MLME-SubIE TSCH Synchronization Len3 = Length in bytes of the sub-IE payload (6 bytes) Sub-ID = 0x1a (MLME-SubIE TSCH Synchronization) Type = Short (0) ASN = Absolute Sequence Number (5 bytes) Join Metric = 1 byte
＃MLME-SubIE TSCH同期Len3 =サブIEペイロードの長さ（6バイト）サブID = 0x1a（MLME-SubIE TSCH同期）タイプ=ショート（0）ASN =絶対シーケンス番号（5バイト）結合メトリック= 1バイト
#MLME-SubIE TSCH Timeslot Len4 = Length in bytes of the sub-IE payload (1 byte) Sub-ID = 0x1c (MLME-SubIE Timeslot) Type = Short (0) Timeslot template ID = 0x00 (default)
＃MLME-SubIE TSCHタイムスロットLen4 =サブIEペイロードの長さ（1バイト）サブID = 0x1c（MLME-SubIEタイムスロット）タイプ=短い（0）タイムスロットテンプレートID = 0x00（デフォルト）
#MLME-SubIE Channel Hopping Len5 = Length in bytes of the sub-IE payload (1 byte) Sub-ID = 0x09 (MLME-SubIE Channel Hopping) Type = Long (1) Hopping Sequence ID = 0x00 (default)
＃MLME-SubIEチャネルホッピングLen5 =サブIEペイロードの長さ（1バイト）サブID = 0x09（MLME-SubIEチャネルホッピング）タイプ=ロング（1）ホッピングシーケンスID = 0x00（デフォルト）
#MLME-SubIE TSCH Slotframe and Link
Len6 = Length in bytes of the sub-IE payload (10 bytes)
Sub-ID = 0x1b (MLME-SubIE TSCH Slotframe and Link)
Type = Short (0)
Number of slotframes = 0x01
Slotframe handle = 0x00
Slotframe size = 101 slots (0x65)
Number of Links (Cells) = 0x01
Timeslot = 0x0000 (2B)
Channel Offset = 0x0000 (2B)
Link Options = 0x0F
(TX Link = 1, RX Link = 1, Shared Link = 1,
Timekeeping = 1 )
Using a custom timeslot template in EBs: setting timeslot length to 15 ms.
EBでのカスタムタイムスロットテンプレートの使用：タイムスロット長を15 msに設定します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Len1 = 0 |Element ID=0x7e|0| Len2 = 53 |GrpId=1|1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Len3 = 6 |Sub ID = 0x1a|0| ASN
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ASN | Join Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Len4 = 25 |Sub ID = 0x1c|0| TT ID = 0x01 | macTsCCAOffset
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= 2700 | macTsCCA = 128 | macTsTxOffset
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= 3180 | macTsRxOffset = 1680 | macTsRxAckDelay
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= 1200 | macTsTxAckDelay = 1500 | macTsRxWait
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= 3300 | macTsAckWait = 600 | macTsRxTx
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= 192 | macTsMaxAck = 2400 | macTsMaxTx
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= 4256 | macTsTimeslotLength = 15000 | Len5 = 0x01
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ID=0x9 |1| CH ID = 0x00 | Len6 = 0x0A | ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bytestream:
バイトストリーム：
00 3F 1A 88 06 1A ASN#0 ASN#1 ASN#2 ASN#3 ASN#4 JP 19 1C 01 8C 0A 80 00 6C 0C 90 06 B0 04 DC 05 E4 0C 58 02 C0 00 60 09 A0 10 98 3A 01 C8 00 0A ...
00 3F 1A 88 06 1A ASN＃0 ASN＃1 ASN＃2 ASN＃3 ASN＃4 JP 19 1C 01 8C 0A 80 00 6C 0C 90 06 B0 04 DC 05 E4 0C 58 02 C0 00 60 09 A0 10 98 3A 01 C8 00 0A ...
Description of the IEs:
IEの説明：
#Header IE Header Len1 = Header IE Length (none) Element ID = 0x7e - termination IE indicating Payload IE coming next Type 0
#Header IEヘッダーLen1 =ヘッダーIEの長さ（なし）要素ID = 0x7e-ペイロードIEが次に来るタイプ0を示す終了IE
#Payload IE Header (MLME) Len2 = Payload IE Len (53 bytes) Group ID = 1 MLME (Nested) Type = 1
＃ペイロードIEヘッダー（MLME）Len2 =ペイロードIE Len（53バイト）グループID = 1 MLME（ネスト）タイプ= 1
#MLME-SubIE TSCH Synchronization Len3 = Length in bytes of the sub-IE payload (6 bytes) Sub-ID = 0x1a (MLME-SubIE TSCH Synchronization) Type = Short (0) ASN = Absolute Sequence Number (5 bytes) Join Metric = 1 byte
＃MLME-SubIE TSCH同期Len3 =サブIEペイロードの長さ（6バイト）サブID = 0x1a（MLME-SubIE TSCH同期）タイプ=ショート（0）ASN =絶対シーケンス番号（5バイト）結合メトリック= 1バイト
#MLME-SubIE TSCH Timeslot Len4 = Length in bytes of the sub-IE payload (25 bytes) Sub-ID = 0x1c (MLME-SubIE Timeslot) Type = Short (0) Timeslot template ID = 0x01 (non-default)
＃MLME-SubIE TSCHタイムスロットLen4 =サブIEペイロードの長さ（25バイト）サブID = 0x1c（MLME-SubIEタイムスロット）タイプ=ショート（0）タイムスロットテンプレートID = 0x01（デフォルト以外）
The 15 ms timeslot announced:
+--------------------------------+------------+
| IEEE 802.15.4 TSCH parameter | Value (us) |
+--------------------------------+------------+
| macTsCCAOffset | 2700 |
+--------------------------------+------------+
| macTsCCA | 128 |
+--------------------------------+------------+
| macTsTxOffset | 3180 |
+--------------------------------+------------+
| macTsRxOffset | 1680 |
+--------------------------------+------------+
| macTsRxAckDelay | 1200 |
+--------------------------------+------------+
| macTsTxAckDelay | 1500 |
+--------------------------------+------------+
| macTsRxWait | 3300 |
+--------------------------------+------------+
| macTsAckWait | 600 |
+--------------------------------+------------+
| macTsRxTx | 192 |
+--------------------------------+------------+
| macTsMaxAck | 2400 |
+--------------------------------+------------+
| macTsMaxTx | 4256 |
+--------------------------------+------------+
| macTsTimeslotLength | 15000 |
+--------------------------------+------------+
#MLME-SubIE Channel Hopping Len5 = Length in bytes of the sub-IE payload. (1 byte) Sub-ID = 0x09 (MLME-SubIE Channel Hopping) Type = Long (1) Hopping Sequence ID = 0x00 (default)
＃MLME-SubIEチャネルホッピングLen5 =サブIEペイロードのバイト単位の長さ。 （1バイト）サブID = 0x09（MLME-SubIEチャネルホッピング）タイプ=ロング（1）ホッピングシーケンスID = 0x00（デフォルト）
Enhanced Acknowledgment packets carry the Time Correction IE (Header IE).
拡張された確認応答パケットは、時間修正IE（ヘッダーIE）を伝送します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Len1 = 2 |Element ID=0x1e|0| Time Sync Info |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bytestream:
バイトストリーム：
02 0F TS#0 TS#1
02 0F TS＃0 TS＃1
Description of the IEs:
IEの説明：
#Header IE Header Len1 = Header IE Length (2 bytes) Element ID = 0x1e - ACK/NACK Time Correction IE Type 0
#Header IEヘッダーLen1 =ヘッダーIEの長さ（2バイト）要素ID = 0x1e-ACK / NACK時間修正IEタイプ0
802.15.4 Auxiliary Security Header with the Security Level set to ENC-MIC-32.
セキュリティレベルがENC-MIC-32に設定された802.15.4補助セキュリティヘッダー。
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L = 5|M=1|1|1|0|Key Index = IDX|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bytestream:
バイトストリーム：
6D IDX#0
6D IDX＃0
Security Auxiliary Header fields in the example:
例のセキュリティ補助ヘッダーフィールド：
#Security Control (1 byte) L = Security Level ENC-MIC-32 (5) M = Key Identifier Mode (0x01) Frame Counter Suppression = 1 (omitting Frame Counter field) ASN in Nonce = 1 (construct Nonce from 5 byte ASN) Reserved = 0
＃セキュリティ制御（1バイト）L =セキュリティレベルENC-MIC-32（5）M =キー識別子モード（0x01）フレームカウンター抑制= 1（フレームカウンターフィールドを省略）ASN in nonce = 1（5バイトASNからnonceを構築） ）予約済み= 0
#Key Identifier (1 byte) Key Index = IDX (deployment-specific KeyIndex parameter that identifies the cryptographic key)
#Key Identifier（1 byte）Key Index = IDX（暗号化キーを識別するデプロイメント固有のKeyIndexパラメータ）
Acknowledgments
謝辞
The authors acknowledge the guidance and input from Rene Struik, Pat Kinney, Michael Richardson, Tero Kivinen, Nicola Accettura, Malisa Vucinic, and Jonathan Simon. Thanks to Charles Perkins, Brian E. Carpenter, Ralph Droms, Warren Kumari, Mirja Kuehlewind, Ben Campbell, Benoit Claise, and Suresh Krishnan for the exhaustive and detailed reviews. Thanks to Simon Duquennoy, Guillaume Gaillard, Tengfei Chang, and Jonathan Munoz for the detailed review of the examples section. Thanks to 6TiSCH co-chair Pascal Thubert for his guidance and advice.
著者は、Rene Struik、Pat Kinney、Michael Richardson、Tero Kivinen、Nicola Accettura、Malisa Vucinic、およびJonathan Simonからのガイダンスと入力を認めます。徹底的かつ詳細なレビューを提供してくれたCharles Perkins、Brian E. Carpenter、Ralph Droms、Warren Kumari、Mirja Kuehlewind、Ben Campbell、Benoit Claise、Suresh Krishnanに感謝します。例のセクションの詳細なレビューを提供してくれたSimon Duquennoy、Guillaume Gaillard、Tengfei Chang、Jonathan Munozに感謝します。 6TiSCHの共同議長Pascal Thubertの指導と助言に感謝します。
Authors' Addresses
著者のアドレス
Xavier Vilajosana (editor) Universitat Oberta de Catalunya 156 Rambla Poblenou Barcelona, Catalonia 08018 Spain
ザビエルビラホサナ（編集者）カタルーニャ大学オープン156ランブラポブレノウバルセロナ、カタルーニャ08018スペイン
Email: xvilajosana@uoc.edu
Kris Pister University of California Berkeley 512 Cory Hall Berkeley, California 94720 United States of America
クリスピスターカリフォルニア大学バークレー校512 Cory Hallバークレー、カリフォルニア州94720アメリカ合衆国
Email: pister@eecs.berkeley.edu
Thomas Watteyne Analog Devices 32990 Alvarado-Niles Road, Suite 910 Union City, CA 94587 United States of America
Thomas Watteyne Analog Devices 32990 Alvarado-Niles Road、Suite 910 Union City、CA 94587アメリカ合衆国
Email: twatteyne@linear.com