3.2.5.8 Receiving an AUTHORITY Message
Section 3.1.5.5.1.1 specifies the rules for handling received AUTHORITY messages. In addition to those rules, when a ROUTE_ENTRY completes validation and is added to the Route Entry Cache (as specified in 3.1.5.5.1.2), the Publisher MUST also check, for each locally registered key, whether the key in the ROUTE_ENTRY falls within its leaf set. If so, it MUST do the following:
Add the ROUTE_ENTRY to the leaf set (removing the farthest entry on the same side of the locally registered key, if there are already 5 entries in the leaf set on that side).
Build a list of leaf set neighbors to which the new ROUTE_ENTRY is forwarded. It MUST pick the nearest cached key greater than the route entry's key and the nearest cached key less than the route entry's key. If the ROUTE_ENTRY is being added because of a FLOOD message, any nodes with endpoints in the Already Flooded List of the FLOOD message MUST be excluded when looking for the nearest key.
Construct a FLOOD message with the D flag clear containing the new ROUTE_ENTRY. The Already Flooded List MUST contain one of the endpoints from each of the two nodes chosen above (the choice of which endpoint can be arbitrary). If the route entry is received in a FLOOD message, then the Already Flooded List MUST also contain any addresses in the Already Flooded List of the original FLOOD message.
Send the FLOOD message to the two nodes previously chosen.
If the ROUTE_ENTRY is received from a FLOOD and the source address of the FLOOD message is not in the received ROUTE_ENTRY, the local node MUST send a FLOOD message with the D flag clear back to the sender, containing a ROUTE_ENTRY for the local key to add the ROUTE_ENTRY to the leaf set.
Whenever a FLOOD message with the D flag clear is sent, the node MUST also put the FLOOD message in the Pending List, set its Retry Count to 2, and start its Message Retransmission Timer.