Subject: [6tisch] IEEE802.15.4 header fields in minimal

From: Xavier Vilajosana <[email-masked]>
Date: Fri, 3 Jul 2015 18:40:35 +0200

Hi all,

in the call today and thanks to the recent coding efforts due to the ETSI
plugtest we identified several fields that need to be agreed in order to
have an inter-operable minimal configuration. To materialize this I propose
the following section in the minimal draft. Please, provide your comments
and considerations before the cutoff date next Monday.

 ++++++
4. IEEE.802.15.4 Specific Header Fields and Considerations

   In order to ensure interoperability at the IEEE802.15.4 layer this
   documents proposes a set of rules that MUST be applied to ensure
   compliance with the minimal configuration.

      Use of long addresses in the IEEE802.15.4 header.  This is a
      mandatory requirement as a minimal network does not have a network
      entity nor the defined process to be able to map long addresses to
      short addresses upon the joining of a node.

      All IEEE802.15.4 frames MUST use Frame Version 0b10 (0x2) to
      support IEs.

      The PANID Compression field MUST be clear and source and
      destination addresses and the destination PANID MUST be present in
      the header according to the Table 2.A in [IEEE802154-2012].

      All 802.15.4 headers (including ACKs) MUST carry the Sequence
      Number to facilitate the detection of duplicate ACKs.

      ACKs MUST carry source and destination addresses and sequence
      number.  Addresses MAY be used as a mechanism to match requests
      with responses while sequence numbers MAY be used to detect
      duplicate ACKs.

Kind regards,
Xavi

---

From: Xavier Vilajosana <[email-masked]>
Date: Sat, 4 Jul 2015 12:29:10 +0200

Dear all, I updated the text to be more precise in the indications

Consider this one please.

      Set the Source and Destination Addressing Modes in the Frame
      Control field of the MAC Header to 0b11 (0x3) in order to use
      64bit addresses (long addresses).  This is a mandatory requirement
      as a minimal network does not have a network entity nor the
      defined process to be able to map long addresses to short
      addresses upon the joining of a node.

      All IEEE802.15.4 frames MUST set the Frame Version bits in the
      Frame Control field of the MAC Header to 0b10 (0x2) to support
      IEs.

      The PANID Compression bit in the Frame Control Field of the MAC
      Header MUST be clear (0b0) and source and destination addresses
      and the destination PANID MUST be present in the header according
      to the Table 2.A in [IEEE802154-2012].  This requires that the
      Source and Destination Addressing Modes bits of the Frame Control
      Field of the MAC Header MUST be both set to 0b11 (0x3).

      All 802.15.4 headers (including ACKs) MUST carry the Sequence
      Number to facilitate the detection of duplicate ACKs.  This is,
      the Sequence Number Suppression bit in the Frame Control field of
      the MAC Header MUST be clear (0).

      ACKs MUST carry source and destination addresses and sequence
      number.  Explicitly the bits PANID Compression of the Frame
      Control Field of the MAC Header MUST be clear (0b0), the Sequence
      Number Suppression bit MUST be clear (0b0) and the Source and
      Destination Addressing Modes MUST be both set to 0b11 (0x3).
      Addresses MAY be used as a mechanism to match requests with
      responses while sequence numbers MAY be used to detect duplicate
      ACKs.

Regards,
Xavi

---

From: Thomas Watteyne <[email-masked]>
Date: Sun, 5 Jul 2015 22:22:46 +0200

Xavi,
Great! I believe your text reflects the discussion we had during the last
call. However, I believe the information this text carries might be
compressed to the following, shorter, text. I believe both versions of the
text carry exactly the same information.
Thomas

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".
Addresses MAY be used to match an Acknowledgment frame to the frame it
acknowledges.
Sequence numbers MAY be used to detect duplicate frames.

On Sat, Jul 4, 2015 at 12:29 PM, Xavier Vilajosana <
[email-masked]> wrote:

