Development of Complex Communications

Development of Complex Communications Protocols Using Estelle O. Catrina

E. Borcoci

International University in Germany School of Information Technology D-76646 Bruchsal, Germany E-mail: [email protected]

Politehnica University of Bucharest Faculty of Electronics and Telecommunications 1-3 Iuliu Maniu, Bucharest, Romania E-mail: [email protected]

Abstract During the decade that has elapsed since its standardisation by ISO, the Estelle formal description technique has been successfully applied to the development of various communications protocols. We present in this paper a protocol engineering methodology that has resulted from the use of Estelle in several projects, involving the specification, validation, performance analysis and implementation of real-life, complex protocols. The methodology is based on the support offered by the Estelle Development Toolset (EDT). It gradually evolved, in parallel with the continuous enhancement of EDT, aiming to provide a protocol engineering environment that consistently supports the entire development process. We outline in the paper the principles of the methods and illustrate them with examples of their application to the development of an innovative transport protocol with multicast and multimedia capabilities. Keywords FDT, Estelle, validation, performance evaluation, FDT-based implementation

1. Introduction Computer aided software engineering tools based on formal description techniques (FDT) can provide essential support for developing communications protocols and distributed systems. Ideally, this support should extend to all the development phases, from requirements capture and design (formal description and validation), to performance evaluation, implementation (automatic code generation) and conformance testing (automatic test generation). The tools gradually mature and become able to cope with industrial applications, but the user still encounters frustrating limitations and contradictions. For example, the design phase produces a simplified or partial formal description, due to limitations of the validation method and/or the FDT, while the automatic implementation requires a complete (yet correct) specification. For complex systems, this gap results in coding the implementation or a large part of it by hand. Also, classical FDT based approach focused on functional properties, neglecting quantitative, real-time properties. A different model is needed for performance analysis (e.g., queuing networks), resulting in substantial additional effort for developing and maintaining it during the design process. However, a trend towards an integrated FDT based methodology can be observed, e.g., in the tools using the standard FDTs Estelle [1] and SDL [2]. An Estelle model of a system is a hierarchy of communicating extended finite state machines, with a rigorous operational semantics. The current standard syntax is similar to that of the Pascal programming language. A graphical syntax has also been proposed [3]. Recent enhancements of the Estelle Development Toolset (EDT) [4] allow a more consistent support of the protocol engineering process, from formal specification to prototype implementation, with performance evaluation in early design phases. Moreover, several case studies have confirmed the applicability of this methodology to real-life, complex protocols. The first case study was dedicated to the Xpress Transport Protocol (XTP) version 4.0 [5]. It consisted of an Estelle specification and validation [6], a performance evaluation by

1

simulation [7] and an automatic derivation of a fully functional implementation [8]. XTP 4.0 covers the services of existing transport protocols (TCP, UDP), includes new features needed by modern applications (reliable multicast) and accommodates various communications paradigms, media requirements and network properties. It is currently proposed for standardisation by SMPTE (Society of Motion Picture and Television Engineers), USA. We use XTP as a running example in this paper. However, the methods we describe include enhancements that have resulted from recent work for extending the OSI-TP protocol [30] with nested transaction models [9] and for evaluating the performance of the SSCOP protocol [10, 31]. We start with an overview, in section 2, of the EDT components involved in the methods presented. In section 3, we introduce the example application, the XTP Estelle specification. The validation method, described in section 4, supports the incremental development of complex Estelle specifications. Essential aspects of the system's behaviour are expressed as dependence relations between events. They serve to jointly specify guiding constraints, delimiting the simulated functionality, and correctness requirements, describing the expected behaviour. Automata derived from these specifications are implemented as observers using the script language of the EDT simulator (Edb). They run synchronised with the simulated system, applying the guiding constraints and checking if the correctness requirements are satisfied. For an incremental development of the specification, collections of guiding and verification scripts are created at each phase and run as non-regression tests in batch mode. Section 5 describes the performance analysis method, aimed at assessing quantitative and real-time properties of the designed system, by simulation with the Estelle specification. Edb scripts dynamically configure the simulated system with real-time parameters, measure relevant quantities during simulation experiments and display various performance metrics in a graphical form. We introduce a taxonomy of performance analysis goals, then discuss an EDT based approach and illustrate it with examples from several case studies. For automatic implementation, discussed in section 6, we have identified three main issues: preserve the correct behaviour obtained by validation, match the runtime properties required by the application and integrate the generated code in particular implementation contexts. We have experimented with pragmatic solutions, using libraries of primitives, to obtain an XTP implementation functionally comparable with SandiaXTP, hand-coded in C++ [28]. We conclude, in section 7, by assessing the current results and identifying future work.

2. EDT overview Figure 1 depicts the main EDT components involved in validation, performance evaluation and implementation, as well as the interactions between them. The Estelle Compiler (Ec) checks the specification for static errors, translates it into the intermediate form (Translator tool) and then generates C language source code (C-code Generator tool). The resulting C code is used both for simulation and for implementation. The Estelle Simulator/Debugger (Edb) builds a simulator program, used for the validation of the specification and for the performance evaluation. It permits interactive and free-run simulations with random selection of the fired transition (without storing the visited states). For interactive simulations, manual selection of the fired transition is also possible. Edb offers a script language that can be used in command line mode or for writing scripts. Various commands are provided, to visualise or modify elements of the current global situation, accessed through predefined functions, and to control the simulation. The commands can be grouped into macros and can be embedded in decision and loop constructs. The Edb observers are scripts that can be automatically executed after each computation step. They play an essential role in automating simulation experiments. A subset of Edb predefined functions

2

and commands supports performance evaluation. The Estelle specification is dynamically annotated, by assigning transition execution and system management duration, with several distribution laws, and relative execution probabilities, for concurrently fireable transitions. Macros written using the Edb script language assign the parameters needed for evaluation at simulation time, and Edb observers collect the results during the simulation experiments. Estelle specification (spec.stl) Estelle Translator System environment generation for simulation

Intermediate form (spec.if)

Ug Ec

User libraries Simulation commands

Edb

Simulation kernel

C code Generator

C code (*.c, *.h, spec.mk)

System splitting for implementation

Ug User libraries Implementation kernel C compiler Link editor

C compiler Link editor

Executable code for implementation (spec)

Executable code for simulation (spec.edb)

Figure 1. The main components of the Estelle Development Toolset, involved in the validation, performance evaluation and implementation. The Universal Generator (Ug) includes several functions that can be viewed as separate tools: test driver generation, splitter, decompiler. The test driver generator produces generic Estelle models for the system's environment that can be used for interactive simulations. The user is thus spared the effort of writing Estelle specifications for the environment. The splitter participates in the automated implementation of the specification. EDT maps an Estelle system module instance (SYSTEMPROCESS or SYSTEMACTIVITY) to a process of the target operating system. The role of the splitter is to produce a separate Estelle specification for each system module body, prepared for the generation of C code. It also generates additional C code for creating a distributed prototype implementation of the system in the original specification, based on the Remote Procedure Call (RPC) paradigm.

3. XTP Estelle specification The Xpress Transport Protocol (XTP) 4.0 was developed during 1994-1995 by the XTP Forum, an international organisation with members from industry and academia [5]. It resulted from a substantial re-design of the Xpress Transfer Protocol (XTP) 3.6, created by Protocol Engines (USA), which covered both the transport layer and the network layer. The goal of the XTP 4.0 design was to obtain a connection-oriented transport protocol with extended functionality and flexible configuration, adaptable to the fast evolution of networks and applications: high speed networks, distributed applications with transactional, multicast and multimedia communications. A remarkable feature is its reliable multicast

3

