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
