1. International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-6367(Print),
INTERNATIONAL JOURNAL OF COMPUTER ENGINEERING &
ISSN 0976 - 6375(Online), Volume 5, Issue 2, February (2014), pp. 108-116 © IAEME
TECHNOLOGY (IJCET)
ISSN 0976 – 6367(Print)
ISSN 0976 – 6375(Online)
Volume 5, Issue 2, February (2014), pp. 108-116
© IAEME: www.iaeme.com/ijcet.asp
Journal Impact Factor (2014): 4.4012 (Calculated by GISI)
www.jifactor.com
IJCET
©IAEME
MODELING OF DSDV ROUTING PROTOCOL FOR AD HOC NETWORKS
USING EVENT-B
Arun Kumar Singh1,
Vinod Kumar singh2
1
2
Electronics Engineering Department, IET, UPTU, Lucknow, India
Professor, Electronics Engineering Department, IET, UPTU, Lucknow, India
ABSTRACT
Ad hoc networks are dynamic networks of mobile nodes with wireless network interfaces
forming an instant network without fixed topology. Destination-sequenced distance vector (DSDV)
is a proactive routing protocol, which continuously maintains the topological information and
whenever communication is needed such route information is available immediately. DSDV is a
modification of the conventional Bellman-Ford routing algorithm to make it suitable for ad hoc
networks. For any routing algorithm route discovery is an important task. In Ad hoc networks,
broadcasting is the basic mechanism by which route discovery and propagation of routing is done.
Therefore, routing algorithms must be robust and free from erratic behaviors. Hence formal
specifications are needed to ensure correctness of routing protocols that are used Ad hoc networks.
Formal methods are mathematical techniques which are used to develop software model.
Event-B is formal technique that enables user to express the problem at abstract level and then add
more details in refinement step to obtain concrete specification. The Event-B model generates proof
obligations. For ensuring correctness of the system we need to discharge all proof obligations. With
this backdrop, the paper focuses on formalizing protocols for routing in Ad hoc networks by using
destination-sequenced distance vector routing. The model ensures bi-directional links and loop free
routes in routing packets.
Keywords: Formal Methods, Formal Specification, Event-B, DSDV, Ad hoc Networks.
1. INTRODUCTION
Ad hoc networks differ significantly from conventional networks in the dynamic topology of
interconnections and automatic administration for setting up the network. The topology of the Ad
hoc can be arbitrary at any time. With the change of the topology of an Ad hoc network, the nodes
in the network have to update their routing information automatically and instantly [1].
108

2. International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-6367(Print),
ISSN 0976 - 6375(Online), Volume 5, Issue 2, February (2014), pp. 108-116 © IAEME
Traditionally, the network routing protocols could be divided into proactive protocols and
reactive protocols. Proactive protocols continuously learn the topology of the network by exchanging
topological information among the network nodes. Thus, when there is a need for a route to a
destination, such route information is available immediately. One of the early protocols that have
been proposed for routing in ad hoc networks is proactive Distance Vector protocols based on the
Distributed Bellman-Ford (DBF) algorithm [2].Destination sequenced distance vector routing
(DSDV) is adapted from the conventional Routing Information Protocol (RIP) to ad hoc networks
routing. It adds a new attribute, sequence number, to each route table entry of the conventional RIP.
Using the newly added sequence number, the mobile nodes can distinguish stale route information
from the new and thus prevent the formation of routing loops.[1]
Numerous formal methods have been applied to the analysis of network protocols. It includes
model checking [3, 4], theorem proving [5], and development by refinement [6, 7]. With reference to
routing protocols, probably the most detailed study [8], has applied an interactive theorem prover
(HOL) together with a model checker (SPIN) to verify different properties of distance vector routing
protocols. In the study [8], case studies have been carried out to analyze the Routing Information
Protocol (RIP) standard and the Ad-Hoc On-Demand Distance Vector (AODV) protocol. The work
regarding formal modeling of topology discovery in changing environment can be found in [13]. In
this case study we have developed the formal model of Destination Sequenced Distance Vector
routing protocol using Event-B.
The rest of the paper is organized as follows: Section 2 presents our modeling approach and
the introduction to Event-B, Section 3 discusses the formal model of DSDV in Event-B and the last
section 4 concludes the paper.
2. FORMAL MODELING USING EVENT-B
A development in Event-B [9] is a set of formal models. A model contains the complete
mathematical development of a Discrete Transition System. Event-B has a semantics based on
transition systems and simulation between such systems, described in [10]. Event-B models are
organized in terms of the two basic constructs: contexts and machines. Contexts specify the static
part of a model whereas machines specify the dynamic part. Within the Event B framework,
asynchronous systems may be developed and structured using abstract systems [10]. Abstraction can
be viewed as a process of simplifying our understanding of a system, by identifying the key features
of the system to be modeled, by focusing on intended purpose of the system and ignoring details of
how that purpose is achieved.
Event-B supports refinement to augment the functionality being modeled, or introducing
details about the dynamic properties of a model. In refinement steps we refine one model M1 to
another model M2, model M2 to model M3 and so on, till the desired functionality is achieved. The
states of the abstract machine are related to the states of the concrete machine by gluing invariants J
(v, w), where v and w are the variables of the abstract machine and concrete machine respectively.
With abstraction, we can postpone treatment of some system features to later refinement steps.
Event-B provides a notion of consistency of a refinement by generating the proof obligations and
providing an environment to discharging the proof obligations while failing proof can help us to
identify inconsistencies in a refinement step. Refinement and abstraction allow us to manage the
complex system in the design process by first describing the abstract problem, introducing solutions
or details in refinement steps to obtain more concrete specifications and verifying that proposed
solutions are valid.
109

