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

Ralph Droms <> Tue, 06 January 2015 19:40 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id F3CBE1A1B34; Tue, 6 Jan 2015 11:40:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BnetIxXrzfaz; Tue, 6 Jan 2015 11:40:44 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B500C1A1AA8; Tue, 6 Jan 2015 11:40:44 -0800 (PST)
Received: by with SMTP id s7so17003756qap.14; Tue, 06 Jan 2015 11:40:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=c2dSJTgsnSvMeCXfCDkHqCTAory24XN31jK8ud/2cE4=; b=RnhbWBvj3DQX/ax97jVeuG4l6yqj56AYDJm4J++99EwMACwgNcXSsnjX6vDNz35fbX hzuQNlb421KKnm6nlcIEaDlNeZ/Rv3Kev54JIBAHQV11pD1NgymnwY23M7Adh1MKcOg2 QymSmOwbnwC/U+b/3BppS+468z3sjCmPR/CagTrJ/SSsdJMT2FPDbE2W/psu7pfedb57 +sQeHobsJLRgGxNv65RbUN5a3t3tKmt0VXxhFHm5w8YNNskpqN2JhkyMHQP56wz4CPhf m5P1HcFwPxiSkjEeZ18m9qcJqJadWK1QBCXxLNfaqg0Bqvm+N9edjUiEm3tIX+usOdkS JGIA==
X-Received: by with SMTP id m5mr124300241qav.51.1420573243883; Tue, 06 Jan 2015 11:40:43 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id 91sm17422815qgf.1.2015. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 06 Jan 2015 11:40:43 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ralph Droms <>
In-Reply-To: <>
Date: Tue, 06 Jan 2015 14:40:41 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>, <> <> <> <>
To: Michael Richardson <>
X-Mailer: Apple Mail (2.1878.6)
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 19:40:47 -0000

On Jan 6, 2015, at 12:01 PM 1/6/15, Michael Richardson <> 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"?

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

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

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

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

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

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

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

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.

- Ralph

> (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 <>, Sandelman Software Works
> -= IPv6 IoT consulting =-