1. Chairs: Pascal Thubert Thomas Watteyne Etherpad for minutes: http://etherpad.tools.ietf.org:9000/p/6tisch IPv6 over the TSCH mode of IEEE 802.15.4e 10/24/2014 Webex

2. 22 Note Well This summary is only meant to point you in the right direction, and doesn't have all the nuances. The IETF's IPR Policy is set forth in BCP 79; please read it carefully. The brief summary: By participating with the IETF, you agree to follow IETF processes. If you are aware that a contribution of yours (something you write, say, or discuss in any IETF context) is covered by patents or patent applications, you need to disclose that fact. You understand that meetings might be recorded, broadcast, and publicly archived. For further information, talk to a chair, ask an Area Director, or review the following: BCP 9 (on the Internet Standards Process) BCP 25 (on the Working Group processes) BCP 78 (on the IETF Trust) BCP 79 (on Intellectual Property Rights in the IETF)

3. 3333 Reminder: Minutes are taken * This meeting is recorded ** Presence is logged *** * Scribe; please contribute online to the minutes at http://etherpad.tools.ietf.org:9000/p/6tisch?useMonospaceFont=true http://etherpad.tools.ietf.org:9000/p/6tisch?useMonospaceFont=true ** Recordings and Minutes are public and may be subject to discovery in the event of litigation. *** From the Webex login

4. 44444 Agenda Administrivia[3min] –Approval agenda –Approval minutes last call IETF91[5min] –meetecho remote presentation –draft agenda draft-ietf-6tisch-tsch-02 publication[2min] –please review wrapping up draft-ietf-6tisch-minimal[15min] draft-richardson-6tisch--security-6top-02 [15min] RPL option status and update 6lo[10min] RFC7322: RFC Style Guide[5min] AOB[1min]

5. Administrivia

6. 6666 Approval Agenda Approval minutes last call Call security DT on Tuesday –6 participants –Goal: review draft-richardson-6tisch-- security-6top –Minutes at https://bitbucket.org/6tisch/meetings/wiki/141 021_webex_security https://bitbucket.org/6tisch/meetings/wiki/141 021_webex_security –Next call next Tuesday

7. IETF91

8. IETF91 admin 0900-1030 HST Thursday Morning Session I (90min) Remote participation and presentation possible –Minutes will include remote participants Important dates: –http://www.ietf.org/meeting/important-dates-2014.html#IETF91http://www.ietf.org/meeting/important-dates-2014.html#IETF91 –2014-10-27 (Monday): Internet Draft submission cut-off (for all drafts, including -00) by UTC 23:59, upload using IETF ID Submission Tool. –2014-10-27 (Monday): Draft Working Group agendas due by UTC 23:59, upload using IETF Meeting Materials Management Tool. –2014-11-03 (Monday): Revised Working Group agendas due by UTC 23:59, upload using IETF Meeting Materials Management Tool. –2014-11-06 send list of remote presenters to Meetecho team.

9. Intro and Status [5min] (Chairs) Note-Well, Blue Sheets, Scribes, Agenda Bashing 6TiSCH milestones recap Chartered Drafts [40min] Goal: present latest changes and decide whether ready for WGLC. * (10min) (TBD) * (15min) (TBD) Liaison and Announcements [25min] * (15min) (TBD) * 6TiSCH ETSI Plugtest at IETF93 (10min) (TBD) Rechartering First Glance [10min] (Chairs) 6TiSCH Security Discussion [20min] * (10min) (Michael Richardson) * TBD (10min) (Rene Struik) Any Other Business [5min]

10. Next steps Thomas to create slide skeleton Slides to chairs by 11/03 midnight PDT for integration Review slides next call 11/07

11. draft-ietf-6tisch-tsch-02

12. Status https://tools.ietf.org/html/draft-ietf-6tisch- tsch-02 published 17 Octoberhttps://tools.ietf.org/html/draft-ietf-6tisch- tsch-02 Diff at https://tools.ietf.org/rfcdiff?url2=draft-ietf- 6tisch-tsch-02.txt https://tools.ietf.org/rfcdiff?url2=draft-ietf- 6tisch-tsch-02.txt Following rewording proposed Closes all issues, but 2 (see later)

