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
