Subject: [6lowpan] HC - Multicast Addresses

From: Jonathan Hui <[email-masked]>
Date: Tue, 7 Apr 2009 12:06:33 -0700

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

---

From: Zach Shelby <[email-masked]>
Date: Wed, 08 Apr 2009 15:23:11 +0300

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:
> 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.
> 
> - 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 
> - 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 
> - 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.
> 
> 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-masked]
> 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.