> 2015-07-03 18:40 GMT+02:00 Xavier Vilajosana <
> [email-masked]>:
>
>> Hi all,
>>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 6 Jul 2015 12:10:46 +0300

>       Field of the MAC Header MUST be both set to 0b11 (0x3).

If I read that right, you are saying that we use 2nd last entry in the
table 2a, where both source and destination addreses are present,
frame version is 0b10, but where we do NOT have source PAN ID, but do
have destination PAN ID, and PAN ID compression is set to 0.

Looking at the 15-15-0130-03 document, at least Ben Rolfe tought that
entry in the table 2a is incorrect. I.e. the second last entry in the
table 2a should still have BOTH source and destination PAN IDs.

https://mentor.ieee.org/802.15/dcn/15/15-15-0130-03-0mag-proposed-pan-id-compression-table.docx

If the 2nd last line in table 2a is correct, there is no way to send
frame version 0b10 frames which has both source and destination PAN
IDs in it, and I have understood that this feature is something that
is actually used.

-- 
[email-masked]

---

From: Xavier Vilajosana <[email-masked]>
Date: Mon, 6 Jul 2015 11:18:43 +0200

Dear Tero,

Yes we are refering to the 2nd last line of table 2.a.

Most of us know that you are right and what you are indicting makes sense.
However vendors have already implemented or are implementing what an
standard document says (w.r.t table 2.a). At this point and understanding
that we had some consensus on only citing work that is already published as
standard we need to refer to table 2.a as it is now (in the 2012 version).

This is strange but if we adopt the changes proposed in some of this mentor
documents, how do we ensure that everybody that has implemented or is
implementing 15.4e  (2012) will  follow this amendments which are not part
of any standard yet.

What others think, does anybody have experience on such situations?

regards,
X

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 6 Jul 2015 13:56:46 +0300

Xavier Vilajosana writes:
> Most of us know that you are right and what you are indicting makes
> sense. However vendors have already implemented or are implementing
> what an standard document says (w.r.t table 2.a).

Are you sure about that? I.e. have you verified this from the vendors
themselves?

I mean, if they do implement this, then there is no way to provide
both PAN IDs for frame version 0b10 frames, and that means this
feature is not available for 802.15.4 at all.

> At this point and understanding that we had some consensus on only
> citing work that is already published as standard we need to refer
> to table 2.a as it is now (in the 2012 version). 

It would be better to verify this from the actual vendors implementing
this, and not to get fixated with the table 2.a... 

> This is strange but if we adopt the changes proposed in some of this
> mentor documents, how do we ensure that everybody that has
> implemented or is implementing 15.4e  (2012) will  follow this
> amendments which are not part of any standard yet. 

If I have understood correctly the document in mentor is trying to
reflect what vendors have implemented, i.e. what 802.15.4e was
supposed to say, and how it was implemented, not necessarely what was
written in 802.15.4e...

As this is confusing issue, it would be best to poll some vendors and
ask what they actually have implemented and specify that for our
draft.

This draft is the one that is used for the testing, so for that they
should implement what is said here. On the other hand if vendors have
ignored the table 2a in the 4e and instead implemented things
differently, it would be annoying to require them to change their
implementations just for the minimal testing, even when we are
following what 4e says...

> What others think, does anybody have experience on such situations?

I would suggest that those who are planning to participate in testing
to check their implementations and verify what they do and change the
draft to reflect that (provided there is one common way). If different
vendors have implemented this differently, then this question gets bit
harder to solve.
-- 
[email-masked]

---

From: Thomas Watteyne <[email-masked]>
Date: Mon, 6 Jul 2015 20:07:34 +0200

Tero,
One of the strong wishes of the participants of the plugtest is to stick to
the standards that are published. We therefore are following information
from Table 2a.
Thomas

On Monday, July 6, 2015, Tero Kivinen <[email-masked]> wrote:

> [email-masked] <javascript:;>
>
> [email-masked] <javascript:;>

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 7 Jul 2015 14:06:21 +0300

