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

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

Hi:

6LoWPAN HC and the new draft proposals (NHC, dispatch, all apart from the flow label) are encoding procedures that can be reversed so as to restore the original packet.
The term sub IP, should it refer to an encapsulation like a vlan, would be inappropriate. If it refers to an adaptation layer below IP, it would apply. 
But if the meaning is unclear, then we need to clarify before using it. 

Cheers,

Pascal


> -----Original Message-----
> From: ipv6 [mailto:[e-mail]] On Behalf Of Michael Richardson
> Sent: mercredi 7 janvier 2015 00:14
> To: Ralph Droms
> Cc: [e-mail]; [e-mail]; 6man WG; Routing
> Over Low power and Lossy networks; [e-mail] WG; [e-mail];
> [e-mail]
> Subject: Re: [6tisch] [6lo] [Roll] call for consensus for the RPL RPI / RH3
> compression
> 
> 
> 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]>, Sandelman Software Works  -=
> IPv6 IoT consulting =-
> 
>