italovalcy / ndvr Goto Github PK

Currently, the key chain is created in the default PIB/TPM ($HOME/.ndn/{ndnsec-key-file/,pib.db} and the router key/identity/certificate are created in the scenario context (not in the router context). As a consequence, we cannot run parallel simulations (due to file lock on $HOME/.ndn/pib.db) and also the n-th router knows about the identities of the (n-1)-th and not the opposite, which leads to inconsistency in Pib:

../src/ndnSIM/ndn-cxx/ndn-cxx/security/pib/pib.cpp:102: ndn::security::pib::Identity ndn::security::pib::Pib::getIdentity(const ndn::Name&) const: Assertion `m_identities.isConsistent()' failed.

NDVR should be able to run an in-memory router's KeyChain:

diff --git a/extensions/ndvr.cpp b/extensions/ndvr.cpp
index 0e01070..fede029 100644
--- a/extensions/ndvr.cpp
+++ b/extensions/ndvr.cpp
@@ -31,6 +31,7 @@ Ndvr::Ndvr(const ndn::security::SigningInfo& signingInfo, Name network, Name rou
   , m_rand(ns3::CreateObject<ns3::UniformRandomVariable>())
   , m_network(network)
   , m_routerName(routerName)
+  , m_keyChain("pib-memory:", "tpm-memory:", true)
   , m_helloIntervalIni(1)
   , m_helloIntervalCur(1)
   , m_helloIntervalMax(5)

Hi,

NDVR configures the Faces to listen and send notifications at startup time. However, throughout NDVR execution, faces may be created/destroyed, and NDVR is not reconfiguring accordingly. We should leverage Face Status Change Notification to quickly identify and reconfigure NDVR upon face change events (creation/removal).

More information: https://redmine.named-data.net/projects/nfd/wiki/FaceMgmt#Face-Status-Change-Notification

the Face Manager also publishes notifications when Faces are created, destroyed, go up, or go down. This is done using the postNotification function returned after registering a notification stream to the dispatcher with the name faces/events. Two methods, afterFaceAdded and afterFaceRemoved, that take the function postNotification as argument, are connected to the FaceTable’s onAdd and onRemove signals [18]. Whenever these two signals are emitted, the connected methods will be invoked immediately, where the postNotification will be used to publish notifications through the dispatcher.

Source: https://named-data.net/publications/techreports/nfd-developer-guide/

How to reproduce:

• Execute an experiment and bring the physical interface down (e.g., by running into MininNDN and using something like node.cmd("ip link set down %s" % mcn.intfs[intf].name) -- example available here)
• You will notice that NDVR will not recover from this failure just because NFD will remove the old face and create a new one once the corresponding interface goes DOWN/UP. NDVR depends on sending and receiving interests from the faces connected to other routers, and since the face changed, FIB entries will be outdated (no longer sending/receiving notifications from NDVR)

What needs to be done:

1. Add means to listen to Face Status Change Notifications
2. To allow 1, we should probably change the default FW strategy associated with /localhost/nfd/faces/events from best-route to multicast (defaults to best-route, at least on MiniNDN)
3. NDVR adds proper routes for protocol control messages upon detecting new faces created (TODO: how to filter which faces are interesting for us ?)
4. NDVR updates its internal data structure to remove/add/modify faces updated

Suppose a scenario such as:

   A
 /   \
B --- C

Currently, NDVR uses the Incoming Face ID to detect how to reach a particular node for two reasons: 1) to get the certificate; 2) to insert FIB entries later on related to learned name prefix from the routing process. This is implemented in the following commit/lines: 487c877#diff-7cb0052807d3b8a56a34865ab9a08382R236-R238

However, it's worth to notice that since we are using the default multicast forward strategy, the incoming face can be a result of another node forwarding the interest on behalf of someone else. In other words, we create FIB entries to forward NDVR interest using the multicast strategy for ALL faces; thus, one node can forward ndvr messages from other nodes and then the interest might be received from (i) the direct face or (ii) from the intermediate forwarder face! Not necessarily means the node moved!

Ideally, we should use the forward strategy semantics similar to the localhop prefix (nfd::scope_prefix::LOCALHOP):

The localhop scope limits propagation to no further than the next node.

Interest packets under prefix ndn:/localhop are restricted by these rules:

• If an Interest is received from a local face, it can be forwarded to a non-local face.
• If an Interest is received from a non-local face, it cannot be forwarded to a non-local face.
• In either case the Interest can be forwarded to a local face.
• PIT entry can be satisfied by Data from any source.

Data packets under prefix ndn:/localhop are unrestricted.

Maybe we need a custom forward strategy

When encoding the Distance Vector information Data, we need to take care of the MTU to avoid exceeding and get error or bad behavior:

+567.631392993s 6 ndn.Ndvr:OnDvInfoInterest(): [INFO ] Replying DV-Info with encoded data: size=8716 I=/ndvr/dvinfo/ndn/%C1.Router/Router6/%027
terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<ndn::Face::OversizedPacketError> >'
  what():  Data /ndvr/dvinfo/ndn/%C1.Router/Router6/%027 encodes into 8895 octets, exceeding the implementation limit of 8800 octets

In the above case, node 6 has more than 240 routes and the total size of encoded data was 8716 (num_routes * (length_name_prefix + len(seqNum+cost))).

Each neighbor for which the node does not receive any updates for a certain time window should be removed. To enable this, the neighbor list should store the "lastSeen" time and if the lastSeen is greater than, let's say, three times the MaxHelloInterval, then remove the neighbor and invalidate all routes.

Our proposal uses the adaptative hello interval to dynamically adjust the time between hello interests: between 1s and 60s. When a node stays some time without learning new neighbors, we consider the network is quite stable and increment the hello interval. Thus, the hello interval becomes a relation between being too short and rapidly detect changes with the price of increasing the overhead.

So far so good. However, when we have a highly dynamic environment and the node stays for a quite long time without adjacency nodes (e.g., moving away from anyone else), the hello increases, and maybe when someone comes to its neighborhood, we lose the adjacency detection window.

A way to solve this would be to take advantage of information from the underlayer protocols. In 802.11, for example, the beacon exchange gives us the "association list" that could help to set up the proper hello interval.

For now, we reduced the maximum hello interface to the average association time of the scenario (e.g., 5s - it depends on the scenario).