In the processing of rereading HC-04 on the way to possible WGLC, I
found some editorial defects, see:
http://trac.tools.ietf.org/wg/6lowpan/trac/query?component=hc
Jonathan and I are working on resolving those, but I'd sure like to
hear your comments.
I also ran into the following observation about destination address
compression.
(I'm going to abbreviate the last four bits of the IPHC base header in
the form M-DAC-DAM, e.g. 1-1-01 for the case mentioned in defect #34.)
It appears to me that the cases
0-0-00
0-1-00
1-1-00
all have exactly the same semantics: send the destination address in-
line.
I'm not going to address 0-0-00 and 0-1-00, because that part is used
by ISA100, and it's probably not worth diverging (although it might be
a good idea to reserve 0-1-00 in both documents).
But we can still fix 1-1-00 without creating a change there.
We know we are compressing a multicast address since the M bit is 1.
Two observations:
Multicast addresses always start with FF, which makes the first 8 bits
redundant.
Also, the last 13 bits of the multicast address might be encoded in
the MAC-layer destination address.
Do we want to make use of these up to 21 inferrable bits (or part of
them)?
Note that we can always fall back to 0-0-00 or 0-1-00 which are
perfectly capable of transporting multicast addresses.
Gruesse, Carsten
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
