Jonathan Hui wrote:
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.
Hi, about address compression.
As people may be aware, MANET WG also designed a address (set)
compression scheme. See for example PacketBB (Packet Building Block)
draft-ietf-manet-packetbb-16.txt section C.1. Is there any relationship
between the two methods?
Alex
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
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
