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
