A framework for modeling transfer protocols

A framework for modeling transfer protocols

Peter Herrmann *, Heiko Krumm

Universit�at Dortmund, Fachbereich Informatik, D-44221 Dortmund, Germany

Abstract

The notion of speci®cation frameworks transposes the framework approach from software development to the level

of formal modeling and analysis. A speci®cation framework is devoted to a special application domain. It supplies re-

usable speci®cation modules and guides the construction of speci®cations. Moreover, it provides theorems to be used as

building blocks of veri®cations. By means of a suitable framework, speci®cation and veri®cation tasks can be reduced to

the selection, parametrization and combination of framework elements resulting in a substantial support which opens

formal analysis even for real-sized problems. The transfer protocol framework addressed here is devoted to the design

of data transfer protocols. Speci®cations of used and provided communication services as well as protocol speci®cations

can be composed from its speci®cation modules. The theorems correspond to the relations between protocol mechanism

combinations and those properties of the provided service which are implemented by them. This article centers on the

application of this framework which is discussed with the help of the speci®cation of a sliding window protocol.

Moreover the structure of its veri®cation is described. The speci®cation and veri®cation technique applied is based on

L. Lamport's temporal logic of actions (TLA). We use the variant cTLA which particularly supports the modeling

of process systems. Ó 2000 Elsevier Science B.V. All rights reserved.

Keywords: Protocol speci®cation; Protocol veri®cation; Temporal logic; Framework; Protocol composition

1. Introduction

Due to recent developments in the ®eld of high-speed and multimedia communication many new datatransfer protocols and protocol variants are designed. Although standardized formal description techniques(i.e., ISO/OSI: Estelle [30] and Lotos [31], ITU: SDL [32]) are available, the protocols are developed fre-quently without any formal support. Furthermore, abstract service speci®cations, describing the relevantproperties of the communication service provided by a protocol, are often omitted. Thus, the documen-tation of a protocol development is often incomplete and ambiguous. Therefore, the correctness of theprotocol cannot be checked systematically.

On the one hand, ambiguous documentation causes the danger of design errors due to misunder-standings. This might lead to re-working e�orts, project delays, and, consequently, to higher project costs.On the other hand, the usage of formal techniques in protocol design causes signi®cant expense, too. Whilesometimes the application of these techniques can be supported by tools (e.g., special editors, interpreters,

Computer Networks 34 (2000) 317±337

www.elsevier.com/locate/comnet

* Corresponding author. Tel.: +49-231-7554836; fax: +49-231-7554730.

E-mail addresses: [email protected] (P. Herrmann), [email protected] (H. Krumm).

1389-1286/00/$ - see front matter Ó 2000 Elsevier Science B.V. All rights reserved.

PII: S 1 3 8 9 - 1 2 8 6 ( 0 0 ) 0 0 0 8 9 - X

compilers, and veri®cation tools; cf. [3,4,9,12±14,29,33,40]), formal models and formal descriptions ofprotocols have to be developed in a creative manner. Due to the complexity of modern high-speed protocolsystems, this task can be quite expensive. Furthermore, the development of formal descriptions is prone toerrors and, similar to program development, a long debugging phase may be necessary before completingthe veri®cation successfully.

The transfer protocol framework [21,22] facilitates the development of formal speci®cations similar toprogram development support by libraries of re-usable program modules. The framework contains spec-i®cation modules which can be instantiated and combined to a protocol or service speci®cation. A protocolspeci®cation consists of a set of modules, each modeling a single protocol mechanism (e.g., sequencenumbering of protocol data units (PDUs), repeat request, time out). The developer does not need to createa protocol mechanism description from scratch. Instead, he uses a module of the framework and con-centrates on suitable instantiations of parameters and on the combination of di�erent modules. Thus, hemodels the logical structure of the protocol directly, facilitating the understanding of the protocolcomponent co-operation. Furthermore, the developer creates a service speci®cation as well. This task issupported by the framework, too, which contains speci®cation modules modeling single constraints ofservices (e.g., no corruptions of transferred data, liveness of transferred data, no phantoms). The developerparametrizes and combines these modules to a service speci®cation describing the properties of the serviceto be provided by the protocol.

The transfer protocol framework supplies a comprehensive collection of speci®cation modules. Itcomprises each typical functional property of data transfer services as well as all of the protocol mech-anisms, we found in present data transfer protocols (cf. [8,35]). Moreover, it is based on few basic as-sumptions only. Therefore, the framework support is very general and it can complement otherapproaches which focus directly on problem-oriented design, construction, and modular implementationof new transfer protocols. So, modern high-speed data transfer protocols like XTP [44] and MSP [36] cane�ciently be speci®ed by means of the framework [24,27]. Moreover, the framework may be used for theformal modeling and analysis of those protocol con®gurations which are in the range of current dynamiccommunication system con®guration approaches like DaCapo [41], F-CCS [45], and AVOCA [39]. Due tothe general orientation of the framework, it should even cover the formal modeling of most futuretransfer protocols. Nevertheless extensions are possible and can easily be introduced by addition of newmodules. Furthermore, the ¯exibility of the speci®cation modules contributes to the broad applicability ofthe framework. Each module corresponds to a generic behavior type where generic module parameterssupport the adaption of module instances to special contexts and requirements. With respect to this,speci®cation modules may be viewed as behavior patterns. Relations exist to approaches which explicitlytranspose the notions of design and software patterns (cf. [11]) to the development of formal speci®cations(e.g., [15,38]). Additionally, there is further work focussing on the pattern-based and tool-assisted re-®nement of abstract cTLA speci®cations into detailed software speci®cations [37] and correspondingimplementation-oriented framework extensions may be of interest. In the sequel, however, we do not wantto stress this point in order to concentrate on practical aspects of framework-based protocol speci®cationand veri®cation.

Formal protocol veri®cation is based on separate speci®cations of the protocol and the service to beprovided. It proves that the protocol actually provides the service and is an e�ective means for the detectionof design errors. It can be performed mechanically by tools based on reachability graph analysis (e.g., statespace exploration [28], model checking [6,7,10,16,20,29]) if the number of reachable system states of theprotocol model is relatively small. However, the state space of most protocols relevant in practice exceedsthe limitations of automated tools. Thus, either the protocol speci®cation has to be simpli®ed, or theveri®cation has to be performed by symbolic logical reasoning. Both, the design of suitable simpli®ca-tions as well as the user-guided computation of logical proofs, increase the protocol development costssigni®cantly.

318 P. Herrmann, H. Krumm / Computer Networks 34 (2000) 317±337

With respect to this, the veri®cation can be facilitated substantially by the framework theorems takinginto consideration that both the service and the protocol speci®cations consist of existing frameworkmodules. Usually, each service constraint (SC) is implemented by a special protocol sub-system combiningthose protocol mechanisms which ensure that the protocol execution complies with the SC. For eachpossible pair of a SC and protocol sub-system, we veri®ed a theorem stating that the protocol sub-systemimplies the service constraint. Therefore, a sub-system of the protocol speci®cation as well as a corre-sponding theorem exist for each constraint of the service speci®cation. Thus, the protocol veri®cation canbe accomplished by identifying suitable ``SC ± protocol sub-system ± theorem'' triples. Additionally, thedeveloper has to check that the protocol mechanism speci®cations of the sub-system and the serviceconstraint speci®cation are parametrized in a suitable and consistent way. By this method, even complextransfer protocols can be veri®ed quite easily [24]. Moreover, this veri®cation method emphasizes thelogical relations between protocol sub-systems and service components supporting the understanding of thedesigned protocol.

