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:
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
-----Original Message-----
From: Jonathan Hui [mailto:[EMAIL PROTECTED]
Sent: mardi 7 octobre 2008 20:34
To: Pascal Thubert (pthubert)
Cc: [email protected]
Subject: Re: [6lowpan] Separating T and F
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
On Oct 7, 2008, at 10:57 AM, Pascal Thubert (pthubert) wrote:
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
-----Original Message-----
From: Jonathan Hui [mailto:[EMAIL PROTECTED]
Sent: mardi 7 octobre 2008 18:50
To: Pascal Thubert (pthubert)
Cc: [email protected]
Subject: Re: [6lowpan] Separating T and F
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
On Oct 7, 2008, at 6:29 AM, Pascal Thubert (pthubert) wrote:
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 protected]
https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
