1 / 23

Data Link Protocols

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. ….

yank
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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

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

More Related