13. 1. Introduction........................ 3 2. Requirements Language.................... 4 3. TSCH in the LLN Context................... 4 4. Problems and Goals..................... 6 4.1. Network Formation.................... 6 4.2. Network Maintenance................... 7 4.3. Multi-Hop Topology................... 7 4.4. Routing and Timing Parents............... 7 4.5. Resource Management................... 8 4.6. Dataflow Control.................... 8 4.7. Deterministic Behavior................. 8 4.8. Scheduling Mechanisms.................. 8 4.9. Secure Communication.................. 9 5. IANA Considerations..................... 9 6. Security Considerations................... 9 7. Acknowledgments....................... 9 8. References......................... 10 8.1. Normative References.................. 10 8.2. Informative References................. 10 8.3. External Informative References............. 13 Appendix A. TSCH Protocol Highlights.............. 15 A.1. Timeslots........................ 15 A.2. Slotframes....................... 16 A.3. Node TSCH Schedule................... 16 A.4. Cells and Bundles.................... 16 A.5. Dedicated vs. Shared Cells............... 17 A.6. Absolute Slot Number.................. 17 A.7. Channel Hopping..................... 18 A.8. Time Synchronization.................. 18 A.9. Power Consumption.................... 19 A.10. Network TSCH Schedule.................. 19 A.11. Join Process...................... 20 A.12. Information Elements.................. 20 A.13. Extensibility...................... 20 Appendix B. TSCH Gotchas.................... 21 B.1. Collision Free Communication.............. 21 B.2. Multi-Channel vs. Channel Hopping............ 21 B.3. Cost of (continuous) Synchronization.......... 21 B.4. Topology Stability................... 21 B.5. Multiple Concurrent Slotframes............. 22 Authors' Addresses....................... 22

14. http://tools.ietf.org/wg/6tisch/trac/ticket/25 Several people have pointed out the need to be more specific about the use of the MLME-TSCH-MODE.request primitive during joining. That is, when does a node issue this command. This discussion was ongoing in the thread ​ http://www.ietf.org/mail-archive/web/6tisch/current/msg02528.html We need to reach consensus how much of this discussion belongs in the 6tisch-tsch draft, and update the draft accordingly OLD A mote wishing to join the network listens for EBs. Since EBs are sent on all frequencies, the joining node can listen on any frequency until it hears an EB. What frequency it listens on, and whether it slowly changes frequency during this joining period is implementation-specific. Using the ASN and the other timing information of the EB, the new mote synchronizes to the network. Using the slotframe and cell information from the EB, it knows how to contact other nodes in the network. NEW A mote wishing to join the network listens for EBs. Since EBs are sent on all frequencies, the joining node can listen on any frequency until it hears an EB. What frequency it listens on is implementation-specific. Once it has received one or more EBs, the new node enables the TSCH mode and uses the ASN and the other timing information of the EB to synchronize to the network. Using the slotframe and cell information from the EB, it knows how to contact other nodes in the network.

15. http://tools.ietf.org/wg/6tisch/trac/ticket/24 Several people have pointed out the need to be more specific about the join priority, including the discussion started at ​ http://www.ietf.org/mail- archive/web/6tisch/current/msg02528.html We need to reach consensus how much of this discussion belongs in the 6tisch-tsch draft, and update the draft accordingly. OLD Motes already part of the network can periodically send Enhanced Beacon (EB) frames to announce the presence of the network. These contain information about the size of the timeslot used in the network, the current ASN, information about the slotframes and timeslots the beaconing mote is listening on, and a 1-byte join priority. Even if a node is configured to send all EB frames on the same channel offset, because of the channel hopping nature of TSCH described in, this channel offset translates into a different frequency at different slotframe cycles. As a result, EB frames are sent on all frequencies. NEW Motes already part of the network can periodically send Enhanced Beacon (EB) frames to announce the presence of the network. These contain information about the size of the timeslot used in the network, the current ASN, information about the slotframes and timeslots the beaconing mote is listening on, and a 1-byte join priority. The join priority field gives information to make a better decision of which node to join. Even if a node is configured to send all EB frames on the same channel offset, because of the channel hopping nature of TSCH described in, this channel offset translates into a different frequency at different slotframe cycles. As a result, EB frames are sent on all frequencies.

16. Final steps Reach rough consensus Decide whether read for WGLC

17. draft-ietf-6tisch-minimal

18. Minimal status Update default timing according to 15.4e TSCH Updated name of timing fields Pending external review and clarifications

19. Proposed Changes OLD The figure below shows an active timeslot in which a packet is sent from the transmitter node (TX) to the receiver node (RX). A link-layer acknowledgement is sent by the RX node to the TX node when the packet is to be acknowledged. The TsTxOffset duration defines the instant in the timeslot when the first byte of the transmitted packet leaves the radio of the TX node. The radio of the RX node is turned on TsLongGT/2 before that instant, and listens for at least TsLongGT. This allows for a de-synchronization between the two node of at most TsLongGT. The RX node needs to send the first byte of the MAC acknowledgement exactly TsTxAckDelay after the end of the last byte of the received packet. TX's radio has to be turned on TsShortGT/2 before that time, and keep listening for at least TsShortGT. NEW The figure below shows an active timeslot in which a packet is sent from the transmitter node (TX) to the receiver node (RX). A link-layer acknowledgement is sent by the RX node to the TX node when the packet is to be acknowledged. The TsTxOffset duration defines the instant in the timeslot when the first byte of the transmitted packet leaves the radio of the TX node. The radio of the RX node is turned on tsRxWait/2 before that instant, and listens for at least tsRxWait. This allows for a de-synchronization between the two node of at most tsRxWait. The RX node needs to send the first byte of the MAC acknowledgement exactly TsTxAckDelay after the end of the last byte of the received packet. TX's radio has to be turned on tsAckWait/2 before that time, and keep listening for at least tsAckWait. The TX node can perform a Clear Channel Assessment (CCA) if required, this does not interfere with the scope of this draft. As for a minimal configuration CCA is not mandatory.

