Subject: [6tisch] comments on 15.4 header fields in minimal

From: Xavier Vilajosana <[email-masked]>
Date: Tue, 21 Jul 2015 19:46:31 +0200

Hi,

>From the discussion today, the section mandating the use of certain 2012
specific configuration needs to be changed so we can be independent to the
evolution of the 15.4 spec.

The current text is:

The IEEE802.15.4 header of all frames MUST include the Sequence Number
field, the Source Address field and the Destination Address field.
In the Frame Control Field, this translates to:

the Frame Version field MUST be set to 0b10 (Frame Version 2)

the Sequence Number Suppression bit MUST be set to 0b0

the Source Addressing Mode MUST set to 0b11 (long address)

the Destination Addressing Mode MUST set to 0b11 (long address) except for
the broadcast address for which Destination Addressing Mode SHOULD set to
0b10 (short address). The use of long addresses is a REQUIRED as no
association procedure is defined in this document.

the PAN ID Compression bit MUST be set to 0b0. According to the Table 2a in
IEEE802154-2012 this translates into the Destination PAN ID field being
"Present" and the Source PAN ID field being "Not Present".

I propose the following text which I think is aligned with what has been
commented during the discussion.

The IEEE802.15.4 header of all frames MUST include the Sequence Number
field, the Source Address field and the Destination Address field and only
the Destination PANID. Source and destination address fields MUST be filled
with an extended address (64 bit) and this be indicated in the
corresponding Frame Control field. In case of a destination broadcast
address, the address field MUST be filled by a short addresses (16bit). The
Destination PANID MUST be present and the Source PANID MUST be elided.

Would that work?

regards,
Xavi

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 21 Jul 2015 22:12:08 +0000

Dear Xavi:

I think that if we indicate a bit setting, it must be against a particular version of the IEEE spec where the bits are defined, in this case 4e-2012.

The document would then state that for further versions of the document where the formatting is unknown at this time, the natural bit setting to obtain the same result is to be used. Unsure how to word that though.

Cheers,

Pascal

From: 6tisch [mailto:[email-masked]] On Behalf Of Xavier Vilajosana
Sent: mardi 21 juillet 2015 19:47
To: [email-masked]
Subject: [6tisch] comments on 15.4 header fields in minimal

Hi,

From the discussion today, the section mandating the use of certain 2012 specific configuration needs to be changed so we can be independent to the evolution of the 15.4 spec.

The current text is:

The IEEE802.15.4 header of all frames MUST include the Sequence Number field, the Source Address field and the Destination Address field.
In the Frame Control Field, this translates to:

the Destination Addressing Mode MUST set to 0b11 (long address) except for the broadcast address for which Destination Addressing Mode SHOULD set to 0b10 (short address). The use of long addresses is a REQUIRED as no association procedure is defined in this document.

the PAN ID Compression bit MUST be set to 0b0. According to the Table 2a in IEEE802154-2012 this translates into the Destination PAN ID field being "Present" and the Source PAN ID field being "Not Present".

I propose the following text which I think is aligned with what has been commented during the discussion.

The IEEE802.15.4 header of all frames MUST include the Sequence Number field, the Source Address field and the Destination Address field and only the Destination PANID. Source and destination address fields MUST be filled with an extended address (64 bit) and this be indicated in the corresponding Frame Control field. In case of a destination broadcast address, the address field MUST be filled by a short addresses (16bit). The Destination PANID MUST be present and the Source PANID MUST be elided.

Would that work?

regards,
Xavi

---

From: Robert Cragie <[email-masked]>
Date: Wed, 22 Jul 2015 07:21:25 +0100

Hi Xavi, Pascal,

