[6tsch] minutes webex 06 September 2013

Thomas Watteyne <watteyne@eecs.berkeley.edu> Fri, 06 September 2013 17:05 UTC

Return-Path: <twatteyne@gmail.com>
X-Original-To: 6tsch@ietfa.amsl.com
Delivered-To: 6tsch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EECE121E80D4 for <6tsch@ietfa.amsl.com>; Fri, 6 Sep 2013 10:05:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Level:
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Ivon8K48Q5v for <6tsch@ietfa.amsl.com>; Fri, 6 Sep 2013 10:05:04 -0700 (PDT)
Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC6821E80CE for <6tsch@ietf.org>; Fri, 6 Sep 2013 10:05:04 -0700 (PDT)
Received: by mail-pd0-f182.google.com with SMTP id r10so3503644pdi.13 for <6tsch@ietf.org>; Fri, 06 Sep 2013 10:05:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=vmgcU3mmx6E6MN4dn2wOn/DrvV0Y8mOpqKl8aBnm1Ts=; b=AKWlIHCJavd39iBzOAbZdVLM9V8JtTvUuQI+Vlwm1EKMP92+tCMRyoZX0tTXsgIjv0 fhi1HWkgV4SLmndA7chM9tzru9pk80+R56gGGWil3gKwnLefGKYcX/hsez+PaYXBwqLT Kd0haoaVqZ5Wrn63x1MTt/Z1rFbuc5Z41u2u2FlxoHq8dPEIebhGpdfKI+wAQe1jv7Hf NycjVHLkOLjzpVqLq8wLga/gppNEXcsf7FJ+27uLlZuuwZYP7yJSvFkJFBcYoIjKGXxx +wuzzvUQYoAmgaVhKmzjDARxKGi6x6lG1GlbGWPKpwYDoo6H0qnMO4GfqQrLWj3jyCEw Teug==
X-Received: by 10.66.121.201 with SMTP id lm9mr5152264pab.80.1378487104251; Fri, 06 Sep 2013 10:05:04 -0700 (PDT)
MIME-Version: 1.0
Sender: twatteyne@gmail.com
Received: by 10.66.147.193 with HTTP; Fri, 6 Sep 2013 10:04:44 -0700 (PDT)
From: Thomas Watteyne <watteyne@eecs.berkeley.edu>
Date: Fri, 6 Sep 2013 10:04:44 -0700
X-Google-Sender-Auth: uiI1efoHvLLzA7nEBvZ_VJn7E9E
Message-ID: <CADJ9OA8OCf211Sx879oTc-ZC1MeJaHk5+Utw_CcD2P2Vnea_RQ@mail.gmail.com>
To: 6TSCH <6tsch@ietf.org>
Content-Type: multipart/alternative; boundary=047d7b2e4ca42d30cf04e5ba0ae2
Subject: [6tsch] minutes webex 06 September 2013
X-BeenThere: 6tsch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:6tsch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>
List-Post: <mailto:6tsch@ietf.org>
List-Help: <mailto:6tsch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:6tsch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Sep 2013 17:05:06 -0000

All,

You will find the minutes of today's webex below.

FYI, all the minutes and slides are archived a
https://bitbucket.org/6tsch/meetings/.

Thanks to Xavi and Dominique for taking notes!

As usual, fix anything we might have missed directly in the e-mail and
reply. We will approve and adopt the minutes at the next call.

Thomas

---

Minutes Webex 6 September 2013, 6TiSCH group

Note: timestamps in PDT.
Taking notes *(using Etherpad)*

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

Present *(alphabetically)*

   1. Cedric Adjh
   2. Diego Dujovne
   3. Dominique Barthel
   4. Geraldine Texier
   5. Maria Rita Palattella
   6. Pascal Thubert
   7. Patrick Wetterwald
   8. Pouria Zand
   9. Qin Wang
   10. Raghuram Sudhaakar
   11. Thomas Watteyne
   12. Tom Phinney
   13. Xavi Vilajosana

Recording

   - Webex recording (audio+slides,streaming)
   -
   https://cisco.webex.com/ciscosales/lsr.php?AT=pb&amp;SP=MC&amp;rID=71216747&amp;rKey=96640b930d5e441d<https://cisco.webex.com/ciscosales/lsr.php?AT=pb&SP=MC&rID=71216747&rKey=96640b930d5e441d>
    *[65min]*

Slides

   - slides_130906_webex.ppt<https://bitbucket.org/6tsch/meetings/src/master/130906_webex/slides_130906_webex.ppt>pt>:
   slides shared during the call

Action items

   - *Pascal* to add description of flows to architecture draft.
   - *Raghuram* and *Xavi* to prepare overview slides of the CoAP. To be
   presented at call in 1-2 weeks.
   - *Pascal* to add Track and Cells to the list of items for a node to
   report to the PCE using report flow, on the ML.
   - *Pouria* to identify the equivalent information sent by a WirelessHART
   and ISA100.11a node to the manager.
   - *Thomas* to contact IEEE802.15.4e authors about EB priority and
   whether the step for EB priority MUST be +1 or can be something else, e.g
   +Step_Of_Rank from RPL.
   - All to ask about RPL OF0 presentation by Pascal on ML.

Agenda

   - Approval minutes & agenda bashing *[3min]*
      - charter update
   - Flow identification *[40min]*
      - 5 flows? Identify the tiers (ME in device, PCE, NME)
      - CoAP mechanisms we could reuse
      - Discussion commands and information exchanged in flows (report)
   - Using RPL in minimal 6TiSCH case *[15min]*
      - Rank, Join Priority and flow label
      - RPL and OF0
      - Impact of routing loops on synchronization
   - AOB *[2min]*