Thus, framework-based protocol veri®cations are relatively easy to develop although they rely on formalproofs. Nevertheless, we have presently to point to some reservations concerning the stringency of veri®-cations. They result from the way, the framework theorems were proved. We used the cTLA-tool cTc [26]to compute the process compositions of the theorems. Then we designed the necessary re®nement mappingsand invariants in order to prepare the manual TLA-based proofs, which ± due to the high e�orts needed ±were not all performed in full formal detail. So, complete proof documentation exists only for some the-orems (see [17]). Moreover we did not check the proofs by means of theorem prover tools. Therefore, we donot recommend the use of the theorems for high risk applications though we are convinced of the over-allvalidity of the theorems.

For the proofs of the framework theorems, high e�orts were needed and they would substantially pro®tfrom the use of theorem prover tools. The framework application, however, is based on the design ofsuitable theorem instances which is accompanied by relatively simple parameter checks. Consequently, wemade the experience that the transfer protocol framework can successfully be applied without special tool-assistance. Nevertheless, one can provide tool-support concentrating on the analysis of compositionalspeci®cation structures, the search of appropriate theorems, the proposal of theorem instances, and thepreparation of predicate logic-based parameter checks. A corresponding tool was developed and isdescribed in [18].

Since a large number of theorems would be necessary to link all suitable protocol mechanism combi-nations with SCs, the framework supports protocol proofs which are performed in two steps. Therefore, itprovides a third collection of speci®cation modules in addition to SCs and protocol mechanisms. Thesemodules, called abstract protocol mechanisms (APMs), support speci®cations which are on an intermediateabstraction level between protocol speci®cations and service speci®cations. Consequently, the theorems donot state directly that protocol mechanisms implement SCs. Instead, the framework contains two collec-tions of theorems. The theorems of one collection state that protocol mechanism combinations implementabstract protocol mechanisms. The other theorems express that APM combinations implement SCs.

The reduction of protocol veri®cations into a series of sub-system proofs is based on a special form ofcompositionality, the superposition. It guarantees that a relevant property of a sub-system is also aproperty of the system as a whole. Superposition was introduced in [5] as a helpful means for the formaldesign of systems. Likewise, [2] proposed a speci®cation technique based on transition systems whichsupports the formal design of distributed systems by superposition. Our approach applies the speci®cationtechnique cTLA [21,37] which is based on the Temporal Logic of Actions (TLA, [34]). cTLA supports themodular de®nition of generic process types and the composition of process systems. Similarly to thestandardized formal description technique Lotos [31] (and similarly to [2]), the processes of a cTLA systeminteract via synchronous joint actions. The process composition operation of cTLA corresponds to thelogical conjunction of processes. Therefore, it covers superposition with respect to all relevant safety and

P. Herrmann, H. Krumm / Computer Networks 34 (2000) 317±337 319

liveness properties. The processes of a cTLA system can model logical behavior constraints as well ascomponents of implementations (cf. constraint-oriented and resource-oriented speci®cation styles [43]).

In the sequel, we concentrate on the practical application of the framework. Therefore, we outline cTLA,its semantics, and the transfer protocol framework concisely. Thereafter, an example application shallclarify the utilization of the framework in more detail. We describe the development of the service andprotocol speci®cations for a well known sliding window protocol (from [42]). Moreover, we discuss theveri®cation of this protocol and point out how the structure of the speci®cations guides the veri®cation.

2. cTLA

cTLA systems are composed of processes. A process is modeled by a state transition system, whosestructure is de®ned by a process type in a programming language-like syntax. As an example, we outline thede®nition of the process type Corruptions in Fig. 1. The header consists of the keyword PROCESS, theprocess type name Corruptions, and a list of generic parameters (i.e., the symbols usd and tc). usd modelsthe set of data units transferred between two service users, while the relation tc describes a set of cor-ruptions which can be tolerated. In process instances specifying that corruptions are not tolerated at all, tcis instantiated with the identity relation. The construct IMPORT refers to the inclusion of other modulescontaining de®nitions of symbols (e.g., data types, functions, and constants). We assume that the symbolkey, which speci®es the set of sequence numbers for data units, is de®ned in the module Symbols. The statespace of a process is modeled by variables declared in the section VARIABLES. In the process type Cor-ruptions buf is the only variable. It describes a set of pairs of a sequence number and a user data unit. Apredicate headed by the keyword INIT speci®es the set of initial states of a process. In Corruptions thevariable buf equals to the empty set in the initial state. The action de®nition part is headed by the keywordACTIONS. An action is a predicate about a pair of a current state and a next state, modeling a set of state

Fig. 1. cTLA safety process type Corruptions.


transitions. The current state is referenced by variables (e.g., buf) while the next state is referenced by so-called primed variables (e.g., buf0). Each pair of a current state and a next state satisfying the predicate is astate transition corresponding to an occurrence of the action. Action de®nitions can contain data pa-rameters. In the example, the action Rq(2,``data'') applies to all transitions in which the variable buf inthe next state is equal to buf in the current state extended by the pair (2,``data''). The variables, INIT,and the actions of a process de®ne a state transition system describing a set of state sequences. A statesequence models a possible behavior of the process if the ®rst state ful®lls INIT and each state transitioncorresponds to an action of the process.

The example process is a service speci®cation module of the framework modeling the constraint that theservice transmits data without corruptions. The action Rq speci®es the submission of data to the service andthe action In the delivery of transmitted data to the service user. The variable buf corresponds to the set ofall data units ever submitted. Thus, the term 9 e 2 usd :: ��krq;e� 2 buf _ �e;d� 2 tc) in the de®-nition of the action In models that a data unit submitted before (action Rq) may only be delivered to theservice user (action In) if it was corrupted only within the limits de®ned by the relation tc. According tothe distinction between safety and liveness properties (cf. [1]), the process type Corruptions speci®es onlysafety properties. Therefore, Corruptions does not rule out state sequences which contain only a ®nitenumber of state changes (i.e., processes terminating eventually are tolerated).

The process type LiveInNoAttr in Fig. 2 is an example of a framework module modeling a livenessproperty. In comparison to the process type Corruptions, listed in Fig. 1, LiveInNoAttr contains a newconstruct WF. While the other parts of LiveInNoAttr de®ne a state transition system again, WF describes thatthe action fIn has to be performed ``weak-fairly''. Similarly, by the construct SF one can declare an actionto be performed ``strong-fairly''. A weak fair action must be performed eventually if otherwise it would beenabled continuously for an in®nite period of time. A strong-fair action has to be performed even if theaction is disabled from time to time. Weak and strong fair actions were introduced in [1]. In contrast todirect liveness properties these fairness assumptions do not model implicit safety properties which might be

Fig. 2. cTLA liveness process type LiveInNoAttr.


in contrast to the (explicit) safety properties of the process. Therefore in TLA [34] and cTLA ± especially inthe transfer protocol framework ± liveness properties are modeled by weak and strong fair actions only.

To support the modularity of the transfer protocol framework, the fairness assumptions should be asweak as possible. Therefore actions are split into two actions, of which one is fair (e.g., fIn in process typeLiveInNoAttr). The other action (e.g., nIn in LiveInNoAttr) is not fair. Both fIn and nIn in LiveInNoAttrmodel the delivery of transferred user data (compare action In in process type Corruptions). The fair actionfIn speci®es that the data unit expected next in the order of transferred data will be delivered lively. Sincethe process type LiveInNoAttr shall concentrate on liveness and therefore must not constrain the delivery ofdata in general, it contains another action nIn tolerating the delivery of other data units.

