Clone wiki

meetings / 130621_webex

Minutes Webex 21 June 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. Guillaume Gaillard
  4. Kris Pister
  5. Maria Rita Palattella
  6. Pascal Thubert
  7. Pouria Zand
  8. Raghuram Sudhaakar
  9. Thomas Watteyne
  10. Tina Tsou
  11. Tom Phinney
  12. Xavi Vilajosana




  • draft-thubert-6tsch-architecture-02 [5min]
  • draft-vilajosana-6tsch-basic-00 [10min]
  • Architecture with remote BBR [10min]
  • Soft cell assignment: random or not? [20min]
  • Track IDs [10min]
  • AOB [5min]


  • [08.05] Meeting starts
  • [08.05] Pascal starts the recording
  • [08.05] Agenda [Pascal]
    • draft-thubert-architecture v2
    • draft-vilajosana-basic v0 (thank you Xavi!)
    • Architecture with remote BBR (by Thomas)
    • Soft cell assignment: random or not
    • Track IDs
    • AOB
  • [08.06] adopting minutes [Pascal]
    • let's do a call for adoption of the previous meeting's minutes from now on
    • any concerns with last call's minutes?

      rough consensus on the call

    • last call's minutes are adopted
    • note: we are recording this call
  • [08.07] draft-thubert-architecture [Pascal]
    • ROLL flow label draft ( using the flow label we can skip to have another encapsulation and use it for the hop-by-hop
    • RPL can use hop by hop option
    • we can forward about anything in a slot (a la GMPLS), i.e. tunnel mode
    • transport mode: dmac to 0xffff at ingress, restored at egress
    • Tunnel Mode:
      • if we setup a track the forwarding is done at the 6tus layer
      • who sets the mac address and what mac addess is there?
      • Using the tunnel abstraction to switch between technologies, assuming a node can have 2 interfaces (e.g. WirelessHART and IEEE802.15.4e), the tunnel model can transport the WirelessHART payload tunneled in the IEEE802.15.4e using 6tus tunnel and the restore it at the egress router.
      • [Thomas]: we need to look closely at the implications, especially on the security aspect
      • [Thomas]: it might be easier to do if:
        • the WirelessHART and IEEE802.15.4e slots are the same length
        • some coordinated schedule of both networks is happening, essentially building a collision-free schedule across both networks.
    • Action: ALL to read proposed -02 draft ( and provide feedback. Pascal to publish after rough consensus.
  • [08.19] draft-vilajosana-6tsch-basic-00 [Xavi]
    • Xavi presents the draft published at
    • We were discussing the minimal configuration for 6TSCH at last call.
    • Draft contains the outcome of that discussion.

      Xavi shares his screen, showing the draft

    • Main purpose of draft is for interop testing.
    • Xavi goes through parameter values.
    • Longer than 10ms slot needed for slower platforms
    • Basic schedule, static schedule, same for all nodes, 5 active slots, rest is sleeping.
    • Recommends neighbor management information base.
  • [08.30] Architecture with remote BBR [Thomas]
    • Addresses the case of several BBRs, on different subnet. ND proxying needed for to work.
    • Several possible architectures : tunnel, combined PCE/router, hybrid
    • Hybrid: the PCE does the proxying of all the nodes in the LLN, the PCE manages and has explicit connections to the BBRs.
    • Keep PCE and ND separate elements. 6tsch does not define anything about how PCE and BBR communicate.
    • [Thomas] 6TSCH should not take on the task of defining BBR-to-PCE communication. But we should not exclude in our specification any of the three approaches and if someone wants to go for them this should not exclude them from the standard.
    • [Pascal] Push as much work as we can to the PCE/discovery. Add to architecture.
    • [Pascal] add some text on the architecture draft telling that can be done in an open way.
    • [Thomas] many ways of doing this. Should describe a reference architecture but leave it open
  • [08.38] Soft cell assignment: random or not? [Thomas]
    • This problem applies only to distributed scheduling.
    • Open question: Is a purely random good enough?
    • Answer will depend on the amount of traffic in the network. We need to indentify the threahold traffic at which point it is NOT good enough (possible collapse).
    • 2 neighbors negociate the allocation of an extra cell, and have to decide on a slotOffset/channelOffset. The problem is that neighbors can choose the same cell and then collisions occur.
    • Two methods:
      • Random selection: select cell randomly, and hope for the best. If collisions happen, a monitoring function detects then and picks another (random) location for that cell.
      • Informed selection: maintain some state and try not to pick same cell as other neighbors. Collision can still happen, but less likely.
    • In both cases, detecting collisions is crucial, and I believe this was agreed on on the ML.
    • [Pouria] presents picture. Shows 2-hop neighborhood. Shows conflicting edges of two nodes. Node A can ask for one hop neighbor's cell usage. It can get up to 2 hop neighbors as 1-hop neighbors can send that information. By combining that information, the figure can be build. During a negotiation node A can send a candidate list to the neighbor.
    • [Thomas] There are 2 steps in solving this:
      1. how much of a problem is it if we just do random.
      2. If random is not good enoug, what is the best approach
    • Problems with random. What is the collision probability? What is the traffic on my network that causes random selection to not work. How often will a collision happen? Is is possible to evaluate the overhead of re-negotiation, and compare that to the overhead to maintain state?
    • There are open questioms
    • [Thomas] Pouria, willing to work on this?
    • [Pouria] yes.
    • [Xavi] look at P2P community, not reinvent.
    • [Kris] No doubt that informed will do better than random.
    • [Thomas] example of Trickle. RFC says one needs to define what is consistency and inconsistency. Opinions here on what is a consistent state? "no collision" as the consistent state is being debated on the ML.
    • [Kris] a node won't know if it's a collision inside network or with something external. Only thing it knows is "this cell doesn't work for me".
    • [Thomas] take as action item to start looking at problem of figuring out how bad random approach is, boundary with informed decision. Who would be interested.
    • [Xavi]: I'm interested.
    • [Pouria] I'm interested.
    • [Alfredo] I'm interested.
    • [Alfredo] the problem is that purely random selection can be done many different ways. We could for example have some dependency on the hop count from the DAGroot, could help with channel re-allocation. Implicit state, related to routing topology.
    • [Thomas] allocate pieces of matrix to differnet parts of DAG. Less fighting. Let's put this to the mailing list and come up with numbers.
  • [08.58] Track IDs [Thomas]
    • discussion stared by Qin. If we don't have clear track ID, it's harder to match cells to tracks.
    • [Pascal] We could use of RPL Instance ID:
      • instanceID: each node has 64 available instanceIDs to manage.
      • the PCE can install route.
      • who selects the instanceID? source? destination? p2p rpl uses source to select instanceID.
      • what about broken track?
    • [Thomas]: 6LoWPAN would compress this nicely. Possibly through contexts?
      • [Pascal] the source mac is still compressed with 6lowpan. InstanceID is kept on the state of the tunnel.
      • [Pascal] Hop by hop option removed compression opportunity.
    • [Thomas]: we will carry on this dicsussion on the mailing list, because time has expired.
  • [09.07] AOB [Thomas]
    • Thomas calls for Any Other Business

      no other business

  • [09.08] meeting ends