Hi Xavier:
Since your email suggested the 802.15.4e-2012 spec is ambiguous, I
thought to check.
According to the 15.4e spec, the value of the IE List Present field in
the FCF signals whether or not IEs are included in the frame (see Clause
5.2.11.5b). Header and Payload IEs can be distinguished via the Type
field (bit 15: set to zero if Header IE; set to one otherwise) and are
self-contained TLV data objects (see Clauses 5.2.4.2 and 5.2.4.3).
Note that IEs should only be processed at receipt after successful
incoming frame security processing (i.e., IEs can be assumed to be
available in the clear for this discussion).
From this, it follows that one can easily find the demarcation line
between Header and Payload IEs if both are present (simply parse the
frame). Moreover, the set of Header IEs can be uniquely determined,
without requiring a special termination symbol. If there are no Payload
IEs, Header IEs may have the same syntax as the leftmost segment of the
MAC payload field (with Data frames, Beacon frames, ACK frames, and even
for Command frames [despite of the Command Type octet preceding the
remainder of the payload]). Hence, one needs a termination symbol
('comma symbol') to make sure one can unambiguously parse this.
Independent of presence of Header IEs, Payload IEs again can have the
same syntax as leftmost segments of the MAC payload and therefore
requiring a termination symbol ('comma' symbol).
For incoming security processing, one needs to be able to distinguish
the frame fields that constitute the 'm' field and the 'a' field in the
CCM mode of operation. If Header IEs are present, this does require a
termination symbol ('comma symbol'), since the encrypted payload field
has a chance of having the same syntax.
In summary,
- if security is enabled, Header IEs require a termination symbol (so as
not to confuse incoming security processing). This even holds if there
are no Header IEs (since the encrypted payload may still look like a
Header IEs);
- Payload IEs require a termination symbol (so as not to cause leftmost
segment of payload data to be confused with payload IEs). This holds
even if there are no Payload IEs and holds irrespective of whether
security is enabled.
So, if there are IEs (as indicated by the IE List Present field), one has
a) Header IEs present, Payload IEs present: need for termination symbol
for Header IEs, if security enabled; need for termination symbol for
Payload IEs if confusion with remainder payload possible. [2
"terminators" if security enabled; 1 if unsecured frame with payload
(4-octet overhead w/ security; o.w., 2-octets)]
b) Header IEs present, Payload IEs not present: need for termination
symbol for Header IEs if security enabled; need for termination symbol
for (empty set of) Payload IEs if confusion with remainder payload
possible. [2 "terminators" if security enabled; 1 if unsecured frame
with payload (4-octet overhead w/ security; o.w., 2-octets)]
c) Header IEs not present, Payload IEs present: need for termination
symbol for Header IEs if security enabled; need for termination symbol
for Payload IEs if confusion with remainder payload possible. [2
"terminators" if security enabled; 1 if unsecured frame with payload
(4-octet overhead w/ security; o.w., 2-octets)]
It is quite a pity that the IE termination symbols eat up so much
per-frame space, since this could easily have been avoided, e.g., if it
had been defined as follows:
- have IEs start with ID field, which would allow defining termination
symbols as 0xff (both for Payload and Header IEs), thus saving 2-octets
per frame in most cases;
-have IEs codify length, so as to allow unambiguously determining how
many Payload IEs actually follow, thus saving a Payload termination
symbol. {This would have allowed 1-byte "terminators" in total with
security and none at all, with careful design.}
Perhaps, removing some of the waste can be funneled back to 802.15.4rev?
On 6/16/2015 12:39 PM, Xavier Vilajosana wrote:
Hi Jose,
when writing the draft we consulted one of the authors of 15.4e about
the same issue. His answer said that the original intent when the spec
was drafted was that the termination IE was only required when a
header IE was followed by something. The problem is, if we get a frame
with no header IE, how do we know what follows is a payload IE, or it
is just payload that looks like a payload IE? In 15.4, where any frame
could come at any time, we need a header terminator to tell us how to
parse the rest of the packet.
so that is the reason for having it there. Any thoughts?
regards,
Xavi
2015-06-16 16:56 GMT+02:00 Thomas Watteyne <[email protected]
<mailto:[email protected]>>:
Jose,
I believe you need to add a header termination IE before sending a
payload IE. This was pointed out during our recent discussion;
I'll let the authors confirm.
The specs for the plugtest have been distributed on the plugtest
ML, please contact me offline if you didn't receive them.
Thomas
On Tue, Jun 16, 2015 at 9:18 AM, José Ángel Miranda
<[email protected] <mailto:[email protected]>> wrote:
Hi,
Looking at the new minimal conf (07- 08 - 09), we have
observed in the IEs example with and without security that a
termination Header IE, indicating Payload IE coming next, is
added. We would like to know where, within the standard, this
is described, or if you have taken this configuration due to
any specific reason. Actually, there is no need to add the
termination Header IE, as within the Payload IE you can easily
distinguish the type in the outer IE descriptor.
It would be nice to know if this configuration will be
required for the plugtest 17 - 18 Jul.
Another question related to the test specification document
for the this plugtest, have you already released this document
? and in that case, where can we find it?
Cheers,
Jose.
_______________________________________________
6tisch mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________
6tisch mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
--
email: [email protected] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
