Colin,
I think ICMP compression for 6LowPAN would make an interesting IETF
draft. However, even with ICMP compression, there are some things that
are better addressed in the 6LowPAN-ND specification:-
Changing timers from 32 bit 1 second to 16 bit 10 second needs to be
done in the 6LowPAN-ND spec as they won't be compressed with a generic
ICMP compression algorithm.
Allowing Context zero to be implied from the prefix will also save more
bits if done in 6LowPAN-ND, although a generic ICMP compression could
detect the duplicate address information and save most of the bits that
are common between the source address, prefix and context information.
If 6LowPAN-ND is now ND for LLNs, we need the sllao and tllao options
for MACs that don't allow the MAC address to be read by the higher
layer. The 6LowPAN ICMP compression algorithm you suggest could save
these duplicate bits for 6LowPAN networks.
Daniel.
Colin O'Flynn wrote:
Hello,
I like the idea of saving bits on the registration time.
Agreed, I see lots of benefits there (smaller message, less RAM on host, and
realistically I doubt you'd ever need below 10 seconds granularity).
I am not so keen on options 3 and 4 as they are changing the meaning of
the fields in RFC4861.
Also agree here as well. I could be swayed for option 3, I'm just not sure
it's worth the possible battle over changing already defined meanings.
However, this isn't generic for all MACs so this optimisation is only
valid if we are creating a 6LowPAN-ND for 15.4 networks only rather than
a generic ND for LLNs.
Should optimizations like this (eliding options, etc) go at the 6LoWPAN
layer itself? e.g.: like how there is UDP compression for 6LoWPAN, there
could also be a ICMPv6 compression header.
I'm not sure if that's pushing us into "layer hell" and needlessly
complicating things; I get the feeling it is. After all the draft itself is
called "6lowpan-nd", so presumably we can assume 6lowpan is below us?
On the other hand a suitably designed generic 6lowpan ICMPv6 compression
header could work without 6lowpan-nd even if someone wishes to do so. This
would allow eliding/compressing options if possible, without needing to
think too much at higher layers.
This could include compressing IP addresses inside options for instance in a
similar matter to addresses being compressed in the IPv6 header.
Regards,
-Colin
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Daniel Gavelle
Sent: July 6, 2010 10:36 AM
To: Zach Shelby
Cc: 6lowpan
Subject: Re: [6lowpan] Size of NS+ARO+SLLAO in nd-10
Zach,
I like the idea of saving bits on the registration time. The DAD table
also needs to hold a registration time for every node on the network so
reducing the lifetimes to 16 bits would save e.g. 1K of RAM on a 500
node network.
I also think a strict specification of the target address would be
useful in saving bytes and avoiding duplication of an address in the ARO.
I am not so keen on options 3 and 4 as they are changing the meaning of
the fields in RFC4861.
I also noticed an RA is fragmented at the 6LowPAN layer when I include a
112 bit CO. Some savings here would be useful, especially allowing
context zero to be specified by a flag in the PIO.
We could also save some space by eliding the sllao and tllao from the
Layer 2 MAC address. We elide addresses from the layer 2 in 6LowPAN.
However, this isn't generic for all MACs so this optimisation is only
valid if we are creating a 6LowPAN-ND for 15.4 networks only rather than
a generic ND for LLNs.
Daniel.
Zach Shelby wrote:
Looking through ND-10 I think we are getting pretty close to our limits in
the size of NS/NA+ARO+SLLAO.
NS/NA = 24 octets
ARO = 16-32 octets
SLLAO = 8-16 octets
Best case = 48 octets
Worst case = 72 octets
We have a request from e.g. backbone-router-02 to add a new 16-bit TID
field to ARO, and this is just one example for the future. There may be
other options to be carried in the NS as well. Is there anything we
can/should do to reduce the worst case for NS/NA? Some random thoughts:
1. What is Target Address in our unicast NS/NAs actually being used for
right now? Why don't we put the Registered Address there instead of in the
ARO option? That would save 16 octets.
2. Reduce the size of Registration Lifetime to 16-bits with e.g. 10 second
granularity. That frees up 16-bits of reserved space.
3. Change the Length of ICMPv6 options to 4 byte granularity. Would save
size in SLLAO for 16-bit addresses at least. Likely would save in other
options as well.
4. Make use of the 32-bits of reserved NS/NA space? I would rather not
start to re-define the NS/NA message though...
Other ideas, thoughts?
Zach
--
__________________________________________________
Daniel Gavelle, Software Engineer
Tel: +44 114 281 2655
Fax: +44 114 281 2951
Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK
Comp Reg No: 3191371 Registered In England
http://www.jennic.com
__________________________________________________
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