3. International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-6367(Print),
ISSN 0976 - 6375(Online), Volume 5, Issue 2, February (2014), pp. 108-116 © IAEME
2.1 MACHINES AND CONTEXTS
Machines specify behavioral properties of Event-B models. It may contain variables,
invariants, theorems, events and variants of a model. Variables v defines the state of a machine. They
are constrained by invariants I (v). Possible state changes are described by events while Contexts
may contain carrier sets, constants, axioms, and theorems. Carrier sets are similar to types [9].
Axioms constrain carrier sets and constants, whereas theorems express properties derivable from
axioms.
Machines and contexts have various relationships: a machine can be “refined” by another
one, and a context can be “extended” by another one (no cycles are allowed in both these
relationships). Moreover, a machine can “see” one or several contexts [10].
A model can only contain contexts, or only machines, or both. In the first case, the model
represents a pure mathematical structure. In the third case, the machines of the model are
parameterized by the contexts. Finally, the second case represents a machine which is not
parameterized.
Machines contain the variables, invariants, theorems, and events of a model, whereas
contexts contain carrier sets, constants, axioms, and theorems of a model:
Machines and contexts have various relationships: a machine can be “refined” by another one, and a
context can be “extended” by another one (no cycles are allowed in both these relationships).
Moreover, a machine can “see” one or several contexts.
A model can only contain contexts, or only machines, or both. In the first case, the model
represents a pure mathematical structure. In the third case, the machines of the model are
parameterized by the contexts. Finally, the second case represents a machine which is not
parameterized.
2.2 EVENTS
A machine event represents a transition. Each event is made of guard G (v) and action S (v).
The guards together denote the necessary condition for the event to be enabled, whereas the actions
together represent the way the variables of the corresponding machine are modified. An event can be
represented by the term -when G (v) then S (v) end.
Events can have no guards, they can be also simple and guarded (keyword where) or
parameterized and guarded (keywords any and where). When an event lies in a machine which
refines another one then the event may specify (if any) the abstract event(s) it refines (keyword
refines). When a refining event refines an abstract event which is parameterized, one may provide
some witnesses (keyword with). The status of the event can be normal, convergent or anticipated. A
“convergent” event must be a new event in a refined machine (one that does not appear in the
abstraction). All convergent events in a machine are concerned with the variant section of that
machine. An “anticipated” event is a new event which is not “convergent” yet but should become
“convergent” in a subsequent refinement.
A machine event represents a transition. It is essentially made of guards and actions. The
guards together denote the necessary condition for the event to be enabled, whereas the actions
together represent the way the variables of the corresponding machine are modified. Events can have
no guards, they can be also simple and guarded (keyword where) or parameterized and guarded
(keywords any and where). When an event lies in a machine which refines another one then the event
may specify (if any) the abstract event(s) it refines (keyword refines). When a refining event refines
an abstract event which is parameterized, one may provide some witnesses (keyword with).
110