Firstly, I preferred the old text as it is more explicit. The only thing
which needs to be changed is to refer to the 802.15.4e-2012 spec. (not just
802.15.4-2012 - that doesn't exist). Secondly, and most importantly: If we
state frame version 2, then the format won't change whatever happens to the
802.15.4 spec. as that is the rule regarding frame versions.

Robert

On 21 July 2015 at 23:12, Pascal Thubert (pthubert) <[email-masked]>
wrote:

>  Dear Xavi:
>
>
>
> I think that if we indicate a bit setting, it must be against a particular
> version of the IEEE spec where the bits are defined, in this case 4e-2012.
>
>
>
> The document would then state that for further versions of the document
> where the formatting is unknown at this time, the natural bit setting to
> obtain the same result is to be used. Unsure how to word that though.
>
>
>
> Cheers,
>
>
>
> Pascal
>
>
>
> *From:* 6tisch [mailto:[email-masked]] *On Behalf Of *Xavier
> Vilajosana
> *Sent:* mardi 21 juillet 2015 19:47
> *To:* [email-masked]
> *Subject:* [6tisch] comments on 15.4 header fields in minimal
>
>
>
> Hi,
>
>
>
> the PAN ID Compression bit MUST be set to 0b0. According to the Table 2a
> in IEEE802154-2012 this translates into the Destination PAN ID field being
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>

---

From: Pat Kinney <[email-masked]>
Date: Wed, 22 Jul 2015 01:26:52 -0500

As per our 6tisch meeting yesterday concerning the PAN ID compression bit table, I have attached an IEEE 802.15 document showing the changes to the latest revision draft. This document will act as guidance to the Technical Editor to modify the revision draft.  In summary, it was agreed that frames of version numbers “0” or “1" should revert to the instructions stated in IEEE 802.15.4-2011.  For frame version “2", new text will be inserted into the revision declaring the rules in a non-ambiguous fashion.

I would ask those interested in setting the header bits to read this document and respond with critiques or questions.

Thanks, Pat
 
Pat Kinney
Kinney Consulting LLC
IEEE 802.15 WG vice chair, TG chair
ISA100.11a WG chair
O: +1.847.960.3715
[email-masked] <mailto:[email-masked]>

On 21, Jul2015, at 12:46, Xavier Vilajosana <[email-masked]> wrote:

Hi,

The current text is:

Would that work?

regards,
Xavi

---

From: Xavier Vilajosana <[email-masked]>
Date: Wed, 22 Jul 2015 11:27:14 +0200

Hi, Pat, all

what is the secret squirrel? :)

In minimal we want to enforce a specific header configuration which enables
us to use long addresses, keeping the presence of the sequence number and
having only destination PANID. With the proposed text we do not specify any
specific configuration from any of the tables in 15.4 (any version).
Vendors will need to look into the spec they are implementing (either 2012
or 2015) and choose the appropiate configuration. IMHO, this is the most
general approach we can take as if the implementations are compliant with
our requirements they will be able to interoperate. As for frame version we
can enforce version 2 since we need IEs in most of the cases (at least for
minimal -- and please take into account the purpose of minimal --).

>From the attached document what we need is  (row 7)

Extended Extended Present Not Present 0

regards,
Xavi

2015-07-22 8:26 GMT+02:00 Pat Kinney <[email-masked]>:

> As per our 6tisch meeting yesterday concerning the PAN ID compression bit
> table, I have attached an IEEE 802.15 document showing the changes to the
> latest revision draft. This document will act as guidance to the Technical
> Editor to modify the revision draft.  In summary, it was agreed that frames
> of version numbers “0” or “1" should revert to the instructions stated in
> IEEE 802.15.4-2011.  For frame version “2", new text will be inserted into
> the revision declaring the rules in a non-ambiguous fashion.
>
> I would ask those interested in setting the header bits to read this
> document and respond with critiques or questions.
>
> Thanks, Pat
>
> Pat Kinney
> *Kinney Consulting LLC*
> [email-masked]
>
>
>

---

From: Pat Kinney <[email-masked]>
Date: Wed, 22 Jul 2015 04:36:50 -0500

Firstly, the secret squirrel is a page that shouldn’t have been in this document

Secondly, agreed, TSCH operation should focus on version 2 only due to the need for IEs.

Finally, given your intent to use long addresses with the destination PANID, the PANID compression bit should be set to 0

Pat

Pat Kinney
Kinney Consulting LLC

On 22, Jul2015, at 4:27, Xavier Vilajosana <[email-masked]> wrote:

Hi, Pat, all

