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

Michael Richardson <> Tue, 06 January 2015 23:13 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1633B1A01CB; Tue, 6 Jan 2015 15:13:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lDJLgH6ySPKD; Tue, 6 Jan 2015 15:13:32 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B925A1A016A; Tue, 6 Jan 2015 15:13:32 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 0351320098; Tue, 6 Jan 2015 18:18:52 -0500 (EST)
Received: by (Postfix, from userid 179) id 585E0637FE; Tue, 6 Jan 2015 18:13:31 -0500 (EST)
Received: from (localhost []) by (Postfix) with ESMTP id 3D87A63745; Tue, 6 Jan 2015 18:13:31 -0500 (EST)
From: Michael Richardson <>
To: Ralph Droms <>
In-Reply-To: <>
References: <>, <> <> <> <> <>
X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Tue, 06 Jan 2015 18:13:31 -0500
Message-ID: <>
Cc: "" <>, "" <>, 6man WG <>, Routing Over Low power and Lossy networks <>, " WG" <>, "" <>, "" <>
Subject: Re: [Roll] [6tisch] [6lo] call for consensus for the RPL RPI / RH3 compression
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <>
List-Id: Routing Over Low power and Lossy networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 06 Jan 2015 23:13:36 -0000

Ralph Droms <> wrote:
    >> Ralph Droms <> 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 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

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  [
]        |   ruby on rails    [

Michael Richardson <>, Sandelman Software Works
 -= IPv6 IoT consulting =-