Hi Pascal,
Pascal Thubert (pthubert) wrote:
>> Yup. The reason why I tied it to the eliding of L3 addresses is in the
>> case where each 15.4 node is doing L3 forwarding and modifying the Hop
>> Limit. I don't want a 15.4 node having to do a memmove() simply to
>> insert a Hop Limit when forwarding it to the next hop. But I am fine
>> with having a router that's forwarding to the outside world to eat this
>> cost. Maybe the rule should state if more than one IP hop is taken in
>> the PAN, then the Hop Limit must not be compressed.
>
> [Pascal] I would not use must :) but I see what you're saying. If you
> have RFD types of devices they wouldn't know what to expect. They can be
> configured to do one way or the other for a given deployment.
I'm not strongly opposed to a memmove() because of the differences in
computation vs. communication energy. However, I am opposed to doing
memmove() repeatedly just to forward a message. To save memory, I'm
guessing such insertions will occur in-place. That's why I was fishing
for ideas to see if there's ways to avoid it. I didn't want to start
going down a slippery slope.
> Note that with the single bit, we can not detect the case where a packet
> bounces from one router to another due to improper L2 operation but
> stays within the PAN.
If it's due to improper L2 operation, does having the Hop Limit field in
the L3 header help us?
>> I had originally proposed with HC1g to move HC2 after the compressed L3
>> header. In this scenario, putting NH into HC2 doesn't work because the
>> position of HC2 depends on whether the Next Hop field appears in the
>> compressed L3 header or not. If you look at the IPv6 header
>> architecture, the Next Header field always describes what header is
>> coming next. So it's a pretty well understood concept. In the 6LoWPAN
>> adaptation layer, however, we did design it in the way you suggest.
>>
> [Pascal] Remember I took great care to place the expanded NH after HC2.
> So that it works (see the note at the very bottom of this mail). Just
> that when you read HC2, if the HC bits are 0 you need to read the full
> HC after HC2 to parse the bits in HC2. I do think it's still cleanly
> putting L4 things together - and TLV is also a well understood concept
> ;)
Ah, I didn't see your note at the bottom. Rather than having the Next
Hop field be in potentially three different places, how about this idea:
Leave the L4C bit in HC1 as before, but rename it to NHC for next-header
compression (if NHC is 0, then the Next Header field is carried inline
and no HC2 header appears; if NHC is 1, then an HC2 header follows).
Then we define a HC2_UDP as follows:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|0|S|P|C| rsv |
+-+-+-+-+-+-+-+-+
The difference here is that we fix the first bit as '0' for UDP and
leave compression mechanisms for other Next Header values undefined for
now. As we define new NHC compression mechanisms, they can be added by
setting the first bit to '1' and some other bit-pattern following. It's
a huffman-style encoding, but we're just assuming that UDP is going to
be the most common case, so we give it the best case.
I've also taken out the 'L' option, opting to say that UDP length should
always be elided and derived from lower layers, just as we've done with
the IP header.
>> If we want flexibility in the HC1 header, I'd argue replacing VTF with
> a
>> bit that expands the HC1 header by another byte and put the VTF bit
>> there. I like reserving extra room in the HC2 header because I'd also
>> like to make provisions for using stateful compression of the UDP
> ports.
>
> [Pascal] But will that be enough anyway? Hard to know what to reserve
> for this so I'd do whatever seems right with what I have. I'd rather
> expand HC2 later with whatever room you need when you know more
> precisely what it is you need and leave VTF in place right now...
Agreed. I was just trying to see if there are other ways to leave
flexibility in the HC1 header.
--
Jonathan Hui
>
> Pascal
>
>> --
>> Jonathan Hui
>>
>>
>>> Pascal
>>>
>>>> -----Original Message-----
>>>> From: Jonathan Hui [mailto:[EMAIL PROTECTED]
>>>> Sent: jeudi 6 mars 2008 17:57
>>>> To: Pascal Thubert (pthubert)
>>>> Cc: 6lowpan
>>>> Subject: Re: HC1g and HC2g
>>>>
>>>>
>>>> Hi Pascal,
>>>>
>>>> I think it's reasonable to incorporate some of your ideas into HC1g.
>>> UDP
>>>> checksums make sense.
>>>>
>>>> I also understand the motivation for eliding the Hop Limit field.
> But
>>>> I'd like to find a way to make it only a single bit. The motivation
> for
>>>> this is in the following paragraph. To me, eliding the Hop Limit
> field
>>>> only makes sense when communicating over a single IP hop. How about
> a
>>>> single bit states if the HLIM is elided or not, and can only be
> elided
>>>> when one of the L3 addresses are completely elided. The latter
>>>> restriction ensures that Hop Limit is only elided on the 6LoWPAN
> side
>>>> for a single IP hop. Am I missing a case here?
>>>>
>>>> If we can remove one bit from HLIM, then I think we can move the NH
>>>> field back into HC1. I would remove the L4C bit and say that if NH
> is
>>>> non-zero, then HC2 must be included. I believe NH is still part of
> the
>>>> L3 header, so it should remain in HC1. The S, D, L, and C fields in
> HC2
>>>> should remain there because they are UDP specific. Also, I was
>>> proposing
>>>> to move HC2 to the start of the L4 header and putting the NH field
>>> there
>>>> seems strange to me.
>>>>
>>>> What do you think?
>>>>
>>>> --
>>>> Jonathan Hui
>>>>
>>>>
>>>> Pascal Thubert (pthubert) wrote:
>>>>> Hi Jonathan:
>>>>>
>>>>> We've been discussing HC1g quite extensively. I'd wish to discuss
>>>>> variations on your initial proposal:
>>>>>
>>>>> ------------------------------------------------------
>>>>> The LOWPAN_HC1g encoding as currently in the draft
>>>>>
>>>>> 0 1 2 3 4 5 6 7
>>>>> +---+---+---+---+---+---+---+---+
>>>>> | SC | DC |VTF| NH |L4C|
>>>>> +---+---+---+---+---+---+---+---+
>>>>>
>>>>> HC2g for UDP
>>>>>
>>>>>
>>>>> 0 1 2 3 4 5 6 7
>>>>> +---+---+---+---+---+---+---+---+
>>>>> | S | D | L | reserved |
>>>>> +---+---+---+---+---+---+---+---+
>>>>>
>>>>>
>>>>> ------------------------------------------------------
>>>>>
>>>>> What seeems to be missing:
>>>>>
>>>>> - Hop limit compression (takes 2 bits)
>>>>> - UDP checksum compression
>>>>>
>>>>>
>>>>> My proposal includes to keep using the mesh header format for route
>>> over
>>>>> to carry the short addresses and hop limit.
>>>>>
>>>>> 0 1 2 3 4 5 6 7
>>>>> +---+---+---+---+---+---+---+---+
>>>>> | SC | DC |VTF| Hlim |L4C|
>>>>> +---+---+---+---+---+---+---+---+
>>>>>
>>>>> HLIM:
>>>>> 00 not compressed
>>>>> 01 placed in the mesh header to count PAN hops
>>>>> 10 fully elided, packet generated inside the PAN
>>>>> 11 fully elided, packet came in a stub
>>>>>
>>>>>
>>>>>
>>>>> HC2g for UDP
>>>>>
>>>>>
>>>>> 0 1 2 3 4 5 6 7
>>>>> +---+---+---+---+---+---+---+---+
>>>>> | NH | S | D | L | C | rsvrd |
>>>>> +---+---+---+---+---+---+---+---+
>>>>>
>>>>> C: checksum is compressed.
>>>>>
>>>>> Note1: with that new format you need an HC2g to be able to compress
>>> NH.
>>>>> I do not mind.
>>>>> Note2: if NH is 0 then the NH is placed after the HC2G as it is
> taken
>>> as
>>>>> an L4 parm not between HC1G and HC2G. The parsing of bits 2..7
>>> depends
>>>>> on that NH.
>>>>>
>>>>> What do you think?
>>>>>
>>>>> Pascal
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