In minimal we want to enforce a specific header configuration which enables us to use long addresses, keeping the presence of the sequence number and having only destination PANID. With the proposed text we do not specify any specific configuration from any of the tables in 15.4 (any version). Vendors will need to look into the spec they are implementing (either 2012 or 2015) and choose the appropiate configuration. IMHO, this is the most general approach we can take as if the implementations are compliant with our requirements they will be able to interoperate. As for frame version we can enforce version 2 since we need IEs in most of the cases (at least for minimal -- and please take into account the purpose of minimal --).

regards,
Xavi

2015-07-22 8:26 GMT+02:00 Pat Kinney <[email-masked] <mailto:[email-masked]>>:
As per our 6tisch meeting yesterday concerning the PAN ID compression bit table, I have attached an IEEE 802.15 document showing the changes to the latest revision draft. This document will act as guidance to the Technical Editor to modify the revision draft.  In summary, it was agreed that frames of version numbers “0” or “1" should revert to the instructions stated in IEEE 802.15.4-2011.  For frame version “2", new text will be inserted into the revision declaring the rules in a non-ambiguous fashion.

Thanks, Pat
 
Pat Kinney
Kinney Consulting LLC
IEEE 802.15 WG vice chair, TG chair
ISA100.11a WG chair
O: +1.847.960.3715 <tel:%2B1.847.960.3715>
[email-masked] <mailto:[email-masked]>

On 21, Jul2015, at 12:46, Xavier Vilajosana <[email-masked] <mailto:[email-masked]>> wrote:

Hi,

The current text is:

Would that work?

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

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

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 22 Jul 2015 14:31:38 +0300

> Extended Extended Present Not Present 0

For normal data frames yes, but not for periodic enhanced beacons, as
those will be sent to the broadcast address, i.e. the 2nd last row:

Extended	Short	Present		Not Present	1

This is because the broadcast address is presented as short address of
0xffff. And as the Source PAN ID and Destination PAN ID are same (or
actually you only have one meaningfull PAN ID), you need to compress
them and send only one, and set the PAN ID compression bit to 1.
-- 
[email-masked]

---

From: Xavier Vilajosana <[email-masked]>
Date: Wed, 22 Jul 2015 14:00:55 +0200

Hi Tero,

thanks, you are right. The proposed text is already indicating that.

"In case of a destination broadcast address, the address field MUST be
filled by a short address (16bit)."

regards,
Xavi

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 22 Jul 2015 15:55:14 +0300

Xavier Vilajosana writes:
> "In case of a destination broadcast address, the address field MUST
> be filled by a short address (16bit)."

Yes, but it might be good to say that explictly, as both data frames
(extended and extended addresses) and beacons (extended and short
addresses) both have only one PAN ID (destination PAN ID), and still
they have different values for PAN ID Compression field. I.e. with
extended and extended that is zero, and with extended and short that
is one...

-- 
[email-masked]

---

From: Xavier Vilajosana <[email-masked]>
Date: Thu, 23 Jul 2015 10:14:53 +0200

Dear Tero, Pat, Robert and all,

what about this more explicit text:

"The IEEE802.15.4 header of all frames MUST include the Sequence Number
field, the Source Address field and the Destination Address field and only
the Destination PANID. Frame Version field MUST be set to 0b10 (Frame
Version 2).

When using  DATA, ACKNOWLEDGEMENT, MAC COMMAND frame types the source and
destination address fields MUST be filled with an extended address (64 bit)
and this be indicated in the corresponding Frame Control field. The
Destination PANID MUST be present, the Source PANID MUST be elided and the
PANID Compression bit MUST be clear (0).

When using BEACON frame types, the destination address field MUST be filled
by a short addresses (16bit), the source address field MUST be filled with
an extended address (64 bit) and this be indicated in the corresponding
Frame Control field. The Destination PANID MUST be present, the Source
PANID MUST be elided and the PANID Compression bit MUST be set (1)."

Question: Do we cover with this a) people sticking to current 2012
amendment as published today, b) people sticking to new version coming soon?

Question: Should we say something about Multipurpose frames?

regards,
Xavi

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 23 Jul 2015 11:40:25 +0300

> what about this more explicit text:

