Carl A. Sunshine, Schemes and Mind Maps of Network Technologies and TCP/IP

Download Carl A. Sunshine and more Schemes and Mind Maps Network Technologies and TCP/IP in PDF only on Docsity!

AD A098 577 UNIVERSITY FORMAL MODELI OF (^) NGSOUTHERN OF COMMUNICATION CALIFORNIA^ PROTMARINA OC OLS.IU)^ DEL^ RET^ INFO--ETC^ FIG^ 17/ MAR a8I C A SUNSHINE DAHCIS^ 72-C-03R& ll.CAqlFlFD ISI/RR-81-89 NL

IIIIIIIR

S1.5 I zIIIIH~1.

MICROCOPY RESOLUTION TEST^ CHART NAhONAL RUP[AU^ Of^ STANVARD^ lq61A

UNCLASSIFIED

SECURITY CLASSIFICATION OF THIS5 PAGE (When Date Entered) __________________ REPORT DOCUMENTATION PAGE (^) BEOECMLEIGFR ORT NUI~tSER 2.GovTCCSONO.. RECIPIENT'S CATALOG NUMBER J/J ISI/RR-81-89 -^ y IT, (and I"4tw:l.; 5._3YPE QF REPOAT &PCX= COVERED (7 Formal Modeling of Communication (^) Protocols, () (^) Research k-

6. P~f n"4*. **8R"O&X-KUM32ER

7. AUTHOR() $**^ ON^ TACT^ OR^ GRANT^ NLIMBER(s) 1)Carl A./Sunshine DH1-2C0P

.79. PERFORMING ORGANIZATION NAME^ AND^ ADDRESS^ 10.^ PROGRAM^ ELEMENT.^ PROJECT,^ TASK USC/Information Sciences Institute

4676 Admiralty Way

Marina del Rey, CA 90291 _____________

11. CONTROLLING OFFICE^ NAME^ AND^ ADDRESS^ 12.^ "EPONT^ DATE Defense Advanced Research Projects Agency^ //^ Mardh^^1981 1400 Wilson Blvd.^ JIS.^ NUMBER^ OP^ PAGES

Arlington, VA 22209 30

14- MONITORING AGENCY NAME^ &^ ADDRESS(Il^ different^ froon^ Controlling^ 0Office)^ IS.^ SECURITY^ CLASS.^ (of^ this^ rsport) ------- (^) Unclassified ISa. DECLASSIFICATION0 SCHEDULE DONRADING

IS. DISTRIBUTION STATEMENT (of this Report) This document is approved for^ public^ release^ and^ sale; distribution is unlimited..-

17. DISTRIBUTION STATEMENT (of the abstract entered In Block 20, It different from,^ Report) 19. KEY WORDS^ (Continue^ on^ reverse^ stde^ It^ necessary^ and^ Identify^ by^ block^ nsinmber) abstract machine, protocol, specification, state exploration, symbolic execution, temporal logic, verification 20. ABSTRACT (Continue on reverse aide It necessay and identify by block^ nuiier)

