1. 23 January 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]
Approval agenda
Approval minutes last call
Updates since last call
draft-dujovne-6tisch-on-the-fly-04 [Diego Dujovne] [20min]
draft-piro-6tisch-security-issues [Giuseppe Piro] [20min]
announcement ROLL interim meeting [5min]
AOB [3min] 4 4 4 4 4

5. Administrivia

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

7. draft-dujovne-6tisch- on-the-fly-04
Diego Dujovne
missed

8. On-The-Fly scheduling
Layer-3 mechanism Dynamically adapt aggregate bandwidth Between neighbours Based on application constraints Distributed Requires 6top-to-6top negotiation

9. Allocation Policy
Allocated cells from the Best Effort (ID=00) track. OTF manges global bandwidth between nodes; no track management Schedule collision is possible: same cell allocated by different pairs of interfering nodes

10. Allocation Policy
Algorithm to decides when to change allocated BW between neighbours
To satisfy traffic requirements (latency, throughput…)
We define:
Scheduled cells: Those already on the BE track
Required cells: Number of cells requested from OTF to 6top
OTF Threshold: Over-provisioning

11. Allocation Policy
This replaces our former definitions of Proactive, Reactive or Hybrid. Required Cells > Scheduled Cells -> Add 1+ cells (Required Cells >= Scheduled Cells-OTF Threshold) && (Required Cells <= Scheduled Cells) -> Do nothing Required Cells < Scheduled Cells-OTF Threshold -> Delete 1+ cells

12. Allocation Policy
This Policy adds hystheresis to the system, reducing 6top negotiation traffic Overprovisioning depends on OTF Threshold

13. Allocation Methods
How OTF and 6top communicate Soft cell and Bundle allocation methods Create/Resize bundles according to requirements Bundles are internally managed by 6top A Bundle is created to use the BE track (ID=00)

14. Extract statistics from 6top
CellList: Per-cell statistics / Per-bundle statistics
MonitoringStatusList: Per-neighbour / Slotframe stats (hardcells, softcells, QoS , metrics, overprovision)
NeighborList: per-neighbor stats; connectivity. Used to reallocate cells on other links depending on thresholds
QueueList: per-queue stats; traffic load (avg length, avg. age of packets)
COAP-YANG model
OTF asks to add/remove cells (bandwidth) only

15. Triggers
OTF algorithms are event-oriented Reduces power consumption OTF generates events (allocation requests) The relationship: BW <- BWA(B,T,S(B,T)) defines the triggering event. BW: Bandwidth, BWA: Algorithm, T: Track, B:Bundle, S(B,T): Stats for B on T, M(B,T): B size on T.

16. Triggers Event A: New Bundle Request 6top for Stats S (B,T)
Calculate BW allocation according to the Algorithm
Ask 6top to Allocate the BW
Increase the value of M for B on T

17. Triggers Event B: Saturated queue (no cell avail.)
Request 6top for Stats S (B,T)
Calculate BW allocation according to the Algorithm
Ask 6top to increase size of B
If successful, increase the value of M for B on T

18. Triggers Event C: Overprovisioned Bundle
Request 6top for Stats S (B,T)
Calculate BW allocation according to the Algorithm
Ask 6top to decrease size of B to BW
If successful, increase the value of M for B on T

19. Triggers Event D: Underprovisioned Bundle
Request 6top for Stats S (B,T)
Calculate BW allocation according to the Algorithm
Ask 6top to increase size of B to BW
If successful, increase the value of M for B on T

20. Triggers
Event E: Bundle is deleted. No longer used.
Purge M (B,T)

21. Bandwidth Estimation Algorithms
OTF can support different pre-stored estimation algorithms Applied to links between the nodes and its neighbors. Algorithms are numbered 0-255, 0 is reserved to the default algorithm Algorithm selection is done by GET/SET commands.

22. Default algorithm
1- Collect BW requests from child nodes 2- Collect self BW requirement 3- Collect outgoing BW 4- if outgoing<incoming+self, ADD softcells/bundles to satisfy requirements 5- if putgoing>incoming+self, DELETE unused softcells 6 Go back to 1.

