Subject: [6lowpan] Multicast address compression in hc01

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Wed, 8 Oct 2008 11:41:03 +0200

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-masked]
https://www.ietf.org/mailman/listinfo/6lowpan

---

From: Jonathan Hui <[email-masked]>
Date: Wed, 8 Oct 2008 08:05:48 -0700

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:

> 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.
> "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.
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 17 Oct 2008 16:10:58 +0200

> but hasn't been addressed on the ML yet. So thanks for brining it up

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

>  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.
> 
> 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
> 
> 
> 
>> 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 
>> 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 
>> 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 ...
>> 
>> does it make sense? Best, Julien
> 
> _______________________________________________ 6lowpan mailing list 
> [email-masked] 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-masked]
https://www.ietf.org/mailman/listinfo/6lowpan