idnits 2.17.1 draft-ietf-6tisch-6top-protocol-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 29, 2017) is 2586 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 1408, but not defined == Missing Reference: 'TEMPORARY' is mentioned on line 1480, but not defined ** Downref: Normative reference to an Informational draft: draft-kivinen-802-15-ie (ref. 'I-D.kivinen-802-15-ie') -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802154-2015' -- Obsolete informational reference (is this intentional?): RFC 6982 (Obsoleted by RFC 7942) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) 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: September 30, 2017 Universitat Oberta de Catalunya 6 T. Watteyne 7 Analog Devices 8 March 29, 2017 10 6top Protocol (6P) 11 draft-ietf-6tisch-6top-protocol-04 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. Different SFs are expected to be defined in future 25 companion 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 September 30, 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 Transaction . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . . . . 27 104 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 105 8.1. IETF IE Subtype '6P' . . . . . . . . . . . . . . . . . . 27 106 8.2. 6TiSCH parameters sub-registries . . . . . . . . . . . . 28 107 8.2.1. 6P Version Numbers . . . . . . . . . . . . . . . . . 28 108 8.2.2. 6P Message Types . . . . . . . . . . . . . . . . . . 28 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 in 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 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, NOT part of the final text. 139 o This section will be removed in the final text. 141 2. Introduction 143 All communication in a 6TiSCH network is orchestrated by a schedule 144 [RFC7554]. This specification defines the 6top Protocol (6P), part 145 of the 6TiSCH Operation sublayer (6top). 6P allows a node to 146 communicate with a neighbor to add/delete TSCH cells to one another. 147 This results in distributed schedule management in a 6TiSCH network. 149 (R) 150 / \ 151 / \ 152 (B)-----(C) 153 | | 154 | | 155 (A) (D) 157 Figure 1: A simple 6TiSCH network. 159 The example network depicted in Figure 1 is used to describe the 160 interaction between nodes. We consider the canonical case where node 161 "A" issues 6P requests to node "B". We keep this example throughout 162 this document. Throughout the document, node A will always represent 163 the node that issues a 6P request; node B the node that receives this 164 request. 166 We consider that node A monitors the communication cells it has in 167 its schedule to node B: 169 o If node A determines that the number of link-layer frames it is 170 sending to B per unit of time is larger than the capacity offered 171 by the TSCH cells it has scheduled to B, it triggers a 6P 172 Transaction with node B to add one or more cells to the TSCH 173 schedule of both nodes. 174 o If the traffic is lower than the capacity, node A triggers a 6P 175 Transaction with node B to delete one or more cells in the TSCH 176 schedule of both nodes. 177 o Node A MAY also monitor statistics to determine whether collisions 178 are happening on a particular cell to node B. If this feature is 179 enabled, node A communicates with node B to add a new cell and 180 delete the cell which suffered from collisions. This results in 181 "relocating" the cell which suffered from collisions to a 182 different [slotOffset,channelOffset] location in the TSCH 183 schedule. The mechanism to handle cell relocation is out of the 184 scope of this document and might be handled by the scheduling 185 function (see below). 187 This results in distributed schedule management in a 6TiSCH network. 189 The 6top Scheduling Function (SF) defines when to add/delete a cell 190 to a neighbor. Different applications require different SFs, so the 191 SF is left out of scope of this document. Different SFs are expected 192 to be defined in future companion specifications. A node MAY 193 implement multiple SFs and run them at the same time. At least one 194 SF MUST be running. The SFID field contained in all 6P messages 195 allows a node to invoke the appropriate SF on a per-transaction 196 basis. 198 Section 3 describes the 6TiSCH Operation Sublayer (6top). Section 4 199 defines the 6top Protocol (6P). Section 5 provides guidelines on how 200 to design an SF. 202 3. 6TiSCH Operation Sublayer (6top) 204 As depicted in Figure 2, the 6TiSCH Operation Sublayer (6top) is the 205 next higher layer to the IEEE Std 802.15.4 TSCH medium access control 206 layer [IEEE802154-2015]. We use "802.15.4" as a short version of 207 "IEEE Std 802.15.4" in this document. 209 . 210 | . | 211 | higher layers | 212 +------------------------------------------+ 213 | 6top | 214 +------------------------------------------+ 215 | IEEE Std 802.15.4 TSCH | 216 | . | 217 . 219 Figure 2: The 6top sublayer in the protocol stack. 221 The roles of the 6top sublayer are to: 223 o Implement and terminate the 6top Protocol (6P), which allows 224 neighbor nodes to communicate to add/delete cells to one another. 225 o Run one or more 6top Scheduling Functions (SF), which define the 226 rules that decide when to add/delete cells. 228 3.1. Hard/Soft Cells 230 Each cell in the schedule as either "hard" or "soft": 232 o a soft cell can be read, added, deleted or updated by 6top. 233 o a hard cell is read-only for 6top. 235 In the context of this specification, all the cells used by 6top are 236 soft cells. Hard cells can be used for example when "hard-coding" a 237 schedule. 239 3.2. Using 6P with the Minimal 6TiSCH Configuration 241 6P MAY be used alongside the Minimal 6TiSCH Configuration 242 [I-D.ietf-6tisch-minimal]. In this case, it is RECOMMENDED to use 2 243 slotframes, as depicted in Figure 3: 245 o Slotframe 0 is used for traffic defined in the Minimal 6TiSCH 246 Configuration. In Figure 3, this slotframe is 5 slots long, but 247 it can be of any length. 248 o Slotframe 1 is used for 6P to allocate cells from. In Figure 3, 249 this slotframe is 10 slots long, but it can be of any length. 251 | 0 1 2 3 4 | 0 1 2 3 4 | 252 +------------------------+------------------------+ 253 Slotframe 0 | | | | | | | | | | | 254 5 slots long | EB | | | | | EB | | | | | 255 | | | | | | | | | | | 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 | | | | | | | | | | | 263 +-------------------------------------------------+ 265 Figure 3: 2-slotframe structure when using 6P alongside the Minimal 266 6TiSCH Configuration. 268 The Minimal 6TiSCH Configuration cell SHOULD be allocated from a 269 slotframe of higher priority than the slotframe used by 6P for 270 dynamic cell allocation. This is to avoid dynamically allocated 271 cells to "mask" the cells used by the Minimal 6TiSCH Configuration. 272 6top MAY support additional slotframes; how to use additional 273 slotframes is out of the scope for this document. 275 4. 6top Protocol (6P) 277 The 6top Protocol (6P) allows two neighbor nodes to communicate to 278 add/delete/relocate cells to their TSCH schedule. Conceptually, two 279 neighbor nodes "negotiate" the location of the cells to add/delete/ 280 relocate. 282 4.1. 6P Transaction 284 We call "6P Transaction" a complete negotiation between two neighbor 285 nodes. A 6P Transaction starts when a node wishes to add/delete/ 286 relocate one or more cells to one of its neighbors. A 6P Transaction 287 ends when the cell(s) have been added/deleted/relocated from the 288 schedule of both nodes, or when the 6P Transaction has failed. 290 The 6P messages exchanged between nodes A and B during a 6P 291 Transaction SHOULD be exchanged on dedicated cells between A and B. 292 If no dedicated cells are scheduled between nodes A and B, shared 293 cells MAY be used. 295 Consistency between the schedules of the two neighbor nodes is of 296 utmost importance. A loss of consistency (e.g. node A has a transmit 297 cell to node B, but node B does not have the corresponding reception 298 cell) can cause loss of connectivity. To verify consistency, 299 neighbor nodes increment the "schedule generation" number of their 300 schedule each time their schedule is modified. Neighbor nodes 301 exchange the schedule generation number at each 6P Transaction to 302 detect possible inconsistencies. This mechanism is explained in 303 Section 4.4.7. 305 An implementation MUST include a mechanism to associate each 306 scheduled cell with the SF that scheduled it. This mechanism is 307 implementation-specific and out of the scope of this document. 309 A 6P Transaction can consist of 2 or 3 steps. It is the SF which 310 determines whether to use 2-step or 3-step transactions. An SF MAY 311 use both 2-step and 3-step transactions. 313 We reuse the topology in Figure 1 to illustrate 2-step and 3-step 314 transactions. 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 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 timeout timer to 351 abort the transaction if no response has been received when it 352 expires. 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 it selected. 356 6. The result of this 6P Transaction is that 2 cells from A to B 357 have been added to the TSCH schedule of both nodes A and B. The 358 schedule generation (see Section 4.4.7) is incremented to allow 359 inconsistency detection. 361 2-step transaction is used when 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 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 timeout timer to 401 abort the transaction if no response has been received when it 402 expires. 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 timeout 406 timer to abort the transaction if no response has been received 407 when it expires. 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. The result of this 6P Transaction is that 2 cells from A to B 411 have been added to the TSCH schedule of both nodes A and B. The 412 schedule generation (see Section 4.4.7) is incremented to allow 413 inconsistencies detection. 415 3-step transaction is used when node B selects the candidate cells. 417 4.2. Message Format 419 4.2.1. 6top Information Element 421 6P messages are carried as payload of a 802.15.4 Payload Information 422 Element (IE) [IEEE802154-2015]. 6P messages travel over a single 423 hop. 425 This document defines the "6top IE", a subtype of the IETF IE defined 426 in [I-D.kivinen-802-15-ie], with subtype IANA_6TOP_SUBIE_ID. The 427 length of the 6top IE content is variable. 429 4.2.2. Generic 6P Message Format 431 All 6P messages follow the generic format shown in Figure 6. 433 1 2 3 434 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 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 |Version| T | R | Code | SFID | SeqNum| GEN | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | Other Fields... 439 +-+-+-+-+-+-+-+-+- 441 Figure 6: Generic 6P Message Format. 443 6P Version (Version): The version of the 6P protocol. Only version 444 0 is defined in this document. Future specifications MAY 445 define further versions of the 6P protocol. 446 Type (T): Type of message. The possible message types are defined 447 in Section 8.2.2. 448 Reserved (R): Reserved bits. These two bits SHOULD be set to zero 449 when sending the message and MUST be ignored upon reception. 450 Code: The Code field contains a 6P Command Identifier when the 6P 451 message is of Type REQUEST. Section 8.2.3 lists the 6P command 452 identifiers. The Code field contains a 6P Return Code when the 453 6P message is of Type RESPONSE or CONFIRMATION. Section 8.2.4 454 lists the 6P Return Codes. The same Return Codes are used in 455 both 6P Response and 6P Confirmation messages. 456 6top Scheduling Function Identifier (SFID): The identifier of the SF 457 to use to handle this message. The SFID is defined in 458 Section 5.1. 459 SeqNum: Sequence number associated with the 6P Transaction, used to 460 match the 6P Request, 6P Response and 6P Confirmation of the 461 same 6P Transaction. The value of SeqNum MUST increment by 462 exactly one at each new 6P request issued to the same neighbor. 464 Schedule Generation (GEN): Schedule Generation for the transactions 465 between node A and node B. The generation is used to ensure 466 consistency between the schedules of the two neighbors. 467 Section 4.4.7 details how the schedule generation is managed. 468 Other Fields: The list of other fields depends on the type of 469 messages, and is detailed in Section 4.3. 471 4.2.3. 6P CellOptions 473 An 8-bit 6P CellOptions bitmap is present in the following 6P 474 requests: ADD, DELETE, COUNT, LIST, RELOCATE. 476 o In the 6P ADD request, the 6P CellOptions bitmap is used to 477 specify what type of cell to add. 478 o In the 6P DELETE request, the 6P CellOptions bitmap is used to 479 specify what type of cell to delete. 480 o In the 6P COUNT and the 6P LIST requests, the 6P CellOptions 481 bitmap is used as a selector of a particular type of cells. 482 o In the 6P RELOCATE request, the 6P CellOptions bitmap is used to 483 specify what type of cell to relocate. 485 The contents of the 6P CellOptions bitmap apply to all elements in 486 the CellList field. Section 8.2.6 contains the RECOMMENDED format of 487 the 6P CellOptions bitmap. Figure 7 contains the RECOMMENDED meaning 488 of the 6P CellOptions bitmap for the 6P COUNT and 6P LIST requests. 490 Note: assuming node A issues the 6P command to node B. 491 +-------------+-----------------------------------------------+ 492 | CellOptions | B's action when receiving a 6P message from A | 493 | Value | | 494 +-------------+-----------------------------------------------+ 495 |TX=0,RX=0,S=0| select all cells scheduled with A | 496 +-------------+-----------------------------------------------+ 497 |TX=1,RX=0,S=0| select the cells scheduled with A | 498 | | and marked as RX | 499 +-------------+-----------------------------------------------+ 500 |TX=0,RX=1,S=0| select the cells scheduled with A | 501 | | and marked as TX | 502 +-------------+-----------------------------------------------+ 503 |TX=1,RX=1,S=0| select the cells scheduled with A | 504 | | and marked as TX and RX | 505 +-------------+-----------------------------------------------+ 506 |TX=0,RX=0,S=1| select the cells scheduled with A | 507 | | and marked as SHARED | 508 +-------------+-----------------------------------------------+ 509 |TX=1,RX=0,S=1| select the cells scheduled with A | 510 | | and marked as RX and SHARED | 511 +-------------+-----------------------------------------------+ 512 |TX=0,RX=1,S=1| select the cells scheduled with A | 513 | | and marked as TX and SHARED | 514 +-------------+-----------------------------------------------+ 515 |TX=1,RX=1,S=1| select the cells scheduled with A | 516 | | and marked as TX and RX and SHARED | 517 +-------------+-----------------------------------------------+ 519 Figure 7: Meaning of the 6P CellOptions bitmap for the 6P COUNT and 520 the 6P LIST requests. 522 The CellOptions is an opaque set of bits, sent unmodified to the SF. 523 The SF MAY redefine the format of the CellOptions bitmap. The SF MAY 524 redefine the meaning of the CellOptions bitmap. 526 4.2.4. 6P CellList 528 A CellList field MAY be present in a 6P ADD Request, a 6P DELETE 529 Request, a 6P RELOCATE Request, a 6P Response or a 6P Confirmation. 530 It is composed of zero, one or more 6P Cell containers. The contents 531 of the CellOptions field specify the options associated all cells in 532 the CellList. This necessarily means that the same options are 533 associated with all cells in the CellList. 535 The 6P Cell is a 4-byte field, its RECOMMENDED format is: 537 1 2 3 538 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 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | slotOffset | channelOffset | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 Figure 8: 6P Cell Format. 545 slotOffset: The slot offset of the cell. 546 channelOffset: The channel offset of the cell. 548 The CellList is an opaque set of bytes, sent unmodified to the SF. 549 The SF MAY redefine the format of the CellList field. 551 4.3. 6P Commands and Operations 553 4.3.1. Adding Cells 555 Cells are added by using the 6P ADD command. The Type field (T) is 556 set to REQUEST. The Code field is set to ADD. Figure 9 defines the 557 format of a 6P ADD Request. 559 1 2 3 560 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 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 |Version| T | R | Code | SFID | SeqNum| GEN | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | Metadata | CellOptions | NumCells | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | CellList ... 567 +-+-+-+-+-+-+-+-+- 569 Figure 9: 6P ADD Request Format. 571 Metadata: Used as extra signaling to the SF. The contents of the 572 Metadata field is an opaque set of bytes passed unmodified to 573 the SF. The meaning of this field depends on the SF, and is 574 out of scope of this document. One example use can be to 575 specify which slotframe to schedule the cells on. 576 CellOptions: Indicates the options to associate with the cells to be 577 added. If more than one cell is added (NumCells>1), the same 578 options are associated with all of them. This necessarily 579 means that, if node A needs to add multiple cells with 580 different options, it needs to issue multiple 6P ADD 581 Transactions. 582 NumCells: The number of additional cells the sender wants to 583 schedule to the receiver. 584 CellList: A list of 0, 1 or multiple 6P Cells to be added. 586 Figure 10 defines the format of a 6P ADD Response and Confirmation. 588 1 2 3 589 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 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 |Version| T | R | Code | SFID | SeqNum| GEN | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | CellList ... 594 +-+-+-+-+-+-+-+-+- 596 Figure 10: 6P ADD Response and Confirmation Formats. 598 CellList: 0, 1 or multiple 6P Cells. 600 We assume the topology in Figure 1 where the SF on node A decides to 601 add NumCells cells to node B. 603 Node A's SF selects NumCandidate cells from its schedule as candidate 604 cells to node B. The CellOptions field specifies the type of these 605 cells. NumCandidate MUST be larger or equal to NumCells. How many 606 cells it selects (NumCandidate) and how that selection is done is 607 specified in the SF and out of scope of this document. Node A sends 608 a 6P ADD Request to node B which contains the CellOptions, the value 609 of NumCells and a selection of NumCandidate cells in the CellList. 610 In case the NumCandidate cells do not fit in a single packet, this 611 operation MUST be split in multiple independent 6P ADD Requests, each 612 for a subset of the number of cells that eventually need to be added. 614 Upon receiving the request, node B's SF verifies which of the cells 615 in the CellList it can install in its schedule following the 616 specified CellOptions field. How that selection is done is specified 617 in the SF and out of scope of this document. That verification can 618 succeed (NumCells cells from the CellList can be used), fail (none of 619 the cells from the CellList can be used) or partially succeed (less 620 than NumCells cells from the CellList can be used). In all cases, 621 node B MUST send a 6P Response with return code set to SUCCESS, and 622 which specifies the list of cells that were scheduled following the 623 CellOptions field. That can contain 0 elements (when the 624 verification failed), NumCells elements (succeeded) or between 0 and 625 NumCells elements (partially succeeded). 627 Upon receiving the response, node A adds the cells specified in the 628 CellList according to the request CellOptions field. 630 4.3.2. Deleting Cells 632 Cells are deleted by using the 6P DELETE command. The Type field (T) 633 is set to REQUEST. The Code field is set to DELETE. Figure 11 634 defines the format of a 6P DELETE Request. 636 1 2 3 637 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 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 |Version| T | R | Code | SFID | SeqNum| GEN | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | Metadata | CellOptions | NumCells | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 | CellList ... 644 +-+-+-+-+-+-+-+-+- 646 Figure 11: 6P DELETE Request Format. 648 Metadata: Same usage as for the 6P ADD command, see Section 4.3.1. 649 CellOptions: Indicates the options that need to be associated to the 650 cells to delete. Only the cells matching the CellOptions are 651 deleted. 652 NumCells: The number of cells from the specified CellList the sender 653 wants to delete from the schedule of both sender and receiver. 654 CellList: A list of 0, 1 or multiple 6P Cells. 656 Figure 12 defines the format of a 6P DELETE Response and 657 Confirmation. 659 1 2 3 660 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 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 |Version| T | R | Code | SFID | SeqNum| GEN | 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 | CellList ... 665 +-+-+-+-+-+-+-+-+- 667 Figure 12: 6P DELETE Response and Confirmation Formats. 669 CellList: 0, 1 or multiple 6P Cells. 671 The behavior for deleting cells is equivalent to that of adding cells 672 except that: 674 o The nodes delete the cells they agree upon rather than adding 675 them. 676 o All cells in the CellList MUST already be scheduled between the 677 two nodes and must match the CellOptions field. If node A puts 678 cells in its CellList that are not already scheduled between the 679 two nodes and match the CellOptions field, node B replies with a 680 ERR_RESET return code. 681 o If the CellList in the 6P Request is empty, the SF on the 682 receiving node is free to delete any cell from the sender, as long 683 as it matches the CellOptions field. 684 o The CellList in a 6P Request (2-step transaction) or 6P Response 685 (3-step transaction) MUST either be empty, contain exactly 686 NumCells cells, or more than NumCells cells. The case where the 687 CellList is not empty but contains less than NumCells cells is not 688 supported. 690 4.3.3. Relocating Cells 692 Cell relocation consists in moving a cell to a different 693 [slotOffset,channelOffset] location in the schedule. The Type field 694 (T) is set to REQUEST. The Code is set to RELOCATE. Figure 13 695 defines the format of a 6P RELOCATE Request. 697 1 2 3 698 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 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 |Version| T | R | Code | SFID | SeqNum| GEN | 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 | Metadata | CellOptions | NumCells | 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 | Rel. CellList ... |Cand. CellList (Optional) ... 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 Figure 13: 6P RELOCATE Request Format. 709 Metadata: Same usage as for the 6P ADD command, see Section 4.3.1. 710 CellOptions: Indicates the options that need to be associated to the 711 relocated cells. 712 NumCells: The number of cells to relocate, which MUST be equal or 713 greater than 1. 714 Relocation CellList: The list of NumCells 6P Cells to relocate. 715 Candidate CellList: A list of NumCandidate candidate cells for node 716 B to pick from. NumCandidate MUST be equal or greater than 717 NumCells. 719 Figure 14 defines the format of a 6P RELOCATE Response and 720 Confirmation. 722 1 2 3 723 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 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 |Version| T | R | Code | SFID | SeqNum| GEN | 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 | CellList ... 728 +-+-+-+-+-+-+-+-+- 730 Figure 14: 6P RELOCATE Response and Confirmation Formats. 732 CellList: 0, 1 or multiple 6P Cells. 734 Node A's SF wants to relocate NumCells cells. Node A creates a 6P 735 RELOCATE Request, and indicates the cells to relocate in the 736 Relocation CellList. It also selects NumCandidate cells from its 737 schedule as candidate cells for node B, and puts those in the 738 Candidate CellList. The CellOptions field specifies the type of the 739 cell(s) to relocate. NumCandidate MUST be larger or equal to 740 NumCells. How many cells it selects (NumCandidate) and how that 741 selection is done is specified in the SF and out of scope of this 742 document. Node A sends the 6P RELOCATE Request to node B. 744 Upon receiving the request, node B's SF verifies that all the cells 745 in the Relocation CellList are indeed scheduled with node A, and are 746 associate the options specified in the CellOptions field. If that 747 check fails, node B MUST send a 6P Response to node A with return 748 code ERR_CELLLIST. If that check passes, node B's SF verifies which 749 of the cells in the Candidate CellList it can install in its 750 schedule. How that selection is done is specified in the SF and out 751 of scope of this document. That verification on Candidate CellList 752 can succeed (NumCells cells from the Candidate CellList can be used), 753 fail (none of the cells from the Candidate CellList can be used) or 754 partially succeed (less than NumCells cells from the Candidate 755 CellList can be used). In all cases, node B MUST send a 6P Response 756 with return code set to SUCCESS, and which specifies the list of 757 cells that were scheduled following the CellOptions field. That can 758 contain 0 elements (when the verification failed), NumCells elements 759 (succeeded) or between 0 and NumCells elements (partially succeeded). 760 If N < NumCells cells appear in the CellList, this means first N 761 cells in the Relocation CellList have been relocated, the remainder 762 have not. 764 Upon receiving the response, node A relocates the cells specified in 765 Relocation CellList of its RELOCATE Request to the new location 766 specified in the CellList of the 6P Response. 768 +----------+ +----------+ 769 | Node A | | Node B | 770 +----+-----+ +-----+----+ 771 | | 772 | 6P RELOCATE Request | 773 | Type = REQUEST | 774 | Code = RELOCATE | 775 | NumCells = 2 | 776 | R.CellList = [(1,2),(2,2)] | 777 | C.CellList = [(3,2),(4,2),(6,5)] | 778 |-------------------------------------->| B relocates 779 | | (1,2)->(4,2) 780 | 6P Response | but cannot 781 | Type = RESPONSE | relocate (2,2) 782 | Code = SUCCESS | 783 | CellList = [(4,2)] | 784 A relocates |<--------------------------------------| 785 (1,2)->(4,2)| | 787 Figure 15: 6P RELOCATE Example. 789 4.3.4. Counting Cells 791 To retrieve the number of scheduled cells at B, node A issues a 6P 792 COUNT command. The Type field (T) is set to REQUEST. The Code field 793 is set to COUNT. Figure 16 defines the format of a 6P COUNT Request. 795 1 2 796 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 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 |Version| T | R | Code | SFID | SeqNum| GEN | 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 | Metadata | CellOptions | 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 Figure 16: 6P COUNT Request Format. 805 Metadata: Same usage as for the 6P ADD command, see Section 4.3.1. 806 CellOptions: Specifies which types of cells to be counted. 808 Figure 17 defines the format of a 6P COUNT Response and Confirmation. 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 and Confirmation Formats. 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 CellOptions: Specifies which types of cells to be listed. 854 Reserved: Set to 0. 855 Offset: The Offset of the first scheduled cell that is requested. 856 The mechanism assumes cells are ordered according to a rule 857 defined in the SF. This rule MUST always order the cells in 858 the same way. 859 MaxNumCells: The maximum number of requested cells. Node B MAY 860 returns less than MaxNumCells cells, for example if MaxNumCells 861 cells do not fit in the frame. 863 Figure 19 defines the format of a 6P LIST Response and Confirmation. 865 1 2 3 866 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 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 |Version| T | R | Code | SFID | SeqNum| GEN | 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 | CellList ... 871 +-+-+-+-+-+-+-+-+- 873 Figure 19: 6P LIST Response and Confirmation Formats. 875 CellList: 0, 1 or multiple 6P Cells. 877 When receiving a LIST command, node B returns the cells in its 878 schedule that match the CellOptions field as specified in 879 Section 4.2.3 881 When node B receives a LIST request, the returned CellList in the 6P 882 Response contains between 1 and MaxNumCells cells, starting from the 883 specified offset. Node B SHOULD include as many cells as fit in the 884 frame. If the response contains the last cell, Node B MUST set the 885 Code field in the response to ERR_EOL, indicating to Node A that 886 there no more cells that match the request. Node B MUST return at 887 least one cell, unless the specified Offset is beyond the end of B's 888 cell list in its schedule. If node B has less than Offset cells that 889 match the request, node B returns an empty CellList and a Code field 890 set to ERR_EOL. 892 4.3.6. Clearing the Schedule 894 To clear the schedule between nodes A and B (for example after a 895 schedule inconsistency is detected), node A issues a CLEAR command. 896 The Type field (T) is set to 6P Request. The Code field is set to 897 CLEAR. Figure 20 defines the format of a 6P CLEAR Request. 899 1 2 900 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 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 |Version| T | R | Code | SFID | SeqNum| GEN | 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 904 | Metadata | 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 907 Figure 20: 6P CLEAR Request Format. 909 Metadata: Same usage as for the 6P ADD command, see Section 4.3.1. 911 Figure 21 defines the format of a 6P CLEAR Response and Confirmation. 913 1 2 3 914 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 915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 916 |Version| T | R | Code | SFID | SeqNum| GEN | 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 919 Figure 21: 6P CLEAR Response and Confirmation Formats. 921 When a 6P CLEAR command is issued from node A to node B, both nodes A 922 and B MUST remove all the cells scheduled between them. That is, 923 node A MUST remove all the cells scheduled with B, and node B MUST 924 remove all the cells scheduled with A. In a 6P CLEAR command, the 925 generation counter GEN MUST NOT be checked. That is, its value is 926 "don't care". In particular, even if the request contains a GEN 927 value that would normally cause node B to detect a schedule 928 generation mismatch, the transaction MUST NOT be aborted. 930 4.4. Protocol Functional Details 932 4.4.1. Version Checking 934 All messages contain a Version field. If multiple Versions of the 6P 935 protocol have been defined (in future specifications for Version 936 values different from 0), a node MAY implement multiple protocol 937 versions at the same time. When receiving a 6P message with a 938 Version number it does not implement, a node MUST reply with a 6P 939 Response with a Return Code field set to ERR_VER. The Version field 940 in the 6P Response MUST be the same as the Version field in the 941 corresponding 6P Request. In a 3-step transaction, the Version field 942 in the 6P Confirmation MUST match that of the 6P Request and 6P 943 Response in the same transaction. 945 4.4.2. SFID Checking 947 All messages contain a SFID field. A node MAY support multiple SFs 948 at the same time. When receiving a 6P message with an unsupported 949 SFID, a node MUST reply with a 6P Response and a return code of 950 ERR_SFID. The SFID field in the 6P Response MUST be the same as the 951 SFID field in the corresponding 6P Request. In a 3-step transaction, 952 the SFID field in the 6P Confirmation MUST match that of the 6P 953 Request and 6P Response in the same transaction. 955 4.4.3. Concurrent 6P Transactions 957 Only a single 6P Transaction between two neighbors, in a given 958 direction, can take place at the same time. That is, a node MUST NOT 959 issue a new 6P Request to a given neighbor before having received the 960 6P Response for a previous request to that neighbor. The only 961 exception to this rule is when the previous 6P Transaction has timed 962 out. If a node receives a 6P Request from a given neighbor before 963 having sent the 6P Response to the previous 6P Request from that 964 neighbor, it MUST send back a 6P Response with a return code of 965 ERR_RESET. A node receiving ERR_RESET MUST abort the transaction and 966 consider it never happened. 968 Nodes A and B MAY support having two transactions going on at the 969 same time, one in each direction. Similarly, a node MAY support 970 concurrent 6P Transactions from different neighbors. In this case, 971 the cells involved in an ongoing 6P Transaction MUST be locked until 972 the transaction finishes. For example, in Figure 1, node C can have 973 a different ongoing 6P Transaction with nodes B and R. In case a 974 node does not have enough resources to handle concurrent 6P 975 Transactions from different neighbors it MUST reply with a 6P 976 Response with return code ERR_NORES. In case the requested cells are 977 locked, it MUST reply to that request with a 6P Response with return 978 code ERR_BUSY. The node receiving ERR_BUSY or an ERR_NORES MAY 979 implement a retry mechanism, defined by the SF. 981 4.4.4. Timeout 983 A timeout happens when the node sending the 6P Request has not 984 received the 6P Response. In a 3-step transaction, a timeout also 985 happens when the node sending the 6P Response has not received the 6P 986 Confirmation. The timeout should be longer than the longest possible 987 time it can take for the exchange to finish. The value of the 988 timeout hence depends on the number of cells scheduled between the 989 neighbor nodes, the maximum number of link-layer retransmissions, 990 etc. The SF MUST determine the value of the timeout. The value of 991 the timeout is out of scope of this document. 993 4.4.5. SeqNum Mismatch 995 A SeqNum mismatch happens when a node receives a 6P Response or 6P 996 Confirmation with SeqNum value different from the SeqNum value in the 997 6P Request. When it detects a SeqNum mismatch, the node MUST drop 998 the packet and consider the 6P Transaction as having failed. 1000 4.4.6. Aborting a 6P Transaction 1002 In case the receiver of a 6P Request fails during a 6P Transaction 1003 and is unable to complete it, it SHOULD reply to that request with a 1004 6P Response with return code ERR_RESET. Upon receiving this 6P 1005 Response, the initiator of the 6P Transaction MUST consider the 6P 1006 Transaction as failed. 1008 4.4.7. Generation Management 1010 For each neighbor, a node maintains a 4-bit generation number. The 1011 generation number counts the number of transactions that have 1012 modified the schedule with the particular neighbor so far. This 1013 number is a variable internal to the node. 1015 4.4.7.1. Incrementing the Generation Number 1017 The generation number is incremented as a 4-bit lollipop counter. 1018 Its possible values are: 1020 +---------+---------------------------+ 1021 | Value | Meaning | 1022 +---------+---------------------------+ 1023 | 0x0 | Clear or never scheduled | 1024 | 0x1-0x9 | Lollipop Counter values | 1025 | 0xa-0xf | Reserved | 1026 +---------+---------------------------+ 1028 Figure 22: Possible values of the generation number. 1030 The generation number is set to 0 upon initialization, and after a 6P 1031 CLEAR command. The generation number is incremented by exactly 1 1032 each time a cell with that neighbor is added/deleted/relocated from 1033 the schedule (e.g. after a successful 6P ADD, 6P DELETE or 6P 1034 RELOCATE transaction). The value rolls from 0x9 to 0x1 (i.e. not 1035 0x0). This results in a lollipop counter with 0x0 the start value, 1036 and 0x1-0x9 the count values. Values from 0xa to 0xf are reserved 1037 and MUST NOT be used. 1039 4.4.7.2. Setting GEN field in the 6P Message Header 1041 Each 6P message contains a GEN field, used to indicate the current 1042 generation number of the node transmitting the message. The value of 1043 the GEN field MUST be set according to the following rules: 1045 o When node A sends a 6P Request or 6P Confirmation to node B, node 1046 A sets GEN to its generation number for Node B. 1047 o When node B sends a 6P Response to node A, node B sets GEN to its 1048 generation number for node A. 1050 4.4.7.3. Detecting and Handling Schedule Generation Inconsistencies 1052 Upon receiving a 6P message, a node MUST do the following checks: 1054 o When node B receives a 6P Request or 6P Confirmation from node A, 1055 it verifies that the value of the GEN field in the 6P message is 1056 equal to its internal generation number. 1057 o When node A receives a 6P Response from node B, it verifies that 1058 the value of the GEN field in the 6P message is equal to its 1059 internal generation number. 1061 If any of these comparisons is false, the node has detected a 1062 schedule generation inconsistency. 1064 When a schedule generation inconsistency is detected: 1066 o If the code of the 6P Request is different from CLEAR, the node 1067 MUST reply with error code ERR_GEN. 1068 o If the code of the 6P Request is CLEAR, the schedule generation 1069 inconsistency MUST be ignored. 1071 It is up to the Scheduling Function to define the action to take when 1072 an schedule generation inconsistency is detected. The RECOMMENDED 1073 action is to issue a 6P CLEAR command. 1075 4.4.8. Handling Error Responses 1077 A return code with a name starting with "ERR_" in Figure 27 indicates 1078 an error. When a node receives a 6P Response or 6P Confirmation with 1079 such an error, it MUST consider the 6P Transaction failed. In 1080 particular, if this was a response to a 6P ADD/DELETE/RELOCATE 1081 Request, the node MUST NOT add/delete/relocate any of the cells 1082 involved in this 6P Transaction. Similarly, a node sending a 6P 1083 Response or a 6P Confirmation with an "ERR_*" return code MUST NOT 1084 add/delete/relocate any cells as part of that 6P Transaction. 1085 Defining what to do after an error has occurred is out of scope of 1086 this document. The SF defines what to do after an error has 1087 occurred. 1089 4.5. Security 1091 6P messages are secured through link-layer security. When link-layer 1092 security is enabled, the 6P messages MUST be secured. This is 1093 possible because 6P messages are carried as Payload IE. 1095 5. Guidelines for 6top Scheduling Functions (SF) 1097 5.1. SF Identifier (SFID) 1099 Each SF has a 1-byte identifier. Section 8.2.5 defines the rules for 1100 applying for an SFID. 1102 5.2. Requirements for an SF 1104 The specification for an SF 1106 o MUST specify an identifier for that SF. 1107 o MUST specify the rule for a node to decide when to add/delete one 1108 or more cells to a neighbor. 1109 o MUST specify the rule for a Transaction source to select cells to 1110 add to the CellList field in the 6P ADD Request. 1111 o MUST specify the rule for a Transaction destination to select 1112 cells from CellList to add to its schedule. 1113 o MUST specify a value for the 6P Timeout, or a rule/equation to 1114 calculate it. 1115 o MUST specify the rule for ordering cells. 1116 o MUST specify a meaning for the "Metadata" field in the 6P ADD 1117 Request. 1118 o MUST specify the behavior of a node when it boots. 1119 o MUST specify what to do after an error has occurred (either the 1120 node sent a 6P Response with an error code, or received one). 1121 o MUST specify the list of statistics to gather. An example 1122 statistic if the number of transmitted frames to each neighbor. 1123 In case the SF requires no statistics to be gathered, the specific 1124 of the SF MUST explicitly state so. 1126 o SHOULD clearly state the application domain the SF is created for. 1127 o SHOULD contain examples which highlight normal and error 1128 scenarios. 1129 o SHOULD contain a list of current implementations, at least during 1130 the I-D state of the document, per [RFC6982]. 1131 o SHOULD contain a performance evaluation of the scheme, possibly 1132 through references to external documents. 1134 o MAY redefine the format of the CellList field. 1135 o MAY redefine the format of the CellOptions field. 1136 o MAY redefine the meaning of the CellOptions field. 1138 5.3. Recommended Structure of an SF Specification 1140 The following section structure for a SF document is RECOMMENDED: 1142 o Introduction 1143 o Scheduling Function Identifier 1144 o Rules for Adding/Deleting Cells 1145 o Rules for CellList 1146 o 6P Timeout Value 1147 o Rule for Ordering Cells 1148 o Meaning of the Metadata Field 1149 o Node Behavior at Boot 1150 o 6P Error Handling 1151 o Examples 1152 o Implementation Status 1153 o Security Considerations 1154 o IANA Considerations 1156 6. Implementation Status 1158 This section records the status of known implementations of the 1159 protocol defined by this specification at the time of posting of this 1160 Internet-Draft, and is based on a proposal described in [RFC6982]. 1161 The description of implementations in this section is intended to 1162 assist the IETF in its decision processes in progressing drafts to 1163 RFCs. Please note that the listing of any individual implementation 1164 here does not imply endorsement by the IETF. Furthermore, no effort 1165 has been spent to verify the information presented here that was 1166 supplied by IETF contributors. This is not intended as, and must not 1167 be construed to be, a catalog of available implementations or their 1168 features. Readers are advised to note that other implementations may 1169 exist. 1171 According to [RFC6982], "this will allow reviewers and working groups 1172 to assign due consideration to documents that have the benefit of 1173 running code, which may serve as evidence of valuable experimentation 1174 and feedback that have made the implemented protocols more mature. 1175 It is up to the individual working groups to use this information as 1176 they see fit". 1178 ETSI 6TiSCH/6lo plugtests: 6P was one of the protocols addressed 1179 during the ETSI 6TiSCH #3 plugtests organized on 15-17 July 2016 1180 in Berlin, Germany. 15 entities participated in this event, 1181 verifying the compliance and interoperability of their 1182 implementation of 6P. This event happened under NDA, so neither 1183 the name of the entities nor the test results are public. This 1184 event is, however, a clear indication of the maturity of 6P, and 1185 the interest it generates. More information about the event at 1186 http://www.etsi.org/news-events/events/1077-6tisch-6lo-plugtests. 1187 ETSI 6TiSCH #2 plugtests: 6P was one of two protocols addressed 1188 during the ETSI 6TiSCH #2 plugtests organized on 2-4 February 2016 1189 in Paris, France. 14 entities participated in this event, 1190 verifying the compliance and interoperability of their 1191 implementation of 6P. This event happened under NDA, so neither 1192 the name of the entities nor the test results are public. This 1193 event is, however, a clear indication of the maturity of 6P, and 1194 the interest it generates. More information about the event at 1195 http://www.etsi.org/news-events/events/1022-6TiSCH-2-plugtests. 1196 OpenWSN: 6P is implemented in the OpenWSN project [OpenWSN] under a 1197 BSD open-source license. The authors of this document are 1198 collaborating with the OpenWSN community to gather feedback about 1199 the status and performance of the protocols described in this 1200 document. Results from that discussion will appear in this 1201 section in future revision of this specification. More 1202 information about this implementation at http://www.openwsn.org/. 1203 Wireshark Dissector: A Wireshark dissector for 6P is implemented 1204 under a BSD open-source license. It is developed and maintained 1205 at https://github.com/openwsn-berkeley/dissectors/, and regularly 1206 merged into the main Wireshark repository. Please see the 1207 Wireshark documentation to see what version of 6P it supports. 1209 7. Security Considerations 1211 6P messages are carried inside 802.15.4 Payload Information Elements 1212 (IEs). Those Payload IEs are encrypted and authenticated at the link 1213 layer through CCM*. 6P benefits from the same level of security as 1214 any other Payload IE. The 6P protocol does not define its own 1215 security mechanisms. A key management solution is out of scope for 1216 this document. The 6P protocol will benefit for the key management 1217 solution used in the network. 1219 8. IANA Considerations 1221 8.1. IETF IE Subtype '6P' 1223 This document adds the following number to the "IEEE Std 802.15.4 1224 IETF IE subtype IDs" registry defined by [I-D.kivinen-802-15-ie]: 1226 +--------------------+------+-----------+ 1227 | Subtype | Name | Reference | 1228 +--------------------+------+-----------+ 1229 | IANA_6TOP_SUBIE_ID | 6P | RFCXXXX | 1230 +--------------------+------+-----------+ 1232 Figure 23: IETF IE Subtype '6P'. 1234 8.2. 6TiSCH parameters sub-registries 1236 This section defines sub-registries within the "IPv6 over the TSCH 1237 mode of IEEE 802.15.4e (6TiSCH) parameters" registry, hereafter 1238 referred to as the "6TiSCH parameters" registry. Each sub-registry 1239 is described in a subsection. 1241 8.2.1. 6P Version Numbers 1243 The name of the sub-registry is "CoAP Version Numbers". 1245 A Note included in this registry should say: "In the 6top Protocol 1246 (6P) [RFCXXXX] there is a field to identify the version of the 1247 protocol. This field is 4 bits in size." 1249 Each entry in the sub-registry must include the Version in the range 1250 0-15, and a reference to the 6P version's documentation. 1252 The initial entry in this sub-registry is as follows: 1254 +---------+------------+ 1255 | Version | Reference | 1256 +---------+------------+ 1257 | 0 | RFCXXXX | 1258 +---------+------------+ 1260 Figure 24: 6P Version Numbers. 1262 All other Version Numbers are Unassigned. 1264 The IANA policy for future additions to this sub-registry is "IETF 1265 Review or IESG Approval" as described in [RFC5226]. 1267 8.2.2. 6P Message Types 1269 The name of the sub-registry is "6P Message Types". 1271 A Note included in this registry should say: "In the 6top Protocol 1272 (6P) version 0 [RFCXXXX], there is a field to identify the type of 1273 message. This field is 2 bits in size." 1274 Each entry in the sub-registry must include the Type in the range 1275 b00-b11, the corresponding Name, and a reference to the 6P message 1276 type's documentation. 1278 Initial entries in this sub-registry are as follows: 1280 +------+--------------+-----------+ 1281 | Type | Name | Reference | 1282 +------+--------------+-----------+ 1283 | b00 | REQUEST | RFCXXXX | 1284 | b01 | RESPONSE | RFCXXXX | 1285 | b10 | CONFIRMATION | RFCXXXX | 1286 +------+--------------+-----------+ 1288 Figure 25: 6P Message Types. 1290 All other Message Types are Reserved. 1292 The IANA policy for future additions to this sub-registry is "IETF 1293 Review or IESG Approval" as described in [RFC5226]. 1295 8.2.3. 6P Command Identifiers 1297 The name of the sub-registry is "6P Command Identifiers". 1299 A Note included in this registry should say: "In the 6top Protocol 1300 (6P) version 0 [RFCXXXX], there is a Code field which is 8 bits in 1301 size. In a 6P Request, the value of this Code field is used to 1302 identify the command." 1304 Each entry in the sub-registry must include the Identifier in the 1305 range 0-255, the corresponding Name, and a reference to the 6P 1306 command identifier's documentation. 1308 Initial entries in this sub-registry are as follows: 1310 +------------+------------+-----------+ 1311 | Identifier | Name | Reference | 1312 +------------+------------+-----------+ 1313 | 0 | Reserved | | 1314 | 1 | ADD | RFCXXXX | 1315 | 2 | DELETE | RFCXXXX | 1316 | 3 | RELOCATE | RFCXXXX | 1317 | 4 | COUNT | RFCXXXX | 1318 | 5 | LIST | RFCXXXX | 1319 | 6 | CLEAR | RFCXXXX | 1320 | 7-254 | Unassigned | | 1321 | 255 | Reserved | | 1322 +------------+------------+-----------+ 1324 Figure 26: 6P Command Identifiers. 1326 The IANA policy for future additions to this sub-registry is "IETF 1327 Review or IESG Approval" as described in [RFC5226]. 1329 8.2.4. 6P Return Codes 1331 The name of the sub-registry is "6P Return Codes". 1333 A Note included in this registry should say: "In the 6top Protocol 1334 (6P) version 0 [RFCXXXX], there is a Code field which is 8 bits in 1335 size. In a 6P Response or 6P Confirmation, the value of this Code 1336 field is used to identify the return code." 1338 Each entry in the sub-registry must include the Code in the range 1339 0-255, the corresponding Name, the corresponding Description, and a 1340 reference to the 6P return code's documentation. 1342 Initial entries in this sub-registry are as follows: 1344 +--------+-------------+---------------------------+-----------+ 1345 | Code | Name | Description | Reference | 1346 +--------+-------------+---------------------------+-----------+ 1347 | 0 | SUCCESS | operation succeeded | RFCXXXX | 1348 | 1 | ERROR | generic error | RFCXXXX | 1349 | 2 | EOL | end of list | RFCXXXX | 1350 | 3 | RESET | critical error, reset | RFCXXXX | 1351 | 4 | VERSION | unsupported 6P version | RFCXXXX | 1352 | 5 | SFID | unsupported SFID | RFCXXXX | 1353 | 6 | GEN | wrong schedule generation | RFCXXXX | 1354 | 7 | BUSY | busy | RFCXXXX | 1355 | 8 | NORES | not enough resources | RFCXXXX | 1356 | 9 | CELLLIST | cellList error | RFCXXXX | 1357 +--------+-------------+---------------------------+-----------+ 1359 Figure 27: 6P Return Codes. 1361 All other Message Types are Unassigned. 1363 The IANA policy for future additions to this sub-registry is "IETF 1364 Review or IESG Approval" as described in [RFC5226]. 1366 8.2.5. 6P Scheduling Function Identifiers 1368 6P Scheduling Function Identifiers. 1370 A Note included in this registry should say: "In the 6top Protocol 1371 (6P) version 0 [RFCXXXX], there is a field to identify the scheduling 1372 function to handle the message. This field is 8 bits in size." 1374 Each entry in the sub-registry must include the SFID in the range 1375 0-255, the corresponding Name, and a reference to the 6P Scheduling 1376 Function's documentation. 1378 The initial entry in this sub-registry is as follows: 1380 +-------+--------------------------+----------------------------+ 1381 | SFID | Name | Reference | 1382 +-------+--------------------------+----------------------------+ 1383 | 0 | Scheduling Function Zero | draft-ietf-6tisch-6top-sf0 | 1384 +-------+--------------------------+----------------------------+ 1386 Figure 28: SF Identifiers (SFID). 1388 All other Message Types are Unassigned. 1390 The IANA policy for future additions to this sub-registry depends on 1391 the value of the SFID, as defined in Figure 29. These specifications 1392 must follow the guidelines of Section 5. 1394 +-----------+------------------------------+ 1395 | Range | Registration Procedures | 1396 +-----------+------------------------------+ 1397 | 0-128 | IETF Review or IESG Approval | 1398 | 128-255 | Expert Review | 1399 +-----------+------------------------------+ 1401 Figure 29: SF Identifier (SFID): Registration Procedures. 1403 8.2.6. 6P CellOptions bitmap 1405 The name of the sub-registry is "6P CellOptions bitmap". 1407 A Note included in this registry should say: "In the 6top Protocol 1408 (6P) version 0 [RFCXXXX], there is an optional CellOptions field 1409 which is 8 bits in size." 1411 Each entry in the sub-registry must include the bit position in the 1412 range 0-7, the corresponding Name, and a reference to the bit's 1413 documentation. 1415 Initial entries in this sub-registry are as follows: 1417 +-----+---------------+-----------+ 1418 | bit | Name | Reference | 1419 +-----+---------------+-----------+ 1420 | 0 | TX (Transmit) | RFCXXXX | 1421 | 1 | RX (Receive) | RFCXXXX | 1422 | 2 | SHARED | RFCXXXX | 1423 | 3-7 | Reserved | | 1424 +-----+---------------+-----------+ 1426 Figure 30: 6P CellOptions bitmap. 1428 All other Message Types are Reserved. 1430 The IANA policy for future additions to this sub-registry is "IETF 1431 Review or IESG Approval" as described in [RFC5226]. 1433 9. References 1434 9.1. Normative References 1436 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1437 Requirement Levels", BCP 14, RFC 2119, 1438 DOI 10.17487/RFC2119, March 1997, 1439 . 1441 [I-D.kivinen-802-15-ie] 1442 Kivinen, T. and P. Kinney, "IEEE 802.15.4 Information 1443 Element for IETF", draft-kivinen-802-15-ie-06 (work in 1444 progress), March 2017. 1446 [IEEE802154-2015] 1447 IEEE standard for Information Technology, "IEEE Std 1448 802.15.4-2015 - IEEE Standard for Low-Rate Wireless 1449 Personal Area Networks (WPANs)", October 2015. 1451 9.2. Informative References 1453 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 1454 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 1455 Internet of Things (IoT): Problem Statement", RFC 7554, 1456 DOI 10.17487/RFC7554, May 2015, 1457 . 1459 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1460 Code: The Implementation Status Section", RFC 6982, 1461 DOI 10.17487/RFC6982, July 2013, 1462 . 1464 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1465 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1466 DOI 10.17487/RFC5226, May 2008, 1467 . 1469 [I-D.ietf-6tisch-minimal] 1470 Vilajosana, X., Pister, K., and T. Watteyne, "Minimal 1471 6TiSCH Configuration", draft-ietf-6tisch-minimal-21 (work 1472 in progress), February 2017. 1474 [OpenWSN] Watteyne, T., Vilajosana, X., Kerkez, B., Chraim, F., 1475 Weekly, K., Wang, Q., Glaser, S., and K. Pister, "OpenWSN: 1476 a Standards-Based Low-Power Wireless Development 1477 Environment", Transactions on Emerging Telecommunications 1478 Technologies , August 2012. 1480 Appendix A. [TEMPORARY] Changelog 1482 o draft-ietf-6tisch-6top-protocol-05 1484 * complete reorder of sections. Merged protocol behavior and 1485 command description 1486 * STATUS to COUNT 1487 * written-out IANA section 1488 * complete proof-read 1489 o draft-ietf-6tisch-6top-protocol-04 1491 * recommendation on which cells to use for 6P traffic 1492 * relocation format: added numberofCells field 1493 * created separate section about "cell suggestion" 1494 * Added RC_ERR_CELLLIST and RC_ERR_EOL error codes 1495 * Added example for two step with the failure 1496 * Recommended numbers in IANA section 1497 * single generation number 1498 * IEEE802.15.4 -> IEEE Std 802.15.4 or 802.15.4 1499 * complete proof-read 1500 o draft-ietf-6tisch-6top-protocol-03 1502 * Added a reference to [I-D.kivinen-802-15-ie]. 1503 * Added the Type field. 1504 * Editorial changes (figs, typos, ...) 1505 o draft-ietf-6tisch-6top-protocol-02 1507 * Rename COUNT to STATUS 1508 * Split LIST to LIST AB and LIST BA 1509 * Added generation counters and describing generation tracking of 1510 the schedule 1511 * Editorial changes (figs, typos, ...) 1512 o draft-ietf-6tisch-6top-protocol-01 1514 * Clarifying locking of resources in concurrent transactions 1515 * Clarifying return of RC_ERR_BUSY in case of concurrent 1516 transactions without enough resources 1517 o draft-ietf-6tisch-6top-protocol-00 1519 * Informational to Std track 1520 o draft-wang-6tisch-6top-protocol-00 1522 * Editorial overhaul: fixing typos, increasing readability, 1523 clarifying figures. 1524 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1525 issues/47 1526 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1527 issues/54 1529 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1530 issues/55 1531 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1532 issues/49 1533 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1534 issues/53 1535 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1536 issues/44 1537 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1538 issues/48 1539 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1540 issues/43 1541 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1542 issues/52 1543 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1544 issues/45 1545 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1546 issues/51 1547 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1548 issues/50 1549 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1550 issues/46 1551 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1552 issues/41 1553 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1554 issues/42 1555 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1556 issues/39 1557 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1558 issues/40 1559 o draft-wang-6tisch-6top-sublayer-05 1561 * Specifies format of IE 1562 * Adds token in messages to match request and response 1563 o draft-wang-6tisch-6top-sublayer-04 1565 * Renames IANA_6TOP_IE_GROUP_ID to IANA_IETF_IE_GROUP_ID. 1566 * Renames IANA_CMD and IANA_RC to IANA_6TOP_CMD and IANA_6TOP_RC. 1567 * Proposes IANA_6TOP_SUBIE_ID with value 0x00 for the 6top sub- 1568 IE. 1569 o draft-wang-6tisch-6top-sublayer-03 1571 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 1572 protocol/issues/32/missing-command-list 1573 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 1574 protocol/issues/31/missing-command-count 1575 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 1576 protocol/issues/30/missing-command-clear 1578 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1579 issues/37/6top-atomic-transaction-6p-transaction 1580 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 1581 protocol/issues/35/separate-opcode-from-rc 1582 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 1583 protocol/issues/36/add-length-field-in-ie 1584 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 1585 protocol/issues/27/differentiate-rc_err_busy-and 1586 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 1587 protocol/issues/29/missing-rc-rc_reset 1588 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 1589 protocol/issues/28/the-sf-must-specify-the-behavior-of-a-mote 1590 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 1591 protocol/issues/26/remove-including-their-number 1592 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top-protocol/ 1593 issues/34/6of-sf 1594 * https://bitbucket.org/6tisch/draft-wang-6tisch-6top- 1595 protocol/issues/33/add-a-figure-showing-the-negociation 1596 o draft-wang-6tisch-6top-sublayer-02 1598 * introduces the 6P protocol and the notion of 6top Transaction. 1599 * introduces the concept of 6OF and its 6OFID. 1601 Authors' Addresses 1603 Qin Wang (editor) 1604 Univ. of Sci. and Tech. Beijing 1605 30 Xueyuan Road 1606 Beijing, Hebei 100083 1607 China 1609 Email: wangqin@ies.ustb.edu.cn 1611 Xavier Vilajosana 1612 Universitat Oberta de Catalunya 1613 156 Rambla Poblenou 1614 Barcelona, Catalonia 08018 1615 Spain 1617 Email: xvilajosana@uoc.edu 1618 Thomas Watteyne 1619 Analog Devices 1620 32990 Alvarado-Niles Road, Suite 910 1621 Union City, CA 94587 1622 USA 1624 Email: twatteyne@linear.com