idnits 2.17.1 draft-ietf-6tisch-6top-protocol-03.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 (October 31, 2016) is 2706 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: 'TEMPORARY' is mentioned on line 1360, but not defined == Outdated reference: A later version (-06) exists of draft-kivinen-802-15-ie-04 ** Downref: Normative reference to an Informational draft: draft-kivinen-802-15-ie (ref. 'I-D.kivinen-802-15-ie') -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802154-2015' -- Obsolete informational reference (is this intentional?): RFC 6982 (Obsoleted by RFC 7942) == Outdated reference: A later version (-21) exists of draft-ietf-6tisch-minimal-16 Summary: 1 error (**), 0 flaws (~~), 4 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: May 4, 2017 Universitat Oberta de Catalunya 6 October 31, 2016 8 6top Protocol (6P) 9 draft-ietf-6tisch-6top-protocol-03 11 Abstract 13 This document defines the 6top Protocol (6P), which enables 14 distributed scheduling in 6TiSCH networks. 6P allows neighbor nodes 15 in a 6TiSCH network to add/delete TSCH cells to one another. 6P is 16 part of the 6TiSCH Operation Sublayer (6top), the next higher layer 17 of the IEEE802.15.4 TSCH medium access control layer. The 6top 18 Scheduling Function (SF) decides when to add/delete cells, and 19 triggers 6P Transactions. Several SFs can be defined, each 20 identified by a different 6top Scheduling Function Identifier (SFID). 21 This document lists the requirements for an SF, but leaves the 22 definition of the SF out of scope. Different SFs are expected to be 23 defined in future companion specifications. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 29 "OPTIONAL" in this document are to be interpreted as described in RFC 30 2119 [RFC2119]. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on May 4, 2017. 49 Copyright Notice 51 Copyright (c) 2016 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. TEMPORARY EDITORIAL NOTES . . . . . . . . . . . . . . . . . . 3 67 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3. 6TiSCH Operation Sublayer (6top) . . . . . . . . . . . . . . 5 69 3.1. Hard/Soft Cells . . . . . . . . . . . . . . . . . . . . . 5 70 3.2. Using 6top with the Minimal 6TiSCH Configuration . . . . 5 71 4. 6top Protocol (6P) . . . . . . . . . . . . . . . . . . . . . 6 72 4.1. 6top Transaction . . . . . . . . . . . . . . . . . . . . 6 73 4.1.1. 2-step 6top Transaction . . . . . . . . . . . . . . . 7 74 4.1.2. 3-step 6top Transaction . . . . . . . . . . . . . . . 8 75 4.2. Message Format . . . . . . . . . . . . . . . . . . . . . 10 76 4.2.1. 6top Information Element . . . . . . . . . . . . . . 10 77 4.2.2. General Message Format . . . . . . . . . . . . . . . 10 78 4.2.3. 6P Message Types . . . . . . . . . . . . . . . . . . 11 79 4.2.4. 6P Command Identifiers . . . . . . . . . . . . . . . 12 80 4.2.5. 6P Return Codes . . . . . . . . . . . . . . . . . . . 12 81 4.2.6. 6P CellOptions . . . . . . . . . . . . . . . . . . . 13 82 4.2.7. 6P Cell Format . . . . . . . . . . . . . . . . . . . 15 83 4.2.8. 6P ADD Request Format . . . . . . . . . . . . . . . . 15 84 4.2.9. 6P DELETE Request Format . . . . . . . . . . . . . . 16 85 4.2.10. 6P STATUS Request Format . . . . . . . . . . . . . . 17 86 4.2.11. 6P LIST Request Format . . . . . . . . . . . . . . . 17 87 4.2.12. 6P CLEAR Request Format . . . . . . . . . . . . . . . 18 88 4.2.13. 6P Response Format . . . . . . . . . . . . . . . . . 19 89 4.2.14. 6P Confirmation Format . . . . . . . . . . . . . . . 20 90 4.3. Protocol Behavior . . . . . . . . . . . . . . . . . . . . 20 91 4.3.1. Version Checking . . . . . . . . . . . . . . . . . . 20 92 4.3.2. SFID Checking . . . . . . . . . . . . . . . . . . . . 20 93 4.3.3. Concurrent 6P Transactions . . . . . . . . . . . . . 21 94 4.3.4. Timeout . . . . . . . . . . . . . . . . . . . . . . . 21 95 4.3.5. SeqNum Mismatch . . . . . . . . . . . . . . . . . . . 21 96 4.3.6. Clearing the Schedule . . . . . . . . . . . . . . . . 22 97 4.3.7. Adding Cells with 2-way Transaction . . . . . . . . . 22 98 4.3.8. Aborting a 6P Transaction . . . . . . . . . . . . . . 22 99 4.3.9. Deleting Cells . . . . . . . . . . . . . . . . . . . 23 100 4.3.10. Listing Cells . . . . . . . . . . . . . . . . . . . . 23 101 4.3.11. Generation Management . . . . . . . . . . . . . . . . 24 102 4.3.12. Handling error responses . . . . . . . . . . . . . . 25 103 4.4. Security . . . . . . . . . . . . . . . . . . . . . . . . 25 104 5. Guidelines for 6top Scheduling Functions (SF) . . . . . . . . 25 105 5.1. SF Identifier (SFID) . . . . . . . . . . . . . . . . . . 26 106 5.2. Requirements for an SF . . . . . . . . . . . . . . . . . 26 107 5.3. Recommended Structure of an SF Specification . . . . . . 27 108 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 27 109 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 110 8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 28 111 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 112 9.1. Normative References . . . . . . . . . . . . . . . . . . 29 113 9.2. Informative References . . . . . . . . . . . . . . . . . 29 114 Appendix A. [TEMPORARY] Changelog . . . . . . . . . . . . . . . 30 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 117 1. TEMPORARY EDITORIAL NOTES 119 This document is an Internet Draft, so work-in-progress by nature. 120 It contains the following work-in-progress elements: 122 o "TODO" statements are elements which have not yet been written by 123 the authors for some reason (lack of time, ongoing discussions 124 with no clear consensus, etc). The statement does indicate that 125 the text will be written at some time. 126 o "TEMPORARY" appendices are there to capture current ongoing 127 discussions, or the changelog of the document. These appendices 128 will be removed in the final text. 129 o "IANA_" identifiers are placeholders for numbers assigned by IANA. 130 These placeholders are to be replaced by the actual values they 131 represent after their assignment by IANA. 132 o The string "REMARK" is put before a remark (questions, suggestion, 133 etc) from an author, editor of contributor. These are on-going 134 discussions at the time to writing, NOT part of the final text. 135 o This section will be removed in the final text. 137 2. Introduction 139 All communication in a 6TiSCH network is orchestrated by a schedule 140 [RFC7554]. This specification defines the 6top Protocol (6P), part 141 of the 6TiSCH Operation sublayer (6top). 6P allow a node to 142 communicate with a neighbor to add/delete a TSCH cell to one another. 143 6P hence enables distributed scheduling in a 6TiSCH network. 145 (R) 146 / \ 147 / \ 148 (B)-----(C) 149 | | 150 | | 151 (A) (D) 153 Figure 1: A simple 6TiSCH network. 155 The example network depicted in Figure 1 is used to describe the 156 interactions between nodes. We consider the canonical case where 157 node "A" issues 6P requests to node "B". We keep this example 158 throughout this document. Throughout the discussions, node A will 159 always represent the node that issues a 6P request; node B the node 160 that receives this request. 162 We consider node A in Figure 1 monitoring the communication cells it 163 has in its schedule to node B. 165 o If node A determines that the number of link-layer frames it is 166 sending to B per unit of time is larger than the capacity offered 167 by the TSCH cells it has scheduled to B, it triggers a 6P 168 Transaction with node B to add one or more cells to B's TSCH 169 schedule. 170 o If the traffic is lower than the capacity, node A triggers a 6P 171 Transaction with node B to delete one or more cells in the TSCH 172 schedule of both nodes. 173 o Node A MAY also monitor statistics to determine whether collisions 174 are happening on a particular cell to node B. If this feature is 175 enabled, node A communicates with node B to add a new cell and 176 delete the cell which suffered from collisions. This conceptually 177 results in "relocating" the cell which suffered from collisions to 178 a different slotOffset/channelOffset location in the TSCH 179 schedule. The mechanism to handle cell relocation is out of the 180 scope of this document and might be handled by the scheduling 181 function (see below). 183 This results in distributed schedule management in a 6TiSCH network. 185 The 6top Scheduling Function (SF) defines when to add/delete a cell 186 to a neighbor. The SF functions as a (required) add-on to 6P. 187 Different applications require different SFs, so the SF is left out 188 of scope of this document. Different SFs are expected to be defined 189 in future companion specifications. A node MAY implement multiple 190 SFs and run them at the same time. The SFID field contained in all 191 6P messages allows a node to switch between SFs on a per-transaction 192 basis. 194 Section 3 describes the 6TiSCH Operation Sublayer (6top). Section 4 195 defines the 6top Protocol (6P). Section 5 provides guidelines on how 196 to design an SF. 198 3. 6TiSCH Operation Sublayer (6top) 200 As depicted in Figure 2, the 6TiSCH Operation Sublayer (6top) is the 201 next higher layer to the IEEE802.15.4 TSCH medium access control 202 layer [IEEE802154-2015]. 204 . 205 | . | 206 | higher layers | 207 +------------------------------------------+ 208 | 6top | 209 +------------------------------------------+ 210 | IEEE802.15.4 TSCH | 211 | . | 212 . 214 Figure 2: The 6top sublayer in the protocol stack. 216 The roles of the 6top sublayer are to: 218 o Implement and terminate the 6top Protocol (6P), which allows 219 neighbor nodes to communicate to add/delete cells to one another. 220 o Run one or more 6top Scheduling Functions (SF), which define the 221 algorithm to decide when to add/delete cells. 223 3.1. Hard/Soft Cells 225 6top qualifies each cell in the schedule as either "hard" or "soft": 227 o a soft cell can be read, added, deleted or updated by 6top. 228 o a hard cell is read-only for 6top. 230 In the context of this specification, all the cells used by 6top are 231 soft cells. Hard cells can be used for example when "hard-coding" a 232 scheduling. This is done, for example, in the Minimal 6TiSCH 233 Configuration [I-D.ietf-6tisch-minimal]. 235 3.2. Using 6top with the Minimal 6TiSCH Configuration 237 6P MAY be used alongside the Minimal 6TiSCH Configuration 238 [I-D.ietf-6tisch-minimal]. In this case, it is RECOMMENDED to use 2 239 slotframes, as depicted in Figure 3: 241 o Slotframe 0 is used for traffic defined in the Minimal 6TiSCH 242 Configuration. In Figure 3, this slotframe is 5 slots long, but 243 it can be of any length. 244 o Slotframe 1 is used by 6top to allocate cells from. In Figure 3, 245 this slotframe is 10 slots long, but it can be of any length. 247 Slotframe 0 SHOULD be of higher priority than Slotframe 1 to avoid 248 for cells in slotframe 1 to "mask" cells in slotframe 0. 6top MAY 249 support further slotframes; how to use more slotframes is out of the 250 scope for this document. 252 | 0 1 2 3 4 | 0 1 2 3 4 | 253 +------------------------+------------------------+ 254 Slotframe 0 | | | | | | | | | | | 255 5 slots long | EB | | | | | EB | | | | | 256 high priority | | | | | | | | | | | 257 +-------------------------------------------------+ 259 | 0 1 2 3 4 5 6 7 8 9 | 260 +-------------------------------------------------+ 261 Slotframe 1 | | | | | | | | | | | 262 10 slots long | |A->B| | | | | | |B->A| | 263 low priority | | | | | | | | | | | 264 +-------------------------------------------------+ 266 Figure 3: 2-slotframe structure when using 6top alongside the Minimal 267 6TiSCH Configuration. 269 4. 6top Protocol (6P) 271 The 6top Protocol (6P) allows two neighbor nodes to communicate to 272 add/delete cells to their TSCH schedule. Conceptually, two neighbor 273 nodes "negotiate" the location of the cell(s) to add/delete. 275 4.1. 6top Transaction 277 We call "6top Transaction" a complete negotiation between two 278 neighbor nodes. A 6P Transaction starts when a node wishes to add/ 279 delete one or more cells to one of its neighbors. It ends when the 280 cell(s) have been added/removed from the schedule of both neighbors, 281 or when the 6P Transaction has failed. 283 A 6P Transaction can consist of 2 or 3 steps. It is the SF which 284 determines whether to use 2-step or 3-step transactions. An SF MAY 285 use both 2-step and 3-step transactions. 287 Consistency between the schedules of two neighbor nodes is of utmost 288 importance. A loss of consistency (e.g. node A has a transmit cell 289 to node B, but node B does not have the corresponding reception cell) 290 can cause loss of connectivity. To verify consistency, neighbors 291 nodes increment the "schedule generation" number of their schedule 292 each time they add/remove a cell. Neighbor nodes exchange generation 293 numbers at each 6P Transaction to detect possible inconsistencies. 294 This mechanism is explained in Section 4.3.11. 296 We reuse the topology in Figure 1 to illustrate 2-step and 3-step 297 transactions. 299 4.1.1. 2-step 6top Transaction 301 Figure 4 is a sequence diagram to help understand the 2-step 6top 302 transaction (several elements are left out to simplify 303 understanding). We assume the SF running on node A determines 2 304 extra cells need to be scheduled to node B. In this example, node A 305 proposes the cells to use. 307 +----------+ +----------+ 308 | Node A | | Node B | 309 +----+-----+ +-----+----+ 310 | | 311 | 6P ADD Request | 312 | NumCells = 2 | 313 | CellList = [(1,2),(2,2),(3,5)] | 314 |-------------------------------------->| 315 | | 316 | 6P Response | 317 | Return Code = RC_SUCCESS | 318 | CellList = [(2,2),(3,5)] | 319 |<--------------------------------------| 320 | | 322 Figure 4: A 2-step 6P Transaction. 324 In this example, the 2-step transaction occurs as follows: 326 1. The SF running on node A selects 3 candidate cells. 327 2. Node A sends a 6P ADD Request to node B, indicating it wishes to 328 add 2 cells (the "NumCells" value), and specifying the list of 3 329 candidate cells (the "CellList" value). Each cell in the 330 CellList is a [slotOffset,channelOffset] tuple. 331 3. Node A at the same time sets a timeout timer to abort the 332 transaction if no response has been received when it expires. 333 The value of the timeout is out of the scope of this document and 334 MAY be defined by the SF. More details are given in 335 Section 4.3.8. 337 4. The SF running on node B selects 2 of the 3 cells in the CellList 338 of the 6P ADD Request. Node B sends back a 6P Response to node 339 A, indicating the cells it selected. 340 5. The result of this 6P Transaction is that 2 cells from A to B 341 have been added to the TSCH schedule of both nodes A and B. 343 4.1.2. 3-step 6top Transaction 345 Figure 5 is a sequence diagram to help understand the 3-step 6top 346 transaction. We assume the SF running on node A determines 2 extra 347 cells need to be scheduled to node B. In this example, node B 348 proposes the cells to use. 350 +----------+ +----------+ 351 | Node A | | Node B | 352 +----+-----+ +-----+----+ 353 | | 354 | 6P ADD Request | 355 | NumCells = 2 | 356 | CellList = [] | 357 |-------------------------------------->| 358 | | 359 | 6P Response | 360 | Return Code = RC_SUCCESS | 361 | CellList = [(1,2),(2,2),(3,5)] | 362 |<--------------------------------------| 363 | | 364 | 6P Confirmation | 365 | Return Code = RC_SUCCESS | 366 | CellList = [(2,2),(3,5)] | 367 |-------------------------------------->| 368 | | 370 Figure 5: A 3-step 6P Transaction. 372 In this example, the 3-step transaction occurs as follows: 374 1. The SF running on node A determines 2 extra cells need to be 375 scheduled to node B, but does not select candidate cells. 376 2. Node A sends a 6P ADD Request to node B, indicating it wishes to 377 add 2 cells (the "NumCells" value), with an empty "CellList". 378 3. Node A at the same time sets a timeout timer to abort the 379 transaction if no response has been received when it expires. 380 The value of the timeout is out of the scope of this document and 381 MAY be defined by the SF. More details are given in 382 Section 4.3.8. 383 4. The SF running on node B selects 3 candidate cells. Node B sends 384 back a 6P Response to node A, indicating the 3 cells it selected. 386 5. Node B at the same time sets a timeout timer to abort the 387 transaction if no response has been received when it expires. 388 The value of the timeout is out of the scope of this document and 389 MAY be defined by the SF. More details are given in 390 Section 4.3.8. 391 6. The SF running on node A selects 2 cells. Node A sends back a 6P 392 Confirmation to node B, indicating the cells it selected. 393 7. The result of this 6P Transaction is that 2 cells from A to B 394 have been added to the TSCH schedule of both nodes A and B. 396 When in a transaction, node A proposes a candidate CellList to node B 397 and B cannot allocate any of those cells. Node B SHOULD respond with 398 a CellList suggesting alternatives. This approach facilitates the 399 agreement between A and B and enables A to not guess what cells may 400 be not used in B. The following figure ilustrated these 3-step 401 transaction. 403 +----------+ +----------+ 404 | Node A | | Node B | 405 +----+-----+ +-----+----+ 406 | | 407 | 6P ADD Request | 408 | NumCells = 2 | 409 | CellList = [(1,2),(2,2),(3,5)] | 410 |-------------------------------------->| 411 | | 412 | 6P Response | 413 | Return Code = RC_SUCCESS | 414 | CellList = [(6,2),(7,2),(8,5)] | 415 |<--------------------------------------| 416 | | 417 | 6P Confirmation | 418 | Return Code = RC_SUCCESS | 419 | CellList = [(7,2),(8,5)] | 420 |-------------------------------------->| 421 | | 423 Figure 6: A 3-step 6P Transaction with cell suggestion. 425 In this example, the 3-step transaction occurs as follows: 427 1. The SF running on node A determines 2 extra cells need to be 428 scheduled to node B, and selects a candidate list of cells. 429 2. Node A sends a 6P ADD Request to node B, indicating it wishes to 430 add 2 cells (the "NumCells" value), with an the proposed 431 "CellList". 432 3. Node A at the same time sets a timeout timer to abort the 433 transaction if no response has been received when it expires. 435 The value of the timeout is out of the scope of this document and 436 MAY be defined by the SF. More details are given in 437 Section 4.3.8. 438 4. The SF running on node B cannot match any of the proposed cells 439 and selects 3 alternative candidate cells. Node B sends back a 440 6P Response to node A, indicating the 3 candidate alternative 441 cells it selected. 442 5. Node B at the same time sets a timeout timer to abort the 443 transaction if no response has been received when it expires. 444 The value of the timeout is out of the scope of this document and 445 MAY be defined by the SF. More details are given in 446 Section 4.3.8. 447 6. The SF running on node A selects 2 cells from the proposed 448 CellList. Node A sends back a 6P Confirmation to node B, 449 indicating the cells it selected. 450 7. The result of this 6P Transaction is that 2 cells from A to B 451 have been added to the TSCH schedule of both nodes A and B. 453 4.2. Message Format 455 4.2.1. 6top Information Element 457 6P messages are carried as payload of IEEE802.15.4 Payload 458 Information Elements (IE) [IEEE802154-2015]. 6p messages travel over 459 a single hop. 461 1 2 3 462 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 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | Payload IE Length |GroupID|T| Sub-ID |6top IE Content 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | Payload Termination IE | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 The 6top IE is an IEEE Payload IE with GroupID IANA_IETF_IE_GROUP_ID. 470 The 6top IE complies with the IE format defined in 471 [I-D.kivinen-802-15-ie]. The Sub-ID used by the 6top IE is 472 IANA_6TOP_SUBIE_ID. The length of the 6top IE content is variable. 473 The content of the 6top IE is specified in Section 4.2. The Payload 474 Termination IE is defined by the IEEE802.15.4 standard 475 [IEEE802154-2015]. 477 4.2.2. General Message Format 479 In all 6P messages, the 6top IE content has the following format: 481 1 2 3 482 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 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 |Version| T | R | Code | SFID | SeqNum|GAB|GBA| 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | Other Fields... 487 +-+-+-+-+-+-+-+-+- 489 Version (6P Version): The version of the 6P protocol. Only version 490 IANA_6TOP_6P_VERSION is defined in this document. Future 491 specifications MAY define further versions of the 6P protocol. 492 Type (T): Type of message. The possible messages types are defined 493 in Section 4.2.3. 494 Reserved (R): These two bits SHOULD be set to zero when sending the 495 message and MUST be ignored on reception. 496 Code: Command to carry out, or response code. The list of command 497 identifiers and return codes is defined only for version 498 IANA_6TOP_6P_VERSION in this document. 499 SFID (6top Scheduling Function Identifier): The identifier of the SF 500 to use to handle this message. The SFID is defined in 501 Section 5.1. 502 SeqNum: An identifier of the packet, used to match the 6P Request, 503 6P Response and 6P Confirmation of the same 6P Transaction. 504 The value of SeqNum MUST increment by exactly one at each new 505 6P request issued to the same neighbor. 506 GAB: Schedule Generation for the cells scheduled from node A to node 507 B. The generation is used to ensure consistency between the 508 schedule of the two neighbors. Section 4.3.11 details how 509 schedule generation is managed. 510 GBA: Schedule Generation for the cells scheduled from node B to node 511 A. 512 Other Fields: The list of other fields depends on the value of the 513 code field, as detailed below. 515 4.2.3. 6P Message Types 517 Figure 7 lists the 6P message types. 519 Value of the "Type" field Meaning 520 +---------------------------+--------------------------------+ 521 | b00 | 6P Request | 522 +---------------------------+--------------------------------+ 523 | b01 | 6P Response | 524 +---------------------------+--------------------------------+ 525 | b10 | 6P Confirmation | 526 | | (3-step 6top Transaction only) | 527 +---------------------------+--------------------------------+ 528 | b11 | Reserved | 529 +---------------------------+--------------------------------+ 531 Figure 7: 6P Message Types 533 4.2.4. 6P Command Identifiers 535 The Code field contains a 6P Command Identifier when 6P Message is a 536 6P Request. Figure 8 lists the 6P command identifiers. 538 Command ID Value Description 539 +--------------+-----------------------+----------------------------+ 540 | CMD_ADD | IANA_6TOP_CMD_ADD | add one or more cells | 541 +--------------+-----------------------+----------------------------+ 542 | CMD_DELETE | IANA_6TOP_CMD_DELETE | delete one or more cells | 543 +--------------+-----------------------+----------------------------+ 544 | CMD_STATUS | IANA_6TOP_CMD_STATUS | status of the schedule | 545 +--------------+-----------------------+----------------------------+ 546 | CMD_LIST | IANA_6TOP_CMD_LIST | list the scheduled cells | 547 | | | in node B | 548 +--------------+-----------------------+----------------------------+ 549 | CMD_CLEAR | IANA_6TOP_CMD_CLEAR | clear all cells on both | 550 | | | node A and node B | 551 +--------------+-----------------------+----------------------------+ 552 | reserved | TODO-0xf | reserved | 553 +--------------+-----------------------+----------------------------+ 555 Figure 8: 6P Command Identifiers 557 4.2.5. 6P Return Codes 559 The Code field contains a 6P Return Code when 6P Message is a 6P 560 Response or a 6P Confirmation. Figure 9 lists the 6P Return Codes 561 and their meaning. 563 Return Code Value Description 564 +--------------+------------------------+---------------------------+ 565 | RC_SUCCESS | IANA_6TOP_RC_SUCCESS | operation succeeded | 566 +--------------+------------------------+---------------------------+ 567 | RC_ERR_VER | IANA_6TOP_RC_ERR_VER | unsupported 6P version | 568 +--------------+------------------------+---------------------------+ 569 | RC_ERR_SFID | IANA_6TOP_RC_ERR_SFID | unsupported SFID | 570 +--------------+------------------------+---------------------------+ 571 | RC_ERR_GEN | IANA_6TOP_RC_ERR_GEN | schedule generation error | 572 +--------------+------------------------+---------------------------+ 573 | RC_ERR_BUSY | IANA_6TOP_RC_ERR_BUSY | handling previous request | 574 +--------------+------------------------+---------------------------+ 575 | RC_ERR_NORES | IANA_6TOP_RC_ERR_NORES | not enough resources | 576 +--------------+------------------------+---------------------------+ 577 | RC_ERR_RESET | IANA_6TOP_RC_ERR_RESET | error in state machine | 578 | | | wrong sequence of | 579 | | | commands | 580 +--------------+------------------------+---------------------------+ 581 | RC_ERR | IANA_6TOP_RC_ERR | generic error | 582 +--------------+------------------------+---------------------------+ 583 | reserved | TODO-0xf | | 584 +--------------+------------------------+---------------------------+ 586 Figure 9: 6P Return Codes 588 4.2.6. 6P CellOptions 590 The 6P CellOptions field is present in the 6P ADD, the 6P DELETE, the 591 6P STATUS and the 6P LIST requests. The 6P CellOptions apply to all 592 elements contained in the CellList field. Hence all cells in the 593 CellList will be of the same type. In the 6P ADD request, it is used 594 to specify what type of cell to add. In the 6P DELETE request, it is 595 used to specify what type of cell to delete. In the 6P STATUS and 596 the 6P LIST requests, it is used as a selector of particular types of 597 cells. Figure 10 contains the RECOMMENDED format of the 6P 598 CellOptions field. Figure 11 contains the RECOMMENDED meaning of the 599 6P CellOptions field for the 6P STATUS and 6P LIST requests. 601 +---------+--------------------+ 602 | bit 0 | Transmit (TX) cell | 603 +---------+--------------------+ 604 | bit 1 | Receive (RX) cell | 605 +---------+--------------------+ 606 | bit 2 | SHARED cell | 607 +---------+--------------------+ 608 | bit 3-7 | Reserved | 609 +---------+--------------------+ 611 Figure 10: Format of the CellOptions field 613 Note: assuming node A issues the 6P command to node B. 614 +-------------+-----------------------------------------------+ 615 | CellOptions | B's action when receiving a 6P message from A | 616 | Value | | 617 +-------------+-----------------------------------------------+ 618 |TX=0,RX=0,S=0| select all cells scheduled with A | 619 +-------------+-----------------------------------------------+ 620 |TX=1,RX=0,S=0| select the cells scheduled with A | 621 | | and marked as RX | 622 +-------------+-----------------------------------------------+ 623 |TX=0,RX=1,S=0| select the cells scheduled with A | 624 | | and marked as TX | 625 +-------------+-----------------------------------------------+ 626 |TX=1,RX=1,S=0| select the cells scheduled with A | 627 | | and marked as TX and RX | 628 +-------------+-----------------------------------------------+ 629 |TX=0,RX=0,S=1| select the cells scheduled with A | 630 | | and marked as SHARED | 631 +-------------+-----------------------------------------------+ 632 |TX=1,RX=0,S=1| select the cells scheduled with A | 633 | | and marked as RX and SHARED | 634 +-------------+-----------------------------------------------+ 635 |TX=0,RX=1,S=1| select the cells scheduled with A | 636 | | and marked as TX and SHARED | 637 +-------------+-----------------------------------------------+ 638 |TX=1,RX=1,S=1| select the cells scheduled with A | 639 | | and marked as TX and RX and SHARED | 640 +-------------+-----------------------------------------------+ 642 Figure 11: Meaning of the 6P CellOptions field for the 6P STATUS and 643 the 6PLIST requests 645 The CellOptions is an opaque set of bits, sent unmodified to the SF. 646 The SF MAY redefine the format of the CellOptions field. The SF MAY 647 redefine the meaning of the CellOptions field. 649 4.2.7. 6P Cell Format 651 A CellList field MAY be present in a 6P ADD Request, 6P DELETE 652 Request, a 6P Response or a 6P Confirmation. It is composed of zero, 653 one of more 6P Cell containers. The CellOptions field defines the 654 type of the cells in a particular CellList. All cells in the 655 CellList will be of the same type. The 6P Cell is a 4-byte field, 656 its RECOMMENDED format is: 658 1 2 3 659 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 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | slotOffset | channelOffset | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 slotOffset: The slot offset of the cell. 665 channelOffset: The channel offset of the cell. 667 The CellList is an opaque set of bytes, sent unmodified to the SF. 668 The SF MAY redefine the format of the CellList field. 670 4.2.8. 6P ADD Request Format 672 1 2 3 673 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 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 |Version| T | R | Code | SFID | SeqNum|GAB|GBA| 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 | Metadata | CellOptions | NumCells | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | CellList ... 680 +-+-+-+-+-+-+-+-+- 682 Version: Set to IANA_6TOP_6P_VERSION. 683 Type: Set to 6P Request (see Figure 7). 684 Reserved: Set to 0. 685 Code: Set to CMD_ADD (see Section 4.2.4). 686 SFID: Identifier of the SF to be used by the receiver to handle the 687 message. 688 SeqNum: Packet identifier to match 6P Request and 6P Response. 689 GAB: Schedule Generation for the cells scheduled from node A to node 690 B. 691 GBA: Schedule Generation for the cells scheduled from node B to node 692 A. 693 Metadata: Metadata used as extra signaling to the SF. The contents 694 of the Metadata field is an opaque set of bytes, and passed 695 unmodified to the SF. The meaning of this field depends on the 696 SF, and is out of scope of this document. One example use can 697 be to specify which slotframe to schedule the cells to. 698 CellOptions: Indicates the type of cells to add. All cells in the 699 CellList for a particular request will use the same CellOption. 700 When different types of cells need to be allocated those need 701 to be handled in separate ADD requests using different 702 CellOptions. The CellOptions is an opaque set of bits, sent 703 unmodified to the SF. The RECOMMENDED format of the 704 CellOptions field is defined in Section 4.2.6. The SF MAY 705 redefine the format or the meaning of the CellOptions field. 706 NumCells: The number of additional cells the sender wants to 707 schedule to the receiver according. 708 CellList: A list of 0, 1 or multiple 6P Cells. The CellList is an 709 opaque set of bytes, sent unmodified to the SF. The 710 RECOMMENDED format of each 6P Cell is defined in Section 4.2.7. 711 The SF MAY redefine the format of the CellList field. 713 4.2.9. 6P DELETE Request Format 715 1 2 3 716 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 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 |Version| T | R | Code | SFID | SeqNum|GAB|GBA| 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 | Metadata | CellOptions | NumCells | 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 | CellList ... 723 +-+-+-+-+-+-+-+-+- 725 Version: Set to IANA_6TOP_6P_VERSION. 726 Type: Set to 6P Request (see Figure 7). 727 Reserved: Set to 0. 728 Code: Set to CMD_DELETE (see Section 4.2.4). 729 SFID: Identifier of the SF to be used by the receiver to handle the 730 message. 731 SeqNum: Packet identifier to match 6P Request and 6P Response. 732 GAB: Schedule Generation for the cells scheduled from node A to node 733 B. 734 GBA: Schedule Generation for the cells scheduled from node B to node 735 A. 736 Metadata: Metadata used as extra signaling to the SF. The contents 737 of the Metadata field is an opaque set of bytes, and passed 738 unmodified to the SF. The meaning of this field depends on the 739 SF, and is hence out of scope of this document. One example 740 use can be to specify which slotframe to delete the cells from. 741 CellOptions: Indicates the type of cells to delete. The CellOptions 742 is an opaque set of bits, sent unmodified to the SF. The 743 RECOMMENDED format of the CellOptions field is defined in 744 Section 4.2.6. The SF MAY redefine the format or the meaning 745 of the CellOptions field. 746 NumCells: The number of cells from the specified CellList the sender 747 wants to delete from the schedule of both sender and receiver. 748 CellList: A list of 0, 1 or multiple 6P Cells. The CellList is an 749 opaque set of bytes, sent unmodified to the SF. The 750 RECOMMENDED format of each 6P Cell is defined in Section 4.2.7. 751 The SF MAY redefine the format of the CellList field. 753 4.2.10. 6P STATUS Request Format 755 1 2 756 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 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 |Version| T | R | Code | SFID | SeqNum|GAB|GBA| 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 | Metadata | CellOptions | 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 Version: Set to IANA_6TOP_6P_VERSION. 764 Type: Set to 6P Request (see Figure 7). 765 Reserved: Set to 0. 766 Code: Set to CMD_STATUS (see Section 4.2.4). 767 SFID: Identifier of the SF to be used by the receiver to handle the 768 message. 769 SeqNum: Packet identifier to match request and response. 770 GAB: Schedule Generation for the cells scheduled from node A to node 771 B. 772 GBA: Schedule Generation for the cells scheduled from node B to node 773 A. 774 Metadata: Metadata used as extra signaling to the SF. The contents 775 of the Metadata field is an opaque set of bytes, and passed 776 unmodified to the SF. The meaning of this field depends on the 777 SF, and is hence out of scope of this document. One example 778 use can be to specify which slotframe to get the status from. 779 CellOptions: Further selects which types of cells to be considered. 780 The CellOptions is an opaque set of bits, sent unmodified to 781 the SF. The RECOMMENDED format and meaning of the CellOptions 782 field is defined in Section 4.2.6. The SF MAY redefine the 783 format or the meaning of the CellOptions field. 785 4.2.11. 6P LIST Request Format 787 The command lists the cells scheduled from node A to node B according 788 to the specified CellOptions. 790 1 2 791 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 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 |Version| T | R | Code | SFID | SeqNum|GAB|GBA| 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 | Metadata | CellOptions | Reserved | 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 | Offset | MaxNumCells | 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 Version: Set to IANA_6TOP_6P_VERSION. 801 Type: Set to 6P Request (see Figure 7). 802 Reserved: Set to 0. 803 Code: Set to CMD_LIST (see Section 4.2.4). 804 SFID: Identifier of the SF to be used by the receiver to handle the 805 message. 806 SeqNum: Packet identifier to match request and response. 807 GAB: Schedule Generation for the cells scheduled from node A to node 808 B. 809 GBA: Schedule Generation for the cells scheduled from node B to node 810 A. 811 Metadata: Metadata used as extra signaling to the SF. One example 812 use can be to specify which slotframe to list the cells from. 813 The contents of the Metadata field is an opaque set of bytes, 814 and passed unmodified to the SF. The meaning of this field 815 depends on the SF, and is hence out of scope of this document. 816 CellOptions: Further selects which types of cells to be considered. 817 The CellOptions is an opaque set of bits, sent unmodified to 818 the SF. The RECOMMENDED format and meaning of the CellOptions 819 field is defined in Section 4.2.6. The SF MAY redefine the 820 format or the meaning of the CellOptions field. 821 Reserved: Set to 0. 822 Offset: The Offset of the first scheduled cell that is requested. 823 The mechanism assumes cells are ordered according to some rule. 824 The ordering rule is defined by the SF. 825 MaxNumCells: The maximum number of requested cells. Less cells than 826 MaxNumCells can be returned if they do not fit in the packet. 828 4.2.12. 6P CLEAR Request Format 830 1 2 831 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 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 |Version| T | R | Code | SFID | SeqNum|GAB|GBA| 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 | Metadata | 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 838 Version: Set to IANA_6TOP_6P_VERSION. 839 Type: Set to 6P Request (see Figure 7). 840 Reserved: Set to 0. 841 Code: Set to CMD_CLEAR (see Section 4.2.4). 842 SFID: Identifier of the SF to be used by the receiver to handle the 843 message. 844 SeqNum: Packet identifier to match request and response. 845 GAB: Schedule Generation for the cells scheduled from node A to node 846 B. 847 GBA: Schedule Generation for the cells scheduled from node B to node 848 A. 849 Metadata: Metadata used as extra signaling to the SF. One example 850 use can be to specify which slotframe to be cleared. The 851 contents of the Metadata field is an opaque set of bytes, and 852 passed unmodified to the SF. The meaning of this field depends 853 on the SF, and is hence out of scope of this document. 855 4.2.13. 6P Response Format 857 1 2 3 858 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 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 |Version| T | R | Code | SFID | SeqNum|GAB|GBA| 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 | Other Fields... 863 +-+-+-+-+-+-+-+-+- 865 Version: Set to IANA_6TOP_6P_VERSION. 866 Type: Set to 6P Response (see Figure 7). 867 Reserved: Set to 0. 868 Code: One of the 6P Return Codes listed in Section 4.2.5. 869 SFID: Identifier of the SF to be used by the receiver to handle the 870 message. The response MUST contain the same SFID value as the 871 value in the SFID field of the 6P Request is responds to. 872 SeqNum: Packet identifier to match request and response. The 873 response MUST contain the same SeqNum value as the value in the 874 SeqNum field of the 6P Request is responds to. 875 GAB: Schedule Generation for the cells scheduled from node A to node 876 B. 877 GBA: Schedule Generation for the cells scheduled from node B to node 878 A. 879 Other Fields: The contents depends on the Code field in the request, 880 and listed below. 882 When responding to an ADD, DELETE, LIST request, the "Other Field" 883 contains a list of 0, 1 or multiple 6P Cells. The format of a 6P 884 Cell is defined in Section 4.2.7. 886 When responding to an STATUS request, the "Other Field" contains the 887 number of cells scheduled between node A and node B that match the 888 CellOptions field, encoded as a 2-octet unsigned integer. This is 889 shown in Figure 12. 891 1 2 3 892 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 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 |Version| T | R | Code | SFID | SeqNum|GAB|GBA| 895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 | Num. Cells | 897 +-+-+-+-+-+-+-+-+ 899 Figure 12 901 When responding to an CLEAR request, the "Other Field" is empty. 903 4.2.14. 6P Confirmation Format 905 A 6P Confirmation is only used in a 3-step transaction, as the third 906 step. A 6P Confirmation Message has the exact same format as a 6P 907 Response Message, except that the Type field is set to 6P 908 Confirmation (see Figure 7). The same Return Codes are used in both 909 6P Response and 6P Confirmation messages. The confirmation MUST 910 contain the same SeqNum value as the value in the SeqNum field of the 911 6P Request and 6P Response of the same transaction. 913 4.3. Protocol Behavior 915 We use the topology in Figure 1 for illustration. We assume node A 916 negotiates to add/delete cells to node B. 918 4.3.1. Version Checking 920 All messages contain a Version field. If multiple Versions of the 6P 921 protocol have been defined (in future specifications for Version 922 values different than IANA_6TOP_6P_VERSION), a node MAY implement 923 multiple protocol versions at the same time. When receiving a 6P 924 message with a Version number it does not implement, a node MUST 925 reply with a 6P Response and a return code of RC_ERR_VER. The 926 Version field in the 6P Response MUST be the same as the Version 927 field in the corresponding 6P Request. 929 4.3.2. SFID Checking 931 All messages contain a SFID field. A node MAY support multiple SFs 932 at the same time. When receiving a 6P message with an unsupported 933 SFID, a node MUST reply with a 6P Response and a return code of 934 RC_ERR_SFID. The Version field in the 6P Response MUST be the same 935 as the Version field in the corresponding 6P Request. In a 3-step 936 transaction, the Version field in the 6P Confirmation MUST match that 937 of the 6P Request and 6P Response in the same transaction. 939 4.3.3. Concurrent 6P Transactions 941 Only a single 6P Transaction between two neighbors, in a given 942 direction, can take place at the same time. That is, a node MUST NOT 943 issue a new 6P Request to a given neighbor before having received the 944 6P Response for a previous request to that neighbor. The only 945 exception to this rule is when the previous 6P Transaction has timed 946 out. If a node receives a 6P Request from a given neighbor before 947 having sent the 6P Response to the previous 6P Request from that 948 neighbor, it MUST send back a 6P Response with a return code of 949 RC_ERR_RESET. A node receiving RC_ERR_RESET MUST abort the 950 transaction and consider it never happened. 952 Nodes A and B MAY support having two transactions going on at the 953 same time, one in each direction. Similarly, a node MAY support 954 concurrent 6P Transactions from different neighbors. In this case, 955 the cells involved in an ongoing 6P Transaction MUST be locked until 956 the transaction finishes. For example, in Figure 1, node C can have 957 a different ongoing 6P Transaction with nodes B and R. In case a 958 node does not have enough resources to handle concurrent 6P 959 Transactions from different neighbors it MUST reply with a 6P 960 Response with return code RC_ERR_NORES. In case the requested cells 961 are locked, it MUST reply to that request with a 6P Response with 962 return code RC_ERR_BUSY. The node receiving RC_ERR_BUSY or an 963 RC_ERR_NORES may implement a retry mechanism, as defined by the SF. 965 4.3.4. Timeout 967 A timeout happens when the node sending the 6P Request has not 968 received the 6P Response. The timeout should be longer than the 969 longest possible time it can take for the 6P Transaction to finish. 970 The value of the timeout hence depends on the number of cells 971 schedule between the neighbor nodes, on the maximum number of link- 972 layer retransmissions, etc. The SF determines the value of the 973 timeout. The value of the timeout is out of scope of this document. 975 4.3.5. SeqNum Mismatch 977 When a node receives a 6P Response with SeqNum value different from 978 the SeqNum value in the 6P Request, it MUST drop the packet and 979 consider the 6P Transaction as having failed. This rules applies as 980 well to a 6P Confirmation with a SeqNum value different from that of 981 the 6P Request or 6P Response of the same transaction. 983 4.3.6. Clearing the Schedule 985 When a 6P CLEAR command is issued from node A to node B, both nodes A 986 and B MUST remove all the cells scheduled between them. That is, 987 node A MUST remove all the cells is has scheduled with B, and node B 988 MUST remove all the cells is has scheduled with A. In a 6P CLEAR 989 command, the generation counters GAB and GBA MUST NOT be checked. 990 That is, their value is "don't care". In particular, even if a 991 schedule generation mismatch is detected, it MUST NOT cause the 992 transaction to abort. 994 4.3.7. Adding Cells with 2-way Transaction 996 We assume the topology in Figure 1 where the SF on node A decides to 997 add NumCells cells to node B. 999 Node A's SF selects NumCandidate>=NumCells cells from its schedule as 1000 candidate cells to node B. The CellOptions field specifies the type 1001 of this cells. NumCandidate MUST be larger or equal to NumCells. 1002 How many cells it selects (NumCandidate) and how that selection is 1003 done is specified in the SF and out of scope of this document. Node 1004 A sends a 6P ADD Request to node B which contains the CellOptions, 1005 the value of NumCells and a seleciton of NumCandidate cells in the 1006 CellList. 1008 Upon receiving the request, node B's SF verifies which of the cells 1009 in the CellList it can install in its schedule following the 1010 specified CellOptions field. How that selection is done is specified 1011 in the SF and out of scope of this document. That verification can 1012 succeed (NumCells cells from the CellList can be used), fail (none of 1013 the cells from the CellList can be used) or partially succeed (less 1014 than NumCells cells from the CellList can be used). In all cases, 1015 node B MUST send a 6P Response with return code set to RC_SUCCESS, 1016 and which specifies the list of cells that were scheduled following 1017 the CellOptions field. That can contain 0 elements (when the 1018 verification failed), NumCells elements (succeeded) or between 0 and 1019 NumCells elements (partially succeeded). 1021 Upon receiving the response, node A adds the cells specified in the 1022 CellList according to the request CellOptions field. 1024 4.3.8. Aborting a 6P Transaction 1026 In case the receiver of a 6top request fails during a 6P Transaction 1027 and is unable to complete it, it SHOULD reply to that request with a 1028 6P Response with return code RC_ERR_RESET. Upon receiving this 6top 1029 reply, the initiator of the 6P Transaction MUST consider the 6P 1030 Transaction as failed. 1032 4.3.9. Deleting Cells 1034 The behavior for deleting cells is equivalent to that of adding cells 1035 except that: 1037 o The nodes delete the cells they agree upon rather than adding 1038 them. 1039 o All cells in the CellList MUST already be scheduled between the 1040 two nodes and match the CellOptions field. If node A puts cells 1041 in its CellList that are not already scheduled between the two 1042 nodes and match the CellOptions field, node B replies with a 1043 RC_ERR_RESET return code. 1044 o If the CellList in the 6P Request is empty, the SF on the 1045 receiving node is free to delete any cell from the sender, as long 1046 as it matches the CellOptions field. 1047 o The CellList in a 6P Request (2-step transaction) or 6P Response 1048 (3-step transaction) MUST either be empty, contain exactly 1049 NumCells cells, or more than NumCells cells. The case where the 1050 CellList is not empty but contains less than NumCells cells is not 1051 supported. 1053 4.3.10. Listing Cells 1055 When a node A issues a LIST command, it specifies: 1057 o Through the CellOptions field, the type of cells to list, 1058 according to Section 4.2.6. 1059 o Through the Offset field, the offset of the first CellOptions type 1060 cell to be present in the returned list. The cell ordering policy 1061 is defined by the SF. 1062 o Through the MaxNumCells field, the maximum number of cells to be 1063 present in the response. 1065 When receiving a LIST command, node B returns the cells in its 1066 schedule that match the CellOptions field as specified in 1067 Section 4.2.6 The RECOMMENDED format of each 6P Cell is defined in 1068 Section 4.2.7. The SF MAY redefine the format of the CellList field. 1070 When node B receives a LIST request, the returned CellList in the 6P 1071 Response contains between 1 and MaxNumCells cells, starting from the 1072 specified Offset, as many as fit in the frame. Node B MUST return at 1073 least one cell, unless the specified Offset is beyond the end of B's 1074 cell list in its schedule. If node B has less than Offset cells of 1075 CellOptions type, the CellList it returns is empty. 1077 4.3.11. Generation Management 1079 For each neighbor, a node maintains 2 two-bit generation numbers. 1080 These numbers are variables internal to the node. 1082 o GTX is the generation number for the transmission cells to the 1083 neighbor. 1084 o GRX is the generation number for the receive cells from the 1085 neighbor. 1087 4.3.11.1. Incrementing GTX and GRX 1089 GTX and GRX are 2-bit variables. Their possible values are: 1091 Value Meaning 1092 +-----------+---------------------------+ 1093 | 0b00 | Clear or never scheduled | 1094 +-----------+---------------------------+ 1095 | 0b01-0b10 | Lollipop Counter values | 1096 +-----------+---------------------------+ 1097 | 0b11 | Reserved | 1098 +-----------+---------------------------+ 1100 Figure 13: Possible values of the GRX and GTX generation numbers. 1102 GTX and GRX are set to 0 upon initialization, and after a 6P CLEAR 1103 command. GTX and GRX are incremented by 1 after each time a cell 1104 with that neighbor is added/deleted from the schedule (e.g. after a 1105 successful 6P ADD or 6P DELETE transactions). The value rolls from 1106 0b10 to 0b01. This results in a lollipop counter with 0x00 as the 1107 start value, and 0b01 and 0b10 the count values. 1109 4.3.11.2. Setting GAB and GBA fields 1111 Each 6P message contains a GAB and a GBA field, used to indicate the 1112 current generation counters of the node transmitting the message. 1113 The value of the GAB and GBA fields MUST be set according to the 1114 following rules: 1116 o When node A sends a 6P Request or 6P confirmation to node B, node 1117 A sets GAB to its GTX and GBA to its GRX. 1118 o When node B sends a 6P Response to node A, node B sets GAB to its 1119 GRX and GBA to its GTX. 1121 4.3.11.3. Detecting and Handling Schedule Generation Inconsistencies 1123 Upon receiving a 6P message, a node MUST do the following checks: 1125 o When node B receives a 6P Request of 6P confirmation from node A, 1126 it verifies that GAB==GRX and GBA==GTX. 1127 o When node A receives a 6P Response from node B, it verifies that 1128 GAB==GTX and GBA==GRX. 1130 If any of these comparisons is false, the node has detected a 1131 schedule generation inconsistency. 1133 When a schedule generation inconsistency is detected: 1135 o If the code of the 6P Request is different from CMD_CLEAR, the 1136 node MUST reply with error code RC_ERR_GEN. 1137 o If the code of the 6P Request is CMD_CLEAR, the schedule 1138 generation inconsistency MUST be ignored. 1140 It is up to the Scheduling Function to define the action to take when 1141 an schedule generation inconsistency is detected. The RECOMMENDED 1142 action is to issue a 6P CLEAR command. 1144 4.3.12. Handling error responses 1146 A return code with a name starting with "RC_ERR" in Figure 9 1147 indicates an error. When a node receives a 6P Response with such an 1148 error, it MUST consider the 6P Transaction failed. In particular, if 1149 this was a response to a 6P ADD/DELETE Request, the node MUST NOT 1150 add/delete any of the cells involved in this 6P Transaction. 1151 Similarly, a node sending a 6P Response with an "RC_ERR" return code 1152 MUST NOT add/delete any cells as part of that 6P Transaction. 1153 Defining what to do after an error has occurred is out of scope of 1154 this document. The SF defines what to do after an error has 1155 occurred. 1157 4.4. Security 1159 6P messages are secured through link-layer security. When link-layer 1160 security is enabled, the 6P messages MUST be secured. This is 1161 possible because 6P messages are carried as Payload IE. 1163 5. Guidelines for 6top Scheduling Functions (SF) 1164 5.1. SF Identifier (SFID) 1166 Each SF has an identifier. The identifier is encoded as a 1-byte 1167 field. The identifier space is divided in the following ranges. 1169 Range Meaning 1170 +-----------+-------------+ 1171 | 0x00-0xef | managed | 1172 +-----------+-------------- 1173 | 0xf0-0xfe | unmanaged | 1174 +-----------+-------------+ 1175 | 0xff | reserved | 1176 +-----------+-------------+ 1178 Figure 14: SFID range. 1180 SF identifiers in the managed space MUST be managed by IANA. 1182 5.2. Requirements for an SF 1184 The specification for an SF 1186 o MUST specify an identifier for that SF. 1187 o MUST specify the rule for a node to decide when to add/delete one 1188 or more cells to a neighbor. 1189 o MUST specify the rule for a Transaction source to select cells to 1190 add to the CellList field in the 6P ADD Request. 1191 o MUST specify the rule for a Transaction destination to select 1192 cells from CellList to add to its schedule. 1193 o MUST specify a value for the 6P Timeout, or a rule/equation to 1194 calculate it. 1195 o MUST specify a meaning for the "Metadata" field in the 6P ADD 1196 Request. 1197 o MUST specify the behavior of a node when it boots. 1198 o MUST specify what to do after an error has occurred (either the 1199 node sent a 6P Response with an error code, or received one). 1200 o MUST specify the list of statistics to gather. An example 1201 statistic if the number of transmitted frames to each neighbor. 1202 In case the SF requires no statistics to be gathered, the specific 1203 of the SF MUST explicitly state so. 1204 o SHOULD clearly state the application domain the SF is created for. 1205 o SHOULD contain examples which highlight normal and error 1206 scenarios. 1207 o SHOULD contain a list of current implementations, at least during 1208 the I-D state of the document, per [RFC6982]. 1209 o SHOULD contain a performance evaluation of the scheme, possibly 1210 through references to external documents. 1211 o MAY redefine the format of the CellList field. 1213 o MAY redefine the format of the CellOptions field. 1214 o MAY redefine the meaning of the CellOptions field. 1216 5.3. Recommended Structure of an SF Specification 1218 The following section structure for a SF document is RECOMMENDED: 1220 o Introduction 1221 o Scheduling Function Identifier 1222 o Rules for Adding/Deleting Cells 1223 o Rules for CellList 1224 o 6P Timeout Value 1225 o Meaning of the Metadata Field 1226 o Node Behavior at Boot 1227 o 6P Error Handling 1228 o Examples 1229 o Implementation Status 1230 o Security Considerations 1231 o IANA Considerations 1233 6. Implementation Status 1235 This section records the status of known implementations of the 1236 protocol defined by this specification at the time of posting of this 1237 Internet-Draft, and is based on a proposal described in [RFC6982]. 1238 The description of implementations in this section is intended to 1239 assist the IETF in its decision processes in progressing drafts to 1240 RFCs. Please note that the listing of any individual implementation 1241 here does not imply endorsement by the IETF. Furthermore, no effort 1242 has been spent to verify the information presented here that was 1243 supplied by IETF contributors. This is not intended as, and must not 1244 be construed to be, a catalog of available implementations or their 1245 features. Readers are advised to note that other implementations may 1246 exist. 1248 According to [RFC6982], "this will allow reviewers and working groups 1249 to assign due consideration to documents that have the benefit of 1250 running code, which may serve as evidence of valuable experimentation 1251 and feedback that have made the implemented protocols more mature. 1252 It is up to the individual working groups to use this information as 1253 they see fit". 1255 ETSI 6TiSCH/6lo plugtests: 6P was one of the protocols addressed 1256 during the ETSI 6TiSCH #3 plugtests organized on 15-17 July 2016 1257 in Berlin, Germany. 15 entities participated in this event, 1258 verifying the compliance and interoperability of their 1259 implementation of 6P. This event happened under NDA, so neither 1260 the name of the entities nor the test results are public. This 1261 event is, however, a clear indication of the maturity of 6P, and 1262 the interest it generates. More information about the event at 1263 http://www.etsi.org/news-events/events/1077-6tisch-6lo-plugtests. 1264 ETSI 6TiSCH #2 plugtests: 6P was one of two protocols addressed 1265 during the ETSI 6TiSCH #2 plugtests organized on 2-4 February 2016 1266 in Paris, France. 14 entities participated in this event, 1267 verifying the compliance and interoperability of their 1268 implementation of 6P. This event happened under NDA, so neither 1269 the name of the entities nor the test results are public. This 1270 event is, however, a clear indication of the maturity of 6P, and 1271 the interest it generates. More information about the event at 1272 http://www.etsi.org/news-events/events/1022-6TiSCH-2-plugtests. 1273 OpenWSN: 6P is implemented in the OpenWSN project [OpenWSN] under a 1274 BSD open-source license. The authors of this document are 1275 collaborating with the OpenWSN community to gather feedback about 1276 the status and performance of the protocols described in this 1277 document. Results from that discussion will appear in this 1278 section in future revision of this specification. More 1279 information about this implementation at http://www.openwsn.org/. 1280 Wireshark Dissector: A Wireshark dissector for 6P is implemented 1281 under a BSD open-source license. It is not yet merged into the 1282 main Wireshark build, but can be downloaded at https://github.com/ 1283 openwsn-berkeley/dissectors/. 1285 7. Security Considerations 1287 6P messages are carried inside IEEE802.15.4 Payload Information 1288 Elements (IEs). Those Payload IEs are encrypted and authenticated at 1289 the link layer through CCM*. 6P benefits from the same level of 1290 security as any other Payload IE. The 6P protocol does not define 1291 its own security mechanisms. A key management solution is out of 1292 scope for this document. The 6P protocol will benefit for the key 1293 management solution used in the network. 1295 8. IANA Consideration 1297 TODO: write out this section as soon as the discussion with the IEEE 1298 about a possible IETF IE ID has concluded. 1300 o TODO: IANA_IETF_IE_GROUP_ID 1301 o TODO: IANA_6TOP_SUBIE_ID 1302 o TODO: IANA_6TOP_6P_VERSION 1303 o TODO: IANA_6TOP_CMD_ADD 1304 o TODO: IANA_6TOP_CMD_DELETE 1305 o TODO: IANA_6TOP_CMD_STATUS 1306 o TODO: IANA_6TOP_CMD_LIST 1307 o TODO: IANA_6TOP_CMD_CLEAR 1308 o TODO: IANA_6TOP_RC_SUCCESS 1309 o TODO: IANA_6TOP_RC_ERR_VER 1310 o TODO: IANA_6TOP_RC_ERR_SFID 1311 o TODO: IANA_6TOP_RC_ERR_GEN 1312 o TODO: IANA_6TOP_RC_ERR_BUSY 1313 o TODO: IANA_6TOP_RC_ERR_NORES 1314 o TODO: IANA_6TOP_RC_ERR_RESET 1315 o TODO: IANA_6TOP_RC_ERR 1317 9. References 1319 9.1. Normative References 1321 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1322 Requirement Levels", BCP 14, RFC 2119, 1323 DOI 10.17487/RFC2119, March 1997, 1324 . 1326 [I-D.kivinen-802-15-ie] 1327 Kivinen, T. and P. Kinney, "IEEE 802.15.4 Information 1328 Element for IETF", draft-kivinen-802-15-ie-04 (work in 1329 progress), October 2016. 1331 [IEEE802154-2015] 1332 IEEE standard for Information Technology, "IEEE Std 1333 802.15.4-2015 - IEEE Standard for Low-Rate Wireless 1334 Personal Area Networks (WPANs)", October 2015. 1336 9.2. Informative References 1338 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 1339 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 1340 Internet of Things (IoT): Problem Statement", RFC 7554, 1341 DOI 10.17487/RFC7554, May 2015, 1342 . 1344 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1345 Code: The Implementation Status Section", RFC 6982, 1346 DOI 10.17487/RFC6982, July 2013, 1347 . 1349 [I-D.ietf-6tisch-minimal] 1350 Vilajosana, X. and K. Pister, "Minimal 6TiSCH 1351 Configuration", draft-ietf-6tisch-minimal-16 (work in 1352 progress), June 2016. 1354 [OpenWSN] Watteyne, T., Vilajosana, X., Kerkez, B., Chraim, F., 1355 Weekly, K., Wang, Q., Glaser, S., and K. Pister, "OpenWSN: 1356 a Standards-Based Low-Power Wireless Development 1357 Environment", Transactions on Emerging Telecommunications 1358 Technologies , August 2012. 1360 Appendix A. [TEMPORARY] Changelog 1362 o draft-ietf-6tisch-6top-protocol-03 1364 * Added a reference to [I-D.kivinen-802-15-ie]. 1365 * Added the Type field. 1366 * Editorial changes (figs, typos, ...) 1367 o draft-ietf-6tisch-6top-protocol-02 1369 * Rename COUNT to STATUS 1370 * Split LIST to LIST AB and LIST BA 1371 * Added generation counters and describing generation tracking of 1372 the schedule 1373 * Editorial changes (figs, typos, ...) 1374 o draft-ietf-6tisch-6top-protocol-01 1376 * Clarifying locking of resources in concurrent transactions 1377 * Clarifying return of RC_ERR_BUSY in case of concurrent 1378 transactions without enough resources 1379 o draft-ietf-6tisch-6top-protocol-00 1381 * Informational to Std track 1382 o draft-wang-6tisch-6top-protocol-00 1384 * Editorial overhaul: fixing typos, increasing readability, 1385 clarifying figures. 1386 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1387 issues/47 1388 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1389 issues/54 1390 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1391 issues/55 1392 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1393 issues/49 1394 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1395 issues/53 1396 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1397 issues/44 1398 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1399 issues/48 1400 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1401 issues/43 1403 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1404 issues/52 1405 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1406 issues/45 1407 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1408 issues/51 1409 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1410 issues/50 1411 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1412 issues/46 1413 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1414 issues/41 1415 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1416 issues/42 1417 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1418 issues/39 1419 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1420 issues/40 1421 o draft-wang-6tisch-6top-sublayer-05 1423 * Specifies format of IE 1424 * Adds token in messages to match request and response 1425 o draft-wang-6tisch-6top-sublayer-04 1427 * Renames IANA_6TOP_IE_GROUP_ID to IANA_IETF_IE_GROUP_ID. 1428 * Renames IANA_CMD and IANA_RC to IANA_6TOP_CMD and IANA_6TOP_RC. 1429 * Proposes IANA_6TOP_SUBIE_ID with value 0x00 for the 6top sub- 1430 IE. 1431 o draft-wang-6tisch-6top-sublayer-03 1433 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 1434 protocol/issues/32/missing-command-list 1435 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 1436 protocol/issues/31/missing-command-count 1437 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 1438 protocol/issues/30/missing-command-clear 1439 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1440 issues/37/6top-atomic-transaction-6p-transaction 1441 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 1442 protocol/issues/35/separate-opcode-from-rc 1443 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 1444 protocol/issues/36/add-length-field-in-ie 1445 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 1446 protocol/issues/27/differentiate-rc_err_busy-and 1447 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 1448 protocol/issues/29/missing-rc-rc_reset 1449 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 1450 protocol/issues/28/the-sf-must-specify-the-behavior-of-a-mote 1452 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 1453 protocol/issues/26/remove-including-their-number 1454 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1455 issues/34/6of-sf 1456 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 1457 protocol/issues/33/add-a-figure-showing-the-negociation 1458 o draft-wang-6tisch-6top-sublayer-02 1460 * introduces the 6P protocol and the notion of 6top Transaction. 1461 * introduces the concept of 6OF and its 6OFID. 1463 Authors' Addresses 1465 Qin Wang (editor) 1466 Univ. of Sci. and Tech. Beijing 1467 30 Xueyuan Road 1468 Beijing, Hebei 100083 1469 China 1471 Phone: +86 (10) 6233 4781 1472 Email: wangqin@ies.ustb.edu.cn 1474 Xavier Vilajosana 1475 Universitat Oberta de Catalunya 1476 156 Rambla Poblenou 1477 Barcelona, Catalonia 08018 1478 Spain 1480 Phone: +34 (646) 633 681 1481 Email: xvilajosana@uoc.edu