Minutes IETF99: 6tisch
minutes-99-6tisch-01
| Meeting Minutes | IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch) WG | |
|---|---|---|
| Date and time | 2017-07-17 11:30 | |
| Title | Minutes IETF99: 6tisch | |
| State | Active | |
| Other versions | plain text | |
| Last updated | 2017-07-18 |
minutes-99-6tisch-01
# Minutes, IETF 99 6TiSCH WG Meeting # Note: these minutes are formatted using Markdown. Agenda and Meeting Information ============================== ``` Meeting : IETF 99, Monday 17 July 2017 (CEST) Time : 13:30-15:30, Monday Afternoon session I (120min) Location : Karlin I/II, Hilton Prague, Prague, Czech Republic Chairs : Pascal Thubert <pthubert@cisco.com> Thomas Watteyne <thomas.watteyne@inria.fr> Responsible AD : Suresh Krishnan URLs : http://tools.ietf.org/wg/6tisch/ https://datatracker.ietf.org/wg/6tisch/ https://www.ietf.org/mailman/listinfo/6tisch https://bitbucket.org/6tisch Intro and Status * Note-Well, Blue Sheets, Scribes, Agenda Bashing [ 5min] * Status of the work [ 5min] (chairs) * Summary 1st F-Interop 6TiSCH Interoperability Event [10min] (Maria Rita Palattella) * Summary OpenWSN hackathon [ 5min] (Tengfei Chang) Dynamic Scheduling * <draft-ietf-6tisch-6p-protocol-07> [15min] (Xavi Vilajosana) * <draft-ietf-6tisch-6top-sf0-05> [10min] (Diego Dujovne) Security * <draft-ietf-6tisch-minimal-security-03> [15min] (Malisa Vucinic) * update security DT and other derived work [15min] (Michael Richardson) Unchartered items, time permitting * Innovation Liaison Officer [10min] (Xavi Vilajosana) * <draft-duquennoy-6tisch-asf> [10min] (Simon Duquennoy) * <draft-munoz-6tisch-examples-02> [ 5min] (Jonathan Munoz) * <draft-papadopoulos-6tisch-pre-reqs-00> [ 5min] (Georgios Papadopoulos) * <draft-lijo-6lo-expiration-time-04> [ 5min] (Lijo Thomas) Any Other Business [ 5min] scheduled 120/120 ``` Resources ========= * agenda: https://datatracker.ietf.org/meeting/99/agenda/6tisch/ * meeting material: https://datatracker.ietf.org/meeting/99/materials.html Summary ======= (This summary is also posted in the INT area wiki, https://trac.ietf.org/trac/int/wiki/IETF99) ``` There were 3 6TiSCH-related events at IETF99. The 1st F-Interop 6TiSCH '''Interoperability Event''' (http://www.etsi.org/news-events/events/1197-6tisch-interop-prague-2017) took place on 14-15 July, just preceding the IETF. 16 entities participated, with a test decription focusing on 6TiSCH (RFC8180, draft-ietf-6tisch-6top-protocol, draft-ietf-6tisch-minimal-security) and related security (OSCOAP, EDHOC). 6TiSCH is now supported by all mahor 156 tests were run, 86% of them passing. 6TiSCH-related projects took part at the '''hackathon''', on 16 July. 6TiSCH is now supported on all major open-source implementations: OpenWSN (http://www.openwsn.org/), Contiki (http://www.contiki-os.org/), RIOT (http://riot-os.org/). Further work included full support of the entire 6TiSCH security bootstrap in OpenWSN. The 2h '''WG meeting''' was organized around 3 sections. Dynamic Scheduling - '''TL;DR''': 6P protocol virtually finished, SF0 goes experimental: immediate future work on SF. - `draft-ietf-6tisch-6p-protocol-07` is almost final, with some final suggestions coming out of the plugtests. There was some discussion about the "generation counter" field, which was resolved during a side-meeting later at IETF99. - `draft-ietf-6tisch-6top-sf0-05`: the WG discussed whether to change the status of this draft to experimental. Security - '''TL;DR''': minimal-security stable and implemented, several complementary work, concern about EDHOC not having a home at IETF. - `draft-ietf-6tisch-minimal-security-03`: the complete solution was shown to work at the plugtests. There were discussion about the fact that, after 5 hops, the solution requires 6LoWPAN fragmentation. The chairs expressed concern about the fact that EDHOC still has no home at the IETF. - `draft-ietf-6tisch-dtsecurity-secure-join`: optimized procedure of ANIMA BRSKI for 6TiSCH - `draft-richardson-6tisch-join-enhanced-beacon`: an additional header in the beacons to configure nodes to serve as join proxies or not. 10 people thought it's a good idea to adopt the draft, none against. - `draft-richardson-6tisch-minimal-rekey`: COMI-based rekeying Unchartered items - '''TL;DR''': lots of new work around 6TiSCH - `draft-duquennoy-6tisch-asf-00`: interesting new SF concepts, chairs encourage authors to continue working on it - `draft-munoz-6tisch-examples-02`: important support document, discussion about where/how to publish it - `draft-papadopoulos-6tisch-pre-reqs-00`: new concept, no time to discuss - `draft-lijo-6lo-expiration-time-04`: not presented (out of time) ``` Volunteers ========== * notetaker 1: **Dominique Barthel** * notetaker 2: **Francesca Palombini** * notetaker 3: **Xavi Vilajosana** * Jabber scribe 1: **Michael Richardson** * Jabber scribe 2: **Ines Robles** Minutes ======= * Intro and Status * [13.30] (exp. 13.30) Note-Well, Blue Sheets, Scribes, Agenda Bashing * Meeting starts. * **Pascal** reminds of Note Well. * Minutes are taken. * Jabber scribes. * Agenda is presented. Includes summary of ETSI plugtest and hackathon developement. * Dynamic Scheduling items * Security work * Time permiting to discuss other new drafts. New SF. (ASF), Examples for 6tisch, Replication and elimination at 6tisch. expiration time, happening at 6lo but relevant to 6tisch * IEEE update at the end. * [13.35] (exp. 13.35) Status of the work (chairs) * two RFCs came out of this group: * RFC8137, IEEE802.15.4 IE ID 5 reserved for IETF * RFC8180, minimal 6TiSCH * update milestone for security work. Suresh will approve it once updated. * after the security work, we can think what is next for the group * [13.36] (exp. 13.40) Summary 1st F-Interop 6TiSCH Interoperability Event (**Maria Rita Palattella**) [10min] * Presenting 6TiSCH ETSI F-Interop event: * 16 participant companies. * 5 6TiSCH completely different implementations * multiple different platforms under test. * There were 16 tests. Evaluated RFC8180, 6top protocol, security at L2 and minimal-security draft * Event run for 1.5 days. All day test sessions. Final wrap-up session. * OSCOAP was also tested in parallel in the same event (4 implementations tested) * reported results at ETSI TRT tool. Results are 85,9% test passed. 14.1% failed. 36,5% tests were not applicable to platforms due to that some implementations were missing. * demonstrates that 8180 is complete and works in all implementations that were tested * **Thomas**: if the implementation does not implement the features, the test was reported as N/A. Requested that a test that was attempted and did not pass be reported as Fail. * F-Interop: will shortly provide a range of protocol tests, on the Internet. * including (6tisch, coap, lorawan, lwm2m, OSCOAP, EDHOC, 6LoWPAN, etc) * RFC8180 works in all implementations * minor suggestions to 6p * return NORES when the ADD request cannot allocate ANY of the requested cells. * **Tengfei**: question on NORES * **Thomas**: Will be addressed later in Xavi's presentation, please raise then. * Next plugtest will be remote. the date will be announced soon. * Please provide suggestions on how to improve F-Interop * Suggestions and comments about the event during the fall please send them to F-Interop coordinators or 6TiSCH chairs. * [13.49] (exp. 13.50) Summary OpenWSN hackathon (**Tengfei Chang**) * about same participants as to the Plugtest * adaptation of RIOT to integrate OpenWSN * integration of OpenWSN into RIOT. * F-Interop: improving the bootstrap of test sessino. * Join Security: finalized the join procedure implementations (cleaned up). Full 6TiSCH solution including bootrap already implemented in OpenWSN * OpenWSN: some fixing and cleanup on OpenMote annd TelosB, added PIO and Cong Option in RPL DIO (RFC6550) * Fixing some RPL issues in DIO. * Dynamic Scheduling * [13.53] (exp. 13.55) <`draft-ietf-6tisch-6p-protocol-07`> (**Xavi Vilajosana**) * draft is stable, several implementations exist, including Open Source ones * 5 implementations tested at the 6TiSCH plugtest * goal: summarized updates in the last month and go for WGLC * since last version, addressed comments, improved general text. * 6P ADD: command currently always return success, even if no cell was allocated. Need to look at list returned. Use NORES response code? * **Tengfei**: NORES means something else. Should create another return code for this case. * **Thomas**: new return code could also say "partial". The idea was to reuse existing code. * **Xavi**: don't see any problem in allocating a couple more. * GEN errors: currently specifies that a CLEAR should be issued, this is costly. Propose to do something more subtle for LIST and COUNT operations. * The return code can allow to correct the requester node allocation. * 1st bullet (slide 6) is already in the draft, we propose to add the rest (slide 6) * **Thomas**: comments form implementors? * **Yatch**: proposal to throw away the GEN management. In all cases, node can detect there is an inconsistency. * **Xavi**: this is safer in terms of consistency. Your proposal force to issue LIST and COUNT often. * **Yatch**: point is timeout could be useful in this case. * **Thomas**: counter example: the problem with that is when the ACK is lost, which is not detected with your proposal. * **Yatch**: timeout, I will detect Ack not received * **Thomas**: let's discuss this issue at a side meeting this week. * Xavi asks for WGLC * **Thomas**: we have to have the discussion first, resolve all the plugtest outcome and then we can go for WGLC * **Pascal**: this draft uses IE. IEEE has created 15.12 group, integrating the concept of 6P, include it in their design. * **Pascal**: maybe Charlie can talk about it the AOB * **Charlie**: nothing to say * [14.07] (exp. 14.10) <`draft-ietf-6tisch-6top-sf0-05`> (**Diego Dujovne**) * lot of revisions, we have gone through a lot of comments * several pieces of text moved from Intro to their respective sections. * better explanation of difference between allocated and scheduled cells * cell usage is measured on last slotframe * better explanation of overprovisioning * relocation: SF0 decides when relocation is activated. Replacement cells are selected randomly. SF0 does not retry the relocation if it fails. Will be evaluated later. * no retransmission by SF0. If request fails, reassess need. * simplify triggering event, reduced to one: number of cells used during last slotframe. * added flow diagram * better explained difference between OVERPROVISION and SF0THRESH. OVERPROVISION is about how many cells to request, SF0THRESH is about when to send request. * Error handling by the SF. When an error occurs there is no retry. It will be decided what to do at the next slotframe (or whenever the SF is triggered again). * timeout value is per transaction * PDR is calculated per cell. * clarified situation at boot: SF0THRESH cells need to be allocated. * **Thomas**: who has it implemented? * **Tengfei**: implemented an old version of the draft on OpenWSN * **Yatch**: same on Contiki * **Thomas**: what is needed is results (either simulation or experiment). More than editorial changes. * **Pascal**: how to avoid oscillations, etc. We need to have this tested and used. * **Thomas**: pb having SF0 (the default SF) being experimental. What message does it send out? * **Xavi**: evaluate interaction of SF0 and 6P. Delay in having request sent out. * **Suresh**: if not this then what? what becomes SF0? Secondly: I would like to see an experimental. I think it is more valuable to document the experiment. I would support if you decide to do that. * Security * [14.23] (exp. 14.20) <`draft-ietf-6tisch-minimal-security-03`> (**Malisa Vucinic**) * Minimal security is presented by Malisa * One touch procedure to handle the join procedure * completely implemented in OpenWSN * ongoing implemention in Contiki based on PSK * Updates based on implementation experience: * communication procedure during the join process: * clarification to be done * One hop with the JP. The JRC is the central entity management the join process (remote). * Join is handled using link local addresses. * Path between Pledge and JP is insecure (Secexempt mechanism used). * Frames are sent in clear at L2. They are however protected at higher layers using OSCOAP. * Security handshake is done using EDHOC. Reduced the protocol overhead by have the Pledge initiates the EDHOC handshake. JRC responds with an optional ACK. Defined in COAP. the response can tell (wait until I respond you). This can be used to mitigate the load in the network. Optional with Pre-shared keys. Is mandatory with asymmetric keys * JP forwards statelessly to JRC. * Optimization done when JRC is collocated with the dagroot. The IPv6 address of the JRC is implicit as it is the same as the DODAGID. Then this one can be used. * Symmetric encryption may use the same hardare as L2 CCM security. * question on what mechanism support (256 bit..) * Status: * OSCOAP implemented in Python. * OSCOAP in C * draft fully implemented in OpenWSN * Contiki implementation ongoing, interop with OpenWSN partially tested in the Plugtest * Issue: packet size downstream (join response payload). May require fragmentation. (5 hops tested). * implementation experience: Join Response too big to fit in 15.4 frame (especially close to the Dagroot because of source routing) * Malisa shows packet dissection. To make it fit, used CoAP Token Length of 0. no content format. * The pledge contains the message id * **Michael**: DAO projection may shorten the routing header. * **Pascal**: First to look at the way you allocate your 6LoRH, see 4 bytes. * **Malisa**: did not implement the switch from long to short MAC address in OpenWSN yet. * **Pascal**: draft at ROLL, could allow to shorten this header even more. DAGroot controls how much state stored along path. * **Malisa**: this is orthogonal to what this draft addresses. What is not implemented is the assignment of short addresses in the stack * **Thomas**: are your results showing 64b MAC addresses? * **Malisa**: yes * CBOR encoding of the join response, quite a big overhead, one proposal would be to use a binary encoding to compress the COSE object. * also, we look at how to dynamically configure the network to accept or not insecure join frames. We could assume one flag used to signal that the join process is allowed. Use an IE that enables to signal that. * **Pascal**: on top of binary switching on/off, you need to "throttle": limit the rate of packets proxied by the JP accepted per unit of time. It's very classical to have a few words to mention that the implementation should throttle. That's all you need. * **Thomas**: +1, you could just add 1-2 sentences that mentions the term "throttle" * **Thomas**: we will wait for new update before WGLC * **Pascal**: there will be a lunch on Wednesday deciding if and where the EDHOC document will be endorsed in the IETF * [14.43] (exp. 14.35) update security DT and other derived work (**Michael Richardson**) * [14.43] `draft-ietf-6tisch-dtsecurity-secure-join` * Zero-touch join protocol. Optimized procedure for 6TiSCH. Similar to ANIMA. * ANIMA voucher document is in almost WGLC, GRASP is in RFC queue. * ANIMA BRSKI doc rewrittten, shorter. Our parallel 6TiSCH document. * 6TiSCH document to be rewritten in same style as improved version in ANIMA. * come Wednesday morning for ANIMA meeting. * Area directors will find a WG to adopt the EDHOC work. * Next steps * BRSKI vs 6TiSCH zero touch protocol * TLS -> EDHOC * HTTP -> CoAP * minimal security join request bootstrapp * need to change the name of the document. Include zero touch words. * Enhanced beacon document now out, allows to define code to indicate if join is allowed or not. * [14.??] `draft-richardson-6tisch-join-enhanced-beacon` * also a bit to announce a router. Saves the cost of multicast router discovery. * **Pascal**: we need a draft at ROLL. DAGroot announces it is a JRC. Propagate value in DIO. * **Pascal**: prefrence: in DIO. * **Pascal**: preferences will reduce (at least, not increase) moving away from the root * **Michael**: on low battery: EB value lower. * **Pascal**: what you announce on your DIO and what you announce on your EB are orthogonal * **Michael**: Agreed * **Thomas**: Don't see why we should mix this with RPL. Some 15.4 TSCH networks don't run RPL at all. * **Pascal**: let's continue this on the mailing list anyway. * **Malisa**: agree on L2 view. When to accept insecure packets at L2 should be addressed at L2. * **Pascal**: global knowledge can be achieved through a propagation mechanism. Learning has to be done from the L3 parent. * **Michael**: Good point (need to learn from L3 parent). * **Michael**: should we define a L3 object at the same time in this document? * **Suresh**: No global preference, both ways can be done. * **Michael**: this document has not been adopted, so it would be good to adopt as is. * **Michael**: will write another document about L3 option * **Thomas**: would like to get a feel from the room if adopting is a good idea. * **Thomas**: Who read the draft? * (around 10 hands up) * **Thomas**: Who thinks adopting the draft is a good idea? * (around 10 hands up) * **Thomas**: Who thinks adopting the draft is NOT a good idea? * (no hands up) * **Pascal**: Will confirm in the mailing list * [14.??] `draft-richardson-6tisch-minimal-rekey` * scenario is: deploy new set of keys, call for the switch. * COMI based. * why rekey? some nodes gone bad and want to get rid of them. * please comment if this belongs to this working group * Unchartered items, time permitting * [15.05] (exp. 14.50) Innovation Liaison Officer (**Xavi Vilajosana**) * skipped due to lack of time. * [10.05] (exp. 15.00) <`draft-duquennoy-6tisch-asf-00`> (**Simon Duquennoy**) * New scheduling function: Autonomous Scheduling Function (ASF). * Slotframes autonomous cells. * Cells are maintained with the information of neighors. * 1 slotframe for traffic plane * TSCH sync * RPL control * application * Slotframes are isolated so they do not interact. Length dimensions the schedule. * All is distributed. Very extensive experimentation. Several hundreds of nodes. RPL in storing and non-storing modes, up and downward traffic * Major limitations: * highly suboptimal. * cells are shared and not cascaded * 3 types of slotframes. * type 1 is like RFC8180 (minimal), a shared slot and is used as a rendez-vous slot. Used as broadcast slot and rendez-vous slot. * for each slotframe a subset of the ch.offsets are used. * type 2 is receiver-based unicast communication. For each neighbor, the hash of the MAC is the transmit cell with that neighbor. A node sets the hash of its own address as a RX cell. * type 3 is sender based slotframe. This is used for privileged nodes (e.g. time source). * recommends sizes of the different slotframes be co-prime. * Status is: * description of slotframe types * definition of cell coordinates (hashing of MAC address) * Example schedule with 4 slotframes * definition of configuration parameters * **Pascal**: different slotframes for different priorities. Radio collisions. Could one time-synch the higher priority slotframes earlier so that they get CSMA advantage. * **Thomas**: time skewing is not possible. * Open Issues: How to distribute the configuration of these slotframes? * Proposal of a new EB IEs * other options, use 6P commands, overloading some of the parameters. * has been evaluated experimentally. * [15.16] (exp. 15.10) <`draft-munoz-6tisch-examples-02`> (**Jonathan Munoz**) * updated a draft submitted some time ago. * provide a reference for new implementers. * show the frame formats. * uses OpenWSN to generate the packets and Wireshark to parse and format them. * Lists the content of all packets implementing 6TiSCH documents. * Jonathan goes through description of one Wireshark output. * next steps: -03 to be delivered this week including 6P LIST command. * **Thomas**: yes, it's a copy paste exercise of the Wireshark output, but: * it was used extensively at the last plugtest. very useful * it is useful presenting the packet content. we might adopt it. * **Pascal**: Suresh what do you think? * **Suresh**: I leave it up to you, but the guideline that I use is: do you think this is going to be useful 5 years from now? If not, keep it as a wiki page. You need to guauge the archival value of this. * **Pascal**: would this doc benefit the RPL info document? Could this text be an appendix to `draft-ietf-roll-useofrplinfo`? * **Michael**: yes it would benefit it. And it would be useful in 5 years. We need to make it clear that this is for 6TiSCH (L2) * [15.24] (exp. 15.15) <`draft-papadopoulos-6tisch-pre-reqs-00`> (**Georgios Papadopoulos**) * determinism, pre-defined and constant delay: multi-path transmission and redundancy elimination * need to transmit to RPL best parent and alternate parent. Need to address ACK collision, if both ACKs transmitted. * Requirements: alternative parent selection (changes in DIO), dual-cast, ACKs, redundancy elimination * **Thomas**: volunteers to read and review? * (4 hands up) * <`draft-lijo-6lo-expiration-time-04`> (**Lijo Thomas**) * Skipped for lack of time * Any Other Business * **Maria-Rita**: will present at 6pm in Paris room results of European project on app protocols on satellite networks. * **Pascal**: Bob Heile sent slides with an IEEE activity update.