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,
1 2

Vinod Kumar singh2

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

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

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

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 Variables sent, got, lost, A Links Invariants inv1: inv3: inv5: sent MSG lost MSG got lost sent inv2: got MSG inv4: ALinks(NODENODE) 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 NODENODE represents the set of active links. Sees RoutingC

111

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 ii NODE i dom(chstore)(got lost) chstore[{i}] = ran(chstore) (got lost) = sent ii NODE chstore[{i}] sent mm MSG m sent(m got m lost (ii NODE im chstore)) m, i, ji m chstore j m chstorei = j dseq NODE(NODE) nexthop NODE(NODENODE) dseqm MSG(NODE) nexthopm MSG(NODENODE) nodemetric NODE(NODE) neighbourNODENODE nodemetricm MSG(NODE) intmednode NODE

Initialisation : act1: sent act2: got act3: lost act4: ALinks act5: chstore act6: dseqNODE{NODE{dsq}} act7: nexthopNODE{NODE{n0}} act8: dseqmMSG{NODE{0}} act9: nexthopmMSG{NODE{n0}} act10: nodemetriclinkvalue0 act11: neighbourneighbour0 act12: nodemetricmMSG{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

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: neighbourNODENODE. Any node has several neighbour node therefore it is declared as relation. Refines Send Send Any s,t, datamsg Where grd1 : sNODE grd3 : st grd5 : datamsg sent grd7 : target(datamsg) = t Then act1 : sent sent {datamsg} act3 : dseqm(datamsg)dseq(s) End

grd2 : grd4 : grd6 : grd8 : act2 : act4 :

tNODE datamsg MSG source(datamsg) = s sdatamsg chstore 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: sdatamsg 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 : tNODE grd3 : grd5 : grd7 : Then act1 : 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

x y ALinks target(datamsg) = t x datamsg chstore chstore (chstore {xdatamsg}) {ydatamsg}

grd2 : grd4 : grd6 : grd8 : act2 :

datamsg sent (got lost) yneighbour[{x}] x target(datamsg) ydatamsg chstore intmednode{x}

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 grd1: grd3: grd5: grd7: grd9: Then act1: 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 grd1: grd3: Then act1: End Fig6: Initiate RoutingTable2 Event
114

Where tempnodemetric NODE(NODE ) nrneighbour[{n}] n2n v=linkvalue0(n)(nr) tempnodemetric1(n)=tempnodemet ric(n)+{nrv}

tempnodemetric1 NODE(NODE grd2: ) nNODE n2NODE n2nr grd4: grd6: grd8:

tempnodemetric(n)=nodemetric(n)+ grd10 : {n0}

nodemetric(n)tempnodemetric1(n)+{n2infinite}

Where grd2: nrneighbour[{n}]

tempnexthop NODE(NODENODE) tempnexthop(n)=nexthop(n)+{nn}

nexthopnexthop+(destdestNODE destn nrdestpath(ALinks)tempnexthop(n)+{destnr})

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: nexthopnexthop+(destdestNODE destn nrdestpath(ALinks)tempnexthop(n)+{destnr }) 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 : grd3 : grd5 : grd7 : grd9 : grd11 : grd13 : Then act1 : dseq(x)dseq(x)+({kkNODE dseq(x)(k)< dseqm(datamsg)(k)}dseqm(datamsg)) nodemetric(x)nodemetric(x)+{pv} act2: nexthop(x)nexthop(x)+{py} v yNODE sNODE x yALinks x datamsg chstore grd2 : grd4 : grd6 : grd8 : grd10 : grd12 : pNODE intmednode={y} source(datamsg)= s x source(datamsg) pdom(dseqm(datamsg) dseq(x)(p)< dseqm(datamsg)(p)

k(kNODEdseq(x)(k)< dseqm(datamsg)(k))
v=(nodemetric(x)(y)+nodemetricm(datamsg)(p))

act3: 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

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. 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):307320, 2000. Abrial, J.R., J.R., Cansell, D.,Mery, D.:A Mechanically Proved and Incremental Development of IEEE 1394 Tree Identify Protocol. Formal Asp. Comput. 14(3), 215227, 2003. A Udaya Shankar and Simon S Lam: A stepwise refinement heuristic for protocol construction.ACM Transactions on Programming Languages and Systems, 14(3):417461, 1992. Karthikeyan Bhargavan, Davor Obradovic, and Carl A. Gunter: Formal verification of standards for distance vector routing protocols. J. ACM, 49(4):538576, 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 169190, 1996. Perkins Charles E., Bhagwat Pravin: Highly Dynamic Destination-Sequenced Distance-Vector Routing (DSDV) for Mobile Computers, London England UK, ACM SIGCOMM94, 1994, pp. 234244. Dominique Mery 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. 119.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.

6. 7.

8. 9. 10. 11.

12.

13.

14. 15.

116