Hi Jonathan
Please see inline
>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?
[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.
>
>Also, would you like to help out with the draft in fleshing out the
>separation of T/F as well?
>
[Pascal] Sure, no problem. I'll be glad to help out here.
Pascal
>--
>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
