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

[Ines Robles <[e-mail]>]

Hi,

Currently the useofrplinfo draft states:

   RPL-aware-node: A device which implements RPL.  Please note that the
   device can be found inside the LLN or outside LLN.

   <<< This would be the number 3 of Michael descriptions
   Should we extend the definition to insert 3.A, 3.b, 3.C, 3D
descriptions???? >>>>

   RPL-Aware-Leaf(RAL): A RPL-aware-node which is a leaf of a
   (Destination Oriented Directed Acyclic Graph) DODAG.

   RPL-unaware-node: A device which does not implement RPL, thus the
   device is not-RPL-aware.  Please note that the device can be found
   inside the LLN.

   <<< This would be the number 2 of Michael descriptions,
   I am wondering if we could add the need of RFCs6775, RFC8138 and the
others that Michael mentioned
   into section 9 Operational Considerations of supporting
not-RPL-aware-leaves. >>>>

   RPL-Unaware-Leaf(RUL): A RPL-unaware-node which is a leaf of a
   (Destination Oriented Directed Acyclic Graph) DODAG.



   6LoWPAN Node (6LN): [RFC6775] defines it as: "A 6LoWPAN node is any
   host or router participating in a LoWPAN.  This term is used when
   referring to situations in which either a host or router can play the
   role described.".  In this document, a 6LN acts as a leaf.

   6LoWPAN Router (6LR): [RFC6775] defines it as:" An intermediate
   router in the LoWPAN that is able to send and receive Router
   Advertisements (RAs) and Router Solicitations (RSs) as well as
   forward and route IPv6 packets.  6LoWPAN routers are present only in
   route-over topologies."


   We would appreciate to know what the WG thinks about this topic?

   Thank you very much,

   Ines.

On Fri, Oct 11, 2019 at 5: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!
>
> 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.
>
>    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.
>
> 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.
>
>    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.
>
>    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.
>
>    {It is distinguished from a 6LR which just happens to be leaf, because
>    there are no children that have picked it as a parent.  Such a 6LR sends
>    out peridic DIOs according trickle}
>
> =====
>
> I would have called (2), RPL Unaware Leaves, and I would have called (3)
> RPL
> Aware Leaves.
> Pascal calls (1) RPL Unaware Leaves, and (2) are RPL Aware Leaves (I
> think).
> Well, maybe my description is wrong!
>
> Flame away!
>
> --
> ]               Never tell me the odds!                 | ipv6 mesh
> networks [
> ]   Michael Richardson, Sandelman Software Works        | network
> architect  [
> ]     [e-mail]  http://www.sandelman.ca/        |   ruby on
> rails    [
>
>
>
>
>
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll
>