Subject: [6lowpan] Separating T and F

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 7 Oct 2008 15:29:30 +0200

Hi Jonathan:

It troubles me though that we cannot isolate the T from the VF because I
can see the need to report congestion and to apply diffserv in route
over.

To give you examples, ISA cares (sometimes) about the flow label but not
the ToS bits because being mesh under this is all carried in MAC
extensions. And the ISA flow label needs only 2 bytes. And in many route
over case, I expect the reverse, caring about the ToS bits but not the
Flow Label.

Proposal: The VTF bit becomes "another HC byte for VTF", if the bit is
reset VTF fields are all compressed, if set then how to compress VTF is
in the next byte. Then we'd have control bits to say how many bytes to
TF follow and what's in there

Combinations we need to support:

No compression: Need 4 bytes. Control is 1111 and then 24 bits F and
then T 

Compressing T only: Need 3 bytes. Control is 1110 and then 24 bits F 

Precedence + 2 bytes Flow: Need 3 bytes. Control is 110 and then 2 bit
ECN,
	                             3 bits precedence and 16 bits
rightmost F

Compressing DSCP  : Need 3 bytes. Control is 10 and and then 24 bits F. 

Compress F: Need one byte. Control is 0 then 2 bit ECN and the next 5
bits are T striped from the rightmost bit. This is obtained by rotating
the byte by 3 so that the first bit is now the least significant DSCP
bit So that compression does not allow odd DSCPs but you'll notice that
most DSCPs are even)... This is also compatible with the precedence
model. See page 14 of attached doc for more.

What do you think?

Pascal

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

---

From: Jonathan Hui <[email-masked]>
Date: Tue, 7 Oct 2008 09:49:48 -0700

Hi Pascal:

Overall, I like the idea of separating T from F in the compression  
format. That is why I had separate bits for them in hc-01.  
Unfortunately, it meant adding a byte to the encoding. Here's one idea  
to extend the idea while keeping the encoding at 1 byte: what if we  
steal a bit from the dispatch value? The argument is that this HC  
should be used very often, so we can afford to take some of the  
dispatch space (similar to how Mesh Addressing and Fragmentation got 2- 
bit forms of the header identifier).

So here's one idea:

Base Encoding

     0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   | 0 | 1 | 0 | 0 | 1 |  CTX  |  TF   |NH | HLIM  |  SAM  |  DAM  |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

- Dispatch: 8-15
- CTX: Context
  - 00: Link-Local
  - 01: Global (1 context)
  - 10: Global (16 contexts)
  - 11: Reserved
- TF: Traffic Class, Flow Label
  - 00: 4-bit Pad + Traffic Class + Flow Label (4 bytes)
  - 01: ECN + 2-bit Pad + Flow Label (3 bytes)
  - 10: Traffic Class (1 byte)
  - 11: No Traffic Class and Flow Label
- NH: Next Header compression
- HLIM: Hop Limit
  - 00: uncompressed
  - 01: 1
  - 10: 64
  - 11: 255
- SAM: Source Address Mode - prefix is link-local, when compressed
  - 00: 128 bits
  - 01: 64 bits
  - 10: 16 bits
  - 11: 0 bits
- DAM: Destination Address Mode - prefix is link-local, when compressed
  - 00: 128 bits
  - 01: 64 bits
  - 10: 16 bits
  - 11: 0 bits

CTX is just to say what contexts we are using for compression - this  
is similar to using different dispatch values in the original  
proposal, except that we explicitly allocate the bits here. TF is now  
expanded to support 3 different encodings of Traffic Class and Flow  
Label. I think it simplifies the encoding (3 encodings vs. 5) and  
carries the full Traffic Class unmodified when uncompressed.

Does that satisfy your needs?

--
Jonathan Hui

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 7 Oct 2008 19:06:11 +0200

Hi Jonathan, 

that's perfect. Your proposal:

- enables the T/F separation
- enables the 2 contexts

All without adding an octet which was a dreadful idea. So I'm all for
it.
The only trouble I have is that ECN is located in various places making 
it harder for a forwarding node to locate and update. But I have no
better
proposal in mind either. Anyone?

If nobody complains I suggest to go for this change in the 01 release of
the WG doc.

Pascal

>-----Original Message-----
>From: Jonathan Hui [mailto:[email-masked]]
>Sent: mardi 7 octobre 2008 18:50
>To: Pascal Thubert (pthubert)
>Cc: [email-masked]
>Subject: Re: [6lowpan] Separating T and F
>
>
>Hi Pascal:
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 7 Oct 2008 19:57:36 +0200

Jonathan:

Let me propose a small delta for the context:

  - 00: Link-Local
  - 01: UL/Global (default context) 
  - 10: UL/Global (backup context) 
  - 11: UL/Global (16 contexts, a byte after the HC contains the
contexts for source and destination)

This way we can have the 2 contexts without the burden of the additional
byte, what do you think?

Pascal

---

From: Jonathan Hui <[email-masked]>
Date: Tue, 7 Oct 2008 11:33:48 -0700

Hi Pascal:

The challenge is that it would be nice to specify the context for the  
source and destination addresses individually. For example, I have two  
contexts: 1 for the PAN and 1 for the common peer/subnet that all  
nodes communicate with outside the PAN. Most of the time the encoding  
will use both contexts simultaneously. I could grab yet another bit  
from the dispatch, expand CTX to 3 bits then there's more than enough  
to do what you suggest.

