[6tsch] minutes discussion models draft

Thomas Watteyne <watteyne@eecs.berkeley.edu> Thu, 26 September 2013 20:05 UTC

Return-Path: <twatteyne@gmail.com>
X-Original-To: 6tsch@ietfa.amsl.com
Delivered-To: 6tsch@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id C592E21E8099 for <6tsch@ietfa.amsl.com>; Thu, 26 Sep 2013 13:05:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.529
X-Spam-Status: No, score=-1.529 tagged_above=-999 required=5 tests=[AWL=0.448, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id OBweD+NjRofY for <6tsch@ietfa.amsl.com>; Thu, 26 Sep 2013 13:05:35 -0700 (PDT)
Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 92ADF21E808E for <6tsch@ietf.org>; Thu, 26 Sep 2013 13:05:33 -0700 (PDT)
Received: by mail-pa0-f46.google.com with SMTP id fa1so1793130pad.33 for <6tsch@ietf.org>; Thu, 26 Sep 2013 13:05:32 -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=6xsWdsV/8fks6tMeimJcg5if/2rnfbajjgTMP4HES6Y=; b=OnGBUneUONInmMBtXH6oBqtTNLU8QFbuBJB+46Wu0N/+OoHerlC0idsBLc0Owt4S5I pcKwqUvnw6VYmzde2JSysheXRJCmZM61tat1ltN0DUrVS0/Lp2yrDU5UZ9Atchihzths Qb5ab3DvUg+Q870BzR4+wBRbuihHRabhw9Sb9CvgilJuJF5ag6yMYm12BkPCCWU2j/I0 zT2WsXY2cQmF80MkVaISj5TtydtWHay0PLbksI7UNshHJYw4S65gZekZIecA7NXKH0Bi Jio/sjTDJ5GgYzjvBs92qCp3qP8JaKR7eaNbvc1AJH8bTxgtco0Bs9XlxhpjAd4++nSM F+5Q==
X-Received: by with SMTP id ip3mr3042517pbc.163.1380225932544; Thu, 26 Sep 2013 13:05:32 -0700 (PDT)
MIME-Version: 1.0
Sender: twatteyne@gmail.com
Received: by with HTTP; Thu, 26 Sep 2013 13:05:12 -0700 (PDT)
From: Thomas Watteyne <watteyne@eecs.berkeley.edu>
Date: Thu, 26 Sep 2013 13:05:12 -0700
X-Google-Sender-Auth: wN8ChGPy7ba4CbzI9aMLw2VSpdI
Message-ID: <CADJ9OA_joLJvznxRKJRjWa_ris3c=qp+Wk6xULA0yAE-n7Qr-Q@mail.gmail.com>
To: 6TSCH <6tsch@ietf.org>
Content-Type: multipart/alternative; boundary=e89a8ff1c81e6b542504e74ee4c8
Subject: [6tsch] minutes discussion models draft
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: Thu, 26 Sep 2013 20:05:37 -0000


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.


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


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.

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

   - *[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
      - 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
      - *[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
      - *[Maria Rita]* Should we take a top-down approach or bottom-up
      - *[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