italovalcy / ndvr Goto Github PK
View Code? Open in Web Editor NEWNDN Distance Vector Routing
NDN Distance Vector Routing
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)
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
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).
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:
node.cmd("ip link set down %s" % mcn.intfs[intf].name)
-- example available here)What needs to be done:
/localhost/nfd/faces/events
from best-route
to multicast
(defaults to best-route, at least on MiniNDN)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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.