Minutes IETF100: 6tisch
IPv6 over the TSCH mode of IEEE 802.15.4e
||Minutes IETF100: 6tisch
# Minutes, IETF 100 6TiSCH WG Meeting #
Note: these minutes are formatted using Markdown.
Agenda and Meeting Information
Meeting : IETF 100, Monday, November 13, 2017 (+08)
Time : 15:50-17:20 SGT, Monday Afternoon session II (90min)
Location : Bras Basah, Raffles City Convention Center, Singapore
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]
* draft-ietf-6tisch-6top-protocol [10min]
* draft-ietf-6tisch-minimal-security [15min]
* draft-ietf-6tisch-dtsecurity-zerotouch-join [10min]
* draft-ietf-6tisch-6top-sfx [ 5min]
Unchartered items, time permitting
* draft-chang-6tisch-msf [15min]
* draft-satish-6tisch-6top-sf1 [10min]
(Bing Liu - Remy)
* draft-richardson-6tisch-roll-join-priority [ 5min]
Any Other Business, IEEE status
* agenda: https://datatracker.ietf.org/meeting/100/materials/agenda-100-6tisch/
* meeting material: https://datatracker.ietf.org/meeting/100/materials.html
_(This summary is also posted in the INT area wiki,
The 6TiSCH working group has a stable set of "6TiSCH Minimal" specifications:
- `6tisch-minimal` (RFC8180)
This forms a complete protocol stack, which can be implemented and benchmarked.
Ongoing work in the WG focuses on augmenting this "Minimal" solution with:
- additional Scheduling Functions
- zero-touch security
- optimizations related to routing and beaconing
7 drafts were presented t IETF 100, both related to the 6TiSCH Minimal specs
and its extensions
- `draft-ietf-6tisch-6top-protocol` transitioned to AD Evaluation status.
The draft is stable and has been implemented and tested.
The WG is waiting for reviews, in particular from the IoT-dir
- `draft-ietf-6tisch-minimal-security` is, pending the description of DSCP
bits, ready for WGLC.
The WG believes that the next revision will be ready for WGLC.
- `draft-ietf-6tisch-dtsecurity-zerotouch-join`: the work is progressing fast.
The WG acknowledged the good progression of the work.
- `draft-ietf-6tisch-6top-sfx`: some editorial changes are needed because this
(experimental) draft can go into WGLC.
The chairs believe the WGLC period will be opening before IETF101.
- `draft-chang-6tisch-msf`: this specification is part of the Minimal 6TiSCH
2 implementations already exist.
The chairs are confident this solution will be stable before IETF101.
- `draft-satish-6tisch-6top-sf1`: the draft is important for the WG, but
several key points lack specifics.
The chairs recommended for the authors to continue the work.
- `draft-richardson-6tisch-roll-join-priority` was not presented due to lack of
* notetaker 1: **Dominique Barthel**
* notetaker 2: **Federico Sismondi**
* Jabber scribe: **Ines Robles**
* **Rahul** to send pointer of LWIG draft to 6TiSCH ML.
* **Malisa** to update minimal-security draft and ask for WGLC afterwards.
* TOS bits change
* **Diego** to update SFX draft:
* no more mentions of SF0
* **Tengfei** to update MSF:
* "NumCellsElapsed" rather than "NumCellsUsed"
* when inconsistency detected the 6P CLEAR req and response shound be
exchanged in the minimal cell * limit backoff exponent on dedicated cells
as only 2 nodes discussing
* **Thomas** to provide feedback about draft-satish-6tisch-6top-sf1 on 6TiSCH
* _[15.52]_ (exp. 15.50) Start of meeting
* _[15.52]_ (exp. 15.50) Intro and Status
* Note-Well, Blue Sheets, Scribes, Agenda Bashing
* Status of the work
* "Minimal 6TiSCH" solution ready
* now, two focus points:
* outside of IETF: facilitating market adoption through
benchmarking, providing open-source implementations, interop
testing and conformance tools, etc. * inside of IETF: build new
technologies. We need to think about rules for adopting further
work, so it fits well and extends what exists.
* [**Pascal**] DIO and Fast ReRoute work to be done in ROLL, we'll be
asking for it. EB at IEEE, etc. First define the need, here.
* _[16.00]_ (exp. 16.00) draft-ietf-6tisch-6top-protocol (**Xavi Vilajosana**)
* stable , v-9
* all proposed cells in the list are equivalent, no priority meaning
attached to order. * inconsistency: use of a Sequence Number to detect
it. Many situations would lead to inconsistencies, some examples
provided. * clarified use of Error Codes. Listed them all in a Table.
* answers discussion in Prague, document seems stable, already two
implementations, one more coming
* next step is to receive review from IoT Directorate
* _[16.09]_ (exp. 16.10) draft-ietf-6tisch-minimal-security (**Malisa Vucinic**)
* -04 published in october.
* fully relies on PSK, zero-touch draft deals with certificates
* Update #1: Key/Nonce derivation
* changes induced by changes in OSCORE. Nonces constructed differently.
Explained on slide 4 and following. * Join request defined from what's
been standardized by OSCORE * Join request/response use now same
nonces, again, changes come from what's been defined by OSCORE
* Update #2: Error handling: opened DoS attack opportunity.
* solution from -04: use non-confirmable CoAP msg for join request. In
case of an error, JRC doesn't reply. No DoS attacks, but forces pledge
to implement retransmission at the app layer.
* [**Thomas**] clarifying question: pledge sends a Join Request, if
anything wrong, won't get back any response. Only Join Response if
everything correct. * [**Malisa**] yes. * [**Michael**] through Meetecho
* `@Thomas`: if it's the wrong network, then you have to timeout. But
you had to do that anyway, because you can't trust the negative reply
* [**Thomas**] through Meetecho chat
* `@Michael`, agreed
* update #3: Join Request Retransmissions. Retransmission counter, timeout
doubled at each attempt (similar to RFC7252). * [**Michael**] through
* `@Thomas`, previously the reliability came from the "TCP" layer
(which is actually CoAP), now it comes from the application
* [**Thomas**] through Meetecho chat
* yep, understood
* [**Pascal**] new way to improve SF, with several traffic classes, respond
differently to each class. * [**Rahul**] slide 9 neighbor cache increase.
Please see LWIG draft which describes this. Will send pointer on the ML. *
[**Pascal**] will next version be ready for last call? * [**Malisa**] will
be writing soon a new version, and go from there to WG last call *
[**Pascal**] about dependence on normative work OSCORE? * [**Goran**]
OSCORE not is WGLC yet * [**Michael**] through Meetecho chat
* `@Goran`, but MISSREF will sort out the timing, if the documents are
* [**Suresh**] difficult to synchronise these two drats. Cannot do
cross-area synch. * [**Michael**] through Meetecho chat
* Suresh, but zerotouch-join still uses certificates, and could depend
* [**Thomas**] should the TOS bits change be done in minimal-security
draft, of a new draft? * [**Pascal**] same draft. Just indicate which
classes the Join traffic should be part of.
* _[16.34]_ (exp. 16.25) draft-ietf-6tisch-dtsecurity-zerotouch-join (**Michael
* -01 version syncs with ANIMA BRSKI -09
* can be read standalone
* voucher uses YANG/CBOR, hoping -core-sid to progress.
* [**Goran**] what's going on right now is a comparison between DTLS and
EDHOC handshake, we are going to have a interim with a proposal about the
comparison between EDHOC handshake and the other mechanism * DTLS has DDoS
mitigation mechanism that involves another round-trip, to decide whether we
turn this on. * dependencies to CORE (SID), ACE (EST over CoAP), to 6TiSCH
as well (outsourced work). * looking for additional co-authors and
reviewers * [**Peter**] will have meeting, discuss EST/CoAP, decision to
put in separate doc, will keep you updated.
* _[16.42]_ (exp. 16.35) draft-ietf-6tisch-6top-sfx (**Diego Dujovne**)
* status: was on-the-fly scheduling and scheduling function zero (SF0)
* on-the-fly experimental results
* [**Pascal**] make sure to clean out draft for mentions of SF0.
* analyzed allocation stability: added feature in SFX compared to SF0.
* review in May and associated comments submitted in sf-05. More comments?
Ready for WGLC? * [**Thomas**] I have some editorial comments we have to go
through. Should be done before considering WGLC. * [**Thomas**] changing
mind on SF nomenclature. No longer use numbers, would be getting ahead of
IANA work. * [**Lijo**] through Meetecho chat:
* do you have some experimental results?
* _[16.50]_ (exp. 16.40) draft-chang-6tisch-msf (**Tengfei Chang**)
* Minimal SF (aka MSF). Uses 6TiSCH-minimal RFC.
* organizes the use of minimal (shared) cell.
* describes node behavior at Boot (minimal-security compliant)
* describes 7 steps at boot
* dynamic scheduling , explains reasons for for adding removing cells
* adapt to traffic: maintain 2 counters, NumCellsUsed and NumCellsPassed
* [**Thomas**]: recommendation to rename latter to NumCellsElapsed
* running code:
* implemented in 6TiSCH simulation
* implemented in OpenWSN
* works! more results coming
* [**Pascal**] will be a need to identify Class for Join traffic.
* [**Pascal**] describe the values used on per classed basis (4,12,16).
* [**Simon**] through Meetecho chat
* is the dedicate cell both TX and RX?
* [**Tengfei**] yes
* lessons learned from implementation:
* when inconsistency detected the 6P CLEAR req and response shound be
exchanged in the minimal cell * limit backoff exponent on dedicated
cells as only 2 nodes discussing
* [**Charlie**] what causes the scheduling inconsistency?
* [**Thomas**] will take this offline.
* [**Thomas**] congrats to you and Malisa to implemt this in two weeks!
* Additional discussion on Meetecho chat
* [**Diego**] would it be nice to see traffic burst conditions on the
experiments * [**Malisa**] we did this in the simulator. Results on the
simulation result slide * [**Diego**] yeap, but the experiments are the
ones which suffer real conditions * [**Malisa**] how the algorithm
converges can also be seen in the simulation * [**Diego**] in fact, the
code is different between 6tisch simulator and openwsn * [**Malisa**]
and also how it adapts to the bursty traffic[17:12] * [**Xavi**] I
think that the simulation can bring more information as we can reach
the limits * [**Malisa**] could be, we implemented independently *
[**Xavi**] the real conditions are really constrained by the setting *
[**Malisa**] this is still preliminary * [**Diego**] exactly. but the
platform can be used to generate more realistic conditions *
[**Malisa**] realistic in what sense? link-layer drops? traffic
pattern? * [**Diego**] traffic pattern generation, phy-layer
interference * [**Malisa**] I agree we can't have completely realistic
behavior on the link but we do introduce drops probabilistically in the
simulator. However, I don't see any difference in how you generate
traffic between the simulator or a real app. * [**Diego**] when you
generate real traffic, it goes through the stack on every node and
suffers processor limitations, plus other resource clogs which are not
seen on the simulator * [**Malisa**] if a node transmits periodically
with a period on the order of 15s, I am not sure how much does
processing delay on the order of ms affect the traffic pattern in the
* _[17.10]_ (exp. 16.55) draft-satish-6tisch-6top-sf1 (**Bing Liu - Remy**)
* SF1: reserve track to destination multiple hops away
* describes end to end operation (slide 3)
* describes PATH and RESV messages (slide 4)
* 3 step transaction for one-hop operation, notes that could be done in 2
steps * presents state transition diagram for downstream node * next steps:
complete definition, cover error handling, SF behaviour when node boots,
security and examples * [**Thomas**] I have a some comments but let's
discuss it later as running out of time..
* draft-richardson-6tisch-roll-join-priority (**Michael Richardson**)
* skipped because of lack of time
* _[17.19]_ (exp. 17.10) Any Other Business
* no other business raised in room
* _[17.20]_ (exp. 17.20) End of Meeting