ieee on semiautomatic implementation communication protocols

IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. SE-13, NO. 9, SEPTEMBER 1987

Semiautomatic Implementation of Communication

ProtocolsGREGOR v. BOCHMANN, SENIOR MEMBER, IEEE, GEORGE WALTER GERBER,

AND JEAN-MARC SERRE

Abstraet-The use of formal specifications in software developmentallows the use of certain automated tools during the specification andsoftware developmen-t process. Formal description techniques havebeen developed for the specification of communication protocols andservices. This paper describes the partial automation of the protocolimplementation process based on a formal specification of the protocolto'be implemented. An implementation strategy and a related softwarestructure for the implementation of state transition oriented specifi-cations is presented. Its application is demonstrated with a much sim-plified Transport protocol. The automated translation of specificationsinto implementation code in a high-level language is also discussed. Asemiautomated implementation strategy is explained which highlightsseveral refinement steps, part of which are automated, which lead froma formal protocol specifieation to an implementation. Experience withseveral full implementations of the OSI Transport protocol is de-scribed.

Index Terms-Communication protocols, Estelle, formal descriptiontechniques, formal specification, implementation methodology, proto-col implementation, specification translation, transport protocol im-plementation.

I. INTRODUCTIONTHE use of formal specification methods has been pro-

for software engineering. Such methods are ofparticular importance for communication software sincecommunication software must satisfy the rules defined bythe communication protocols which' are used. Many dif-ferent implementations are usually built for a given com-munication protocol. It is therefore important that theserules 'be specified precisely. For this reason, they are can-didates for being specified with a formal 'specificationmethod.The -rules for communication between different com-

puter systems are usually based on some architectural as-sumptions, such as' defined by the OSI reference model[21] and the service concept [30], which define a layered

Manuscript received December 28, 1984; revised July 31, 1986. Thiswork was supported by the Fond National Suisse de la Recherche Scienti-fique, the Department of Communications, Canada, and the Natural Sci-ences and Engineering Research Council of Canada.

G. v. Bochmann is with the Department of Computer Science and Op-erations Research, University of Montreal, C.P. 6128, Montreal, P.Q. H3C3J7, Canada.

G. W. Gerber was with the Department of Computer Science and Op-erations Research, University of Montreal, C.P. 6128, Montreal, P.Q. H3C3J7, Canada. He is now with the Centro de Pesquisas de Energia Electrica,Rio de Janeiro, Brazil.

J. M. Serre was with the Department of Computer Sciences and Oper-ations Research lUniversity of Montreal, C.P. 6128, Montreal, P.: Q. H3C3J7, Canada. He is now with Bell Northern Research, 3 Place du Com-merce, Verdun, Ile des Soeurs, H3L 1H6, Canada.

IEEE Log Number 8716545.

ApplicationPresentation

SessionTransportNet work

Link

Physics I

+-t4 ------

4-

4-I

4--

ApplicationPresentation

Session

TransportNetwork

Link

Physical

Fig. 1. OSI architecture.

system structure, such as shown in Fig. 1. For each layer,the service specification defines the communication ser-vice to be provided to the user entities in the next higherlayer. The protocol specification, which defines the be-havior of an entity within the layer, defines how the cor-responding entities in different systems communicate withone another by exchanging so-called protocol data units(PDU), using the communication service provided by thelayer belowFormal specifications, like informal ones, are used for

the following purposes:1) For each communication protocol and service, there

is usually one specification which serves as "reference"for all other activities.

2) Protocol and service specifications are used for thevalidation of the design of the protocol of a given layer.For this purpose, the service provided by the protocol en-tities (as defined by the protocol specification) commu-nicating through the service of the underlying layer iscompared with the service defined by the service specifi-cation of the given layer.

3) The protocol specification is used for the elaboration-of implementations.

4) The protocol specification is used during the vali-dation (debugging, testing) of an implementation, and forassessing its conformance with the protocol specification.

Expenrments with automated tools for the above activ-ities have been reported in the literature (for a review, seefor instance [8]). Such tools become important when for-mal specifications are used for real-life protocols whichare usually sufficiently complex to make some automationdesirable. Since such tools only become effective if theycan be based on specifications written in some formalmethod, the development of suitable formal descriptiontechniques (FDT's) for communication protocols and ser-vices has been an area of much concern. For this reason,standardized FDT's are developed within ISO and CCITT

0098-5589/87/0900-0989$01.00 © 1987 IEEE

989


[29], [12]. The results of these standardization efforts arethree FDT candidates, SDL [24], Estelle [13], and Lotos[18]. SDL and Estelle are based on the model of finitestate machines extended with programming language ele-ments, while Lotos is based on CCS [20] and abstract datatypes [1]. A number of protocol standards for Open Sys-tems Interconnection (OSI) have been written using thesetechniques.

This paper considers the automation of the protocol im-plementation activity (point 3) above). In Section II ofthis paper, general issues and design choices for protocolimplementations are discussed. Also different objectivesfor the implementations are considered.

Section III describes a general implementation strategyassuming that a formal specification of the protocol isgiven written in an extended state machine formalism. Forthis implementation strategy, a specification compiler hasbeen developed which translates a formal specification,written in a dialect of Estelle, into appropriate Pascalcode, to be incorporated into a Pascal program imple-menting the protocol specification. This implementationstrategy is demonstrated by a simple example for whichthe generated Pascal code is explained.A complete implementation methodology including au-

tomated and nonautomated aspects is presented in SectionIV. The application of this methodology to the implemen-tation of the OSI Transport protocol class 2 is presented.The implementation obtained through the semiautomaticimplementation methodology is compared with a similarimplementation which was developed in a traditionalmanner.

IL. ISSUES IN PROTOCOL IMPLEMENTATIONSOne advantage of formal specifications is the fact that

implementations can often be obtained in a semiauto-mated manner, as for instance described below. How-ever, different modes of executions, based on the formalspecification, may be useful for various purposes, such asthe following:

1) Traditional meaning of "implementation," wherethe communication protocol is executed for providing acommunication service in a real operational system.

2) Simulated execution of the specification: this maybe useful during the design of the protocol for analyzingthe logical correctness of the protocol [16], [27], or formaking performance simulations [28], [9]. Performancesimulations are in particular useful for determining opti-mal parameters for real implementations which are ex-pected to satisfy specific performance objectives.

3) Test trace validation during conformance testing:when a real implementation is tested for conformance withthe protocol specification, the observed sequences of in-teractions may be "compared" with the specification,i.e., the observed trace is checked in order to determinewhether it is a possible trace according to the specification[16], [271, [10].

purposes, different design choices seem to be appropriatefor realizing the execution of the specification. In the fol-lowing we only consider case 1).

