1. 6tisch Avatar 6tisch
  2. admin
  3. meetings

Wiki

Clone wiki

meetings / 130927_webex

View History

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

Slides

Action Items

Agenda

  • Administrivia [4min]
    • Approval agenda
    • Approval minutes last call
    • cut-off dates
    • update draft architecture [Pascal]
  • Update minimal draft [Xavi] [15min]
  • 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:
    • Vancouver important dates:
    • 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/6tisch/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

Updated