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

[Michael Richardson <[e-mail]>]

Ralph Droms <[e-mail]> wrote:
    >> 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,

    > "addressing contexts"?

It's a meaningless and ambiguous term, particularly in IPv6.  Perhaps there
is a better one in some BEHAVE document.
What I mean is that you can run ten different 10.0.0.0/8 RFC1918 networks
simultaneously on the same link using one of the 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;

    > ..instanceIDs covering intersecting sets of nodes; i.e., some nodes are
    > part of multiple instances?

Correct, any node could be part of multiple DODAGs which have been optimized
differently.  Whether those nodes will route traffic along a shorter path
than going to (respective) DODAG roots, and then out again is really outside
of our scope, let's just agree that it is a reasonable.
(Consider a powered light bulb router that participates in both the light
control DODAG, and also the TV remote control DODAG)

    >> but potentially not every node has
    >> the specific routes that permits it to do that.

    > Not sure how that relates to a sub-IP protocol for carrying source routes and RPL tags?

I guess it depends upon what you mean by "sub-IP".
I think that we are speaking about it in the former IETF AREA sense; things
which are below IP, which have a layering distinction from IP, and which
can simultaenously carry a multitude of layer-3 protocols.  MPLS for
instance.

Are you considering 6lowpan HC to be a sub-IP protocol?
Is PPP a sub-IP protocol?
Is PPP VJ compression a sub-IP protocol?

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

    > That statement gets to part of my question about
    > draft-thubert-6lo-routing-dispatch: in the abstract, is
    > draft-thubert-6lo-routing-dispatch intended to provide a mechanism
    > through which the original RPI, RH3 and IP-in-IP headers can be
    > reconstructed before sending the resulting IPv6 datagram up to the IPv6
    > stack?  At the risk of being overly concerned with the details, I
    > really mean "reconstruct the header" as opposed to "carry information
    > that can be used to perform the same function".

I think that this is the intent, and I see this as a good thing.

    >> and in particular the loop LLN->ethernet->LLN should be
    >> lossless(%).

    > ...where both LLNs and ethernet are part of the same RPL instance?

Yes, exactly: ethernet bridge of LLN between metal floors or other radio
opaque barriers.

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

    > Yeah.  We already see a side-effect of this form of implementation in
    > the desire for compression techniques that do not result in expansion
    > during transit, because such expansion can require re-fragmentation of
    > a datagram that might otherwise be forwarded in place without
    > explicitly uncompressing to the full IPv6 representation.

    >> 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 think there are also important issues to think about the interaction
    > between a sub-IP protocol and the rest of the IPv6 protocol.  If the
    > abstraction is that the sub-IP bits reconstruct into IPv6 headers, we
    > may have less collateral damage to worry about.  Documents defining
    > that behavior will beed to be careful to show the details and that the
    > conversions are lossless.

I agree completely.
One of the concerns I realized with rpl-flow-label was that it created an
alternative to 6553 which was not equivalent.  It's better actually, even on
Ethernet-like media.  It's also easier to implement in ASICs and current
protocol stacks because filters which match the flow label area available
already.  As such, if we go the rpl-flow-label way, we should probably
obsolete 6553 since we have present way to negotiate or announce what
should be used for a given network.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [


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