Subject: [6tsch] data structure and format for management packets

From: Qin Wang <[email-masked]>
Date: Tue, 20 Aug 2013 05:05:11 +0800

Hi all,

I separate a thread from thread "Message Flows", to discuss the format for
management messages, e.g. JSON, BSON, or others.

As Thomas's suggestion, before delving into the representation of the
information, we firstly identify what the contents of the different
signaling packets are, and in addition, what the data structures they may
use.

I would like to take the commands defined in draft-wang-6tsch-6top-00 as
starting point. Here are the parameters in those commands.

//integer
(1) xxxID, e.g. TrackID, SlotframeID
(2) xxxOffset, e.g. SlotOffset
(3) NumOfxxx/Length
(4) xxxLevel, QoSLevel, SecuirtyLevel, Priority
(5) Status
(6) ASN (5Byte integer), e.g. last time when a packet received from a
neighbor

//string
(7) L2 address
(8) SecurityKey

//bitmap
(9) LinkOption

//floating
(10) Metrics, e.g. PDR, ETX, queuing statistics, energy-related metrics

Maybe something else........

Now, we can evaluate different representation methods. What do you think?

Thanks
Qin

---

From: Qin Wang <[email-masked]>
Date: Tue, 20 Aug 2013 06:54:14 +0800

Hi Kris,

You are right. Security Key should be a structured data, besides the key
material, it should includes something like lifetime, KeyID, .....Correct?

Many thanks!

Qin

On Tue, Aug 20, 2013 at 5:14 AM, Kris Pister <[email-masked]> wrote:

>  is the security key a string?  That doesn't seem right.
>
> ksjp
>
>
> On 8/19/2013 2:05 PM, Qin Wang wrote:
>
> Hi all,
>
>  I separate a thread from thread "Message Flows", to discuss the format
> for management messages, e.g. JSON, BSON, or others.
>
> _______________________________________________
> 6tsch mailing [email-masked]://www.ietf.org/mailman/listinfo/6tsch
>
>
>

---

From: Thomas Watteyne <[email-masked]>
Date: Mon, 19 Aug 2013 23:07:45 -0700

Qin,

Thanks for starting the thread! I have comment which my sound a bit vague,
but it's on purpose :)

Do you envision that the flows will match the 6tos commands exactly? That
is, are you considering that the packets sent between different devices in
the network (PCE, motes, etc) contain the same commands as the 6top set of
commands from
http://tools.ietf.org/html/draft-wang-6tsch-6top-00#section-2.4?

Maybe we could by identifying the flows that we are considering, then the
contents of those packets (possibly described using some high level
representation such as JSON), and only then worry about their efficient
representation (e.g. BSON). Just a thought.

Thomas

On Mon, Aug 19, 2013 at 3:54 PM, Qin Wang <[email-masked]> wrote:

>>  I would like to take the commands defined in draft-wang-6tsch-6top-00
>> as starting point. Here are the parameters in those commands.
>>
>>  //integer
> 6tsch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tsch
>
>

---

From: Xavier Vilajosana Guillen <[email-masked]>
Date: Tue, 20 Aug 2013 06:28:53 -0700

Hi, one cent more to what Thomas says.

IMHO, the most important thing is the content and secondary is the
representation, at least at that time. So my feeling is that we need first
to identify the content, and later express it json,bson or any other
compressed format.

One possible way to think on that is go in a two way approach, bottom up
and top down, i.e someone needs to describe what the PCE,etc .. need,
another can take the 6top commands and go up from there. From this two
specifications we will be able to identify what is missing and how to match
things.

just thoughts.
X

---

From: Qin Wang <[email-masked]>
Date: Tue, 20 Aug 2013 21:39:16 +0800

Thomas,

I agree with you. Let's identify the control flows first.

Assume there is a management entity (ME) which may be exist in PCE (in
centrilized case) or upper layer of mote (in distributed caes). The control
flows discussed here are between ME and 6top of mote. Then, I think there
are three kinds of flows as follows.

(1) Action Flow. ME sends a action request (e.g. create/delete
hardcell/update/softcell, create/delete/update slotframe) to 6top, 6top
executes the action request, and then 6top responses confirmation message.
(2) Query Flow. ME sends a query (e.g. read neighbor, read statistics, read
timesource) to 6top, 6top responses the corresponding information in the
local MIB.
(3) Report Flow. According to some criteria configured in mote (e.g.
periodically), 6top reports the information in local MIB. From the 6top's
commands point of view, it is a kind of query triggered by 6top of mote
self.

What do you think?

Thanks
Qin

On Tue, Aug 20, 2013 at 2:07 PM, Thomas Watteyne <[email-masked]
> wrote:

---

From: Thomas Watteyne <[email-masked]>
Date: Tue, 20 Aug 2013 22:46:20 -0700

Qin,
I totally agree with these flows.
Thomas

On Tue, Aug 20, 2013 at 6:39 AM, Qin Wang <[email-masked]> wrote:

> (2) Query Flow. ME sends a query (e.g. read neighbor, read statistics,
> read timesource) to 6top, 6top responses the corresponding information in
> the local MIB.
> On Tue, Aug 20, 2013 at 2:07 PM, Thomas Watteyne <
>> Thanks for starting the thread! I have comment which my sound a bit
>> vague, but it's on purpose :)
>>
>>>>  I separate a thread from thread "Message Flows", to discuss the
>>>> format for management messages, e.g. JSON, BSON, or others.
>>>>

---

From: Qin Wang <[email-masked]>
Date: Thu, 22 Aug 2013 01:41:06 +0800

Hi Thomas, Xavi and all,

I went through the 6top commands defined in
http://tools.ietf.org/html/draft-wang-6tsch-6top-00#section-2.4 and put
them into the three control flows. See the attached file. As Xavi
suggested, it is bottom-up approach, thus, leaving lots of TODOs to
top-down approach.

It is just start point. Any comments and suggestions are welcome.

Qin

On Wed, Aug 21, 2013 at 1:46 PM, Thomas Watteyne <[email-masked]

>>> Do you envision that the flows will match the 6tos commands exactly?
>>> That is, are you considering that the packets sent between different
>>> devices in the network (PCE, motes, etc) contain the same commands as the
>>> 6top set of commands from
>>> Maybe we could by identifying the flows that we are considering, then
>>> the contents of those packets (possibly described using some high level
>>>> You are right. Security Key should be a structured data, besides the
>>>> key material, it should includes something like lifetime, KeyID,
>>>> .....Correct?
>>>>
>>>> Many thanks!
>>>>
>>>> Qin
>>>>
>>>>
>>>>>  As Thomas's suggestion, before delving into the representation of
>>>>> the information, we firstly identify what the contents of the different
>>>>>  I would like to take the commands defined
>>>>> in draft-wang-6tsch-6top-00 as starting point. Here are the parameters in
>>>>> those commands.
>>>>>
>>>>>  //integer
>>>>>  (6) ASN (5Byte integer), e.g. last time when a packet received from
>>>>> a neighbor
>>>>>
>>>>>  //string
>>>>> (7) L2 address
>>>>> (8) SecurityKey
>>>>>
>>>>>  //bitmap
>>>>> (9) LinkOption
>>>>>
>>>>>  //floating

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 21 Aug 2013 21:36:50 -0700

Qin,

Wonderful. I guess we could add a READ function for the LS mapping, too?
Although in your description you're assuming the ME installs the LS map, it
would be nice if we could use the same format in a mote distribute way in
the future (where some entity needs to query a node to learn its LS
mapping). Even in the presence of an ME, something can happen (power
failuer, bug) which requires it to retrieve what's already installed.

I believe Table 3 is missing some entry for the node to send a request to
the ME.

Thomas

On Wed, Aug 21, 2013 at 10:41 AM, Qin Wang <[email-masked]> wrote:

> On Wed, Aug 21, 2013 at 1:46 PM, Thomas Watteyne <
>>>>> On Tue, Aug 20, 2013 at 5:14 AM, Kris Pister <[email-masked]>wrote:
>>>>>

---

From: Qin Wang <[email-masked]>
Date: Thu, 22 Aug 2013 21:34:50 +0800

Thomas,

I add READ.labelswitch.status in Table 2 and Table 3.

But, I don't understand "Table 3 is missing some entry for the node to send
a request to the ME." very well. IMHO, the operations listed in Table 3 are
triggered by some internal events of a node, e.g. timer if a periodic
report is configured, and as result, the node will send some information in
local MIB to ME, instead of sending a request to ME. Correct? Do I miss
something?

Thanks
Qin

On Thu, Aug 22, 2013 at 12:36 PM, Thomas Watteyne <
[email-masked]> wrote:

>>>>> On Mon, Aug 19, 2013 at 3:54 PM, Qin Wang <[email-masked]>wrote:
>>>>>
>>>>>> Hi Kris,
>>>>>>
>>>>>>>  (6) ASN (5Byte integer), e.g. last time when a packet received
>>>>>>> from a neighbor
>>>>>>>
>>>>>>>  //string
>>>>>>> (7) L2 address
>>>>>>> (8) SecurityKey
>>>>>>>
>>>>>>>  //bitmap
>>>>>>> (9) LinkOption
>>>>>>>
>>>>>>>  //floating