capability. The protocol's kernel is a toolkit of mechanisms with orthogonal functionality. They can be independently enabled to obtain combinations permitting various communications paradigms. The protocol specification [5] is not accompanied by a transport service specification. It only suggests how to use the toolkit to obtain a basic set of service types: unicast and multicast connection-oriented or datagram service, unicast transaction service, etc. Several versions of the XTP Estelle specification have been developed, for different versions of the protocol, from XTP 3.6 (1992), to the current XTP 4.0b (initially at Institut National des Télécommunications Evry, France, later at Politehnica University of Bucharest). Figure 2 shows the structure of the most recent Estelle specification [6]. It was developed between October 1995 and February 1996, during the design of the current version of the XTP reliable multicast mechanisms.

XTP

u_sap[1]

cu CONTEXT cl

cnx[1] PACKET_MNGM

Transport service primitives ..... u_sap[n] u_sap[2] cu CONTEXT cl

.....

cnx[2] nw

first cntl data diag .....

cu CONTEXT cl

cnx[n]

p_sap Network service primitives

Figure 2. Structure of the XTP 4.0 Estelle specification. The Estelle module XTP describes an XTP entity. It only performs management tasks. For each communication, an XTP entity keeps a state record, called a context. A communication requires an association of contexts from the participating XTP entities (for any type of service). The CONTEXT module describes the state machine that controls the activity at one association endpoint. The CONTEXT instances are dynamically created by XTP for the duration of an association. The module PACKET_MNGM is the interface with the underlying connectionless network service. It submits outgoing packets to the network layer and decodes incoming packets and routes them to the destination CONTEXT instances. The Estelle specification covers the XTP features in the current informal specification almost completely. We have also specified a generic transport service interface, consisting of a reduced set of basic, general purpose operations that can be performed by the protocol. All the service types provided by XTP use combinations of these operations, configured appropriately, through parameters that directly control XTP mechanisms. The allocation of CONTEXT instances to users, a "local matter", was not specified in Estelle. An interaction of the transport service interface just carries the index of the source or destination CONTEXT instance. The size of the specification remained moderate (8000 lines), compared with the rich XTP functionality, by exploiting XTP design principles and by using a generic service interface, tailored to the XTP functionality. A relevant example is the specification of the multicast communications. XTP has only one multicast specific packet type and the same toolkit of basic mechanisms is used for unicast and for multicast communications. For many events, the same transition is used in unicast mode and in multicast mode. Estelle's support for complex algorithms was essential for covering the XTP's functionality, e.g., for managing the state of the receiver group in a multicast transmitter.

4

4. Validation of the Estelle specification using guided simulation The principle of the validation method is depicted in figure 3. The simulation is performed with the Estelle specification of a closed system, consisting of entities of the protocol being validated and a model of their environment. The validation is conducted based on a functional decomposition, focusing successively on different aspects of the system's behaviour. Guiding constraints are applied during the simulation, to confine the computation paths within a limited state space area where the analysed functions are active (and/or certain critical situations occur). The simulation environment provides the means for applying guiding constraints and for verifying the associated correctness requirements on-the-fly. For EDT, this is done by automata implemented using the simulator's script language. Simulated Estelle specification System specification (to be validated)

event detection guiding action event detection

System's environment model

Simulation environment

Guiding constraints

Guiding

Correctness requirements

Verification

input/output, etc.

Tracing

verdict trace

Figure 3. Simulation with automated guiding and verification. For the large global state spaces of most applications, various techniques must be applied to improve the coverage and the efficiency of the exploration. A typical approach is to use memory efficient partial exploration algorithms, such as Holzmann's "bitstate" method, and to verify the properties while visiting the states ("on-the-fly") [11, 12]. Other methods reduce the explored state space: higher abstraction, data type range limitation, state space decomposition (e.g., by successive, limited depth explorations, or various kinds of constrained explorations). For many applications, the state space is so large that the most effective solution remains random simulation. In this case, the visited states are not recorded and the fired transitions are randomly selected from the current set of fireable transitions. The exploration consists of a series of random simulation runs (experiments) starting from some initial state. A state space decomposition using guiding constraints is essential for improving efficiency. Currently, this is the framework for automated validation with Edb.

4.1. Specifying relations between events Essentially, the service and the protocol are specified as a set of service primitives and protocol packets, together with a set of rules for using them. We intend to model them by a set of events and a set of constraints for their occurrence, respectively [13, 9]. The events are particular instances of actions performed by the system (e.g., message sending or consuming, timer start, stop or expiration, internal actions). The analysis of a protocol function starts with the selection of the events that need to be detected during the simulation, for making guiding and verification decisions. The event occurrence constraints are used for specifying both guiding constraints and correctness requirements. They must be able to capture essential aspects of the system's behaviour and need to be evaluated on the fly. The service and protocol specifications exhibit a variety of dependencies between events. The left column of table 1 lists samples from the specification of the graceful and abrupt close

5

services, for an XTP multicast association (for our service interface). We can identify in these examples various local and global relations: from simple precedence, to complex group synchronisation and exclusion. We outline in the following a simple and intuitive formalism able to express such relations. Table 1. Dependence relations for the termination of an XTP multicast association. Informal service specification

Event dependence relations

• Abbreviations XTP-MTRS: XTP multicast transmitter. XTP-MRCV: XTP multicast receiver. USER- MTRS: User multicast transmitter. USER- MRCV: User multicast receiver.

• Abbreviations - event location XT: XTP multicast transmitter. XR: XTP multicast receiver. UT: User multicast transmitter. UR: User multicast receiver.

• Primitives CLOSE request, indication, confirm (graceful close) RELEASE request, indication (abort, abrupt close) DATA request, indication - last data unit

• Event names (** = XT/XR/UT/UR) ClsReq**, ClsInd**, ClsCnf** RlsReq**, RlsInd** EoSnd**, EoDlv** (end of send/deliver)

Dependence relations: Service rules (samples): • RELEASE request may be sent by the User to XTP when- • RlsReqUT ← ¬ (|RlsIndUT|∨ |ClsCnfUT|) ever it wants to abort an open association. • RlsReqUR ← ¬ (|RlsIndUR|∨ |ClsIndUR|) • CLOSE request may be sent by USER-MTRS to XTP-MTRS • ClsReqUT ← |EoSndUT| ∧ after terminating the data transmission on an open asso¬ (|RlsReqUT| ∨ |RlsIndUT|) ciation (not after RELEASE request/indication). • ClsReqUR ← false USER- MRCV may not transmit CLOSE request. • ClsIndXR ← |ClsReqXT| ∧ |EoDlvXR| ∧ • CLOSE indication may be sent by XTP-MRCV to USERMRCV only if the data stream has been gracefully closed ¬ (|RlsReqXR| ∨ |RlsIndXR|) (not after RELEASE request/indication). • ClsIndXT ← false XTP-MTRS may not send CLOSE indication.

(G) (G) (G) (G)

• CLOSE confirm shall be sent by XTP-MTRS to USER-MTRS • ClsCnfXT ← ∧n∈N (|ClsIndXRn|) ∧ only if the data stream has been gracefully closed by all ¬ (|RlsReqXT| ∨ |RlsIndXT|) (N) receivers in the current group. It shall not be sent after • ClsCnfXR ← false receiving RELEASE request or sending RELEASE indication. XTP-MRCV may not send CLOSE confirm. • XTP-MTRS terminates the association either after sending • ϕ = (|ClsCnfXT| ∨ |RlsIndXT| ∨ |RlsReqXT|) ∧ f CLOSE confirm or RELEASE indication, or after receiving ∧n∈N (|ClsIndXRn| ∨ |RlsIndXRn| ∨ |RlsIndXRn|) RELEASE request. XTP-MRCV terminates the association either after sending CLOSE indication or RELEASE indication, or after receiving RELEASE request.

