Hi Carsten,
You are right that there is redundancy w.r.t. carrying the full
destination address in-line. I think this was noted before. At the
time someone did mention that leaving redundancy does potentially
allow optimizations based on link-local vs. global and unicast vs.
multicast properties of the destination address without having to
fully recompose the address and interpreting a full IPv6 address.
Because there were no objects (strong or minor) to the idea, we left
the redundancy in.
However, I'm not aware of anyone actually making use of the proposed
optimization by allowing redundancy in the format. So maybe we should
revisit this?
--
Jonathan Hui
On May 12, 2009, at 2:20 AM, Carsten Bormann wrote:
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
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
