Chapter I: Introduction

Transcription

1 -1-1. Introduction 1.1 What is a protocol? Chapter I: Introduction Aset of rules that govern the interaction of concurrent processes in a distributed system. The protocol "provides a service", and we judge the protocol based upon how successfully, and how efficiently, itprovides the service. 1.2 Examples of communications protocols 1. In a half-duplex transmission system, the procedures that the user on each end follow to determine who can use the channel next is a protocol. If the protocol that is prescribed is incorrect, both users may transmit at the same time, so that neither is successful, or both users may wait for the other to transmit, so that no data is transmitted. The service that the protocol provides controls both users, on different ends of a channel, so that they can share the channel. In an Ethernet, a protocol determines which users, in a large group of users, may transmit, and when they must retransmit, to share a single channel and successfuly transfer data.. 2. In the telephone network there is a protocol to place a phone call. The caller picks up the telephone, and waits until the network returns a dial tone. The caller then enters the telephone number of the called party. The network waits until a complete phone number is entered, then rings the phone of the called party and returns the ring or a busy signal to the called party. When the called party picks up the phone, the ringing stops and the two partys can talk. 3. In networks with transmission errors there are protocols (ARQ protocols) that determine when a message is received incorrectly, and must be retransmitted. These protocols are typically implemented by sending additional control messages between the transmitter and receiver. The control messages may also be received incorrectly or lost. A condition that was overlooked in some of the early error recovery protocols. The service provided by a protocol may guarantee that a receiver: a) Recovers all of the messages from a source. b) Discards duplicate copies of the received messages. And, c) places the received messages in the same order that they were transmitted. 4. In large networks, the routes that users select, to minimize the interference with other users, is a routing protocol, and the transmission rate that each user sends data, to prevent congestion in the network, and allow afair share of the network capacity to be used by other users is a congestion control protocol. 1.3 Example of how protocols fail Most protocol failures have occurred because of unexpected series of events. Early protocols were designed to protect railroad operations, and the failures are well documented. Clayton tunnel collision, 1841, 21 dead and 176 injured. 4devices used to allow only 1 train in the tunnel at a time - in each direction. 125

2 -2-1. Signal lights on the tracks - to indicate to other trains that a train has passed the entry point to the tunnel, 2. A signal man on each end of the tunnel 3. A buzzer to notify a signal man that the signal light should be set. If the signal fails, the signal man uses flags to stop trains from entering the tunnel. 4. An early version of a telegraph to communicate between the signal men, with three possible messages: i. A train has entered the tunnel from the signal man at the entrance to the tunnel ii. The train has left the tunnel from the signal man at the exit. iii. Query: Has the train left the tunnel? from the sgnal man at the entrance, in case he misses message ii. The signal man at the entrance resets the signal light when the tunnel is clear. Unexpected event: The signal light fails, and a second train enters the tunnel before the signal man arrives with the red flag. The second train sees the red flag and stops in the tunnel. Tw o trains in the tunnel is the unplanned event. Sequence: i. The signal man at the exit sends message ii when the first train leaves the tunnel. ii. After atime, the signal man at the entrance sends message iii He is asking if the second train has left the tunnel, but the signal man at the exit assumes that he missed the first message ii, and resends the message. iii. The signal man at the entrance assumes that the tunnel is clear and lets another train enter iv. The train in the tunnel trys to back up to the tunnel entrance and crashes with the third train. 125

3 Formal Methods When we design a protocol we must guarantee that the protocol performs the services that are needed. 1. Guaranteeing that the protocol performs the intended function is protocol verification. Some protocols have become very complex, and informally reasoning about the operation of the protocol has resulted in unexpected errors. Formal procedures have been developed to help engineers verify the correctness of protocols. 2. The specification of protocols are frequently ambibuous, particularly when the description descriptions are in English. Formal specification languages have been developed to reduce the ambiguity. 3. When we implement a protocol we must guarantee that it will operate with other other implementations of the protocol. There may be many possible sequences of operations. We must test all sequence of operations to guarantee that they have the same result. Guaranteeing that implementations result in the same protocol operations is called conformance testing. 125

4 -4-2. Outline 1. Layered Architectures Architectures for Cyber-Physical Systems 2. ARQ protocols A. Stop and Wait B. Go-back-N C. Selective Repeat ARQ D. Beeforth Protocol 3. Protocol Models A. Finite State Machinee B. Extended Finite State Machines C. Communicating Sequential processes D. Petri Nets E. Flow Chart Languages SDL F. Programming Languages 4. Protocol Verification/Validation A. Composite Finite State Machines B. Probabilitistic Verification 5. Conformance Testing IEEE Tutorial 6. Protocol Analysis 7. Broadcast/Multicast Protocols Steiner Trees 8. Read and discuss A. M. C. Yuang, "Survey of protocol verification techniques based on finite state machine models," Proc. of Computer Networking Symposium, Apr 1988, pp B. T. Elsharnouby, A. U. Shankar, "SeSFJava harness: service and assertion checking for protocol," IEEE JSAC, vol. 22, iss. 10, Dec. 2004, pp C. R. J. Linn, "Conformance evaluation methodology and protocol testing," IEEE JSAC, vol. 7, iss. 7, Sep , pp D. J. W. Palmer, K. Sabnani, "A Survey of Protocol Verification Techniques," IEEE MILCOM 1986, Oct. 5-9, 1986, pp E. F. Babich, L. Deotto, "Formal methods for specification and analysis of communication protocols," IEEE Communications Surveys & Tutorials, vol. 4, iss. 1, First Quarter 2002, pp F. D. Lee, M. Yannakakis, "Principles and methods of testing finite state machines-a survey." Proc. of the IEEE, vol. 84, iss. 8, Aug. 1996, pp

