Subject: Re: [6lo] 6tisch Digest, Vol 13, Issue 11

From: Martin Turon <[email-masked]>
Date: Wed, 15 Oct 2014 13:50:43 -0700

Hi Pascal,

Thanks for taking the initiative to down-select a solution for RPL
next-header compression.

On the choice between (a) Greedy and (b) Conservative for how to introduce
RPL-specific compressed hop-by-hop headers, I would strongly advise and
vote for (b) Conservative.

6LowPAN provides a very powerful, general mechanism for compressing generic
IPv6 headers, and only reaches deeper than IP in the case of UDP.  I think
this leaning should remain, and would advise for the introduction of a new
NHC type called "compressed hop-by-hop" which RPL can take 1/4 of.  For RPL
to consume 1/4 of all compressed Next Hop headers seems too far of a reach
for one protocol to make into generic 6lo compression.

Small frame 802.15.4-2004 packets are over 10 years old, and still aren't
going away anytime soon.  BLE is looking at adopting 6lo on even smaller
frames.  I think 6lo should remain viable and extensible for the small
frame platforms for which it was originally designed.

Martin

_____________________________
Martin Turon  |  Nest Labs

> ---------- Forwarded message ----------
> From: "Pascal Thubert (pthubert)" <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> Cc: Michael Richardson <[email-masked]>, Routing Over Low power
> and Lossy networks <[email-masked]>, "Ralph Droms (rdroms)" <
> [email-masked]>, Samita Chakrabarti <[email-masked]>,
> Carsten Bormann <[email-masked]>, "[email-masked]" <[email-masked]>
> Date: Wed, 15 Oct 2014 07:52:07 +0000
> Subject: [6tisch] Call for advice on the RFC 6553 6lo encoding
> Dear all,
>
> I'm attaching below a mail from Carsten which summarizes the only point of
> contention that we still have in our discussion on how to compress the RPL
> Information in 6lo. As Carsten explains below, we need advice from the list
> on which approach we should be taking, and we are now calling for advice.
>
> There are basically 2 approaches:
> a) Greedy. RPL would consume a high code in the NHC space, which can be
> interpreted as 1/4 of its addressing capability. This would be leaving more
> than half available for future use.
> b) Conservative. RPL would only consume a very limited NHC space, at the
> expense of one extra octet in each packet.
>
> We have to choose between protecting resources now (frame size, energy) or
> in the future (NHC encodingspace):
> a) optimizes for today's RPL-routed data packets at a time when frame size
> is a major issue, mostly with 802.15.4-2006 and ultra-low-speed networks
> (PLC, LPWA).
> b) optimizes for a future when we deploy new services and routing
> protocols in LLNs, which will require new IPv6 options headers, and the
> space left in the NHC encoding becomes an issue.
>
> Please help us and post advice, indicating whether you favor a) greedy or
> b) conservative, and for which technical reason.
>
> We need to extract an initial consensus and publish a proposed solution
> I-draft by the cut-off on the 27, preferably earlier than that.
>
> Thanks a bunch in advance,
>
> Pascal
>
>