idnits 2.17.1 draft-wang-6tisch-6top-sublayer-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 9, 2015) is 3115 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TEMPORARY' is mentioned on line 626, but not defined == Unused Reference: 'IEEE802154' is defined on line 559, but no explicit reference was found in the text == Unused Reference: 'RFC7554' is defined on line 567, but no explicit reference was found in the text == Unused Reference: 'OpenWSN' is defined on line 584, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-6tisch-minimal-12 == Outdated reference: A later version (-10) exists of draft-ietf-6tisch-terminology-05 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6TiSCH Q. Wang, Ed. 3 Internet-Draft Univ. of Sci. and Tech. Beijing 4 Intended status: Informational X. Vilajosana 5 Expires: April 11, 2016 Universitat Oberta de Catalunya 6 October 9, 2015 8 6TiSCH Operation Sublayer (6top) 9 draft-wang-6tisch-6top-sublayer-02 11 Abstract 13 This document defines the 6TiSCH Operation Sublayer (6top), which 14 offers mechanisms for distributed scheduling in 6TiSCH networks. The 15 6top sublayer is the next higher layer of the IEEE802.15.4e TSCH 16 medium access control layer. The 6top Protocol (6P) defined in this 17 document allows neighbor nodes to add/delete TSCH cells to one 18 another. To be able to match different application requirements, the 19 algorithm of when to add/delete cells, called the 6top Objective 20 Function (6OF), is left out of scope, and will be specified in one of 21 more companion documents. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 27 "OPTIONAL" in this document are to be interpreted as described in RFC 28 2119 [RFC2119]. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on April 11, 2016. 47 Copyright Notice 49 Copyright (c) 2015 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. 6TiSCH Operation Sublayer (6top) . . . . . . . . . . . . . . 4 66 2.1. Hard/Soft Cells . . . . . . . . . . . . . . . . . . . . . 4 67 2.2. 6top and minimal . . . . . . . . . . . . . . . . . . . . 4 68 3. 6top Protocol (6P) . . . . . . . . . . . . . . . . . . . . . 5 69 3.1. Message Format . . . . . . . . . . . . . . . . . . . . . 6 70 3.1.1. 6top Information Element . . . . . . . . . . . . . . 6 71 3.1.2. General Message Format . . . . . . . . . . . . . . . 6 72 3.1.3. 6P OpCode . . . . . . . . . . . . . . . . . . . . . . 6 73 3.1.4. 6P Cell Format . . . . . . . . . . . . . . . . . . . 7 74 3.1.5. 6P ADD Request Format . . . . . . . . . . . . . . . . 7 75 3.1.6. 6P DELETE Request Format . . . . . . . . . . . . . . 8 76 3.1.7. 6P Response Format . . . . . . . . . . . . . . . . . 8 77 3.2. Protocol Behavior . . . . . . . . . . . . . . . . . . . . 8 78 3.2.1. Version Checking . . . . . . . . . . . . . . . . . . 8 79 3.2.2. 6OFID Checking . . . . . . . . . . . . . . . . . . . 9 80 3.2.3. Concurrent Atomic Transactions . . . . . . . . . . . 9 81 3.2.4. Timeout . . . . . . . . . . . . . . . . . . . . . . . 9 82 3.2.5. Adding cells . . . . . . . . . . . . . . . . . . . . 9 83 3.2.6. Deleting cells . . . . . . . . . . . . . . . . . . . 10 84 3.2.7. Handling error responses . . . . . . . . . . . . . . 10 85 3.3. Security . . . . . . . . . . . . . . . . . . . . . . . . 11 86 4. Guidelines for 6top Objective Functions (6OF) . . . . . . . . 11 87 4.1. 6OF Identifier (6OFID) . . . . . . . . . . . . . . . . . 11 88 4.2. Requirements for a 6OF . . . . . . . . . . . . . . . . . 11 89 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 90 6. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 12 91 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 92 7.1. Normative References . . . . . . . . . . . . . . . . . . 12 93 7.2. Informative References . . . . . . . . . . . . . . . . . 13 94 Appendix A. [TEMPORARY] IEEE Liaison Considerations . . . . . . 13 95 Appendix B. [TEMPORARY] Terms for the Terminology Draft . . . . 13 96 Appendix C. [TEMPORARY] Changelog . . . . . . . . . . . . . . . 14 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 99 1. Introduction 101 All communication in a 6TiSCH network is orchestrated by a schedule. 102 This specification defines the mechanisms offered by the 6TiSCH 103 Operation Sublayer (6top) sublayer. These mechanisms allow a node to 104 communicate with its neighbor node(s) to agree on a TSCH schedule in 105 a distributed manner. 107 (A) 108 / \ 109 / \ 110 (B)-----(C) 111 | | 112 | | 113 (D) (E) 115 Figure 1: A simple 6TiSCH network. 117 For example, node C in Figure 1 monitors the communication cells to 118 node A it has in its schedule. 120 o If node C determines the number of frames it is sending to A per 121 unit of time is larger than the capacity offered by the TSCH cells 122 it has scheduled to A, it communicates with node A to add one or 123 more cells. 124 o If node C determines collisions are happening on a particular cell 125 to node A, it communicates with node A to add a new cell and 126 delete the cell which suffered from collisions. This results, 127 conceptually, in "relocating" the cell which suffered from 128 collisions to a different slotOffset/channelOffset location in the 129 TSCH schedule. 130 o If the traffic is lower than the capacity, node C communicates 131 with node A to delete one or more cells to A. 133 This results in a distributed schedule management solution. 135 The mechanisms needed to enable this interaction are defined by the 136 6TiSCH Operation Sublayer (6top) sublayer, described in Section 2. 137 The 6top Protocol (6P), specified in Section 3, defines the 138 communication between neighbor nodes in this context. The 6top 139 sublayer includes a 6top Objective Function (6OF) which defines 140 policy of when to add/delete a cell to a neighbor. Different 141 applications require different 6OFs, so the 6OF is left out of scope 142 of this document. One of more 6OFs will be defined in one of more 143 companion documents. Section 4 provides some guidelines on how to 144 design a 6OF. 146 2. 6TiSCH Operation Sublayer (6top) 148 As depicted in Figure 2, the 6TiSCH Operation Sublayer (6top) sits 149 directly above the IEEE802.15.4e TSCH medium access control layer 150 [IEEE802154e]. 152 . 153 | . | 154 | next higher layer | 155 +------------------------------------------+ 156 | 6top | 157 +------------------------------------------+ 158 | IEEE802.15.4e TSCH | 159 | . | 160 . 162 Figure 2: The 6top sublayer in the protocol stack. 164 The roles of the 6top sublayer are: 166 o Implement and terminate the 6top Protocol (6P), which allows 167 neighbor nodes to communicate to add/delete cells to one another. 168 o Run a 6top Objective Function (6OF) which defines the algorithm to 169 decide when to add/delete cells. 170 o Offer a way for a neighbor node to discover which 6OF is being 171 used. 173 2.1. Hard/Soft Cells 175 6top qualifies each cell in the schedule as either "hard" or "soft": 177 o Soft Cell: can be read, added, deleted or updated by 6top. 178 o Hard Cell: is read-only by 6top. 180 In the context of this specification, all cells are soft. Hard cells 181 can be used for example when "hard-coding" a cell (e.g. the 6TiSCH 182 Configuration [I-D.ietf-6tisch-minimal]). 184 2.2. 6top and minimal 186 6top MAY be used alongside the Minimal 6TiSCH Configuration 187 [I-D.ietf-6tisch-minimal]. In this case, it is RECOMMENDED to use 2 188 slotframes, as depicted in Figure 3: 190 o Slotframe 0 (SF0) is used for traffic defined in the Minimal 191 6TiSCH Configuration. In Figure 3, this slotframe is 5 slots 192 long, but it can be of any length. 193 o Slotframe 1 (SF1) is used by 6top to allocate cells from. In 194 Figure 3, this slotframe is 10 slots long, but it can be of any 195 length. 197 . 199 SF0 SHOULD be of higher priority than SF1. 6top MAY support further 200 slotframes; how to use more slotframes is out of the scope for this 201 document. 203 | 0 1 2 3 4 | 0 1 2 3 4 | 204 +------------------------+------------------------+ 205 SF0 | EB | | | | | EB | | | | | 206 | | | | | | | | | | | 207 --------------------------------------------------- 208 SF1 | |A->B| | | | | | |B->A| | 209 | | | | | | | | | | | 210 +-------------------------------------------------+ 211 | 0 1 2 3 4 5 6 7 8 9 | 213 Figure 3: 2-slotframe structure when using 6top alongside the Minimal 214 6TiSCH Configuration. 216 3. 6top Protocol (6P) 218 The 6top Protocol (6P) allows two neighbor nodes to pass information 219 to add/delete cells to their TSCH schedule. This information is 220 carried as IEEE802.15.4 Information Elements (IE) [IEEE802154e] and 221 travels only a single hop. 223 Conceptually, two neighbor nodes "negotiate" the location of the 224 cells to add/delete. We reuse the topology in Figure 1 to illustrate 225 how the protocol works. 227 When node A wants to add (resp. delete) 2 cells to/from node B: 229 1. Node A sends a message to node B indicating it wants to add 230 (resp. delete) 2 cells to/from node B to its schedule, and 231 listing 2 or more candidate cells. 232 2. Node B responds with a message indicating that the operation 233 succeeded, and specifying which cells from the candidate list it 234 added (resp. deleted). This allows node A to add (resp. delte) 235 the same cells to/from its schedule. 237 We call "6top Atomic Transaction" the action of two neighbor nodes 238 exchanging a 6P Request Message and the corresponding 6P Reply 239 message. 241 3.1. Message Format 243 3.1.1. 6top Information Element 245 The messages exchanges as part of the 6P protocol are carried in a 246 6top Information Element. The 6top Information Element is Payload IE 247 with Group ID IANA_6TOP_IE_GROUP_ID. The length of the 6top 248 Information Element is Variable. The content of the 6top Information 249 Element is specified in Section 3.1. 251 3.1.2. General Message Format 253 All 6P messages have the following format: 255 1 2 3 256 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 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Ver |OpCode | 6OFID | Other Fields 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 Ver (6P Version): The version of the 6P protocol. Only version 262 IANA_6P_VERSION is defined in this document. Future 263 specification might define further version of the 6P protocol. 264 OpCode (6P OpCode): Operation to carry out, or the response code. 265 The list of OpCode values is defined only for version 266 IANA_6P_VERSION in this document. 267 6OFID (6top Objective Function Identifier): The identifier of the 268 6OF to use to handle this message. The 6OFID is defined in 269 Section 4.1. 270 Other Fields: The list of other fields depends on the value of the 271 OpCode, as detailed below. 273 3.1.3. 6P OpCode 275 Figure 4 lists the possible OpCode values. 277 Value OpCode RC Description 278 +-------------------+--------------+---+----------------------------+ 279 | IANA_ADD | ADD | N | add one or more cells | 280 +-------------------+-----------------------------------------------+ 281 | IANA_DELETE | DELETE | N | delete one or more cells | 282 +-------------------+-----------------------------------------------+ 283 | IANA_RC_SUCCESS | RC_SUCCESS | Y | operation succeeded | 284 +-------------------+-----------------------------------------------+ 285 | IANA_RC_ERR_VER | RC_ERR_VER | Y | unsupported 6P version | 286 +-------------------+-----------------------------------------------+ 287 | IANA_RC_ERR_6OFID | RC_ERR_6OFID | Y | unsupported 6OFID | 288 +-------------------+-----------------------------------------------+ 289 | IANA_RC_ERR_BUSY | RC_ERR_BUSY | Y | the node is busy | 290 +-------------------+-----------------------------------------------+ 291 | IANA_RC_ERR | RC_ERR | Y | operation failed | 292 +-------------------+-----------------------------------------------+ 293 | TODO-0xf | reserved | 294 +-------------------+-----------------------------------------------+ 296 Figure 4: 6P OpCodes. (RC is return code) 298 3.1.4. 6P Cell Format 300 The 6P Cell is an element which is present in several messages. It 301 is a 4-byte field formatted as: 303 1 2 3 304 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 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | slotOffset | channelOffset | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 slotOffset: The slot offset of the cell. 310 channelOffset: The channel offset of the cell. 312 3.1.5. 6P ADD Request Format 314 1 2 3 315 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 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Ver |OpCode | 6OFID | NumCells | Container | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | CellList ... 320 +-+-+-+-+-+-+- 322 Ver: Set to IANA_6P_VERSION. 323 OpCode: Set to IANA_ADD for a 6P ADD Request. 325 6OFID: Identifier of the 6OF to be used by the receiver to handle 326 the message. 327 NumCells: The number of additional TX cells the sender wants to 328 schedule to the receiver. 329 Container: An indication of where in the schedule to take the cells 330 from (which slotframe, which chunk, etc.). This value is an 331 indication to the 6OF. The meaning of this field depends on 332 the 6OF, and is hence out of scope of this document. 333 CellList: A list of 0, 1 of multiple 6P Cells. The format of a 6P 334 Cell is defined in Section 3.1.4 336 3.1.6. 6P DELETE Request Format 338 The 6P DELETE Request has the exact same format as the 6P ADD 339 Request, except for the OpCode which is set to IANA_DELETE. 341 3.1.7. 6P Response Format 343 1 2 3 344 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 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | Ver |OpCode | 6OFID | CellList ... 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 Ver: Set to IANA_6P_VERSION. 350 6OFID: Identifier of the 6OF to be used by the receiver to handle 351 the message. 352 OpCode: One of the "return code" OpCodes listed in Section 3.1.3. 353 CellList: A list of 0, 1 of multiple 6P Cells. The format of a 6P 354 Cell is defined in Section 3.1.4. 356 3.2. Protocol Behavior 358 For illustration, we assume we use the topology in Figure 1, and that 359 node A negotiates to add/delete cells to node B. 361 3.2.1. Version Checking 363 All messages contain a Version field. If multiple Versions of the 6P 364 protocol have been defined (in future specifications for Version 365 values different than IANA_6P_VERSION), a node MAY implement multiple 366 protocol versions at the same time. When receiving a 6P message with 367 a Version number it does not implement, a node MUST reply with a 6P 368 Response and a return code of IANA_RC_ERR_VER. The Version field in 369 the 6P Response MUST be the same as the Version field in the 370 corresponding 6P Request. 372 3.2.2. 6OFID Checking 374 All messages contain a 6OFID field. If multiple 6OFs has been 375 defined, a node MAY support multiple 6OFs at the same time. When 376 receiving a 6P message with an unsupported 6OFID, a node MUST reply 377 with a 6P Response and a return code of IANA_RC_ERR_6OFID. The 378 Version field in the 6P Response MUST be the same as the Version 379 field in the corresponding 6P Request. 381 3.2.3. Concurrent Atomic Transactions 383 Only a single 6P Atomic Transaction between two neighbors, in a given 384 direction, can take place at the same time. That is, a node MUST NOT 385 issue a new 6P Request to a given neighbor before having received the 386 6P Response for a previous request to that neighbor. The only 387 exception to this rule is when the previous Atomic Transaction has 388 timed out. If a node receives a 6P Request from a given neighbor 389 before having sent the 6P Response to the previous 6P Request from 390 that neighbor, it MUST send back a 6P Response with a return code of 391 IANA_RC_ERR. 393 A node MAY support concurrent Atomic Transactions from different 394 neighbors. In this case, in Figure 1, node C can have a different 395 ongoing Atomic Transaction with nodes B and E. In case a node does 396 not have enough resources to handle concurrent Atomic Transactions 397 from different neighbors, when it receives a 6P Request from a 398 neighbor while already handling a different request from a different 399 neighbor, it MUST reply to that second request with a 6P Response 400 with return code IANA_RC_ERR_BUSY. 402 3.2.4. Timeout 404 A timeout happens when the node sending the 6P Request has not 405 received the 6P Response. The value of the timeout is coupled with 406 how the cells between the nodes are scheduled. The 6OF determines 407 the value of the timeout. The value of the timeout is out of scope 408 of this document. 410 3.2.5. Adding cells 412 We assume the topology in Figure 1 where the 6OF on node C decides to 413 add NumCell cells to node A. 415 Node C's 6OF selects NumCandidate>=NumCell cells from its schedule as 416 candidate transmit cells to node A. NumCandidate MUST be larger or 417 equal to NumCell. How many cells it selects (NumCandidate) and how 418 that selection is done is specified in the 6OF and out of scope of 419 this document. Node C sends a 6P ADD Request to node A which 420 contains the value of NumCells and the NumCandidate cells in the 421 CellList. 423 Upon receiving the request, node A's 6OF verifies which of the cells 424 in the CellList it can add as receive cells from node C in its own 425 schedule. How that selection is done is specified in the 6OF and out 426 of scope of this document. That verification can succeed (NumCell 427 cells from the CellList can be used), fail (none of the cells from 428 the CellList can be used) or partially succeed (less than NumCell 429 cells from the CellList can be used). In all cases, node A MUST send 430 a 6P Response with return code set to IANA_RC_SUCCESS, and which 431 specifies the list of cells that were scheduled as receive cells from 432 C. That can contain 0 elements (when the verification failed), 433 NumCell elements (succeeded) or between 0 and NumCell elements 434 (partially succeeded). 436 Upon receiving the response, node C adds the cells specified in the 437 CellList as transmit cells to node A. 439 3.2.6. Deleting cells 441 The behavior for deleting cells is equivalent to that of adding cells 442 except that: 444 o The nodes delete the cells they agree upon rather than adding 445 them. 446 o All cells in the CellList MUST be already scheduled between the 447 two nodes. 448 o If the CellList in the 6P Request is empty, the 6OF on the 449 receiving node is free to delete any cell from the sender. 450 o The CellList MUST either be equal, contain exactly NumCell cells, 451 or more than NumCell cells. The case where the CellList is not 452 empty but contains less than NumCell cells is not supported. 454 3.2.7. Handling error responses 456 A return code with a name starts with "RC_ERR" in Figure 4 indicates 457 an error. When a node receives a 6P Response with such an error, it 458 MUST consider the Atomic Transaction has failed. In particular, if 459 this was a response to a 6P ADD/DELETE Request, the node MUST NOT 460 add/delete any of the cells involved in this Atomic Transaction. 461 Similarly, a node sending a 6P Response with an "RC_ERR" return code 462 MUST NOT add/delete any cells as part of that Atomic Transaction. 463 The 6OF defines what to do after an error has occurred. Defining 464 what to do after an error has occurred is out of scope of this 465 document. 467 3.3. Security 469 6P messages are secured through link-layer security. When link-layer 470 security is enabled, the 6P messages MUST be secured. This is 471 possible because 6P messages are carried as Payload IE. 473 4. Guidelines for 6top Objective Functions (6OF) 475 4.1. 6OF Identifier (6OFID) 477 Each 6OF has an identifier. The identifier is encoded as a 1-byte 478 field. The identifier space is divided in the following ranges. 480 Range Meaning 481 +-----------+-------------+ 482 | 0x00 | reserved | 483 +-----------+-------------- 484 | 0x01-0x7f | managed | 485 +-----------+-------------- 486 | 0x80-0xfe | unmanaged | 487 +-----------+-------------+ 488 | 0xff | reserved | 489 +-----------+-------------+ 491 Figure 5: 6OFID range. 493 6OF identifiers in the managed space MUST be managed by IANA. 495 4.2. Requirements for a 6OF 497 The specification for a 6OF 499 o MUST specify an identifier for that 6OF. 500 o MUST specify a set of rules for a node to decide when to add one 501 or more cells to a neighbor. 502 o MUST specify a set of rules for a node to decide when to delete 503 one or more cells to a neighbor. 504 o MUST specify a value for the timeout, or a rule to calculate it. 505 o MUST specify a meaning for the "Container" field in the 6P ADD 506 Request. 507 o MUST specify the rule for selecting the cells (including their 508 number) to add to the CellList field in the 6P ADD Request. 509 o MUST specify the rule for verifying which cells from the CellList 510 it can add to it schedule. 511 o MUST specify what to do after an error has occurred (either the 512 node sent a 6P Response with an error code, or received one). 513 o SHOULD clearly state the application domain the 6OF is created 514 for. 516 o SHOULD contain examples which highlight normal and error 517 scenarios. 518 o SHOULD contain a performance evaluation of the scheme, possibly 519 through references to external documents. 521 5. Security Considerations 523 TODO: analyze risks 525 6P messages are carried inside IEEE802.15.4 Payload Information 526 Elements (IEs). Those Payload IEs are encrypted and authenticated at 527 the link layer through CCM*. 6P benefits from the same level of 528 security as any other Payload IE. The 6P protocol does not define 529 its own security mechanisms. A key management solution is out of 530 scope for this document. The 6P protocol will benefit for the key 531 management solution used in the network. 533 6. IANA Consideration 535 o TODO: IANA_6TOP_IE_GROUP_ID 536 o TODO: IANA_6P_VERSION 537 o TODO: IANA_ADD 538 o TODO: IANA_DELETE 539 o TODO: IANA_RC_SUCCESS 540 o TODO: IANA_RC_ERR_VER 541 o TODO: IANA_RC_ERR_BUSY 542 o TODO: IANA_RC_ERR 544 7. References 546 7.1. Normative References 548 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 549 Requirement Levels", BCP 14, RFC 2119, 550 DOI 10.17487/RFC2119, March 1997, 551 . 553 [IEEE802154e] 554 IEEE standard for Information Technology, "IEEE std. 555 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 556 Networks (LR-WPANs) Amendment 1: MAC sublayer", April 557 2012. 559 [IEEE802154] 560 IEEE standard for Information Technology, "IEEE std. 561 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 562 and Physical Layer (PHY) Specifications for Low-Rate 563 Wireless Personal Area Networks", June 2011. 565 7.2. Informative References 567 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 568 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 569 Internet of Things (IoT): Problem Statement", RFC 7554, 570 DOI 10.17487/RFC7554, May 2015, 571 . 573 [I-D.ietf-6tisch-minimal] 574 Vilajosana, X. and K. Pister, "Minimal 6TiSCH 575 Configuration", draft-ietf-6tisch-minimal-12 (work in 576 progress), September 2015. 578 [I-D.ietf-6tisch-terminology] 579 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 580 "Terminology in IPv6 over the TSCH mode of IEEE 581 802.15.4e", draft-ietf-6tisch-terminology-05 (work in 582 progress), July 2015. 584 [OpenWSN] Watteyne, T., Vilajosana, X., Kerkez, B., Chraim, F., 585 Weekly, K., Wang, Q., Glaser, S., and K. Pister, "OpenWSN: 586 a Standards-Based Low-Power Wireless Development 587 Environment", Transactions on Emerging Telecommunications 588 Technologies , August 2012. 590 Appendix A. [TEMPORARY] IEEE Liaison Considerations 592 The 6P messages are carried into a single IEEE802.15.4 Payload 593 Information Element. We need a mechanism to discriminate 6P messages 594 from other IEs. In the text, we assume a Payload IE Group ID 595 (IANA_6TOP_IE_GROUP_ID) assigned. Another option would be for the 596 IEEE to assign a Payload IE Group ID to the IETF, and for 6TiSCH to 597 coordinate the creation of a IANA entry for subIEs. 599 Appendix B. [TEMPORARY] Terms for the Terminology Draft 601 Terms introduced by this document, and which needs to be added to 602 [I-D.ietf-6tisch-terminology]: 604 6top: The "6TiSCH Operation Sublayer", which the next highest 605 layer of the IEEE802.15.4e TSCH medium access control 606 layer. It implements and terminates the "6top Protocol" 607 (6P), and contains a "6top Objective Function" (6OF). It 608 is defined in LINK_draft-wang-6tisch-6top-sublayer. 609 6OF: The "6top Objective Function", the policy inside the 610 "6TiSCH Operation Sublayer" (6top) which decides when to 611 add/remove cells. It is defined in LINK_draft-wang- 612 6tisch-6top-sublayer. 614 6OFID: The "6top Objective Function Identifier", a 4-bit field 615 identifying a 6OF. It is defined in LINK_draft-wang- 616 6tisch-6top-sublayer. 617 6P: The "6top Protocol", which allows neighbor nodes to 618 communicate to add/delete cells to one another in their 619 TSCH schedule. It is defined in LINK_draft-wang-6tisch- 620 6top-sublayer. 621 6top Atomic Transaction: Part of the "6top Protocol" (6P), the 622 action of two neighbors exchanging a 6P request message 623 and the corresponding 6P response message. It is defined 624 in LINK_draft-wang-6tisch-6top-sublayer. 626 Appendix C. [TEMPORARY] Changelog 628 o -02 630 * introduces the 6P protocol and the notion of 6top Atomic 631 Transaction. 632 * introduces the concept of 6OF and its 6OFID. 634 Authors' Addresses 636 Qin Wang (editor) 637 Univ. of Sci. and Tech. Beijing 638 30 Xueyuan Road 639 Beijing, Hebei 100083 640 China 642 Phone: +86 (10) 6233 4781 643 Email: wangqin@ies.ustb.edu.cn 645 Xavier Vilajosana 646 Universitat Oberta de Catalunya 647 156 Rambla Poblenou 648 Barcelona, Catalonia 08018 649 Spain 651 Phone: +34 (646) 633 681 652 Email: xvilajosana@uoc.edu