In communication software design, it seems natural tomodel the structure of the software system somehow alongthe lines of the protocol architecture. This architectureoften follows the OSI Reference Model shown in Fig. 1,or a subset of the layers defined in that model. Usuallyseveral levels of protocols are involved in a given com-munication system. The communication software must bewritten in such a way that

1) all properties defined by the protocol specificationare satisfied by the system, i.e., the system conforms tothe protocol specification [23], and

2) other properties, not defined by the protocol speci-fication, are chosen and implemented in such a way as tomake the resulting system useful; in particular the follow-ing issues must be addressed:

* efficiency of operation (communication delays, max-imum throughput, memory requirements, etc.),

* appropriate interfaces to user programs,* appropriate interfaces to the underlying data trans-

mission facilities, usually through the I/O facilities of theoperating system.Because of the importance of point 2), it is difficult to

completely automate the protocol implementation pro-cess. However, the aspects of an implementation relatingto point 1) can be obtained automatically from a formalspecification, as explained below. An implementationmethodology addressing both aspects is described in Sec-tion IV.Given a formal specification of the protocol to be im-

plemented, many properties not defined are either relatedto expressions, statements, functions, or procedures notexplicitly defined (which are called "implementation de-pendent"), or to the intrinsic nondeterminism of the spec-ification. Most specification languages allow the specifi-cation of nondete'rministic systems for which severalbehaviors are possible in a given situation. In the case thatan extended FSM model is used as specification language,nondeterminism is introduced when for a given state ofthe machine and given input interaction, there may bemore than one transition that could be executed. Nonde-terminism may also be introduced by spontaneous tran-sitions which may be executed, without involving any in-put, provided that the present state satisfies a specifiedcondition. A method for implementing such transitions isdescribed in Section IV.Another important implementation issue is the overall

software architecture in terms of procedures, modules, andprocesses. This structure will usually reflect the structureof the specification. A complete protocol specification fora given layer often consists of several specification mod-ules. As an example, Fig. 2 shows the structure of theTransport protocol specification which was used for theimplementation project described in Section IV. It con-tains one AP module for each Transport connection,

990

It is important to note that for each of these different

BOCHMANN et al.: IMPLEMENTATION OF COMMUNICATION PROTOCOLS

U, URn

......................................AP

Mapping

N

Fig. 2. Structure of the Transport protocol specification.

which handles connection establishment, data transfer anddisconnection, and one common Mapping module whichlooks after the multiplexing of several Transport connec-

tion over a single Network connection. The figure alsoshows several instances of user modules Ui and module Nproviding the Network service; these latter modules rep-

resent the environment of the Transport entity.However, the protocol for a given layer is usually not

implemented in isolation, but in combination with theother protocol layers. Given that the software system cor-

responds to a large number of modules in the specifica-tion, it is important to determine how.the interactions be-tween these different modules are realized in theimplementation. Some of these modules also interact withthe environment, e.g., user programs or I/O devices.Often, the specification defines a static structure by whichthe different modules are interconnected.

Important design decisions relate to the manner in whichthese different interactions are realized. Another impor-tant design decision is the question of how many pro-

cesses are used to implement the system, and how theseprocesses communicate with one another and the environ-ment using the operating system facilities. The imple-mentation strategy discussed below provides automati-cally certain alternatives for the implementation of moduleinteractions. It assumes that several specification modulesare usually combined into a single process for implemen-tation, although in an extreme case, one process per mod-ule could be used.

III. TRANSLATING FORMAL SPECIFICATIONS INTO A

HIGH-LEVEL PROGRAMMING LANGUAGEA. Specifications Using an Extended FSM Model

It is assumed in the following that the protocol speci-fication is given in an extended finite state machine for-malism [6], as for instance Estelle or SDL. Using such a

formalism, a module of the specification can be describedas an extended finite state machine which interacts throughinput/output interactions with other modules in the sys-

tem. Alternatively, a module may also be described as

consisting of several interconnected more simple mod-ules, as for instance the Transport entity shown in Fig. 2.The behavior of each machine is described as an extendedfinite state transition machine. It may execute a state tran-

neously. During such a transition, it may also generateoutput interactions. The extensions relate to interactionparameters and additional state variables. The relation ofthe state transitions with these parameters and state vari-ables is described using a programming language notation(Pascal in the case of Estelle). For instance, an enablingcondition may be associated with a transition which maydepend on input interaction parameters and state vari-ables, and which must be satisfied if the transition is tobe executed.The output interactions generated by a given module

become input for another module of the specified systemor for the environment. The destination module is deter-mined by the interconnection structure between the dif-ferent module instances within the specified system. Usu-ally, it is possible to describe systems with static moduleinterconnection structures, such as shown in Fig. 2, butFDT's and many other languages also allow the specifi-cation of dynamically changing interconnection struc-tures.An important feature of the specification language is the

kind of module interactions assumed. Many languages as-sume that output interactions are placed in an input queueof the destination module, and the destination module willindependently consider each interaction at the head of aninput queue (Estelle allows for several input queues permodule) for execution of a corresponding transition [13],[24]. Another approach is the direct interaction model,similar to rendezvous [15], [18] where an output can onlybe generated if the destination module accepts the inter-action as input for one of its transitions.

B. A Simple Example Specification

In order to demonstrate the principles explained above,and to lead to the discussion of the translation process,this section presents a very simple specification example.It is based on the Transport protocol, but only two (out ofmany) transitions are considered.As Fig. 2 shows,_ the Transport entity is described as

consisting of one module of type AP per Transport con-nection and a single Mapping module. An (incomplete)formal specification of this Transport entity is given inFig. 3. Fig. 3(a) defines the interaction structure of theTransport entity in terms of its interaction points with theenvironment and its refinement in terms of the Mappingand AP submodules. TSAP is an array of interactionspoints, one for each possible Transport connection, overwhich the Transport service is provided to the user mod-ules. The different connections are distinguished by anindex value of type TCEP_id_type. NSAP is the inter-action point over which the Network service is used.

Fig. 3(b) shows the definition of the different kinds ofinteractions that can occur between the Transport entityand its users. The specification of the channel typeTS_primitives given here defines only two kinds of in-teractions: the TCONreq interaction by which the user

991

sition due to an input interaction received, or sponta-


module TP_entity;(* external port declarations *)TSAP array [TCEP_id_type] of TS-primitives (provider);NSAP NSprimitives (user);

end TP_entity;

