Behavioural approach to

OSI system design

Vincenza Carchiolo*, Antonella Di Stefano*, Alberto Faro* and
Giuseppe Pappalardo*tt propose a behavioural formal description technique
for OSI protocol description

An informal approach to OSI design is apt to cause errors

The wide range of requirements posed by protocol design
that will manifest themselves as unexpected or undesired
is not accommodated by any single extant formal descrip-
behaviour in the implementation - it is now commonly
tion technique. As a solution, the behavioural language
agreed that formal techniques are to be preferred . A
LIPS is proposed, the use of which is illustrated in four
Formal Description Technique (FDT) suitable for OSI
typical design steps : specification, verification, simulation
protocol description must assist the designer in all of the
and performance evaluation .
above four design steps . Moreover, owing to the size and
complexity of OSI protocols, the applicability of FDT is
Keywords : open systems interconnection, protocol design,
strongly linked to the existence of tools that can make
formal description technique, language
design, to a great extent, automated, e .g. tools for
verification' or simbolic simulation 2.
Many FDTs have been proposed in the literature (a
review of them is outside the scope of this paper -
The spread of computer networks has resulted in growing
comprehensive surveys can be found in References 3-6).
interest in the implementation of distributed architec-
Extant FDTs fail to accommodate the wide range of
tures, together with their related complex communica-
requirements posed by the above steps - even the
tion protocols . By far the most popular is Open Systems
standard FDTs ESTELLE 7 and LOTOS8 do not cater for
Interconnection (OSI), a standard layered architecture
performance analysis. As an answer to this problem the
defined by the International Standards Organization
Language for Interacting Parallel Processes (LIPS) 9 is
(ISO).
proposed, based on Milner's Synchronous Calculus for
OSI system design consists in defining, for each layer of
Communicating Systems (SCCS) 10.
the architecture, the protocol that provides the service
required of the layer . For each layer, this design can be
viewed as consisting of four main steps :
LIPS
1 Specification of the protocol and services relating to
the layer. LIPS is a behavioural FDT for synchronous and asyn-
2 Verification of the protocol with respect to the chronous systems . In the framework provided by LIPS, an
services it is expected to provide . observer views a system, also called a process in the
3 Simulation of the behaviour of a set of entities that sequel, as a black box whose interface with its environ-
interact in accordance with the protocols . ment is represented by a set of gates . The observer is
4 Performance analysis . provided with a discrete-time clock, and at each time unit
sees the process make either offers to communicate with
'Instituto di Informatica e Telecomunicazioni, FacoltA di Ingegneria, the environment, or no offer at all . Communication offers
University di Catania, Viale Andrea Doria 6, 95125 Catania, Italy and their absence are both referred to as actions; in
tComputing Laboratory, University of Newcastle-upon-Tyne, Claremont
Tower, Claremont Road, Newcastle-upon-Tyne NE1 7RU, UK
particular, the absence of offers is called the idle action,
t University d i Reggio Calabria, Via Zecca 2,89100 Reggio Calabria, Italy and is denoted by I (not to be confused with the integer
0140-3664/88/060291-08 $03.00 C 1988 Butterworth & Co (Publishers) Ltd

vol 11 no 6 december 1988 291



1) . In LIPS, the behaviour of a process is specified through
the ordering in time of the process' actions .
An input and an output action taking place at gate g are
denoted respectively by g and g; they can be regarded as
simple actions. Act, the set of actions, is endowed with a
dot product intended to denote the simultaneous
occurrence of several actions, e .g. a • b is the action given
rise to by the simultaneous occurance of actions a and b . If
a and b are simple actions, they are said to be the factors
of the compound action a • b .
Owing to its intended meaning, the product must
be commutative and associative . Moreover, the idle
action 1 maybe regarded as simultaneous with any action,
and accordingly 1 is taken to be the unity for" • ". Finally it
is assumed that for each action a E Act, there is an inverse
a E Act such that a • a = 1 . The above properties imply
that (Act, • ,1, -) is an abelian group . As suggested by the
notation, the simple actions g and g are defined to be the
inverse of each other, and therefore, by a standard
property of abelian groups, the factors of a are the inverse
of the factors of a .
LIPS processes are built with operators which can be
divided into basic and derived, the latter aimed at making
the representation of OSI protocols easier. The semantics
of basic operators is given in Table 1, in terms of inference
rules for the relation -a (P-a -). Q means that process
P can perform action a and become Q at the next time
unit) ; derived operators are defined in Table 2 in terms of
the basic ones. An informal introduction is provided
below.
Action
For each action a E Act and process P, (a :P) is the process
which performs a, followed, after one time unit, by the
behaviour of P.
Choice
If P and Q are processes, P + Q denotes a process offering
to behave either like P or like Q . Thus, the choice operator
can be used to model non-determinism in process
behaviour . Note that action binds tighter than choice, so
that a :P+Q=-(a :P)+Q.
Product
P*Q represents the synchronous parallel evolution of
processes P and Q . At each time unit P*Q offers the
actions resulting from the product a • b of any two actions
a and b offered at that time unit by P and Q respectively .
Note that if the input g is a factor of a, and the output g is a
factor of b (or conversely), so that g • g = 1, neither g nor g
will be a factor of a • b . This is interpreted as an instance of
communication taking place between P and Q at their
Table 2 . LIPS derived operators
Operator and syntax Definition
Exponentiation 1 T :P 1T :P = 1 : IT-1 :p (T > 1)
1' :P = 1 :P
Delay SP SP = (1 :SP) + P
SP S„P=(1 :S„_1P)+P (n>0)
S OP = P
Timeout PO„Q PO„Q=P+1 :(P9 i _ 1 Q) (n>0)
Pe% Q=Q
common gate g, invisibly to the environment . On the
other hand, if Q offers, besides b, an action b1 that does
not contain the factor g, then g will be a factor of a • b1 .
Thus, P*Q permits P and Q to use their common gates to
communicate invisibly to the environment, but does not
conceal these gates from the environment .
Restriction
Given a gate setG, the unary postfix operator\G is defined
as follows : if P is a process, P\G behaves like the process
obtained from P by pruning away any subprocess that
starts with an action having at least one factor at a gate
in G .
The combination of product and restriction in (P*Q)\G
describes the concurrent behaviour of P and Q communi-
cating through their common gates, with a subset G of
these made internal, i .e . concealed from the environ-
ment. This may be better understood from the expansion
theorem 10, by which the behaviour of (P*Q)\G can be
expressed in terms of action and choice : let P = Eip i :Pi
and Q = Eigi :Qi, then (P*Q)\G = E (pi • qi :((Pi*Qi) I pi • qi
has no factors at gates in G J where denotes observa-
tional equivalence (see below) .
Process definition
The declaration p : = P, where p is an identifier and P may
contain p, makes p a process that can stand for P .
Thus, non-terminating behaviour may be represented,
e .g. p : = a :p defines a process p that cyclically performs
the action a.
Inaction
The inaction process 0 cannot execute any action ; 0 is
'destructive' with respect to time, in that P*O = 0 for all
processes P.
Some useful derived operators, based on the four main
ones and increasing the suitability of SCCS for protocol
specification, are presented by Carchiolo et al .9 . Here
attention is restricted to exponentiation, delay and
timeout.

Table 1 . LIPS basic operators Exponentiation

If P is a process, l T : P represents the process that idles for T
Operator and syntax Premise Conclusion time units before behaving like P .
Action a :P None a :P-a-. P
Delay
Summation P + Q P-a- P' P + Q-a-P' S n P (resp. SP) can wait up to n time units (resp . arbitrarily
Q-a- Q' P + Q-a-.Q' long) before behaving like P.
Product P-a-.P' Q-b-.Q' P'Q-ab-.P"Q'
S serves to represent asynchrony, in that it may be used
P'Q
to describe a system that after an indefinite time period
Restriction P\G P-a- P'
starts performing non-idle actions at its gates . Thus, based
no factor of a occurs
at G P\G-a-.PIG on S, a subcalculus of LIPS can be developed to model
asynchronous behaviour9. As LIPS is derived from SCCS,
Process p (defined by P-a- P' p-a-.P'
identifier p : = P) so can its asynchronous subcalculus be derived from the
Calculus of Communicating Systems (CCS) 11 .

292 computer communications


Timeout
During the first n time units of its behaviour, P19 r ,P2 can
either idle or start behaving like P1 ; after the n units have
elapsed, it must behave like P2.
Observation equivalence
Observation equivalence is a binary relation over proc-
esses. Two processes P and Q are in such a relation
(donated by P = Q), if they can perform exactly the same
actions and become processes that still enjoy this
property ° .
SPECIFICATION
The effort towards the development of FDTs in the area of
OSI is motivated by'the need for clear and unambiguous
descriptions of communication protocols . Even though a
specification in a natural language may appear plain at a
first reading, it is apt to reveal incompleteness and
ambiguity upon a more accurate examination . To avoid
this, the specification language must be embedded in a
formal framework, and enjoy the features discussed
below.
Completeness
Two main approaches exist for the specification of OSI
systems : the behavioural or constructive, and the assertive .
While an assertive specification is given in terms of the
properties of the specified system' 2-1s, a constructive
specification directly describes the behaviour of the
system' 0,11,16' 17 The assertive approach allows a system
to be described focussing on some selected aspects, but
cannot guarantee the completeness of the description of
the system behaviour. In contrast, this completeness is
inherent to the constructive approach, for in it the system
behaviour must be described explicitly .
Observation and abstraction
Observation means describing a system in terms of its
interaction with the environment, thus abstracting from its
internal characteristics . In general, a specification lang-
uage should be abstract in order to avoid overspecification,
which imposes unnecessary constraints on implementa-
tions .
Nondeterminism and concurrency
Two typical aspects of the OSI environment, which
should be reflected by the FDT adopted, are nondeter-
minism and concurrency.
Nondeterminism is present whenever the evolution in
time of a system is not uniquely determined . It can
manifest itself in two forms, external, i .e. the environ-
ment is offered a choice of possible interactions, and
internal, which originates from non-observable decisions
taken internally by the system .
Concurrency is also typical of OSI, owing to resource
distribution and the need for the simultaneous execution
of several tasks, It should be possible to specify both
synchronous and asynchronous concurrent behaviour .
Probability
The components of an OS1 system are generally charact-
erized by stochastic behaviour (e .g. messages can be lost
during transmission on physical channels) . This entails
that a FDT should include probabilistic features, to permit
performance evaluation of real OSI systems .
vol 11 no 6 december 1988
LIPS has been shown to be a behavioural language which
adopts an observational approach to specification, and
can represent non-determinism and concurrency. In
particular, the choice operator models the capability of a
system to offer non-deterministic behaviour, while the
product and restriction operators model parallelism and
communication . Although the basic LIPS operators
describe process behaviour synchronously, viz. at each
and every time unit, asynchronous behaviour can be
represented by the delay operator 8 . The section (below)
on performance analysis shows how LIPS can be extended
to also model stochastic aspects .
In order to demonstrate the use of LIPS as a specification
technique, the following description is presented :
• a sending entity SENDER;
• a receiving entity RECEIVER;
• an unreliable medium made up of two monodirec-
tional channels M1 and M2 (see Figure 1).
For simplicity, a message transmission that takes place at
gate g is modelled by a simple action at g .
Sender specification :
S : = S m5 :1 TI :d5 :S1
S1 : = (a S :S) A T (f :S)
To process the message input at gate m 5 , the sender S
needs T1 time units, after which the resulting message is
sent through the gate d5 . An acknowledgement is then
awaited at gate a 5, but if none is received within T time
units, failure is notified at gate f .
Receiver specification :
•
R : = 8 d r :1 T2 :(a r Mr)
:R
The receiver R waits for a message at gate d r , and after
receiving it, processes it for T2 time units, after which the
message is simultaneously acknowleded at gate a r and
delivered at m r .
Medium specification :
Medium : = M1 *M2
M1 : = 8 d 5 : ( M1 + d r : M1)
M2: = 8 a r :(M2 + 5`s : M2)
M1 accepts a message at gate d 5 and either loses it or
delivers it at gate d r . Likewise, M2 accepts an acknowledge-
ment at gate a r and either loses it or delivers it at gate a 5 .
Note that the channels M1 and M2 are assumed to
introduce a propagation delay of one time unit only .
VERIFICATION
Protocol verification is aimed at ascertaining that the
M1 }-sd r
M2 *-o r
+
Figure 1. The use of LIPS as a specification technique
293


specification of a protocol is complete, correct and The former approach can be takled by a bisimulation
consistent (see Reference 4) . constructor tool, e .g. (for asynchronous behaviour) BI P 1 .
In order to be complete, the specification of a protocol In the latter appraoch, the proof can be performed by
should include, e .g. the reactions to all permitted inputs, equational reasoning (for the case of asynchronous
and all the service options that the protocol is intended to behaviouran example can be found in Reference 20) . The
provide . On the other hand, overspecification is also to be following example deals with a synchronous system .
avoided : the specification of a protocol should not yet lay The example system considered enables a pair of users
down constraints that do not contribute to providing the to communicate : messages input by a user at gate m s are
required service . delivered to the other user at gate m„ unless a failure
Correctness properties of a protocol can be divided occurs, in which case the sending user is notified at gate f.
into safety and liveness properties . Safety properties Thus, the service expected from the system can be
forbid a protocol to enter unacceptable states (something specified in LIPS as :
bad never happens) . Safety is often expressed by
invariants that the protocol should maintain while it is ES: =
engaged in a cycle, or by conditions that must hold when 8m s :1t 1 : (*message input at m s *)
it reaches a terminal state . For a communication system, a ( 1t2 :f:ES (*message lost, hence f is notified *)
typical safety property is that the output sequence should + 1 :16 : Mr : (*message received at m, *)
be a prefix of the input sequence ; other examples are: ( 1t4 :f :ES (*ack lost, hence-f is notified *)
deadlock freedom (the system never enters a state from + 1 : ES (*OK, ready for another transaction *)
which no progress is possible) ; mutual exclusion (at most,
one user is granted a certain resource) ; boundedness (the
In order to provide ES, a sender entity S and a receiver
size of a queue never exceeds some upper bound) ; and
entity R interact, in accordance with a suitable protocol,
partial correctness (a program that terminates computes
via the underlying service represented by the two
the expected function) .
unreliable media M1 and M2 (see Figure 2) .
Liveness properties demand that the protocol should
Individually, S, R, M1 and M2 have been introduced
eventually enter a desirable state (something good
and formally specified in the previous section . The global
eventually happens) . Examples of liveness properties are :
behaviour of the system is defined by :
the ability to recover from failure, e .g. to get back to a
normal state after a perturbation (self-synchronization);
B: = (S*M1 *M2*R)\G
termination (for programs intended to terminate) ; the
absence of livelocks (unproductive cycles), e .g. due to where G is the set of internal gates 3ds ,as ,d,a,} . By applying
erroneous scheduling or to critical message transmission the expansion theorem, we can derive the following
timings (tempo-blocking) ; and the requirement that a expression for B :
protocol should achieve its goal within a finite time, or at
least eventually . Eventual provision of a service may be B ((S m 5 :1 Tl :d s :S1)*M1 *M2*R)\G
acceptable when components such as communication Sm s :(((1 T1 :ds :S1)*M1*M2*R)\G
channels are faulty but fair, in that they may misbehave for • S m s : 1 T1 :
any finite time but not forever. ( ( (ds :S1) _
Consistency means that the service offered (needed) • (Sd s :(Ml +d, :M1))
by the protocol should conform to that expected • M2*R
(provided) by the upper (lower) layer. Of course, as a by- )\G
product of consistency verification, several correctness
properties may be established, e .g. if the expected service • S m s :1
:
71 :1 :((S1 *(M1 + d, :M1)*M2*R)\G)
1T1
is non-terminating, consistency with it implies deadlock- • S ms + 1
freedom . ( (((a s :S) AT(-f:S))*M1 *M2*R)\G
Several approaches to protocol verification exist in the + ( ((a, :S) 0 T (1 :S))
literature, in relation to different kinds of specification * (ff :M1)
techniques. Assertive specification is more adequate * M2
for proving selected correctness properties, whereas * S d,:1 T2
:6,-_m,) : R
the behavioural/constructive approach is preferable for )\G
proving overall consistency . A behavioural approach
: i T1+1 .
based on the observation equivalence of Milner does • Sm
not permit the study of liveness ; this can, however, be ( 1Y:((f:S)*M1 *M2*R)\G
treated by integrating the behavioural approach with + 1:
temporal logic18, 19
. ( ((as :S)0T- 1(T:S))
The aspect of protocol verification considered in this • M1
paper is consistency between the service offered by the • 8a, :(M2_+ a s :M2)
protocol of a layer, and the service expected by the upper
• 1T2 :(a, •m ,) :R
layer. In the spirit of LIPS, this consistency is established )\G
by proving observation equivalence between the com-
T1+1 .
position of the entities performing the protocol with the • Sm :1
underlying service, and the specification of the expected ( 1~:f:8
service . This equivalence can be proved in two ways : first + 1 :1 T2 :m, :
by finding a suitable bisimulation relation, in accordance ( ((as : S) 07_72_2(f :S))
with the definition of observation equivalence 9; or • M1
second, by applying the algebraic laws of SCCS . • (M2 +a, : M2)

294 computer communications


: 1 T1+1 .
• Sm
( l :f :B
+ 1 :1 72 :m r
( ( ((aS :S)97-T2-2(f :S))
* M1 *M2*R
)\G
+ ( ((aS :S)9T-T2-2(I :S))
* M1*(a 5 :M2)*R
)\G
: 1 Ti+1 :
• Sm
( 1 :f:B
+ 1 :l T2 . m
( 1 T-T2-f B containing loops and meshes ; the latter yields the
+ 1 :B
Therefore, the behaviour described by B is observation
equivalent to the expected service ES.
SIMULATION
As discussed in the previous sections, the information
conveyed by the specification of a system consists of two
aspects: structure and behaviour; a simulator is a com-
puterized tool that allows these two aspects to be
visualized . It can be employed for instruction, either on a
protocol or on a specification language, but its chief
application is as a design aid, especially for quick
prototyping. Although design has to be proved correct
with the techniques illustrated above, simulation is a
cheap way of gaining confidence in it; indeed, simulation
allows a sort of symbolic testing and debugging to be
performed before actually tackling implementation .
The LIPS simulator presented in this section is derived
from that of Pappalardo2 . Although an Interlisp workstation
has been employed for a graphical user interface, the
simulator has been mainly written in the logic program-
ming language Prolog. This choice is motivated by
Prolog's facilities for symbolic computation, and by
its relational flavour, which nicely matches LIPS non-
deterministic semantics .
Visualizing the structure described by a LIPS specifica-
tion is fairly straightforward . Recall that if a process is made
up of the component subprocesses P 1 , . . . ,P,,, con-
nected through the internal gates G, then its specification
will be (P7* . . .*P„)\G . In turn, any component P; can be
further made up of subcomponents . Thus, the structure of
a process is easily recognized from its syntax, by parsing,
and visualized on the terminal screen as a set of possibly
nested boxes .
Service provided
M s f mr
Figure 2 . Communication system
vol 11 no 6 december 1988
The behaviour described by a LIPS process is visualized
in terms of the transition graph and transition tree
associated with the process . It should be recalled that
LIPS semantics is represented by the relation -a-o(defined
in Table 2). The intended meaning of P-a-.Q is that P
may perform the action a and become Q in one time unit .
The transition graph of a process P may be obtained by
drawing a node Np labelled with P and, for each a such
that P-a->Q an edge labelled with a and leading to a
node Nq labelled with Q; and by recursively applying the
above step to each node NQ. Note that if the construction
leads to consider a relation Q1-a-*Q2, such that Q2 has
been encountered before, the graph will already contain a
node NQ2 for Q2 ; the a-labelled edge can then be either
direct to the existing N Q2 or to a newly created one . The
former option yields the transition graph proper, possibly
transition tree, which can also be obtained by unfolding
the transition graph .
A process P may show varying degrees of finiteness :
• P may have a finite transition tree and graph ;
• P may have a finite transition graph, but an infinite
transition tree - this happens if the finite transition
graph contains a loop ; and
• P may have an infinite transition graph (and therefore
an infinite transition tree) - this happens if every step
in the construction of the graph yields at least a new
process .
The simulator can recognize, by parsing an important
subset of the first two classes, which is large enough to
contain most processes of practical interest . Ideally, in this
case, it should visualize the finite transition graph ;
otherwise, it should enable a step-by-step traversal of the
transition tree . In fact, even for processes in the first two
classes, the transition graph may have so many nodes that
its construction becomes impossible because of time and
storage requirements . When such a phenomenon -
sometimes called 'state space explosion'- occurs, one
can only fall back on traversing the transition tree .
As an example, Figure 3 shows the transition graph and
tree of the process p defined by :
p : = g :p + h :q
q: = j :p + k :q
At each step of the exploration of a transition tree, the
simulator shows a tree node with its outgoing edges, each
labelled with an action that the process offers in the state
represented by the node ; also shown are the path
followed and the time units taken to reach the node
displayed . The user may interactively decide to perform
l
Figure 3 . Transition graph and tree of the process p
295

one of the actions offered, which will take him to a new
node, or to back up to some ancestor node . When the
simulated process is made up of components, the
simulator shows which components perform which
actions at which gates, including the pairs of inverse
actions that match to produce an idle action 1 .
Some implementation notes are worth making . The
core of the simulator, not surprisingly, is an algorithm der
that computes the relation -ate . As a Prolog program is
ultimately a collection of axioms and rules, and -a--* is
indeed defined in Table 1 by such a collection, der can be
straightforwardly encoded . Viewing a process definition
p: = P as a binary predicate' : = 'with arguments p and P
leads to an efficient and natural Prolog representation of
LIPS process definitions . Further assets that accrue from
the use of Prolog are its built-in parser and backtracking
mechanism . The latter plays a fundamental role in
computing the transition graph, and in permitting efficient
back-up in the exploration of the transition tree .
On top of the basic tree traversal functionalities
described, the simulator provides masking, environment-
driven simulation and property checking.
Masking is particularly useful for highlighting the only
or the few transition tree paths that represent the purpose
of a process, e .g. the main objective of the ISO transport
layer is to provide a data transfer service which is not easily
recognized in the transition tree, where it appears amidst
the complex behaviour brought about by the protocol's
abort features. In the LIPS simulator these can be
neutralized by masking the processes that describe
them .
Environment-driven simulation enables a process to be
simulated in the presence of a given environment, which
is also formally specified by a LIPS process. Thus, in order
to simulate P in the presence of an environment Env with
which it shares the gates G, one simulates the process
(P*Env)\G . Finally, property checking consists in ascert-
aining that a given property is not violated by the action
path incrementally constructed while traversing the
transition tree . Properties are specified by Prolog predi-
cates which can be easily interfaced with the traversal
routines .
PERFORMANCE ANALYSIS
Two main performance indices are used to characterize
communication systems : transfer time and throughput.
Transfer time measures the 'speed' at which messages are
transferred between two points of the system ; throughput
characterizes a communication system in terms of the
number of messages or bits crossing a given interface in a
time unit.
The LIPS approach to the description of communica-
tion systems permits both these parameters to be
calculated ; given a LIPS process it is possible to work out
the time needed for a message to pass from one gate to
another (i .e. the intergate transfer time), and the number
of messages (orbits) passing through a given gate in a time
unit (i.e. the gate throughput).
In particular, this evaluation is easy if the LIPS process is
deterministic . For simplicity, assume the message length L
is fixed ; the transfer time T is defined as the time elapsing
between the observation of the arrival of a new message,
and the observation of the relevant acknowledgement at
296
the sender . The throughput TH is then equal to the
message length L divided by the transfer time T(TH = LIT) .
A generalization of this scenario is that in which the
system can perform non-deterministic choices . In this
case there are two possibilities:
1 The observer does not know the probability associ-
ated with each action .
2 The observer knows the probability of each choice
involved in the performance evaluation .
LIPS, as presented so far, enables us to formalize only the
first case. Though we can calculate the time needed to
cover a given path, we cannot compute the average
transfer time T m or, consequently, the throughput
TH = LIT, Only specific cases can be evaluated, e .g. the
worst and best cases. In order to cope also with the
second case, viz. stochastic behaviour, recourse must
be made to the Extended Language LIPS (ELLIPSe) . This
is characterized by a new notion of action, denoted by
a {n), and meaning that an action at gate a has a probability
n of being observed . Accordingly, if P is defined by
P : = a{n1) : Q1 + b{n2) : Q2, then 0 + n2 = 1 must
hold . Note that probabilities can be ascribed not only to
actions, but also to process transitions, by the notations
np(Q) and np(Q) for path J . The former denotes the
probability that process P becomes Q, and the latter the
probability that P becomes Q by following a particular
path], e .g . the probabilities associated with the processes
shown in Figure 4 are :
np(Q) for path a :b = 70 n2
np(R) for path a :d = n1 n4
np(S) for path c :e = n3 n5
np(R) for path c :f = n3 n6
The probabilities that a compound process P*Q becomes
some derived process are also easy to work out, e .g. if:
P : = a{n a ) : Pa + b{n b ) : Pb
Q := c{n c ) : Q c + d{nd) : P d
then:
nP*Q(Pa * P c) = na n c
nP*Q(Pb * Pd) = nbnd
nP*Q(Pa * Pd) = h a nd
nP*Q(Pb * Pc) = nbn c
The above extensions to LIPS allow us to evaluate the
performance requirements of OSI systems . This can briefly
be further illustrated in a typical case dealing with the
transmission of variable-length messages through an
unreliable medium . An evaluation of this situation can be
made on the basis of the following assumptions :
• the message length L is variable ; and
1
2
3
t
Figure 4 . Stochastic timed-tree
computer communications

• the timeout is chosen so that retransmission is avoided
for the range of messages analyzed ;
then <Tm >, the average transmission time, can be
expressed as :
L2
<T m > = n(L)Tm (L)
L cation Testing and Verification North-Holland, The
where
• L1 is the length of the shortest message ;
• L2 is the length of the longest message ;
• n(L) is the probability that a message has length L ;
• T m (L) is the average transfer time for a message of
length L .
Note that L1 and L2 are fixed, because they characterize
the system under study, n(L) is assumed known, and, as
demonstrated by Carchiolo et at 21 , Tm (L) can be calcu-
lated symbolically from the LIPS specifications of the
interacting processes that make up the system (e.g.
sender, receiver and medium in Figure 2) . From < Tm > it is
then possible to calculate the throughput :
TH = <L>/<T,>
where <L> is the average message length .
CONCLUSION
The applicability of the behavioural language LIPS to the
design of OSI systems has been shown . LIPS has a formal
semantics, and provides a unique framework in which to
treat both synchronous and asynchronous systems . The
complexity of OSI systems requires that each design step
(viz. specification, verification, simulation and perform-
ance evaluation) should be supported by automated
tools. The development of such tools is under way, with
the objective of embedding LIPS and ELLIPSe into a
Prolog environment. Further studies are planned to
extend LIPS to cover the verification of divergent
processes' 6, and to enhance the suitability of ELLIPSe for
stochastic performance evaluation .
ACKNOWLEDGEMENTS
Giuseppe Pappalardo's work has been supported by the
Royal Signals and Radar Establishment of the UK Ministry
of Defence .
REFERENCES
1 Carchiolo, V and Faro, A 'A tool for the automated
verification of ECCS specifications of OSI protocols'
Proc. Symposium on Discrete Event Syst IIASA,
Sopron, Hungary (1987)
2 Pappalardo, G 'Experiences with a verification and
simulation tool for behavioural Languages' Proc . 7th
IFIP Workshop on Protocol Specification Testing and
Verification North-Holland, The Netherlands (1987)
3 Bochmann, G and Sunshine, C 'Formal methods in
communication protocol design' IEEE Trans. Commun.
Vol COM-28 No 4 (1980)
vol 11 no 6 december 1988
4 Sajkowski, M 'Protocol verification techniques :
status quo and perspective' Proc. 5th IFIP Workshop
on Protocol Specification Testing and Verification
North-Holland, The Netherlands (1984)
5 Venkatraman, R C and Piatkowski, T 'A formal
comparison of formal protocol specification tech-
niques' Proc. 5th IFIP Workshop on Protocol Specifi-
Netherlands (1985)
6 Piatkowski, T F 'The state of the art in protocol
engineering' Proc . SIGCOMM '86, ACM Comput
Commun. Rev. Vol 16 No 3 (1986)
7 Information Processing Systems - Open Systems
Interconnection 'ESTELLE - a formal description tech-
nique based on an extended state transition model'
ISO/TC97/SC21/DP9074, ISO, Geneva, Switzerland
(1987)
8 Information Processing Systems - Open Systems
Interconnection 'LOTOS - a formal description tech-
nique based on the temporal ordering of the
observational behaviour' ISO/TC97/SC21/DP8807,
ISO, Geneva, Switzerland (June 1985)
9 Carchiolo, V, Di Stefano, A, Faro, A and Pappalardo,
G ECCS and LIPS: two languages for OSI specification
and verification Internal Report, Instituto di Infor-
matica e Telecomunicazioni, University di Catania,
Catania, Italy (1986)
10 Milner, R 'Calculi for synchrony and asynchrony'
Theor. Comput Sci. Vol 25 (July 1983)
11 Milner, R A Calculus of Communication Systems
LCNS 92 Springer-Verlag, FRG (1980)
12 Apt, K R, Frances, N and De Roever, P A 'A proof
system for communicating sequential processes'
ACM Trans . Prog. Lang. Syst Vol 2 (July 1980)
13 Levin, G M and Gries, D 'A proof technique for
commuicating sequential processes' Acta Inf. Vol 15
(1983)
14 Pnueli, A 'The temporal semantics of concurrent
programs' Theor. Comput Sci. Vol 13 (1981)
15 Schwartz, R, Melliar-Smith, M and Vogt, F 'An
interval logic for higher level temporal reasoning' Proc .
3rd IFIP Workshop on Protocol Specification Testing
and Verification North-Holland, The Netherlands
(1983)
16 Brookes, S D, Hoare, C A R and Roscoe, A W 'A
theory of communicating sequential processes'] . Ass.
Comput. Mach. Vol 31 (July 1984)
17 Reisig, W Petri nets: an introduction Springer-
Verlag, FRG (1985)
18 Carchiolo, V and Pappalardo, G 'CCS as a specifi-
cation and verification technique : a case study and a
comparison with temporal logic' Proc. Pacific Comput
Commun. '85 North-Holland, The Netherlands
(1986)
19 Gustavsson, R and Parrow, ) 'Modelling distributed
systems in an extension of CCS with infinite experi-
ments and temporal logic' Proc. 4th IFIP Workshop
on Protocol Specification Testing and Verification
North-Holland, The Netherlands (1985)
20 Carchiolo, V, Faro, A, Mirabelle, 0, Pappalardo, G
and Scollo, G 'A LOTOS specification of the PROWAY
highway service' IEEE Trans . Comput Vol C-35 No 11
(November 1986)
21 Carchiolo, V, Faro, A and Malgeri, M 'Performance
analysis of interacting parallel systems using LIPS'
Proc. Chip Edmonton, Canada (1988)
297
 Vincenza Carchiolo received
her degree in electrical engin-
eering from the University of
Catania, Italy, in 1983 . Until
1984 she worked at CREI-
Politecnico di Milano on the
design of an OSI protocol
testing system, and since
then has been teaching at
the University of Catania.
Between 1984 and 1987 she
was involved in the EC's
ESPRIT-SEDOS project . Her main research interests are
computer networks, formal description techniques,
and the verification and testing of distributed systems .
Antonella di Stefano rec-
eived her degree in electrical
engineering from the Univer-
sity of Catania, Italy, in 1983 .
Between 1984 and 1987 she
was involved with the EC's
ESPRIT-SEDOS project. She
is currently teaching at the
University of Catania, where
her research interests include
the use of expert systems for
computer networks, and
formal description techniques .
298
Alberto Faro received his
degree in engineering from
the Politecnico di Milano,
Italy, in 1971 . He is currently
a full Professor of Computer
Science in the Faculty of
Engineering at the University
of Catania, Italy, and is also
Director of the University's
Institute of Informatics and
Telecommunication, and of
its Computer Centre . His
particular interest is in the architecture of, and formal
description techniques for, distributed systems .
Giuseppe Pappalardo rec-
eived his degree in electrical
engineeringfrom the Univer-
sity of Catania, Italy, in 1983 .
Following six months at CREI-
Politecnico di Milano, he
joined the University of
Catania in 1984, where he
was involved with the EC's
ESPRIT-SEDOS project. He
currently works as a resear-
cher at the University of
Reggio Calabria, Italy, where his main interest lies with
distributed computing and automated tools for
computer network software .
computer communications