We consider a set of symbols E (event names) and a mapping of E to some instances of actions, executed on computation paths. An event is a distinct action instance identified by this mapping (so in the following we refer to a set of events E). We observe the system during the simulation and detect the events produced at each step. A computation step can produce zero, one or several events. For instance, firing an Estelle transition can produce no significant event, or an input event only, or an input and outputs. One approach is to assume that a fired transition produces an atomic group of events, i.e., one cannot distinguish the moments when the events within a group occur. During a simulation run, we observe a sequence of event groups. An alternative is to assume that a transition produces an ordered group of events. In this case, during a simulation run we observe a sequence of events. When applicable, the second model simplifies the analysis of the event dependencies and, especially, the implementation of the guiding and verification automata.

6

The choice depends on the capabilities of the simulator and the relations to be specified. We used both models with the EDT simulator. We summarise in the following the approach based on ordered groups (the use of atomic groups is presented in [13, 9]). Our objective is to determine, for any event, if a specific dependence condition on other events is satisfied, from the event pattern observed so far. We want to impose some dependencies as guiding constraints, and check the others as correctness requirements. The first step is to evaluate if some event e∈E occurred in a prefix of the computation path. Let um = e1 e2 ... em, um∈E*, be the sequence of detected events. The event occurrence operator, denoted |e|um, simply assesses if some event e is present in the sequence um or not: |e|um = True, if e ∈ {e1, e2, ... em} False, otherwise. The next step is to evaluate if some sets of events occurred. For this purpose, we can use boolean expressions, called event occurrence expressions, defined as follows: if e∈E and um∈E*, then |e|um is an occurrence expression; if ϕ1 and ϕ2 are occurrence expressions, then (¬ϕ1), (ϕ1∧ϕ2), (ϕ1∨ϕ2) are occurrence expressions. We indicate the evaluation prefix um for an expression ϕ by writing ϕ|um, unless um is implicit. For example, if D ⊆ E, D = {a, b, c, d}, the expression ϕ(D) = (|a| ∨ |b|) ∧ |c| ∧ ¬|d| has the value True if any of the 3 patterns {{a, c}, {b, c}, {a, b, c}} occurred in the path prefix. It has the value False for any of the other 13 patterns in 2D. We can use an expression ϕe(De), De ⊆ E-{e}, to indicate after which event patterns some event e∈E may occur (those for which ϕe(De)=True). The expression ϕe specifies the dependence of the event e on the other events, so it is called the dependence formula for e. We define ϕe ≡ True for the events without constraints and ϕe ≡ False for forbidden events. The dependence relation, between an event e and the events De, denoted e←ϕe(De), is defined as follows: for any computation path prefix having um as its sequence of detected events, the event e may occur if and only if ϕe(De)|um= True. The right column in table 1 lists the dependence relations corresponding to the samples of service specification in the left column. The relations for events produced by the XTP entities serve for checking the correctness of the protocol design. Those for the events produced by the environment are used as guiding constraints, as described in the next section.

4.2. Guiding the simulation The simulation is guided by dynamically applying constraints that restrict non-deterministic choices in the protocol entities and their environment. Typical examples are constraints for services requested by users, decisions to accept or reject them, delivery or loss of packets. The aim of guiding is twofold: to improve the efficacy of the simulation (for large state spaces) and to support an incremental development of complex specifications. For the first objective, guiding improves the functional coverage, despite an inherently partial state space coverage. For the second, it provides the basis of non-regression tests. The constraints may be more or less restrictive. Restrictive constraints are needed for simulating a particular evolution, either for its special relevance, or as a preamble. Loose constraints are useful for covering a class of situations, only limited by the ability to specify and verify the correct behaviour. The first step is to select the relevant events (e.g., some message inputs or outputs, at some instances). The others are ignored (not observed). Among the relevant events, some are constrained events, triggered by guiding, others are verified events, whose occurrence must satisfy the correctness requirements.

7

We define a basic guiding specification as a pair G = (EG, SG), where: • EG is a finite set of events. The guiding actions trigger the occurrence of some events Ec ⊂ EG. The events Enc = EG -Ec are non-constrained actions of the simulated system. • SG is a specification of dependence relations: SG = { e ← ϕe(De) | ∀e∈ Ec ; De ⊆ EG }. The set of stimuli sent by the environment and the outcomes of non-deterministic decisions made by the protocol entities are restricted to the set of events Ec. The dependence relations SG are constraints for the sequences of events. An event e∈Ec may occur (once) when its dependence formula is satisfied. The events Enc just participate in the guiding decisions. From a guiding specification G= (EG, SG) we can derive an acyclic automaton AG, which runs synchronised with the simulated system, monitors its evolution and performs the guiding actions [9]. At each computation step, the automaton records the produced events e∈EG and enables some events e∈Ec for which the dependence formulas hold.

4.3. Verifying correctness requirements Event dependence relations can express properties for finite, acyclic event sequences. We define a basic correctness requirements specification as a triple V= (EV, SD, SF), where: • EV is a finite set of events. • SD is a specification of dependence relations: SD = {e ← ϕe(De) | ∀e∈EV ; De ⊆ EV }. • SF is an event occurrence expression ϕf(Df), Df ⊂EV, assessing the expected termination. Intuitively, for a set EV of significant events, SF indicates the correct outcome of the verified activity and SD specifies the allowed sequences of events leading to it. We say that a sequence of events um = e1 e2 ... em, um∈EV*, satisfies SD and belongs to the language ΛSD ⊂ EV* if and only if: ∀i∈ {1 ..m}, ϕei(Dei) |ui-1 = True (with u0 the empty string) The specification SF indicates, by ϕf(Df) =True, the sets of events in 2Df whose occurrence is required for correct termination. When a computation path satisfies both SD and SF, we conclude that the verified activity has been successfully completed. Any maximal sequence in ΛSD must satisfy SF. However, correct termination may be reached for shorter sequences (e.g., it might depend on any of several events which are not mutually exclusive). Together, SD and SF define a language Λ⊂ ΛSD. From a specification V = (EV, SD, SF), we can derive an acyclic automaton AV that recognises the language Λ [9]. Running synchronised with the simulated system, AV verifies on-the-fly that the specification V is satisfied, based on model checking principles [11, 12]. When guiding is used, the specifications (G, V) need to be jointly specified. Some of the events in EV correspond to events in EG and conversely. For example, the transmission of a service request may be an event of Ec⊂EG, satisfying SG, and its reception an event of EV. The transmission of an indication may be an event of EV, satisfying SD, and its reception an event of Enc ⊂ EG. The SG formulas are written (and minimised) assuming that the verified system satisfies SD. Conversely, the formulas SD and SF are written (and minimised) assuming that the environment behaves according to SG. However, the events e∈EV corresponding to guiding actions need not actually be verified. The basic specifications (G, V) are used for verifying elementary, acyclic components of the system's behaviour. They form convenient building blocks for composite specifications covering larger parts of the behaviour, using sequencing, alternative and loop composition operations [13, 9].

8

