Protocol verification for OSI

185

Protocol Verification for OSI Bj~rn P E H R S O N

1. Introduction

Swedish Institute of Computer Science, Box 1263, S-164 28 Stockholm, Sweden

Abstract. This is a tutorial on formal methods for verification of communication protocols. We focus on methods to show that a proposed communication protocol meets its specification by proving properties, and which offer support for the design of correct specifications of OSI protocols. Emphasis is put on methods where algorithms are available and can be integrated in protocol design tools. This kind of support is especially useful in the early phases of protocol design, to analyse basic properties. The methods can be used in the process of producing detailed specifications in any of the standardised formal description techniques: Estelle, LOTOS and SDL. Keywords. Distributed systems, protocols, analysis and verification, formal description techniques, OSI.

Bj6rn Pehrson received his BSc. from Stoeldaolm University 1966, his MSc. 1969 and his Ph.D. degree in automatic control in 1975 from the University of Uppsala. During the period 1969-1985, he worked as a lecturer, researcher and professor at Uppsala University in the area of methods and tools for design of distributed systems. Since 1985, when the Swedish Institute of Computer Science (SICS) was formed, he is managing the Distributed Systems Laboratory at SICS, and is also an adjunct professor in Computer Networks at the Royal Institute of Technology in Stockholm.

We will give a tutorial presentation of how to analyse the correctness of protocol specifications. After the introduction of some necessary concepts, two basically different methods are presented together with an illustrative example. A short introduction to more advanced methods are given with references for further reading. We will assume that the reader is familiar with the OSI concepts [30] and has some elementary background in system design. Since our scope is verification, which requires some sort of specification, we also recommend the tutorial on specification in this issue as a prerequisite [7]. A more general introduction to computer communication and protocols can be found in [23]. An earlier introduction to protocol specification and verification can be found in [8]. The OSI-model provides a framework for defining the s t r u c t u r e of interconnected entities in protocol design in terms of a layered architecture comprising services and protocol entities. The service in each layer is provided by means of a protocol, i.e. the procedure for communication between two protocol entities using the service of the underlying layer (Fig. 1). A well-structured specification facilitates subsequent verification. The service concept contributes to the structuring of all phases in protocol design, specification, synthesis, and validation [66]. Design of OSI protocols involves schematically the following phases (Fig. 2): - formulation of user requirements, - specification of communication services that meet the user requirements, -specification of protocols that provide the specified communication services,

North-Holland Computer Networks and ISDN Systems 18 (1989/90) 185-201 0169-7552/90/$3.50 © 1990, Elsevier Science Publishers B.V. (North-Holland)

Fig. 1. The structure of an OSI-layer.

B. Pehrson / Protocol verification for 0S1

186

Synthesis/ Design

(

~

requirements

~ - I

Servce

,,~1 Specification

I

Protocol Specification

-I

Protocol Entity ] Implementation

Analysis/ Validation

Fig. 2. Design of communication protocols.

implementation of protocol entities conforming to the protocol specifications. Observe that it is not protocols that are implemented, but protocol entities. The arrows directed from left to right represent activities of design (sometimes also called synthesis) in which specifications and implementations are created. Arrows directed from right to left represent activities checking the correctness of a specification or implementation. We will use the term validation as a generic term for investigation of the correctness of a design. As we will discuss below, verification is one out of several validation methods. Validation of communication protocols has several aspects which all are of practical importance but different in nature and must be attracted by different methods. - The objective might be to investigate if a specified service satisfies the user requirements. This validation task can often best be solved by letting the user try a simulation model or a rapid prototype of the service definition or the protocol. Another objective might be the validation that the specification of a proposed protocol meets a given service specification, i.e. to show that the protocol actually provides the specified service. This objective is important to meet, e.g. in the standardization of new communication services and protocols, or at an early stage in the design of proprietary protocols. Abstract properties are investigated before making detailed implementation specifications. This is the validation problem that we will discuss further in this tutorial. Yet another objective might be to test an implementation of a protocol entity. The purpose might be to test that the alleged protocol entity implementation actually conforms to the protocol specification, or that it can interoperate with other implementations. Validation by con-

-

-

formance testing has received a lot of attention lately due to the promotion of software product certification schemes. Interoperability testing, finally, is the ultimate test of interest for users in an inhomogeneous communication environment. Any method that increases the confidence in the correctness could be used as a validation method. Validation should be made as early as possible in the design process. As soon as new claims or design decisions are made, they should be validated. In that way, the cost of correcting errors is minimized. - In some cases, the only available method is to actually implement the protocol and test the implementation. Sometimes simulation is a better method, in the sense that it requires less effort and facilitates validation earlier in the design process. - In this paper, we will deal only with the verification of protocol specifications using formal methods. We will call such methods validation by verification or reasoning about properties. Such methods are often still better than simulation since they, when at all possible to use, give more definite information. - In a few cases, it is even possible to device automated design procedures which can be proven to always generate correct designs once and for all. Since this is still an area of research, we will not discuss such procedures here. By a formal method, we will mean a method based on strict rules for how to construct and assign meaning to specifications (syntax and semantics). There are several reasons to use formal methods. Beyond comprehensive and unambiguous specification, formal methods can provide support for validation in different phases of the design process. We will emphasise methods for which algorithms can be found so that programs can be written automating the validation phase. We will -

B. Pehrson / Protocol verification for 0S1

not, however, discuss tools. For some methods, tools are available and several projects are under way. A survey of tools and tool development projects can be found in [6]. Again, we will restrict our discussion to time-independent properties and only give some references to verification of performance aspects. The essence of a protocol is the behaviour of the communicating protocol entities and the underlying medium, i.e. the set of possible sequences of events that can occur when the entities execute. There are different approaches to specification of protocols and their properties. Behaviours are often specified in terms of some kind of transition system, e.g. state machines, nets, traces, etc. We will concentrate on transition systems which can be specified as communicating finite state machines. Protocol properties are often specified in terms of assertions associated with a transition system. The emphasis is put on properties related to the ordering of events. Protocol properties are classifed in the categories safety properties and livehess properties. Safety properties are properties that assure that no undesirable events will ever happen (e.g. deadlocks). Safety properties specify only what may or may not happen. Liveness properties assure that desired events will eventually happen (e.g. completion, recurrence, progress). Safety properties can be stated as invariant assertions associated with transition system models or as relations (simulation, bisimulation) between a proposed and a required behaviour. Liveness properties, in general, require temporal reasoning, e.g. in temporal logic. Since this is a tutorial, and not a survey, we have no intention to cover the state of the art completely. We have chosen our examples entirely from a pedagogical point of view, without special regard to completeness or to cover the milestones of the pioneering research. Our goal has been to discuss some principal formal specification methods which have proved to be useful in practical design, including verification, of communication protocols. The paper is an extension of a tutorial on protocol verification originally given at an IFIP conference 1988 [56]. 1.1. Exposition In section 2, basic notations used in the subsequent sections are introduced. We also discuss

187

