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

Ralph Droms <> Tue, 06 January 2015 15:26 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C9F251A00E1; Tue, 6 Jan 2015 07:26:19 -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 o0kqJrfF93gY; Tue, 6 Jan 2015 07:26:16 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 56D5D1A00A8; Tue, 6 Jan 2015 07:26:16 -0800 (PST)
Received: by with SMTP id ey11so31343221pad.10; Tue, 06 Jan 2015 07:26:15 -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=JHZRPpvMVNRCAbo7XYtpu0uZBKGGRJkRfRyVtpsxGuY=; b=y4gixdctYoa1bqWmm4IjyneJsYUnZ2mepeCXlihMaNWcDs8UYlqbsr1KJPWMrKxX/q 9HBOGU/gBjon1mC70KQe+9N/hjeEAa8YEP37jUCtIR4gxdH1vwq9GblkWYYNAC8nHvfW Z0Y2GMpuFbn4PXK+ONaTSLjwno2f+fjrc3KX/Aa/Z/59yV3pDHgW/m/ckFEmw/7z/dVT ZtUnA7RdJO2bw7GdcrwIXAlxAJykOwbkSQAH5Vm57LGeSbPMQHmMthPTm8i9iegxc+tu clG0n+WnZSINwXbEMcOMuIxEds170JTCx90TulEHM19VYbxvWDAKiHxlLKdHSc04zj/K YG3Q==
X-Received: by with SMTP id bo1mr160246583pdb.23.1420557975552; Tue, 06 Jan 2015 07:26:15 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id wi15sm57689798pac.21.2015. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 06 Jan 2015 07:26:14 -0800 (PST)
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ralph Droms <>
In-Reply-To: <>
Date: Tue, 06 Jan 2015 09:33:01 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>, <> <>
To: Routing Over Low power and Lossy networks <>
X-Mailer: Apple Mail (2.1878.6)
Cc: "" <>, "" <>, 6man WG <>, " WG" <>, "" <>, "" <>
Subject: Re: [Roll] [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 15:26:20 -0000

(Adding 6man because of architecture issues)

On Jan 6, 2015, at 1:22 AM 1/6/15, Pascal Thubert (pthubert) <> wrote:

> Hello Ralph 
> You certainly got it all right.
> To your question we started through the NHC and found that path less efficient than Laurent's initial suggestion to place all the LLN routing artifacts in a different header/dispatch whatever the correct term is for that object.
> One additional concern that doesn't show in your mail is the need for IP encapsulation when the artifacts are added by a router on the way or must be removed at LLN egress. By leaving the original IPv6 packet intact we simplify that matter and optimize the overall result by providing an improved compression for the outter header.

Yeah, I noticed the issue of IP encap hasn't been addressed (if I recall correctly) in draft-thubert-6lo-rpl-nhc...

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

> The new proposal also reopens the dispatch space (1/3 of the total) that is used is mesh under for mesh header, so it can also be use AND extended as TLV in route over.

There are both architectural and pragmatic issues in the design of the RPL-in-dispatch protocol.

The upcoming bakeoff might be a way to stimulate some running code that would check out all the potential impacts of moving the RPL information to a sub-IP protocol.

- Ralph

> Makes sense?
> Pascal
>> Le 5 janv. 2015 à 23:29, Ralph Droms <> a écrit :
>> Do I have it right that:
>> 1) draft-thubert-roll-flow-label-02 compresses RPL RPI but not RH3
>> 2) draft-thubert-6lo-rpl-nhc-02 compresses RPL RPI and might be extended to compress RH3
>> 3) draft-thubert-6lo-routing-dispatch-01 compresses both RPL RPI and RH3
>> In discussion during the IETF-91 6lo working group meeting, a concern was raised about further consumption of NHC codepoints beyond what is defined in draft-thubert-6lo-rpl-nhc-02 for a future RH3 compression scheme.
>> Pascal, Carsten - as you have devised a mechanism for RH3 compression in draft-thubert-6lo-routing-dispatch-01, would you be able to retrofit a version of that mechanism into draft-thubert-6lo-rpl-nhc-02?  This extension to NHC compression would provide an explicit proposal for evaluation of RPL header compression in NHC.
>> - Ralph
>> _______________________________________________
>> Roll mailing list
> _______________________________________________
> 6lo mailing list