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

[Simon Duquennoy <[e-mail]>]

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/
>