Looks better.

> "The IEEE802.15.4 header of all frames MUST include the Sequence
> Number field, the Source Address field and the Destination Address
> field and only the Destination PANID. Frame Version field MUST be
> set to 0b10 (Frame Version 2).
> 
> When using  DATA, ACKNOWLEDGEMENT, MAC COMMAND frame types the
> source and destination address fields MUST be filled with an
> extended address (64 bit) and this be indicated in the corresponding
> Frame Control field. The Destination PANID MUST be present, the
> Source PANID MUST be elided and the PANID Compression bit MUST be
> clear (0). 
> 
> When using BEACON frame types, the destination address field MUST be
> filled by a short addresses (16bit), the source address field MUST
  	    ^^^^^^^^^^^^^^^^^

I would change to be "a broadcast short address" to be clear why we
use short address there.

Note, that there is also cases where beacons are not send to broadcast
address (i.e. when beacon request commands are used) but I think that
case is not for minimal.

> be filled with an extended address (64 bit) and this be indicated in
> the corresponding Frame Control field. The Destination PANID MUST be
> present, the Source PANID MUST be elided and the PANID Compression
> bit MUST be set (1)."
> 

For a) I cannot say, as it depends how the implementors resolved
internal conflicts in the standard. For b) answer is yes.

> Question: Should we say something about Multipurpose frames?

This is one of the problems with 802.15.4e-2012. Multipurpose frames
DO NOT USE this format at all. There is no PAN ID Compression field,
and there is only one PAN ID field in the header at all... So table 2a
should not have mentioned multipurpose frame at all.

The multipurpose frames have only one "Destination PAN Identifier"
which is optional, and no "Source PAN Identifier" at all. Whether the
"Destination PAN Identifier" is present depends on the "PAN ID
Present" field in the "MP Frame Control", so the rules for them are
completely different.

That means I do not think we need to mention them here, especially as
I do not think they are required for any minimal use cases. 
-- 
[email-masked]

---

From: Subir Das <[email-masked]>
Date: Thu, 23 Jul 2015 06:00:29 -0400

I am ok with the suggested mod  on broadcast and suggestion on not to
mention mutli-purpose frames.

-Subir

---

From: Pat Kinney <[email-masked]>
Date: Thu, 23 Jul 2015 06:05:51 -0500

I agree with Tero’s comments, but to the issue of the multipurpose frame, I would like to see it explicitly stated that multipurpose frames are not used by minimal.

Pat

Pat Kinney
Kinney Consulting LLC

On 23, Jul2015, at 3:40, Tero Kivinen <[email-masked]> wrote:

Looks better.

 	    ^^^^^^^^^^^^^^^^^

---

From: Jonathan Simon <[email-masked]>
Date: Fri, 24 Jul 2015 13:00:09 -0700

Pat - I’m noticing some differences between the proposed table and the one in 15.4-2012.

In 15.4-2012, the last 2 rows of table 2a are

SRC addr   DST addr    SRC PAN          DST PAN         PIDC
Present    Present     Not Present      Present         0    (row 12)
Present    Present     Not Present      Not Present     1    (row 13)
 
In the proposed table, rows 12-14 correspond to the 2012 row 12 case

SRC addr   DST addr    SRC PAN          DST PAN         PIDC
Extended   Short       Not Present      Present         1
Short      Extended    Not Present      Present         1
Short      Short       Not Present      Present         1

So the PIDC bit is inverted from the previous version for some address sizes, but for both extended addresses (new table row 7), you keep the original sense:

SRC addr   DST addr    SRC PAN          DST PAN         PIDC
Extended   Extended    Not Present      Present         1

This breaks backward compatibility for older applications that weren’t considering address size.

There is no row in the new table that corresponds to 2012 row 13 for mixed or short addresses.  This breaks our existing IP product implementation.

-- 
Jonathan

On Jul 21, 2015, at 11:26 PM, Pat Kinney <[email-masked]> wrote:

> <15-15-0561-03-0mag-yet-another-document-explaining-pan-id-compression (1).docx>
>

---

From: Robert Cragie <[email-masked]>
Date: Sat, 25 Jul 2015 19:39:24 +0100

