Subject: [6tsch] minutes WebEx 1 March 2013

From: Thomas Watteyne <[email-masked]>
Date: Fri, 1 Mar 2013 11:15:25 -0800

All,
Notes of today's meeting below. Please correct inline and reply.
Thomas

---

Present:
- Alfredo Grieco
- Herman Storey
- Maria Rita Palattella
- Normann Finn
- Pascal Thubert
- Qin Wang
- Raghuram Sudhaakar
- Thomas Watteyne
- Tina Tsou
- Tom Phinney
- Xavi Vilajosana

Agenda:
- Presentation of the backbone router draft  [15min]
    . http://tools.ietf.org/html/draft-thubert-6lowpan-backbone-router-03
- 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
http://tools.ietf.org/html/draft-thubert-6lowpan-backbone-router-03
      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