23. External CoAP/YANG interface
To select algorithm and provide parameters '6t/e/otf/alg' for SET and GET '/6t/e/otf/alg/par' for Parameters

24. draft-piro-6tisch-security- issues
G. Piro, G. Boggia, L. A. Grieco
23 Jan. 2015

25. General details
title: Layer-2 security aspects for the IEEE e MAC
focus: MAC layer security
IEEE (e) overview
definition of keys
security configurations
key management
current version: 03 (submitted on Dec. 2014)

26. L2 keys (1/2)
master l2 key: initial secret shared among all the motes and configured by the manufacturer or by the network administrator before the network deployment
production network key: secret shared by all the authorized nodes and obtained during the join procedure
per-peer L2 key: negotiated only between a couple of nodes through a KMP strategy

27. L2 keys (2/2)
master L2 key protects enhanced beacon messages and data frames carrying messages exchanged during the join procedure
production network key protects broadcast messages and MAC frames exchanged during the KMP
per-peer L2 key protects messages exchanged between two nodes at the MAC layer

28. Security configurations
Fully Secured network: all the devices forming the network are configured to fully support security services and they have already obtained (or negotiated) all the keys
Unsecured network: security services are not supported
Partial Secured network: only the integrity of message is supported
Hybrid Secured network: a network falls in this configuration when there still are a group of devices that have not yet authenticated by the network (because they have not yet correctly completed the join procedure).

29. Establishing L2 security links

30. Bootstrap of the coordinator

31. Bootstrap of the remote node

32. Join phase
This aspect is investigated in both [I-D.draft-richardson-6tisch-security-architecture] and [I-D.draft-struik-6tisch-security-architecture-elements]
It is out of scope of this Internet Draft
At the end of the join procedure, the "joining node" obtains the "production network key" and updates security MAC attributes as described for the "master L2 key"

33. Key Negotiation Phase Used to negotiate the per-peer L2 key
Messages are exchanged through new Information Elements
Crypto Information Element
Authentication Information Element
It is composed by 6 steps
At the end, nodes has negotiated a link keys from which extracting per-peer L2 keys

34. Key Negotiation Phase - KMP
A sends to B: Cert_A and Rand_A
B sends to A: Cert_B and Rand_B
A and node B computes the PreLinkKey, P_k, by using the ECDH algorithm
A sends to B the authentication parameter as for the Station-To-Station protocol:
AuthField_A = E(P_k, sign)
sign = S(PVK_A, H_128 {P_k || RAND_B || RAND_A})
B sends to A the authentication parameter as for the Station-To-Station protocol:
AuthField_B = E(P_k, sign)
sign = S(PVK_B, H_128 {P_k || RAND_A || RAND_B})
nodes A and B verifies the authenticity of received AuthField parameters (according to the Station-To-Station protocol) and computes the "per-peer L2 key"
L_k = H_128 (i | PAN_ID | P_k).

35. ROLL interim meeting

36. virtual interim meeting for ROLL: Feb10, 2015, 15:00 UTC
Goal: conclude on the approach that we decide to follow for the RPI
Participants: WG members: roll, 6lo, 6tisch, ADs
Links:
Items: Approach to be analyzed (TBD)
1- flow-label approach: TBD the advantages/disvadvantages
2- NHC approach: TBD the advantages/disvadvantages
3- Dispatch approach: TBD the advantages/disvadvantages
4- Consensus time: TBD....
5- Next steps....

37. virtual interim meeting for ROLL: 2015-02-10, 15:00 UTC
The goal of this interim meeting is to do a deep technical dive into the different ways of optimizing the byte/power cost of the RFC6553 (RPI) and RFC6554 (RH3) options.
This could involve compression or recoding, or???
We invite submissions on this. Please post your -00 draft by January 23 if possible, or point us at your other drafts.
We will use JITSI for audio, video and slides, with the following
URL:

38. AOB ?

39. Thank you!