Clone wiki

meetings / 130301_webex

Minutes Webex 01 March 2013, 6TSCH group

Note: timestamps in PST.

Present (alphabetically)

  1. Alfredo Grieco
  2. Herman Storey
  3. Maria Rita Palattella
  4. Normann Finn
  5. Pascal Thubert
  6. Qin Wang
  7. Raghuram Sudhaakar
  8. Thomas Watteyne
  9. Tina Tsou
  10. Tom Phinney
  11. Xavi Vilajosana


  • Presentation of the backbone router draft [15min]
  • 6tus [15min]
    • thoughts on where 6tus fits in architecture
    • thoughts on where 6tus fits in 6tsch work
  • mailing list topics [30min]
    • Broadcast channels
    • Mapping channels to flows
      • DIS, DIO, DAO, ND, hard-reserved, lazy-reserved, best-effort

Minutes: [09.03] meeting starts [09.03] Move phone call to 1h earlier? [Pascal] * Pascal has gotten unicast requests for this change, especially from Asia * Pascal asks for rough consensus on phone call. * rough consensus reached * Pascal to ask same question on ML before rescheduling Backbone Router Presentation [Pascal] * Pascal presents using slides: * Goal of BR: * several independent wireless mesh networks appear as one IPv6 subnet (i.e. share same /64 prefix). * allows a mote to move from one mesh network to other without requiring a new IPv6 address * works with different technologies: RPL, 6LoWPAN, other. * Each "root" of a mesh network (6LBR, RPL root, etc) is a BR * BRs are connected by a Transit Link, i.e. they live in one broadcast domain * each BR serves as an ND proxy for the motes in its mesh. * draft specifies how BRs claim and defend addresses, and how resolutions are revolved * Clarifying questions: * [Thomas] requirements on transit link? [Pascal] broadcast domain, same as regular ND Thoughts on 6tsch and 6tus [Thomas] * Thomas presents thoughts of what 6tus is and how fits in 6tsch architecture using slides: * Many scheduling policies exist which are valid and should be supported: * centralized scheduling engine (i.e. PCE) * distributed approach (i.e. RSVP) * 6tus introduces the distinction between hard and soft links (which becomes an extra flag in TSCH links): * 6tus will not move hard links. These are typically installed by a PCE. * 6tus will monitor and if necessary move soft links. * 6tus defines the mechanism on which policies can build: * commands which can be called by upper layer (API) * header formats (6tus defines 3 new IEs) * protocol for neighbor motes to negotiate adding/delete/moving links. * Remarks: * [Pascal] "link" is used everywhere, we need a better name for it. "slot"? "cell"? * [Pascal] 6tus should introduce the concept of virtual bandwidth (similar to virtual memory): the routing layer should consider having some bandwidth, but only part of it can be scheduled at some time. Extra bandwidth can be scheduled on-the-fly, or some overflow mechanism can exist. * [Pascal] in a PCE setting, the PCE should not have to contact both A and B to establish an A->B link. Instead, it should only contact mote A, which should use 6tus to propagate request to mote B. * [Maria Rita, Qin, Xavi, Pascal] In a PCE setting, it is important that the PCE knows as much as possible to handle QoS (e.g. schedule more links that required). 6tus should contain some feedback mechanism to the PCE. * [Pascal] 6tus should discuss how to handle DIS. [09.54] Liaison work [Pascal] * ISA100.20 * ISA100.20 is looking for a format to send commands from system manager to motes. * Thinking about CoAP, EXI, netconf. * [Thomas] Who could be liaison? * [Pascal] options are Pascal, Pat Kinney, Herman Storey * [Pascal] time permitting, Herman could present ISA100.20 status on 6TSCH call * IoT6 * architecture close to 6tsch * key people are Antonio Skarmeta and Antonio Jara from U. Murcia, Spain * [Thomas] Who could be liaison? * [Maria Rita] could get more information [10.00] recording * [Pascal] is recording, OK to make available to people who could not make it? * rough consensus on call that's no problem. * [Tom] we can alternate between 2 times. * [Tom] mention that meetings are recorded when sending poll to reschedule meeting. [10.04]* end of meeting