Hi Julien,
This mcast compression issue was brought up in the last WG meeting,
but hasn't been addressed on the ML yet. So thanks for brining it up
again.
Adhering to the 16-bit format was my attempt to keep the format as
simple as possible. I've been trying very hard to limit the number of
encoding variations. I've also been trying to address concerns of
keeping the base format compact. As you will see in my post to the "T
and F" thread, I've reduced the encoding to dispatch + 1-byte encoding
(1 byte less than the HC-01 draft).
So adding 1 bit will require either adding a full byte to the encoding
or stealing yet another bit from the dispatch. In all honesty, we
might want to consider giving HC a very short header type (similar to
mesh addressing and frag). I think there are unused bits with the frag
header, and stealing one to indicate frag vs. mesh would give us 13
bits to play with vs. 11 bits that I had in my last post. However,
this would require making a minor update to the frag header.
A separate question is whether or not increasing the group ID beyond
8/9 bits is useful. As you noted, most of the significant group ids
are trivially supported. The solicited node address is not used with
the ND/DAD proposal that we are currently working on (multicast over a
LoWPAN is not the most efficient).
What do people think?
--
Jonathan Hui
On Oct 8, 2008, at 2:41 AM, Julien Abeille (jabeille) wrote:
Hi Jonathan, all,
a few comments/questions about multicast address compression in hc-01:
- is there a need to respect the 16 bit address formats defined in
RFC4944 when compressing addresses. I though these formats were
defined for layer 2 16 bits addresses, while the compressed
addresses in the ip header are rather independant.
- with 9 bits group-id, we do not support sollicited node and a few
"well known" addresses (though most significant are supoprted),
should we work on a format with different length possible?
Also the current group-id mapping is stateful. A stateless model
would avoid the need to store many mappings, and seems feasible as
most group-ids start with a large number of 0 bytes.
we could use one more bit for destination address mode: something like
000 128
001 unicast 64
010 unicast 16
011 unicast 0
100 multicast 32 (for e.g. sollicited node), one byte flags + scope,
3bytes = last 3 bytes
101 multicast 24 flags + scope + last 2 bytes
110 multicast 16 bits : flags + scope + last byte
...
this way we also incorporate flags.
the issue is that we need one more bit for this...
does it make sense?
Best,
Julien
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