4.4. Using the Edb simulator for validation With Edb, validation can be done by exploring the state space using a series of random simulation experiments with on-the-fly guiding and verification. The automata AG and AV, corresponding to a specification (G, V) are implemented as observers using the Edb script language. Their state is given by variables, which record for each event if it occurred or not. An Edb observer is automatically executed after each transition fired by the simulated system. The guiding observer updates the state by recording the produced events and enables, with a guiding action, the remaining constrained events for which the dependence formula is satisfied. The guiding actions affect transition selection (permit/forbid some transitions) and, for outputs of the environment, indicate the message type and the parameter values. The verification observer records each event produced and evaluates the associated dependence formula. If the formula is not satisfied, it stops the simulation experiment and reports the error. If SF is satisfied, it reports the correct termination of the experiment. A series of random simulation experiments is performed for each specification (G, V). All the scenarios are finite (i.e., no infinite loops). The number of computation steps of an experiment is limited to a maximum value estimated from measurements. Each experiment ends with a relevant result. A partial success verdict is given if an experiment satisfies SD and reaches the goal specified by SF. The series of experiments can be continued. An absolute failure verdict is given if an experiment violates SD or if it terminates without reaching SF, either by deadlock or by consuming the number of computation steps (probable livelock). The series is interrupted and the faulty experiment is replayed to find the cause of the failure. Intuitively, the success results of the series of experiments are cumulative. For a comprehensive set of scenarios, the cumulative success results offer a solid basis for accepting the design. It seems difficult to objectively evaluate the quality of the validation thus obtained. The coverage of the specification's code offers useful but minimal information (not really relevant for the state space coverage). Edb records the coverage of the transition set. Although partial, this validation can substantially improve the design, by removing errors from the most probable system runs. Actually, this is the practical target for complex applications, in particular for complete specifications that can be used for automatic implementation. A first version of the method presented in this section was experimented with during the development of the XTP 4.0 Estelle specifications. In the early phases of the XTP 4.0 design, from XTP 3.6, it permitted identification of an omission in the definition of the graceful close mechanism, causing unrecoverable data loss. It was also used during the redesign of the XTP reliable multicast procedures to simulate complex multicast communications scenarios. Based on these experiments, the Edb support for event detection was enhanced. The new Edb version (4.2) was used during a project for extending the OSI-TP protocol [30] with nested transaction models [9, 13]. The extended OSI-TP Estelle specification has 29000 lines. The simulation scenarios with multiple nested subtransactions needed system configurations with 40-50 module instances. The improvement of the productivity, after introducing the guiding and verification observers, was spectacular: fully automated simulations, fast nonregression tests by running collections of simulation scenarios in batch mode, etc. Currently, Edb observers implementing (G, V) specifications are hand-coded using the Edb script language. Implementation is based on a template that specifies naming conventions and how the observer is structured in general (reusable) macros and scenario-specific macros [9]. This template allows relatively fast implementation of large collections of high complexity (G, V) specifications. Enhanced tool support is possible and is currently being studied. The MSC [29] tracing function of the simulator, recently added to Edb, permits automatically obtaining example traces to illustrate (G, V) specifications.

9

5. Performance evaluation based on the Estelle specification Besides the functional properties discussed so far, communications protocols must satisfy certain quantitative and real-time properties. They have always been a major concern, but have become crucial in the design of protocols for distributed multimedia applications, exhibiting sophisticated and tight real-time quality of service requirements [14]. The ability of the protocols to satisfy such requirements has to be studied from the early design stages. The functional properties and the real-time properties must be treated in parallel. Various performance evaluation methods are mentioned in the literature [15]. Analytic queuing network techniques use product-form queuing networks, solved by exact or approximate methods, available for certain models. Markov chain techniques use stochastic models, mapped to linear equations, which are solved by numerical methods. Both approaches have limited applicability. Discrete event simulation seems the only practical choice for complex systems. Finally, hybrid techniques try to combine the benefits of different techniques. In an FDT-based development methodology, the performance evaluation model must be derived from the formal description of the protocol. The use of other languages and tools raises major difficulties, especially for complex protocols: translating the formal description to the performance evaluation model, ensuring the behaviour equivalence of the two models, maintaining two separate models during the system development. We can avoid these problems by extending the use of the formal description to performance analysis. Several approaches have been proposed, with different solutions for specifying quantitative aspects (e.g., language extensions or annotations) and different performance evaluation models (e.g., timed automata, Markov chains) [14, 18, 19]. EDT supports performance evaluation based on Estelle specifications, using a dynamic annotation and a timed automata model, compatible with the Estelle semantics [16, 17]. Edb scripts configure the system (time intervals for transition execution and system management, relative transition execution probabilities) and collect statistics during simulation experiments.

5.1. A taxonomy for performance evaluation simulations Performance evaluation can serve for various purposes during the development of communications protocols. Many characteristics can be measured, depending on the types and quality of service provided by the protocol. To illustrate Estelle based performance evaluation, we list several classes of objectives, identified during our case studies, and outline the specific aspects of the methodology for each one. A. Assessing protocol mechanisms in a generic context The goal is to evaluate the relative performance for alternative designs of a protocol function. General properties can be evaluated with just a generic model of the environment (e.g., maximum throughput of a saturated transmitter, for various bandwidth-delay products). The Estelle specification of the environment only models essential aspects, relevant for the studied mechanisms (e.g., packet loss and bandwidth-delay product, for assessing error and flow control mechanisms). A guiding automaton drives the simulation according to a scenario that activates the designed function. We can further distinguish two sub-cases. A1. Comparative analysis of different mechanisms or policies This analysis is useful for selecting a solution that matches a class of applications and network technologies, targeted by the protocol. Simulations are made with each mechanism or policy for a limited set of relevant environment characteristics. For example, error control can use go-back-N or selective retransmission, with or without negative acknowledgements. Also, throughput is greatly influenced by the policies for acknowledgement and dynamic timer

10

adjustment, used by the flow and error control functions. Such an analysis is particularly important for configurable protocols, such as XTP. A2. Comparative analysis of different configuration settings for particular mechanisms This analysis aims at determining appropriate protocol configurations. A series of simulations are run for different settings of certain protocol and environment parameters, e.g., window and buffer sizes, reliability of the lower layer service, transfer delay and timer values. B. Assessing the protocol for specific applications The goal in this case is to evaluate the performance in a specific target environment. This includes support for critical applications with strict quality of service requirements (e.g., realtime video or audio) and efficiency for particular network technologies (e.g., ATM, FDDI). The Estelle specification of the environment must be customised to incorporate specific aspects of the application (e.g., traffic model) and the data delivery service (e.g., access delay, traffic contract, priorities). This analysis can be used for an overall assessment of the protocol’s design or to refine the previous ones. The results are less general, specific to the selected environment, but they can identify particular problems with critical applications. C. Early performance predictions In the previous cases, the emphasis was on the relative performance for selecting alternative design solutions or adequate protocol configuration parameters. This analysis aims at providing early predictions of absolute performance values, which are also necessary for assessing the design (e.g., to find out if an implementation for a typical platform can provide the minimum throughput required by the target applications). We need a more accurate timing model, based on measurements made on specific implementation platforms (e.g., to take into account inter-process communication and scheduling overhead, etc.). Good predictions can be obtained for implementations that strictly reproduce the structure of the Estelle specification, in particular for those automatically derived.

5.2. Using the Edb simulator for performance evaluation After ensuring the functional correctness of the protocol’s specification, we can proceed with simulations for performance evaluation, using the same architecture (figure 3). The simple Estelle model of the system's environment used for validation has to be extended with the timing aspects required by performance evaluation. The model of the lower layer service must simulate a pipeline behaviour and transfer the packets with configurable rate and delay, taking into account their size. In the case of unreliable service, the model must lose, reorder and duplicate packets with configurable probabilities. The service user must generate data units according to certain traffic models. For convenience, support for collecting the measured parameters (variables and functions) can also be added in the environment. An important goal of the Edb approach is to avoid modification of the protocol’s specification for the purpose of performance evaluation. This is possible because the assignment of execution times and the measurements are made by the simulation environment (Edb scripts). Also, validation by random simulation does not require major simplifications of the protocol specification to limit the state space size. Therefore, the resulting specification can contain all the information needed by the Edb observers to collect the statistical data. In particular cases, when some measurements cannot be taken by observing the existing state variables, passive support for collecting them might have to be added in the specification. The values of all the time related parameters (including delay values of the delayed transitions) are normalised to a conventional time unit, ETU (Estelle Time Unit), to ensure the consistency of the results. One ETU represents a certain amount of physical time, declared in