Benjamin A. Rolfe writes:
> There is certainly no intent, at least with any of the documents I
> have posted regarding PAN ID compression, to change behaviors as
> understood by those using 802.15.4e as published, the intention is
> to clear up ambiguity in amendment and correct obvious errors (like
> the inclusion of MP-frames in the PAN ID compression table, which
> makes no sense)

Yes. Luckily the MP-frames do not even have PAN ID compression field,
only the PAN ID Present flag, and source PAN ID always matches the
destination PAN ID...

Listing MP-frames in that table did confuse me originally...

> We received comments from people who could not unambiguously
> determine what to implement given the text published in 2012. It is
> therefore our job to "fix" the text so that it can be implemented
> consistently. There were also several errors introduced WRT the
> "legacy" behavior (frame version < 2) which were not intended by
> TG4e, such as losing the text which specified that PAN ID
> compression is only used when the source and destination PAN IDs are
> equal.

Reading table 2a in 802.15.4e indicates that there is no way to send
following frame:

	* Has IEs, i.e. requires 0b10 frame format
	* Has source address and source PAN ID
	* Has destination address and destination PAN ID
	* And those source and destination PAN IDs are not same

I.e. you cannot anymore send frames using 0b10 frame format from one
PAN to another... This is possible with frame format 0b00 or 0b01, but
if you want to use IEs or anything that requires 0b10 frame format,
then you are out of luck.

In your 15-15-0130-03 document you changed this to be possible by
changeing "short or extened" / "short or extened" / "0" (PAN ID
compression) / "Beacon, Data, Acknowledgement, Command", so that it
says "Present" / "Present" instead of "Not Present" / "Present" in PN
ID columns. 

So I assume this was one of those unambiguities you mentioned there?

> The point of querying implementers and developers of other
> specifications based upon the published standard is to resolve
> ambiguities in a rational and realistic way.  It would be of great
> help to the revision task if you can clarify what  "following the
> information from Table 2a" means specifically.

Yes...
-- 
[email-masked]

---

From: "Benjamin A. Rolfe" <[email-masked]>
Date: Mon, 6 Jul 2015 11:39:26 -0700

There is certainly no intent, at least with any of the documents I have 
posted regarding PAN ID compression, to change behaviors as understood 
by those using 802.15.4e as published, the intention is to clear up 
ambiguity in amendment and correct obvious errors (like the inclusion of 
MP-frames in the PAN ID compression table, which makes no sense).  We 
received comments from people who could not unambiguously determine what 
to implement given the text published in 2012. It is therefore our job 
to "fix" the text so that it can be implemented consistently. There were 
also several errors introduced WRT the "legacy" behavior (frame version 
< 2) which were not intended by TG4e, such as losing the text which 
specified that PAN ID compression is only used when the source and 
destination PAN IDs are equal.

The point of querying implementers and developers of other 
specifications based upon the published standard is to resolve 
ambiguities in a rational and realistic way.  It would be of great help 
to the revision task if you can clarify what  "following the information 
from Table 2a" means specifically.

Thanks for the consideration

Benjamin A. Rolfe
Blind Creek Associates

On 7/6/2015 11:07 AM, Thomas Watteyne wrote:
> Tero,
> One of the strong wishes of the participants of the plugtest is to 
> stick to the standards that are published. We therefore are following 
> information from Table 2a.
> Thomas
>
> On Monday, July 6, 2015, Tero Kivinen <[email-masked] 
> <mailto:[email-masked]>> wrote:
>

---

From: "Benjamin A. Rolfe" <[email-masked]>
Date: Tue, 7 Jul 2015 11:45:38 -0700

Tero is correct that there are errors in Table 2a from 802.15.4e-2012 - 
things in the table inconcistentet with text and clearly not intended.
This is what the revision team is trying to fix. Input from implementers 
and users will help ensure we "fix" it instead of just breaking it 
differently.

BR
Ben