Minutes for 6TISCH at IETF-96

Meeting Minutes IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch) WG
Title Minutes for 6TISCH at IETF-96
State Active
Other versions plain text
Last updated 2016-07-18

Meeting Minutes

   # Minutes, IETF 96 6TiSCH WG Meeting #

Agenda and Meeting information

Meeting        :   IETF96 Monday, July 18, 2016 (CEST)
Time           :   14:00-15:30 Monday Afternoon session I (90min)
Location       :   Room Bellevue, Intercontinental Berlin
Chairs         :   Pascal Thubert
                   Thomas Watteyne
Responsible AD :   Suresh Krishnan
Live minutes   :   http://etherpad.tools.ietf.org:9000/p/notes-ietf-96-6tisch
Live feeds     :   https://tools.ietf.org/agenda/96/#96-mon-1400-6tisch

Other 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                                  [5min] (Chairs)

   Note-Well, Blue Sheets, Scribes, Agenda Bashing

New charter and status docs                      [20min] (Chairs)
   * Status Documents
   * Status 6lo / ROLL
   * Milestones
   * Action Plan

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

   * status of the work and action plan          [10min] (Michael Richardson)

Plugtests News
   * ETSI 6TiSCH/6lo plugtests Results           [10min] (Miguel Angel Reina
                                                         (Maria Rita Palattella)

Unchartered items, time permitting
   *            [10min] (Satish Anamalamudi)

Any Other Business                                [2min] (Chairs)


* agenda: https://datatracker.ietf.org/meeting/96/agenda/6tisch/
* presented slides: (https://datatracker.ietf.org/meeting/96/session/6tisch/


This summary was posted at

6TiSCH had two events at IETF96: the 3-day ETSI 6TiSCH/6lo plugtest [1] and a
90min WG meeting.

During the WG meeting, progress in WG items was observed, technical discussions
took place on adding functions to the 6P protocol
(​https://tools.ietf.org/html/draft-ietf-6tisch-6top-protocol). These changes
are important, but they might mean delaying the delivery of that draft by 1-2
months. The group agreed with the delay considering that the proposed additions
are indeed important. It was observed that the name in the milestone needs to
be udpated as well as the milestone itself.

The fact that SF0 (​https://tools.ietf.org/html/draft-ietf-6tisch-6top-sf0)
does not provide a complete solution since it does not allocate the bundles of
cells that it uses was observed. To be resolved inside or outside SF0 is to be
discussed on the mailing list.

The ETSI 6TiSCH/6lo plugtest was a success. 6P, SF0 and 6BBR were tested. Kudos
to ETSI for the great support!

Security work has started. Michael Richardson presented a status indicating

[1] ​http://www.etsi.org/news-events/events/1077-6tisch-6lo-plugtests
[2] ​https://datatracker.ietf.org/meeting/96/agenda/6tisch/


* Scribes
    * Dominique Barthel
    * Diego Dujovne
* Jabber
    * Ines Robles


* _[14.01]_ Intro and Status (**Chairs**)
   * Thomas presents Note Well, goes over agenda
   * Comment to the agenda?
   > No issues raised. Agenda approved.
* _[14.03]_ Status (**Chairs**)
    * minimal draft going through IESG reveiw
    * 6LoRH passed LC, now at ROLL, waiting for 6lo-paging-dispatch, itself
    missing shepherd review * news from 6man:
        * RFC2460, RFC4291 and RFC1981 bis'ed to become Internet standard.
        Discussion on header insertion. * Some would like to clarify that
        header insertion cannot be done. Would break a lot of stuff. Chime in!
    * 6P protocol
    * security work kickstarted, lead by **Michael Richardson**
    * [**Suresh Krishnan**] minimal draft has to go through IETF last call
    before IESG * [**Suresh Krishnan**] Meeting tomorrow between IEEE and IETF
    management on policy for copyright on IEEE documents. 6tisch-minimal has
    references to copyrighted material from IEEE. * [**Thomas Watteyne**] Xavi,
    can you confirm the minimal draft was reworked to NOT contain copy-paste
    from IEEE specs? * [**Xavier Vilajosana**] confirmed
* _[14.09]_  (**Xavier Vilajosana**)
    * version -01 submitted recently. Used to be -sublayer draft.
    * this text has clarification on 6top concurrent transactions
    * today discuss a few points that came up during ETSI plugtest.
    * 6p command to count cells in the schedule for a link. extend the command
    to get the status in both directions of the link. propose to change name
    from 6p count to 6p status. * 6p list does not paginate. can add pagination
    add an offset for each page. another command: list from A->B and B->A
    (TX and RX) cells. A and B neighbours. * detect if a node and its neighbor
    is consistent after disconnection and restore state or reset. keep the
    status by defining a Schedule Generation * new NO_RESOURCES error: not
    enough cells for request. * consistency: ensure that both ends agree on
    their schedule, especially after disconnection, reboot, etc. Could CLEAR
    and restart the whole process. * Change the seqnum byte to hold a shorter
    seqnum and a 2 bit lollipop counter ("generation" number) for each link
    direction. 3 states: starting, value 1, value2. Once it's going, alternate
    between values 1 and 2. * [**Thomas Watteyne**] what happens when schedule
    unknown Do both ends have to CLEAR? * [**Xavier Vilajosana**] Both have to
    clear. * [**Thomas Watteyne**] this needs to appear in the draft >
    https://tools.ietf.org/wg/6tisch/trac/ticket/43 * [**Thomas Watteyne**] is
    a one-bit counter enough? * [**Xavier Vilajosana**] yes, because
    requirement to have only one transaction on-going. * [**Pascal Thubert**]
    how to know that one or more routers around who has the state about the
    node (me). What to do? TBD * [**Thomas Watteyne**] these are issues that
    arose during the plugtest yesterday. We have not yet discussed them on the
    mailing list. Will do. * [**Pascal Thubert**] this means will probably not
    be done in July as planned. * [**Thomas Watteyne**] help needed? *
    [**Xavier Vilajosana**] if you think our proposals above create issues,
    tell us on the mailing list. If nothing heard, will push a new draft out
* _[14.28]_  (**Diego Dujovne**)
    * this used to be "on-the-fly scheduling". Now default scheduling function,
    aka SF0. * algorithm to measure bandwidth usage (short of having the
    application communicate its requirement to us). * the number of cells is
    converted to the input for the allocation policy * Establish a high
    SF0THRESH for overprovisioning * [**Thomas Watteyne**] don't understand
    drawing on slide 4. * [**Nicola Accettura**, **Pascal Thubert**, **Thomas
    Watteyne**] discussion about how threshold arrow should be drawn one-way,
    going down from current scheduled cells. * [**Thomas Watteyne**]
    Recommendation: convert the figure 4 in 3 sub-figures. One that represents
    the case that there are too many cells, another where there are more cells
    needed and another where the number of cells is fine. Also, draw the THRESH
    as a single-ended arrow. >
    https://tools.ietf.org/wg/6tisch/trac/ticket/44 * whitelist: selection of
    the channel offset randomly. The neighbor selects the cells sequentially in
    case there is a collision. (i,e if the cell is used proposes the next cell
    in the list). * [**Pascal Thubert**] use of blacklist-> administrative
    to reserve some cells. Other more functional to avoid noisy channels,
    etc... Why the concept is comming here? * [**Diego Dujovne**] a black list
    is something that has been allocated to something else. Is a mechanism to
    internally reserve/protect some cells. * [**Pascal Thubert**] there should
    be a mechanism to avoid collisions in the selection/ or to reuse too many
    times the same cell. * Timeout: if no news from neighbor, cancel the state
    requested by command. * There may be concurrent requests from several
    neighbors (NOT concurrent requests for the same neighbor). * these
    concurrent requests may prevent from accepting the requested allocation. *
    Use 1 bit from the metadata field to differentiate between concurrent
    transaction or busy because there are no processing resources. * "No
    processing ressource" means no CPU ressource or other reason, please come
    back later. * "ongoing concurrent transaction" means some other neighbor
    requested cell range that overlap with your request, or somtehing similar.
    * todo: adapt to changes in 6P. Cell relocation: on which PDR? is 20% below
    average (across all cells to same neighbor?) a good value? Cell
    garbage-collection when neighbor has disappeared? * [**Tengfei Chang**] on
    slide 4, how is the number of cells to add/delete computed? * [**Thomas
    Watteyne**] this is essential work, SF0 is meant to be the generic, default
    scheduling. What we need is feedback from implementors and people who
    deploy/test these networks on the performance of SF0. This could be done by
    simulation. * [**Thomas Watteyne**] next we'll have a presentation of SF1.
    Authors of SF1, please position SF1 wrt SF0 so the WG can understand if we
    should merge, pick one, and keep both. * [**Pascal Thubert**] depending of
    node position in the network (center, edge), reaction to cell shortage
    might be different. * [**Xavier Vilajosana**] why differentiate between
    "node busy" and "concurrent transaction"? Will retry in any case. *
    [**Diego Dujovne**] different timeout value
* _[14.58]_ Status of the security work and action plan (**Michael Richardson**)
    * security design team, resumed work in May 2016.
    * -00 draft will be out this week. Table of contents presented here.
    * Explain motivation, assumptions and restrictions. Protocol bandwidth
    conservative join coordination entity to control the joining sequence *
    Code reuse: No security protocol not already used for other purposes (if
    single use, less chances of being maintained, etc). * not reinvent DTLS.
    OSCOAP evolution? * Zero conf: too expensive?. Acceptable. * [**Göran
    Selander**] OSCOAP is an application-layer protocol on top of COSE. We are
    going to ask for adoption in CoRE, which is where it belongs.
    Diffie-Hellman (EDHOC) is less clear. It will be presented in the ACE WG
    meeting this week. * [**Michael Richardson**] again, we'd rather not use a
    protocol that's not already in the device for some other purpose. *
    [**Göran Selander**] used also for firmware updates. You have it already in
    your device. * [**Carsten Bormann**] COSE working group has not finished
    the main task. It will/may? be closed once the main draft is done. * Not
    throw away the good design patterns we had before.
* _[15.07]_ ETSI 6TiSCH/6lo plugtests Results (**Maria Rita Palattella**, on
behalf of **Miguel Angel Reina Ortega**)
    * supported by OpenMote (hardware) and OpenWSN (software)
    * two full days spread over 3 calendar days.
    * test description by Maria Rita, Xavi Vilajosana, Thomas Watteyne and
    Tengfei Chang for 6TiSCH, and Carsten Borman and Kerry Lynn for 6lo. *
    6TiSCH had 20 tests. "85%" interoperability. Tests also prompted for
    improvements in 6P. * 6lo NFC: "80%" interoperability. Sniffing Mechanism *
    6lo BBR: 66%. Actually, many could not be run at all. Most of the tests
    that ran actually worked. * take-aways: advertize event earlier in advance.
    Have a pre-test session. * [**Thomas Watteyne**] discussing with
    Miguel/ETSI about next event, maybe somewhere in Europe in Feb 2017, or at
    IETF meeting in July 2017 (Prague). * [**Pascal Thubert**] thanks to ETSI
    for organizing this!
* _[15.15]_  (**Satish Anamalamudi**)
    * need for SF? end-to-end scheduling for real time applications. Schedule
    isolated traffic flows. * background: RSVP-MPLS and RSVP-GMPLS. * [**Pascal
    Thubert**] in 6TiSCH Architecture, we have notion of a track. Please use it
    in your design. * [**Pascal Thubert**] More than defining the algorithm,
    defining a path here. * each cell is implicit label as per GMPLS. * Satish
    goes through examples of protocol operation. * [**Pascal Thubert**] this is
    not just allocation algorithm, this is path-setup algorithm. We are not
    currently chartered for that. * [**Pascal Thubert**] the group is
    interested, keep working on it, but the WG cannot adopt it (yet). *
    [**Xavier Vilajosana**] many papers of this topic. * [**Xavier
    Vilajosana**] timeslot is enough as a label. * [**Xavier Vilajosana**]
    slotframe ID should be part of label, in case you have more than one
* _[15.30]_ Any Other Business (**Chairs**)
    * Info session on the F-Interop project at 20.30 tonight, including live
    demo. * no other business