DD 1 (^1473) EDITION OF I NOV 65 15OBSOLETE UNCLASSIFIED (^) ~6 ~. S/N 102-14601SECURITY CLASSIPICATION OF*^ THIS^ PAGE^ (Wea^ Date^ bweed

UNCLASSIFIED

SRCURITY CLASSIFICATION OF THIS PAGE(Wh U Data EnteM4)

Interest in more rigorous definition and^ analysis^ of^ communication^ protocols is increasing. This report surveys the^ current^ state^ of^ the^ art^ in^ protocol specification and verification. Methods for^ specification^ such^ as^ abstract machines, Petri nets, formal languages, abstract data^ types,^ and^ programs^ are described and compared. Verification methods including^ state^ exploration, symbolic execution, structural induction, and program proof are^ discussed. Work is progressing rapidly in many^ of^ these^ areas,^ and^ no^ clearly^ superior method has^ emerged^ yet.^ At^ least^ in^ the^ area^ of^ specification,^ some^ of^ these methods are ready for use by a wider community of protocol designers and

users

Avaession ~~

NTIS GPIel

DTIC TAB

Unannounlced

ID J S t (^) ifi aic:-.

Justri ficot I -

Dist :

UNCLASSIFIED SECURITY CLASSIFICATION OF Th4S^ PAGIK(Whe^ De^ BM

(t

 - 1. INTRODUCTION CONTENTS - 2. MEANING OF SPECIFICATION AND VERIFICATION - 3. SPECIFICATION METHODS.................................................... - Finite State Automata......................................................... - Abstract Machine Model - FormaiLlanguages........................................................... 

• *1Sequencing Expressions - PetriNoes................................................................. - Buffer Histories............................................................. - Abstract Data Types - Programs and Program Assertions..............................................
• *4. VERIFICATION - State Exploration - Symbolic Execution.......................................................... - Structural Induction - Program Verification......................................................... - Design Rules............................................................... - 5. CONCLUSIONS............................................................. - REFERENCES..............................................................

Iv

FIGURES

Figure 2.1. User view of protocol layer ...................................... I Figure 2.2. Internal structure of protocol layer ...........................................^2 Figure 3.1. Finite State Automata for connection establishment ............................ 5 Figure 3.2. Protocol service in Special ..................................................^7 Figure 3.3. Alternating bit protocol in formal grammar ....................................^8 Figure 3.4. CCITT X.25 as protocol sequence expression ..................................^10 Figure 3.5. Alternating bit protocol as a Petri Net (^) ......................................... 11 Figure 3.6. Protocol service in Gypsy ................................................... 12 Figure 3.7. Protocol service in AFFIRM ................................................. 14 Figure 3.8. Alternating bit protocol in state deltas ........................................ 17

2 FORMAL MODELING OF COMMUNJIICATION4 (^) VROTOCO1.S

This description of the input/output behavior of the protocol layer constitutes a service specification of the protocol. It should be "abstract" in the sense that it describes the types of commands and their effects, but leaves open the exact format and mechanisms for conveying them (e.g., procedure calls, system calls, interrupts).

Although the internal structure of a protocol layer is irrelevant (^) to the user, the protocol designer must be concerned with it. Ina network environment with physically separated users, a protocol layer must be implemented in a distributed fashion, with entities (processes or modules) local to each user communicating among one another via the services of the lower layer (see Fig. 2.2). These entities may be considered "black boxes" in their own right, and the rules by which they interact with each other (and their users) to provide the layer's service constitutes the actual protocol. Hence a protocol specification must describe the operation of each entity within a layer in response to commands from its users, messages from the other entities (via the lower layer service), and internally initiated actions (e.g., timeouts).

USER USER

ENTITY I^ ENTITY

LOWER nLAYER

Figure 2.2. Internal structure of protocol layer

A protocol specification isa refinement or distributed "implementation" of its service specification in the sense that it partly defines how the service is provided (i.e., by a set of cooperating entities). This "implementation" of the service is what is usually meant by the design Of a Protocol layer. The protocol specification should define each entity to the degree necessary to ensure compatibility with the other entities of the layer, but no further. Each entity remains to be implemented in the more conventional sense of that term, typically by coding ina particular programming language.

MEANING OF SPECIFICATION AND VERIFICATION 3

Verification is essentially a demonstration that an object meets its specifications. From the above

discussion, we see that the service and the protocol are the two major items requiring specification

for a protocol layer. Hence there are two basic verification problems that must be addressed: (1) the

protocol's design must be verified by analyzing the possible interactions of the entities of the layer,

each functioning according to its (abstract) protocol specification and communicating through the

underlying layer's service, to see whether this combined operation satisfies the layer's service

specification; and (2) the implementation of each protocol entity must be verified against its abstract

protocol specification.

The term "protocol verification" is usually intended to mean this first design verification problem.

Because protocols are inherently systems of concurrent independent entities interacting via (possibly

unreliable) exchange of messages, verification of protocol designs takes on a characteristic

communication- oriented flavor. Implementation of each entity, on the other hand, is usually done by

"ordinary" programming techniques, and hence represents a more common (but by no means trivial)

program verification problem that has received less attention from protocol verifiers.

It is only recently that the need for complete service specifications has been realized. Hence much

of the work to date has attempted to verify plausible but rather ad hoc sets of properties. There are

also a set of desirable properties common to most protocols (and other systems) including:

*Freedom from deadlock, or arrival at some desired final state(s);

*Completeness of the protocol in handling all situations that may arise during execution;

*Progress, or the absence of cycles where no "useful " work is done;

*Stability, meaning that the protocol will return to a "normal" mode of operation after an

abnormal condition occurs.

These properties may be viewed as implicit requirements on any protocol, and may be verified in

the ibuence of ant explicit service specification.

3. SPECIFICATION METHODS

Protocol specification methods have traditionally developed from two viewpoints: state machines

and programs. As we shall see, there is really no fundamental difference between these approachf:%i

and a variety of elaborations that span the gap between them have been proposed. But these two

categories still provide a useful starting point for discussion.

Program specifications are motivated by the observation that protocols are merely a particular

class of information processing procedures, and that various programming languages provide a

convenient means for describing such procedures. Because they typically involve multiple

concurrent processes, protocols do present some special challenges, but programming languages

catering to^ such^ problems^ have^ been^ developed.

SPECIFICATION METHODS 5

Idle Oe

~Open

Send I NIT Receive INIT Send (^) INIT Wait

Receive INIT

Establi shed

Figure 3.1. Finite State Automaton for connection establishment

message and/or sequence number in a pure FSA model. Hence extension of the model to include a number of^ different^ type state^ variables becomes^ desirable,^ as^ discussed^ next.

Abstract Machine Model We shall use the term abstract machine to represent the extension of an FSA obtained^ by^ allowing multiple state variables of various types. The major difference is that the "state" now becomes a vector of these variables, and the transition functions giving the next state and the output become correspondingly more complex. If the data types of the state variables are unbounded (e.g., a queue), the model may not even have a finite number of states.

An abstract machine model for a protocol often has a distinguished state^ variable^ (called^ "the state") which still serves to identify the major phases of the protocol. In these cases, the same graphical model as for FSA^ may be^ used,^ with^ circles^ representing^ the^ major states,^ and^ arcs^ the transitions between states. Each arc is labeled with the event causing the transition (which typically includes conditions on the^ rest^ of^ the^ state^ vector^ and^ any^ parameters of^ the event),^ with^ outputs produced, and with any changes to the rest of the state vector. The tabular specification must be similarly augmented.

Many people have proposed particular forms of such^ abstract^ machine^ models^ for^ specifying protocols [LeMo 73, Boch 78, DaBr 78, SuDa 78, Piat8O, Tenn80, Dick 80, and SDCo 80]. While differing in details of syntax, the proposals may be considered^ equivalent^ in^ their^ basic^ intention.

a -_ ____ ____ ____ ____

6 FORMAL MODELING OF COMMUNICATION PROTOCOLS

A useful elaboration appearing in several methods is the ability to define "submachines" which give the details of operation within what appears as a single "compound" state of a higher level machine [SDCo 80]. Entry into the parent level's compound state causes activation of the appropriate submachine at its initial state, and any inputs not handled at the parent level are passed to the submachine. Exit from the parent state terminates the submachine no matter which substate it is in. This corresponds roughly to the subroutine notion in programming, (^) and has been called "hierarchical dependence" by [Boch 78].

Two formal specification languages have been developed expressly for defining such abstract machines: Special [RLSi 79] and Ina Jo [Loca 80]. Special is based on the work of Parnas [Parn 72] where the state is represented by a set of value-returning functions (Vfunctions), and the commands by a set of state- modifying functions (Ofunctions) which set the values subsequently returned by some Vfunctions. The Ofunctions may also have a test for exception conditions (^) which cause an error return instead of their normal effects. In Special, there is no explicit output produced, but some of the Vfunctions are meant to be "observable" to the users, while others are not visible to the users (^) and represent (^) purely internal state information.

The state variables in Special may include basic types such as integer, record, sequence, set, and boolean, and also user-defined types that are defined independently (^) as other abstract machines. The effects section of Ofunctions may then call on the Ofunctions (^) of the more primitive types. The Ofunctions may also include delay until constructs (^) which cause an operation to wait until the specified property of the state is true before it is (^) effected. A service specification for a simple sing!e- message-at-a-time data transfer (^) protocol is given in Figure 3.2.

In Ina Jo, the state is defined directly as a number of variables of different types, although there is no facility for using separately de&;ned machines as additional types. The effects of commands are given in transforms which specify the new values of any changed state variables as a function of (^) their old values and the parameters of the command. Ina Jo also allows the specification of properties that must be maintained by the transforms, but further consideration of these is postponed until (^) our discussion of verification.

A difficulty with abstract machine models stems from their purely passive nature: they define the effects of operations which are invoked, but do not (^) include any notion of an active agent which may cause events or invoke operations on its own initiative. For example, the effects of a Retransmit operation may be defined, but not the fact that the operation is to be invoked whenever a certain time elapses. This shortcoming may be partially avoided by interpreting some events as "external" or callable by a user of the machine, and other events as "internal" or called by some sort of daemon process associated with the protocol machine itself. Understandably, this problem is more serious when the issue is liveness rather than safety.

8 FORMAL MODELING OF COMMUNICATION PROTOCOLS

to terminal symbols. For each transition from state S to state T with input i and output o (which may be null), we add a production to the grammar, S:: = ioT. The initial state (^) of the machine becomes the starting symbol of the grammar. Figure 3.3 shows an example of this type of specification (^) for the "Alternating Bit" protocol. Of course it is possible to simplify the resulting grammar (^) by substituting later productions for the nonterminals in earlier (^) productions, thereby making the omitted states implicit in the succession of terminal symbols.

SO::= CO CO::= SendO WO WO::= ReceiveAckl S1 SO::= ReceiveMsgO (^) Al ReceiveAckO CO Receivesgl AO Timeout CO (^) ReceivetsgError AO AO::= SendAckO SO S::= (^) C Cl::= Sendi W1 Si::- ReceiveMsgl (^) AO Wl::= ReceiveAckO SO ReceiveMsgO (^) Al ReceiveAckl C1 ReceiveMsgError (^) Al Timeout Cl (^) Al::= SendAckl S

(a) Sender (b) Receiver

Figure 3.3. Alternating bit protocol in formal grammar

One disadvantage of formal grammar models is apparent from the (^) example. They do not distinguish between inputs and outputs (although (^) the names of the symbols may be chosen to informally indicate this). The (^) usual interpretation of grammars as defining either a recognizer for the language or a producer makes it difficult to view them as both (recognizer of inputs and producer of outputs) as necessary for protocols.

Formal language models suffer from the same limitations as FSA in representing the (^) text of messages or the values of sequence numbers. An indexing (^) scheme for defining groups of productions parameterized by a sequence number has been proposed (^) by Harangozo [Hara 77]. While maintaining a compact notation. this effectively multiplies (^) the number of productions (or states).

An advantage of grammars is that the same formalism may be used to represent the format of messages exchanged. Thus there may be an "action grammar" for the allowed sequences of events, and a "message grammar" for the format of fields in each event [TeLi 78]. The productions of the latter may be substituted for (^) the terminals of the former, yielding a more detailed description of the interactions.

SPECIFICATION METHOOS 9

Sequencing Expressions Sequencing expressions are an attempt to specify the sequence of protocol operations directly. The basic operators for building up such expressions are repetition, follows, and alternatives. A simple form are the well-known regular expressions that correspond to FSA (and type 3 formal grammars). As with grammars, there is no formal distinction between inputs and outputs in the sequencing expressions (but naming conventions may be used). However, there is no longer any explicit state that must be invented and specified. Instead, the current location in the expression is an implicit state.

Schindler has proposed a number of extensions to facilitate protocol specification [Schi 80]. The overall expression may be broken into several blocks, each block functioning much as a nonterminal in a grammar. Each term in the expression may have a rejection predicate which causes an otherwise allowed operation to be deemed invalid if false. These predicates may refer to the parameter values of the current and previous operations and to the number of operations of a given type previously executed (successfully).

Each block may also have several exit blocks specified, so that an operation that does not match within the currently active block may match (and cause entry to) an exit block. These are intended to specify the handling of "abnormal" events such^ as^ a^ Disconnect^ during^ data^ transfer.^ Thus,^ the^ exit block construct serves to define an alternative which "distributes over" all the items in the current block. Operations that do not match the current pointer or any exit blocks are "rejected" or ignored with no effect on the system.

An example (taken (^) from [Schi 80]) of this type specification for the X.25 Level 3 protocol is given in Figure 3.4. Note that only part of the data transfer constraints are represented in the sequencing expression here (DIT block), which must be augmented by an abstract machine type specification for the data transfer operations (not shown here for brevity). The complete constraints could be captured in the sequencing expressions, but we have chosen the simpler example for ease of understanding. Thus the explicit state machine and sequence expression methods can be mixed in whatever proportion seems clearest.

The original work by Schindler on sequencing expressions focused on the interactions between protocol entities and omitted user input/output (from/to the level above). Reference [SFAI 80] describes recent extensions to include user interfaces, with particular emphasis on service specifications. Bochmann has also proposed a sequence notation for specifying protocol services [Boch 80].

SPECIFICATION METHODS 11

SENDER LINK RECEIVER

I II

I I I

I I A M I

I I

L

(^16 24 )

Figu re 3.5. Alternating bit protocol as a Petri Net

'Pure" Petri nets suffer most of the same limitations as FSA, although they can represent an unbounded number of tokens (e.g., messages in transit). Hence a variety of (^) extensions to Petri nets, such as inhibitor arcs, typed tokens, and state variables (or a separate "data (^) graph"), have been proposed by various authors [Kell 76, GoMa 76, AABe 78, Symo 80, RaEs 80]. Petri nets extended in this fashion have an expressive power similar to abstract machines. It issomewhat easier to combine Petri nets into composite systems by identifying the input places of one net with the outputs of another. Since multiple control tokens are allowed in Petri nets. the result is a single Petri net with concurrently executing subparts.

Another extension not usually found in abstract machines is the addition of timing constraints to

the transitions. These may be necessary to rule out undesirable behavior in some cases [MeFa 761.

amI r26 15 -: -- : - 2 1 -i il a lll I I

12 FORMAL MODELING OF COMMUNICATION PROTOCOLS

Buffer Histories

Buffer histories are similar (^) to formal languages and sequence expressions in their attempt to define the input/output behavior of (^) the system without any mention of explicit states. The basic model is a process or active computing entity that has a set of buffers through which it (^) exchanges items of specified types with the outside world. Several processes may be connected by these buffers. The major component of the specifications are relations (^) between the items read from and written to different buffers by (^) different processes.

The division of (^) the interaction history into separate histories for each buffer is sometimes an advantage (e.g., in stating that the output bears some relation to the (^) input), and sometimes a disadvantage because the relative ordering (^) of items in different buffers must be considered (e.g., whether a Send request in a message data buffer is preceded by a (^) Connect request in a call control buffer). In the latter case, some sort of time (^) stamps must also be associated with the items to allow a relative (^) ordering. Of course both the time stamps and the buffer histories are specification constructs, and need not appear in any implementation.

The major development of this type of specification has been in the Gypsy system [GoCo (^) 78]. This system caters to cyclic processes in whikh the buffer relations (^) are specified to hold at blockage points when a process tries to read from an empty buffer or write (^) to a full one. An example Gypsy specification for a simple data transfer service is given in Figure (^) 3.6.

BEGIN

TYPE msg

PROCEDURE Protoco1Service (Sent: INPUT (^) BUFFER[1) OF msg, Delivered: OUTPUT BUFFER[O] OF msg) BEGIN BLOCK ALLFROM(Sent) = ALLTO(Delivered) END

END

Figure 3.6. Protocol service in Gypsy

Other workers have also made use of similar event histories in their specifications, notably Hailpem [HaOw 801 and Luckham and Karp [LuKa 79]. In these cases, the histories may be of more general events or actions performed, and need not correspond to items actually (^) placed in buffers.