11

the specification as the constant SLOT (e.g., SLOT =10 means an ETU of 10 μs). Measurements are made during guided free run simulations. Hence, performance evaluation needs an Edb simulation environment consisting of guiding, measurement and tracing components. Typically, some of the scenarios used for validation can also serve for performance evaluation. We need only adapt some existing Edb scripts by adding measurement capability to guiding and tracing as one or several observers. A task of the measurement observer is to dynamically configure the system for performance evaluation. Edb functions can assign a time interval and a certain distribution (uniform, exponential, geometric, Poisson) for transition execution and system management. Also, they can assign transition selection probabilities. This configuration has to be done as soon as a (relevant) module instance is created, at system initialisation or dynamically. The assignment of execution times is only needed for the relatively small subset of transitions that determine the performance of the analysed functionality (e.g., for a connection oriented protocol, only a small subset of transitions effectively influence the data transfer performance metrics). Execution times can be estimated in several ways. For a comparative analysis, a rough estimation is usually sufficient. For example, the mean number of C code lines executed when firing the transition can be divided by the equivalent mean speed of a typical target processor. Alternatively, rough estimates can be obtained by measuring similar actions on existing implementations, assuming the designed protocol will be implemented using a similar technique on a similar platform. More accurate estimates are needed for predicting absolute values. The implementation technique and the target platform have a decisive influence. In particular, accurate estimates can easily be obtained for automatic implementations obtained with EDT by measurements taken on the generated code. Moreover, in this case both the transition execution and the system management times can be accurately determined. The other task of the measurement observer is to collect statistical data during the simulation by observing the system’s components. It uses the comprehensive collection of Edb functions for accessing the system’s components and other Edb functions that provide general statistics useful for performance evaluation (e.g., for fired transitions and queue contents). When some measurement or configuration actions are needed, the simulation steps can be specified using an event-based approach, as for guiding, and implemented as in the guiding observers. Alternatively, several Edb predefined observers (fscurve, tmcurve, resptime, throughput) can help in collecting and processing some typical performance related data.

5.3. Examples of performance evaluation experiments We illustrate the application of Estelle based performance evaluation methodology with several examples from a series of case studies [7, 10, 20, 21]. a. Comparative analysis of XTP window flow control policies (analysis of type A1) XTP has two flow control mechanisms. A sliding-window mechanism limits the amount of data the transmitter may send, based on feedback from the receiver (advertised credit). Its efficiency is determined by the acknowledgement policy and the bandwidth-delay product of the underlying medium. The rate mechanism controls the rate and the burstiness of the transmitted data stream, based on negotiated rate and burst values. The two mechanisms can be independently activated. When used together, the amount of data in the advertised window is transmitted as a data stream regulated according to the negotiated rate and burst. We wanted to study the efficiency of different acknowledgement policies for the slidingwindow mechanism. In XTP, the transmitter obtains a reply from the receiver (control packet) only after making an explicit request, using several flags in the header of a transmitted packet.

12

The reply, called a status report, includes the window (credit) advertised by the receiver. The transmitter is free to choose an acknowledgement policy that maximises the performance. Five policies have been proposed for sending status requests: P1 - when the upper bound of the window is reached; P2 - in every data packet sent; P3 - after every received status report, i.e., at each round-trip-time (RTT); P4 - when no status reports are awaited and the available credit will be consumed in less than RTT; P5 - when no status reports are awaited and the available credit is a certain fraction of the maximum window size. We used Edb to compare these policies for unicast transfer, based on two performance metrics: the throughput (packets/s) and the response time (waiting time of a packet in the transmission buffer), as a function of the window size (packets). The specification of the environment consisted of a generic user with a constant rate of fixed size service data units and a high speed transmission medium, either generic or FDDI. Rough execution time estimates were assigned to the transitions processing the data and control packets. The results [7] indicate that policy P4 offers the best performance for a large range of parameter values and different underlying media. Similar results were obtained by simulation with a queuing network model of the protocol. b. Comparative analysis of XTP processing overhead (analysis of type A2) The goal was to evaluate the processing per data unit as a function of different protocol configuration parameters. The experiments were typical unicast bidirectional stream transfers, with window flow control, rate control and selective retransmission mechanisms activated. The simulated system included generic Estelle models for the XTP service users and for an unreliable medium. We made four types of experiments, denoted E1-E4. Table 2 lists the values of the parameters for E1. The other experiments differed from E1 as follows: in E2, the maximum size of the service data unit (SDU) was increased to 4096 Bytes; in E3, the initial value of Wtimer was increased to 1000 ETU; in E4, the rate was increased to 300 Kbyte/s. Table 2. Main protocol configuration parameters for the experiment E1. XTP PARAMETERS Transmission/reception buffer size = maximum window size Maximum data segment size in DATA packets Initial Wtimer value SERVICE USER PARAMETERS Maximum size of the service data unit Number of transmitted data units Random data unit size NEGOTIATED PARAMETERS (USERS, XTP) Burst size Rate MEDIUM Bandwidth Packet loss probability

8192 Bytes 4096 Bytes 200 ETU 1024 Bytes 50 uniform distribution 1024 Bytes 100 KByte/s 10 Mbit/s 0.05

Figure 4 shows the simulation results. Three metrics were used for evaluating the processing overhead: the mean number of transitions per transferred SDU (ntrans/SDU), the mean number of transitions per kilobyte of transferred data (ntrans/KB) and the mean number of control packets per data packet (nctrl/ndata). The results indicate that the configuration for the experiment E4 is the best (details are provided in [7]). A series of such experiments, automatically repeated for extended ranges of the parameters’ values, can help in determining the optimal regions for the protocol configuration parameters.

13

100 80

10x(nctrl/ndata)

60

ntrans/KB

40

ntrans/SDU

20 0 1

2

3

4

Experiment number

Figure 4. Processing overhead for XTP unicast communications. c. XTP capability to transfer multimedia traffic in a LAN environment (analysis of type B) A major goal of the XTP 4.0 design was to support distributed multimedia applications. To assess this critical capability, one must evaluate the quality of service parameters of realtime multimedia traffic (throughput, transfer delay, jitter) for specific traffic models and a high speed network environment. The XTP support was confirmed by simulations with the Estelle specification for unicast and multicast transfer of real-time audio and video streams in small FDDI networks [21, 7]. The XTP service user was adapted to model combined audio and MPEG video traffic sources. An Estelle model of an FDDI network was used for the underlying medium.

Throughput [KBytes/s]

d. XTP throughput (analysis of type C) The objective was to obtain predictions for the throughput of an XTP implementation for unicast bidirectional stream transfer. We maintained the protocol configuration used for the analysis of processing overhead and the generic models of the environment. The basic parameters are listed in table 2, but we made a series of experiments with different values for maximum rate, SDU size and initial Wtimer value. The time values assigned for transition execution and system management are based on measurements taken on an XTP prototype, automatically derived from the Estelle specification using EDT (for a Sparc 5 processor). Figure 5 shows throughput values (user to user) obtained by simulation. For a rate of 100 KBytes/s, the throughput is limited by the XTP flow control mechanisms. For higher rate values, the maximum throughput of the protocol is reached (for the simulated configuration and timing model). However, the actual user transmission rate is less than the negotiated value. The results show a relatively low degradation of the throughput with increased loss probability (20% versus 10 times). The higher throughput obtained for the larger SDU size is due to the reduced number of interactions at the user-XTP interface. 250

SDU size=1024, Wtimer=300, p=0,01

200 150

SDU size=1024, Wtimer=300, p=0,1

