Pascal Thubert (pthubert) <[email protected]> wrote: > This new thing is not a anyway, it is the expression of a willingness, > aka a preference. IPv6 has introduced the concept in RAs with RFC 4191.
I resist mixing the word "preference" into the conversation...
> The preference is NOT a metric, it is NOT to be confused/aggregated
> with the Rank; and to the 802.15.4 join priority that we derive from
> Rank for the time distribution, your point exactly.
I was thinking about whether or not the Join Priority should be incremented
by some number related to the rank.
I definitely think that Join Proxy should probably be calculated in some
way related to the number of free neighbor caches available for insecured
traffic.
> We are extending RFC 4191 in 2 ways: 1) to use more bits because nodes
So, 4191 is about Route Advertisements.
This extension is about pledges finding Join Proxy. There is a similarity,
but I had not thought that this Join Priority to be applied to RAs.
The "R" bit that is present in this extension identifies the sender as
willing to answer *unicast* Router Solicitations. Such RS's would be sent
securely by host nodes which have already joined, but which may have lost
their default router due to a long sleep. Note: host nodes, not routers.
The "R" bit might not be set by a router whose neighbor cache is full.
(It still has to send beacons to keep time!)
I am open to the idea that this priority might influence a host to decide
which router to send the RS to.
> If the DAG root is getting saturated (e.g. bandwidth) it should be able
> to signal it with lowering preferences that is propagated in DIOS. If a
> node is even more saturated for its own reasons (e.g. neighbor cache)
> it should be able to signal that with a preference that it lower than
> that of its parent.
A 6LR which has a full neighbor cache should have a very undesireable Join
Priority (i.e. a bigger number). It might however express a relatively low
minimum join priority in the DIOs to it's children if it still has available
bandwidth. That would naturally push the joining nodes that can hear both to
attempting to join to the children, which reduces the pressure on the
neighbor cache entries.
> In order to throttle the join process we need something similar to
> express willingness to accept more joins/children in an abstract
> fashion.
> We can make the mechanism optional since the problem mostly affects
> large networks. But I think that we must be ready because there is a
> saturation point where the problem will show up and another where the
> join will perpetually fail.
> Does that make sense?
Agreed.
Pascal, let me bring this text from me back in:
mcr> These documents could be combined, and I would suggest that if
mcr> there was no thought that the first one (enhanced-beacon) might be
mcr> turned over the IEEE. Perhaps Pascal could explain that comment from
mcr> Monday.
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
