[Anima-bootstrap] developments on 6tisch join scheduling

[Michael Richardson <[e-mail]>]

During discussions at IETF96, it became clear that the join ordering/time
sequence envisioned for 6tisch would be less possible than I thought.
The bad news is that a new mechanism might be hard to actually design.
The good news is that I think a new mechanism would put 6tisch join
and ANIMA bootstrap almost identical.

To go back, the proposal was:
  1) a new pledge would send a NA with an EARO, which would turn into a
     DAC/DAR process up to the 6LBR.  The 6LBR would let the JCE know
     about the new node through mechanism TBD.
     The new pledge would receive a NA in reply, which, for the pledge
     would acknowledge that they might be knocking on the right door.
     (A network which didn't like that node would reply in some negative
     fashion, which naturally could also be forged)

  2) the JCE would reach out (via the proxy) to the pledge, on a schedule
     determined by the JCE.  The JCE would control the order of joining,
     and since CoAP would be used with using something like:
          draft-wang-6tisch-6top-protocol-00
     all joining nodes would remain quiet except when responding to
     queries from the JCE.

The goal of having the pledge be passive was one of bandwidth conservation,
the JCE would enroll only as many pledges as it felt it had available
bandwidth in the upper parts of the MESH DODAG tree.  A 6tisch network might
allocate a rather small amount of bandwidth for join messages, and utilizing
the bandwidth responsabily is important.  That means never wasting any energy
among the lower parts of the DODAG when the packets would just get dropped
further upwards.

In discussions, it appears that the EARO as described in
draft-thubert-6lo-rfc6775-update-00 might be replaced by the Crypto-ID
of draft-sarikaya-6lo-ap-nd-02, and the process is slightly different.

One additional reason why the passive pledge turns out to be a problem is
that the JCE does not actually know the wake/sleep schedule for the pledge.
In the 6tisch case, it ought to be possible for the pledge to sync up to
the schedule and so the proxy will know when it can transmit to it, but
in order to keep the proxy from having to store a lot of data coming from the
JCE, the JCE also needs to know the schedule out at the edge.  This does not
seem unsolveable, but it was an additional concern raised.

Meanwhile, in ANIMA bootstrap, the initial contact is through a GRASP
discovery (or DNSSD) to find a proxy.  The new pledge uses the proxy to
initiate an EST session using the proxy.  The enrollment process in the ANIMA
case is driven by the pledge, on the assumption that the ANIMA ACP has
sufficient bandwidth for normal congestion control present in TCP and CoAP to
deal with a limits.

What is needed is a way to adjust things so that the pledges will attempt to
join in a way that does not overwhelm the network, and more so, that the proxy
nodes can easily police that they are doing so.

So the idea is to use the ANIMA GRASP discovery mechanism to find a proxy,
but in addition, in the reply, to get some kind of number to seed a backoff
algorithm that causes the pledge to attempt to initiate the join process
at times deterministic to the network.  I'm not talking about an exponential
backoff.

This is where the hard part is, how to come up with a simple to describe, and
simple to code algorithm which would fill up the available bandwidth, and be
easily subdividable.

By subdividable, I mean, if we pass 5% of the join bandwidth to proxy A, at
rank 3, that it would be able to easily pass some percent of that bandwidth
to a new proxy at rank 4 in a way that does not mean reconfiguring the entire
mesh to delegate bandwidth.

Removing the subdivable property, some simple pseudo-random number generator,
with the right seed would be the right idea.   A good PRNG ought to span
the available time space evenly.  I don't have a solution, but I'm trying to
write up the requirements more clearly.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-