Similar to Lotos [31], cTLA supports the composition of systems from processes. The processes interactvia synchronous joint actions. Action parameters model the communication of data. The variables ofa process are private and therefore cannot be accessed by other processes. Like each process, the system as awhole is a state transition system. The vector of all variables of all processes forms the system state. Asystem behavior is a sequence of system states where the state changes correspond to system actions. Eachsystem action is de®ned by the logical conjunction of process actions. In this conjunction, each process isrepresented either by a true process action or by the pseudo-action ``stutter'' denoting that the process doesnot perform a state change in this system action.

The speci®cation SlidWindService, listed in Fig. 3, models such a system composed of processes. In thepart headed by PROCESSES the processes of the system are declared. For example, the process Id is aninstance of the process type SDUId and the process C is an instance of the process type Corruptions, de-scribed above, with the parameter setting �usd; f�k; k�jk 2 usdg�. In the ACTIONS part, the system actions

Fig. 3. Service speci®cation SlidWindService.


are declared by conjunctions of process actions. For instance, the local process actions Rq of the processesId, C, Cap, and LIn are coupled to the system action Rq while the processes G, R, D, and P participate bystuttering steps only.

The speci®cation technique cTLA supports superposition (cf. [2,5]) which guarantees that a propertyful®lled by a process or sub-system is also a property of each system containing this process or sub-system.It is essential for the conception of the framework and, particularly, for structuring the veri®cation intosub-system implications. With regard to the safety properties, which constrain initial states and statetransitions of systems only, superposition can be guaranteed quite easily. Since a system state is modeled bya vector of process states which are de®ned by private variables only, properties constraining the states of asingle process also constrain the states of the whole system.

With respect to liveness properties, however, superposition is more subtle. In a system, a process actioncan be coupled with actions of other processes. Thus, the environment of a process can block the processaction, and due to the blocking, the fairness assumption of this process action may be violated. In contrastto TLA, which adopts the fairness assumptions introduced in [1] directly, cTLA therefore uses conditionalfairness assumptions only. The WF/SF constructs of cTLA refer to periods of time where a process actionis enabled as well as the action is not blocked by the environment of the process. For instance, the processLIn: LiveInNoAttr (Fig. 2) only has the liveness property that data submitted (action Rq) will be eventuallydelivered (actions fIn or nIn) if the process action fIn is not blocked by the environment of Lin toooften.

On the one hand, this restriction of liveness properties to conditional fairness directly supportssuperposition. On the other hand, however, conditional fairness assumptions are not able to expressabsolute liveness properties which are of particular interest for the system design. Nevertheless, one canspecify absolute liveness properties by means of an additional condition preventing the process envi-ronment to block fair actions too often. If one can prove the safety property that the fair process actionfIn is tolerated by the process environment whenever it is enabled due to the local process states inLiveInNoAttr, the conditional fairness corresponds to the unconditional fairness according to [1]. Allmodules of the framework, which describe liveness properties correspond to the pattern of the examplemodule LiveInNoAttr and describe fairness assumptions as weak as possible. They separate fair sub-actions (e.g., fIn) and are designed to express absolute liveness properties under the assumption that thefair sub-actions are only blocked by the environment in system states where they are disabled at all.Indeed, the modules of the framework are designed under consideration of each other in order to ful®llthis assumption.

3. Formal semantics

The language cTLA supports the modular formal speci®cation of distributed systems and applies statetransition system-based modeling like the standard languages Estelle [30] and SDL [32]. Nevertheless, thesestandard languages mainly concentrate on the structured and easy-to-read formal description of systemsand accordingly provide a rich set of language constructs. Formal veri®cations, however, need additionalmeans since the languages do not directly support formal reasoning. In contrast to these standard lan-guages cTLA has been designed under the objective of explicit veri®cation support. Therefore it is directlybased on L. Lamport's Temporal Logic of Actions TLA [34]. Thus, each cTLA process instance corre-sponds to a TLA formula. This correspondence de®nes the formal semantics of cTLA. Moreover, it enablesTLA-based veri®cation.

In TLA, canonical formulas describe the safety and liveness properties of state transition systems inaccordance to [1]. Inference rules support the syntactical deduction of valid formulas. Moreover, there is aninteresting conception of re®nement. A more detailed speci®cation Im correctly re®nes a more abstract


speci®cation Sp if the implication Im ) Sp is a valid TLA-formula, where Sp is the speci®cation Sp undersubstitution of its free-state variable occurrences by functions of the state variables of Im. These functionsform the so-called re®nement mapping. Due to the correct re®nement Im implements Sp in the practicallyrelevant sense that Im meets the safety and liveness requirements expressed by Sp. cTLA adopts thesenotions and techniques of TLA. It is an extension of TLA adding explicit notions of processes, processtypes, and process composition (as mentioned, the superposition character of composition is of particularinterest). Furthermore, there is a di�erent look of cTLA speci®cations since in cTLA canonical parts offormulas are not explicitly written down.

The TLA formula which corresponds to a process instance depends on the parameter settings of theinstantiation and on the de®nition of the process type. Process type parameters are generic. As usual, weassume that the text strings of actual parameters replace the formal parameter occurrences in the processtype de®nitions. With respect to the process type de®nitions, there are two forms, one for simple processesand one for systems. In both cases, the TLA formulas of process instances are in canonical form and referdirectly to predicate and action de®nitions of the process type.

For clari®cation of simple processes let LIn : LiveInNoAttr be a process instance of process type Live-InNoAttr listed in Fig. 2. LIn corresponds to following TLA formula dLIn where the symbols INIT, Rq,fIn, and nIn represent the initial state predicate and actions of the process type LiveInNoAttr:

dLIn,INIT^��Rq_9krq 2 key :: fIn�krq�_9krq 2 key :: nIn�krq��cRq;maxIn�^

8krq 2 key :: WF�cRq;maxIn��fIn�krq� ^ krq 2 efIn�

dLIn is an usual canonical TLA formula describing the safety and liveness properties of a state transitionsystem with the two state variables cRq and maxIn. The ®rst four lines are devoted to safety properties andde®ne the initial states and the next state relation of the state transition system. The last line addressesliveness and adds fairness assumptions on sub-relations of the next state relation. There is only one par-ticularity in formula dLIn. While usually fairness operators refer directly to actions of the next state relation,here the weak fairness is not applied to the action fIn but to a sub-action of it, namely to the conditionalaction fIn�krq� ^ krq 2 efIn, where an additional state variable efIn is addressed. We assume that for eachfair action of a process a corresponding environment readiness variable like efIn exists. The variable isshared between the process and its environment. It is written by the environment and read by the process. Itacts as an abstraction of the process environment and indicates the current readiness of the environment forthe action. The value of the variable is the set of those action parameter values for which the environmentcurrently does not block occurrences of the action. For instance, when efIn is empty, the environment isassumed to block the action fIn under each possible parametrization. In contrast, the TLA formuladLIn ^�efIn � key, where key denotes the set of all possible values for the action parameter krq, describesa state transition system modeling the process LIn in an environment which always tolerates state transi-tions according to fIn.

