* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

6tisch Status Pages

IPv6 over the TSCH mode of IEEE 802.15.4e (Active WG)
Int Area: Suresh Krishnan, Terry Manderson | 2013-Oct-08 —  

IETF-99 6tisch minutes

Session 2017-07-17 1330-1530: Karlin I/II - Audio stream - 6tisch chatroom


minutes-99-6tisch-01 minute

          # 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'''
          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 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)  (**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
                      * 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)  (**Diego Dujovne**)
                  * lot of revisions, we have gone through a lot of comments
                  * several pieces of text moved from Intro to their respective
                  * 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
                  * **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)  (**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
                      * 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
                          * (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
                  * skipped due to lack of time.
              * [10.05] (exp. 15.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
                      * Proposal of a new EB IEs
                      * other options, use 6P commands, overloading some of the
                 * has been evaluated experimentally.
              * [15.16] (exp. 15.10)  (**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
                  * Jonathan goes through description of one Wireshark output.
                  * next steps: -03 to be delivered this week including 6P LIST
                  * **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)  (**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)
              *  (**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.

Generated from PyHt script /wg/6tisch/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -