Formal Verification of AODV Protocol using cadence SMV

1
Formal Verification of AODV Protocolusing
cadence SMV
(CPSC513 Course Project)

• Jun Wang and Xin Liu
• jwang_at_cs.ubc.ca, liu_at_cs.ubc.ca
• 
  

2
Outline

• Motivation
• AODV Introduction
• cadence SMV Introduction
• Building Model
• Conclusion

3
Motivation

• Find an appropriate approach to use cadence SMV
  verifying real-life software communication
  protocols, such as AODV. The emphasis is how to
  build the model.
• Find some bugs in current AODV protocol
  (RFC3561)? Hope we can

4
AODV Introduction

• Background
• A mobile ad hoc network is a collection of nodes
  which communicate over wireless channels. ad
  hoc means that the nodes are free to move
  randomly.
• need routing protocol
• Proactive table driven
• Reactive on demand
• AODV (Ad hoc On-demand Distance Vector) Protocol
• a reactive routing protocol for ad hoc mobile
  networks.
• 3 control messages RREQ, RREP, REER
• Sequence number
• Important property Loop free

5
cadence SMV Introduction

• Find an appropriate approach to use cadence SMV
  verifying real-life software communication
  protocol, such as AODV. The emphasis is how to
  build the model.
• Find some bugs in current AODV protocol
  (RFC3561)? Hope we can

6
Distributed Architecture

• Distributed vs. Centralized
• Distributed
• Robustness failure of any participant has no
  effect on other participants.
• Scalability while in centralized architecture,
  server is the bottleneck.
• Minimum delay information crosses the network
  only once to reach its final destination, while
  in centralized architecture, information reaches
  its destination through the server.
• Centralized
• Consistency Global consistency is guaranteed.
• Cheating difficult the presence of server makes
  cheating difficult.
• Easily charge allow game companies to easily
  charge players.

7
Distributed Architecture (cont.)

• MiMaze Architecture

Note the game server is only used when a new
entity joins a session, to learn the session
group and to download the game.
8
Distributed Architecture (cont.)

• Fully distributed, Serverless architecture.
• Based on RTP/UDP/IP multicast.
• Only one multicast group in MiMaze.
• Game server is only used when new participant
  joining the game session.
• Once the game has started, participants exchange
  their own states (including position, direction,
  speed,) to compute the game state.
• In MiMaze, no central entity (or server) exists
  to compute the game state, each participant
  computes its own view of the game state (may be
  inconsistent).

9
Bucket Synchronization Mechanism

• Distributed synchronization
• All ADUs issued at the same time are computed
  together to evaluate the state of the game.
• All the session entities display the same game
  state simultaneously.
• MiMaze bucket synchromization
• Time is divided into fixed length periods and a
  bucket is associated with each period.
• All ADUs received by a player are stored in the
  bucket corresponding to the time interval in
  which senders issue the ADUs.
• At the end of every bucket interval, all ADUs in
  that bucket are used by the entity to compute its
  local view of the global game state.
• Bucket will be computed 100ms after the end of
  the sampling period during which ADUs have been
  issued, which is the playout delay.

10
Bucket Synchronization Mechanism

• Bucket frequency
• The bucket frequency defines the rate at which a
  new game state is computed and displayed.
• In MiMaze, the bucket frequency is 25 buckets per
  second.
• The ADU transmission frequency is equal to the
  bucket frequency, thus, there should be one new
  ADU per entity at the time a bucket is processed.

11
Bucket Synchronization Mechanism

• Example

12
Bucket Synchronization Mechanism

• Global clock mechanism
• The bucket synchronization mechanism uses NTP to
  evaluate the delay between participating
  entities.
• If NTP is not available, use a NTP-like algorithm
  based on the evaluation of the round trip time.
• There are 3 levels (strata) of NTP servers and it
  is very difficult to maintain good
  synchronization when level 3 servers are
  involved.
• In order to increase the precision of NTP under
  stratum 2 and 3, use both NTP and NTP-like
  algorithm.

13
Dead reckoning

• What is dead reckoning?
• Dead reckoning is an extrapolation techniques
  used in the aviation systems to compute an
  estimate of the current position of a plane based
  on the knowledge of its position in the past and
  on its trajectory.
• An important property of game objects behavior
• Continuous, which means that the behavior of
  avatar X at time t1 can be extrapolated from its
  behavior at time t with high possibility.

14
Dead reckoning (cont.)

• Why need dead reckoning?
• To deliver a complete view of the game, the
  bucket algorithm requires at least one ADU per
  participant to be available in each bucket.
  However, a ADU can be missing or late (received
  after 100ms).
• MiMaze uses the simplest dead reckoning algorithm
• When an avatar position (ADU) is missing at the
  time we compute a bucket, simply replay the last
  known position of this avatar.
• The late ADUs are still stored in their
  destination bucket, since they are useful to
  replace a missing ADU when computing future
  buckets.

15
Dead reckoning (cont.)

• Error Control
• replace lost ADUs.
• Synchronization
• extrapolate late ADUs.
• Trajectory smoothing
• interpolation between received states when sender
  frequency is lower than display frequency.
• Anticipating collisions
• dead reckoning can be used by the sending
  entities to anticipate potential future
  collisions.
• Congestion control
• adapt ADU transmission frequency according to
  network load.

16
Performance evaluation

• Experimental environment
• The evaluation of MiMaze is performed on the
  MBone with up to 25 players located in various
  places in France.
• The number of participants are varied in order to
  vary the loss rate.
• The architecture of the experimental multicast
  tree

17
Performance evaluation (cont.)

• Monitoring
• During the experiment, participants play
  MiMaze and collect traces which is composed of
• Network level data for each received ADU,
  collect the senders identity, the transmission
  and reception time-stamp, etc.
• Application level data information contained in
  all ADUs sent and received is time-stamped and
  collected in the trace file, which is used to
  reconstruct the state of game computed by each
  participant.
• Synchronization data network delays and clock
  offsets with respect to each participant are
  collected. These data is used to resynchronize
  the traces.

18
Performance evaluation (cont.)

• Resynchronize traces
• (main difficulty in analysis)
• Since the system is distributed, there is no
  absolute clock in a game session, each
  participant timestamps its local traces.
• Global clock mechanism is imperfect, use an
  algorithm based on least-squares to resynchronize
  traces.
• Omit time intervals where relative clock
  information is not interpretable.

19
Performance evaluation (cont.)

• Distributed game metrics
• Need a meaningful performance metric to analyze
  distributed multiplayer games.
• This metric should reflect how far the
  distributed game behavior is from the perfect
  behavior if without the network delay and lost.
• Use drift distance. The drift distance
  represents the distance units between the real
  position of an avatar in local entity, and the
  position of the same avatar computed by a remote
  entity.
• The game is consistent if the drift distance is
  zero, however, a small drift does not means that
  the game is inconsistent.

20
Performance evaluation (cont.)

• In order to keep figures clear, the paper present
  performance observed between only two
  participants (droopy and hugo).
• Delay distribution (between hosts hugo and
  droopy)

21
Performance evaluation (cont.)

• Distribution of late ADUs

• Percentage of late ADUs

Note between hosts hugo and droopy.
Note between hosts hugo and droopy.
22
Performance evaluation (cont.)

• Percentage of lost ADUs

• Distribution of lost ADUs

Note between hosts hugo and droopy.
Note between hosts hugo and droopy.
23
Performance evaluation (cont.)

• Drift distance

• Distribution of drift distance

Note between hosts hugo and droopy.
Note between hosts hugo and droopy.
24
Performance evaluation (cont.)

• Consistency improvement (gain) with distributed
  synchronization

Note a value 1 on the vertical axis corresponds
to no gain and 2 corresponds to a 100 gain.
25
Summary

• MiMaze is implemented on a completely distributed
  communication architecture based on the IP
  multicast protocol suit (RTP/UDP/IP multicast).
• MiMaze use a simple distributed synchronization
  mechanism - the bucket mechanism to provide an
  acceptable level of game state consistency.
• MiMaze shows that real-time interactive can be
  maintained in the fully distributed applications,
  provided that some level of inconsistency can be
  tolerated by the applications.

26
Discuss

• Main Contribution
• This work shows that with a multicast
  communication architecture and with a simple
  synchronization mechanism (the bucket mechanism),
  a fully distributed interactive application can
  provide an acceptable level of consistency.
• It also identified the problem of defining a
  proper metric for the evaluation of the
  application consistency.
• This work is a proof of feasibility of
  distributed multiplayer architectures on
  heterogeneous best-effort networks (Internet).

27
Discuss (cont.)

• Related Work
• Amaze
• can be considered as MiMazes ancestor. It
  is played on a LAN, using point-to-point
  communication. Amaze transmits the game state on
  the network, and maintains replicated copies of
  the game state.
• Spline
• a virtual distributed interactive world. It
  has a distributed architecture based on the DIS
  standard. Most of the efforts has been done on
  local flow synchronization mechanism.
• PARADISE
• aims to architect and build a large-scale
  internet worked simulation environment that
  supports multiplayer interactive applications. It
  aims primarily at aggregation and specific dead
  reckoning algorithms.

28
Discuss (cont.)

• Future Work
• Extensions of MiMaze (has done)
• Using Synchronized 3D Virtual Reality Modeling
  Language (VRML) to get a 3D game.
• Mapping MPEG video on the maze wall.
• Supports 3D spatial audio.
• Congestion control
• Avatar collision detection and anticipation
• Session management in subgroups of participants.

29
References

• MiMaze http//www-sop.inria.fr/rodeo/MiMaze/
• Design and Evaluation of MiMaze, a Multi-player
  Game on the Internet, Laurent Gautier, Christophe
  Diot, IEEE Multimedia Systems Conference, Austin,
  June 28 - July 1, 1998.
• Distributed Synchronization for Multiplayer
  Interactive Applications on the Internet, Laurent
  Gautier, Christophe Diot, IEEE ICNP Conference,
  Austin, October 1998.
• MiMaze, a 3D Multi-Player Game on the Internet ,
  Emmanuel Lety, Laurent Gautier, Christophe Diot,
  In the Proceedings of the 4th International
  Conference on Virtual System and MultiMedia, Nov
  98, Gifu, Japan.
• IEEE Standard for Distributed Interactive
  Simulation -- Application Protocols (IEEE Std
  1278.1-1995). IEEE Computer Society. 1995.
• S. Deering. "Host Extensions for IP
  Multicasting". RFC 1112. 17. August 1989.

30
A Distributed Architecture for Multiplayer
Interactive Applications on the Internet

• 
  Thanks!