1. 6tisch Avatar 6tisch
  2. admin
  3. meetings

Wiki

Clone wiki

meetings / 160718_ietf96_berlin

View History

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 <pthubert@cisco.com>
                   Thomas Watteyne <thomas.watteyne@inria.fr>
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
   * <draft-ietf-6tisch-6top-protocol-01>        [15min] (Xavier Vilajosana)
   * <draft-ietf-6tisch-6top-sf0-01>             [15min] (Diego Dujovne)

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

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

Unchartered items, time permitting
   * <draft-satish-6tisch-6top-sf1-01>           [10min] (Satish Anamalamudi)

Any Other Business                                [2min] (Chairs)

Resources

Summary

This summary was posted at https://trac.tools.ietf.org/area/int/trac/wiki/IETF96.

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 directions.

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

Volunteers

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

Minutes

  • [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] <draft-wang-6tisch-6top-protocol-00> (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 quickly.
  • [14.28] <draft-dujovne-6tisch-6top-sf0-01> (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] <draft-satish-6tisch-6top-sf1-01> (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 slotframe.
  • [15.30] Any Other Business (Chairs)
    • Info session on the F-Interop project at 20.30 tonight, including live demo.
    • no other business

Updated