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

Wiki

Clone wiki

meetings / 130925_webex_models_draft

View History

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

Note: timestamps in PDT.

Taking notes (using Etherpad)

  1. Thomas Watteyne
  2. Raghuram Sudhaakar

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.

Format

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

Updated