Re: [Roll] [6lo] Call for advice on the RFC 6553 6lo encoding

"Pascal Thubert (pthubert)" <> Wed, 15 October 2014 08:40 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E05E21A19E7; Wed, 15 Oct 2014 01:40:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QYkuZ2xZxYJ0; Wed, 15 Oct 2014 01:40:48 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 61D0B1A19ED; Wed, 15 Oct 2014 01:40:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=1974; q=dns/txt; s=iport; t=1413362448; x=1414572048; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Smi0vjiMvZO8OUq7sE3IB2fkSqCe4HHLVC9mUUOH4yE=; b=UDXaF9NJXXU/xZovmiSKX3yIuFiK2uOl+EgDSn+E/W9yTxmPUhtDvTH2 cAbLR3GSvGUPlV8NKFl2ysb1WQPmhVwdCbs9hB6goDC1FhpLQJ9qpB/hP rQwTUhGG32/HMB4KFfj9fFhXQ7C9IQsmm/0HynHgZciFMrVGccX6GkHCH 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.04,722,1406592000"; d="scan'208";a="87051391"
Received: from ([]) by with ESMTP; 15 Oct 2014 08:40:44 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s9F8eiMB013517 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 Oct 2014 08:40:44 GMT
Received: from ([]) by ([fe80::200:5efe:]) with mapi id 14.03.0195.001; Wed, 15 Oct 2014 03:40:44 -0500
From: "Pascal Thubert (pthubert)" <>
To: Carsten Bormann <>
Thread-Topic: [6lo] Call for advice on the RFC 6553 6lo encoding
Thread-Index: AQHP6E32JyW5QHhusk2y3j3oyyqBgpww0yNw
Date: Wed, 15 Oct 2014 08:40:43 +0000
Deferred-Delivery: Wed, 15 Oct 2014 08:40:00 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Routing Over Low power and Lossy networks <>, "" <>, "" <>
Subject: Re: [Roll] [6lo] Call for advice on the RFC 6553 6lo encoding
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: Wed, 15 Oct 2014 08:40:50 -0000

Hello Carsten:

At this moment, we can guarantee that a) and b) as presented are generally doable. This is why I called on that. People might think that b) is acceptable as presented anyway.

You are suggesting here that the extra byte in b) may apply only to some packets, but we do not have a consensus that your specific solution is acceptable and I have my own string doubts because of the way RPL uses those bits.

We can discuss this on another thread, but I'd wish to keep this call very abstract on 2 general approaches as opposed to draft-pascal vs. draft-carsten to get the rough balance of people's minds, greedy, or conservative.



> -----Original Message-----
> From: Carsten Bormann []
> Sent: mercredi 15 octobre 2014 09:59
> To: Pascal Thubert (pthubert)
> Cc:; Routing Over Low power and Lossy networks;
> Subject: Re: [6lo] Call for advice on the RFC 6553 6lo encoding
> On 15 Oct 2014, at 09:52, Pascal Thubert (pthubert) <>
> wrote:
> > b) Conservative. RPL would only consume a very limited NHC space, at the
> expense of one extra octet in each packet.
> No, that's not how it [1] works.
> There is no extra byte except if the R or F flags in the RPL Packet Information
> (RPI) are non-zero.
> It appears to me that those flags are an infrequent occurrence, so the total
> expense in bytes sent should be near zero.  There *is* expense in code size
> (complexity), though.
> I have not been able to obtain any real world numbers on the frequency of
> non-zero R bits in real life RPL traffic.
> (I have no idea whether non-zero F bits actually exist in real life at all.) Those
> would be questions that people with more RPL experience than I have can
> answer.
> Grüße, Carsten
> [1]