(a)(* Transport service interactionstype

option_type = set of (optionl, option2);data_type = ..; (* implementation dependent *)T_address = ...; (* implementation dependent *)

channel TS_primitives (user, provider);by user:

TCONreq (dest address : T_address;proposed_options : option_type);

TDATAreq (d : data-type);

by provider:

end TS-primitives;(b)

module Mapping;P array [TCEP_id_type) of PDU_and_control (mapping);NS NS_primitives (user);

end Mapping;

(c)PDU definitions

typesequence_nb = 0 .. 255;credit_type = 0 .. 127;

channel PDU_and_control (AP, mapping);by AP, mapping:

CR (addresss T_address;options option type);

AK (TR : sequence_nb;credit : credit_type);

end PDU_and_control;

(d)module AP;

TS TS_primitives (provider);MAP : PDU_and_control (AP);

end AP;

process Mapping_process for Mapping;

end Mapping_process;

process AP_process for AP;var

state : (closed, open, wait_for_CC,*options : option type;TRseq : sequence_nb;R_credit : credit-type;

function accepted-options (requested-options option_type)option_type;

begin (* all options supported *)accepted_options := requested-options

end;

transwhen TS . TCONreqfrom closed to wait_for_CCbegin

TRseq := 0;options := accepted options (proposed options);out MAP CR (dest_address, options);

end;

transprovided true (* it is possible to send an AK,

implementation dependent choice *)from open to samebegin

out MAP AK (TRseq, R_credit);end;

end AP-process;(e)

(* process instantiations and interconnections *)Al AP with AP_process;A2 AP with AP_process;A3 AP with AP_process;A4 AP with AP_process;

M : Mapping with Mapping-process;connect

Al.MAP to M.P [1);A2.MAP to M. P [2);A3.MAP to M.P [3];A4.MAP to M.P [4];

(f)

Fig. 3. Example specification.

can request the establishment of a connection, and theTDATAreq interaction by which the user may send dataover the established connection. The notation.. . . . isused here to indicate that certain parts of the specificationare not included. The specification also introduces tworoles, user and provider. As indicated in Fig. 3(a), themodule TP entity plays the role provider for the inter-action points TSAP. It is assumed that a similar definitionis given for the channel type NS_primitives.

Fig. 3(c) shows the definition of the submodule typesMapping and AP. They are interconnected by channelsof type PDU_and_control, which are defined in Fig.3(d). Over this channel coded protocol information is ex-changed. The existing module's instances and their inter-connection structure are defined in Fig. 3(f).

Fig. 3(e), finally, shows the definition of an extendedfinite state machine specifying the behavior for a moduleof type AP. Such a behavior is called a "process." Eachmodule instance associated with this process contains thestate variables STATE, options, TRseq, and R_credit.STATE is the so-called major state variable which cor-responds to the "finite state" of the machine. Only twotransitions are shown. The first is executed when aTCONreq is received by the user. It leads to an update

of the state variables, including the new major statewait for CC, and to the generation of output of kindCR. The second transition is a spontaneous one, whichmay be executed whenever the connection is in the OPEN(major) state. It has the effect of generating an AK outputinteraction.

C. An Implementation Strategy

The implementation strategy described here applies to-the automated implementation of specifications written inan extended finite state machine language in general. Itwas used by the Estelle compiler [14] which was used forseveral implementation projects [25], [32]. The objectiveof this compiler was to translate formal specificationswritten in an Estelle-like language, as shown in Fig. 3,into Pascal procedures which would be suitable for incor-poration, without change, into a Pascal program imple-menting the protocol. A similar translation approach canbe used for other implementation languages, for exampleC.The following points present important aspects of the

implementation approach, and have a strong impact onthe structure of the implementation.

992


1) The automated translation process gives rise to oneprocedure written in the implementation language (in ourcase Pascal) for each process type in the specification.Each of the so obtained procedures can be compiled sep-arately, if the implementation language compiler supportsthat option.

2) The execution of a transition of a module instanceis performed by calling the procedure corresponding tothe process type and passing to it as parameters the inputinteraction (if any) and a record data structure which con-tains the information about the present state of the mod-ule.

3) In a given system state, a number of different tran-sitions belonging to different module instances may bepossible. The selection of the next transition to be per-formed is made by an overall transition scheduler, whichis usually part of the Pascal main program. This schedulerdetermines which module instance and which input inter-action (or spontaneous transition) will be processed, andcalls the corresponding process procedure. It is importantto note that this scheduler is not automatically generated.A simple round-robin scheduler procedure is provided aspart of the run-time support for the implementations gen-erated by the Estelle compiler; the implementor is free towrite his/her own scheduler to suit any particular imple-mentation objectives.

4) For a given input interaction and a given state of themodule instance, there are, in general, several possibletransitions. A simple method of selection is to execute thefirst possible transition in the order in which the transi-tions are defined in the specification. With such an ap-proach, the scheduler selects the module instance and theinput interaction to be processed, or possibly a sponta-neous transition is to be executed. The selection of thetransition to process a given input is performed by theprocedure implementing the module type. This selectionmay be realized by embedded case statements consideringdifferent interaction points, different kinds of interactions,and different major module states. It is also possible togenerate embedded IF statements following in lexical or-der all the transitions in the specification, testing each tosee whether it applies. These are two extreme choices fortranslating a module specification into program code.Combined approaches may often be more suitable. It isalso possible to construct a transition table including, foreach major state and kind of input, the list of applicabletransitions. This form of code is particularly compact. Therun-time support will then include a state machine inter-preter [5], which may also include facilities for step-wiseprogram execution, traces and other test instrumentation.Which of these approaches is taken for the generation ofthe program is largely a question of optimization.

5)'The record data structure which contains the stateinformation for a module instance also contains pointersto each of the surrounding module instances to which theformer is connected. These pointers are used to forwardoutput interactions generated by the module to the appro-priate receiving module instances. Two options of module

interactions are supported, queueing and "direct call."The latter is a simplified version of rendezvous where theoutputting module calls the procedure generated for thedestination module, passing the generated output as inputparameter. It is assumed that an output operation is onlyperformed when the receiving module is in a state whereit can accept the given interaction as input. It is the re-sponsibility of the designer of the specification/imple-mentation to make sure that this condition is satisfied.

6) The above considerations apply to all interactionsbetween module instances which are part of the specifiedsystem. Interactions with its environment are not easilyincluded in this general implementation scheme. How-ever, most specified systems are "embedded" systemswhich include interactions with the environment. For in-stance, the Transport protocol implementation describedin Section IV interacts with the user processes and part ofthe operating system providing the Network communica-tion service. Output to the environment is easily imple-mented by calling an implementatiQn-dependent proce-dure for output. Input from the environment can beimplemented by including spontaneous transitions in thespecification which would be called by the global sched-uler and execute the processing related to the input. Thescheduler should be aware when the external input isavailable.

