Re: [Roll] [6tisch] [6lo] call for consensus for the RPL RPI / RH3 compression

[Michael Richardson <[e-mail]>]

Ralph Droms <[e-mail]> wrote:
    > But ... in my opinion, moving the LLN artifacts to the header/dispatch
    > in the way defined in draft-thubert-6lo-routing-dispatch raises,
    > implicitly, an important architectural issue: is the information in the
    > dispatch header compressed IPv6 headers or headers for an independent,
    > sub-IP protocol?

My answer is that a sub-IP protocol can encapsulate arbitrary layer-3 packets.
In particular, one can have overlapping IP addressing contexts, and there is
no implicit l3-routing assumed between sub-IP protocols.
In the LLN case, the l3-layer is constrained; the additional "tag" (the RPL
Instance ID) is used to select a particular QoS much like the DSCP can do.
Routing between instanceIDs is assumed; but potentially not every node has
the specific routes that permits it to do that.

    > My understanding is that the IETF has made an architectural decision to
    > do all the mesh network forwarding and routing in IPv6, so as to reuse
    > as much as possible existing technology and associated infrastructure
    > such as OAM.  If the dispatch header does not contain compressed IPv6
    > headers, per se, then this architectural question would lead me to
    > investigate the completeness of the new protocol and the impacts of the
    > new protocol on IPv6 and network operations.

I think that all of the HC methods *can* be implemented as Bump-in-the-Stack
activities; and in particular the loop LLN->ethernet->LLN should be
lossless(%). (ethernet->LLN->ethernet is both out of scope [the LLN is never
a transit network], and also potentially lossy as some generality of 6553 and
6554 may sacrificed.

(%)-lossless definition assumes flow label is always zero.

A think that concerns me is that I think that most constrained devices will
not implement HC as a bump in the stack, but will uncompress the headers
directly into internal control structures, and may have loose the ability to
process uncompressed 6553/6554 headers.

One could view this as a vestigal appendix-like thing that evolved away.
This could be regarded as good: less unused/untested code that will get
exploited.   This could be regarded as bad: as frame sizes in LLN radios grow
(802.15.4g, I'm told, has much larger frames) some systems might have no
6lowpan layer, and interoperation opportunities might become difficult.

(I picked the appendix on purpose: some say that it was used to digest
grasses/cellulose. If we had a useful appendix, humans might never starve...)

--
Michael Richardson <[e-mail]>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-