[Roll] naming and other goals for RPL Unaware Leaves

[Michael Richardson <[e-mail]>]

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    [