1 / 7

Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)

Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [ IG 6tisch Opening Report for May 2016 Session ] Date Submitted: [ 15 May 2016 ] Source: [ Patrick Kinney ] Company [ Kinney Consulting LLC ] Address [ Chicago area, IL, USA ]

arleen
Download Presentation

Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title:[IG 6tisch Opening Report for May 2016 Session] Date Submitted: [15 May 2016] Source: [Patrick Kinney] Company [Kinney Consulting LLC] Address [Chicago area, IL, USA] Voice:[+1.847.960.3715], E-Mail:[pat.kinney@ieee.org] Re:[IG 6tischOpening& Closing Report for May 2016 Session.] Abstract:[Opening Report for the May Session] Purpose:[] Notice: This document has been prepared to assist the IEEE P802.15. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. Release: The contributor acknowledges and accepts that this contribution becomes the property of IEEE and may be made publicly available by P802.15. <Pat Kinney>, <Kinney Consulting LLC>

  2. IG 6T Meeting Goals (Agenda 15-16-0-00) • Monday 16 May, PM2: • 6tisch issues discussion • Call for adoption for draft-wang-6tisch-6top-protocol-00 • Call for adoption for draft-dujovne-6tisch-6top-sf0-01 • Security – started again • 6tisch-802.15 liaison discussion Slide 2 <Pat Kinney>, <Kinney Consulting LLC>

  3. 6TISCH Issues Discussion • Call for 6tisch WG adoption of draft-wang-6tisch-6top-protocol-00 • Abstract • This document defines the 6top Protocol (6P), which enables distributed scheduling in 6TiSCH networks. 6P allows neighbor nodes in a 6TiSCH network to add/delete TSCH cells to one another. 6P is part of the 6TiSCH Operation Sublayer (6top), the next higher layer of the IEEE802.15.4 TSCH medium access control layer. The 6top Scheduling Function (SF) decides when to add/delete cells, and triggers 6P transactions. Several SFs can be defined, each identified by a different 6top Scheduling Function Identifier (SFID). This document lists the requirements for an SF, but leaves the definition of the SF out of scope. Different SFs are expected to be defined in future companion specifications. Slide 6 <Pat Kinney>, <Kinney Consulting LLC>

  4. 6TISCH Issues Discussion • Call for 6tisch WG adoption of draft-dujovne-6tisch-6top-sf0-01 • Abstract • This document defines a 6top Scheduling Function called "Scheduling Function Zero" (SF0). SF0 dynamically adapts the number of reserved cells between neighbor nodes, based on the currently allocated bandwidth and the neighbor nodes' requirements. Neighbor nodes negotiate in a distributed neighbor-to-neighbor basis the cell(s) to be added/deleted. SF0 uses the 6P signaling messages to add/delete cells in the schedule. Some basic rules for deciding when to add/delete cells and for selecting the cells to be added/deleted within the schedule are also provided. Slide 7 <Pat Kinney>, <Kinney Consulting LLC>

  5. Recharter– SecurityObject Security of COAP for 6tisch Joining Node Join Assistant [Intermediate] Join Coordination Entity POST /join OSCOAP / EDHOC JOIN REQUEST / ACK 2.04 (Changed) POST /6top/… CONFIG K2 / ACK OSCOAP 2.04 (Changed) • Mutual authentication of JN and JCE • based on pre-established node credentials • Establishment of security context (optional) • Secure provisioning of network credentials Secure configuration of K2 on JN Rate limitation for DoS mitigation (e.g. CoAP forward proxy)

  6. start/end states (and costs) of 3 options PSK start state: • each mote is pre-configured with a key, the same key is written in the JCE together with its MAC address end state: • the JCE has authenticated the mote; the mote has authenticated the JCE • the JCE has installed (through secure session with the JN) key K2. This key is then used for link-layer AUTH+ENV CCM* • the PSK enables a session between the node and the JCE. The JCE uses that session to send commands to the mote to (1) rotate K2, (2) change PSK Cost: • 4 packets • Memory: don’t know Protocols: • OSCOAP, EDHOC • Raw Public Key • start state: • ??? • end state: • ??? • Cost: • ??? • Protocols: • ??? • certs • start state: • ??? • end state: • ??? • Cost: • ??? • Protocols: • ???

  7. 6TISCH Issues Discussion – 802.15 liaison discussion At our last meeting in Macau, it was agreed that the IG 6T should increase its scope to include all IETF matters for IEEE 802.15. Additionally, it would be appropriate to change the Interest Group to a Standing Committee. Proposed changes to Operations Manual 7.8 IETF Liaison Standing Committee (SC IETF) 7.8.1 Function 7.8.1.1 The SC IETF is an informal liaison of IEEE 802.15 with IETF to provide information about standards and ongoing activities within IEEE 802.15 to IETF, and to provide information on relevant IETF activities to the IEEE 802.15. 7.8.1.2 An additional function of the SC IETF is to coordinate joint IEEE 802.15 & IETF efforts to implement system and device architectures and interfaces to support an application space. 7.8.2 Operation The SC IETF shall meet at least once during every session and discuss relevant ongoing IETF activities and formulate any messages intended to be sent to the IETF. No messages to the IETF may be sent without approval of the IEEE 802.15 WG. Slide 10 <Pat Kinney>, <Kinney Consulting LLC>

More Related