Re: [Roll] naming and other goals for RPL Unaware Leaves

[Abdussalam Baryun <[e-mail]>]

Thanks Micheal,
I prefer that we stick to IPv6 host definitions (rfc4861 and all its
updates), so it can be aware and unaware of such addition protocol as you
mentioned. More comments below,

On Fri, Oct 11, 2019 at 4:56 PM Michael Richardson <[e-mail]>
wrote:

>
> At the virtual interim a few weeks ago, Pascal and I discussed different
> possible goals for the documents.  Some of the confusion comes down to
> mis-understandings resulting from the choices of names.
>
> Let me go through a series of descriptions and connect some terms as I can
> to
> them.
>
> 1) Host. It was Carsten who first pointed that things that do not route are
>    hosts, and RFC8504 says what a host is supposed to do.
>    RFC8504 does not say anything about being able to decapsulate
> IP(dst:me)IP(dst:me)
>    packets.  I tried to get that in, but 6man was rather hostile to this.
>    RFC8504 also says nothing about supporting 6lowpan stuff!
>

I think that is ok no problem or confusion as long we follow IPv6 host
definitions [RFC4861 and its updates].

>
> 2) 6lowpan host.
>    Everything from (1), plus ability to do
>       rfc4944: Transmission of IPv6 Packets over IEEE 802.15.4 Networks
>
>    which means doing some amount of header compression.
>

that is an addition protocol that is in the use case of such subnet
IEEE802.15.4 which LLN may have other subnets with other protocols.

>
>    Does it include any of:
>
>    rfc6775: Neighbor Discovery Optimization for IPv6 over Low-Power
> Wireless
>             Personal Area Networks (6LoWPANs)
>    rfc7400: 6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power
>             Wireless Personal Area Networks
>    rfc8025: IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN)
>             Paging Dispatch
>    rfc8066: IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN)
> ESC
>             Dispatch Code Points and Guidelines
>    rfc8505: Registration Extensions for IPv6 over Low-Power Wireless
> Personal
>             Area Network (6LoWPAN) Neighbor Discovery
>    rfc8138: IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN)
>             Routing Header
>
>    I have no idea.  If someone says a product does "rfc6775", then 4944 is
>    clearly included.   Some of the more recent radios (DECT) may have
> nailed
>    down that they need additional things, but I didn't check.
>

I think those standards are special for WPAN in general but mostly direct
in the eyes of  IEEE802.15.4, however we need to make WPAN general the
local area network of LLN and not the IEEE802 subnet.

>
> 3) RPL host.
>    Pascal and I disagree whether to call this an RPL *AWARE* host (because
> it
>    speaks RPL data plane), or an RPL *UNAWARE* host (because it does not
>    speak 6550).  It being a host, it is by definition a leaf.
>
It is an IPv6 host and then a RPL leaf, so YES, it is better to say/call-it
* RPL leaf * because not all IPv6 hosts are RPL leaf, so using to call it
RPL leaf is perfect and short. using aware and unaware is not needed
because it is better to call unaware RPL host by IPv6 host.

>
>    We are we want is a definition which includes:
>    A) All the stuff above which we were uncertain about.  Specifically, we
>       really want RFC8505 and RFC6775 to be supported.
>       Specifically, EARO with the TID.
>
>    B) We want these devices to ignore RPI and RH3 headers according
> rfc8200,
>       as useofrplinfo envisions.
>
>    C) We want these devices to accept IP(dst:me),headers,IP(dst:me)
> constructs,
>       as it simplies the useofrplinfo situation for storing mode.  But,
>       we have some ways to work around this in the 6LR in storing mode, but
>       it is a spec change.
>
>    D) Ideally, these hosts would send IPv6 packets with an RPI header
> already
>       inserted.  This eliminates the need to do an IPIP encapsulation at
> the
>       first 6LR.
>

I this the RPL leaf can be called by such mode of operation or some kind of
classification,


>
>    A typical example of such a device is a window smash sensor that might
> be
>    part of a (home) security system.  When installed, it might be
> provisioned
>    with some cable for power and control.  Then, having sent out an
> EARO/TID
>    to register with the 6LR/6LBR, it goes into a deep sleep, waking up
>    perhaps weekly or monthly.  If the window is smashed, it send packets,
>    probably until the battery runs dry.  If it is re-used, it is
> effectively
>    refurbished with a new battery and rejoins as if it was a new device.
>
>    There are other examples of sleepy devices which would never be able to
>    forward packets.
>
> 4) 6LR with incompatible MOP, or other handicap.
>
>    Such a device is forced by the rules of 6550 to join the network as a
> leaf.
>    It is unclear to me if it is allowed to send DAOs for itself, or if it
> has
>    to use ND like (3) above.  Clearly it listens to DIOs, because that's
> how
>    it learnt that it couldn't join as a router.  The key thing is that it
>    does not emit DIOs, and thus never attracts any children.
>

I was voting in the past to re-write RFC6550, but the WG directed to
continue with, I still think to obsolete it with another new draft to
solve/clarify  such issues.

AB