[Nfd-dev] NFD RIB Daemon - trigger FIB updates from RIB

[Syed Obaid Amin]

Lan,

I left a comment on gerrit last night regarding a problem in using
EventEmitter. This proposal of Junxiao is one of the possible solutions for
that problem. Please see the following link for the details:

http://gerrit.named-data.net/#/c/911/4/rib/rib-manager.cpp

If we use EventEmitter then we need to make these changes as well, which I
think would take time. Therefore I suggested that for v0.2 we can use the
code that we have under review for task #1326 (
http://redmine.named-data.net/issues/1326). For later release we can use
EventEmitter approach.

Regards,
Obaid


On Tue, Jun 24, 2014 at 1:07 PM, Lan Wang (lanwang) <lanwang at memphis.edu>
wrote:

>  Junxiao,
>
>  I've asked Vince and Obaid to look at this proposal closely.  But before
> you sent this proposal, Obaid and I already talked about the route
> expiration issue you raised, and he will implement the EvenTimer approach
> you suggested -- RIB maintains the time-out and sends a signal to
> RIBManager when the timer expires.  Just FYI.
>
>  Lan
>
>  On Jun 24, 2014, at 8:22 AM, Junxiao Shi <shijunxiao at email.arizona.edu>
> wrote:
>
>  This is a design proposal for NFD RIB Daemon.
>
>  Background
> RIB Management functionality is implemented as a separate process: NFD RIB
> Daemon.
> RIB Daemon processes RIB updates from local applications and routing
> protocols, and then synchronizes the RIB to the FIB in main NFD process via
> FIB Management protocol.
> Currently, RIB Daemon has a RibManager component that is responsible for
> processing RIB updates, and a RIB data structure which is exclusively
> accessed by the RibManager.
> Historically, before RIB is implemented, RIB Daemon is a pass-through
> protocol translator that translates each RIB update into one FIB update,
> ignoring route inheritance flags.
> In the protocol translator, FIB updates are sent from RibManager, and a
> RIB update command is answered after the corresponding FIB update is
> complete.
>
>  Problem
> Task 1326 implements Route expiration in RIB: when a Route (prefix
> registration) expires, the FaceEntry is removed from the RIB, which shall
> trigger FIB updates.
> During the code review http://gerrit.named-data.net/911 (patchset 4
> rib-manager.cpp), a question is raised: should RibManager set the timer to
> remove the FaceEntry and trigger FIB updates, or should the RIB set the
> timer and notify RibManager?
>  Reviewer opinion is: expiration period is an attribute of a Route, so
> the timer should be set in RIB.
> This leads to another problem: after removing the FaceEntry, if the FIB
> update(s) fails, RIB and FIB will be out-of-sync.
> A related problem is: if a RIB update triggers multiple FIB updates, if
> some FIB updates succeed but others fail, RIB and FIB will also be
> out-of-sync.
>
>  Proposed Design
> RibManager updates the RIB only; it does not directly update the FIB.
>
>  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.
>
>  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.
> If any FIB update fails, (a) in case of a non-recoverable error (eg.
> signing key of RIB Daemon is not trusted), the RIB Daemon shall crash; (b)
> in case of a non-existent face error, the RibUpdateBatch is abandoned; (c)
> in other cases, the FIB update is retried.
> 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.
> For routing updates, the RibManager can respond with "100 continue" or
> similar code right away without waiting for FIB updates to complete.
>
>  Benefits
> The proposed design decouples FIB updates from RIB updates.
> A RIB update, regardless of source, can trigger FIB updates.
> If a RIB update *command* needs to wait for the RIB update and FIB
> updates to complete, RibManager can wait on a callback from the RIB.
>
>
>
>  Yours, Junxiao
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140624/c942fc68/attachment.html>