1. 8 May 2015 Webex IPv6 over the TSCH mode of IEEE 802.15.4e Chairs:
Pascal Thubert
Thomas Watteyne
Etherpad for minutes:

2. 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) 2 2

3. Reminder: Minutes are taken. This meeting is recorded
Reminder: Minutes are taken * This meeting is recorded ** Presence is logged ***
* Scribe; please contribute online to the minutes at
** Recordings and Minutes are public and may be subject to discovery in the event of litigation.
*** From the Webex login 3 3 3 3

4. Agenda - Administrivia [2min]
Minutes Last meetings
- Consensus removing 'e' (concerns charter and draft references) [10min]
- Suggestions for draft-ietf-6tisch-architecture [10min]
- Plugtest test plan [10min]
- 6TiSCH design for DetNet [15min]
- Security Changes [10min]
- AOB [3min] 4 4 4 4 4

5. Administrivia

6. Admin is trivia
Approval Agenda
Approval minutes 6 6 6 6

7. ML stats
128 s since last call
Topics
Finalizing drafts (53)
draft-ietf-6tisch-minimal (incl. security) (43)
draft-ietf-6tisch-architecture (10)
Security (37)
Role of Ebs (16)
CoAP security (11)
joining security (7)
draft-richardson-security-6top (3)
removing the 'e' in the charter (31)
admin/announcements (6)
Plugtest (3)
agenda/minutes (3)
new ideas (1)
Tero Kivinen 16
Kris Pister 14
Pascal Thubert
Michael Richardson 13
Thomas Watteyne 12
Qin Wang 9
Tom Phinney 7
Xavi Vilajosana 6
NB: reflects activity only

8. Consensus removing 'e' (concerns charter and draft references)

9. Proposal In charter In I-Ds Remove ‘e’
Undated reference when talking about IEEE TSCH in general
Otherwise dated reference:
IEEE standard for Information Technology, IEEE std.
, Part. 15.4: Wireless Medium Access Control (MAC)
and Physical Layer (PHY) Specifications for Low-Rate
Wireless Personal Area Networks, June 2011 as amended by IEEE std.
e, Part. 15.4: Low-Rate Wireless Personal Area
Networks (LR-WPANs) Amendment 1: MAC sublayer

10. Suggestions for
Architecture draft

11. Discussion
Different understandings of scope of the document (see
The 6TiSCH vision: mechanisms to establish and maintain routing and scheduling in a centralized, distributed, or mixed fashion, as well as how 6TiSCH components interact and how 6TiSCH interacts with other IoT-related IETF WGs and technologies. This document is versioned ("volumes") to accurately track the evolution of the technology, charter, and discussions.
An overview of the different blocks and an “index” to the different I-Ds

12. Update Plugtest

13. Status Plugtest Important dates:
April First draft sent to 6TiSCH ML  feedback welcome
May 31st: Registration deadline  don’t forget to register
Early June 2015: final test spec
Scope: draft-ietf-6tisch-minimal
17-19 July: Plugtest

14. Tests (work-in-progress)

15. IETF 93 Hackathon
The Internet Engineering Task Force (IETF) is holding a Hackathon to encourage developers to discuss, collaborate and develop utilities, ideas, sample code and solutions that show practical implementations of IETF standards.
When: Saturday July 18 and Sunday July 19
Where: Hilton Prague, Room TBD
Keep up to date by subscribing to
The Hackathon is free to attend but limited to 100 attendees.
Champions are individuals familiar with a given technology who have volunteered to help get others get up and running with that technology
Champions should:
Plan to arrive Friday, for any setup, and attend Saturday and Sunday
Prepare a brief overview presentation to introduce the technology and suggest potential projects
Make themselves available to answer questions and help others
Hack on things themselves in their copious free time
Additional champions for new or existing technologies are welcome at any time, send to hackathon at ietf.org
Proposal: Propose an OpenWSN/OpenMote/6TiSCH technology?
4/16/2018

16. 6TiSCH design for DetNet
Note, some Cisco IPR below

18. Source & destination diversity with LeapFrog Cooperation

19. Collaboration A B C D E F G H I Scheduled transmission (far)1’ 2’ 3’ 4’ 5’ A B C D E F G H I 1 2 3 4 5
Scheduled transmission (far)
Scheduled promiscuous listen (near)

20. Alternate view with plan B and CF G H I
Scheduled transmission (far, low probability))
Scheduled promiscuous listen (mid distance)
Scheduled promiscuous listen (near, high probability)

21. Path Diversity with Replication and Elimination

22. ARC chain
An ARC chain is a form of « ladder » that can be used for frame replication and elimination with no single point of failture.
Each side of the ladder is a main path, and the steps can be used for Replication and Elimination D P I J G C L M H A B E F Z

23. Scheduling rules
A scheduled frame or packet is associated to a number of receive and transmit slots at any given node.
The first slot is a receive slot and the last is a transmit slot.
There may be intermixed a rcv and xmit slots in between
A node in an ARC copies a frame received from a parent ARC as soon as possible inside the ARC, left and right, not down.
But it does not copy in one direction if it already got the frame from that direction
And may not listen on a receive slot if frame was already received from any direction
Note that the L2 ACK if any is ignored and can be omitted

24. Scheduling an ARC L H F L F receives a first copy of the packet at T1
(can be based on timer or time slot). H
Rcv (up) F
time

