Subject: [6lowpan] HC-04: fixes and redundancies

From: Carsten Bormann <[email-masked]>
Date: Tue, 12 May 2009 11:20:59 +0200

In the processing of rereading HC-04 on the way to possible WGLC, I  
found some editorial defects, see:

http://trac.tools.ietf.org/wg/6lowpan/trac/query?component=hc

Jonathan and I are working on resolving those, but I'd sure like to  
hear your comments.

I also ran into the following observation about destination address  
compression.
(I'm going to abbreviate the last four bits of the IPHC base header in  
the form M-DAC-DAM, e.g. 1-1-01 for the case mentioned in defect #34.)

It appears to me that the cases
0-0-00
0-1-00
1-1-00
all have exactly the same semantics: send the destination address in- 
line.

I'm not going to address 0-0-00 and 0-1-00, because that part is used  
by ISA100, and it's probably not worth diverging (although it might be  
a good idea to reserve 0-1-00 in both documents).
But we can still fix 1-1-00 without creating a change there.

We know we are compressing a multicast address since the M bit is 1.
Two observations:
Multicast addresses always start with FF, which makes the first 8 bits  
redundant.
Also, the last 13 bits of the multicast address might be encoded in  
the MAC-layer destination address.

Do we want to make use of these up to 21 inferrable bits (or part of  
them)?
Note that we can always fall back to 0-0-00 or 0-1-00 which are  
perfectly capable of transporting multicast addresses.

Gruesse, Carsten

---

From: Jonathan Hui <[email-masked]>
Date: Tue, 12 May 2009 09:30:38 -0700

Hi Carsten,

You are right that there is redundancy w.r.t. carrying the full  
destination address in-line. I think this was noted before. At the  
time someone did mention that leaving redundancy does potentially  
allow optimizations based on link-local vs. global and unicast vs.  
multicast properties of the destination address without having to  
fully recompose the address and interpreting a full IPv6 address.  
Because there were no objects (strong or minor) to the idea, we left  
the redundancy in.

However, I'm not aware of anyone actually making use of the proposed  
optimization by allowing redundancy in the format. So maybe we should  
revisit this?

--
Jonathan Hui

On May 12, 2009, at 2:20 AM, Carsten Bormann wrote:

> (I'm going to abbreviate the last four bits of the IPHC base header  
> in the form M-DAC-DAM, e.g. 1-1-01 for the case mentioned in defect  
> #34.)
>
> I'm not going to address 0-0-00 and 0-1-00, because that part is  
> used by ISA100, and it's probably not worth diverging (although it  
> might be a good idea to reserve 0-1-00 in both documents).
> Multicast addresses always start with FF, which makes the first 8  
> bits redundant.
> _______________________________________________
> 6lowpan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowpan

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 12 May 2009 22:47:00 +0200

On May 12, 2009, at 11:20, Carsten Bormann wrote:

> it might be a good idea to reserve 0-1-00 in both documents).

Actually, to maintain symmetry (and be able to use the same code path)  
between SAC/SAM and DAC/DAM, it would be a much better idea to specify  
0-0-00 as reserved (0-00 means :: = all zeros for SAC/SAM, which is  
not a valid destination address).

Gruesse, Carsten