degree in computer science in 1978, all from the. University of California, Los Angeles. Following a year as a Post-Doctoral Fellow at the Weizmann Institute of ...
630
3
[7] A. Hopkins, T. B. Smith, and J. Lala, "FTMP-A highly reliable fault-tolerant multiprocessor for aircraft," Proc. IEEE, vol. 66, pp. 1221-1239, Oct. 1978. [8] R. Shostak, R. Schwartz, and P. M. Melliar-Smith, "STP: A mechanized logic for specification and verification," SRI Int., Dec. 1981. [9] R. Shostak, "Deciding combinations of theories," Menlo Park, CA, CSL-130, SRI Int., Menlo Park, CA, CSL-131, Dec. 1981. 110] L. Lamport and P. M. Melliar-Smith, "Synchronizing clocks in the presence of faults," SRI Int., Menlo Park, CA, Feb. 1982. 11] S. Igarashi, R. London, and D. Luckham, "Automatic program verification 1: A logical basis and its implementation," Acta Informatica, vol. 4, pp.45-182, 1975.
IEEE TRANSACTIONS ON COMPUTERS, VOL. c-31, NO. 7, JULY 1982
a1_ I120
Richard L. Schwartz received the B.S. degree in mathematics/computer science in 1976, the M.S. degree in computer science in 1976, and the Ph.D. degree in computer science in 1978, all from the University of California, Los Angeles. Following a year as a Post-Doctoral Fellow at the Weizmann Institute of Science in Israel, he joined the Computer Science Laboratory at SRI International, Menlo Park, CA, in 1979. His research interests include formal semantics of programming languages and systems, program specification and verification, and programming language design. Dr. Schwartz was a recipient of an IBM Doctoral Fellowship. He is a member of the Editorial Advisory Board of the Journal of Computer Lan-
guages.
P. Michael Melliar-Smith received the B.A. degree in natural sciences from Cambridge University, Cambridge, England, in 1964. Presently, he is a Senior Computer Scientist at the Computer Science Laboratory, SRI International, Menlo Park,' CA. From 1964 to 1973 he was with GEC Computers. He was also a Senior Research Associate at Newcastle University, Newcastle, England from 1973 to 1976. His major interests concern formal specification and verification and reliable distributed systems.
A Validation Technique for Tightly Coupled Protocols HARRY RUDIN,
SENIOR MEMBER, IEEE, AND
COLIN H. WEST,
MEMBER, IEEE
Abstract-For several years the authors have been part of an effort protocols used for this information exchange have two properties: first, the protocols must themselves be fault-free, and second, the protocols must recover from transmission er-
developing automated techniques for examining the syntax of protocols for the absence of various errors. Recently, we have turned our attention to trying to prove various functional properties of protocols used in ring-topology systems. Ring systems have a number of properties that distinguish them from the more general computer networks towards which our earlier validation work was directed. We report here on the resulting changes in the protocol models and validation techniques, together with extensions used to prove that the protocol being examined has the various desirable functional properties demanded of it. Index Terms-Computer networks, local area networks, multiac-
cess, protocols, ring, validation, verification.
I. INTRODUCTION
A PROTOCOL is the set of rules specifying how cooperating processes exchange data and control information. Reliable computer-communication systems require that the Manuscript received October 6, 1981; revised JalmaTy 12, 1982. The authors are with IBM Zurich Research Laboratory, 8803 Ruschlikon, Switzerland.
rors. A number of protocol validation systems, which help to ensure fault-free protocols, has been developed at the IBM Zurich Research Laboratory [1]- [4]. These validation systems depict the processes involved as being finite-state machines that send and receive messages among themselves. The finite-state machines are connected by communications channels implicitly represented by queues capable of storing messages in transit. This model has proven to be very powerful for the loosely coupled protocols we have been examining such as X.21 and X.25 [5], [6], SNA [7], and a simple data-link control protocol [8]. There are other approaches to validation; Hajek [9] has described the results obtained from an alternative validation system. The most recent overview and bibliography of the various approaches is in a paper by Bochmann and Sunshine [101]. Sunshine [11] has just published a large collection of papers dealing with protocol specification and validation.
0018-9340/82/0700-0630$00.75
©) 1982 IEEE
631
RUDIN AND WEST: VALIDATION FOR TIGHTLY COUPLED PROTOCOLS MONITOR
TERMINAL
TERMINAL
TERMINAL
TERMINAL
TERMINAL
Fig. 1. A ring communication system.
Fig. 3. Implication of the asynchronous model for the ring.
PROCESS N
capability or the system identifies a "reception error." The significance of this type of error is that the system has reached a state for which the protocol designer has made no provision. If process N has the capability to transmit a message in its current state, this is indicated with a "-" sign as in -OUT in Fig. 2. The destination process must also be specified for each transmission. An important property of the process model is the decoupling of input and output. This enables the modeling of local actions resulting from the reception of a message or initiation of the sending of a message, without specifying the nature of the local actions themselves. The validation of the message exchanges through the communication medium is thus independent of the nature of the local actions, which may involve communication with processes not modeled direct in the system. We shall see that the resulting time delay between the reception of a message and the sending of a subsequent message is inappropriate in a ring system. Our particular validation procedure [2] constructs a directed global graph for the entire system based on the individual process descriptions. The nodes represent global states of each of the individual process states and contents of each of the process-connecting queues. (These queues may hold an arbitrary number of messages-corresponding to the communication medium-but for a ring system, the maximum number of messages would be set to one.) The arcs represent transitions between these global states. The validation procedure consists of first generating this global-state graph and then examining it for various syntactic errors such as the reception error mentioned above, unexercised arcs (corresponding to "dead code"), and deadlocks. Liveness, tempo-blocking [9], etc., are also properties that can be derived from the global-state graph, although considerably more computational resources are required. The approach has proven to be a very powerful technique as indicated in the list of successful applications given above. The implications of this model applied to the ring communication system shown in Fig. 1, are shown in Fig. 3. The point of Fig. 3 is to indicate that the coupling of communicating processes by message queues in the model is inappropriate to a ring system because of the ring's synchronous nature. The delay between the reception of a message by a process and its retransmission to the next process on the ring is fixed. Furthermore, the transit time between any pair of processes in a ring is fixed, and is determined by the number of intermediate
OUTPUT
INPUT 1l l BUFFER
/
(S)
F
Fig.
BUFFER
(S)
. 2.
The
asynchronous model.
Recently, we have turned our attention to more tightly coupled, more synchronous protocols such as those involved in ring-topology systems. (See Fig. 1.) Here we have found that our existing protocol validation tools were not ideal. We believe that we have found a better basis for the validation of synchronous protocols. These new techniques are described here, starting in Section III. First, however, our earlier approach is described in Section II; a comparison of the two methods for a primitive ring system is made in Section IV. In Section V, a means of representing time is presented, Section VI deals with modeling transmission errors, and Section VII, with the demonstration of various functional properties. The Appendix includes a simplified token-ring protocol and its validation as an example. II.
THE PREVIOUS APPROACH
In the previous approach, finite-state-machine-like directed graphs are used to define the protocol as shown in the example of Fig. 2. In some current state, process N removes messages from its input buffer(s) as indicated by the arc labeled +IN. The symbol "+" is used to indicate reception [3]. If it is possible for a message to be in any one of the processes' input buffers, the current state must have the appropriate reception
IEEE TRANSACTIONS ON COMPUTERS, VOL.
632
PROCESS N
C-31, NO. 7,
JULY 1982
IDLE'|
FREE FRAME:
FREE IDLE
DATA FRAME:
BUSY ADDR'DATA
Fig. 6. Frames for a ring communication system.
RiN RING IN
RING
OUT
Fig. 4. The synchronous model. Note: If the current state is a "repeating" state and there is no reception arc matching the incoming message, the incoming message is automatically repeated, i.e., left unchanged. (© 1982 by North-Holland, Amsterdam, The Netherlands. Reprinted by permission [14, Fig. 4].)
An important function of a process communicating in a ring system is its ability to simply repeat or pass on to the next process in the ring any message not destined for it. Rather than include specific state transitions for all messages that need repeating in this way, we have included in the process representation a "repeating" attribute that can be defined for individual process states. If the current state is labeled as a 4"repeating" state and the message in the buffer is not matched by an appropriately labeled arc departing from the current process state, the INCOMING MESSAGE is passed on to the succeeding process UNCHANGED at the next clock interval. Thus, without specification of arcs, each state labeled "repeating" automatically performs a repeating function. The sequence is then that each process reacts to the message currently in its buffer by appropriately replacing it if the formal description so specifies, or leaving it unchanged otherwise. The messages are then rotated to the succeeding process, synchronously, and the process is repeated. Clearly, this leads to a very economic representation of the "repeater" function which lies at the heart of the operation of ring communication systems. IV. COMPARISON OF MODELS APPLIED TO A SIMPLE RING
Fig. 5. Implication of the synchronous model for the ring. (© 1982 by North-Holland, Amsterdam, The Netherlands. Reprinted by permission [14, Fig. 3].) processes as
the transit time between neighbor processes is also
constant. The asynchronous model does not lend itself to an accurate representation of these properties. The separation of input and output in the individual processes, and the unspe-
cified transit time of a message between processes means that of the states explored by a validation based on the asynchronous model are not accessible when a synchronous ring system is executed.
many
III.
MODELING SYNCHRONOUS PROCESSES
Fig. 4 indicates the new approach. Here a single buffer with single message capacity is associated with each process. Arcs leading from state to state indicate that reception of a particular message, +IN in Fig. 4, from the preceding process leads to a particular next state and generation of an output message, -OUT in Fig. 4, to the succeeding process. Normally, receptions and transmissions must be explicitly specified as in Fig. 4. The implication of this synchronous model for the ring communication system of Fig. 1 is shown in Fig. 5. Note that all buffers have single message capacity and that a synchronous, clocked rotation of the messages is enforced.
Fig. 6 shows possible frame structures for a hypothetical primitive "token"-ring communication system of the type shown in Fig. 1. The "free frame" circulating on the ring consists of a free character followed by two idle characters. Upon receiving such a frame, a transmitting terminal may convert the free character to busy, the first idle character to an address, and the second idle to data-all as shown in the "data frame." Such a system represents a gross simplification of practical ring systems such as, for example, the "Cambridge Ring" [ 12]. It is instructive to compare the asynchronous and synchronous models for this primitive ring communication system. We shall look only at two aspects: transmission of a character by an originating terminal and the repeating of frames on the ring. Fig. 7 shows the asynchronous model. Starting from the initial -state SO, the various radially aligned loops model repetition of the various incoming frame components. Each loop goes through an intermediate state (R 1 through R4) because of the inherent asynchronism of the model. After reception of a free character, this may either be repeated or converted to a busy, followed by reception of an idle and its conversion to an address, followed by reception of another idle and its conversion to a data character. Reception of a frame by the destination terminal is not shown. Fig. 8 illustrates the same terminal but using the synchronous model. Again starting at state SO, marked as a repeating state, the repeating of incoming characters is implicitly modeled with the exception of the free character, repeating of
633
RUDIN AND WEST: VALIDATION FOR TIGHTLY COUPLED PROTOCOLS
"REPEATING" STATE
S0
S
4 I-
a,~°
S
Fig. 8. Synchronous transmitting terminal model. Note: For "repeating" state SO, incoming messages without a matching reception arc are automatically repeated, i.e., left unchanged. Fig. 7. Asynchronous transmitting terminal model.
can be used to count instances of the timing character; the count could be reset when a free or busy character appears. The observation of some number of timing characters, without the appearance of a free or busy character can be used to represent a time-out whose purpose is to initiate some remedial action if there is no token (free or busy) within the specified pe-
which is explicitly indicated because here there are two possibilities following reception: repetition, or conversion to the busy character as indicated by the arc leading to state S 1. Conversion of the first idle character to the address and the riod. All the other processes on the ring ignore the time character, second idle to data is indicated by successive arcs leading back i.e., they simply repeat the time character without changing to the initial state SO. In comparing the representation of Figs. 7 and 8, it is clear state. This technique has been successfully used in the valithat the synchronous representation is much more compact. dation of a token-ring protocol being implemented at the IBM The computer time required for validating a synchronous Zurich Research Laboratory [14]. system described using the synchronous model is substantially VI. MODELING ERROR CONDITIONS less for the following reason. In a synchronous, tightly coupled system of protocols, each process must respond in the next An important aspect of the ring protocols we have been clock cycle (albeit with possibly an empty message). Thus, the validating is their recovery after errors have occurred on the degree of freedom inherent in the asynchronous protocol ring. For example, in token-based protocols, a circulating free simply does not exist in the synchronous case. The new de- token is marked busy by a process wishing to transmit, and scription is economic because it generates fewer global states marked free again when transmission of a message is comcompared with the asynchronous approach. The reduction in pleted. Obviously, any corruption of a free or busy token is an the number of global states leads to a more efficient validation. error condition from which the protocol must be able to re(In this connection, it should be stated that improvement in cover. A method we have used in the past to model errors of the speed of the asynchronous, "perturbation" approach [2] this type is to introduce an additional process (or demon) that has recently been made through the use of "canonical se- can corrupt messages into the communication system. In the quences" [13].) present example, a demon could be used that has the ability to simply change any busy token to a free token and vice V. A REPRESENTATION FOR TIME AND TIMEOUTS versa. The desire to analyze recovery of a protocol from such error In the asynchronous model, it was not possible to model timeouts of a specific duration, but only those of unspecified length conditions makes this simple approach inapplicable, as valiby defining process state transitions not associated with the dation will exercise sequences where any number of tokens in sending or reception of an observable message. The cyclic succession is corrupted. Proof of recovery in such sequences nature of a ring enables a better modeling of timeouts by in- cannot be demonstrated, as no recovery is possible. This is troducing additional processes in the ring that have the ability analogous to the General's problem [15]. The solution is to use to introduce and remove circulating messages. By specifying a demon that can corrupt a message at any time, but will do the number of cycles around the ring between insertion and so only a predetermined number of times during the operation removal, it is possible to simulate a delay of a corresponding of the protocol. Validation then generates global-state graphs containing duration. An example will serve to illustrate the methodall numbers of errors up to a maximum predefined number ology. The sample frames shown in Fig. 6 imply that there are from which recovery properties of the protocol in the approthree processes on the ring (one slot per process). A fourth slot priate circumstances can be analyzed. We are thus in a position could be added to the frame in the form of a timing character; where it is impossible to prove recovery in all circumstances, this means that a fourth process must also be modeled, which but can prove recovery from a specified number of errors. This
IEEE TRANSACTIONS ON COMPUTERS, VOL.
634 STATES SATISFYING
INITIAL CONDITION
FIRST SUCCESSOR STATES
/
SECOND SUCCESSOR STATES
r
i -
_
DESIRABLE CONDITION
REACHED
GLOBAL STATES
Fig. 9. Traces of several paths. (©) 1982 by North-Holland, Amsterdam, The Netherlands. Reprinted by permission [14, Fig. 10].)
is similar to the situation that prevails with respect to bit errors, where codes can be derived that permit recovery from single or multiple bit errors, but not from arbitrarily large numbers of bit errors. VII. PROVING FUNCTIONAL PROPERTIES
Our usual validation procedure consists again of first generating a global-state graph. Reception errors and unexercised arcs (dead code) are automatically detected. In a ring protocol as modeled here, static deadlocks cannot exist and will not be detected. In our present work, we have also found it desirable to prove that the protocol has certain functional properties; this is equivalent to proving specific assertions about the protocol. To prove that the protocol has certain functional properties, the technique used here is to demonstrate that given a particular initial condition or state, another desirable condition or state is reached regardless of what the connecting particular path in global-state space happens to be. As discussed in the previous section, an important property we should like to prove is the recovery of the protocol from a specified number of occurrences of particular transmission errors. There are two mechanisms which can be used to carry out such a proof. The first requires calculation of a reachability matrix showing which global states can be reached from all other global states. The second technique generates a trace of all the possible paths starting from those global states satisfying a specified initial -condition. The trace continues until either a desired final condition is reached-at which point the trace is successfully terminated-or until a specified number of iterations is reached without satisfying the desired condition. At this point, the protocol must be examined to determine whether an error has occurred or whether more iterations are required to reach the desired condition. We have found the technique of using traces to be the more practical for two reasons. First, the reachability matrix does not have to be generated; this can be large and costly to calculate in terms of computer time. Second, the sequence of transitions along the trace can easily be displayed, and this is most instructive for analyzing and repairing a faulty protocol. A graphical representation of the trace technique used is shown in Fig. 9. Given a particular starting condition-for
C-31,
NO.
7,
JULY 1982
example, the introduction of an error-the set of all corresponding global states is identified. The successor states to the initial set of states are generated and then checked to see whether the desired termination condition (successful recovery in the case where a transmission error has been introduced) has been reached. When the desired termination condition is reached, the corresponding path is no longer followed. Successor states are again generated, examined, etc., for the paths not yet satisfactorily terminated. The overall procedure just described is similar to that used by Brand and Joyner to prove protocol properties by means of symbolic execution [16], the difference being that Brand and Joyner generally store more information per global state but traverse fewer of these global states. For the protocols we have examined we feel that we have found a fortuitous tradeoff between expressive power and computational feasibility. VIII. EXTENSION TO MULTIPLE-ACCESS PROTOCOLS
Extension of the model described to other tightly synchronized processes is fairly straightforward. One such extension we plan to make is to multiple-access protocols for broadcast media such as the "Aloha" or "Ethernet"-type protocols. Here the main difference is in the transmission medium. This we plan to model as a single buffer seen by all the communicating processes. Output of all information sources will be "OR"-ed together into the common buffer. All the attached devices would then read the contents of this common buffer. IX. CONCLUSION
The work reported on here includes a representation for communication protocols which is particularly well suited for tightly coupled or synchronized processes, a means of incorporating the flow of time and time-outs in the model, and a method for including demonstrations that assertions regarding desirable protocol functions are true or untrue. Our initial experience with this modified validation system-application to a token-ring local area network-[ 14] has shown that 1) the representation itself is conveniently compact (this is a result of including the repeater function); 2) the validation process is indeed much more efficient in terms of the computer time required for validation than our previous approach (fewer global states are generated because of the enforced synchronism); 3) the mechanism for demonstrating functional protocol properties is useful and straightforward to apply (this has seen extensive use in connection with demonstrating recovery from transmission errors); and 4) the use of the trace mechanism is an ideal means for acquiring insight into a protocol. (Seeing the sequence of events leading to a difficulty is the fastest means of understanding the underlying phenomena.) A disadvantage of the technique is that conclusions can be drawn concerning the protocol's behavior only for a particular ring configuration. Because the validation is automated, it is possible, of course, to repeat it with different numbers of processes, or ordering of processes, and so to examine different
635
RUDIN AND WEST: VALIDATION FOR TIGHTLY COUPLED PROTOCOLS SAMPLE A MODIFIED ON 4 JAN 1982 SYSTEM 'D,A,B' EVENTS 'NULL,FREE,IDLE,BUSY,ADDRA,ADDRB,DATA,ERROR'
PROCESS 'D' A THIS IS THE DEMON STATES 'IN2.IN1.INO,D1,D2' REPEAT IIN2,IN1,INO,D1,D2' A
---
A THE DEMOH INITIALIZES THE RING: TRAN '1IN2 ,IN ,NULL,FREE' TRAN 'IN1, INO,NULL,IDLE' TRAN 'INO,D1,NULL,IOLE'
TRAN -D1,D2,ADDRA,ADDRA1 TRAN 'D1,D2,ADDRH,ADDRBH A THE ONLY ERRORS WHICH THE DEMON IS ALLOWED TO MAKE: TRAN 'D1,D2,ADDRH,ADDRA' TRAN 'Dl,D2,ADDRA,ADDRB' RA---
PROCESS A' A THIS IS TERMINAL A
STATES 'SO,S1,S2,S3,S4,S5' REPEAT '50' TRAN 'SO ,SO,FREE,FREE' TRAN 'SO,S1.FREE,BUSY' TRAN '51 ,S2,IDLE,ADDRA' TRAN 'S2,S3,IDLE,DATA' TRAN 'S3,S4,BUSY,FREE' TRAN 'S4 ,S5,ADDRA ,IDLE' TRAN 'S5 ,SO.DATA ,IDLE' PROCESS 'H' A THIS IS TERMINAL B STATES 'SO,S1,S2,S3,S4,S5,' REPEAT 'SO' TRAN 'SO,SO.PREE,FREE'
TRAN eSO, S1, FREE,BUSY' TRAN 'S1 ,S2 ,IDLE,ADDRH' TRAN 'S2,S3.IDLE,DATA' TRAN '53 ,S4 ,BUSY,FREE' TRAN 'S4 ,S5,ADDRB,IDLE' TRAN 'S5 ,SO ,DATA ,IDLE'
Fig. II. State transition diagram for terminal A. VALDRING
ERROR IN STATE NO. 16 ERROR IN STATE NO. IS 2 9 S TA TES EXERCISED. 2 9 s TAES GENERA TED TMFE TAKEN 2.72 SECYONS GLOBAL STATES To BE LISTED 16 18
RINGSTATE:
RIN-C> RINGSTAJ£:
RING 'D,A,B' 12000 ENDRING 6017
la ST->
16
D
IS
RING> FREE
A
AODR8S
DATA
B
A
D
D2
FREE
DATA
SO
ADDRA
54
Fig. 10. Formal definition of sample protocol state.
Fig. 12. Invoking validator and results of validation.
topologies. The generalized validation of a protocol for multiple topologies can be performed in some simple cases [17], but in general appears to be difficult. Some induction technique that would allow results of a single validation to be extrapolated to multiple configurations would be particularly interesting for ring-topology systems. This is a subject for future research. APPENDIX
In order to illustrate the technique, a simplified token-ring protocol is included here. The protocol is formally described in Fig. 10 and consists of three processes: two communicating terminals A and B, and a demon D, whose function is that of simulating transmission errors. The protocol is best understood by looking first at Fig. 11 which shows the state transition diagram for terminal A. The protocol is patterned very much after the frames shown in Fig. 6. Note that terminal A transmits a particular address ADDRA as its source address. After converting the free frame to a busy frame terminal A waits in state S3 until its busy frame returns, then converts it back to a free frame. Thus a sending terminal removes the messages which it generates; the receiving terminal merely makes a copy of the passing messages destined for it. The destination is specified by a destination address which is not modeled here. Returning to Fig. 10, the formal protocol specification is written in APL in the form of a function SAMPLE. Looking down through the protocol the following can be seen. The protocol "SYSTEM" consists of three processes D, A, and B.
There follows a list of "EVENTS" or message types. Two types are new: NULL used only for ring initialization and ERROR used as part of the protocol error detecting mechanism; neither is a part of the protocol per se. The PROCESSES are now defined in turn, the first being the demon D. First, a list of the STATES in this process is given followed by a list of STATES which have the REPEAT property mentioned above in Section III. The demon was given the task of initializing the ring as shown in the next three TRANsition statements, which indicate in sequence the present state, the succeeding state, the message type received, and the message type sent for each state transition. The following four transitions describe first error-free transmission and then single error corruptions of the two possible source addresses as described- in Section VI. Process A is described in a similar fashion; process B is identical with the exception that its source address is ADDRB. The RING statement specifies the order in which the processes are to appear on the ring, and the final statement initializes a hashing scheme for storing the global system states as they are generated by the validation process. Executing the function defined by Fig. 11 generates the transition tables, etc., required by the validator. The validator itself is invoked by executing the function VALRING as shown in Fig. 12. The validator has found two errors; running time statistics are also given. The offending global states are then listed in detail. Directly under the label for each of the three processes D, A, and B appears the state of the corresponding
IEEE TRANSACTIONS ON COMPUTERS, VOL. c-31, NO. 7, JULY 1982
636 CBECK X GLOBAL STATES TO BE LISTED 16 18
RINOSTATE: 16 ST-, RINGC
16
D
DATA
D2
B ADDRB
54
FREE
so
D 1 ST-
RING, NULL
2 ST-,
RINGD
4
ST-
RINGD
7 ST->
RINGD
10 Sr-,
RINGD
16 ST-, RINGC
NULL NULL BUSY ADDRA
DATA
IN2
IND
INO Di Di
D2
NULL
FRgg
IDLE IDLE
BUST
50
so
S1
S2 S3
S4 ADDRB
NULL
NbULL BUSY ADDRA DA TA
FREE
so so
so so so
so
Fig. 13. Trace of global state 16.
[5] C. H. West and P. Zafiropulo, "Automated validation of a communications protocol: The CCITT X.21 recommendation," IBM J. Res. Develop., vol. 22, pp. 60-7 1, Jan. 1978. [6] IBM Europe, "Technical improvements to CCITT recommendation X.25," Study Group VII, Oct. 1978. [71 G. D. Schultz, D. B. Rose, C. H. West, and J. P. Gray, "Executable description and validation of SNA," IEEE Trans. Commun., vol. COM-28, pp. 661-677, Apr. 1980. [8] M. Sherman and H. Rudin, "Using automated validation techniques to improve distributed software reliability," in Proc. IEEE Symp. on Rel. in Distributed Software and Database Syst., Pittsburgh, PA, July 21-22, 1981,pp. 107-112. [9] J. Hajek, "Automatically verified data transfer protocols," in Proc. 4th Int. Conf. Comput. Commun., Kyoto, Japan, Sept. 1978, pp. 749756. [101 G. V. Bochmann and C. Sunshine, "Formal methods in communication protocol design," IEEE Trans. Commun., vol. COM-28, pp. 624-631, Apr. 1980. [11] C. A. Sunshine, Ed., Communication Protocol Modeling. Dedham, MA: Artech House, 1981. [12] M. V. Wilkes and D. J. Wheeler, "The Cambridge digital communication ring," in Proc. Local Area Network Symp., Boston, MA, May 1979, pp.47-59. [13] J. Rubin and C. H. West, "An improved protocol validation technique," Comput. Networks, to be published, [14] H. Rudin, "Validation of a token-ring protocol," in Proc. Int. Symp. on Local Comput. Networks. Amsterdam, The Netherlands: NorthHolland, to be published. [15] Y. Yemini and D. Cohen, "Some issues in distributed process communication," in Proc. 1st Int. ConfJ on Distributed Comput. Syst., Huntsville, AL, Oct. 1979, p. 199. [16] D. Brand and W. H. Joyner, Jr., "Verification of protocols using symbolic execution," Comput. Networks, vol. 2, pp. 351-360, Oct. 1978. [17] P. Merlin, "Specification and validation of protocols," IEEE Trans. Commun., vol. COM-27, pp. 1671-1680, Nov. 1979.
process, i.e., states D2, S4, and SO, correspondingly. Below and between the various states the various message types flowing on the ring are shown in their proper physical position on the ring. The error, in the case of global state 16 is that there is no provision for receiving ADDRB in state 54 of process A. In the case of global state 18 there is similarly no provision for handling ADDRA in process B. These, of course, are the errors introduced by the demon. At this point the designer would have Harry Rudin (S'55-M'62-SM'81) received the to decide what error recovery mechanism he wants to initiate B.E., M.E., and D. Eng. degrees from Yale University, New Haven, CT, in 1958, 1960, and 1964, should such an error occur and modify the protocol correrespectively. spondingly. From 1961 to 1964 he served as Instructor in In a more complicated protocol it is often difficult to imagine Electrical Engineering at Yale University. In 1964 he joined Bell Laboratories, where he worked in just what sequence leads to a particular error. In this case a 2 the area of data communications, mainly on autotrace of the path leading to the particular global state is most matic equalization techniques. He has been with instructive. Such a trace is shown in Fig. 13 for global state 16. the IBM Zurich Research Laboratory, Ruschlikon, Switzerland since 1968, where he has worked As time moves down the figure, one can see how the demon computer communications systems. Here his activities, first centered on first initializes the ring by generating FREE, IDLE, IDLE, on traffic theoretic aspects of information flow in computer networks, particularly and how terminal A then converts this free frame to a busy on the problems of dynamic multiplexing, network dimensioning, routing, and control. Recently, he has worked on the formal specification of protocols frame BUSY, ADDRA, DATA, and how the demon corrupts inflowcomputer-communication systems and their automated verification. ADDRA to ADDRB as it goes from state DI to D2, finally Dr. Rudin is an Editor of the IEEE TRANSACTIONS ON COMMUNICAculminating in the error condition shown in global state 16. TIONS, a correspondent for IEEE COMMUNICATIONS MAGAZINE, and is active in a number of IEEE Communications Society committees.
ACKNOWLEDGMENT
The authors wish to thank F. Closs and H. Mueller for numerous discussions on ring protocols, and D. Brand, R. Hauser, and P. Zafiropulo for many discussions on protocols per se. REFERENCES [I] H. Rudin, C. H. West, and P. Zafiropulo, "Automated protocol validation: One chain of development," in Proc. Comput. Network Protocol Conf., Liege, Belgium, Feb. 1978, paper F4. [2] C. H. West, "General technique for communications protocol validation," IBM J. Res. Develop., vol. 22, pp. 393-404, July 1978. [3] P. Zafiropulo, "Protocol validation by duologue-matrix analysis," IEEE Trans. Commun., vol. COM-26, pp. 1187-1194, Aug. 1978.
[4] P. Zafiropulo, C. H. West, H. Rudin, D. D. Cowan, and D. Brand, "Towards analyzing and synthesizing protocols," IEEE Trans. Commun., vol. COM-28, pp. 651-660, Apr. 1980.
ng
C 1 H. West (M'81) received the B.S. degree in Coln physics in 1960 and the Ph.D. degree in elementa-
ry particle physics in 1965, both from Imperial College, London, England. From 1961 to 1966 he was a Visiting Scientist at the European Organization for Nuclear Research (CERN) in Geneva, Switzerland, and subsequently held post-doctoral positions in the Department of Physics and in the Moore School of Electrical Engineering of the University of Pennsylvania, Philadelphia. He joined IBM in 1971 at the Zurich Research Laboratory and has worked on laboratory automation, computer graphics, communications, and computer networks. He is currently working on image processing and the further development of communications protocol validation. Dr. West is a member of the American Physical Society. He recently received an IBM Outstanding Innovation Award for his work on the automated validation of communications protocols.