how the notation can be used to specify a simple data link service and protocol which will be used through out the paper to illustrate some verification methods. In Section 3, we will discuss some verification techniques. First, we review classical reachability analysis of communicating finite state machines. This verification method has attracted much attention during the years and probably still is the most widely used. Many applications have been reported. Different refinements have been made to reduce the problem of state explosion, some of which will be discussed. The classical technique has during the last decade been formalised in algebraic frameworks sometimes referred to as process algebras. Some of these results will be discussed. In Section 4, we will apply the methods discussed in Section 3, to verify a data link protocol. In the methods discussed so far, liveness properties cannot readily be expressed. An approach to this problem is to add liveness conditions expressed as temporal logic formulas and check if the state transition system is a model for these formulas. The method is called model checking. It will be discussed in Section 5. In Section 6, we will discuss some more general methods which deal with infinite state spaces. The general concurrent program verification problem is considerably more complex than the finite state case. Other proof methods must be used, e.g. induction. The proof must be designed by hand and a certain ingenuity often is required to find the proof. It is beyond the scope of this tutorial to go into detail on these general verification methods. We will only give a short introduction and give pointers for further study. In the concluding section, we will point out some important aspects of protocol design not addressed in this paper, like real-time properties, dynamic communication patterns, etc. We will also discuss the relation between the techniques described in this paper and the standardised FDTs: EsteUe, LOTOS, and SDL.

2. Finite State Transition Systems Different formal methods provide different support for reasoning. It is therefore natural to discuss verification methods according to the un-

188

B. Pehrson / Protocol verification for OSI

Data link service

(~)Channell(~) (~) Channel2~ Fig. 3. A data link layer.

derlying formalism. Formalisms for systems with a finite state space take a special position. The verification methods can be based on an exhaustive exploration of the state space and it is often possible to find algorithms which make it possible to mechanically determine properties. Formal reasoning about protocols requires some sort of formal description of the protocol and its properties. The description should include the underlying service, and the service provided. In this section, we will define the basic notation and other concepts to be used in the following exampies. Notation. We will use a simple data link service and protocol to illustrate some of the verification methods. First, we will discuss some concepts that refer to the structure of a protocol. We refine Fig. 2 by dividing the medium into two uni-directional channels (Fig. 3). A Sender entity transmits messages to a Receiver entity via one channel. Acknowledgements are transmitted back by the Receiver to the Sender on the other channel. Each module in Fig. 3 represents a process. A process can have an associated behaviour a n d / o r consist of a parallel composition of subcomponent processes which may communicate with each other and also with the environment. In Fig. 3, the processes are: the service provided (the outer box), the protocol entities, and the medium channels which describe the underlying service. An important concept is that the service provided should "equal" the parallel composition of the entities and the channels. We will discuss what we mean by "equal" later. So far we can think of it as "being implemented by".

S is a set of states. We will concentrate on systems where S is finite. i ~ S is the initial state in which the system starts. E is a set of labels representing atomic events. The set E will here include communication events (i.e. input and output events) and internal events. Communication events represent interactions with the environment. They can occur at ports. Communication events are denoted p?m or p!m where p is the name of a port at which the event can occur, m is the value of a message, and ?, ! are the T / O designators: ? means input and ! means output. We will use the symbol r to represent internal events. - T is a set of labeled transitions, which is a subset of S × E × S. Each transition is a triple consisting of a state s ~ S, a label E ~ E, and a state s ' ~ S. This can be written s e s ' Intuitively, a transition means that the system, if its current state is s, can change its state to s ' when the event e occurs. We will use a graphical representation of transition systems. The graphical representation is shown in Fig. 4. A transition system is contained in a box. The ports are shown as small ovals on the box boundary. The port oval can contain the port name. States are represented by circles and transitions are directed arcs (arrows) labeled with the associated event. The initial state is indicated by means of a black token (see Fig. 4). -

Data link services. As a first example, we will discuss data link services. Later we will also discuss a data link protocol used to provide reliable data link services over media which consist of unreliable transmission lines. F r o m a user point of view, a data link service could be regarded as queue. Messages are enqueued in one end and can, after some delay, E x a m p l e :

2.1. Behaviour We define the behaviour of a process in terms of a finite-state labeled transition system. A transition system is a quadruple (S, i, E, T ) where

a)

b)

Fig. 4. A reliable data link service (a) and an unreliable transmission line (b).

B. Pehrson / Protocol verification for OSI

----
(D-----

189

Q

Q

a) b) Fig. 5. Description of reliable queues with 2 messagevalues and 1 place (a) and 2 places (b). become dequeued in the other end. First, we assume the capacity of the queue to be one message at time, and only one type of message. Then a simple specification of the data link service could look as Fig. 4(a). The m indicates the message value which is first accepted at port a and then delivered at port b. The internal event ( r ) firing a transition back to the initial state in Fig. 4(b), instead of delivering the message at the b-port, describes that the message may be lost. In this way, an unreliable transmission line can be represented. Some services may allow more than one message to be in transit simultaneously, in some cases even an unbounded number. However, only a bounded number could be handled using finite state descriptions. The example in Fig. 5 describes a reliable queue of capacity 1 in a) and capacity 2 in b), accepting two different message values, 0 and 1. The number of states increases rapidly when the capacity of the queue and the number of different messages increase. To make the graphical representation more comprehensive, a more expressive representation could be used involving variables and simple assignment operations. If the variables can only take a finite number of values, such a specification still represents a finite state transition system. Since the notation becomes more complex and needs more explanation, we will not discuss this further in this tutorial. The verification methods remain the same and are better illustrated using a simple notation. 2.2. Parallel Composition of Behaviours To be able to investigate the resulting behaviour of a transition system built from subcomponents, we formally define an operation called

parallel composition of transition systems as intuitively used above. The parallel composition of transition system is intended to represent that the processes, represented by the transition systems composed, run in parallel. Assume we have two transition systems TS 1 = ($1, i 1, E 1, 7"1) and TS 2 = ( S 2, i2, E2, T2), where E 1 ¢q E 1 = ~. T h e parallel composition, of TS 1 and TS 2, denoted TS 1 II TS2, is a new transition system, TS = (S, i, E, T ) , where - S = S 1 × $2 is the global state space. The states of the parallel composition are called global states. The global state representing that TS a is in state n and TS 2 is in state m is denoted (n, m). i ~ S = (i 1, i2) is the initial global state. E = E 1 U E 2 - E ' , where the coevent ( e 1, e2) E ' for all e 1 ~ E 1 and e 2 ~ E 2 such that e I and e 2 match, i.e. have the same port name and message value but opposite I/O-designator. Intuitively, coevents represent synchronisation events on ports where TS~ and TS 2 are interconnected. When a coevent occurs, the associated events occur simultaneously and are replaced by the internal event r. The c o m m o n value is considered to be passed. -

-

el -

T=((s,

el

r)-o(s',

e2

r) where s ~ s ' ~ T e2 r t

r) ~ (s, r ' ) where r --*

1, (s,

E T2, (s, r ) -~ ( s ' , e2 r ' r ' ) where s--->s ~ T 1 A r ~ ~ T 2 A (el, e2) E ' }. Intuitively, this defines the union of T1 and T2 except for synchronised transitions (coevents), which all are replaced by internal transitions. The definition above describes synchronous communication between TS1 and TS 2. The events in E ' represent synchronisation between TS~ and TS 2. If communication between TS~ and TS 2 is el

t

B. Pehrson / Protocol verificationfor OSI

190

asynchronous, there must be a buffering queue in between. Synchronisation involves an output event in one of the transition systems, and an input event occuring simultaneously in the other. If more than two ports can synchronise in a single coevent, we talk about multicasting or broadcasting. The simple value matching mechanism defined above is sufficient for our purpose. More general value matching, or value passing, mechanisms can be defined. The procedure to construct the composition from the components could in short be described as follows: to find the events and transitions of the parallel composition, we follow the following algorithm: From each global state, starting in the initial global state, we examine which events can occur in the components to be composed, and to which global state the corresponding transitions lead. F r o m each of these new global states we repeat this procedure until there is no more transition, or all states are already examined. Example: Composition of data link services. Let us, as an example, make a parallel composition of two queues of capacity one (Fig. 6 ) t o construct a queue of capacity two. The processes in Fig. 6 can initially accept a message (0 or 1) at port a, - synchronise at port c as a result of one of the coevents (c!0, c?0) or ( c ! l , c ? l ) , - either deliver the first message at port b and restart, or accept a second message at port a, - deliver the first message at port b and synchronise at port c to forward the second message, either deliver the second message at port b and restart, or accept a third message at port a, etc. Using the definition of the parallel composition, we can construct the global state space (see Fig. 7). Only internal events can occur on port c in Fig. 6. Therefore port c is not shown in Fig. 7. To find the events and transitions of the parallel composition, we start in the initial global state -

-

O

(-, .) where both places in the queue are empty. We examine which events can occur and to which state the corresponding transitions lead. F r o m each of these new states we repeat this procedure until there is no more transition, or all states are already examined. F r o m the initial global state (-, -), the left transition system of Fig. 6, can accept a message ( a ? 0 or a ? l ) from port a leading to the global states (0, -) and (1, .) respectively. The right transition system can accept a message at port c (c?0 or c?l). However, port c is connected to the left transition system, which cannot provide a synchronising output event. Thus the only transitions from initial state are the transitions from (-, .) to (0, -) when a?0 occurs, and to (1, -) when a ? l occurs. The first place in the queue is now occupied, while the second is still empty. We proceed to the state (0, .). We find the single event c]0 in the left transition system and the two events, c?0 and c?l, in the right system. The only synchronisation that can occur is (c!0, c?0). Since the both transition systems participate in the coevent, they will both change their states. The resulting internal event will lead to the global state (., 0). We get a similar result from (1, -). Now, the synchronising coevent is ( c ! l , c ? l ) . The result is an internal event to the global state (-, 1). The internal events reflect that the message is propagated from the first place in the 2-place queue (the left 1-place queue) to the second (the right 1-place queue). In each of the global states (., 0) and (., 1), three events can occur: the left transition system can accept a new message. Either a?0 occurs causing a transition leading to the states (0, 0) or (0, 1), or a ? l occurs causing a transition leading to state (1, 0) or state (1, 1). We now have two -

-

-

-

O

Fig. 6. Synchronouslycommunicatingprocesses.

B. Pehrson / Protocol verification for OSI

(E)'------

~

..

a?0

•

cQ

b!l

b~l

b!l

b!O1

~b!O

~ b!0

Fig. 7. The global state space resulting from the parallel c o m p o s i t i o n in Fig. 6.

messages in the queue. Thus it is full and the first message has to be delivered. - the left system can deliver the first message (b!0 or b!l), both transitions leading back to the initial state (., .). The queue is now empty again. - In the global states (0, 0), (0, 1), (1, 0), and (1, 1), the queue is full and the first message must be delivered, i.e. b!0 or b!l must occur and we get back to one of the states (0, .) or (1, .), which have already been examined. Since there are no more unexamined states, the global state space is complete. Although the example discussed here is simple, and although it is in principal trivial to derive the global state space, it is tedious to do so manually. However, the procedure is easily automated. We will later discuss a slightly more complex example describing a data link protocol implementing a service as described above. In the example discussed in this section, all states in the cartesian product of the state spaces of the components became part of the global state space. In the next example, this will not be the case.

3. Verification

Procedures

for Finite State Systems

3.1. Reachability Analysis In the process of forming the global state space as described above, a number of safety properties can be checked. Examples of safety properties which can be verified are absence of - unmatched communication events, e.g. due to incomplete specification, - deadlocks, i.e. global states from which no transition is possible,

191

- undesired loops, i.e. infinite loops in which no progress is made. This is called reachability analysis and means exhaustive exploration of all possible interactions between a set of communicating processes modeled as transition systems. It is a simple and straightforward method which is easily mechanized. The global state space, also called the reachability graph, of the set of interconnected transition systems is calculated and analysed.

3.2. Equivalences If we " h i d e " the synchronisation events in Fig. 7, the behaviour specified by the transition system seems "equal" to the behaviour of the two-place queue in Fig. 5(b). Observe that, if we merge the two pairs of states of the transition system in Fig. 7 that are joined by the internal unobservable transitions, we get exactly the same transition system as in Fig. 5(b) describing the two-place queue. We will discuss the concept of equivalence further below. The objective of verification of a protocol is to prove that the protocol provides the desirable service. One way towards this goal is to compare the specification of the protocol with the specification of the service. Comparing two specifications consists of proving that some relation holds between the specifications. Different relations captures different aspects of the specifications. The relations used can be fundamentally different type, e.g. equivalences (i.e. if two specifications are considered equivalent, then they cannot be told apart or they can be used interchangeably) or the relation can be an implementation relation (i.e. one specification implements an other if the first can mimic the behaviour of the second). Below we give examples and explain some relations which are used in verification of communication systems. An often used relation is the observation equivalence relation [48]. The intuition behind observational equivalence is that two specifications are considered observational equivalent if an external user cannot distinguish between them merely by repeated experiments. Observation equivalence between two processes is proven by the existence of a bisimulation relation between the state sets of the processes such that the initial states are related. If two states r and s are related by a bisimulation, then each transition of r can be

192

B. Pehrson / Protocol verificationfor OSI

g; a) observation equivalent processes

b) not observatk3n equivalentprocesses Fig. 8. Illustration of bisimulation.

simulated by a transition of s and vice versa. Her/ce the states r and s can never be distinguished by an external observer. In Fig. 8, we illustrate the bisimulation concept. The processes in Fig. 8(a), where ~- is an internal event, are observation equivalent. The final states simulate each other since no action is possible in any of them. The preceding states (2, 2b) simulate each other since only a b-event can occur and the corresponding transitions lead to states which simulate each other. Since an internal event is not observable, (2, 2 a ) are also observation equivalent. Finally, both initial states can simulate each other since the a-event is the only possible event in both cases, and the corresponding transitions lead to states which simulate eachother. The processes in Fig. 8(b) are not observation equivalent. Initially, an a-event can occur in both processes. In the states 2a or 2b, however, only one event, b or c, can occur. In state 2, both can occur after the initial a-event. Thus, 2 can neither be simulated by 2a nor 2b. In this example, the deadlock properties, i.e. the possibility to deadlock with other processes after a sequence of communication events, are different. To see this, consider a process P which after an a only accepts a b. The left process in Fig. 8(b) will never deadlock when communicating with P, but the right process might deadlock if its first transition is to state 2b. Observation equivalence.is sometimes unnecessarily strong, i.e. it discriminates between process which we would like to consider equivalent. In Fig. 8(b), the discrimination is motivated by the fact that the deadlock properties are different. In Fig. 8(c), a similar distinction cannot be made. Although the processes here are not observation equivalent, they are equivalent in the deadlock properties.

i

c) not observation equivalent processes

As indicated earlier, the process in Figs. 5(b) and 7, describing a queue of capacity two, and its implementation as a composition of the two queues of capacity one, are observation equivalent. The bisimulation relation can be written down as the set of pairs of states simulating each other:

= ((., (., .)), (o, (o, .)), (o, (., o)),

(00,

(0, 0)), (1, (1, -)), (1, (., 1)), (11, (1, 1)), (10, (1, 0)), (01, (0, 1))}.

An overview of methods to decide observation equivalence can be found in [9]. Such investigations are not easy to perform manually. Fortunately there are algorithms which can be implemented as computer programs which can be integrated in protocol design too!s, Anjexample of such a tool based on the process algebra CCS and Hennessy-Milner Logic is reported in [14]. An illustrate application of this concept to verification of the C S M A / C D medium access protocol is reported in [55]. A slightly relaxed equivalence is test equivalence [25]. The intuition is that two processes are test equivalent if they cannot be told apart by executing tests (i.e. sequences of interactions) on them. Test equivalence differs from observational equivalence in that test equivalence is not sensitive for where in the computations non-deterministic choices are made. A yet weaker equivalence is trace equicalence. Two specifications are considered trace equivalent if they can perform the same sequences of events. In Fig. 8, all examples are pairwise trace equivalent. In Fig. 8(a), the trace generated is ab, in Fig. 8(b) two traces are generated, ab or ac, while in Fig. 8(c), the traces are aab or aac. Trace equivalence does not discriminate between processes having different deadlock properties.

B. Pehrson / Protocolverificationfor OSI Implementation relations can be thought of as equivalences in one direction. If two processes are equivalent they can mimic each other in some way. If one process implements an other, then every thing the first process can do can be mimicked by the second, but the converse does not necessarily hold. 3.3. State Space Explosion

The difficulty with reachability analysis is the exponential complexity which leads to state space explosion: if n machines are composed in parallel and each has k states, the composition may have k" states. We will not discuss this problem in detail here. We will only point out some relief techniques that have been developed to deal with it, e.g. canonical sequences [59], projection [37], transition choice rules [4], different progress criteria [19,20], stochastic techniques [67], probabilistic techniques [47]. Some of these techniques are discussed in [43]. In [47], the basic state transition model is extended to include a probability function, which assigns choice probabilities, adding up to one, to outgoing transitions in every state in which there is a non-deterministic choice. The advantage of this partial state space exploration is that it concentrates on the most probable transition sequences. This provides a kind of confidence in the correctness which can be related to the reliability of the subsequent implementation, since it is not meaningful to spend more effort to increase the reliability of the protocol than of other components in the implementation, such as hardware. A discussion about the limits of reachability analysis can be found in [29]. He claims that his carefully designed validator handles protocol descriptions that generate 105-107 states in the order of minutes of CPU-time on a small size machine (Vax 11/750) and in the order of seconds of CPU-time on a larger machine (Cray). He concludes that this most likely covers a large fraction of practically interesting protocols. 3.4. Other Similar Methods

193

developed during the years and is probably still the most used method for protocol verification. Examples of protocols partially verified by traditional reachability analysis include X.21 [68], X.25 [5]. Examples of other similar approaches are [1,2,4,11]. Net Models There are many variations on the theme of reachability analysis. A variant of the transition system approach taken here, uses Petri nets with different extensions. Good surveys and discussions of Petri Net based methods for protocol verification can be found in [16] and [15]. Process Algebras Another framework, sometimes referred to as process algebra, has proved to be useful, both as formalization of the classical methods and as bases for a broader scope of properties to be analyzed, e.g. some of the various equivalences discussed above. One of these theories, the process algebra CCS [48], has played an important role in the development with ISO of LOTOS [32], a formal description language for OSI-protocols. Several applications of CCS to verification of synchronization aspects of realistic protocols have been reported.

4. Verification of the Alternating Bit Protocol In this section, we will apply the verification procedures discussed in the previous section. We will verify that a simple data link protocol provides a reliable data link service over unreliable media. The media consist of unreliable transmission lines, i.e. lines that can cause transmission errors, such as lost or garbled messages. The protocol is called the alternating bit protocol. The use of this protocol for demonstration has sometimes been criticised since it is too simple to illustrate the potential of the methods in applications of realistic complexity. However, since it is easier to understand basic principles from simple examples, we will discuss-how the methods scale up separately. 4.1. Service Specification

Some of the pioneering work in the field of protocol verification was based on reachability analysis [5,69]. The method has been refined and

As the specification of the data link service to be provided, we will use the specification shown in

194

B. Pehrson / Protocol verification for OSI

i ®

Q

Sender

Channels

I

Receiver

Fig. 9. The alternating bit protocol over an empty medium abstraction.

Fig. 4(a). As the specification of the service expected from the underlying medium, the unreliable transmission lines, we could use the specification in Fig. 4(b). However, we will make a small simplification to avoid an unnecessarily complex state diagram. This will be pointed out below. 4.2. Protocol Specification First, we will discuss the protocol design informally and then specify it formally (Fig. 9). In order to cope with an unreliable medium, the receiver has to acknowledge the receipt of correct messages. Garbled messages are detected by using some encoding techniques, e.g. CRC. Messages which cannot be corrected are discarded and treated as lost messages. To detect lost messages, each messages can be numbered sequentially. Periodically, until receiving an acknowledgement containing the same sequence number as assigned to the last sent message, the sender retransmits the message triggered by a time-out mechanism. When a message containing the same sequence number is received, the sender increments its state to the " n e x t sequence number to be assigned". Since also acknowledgements may be lost, the receiver has to retransmit acknowledgements until a message with the next sequence number arrives. Then, the receiver starts to acknowledge this new sequence number, and increments its state to the " n e x t expected sequence number". If the sender requires every message to be acknowledged before the next message is transmitted, only two values are needed for the sequence number, one for the latest acknowledged message and one for the latest transmitted mes-

