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
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的最低操作模式。此最低操作模式指定了需要支持的协议基线集，以及足以启用6Disch功能网络的推荐配置和操作模式。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协议之间的适当链路。所有6Disk兼容设备都应实现此最低操作模式。
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）的产品。它代表了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.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of 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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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].
6Disch网络通过由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.
本规范规定了构建6Disch网络的最低运行模式的运行参数和程序。任何符合6Disk标准的设备都应实现此操作模式。此操作参数配置为节点提供引导网络所需的带宽。引导过程包括初始网络配置和安全引导。在本规范中，802.15.4 TSCH模式、6LoWPAN框架、RPL[RFC6550]和RPL目标函数0（OF0）[RFC6552]未经修改地使用。指定TSCH的参数和特定操作，以保证6Disch网络中节点之间的互操作性。
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.
在6Disch网络中，节点遵循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.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照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：我们在本文档中使用“802.15.4”作为“IEEE标准802.15.4”的简短版本。
SFD: Start of Frame Delimiter
SFD：帧分隔符的开始
RX: Reception
接收：接收
TX: Transmission
传输
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.
连接度量：TSCH同步IE中的字段，表示发送EB的节点与PAN协调器之间的拓扑距离。
PAN: Personal Area Network
个人区域网
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.
符合本规范的实现必须在时隙信道跳频（TSCH）模式下实现IEEE Std 802.15.4[IEEE.802.15.4]。
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.
本节剩余部分详细介绍了推荐的TSCH设置，如图1所示。EB列中标记的任何属性在节点发送的EBs[IEEE.802.15.4]中公布，并由加入网络的人学习。更改其值意味着更改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标准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.
+--------------------------------+------------------------------+---+
| 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标准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.
此最小操作模式使用单个slotframe。TSCH slotframe由可调数量的时隙组成。slotframe大小（即它包含的时隙数）在能耗方面权衡带宽。慢帧大小需要调整；调整它的方式超出了本规范的范围。slotframe的大小在EB中公布。slotframe句柄（macSlotframeHandle）的建议值为0x00。例如，实现可以选择使用不同的slotframe句柄来添加其他具有更高优先级的slotframe。其他插槽框架的使用超出了本文档的范围。
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.
slotframe中只有一个调度单元。该小区可以调度在slotframe内的任何slotofset/channelOffset处。该单元在进度表中的位置将在EB中公布。计划单元的链接类型正在播发，以允许在其上发送EBs。
Figure 2 shows an example of a slotframe of length 101 timeslots, resulting in a radio duty cycle below 0.99%.
图2显示了长度为101个时隙的slotframe示例，导致无线电占空比低于0.99%。
Chan. +----------+----------+ +----------+
Off.0 | TxRxS/EB | OFF | | OFF |
Chan. +----------+----------+ +----------+
Off.1 | OFF | OFF | ... | OFF |
+----------+----------+ +----------+
.
.
.
Chan. +----------+----------+ +----------+
Off.15 | OFF | OFF | | OFF |
+----------+----------+ +----------+
Chan. +----------+----------+ +----------+
Off.0 | TxRxS/EB | OFF | | OFF |
Chan. +----------+----------+ +----------+
Off.1 | OFF | OFF | ... | OFF |
+----------+----------+ +----------+
.
.
.
Chan. +----------+----------+ +----------+
Off.15 | OFF | OFF | | OFF |
+----------+----------+ +----------+
slotOffset 0 1 100
Slotofset 0 1 100
EB: Enhanced Beacon Tx: Transmit Rx: Receive S: Shared OFF: Unscheduled by this specification
EB：增强信标发送：发送接收：接收S：共享关闭：本规范未计划
Figure 2: Example Slotframe of Length 101 Timeslots
图2：长度为101个时隙的Slotframe示例
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.
节点可以使用调度的小区来发送/接收所有类型的链路层帧。EBs被发送到链路层广播地址，并且未被确认。数据帧以单播方式发送，并由接收邻居确认。
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.
slotframe中的所有剩余单元都是未计划的。将来可能会定义动态调度解决方案来调度这些单元。一个例子是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)
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次尝试后没有收到任何数据包，则传输被视为失败，链路层必须通知上层。不需要确认的数据包（包括EBs）不会重新传输。
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]允许多个字段存在（或不存在），具有不同的长度和不同的值。本规范详细说明了802.15.4帧的建议内容，同时严格遵守[IEEE.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源地址字段设置为节点的短地址。否则，必须使用长地址。
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为“存在”。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节描述了nonce生成，第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节点以未同步、未连接的状态启动。通过侦听EBs实现初始同步。可能会听到来自多个网络的EBs。网络之间存在许多歧视机制，其细节超出了范围。
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标准802.15.4规范没有定义EBs的发送频率，也没有定义EBs的内容[IEEE.802.15.4]。在最小TSCH配置中，节点应在每个EB_周期发送EB。调整EB_周期可以在连接时间和能耗之间进行权衡。
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.
EBs应用于获取有关本地网络的信息，并同步ASN和节点决定加入的特定网络的时间偏移。一旦加入到特定网络，节点可以选择继续侦听eb，以收集关于其他网络的更多信息。在加入过程中，在创建到时间父节点的安全连接之前，节点可以使用EBs保持同步。[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规范要求发送EBs，以使节点能够加入网络。EBs应携带下列信息元素[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同步IE：包含同步信息，如ASN和连接度量。连接度量字段的值在第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 Slotframe和Link 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与加入时接收的EB具有完全相同的内容，TSCH同步IE中的加入度量字段除外。
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。这并不排除从其他网络收听EBs。
Per [IEEE.802.15.4], each acknowledgment contains an ACK/NACK Time Correction IE.
根据[IEEE.802.15.4]，每个确认都包含一个ACK/NACK时间校正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标准802.15.4[IEEE.802.15.4]中定义的链路层安全机制进行保护。链路层身份验证必须应用于整个帧，包括802.15.4报头。链路层加密可应用于802.15.4有效负载IEs和802.15.4有效负载。
This specification assumes the existence of two cryptographic keys:
本规范假设存在两个加密密钥：
Key K1 is used to authenticate EBs. EBs MUST be authenticated only (no encryption); their contents are defined in Section 4.5.2.
密钥K1用于对EBs进行身份验证。EBs必须仅经过身份验证（无加密）；其内容见第4.5.2节。
Key K2 is used to authenticate and encrypt DATA and ACKNOWLEDGMENT frames.
密钥K2用于对数据和确认帧进行身份验证和加密。
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认证EBs，并依赖密钥分发阶段来学习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标准802.15.4[IEEE.802.15.4]第6.3.1.2节中定义的EBs，即，即使“未固化过程的状态指示错误”，它们也会被转发。JN然后运行密钥分发阶段来学习K1和K2。在此过程中，JN正在与之交谈的节点使用secemption机制（参见[IEEE.802.15.4]第9.2.4节）来处理来自JN的帧。密钥分发阶段完成后，为JN安装SecExcempts的节点必须清除已安装的异常规则。
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
R(N) = R(P) + rank_increment
rank_increment = (Rf*Sp + Sr) * MinHopRankIncrease
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 | |
+----------------------+-------------------------------------+
+----------------------+-------------------------------------+
| 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].
秩（Sp）的步进使用预期传输计数（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的最小值（秩的最小步长）表示链接质量良好。Sp的最大值（秩的最大步长）表示链路质量差。Sp的默认值（等级的默认步骤）表示平均质量链接。不应选择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
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
+-------+
+-------+
| 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：5跳网络的秩计算示例，其中所有链路的numTx=100，numTxAck=75。
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节）应由具有足够能力的节点实现。未实现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]).
RPL信令消息，如DODAG信息对象（DIO），使用涓流算法发送（见[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封装要求。必须根据[RFC8138]和[RFC8025]压缩路由扩展头，如RPL数据包信息（RPI）[RFC6550]和源路由头（SRH）[RFC6554]，以及封装情况下的外部IP头。
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的节点在拓扑上“更接近”网络的根。因此，联接度量的较低值表示联接节点更倾向于与该邻居同步。
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（秩（0））=1。DAGRank（秩（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，则连接度量值必须遵循[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].
当一个节点加入网络时，它可能会听到网络中已经存在的不同节点发送的EBs。要同步到哪个邻居（例如，哪个邻居成为节点的初始时间源邻居）的决定是特定于实现的。例如，在接收到第一个EB之后，节点最多可以监听MAX_EB_延迟秒，直到它从NUM_邻居到不同邻居接收EB为止。图5中定义了MAX_EB_DELAY和NUM_neights_TO_WAIT的建议值。当从不同的邻居接收EB时，节点可以使用每个EB中的连接度量字段来选择初始时间源邻居，如IEEE Std 802.15.4[IEEE.802.15.4]第6.3.6节所述。
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.
在任何时候，节点都必须与至少一个时间源邻居保持同步。使用RPL时，节点的时间源邻居必须在其RPL路由父集中的邻居中选择。如果节点无法保持与至少一个时间源邻居的连接，则该节点将失去同步，需要再次加入网络。
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秩之前不得发送EBs，以避免时间同步结构中的不一致。这适用于其他路由协议及其相应的路由度量。一旦节点获得路由信息（例如，RPL等级，见第5.1.1节），它就应该开始发送EBs。
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]，规范建议使用边界值（父级开关阈值），以避免在比较列组时父级不断变化。当评估属于小于当前最小路径的路径成本的父节点时，仅当新路径和当前路径之间的差异大于定义的父节点开关阈值时，才选择候选节点作为新父节点。否则，节点可以继续使用当前首选父节点。根据[RFC6719]，当使用ETX度量时，父开关阈值应设置为192（格式为128*ETX）；本文件的建议是，如果使用的度量为（（3*ETX）-2）*minHopRankIncrease或比例值，则使用等于640的父开关阈值。这将处理路由父节点和时间源邻居选择的滞后问题。
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).
标识符：邻居的标识符（例如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.
时间源邻居：指示此邻居是否为时间源邻居的标志。
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).
节点被配置为在队列中为每条链路保留可配置数量的上层数据包（默认NUM_UPPERLAYER_数据包），并在可配置的时间内覆盖加入过程（默认最大加入时间）。
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层（包括EBs）生成的帧以高于来自更高层的帧的优先级排队。
A frame type BEACON is queued with higher priority than frame types 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 |
+-------------------------+-------------------+
+-------------------------+-------------------+
| 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，则可以通过发送经过身份验证的EBs生成假EBs来攻击整个网络。攻击者可以使加入节点向攻击者发起加入过程。如果加入过程包括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帧。在这里，我们讨论这些伪EBs可能产生的影响，这取决于预设置的密钥。
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都是预供应的；加入节点可以区分合法EBs和假EBs，并加入合法网络。假EBs没有影响。
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.
一旦加入过程结束，加入的节点就可以对EBs进行身份验证（它知道K1）。这意味着它可以处理它们的内容并使用EBs进行同步。
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为插槽中的安全操作提供nonce。使用给定密钥重复使用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之前容易受到定时攻击。在网络运行期间，节点可以维护来自邻居的时间更新统计信息，并监视异常情况。
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
LLN中媒体访问控制（MAC）层的拒绝服务（DoS）攻击很容易通过射频（RF）干扰实现。这是判断更复杂的拒绝服务攻击的基本情况。例如，发送虚假的EBs宣布非常低的加入度量可能会导致节点浪费时间和精力尝试加入虚假网络，即使在听到合法的EBs时也是如此。适当的加入安全性将防止节点加入错误标志，但到那时，时间和精力将被浪费。但是，攻击者的能量消耗会更低，并且
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.
如果攻击者简单地在其所听到的任何有效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.
第六层应跟踪异常事件，并向上级报告。例如，如上所述，EBs报告无法加入的网络的低加入度量可能是攻击的迹象。此外，在正常网络操作中，使用有效循环冗余校验（CRC）的数据包上的消息完整性检查失败将以每百万个数据包一次的速率发生。任何明显偏离此速率的行为都可能是网络攻击的迹象。同样，ACK或EBs中与MAC层的时间感及其自身合理的时间误差漂移率不一致的时间更新也可能是网络攻击的结果。
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标准”，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.，Kushalnagar，N.，Hui，J.，和D.Culler，“通过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.，Clausen，T.，Hui，J.，Gnawali，O.，和J.Ko，“涓流算法”，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]Hui，J.，Ed.和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.，Ed.，Thubert，P.，Ed.，Brandt，A.，Hui，J.，Kelsey，R.，Levis，P.，Pister，K.，Struik，R.，Vasseur，JP.，和R.Alexander，“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.，和D.Barthel，“低功率和有损网络中用于路径计算的路由度量”，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.，Ed.“低功耗和有损网络路由协议（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.，和V.Manral，“低功耗和有损网络（RPL）路由协议源路由的IPv6路由头”，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/RFC67752012年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，“低功率无线个人区域网（6LoWPAN）上的IPv6寻呼调度”，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.，Ed.，Bormann，C.，Toutain，L.，和R.Cragie，“低功率无线个人区域网络（6LoWPAN）路由头上的IPv6”，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：基于标准的低功耗无线开发环境”，新兴电信技术交易，第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协议（6P）”，正在进行的工作，草案-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.，Ed.，Palatella，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的最低安全框架”，正在进行的工作，草稿-ietf-6TISCH-最低安全-022017年3月。
[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安全连接协议”，正在进行的工作，草稿-ietf-6TISCH-dtsecurity-Secure-JOIN-012017年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]Palatella，M.，Thubert，P.，Watteyne，T.，和Q.Wang，“IEEE 802.15.4e TSCH模式下IPv6中的术语”，正在进行中的工作，草案-ietf-6TiSCH-TERMENCHICS-082016年12月。
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）相应的ByTestStream，以及（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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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:
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
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:
IEs的说明：
#Header IE Header Len1 = Header IE Length (0) Element ID = 0x7e - termination IE indicating Payload IE coming next Type 0
#标头IE标头Len1=标头IE长度（0）元素ID=0x7e-终止IE指示有效负载IE下一个类型0
#Payload IE Header (MLME) Len2 = Payload IE Len (26 bytes) Group ID = 1 MLME (Nested) Type = 1
#有效负载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子IE通道跳频Len5=子IE有效负载的字节长度（1字节）子ID=0x09（MLME子IE通道跳频）类型=长（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 )
#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.
在EBs中使用自定义时隙模板：将时隙长度设置为15毫秒。
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 | ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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:
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:
IEs的说明：
#Header IE Header Len1 = Header IE Length (none) Element ID = 0x7e - termination IE indicating Payload IE coming next Type 0
#标头IE标头Len1=标头IE长度（无）元素ID=0x7e-终止IE指示有效负载IE下一个类型0
#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 |
+--------------------------------+------------+
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子IE通道跳跃Len5=子IE有效负载的字节长度。（1字节）子ID=0x09（MLME子通道跳变）类型=长（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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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:
Bytestream：
02 0F TS#0 TS#1
02 0F TS#0 TS#1
Description of the IEs:
IEs的说明：
#Header IE Header Len1 = Header IE Length (2 bytes) Element ID = 0x1e - ACK/NACK Time Correction IE Type 0
#标头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.
802.15.4安全级别设置为ENC-MIC-32的辅助安全标头。
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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:
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)
#安全控制（1字节）L=安全级别ENC-MIC-32（5）M=密钥标识符模式（0x01）
Frame Counter Suppression = 1 (omitting Frame Counter field) ASN in Nonce = 1 (construct Nonce from 5 byte ASN) Reserved = 0
帧计数器抑制=1（省略帧计数器字段）ASN在Nonce=1（从5字节ASN构造Nonce）保留=0
#Key Identifier (1 byte) Key Index = IDX (deployment-specific KeyIndex parameter that identifies the cryptographic key)
#密钥标识符（1字节）密钥索引=IDX（用于标识加密密钥的部署特定密钥索引参数）
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
Email: xvilajosana@uoc.edu
Kris Pister University of California Berkeley 512 Cory Hall Berkeley, California 94720 United States of America
克里斯·皮特加利福尼亚大学加利福尼亚大学伯克利512科丽霍尔伯克利加利福尼亚94720美利坚合众国
Email: pister@eecs.berkeley.edu
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模拟设备美国加利福尼亚州联合市Alvarado Niles路32990号910室94587
Email: twatteyne@linear.com
Email: twatteyne@linear.com