Internet Engineering Task Force (IETF) Q. Wang, Ed.
Request for Comments: 8480 Univ. of Sci. and Tech. Beijing
Category: Standards Track X. Vilajosana
ISSN: 2070-1721 Universitat Oberta de Catalunya
T. Watteyne
Analog Devices
November 2018
Internet Engineering Task Force (IETF) Q. Wang, Ed.
Request for Comments: 8480 Univ. of Sci. and Tech. Beijing
Category: Standards Track X. Vilajosana
ISSN: 2070-1721 Universitat Oberta de Catalunya
T. Watteyne
Analog Devices
November 2018
6TiSCH Operation Sublayer (6top) Protocol (6P)
6Disch操作子层（6top）协议（6P）
Abstract
摘要
This document defines the "IPv6 over the TSCH mode of IEEE 802.15.4e" (6TiSCH) Operation Sublayer (6top) Protocol (6P), which enables distributed scheduling in 6TiSCH networks. 6P allows neighbor nodes to add/delete Time-Slotted Channel Hopping (TSCH) cells to/on one another. 6P is part of the 6TiSCH Operation Sublayer (6top), the layer just above the IEEE Std 802.15.4 TSCH Medium Access Control layer. 6top is composed of one or more Scheduling Functions (SFs) and the 6top Protocol defined in this document. A 6top SF decides when to add/delete cells, and it triggers 6P Transactions. The definition of SFs is out of scope for this document; however, this document provides the requirements for an SF.
本文档定义了“基于IEEE 802.15.4e（6TiSCH）操作子层（6top）协议（6P）TSCH模式的IPv6”，该协议支持在6TiSCH网络中进行分布式调度。6P允许相邻节点在彼此之间添加/删除时隙信道跳频（TSCH）小区。6P是6TiSCH操作子层（6top）的一部分，该层恰好位于IEEE Std 802.15.4 TSCH介质访问控制层之上。6top由一个或多个调度功能（SFs）和本文档中定义的6top协议组成。6top SF决定何时添加/删除单元格，并触发6P事务。SFs的定义超出了本文件的范围；但是，本文件规定了SF的要求。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8480.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8480.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Requirements Language ......................................5
2. 6TiSCH Operation Sublayer (6top) ................................5
2.1. Hard/Soft Cells ............................................6
2.2. Using 6P with the Minimal 6TiSCH Configuration .............6
3. 6top Protocol (6P) ..............................................7
3.1. 6P Transactions ............................................7
3.1.1. 2-Step 6P Transaction ...............................8
3.1.2. 3-Step 6P Transaction ..............................10
3.2. Message Format ............................................12
3.2.1. 6top Information Element (IE) ......................12
3.2.2. Generic 6P Message Format ..........................12
3.2.3. 6P CellOptions .....................................13
3.2.4. 6P CellList ........................................16
3.3. 6P Commands and Operations ................................17
3.3.1. Adding Cells .......................................17
3.3.2. Deleting Cells .....................................19
3.3.3. Relocating Cells ...................................21
3.3.4. Counting Cells .....................................27
3.3.5. Listing Cells ......................................28
3.3.6. Clearing the Schedule ..............................30
3.3.7. Generic Signaling between SFs ......................31
3.4. Protocol Functional Details ...............................31
3.4.1. Version Checking ...................................31
3.4.2. SFID Checking ......................................32
3.4.3. Concurrent 6P Transactions .........................32
3.4.4. 6P Timeout .........................................33
3.4.5. Aborting a 6P Transaction ..........................33
3.4.6. SeqNum Management ..................................33
3.4.7. Handling Error Responses ...........................40
3.5. Security ..................................................40
1. Introduction ....................................................3
1.1. Requirements Language ......................................5
2. 6TiSCH Operation Sublayer (6top) ................................5
2.1. Hard/Soft Cells ............................................6
2.2. Using 6P with the Minimal 6TiSCH Configuration .............6
3. 6top Protocol (6P) ..............................................7
3.1. 6P Transactions ............................................7
3.1.1. 2-Step 6P Transaction ...............................8
3.1.2. 3-Step 6P Transaction ..............................10
3.2. Message Format ............................................12
3.2.1. 6top Information Element (IE) ......................12
3.2.2. Generic 6P Message Format ..........................12
3.2.3. 6P CellOptions .....................................13
3.2.4. 6P CellList ........................................16
3.3. 6P Commands and Operations ................................17
3.3.1. Adding Cells .......................................17
3.3.2. Deleting Cells .....................................19
3.3.3. Relocating Cells ...................................21
3.3.4. Counting Cells .....................................27
3.3.5. Listing Cells ......................................28
3.3.6. Clearing the Schedule ..............................30
3.3.7. Generic Signaling between SFs ......................31
3.4. Protocol Functional Details ...............................31
3.4.1. Version Checking ...................................31
3.4.2. SFID Checking ......................................32
3.4.3. Concurrent 6P Transactions .........................32
3.4.4. 6P Timeout .........................................33
3.4.5. Aborting a 6P Transaction ..........................33
3.4.6. SeqNum Management ..................................33
3.4.7. Handling Error Responses ...........................40
3.5. Security ..................................................40
4. Requirements for 6top Scheduling Function (SF) Specifications ..41
4.1. SF Identifier (SFID) ......................................41
4.2. Requirements for an SF Specification ......................41
5. Security Considerations ........................................42
6. IANA Considerations ............................................43
6.1. IETF IE Subtype 6P ........................................43
6.2. 6TiSCH Parameters Subregistries ...........................43
6.2.1. 6P Version Numbers .................................43
6.2.2. 6P Message Types ...................................44
6.2.3. 6P Command Identifiers .............................44
6.2.4. 6P Return Codes ....................................45
6.2.5. 6P Scheduling Function Identifiers .................46
6.2.6. 6P CellOptions Bitmap ..............................47
7. References .....................................................48
7.1. Normative References ......................................48
7.2. Informative References ....................................48
Appendix A. Recommended Structure of an SF Specification ..........49
Authors' Addresses ................................................50
4. Requirements for 6top Scheduling Function (SF) Specifications ..41
4.1. SF Identifier (SFID) ......................................41
4.2. Requirements for an SF Specification ......................41
5. Security Considerations ........................................42
6. IANA Considerations ............................................43
6.1. IETF IE Subtype 6P ........................................43
6.2. 6TiSCH Parameters Subregistries ...........................43
6.2.1. 6P Version Numbers .................................43
6.2.2. 6P Message Types ...................................44
6.2.3. 6P Command Identifiers .............................44
6.2.4. 6P Return Codes ....................................45
6.2.5. 6P Scheduling Function Identifiers .................46
6.2.6. 6P CellOptions Bitmap ..............................47
7. References .....................................................48
7.1. Normative References ......................................48
7.2. Informative References ....................................48
Appendix A. Recommended Structure of an SF Specification ..........49
Authors' Addresses ................................................50
All communication in an "IPv6 over the TSCH mode of IEEE 802.15.4e" (6TiSCH) network is orchestrated by a schedule [RFC7554]. The schedule is composed of cells, each identified by a [slotOffset,channelOffset] (Section 3.2.4). This specification defines the 6TiSCH Operation Sublayer (6top) Protocol (6P), which is terminated by 6top. 6P allows a node to communicate with a neighbor node to add/delete Time-Slotted Channel Hopping (TSCH) cells to/on one another. This results in distributed schedule management in a 6TiSCH network. 6top is composed of one or more Scheduling Functions (SFs) and the 6top Protocol defined in this document. The definition of SFs is out of scope for this document; however, this document provides the requirements for an SF.
“IEEE 802.15.4e的TSCH模式上的IPv6”（6TiSCH）网络中的所有通信都由一个时间表[RFC7554]进行编排。时间表由单元格组成，每个单元格由[Slotofset，channelOffset]标识（第3.2.4节）。本规范定义了6TiSCH操作子层（6top）协议（6P），该协议由6top终止。6P允许节点与邻居节点通信，以便在彼此之间添加/删除时隙信道跳频（TSCH）小区。这将导致6Disch网络中的分布式计划管理。6top由一个或多个调度功能（SFs）和本文档中定义的6top协议组成。SFs的定义超出了本文件的范围；但是，本文件规定了SF的要求。
The example network depicted in Figure 1 is used to describe the interaction between nodes. We consider the canonical case where node "A" issues 6P Requests (also referred to as "commands" in this document) to node "B". We use this example throughout this document: node A always represents the node that issues a 6P Request, and node B represents the node that receives this request.
图1所示的示例网络用于描述节点之间的交互。我们考虑规范的情况，节点“A”将6P请求（也被称为“命令”）在节点“B”中。我们在本文档中使用了这个示例：节点A始终表示发出6P请求的节点，节点B表示接收该请求的节点。
(R)
/ \
/ \
(B)-----(C)
| |
| |
(A) (D)
(R)
/ \
/ \
(B)-----(C)
| |
| |
(A) (D)
Figure 1: A Simple 6TiSCH Network
图1：一个简单的6Disch网络
We consider that node A monitors the communication cells it has in its schedule to node B:
我们认为节点A监视它在其调度到节点B的通信单元：
o If node A determines that the number of link-layer frames it is sending to node B per unit of time exceeds the capacity offered by the TSCH cells it has scheduled to node B, it triggers a 6P Transaction with node B to add one or more cells to the TSCH schedule of both nodes.
o 如果节点A确定其每单位时间发送给节点B的链路层帧的数量超过其调度给节点B的TSCH小区提供的容量，则它触发与节点B的6P事务，以将一个或多个小区添加到两个节点的TSCH调度中。
o If the traffic is lower than the capacity offered by the TSCH cells it has scheduled to node B, node A triggers a 6P Transaction with node B to delete one or more cells in the TSCH schedule of both nodes.
o 如果通信量低于其调度给节点B的TSCH小区提供的容量，则节点A触发与节点B的6P事务，以删除两个节点的TSCH调度中的一个或多个小区。
o Node A MAY also monitor statistics to determine whether collisions are happening on a particular cell to node B. If this feature is enabled, node A communicates with node B to "relocate" this particular cell to a different [slotOffset,channelOffset] location in the TSCH schedule.
o 节点A还可以监视统计信息，以确定特定小区与节点B之间是否发生冲突。如果启用此功能，节点A将与节点B通信，以将该特定小区“重新定位”到TSCH调度中的不同[Slotofset，channelOffset]位置。
This results in distributed schedule management in a 6TiSCH network.
这将导致6Disch网络中的分布式计划管理。
The 6top SF defines when to add/delete a cell to/on a neighbor. Different applications require different SFs; this topic is out of scope for this document. Different SFs are expected to be defined in future companion specifications. A node MAY implement multiple SFs and run them at the same time. At least one SF MUST be running. The SFID field contained in all 6P messages allows a node to invoke the appropriate SF on a per-6P Transaction basis.
6top SF定义何时向邻居添加/删除单元格。不同的应用需要不同的SF；此主题超出了本文档的范围。不同的SF预计将在未来的配套规范中定义。一个节点可以实现多个SF并同时运行它们。必须至少运行一个SF。所有6P消息中包含的SFID字段允许节点在每个6P事务的基础上调用适当的SF。
Section 2 describes 6top. Section 3 defines 6P. Section 4 provides guidelines on how to define an SF.
第2节描述了6top。第3节定义了6P。第4节提供了如何定义SF的指南。
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]所述进行解释。
As depicted in Figure 2, 6top is the layer just above the IEEE Std 802.15.4 TSCH Medium Access Control (MAC) layer [IEEE802154]. We use "802.15.4" as a short version of "IEEE Std 802.15.4" in this document.
如图2所示，6top是IEEE Std 802.15.4 TSCH介质访问控制（MAC）层[IEEE802154]正上方的层。在本文档中，我们使用“802.15.4”作为“IEEE标准802.15.4”的简短版本。
.
| . |
| higher layers |
+------------------------------------------+
| 6top |
+------------------------------------------+
| IEEE Std 802.15.4 TSCH |
| . |
.
.
| . |
| higher layers |
+------------------------------------------+
| 6top |
+------------------------------------------+
| IEEE Std 802.15.4 TSCH |
| . |
.
Figure 2: 6top in the Protocol Stack
图2：协议栈中的6top
The roles of 6top are to:
6top的角色是：
o Terminate 6P, which allows neighbor nodes to communicate to add/delete cells to/on one another.
o 终止6P，它允许相邻节点相互通信以添加/删除单元。
o Run one or multiple 6top SFs, which define the rules that decide when to add/delete cells.
o 运行一个或多个6top SFs，它们定义决定何时添加/删除单元格的规则。
Each cell in the schedule is either "hard" or "soft":
明细表中的每个单元格都是“硬”或“软”：
o A soft cell can be read, added, deleted, or updated by 6top.
o 6top可以读取、添加、删除或更新软单元格。
o A hard cell is read-only for 6top.
o 硬单元对于6top是只读的。
In the context of this specification, all the cells used by 6top are soft cells. Hard cells can be used, for example, when "hard-coding" a schedule [RFC8180].
在本规范的上下文中，6top使用的所有单元格都是软单元格。例如，当“硬编码”时间表[RFC8180]时，可以使用硬单元。
6P MAY be used alongside the minimal 6TiSCH configuration [RFC8180]. In this case, it is RECOMMENDED to use two slotframes, as depicted in Figure 3:
6P可与最小6Disch配置一起使用[RFC8180]。在这种情况下，建议使用两个插槽框架，如图3所示：
o Slotframe 0 is used for traffic defined in the minimal 6TiSCH configuration. In Figure 3, Slotframe 0 is five slots long, but it can be shorter or longer.
o Slotframe 0用于最小6Disch配置中定义的流量。在图3中，Slotframe 0有五个插槽长，但可以更短或更长。
o 6P allocates cells from Slotframe 1. In Figure 3, Slotframe 1 is 10 slots long, but it can be shorter or longer.
o 6P从Slotframe 1分配单元格。在图3中，Slotframe 1有10个插槽长，但可以更短或更长。
| 0 1 2 3 4 | 0 1 2 3 4 |
+------------------------+------------------------+
Slotframe 0 | | | | | | | | | | |
5 slots long | EB | | | | | EB | | | | |
(Minimal 6TiSCH) | | | | | | | | | | |
+-------------------------------------------------+
| 0 1 2 3 4 | 0 1 2 3 4 |
+------------------------+------------------------+
Slotframe 0 | | | | | | | | | | |
5 slots long | EB | | | | | EB | | | | |
(Minimal 6TiSCH) | | | | | | | | | | |
+-------------------------------------------------+
| 0 1 2 3 4 5 6 7 8 9 |
+-------------------------------------------------+
Slotframe 1 | | | | | | | | | | |
10 slots long | |A->B| | | | | | |B->A| |
(6P) | | | | | | | | | | |
+-------------------------------------------------+
| 0 1 2 3 4 5 6 7 8 9 |
+-------------------------------------------------+
Slotframe 1 | | | | | | | | | | |
10 slots long | |A->B| | | | | | |B->A| |
(6P) | | | | | | | | | | |
+-------------------------------------------------+
Figure 3: 2-Slotframe Structure when Using 6P alongside the Minimal 6TiSCH Configuration
图3：使用6P和最小6Disch配置时的2-Slotframe结构
The minimal 6TiSCH configuration cell SHOULD be allocated from a slotframe of higher priority than the slotframe used by 6P for dynamic cell allocation. This way, dynamically allocated cells cannot "mask" the cells used by the minimal 6TiSCH configuration. 6top MAY support additional slotframes; how to use additional slotframes is out of scope for this document.
最小6Disch配置单元应从优先级高于6P用于动态单元分配的slotframe的slotframe分配。这样，动态分配的单元就不能“屏蔽”最小6Disch配置使用的单元。6top可以支持额外的slotframe；如何使用其他插槽框架超出了本文档的范围。
6P enables two neighbor nodes to add/delete/relocate cells in their TSCH schedule. Conceptually, two neighbor nodes "negotiate" the location of the cells to add, delete, or relocate in their TSCH schedule.
6P允许两个相邻节点在其TSCH调度中添加/删除/重新定位单元。从概念上讲，两个相邻节点“协商”要在其TSCH调度中添加、删除或重新定位的单元的位置。
We call "6P Transaction" a complete negotiation between two neighbor nodes. A particular 6P Transaction is executed between two nodes as a result of an action triggered by one SF. For a 6P Transaction to succeed, both nodes must use the same SF to handle the particular transaction. A 6P Transaction starts when a node wishes to add/delete/relocate one or more cells with one of its neighbors. A 6P Transaction ends when (1) the cell(s) has been added/deleted/ relocated in the schedule of both nodes or (2) the 6P Transaction has failed.
我们称“6P事务”为两个相邻节点之间的完全协商。由于一个SF触发的操作，在两个节点之间执行特定的6P事务。为了使6P事务成功，两个节点必须使用相同的SF来处理特定事务。当节点希望添加/删除/重新定位一个或多个与其邻居之一的单元时，6P事务开始。当（1）在两个节点的调度中添加/删除/重新定位单元或（2）6P事务失败时，6P事务结束。
6P messages exchanged between nodes A and B during a 6P Transaction SHOULD be exchanged on non-shared unicast cells ("dedicated" cells) between nodes A and B. If no dedicated cells are scheduled between nodes A and B, shared cells MAY be used.
在6P事务期间，节点A和B之间交换的6P消息应在节点A和B之间的非共享单播小区（“专用”小区）上交换。如果节点A和B之间没有调度专用小区，则可以使用共享小区。
Keeping consistency between the schedules of the two neighbor nodes is important. A loss of consistency can cause loss of connectivity. One example is when node A has a transmit cell to node B but node B does not have the corresponding reception cell. To verify consistency, neighbor nodes maintain a sequence number (SeqNum). Neighbor nodes exchange the SeqNum as part of each 6P Transaction to detect a possible inconsistency. This mechanism is explained in Section 3.4.6.2.
保持两个相邻节点的调度之间的一致性非常重要。一致性丢失可能会导致连接丢失。一个示例是当节点A具有到节点B的发射小区但节点B不具有相应的接收小区时。为了验证一致性，相邻节点维护一个序列号（SeqNum）。邻居节点交换SeqNum作为每个6P事务的一部分，以检测可能的不一致性。第3.4.6.2节解释了该机制。
An implementation MUST include a mechanism to associate each scheduled cell with the SF that scheduled it. This mechanism is implementation specific and is out of scope for this document.
实现必须包括一种机制，将每个调度单元与调度它的SF相关联。此机制是特定于实现的，不在本文档的范围内。
A 6P Transaction can consist of two or three steps. A 2-step transaction is used when node A selects the cells to be allocated. A 3-step transaction is used when node B selects the cells to be allocated. An SF MUST specify whether to use 2-step transactions, 3-step transactions, or both.
6P交易可以由两个或三个步骤组成。当节点A选择要分配的单元时，使用两步事务。当节点B选择要分配的单元时，使用三步事务。SF必须指定是使用两步事务、三步事务，还是两者都使用。
We illustrate 2-step and 3-step transactions using the topology in Figure 1.
我们使用图1中的拓扑说明了两步和三步事务。
Figure 4 shows an example 2-step 6P Transaction. In a 2-step transaction, node A selects the candidate cells. Several elements are left out so that the diagram is easier to understand.
图4显示了一个示例2步骤6P事务。在两步事务中，节点a选择候选单元。为了使图表更容易理解，省略了几个元素。
+----------+ +----------+
| Node A | | Node B |
+----+-----+ +-----+----+
| |
| 6P ADD Request |
| Type = REQUEST |
| Code = ADD |
| SeqNum = 123 |
cells | NumCells = 2 |
locked | CellList = [(1,2),(2,2),(3,5)] |
+-- |-------------------------------------->|
| | L2 ACK |
| 6P Timeout |<- - - - - - - - - - - - - - - - - - - |
| | | |
| | | 6P Response |
| | | Type = RESPONSE |
| | | Code = RC_SUCCESS |
| | | SeqNum = 123 | cells
| | | CellList = [(2,2),(3,5)] | locked
+-> X |<--------------------------------------| --+
| L2 ACK | |
| - - - - - - - - - - - - - - - - - - ->| <-+
| |
+----------+ +----------+
| Node A | | Node B |
+----+-----+ +-----+----+
| |
| 6P ADD Request |
| Type = REQUEST |
| Code = ADD |
| SeqNum = 123 |
cells | NumCells = 2 |
locked | CellList = [(1,2),(2,2),(3,5)] |
+-- |-------------------------------------->|
| | L2 ACK |
| 6P Timeout |<- - - - - - - - - - - - - - - - - - - |
| | | |
| | | 6P Response |
| | | Type = RESPONSE |
| | | Code = RC_SUCCESS |
| | | SeqNum = 123 | cells
| | | CellList = [(2,2),(3,5)] | locked
+-> X |<--------------------------------------| --+
| L2 ACK | |
| - - - - - - - - - - - - - - - - - - ->| <-+
| |
Figure 4: An Example 2-Step 6P Transaction
图4：示例2步骤6P事务
In this example, the 2-step transaction occurs as follows:
在本例中，两步事务发生如下：
1. The SF running on node A determines that two extra cells need to be scheduled to node B.
1. 在节点A上运行的SF确定需要向节点B调度两个额外的小区。
2. The SF running on node A selects candidate cells for node B to choose from. Node A MUST select at least as many candidate cells as the number of cells to add. Here, node A selects three candidate cells. Node A locks those candidate cells in its schedule until it receives a 6P Response.
2. 在节点A上运行的SF为节点B选择候选单元。节点A必须选择至少与要添加的单元格数量相同的候选单元格。这里，节点A选择三个候选单元。节点A在其调度中锁定这些候选小区，直到收到6P响应。
3. Node A sends a 6P ADD Request to node B, indicating that it wishes to add two cells (the "NumCells" value) and specifying the list of three candidate cells (the "CellList" value). Each cell in the CellList is a [slotOffset,channelOffset] tuple. This 6P ADD Request is link-layer acknowledged by node B (labeled "L2 ACK" in Figure 4).
3. 节点A向节点B发送6P ADD请求，指示它希望添加两个单元（“NumCells”值），并指定三个候选单元的列表（“cellllist”值）。CellList中的每个单元格都是一个[Slotofset，channelOffset]元组。这个6P ADD请求是由节点B确认的链路层（图4中标记为“L2 ACK”）。
4. After having successfully sent the 6P ADD Request (i.e., receiving the link-layer acknowledgment), node A starts a 6P Timeout to abort the 6P Transaction in the event that no response is received from node B.
4. 成功发送6P添加请求（即，接收链路层确认）后，节点A启动6P超时，以在没有从节点B收到响应的情况下中止6P事务。
5. The SF running on node B selects two out of the three cells from the CellList of the 6P ADD Request. Node B locks those cells in its schedule until the transmission is successful (i.e., node B receives a link-layer ACK from node A). Node B sends back a 6P Response to node A, indicating the cells it has selected. The response is link-layer acknowledged by node A.
5. 节点B上运行的SF从6P ADD请求的小区列表中选择三个小区中的两个。节点B在其调度中锁定这些小区，直到传输成功（即，节点B从节点a接收链路层ACK）。节点B向节点a发回一个6P响应，指示它已选择的小区。响应是由节点A确认的链路层。
6. Upon completion of this 6P Transaction, two cells from node A to node B have been added to the TSCH schedule of both nodes A and B.
6. 完成此6P事务后，从节点A到节点B的两个小区已添加到节点A和B的TSCH调度中。
7. An inconsistency in the schedule can happen if the 6P Timeout expires when the 6P Response is in the air, if the last link-layer ACK for the 6P Response is lost, or if one of the nodes is power-cycled during the transaction. 6P provides an inconsistency detection mechanism to cope with such situations; see Section 3.4.6.2 for details.
7. 如果6P响应在空中时6P超时过期，如果6P响应的最后一个链路层ACK丢失，或者如果其中一个节点在事务期间通电，则可能会发生调度不一致。6P提供了一种不一致性检测机制来应对这种情况；详见第3.4.6.2节。
Figure 5 shows an example 3-step 6P Transaction. In a 3-step transaction, node B selects the candidate cells. Several elements are left out so that the diagram is easier to understand.
图5显示了一个示例3步骤6P事务。在3步事务中，节点B选择候选单元。为了使图表更容易理解，省略了几个元素。
+----------+ +----------+
| Node A | | Node B |
+----+-----+ +-----+----+
| |
| 6P ADD Request |
| Type = REQUEST |
| Code = ADD |
| SeqNum = 178 |
| NumCells = 2 |
| CellList = [] |
|-------------------------------------->|
| L2 ACK |
6P Timeout |<- - - - - - - - - - - - - - - - - - - |
| | |
| | 6P Response |
| | Type = RESPONSE |
| | Code = RC_SUCCESS |
| | SeqNum = 178 | cells
| | CellList = [(1,2),(2,2),(3,5)] | locked
X |<--------------------------------------| --+
| L2 ACK | |
| - - - - - - - - - - - - - - - - - - ->| 6P Timeout |
| | | |
| 6P Confirmation | | |
| Type = CONFIRMATION | | |
| Code = RC_SUCCESS | | |
cells | SeqNum = 178 | | |
locked | CellList = [(2,2),(3,5)] | | |
+-- |-------------------------------------->| X <--+
| | L2 ACK |
+-> |<- - - - - - - - - - - - - - - - - - - |
| |
+----------+ +----------+
| Node A | | Node B |
+----+-----+ +-----+----+
| |
| 6P ADD Request |
| Type = REQUEST |
| Code = ADD |
| SeqNum = 178 |
| NumCells = 2 |
| CellList = [] |
|-------------------------------------->|
| L2 ACK |
6P Timeout |<- - - - - - - - - - - - - - - - - - - |
| | |
| | 6P Response |
| | Type = RESPONSE |
| | Code = RC_SUCCESS |
| | SeqNum = 178 | cells
| | CellList = [(1,2),(2,2),(3,5)] | locked
X |<--------------------------------------| --+
| L2 ACK | |
| - - - - - - - - - - - - - - - - - - ->| 6P Timeout |
| | | |
| 6P Confirmation | | |
| Type = CONFIRMATION | | |
| Code = RC_SUCCESS | | |
cells | SeqNum = 178 | | |
locked | CellList = [(2,2),(3,5)] | | |
+-- |-------------------------------------->| X <--+
| | L2 ACK |
+-> |<- - - - - - - - - - - - - - - - - - - |
| |
Figure 5: An Example 3-Step 6P Transaction
图5：一个示例3步骤6P事务
In this example, the 3-step transaction occurs as follows:
在此示例中，三步事务发生如下：
1. The SF running on node A determines that two extra cells need to be scheduled to node B. The SF uses a 3-step transaction, so it does not select candidate cells.
1. 在节点A上运行的SF确定需要将两个额外的小区调度到节点B。SF使用三步事务，因此它不选择候选小区。
2. Node A sends a 6P ADD Request to node B, indicating that it wishes to add two cells (the "NumCells" value), with an empty "CellList". This 6P ADD Request is link-layer acknowledged by node B.
2. 节点A向节点B发送一个6P添加请求，指示它希望添加两个单元格（“NumCells”值），其中包含一个空的“CellList”。此6P添加请求由节点B确认为链路层。
3. After having successfully sent the 6P ADD Request, node A starts a 6P Timeout to abort the transaction in the event that no 6P Response is received from node B.
3. 成功发送6P ADD请求后，如果没有从节点B接收到6P响应，节点A将启动6P超时以中止事务。
4. The SF running on node B selects three candidate cells and locks them. Node B sends back a 6P Response to node A, indicating the three cells it has selected. The response is link-layer acknowledged by node A.
4. 在节点B上运行的SF选择三个候选小区并锁定它们。节点B向节点a发回一个6P响应，指示它已选择的三个小区。响应是由节点A确认的链路层。
5. After having successfully sent the 6P Response, node B starts a 6P Timeout to abort the transaction in the event that no 6P Confirmation is received from node A.
5. 成功发送6P响应后，如果没有从节点a收到6P确认，节点B将启动6P超时以中止事务。
6. The SF running on node A selects two cells from the CellList field in the 6P Response and locks them. Node A sends back a 6P Confirmation to node B, indicating the cells it selected. The confirmation is link-layer acknowledged by node B.
6. 节点A上运行的SF从6P响应中的CellList字段中选择两个单元格并锁定它们。节点A向节点B发回一个6P确认，指示它选择的单元。确认是由节点B确认的链路层。
7. Upon completion of the 6P Transaction, two cells from node A to node B have been added to the TSCH schedule of both nodes A and B.
7. 完成6P事务后，从节点A到节点B的两个小区已添加到节点A和B的TSCH调度中。
8. An inconsistency in the schedule can happen if the 6P Timeout expires when the 6P Confirmation is in the air, if the last link-layer ACK for the 6P Confirmation is lost, or if one of the nodes is power-cycled during the transaction. 6P provides an inconsistency detection mechanism to cope with such situations; see Section 3.4.6.2 for details.
8. 如果6P确认在空中时6P超时过期，如果6P确认的最后一个链路层ACK丢失，或者如果其中一个节点在事务期间通电，则可能会发生调度不一致。6P提供了一种不一致性检测机制来应对这种情况；详见第3.4.6.2节。
6P messages travel over a single hop. 6P messages are carried as payload of an 802.15.4 Payload Information Element (IE) [IEEE802154]. The messages are encapsulated within the Payload IE header. The Group ID is set to the IETF IE value defined in [RFC8137]. The content is encapsulated by a subtype ID, as defined in [RFC8137].
6P消息在单跳上传输。6P消息作为802.15.4有效负载信息元素（IE）[IEEE802154]的有效负载进行传输。这些消息封装在有效负载IE报头中。组ID设置为[RFC8137]中定义的IETF IE值。内容由[RFC8137]中定义的子类型ID封装。
Since 6P messages are carried in IEs, IEEE bit/byte ordering applies. Bits within each field in the "6top IE" subtype 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 copied to the packet in the order from the octet containing the lowest-numbered bits to the octet containing the highest-numbered bits (little endian).
由于6P消息在IEs中传输，因此IEEE位/字节顺序适用。“6top IE”子类型中每个字段内的位从0（最左侧和最低有效）到k-1（最右侧和最高有效）进行编号，其中字段的长度为k位。长度超过单个八位字节的字段按从包含编号最低位的八位字节到包含编号最高位的八位字节（小端）的顺序复制到数据包中。
This document defines the 6top IE, a subtype of the IETF IE defined in [RFC8137], with subtype SUBID_6TOP. The subtype content of the 6top IE is defined in Section 3.2.2. The length of the 6top IE content is variable.
本文档定义了6top IE，即[RFC8137]中定义的IETF IE的子类型，子类型为SUBID_6top。第3.2.2节定义了6top IE的子类型内容。6top IE内容的长度是可变的。
All 6P messages follow the generic format shown in Figure 6.
所有6P消息都遵循图6所示的通用格式。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| T | R | Code | SFID | SeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Other Fields...
+-+-+-+-+-+-+-+-+-
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| T | R | Code | SFID | SeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Other Fields...
+-+-+-+-+-+-+-+-+-
Figure 6: Generic 6P Message Format
图6：通用6P消息格式
6P Version (Version): The version of 6P. Only version 0 is defined in this document. Future specifications may define subsequent versions of 6P.
6P版本（Version）：6P的版本。此文档中仅定义了版本0。未来的规范可能会定义6P的后续版本。
Type (T): The type of message. The message types are defined in Section 6.2.2.
类型（T）：消息的类型。第6.2.2节定义了消息类型。
Reserved (R): Reserved bits. These two bits SHOULD be set to zero when sending the message and MUST be ignored upon reception.
保留（R）：保留位。发送消息时，这两个位应设置为零，接收时必须忽略。
Code: The Code field contains a 6P command identifier when the 6P message has a Type value of REQUEST. Section 6.2.3 lists the 6P command identifiers. The Code field contains a 6P return code when the 6P message has a Type value of RESPONSE or CONFIRMATION. Section 6.2.4 lists the 6P return codes. The same return codes are used in both 6P Response and 6P Confirmation messages.
代码：当6P消息的类型值为REQUEST时，代码字段包含6P命令标识符。第6.2.3节列出了6P命令标识符。当6P消息具有响应或确认类型值时，代码字段包含6P返回代码。第6.2.4节列出了6P返回代码。在6P响应和6P确认消息中使用相同的返回代码。
6top Scheduling Function Identifier (SFID): The identifier of the SF to use to handle this message. The SFID is defined in Section 4.1.
6top调度功能标识符（SFID）：用于处理此消息的SF的标识符。SFID的定义见第4.1节。
SeqNum: The sequence number associated with the 6P Transaction. Used to match the 6P Request, 6P Response, and 6P Confirmation of the same 6P Transaction. The value of SeqNum MUST be different for each new 6P Request issued to the same neighbor and using the same SF. The SeqNum is also used to ensure consistency between the schedules of the two neighbors. Section 3.4.6 details how the SeqNum is managed.
SeqNum：与6P事务相关联的序列号。用于匹配同一6P事务的6P请求、6P响应和6P确认。对于发出给同一邻居并使用相同SF的每个新6P请求，SeqNum的值必须不同。SeqNum还用于确保两个邻居的计划之间的一致性。第3.4.6节详细说明了如何管理SeqNum。
Other Fields: The list of other fields and how they are used are detailed in Section 3.3.
其他字段：第3.3节详细介绍了其他字段的列表及其使用方法。
6P Request, 6P Response, and 6P Confirmation messages for a given transaction MUST share the same Version, SFID, and SeqNum values.
给定事务的6P请求、6P响应和6P确认消息必须共享相同的版本、SFID和SeqNum值。
Future versions of the 6P message SHOULD maintain the format of the 6P Version, Type, and Code fields for backward compatibility.
6P消息的未来版本应保持6P版本、类型和代码字段的格式，以实现向后兼容性。
An 8-bit 6P CellOptions bitmap is present in the following 6P Requests: ADD, DELETE, COUNT, LIST, and RELOCATE. The format and meaning of this field MAY be redefined by the SF; the routine that parses this field is therefore associated with a specific SF.
8位6P CellOptions位图出现在以下6P请求中：添加、删除、计数、列出和重新定位。SF可重新定义该字段的格式和含义；因此，解析此字段的例程与特定SF关联。
o In the 6P ADD Request, the 6P CellOptions bitmap is used to specify what type of cell to add.
o 在6P添加请求中，6P CellOptions位图用于指定要添加的单元格类型。
o In the 6P DELETE Request, the 6P CellOptions bitmap is used to specify what type of cell to delete.
o 在6P删除请求中，6P CellOptions位图用于指定要删除的单元格类型。
o In the 6P RELOCATE Request, the 6P CellOptions bitmap is used to specify what type of cell to relocate.
o 在6P重新定位请求中，6P CellOptions位图用于指定要重新定位的单元格类型。
o In the 6P COUNT and LIST Requests, the 6P CellOptions bitmap is used as a selector of a particular type of cells.
o 在6P计数和列表请求中，6P CellOptions位图用作特定类型单元格的选择器。
The content of the 6P CellOptions bitmap applies to all elements in the CellList field. The possible values of the 6P CellOptions are as follows:
6P CellOptions位图的内容适用于CellList字段中的所有元素。6P Celloption的可能值如下所示：
o TX = 1 (resp. 0) refers to macTxType = TRUE (resp. FALSE) in the macLinkTable of 802.15.4 [IEEE802154].
o TX=1（分别为0）指802.15.4[IEEE802154]的macLinkTable中的macTxType=TRUE（分别为FALSE）。
o RX = 1 (resp. 0) refers to macRxType = TRUE (resp. FALSE) in the macLinkTable of 802.15.4.
o RX=1（分别为0）指802.15.4的macLinkTable中的macRxType=TRUE（分别为FALSE）。
o S = 1 (resp. 0) refers to macSharedType = TRUE (resp. FALSE) in the macLinkTable of 802.15.4.
o S=1（resp.0）表示802.15.4的macLinkTable中的macSharedType=TRUE（resp.FALSE）。
Section 6.2.6 provides the format of the 6P CellOptions bitmap; this format applies unless redefined by the SF. Figure 7 shows the meaning of the 6P CellOptions bitmap for the 6P ADD, DELETE, and RELOCATE Requests (unless redefined by the SF). Figure 8 shows the meaning of the 6P CellOptions bitmap for the 6P COUNT and LIST Requests (unless redefined by the SF).
第6.2.6节提供了6P CellOptions位图的格式；除非SF重新定义，否则此格式适用。图7显示了6P添加、删除和重新定位请求的6P CellOptions位图的含义（除非SF重新定义）。图8显示了6P CellOptions位图对于6P计数和列表请求的意义（除非SF重新定义）。
Note: Here, we assume that node A issues the 6P command to node B.
+-------------+-----------------------------------------------------+
| CellOptions | The type of cells B adds/deletes/relocates to its |
| Value | schedule when receiving a 6P ADD/DELETE/RELOCATE |
| | Request from A |
+-------------+-----------------------------------------------------+
|TX=0,RX=0,S=0| Invalid combination. RC_ERR is returned |
+-------------+-----------------------------------------------------+
|TX=1,RX=0,S=0| Add/delete/relocate RX cells at B (TX cells at A) |
+-------------+-----------------------------------------------------+
|TX=0,RX=1,S=0| Add/delete/relocate TX cells at B (RX cells at A) |
+-------------+-----------------------------------------------------+
|TX=1,RX=1,S=0| Add/delete/relocate TX|RX cells at B (and at A) |
+-------------+-----------------------------------------------------+
|TX=0,RX=0,S=1| Invalid combination. RC_ERR is returned |
+-------------+-----------------------------------------------------+
|TX=1,RX=0,S=1| Add/delete/relocate RX|SHARED cells at B |
| | (TX|SHARED cells at A) |
+-------------+-----------------------------------------------------+
|TX=0,RX=1,S=1| Add/delete/relocate TX|SHARED cells at B |
| | (RX|SHARED cells at A) |
+-------------+-----------------------------------------------------+
|TX=1,RX=1,S=1| Add/delete/relocate TX|RX|SHARED cells at B |
| | (and at A) |
+-------------+-----------------------------------------------------+
Note: Here, we assume that node A issues the 6P command to node B.
+-------------+-----------------------------------------------------+
| CellOptions | The type of cells B adds/deletes/relocates to its |
| Value | schedule when receiving a 6P ADD/DELETE/RELOCATE |
| | Request from A |
+-------------+-----------------------------------------------------+
|TX=0,RX=0,S=0| Invalid combination. RC_ERR is returned |
+-------------+-----------------------------------------------------+
|TX=1,RX=0,S=0| Add/delete/relocate RX cells at B (TX cells at A) |
+-------------+-----------------------------------------------------+
|TX=0,RX=1,S=0| Add/delete/relocate TX cells at B (RX cells at A) |
+-------------+-----------------------------------------------------+
|TX=1,RX=1,S=0| Add/delete/relocate TX|RX cells at B (and at A) |
+-------------+-----------------------------------------------------+
|TX=0,RX=0,S=1| Invalid combination. RC_ERR is returned |
+-------------+-----------------------------------------------------+
|TX=1,RX=0,S=1| Add/delete/relocate RX|SHARED cells at B |
| | (TX|SHARED cells at A) |
+-------------+-----------------------------------------------------+
|TX=0,RX=1,S=1| Add/delete/relocate TX|SHARED cells at B |
| | (RX|SHARED cells at A) |
+-------------+-----------------------------------------------------+
|TX=1,RX=1,S=1| Add/delete/relocate TX|RX|SHARED cells at B |
| | (and at A) |
+-------------+-----------------------------------------------------+
Figure 7: Meaning of the 6P CellOptions Bitmap for the 6P ADD, DELETE, and RELOCATE Requests
图7:6P添加、删除和重新定位请求的6P CellOptions位图的含义
Note: Here, we assume that node A issues the 6P command to node B.
+-------------+-----------------------------------------------------+
| CellOptions | The type of cells B selects from its schedule when |
| Value | receiving a 6P COUNT or LIST Request from A, |
| | from all the cells B has scheduled with A |
+-------------+-----------------------------------------------------+
|TX=0,RX=0,S=0| All cells |
+-------------+-----------------------------------------------------+
|TX=1,RX=0,S=0| All cells marked as RX only |
+-------------+-----------------------------------------------------+
|TX=0,RX=1,S=0| All cells marked as TX only |
+-------------+-----------------------------------------------------+
|TX=1,RX=1,S=0| All cells marked as TX and RX only |
+-------------+-----------------------------------------------------+
|TX=0,RX=0,S=1| All cells marked as SHARED (regardless of TX, RX) |
+-------------+-----------------------------------------------------+
|TX=1,RX=0,S=1| All cells marked as RX and SHARED only |
+-------------+-----------------------------------------------------+
|TX=0,RX=1,S=1| All cells marked as TX and SHARED only |
+-------------+-----------------------------------------------------+
|TX=1,RX=1,S=1| All cells marked as TX, RX, and SHARED |
+-------------+-----------------------------------------------------+
Note: Here, we assume that node A issues the 6P command to node B.
+-------------+-----------------------------------------------------+
| CellOptions | The type of cells B selects from its schedule when |
| Value | receiving a 6P COUNT or LIST Request from A, |
| | from all the cells B has scheduled with A |
+-------------+-----------------------------------------------------+
|TX=0,RX=0,S=0| All cells |
+-------------+-----------------------------------------------------+
|TX=1,RX=0,S=0| All cells marked as RX only |
+-------------+-----------------------------------------------------+
|TX=0,RX=1,S=0| All cells marked as TX only |
+-------------+-----------------------------------------------------+
|TX=1,RX=1,S=0| All cells marked as TX and RX only |
+-------------+-----------------------------------------------------+
|TX=0,RX=0,S=1| All cells marked as SHARED (regardless of TX, RX) |
+-------------+-----------------------------------------------------+
|TX=1,RX=0,S=1| All cells marked as RX and SHARED only |
+-------------+-----------------------------------------------------+
|TX=0,RX=1,S=1| All cells marked as TX and SHARED only |
+-------------+-----------------------------------------------------+
|TX=1,RX=1,S=1| All cells marked as TX, RX, and SHARED |
+-------------+-----------------------------------------------------+
Figure 8: Meaning of the 6P CellOptions Bitmap for the 6P COUNT and LIST Requests
图8:6P CellOptions位图对于6P计数和列表请求的意义
The CellOptions constitute an opaque set of bits, sent unmodified to the SF. The SF MAY redefine the format and meaning of the CellOptions field.
Celloption构成一组不透明的位，未经修改发送到SF。SF可以重新定义CellOptions字段的格式和含义。
A CellList field MAY be present in a 6P ADD Request, a 6P DELETE Request, a 6P RELOCATE Request, a 6P Response, or a 6P Confirmation. It is composed of a concatenation of zero or more 6P Cells as defined in Figure 9. The content of the CellOptions field specifies the options associated with all cells in the CellList. This necessarily means that the same options are associated with all cells in the CellList.
小区列表字段可能出现在6P添加请求、6P删除请求、6P重新定位请求、6P响应或6P确认中。它由零个或多个6P单元串联而成，如图9所示。CellOptions字段的内容指定与CellList中所有单元格关联的选项。这必然意味着相同的选项与CellList中的所有单元格相关联。
A 6P Cell is a 4-byte field; its default format is:
6P单元是一个4字节的字段；其默认格式为：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| slotOffset | channelOffset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| slotOffset | channelOffset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: 6P Cell Format
图9:6P单元格式
slotOffset: The slot offset of the cell.
slotOffset：单元格的插槽偏移量。
channelOffset: The channel offset of the cell.
channelOffset：单元格的通道偏移。
The CellList is an opaque set of bytes, sent unmodified to the SF. The length of the CellList field is implicit and is determined by the IE Length field of the Payload IE header as defined in 802.15.4. The SF MAY redefine the format of the CellList field; the routine that parses this field is therefore associated with a specific SF.
CellList是一组不透明的字节，未经修改发送到SF。CellList字段的长度是隐式的，由802.15.4中定义的有效负载IE报头的IE长度字段确定。SF可以重新定义CellList字段的格式；因此，解析此字段的例程与特定SF关联。
Cells are added by using the 6P ADD command. The Type field (T) is set to REQUEST. The Code field is set to ADD. Figure 10 defines the format of a 6P ADD Request.
使用6P ADD命令添加单元格。类型字段（T）设置为请求。“代码”字段设置为“添加”。图10定义了6P添加请求的格式。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| T | R | Code | SFID | SeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metadata | CellOptions | NumCells |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CellList ...
+-+-+-+-+-+-+-+-+-
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| T | R | Code | SFID | SeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metadata | CellOptions | NumCells |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CellList ...
+-+-+-+-+-+-+-+-+-
Figure 10: 6P ADD Request Format
图10:6P添加请求格式
Metadata: Used as extra signaling to the SF. The contents of the Metadata field are an opaque set of bytes passed unmodified to the SF. The meaning of this field depends on the SF and is out of scope for this document. For example, Metadata can specify in which slotframe to add the cells.
元数据：用作SF的额外信令。元数据字段的内容是一组不透明的字节，未经修改就传递给SF。该字段的含义取决于SF，不在本文件范围内。例如，元数据可以指定在哪个slotframe中添加单元格。
CellOptions: Indicates the options to associate with the cells to be added. If more than one cell is added (NumCells > 1), the same options are associated with each one. This necessarily means that if node A needs to add multiple cells with different options it needs to initiate multiple 6P ADD Transactions.
CellOptions：指示与要添加的单元格关联的选项。如果添加了多个单元格（NumCells>1），则每个单元格都会关联相同的选项。这必然意味着，如果节点A需要添加具有不同选项的多个单元格，则需要启动多个6P add事务。
NumCells: The number of additional cells node A wants to schedule to node B.
NumCells：节点A希望调度到节点B的附加单元数。
CellList: A list of zero or multiple candidate cells. Its length is implicit and is determined by the Length field of the Payload IE header.
单元格列表：由零个或多个候选单元格组成的列表。其长度是隐式的，由有效负载IE报头的长度字段确定。
Figure 11 defines the format of a 6P ADD Response and Confirmation.
图11定义了6P ADD响应和确认的格式。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| T | R | Code | SFID | SeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CellList ...
+-+-+-+-+-+-+-+-+-
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| T | R | Code | SFID | SeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CellList ...
+-+-+-+-+-+-+-+-+-
Figure 11: 6P ADD Response and Confirmation Format
图11:6P添加响应和确认格式
CellList: A list of zero or more 6P Cells.
CellList：零个或多个6P单元的列表。
Consider the topology in Figure 1; in this case, the SF on node A decides to add NumCells cells to node B.
考虑图1中的拓扑结构；在这种情况下，节点A上的SF决定将NumCells单元添加到节点B。
Node A's SF selects NumCandidate cells from its schedule. These are cells that are candidates to be scheduled with node B. The CellOptions field specifies the type of these cells. NumCandidate MUST be greater than or equal to NumCells. How many cells node A selects (NumCandidate) and how that selection is done are specified in the SF and are out of scope for this document. Node A sends a 6P ADD Request to node B that contains the CellOptions, the value of NumCells, and a selection of NumCandidate cells in the CellList. If the NumCandidate cells do not fit in a single packet, this operation MUST be split into multiple independent 6P ADD Requests, each for a subset of the number of cells that eventually need to be added. In the case of a 3-step transaction, the SF is responsible for ensuring that the returned Candidate CellList fits into the 6P Response.
节点A的SF从其计划中选择NumCandidate单元格。这些单元格是要与节点B一起调度的候选单元格。CellOptions字段指定这些单元格的类型。NumCandidate必须大于或等于NumCells。节点A选择的单元格数量（NumCandidate）和选择方式在SF中指定，不在本文档的范围内。节点A向节点B发送一个6P添加请求，该请求包含CellOptions、NumCells的值以及CellList中NumCandidate单元格的选择。如果NumCandidate单元格不适合单个数据包，则必须将此操作拆分为多个独立的6P ADD请求，每个请求对应最终需要添加的单元格数的子集。在三步事务的情况下，SF负责确保返回的候选单元格列表符合6P响应。
Upon receiving the request, node B checks to see whether the CellOptions are set to a valid value as noted by Figure 7. If this is not the case, a Response with code RC_ERR is returned. If the number of cells in the received CellList in node B is smaller than NumCells, node B MUST return a 6P Response with the RC_ERR_CELLLIST code. Otherwise, node B's SF verifies which of the cells in the CellList it can install in node B's schedule, following the specified CellOptions field. How that selection is done is specified in the SF and is out of scope for this document. The verification can succeed (NumCells cells from the CellList can be used), fail (none of the cells from the CellList can be used), or partially succeed (fewer than NumCells cells from the CellList can be used). In all cases, node B MUST send a 6P Response that includes a return code set to RC_SUCCESS and that specifies the list of cells that were scheduled following the CellOptions field. That list can contain NumCells elements (succeed), 0 elements (fail), or between 0 and NumCells elements (partially succeed).
收到请求后，节点B检查Celloption是否设置为有效值，如图7所示。如果不是这种情况，则返回代码为RC_ERR的响应。如果节点B中接收到的小区列表中的小区数小于NumCells，则节点B必须返回带有RC_ERR_小区列表代码的6P响应。否则，节点B的SF将根据指定的CellOptions字段验证它可以在节点B的计划中安装CellList中的哪些单元。SF中规定了如何进行选择，这超出了本文件的范围。验证可以成功（可以使用CellList中的NumCells单元格）、失败（不能使用CellList中的任何单元格）或部分成功（可以使用CellList中少于NumCells的单元格）。在所有情况下，节点B都必须发送一个6P响应，该响应包括一个设置为RC_SUCCESS的返回码，并指定在CellOptions字段之后调度的单元列表。该列表可以包含NumCells元素（成功）、0个元素（失败），或介于0和NumCells元素之间（部分成功）。
Upon receiving the response, node A adds the cells specified in the CellList according to the CellOptions field.
收到响应后，节点A根据CellOptions字段添加CellList中指定的单元。
Cells are deleted by using the 6P DELETE command. The Type field (T) is set to REQUEST. The Code field is set to DELETE. Figure 12 defines the format of a 6P DELETE Request.
使用6P DELETE命令删除单元格。类型字段（T）设置为请求。代码字段设置为删除。图12定义了6P删除请求的格式。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| T | R | Code | SFID | SeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metadata | CellOptions | NumCells |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CellList ...
+-+-+-+-+-+-+-+-+-
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| T | R | Code | SFID | SeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metadata | CellOptions | NumCells |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CellList ...
+-+-+-+-+-+-+-+-+-
Figure 12: 6P DELETE Request Format
图12:6P删除请求格式
Metadata: Same usage as for the 6P ADD command; see Section 3.3.1. Its format is the same as that in the 6P ADD command, but its content could be different.
元数据：与6P ADD命令的用法相同；见第3.3.1节。其格式与6P ADD命令中的格式相同，但其内容可能不同。
CellOptions: Indicates the options that need to be associated with the cells to delete. Only cells matching the CellOptions can be deleted.
CellOptions：指示需要与要删除的单元格关联的选项。只能删除与选项匹配的单元格。
NumCells: The number of cells from the specified CellList the sender wants to delete from the schedule of both sender and receiver.
NumCells：发送方希望从发送方和接收方的计划中删除的指定单元列表中的单元数。
CellList: A list of zero or more 6P Cells. Its length is determined by the Length field of the Payload IE header.
CellList：零个或多个6P单元的列表。其长度由有效负载IE标头的长度字段确定。
Figure 13 defines the format of a 6P DELETE Response and Confirmation.
图13定义了6P删除响应和确认的格式。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| T | R | Code | SFID | SeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CellList ...
+-+-+-+-+-+-+-+-+-
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| T | R | Code | SFID | SeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CellList ...
+-+-+-+-+-+-+-+-+-
Figure 13: 6P DELETE Response and Confirmation Format
图13:6P删除响应和确认格式
CellList: A list of zero or more 6P Cells.
CellList：零个或多个6P单元的列表。
The behavior for deleting cells is equivalent to that of adding cells except that:
删除单元格的行为与添加单元格的行为相同，只是：
o The nodes delete the cells they agree upon rather than adding them.
o 节点删除它们同意的单元格，而不是添加它们。
o All cells in the CellList MUST already be scheduled between the two nodes and MUST match the CellOptions field. If node A puts cells in its CellList that are not already scheduled between the two nodes and match the CellOptions field, node B MUST reply with a RC_ERR_CELLLIST return code.
o CellList中的所有单元格必须已在两个节点之间调度，并且必须与CellOptions字段匹配。如果节点A将尚未在两个节点之间调度的单元格放入其CellList中，并且与CellOptions字段匹配，则节点B必须使用RC_ERR_CellList返回代码进行回复。
o The CellList in a 6P Request (2-step transaction) or 6P Response (3-step transaction) MUST be empty, contain exactly NumCells cells, or contain more than NumCells cells. The case where the CellList is not empty but contains fewer than NumCells cells is not supported; the RC_ERR_CELLLIST code MUST be returned when the CellList contains fewer than NumCells cells. If the CellList is empty, the SF on the receiving node MUST choose NumCells cells scheduled to the sender matching the CellOptions field and delete them. If the CellList contains more than NumCells cells, the SF on the receiving node chooses exactly NumCells cells from the CellList to delete.
o 6P请求（2步事务）或6P响应（3步事务）中的单元格列表必须为空，且包含的单元格必须正好是NumCells单元格，或者包含的单元格不能超过NumCells。不支持CellList不为空但包含少于NumCells个单元格的情况；当CELLLIST包含的单元格少于NumCells时，必须返回RC_ERR_CELLLIST代码。如果CellList为空，则接收节点上的SF必须选择与CellOptions字段匹配的发送方计划的NumCells单元格，并将其删除。如果CellList包含多个NumCells单元格，则接收节点上的SF会从CellList中选择要删除的NumCells单元格。
Cell relocation consists of moving a cell to a different [slotOffset,channelOffset] location in the schedule. The Type field (T) is set to REQUEST. The Code field is set to RELOCATE. Figure 14 defines the format of a 6P RELOCATE Request.
单元重新定位包括将单元移动到计划中不同的[Slotofset，channelOffset]位置。类型字段（T）设置为请求。代码字段设置为重新定位。图14定义了6P重新定位请求的格式。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| T | R | Code | SFID | SeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metadata | CellOptions | NumCells |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Relocation CellList ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Candidate CellList ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| T | R | Code | SFID | SeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metadata | CellOptions | NumCells |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Relocation CellList ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Candidate CellList ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 14: 6P RELOCATE Request Format
图14:6P重新定位请求格式
Metadata: Same usage as for the 6P ADD command; see Section 3.3.1.
元数据：与6P ADD命令的用法相同；见第3.3.1节。
CellOptions: Indicates the options that need to be associated with cells to be relocated.
CellOptions：指示需要与要重新定位的单元格关联的选项。
NumCells: The number of cells to relocate. MUST be greater than or equal to 1.
NumCells：要重新定位的单元格数。必须大于或等于1。
Relocation CellList: The list of NumCells 6P Cells to relocate.
重新定位单元列表：要重新定位的NumCells 6P单元的列表。
Candidate CellList: A list of NumCandidate candidate cells for node B to pick from. NumCandidate MUST be 0, equal to NumCells, or greater than NumCells. Its length is determined by the Length field of the Payload IE header.
候选单元格列表：节点B要从中选择的NumCandidate候选单元格列表。NumCandidate必须为0、等于NumCells或大于NumCells。其长度由有效负载IE标头的长度字段确定。
In a 2-step 6P RELOCATE Transaction, node A specifies both (1) the cells it needs to relocate and (2) the list of candidate cells to relocate to. The Relocation CellList MUST contain exactly NumCells entries. The Candidate CellList MUST contain at least NumCells entries (NumCandidate >= NumCells).
在两步6P重新定位事务中，节点a指定（1）需要重新定位的单元格和（2）要重新定位的候选单元格列表。重新定位单元列表必须完全包含NumCells条目。候选单元格列表必须至少包含NumCells条目（NumCandidate>=NumCells）。
In a 3-step 6P RELOCATE Transaction, node A specifies only the cells it needs to relocate -- not the list of candidate cells to relocate to. The Candidate CellList MUST therefore be empty.
在3步6P重定位事务中，节点a只指定需要重定位的单元，而不是要重定位到的候选单元列表。因此，候选单元格列表必须为空。
Figure 15 defines the format of a 6P RELOCATE Response and Confirmation.
图15定义了6P重新定位响应和确认的格式。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| T | R | Code | SFID | SeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CellList ...
+-+-+-+-+-+-+-+-+-
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| T | R | Code | SFID | SeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CellList ...
+-+-+-+-+-+-+-+-+-
Figure 15: 6P RELOCATE Response and Confirmation Format
图15:6P重新定位响应和确认格式
CellList: A list of zero or more 6P Cells.
CellList：零个或多个6P单元的列表。
Node A's SF wants to relocate NumCells cells. Node A creates a 6P RELOCATE Request and indicates the cells it wants to relocate in the Relocation CellList. It also selects NumCandidate cells from its schedule as candidate cells to relocate the cells to, and it puts them in the Candidate CellList. The CellOptions field specifies the type of the cell(s) to relocate. NumCandidate MUST be greater than or equal to NumCells. How many cells it selects (NumCandidate) and how that selection is done are specified in the SF and are out of scope for this document. Node A sends the 6P RELOCATE Request to node B.
节点A的SF希望重新定位NumCells单元。节点A创建一个6P重定位请求，并在重定位单元列表中指示它想要重定位的单元。它还从其计划中选择NumCandidate单元格作为候选单元格，以将这些单元格重新定位到其中，并将它们放入候选单元格列表中。CellOptions字段指定要重新定位的单元格类型。NumCandidate必须大于或等于NumCells。它选择了多少单元格（NumCandidate）以及选择的方式在SF中指定，并且超出了本文档的范围。节点A向节点B发送6P重新定位请求。
Upon receiving the request, node B checks to see if the length of the Candidate CellList is greater than or equal to NumCells. Node B's SF verifies that all the cells in the Relocation CellList are scheduled with node A and are associated with the options specified in the CellOptions field. If either check fails, node B MUST send a 6P Response to node A with return code RC_ERR_CELLLIST. If both checks pass, node B's SF verifies which of the cells in the Candidate CellList it can install in its schedule. How that selection is done is specified in the SF and is out of scope for this document. That verification for the Candidate CellList can succeed (NumCells cells from the Candidate CellList can be used), fail (none of the cells from the Candidate CellList can be used), or partially succeed (fewer than NumCells cells from the Candidate CellList can be used). In all cases, node B MUST send a 6P Response that includes a return code set to RC_SUCCESS and that specifies the list of cells that will be rescheduled following the CellOptions field. That list can contain NumCells elements (succeed), 0 elements (fail), or between 0 and NumCells elements (partially succeed). If N < NumCells cells appear in the CellList, this means that the first N cells in the Relocation CellList have been relocated and the remainder have not.
在接收到请求后，节点B检查候选小区列表的长度是否大于或等于NumCells。节点B的SF验证重新定位单元列表中的所有单元是否与节点A一起调度，并与CellOptions字段中指定的选项相关联。如果任一检查失败，节点B必须向节点a发送一个6P响应，返回代码为RC_ERR_CELLLIST。如果两个检查都通过，节点B的SF将验证候选小区列表中的哪些小区可以安装在其计划中。SF中规定了如何进行选择，这超出了本文件的范围。对候选单元格列表的验证可以成功（可以使用候选单元格列表中的NumCells单元格）、失败（不能使用任何候选单元格列表中的单元格）或部分成功（可以使用少于候选单元格列表中的NumCells单元格）。在所有情况下，节点B必须发送一个6P响应，该响应包括一个设置为RC_SUCCESS的返回码，并指定将在CellOptions字段之后重新调度的单元列表。该列表可以包含NumCells元素（成功）、0个元素（失败），或介于0和NumCells元素之间（部分成功）。如果N<NumCells个单元格出现在CellList中，这意味着重新定位单元格列表中的前N个单元格已重新定位，其余单元格未重新定位。
Upon receiving the response with code RC_SUCCESS, node A relocates the cells specified in the Relocation CellList of its RELOCATE Request to the new locations specified in the CellList of the 6P Response, in the same order. If the received return code is RC_ERR_CELLLIST, the transaction is aborted and no cell is relocated. In the case of a 2-step transaction, node B relocates the selected cells upon receiving the link-layer ACK for the 6P Response. In the case of a 3-step transaction, node B relocates the selected cells upon receiving the 6P Confirmation.
在接收到代码为RC_SUCCESS的响应后，节点A按照相同的顺序将其重新定位请求的重新定位单元列表中指定的单元重新定位到6P响应的单元列表中指定的新位置。如果收到的返回代码是RC_ERR_CELLLIST，则事务将中止，并且不会重新定位任何单元格。在两步事务的情况下，节点B在接收到用于6P响应的链路层ACK时重新定位所选小区。在三步事务的情况下，节点B在接收到6P确认后重新定位所选单元。
The SF SHOULD NOT relocate all cells between two nodes at the same time, as this might result in the schedules of both nodes diverging significantly.
SF不应同时在两个节点之间重新定位所有小区，因为这可能会导致两个节点的调度出现显著差异。
Figure 16 shows an example of a successful 2-step 6P RELOCATE Transaction.
图16显示了一个成功的两步6P重定位事务的示例。
+----------+ +----------+
| Node A | | Node B |
+----+-----+ +-----+----+
| |
| 6P RELOCATE Request |
| Type = REQUEST |
| Code = RELOCATE |
| SeqNum = 11 |
| NumCells = 2 |
| R.CellList = [(1,2),(2,2)] |
| C.CellList = [(3,3),(4,3),(5,3)] |
|-------------------------------------->| B prepares
| L2 ACK | to relocate
|<- - - - - - - - - - - - - - - - - - - | (1,2)->(5,3)
| | and
| | (2,2)->(3,3)
| 6P Response |
| Code = RC_SUCCESS |
| SeqNum = 11 |
| CellList = [(5,3),(3,3)] |
A relocates |<--------------------------------------|
(1,2)->(5,3) | L2 ACK |
and | - - - - - - - - - - - - - - - - - - ->| B relocates
(2,2)->(3,3) | | (1,2)->(5,3)
| | and
| | (2,2)->(3,3)
+----------+ +----------+
| Node A | | Node B |
+----+-----+ +-----+----+
| |
| 6P RELOCATE Request |
| Type = REQUEST |
| Code = RELOCATE |
| SeqNum = 11 |
| NumCells = 2 |
| R.CellList = [(1,2),(2,2)] |
| C.CellList = [(3,3),(4,3),(5,3)] |
|-------------------------------------->| B prepares
| L2 ACK | to relocate
|<- - - - - - - - - - - - - - - - - - - | (1,2)->(5,3)
| | and
| | (2,2)->(3,3)
| 6P Response |
| Code = RC_SUCCESS |
| SeqNum = 11 |
| CellList = [(5,3),(3,3)] |
A relocates |<--------------------------------------|
(1,2)->(5,3) | L2 ACK |
and | - - - - - - - - - - - - - - - - - - ->| B relocates
(2,2)->(3,3) | | (1,2)->(5,3)
| | and
| | (2,2)->(3,3)
Figure 16: Example of a Successful 2-Step 6P RELOCATE Transaction
图16：成功的两步6P重定位事务示例
Figure 17 shows an example of a partially successful 2-step 6P RELOCATE Transaction.
图17显示了部分成功的两步6P重新定位事务的示例。
+----------+ +----------+
| Node A | | Node B |
+----+-----+ +-----+----+
| |
| 6P RELOCATE Request |
| Type = REQUEST |
| Code = RELOCATE |
| SeqNum = 199 |
| NumCells = 2 |
| R.CellList = [(1,2),(2,2)] |
| C.CellList = [(3,3),(4,3),(5,3)] | B prepares
|-------------------------------------->| to relocate
| L2 ACK | (1,2)->(4,3)
|<- - - - - - - - - - - - - - - - - - - | but cannot
| | relocate (2,2)
| 6P Response |
| Type = RESPONSE |
| Code = RC_SUCCESS |
| SeqNum = 199 |
| CellList = [(4,3)] |
A relocates |<--------------------------------------|
(1,2)->(4,3) | L2 ACK |
| - - - - - - - - - - - - - - - - - - ->| B relocates
| | (1,2)->(4,3)
| |
| |
+----------+ +----------+
| Node A | | Node B |
+----+-----+ +-----+----+
| |
| 6P RELOCATE Request |
| Type = REQUEST |
| Code = RELOCATE |
| SeqNum = 199 |
| NumCells = 2 |
| R.CellList = [(1,2),(2,2)] |
| C.CellList = [(3,3),(4,3),(5,3)] | B prepares
|-------------------------------------->| to relocate
| L2 ACK | (1,2)->(4,3)
|<- - - - - - - - - - - - - - - - - - - | but cannot
| | relocate (2,2)
| 6P Response |
| Type = RESPONSE |
| Code = RC_SUCCESS |
| SeqNum = 199 |
| CellList = [(4,3)] |
A relocates |<--------------------------------------|
(1,2)->(4,3) | L2 ACK |
| - - - - - - - - - - - - - - - - - - ->| B relocates
| | (1,2)->(4,3)
| |
| |
Figure 17: Example of a Partially Successful 2-Step 6P RELOCATE Transaction
图17：部分成功的两步6P重定位事务示例
Figure 18 shows an example of a failed 2-step 6P RELOCATE Transaction.
图18显示了一个失败的两步6P重新定位事务的示例。
+----------+ +----------+
| Node A | | Node B |
+----+-----+ +-----+----+
| |
| 6P RELOCATE Request |
| Type = REQUEST |
| Code = RELOCATE |
| SeqNum = 53 |
| NumCells = 2 |
| R.CellList = [(1,2),(2,2)] |
| C.CellList = [(3,3),(4,3),(5,3)] |
|-------------------------------------->| B cannot
| L2 ACK | relocate
|<- - - - - - - - - - - - - - - - - - - | (1,2)
| | or (2,2)
| 6P Response |
| Type = RESPONSE |
| Code = RC_SUCCESS |
| SeqNum = 53 |
| CellList = [] |
|<--------------------------------------| B does not
| L2 ACK | relocate
A does not | - - - - - - - - - - - - - - - - - - ->|
relocate | |
| |
+----------+ +----------+
| Node A | | Node B |
+----+-----+ +-----+----+
| |
| 6P RELOCATE Request |
| Type = REQUEST |
| Code = RELOCATE |
| SeqNum = 53 |
| NumCells = 2 |
| R.CellList = [(1,2),(2,2)] |
| C.CellList = [(3,3),(4,3),(5,3)] |
|-------------------------------------->| B cannot
| L2 ACK | relocate
|<- - - - - - - - - - - - - - - - - - - | (1,2)
| | or (2,2)
| 6P Response |
| Type = RESPONSE |
| Code = RC_SUCCESS |
| SeqNum = 53 |
| CellList = [] |
|<--------------------------------------| B does not
| L2 ACK | relocate
A does not | - - - - - - - - - - - - - - - - - - ->|
relocate | |
| |
Figure 18: Failed 2-Step 6P RELOCATE Transaction Example
图18：失败的2步6P重新定位事务示例
Figure 19 shows an example of a successful 3-step 6P RELOCATE Transaction.
图19显示了一个成功的3步6P重定位事务的示例。
+----------+ +----------+
| Node A | | Node B |
+----+-----+ +-----+----+
| |
| 6P RELOCATE Request |
| Type = REQUEST |
| Code = RELOCATE |
| SeqNum = 11 |
| NumCells = 2 |
| R.CellList = [(1,2),(2,2)] |
| C.CellList = [] |
|-------------------------------------->|
| L2 ACK |
|<- - - - - - - - - - - - - - - - - - - | B identifies
| | candidate
| | cells
| 6P Response | (3,3),
| Code = RC_SUCCESS | (4,3), and
| SeqNum = 11 | (5,3)
| CellList = [(3,3),(4,3),(5,3)] |
A prepares |<--------------------------------------|
to relocate | L2 ACK |
(1,2)->(5,3) | - - - - - - - - - - - - - - - - - - ->|
and | |
(2,2)->(3,3) | 6P Confirmation |
| Code = RC_SUCCESS |
| SeqNum = 11 |
| CellList = [(5,3),(3,3)] |
|-------------------------------------->| B relocates
| L2 ACK | (1,2)->(5,3)
A relocates |<- - - - - - - - - - - - - - - - - - - | and
(1,2)->(5,3) | | (2,2)->(3,3)
and | |
(2,2)->(3,3) | |
| |
+----------+ +----------+
| Node A | | Node B |
+----+-----+ +-----+----+
| |
| 6P RELOCATE Request |
| Type = REQUEST |
| Code = RELOCATE |
| SeqNum = 11 |
| NumCells = 2 |
| R.CellList = [(1,2),(2,2)] |
| C.CellList = [] |
|-------------------------------------->|
| L2 ACK |
|<- - - - - - - - - - - - - - - - - - - | B identifies
| | candidate
| | cells
| 6P Response | (3,3),
| Code = RC_SUCCESS | (4,3), and
| SeqNum = 11 | (5,3)
| CellList = [(3,3),(4,3),(5,3)] |
A prepares |<--------------------------------------|
to relocate | L2 ACK |
(1,2)->(5,3) | - - - - - - - - - - - - - - - - - - ->|
and | |
(2,2)->(3,3) | 6P Confirmation |
| Code = RC_SUCCESS |
| SeqNum = 11 |
| CellList = [(5,3),(3,3)] |
|-------------------------------------->| B relocates
| L2 ACK | (1,2)->(5,3)
A relocates |<- - - - - - - - - - - - - - - - - - - | and
(1,2)->(5,3) | | (2,2)->(3,3)
and | |
(2,2)->(3,3) | |
| |
Figure 19: Example of a Successful 3-Step 6P RELOCATE Transaction
图19：成功的3步6P重定位事务示例
To retrieve the number of scheduled cells node A has with B, node A issues a 6P COUNT command. The Type field (T) is set to REQUEST. The Code field is set to COUNT. Figure 20 defines the format of a 6P COUNT Request.
为了检索节点A与节点B的调度单元数，节点A发出6P COUNT命令。类型字段（T）设置为请求。“代码”字段设置为“计数”。图20定义了6P计数请求的格式。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| T | R | Code | SFID | SeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metadata | CellOptions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| T | R | Code | SFID | SeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metadata | CellOptions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: 6P COUNT Request Format
图20:6P计数请求格式
Metadata: Same usage as for the 6P ADD command; see Section 3.3.1. Its format is the same as that in the 6P ADD command, but its content could be different.
元数据：与6P ADD命令的用法相同；见第3.3.1节。其格式与6P ADD命令中的格式相同，但其内容可能不同。
CellOptions: Specifies which type of cell to be counted.
CellOptions：指定要计数的单元格类型。
Figure 21 defines the format of a 6P COUNT Response.
图21定义了6P计数响应的格式。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| T | R | Code | SFID | SeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NumCells |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| T | R | Code | SFID | SeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NumCells |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: 6P COUNT Response Format
图21:6P计数响应格式
NumCells: The number of cells that correspond to the fields of the request.
NumCells：与请求字段相对应的单元格数。
Node A issues a COUNT command to node B, specifying some cell options. Upon receiving the 6P COUNT Request, node B goes through its schedule and counts the number of cells scheduled with node A in its own schedule that match the cell options in the CellOptions field of the request. Section 3.2.3 details the use of the CellOptions field.
节点A向节点B发出计数命令，指定一些单元格选项。在接收到6P计数请求后，节点B将完成其调度，并在其自己的调度中统计与节点A调度的小区数量，这些小区数量与请求的CellOptions字段中的小区选项相匹配。第3.2.3节详细介绍了CellOptions字段的使用。
Node B issues a 6P Response to node A with return code RC_SUCCESS and with NumCells containing the number of cells that match the request.
节点B向节点a发出一个6P响应，返回代码为RC_SUCCESS，NumCells包含与请求匹配的单元数。
To retrieve a list of scheduled cells node A has with node B, node A issues a 6P LIST command. The Type field (T) is set to REQUEST. The Code field is set to LIST. Figure 22 defines the format of a 6P LIST Request.
为了检索节点a与节点B的调度单元列表，节点a发出6P list命令。类型字段（T）设置为请求。“代码”字段设置为“列表”。图22定义了6P列表请求的格式。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| T | R | Code | SFID | SeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metadata | CellOptions | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset | MaxNumCells |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| T | R | Code | SFID | SeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metadata | CellOptions | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset | MaxNumCells |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 22: 6P LIST Request Format
图22:6P列表请求格式
Metadata: Same usage as for the 6P ADD command; see Section 3.3.1. Its format is the same as that in the 6P ADD command, but its content could be different.
元数据：与6P ADD命令的用法相同；见第3.3.1节。其格式与6P ADD命令中的格式相同，但其内容可能不同。
CellOptions: Specifies which type of cell to be listed.
CelloOptions：指定要列出的单元格类型。
Reserved: Reserved bits. These bits SHOULD be set to zero when sending the message and MUST be ignored upon reception.
保留：保留位。发送信息时，这些位应设置为零，接收时必须忽略。
Offset: The offset of the first scheduled cell that is requested. The mechanism assumes that cells are ordered according to a rule defined in the SF. The rule MUST always order the cells in the same way.
偏移量：请求的第一个计划单元格的偏移量。该机制假设单元格是根据SF中定义的规则排序的。规则必须始终以相同的方式排列单元格。
MaxNumCells: The maximum number of cells to be listed. Node B MAY return fewer than MaxNumCells cells -- for example, if MaxNumCells cells do not fit in the frame.
MaxNumCells：要列出的最大单元格数。节点B返回的单元格可能少于MaxNumCells——例如，如果MaxNumCells单元格不适合该帧。
Figure 23 defines the format of a 6P LIST Response.
图23定义了6P列表响应的格式。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| T | R | Code | SFID | SeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CellList ...
+-+-+-+-+-+-+-+-+-
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| T | R | Code | SFID | SeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CellList ...
+-+-+-+-+-+-+-+-+-
Figure 23: 6P LIST Response Format
图23:6P列表响应格式
CellList: A list of zero or more 6P Cells.
CellList：零个或多个6P单元的列表。
When receiving a LIST command, node B returns the cells scheduled with A in its schedule that match the CellOptions field as specified in Section 3.2.3.
当接收到LIST命令时，节点B返回其调度中与第3.2.3节中规定的CellOptions字段匹配的a调度的单元格。
When node B receives a LIST Request, the returned CellList in the 6P Response contains between 0 and MaxNumCells cells, starting from the specified offset. Node B SHOULD include as many cells as will fit in the frame. If the response contains the last cell, node B MUST set the Code field in the response to RC_EOL ("End of List", as per Figure 38 in Section 6.2.4), indicating to node A that there are no more cells that match the request. Node B MUST return at least one cell, unless the specified offset is beyond the end of B's cell list in its schedule. If node B has fewer than Offset cells that match the request, node B returns an empty CellList and a Code field set to RC_EOL.
当节点B收到列表请求时，6P响应中返回的CellList包含0到MaxNumCells之间的单元格，从指定的偏移量开始。节点B应包括尽可能多的单元，以适应帧。如果响应包含最后一个单元，则节点B必须在对RC_EOL的响应中设置代码字段（“列表结束”，如第6.2.4节中的图38所示），以指示节点A没有更多与请求匹配的单元。节点B必须返回至少一个单元格，除非指定的偏移量超出其计划中B的单元格列表末尾。如果节点B的偏移单元格少于与请求匹配的单元格，则节点B将返回一个空单元格列表和一个设置为RC_EOL的代码字段。
To clear the schedule between nodes A and B (for example, after a schedule inconsistency is detected), node A issues a CLEAR command. The Type field (T) is set to REQUEST. The Code field is set to CLEAR. Figure 24 defines the format of a 6P CLEAR Request.
为了清除节点A和B之间的调度（例如，在检测到调度不一致后），节点A发出清除命令。类型字段（T）设置为请求。代码字段设置为清除。图24定义了6P清除请求的格式。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| T | R | Code | SFID | SeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metadata |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| T | R | Code | SFID | SeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metadata |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 24: 6P CLEAR Request Format
图24:6P清除请求格式
Metadata: Same usage as for the 6P ADD command; see Section 3.3.1. Its format is the same as that in the 6P ADD command, but its content could be different.
元数据：与6P ADD命令的用法相同；见第3.3.1节。其格式与6P ADD命令中的格式相同，但其内容可能不同。
Figure 25 defines the format of a 6P CLEAR Response.
图25定义了6P清晰响应的格式。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| T | R | Code | SFID | SeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| T | R | Code | SFID | SeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 25: 6P CLEAR Response Format
图25:6P清晰响应格式
When a 6P CLEAR command is issued from node A to node B, both nodes A and B MUST remove all the cells scheduled between them. That is, node A MUST remove all the cells scheduled with node B, and node B MUST remove all the cells scheduled with node A. In a 6P CLEAR command, the SeqNum MUST NOT be checked. In particular, even if the request contains a SeqNum value that would normally cause node B to detect a schedule inconsistency, the transaction MUST NOT be aborted. Upon 6P CLEAR completion, the value of SeqNum MUST be reset to 0.
当从节点a向节点B发出6P CLEAR命令时，节点a和B都必须删除它们之间调度的所有单元。也就是说，节点A必须删除与节点B一起调度的所有单元，节点B必须删除与节点A一起调度的所有单元。在6P CLEAR命令中，不得检查SeqNum。特别是，即使请求包含通常会导致节点B检测到调度不一致的SeqNum值，也不能中止事务。6P清除完成后，SeqNum的值必须重置为0。
The return code sent in response to a 6P CLEAR command SHOULD be RC_SUCCESS unless the operation cannot be executed. When the CLEAR operation cannot be executed, the return code MUST be set to RC_RESET.
为响应6P CLEAR命令而发送的返回码应为RC_SUCCESS，除非无法执行该操作。当无法执行清除操作时，返回代码必须设置为RC_RESET。
The 6P SIGNAL message allows the SF implementations on two neighbor nodes to exchange generic commands. The payload in a received SIGNAL message is an opaque set of bytes passed unmodified to the SF. The length of the payload is determined by the Length field of the Payload IE header. How the generic SIGNAL command is used is specified by the SF and is outside the scope of this document. The Type field (T) is set to REQUEST. The Code field is set to SIGNAL. Figure 26 defines the format of a 6P SIGNAL Request.
6P信号消息允许两个相邻节点上的SF实现交换通用命令。接收到的信号消息中的有效负载是未经修改而传递给SF的一组不透明字节。有效负载的长度由有效负载IE标头的长度字段确定。通用信号命令的使用方式由SF规定，不在本文件范围内。类型字段（T）设置为请求。代码字段设置为信号。图26定义了6P信号请求的格式。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| T | R | Code | SFID | SeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metadata | 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| T | R | Code | SFID | SeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metadata | payload ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 26: 6P SIGNAL Request Format
图26:6P信号请求格式
Metadata: Same usage as for the 6P ADD command; see Section 3.3.1. Its format is the same as that in the 6P ADD command, but its content could be different.
元数据：与6P ADD命令的用法相同；见第3.3.1节。其格式与6P ADD命令中的格式相同，但其内容可能不同。
Figure 27 defines the format of a 6P SIGNAL Response.
图27定义了6P信号响应的格式。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| T | R | Code | SFID | SeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| T | R | Code | SFID | SeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| payload ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 27: 6P SIGNAL Response Format
图27:6P信号响应格式
All messages contain a Version field. If multiple protocol versions of 6P have been defined (in future specifications for Version values different from 0), a node MAY implement multiple protocol versions at the same time. When a node receives a 6P message with a version number it does not implement, the node MUST reply with a 6P Response with a return code field set to RC_ERR_VERSION. The format of this 6P Response message MUST be compliant with version 0 and MUST be
所有消息都包含一个版本字段。如果定义了6P的多个协议版本（在未来版本值不同于0的规范中），则节点可以同时实现多个协议版本。当节点接收到版本号为6P的消息时，该节点必须使用返回码字段设置为RC_ERR_version的6P响应进行回复。此6P响应消息的格式必须与版本0兼容，并且必须
supported by all future versions of the protocol. This ensures that when node B sends a 6P Response to node A indicating that it does not implement the 6P version in the 6P Request, node A can successfully parse that response.
由协议的所有未来版本支持。这确保了当节点B向节点a发送一个6P响应，指示它没有在6P请求中实现6P版本时，节点a可以成功解析该响应。
When a node supports a version number received in a 6P Request message, the Version field in the 6P Response MUST be the same as the Version field in the corresponding 6P Request. Similarly, in a 3-step transaction, the Version field in the 6P Confirmation MUST match that of the 6P Request and 6P Response of the same transaction.
当节点支持在6P请求消息中接收的版本号时，6P响应中的版本字段必须与相应6P请求中的版本字段相同。类似地，在三步事务中，6P确认中的版本字段必须与同一事务的6P请求和6P响应的版本字段匹配。
All messages contain an SFID field. A node MAY support multiple SFs at the same time. When receiving a 6P message with an unsupported SFID, a node MUST reply with a 6P Response with a return code of RC_ERR_SFID. The SFID field in the 6P Response MUST be the same as the SFID field in the corresponding 6P Request. In a 3-step transaction, the SFID field in the 6P Confirmation MUST match that of the 6P Request and the 6P Response of the same transaction.
所有消息都包含一个SFID字段。一个节点可以同时支持多个SF。当接收到带有不支持的SFID的6P消息时，节点必须使用返回代码为RC_ERR_SFID的6P响应进行回复。6P响应中的SFID字段必须与相应6P请求中的SFID字段相同。在三步事务中，6P确认中的SFID字段必须与同一事务的6P请求和6P响应的SFID字段匹配。
Only a single 6P Transaction at a time in a given direction can take place between two neighbors. That is, a node MUST NOT issue a new 6P Request to a given neighbor before the previous 6P Transaction it initiated has finished (or possibly timed out). If a node receives a 6P Request from a given neighbor before having sent the 6P Response to the previous 6P Request from that neighbor, it MUST send back a 6P Response with a return code of RC_RESET (as per Figure 38 in Section 6.2.4) and discard this ongoing second transaction. A node receiving a RC_RESET code MUST abort the second transaction and treat it as though it never happened (i.e., reverting changes to the schedule or SeqNum done by this transaction).
在给定的方向上，一次只能在两个邻居之间进行一个6P事务。也就是说，在节点发起的前一个6P事务完成（或可能超时）之前，节点不得向给定的邻居发出新的6P请求。如果一个节点在将6P响应发送到来自该邻居的前一个6P请求之前收到了来自该邻居的6P请求，则它必须发送返回码为RC_RESET的6P响应（如第6.2.4节中的图38所示），并放弃正在进行的第二个事务。接收RC_重置代码的节点必须中止第二个事务，并将其视为从未发生过（即，还原对此事务所做的计划或SeqNum的更改）。
Nodes A and B MAY support having two transactions going on at the same time, one in each direction. Similarly, a node MAY support concurrent 6P Transactions with different neighbors. In this case, the cells involved in an ongoing 6P Transaction MUST be "locked" until the transaction finishes. For example, in Figure 1, node C can have a different ongoing 6P Transaction with nodes B and R. If a node does not have enough resources to handle concurrent 6P Transactions from different neighbors, it MUST reply with a 6P Response with return code RC_ERR_BUSY (as per Figure 38 in Section 6.2.4). If the requested cells are locked, it MUST reply to that request with a 6P Response with return code RC_ERR_LOCKED (as per Figure 38). The node receiving RC_ERR_BUSY or RC_ERR_LOCKED MAY implement a retry mechanism as defined by the SF.
节点A和B可以支持同时进行两个事务，每个方向一个事务。类似地，节点可以支持与不同邻居的并发6P事务。在这种情况下，正在进行的6P事务中涉及的单元格必须“锁定”，直到事务完成。例如，在图1中，节点C可以与节点B和R有一个不同的正在进行的6P事务。如果节点没有足够的资源来处理来自不同邻居的并发6P事务，它必须使用返回码为RC_ERR_BUSY的6P响应进行回复（根据第6.2.4节中的图38）。如果请求的单元格被锁定，它必须用返回码RC_ERR_locked的6P响应响应该请求（如图38所示）。接收RC_ERR_BUSY或RC_ERR_LOCKED的节点可以实现由SF定义的重试机制。
A timeout occurs when the node that successfully sent a 6P Request does not receive the corresponding 6P Response within an amount of time specified by the SF. In a 3-step transaction, a timeout also occurs when a node sending the 6P Response does not receive a 6P Confirmation. When a timeout occurs, the transaction MUST be canceled at the node where the timeout occurs. The value of the 6P Timeout should be greater than the longest possible time it takes to receive the 6P Response or Confirmation. The value of the 6P Timeout hence depends on the number of cells scheduled between the neighbor nodes, the maximum number of link-layer retransmissions, etc. The SF MUST determine the value of the timeout. The value of the timeout is out of scope for this document.
当成功发送6P请求的节点在SF指定的时间内没有收到相应的6P响应时，会发生超时。在三步事务中，当发送6P响应的节点没有收到6P确认时，也会发生超时。发生超时时，必须在发生超时的节点取消事务。6P超时值应大于接收6P响应或确认所需的最长时间。因此，6P超时的值取决于邻居节点之间调度的小区数量、链路层重传的最大数量等。SF必须确定超时的值。超时值超出此文档的范围。
If the receiver of a 6P Request fails during a 6P Transaction and is unable to complete it, it SHOULD reply to that request with a 6P Response with return code RC_RESET. Upon receiving this 6P Response, the initiator of the 6P Transaction MUST consider the 6P Transaction as having failed.
如果6P请求的接收者在6P事务期间失败，并且无法完成该事务，则其应使用返回代码为RC_RESET的6P响应响应该请求。当接收到6P响应时，6P事务的发起方必须考虑6P事务失败。
Similarly, in the case of a 3-step transaction, when the receiver of a 6P Response fails during the 6P Transaction and is unable to complete it, it MUST reply to that 6P Response with a 6P Confirmation with return code RC_RESET. Upon receiving this 6P Confirmation, the sender of the 6P Response MUST consider the 6P Transaction as having failed.
类似地，在三步事务的情况下，当6P响应的接收者在6P事务期间失败并且无法完成它时，它必须用返回代码RC_RESET的6P确认回复该6P响应。当接收到6P确认时，6P响应的发送方必须考虑6P事务失败。
The SeqNum is the field in the 6top IE header used to match Request, Response, and Confirmation messages for a given transaction. The SeqNum is used to detect and handle duplicate commands (Section 3.4.6.1) and inconsistent schedules (Section 3.4.6.2). Each node remembers the last used SeqNum for each neighbor. That is, a node stores as many SeqNum values as it has neighbors. In the case of supporting multiple SFs at a time, a SeqNum value is maintained per SF and per neighbor. In the remainder of this section, we describe the use of SeqNum between two neighbors; the same happens for each other neighbor, independently.
SeqNum是6top IE头中的字段，用于匹配给定事务的请求、响应和确认消息。SeqNum用于检测和处理重复命令（第3.4.6.1节）和不一致计划（第3.4.6.2节）。每个节点都会记住每个邻居最后使用的SeqNum。也就是说，一个节点存储的SeqNum值与其邻居的数量相同。在一次支持多个SF的情况下，每个SF和每个邻居保持一个SeqNum值。在本节的剩余部分中，我们将描述在两个相邻节点之间使用SeqNum；同样的情况也会发生在彼此的邻居身上。
When a node resets, or after a CLEAR Transaction, it MUST reset SeqNum to 0. The 6P Response and 6P Confirmation for a transaction MUST use the same SeqNum value as that in the request. After every transaction, the SeqNum MUST be incremented by exactly 1.
当节点重置时，或在清除事务后，它必须将SeqNum重置为0。事务的6P响应和6P确认必须使用与请求中相同的SeqNum值。在每个事务之后，SeqNum必须精确地增加1。
Specifically, if node A receives the link-layer acknowledgment for its 6P Request, it will increment the SeqNum by exactly 1 after the 6P Transaction ends. This ensures that, for the next 6P Transaction where it sends a 6P Request, the 6P Request will have a different SeqNum.
具体地说，如果节点A收到其6P请求的链路层确认，则在6P事务结束后，它会将SeqNum精确地增加1。这可以确保，对于发送6P请求的下一个6P事务，6P请求将具有不同的SeqNum。
Similarly, node B increments the SeqNum by exactly 1 after having received the link-layer acknowledgment for the 6P Response (2-step 6P Transaction) or after having sent the link-layer acknowledgment for the 6P Confirmation (3-step 6P Transaction).
类似地，节点B在接收到针对6P响应的链路层确认（2步骤6P事务）或在发送针对6P确认的链路层确认（3步骤6P事务）后，将SeqNum精确地增加1。
When node B receives a 6P Request from node A with SeqNum equal to 0, it checks the stored SeqNum for A. If A is a new neighbor, the stored SeqNum in B will be 0. The transaction can continue. If the stored SeqNum for A in B is different than 0, a potential inconsistency is detected. In this case, B MUST return RC_ERR_SEQNUM with SeqNum=0. The SF of node A MAY decide what to do next, as described in Section 3.4.6.2.
当节点B从节点a接收到SeqNum等于0的6P请求时，它将检查存储的SeqNum中是否有a。如果a是新邻居，则存储在B中的SeqNum将为0。交易可以继续。如果B中存储的A的SeqNum不同于0，则检测到潜在的不一致性。在这种情况下，B必须返回带有SEQNUM=0的RC_ERR_SEQNUM。如第3.4.6.2节所述，节点A的SF可以决定接下来要做什么。
The SeqNum MUST be implemented as a lollipop counter: it rolls over from 0xFF to 0x01 (not to 0x00). This is used to detect a neighbor reset. Figure 28 lists the possible values of the SeqNum.
SeqNum必须实现为棒棒糖计数器：它从0xFF滚动到0x01（而不是0x00）。这用于检测邻居重置。图28列出了SeqNum的可能值。
+-----------+------------------------------+
| Value | Meaning |
+-----------+------------------------------+
| 0x00 | Clear, or after device reset |
| 0x01-0xFF | Lollipop counter values |
+-----------+------------------------------+
+-----------+------------------------------+
| Value | Meaning |
+-----------+------------------------------+
| 0x00 | Clear, or after device reset |
| 0x01-0xFF | Lollipop counter values |
+-----------+------------------------------+
Figure 28: Possible Values of the SeqNum
图28:SeqNum的可能值
All 6P commands are link-layer acknowledged. A duplicate message means that a node receives a second 6P Request, Response, or Confirmation. This happens when the link-layer acknowledgment is not received and a link-layer retransmission happens. Duplicate messages are normal and unavoidable.
所有6P命令均为链路层确认。重复消息意味着节点接收第二个6P请求、响应或确认。当未收到链路层确认且发生链路层重传时，会发生这种情况。重复消息是正常的，也是不可避免的。
Figure 29 shows an example 2-step transaction in which node A receives a duplicate 6P Response.
图29显示了一个示例两步事务，其中节点A接收到重复的6P响应。
+----------+ +----------+
| Node A | | Node B |
+----+-----+ +-----+----+
| |
| 6P Request (SeqNum=456) |
|-------------------------------------->|
| L2 ACK |
|<- - - - - - - - - - - - - - - - - - - |
| |
| 6P Response (SeqNum=456) |
|<--------------------------------------|
| L2 ACK |
| - - - - - - - - - - -X | no ACK:
| | link-layer
| 6P Response (SeqNum=456) | retransmit
duplicate |<--------------------------------------|
6P Response | L2 ACK |
received | - - - - - - - - - - - - - - - - - - ->|
| |
+----------+ +----------+
| Node A | | Node B |
+----+-----+ +-----+----+
| |
| 6P Request (SeqNum=456) |
|-------------------------------------->|
| L2 ACK |
|<- - - - - - - - - - - - - - - - - - - |
| |
| 6P Response (SeqNum=456) |
|<--------------------------------------|
| L2 ACK |
| - - - - - - - - - - -X | no ACK:
| | link-layer
| 6P Response (SeqNum=456) | retransmit
duplicate |<--------------------------------------|
6P Response | L2 ACK |
received | - - - - - - - - - - - - - - - - - - ->|
| |
Figure 29: Example Duplicate 6P Message
图29：重复6P消息示例
Figure 30 shows an example 3-step transaction in which node A receives an out-of-order duplicate 6P Response after having sent a 6P Confirmation.
图30显示了一个示例3步事务，其中节点A在发送6P确认后收到一个无序重复的6P响应。
+----------+ +----------+
| Node A | | Node B |
+----+-----+ +-----+----+
| |
| 6P Request (SeqNum=123) |
|-------------------------------------->|
| L2 ACK |
|<- - - - - - - - - - - - - - - - - - - |
| |
| 6P Response (SeqNum=123) |
|<--------------------------------------|
| L2 ACK |
| - - - - - - - - - - -X | no ACK:
| | link-layer
| 6P Confirmation (SeqNum=123) | retransmit
|-------------------------------------->| |
| L2 ACK | |
|<- - - - - - - - - - - - - - - - - - - | frame
| | queued
| 6P Response (SeqNum=123) | |
duplicate |<--------------------------------------| <--+
out-of-order | L2 ACK |
6P Response | - - - - - - - - - - - - - - - - - - ->|
received | |
+----------+ +----------+
| Node A | | Node B |
+----+-----+ +-----+----+
| |
| 6P Request (SeqNum=123) |
|-------------------------------------->|
| L2 ACK |
|<- - - - - - - - - - - - - - - - - - - |
| |
| 6P Response (SeqNum=123) |
|<--------------------------------------|
| L2 ACK |
| - - - - - - - - - - -X | no ACK:
| | link-layer
| 6P Confirmation (SeqNum=123) | retransmit
|-------------------------------------->| |
| L2 ACK | |
|<- - - - - - - - - - - - - - - - - - - | frame
| | queued
| 6P Response (SeqNum=123) | |
duplicate |<--------------------------------------| <--+
out-of-order | L2 ACK |
6P Response | - - - - - - - - - - - - - - - - - - ->|
received | |
Figure 30: Example Out-of-Order Duplicate 6P Message
图30：无序重复6P消息示例
A node detects a duplicate 6P message when it has the same SeqNum and type as the last frame received from the same neighbor. When receiving a duplicate 6P message, a node MUST send a link-layer acknowledgment but MUST silently ignore the 6P message at 6top.
当节点具有与从同一邻居接收的最后一帧相同的SeqNum和类型时，节点会检测到重复的6P消息。当接收到重复的6P消息时，节点必须发送链路层确认，但必须在6top默默忽略6P消息。
A schedule inconsistency happens when the schedules of nodes A and B are inconsistent -- for example, when node A has a transmit cell to node B, but node B does not have the corresponding receive cell and therefore isn't listening to node A on that cell. A schedule inconsistency results in loss of connectivity.
当节点A和B的调度不一致时，就会发生调度不一致——例如，当节点A有一个到节点B的发送小区，但节点B没有相应的接收小区，因此没有侦听该小区上的节点A时。计划不一致会导致连接丢失。
The SeqNum field, which is present in each 6P message, is used to detect an inconsistency. The SeqNum field increments by 1 in each message, as detailed in Section 3.4.6. A node computes the expected
SeqNum字段出现在每个6P消息中，用于检测不一致性。如第3.4.6节所述，每条消息中的SeqNum字段递增1。节点计算预期的
SeqNum field for the next 6P Transaction. If a node receives a 6P Request with a SeqNum value that is not the expected value, it has detected an inconsistency.
下一个6P事务的SeqNum字段。如果节点接收到SeqNum值不是预期值的6P请求，则它已检测到不一致。
There are two cases in which a schedule inconsistency happens.
有两种情况下会发生计划不一致。
The first case is when a node loses state -- for example, when it is power-cycled (turned off, then on). In that case, its SeqNum value is reset to 0. Since the SeqNum is a lollipop counter, its neighbor detects an inconsistency in the next 6P Transaction. This is illustrated in Figures 31 and 32.
第一种情况是当节点失去状态时——例如，当它处于电源循环状态时（先关闭，然后打开）。在这种情况下，其SeqNum值重置为0。因为SeqNum是棒棒糖计数器，所以它的邻居在下一个6P事务中检测到不一致。图31和32对此进行了说明。
+----------+ +----------+
| Node A | | Node B |
+----+-----+ +-----+----+
SeqNum=87 | | SeqNum=87
| |
| 6P Request (SeqNum=87) |
|-------------------------------------->|
| L2 ACK |
|<- - - - - - - - - - - - - - - - - - - |
| |
| 6P Response (SeqNum=87) |
|<--------------------------------------|
| L2 ACK |
| - - - - - - - - - - - - - - - - - - ->|
| ==== power-cycle
| |
SeqNum=88 | | SeqNum=0
| |
| 6P Request (SeqNum=88) |
|-------------------------------------->| Inconsistency
| L2 ACK | detected
|<- - - - - - - - - - - - - - - - - - - |
| |
| 6P Response (SeqNum=0, RC_ERR_SEQNUM) |
|<--------------------------------------|
| L2 ACK |
| - - - - - - - - - - - - - - - - - - ->|
+----------+ +----------+
| Node A | | Node B |
+----+-----+ +-----+----+
SeqNum=87 | | SeqNum=87
| |
| 6P Request (SeqNum=87) |
|-------------------------------------->|
| L2 ACK |
|<- - - - - - - - - - - - - - - - - - - |
| |
| 6P Response (SeqNum=87) |
|<--------------------------------------|
| L2 ACK |
| - - - - - - - - - - - - - - - - - - ->|
| ==== power-cycle
| |
SeqNum=88 | | SeqNum=0
| |
| 6P Request (SeqNum=88) |
|-------------------------------------->| Inconsistency
| L2 ACK | detected
|<- - - - - - - - - - - - - - - - - - - |
| |
| 6P Response (SeqNum=0, RC_ERR_SEQNUM) |
|<--------------------------------------|
| L2 ACK |
| - - - - - - - - - - - - - - - - - - ->|
Figure 31: Example of Inconsistency Because Node B Resets (Detected by Node B)
图31：由于节点B重置（由节点B检测）导致的不一致示例
+----------+ +----------+
| Node A | | Node B |
+----+-----+ +-----+----+
SeqNum=97 | | SeqNum=97
| |
| 6P Request (SeqNum=97) |
|-------------------------------------->|
| L2 ACK |
|<- - - - - - - - - - - - - - - - - - - |
| |
| 6P Response (SeqNum=97) |
|<--------------------------------------|
| L2 ACK |
| - - - - - - - - - - - - - - - - - - ->|
| ==== power-cycle
| |
SeqNum=98 | | SeqNum=0
| |
| 6P Request (SeqNum=0) |
Inconsistency |<--------------------------------------|
detected | L2 ACK |
|- - - - - - - - - - - - - - - - - - - >|
| |
| 6P Response (SeqNum=0, RC_ERR_SEQNUM) |
|-------------------------------------->|
| L2 ACK |
|<- - - - - - - - - - - - - - - - - - - |
+----------+ +----------+
| Node A | | Node B |
+----+-----+ +-----+----+
SeqNum=97 | | SeqNum=97
| |
| 6P Request (SeqNum=97) |
|-------------------------------------->|
| L2 ACK |
|<- - - - - - - - - - - - - - - - - - - |
| |
| 6P Response (SeqNum=97) |
|<--------------------------------------|
| L2 ACK |
| - - - - - - - - - - - - - - - - - - ->|
| ==== power-cycle
| |
SeqNum=98 | | SeqNum=0
| |
| 6P Request (SeqNum=0) |
Inconsistency |<--------------------------------------|
detected | L2 ACK |
|- - - - - - - - - - - - - - - - - - - >|
| |
| 6P Response (SeqNum=0, RC_ERR_SEQNUM) |
|-------------------------------------->|
| L2 ACK |
|<- - - - - - - - - - - - - - - - - - - |
Figure 32: Example of Inconsistency Because Node B Resets (Detected by Node A)
图32：由于节点B重置（由节点A检测）导致的不一致示例
The second case is when the maximum number of link-layer retransmissions is reached on the 6P Response of a 2-step transaction (or, equivalently, on a 6P Confirmation of a 3-step transaction). This is illustrated in Figure 33.
第二种情况是，在两步事务的6P响应（或等效地，在三步事务的6P确认）上达到链路层重传的最大次数。如图33所示。
+----------+ +----------+
| Node A | | Node B |
+----+-----+ +-----+----+
SeqNum=87 | | SeqNum=87
| |
| 6P Request (SeqNum=87) |
|-------------------------------------->|
| L2 ACK |
|<- - - - - - - - - - - - - - - - - - - |
| |
| 6P Response (SeqNum=87) |
|<--------------------------------------|
| L2 ACK |
| - - - - - - - - X |
SeqNum=88 | | no ACK:
| 6P Response (SeqNum=87) | retrans. 1
(duplicate) |<--------------------------------------|
| L2 ACK |
| - - - - - - - - X |
| | no ACK:
| 6P Response (SeqNum=87) | retrans. 2
(duplicate) |<--------------------------------------|
| L2 ACK |
| - - - - - - - - X |
| | max. retrans.:
| | inconsistency
| | detected
+----------+ +----------+
| Node A | | Node B |
+----+-----+ +-----+----+
SeqNum=87 | | SeqNum=87
| |
| 6P Request (SeqNum=87) |
|-------------------------------------->|
| L2 ACK |
|<- - - - - - - - - - - - - - - - - - - |
| |
| 6P Response (SeqNum=87) |
|<--------------------------------------|
| L2 ACK |
| - - - - - - - - X |
SeqNum=88 | | no ACK:
| 6P Response (SeqNum=87) | retrans. 1
(duplicate) |<--------------------------------------|
| L2 ACK |
| - - - - - - - - X |
| | no ACK:
| 6P Response (SeqNum=87) | retrans. 2
(duplicate) |<--------------------------------------|
| L2 ACK |
| - - - - - - - - X |
| | max. retrans.:
| | inconsistency
| | detected
Figure 33: Example Inconsistency Because of Maximum Link-Layer Retransmissions (where Maximum = 2)
图33：最大链路层重传导致的不一致示例（其中最大值=2）
In both cases, node B detects the inconsistency.
在这两种情况下，节点B都检测到不一致性。
If the inconsistency is detected during a 6P Transaction (Figure 31), the node that has detected it MUST send back a 6P Response or 6P Confirmation with an error code of RC_ERR_SEQNUM. In this 6P Response or 6P Confirmation, the SeqNum field MUST be set to the value of the sender of the message (0 in the example in Figure 31).
如果在6P事务期间检测到不一致性（图31），则检测到不一致性的节点必须返回一个6P响应或6P确认，错误代码为RC_ERR_SEQNUM。在这个6P响应或6P确认中，SeqNum字段必须设置为消息发送者的值（图31中的示例中为0）。
The SF of the node that has detected the inconsistency MUST define how to handle the inconsistency. Three possible ways to do this are as follows:
检测到不一致的节点的SF必须定义如何处理不一致。三种可能的方法如下：
o Issue a 6P CLEAR Request to clear the schedule, and then rebuild.
o 发出6P清除请求以清除计划，然后重新生成。
o Issue a 6P LIST Request to retrieve the schedule.
o 发出6P列表请求以检索计划。
o Internally "roll back" the schedule.
o 在内部“回滚”计划。
How to handle an inconsistency is out of scope for this document. The SF defines how to handle an inconsistency.
如何处理不一致性超出了本文档的范围。SF定义了如何处理不一致性。
A return code marked as Yes in the "Is Error?" column in Figure 38 (Section 6.2.4) indicates an error. When a node receives a 6P Response or 6P Confirmation with an error, it MUST consider the 6P Transaction as having failed. In particular, if this was a response to a 6P ADD, DELETE, or RELOCATE Request, the node MUST NOT add, delete, or relocate any of the cells involved in this 6P Transaction. Similarly, a node sending a 6P Response or a 6P Confirmation with an error code MUST NOT add, delete, or relocate any cells as part of that 6P Transaction. If a node receives an unrecognized return code, the 6P Transaction MUST be considered as having failed. In particular, in a 3-step 6P Transaction, when receiving a 6P Response with a return code that it does not recognize, the requester (node A) MUST send a 6P Confirmation to the responder (node B) with return code RC_ERR and consider the transaction failed. Upon reception of a 6P Confirmation with return code RC_ERR, the responder MUST consider the transaction failed as well. Defining what to do after an error has occurred is out of scope for this document. The SF defines what to do after an error has occurred.
图38（第6.2.4节）中“是错误？”列中标记为“是”的返回代码表示错误。当节点收到6P响应或6P确认错误时，它必须考虑6P事务失败。特别是，如果这是对6P添加、删除或重新定位请求的响应，则节点不得添加、删除或重新定位此6P事务中涉及的任何单元格。类似地，发送带有错误代码的6P响应或6P确认的节点不得在该6P事务中添加、删除或重新定位任何单元格。如果节点收到无法识别的返回代码，则必须将6P事务视为失败。特别地，在3步6P事务中，当接收到具有不识别的返回代码的6P响应时，请求者（节点A）必须向返回者代码RCYER发送应答器（节点B）的6P确认，并考虑事务失败。当接收到带有返回码RCYER的6P确认时，应答器也必须考虑事务失败。定义发生错误后要执行的操作超出了本文档的范围。SF定义了发生错误后要执行的操作。
6P messages MUST be secured through link-layer security. This is possible because 6P messages are carried as Payload IEs.
必须通过链路层安全保护6P消息。这是可能的，因为6P消息作为有效负载IEs进行传输。
Each SF has a 1-byte identifier. Section 6.2.5 defines the rules for applying for an SFID.
每个SF都有一个1字节的标识符。第6.2.5节定义了申请SFID的规则。
The specification for an SF
SF的规范
o MUST specify an identifier for that SF.
o 必须指定该SF的标识符。
o MUST specify the rule for a node to decide when to add/delete one or more cells to/on a neighbor.
o 必须为节点指定规则，以决定何时向邻居添加/删除一个或多个单元格。
o MUST specify the rule for a transaction source to select cells to add to the CellList field in the 6P ADD Request.
o 必须为事务源指定规则，以选择要添加到6P添加请求中CellList字段的单元格。
o MUST specify the rule for a transaction destination to select cells from the CellList to add to its schedule.
o 必须为事务目标指定规则，以便从单元格列表中选择要添加到其计划中的单元格。
o MUST specify a value for the 6P Timeout or a rule/equation to calculate it.
o 必须为6P超时指定一个值或一个规则/公式来计算它。
o MUST specify the rule for ordering cells.
o 必须指定单元格排序规则。
o MUST specify a meaning for the Metadata field in the 6P ADD Request.
o 必须在6P添加请求中指定元数据字段的含义。
o MUST specify the SF behavior of a node when it boots.
o 必须指定节点引导时的SF行为。
o MUST specify how to handle a schedule inconsistency.
o 必须指定如何处理计划不一致。
o MUST specify what to do after an error has occurred (the node either sent a 6P Response with an error code or received one).
o 必须指定发生错误后要执行的操作（节点发送带有错误代码的6P响应或接收到错误代码的6P响应）。
o MUST specify the list of statistics to gather. Example statistics include the number of transmitted frames to each neighbor. If the SF does not require that statistics be gathered, the SF specification MUST explicitly say so.
o 必须指定要收集的统计信息列表。示例统计信息包括发送到每个邻居的帧数。如果SF不要求收集统计数据，则SF规范必须明确说明这一点。
o SHOULD clearly state the application domain the SF is created for.
o 应明确说明创建SF的应用程序域。
o SHOULD contain examples that highlight normal and error scenarios.
o 应包含突出显示正常和错误场景的示例。
o SHOULD contain a list of current implementations, at least during the Internet-Draft (I-D) state of the document, per [RFC7942].
o 根据[RFC7942]，应至少在文件的互联网草稿（I-D）状态下包含当前实施的列表。
o SHOULD contain a performance evaluation of the scheme, possibly through references to external documents.
o 应包含方案的绩效评估，可能通过参考外部文件。
o SHOULD define the format of the SIGNAL command payload and its use.
o 应定义信号命令有效载荷的格式及其使用。
o MAY redefine the format of the CellList field.
o 可以重新定义单元格列表字段的格式。
o MAY redefine the format of the CellOptions field.
o 可以重新定义CellOptions字段的格式。
o MAY redefine the meaning of the CellOptions field.
o 可以重新定义CellOptions字段的含义。
6P messages are carried inside 802.15.4 Payload Information Elements (IEs). Those Payload IEs are encrypted and authenticated at the link layer through CCM* [CCM-Star] ("CCM" stands for "Cipher block Chaining -- Message authentication code"). 6P benefits from the same level of security as any other Payload IE. 6P does not define its own security mechanisms. In particular, although a key management solution is out of scope for this document, 6P will benefit from the key management solution used in the network. This is relevant, as security attacks such as forgery and misattribution attacks become more damaging when a single key is shared amongst a group of more than two participants.
6P消息在802.15.4有效负载信息元素中传输。这些有效载荷在链路层通过CCM*[CCM Star]（“CCM”代表“密码块链接——消息认证码”）进行加密和认证。6P与任何其他有效负载具有相同的安全级别，即6P不定义自己的安全机制。特别是，尽管密钥管理解决方案不在本文档范围内，但6P将受益于网络中使用的密钥管理解决方案。这是相关的，因为当两个以上的参与者共享一个密钥时，伪造和错误归因等安全攻击变得更具破坏性。
6P does not provide protection against DoS attacks. Example attacks include not sending confirmation messages in 3-step transactions and sending incorrectly formatted requests. These cases SHOULD be handled by an appropriate policy, such as rate-limiting or time-limited blacklisting of the attacker after several attempts. The effect on the overall network is mostly localized to the two nodes in question, as communication happens in dedicated cells.
6P不提供针对DoS攻击的保护。示例攻击包括在三步事务中不发送确认消息和发送格式不正确的请求。这些情况应通过适当的策略进行处理，例如在多次尝试后对攻击者进行速率限制或时间限制黑名单。由于通信发生在专用小区中，因此对整个网络的影响主要局限于所讨论的两个节点。
This document adds the following number to the "IEEE Std 802.15.4 IETF IE Subtype IDs" registry defined by [RFC8137]:
本文件将以下编号添加到[RFC8137]定义的“IEEE Std 802.15.4 IETF IE子类型ID”注册表中：
+--------+------------+-----------+
| Value | Subtype ID | Reference |
+--------+------------+-----------+
| 1 | SUBID_6TOP | RFC 8480 |
+---------------------+-----------+
+--------+------------+-----------+
| Value | Subtype ID | Reference |
+--------+------------+-----------+
| 1 | SUBID_6TOP | RFC 8480 |
+---------------------+-----------+
Figure 34: IETF IE Subtype SUBID_6TOP
图34:IETF IE子类型子ID6top
This section defines subregistries within the "IPv6 Over the TSCH Mode of IEEE 802.15.4e (6TiSCH)" parameters registry, hereafter referred to as the "6TiSCH parameters" registry. Each subregistry is described in a subsection.
本节定义了“IEEE 802.15.4e（6Disch）的TSCH模式下的IPv6”参数注册表（以下简称“6Disch参数”注册表）中的子域。每个分区都在一个小节中描述。
The name of the subregistry is "6P Version Numbers".
分区域名称为“6P版本号”。
The following note is included in this registry: "In the 6top Protocol (6P) [RFC8480], there is a field to identify the version of the protocol. This field is 4 bits in size."
此注册表中包含以下注释：“在6top协议（6P）[RFC8480]中，有一个字段用于标识协议的版本。此字段的大小为4位。”
Each entry in the subregistry must include the version in the range 0-15 and a reference to the 6P version's documentation.
子区域中的每个条目必须包括0-15范围内的版本和对6P版本文件的参考。
The initial entry in this subregistry is as follows:
本次区域的初始条目如下：
+---------+-----------+
| Version | Reference |
+---------+-----------+
| 0 | RFC 8480 |
+---------+-----------+
+---------+-----------+
| Version | Reference |
+---------+-----------+
| 0 | RFC 8480 |
+---------+-----------+
Figure 35: 6P Version Number Entry
图35:6P版本号条目
All other version numbers are Unassigned.
所有其他版本号均未分配。
The IANA policy for future additions to this subregistry is "IETF Review" or "IESG Approval" as described in [RFC8126].
本次区域未来新增的IANA政策为[RFC8126]中所述的“IETF审查”或“IESG批准”。
The name of the subregistry is "6P Message Types".
子区域的名称为“6P消息类型”。
The following note is included in this registry: "In version 0 of the 6top Protocol (6P) [RFC8480], there is a field to identify the type of message. This field is 2 bits in size."
此注册表中包含以下注释：“在6top协议（6P）[RFC8480]的版本0中，有一个字段用于标识消息类型。此字段的大小为2位。”
Each entry in the subregistry must include the message type in the range b00-b11, the corresponding name, and a reference to the 6P message type's documentation.
子目录中的每个条目必须包括b00-b11范围内的消息类型、相应名称以及对6P消息类型文档的引用。
Initial entries in this subregistry are as follows:
本次区域的初始条目如下：
+------+--------------+-----------+
| Type | Name | Reference |
+------+--------------+-----------+
| b00 | REQUEST | RFC 8480 |
| b01 | RESPONSE | RFC 8480 |
| b10 | CONFIRMATION | RFC 8480 |
+------+--------------+-----------+
+------+--------------+-----------+
| Type | Name | Reference |
+------+--------------+-----------+
| b00 | REQUEST | RFC 8480 |
| b01 | RESPONSE | RFC 8480 |
| b10 | CONFIRMATION | RFC 8480 |
+------+--------------+-----------+
Figure 36: 6P Message Types
图36:6P消息类型
All other message types are Unassigned.
所有其他消息类型都是未分配的。
The IANA policy for future additions to this subregistry is "IETF Review" or "IESG Approval" as described in [RFC8126].
本次区域未来新增的IANA政策为[RFC8126]中所述的“IETF审查”或“IESG批准”。
The name of the subregistry is "6P Command Identifiers".
子区域的名称为“6P命令标识符”。
The following note is included in this registry: "In version 0 of the 6top Protocol (6P) [RFC8480], there is a Code field that is 8 bits in size. In a 6P Request, the value of this Code field is used to identify the command."
此注册表中包含以下注释：“在6top协议（6P）[RFC8480]的版本0中，有一个8位大小的代码字段。在6P请求中，此代码字段的值用于标识命令。”
Each entry in the subregistry must include an identifier in the range 0-255, the corresponding name, and a reference to the 6P command identifier's documentation.
子目录中的每个条目必须包括范围为0-255的标识符、相应的名称以及对6P命令标识符文档的引用。
Initial entries in this subregistry are as follows:
本次区域的初始条目如下：
+------------+------------+-----------+
| Identifier | Name | Reference |
+------------+------------+-----------+
| 0 | Reserved | RFC 8480 |
| 1 | ADD | RFC 8480 |
| 2 | DELETE | RFC 8480 |
| 3 | RELOCATE | RFC 8480 |
| 4 | COUNT | RFC 8480 |
| 5 | LIST | RFC 8480 |
| 6 | SIGNAL | RFC 8480 |
| 7 | CLEAR | RFC 8480 |
| 8-254 | Unassigned | |
| 255 | Reserved | RFC 8480 |
+------------+------------+-----------+
+------------+------------+-----------+
| Identifier | Name | Reference |
+------------+------------+-----------+
| 0 | Reserved | RFC 8480 |
| 1 | ADD | RFC 8480 |
| 2 | DELETE | RFC 8480 |
| 3 | RELOCATE | RFC 8480 |
| 4 | COUNT | RFC 8480 |
| 5 | LIST | RFC 8480 |
| 6 | SIGNAL | RFC 8480 |
| 7 | CLEAR | RFC 8480 |
| 8-254 | Unassigned | |
| 255 | Reserved | RFC 8480 |
+------------+------------+-----------+
Figure 37: 6P Command Identifiers
图37:6P命令标识符
The IANA policy for future additions to this subregistry is "IETF Review" or "IESG Approval" as described in [RFC8126].
本次区域未来新增的IANA政策为[RFC8126]中所述的“IETF审查”或“IESG批准”。
The name of the subregistry is "6P Return Codes".
子区域名称为“6P返回代码”。
The following note is included in this registry: "In version 0 of the 6top Protocol (6P) [RFC8480], there is a Code field that is 8 bits in size. In a 6P Response or 6P Confirmation, the value of this Code field is used to identify the return code."
此注册表中包含以下注释：“在6top协议（6P）[RFC8480]的版本0中，有一个大小为8位的代码字段。在6P响应或6P确认中，此代码字段的值用于标识返回代码。”
Each entry in the subregistry must include a return code in the range 0-255, the corresponding name, the corresponding description, and a reference to the 6P return code's documentation. If the return code corresponds to a Response error, the "Is Error?" entry must indicate "Yes". Otherwise, "No" must be used.
子目录中的每个条目必须包括范围为0-255的返回代码、相应的名称、相应的说明以及对6P返回代码文档的引用。如果返回代码对应于响应错误，“是错误？”条目必须指示“是”。否则，必须使用“否”。
Initial entries in this subregistry are as follows:
本次区域的初始条目如下：
+------+-----------------+---------------------------+-----------+
| Code | Name | Description | Is Error? |
+------+-----------------+---------------------------+-----------+
| 0 | RC_SUCCESS | operation succeeded | No |
| 1 | RC_EOL | end of list | No |
| 2 | RC_ERR | generic error | Yes |
| 3 | RC_RESET | critical error, reset | Yes |
| 4 | RC_ERR_VERSION | unsupported 6P version | Yes |
| 5 | RC_ERR_SFID | unsupported SFID | Yes |
| 6 | RC_ERR_SEQNUM | schedule inconsistency | Yes |
| 7 | RC_ERR_CELLLIST | cellList error | Yes |
| 8 | RC_ERR_BUSY | busy | Yes |
| 9 | RC_ERR_LOCKED | cells are locked | Yes |
+------+-----------------+---------------------------+-----------+
+------+-----------------+---------------------------+-----------+
| Code | Name | Description | Is Error? |
+------+-----------------+---------------------------+-----------+
| 0 | RC_SUCCESS | operation succeeded | No |
| 1 | RC_EOL | end of list | No |
| 2 | RC_ERR | generic error | Yes |
| 3 | RC_RESET | critical error, reset | Yes |
| 4 | RC_ERR_VERSION | unsupported 6P version | Yes |
| 5 | RC_ERR_SFID | unsupported SFID | Yes |
| 6 | RC_ERR_SEQNUM | schedule inconsistency | Yes |
| 7 | RC_ERR_CELLLIST | cellList error | Yes |
| 8 | RC_ERR_BUSY | busy | Yes |
| 9 | RC_ERR_LOCKED | cells are locked | Yes |
+------+-----------------+---------------------------+-----------+
Figure 38: 6P Return Codes
图38:6P返回代码
All other message types are Unassigned.
所有其他消息类型都是未分配的。
The IANA policy for future additions to this subregistry is "IETF Review" or "IESG Approval" as described in [RFC8126].
本次区域未来新增的IANA政策为[RFC8126]中所述的“IETF审查”或“IESG批准”。
The name of the subregistry is "6P Scheduling Function Identifiers".
子区域的名称为“6P调度功能标识符”。
The following note is included in this registry: "In version 0 of the 6top Protocol (6P) [RFC8480], there is a field to identify the Scheduling Function to handle the message. This field is 8 bits in size."
此注册表中包含以下说明：“在6top协议（6P）[RFC8480]的版本0中，有一个字段用于标识处理消息的调度功能。此字段的大小为8位。”
Each entry in the subregistry must include an SFID in the range 0-255, the corresponding name, and a reference to the 6P Scheduling Function's documentation.
子区域中的每个条目必须包含范围为0-255的SFID、相应名称以及对6P调度功能文档的引用。
There are currently no entries in this subregistry.
此子区域中当前没有条目。
+------+---------------------------------+--------------------------+
| SFID | Name | Reference |
+------+---------------------------------+--------------------------+
| 0-255| Unassigned | |
+------+---------------------------------+--------------------------+
+------+---------------------------------+--------------------------+
| SFID | Name | Reference |
+------+---------------------------------+--------------------------+
| 0-255| Unassigned | |
+------+---------------------------------+--------------------------+
Figure 39: SF Identifier (SFID) Entry
图39：SF标识符（SFID）条目
All message types are Unassigned.
所有消息类型都是未分配的。
The IANA policy for future additions to this subregistry depends on the value of the SFID, as shown in Figure 40. These specifications must follow the guidelines of Section 4.
该分区未来新增的IANA政策取决于SFID的值，如图40所示。这些规范必须遵循第4节的指南。
+-----------+------------------------------+
| Range | Registration Procedures |
+-----------+------------------------------+
| 0-127 | IETF Review or IESG Approval |
| 128-255 | Expert Review |
+-----------+------------------------------+
+-----------+------------------------------+
| Range | Registration Procedures |
+-----------+------------------------------+
| 0-127 | IETF Review or IESG Approval |
| 128-255 | Expert Review |
+-----------+------------------------------+
Figure 40: SF Identifier (SFID): Registration Procedure
图40:SF标识符（SFID）：注册过程
The name of the subregistry is "6P CellOptions Bitmap".
该分区的名称为“6P CellOptions位图”。
The following note is included in this registry: "In version 0 of the 6top Protocol (6P) [RFC8480], there is an optional CellOptions field that is 8 bits in size."
此注册表中包含以下注释：“在6top协议（6P）[RFC8480]的版本0中，有一个可选的CellOptions字段，大小为8位。”
Each entry in the subregistry must include a bit position in the range 0-7, the corresponding name, and a reference to the bit's documentation.
子区域中的每个条目必须包括0-7范围内的位位置、相应名称以及对位文档的引用。
Initial entries in this subregistry are as follows:
本次区域的初始条目如下：
+-----+---------------+-----------+
| bit | Name | Reference |
+-----+---------------+-----------+
| 0 | TX (Transmit) | RFC 8480 |
| 1 | RX (Receive) | RFC 8480 |
| 2 | SHARED | RFC 8480 |
| 3-7 | Reserved | |
+-----+---------------+-----------+
+-----+---------------+-----------+
| bit | Name | Reference |
+-----+---------------+-----------+
| 0 | TX (Transmit) | RFC 8480 |
| 1 | RX (Receive) | RFC 8480 |
| 2 | SHARED | RFC 8480 |
| 3-7 | Reserved | |
+-----+---------------+-----------+
Figure 41: 6P CellOptions Bitmap
图41:6P CellOptions位图
All other message types are Unassigned.
所有其他消息类型都是未分配的。
The IANA policy for future additions to this subregistry is "IETF Review" or "IESG Approval" as described in [RFC8126].
本次区域未来新增的IANA政策为[RFC8126]中所述的“IETF审查”或“IESG批准”。
[IEEE802154] IEEE, "IEEE Standard for Low-Rate Wireless Networks", IEEE 802.15.4, DOI 10.1109/IEEESTD.2016.7460875.
[IEEE802154]IEEE，“低速无线网络的IEEE标准”，IEEE 802.15.4，DOI 10.1109/IEEESTD.2016.7460875。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC8137] Kivinen, T. and P. Kinney, "IEEE 802.15.4 Information Element for the IETF", RFC 8137, DOI 10.17487/RFC8137, May 2017, <https://www.rfc-editor.org/info/rfc8137>.
[RFC8137]Kivinen，T.和P.Kinney，“IETF的IEEE 802.15.4信息元素”，RFC 8137，DOI 10.17487/RFC8137，2017年5月<https://www.rfc-editor.org/info/rfc8137>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[CCM-Star] Struik, R., "Formal Specification of the CCM* Mode of Operation", IEEE P802.15-4/0537r2, September 2005.
[CCM Star]Struik，R.，“CCM*运行模式的正式规范”，IEEE P802.15-4/0537r2，2005年9月。
[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, <https://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月<https://www.rfc-editor.org/info/rfc7554>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, <https://www.rfc-editor.org/info/rfc7942>.
[RFC7942]Sheffer，Y.和A.Farrel，“提高运行代码的意识：实现状态部分”，BCP 205，RFC 7942，DOI 10.17487/RFC7942，2016年7月<https://www.rfc-editor.org/info/rfc7942>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]Cotton，M.，Leiba，B.，和T.Narten，“在RFC中编写IANA考虑事项部分的指南”，BCP 26，RFC 8126，DOI 10.17487/RFC8126，2017年6月<https://www.rfc-editor.org/info/rfc8126>.
[RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180, May 2017, <https://www.rfc-editor.org/info/rfc8180>.
[RFC8180]Vilajosana，X.，Ed.，Pister，K.，和T.Watteyne，“IEEE 802.15.4e（6TiSCH）配置TSCH模式下的最小IPv6”，BCP 210，RFC 8180，DOI 10.17487/RFC8180，2017年5月<https://www.rfc-editor.org/info/rfc8180>.
The following section structure for an SF document is RECOMMENDED:
建议SF文件采用以下章节结构：
o Introduction
o 介绍
o RFC 2119 Requirements Language (if applicable)
o RFC 2119要求语言（如适用）
o Scheduling Function Identifier
o 调度函数标识符
o Rules for Adding/Deleting Cells
o 添加/删除单元格的规则
o Rules for CellList
o 牢房名单规则
o 6P Timeout Value
o 6P超时值
o Rule for Ordering Cells
o 单元格排序规则
o Meaning of the Metadata Field
o 元数据字段的含义
o Node Behavior at Boot
o 启动时的节点行为
o Schedule Inconsistency Handling
o 计划不一致性处理
o 6P Error Handling
o 6P错误处理
o Examples
o 例子
o Implementation Status
o 实施情况
o Security Considerations
o 安全考虑
o IANA Considerations
o IANA考虑
o Normative References (if applicable)
o 规范性引用文件（如适用）
o Informative References (if applicable)
o 参考资料（如适用）
Authors' Addresses
作者地址
Qin Wang (editor) Univ. of Sci. and Tech. Beijing 30 Xueyuan Road Beijing, Hebei 100083 China
王勤（编辑）Sci大学。中国河北省北京市学院路30号北京科技大厦邮编：100083
Email: wangqin@ies.ustb.edu.cn
Email: wangqin@ies.ustb.edu.cn
Xavier Vilajosana Universitat Oberta de Catalunya 156 Rambla Poblenou Barcelona, Catalonia 08018 Spain
加泰罗尼亚奥贝塔泽维尔维拉霍萨纳大学156兰布拉波布伦努巴塞罗那，加泰罗尼亚08018西班牙
Email: xvilajosana@uoc.edu
Email: xvilajosana@uoc.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: thomas.watteyne@analog.com
Email: thomas.watteyne@analog.com