Hi,
I'm quite lost with this new coding:
On Tue, Oct 7, 2008 at 23:14, Jonathan Hui <[EMAIL PROTECTED]> wrote:
>
> 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.
where is stored the prefix value ?
Laurent
>
> 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
>
>
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
