A Formalized Methodology for Constructing Safe Multiphase Protocols Robert J. Hilderman and Howard J. Hamilton Department of Computer Science University of Regina Regina, Saskatchewan, Canada, S4S 0A2 fhilder,
[email protected]
Abstract
Communication protocols typically go through di erent phases, where each one performs a distinct function. Phases are implemented as layers (i.e., a protocol constructed on the OSI model) or as alternative functions (a protocol which can perform many functions, but is limited to performing one at a time). In either case, each phase is itself a protocol which can be modelled as a communicating nite-state machine. A multiphase communication protocol is constructed by connecting a state (or states) of protocol A to a state (or states) of protocol B in such a way that if the component protocols A and B are safe, then the multiphase protocol is safe. [Chow et al, 1985] proposed a method for connecting states which has this property. An improved method was subsequently proposed by [Lin and Tarng, 1993]. In this paper, we discuss a new protocol veri cation method which we use to analyze, construct, and verify a multiphase protocol. The State Transition Generation Algorithm, an algorithm which we have developed based upon the method of Lin and Tarng, is used to analyze Prolog speci cations for two communicating nite-state machines being combined, and to generate any new transitions that are required to ensure the new multiphase protocol is safe. We then use a protocol modelling language and two automated protocol veri cation tools to construct and verify the multiphase protocol. The multiphase protocol is shown to be safe with respect to speci c correctness criteria when the component protocols are augmented with the new transitions generated by the State Transition Generation Algorithm.
1 Introduction Communication protocols typically go through many different phases during operation, where each phase performs some distinct function. These may be implemented as layers (i.e., as in the OSI model) [Tanenbaum, 1989] or as alternative functions (i.e., the protocol is limited to performing one function at a time) [Lin, 1991]. In either case, the protocol layers or alternative functions are complex parallel programs known as multiphase protocols. When constructing a multiphase protocol, it is useful and reasonable to analyze, design, and develop each phase independently. We propose a vestep methodology as follows:
Partition the complex multiphase protocol into several simpler component protocols.
Design, construct, and verify the operation of each component protocol.
Connect the component protocols together to reconstruct the complex multiphase protocol.
Use the State Transition Generation Algorithm to determine any new transitions that are required to ensure the multiphase protocol is safe.
Model and verify the multiphase protocol using an automated protocol veri cation tool.
One technique that has been used successfully in this divide-and conquer approach is to model the component protocols as networks of nite automata called communicating nite-state machines [Bochmann, 1978], [Chow et al, 1985], [Lin and Tarng, 1993]. Using this technique, a state (or states) of a nite automaton representing protocol A must be connected to a state (or states) of a nite automaton representing protocol B in such a way that certain general properties of correctness are maintained. In [Chow et al, 1985], a method is proposed for connecting the nite automata for A and B which satis es certain correctness properties. However, their method su ers from one serious weakness. They assume that a message transmitted immediately before a phase transition (i.e., where control is passed from one phase to another) can never be lost or corrupted. In [Lin and Tarng, 1993], an improved method for connecting the nite automata for A and B is proposed which tolerates message loss and corruption. Their method is based upon four rules which enable component protocols to be connected together in a disciplined manner to ensure that the multiphase protocol is correct. We have incorporated the four rules of Lin and Tarng into the State Transition Generation Algorithm. This algorithm analyzes the Prolog speci cation for the nite automata of the component protocols being combined to determine whether any new transitions must be added to the multiphase protocol to ensure that it is safe. Any new transitions generated are added to the nite automata of the component protocols from which a PROMELA model is constructed. PROMELA [Holzmann, 1991] [Holzmann, 1993] is a notation for specifying and formalizing the behaviour of nite automata. The PROMELA model is then veri ed using SPIN [Holzmann, 1991] [Holzmann, 1993], a software tool for executing and simulating PROMELA speci cations, and PAN [Holzmann, 1991] [Holzmann, 1993], a software tool which uses reachability analysis techniques to check for logical inconsistencies in the state space of a PROMELA model.
The remainder of this paper is organized as follows. In Section 2, an overview of protocols and correctness criteria for verifying protocols is presented. In Section 3, the communicating nite-state machine method for specifying the procedure rules of a protocol is discussed, as well as rules for connecting protocols. In Section 4, the State Transition Generation Algorithm is introduced. In Section 5, a PROMELA, SPIN, and PAN are described. In Section 6, we present a detailed example demonstrating steps four and ve of our proposed methodology. In Section 7, we provide a brief discussion of our experience in applying this methodology. We conclude in Section 8 with a summary of our work and suggestions for future research.
2 Protocols and Correctness Criteria Protocols are sets of rules governing the interaction of concurrent processes in distributed systems. A protocol formalizes the interaction between communicating components by standardizing key elements of how information is exchanged. A protocol speci cation is similar to a language de nition in that it consists of a vocabulary, encoding format, and procedure rules [Holzmann, 1993]. There are many di erent kinds of failure that can occur during the operation of a protocol because of the many possible interleavings of states of concurrently executing processes. New procedure rules can be added to address the di erent kinds of failure, but each new procedure rule increases the complexity of the protocol in ways that may not be known or may not be immediately obvious. Correctness criteria are properties which specify the kinds of failure that a protocol can tolerate. A safety property expresses something bad that should never happen (i.e., that we would like to be impossible). Safety properties include:
Freedom form deadlock. Deadlock occurs when the protocol is unable to make forward progress because each communicating process is waiting for one of the other processes to do something that will never occur.
Freedom from unspeci ed reception. Unspeci ed reception is the result of a logically inconsistent or incomplete protocol which causes a process to receive a message at a state of execution where the next state of execution is unde ned.
Freedom from assertion violations. Assertion violations are Boolean conditions that are not satis ed when a process or set of processes reaches a given state of execution.
Freedom from unexecutable code. Unexecutable code signi es that the requirements of the protocol are not fully understood or that it may be overspeci ed.
On the other hand, a liveness property expresses something good that should eventually happen (i.e., that we would like to be inevitable). Liveness properties include:
Delivery of the speci ed service. There should be no non-progress cycles or livelock cycles. A non-progress cycle is an in nite series of states that have never been visited. Similarly, a livelock cycle is an in nite series of states that has already been visited. Termination of the speci ed service. Proper termination occurs when all processes have terminated and all messages have been received.
A protocol can be proven correct only with respect to speci c correctness criteria (i.e., a given protocol may not necessarily satisfy all of the above correctness criteria). A protocol that does satisfy speci c correctness criteria does not take inconsistent courses of action with respect to the criteria and is said to be safe, logically consistent, complete, or free from collision.
3 Constructing Multiphase Protocols
In this work, a protocol is modelled as a pair of nite automata [Bochmann, 1978]. Since transitions between states represent the sending (receiving) of a message to (from) the other nite automaton in the pair, the model is called a communicating nite-state machine. More formally, a communicating nite-state machine is directed labelled graph where each node corresponds to a di erent state of the protocol and each edge (i.e., transition) corresponds to the sending or receiving of a message. A transition from state x to state y is said to be incident from state x and incident to state y. One node is designated as the initial state, and each node in the communicating nite-state machine is reachable from this node. A nal node is a node in the communicating nitestate machine with no transitions incident from it (there may be more than one nal node). A nal node that is reached during execution of the protocol represents a termination state for the protocol. An ordered pair (M; N ) is used to denote a protocol consisting of the communicating nite-state machines M and N . A multiphase protocol is a network of communicating nite-state machines which possesses certain desirable correctness properties. It is constructed by connecting together simpler component protocols which represent speci c phases or functions. That is, given protocol (M1 ; N1), called the leading phase, and protocol (M2 ; N2), called the trailing phase, connect the respective component protocols together to create protocol (M; N ) in such a way that the following properties are satis ed:
M1 is connected to M2 . N1 is connected to N2 . When (M1 ; N1) reaches some state of execution, it is terminated. When (M1 ; N1) is terminated, (M2 ; N2) is activated. If (M1 ; N1) and (M2 ; N2) are safe, then the new multiphase protocol (M; N ) is safe.
The states in which M1 is connected to M2 and N1 is connected to N2 are called joint states. It is not merely sucient to arbitrarily join two safe component protocols without considering the possibility of collision. Collision occurs when one of the communicating nite-state machines takes some inconsistent course of action as a result of violating a safety or liveness property. This typically happens following phase reactivation, where one of the communicating nite-state machines follows a transition from the joint state and resumes execution at some state in the leading phase of the multiphase protocol, while the other follows a transition from the joint state and resumes execution in the trailing phase. Consequently, there must be some method for resolving collisions which enables the component protocols to resynchronize the phases. In [Lin and Tarng, 1993], four rules are speci ed which identify new transitions to add to the multiphase protocol to ensure that it is able to resolve collisions due to phase reactivation. New transitions are generated according to the four rules as follows:
Rule 1. If there are any sending transitions inherited
from the leading phase that are incident from the joint state, then add a similar transition to each state inherited from the trailing phase. Rule 2. If there are any receiving transitions inherited from the leading phase that are incident from the joint state, then add a similar transition to each state inherited from the trailing phase. Rule 3. If there are any receiving transitions inherited from the trailing phase, and any sending paths inherited from the leading phase which start at the joint state, then add a receiving transition loop (i.e., a transition incident from and incident to the same state) to each state of the sending path. Rule 4. If there are any sending paths inherited from the trailing phase of M (N ) and any sending paths inherited from the leading phase of N (M ), then remember the states on the sending paths in the leading phase and the messages from each sending transition in the trailing phase.
Rules 1 and 2 are symmetric, di ering only in whether they check for a sending or receiving transition. By adding the new transitions generated by rules 1 and 2, we are allowing the trailing phase of M (N ) to reactivate the leading phase so that it can resynchronize with the leading phase of N (M ). In rule 3, the rst transition on the sending path in M (N ) represents the action of reactivating the leading phase, and the receiving transition loop is used to receive a message in the trailing phase from N (M ). Rule 4 generates transitions that could be used to resolve collisions if there are sequences of transitions in the communicating nite-state machines that allow one to enter the trailing phase while the other remains stuck at some non-joint state in the leading
phase. Whether any transitions are required as a result of rule 4 cannot be easily determined except through a state space analysis during automated protocol veri cation.
4 State Transition Generation Algorithm The communicating nite-state machines for a protocol are usually complex, even for simple protocols, complicating the task of applying the four rules of the previous section. To ensure that no transitions are overlooked when constructing a multiphase protocol, we have developed an automated tool which analyzes the communicating nite-state machines being combined and generates the transitions required to ensure that the multiphase protocol is safe. The tool, called the State Transition Generation Algorithm, and written in SWIProlog, is a combination of graph search algorithms which checks for the types of transitions speci ed in the four rules.
5 Automated Protocol Veri cation Three state-of-the-art protocol modelling and veri cation tools were used to verify the multiphase protocol augmented with the transitions generated by the State Transition Generation Algorithm. The tools, PROMELA, SPIN, and PAN, are described completely in [Holzmann, 1991] and [Holzmann, 1993]. PROMELA is a protocol speci cation language that has syntax and semantics similar to the C programming language. It allows the designer of a protocol to separate those fundamental rules required to verify the protocol from those required to implement the protocol. SPIN is a software tool for executing and simulating PROMELA speci cations. Its primary function is to analyze the logical consistency of a PROMELA speci cation through a random simulation. Random simulation can detect whether a PROMELA speci cation is free from assertion violations, invalid endstates, unspeci ed receptions, unreachable states, and deadlock. PAN is a software tool for performing state space analysis of PROMELA speci cations which uses reachability analysis techniques to generate and test all states that it is possible to reach from each state in the protocol.
6 An Extended Example In this section, we demonstrate steps four and ve of our formalized methodology to incrementally construct and verify a multiphase protocol. The multiphase protocol model is shown pictorially in Figure 1. In Figure 1, we show two stations, called M and N , connected by a communication channel, called the physical layer. M consists of a network layer, and a data link layer containing two processes: the primary station of the Unbalanced Link Initialization Protocol (i.e., M1 ) [Baratz and Segall, 1988] and the sending station of the Positive Acknowledgement/Retransmission Protocol (i.e., M2 ) [Tanenbaum, 1989]. Similarly, N consists of a network layer, and a data link layer containing two processes: the secondary station of the Unbalanced Link Initialization Protocol (i.e., N1 ) and the receiving station of the Positive Acknowledgement/Retransmission Protocol (i.e., N2 ).
M
M2
Physical Layer
Data Link Layer
joint(m,8,9). joint(n,5,6).
N1
M1
Network Layer
initial(m,1). initial(n,1).
N
Data Link Layer
Network Layer
N2
Figure 1. The multiphase protocol model
The Unbalanced Link Initialization Protocol is a data link layer technique for opening a connection between two stations and ensuring synchronization prior to transferring data. The Positive Acknowledgement/Retransmission Protocol is a data link layer alternating-bit technique which allows data to be transmitted in one direction over a channel that may corrupt and lose messages. Other speci c details of the Unbalanced Link Initialization Protocol and the Positive Acknowledgement/Retransmission Protocol will not be described here. For more details on these protocols, please consult [Baratz and Segall, 1988] and [Tanenbaum, 1989], respectively. The objective of this extended example is to construct and verify the multiphase protocol (M; N ), where M and N are the protocols created by combining processes M1 and M2 and processes N1 and N2 , respectively. The multiphase protocol (M; N ) works as follows. The network layer of M instructs M1 to set up a connection with N . M1 sets up a connection by exchanging a series of messages with N1 . When M1 has determined that a high-quality connection has been established, it noti es the network layer in M . Concurrently, N1 noti es the network layer in N that a connection has been established. After receiving the noti cation from M1 , the network layer in M instructs M2 to begin sending data to N2 . Concurrently, after receiving the noti cation from N1 , the network layer in N instructs N2 to expect to receive data from M2 . The multiphase protocol must enforce the following conditions. First, since the physical layer can corrupt and lose messages, then M and N must be capable of resynchronizing, when necessary. Second, processes M1 and M2 and processes N1 and N2 can communicate concurrently with the network layer in M and N , respectively. Third, only one of the processes in each of M and N should be active at any given time (i.e., sending (receiving) messages to (from) the physical layer). And last, M1 must not set up a connection with N2 , and M2 must not send data to N1. The Unbalanced Link Initialization Protocol and the Positive Acknowledgement/Retransmission Protocol were modelled in PROMELA and veri ed using SPIN and PAN [Hil-
transition(m,1,[[2,+,timeout],[3,+,dack]]). transition(m,2,[[1,-,disconnect]]). transition(m,3,[[4,-,clear]]). transition(m,4,[[3,+,timeout],[5,+,cack]]). transition(m,5,[[6,-,test]]). transition(m,6,[[2,+,timeout],[7,+,tack]]). transition(m,7,[[8,-,success]]). transition(m,8,[[1,-,disconnect]]). transition(m,9,[[10,-,zero]]). transition(m,10,[[9,+,timeout],[11,+,ack]]). transition(m,11,[[12,-,one]]). transition(m,12,[[11,+,timeout],[9,+,ack]]). transition(n,1,[[2,+,disconnect],[3,+,clear],[4,+,test],[5,+,success]]). transition(n,2,[[1,-,dack]]). transition(n,3,[[1,-,cack]]). transition(n,4,[[1,-,tack]]). transition(n,5,[[2,+,disconnect]]). transition(n,6,[[7,+,zero],[11,+,one]]). transition(n,7,[[8,-,ack]]). transition(n,8,[[9,+,zero],[10,+,one]]). transition(n,9,[[8,-,ack]]). transition(n,10,[[6,-,ack]]). transition(n,11,[[6,-,ack]]).
Figure 2. Prolog specification for (M; N )
derman, 1997]. Both protocols were found to be safe with respect to assertion violations, invalid endstates, unspeci ed receptions, unreachable states, deadlock states, and nonprogress cycles. To determine whether there were any new transitions required to make the multiphase protocol (M; N ) safe, we developed a Prolog speci cation for (M; N ), shown in Figure 2, and used it as input to the State Transition Generation Algorithm. In Figure 2, the initial state of M and N is state 1. The joint state for M1 and M2 is states 8 and 9, respectively, and the joint state for N1 and N2 is states 5 and 6, respectively. Following the transitions in the Prolog speci cation, the original communicating nite-state machines can be reconstructed. For example, by decoding transition(m,1,[[2,+,timeout],[3,+,dack]]) we nd that state 1 in M is connected to states 2 and 3 via a timeout receiving transition and a dack receiving transition, respectively. The + and - symbols denote a receiving and sending transition, respectively. The State Transition Generation Algorithm generated the new transitions shown in Figure 3. In Figure 3, three new transitions are required in M . First, according to rule 1, a sending transition labelled disconnect is required, incident from all states in M2 and incident to state 1 in M1 . Second, according to rule 3, a receiving transition labelled ack is required, incident from and incident to state 1 in M1 . Third, according to rule 3, a receiving transition labelled timeout is required, incident from and incident to state 1 in M1. One new transition is required in N . According to rule 2, a receiving transition labelled disconnect is required, incident from all states in N2 and incident to state 2 in N1 . The information provided in the remainder of Figure 3 speci es a transition that could be required if a rule 4 violation is detected during automated protocol veri cation. It says that a receiving transition labelled zero may be required, incident
Checking protocols M1 and M2. Applying rules 1 and 2. Add [1,-,disconnect] to all states in M2. Rules 1 and 2 done. Applying rule 3. Add [1,+,ack] to state 1 in M1. Add [1,+,timeout] to state 1 in M1. Rule 3 done. Protocols M1 and M2 done. Checking protocols N1 and N2. Applying rules 1 and 2. Add [2,+,disconnect] to all states in N2. Rules 1 and 2 done. Applying rule 3. Rule 3 done. Protocols N1 and N2 done. Checking protocols M1 and N2. Generating sending paths for M1. [2,1] [8,1] [7,8,1] [5,6] [3,4] M1 done. Generating messages for N2. N2 done. Protocols M1 and N2 done. Checking protocols N1 and M2. Generating sending paths for N1. [2,1] [3,1] [4,1] N1 done. Generating messages for M2. [ ,+,zero] M2 done. Protocols N1 and M2 done.
Figure 3. New transitions generated for (M; N )
from and incident to state 1 in N1 . To determine whether any of the new transitions are actually necessary for (M; N ) to be safe, a PROMELA speci cation was developed according to the original speci cations (i.e., without any of the new transitions added). Using SPIN, the rst random simulation of the PROMELA speci cation found N1 receiving a zero message. But N1 is not supposed to receive a zero message, only N2 is. This situation developed because a a success message was lost enabling M to enter the trailing phase while N remained in the leading phase. To resolve this problem, the leading phase of N was modi ed by adding a receiving transition loop labelled zero to state 1. The second random simulation found N2 receiving a disconnect message. But N2 is not supposed to receive a disconnect message, only N1 is. This situation developed because M2 timed out trying to send a zero message enabling M to reenter the leading phase while N remained in the trailing phase. To resolve this problem, the trailing phase of N was modi ed by adding the receiving transition labelled disconnect incident from state 8 and incident to state 2.
The third random simulation found that M2 timed out after trying to send a zero message. After sending a zero message, M2 waits to receive an ack message from N2 . But N2 was unable to send an ack message because a success message was lost earlier, enabling M to enter the trailing phase, while N remained in the leading phase. Since M2 cannot receive an ack message from N1 , there is obviously a problem with the channel, so it should be re-initialized. M2 can start the re-initialization of the channel by sending a disconnect message to N . To resolve this problem, the trailing phase of M was modi ed by adding the sending transition labelled disconnect, incident from states 10 and 12 and incident to state 1. The fourth random simulation completed error-free with both M and N entering a valid endstate. This result does not necessarily mean that the protocol is safe, it just means that a sequence of random events was executed which allowed the protocol to enter a valid endstate. There are likely many states that were not generated and tested during the random simulations. But since SPIN did not nd any logical inconsistencies during the random simulation, the next step is to do a state space analysis using PAN. Two PAN runs were done, where each run checked for violations of di erent correctness criteria. In the rst run, a full state space analysis was done to check for assertion violations, invalid endstates, unspeci ed receptions, unreachable states, and deadlock states. In the second run, a full state space search was done to check for assertion violations and non-progress cycles. In both runs, no correctness criteria violations were found. Given these results, we now state that the multiphase protocol (M; N ) is safe with respect to the correctness criteria speci ed. It appears that the receiving transition labelled ack, incident from and incident to state 1 in M , is not required to ensure that (M; N ) is safe. One of the requirements of the Unbalanced Link Initialization Protocol is that a primary station should ignore all messages it receives other than dack, cack, and tack messages. This technique is used to clear the channel of old messages prior to re-initializing the connection with the secondary station. This would include ack messages sent from the secondary station. Consequently, the PROMELA speci cation for M1 already had the capability to receive and ignore ack messages.
7 Discussion
There is not necessarily an obvious relationship between the states in the communicating nite-state machines for a protocol and the corresponding PROMELA speci cation. For example, the six states in the communicating nite-state machine for N2 are accommodated in a tight PROMELA do loop, with each state distinguished from the others by setting ags to particular values. The actual state that the PROMELA model is in at this point is not known until runtime. On the other hand, the communicating nite-state machine for M1 and the corresponding PROMELA speci cation have a fairly close relationship.
The lack of a clear relationship between the communicating nite-state machines and the PROMELA code contributed to another problem. Most of the time spent doing this work was spent attempting to produce a high-quality PROMELA model. It was found that that it takes a long time to get models that properly re ect the communicating nite-state machines and that are acceptable for veri cation. This same problem has been reported by other researchers using automated protocol veri cation tools [Cattel, 1994]. The communicating nite-state machine model has also been found to be a weak model. The model seems to oversimplify the complexity of a protocol in some instances (particularly when messages can be corrupted or lost). This same problem has also be previously reported by other researchers [Lin, 1991]. Finally, the use of the communicating nite-state machine model makes it dicult to preserve the modularity of the component protocols. For example, if we want to combine protocols A and B to form protocol (A; B ), we don't want to simply combine all the characteristics of protocols A and B into one big communicating nite-state machine or write one big PROMELA speci cation. We'd probably like to preserve the modularity of the component protocols by creating some kind of control structure that can coordinate the two component protocols so that it appears as though they are one. That is the approach that we took in this work when we decided to use a simulated network layer. Unfortunately, this adds a new level of complexity to the model that must then also be veri ed.
8 Conclusion and Future Research
Protocol veri cation is a complex task, even when there are only a few states in the associated communicating nitestate machines. To trace through the state space manually would be nearly impossible and the likelihood of error would be very high. We showed how automated tools can be used in a ve step methodology to simplify the task of protocol construction and veri cation. By using the State Transition Generation Algorithm, in conjunction with PROMELA, SPIN, and PAN, we showed that a multiphase protocol can be constructed which is safe with respect to speci c correctness criteria. Much work still needs to be done in deriving appropriate models for representing protocols and in translating these models into veri able speci cations. The communicating nite-state machine model upon which this work is based, appears to be a weak model for representing protocols. For example, there is no way to encapsulate special rules or conditions in the individual states of a communicating nitestate machine. Thus, the model seems suitable only for specifying the logical ow of a protocol from a high level. In contrast to communicating nite-state machines, PROMELA is a powerful notation for specifying the procedure rules. But when protocol speci cation is translated from a communicating nite-state machine model into a PROMELA model, how can we be sure that we have mod-
elled what was originally speci ed in the communicating nite-state machine model? That is, the translation process may result in errors being introduced into the protocol (particularly for complex protocols) or important details may be omitted entirely. Future research will focus on studying the relationship between communicating nite-state machines and PROMELA models. The objective of this work will be to develop reusable components representing various types of protocol behaviour. Using the method presented in this paper for generating new transitions, a protocol developers toolkit will be developed which enables a correct, complex protocol to be easily constructed from correct, simple components.
9 References
[Baratz and Segall, 1988] Baratz, A.E. and Segall, A., "Reliable link initialization procedures", IEEE Transactions on Communications, Vol. 36, No. 2, pp. 144-152, Feb. 1988. [Bochmann, 1978] Bochmann, G.V., "Finite-state description of communication protocols", Computer Networks, Vol. 2, pp. 361-372, Oct. 1978. [Cattel, 1994] Cattel, L., "Modelling and veri cation of a multiprocessor real-time OS kernel", Proceedings of the 1994 SPIN Workshop (SPIN'94), pp. 1-16, Berne, Switzerland, 1994. [Chow et al, 1985] Chow, C.H., Gouda, M.G., and Lam S.S., "A discipline for multiphase communication protocols", ACM Transactions on Computer Systems, Vol. 3, No. 4, pp. 315-343, Nov. 1985. [Hilderman, 1997] Hilderman, R.J., Constructing multiphase protocols, Technical Report, Department of Computer Science, University of Regina, Regina, SK, Canada, 1997. [Holzmann, 1991] Holzmann, G.J., Design and Validation of Computer Protocols, Prentice Hall Software Series, Prentice Hall, Englewood Cli s, N.J., 1991. [Holzmann, 1993] Holzmann, G.J., "Design and Validation of Protocols: A Tutorial", Computer Networks and ISDN Systems, Vol. 25, pp. 981-1017, 1993. [Lin, 1991] Lin, H.-A., "Constructing protocols with alternative functions", IEEE Transactions on Computers, Vol. 40, No. 4, pp. 376-386, Apr. 1991. [Lin and Stovall, 1989] Lin, H.-A. and Stovall, H.E., "Selfsynchronizing communication protocols", IEEE Transactions on Computers, Vol. 38, No. 5, pp. 609-625, May 1989. [Lin and Tarng, 1993] Lin, H.-A. and Tarng, C.-L., "An improved method for constructing multiphase communication protocols", IEEE Transactions on Computers, Vol. 42, No. 1, pp. 15-25, Jan. 1993. [Tanenbaum, 1989] Tanenbaum, A.S., Computer Networks, 2nd Edition, Prentice Hall, Englewood Cli s, N.J., 1988.