7) The data structures containing the state informationof the module instances and the pointers connecting themaccording to the module interconnection structure definedin the specification are created by support routines, whichare called during the execution of the implementation. Inthe case of static system structure, these routines are calledduring the initialization phase. The initialization proce-dures are also generated by the Estelle compiler based onthe specification of the modules.

D. Translating a Specification into ImplementationCode

In order to make the above discussion more concrete,we present in detail the translation of the example shownin Fig. 3 using the translator mentioned before [14]. It isimportant to note that the specification of Fig. 3 must be"completed," as explained in Section IV-B, before thetranslation process is applied. We assume in the followingthat this has been done.

In summary, the compiler generates three categories ofstatements. First are the type declarations for the recordswhich will represent' the state of the module instances,channels, and interactions as well as the variables and typedeclarations required by the run-time support. Secondly,there are procedures which implement the processes bycode to handle the various defined transitions. Finally,there are procedures for the initialisation of the systemand the creation and linking of the various data structures.

Details of the generated code are shown in Figs. 4 and5. Fig. 4 shows the declarations generated by the com-piler. Lines 1-38 show the type declaration SOTYPE forthe records which represent the interactions in the speci-

993


SITYPE - 'SOTYPE;SOTYPE -

RECORDNEXT: SITYPE;CASE CHANNEL OF

C2TS prii1tives:(CASE T2TS_primitives: S2TS primitives OF

S2TCONreq:(D2TCONreq:

RECORDdest_address: T_address;proposed opt ions opt ico type

END);S2TDATAreq:

(D2TDATkreq:RECORD

d: dats typeEND); );

CIPDU and control:(CASE TIPDU snd control:

SIPDU and control OFSICR:

(D1CR:RECORD

address: T_address;options: option type

END);SIAK:

(DI AK:

RECURDTR: sequence nb;credit: cred it_type

END); );

COAP process:

(CASE TOAP_process: SOAP_process OF

R1ANY:0; );

END;

PITYPE - POTYPE;POTYPE

RECORDIDENT: P2TYPE;CHANLIST: CITYPE;NEXT, REFINEMENT: PITYPE;CASE PROCESS OF

POMapping process:

0;POAP process:

(DOAP_process:RECORD

STATE: (closed, open,

wait for CC);opt ions: opt ion_type;

TRseq; sequence_nb;R credit: credit_type;

END);END;

60 VAR61 POVAR: PITYPE;62 COVAR: CITYPE;63 SOVAR: SITYPE;

Fig. 4. Declaration code produced by FDT compiler.

fication. Each interaction primitive defined in the originalspecification is implemented as a variant of that declara-tion. Note the presence of a system attribute, NEXT inline 4, required by the implementation in addition to thevariant fields that reproduce exactly the fields present inthe original specification (lines 11-12, 17, 25-26, and 31-32). To handle the use of identical field names in differentinteractions, the user fields are not inserted directly in thevariant for each interaction; rather, they are grouped in a

dummy record (for example: D2T CONreq in line 9)which then appears as the only attribute of each variant(S2T_CONreq in this case).Another point to notice in the SOTYPE declaration is

the definition of an empty variant, COAP_process (lines

2

3

678910II

12131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778

PROCEDUIE A?_process;

LABEL1;

VARCIVAR: CITYPE;SIVAR: SITYPE;

FuNCTLON accepted opt ions( requested opt ions: opt ion_type):option type;

BEGCNWITH POVAR^.DOAP_process Do

BEGINaccepted_options : requested_options;END

END;

BEGINCIVAR COVAR;SIVAR : SOVAR;WITH POVAR'.DOAP_process DO

BEGINIF COVAR-.IDENT a I THEN

IF SOVAR .T2TS przimtives - S2TCONreq THENWITH SOVAR .D2TCONreq DO

BEGINIF STATE IN [closed) THEN

BEGINSTATE : wait_for_CC;TRseq : 0;

options :- accepted options(proposed_opt ions);BEGlN

POPROCEIDUREM2);NEW(SOVAR, CIPDU and control,SICR);SOVAR .T1PDU and_control :- SICR;SOVAR .DClR.address : dest address;SOVAR- .DICR.opt lons :- options;OUT

END;GOTO 1; END;

END;IF true THEN

BEGINIF STATE IN [open] THENBEGINIF COVAR . IDENT - 0 THEN

IF SOVAR'.TOAP_process RIANY THENBEGINBEGIN

POPROCEDUREJ(2);NEW(SOVAR, CIPDU_and control,SIAK);SOVAR'.TIPDU and control :- S1AK;SOVAR .DIAK.TR : - TRseq;SOVAR'.DIAK.credit :- R_credit;OUT

END;GOTO 1;END;

END;END;

END:1:

CASE C1VAR' . IDENT OF0:

CASE S1VAR .TUAP_process OFRIANY:

DISPOSE(S1VAR, COAP_process, RIANY);END;

1:CASE SIVAR .T2TS_pra1itives OF

S2TCONreq:DISPOSE(SIVAR, C2TS_priattives,

S2TCONreq);END;

END;END;

Fig. 5. Procedure generated by FDT compiler.

34-37), which does not correspond to any explicit chan-nel or interaction definition in the original source code.This variant is generated to handle the spontaneous tran-sition in the AP process process. Spontaneous transi-tions are treated as special interactions on a channel 0 and

23456789101112

-131415161718192021222324252627282930313233343536373839404!1424344454647484950515253545556575859

994


dummy variants are generated for each spontaneous tran-sition present in the specification.The second part of Fig. 4 shows the type declaration

POTYPE for the data structures which will represent themodule instances during execution. For each module typedefined, a variant is added to the POTYPE declaration.The same technique outlined for the interactions is usedhere and user declared local attributes appear withoutchange within a dummy record in each variant. The attri-butes for the APprocess module of Fig. 3(e) are shownin lines 49-57. There is also an empty variant (lines 47-48) for the Mapping module present in the full examplespecification. There are 4 system attributes (lines 43-45)present in all process records; these are used by the runtime routines to identify, build and link the data structuresmodelling the specified system.

Finally, in lines 61-63, are shown three key globalvariables which determine the context for any transition.During execution, these pointers (POVAR, COVAR andSOVAR) will contain respectively the addresses of thecurrent module instance, the current channel whose inter-action is being treated, and the current interaction itself.These are the only global variables shared by all routinesin the system.

