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
