[6tsch] minutes discussion models draft

[Thomas Watteyne <[e-mail]>]

All,

We had *very* interesting discussions with "models draft" volunteers by
e-mail and on a call on Wednesday.

The minutes of the wednesday discussion are available at
https://bitbucket.org/6tsch/meetings/wiki/130925_webex_models_draft, and
copy-pasted below.

Please let me know if I forgot something.

We will continue this discussion on the call tomorrow. Looking forward.

Thomas

PS: who took notes over Etherpad on the call on Wednesday? Your name wasn't
entered in Etherpad.

---

Minutes Webex 25 September 2013, 6TiSCH group, models draft team

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

   1. Thomas Watteyne
   2. ??

Present *(alphabetically)*

   1. Maria Rita Palattella
   2. Pascal Thubert
   3. Pouria Zand
   4. Qin Wang
   5. Raghuram Sudhaakar
   6. Thomas Watteyne

Goal

This is a one-off discussion between the member of the models draft team.
Minutes are listed here for completeness.

Its goal is to discuss the scope and details of the information and data
model for 6TiSCH.
Formal

Round-table. Question asked: "what are your ideas about scope?"
Minutes

   - *[08.02]* meeting starts
   - *Raghuram*
      - Previous work done in the context of databases.
      - Defined how different tables of a database are interacting (data
      model in the context of databases).
      - Extrapolating to 6TiSCH: data model is definition of messages.
      - What fields do we want in each message (and their meaning).
      - Table in a database are messages in 6TiSCH.
      - Information model: define the interaction (what query needs to be
      directed to what tables?).
      - We want to define the message flows.
      - Questions: messages flow are already in the 6top draft. What are we
      defining differently? About how do we name URI and map method: has to be
      part of new document.
      - *[Pascal]* We need to define at UML level.
      - *[Raghuram]* Information model is message flows?
      - *[Pascal]* Information model is static. Content of messages. Flow
      on top of information model. We need both models.
   - *Thomas*
      - 6top is at the core of what we do.
      - In the end, we will define 2 mechanisms
         - mote interacts with neighbor
         - entity interacts with 6top sublayer of mote multiple hops away
         (CoAP)
      - These mechanisms allow for many different interaction models:
         - decentralized RSVP-like reservation
         - purely centralized (e.g. TASA)
         - on-the-fly decentralized reservation
         - cluster-based model
         - etc.
      - Someone can take these mechanisms and develop some interaction
      model, while staying standards compliant.
      - Scope of this draft: give access to 6top over CoAP
         - Resources (URIs)
         - Method (GET/PUT/POST/DELETE)
         - Profiles
         - Triggers
      - *[Pascal]* Interaction model is a dynamic view as opposed to the
      information layer which is static model.
      - *[Pascal]* We want interaction model as well as information model.
   - *Qin*
      - There are 3 things associated with data/information model:
         - Management Information Base (MIB), i.e. the 6top database
         - message formats (TLV, etc.)
         - control flows (interaction between entities)
      - The messages can be configurable. We need to define define a
      mechanism to define messages.
      - Different applications can require different formats. We can not
      define every message, but define mechanism.
      - About control flow: what can the network reuse? centralized or
      distributed. The flows we defined now is just one of many.
      - *[Pascal]* information model could be the same.
   - *Maria Rita*
      - We can imagine a case in which centralized and distributed models
      are mixed.
      - What we define for centralized can be reused for decentralized.
      - *[Thomas]* People can use the mechanisms defined to explore
      different triggers. We need not define all possible scenarios.
      - *[Maria Rita]* we need to be extensible. We are considering only
      PCE so far. We could imagine networks with several PCEs, etc. We
need to be
      as general as extensible as possible.
      - The data model should define the message formats. Quite clear.
      - The information model should contain the interaction model, i.e. in
      which way the information is exchanged.
      - *[Raghuram]* the data model needs to include CoAP and payload
      format.
      - *[Maria Rita]* we need to keep an eye open for methods different
      from CoAP.
      - *[Pascal]* we might not be using CoAP for mote-to-mote 6top
      communication. Information model could.
   - *Pouria*
      - Agree with Pascal: we need to differentiate between information and
      interaction model.
      - Can we use CoAP for 6top-to-6top?
      - *[Thomas]* This is already defined in the current 6top draft. Qin &
      Xavi proposed a number of IEEE802.15.4e information elements to do the
      negotiation between neighbors. To communicate between 2 neighbors the
      current proposal is to use these IEs, not CoAP.
      - *[Qin]* Agreed.
      - I see 3 mechanisms:
         - CoAP-to-6top (multiple hops)
         - 6top-6top (single hop reservation of soft cells)
         - RSVP-like reservation
      - *[Thomas]* agreed with extra mechanism
      - *[All]* consensus that we will get there, but RSVP needs more
      investigation.
      - *[Maria Rita]* Should we take a top-down approach or bottom-up
      approach?
      - *[Thomas]* define the 6top interfaces which is one of building
      blocks to communicate with 6top nodes from other places. TASA can be
      another model.
      - *[Qin]* what is the role of CBOR?
      - *[Thomas]* [Thomas] format of the CoAP payload
   - *Pascal*
      - Summary for what we agreed on:
         - start bottom-up: data model first
         - 3 models: interaction, data, information
         - CoAP:
            - minimal base
            - extensible by profiles
            - profiles means that discovery is required
         - *[09.06]* meeting ends