Re: [6tisch] [6lo] Proposed improvement in RH3-6LoRH

[Simon Duquennoy <[e-mail]>]

Yes let me participate to the next 6TiSCH interim. I'll be also at the plugtest.
Will be much easier over voice ;)
Thanks,
Simon


On Wed, Jan 20, 2016 at 8:54 AM, Pascal Thubert (pthubert)
<[e-mail]> wrote:
> Our messages crossed, Simon.
>
>> - IPv6 stack interacting with the adaptation layer
>
> I'm not sure I agree with that (see my other mail), but if you're correct I really what to dig that and fix it.  Please read the other email I just sent and if you still see that the mapping is not there then please refine what the issue is exactly.
>
>
>> - No one-to-one mapping between a RH3-6LoRH and a RH3
>
> We can reconstruct an RH0 form from RH3 and from RH3-6LoRH, and recompress an RH0 into both as well. I fail to see what the problem is though I do hope that implementations never need to play that game. When the packet goes up the stack, the RH3-6LoRH should be gone, removed by the last router (which may be collocated).
>
> Would you be willing to participate to the next 6TiSCH interim? We'll discuss that topic since it impacts the plugtest.
>
> Cheers,
>
> Pascal
>
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]]
>> On Behalf Of Simon Duquennoy
>> Sent: mercredi 20 janvier 2016 08:44
>> To: Michael Richardson <[e-mail]>
>> Cc: Pascal Thubert (pthubert) <[e-mail]>; [e-mail];
>> Routing Over Low power and Lossy networks <[e-mail]>; Tengfei Chang
>> <[e-mail]>; [e-mail]
>> Subject: Re: [6tisch] [6lo] Proposed improvement in RH3-6LoRH
>>
>> Right, I'm using the wrong wording, I counted RFC6554 as RPL, sorry for the
>> confusion.
>>
>> What I don't like:
>> - IPv6 stack interacting with the adaptation layer
>> - No one-to-one mapping between a RH3-6LoRH and a RH3
>>
>> If I'm not mistaken, everything else in 6lowpan offers this one-to-one
>> mapping, and that allows the IPv6 stack to work independently of 6lowpan
>> (i.e. the same stack runs both in 6lowpan environment or not).
>> I also find this property nice, conceptually, as one can produce any
>> IPv6 packet and easily derive its compressed form, and back. One header
>> maps to one compressed header with all its fields compressed, etc.
>>
>> If I'm the only one to think this is an issue, I'm ready to close the issue.
>>
>> Thanks,
>> Simon
>>
>>
>> On Tue, Jan 19, 2016 at 11:06 PM, Michael Richardson
>> <[e-mail]> wrote:
>> >
>> > Simon Duquennoy <[e-mail]> wrote:
>> >     > Not really. It was rather my view of the architecture that differs a
>> >     > bit from what you describe in your previous mail.
>> >
>> > okay.
>> >
>> >     > For me RPL produces the RH3 and then passes the packet down the
>> stack
>> >     > for compression. Or for incoming packets, first there is
>> >     > decompression, then the IPv6 packet with its headers and extension
>> >     > headers are passed up to RPL etc. If find it odd to force upper layers
>> >     > to work on 6lowpan compressed formats.
>> >
>> > RPL is the thing in RFC6550, a routing protocol, that runs over ICMP ND
>> messages.
>> >
>> > I think the thing you are describing is the IPv6 stack, and you don't
>> > like that the IPv6 stack has to interact with the link adaptation layer.
>> >
>> > --
>> > Michael Richardson <[e-mail]>, Sandelman Software
>> Works
>> > IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/
>> >