Fig. 5 shows the procedure generated to handle thetransitions for the AP_process module. The procedureassumes that its context (POVAR, COVAR, and SO-VAR) has been set up correctly before the procedure iscalled. For each defined transition, a section of code isgenerated. The example has two transitions: the first, trig-gered by the receipt of a T CONreq interaction, leads tothe code in lines 25-43 and the second, a spontaneoustransition, leads to the code in lines 44-62. All proce-dures begin with a partial saving of context (lines 21-22)so that the environment is not lost when the output pro-cedure modifies the values ofCOVAR and SOVAR. Thereis also a WITH statement on the correct variant of thecurrent module (line 23) so that local module variablesmay be referred to directly within the procedure body.

Creation and destruction of the interaction recordswhich transfer information between module instances isimplemented completely within the generated "module"procedures. At the end of each such procedure (lines 64-77) in this case) Pascal code is generated to dispose ofany interactions the process may receive. It is in the na-ture of the Pascal language that for each variant of a rec-ord type, a separate DISPOSE statement is needed wherethe value of the variant tag is expressed as a constant (itis not possible to use a general-purpose DISPOSE state-ment where the variant tag would be expressed as a vari-able). Generation of this specific disposal code is an im-portant task of the compiler.Each transition follows the same pattern. The code is

preceded by tests on the identity of the received interac-tion and that of the received interaction and that of thechannel upon which it came. To this may be added tests

A WITH statement on the input (line 27) allows the re-ceived interaction attributes to be used directly in the tran-sition statements. At the end of the transition a "GOTO1" statement passes control to the data record disposalcode. For a spontaneous transition (lines 44-62), the pat-tern is the same except that the "spontaneous" channel 0is used and the interaction is a "pseudo" interaction withno attributes internally generated by the system.Another aspect shown in Fig. 5 is the implementation

of the output statement (lines 34-41 and 51-58). The in-teraction to be sent is first created (line 53) and its datafields are initialized (line 54-56). The call to the libraryprocedure POPROCEDURE (line 52) had located chan-nel MAP (assigned the number 2 by the compiler) and hadplaced its address in COVAR. The output routine usesdata in the Channel data structure to place the interactionin the right reception queue. If a channel with rendezvousis specified, the procedure representing the recipient mod-ule is called directly at this point. If the channel usesqueued interactions, control returns immediately to thesender; the recipient being activated later by the schedulerwhen it comes upon the pending interaction in its scan ofchannel queues.

E. Translation IssuesThe above example gives a simplified introduction to

code generated for Estelle specifications. In general, thetranslation process is more difficult, in particular when thefull power of the specification language is taken into ac-count. A number of specification translators have been orare being built for Estelle and similar languages [5], [3],[14], [4].The Estelle compiler described here [14] is partitioned

into the usual phases of lexical, syntactic, and semanticanalysis, optimizations, and code generation. The syntaxanalysis phase creates an internal representation of thespecification in the form of a tree structure. The nodes ofthe tree are characterized by semantic attributes which areevaluated during the subsequent semantic analysis phase.During this phase, certain semantic conditions are alsochecked. The compiler only verifies those semantic con-ditions which would not be validated by the subsequentPascal compilation of the generated Pascal program. It isnoted, however, that it would be more convenient to havea complete verification of the static semantics by the spec-ification compiler. Certain optimizations may be per-formed on the internal representation of the specification.For instance, the different transitions could be sorted in aspecific order to make the generated code smaller or moreefficient. The code generation phase is relatively straight-forward, in particular for those parts of a specificationwhich are already essentially written in the Pascal nota-tion, such as the actions of transitions, or the expressionsin PROVIDED clauses. However, there are certain as-pects of the specification language which are more diffi-cult to handle, such as the following.

corresponding to PROVIDED or FROM clauses (line 29).

.995

There seems to be no simple translation scheme which


correctly handles Estelle's scope rules in relation with theWHEN clause and the associated input parameters. Ourcompiler simply generates a Pascal WITH statementwhich opens a scope containing the parameter names.However, this approach does not work when the samenames are also used for formal parameters or local vari-ables in a procedure declared within the transition.Another problem related to scope rules is due to the

identifiers of certain run-time utility procedures, vari-ables, and types. These identifiers are referenced in thegenerated Pascal code. For instance an <output> pro-cedure is used for generating an output interaction. There-fore, the inadvertent use of the same identifiers for otherpurposes in the specification leads to problems. One (un-satisfactory) solution is to prohibit the use of these pre--defined identifiers in specifications.

In addition, the compiler generates certain additionalidentifiers which correspond to parts of the specification.These identifiers should never be in conflict with the otheridentifiers of the specification which remain present in thetranslated Pascal code; they should also have a mnemonicform closely resembling the part of the specification whichthey represent. Our compiler forms such identifiers bypreceding the original name by a fixed character and anumber which is used to distinguish different cases (seefor example Fig. 4). There seems to be no completelysatisfactory solution, in particular if the generated codeshould be compilable by a Pascal compiler that distin-guishes identifiers based on only its first (say) 10 char-acters.The run-time utility procedures which are used for cre-

ating the interconnection structure between modules dur-ing the initialization of a system have to work with anytype of module and channel. They are a kind of genericprocedures which are difficult to write in the Pascal pro-gramming language.

IV. PROTOCOL IMPLEMENTATION METHODOLOGYIt is important to note that the automated translation of

specifications, as described above, covers only part of theimplementation effort. As mentioned before, there are as-pects of an implementation which are not described by thespecification and which must be chosen during the imple-mentation phase. These aspects are discussed in this sec-tion. We first present a Transport protocol implementa-tion which was developed in a traditional, ad hoc manner,although a formal specification of the protocol was usedas a basis for certain parts of the code. A systematic meth-odology for implementing protocols in several steps ofrefinement and based on a formal specification is then de-scribed. It was subsequently applied to the same Trans-port protocol together with the automated specificationtranslation approach described above. A comparison ofthese two implementations is also given.

A. An ad hoc Implementation Based on a FormalSpecificationThe structure of this implementation [25] of the OSI

Transport protocol classes 0 and 2 is shown in Fig. 6. The

.U

dsapletion ( transport service)

Intertusk A AR

commu- inication Mapping

