ll
Two Standards Means Problems: A Case
Study on Formal Protocol Descriptions
Alessandro F A N T E C H I *, Stefania G N E S I *
and Cosimo L A N E V E **
• lstituto di Elaborazione dell'lnformazione, CN.R., Via S.
Maria 46, 1 56100Pisa, Italy
• * Dipartimento di Matematica, Universit?l di Siena, Via del
Capitano 15, 1 53100 Siena, ltalv
Estelle and LOTOS Formal Description Techniques for
protocol specifications are considered as a typical example of
incompatibility problems which can arise when two standard
are used in the same context,
The aim of this paper is to indicate the sources of possible
problems and to show the effects of having incompatible
specifications of the same system. A brief discussion follows on
some techniques and methods to verify the compatibility be-
tween Estelle and LOTOS specifications.
Kevwords." OSI, Formal specification, Formal description tech-
niques, Conformance testing, LOTOS, Estelle.
Received: 18 April 1988
Revised: 16 August 1988
Alessandro Fanteehi, born in 1955,
_ graduated cum laude in Computer Sci-
ence at the University of Pisa, Italy, in
1978. Since 1983 he has been working
with the programming Languages and
Operating Systems group of the
Istituto di Elaborazione dell'Informa-
zione of the Italian National Research
i Council (CNR), Pisa, Italy. He has
~i;'I ~'~
also worked at the research center of
Olivetti in Pisa from 1981 to 1983. His
current research interests include
semantics of concurrent programming
languages and applications of temporal logic to the specifica-
tion and verification of concurrent systems,
1 1 ~ Stefania Gnesi, born in 1954, g r a d - t h a t
i hated cum laude in Computer Science
at the University of Pisa, Italy, in 1978.
Since 1984 she has been working with
the programming Languages and Op-
erating Systems group of the Istituto
di Elaborazione dell'Informazione of
the Italian National Research Council
a ..... (CNR), Pisa, Italy. Her current re-
search interests include methods and
tools for the specification and verifica-
tion of concurrent systems, and appli-
cations of temporal logic,
North-Holland
Computer Standards & Interfaces 9 (1989) 11-19
0920-5489/89/$3.50 ~v~1989, Elsevier Science Publishers B.V. (North-Holland)
1. Introduction
Whenever two standards have been defined to
specify the same class of objects, problems of
incompatibility can arise.
We consider a case of this type which concerns
the two standard Formal Description Techniques
(FDTs, in the following), Estelle and LOTOS,
defined by ISO. These F D T s have been developed
with the aim of making possible formal descrip-
tions of the standards of the OSI architecture [1].
Formal descriptions should provide a basis for:
- the unambiguous and clear specification of
protocol standards;
- the verification of specifications in order to
identify errors and to prove properties:
the implementation of a specification and
testing of this implementation.
These two F D T s have been developed simulta-
neously and so far neither is privileged within the
ISO committee. Consequently two formal descrip-
tions (Estelle and LOTOS) of communication pro-
tOCOIS (at the working draft status) of the same
layer (for instance, the transport layer protocol,
class 0), can co-exist in ISO and there is no
guarantee that, when two protocols are imple-
mented on the basis of two different formal de-
scriptions, p r o c e s s e s w h i c h use these t w o p r o t o c o l s
c a n communicate correctly.
It is true that currently the existing Estelle and
LOTOS specifications of protocols and services of
the OSI architecture do not constitute an official
standard. However, in the near future, it is likely
t h e y will b e g i v e n an official status, as refer-
Cosimo Laneve, born in 1962, grad-
hated in Computer Science at The
I h University of Pisa, Italy, in 1987. He
currently holds a fellowship at the De-
I P
D
'
partment of Mathematics of the Uni-
versity of Siena, where he is post-
graduate student in Logics. His re-
search interests include concurrent and
distributed systems, formal descrip-
tion techniques and temporal logics.
12
ence specifications which can be used to derive
formally tests to verify that implementations con-
form to them, or to directly derive implementa-
tions. If neither Estelle nor LOTOS are preferred,
the problem will arise as to whether two specifica-
tions of the same object will be compatible, i.e.
whether tests derived by them will check the same
properties, or implementations derived by them
will realize the same object,
In the rest of the paper, after a brief presenta-
tion of the two FDTs, we will address incompati-
bility problems which can arise in the above de-
picted situation, and specify more precisely the
notion of compatibility. We will also analyze the
intrinsic differences between Estelle and EOTOS
which can cause the production of incompatibili-
ties and show that this will happen more often in
certain application areas. Finally, we will briefly
introduce and discuss the techniques and methods
that can be used to detect potential sources of
incompatibility, stating possible directions of fu-
ture research.
2. Estelle
Estelle [2] is a Pascal-based language with ex-
tensions to encompass parallelism. An Estelle de-
scription of a system consists of a set of modules
exchanging messages through bidirectional com-
munication channels. Each module is an extended
state transition machine which, when enabled, can
execute a transition from one state to another,
In Fig. 1 the syntax of an Estelle module is
shown. It consists of two parts; the first part
module Name (list-of-variables)process
ip Pl: channel-type(role)
end
body Name 1 for Name 2
(DECLARATION PART}
const ...
vat ...
state ...
...
initialize (INITIALIZATION PART)
to ... {initial module state}
'"
trans (TRANSITION PART}
(clauses, transition blocks)*
end
Fig. 1. Module header and body definitions,
A. Fantechi et al. / Formal Protocol Descriptions
(header definition)contains principally the defini-
tion of the module name together with possible
input variables and the names of its interaction
points; the second part (body definition) specifies
its behaviour. This part consists of three subparts:
(1) the declaration, which specifies constants, vari-
ables, local types and used functions; (2) the ini-
tialization in which the local variables and the
module state are initialized; (3) the transition
which specifies the set of transitions that the mod-
ule can execute. Each transition is made up by a
set of clauses and a transition block. The transi-
tion block, which is a list of statements, is ex-
ecuted when all the clauses in the relative set have
been verified. The main clauses which concur to
enable a module transition are:
- the state of the module,
- the presence of a particular interaction in the
queue associated to an interaction point,
- the truth of a boolean formula,
- the priority among transitions,
- the time elapsed since the preceding transi-
tion.
Note that the last clause makes it possible to
model a synchronous system which can quantify
the time elapsed from the end of one transition to
the beginning of the next.
The 'firing' of a transition consists in the execu-
tion of a block of statements associated to it and
in the passage from the current state of the rood-
ule to that specified in the ' t o ' clause.
The set of modules which constitute the system
description is hierarchically structured; it forms a
tree whose root is the whole system specification.
This hierarchy is dynamically variable in terms of
modules and of channels linking them. In particu-
lar, the language provides constructs to dynami-
cally create and terminate modules (called 'sons').
When a module is created, it is not linked to any
other module. In order to be able to send or
receive messages, the father (the module that has
created it) properly connects its interaction points
(by the statement 'connect').
By ' p r o p e r l y ' we mean that two interaction
points (belonging to different modules) will be
connected only if they have the same type and the
two modules use them with dual roles. More pre-
cisely, as shown in Fig. 1, a type is associated to
every module interaction point. This type char-
acterizes the primitives through which the module
may send and receive messages and identifies the
 A. Fantechi et al. / Formal Protocol Descriptions