4. International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-6367(Print),
ISSN 0976 - 6375(Online), Volume 5, Issue 2, February (2014), pp. 108-116 © IAEME
3. FORMAL DEVELOPMENT OF DSDV USING EVENT- B
3.1 INFORMAL DESCRIPTION OF DSDV PROTOCOL
Destination Sequenced Distance Vector is proactive routing protocol having new attribute of
sequence number to make it more suitable for Ad hoc networks. The DSDV routing protocol [11]
provides a single path to a destination, which is selected using the distance vector shortest path
routing algorithm. The routing table gives the best distance to each destination and which route to get
there by periodic updating of information with all its neighbors.
Routing denotes the selection of paths through a network for sending data from a source to a
destination. A path may require the data message to travel over multiple nodes, each node being an
intermediate router. In routing protocols each host works as a router and constructs a graph
representing the network topology. In this graph, vertices and edges represent routing nodes and
direct connection between nodes, respectively. To specify the correct desired properties of protocol
at abstract level and in carrying out the development and proofs in subsequent refinement models, is
a challenging problem [12, 13, 14].
The next section 3.2 describes the formal development of Distance vector protocol.
3.2 FORMAL DEVELOPMENT
In this paper, we have presented the formal development of Destination Sequenced Distance
Vector routing protocol using Event B. The abstract model (Fig.1) specifies the environmental
assumptions and system requirements for basic communication
Machine RoutingM
Sees RoutingC
Variables sent, got, lost, A Links
Invariants
inv1:
sent ⊆ MSG
inv2: got ⊆ MSG
inv3:
lost ⊆ MSG
inv4: ALinks∈(NODE↔NODE)
inv5:
got ∪ lost ⊆ sent
inv6: got ∩ lost = ∅
Fig 1: Abstract Machine
protocol [12] of data packet sending, losing and receiving as well as changes in network topology by
using events: ADD_LINK, DEL_LINK, SEND, RECEIVE and LOSING. In the context of machine
NODE and MSG are defined as a carrier set which represent the set of nodes and the messages
respectively. For the given network it is assumed that there are only finite numbers of directed nodes.
The variables sent, got and lost are defined as a subset of MSG (Fig.1). The variable ALinks which is
defined as: ALinks ∈ NODE↔NODE represents the set of active links.
111

5. International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-6367(Print),
ISSN 0976 - 6375(Online), Volume 5, Issue 2, February (2014), pp. 108-116 © IAEME
Variables:
sent,got,lost,ALinks,Chstore,dseq,nexthop,dseqm,nexthopm,nodemetric,neighbour,
nodemetricm,intmednode
Invariants :
inv1 :
inv2 :
inv3 :
inv4 :
inv5 :
inv6 :
inv7 :
inv8 :
inv9 :
inv10 :
inv11 :
inv12 :
inv13 :
inv14 :
chstore∈ NODE ↔MSG
∀i·i ∈ NODE ∧ i ∈ dom(chstore)⇒(got ∪ lost) ∩ chstore[{i}] = ∅
ran(chstore) ∪ (got ∪ lost) = sent
∀i·i ∈ NODE ⇒chstore[{i}] ⊆ sent
∀m·m ∈ MSG ∧m ∉ sent⇒(m ∉ got ∧m ∉ lost ∧ (∀i·i ∈ NODE ⇒i↦m ∉
chstore))
∀m, i, j·i↦ m ∈ chstore ∧ j↦ m ∈ chstore⇒i = j
dseq ∈ NODE→(NODE→ℕ)
nexthop ∈ NODE→(NODE→NODE)
dseqm ∈ MSG→(NODE→ℕ)
nexthopm ∈ MSG→(NODE→NODE)
nodemetric ∈ NODE→(NODE→ℕ)
neighbour∈NODE↔NODE
nodemetricm ∈MSG→(NODE→ℕ)
intmednode⊆ NODE
Initialisation :
act1:
sent≔∅
act2:
got≔∅
act3:
lost≔∅
act4:
ALinks≔∅
act5:
chstore≔∅
act6:
dseq≔NODE×{NODE×{dsq}}
act7:
nexthop≔NODE×{NODE×{n0}}
act8:
dseqm≔MSG×{NODE×{0}}
act9:
nexthopm≔MSG×{NODE×{n0}}
act10:
nodemetric≔linkvalue0
act11:
neighbour≔neighbour0
act12:
nodemetricm≔MSG×{NODE×{0}}
act13:
intmednode ≔∅
Fig 2. Variables, Invarients and Initialisation of DSDV machine
For DSDV machine, the variables, invariants and there initialization is given in Fig2 which
also includes variables of basic communication protocol [12, 15]. Every site maintain the
information about sequence number of destination site. The variable dseq represents sequence
number of destination site. It is represented as dseq ∈ NODE→ (NODE→ℕ). A mapping
{sm({tmn1}) } ∈ dseq indicates that routing table of site s has entry that n1 is the sequence number of
destination site t. The variable nexthop give the information about next hop entry of a node to reach a
destination. A mapping {n1m({n2mn3}) } ∈ nexthop represents that to reach a destination node n2,
n3 is nexthop for the node n1.The variable nodemetric contains the information about the total hop
count from a particular node. The site sends the routing information through the messages. Any site
updates its routing information after receiving the message. The variable dseqm contain the sequence
number of nodes. It maps each message to sequence number function. The sequence number function
maps each node to natural number. The length of sequence number function is number of nodes
112