100

SDU size=4096, Wtimer=500, p=0,01

50

SDU size=4096, Wtimer=500, p=0,1

0 100

300

500

Rate [KBytes/s]

p = packet loss probability in the underlying medium

Figure 5. Mean XTP throughput (user to user) versus negotiated maximum rate.

14

The values predicted by simulation are close to those measured on a preliminary XTP prototype (non-optimised) in a real network environment. This confirms that accurate predictions can be obtained if the implementation follows the architecture of the Estelle specification and good execution time estimates are provided for the essential transitions.

6. Automatic implementation from the Estelle specification The protocol implementation has to meet several requirements. The obvious (but hard) requirement is the compliance with the protocol's specification. Next, it must match the specific performance requirements of the target applications (i.e., communications systems in which it is integrated). Finally, it is constrained by the resources provided by the target implementation platform: processing power, storage capacity, support for real time and for multiple threads or processes, single or multi-processor platform, etc. The classical approach consists in hand-coding the implementation using a programming language. It copes very well with performance requirements and resource constraints, but involves a large amount of work and handles the essential compliance requirement poorly. Alternatively, a complete and validated formal description can be used to automatically produce the implementation. This approach can ensure that the implementation complies with the specification and can greatly reduce the development and maintenance effort. It is (quite inherently) more difficult to meet the efficiency requirements and to customise the implementation for integration in a particular context [22]. Insufficient support for these aspects limits its industrial use (and a wider acceptance of the FDT based design). The aim of our XTP implementation case study was to investigate these difficulties by obtaining a realistic implementation from an Estelle specification using EDT [8, 24].

6.1. Using EDT for implementation An Estelle specification is a hierarchically structured collection of module instances. The system modules occupy the top of the hierarchy. They run independently and synchronise with each other by message exchange. Within a system module, further synchronisation rules are imposed: priority of a parent module over the children modules and, depending on the module attributes, either parallel synchronous or asynchronous interleaving execution. A system module cyclically performs a management phase to identify the fireable transitions, followed by an execution phase. The transition selection algorithm is complex and can cause excessive overhead. Various solutions to reduce this overhead have been investigated [22]: optimisation of the algorithm, structural transformation of the specifications, identification of favourable specification styles, different scheduling policies, etc. According to [23], two main classes of models are used in hand-coded implementations: the server model and the activity thread model. In the server model, each entity processes events in an endless loop. They communicate asynchronously and a scheduler offers to each one a fair chance to run. In the activity thread model, when the system gets some work to do, control passes from one entity to another following the flow of messages. Ideally, an entity ends its work by issuing a message, implemented as a procedure call to the destination entity (synchronous communication). This minimises scheduling and communication overhead [25]. Most of the current automatic implementation tools, including EDT, use the server model, which matches Estelle (and SDL) semantics better. The activity thread model could provide a considerable performance improvement. However, due to major contradictions with the Estelle model, excessive restrictions for the Estelle specifications are needed to permit its use. EDT maps an Estelle system module instance (SYSTEMPROCESS or SYSTEMACTIVITY) to a

15

process of the target operating system and implements children modules as procedures. It generates a separate program for each body of an Estelle system module in the specification, as described in the following [26]. First, the Universal Generator (Ug) splits the original specification, spec.stl, in several specifications, mb_k.stl, one for each system module body. Each specification mb_k.stl contains a system module from spec.stl, embedded in a new Estelle system module, generated by Ug. The task of the embedding module is to transfer messages between the original system module and the environment. Next, for each specification mb_k.stl, the Estelle-to-C compiler (Ec) generates a C program and a make file. The C code is independent of the target platform. To ensure that the implementation reproduces the behaviour verified by simulation, the same C code is used for both purposes. We can proceed to immediately experiment with a prototype or to further refine the implementation. For the first case, EDT can automatically distribute the system's components to user selected hosts. The set of Estelle system module instances and communication links from spec.stl is mapped on a set of processes communicating via TCP/IP. For the second case, we can customise primitives in the tool's libraries, to obtain a more efficient implementation, for a precise target and context. The latter approach was first applied to the XTP implementation. The embedding module added by Ug contains internal interaction points connected to all the external interaction points of the original module, and transitions that handle the messages. The transitions use four generic primitives, mxinit, mxwhen, mxoutput and mxsend, for the mapping between Estelle messages and the inter-process communication mechanisms (IPC) provided by the target operating system (e.g., sockets, message queues, signals, etc.): INITIALIZE BEGIN mxinit; END;

{ IPC mechanism(s) initialization }

TRANS { Outgoing interactions; for each interaction point and type} WHEN s_p_sap.Data_req BEGIN mxsend(1, 0); { send Data_req using an IPC mechanism } END; { s_p_sap identifier=1, Data_req identifier= 0 } TRANS { Incoming interactions; 2 interaction points in this example} ANY x : 0 ..1 { for x = any of the interaction points } PROVIDED mxwhen(x) { a message is received for interaction point x } BEGIN mxoutput(x); { output the corresponding Estelle interaction } END; { to the interaction point x }

This approach avoids the necessity of modifying the original Estelle specification, confines the interface problems to a set of four C functions and offers a lot of flexibility for implementing the interface. The user can choose interface functions from the tool's library or develop customised versions (using IPC mechanisms known to the EDT runtime library). The dispatcher function in the runtime library is the core of the process that implements an Estelle system module. It contains an infinite loop in which the process waits for an event, selects the fireable transitions (system management phase) and fires them (execution phase). The process blocks, waiting for the arrival of incoming messages from the environment or the expiration of running timers (corresponding to enabled delayed transitions). The detection of an event wakes up the process, which starts to execute the loop. A timer management function updates the list of running timers and marks the delayed transitions becoming

16

fireable. Then, a set of transitions is selected and fired. It may contain several transitions, for the SYSTEMPROCESS attribute, or a single transition, for the SYSTEMACTIVITY attribute. The process continues to run as long as fireable transitions exist, i.e., until it achieves the treatment of the event which woke it up and those which occurred in the mean time. Eventually, the process blocks, waiting for another input or time-out event. During a run, the process fetches (at most) one incoming message from each input port and achieves their treatment before letting other messages in. Hence, the interface with the environment provides an implicit flow control on incoming messages. This is a useful property for an implementation, not guaranteed by the Estelle model, which assumes an asynchronous communication with unlimited queues. As a side effect, the parallelism between the Estelle sub-modules is reduced. The current EDT runtime library uses a (relatively) optimised transition selection algorithm. The algorithm is fully compliant with the Estelle operational semantics and does not impose any restrictions concerning the Estelle language features.

6.2. XTP 4.0. implementation We adopted an implementation context similar to that of SandiaXTP [28], the reference XTP 4.0 implementation, hand-coded in C++: UNIX operating system (user space); UDP/IP sockets at the data delivery service interface; UNIX domain sockets, shared memory and XTP-specific application programming library, at the transport service interface [8]. Figure 6 illustrates our goal: a realistic implementation, functionally similar to SandiaXTP and able to inter-operate with it. In the following, we call this implementation E-XTP. User

User

User

User

User

UNIX process

UNIX process

UNIX process

UNIX process

UNIX process

IPC

IPC

IPC

IPC

IPC

IPC XTPI u_sap[1]... u_sap[k] XTP p_sap

UNIX Process

E-XTP

SandiaXTP UNIX Process IPC

UDP/IP

IPC

UDP/IP

IPC XTPI

IPC

IP network unicast/multicast

u_sap[1]... u_sap[k] XTP p_sap

UNIX Process

E-XTP IPC

UDP/IP

