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

["Pascal Thubert (pthubert)" <[e-mail]>]

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 <[e-mail]> On Behalf Of Michael Richardson
Sent: vendredi 11 octobre 2019 16:57
To: [e-mail]
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.

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    [