20. Time slot internal timing diagram /------------------- Time Slot duration --------------------/ | /tsShortGT/ | | | | | | | |------------+-----------------+--------------+------+------| TX | | TX-Packet | |RX Ack| | |------------+-----------------+--------------+------+------| |/tsTxOffset/| | | | | | | | | | | |------------+-----------------+--------------+------+------| RX | | | | RX-Packet | |TX Ack| | |---------+--+--+--------------+--------------+------+------| | | | | | | | | | /tsLongGT/ |/TsTxAckDelay/| | | Start End of of Slot /---------------------------- Time Slot duration ---------------------/ | /tsAckWait/ | | | /tsRxAckDelay/| | | | |---------------------+-----------------+---------------+------+------| TX | /1/ /3/ /2/ | TX-Packet | |RX Ack| | |-----+------+--------+-----------------+---------------+------+------| |/ tsTxOffset /| | | | | | | | | | | |---------------------+-----------------+---------------+------+------| RX | | | | RX-Packet | |TX Ack| | |------------------+--+--+--------------+---------------+------+------| | | | | | | | | | /tsRxWait/ |/tsTxAckDelay/ | | | Start End of of Slot Slot /1/ tsCCAOffset /2/ tsRxTx /3/ tsCCA OLD NEW

21. +--------------------------------+------------+ | IEEE802.15.4e TSCH parameter | Value | +--------------------------------+------------+ | TsTxOffset | 2120us | +--------------------------------+------------+ | TsLongGT | 2000us | +--------------------------------+------------+ | TsTxAckDelay | 1000us | +--------------------------------+------------+ | TsShortGT | 400us | +--------------------------------+------------+ | Time Slot duration | 10000us | +--------------------------------+------------+ | IEEE802.15.4e TSCH parameter | Value (us) | +--------------------------------+------------+ | tsCCAOffset | 1800 | +--------------------------------+------------+ | tsCCA | 128 | +--------------------------------+------------+ | tsTxOffset | 2120 | +--------------------------------+------------+ | tsRxOffset | 1120 | +--------------------------------+------------+ |tsRxAckDelay | 800 | +--------------------------------+------------+ | tsTxAckDelay | 1000 | +--------------------------------+------------+ | tsRxWait | 2200 | +--------------------------------+------------+ | tsAckWait | 400 | +--------------------------------+------------+ | tsRxTx | 192 | +--------------------------------+------------+ | tsMaxAck | 2400 | +--------------------------------+------------+ | tsMaxTx | 4256 | +--------------------------------+------------+ | Time Slot duration | 10000 | +--------------------------------+------------+ OLD NEW

22. Open Questions HbH header compression. Indicate direction –+1 for 6lo approach –+1 for not limiting possible future extensions with other routing protocols Security –What should we say at the minimal draft? No security at all? Review of IEs in the EBs and other Frames. Is everything covered? –Need review and approval from 15.4e experts/implementors

23. ML Questions Routing Header Compression 23

24. Final steps What to do with possible compression of RPL option? Reach rough consensus Decide whether ready for WGLC

25. draft-richardson-6tisch-- security-6top-02

26. 6tisch mesh 6top/NS/ARO join protocl (“wirelessHART”-like) JCE Joining Node Join Assistant (proxy) 6LBR Join Coordination Entity Akin to PCE Could be part of 6LBR Or co-located in PCE Router Advertisement Certificate Request (2) Certificate Reply (3) (2) and (3) May have limited Utility, kept for now NS (DAR) (5) ?? (6) ?? (7) NS (DAC) (8) NS / Join ACK (9) DAO Mesh node DAO DAOACK BEACON (1) Router Solicitation 6top (CoAP/DTLS) Join Request (4) (NS w/(E)ARO) OUI field of EARO Contains 802.11AR IDevID DTLS connection Has client and server Autonomic certificates draft-richardson-6tisch--security-6top 26

27. RPL option status and update 6lo

