On Jul 6, 2010, at 12:36 PM, Daniel Gavelle wrote: > 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.
In that case the Valid Lifetime field in 6CO should be changed to 16-bits with 10 second resolution as well. I agree this does save RAM space both on routers and border routers. 32-bit values are not efficient to deal with on 8-bit and 16-bit micro-controllers either. > 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. Exactly, this would be a huge savings if there is no other real use of the Target Address (I can't think of any for our case, but might be missing something). > I am not so keen on options 3 and 4 as they are changing the meaning of the > fields in RFC4861. Like it said, random thoughts ;-) Let's just forget I mentioned 3 and 4. > 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 really can't mess with PIO, but how about this. We make a rule that is a single PIO is present in an RA, then it is assumed that this is CID=0 by default. > 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. The title is "Neighbor Discovery Optimization for Low Power and Lossy Networks" - and I think that is the right direction. 6LoWPAN is our most important LLN here, but these optimizations could be applied elsewhere also. This will be important in moving this through the IESG as well I guess. Including the SLLAO in ND messages allows a priori L2 information to be exchanged between neighbors. The SLLAO/TLLAO are used for multihop DAD as well so that the 6LR doesn't have to save temporary state during DAD. I am not sure how well it would work to elide the SLLAO/TLLAO - it is more straightforward to have it always there (a clear MUST rather than a SHOULD...). Zach > > 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 > __________________________________________________ -- Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
