[要約] RFC 8480は、6TiSCHネットワークで使用される6topプロトコル（6P）に関する仕様です。6Pは、ネットワーク内のノード間でリソースの割り当てとスケジューリングを行うためのプロトコルです。このRFCの目的は、6Pプロトコルの機能と動作を明確に定義し、6TiSCHネットワークの効率と信頼性を向上させることです。
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)
6TiSCH操作サブレイヤー（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.
このドキュメントでは、6TiSCHネットワークで分散スケジューリングを可能にする「IEEE 802.15.4eのTSCHモードでのIPv6」（6TiSCH）操作サブレイヤー（6top）プロトコル（6P）を定義します。 6Pにより、隣接ノードはタイムスロットチャネルホッピング（TSCH）セルを相互に追加/削除できます。 6Pは6TiSCH Operation Sublayer（6top）の一部であり、IEEE Std 802.15.4 TSCH Medium Access Controlレイヤーのすぐ上のレイヤーです。 6topは、1つ以上のスケジューリング機能（SF）と、このドキュメントで定義されている6topプロトコルで構成されています。 6top SFはセルを追加/削除するタイミングを決定し、6Pトランザクションをトリガーします。 SFの定義はこのドキュメントの範囲外です。ただし、このドキュメントでは、SFの要件について説明します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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]によって調整されます。スケジュールはセルで構成され、各セルは[slotOffset、channelOffset]で識別されます（セクション3.2.4）。この仕様は、6topで終了する6TiSCH操作サブレイヤー（6top）プロトコル（6P）を定義します。 6Pを使用すると、ノードは隣接ノードと通信して、タイムスロットチャネルホッピング（TSCH）セルを相互に追加/削除できます。これにより、6TiSCHネットワークで分散スケジュール管理が行われます。 6topは、1つ以上のスケジューリング機能（SF）と、このドキュメントで定義されている6topプロトコルで構成されています。 SFの定義はこのドキュメントの範囲外です。ただし、このドキュメントでは、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"がノード "B"に6Pリクエスト（このドキュメントでは "コマンド"とも呼ばれます）を発行する正規のケースを考えます。このドキュメントでは、この例を使用しています。ノードAは常に6Pリクエストを発行するノードを表し、ノードBはこのリクエストを受信するノードを表します。
(R)
/ \
/ \
(B)-----(C)
| |
| |
(A) (D)
Figure 1: A Simple 6TiSCH Network
図1：シンプルな6TiSCHネットワーク
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トランザクションをトリガーして、1つ以上を追加します両方のノードの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スケジュール内の1つ以上のセルを削除します。
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と通信して、この特定のセルを別の[slotOffset、channelOffset]の場所に「再配置」 TSCHスケジュール。
This results in distributed schedule management in a 6TiSCH network.
これにより、6TiSCHネットワークで分散スケジュール管理が行われます。
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を実装して同時に実行できます（MAY）。少なくとも1つの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.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、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]のすぐ上のレイヤーです。このドキュメントでは、「IEEE Std 802.15.4」の短縮版として「802.15.4」を使用しています。
.
| . |
| 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 セルを追加/削除するタイミングを決定するルールを定義する1つまたは複数の6top SFを実行します。
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は、最小の6TiSCH構成[RFC8180]と併用できます。この場合、図3に示すように、2つのスロットフレームを使用することをお勧めします。
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 スロットフレーム0は、最小の6TiSCH構成で定義されたトラフィックに使用されます。図3では、Slotframe 0は5スロット長ですが、それより短くても長くてもかまいません。
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はスロットフレーム1からセルを割り当てます。図3では、スロットフレーム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 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：最小の6TiSCH構成で6Pを使用する場合の2スロットフレーム構造
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.
最小の6TiSCH構成セルは、動的なセル割り当てに6Pが使用するスロットフレームよりも高い優先度のスロットフレームから割り当てられる必要があります（SHOULD）。このようにして、動的に割り当てられたセルは、最小の6TiSCH構成で使用されるセルを「マスク」できません。 6topは追加のスロットフレームをサポートする場合があります。追加のスロットフレームを使用する方法は、このドキュメントの範囲外です。
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を使用すると、2つの隣接ノードがTSCHスケジュールでセルを追加/削除/再配置できます。概念的には、2つの隣接ノードが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トランザクション」を2つの隣接ノード間の完全なネゴシエーションと呼びます。 1つのSFによってトリガーされたアクションの結果として、特定の6Pトランザクションが2つのノード間で実行されます。 6Pトランザクションが成功するには、両方のノードが同じSFを使用して特定のトランザクションを処理する必要があります。 6Pトランザクションは、ノードが1つ以上のセルを隣接ノードの1つに追加/削除/再配置したいときに開始されます。 6Pトランザクションは、（1）両方のノードのスケジュールでセルが追加/削除/再配置されたとき、または（2）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の間に専用セルがスケジュールされていない場合、共有セルを使用できます（MAY）。 。
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.
2つの隣接ノードのスケジュール間の一貫性を保つことが重要です。一貫性が失われると、接続が失われる可能性があります。 1つの例は、ノードAにノードBへの送信セルがあるが、ノードBに対応する受信セルがない場合です。一貫性を確認するために、隣接ノードはシーケンス番号（SeqNum）を維持します。隣接ノードは、起こり得る不整合を検出するために、各6Pトランザクションの一部としてSeqNumを交換します。このメカニズムについては、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トランザクションは、2つまたは3つのステップで構成できます。 2ステップトランザクションは、ノードAが割り当てられるセルを選択するときに使用されます。ノードBが割り当てるセルを選択するときに、3ステップのトランザクションが使用されます。 SFは、2ステップトランザクション、3ステップトランザクション、またはその両方を使用するかどうかを指定する必要があります。
We illustrate 2-step and 3-step transactions using the topology in Figure 1.
図1のトポロジを使用して、2ステップおよび3ステップのトランザクションを示します。
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トランザクションの例を示しています。 2ステップトランザクションでは、ノード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 | |
| - - - - - - - - - - - - - - - - - - ->| <-+
| |
Figure 4: An Example 2-Step 6P Transaction
図4：2ステップ6Pトランザクションの例
In this example, the 2-step transaction occurs as follows:
この例では、2ステップトランザクションは次のように発生します。
1. The SF running on node A determines that two extra cells need to be scheduled to node B.
1. ノードAで実行されているSFは、ノードBに2つの追加セルをスケジュールする必要があると判断します。
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が3つの候補セルを選択します。ノード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は6P ADD要求をノードBに送信し、2つのセル（ "NumCells"値）を追加することを示し、3つの候補セルのリスト（ "CellList"値）を指定します。 CellListの各セルは[slotOffset、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 ADD要求の送信に成功した（つまり、リンク層の確認応答を受信した）後、ノード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要求のCellListから3つのセルのうち2つを選択します。ノード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への2つのセルが、ノード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が失われた場合、またはトランザクション中にノードの1つがパワーサイクルされた場合、スケジュールの不整合が発生する可能性があります。 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 |
+-> |<- - - - - - - - - - - - - - - - - - - |
| |
Figure 5: An Example 3-Step 6P Transaction
図5：3ステップ6Pトランザクションの例
In this example, the 3-step transaction occurs as follows:
この例では、3ステップのトランザクションは次のように発生します。
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は、2つの追加のセルをノードBにスケジュールする必要があると判断します。SFは3ステップのトランザクションを使用するため、候補セルを選択しません。
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は6B ADDリクエストをノードBに送信し、2つのセル（ "NumCells"値）を空の "CellList"で追加したいことを示します。この6P ADD要求は、ノード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要求を正常に送信した後、ノードAは6Pタイムアウトを開始して、ノードBから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は3つの候補セルを選択し、それらをロックします。ノードBはノードAに6P応答を返し、選択した3つのセルを示します。応答はノード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応答を正常に送信した後、ノードBは6Pタイムアウトを開始して、ノードAから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フィールドから2つのセルを選択し、それらをロックします。ノードAは6B確認をノードBに送り返し、選択したセルを示します。確認は、ノード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への2つのセルが、ノード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が失われた場合、またはトランザクション中にノードの1つで電源が再投入された場合、スケジュールの不整合が発生する可能性があります。 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メッセージは1つのホップを通過します。 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メッセージはIEで伝送されるため、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.
このドキュメントは、[RFC8137]で定義されたIETF IEのサブタイプである6top IEを、サブタイプSUBID_6TOPで定義します。 6top IEのサブタイプの内容は、セクション3.2.2で定義されています。 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...
+-+-+-+-+-+-+-+-+-
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バージョン（バージョン）：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）：予約済みビット。これらの2ビットはメッセージを送信するときにゼロに設定する必要があり（SHOULD）、受信時に無視する必要があります。
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コマンドIDをリストしています。 6Pメッセージのタイプ値がRESPONSEまたはCONFIRMATIONである場合、Codeフィールドには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.
6トップスケジューリング機能識別子（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確認を照合するために使用されます。 SeqNumの値は、同じネイバーに発行され、同じSFを使用する新しい6Pリクエストごとに異なる必要があります。 SeqNumは、2つのネイバーのスケジュール間の整合性を確保するためにも使用されます。セクション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バージョン、タイプ、およびコードフィールドのフォーマットを維持する必要があります（SHOULD）。
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要求に存在します：ADD、DELETE、COUNT、LIST、およびRELOCATE。このフィールドのフォーマットと意味は、SFによって再定義される場合があります。したがって、このフィールドを解析するルーチンは、特定のSFに関連付けられています。
o In the 6P ADD Request, the 6P CellOptions bitmap is used to specify what type of cell to add.
o 6P ADDリクエストでは、6P CellOptionsビットマップを使用して、追加するセルのタイプを指定します。
o In the 6P DELETE Request, the 6P CellOptions bitmap is used to specify what type of cell to delete.
o 6P DELETE要求では、6P CellOptionsビットマップを使用して、削除するセルのタイプを指定します。
o In the 6P RELOCATE Request, the 6P CellOptions bitmap is used to specify what type of cell to relocate.
o 6P RELOCATEリクエストでは、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 COUNTおよびLIST要求では、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 CellOptionsの可能な値は次のとおりです。
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（または0）は、802.15.4のmacLinkTableのmacSharedType = TRUE（または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 ADD、DELETE、およびRELOCATEリクエストの6P CellOptionsビットマップの意味を示しています（SFによって再定義されている場合を除く）。図8は、6P COUNTおよびLISTリクエストの6P CellOptionsビットマップの意味を示しています（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) |
+-------------+-----------------------------------------------------+
Figure 7: Meaning of the 6P CellOptions Bitmap for the 6P ADD, DELETE, and RELOCATE Requests
図7：6P ADD、DELETE、およびRELOCATE要求の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 |
+-------------+-----------------------------------------------------+
Figure 8: Meaning of the 6P CellOptions Bitmap for the 6P COUNT and LIST Requests
図8：6P COUNTおよびLIST要求の6P CellOptionsビットマップの意味
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.
CellOptionsは不透明なビットのセットを構成し、変更されずにSFに送信されます。 SFは、CellOptionsフィールドのフォーマットと意味を再定義してもよい（MAY）。
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.
CellListフィールドは、6P ADD要求、6P DELETE要求、6P RELOCATE要求、6P応答、または6P確認に存在する場合があります。これは、図9で定義されている0個以上の6Pセルの連結で構成されています。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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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で定義されているPayload IEヘッダーのIE Lengthフィールドによって決定されます。 SFはCellListフィールドのフォーマットを再定義してもよい（MAY）。したがって、このフィールドを解析するルーチンは、特定の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コマンドを使用して追加されます。 Typeフィールド（T）はREQUESTに設定されます。 [コード]フィールドはADDに設定されています。図10は、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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metadata | CellOptions | NumCells |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CellList ...
+-+-+-+-+-+-+-+-+-
Figure 10: 6P ADD Request Format
図10：6P ADDリクエストのフォーマット
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への追加のシグナリングとして使用されます。 Metadataフィールドの内容は、変更されずにSFに渡される不透明なバイトのセットです。このフィールドの意味はSFに依存し、このドキュメントの範囲外です。たとえば、メタデータは、セルを追加するスロットフレームを指定できます。
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.
CellList：ゼロまたは複数の候補セルのリスト。その長さは暗黙であり、ペイロード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 ...
+-+-+-+-+-+-+-+-+-
Figure 11: 6P ADD Response and Confirmation Format
図11：6P ADD応答および確認フォーマット
CellList: A list of zero or more 6P Cells.
CellList：0個以上の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は、CellOptions、NumCellsの値、およびCellList内のNumCandidateセルの選択を含む6P ADD要求をノードBに送信します。 NumCandidateセルが1つのパケットに収まらない場合、この操作は複数の独立した6P ADDリクエストに分割する必要があります。それぞれ、最終的に追加する必要のあるセル数のサブセットごとに行います。 3ステップのトランザクションの場合、SFは、返されたCandidate CellListが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は、CellOptionsが図7に示すように有効な値に設定されているかどうかを確認します。そうでない場合は、コードRC_ERRの応答が返されます。ノードBで受信したCellListのセル数がNumCellsより小さい場合、ノードBはRC_ERR_CELLLISTコードを含む6P応答を返さなければなりません（MUST）。そうでない場合、ノードBのSFは、指定されたCellOptionsフィールドに従って、ノードBのスケジュールにインストールできるCellList内のセルを確認します。その選択方法はSFで指定されており、このドキュメントの範囲外です。検証は成功する（CellListのNumCellsセルを使用できる）、失敗する（CellListのセルはどれも使用できない）、または部分的に成功する（CellListのNumCellsセルよりも少ない数しか使用できない）場合があります。すべての場合において、ノードBは、RC_SUCCESSに設定された戻りコードを含み、CellOptionsフィールドの後にスケジュールされたセルのリストを指定する6P応答を送信する必要があります。そのリストには、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コマンドを使用して削除されます。 Typeフィールド（T）はREQUESTに設定されます。 [コード]フィールドはDELETEに設定されています。図12は、6P DELETE要求のフォーマットを定義しています。
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 DELETEリクエストのフォーマット
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：削除するセルに関連付ける必要があるオプションを示します。 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のセルの数。
CellList: A list of zero or more 6P Cells. Its length is determined by the Length field of the Payload IE header.
CellList：0個以上の6Pセルのリスト。その長さは、ペイロードIEヘッダーの長さフィールドによって決定されます。
Figure 13 defines the format of a 6P DELETE Response and Confirmation.
図13は、6P DELETE応答および確認のフォーマットを定義しています。
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 DELETE応答および確認フォーマット
CellList: A list of zero or more 6P Cells.
CellList：0個以上の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内のすべてのセルは、2つのノード間ですでにスケジュールされている必要があり、CellOptionsフィールドと一致する必要があります。ノードAが2つのノード間でまだスケジュールされておらず、CellOptionsフィールドに一致しないセルをCellListに配置する場合、ノード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ステップトランザクション）のCellListは、空であるか、正確に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.
セルの再配置は、スケジュール内の別の[slotOffset、channelOffset]の場所にセルを移動することで構成されます。 Typeフィールド（T）はREQUESTに設定されます。 CodeフィールドはRELOCATEに設定されています。図14は、6P RELOCATE要求のフォーマットを定義しています。
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 RELOCATEリクエストのフォーマット
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.
Relocation CellList：再配置する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.
Candidate CellList：ノード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).
2ステップ6P RELOCATEトランザクションでは、ノードAは、（1）再配置する必要があるセルと、（2）再配置先の候補セルのリストの両方を指定します。 Relocation CellListには、正確にNumCellsエントリが含まれている必要があります。候補CellListには、少なくとも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 RELOCATEトランザクションでは、ノードAは、再配置する必要があるセルのみを指定します。再配置先の候補セルのリストは指定しません。したがって、候補CellListは空でなければなりません。
Figure 15 defines the format of a 6P RELOCATE Response and Confirmation.
図15は、6P RELOCATE応答および確認のフォーマットを定義しています。
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 RELOCATE応答および確認フォーマット
CellList: A list of zero or more 6P Cells.
CellList：0個以上の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 RELOCATE要求を作成し、再配置するセルを再配置CellListに示します。また、セルを再配置する候補セルとしてNumCandidateセルをスケジュールから選択し、それらをCandidate CellListに配置します。 CellOptionsフィールドは、再配置するセルのタイプを指定します。 NumCandidateはNumCells以上でなければなりません。選択するセルの数（NumCandidate）とその選択方法はSFで指定されており、このドキュメントの範囲外です。ノードAは6P RELOCATE要求をノードBに送信します。
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は、候補CellListの長さがNumCells以上かどうかを確認します。ノードBのSFは、再配置CellListのすべてのセルがノードAでスケジュールされ、CellOptionsフィールドで指定されたオプションに関連付けられていることを確認します。いずれかのチェックが失敗した場合、ノードBは戻りコードRC_ERR_CELLLISTを使用してノードAに6P応答を送信する必要があります。両方のチェックに合格すると、ノードBのSFは、候補CellList内のどのセルをスケジュールにインストールできるかを確認します。その選択方法はSFで指定されており、このドキュメントの範囲外です。 Candidate CellListの検証が成功する（Candidate CellListのNumCellsセルを使用できる）、失敗する（Candidate CellListのどのセルも使用できない）、または部分的に成功する（Candidate CellListのNumCellsセルより少ない数を使用できる） ）。すべての場合において、ノードBは、RC_SUCCESSに設定された戻りコードを含み、CellOptionsフィールドに続いて再スケジュールされるセルのリストを指定する6P応答を送信する必要があります。そのリストには、NumCells要素（成功）、0要素（失敗）、または0からNumCells要素（部分的に成功）を含めることができます。 CellListにN <NumCellsセルが表示される場合、これはRelocation 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は、コードRC_SUCCESSの応答を受信すると、そのRELOCATE要求の再配置CellListで指定されたセルを、6P応答のCellListで指定された新しい場所に同じ順序で再配置します。受信した戻りコードがRC_ERR_CELLLISTの場合、トランザクションは中止され、セルは再配置されません。 2ステップトランザクションの場合、ノードBは6P応答のリンク層ACKを受信すると、選択されたセルを再配置します。 3ステップトランザクションの場合、ノード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は、2つのノード間のすべてのセルを同時に再配置しないでください。これにより、両方のノードのスケジュールが大幅に異なる可能性があります。
Figure 16 shows an example of a successful 2-step 6P RELOCATE Transaction.
図16は、成功した2ステップ6P RELOCATEトランザクションの例を示しています。
+----------+ +----------+
| 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：成功した2ステップ6P RELOCATEトランザクションの例
Figure 17 shows an example of a partially successful 2-step 6P RELOCATE Transaction.
図17は、部分的に成功した2ステップ6P RELOCATEトランザクションの例を示しています。
+----------+ +----------+
| 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：部分的に成功した2ステップ6P RELOCATEトランザクションの例
Figure 18 shows an example of a failed 2-step 6P RELOCATE Transaction.
図18は、失敗した2ステップ6P 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 RELOCATEトランザクションの例
Figure 19 shows an example of a successful 3-step 6P RELOCATE Transaction.
図19は、成功した3ステップ6P RELOCATEトランザクションの例を示しています。
+----------+ +----------+
| 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 RELOCATEトランザクションの例
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コマンドを発行します。 Typeフィールド（T）はREQUESTに設定されます。 [コード]フィールドはCOUNTに設定されています。図20は、6P COUNT要求のフォーマットを定義しています。
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 COUNTリクエストの形式
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 COUNT応答のフォーマットを定義しています。
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 COUNT応答フォーマット
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は、いくつかのセルオプションを指定して、COUNTコマンドをノードBに発行します。 6P COUNT要求を受信すると、ノードBはそのスケジュールを通過し、要求のCellOptionsフィールドのセルオプションと一致する独自のスケジュールでノードAでスケジュールされたセルの数をカウントします。セクション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は、戻りコードRC_SUCCESSと要求に一致するセルの数を含むNumCellsでノードAに6P応答を発行します。
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コマンドを発行します。 Typeフィールド（T）はREQUESTに設定されます。 [コード]フィールドはLISTに設定されています。図22は、6P LIST要求のフォーマットを定義しています。
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 LISTリクエストのフォーマット
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.
CellOptions：リストするセルのタイプを指定します。
Reserved: Reserved bits. These bits SHOULD be set to zero when sending the message and MUST be ignored upon reception.
予約済み：予約済みビット。これらのビットは、メッセージを送信するときにゼロに設定する必要があり（SHOULD）、受信時に無視する必要があります。
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 LIST応答のフォーマットを定義しています。
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 LIST応答フォーマット
CellList: A list of zero or more 6P Cells.
CellList：0個以上の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がLIST要求を受信すると、6P応答で返されたCellListには、指定されたオフセットから開始して、0〜MaxNumCellsのセルが含まれます。ノードBは、フレームに収まるだけの数のセルを含める必要があります（SHOULD）。応答に最後のセルが含まれている場合、ノードBは、RC_EOL（セクション6.2.4の図38の「リストの終わり」）の応答にコードフィールドを設定し、一致するセルがそれ以上ないことをノードAに示す必要があります。リクエスト。ノードBは、指定されたオフセットがそのスケジュールのBのセルリストの最後を超えていない限り、少なくとも1つのセルを返さなければなりません（MUST）。ノードBのリクエストに一致するオフセットセルがノードBより少ない場合、ノードBは空のCellListと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はCLEARコマンドを発行します。 Typeフィールド（T）はREQUESTに設定されます。 [コード]フィールドは[クリア]に設定されています。図24は、6P CLEAR要求のフォーマットを定義しています。
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 CLEARリクエストのフォーマット
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 25: 6P CLEAR Response Format
図25：6P CLEAR応答フォーマット
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.
6A CLEARコマンドがノードAからノードBに発行されると、ノードAとBの両方が、それらの間にスケジュールされたすべてのセルを削除する必要があります。つまり、ノードAはノードBでスケジュールされたすべてのセルを削除する必要があり、ノードBはノードAでスケジュールされたすべてのセルを削除する必要があります。6PCLEARコマンドでは、SeqNumをチェックしてはなりません（MUST NOT）。特に、通常はノードBがスケジュールの不整合を検出する原因となるSeqNum値が要求に含まれている場合でも、トランザクションを中止してはなりません（MUST NOT）。 6P CLEARの完了時に、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である必要があります。 CLEAR操作を実行できない場合は、戻りコードを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 SIGNALメッセージを使用すると、2つの隣接ノードのSF実装で一般的なコマンドを交換できます。受信したSIGNALメッセージのペイロードは、変更されずにSFに渡される不透明なバイトのセットです。ペイロードの長さは、ペイロードIEヘッダーの長さフィールドによって決まります。汎用のSIGNALコマンドの使用方法はSFによって指定されており、このドキュメントの範囲外です。 Typeフィールド（T）はREQUESTに設定されます。 CodeフィールドはSIGNALに設定されています。図26は、6P SIGNAL要求のフォーマットを定義しています。
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 SIGNALリクエストのフォーマット
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 SIGNAL応答のフォーマットを定義しています。
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 SIGNAL応答フォーマット
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 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.
すべてのメッセージには、バージョンフィールドが含まれています。 6Pの複数のプロトコルバージョンが定義されている場合（0とは異なるバージョン値の将来の仕様で）、ノードは同時に複数のプロトコルバージョンを実装できます（MAY）。ノードが実装していないバージョン番号を含む6Pメッセージを受信した場合、ノードは戻りコードフィールドをRC_ERR_VERSIONに設定した6P応答で応答する必要があります。この6P応答メッセージの形式は、バージョン0に準拠する必要があり、プロトコルの将来のすべてのバージョンでサポートされる必要があります。これにより、ノードBが6P要求に6Pバージョンを実装していないことを示す6P応答をノードAに送信すると、ノード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要求のバージョンフィールドと同じでなければなりません（MUST）。同様に、3ステップトランザクションでは、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を同時にサポートしてもよい（MAY）。サポートされていないSFIDを含む6Pメッセージを受信した場合、ノードは戻りコードRC_ERR_SFIDを含む6P応答で応答する必要があります。 6P応答のSFIDフィールドは、対応する6P要求のSFIDフィールドと同じである必要があります。 3ステップトランザクションでは、6P確認のSFIDフィールドは、同じトランザクションの6P要求と6P応答のフィールドと一致する必要があります。
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).
特定の方向で一度に1つの6Pトランザクションのみが、2つのネイバー間で実行できます。つまり、ノードは、それが開始した前の6Pトランザクションが終了する（またはタイムアウトする）前に、特定のネイバーに新しい6Pリクエストを発行してはなりません（MUST NOT）。ノードが特定のネイバーから6Pリクエストを受信する前に、そのネイバーから前の6Pリクエストへの6Pレスポンスを送信する場合、ノードはRC_RESETのリターンコードで6Pレスポンスを返信する必要があります（セクション6.2.4の図38のとおり）。この進行中の2番目のトランザクションを破棄します。 RC_RESETコードを受信するノードは、2番目のトランザクションを中止し、それが発生しなかったかのように処理する必要があります（つまり、このトランザクションによって行われたスケジュールまたは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は、2つのトランザクションが同時に進行することをサポートする場合があります（各方向に1つ）。同様に、ノードは異なるネイバーとの同時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によって定義された再試行メカニズムを実装してもよい（MAY）。
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応答を受信しない場合、タイムアウトが発生します。 3ステップトランザクションでは、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リクエストの受信者が失敗し、それを完了できない場合、6P応答で戻りコードRC_RESETを使用して、そのリクエストに応答する必要があります（SHOULD）。この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.
同様に、3ステップトランザクションの場合、6Pトランザクションの受信者が6Pトランザクション中に失敗し、それを完了できない場合、6P確認に戻りコードRC_RESETで応答する必要があります。この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をサポートする場合、SeqNum値は、SFごと、およびネイバーごとに維持されます。このセクションの残りの部分では、2つのネイバー間の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.
ノードがリセットするとき、またはCLEARトランザクションの後で、ノードは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トランザクションが終了した後、ノードAは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は、SeqNumが0のノードAから6Pリクエストを受信すると、Aの保存されたSeqNumをチェックします。Aが新しいネイバーの場合、Bに保存されたSeqNumは0になります。トランザクションは続行できます。 BのAに格納されたSeqNumが0と異なる場合、潜在的な不整合が検出されます。この場合、BはSeqNum = 0でRC_ERR_SEQNUMを返す必要があります。ノードAのSFは、セクション3.4.6.2で説明されているように、次に何をすべきかを決定してもよい（MAY）。
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 |
+-----------+------------------------------+
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コマンドはすべて、リンク層で確認されます。重複メッセージは、ノードが2番目の6P要求、応答、または確認を受信することを意味します。これは、リンク層の確認応答が受信されず、リンク層の再送信が発生した場合に発生します。メッセージの重複は正常であり、避けられません。
Figure 29 shows an example 2-step transaction in which node A receives a duplicate 6P Response.
図29は、ノードAが重複する6P応答を受信する2ステップトランザクションの例を示しています。
+----------+ +----------+
| 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は、ノードAが6P確認を送信した後、順不同の重複した6P応答を受信する3ステップトランザクションの例を示しています。
+----------+ +----------+
| 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
各6PメッセージにあるSeqNumフィールドは、不整合を検出するために使用されます。セクション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.
スケジュールの不整合が発生するケースは2つあります。
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 |
| - - - - - - - - - - - - - - - - - - ->|
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 |
|<- - - - - - - - - - - - - - - - - - - |
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.
2番目のケースは、2段階のトランザクションの6P応答（または、3段階のトランザクションの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
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）、それを検出したノードは、エラーコードRC_ERR_SEQNUMとともに6P応答または6P確認を送信する必要があります。この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は、不整合を処理する方法を定義する必要があります。これを行うには、次の3つの方法があります。
o Issue a 6P CLEAR Request to clear the schedule, and then rebuild.
o 6P CLEARリクエストを発行してスケジュールをクリアしてから、再構築します。
o Issue a 6P LIST Request to retrieve the schedule.
o 6P LISTリクエストを発行して、スケジュールを取得します。
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のADD、DELETE、またはRELOCATE要求に対する応答である場合、ノードはこの6Pトランザクションに関係するセルを追加、削除、または再配置してはなりません（MUST NOT）。同様に、エラーコードとともに6P応答または6P確認を送信するノードは、その6Pトランザクションの一部としてセルを追加、削除、または再配置してはなりません（MUST NOT）。ノードが認識されない戻りコードを受け取った場合、6Pトランザクションは失敗したと見なされなければなりません（MUST）。特に、3ステップの6Pトランザクションでは、認識できない戻りコードを含む6P応答を受信した場合、リクエスター（ノードA）は戻りコードRC_ERRを含む6P確認をレスポンダー（ノードB）に送信し、トランザクションは失敗しました。戻りコードRC_ERRの6P確認を受信すると、レスポンダはトランザクションも失敗したと見なす必要があります。エラーが発生した後に何をするかを定義することは、このドキュメントの範囲外です。 SFは、エラーが発生した後の処理を定義します。
6P messages MUST be secured through link-layer security. This is possible because 6P messages are carried as Payload IEs.
6Pメッセージは、リンク層セキュリティを介して保護する必要があります。 6PメッセージはペイロードIEとして伝送されるため、これは可能です。
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 ノードが1つ以上のセルを隣接ノードに追加/削除するタイミングを決定するためのルールを指定する必要があります。
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 ADDリクエストのCellListフィールドに追加するセルを選択するためのルールを指定する必要があります。
o MUST specify the rule for a transaction destination to select cells from the CellList to add to its schedule.
o スケジュールに追加するCellListからセルを選択するトランザクション宛先のルールを指定する必要があります。
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 ADDリクエストのメタデータフィールドの意味を指定する必要があります。
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応答を送信するか、受信しました）。
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）状態の間、現在の実装のリストを含める必要があります（SHOULD）。
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 SIGNALコマンドのペイロードの形式とその使用を定義する必要があります。
o MAY redefine the format of the CellList field.
o CellListフィールドのフォーマットを再定義できます。
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ペイロード情報要素（IE）内で運ばれます。これらのペイロードIEは、CCM * [CCM-Star]を介してリンク層で暗号化および認証されます（「CCM」は「暗号ブロックチェーン-メッセージ認証コード」の略です）。 6Pは、他のPayload IEと同じレベルのセキュリティの恩恵を受けます。 6Pは独自のセキュリティメカニズムを定義していません。特に、キー管理ソリューションはこのドキュメントの範囲外ですが、6Pはネットワークで使用されるキー管理ソリューションの恩恵を受けます。偽造や誤配攻撃などのセキュリティ攻撃は、単一のキーが3人以上の参加者のグループ間で共有されている場合により大きなダメージを与えるため、これは重要です。
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攻撃に対する保護を提供しません。攻撃の例としては、3ステップのトランザクションで確認メッセージを送信しない、不正な形式のリクエストを送信するなどがあります。これらのケースは、数回の試行後の攻撃者のレート制限または時間制限のあるブラックリストなどの適切なポリシーによって処理する必要があります（SHOULD）。通信は専用セルで行われるため、ネットワーク全体への影響は、主に問題の2つのノードに限定されます。
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 Subtype IDs」レジストリに次の番号を追加しています。
+--------+------------+-----------+
| Value | Subtype ID | Reference |
+--------+------------+-----------+
| 1 | SUBID_6TOP | RFC 8480 |
+---------------------+-----------+
Figure 34: IETF IE Subtype SUBID_6TOP
図34：IETF IEサブタイプSUBID_6TOP
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のTSCHモードを介したIPv6（6TiSCH）」パラメータレジストリ内のサブレジストリを定義します。これ以降、「6TiSCHパラメータ」レジストリと呼びます。各サブレジストリについては、サブセクションで説明します。
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 |
+---------+-----------+
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 |
+------+--------------+-----------+
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 Command Identifiers」です。
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 |
+------------+------------+-----------+
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 Return Codes」です。
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 |
+------+-----------------+---------------------------+-----------+
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 Scheduling Function Identifiers」です。
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 | |
+------+---------------------------------+--------------------------+
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ポリシーは、図40に示すように、SFIDの値によって異なります。これらの仕様は、セクション4のガイドラインに従う必要があります。
+-----------+------------------------------+
| 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 Bitmap」です。
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には、サイズが8ビットのオプションのCellOptionsフィールドがあります。」
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 | |
+-----+---------------+-----------+
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。、編、Palattella、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]コットン、M。、レイバ、B。、およびT.ナルテン、「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 CellListのルール
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
Q in Wang（editor）UN IV。of SCI。and tech。Beijing 30 X UE元road Beijing、彼は100083中国でした
Email: wangqin@ies.ustb.edu.cn
Xavier Vilajosana Universitat Oberta de Catalunya 156 Rambla Poblenou Barcelona, Catalonia 08018 Spain
Xavier Vilajosana Open University of Catalonia 156 Rambla Poblenou Barcelona、Catalonia 08018 Spain
Email: xvilajosana@uoc.edu
Thomas Watteyne Analog Devices 32990 Alvarado-Niles Road, Suite 910 Union City, CA 94587 United States of America
Thomas Watteyne Analog Devices 32990 Alvarado-Niles Road、Suite 910 Union City、CA 94587アメリカ合衆国
Email: thomas.watteyne@analog.com