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 _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
