idnits 2.17.1 draft-ietf-6tisch-6top-protocol-07.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 (June 27, 2017) is 2495 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCXXXX' is mentioned on line 1434, but not defined == Missing Reference: 'TEMPORARY' is mentioned on line 1505, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802154' ** Downref: Normative reference to an Informational RFC: RFC 8137 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 6982 (Obsoleted by RFC 7942) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6TiSCH Q. Wang, Ed. 3 Internet-Draft Univ. of Sci. and Tech. Beijing 4 Intended status: Standards Track X. Vilajosana 5 Expires: December 29, 2017 Universitat Oberta de Catalunya 6 T. Watteyne 7 Analog Devices 8 June 27, 2017 10 6top Protocol (6P) 11 draft-ietf-6tisch-6top-protocol-07 13 Abstract 15 This document defines the 6top Protocol (6P), which enables 16 distributed scheduling in 6TiSCH networks. 6P allows neighbor nodes 17 to add/delete TSCH cells to one another. 6P is part of the 6TiSCH 18 Operation Sublayer (6top), the next higher layer to the IEEE Std 19 802.15.4 TSCH medium access control layer. The 6top Scheduling 20 Function (SF) decides when to add/delete cells, and triggers 6P 21 Transactions. Several SFs can be defined, each identified by a 22 different 6top Scheduling Function Identifier (SFID). This document 23 lists the requirements for an SF, but leaves the definition of the SF 24 out of scope. SFs are expected to be defined in future companion 25 specifications. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 31 "OPTIONAL" in this document are to be interpreted as described in RFC 32 2119 [RFC2119]. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on December 29, 2017. 50 Copyright Notice 52 Copyright (c) 2017 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. TEMPORARY EDITORIAL NOTES . . . . . . . . . . . . . . . . . . 3 68 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. 6TiSCH Operation Sublayer (6top) . . . . . . . . . . . . . . 5 70 3.1. Hard/Soft Cells . . . . . . . . . . . . . . . . . . . . . 5 71 3.2. Using 6P with the Minimal 6TiSCH Configuration . . . . . 6 72 4. 6top Protocol (6P) . . . . . . . . . . . . . . . . . . . . . 6 73 4.1. 6P Transactions . . . . . . . . . . . . . . . . . . . . . 7 74 4.1.1. 2-step 6P Transaction . . . . . . . . . . . . . . . . 7 75 4.1.2. 3-step 6P Transaction . . . . . . . . . . . . . . . . 8 76 4.2. Message Format . . . . . . . . . . . . . . . . . . . . . 10 77 4.2.1. 6top Information Element (IE) . . . . . . . . . . . . 10 78 4.2.2. Generic 6P Message Format . . . . . . . . . . . . . . 10 79 4.2.3. 6P CellOptions . . . . . . . . . . . . . . . . . . . 11 80 4.2.4. 6P CellList . . . . . . . . . . . . . . . . . . . . . 12 81 4.3. 6P Commands and Operations . . . . . . . . . . . . . . . 13 82 4.3.1. Adding Cells . . . . . . . . . . . . . . . . . . . . 13 83 4.3.2. Deleting Cells . . . . . . . . . . . . . . . . . . . 14 84 4.3.3. Relocating Cells . . . . . . . . . . . . . . . . . . 16 85 4.3.4. Counting Cells . . . . . . . . . . . . . . . . . . . 18 86 4.3.5. Listing Cells . . . . . . . . . . . . . . . . . . . . 19 87 4.3.6. Clearing the Schedule . . . . . . . . . . . . . . . . 20 88 4.4. Protocol Functional Details . . . . . . . . . . . . . . . 21 89 4.4.1. Version Checking . . . . . . . . . . . . . . . . . . 21 90 4.4.2. SFID Checking . . . . . . . . . . . . . . . . . . . . 22 91 4.4.3. Concurrent 6P Transactions . . . . . . . . . . . . . 22 92 4.4.4. Timeout . . . . . . . . . . . . . . . . . . . . . . . 22 93 4.4.5. SeqNum Mismatch . . . . . . . . . . . . . . . . . . . 23 94 4.4.6. Aborting a 6P Transaction . . . . . . . . . . . . . . 23 95 4.4.7. Generation Management . . . . . . . . . . . . . . . . 23 96 4.4.8. Handling Error Responses . . . . . . . . . . . . . . 24 97 4.5. Security . . . . . . . . . . . . . . . . . . . . . . . . 25 98 5. Guidelines for 6top Scheduling Functions (SF) . . . . . . . . 25 99 5.1. SF Identifier (SFID) . . . . . . . . . . . . . . . . . . 25 100 5.2. Requirements for an SF . . . . . . . . . . . . . . . . . 25 101 5.3. Recommended Structure of an SF Specification . . . . . . 26 102 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 26 103 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 104 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 105 8.1. IETF IE Subtype '6P' . . . . . . . . . . . . . . . . . . 28 106 8.2. 6TiSCH parameters sub-registries . . . . . . . . . . . . 28 107 8.2.1. 6P Version Numbers . . . . . . . . . . . . . . . . . 28 108 8.2.2. 6P Message Types . . . . . . . . . . . . . . . . . . 29 109 8.2.3. 6P Command Identifiers . . . . . . . . . . . . . . . 29 110 8.2.4. 6P Return Codes . . . . . . . . . . . . . . . . . . . 30 111 8.2.5. 6P Scheduling Function Identifiers . . . . . . . . . 31 112 8.2.6. 6P CellOptions bitmap . . . . . . . . . . . . . . . . 32 113 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 114 9.1. Normative References . . . . . . . . . . . . . . . . . . 33 115 9.2. Informative References . . . . . . . . . . . . . . . . . 33 116 Appendix A. [TEMPORARY] Changelog . . . . . . . . . . . . . . . 34 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 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 point. 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 132 IANA. These placeholders are to be replaced by the actual values 133 they represent after their assignment by IANA. 134 o "RFCXXXX" refers to the RFC number of this specification, once 135 published. 136 o The string "REMARK" is put before a remark (questions, suggestion, 137 etc) from an author, editor or contributor. These are on-going 138 discussions at the time of writing, and will not be part of the 139 final text. 140 o This section will be removed in the final text. 142 2. Introduction 144 All communication in a 6TiSCH network is orchestrated by a schedule 145 [RFC7554]. This specification defines the 6top Protocol (6P), part 146 of the 6TiSCH Operation sublayer (6top). 6P allows a node to 147 communicate with a neighbor to add/delete TSCH cells to one another. 148 This results in distributed schedule management in a 6TiSCH network. 150 (R) 151 / \ 152 / \ 153 (B)-----(C) 154 | | 155 | | 156 (A) (D) 158 Figure 1: A simple 6TiSCH network. 160 The example network depicted in Figure 1 is used to describe the 161 interaction between nodes. We consider the canonical case where node 162 "A" issues 6P requests to node "B". We keep this example throughout 163 this document. Throughout the document, node A will always represent 164 the node that issues a 6P request; node B the node that receives this 165 request. 167 We consider that node A monitors the communication cells it has in 168 its schedule to node B: 170 o If node A determines that the number of link-layer frames it is 171 sending to B per unit of time is larger than the capacity offered 172 by the TSCH cells it has scheduled to B, it triggers a 6P 173 Transaction with node B to add one or more cells to the TSCH 174 schedule of both nodes. 175 o If the traffic is lower than the capacity, node A triggers a 6P 176 Transaction with node B to delete one or more cells in the TSCH 177 schedule of both nodes. 178 o Node A MAY also monitor statistics to determine whether collisions 179 are happening on a particular cell to node B. If this feature is 180 enabled, node A communicates with node B to add a new cell and 181 delete the cell which suffered from collisions. This results in 182 "relocating" the cell which suffered from collisions to a 183 different [slotOffset,channelOffset] location in the TSCH 184 schedule. The mechanism to handle cell relocation is out of the 185 scope of this document and might be handled by the scheduling 186 function (see below). 188 This results in distributed schedule management in a 6TiSCH network. 190 The 6top Scheduling Function (SF) defines when to add/delete a cell 191 to a neighbor. Different applications require different SFs, so the 192 SF is left out of scope of this document. Different SFs are expected 193 to be defined in future companion specifications. A node MAY 194 implement multiple SFs and run them at the same time. At least one 195 SF MUST be running. The SFID field contained in all 6P messages 196 allows a node to invoke the appropriate SF on a per-transaction 197 basis. 199 Section 3 describes the 6TiSCH Operation Sublayer (6top). Section 4 200 defines the 6top Protocol (6P). Section 5 provides guidelines on how 201 to design an SF. 203 3. 6TiSCH Operation Sublayer (6top) 205 As depicted in Figure 2, the 6TiSCH Operation Sublayer (6top) is the 206 next higher layer to the IEEE Std 802.15.4 TSCH medium access control 207 (MAC) layer [IEEE802154]. We use "802.15.4" as a short version of 208 "IEEE Std 802.15.4" in this document. 210 . 211 | . | 212 | higher layers | 213 +------------------------------------------+ 214 | 6top | 215 +------------------------------------------+ 216 | IEEE Std 802.15.4 TSCH | 217 | . | 218 . 220 Figure 2: The 6top sublayer in the protocol stack. 222 The roles of the 6top sublayer are to: 224 o Implement and terminate the 6top Protocol (6P), which allows 225 neighbor nodes to communicate to add/delete cells to one another. 226 o Run one or more 6top Scheduling Functions (SF), which define the 227 rules that decide when to add/delete cells. 229 3.1. Hard/Soft Cells 231 Each cell in the schedule is either "hard" or "soft": 233 o a soft cell can be read, added, deleted or updated by 6top. 234 o a hard cell is read-only for 6top. 236 In the context of this specification, all the cells used by 6top are 237 soft cells. Hard cells can be used for example when "hard-coding" a 238 schedule [RFC8180]. 240 3.2. Using 6P with the Minimal 6TiSCH Configuration 242 6P MAY be used alongside the Minimal 6TiSCH Configuration [RFC8180]. 243 In this case, it is RECOMMENDED to use 2 slotframes, as depicted in 244 Figure 3: 246 o Slotframe 0 is used for traffic defined in the Minimal 6TiSCH 247 Configuration. In Figure 3, this slotframe is 5 slots long, but 248 the slotframe can be shorter or longer. 249 o 6P allocates cells from Slotframe 1. In Figure 3, Slotframe 1 is 250 10 slots long, but the slotframe can be shorter or longer. 252 | 0 1 2 3 4 | 0 1 2 3 4 | 253 +------------------------+------------------------+ 254 Slotframe 0 | | | | | | | | | | | 255 5 slots long | EB | | | | | EB | | | | | 256 | | | | | | | | | | | 257 +-------------------------------------------------+ 259 | 0 1 2 3 4 5 6 7 8 9 | 260 +-------------------------------------------------+ 261 Slotframe 1 | | | | | | | | | | | 262 10 slots long | |A->B| | | | | | |B->A| | 263 | | | | | | | | | | | 264 +-------------------------------------------------+ 266 Figure 3: 2-slotframe structure when using 6P alongside the Minimal 267 6TiSCH Configuration. 269 The Minimal 6TiSCH Configuration cell SHOULD be allocated from a 270 slotframe of higher priority than the slotframe used by 6P for 271 dynamic cell allocation. This way, dynamically allocated cells 272 cannot "mask" the cells used by the Minimal 6TiSCH Configuration. 273 6top MAY support additional slotframes; how to use additional 274 slotframes is out of the scope for this document. 276 4. 6top Protocol (6P) 278 The 6top Protocol (6P) enables two neighbor nodes to add/delete/ 279 relocate cells to their TSCH schedule. Conceptually, two neighbor 280 nodes "negotiate" the location of the cells to add, delete, or 281 relocate in their TSCH schedule. 283 4.1. 6P Transactions 285 We call "6P Transaction" a complete negotiation between two neighbor 286 nodes. A 6P Transaction starts when a node wishes to add/delete/ 287 relocate one or more cells to one of its neighbors. A 6P Transaction 288 ends when the cell(s) have been added/deleted/relocated from the 289 schedule of both nodes, or when the 6P Transaction has failed. 291 The 6P messages exchanged between nodes A and B during a 6P 292 Transaction SHOULD be exchanged on dedicated cells between A and B. 293 If no dedicated cells are scheduled between nodes A and B, shared 294 cells are used. 296 Consistency between the schedules of the two neighbor nodes is of 297 utmost importance. A loss of consistency (e.g. node A has a transmit 298 cell to node B, but node B does not have the corresponding reception 299 cell) can cause loss of connectivity. To verify consistency, 300 neighbor nodes increment the "schedule generation" number of their 301 schedule each time their schedule is modified. Neighbor nodes 302 exchange the schedule generation number as part of each 6P 303 Transaction to detect possible inconsistencies. This mechanism is 304 explained in Section 4.4.7. 306 An implementation MUST include a mechanism to associate each 307 scheduled cell with the SF that scheduled it. This mechanism is 308 implementation-specific and out of the scope of this document. 310 A 6P Transaction can consist of 2 or 3 steps. An SF MUST specify 311 whether to use 2-step transactions, 3-step transactions, or both. 313 We illustrate 2-step and 3-step transactions using the topology in 314 Figure 1. 316 4.1.1. 2-step 6P Transaction 318 Figure 4 shows an example 2-step 6P Transaction. Several elements 319 are left out to simplify understanding. 321 +----------+ +----------+ 322 | Node A | | Node B | 323 +----+-----+ +-----+----+ 324 | | 325 | 6P ADD Request | 326 | Type = REQUEST | 327 | Code = ADD | 328 | NumCells = 2 | 329 timeout | CellList = [(1,2),(2,2),(3,5)] | 330 --- |-------------------------------------->| 331 | | | 332 | | 6P Response | 333 | | Type = RESPONSE | 334 | | Code = SUCCESS | 335 | | CellList = [(2,2),(3,5)] | 336 X |<--------------------------------------| 337 | | 339 Figure 4: An example 2-step 6P Transaction. 341 In this example, the 2-step transaction occurs as follows: 343 1. The SF running on node A determines that 2 extra cells need to be 344 scheduled to node B. 345 2. The SF running on node A selects 3 candidate cells. 346 3. Node A sends a 6P ADD Request to node B, indicating it wishes to 347 add 2 cells (the "NumCells" value), and specifying the list of 3 348 candidate cells (the "CellList" value). Each cell in the 349 CellList is a (slotOffset,channelOffset) tuple. 350 4. When it sends the 6P ADD Request, Node A sets a timer to abort 351 the transaction if no response has been received before the 352 timeout. 353 5. The SF running on node B selects 2 out of the 3 cells in the 354 CellList of the 6P ADD Request. Node B sends back a 6P Response 355 to node A, indicating the cells that node B selected. 356 6. Upon completion of this 6P Transaction, 2 cells from A to B have 357 been added to the TSCH schedule of both nodes A and B. The 358 schedule generation number (see Section 4.4.7) is incremented to 359 allow inconsistency detection. 361 In a 2-step transaction, node A selects the candidate cells. 363 4.1.2. 3-step 6P Transaction 365 Figure 5 shows an example 3-step 6P Transaction. Several elements 366 are left out to simplify understanding. 368 +----------+ +----------+ 369 | Node A | | Node B | 370 +----+-----+ +-----+----+ 371 | | 372 | 6P ADD Request | 373 | Type = REQUEST | 374 | Code = ADD | 375 | NumCells = 2 | 376 timeout | CellList = [] | 377 --- |-------------------------------------->| 378 | | | 379 | | 6P Response | 380 | | Type = RESPONSE | 381 | | Code = SUCCESS | 382 | | CellList = [(1,2),(2,2),(3,5)] | timeout 383 X |<--------------------------------------| --- 384 | | | 385 | 6P Confirmation | | 386 | Type = CONFIRMATION | | 387 | Code = SUCCESS | | 388 | CellList = [(2,2),(3,5)] | | 389 |-------------------------------------->| X 390 | | 392 Figure 5: An example 3-step 6P Transaction. 394 In this example, the 3-step transaction occurs as follows: 396 1. The SF running on node A determines that 2 extra cells need to be 397 scheduled to node B, but does not select candidate cells. 398 2. Node A sends a 6P ADD Request to node B, indicating it wishes to 399 add 2 cells (the "NumCells" value), with an empty "CellList". 400 3. When it sends the 6P ADD Request, Node A sets a timer to abort 401 the transaction if no response has been received before the 402 timeout. 403 4. The SF running on node B selects 3 candidate cells. Node B sends 404 back a 6P Response to node A, indicating the 3 cells it selected. 405 5. When it sends the 6P Response to node A, Node B sets a timer to 406 abort the transaction if no response has been received before the 407 timeout. 408 6. The SF running on node A selects 2 cells. Node A sends back a 6P 409 Confirmation to node B, indicating the cells it selected. 410 7. Upon completion of this 6P Transaction, 2 cells from A to B have 411 been added to the TSCH schedule of both nodes A and B. The 412 schedule generation number (see Section 4.4.7) is incremented to 413 allow inconsistencies detection. 415 In a 3-step transaction, node B selects the candidate cells. 417 4.2. Message Format 419 4.2.1. 6top Information Element (IE) 421 6P messages are carried as payload of a 802.15.4 Payload Information 422 Element (IE) [IEEE802154]. 6P messages travel over a single hop. 424 This document defines the "6top IE", a subtype of the IETF IE defined 425 in [RFC8137], with subtype IANA_6TOP_SUBIE_ID. The length of the 426 6top IE content is variable. 428 4.2.2. Generic 6P Message Format 430 All 6P messages follow the generic format shown in Figure 6. 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 |Version| T | R | Code | SFID | SeqNum| GEN | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | Other Fields... 438 +-+-+-+-+-+-+-+-+- 440 Figure 6: Generic 6P Message Format. 442 6P Version (Version): The version of the 6P protocol. Only version 443 0 is defined in this document. Future specifications MAY 444 define further versions of the 6P protocol. 445 Type (T): Type of message. The message types are defined in 446 Section 8.2.2. 447 Reserved (R): Reserved bits. These two bits SHOULD be set to zero 448 when sending the message and MUST be ignored upon reception. 449 Code: The Code field contains a 6P Command Identifier when the 6P 450 message is of Type REQUEST. Section 8.2.3 lists the 6P command 451 identifiers. The Code field contains a 6P Return Code when the 452 6P message is of Type RESPONSE or CONFIRMATION. Section 8.2.4 453 lists the 6P Return Codes. The same return codes are used in 454 both 6P Response and 6P Confirmation messages. 455 6top Scheduling Function Identifier (SFID): The identifier of the SF 456 to use to handle this message. The SFID is defined in 457 Section 5.1. 458 SeqNum: Sequence number associated with the 6P Transaction, used to 459 match the 6P Request, 6P Response and 6P Confirmation of the 460 same 6P Transaction. The value of SeqNum MUST increment by 461 exactly one at each new 6P request issued to the same neighbor. 463 Schedule Generation (GEN): Schedule Generation for the transactions 464 between node A and node B. The generation is used to ensure 465 consistency between the schedules of the two neighbors. 466 Section 4.4.7 details how the schedule generation is managed. 467 Other Fields: The list of other fields depends on the type of 468 messages, and is detailed in Section 4.3. 470 4.2.3. 6P CellOptions 472 An 8-bit 6P CellOptions bitmap is present in the following 6P 473 requests: ADD, DELETE, COUNT, LIST, RELOCATE. 475 o In the 6P ADD request, the 6P CellOptions bitmap is used to 476 specify what type of cell to add. 477 o In the 6P DELETE request, the 6P CellOptions bitmap is used to 478 specify what type of cell to delete. 479 o In the 6P COUNT and the 6P LIST requests, the 6P CellOptions 480 bitmap is used as a selector of a particular type of cells. 481 o In the 6P RELOCATE request, the 6P CellOptions bitmap is used to 482 specify what type of cell to relocate. 484 The contents of the 6P CellOptions bitmap apply to all elements in 485 the CellList field. Section 8.2.6 contains the RECOMMENDED format of 486 the 6P CellOptions bitmap. Figure 7 contains the RECOMMENDED meaning 487 of the 6P CellOptions bitmap for the 6P COUNT and 6P LIST requests. 489 Note: assuming node A issues the 6P command to node B. 490 +-------------+------------------------------------------------+ 491 | CellOptions | cells scheduled with A that are to be selected | 492 | Value | by B when receiving a 6P message from A | 493 +-------------+------------------------------------------------+ 494 |TX=0,RX=0,S=0| select all cells | 495 +-------------+------------------------------------------------+ 496 |TX=1,RX=0,S=0| select the cells scheduled marked as RX | 497 +-------------+------------------------------------------------+ 498 |TX=0,RX=1,S=0| select the cells marked as TX | 499 +-------------+------------------------------------------------+ 500 |TX=1,RX=1,S=0| select the cells marked as TX and RX | 501 +-------------+------------------------------------------------+ 502 |TX=0,RX=0,S=1| select the cells marked as SHARED | 503 +-------------+------------------------------------------------+ 504 |TX=1,RX=0,S=1| select the cells marked as RX and SHARED | 505 +-------------+------------------------------------------------+ 506 |TX=0,RX=1,S=1| select the cells marked as TX and SHARED | 507 +-------------+------------------------------------------------+ 508 |TX=1,RX=1,S=1| select the cells marked as TX and RX and SHARED| 509 +-------------+------------------------------------------------+ 511 Figure 7: Meaning of the 6P CellOptions bitmap for the 6P COUNT and 512 the 6P LIST requests. 514 The CellOptions is an opaque set of bits, sent unmodified to the SF. 515 The SF MAY redefine the format of the CellOptions bitmap. The SF MAY 516 redefine the meaning of the CellOptions bitmap. 518 4.2.4. 6P CellList 520 A CellList field MAY be present in a 6P ADD Request, a 6P DELETE 521 Request, a 6P RELOCATE Request, a 6P Response or a 6P Confirmation. 522 It is composed of zero, one or more 6P Cell containers. The contents 523 of the CellOptions field specify the options associated with all 524 cells in the CellList. This necessarily means that the same options 525 are associated with all cells in the CellList. 527 The 6P Cell is a 4-byte field, its RECOMMENDED format is: 529 1 2 3 530 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 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | slotOffset | channelOffset | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 Figure 8: 6P Cell Format. 537 slotOffset: The slot offset of the cell. 538 channelOffset: The channel offset of the cell. 540 The CellList is an opaque set of bytes, sent unmodified to the SF. 541 The SF MAY redefine the format of the CellList field. 543 4.3. 6P Commands and Operations 545 4.3.1. Adding Cells 547 Cells are added by using the 6P ADD command. The Type field (T) is 548 set to REQUEST. The Code field is set to ADD. Figure 9 defines the 549 format of a 6P ADD Request. 551 1 2 3 552 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 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 |Version| T | R | Code | SFID | SeqNum| GEN | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | Metadata | CellOptions | NumCells | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | CellList ... 559 +-+-+-+-+-+-+-+-+- 561 Figure 9: 6P ADD Request Format. 563 Metadata: Used as extra signaling to the SF. The contents of the 564 Metadata field is an opaque set of bytes passed unmodified to 565 the SF. The meaning of this field depends on the SF, and is 566 out of scope of this document. For example, Metadata can 567 specify in which slotframe to add the cells. 568 CellOptions: Indicates the options to associate with the cells to be 569 added. If more than one cell is added (NumCells>1), the same 570 options are associated with all of them. This necessarily 571 means that, if node A needs to add multiple cells with 572 different options, it needs to issue multiple 6P ADD 573 Transactions. 574 NumCells: The number of additional cells the sender wants to 575 schedule to the receiver. 576 CellList: A list of 0, 1 or multiple 6P Cells to be added. 578 Figure 10 defines the format of a 6P ADD Response and Confirmation. 580 1 2 3 581 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 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 |Version| T | R | Code | SFID | SeqNum| GEN | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 | CellList ... 586 +-+-+-+-+-+-+-+-+- 588 Figure 10: 6P ADD Response and Confirmation Formats. 590 CellList: A list of 0, 1 or multiple 6P Cells. 592 Consider the topology in Figure 1 where the SF on node A decides to 593 add NumCells cells to node B. 595 Node A's SF selects NumCandidate cells from its schedule as candidate 596 cells to node B. The CellOptions field specifies the type of these 597 cells. NumCandidate MUST be larger or equal to NumCells. How many 598 cells it selects (NumCandidate) and how that selection is done is 599 specified in the SF and out of scope of this document. Node A sends 600 a 6P ADD Request to node B which contains the CellOptions, the value 601 of NumCells and a selection of NumCandidate cells in the CellList. 602 In case the NumCandidate cells do not fit in a single packet, this 603 operation MUST be split into multiple independent 6P ADD Requests, 604 each for a subset of the number of cells that eventually need to be 605 added. 607 Upon receiving the request, node B's SF verifies which of the cells 608 in the CellList it can install in node B's schedule following the 609 specified CellOptions field. How that selection is done is specified 610 in the SF and out of scope of this document. The verification can 611 succeed (NumCells cells from the CellList can be used), fail (none of 612 the cells from the CellList can be used) or partially succeed (less 613 than NumCells cells from the CellList can be used). In all cases, 614 node B MUST send a 6P Response with return code set to SUCCESS, and 615 which specifies the list of cells that were scheduled following the 616 CellOptions field. That can contain 0 elements (when the 617 verification failed), NumCells elements (succeeded) or between 0 and 618 NumCells elements (partially succeeded). 620 Upon receiving the response, node A adds the cells specified in the 621 CellList according to the request CellOptions field. 623 4.3.2. Deleting Cells 625 Cells are deleted by using the 6P DELETE command. The Type field (T) 626 is set to REQUEST. The Code field is set to DELETE. Figure 11 627 defines the format of a 6P DELETE Request. 629 1 2 3 630 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 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 |Version| T | R | Code | SFID | SeqNum| GEN | 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 | Metadata | CellOptions | NumCells | 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 | CellList ... 637 +-+-+-+-+-+-+-+-+- 639 Figure 11: 6P DELETE Request Format. 641 Metadata: Same usage as for the 6P ADD command, see Section 4.3.1. 642 Its format is the same as that in 6P ADD command, but its 643 contents could be different. 644 CellOptions: Indicates the options that need to be associated to the 645 cells to delete. Only the cells matching the CellOptions are 646 deleted. 647 NumCells: The number of cells from the specified CellList the sender 648 wants to delete from the schedule of both sender and receiver. 649 CellList: A list of 0, 1 or multiple 6P Cells. 651 Figure 12 defines the format of a 6P DELETE Response and 652 Confirmation. 654 1 2 3 655 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 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 |Version| T | R | Code | SFID | SeqNum| GEN | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | CellList ... 660 +-+-+-+-+-+-+-+-+- 662 Figure 12: 6P DELETE Response and Confirmation Formats. 664 CellList: A list of 0, 1 or multiple 6P Cells. 666 The behavior for deleting cells is equivalent to that of adding cells 667 except that: 669 o The nodes delete the cells they agree upon rather than adding 670 them. 671 o All cells in the CellList MUST already be scheduled between the 672 two nodes and must match the CellOptions field. If node A puts 673 cells in its CellList that are not already scheduled between the 674 two nodes and match the CellOptions field, node B replies with a 675 CELLLIST_ERR return code. 677 o If the CellList in the 6P Request is empty, the SF on the 678 receiving node SHOULD delete any cell from the sender, as long as 679 it matches the CellOptions field. 680 o The CellList in a 6P Request (2-step transaction) or 6P Response 681 (3-step transaction) MUST either be empty, contain exactly 682 NumCells cells, or more than NumCells cells. The case where the 683 CellList is not empty but contains less than NumCells cells is not 684 supported. 686 4.3.3. Relocating Cells 688 Cell relocation consists in moving a cell to a different 689 [slotOffset,channelOffset] location in the schedule. The Type field 690 (T) is set to REQUEST. The Code is set to RELOCATE. Figure 13 691 defines the format of a 6P RELOCATE Request. 693 1 2 3 694 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 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 |Version| T | R | Code | SFID | SeqNum| GEN | 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | Metadata | CellOptions | NumCells | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 | Rel. CellList ... |Cand. CellList (Optional) ... 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 Figure 13: 6P RELOCATE Request Format. 705 Metadata: Same usage as for the 6P ADD command, see Section 4.3.1. 706 Its format is the same as that in 6P ADD command, but its 707 contents could be different. 708 CellOptions: Indicates the options that need to be associated to the 709 relocated cells. 710 NumCells: The number of cells to relocate, which MUST be equal or 711 greater than 1. 712 Relocation CellList: The list of NumCells 6P Cells to relocate. 713 Candidate CellList: A list of NumCandidate candidate cells for node 714 B to pick from. NumCandidate MUST be equal or greater than 715 NumCells. 717 Figure 14 defines the format of a 6P RELOCATE Response and 718 Confirmation. 720 1 2 3 721 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 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 |Version| T | R | Code | SFID | SeqNum| GEN | 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 | CellList ... 726 +-+-+-+-+-+-+-+-+- 728 Figure 14: 6P RELOCATE Response and Confirmation Formats. 730 CellList: A list of 0, 1 or multiple 6P Cells. 732 Node A's SF wants to relocate NumCells cells. Node A creates a 6P 733 RELOCATE Request, and indicates the cells to relocate in the 734 Relocation CellList. It also selects NumCandidate cells from its 735 schedule as candidate cells for node B, and puts those in the 736 Candidate CellList. The CellOptions field specifies the type of the 737 cell(s) to relocate. NumCandidate MUST be larger or equal to 738 NumCells. How many cells it selects (NumCandidate) and how that 739 selection is done is specified in the SF and out of scope of this 740 document. Node A sends the 6P RELOCATE Request to node B. 742 Upon receiving the request, node B's SF verifies that all the cells 743 in the Relocation CellList are indeed scheduled with node A, and are 744 associate the options specified in the CellOptions field. If that 745 check fails, node B MUST send a 6P Response to node A with return 746 code CELLLIST_ERR. If that check passes, node B's SF verifies which 747 of the cells in the Candidate CellList it can install in its 748 schedule. How that selection is done is specified in the SF and out 749 of scope of this document. That verification on Candidate CellList 750 can succeed (NumCells cells from the Candidate CellList can be used), 751 fail (none of the cells from the Candidate CellList can be used) or 752 partially succeed (less than NumCells cells from the Candidate 753 CellList can be used). In all cases, node B MUST send a 6P Response 754 with return code set to SUCCESS, and which specifies the list of 755 cells that were scheduled following the CellOptions field. That can 756 contain 0 elements (when the verification failed), NumCells elements 757 (succeeded) or between 0 and NumCells elements (partially succeeded). 758 If N < NumCells cells appear in the CellList, this means first N 759 cells in the Relocation CellList have been relocated, the remainder 760 have not. 762 Upon receiving the response, node A relocates the cells specified in 763 Relocation CellList of its RELOCATE Request to the new location 764 specified in the CellList of the 6P Response. 766 +----------+ +----------+ 767 | Node A | | Node B | 768 +----+-----+ +-----+----+ 769 | | 770 | 6P RELOCATE Request | 771 | Type = REQUEST | 772 | Code = RELOCATE | 773 | NumCells = 2 | 774 | R.CellList = [(1,2),(2,2)] | 775 | C.CellList = [(3,2),(4,2),(6,5)] | 776 |-------------------------------------->| B relocates 777 | | (1,2)->(4,2) 778 | 6P Response | but cannot 779 | Type = RESPONSE | relocate (2,2) 780 | Code = SUCCESS | 781 | CellList = [(4,2)] | 782 A relocates |<--------------------------------------| 783 (1,2)->(4,2)| | 785 Figure 15: 6P RELOCATE Example. 787 4.3.4. Counting Cells 789 To retrieve the number of scheduled cells at B, node A issues a 6P 790 COUNT command. The Type field (T) is set to REQUEST. The Code field 791 is set to COUNT. Figure 16 defines the format of a 6P COUNT Request. 793 1 2 794 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 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 |Version| T | R | Code | SFID | SeqNum| GEN | 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 | Metadata | CellOptions | 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 801 Figure 16: 6P COUNT Request Format. 803 Metadata: Same usage as for the 6P ADD command, see Section 4.3.1. 804 Its format is the same as that in 6P ADD command, but its 805 contents could be different. 806 CellOptions: Specifies which types of cells to be counted. 808 Figure 17 defines the format of a 6P COUNT Response. 810 1 2 3 811 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 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 |Version| T | R | Code | SFID | SeqNum| GEN | 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 | NumCells | 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 Figure 17: 6P COUNT Response Format. 820 NumCells: The number of cells which correspond to the fields of the 821 request. 823 Node A issues a COUNT command to node B, specifying a set of cell 824 options. Upon receiving the 6P COUNT request, node B goes through 825 its schedule and counts the number of cells scheduled with node A in 826 its own schedule, and which match the cell options in the CellOptions 827 field of the request. Section 4.2.3 details the use of the 828 CellOptions field. 830 Node B issues a 6P response to node A with return code set to 831 SUCCESS, and with NumCells containing the number of cells that match 832 the request. 834 4.3.5. Listing Cells 836 To retrieve the list of scheduled cells at B, node A issues a 6P LIST 837 command. The Type field (T) is set to REQUEST. The Code field is 838 set to LIST. Figure 18 defines the format of a 6P LIST Request. 840 1 2 841 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 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 |Version| T | R | Code | SFID | SeqNum| GEN | 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 | Metadata | CellOptions | Reserved | 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 | Offset | MaxNumCells | 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 Figure 18: 6P LIST Request Format. 852 Metadata: Same usage as for the 6P ADD command, see Section 4.3.1. 853 Its format is the same as that in 6P ADD command, but its 854 contents could be different. 855 CellOptions: Specifies which types of cells to be listed. 856 Reserved: Set to 0. 858 Offset: The Offset of the first scheduled cell that is requested. 859 The mechanism assumes cells are ordered according to a rule 860 defined in the SF. The rule MUST always order the cells in the 861 same way. 862 MaxNumCells: The maximum number of cells to be listed. Node B MAY 863 returns less than MaxNumCells cells, for example if MaxNumCells 864 cells do not fit in the frame. 866 Figure 19 defines the format of a 6P LIST Response. 868 1 2 3 869 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 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 |Version| T | R | Code | SFID | SeqNum| GEN | 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 | CellList ... 874 +-+-+-+-+-+-+-+-+- 876 Figure 19: 6P LIST Response Format. 878 CellList: A list of 0, 1 or multiple 6P Cells. 880 When receiving a LIST command, node B returns the cells in its 881 schedule that match the CellOptions field as specified in 882 Section 4.2.3 884 When node B receives a LIST request, the returned CellList in the 6P 885 Response contains between 1 and MaxNumCells cells, starting from the 886 specified offset. Node B SHOULD include as many cells as fit in the 887 frame. If the response contains the last cell, Node B MUST set the 888 Code field in the response to EOL, indicating to Node A that there no 889 more cells that match the request. Node B MUST return at least one 890 cell, unless the specified Offset is beyond the end of B's cell list 891 in its schedule. If node B has less than Offset cells that match the 892 request, node B returns an empty CellList and a Code field set to 893 EOL. 895 4.3.6. Clearing the Schedule 897 To clear the schedule between nodes A and B (for example after a 898 schedule inconsistency is detected), node A issues a CLEAR command. 899 The Type field (T) is set to 6P Request. The Code field is set to 900 CLEAR. Figure 20 defines the format of a 6P CLEAR Request. 902 1 2 903 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 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 |Version| T | R | Code | SFID | SeqNum| GEN | 906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 907 | Metadata | 908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 Figure 20: 6P CLEAR Request Format. 912 Metadata: Same usage as for the 6P ADD command, see Section 4.3.1. 913 Its format is the same as that in 6P ADD command, but its 914 contents could be different. 916 Figure 21 defines the format of a 6P CLEAR Response. 918 1 2 3 919 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 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 |Version| T | R | Code | SFID | SeqNum| GEN | 922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 Figure 21: 6P CLEAR Response Format. 926 When a 6P CLEAR command is issued from node A to node B, both nodes A 927 and B MUST remove all the cells scheduled between them. That is, 928 node A MUST remove all the cells scheduled with B, and node B MUST 929 remove all the cells scheduled with A. In a 6P CLEAR command, the 930 generation counter GEN MUST NOT be checked. That is, its value is 931 "don't care". In particular, even if the request contains a GEN 932 value that would normally cause node B to detect a schedule 933 generation mismatch, the transaction MUST NOT be aborted. 935 4.4. Protocol Functional Details 937 4.4.1. Version Checking 939 All messages contain a Version field. If multiple Versions of the 6P 940 protocol have been defined (in future specifications for Version 941 values different from 0), a node MAY implement multiple protocol 942 versions at the same time. When receiving a 6P message with a 943 Version number it does not implement, a node MUST reply with a 6P 944 Response with a Return Code field set to VER_ERR. The Version field 945 in the 6P Response MUST be the same as the Version field in the 946 corresponding 6P Request. In a 3-step transaction, the Version field 947 in the 6P Confirmation MUST match that of the 6P Request and 6P 948 Response in the same transaction. 950 4.4.2. SFID Checking 952 All messages contain a SFID field. A node MAY support multiple SFs 953 at the same time. When receiving a 6P message with an unsupported 954 SFID, a node MUST reply with a 6P Response and a return code of 955 SFID_ERR. The SFID field in the 6P Response MUST be the same as the 956 SFID field in the corresponding 6P Request. In a 3-step transaction, 957 the SFID field in the 6P Confirmation MUST match that of the 6P 958 Request and 6P Response in the same transaction. 960 4.4.3. Concurrent 6P Transactions 962 Only a single 6P Transaction between two neighbors, in a given 963 direction, can take place at the same time. That is, a node MUST NOT 964 issue a new 6P Request to a given neighbor before having received the 965 6P Response for a previous request to that neighbor, except when the 966 previous 6P Transaction has timed out. If a node receives a 6P 967 Request from a given neighbor before having sent the 6P Response to 968 the previous 6P Request from that neighbor, it MUST send back a 6P 969 Response with a return code of RESET. A node receiving RESET code 970 MUST abort the transaction and consider it never happened. 972 Nodes A and B MAY support having two transactions going on at the 973 same time, one in each direction. Similarly, a node MAY support 974 concurrent 6P Transactions from different neighbors. In this case, 975 the cells involved in an ongoing 6P Transaction MUST be locked until 976 the transaction finishes. For example, in Figure 1, node C can have 977 a different ongoing 6P Transaction with nodes B and R. In case a 978 node does not have enough resources to handle concurrent 6P 979 Transactions from different neighbors it MUST reply with a 6P 980 Response with return code BUSY. In case the requested cells are 981 locked, it MUST reply to that request with a 6P Response with return 982 code NORES. The node receiving BUSY or an NORES MAY implement a 983 retry mechanism, defined by the SF. 985 4.4.4. Timeout 987 A timeout occurs when the node sending the 6P Request has not 988 received the 6P Response within a specified amount of time determined 989 by the SF. In a 3-step transaction, a timeout also occurs when the 990 node sending the 6P Response has not received the 6P Confirmation. 991 The timeout should be longer than the longest possible time it can 992 take for the exchange to finish. The value of the timeout hence 993 depends on the number of cells scheduled between the neighbor nodes, 994 the maximum number of link-layer retransmissions, etc. The SF MUST 995 determine the value of the timeout. The value of the timeout is out 996 of scope of this document. 998 4.4.5. SeqNum Mismatch 1000 A SeqNum mismatch happens when a node receives a 6P Response or 6P 1001 Confirmation with SeqNum value different from the SeqNum value in the 1002 6P Request. When it detects a SeqNum mismatch, the node MUST drop 1003 the packet and consider the 6P Transaction as having failed. 1005 4.4.6. Aborting a 6P Transaction 1007 In case the receiver of a 6P Request fails during a 6P Transaction 1008 and is unable to complete it, it SHOULD reply to that Request with a 1009 6P Response with return code RESET. Upon receiving this 6P Response, 1010 the initiator of the 6P Transaction MUST consider the 6P Transaction 1011 as failed. 1013 Similarly, in the case of 3-step transaction, when the receiver of a 1014 6P Response fails during the 6P Transaction and is unable to complete 1015 it, it SHOULD reply to that 6P Response with a 6P Confirmation with 1016 return code RESET. Upon receiving this 6P Confirmation, the sender 1017 of the 6P Response MUST consider the 6P Transaction as failed. 1019 4.4.7. Generation Management 1021 For each neighbor, a node maintains a 4-bit generation number. The 1022 generation number counts the number of transactions that have 1023 modified the schedule with the particular neighbor so far. This 1024 number is a variable internal to the node. 1026 4.4.7.1. Incrementing the Generation Number 1028 The generation number is incremented as a 4-bit lollipop counter. 1029 Its possible values are: 1031 +---------+---------------------------+ 1032 | Value | Meaning | 1033 +---------+---------------------------+ 1034 | 0x0 | Clear or never scheduled | 1035 | 0x1-0x9 | Lollipop Counter values | 1036 | 0xa-0xf | Reserved | 1037 +---------+---------------------------+ 1039 Figure 22: Possible values of the generation number. 1041 The generation number is set to 0 upon initialization, and after a 6P 1042 CLEAR command. The generation number is incremented by exactly 1 1043 each time a cell with that neighbor is added/deleted/relocated from 1044 the schedule (e.g. after a successful 6P ADD, 6P DELETE or 6P 1045 RELOCATE transaction). The value rolls from 0x9 to 0x1 (i.e. not to 1046 0x0). This results in a lollipop counter with 0x0 the start value, 1047 and 0x1-0x9 the count values. Values from 0xa to 0xf are reserved 1048 and MUST NOT be used. 1050 4.4.7.2. Setting GEN field in the 6P Message Header 1052 Each 6P message contains a GEN field, used to indicate the current 1053 generation number of the node transmitting the message. The value of 1054 the GEN field MUST be set according to the following rules: 1056 o When node A sends a 6P Request or 6P Confirmation to node B, node 1057 A sets GEN to its generation number for Node B. 1058 o When node B sends a 6P Response to node A, node B sets GEN to its 1059 generation number for node A. 1061 4.4.7.3. Detecting and Handling Schedule Generation Inconsistencies 1063 Upon receiving a 6P message, a node MUST do the following checks: 1065 o When node B receives a 6P Request or 6P Confirmation from node A, 1066 it verifies that the value of the GEN field in the 6P message is 1067 equal to its internal generation number. 1068 o When node A receives a 6P Response from node B, it verifies that 1069 the value of the GEN field in the 6P message is equal to its 1070 internal generation number. 1072 If any of these comparisons is false, the node has detected a 1073 schedule generation inconsistency. 1075 When a schedule generation inconsistency is detected: 1077 o If the code of the 6P Request is different from CLEAR, the node 1078 MUST reply with error code GEN_ERR. 1079 o If the code of the 6P Request is CLEAR, the schedule generation 1080 inconsistency MUST be ignored. 1082 It is up to the Scheduling Function to define the action to take when 1083 an schedule generation inconsistency is detected. The RECOMMENDED 1084 action is to issue a 6P CLEAR command. 1086 4.4.8. Handling Error Responses 1088 A return code marked as Yes in the "Is Error" column in Figure 27 1089 indicates an error. When a node receives a 6P Response or 6P 1090 Confirmation with such an error, it MUST consider the 6P Transaction 1091 as failed. In particular, if this was a response to a 6P ADD/DELETE/ 1092 RELOCATE Request, the node MUST NOT add/delete/relocate any of the 1093 cells involved in this 6P Transaction. Similarly, a node sending a 1094 6P Response or a 6P Confirmation with an error code MUST NOT 1095 add/delete/relocate any cells as part of that 6P Transaction. 1096 Defining what to do after an error has occurred is out of scope of 1097 this document. The SF defines what to do after an error has 1098 occurred. 1100 4.5. Security 1102 6P messages are secured through link-layer security. When link-layer 1103 security is enabled, the 6P messages MUST be secured. This is 1104 possible because 6P messages are carried as Payload IE. 1106 5. Guidelines for 6top Scheduling Functions (SF) 1108 5.1. SF Identifier (SFID) 1110 Each SF has a 1-byte identifier. Section 8.2.5 defines the rules for 1111 applying for an SFID. 1113 5.2. Requirements for an SF 1115 The specification for an SF 1117 o MUST specify an identifier for that SF. 1118 o MUST specify the rule for a node to decide when to add/delete one 1119 or more cells to a neighbor. 1120 o MUST specify the rule for a Transaction source to select cells to 1121 add to the CellList field in the 6P ADD Request. 1122 o MUST specify the rule for a Transaction destination to select 1123 cells from CellList to add to its schedule. 1124 o MUST specify a value for the 6P Timeout, or a rule/equation to 1125 calculate it. 1126 o MUST specify the rule for ordering cells. 1127 o MUST specify a meaning for the "Metadata" field in the 6P ADD 1128 Request. 1129 o MUST specify the SF behavior of a node when it boots. 1130 o MUST specify what to do after an error has occurred (either the 1131 node sent a 6P Response with an error code, or received one). 1132 o MUST specify the list of statistics to gather. An example 1133 statistic is the number of transmitted frames to each neighbor. 1134 In case the SF requires no statistics to be gathered, the specific 1135 of the SF MUST explicitly state so. 1137 o SHOULD clearly state the application domain the SF is created for. 1138 o SHOULD contain examples which highlight normal and error 1139 scenarios. 1140 o SHOULD contain a list of current implementations, at least during 1141 the I-D state of the document, per [RFC6982]. 1143 o SHOULD contain a performance evaluation of the scheme, possibly 1144 through references to external documents. 1146 o MAY redefine the format of the CellList field. 1147 o MAY redefine the format of the CellOptions field. 1148 o MAY redefine the meaning of the CellOptions field. 1150 5.3. Recommended Structure of an SF Specification 1152 The following section structure for a SF document is RECOMMENDED: 1154 o Introduction 1155 o Scheduling Function Identifier 1156 o Rules for Adding/Deleting Cells 1157 o Rules for CellList 1158 o 6P Timeout Value 1159 o Rule for Ordering Cells 1160 o Meaning of the Metadata Field 1161 o Node Behavior at Boot 1162 o 6P Error Handling 1163 o Examples 1164 o Implementation Status 1165 o Security Considerations 1166 o IANA Considerations 1168 6. Implementation Status 1170 This section records the status of known implementations of the 1171 protocol defined by this specification at the time of posting of this 1172 Internet-Draft, and is based on a proposal described in [RFC6982]. 1173 The description of implementations in this section is intended to 1174 assist the IETF in its decision processes in progressing drafts to 1175 RFCs. Please note that the listing of any individual implementation 1176 here does not imply endorsement by the IETF. Furthermore, no effort 1177 has been spent to verify the information presented here that was 1178 supplied by IETF contributors. This is not intended as, and must not 1179 be construed to be, a catalog of available implementations or their 1180 features. Readers are advised to note that other implementations may 1181 exist. 1183 According to [RFC6982], "this will allow reviewers and working groups 1184 to assign due consideration to documents that have the benefit of 1185 running code, which may serve as evidence of valuable experimentation 1186 and feedback that have made the implemented protocols more mature. 1187 It is up to the individual working groups to use this information as 1188 they see fit". 1190 First F-Interop ETSI 6TiSCH plugtests: 6P is one of the protocols 1191 addressed during the First F-Interop ETSI 6TiSCH plugtests 1192 organized on 14-15 July 2017 in Prague, Czech Republic. TODO: 1193 update when event over; probably includes further open source 1194 implementation. 1195 ETSI 6TiSCH/6lo plugtests: 6P was one of the protocols addressed 1196 during the ETSI 6TiSCH #3 plugtests organized on 15-17 July 2016 1197 in Berlin, Germany. 15 entities participated in this event, 1198 verifying the compliance and interoperability of their 1199 implementation of 6P. This event happened under NDA, so neither 1200 the name of the entities nor the test results are public. This 1201 event is, however, a clear indication of the maturity of 6P, and 1202 the interest it generates. More information about the event at 1203 http://www.etsi.org/news-events/events/1077-6tisch-6lo-plugtests. 1204 ETSI 6TiSCH #2 plugtests: 6P was one of two protocols addressed 1205 during the ETSI 6TiSCH #2 plugtests organized on 2-4 February 2016 1206 in Paris, France. 14 entities participated in this event, 1207 verifying the compliance and interoperability of their 1208 implementation of 6P. This event happened under NDA, so neither 1209 the name of the entities nor the test results are public. This 1210 event is, however, a clear indication of the maturity of 6P, and 1211 the interest it generates. More information about the event at 1212 http://www.etsi.org/news-events/events/1022-6TiSCH-2-plugtests. 1213 OpenWSN: 6P is implemented in the OpenWSN project [OpenWSN] under a 1214 BSD open-source license. The authors of this document are 1215 collaborating with the OpenWSN community to gather feedback about 1216 the status and performance of the protocols described in this 1217 document. Results from that discussion will appear in this 1218 section in future revision of this specification. More 1219 information about this implementation at http://www.openwsn.org/. 1220 F-Interop Interoperability/Conformance Testing tool The F-Interop 1221 project is putting together an online tool to conduct online and 1222 remote interoperability/conformance tests. 6P is one of the 1223 supported protocols. 1224 6TiSCH simulator The 6TiSCH simulator is a Python-based high-level 1225 simulator which implements 6P and is built to evaluate the 1226 performance of differents SFs. More information at 1227 https://bitbucket.org/6tisch/simulator/. 1228 Wireshark Dissector: A Wireshark dissector for 6P is implemented 1229 under a BSD open-source license. It is developed and maintained 1230 at https://github.com/openwsn-berkeley/dissectors/, and regularly 1231 merged into the main Wireshark repository. Please see the 1232 Wireshark documentation to see what version of 6P it supports. 1234 7. Security Considerations 1236 6P messages are carried inside 802.15.4 Payload Information Elements 1237 (IEs). Those Payload IEs are encrypted and authenticated at the link 1238 layer through CCM*. 6P benefits from the same level of security as 1239 any other Payload IE. The 6P protocol does not define its own 1240 security mechanisms. A key management solution is out of scope for 1241 this document. The 6P protocol will benefit for the key management 1242 solution used in the network. 1244 8. IANA Considerations 1246 8.1. IETF IE Subtype '6P' 1248 This document adds the following number to the "IEEE Std 802.15.4 1249 IETF IE subtype IDs" registry defined by [RFC8137]: 1251 +--------------------+------+-----------+ 1252 | Subtype | Name | Reference | 1253 +--------------------+------+-----------+ 1254 | IANA_6TOP_SUBIE_ID | 6P | RFCXXXX | 1255 +--------------------+------+-----------+ 1257 Figure 23: IETF IE Subtype '6P'. 1259 8.2. 6TiSCH parameters sub-registries 1261 This section defines sub-registries within the "IPv6 over the TSCH 1262 mode of IEEE 802.15.4e (6TiSCH) parameters" registry, hereafter 1263 referred to as the "6TiSCH parameters" registry. Each sub-registry 1264 is described in a subsection. 1266 8.2.1. 6P Version Numbers 1268 The name of the sub-registry is "6P Version Numbers". 1270 A Note included in this registry should say: "In the 6top Protocol 1271 (6P) [RFCXXXX] there is a field to identify the version of the 1272 protocol. This field is 4 bits in size." 1274 Each entry in the sub-registry must include the Version in the range 1275 0-15, and a reference to the 6P version's documentation. 1277 The initial entry in this sub-registry is as follows: 1279 +---------+-----------+ 1280 | Version | Reference | 1281 +---------+-----------+ 1282 | 0 | RFCXXXX | 1283 +---------+-----------+ 1285 Figure 24: 6P Version Numbers. 1287 All other Version Numbers are Unassigned. 1289 The IANA policy for future additions to this sub-registry is "IETF 1290 Review or IESG Approval" as described in [RFC5226]. 1292 8.2.2. 6P Message Types 1294 The name of the sub-registry is "6P Message Types". 1296 A Note included in this registry should say: "In the 6top Protocol 1297 (6P) version 0 [RFCXXXX], there is a field to identify the type of 1298 message. This field is 2 bits in size." 1300 Each entry in the sub-registry must include the Type in the range 1301 b00-b11, the corresponding Name, and a reference to the 6P message 1302 type's documentation. 1304 Initial entries in this sub-registry are as follows: 1306 +------+--------------+-----------+ 1307 | Type | Name | Reference | 1308 +------+--------------+-----------+ 1309 | b00 | REQUEST | RFCXXXX | 1310 | b01 | RESPONSE | RFCXXXX | 1311 | b10 | CONFIRMATION | RFCXXXX | 1312 +------+--------------+-----------+ 1314 Figure 25: 6P Message Types. 1316 All other Message Types are Reserved. 1318 The IANA policy for future additions to this sub-registry is "IETF 1319 Review or IESG Approval" as described in [RFC5226]. 1321 8.2.3. 6P Command Identifiers 1323 The name of the sub-registry is "6P Command Identifiers". 1325 A Note included in this registry should say: "In the 6top Protocol 1326 (6P) version 0 [RFCXXXX], there is a Code field which is 8 bits in 1327 size. In a 6P Request, the value of this Code field is used to 1328 identify the command." 1330 Each entry in the sub-registry must include the Identifier in the 1331 range 0-255, the corresponding Name, and a reference to the 6P 1332 command identifier's documentation. 1334 Initial entries in this sub-registry are as follows: 1336 +------------+------------+-----------+ 1337 | Identifier | Name | Reference | 1338 +------------+------------+-----------+ 1339 | 0 | Reserved | | 1340 | 1 | ADD | RFCXXXX | 1341 | 2 | DELETE | RFCXXXX | 1342 | 3 | RELOCATE | RFCXXXX | 1343 | 4 | COUNT | RFCXXXX | 1344 | 5 | LIST | RFCXXXX | 1345 | 6 | CLEAR | RFCXXXX | 1346 | 7-254 | Unassigned | | 1347 | 255 | Reserved | | 1348 +------------+------------+-----------+ 1350 Figure 26: 6P Command Identifiers. 1352 The IANA policy for future additions to this sub-registry is "IETF 1353 Review or IESG Approval" as described in [RFC5226]. 1355 8.2.4. 6P Return Codes 1357 The name of the sub-registry is "6P Return Codes". 1359 A Note included in this registry should say: "In the 6top Protocol 1360 (6P) version 0 [RFCXXXX], there is a Code field which is 8 bits in 1361 size. In a 6P Response or 6P Confirmation, the value of this Code 1362 field is used to identify the return code." 1364 Each entry in the sub-registry must include the Code in the range 1365 0-255, the corresponding Name, the corresponding Description, and a 1366 reference to the 6P return code's documentation. 1368 Initial entries in this sub-registry are as follows: 1370 +--------+-------------+---------------------------+-----------+ 1371 | Code | Name | Description | Is Error? | 1372 +--------+-------------+---------------------------+-----------+ 1373 | 0 | SUCCESS | operation succeeded | No | 1374 | 1 | ERROR | generic error | Yes | 1375 | 2 | EOL | end of list | No | 1376 | 3 | RESET | critical error, reset | Yes | 1377 | 4 | VER_ERR | unsupported 6P version | Yes | 1378 | 5 | SFID_ERR | unsupported SFID | Yes | 1379 | 6 | GEN_ERR | wrong schedule generation | Yes | 1380 | 7 | BUSY | busy | Yes | 1381 | 8 | NORES | not enough resources | Yes | 1382 | 9 | CELLLIST_ERR| cellList error | Yes | 1383 +--------+-------------+---------------------------+-----------+ 1385 Figure 27: 6P Return Codes. 1387 All other Message Types are Unassigned. 1389 The IANA policy for future additions to this sub-registry is "IETF 1390 Review or IESG Approval" as described in [RFC5226]. 1392 8.2.5. 6P Scheduling Function Identifiers 1394 6P Scheduling Function Identifiers. 1396 A Note included in this registry should say: "In the 6top Protocol 1397 (6P) version 0 [RFCXXXX], there is a field to identify the scheduling 1398 function to handle the message. This field is 8 bits in size." 1400 Each entry in the sub-registry must include the SFID in the range 1401 0-255, the corresponding Name, and a reference to the 6P Scheduling 1402 Function's documentation. 1404 The initial entry in this sub-registry is as follows: 1406 +-------+--------------------------+----------------------------+ 1407 | SFID | Name | Reference | 1408 +-------+--------------------------+----------------------------+ 1409 | 0 | Scheduling Function Zero | draft-ietf-6tisch-6top-sf0 | 1410 +-------+--------------------------+----------------------------+ 1412 Figure 28: SF Identifiers (SFID). 1414 All other Message Types are Unassigned. 1416 The IANA policy for future additions to this sub-registry depends on 1417 the value of the SFID, as defined in Figure 29. These specifications 1418 must follow the guidelines of Section 5. 1420 +-----------+------------------------------+ 1421 | Range | Registration Procedures | 1422 +-----------+------------------------------+ 1423 | 0-127 | IETF Review or IESG Approval | 1424 | 128-255 | Expert Review | 1425 +-----------+------------------------------+ 1427 Figure 29: SF Identifier (SFID): Registration Procedures. 1429 8.2.6. 6P CellOptions bitmap 1431 The name of the sub-registry is "6P CellOptions bitmap". 1433 A Note included in this registry should say: "In the 6top Protocol 1434 (6P) version 0 [RFCXXXX], there is an optional CellOptions field 1435 which is 8 bits in size." 1437 Each entry in the sub-registry must include the bit position in the 1438 range 0-7, the corresponding Name, and a reference to the bit's 1439 documentation. 1441 Initial entries in this sub-registry are as follows: 1443 +-----+---------------+-----------+ 1444 | bit | Name | Reference | 1445 +-----+---------------+-----------+ 1446 | 0 | TX (Transmit) | RFCXXXX | 1447 | 1 | RX (Receive) | RFCXXXX | 1448 | 2 | SHARED | RFCXXXX | 1449 | 3-7 | Reserved | | 1450 +-----+---------------+-----------+ 1452 Figure 30: 6P CellOptions bitmap. 1454 All other Message Types are Reserved. 1456 The IANA policy for future additions to this sub-registry is "IETF 1457 Review or IESG Approval" as described in [RFC5226]. 1459 9. References 1460 9.1. Normative References 1462 [IEEE802154] 1463 IEEE standard for Information Technology, "IEEE Std 1464 802.15.4-2015 - IEEE Standard for Low-Rate Wireless 1465 Personal Area Networks (WPANs)", October 2015. 1467 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1468 Requirement Levels", BCP 14, RFC 2119, 1469 DOI 10.17487/RFC2119, March 1997, 1470 . 1472 [RFC8137] Kivinen, T. and P. Kinney, "IEEE 802.15.4 Information 1473 Element for the IETF", RFC 8137, DOI 10.17487/RFC8137, May 1474 2017, . 1476 9.2. Informative References 1478 [OpenWSN] Watteyne, T., Vilajosana, X., Kerkez, B., Chraim, F., 1479 Weekly, K., Wang, Q., Glaser, S., and K. Pister, "OpenWSN: 1480 a Standards-Based Low-Power Wireless Development 1481 Environment", Transactions on Emerging Telecommunications 1482 Technologies , August 2012. 1484 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1485 IANA Considerations Section in RFCs", RFC 5226, 1486 DOI 10.17487/RFC5226, May 2008, 1487 . 1489 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1490 Code: The Implementation Status Section", RFC 6982, 1491 DOI 10.17487/RFC6982, July 2013, 1492 . 1494 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 1495 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 1496 Internet of Things (IoT): Problem Statement", RFC 7554, 1497 DOI 10.17487/RFC7554, May 2015, 1498 . 1500 [RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal 1501 IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) 1502 Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180, 1503 May 2017, . 1505 Appendix A. [TEMPORARY] Changelog 1507 o draft-ietf-6tisch-6top-protocol-07 1509 * Inverting NORES and BUSY error codes for concurrent 1510 transactions. 1511 * Adding missing implementations. 1512 * Fixing references. 1513 * Fixing typos. 1514 o draft-ietf-6tisch-6top-protocol-06 1516 * Changing error code from RESET to CELLLIST_ERR when deleting 1517 unscheduled cells. 1518 * Fixing typos. 1519 o draft-ietf-6tisch-6top-protocol-05 1521 * complete reorder of sections. Merged protocol behavior and 1522 command description 1523 * STATUS to COUNT 1524 * written-out IANA section 1525 * complete proof-read 1526 o draft-ietf-6tisch-6top-protocol-04 1528 * recommendation on which cells to use for 6P traffic 1529 * relocation format: added numberofCells field 1530 * created separate section about "cell suggestion" 1531 * Added RC_ERR_CELLLIST and RC_ERR_EOL error codes 1532 * Added example for two step with the failure 1533 * Recommended numbers in IANA section 1534 * single generation number 1535 * IEEE802.15.4 -> IEEE Std 802.15.4 or 802.15.4 1536 * complete proof-read 1537 o draft-ietf-6tisch-6top-protocol-03 1539 * Added a reference to [RFC8137]. 1540 * Added the Type field. 1541 * Editorial changes (figs, typos, ...) 1542 o draft-ietf-6tisch-6top-protocol-02 1544 * Rename COUNT to STATUS 1545 * Split LIST to LIST AB and LIST BA 1546 * Added generation counters and describing generation tracking of 1547 the schedule 1548 * Editorial changes (figs, typos, ...) 1549 o draft-ietf-6tisch-6top-protocol-01 1551 * Clarifying locking of resources in concurrent transactions 1552 * Clarifying return of RC_ERR_BUSY in case of concurrent 1553 transactions without enough resources 1554 o draft-ietf-6tisch-6top-protocol-00 1556 * Informational to Std track 1557 o draft-wang-6tisch-6top-protocol-00 1559 * Editorial overhaul: fixing typos, increasing readability, 1560 clarifying figures. 1561 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1562 issues/47 1563 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1564 issues/54 1565 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1566 issues/55 1567 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1568 issues/49 1569 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1570 issues/53 1571 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1572 issues/44 1573 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1574 issues/48 1575 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1576 issues/43 1577 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1578 issues/52 1579 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1580 issues/45 1581 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1582 issues/51 1583 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1584 issues/50 1585 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1586 issues/46 1587 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1588 issues/41 1589 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1590 issues/42 1591 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1592 issues/39 1593 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1594 issues/40 1595 o draft-wang-6tisch-6top-sublayer-05 1597 * Specifies format of IE 1598 * Adds token in messages to match request and response 1599 o draft-wang-6tisch-6top-sublayer-04 1600 * Renames IANA_6TOP_IE_GROUP_ID to IANA_IETF_IE_GROUP_ID. 1601 * Renames IANA_CMD and IANA_RC to IANA_6TOP_CMD and IANA_6TOP_RC. 1602 * Proposes IANA_6TOP_SUBIE_ID with value 0x00 for the 6top sub- 1603 IE. 1604 o draft-wang-6tisch-6top-sublayer-03 1606 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 1607 protocol/issues/32/missing-command-list 1608 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 1609 protocol/issues/31/missing-command-count 1610 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 1611 protocol/issues/30/missing-command-clear 1612 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1613 issues/37/6top-atomic-transaction-6p-transaction 1614 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 1615 protocol/issues/35/separate-opcode-from-rc 1616 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 1617 protocol/issues/36/add-length-field-in-ie 1618 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 1619 protocol/issues/27/differentiate-rc_err_busy-and 1620 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 1621 protocol/issues/29/missing-rc-rc_reset 1622 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 1623 protocol/issues/28/the-sf-must-specify-the-behavior-of-a-mote 1624 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 1625 protocol/issues/26/remove-including-their-number 1626 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1627 issues/34/6of-sf 1628 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 1629 protocol/issues/33/add-a-figure-showing-the-negociation 1630 o draft-wang-6tisch-6top-sublayer-02 1632 * introduces the 6P protocol and the notion of 6top Transaction. 1633 * introduces the concept of 6OF and its 6OFID. 1635 Authors' Addresses 1637 Qin Wang (editor) 1638 Univ. of Sci. and Tech. Beijing 1639 30 Xueyuan Road 1640 Beijing, Hebei 100083 1641 China 1643 Email: wangqin@ies.ustb.edu.cn 1644 Xavier Vilajosana 1645 Universitat Oberta de Catalunya 1646 156 Rambla Poblenou 1647 Barcelona, Catalonia 08018 1648 Spain 1650 Email: xvilajosana@uoc.edu 1652 Thomas Watteyne 1653 Analog Devices 1654 32990 Alvarado-Niles Road, Suite 910 1655 Union City, CA 94587 1656 USA 1658 Email: twatteyne@linear.com