Subject: [6lowpan] #88: Space optimization in RS/RA

From: "6lowpan issue tracker" <[email-masked]>
Date: Fri, 09 Jul 2010 07:42:30 -0000

#88: Space optimization in RS/RA
--------------------------------+-------------------------------------------
 Reporter:  zach@…              |       Owner:  zach@…            
     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.

 2. Allowing for a default CID=0 of some kind by usigng 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?

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

---

From: Zach Shelby <[email-masked]>
Date: Mon, 12 Jul 2010 14:47:12 +0300

> #88: Space optimization in RS/RA

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

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

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

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 14 Jul 2010 17:47:15 -0700

On 07/12/10 04:47 AM, Zach Shelby wrote:

> C = true if valid lifetime>  0, false if valid lifetime = 0

What happens when the 6LBR later needs to advertise a second prefix?
Does it first have to emit ABROs with Context flag= false and wait for 
some unknown amount of time until the implicit CID=0 information is no 
longer used? It clearly doesn't want to retire the PIO by setting its 
Valid Lifetime to zero.

Perhaps something like the above can be made to work, at the cost of 
more complex implementation in the hosts and routers and with some 
operational constraints on when and how a 2nd prefix can be added to the 
network.

Question is how to compare that added complexity with the savings of 
bytes on the wire. My takes is less complexity wins in this case.

    Erik