Formal Verification of AODV Protocol using cadence SMV - PowerPoint PPT Presentation

1 / 30
About This Presentation
Title:

Formal Verification of AODV Protocol using cadence SMV

Description:

'Continuous', which means that the behavior of avatar X at time t 1 can be ... When an avatar position (ADU) is missing at the time we compute a bucket, simply ... – PowerPoint PPT presentation

Number of Views:184
Avg rating:3.0/5.0
Slides: 31
Provided by: xin2
Category:

less

Transcript and Presenter's Notes

Title: 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!
Write a Comment
User Comments (0)
About PowerShow.com