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

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 22 Aug 2013 19:00:11 +0000

Perfect sync : )

The questions top down are which device talks to which devices and to express what.
Now it's good to have an idea of the formalism we expect to be using to make sure that it fits as we refine our work.
Carsten will participate to the call tomorrow to present CBOR.

Cheers,

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of Xavier Vilajosana Guillen
Sent: mardi 20 août 2013 15:29
To: Thomas Watteyne
Cc: [email-masked]
Subject: Re: [6tsch] data structure and format for management packets

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

On Mon, Aug 19, 2013 at 11:07 PM, Thomas Watteyne <[email-masked]<mailto:[email-masked]>> wrote:
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]<mailto:[email-masked]>> wrote:
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]<mailto:[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.

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

_______________________________________________

6tsch mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/6tsch

_______________________________________________
6tsch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tsch

_______________________________________________
6tsch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tsch

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 22 Aug 2013 16:19:19 -0700

Qin,

I wasn't clear, sorry! What I mean is, if I'm a node in the network and
suddently I feel like sending 10 pkts/s to a different node, how do I let
the ME know to it can provision the slots?

Thomas

On Thu, Aug 22, 2013 at 12:00 PM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

>  Perfect sync : )****
>
> ** **
>
> The questions top down are which device talks to which devices and to
> express what.****
>
> Now it’s good to have an idea of the formalism we expect to be using to
> make sure that it fits as we refine our work.****
>
> Carsten will participate to the call tomorrow to present CBOR.****
>
> ** **
>
> Cheers,****
>
> ** **
>
> Pascal****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Xavier Vilajosana Guillen
> *Sent:* mardi 20 août 2013 15:29
> *To:* Thomas Watteyne
> *Cc:* [email-masked]
> *Subject:* Re: [6tsch] data structure and format for management packets***
> *
>
> ** **
>
> 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****
>
> ** **
>
> On Mon, Aug 19, 2013 at 11:07 PM, Thomas Watteyne <
> [email-masked]> wrote:****
>
> 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:***
> *
>
> 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:***
> *
>
> 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.****
>
> ** **
>
> 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****
>
> ** **
>
> ** **
>
>   ****
>
> ** **
>
> _______________________________________________****
>
> 6tsch mailing list****
>
> [email-masked]****
>
> https://www.ietf.org/mailman/listinfo/6tsch****
>
>  ** **
>
> ** **
>
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tsch****
>
> ** **
>
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tsch****
>
> ** **
>

---

From: Qin Wang <[email-masked]>
Date: Fri, 23 Aug 2013 21:10:21 +0800

Thomas,

We can separate centralized case and distributed case to think about it.

(1) centralized case: PCE will configure the report/alarm criteria and
provision tracks used for the node to send message to the ME in PCE in
advance, so, the ME in PCE should be well prepared when the node is sending
the 10pkts/s.

(2) distributed case: the ME is in the upper layer of the same node, so
event-driven mechanism can be used.

Make sense?

Qin

On Fri, Aug 23, 2013 at 7:19 AM, Thomas Watteyne <[email-masked]
> wrote:

>> *From:* [email-masked] [mailto:[email-masked]] *On
>> Behalf Of *Xavier Vilajosana Guillen
>> *Subject:* Re: [6tsch] data structure and format for management packets**
>> **
>>
>> ** **
>>
>> Thanks for starting the thread! I have comment which my sound a bit
>> vague, but it's on purpose :)****
>>
>> ** **
>>
>> On Mon, Aug 19, 2013 at 3:54 PM, Qin Wang <[email-masked]> wrote:**
>> **
>>
>> Hi Kris,****
>>
>> ** **
>>
>> On Tue, Aug 20, 2013 at 5:14 AM, Kris Pister <[email-masked]> wrote:**
>> **
>>
>> I separate a thread from thread "Message Flows", to discuss the format
>> for management messages, e.g. JSON, BSON, or others.****
>>
>> ** **
>>
>> (10) Metrics, e.g. PDR, ETX, queuing statistics, energy-related metrics**
>> **
>>
>> ** **
>>

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 23 Aug 2013 07:49:14 -0700

Qin,
Could we please bring this up when presenting your section during the call
in 15min?
Thanks,
Thomas

On Fri, Aug 23, 2013 at 6:10 AM, Qin Wang <[email-masked]> wrote:

> On Fri, Aug 23, 2013 at 7:19 AM, Thomas Watteyne <
> [email-masked]> wrote:
>
>> Qin,
>>
>>> *Subject:* Re: [6tsch] data structure and format for management packets*
>>> ***
>>>
>>> ** **
>>>
>>> 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
>>> On Mon, Aug 19, 2013 at 3:54 PM, Qin Wang <[email-masked]> wrote:*
>>> ***
>>>
>>> Hi Kris,****
>>>
>>> ** **
>>>
>>> On Tue, Aug 20, 2013 at 5:14 AM, Kris Pister <[email-masked]> wrote:*
>>> ***
>>>
>>> (10) Metrics, e.g. PDR, ETX, queuing statistics, energy-related metrics*
>>> ***
>>>
>>> ** **
>>>

---

From: Qin Wang <[email-masked]>
Date: Fri, 23 Aug 2013 22:52:02 +0800

Sure!

Qin

On Fri, Aug 23, 2013 at 10:49 PM, Thomas Watteyne <
[email-masked]> wrote:

>>>> *Subject:* Re: [6tsch] data structure and format for management packets
>>>> ****
>>>>
>>>> ** **
>>>>
>>>> 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,
>>>> On Mon, Aug 19, 2013 at 3:54 PM, Qin Wang <[email-masked]> wrote:
>>>> ****
>>>>
>>>> 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:
>>>> ****
>>>>
>>>> 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****
>>>>
>>>> Now, we can evaluate different representation methods. What do you
>>>> think?****
>>>>
>>>> ** **
>>>>
>>>> Thanks****
>>>>
>>>> Qin****
>>>>
>>>> ** **
>>>>
>>>> ** **
>>>>
>>>>   ****
>>>>
>>>> ** **
>>>>