idnits 2.17.1 draft-wang-6tisch-6top-sublayer-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 19, 2015) is 3084 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TEMPORARY' is mentioned on line 790, but not defined -- Obsolete informational reference (is this intentional?): RFC 6982 (Obsoleted by RFC 7942) == Outdated reference: A later version (-21) exists of draft-ietf-6tisch-minimal-12 == Outdated reference: A later version (-10) exists of draft-ietf-6tisch-terminology-05 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 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: Informational X. Vilajosana 5 Expires: April 21, 2016 Universitat Oberta de Catalunya 6 October 19, 2015 8 6TiSCH Operation Sublayer (6top) 9 draft-wang-6tisch-6top-sublayer-03 11 Abstract 13 This document defines the 6TiSCH Operation Sublayer (6top), which 14 offers mechanisms for distributed scheduling in 6TiSCH networks. The 15 6top sublayer is the next higher layer of the IEEE802.15.4e TSCH 16 medium access control layer. The 6top Protocol (6P) defined in this 17 document allows neighbor nodes to add/delete TSCH cells to one 18 another. To be able to match different application requirements, the 19 6top Scheduling Function (SF) decides when to add/delete cells. The 20 SF is left out of scope, and will be specified in one or more 21 companion documents. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 27 "OPTIONAL" in this document are to be interpreted as described in RFC 28 2119 [RFC2119]. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on April 21, 2016. 47 Copyright Notice 49 Copyright (c) 2015 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. 6TiSCH Operation Sublayer (6top) . . . . . . . . . . . . . . 4 66 2.1. Hard/Soft Cells . . . . . . . . . . . . . . . . . . . . . 4 67 2.2. Using 6top with the Minimal 6TiSCH Configuration . . . . 5 68 3. 6top Protocol (6P) . . . . . . . . . . . . . . . . . . . . . 5 69 3.1. Message Format . . . . . . . . . . . . . . . . . . . . . 6 70 3.1.1. 6top Information Element . . . . . . . . . . . . . . 6 71 3.1.2. General Message Format . . . . . . . . . . . . . . . 7 72 3.1.3. 6P Command Identifiers . . . . . . . . . . . . . . . 7 73 3.1.4. 6P Return Codes . . . . . . . . . . . . . . . . . . . 8 74 3.1.5. 6P Cell Format . . . . . . . . . . . . . . . . . . . 8 75 3.1.6. 6P ADD Request Format . . . . . . . . . . . . . . . . 8 76 3.1.7. 6P DELETE Request Format . . . . . . . . . . . . . . 9 77 3.1.8. 6P COUNT Request Format . . . . . . . . . . . . . . . 9 78 3.1.9. 6P LIST Request Format . . . . . . . . . . . . . . . 9 79 3.1.10. 6P CLEAR Request Format . . . . . . . . . . . . . . . 9 80 3.1.11. 6P Response Format . . . . . . . . . . . . . . . . . 10 81 3.2. Protocol Behavior . . . . . . . . . . . . . . . . . . . . 10 82 3.2.1. Version Checking . . . . . . . . . . . . . . . . . . 10 83 3.2.2. SFID Checking . . . . . . . . . . . . . . . . . . . . 10 84 3.2.3. Concurrent 6P Transactions . . . . . . . . . . . . . 11 85 3.2.4. Timeout . . . . . . . . . . . . . . . . . . . . . . . 11 86 3.2.5. Adding cells . . . . . . . . . . . . . . . . . . . . 11 87 3.2.6. Aborting a 6P Transaction . . . . . . . . . . . . . . 12 88 3.2.7. Deleting cells . . . . . . . . . . . . . . . . . . . 12 89 3.2.8. Handling error responses . . . . . . . . . . . . . . 12 90 3.3. Security . . . . . . . . . . . . . . . . . . . . . . . . 13 91 4. Guidelines for 6top Scheduling Functions (SF) . . . . . . . . 13 92 4.1. SF Identifier (SFID) . . . . . . . . . . . . . . . . . . 13 93 4.2. Requirements for an SF . . . . . . . . . . . . . . . . . 13 94 4.3. Recommended Structure of an SF Specification . . . . . . 14 96 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 14 97 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 98 7. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 15 99 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 100 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 101 8.2. Informative References . . . . . . . . . . . . . . . . . 15 102 Appendix A. [TEMPORARY] IETF IE . . . . . . . . . . . . . . . . 16 103 Appendix B. [TEMPORARY] IEEE Liaison Considerations . . . . . . 17 104 Appendix C. [TEMPORARY] Terms for the Terminology Draft . . . . 17 105 Appendix D. [TEMPORARY] Changelog . . . . . . . . . . . . . . . 17 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 108 1. Introduction 110 All communication in a 6TiSCH network is orchestrated by a schedule 111 [RFC7554]. This specification defines the mechanisms offered by the 112 6TiSCH Operation Sublayer (6top) sublayer. These mechanisms allow a 113 node to communicate with its neighbor node(s) to agree on a TSCH 114 schedule in a distributed manner. 116 (A) 117 / \ 118 / \ 119 (B)-----(C) 120 | | 121 | | 122 (D) (E) 124 Figure 1: A simple 6TiSCH network. 126 For example, node C in Figure 1 monitors the communication cells to 127 node A it has in its schedule. 129 o If node C determines the number of frames it is sending to A per 130 unit of time is larger than the capacity offered by the TSCH cells 131 it has scheduled to A, it communicates with node A to add one or 132 more such cells. 133 o If the traffic is lower than the capacity, node C communicates 134 with node A to delete one or more cells to A. 135 o Node C might also monitor statistics to determine whether 136 collisions are happening on a particular cell to node A. If this 137 feature is enabled, node C communicates with node A to add a new 138 cell and delete the cell which suffered from collisions. This 139 results, conceptually, in "relocating" the cell which suffered 140 from collisions to a different slotOffset/channelOffset location 141 in the TSCH schedule. The mechanism handling cell relocation is 142 out of the scope of this document. 144 This results in a distributed schedule management solution. 146 The mechanisms needed to enable this interaction are defined by the 147 6TiSCH Operation Sublayer (6top) sublayer, described in Section 2. 148 The 6top Protocol (6P), specified in Section 3, defines the 149 communication between neighbor nodes in this context. The 6top 150 sublayer includes a 6top Scheduling Function (SF) which defines the 151 policy of when to add/delete a cell to a neighbor. Different 152 applications require different SFs, so the SF is left out of scope of 153 this document. One or more SFs will be defined in one or more 154 companion documents. Section 4 provides some guidelines on how to 155 design an SF. 157 2. 6TiSCH Operation Sublayer (6top) 159 As depicted in Figure 2, the 6TiSCH Operation Sublayer (6top) sits 160 directly above the IEEE802.15.4e TSCH medium access control layer 161 [IEEE802154e]. 163 . 164 | . | 165 | next higher layer | 166 +------------------------------------------+ 167 | 6top | 168 +------------------------------------------+ 169 | IEEE802.15.4e TSCH | 170 | . | 171 . 173 Figure 2: The 6top sublayer in the protocol stack. 175 The roles of the 6top sublayer are: 177 o Implement and terminate the 6top Protocol (6P), which allows 178 neighbor nodes to communicate to add/delete cells to one another. 179 o Run a 6top Scheduling Function (SF) which defines the algorithm to 180 decide when to add/delete cells. 181 o Offer a way for a neighbor node to discover which SF is being 182 used. 184 2.1. Hard/Soft Cells 186 6top qualifies each cell in the schedule as either "hard" or "soft": 188 o a Soft Cell can be read, added, deleted or updated by 6top. 189 o a Hard Cell is read-only for 6top. 191 In the context of this specification, all the cells used by 6top are 192 Soft Cells. Hard cells can be used for example when "hard-coding" a 193 cell (e.g. the 6TiSCH Configuration [I-D.ietf-6tisch-minimal]). 195 2.2. Using 6top with the Minimal 6TiSCH Configuration 197 6top MAY be used alongside the Minimal 6TiSCH Configuration 198 [I-D.ietf-6tisch-minimal]. In this case, it is RECOMMENDED to use 2 199 slotframes, as depicted in Figure 3: 201 o Slotframe 0 (SFR0) is used for traffic defined in the Minimal 202 6TiSCH Configuration. In Figure 3, this slotframe is 5 slots 203 long, but it can be of any length. 204 o Slotframe 1 (SFR1) is used by 6top to allocate cells from. In 205 Figure 3, this slotframe is 10 slots long, but it can be of any 206 length. 208 . 210 SFR0 SHOULD be of higher priority than SFR1. 6top MAY support 211 further slotframes; how to use more slotframes is out of the scope 212 for this document. 214 | 0 1 2 3 4 | 0 1 2 3 4 | 215 +------------------------+------------------------+ 216 SFR0 | EB | | | | | EB | | | | | 217 | | | | | | | | | | | 218 +-------------------------------------------------+ 219 SFR1 | |A->B| | | | | | |B->A| | 220 | | | | | | | | | | | 221 +-------------------------------------------------+ 222 | 0 1 2 3 4 5 6 7 8 9 | 224 Figure 3: 2-slotframe structure when using 6top alongside the Minimal 225 6TiSCH Configuration. 227 3. 6top Protocol (6P) 229 The 6top Protocol (6P) allows two neighbor nodes to pass information 230 to add/delete cells to their TSCH schedule. This information is 231 carried as IEEE802.15.4 Information Elements (IE) [IEEE802154e] and 232 travels only a single hop. 234 Conceptually, two neighbor nodes "negotiate" the location of the 235 cells to add/delete. We reuse the topology in Figure 1 to illustrate 236 how the protocol works. 238 When node A wants to add (resp. delete) 2 cells to node B: 240 1. Node A sends a message to node B indicating it wants to add 241 (resp. delete) 2 cells to node B to its schedule, and listing 2 242 or more candidate cells. 243 2. Node B responds with a message indicating that the operation 244 succeeded, and specifying which cells from the candidate list it 245 added (resp. deleted). This allows node A to add (resp. delete) 246 the same cells to/from its schedule. 248 Figure 4 is a sequence diagram which illustrates this exchange. 249 Here, node A requests 2 cells to node B. It sends a 6P ADD Request 250 to node be indicatig it wishes to add 2 cells (the "NumCells" value), 251 and specifying a list of 3 candidate cells from which node B can 252 choose (the "CellList" value). Each cell in the CellList is a tuple 253 with the (slotOffset,channelOffset) coordinates of the candidate cell 254 in the TSCH schedule. Node B selects 2 of the 3 cells in the 255 CellList of the 6P ADD Request, and sends a 6P Response back to node 256 A specifying the cells it selected from the specified container (e.g 257 Slotframe, Chunk, etc ...). This allow nodes A and B to add those 258 two cells to their schedule. 260 +----------+ +----------+ 261 | Node A | | Node B | 262 +----+-----+ +-----+----+ 263 | | 264 | 6P ADD Request | 265 | NumCells = 2 | 266 | Container ID = 1 | 267 | CellList = [(1,2),(2,2),(3,5)] | 268 |-------------------------------------->| 269 | | 270 | 6P Response | 271 | Return Code = IANA_RC_SUCCESS| 272 | CellList = [(2,2),(3,5)] | 273 |<--------------------------------------| 274 | | 276 Figure 4: Sequence diagram to illustrate the 6P negotiation. 278 We call "6P Transaction" the action of two neighbor nodes exchanging 279 a 6P Request Message and the corresponding 6P Reply message. 281 3.1. Message Format 283 3.1.1. 6top Information Element 285 The messages exchanges as part of the 6P protocol are carried in a 286 6top Information Element. The 6top Information Element is a IETF IE 287 with Group ID IANA_6TOP_IE_GROUP_ID. The length of the 6top 288 Information Element is variable. The content of the 6top Information 289 Element is specified in Section 3.1. TODO: IETF IE specified in 290 Appendix A for now, but to be specified in separate draft in the 291 future. 293 3.1.2. General Message Format 295 All 6P messages have the following format: 297 1 2 3 298 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 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Ver | Code | SFID | Other Fields 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 Ver (6P Version): The version of the 6P protocol. Only version 304 IANA_6P_VERSION is defined in this document. Future 305 specification might define further version of the 6P protocol. 306 Code: Command to carry out, or response code. The list of command 307 identifiers and return codes is defined only for version 308 IANA_6P_VERSION in this document. 309 SFID (6top Scheduling Function Identifier): The identifier of the SF 310 to use to handle this message. The SFID is defined in 311 Section 4.1. 312 Other Fields: The list of other fields depends on the value of the 313 code field, as detailed below. 315 3.1.3. 6P Command Identifiers 317 Figure 5 lists the 6P command identifiers. 319 Value Command ID Description 320 +-------------------+--------------+-----------------------------+ 321 | IANA_CMD_ADD | CMD_ADD | add one or more cells | 322 +-------------------+--------------------------------------------+ 323 | IANA_CND_DELETE | CMD_DELETE | delete one or more cells | 324 +-------------------+--------------------------------------------+ 325 | IANA_CMD_COUNT | CMD_COUNT | count scheduled cells | 326 +-------------------+--------------------------------------------+ 327 | IANA_CMD_LIST | CMD_LIST | list the scheduled cells | 328 +-------------------+--------------------------------------------+ 329 | IANA_CMD_CLEAR | CMD_CLEAR | clear all cells | 330 +-------------------+--------------------------------------------+ 331 | TODO-0xf | reserved | 332 +-------------------+--------------------------------------------+ 334 Figure 5: 6P Command Identifiers 336 3.1.4. 6P Return Codes 338 Figure 6 lists the 6P Return Codes and their meaning. 340 Value Return Code Description 341 +------------------+---------------------------------------------+ 342 | IANA_RC_SUCCESS | RC_SUCCESS | operation succeeded | 343 +------------------+---------------------------------------------+ 344 | IANA_RC_VER_ERR | RC_VER_ERR | unsupported 6P version | 345 +------------------+---------------------------------------------+ 346 | IANA_RC_SFID_ERR | RC_SFID_ERR | unsupported SFID | 347 +------------------+---------------------------------------------+ 348 | IANA_RC_ERR_BUSY | RC_ERR_BUSY | handling previous request | 349 +------------------+---------------------------------------------+ 350 | IANA_RC_RESET | RC_RESET | abort 6P transaction | 351 +------------------+---------------------------------------------+ 352 | IANA_RC_ERR | RC_ERR | operation failed | 353 +------------------+---------------------------------------------+ 354 | TODO-0xf | reserved | 355 +------------------+---------------------------------------------+ 357 Figure 6: 6P Return Codes 359 3.1.5. 6P Cell Format 361 The 6P Cell is an element which is present in several messages. It 362 is a 4-byte field formatted as: 364 1 2 3 365 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 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | slotOffset | channelOffset | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 slotOffset: The slot offset of the cell. 371 channelOffset: The channel offset of the cell. 373 3.1.6. 6P ADD Request Format 375 1 2 3 376 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 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | Ver | Code | SFID | NumCells | Container | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | CellList ... 381 +-+-+-+-+-+-+- 383 Ver: Set to IANA_6P_VERSION. 385 Code: Set to IANA_CMD_ADD for a 6P ADD Request. 386 SFID: Identifier of the SF to be used by the receiver to handle the 387 message. 388 NumCells: The number of additional TX cells the sender wants to 389 schedule to the receiver. 390 Container: An indication of where in the schedule to take the cells 391 from (which slotframe, which chunk, etc.). This value is an 392 indication to the SF. The meaning of this field depends on the 393 SF, and is hence out of scope of this document. 394 CellList: A list of 0, 1 or multiple 6P Cells. The format of a 6P 395 Cell is defined in Section 3.1.5 397 3.1.7. 6P DELETE Request Format 399 The 6P DELETE Request has the exact same format as the 6P ADD 400 Request, except for the code which is set to IANA_CMD_DELETE. 402 3.1.8. 6P COUNT Request Format 404 1 2 405 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Ver | Code | SFID | Container | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 Ver: Set to IANA_6P_VERSION. 411 Code: Set to IANA_CMD_COUNT for a 6P COUNT Request. 412 SFID: Identifier of the SF to be used by the receiver to handle the 413 message. 414 Container: An indication of where in the schedule to take the cells 415 from (which slotframe, which chunk, etc.). This value is an 416 indication to the SF. The meaning of this field depends on the 417 SF, and is hence out of scope of this document. 419 3.1.9. 6P LIST Request Format 421 The 6P LIST Request has the exact same format as the 6P COUNT 422 Request, except for the code which is set to IANA_CMD_LIST. 424 3.1.10. 6P CLEAR Request Format 426 The 6P CLEAR Request has the exact same format as the 6P COUNT 427 Request, except for the code which is set to IANA_CMD_CLEAR. 429 3.1.11. 6P Response Format 431 1 2 3 432 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 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | Ver | Code | SFID | Other Fields ... 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 Ver: Set to IANA_6P_VERSION. 438 SFID: Identifier of the SF to be used by the receiver to handle the 439 message. 440 Code: One of the 6P Return Codes listed in Section 3.1.4. 441 Other Fields: The fields depends on what command the request is for: 443 Response to an ADD, DELETE or LIST command: A list of 0, 1 or 444 multiple 6P Cells. The format of a 6P Cell is defined in 445 Section 3.1.5. 446 Response to COUNT command: The number of cells scheduled from the 447 requestor to the receiver by the 6P protocol, encoded as a 448 2-octet unsigned integer. 449 Response to CLEAR command: No other fields are present in the 450 response. 452 3.2. Protocol Behavior 454 For illustration, we assume we use the topology in Figure 1, and that 455 node A negotiates to add/delete cells to node B. 457 3.2.1. Version Checking 459 All messages contain a Version field. If multiple Versions of the 6P 460 protocol have been defined (in future specifications for Version 461 values different than IANA_6P_VERSION), a node MAY implement multiple 462 protocol versions at the same time. When receiving a 6P message with 463 a Version number it does not implement, a node MUST reply with a 6P 464 Response and a return code of IANA_RC_VER_ERR. The Version field in 465 the 6P Response MUST be the same as the Version field in the 466 corresponding 6P Request. 468 3.2.2. SFID Checking 470 All messages contain a SFID field. If multiple SFs has been defined, 471 a node MAY support multiple SFs at the same time. When receiving a 472 6P message with an unsupported SFID, a node MUST reply with a 6P 473 Response and a return code of IANA_RC_SFID_ERR. The Version field in 474 the 6P Response MUST be the same as the Version field in the 475 corresponding 6P Request. 477 3.2.3. Concurrent 6P Transactions 479 Only a single 6P Transaction between two neighbors, in a given 480 direction, can take place at the same time. That is, a node MUST NOT 481 issue a new 6P Request to a given neighbor before having received the 482 6P Response for a previous request to that neighbor. The only 483 exception to this rule is when the previous 6P Transaction has timed 484 out. If a node receives a 6P Request from a given neighbor before 485 having sent the 6P Response to the previous 6P Request from that 486 neighbor, it MUST send back a 6P Response with a return code of 487 IANA_RC_ERR. 489 A node MAY support concurrent 6P Transactions from different 490 neighbors. In this case, in Figure 1, node C can have a different 491 ongoing 6P Transaction with nodes B and E. In case a node does not 492 have enough resources to handle concurrent 6P Transactions from 493 different neighbors, when it receives a 6P Request from a neighbor 494 while already handling a different request from a different neighbor, 495 it MUST reply to that second request with a 6P Response with return 496 code IANA_RC_BUSY. 498 3.2.4. Timeout 500 A timeout happens when the node sending the 6P Request has not 501 received the 6P Response. The value of the timeout is coupled with 502 how the cells between the nodes are scheduled. The SF determines the 503 value of the timeout. The value of the timeout is out of scope of 504 this document. 506 3.2.5. Adding cells 508 We assume the topology in Figure 1 where the SF on node C decides to 509 add NumCell cells to node A. 511 Node C's SF selects NumCandidate>=NumCell cells from its schedule as 512 candidate transmit cells to node A. NumCandidate MUST be larger or 513 equal to NumCell. How many cells it selects (NumCandidate) and how 514 that selection is done is specified in the SF and out of scope of 515 this document. Node C sends a 6P ADD Request to node A which 516 contains the value of NumCells and the NumCandidate cells in the 517 CellList. 519 Upon receiving the request, node A's SF verifies which of the cells 520 in the CellList it can add as receive cells from node C in its own 521 schedule. How that selection is done is specified in the SF and out 522 of scope of this document. That verification can succeed (NumCell 523 cells from the CellList can be used), fail (none of the cells from 524 the CellList can be used) or partially succeed (less than NumCell 525 cells from the CellList can be used). In all cases, node A MUST send 526 a 6P Response with return code set to IANA_RC_SUCCESS, and which 527 specifies the list of cells that were scheduled as receive cells from 528 C. That can contain 0 elements (when the verification failed), 529 NumCell elements (succeeded) or between 0 and NumCell elements 530 (partially succeeded). 532 Upon receiving the response, node C adds the cells specified in the 533 CellList as transmit cells to node A. 535 3.2.6. Aborting a 6P Transaction 537 In case the receiver of a 6top request fails during a 6P Transaction 538 and is unable to complete it, it SHOULD reply to that request with a 539 6P Response with return code IANA_RC_ERR_RESET. Upon receiving this 540 6top reply, the initiator of the 6P Transaction MUST consider the 6P 541 Transaction as failed. 543 3.2.7. Deleting cells 545 The behavior for deleting cells is equivalent to that of adding cells 546 except that: 548 o The nodes delete the cells they agree upon rather than adding 549 them. 550 o All cells in the CellList MUST be already scheduled between the 551 two nodes. 552 o If the CellList in the 6P Request is empty, the SF on the 553 receiving node is free to delete any cell from the sender. 554 o The CellList MUST either be equal, contain exactly NumCell cells, 555 or more than NumCell cells. The case where the CellList is not 556 empty but contains less than NumCell cells is not supported. 558 3.2.8. Handling error responses 560 A return code with a name starting with "RC_ERR" as in Figure 6 561 indicates an error. When a node receives a 6P Response with such an 562 error, it MUST consider the 6P Transaction failed. In particular, if 563 this was a response to a 6P ADD/DELETE Request, the node MUST NOT 564 add/delete any of the cells involved in this 6P Transaction. 565 Similarly, a node sending a 6P Response with an "RC_ERR" return code 566 MUST NOT add/delete any cells as part of that 6P Transaction. The SF 567 defines what to do after an error has occurred. Defining what to do 568 after an error has occurred is out of scope of this document. 570 3.3. Security 572 6P messages are secured through link-layer security. When link-layer 573 security is enabled, the 6P messages MUST be secured. This is 574 possible because 6P messages are carried as Payload IE. 576 4. Guidelines for 6top Scheduling Functions (SF) 578 4.1. SF Identifier (SFID) 580 Each SF has an identifier. The identifier is encoded as a 1-byte 581 field. The identifier space is divided in the following ranges. 583 Range Meaning 584 +-----------+-------------+ 585 | 0x00 | reserved | 586 +-----------+-------------- 587 | 0x01-0xef | managed | 588 +-----------+-------------- 589 | 0xf0-0xfe | unmanaged | 590 +-----------+-------------+ 591 | 0xff | reserved | 592 +-----------+-------------+ 594 Figure 7: SFID range. 596 SF identifiers in the managed space MUST be managed by IANA. 598 4.2. Requirements for an SF 600 The specification for an SF 602 o MUST specify an identifier for that SF. 603 o SHOULD clearly state the application domain the SF is created for. 604 o MUST specify the rule for a node to decide when to add/delete one 605 or more cells to a neighbor. 606 o MUST specify the rule for a Transaction source to select cells to 607 add to the CellList field in the 6P ADD Request. 608 o MUST specify the rule for a Transaction destination to select 609 cells from CellList to add to its schedule. 610 o MUST specify a value for the 6P Timeout, or a rule to calculate 611 it. 612 o MUST specify a meaning for the "Container" field in the 6P ADD 613 Request. 614 o MUST specify the behavior of a node when it boots. 615 o MUST specify what to do after an error has occurred (either the 616 node sent a 6P Response with an error code, or received one). 618 o SHOULD contain examples which highlight normal and error 619 scenarios. 620 o SHOULD contain a list of current implementations, at least during 621 the I-D state of the document, per [RFC6982]. 622 o SHOULD contain a performance evaluation of the scheme, possibly 623 through references to external documents. 625 4.3. Recommended Structure of an SF Specification 627 The following section structure for a SF document is RECOMMENDED: 629 o Introduction 630 o Scheduling Function Identifier 631 o Rules for Adding/Deleting Cells 632 o Rules for CellList 633 o 6P Timeout Value 634 o Meaning of Container Field 635 o Node Behavior at Boot 636 o 6P Error Handling 637 o Examples 638 o Implementation Status 639 o Security Considerations 640 o IANA Considerations 642 5. Implementation Status 644 This section records the status of known implementations of the 645 protocol defined by this specification at the time of posting of this 646 Internet-Draft, and is based on a proposal described in [RFC6982]. 647 The description of implementations in this section is intended to 648 assist the IETF in its decision processes in progressing drafts to 649 RFCs. Please note that the listing of any individual implementation 650 here does not imply endorsement by the IETF. Furthermore, no effort 651 has been spent to verify the information presented here that was 652 supplied by IETF contributors. This is not intended as, and must not 653 be construed to be, a catalog of available implementations or their 654 features. Readers are advised to note that other implementations may 655 exist. 657 According to [RFC6982], "this will allow reviewers and working groups 658 to assign due consideration to documents that have the benefit of 659 running code, which may serve as evidence of valuable experimentation 660 and feedback that have made the implemented protocols more mature. 661 It is up to the individual working groups to use this information as 662 they see fit". 664 OpenWSN: This specification is implemented in the OpenWSN project 665 [OpenWSN]. The authors of this document are collaborating with 666 the OpenWSN community to gather feedback about the status and 667 performance of the protocols described in this document. Results 668 from that discussion will appear in this section in future 669 revision of this specification. 671 6. Security Considerations 673 TODO: analyze risks 675 6P messages are carried inside IEEE802.15.4 Payload Information 676 Elements (IEs). Those Payload IEs are encrypted and authenticated at 677 the link layer through CCM*. 6P benefits from the same level of 678 security as any other Payload IE. The 6P protocol does not define 679 its own security mechanisms. A key management solution is out of 680 scope for this document. The 6P protocol will benefit for the key 681 management solution used in the network. 683 7. IANA Consideration 685 o TODO: IANA_6TOP_IE_GROUP_ID 686 o TODO: IANA_6P_VERSION 687 o TODO: IANA_CMD_ADD 688 o TODO: IANA_CMD_DELETE 689 o TODO: IANA_RC_SUCCESS 690 o TODO: IANA_RC_VER_ERR 691 o TODO: IANA_RC_ERR 693 8. References 695 8.1. Normative References 697 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 698 Requirement Levels", BCP 14, RFC 2119, 699 DOI 10.17487/RFC2119, March 1997, 700 . 702 [IEEE802154e] 703 IEEE standard for Information Technology, "IEEE std. 704 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 705 Networks (LR-WPANs) Amendment 1: MAC sublayer", April 706 2012. 708 8.2. Informative References 710 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 711 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 712 Internet of Things (IoT): Problem Statement", RFC 7554, 713 DOI 10.17487/RFC7554, May 2015, 714 . 716 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 717 Code: The Implementation Status Section", RFC 6982, 718 DOI 10.17487/RFC6982, July 2013, 719 . 721 [I-D.ietf-6tisch-minimal] 722 Vilajosana, X. and K. Pister, "Minimal 6TiSCH 723 Configuration", draft-ietf-6tisch-minimal-12 (work in 724 progress), September 2015. 726 [I-D.ietf-6tisch-terminology] 727 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 728 "Terminology in IPv6 over the TSCH mode of IEEE 729 802.15.4e", draft-ietf-6tisch-terminology-05 (work in 730 progress), July 2015. 732 [OpenWSN] Watteyne, T., Vilajosana, X., Kerkez, B., Chraim, F., 733 Weekly, K., Wang, Q., Glaser, S., and K. Pister, "OpenWSN: 734 a Standards-Based Low-Power Wireless Development 735 Environment", Transactions on Emerging Telecommunications 736 Technologies , August 2012. 738 Appendix A. [TEMPORARY] IETF IE 740 This section contains a proposal for the specification of an IETF IE. 741 If this proposal is supported by the 6TiSCH WG, the authors of this 742 draft recommend for the specification of the IETF IE to be its own 743 draft, possibly developed in the 6TiSCH WG. The reason for having it 744 a separated document is that the scope of the IETF IE is wider that 745 the 6P protocol defined in this document. 747 The IETF IE is a IEEE802.15.4 Payload Information Element with the 748 Group ID set to IANA_6TOP_IE_GROUP_ID. The value of 749 IANA_6TOP_IE_GROUP_ID is defined by the IEEE, communicated to the 750 IETF, and noted by IANA. The format of the IETF IE is exactly the 751 same as the format of an MLME Information Element, as specified in 752 [IEEE802154e], Section 5.2.4.5. The difference is that the space of 753 Sub-IDs is managed by the IETF/IANA. 755 Appendix B. [TEMPORARY] IEEE Liaison Considerations 757 If the specification described in this document is supported by the 758 6TiSCH WG, the authors of this document ask the 6TiSCH WG chairs to 759 liaise with the IEEE to request a Payload Information Element Group 760 ID to be assigned to the IETF (Group ID IANA_6TOP_IE_GROUP_ID 761 described in Appendix A). 763 Appendix C. [TEMPORARY] Terms for the Terminology Draft 765 Terms introduced by this document, and which needs to be added to 766 [I-D.ietf-6tisch-terminology]: 768 6top: The "6TiSCH Operation Sublayer" (6top) is the next 769 highest layer of the IEEE802.15.4e TSCH medium access 770 control layer. It implements and terminates the "6top 771 Protocol" (6P), and contains a "6top Scheduling Function" 772 (SF). It is defined in TODO_LINK_draft-wang-6tisch-6top- 773 sublayer. 774 SF: The "6top Scheduling Function" (SF) is the policy inside 775 the "6TiSCH Operation Sublayer" (6top) which decides when 776 to add/remove cells. It is defined in TODO_LINK_draft- 777 wang-6tisch-6top-sublayer. 778 SFID: The "6top Scheduling Function Identifier" (SFID) is a 779 4-bit field identifying a SF. It is defined in 780 TODO_LINK_draft-wang-6tisch-6top-sublayer. 781 6P: The "6top Protocol" (6P) allows neighbor nodes to 782 communicate to add/delete cells to one another in their 783 TSCH schedule. It is defined in TODO_LINK_draft-wang- 784 6tisch-6top-sublayer. 785 6P Transaction: Part of the "6top Protocol" (6P), the action of two 786 neighbors exchanging a 6P request message and the 787 corresponding 6P response message. It is defined in 788 TODO_LINK_draft-wang-6tisch-6top-sublayer. 790 Appendix D. [TEMPORARY] Changelog 792 o -03 794 * 795 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 796 sublayer/issues/32/missing-command-list 797 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 798 sublayer/issues/31/missing-command-count 799 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 800 sublayer/issues/30/missing-command-clear 801 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-sublayer/ 802 issues/37/6top-atomic-transaction-6p-transaction 804 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 805 sublayer/issues/35/separate-opcode-from-rc 806 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 807 sublayer/issues/36/add-length-field-in-ie 808 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 809 sublayer/issues/27/differentiate-rc_err_busy-and 810 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 811 sublayer/issues/29/missing-rc-rc_reset 812 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 813 sublayer/issues/28/the-sf-must-specify-the-behavior-of-a-mote 814 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 815 sublayer/issues/26/remove-including-their-number 816 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-sublayer/ 817 issues/34/6of-sf 818 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 819 sublayer/issues/33/add-a-figure-showing-the-negociation 820 o -02 822 * introduces the 6P protocol and the notion of 6top Transaction. 823 * introduces the concept of 6OF and its 6OFID. 825 Authors' Addresses 827 Qin Wang (editor) 828 Univ. of Sci. and Tech. Beijing 829 30 Xueyuan Road 830 Beijing, Hebei 100083 831 China 833 Phone: +86 (10) 6233 4781 834 Email: wangqin@ies.ustb.edu.cn 836 Xavier Vilajosana 837 Universitat Oberta de Catalunya 838 156 Rambla Poblenou 839 Barcelona, Catalonia 08018 840 Spain 842 Phone: +34 (646) 633 681 843 Email: xvilajosana@uoc.edu