6. International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-6367(Print),
ISSN 0976 - 6375(Online), Volume 5, Issue 2, February (2014), pp. 108-116 © IAEME
present in the system. Therefore, dseqm(m) contains sequence number of each node. Similarly,
variable nexthopm contains nexthop entry of a destination node in a message. A mapping
{m1m({n1mn2}) } ∈ nexthopm indicates that message m1 has the information that for the destination
node n1, node n2 is next hop .The hope count information in a broadcast message is maintained by
nodemetricm. The neighbour of a node is represented through the variable neighbour. It is
represented as: neighbour∈NODE↔NODE. Any node has several neighbour node therefore it is
declared as relation.
Refines Send
Send
Any s,t, datamsg Where
grd1 : s∈NODE
grd3 : s≠t
grd5 : datamsg ∉ sent
grd7 : target(datamsg) = t
Then
act1 : sent ≔ sent ∪ {datamsg}
act3 : dseqm(datamsg)≔dseq(s)
End
grd2 :
grd4 :
grd6 :
grd8 :
t∈NODE
datamsg ∈ MSG
source(datamsg) = s
s↦datamsg ∉chstore
act2 :
act4 :
chstore ≔ chstore ∪ {s↦ datamsg}
nodemetricm(datamsg)≔nodemetric(s)
Fig 3. Send Event
Send Event:
This event models the sending of messages from one node to other node. The message datamsg has
not been sent is insured through guard grd5. The site s and site t is source and destination site is
specified through guard grd6 and guard grd7 respectively. The guard grd8 is written as:
s↦datamsg ∉ chstore It ensures that message datamsg is not present in the channel. The message
contains all the routing information of sending node. The action act1 add the datamsg message in the
sent variable. The action act2 add the message datamsg in to the channel. The action act3 assigns the
sequence number to message datamsg. The sequence number of sender site s is assigned to message
datamsg. The action act4 asigns the nodemetric value to message datamsg.
Forward
Any datamsg, x, y, t Where
grd1 :
t∈NODE
grd3 :
x↦ y ∈ ALinks
grd5 :
target(datamsg) = t
grd7 :
Then
act1 :
grd2
:
grd4
:
grd6
:
grd8 :
x↦ datamsg ∈ chstore
chstore ≔ (chstore ∖
{x↦datamsg})∪ {y↦datamsg}
act2 :
datamsg ∈ sent ∖ (got ∪ lost)
y∈neighbour[{x}]
x ≠ target(datamsg)
y↦datamsg ∉chstore
intmednode≔{x}
End
Fig 4: Forward Event
Forward Event:
This event forward the routing update messages from one node to other node. The message
datamsg has been sent but not received and lost is ensured through guard grd2. The guard grd3
ensures that node x and y are connected. The guard grd4 ensures that y is a neighbour of node x. The
113