channel name (Rol%, Role2)
by Role~
Interaction Namel(typed parameters);
•"
Interaction Name N(typed parameters);
byInteraction
Role, Namel(typed parameters):
Interaction NameK(typed parameters):
Fig. 2. Channel definition,
kind of messages exchanged between partners.
Fig. 2 shows the syntax for channel definition,
which makes it possible, for each channel type, to
express both the primitives for exchanging mes-
sages and their type. These interaction points may
he disconnected during the computation. Note
that only two modules will be involved in a corn-
munication: the sender and the receiver. Conse-
quently, this kind of communication is 'point to
point' (or symmetric),
A module delegates a son to receive messages
from one of its interaction points. For this reason
the two interaction points must have the same
type and the two modules must use them with the
same role.
Each module interaction point has an associ-
ated unlimited queue in which all the messages
received by the module are enqueued; conse-
quently the communication is said to be asynch-
ronous,
3. L O T O S
LOTOS (Language of Temporal Ordering
Specification) [3] is a language based on process
algebraic methods and is derived from Milner's
Calculus of Communicating Systems [4]. A system
is seen, by LOTOS, as a single process which may
contain several interacting subprocesses. A pro-
cess is described by defining the temporal relation
between the events that constitute its externally
observable behaviour. To shape the temporal
ordering of events, the language provides several
operators (sequential composition, non-determin-
istic choice, synchronized and non-synchronized
parallelism, etc); using these operators properly, it
is possible to build expressions which specify the
13
process behaviour. For example, the syntax of a
behaviour expression B is simply:
B := a ; B ' IB' op B" Ip[g][v] ]stop
where B' and B" are behaviour expressions, a is
an action (or event) and op indicates the symbol
for sequential composition (":"), non-determinis-
tic choise (" []"), parallel composition (" Ir' or "tl]"),
etc. The stop action denotes a process which is
unable to perform any action, p[g][v] denotes pro-
cess calling.
The main actions considered are the communi-
cations between a process and the external en-
vironment, which are based upon the general idea
of "interaction". In an interaction, a LOTOS pro-
cess and the external environment establish to-
gether the t-uple of values they want to exchange
through a 'gate' (or interaction point). The syntax
for these action is:
g?x:t g!v
which denotes, respectively, a process which can
interact at the gate 'g' offering any value of type
' t ' and a process which can interact at gate 'g'
offering only the value ' v'.
The synchronized parallel composition operator
is used to define processes which are going to
interact at the same gate. Interaction generally
occurs between more than two processes: they
synchronize by simultaneously offering/accepting
the same value at the same gate. In this way
synchronous point to point and multicast com-
munications can be modeled.
Another important action is the unobservable
'i'. This action is hidden from any external ob-
servation, i.e. an external observer of the system
does not see its execution. Such actions may be
produced as the result of a hiding operation per-
formed on a system of composed processes. In this
way internal implementation details are hidden,
and only the interactions with the external world
can be observed. This concept is the basis on
which a notion of observational equivalence, which
can be used to relate descriptions at a different
abstraction level, is constructed.
Another event considered in the behaviour ex-
pressions is the termination (unobservable) action
which makes it possible to pass a result value to
the continuation of a terminated process ('d'). In
this way, processes can be called as if they were
14 A. Fantechi et al. / Formal Protocol Descriptions
procedures; recursive calls are also admitted. In
particular, the LOTOS BNF syntax of the process
declaration is:
process declaration
:= process process identification[gate*][value*]
'.'= 'behaviour expression endproc
A process is called by referring to its name and
supplying it with an n-uple of gates and an m-uple
of values.
Values, value expressions and data structures in
LOTOS are represented using an algebraic specifi-
cation method which allows parameterized ab-
stract data types to be defined.
4. Compatibility between Estelle and LOTOS De-
seriptions
An Estelle or LOTOS specification can provide
the basis which can be used to develop an imple-
mentation of the specified system (service, proto-
col). The development from specification to imple-
mentation will consist of one or more transforma-
tion steps which are generally written in different
programming languages. Each transformation step
will include the implementation of details which
were not considered in the higher level specifica-
tion. This process should be associated to a notion
of correctness which ensures that the derived ira-
plementation conforms to (behaves as specified
by) the specification,
In this context we assume that some rigorous
standard or automatic way of deriving a correct
implementation from a specification is available
(the development of such a technique is by no
means an easy task). Therefore we presume that
the implementation process is error free. This
means that the origin of any difference between
implementations of the same system must be
searched in the formal descriptions from which
they have been derived. Consequently, we can
concentrate on the differences between LOTOS
and Estelle specifications. The presence of two
formal specifications of the same protocol raises
the question as to whether they really represent
the same object. We are not concerned however
proc Sender[a] noexit := a !5; Sender [a] proe Receiver [a] n o e x i t := a ?x: nat; Receiver [a]
endproc endproc
Fig. 3. L O T O S specification.
with proving the equivalence between these speci-
fications, but a weaker relation: their compatibil-
ity. This notion can be informally described thus:
given a LOTOS description L and an Estelle de-
scription E of the same protocol, L and E will be
compatible if two processes using two protocols,
one implemented from L and the other from E
(using the standard derivation methods) can com-
municate correctly.
Compatibility can be defined formally as a
relation between two specifications which guaran-
tees that the derived implementations communi-
cate [5].
Assuming that we have a LOTOS and an Estelle
description of a given system, two main factors
may concur so that the descriptions effectively
specify two different objects:
- d i s t i n c t interpretations of the informal de-
scription,
- differences between languages.
Different interpretations of informal descrip-
tions by the relative specifiers (ignoring the possi-
bility of errors made by them) may result in
differences between LOTOS and Estelle descrip-
tions. In fact, as the reference description is infor-
mal it may be ambiguous and thus two different
specifiers (one using LOTOS and the other Estelle)
may interpret it differently. We will not discuss
this question in detail: we only want to stress the
need for a comparison between formal descrip-
tions which are derived from the same informal
one.
A more interesting question is the presence of
differences between the two specifications which
may arise because of differences between the two
FDTs. To clarify this point we give a simple
example.
Consider the following system:
Sender:
-send the message '5' to Receiver,
-wait until Receiver has acknowledged it,
-repeat forever.
Receiver:
-receive a message of type 'nat' from Sender,
-acknowledge reception,
-repeat forever.
 A. Fantechi et al. / Formal Protocol Descriptions 15

