Subject: [6tisch] Minimal: error in IE header examples

From: Simon Duquennoy <[email-masked]>
Date: Mon, 22 Jun 2015 13:21:18 +0200

Dear all,

I believe the example IE headers (for header/payload/MLME IEs) are wrong in
section 10.1 of the minimal draft. Some endianness confusion I guess:

1) Header IE: list termination:
len = 0 as bits 0-6
id = 0x7e as bits 7-14
type = 0 as bit 15
header = len + id << 7 which gives 0x3f00

=> with little endian encoding we get: 00 3F
=> in the document, it is currently 00 FC

2) Payload IE Header (MLME): 1A 88 seems correct

3) MLME-SubIE TSCH Synchronization:
len = 6 as bits 0-7
id = 0x1a as bits 8-14
type = 0 as bit 15
header = len + id << 8 which gives 0x1a06

=> with little endian encoding we get: 06 1A
=> in the document, it is currently 06 34

4) MLME-SubIE TSCH Timeslot:
len = 1 as bits 0-7
id = 0x1c as bits 8-14
type = 0 as bit 15
header = len + id << 8 which gives 0x1c01

=> with little endian encoding we get: 01 1C
=> in the document, it is currently 01 38

and so on..

My apologies if it is me misreading something.

One other minor remark: in section 10, when describing byte order, I would
suggest referring to "little-endian ordering" rather than "LSB format".

Thank you,
Simon

---

From: Simon Duquennoy <[email-masked]>
Date: Mon, 22 Jun 2015 16:00:41 +0200

Another error (I believe):
In 10.1, the slotframe and link IE is supposed to contain 1 slotframe with
handle 0, but the IE starts with 0101 (should be 0100)
Simon

On Mon, Jun 22, 2015 at 1:21 PM, Simon Duquennoy <[email-masked]> wrote:

> Dear all,
>
> I believe the example IE headers (for header/payload/MLME IEs) are wrong
> in section 10.1 of the minimal draft. Some endianness confusion I guess:
>

---

From: Jonathan Hui <[email-masked]>
Date: Mon, 22 Jun 2015 08:48:53 -0700

As someone who has implemented and deployed product that use IEEE
802.15.4e-2012 Information Elements, I agree with Simon's encodings.

--
Jonathan Hui

On Mon, Jun 22, 2015 at 4:21 AM, Simon Duquennoy <[email-masked]> wrote:

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

---

From: Xavier Vilajosana <[email-masked]>
Date: Mon, 22 Jun 2015 18:14:55 +0200

Dear Simon,

thanks for your comments. I might have messed bits up with endianness. I
will recheck again. Note that we read them from left to right being the
leftmost the least significative bit and the right most the most
significative bit.

in this case and taking the first element you mention

 7 zeros   0x7e    type 0
0000000011111100

if I convert this to hex where the least significant bit is the leftmost it
leads to
0x00 0x3F

as you indicate.

thanks so much for your comment!
X

2015-06-22 17:48 GMT+02:00 Jonathan Hui <[email-masked]>:

>> One other minor remark: in section 10, when describing byte order, I
>> would suggest referring to "little-endian ordering" rather than "LSB
>> format".
>>
>> Thank you,
>> Simon
>>
>>

---

From: Tengfei Chang <[email-masked]>
Date: Tue, 23 Jun 2015 22:39:00 +0800

I don't think 0x00 0x3F is right.

In section 5.2 of IEEE802.15.4 standard, the second paragraph said :

The frames in the MAC sublayer are described as a sequence of fields in a
specific order. All frame formats
in this subclause are depicted in the order in which they are transmitted
by the PHY, from left to right, where
the leftmost bit is transmitted first in time. Bits within each field are
numbered from 0 (leftmost and least
significant) to k – 1 (rightmost and most significant), where the length of
the field is k bits. Fields that are
longer than a single octet are sent to the PHY in the order from the octet
containing the lowest numbered bits
to the octet containing the highest numbered bits.

When transmitting the data, we should make sure b0 goest first.

*For termination header IE *
*1) Header IE: list termination:*
*len = 0 as bits 0-6*
*id = 0x7e as bits 7-14*
*type = 0 as bit 15*
*header = len + id << 7 which gives 0x3f00*

When transmitting the 00 3F, the bit transmitted by PHT is bit 7, not b0.

=> in the document, it is currently 00 FC: 0000000 01111110 0,

The first 7 bits goes is  len field bit0-bit6: 0000000, then goes ID:
b7-b14 7E 01111110, then type bit 15 0.

Which is Correct.

Tengfei

