idnits 2.17.1 draft-wang-6tisch-6top-sublayer-04.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 (November 3, 2015) is 3090 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TEMPORARY' is mentioned on line 799, 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-06 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: May 6, 2016 Universitat Oberta de Catalunya 6 November 3, 2015 8 6TiSCH Operation Sublayer (6top) 9 draft-wang-6tisch-6top-sublayer-04 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 May 6, 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 . . . . . . . . . . . . . . . . . 16 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_6TOP_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_IETF_IE_GROUP_ID. The Sub-ID used by the 288 Information Element is IANA_6TOP_SUBIE_ID. The length of the 6top 289 Information Element is variable. The content of the 6top Information 290 Element is specified in Section 3.1. TODO: IETF IE specified in 291 Appendix A for now, but to be specified in separate draft in the 292 future. 294 3.1.2. General Message Format 296 All 6P messages have the following format: 298 1 2 3 299 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 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Ver | Code | SFID | Other Fields 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 Ver (6P Version): The version of the 6P protocol. Only version 305 IANA_6TOP_6P_VERSION is defined in this document. Future 306 specification might define further version of the 6P protocol. 307 Code: Command to carry out, or response code. The list of command 308 identifiers and return codes is defined only for version 309 IANA_6TOP_6P_VERSION in this document. 310 SFID (6top Scheduling Function Identifier): The identifier of the SF 311 to use to handle this message. The SFID is defined in 312 Section 4.1. 313 Other Fields: The list of other fields depends on the value of the 314 code field, as detailed below. 316 3.1.3. 6P Command Identifiers 318 Figure 5 lists the 6P command identifiers. 320 Value Command ID Description 321 +----------------------+--------------+---------------------------+ 322 | IANA_6TOP_CMD_ADD | CMD_ADD | add one or more cells | 323 +----------------------+------------------------------------------+ 324 | IANA_6TOP_CMD_DELETE | CMD_DELETE | delete one or more cells | 325 +----------------------+------------------------------------------+ 326 | IANA_6TOP_CMD_COUNT | CMD_COUNT | count scheduled cells | 327 +----------------------+------------------------------------------+ 328 | IANA_6TOP_CMD_LIST | CMD_LIST | list the scheduled cells | 329 +----------------------+------------------------------------------+ 330 | IANA_6TOP_CMD_CLEAR | CMD_CLEAR | clear all cells | 331 +----------------------+------------------------------------------+ 332 | TODO-0xf | reserved | 333 +----------------------+------------------------------------------+ 335 Figure 5: 6P Command Identifiers 337 3.1.4. 6P Return Codes 339 Figure 6 lists the 6P Return Codes and their meaning. 341 Value Return Code Description 342 +-----------------------+----------------------------------------+ 343 | IANA_6TOP_RC_SUCCESS | RC_SUCCESS | operation succeeded | 344 +-----------------------+----------------------------------------+ 345 | IANA_6TOP_RC_VER_ERR | RC_VER_ERR | unsupported 6P version | 346 +-----------------------+----------------------------------------+ 347 | IANA_6TOP_RC_SFID_ERR | RC_SFID_ERR | unsupported SFID | 348 +-----------------------+----------------------------------------+ 349 | IANA_6TOP_RC_BUSY | RC_BUSY | handling previous request| 350 +-----------------------+----------------------------------------+ 351 | IANA_6TOP_RC_RESET | RC_RESET | abort 6P transaction | 352 +-----------------------+----------------------------------------+ 353 | IANA_6TOP_RC_ERR | RC_ERR | operation failed | 354 +-----------------------+----------------------------------------+ 355 | TODO-0xf | reserved | 356 +-----------------------+----------------------------------------+ 358 Figure 6: 6P Return Codes 360 3.1.5. 6P Cell Format 362 The 6P Cell is an element which is present in several messages. It 363 is a 4-byte field formatted as: 365 1 2 3 366 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 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | slotOffset | channelOffset | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 slotOffset: The slot offset of the cell. 372 channelOffset: The channel offset of the cell. 374 3.1.6. 6P ADD Request Format 376 1 2 3 377 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 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Ver | Code | SFID | NumCells | Container | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | CellList ... 382 +-+-+-+-+-+-+- 384 Ver: Set to IANA_6TOP_6P_VERSION. 386 Code: Set to IANA_6TOP_CMD_ADD for a 6P ADD Request. 387 SFID: Identifier of the SF to be used by the receiver to handle the 388 message. 389 NumCells: The number of additional TX cells the sender wants to 390 schedule to the receiver. 391 Container: An indication of where in the schedule to take the cells 392 from (which slotframe, which chunk, etc.). This value is an 393 indication to the SF. The meaning of this field depends on the 394 SF, and is hence out of scope of this document. 395 CellList: A list of 0, 1 or multiple 6P Cells. The format of a 6P 396 Cell is defined in Section 3.1.5 398 3.1.7. 6P DELETE Request Format 400 The 6P DELETE Request has the exact same format as the 6P ADD 401 Request, except for the code which is set to IANA_6TOP_CMD_DELETE. 403 3.1.8. 6P COUNT Request Format 405 1 2 406 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | Ver | Code | SFID | Container | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 Ver: Set to IANA_6TOP_6P_VERSION. 412 Code: Set to IANA_6TOP_CMD_COUNT for a 6P COUNT Request. 413 SFID: Identifier of the SF to be used by the receiver to handle the 414 message. 415 Container: An indication of where in the schedule to take the cells 416 from (which slotframe, which chunk, etc.). This value is an 417 indication to the SF. The meaning of this field depends on the 418 SF, and is hence out of scope of this document. 420 3.1.9. 6P LIST Request Format 422 The 6P LIST Request has the exact same format as the 6P COUNT 423 Request, except for the code which is set to IANA_6TOP_CMD_LIST. 425 3.1.10. 6P CLEAR Request Format 427 The 6P CLEAR Request has the exact same format as the 6P COUNT 428 Request, except for the code which is set to IANA_6TOP_CMD_CLEAR. 430 3.1.11. 6P Response Format 432 1 2 3 433 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 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | Ver | Code | SFID | Other Fields ... 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 Ver: Set to IANA_6TOP_6P_VERSION. 439 SFID: Identifier of the SF to be used by the receiver to handle the 440 message. 441 Code: One of the 6P Return Codes listed in Section 3.1.4. 442 Other Fields: The fields depends on what command the request is for: 444 Response to an ADD, DELETE or LIST command: A list of 0, 1 or 445 multiple 6P Cells. The format of a 6P Cell is defined in 446 Section 3.1.5. 447 Response to COUNT command: The number of cells scheduled from the 448 requestor to the receiver by the 6P protocol, encoded as a 449 2-octet unsigned integer. 450 Response to CLEAR command: No other fields are present in the 451 response. 453 3.2. Protocol Behavior 455 For illustration, we assume we use the topology in Figure 1, and that 456 node A negotiates to add/delete cells to node B. 458 3.2.1. Version Checking 460 All messages contain a Version field. If multiple Versions of the 6P 461 protocol have been defined (in future specifications for Version 462 values different than IANA_6TOP_6P_VERSION), a node MAY implement 463 multiple protocol versions at the same time. When receiving a 6P 464 message with a Version number it does not implement, a node MUST 465 reply with a 6P Response and a return code of IANA_6TOP_RC_VER_ERR. 466 The Version field in the 6P Response MUST be the same as the Version 467 field in the corresponding 6P Request. 469 3.2.2. SFID Checking 471 All messages contain a SFID field. If multiple SFs has been defined, 472 a node MAY support multiple SFs at the same time. When receiving a 473 6P message with an unsupported SFID, a node MUST reply with a 6P 474 Response and a return code of IANA_6TOP_RC_SFID_ERR. The Version 475 field in the 6P Response MUST be the same as the Version field in the 476 corresponding 6P Request. 478 3.2.3. Concurrent 6P Transactions 480 Only a single 6P Transaction between two neighbors, in a given 481 direction, can take place at the same time. That is, a node MUST NOT 482 issue a new 6P Request to a given neighbor before having received the 483 6P Response for a previous request to that neighbor. The only 484 exception to this rule is when the previous 6P Transaction has timed 485 out. If a node receives a 6P Request from a given neighbor before 486 having sent the 6P Response to the previous 6P Request from that 487 neighbor, it MUST send back a 6P Response with a return code of 488 IANA_6TOP_RC_ERR. 490 A node MAY support concurrent 6P Transactions from different 491 neighbors. In this case, in Figure 1, node C can have a different 492 ongoing 6P Transaction with nodes B and E. In case a node does not 493 have enough resources to handle concurrent 6P Transactions from 494 different neighbors, when it receives a 6P Request from a neighbor 495 while already handling a different request from a different neighbor, 496 it MUST reply to that second request with a 6P Response with return 497 code IANA_6TOP_RC_BUSY. 499 3.2.4. Timeout 501 A timeout happens when the node sending the 6P Request has not 502 received the 6P Response. The value of the timeout is coupled with 503 how the cells between the nodes are scheduled. The SF determines the 504 value of the timeout. The value of the timeout is out of scope of 505 this document. 507 3.2.5. Adding cells 509 We assume the topology in Figure 1 where the SF on node C decides to 510 add NumCell cells to node A. 512 Node C's SF selects NumCandidate>=NumCell cells from its schedule as 513 candidate transmit cells to node A. NumCandidate MUST be larger or 514 equal to NumCell. How many cells it selects (NumCandidate) and how 515 that selection is done is specified in the SF and out of scope of 516 this document. Node C sends a 6P ADD Request to node A which 517 contains the value of NumCells and the NumCandidate cells in the 518 CellList. 520 Upon receiving the request, node A's SF verifies which of the cells 521 in the CellList it can add as receive cells from node C in its own 522 schedule. How that selection is done is specified in the SF and out 523 of scope of this document. That verification can succeed (NumCell 524 cells from the CellList can be used), fail (none of the cells from 525 the CellList can be used) or partially succeed (less than NumCell 526 cells from the CellList can be used). In all cases, node A MUST send 527 a 6P Response with return code set to IANA_6TOP_RC_SUCCESS, and which 528 specifies the list of cells that were scheduled as receive cells from 529 C. That can contain 0 elements (when the verification failed), 530 NumCell elements (succeeded) or between 0 and NumCell elements 531 (partially succeeded). 533 Upon receiving the response, node C adds the cells specified in the 534 CellList as transmit cells to node A. 536 3.2.6. Aborting a 6P Transaction 538 In case the receiver of a 6top request fails during a 6P Transaction 539 and is unable to complete it, it SHOULD reply to that request with a 540 6P Response with return code IANA_6TOP_RC_RESET. Upon receiving this 541 6top reply, the initiator of the 6P Transaction MUST consider the 6P 542 Transaction as failed. 544 3.2.7. Deleting cells 546 The behavior for deleting cells is equivalent to that of adding cells 547 except that: 549 o The nodes delete the cells they agree upon rather than adding 550 them. 551 o All cells in the CellList MUST be already scheduled between the 552 two nodes. 553 o If the CellList in the 6P Request is empty, the SF on the 554 receiving node is free to delete any cell from the sender. 555 o The CellList MUST either be equal, contain exactly NumCell cells, 556 or more than NumCell cells. The case where the CellList is not 557 empty but contains less than NumCell cells is not supported. 559 3.2.8. Handling error responses 561 A return code with a name starting with "RC_ERR" as in Figure 6 562 indicates an error. When a node receives a 6P Response with such an 563 error, it MUST consider the 6P Transaction failed. In particular, if 564 this was a response to a 6P ADD/DELETE Request, the node MUST NOT 565 add/delete any of the cells involved in this 6P Transaction. 566 Similarly, a node sending a 6P Response with an "RC_ERR" return code 567 MUST NOT add/delete any cells as part of that 6P Transaction. The SF 568 defines what to do after an error has occurred. Defining what to do 569 after an error has occurred is out of scope of this document. 571 3.3. Security 573 6P messages are secured through link-layer security. When link-layer 574 security is enabled, the 6P messages MUST be secured. This is 575 possible because 6P messages are carried as Payload IE. 577 4. Guidelines for 6top Scheduling Functions (SF) 579 4.1. SF Identifier (SFID) 581 Each SF has an identifier. The identifier is encoded as a 1-byte 582 field. The identifier space is divided in the following ranges. 584 Range Meaning 585 +-----------+-------------+ 586 | 0x00 | reserved | 587 +-----------+-------------- 588 | 0x01-0xef | managed | 589 +-----------+-------------- 590 | 0xf0-0xfe | unmanaged | 591 +-----------+-------------+ 592 | 0xff | reserved | 593 +-----------+-------------+ 595 Figure 7: SFID range. 597 SF identifiers in the managed space MUST be managed by IANA. 599 4.2. Requirements for an SF 601 The specification for an SF 603 o MUST specify an identifier for that SF. 604 o SHOULD clearly state the application domain the SF is created for. 605 o MUST specify the rule for a node to decide when to add/delete one 606 or more cells to a neighbor. 607 o MUST specify the rule for a Transaction source to select cells to 608 add to the CellList field in the 6P ADD Request. 609 o MUST specify the rule for a Transaction destination to select 610 cells from CellList to add to its schedule. 611 o MUST specify a value for the 6P Timeout, or a rule to calculate 612 it. 613 o MUST specify a meaning for the "Container" field in the 6P ADD 614 Request. 615 o MUST specify the behavior of a node when it boots. 616 o MUST specify what to do after an error has occurred (either the 617 node sent a 6P Response with an error code, or received one). 619 o SHOULD contain examples which highlight normal and error 620 scenarios. 621 o SHOULD contain a list of current implementations, at least during 622 the I-D state of the document, per [RFC6982]. 623 o SHOULD contain a performance evaluation of the scheme, possibly 624 through references to external documents. 626 4.3. Recommended Structure of an SF Specification 628 The following section structure for a SF document is RECOMMENDED: 630 o Introduction 631 o Scheduling Function Identifier 632 o Rules for Adding/Deleting Cells 633 o Rules for CellList 634 o 6P Timeout Value 635 o Meaning of Container Field 636 o Node Behavior at Boot 637 o 6P Error Handling 638 o Examples 639 o Implementation Status 640 o Security Considerations 641 o IANA Considerations 643 5. Implementation Status 645 This section records the status of known implementations of the 646 protocol defined by this specification at the time of posting of this 647 Internet-Draft, and is based on a proposal described in [RFC6982]. 648 The description of implementations in this section is intended to 649 assist the IETF in its decision processes in progressing drafts to 650 RFCs. Please note that the listing of any individual implementation 651 here does not imply endorsement by the IETF. Furthermore, no effort 652 has been spent to verify the information presented here that was 653 supplied by IETF contributors. This is not intended as, and must not 654 be construed to be, a catalog of available implementations or their 655 features. Readers are advised to note that other implementations may 656 exist. 658 According to [RFC6982], "this will allow reviewers and working groups 659 to assign due consideration to documents that have the benefit of 660 running code, which may serve as evidence of valuable experimentation 661 and feedback that have made the implemented protocols more mature. 662 It is up to the individual working groups to use this information as 663 they see fit". 665 OpenWSN: This specification is implemented in the OpenWSN project 666 [OpenWSN]. The authors of this document are collaborating with 667 the OpenWSN community to gather feedback about the status and 668 performance of the protocols described in this document. Results 669 from that discussion will appear in this section in future 670 revision of this specification. 672 6. Security Considerations 674 TODO: analyze risks 676 6P messages are carried inside IEEE802.15.4 Payload Information 677 Elements (IEs). Those Payload IEs are encrypted and authenticated at 678 the link layer through CCM*. 6P benefits from the same level of 679 security as any other Payload IE. The 6P protocol does not define 680 its own security mechanisms. A key management solution is out of 681 scope for this document. The 6P protocol will benefit for the key 682 management solution used in the network. 684 7. IANA Consideration 686 o TODO: IANA_IETF_IE_GROUP_ID 687 o TODO: IANA_6TOP_SUBIE_ID 688 o TODO: IANA_6TOP_6P_VERSION 689 o TODO: IANA_6TOP_CMD_ADD 690 o TODO: IANA_6TOP_CMD_DELETE 691 o TODO: IANA_6TOP_CMD_LIST 692 o TODO: IANA_6TOP_CMD_COUNT 693 o TODO: IANA_6TOP_CMD_CLEAR 694 o TODO: IANA_6TOP_RC_SUCCESS 695 o TODO: IANA_6TOP_RC_VER_ERR 696 o TODO: IANA_6TOP_RC_SFID_ERR 697 o TODO: IANA_6TOP_RC_BUSY 698 o TODO: IANA_6TOP_RC_RESET 699 o TODO: IANA_6TOP_RC_ERR 701 8. References 703 8.1. Normative References 705 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 706 Requirement Levels", BCP 14, RFC 2119, 707 DOI 10.17487/RFC2119, March 1997, 708 . 710 [IEEE802154e] 711 IEEE standard for Information Technology, "IEEE std. 712 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 713 Networks (LR-WPANs) Amendment 1: MAC sublayer", April 714 2012. 716 8.2. Informative References 718 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 719 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 720 Internet of Things (IoT): Problem Statement", RFC 7554, 721 DOI 10.17487/RFC7554, May 2015, 722 . 724 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 725 Code: The Implementation Status Section", RFC 6982, 726 DOI 10.17487/RFC6982, July 2013, 727 . 729 [I-D.ietf-6tisch-minimal] 730 Vilajosana, X. and K. Pister, "Minimal 6TiSCH 731 Configuration", draft-ietf-6tisch-minimal-12 (work in 732 progress), September 2015. 734 [I-D.ietf-6tisch-terminology] 735 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 736 "Terminology in IPv6 over the TSCH mode of IEEE 737 802.15.4e", draft-ietf-6tisch-terminology-06 (work in 738 progress), November 2015. 740 [OpenWSN] Watteyne, T., Vilajosana, X., Kerkez, B., Chraim, F., 741 Weekly, K., Wang, Q., Glaser, S., and K. Pister, "OpenWSN: 742 a Standards-Based Low-Power Wireless Development 743 Environment", Transactions on Emerging Telecommunications 744 Technologies , August 2012. 746 Appendix A. [TEMPORARY] IETF IE 748 This section contains a proposal for the specification of an IETF IE. 749 If this proposal is supported by the 6TiSCH WG, the authors of this 750 draft recommend for the specification of the IETF IE to be its own 751 draft, possibly developed in the 6TiSCH WG. The reason for having it 752 a separated document is that the scope of the IETF IE is wider that 753 the 6P protocol defined in this document. 755 The IETF IE is a IEEE802.15.4 Payload Information Element with the 756 Group ID set to IANA_IETF_IE_GROUP_ID. The value of 757 IANA_IETF_IE_GROUP_ID is defined by the IEEE, communicated to the 758 IETF, and noted by IANA. The format of the IETF IE is exactly the 759 same as the format of an MLME Information Element, as specified in 760 [IEEE802154e], Section 5.2.4.5. The difference is that the space of 761 Sub-IDs is managed by the IETF/IANA. The Sub-ID used by 6top 762 commands is IANA_6TOP_SUBIE_ID with value 0x00. 764 Appendix B. [TEMPORARY] IEEE Liaison Considerations 766 If the specification described in this document is supported by the 767 6TiSCH WG, the authors of this document ask the 6TiSCH WG chairs to 768 liaise with the IEEE to request a Payload Information Element Group 769 ID to be assigned to the IETF (Group ID IANA_IETF_IE_GROUP_ID 770 described in Appendix A). 772 Appendix C. [TEMPORARY] Terms for the Terminology Draft 774 Terms introduced by this document, and which needs to be added to 775 [I-D.ietf-6tisch-terminology]: 777 6top: The "6TiSCH Operation Sublayer" (6top) is the next 778 highest layer of the IEEE802.15.4e TSCH medium access 779 control layer. It implements and terminates the "6top 780 Protocol" (6P), and contains a "6top Scheduling Function" 781 (SF). It is defined in TODO_LINK_draft-wang-6tisch-6top- 782 sublayer. 783 SF: The "6top Scheduling Function" (SF) is the policy inside 784 the "6TiSCH Operation Sublayer" (6top) which decides when 785 to add/remove cells. It is defined in TODO_LINK_draft- 786 wang-6tisch-6top-sublayer. 787 SFID: The "6top Scheduling Function Identifier" (SFID) is a 788 4-bit field identifying a SF. It is defined in 789 TODO_LINK_draft-wang-6tisch-6top-sublayer. 790 6P: The "6top Protocol" (6P) allows neighbor nodes to 791 communicate to add/delete cells to one another in their 792 TSCH schedule. It is defined in TODO_LINK_draft-wang- 793 6tisch-6top-sublayer. 794 6P Transaction: Part of the "6top Protocol" (6P), the action of two 795 neighbors exchanging a 6P request message and the 796 corresponding 6P response message. It is defined in 797 TODO_LINK_draft-wang-6tisch-6top-sublayer. 799 Appendix D. [TEMPORARY] Changelog 801 o -04 803 * Renames IANA_6TOP_IE_GROUP_ID to IANA_IETF_IE_GROUP_ID. 804 * Renames IANA_CMD and IANA_RC to IANA_6TOP_CMD and IANA_6TOP_RC. 805 * Proposes IANA_6TOP_SUBIE_ID with value 0x00 for the 6top sub- 806 IE. 807 o -03 809 * 810 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 811 sublayer/issues/32/missing-command-list 813 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 814 sublayer/issues/31/missing-command-count 815 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 816 sublayer/issues/30/missing-command-clear 817 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-sublayer/ 818 issues/37/6top-atomic-transaction-6p-transaction 819 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 820 sublayer/issues/35/separate-opcode-from-rc 821 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 822 sublayer/issues/36/add-length-field-in-ie 823 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 824 sublayer/issues/27/differentiate-rc_err_busy-and 825 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 826 sublayer/issues/29/missing-rc-rc_reset 827 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 828 sublayer/issues/28/the-sf-must-specify-the-behavior-of-a-mote 829 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 830 sublayer/issues/26/remove-including-their-number 831 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-sublayer/ 832 issues/34/6of-sf 833 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 834 sublayer/issues/33/add-a-figure-showing-the-negociation 835 o -02 837 * introduces the 6P protocol and the notion of 6top Transaction. 838 * introduces the concept of 6OF and its 6OFID. 840 Authors' Addresses 842 Qin Wang (editor) 843 Univ. of Sci. and Tech. Beijing 844 30 Xueyuan Road 845 Beijing, Hebei 100083 846 China 848 Phone: +86 (10) 6233 4781 849 Email: wangqin@ies.ustb.edu.cn 851 Xavier Vilajosana 852 Universitat Oberta de Catalunya 853 156 Rambla Poblenou 854 Barcelona, Catalonia 08018 855 Spain 857 Phone: +34 (646) 633 681 858 Email: xvilajosana@uoc.edu