7. International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-6367(Print),
ISSN 0976 - 6375(Online), Volume 5, Issue 2, February (2014), pp. 108-116 © IAEME
target of message datamsg is t is ensured through guard grd5. The guard grd6 specifies that x is not
target of message datamsg. The guard grd7 specifies that update message datamsg is currently
located at site x. The guard grd8 specifies that message datamsg is not present at site y. The action
act1 indicates passing of message datamsg from node x to node y. The action act2 maintains the
information about sender of message datamsg.
Initiate_Routing_Table
Any n, tempnodemetric, n2,nr,v,
tempnodemetric1
Where
grd1:
tempnodemetric1∈ NODE→(NODE grd2:
→ℕ )
tempnodemetric∈ NODE→(NODE
→ℕ )
grd3:
n∈NODE
grd4:
nr∈neighbour[{n}]
grd5:
n2∈NODE
grd6:
n2≠n
grd7:
n2≠nr
grd8:
v=linkvalue0(n)(nr)
grd9:
tempnodemetric(n)=nodemetric(n)+ grd10
:
{n↦0}
tempnodemetric1(n)=tempnodemet
ric(n)+{nr↦v}
Then
act1:
nodemetric(n)≔tempnodemetric1(n)+{n2↦infinite}
End
Fig5: Initiate Routing Table Event
Initiate Routing Table Event:
Every node maintains entry of metric count value. This value gives total distance to
destination node from a given node. This event assigns the matric value for a particular node. This
event assigns a value to the node matric of node n for neighbour node nr. The value represents
distance to the neighbour node. It also assigns infinite value for those node n2 which are not in
neighbour of node n. The guard grd4 specifies that node nr is neighbour of node n. The node n2 is a
node which is not neighbour of node n is specified through guard grd7. The value v indicate the link
value between node n and neighbour nr. The grd guard9 specifies that nodematric value from node n
to itself is zero. The guard grd10 specifies that distance of neighbour node is v. The action act1
assigns infinite value to those node which are not in neighbour.
Initiate_Routing_Table2
Any tempnexthop, nr, n
Where
grd1:
tempnexthop∈ NODE→(NODE→NODE)
grd3:
grd2: nr∈neighbour[{n}]
tempnexthop(n)=nexthop(n)+{n↦n}
Then
act1:
nexthop≔nexthop+(λdest•dest∈NODE∧ dest≠n ∧
nr↦dest∈path(ALinks)∣tempnexthop(n)+{dest↦nr})
End
Fig6: Initiate RoutingTable2 Event
114

