NDVR: NDN Distance Vector Routing
NNDVR: NDN Distance Vector Routing
Italo Valcy da Silva Brito
Abstract —Ad hoc mobile scenarios desire a lightweight routingprotocol to propagate rapidly changing data reachability infor-mation in a highly dynamic environment. We are developinga distance-vector routing protocol that enables each node toselectively propagate a data reachability vector containing thenamed-data prefixes current reachable to their neighbors. In thisreport, we describe the implementation of NDVR (NDN DistanceVector Routing), discuss the rationale for the protocol designchoices, and demonstrate a use case for the protocol to illustratehow the routing protocol can help NDN applications, specially inmobile adhoc scenarios.
Index Terms —NDN, routing, distance-vector, adhoc, mobility
I. I
NTRODUCTION
Ad hoc mobile scenarios desire a lightweight routing proto-col to propagate rapidly changing data reachability informationin a highly dynamic environment. The currently deployedNamed-Data Networking (NDN) routing protocol, NLSR, isbased on link-state algorithms, which require synchronizationof the link-state database, which can be challenging to achievein the above-intended scenario. We are developing a distance-vector routing protocol that enables each node to selectivelypropagate a data reachability vector containing the named-dataprefixes current reachable to their neighbors. Such reachabilityinformation can be propagated transitively, allowing all reach-able nodes at the time to estimate their reachability to desireddata in a distributed and asynchronous manner.This technical report presents our work in progress and pro-totype of the NDN Distance Vector Routing (NDVR) protocol [1]. The initial design of NDVR consists of the simplest pos-sible way to propagate name prefix reachability informationbased on distance vector algorithms. The protocol enablesdynamically identified neighbors to use NDN’s Interest andData packets to propagate routing updates and runs in twomain phases: (i) dynamic neighbor discovery and (ii) distance-vector information exchange (dvinfo). NDVR prototype wasdeveloped on the ndnSIM simulation environment.The report is organized as follows. In Section II we discussthe rationale for the protocol design choices. In Section IIIwe demonstrate how the protocol can help a NDN applicationand present our preliminary evaluation. Finally, we concludein Section IV. II. D ESIGN
NDVR was designed to be a lightweight routing protocolfor wireless mobile adhoc mobile networks, which means thatit propagates reachability information in a highly dynamic The code is available on GitHub: https://github.com/italovalcy/ndvr scenario, with minimal configuration and no additional syn-chronization requirements. NDVR’s key design aspects are: • Dynamically detect neighbors lightweight protocol toexchange reachability information (i.e., NDN name pre-fixes) using a distance-vector algorithm • Provide support for highly dynamic mobile adhoc wire-less network • Use the NDN trust model to secure the protocol datapackets.To better understand where and how the NDVR protocol canbe used, consider the scenario illustrated in Figure 1. Figure1 represents an adhoc wireless scenario where, in the instantT0 (Figure 1A), there is a group of three nodes, A, B, andC. Each node has a wireless network interface configured inAdhoc mode. We assume a range wireless signal propagationmodel for simplicity, where the outer opaque circle representsthe range of each node. For example, the gray filled outercircle is the wireless range for A, the pink filled outer circleis the wireless range for B, and the green filled outer circlerepresents the wireless range for C. Thus, in Figure 1A thenodes A, B, and C are interconnected (they are in the wirelessrange of each other). In the instant T1 (after T0), a mobilenode D moves towards the group and reaches the wirelessrange of A, establishing a wireless link between D and A. Itis worth notice that D does not establish a wireless associationwith either A or C because the transmission power of Dis not strong enough to reach A’s or C’s reception antenna(i.e., A and C are not inside the blue circle representing D’stransmission range) and vice-versa (i.e., D is not inside thegreen circle representing C’s transmission range and D is notinside the pink circle representing A’s transmission range).Figures 1A’ and 1B’ represent the same scenario using arrowsto represent the wireless association between nodes. Thus, thearrow between A and B means that A is at the B’s wirelessrange and B is at A’s wireless range.Each node in the scenario can participate in the routingprocess by (i) advertising local reachability information (e.g.,name prefixes of NDN producer applications or repos runningon the same node) or by (ii) learning and disseminatingreachability information from other reachable neighbors. Toillustrate the routing process, let’s assume that every nodeadvertises its local prefixes, i.e., node A advertises /ndn/a ,node B advertises /ndn/b so on.We also assume that when the scenario first starts, the nodesdon’t know about each other; they don’t have any informationabout the neighborhood. This assumption also applies to node a r X i v : . [ c s . N I] F e b B C A B CD
Instant T0 Instant T1 (A) (B)
A B C A B CD (A') (B')
Fig. 1. Mobile adhoc wireless network scenario where the NDVR protocolwill be used. mobility: when a node moves around the topology, we assumethat the neighborhood is unknown and needs to be discovered.For example, when the topology starts in Figure 1A’, nodes A,B, and C don’t actually know they are neighbors. Indeed, theysend periodic messages to announce themselves, and so theyget to know the neighbors. Whenever a neighbor is detected,the node sends an Interest to retrieve the neighbor distancevector table with routing updates, if any.
A. Naming schema
A critical aspect of the design of NDVR is the namingschema and its relationship with the trust model. We took thehierarchical naming schema from NLSR and simplified it asmuch as possible to have the minimal naming components forthe protocol features and enabling the proper data validation.The protocol is designed so that each router is namedhierarchically under the network name prefix where the routerresides, followed by the actual router name. The router nameis formatted in three parts: the network or organization name(e.g. /google , /uf ba , /ndn ), router command marker (i.e., % C .Router ) and a router label (e.g., RouterA). For example,considering Figure 1B’ and supposing all the wireless routersare running at the UFBA University campus, they would benamed as /uf ba/ % C .Router/A , /uf ba/ % C .Router/B , /uf ba/ % C .Router/C and /uf ba/ % C .Router/D . Therouter name is supposed to be unique on the network. It maybe chosen from the hostname, highest ethernet MAC addressfrom all wireless interfaces, or specially created (e.g., the namecan be formatted to represent a hierarchical topology). Theuniqueness of the router name is important for the trust modelbecause it must match the name of the public key signing theprotocol data packets (more information on Section II-C).NDVR’s naming design is composed of two main messagetypes: EHLO and DVINFO. The EHLO message (ExtendedHello) is used for neighbor discovery and to announce whenthe router has new updates on its distance vector information.The DVINFO message (Distance Vector Information) is used to exchange the distance vector table with the neighbors. Bothmessages are only exchanged in the neighborhood, using thefollowing naming schema: • /localhop/ndvr/ehlo/ < RouterN ame > / < pref ixes > / < ver > / < digest > : this nameprefix is used to exchange EHLO messages betweenneighbors. Each router sends periodic interest packetsthrough all its faces. The ehlo interval can be configuredand defaults to one second to better deal with highlydynamic MANETs. To receive the neighbor’s ehlo mes-sages, each router has a pre-installed FIB entry that for-wards the /localhop/ndvr/ehlo interests to the NDVRapplication. The /localhop defines the scope in whichthe interest will be forward: only in the neighborhood[2]. The name component pref ixes is an integer torepresent the number of name prefixes the router hasto advertise. The number of prefixes is used to decidewhether the node should fetch or not the neighbor’sdistance-vector ( pref ixes ¿ 0). Furthermore, if a router- let’s say router A - has more prefixes to advertise thanits neighbor - let’s say router D -, the neighbor shouldrequest the distance-vector first. This is a prioritizationstrategy we adopt to avoid redundant distance-vectorexchange within a group of nodes. The name components ver and digest represent the distance vector tablestate, and they are used to help the neighbors fetch andsynchronize their distance vector information. • /localhop/ndvr/dvinf o/ < RouterN ame > / < ver > : this namespace is used to exchange on-demand distance vector information (DVINFO)between neighbors. As soon as a node, let’s sayA, detects that a neighbor, let’s say B, has newreachability information (i.e., pref ixes is greaterthan zero and the ver is newer than any previous- if any - and the digest is different from the localdistance vector table), then A sends an Interestfor B’s distance vector (e.g., interest.name = /localhop/ndvr/dvinf o/uf ba/ % C .Router/B/ )and B replies with its distance vector table as a signeddata packet. Once A receives the data packet containingB’s DVINFO, A starts the validation process. Thevalidation process may require B’s key if not previouslyseen. Thus, A will also send an interest for B’s keyaccording to the Key Locator from the DVINFO packet.Once A finishes the validation process successfully, Aprocesses B’s DVINFO using the well-known Bellman-Ford Distributed algorithm with sequence numbers[3]. • / < network > / < RouterN ame > /KEY : thisnamespace is used to fetch the keys that sign DVINFOdata packages. Following the same approach as NLSR,the nodes obtain the neighbors key by using a direct fetchmechanism. . Neighbor detection and routing updates propagation1) Neighbor detection: The neighbor detection process isbased on each node periodically sending Interest packetson its non-local faces. All nodes are pre-configured witha FIB entry to forward interests matching the namespace /localhop/ndvr/ehlo to the NDVR application (the pre-configuration is done by creating a FIB entry on the NDVRapplication startup routine). Figure 2 illustrates the neighbordetection since the moment zero when the network just started.The nodes don’t know about each other’s existence (Fig. 2A)until they all send periodic EHLO interests (Fig. 2B). A B CA B C (A) (B)
Fig. 2. Scenario to illustrate the neighbor discovery process.
Note that even though we enumerate the messages sent byA as 1, by B as 2, and by C as 3, there is no specific orderin which those events may occur. Each node runs its instanceof the NDVR protocol application, and they send the periodicEHLO by themselves. It is worthy of mentioning, though, thatdepending on the host communication model (i.e., the transportmethod - ethernet broadcast, unicast, udp, udp+multicast, etc.),if all nodes send their interest at the same time through thewireless shared medium, the network may be impacted bycollisions and packet loss (especially on the ndnSIM simula-tion environment, but also in real environments depending onthe communication model). A simple and effective strategyis to randomly wait a couple of milliseconds before startingthe periodic EHLO routine. The periodic EHLO messages arebased on the ehloInterval configuration parameter, whichdefaults to one second.Each node keeps a list of neighbors, along with their mostrecent DVINFO version, the last time the neighbor was seen,the first time has seen, and the face id from which the neighboris accessible (for multiple face scenarios).When a node moves around the topology, the NDVR routingprotocol must quickly detect new neighbors and neighborsthat moved away, then update its distance vector table. Theperiodic EHLO message works just as it is for detecting newneighbors. On the other hand, to remove an adjacency, theNDVR protocol waits a certain time without receiving EHLOmessages from a node to consider the node timed out and nolonger neighbor. The timeout for periodic EHLO messagesis based on the ehloInterval and configured through theparameter ehloM ultiplier , which defaults to 2, meaning thetimeout will be twice the ehlo interval value. Configuring the ehloM ultiplier to 1 leads to frequent neighbor removal dueto variations on the wireless medium propagation delay, and higher values may postpone the update of association statusfor mobile nodes.
2) Routing updates propagation:
Routing updates propaga-tion is the process in which the nodes notify their neighborsabout new name prefixes on-demand, and the neighbors fetchdistance vector information. The on-demand routing updatespropagation means that a node sends routing announcementsto its neighbors only when/if the node produces new dataand publishes reachability information about the produceddata through the NDVR routing protocol. For example, inthe previous scenario from Figure 1, node A runs the NDVRprotocol application and an NDN producer application, whichproduces data for the name prefix /ndn/a. The same appliesfor node b, with the name prefix /ndn/b, nodes c and d,with /ndn/c and /ndn/d, respectively. When the NDN producerapplication produces new data, it notifies the local NDVRprocess to announce the newly produced data. Then, theNDVR protocol application notifies its neighbors about newreachability information by sending the next EHLO with thenumber of prefixes, an incremented version, and a new digest.From the latest version and digest, the neighbors send interestfor the DVINFO.When an NDVR node sends an interest to notify new reach-ability information, the wireless shared medium - especiallyin adhoc mode with broadcast faces - multiple nodes in thesame communication range may receive the same interestnotification and request the DVINFO at the same time. NDVRadopts a prioritization approach where only a subgroup ofthe neighbors sends interest for the DVINFO right away.Other nodes in the communication range wait a backoff time before sending the interest, which will hopefully be satisfiedfrom their opportunistic cache populated from the answers forthe priority subgroup of neighbors. The size of the prioritysubgroup of neighbors defaults to two (primary and secondary)to guarantee at least one request even under packet lossenvironments. The subgroup of neighbors is chosen using arounding robin approach so that no single node is overloadedto request the DVINFO every time.Figure 3 illustrates the above approach in the same scenariopresented before (with all four nodes, A, B, C, and D). In thisexample, node A has new reachability information, and as so Asends an EHLO (1) with an increased version. In the EHLOinterest sent by A, it chooses B and C to be the requestersof its DVINFO; those are A’s priority subgroup. All otherneighbors not listed in A’s priority subgroup - in this case, D- will wait a time before sending its interest. Since B and Care in A’s priority subgroup, they will send an interest rightaway to fetch A’s DVINFO content (2 and 3). Router A willreceive two interests from B and C (unless there is packetloss); however, the order and inter-arrival time is unknown- it will depend on the wireless channel. Note that C alsoreceives the DVINFO interest from B (2), and B also getsthe DVINFO interest from C (3); however, since they are not Backoff time here refers to the strategy of decreasing the rate of someprocess to gradually find an acceptable rate. In particular, it was used to waitfor some period in order to avoid collisions or redundant interest. roducers for that name prefix and due to the localhop scope,they drop the interest. To avoid answering the same interesttwice (one from the application and another from the cache),A also delays its content for some milliseconds increasing thechange to avoid extra overhead. When A sends the data packetwith its DVINFO table (4), all nodes in the communicationrange will receive it. Thus, D will overhear A’s DVINFO andopportunistically save this data on its content store. Later,when D finishes the wait time, it will fetch A’s DVINFOfrom the content store. To enable a node to overhear NDVRDVINFO data packets, we deployed a custom ”unsolicited datapolicy” which caches NDVR data packets (the default policyis to drop unsolicited data packets).
A B CD
EHLO InterestDVINFO InterestDVINFO Data
Fig. 3. DVINFO exchange between nodes. A send a notify interest, B andC request A’s DVINFO and B, C, D receive the reply (D overhears) .
Table I illustrates the messages exchanged in the scenariopresented in Figure 3. From the column Name, which rep-resents a simplified name in the NDN packet, you can seehow A represents its priority subgroup - by using applicationparameters. We can also see how B and C generate twointerests for the same name prefix (different nonces).
ACKET FLOW REPRESENTING THE
DVINFO
EXCHANGE PROCESS FROM F IGURE To encapsulate the distance vector table into the NDNdata content, NDVR serializes the distance vector informationusing Google’s protocol buffer (protobuf) standard . Amongmany other serialization strategies, protobuf showed to be veryefficient and flexible. The information encapsulated into theDVINFO data packet is: the reachable name prefix cost toreach the name prefix and sequence number. Like NLSR, thereachable name prefix refers to name prefixes that a router orits directly connected neighbors can reach. In other words, theyeither produce or host content with names that fall under theadvertised name prefixes. The cost to reaching the name prefixis a metric provided by NDVR to qualify the path towards the https://developers.google.com/protocol-buffers/docs/cpptutorial name prefix’s origin. The cost can be based on the hop count orany other strategy (e.g., cumulative delay, residual bandwidth,signal strength, etc.). NDVR’s cost defaults to hop count.Finally, the sequence number is used to represent the freshnessof the route and avoid counting-to-infinity problems [4] (alsoreferred to as short-term and long-term routing loops, whichare well-known problems present on the Distributed Bellman-Ford (DBF) basic distance vector algorithm). The usage ofsequence numbers on mobile adhoc networks is well discussedin the literature [4], and one of its primary examples is theDSDV routing algorithm [3]. The basic idea of using sequencenumbers is to tag each name prefix on the origin routerwith a monotonically increasing number and use this numberlater in the routing propagation process (as part of the DBFalgorithm) to determine the relative freshness of reachabilityinformation (the highest sequence number is preferred). Werefer to [4, Section 3.3.1] and [3] for more details on thesequence numbers for MANET routing algorithms.The algorithm for processing the distance vector informa-tion is shown in Listing 1. It is mostly the basic DBF algorithmwith sequence numbers. The main difference is the incomingNDN face as the next hop for later installing the resultingroutes on the FIB. The function calculateCost() incrementsthe hop count as the routing selection metric. Node i receives a DvInfo message from neighbor j For each name prefix d on DvInfo message: cost_i_d = calculateCost(j, cost_j_d) if isNewPrefix(d) or (seqNum_i_d < seqNum_j_d) or((seqNum_i_d == seqNum_j_d) and (cost_i_d >cost_j_d)) then learnPrefix(d, nextHop = j, cost = cost_i_d,seqNum = seqNum_j_d) Listing 1. Simplified algorithm for processing the DVINFO (mostly based inDBF algorithm with sequence number).
C. Security
Every NDN Data packet is digitally signed, covering thename, content, and metadata. The public key used to sign theNDN Data packet is specified in the actual packet, in the fieldKeyLocator. The data packet validation follows a workflowwhere i) the client fetches the key specified on the KeyLocator,ii) the client validates the public key properties (expiration,revocation, cryptography algorithms) and authenticates thekey against the trust model (trust anchors and validationrules), iii) the client verifies the signature on the data packet.NDVR leverages data validation for reachability exchange bydeploying a simplified trust model and validation rules.NDVR uses a two-level hierarchical trust model to representthe intra-domain routing structure, as shown in Table II. Thereare only two levels on the trust chain: the Network Key, whichis our trust anchor, and as so it is supposed to be pre-installedon all nodes; the Router Key, which is used to sign the datapackets directly. The Network Key is used to validate theRouter Key, which turns to be used to validate NDVR datapackages (i.e., DVINFO). This relationship between all thosekeys and the trust model is shown in Figure 4.Listing 2 shows the validation rules applied to NDVRpackets. There are three validation rules, starting from bottom ey owner Key nameNetwork (Trust Anchor -pre-installed) /¡network¿/KEYRouter /¡network¿/¡routerName¿/KEYTABLE IIS
IMPLIFIED T RUST M ODEL FOR
NDVR.
NetworkRoot Key Router Key NDVRpackets signverified by signverified by
Fig. 4. Illustration of the relationship between the keys in NDVR trust model. to top: i) in lines 57-61 is the validation rule for the trustanchor, which trust is assumed (not derived); ii) in lines 29-55, validation rule to ensure the router key is signed bythe network key (trust is derived); and finally, iii) lines 1-27 which include the validation rule for the DVINFO datapackets, which must be signed by a router key with the samename of the DVINFO routerName component name (trust alsoderived). rule { id "DvInfo data should be signed by Router’s key" for data filter { type name regex ˆ
III. P
RELIMINARY E VALUATION
The preliminary evaluation was based on two experimentsto validate how the routing protocol can help different aspectsof a NDN scenario: using the routing protocol on a DataSynchronization scenario and using the routing protocol tohelp the forwarding strategy.
A. Routing and Data Synchronization
To evaluate how routing can help the data synchronizationfunction, this experiment compares NDVR routing protocoland a simple producer/consumer NDN application versusDDSN (Distributed Dataset Synchronization over disruptiveNetworks) [5]. DDSN was chosen to be compared because,even though it is a synchronization strategy (not routing),it does provide some features for mobile adhoc networksthat a routing strategy can also provide. To provide a faircomparison, NDVR routers also run a simple NDN syncapplication that produces and fetch data upon receiving anew name prefix from NDVR’s routing announcements. Thus,the sync protocol can be seen as i) state synchronization(i.e., learn the latest data generated by others) is providedby NDVR by propagating reachability information about eachname prefix of latest generated data; ii) data synchronization(i.e., fetch the newly learned data) is provided by the simplesync NDN application. We are working on future evaluationsmore suitable for the routing strategy specifically.The evaluation scenario is similar to the proposed on DDSNpaper [5]: 20 mobile nodes on an 800m x 800m topology withmobility based on the Random Walk Mobility Model, speedranges from 1m/s to 20m/s, direction ranges from to π ,each node moves along the same path for 20s before changingits direction and speed, network device IEEE 802.11b 2.4GHz(transmission rate of 11Mbps), Wi-Fi propagation model basedon a maximum range of 60m. Each node generates datafollowing a Poisson distribution with λ = 40 s on average,and its data generation process lasts for 800s.Figure 5 presents the CDF graph of the data retrieval delayfor DDSN and NDVR+SimpleProdCons (NDVR). And Figure6 illustrates the protocol overhead (considering a 95% confi-dence interval) in terms of the total number of packets. Figure
100 200 300 400 500Delay (s)0.00.20.40.60.81.0
CDF
DDSNNDVR
Fig. 5. Data retrieval delay, NDVR+SimpleSync and DDSN.
NDVR DDSN0500010000150002000025000 ndvr-ehlo-interestndvr-dvinfo-interestndvr-dvinfo-dataddsn-sync-interestddsn-sync-ack
Fig. 6. Protocol overhead in total number of packets, NDVR and DDSN.
B. Routing and Forwarding strategies
This experiment evaluates how the routing protocol can helpa forward strategy in better doing its task of selecting a subsetof next-hop and forward interests. We investigate four differentconfigurations in the same scenario: i) multicast forwardingstrategy with a default route , ii) m-ASF (Adaptive SmoothedRTT-based Forwarding - ASF - for mobile networks [6]) anddefault route, iii) NDVR routing plus multicast forwarding,and iv) NDVR plus m-ASF. The scenario was based on atopology with 15 mobile nodes on a 300 m x 300 m areawith a group mobility model based on Reference Point GroupMobility, the average group size of 3 nodes with a standarddeviation . and zero group change probability. Speed rangesfrom 1m/s to 20m/s, network device IEEE 802.11b 2.4GHz(transmission rate of 11Mbps), Wi-Fi propagation model based The default route means one FIB entry for the name / and using thewireless adhoc face as next-hop on a maximum range of 60m. Every node produces data on adifferent name prefix ( /ndn/dataSync/X , X being the nodeid). They also consumes data from all other nodes, followinga Constante Bit Rate traffic model, with IDT = 100 ms (InterDeparture Time) and P S = 300 bytes (Payload size) during100 seconds.
Data delivery rate (all nodes)
Total forwarded packets (all nodes)
Packet per second ndvr_mcastndvr_masfmasfmcast
Fig. 7. Data delivery rate and total forwarded packets among differentstrategies with and without NDVR routing protocol
Figure 7 presents the Data Delivery Rate and the TotalOverhead (Total number of forwarded packets), both aggre-gated for all nodes. Regarding the data delivery rate, it ispossible to see that both multicast and m-ASF forwardingstrategies benefit from using the NDVR routing. The higherdata delivery rate results from an efficient name reachabilityinformation propagation that saves the nodes from forwardingunnecessary interests when the data is not reachable. Thetotal number of forwarded packets also reflects how therouting protocol reduces overhead and, consequently, reducescollisions/contention on the wireless channel. On average, forthe data delivery rate, the multicast strategy improved from . ± . pps to . ± . pps , and the m-ASF strat-egy improved from . ± . pps to . ± . pps .For the overhead, the multicast reduced from . ± . pps to . ± . pps and the m-ASF reducedfrom . ± . pps to . ± . pps .IV. C ONCLUSION
This technical report presented the development of NDVR(NDN Distance Vector Routing), a routing protocol for NDNmobile adhoc networks. NDVR design consists in the simplestpossible way to propagate name prefix reachability infor-mation based on distance vector algorithms. Neighbors aredetected dynamically, and routing updates are propagatedon-demand. Furthermore, NDVR from the wireless sharedmedium and NDN opportunistic caching characteristics toreduce the protocol overhead by using specific strategies whenbroadcasting protocol messages in a group of nodes. Thesimplified trust model and strict validation rules ensure thereachability information exchange is secure, allowing onlytrusted routers to participate in the routing propagation pro-cess.NDVR was preliminarily evaluated using a prototype de-veloped in the ndnSIM simulator and a comparison withhe DDSN synchronization strategy and evaluated on theintegration with multicast and m-ASF forwarding strategies.The results are promising, showing a comparable performancefor data retrieval delay, efficient data reachability informationpropagation, and enhanced protocol overhead.V. A
CKNOWLEDGMENTS
I want to thank my shepherd, professor Leobino Sampaio,for his valuable comments, suggestions, and thoughtful dis-cussions. I also thank professor Lixia Zhang for the collabo-rations. R
EFERENCES[1] I. V. S. Brito, L. Sampaio, and L. Zhang, “Ndncomm 2020 poster:Towards a distance vector routing protocol for named data networking,”
Named Data Networking Community Meeting 2020 , 2020.[2] NDN Project, “Namespace-based scope control, localhop scope,” https://redmine.named-data.net/projects/nfd/wiki/ScopeControl, accessed: 2021-02-10.[3] C. E. Perkins and P. Bhagwat, “Highly dynamic destination-sequenceddistance-vector routing (DSDV) for mobile computers,”
ACM SIGCOMMcomputer communication review , vol. 24, no. 4, pp. 234–244, 1994.[4] P. Mohapatra and S. Krishnamurthy,
AD HOC NETWORKS: technologiesand protocols . Springer Science & Business Media, 2004.[5] T. Li, Z. Kong, S. Mastorakis, and L. Zhang, “Distributed datasetsynchronization in disruptive networks,” in . IEEE, 2019,pp. 428–437.[6] M. Chowdhury, A. Lane, and L. Wang, “Ndncomm 2020 presentation: m-asf - an adaptive srtt-based forwarding strategy for mobile environments,”