[Nfd-dev] Expiration time of the RIB entry at the NDN nodes

[Lee, Jongdeog]

Dear Junxiao,

  Thanks. I fixed the issue based on your advice.
  As you said, the prefix is expired because the associated face is expired.
  To prevent this,

1. nfdc create -P udp4://ndnx.cs.illinois.edu
2. nfdc register / tcp4://ndnx.cs.illinois.edu
3. nfdc register /localhop/nfd tcp4://ndnx.cs.illinois.edu

  Above commands fixed my issue (I skipped step 1 before, and it expires the face).

Best wishes,
Jongdeog Lee (JD)

------------------------------------------------
Ph.D. Student
Department of Computer Science
University of Illinois at Urbana-Champaign
________________________________
From: Junxiao Shi [shijunxiao at email.arizona.edu]
Sent: Friday, February 03, 2017 8:41 PM
To: Lee, Jongdeog
Cc: nfd-dev at lists.cs.ucla.edu
Subject: Re: [Nfd-dev] Expiration time of the RIB entry at the NDN nodes

Hi Jongdeog

  So I guess if the pingserver is not idle, the prefix at the Illinois node would not be expired, right?

If the connection between end host and gateway router is good, and there's no problem with certificate retrieval, the prefix registered on Illinois node should not disappear, regardless of whether the pingserver is idle or not.

Routes registered via auto prefix propagation are set to "never expire", so that they will not appear as long as the face does not appear.
A UDP on-demand face has a default idle timeout of 600 seconds (router's nfd.conf face_system.udp.idle_timeout key), which means your end host must send something to the router at least once every 600 seconds. If everything else is idle, auto prefix propagation can still fulfill this requirement by sending a prefix registration command once every 300 seconds (end host's nfd.conf rib.auto_prefix_propagate.refresh_interval key).

However, there are two possible reasons that can cause the face to disappear.

First, if there is a network connectivity problem that causes either end to receive an ICMP error, the face disappears on that end.
On end host side, you can prevent this situation by creating the face with persistency set to permanent. The command is nfdc create -P udp4://192.0.2.1:6363<https://urldefense.proofpoint.com/v2/url?u=http-3A__192.0.2.1-3A6363&d=DwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Z7ZyWHGeVXO4-LRL2FeI1ZE8d269MMOL_mjEf1LVJpE&m=HR2SgAeeV7vbnp3lqnGI0f421cqUvzmjeim3StaLrsY&s=tBokOJVtokpjyuFKg5DFmyyyUX43IFLNWwH2T1EnxPg&e=> for NFD 0.5.1 or below, and nfdc face create udp4://192.0.2.1:6363<https://urldefense.proofpoint.com/v2/url?u=http-3A__192.0.2.1-3A6363&d=DwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Z7ZyWHGeVXO4-LRL2FeI1ZE8d269MMOL_mjEf1LVJpE&m=HR2SgAeeV7vbnp3lqnGI0f421cqUvzmjeim3StaLrsY&s=tBokOJVtokpjyuFKg5DFmyyyUX43IFLNWwH2T1EnxPg&e=> permanent for upcoming NFD version.
In case the face disappears on router side, the next prefix registration command will create a new face on the router and add the prefix again.

Second, if there is a certificate retrieval problem, or any other reason that causes the prefix registration command sent by auto prefix propagation to fail, the exponential back-off retrying algorithm in auto prefix propagation will kick in. The base retry wait is 50 seconds, and the maximum retry wait is as long as 3600 seconds (end host's nfd.conf rib.auto_prefix_propagate section). This means, if prefix registration command has failed four times, the retry wait would increase to 800 seconds which is greater than UDP on-demand face's idle timeout, and then you'll observe the end host's face appear and disappear on the router one time or another.

But if there's no ICMP error and no error during prefix registration, none of these would happen.

Yours, Junxiao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20170208/04cd1294/attachment-0001.html>