Presentation is loading. Please wait.

Presentation is loading. Please wait.

23 January 2015 Webex IPv6 over the TSCH mode of IEEE e

Similar presentations


Presentation on theme: "23 January 2015 Webex IPv6 over the TSCH mode of IEEE e"— Presentation transcript:

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!


Download ppt "23 January 2015 Webex IPv6 over the TSCH mode of IEEE e"

Similar presentations


Ads by Google