Minutes Webex 19 April 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. Raghuram Sudhaakar
7. Robert Assimiti
8. Subir Das
9. Thomas Watteyne
10. Xavi Vilajosana
11. Yoshihiro Obha

Slides

• call_april_19th.pptx: slides shared during the call

Agenda

• change to draft charter [20min]
• Rough consensus on draft draft charter?
• 6tus naming convention [10min]
• Next steps [20min]

Minutes

• [08.06] [Pascal,Yoshihiro] Sync'up about security draft. Pascal met with Rene Struik, who could help us describe the key exchanges involved in a 6TSCH network. Open questions include how to bootstrap (the security aspect of) a keys, and what exact keys can be used. Yoshihiro agrees that this should be discussed.
  • Action Item Pascal to close the loop between Rene and Yoshihiro.
• [08.10] Overview of the agenda. [Thomas]
• [08.11] Changes to draft charter. [Thomas]
  • overview of changes:
    • Thomas present slides.
    • added term "diversity", as suggested by Tom, as well as "low power operation"

      Closes https://bitbucket.org/6tisch/charter-ietf-6tsch/issue/1/

    • In the 6tus draft, limiting the scope of bootstrapping to TSCH, not security. As suggested by Michael.

      Closes https://bitbucket.org/6tisch/charter-ietf-6tsch/issue/2/

      • 6tus layer initializes the TSCH vs initializes the whole network.
      • [Pascal] depends on whether we have the capability to do that work or not. Boostrapping the network will be better objective but depends on the 6tus draft. 6tus should cover boostraping slots, cells, etc. Security is part of the security work item.
      • [Robert] distinguish between network boostrapping and security boostrapping makes sense. Boostrapping the network is simple, security aspects are more complex and this has to be in another work item. Security can be operated from the link layer, etc... too much for the same work item
      • [Thomas] Let's keep the text as it is now (and as it is on the slide), le's deal with security in security work item.
      • Action Item Thomas maybe change the nature (informational) of the security work item.
  • overview of charter
    • Thomas shows charter on shared screen.
    • introduction has grows a lot. Longer than usual charter. Leave it as this?
    • [Pascal] Other PHY? provide different sizes for the time slot? make sure that we agree on working group description: the same as previous weeks. Models: centralized, decentralized, best efforts (minimal configuration)
    • [Pascal] Determinsm: should we use the term? Let's agree on what we can achieve. Using 6TSCH, we can provision a track, and know the probability of end-to-end delivery. Yet, you cannot never have 100% reliability, because of the nature of wireless.
    • [Herman] Determinsim depends on the applications. Applications have a tolerance, if you are polling it is not deterministic, applies to schedule transmission and comes with the tolerance (robot == few ms), you can have a network that is not scheduled but provides determinsm because it is fast enough. Scale and tolerance are important considerations, slotted is a practical artifact to implement determinism, clarify whether the determinism "word" should appear as is in the charter. (keep in but discuss what it means in our context)
    • [Pascal] We need to be ready for discussions about determinsim in the BOF.
  • work items.
    • 6 as defined before
  • non-milestone work items:
    • implementers guide
    • inter-operability guide
    • coexistence guide between different protocols (including different TSCH)
    • applicability statement
    • All as informational RFCs.
  • [Thomas] Can we reach a consensus on the draft charter language?
    • [all] Rough consensus.
• what to call 6tus.
  • [Thomas] overview of the mailing list (not expressing opinion)
    • 6tus not adaptation layer, since it does not try to fit one protocol into another
    • no layer as there are no fields added
      • [Pascal]
        • disagree with this statement, since time and frequency packet is sent on contains inforamtion, and can be used as a label.
        • 6tus has a GMPLS aspect, 6tus layer can switch packets exactly like GMPLS. We can see 6tus as GMPLS (2.5 layer) that "substitutes" routing once the schedule is set. So it has some relationship to a layer. It is not an adaptation layer (no transformation), but it can be described as a layer.
      • [Robert]
        • As 6tus is a mechanism to agree between the PCE and the node, 6tus should be called a "protocol".
        • A management entity is not a layer.
        • It is important to clarify whether 6tus includes information on the headers, and when used. This is a good indications of the kind of "thing" we are talking.
      • [Pascal]
        • We have to see 6tus as GMPLS. It is a layer that is able to decide on routing (what is the next hop) acording to the cell the packet was received on. A node using 6tus can not forward a packet to the routing layer if it knows that a packet was received on a particular cell, and if it has some switching table mapping incoming to outgoing cells. Packets which can not be switched can be forwarded by the normal routing engine (RPL).
      • [Dominique]
        • In that sense 6tus is a layer that can forward packets (layer 2.25?).
• Next steps
  • [Thomas] With rough consensus on draft charter text, let's resume our technical discussions.
  • First step is to clean up our drafts, as suggested by Adrian during last webex.
  • went over all drafts, and contacted authors to discuss possible changes.
  • Identified issues to be closed before submitting a new version of the draft
  • Let's get this done in the next couple of weeks.
• [09.04]
  • Action Item Thomas Call for adoption draft charter text.
• [09.05]
  • meeting ends