Model-based Prototyping of an Interoperability Protocol for Mobile Ad-hoc Networks

Transcription

1 Model-based Prototyping of an Interoperability Protocol for Mobile Ad-hoc s L.M. Kristensen, M. Westergaard, and P.C. Nørgaard 2 Department of Computer Science, University of Aarhus, Denmark 2Ericsson Danmark A/S, Telebit, Denmark

2 Motivation Validate Domain expert Core Core `("3ffe:00:3:40::3","3ffe:00:3:4 05::","3ffe:00:3:405::") `(ROUTING,{src="3ffe:00:3:40::2 ",dest="3ffe:00:3:40::",cont=dns _REQ("AHN(3)")}) Core `("3ffe:00:3:40::4","3ffe:00:3:4 06::","3ffe:00:3:406::") Gateway Gateway Config Gateway Gateway2 Config2 AdHoc Formal model `(RECEIVE("AHN(4)"),{src="3ffe:00 :3:405::",dest="all-nodes multicast",cont=gw_adv(("3ffe:00:3:40::"," 3ffe:00:3:405::"))})++ 3`(FLOODING("3ffe:00:3:405::"),{ src="3ffe:00:3:405::",dest="all-no des multicast",cont=gw_adv(("3ffe: 00:3:40::","3ffe:00:3:405::"))}) 4 AdHoc AdHoc FM expert Modeling Figure 2 shows the approach taken to use CPN models to develop a prototype of the interoperability protocol. A CPN model (lower left of Fig. 2) has been developed by modelling the natural language protocol specification [22] (lower right) of the interoperability protocol. The modelling activity transforms the natural language specification into a formal executable specification represented by the CPN model. The CPN model captures the network architecture depicted in Fig. and the protocol mechanisms of the interoperability protocol, e.g., the periodic transmission of advertisements, the dynamic updates of the DNS database, and traffic flows between hosts in the core network and nodes in the ad-hoc network. The Specification

3 Methodology Explore and interact Core Core `("3ffe:00:3:40::3","3ffe:00:3:4 05::","3ffe:00:3:405::") `(ROUTING,{src="3ffe:00:3:40::2 ",dest="3ffe:00:3:40::",cont=dns _REQ("AHN(3)")}) Core `("3ffe:00:3:40::4","3ffe:00:3:4 06::","3ffe:00:3:406::") Gateway Gateway Animation Config Gateway Gateway2 Config2 AdHoc Formal model `(RECEIVE("AHN(4)"),{src="3ffe:00 :3:405::",dest="all-nodes multicast",cont=gw_adv(("3ffe:00:3:40::"," 3ffe:00:3:405::"))})++ 3`(FLOODING("3ffe:00:3:405::"),{ src="3ffe:00:3:405::",dest="all-no des multicast",cont=gw_adv(("3ffe: 00:3:40::","3ffe:00:3:405::"))}) 4 AdHoc AdHoc FM expert Modeling Domain expert Figure 2 shows the approach taken to use CPN models to develop a prototype of the interoperability protocol. A CPN model (lower left of Fig. 2) has been developed by modelling the natural language protocol specification [22] (lower right) of the interoperability protocol. The modelling activity transforms the natural language specification into a formal executable specification represented by the CPN model. The CPN model captures the network architecture depicted in Fig. and the protocol mechanisms of the interoperability protocol, e.g., the periodic transmission of advertisements, the dynamic updates of the DNS database, and traffic flows between hosts in the core network and nodes in the ad-hoc network. The Specification

4 Overview The project A solution: dynamic DNS and renumbering A formal model prototype Visualizing the formal model prototype Lessons learned

5 The Project Gateways A B C MN MN MN MN MN MN Core network Ad-hoc network Possible solutions Mobile IP Mobile host routes injected by gateways into the core network Dynamic DNS and renumbering

6 Scenario

7 Router Advertisements

8 Mobility & DNS Update

9 Mobility & DNS Update

