data link protocols l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Data Link Protocols PowerPoint Presentation
Download Presentation
Data Link Protocols

Loading in 2 Seconds...

play fullscreen
1 / 23

Data Link Protocols - PowerPoint PPT Presentation


  • 153 Views
  • Updated on

Data Link Protocols. By Erik Reeber. Goals. Use SPIN to model-check successively more complex protocols Using the protocols in Tannenbaum’s 3 rd Edition of Computer Networks Compare this approach to using other verification tools. A Layered Packet. Physical. Data Link. Network. ….

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

Data Link Protocols


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
    Presentation Transcript
    1. Data Link Protocols By Erik Reeber

    2. Goals • Use SPIN to model-check successively more complex protocols • Using the protocols in Tannenbaum’s 3rd Edition of Computer Networks • Compare this approach to using other verification tools

    3. A Layered Packet Physical Data Link Network … User Data Background • Processes communicate using layers • Each layer provides services to higher-level layers and ultimately to the user

    4. Data Link Layer • Sits between the physical and network layers • For our purposes: provides non-lossy, error-free, and ordered communication for the network layer • The physical layer will provide error-free communication, but packets may get lost.

    5. Specification • Safety: [] ! Bad_network_packet • Liveness: [] (network_message_sent -> <> network_message_received) • A packet is “bad” if it is not the packet expected

    6. Problems with the Spec • Ideally, requires an infinite queue to check • Ideally, any packet can be sent. This can be implemented in SPIN with: packet new_packet; do :: (i < PKT_SIZE) -> if :: true-> new_packet.p[i]++ :: true-> skip fi :: else -> break od

    7. Simplifications • Use a finite queue, that loops around • Use a packet size of 1, and pick between 0 and 1. 0,4,8 12,… 1 2 3 packet new_packet; if :: true-> new_packet.p[0]=0 :: true-> new_packet.p[0]=1 fi

    8. Why OK? • Finite-queue of k elements: not always ok (consider k=2, and drop 2). We must prove: [] ((network_sent – network_received) < k). • Packet size 1: ok, since the physical layer can only lose packets. Any packet loss or reordering can be detected with just 1 bit.

    9. Protocol 1 • Assumes no packets are lost by the physical layer • Assumes receiver infinitely fast sender() { packet buffer; frame s; do :: true -> A_from_network?to_sender(buffer); s.info.p=buffer.p; A_to_physical!to_physical(s) } receiver() { packet pack; frame r,s; do :: true -> B_wait_for_event?to_receiver(); B_from_physical_layer?to_receiver(r); pack.info.p = r.info.p; B_to_network!to_network(pack) }

    10. Notes on Protocol 1 • I use separate processes for the network, physical, and data-link processes (6 processes already!) • Wire is multiple channel, all other communication is done with 0 width (synchronous) channels. • Need to add a constraint to both properties: [] (num_packets_in_DLR < 2) • With the constraint, both properties went through SPIN 

    11. Protocol 2 • No longer assume infinite speed receiver • Instead, receiver sends ack back to sender B A frame ack

    12. Notes on Protocol 2 • Up to 8 processes! • Model-checker getting slow (liveness proof went 252,700 states deep) • Never more than one message being dealt with at a time • Both checks went through 

    13. Protocol 2_5 • Tannenbaum mentions a simple extension to protocol 2 to make it handle dropped messages. Just set a timer on the sender, if the timer buzzes resend. • Why doesn’t that work? • Safety proofs goes through if add the condition that the ack is never dropped 

    14. Protocol 3 • Truly handle lost messages • Add a one bit sequence number to the message and the ack. Also timeout as in 2_5. • But how does one implement a timer in SPIN…

    15. Timer Implementations • Use the timeout keyword: • Had problems with the timeout keyword sticking • Use the scheduler: timer() { do :: timeout -> A_wait_for_event!to_sender(time_out) od } timer() { do :: true -> A_wait_for_event!to_sender(time_out) od }

    16. More timer implementations • Use non-determinism: timer() { do :: true -> do :: true -> skip :: true -> break od; A_wait_for_event!to_sender(time_out) od }

    17. Notes on protocol 3 • Proved liveness with the scheduler’s timer and safety under the timeout keyword. • Looking for the right timer implementation • Made a pretty and an ugly version of protocol 3. The ugly version gets rid of the physical senders

    18. Protocol 4 • Bidirectional • 1-bit windowing protocol (only 1 bit ack) • More efficient && symmetric • Original implementation has 12 processes: my ugly version weans this down to 6 – and still does not make it through.

    19. Notes on Protocol 4 • I tried using various forms of compression, but never got a full search  • On the other hand, between my 5 implementations of protocol 4, SPIN caught a lot of errors.

    20. 3 More Protocols? • There are three more data link protocols in Tannenbaum’s book. First n-bit windowing, then 1-bit sliding window, and finally the n-bit sliding window protocol • Since Protocol 4 did not go through, …

    21. Spin v. ACL2 • ACL2 proof would work at a lower level: • + ACL2 can handle more states • - if the user can do the proof • + SPIN has a better simulator: it’s tough to simulate this type of ACL2 code. (defun next_system_state (i system_state) (cond ((== i 0) (execute_A system_state)) (t (execute_B system_state)))) ... (thm (and (not (get-val ‘bad_network_packet (init_state))) (implies (not (get-val ‘bad_network_packet s)) (not (get-val ‘bad_network_packet (next_system_state i s))))

    22. Conclusions • Model-checking complex protocols is hard • SPIN is very good at helping users find bugs. The interactive simulator is useful. • Try combining SPIN with theorem proving

    23. Future Work • Simplify the spec: Is there something simpler that will still distinguish ordering? • Simplify the model: 6 processes are not really necessary. • Implement a better timer • Prove the network protocols in ACL2 or PVS for comparison