idnits 2.17.1 draft-duquennoy-6tisch-asf-01.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 1, 2018) is 2247 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'TEMPORARY' is mentioned on line 578, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802154-2015' == Outdated reference: A later version (-12) exists of draft-ietf-6tisch-6top-protocol-09 == Outdated reference: A later version (-10) exists of draft-ietf-6tisch-terminology-09 -- Obsolete informational reference (is this intentional?): RFC 6982 (Obsoleted by RFC 7942) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6TiSCH S. Duquennoy, Ed. 3 Internet-Draft RISE SICS 4 Intended status: Standards Track X. Vilajosana 5 Expires: September 2, 2018 Universitat Oberta de Catalunya 6 T. Watteyne 7 Inria 8 March 1, 2018 10 6TiSCH Autonomous Scheduling Function (ASF) 11 draft-duquennoy-6tisch-asf-01 13 Abstract 15 This document defines a Scheduling Function called "ASF": the 6TiSCH 16 Autonomous Scheduling Function. With ASF, nodes maintain their TSCH 17 schedule based on local neighborhood knowledge, without any signaling 18 after association. Hashes of the nodes' MAC address are used to 19 deterministically derive the [slotOffset,channelOffset] location of 20 cells in the TSCH schedule. Different traffic types (e.g. TSCH EB, 21 RPL DIO, UDP etc.) are assigned to distinct slotframes, for isolation 22 and flexible dimensioning. This approach provides over-provisioned 23 schedules with low maintenance, in pursuit for simplicity rather than 24 optimality. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 30 "OPTIONAL" in this document are to be interpreted as described in RFC 31 2119 [RFC2119]. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on September 2, 2018. 50 Copyright Notice 52 Copyright (c) 2018 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2.1. Application Domains . . . . . . . . . . . . . . . . . . . 3 70 3. General Operation . . . . . . . . . . . . . . . . . . . . . . 4 71 3.1. Cell Coordinates . . . . . . . . . . . . . . . . . . . . 4 72 3.2. Types of Slotframes . . . . . . . . . . . . . . . . . . . 4 73 3.2.1. Rendez-vous slotframe . . . . . . . . . . . . . . . . 4 74 3.2.2. Receiver-based slotframe . . . . . . . . . . . . . . 4 75 3.2.3. Sender-based slotframe . . . . . . . . . . . . . . . 5 76 3.3. Conditional Cells . . . . . . . . . . . . . . . . . . . . 5 77 3.4. Interaction between Slotframes . . . . . . . . . . . . . 5 78 4. Configuration . . . . . . . . . . . . . . . . . . . . . . . . 6 79 5. Scheduling Function Identifier . . . . . . . . . . . . . . . 9 80 6. Rules for Adding/Deleting Cells . . . . . . . . . . . . . . . 9 81 7. Rules for CellList . . . . . . . . . . . . . . . . . . . . . 9 82 8. 6P Timeout Value . . . . . . . . . . . . . . . . . . . . . . 10 83 9. Rule for Ordering Cells . . . . . . . . . . . . . . . . . . . 10 84 10. Meaning of the Metadata Field . . . . . . . . . . . . . . . . 10 85 11. Node Behavior at Boot . . . . . . . . . . . . . . . . . . . . 10 86 12. 6P Error Handling . . . . . . . . . . . . . . . . . . . . . . 10 87 13. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11 88 14. [TEMPORARY] Implementation Status . . . . . . . . . . . . . . 11 89 15. Security Considerations . . . . . . . . . . . . . . . . . . . 11 90 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 91 16.1. 6P Scheduling Function Identifiers 'ASF' . . . . . . . . 12 92 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 93 17.1. Normative References . . . . . . . . . . . . . . . . . . 12 94 17.2. Informative References . . . . . . . . . . . . . . . . . 12 95 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 13 96 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 13 97 Appendix C. [TEMPORARY] Changelog . . . . . . . . . . . . . . . 13 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 100 1. TEMPORARY EDITORIAL NOTES 102 This document is an Internet Draft, so work-in-progress by nature. 103 It contains the following work-in-progress elements: 105 o "TODO" statements are elements which have not yet been written by 106 the authors for some reason (lack of time, ongoing discussions 107 with no clear consensus, etc). The statement does indicate that 108 the text will be written at some point. 109 o "TEMPORARY" appendices are there to capture current ongoing 110 discussions, or the changelog of the document. These appendices 111 will be removed in the final text. 112 o "IANA_*" identifiers are placeholders for numbers assigned by 113 IANA. These placeholders are to be replaced by the actual values 114 they represent after their assignment by IANA. 115 o "RFCXXXX" refers to the RFC number of this specification, once 116 published. 117 o The string "REMARK" is put before a remark (questions, suggestion, 118 etc) from an author, editor or contributor. These are on-going 119 discussions at the time of writing, and will not be part of the 120 final text. 121 o This section will be removed in the final text. 123 2. Introduction 125 This document defines an autonomous Scheduling Function for the 6top 126 sublayer [I-D.ietf-6tisch-6top-protocol], called "ASF". It is 127 designed to operate without any runtime signaling, keeping the TSCH 128 schedule consistent between neighbors at all times (slots for 129 transmission and reception always match). ASF uses 6P solely for 130 configuration at association time (6P SIGNAL) and for schedule 131 inspection (6P STATUS and LIST). ASF isolates different traffic 132 types into distinct slotframes, so as to avoid any disruption between 133 MAC synchronization, control and application traffic. 135 ASF addresses all requirements listed in Section "Requirements for an 136 SF" from [I-D.ietf-6tisch-6top-protocol]. The organization of this 137 document follows section "Recommended Structure of an SF 138 Specification" in [I-D.ietf-6tisch-6top-protocol]. This document 139 follows the terminology defined in [I-D.ietf-6tisch-terminology]. 141 2.1. Application Domains 143 ASF is primarily targeted at applications with random traffic flows, 144 such as interactive CoAP traffic. Its main strength is its 145 signaling-free nature, which ensures the slots installed at 146 neighboring nodes are consistent at all times. Its main weakness is 147 its contention-based nature and its need to over-provision the 148 schedule, rendering it unable to meet stringent latency and energy 149 requirements. An example application domains is building 150 instrumentation. ASF was evaluated experimentally and shown to 151 achieve over 99.99% end-to-end delivery in 6TiSCH/RPL testbeds 152 [Orchestra-SenSys]. 154 3. General Operation 156 ASF uses multiple slotframes, each assigned to one particular type of 157 traffic, e.g. TSCH EBs, RPL or UDP traffic. Nodes maintain the 158 cells within the slotframes autonomously, based on the hash of either 159 the source's or destination's MAC address. Each slotframe is 160 uniquely assigned a set of channel offsets. 162 3.1. Cell Coordinates 164 Cell coordinates in ASF are either fixed or derived from a MAC 165 address (depending on the slotframe type, see Section 3.2). To 166 derive coordinates from a MAC (EUI-64) address, nodes MUST use the 167 hash function provided at configuration time, see Section 4. One 168 example hash function is SAX [SAX-DASFAA]. Let S_len be the length 169 of slotframe S, and S_channels be the set of channels assigned to 170 slotframe S. The slot coordinates derived from a given MAC address 171 are computed as follows: 173 slotOffset(MAC) = hash(MAC) % S_len 174 channelOffset(MAC) = S_channels[(hash(MAC) / L) % len(S_channels)] 176 3.2. Types of Slotframes 178 There are three different types of slotframes, described next. 179 Section 4 provides full details on cell options and other aspects. 181 3.2.1. Rendez-vous slotframe 183 Contains a single contention-based rendez-vous cell, at coordinates 184 [slot offset: 0; channel offset: 0]. This slotframe is equivalent to 185 the 6TiSCH minimal schedule [RFC8180]. 187 3.2.2. Receiver-based slotframe 189 One Rx cell: Coordinates computed as the hash of the node's own MAC 190 address. 191 Multiple Tx cells: One Tx cell per neighbor. Coordinates computed 192 as the hash of the neighbor's MAC address. 194 3.2.3. Sender-based slotframe 196 One Tx cell: Coordinates computed as the hash of the node's own MAC 197 address. 198 Multiple Rx cells: One Rx cell per neighbor. Coordinates computed 199 as the hash of the neighbor's MAC address. 201 3.3. Conditional Cells 203 In order to handle traffic bursts, ASF utilizes conditional cells. 204 When a node has several frames in its queue for a given neighbor, it 205 can set the [IEEE802154-2015] 'frame pending' bit in unicast 206 transmissions to that neighbor. Cells at upcoming time offsets will 207 be used to carry more frames. Note that collisions may happen on 208 these conditional cells, which MUST therefore have the 'Shared' bit 209 set. 211 Sender: A sender with multiple unicast frames in its queue for a 212 given neighbor MAY send frames with the 'frame pending' bit set. 213 After sending a unicast frame with the 'frame pending' bit set, if 214 a link-layer Acknowledgment (ACK) is received, the sender 215 immediately schedules a temporary Tx cell. Compared to the 216 initial cell, the temporary cell has the same Link Options plus 217 the 'Shared' bit, the same channel offset, and a time offset 218 incremented by 1 (modulo the slotframe length). The next frame 219 will be sent on this temporary cell, and may set the 'frame 220 pending' bit again to signal more traffic to come. The procedure 221 repeats until the transmit queue is empty, or until no 222 acknowledgment is received for a frame. 223 Receiver: Upon receiving a unicast frame with the 'frame pending' 224 bit set, the node first sends a link-layer ACK. It then schedules 225 a temporary Rx cell, with same Link Options, same channel offset, 226 and time offset incremented by 1. If, in the new cell, it 227 receives a unicast frame with the 'frame pending' bit set, it 228 continues scheduling additional Rx cells to receive subsequent 229 frames. 231 3.4. Interaction between Slotframes 233 ASF is expected to maintain multiple slotframes, each dedicated to a 234 different traffic type. As the slotframes repeat over time, cells 235 from different slotframes overlap periodically. In case a node has 236 multiple cells scheduled at the same time, the precedence rules from 237 [IEEE802154-2015] apply. In order to distribute cell overlap 238 uniformly, it is RECOMMENDED to select slotframe lengths that are co- 239 primes. 241 4. Configuration 243 An ASF configuration consists of a series of slotframes with 244 attributes. ASF uses the 6P SIGNAL command (format in Figure 1) to 245 disseminate its configuration. SIGNAL commands are directly included 246 as IETF IE in each EB, so that nodes learn the ASF configuration 247 directly at join-time. 249 6TiSCH EBs are not secured. For applications that require the ASF 250 schedule to be sent securely, the ASF SIGNAL command MAY be sent 251 instead in separate data broadcast packets, after join-time. To 252 summarize, there are two cases: 254 Initial EB includes ASF SIGNAL: The node configures itself to run 255 the ASF configuration provided. 256 Initial EB does not include ASF SIGNAL: The node runs the 6TiSCH 257 minimal schedule ([RFC8180]) at association. When later receiving 258 a packet with ASF SIGNAL, the node replaces the 6TiSCH minimal 259 schedule with the ASF configuration provided. 261 Figure 1 describes the format of the ASF SIGNAL command. 263 1 2 3 264 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 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | # Slotframes | Slotframe list ... 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 Figure 1: Format of the ASF SIGNAL command. 271 Where: 273 # Slotframes: The number of ASF slotframes 274 Slotframe list: The list of slotframes, with format described in 275 Figure 2 276 1 2 3 277 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 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Slotf. handle | Slotframe size | Type | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Min. channel offset | Max. channel offset | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | Tx Cell Opt | Rx Cell Opt | Nbr Set | Hash func. | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | # Filters | Traffic filter list ... 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 288 Figure 2: Format of the ASF SIGNAL slotframe descriptor. 290 Figure 2 shows the format of a slotframe descriptor, where: 292 Slotf. handle: The IEEE 802.15.4 slotframe handle (8 bits) 293 Slotframe size: The IEEE 802.15.4 slotframe size (16 bits) 294 Type: The ASF slotframe type. The set of possible values for this 295 field is presented in Figure 3. The different slotframe types are 296 described in Section 3.2. 297 Min. channel offset: ASF slotframes are assigned a channel offset 298 range. This defines the lower bound for the range. 299 Max. channel offset: ASF slotframes are assigned a channel offset 300 range. This defines the upper bound for the range. 301 Tx Cell Opt: The options to be used for the Tx Cells, if any. 302 Rx Cell Opt: The options to be used for the Rx Cells, if any. 303 Nbr Set: The set of neighbors for which Cells are instantiated. The 304 set of possible values for this field is presented in Figure 4. 305 Hash func.: The hash function used to compute cell coordinates from 306 a node's EUI-64 address, as defined in Section 3.1. The set of 307 possible values for this field is presented in Figure 5. 308 # Filters: ASF slotframes are assigned a subset of the traffic each. 309 One or several traffic filters will be applied to only select 310 packets with the intended properties. When there are several 311 traffic filters, they are combined with a OR, i.e., packets that 312 satisfy any of the filters will be sent on the slotframe. This 313 field defines how many filters are in place. The filter 314 descriptions follow inline, with format defined in Figure 6. 316 +-----------+---------------------------------+ 317 | Num. | Description | 318 +-----------+---------------------------------+ 319 | 0 | Rendez-vous slotframe | 320 +-----------+---------------------------------+ 321 | 1 | Receiver-based slotframe | 322 +-----------+---------------------------------+ 323 | 2 | Sender-based slotframe | 324 +-----------+---------------------------------+ 325 | 128--255 | Reserved | 326 +-----------+---------------------------------+ 328 Figure 3: Field: types of slotframes. 330 +-----------+---------------------------------+ 331 | Num. | Description | 332 +-----------+---------------------------------+ 333 | 0 | Empty set | 334 +-----------+---------------------------------+ 335 | 1 | All TSCH time sources | 336 +-----------+---------------------------------+ 337 | 2 | All RPL parents | 338 +-----------+---------------------------------+ 339 | 3 | The RPL preferred parent | 340 +-----------+---------------------------------+ 341 | 4 | All IPv6 NDP neighbors | 342 +-----------+---------------------------------+ 343 | 128--255 | Reserved | 344 +-----------+---------------------------------+ 346 Figure 4: Field: neighbor set. 348 +-----------+---------------------------------+ 349 | Num. | Description | 350 +-----------+---------------------------------+ 351 | 0 | SAX (Shift-Add-XOR) | 352 +-----------+---------------------------------+ 353 | 1--255 | Reserved | 354 +-----------+---------------------------------+ 356 Figure 5: Field: Hash function 358 1 2 3 359 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 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | FT | UC/BC | IP protocol | Type / Code / Port | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 Figure 6: Format of the ASF SIGNAL traffic filters. 366 The fields for traffic filter descriptions (Figure 6) are described 367 next: 369 FT: The IEEE 802.15.4 frame type. Examples; 0: Beacon; 1: Data. 370 UC/BC: Unicast/broadcast nature. Possible values; 0: unicast; 1: 371 broadcast; 2: any. 372 IP protocol: The IP protocol number. Examples; 0x3a: ICMPv6; 0x11: 373 UDP. A value of 0x00 ignores this field. 374 Type / Code / Port: In the case of ICMPv6: the Type (first 8 bits) 375 followed by the Code (last 8 bits). In case of UDP or TCP: the 376 16-bit port. A value of 0x00 ignores this field. 378 Example filters are given next: 380 All TSCH EBs: FT: 0 (beacon), UC/BC: 1 (broadcast), IP protocol: 0, 381 Type: 0. 382 All RPL Traffic: FT: 1 (data), UC/BC: 2 (unicast and broadcast), IP 383 protocol: 0x3a (ICMPv6), Type: 0x9b (RPL), Code: 0x00 384 RPL Unicast DIO: FT: 1 (data), UC/BC: 0 (unicast), IP protocol: 0x3a 385 (ICMPv6), Type: 0x9b (RPL), Code: 0x01 (DIO) 386 UDP port 5683: FT: 1 (data), UC/BC: 2 (unicast and broadcast), IP 387 protocol: 0x11 (UDP), Port: 5683 389 5. Scheduling Function Identifier 391 The Scheduling Function Identifier (SFID) of ASF is IANA_SFID_ASF. 393 6. Rules for Adding/Deleting Cells 395 ASF nodes maintain their cells autonomously, and do not use 6P ADD 396 nor DELETE. 398 7. Rules for CellList 400 For the 6P LIST command, ASF uses the default CellList field format 401 defined in Section 4.2.4 [TODO: update if needed] of 402 [I-D.ietf-6tisch-6top-protocol]. 404 8. 6P Timeout Value 406 The timeout is of low criticality in ASF as 6P Requests are only used 407 for schedule inspection, not for cell addition/removal. The 408 RECOMMENDED timeout value in slots is: 410 2^(macMaxBe+2)*SlotframeD_len 412 which is an upper bound of the maximum time spent in transmission 413 attempts of a 6P Request and Response, over slotframeD (where 6P 414 traffic is sent). The upper bound is conservative, giving extra time 415 for time spent in packet queues. 417 9. Rule for Ordering Cells 419 Cells are ordered by increasing slotframe handle, then by timeslot, 420 then channel offset. 422 10. Meaning of the Metadata Field 424 The Metadata 16-bit field is used as follows: Figure 7 shows the 425 format of the Metadata field, where: 427 o Slotframe: is used to identify a slotframe by its handle. 428 o Bits 8-15 are reserved. 430 1 2 3 431 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 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | Slotframe | Reserved | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 Figure 7: Format of the Metadata Field. 438 11. Node Behavior at Boot 440 At boot, nodes start with an empty schedule. When associating, they 441 configure their schedule with the 6P ASF SIGNAL command, which is 442 included either in the initial EB or later packets, as described in 443 Section 4. 445 12. 6P Error Handling 447 ASF only uses 6P commands COUNT and LIST. In case of error on STATUS 448 or LIST, the node MAY retry to contact this neighbor after the 6P 449 timeout. 451 13. Examples 453 TODO 455 14. [TEMPORARY] Implementation Status 457 This section records the status of known implementations of the 458 protocol defined by this specification at the time of posting of this 459 Internet-Draft, and is based on a proposal described in [RFC6982]. 460 The description of implementations in this section is intended to 461 assist the IETF in its decision processes in progressing drafts to 462 RFCs. Please note that the listing of any individual implementation 463 here does not imply endorsement by the IETF. Furthermore, no effort 464 has been spent to verify the information presented here that was 465 supplied by IETF contributors. This is not intended as, and must not 466 be construed to be, a catalog of available implementations or their 467 features. Readers are advised to note that other implementations may 468 exist. 470 According to [RFC6982], "this will allow reviewers and working groups 471 to assign due consideration to documents that have the benefit of 472 running code, which may serve as evidence of valuable experimentation 473 and feedback that have made the implemented protocols more mature. 474 It is up to the individual working groups to use this information as 475 they see fit". 477 Contiki: The mechanism behind this specification is implemented in 478 the Contiki project [Contiki]. Adjustments to exactly match this 479 specification are in progress. The mechanism was evaluated 480 experimentally in large-scale testbeds in [Orchestra-SenSys]. 482 15. Security Considerations 484 At run-time, ASF is not threatened by attacks on 6P messages as it 485 operates without signaling. However, it bases its TSCH schedule on 486 external information, namely: (1) the identify of the current TSCH 487 time source and (2) the MAC address of its neighbors. ASF relies on 488 link-layer security to ensure the integrity of the above information. 490 At configuration time, ASF relies on a 6P SIGNAL command. This 491 command MAY be secured as described in Section 4. When this command 492 is not secured, the security of the network is equivalent to that of 493 the 6TiSCH minimal configuration ([RFC8180]). That is, the network 494 schedule is propagated directly through EBs. 496 16. IANA Considerations 498 16.1. 6P Scheduling Function Identifiers 'ASF' 500 This document adds the following number to the "6P Scheduling 501 Function Identifiers" registry defined by 502 [I-D.ietf-6tisch-6top-protocol]: 504 +----------------------+--------------------------------+-----------+ 505 | SFID | Name | Reference | 506 +----------------------+--------------------------------+-----------+ 507 | IANA_6TiSCH_SFID_ASF | Autonomous Scheduling Function | RFCXXXX | 508 | | (ASF) | | 509 +----------------------+--------------------------------+-----------+ 511 Figure 8: 6P Scheduling Function Identifiers 'ASF'. 513 17. References 515 17.1. Normative References 517 [IEEE802154-2015] 518 IEEE standard for Information Technology, "IEEE Std 519 802.15.4-2015 Standard for Low-Rate Wireless Personal Area 520 Networks (WPANs)", December 2015. 522 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 523 Requirement Levels", BCP 14, RFC 2119, 524 DOI 10.17487/RFC2119, March 1997, 525 . 527 17.2. Informative References 529 [Contiki] Dunkels, A., Lignan, A., Thebaudeau, B., Quattlebaum, R., 530 Rosendal, F., Oikonomou, G., Deru, L., Alvira, M., 531 Tsiftes, N., Schmidt, O., and S. Duquennoy, "The Contiki 532 Open Source OS for the Internet of Things", 533 https://github.com/contiki-os/contiki , November 2016. 535 [I-D.ietf-6tisch-6top-protocol] 536 Wang, Q., Vilajosana, X., and T. Watteyne, "6top Protocol 537 (6P)", draft-ietf-6tisch-6top-protocol-09 (work in 538 progress), October 2017. 540 [I-D.ietf-6tisch-terminology] 541 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 542 "Terminology in IPv6 over the TSCH mode of IEEE 543 802.15.4e", draft-ietf-6tisch-terminology-09 (work in 544 progress), June 2017. 546 [Orchestra-SenSys] 547 Duquennoy, S., Al Nahas, B., Landsiedel, O., and T. 548 Watteyne, "Orchestra: Robust Mesh Networks Through 549 Autonomously Scheduled TSCH", ACM SenSys 2015 , November 550 2015. 552 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 553 Code: The Implementation Status Section", RFC 6982, 554 DOI 10.17487/RFC6982, July 2013, 555 . 557 [RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal 558 IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) 559 Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180, 560 May 2017, . 562 [SAX-DASFAA] 563 Ramakrishna, M. and J. Zobel, "Performance in Practice of 564 String Hashing Functions", DASFAA , 1997. 566 Appendix A. Contributors 568 Beshr Al Nahas (Chalmers University, beshr@chalmers.se) and Olaf 569 Landsiedel (Chalmers University, olafl@chalmers.se) contributed to 570 the design and evaluation of ASF. 572 Appendix B. Acknowledgments 574 TODO people 576 TODO projects 578 Appendix C. [TEMPORARY] Changelog 580 o draft-duquennoy-6tisch-asf-01 582 * Defines ASF configuration parameters and procedure; 583 * Defines packet format to disseminate configurations (6P 584 signal); 585 * Defines burst mode (conditional cells based on 'frame pending' 586 bit); 587 * Makes Hash function configurable (SAX remains default). 589 o draft-duquennoy-6tisch-asf-00 591 * Initial draft. 593 Authors' Addresses 595 Simon Duquennoy (editor) 596 RISE SICS 597 Isafjordsgatan 22 598 164 29 Kista 599 Sweden 601 Email: simon.duquennoy@ri.se 603 Xavier Vilajosana 604 Universitat Oberta de Catalunya 605 156 Rambla Poblenou 606 Barcelona, Catalonia 08018 607 Spain 609 Email: xvilajosana@uoc.edu 611 Thomas Watteyne 612 Inria 613 2 Rue Simone Iff 614 Paris 615 France 617 Email: thomas.watteyne@inria.fr