Hi Daniel, > However, even with ICMP compression, there are some things that > are better addressed in the 6LowPAN-ND specification:-
I agree completely here. The ICMPv6 header compression would be as dumb as possible in all these regards. Maybe I'll try to whip something up quickly and submit it, just so everyone can understand the options I was thinking about. Regards, -Colin -----Original Message----- From: Daniel Gavelle [mailto:[email protected]] Sent: July 12, 2010 9:56 AM To: Colin O'Flynn Cc: 'Zach Shelby'; '6lowpan' Subject: Re: [6lowpan] Size of NS+ARO+SLLAO in nd-10 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
