Subject: Re: [Roll] [6lo] [6tisch] The "BEFORE" and "AFTER"

From: Michael Richardson <[email-masked]>
Date: Thu, 21 Jan 2016 15:06:37 -0500

Pascal Thubert (pthubert) <[email-masked]> wrote:
    > The non RPL source leaf sends a packet IPHC source = self dest = other leaf.

    > The 6LR adds the RPI but the IPHC and whatever comes after it stay untouched
    > and the packet flies to the root.

I think that we went through this in useofrpi....

I read the above sentence to say that the packet format is supposed to be:
    IP2 RPI IP1 ULP

which means that the the IP2 must say "6LR" to "Root", which implies that the
6LR knows what the root is.   That's an unavoidable interaction between RPL
and the IPv6 forwarding stack, and this is where I claim it's now about
6lowpan, but rather about mesh-over.

I think that for a locally generated packet, a
smart stack doesn't build those headers, but rather speaks directly to the
6LoRH part of the 6lowpan stack, and says:
      IPsrc=ME, IPdst=THEM, RPLroot=him

    > The root adds IP in IP 6LoRH, the updated RPI and the RH3 6LoRH(s) but still
    > the IPHC and whatever comes after it stay untouched.

The root removes the IP/RPI, and adds IP3/RH3. (We agreed that the RPI is
perhaps unnecessary).  IP3 = RPL hop before "THEM", which root knows.

I will read the rest of the text.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 22 Jan 2016 08:25:30 +0000

Hello Michael

Please see inline

> 6lowpan, but rather about mesh-over.

It is. The 6LR will have to decide which topology is used for that packet and encaps to the right root with the right RPI. This is no surprise. 

> I think that for a locally generated packet, a smart stack doesn't build those
> headers, but rather speaks directly to the 6LoRH part of the 6lowpan stack,
> and says:

Yes

> I will read the rest of the text.

The RPI is necessary to decide what the root is when the root is elided (at least if there is a possible confusion) I hope  that you'll find that the new text is clear on that.

About stack interaction, I see the compression of the root as a new instance of stateful compression:

With RFC6282, the state is provided to the stack by NDP, and NDP exchanges it through 6LoWPAN Context Option in RAs. In the compressed packet, the context is indexed by a Context Identifier Extension. 

With 6LoRH,  the state is provided to the stack by RPL, and NDP exchanges it through DODAGID in  DIO. In the compressed packet, the context is indexed by InstanceID in RPI. 

Cheers,

Pascal