To save content items to your account,
please confirm that you agree to abide by our usage policies.
If this is the first time you use this feature, you will be asked to authorise Cambridge Core to connect with your account.
Find out more about saving content to .
To save content items to your Kindle, first ensure no-reply@cambridge.org
is added to your Approved Personal Document E-mail List under your Personal Document Settings
on the Manage Your Content and Devices page of your Amazon account. Then enter the ‘name’ part
of your Kindle email address below.
Find out more about saving to your Kindle.
Note you can select to save to either the @free.kindle.com or @kindle.com variations.
‘@free.kindle.com’ emails are free but can only be saved to your device when it is connected to wi-fi.
‘@kindle.com’ emails can be delivered even when you are not connected to wi-fi, but note that service fees apply.
An important reason why formal description techniques are not appreciated as widely as wished by the developers of such techniques, is that people who actually design and implement software have relatively little knowledge of formal methods. The acceptance of formal techniques not only depends on the existence of techniques that are easy to understand and easy to use, but also on the training of potential users. This implies that there is a need for text books and case-studies. We think that a collection of formal specifications in a restricted area of application may help to get a better understanding of the use of formal techniques. Although the method we use is well suited for formal verification, we concentrate on the act of specification. A first requirement for a formal correctness proof is a formal specification.
We restrict ourselves in this book to a collection of specifications concerning one application area, the field of communication protocols. Although this seems to be an area with a relatively high acceptance of formal techniques, most of the protocols that are actually in use are specified in natural language, if ever specified otherwise than by the actual implementation. Even well-known and accepted standards, such as the token ring protocol, do not have a rigorous formal definition. Informal specifications in this area may lead to misinterpretations and, thus, to different implementations that will not be able to work together. Formal techniques are especially needed for communication protocol design, since these protocols describe distributed systems which have a high degree of non-determinism.
Sliding Window Protocols are used to provide reliable data communication between two computers in a network environment. A Sliding Window Protocol is connection oriented: a logical connection between the computers is established before data are transferred. Establishing a connection is not part of a Sliding Window Protocol. The connection is supposed to be a point-to-point connection without an intermediate network station. Sliding Window Protocols are situated in the Data Link Layer of the ISO OSI layer model.
In Tanenbaum ([Tan89]) three Sliding Window Protocols are presented. In this chapter a formal specification of these protocols is given. In the remainder of this section we give a general and informal description of a Sliding Window Protocol. In sections 4.2 to 4.4 the different Sliding Window Protocols are introduced and specified in PSF. The communication between Host processes and a Sliding Window Protocol is specified in section 4.5.
GENERAL DESCRIPTION OF A SLIDING WINDOW PROTOCOL
A Sliding Window Protocol (SWP) manages the communication on a point-to-point connection between two computers in a network at the Data Link Layer level in the OSI terminology. A SWP is a full-duplex protocol. This means that data can be transmitted simultaneously from station <I>A to station <I>B and vice versa. On both sides a SWP process is active, taking care of correct transmission. A SWP process contains a sending and a receiving part, managing outgoing and incoming data respectively. As we shall see in the sequel, these parts are not fully separated.
The specifications in this book are the result of a number of case studies performed by researchers from the Programming Research Group at the University of Amsterdam. The primary goal was to study the use of the techniques developed by the Programming Research Group for the specification of real-life protocols. From the pool of available case studies we made a selection that focuses on communication protocols, which we present in an order well suited for use in education. We hope that this book provides a first step towards a methodology for the design of communication protocols using PSF.
The following people have contributed to this book: Jacob Brunekreef, Henrik Jacobsson, Sjouke Mauw, Gert Veltink and Jos van Wamel.
Other people have helped in initiating and creating this book. The editors would like to express their gratitude for their help in various ways to Jan Bergstra, Jacob Brunekreef, Bob Diertens, Casper Dik, Hans Kamps, Hans Mulder and Jos van Wamel.
In this chapter we will focus on the specification language used throughout this book: PSF (Process Specification Formalism). We will discuss the mathematical origins of PSF as well as its syntax and semantics. The language itself will be clarified by using a running example, which gets more complicated as new language features are introduced. Apart from giving specifications in PSF we will also describe the implementations that make up the so-called PSF-Toolkit, such as the term rewriting system and the simulator.
The PSF-Toolkit also embodies a collection of frequently used specifications in the form of the PSF standard library. In this chapter we will explain which modules are part of the library and how they can be used. A full listing of the relevant modules from the PSF standard library can be found in Appendix A.
ACP
Before we turn our attention to PSF, we will give some information on ACP (Algebra of Communicating Processes). ACP is the theoretical foundation for the process part of PSF, and deserves some explanation as such.
The development of ACP was started in 1982 by J.A. Bergstra and J.W. Klop, at the Centre for Mathematics and Computer Science in Amsterdam. Compared with other concurrency theories like CCS, CSP and Petri Nets, ACP is most closely allied to CCS. The main difference between ACP and the other approaches is the way in which the semantics is treated.
Most formalisms, like CCS, CSP and Petri Nets are based on one specific model of concurrency. ACP, however, is a theory based on algebraic methods. The theory is defined by a set of axioms.
In this chapter specifications of three simple protocols are given in the formalism of PSF. The main goal is to make the reader familiar with the way the formal description technique PSF can be used for the specification of communication protocols. For this reason we specify protocols which are, in technical terms, not hard to understand.
The communication protocols specified in this chapter are the Alternating Bit Protocol (ABP), the Positive Acknowledgement with Retransmission Protocol (PAR-Protocol), and the Concurrent Alternating Bit Protocol (CABP), which is a more complicated version of the ABP.
The three protocols have in common that they follow a simplex scheme, which means that there is only one sender and one receiver and that the data flows in one direction. Moreover, the protocols handle just one data element at a time. These two restrictions make the protocols behave externally as one-element buffers.
The simple protocols considered have an interesting history in the theories of concurrency. Many different specifications and verifications can be found in the literature. Our specifications of the simple protocols are based on existing specifications in ACP that were made for mathematical analysis.
The ABP as specified in this chapter has been verified algebraically in the formalism of ACP. The PAR-Protocol has also been specified and verified by means of ACP but a special operator was needed to specify some restrictions on the communication between the timer process and the sender process: the priority operator. We present a version without priorities which is very similar to this specification. This is because priorities cannot be specified in PSF.
When describing the behaviour of a real-time process, we may wish to include instantaneous observable events that are not synchronisations. These signals may make it easier to describe and analyse certain aspects of behaviour, providing useful reference points in a history of the system. For example, an audible bell might form part of the user interface to a telephone network, even though the bell may ring without the cooperation of the user. This is incompatible with our existing view of communication.
In some cases, suitable environmental assumptions will allow us to describe such behaviour within the existing timed failures model. However, if we intend that these signals should be used to trigger other events or behaviours, then we must extend our semantic model to include an element of broadcast communication: some output events may occur without the cooperation of the environment.
In our model, signal events will occur as soon as they become available, and will propagate through parallel combination. A process may ignore any signal â performed by another process, unless it is waiting to perform the corresponding synchronisation a. If this is the case, then both â and a will occur. Of these, only the signal will be observed outside the parallel combination; it makes no sense to propagate a synchronisation.
As computing devices become faster and more powerful, we find ourselves increasingly dependent upon systems which are difficult to understand and prone to failure. The failure of a commercial banking system or a company database may be expensive and inconvenient. The failure of an aircraft control system or a railway signalling network may result in injury or death. As the consequences of system failure become ever more severe, we must find ways to make these applications of computing technology safer and more reliable.
Over the past twenty-five years, mathematical techniques have been developed for the specification and implementation of computing systems. Formal methods have been used in the design and analysis of transformational systems—in which results are computed from a given set of inputs—and have been shown to reduce design costs and improve reliability. However, many of the systems in which safety is a primary concern are real-time systems, and cannot easily be viewed in a transformational setting.
Real-time systems maintain a continuous interaction with their environment and are often subject to complex timing constraints. They may also be required to perform several tasks concurrently. To reason about such systems we require a mathematical formalism that supports a treatment of timed concurrency. In this thesis we explore and extend one such formalism, the theory of Communicating Sequential Processes, first introduced by Hoare (1985).
A wide variety of formal methods have been proposed for the specification and development of real-time systems, based upon process algebras, temporal logics, and timed programming languages. Although much research has been carried out, a consensus has yet to emerge concerning the applicability of the various formalisms to different types of system. A successful development method is likely to involve some combination of the features mentioned above. A notation that is well-suited to requirements capture is unlikely to be an efficient programming language, and vice versa.
Quantitative Temporal Logics
Hooman and Widom (1989) present a compositional proof system relating an occam-like language to a quantitative temporal logic, similar to the one developed by Koymans and de Roever (1983). Although the system description language is somewhat limited, it is clear that quantitative temporal logics are useful assertion languages; Jackson (1990) shows how such a logic may be employed as a specification language for timed CSP. It would be interesting to see the proof system applied in the development of a large, complex system.
Shasha et al. (1983) use a quantitative temporal logic to prove the correctness of a carrier-sense broadcast protocol, similar to the one described in chapter seven. By assuming a simplified version of the service provided by the physical layer, and an internal specification of the data link layer, the authors are able to establish that certain desirable properties hold of the network.
If we wish to produce a readable specification of a large system, then we must take care to present our description in a clear, structured fashion. At each level of abstraction, we identify the interfaces between system components and conceal any events which are not of interest. We express our specification as a series of service specifications, each describing the service provided by a particular component of the system. In this way, we may refine a description of the service provided by a system towards a satisfactory implementation.
The hiding operator provides the mechanism for abstraction in timed CSP; the expression P\ A denotes a process that behaves as P, except that
events from A occur as soon as they become available
only events from outside A are observed
In section 5.2.8 we gave an inference rule for this operator that was easy to derive, but difficult to apply. We can achieve a significant reduction in complexity if we separate the concerns of concealment and scheduling. To this end, we define a predicate actA which holds of any A-active behaviour:
Definition 6.1 actA(s, X) ≙ [0, end(s, X)) × A ⊆ X
A behaviour (s, X) is A-active if all events from set A occur as soon as they become available. If we wish to establish that P\A satisfies a specification S(s, X), it is sufficient to show that
S(s, X) holds for all of the A-active behaviours of P
S(s, X) is unaffected by the concealment of events from A
The second condition is satisfied if the truth of the specification is unaffected by the removal of A's events from the trace and refusal.