coding/decoding ( transport PDU andnetwork service

N

Fig. 6. Structure of "manual" implementation.

logical behavior of the AP and Mapping modules is basedon the formal Transport protocol specification given in[7]. The Transport entity is a single task in the operatingsystem, communicating through operating system primi-tives with a task providing the Network service, and sev-eral user tasks which may establish one or several Trans-port connections with remote systems through theTransport entity.The interactions between the different tasks is based on

message exchange provided by the operating system. Forthe original implementation which was running on a PDP-11 computer, the user data was not directly included inthese messages, rather pointers to data buffers were passedbetween the tasks. The data buffers were allocated inshared memory by the task first generating the data, orreceiving it through external I/O primitives, and wereshared among all the processes using the data [19].

Overall, the program handles the incoming events in anasynchronous manner. Messages received by the task orinternal time-outs give rise to event interrupts whichschedule corresponding event handling routines which inturn call the procedures implementing the protocol. Thiskind of program structure is efficient and relatively trans-portable. In fact, the program was subsequently trans-ported to run under VMS on a VAX, and it is presentlyported to run under Unix. Only the intertask communi-cation package had to be adapted for each of these newenvironments.The experience of this implementation showed that the

availability of a formal specification simplifies signifi-cantly the implementation process; however, only part ofthe implementation is directly related to the formal spec-ification. Much time was spent in the development of theinterfaces with the operating system for interaction withthe user processes and the Network communication ser-vice, including buffer management. Another importantpart, not included in the formal specification, is the cod-ing and decoding of PDU's. The size of the Pascal sourcecode for these different program sections is given in TableI.

B. Implementing Protocols by Stepwise Refinement ofSpecificationAlthough the number of steps to be used for going from

a protocol specification to the implementation code may

996


TABLE ISIZE OF DIFFERENT PARTS OF Two TRANSPORT PROTOCOL

IMPLEMENTATIONS

(A) ad hoc (manual) implementation approach(B) implementation using the specification compiler

Number of Program sizesource lines (in octets)

Part of program (A) (B) (A) (B)

(a) PDU de- and en-coding 3 000 3 000 11 940 11 940

(b) Code corresponding to thetransitions of the formalspecification 3 000 5 500** 17 800 29 306

(c) Buffer management andO/S interfaces forintertask communication 3 000 3 000 3 974 3 974

(d) Run-time support routines 1 000 1 400*** 2 324 3 452

(e) main program 1 000 400 6 468* 3 282*

Notes:including static variablesthis part of the code is automatically obtained bytranslation of the -detailed specification (see Section 4.2)this part of the code is fixed (independent of thespecification) and comes with the specification compiler

vary in different cases, we propose a methodology whichidentifies the following steps:

1) Preparation of a detailed specification,2) Adaptation to the implementation environment,3) Program code creation, and4) Testing.

Each of these steps is further discussed below.1) Detailed Protocol Specification: As further ex-

plained in [26], the objective is to obtain a detailed spec-

ification which would be valid for a large number of im-

plementations of the protocol in question. However,compared to the protocol specification, it is more detailedand specific, i.e., the available choices are reduced. Theprotocol specification should only describe properties thatmust be satisfied by all conforming protocol implemen-tations, and it should be designed in such a manner thatany two communicating implementations that conform tothe specification will provide the corresponding commu-

nication service (see point 2) in the Introduction).It seems that the following aspects can normally be de-

scribed in the detailed specification:a) More detailed specification of the local service in-

terfaces with the protocol layers below and above;b) Identification of all error cases (in addition to those

already described in the protocol specifications) and def-inition of the corresponding error handling (in particular,the handling of unexpected interactions from the user

module);c) The handling of the spontaneous transitions.Point a) includes in particular the definition of certain

data types which have been left undefined by the protocolspecification, such as data type and T_address in Fig.3. It may also include the definition of certain implemen-tation-dependent procedures and/or functions, or the def-inition of supplementary service primitive parameters.A protocol specification usually indicates the required

behavior of the protocol entity in the case of certain errors

committed by the peer protocol entity. However, oftenthese indications are relatively vague, and more precise

choices must be made for any implementation. In addi-

tion, erroneous behavior of the user and/or underlyingcommunication service may be foreseen. The detailedprotocol specification should define the behavior of theprotocol implementation for these situations.As mentioned in Section III-B, a spontaneous transition

may be executed any time its enabling condition is satis-fied. For efficiency reasons, however, an implementationshould normally select appropriate instants for the exe-cution of the defined spontaneous transitions. The strat-egy for doing this should be defined in the detailed pro-tocol specification.For example, Fig. 3 contains one spontaneous transi-

tion for sending acknowledgments which is enabledwhenever the connection is in the OPEN state. The as-sociated PROVIDED clause is completely implementa-tion dependent. In fact, the strategy for sending acknowl-edgments can have an impact on the end-to-endtransmission delay, on buffer management at the sendingand receiving sites, and on the cost of communication.Therefore, an appropriate acknowledgment scheme mustbe selected depending on the performance requirementsof the protocol implementation. In practice, the sponta-neous transition could for instance be executed wheneveran additional buffer (and therefore additional credit) isavailable.

In general, a spontaneous transition has a PROVIDEDclause of the form PROVIDED <boolean expres-sion>, and whether it is enabled may depend on addi-tional state variables included in the expression. The fol-lowing systematic approaches to the handling ofspontaneous transitions may be considered (it is noted thatsuch choices must be made whether a specification com-piler is used, or not):

a) Considered all spontaneous transition for executionat regular time intervals.

b) Maintain two lists of spontaneous transitions, calledactive and passive. Initially, the active list contains allspontaneous transitions. Transitions from the active listare considered for execution at regular time intervals. Ifone of them is not enabled at that time, it is placed on thepassive list. A transition from the passive list is put onthe active list when the execution of the transition mayhave led the effect of changing the state variables in sucha manner as to make the enabling condition of the spon-taneous transition true. An analysis of the data flow be-tween the actions of all transitions (which may update thestate variables) and variables used in the enabling condi-tions of the spontaneous transitions should be made in or-der to determine whether, after the execution of a giventransition, one of the passive transitions should be madeactive.

c) Maintain a try list of spontaneous transitions. A dataflow analysis similar as for point 2) above should be usedto determine, after the execution of a given transition,which spontaneous transition may be enabled due to theaction of the executed transitions. All those spontaneoustransitions are placed on the try-list and are considered forexecution before the next input transition is executed. Itis noted that the data flow analysis may be done in an

997


informal manner by the person writing the detailed pro-tocol specification. Operations of the form "try transition< number> ", which have the effect of putting the indi-cated spontaneous transition into the try-list, may be in-cluded in the definition of the transition actions. This lat-ter strategy has been used for the Transportimplementation described in Section IV-C.

2) Adaptation to the Implementation Environ-ment: While it can be expected that many design choicesmade at the level of the detailed protocol specification maybe applicable for a large number of different implemen-tation projects in different implementation environments,the next step involves the adaptation to the particular run-time environment. Buffer management issues and oper-ating systems interfaces must be considered in detail, in-cluding interprocess (task) communication.The partition of the communication software into sev-