Figure 6. Hosts running E-XTP and SandiaXTP. In the E-XTP structure (figure 6), the block XTP corresponds to the original Estelle specification (figure 2). The block XTPI is the embedding Estelle module, produced by Ug. Additionally, E-XTP contains the interfaces between XTP and the environment, denoted IPC. The core of the implementation consists of the C code generated by the Estelle compiler from XTPI (20000 lines) and the EDT runtime library that implements the Estelle model (inter-module communication, transition selection, etc.). The IPC interfaces are implemented using customised versions of the generic EDT interface primitives (mxinit, mxwhen, mxoutput, mxsend). For the UDP/IP interface, the XTP specific functionality added to these primitives includes the encoding/decoding of XTP packets and the checksum computation. For the XTP-user interface, the primitives handle the allocation of contexts to user processes.

17

9000 8000 7000 6000 5000 4000 3000 2000 1000 0

8150 7640

Unicast

throughput [Kbit/sec]

throughput [Kbit/sec]

Moreover, the interface primitives cooperate with send/receive buffer management primitives, for optimising the data path between the user buffer and the UDP/IP interface. The size of the executable code is 210 kilobytes, similar to that of SandiaXTP 1.5. Figure 7 shows the results of throughput measurements for SandiaXTP and E-XTP [24], for a one-way data transfer, between Sparc stations Ultra 1, on 10 Mbit/s Ethernet. For the typical protocol settings used (flow control, error control and checksum enabled, rate control disabled, acknowledgement at end of window), the two implementations offer quite similar, although relatively moderate throughput values. However, running in user space is a major handicap for both of them: measurements made on E-XTP pointed out that the system calls are responsible for 50-60% of the processing time per packet.

SandiaXTP E-XTP 4150 3920 2100 2040

256

512

1024

9000 8000 7000 6000 5000 4000 3000 2000 1000 0

Multicast, 3 receivers SandiaXTP E-XTP

6400

3100 3310 1430 1740

256

data unit size [bytes]

6100

512

1024

data unit size [bytes]

Figure 7. Throughput of E-XTP and SandiaXTP (user buffer to user buffer), as a function of the data unit size. The window size is 24 data units.

6.3. Improving the runtime efficiency The analysis of the implementation pointed out two main sources of overhead: the implementation of the communication mechanisms (mainly the data path) and the Estelle system management (transition selection and scheduling) [24]. For the EDT implementation model (a typical solution), two kinds of communication can be identified: external and internal. The external communications, between the process and its environment, rely on the IPC mechanisms provided by the target operating system (message queues, shared memory, sockets, etc.). The sources of overhead are the IPC latency and data copying. A particular problem is the mapping between the Estelle interactions and whatever corresponds to them in the environment: basic IPC mechanisms or the access to some service via a programming interface. In general, the mapping might need to be partially hand-coded. With EDT, this corresponds to customising the generic interface primitives. The internal communications, between modules within a process, are implemented by the tool's runtime library. The sources of overhead are message copying, message routing and queue management. A general, always safe, solution implies copying once the parameters. However, even this copying is often redundant, most notably for user data manipulation. One approach is to use a code generator able to detect when it is useful and safe to work with references instead of values. It could apply off-setting or scatter-gather to deal with the variable size of the data units. Promising results have been reported [25], but the approach has limitations and cannot completely avoid human involvement (e.g., guiding by annotation). Alternatively, we can focus on optimising the manipulation of user data (which is the main problem), with Estelle primitive procedures provided in a buffer management library. In

18

such a case, the Estelle code works only with buffer descriptors and uses primitives for operations with the data buffers of the transmitter or the receiver. The point is that the user data are not interpreted by the protocol state machine and buffer management is an implementation matter. We can (and we should) hide the details and leave the tool's runtime library take care of them. Based on this idea, in E-XTP, the primitives for data buffer manipulation and external communications cooperate to optimise the complete data path between the user buffer and the data delivery service (using shared memory and scatter-gather) and to integrate packet manipulation issues (encoding, decoding, checksum computation). Measurements on E-XTP [24], illustrated in figure 8, point out that the system management overhead of the EDT runtime library remains substantial, despite current optimisations. transmission [microsec/packet] 107 45%

reception [microsec/packet]

130

109 48%

118 52%

55% management execution

management execution

Figure 8. Contribution of the system management duration to the processing time per data unit, in the XTP module. The current transition selection algorithm consists of a single-pass search of the hierarchically structured list of module instances, checking for fireable transitions. At each instance, it looks for fireable transitions using table-based decoding (input/state table) followed by programmed selection (checking of provided clauses, interaction point identity, priorities). The search is often partial, but always starts from the root. The complete list of instances can become very large, and this solution does not scale well (e.g., for 100 simultaneous XTP associations the list contains 100 CONTEXT instances). Some Estelle features, e.g., spontaneous and delayed transitions, have been identified as major causes of overhead [8, 24]. We are currently studying new approaches to scheduling and transition selection that can substantially reduce the system management overhead. For instance, suppose that, after each step, the scheduler can anticipate the next work to be done and marks as active the instances that need to be put to work. For the next step, it has to check only the active instances. If it is always one, we are close to the efficiency of an activity thread. If they are too many (rather unlikely), we are back to the current overhead. The main obstacle to anticipating next work is the use of primitives in the PROVIDED clauses (especially for spontaneous transitions). Also, the efficiency may be reduced by the presence of exported variables in PROVIDED clauses. Major improvements can be obtained for large classes of specification profiles that avoid using features which substantially increase the management overhead. The tool can provide optimised algorithms for such profiles, so that the user can adopt a specification style which best matches the application. The development of XEC (eXperimental Estelle Compiler) [27] promises the possibility of experimenting with a large variety of other optimisations.

7. Conclusions Ideally, a protocol engineering environment should be able to consistently support all the activities of the development process with an integrated toolset and methodology. The gaps and inconsistencies can substantially reduce the productivity (e.g., non-automated translation between models used for requirement analysis, design and evaluation, large gap between the

19

abstraction level needed for validation and that required for automatic implementation). The difficulty of ensuring consistent support increases with the complexity of the application. We presented in this paper elements of an integrated methodology based on Estelle FDT covering the formal description, validation, performance analysis and implementation. The methods are supported by the Estelle Development Toolset (EDT). They can be applied to a wide range of applications, but are particularly interesting for complex specifications. During an incremental development of a complex system, functions are gradually integrated into the formal description. Non-regression tests have to be created for each added function and run at each modification of the design. Guiding constraints select particular aspects of the system's behaviour during simulation. They can limit the simulation to the functions specified so far and, more generally, support a validation strategy based on decomposing the system's behaviour. The aim is to improve the functional coverage when a huge state space is (inherently) partially covered. This is the practical target for complex applications, in particular for complete formal descriptions that can be used for automatic implementation. A unified framework is provided for jointly specifying the guiding constraints and the verified properties, using dependence relations between events. Intuitively, the set of messages and the rules for using them, given in a service or protocol specification, are translated to a set of events and constraints for their occurrence. Some constraints refer to non-deterministic choices in the simulated system and are used for guiding decisions (e.g., stimuli assumed to be sent by a service user). The others represent the correctness requirements (e.g., the expected reactions of the system to the received stimuli). Automata derived from these specifications are implemented as observers in the simulator's script language. Event based validation methods are also provided by the SDL tools SDT (Telelogic) and ObjectGeode (Verilog). They use Message Sequence Charts (MSC) [29] for describing the expected behaviour of the system. Random simulation and bit-state (partial) or exhaustive simulation can be used. The means for constraining the simulation include restrictions for the set of stimuli sent by the environment and MSC based guiding. An essential difference is that the specifications (EV, SD, SF) can emphasise specific, essential relations between the events, while the MSCs are limited to the order of events. Also, the specifications (G, V) explicitly indicate what is assumed (by guiding) and what is verified. They provide a more flexible and convenient framework for decomposing the system's behaviour. By combining restrictive with loose guiding constraints and by verifying only essential properties, matched with the guiding, it is possible to reduce the explicit enumeration of possible situations. The resulting Estelle specification can be used for automatic implementation. The main challenges are to ensure good runtime efficiency and to support integration in various target platforms. The approach we experimented with confines the interfacing and data path optimisation problems to a small set of Estelle primitive procedures (written in the C language). Generic versions of these primitives can be provided by the tool's library, ensuring that the Estelle semantics is observed. The user can customise the primitives to adapt them to the application and target platform. The resulting XTP implementation approached the efficiency of SandiaXTP, hand-coded in C++. Work is currently being carried on for providing a more general and flexible library of primitives. Also, we are studying scheduling algorithms that reduce the system management overhead for certain Estelle specification profiles. The current EDT performance evaluation features have a native definition, e.g., Estelle transition execution and system management times. The resulting performance model is strongly dependent on the structure of the Estelle specification. Hence, we can expect good accuracy only if the implementation strictly follows the specification. However, this is what we need in the framework of an FDT based protocol development.

