idnits 2.17.1 draft-ietf-6tisch-6top-protocol-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 30, 2018) is 2218 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCXXXX' is mentioned on line 1767, but not defined == Unused Reference: 'OpenWSN' is defined on line 1817, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802154' ** Downref: Normative reference to an Informational RFC: RFC 8137 -- Obsolete informational reference (is this intentional?): RFC 6982 (Obsoleted by RFC 7942) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6TiSCH Q. Wang, Ed. 3 Internet-Draft Univ. of Sci. and Tech. Beijing 4 Intended status: Standards Track X. Vilajosana 5 Expires: October 1, 2018 Universitat Oberta de Catalunya 6 T. Watteyne 7 Analog Devices 8 March 30, 2018 10 6top Protocol (6P) 11 draft-ietf-6tisch-6top-protocol-11 13 Abstract 15 This document defines the 6top Protocol (6P), which enables 16 distributed scheduling in 6TiSCH networks. 6P allows neighbor nodes 17 to add/delete TSCH cells to one another. 6P is part of the 6TiSCH 18 Operation Sublayer (6top), the next higher layer to the IEEE Std 19 802.15.4 TSCH medium access control layer. The 6top layer terminates 20 the 6top Protocol defined in this document, and runs one of more 6top 21 Scheduling Function(s). A 6top Scheduling Function (SF) decides when 22 to add/delete cells, and triggers 6P Transactions. This document 23 lists the requirements for an SF, but leaves the definition of SFs 24 out of scope. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 30 "OPTIONAL" in this document are to be interpreted as described in RFC 31 2119 [RFC2119]. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on October 1, 2018. 50 Copyright Notice 52 Copyright (c) 2018 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. 6TiSCH Operation Sublayer (6top) . . . . . . . . . . . . . . 4 69 2.1. Hard/Soft Cells . . . . . . . . . . . . . . . . . . . . . 5 70 2.2. Using 6P with the Minimal 6TiSCH Configuration . . . . . 5 71 3. 6top Protocol (6P) . . . . . . . . . . . . . . . . . . . . . 6 72 3.1. 6P Transactions . . . . . . . . . . . . . . . . . . . . . 6 73 3.1.1. 2-step 6P Transaction . . . . . . . . . . . . . . . . 7 74 3.1.2. 3-step 6P Transaction . . . . . . . . . . . . . . . . 9 75 3.2. Message Format . . . . . . . . . . . . . . . . . . . . . 11 76 3.2.1. 6top Information Element (IE) . . . . . . . . . . . . 11 77 3.2.2. Generic 6P Message Format . . . . . . . . . . . . . . 11 78 3.2.3. 6P CellOptions . . . . . . . . . . . . . . . . . . . 12 79 3.2.4. 6P CellList . . . . . . . . . . . . . . . . . . . . . 14 80 3.3. 6P Commands and Operations . . . . . . . . . . . . . . . 15 81 3.3.1. Adding Cells . . . . . . . . . . . . . . . . . . . . 15 82 3.3.2. Deleting Cells . . . . . . . . . . . . . . . . . . . 17 83 3.3.3. Relocating Cells . . . . . . . . . . . . . . . . . . 18 84 3.3.4. Counting Cells . . . . . . . . . . . . . . . . . . . 24 85 3.3.5. Listing Cells . . . . . . . . . . . . . . . . . . . . 25 86 3.3.6. Clearing the Schedule . . . . . . . . . . . . . . . . 27 87 3.3.7. Generic Signaling Between SFs . . . . . . . . . . . . 28 88 3.4. Protocol Functional Details . . . . . . . . . . . . . . . 28 89 3.4.1. Version Checking . . . . . . . . . . . . . . . . . . 28 90 3.4.2. SFID Checking . . . . . . . . . . . . . . . . . . . . 29 91 3.4.3. Concurrent 6P Transactions . . . . . . . . . . . . . 29 92 3.4.4. 6P Timeout . . . . . . . . . . . . . . . . . . . . . 30 93 3.4.5. Aborting a 6P Transaction . . . . . . . . . . . . . . 30 94 3.4.6. SeqNum Management . . . . . . . . . . . . . . . . . . 30 95 3.4.7. Handling Error Responses . . . . . . . . . . . . . . 36 96 3.5. Security . . . . . . . . . . . . . . . . . . . . . . . . 36 97 4. Requirements for 6top Scheduling Functions (SF) . . . . . . . 36 98 4.1. SF Identifier (SFID) . . . . . . . . . . . . . . . . . . 36 99 4.2. Requirements for an SF . . . . . . . . . . . . . . . . . 36 100 5. Security Considerations . . . . . . . . . . . . . . . . . . . 37 101 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 102 6.1. IETF IE Subtype '6P' . . . . . . . . . . . . . . . . . . 37 103 6.2. 6TiSCH parameters sub-registries . . . . . . . . . . . . 38 104 6.2.1. 6P Version Numbers . . . . . . . . . . . . . . . . . 38 105 6.2.2. 6P Message Types . . . . . . . . . . . . . . . . . . 38 106 6.2.3. 6P Command Identifiers . . . . . . . . . . . . . . . 39 107 6.2.4. 6P Return Codes . . . . . . . . . . . . . . . . . . . 40 108 6.2.5. 6P Scheduling Function Identifiers . . . . . . . . . 41 109 6.2.6. 6P CellOptions bitmap . . . . . . . . . . . . . . . . 42 110 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 111 7.1. Normative References . . . . . . . . . . . . . . . . . . 43 112 7.2. Informative References . . . . . . . . . . . . . . . . . 43 113 Appendix A. Recommended Structure of an SF Specification . . . . 44 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 116 1. Introduction 118 All communication in a 6TiSCH network is orchestrated by a schedule 119 [RFC7554]. The schedule is composed of cells, each identified by a 120 [slotOffset,channelOffset]. This specification defines the 6top 121 Protocol (6P), terminated by the 6TiSCH Operation sublayer (6top). 122 6P allows a node to communicate with a neighbor node to add/delete 123 TSCH cells to each other. This results in distributed schedule 124 management in a 6TiSCH network. The 6top layer terminates the 6top 125 Protocol, and runs one or more 6top Scheduling Functions (SFs) that 126 decide when to add/delete cells and trigger 6P Transactions. The SF 127 is out of scope of this document but the requirements for an SF are 128 defined here. 130 (R) 131 / \ 132 / \ 133 (B)-----(C) 134 | | 135 | | 136 (A) (D) 138 Figure 1: A simple 6TiSCH network. 140 The example network depicted in Figure 1 is used to describe the 141 interaction between nodes. We consider the canonical case where node 142 "A" issues 6P requests to node "B". We keep this example throughout 143 this document. Throughout the document, node A always represents the 144 node that issues a 6P request; node B the node that receives this 145 request. 147 We consider that node A monitors the communication cells it has in 148 its schedule to node B: 150 o If node A determines that the number of link-layer frames it is 151 sending to node B per unit of time exceeds the capacity offered by 152 the TSCH cells it has scheduled to node B, it triggers a 6P 153 Transaction with node B to add one or more cells to the TSCH 154 schedule of both nodes. 155 o If the traffic is lower than the capacity, node A triggers a 6P 156 Transaction with node B to delete one or more cells in the TSCH 157 schedule of both nodes. 158 o Node A MAY also monitor statistics to determine whether collisions 159 are happening on a particular cell to node B. If this feature is 160 enabled, node A communicates with node B to "relocate" the cell 161 which suffers collisions to a different [slotOffset,channelOffset] 162 location in the TSCH schedule. 164 This results in distributed schedule management in a 6TiSCH network. 166 The 6top Scheduling Function (SF) defines when to add/delete a cell 167 to a neighbor. Different applications require different SFs, so the 168 SF is left out of scope of this document. Different SFs are expected 169 to be defined in future companion specifications. A node MAY 170 implement multiple SFs and run them at the same time. At least one 171 SF MUST be running. The SFID field contained in all 6P messages 172 allows a node to invoke the appropriate SF on a per-6P Transaction 173 basis. 175 Section 2 describes the 6TiSCH Operation Sublayer (6top). Section 3 176 defines the 6top Protocol (6P). Section 4 provides guidelines on how 177 to define an SF. 179 2. 6TiSCH Operation Sublayer (6top) 181 As depicted in Figure 2, the 6TiSCH Operation Sublayer (6top) is the 182 next higher layer to the IEEE Std 802.15.4 TSCH medium access control 183 (MAC) layer [IEEE802154]. We use "802.15.4" as a short version of 184 "IEEE Std 802.15.4" in this document. 186 . 187 | . | 188 | higher layers | 189 +------------------------------------------+ 190 | 6top | 191 +------------------------------------------+ 192 | IEEE Std 802.15.4 TSCH | 193 | . | 194 . 196 Figure 2: The 6top sublayer in the protocol stack. 198 The roles of the 6top sublayer are to: 200 o Terminate the 6top Protocol (6P), which allows neighbor nodes to 201 communicate to add/delete cells to one another. 202 o Run one or multiple 6top Scheduling Functions (SFs), which define 203 the rules that decide when to add/delete cells. 205 2.1. Hard/Soft Cells 207 Each cell in the schedule is either "hard" or "soft": 209 o a soft cell can be read, added, deleted or updated by 6top. 210 o a hard cell is read-only for 6top. 212 In the context of this specification, all the cells used by 6top are 213 soft cells. Hard cells can be used for example when "hard-coding" a 214 schedule [RFC8180]. 216 2.2. Using 6P with the Minimal 6TiSCH Configuration 218 6P MAY be used alongside the Minimal 6TiSCH Configuration [RFC8180]. 219 In this case, it is RECOMMENDED to use 2 slotframes, as depicted in 220 Figure 3: 222 o Slotframe 0 is used for traffic defined in the Minimal 6TiSCH 223 Configuration. In Figure 3, this slotframe is 5 slots long, but 224 the slotframe can be shorter or longer. 225 o 6P allocates cells from Slotframe 1. In Figure 3, Slotframe 1 is 226 10 slots long, but the slotframe can be shorter or longer. 228 | 0 1 2 3 4 | 0 1 2 3 4 | 229 +------------------------+------------------------+ 230 Slotframe 0 | | | | | | | | | | | 231 5 slots long | EB | | | | | EB | | | | | 232 (Minimal 6TiSCH) | | | | | | | | | | | 233 +-------------------------------------------------+ 235 | 0 1 2 3 4 5 6 7 8 9 | 236 +-------------------------------------------------+ 237 Slotframe 1 | | | | | | | | | | | 238 10 slots long | |A->B| | | | | | |B->A| | 239 (6P) | | | | | | | | | | | 240 +-------------------------------------------------+ 242 Figure 3: 2-slotframe structure when using 6P alongside the Minimal 243 6TiSCH Configuration. 245 The Minimal 6TiSCH Configuration cell SHOULD be allocated from a 246 slotframe of higher priority than the slotframe used by 6P for 247 dynamic cell allocation. This way, dynamically allocated cells 248 cannot "mask" the cells used by the Minimal 6TiSCH Configuration. 249 6top MAY support additional slotframes; how to use additional 250 slotframes is out of scope for this document. 252 3. 6top Protocol (6P) 254 The 6top Protocol (6P) enables two neighbor nodes to add/delete/ 255 relocate cells in their TSCH schedule. Conceptually, two neighbor 256 nodes "negotiate" the location of the cells to add, delete, or 257 relocate in their TSCH schedule. 259 3.1. 6P Transactions 261 We call "6P Transaction" a complete negotiation between two neighbor 262 nodes. A 6P Transaction starts when a node wishes to add/delete/ 263 relocate one or more cells with one of its neighbors. A 6P 264 Transaction ends when the cell(s) have been added/deleted/relocated 265 in the schedule of both nodes, or when the 6P Transaction has failed. 267 6P messages exchanged between nodes A and B during a 6P Transaction 268 SHOULD be exchanged on non-shared unicast cells ("dedicated" cells) 269 between A and B. If no dedicated cells are scheduled between nodes A 270 and B, shared cells MAY be used. 272 Keeping consistency between the schedules of the two neighbor nodes 273 is important. A loss of consistency can cause loss of connectivity. 274 One example is when node A has a transmit cell to node B, but node B 275 does not have the corresponding reception cell. To verify 276 consistency, neighbor nodes maintain a Sequence Number (SeqNum). 277 Neighbor nodes exchange the SeqNum as part of each 6P Transaction to 278 detect possible inconsistency. This mechanism is explained in 279 Section 3.4.6.2. 281 An implementation MUST include a mechanism to associate each 282 scheduled cell with the SF that scheduled it. This mechanism is 283 implementation-specific and out of scope of this document. 285 A 6P Transaction can consist of 2 or 3 steps. A 2-step transaction 286 is used when node A selects the cells to be allocated. A 3-step 287 transaction is used when node B selects the cells to be allocated. 288 An SF MUST specify whether to use 2-step transactions, 3-step 289 transactions, or both. 291 We illustrate 2-step and 3-step transactions using the topology in 292 Figure 1. 294 3.1.1. 2-step 6P Transaction 296 Figure 4 shows an example 2-step 6P Transaction. In a 2-step 297 transaction, node A selects the candidate cells. Several elements 298 are left out to simplify understanding. 300 +----------+ +----------+ 301 | Node A | | Node B | 302 +----+-----+ +-----+----+ 303 | | 304 | 6P ADD Request | 305 | Type = REQUEST | 306 | Code = ADD | 307 | SeqNum = 123 | 308 cells | NumCells = 2 | 309 locked | CellList = [(1,2),(2,2),(3,5)] | 310 +-- |-------------------------------------->| 311 | | L2 ACK | 312 | 6P Timeout |<- - - - - - - - - - - - - - - - - - - | 313 | | | | 314 | | | 6P Response | 315 | | | Type = RESPONSE | 316 | | | Code = RC_SUCCESS | 317 | | | SeqNum = 123 | cells 318 | | | CellList = [(2,2),(3,5)] | locked 319 +-> X |<--------------------------------------| --+ 320 | L2 ACK | | 321 | - - - - - - - - - - - - - - - - - - ->| <-+ 322 | | 324 Figure 4: An example 2-step 6P Transaction. 326 In this example, the 2-step transaction occurs as follows: 328 1. The SF running on node A determines that 2 extra cells need to be 329 scheduled to node B. 330 2. The SF running on node A selects 3 candidate cells. Node A locks 331 the candidate cells in it schedule until it receives a 6P 332 response. 333 3. Node A sends a 6P ADD Request to node B, indicating it wishes to 334 add 2 cells (the "NumCells" value), and specifying the list of 3 335 candidate cells (the "CellList" value). Each cell in the 336 CellList is a [slotOffset,channelOffset] tuple. This 6P ADD 337 Request is link-layer acknowledged by node B (labeled "L2 ACK" in 338 Figure 4). 339 4. After having successfully sent the 6P ADD Request (i.e. receiving 340 the link-layer acknowledgment), node A starts a 6P Timeout to 341 abort the 6P Transaction in case no response is received from 342 node B. 343 5. The SF running on node B selects 2 out of the 3 cells from the 344 CellList of the 6P ADD Request. Node B locks those cells in it 345 schedule until the transmission is successfull (i.e. node B 346 receives a link-layer ACK from node A). Node B sends back a 6P 347 Response to node A, indicating the cells it has selected. The 348 response is link-layer acknowledged by node A. 349 6. Upon completion of this 6P Transaction, 2 cells from A to B have 350 been added to the TSCH schedule of both nodes A and B. 351 7. An inconsistency in the schedule can happen if the 6P Timeout 352 expires when the 6P Response is in the air, if the last link- 353 layer ACK for the 6P Response is lost, or if one of the nodes is 354 power cycled. 6P provides an inconsistency detection mechanism 355 described in Section 3.4.6.1 to cope with such situations. 357 3.1.2. 3-step 6P Transaction 359 Figure 5 shows an example 3-step 6P Transaction. In a 3-step 360 transaction, node B selects the candidate cells. Several elements 361 are left out to simplify understanding. 363 +----------+ +----------+ 364 | Node A | | Node B | 365 +----+-----+ +-----+----+ 366 | | 367 | 6P ADD Request | 368 | Type = REQUEST | 369 | Code = ADD | 370 | SeqNum = 178 | 371 | NumCells = 2 | 372 | CellList = [] | 373 |-------------------------------------->| 374 | L2 ACK | 375 6P Timeout |<- - - - - - - - - - - - - - - - - - - | 376 | | | 377 | | 6P Response | 378 | | Type = RESPONSE | 379 | | Code = RC_SUCCESS | 380 | | SeqNum = 178 | cells 381 | | CellList = [(1,2),(2,2),(3,5)] | locked 382 X |<--------------------------------------| --+ 383 | L2 ACK | | 384 | - - - - - - - - - - - - - - - - - - ->| 6P Timeout | 385 | | | | 386 | 6P Confirmation | | | 387 | Type = CONFIRMATION | | | 388 | Code = RC_SUCCESS | | | 389 cells | SeqNum = 178 | | | 390 locked | CellList = [(2,2),(3,5)] | | | 391 +-- |-------------------------------------->| X <--+ 392 | | L2 ACK | 393 +-> |<- - - - - - - - - - - - - - - - - - - | 394 | | 396 Figure 5: An example 3-step 6P Transaction. 398 In this example, the 3-step transaction occurs as follows: 400 1. The SF running on node A determines that 2 extra cells need to be 401 scheduled to node B, but does not select candidate cells. 402 2. Node A sends a 6P ADD Request to node B, indicating it wishes to 403 add 2 cells (the "NumCells" value), with an empty "CellList". 404 This 6P ADD Request is link-layer acknowledged by node B. 405 3. After having successfully sent the 6P ADD Request, node A starts 406 a 6P Timeout to abort the transaction in case no 6P Response is 407 received from node B. 408 4. The SF running on node B selects 3 candidate cells, and locks 409 them. Node B sends back a 6P Response to node A, indicating the 410 3 cells it has selected. The response is link-layer acknowledged 411 by node A. 412 5. After having successfully sent the 6P Response, node B starts a 413 6P Timeout to abort the transaction in case no 6P Confirmation is 414 received from node A. 415 6. The SF running on node A selects 2 cells from the CellList field 416 in the 6P Response, and locks those. Node A sends back a 6P 417 Confirmation to node B, indicating the cells it selected. The 418 confirmation is link-layer acknowledged by node B. 419 7. Upon completion of the 6P Transaction, 2 cells from A to B have 420 been added to the TSCH schedule of both nodes A and B; other 421 cells are unlocked. 422 8. An inconsistency in the schedule can happen if the 6P Timeout 423 expires when the 6P Confirmation is in the air, if the last link- 424 layer ACK for the 6P Confirmation is lost, or if one of the nodes 425 is power cycled. 6P provides an inconsistency detection 426 mechanism described in Section 3.4.6.1 to cope with such 427 situations. 429 3.2. Message Format 431 3.2.1. 6top Information Element (IE) 433 6P messages travel over a single hop. 6P messages are carried as 434 payload of an 802.15.4 Payload Information Element (IE) [IEEE802154]. 435 The messages are encapsulated within the Payload IE Header. The 436 Group ID is set to the IETF IE value defined in [RFC8137]. The 437 content is encapsulated by a SubType ID, as defined in [RFC8137]. 439 Since 6P messages are carried in IEs, IEEE bit/byte ordering applies. 440 Bits within each field in the 6top IE are numbered from 0 (leftmost 441 and least significant) to k-1 (rightmost and most significant), where 442 the length of the field is k bits. Fields that are longer than a 443 single octet are copied to the packet in the order from the octet 444 containing the lowest numbered bits to the octet containing the 445 highest numbered bits (little endian). 447 This document defines the "6top IE", a SubType of the IETF IE defined 448 in [RFC8137], with subtype ID IANA_6TOP_SUBIE_ID. The SubType 449 Content of the "6top IE" is defined in Section 3.2.2. The length of 450 the "6top IE" content is variable. 452 3.2.2. Generic 6P Message Format 454 All 6P messages follow the generic format shown in Figure 6. 456 1 2 3 457 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 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 |Version| T | R | Code | SFID | SeqNum | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | Other Fields... 462 +-+-+-+-+-+-+-+-+- 464 Figure 6: Generic 6P Message Format. 466 6P Version (Version): The version of the 6P protocol. Only version 467 0 is defined in this document. Future specifications MAY 468 define further versions of the 6P protocol. 469 Type (T): Type of message. The message types are defined in 470 Section 6.2.2. 471 Reserved (R): Reserved bits. These two bits SHOULD be set to zero 472 when sending the message, and MUST be ignored upon reception. 473 Code: The Code field contains a 6P Command Identifier when the 6P 474 message is of Type REQUEST. Section 6.2.3 lists the 6P command 475 identifiers. The Code field contains a 6P Return Code when the 476 6P message is of Type RESPONSE or CONFIRMATION. Section 6.2.4 477 lists the 6P Return Codes. The same return codes are used in 478 both 6P Response and 6P Confirmation messages. 479 6top Scheduling Function Identifier (SFID): The identifier of the SF 480 to use to handle this message. The SFID is defined in 481 Section 4.1. 482 SeqNum: Sequence number associated with the 6P Transaction, used to 483 match the 6P Request, 6P Response and 6P Confirmation of the 484 same 6P Transaction. The value of SeqNum MUST be different at 485 each new 6P Request issued to the same neighbor. The SeqNum is 486 also used to ensure consistency between the schedules of the 487 two neighbors. Section 3.4.6 details how the SeqNum is 488 managed. 489 Other Fields: The list of other fields and how they are used is 490 detailed in Section 3.3. 492 3.2.3. 6P CellOptions 494 An 8-bit 6P CellOptions bitmap is present in the following 6P 495 requests: ADD, DELETE, COUNT, LIST, RELOCATE. 497 o In the 6P ADD request, the 6P CellOptions bitmap is used to 498 specify what type of cell to add. 499 o In the 6P DELETE request, the 6P CellOptions bitmap is used to 500 specify what type of cell to delete. 501 o In the 6P COUNT and the 6P LIST requests, the 6P CellOptions 502 bitmap is used as a selector of a particular type of cells. 504 o In the 6P RELOCATE request, the 6P CellOptions bitmap is used to 505 specify what type of cell to relocate. 507 The contents of the 6P CellOptions bitmap apply to all elements in 508 the CellList field. Section 6.2.6 contains the RECOMMENDED format of 509 the 6P CellOptions bitmap. Figure 7 contains the RECOMMENDED meaning 510 of the 6P CellOptions bitmap for the 6P ADD, DELETE, RELOCATE 511 requests. Figure 8 contains the RECOMMENDED meaning of the 6P 512 CellOptions bitmap for the 6P COUNT, LIST requests. 514 Note: assuming node A issues the 6P command to node B. 515 +-------------+-----------------------------------------------------+ 516 | CellOptions | the type of cells B adds/deletes/relocates to its | 517 | Value | schedule when receiving a 6P ADD/DELETE/RELOCATE | 518 | | Request from A. | 519 +-------------+-----------------------------------------------------+ 520 |TX=0,RX=0,S=0| Does not apply. RC_ERR is returned. | 521 +-------------+-----------------------------------------------------+ 522 |TX=1,RX=0,S=0| add/delete/relocate RX cells at B (TX cells at A) | 523 +-------------+-----------------------------------------------------+ 524 |TX=0,RX=1,S=0| add/delete/relocate TX cells at B (RX cells at A) | 525 +-------------+-----------------------------------------------------+ 526 |TX=1,RX=1,S=0| add/delete/relocate TX|RX cells at B (and at A) | 527 +-------------+-----------------------------------------------------+ 528 |TX=0,RX=0,S=1| Does not apply. RC_ERR is returned. | 529 +-------------+-----------------------------------------------------+ 530 |TX=1,RX=0,S=1| add/delete/relocate RX|SHARED cells at B | 531 | | (TX|SHARED cells at A) | 532 +-------------+-----------------------------------------------------+ 533 |TX=0,RX=1,S=1| add/delete/relocate TX|SHARED cells at B | 534 | | (RX|SHARED cells at A) | 535 +-------------+-----------------------------------------------------+ 536 |TX=1,RX=1,S=1| add/delete/relocate TX|RX|SHARED cells at B | 537 | | (and at A) | 538 +-------------+-----------------------------------------------------+ 540 Figure 7: Meaning of the 6P CellOptions bitmap for the 6P ADD, 541 DELETE, RELOCATE requests. 543 Note: assuming node A issues the 6P command to node B. 544 +-------------+-----------------------------------------------------+ 545 | CellOptions | the type of cells B selects from its schedule when | 546 | Value | receiving a 6P COUNT or LIST Request from A, | 547 | | from all the cells B has scheduled with A | 548 +-------------+-----------------------------------------------------+ 549 |TX=0,RX=0,S=0| all cells | 550 +-------------+-----------------------------------------------------+ 551 |TX=1,RX=0,S=0| all cells marked as RX only | 552 +-------------+-----------------------------------------------------+ 553 |TX=0,RX=1,S=0| all cells marked as TX only | 554 +-------------+-----------------------------------------------------+ 555 |TX=1,RX=1,S=0| all cells marked as TX and RX only | 556 +-------------+-----------------------------------------------------+ 557 |TX=0,RX=0,S=1| all cells marked as SHARED (regardless of TX, RX) | 558 +-------------+-----------------------------------------------------+ 559 |TX=1,RX=0,S=1| all cells marked as RX and SHARED only | 560 +-------------+-----------------------------------------------------+ 561 |TX=0,RX=1,S=1| all cells marked as TX and SHARED only | 562 +-------------+-----------------------------------------------------+ 563 |TX=1,RX=1,S=1| all cells marked as TX and RX and SHARED | 564 +-------------+-----------------------------------------------------+ 566 Figure 8: Meaning of the 6P CellOptions bitmap for the 6P COUNT, LIST 567 requests. 569 The CellOptions is an opaque set of bits, sent unmodified to the SF. 570 The SF MAY redefine the format and meaning of the CellOptions field. 572 3.2.4. 6P CellList 574 A CellList field MAY be present in a 6P ADD Request, a 6P DELETE 575 Request, a 6P RELOCATE Request, a 6P Response, or a 6P Confirmation. 576 It is composed of a concatenation of zero, one or more 6P Cells as 577 defined in Figure 9. The content of the CellOptions field specifies 578 the options associated with all cells in the CellList. This 579 necessarily means that the same options are associated with all cells 580 in the CellList. 582 A 6P Cell is a 4-byte field, its RECOMMENDED format is: 584 1 2 3 585 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 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 | slotOffset | channelOffset | 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 Figure 9: 6P Cell Format. 592 slotOffset: The slot offset of the cell. 593 channelOffset: The channel offset of the cell. 595 The CellList is an opaque set of bytes, sent unmodified to the SF. 596 The length of the CellList field is implicit, and determined by the 597 IE Length field, present in the Payload IE header as defined by the 598 IEEE 802.15.4 standard [IEEE802154]. The SF MAY redefine the format 599 of the CellList field. 601 3.3. 6P Commands and Operations 603 3.3.1. Adding Cells 605 Cells are added by using the 6P ADD command. The Type field (T) is 606 set to REQUEST. The Code field is set to ADD. Figure 10 defines the 607 format of a 6P ADD Request. 609 1 2 3 610 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 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 |Version| T | R | Code | SFID | SeqNum | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | Metadata | CellOptions | NumCells | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | CellList ... 617 +-+-+-+-+-+-+-+-+- 619 Figure 10: 6P ADD Request Format. 621 Metadata: Used as extra signaling to the SF. The contents of the 622 Metadata field is an opaque set of bytes passed unmodified to 623 the SF. The meaning of this field depends on the SF, and is 624 out of scope of this document. For example, Metadata can 625 specify in which slotframe to add the cells. 626 CellOptions: Indicates the options to associate with the cells to be 627 added. If more than one cell is added (NumCells>1), the same 628 options are associated with each one. This necessarily means 629 that, if node A needs to add multiple cells with different 630 options, it needs to initiate multiple 6P ADD Transactions. 631 NumCells: The number of additional cells node A wants to schedule to 632 node B. 633 CellList: A list of 0, 1 or multiple candidate cells. Its length is 634 implicit and determined by the Length field of the Payload IE 635 header. 637 Figure 11 defines the format of a 6P ADD Response and Confirmation. 639 1 2 3 640 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 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 |Version| T | R | Code | SFID | SeqNum | 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 | CellList ... 645 +-+-+-+-+-+-+-+-+- 647 Figure 11: 6P ADD Response and Confirmation Formats. 649 CellList: A list of 0, 1 or multiple 6P Cells. 651 Consider the topology in Figure 1 where the SF on node A decides to 652 add NumCells cells to node B. 654 Node A's SF selects NumCandidate cells from its schedule. These are 655 cells that are candidates to be scheduled with node B. The 656 CellOptions field specifies the type of these cells. NumCandidate 657 MUST be larger or equal to NumCells. How many cells node A selects 658 (NumCandidate) and how that selection is done is specified in the SF 659 and out of scope of this document. Node A sends a 6P ADD Request to 660 node B which contains the CellOptions, the value of NumCells, and a 661 selection of NumCandidate cells in the CellList. In case the 662 NumCandidate cells do not fit in a single packet, this operation MUST 663 be split into multiple independent 6P ADD Requests, each for a subset 664 of the number of cells that eventually need to be added. In case of 665 a 3-step transaction, the SF is reponsible of ensuring that the 666 returned candidate celllist fit in the 6P Response packet. 668 Upon receiving the request, node B checks whether the cellOptions are 669 set to a legal value as noted by Figure 7. If this is not the case, 670 a Response with code RC_ERR is returned. Otherwise, node B's SF 671 verifies which of the cells in the CellList it can install in node 672 B's schedule, following the specified CellOptions field. How that 673 selection is done is specified in the SF and out of scope of this 674 document. The verification can succeed (NumCells cells from the 675 CellList can be used), fail (none of the cells from the CellList can 676 be used), or partially succeed (less than NumCells cells from the 677 CellList can be used). In all cases, node B MUST send a 6P Response 678 with return code set to RC_SUCCESS, and which specifies the list of 679 cells that were scheduled following the CellOptions field. That can 680 contain NumCells elements (succeed), 0 elements (fail), or between 0 681 and NumCells elements (partially succeed). 683 Upon receiving the response, node A adds the cells specified in the 684 CellList according to the CellOptions field. 686 3.3.2. Deleting Cells 688 Cells are deleted by using the 6P DELETE command. The Type field (T) 689 is set to REQUEST. The Code field is set to DELETE. Figure 12 690 defines the format of a 6P DELETE Request. 692 1 2 3 693 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 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 |Version| T | R | Code | SFID | SeqNum | 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 | Metadata | CellOptions | NumCells | 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 | CellList ... 700 +-+-+-+-+-+-+-+-+- 702 Figure 12: 6P DELETE Request Format. 704 Metadata: Same usage as for the 6P ADD command, see Section 3.3.1. 705 Its format is the same as that in the 6P ADD command, but its 706 content could be different. 707 CellOptions: Indicates the options that need to be associated to the 708 cells to delete. Only cells matching the CellOptions can are 709 deleted. 710 NumCells: The number of cells from the specified CellList the sender 711 wants to delete from the schedule of both sender and receiver. 712 CellList: A list of 0, 1 or multiple 6P Cells. Its length is 713 determined by the Length field of the Payload IE header. 715 Figure 13 defines the format of a 6P DELETE Response and 716 Confirmation. 718 1 2 3 719 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 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 |Version| T | R | Code | SFID | SeqNum | 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 | CellList ... 724 +-+-+-+-+-+-+-+-+- 726 Figure 13: 6P DELETE Response and Confirmation Formats. 728 CellList: A list of 0, 1 or multiple 6P Cells. 730 The behavior for deleting cells is equivalent to that of adding cells 731 except that: 733 o The nodes delete the cells they agree upon rather than adding 734 them. 735 o All cells in the CellList MUST already be scheduled between the 736 two nodes and MUST match the CellOptions field. If node A puts 737 cells in its CellList that are not already scheduled between the 738 two nodes and match the CellOptions field, node B MUST reply with 739 a RC_ERR_CELLLIST return code. 740 o If the CellList in the 6P Request is empty, the SF on the 741 receiving node SHOULD delete any cell from the sender, as long as 742 it matches the CellOptions field. 743 o The CellList in a 6P Request (2-step transaction) or 6P Response 744 (3-step transaction) MUST either be empty, contain exactly 745 NumCells cells, or more than NumCells cells. The case where the 746 CellList is not empty but contains less than NumCells cells is not 747 supported. 749 3.3.3. Relocating Cells 751 Cell relocation consists in moving a cell to a different 752 [slotOffset,channelOffset] location in the schedule. The Type field 753 (T) is set to REQUEST. The Code is set to RELOCATE. Figure 14 754 defines the format of a 6P RELOCATE Request. 756 1 2 3 757 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 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 |Version| T | R | Code | SFID | SeqNum | 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 | Metadata | CellOptions | NumCells | 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 | Relocation CellList ... 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 765 | Candidate CellList ... 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 768 Figure 14: 6P RELOCATE Request Format. 770 Metadata: Same usage as for the 6P ADD command, see Section 3.3.1. 771 CellOptions: Indicates the options that need to be associated with 772 cells to be relocated. 773 NumCells: The number of cells to relocate, which MUST be equal or 774 greater than 1. 775 Relocation CellList: The list of NumCells 6P Cells to relocate. 776 Candidate CellList: A list of NumCandidate candidate cells for node 777 B to pick from. NumCandidate MUST be 0, equal to NumCells, or 778 greater than NumCells. Its length is determined by the Length 779 field of the Payload IE header. 781 In a 2-step 6P RELOCATE Transaction, node A specifies both the cells 782 it needs to relocate, and the list of candidate cells to relocate to. 783 The Relocation CellList MUST contain exactly NumCells entries. The 784 Candidate CellList MUST contain at least NumCells entries (that is 785 NumCandidate>=NumCells). 787 In a 3-step 6P RELOCATE Transaction, node A specifies only the cells 788 it needs to relocate, but not the list of candidate cells to relocate 789 to. The Candidate CellList MUST therefore be empty. 791 Figure 15 defines the format of a 6P RELOCATE Response and 792 Confirmation. 794 1 2 3 795 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 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 |Version| T | R | Code | SFID | SeqNum | 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 | CellList ... 800 +-+-+-+-+-+-+-+-+- 802 Figure 15: 6P RELOCATE Response and Confirmation Formats. 804 CellList: A list of 0, 1 or multiple 6P Cells. 806 Node A's SF wants to relocate NumCells particular cells. Node A 807 creates a 6P RELOCATE Request, and indicates the cells it wants to 808 relocate in the Relocation CellList. It also selects NumCandidate 809 cells from its schedule as candidate cells to relocate the cells to, 810 and puts those in the Candidate CellList. The CellOptions field 811 specifies the type of the cell(s) to relocate. NumCandidate MUST be 812 larger or equal to NumCells. How many cells it selects 813 (NumCandidate) and how that selection is done is specified in the SF 814 and out of scope of this document. Node A sends the 6P RELOCATE 815 Request to node B. 817 Upon receiving the request, Node B checks if the length of the 818 Candidate CellList is larger or equal to NumCells. Node B's SF 819 verifies that all the cells in the Relocation CellList are indeed 820 scheduled with node A, and are associate the options specified in the 821 CellOptions field. If that check fails, node B MUST send a 6P 822 Response to node A with return code RC_ERR_CELLLIST. If that check 823 passes, node B's SF verifies which of the cells in the Candidate 824 CellList it can install in its schedule. How that selection is done 825 is specified in the SF and out of scope of this document. That 826 verification on Candidate CellList can succeed (NumCells cells from 827 the Candidate CellList can be used), fail (none of the cells from the 828 Candidate CellList can be used) or partially succeed (less than 829 NumCells cells from the Candidate CellList can be used). In all 830 cases, node B MUST send a 6P Response with return code set to 831 RC_SUCCESS, and which specifies the list of cells that will be re- 832 scheduled following the CellOptions field. That can contain NumCells 833 elements (succeed), 0 elements (fail), between 0 and NumCells 834 elements (partially succeed). If N < NumCells cells appear in the 835 CellList, this means first N cells in the Relocation CellList have to 836 be relocated, the remainder have not. 838 Upon receiving the response with Code RC_SUCCESS, node A relocates 839 the cells specified in Relocation CellList of its RELOCATE Request to 840 the new locations specified in the CellList of the 6P Response, in 841 the same order. In case the received Response Code is 842 RC_ERR_CELLLIST, the transaction is aborted and no cell is relocated. 843 Upon receiving the L2 Ack of the 6P Response or 6P Confirmation in 844 case of a 3-step transaction, Node B relocates the selected cells. 846 The SF SHOULD take into account situations such as the relocation of 847 all cells at a time between two nodes. If the operation fails the 848 schedules of both nodes may completely diverge. Is up to the SF the 849 handling of such situation. 851 Figure 16 shows an example of a successful 2-step 6P RELOCATION 852 Transaction. 854 +----------+ +----------+ 855 | Node A | | Node B | 856 +----+-----+ +-----+----+ 857 | | 858 | 6P RELOCATE Request | 859 | Type = REQUEST | 860 | Code = RELOCATE | 861 | SeqNum = 11 | 862 | NumCells = 2 | 863 | R.CellList = [(1,2),(2,2)] | 864 | C.CellList = [(3,3),(4,3),(5,3)] | 865 |-------------------------------------->| B prepares 866 | L2 ACK | to relocate 867 |<- - - - - - - - - - - - - - - - - - - | (1,2)->(5,3) 868 | | and 869 | | (2,2)->(3,3) 870 | 6P Response | 871 | Code = RC_SUCCESS | 872 | SeqNum = 11 | 873 | CellList = [(5,3),(3,3)] | 874 A relocates|<--------------------------------------| 875 (1,2)->(5,3)| L2 ACK | 876 and | - - - - - - - - - - - - - - - - - - ->|B relocates 877 (2,2)->(3,3)| |(1,2)->(5,3) 878 | |and 879 | |(2,2)->(3,3) 881 Figure 16: Example of a successful 2-step 6P RELOCATION Transaction. 883 Figure 17 shows an example of a partially successful 2-step 6P 884 RELOCATION Transaction. 886 +----------+ +----------+ 887 | Node A | | Node B | 888 +----+-----+ +-----+----+ 889 | | 890 | 6P RELOCATE Request | 891 | Type = REQUEST | 892 | Code = RELOCATE | 893 | SeqNum = 199 | 894 | NumCells = 2 | 895 | R.CellList = [(1,2),(2,2)] | 896 | C.CellList = [(3,3),(4,3),(5,3)] |B prepares 897 |-------------------------------------->|to relocate 898 | L2 ACK |(1,2)->(4,3) 899 |<- - - - - - - - - - - - - - - - - - - |but cannot 900 | |relocate (2,2) 901 | 6P Response | 902 | Type = RESPONSE | 903 | Code = RC_SUCCESS | 904 | SeqNum = 199 | 905 | CellList = [(4,3)] | 906 A relocates |<--------------------------------------| 907 (1,2)->(4,3)| L2 ACK | 908 | - - - - - - - - - - - - - - - - - - ->|B relocates 909 | |(1,2)->(4,3) 910 | | 911 | | 913 Figure 17: Example of a partially successful 2-step 6P RELOCATION 914 Transaction. 916 Figure 18 shows an example of a failed 2-step 6P RELOCATION 917 Transaction. 919 +----------+ +----------+ 920 | Node A | | Node B | 921 +----+-----+ +-----+----+ 922 | | 923 | 6P RELOCATE Request | 924 | Type = REQUEST | 925 | Code = RELOCATE | 926 | SeqNum = 53 | 927 | NumCells = 2 | 928 | R.CellList = [(1,2),(2,2)] | 929 | C.CellList = [(3,3),(4,3),(5,3)] | 930 |-------------------------------------->| B cannot 931 | L2 ACK | relocate 932 |<- - - - - - - - - - - - - - - - - - - | (1,2) 933 | | nor (2,2) 934 | 6P Response | 935 | Type = RESPONSE | 936 | Code = RC_SUCCESS | 937 | SeqNum = 53 | 938 | CellList = [] | 939 |<--------------------------------------| B does not 940 | L2 ACK | relocate 941 A does not | - - - - - - - - - - - - - - - - - - ->| 942 relocate | | 943 | | 945 Figure 18: Failed 2-step 6P RELOCATION Transaction Example. 947 Figure 19 shows an example of a successful 3-step 6P RELOCATION 948 Transaction. 950 +----------+ +----------+ 951 | Node A | | Node B | 952 +----+-----+ +-----+----+ 953 | | 954 | 6P RELOCATE Request | 955 | Type = REQUEST | 956 | Code = RELOCATE | 957 | SeqNum = 11 | 958 | NumCells = 2 | 959 | R.CellList = [(1,2),(2,2)] | 960 | C.CellList = [] | 961 |-------------------------------------->| 962 | L2 ACK | 963 |<- - - - - - - - - - - - - - - - - - - | B identifies 964 | | candidate 965 | | cells 966 | 6P Response | (3,3), 967 | Code = RC_SUCCESS | (4,3) and 968 | SeqNum = 11 | (5,3) 969 | CellList = [(3,3),(4,3),(5,3)] | 970 A prepares |<--------------------------------------| 971 to relocate | L2 ACK | 972 (1,2)->(5,3) | - - - - - - - - - - - - - - - - - - ->| 973 and | | 974 (2,2)->(3,3) | 6P Confirmation | 975 | Code = RC_SUCCESS | 976 | SeqNum = 11 | 977 | CellList = [(5,3),(3,3)] | 978 |-------------------------------------->| B relocates 979 | L2 ACK | (1,2)->(5,3) 980 A relocates |<- - - - - - - - - - - - - - - - - - - | and 981 (1,2)->(5,3)| | (2,2)->(3,3) 982 and | | 983 (2,2)->(3,3)| | 984 | | 986 Figure 19: Example of a successful 3-step 6P RELOCATION Transaction. 988 3.3.4. Counting Cells 990 To retrieve the number of scheduled cells a node A has with B, node A 991 issues a 6P COUNT command. The Type field (T) is set to REQUEST. 992 The Code field is set to COUNT. Figure 20 defines the format of a 6P 993 COUNT Request. 995 1 2 996 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 997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 998 |Version| T | R | Code | SFID | SeqNum | 999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1000 | Metadata | CellOptions | 1001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1003 Figure 20: 6P COUNT Request Format. 1005 Metadata: Same usage as for the 6P ADD command, see Section 3.3.1. 1006 Its format is the same as that in the 6P ADD command, but its 1007 content could be different. 1008 CellOptions: Specifies which type of cell to be counted. 1010 Figure 21 defines the format of a 6P COUNT Response. 1012 1 2 3 1013 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 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1015 |Version| T | R | Code | SFID | SeqNum | 1016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1017 | NumCells | 1018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1020 Figure 21: 6P COUNT Response Format. 1022 NumCells: The number of cells which correspond to the fields of the 1023 request. 1025 Node A issues a COUNT command to node B, specifying cell options. 1026 Upon receiving the 6P COUNT request, node B goes through its schedule 1027 and counts the number of cells scheduled with node A in its own 1028 schedule, and which match the cell options in the CellOptions field 1029 of the request. Section 3.2.3 details the use of the CellOptions 1030 field. 1032 Node B issues a 6P response to node A with return code set to 1033 RC_SUCCESS, and with NumCells containing the number of cells that 1034 match the request. 1036 3.3.5. Listing Cells 1038 To retrieve a list of scheduled cells node A has with node B, node A 1039 issues a 6P LIST command. The Type field (T) is set to REQUEST. The 1040 Code field is set to LIST. Figure 22 defines the format of a 6P LIST 1041 Request. 1043 1 2 1044 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 1045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1046 |Version| T | R | Code | SFID | SeqNum | 1047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1048 | Metadata | CellOptions | Reserved | 1049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1050 | Offset | MaxNumCells | 1051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1053 Figure 22: 6P LIST Request Format. 1055 Metadata: Same usage as for the 6P ADD command, see Section 3.3.1. 1056 Its format is the same as that in the 6P ADD command, but its 1057 content could be different. 1058 CellOptions: Specifies which type of cell to be listed. 1059 Reserved: Reserved bits. These bits SHOULD be set to zero when 1060 sending the message, and MUST be ignored upon reception. 1061 Offset: The Offset of the first scheduled cell that is requested. 1062 The mechanism assumes cells are ordered according to a rule 1063 defined in the SF. The rule MUST always order the cells in the 1064 same way. 1065 MaxNumCells: The maximum number of cells to be listed. Node B MAY 1066 return less than MaxNumCells cells, for example if MaxNumCells 1067 cells do not fit in the frame. 1069 Figure 23 defines the format of a 6P LIST Response. 1071 1 2 3 1072 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 1073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1074 |Version| T | R | Code | SFID | SeqNum | 1075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1076 | CellList ... 1077 +-+-+-+-+-+-+-+-+- 1079 Figure 23: 6P LIST Response Format. 1081 CellList: A list of 0, 1 or multiple 6P Cells. 1083 When receiving a LIST command, node B returns the cells scheduled 1084 with A in its schedule that match the CellOptions field as specified 1085 in Section 3.2.3. 1087 When node B receives a LIST request, the returned CellList in the 6P 1088 Response contains between 1 and MaxNumCells cells, starting from the 1089 specified offset. Node B SHOULD include as many cells as fit in the 1090 frame. If the response contains the last cell, Node B MUST set the 1091 Code field in the response to RC_EOL ("End of List", as per 1092 Figure 37), indicating to Node A that there no more cells that match 1093 the request. Node B MUST return at least one cell, unless the 1094 specified Offset is beyond the end of B's cell list in its schedule. 1095 If node B has less than Offset cells that match the request, node B 1096 returns an empty CellList and a Code field set to RC_EOL. 1098 3.3.6. Clearing the Schedule 1100 To clear the schedule between nodes A and B (for example after a 1101 schedule inconsistency is detected), node A issues a CLEAR command. 1102 The Type field (T) is set to 6P Request. The Code field is set to 1103 CLEAR. Figure 24 defines the format of a 6P CLEAR Request. 1105 1 2 1106 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 1107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1108 |Version| T | R | Code | SFID | SeqNum | 1109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1110 | Metadata | 1111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1113 Figure 24: 6P CLEAR Request Format. 1115 Metadata: Same usage as for the 6P ADD command, see Section 3.3.1. 1116 Its format is the same as that in the 6P ADD command, but its 1117 content could be different. 1119 Figure 25 defines the format of a 6P CLEAR Response. 1121 1 2 3 1122 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 1123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1124 |Version| T | R | Code | SFID | SeqNum | 1125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1127 Figure 25: 6P CLEAR Response Format. 1129 When a 6P CLEAR command is issued from node A to node B, both nodes A 1130 and B MUST remove all the cells scheduled between them. That is, 1131 node A MUST remove all the cells scheduled with node B, and node B 1132 MUST remove all the cells scheduled with node A. In a 6P CLEAR 1133 command, the SeqNum MUST NOT be checked. In particular, even if the 1134 request contains a SeqNum value that would normally cause node B to 1135 detect a schedule inconsistency, the transaction MUST NOT be aborted. 1136 Upon 6P CLEAR completion, the value of SeqNum MUST be reset to 0. 1138 The Response Code to a 6P CLEAR command SHOULD be RC_SUCCESS unless 1139 the operation cannot be executed. When the CLEAR operation cannot be 1140 executed, the Response Code MUST be set to RC_RESET. 1142 3.3.7. Generic Signaling Between SFs 1144 The 6P SIGNAL message allows the SF implementations on two neighbor 1145 nodes to exchange generic commands. The payload in a received SIGNAL 1146 message is an opaque set of bytes passed unmodified to the SF. How 1147 the generic SIGNAL command is used is specified by the SF, and 1148 outside the scope of this document. The Type field (T) is set to 1149 REQUEST. The Code field is set to SIGNAL. Figure 26 defines the 1150 format of a 6P SIGNAL Request. 1152 1 2 1153 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 1154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1155 |Version| T | R | Code | SFID | SeqNum | 1156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1157 | Metadata | payload ... 1158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1160 Figure 26: 6P SIGNAL Request Format. 1162 Metadata: Same usage as for the 6P ADD command, see Section 3.3.1. 1163 Its format is the same as that in the 6P ADD command, but its 1164 content could be different. 1166 Figure 27 defines the format of a 6P SIGNAL Response. 1168 1 2 3 1169 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 1170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1171 |Version| T | R | Code | SFID | SeqNum | 1172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1173 | payload ... 1174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1176 Figure 27: 6P SIGNAL Response Format. 1178 3.4. Protocol Functional Details 1180 3.4.1. Version Checking 1182 All messages contain a Version field. If multiple Versions of the 6P 1183 protocol have been defined (in future specifications for Version 1184 values different from 0), a node MAY implement multiple protocol 1185 versions at the same time. When a node receives a 6P message with a 1186 Version number it does not implement, the node MUST reply with a 6P 1187 Response with a Return Code field set to RC_ERR_VERSION. The format 1188 of this 6P Response message MUST be compliant with Version 0 and MUST 1189 be supported by all future versions of the protocol. This ensures 1190 that, when node B sends a 6P Response to node A indicating it does 1191 not implement the 6P version in the 6P Request, node A can 1192 successfully parse that response. 1194 When a node supports a version number received in a 6P Request 1195 message, the Version field in the 6P Response MUST be the same as the 1196 Version field in the corresponding 6P Request. Similarly, in a 1197 3-step transaction, the Version field in the 6P Confirmation MUST 1198 match that of the 6P Request and 6P Response of the same transaction. 1200 3.4.2. SFID Checking 1202 All messages contain an SFID field. A node MAY support multiple SFs 1203 at the same time. When receiving a 6P message with an unsupported 1204 SFID, a node MUST reply with a 6P Response and a return code of 1205 RC_ERR_SFID. The SFID field in the 6P Response MUST be the same as 1206 the SFID field in the corresponding 6P Request. In a 3-step 1207 transaction, the SFID field in the 6P Confirmation MUST match that of 1208 the 6P Request and the 6P Response of the same transaction. 1210 3.4.3. Concurrent 6P Transactions 1212 Only a single 6P Transaction between two neighbors, in a given 1213 direction, can take place at the same time. That is, a node MUST NOT 1214 issue a new 6P Request to a given neighbor before having received the 1215 6P Response for a previous request to that neighbor, except when the 1216 previous 6P Transaction has timed out. If a node receives a 6P 1217 Request from a given neighbor before having sent the 6P Response to 1218 the previous 6P Request from that neighbor, it MUST send back a 6P 1219 Response with a return code of RC_RESET (as per Figure 37) and 1220 discard this ongoing second transaction. A node receiving a RC_RESET 1221 code MUST abort the second transaction and consider it never 1222 happened. 1224 Nodes A and B MAY support having two transactions going on at the 1225 same time, one in each direction. Similarly, a node MAY support 1226 concurrent 6P Transactions with different neighbors. In this case, 1227 the cells involved in an ongoing 6P Transaction MUST be "locked" 1228 until the transaction finishes. For example, in Figure 1, node C can 1229 have a different ongoing 6P Transaction with nodes B and R. In case 1230 a node does not have enough resources to handle concurrent 6P 1231 Transactions from different neighbors it MUST reply with a 6P 1232 Response with return code RC_ERR_BUSY (as per Figure 37). In case 1233 the requested cells are locked, it MUST reply to that request with a 1234 6P Response with return code RC_ERR_LOCKED (as per Figure 37). The 1235 node receiving RC_ERR_BUSY or a RC_ERR_LOCKED MAY implement a retry 1236 mechanism, defined by the SF. 1238 3.4.4. 6P Timeout 1240 A timeout occurs when the node have successfully sent a 6P Request 1241 does not receive the corresponding 6P Response within an amount of 1242 time specified by the SF. In a 3-step transaction, a timeout also 1243 occurs when a node sending the 6P Response does not receive a 6P 1244 Confirmation. When a timeout occurs, the transaction MUST be 1245 canceled at the node where the timeout occurs. The value of the 6P 1246 Timeout should be larger than the longest possible time it takes to 1247 receive the 6P Response or Confirmation. The value of the 6P Timeout 1248 hence depends on the number of cells scheduled between the neighbor 1249 nodes, the maximum number of link-layer retransmissions, etc. The SF 1250 MUST determine the value of the timeout. The value of the timeout is 1251 out of scope of this document. 1253 3.4.5. Aborting a 6P Transaction 1255 In case the receiver of a 6P Request fails during a 6P Transaction 1256 and it is unable to complete it, it SHOULD reply to that Request with 1257 a 6P Response with return code RC_RESET. Upon receiving this 6P 1258 Response, the initiator of the 6P Transaction MUST consider the 6P 1259 Transaction as failed. 1261 Similarly, in the case of 3-step transaction, when the receiver of a 1262 6P Response fails during the 6P Transaction and is unable to complete 1263 it, it MUST reply to that 6P Response with a 6P Confirmation with 1264 return code RC_RESET. Upon receiving this 6P Confirmation, the 1265 sender of the 6P Response MUST consider the 6P Transaction as failed. 1267 3.4.6. SeqNum Management 1269 The SeqNum is the field in the 6top IE header used to match Request, 1270 Response and Confirmation. The SeqNum is used to detect and handle 1271 duplicate commands (Section 3.4.6.1) and schedule inconsistencies 1272 (Section 3.4.6.2). Each node remembers the last used SeqNum for each 1273 neighbor. That is, a node stores as many SeqNum values as it has 1274 neighbors. In case of supporting multiple SFs at a time, a SeqNum 1275 value is maintained per SF and per neighbor. In the remainder of 1276 this section, we describe the use of SeqNum between two neighbors; 1277 the same happens for each other neighbor, independently. 1279 When a node resets or after a CLEAR transaction, it MUST reset SeqNum 1280 to 0. The 6P Response and 6P Confirmation for a transaction MUST use 1281 the same SeqNum value as that in the Request. After every 1282 transaction, the SeqNum MUST be incremented by exactly 1. 1284 Specifically, if node A receives the link-layer acknowledgment for 1285 its 6P Request, it commits to incrementing the SeqNum by exactly 1 1286 after the 6P Transaction ends. This ensure that, at the next 6P 1287 Transaction where it sends a 6P Request, that 6P Request will have a 1288 different SeqNum. 1290 Similarly, a node B increments the SeqNum by exactly 1 after having 1291 received the link-layer acknowledgment for the 6P Response (2-step 6P 1292 Transaction), or after having sent the link-layer acknowledgment for 1293 the 6P Confirmation (3-step 6P Transaction) . 1295 When a node B receives a 6P Request from node A with SeqNum equal to 1296 0, it checks the stored SeqNum for A. If A is a new neighbor, the 1297 stored SeqNum in B will be 0. The transaction can continue. If the 1298 stored SeqNum for A in B is different than 0, a potential 1299 inconsistency is detected. In this case B MUST return RC_ERR_SEQNUM 1300 with SeqNum=0. The SF at A MAY decide what to do next as described 1301 in Section 3.4.6.2. 1303 The SeqNum MUST be implemented as a lollipop counter: it rolls over 1304 from 0xFF to 0x01 (not to 0x00). This is used to detect a neighbor 1305 reset. Figure 28 lists the possible values of the SeqNum. 1307 +-----------+-----------------------------+ 1308 | Value | Meaning | 1309 +-----------+-----------------------------+ 1310 | 0x00 | Clear or After device Reset | 1311 | 0x01-0xFF | Lollipop Counter values | 1312 +-----------+-----------------------------+ 1314 Figure 28: Possible values of the SeqNum. 1316 3.4.6.1. Detecting and Handling Duplicate 6P Messages 1318 All 6P commands are link-layer acknowledged. A duplicate message 1319 means that a node receives a second 6P Request, Response or 1320 Confirmation. This happens when the link-layer acknowledgment is not 1321 received, and a link-layer retransmission happens. Duplicate 1322 messages are normal and unavoidable. 1324 Figure 29 shows an example 2-step transaction in which Node A 1325 receives a duplicate 6P Response. 1327 +----------+ +----------+ 1328 | Node A | | Node B | 1329 +----+-----+ +-----+----+ 1330 | | 1331 | 6P Request (SeqNum=456) | 1332 |-------------------------------------->| 1333 | L2 ACK | 1334 |<- - - - - - - - - - - - - - - - - - - | 1335 | | 1336 | 6P Response (SeqNum=456) | 1337 |<--------------------------------------| 1338 | L2 ACK | 1339 | - - - - - - - - - - -X | No ACK: 1340 | | link-layer 1341 | 6P Response (SeqNum=456) | retransmit 1342 duplicate |<--------------------------------------| 1343 6P Response | L2 ACK | 1344 received | - - - - - - - - - - - - - - - - - - ->| 1345 | | 1347 Figure 29: Example duplicate 6P message. 1349 Figure 30 shows example 3-step transaction in which Node A receives a 1350 out-of-order duplicate 6P Response after having sent a 6P 1351 Confirmation. 1353 +----------+ +----------+ 1354 | Node A | | Node B | 1355 +----+-----+ +-----+----+ 1356 | | 1357 | 6P Request (SeqNum=123) | 1358 |-------------------------------------->| 1359 | L2 ACK | 1360 |<- - - - - - - - - - - - - - - - - - - | 1361 | | 1362 | 6P Response (SeqNum=123) | 1363 |<--------------------------------------| 1364 | L2 ACK | 1365 | - - - - - - - - - - -X | No ACK: 1366 | | link-layer 1367 | 6P Confirmation (SeqNum=123) | retransmit 1368 |-------------------------------------->| | 1369 | L2 ACK | | 1370 |<- - - - - - - - - - - - - - - - - - - | frame 1371 | | queued 1372 | 6P Response (SeqNum=123) | | 1373 duplicate |<--------------------------------------| <--+ 1374 out-of-order | L2 ACK | 1375 6P Response | - - - - - - - - - - - - - - - - - - ->| 1376 received | | 1378 Figure 30: Example out-of-order duplicate 6P message. 1380 A node detects a duplicate 6P message when it has the same SeqNum and 1381 type as the last frame received from the same neighbor. When 1382 receiving a duplicate 6P message, a node MUST send a link-layer 1383 acknowledgment, but MUST silently ignore the 6P message at the 6top 1384 sublayer. 1386 3.4.6.2. Detecting and Handling a Schedule Inconsistency 1388 A schedule inconsistency happens when the schedules of nodes A and B 1389 are inconsistent. For example, when node A has a transmit cell to 1390 node B, but node B does not have the corresponding receive cell, and 1391 therefore isn't listening to node A on that cell. A schedule 1392 inconsistency results in loss of connectivity. 1394 The SeqNum field, which is present in each 6P message, is used to 1395 detect an inconsistency. The SeqNum field increments by 1 at each 1396 message. A node computes the expected SeqNum field for the next 6P 1397 Transaction. If a node receives a 6P Request with a SeqNum value 1398 that is not the expected one, it has detected an inconsistency. 1400 There are at least 2 cases in which a schedule inconsistency happens. 1402 The first case is when a node loses state, for example when it is 1403 power cycled (turned off, then on). In that case, its SeqNum value 1404 is reset to 0. Since the SeqNum is a lollipop counter, its neighbor 1405 detects an inconsistency at the next 6P transaction. This is 1406 illustrated in Figure 31. 1408 +----------+ +----------+ 1409 | Node A | | Node B | 1410 +----+-----+ +-----+----+ 1411 SeqNum=87 | | SeqNum=87 1412 | | 1413 | 6P Request (SeqNum=87) | 1414 |-------------------------------------->| 1415 | L2 ACK | 1416 |<- - - - - - - - - - - - - - - - - - - | 1417 | | 1418 | 6P Response (SeqNum=87) | 1419 |<--------------------------------------| 1420 | L2 ACK | 1421 | - - - - - - - - - - - - - - - - - - ->| 1422 | ==== power-cycle 1423 | | 1424 SeqNum=88 | | SeqNum=0 1425 | | 1426 | 6P Request (SeqNum=88) | 1427 |-------------------------------------->| Inconsistency 1428 | L2 ACK | Detected 1429 |<- - - - - - - - - - - - - - - - - - - | 1430 | | 1431 | 6P Response (SeqNum=0, RC_ERR_SEQNUM) | 1432 |<--------------------------------------| 1433 | L2 ACK | 1434 | - - - - - - - - - - - - - - - - - - ->| 1436 Figure 31: Example of inconsistency because of node reset. 1438 The second case is when the maximum number of link-layer 1439 retransmissions is reached on the 6P Response of a 2-step transaction 1440 (or equivalently on a 6P Confirmation of a 3-step transaction). This 1441 is illustrated in Figure 32. 1443 +----------+ +----------+ 1444 | Node A | | Node B | 1445 +----+-----+ +-----+----+ 1446 SeqNum=87 | | SeqNum=87 1447 | | 1448 | 6P Request (SeqNum=87) | 1449 |-------------------------------------->| 1450 | L2 ACK | 1451 |<- - - - - - - - - - - - - - - - - - - | 1452 | | 1453 | 6P Response (SeqNum=87) | 1454 |<--------------------------------------| 1455 | L2 ACK | 1456 | - - - - - - - - X | 1457 SeqNum=88 | | no ACK: 1458 | 6P Response (SeqNum=87) | retrans. 1 1459 (duplicate) |<--------------------------------------| 1460 | L2 ACK | 1461 | - - - - - - - - X | 1462 | | no ACK: 1463 | 6P Response (SeqNum=87) | retrans. 2 1464 (duplicate) |<--------------------------------------| 1465 | L2 ACK | 1466 | - - - - - - - - X | 1467 | | max retrans.: 1468 | | Inconsistency 1469 | | Detected 1471 Figure 32: Example inconsistency because of maximum link-layer 1472 retransmissions (here 2). 1474 In both cases, node B detects the inconsistency. 1476 If the inconsistency is detected during a 6P Transaction (Figure 31), 1477 the node that has detected it MUST send back a 6P Response or 6P 1478 Confirmation with an error code of RC_ERR_SEQNUM. In this 6P 1479 Response or 6P Confirmation, the SeqNum field MUST be set to the 1480 value of the sender of the message (0 in the example in Figure 31). 1482 The SF of the node which has detected the inconsistency MUST define 1483 how to handle the inconsistency. A first possibility is to issue a 1484 6P CLEAR request to clear the schedule, and rebuild. A second 1485 possibility is to issue a 6P LIST request to retrieve the schedule. 1486 A third possibility is to internally "roll-back" the schedule. How 1487 to handle an inconsistency is out of scope of this document. The SF 1488 defines how to handle an inconsistency. 1490 3.4.7. Handling Error Responses 1492 A return code marked as Yes in the "Is Error" column in Figure 37 1493 indicates an error. When a node receives a 6P Response or 6P 1494 Confirmation with an error, it MUST consider the 6P Transaction as 1495 failed. In particular, if this was a response to a 6P ADD, DELETE or 1496 RELOCATE Request, the node MUST NOT add, delete or relocate any of 1497 the cells involved in this 6P Transaction. Similarly, a node sending 1498 a 6P Response or a 6P Confirmation with an error code MUST NOT add, 1499 delete, relocate any cells as part of that 6P Transaction. Defining 1500 what to do after an error has occurred is out of scope of this 1501 document. The SF defines what to do after an error has occurred. 1503 3.5. Security 1505 6P messages are secured through link-layer security. When link-layer 1506 security is enabled, the 6P messages MUST be secured. This is 1507 possible because 6P messages are carried as Payload IEs. 1509 4. Requirements for 6top Scheduling Functions (SF) 1511 4.1. SF Identifier (SFID) 1513 Each SF has a 1-byte identifier. Section 6.2.5 defines the rules for 1514 applying for an SFID. 1516 4.2. Requirements for an SF 1518 The specification for an SF 1520 o MUST specify an identifier for that SF. 1521 o MUST specify the rule for a node to decide when to add/delete one 1522 or more cells to a neighbor. 1523 o MUST specify the rule for a Transaction source to select cells to 1524 add to the CellList field in the 6P ADD Request. 1525 o MUST specify the rule for a Transaction destination to select 1526 cells from CellList to add to its schedule. 1527 o MUST specify a value for the 6P Timeout, or a rule/equation to 1528 calculate it. 1529 o MUST specify the rule for ordering cells. 1530 o MUST specify a meaning for the "Metadata" field in the 6P ADD 1531 Request. 1532 o MUST specify the SF behavior of a node when it boots. 1533 o MUST specify how to handle a schedule inconsistency. 1534 o MUST specify what to do after an error has occurred (either the 1535 node sent a 6P Response with an error code, or received one). 1536 o MUST specify the list of statistics to gather. Example statistics 1537 include the number of transmitted frames to each neighbor. In 1538 case the SF requires no statistics to be gathered, the specific of 1539 the SF MUST explicitly state so. 1541 o SHOULD clearly state the application domain the SF is created for. 1542 o SHOULD contain examples which highlight normal and error 1543 scenarios. 1544 o SHOULD contain a list of current implementations, at least during 1545 the I-D state of the document, per [RFC6982]. 1546 o SHOULD contain a performance evaluation of the scheme, possibly 1547 through references to external documents. 1548 o SHOULD define the format of the SIGNAL command payload and its 1549 use. 1551 o MAY redefine the format of the CellList field. 1552 o MAY redefine the format of the CellOptions field. 1553 o MAY redefine the meaning of the CellOptions field. 1555 5. Security Considerations 1557 6P messages are carried inside 802.15.4 Payload Information Elements 1558 (IEs). Those Payload IEs are encrypted and authenticated at the link 1559 layer through CCM* [CCM-Star]. 6P benefits from the same level of 1560 security as any other Payload IE. The 6P protocol does not define 1561 its own security mechanisms. In particular, although a key 1562 management solution is out of scope of this document, the 6P protocol 1563 will benefit for the key management solution used in the network. 1565 The 6P protocol does not provide protection against DOS attacks. 1566 Example attacks include, not sending confirmation messages in 3-step 1567 transaction, sending wrongly formatted requests, etc. These cases 1568 SHOULD be handled by an appropriate policy, such as blacklisting the 1569 attacker after several attempts. The effect on the overall network 1570 is mostly localized to those two nodes, as communication happens in 1571 dedicated cells. 1573 6. IANA Considerations 1575 6.1. IETF IE Subtype '6P' 1577 This document adds the following number to the "IEEE Std 802.15.4 1578 IETF IE subtype IDs" registry defined by [RFC8137]: 1580 +--------------------+------+-----------+ 1581 | Subtype | Name | Reference | 1582 +--------------------+------+-----------+ 1583 | IANA_6TOP_SUBIE_ID | 6P | RFCXXXX | 1584 +--------------------+------+-----------+ 1586 Figure 33: IETF IE Subtype '6P'. 1588 6.2. 6TiSCH parameters sub-registries 1590 This section defines sub-registries within the "IPv6 over the TSCH 1591 mode of IEEE 802.15.4e (6TiSCH) parameters" registry, hereafter 1592 referred to as the "6TiSCH parameters" registry. Each sub-registry 1593 is described in a subsection. 1595 6.2.1. 6P Version Numbers 1597 The name of the sub-registry is "6P Version Numbers". 1599 A Note included in this registry should say: "In the 6top Protocol 1600 (6P) [RFCXXXX] there is a field to identify the version of the 1601 protocol. This field is 4 bits in size." 1603 Each entry in the sub-registry must include the Version in the range 1604 0-15, and a reference to the 6P version's documentation. 1606 The initial entry in this sub-registry is as follows: 1608 +---------+-----------+ 1609 | Version | Reference | 1610 +---------+-----------+ 1611 | 0 | RFCXXXX | 1612 +---------+-----------+ 1614 Figure 34: 6P Version Numbers. 1616 All other Version Numbers are Unassigned. 1618 The IANA policy for future additions to this sub-registry is "IETF 1619 Review or IESG Approval" as described in [RFC8126]. 1621 6.2.2. 6P Message Types 1623 The name of the sub-registry is "6P Message Types". 1625 A note included in this registry should say: "In the 6top Protocol 1626 (6P) version 0 [RFCXXXX], there is a field to identify the type of 1627 message. This field is 2 bits in size." 1628 Each entry in the sub-registry must include the Type in range 1629 b00-b11, the corresponding Name, and a reference to the 6P message 1630 type's documentation. 1632 Initial entries in this sub-registry are as follows: 1634 +------+--------------+-----------+ 1635 | Type | Name | Reference | 1636 +------+--------------+-----------+ 1637 | b00 | REQUEST | RFCXXXX | 1638 | b01 | RESPONSE | RFCXXXX | 1639 | b10 | CONFIRMATION | RFCXXXX | 1640 +------+--------------+-----------+ 1642 Figure 35: 6P Message Types. 1644 All other Message Types are Reserved. 1646 The IANA policy for future additions to this sub-registry is "IETF 1647 Review or IESG Approval" as described in [RFC8126]. 1649 6.2.3. 6P Command Identifiers 1651 The name of the sub-registry is "6P Command Identifiers". 1653 A Note included in this registry should say: "In the 6top Protocol 1654 (6P) version 0 [RFCXXXX], there is a Code field which is 8 bits in 1655 size. In a 6P Request, the value of this Code field is used to 1656 identify the command." 1658 Each entry in the sub-registry must include an Identifier in the 1659 range 0-255, the corresponding Name, and a reference to the 6P 1660 command identifier's documentation. 1662 Initial entries in this sub-registry are as follows: 1664 +------------+------------+-----------+ 1665 | Identifier | Name | Reference | 1666 +------------+------------+-----------+ 1667 | 0 | Reserved | | 1668 | 1 | ADD | RFCXXXX | 1669 | 2 | DELETE | RFCXXXX | 1670 | 3 | RELOCATE | RFCXXXX | 1671 | 4 | COUNT | RFCXXXX | 1672 | 5 | LIST | RFCXXXX | 1673 | 6 | SIGNAL | RFCXXXX | 1674 | 7 | CLEAR | RFCXXXX | 1675 | 8-254 | Unassigned | | 1676 | 255 | Reserved | | 1677 +------------+------------+-----------+ 1679 Figure 36: 6P Command Identifiers. 1681 The IANA policy for future additions to this sub-registry is "IETF 1682 Review or IESG Approval" as described in [RFC8126]. 1684 6.2.4. 6P Return Codes 1686 The name of the sub-registry is "6P Return Codes". 1688 A Note included in this registry should say: "In the 6top Protocol 1689 (6P) version 0 [RFCXXXX], there is a Code field which is 8 bits in 1690 size. In a 6P Response or 6P Confirmation, the value of this Code 1691 field is used to identify the return code." 1693 Each entry in the sub-registry must include a Code in the range 1694 0-255, the corresponding Name, the corresponding Description, and a 1695 reference to the 6P return code's documentation. 1697 Initial entries in this sub-registry are as follows: 1699 +------+-----------------+---------------------------+-----------+ 1700 | Code | Name | Description | Is Error? | 1701 +------+-----------------+---------------------------+-----------+ 1702 | 0 | RC_SUCCESS | operation succeeded | No | 1703 | 1 | RC_EOL | end of list | No | 1704 | 2 | RC_ERR | generic error | Yes | 1705 | 3 | RC_RESET | critical error, reset | Yes | 1706 | 4 | RC_ERR_VERSION | unsupported 6P version | Yes | 1707 | 5 | RC_ERR_SFID | unsupported SFID | Yes | 1708 | 6 | RC_ERR_SEQNUM | schedule inconsistency | Yes | 1709 | 7 | RC_ERR_CELLLIST | cellList error | Yes | 1710 | 8 | RC_ERR_BUSY | busy | Yes | 1711 | 9 | RC_ERR_LOCKED | cells are locked | Yes | 1712 +------+-----------------+---------------------------+-----------+ 1714 Figure 37: 6P Return Codes. 1716 All other Message Types are Unassigned. 1718 The IANA policy for future additions to this sub-registry is "IETF 1719 Review or IESG Approval" as described in [RFC8126]. 1721 6.2.5. 6P Scheduling Function Identifiers 1723 6P Scheduling Function Identifiers. 1725 A Note included in this registry should say: "In the 6top Protocol 1726 (6P) version 0 [RFCXXXX], there is a field to identify the scheduling 1727 function to handle the message. This field is 8 bits in size." 1729 Each entry in the sub-registry must include an SFID in the range 1730 0-255, the corresponding Name, and a reference to the 6P Scheduling 1731 Function's documentation. 1733 Initial entries in this sub-registry are as follows: 1735 +----+---------------------------------+----------------------------+ 1736 |SFID| Name | Reference | 1737 +----+---------------------------------+----------------------------+ 1738 | 0 | Minimal Scheduling Function | draft-chang-6tisch-msf | 1739 | | (MSF) | | 1740 +----+---------------------------------+----------------------------+ 1741 | 1 | Experimental Scheduling Function| draft-ietf-6tisch-6top-sfx | 1742 | | (SFX) | | 1743 +----+---------------------------------+----------------------------+ 1745 Figure 38: SF Identifiers (SFID). 1747 All other Message Types are Unassigned. 1749 The IANA policy for future additions to this sub-registry depends on 1750 the value of the SFID, as defined in Figure 39. These specifications 1751 must follow the guidelines of Section 4. 1753 +-----------+------------------------------+ 1754 | Range | Registration Procedures | 1755 +-----------+------------------------------+ 1756 | 0-127 | IETF Review or IESG Approval | 1757 | 128-255 | Expert Review | 1758 +-----------+------------------------------+ 1760 Figure 39: SF Identifier (SFID): Registration Procedure. 1762 6.2.6. 6P CellOptions bitmap 1764 The name of the sub-registry is "6P CellOptions bitmap". 1766 A Note included in this registry should say: "In the 6top Protocol 1767 (6P) version 0 [RFCXXXX], there is an optional CellOptions field 1768 which is 8 bits in size." 1770 Each entry in the sub-registry must include a bit position in the 1771 range 0-7, the corresponding Name, and a reference to the bit's 1772 documentation. 1774 Initial entries in this sub-registry are as follows: 1776 +-----+---------------+-----------+ 1777 | bit | Name | Reference | 1778 +-----+---------------+-----------+ 1779 | 0 | TX (Transmit) | RFCXXXX | 1780 | 1 | RX (Receive) | RFCXXXX | 1781 | 2 | SHARED | RFCXXXX | 1782 | 3-7 | Reserved | | 1783 +-----+---------------+-----------+ 1785 Figure 40: 6P CellOptions bitmap. 1787 All other Message Types are Reserved. 1789 The IANA policy for future additions to this sub-registry is "IETF 1790 Review or IESG Approval" as described in [RFC8126]. 1792 7. References 1794 7.1. Normative References 1796 [IEEE802154] 1797 IEEE standard for Information Technology, "IEEE Std 1798 802.15.4-2015 - IEEE Standard for Low-Rate Wireless 1799 Personal Area Networks (WPANs)", October 2015. 1801 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1802 Requirement Levels", BCP 14, RFC 2119, 1803 DOI 10.17487/RFC2119, March 1997, 1804 . 1806 [RFC8137] Kivinen, T. and P. Kinney, "IEEE 802.15.4 Information 1807 Element for the IETF", RFC 8137, DOI 10.17487/RFC8137, May 1808 2017, . 1810 7.2. Informative References 1812 [CCM-Star] 1813 Struik, R., "Formal Specification of the CCM* Mode of 1814 Operation, IEEE P802.15 Working Group for Wireless 1815 Personal Area Networks (WPANs).", September 2005. 1817 [OpenWSN] Watteyne, T., Vilajosana, X., Kerkez, B., Chraim, F., 1818 Weekly, K., Wang, Q., Glaser, S., and K. Pister, "OpenWSN: 1819 a Standards-Based Low-Power Wireless Development 1820 Environment", Transactions on Emerging Telecommunications 1821 Technologies , August 2012. 1823 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1824 Code: The Implementation Status Section", RFC 6982, 1825 DOI 10.17487/RFC6982, July 2013, 1826 . 1828 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 1829 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 1830 Internet of Things (IoT): Problem Statement", RFC 7554, 1831 DOI 10.17487/RFC7554, May 2015, 1832 . 1834 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1835 Writing an IANA Considerations Section in RFCs", BCP 26, 1836 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1837 . 1839 [RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal 1840 IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) 1841 Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180, 1842 May 2017, . 1844 Appendix A. Recommended Structure of an SF Specification 1846 The following section structure for a SF document is RECOMMENDED: 1848 o Introduction 1849 o Scheduling Function Identifier 1850 o Rules for Adding/Deleting Cells 1851 o Rules for CellList 1852 o 6P Timeout Value 1853 o Rule for Ordering Cells 1854 o Meaning of the Metadata Field 1855 o Node Behavior at Boot 1856 o Schedule Inconsistency Handling 1857 o 6P Error Handling 1858 o Examples 1859 o Implementation Status 1860 o Security Considerations 1861 o IANA Considerations 1863 Authors' Addresses 1865 Qin Wang (editor) 1866 Univ. of Sci. and Tech. Beijing 1867 30 Xueyuan Road 1868 Beijing, Hebei 100083 1869 China 1871 Email: wangqin@ies.ustb.edu.cn 1873 Xavier Vilajosana 1874 Universitat Oberta de Catalunya 1875 156 Rambla Poblenou 1876 Barcelona, Catalonia 08018 1877 Spain 1879 Email: xvilajosana@uoc.edu 1880 Thomas Watteyne 1881 Analog Devices 1882 32990 Alvarado-Niles Road, Suite 910 1883 Union City, CA 94587 1884 USA 1886 Email: thomas.watteyne@analog.com