On Tue, Jun 23, 2015 at 12:14 AM, Xavier Vilajosana <
[email-masked]> wrote:

> if I convert this to hex where the least significant bit is the leftmost
> it leads to
> 0x00 0x3F
>
> as you indicate.
>

---

From: Jonathan Hui <[email-masked]>
Date: Tue, 23 Jun 2015 07:56:12 -0700

Tengfei,

Hex values are typically written in MSB order - this is different from IEEE
802.15.4 which writes bit strings out in LSB order.

For example:
IEEE 802.15.4: 10000000
is equivalent to
Hex: 0x01

So, w.r.t. the bytes being discussed:
IEEE 802.15.4: 00000000 11111100
is equivalent to
Hex: 0x00 0x3f

See the Annexes in IEEE 802.15.4 to see many more examples of hex
representations of MAC frames.

--
Jonathan Hui

On Tue, Jun 23, 2015 at 7:39 AM, Tengfei Chang <[email-masked]>
wrote:

> significant) to k – 1 (rightmost and most significant), where the length
> of the field is k bits. Fields that are
>>>> I believe the example IE headers (for header/payload/MLME IEs) are
>>>> wrong in section 10.1 of the minimal draft. Some endianness confusion I
>>>> guess:
>>>>

---

From: Tengfei Chang <[email-masked]>
Date: Tue, 23 Jun 2015 23:21:36 +0800

The hex value is correct. But I don't think this is the way to we should
follow to order the data. IEEE802.15.4 said we should transmit the first
bit, so we should follow this order.

Tengfei

On Tue, Jun 23, 2015 at 10:56 PM, Jonathan Hui <[email-masked]> wrote:

> Tengfei,
>
> Hex values are typically written in MSB order - this is different from
> IEEE 802.15.4 which writes bit strings out in LSB order.
>
> For example:
> IEEE 802.15.4: 10000000
> is equivalent to
> Hex: 0x01
>
>> the leftmost bit is transmitted first in time. Bits within each field
>> are numbered from 0 (leftmost and least
>> longer than a single octet are sent to the PHY in the order from the
>> octet containing the lowest numbered bits

---

From: Jonathan Hui <[email-masked]>
Date: Tue, 23 Jun 2015 08:27:07 -0700

As mentioned in my previous mail, the annexes in the IEEE 802.15.4
specification use the convention I outlined.

--
Jonathan Hui

On Tue, Jun 23, 2015 at 8:21 AM, Tengfei Chang <[email-masked]>
wrote:

>>> The frames in the MAC sublayer are described as a sequence of fields in
>>> a specific order. All frame formats
>>> in this subclause are depicted in the order in which they are
>>> transmitted by the PHY, from left to right, where
>>>> thanks for your comments. I might have messed bits up with endianness.
>>>> I will recheck again. Note that we read them from left to right being the
>>>> if I convert this to hex where the least significant bit is the
>>>> leftmost it leads to
>>>> 0x00 0x3F
>>>>
>>>> as you indicate.
>>>>

---

From: Tengfei Chang <[email-masked]>
Date: Tue, 23 Jun 2015 23:33:35 +0800

Jonathan ,

Could you pointed which annexes or a page I can refer to? Did it say that
is an example that transmitted by PHY?

Tengfei

On Tue, Jun 23, 2015 at 11:27 PM, Jonathan Hui <[email-masked]> wrote:

>>>> significant) to k – 1 (rightmost and most significant), where the
>>>> length of the field is k bits. Fields that are

---

From: Xavier Vilajosana <[email-masked]>
Date: Wed, 24 Jun 2015 17:53:19 +0200

Hi Tengfei,
this is confusing. Lets make sure this is the right way.

For me the problem is how do we transform an HEX WORD to 16bits

for example can be interpreted from left to right as LSB and from MSB being
right to left when transforming the binary representation to the Hex
representation

Taking this IE as example

if we consider that E in 0x7E is the least significative 4bits and least
significative bits are placed first (most left) we have:

 7 zeros   0x7e    type 0
0000000011111100

1) When transforming this to HEX we consider the least significative bits to
go first from left to right. So
LSb                           MSb
0000 0000 1111 1100
 0x0  0x0      0xF   0x3

  0x00          0x3F

2) Another option is to convert to hex by considering the MSb first within
the octet
                  MSb         LSb
0000 0000 1111 1100
 0x0  0x0      0xF   0x3

  0x00          0xFC

What is the right option? I am not sure but seems more reasonable to be 1)

Maybe those annexes in 15.4 can help to find the right answer.

regards,
Xavi

2015-06-23 17:33 GMT+02:00 Tengfei Chang <[email-masked]>:

>>>> On Tue, Jun 23, 2015 at 7:39 AM, Tengfei Chang <[email-masked]
>>>> > wrote:
>>>>
>>>>> The frames in the MAC sublayer are described as a sequence of fields
>>>>> in a specific order. All frame formats
>>>>>> thanks for your comments. I might have messed bits up with
>>>>>> endianness. I will recheck again. Note that we read them from left to right
>>>>>> being the leftmost the least significative bit and the right most the most
>>>>>> significative bit.
>>>>>>
>>>>>>>> One other minor remark: in section 10, when describing byte order,
>>>>>>>> I would suggest referring to "little-endian ordering" rather than "LSB
>>>>>>>> format".
>>>>>>>>
>>>>>>>> Thank you,
>>>>>>>> Simon
>>>>>>>>
>>>>>>>>

---

From: Xavier Vilajosana <[email-masked]>
Date: Wed, 24 Jun 2015 17:55:03 +0200

Sorry option 2 was incorrect.. too fast copy&paste

 0x0  0x0      0xF   0xC

  0x00          0xFC

regards,
X

2015-06-24 17:53 GMT+02:00 Xavier Vilajosana <[email-masked]>
:

> for example can be interpreted from left to right as LSB and from MSB
> being right to left when transforming the binary representation to the Hex
> representation
>
>> Could you pointed which annexes or a page I can refer to? Did it say
>> that is an example that transmitted by PHY?
>>
>> Tengfei
>>
>>>> The hex value is correct. But I don't think this is the way to we
>>>> should follow to order the data. IEEE802.15.4 said we should transmit the
>>>> first bit, so we should follow this order.
>>>>
>>>> Tengfei
>>>>
>>>>> On Tue, Jun 23, 2015 at 7:39 AM, Tengfei Chang <
>>>>> [email-masked]> wrote:
>>>>>
>>>>>> the leftmost bit is transmitted first in time. Bits within each
>>>>>> field are numbered from 0 (leftmost and least
>>>>>> The first 7 bits goes is  len field bit0-bit6: 0000000, then goes
>>>>>> ID: b7-b14 7E 01111110, then type bit 15 0.
>>>>>>
>>>>>> Which is Correct.
>>>>>>
>>>>>> Tengfei
>>>>>>

---

From: Simon Duquennoy <[email-masked]>
Date: Wed, 24 Jun 2015 21:54:59 +0200

Hello,

I believe what we want is the frame content as a series of bytes (not bits,
symbols or 16-bit words) in the order in which they are sent and received.
Here the second byte, in binary form starting with least significant bit,
is: 11111100 (as mentioned in your mail). That's unambiguously 0x3f (==
0b00111111, == 63).

Best regards,
Simon

On Wed, Jun 24, 2015 at 5:55 PM, Xavier Vilajosana <
[email-masked]> wrote:

> 2015-06-24 17:53 GMT+02:00 Xavier Vilajosana <
> [email-masked]>:
>
>> Hi Tengfei,
>> 2) Another option is to convert to hex by considering the MSb first
>> within the octet
>>                   MSb         LSb
>> 0000 0000 1111 1100
>>  0x0  0x0      0xF   0x3
>>
>>   0x00          0xFC
>>
>>
>>>> On Tue, Jun 23, 2015 at 8:21 AM, Tengfei Chang <[email-masked]
>>>> > wrote:
>>>>
>>>>>> Hex values are typically written in MSB order - this is different
>>>>>> from IEEE 802.15.4 which writes bit strings out in LSB order.
>>>>>>
>>>>>> For example:
>>>>>> IEEE 802.15.4: 10000000
>>>>>> is equivalent to
>>>>>> Hex: 0x01
>>>>>>
>>>>>>>>> On Mon, Jun 22, 2015 at 4:21 AM, Simon Duquennoy <[email-masked]
>>>>>>>>> > wrote:
>>>>>>>>>
>>>>>>>>>> Dear all,
>>>>>>>>>>
>>>>>>>>>> I believe the example IE headers (for header/payload/MLME IEs)
>>>>>>>>>> are wrong in section 10.1 of the minimal draft. Some endianness confusion I
>>>>>>>>>> guess:
>>>>>>>>>>
>>>>>>>>>> One other minor remark: in section 10, when describing byte
>>>>>>>>>> order, I would suggest referring to "little-endian ordering" rather than
>>>>>>>>>> "LSB format".
>>>>>>>>>>
>>>>>>>>>> Thank you,
>>>>>>>>>> Simon
>>>>>>>>>>
>>>>>>>>>>