5 -5- G. R. Alur, D.L.Dill, "A Theory of Timed Automata," "Theoretical Computer Science," v. 126 pp (1994). H. R. Alur, "Timed Automata," 11th International Conference on Computer-Aided Verification, LNCS 1633, pp. 8-22, Springer-Verlag, Plan During the course of the semester we will read and discuss several papers. Iwill asign a paper 1 week before we plan on discussing it. All students will be expected to hand in a 1 page summary, before the discussion. Grades will be based on the written summaries as well as exams on the techniques that will be taught. 4. Reading Technical Papers A technical paper is not a novel, it should not be read from cover to cover in a single pass. The objective is to read the paper quickly and to obtain a better understanding of the material. The general idea is to read the paper in several passes and to decompose the paper. Technical papers, like newspaper articles, are written to convey information. Well written papers have a recursive architecture. The first section describes what will be done in the paper, and the final section sums up what has been done. In each section, the first paragraph tells what will be done in the section, and the last paragraph tells what has been done. In each paragraph, the first sentence tells what the paragraph is about. In addition, there is an abstract that summarizes the important contributions of the paper, and figures and tables that summarize the results. Instead of reading a paper from beginning to end, we should use the structure to progessively understand the paper. Weshould read the paper in three passes. 1. Find out what the paper is about and what results are reported. This is done by reading the abstract, introduction, first paragraph of each section, and the conclusion. Then looking at the figures and tables to see what results are summarized. This procedure shouldn t take more than 5-10 minutes. After completing this phase you should write down one or two sentences to describe why the paper is important. You can use this summary after you finish the paper to decide if you were right, and whether or not you spent enough time in this step. At the end of this step you should decide if you are interested in finding out more about the paper. 2. Determine how the results are obtained or how the arguments are supported. The objective is towrite down an outline of the procedures that the author uses in each section. Read the first and last paragraph of each section, then read the first sentence of each paragraph. Write down an outline of how the section supports the claims in the first paragraph. This procedure should take minutes for a typical paper. At the end of this step you should know which sections you are interested in understanding more 118

6 -6- completely. 3. Understand the details of the paper. Read the complete prose and go through the equations in the sections that are interesting. You should be able to read the prose quickly because you already know what is being said. When going through the equations you should realize that most technical papers leave out many steps in developing the equations and you will have to fill in the equations yourself or go to text books to figure out what has been done. This makes it particularly important to decide which equations are of particular interest to you, and which should be accepted without understanding how they are obtained. When you follow this procedure you should cut the amount of time to read a technical paper and have a better understanding of the importance of the paper. Writing down the objective of the paper and the outline is an important part of increasing understanding, and should not be skipped. When you follow this procedure, you will find that some technical writers are not very good at establishing the recursive structure, which will make you do more work to extract the information. Hopefully, by looking for the structure, you will become a better writer. Depending on what we want to get out of a technical paper it is not always useful to perform all three steps. The first step tells us what the paper is about. We must perform the first step in order to determine if the paper is worth looking at in greater detail. Many technical papers are incremental advances over other papers or only tangentially related to the field that we are interested in, and we can stop after this step. The second step is necessary to understand the contributions of the paper. With most papers we can stop after this step. It s only necessary to perform the third step if we want to extend the paper, or if the technique that is used will be useful to solve other problems. In most cases we will find that the techniques are straightforward and that we can accept them as being most likely correct. After all, the papers that we will be reading have been refereed and accepted for publication by a reputable journal. Home Work Due in class February 4th Perform a first level read of papers [1, 2, 3]. All of the papers are available in IEEE xplore, which is available through the Columbia library on-line. Write 1/2 to 3/4 of a page, 12 point font, for each paper. Describe what the paper is about and the most important points. Use your own words. Do not copy text from the paper. Donot include figures from the paper. Please work alone. Do not collaborate. Each paper should take minutes REFERENCES [1] R. Kianfar, B. Augusto, A. Ebadighajari, U. Hakeem, J. Nilsson, A. Raza, R. S. Tabar, N. V. Irukulapati, C. Englund, P. Falcone, S. Papanastasiou, L. Svensson, H. Wymeersch, "Design and Experimental Validation of a Cooperative Driving System in the Grand Cooperative Driving Challenge, "IEEE Transactions on Intelligent Transportation Systems, vol. 13, no. 3, pp , [2] M. Aeberhard, S. Schlichtharle, N. Kaempchen, and T. Bertram, "Track-to-Track Fusion With Asynchronous Sensors Using Information Matrix Fusion for Surround Environment Perception," IEEE Transactions on Intelligent Transportation Systems, vol. 13, no. 4, pp ,

7 -7- [3] R. Horowitz, P. Varaiya, "Control Design of an Automated Highway System," Proceedings of the IEEE, vol. 88, pp ,