module Sender process module Receiver process

ip ip
a: C access p o i n t ( P r o v i d e r ) individual queue a: C access p o i n t (User) individual queue
end end

b o d y s e n d e r for S e n d e r b o d y receiver for R e c e i v e r

state s 1, s2: state sl;
initialize to s 1 initialize to s I
trans trans
from s 1 to s~ from s 1 to s 1
begin when a.receive(x)
o u t p u t a.send(5) begin
end output a . a c k
from s ~ to s ~ end
when a.receive
begin
output a . s e n d ( 5 )
end

Fig. 4. Estelle specification.

In LOTOS this system may be described as in Receivert=-" Repeat

Fig. 3.
receive (Queue, x)"
Note that acknowledgement of reception is
omitted: acknowledgement is implicit due to the send (Mitt, ack)
LOTOS synchronous communication mechanism.
Likewise, the above protocol may be specified forever
in Estelle as in Fig. 4. However if we combine Sender k and Receiver E
As we have both LOTOS and Estelle formal the two processes will not communicate correctly:
descriptions, we can ask what will happen if we Mitt will send an infinite number of messages to
implement a protocol subset following the LOTOS Receivert~, while ReceiverF_ will wait forever the
description (for example the process 'Sender') and SenderL's reception of the acknowledge of the first
the remaining subset following the Estelle specifi- message sent.
cation. Let us use an implementation language The above example demonstrates the impor-
which has a synchronous communication mecha- tance of the differences between the two languages
nism and a construct which dynamically creates in producing incompatible descriptions.
and destroys processes (this is needed to realize
the Estelle unbounded queue associated to a chan-
nel). For the LOTOS description the Sender pro-
5. Differences between LOTOS and Estelle
cess will be implemented in the following way:

SenderL: repeat The main differences that we recognize between

send (Dest, 5) the two FDTs are:
forever 1. synchronous versus asynchronous communi-
cation,
For the Estelle description, the Receiver pro- 2. point to point versus multicast communica-
cess will be implemented as follows: tion,
Receivert~" (Queue IIReceiverF.') 3. the time notion.
In the following we will discuss the problems
We omit the detailed description of the Queue that each of the above points can cause in the
process (it implements the Estelle unbounded formal description phase, with particular attention
buffer). Receiver E' implementation is: to the OSI world.
16 A. Fantechi et al. / Formal Protocol Descrtptions
Synchronous versus asynchronous. As we have
already stated, communication between LOTOS
processes is synchronous, whereas in Estelle com-
munication between modules is asynchronous with
a boundless queue. The Estelle interaction scheme
does not permit the "backpressure" control flow
to be modeled directly [6]. Backpressure is an
implicit control flow mechanism of messages from
a user (or client) to a provider (or server), which
specifies that the user is blocked from sending
other requests to the provider when the communi-
cation channel queue between them is full. In this
mechanism, there is no explicit communication of
control information between the two partners. The
presence of a boundless queue between two corn-
municating modules imposed by Estelle means
that "full queue" status is never reached. For
instance, if the session protocol wants to send the
communication request to the transport protocol,
it will perform:
output T_ch.CR(process A, process B. . . . )
where T ch is the channel which links the two
protocols. The message will be enqueued in the
correct queue without checking the queue status,
Implementations derived from an Estelle formal
description of this type should have a boundless
queue between these protocols, even if the imple-
mentation language has mechanisms for synchro-
nous communication and for asynchronous corn-
munication with bounded queues,
In LOTOS, it is easier to specify backpressure
flow because a user can only send a request to the
provider when the latter is ready to interact at the
same gate. Consequently, if the provider is busy
meeting other requests, it may delay the service
request simply by not interacting at the gate in
question,
Note that the formal specification of backpres-
sure control flow is not taken into consideration in
the OSI model because it does not require interac-
tions to be specified between adjacent entities
(entities which, inside OSI architecture, are at two
contiguous layers) but only between peer entities
(entities of the same OSI layer but on remote
machines). In any case this mechanism needs a
formalization when the protocols specified are to
be implemented by derivation,
Point-to-point versus multicast. By 'point-to-
point (or symmetric) communication' we intend a
communication mechanism in which only two en-
tities are involved: one sending a message (sender)
and the other receiving it (receiver). On the other
hand, in multicast communication, a single entity
sends a message to more than one receiver. Multi-
cast communication is very useful, for example it
can serve at the operating system level to obtain
information on the physical location of distributed
resources, their availability, etc.
The main problem raised in multicast com-
munication is that of being able to send a message
to a set of processes synchronizing with all of
them. With LOTOS, using all the facilities offered
by the parallel composition, simultaneous interac-
tion with a set of processes is possible. It is
sufficient to compose correctly all the processes
interested as follows:
((---(P1 [glP2) [g[ ... )1 g IPN)
in which processes P1, P2 . . . . . PN must interact at
the same gate 'g'. The LOTOS parallel composi-
tion semantics forces every process in the above
set to interact (synchronize and possibly give a
value) at gate 'g', whenever possible. We may find
this problem in the OSI model when lower layer
protocols are to be specified (e.g. Ethernet).
Estelle only provides point to point communi-
cation mechanisms. This means that situations in
which a process must send a message to more than
one receiver cannot be described directly. The
solution is to emulate the multicast communica-
tion to n entities through n symmetric communi-
cations: each process must be directly connected
(through a channel) to the others; immediate
simultaneous synchronization of all the processes
is not respected.
Time notion. The F D T s may be required to
express time measuring features. This is impossi-
ble in L O T O S because there is no time notion. On
the contrary, Estelle can express these aspects well
using the delay clause. This is a particular case of
the differences between the two FDTs: using one
of them time dependent synchronous systems can
be specified, using the other it is not possible.
In the framework of the OSI model, examples
in which temporal notions are needed may be
found in the lower layers. In order to cope with
message losses, in these protocols a mechanism is
needed which warns the station that when a cer-
rain period of time has elapsed after the transmis-
sion, a message will be considered lost. The time
period can be specified to a sufficient degree
 A. Fantechi et al. / Formal Protocol Descriptions
trans
from s, to s2
begin
endOUtput M.msg;
from s 2 to s 3
delay(S0,50)
begin {the message has not been acknowledged}
" lems arise in the specification of the lower levels
end
f r o m s 2 to s 4
w h e n M.ack
begin {the message has been acknowledged}
--.
end
Fig. 5. A time-out example,
because at these layers the physical medium and
the distance between stations and, consequently,
the time needed for a message to reach another
station are known. A similar situation is easily
specified in Estelle using a 'delay' clause which
makes it possible to delay the execution of the
relative transition block. For example, supposing
that our time-scale is in milliseconds, a process
which sends a message and wait only 50 millisec-
onds for the acknowledgement can be described as
in Fig. 5.
Another example of application can be found
in real time distributed systems. A formal descrip-
tion of these systems usually requires that an
event (i.e. the arrive of a message) occurs within a
precise time interval,
6. Critical A r e a s
In Section 4 we have examined a case of incom-
patibility between the implementation of a LOTOS
description and an Estelle one. The fundamental
point which caused this incompatibility is that:
synchronous communication guarantees the sender
that the receiver has effectively received the mes-
sage," asynchronous communication does not.
Using this property of synchronous communi-
cation, we have produced the simple example of
Section 4.
From an analysis of the high levels protocol
specifications of the OSI architecture we can see
that most communications are acknowledged,
Hence, in both Estelle and LOTOS specifications,
each communication is modeled by a pair of com-
17
munications: message and acknowledge. In gen-
eral, the correspondence is not one to one; an
acknowledge may refer to several previous mes-
sages (sliding window protocols).
It is easy to be convinced that this kind of
communication does not involve the problems dis-
cussed in the previous section. Indeed, such prob-
of the OS1 architecture, i.e. when we want to
specify low level characteristics, in which syn-
chronization, symmetry and time are important
aspects.
Other areas in which such aspects are crucial
include, in our opinion, the distributed real time
systems sector, in which time and synchronization
between processes play a preeminent role, and
that of fault tolerant distributed systems, in which
we often have the problem of guaranteeing the
simultaneous and consistent update of more copies
of the same object allocated on different nodes of
the system. Algorithms which solve such problems
can often be described more easily if multicast
synchronous communication is used.
Any future attempt by the standards organiza-
tions to give two formal specifications of protocols
and systems in these critical areas should take into
account the problems which may be created by
differences between the two languages. Although
it may appear that the considerations made in this
section suggest that it is only important to verify
the compatibility between LOTOS and Estelle
spcifications in certain particular areas, it will
always be possible for two incompatible formal
specifications to be derived from an informal one
due to different interpretations by the two speci-
fiers, even for systems which are not in the critical
areas. This does not affect the general requirement
for a compatibility checking method.
7. C o m p a t i b i l i t y C h e c k
The above discussion clearly illustrates that a
method which can be used to compare LOTOS
and Estelle descriptions is needed. This is because
protocols, which have been implemented from two
different descriptions, may lose their compatibil-
ity, thus invalidating both the OSI standard and
the formal descriptions.
In Section 4 we have discussed the need for a
correct method to derive an implementation from
18 A. Fantechi et al. / Formal Protocol Descriptions
a specification, i.e. a proof that an implementation
behaves as the specification prescribed (confor-
mance proof). A way to check that the implemen-
tation respect the requirements of the specification
is to use a set of tests (called conformance tests),
In the OSI context, the conformance testing
activity aims at developing a standard set of tests
for each standard protocol which guarantees that
implementations conform to the respective (infor-
mal) standards. Such tests are currently derived
from the informal standard definition and indeed
constitute the only formal objects with which im-
plementations can be compared,
Conformance testing may be also applied to
LOTOS and Estelle descriptions to verify their
compatibility. We may envisage LOTOS and
Estelle protocol descriptions as different imple-
mentations of the relative informal standard,
Therefore, we will consider the two descriptions
compatible if they both verify the conformance
tests for the protocol in question.
Unfortunately, practical limitations make it im-
possible to be exhaustive in testing a protocol, and
economic considerations may restrict conformance
testing ever further. This means that, in general, it
is not possible to use this method to test the
compatibility of two specifications completely,
Another, more formal, way to check compati-
bility is by formal comparison of the specifica-
tions. Since LOTOS and Estelle are two different
languages, we have no direct equivalence between
specifications. Descriptions in these languages can
be formally compared in two ways:
1. by converting the LOTOS description to an
Estelle one and then comparing the two de-
scriptions, or vice-versa; this approach as-
sumes the existence of a "correct" converter,
or translator, from one language to the other;
specifications in the target language can be
compared using some notion of equivalence
for the target language. A "correct" trans-
lator should solve the problems discussed in
section 5.
2. by converting both LOTOS and Estelle de-
scriptions to descriptions in another lan-
guage and then comparing the two descrip-
tions in this new language. This approach
does not require the existence of a translator,
since the third description can ignore specifi-
cation details which are not interesting for
compatibility. To cater for different imple-
mentation details caused by differences in
the two languages, the third description lan-
guage should be more abstract.
As an example of the second approach we
suggest converting both LOTOS and Estelle de-
scriptions to axiomatic specifications of the object
being described. An axiomatic specification is a
set of properties, or axioms, which qualify im-
plicitly the behaviour of an object. Unlike F D T
descriptions (called behavioural descriptions), as it
is at a higher abstraction level, an axiomatic de-
scription of a system which states all its manda-
tory properties, will not explicitly specify all possi-
ble system behaviours.
A possibility considered in [5] is to use tem-
poral logic as a higher abstraction level specifica-
tion method: this has been recognized as the most
suitable formalism for axiomatically expressing
properties of concurrent systems (the class of sys-
tems that can be specified by formalisms such as
LOTOS and Estelle). The proposed method con-
sists in comparing the properties of formal de-
scriptions, properties expressed in a language
based on temporal logic and derived formally
from the descriptions, and considering them
equivalent if the two axiomatic descriptions pro-
duced are equivalent.
8. Conclusions
The classical problem of incompatibilities raised
by the use of two different standards has been
studied for the case of the standard Formal De-
scription Techniques developed by ISO in the
context of OSI architecture.
We have indicated the sources of possible prob-
lems, shown the effects of having incompatible
specifications of the same system and motivated
the need to consider such problems when giving
official standard formal specifications.
Techniques and methods which can be used to
verify the compatibility between Estelle and
LOTOS specifications have been discussed. In any
case, we believe that any method to compare
descriptions of objects of the complexity of an
OSI protocol or service will only have success if
an automated support tool is provided.
Considerable work is still needed for the defini-
tion and development of tools which can effec-
tively use some of the techniques involved and for
 A. Fantechi et al. / Formal Protocol Descriptions
the integration of such tools in an environment
which would support a complete comparison
method.
Acknowledgements
We wish to acknowledge C. Peters for her
careful revision of our English.
The work of C. Laneve has been partially sup-
ported by Ing. C. Olivetti S.p.A. with an under-
graduate fellowship,
References
[1] H. Zimmerman, OSI Reference Model: The ISO Model of
Architecture for Open Systems Interconnection, IEEE
Trans. on Comm. Vol. COM-28, No. 4 (1980).
19
[2] ISO Information Processing Systems - Open System
lnterconnection,
Estelle: A Formal Description Technique
Based on an Extended State Transition Model, DIS 9074
(1987).
[3] 1SO - Information Processing Systems - Open System
lnterconnection, LOTOS, A Formal Description Technique
Based on the Temporal Ordering of Observational Be-
haviour, DIS 8807 (1987).
[41 R. Milner, A. Calculus ofCommunicatingSystems, Lecture
Notes in Computer Science No. 92 (Springer Verlag, New
York, 1980).
[51 A. Fantechi, S. Gnesi and C. Laneve, Comparing LOTOS
and Estelle Formal Descriptions, EUTECO'88 Conference
Proceedings, Wien, April 1988 (North-Holland, Amster-
dam).
[6] C.A. Vissers and G. Scollo, Formal Specifications in OSI,
IBM Europe Seminar Networking in Open Systems, Ob-
erlech, Austria (August 18-22, 1986).