eral processes must be decided at this level. Fig. 6 showshow the interprocess communication interfaces were in-cluded in the software structure of the Transport protocolimplementation developed with the Estelle compiler (seeSection IV-C). The formal specification of the Transportprotocol was completed by the addition of two interfacemodules which include environment-specific routines forsending and receiving messages from the other processesin the system.

3) Program Code Creation: Based on the formal spec-ification of the protocol, which has been completed as de-scribed above, the implementation code can be producedmanually, or through a specification compiler. It is notedthat the manual programming task is usually much sim-pler based on a formal specification than when it is basedon an informal protocol specification.

4) Protocol Implementation Testing: Protocol imple-mentation testing usually proceeds in several stages. De-bugging testing is often performed using an interactivetesting tool by which arbitrary peer and user interactionscan be generated and the output of the implementationunder test (IUT) be observed. Afterwards, the implemen-tation may be submitted to conformance test [23] whichis usually executed in a largely automated manner.

It is important to note that certain tests can be executedbased on the formal protocol specification or the detailedprotocol specification if a suitable execution support ex-ists for the specification language. Any errors found inthese specifications may be corrected before the more de-tailed steps of the implementation proceeds. If the de-tailed specification is shared for many implementationprojects, they may all benefit from less error-prone spec-ifications.

C. A Semiautomatic Transport ImplementationIn order to evaluate the usefulness of the Estelle com-

piler for the automatic generation of parts of a protocolimplementation, the same formal specification that wasthe basis for the implementation described in Section IV-A was also used for generating an implementation withthe Estelle compiler described above.

The same buffer management and intertask communi-cation routines were used in order to make a comparisonbetween the two implementations more meaningful. Theresulting program sizes are shown in Table I (column B).It is noted that only row 2 is generated by the specificationcompiler, and row 4 is a fixed set of run-time supportroutines. Rows 1 and 3 are the same in the two imple-mentations. As the table shows, the transition code gen-erated by the compiler is larger than the correspondingcode of the hand-coded implementation, but it turned outto be of a more regular structure.As the above table shows, the buffer management and

intertask communication routines are relatively complex.However, as explained in Section III-C, the specificationcompiler allows the integration of several separately spec-ified modules into a single Pascal program. The imple-mented Transport protocol entity, for instance, consistsof one Mapping module and several AP modules, asshown in Fig. 6. Also, the specifications of the protocolsfor several layers could be combined into a single pro-gram (task). This would reduce the intertask communi-cation overhead associated with an implementation whereeach layer protocol would be implemented in a separateprogram.

It is interesting to note that about half of the overallprogram code were generated by the specification com-piler. It is also interesting to note that most errors foundafter the initial debugging phase were related to the en-vironment-specific parts of the specification. This indi-cates that the detailed formal specification contained rel-atively few errors [26].

V. DIsCUSSION AND CONCLUSIONSThe availability of the formal specification of a protocol

can be useful for the validation of the protocol design, aswell as for protocol implementation and testing. This pa-per discusses the semiautomatic implementation of pro-tocols based on their formal specification. It is importantto note that a protocol specification usually leaves impor-tant design decisions unspecified; these design decisionsmust be made for each implementation of the protocol de-pending on the particular implementation requirements.As discussed in Section IV-B, protocol specificationswritten in a formal description technique (FDT) may berefined in several steps until an implementation-orientedspecification is obtained.

It is sometimes argued that specifications in Estelle tendto appear "implementation oriented," in the sense thatthey imply certain design decisions which are a matter ofimplementation [17]. Real implementations adopting thesedecisions can be obtained semiautomatically, as describedin the paper. However, it is conceivable that other imple-mentations would use different implementation choices.Their automated generation would require automatic pro-gram transformations, which are more difficult to realize.SDL has similar characteristics as Estelle. However, mostexisting specifications written in SDL describe the "datapart" informally, which implies that this important part

998


cannot be processed automatically. Other specificationlanguages, such as Lotos, are primarily intended for moreabstract specifications. So-called "wide band" languagesare designed with the aim to be suitable for writing ab-stract specifications which can be transformed, within thesame language, into implementation-oriented designs andcode [31].The implementation strategy using the stepwise refine-

ments described in Section IV-B can be applied with anyof the above languages. An important saving in imple-mentation effort can be obtained if an existing formal pro-tocol specification, or (better) detailed specification, canbe used as starting point for the implementation project.The translation methodology described in Section III is

largely adapted to specifications written in an extendedfinite state machine formalism. As discussed in SectionIV in relation with the Transport protocol implementa-tions, a specification compiler can produce readable codewhich is relatively efficient in space and run-time. How-ever, it is also clear that it would not be used in caseswhere high-performance implementations are desired.

Further experiences with the semiautomatic implemen-tation approaches are underway. Areas which need par-ticular attention include the following:

1) The automatic inclusion of testing facilities withinthe generated implementations.

2) Efficiency improvements in the generated code re-lated to interactions between different module instances.An implementation language with generic types or lessstrong typing rules than Pascal seems to be useful here.

3) Integration, within the specification language and itscompiler, of PDU coding and decoding facilities based onthe ASN1 notation 12] for OSI Application layer proto-cols. This would allow for automatic code generation forpart (a) in Table I.

REFERENCES

[1] H. Ehrig and B. Mahr, Fundamentals ofAlgebraic Specifications, vol.1. New York: Springer-Verlag, 1985.

[2] Information Processing-Open Systems Interconnection-Specifica-tion of Abstract Syntax Notation One (ASN. 1), ISO DIS 8824.

[3] J. P. Ansart, V. Chari, and D. Simon, "From formal description toautomated implementation using PDIL," in Protocol Specification,Testing and Verification (IFIP/WG6. 1), H. Rudin and C. H. West,Eds. Amsterdam, The Netherlands: North-Holland, 1983.

[4] J. P. Ansart et al., "Software tools for Estelle," in Protocol Speci-fication, Testing and Verification VI, B. Sarikaya and G. Bochmann,eds. Amsterdam, The Netherlands: North-Holland, 1986, pp. 55-62.

[5] T. P. Blumer and R. Tenney, "A formal specification technique andimplementation method for protocols, " Comput. Networks vol. 6, no.3, pp. 201-217, July 1982.

[6] G. v. Bochmann, "A general transition model for protocols and com-munication services," IEEE Trans. Commun., vol. COM-28, no. 4,pp. 643-650, Apr. 1980; reprinted in Communication Protocol Mod-eling, C. Sunshine, Ed. Dedham, MA: Artech House, 1981.

[7] -, "Example of a Transport protocol specification," prepared forCERBO Informatique Inc. under contract for Department of Com-munications Canada, Oct. 1982.