I too have some concerns with the way the PAN ID compression is used for
frame version 2. Please see attached analysis regarding PAN ID compression.

Robert

On 24 July 2015 at 21:00, Jonathan Simon <[email-masked]> wrote:

> So the PIDC bit is inverted from the previous version for some address
> sizes, but for both extended addresses (new table row 7), you keep the
> original sense:
>
> There is no row in the new table that corresponds to 2012 row 13 for mixed
> or short addresses.  This breaks our existing IP product implementation.
>
> --
> Jonathan
>
> On Jul 21, 2015, at 11:26 PM, Pat Kinney <
> [email-masked]> wrote:
>

---

From: Jonathan Simon <[email-masked]>
Date: Sat, 25 Jul 2015 17:50:32 -0700

I noticed I said 15.4-2012 in my previous email.  I meant 15.4e-21012 in
case it wasn't clear.

On Sat, Jul 25, 2015 at 11:39 AM, Robert Cragie <[email-masked]

>> There is no row in the new table that corresponds to 2012 row 13 for
>> mixed or short addresses.  This breaks our existing IP product
>> implementation.
>>
>> --
>> Jonathan
>>
>> the Destination Addressing Mode MUST set to 0b11 (long address) except
>> for the broadcast address for which Destination Addressing Mode SHOULD set
>> to 0b10 (short address). The use of long addresses is a REQUIRED as no

---

From: Xavier Vilajosana <[email-masked]>
Date: Mon, 27 Jul 2015 06:52:45 +0200

Hi,

we discussed this concern at the IETF meeting. In minimal we wanted to
support what is already standardized (15.4e-2012) but it seems that if we
make things align to 2012 then we won't be compatible with 2015. If we try
to make the text less specific aiming to have people use the table they
want we loose some how the sense of minimal as different people
implementing it will have different configurations (specially PIDC bits
set).

So, what do we do?

2015-07-26 2:50 GMT+02:00 Jonathan Simon <[email-masked]>:

> On Sat, Jul 25, 2015 at 11:39 AM, Robert Cragie <
> [email-masked]> wrote:
>
>>> As per our 6tisch meeting yesterday concerning the PAN ID compression
>>> bit table, I have attached an IEEE 802.15 document showing the changes to
>>> the latest revision draft. This document will act as guidance to the
>>> Technical Editor to modify the revision draft.  In summary, it was agreed
>>> that frames of version numbers “0” or “1" should revert to the instructions
>>> stated in IEEE 802.15.4-2011.  For frame version “2", new text will be
>>> inserted into the revision declaring the rules in a non-ambiguous fashion.
>>>

---

From: Robert Cragie <[email-masked]>
Date: Mon, 27 Jul 2015 10:00:56 +0100

For some reason, it was deemed necessary to change PAN ID compression in
802.15.4-2012 for frame version 2 but there is an issue with the case where:

* both addresses are present
* either or both is a short address
* PAN ID compression is set to 1

In this case the inferred PAN ID is 0xffff but it is not possible to
distinguish an identical short address which may be allocated in different
PANs. So I believe the decision was to keep the original format for PAN ID
compression where either or both are short addresses but to change the
behaviour if both addresses are extended addresses. I have already pointed
out that this is a significant change from frame version 0/1 and changes
the meaning for PAN ID compression. See the analysis document I sent out
earlier.

I don't actually see how 802.15.4e-2012 Table 2a can actually be used as it
is erroneous as described above. I would be interested to know if anyone is
doing it this way, especially using PAN ID compression set to 1.

Robert

On 27 July 2015 at 05:52, Xavier Vilajosana <[email-masked]>
wrote:

>>>> From the discussion today, the section mandating the use of certain
>>>> 2012 specific configuration needs to be changed so we can be independent to
>>>> the evolution of the 15.4 spec.
>>>>
>>>> The current text is:
>>>>
>>>> the PAN ID Compression bit MUST be set to 0b0. According to the Table
>>>> 2a in IEEE802154-2012 this translates into the Destination PAN ID field
>>>> being "Present" and the Source PAN ID field being "Not Present".
>>>>