6TiSCHInternet Engineering Task Force (IETF) Q. Wang, Ed.Internet-DraftRequest for Comments: 8480 Univ. of Sci. and Tech. BeijingIntended status:Category: Standards Track X. VilajosanaExpires: December 22, 2018ISSN: 2070-1721 Universitat Oberta de Catalunya T. Watteyne Analog DevicesJune 20,November 2018 6TiSCH Operation Sublayer (6top) Protocol (6P)draft-ietf-6tisch-6top-protocol-12Abstract This document defines theIPv6"IPv6 over the TSCH mode of IEEE802.15.4e802.15.4e" (6TiSCH) Operation Sublayer (6top) Protocol (6P), which enables distributed scheduling in 6TiSCH networks. 6P allows neighbor nodes to add/deleteTSCHTime-Slotted Channel Hopping (TSCH) cellstoto/on one another. 6P is part of the 6TiSCH Operation Sublayer (6top), thenext higherlayertojust above the IEEE Std 802.15.4 TSCHmedium access controlMedium Access Control layer.The6toplayer terminatesis composed of one or more Scheduling Functions (SFs) and the 6top Protocol defined in thisdocument, and runs one or more 6top Scheduling Function(s).document. A 6topScheduling Function (SF)SF decides when to add/delete cells, and it triggers 6P Transactions.This document lists the requirements for an SF, but leaves theThe definition of SFs is out ofscope. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" inscope for this document; however, this documentare to be interpreted as described in RFC 2119 [RFC2119].provides the requirements for an SF. Status of This Memo ThisInternet-Draftissubmitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documentsan Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF).Note that other groups may also distribute working documents as Internet-Drafts. The listIt represents the consensus ofcurrent Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents validthe IETF community. It has received public review and has been approved fora maximumpublication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 ofsix monthsRFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may beupdated, replaced, or obsoleted by other documentsobtained atany time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 22, 2018.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. 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. Table of Contents 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . 3....................................................3 1.1. Requirements Language ......................................5 2. 6TiSCH Operation Sublayer (6top). . . . . . . . . . . . . . 4................................5 2.1. Hard/Soft Cells. . . . . . . . . . . . . . . . . . . . . 5............................................6 2.2. Using 6P with the Minimal 6TiSCH Configuration. . . . . 5.............6 3. 6top Protocol (6P). . . . . . . . . . . . . . . . . . . . . 6..............................................7 3.1. 6P Transactions. . . . . . . . . . . . . . . . . . . . . 6............................................7 3.1.1.2-step2-Step 6P Transaction. . . . . . . . . . . . . . . . 7...............................8 3.1.2.3-step3-Step 6P Transaction. . . . . . . . . . . . . . . . 9..............................10 3.2. Message Format. . . . . . . . . . . . . . . . . . . . . 11............................................12 3.2.1. 6top Information Element (IE). . . . . . . . . . . . 11......................12 3.2.2. Generic 6P Message Format. . . . . . . . . . . . . . 11..........................12 3.2.3. 6P CellOptions. . . . . . . . . . . . . . . . . . . 12.....................................13 3.2.4. 6P CellList. . . . . . . . . . . . . . . . . . . . . 15........................................16 3.3. 6P Commands and Operations. . . . . . . . . . . . . . . 16................................17 3.3.1. Adding Cells. . . . . . . . . . . . . . . . . . . . 16.......................................17 3.3.2. Deleting Cells. . . . . . . . . . . . . . . . . . . 18.....................................19 3.3.3. Relocating Cells. . . . . . . . . . . . . . . . . . 19...................................21 3.3.4. Counting Cells. . . . . . . . . . . . . . . . . . . 25.....................................27 3.3.5. Listing Cells. . . . . . . . . . . . . . . . . . . . 26......................................28 3.3.6. Clearing the Schedule. . . . . . . . . . . . . . . . 28..............................30 3.3.7. Generic SignalingBetweenbetween SFs. . . . . . . . . . . . 29......................31 3.4. Protocol Functional Details. . . . . . . . . . . . . . . 29...............................31 3.4.1. Version Checking. . . . . . . . . . . . . . . . . . 29...................................31 3.4.2. SFID Checking. . . . . . . . . . . . . . . . . . . . 30......................................32 3.4.3. Concurrent 6P Transactions. . . . . . . . . . . . . 30.........................32 3.4.4. 6P Timeout. . . . . . . . . . . . . . . . . . . . . 31.........................................33 3.4.5. Aborting a 6P Transaction. . . . . . . . . . . . . . 31..........................33 3.4.6. SeqNum Management. . . . . . . . . . . . . . . . . . 31..................................33 3.4.7. Handling Error Responses. . . . . . . . . . . . . . 38...........................40 3.5. Security. . . . . . . . . . . . . . . . . . . . . . . . 38..................................................40 4. Requirements for 6top SchedulingFunctionsFunction (SF)Specification 38Specifications ..41 4.1. SF Identifier (SFID). . . . . . . . . . . . . . . . . . 38......................................41 4.2. Requirements for an SFspecification . . . . . . . . . . 38Specification ......................41 5. Security Considerations. . . . . . . . . . . . . . . . . . . 39........................................42 6. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 39............................................43 6.1. IETF IE Subtype'6P' . . . . . . . . . . . . . . . . . . 406P ........................................43 6.2. 6TiSCHparameters sub-registries . . . . . . . . . . . . 40Parameters Subregistries ...........................43 6.2.1.6P Version Numbers . . . . . . . . . . . . . . . . . 406P Version Numbers .................................43 6.2.2. 6P Message Types. . . . . . . . . . . . . . . . . . 41...................................44 6.2.3. 6P Command Identifiers. . . . . . . . . . . . . . . 41.............................44 6.2.4. 6P Return Codes. . . . . . . . . . . . . . . . . . . 42....................................45 6.2.5. 6P Scheduling Function Identifiers. . . . . . . . . 43.................46 6.2.6. 6P CellOptionsbitmap . . . . . . . . . . . . . . . . 44Bitmap ..............................47 7. References. . . . . . . . . . . . . . . . . . . . . . . . . 44.....................................................48 7.1. Normative References. . . . . . . . . . . . . . . . . . 45......................................48 7.2. Informative References. . . . . . . . . . . . . . . . . 45....................................48 Appendix A. Recommended Structure of an SF Specification. . . . 46..........49 Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . 46................................................50 1. Introduction All communication ina IPv6an "IPv6 over the TSCH mode of IEEE802.15.4e802.15.4e" (6TiSCH) network is orchestrated by a schedule [RFC7554]. The schedule is composed of cells, each identified by a[slotOffset,channelOffset].[slotOffset,channelOffset] (Section 3.2.4). This specification defines the 6TiSCH Operation Sublayer (6top) Protocol (6P), which is terminated bythe 6TiSCH Operation sublayer (6top).6top. 6P allows a node to communicate with a neighbor node to add/deleteTSCHTime-Slotted Channel Hopping (TSCH) cellstoto/on one another. This results in distributed schedule management in a 6TiSCH network.The6toplayer terminates the 6top Protocol, and runsis composed of one or more6topScheduling Functions (SFs)that decide when to add/delete cellsandtrigger 6P Transactions.the 6top Protocol defined in this document. TheSFdefinition of SFs is out of scopeoffor thisdocument butdocument; however, this documentdefinesprovides the requirements for an SF.(R) / \ / \ (B)-----(C) | | | | (A) (D) Figure 1: A simple 6TiSCH network.The example network depicted in Figure 1 is used to describe the interaction between nodes. We consider the canonical case where node "A" issues 6PrequestsRequests (also referred to as "commands" in this document) to node "B". Wekeepuse this example throughout thisdocument. Throughout the document,document: node A always represents the node that issues a 6Prequest;Request, and node B represents the node that receives this request. (R) / \ / \ (B)-----(C) | | | | (A) (D) Figure 1: A Simple 6TiSCH Network We consider that node A monitors the communication cells it has in its schedule to node 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 If the traffic is lower than thecapacity,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 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"thethis particular cellwhich undergoes collisionsto a different [slotOffset,channelOffset] location in the TSCH schedule. This results in distributed schedule management in a 6TiSCH network. The 6topScheduling Function (SF)SF defines when to add/delete a celltoto/on a neighbor. Different applications require differentSFs, so the SFSFs; this topic isleftout of scopeoffor 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. Section 2 describesthe 6TiSCH Operation Sublayer (6top).6top. Section 3 definesthe 6top Protocol (6P).6P. Section 4 provides guidelines on how to define an SF. 1.1. Requirements Language 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. 2. 6TiSCH Operation Sublayer (6top) As depicted in Figure 2,the 6TiSCH Operation Sublayer (6top)6top is thenext higherlayertojust above the IEEE Std 802.15.4 TSCHmedium access controlMedium Access Control (MAC) layer [IEEE802154]. We use "802.15.4" as a short version of "IEEE Std 802.15.4" in this document. . | . | | higher layers | +------------------------------------------+ | 6top | +------------------------------------------+ | IEEE Std 802.15.4 TSCH | | . | . Figure 2:The6topsublayerin theprotocol stack.Protocol Stack The roles ofthe6topsublayerare to: o Terminatethe 6top Protocol (6P),6P, which allows neighbor nodes to communicate to add/delete cellstoto/on one another. o Run one or multiple 6topScheduling Functions (SFs),SFs, which define the rules that decide when to add/delete cells. 2.1. Hard/Soft Cells Each cell in the schedule is either "hard" or "soft": oaA soft cell can be read, added,deleteddeleted, or updated by 6top. oaA hard cell is read-only for 6top. In the context of this specification, all the cells used by 6top are soft cells. Hard cells can beusedused, forexampleexample, when "hard-coding" a schedule [RFC8180]. 2.2. Using 6P with the Minimal 6TiSCH Configuration 6P MAY be used alongside theMinimalminimal 6TiSCHConfigurationconfiguration [RFC8180]. In this case, it is RECOMMENDED to use2two slotframes, as depicted in Figure 3: o Slotframe 0 is used for traffic defined in theMinimalminimal 6TiSCHConfiguration.configuration. In Figure 3, Slotframe 0 is5five slots long, but it can be shorter or longer. o 6P allocates cells from Slotframe 1. In Figure 3, Slotframe 1 is 10 slots long, but it can be shorter or longer. | 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 structure2-Slotframe Structure whenusingUsing 6P alongside the Minimal 6TiSCHConfiguration.Configuration TheMinimalminimal 6TiSCHConfigurationconfiguration 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 theMinimalminimal 6TiSCHConfiguration.configuration. 6top MAY support additional slotframes; how to use additional slotframes is out of scope for this document. 3. 6top Protocol (6P)The 6top Protocol (6P)6P enables two neighbor nodes toadd/delete/ relocateadd/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. 3.1. 6P Transactions 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)havehas been added/deleted/ relocated in the schedule of bothnodes,nodes orwhen(2) the 6P Transaction has failed. 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. 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 nodeB,B but node B does not have the corresponding reception cell. To verify consistency, neighbor nodes maintain aSequence Numbersequence 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. An implementation MUST include a mechanism to associate each scheduled cell with the SF that scheduled it. This mechanism isimplementation-specificimplementation specific and is out of scopeoffor this document. A 6P Transaction can consist of2two or3three 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. We illustrate 2-step and 3-step transactions using the topology in Figure 1. 3.1.1.2-step2-Step 6P Transaction 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 tosimplify understanding.understand. +----------+ +----------+ | 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: Anexample 2-stepExample 2-Step 6PTransaction.Transaction In this example, the 2-step transaction occurs as follows: 1. The SF running on node A determines that2two extra cells need to be scheduled to node B. 2. The SF running on node A selects candidate cells for node B to choose from. Node A MUST select at least as many candidate cells as the number of cells to add. Here, node A selects3three candidate cells. Node A locks those candidate cells in its schedule until it receives a 6Presponse.Response. 3. Node A sends a 6P ADD Request to node B, indicating that it wishes to add2two cells (the "NumCells"value),value) and specifying the list of3three 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). 4. After having successfully sent the 6P ADD Request(i.e.(i.e., receiving the link-layer acknowledgment), node A starts a 6P Timeout to abort the 6P Transaction incasethe event that no response is received from node B. 5. The SF running on node B selects2two out of the3three cells from the CellList of the 6P ADD Request. Node B locks those cells in its schedule until the transmission is successful(i.e.(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. 6. Upon completion of this 6P Transaction,2two cells from node A to node B have been added to the TSCH schedule of both nodes A and B. 7. An inconsistency in the schedule can happen if the 6P Timeout expires when the 6P Response is in the air, if the lastlink- layerlink-layer ACK for the 6P Response is lost, or if one of the nodes ispower cycledpower-cycled during the transaction. 6P provides an inconsistency detection mechanismdescribed in Section 3.4.6.1to cope with suchsituations.situations; see Section 3.4.6.2 for details. 3.1.2.3-step3-Step 6P Transaction 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 tosimplify understanding.understand. +----------+ +----------+ | 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: Anexample 3-stepExample 3-Step 6PTransaction.Transaction In this example, the 3-step transaction occurs as follows: 1. The SF running on node A determines that2two extra cells need to be scheduled to node B. The SF uses a 3-step transaction, so it does not select candidate cells. 2. Node A sends a 6P ADD Request to node B, indicating that it wishes to add2two cells (the "NumCells" value), with an empty "CellList". This 6P ADD Request is link-layer acknowledged by node B. 3. After having successfully sent the 6P ADD Request, node A starts a 6P Timeout to abort the transaction incasethe event that no 6P Response is received from node B. 4. The SF running on node B selects3three candidatecells,cells and locks them. Node B sends back a 6P Response to node A, indicating the3three cells it has selected. The response is link-layer acknowledged by node A. 5. After having successfully sent the 6P Response, node B starts a 6P Timeout to abort the transaction incasethe event that no 6P Confirmation is received from node A. 6. The SF running on node A selects2two cells from the CellList field in the 6PResponse,Response and locksthose.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. 7. Upon completion of the 6P Transaction,2two cells from node A to node B have been added to the TSCH schedule of both nodes A and B. 8. An inconsistency in the schedule can happen if the 6P Timeout expires when the 6P Confirmation is in the air, if the lastlink- layerlink-layer ACK for the 6P Confirmation is lost, or if one of the nodes ispower cycledpower-cycled during the transaction. 6P provides an inconsistency detection mechanismdescribed in Section 3.4.6.1to cope with suchsituations.situations; see Section 3.4.6.2 for details. 3.2. Message Format 3.2.1. 6top Information Element (IE) 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 IEHeader.header. The Group ID is set to the IETF IE value defined in [RFC8137]. The content is encapsulated by aSubTypesubtype ID, as defined in [RFC8137]. Since 6P messages are carried in IEs, IEEE bit/byte ordering applies. Bits within each field in the6top IE"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 thelowest numberedlowest-numbered bits to the octet containing thehighest numberedhighest-numbered bits (little endian). This document defines the"6top IE",6top IE, aSubTypesubtype of the IETF IE defined in [RFC8137], with subtypeID IANA_6TOP_SUBIE_ID.SUBID_6TOP. TheSubType Contentsubtype content of the"6top IE"6top IE is defined in Section 3.2.2. The length of the"6top IE"6top IE content is variable. 3.2.2. Generic 6P Message Format All 6P messages follow the generic format shown in Figure 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 MessageFormat.Format 6P Version (Version): The version ofthe 6P protocol.6P. Only version 0 is defined in this document. Future specifications may definefurthersubsequent versions ofthe 6P protocol.6P. Type (T):TypeThe type of message. The message types are defined in Section 6.2.2. Reserved (R): Reserved bits. These two bits SHOULD be set to zero when sending themessage,message and MUST be ignored upon reception. Code: The Code field contains a 6PCommand Identifiercommand identifier when the 6P messageis ofhas 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 messageis ofhas 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. 6top Scheduling Function Identifier (SFID): The identifier of the SF to use to handle this message. The SFID is defined in Section 4.1. SeqNum:SequenceThe sequence number associated with the 6PTransaction, usedTransaction. Used to match the 6P Request, 6PResponseResponse, and 6P Confirmation of the same 6P Transaction. The value of SeqNum MUST be differentatfor 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. Other Fields: The list of other fields and how they are usedisare detailed in Section 3.3. 6PRequests,Request, 6PResponseResponse, and 6P Confirmation messages for asamegiven transaction MUST share the same Version,SFIDSFID, and SeqNum values. Future versions of the 6PMessagemessage SHOULD maintain the format of the 6P Version,TypeType, and Code fields for backward compatibility. 3.2.3. 6P CellOptions An 8-bit 6P CellOptions bitmap is present in the following 6Prequests: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. o In the 6P ADDrequest,Request, the 6P CellOptions bitmap is used to specify what type of cell to add. o In the 6P DELETErequest,Request, the 6P CellOptions bitmap is used to specify what type of cell to delete. o In the 6P RELOCATErequest,Request, the 6P CellOptions bitmap is used to specify what type of cell to relocate. o In the 6P COUNT andthe 6PLISTrequests,Requests, the 6P CellOptions bitmap is used as a selector of a particular type of cells. The content of the 6P CellOptions bitmap applies to all elements in the CellList field. The possible values of the 6P CellOptionsare:are as follows: o TX = 1 (resp. 0) refers to macTxType = TRUE (resp. FALSE) in the macLinkTable of 802.15.4 [IEEE802154]. o RX = 1 (resp. 0) refers to macRxType = TRUE (resp. FALSE) in the macLinkTable of 802.15.4. o S = 1 (resp. 0) refers to macSharedType = TRUE (resp. FALSE) in the macLinkTable of 802.15.4. Section 6.2.6containsprovides the format of the 6P CellOptionsbitmap,bitmap; this format applies unless redefined by the SF. Figure 7containsshows the meaning of the 6P CellOptions bitmap for the 6P ADD, DELETE, and RELOCATErequests, unlessRequests (unless redefined by theSF.SF). Figure 8containsshows the meaning of the 6P CellOptions bitmap for the 6PCOUNT,COUNT and LISTrequests, unlessRequests (unless redefined by theSF.SF). Note:assumingHere, 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 fromA.A | +-------------+-----------------------------------------------------+ |TX=0,RX=0,S=0| Invalid combination. RC_ERR isreturned.returned | +-------------+-----------------------------------------------------+ |TX=1,RX=0,S=0|add/delete/relocateAdd/delete/relocate RX cells at B (TX cells at A) | +-------------+-----------------------------------------------------+ |TX=0,RX=1,S=0|add/delete/relocateAdd/delete/relocate TX cells at B (RX cells at A) | +-------------+-----------------------------------------------------+ |TX=1,RX=1,S=0|add/delete/relocateAdd/delete/relocate TX|RX cells at B (and at A) | +-------------+-----------------------------------------------------+ |TX=0,RX=0,S=1| Invalid combination. RC_ERR isreturned.returned | +-------------+-----------------------------------------------------+ |TX=1,RX=0,S=1|add/delete/relocateAdd/delete/relocate RX|SHARED cells at B | | | (TX|SHARED cells at A) | +-------------+-----------------------------------------------------+ |TX=0,RX=1,S=1|add/delete/relocateAdd/delete/relocate TX|SHARED cells at B | | | (RX|SHARED cells at A) | +-------------+-----------------------------------------------------+ |TX=1,RX=1,S=1|add/delete/relocateAdd/delete/relocate TX|RX|SHARED cells at B | | | (and at A) | +-------------+-----------------------------------------------------+ Figure 7: Meaning of the 6P CellOptionsbitmapBitmap for the 6P ADD, DELETE, and RELOCATErequests.Requests Note:assumingHere, 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|allAll cells | +-------------+-----------------------------------------------------+ |TX=1,RX=0,S=0|allAll cells marked as RX only | +-------------+-----------------------------------------------------+ |TX=0,RX=1,S=0|allAll cells marked as TX only | +-------------+-----------------------------------------------------+ |TX=1,RX=1,S=0|allAll cells marked as TX and RX only | +-------------+-----------------------------------------------------+ |TX=0,RX=0,S=1|allAll cells marked as SHARED (regardless of TX, RX) | +-------------+-----------------------------------------------------+ |TX=1,RX=0,S=1|allAll cells marked as RX and SHARED only | +-------------+-----------------------------------------------------+ |TX=0,RX=1,S=1|allAll cells marked as TX and SHARED only | +-------------+-----------------------------------------------------+ |TX=1,RX=1,S=1|allAll cells marked asTX and RXTX, RX, and SHARED | +-------------+-----------------------------------------------------+ Figure 8: Meaning of the 6P CellOptionsbitmapBitmap for the 6PCOUNT,COUNT and LISTrequests.Requests The CellOptionsisconstitute an opaque set of bits, sent unmodified to the SF. The SF MAY redefine the format and meaning of the CellOptions field. 3.2.4. 6P CellList 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 ofzero, onezero 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. A 6P Cell is a 4-bytefield,field; its default format is: 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 CellFormat.Format slotOffset: The slot offset of the cell. channelOffset: The channel offset of the cell. The CellList is an opaque set of bytes, sent unmodified to the SF. The length of the CellList field isimplicit,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. 3.3. 6P Commands and Operations 3.3.1. Adding Cells 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. 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 RequestFormat.Format Metadata: Used as extra signaling to the SF. The contents of the Metadata fieldisare an opaque set of bytes passed unmodified to the SF. The meaning of this field depends on theSF,SF and is out of scopeoffor this document. For example, Metadata can specify in which slotframe to add the cells. CellOptions: Indicates the options to associate with the cells to be added. If more than one cell is added(NumCells>1),(NumCells > 1), the same options are associated with each one. This necessarily meansthat,that if node A needs to add multiple cells with differentoptions,options it needs to initiate multiple 6P ADD Transactions. NumCells: The number of additional cells node A wants to schedule to node B. CellList: A list of0zero or multiple candidate cells. Its length is implicit and is determined by the Length field of the Payload IE header. Figure 11 defines the format of a 6P ADD Response and Confirmation. 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 ConfirmationFormats.Format CellList: A list of0zero or more 6P Cells. Consider the topology in Figure1 where1; in this case, the SF on node A decides to add NumCells cells to node 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 belargergreater than or equal to NumCells. How many cells node A selects (NumCandidate) and how that selection is doneisare specified in the SF and are out of scopeoffor this document. Node A sends a 6P ADD Request to node Bwhichthat contains the CellOptions, the value of NumCells, and a selection of NumCandidate cells in the CellList.In caseIf 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 returnedcandidateCandidate CellList fits into the 6P Response. Upon receiving the request, node B checks to see whether thecellOptionsCellOptions 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,Nodenode 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 scopeoffor 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 Responsewiththat includes a return code set toRC_SUCCESS,RC_SUCCESS andwhichthat 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). Upon receiving the response, node A adds the cells specified in the CellList according to the CellOptions field. 3.3.2. Deleting Cells 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. 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 RequestFormat.Format Metadata: Same usage as for the 6P ADDcommand,command; see Section 3.3.1. Its format is the same as that in the 6P ADD command, but its content could be different. CellOptions: Indicates the options that need to be associatedtowith the cells to delete. Only cells matching the CellOptions canarebe deleted. NumCells: The number of cells from the specified CellList the sender wants to delete from the schedule of both sender and receiver. CellList: A list of0zero or more 6P Cells. Its length is determined by the Length field of the Payload IE header. Figure 13 defines the format of a 6P DELETE Response and Confirmation. 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 ConfirmationFormats.Format CellList: A list of0zero or more 6P Cells. 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 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 The CellList in a 6P Request (2-step transaction) or 6P Response (3-step transaction) MUSTeitherbe 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 notsupported.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 nodeSHOULDMUST choose NumCells cellswithscheduled to the senderfrom its schedule, which matchmatching theCellOption field,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. 3.3.3. Relocating Cells Cell relocation consistsinof 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. 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 RequestFormat.Format Metadata: Same usage as for the 6P ADDcommand,command; see Section 3.3.1. CellOptions: Indicates the options that need to be associated with cells to be relocated. NumCells: The number of cells torelocate, whichrelocate. MUST beequal orgreater than or equal to 1. Relocation CellList: The list of NumCells 6P Cells to relocate. 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. In a 2-step 6P RELOCATE Transaction, node A specifies both (1) the cells it needs torelocate,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).(NumCandidate >= NumCells). In a 3-step 6P RELOCATE Transaction, node A specifies only the cells it needs torelocate, butrelocate -- not the list of candidate cells to relocate to. The Candidate CellList MUST therefore be empty. Figure 15 defines the format of a 6P RELOCATE Response and Confirmation. 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 ConfirmationFormats.Format CellList: A list of0zero or more 6P Cells. Node A's SF wants to relocate NumCells cells. Node A creates a 6P RELOCATERequest,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 putsthosethem in the Candidate CellList. The CellOptions field specifies the type of the cell(s) to relocate. NumCandidate MUST belargergreater than or equal to NumCells. How many cells it selects (NumCandidate) and how that selection is doneisare specified in the SF and are out of scopeoffor this document. Node A sends the 6P RELOCATE Request to node B. Upon receiving the request,Nodenode B checks to see if the length of the Candidate CellList islargergreater than or equal to NumCells. Node B's SF verifies that all the cells in the Relocation CellList are scheduled with nodeA,A and areassociateassociated 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 scopeoffor this document. That verificationonfor the Candidate CellList can succeed (NumCells cells from the Candidate CellList can be used), fail (none of the cells from the Candidate CellList can beused)used), or partially succeed (fewer than NumCells cells from the Candidate CellList can be used). In all cases, node B MUST send a 6P Responsewiththat includes a return code set toRC_SUCCESS,RC_SUCCESS andwhichthat specifies the list of cells that will bere- scheduledrescheduled 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 beenrelocated,relocated and the remainder have not. Upon receiving the response withCodecode 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.In caseIf 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,Nodenode B relocates the selected cells upon receiving the link-layer ACK for the 6P Response. In the case of a 3-step transaction,Nodenode B relocates the selected cells upon receiving the 6P Confirmation. The SF SHOULD NOT relocate all cells between two nodes at the same time,whichas this might result in the schedules of both nodes diverging significantly. Figure 16 shows an example of a successful 2-step 6PRELOCATIONRELOCATE Transaction. +----------+ +----------+ | 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)] | Arelocates|<--------------------------------------| (1,2)->(5,3)|relocates |<--------------------------------------| (1,2)->(5,3) | L2 ACK | and | - - - - - - - - - - - - - - - - - -->|B->| B relocates(2,2)->(3,3)| |(1,2)->(5,3)(2,2)->(3,3) | | (1,2)->(5,3) | | and ||and||(2,2)->(3,3)(2,2)->(3,3) Figure 16: Example of asuccessful 2-stepSuccessful 2-Step 6PRELOCATION Transaction.RELOCATE Transaction Figure 17 shows an example of a partially successful 2-step 6PRELOCATIONRELOCATE Transaction. +----------+ +----------+ | 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| B prepares|-------------------------------------->|to|-------------------------------------->| to relocate | L2 ACK|(1,2)->(4,3)| (1,2)->(4,3) |<- - - - - - - - - - - - - - - - - - -|but| but cannot ||relocate| relocate (2,2) | 6P Response | | Type = RESPONSE | | Code = RC_SUCCESS | | SeqNum = 199 | | CellList = [(4,3)] | A relocates |<--------------------------------------|(1,2)->(4,3)|(1,2)->(4,3) | L2 ACK | | - - - - - - - - - - - - - - - - - -->|B->| B relocates ||(1,2)->(4,3)| (1,2)->(4,3) | | | | Figure 17: Example of apartially successful 2-stepPartially Successful 2-Step 6PRELOCATION Transaction.RELOCATE Transaction Figure 18 shows an example of a failed 2-step 6PRELOCATIONRELOCATE Transaction. +----------+ +----------+ | 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) | |noror (2,2) | 6P Response | | Type = RESPONSE | | Code = RC_SUCCESS | | SeqNum = 53 | | CellList = [] | |<--------------------------------------| B does not | L2 ACK | relocate A does not | - - - - - - - - - - - - - - - - - - ->| relocate | | | | Figure 18: Failed2-step2-Step 6PRELOCATIONRELOCATE TransactionExample.Example Figure 19 shows an example of a successful 3-step 6PRELOCATIONRELOCATE Transaction. +----------+ +----------+ | 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)(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)|(1,2)->(5,3) | | (2,2)->(3,3) and | |(2,2)->(3,3)|(2,2)->(3,3) | | | | Figure 19: Example of asuccessful 3-stepSuccessful 3-Step 6PRELOCATION Transaction.RELOCATE Transaction 3.3.4. Counting Cells 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. 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 RequestFormat.Format Metadata: Same usage as for the 6P ADDcommand,command; see Section 3.3.1. Its format is the same as that in the 6P ADD command, but its content could be different. CellOptions: Specifies which type of cell to be counted. Figure 21 defines the format of a 6P COUNT Response. 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 ResponseFormat.Format NumCells: The number of cellswhichthat correspond to the fields of the request. Node A issues a COUNT command to node B, specifying some cell options. Upon receiving the 6P COUNTrequest,Request, node B goes through its schedule and counts the number of cells scheduled with node A in its own schedulewhichthat match the cell options in the CellOptions field of the request. Section 3.2.3 details the use of the CellOptions field. Node B issues a 6PresponseResponse to node A with return codeset to RC_SUCCESS,RC_SUCCESS and with NumCells containing the number of cells that match the request. 3.3.5. Listing Cells 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. 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 RequestFormat.Format Metadata: Same usage as for the 6P ADDcommand,command; see Section 3.3.1. Its format is the same as that in the 6P ADD command, but its content could be different. CellOptions: Specifies which type of cell to be listed. Reserved: Reserved bits. These bits SHOULD be set to zero when sending themessage,message and MUST be ignored upon reception. Offset: TheOffsetoffset 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. MaxNumCells: The maximum number of cells to be listed. Node B MAY return fewer than MaxNumCellscells,cells -- forexampleexample, if MaxNumCells cells do not fit in the frame. Figure 23 defines the format of a 6P LIST Response. 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 ResponseFormat.Format CellList: A list of0zero or more 6P Cells. 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. When node B receives a LISTrequest,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,Nodenode B MUST set the Code field in the response to RC_EOL ("End of List", as per Figure38),38 in Section 6.2.4), indicating toNodenode A that there are no more cells that match the request. Node B MUST return at least one cell, unless the specifiedOffsetoffset 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. 3.3.6. Clearing the Schedule To clear the schedule between nodes A and B (forexampleexample, after a schedule inconsistency is detected), node A issues a CLEAR command. The Type field (T) is set to6P Request.REQUEST. The Code field is set to CLEAR. Figure 24 defines the format of a 6P CLEAR Request. 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 RequestFormat.Format Metadata: Same usage as for the 6P ADDcommand,command; see Section 3.3.1. Its format is the same as that in the 6P ADD command, but its content could be different. Figure 25 defines the format of a 6P CLEAR Response. 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 ResponseFormat.Format 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. 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. 3.3.7. Generic SignalingBetweenbetween SFs 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 determinedthroughby thelengthLength field of the Payload IEHeader.header. How the generic SIGNAL command is used is specified by theSF,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. 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 RequestFormat.Format Metadata: Same usage as for the 6P ADDcommand,command; see Section 3.3.1. Its format is the same as that in the 6P ADD command, but its content could be different. Figure 27 defines the format of a 6P SIGNAL Response. 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 ResponseFormat.Format 3.4. Protocol Functional Details 3.4.1. Version Checking All messages contain a Version field. If multipleVersionsprotocol versions ofthe6Pprotocolhave 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 aVersionversion 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 withVersionversion 0 and MUST be supported by all future versions of the protocol. This ensuresthat,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. 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. 3.4.2. SFID Checking 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. 3.4.3. Concurrent 6P Transactions Only a single 6P Transactionbetween two neighbors,at a time in a givendirection,direction can take placeat the same time.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(possibly(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 Figure38)38 in Section 6.2.4) and discard this ongoing second transaction. A node receiving a RC_RESET code MUST abort the second transaction andconsidertreat it as though it never happened(i.e.(i.e., reverting changes to the schedule or SeqNum done by this transaction). 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.In caseIf a node does not have enough resources to handle concurrent 6P Transactions from differentneighborsneighbors, it MUST reply with a 6P Response with return code RC_ERR_BUSY (as per Figure38). In case38 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 oraRC_ERR_LOCKED MAY implement a retrymechanism,mechanism as defined by the SF. 3.4.4. 6P Timeout 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 belargergreater 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 scopeoffor this document. 3.4.5. Aborting a 6P TransactionIn caseIf the receiver of a 6P Request fails during a 6P Transaction and is unable to complete it, it SHOULD reply to thatRequestrequest 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. 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.4.6. SeqNum Management The SeqNum is the field in the 6top IE header used to match Request,ResponseResponse, andConfirmation.Confirmation messages for a given transaction. The SeqNum is used to detect and handle duplicate commands (Section 3.4.6.1) andschedule inconsistenciesinconsistent 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. When a noderesetsresets, or after a CLEARtransaction,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 theRequest.request. After every transaction, the SeqNum MUST be incremented by exactly 1. Specifically, if node A receives the link-layer acknowledgment for its 6P Request, itcommits to incrementingwill increment the SeqNum by exactly 1 after the 6P Transaction ends. Thisensureensures that,atfor the next 6P Transaction where it sends a 6P Request, the 6P Request will have a different SeqNum. Similarly,anode B increments the SeqNum by exactly 1 after having received the link-layer acknowledgment for the 6P Response (2-step 6PTransaction),Transaction) or after having sent the link-layer acknowledgment for the 6P Confirmation (3-step 6PTransaction) .Transaction). Whenanode 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. 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.+-----------+-----------------------------++-----------+------------------------------+ | Value | Meaning |+-----------+-----------------------------++-----------+------------------------------+ | 0x00 |ClearClear, orAfterafter deviceResetreset | | 0x01-0xFF | LollipopCountercounter values |+-----------+-----------------------------++-----------+------------------------------+ Figure 28: PossiblevaluesValues of theSeqNum.SeqNum 3.4.6.1. Detecting and Handling Duplicate 6P Messages All 6P commands are link-layer acknowledged. A duplicate message means that a node receives a second 6P Request,ResponseResponse, or Confirmation. This happens when the link-layer acknowledgment is notreceived,received and a link-layer retransmission happens. Duplicate messages are normal and unavoidable. Figure 29 shows an example 2-step transaction in whichNodenode A receives a duplicate 6P Response. +----------+ +----------+ | Node A | | Node B | +----+-----+ +-----+----+ | | | 6P Request (SeqNum=456) | |-------------------------------------->| | L2 ACK | |<- - - - - - - - - - - - - - - - - - - | | | | 6P Response (SeqNum=456) | |<--------------------------------------| | L2 ACK | | - - - - - - - - - - -X |Nono ACK: | | link-layer | 6P Response (SeqNum=456) | retransmit duplicate |<--------------------------------------| 6P Response | L2 ACK | received | - - - - - - - - - - - - - - - - - - ->| | | Figure 29: ExampleduplicateDuplicate 6Pmessage.Message Figure 30 shows an example 3-step transaction in whichNodenode A receivesaan out-of-order duplicate 6P Response after having sent a 6P Confirmation. +----------+ +----------+ | Node A | | Node B | +----+-----+ +-----+----+ | | | 6P Request (SeqNum=123) | |-------------------------------------->| | L2 ACK | |<- - - - - - - - - - - - - - - - - - - | | | | 6P Response (SeqNum=123) | |<--------------------------------------| | L2 ACK | | - - - - - - - - - - -X |Nono 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: Exampleout-of-order duplicateOut-of-Order Duplicate 6Pmessage.Message 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-layeracknowledgment,acknowledgment but MUST silently ignore the 6P message atthe 6top sublayer.6top. 3.4.6.2. Detecting and Handling a Schedule Inconsistency A schedule inconsistency happens when the schedules of nodes A and B areinconsistent. Forinconsistent -- for example, when node A has a transmit cell to node B, but node B does not have the corresponding receivecell,cell and therefore isn't listening to node A on that cell. A schedule inconsistency results in loss of connectivity. The SeqNum field, which is present in each 6P message, is used to detect an inconsistency. The SeqNum field increments by 1atin each message, as detailed in Section 3.4.6. A node computes the expected SeqNum field for the next 6P Transaction. If a node receives a 6P Request with a SeqNum value that is not the expectedone,value, it has detected an inconsistency. There areat least 2two cases in which a schedule inconsistency happens. The first case is when a node losesstate,state -- forexampleexample, when it ispower cycledpower-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 inconsistencyatin the next 6Ptransaction.Transaction. This is illustrated inFigureFigures 31 andFigure32. +----------+ +----------+ | 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 |Detecteddetected |<- - - - - - - - - - - - - - - - - - - | | | | 6P Response (SeqNum=0, RC_ERR_SEQNUM) | |<--------------------------------------| | L2 ACK | | - - - - - - - - - - - - - - - - - - ->| Figure 31: Example ofinconsistency because of nodeInconsistency Because Node Breset. DetectedResets (Detected bynode BNode 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|<--------------------------------------| DetectedInconsistency |<--------------------------------------| detected | L2 ACK | |- - - - - - - - - - - - - - - - - - - >| | | | 6P Response (SeqNum=0, RC_ERR_SEQNUM) | |-------------------------------------->| | L2 ACK | |<- - - - - - - - - - - - - - - - - - - | Figure 32: Example ofinconsistency because nodeInconsistency Because Node Bresets. DetectedResets (Detected bynode ANode 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(or, equivalently, on a 6P Confirmation of a 3-step transaction). This is illustrated in Figure 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 | | |maxmax. retrans.: | |Inconsistencyinconsistency | |Detecteddetected Figure 33: Exampleinconsistency becauseInconsistency Because ofmaximum link-layer retransmissions (here 2).Maximum Link-Layer Retransmissions (where Maximum = 2) In both cases, node B detects the inconsistency. 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). The SF of the nodewhichthat has detected the inconsistency MUST define how to handle the inconsistency.A first possibility isThree possible ways toissuedo this are as follows: o Issue a 6P CLEARrequestRequest to clear the schedule, and then rebuild.A second possibility is to issueo Issue a 6P LISTrequestRequest to retrieve the schedule.A third possibility is to internally "roll-back"o Internally "roll back" the schedule. How to handle an inconsistency is out of scopeoffor this document. The SF defines how to handle an inconsistency. 3.4.7. Handling Error Responses A return code marked as Yes in the "IsError"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,DELETEDELETE, or RELOCATE Request, the node MUST NOT add,deletedelete, 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 returncodecode, the 6P Transaction MUST be considered as having failed. In particular, in a3 step3-step 6P Transaction, when receiving a 6P Response withan unrecognizeda return code that it does not recognize, the requester (node A) MUSTbe responded withsend a 6P Confirmation to the responder (node B) with return code RC_ERR and consider the transactionasfailed. 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 scopeoffor this document. The SF defines what to do after an error has occurred. 3.5. Security 6P messages MUST be secured through link-layer security. This is possible because 6P messages are carried as Payload IEs. 4. Requirements for 6top SchedulingFunctionsFunction (SF)SpecificationSpecifications 4.1. SF Identifier (SFID) Each SF has a 1-byte identifier. Section 6.2.5 defines the rules for applying for an SFID. 4.2. Requirements for an SFspecificationSpecification The specification for an SF o MUST specify an identifier for that SF. o MUST specify the rule for a node to decide when to add/delete one or more cellstoto/on a neighbor. o MUST specify the rule for aTransactiontransaction source to select cells to add to the CellList field in the 6P ADD Request. o MUST specify the rule for aTransactiontransaction destination to select cells from the CellList to add to its schedule. o MUST specify a value for the 6PTimeout,Timeout or a rule/equation to calculate it. o MUST specify the rule for ordering cells. o MUST specify a meaning for the"Metadata"Metadata field in the 6P ADD Request. o MUST specify the SF behavior of a node when it boots. o MUST specify how to handle a schedule inconsistency. o MUST specify what to do after an error has occurred(either the(the node either sent a 6P Response with an errorcode,code or received one). o MUST specify the list of statistics to gather. Example statistics include the number of transmitted frames to each neighbor.In caseIf the SFrequires nodoes not require that statisticstobe gathered, thespecific of theSF specification MUST explicitlystatesay so. o SHOULD clearly state the application domain the SF is created for. o SHOULD contain exampleswhichthat highlight normal and error scenarios. o SHOULD contain a list of current implementations, at least during theI-DInternet-Draft (I-D) state of the document, per[RFC6982].[RFC7942]. o SHOULD contain a performance evaluation of the scheme, possibly through references to external documents. o SHOULD define the format of the SIGNAL command payload and its use. o MAY redefine the format of the CellList field. o MAY redefine the format of the CellOptions field. o MAY redefine the meaning of the CellOptions field. 5. Security Considerations 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-Star] ("CCM" stands for "Cipher block Chaining -- Message authentication code"). 6P benefits from the same level of security as any other Payload IE.The6Pprotocoldoes not define its own security mechanisms. In particular, although a key management solution is out of scopeoffor this document,the6Pprotocolwill benefitforfrom the key management solution used in the network. This isrelevantrelevant, as security attacks such as forgery and misattribution attacks become more damaging when a single key is shared amongst a group of more than2two participants.The6Pprotocoldoes not provide protection againstDOSDoS attacks. Example attacksinclude,include not sending confirmation messages in 3-steptransaction,transactions and sendingwronglyincorrectly 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 tothosethe twonodes,nodes in question, as communication happens in dedicated cells. 6. IANA Considerations 6.1. IETF IE Subtype'6P'6P This document adds the following number to the "IEEE Std 802.15.4 IETF IEsubtypeSubtype IDs" registry defined by [RFC8137]: +--------+------------+-----------+ | Value | Subtype ID | Reference | +--------+------------+-----------+ |<TBD>1 | SUBID_6TOP |RFCXXXXRFC 8480 | +---------------------+-----------+ Figure 34: IETF IE SubtypeSUBID_6TOP.SUBID_6TOP 6.2. 6TiSCHparameters sub-registriesParameters Subregistries This section definessub-registriessubregistries within the "IPv6overOver the TSCHmodeMode of IEEE 802.15.4e(6TiSCH) parameters"(6TiSCH)" parameters registry, hereafter referred to as the "6TiSCH parameters" registry. Eachsub-registrysubregistry is described in a subsection. 6.2.1. 6P Version Numbers The name of thesub-registrysubregistry is "6P Version Numbers".A NoteThe following note is included in thisregistry should say:registry: "In the 6top Protocol (6P)[RFCXXXX][RFC8480], there is a field to identify the version of the protocol. This field is 4 bits in size." Each entry in thesub-registrysubregistry must include theVersionversion in the range0-15,0-15 and a reference to the 6P version's documentation. The initial entry in thissub-registrysubregistry is as follows: +---------+-----------+ | Version | Reference | +---------+-----------+ | 0 |RFCXXXXRFC 8480 | +---------+-----------+ Figure 35: 6P VersionNumbers.Number Entry All otherVersion Numbersversion numbers are Unassigned. The IANA policy for future additions to thissub-registrysubregistry is "IETFReviewReview" orIESG"IESG Approval" as described in [RFC8126]. 6.2.2. 6P Message Types The name of thesub-registrysubregistry is "6P Message Types".AThe following note is included in thisregistry should say:registry: "In version 0 of the 6top Protocol (6P)version 0 [RFCXXXX],[RFC8480], there is a field to identify the type of message. This field is 2 bits in size." Each entry in thesub-registrysubregistry must include theTypemessage type in the range b00-b11, the correspondingName,name, and a reference to the 6P message type's documentation. Initial entries in thissub-registrysubregistry are as follows: +------+--------------+-----------+ | Type | Name | Reference | +------+--------------+-----------+ | b00 | REQUEST |RFCXXXXRFC 8480 | | b01 | RESPONSE |RFCXXXXRFC 8480 | | b10 | CONFIRMATION |RFCXXXXRFC 8480 | +------+--------------+-----------+ Figure 36: 6P MessageTypes.Types All otherMessage Typesmessage types areReserved.Unassigned. The IANA policy for future additions to thissub-registrysubregistry is "IETFReviewReview" orIESG"IESG Approval" as described in [RFC8126]. 6.2.3. 6P Command Identifiers The name of thesub-registrysubregistry is "6P Command Identifiers".A NoteThe following note is included in thisregistry should say:registry: "In version 0 of the 6top Protocol (6P)version 0 [RFCXXXX],[RFC8480], there is a Code fieldwhichthat is 8 bits in size. In a 6P Request, the value of this Code field is used to identify the command." Each entry in thesub-registrysubregistry must include anIdentifieridentifier in the range 0-255, the correspondingName,name, and a reference to the 6P command identifier's documentation. Initial entries in thissub-registrysubregistry are as follows: +------------+------------+-----------+ | Identifier | Name | Reference | +------------+------------+-----------+ | 0 | Reserved | RFC 8480 | | 1 | ADD |RFCXXXXRFC 8480 | | 2 | DELETE |RFCXXXXRFC 8480 | | 3 | RELOCATE |RFCXXXXRFC 8480 | | 4 | COUNT |RFCXXXXRFC 8480 | | 5 | LIST |RFCXXXXRFC 8480 | | 6 | SIGNAL |RFCXXXXRFC 8480 | | 7 | CLEAR |RFCXXXXRFC 8480 | | 8-254 | Unassigned | | | 255 | Reserved | RFC 8480 | +------------+------------+-----------+ Figure 37: 6P CommandIdentifiers.Identifiers The IANA policy for future additions to thissub-registrysubregistry is "IETFReviewReview" orIESG"IESG Approval" as described in [RFC8126]. 6.2.4. 6P Return Codes The name of thesub-registrysubregistry is "6P Return Codes".A NoteThe following note is included in thisregistry should say:registry: "In version 0 of the 6top Protocol (6P)version 0 [RFCXXXX],[RFC8480], there is a Code fieldwhichthat 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." Each entry in thesub-registrysubregistry must include aCodereturn code in the range 0-255, the correspondingName,name, the correspondingDescription,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. Initial entries in thissub-registrysubregistry 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 ReturnCodes.Codes All otherMessage Typesmessage types are Unassigned. The IANA policy for future additions to thissub-registrysubregistry is "IETFReviewReview" orIESG"IESG Approval" as described in [RFC8126]. 6.2.5. 6P Scheduling Function Identifiers6PThe name of the subregistry is "6P Scheduling FunctionIdentifiers. A NoteIdentifiers". The following note is included in thisregistry should say:registry: "In version 0 of the 6top Protocol (6P)version 0 [RFCXXXX],[RFC8480], there is a field to identify thescheduling functionScheduling Function to handle the message. This field is 8 bits in size." Each entry in thesub-registrysubregistry must include an SFID in the range 0-255, the correspondingName,name, and a reference to the 6P Scheduling Function's documentation.InitialThere are currently no entries in thissub-registry are as follows: +----+---------------------------------+----------------------------+ |SFID| Name | Reference | +----+---------------------------------+----------------------------+ | 0subregistry. +------+---------------------------------+--------------------------+ |Minimal Scheduling FunctionSFID |draft-chang-6tisch-msfName | Reference | +------+---------------------------------+--------------------------+ |(MSF)0-255| Unassigned | |+----+---------------------------------+----------------------------++------+---------------------------------+--------------------------+ Figure 39: SFIdentifiers (SFID).Identifier (SFID) Entry Allother Message Typesmessage types are Unassigned. The IANA policy for future additions to thissub-registrysubregistry depends on the value of the SFID, asdefinedshown in Figure 40. These specifications must follow the guidelines of Section 4. +-----------+------------------------------+ | Range | Registration Procedures | +-----------+------------------------------+ | 0-127 | IETF Review or IESG Approval | | 128-255 | Expert Review | +-----------+------------------------------+ Figure 40: SF Identifier (SFID): RegistrationProcedure.Procedure 6.2.6. 6P CellOptionsbitmapBitmap The name of thesub-registrysubregistry is "6P CellOptionsbitmap". A NoteBitmap". The following note is included in thisregistry should say:registry: "In version 0 of the 6top Protocol (6P)version 0 [RFCXXXX],[RFC8480], there is an optional CellOptions fieldwhichthat is 8 bits in size." Each entry in thesub-registrysubregistry must include a bit position in the range 0-7, the correspondingName,name, and a reference to the bit's documentation. Initial entries in thissub-registrysubregistry are as follows: +-----+---------------+-----------+ | bit | Name | Reference | +-----+---------------+-----------+ | 0 | TX (Transmit) |RFCXXXXRFC 8480 | | 1 | RX (Receive) |RFCXXXXRFC 8480 | | 2 | SHARED |RFCXXXXRFC 8480 | | 3-7 | Reserved | | +-----+---------------+-----------+ Figure 41: 6P CellOptionsbitmap.Bitmap All otherMessage Typesmessage types areReserved.Unassigned. The IANA policy for future additions to thissub-registrysubregistry is "IETFReviewReview" orIESG"IESG Approval" as described in [RFC8126]. 7. References 7.1. Normative References [IEEE802154]IEEE standard for Information Technology,IEEE, "IEEEStd 802.15.4-2015 - IEEEStandard for Low-Rate WirelessPersonal Area Networks (WPANs)", October 2015.Networks", 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>. [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>. [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>. 7.2. Informative References [CCM-Star] Struik, R., "Formal Specification of the CCM* Mode ofOperation,Operation", IEEEP802.15 Working Group for Wireless Personal Area Networks (WPANs).",P802.15-4/0537r2, September 2005.[OpenWSN] Watteyne, T., Vilajosana, X., Kerkez, B., Chraim, F., Weekly, K., Wang, Q., Glaser, S., and K. Pister, "OpenWSN: a Standards-Based Low-Power Wireless Development Environment", Transactions on Emerging Telecommunications Technologies , August 2012. [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", RFC 6982, DOI 10.17487/RFC6982, July 2013, <https://www.rfc-editor.org/info/rfc6982>.[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>. [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>. [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>. [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>. Appendix A. Recommended Structure of an SF Specification The following section structure foraan SF document is RECOMMENDED: o Introduction o RFC 2119 Requirements Language (if applicable) o Scheduling Function Identifier o Rules for Adding/Deleting Cells o Rules for CellList o 6P Timeout Value o Rule for Ordering Cells o Meaning of the Metadata Field o Node Behavior at Boot o Schedule Inconsistency Handling o 6P Error Handling o Examples o Implementation Status o Security Considerations o IANA Considerations o Normative References (if applicable) o Informative References (if applicable) Authors' Addresses Qin Wang (editor) Univ. of Sci. and Tech. Beijing 30 Xueyuan Road Beijing, Hebei 100083 China Email: wangqin@ies.ustb.edu.cn Xavier Vilajosana Universitat Oberta de Catalunya 156 Rambla Poblenou Barcelona, Catalonia 08018 Spain Email: xvilajosana@uoc.edu Thomas Watteyne Analog Devices 32990 Alvarado-Niles Road, Suite 910 Union City, CA 94587USAUnited States of America Email: thomas.watteyne@analog.com