On Jul 9, 2010, at 10:42 AM, 6lowpan issue tracker wrote:

> #88: Space optimization in RS/RA
> --------------------------------+-------------------------------------------
> Reporter:  z...@…              |       Owner:  z...@…            
>     Type:  enhancement         |      Status:  new               
> Priority:  minor               |   Milestone:                    
> Component:  nd                  |     Version:                    
> Severity:  -                   |    Keywords:                    
> --------------------------------+-------------------------------------------
> Several space optimizations have been suggested for the information
> carried in RAs, in particular the combination of ABRO, PIO and 6CO is
> getting very large (already requires fragmentation). Can we avoid or
> minimize fragmentation by optimizing these somewhat? Current suggestions
> on the table:
> 
> 1.  PIO in classic ND only allows to set option length to 4 and there
> are 8 bytes you don’t use. Could we set it to 3 to save 8 bytes? The
> problem with this suggestion is that the last 8 bytes are used with the R
> bit is set.

Looks like this shouldn't be done, so as not to loose RFC4861 compatibility. 

> 2. Allowing for a default CID=0 using information in the
> PIO and/or ABRO options. Currently the prefix is carried in all 3 options:
> ABRO, PIO and 6CO. How to reduce the overlap?

I have a proposal here. We can elide the 6CO in cases where there is an RA with 
an ABRO and a single PIO. This can be done with a new flag in the ABRO (Context 
Flag) which indicates that the PIO in this message is used to form the CID=0 
context information. The elided 6CO fields are implied as:

Context Prefix = Prefix from PIO
Length = Length from PIO
CID = 0
C = true if valid lifetime > 0, false if valid lifetime = 0
Valid Lifetime = Valid Lifetime from PIO

This is actually going to be the setup in most 6LoWPAN networks, where a CID is 
assigned only to a single default prefix. This would typically save 16 bytes. 

Thoughts?  

Zach

> 
> 3. Colin suggested ICMPv6/ND optimization using HC next-header
> compression. Would it require us to add a work item for that in a future
> charter?
> 
> -- 
> Ticket URL: <http://wiki.tools.ietf.org/wg/6lowpan/trac/ticket/88>
> 6lowpan <http://tools.ietf.org/6lowpan/>
> 

-- 
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

Reply via email to