idnits 2.17.1 draft-ietf-6tisch-6top-protocol-10.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 5, 2018) is 2215 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 1722, but not defined == Missing Reference: 'TEMPORARY' is mentioned on line 1884, but not defined -- 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: September 6, 2018 Universitat Oberta de Catalunya 6 T. Watteyne 7 Analog Devices 8 March 5, 2018 10 6top Protocol (6P) 11 draft-ietf-6tisch-6top-protocol-10 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 6P 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 September 6, 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 . . . . . . . . . . . . . . . . . . . . . 10 76 3.2.1. 6top Information Element (IE) . . . . . . . . . . . . 10 77 3.2.2. Generic 6P Message Format . . . . . . . . . . . . . . 10 78 3.2.3. 6P CellOptions . . . . . . . . . . . . . . . . . . . 11 79 3.2.4. 6P CellList . . . . . . . . . . . . . . . . . . . . . 13 80 3.3. 6P Commands and Operations . . . . . . . . . . . . . . . 14 81 3.3.1. Adding Cells . . . . . . . . . . . . . . . . . . . . 14 82 3.3.2. Deleting Cells . . . . . . . . . . . . . . . . . . . 16 83 3.3.3. Relocating Cells . . . . . . . . . . . . . . . . . . 17 84 3.3.4. Counting Cells . . . . . . . . . . . . . . . . . . . 22 85 3.3.5. Listing Cells . . . . . . . . . . . . . . . . . . . . 23 86 3.3.6. Clearing the Schedule . . . . . . . . . . . . . . . . 25 87 3.3.7. Generic Signaling Between SFs . . . . . . . . . . . . 26 88 3.4. Protocol Functional Details . . . . . . . . . . . . . . . 26 89 3.4.1. Version Checking . . . . . . . . . . . . . . . . . . 26 90 3.4.2. SFID Checking . . . . . . . . . . . . . . . . . . . . 27 91 3.4.3. Concurrent 6P Transactions . . . . . . . . . . . . . 27 92 3.4.4. 6P Timeout . . . . . . . . . . . . . . . . . . . . . 28 93 3.4.5. Aborting a 6P Transaction . . . . . . . . . . . . . . 28 94 3.4.6. SeqNum Management . . . . . . . . . . . . . . . . . . 28 95 3.4.7. Handling Error Responses . . . . . . . . . . . . . . 34 96 3.5. Security . . . . . . . . . . . . . . . . . . . . . . . . 34 97 4. Requirements for 6top Scheduling Functions (SF) . . . . . . . 34 98 4.1. SF Identifier (SFID) . . . . . . . . . . . . . . . . . . 34 99 4.2. Requirements for an SF . . . . . . . . . . . . . . . . . 34 100 5. Security Considerations . . . . . . . . . . . . . . . . . . . 35 101 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 102 6.1. IETF IE Subtype '6P' . . . . . . . . . . . . . . . . . . 35 103 6.2. 6TiSCH parameters sub-registries . . . . . . . . . . . . 36 104 6.2.1. 6P Version Numbers . . . . . . . . . . . . . . . . . 36 105 6.2.2. 6P Message Types . . . . . . . . . . . . . . . . . . 36 106 6.2.3. 6P Command Identifiers . . . . . . . . . . . . . . . 37 107 6.2.4. 6P Return Codes . . . . . . . . . . . . . . . . . . . 38 108 6.2.5. 6P Scheduling Function Identifiers . . . . . . . . . 39 109 6.2.6. 6P CellOptions bitmap . . . . . . . . . . . . . . . . 40 110 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 111 7.1. Normative References . . . . . . . . . . . . . . . . . . 41 112 7.2. Informative References . . . . . . . . . . . . . . . . . 41 113 Appendix A. Recommended Structure of an SF Specification . . . . 42 114 Appendix B. Implementation Status . . . . . . . . . . . . . . . 42 115 Appendix C. [TEMPORARY] Changelog . . . . . . . . . . . . . . . 43 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 118 1. Introduction 120 All communication in a 6TiSCH network is orchestrated by a schedule 121 [RFC7554]. The schedule is composed of cells, each identified by a 122 [slotOffset,channelOffset]. This specification defines the 6top 123 Protocol (6P), terminated by the 6TiSCH Operation sublayer (6top). 124 6P allows a node to communicate with a neighbor node to add/delete 125 TSCH cells in each other. This results in distributed schedule 126 management in a 6TiSCH network. The 6top layer terminates the 6top 127 Protocol, and runs one of more 6top Scheduling Functions (SFs) that 128 decide when to add/delete cells and trigger 6P Transactions. The SF 129 is out of scope of this document but the requirements for an SF are 130 defined here. 132 (R) 133 / \ 134 / \ 135 (B)-----(C) 136 | | 137 | | 138 (A) (D) 140 Figure 1: A simple 6TiSCH network. 142 The example network depicted in Figure 1 is used to describe the 143 interaction between nodes. We consider the canonical case where node 144 "A" issues 6P requests to node "B". We keep this example throughout 145 this document. Throughout the document, node A always represents the 146 node that issues a 6P request; node B the node that receives this 147 request. 149 We consider that node A monitors the communication cells it has in 150 its schedule to node B: 152 o If node A determines that the number of link-layer frames it is 153 sending to B per unit of time is larger than the capacity offered 154 by the TSCH cells it has scheduled to B, it triggers a 6P 155 Transaction with node B to add one or more cells to the TSCH 156 schedule of both nodes. 157 o If the traffic is lower than the capacity, node A triggers a 6P 158 Transaction with node B to delete one or more cells in the TSCH 159 schedule of both nodes. 160 o Node A MAY also monitor statistics to determine whether collisions 161 are happening on a particular cell to node B. If this feature is 162 enabled, node A communicates with node B to "relocate" the cell 163 which suffers collisions to a different [slotOffset,channelOffset] 164 location in the TSCH schedule. 166 This results in distributed schedule management in a 6TiSCH network. 168 The 6top Scheduling Function (SF) defines when to add/delete a cell 169 to a neighbor. Different applications require different SFs, so the 170 SF is left out of scope of this document. Different SFs are expected 171 to be defined in future companion specifications. A node MAY 172 implement multiple SFs and run them at the same time. At least one 173 SF MUST be running. The SFID field contained in all 6P messages 174 allows a node to invoke the appropriate SF on a per-6P Transaction 175 basis. 177 Section 2 describes the 6TiSCH Operation Sublayer (6top). Section 3 178 defines the 6top Protocol (6P). Section 4 provides guidelines on how 179 to define an SF. 181 2. 6TiSCH Operation Sublayer (6top) 183 As depicted in Figure 2, the 6TiSCH Operation Sublayer (6top) is the 184 next higher layer to the IEEE Std 802.15.4 TSCH medium access control 185 (MAC) layer [IEEE802154]. We use "802.15.4" as a short version of 186 "IEEE Std 802.15.4" in this document. 188 . 189 | . | 190 | higher layers | 191 +------------------------------------------+ 192 | 6top | 193 +------------------------------------------+ 194 | IEEE Std 802.15.4 TSCH | 195 | . | 196 . 198 Figure 2: The 6top sublayer in the protocol stack. 200 The roles of the 6top sublayer are to: 202 o Terminate the 6top Protocol (6P), which allows neighbor nodes to 203 communicate to add/delete cells to one another. 204 o Run one or multiple 6top Scheduling Functions (SFs), which define 205 the rules that decide when to add/delete cells. 207 2.1. Hard/Soft Cells 209 Each cell in the schedule is either "hard" or "soft": 211 o a soft cell can be read, added, deleted or updated by 6top. 212 o a hard cell is read-only for 6top. 214 In the context of this specification, all the cells used by 6top are 215 soft cells. Hard cells can be used for example when "hard-coding" a 216 schedule [RFC8180]. 218 2.2. Using 6P with the Minimal 6TiSCH Configuration 220 6P MAY be used alongside the Minimal 6TiSCH Configuration [RFC8180]. 221 In this case, it is RECOMMENDED to use 2 slotframes, as depicted in 222 Figure 3: 224 o Slotframe 0 is used for traffic defined in the Minimal 6TiSCH 225 Configuration. In Figure 3, this slotframe is 5 slots long, but 226 the slotframe can be shorter or longer. 227 o 6P allocates cells from Slotframe 1. In Figure 3, Slotframe 1 is 228 10 slots long, but the slotframe can be shorter or longer. 230 | 0 1 2 3 4 | 0 1 2 3 4 | 231 +------------------------+------------------------+ 232 Slotframe 0 | | | | | | | | | | | 233 5 slots long | EB | | | | | EB | | | | | 234 (Minimal 6TiSCH) | | | | | | | | | | | 235 +-------------------------------------------------+ 237 | 0 1 2 3 4 5 6 7 8 9 | 238 +-------------------------------------------------+ 239 Slotframe 1 | | | | | | | | | | | 240 10 slots long | |A->B| | | | | | |B->A| | 241 (6P) | | | | | | | | | | | 242 +-------------------------------------------------+ 244 Figure 3: 2-slotframe structure when using 6P alongside the Minimal 245 6TiSCH Configuration. 247 The Minimal 6TiSCH Configuration cell SHOULD be allocated from a 248 slotframe of higher priority than the slotframe used by 6P for 249 dynamic cell allocation. This way, dynamically allocated cells 250 cannot "mask" the cells used by the Minimal 6TiSCH Configuration. 251 6top MAY support additional slotframes; how to use additional 252 slotframes is out of scope for this document. 254 3. 6top Protocol (6P) 256 The 6top Protocol (6P) enables two neighbor nodes to add/delete/ 257 relocate cells in their TSCH schedule. Conceptually, two neighbor 258 nodes "negotiate" the location of the cells to add, delete, or 259 relocate in their TSCH schedule. 261 3.1. 6P Transactions 263 We call "6P Transaction" a complete negotiation between two neighbor 264 nodes. A 6P Transaction starts when a node wishes to add/delete/ 265 relocate one or more cells with one of its neighbors. A 6P 266 Transaction ends when the cell(s) have been added/deleted/relocated 267 in the schedule of both nodes, or when the 6P Transaction has failed. 269 6P messages exchanged between nodes A and B during a 6P Transaction 270 SHOULD be exchanged on non-shared unicast cells ("dedicated" cells) 271 between A and B. If no dedicated cells are scheduled between nodes A 272 and B, shared cells MAY be used. 274 Keeping consistency between the schedules of the two neighbor nodes 275 is important. A loss of consistency can cause loss of connectivity. 276 One example is when node A has a transmit cell to node B, but node B 277 does not have the corresponding reception cell. To verify 278 consistency, neighbor nodes maintain a Sequence Number (SeqNum). 279 Neighbor nodes exchange the SeqNum as part of each 6P Transaction to 280 detect possible inconsistency. This mechanism is explained in 281 Section 3.4.6.2. 283 An implementation MUST include a mechanism to associate each 284 scheduled cell with the SF that scheduled it. This mechanism is 285 implementation-specific and out of scope of this document. 287 A 6P Transaction can consist of 2 or 3 steps. A 2-step transaction 288 is used when node A selects the cells to be allocated. A 3-step 289 transaction is used when node B selects the cells to be allocated. 290 An SF MUST specify whether to use 2-step transactions, 3-step 291 transactions, or both. 293 We illustrate 2-step and 3-step transactions using the topology in 294 Figure 1. 296 3.1.1. 2-step 6P Transaction 298 Figure 4 shows an example 2-step 6P Transaction. In a 2-step 299 transaction, node A selects the candidate cells. Several elements 300 are left out to simplify understanding. 302 +----------+ +----------+ 303 | Node A | | Node B | 304 +----+-----+ +-----+----+ 305 | | 306 | 6P ADD Request | 307 | Type = REQUEST | 308 | Code = ADD | 309 | SeqNum = 123 | 310 | NumCells = 2 | 311 | CellList = [(1,2),(2,2),(3,5)] | 312 |-------------------------------------->| 313 | L2 ACK | 314 6P Timeout |<- - - - - - - - - - - - - - - - - - - | 315 | | | 316 | | 6P Response | 317 | | Type = RESPONSE | 318 | | Code = RC_SUCCESS | 319 | | SeqNum = 123 | 320 | | CellList = [(2,2),(3,5)] | 321 X |<--------------------------------------| 322 | L2 ACK | 323 | - - - - - - - - - - - - - - - - - - ->| 324 | | 325 | | 327 Figure 4: An example 2-step 6P Transaction. 329 In this example, the 2-step transaction occurs as follows: 331 1. The SF running on node A determines that 2 extra cells need to be 332 scheduled to node B. 333 2. The SF running on node A selects 3 candidate cells. 334 3. Node A sends a 6P ADD Request to node B, indicating it wishes to 335 add 2 cells (the "NumCells" value), and specifying the list of 3 336 candidate cells (the "CellList" value). Each cell in the 337 CellList is a [slotOffset,channelOffset] tuple. This 6P ADD 338 Request is link-layer acknowledged by node B (labeled "L2 ACK" in 339 Figure 4). 340 4. After having successfully sent the 6P ADD Request, Node A starts 341 a 6P Timeout to abort the 6P Transaction in case no response is 342 received from 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 sends back a 6P Response 345 to node A, indicating the cells it has selected. The response is 346 link-layer acknowledged by node A. 347 6. Upon completion of this 6P Transaction, 2 cells from A to B have 348 been added to the TSCH schedule of both nodes A and B. 350 3.1.2. 3-step 6P Transaction 352 Figure 5 shows an example 3-step 6P Transaction. In a 3-step 353 transaction, node B selects the candidate cells. Several elements 354 are left out to simplify understanding. 356 +----------+ +----------+ 357 | Node A | | Node B | 358 +----+-----+ +-----+----+ 359 | | 360 | 6P ADD Request | 361 | Type = REQUEST | 362 | Code = ADD | 363 | SeqNum = 178 | 364 | NumCells = 2 | 365 | CellList = [] | 366 |-------------------------------------->| 367 | L2 ACK | 368 6P Timeout |<- - - - - - - - - - - - - - - - - - - | 369 | | | 370 | | 6P Response | 371 | | Type = RESPONSE | 372 | | Code = RC_SUCCESS | 373 | | SeqNum = 178 | 374 | | CellList = [(1,2),(2,2),(3,5)] | 375 X |<--------------------------------------| 376 | L2 ACK | 377 | - - - - - - - - - - - - - - - - - - ->| 6P Timeout 378 | | | 379 | 6P Confirmation | | 380 | Type = CONFIRMATION | | 381 | Code = RC_SUCCESS | | 382 | SeqNum = 178 | | 383 | CellList = [(2,2),(3,5)] | | 384 |-------------------------------------->| X 385 | L2 ACK | 386 |<- - - - - - - - - - - - - - - - - - - | 387 | | 389 Figure 5: An example 3-step 6P Transaction. 391 In this example, the 3-step transaction occurs as follows: 393 1. The SF running on node A determines that 2 extra cells need to be 394 scheduled to node B, but does not select candidate cells. 395 2. Node A sends a 6P ADD Request to node B, indicating it wishes to 396 add 2 cells (the "NumCells" value), with an empty "CellList". 397 This 6P ADD Request is link-layer acknowledged by node B. 399 3. After having successfully sent the 6P ADD Request, Node A starts 400 a 6P Timeout to abort the transaction in case no 6P Response is 401 received. 402 4. The SF running on node B selects 3 candidate cells. Node B sends 403 back a 6P Response to node A, indicating the 3 cells it selected. 404 The response is link-layer acknowledged by node A. 405 5. After having successfully sent the 6P Response, Node B starts a 406 6P Timeout to abort the transaction in case no 6P Confirmation is 407 received. 408 6. The SF running on node A selects 2 cells from the CellList field 409 in the 6P Response. Node A sends back a 6P Confirmation to node 410 B, indicating the cells it selected. The confirmation is link- 411 layer acknowledged by node B. 412 7. Upon completion of this 6P Transaction, 2 cells from A to B have 413 been added to the TSCH schedule of both nodes A and B. 415 3.2. Message Format 417 3.2.1. 6top Information Element (IE) 419 6P messages travel over a single hop. 6P messages are carried as 420 payload of an 802.15.4 Payload Information Element (IE) [IEEE802154]. 421 The messages are encapsulated with the Payload IE Header. The Group 422 ID is set to the IETF IE value defined in [RFC8137]. The content is 423 encapsulated by a SubType ID, as defined in [RFC8137]. 425 Since 6P messages are carried in IEs, IEEE bit/byte ordering applies. 426 Bits within each field in the 6top IE are numbered from 0 (leftmost 427 and least significant) to k-1 (rightmost and most significant), where 428 the length of the field is k bits. Fields that are longer than a 429 single octet are copied to the packet in the order from the octet 430 containing the lowest numbered bits to the octet containing the 431 highest numbered bits (little endian). 433 This document defines the "6top IE", a SubType of the IETF IE defined 434 in [RFC8137], with subtype ID IANA_6TOP_SUBIE_ID. The SubType 435 Content of the "6top IE" is defined in Section 3.2.2. The length of 436 the "6top IE" content is variable. 438 3.2.2. Generic 6P Message Format 440 All 6P messages follow the generic format shown in Figure 6. 442 1 2 3 443 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 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 |Version| T | R | Code | SFID | SeqNum | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | Other Fields... 448 +-+-+-+-+-+-+-+-+- 450 Figure 6: Generic 6P Message Format. 452 6P Version (Version): The version of the 6P protocol. Only version 453 0 is defined in this document. Future specifications MAY 454 define further versions of the 6P protocol. 455 Type (T): Type of message. The message types are defined in 456 Section 6.2.2. 457 Reserved (R): Reserved bits. These two bits SHOULD be set to zero 458 when sending the message and MUST be ignored upon reception. 459 Code: The Code field contains a 6P Command Identifier when the 6P 460 message is of Type REQUEST. Section 6.2.3 lists the 6P command 461 identifiers. The Code field contains a 6P Return Code when the 462 6P message is of Type RESPONSE or CONFIRMATION. Section 6.2.4 463 lists the 6P Return Codes. The same return codes are used in 464 both 6P Response and 6P Confirmation messages. 465 6top Scheduling Function Identifier (SFID): The identifier of the SF 466 to use to handle this message. The SFID is defined in 467 Section 4.1. 468 SeqNum: Sequence number associated with the 6P Transaction, used to 469 match the 6P Request, 6P Response and 6P Confirmation of the 470 same 6P Transaction. The value of SeqNum MUST be different at 471 each new 6P request issued to the same neighbor. The SeqNum is 472 also used to ensure consistency between the schedules of the 473 two neighbors. Section 3.4.6 details how the SeqNum is 474 managed. 475 Other Fields: The list of other fields and how they are used is 476 detailed in Section 3.3. 478 3.2.3. 6P CellOptions 480 An 8-bit 6P CellOptions bitmap is present in the following 6P 481 requests: ADD, DELETE, COUNT, LIST, RELOCATE. 483 o In the 6P ADD request, the 6P CellOptions bitmap is used to 484 specify what type of cell to add. 485 o In the 6P DELETE request, the 6P CellOptions bitmap is used to 486 specify what type of cell to delete. 487 o In the 6P COUNT and the 6P LIST requests, the 6P CellOptions 488 bitmap is used as a selector of a particular type of cells. 490 o In the 6P RELOCATE request, the 6P CellOptions bitmap is used to 491 specify what type of cell to relocate. 493 The contents of the 6P CellOptions bitmap apply to all elements in 494 the CellList field. Section 6.2.6 contains the RECOMMENDED format of 495 the 6P CellOptions bitmap. Figure 7 contains the RECOMMENDED meaning 496 of the 6P CellOptions bitmap for the 6P COUNT and 6P LIST requests. 497 Figure 8 contains the RECOMMENDED meaning of the 6P CellOptions 498 bitmap for the 6P ADD/DELETE/RELOCATE requests. 500 Note: assuming node A issues the 6P command to node B. 501 +-------------+-----------------------------------------------------+ 502 | CellOptions | the cells B selects from its schedule when | 503 | Value | receiving a 6P COUNT or LIST Request from A, | 504 | | from all the cells B has scheduled with A | 505 +-------------+-----------------------------------------------------+ 506 |TX=0,RX=0,S=0| all cells | 507 +-------------+-----------------------------------------------------+ 508 |TX=1,RX=0,S=0| all cells marked as RX | 509 +-------------+-----------------------------------------------------+ 510 |TX=0,RX=1,S=0| all cells marked as TX | 511 +-------------+-----------------------------------------------------+ 512 |TX=1,RX=1,S=0| all cells marked as TX and RX | 513 +-------------+-----------------------------------------------------+ 514 |TX=0,RX=0,S=1| all cells marked as SHARED | 515 +-------------+-----------------------------------------------------+ 516 |TX=1,RX=0,S=1| all cells marked as RX and SHARED | 517 +-------------+-----------------------------------------------------+ 518 |TX=0,RX=1,S=1| all cells marked as TX and SHARED | 519 +-------------+-----------------------------------------------------+ 520 |TX=1,RX=1,S=1| all cells marked as TX and RX and SHARED | 521 +-------------+-----------------------------------------------------+ 523 Figure 7: Meaning of the 6P CellOptions bitmap for the 6P COUNT and 524 LIST requests. 526 Note: assuming node A issues the 6P command to node B. 527 +-------------+-----------------------------------------------------+ 528 | CellOptions | the type of cells B adds/deletes/relocates to its | 529 | Value | schedule when receiving a 6P ADD/DELETE/RELOCATE | 530 | | Request from A. | 531 +-------------+-----------------------------------------------------+ 532 |TX=0,RX=0,S=0| Does not apply. RC_ERR is returned. | 533 +-------------+-----------------------------------------------------+ 534 |TX=1,RX=0,S=0| add/delete/relocate RX cells at B. TX cells at A. | 535 +-------------+-----------------------------------------------------+ 536 |TX=0,RX=1,S=0| add/delete/relocate TX cells at B. RX cells at A. | 537 +-------------+-----------------------------------------------------+ 538 |TX=1,RX=1,S=0| add/delete/relocate TXRX cells at B.TXRX cells at A.| 539 +-------------+-----------------------------------------------------+ 540 |TX=0,RX=0,S=1| Does not apply. RC_ERR is returned. | 541 +-------------+-----------------------------------------------------+ 542 |TX=1,RX=0,S=1| add/delete/relocate RX Shared cells at B. | 543 | | TX Shared cells at A. | 544 +-------------+-----------------------------------------------------+ 545 |TX=0,RX=1,S=1| add/delete/relocate TX Shared cells at B. | 546 | | RX Shared cells at A. | 547 +-------------+-----------------------------------------------------+ 548 |TX=1,RX=1,S=1| add/delete/relocate TXRX Shared cells at B. | 549 | | TXRX Shared cells at A. | 550 +-------------+-----------------------------------------------------+ 552 Figure 8: Meaning of the 6P CellOptions bitmap for the 6P ADD, 553 DELETE, RELOCATE requests. 555 The CellOptions is an opaque set of bits, sent unmodified to the SF. 556 The SF MAY redefine the format and meaning of the CellOptions field. 558 3.2.4. 6P CellList 560 A CellList field MAY be present in a 6P ADD Request, a 6P DELETE 561 Request, a 6P RELOCATE Request, a 6P Response or a 6P Confirmation. 562 It is composed of a concatenation of zero, one or more 6P Cells as 563 defined in Figure 9. The contents of the CellOptions field specify 564 the options associated with all cells in the CellList. This 565 necessarily means that the same options are associated with all cells 566 in the CellList. 568 The 6P Cell is a 4-byte field, its RECOMMENDED format is: 570 1 2 3 571 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 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | slotOffset | channelOffset | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 Figure 9: 6P Cell Format. 578 slotOffset: The slot offset of the cell. 579 channelOffset: The channel offset of the cell. 581 The CellList is an opaque set of bytes, sent unmodified to the SF. 582 The SF MAY redefine the format of the CellList field. 584 3.3. 6P Commands and Operations 586 3.3.1. Adding Cells 588 Cells are added by using the 6P ADD command. The Type field (T) is 589 set to REQUEST. The Code field is set to ADD. Figure 10 defines the 590 format of a 6P ADD Request. 592 1 2 3 593 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 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 |Version| T | R | Code | SFID | SeqNum | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | Metadata | CellOptions | NumCells | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | CellList ... 600 +-+-+-+-+-+-+-+-+- 602 Figure 10: 6P ADD Request Format. 604 Metadata: Used as extra signaling to the SF. The contents of the 605 Metadata field is an opaque set of bytes passed unmodified to 606 the SF. The meaning of this field depends on the SF, and is 607 out of scope of this document. For example, Metadata can 608 specify in which slotframe to add the cells. 609 CellOptions: Indicates the options to associate with the cells to be 610 added. If more than one cell is added (NumCells>1), the same 611 options are associated with each one. This necessarily means 612 that, if node A needs to add multiple cells with different 613 options, it needs to initiate multiple 6P ADD Transactions. 614 NumCells: The number of additional cells the sender wants to 615 schedule to the receiver. 616 CellList: A list of 0, 1 or multiple candidate cells. 618 Figure 11 defines the format of a 6P ADD Response and Confirmation. 620 1 2 3 621 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 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 |Version| T | R | Code | SFID | SeqNum | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 | CellList ... 626 +-+-+-+-+-+-+-+-+- 628 Figure 11: 6P ADD Response and Confirmation Formats. 630 CellList: A list of 0, 1 or multiple 6P Cells. 632 Consider the topology in Figure 1 where the SF on node A decides to 633 add NumCells cells to node B. 635 Node A's SF selects NumCandidate cells from its schedule. These are 636 cells that are candidates to be scheduled with node B. The 637 CellOptions field specifies the type of these cells. NumCandidate 638 MUST be larger or equal to NumCells. How many cells node A selects 639 (NumCandidate) and how that selection is done is specified in the SF 640 and out of scope of this document. Node A sends a 6P ADD Request to 641 node B which contains the CellOptions, the value of NumCells and a 642 selection of NumCandidate cells in the CellList. In case the 643 NumCandidate cells do not fit in a single packet, this operation MUST 644 be split into multiple independent 6P ADD Requests, each for a subset 645 of the number of cells that eventually need to be added. 647 Upon receiving the request, node B's SF verifies which of the cells 648 in the CellList it can install in node B's schedule, following the 649 specified CellOptions field. How that selection is done is specified 650 in the SF and out of scope of this document. The verification can 651 succeed (NumCells cells from the CellList can be used), fail (none of 652 the cells from the CellList can be used) or partially succeed (less 653 than NumCells cells from the CellList can be used). In all cases, 654 node B MUST send a 6P Response with return code set to RC_SUCCESS, 655 and which specifies the list of cells that were scheduled following 656 the CellOptions field. That can contain 0 elements (fail), NumCells 657 elements (succeeded) or between 0 and NumCells elements (partially 658 succeeded). 660 Upon receiving the response, node A adds the cells specified in the 661 CellList according to the request CellOptions field. 663 3.3.2. Deleting Cells 665 Cells are deleted by using the 6P DELETE command. The Type field (T) 666 is set to REQUEST. The Code field is set to DELETE. Figure 12 667 defines the format of a 6P DELETE Request. 669 1 2 3 670 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 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 |Version| T | R | Code | SFID | SeqNum | 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 | Metadata | CellOptions | NumCells | 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 | CellList ... 677 +-+-+-+-+-+-+-+-+- 679 Figure 12: 6P DELETE Request Format. 681 Metadata: Same usage as for the 6P ADD command, see Section 3.3.1. 682 Its format is the same as that in 6P ADD command, but its 683 contents could be different. 684 CellOptions: Indicates the options that need to be associated to the 685 cells to delete. Only the cells matching the CellOptions are 686 deleted. 687 NumCells: The number of cells from the specified CellList the sender 688 wants to delete from the schedule of both sender and receiver. 689 CellList: A list of 0, 1 or multiple 6P Cells. 691 Figure 13 defines the format of a 6P DELETE Response and 692 Confirmation. 694 1 2 3 695 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 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 |Version| T | R | Code | SFID | SeqNum | 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 | CellList ... 700 +-+-+-+-+-+-+-+-+- 702 Figure 13: 6P DELETE Response and Confirmation Formats. 704 CellList: A list of 0, 1 or multiple 6P Cells. 706 The behavior for deleting cells is equivalent to that of adding cells 707 except that: 709 o The nodes delete the cells they agree upon rather than adding 710 them. 712 o All cells in the CellList MUST already be scheduled between the 713 two nodes and MUST match the CellOptions field. If node A puts 714 cells in its CellList that are not already scheduled between the 715 two nodes and match the CellOptions field, node B MUST reply with 716 a RC_ERR_CELLLIST return code. 717 o If the CellList in the 6P Request is empty, the SF on the 718 receiving node SHOULD delete any cell from the sender, as long as 719 it matches the CellOptions field. 720 o The CellList in a 6P Request (2-step transaction) or 6P Response 721 (3-step transaction) MUST either be empty, contain exactly 722 NumCells cells, or more than NumCells cells. The case where the 723 CellList is not empty but contains less than NumCells cells is not 724 supported. 726 3.3.3. Relocating Cells 728 Cell relocation consists in moving a cell to a different 729 [slotOffset,channelOffset] location in the schedule. The Type field 730 (T) is set to REQUEST. The Code is set to RELOCATE. Figure 14 731 defines the format of a 6P RELOCATE Request. 733 1 2 3 734 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 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 |Version| T | R | Code | SFID | SeqNum | 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 | Metadata | CellOptions | NumCells | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | Relocation CellList ... 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 742 | Candidate CellList ... 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 745 Figure 14: 6P RELOCATE Request Format. 747 Metadata: Same usage as for the 6P ADD command, see Section 3.3.1. 748 CellOptions: Indicates the options that need to be associated to the 749 relocated cells. 750 NumCells: The number of cells to relocate, which MUST be equal or 751 greater than 1. 752 Relocation CellList: The list of NumCells 6P Cells to relocate. 753 Candidate CellList: A list of NumCandidate candidate cells for node 754 B to pick from. NumCandidate MUST be 0, equal to NumCells, or 755 greater than NumCells. 757 In a 2-step 6P RELOCATE Transaction, node A specifies both the cells 758 it needs to relocate, and the list of candidate cells to relocate to. 760 The Relocation CellList MUST contain exactly NumCells entries. The 761 Candidate CellList MUST contain at least NumCells entries. 763 In a 3-step 6P RELOCATE Transaction, node A only specifies the cells 764 it needs to relocate, but not the list of candidate cells to relocate 765 to. The Candidate CellList MUST therefore be empty. 767 Figure 15 defines the format of a 6P RELOCATE Response and 768 Confirmation. 770 1 2 3 771 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 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 |Version| T | R | Code | SFID | SeqNum | 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 | CellList ... 776 +-+-+-+-+-+-+-+-+- 778 Figure 15: 6P RELOCATE Response and Confirmation Formats. 780 CellList: A list of 0, 1 or multiple 6P Cells. 782 Node A's SF wants to relocate NumCells cells. Node A creates a 6P 783 RELOCATE Request, and indicates the cells to relocate in the 784 Relocation CellList. It also selects NumCandidate cells from its 785 schedule as candidate cells for node B, and puts those in the 786 Candidate CellList. The CellOptions field specifies the type of the 787 cell(s) to relocate. NumCandidate MUST be larger or equal to 788 NumCells. How many cells it selects (NumCandidate) and how that 789 selection is done is specified in the SF and out of scope of this 790 document. Node A sends the 6P RELOCATE Request to node B. 792 Upon receiving the request, Node B checks if the length of the 793 Candidate CellList is larger or equal to NumCells. Node B's SF 794 verifies that all the cells in the Relocation CellList are indeed 795 scheduled with node A, and are associate the options specified in the 796 CellOptions field. If that check fails, node B MUST send a 6P 797 Response to node A with return code RC_ERR_CELLLIST. If that check 798 passes, node B's SF verifies which of the cells in the Candidate 799 CellList it can install in its schedule. How that selection is done 800 is specified in the SF and out of scope of this document. That 801 verification on Candidate CellList can succeed (NumCells cells from 802 the Candidate CellList can be used), fail (none of the cells from the 803 Candidate CellList can be used) or partially succeed (less than 804 NumCells cells from the Candidate CellList can be used). In all 805 cases, node B MUST send a 6P Response with return code set to 806 RC_SUCCESS, and which specifies the list of cells that were scheduled 807 following the CellOptions field. That can contain 0 elements (when 808 the verification failed), NumCells elements (succeeded) or between 0 809 and NumCells elements (partially succeeded). If N < NumCells cells 810 appear in the CellList, this means first N cells in the Relocation 811 CellList have been relocated, the remainder have not. 813 Upon receiving the response with Code RC_SUCCESS, node A relocates 814 the cells specified in Relocation CellList of its RELOCATE Request to 815 the new location specified in the CellList of the 6P Response. In 816 case the received Response Code is RC_ERR_CELLLIST. The transaction 817 is aborted and no cell is relocated. 819 Figure 16 shows an example of a successful 2-step 6P RELOCATION 820 Transaction. 822 +----------+ +----------+ 823 | Node A | | Node B | 824 +----+-----+ +-----+----+ 825 | | 826 | 6P RELOCATE Request | 827 | Type = REQUEST | 828 | Code = RELOCATE | 829 | SeqNum = 11 | 830 | NumCells = 2 | 831 | R.CellList = [(1,2),(2,2)] | 832 | C.CellList = [(3,3),(4,3),(5,3)] | 833 |-------------------------------------->| 834 | L2 ACK | 835 |<- - - - - - - - - - - - - - - - - - - | B relocates 836 | | (1,2)->(5,3) 837 | | and 838 | 6P Response | (2,2)->(3,3) 839 | Code = RC_SUCCESS | 840 | SeqNum = 11 | 841 | CellList = [(5,3),(3,3)] | 842 |<--------------------------------------| 843 | L2 ACK | 844 A relocates | - - - - - - - - - - - - - - - - - - ->| 845 (1,2)->(5,3)| | 846 and | | 847 (2,2)->(3,3)| | 849 Figure 16: Example of a successful 2-step 6P RELOCATION Transaction. 851 Figure 17 shows an example of a partially successful 2-step 6P 852 RELOCATION Transaction. 854 +----------+ +----------+ 855 | Node A | | Node B | 856 +----+-----+ +-----+----+ 857 | | 858 | 6P RELOCATE Request | 859 | Type = REQUEST | 860 | Code = RELOCATE | 861 | SeqNum = 199 | 862 | NumCells = 2 | 863 | R.CellList = [(1,2),(2,2)] | 864 | C.CellList = [(3,3),(4,3),(5,3)] | 865 |-------------------------------------->| 866 | L2 ACK | 867 |<- - - - - - - - - - - - - - - - - - - | B relocates 868 | | (1,2)->(4,3) 869 | 6P Response | but cannot 870 | Type = RESPONSE | relocate (2,2) 871 | Code = RC_SUCCESS | 872 | SeqNum = 199 | 873 | CellList = [(4,3)] | 874 |<--------------------------------------| 875 | L2 ACK | 876 A relocates | - - - - - - - - - - - - - - - - - - ->| 877 (1,2)->(4,3)| | 879 Figure 17: Example of a partially successful 2-step 6P RELOCATION 880 Transaction. 882 Figure 18 shows an example of a failed 2-step 6P RELOCATION 883 Transaction. 885 +----------+ +----------+ 886 | Node A | | Node B | 887 +----+-----+ +-----+----+ 888 | | 889 | 6P RELOCATE Request | 890 | Type = REQUEST | 891 | Code = RELOCATE | 892 | SeqNum = 53 | 893 | NumCells = 2 | 894 | R.CellList = [(1,2),(2,2)] | 895 | C.CellList = [(3,3),(4,3),(5,3)] | 896 |-------------------------------------->| 897 | L2 ACK | 898 |<- - - - - - - - - - - - - - - - - - - | B can 899 | | relocate 900 | 6P Response | neither (1,2) 901 | Type = RESPONSE | nor (2,2) 902 | Code = RC_SUCCESS | 903 | SeqNum = 53 | 904 | CellList = [] | 905 |<--------------------------------------| 906 | L2 ACK | 907 A does not | - - - - - - - - - - - - - - - - - - ->| 908 relocate | | 910 Figure 18: Failed 2-step 6P RELOCATION Transaction Example. 912 Figure 19 shows an example of a successful 3-step 6P RELOCATION 913 Transaction. 915 +----------+ +----------+ 916 | Node A | | Node B | 917 +----+-----+ +-----+----+ 918 | | 919 | 6P RELOCATE Request | 920 | Type = REQUEST | 921 | Code = RELOCATE | 922 | SeqNum = 11 | 923 | NumCells = 2 | 924 | R.CellList = [(1,2),(2,2)] | 925 | C.CellList = [] | 926 |-------------------------------------->| 927 | L2 ACK | 928 |<- - - - - - - - - - - - - - - - - - - | B identifies 929 | | candidate 930 | | cells 931 | 6P Response | (3,3), 932 | Code = RC_SUCCESS | (4,3) and 933 | SeqNum = 11 | (5,3) 934 | CellList = [(3,3),(4,3),(5,3)] | 935 |<--------------------------------------| 936 | L2 ACK | 937 A relocates | - - - - - - - - - - - - - - - - - - ->| 938 (1,2)->(5,3)| | 939 and | 6P Confirmation | 940 (2,2)->(3,3)| Code = RC_SUCCESS | 941 | SeqNum = 11 | 942 | CellList = [(5,3),(3,3)] | 943 |-------------------------------------->| 944 | L2 ACK | 945 |<- - - - - - - - - - - - - - - - - - - | B relocates 946 | | (1,2)->(5,3) 947 | | and 948 | | (2,2)->(3,3) 949 | | 951 Figure 19: Example of a successful 3-step 6P RELOCATION Transaction. 953 3.3.4. Counting Cells 955 To retrieve the number of scheduled cells at B, node A issues a 6P 956 COUNT command. The Type field (T) is set to REQUEST. The Code field 957 is set to COUNT. Figure 20 defines the format of a 6P COUNT Request. 959 1 2 960 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 961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 962 |Version| T | R | Code | SFID | SeqNum | 963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 964 | Metadata | CellOptions | 965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 967 Figure 20: 6P COUNT Request Format. 969 Metadata: Same usage as for the 6P ADD command, see Section 3.3.1. 970 Its format is the same as that in 6P ADD command, but its 971 contents could be different. 972 CellOptions: Specifies which types of cells to be counted. 974 Figure 21 defines the format of a 6P COUNT Response. 976 1 2 3 977 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 978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 979 |Version| T | R | Code | SFID | SeqNum | 980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 981 | NumCells | 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 Figure 21: 6P COUNT Response Format. 986 NumCells: The number of cells which correspond to the fields of the 987 request. 989 Node A issues a COUNT command to node B, specifying a set of cell 990 options. Upon receiving the 6P COUNT request, node B goes through 991 its schedule and counts the number of cells scheduled with node A in 992 its own schedule, and which match the cell options in the CellOptions 993 field of the request. Section 3.2.3 details the use of the 994 CellOptions field. 996 Node B issues a 6P response to node A with return code set to 997 RC_SUCCESS, and with NumCells containing the number of cells that 998 match the request. 1000 3.3.5. Listing Cells 1002 To retrieve a list of scheduled cells at B, node A issues a 6P LIST 1003 command. The Type field (T) is set to REQUEST. The Code field is 1004 set to LIST. Figure 22 defines the format of a 6P LIST Request. 1006 1 2 1007 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 1008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1009 |Version| T | R | Code | SFID | SeqNum | 1010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1011 | Metadata | CellOptions | Reserved | 1012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1013 | Offset | MaxNumCells | 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1016 Figure 22: 6P LIST Request Format. 1018 Metadata: Same usage as for the 6P ADD command, see Section 3.3.1. 1019 Its format is the same as that in 6P ADD command, but its 1020 contents could be different. 1021 CellOptions: Specifies which types of cells to be listed. 1022 Reserved: Reserved bits. These bits SHOULD be set to zero when 1023 sending the message and MUST be ignored upon reception. 1024 Offset: The Offset of the first scheduled cell that is requested. 1025 The mechanism assumes cells are ordered according to a rule 1026 defined in the SF. The rule MUST always order the cells in the 1027 same way. 1028 MaxNumCells: The maximum number of cells to be listed. Node B MAY 1029 return less than MaxNumCells cells, for example if MaxNumCells 1030 cells do not fit in the frame. 1032 Figure 23 defines the format of a 6P LIST Response. 1034 1 2 3 1035 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 1036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1037 |Version| T | R | Code | SFID | SeqNum | 1038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1039 | CellList ... 1040 +-+-+-+-+-+-+-+-+- 1042 Figure 23: 6P LIST Response Format. 1044 CellList: A list of 0, 1 or multiple 6P Cells. 1046 When receiving a LIST command, node B returns the cells in its 1047 schedule that match the CellOptions field as specified in 1048 Section 3.2.3. 1050 When node B receives a LIST request, the returned CellList in the 6P 1051 Response contains between 1 and MaxNumCells cells, starting from the 1052 specified offset. Node B SHOULD include as many cells as fit in the 1053 frame. If the response contains the last cell, Node B MUST set the 1054 Code field in the response to RC_EOL (as per Figure 37), indicating 1055 to Node A that there no more cells that match the request. Node B 1056 MUST return at least one cell, unless the specified Offset is beyond 1057 the end of B's cell list in its schedule. If node B has less than 1058 Offset cells that match the request, node B returns an empty CellList 1059 and a Code field set to RC_EOL. 1061 3.3.6. Clearing the Schedule 1063 To clear the schedule between nodes A and B (for example after a 1064 schedule inconsistency is detected), node A issues a CLEAR command. 1065 The Type field (T) is set to 6P Request. The Code field is set to 1066 CLEAR. Figure 24 defines the format of a 6P CLEAR Request. 1068 1 2 1069 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 1070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1071 |Version| T | R | Code | SFID | SeqNum | 1072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1073 | Metadata | 1074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1076 Figure 24: 6P CLEAR Request Format. 1078 Metadata: Same usage as for the 6P ADD command, see Section 3.3.1. 1079 Its format is the same as that in 6P ADD command, but its 1080 contents could be different. 1082 Figure 25 defines the format of a 6P CLEAR Response. 1084 1 2 3 1085 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 1086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1087 |Version| T | R | Code | SFID | SeqNum | 1088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1090 Figure 25: 6P CLEAR Response Format. 1092 When a 6P CLEAR command is issued from node A to node B, both nodes A 1093 and B MUST remove all the cells scheduled between them. That is, 1094 node A MUST remove all the cells scheduled with node B, and node B 1095 MUST remove all the cells scheduled with node A. In a 6P CLEAR 1096 command, the SeqNum MUST NOT be checked. In particular, even if the 1097 request contains a SeqNum value that would normally cause node B to 1098 detect a schedule mismatch, the transaction MUST NOT be aborted. 1099 Upon 6P CLEAR completion, the value of SeqNum MUST be reset to 0. 1101 The Response Code to a 6P CLEAR command SHOULD be RC_SUCCESS unless 1102 the operation cannot be executed. When the CLEAR operation cannot be 1103 executed the Response Code MUST be set to RC_RESET. 1105 3.3.7. Generic Signaling Between SFs 1107 The 6P SIGNAL message allows the SF implementations on two neighbor 1108 nodes to exchange generic commands. The payload in a received SIGNAL 1109 message is an opaque set of bytes passed unmodified to the SF. How 1110 the generic SIGNAL command is used is specified by the SF, and 1111 outside the scope of this document. The Type field (T) is set to 1112 REQUEST. The Code field is set to SIGNAL. Figure 26 defines the 1113 format of a 6P SIGNAL Request. 1115 1 2 1116 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 1117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1118 |Version| T | R | Code | SFID | SeqNum | 1119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1120 | Metadata | payload ... 1121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1123 Figure 26: 6P SIGNAL Request Format. 1125 Metadata: Same usage as for the 6P ADD command, see Section 3.3.1. 1126 Its format is the same as that in 6P ADD command, but its 1127 contents could be different. 1129 Figure 27 defines the format of a 6P SIGNAL Response. 1131 1 2 3 1132 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 1133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1134 |Version| T | R | Code | SFID | SeqNum | 1135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1136 | payload ... 1137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1139 Figure 27: 6P SIGNAL Response Format. 1141 3.4. Protocol Functional Details 1143 3.4.1. Version Checking 1145 All messages contain a Version field. If multiple Versions of the 6P 1146 protocol have been defined (in future specifications for Version 1147 values different from 0), a node MAY implement multiple protocol 1148 versions at the same time. When a node receives a 6P message with a 1149 Version number it does not implement, the node MUST reply with a 6P 1150 Response with a Return Code field set to RC_ERR_VERSION. The format 1151 of this 6P Response message MUST be compliant with Version 0 and MUST 1152 be supported by all future versions of the protocol. This ensures 1153 that, when node B sends a 6P Response to node A indicating it does 1154 not implement the 6P version in the 6P Request, node A can 1155 successfully parse that response. 1157 In case a node supports a version number received in a 6P Request 1158 message, the Version field in the 6P Response MUST be the same as the 1159 Version field in the corresponding 6P Request. Similarly, in a 1160 3-step transaction, the Version field in the 6P Confirmation MUST 1161 match that of the 6P Request and 6P Response in the same transaction. 1163 3.4.2. SFID Checking 1165 All messages contain an SFID field. A node MAY support multiple SFs 1166 at the same time. When receiving a 6P message with an unsupported 1167 SFID, a node MUST reply with a 6P Response and a return code of 1168 RC_ERR_SFID. The SFID field in the 6P Response MUST be the same as 1169 the SFID field in the corresponding 6P Request. In a 3-step 1170 transaction, the SFID field in the 6P Confirmation MUST match that of 1171 the 6P Request and 6P Response in the same transaction. 1173 3.4.3. Concurrent 6P Transactions 1175 Only a single 6P Transaction between two neighbors, in a given 1176 direction, can take place at the same time. That is, a node MUST NOT 1177 issue a new 6P Request to a given neighbor before having received the 1178 6P Response for a previous request to that neighbor, except when the 1179 previous 6P Transaction has timed out. If a node receives a 6P 1180 Request from a given neighbor before having sent the 6P Response to 1181 the previous 6P Request from that neighbor, it MUST send back a 6P 1182 Response with a return code of RC_RESET (as per Figure 37) and 1183 discard this ongoing second transaction. A node receiving RC_RESET 1184 code MUST abort the second transaction and consider it never 1185 happened. 1187 Nodes A and B MAY support having two transactions going on at the 1188 same time, one in each direction. Similarly, a node MAY support 1189 concurrent 6P Transactions from different neighbors. In this case, 1190 the cells involved in an ongoing 6P Transaction MUST be locked until 1191 the transaction finishes. For example, in Figure 1, node C can have 1192 a different ongoing 6P Transaction with nodes B and R. In case a 1193 node does not have enough resources to handle concurrent 6P 1194 Transactions from different neighbors it MUST reply with a 6P 1195 Response with return code RC_ERR_BUSY (as per Figure 37). In case 1196 the requested cells are locked, it MUST reply to that request with a 1197 6P Response with return code RC_ERR_LOCKED (as per Figure 37). The 1198 node receiving RC_ERR_BUSY or a RC_ERR_LOCKED MAY implement a retry 1199 mechanism, defined by the SF. 1201 3.4.4. 6P Timeout 1203 A timeout occurs when the node sending the 6P Request has not 1204 received the 6P Response within a specified amount of time determined 1205 by the SF. In a 3-step transaction, a timeout also occurs when the 1206 node sending the 6P Response has not received the 6P Confirmation. 1207 When a timeout occurs the transaction MUST be cancelled at the node 1208 where the timeout occurred. The value of the 6P Timeout should be 1209 larger than the longest possible time it can take for the exchange to 1210 finish. The value of the 6P Timeout hence depends on the number of 1211 cells scheduled between the neighbor nodes, the maximum number of 1212 link-layer retransmissions, etc. The SF MUST determine the value of 1213 the timeout. The value of the timeout is out of scope of this 1214 document. 1216 3.4.5. Aborting a 6P Transaction 1218 In case the receiver of a 6P Request fails during a 6P Transaction 1219 and it is unable to complete it, it SHOULD reply to that Request with 1220 a 6P Response with return code RC_RESET. Upon receiving this 6P 1221 Response, the initiator of the 6P Transaction MUST consider the 6P 1222 Transaction as failed. 1224 Similarly, in the case of 3-step transaction, when the receiver of a 1225 6P Response fails during the 6P Transaction and is unable to complete 1226 it, it MUST reply to that 6P Response with a 6P Confirmation with 1227 return code RC_RESET. Upon receiving this 6P Confirmation, the 1228 sender of the 6P Response MUST consider the 6P Transaction as failed. 1230 3.4.6. SeqNum Management 1232 The SeqNum is the field in the 6top IE header used to match Request, 1233 Response and Confirmation. The SeqNum is used to detect and handle 1234 duplicate commands (Section 3.4.6.1) and schedule inconsistencies 1235 (Section 3.4.6.2). Each node remembers the last used SeqNum for each 1236 neighbor. That is, a node stores as many SeqNum values as it has 1237 neighbors. In the remainder of this section, we describe the use of 1238 SeqNum between two neighbors; the same happens for each other 1239 neighbor, independently. 1241 When a node resets or after a CLEAR transaction, it MUST reset SeqNum 1242 to 0. The 6P Response and 6P Confirmation for a transaction MUST use 1243 the same SeqNum value as that in the Request. After every 1244 transaction, the SeqNum MUST be incremented by exactly 1. 1246 Specifically, if node A receives the link-layer acknowledgment for 1247 its 6P Request, it commits to incrementing the SeqNum by exactly 1 1248 after the 6P Transaction ends. This ensure that, at the next 6P 1249 Transaction where it sends a 6P Request, that 6P Request will have a 1250 different SeqNum. 1252 Similarly, node B increments the SeqNum by exactly 1 after having 1253 received the link-layer acknowledgment for the 6P Response (2-step 6P 1254 Transaction), or after having sent the link-layer acknowledgment for 1255 the 6P Confirmation (3-step 6P Transaction) . 1257 The SeqNum MUST be implemented as a lollipop counter: it rolls over 1258 from 0xFF to 0x01 (not to 0x00). This is used to detect that a 1259 neighbor reset. Figure 28 lists the possible values of the SeqNum. 1261 +----------+----------------------------+ 1262 | Value | Meaning | 1263 +----------+----------------------------+ 1264 | 0x00 | Clear or After device Reset| 1265 |0x01-0xFF | Lollipop Counter values | 1266 +----------+----------------------------+ 1268 Figure 28: Possible values of SeqNum. 1270 3.4.6.1. Detecting and Handling Duplicate 6P Messages 1272 All 6P commands are link-layer acknowledged. A duplicate message 1273 means that a node receives a second 6P Request, Response or 1274 Confirmation. This happens when the link-layer acknowledgment is not 1275 received, and a link-layer retransmission happens. Duplicate 1276 messages are normal and unavoidable. 1278 Figure 29 shows an example 2-step transaction in which Node A 1279 receives a duplicate 6P Response. 1281 +----------+ +----------+ 1282 | Node A | | Node B | 1283 +----+-----+ +-----+----+ 1284 | | 1285 | 6P Request (SeqNum=456) | 1286 |-------------------------------------->| 1287 | L2 ACK | 1288 |<- - - - - - - - - - - - - - - - - - - | 1289 | | 1290 | 6P Response (SeqNum=456) | 1291 |<--------------------------------------| 1292 | L2 ACK | 1293 | - - - - - - - - - - -X | No ACK: 1294 | | link-layer 1295 | 6P Response (SeqNum=456) | retransmit 1296 duplicate |<--------------------------------------| 1297 6P Response | L2 ACK | 1298 received | - - - - - - - - - - - - - - - - - - ->| 1299 | | 1301 Figure 29: Example duplicate 6P message. 1303 Figure 30 shows example 3-step transaction in which Node A receives a 1304 out-of-order duplicate 6P Response after having sent a 6P 1305 Confirmation. 1307 +----------+ +----------+ 1308 | Node A | | Node B | 1309 +----+-----+ +-----+----+ 1310 | | 1311 | 6P Request (SeqNum=123) | 1312 |-------------------------------------->| 1313 | L2 ACK | 1314 |<- - - - - - - - - - - - - - - - - - - | 1315 | | 1316 | 6P Response (SeqNum=123) | 1317 |<--------------------------------------| 1318 | L2 ACK | 1319 | - - - - - - - - - - -X | No ACK: 1320 | | link-layer 1321 | 6P Confirmation (SeqNum=123) | retransmit 1322 |-------------------------------------->| | 1323 | L2 ACK | | 1324 |<- - - - - - - - - - - - - - - - - - - | frame 1325 | | queued 1326 | 6P Response (SeqNum=123) | | 1327 duplicate |<--------------------------------------| <--+ 1328 out-of-order | L2 ACK | 1329 6P Response | - - - - - - - - - - - - - - - - - - ->| 1330 received | | 1332 Figure 30: Example out-of-order duplicate 6P message. 1334 A node detects a duplicate 6P message when it has the same SeqNum and 1335 type as the last frame received from the same neighbor. When 1336 receiving a duplicate 6P message, a node MUST send a link-layer 1337 acknowledgment, but MUST silently ignore it at the 6top sublayer. 1339 3.4.6.2. Detecting and Handling a Schedule Inconsistency 1341 A schedule inconsistency happens when the schedules of nodes A and B 1342 are inconsistent. For example, when node A has a transmit cell to 1343 node B, but node B isn't listening to node A on that cell. A 1344 schedule inconsistency results in loss of connectivity. 1346 The SeqNum field, which is present in each 6P message, is used to 1347 detect an inconsistency. Given that the SeqNum field increments by 1 1348 at each message. A node computes the expected SeqNum field for the 1349 next 6P Transaction. If a node receives a 6P Request with a SeqNum 1350 value that is not the expected on, it has detected an inconsistency. 1352 There are at least 2 cases in which a schedule inconsistency happens. 1354 The first case is when a node loses state, for example when power 1355 cycled. In that case, its SeqNum value is reset to 0. Since the 1356 SeqNum is a lollipop counter, its neighbor detects an inconsistency 1357 at the next 6P transaction. This is illustrated in Figure 31. 1359 +----------+ +----------+ 1360 | Node A | | Node B | 1361 +----+-----+ +-----+----+ 1362 SeqNum=87 | | SeqNum=87 1363 | | 1364 | 6P Request (SeqNum=87) | 1365 |-------------------------------------->| 1366 | L2 ACK | 1367 |<- - - - - - - - - - - - - - - - - - - | 1368 | | 1369 | 6P Response (SeqNum=87) | 1370 |<--------------------------------------| 1371 | L2 ACK | 1372 | - - - - - - - - - - - - - - - - - - ->| 1373 | ==== power-cycle 1374 | | 1375 SeqNum=88 | | SeqNum=0 1376 | | 1377 | 6P Request (SeqNum=88) | 1378 |-------------------------------------->| Inconsistency 1379 | L2 ACK | Detected 1380 |<- - - - - - - - - - - - - - - - - - - | 1381 | | 1382 | 6P Response (SeqNum=0, RC_ERR_SEQNUM) | 1383 |<--------------------------------------| 1384 | L2 ACK | 1385 | - - - - - - - - - - - - - - - - - - ->| 1387 Figure 31: Example of inconsistency because of node reset. 1389 The second case is when the maximum number of link-layer 1390 retransmissions is reached on the 6P Response of a 2-step transaction 1391 (or equivalently on a 6P Confirmation of a 3-step transaction). This 1392 is illustrated in Figure 32. 1394 +----------+ +----------+ 1395 | Node A | | Node B | 1396 +----+-----+ +-----+----+ 1397 SeqNum=87 | | SeqNum=87 1398 | | 1399 | 6P Request (SeqNum=87) | 1400 |-------------------------------------->| 1401 | L2 ACK | 1402 |<- - - - - - - - - - - - - - - - - - - | 1403 | | 1404 | 6P Response (SeqNum=87) | 1405 |<--------------------------------------| 1406 | L2 ACK | 1407 | - - - - - - - - X | 1408 SeqNum=88 | | no ACK: 1409 | 6P Response (SeqNum=87) | retrans. 1 1410 (duplicate) |<--------------------------------------| 1411 | L2 ACK | 1412 | - - - - - - - - X | 1413 | | no ACK: 1414 | 6P Response (SeqNum=87) | retrans. 2 1415 (duplicate) |<--------------------------------------| 1416 | L2 ACK | 1417 | - - - - - - - - X | 1418 | | max retrans.: 1419 | | Inconsistency 1420 | | Detected 1422 Figure 32: Example inconsistency because of maximum link-layer 1423 retransmissions (here 2). 1425 In both cases, node B detects the inconsistency. 1427 If the inconsistency is detected during a 6P Transaction (Figure 31), 1428 the node that has detected it MUST send back a 6P Response or 6P 1429 Confirmation with an error code of RC_ERR_SEQNUM. In this 6P 1430 Response or 6P Confirmation, the SeqNum field MUST be set to the 1431 value of the sender of the message (to 0 in Figure 31). 1433 The SF of the node which has detected the inconsistency MUST define 1434 how to handle the inconsistency. A first possibility is to issue a 1435 6P CLEAR request to clear the schedule, and rebuild. A second 1436 possibility is to issue a 6P LIST request to retrieve the schedule. 1437 A third possibility is to internally "roll-back" the schedule. How 1438 to handle an inconsistency is out of scope of this document. The SF 1439 defines how to handle an inconsistency. 1441 3.4.7. Handling Error Responses 1443 A return code marked as Yes in the "Is Error" column in Figure 37 1444 indicates an error. When a node receives a 6P Response or 6P 1445 Confirmation with such an error, it MUST consider the 6P Transaction 1446 as failed. In particular, if this was a response to a 6P ADD/DELETE/ 1447 RELOCATE Request, the node MUST NOT add/delete/relocate any of the 1448 cells involved in this 6P Transaction. Similarly, a node sending a 1449 6P Response or a 6P Confirmation with an error code MUST NOT 1450 add/delete/relocate any cells as part of that 6P Transaction. 1451 Defining what to do after an error has occurred is out of scope of 1452 this document. The SF defines what to do after an error has 1453 occurred. 1455 3.5. Security 1457 6P messages are secured through link-layer security. When link-layer 1458 security is enabled, the 6P messages MUST be secured. This is 1459 possible because 6P messages are carried as Payload IE. 1461 4. Requirements for 6top Scheduling Functions (SF) 1463 4.1. SF Identifier (SFID) 1465 Each SF has a 1-byte identifier. Section 6.2.5 defines the rules for 1466 applying for an SFID. 1468 4.2. Requirements for an SF 1470 The specification for an SF 1472 o MUST specify an identifier for that SF. 1473 o MUST specify the rule for a node to decide when to add/delete one 1474 or more cells to a neighbor. 1475 o MUST specify the rule for a Transaction source to select cells to 1476 add to the CellList field in the 6P ADD Request. 1477 o MUST specify the rule for a Transaction destination to select 1478 cells from CellList to add to its schedule. 1479 o MUST specify a value for the 6P Timeout, or a rule/equation to 1480 calculate it. 1481 o MUST specify the rule for ordering cells. 1482 o MUST specify a meaning for the "Metadata" field in the 6P ADD 1483 Request. 1484 o MUST specify the SF behavior of a node when it boots. 1485 o MUST specify how to handle a schedule inconsistency. 1486 o MUST specify what to do after an error has occurred (either the 1487 node sent a 6P Response with an error code, or received one). 1489 o MUST specify the list of statistics to gather. An example 1490 statistic is the number of transmitted frames to each neighbor. 1491 In case the SF requires no statistics to be gathered, the specific 1492 of the SF MUST explicitly state so. 1494 o SHOULD clearly state the application domain the SF is created for. 1495 o SHOULD contain examples which highlight normal and error 1496 scenarios. 1497 o SHOULD contain a list of current implementations, at least during 1498 the I-D state of the document, per [RFC6982]. 1499 o SHOULD contain a performance evaluation of the scheme, possibly 1500 through references to external documents. 1501 o SHOULD define the format of the SIGNAL command payload and its 1502 use. 1504 o MAY redefine the format of the CellList field. 1505 o MAY redefine the format of the CellOptions field. 1506 o MAY redefine the meaning of the CellOptions field. 1508 5. Security Considerations 1510 6P messages are carried inside 802.15.4 Payload Information Elements 1511 (IEs). Those Payload IEs are encrypted and authenticated at the link 1512 layer through CCM* [CCM-Star] 6P benefits from the same level of 1513 security as any other Payload IE. The 6P protocol does not define 1514 its own security mechanisms. The 6P protocol does not provide 1515 protection against DOS attacks. This is relevant in 3-step 1516 transactions when a confirmation message could not be sent in purpose 1517 by the attacker. Such situations SHOULD be handled by an appropiate 1518 policy such as blacklisting the attacker after several attempts. 1519 Other DoS attacks are possible by sending unmeaningful requests to 1520 nodes. The effect to the overall network can be minimal as 1521 communication between attacked node and attacker happen in dedicated 1522 cells. DoS then only limits that cells. Yet, this can be avoided by 1523 blacklisting the node after several attempts. When to blacklist is 1524 policy specific and SHOULD be addressed by the SF. A key management 1525 solution is out of scope for this document. The 6P protocol will 1526 benefit for the key management solution used in the network. 1528 6. IANA Considerations 1530 6.1. IETF IE Subtype '6P' 1532 This document adds the following number to the "IEEE Std 802.15.4 1533 IETF IE subtype IDs" registry defined by [RFC8137]: 1535 +--------------------+------+-----------+ 1536 | Subtype | Name | Reference | 1537 +--------------------+------+-----------+ 1538 | IANA_6TOP_SUBIE_ID | 6P | RFCXXXX | 1539 +--------------------+------+-----------+ 1541 Figure 33: IETF IE Subtype '6P'. 1543 6.2. 6TiSCH parameters sub-registries 1545 This section defines sub-registries within the "IPv6 over the TSCH 1546 mode of IEEE 802.15.4e (6TiSCH) parameters" registry, hereafter 1547 referred to as the "6TiSCH parameters" registry. Each sub-registry 1548 is described in a subsection. 1550 6.2.1. 6P Version Numbers 1552 The name of the sub-registry is "6P Version Numbers". 1554 A Note included in this registry should say: "In the 6top Protocol 1555 (6P) [RFCXXXX] there is a field to identify the version of the 1556 protocol. This field is 4 bits in size." 1558 Each entry in the sub-registry must include the Version in the range 1559 0-15, and a reference to the 6P version's documentation. 1561 The initial entry in this sub-registry is as follows: 1563 +---------+-----------+ 1564 | Version | Reference | 1565 +---------+-----------+ 1566 | 0 | RFCXXXX | 1567 +---------+-----------+ 1569 Figure 34: 6P Version Numbers. 1571 All other Version Numbers are Unassigned. 1573 The IANA policy for future additions to this sub-registry is "IETF 1574 Review or IESG Approval" as described in [RFC8126]. 1576 6.2.2. 6P Message Types 1578 The name of the sub-registry is "6P Message Types". 1580 A Note included in this registry should say: "In the 6top Protocol 1581 (6P) version 0 [RFCXXXX], there is a field to identify the type of 1582 message. This field is 2 bits in size." 1583 Each entry in the sub-registry must include the Type in the range 1584 b00-b11, the corresponding Name, and a reference to the 6P message 1585 type's documentation. 1587 Initial entries in this sub-registry are as follows: 1589 +------+--------------+-----------+ 1590 | Type | Name | Reference | 1591 +------+--------------+-----------+ 1592 | b00 | REQUEST | RFCXXXX | 1593 | b01 | RESPONSE | RFCXXXX | 1594 | b10 | CONFIRMATION | RFCXXXX | 1595 +------+--------------+-----------+ 1597 Figure 35: 6P Message Types. 1599 All other Message Types are Reserved. 1601 The IANA policy for future additions to this sub-registry is "IETF 1602 Review or IESG Approval" as described in [RFC8126]. 1604 6.2.3. 6P Command Identifiers 1606 The name of the sub-registry is "6P Command Identifiers". 1608 A Note included in this registry should say: "In the 6top Protocol 1609 (6P) version 0 [RFCXXXX], there is a Code field which is 8 bits in 1610 size. In a 6P Request, the value of this Code field is used to 1611 identify the command." 1613 Each entry in the sub-registry must include the Identifier in the 1614 range 0-255, the corresponding Name, and a reference to the 6P 1615 command identifier's documentation. 1617 Initial entries in this sub-registry are as follows: 1619 +------------+------------+-----------+ 1620 | Identifier | Name | Reference | 1621 +------------+------------+-----------+ 1622 | 0 | Reserved | | 1623 | 1 | ADD | RFCXXXX | 1624 | 2 | DELETE | RFCXXXX | 1625 | 3 | RELOCATE | RFCXXXX | 1626 | 4 | COUNT | RFCXXXX | 1627 | 5 | LIST | RFCXXXX | 1628 | 6 | SIGNAL | RFCXXXX | 1629 | 7 | CLEAR | RFCXXXX | 1630 | 8-254 | Unassigned | | 1631 | 255 | Reserved | | 1632 +------------+------------+-----------+ 1634 Figure 36: 6P Command Identifiers. 1636 The IANA policy for future additions to this sub-registry is "IETF 1637 Review or IESG Approval" as described in [RFC8126]. 1639 6.2.4. 6P Return Codes 1641 The name of the sub-registry is "6P Return Codes". 1643 A Note included in this registry should say: "In the 6top Protocol 1644 (6P) version 0 [RFCXXXX], there is a Code field which is 8 bits in 1645 size. In a 6P Response or 6P Confirmation, the value of this Code 1646 field is used to identify the return code." 1648 Each entry in the sub-registry must include the Code in the range 1649 0-255, the corresponding Name, the corresponding Description, and a 1650 reference to the 6P return code's documentation. 1652 Initial entries in this sub-registry are as follows: 1654 +------+-----------------+---------------------------+-----------+ 1655 | Code | Name | Description | Is Error? | 1656 +------+-----------------+---------------------------+-----------+ 1657 | 0 | RC_SUCCESS | operation succeeded | No | 1658 | 1 | RC_EOL | end of list | No | 1659 | 2 | RC_ERR | generic error | Yes | 1660 | 3 | RC_RESET | critical error, reset | Yes | 1661 | 4 | RC_ERR_VERSION | unsupported 6P version | Yes | 1662 | 5 | RC_ERR_SFID | unsupported SFID | Yes | 1663 | 6 | RC_ERR_SEQNUM | schedule inconsistency | Yes | 1664 | 7 | RC_ERR_CELLLIST | cellList error | Yes | 1665 | 8 | RC_ERR_BUSY | busy | Yes | 1666 | 9 | RC_ERR_LOCKED | cells are locked | Yes | 1667 +------+-----------------+---------------------------+-----------+ 1669 Figure 37: 6P Return Codes. 1671 All other Message Types are Unassigned. 1673 The IANA policy for future additions to this sub-registry is "IETF 1674 Review or IESG Approval" as described in [RFC8126]. 1676 6.2.5. 6P Scheduling Function Identifiers 1678 6P Scheduling Function Identifiers. 1680 A Note included in this registry should say: "In the 6top Protocol 1681 (6P) version 0 [RFCXXXX], there is a field to identify the scheduling 1682 function to handle the message. This field is 8 bits in size." 1684 Each entry in the sub-registry must include the SFID in the range 1685 0-255, the corresponding Name, and a reference to the 6P Scheduling 1686 Function's documentation. 1688 The initial entries in this sub-registry is as follows: 1690 +----+---------------------------------+----------------------------+ 1691 |SFID| Name | Reference | 1692 +----+---------------------------------+----------------------------+ 1693 | 0 | Minimal Scheduling Function | draft-chang-6tisch-msf | 1694 | | (MSF) | | 1695 +----+---------------------------------+----------------------------+ 1696 | 1 | Experimental Scheduling Function| draft-ietf-6tisch-6top-sfx | 1697 | | (SFX) | | 1698 +----+---------------------------------+----------------------------+ 1700 Figure 38: SF Identifiers (SFID). 1702 All other Message Types are Unassigned. 1704 The IANA policy for future additions to this sub-registry depends on 1705 the value of the SFID, as defined in Figure 39. These specifications 1706 must follow the guidelines of Section 4. 1708 +-----------+------------------------------+ 1709 | Range | Registration Procedures | 1710 +-----------+------------------------------+ 1711 | 0-127 | IETF Review or IESG Approval | 1712 | 128-255 | Expert Review | 1713 +-----------+------------------------------+ 1715 Figure 39: SF Identifier (SFID): Registration Procedures. 1717 6.2.6. 6P CellOptions bitmap 1719 The name of the sub-registry is "6P CellOptions bitmap". 1721 A Note included in this registry should say: "In the 6top Protocol 1722 (6P) version 0 [RFCXXXX], there is an optional CellOptions field 1723 which is 8 bits in size." 1725 Each entry in the sub-registry must include the bit position in the 1726 range 0-7, the corresponding Name, and a reference to the bit's 1727 documentation. 1729 Initial entries in this sub-registry are as follows: 1731 +-----+---------------+-----------+ 1732 | bit | Name | Reference | 1733 +-----+---------------+-----------+ 1734 | 0 | TX (Transmit) | RFCXXXX | 1735 | 1 | RX (Receive) | RFCXXXX | 1736 | 2 | SHARED | RFCXXXX | 1737 | 3-7 | Reserved | | 1738 +-----+---------------+-----------+ 1740 Figure 40: 6P CellOptions bitmap. 1742 All other Message Types are Reserved. 1744 The IANA policy for future additions to this sub-registry is "IETF 1745 Review or IESG Approval" as described in [RFC8126]. 1747 7. References 1749 7.1. Normative References 1751 [IEEE802154] 1752 IEEE standard for Information Technology, "IEEE Std 1753 802.15.4-2015 - IEEE Standard for Low-Rate Wireless 1754 Personal Area Networks (WPANs)", October 2015. 1756 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1757 Requirement Levels", BCP 14, RFC 2119, 1758 DOI 10.17487/RFC2119, March 1997, 1759 . 1761 [RFC8137] Kivinen, T. and P. Kinney, "IEEE 802.15.4 Information 1762 Element for the IETF", RFC 8137, DOI 10.17487/RFC8137, May 1763 2017, . 1765 7.2. Informative References 1767 [CCM-Star] 1768 Struik, R., "Formal Specification of the CCM* Mode of 1769 Operation, IEEE P802.15 Working Group for Wireless 1770 Personal Area Networks (WPANs).", September 2005. 1772 [OpenWSN] Watteyne, T., Vilajosana, X., Kerkez, B., Chraim, F., 1773 Weekly, K., Wang, Q., Glaser, S., and K. Pister, "OpenWSN: 1774 a Standards-Based Low-Power Wireless Development 1775 Environment", Transactions on Emerging Telecommunications 1776 Technologies , August 2012. 1778 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1779 Code: The Implementation Status Section", RFC 6982, 1780 DOI 10.17487/RFC6982, July 2013, 1781 . 1783 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 1784 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 1785 Internet of Things (IoT): Problem Statement", RFC 7554, 1786 DOI 10.17487/RFC7554, May 2015, 1787 . 1789 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1790 Writing an IANA Considerations Section in RFCs", BCP 26, 1791 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1792 . 1794 [RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal 1795 IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) 1796 Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180, 1797 May 2017, . 1799 Appendix A. Recommended Structure of an SF Specification 1801 The following section structure for a SF document is RECOMMENDED: 1803 o Introduction 1804 o Scheduling Function Identifier 1805 o Rules for Adding/Deleting Cells 1806 o Rules for CellList 1807 o 6P Timeout Value 1808 o Rule for Ordering Cells 1809 o Meaning of the Metadata Field 1810 o Node Behavior at Boot 1811 o Schedule Inconsistency Handling 1812 o 6P Error Handling 1813 o Examples 1814 o Implementation Status 1815 o Security Considerations 1816 o IANA Considerations 1818 Appendix B. Implementation Status 1820 This section records the status of known implementations of the 1821 protocol defined by this specification at the time of posting of this 1822 Internet-Draft, and is based on a proposal described in [RFC6982]. 1823 The description of implementations in this section is intended to 1824 assist the IETF in its decision processes in progressing drafts to 1825 RFCs. Please note that the listing of any individual implementation 1826 here does not imply endorsement by the IETF. Furthermore, no effort 1827 has been spent to verify the information presented here that was 1828 supplied by IETF contributors. This is not intended as, and must not 1829 be construed to be, a catalog of available implementations or their 1830 features. Readers are advised to note that other implementations may 1831 exist. 1833 According to [RFC6982], "this will allow reviewers and working groups 1834 to assign due consideration to documents that have the benefit of 1835 running code, which may serve as evidence of valuable experimentation 1836 and feedback that have made the implemented protocols more mature. 1837 It is up to the individual working groups to use this information as 1838 they see fit". 1840 First F-Interop ETSI 6TiSCH plugtests: 6P is one of the protocols 1841 addressed during the First F-Interop ETSI 6TiSCH plugtests 1842 organized on 14-15 July 2017 in Prague, Czech Republic. It was 1843 attended by 14 entities, which 4-5 independent implementation 1844 bases. 1845 ETSI 6TiSCH/6lo plugtests: 6P was one of the protocols addressed 1846 during the ETSI 6TiSCH #3 plugtests organized on 15-17 July 2016 1847 in Berlin, Germany. 15 entities participated in this event, 1848 verifying the compliance and interoperability of their 1849 implementation of 6P. This event happened under NDA, so neither 1850 the name of the entities nor the test results are public. This 1851 event is, however, a clear indication of the maturity of 6P, and 1852 the interest it generates. More information about the event at 1853 http://www.etsi.org/news-events/events/1077-6tisch-6lo-plugtests. 1854 ETSI 6TiSCH #2 plugtests: 6P was one of two protocols addressed 1855 during the ETSI 6TiSCH #2 plugtests organized on 2-4 February 2016 1856 in Paris, France. 14 entities participated in this event, 1857 verifying the compliance and interoperability of their 1858 implementation of 6P. This event happened under NDA, so neither 1859 the name of the entities nor the test results are public. This 1860 event is, however, a clear indication of the maturity of 6P, and 1861 the interest it generates. More information about the event at 1862 http://www.etsi.org/news-events/events/1022-6TiSCH-2-plugtests. 1863 OpenWSN: 6P is implemented in the OpenWSN project [OpenWSN] under a 1864 BSD open-source license. The authors of this document are 1865 collaborating with the OpenWSN community to gather feedback about 1866 the status and performance of the protocols described in this 1867 document. Results from that discussion will appear in this 1868 section in future revision of this specification. More 1869 information about this implementation at http://www.openwsn.org/. 1870 F-Interop Interoperability/Conformance Testing tool The F-Interop 1871 project is putting together an online tool to conduct online and 1872 remote interoperability/conformance tests. 6P is one of the 1873 supported protocols. 1874 6TiSCH simulator The 6TiSCH simulator is a Python-based high-level 1875 simulator which implements 6P and is built to evaluate the 1876 performance of differents SFs. More information at 1877 https://bitbucket.org/6tisch/simulator/. 1878 Wireshark Dissector: A Wireshark dissector for 6P is implemented 1879 under a BSD open-source license. It is developed and maintained 1880 at https://github.com/openwsn-berkeley/dissectors/, and regularly 1881 merged into the main Wireshark repository. Please see the 1882 Wireshark documentation to see what version of 6P it supports. 1884 Appendix C. [TEMPORARY] Changelog 1886 o draft-ietf-6tisch-6top-protocol-10 1888 * Adding a table detailing celloptions usage in ADD/DELETE/ 1889 RELOCATE operations. 1891 * Addressing comments from IoT Directorate. 1892 * Fixing typos. 1893 o draft-ietf-6tisch-6top-protocol-09 1895 * Requiring version 0 in RC_ERR_VERSION response. 1896 * Adding L2 ACK in figures. 1897 * Inconsistency management update. 1898 * Moving SF requirements to another section. 1899 * Moving implementation status to appendix. 1900 * Fixing typos. 1901 o draft-ietf-6tisch-6top-protocol-08 1903 * Replacing GEN counter by SeqNum and timeout. 1904 * Adding SIGNAL command. 1905 * Adding RC_ERR_SEQNUM return code. 1906 * Clarifying IETF IE usage. 1907 * Cleaning up error codes. 1908 * Fixing typos. 1909 o draft-ietf-6tisch-6top-protocol-07 1911 * Inverting RC_ERR_LOCKED and RC_ERR_BUSY error codes for 1912 concurrent transactions. 1913 * Adding missing implementations. 1914 * Fixing references. 1915 * Fixing typos. 1916 o draft-ietf-6tisch-6top-protocol-06 1918 * Changing error code from RC_RESET to RC_ERR_CELLLIST when 1919 deleting unscheduled cells. 1920 * Fixing typos. 1921 o draft-ietf-6tisch-6top-protocol-05 1923 * complete reorder of sections. Merged protocol behavior and 1924 command description 1925 * STATUS to COUNT 1926 * written-out IANA section 1927 * complete proof-read 1928 o draft-ietf-6tisch-6top-protocol-04 1930 * recommendation on which cells to use for 6P traffic 1931 * relocation format: added numberofCells field 1932 * created separate section about "cell suggestion" 1933 * Added RC_ERR_CELLLIST and RC_ERR_EOL error codes 1934 * Added example for two step with the failure 1935 * Recommended numbers in IANA section 1936 * single generation number 1937 * IEEE802.15.4 -> IEEE Std 802.15.4 or 802.15.4 1938 * complete proof-read 1940 o draft-ietf-6tisch-6top-protocol-03 1942 * Added a reference to [RFC8137]. 1943 * Added the Type field. 1944 * Editorial changes (figs, typos, ...) 1945 o draft-ietf-6tisch-6top-protocol-02 1947 * Rename COUNT to STATUS 1948 * Split LIST to LIST AB and LIST BA 1949 * Added generation counters and describing generation tracking of 1950 the schedule 1951 * Editorial changes (figs, typos, ...) 1952 o draft-ietf-6tisch-6top-protocol-01 1954 * Clarifying locking of resources in concurrent transactions 1955 * Clarifying return of RC_ERR_BUSY in case of concurrent 1956 transactions without enough resources 1957 o draft-ietf-6tisch-6top-protocol-00 1959 * Informational to Std track 1960 o draft-wang-6tisch-6top-protocol-00 1962 * Editorial overhaul: fixing typos, increasing readability, 1963 clarifying figures. 1964 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1965 issues/47 1966 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1967 issues/54 1968 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1969 issues/55 1970 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1971 issues/49 1972 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1973 issues/53 1974 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1975 issues/44 1976 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1977 issues/48 1978 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1979 issues/43 1980 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1981 issues/52 1982 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1983 issues/45 1984 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1985 issues/51 1986 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1987 issues/50 1989 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1990 issues/46 1991 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1992 issues/41 1993 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1994 issues/42 1995 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1996 issues/39 1997 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1998 issues/40 1999 o draft-wang-6tisch-6top-sublayer-05 2001 * Specifies format of IE 2002 * Adds token in messages to match request and response 2003 o draft-wang-6tisch-6top-sublayer-04 2005 * Renames IANA_6TOP_IE_GROUP_ID to IANA_IETF_IE_GROUP_ID. 2006 * Renames IANA_CMD and IANA_RC to IANA_6TOP_CMD and IANA_6TOP_RC. 2007 * Proposes IANA_6TOP_SUBIE_ID with value 0x00 for the 6top sub- 2008 IE. 2009 o draft-wang-6tisch-6top-sublayer-03 2011 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 2012 protocol/issues/32/missing-command-list 2013 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 2014 protocol/issues/31/missing-command-count 2015 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 2016 protocol/issues/30/missing-command-clear 2017 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 2018 issues/37/6top-atomic-transaction-6p-transaction 2019 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 2020 protocol/issues/35/separate-opcode-from-rc 2021 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 2022 protocol/issues/36/add-length-field-in-ie 2023 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 2024 protocol/issues/27/differentiate-rc_err_busy-and 2025 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 2026 protocol/issues/29/missing-rc-rc_reset 2027 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 2028 protocol/issues/28/the-sf-must-specify-the-behavior-of-a-mote 2029 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 2030 protocol/issues/26/remove-including-their-number 2031 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 2032 issues/34/6of-sf 2033 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 2034 protocol/issues/33/add-a-figure-showing-the-negociation 2035 o draft-wang-6tisch-6top-sublayer-02 2036 * introduces the 6P protocol and the notion of 6top Transaction. 2037 * introduces the concept of 6OF and its 6OFID. 2039 Authors' Addresses 2041 Qin Wang (editor) 2042 Univ. of Sci. and Tech. Beijing 2043 30 Xueyuan Road 2044 Beijing, Hebei 100083 2045 China 2047 Email: wangqin@ies.ustb.edu.cn 2049 Xavier Vilajosana 2050 Universitat Oberta de Catalunya 2051 156 Rambla Poblenou 2052 Barcelona, Catalonia 08018 2053 Spain 2055 Email: xvilajosana@uoc.edu 2057 Thomas Watteyne 2058 Analog Devices 2059 32990 Alvarado-Niles Road, Suite 910 2060 Union City, CA 94587 2061 USA 2063 Email: thomas.watteyne@analog.com