Subject: [6lowpan] Context-based header compression

From: Carsten Bormann <[email-masked]>
Date: Tue, 8 Jul 2008 00:31:37 +0200

Lowpanners,

I submitted a short draft on a simple header compression scheme.

> Filename:	 draft-bormann-6lowpan-cbhc-00.txt
> Title:		 Context-based Header Compression for 6lowpan
>
> Abstract:
> 6lowpan (RFC 4944) so far has only defined stateless forms of header
> compression.  This document specifies how a node and a router can
> agree on state that will allow much better header compression of
> global addresses.

I think this could combine well with draft-hui-6lowpan-hc-00.txt, but  
I haven't really done the integration work.

This draft is still in a very early stage.  Looking forward to comments.

Gruesse, Carsten

_______________________________________________
6lowpan mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6lowpan

---

From: Jonathan Hui <[email-masked]>
Date: Mon, 7 Jul 2008 19:12:25 -0700

Hi Carsten,

I'm supportive of this effort and have been working on similar  
improvements to the HC draft based on feedback from the last WG  
meeting. Support for different context IDs makes setup and teardown of  
context clean, as mentioned in your I.D. RAs are a natural place to  
advertise context information. Let me put some thoughts out on the  
encoding.

HC would benefit greatly by expanding the encoding to two bytes. For  
each address, 2 bits are already used to indicate the compressed  
address mode (0-bit, 16-bit, 64-bit, and full 128-bit). We can augment  
the encoding by adding another 2 bits for each address to carry the  
context ID. This approach is similar to yours, but differs in that it  
explicitly separates the context ID space from the address compression  
mode. In my mind, the compression prefix and address compression mode  
are orthogonal concepts. A single context ID can be used to support  
different address compression modes. For example, a single /64 prefix  
could be used along with 64-bit, 16-bit, or 0-bit compressed  
addresses. We could even reserve context ID 0 to be the link-local  
prefix. Using the same encoding for link-local and global addresses  
reduces encoding/decoding requirements.

Here's a proposed encoding format that incorporates the context ID  
mechanism, as well as a couple other improvements. Specifically, I've  
added a bit to HLIM based on past discussions within the WG. I've also  
used separate bits for Traffic Class and Flow Label. There's 3 extra  
bits, so there's still room to play with it a bit.

   0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| T |VF |NH | HLIM  |    rsv    |  SC   | SCtxt |  DC   | DCtxt |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

--
Jonathan Hui

On Jul 7, 2008, at 3:31 PM, Carsten Bormann wrote:

> I think this could combine well with draft-hui-6lowpan-hc-00.txt,  
> but I haven't really done the integration work.
>

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 8 Jul 2008 12:31:15 +0200

Hi Jonathan,

thanks for the comments.

On Jul 08 2008, at 04:12, Jonathan Hui wrote:

> it explicitly separates the context ID space from the address  
> compression mode. In my mind, the compression prefix and address  
> compression mode are orthogonal concepts. A single context ID can be  
> used to support different address compression modes. For example, a  
> single /64 prefix could be used along with 64-bit, 16-bit, or 0-bit  
> compressed addresses.

Do you have an example how that would work in practice?

I tried to separate out the contexts for the different prefix lengths  
because I couldn't quite imagine a useful case where you would use the  
same prefix bits at different lengths.
The separation allows a larger number of contexts to be available  
(while spending the same small number of per-packet bits), which helps  
with transitions between different context settings.
If I correctly read your diagram, you would only have four contexts;  
given that half of them might be tied up in a transition, this would  
leave about two, one for the prefix of the local link and one for  
exactly one potential correspondent.

Gruesse, Carsten

---

From: Jonathan Hui <[email-masked]>
Date: Tue, 8 Jul 2008 09:12:33 -0700

Hi Carsten,

On Jul 8, 2008, at 3:31 AM, Carsten Bormann wrote:
>> compression mode are orthogonal concepts. A single context ID can  
>> be used to support different address compression modes. For  
>> example, a single /64 prefix could be used along with 64-bit, 16- 
>> bit, or 0-bit compressed addresses.
>

Consider a::b where a is a /64 prefix and b is the 64-bit IID.
1) all 64-bits of b carried in-line in the compressed IPv6 header.
2) lower 16-bits of b carried in-line in the compressed IPv6 header.  
Other 48-bits are derived using the PAN ID (if we follow the IID  
generation guidelines of RFC 4944).
3) 0-bits of b carried in-line in compressed IPv6 header. b is derived  
from either the 6lowpan mesh header or the 802.15.4 link header.

I don't think we should be coupling the context ID with the address  
compression mode. Am I missing something? Or is this a plausible  
scenario?

--
Jonathan Hui