25. Scheduling an ARC L H F L F forwards the packet along the ARC at T2
F being at the extreme right of its ARC, it only sends to the left H
Rcv right
Rcv (up) F
Xmit left
time

26. H may not listen if it received from F
Scheduling an ARC L H F L
H receives a first copy of the packet at T3
It may or may not have received F’s copy,
depending on interferences, multipath, fading etc…
If it had received the packet, it could refrain from listening, or listen still in order to validate that the packets are identical.
Rcv (up) H
Rcv right
H may not listen if it received from F
Rcv (up) F
Xmit left
time

27. Scheduling an ARC L H F L Rcv right
H forwards the packet along the ARC at T4
Being in the middle of the ARC, H has a transmit schedule
on both sides
Rcv (up) H
Rcv right
Xmit left
xmit right
H will not send right if it received from left
F may not listen if it received from above
Rcv (up) F
Rcv left
Xmit left
time

28. L may not listen if it received from above
Scheduling an ARC L H F
Rcv (up) L
Rcv right
L may not listen if it received from above
Rcv (up) H
Rcv right
Xmit left
xmit right
L receives a first copy
of the packet at T5
Could be same time as H to L but on a different channel
Rcv (up) F
Rcv left
Xmit left
time

29. Scheduling an ARC L H F Rcv (up) L Rcv right xmit right
L will not send if it received from H
H may not listen if it already has that pak
Rcv (up) H
Rcv right
Xmit left
xmit right
Rcv left
L sends at T6 to H, unless it already got the same message from H
Rcv (up) F
Rcv left
Xmit left
time

30. Scheduling an ARC L H F Rcv (up) L Rcv right xmit right
L will not send if it received from H
H may not listen if it already has that pak
Rcv (up) H
Rcv right
Xmit left
xmit right
Rcv left
L sends at T7 to H, unless it already got the same message from H.
L is exterme left so no sending leftwise.
Rcv (up) F
Rcv left
Xmit left
time

31. Scheduling an ARC L H F Rcv (up) L Rcv right xmit right
L will not send to that slot if it got the packet from H already
At T8, H forwards right, if still needed
Rcv (up) H
Rcv right
Xmit left
xmit right
Rcv left
xmit right
H may not listen if it has the packet already
Rcv (up) F
Rcv left
Xmit left
Rcv left
time

32. Scheduling an ARC L H F At T9, H forwards left, if still needed
Rcv (up) L
Rcv right
xmit right
Rcv right
L may not listen to that slot if it got the packet already
Rcv (up) H
Rcv right
Xmit left
xmit right
Rcv left
xmit right
Xmit left
At T9, All receive opportunities are consumed, F can send down
H will not send if it received from that side
Rcv (up) F
Rcv left
Xmit left
Rcv left
Xmit down
time

33. H will not send right if it received from left
Scheduling an ARC L H
At T10, All receive opportunities are consumed, L can also send down F
Rcv (up) L
Rcv right
xmit right
Rcv right
Xmit down
L will not listen to that slot if it got the packet already from previous
Rcv (up) H
Rcv right
Xmit left
xmit right
Rcv left
xmit right
Xmit left
H will not send right if it received from left
Rcv (up) F
Rcv left
Xmit left
Rcv left
Xmit down
time

34. Notes
A real ARC might have any number of incoming links, as well as any number of nodes between nodes with incoming.
The cool thing for this scheduling algorithm is that it can schedule sending right after receive, all the unneeded transmissions and listens do not actually happen.

35. Security Changes
Tero Kivinen
INSIDE Secure

36. What
In maintenance work the SC-M takes all amendments published and rolls them into one document.
During this process there is quite a lot of mistakes, errors and omissions noted, which are then fixed during the process.
Currently in sponsor ballot, you can buy the current version from IEEE.
Security section snapshot can be found from
security-functional-description-from-p revc-df5.pdf
Mentor is like IEEE version of internet-draft repository. Members can submit stuff, everybody can read and download them.

37. Corrections
Fixed incoming state machine to clearly allow mixing secured and not-secured frames.
Fixed incoming state machine to work with TSCH ASN, i.e. skip the frame counter processing if TSCH is used.
Properly specified which parts of the 4e new frames are encrypted and which not (i.e. header IEs are not encrypted and Payload IEs can be encrypted).
Specified that Enh-Acks cannot use the same frame counter as the incoming packet had, they can still use ASN for TSCH.
Changed the PIB tables to be bit more logical, keeping the same feature set.

38. Changes / Things removed
Changed the MAC command identifier to be encrypted for new frame types. It is after the encrypted payload IEs, and you need to decrypt them before you can know where the command identifier is, which would make it very complicated if it was in clear.
Removed ability have 5-octet frame counter stored in frame, now 5-octet nonce format is only used for TSCH and ASN.
Removed encrypt only security level (security level 4).
Removed the short address from the TSCH nonce generation as it is unsafe, and not specified clearly enough (i.e. there cannot really be interoperable implementations done based on the text in 4e).

39. Additions
Added ability to specify which IEs the MAC layer will act on, i.e. for each IE there is now ability to specify policy whether it is processed or skipped.
To make security easier to understand we spitted the incoming state machine to two pieces one for secured frame and another for not-secured frames.
Provided state machine pictures and security PIB entry pictures.
security-section-pictures.pdf
Not part of base specification, but will be referenced in the bibliography.

40. AOB ?

41. Thank you!