8. International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-6367(Print),
ISSN 0976 - 6375(Online), Volume 5, Issue 2, February (2014), pp. 108-116 © IAEME
Initiate_Routing_Table2:
This event makes the next hop entry for each destination node. The guard grd2 ensures that node nr
is neighbour of node n. The guard grd3 specifies that nexthop entry of a node n for the destination
node n will be same i.e., node n. The action act1 is wriiten as:
nexthop≔nexthop+(λdest·dest∈NODE∧ dest≠n ∧ nr↦dest∈path(ALinks)∣tempnexthop(n)+{dest↦nr
})
It represents that for every node dest, if there is a path from neighbour node nr then nr will be next
hop of the node n for the destination node dest.
Routing_Table_Update
Where
grd1 :
v∈ℕ
grd2 :
p∈NODE
grd3 :
y∈NODE
grd4 :
intmednode={y}
grd5 :
s∈NODE
grd6 :
source(datamsg)= s
grd7 :
x ↦ y∈ALinks
grd8 :
x ≠ source(datamsg)
grd9 :
x↦ datamsg ∈ chstore
grd10 :
p∈dom(dseqm(datamsg)
grd11 :
∃k·(k∈NODE⇒dseq(x)(k)< dseqm(datamsg)(k))
grd12 :
dseq(x)(p)< dseqm(datamsg)(p)
grd13 :
v=(nodemetric(x)(y)+nodemetricm(datamsg)(p))
Then
act1 :
dseq(x)≔dseq(x)+({k∣k∈NODE∧ dseq(x)(k)<
dseqm(datamsg)(k)} dseqm(datamsg))
act3:
act2: nexthop(x)≔nexthop(x)+{p↦y}
nodemetric(x)≔nodemetric(x)+{p↦v}
◁
End
Fig7: Routing_Table_Update Event
4. CONCLUSION
This paper presents formal modeling of Destination Sequenced Distance Vector routing
protocol. We have used Event-B as a formal method for writing specifications. Event-B generates
proof obligations which need to be discharged for ensuring correctness of the system. Rodin
platform has been used for discharging proof obligations. Total, sixty five (65) proof obligations
have been generated by the system through consistency checking. Out of 65, sixty two (62)
obligations have been discharged automatically, while remaining three (03) requires interaction
with the prover. The model presented in the current paper provides a valuable insight in protocol
implementation which may be further applied to other routing protocols for ad hoc networks.
ACKNOWLEDGEMENTS
The authors acknowledge the valuable suggestions of Er. Raghuraj Suryavanshi and Prof.
Girish Chandra, Department of Computer Science and Engineering, IET, UPTU, Lucknow.
115

9. International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-6367(Print),
ISSN 0976 - 6375(Online), Volume 5, Issue 2, February (2014), pp. 108-116 © IAEME
REFERENCES
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
Guoyou He: Destination-Sequenced Distance Vector (DSDV) protocol. Technical report,
Helsinki University of Technology, Finland.
Tanenbaum Andrew S.: Computer Networks, Prentice Hall, Inc., 1996, ISBN 7-302-02410-3.
Christel Baier and Joost-Pieter Katoen: Principles of Model Checking. The MIT Press, 2008.
Gerhard J. Holzmann: The Spin Model Checker: Primer and Reference Manual. Addison–
Wesley, 2003.
Marco Devillers, David Griffioen, Judi Romijn, and Frits Vaandrager: Verification of a leader
election protocol: Formal methods applied to ieee 1394. Form. Methods Syst. Des.,
16(3):307–320, 2000.
Abrial, J.R., J.R., Cansell, D.,M´ery, D.:A Mechanically Proved and Incremental Development
of IEEE 1394 Tree Identify Protocol. Formal Asp. Comput. 14(3), 215–227, 2003.
A Udaya Shankar and Simon S Lam: A stepwise refinement heuristic for protocol
construction.ACM Transactions on Programming Languages and Systems, 14(3):417–461,
1992.
Karthikeyan Bhargavan, Davor Obradovic, and Carl A. Gunter: Formal verification of
standards for distance vector routing protocols. J. ACM, 49(4):538–576, 2002.
Abrial, J.R.:Modeling in Event-B: System and Software Design. Cambridge University Press,
2010.
Abrial, J.R.: Extending B without Changing it (for developing distributed systems). Proc. of
the 1st Conf. on the B method, H. Habrias (editor), France, pages 169–190, 1996.
Perkins Charles E., Bhagwat Pravin: Highly Dynamic Destination-Sequenced Distance-Vector
Routing (DSDV) for Mobile Computers, London England UK, ACM SIGCOMM’94, 1994,
pp. 234–244.
Dominique M´ery and Neeraj Kumar Singh:Analysis of DSR Protocol in Event-B 13th
International Symposium on Stabilization, Safety, and Security of Distributed Systems (2011)
401-415.
Hoang, T.S., Kuruma, H., Basin, D.A., Abrial, J.R.: Developing Topology Discovery
in Event-B. In: Leuschel, M., Wehrheim, H. (eds.) IFM 2009. LNCS, vol. 5423,
pp. 1–19.Springer, Heidelberg (2009)
Butler, M.: Incremental Design of Distributed Systems with Event-B, Marktoberdorf Summer
School 2008 Lecture Notes (2008), http://eprints.ecs.soton.ac.uk/16910
Singh, A.K and Singh, V.K.: Formal Modeling of Distance Vector Routing Protocol using
Event-B in Advance in Electronic and Electric Engineering ISSN 2231-1297, Volume 3,
Number 1 (2013), pp. 91-98.
116