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

From: Michael Richardson <[email-masked]>
Date: Fri, 11 Oct 2019 16:56:52 +0200

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  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 11 Oct 2019 17:56:56 +0200

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,

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

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

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

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

>       inserted.  This eliminates the need to do an IPIP encapsulation at

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

>    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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 11 Oct 2019 17:13:03 +0000

Many thanks for the great description Michael!

The art of RFC 6550:
1) a leaf is a node that connects to the RPL network as a host and obtained reachability from the RPL domain 
2) all leaves need to be RPL aware. This involves sending DAOs thus speaking RFC 6550.

I wrote the first rounds of the RUL draft with the expectation that:
- we define a new type of leaf that does 1) but not 2) . I called that guys a RUL. Note well: the definition a pure ROLL definition; it is not related to 6LoWPAN nor even IPv6, though currently RPL only applies to AF v6 and mostly in conjunction with 6LoWPAN.
- the RUL draft applies to a specific family of RULs that supports RFC 8505 and plays it by the rules of the RUL draft
- the RUL draft also lists dependencies on the RUL, e.g., support RFC 8200 for handling RH and HbH as a host (https://tools.ietf.org/html/draft-ietf-roll-unaware-leaves-04#section-6). 
- when the RUL draft is RFC-blah, the set of properties above is wrapped into a "RUL that supports RFC-blah", not sure we need a name for it, but we could. That would be a definition that goes beyond ROLL.  

If we want to change the above then the draft will need a rewrite accordingly because this definition is used pervasively.

In contrast I called a leaf-that-is-not-a-RUL a RAL. => A leaf is either a RUL or a RAL nut not both. IOW  {RUL} v {RAL} = {leaves} and {RUL} ^ {RAL} = 0. So the term leaf was extended and the leaves that RFC 6550 presented can still be named as RAL. Combining with a RPL router we obtain the RAN, RPL aware node.

The use of RPL info could use a name for "RUL that supports RFC-blah", because it calls it a RUL right now. The problem is that this creates a normative reference to the RUL draft and may delay useofrplinfo. OTOH, delaying may be a good idea to ensure final consistency.

What do others think?

Pascal

-----Original Message-----
From: Roll <[email-masked]> On Behalf Of Michael Richardson
Sent: vendredi 11 octobre 2019 16:57
To: [email-masked]
Subject: [Roll] naming and other goals for RPL Unaware Leaves

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.

2) 6lowpan host.

   Does it include any of:

3) RPL host.

      

   

=====

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!

---

From: Michael Richardson <[email-masked]>
Date: Fri, 11 Oct 2019 22:18:22 +0200

Pascal Thubert (pthubert) <[email-masked]> wrote:
    > The art of RFC 6550: 1) a leaf is a node that connects to the RPL
    > network as a host and obtained reachability from the RPL domain 2) all
    > leaves need to be RPL aware. This involves sending DAOs thus speaking
    > RFC 6550.

Agreed, but can you relate it to the categories I wrote about?

    > I wrote the first rounds of the RUL draft with the expectation that: -
    > we define a new type of leaf that does 1) but not 2) .

So, this is my category:

    mcr> 3) RPL host.  Pascal and I disagree whether to call this an RPL *AWARE*
    mcr> host (because it speaks RPL data plane), or an RPL *UNAWARE* host
    mcr> (because it does not speak 6550).  It being a host, it is by definition
    mcr> a leaf.

Do others agree?
I don't care what we call it.

But, useofrplinfo used the term RUL to refer to category (2), not (3).
If all leaves are (3) then from an RPL point of view, they require no special care.

If useofrplinfo can assume (3), which is a new thing, then can useofrplinfo define (2),
explain that are difficult to deal with, and remove support for them?
If we go this way, then useofrplinfo winds up with a reference to
unaware-leaves and has to wait for it to progress.

Maybe we could change the word unaware to non-participating.
Or maybe anti-social.   

    > In contrast I called a leaf-that-is-not-a-RUL a RAL. => A leaf is
    > either a RUL or a RAL nut not both. IOW {RUL} v {RAL} = {leaves} and
    > {RUL} ^ {RAL} = 0. So the term leaf was extended and the leaves that
    > RFC 6550 presented can still be named as RAL. Combining with a RPL
    > router we obtain the RAN, RPL aware node.

A RAL speaks RPL, but is just at the edge.  Is it my category (4), or is
it 

    >    {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}

---

From: Ines Robles <[email-masked]>
Date: Tue, 22 Oct 2019 16:02:36 +0300

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 <[email-masked]>
wrote:

> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 22 Oct 2019 13:50:43 +0000

Hello Ines :

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

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

<Pascal> I like those definitions because they are RPL related in a RPL draft. RFC 8138 is also ROLL and is orthogonal. We can say a RFC-8138-complient node without a defining a fancy name. The others are external to ROLL. </Pascal>

   RPL-Unaware-Leaf(RUL): A RPL-unaware-node which is a leaf of a
   (Destination Oriented Directed Acyclic Graph) DODAG.
This is all consistent with option 1 the other thread and with the way the RUL draft is written today.

This is interesting for the control plane because we know a RUL cannot speak RPL. The RUL drafts asks the RUL to speak RFC 8505 in a certain way instead.

This is less interesting for useofrplinfo because it is data plane. The data plane does not care about RPL but about the way a host treats a consumed RH or a HbH option, and that’s RFC 8200 not RPL. The data plane also cares about IP in IP encapsulation. When useofrplinfo says what to do with a RUL (e.g., in section 7.1.4<https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo-31#section-7.1.4>)  that really applies to a node that can do those things whether it is a RAL or a RUL. Suggestion, we call that thing a Leaf. Because a thing that does not do any of that is an external destination for which the only thing useofrplinfo can do is tunnel to the 6LR and terminate all IP in IP, artifacts and compression there. We already have text in useofrplinfo for those.

: )

Pascal