20

The main advantage is the use of the same basic model, the Estelle specification, for all aspects of protocol development. This avoids the effort of developing and maintaining different models. The specification might contain more details than needed for performance evaluation, implying longer simulation time, but it is functionally correct and complete. Currently, the tool does not provide traffic generators. The designer has to model them by writing special Estelle modules. Future work includes adding traffic generator modules and refining the mapping between the implementation models and the performance model. The framework defined for validation can be extended to performance analysis. The generic Estelle model of the environment, used for validation, might have to be replaced for some performance analysis purposes. However, this is the only situation requiring changes in the Estelle specification. An essential EDT feature is that the protocol specification is not modified for validation or performance evaluation and does not have to be recompiled for simulation experiments with different scenarios or performance related parameters. Further integration of the methods used for qualitative and quantitative analysis is being investigated, as well as an enhanced tool support for implementing the observers. The same observers could be used to guide the simulation experiments in both cases. Also, the eventbased approach used for guiding and qualitative properties could be extended to the performance measurements and the quantitative properties.

Acknowledgements Part of the work was supported by the European Commission, in the framework of the COPERNICUS project COP62 and the KIT-IDEMCOP action. The validation methodology was improved during the Project CNET-INT 96 PE7408, funded by CNET France Telecom.

References [1] ISO/IEC. Information Processing Systems. Estelle - A Formal Description Technique based on Extended State Transition Model. IS 9074, 1997 (1989). [2] ITU-T. Recommendation Z.100. Specification and Description Language (SDL), 1996. [3] J. Templemore-Finlayson, et al. A Graphical Representation and Prototype Editor for the FDT Estelle. Formal Description Techniques (XI) and Protocol Specification, Testing and Verification (XVIII), Kluwer Academic Publishers, 1998. [4] Estelle Development Toolset. Institut National des Télécommunications, Evry, France. Documentation is available from: http://alix.int-evry.fr/~stan/edt.html. [5] XTP Forum. Xpress Transport Protocol specification revision 4.0, 1995. The original document and an updated version are available from: http://www.mentat.com/xtp.html. [6] O. Catrina, E. Borcoci. Estelle specification and validation of XTP 4.0. Deliverable for Workpackage 2, Task 2.1, Copernicus Project COP62, 1996. [7] E. Borcoci, O. Catrina, N. Munteanu. Experiments with performance evaluation of XTP 4.0. Deliverable for Workpackage 2, Task 2.4, Copernicus project COP62, 1997. [8] O. Catrina, E. Lallet, S. Budkowski. Automatic implementation using EDT. Research Report RR 971001, Institut National des Télécommunications, Evry, France, 1997. [9] O. Catrina, S. Budkowski. Integration of subtransactions in OSI-TP. Validation of the Estelle specification using EDT. Research Report RR 981202, Institut National des Télécommunications, Evry, France, 1998. [10] C. Negulescu, E. Borcoci. SSCOP Throughput Evaluation - Simulation Based on Estelle Specification. 1st International Workshop on the FDT Estelle, Evry, France, 1998. [11] P. Godefroid, G. Holzmann. On the Verification of Temporal Properties. Protocol Speci-

21

fication, Testing and Verification XIII. Elsevier, 1993. [12] T. Jeron. Contribution a la validation des protocoles: test d'infinitude et vérification a la volée. PhD thesis, Rennes University, France, 1991. [13] O. Catrina, S. Budkowski. Simulation guiding and validation based on dependence relations between events. 13th European Simulation Multiconference, Warsaw, 1999. [14] S. Fischer, S. Leue. Formal methods for broadband and multimedia systems. Computer Networks and ISDN Systems 30, 1998. [15] A. Mitschele-Thiel, B. Müller-Closterman. Performance Engineering of SDL/MSC Systems. Tutorial. SDL Forum 1997, Evry, France. [16] P. Dembinski, S. Budkowski. Simulating Estelle specifications with time parameters. Protocol Specification, Testing and Verification VII. Elsevier, North Holland, 1987. [17] M. Hendaz, S. Budkowski. A New Approach for Protocols Performance Evaluation using Annotated Estelle Specifications. Formal Description Techniques VIII. Chapman & Hall, 1995. [18] M. Diefenbruch, et al. The QUEST Approach for the Performance Evaluation of SDL Systems. Formal Description Techniques IX, Chapman & Hall, 1996. [19] M. Steppler, M. Lott. SPEET-SDL Performance Evaluation Tool. SDL'97: Time for testing - SDL, MSC and trends. Elsevier, 1997. [20] E. Borcoci, N. Munteanu, S. Budkowski. L'évaluation des performances pour des protocoles de communication à haute complexité en utilisant les spécifications Estelle. Colloque francophone sur l'ingenierie des protocoles (CFIP'97), Hermes, Paris, 1997. [21] E. Borcoci, I. Mitrea. Multimedia Traffic Capability of Multicast Transport Protocols Simulation Study. Proceedings of the International Conference on Telecommunication (ICT'99), Korea, 1999. [22] R. Gotzhein, et al. Improving the Efficiency of Automated Protocol Implementation Using Estelle. Computer Communications 19, 1996. [23] L. Svobodova. Implementing OSI Systems. IEEE Journal on Selected Areas of Communication, vol. 7, no. 7, 1989. [24] O. Catrina, A. Nogai. On the Improvement of the Estelle Based Automatic Implementations. Formal Description Techniques (XI) and Protocol Specification, Testing and Verification (XVIII). Kluwer Academic Publishers, 1998. [25] R. Henke, H. Konig, A. Mitschele-Thiel. Derivation of Efficient Implementations from SDL Specifications Employing Data Referencing, Integrated Packet Framing and Activity Threads. SDL'97: Time for testing - SDL, MSC and trends. Elsevier, 1997. [26] E. Lallet, S. Fischer, J.-F. Verdier. A new Approach for Distributing Estelle Specifications. Formal Description Techniques VIII. Chapman & Hall, 1995. [27] J. Thees. Protocol Implementation with Estelle - from Prototypes to Efficient Implementations. 1st International Workshop on the FDT Estelle, Evry, France, 1998. [28] T. Strayer. SandiaXTP User's Guide. SandiaXTP Reference Manual. Sandia National Laboratories, USA, 1996. [29] ITU-T. Recommendation Z.120. Message Sequence Chart (MSC), 1996. [30] ITU-T Recommendation X.862. Open Systems Interconnection - Distributed Transactions Processing: Protocol specification. (ISO/IEC 10026-3), 1993. [31] ITU-T Recommendation Q.2110. Service Specific Connection Oriented Protocol (SSCOP), 1994.

22