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