The TLA formula of systems shall be explained by an extension of the example. We refer to the processtype SlidWindService which is de®ned in Fig. 3. As explained in Section 2, instances of this type are systemswhich are composed from eight process instances Id; . . . ; LIn. Since all other processes, besides LIn do notexpress liveness properties, fairness assumptions only apply to actions of LIn (as shown in Fig. 2 the actionLIn.fIn is accompanied by a fairness statement). Let SWS : SlidWindService(usd) be an instance of thissystem type. It corresponds to following canonical TLA formula dSWS :


dSWS , Id:INIT ^ C:INIT ^ G:INIT ^ R:INIT^D:INIT ^ P:INIT ^ Cap:INIT ^ LIn:INIT ^��9krq 2 key; d 2 usd :: Rq�krq; d�_9krq 2 key; d 2 usd :: fIn�krq; d�_9krq 2 key; d 2 usd :: nIn�krq; d��Id:cRq;C:buf;...;LIn:cRq;LIn:maxIn�^

8krq 2 key ::WF�Id:cRq;C:buf;...;LIn:maxIn��9d 2 usd :: fIn�krq; d� ^ krq 2 sefIn�

The formula dSWS refers to the de®nitions of the initial predicates of the process instances. Thus, LIn.INITstands for the initial predicate of LIn. Moreover, dSWS refers to the action de®nitions of process typeSlidWindService which are conjunctions of process actions. For instance, as listed in Fig. 3, fIn(krq,d)is de®ned as Id.In(krq) ^ . . .^ LIn.fIn(krq). Since the action fIn of SWS contains the fair processaction LIn.fIn, it also is accompanied by a fairness statement. The last line of dSWS states a correspondingfairness assumption for the system action fIn. As in simple processes the fairness assumption is condi-tional and the symbol sefIn denotes the corresponding environment readiness variable for the system actionfIn.

For the reasoning on process compositions not only TLA formulas of the form of dSWS are used.Moreover, a compositional form exists which is a conjunction of the TLA formulas of the constitutingprocesses. Thus, the compositional formula gSWS of SWS is:gSWS , bId ^ bC ^ . . . ^dLIn ^ SCC^

��LIn:efIn � fkrq 2 keyj9d 2 usd :: krq 2 sefIn ^ Enabled�Id:In�krq��^ . . . ^ Enabled�Cap:In�krq��g�

In addition to the formulas of the constituting processes, the compositional formula gSWS conjoins twoinvariants. The so-called coupling constraint SCC expresses the safety conditions which result from thespecial action coupling of a system, e.g., it states with respect to the action LIn.fIn(krq) that this actionhas to occur in combination with simultaneous occurrences of the actions Id.In(krq),C:In�krq;d�; . . . ;Cap:In�krq�. The last invariant de®nes the environment readiness variable LIn:efIn ofprocess LIn as state function: The action fIn of process LIn is tolerated by LIn's environment for a pa-rameter value krq, exactly if the environment of SWS tolerates the system action fIn and all these actionsof the other processes of SWS are enabled, which are coupled with LIn.fIn within the system action fIn.

Besides the syntax and the TLA transformation rules outlined above, the cTLA language de®nitioncontains few conditions restricting the content of system action de®nitions especially in context with theoccurrence of fair actions. In the main, these conditions express the assumption, that fair process actionsare disjoint and that for each fair process action there is exactly one containing system action. Under theseconditions, one can prove that the compositional TLA formula of a system instance is equivalent to thedirect canonical TLA formula of this system instance (the proof is described in [17]). In the example thismeans that dSWS () gSWS is valid.

From the equivalence of the compositional formula with the direct canonical formula of a system in-stance, we can infer that the compositional formula is free from contradiction. In combination with theform of the compositional formula which conjoins the formulas of the constituting processes, we can inferthat process composition implies the consistent logical conjunction of processes. Therefore, a system for-mula implies the formula of each constituting process. This means, that process composition has idealsuperposition character because the safety and liveness properties of processes are also properties ofcontaining systems. Moreover, since logical conjunction is commutative and associative, superpositionapplies not only to processes but also to sub-systems of a system.


Superposition facilitates the formal veri®cation of system properties. In order to prove that a system Shas the properties expressed by a TLA formula P, it is su�cient to ®nd a sub-system Sys of S for which theTLA formula cSys ) P can be proven. This supports the broad applicability of the theorems supplied by thetransfer protocol framework. Theorems have the form of TLA implications from a parameter conditionPars, a protocol mechanism sub-system Sys, and an environment condition invariant EnvCond to a serviceproperty speci®cation (e.g., Pars ^ Sys ^�EnvCond ) LiveInNoAttr, cf. Fig. 8 in Section 7). The sub-systems Sys of the theorems are relatively small and really concentrate on these protocol mechanisms whichare necessary for the implementation of certain service properties. Besides few parameter and non-blockingconditions, the theorems do not refer to the environment of Sys. Therefore, a relatively small number oftheorems can cover the relevant relations between protocol mechanisms and service properties. In practicalproofs that a speci®c protocol implements a service with special functional properties, there is a very highprobability that one ®nds suitable instances of framework theorems and consequently does not need toperform original proofs.

4. Transfer protocol framework

The Transfer Protocol Framework consists of speci®cation modules and theorems. The speci®cationmodules are cTLA process type declarations which describe protocol mechanisms, constraints of a basictransfer medium, and SCs. They are structured into three layers:

1. Service constraints (SCs): An SC (e.g., an instance of the process type Corruptions in Fig. 1) models asingle property of a communication service. It is instantiated from an SC module of the framework. Servicespeci®cations are combined from SC instances. The framework contains SCs specifying that transmissionerrors (i.e., corruptions, duplicates, re-orderings, gaps, phantoms) do not occur, that the service capacity islimited, and that the service guarantees a live delivery of transmitted user or signalling data. By other SCs,one can model aspects of connection handling, datagram transfer, and functional quality of service. A thirdgroup of SCs allows to model constraints regarding the coordination of di�erent connections (e.g., limitingthe number of connections currently active in a station).

2. Abstract protocol mechanisms (APMs) and abstract medium constraints (AMCs): An abstract protocolspeci®cation is modeled by a system composed of APMs and AMCs. The APMs and AMCs re¯ect thecommon scenario of protocol descriptions. Protocol entities co-operate and communicate by means of abasic medium. With respect to this, the di�erent APMs model single mechanisms of protocol entities andthe AMCs describe properties of the basic medium. The APMs specify abstractions of protocol mechanismsused in real protocols. They only model the essential functions of the protocol mechanisms and do notattach importance to details of e�cient implementation. For instance, the APM modeling sequencenumbering is not concerned with the re-use of numbers and therefore is based on an in®nite range ofnumbers. Besides sequence numbering, the framework contains APMs modeling protocol mechanisms usedby various transfer protocols (cf. [8,35]). One can specify the storage of user data, cyclic redundancy checks,segmentation and re-assembly of user data, as well as the handling of re-ordered and defective data.Moreover, APMs are available for modeling the management of feedback messages (i.e., acknowledgementof data, rejection of defective data units, granting new transmission credits), ¯ow control mechanisms, andthe handling of messages to trigger a feedback from the receiver to the transmitter of user data. Anothergroup of APMs supports the speci®cation of connection handling, datagram transfer, functional quality ofservice management, and mechanisms to coordinate di�erent connections. Since the basic medium is aservice, the AMCs model service contraints similar to the SCs.

3. Finite APMs (FAPMs) and Abstract medium constraints (AMCs): A system of FAPMs and AMCsmodels a transfer protocol in a quite direct manner. Each protocol mechanism of the protocol is modeledby an FAPM instance. AMC instances specify the basic medium. A composition of the FAPM instances