10 Coloured Petri Nets Bi-partite directed labeled graph (places and transitions) Places can contain tokens (e.g 2, token, or ) Transitions can occur, thereby moving tokens from input-places to output-places

11 Coloured Petri Nets Example Transition Tokens which can occur ipadr `"3ffe:00:3:40::" DNSAdr IPAdr `("AHN(3)","3ffe:00:3:405::3")++ `("AHN(4)","3ffe:00:3:405::4")++ `("AHN(5)","3ffe:00:3:406::5") PlacesTransitions ipadr DNSRequest (symname,resipadr) 3 DNS Database SymNamexIPAdr (ROUTING, (RECEIVE ipadr, {src = ipadr, {src = srcipadr, dest = srcipadr, dest = ipadr, cont = DNS_REP (symname,resipadr)}) cont = DNS_REQ symname}) (symname,newipadr) DNSUpdate (symname,resipadr) (RECEIVE ipadr, {src = newipadr, dest = ipadr, cont = DNS_UPD (symname,newipadr)}) I/O Core `(ROUTING,{src="3ffe:00:3:40:: `(RECEIVE("3ffe:00:3:40::"),{src CmdxPacket ",dest="3ffe:00:3:40::2",cont=dns ="3ffe:00:3:40::2",dest="3ffe:00: _REP(("AHN(3)","3ffe:00:3:405::3")) 3:40::",cont=DNS_REQ("AHN(3)")}) })

12 Model `("3ffe:00:3:40::3","3ffe:00:3:4 05::","3ffe:00:3:405::") `(ROUTING,{src="3ffe:00:3:40::2 ",dest="3ffe:00:3:40::",cont=dns _REQ("AHN(3)")}) Gateway Config Gateway `(RECEIVE("AHN(4)"),{src="3ffe:00 :3:405::",dest="all-nodes multicast",cont=gw_adv(("3ffe:00:3:40::"," 3ffe:00:3:405::"))})++ 3`(FLOODING("3ffe:00:3:405::"),{ src="3ffe:00:3:405::",dest="all-no des multicast",cont=gw_adv(("3ffe: 00:3:40::","3ffe:00:3:405::"))}) 4 Core Core AdHoc AdHoc Core Gateway Gateway2 AdHoc `("3ffe:00:3:40::4","3ffe:00:3:4 06::","3ffe:00:3:406::") Config2

13 Tying the Model to the Animation input (srcipadr, nhipadr, content); output (); We are able to annotate transitions with codesegments, which are executed whenever the action show_flow(srcipadr, nhipadr, content) transition occurs I/O `(ROUTING,{src="3ffe:00:3:40:: ",dest="3ffe:00:3:40::2",cont=dns _REP(("AHN(3)","3ffe:00:3:405::3")) }) Core CmdxPacket input (srcipadr, nhipadr, content); output (); action (ROUTING, { src = srcipadr, show_flow(srcipadr, nhipadr, content) dest = destipadr, cont = content}) routinginformation Route (RECEIVE nhipadr, [nhipadr = FindNextHop routinginformation destipadr] {src = srcipadr,dest=destipadr,cont=content}) `[("3ffe:00:3:405::","3ffe:00:3:40 ::3"),("3ffe:00:3:406::","3ffe:00:3 :40::4")] RoutingInformation RoutingInformation

14 Advantages of Model-based Prototypes Easier to control and reproduce scenarios Implementation details can be abstracted away Setup of physical network equipment is not required Larger scenarios can be investigated

15 Advantages of Integration of Formal Models with Informal Animation Behavior is as defined by the formal model Knowledge of the formal modeling language is not required Presentation for military leaders is possible Validation that the implemented prototype corresponds to the specification

16 Future Work Enhancements of the modeling language to automatically trigger events in the visualization Synchronous events: the current presentation is quite verbose Asynchronous events: not really possible - in this project we use polling, which clutters the formal model

17 Sending Data

18 Sending Data and Mobility