What do you/others think?

--
Jonathan Hui

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 7 Oct 2008 22:53:59 +0200

Well, that's why I discussed a default and a backup context. If there is
a normal (default) context then both ends should be using it. If there's
renumbering going on, both ends should be able to switch to the backup. 

In that vision of things, source should match destination context so one
bit is enough for both, you see?

OTOH, if you need richness, then use 11 and you get 16 bits for source
and 16 bits for destination context. Though even so, IMHO, source and
destination contexts should be the same most times.

Pascal

>Sent: mardi 7 octobre 2008 20:34
>>>> To give you examples, ISA cares (sometimes) about the flow label
but
>>>> not
>>>> reset VTF fields are all compressed, if set then how to compress
VTF
>>>> is
>>>> Compressing DSCP  : Need 3 bytes. Control is 10 and and then 24
bits
>>>> F.

---

From: Jonathan Hui <[email-masked]>
Date: Tue, 7 Oct 2008 14:14:34 -0700

Just to make sure I understand you, let me throw out an example:

A - { IP network } - B

1) When both A and B are directly attached to the same IP link and  
communicate via link-local, they use CTX=00.
2) When both A and B belong to the same LoWPAN and communicate using  
the default global prefix for both source and destination addresses,  
the use CTX=01.
3) When both A and B belong to the same LoWPAN and communicate using  
the alternate global prefix for both source and destination addresses,  
they use CTX=10.
4) When A is a LoWPAN node and B is outside the LoWPAN, they use CTX=11.

The values of CTX are as you proposed in the previous email. Do you  
agree with these examples?

Also, would you like to help out with the draft in fleshing out the  
separation of T/F as well?

--
Jonathan Hui

On Oct 7, 2008, at 1:53 PM, Pascal Thubert (pthubert) wrote:

>>>>> Proposal: The VTF bit becomes "another HC byte for VTF", if the  
>>>>> bit
>>> is
>>>>> in the next byte. Then we'd have control bits to say how many  
>>>>> bytes
>>> to

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 7 Oct 2008 23:18:08 +0200

Hi Jonathan

Please see inline

>agree with these examples?

[Pascal] That's right. Reasoning is that the backup is used, like, to
transition during a renumbering phase while the default context is going
unavailable. So there's no point for either side of using it.

>separation of T/F as well?
[Pascal] Sure, no problem. I'll be glad to help out here.

Pascal

>>>>>> extensions. And the ISA flow label needs only 2 bytes. And in
many
>>>>>> route
>>>>>> over case, I expect the reverse, caring about the ToS bits but
not
>>>> the
>>>>>> Compressing T only: Need 3 bytes. Control is 1110 and then 24
bits
>> F
>>>>>>
>>>>>> Precedence + 2 bytes Flow: Need 3 bytes. Control is 110 and then
2
>>>>>> bit So that compression does not allow odd DSCPs but you'll
notice
>>>>>> that

---

From: "Laurent Toutain" <[email-masked]>
Date: Wed, 8 Oct 2008 11:59:22 +0200

Hi,

I'm quite lost with this new coding:

On Tue, Oct 7, 2008 at 23:14, Jonathan Hui <[email-masked]> wrote:

> 2) When both A and B belong to the same LoWPAN and communicate using the
> default global prefix for both source and destination addresses, the use
> CTX=01.
> 3) When both A and B belong to the same LoWPAN and communicate using the
> alternate global prefix for both source and destination addresses, they use
> CTX=10.

where is stored the prefix value ?

Laurent

> The values of CTX are as you proposed in the previous email. Do you agree
> with these examples?
>
>>>>> proposal, except that we explicitly allocate the bits here. TF is
>>>>>
>>>> now
>>
>>>>>> can see the need to report congestion and to apply diffserv in
>>>>>>
>>>>> route
>>
>>> over.
>>>>>>
>>>>>> over case, I expect the reverse, caring about the ToS bits but not
>>>>>>
>>>>> the
>>>>
>>>>> Flow Label.
>>>>>>
>>>>>> Proposal: The VTF bit becomes "another HC byte for VTF", if the bit
>>>>>>
>>>>> is
>>>>
>>>>>> in the next byte. Then we'd have control bits to say how many bytes
>>>>>>
>>>>> to
>>>>
>>>>>> No compression: Need 4 bytes. Control is 1111 and then 24 bits F
>>>>>>
>>>>> and
>>
>>> then T
>>>>>>
>>>>>> Compressing T only: Need 3 bytes. Control is 1110 and then 24 bits
>>>>>>
>>>>> F
>>
>>>
>>>>>> Precedence + 2 bytes Flow: Need 3 bytes. Control is 110 and then 2
>>>>>>
>>>>> bit
>>>>
>>>>> ECN,

---

From: Jonathan Hui <[email-masked]>
Date: Wed, 8 Oct 2008 08:05:21 -0700

Hi Laurent,

HC elides the prefix by relying on shared context (state established  
with all nodes in the LoWPAN). Every node in the LoWPAN stores the  
shared context so that they can meaningfully communicate without  
having to carry the full prefix in every packet.

--
Jonathan Hui

On Oct 8, 2008, at 2:59 AM, Laurent Toutain wrote:

> the alternate global prefix for both source and destination  
> addresses, they use CTX=10.
>