Minutes

   - *[08.05]* Meeting starts

   Recording starts

   - *[08.06]* Approval minutes & agenda bashing *[3min]*
      - approval minutes last minutes

      No concerns raised. Minutes approved.

      - approval agenda

      No concerns raised. Agenda approved.

      - charter update
         - Submitted to IESG Thursday on 9/5/13
         - Talk by Thomas about 6TiSCH activity at senZations'13
      - *[08.10]* Flow identification *[40min]*
      - 5 flows? Identify the tiers (ME in device, PCE, NME)
         - Request Flow: Internet to PCE or Mesh to PCE
         - Action Flow: PCE --> Mesh
         - Report Flow: Mesh--> PCE
         - Event Flow: Node notifies to the PCE
         - Query Flow: PCE asks a node
         - Acknowledgements of flows:
         - Leave the ACKs to the transport mechanism. For example, CoAP
         provides the optional mechanism of confirmable messages.
         - *[Qin]* ACK from transport layer is part of the confirmation.
         Not all of the confirmation. We use ACK from transport layer
if it can be
         used. If we need additional confirmation, this can be added from the
         applications layer.
         - *[Thomas]* 2 aspects:
            - ACK is to confirm that the message has been received.
            - Application-level response us used to provide a response
            payload, e.g track confirmation, etc.
         - ACKs are optional on the transport layer.
         - Next steps: add to architecture draft?
            - High level overview of the flows go to the architecture.
            - *[Maria Rita]* Full details about the bits-and-bytes should
            go to the flows description draft.
            - *[Qin]* Question about the picture: it is more focused to the
            centralized case. In a distributed case the flows do not work.
            - *[Pascal]* The current charter does not address 6top to 6top.
            - *[Xavi]* We can map decentralized flows to centralized in
            very brief discussion on the ML to see if there is some
immediate mapping.
         - Volunteer to add description of flows to architecture draft?

         Action item: Pascal to add description of flows to architecture
         draft.

         - CoAP mechanisms we could reuse
         - CoAP provides mechanisms we could take advantage of.
            - Resources
            - methods (GET/PUT/PUSH)
            - confirmable messages
         - Volunteers to prepare an overview of the CoAP in 1-2 weeks?

         Action item: Raghuram and Xavi to prepare overview slides of the
         CoAP. To be presented at call in 1-2 weeks.

         - Discussion commands and information exchanged in flows (report)
         - Sent by the node to the PCE.
         - Gives information about how the node is doing.
         - Go through the proposed fields on the ML after some discussion:
            - For each neighbor: ID, RSSI, LQI, Counters, Bundle
            information, statistics about the link.
            - Queue information
            - Time source parents.
            - Not clear yet as to how to get at all these metrics.
         - How the PCE can configure the mote to relay only some of this
         information, what the PCE wants to know and when. Ongoing
discussion on the
         ML.
         - *[Pascal]* Bundle allocation is not redundant as when we use
         RPL-based allocation the bundle is built dynamically.
         - *[Pascal]* Tracks and cell information. Ask for devices to
         report about a particular track.
         - *[Pascal]* Monitor cells that are not being used to know if they
         are good.

         Action item: Pascal to add Track and Cells to the list of items
         for a node to report to the PCE using report flow, on the ML.

         - *[Diego]* It would be interesting to get the average RSSI/LQI
         per channel instead of the average amongst all. Requires node to keep
         per-channel measurements of RSSI/LQI.
         - *[Thomas]* Important to think about the mechanism to allow a
         subset of this information to be configured.
         - Volunteers to identify the equivalent information sent by a
         WirelessHART and ISA100.11a node to the manager?

         Action item: Pouria to identify the equivalent information sent by
         a WirelessHART and ISA100.11a node to the manager.

         - "Timeslot Management Methods and Formats" draft: Let's wait 1-2
         weeks before starting a skeleton.
      - *[08.51]* Using RPL in minimal 6TiSCH case [15min]
      - Rank, Join Priority and flow label
         - Network bootstrap and synchronization.
         - A joining node listens for EBs. Keeps listening until it hears
         multiple. Based on EBs, picks best temporary parent neighbor.
         - Keeps synchronized to this temporary parent until it gets RPL
         DIOs. Once it acquires a RPL rank, starts sending EBs. RPL
rank used as EB
         join priority.
         - The node keeps silent until it has a rank and selected
         preferrred parent.
         - *[Qin]* RPL rank as join priority, is a field of 15.4e, every
         15.4e implementation will implement that part, 6top will override this
         field. Breaks 15.4e?

         Action item: Thomas to contact IEEE802.15.4e authors about EB
         priority and whether the step for EB priority MUST be +1 or can be
         something else, e.g +Step_Of_Rank from RPL. Note: by lack of
time, we will
         skip last slides.

         - RPL and OF0 *[Pascal]*
         - Zero OF, uses basic information from RPL
         - Increments the rank at each hop independently of a very detailed
         metric.
         - Linear categories of rank between 1 or 9.
         - How do we compute the step if we are using ETX. --> use a linear
         approach.

         Action item: All to ask about RPL OF0 presentation by Pascal on ML.

         - *[09.11]* AOB

   No other business raised.

   - *[09.12]* Meeting ends