and AMC instances forms a structured formal protocol speci®cation. In contrast to the APMs, the FAPMsuse only ®nite variables. Thus, sequence numbers have to be re-used which corresponds directly to themechanism employed in sliding window protocols. Furthermore, connections have to be identi®ed by a®nite number of connection identi®ers. Therefore, besides FAPMs similar to the APMs listed above, theframework contains FAPMs modeling the administration of sequence numbers and connection identi®ers.

The theorems of the framework are logical implications between cTLA systems. Due to the three-layeredstructure of the speci®cations patterns, two kinds of theorems are used:· An SC theorem states that a system modeled by APMs and AMCs implies an SC. For some SCs of the

framework, more than one theorem is available. This re¯ects that a service constraint can be realized bydi�erent protocol mechanism combinations.

· The gap between an abstract protocol system modeled by APMs and AMCs and a direct protocol modelconsisting of FAPMs and AMCs is bridged by APM and AMC theorems. A theorem states that a systemof FAPMs and AMCs implements a certain APM or AMC.

The structure of the framework is further re®ned by distinguishing safety and liveness properties. Thus,each of the three sorts of speci®cation modules contains two groups of modules called safety resp. livenessprocess types. Likewise, the theorems are classi®ed into safety and liveness theorems according to theprocess on the right-hand side of the implication. The theorems are logical implications as listed below:· Safety theorem: Pars ^ Sys) �Safety�Proc.· Liveness theorem: Pars ^ Sys ^�EnvCond ) �Liveness�Proc.The system de®nition Sys, the central part of the left-hand side of a theorem implication, describes a systemcomposed from process instances. The theorem expresses that this system implements the process Proclisted on the right-hand side of the implication. The process instances of Sys are parametrized instantiationsof process types. Since process types must not be parametrized arbitrarily, a predicate logic formula Parsde®nes a su�cient condition for correct and consistent process parametrizations. Furthermore, in livenesstheorems the left-hand side of the implication contains an invariant, the so-called environment conditionEnvCond. This condition constrains the behavior of the environment of the system Sys. It rules out that fairactions of Sys may be blocked by the environment too often.

Currently, the transfer protocol framework contains 133 speci®cation patterns (28 SCs, 44 APMs, 14AMCs, and 47 FAPMs) and 165 theorems (31 SC theorems and 134 APM theorems).

5. Service speci®cation

Our protocol example shall implement a reliable and live simplex data transfer service of a ®xed capacity.Particularly, data must be transmitted without errors. Thus, the service has to ful®ll ®ve service constraints:transmitted data are not corrupted; the stream of data delivered to the receiver does not contain gaps; thedelivered data are not re-ordered; duplicates of data are not delivered; the stream of delivered data does notcontain phantoms. Another SC limits the capacity of the service. At the same time only a certain number ofdata units ± eight in this example ± may be sent and not yet delivered. The last service constraint re¯ectsliveness aspects. The service is alive if it eventually delivers all transmitted data units to the receiverguaranteeing that data may not be lost due to inactivity. Furthermore, due to the liveness of the service thetransmitting service user will be able to submit new data units in intervals since each data delivery causesthe amount of data falling below the capacity limit. Thus, after a delivery at least one new data unit may betransmitted.

To create a formal speci®cation of this service, at ®rst we design constraint speci®cations, each modelingonly one of the SCs listed above (cf. upper part of Fig. 4). As already mentioned, the constraint speci®-cations are developed parametrizing SCs of the transfer protocol framework. In the second step, wecompose the constraint speci®cations to the service speci®cation.


The speci®cation SlidWindService, listed in Fig. 3, models the service. It contains a parameter usd

de®ning the set of data units to be transmitted by the service. For instance, the replacement of usd by theset f0; . . . ; 255g speci®es a byte-oriented data transfer service. The service speci®cation SlidWindServiceconsists of the eight constraints Id, C, G, R, D, P, Cap, and LIn which will be developed by instantiating theframework SCs SDUId, Corruptions, Gaps, Re-orderings, Duplicates, Phantoms, Capacity, resp. LiveIn-NoAttr.