sage. One bit, alternating between 0 and 1, is consequently sufficient to represent the sequence number. This fact has given the protocol its name [31. The description in Fig. 9 is similar but not identical to one of the examples in [5]. The transition system to the left represents the sender, the system to the right represents the receiver, and the systems in the middle represents the two channels of the underlying medium. We have again only one type of message represented by m. For the purpose of verifying the basic properties of the protocol, we do not have to distinguish between different messages. If we would include several message values, we would get more states in a similar way as illustrated in Figs. 4 and 5. Observe that we have reduced the description of each channel to contain just one state describing reception and delivery of a message as an atomic action. In the same transition, we have included two communication events. We have done this to simplify our example. The number of states is reduced substantially. The definition of parallel composition must be generalized to accomodate this generalization, which is straightforward. Since no message can stay in the channel, the simplification is called the empty medium abstraction. It can be used when it is unimportant how m a n y messages are in transit in the medium, or, as a first analysis of the protocol. However, to make a complete analysis, we also have to consider cases where one or more messages are in transit in the medium. Another way to simplify is to short-circuit the medium and identify its input and output ports. However, we might still want to include medium properties like unreliability, e.g. random loss of messages. Such properties could also be

195

B. Pehrson / Protocol verificationfor 0 S I



(Er

It is obvious that the transition system in Fig. 10 is different from the specification in Fig. 4(a). Yet, the transition systems are observation equivalent. Both figures describe an infinitely repeated sequence where the only externally visible events, a?m and b!m, alternate. The property that progress is eventually made, i.e. that we are not caught in a loop for ever, is a liveness property.

(1)

?m

fe(N~

rn

Fig. 10. Reachabilitygraph formed from Fig. 9.

included directly in the description of the protocol entities. When the sender enters the states labeled s, a message has been accepted at the a-port and is ready to be transmitted together with the associated sequence number. When the receiver enters the states labeled r, a message has been received from the sender and the transmission of an acknowledgement is pending.

4.3. Reachability Graph Figure 10 shows the reachability graph of the alternating bit protocol specification in Fig. 9. It is derived according to the algorithm discussed in the previous section. The ~--labeled looping transitions in each state represent loss and retransmission of messages and acknowledgements. To make Fig. 10 more readable, the internal events corresponding to transfer of messages and acknowledgements are labeled both with ~- and with the names of the involved ports (cd and re) and sequence numbers within parentheses.

4. 4. Safety properties In the procedure used to construct the reachability graph, we have verified that the protocol contains no unmatched communication events and no deadlocks. However, we can see that there are a number of infinite loops in which no progress is made. These loops represent the time-out triggered retransmissions of messages and acknowledgements.

4.5. Liveness Properties The methods discussed in this section, deal with safety properties only. Sometimes, the possibility of desired events to happen is also referred to as a liveness property. The more orthodox standpoint is that a liveness property is present only if it can be proved that the desired events actually will happen. Such properties depend on assumptions that progress is eventually made from a state, and sometimes that an unproductive loop is eventually exited. These assumptions cannot be formulated with the method in this section. Verification of liveness in the orthodox sense will be discussed in Section 5.

5. Model Checking

in

Temporal Logic

The model checking approach to verification of finite state systems [12,42,65] can be regarded as an extension of the methods discussed in the previous section: propositional temporal logic formulas are used to specify desirable protocol properties associated with states and sequences of states in the global state transition system describing the protocol. There are two important advantages to be gained from this method: - it provides a more abstract way to specify and reason about properties than do pure transition systems, which are prone to overspecification. it provides means to specify and reason about liveness properties in the orthodox sense, i.e. that a liveness property is present only if it can be proved that the desired events actually will happen.

5.1. Temporal Logic Temporal logic is a modal logic, i.e. a logic which distinguishes among different states by using

196

B. Pehrson / Protocol verification for 0S1

modal operators that make it possible to speak about a proposition being true, e.g. now (in the current state), eventually (in some state which will eventually be reached), henceforth (in every subsequent state), from the next state and henceforth, etc. There are two main variants of temporal logic, branching time and linear time. The basic difference is that linear time temporal logic considers each execution sequence individually, while the branching time temporal logic deal with all computation sequences at once. Thus In the linear time variant, systems are denoted as sets of sequences, i.e. linear time logic has a trace-oriented semantics. - T h e branching time denotations additionally contain information, e.g. about the relative order of non-deterministic choices. The semantic model is tree-oriented. The pros and cons of linear versus branching time temporal logic have been debated for almost ten years, and there is yet no consensus on how they relate or which is best for the purpose of protocol verification. In our discussion here, we will use the concepts defined by Clarke, Emerson and Sistla [12]. They define a propositional branching time temporal logic called computation tree logic (CTL). We compose a CTL specification from a set of atomic propositions. Informally, these propositions can be thought of as expressing meaningful statements which should be true or false at states in the global state space of a parallel composition of transition systems. In our example in Fig. 10, there are two atomic propositions: s which is true in two global states, and r which is true in two other global states. The intuition behind these propositions is s --- " a message has been accepted at the a-port and is ready to be transmitted together with the associated sequence number", r = " a message has been received from the sender and the transmission of an acknowledgement is pending". A desired property of the protocol is that after s is true, r will become true eventually. We can formulate and prove this property in CTL, as will be demonstrated below. Formally, CTL formulas are interpreted on (Kripke) structures which represent the possible -

-

-

-

-

-

-

states that a system can reach. A structure is a tuple M = (S, i, P, T), where S is a set of states and each state is a set of atomic propositions, i ~ S is an initial state, P is an assignment of true atomic propositions to each state, and T is a binary relation on S describing possible transitions. If we compare this definition of a structure with our definition of a transition system in Section 2, we can think of a structure as a transition graph, but the transitions are unlabeled. Instead the states are labeled with atomic propositions. CTL formulas can be used to represent specifications. We can compose more complex CTL formulas from atomic propositions using the ordinary logic operators -~ and A. CTL also provides modal operators: First there are path-operators which are common to linear and branching time model logics. Note that these formulas express properties of paths and not states: G f is true of a path if f is true in each state along the path, F f is true of a path if f is true in some state along the path, X f is true of a path if f is true at the successor of the initial state of the path, - f U g is true of a path if g eventually becomes true in a path and f is always true till then. In order to use the formulas above on states, we have the following two state-operators, specific for branching-time modal logic: A f is true in a state s if f is true of all paths starting at s, E f is true in a state s if f is true of some path starting at s. So, for example, the following operators can be derived: AFf intuitively means that f holds in the future along every path, i.e. f is inevitable, E F f means that there is some path leading to a state in which f holds, f is potentially true, - E G f means that there is some path on which f holds, - A G f means that f holds at every state on every path, i.e. f holds globally. The semantics of some of these operators is illustrated in Fig. 11. Using the operators we can express properties in terms of temporal logic formulas, e.g. - no deadlock exists: AG -~ deadlock, - a deadlock exists: EF deadlock, -

-

-

-

-

-

-

197

B. P e h r s o n / P r o t o c o l verification f o r O S I

Fig. 11. Representation of some simple correctness properties inCTL(O=p, o =-p).

sage also consists of just one bit and can take the values 0 and 1. The model of the alternating bit protocol in Fig. 9 has to be extended accordingly. Here, we introduce the following four new atomic propositions: the message to be sent is 0: m s = 0, the message to be sent is 1: m s = 1, the message received is 0: m r = 0, the message received is 1: m r = 1. The following C T L formulas imply that sending a message (s) strictly alternates with receiving a message ( r ) and that the same message is received (mr) as was sent (ms): -

-

a sent message will be received: AG (sent ---}AF received). To determine if a formula is true in the structure M, it has to be evaluated in each state. Each state is labeled with the set of subformulas that are true in the state, starting in stage 1 with subformulas of length 1, then stage 2 with subformulas of length 2, etc. This procedure can easily be automated. A discussion about methods to reduce the problem of state space explosion when forming the global state space can be found in [13]. -

5.2. Example: The Alternating Bit Protocol in CTL The structure used in [12] to specify the alternating bit protocol corresponds to a state transition system, specified as a CSP program, and two atomic propositions, s and r. It is similar to our example in the Figs. 9 and 10. The two atomic propositions correspond to the labels s (a message has been received from the data link user and is ready to be transmitted to the receiver) and r (a message has been received from the sender and the transmission of an acknowledgement is pending). We want to prove that sending a message strictly alternates with receiving a message and that the same message is received as was sent. This alternation is expressed in the following proposition: p = " i f r becomes false, then s must become true before r becomes true again". To prove that s and r alternate is straightforward according to the procedure described above. To prove that the same message is received as was sent, we have to distinguish between different messages submitted, as opposed to the case illustrated in Fig. 10, since the alternating bit mechanism is supposed to be hidden from the user. As C T L is a propositional logic (allowing only atomic propositions, no quantifiers over variables), we have to repeat the proof for each possible message. For simplicity, it is assumed that the mes-

-

-

A G ( r ---}A[r U ( ~ r A A [ ~ r U s])]), A G ( s A m s = 0 --, A[s U (-~s A A [ ~ s U r A

m

r =

0])]),

A G ( s A m s = 1 --, A[s U (-~s A A [ ~ s U r A m r = 1])]).

Unfortunately, it is not trivial to get an intuitive feeling about the meaning of the formulas. Roughly, they say - if r is true, then r will remain true until it becomes false and once false, it will stay false until s becomes true, if s is true and the message to be sent is 0, then s will remain true until it becomes false and once false, it will stay false until r becomes true and the received message is 0, if s is true and the message to be sent is 1, then s will remain true until it becomes false and once false, it will stay false until r becomes true and the received message is 1. The reader is encouraged to interpret the propositions by drawing trees. A discussion about the expressiveness of temporal logic can be found in [621. -

-

5.3. Fairness and Liveness Let us now return to the improductive loops in Fig. 10. We would like to assume a fairness property, e.g. if we infinitely often come to a state from which there are two transitions, we will infinitely often pick both transitions. In an extended version of CTL, fairness predicates are used to select only fair paths in the definition of A f and E f . The fairness predicates can be used to express conditions that must hold infinitely often. The fairness constraints are formulated as a set of states. Any infinite path has to pass these states infinitely m a n y times. In our example the states labeled s and r are included in the fairness constraints. If

198

B. Pehrson / Protocol verificationfor OSI

only fair paths are considered, the conjunction of the three formulas can be shown to be always globally true. This intuitively means that a messages cannot be garbled or lost each time transmitted. 5.4. Other Similar Methods

Richier et al. [58] use a method in the Xesar system which is very similar to C T L . Vardi and Wolper [65] discuss the model checking method using a linear time temporal logic. It is applied to reasoning about probabilistic concurrent programs. Sabnani [61], extends the model checking approach by allowing propositional temporal logic specifications of the components of the protocol to be verified, not only the conditions the protocol has to satisfy. Parrow [54] takes a slightly different approach. Rather than checking a transition system against a temporal logic formula, temporal logic is integrated into the transition system calculus (CCS) to specify and reason about properties which are not easily expressed otherwise. The method is used to verify safety and fairness properties of the medium access protocol C S M A / C D [31]. Hennessy and Milner [26] have developed a modal logic especially designed to reason about properties of processes in CCS. This logic has recently been used to do model checking in CCS [64]. The tool described in [14] supports both checking of equivalences between processes in CCS and model checking in HML.

6. Infinite State Spaces

In special cases, it is possible to find proof methods, and even to prove decidability of some properties also in the infinite state space case. One such special case is if we allow an infinite number of messages in our channels of the alternating bit protocol in Fig. 9. Larsen and Milner [41] use this example to illustrate a compositional proof method for communicating systems. Due to symmetry and regularity, it is possible to reduce the number of different channel states to be investigated to a finite number. The same example is generalized by

Holmstr/Sm [28] who specifies the channels in Hennessy-Milner logic. Again, the same example is used by Pachl [53], who introduces a formalism for reasoning about the contents of the communication channels, called channel expressions. The underlying theory is related to reachability analysis and can be used to prove a decidability result about deadlock detection in communicating finite state machines. The author assumes, however, that any algorithm would be too slow to be of interest in practice. Finkel [17] extends the class of manageable infinite state space cases along similar lines using monogenuous FIFO-nets to specify the channels. The general concurrent program verification problem is considerably more complex than the finite state case. We will only give pointers for further study. A good exposition of basic concepts can be found in [21]. Floyd's approach to reasoning about sequential programs [18] was formulated by Hoare [27] in an axiomatic framework, which was extended by Manna and Pnueli [44] to deal with termination. Owicki and Gries developed the axiomatic approach of Hoare to include concurrent programs [51]. Other methods to reason about safety properties of concurrent programs were developed, e.g. by [36,38]. Later, temporal logic was combined with some of these frameworks to deal with liveness properties, e.g. in [22,45,52]. The ingredients, when verifying parallel programs in these methods, are inference rules for the constructs of the programming language; invariants expressing the safety properties of the program, e.g. in terms of logic formulas that must be satisfied always, and liveness assertions which are usually proven by induction over well-founded sets. Several frameworks that are based on the same fundamental principles, and integrate transition systems, classical logic and temporal logic more intimately, have been developed later, e.g. in [34,39,50,57]. A tutorial introduction to some of these concepts can be found in [40].

7. Conclusions and Trends

We have discussed some different approaches to protocol verification. The formal description techniques used are state transition systems and assertional techniques based on logic.

B. Pehrson / Protocol verification for OSI

In the case when a protocol can be described with a finite state space, algorithmic verification of safety and liveness of behaviour is possible. According to Holzmann [29] most realistic applications fall into this category. A number of successful applications of realistic size has been reported. Tools supporting such algorithmic methods are being developed [6]. Careful structuring of the specification to be verified is vital to decrease the complexity and facilitate verification. This conclusion is made from a theoretical analysis, e.g. in [63] where changes in the H D L C protocol are proposed. The experience from a large industrial protocol standardization project confirms this view [24]. In the case of an infinite state space, the methods require more intimate knowledge both about proof method, and about the design to be verified. Proofs are not always possible to find. Further research is needed to make these methods more widely available. So far, we have discussed verification without questioning its role in the design process. To have something to verify, we must come up with a design. Of course, it would be better to develop provably correct synthesis procedures which could be used to derive protocol specifications from specifications of the service to provide and the service available. However, the synthesis problem is much more difficult to solve, and we instead have to use all methods available to increase our confidence in a specification before its implementation. Until synthesis techniques are available, design for verifiability should be part of the design methodology. Also, there are other interesting protocol properties to verify, which we have not discussed in this tutorial, e.g. related to time and performance. Several authors have presented different approaches to specification and reasoning about time and performance, e.g. in [46, 60, 63, 70]. Another thing which we have not discussed so far, is the relation between the concepts used here to support verification, and the standardised formal description languages Estelle, LOTOS and SDL [10,32,33]. With some variation, these languages are more complete specification languages, designed to allow the user to express all the details needed in an implementation specification. The techniques discussed in this tutorial do not provide an alternative. They rather provide a comple-

199

merit to be used to verify more abstract properties of a protocol in the process of deriving a more concrete specification. A new trend in reasoning about protocols is to use concepts and methods introduced in the area of knowledge based systems. Some early work in this area can be found, e.g. in [35,49]. A final conclusion of this discussion is that the emerging formal verification techniques are mature enough to improve the industrial design process, integrated with conventional methods, and especially in the early stages of design. Standardised languages and tools should be reviewed to take advantage of this fact. Time and money can be saved in design, reuse and maintenance, and the end products become more reliable.

References [1] S. Aggarwal, D. Barbara and K.Z. Meth, SPANNER - A Tool for the Specification, Analysis, and Evaluation of Protocols, IEEE Trans. Software Engrg. (December 1987). [2] S. Aggarwal, R.P. Kurshan and K. Sabnani, A Calculus for Protocol Specification, and Validation, in: Proc. IFIP Int. Conf. on Protocol Specification, Testing and Verification 111, ZUrich (North-Holland, Amsterdam, 1984). [3] K.A. Bartlett, R.A. Scantlebury and P.T. Wilkinson, A Note on Reliable Full-duplex Transmission over Halfduplex Links, Comm. A C M 12 (5) (1969) 260-261. [4] T.P. Blumer and D.P. Sidhu, Mechanical Verification and Automatic Implementation of Protocols, in. Proc. A CM SIGCOMM (1983). [5] G.V. Bochmann, Finite State Description of Communication Protocols, Comput. Networks 2 (1978) 361-372. [6] G.V. Bochmann, Usage of Protocol Development Tools: The Results of A Survey, in: Proc. IFIP Int. Conf. on Protocol Specification, Testing and Verification VII, ZUrich (North-Holland, Amsterdam, 1988). [7] G.V. Bochmann, Specification of Protocols, IFIP Int. Conf. on Protocol Specification, Testing and Verification 11111, Atlantic City (North-Holland, Amsterdam, 1989); revised version in Comput. Networks 1SDN Systems 18 (1989/90) 167-184, this issue. [8] G.V. Bochmann and C. Sunshine, Formal Methods in Communication Protocol Design, IEEE Trans. Comm. 28 (4) (1980). [9] T. Bolognesi and S.A. Smolka, Fundamental Results for the Verification of Observational Equivalence - A Survey, in: Proc. IFIP Int. Conf. on Protocol Specification, Testing and Verification VII, Zi~rich (North-Holland, Amsterdam, 1988). [10] CCITT, SDL - System Description and Definition Language, CCITT Recommendation Z. 100, CCITT, Geneva, 1988. [11] A. Chung, D. Sidhu and T. Blumer, Automated Validation of Protocols using EDS, IFIP Int. Conf. on Protocol

200

B. Pehrson / Protocol verification for OSI

Specification, Testing and Verification 111, Atlantic City, 1988. [12] E.M. Clarke, E.A. Emerson and A.P. Sistla, Automatic Verification of Finite-State Concurrent Systems using Temporal Logic Specifications, A C M TOPLAS 8 (2) (1986). [13] E.M. Clarke and O. Grtimberg, Avoiding the State Explosion Problem in Temporal Logic Model Checking Algorithms, in: Proc. 6th Annual A C M Syrup. on Principles of Distributed Systems, Vancouver (1987). [14] R. Cleveland, J. Parrow and B. Steffen, A. Semantic-Based Verification Tool for Finite-State Systems, in: Proc. IFIP Int. Conf. on Protocol Specification, Testing and Verification IX, Enschede (North-Holland, Amsterdam) to appear. [15] J.P. Courtiat, J.M. Ayache and B. Algayres, Petri Nets are Good for Protocols, in: Proc. A C M SIGCOMM (1984). [16] M. Diaz, Modeling and Analysis of Communication and Cooperation Protocols using Petri Net Based Models, in: Proc. IFIP lnt. Conf. on Protocol Specification, Testing and Verification 11, Idlewyld (North-Holland, Amsterdam, 1982). [17] A. Finkel, A New Class of Analyzable CFSMs with Unbounded FIFO Channels, in: Proc. IFIP Int. Conf. on Protocol Specification, Testing and Verification VIII, Atlantic City (North-Holland, Amsterdam, 1989). [18] R.W. Floyd, Assigning Meaning to Programs, in: Proc. Syrup. in Applied Math. X I X (American Math. Society, Providence, RI, 1967) 19-32. [19] M.G. Gouda and J.-Y. Han, Protocol Validation by Fair Progress State Exploration, Comput. Networks I S D N Systems 9 (1985) 353-361. [20] M.G. Gouda and Y.T. Yu Protocol Validation by Maximal Progress State Exploration, IEEE Trans. Comm. 32 (1) (1984) 94-97. [21] B.T. Hailpern, Verifying Concurrent Processes Using Temporal Logic, Lecture Notes in Computer Science 129 (Springer, Berlin, 1982). [22] B.T. Hailpern and S.S. Owicki, Modular Verification of Computer Communication Protocols, 1EEE Trans. Comm. 31 (1) (1983). [23] F. Halsall, Data Communications, Computer Networks and OSI, (Addison-Wesley, Reading, MA, 2rid ed., 1988). [24] H. Hansson, F. Orava and B. Pehrson, Specification and Validation of Services and Protocols for a Public Land Mobile ISDN System, I E E E / E U R E L 8th European Conf. on Electrotechnics, Stockholm, 1988. [25] M. Hennessy, Algebraic Theory of Processes (MIT Press, Cambridge, MA, 1988). [26] M. Hennessy and R. Milner, Algebraic Laws for Non-Determinism and Concurrency, J. A C M 32 (1) (1985). [27] C.A.R. Hoare, AN Axiomatic Basis for Computer Programming, Comot A C M 12 (10) (1969). [28] S. Holmstrt~m, Hermessy-Milner Logic with Recursion as a Specification Language and a Refinement Calculus Based on it, Report 44, Programming Methodology Group, Chalmers Institute of Technology, Gothenburgh, 1988. [29] G.J. Holzmarm, On Limits and Possibilities of Automated Protocol Analysis, in: IFIP Int. Conf. on Protocol Specification, Testing and Verification Vll, Ziirich (North-Holland, Amsterdam, 1988). [30] ISO, The Reference Model of Open System Interconnection, ISO International Standard IS 7498.

[31] ISO, Local Area Networks CSMA/CD Access Method and Physical Layer Specification, ISO/TC97/SC6, 1984. [32] ISO, LOTOS - A Formal Description Technique Based on the Temporal Ordering of Observational Behaviour, ISO International Standard IS 8807. [33] ISO, EsteUe - A Formal Description Technique Based on an Extended State Transition Model, ISO International Standard IS 9074. [34] B. Jonsson, Modular Verification of Asynchronous Networks, in: Proc. 6th Annual A C M Syrup. on Principles of Distributed Systems, Vancouver (1987). [35] G. Juanole, O. Amyay, P. Azema, R. Gustavsson and B. Pehrson, Towards a Knowledge Base for Design of (N) Service/Protocol Pairs-An epistemic approach, EUTECO 88 (North-Holland, Amsterdam, 1988). [36] R.M. Keller, Some Theoretical Aspects of Applicative Multiprocessing, in: Proc. 9th FOCS, Ryzyna, Lecture Notes in Computer Science 88 (Springer, Berlin, 1980) 58-74. [37] S.S. Lam and A.U. Shankar, Protocol Verification via projections, IEEE Trans. Comm. 10 (4) (1984) 325-342. [38] L. Lamport, Proving the Correctness of Multiprocess Programs, IEEE Trans. Software Engrg. 3 (2) (1977). [39] L. Lamport, Specifying Concurrent Program Modules, A C M TOPLAS 5 (2) (1983) 190-222. [40] L. Lamport, A Simple Approach to Specifying Concurrent Systems, SRC Report #15, Digital Systems Research Center, 1986. [41] K.G. Larsen and R. Milner, A Complete Protocol Verification using Relativized Bisimulation, LFCS Report ECS-LFCS-86-13, Department of Computer Science, University of Edinburgh, 1986. [42] O. Lichtenstein and A. Pnueli, Checking that Finite State Concurrent Programs Satisfy Their Linear Specifications, in: Proc. 12th A C M Syrup. on Principles of Programming Languages, New Orleans (1985) 97-107. [43] F.J. Lin, P.M. Chu and M.T. Liu, Protocol Verification Using Reachability Analysis, The State Space Explosion Problem and Relief Strategies, A C M SIGCOMM 1987, Comput. Comm. Rev. 17 (5) (1987). [44] Z. Manna and A. Pnueli, An Axiomatic Approach to Total Correctness of Programs, Acta Inform. 3 (1974) 243-263. [45] Z. Manna and A. Pnueli, The Temporal Framework for Concurrent Program, in R.S. Boyer and J.S. Moore, eds., The Correctness Problem in Computer Science (Academic Press, New York, 1981) 215-274. [46] G. Masapati and G. White, Algorithms for the Reduction of Timed Finite State Graphs, A C M SIGCOMM 1987, Comput. Comm. Rev. 17 (5) (1987). [47] N.F. Maxemchuk and K. Sabnani, Probabilistic Verification of Communication Protocols, in: Proc. 1FIP Int. Conf. on Protocol Specification, Testing and Verification VII, Ziirich (North-Holland, Amsterdam, 1988). [48] R. Milner, Calculus for Communication and Concurrency (Prentice-Hall, Englewood Cliffs, NJ, 1989). [49] G. Neiger and S. Toueg, Substituting for Real Time and Common Knowledge in Asynchronous Distributed Systems, in: Proc. 6th Annual A C M Syrup. on Principles of Distributed Systems, Vancouver (1987). [50] V. Nguyen, A. Demers, D. Gales and S. Owicki, A Model and Temporal Proof System for Networks of Processes, Distrib. Comput. I (1986) 7-25.

B. Pehrson / Protocol verification for OSI

[51] S.S. Owicki and D. Gries, Verifying Properties of Parallel Programs, Comm. A C M 19 (5) (1976) 279-285. [52] S.S. Owicki and L. Lamport, Proving Liveness Properties of Concurrent Programs, A C M TOPLAS 4 (3) (1982) 455-495. [53] J. Pachi, Protocol Description and Analysis Based on a State Transition Model with Channel Expressions, in: Proc. IFIP Int. Conf. on Protocol Specification, Testing and Verification VII, Ziirich (North-Holland, Amsterdam, 1988). [54] J. Parrow, Fairness Properties in Process Algebra, Ph.D. Thesis, Uppsala University, 1986. [55] J. Parrow, Verifying a CSMA/CD-protocol with CCS, in: Proc. IFIP Int. Conf. on Protocol Specification, Testing and Verification VIII, Atlantic City (North-Holland, Amsterdam, 1989). [56] B. Pehrson, Tutorial on Verification of Protocols, in: Proc. IFIP Int. Conf. on Protocol Specification, Testing and Verification VIII, Atlantic City (North-Holland, Amsterdam, 1989). [57] J. Reed and R. Yeh, Specification and Verification of Liveness Properties of Cyclic, Concurrent Properties, A C M TOPLAS 10 (1) (1988). [58] J.L. Richier, C. Rodrigues, J. Sifakis and J. Voiron, Verification in Xesax of the Sliding Window Protocol in: Proc. IFIP Int. Conf. on Protocol Specification, Testing and Verification VII, Z'tirich (North-Holland, Amsterdam, 1988). [59] J. Rubin and C. West, An Improved Protocol Validation Technique, Comput. Networks 6 (1982) 65-73. [60] H. Rudin, From Formal Protocol Specification Towards Automated Performance Prediction in: Proc. IFIP Int. Conf. on Protocol Specification, Testing and Verification III, Ziirich (North-Holland, Amsterdam, 1983).

201

[61] K. Sabnani, An Algorithmic Technique for Protocol Verification, IEEE Trans. Comm. (August 1988) 924-931. [62] R.L. Schwartz and M. Melfiar-Smith, From State Machines to Temporal Logic: Specification Methods for Protocol Standards, IEEE Trans. Comm. (December 1982). [63] A.U. Shankar and S.S. Lain, An HDLC Protocol Specification and Its Verification Using Image Protocols, A C M TOCS I (4) (1983). [64] C. Stifling and D. Walker, Local Model Checking in the Modal Mu-calculus, in: Proc. TAPSOFT 1989, Lecture Notes in Computer Science 351 (Springer, Berlin, 1989) 369-383. [65] M.Y. Vardi and P. Wolper, An Automata-Thooretic Approach to Automatic Program Verification, in: Proc. IEEE Syrup. on Logic in Computer Science, Cambridge (1986). [66] C. Vissers and L. Logrippo, The Importance of the Service Concept in the Design of Data Communication Protocols, in: Proc IFIP Int. Conf. on Protocol Specification, Testing and Verification V, Toulouse-Moissac (North-Holland, Amsterdam, 1986). [67] C. West, Protocol Validation by Random State Exploration in: Proc. IFIP Int. Conf. on Protocol Specification, Testing and Verification VI, Montreal (North-Holland, Amsterdam, 1987). [68] C.H. West and P. Safiropulo, Automated Validation of a Communication Protocol: The CCITT X.21 Recommendation, I B M J. Res. Develop. 2 (1978) 60-71. [69] P. Zafiropulo, C. West, H. Rudin, D.D. Cowan and D. Brand, Towards Analyzing and Synthesizing Protocols, IEEE Trans. Comm. 28 (4) (1980). [70] J.J. Zic, Extension to Communicating Sequential Processes to Allow Protocol Performance Specification, A CM SIGCOMM 1987, Comput. Comm. Rev. 17 (5)(1987).