Clone wiki

meetings / 130531_webex

Minutes Webex 31 May 2013, 6TSCH group

Note: timestamps in PDT.

Taking notes (using Etherpad)

  1. Xavi Vilajosana
  2. Dominique Barthel
  3. Thomas Watteyne

Present (alphabetically)

  1. Alfredo Grieco
  2. Dominique Barthel
  3. Herman Storey
  4. Maria Rita Palattella
  5. Pascal Thubert
  6. Pouria Zand
  7. Raghuram Sudhaakar
  8. Robert Assimiti
  9. Thomas Watteyne
  10. Tina Tsou
  11. Tom Phinney
  12. Xavi Vilajosana




  • Logo Challenge [3min]
  • Berlin Update [3min]
  • 6lo [3min]
  • Multiplexing Tracks [10min]
  • Explicit Labels [10min]
  • Forwarding Modes [10min]
  • Bundle Size and ETX [10min]
  • "Simplest TSCH" draft [10min]

Executive summary

  • Rough consensus to be confirmed on mailing list:
    • We need to take retransmissions into account when building the schedule, and have retransmissions happen on the same track that first attempt.
    • We will not support tracks between merged or split.
    • We will not remove the MAC header on packets being switched.
  • Ideas to be developed on ML:
    • [champion: Pascal] To avoid the RPL stretch, could we allow the PCE to install routes.
    • [champions: Pascal,Xavi] 1-bit so 6tus either switches or hands off to packet to routing layer. Several options: multicast MAC address, IEEE802.15.4e IE, something in 6LoWPAN.
    • [champion: Alfredo] add timestamp to packet to influence forwarding decision (most likely when routing, not switching, a packet)
    • [champion: Pascal] Dealing with 6LoWPAN fragment. To avoid re-assembly at each hop: 6tus switching or 6LoWPAN switching? (probably a combination)
  • Action items:
    • [Maria Rita, Alfredo, Pascal, Pouria] Set of slides on how to build the simplest 6TSCH network.


  • [08.05] Meeting starts
    • [Pascal] Goal: How can be avoid the waste of BW. Side discussion: Where do we place the excess bandwidth needed because of retries.
  • [08.07] Logo Challenge
    • 15 votes so far.
    • Logo 2 a bit ahead of logo 3
    • URL on ML
    • Winner announced at next call
  • Berlin Update
    • Thomas presents important dates slides
    • Pascal social event is on Tuesday, usually lots of fun
  • 6lo
    • 6lowpan is closing
    • new ML for updates and other improvements
    • 6lowpan will hold interop in berlin
    • compression mechanisms
    • have not hear asked for a BoF
  • [08.11] Multiplexing Tracks [Pascal]
    • Statistical mux
      • effect of queuing on priority
      • undeterministic flows: multiple flows arrive in router. Complex router.
      • could 6tus do this sort of thing
      • can 6tus can have a statistical mux?
      • federates the cost of retries as allows slot reuse
      • how much of that we can to have on the 6tus sublayer?
      • won't expect that this will be simple.
      • [Thomas]
        • wireless is lossy in nature, retries are part of the actual flow.
        • it is important that we consider retries part of the initial flow.
        • building the track according to what is required, and use another shared track for retries will make things very complicated.
        • suggest: pipe on the main track should reflect the retransmissions (ETX). so reservation should take etx into account.
        • Errors does not translate to other hops, jitter translates to next hops.
    • [8:17] Implicit vs explicit pipes [Thomas]
      • If each flow is a dedicated pipe, when there is no traffic, the receivers idle listens for each flow. This might incur more energy.
      • When we are multiplexing tracks, implicit label does not identify flow, and Kris proposed to use the mac destination address as a dissector.
      • Idea: install a track and assume it is deterministic. One can always use routed cells.
      • [Pascal] We don't want to reinvent QoS in 6tus.
      • [Pascal] Routes are installed by RPL, would we let the PCE install routes?
      • [Thomas] The PCE installs L2 resources. PCE can install other cells so this can be used for non-switched routing.
      • Use 1 bit in 6LoWPAN header that tells whether explicit of implicit label?
      • In order to be able to distinguish between switched packets and packets that have an special header we need some bit at L2 so the switching component can decide to forward or to parse the header.
      • [Pascal] An alternative is to use multicast mac layer addresses.
      • Keep mac layer header in the label switched packets
      • Thomas ask for rough consensus between
        • Proposal 1: LS tracks are water tight pipes (deterministic)
        • Proposal 2: combine/multiples cells so we can optimize the energy consumption.
        • we vote for proposal 1.
  • [8:34] Explicit Labels [Alfredo]
    • Explicit label can contain TTL or a TS.
      • use it to drop packets on route if too old/late
      • change priority as a function of ttl
      • manage delay
    • How to make it optional?
      • how to distinguish a packet with/without header?
      • [Pascal] Even if jitter is accumulated in the track, at the other side of the tunnel you know what packet it is so (worst case) you can know if it is too late or delay is not guaranteed.
      • [Alfredo] Soft delay guarantees
      • Whether bot considering that for Label Switching, where the field should live? L3 has this information.
      • Infomration is passed to L3,
      • It has to be somewhere between L2 and L3.
      • In conclusion:
        • Great idea. Be able to adjust when packet is routed.
        • Cannot be applied to label switching
        • Consider this for routing not for track based switching.
  • [8:45] Forwarding Modes [Maria Rita]
    • IP Routing
      • different sublayers on the stack and showing how a packet flows.
      • x-y has a bundle of 2 cells
      • a packet flows through the network and goes up to L3 at each hop so the next hop is determined by routing.
    • Track switching:
      • we can use 2 tracks and use label switching
      • in that case the packet is directly forwarded by 6tus
      • Some cells are colored but others can be used for other things, so not all cells form part of the label switching path
    • 6LoWPAN fragments forwarding (
      • avoids fragment reassembly at each hop.
      • state installed in nodes by first fragments, fragments follow the same track
      • datagram ID of each fragment is switched at each hop to play the role of a label as in LS
      • we can switch at 6tus layer or at 6lowpan layer
  • [8:59] bundle size and ETC
    • long term PDT stats can be used.
    • account for retransmissions on the schedule.
    • No concerns from the people on the call
  • [09.00] Simplest TSCH draft
    • good and simple base
    • interop events
    • work out all the details
    • how do you join, how do you synch, what's in the EB
    • more complex scenarios can appear later
    • absolute simples tsch
    • hardcoded slotted aloha
    • [Tom] The best way to do this is take an example and go through it completely to identify all the elements that you forgot about.
    • [Xavi] proposes to work on this
    • [Alfredo] proposes to work on this
    • [Maria Rita] proposes to work on this (by chat)
    • [Thomas] Could volunteers prepare a set of slides for the next call?