Minutes IETF99: 6tisch

Meeting Minutes IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch) WG
Title Minutes IETF99: 6tisch
State Active
Other versions plain text
Last updated 2017-07-18

Meeting Minutes

# 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
                   Thomas Watteyne
Responsible AD :   Suresh Krishnan
URLs           :   http://tools.ietf.org/wg/6tisch/

Intro and Status
    * Note-Well, Blue Sheets, Scribes, Agenda Bashing           [ 5min]
    * Status of the work                                        [ 5min]
    * Summary 1st F-Interop 6TiSCH Interoperability Event       [10min]
      (Maria Rita Palattella)
    * Summary OpenWSN hackathon                                 [ 5min]
      (Tengfei Chang)

Dynamic Scheduling
    *                         [15min]
      (Xavi Vilajosana)
    *                            [10min]
      (Diego Dujovne)

    *                    [15min]
      (Malisa Vucinic)
    * update security DT and other derived work                 [15min]
      (Michael Richardson)

Unchartered items, time permitting
    * Innovation Liaison Officer                                [10min]
      (Xavi Vilajosana)
    *                               [10min]
      (Simon Duquennoy)
    *                           [ 5min]
      (Jonathan Munoz)
    *                    [ 5min]
      (Georgios Papadopoulos)
    *                        [ 5min]
      (Lijo Thomas)

Any Other Business                                              [ 5min]

                                                      scheduled    120/120


* agenda: https://datatracker.ietf.org/meeting/99/agenda/6tisch/
* meeting material: https://datatracker.ietf.org/meeting/99/materials.html


(This summary is also posted in the INT area wiki,

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.

- '''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) ```


* notetaker 1:     **Dominique Barthel**
* notetaker 2:     **Francesca Palombini**
* notetaker 3:     **Xavi Vilajosana**
* Jabber scribe 1: **Michael Richardson**
* Jabber scribe 2: **Ines Robles**


* 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
            * 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
    * [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,
        * 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
        * 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
            * 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
        * 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
            * **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
        * [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
        * 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
            * Proposal of a new EB IEs
            * other options, use 6P commands, overloading some of the
       * has been evaluated experimentally.
    * [15.16] (exp. 15.10) <`draft-munoz-6tisch-examples-02`> (**Jonathan
        * 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
        * 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,
            * 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.