Feature #1941
Updated by Junxiao Shi over 9 years ago
Currently, FIB updates are generated by `RibManager` class. This is semantically incorrect, because `RibManager`'s responsibility is to accept RIB register/unregister commands, while FIB updates can result from not only RIB register/unregister commands, but also Route expiration. This Task is to implement the [proposed design](http://www.lists.cs.ucla.edu/mailman/private/nfd-dev/2014-June/000217.html): send FIB updates from a separate `FibUpdater` module, and trigger FIB updates from a `RibUpdateBatch`. This design has been [approved and clarified](http://www.lists.cs.ucla.edu/mailman/private/nfd-dev/2014-June/000224.html). ## Design RibManager updates the RIB only; it does not directly update the FIB. RibManager can respond to prefix registration commands right away without waiting for `Rib::beginApplyUpdate` to complete, because a successful response indicates the acceptance, not the completion, of a [[RibMgmt]] command. **RIB updates are batched**. A batch of RIB updates is packaged into a RibUpdateBatch object. All RIB updates in the same RibUpdateBatch object must refer to the same face. When RibManager receives one or more RIB updates, it generates a RibUpdateBatch, and passes it to Rib::beginApplyUpdate() to begin the RIB update procedure. When one or more Route expires, the RIB itself generates a RibUpdateBatch, and begin the RIB update procedure. Note: before #1698, RibUpdateBatch may contain only one RIB update. The **RIB update procedure has admission control**: if a previous RibUpdateBatch is in progress, the new batch will be put in a queue until the previous batch is complete. To apply a batch of RIB updates, the current collection of RIB entries and the RibUpdateBatch are passed to FibUpdater component to compute the optimal set of FIB updates, and the FibUpdater component shall send these FIB updates. FIB updates should be send sequentially, in order to avoid #1990 and avoid overloading NFD; given that NFD is local, this shouldn't cause long latency. FIB updates for RibUpdateBatch's face should be sent before FIB updates for other faces. **If any FIB update fails**, (a) in case of a non-recoverable error (eg. signing key of RIB Daemon is not trusted, more than 10 timeouts for the same command), the RIB Daemon shall crash; (b) in case of a non-existent face error of the same face, the RibUpdateBatch is abandoned; (c) in case of a non-existent face error of a different face, the FIB update is skipped; (d) in other cases (eg. timeout), the FIB update is retried. The updates can be skipped in case (c) because they are for inherited routes. Inherited routes can only affect the calculation of updates for the same face, which is an invalid face, and do not alter the route flags. If the RibUpdateBatch is abandoned, the RIB is unchanged; otherwise, after all FIB updates are successful, the RIB entries are updated. For a prefix registration request from application, the RibManager should pass a callback to `Rib::beginApplyUpdate`, which is called after all FIB updates are successful and the RIB is updated. The called function can respond to the prefix registration request(s) that generate this RibUpdateBatch. For routing updates, the RibManager can respond with "100 continue" or similar code right away without waiting for FIB updates to complete.