Hi,
After talking back and forth with Julien, Pascal and Jonathan I have to
agree that there really isn't much better that we can do here without
splitting hairs. So I suggest that we just keep it as in the current
draft wrt multicast compression. Thanks to Jonathan anyways for
exploring the possibilities. So that one concern is now withdrawn ;-)
- Zach
Jonathan Hui wrote:
Hi Everyone,
During the WG meeting, one concern that was brought up is that support
for multicast destination addresses may be too complex.
Currently, the format supports the following forms:
1) FF02::00XX
2) FF0X::0XXX
3) FFXX::XX:XXXX
4) FFXX::00XX:XXXX:XXXX
5) FFXX:RIID:[plen][prefix]:XXXX:XXXX
- Case 1 supports the most common link-local cases (e.g. link-local
all-nodes/all-routers).
- Case 2 supports variable scoped multicast addresses.
- Case 3 supports longer well-known addresses (e.g. all-dhcp-servers).
- Case 4 supports solicited node and node information queries commonly
used in IPv6 ND.
- Case 5 supports Unicast-Prefix-based Multicast addresses.
I think everyone agrees that compressing multicast destination addresses
is necessary, but we should discuss what level of support is required.
Several months ago, some people (Julien in particular) discussed the
usefulness of each of the above cases.
Here are some of my comments:
- Support for cases 1, 3, and 4 are probably a good idea to support. We
could combine cases with higher compression into the ones with lower
compression, reducing implementation cost but trades wire-line
efficiency for those cases.
- Extra support only adds required complexity to the decompressor. The
compressor can always choose not to support certain cases and, in the
base case, can choose not to compress anything at all.
- As one data point, my current decompressor implementation requires 38
lines of code (with memcpy being the only function call) to support all
5 cases for multicast destination addresses. It could probably be
optimized for smaller code.
- It is very hard to add support in later revisions. There is no version
number in the protocol format. Even if there was, nodes would have to
negotiate and maintain state for which version is being used by its
neighbors.
In the end, my vote is to keep all of the multicast cases defined in the
HC doc, but would like to here what others think.
We are down to two open issues before we can LC the HC document (the
other being LOWPAN_NHC support for IPv6 extension headers). I'd like to
resolve these issues hopefully within the next week so that we can move
quickly towards LC. So send your thoughts!
Thanks.
--
Jonathan Hui
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
--
http://zachshelby.org - My blog “On the Internet of Things”
Mobile: +358 40 7796297
Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND
This e-mail and all attached material are confidential and may contain
legally privileged information. If you are not the intended recipient,
please contact the sender and delete the e-mail from your system without
producing, distributing or retaining copies thereof.
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
