[6tsch] minutes webex 27 September 2013

[Thomas Watteyne <[e-mail]>]

All,

You will find the minutes of this week'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, please fix anything we might have missed directly in the e-mail
and reply. We will approve and adopt the minutes at the beginning of the
next call.

Thomas

-----

Minutes Webex 27 September 2013, 6TiSCH group

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

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

Present *(alphabetically)*

   1. Diego Dujovne
   2. Dominique Barthel
   3. Elvis Vogli
   4. Geraldine Texier
   5. Guillaume Gaillard
   6. Maria Rita Palattella
   7. Nicolas Montavont
   8. Pascal Thubert
   9. Patrick Wetterwald
   10. Pouria Zand
   11. Qin Wang
   12. Raghuram Sudhaakar
   13. Thomas Watteyne
   14. Tom Phinney
   15. Xavi Vilajosana

Recording

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

Slides

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

Action Items

   - *Xavi* to put paragraph in minimal draft about relationship between
   ASN and timestamp.
   - *Qin* to discuss limit of join priority on ML.
   - *All* review minimal draft (
   https://bitbucket.org/6tsch/draft-vilajosana-6tsch-basic/src) by next
   call. Post feedback on ML.

Agenda

   - Administrivia *[4min]*
      - Approval agenda
      - Approval minutes last call
      - cut-off dates
      - update draft architecture *[Pascal]*
   - Update minimal draft *[Xavi]* *[15min]*
      - See latest version at
      https://bitbucket.org/6tsch/draft-vilajosana-6tsch-basic/src
   - models *[Pascal]* *[15min]*
      - data
      - information
      - interaction
   - discussion model draft *[Maria Rita,Pouria,Raghuram,Qin]* *[25min]*
      - overview Wednesday discussion
      - open questions (URI, method, triggers, profiles, 6top)
      - roadmap
   - AOB *[1min]*

Minutes

   - *[08.05]* Meeting starts
   - *[08.06]* Administrivia
      - Approval agenda

      No issues raised. Agenda approved.

      - Approval minutes last call

      No issues raised. Minutes approved.

      - WG formation status:
         - 6TiSCH discussed during IESG telechat 2013-09-26
         - slight changes to charter following discussion.
            - See current charter at
            https://datatracker.ietf.org/doc/charter-ietf-6tisch/
         - prepare for renaming of:
            - mailing list
            - bitbucket group
         - Vancouver important dates:
         - see http://www.ietf.org/meeting/cutoff-dates-2013.html#IETF88
         - draft submission cut-off: 21-10-2013
      - update draft architecture *[Pascal]*
         - Major changes:
            - Section 8. Network synchronization
               - Time Synchronization Global Instance (TSGI)
            - Section 10. Management
               - add subsections about beacon interaction. Still WIP.
            - check latest version on the site
         - *[08.15]* Update minimal draft *[Xavi]*
      - See latest version at
      https://bitbucket.org/6tsch/draft-vilajosana-6tsch-basic/src
      - Already renamed the draft. Waiting for feedback to publish new
      version.
      - slotframe representation:
         - first slot for EB
         - 5 shared slots
         - the rest of the slotframe is unused
      - timeslot timing
         - we need to define the timings. The draft contains a table with
         the timings. People need to implement these timings to interoperate.
         - EB: need to contain a minimum number of IEs
            - syncIE (IE, join priority). How use join priority discussed
            in draft.
            - Frame and link IE. If a mote doesn't pre-configure, can
            configure its slotframe based on information in IE.
         - ACK: contains time correction IE (same as IEEE802.15.4e)
         - neighbors
            - some information kept per neighbor, including counter,
            address, RPL rank.
         - *[Pascal]* Can we remove ASN?
      - *[Xavi]* we could replace name "ASN" by "timestamp" in the
      description of the tables.
      - *[Qin]* according to IEEE802.15.4, join priority can go from 0 to
      0x3f.
      - *[Xavi]* OK, will investigate.
      - *[Pouria]* counter for "number of acknowledge". Since shared cell,
      can we use this information as a good metric for qualifying the
quality of
      the link?
      - *[Xavi]* we only need to collect information, other pieces will
      decide what to do with this information.
      - RFC6552, using OF0
      - Xavi presents an example, that is now in the draft.
      - *[Pascal]* modified slides slightly, removed leftover f.
      - *[Xavi]* Thanks. Probably not in draft, will check.
      - Please send more comments before submitting.
      - *[Pascal]* Hysteresys?
      - *[Xavi]* Yes, in draft.

      Action item: all review by next call.

      - *[Qin]* Maximum value of join priority 0x3f. Could we ask
      IEEE802.15.4e author why?
      - *[Thomas]* Important point. Please discuss on ML.
   - *[08.33]* models *[Pascal]*
      - information model: its goal is to define a model that can be
      extended.
      - we don't feel 100% confident to write an information model.
      - we can take advantage of Qin's work on 6top.
      - start with data model using CoAP and CBOR. From there, we will be
      in better shape to write information model.
      - our goal is not to describe an information that has everything, but
      one that can be extended. This will be very visible in data model.
      - "interaction model" is a term that came up, which for example
      indicates the difference between GET and Observe.
      - want to insist that pub/sub and source/sink models are used in
      industrial. We need to make sure CoAP can support them.
      - side note: asked the ROLL WG to make
      http://tools.ietf.org/html/draft-ietf-roll-rpl-industrial-applicability-01
into
      RFC. Allows us to easily refer to it.
      - *[Pascal]* Tom, can you comment on the usability of CoAP for can be
      used for client/server, pub/sub and source/sink models?
      - *[Tom]*
         - client/server is 1-to-1 direct communications.
         - The server can be addressed by role. There is a binding issue.
         - pub/sub: set of subscribers, 1-to-n relationship. Source of
         information sends to multiple addressees.
         - pub/sub is a publication model, with a set of subscribers. More
         scalable.
         - pub/sub is connected. Subscription process. Fundamental
         abstraction. Long-term association.
         - pub/sub: one of the challenges is how it is implemented.
         - Works well when the number of receivers is not known in advance.
         - Source/sink is used to distribute alerts. Alarms have different
         keying model.
         - summarize:
            - pub/sub is 1-to-n. For example, military fire control
            systems, anyone interested in this information, listen to
it. Multicast.
            - source/sink used for alerts. Something going wrong. Many
            sources information such as alert. Many receivers want to
receive all.
            Typically, want to receive all alerts from a specific
segment. multicast,
            not connected.
            - CoAP can be used for any of these, we just need multicast.
         - pub/sub for sensor readings.
         - source/sink is both for data and signalling. process alarm.
         - No attempts at retries in source/sink.
      - *[Thomas]* How much of is related to the network, or how much of is
      related to the data
      - *[Tom]* most of the interaction models are mostly of interaction of
      the data and not for management or control of the data.
   - *[08.50]* discussion model draft *[Maria Rita]*
      - overview Wednesday discussion
         - private e-mail and round table on webex on 09/25.
         - 6top is heart of the 6tisch work and architecture.
         - Manages MIB
         - exposes an API
         - API already defined in 6top draft.
         - Principles:
            - different apps with different requirements
            - Cannot define everything -> require mechanism to be extensible
            - Hybrid use cases: centralized and distributed models.
         - Three mechanisms:
            - neighbor to neighbor negotiation (already in 6top draft)
            - Distributed Multi-hop reservation (RSVP-like)
            - CoAP endpoint to 6top - our focus by now.
         - Scheduling approaches.
            - not addressing specific scheduling approaches. Using the 3
            mechanisms, can implement a wide range of scheduling solutions:
               - decentralized RSVP-like reservation
               - purely centralized (e.g. TASA)
               - Multiple PCEs
               - on-the-fly decentralized reservation
               - cluster-based model
               - etc.
            - we need to identify scenarios and define mechanisms as
            building blocks NOT specific mechanisms.
         - scope:
            - give access to give 6top over CoAP
            - expose the list of commands over CoAP.
         - *[Thomas]* in 6top, negotiation is done using TLVs in IE. It
         would be interesting if the same format in the negotiation
phase at 6top
         and the negotiation phase on CoAP. i.e having same payload
format in msg
         carried by CoAP to 6top and messages between 6top layer in
different nodes.
         - *[Qin]* Use TLV vs CBOR? how to combine?
         - *[Qin]* define what is a resource (either the element we want to
         modify (e.g table) or a field on a table. So we need to
discuss what the
         granularity of a resource defined as a CoAP URI is.
         - Propose new call on the ML in case this needs to be further
         discussed during the week.
      - *[09.08]* AOB

   No other issues raised.

   - *[09.09]* Meeting ends