28. draft-thubert-6lo-rpl-nhc-02 Mostly converged with Carsten Intent to have a common draft Isolated debate greedy vs. conservative 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NHC: I=0, K=0 | RPLInstanceID | SenderRank | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NHC: I=1, K=1 | SenderRank | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

29. The RFC Style Guide RFC 7322 http://www.rfc- editor.org/styleguide.htmlhttp://www.rfc- editor.org/styleguide.html

30. 30 RFC 7322: "RFC Style Guide"RFC 7322: "RFC Style Guide" The RPC is manually fixing these items, while the tools do not yet provide this functionality: Section 4: Unnumbered sections (related ticket for xml2rfc v2)related ticket for xml2rfc v2 Section 4.8.6.3: Referencing STDs and BCPs (related ticket for xml2rfc v2)related ticket for xml2rfc v2 Section 4.8.6.4: Referencing Internet-Drafts "Authors' Addresses" will appear in the Table of Contents (related ticket for xml2rfc v2)related ticket for xml2rfc v2 Note that some of these fixes occur in the final stages of the publication process; i.e., the changes are applied to the.nroff file to get the required.txt output.

31. 31 Web Portion of the Style GuideWeb Portion of the Style Guide – detailed hereafter Status of This Memo BoilerplateStatus of This Memo Boilerplate - "Status of This Memo" text as defined by RFC 5741RFC 5741 Abbreviations ListAbbreviations List - Expansions of abbreviations (and acronyms) in RFCs Terms ListTerms List - Table of decisions on consistent usage in RFCs IAB FormatIAB Format - IAB-specific format for RFCs in the IAB stream. Old materials (replaced by the documents above): RFC Editorial PoliciesRFC Editorial Policies - A collection of policies on RFC editorial issues. "Instructions to RFC Authors""Instructions to RFC Authors" - A draft replacement for RFC 2223.

32. No expansion This list includes some terms that look like abbreviations but are actually fixed names for things, and hence cannot and should not be expanded. These are noted as "No expansion". ---------------------------------------------------------------------- … 6CO - 6LoWPAN Context Option (6CO) (RFC 6775) 6LBR - 6LoWPAN Border Router (6LBR) (RFC 6345) 6LN - 6LoWPAN Node (6LN) (RFC 6775) 6LoWPANs - IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) (RFC 4919) 6LR - 6LoWPAN Router (6LR) (RFC 6606) …

33. MUSTs RFC numbers may be used as modifiers in running text, but they must appear as follows: no hyphens between "RFC" and the number (e.g., RFC-5011- style rollover); a space should appear between the RFC and the number (e.g., RFC 5011 style rollover) avoid hyphenating citations with text (e.g., don't use [RFC5011]-style rollover) if the sentence is unclear or potentially confusing, the sentence will be rewritten when possible. Otherwise, the issue will be raised with the authors for discussion.

34. RECOMMENDED Length of Sections All RFCs are naturally divided in to sections. We recommend that the length of a section or subsection be limited to allow for easily referenced objects. Abbreviations as Verbs Avoid using abbreviations as verbs when possible. If unavoidable, suffixes should be affixed without punctuation, for example, "XORed" (not XOR'ed) and "NATed" (not NAT- ed). Expanding abbreviations upon first use Abbreviations should be expanded upon first use. The abbreviated form should be used thereafter. Didactic Capitalization Use of didactic capitalization is not needed. For example: Extensible Markup Language (XML) (not EXtensible Markup Language (XML) or eXtensible Markup Language (XML))

35. RECOMMENDED (con’t) In-text Citations (bracketed citation) An in-text citation may a) be read as part of the text or b) follow the subject for which it is being cited. For example: a)As part of the transition to IPv6, NAT64 [RFC6146] and DNS64 [RFC6147] technologies will be utilized by some access networks to provide IPv4 connectivity for IPv6-only nodes [RFC6144]. or b) Note that SAVI raises a number of important privacy considerations that are discussed more fully in [RFC6959]. We recommend using a) and strongly recommend consistent use of one style throughout. Referring to specific sections within another document This is mostly left to author preference. However, note the following: Instances of "[RFCXXXX] section N.N" will be updated as "[RFCXXXX], Section N.N" in most cases. If that format may be unclear, the text will be updated as "Section N.N of [RFCXXXX]". If neither option works for some reason, a question will be sent to the authors.

36. AOB ?

37. Next meetings and deadlines Monday 10/27 I-D cutoff –draft-ietf-6tisch-minimal? –draft-ietf-6tisch-tsch? –draft-ietf-6tisch-6top-interface (  reviews!) –Others? Monday 10/27: draft WG meeting agenda Tuesday 10/28: security DT webex Monday 11/03: final WG meeting agenda Monday 11/03: slides IETF91 Friday 11/07: 6TiSCH webex –Goal: review slides

38. Thank you!