Tero - thanks for the feedback. The goal is to make it quick and easy
for people to implement minimal correctly to enable interop, so any
advice on how we can streamline that process is welcome.
On 5/4/2015 5:08 AM, Tero Kivinen wrote:
When reading the draft once again, I noticed some more issues:
- The document goes to quite deeply in the explaining the format of
IEs, including the length and Sub-IDs etc, but it completely omits
the fact that most IEs we are talking about are MLME Nested IEs.
Good point. My understanding is that all of the IEs described in the
document are
nested MLME IEs except the ACK time correction IE.
I.e. the format of the data that will be included in the packet will
be:
<Header IEs> <Header Termination 1 IE> <MLME Payload IE>
The <MLME Payload IE> will then contain the IEs described in the
section 4. The <Header IEs> part will include the IE described in
section 5.
I.e in normal case the format will be:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length1 = 0 |Element ID=0x7f|0| Length2 = xxx |GrpId=1|1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length3 = 6 |Sub ID = 0x1a |0| ASN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASN |Join Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length4 = 1 |Sub ID = 0x1c |0| TT ID = 0x00 | Length5 = ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
That's helpful. It would probably be helpful to put a similar figure in
the minimal
draft, with explicit examples of the IEs that are necessary in an EB.
Where the Length1 is the length of Header Termination 1 IE, which is
the first 16-bits of the data, then next 16-bits is the MLME Payload
IE (Group ID = 1) and its length is in Length2, which then includes
all nested IEs inside it. The first nested IE would then be the Sync
IE with length of 6 and Sub ID of 0x1a etc...
I.e. if we copy that much of the 802.15.4 it would be better to copy
so much that people could actually implement it. Or better would be
just leave out stuff that is already in the 802.15.4 and only include
things that we need to say here.
I agree. What does the rest of the group think? Put in enough to
implement it,
or just point to 802.15.4 (-e, -2015, or -nothing pending resolution of
that debate)?
For example we could say that for TSCH Timeslot IE we always use the
Timeslot Template ID of 0x00 and there is no other data in the IE.
I believe that is exactly what the text says.
In 4.2.2: "Timeslot Template ID (b0-b7) = 0x00"
We could delete the rest of section 4.2.2 which describes what to do if
you *don't*
want the default timeslot template. Agree?
Especially as the format for rest of the IE is not accurate, as the
format specified there cannot be used in 915 MHz band, as default
values for macTsMaxTx and macTsTimeslotLength do not fit in the
16-bits allocated for them in IE. In latest revision the last fields
are either 2 or 3 octets and their length can be seen from the length
of the IE.
This parts of the document is bad because it includes too much
information to cause confusion, but too little information so you
cannot still implement anything based on this text.
We'll fix it, pending some input from the group on the questions above.
--
The section 8 says:
One of the
keys (K1) is used to authenticate EBs (all frame). As defined in
Section 4 EBs MUST be authenticated but payload not encrypted. This
prevents two independent networks to interfere or enable non-allowed
nodes to join a particular network.
Which would indicate that well-known keys cannot be used as K1, as
they do not authenticate the EBs.
Also I do not understand what the
This
prevents two independent networks to interfere or enable non-allowed
nodes to join a particular network.
is really trying to say in the "enable non-allowed nodes ..." part. If
it is trying to say that using real key as K1 will prevent nodes which
do not know the key for joining the network, then that is true, but it
is not true for for the well-known keys case. Well-known keys do NOT
provide that feature.
We have a proposal to replace this text. We should try to come to
resolution on that.
I'll send an email on that shortly.
ksjp
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
