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

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Michael

Please see inline

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

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:
>       IPsrc=ME, IPdst=THEM, RPLroot=him

Yes



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

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