Minutes IETF99: 6tisch
IPv6 over the TSCH mode of IEEE 802.15.4e
||Minutes IETF99: 6tisch
# 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
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]
* update security DT and other derived work [15min]
Unchartered items, time permitting
* Innovation Liaison Officer [10min]
* [ 5min]
* [ 5min]
* [ 5min]
Any Other Business [ 5min]
* 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'''
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.
- '''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
- '''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
* 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.
* [14.23] (exp. 14.20) <`draft-ietf-6tisch-minimal-security-03`>
* 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..)
* 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. *
* 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
* (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
* 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`>
* 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.