Subject: [6tsch] format of management message

From: Qin Wang <[email-masked]>
Date: Tue, 27 Aug 2013 06:38:11 +0800

Dear All,

According to last Friday's call, we start the thread to discuss the format
of management message.

Background:
The management messages are exchanged between a Management Entity (ME) and
6top, and the ME can be existing in PCE or upper layer of 6top. In some
other threads, we have been discussing about the control flows and the
content of control flows, which can be used as reference.

Consideration:
(1) Where the format will be used? IMHO, the format, which we are talking
about, is only used to express the exchanged messages, it should not be
used in storage like MIB. Thus, Compacting is a process of translating the
data in storage format to the data in message format, and De-compacting is
a reverse process. Make sense?

(2) Criteria of evaluation.
    -- Compact data size
    -- Computational complexity of Compacting/De-compacting
    -- tool is existing or not
    -- .... more?

(3) Candidates: CBOR, JSON, BSON, and ......

Any comments and suggestions are welcome.

Thanks
Qin

---

From: Xavier Vilajosana Guillen <[email-masked]>
Date: Mon, 26 Aug 2013 15:56:00 -0700

Hi Qin,

I see it like you indicate at (1). The format and encoding is only used in
the payload of exchanged messages.

as regards to (2)
- 1) Computational complexity is a limiting factor if we want to be able to
run in 8bit uC. So this is important.
- 2) Compact data size. This can be easily experimented as soon as we have
some formats defined.
- 3) I don't think the tool is a problem as most of this formats have a
tool.

(3) I know about EXI (Efficeint XML) which compares to ASN.1. I am not an
expert of that and I do not know if BSON or CBOR perform better but it
might be another candidate.

X

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

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

---

From: Thomas Watteyne <[email-masked]>
Date: Tue, 27 Aug 2013 11:26:49 -0700

Qin,

Very much along the same line here. The scope of work item 1 from
https://bitbucket.org/6tsch/charter-ietf-6tsch/src/ is the format of the
data that is exchanged, i.e. what you would see if you started Wireshark. I
don't believe we are making any assumption on the way the data is stored
inside the devices. I believe it is safe to assume that this is
implementation-specific and out of scope.

Thomas

On Mon, Aug 26, 2013 at 3:56 PM, Xavier Vilajosana Guillen <
[email-masked]> wrote:

> - 1) Computational complexity is a limiting factor if we want to be able
> to run in 8bit uC. So this is important.
>> According to last Friday's call, we start the thread to discuss the
>> format of management message.
>>
>> Background:
>> The management messages are exchanged between a Management Entity (ME)
>> and 6top, and the ME can be existing in PCE or upper layer of 6top. In some

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

---

From: Qin Wang <[email-masked]>
Date: Fri, 30 Aug 2013 01:45:06 +0800

Hi Thomas, Xavi and all,

I did a comparison on some data coding methods (JSON, CBOR,UBJSON, BSON),
not completely yet. See the attached file.

I compare them from two angles, one is their data types, another one is the
overhead from the data format in storage to the data format in exchanged
messages.

Xavi, do you know the proper link for EXI?

Any input is welcome.

Thanks
Qin

On Wed, Aug 28, 2013 at 2:26 AM, Thomas Watteyne <[email-masked]
> wrote:

>> I see it like you indicate at (1). The format and encoding is only used
>> in the payload of exchanged messages.
>>
>> as regards to (2)
>> - 2) Compact data size. This can be easily experimented as soon as we
>> have some formats defined.
>>> (1) Where the format will be used? IMHO, the format, which we are
>>> talking about, is only used to express the exchanged messages, it should
>>> not be used in storage like MIB. Thus, Compacting is a process of
>>> translating the data in storage format to the data in message format, and
>>> De-compacting is a reverse process. Make sense?
>>>

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Thu, 29 Aug 2013 13:58:44 -0400

Hi Thomas,
                Are you looking for the EXI spec, such as
the one specified on this link?:

http://www.w3.org/TR/exi/#encodingDatatypes

                   Diego

2013/8/29 Qin Wang <[email-masked]>:
> On Wed, Aug 28, 2013 at 2:26 AM, Thomas Watteyne
> <[email-masked]> wrote:
>>
>> Qin,
>>
>> On Mon, Aug 26, 2013 at 3:56 PM, Xavier Vilajosana Guillen
>> <[email-masked]> wrote:
>>>
>>> Hi Qin,
>>>
>>> expert of that and I do not know if BSON or CBOR perform better but it might
>>> be another candidate.
>>>
>>> X
>>>
>>>
>>>> talking about, is only used to express the exchanged messages, it should not
>>>> be used in storage like MIB. Thus, Compacting is a process of translating
>>>> the data in storage format to the data in message format, and De-compacting
>>>> is a reverse process. Make sense?
>>>>

-- 
DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
www.ingenieria.udp.cl
(56 2) 676 8125

---

From: Xavier Vilajosana Guillen <[email-masked]>
Date: Thu, 29 Aug 2013 10:58:54 -0700

Hi Qin,

this is the EXI specification
http://www.w3.org/TR/exi/

I go through your document and I will come back with comments.
X

On Thu, Aug 29, 2013 at 10:45 AM, Qin Wang <[email-masked]> wrote:

> I compare them from two angles, one is their data types, another one is
> the overhead from the data format in storage to the data format in
> exchanged messages.
>
> On Wed, Aug 28, 2013 at 2:26 AM, Thomas Watteyne <
> [email-masked]> wrote:
>
>> Qin,
>>
>>> (3) I know about EXI (Efficeint XML) which compares to ASN.1. I am not
>>> an expert of that and I do not know if BSON or CBOR perform better but it