idnits 2.17.1 draft-ietf-6tisch-6top-protocol-02.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 (July 25, 2016) is 2804 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TEMPORARY' is mentioned on line 1189, 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-16 == Outdated reference: A later version (-10) exists of draft-ietf-6tisch-terminology-07 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: January 26, 2017 Universitat Oberta de Catalunya 6 July 25, 2016 8 6top Protocol (6P) 9 draft-ietf-6tisch-6top-protocol-02 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 January 26, 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 . . . . . . . . . . . . . . . . . . . . . 9 76 4.2.1. 6top Information Element . . . . . . . . . . . . . . 9 77 4.2.2. General Message Format . . . . . . . . . . . . . . . 9 78 4.2.3. 6P Command Identifiers . . . . . . . . . . . . . . . 10 79 4.2.4. 6P Return Codes . . . . . . . . . . . . . . . . . . . 11 80 4.2.5. 6P Cell Format . . . . . . . . . . . . . . . . . . . 11 81 4.2.6. 6P ADD Request Format . . . . . . . . . . . . . . . . 12 82 4.2.7. 6P DELETE Request Format . . . . . . . . . . . . . . 12 83 4.2.8. 6P STATUS Request Format . . . . . . . . . . . . . . 12 84 4.2.9. 6P LIST_AB Request Format . . . . . . . . . . . . . . 13 85 4.2.10. 6P LIST_BA Request Format . . . . . . . . . . . . . . 14 86 4.2.11. 6P CLEAR Request Format . . . . . . . . . . . . . . . 14 87 4.2.12. 6P Response Format . . . . . . . . . . . . . . . . . 14 88 4.2.13. 6P Confirmation Format . . . . . . . . . . . . . . . 15 89 4.3. Protocol Behavior . . . . . . . . . . . . . . . . . . . . 15 90 4.3.1. Version Checking . . . . . . . . . . . . . . . . . . 15 91 4.3.2. SFID Checking . . . . . . . . . . . . . . . . . . . . 15 92 4.3.3. Concurrent 6P Transactions . . . . . . . . . . . . . 16 93 4.3.4. Timeout . . . . . . . . . . . . . . . . . . . . . . . 16 94 4.3.5. SeqNum Mismatch . . . . . . . . . . . . . . . . . . . 16 95 4.3.6. Clearing the Schedule . . . . . . . . . . . . . . . . 17 96 4.3.7. Adding Cells with 2-way Transaction . . . . . . . . . 17 97 4.3.8. Aborting a 6P Transaction . . . . . . . . . . . . . . 17 98 4.3.9. Deleting Cells . . . . . . . . . . . . . . . . . . . 18 99 4.3.10. Listing Cells . . . . . . . . . . . . . . . . . . . . 18 100 4.3.11. Generation Management . . . . . . . . . . . . . . . . 19 101 4.3.12. Handling error responses . . . . . . . . . . . . . . 20 102 4.4. Security . . . . . . . . . . . . . . . . . . . . . . . . 20 103 5. Guidelines for 6top Scheduling Functions (SF) . . . . . . . . 20 104 5.1. SF Identifier (SFID) . . . . . . . . . . . . . . . . . . 21 105 5.2. Requirements for an SF . . . . . . . . . . . . . . . . . 21 106 5.3. Recommended Structure of an SF Specification . . . . . . 22 107 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 22 108 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 109 8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 23 110 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 111 9.1. Normative References . . . . . . . . . . . . . . . . . . 24 112 9.2. Informative References . . . . . . . . . . . . . . . . . 24 113 Appendix A. [TEMPORARY] IETF IE . . . . . . . . . . . . . . . . 25 114 Appendix B. [TEMPORARY] IEEE Liaison Considerations . . . . . . 25 115 Appendix C. [TEMPORARY] Terms for the Terminology Draft . . . . 26 116 Appendix D. [TEMPORARY] Changelog . . . . . . . . . . . . . . . 26 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 119 1. TEMPORARY EDITORIAL NOTES 121 This document is an Internet Draft, so work-in-progress by nature. 122 It contains the following work-in-progress elements: 124 o "TODO" statements are elements which have not yet been written by 125 the authors for some reason (lack of time, ongoing discussions 126 with no clear consensus, etc). The statement does indicate that 127 the text will be written at some time. 128 o "TEMPORARY" appendices are there to capture current ongoing 129 discussions or the changelog of the document. These appendices 130 will be removed in the final text. 131 o "IANA_" identifiers are placeholders for numbers assigned by IANA. 132 These placeholders are to be replaced by the actual values they 133 represent after their assignment by IANA. 134 o This section will be removed in the final text. 136 2. Introduction 138 All communication in a 6TiSCH network is orchestrated by a schedule 139 [RFC7554]. This specification defines the 6top Protocol (6P), part 140 of the 6TiSCH Operation sublayer (6top). 6P allow a node to 141 communicate with a neighbor to add/delete a TSCH cell to one another. 142 6P hence enables distributed scheduling in a 6TiSCH network. 144 (R) 145 / \ 146 / \ 147 (B)-----(C) 148 | | 149 | | 150 (A) (D) 152 Figure 1: A simple 6TiSCH network. 154 The example network depicted in Figure 1 is used to describe the 155 interactions between nodes. We consider the canonical case where 156 node "A" issues 6P requests to node "B". We keep this example 157 throughout this document. Throughout the discussions, node A will 158 always represent the node that issues a 6P request; node B the node 159 that receives this request. 161 We consider node A in Figure 1 monitoring the communication cells it 162 has in its schedule to node B. 164 o If node A determines that the number of link-layer frames it is 165 sending to B per unit of time is larger than the capacity offered 166 by the TSCH cells it has scheduled to B, it triggers a 6P 167 Transaction with node B to add one or more cells to B's TSCH 168 schedule. 169 o If the traffic is lower than the capacity, node A triggers a 6P 170 Transaction with node B to delete one or more cells in the TSCH 171 schedule of both nodes. 172 o Node A MAY also monitor statistics to determine whether collisions 173 are happening on a particular cell to node B. If this feature is 174 enabled, node A communicates with node B to add a new cell and 175 delete the cell which suffered from collisions. This conceptually 176 results in "relocating" the cell which suffered from collisions to 177 a different slotOffset/channelOffset location in the TSCH 178 schedule. The mechanism to handle cell relocation is out of the 179 scope of this document and might be handled by the scheduling 180 function (see below). 182 This results in distributed schedule management in a 6TiSCH network. 184 The 6top Scheduling Function (SF) defines when to add/delete a cell 185 to a neighbor. The SF functions as a (required) add-on to 6P. 186 Different applications require different SFs, so the SF is left out 187 of scope of this document. Different SFs are expected to be defined 188 in future companion specifications. A node MAY implement multiple 189 SFs and run them at the same time. The SFID field contained in all 190 6P messages allows a node to switch between SFs on a per-transaction 191 basis. 193 Section 3 describes the 6TiSCH Operation Sublayer (6top). Section 4 194 defines the 6top Protocol (6P). Section 5 provides guidelines on how 195 to design an SF. 197 3. 6TiSCH Operation Sublayer (6top) 199 As depicted in Figure 2, the 6TiSCH Operation Sublayer (6top) is the 200 next higher layer to the IEEE802.15.4 TSCH medium access control 201 layer [IEEE802154-2015]. 203 . 204 | . | 205 | next higher layer | 206 +------------------------------------------+ 207 | 6top | 208 +------------------------------------------+ 209 | IEEE802.15.4 TSCH | 210 | . | 211 . 213 Figure 2: The 6top sublayer in the protocol stack. 215 The roles of the 6top sublayer are: 217 o Implement and terminate the 6top Protocol (6P), which allows 218 neighbor nodes to communicate to add/delete cells to one another. 219 o Run one or more 6top Scheduling Functions (SF), which define the 220 algorithm to decide when to add/delete cells. 222 3.1. Hard/Soft Cells 224 6top qualifies each cell in the schedule as either "hard" or "soft": 226 o a Soft Cell can be read, added, deleted or updated by 6top. 227 o a Hard Cell is read-only for 6top. 229 In the context of this specification, all the cells used by 6top are 230 Soft Cells. Hard cells can be used for example when "hard-coding" a 231 scheduling. This is done, for example, in the Minimal 6TiSCH 232 Configuration [I-D.ietf-6tisch-minimal]. 234 3.2. Using 6top with the Minimal 6TiSCH Configuration 236 6P MAY be used alongside the Minimal 6TiSCH Configuration 237 [I-D.ietf-6tisch-minimal]. In this case, it is RECOMMENDED to use 2 238 slotframes, as depicted in Figure 3: 240 o Slotframe 0 is used for traffic defined in the Minimal 6TiSCH 241 Configuration. In Figure 3, this slotframe is 5 slots long, but 242 it can be of any length. 243 o Slotframe 1 is used by 6top to allocate cells from. In Figure 3, 244 this slotframe is 10 slots long, but it can be of any length. 246 Slotframe 0 SHOULD be of higher priority than Slotframe 1 to avoid 247 for cells in slotframe 1 to "mask" cells in slotframe 0. 6top MAY 248 support further slotframes; how to use more slotframes is out of the 249 scope for this document. 251 | 0 1 2 3 4 | 0 1 2 3 4 | 252 +------------------------+------------------------+ 253 Slotframe 0 | | | | | | | | | | | 254 5 slots long | EB | | | | | EB | | | | | 255 high priority | | | | | | | | | | | 256 +-------------------------------------------------+ 258 | 0 1 2 3 4 5 6 7 8 9 | 259 +-------------------------------------------------+ 260 Slotframe 1 | | | | | | | | | | | 261 10 slots long | |A->B| | | | | | |B->A| | 262 low priority | | | | | | | | | | | 263 +-------------------------------------------------+ 265 Figure 3: 2-slotframe structure when using 6top alongside the Minimal 266 6TiSCH Configuration. 268 4. 6top Protocol (6P) 270 The 6top Protocol (6P) allows two neighbor nodes to communicate to 271 add/delete cells to their TSCH schedule. Conceptually, two neighbor 272 nodes "negotiate" the location of the cell(s) to add/delete. 274 4.1. 6top Transaction 276 We call "6top Transaction" a complete negotiation between two 277 neighbor nodes. A 6P Transaction starts when a node wishes to add/ 278 delete one or more cells to one of its neighbors. It ends when the 279 cell(s) have been added/removed from the schedule of both neighbors, 280 or when the 6P Transaction has failed. 282 A 6P Transaction can consist of 2 or 3 steps. It is the SF which 283 determines whether to use 2-step or 3-step transactions. An SF MAY 284 use both 2-step and 3-step transactions. 286 Consistency between the schedules of two neighbor nodes is of utmost 287 importance. A loss of consistency (e.g. node A has a transmit cell 288 to node B, but node B does not have the corresponding reception cell) 289 can cause loss of connectivity. To verify consistency, neighbors 290 nodes increment the "schedule generation" number of their schedule 291 each time they add/remove a cell. Neighbor nodes exchange generation 292 numbers at each 6P Transaction to detect possible inconsistencies. 293 This mechanism is explained in Section 4.3.11. 295 We reuse the topology in Figure 1 to illustrate 2-step and 3-step 296 transactions. 298 4.1.1. 2-step 6top Transaction 300 Figure 4 is a sequence diagram to help understand the core principle 301 of 6P (several elements are left out to simplify understanding). We 302 assume the SF running on node A determines 2 extra cells need to be 303 scheduled to node B. In this example, node A proposes the cells to 304 use. 306 +----------+ +----------+ 307 | Node A | | Node B | 308 +----+-----+ +-----+----+ 309 | | 310 | 6P ADD Request | 311 | NumCells = 2 | 312 | CellList = [(1,2),(2,2),(3,5)] | 313 |-------------------------------------->| 314 | | 315 | 6P Response | 316 | Return Code = RC_SUCCESS | 317 | CellList = [(2,2),(3,5)] | 318 |<--------------------------------------| 319 | | 321 Figure 4: A 2-step 6P Transaction. 323 In this example, the 2-step transaction occurs as follows: 325 1. The SF running on node A selects 3 candidate cells. 326 2. Node A sends a 6P ADD Request to node B, indicating it wishes to 327 add 2 cells (the "NumCells" value), and specifying the list of 3 328 candidate cells (the "CellList" value). Each cell in the 329 CellList is a (slotOffset,channelOffset) tuple. 330 3. Node A at the same time sets a timeout timer in order to cancel 331 the transaction in case a response is not received after the 332 timeout. The value of the timeout is out of the scope of this 333 document and MAY be defined by the SF. More details are given in 334 Section 4.3.8. 336 4. The SF running on node B selects 2 of the 3 cells in the CellList 337 of the 6P ADD Request. Node B sends back a 6P Response to node 338 A, indicating the cells it selected. 339 5. The result of this 6P Transaction is that 2 cells from A to B 340 have been added to the TSCH schedule of both nodes A and B. 342 4.1.2. 3-step 6top Transaction 344 Figure 5 is a sequence diagram to help understand the core principle 345 of 6P (several elements are left out to simplify understanding). We 346 assume the SF running on node A determines 2 extra cells need to be 347 scheduled to node B. In this example, node B proposes the cells to 348 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 in order to cancel 379 the transaction in case a response is not received after the 380 timeout. The value of the timeout is out of the scope of this 381 document and MAY be defined by the SF. More details are given in 382 Section 4.3.8. 384 4. The SF running on node B selects 3 candidate cells. Node B sends 385 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 in order to cancel 387 the transaction in case a confirmation is not received after the 388 timeout. The value of the timeout is out of the scope of this 389 document and 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 4.2. Message Format 398 4.2.1. 6top Information Element 400 6P messages are carried as payload of IEEE802.15.4 Payload 401 Information Elements (IE) [IEEE802154-2015]. 6p messages travel over 402 a single hop. 404 1 2 3 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 4 5 6 7 8 9 0 1 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Payload IE Length |GroupID|T| Sub-ID |6top IE Content 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Payload Termination IE | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 The 6top IE is an IEEE Payload IE with GroupID IANA_IETF_IE_GROUP_ID. 413 The 6top IE complies with the IE format defined in 414 [draft-kivinen-ie]. The Sub-ID used by the 6top IE is 415 IANA_6TOP_SUBIE_ID. The length of the 6top IE content is variable. 416 The content of the 6top IE is specified in Section 4.2. The Payload 417 Termination IE is defined by the IEEE802.15.4 standard 418 [IEEE802154-2015]. TODO: IETF IE specified in Appendix A for now, 419 but to be specified in a separate draft in the future, possibly/ 420 probably [draft-kivinen-ie]. 422 4.2.2. General Message Format 424 In all 6P messages, the 6top IE content has the following format: 426 1 2 3 427 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 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 |Version| Code | SFID | SeqNum|GAB|GBA| Other Fields... 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 Version (6P Version): The version of the 6P protocol. Only version 433 IANA_6TOP_6P_VERSION is defined in this document. Future 434 specifications MAY define further versions of the 6P protocol. 435 Code: Command to carry out or response code. The list of command 436 identifiers and return codes is defined only for version 437 IANA_6TOP_6P_VERSION in this document. 438 SFID (6top Scheduling Function Identifier): The identifier of the SF 439 to use to handle this message. The SFID is defined in 440 Section 5.1. 441 SeqNum: An identifier of the packet, used to match the 6P Request, 442 6P Response and 6P Confirmation of the same 6P Transaction. 443 The value of SeqNum MUST increment by exactly one at each new 444 6P request issued to the same neighbor. 445 GAB: Schedule Generation for the cells scheduled from node A to node 446 B. The generation is used to ensure consistency between the 447 schedule of the two neighbors. Section 4.3.11 details how 448 schedule generation is managed. 449 GBA: Schedule Generation for the cells scheduled from node B to node 450 A. 451 Other Fields: The list of other fields depends on the value of the 452 code field, as detailed below. 454 4.2.3. 6P Command Identifiers 456 Figure 6 lists the 6P command identifiers. 458 Command ID Value Description 459 +--------------+-----------------------+----------------------------+ 460 | CMD_ADD | IANA_6TOP_CMD_ADD | add one or more cells | 461 +--------------+-----------------------+----------------------------+ 462 | CMD_DELETE | IANA_6TOP_CMD_DELETE | delete one or more cells | 463 +--------------+-----------------------+----------------------------+ 464 | CMD_STATUS | IANA_6TOP_CMD_STATUS | status of the schedule | 465 +--------------+-----------------------+----------------------------+ 466 | CMD_LIST_AB | IANA_6TOP_CMD_LIST_AB | list the scheduled cells | 467 | | | outgoing from A to B | 468 +--------------+-----------------------+----------------------------+ 469 | CMD_LIST_BA | IANA_6TOP_CMD_LIST_BA | list the scheduled cells | 470 | | | outgoing from B to A | 471 +--------------+-----------------------+----------------------------+ 472 | CMD_CLEAR | IANA_6TOP_CMD_CLEAR | clear all cells on both | 473 | | | node A and node B | 474 +--------------+-----------------------+----------------------------+ 475 | reserved | TODO-0xf | reserved | 476 +--------------+-----------------------+----------------------------+ 478 Figure 6: 6P Command Identifiers 480 4.2.4. 6P Return Codes 482 Figure 7 lists the 6P Return Codes and their meaning. 484 Return Code Value Description 485 +--------------+------------------------+---------------------------+ 486 | RC_SUCCESS | IANA_6TOP_RC_SUCCESS | operation succeeded | 487 +--------------+------------------------+---------------------------+ 488 | RC_ERR_VER | IANA_6TOP_RC_ERR_VER | unsupported 6P version | 489 +--------------+------------------------+---------------------------+ 490 | RC_ERR_SFID | IANA_6TOP_RC_ERR_SFID | unsupported SFID | 491 +--------------+------------------------+---------------------------+ 492 | RC_ERR_GEN | IANA_6TOP_RC_ERR_GEN | schedule generation error | 493 +--------------+------------------------+---------------------------+ 494 | RC_ERR_BUSY | IANA_6TOP_RC_ERR_BUSY | handling previous request | 495 +--------------+------------------------+---------------------------+ 496 | RC_ERR_NORES | IANA_6TOP_RC_ERR_NORES | not enough resources | 497 +--------------+------------------------+---------------------------+ 498 | RC_ERR_RESET | IANA_6TOP_RC_ERR_RESET | abort 6P Transaction | 499 +--------------+------------------------+---------------------------+ 500 | RC_ERR | IANA_6TOP_RC_ERR | generic error | 501 +--------------+------------------------+---------------------------+ 502 | reserved | TODO-0xf | | 503 +--------------+------------------------+---------------------------+ 505 Figure 7: 6P Return Codes 507 4.2.5. 6P Cell Format 509 The 6P Cell is an element which is present in several messages. It 510 is a 4-byte field, its RECOMMENDED format is: 512 1 2 3 513 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 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | slotOffset | channelOffset | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 slotOffset: The slot offset of the cell. 519 channelOffset: The channel offset of the cell. 521 The CellList is an opaque set of bytes, sent unmodified to the SF. 522 The SF MAY redefine the format of the CellList field. 524 4.2.6. 6P ADD Request Format 526 1 2 3 527 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 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 |Version| Code | SFID |SeqNum |GAB|GBA| NumCells | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | Metadata | CellList ... 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 Version: Set to IANA_6TOP_6P_VERSION. 535 Code: Set to CMD_ADD for a 6P ADD Request. 536 SFID: Identifier of the SF to be used by the receiver to handle the 537 message. 538 SeqNum: Packet identifier to match 6P Request and 6P Response. 539 GAB: Schedule Generation for the cells scheduled from node A to node 540 B. 541 GBA: Schedule Generation for the cells scheduled from node B to node 542 A. 543 NumCells: The number of additional TX cells the sender wants to 544 schedule to the receiver. 545 Metadata: Metadata used as extra signaling to the SF. The contents 546 of the Metadata field is an opaque set of bytes, and passed 547 unmodified to the SF. The meaning of this field depends on the 548 SF, and is hence out of scope of this document. One example 549 use can be to specify which slotframe to schedule the cells to. 550 CellList: A list of 0, 1 or multiple 6P Cells. The CellList is an 551 opaque set of bytes, sent unmodified to the SF. The 552 RECOMMENDED format of each 6P Cell is defined in Section 4.2.5. 553 The SF MAY redefine the format of the CellList field. 555 4.2.7. 6P DELETE Request Format 557 The 6P DELETE Request has the exact same format as the 6P ADD 558 Request, except for the code which is set to CMD_DELETE. 560 4.2.8. 6P STATUS Request Format 562 1 2 563 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 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 |Version| Code | SFID |SeqNum |GAB|GBA| Metadata 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 Metadata | 568 +-+-+-+-+-+-+-+-+ 570 Version: Set to IANA_6TOP_6P_VERSION. 571 Code: Set to CMD_STATUS for a 6P STATUS Request. 573 SFID: Identifier of the SF to be used by the receiver to handle the 574 message. 575 SeqNum: Packet identifier to match request and response. 576 GAB: Schedule Generation for the cells scheduled from node A to node 577 B. 578 GBA: Schedule Generation for the cells scheduled from node B to node 579 A. 580 Metadata: Metadata used as extra signaling to the SF. The contents 581 of the Metadata field is an opaque set of bytes, and passed 582 unmodified to the SF. The meaning of this field depends on the 583 SF, and is hence out of scope of this document. One example 584 use can be to specify which slotframe to read the cells from. 586 4.2.9. 6P LIST_AB Request Format 588 The command lists the cells scheduled from node A to node B. 590 1 2 591 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 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 |Version| Code | SFID | SeqNum|GAB|GBA| Metadata 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 Metadata | Offset | numCells 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | 598 +-+-+-+-+-+-+-+-+ 600 Version: Set to IANA_6TOP_6P_VERSION. 601 Code: Set to CMD_LIST_AB for a 6P LIST_AB Request. 602 SFID: Identifier of the SF to be used by the receiver to handle the 603 message. 604 SeqNum: Packet identifier to match request and response. 605 GAB: Schedule Generation for the cells scheduled from node A to node 606 B. 607 GBA: Schedule Generation for the cells scheduled from node B to node 608 A. 609 Metadata: Metadata used as extra signaling to the SF. One example 610 use can be to specify which slotframe to schedule the cells to. 611 The contents of the Metadata field is an opaque set of bytes, 612 and passed unmodified to the SF. The meaning of this field 613 depends on the SF, and is hence out of scope of this document. 614 Offset: The Offset of the first scheduled cell that is requested. 615 The mechanism assumes cells are ordered according to some rule. 616 The ordering rule is defined by the SF. 617 numCells: The number of requested cells. 619 4.2.10. 6P LIST_BA Request Format 621 The 6P LIST_BA Request has the exact same format as the 6P LIST_BA 622 Request, except for the code which is set to CMD_LIST_BA. 6P LIST_BA 623 lists the cells scheduled from note B to node A. 625 4.2.11. 6P CLEAR Request Format 627 The 6P CLEAR Request has the exact same format as the 6P STATUS 628 Request, except for the code which is set to CMD_CLEAR. 630 4.2.12. 6P Response Format 632 1 2 3 633 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 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 |Version| Code | SFID | SeqNum|GAB|GBA| Other Fields... 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 Version: Set to IANA_6TOP_6P_VERSION. 639 SFID: Identifier of the SF to be used by the receiver to handle the 640 message. The response MUST contain the same SFID value as the 641 value in the SFID field of the 6P Request is responds to. 642 Code: One of the 6P Return Codes listed in Section 4.2.4. 643 SeqNum: Packet identifier to match request and response. The 644 response MUST contain the same SeqNum value as the value in the 645 SeqNum field of the 6P Request is responds to. 646 GAB: Schedule Generation for the cells scheduled from node A to node 647 B. 648 GBA: Schedule Generation for the cells scheduled from node B to node 649 A. 650 Other Fields: The contents depends on the Code field in the request, 651 and listed below. 653 When responding to an ADD, DELETE, LIST_AB or LIST_BA command, the 654 "Other Field" contains a list of 0, 1 or multiple 6P Cells. The 655 format of a 6P Cell is defined in Section 4.2.5. 657 When responding to an STATUS command, the "Other Field" contains 659 o The number of cells scheduled from node A to node B, encoded as a 660 2-octet unsigned integer. 661 o The number of cells scheduled from node B to node A, encoded as a 662 2-octet unsigned integer. 664 This is shown in Figure 8. 666 1 2 3 667 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 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 |Version| Code | SFID | SeqNum|GAB|GBA| num. AB cells 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 | number BA cells | 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 Figure 8 676 When responding to an CLEAR command, the "Other Field" is empty. 678 4.2.13. 6P Confirmation Format 680 A 6P Confirmation is only used in a 3-step transaction, as the third 681 step. A 6P Confirmation Message has the exact same format as a 6P 682 Response Message. It is only the fact that it appears as the third 683 step in a 3-step transaction that distinguishes it from a 6P 684 Response. In particular, the same Return Codes are used in both 6P 685 Response and 6P Confirmation messages. The confirmation MUST contain 686 the same SeqNum value as the value in the SeqNum field of the 6P 687 Request and 6P Response of the same transaction. 689 4.3. Protocol Behavior 691 We use the topology in Figure 1 for illustration. We assume node A 692 negotiates to add/delete cells to node B. 694 4.3.1. Version Checking 696 All messages contain a Version field. If multiple Versions of the 6P 697 protocol have been defined (in future specifications for Version 698 values different than IANA_6TOP_6P_VERSION), a node MAY implement 699 multiple protocol versions at the same time. When receiving a 6P 700 message with a Version number it does not implement, a node MUST 701 reply with a 6P Response and a return code of RC_ERR_VER. The 702 Version field in the 6P Response MUST be the same as the Version 703 field in the corresponding 6P Request. 705 4.3.2. SFID Checking 707 All messages contain a SFID field. If multiple SFs have been 708 defined, a node MAY support multiple SFs at the same time. When 709 receiving a 6P message with an unsupported SFID, a node MUST reply 710 with a 6P Response and a return code of RC_ERR_SFID. The Version 711 field in the 6P Response MUST be the same as the Version field in the 712 corresponding 6P Request. In a 3-step transaction, the Version field 713 in the 6P Confirmation MUST match that of the 6P Request and 6P 714 Response in the same transaction. 716 4.3.3. Concurrent 6P Transactions 718 Only a single 6P Transaction between two neighbors, in a given 719 direction, can take place at the same time. That is, a node MUST NOT 720 issue a new 6P Request to a given neighbor before having received the 721 6P Response for a previous request to that neighbor. The only 722 exception to this rule is when the previous 6P Transaction has timed 723 out. If a node receives a 6P Request from a given neighbor before 724 having sent the 6P Response to the previous 6P Request from that 725 neighbor, it MUST send back a 6P Response with a return code of 726 RC_ERR. 728 A node MAY support concurrent 6P Transactions from different 729 neighbors. In this case, the cells involved in the ongoing 6P 730 Transaction MUST be locked until the transaction finishes. For 731 example, in Figure 1, node C can have a different ongoing 6P 732 Transaction with nodes B and R. In case a node does not have enough 733 resources to handle concurrent 6P Transactions from different 734 neighbors it MUST reply with a 6P Response with return code 735 RC_ERR_NORES. In case the requested cells are locked, it MUST reply 736 to that request with a 6P Response with return code RC_ERR_BUSY. The 737 node receiving RC_ERR_BUSY or an RC_ERR_NORES may implement a retry 738 mechanism, as decided by the SF. 740 4.3.4. Timeout 742 A timeout happens when the node sending the 6P Request has not 743 received the 6P Response. The timeout should be longer than the 744 longest possible time it can take for the 6P Transaction to finish. 745 The value of the timeout hence depends on the number of cells 746 schedule between the neighbor nodes, on the maximum number of link- 747 layer retransmissions, etc. The SF determines the value of the 748 timeout. The value of the timeout is out of scope of this document. 750 4.3.5. SeqNum Mismatch 752 When a node receives a 6P Response with SeqNum value different from 753 the SeqNum value in the 6P Request, it MUST drop the packet and 754 consider the 6P Transaction as having failed. This rules applies as 755 well to a 6P Confirmation with a SeqNum value different from that of 756 the 6P Request or 6P Response of the same transaction. 758 4.3.6. Clearing the Schedule 760 When a 6P CLEAR command is issued from node A to node B, both nodes A 761 and B MUST remove all the cells scheduled between them. That is, 762 node A MUST remove all transmit and receive cells with node B, and 763 node B MUST remove all transmit and receive cells with node A. In a 764 6P CLEAR command, the generation counters GAB and GBA MUST NOT be 765 checked. That is, their value is "don't care". In particular, even 766 if a schedule generation mismatch is detected, it MUST NOT cause the 767 transaction to abort. 769 4.3.7. Adding Cells with 2-way Transaction 771 We assume the topology in Figure 1 where the SF on node A decides to 772 add NumCell cells to node B. 774 Node A's SF selects NumCandidate>=NumCell cells from its schedule as 775 candidate transmit cells to node B. NumCandidate MUST be larger or 776 equal to NumCell. How many cells it selects (NumCandidate) and how 777 that selection is done is specified in the SF and out of scope of 778 this document. Node A sends a 6P ADD Request to node B which 779 contains the value of NumCells and the NumCandidate cells in the 780 CellList. 782 Upon receiving the request, node B's SF verifies which of the cells 783 in the CellList it can add as receive cells from node A in its own 784 schedule. How that selection is done is specified in the SF and out 785 of scope of this document. That verification can succeed (NumCell 786 cells from the CellList can be used), fail (none of the cells from 787 the CellList can be used) or partially succeed (less than NumCell 788 cells from the CellList can be used). In all cases, node B MUST send 789 a 6P Response with return code set to RC_SUCCESS, and which specifies 790 the list of cells that were scheduled as receive cells from A. That 791 can contain 0 elements (when the verification failed), NumCell 792 elements (succeeded) or between 0 and NumCell elements (partially 793 succeeded). 795 Upon receiving the response, node A adds the cells specified in the 796 CellList as transmit (Tx) cells to node B. 798 4.3.8. Aborting a 6P Transaction 800 In case the receiver of a 6top request fails during a 6P Transaction 801 and is unable to complete it, it SHOULD reply to that request with a 802 6P Response with return code RC_ERR_RESET. Upon receiving this 6top 803 reply, the initiator of the 6P Transaction MUST consider the 6P 804 Transaction as failed. 806 4.3.9. Deleting Cells 808 The behavior for deleting cells is equivalent to that of adding cells 809 except that: 811 o The nodes delete the cells they agree upon rather than adding 812 them. 813 o All cells in the CellList MUST be already scheduled between the 814 two nodes. 815 o If the CellList in the 6P Request is empty, the SF on the 816 receiving node is free to delete any cell from the sender. 817 o The CellList in a 6P Request (2-step transaction) or 6P Response 818 (3-step transaction) MUST either be empty, contain exactly NumCell 819 cells, or more than NumCell cells. The case where the CellList is 820 not empty but contains less than NumCell cells is not supported. 822 4.3.10. Listing Cells 824 When a node A issues a LIST_AB or LIST_BA command, it specifies: 826 o Through the "Offset" field, the offset of the first cell to be 827 present in the returned list. The cell ordering policy is defined 828 by the SF. 829 o Through the "numCells" field, the number of cells to be present in 830 the reponse. 832 When receiving a LIST_AB command, node B returns the cells that are 833 scheduled from A to B in its schedule (i.e. receive cells from node 834 A). When receiving a LIST_BA command, node B returns the cells that 835 are scheduled from B to A in its schedule (i.e. transmit cells to 836 node A). The RECOMMENDED format of each 6P Cell is defined in 837 Section 4.2.5. The SF MAY redefine the format of the CellList field. 839 Depending on how many cells node B has in its schedule with match the 840 LIST_AB or LIST_BA request, the cellList returned in the 6P Response 841 contains between 0 and numCells cells: 843 o If node B has more than Offset+numCells cells, the cellList it 844 returns contains exactly numCells cells. 845 o If node B has N cells, where Offset. 1103 [IEEE802154-2015] 1104 IEEE standard for Information Technology, "IEEE Std 1105 802.15.4-2015 - IEEE Standard for Low-Rate Wireless 1106 Personal Area Networks (WPANs)", October 2015. 1108 [draft-kivinen-ie] 1109 IETF. draft-kivinen-802-15-ie (work in progress), "IEEE 1110 802.15.4 Information Element for IETF", April 2016. 1112 9.2. Informative References 1114 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 1115 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 1116 Internet of Things (IoT): Problem Statement", RFC 7554, 1117 DOI 10.17487/RFC7554, May 2015, 1118 . 1120 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1121 Code: The Implementation Status Section", RFC 6982, 1122 DOI 10.17487/RFC6982, July 2013, 1123 . 1125 [I-D.ietf-6tisch-minimal] 1126 Vilajosana, X. and K. Pister, "Minimal 6TiSCH 1127 Configuration", draft-ietf-6tisch-minimal-16 (work in 1128 progress), June 2016. 1130 [I-D.ietf-6tisch-terminology] 1131 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 1132 "Terminology in IPv6 over the TSCH mode of IEEE 1133 802.15.4e", draft-ietf-6tisch-terminology-07 (work in 1134 progress), March 2016. 1136 [OpenWSN] Watteyne, T., Vilajosana, X., Kerkez, B., Chraim, F., 1137 Weekly, K., Wang, Q., Glaser, S., and K. Pister, "OpenWSN: 1138 a Standards-Based Low-Power Wireless Development 1139 Environment", Transactions on Emerging Telecommunications 1140 Technologies , August 2012. 1142 Appendix A. [TEMPORARY] IETF IE 1144 [draft-kivinen-ie] has been published and will probably replace this 1145 section. As soon as [draft-kivinen-ie] is adopted, we will remove 1146 this section and revise this document if needed. 1148 This section contains a proposal for the specification of an IETF IE. 1149 If this proposal is supported by the 6TiSCH WG, the authors of this 1150 draft recommend for the specification of the IETF IE to be its own 1151 draft, possibly developed in the 6TiSCH WG. The reason for having it 1152 a separated document is that the scope of the IETF IE is wider that 1153 the 6P protocol defined in this document. 1155 The proposal is to use an IETF IE, a IEEE802.15.4 Payload Information 1156 Element with the Group ID set to IANA_IETF_IE_GROUP_ID. The value of 1157 IANA_IETF_IE_GROUP_ID is defined by the IEEE, communicated to the 1158 IETF, and noted by IANA. The format of the IETF IE is exactly the 1159 same as the format of an MLME Information Element, as specified in 1160 [IEEE802154-2015], Section 5.2.4.5. The difference is that the space 1161 of Sub-IDs is managed by the IETF/IANA. The Sub-ID used by 6top 1162 commands is IANA_6TOP_SUBIE_ID with value 0x00. 1164 Other options are being discussed between the IETF 6TiSCH WG and the 1165 IEEE 6TiSCH IG, and listed in https://www.ietf.org/mail- 1166 archive/web/6tisch/current/msg04469.html. These options concern the 1167 way 6P Messages are transported as IEEE802.15.4 IEs, and do not 1168 impact the format of those messages. 1170 Appendix B. [TEMPORARY] IEEE Liaison Considerations 1172 This liaison work has resulted in the publication of 1173 [draft-kivinen-ie]. As soon as [draft-kivinen-ie] is adopted, we 1174 will remove this section and revise this document if needed. 1176 If the specification described in this document is supported by the 1177 6TiSCH WG, the authors of this document ask the 6TiSCH WG chairs to 1178 liaise with the IEEE to request a Payload Information Element Group 1179 ID to be assigned to the IETF (Group ID IANA_IETF_IE_GROUP_ID 1180 described in Appendix A). 1182 Appendix C. [TEMPORARY] Terms for the Terminology Draft 1184 Terms introduced by this document, and which needs to be added to 1185 [I-D.ietf-6tisch-terminology]: 1187 TODO: add terms? 1189 Appendix D. [TEMPORARY] Changelog 1191 o draft-ietf-6tisch-6top-protocol-02 1193 * Rename COUNT to STATUS 1194 * Split LIST to LIST AB and LIST BA 1195 * Added generation counters and describing generation tracking of 1196 the schedule 1197 * Editorial changes (figs, typos, ...) 1198 o draft-ietf-6tisch-6top-protocol-01 1200 * Clarifying locking of resources in concurrent transactions 1201 * Clarifying return of RC_ERR_BUSY in case of concurrent 1202 transactions without enough resources 1203 o draft-ietf-6tisch-6top-protocol-00 1205 * Informational to Std track 1206 o draft-wang-6tisch-6top-protocol-00 1208 * Editorial overhaul: fixing typos, increasing readability, 1209 clarifying figures. 1210 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1211 issues/47 1212 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1213 issues/54 1214 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1215 issues/55 1216 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1217 issues/49 1218 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1219 issues/53 1220 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1221 issues/44 1222 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1223 issues/48 1224 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1225 issues/43 1227 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1228 issues/52 1229 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1230 issues/45 1231 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1232 issues/51 1233 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1234 issues/50 1235 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1236 issues/46 1237 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1238 issues/41 1239 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1240 issues/42 1241 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1242 issues/39 1243 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1244 issues/40 1245 o draft-wang-6tisch-6top-sublayer-05 1247 * Specifies format of IE 1248 * Adds token in messages to match request and response 1249 o draft-wang-6tisch-6top-sublayer-04 1251 * Renames IANA_6TOP_IE_GROUP_ID to IANA_IETF_IE_GROUP_ID. 1252 * Renames IANA_CMD and IANA_RC to IANA_6TOP_CMD and IANA_6TOP_RC. 1253 * Proposes IANA_6TOP_SUBIE_ID with value 0x00 for the 6top sub- 1254 IE. 1255 o draft-wang-6tisch-6top-sublayer-03 1257 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 1258 protocol/issues/32/missing-command-list 1259 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 1260 protocol/issues/31/missing-command-count 1261 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 1262 protocol/issues/30/missing-command-clear 1263 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1264 issues/37/6top-atomic-transaction-6p-transaction 1265 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 1266 protocol/issues/35/separate-opcode-from-rc 1267 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 1268 protocol/issues/36/add-length-field-in-ie 1269 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 1270 protocol/issues/27/differentiate-rc_err_busy-and 1271 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 1272 protocol/issues/29/missing-rc-rc_reset 1273 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 1274 protocol/issues/28/the-sf-must-specify-the-behavior-of-a-mote 1276 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 1277 protocol/issues/26/remove-including-their-number 1278 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1279 issues/34/6of-sf 1280 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 1281 protocol/issues/33/add-a-figure-showing-the-negociation 1282 o draft-wang-6tisch-6top-sublayer-02 1284 * introduces the 6P protocol and the notion of 6top Transaction. 1285 * introduces the concept of 6OF and its 6OFID. 1287 Authors' Addresses 1289 Qin Wang (editor) 1290 Univ. of Sci. and Tech. Beijing 1291 30 Xueyuan Road 1292 Beijing, Hebei 100083 1293 China 1295 Phone: +86 (10) 6233 4781 1296 Email: wangqin@ies.ustb.edu.cn 1298 Xavier Vilajosana 1299 Universitat Oberta de Catalunya 1300 156 Rambla Poblenou 1301 Barcelona, Catalonia 08018 1302 Spain 1304 Phone: +34 (646) 633 681 1305 Email: xvilajosana@uoc.edu