[8] -, "Usage of protocol development tools: The results of survey"(invited paper), presented at the 7th IFIP Symp. Protocol Specifica-tion, Testing and Verification, Zurich, Switzerland, May 1987.

[9] G. v. Bochmann, D. Ouimet, and J. Vaucher, "Simulation for vali-dating performance and correctness of communication protocols,"Dep. d'IRO, Univ. Montreal, Tech. Rep., 1987.

[10] G. v. Bochmann, R. Dssouli, and J. R. Zhao, "Trace analysis forconformance and arbitration testing," IEEE Trans. Commun., sub-mitted for publication.

[11] G. v. Bochmann and J. P. Verjus, "Some comments on "transition-oriented" vs. "structured" specification of distributed algorithms andprotocols," IEEE Trans. Software Eng., to be published.

[12] G. J. Dickson and P. de Chazal, "Application of the CCITT SDL toprotocol specification," Proc. IEEE, Dec. 1983.

[13] Estelle: A Formal Description Technique Based on an Extended StateTransition Model, ISO DIS 9074, 1987.

[14] G. Gerber, "Une methode d'implantation automatisee de systemesspecifies formellement," M.Sc. thesis, Univ. Montreal, 1983.

[15] C. A. R. Hoare, "Communicating sequential processes," Commun.ACM, vol. 21, no. 8, pp. 666-677, Aug. 1978.

[16] C. Jard and G. v. Bochmann, "An approach to testing specifica-tions," J. Syst. Software, vol. 3, no. 4, pp. 315-323, Dec. 1983.

[17] L. Kovacs and A. Ercsenyl, "Specification versus implementationbased on Estelle," ACM Comput. Commun. Rev., vol. 16, no. 4, pp.4-22, July 1986.

[18] LOTOS: A Formal Description Technique, ISO DIS 8807, 1987.[19] M. Maksud, "Operator's manual for the interaction transport tester,"

prepared for CERBO Informatique Inc. under contract for the De-partment of Communications of Canada, 1984.

[20] R. Milner, A Calculus of Communicating Systems (Lecture NotesinComputer Science, No. 92). New York: Springer-Verlag, 1980.

[21] Reference Modelfor OSI, ISO IS 7498, 1982.[22] H. Partsch and R. Steinbrueggen, "Program transformation sys-

tems," ACM Comput. Surveys, vol. 15, no. 3, Sept. 1983.[23] D. Rayner, "A system for testing protocol implementations," Com-

put. Networks, vol. 6, no. 6, Dec. 1982.[24] Recommendation Z. 100, CCITT SG XI, 1987.[25] J. M. Serre, "Methodologie d'implantation du protocole Transport

classe 0/2," M.Sc. thesis, Dep. d'IRO, Universite de Montreal,1985.

[26] J. M. Seere, E. Cemy, and G. v. Bochmann, "A methodology forimplementing high-level communication protocols," in Proc. 19thHawaii Int. Conf. Syst. Sci., Jan. 1986.

[27] H. Ural and R. L. Probert, "Automated testing of protocol specifi-cations and their implementations," in Proc. ACM SIGCOMM Symp.,1984.

[28] J. Vaucher and G. v. Bochmann, "A simulation tool for formal spec-ifications" (27 pages + annexes), prepared for CERBO InformatiqiieInc. under contract for the Department of Communications Canada,1984.

129] C. A. Vissers, G. v. Bochmann, and R. L. Tenney, "Formal descrip-tion techniques by ISO/TC97/SC16/WGI ad hoc group on FDT,"Proc. IEEE, vol. 71, no. 12, pp. 1356-1364, Dec. 1983.

[30] C. Vissers and L. Logrippo, "The importance of the concept of ser-

vice in the design of data communications protocols," in Proc. IFIPWorkshop Protocol Specification, Verification and Testing, Toulouse,1985. Amsterdam, The Netherlands: North-Holland.

[31] F. L. Bauer et al., Towards a Wide-Spectrum Language to SupportProgram Specification and Program Development (Lecture Notes inComputer Science, No. 69). New York: Springer-Verlag, 1979, pp.543-552.

[32] G. v. Bochmann, "Semi-automatic implementation of transport andsession protocols," Comput. Standards and Interfaces, vol. 5, pp.343-349, 1987.

Gregor v. Bochmann (M'82-SM'84) received theDiploma in physics from the University of Mun-ich, West Germany, in 1968, and the Ph.D. de-gree from McGill University, Montreal, P.Q.,Canada, in 1971.

He has worked in the areas of programminglanguages and compiler design, communicationprotocols, and software engineering. He is cur-

rently Professor in the Department d'Informatiqueet de Recherche Operationnelle, Universite deMontreal. His present work is aimed at design,

implementation, and testing methods for communication protocols and dis-tributed systems. During 1977-1978, he was a Visiting Professor at theEcole Polytechnique Federale, Lausanne, Switzerland. During 1979-1980he was a Visiting Professor in the Computer Systems Laboratory at Stan-ford University, Stanford, CA.

999


George Walter Gerber was born in Berne, Swit-

zerland, on August 23, 1954. He received the Di-

s ploma in mathematics from the Swiss Federal In-stitute of Technology (ETH Zurich) in 1978 and

the M.Sc. degree in computer science from the

University of Montreal, Montreal, P.Q., Canada,in 1983.

From 1978 to 1981 he was with the Develop-ment Divisiop for Building Automation at Landis& Gyr, Zug, Switzerland, as a Software Special-ist. From 1982 to 1983 he was a Research Assis-

tant at the Department of Computer Science and Operations Research ofthe University of Montreal, focusing on formal languages, compilation,and communication protocols. Since November 1983 he has been at CE-PEL, Brazilian national research centre for electric energy, in Rio de Ja-neiro, where his work encompasses protocol specification, implementationand testing, and power plant and substation automation. His research in-terests include communication protocols, distributed systems, and auto-mation.

Jean-Marc Serre finished his Mastet thesis inHI 1985 with Professors Eduard Cerny and Gregor v.

_ Bochmani at the University of Monitreal, Mon-~'treal, P.Q., Canada.

g lll He worked from 1983 to 1986 as a ResearchAssistant of P-rofessor Bochmann, implementingvarious transport protocols classes and confor-

nmance testers using FDT techniques. Some ofthose programs were used to perform internationalOSI tryouts with Sweden, Japan, England,

Australia. Fromi the beginning oif 1986 to 1987 h~eworked as a Programmer Analyst for CWARC, a Canadian governmentowned R&D center. He is currently working for Bell Northern Researchon network management standards.

1000

ieee on semiautomatic implementation communication protocols

Documents