Id is a special constraint which models the assignment of an unambiguous and ordered sequence numberto each data unit submitted. These sequence numbers are necessary to detect transmission errors. The otherseven constraints processes specify the seven SCs mentioned above. For example, the constraint C modelsthat only data which are not corrupted during the transmission may be delivered to the service user. It is aninstantiation of the SC Corruptions, listed in Fig. 1, which uses the process parameter usd and tc. usdcorresponds to the global parameters usd in the process SlidWindService. By the relation tc we can ®x, ifand to which degree corruptions of data may be tolerated. For instance, if one models byte-oriented datatransfer, the replacement of tc by f�k; 2 � �k div 2��g [ f�k; 2 � �k div 2� 1��g speci®es that one tolerates thecorruption of the lowest priority bit. Since in our example corruptions must not occur, we replace tc by theidentity relation f�k; k� j k 2 usdg. The constraint process G models the SC that the stream of delivereddata has no gaps. G is instantiated from the SC Gaps, the parameter tg of which describes the maximum sizeof gaps. We replace it by the value 0. The Constraints R, D, and P model the SCs which exclude re-orderings, duplicates, and phantoms in the stream of delivered data. The capacity of the service is modeledby the constraint Cap while the liveness constraint process LIn of type LiveInNoAttr (Fig. 2) speci®es thatthe service must be alive.

Fig. 4. Structure of service and protocol speci®cations.


The actions Rq, fIn, and nIn are speci®ed in the service speci®cation SlidWindService. By Rq thesubmission of a new data unit d by the transmitting service user is modeled. During the submission,the sequence number krq is assigned to the data unit d. Rq is a conjunction of the process action Rq withthe process constraints Id, C, Cap, and LIn while the other processes do not contribute with a processaction. cTLA, however, demands that the processes G, R, D, and P perform a local stuttering step duringthe execution of Rq. Thus, it models concurrency by interleaving.

The delivery of data units d with sequence numbers krq to the receiving service user is speci®ed by theactions fIn and nIn. Since the service should be performed lively, we have to provide the actionmodeling the data delivery with a fairness assumption. As described in Section 2, we reduce this action toa weak fair action fIn and to a complementary non-fair action nIn. In both actions the constraintprocesses Id, C, G, R, D, P, and Cap participate with their process actions In. From the process LIn, theprocess action fIn is coupled to the system action fIn and the process action nIn to nIn. fIn modelsthe delivery of data essential for the progress of the transmission. For instance, the delivery of a data unitwhich was sent but not yet delivered is modeled by fIn. In contrast, nIn speci®es the delivery of datanot important for the progress of the transmission (e.g., the delivery of duplicates). Since in our exampleall data deliveries are essential, the action nIn is never enabled. Thus, we can omit it in a simpli®eddescription.

The action fIn of system SlidWindService is weak fair since it contains the process action fIn of theprocess LIn which is weak fair as well (cf. Fig. 2). Therefore, if fIn is continuously enabled, it willeventually be selected for execution.

6. Protocol speci®cation

The sliding window protocol [42] shall implement the data transfer service introduced above. Theprotocol consists of a transmitter entity S at the station of the data transmitter and a receiver entity R at thereceiver site which communicate by means of a full duplex basic service (cf. lower part of Fig. 4). The basicservice is modeled by two simplex data channels M and A. It is less reliable than the service to be providedand we assume that it guarantees only that corruptions, re-orderings, and phantoms do not occur duringthe transmission. Thus, data losses and duplicates are possible. We model the basic service composing thefollowing SCs: data units are not corrupted; data units are delivered in correct order; the stream of de-livered data does not contain phantoms. This kind of data transfer quality is quite realistic. It exists if thepoint-to-point data transfer used is protected against corruptions but not against data losses due to bu�erover¯ows in transit nodes. Duplicates may occur due to incorrect copying of data in the transit nodes.Furthermore, we demand that the basic service guarantees the following liveness assumption: If the user ofthe basic service repeatedly sends data units with a certain attribute, eventually one of these data units willbe delivered to its peer. Without this liveness assumption, data units essential for the transmission might belost again and again leading to livelocks.

The main task of the protocol entities S and R of the sliding window protocol is to detect and toremedy data losses and duplicates. Furthermore, the capacity and liveness of the service provided by theprotocol have to be guaranteed. The protocol uses a set of protocol functions customary for mostmodern data transfer protocols (cf. [8,35]). Data losses and duplicates are detected by means of sequencenumbers. Each new data unit submitted to the protocol entity S is assigned a sequence number. Thedata unit and its sequence number are transmitted together in a protocol data packet, so-called PDU.Due to the order of the sequence numbers, the receiver entity R detects duplications and gaps. Du-plicated data will be ignored while gaps are remedied by selective retransmission. The protocol appliesthe method ``Positive Acknowledgement with Retransmission'' (PAR). In intervals, S retransmits dataunits which are still not con®rmed. To con®rm data units, R transmits con®rmation PDUs to S which


contain the sequence number sack of the data unit delivered last to the service user. By this PDU alldata units are con®rmed, of which the sequence numbers are lower or equal to sack. S guarantees the®nite capacity of the service provided since it does only accept a new data unit for transmission, if lessthan eight data units are currently not con®rmed. The liveness of the service is guaranteed since on theone hand, S transmits new data units and retransmits uncon®rmed data units to R in intervals. On theother hand, R delivers all correct data units to the service user and repeatedly transmits con®rmationPDUs to S.

The speci®cation SlidWindProtocol of the sliding window protocol (Figs. 5 and 6) is designed byparametrizing and composing processes of the framework. 1 Like the service speci®cation, SlidWindPro-tocol contains a parameter usd denoting the set of data units transferred by the protocol. The parameterreplacements of the process instances are de®ned in a separate process SWParameters listed below. In thePROCESSES part of the speci®cation (cf. Fig. 5) the processes modeling the entities and the basic channelsare listed. The transmitter protocol entity S is speci®ed by the processes SBK, SBU, SAck, SCap, andSLMRq instantiated from FAPMs of the framework. They model protocol mechanisms to maintain se-quence numbers as well as data units, to handle con®rmation PDUs, to limit the size of the transmitterbu�er, and to guarantee the liveness by transmitting data units in intervals.

The receiver protocol entity is modeled by the processes RBK, RBU, RG, RR, RD, RP, RAck, RLARq,and RLIn which are also instantiated from FAPMs. These processes specify the protocol mechanisms tomaintain sequence numbers as well as data units, to deliver data to the service users in the correct order,and to con®rm delivered data. Furthermore, RLARq and RLIn guarantee the liveness of the entity sincecon®rmation PDUs and data deliveries are repeatedly triggered.

The basic data channel M models the transfer of user data and the so-called protocol control infor-mation (PCI) within PDUs from S to R. We specify it by means of the processes MId, MC, MR, MP, andMLI which are instantiated from AMCs of the framework. Like the SC Id, MId is a special constraintmodeling the assignment of data units to PDUs to be transmitted. By MC, MR, and MP we model thattransmitted data units are neither corrupted nor re-ordered and that phantoms are not delivered. MLIguarantees that, if PDUs with a certain attribute are sent in intervals, eventually one of them will be de-livered to the protocol entity R. The basic data channel A modeling the transfer of PCI within PDUs fromR to S is speci®ed by the processes AId, AC, AR, AP, and ALI, which correspond to the constraints ofchannel M.

The coupling of process actions to system actions is described in the part of the speci®cation headed byACTIONS (cf. Fig. 6). The actions In, MRq, MIn, ARq, and AIn are each speci®ed by a fair and a com-plementary non-fair action. Thus, fMRq speci®es the transmission of PDUs which are essential for theprogress of the communication. In contrast, nMRq models transmissions which are allowed and for the sakeof e�ciency often are also desirable but at the present state not important for the liveness of the protocol.The speci®cation respects the distribution of the protocol entities S and R since either the processes of S orthose of R participate in a system action by stuttering steps only.

The constraints are developed from framework processes by instantiation of process parameters. In Fig.7, the speci®cation SWParameters lists the de®nitions of the actual parameter types. The identi®er swpdumodels the format of the PDUs of the sliding window protocol. It is a record consisting of the threecomponents info, seq, and ack. Data units transmitted in the PDU are stored in the record componentinfo. In the element seq, either the sequence number of a data unit is stored which can be a naturalnumber or the special symbol ``notsent'' denoting a phantom (data type key). Or the special symbol

1 Due to the size of the speci®cation, we abstain from listing most process parameters in the PROCESSES part. In the ACTIONS part,

most system actions are listed without action parameters and local process actions.


``��'' marks that the PDU does not contain a data unit. The sequence number of the data unit deliveredlast to the service user is stored in the record component ack.

The sequence numbers of data units sent resp. con®rmed form the protocol control information (PCI) ofa PDU. Thus, the identi®er spci de®nes a record consisting only of the components seq and ack.swspci models a pointer to the PCI of a PDU. It maps a PDU record to the PCI record, of which thecomponents seq and ack contain the same values as in the PDU.

Fig. 5. Protocol Speci®cation SlidWindProtocol (PROCESSES-part).


As already mentioned in Section 4, we specify the sliding window protocol in two steps. First, we createthe detailed protocol speci®cation. In the second step, we develop a more abstract protocol speci®cationwhich models the distributed functionality of the entities but contains variables of an in®nite range. Thus,we abstract from protocol errors due to the reuse of sequence numbers and connection identi®ers in theabstract speci®cation. The abstract speci®cation supports the reduction of the protocol veri®cation into twosimpler steps (cf. Section 7). In the abstract protocol speci®cation, we model the protocol entities by theconstraint processes SBK, RBK, SBU, RBU, RG, RR, RD, SAck, RAck, SCap, SLMRq, RLARq, and RLInagain which, however, are instantiated from APMs this time. To model the basic data channels M and A,we use the same AMCs as in the speci®cation SlidWindProtocol.

7. Veri®cation

The protocol veri®cation guarantees that the communication service speci®ed in Section 5 is imple-mented by the sliding window protocol described in Section 6. Due to the compositionality of cTLA we can

Fig. 6. Protocol Speci®cation SlidWindProtocol (ACTIONS-part).


reduce the veri®cation into a series of simpler proof steps. In each proof step, we verify that a single SC isrealized by a protocol sub-system consisting of only some protocol mechanisms. Each proof step corre-sponds directly to a framework theorem. We assume that the theorems are correct though we have to referto the reservations concerning the stringency of the presently available theorem proofs described in theintroduction. Therefore, we have to check only if the protocol speci®cation contains all protocol mecha-nisms necessary for the SC. Furthermore, the actual parameters of the protocol mechanisms have to beconsistent to each other and to those of the SC realized. Thus, we can reduce the protocol veri®cation intothe simple selection and consistency checking of framework theorems.

The protocol veri®cation is reduced to two major steps. First, we prove that the communication serviceis ful®lled by the abstract protocol modeled by APMs and AMCs. Second, we verify that the abstractprotocol speci®cation is implemented by the more detailed sliding window protocol speci®cation con-sisting of FAPMs and AMCs. To perform the ®rst step, we apply eight framework theorems, eachproving one SC of the service speci®cation. As an example, we list the theorem instance verifying aninstance of the liveness SC LiveInNoAttr 2 in Fig. 8. The theorem states that an instance of the SCLiveInNoAttr, i.e., LIn, is implemented by a protocol system which contains the processes of Sys as a sub-system if the conditions Pars and �EnvCond hold. Sys consists of instances of the APMs SLiveMRq,RLiveARq, RLiveIn, and RAcknowledge as well as instances of the AMCs MSDUId, MCorruptions,MPhantoms, MLiveIn, ASDUId, ACorruptions, APhantoms, and ALiveIn. It guarantees that user data(SLiveMRq) and con®rmations (RLiveARq) are transmitted arbitrarily often between the protocol entities,that correctly transmitted user data are delivered to the service user (RLiveIn), and that only delivereddata are con®rmed (RAcknowledge). Furthermore the basic data channels are alive (MLiveIn and ALi-veIn) and do not deliver corrupted data or phantoms (MSDUId, MCorruptions, MPhantoms, ASDUId,ACorruptions, and APhantoms).

While instantiating the formal parameters of the constraint processes in Sys according to the description inSection 6, we adapted the theorem to our example. Since the abstract protocol speci®cation contains instances

Fig. 7. Parameter de®nitions of SWParameters.

2 To reduce the speci®cation size, we omitted the actual parameters of the processes in the protocol sub-system de®nition.


of all APMs and AMCs listed in Sys, which are coupled in accordance with the (not explicitly listed) couplingformula CCLiveInNoAttr, Sys is a sub-system of the abstract sliding window protocol. The replacements of theparameters are consistent if the formula Pars holds. The ®rst conjunct of Pars is a tautology and thereforeholds. The other conjuncts express that, if two PDUs p and q are identical, their record components p:seq andq:seq resp. p:ack and q:ack must have equal values as well. These conjuncts hold trivially since two records areequal per de®nition if all record components (particularly seq and ack) are equal as well.

The temporal condition �EnvCond guarantees that LiveInNoAttr is implemented not only by the sub-system Sys but also by the whole abstract sliding window protocol. A liveness proof might fail if the entiresystem contains processes weakening the liveness of the APMs and AMCs in Sys. For instance, if the entiresystem contains an APM preventing the delivery of user data at all, Sys could of course not guarantee theliveness of the SC LiveInNoAttr. During the design of the theorem, we veri®ed that except for the APMDataChanOpenR all APMs and AMCs of the framework ful®ll the condition �EnvCond. DataChanOpenR,however, is not a part of the abstract protocol speci®cation. Thus, �EnvCond also holds, and we provedthat the abstract sliding window protocol implements the service constraint LIn modeled as an instance ofthe SC LiveInNoAttr. In the same way we verify the other seven SCs of the service speci®cation.

Thereafter, the second major proof step veri®es that the abstract sliding window protocol speci®cation isful®lled by the more detailed one. It is performed accordingly. By the application of 13 framework theo-

Fig. 8. Theorem LiveInNoAttr.


rems, we prove that the 13 APMs of the abstract protocol speci®cation are ful®lled. The proof of the AMCsis not necessary since the basic services used by the entities of the detailed resp. abstract protocol aremodeled by identical AMCs.

8. Conclusion

We outlined the essential features of the transfer protocol framework and its application to the formalspeci®cation and veri®cation of communication protocols with the help of a sliding window protocol ex-ample. Similarly, more complex protocols were examined with remarkably less expense of work. For in-stance, the high-speed transfer protocol XTP [44] was speci®ed and veri®ed within three weeks [24]. Theframework can be accessed via WWW (http://ls4-www.informatik.uni-dortmund.de/RVS/P-TPM).

Currently, we extend the speci®cation technique cTLA. Besides the modeling of event-discrete, not time-valued dynamical behaviors, cTLA can also be used to specify real-time properties and continuous be-haviors [19,23]. We are going to adapt the framework approach to the modeling of distributed realtimesystems. At the moment, we examine the application ®eld of chemical engineering system control [25].Furthermore, the cTLA extension can also be utilized for communication protocols (e.g., modeling thetransmission of multimedia data).

References

[1] B. Alpern, F.B. Schneider, De®ning liveness, Inform. Proc. Lett. 21 (1985) 181±185.

[2] R.J.R. Back, R. Kurki-Suonio, Decentralization of process nets with a centralized control, Distrib. Comp. 3 (1989) 73±87.

[3] M. Broy, F. Huber, B. Paech, B. Rumpe, K. Spies, Software and system modeling based on a uni®ed formal semantics, in:

M. Broy, B. Rumpe (Eds.), Proceedings of the RTSE'97, Lecture Notes in Computer Science, vol. 1526, Springer, Berlin, 1998.

[4] S. Budkowski, Estelle development toolset, Comp. Netw. and ISDN Sys. 25 (1992) 63±82.

[5] K.M. Chandy, J. Misra, Parallel Program Design ± A Foundation, Addison-Wesley, Reading, MA, 1988.

[6] E.M. Clarke, E.A. Emerson, A.P. Sistla, Automatic veri®cation of ®nite-state concurrent systems using temporal logic

speci®cations, ACM Trans. Prog. Lang. and Sys. 8 (1986) 244±263.

[7] E.M. Clarke, O. Grumberg, D.E. Long, Model checking and abstraction, ACM Trans. Prog. Lang and Sys. 16 (1994) 1512±1542.

[8] W.A. Doeringer, D. Dykeman, M. Kaiserswerth, W. Meister, H. Rudin, R. Williamson, A survey of light-weight transport

protocols for high-speed networks, IEEE Trans. Comm. 38 (1990) 2025±2039.

[9] U. Engberg, P. Grùnning, L. Lamport, Mechanical veri®cation of concurrent systems with TLA, in: G. von Bochmann, D.K.

Probst (Eds.), Proceedings of the CAV'92, Lecture Notes in Computer Science, vol. 663, Springer, Berlin, 1992, pp. 44±55.

[10] J.-C. Fernandez, L. Mounier, On the ¯y veri®cation of behavioural equivalences and preorders, in: Lecture Notes in Computer

Science, vol. 575, Springer, Berlin, 1991, pp. 181±191.

[11] E. Gamma, R. Helm, R. Johnson, J. Vlissides, Design Patterns ± Elements of Reusable Object-Oriented Software, Addison-

Wesley, Reading, MA, 1995.

[12] H. Garavel, M. Jorgensen, R. Mateescu, Ch. Recheur, M. Sighireanu, B. Vivien, CADP'97 ± status, applications and perspectives,

in: COST247 Workshop on Appl. Form. Methods in Sys. Design, 1997.

[13] S.J. Garland, J.V. Guttag, J.J. Horning, An overview of larch, in: P. Lauer (Ed.), Functional Programming, Concurrency,

Simulation, and Automated Reasoning, Lecture Notes in Computer Science, vol. 693, Springer, Berlin, 1993, pp. 329±348.

[14] S.J. Garland, N.A. Lynch, M. Vaziri, IOA: a language for specifying, programming, and validating distributed systems, MIT

Laboratory for Computer Science, 1997.

[15] B. Geppert, R. Gotzhein, F. R�oûler, Con®guring communication protocols using SDL patterns, in: A. Cavalli, A. Sarma (Eds.),

Proceedings of the SDL'97, Elsevier, Amsterdam, 1997.

[16] R. Gerth, D. Peled, M.Y. Vardi, P. Wolper, Simple on-the-¯y automatic veri®cation of linear temporal logic, in: P. Dembi�nski,

M. �Sredniawa (Eds.), Proceedings of the PSTV XV, Chapman & Hall, London, 1995, pp. 3±18.

[17] P. Herrmann, Problemnaher korrektheitssichernder Entwurf von Hochleistungsprotokollen, Deutscher Universit�atsverlag, 1998

(in German).

[18] P. Herrmann, O. Dr�ogehorn, W. Geisselhardt, H. Krumm, Tool-supported formal veri®cation of highspeed transfer protocol

designs, in: Proceedings of the ICOTS'99, ATSMA, 1999, pp. 531±541.


[19] P. Herrmann, G. Graw, H. Krumm, Compositional speci®cation and structured veri®cation of hybrid systems in cTLA, in:

Proceedings of the ISORC'98, IEEE Computer Society Press, Silver Spring, MD, 1998, pp. 335±340.

[20] P. Herrmann, T. Kraatz, H. Krumm, M. Stange, Automated veri®cation of re®nements of concurrent and distributed systems,

Research Report 541, Universit�at Dortmund, Fachbereich Informatik, 1994.

[21] P. Herrmann, H. Krumm, Compositional speci®cation and veri®cation of high-speed transfer protocols, in: S.T. Vuong, S.T.

Chanson (Eds.), Proceedings of the PSTV XIV, Chapman & Hall, London, 1994, pp. 339±346.

[22] P. Herrmann, H. Krumm, Re-usable veri®cation elements for high-speed transfer protocol con®gurations, in: P. Dembi�nski,

M. �Sredniawa (Eds.), Proceedings of the PSTV XV, Chapman & Hall, London, 1995, pp. 171±186.

[23] P. Herrmann, H. Krumm, Speci®cation of hybrid systems in cTLA+, in: Proceedings of the WPDRTS'97, IEEE Computer Society

Press, Silver Spring, MD, 1997, pp. 212±216.

[24] P. Herrmann, H. Krumm, Modular speci®cation and veri®cation of XTP, Telecom. Sys. 9 (1998) 207±221.

[25] P. Herrmann, H. Krumm, Formal hazard analysis of hybrid systems in cTLA, in: Proceedings of the SRDS'99, IEEE Computer

Society Press, Silver Spring, MD, 1999, pp. 68±77.

[26] C. Heyl, A. Mester, H. Krumm, cTc ± a tool supporting the construction of cTLA-speci®cations, in: T. Margaria, B. Ste�en (Eds.),

Proceedings of the TACAS'96, Lecture Notes in Computer Science, vol. 1055, Springer, Berlin, 1996, pp. 407±411.

[27] V. Hinz, Formale Spezi®kation und Veri®kation eines Hochleistungstransferprotokolls mit dem Transferprotokollframework,

Diploma Thesis, University of Dortmund, 1998 (in German).

[28] G.J. Holzmann, Algorithms for automated protocol veri®cation, AT&T Tech. J. (1990) 32±44.

[29] G.J. Holzmann, The model checker spin, IEEE Trans. Soft. Eng. 23 (1997) 279±295.

[30] ISO, Information technology ± Open Systems Interconnection ± ESTELLE: A formal description technique based on an extended

state transition model (Amendment 1), International Standard ISO/IEC 9074, 1997.

[31] ISO, Information processing systems ± Open Systems Interconnection ± LOTOS ± A formal description technique based on the

temporal ordering of observational behaviour, International Standard ISO 8807, 1989.

[32] ITU, SG X: Recommendation Z.100: CCITT Speci®cation and Description Language SDL, 1993.

[33] R.P. Kurshan, Computer-Aided Veri®cation of Coordinating Processes: The Auto-mata-Theoretic Approach, Princeton

University Press, Princeton, NJ, 1995.

[34] L. Lamport, The temporal logic of actions, ACM Trans. Prog. Lang. and Sys. 16 (1994) 872±923.

[35] T.F. La Porta, M. Schwartz, Architectures, features, and implementation of high-speed transport protocols, IEEE Netw. Mag.

(1991) 14±22.

[36] T.F. La Porta, M. Schwartz, The multi stream protocol: a highly ¯exible high-speed transport protocol, IEEE J. Select. Areas

Commun. 11 (1993).

[37] A. Mester, H. Krumm, Composition and re®nement mapping based construction of distributed applications, in: U.H. Engberg,

K.G. Larsen, A. Skou (Eds.), Proceedings of the TACAS'95, BRICS Notes Series, vol. NS-95-2, 1995, pp. 290±303.

[38] A. Mester, H. Krumm, Formal behavioural patterns for the tool-assisted design of distributed applications, in: H. K�onig,

K. Geihs, T. Preuû (Eds.), Proceedings of the DAIS 97, Chapman & Hall, London, 1997, pp. 235±248.

[39] S. O'Malley, L. Peterson, A dynamic network architecture, ACM Trans. Comp. Sys. 10 (1992) 110±143.

[40] S. Owre, J. Rushby, N. Shankar, F. von Henke, Formal veri®cation for fault-tolerant architectures: Prolegomena to the design of

PVS, IEEE Trans. Soft. Eng. 21 (1995) 107±125.

[41] T. Plagemann, A framework for dynamic protocol con®guration, Eur. Trans. Telecomm. 10 (1999) 263±273.

[42] A.S. Tanenbaum, Computer Networks, Prentice-Hall, Englewood Cli�s, NJ, 1996.

[43] C.A. Vissers, G. Scollo, M. van Sinderen, Architecture and speci®cation style in formal descriptions of distributed systems, in:

S. Agarwal, K. Sabnani (Eds.), Proceedings of the PSTV VIII, Elsevier, Amsterdam, 1988, pp. 189±204.

[44] XTP Transport Protocol Speci®cation, Revision 4.0, XTP Forum, Santa Barbara, 1995.

[45] M. Zitterbart, B. Stiller, A. Tantawy, A model for ¯exible high-performance communication subsystems, IEEE J. Select. Areas

Commun. 11 (1993) 507±518.

Peter Herrmann studied Computer Science at the University of Karlsruhe (diploma in 1990). Since then heworks as a researcher in the Computer Networks and Distributed Systems Group of the Computer ScienceDepartment at the University of Dortmund (Ph.D. in 1997). His research interests include the formal-baseddevelopment of distributed as well as continuous-discrete technical systems. Moreover, he is interested insecurity aspects of component-structured distributed software.


Heiko Krumm studied Computer Science at the University of Karlsruhe (diploma in 1978, Ph.D. in 1984). Heworked in the Institute of Telematics of Karlsruhe University in the ®eld of formal speci®cation, im-plementation, and veri®cation of communication systems. Since 1990, he is professor for Computer Networksand Distributed Systems at the University of Dortmund. Additional research interests include architectures,platforms, and design assistance for distributed applications. Moreover, current work concerns the automatedmanagement and security issues of distributed systems.


A framework for modeling transfer protocols

Documents

Transcript of A framework for modeling transfer protocols