Protocol visualization in Estelle

Computer Networks and ISDN Systems 25 (1993) 741-760 North-Holland

741

Protocol visualization in Estelle Paul D. A m e r * and Darren N e w Department of Computer and Information Sciences, University of Delaware, Newark, DE 19716, USA

Abstract Amer, P.D. and D. New, Protocol visualization in Estelle, Computer Networks and ISDN Systems 25 (1993) 741-760.

Protocol visualization is introduced as a new field of research within the realm of computer communication protocol engineering. A workstation tool is designed, implemented, and analyzed for the Graphical Representation Of Protocols in Estelle (GROPE), an ISO international standard formal description technique for specifying computer communication protocols. GROPE's protocol visualization approach provides a dynamic, graphical representation of a simulated Estelle protocol specification, pictorially representing its architecture and finite state machines. GROPE animates the firing of Estelle transitions and the exchange of interactions over channels. For visually complex Estelle specifications, GROPE provides several user-controlled mechanisms for simplifying both the architecture and extended finite state machine behavior. Design issues both for GROPE and for protocol visualization tools in general are presented.

Keywords: Estelle; formal description technique; FDT; ISO; protocol specification; visualization.

I. Introduction

As a result of technological improvements in personal workstations, networking and computer graphics, the field of scientific visualization is rapidly advancing. Scientific visualization conferences bring together scientists in a variety of domains; over 100 areas of scientific research now use graphics to better understand inherent forces and relationships [27]. This paper introduces protocol visualization as a new field of research within the realm of computer communication protocol engineering. A workstation tool is designed, implemented, and analyzed for the Graphical Representation Of Protocols in Estelle (GROPE), an ISO international standard formal description technique for specifying computer communication protocols. To avoid ambiguities inherent in natural lan-

Correspondence to: P.D. Amer, Computer and Information Science Department, 103 Smith Hall, University of Delaware, Newark, DE 19716, USA. * This work supported, in part, by the US Army Research Office and the US Army Communication Electronics Command (CECOM), Ft. Monmouth, NJ.

guage specifications and to simplify the formal testing of specifications, ISO initiated research on the definition and standardization of formal languages for describing ISO computer communication services and protocols. It is assumed that the reader is familiar with the motivations behind the development of formal description techniques (FDTs). Several specialized international conferences (e.g., IFIP PSTV, FORTE, IWPTS) now focus specific attention on this topic. While some of Estelle's features are discussed in the context of presenting GROPE, it also is assumed that the reader is familiar with the Estelle ISO international standard [14]. Estelle tutorial information can be found in [2,9,30]. GROPE's protocol visualization approach provides a dynamic, graphical representation of a simulated Estelle protocol specification, pictorially representing its architecture and state machines. GROPE animates the firing of Estelle transitions and the exchange of interactions over channels. For visually complex Estelle specifications, GROPE provides several user-controlled mechanisms for abstracting the detail of both the architecture and extended finite state machine behavior.

0169-7552/93/$06.00 © 1993 - Elsevier Science Publishers B.V. All rights reserved

742

P.D. Amer, D. New / Protocol visualization

GROPE's initial design was proposed at IFIP PSTV'89 [20]. The first demonstration took place at FORTE'90 in Vancouver and version 1 with GROPE's basic protocol visualization features described was published in [21]. Currently, GROPE enjoys wide distribution to over fifty locations in fifteen countries. This paper summarizes GROPE's basic features and introduces several new ideas including complexity reduction techniques for visualizing large finite state machines. Section 2 defines and motivates the need for protocol visualization as a mechanism for protocol specification design, testing, and perhaps most importantly learning. It also summarizes other relevant Estelle tools. Section 3 presents GROPE's basic design and certain extensions introduced since [21]. Section 4 describes those extensions specific to fsm complexity reduction and Section 5 relates three practical experiences in using GROPE. Conclusions and proposed future work are provided in Section 6.

2. Motivation for protocol visualization and Estelle tools Why add dynamic representation to protocol specification? Most communication protocols are dynamic by their very nature. "Cause and effect" is the main theme of a communication protocol. The rules followed and the data exchanged are

merely mechanisms to assure that a given effect is achieved by a given cause. Learning the details of an inherently dynamic protocol through a static representation, such as a listing in an ISO document, although the traditional method, can be difficult especially for large, complex protocols. One technique which eases the understanding of a large protocol is simulation of its specification. Such "emulator" tools have been developed for example by the National Institute of Standards and Technology (NIST) [28], and BULL in France [3] (see also [7]). The dynamic presentation of information creates a temporal dimension in which cause-and-effect relationships are easier to detect due to the causal event being closely followed in time by the effect. In a static specification, such proximity is usually not present and cause-and-effect relationships are not evident.

2.1. Why add graphics and animation to protocol specification? While FDT emulator tools are a strong advance in protocol engineering, for cause-and-effect relationships to be best noticed and understood, simulation observers must not be swamped by unnecessary detail. Large amounts of information need be suppressed to focus an observer's attention on only the most pertinent activities. A typical Estelle specification contains a great deal of information, all of which is needed to fully specify a protocol. However, it also contains a

Paul D. Amer was born in New York in 1953. He received the B.S. degree summa cum laude in mathematics from the State University of New York at Albany in 1974, and the M.S. and Ph.D. degrees in computer and information science in 1976 and 1979, respectively, from The Ohio State University. Since 1979, he has been at the University of Delaware where currently he is professor of computer science. From 1978 to 1987, he was employed permanent part-time as a Research Computer Scientist for the National Bureau of Standards in Wash, DC. In 1985, he spent one year at the Agence de l'Informatique in Paris contributing to the development of Estelle as part of the ESPRIT Project SEDOS. He is currently on sabbatical (until Summer 1993) at the Laboratoire d'Automatique et d'Analyse des Syst~mes (LAAS du CNRS) in Toulouse investigating services and protocols that support multimedia applications. Professor Amer is on the Editorial Boards of Computer Networks and ISDN Systems, Computer Standards and Interfaces, and R~seaux et Informatique R~partie. Additional interests include Estelle specifications of ISO protocols and services; automatic test case generation; and semantic extensions to Estelle to handle broadcast channels, n-way synchronization, and real-time constraints. Darren New received a B.S. in computer science from West Chester University and a Ph.D. in computer

and information science from the University of Delaware. At Bellcore, he investigates network requirements for delivering interactive multimedia information. Before that, he investigated the graphical presentation of formal descriptions of network protocols. Darren is a member of the Association for Computing Machinery and the Electronic Frontier Foundation.

P.D. Arner, D. New / Protocol visualization

great deal of extra information that enhances readability (e.g., comments) and allows for such necessities as strict type checking. A protocol visualization tool must allow simple access to various portions of a specification without encumbering a user with unwanted details about other portions. G R O P E uses animation and graphics to suppress unnecessary detail and allow varying user-controlled levels of abstraction. G R O P E provides a careful selection of animated visual cues for focusing a user's attention on the most important portion of a specification at the time it becomes important. G R O P E maintains animated, up-to-date graphics automatically as a visualization session progresses. A challenge of protocol visualization research is determining which specification aspects contribute most to the understanding of its temporal working and choosing effective graphical representations and animation sequences for them. The ability to use graphics to abstract information is important and helpful, as is the provision for a user to choose comfortably between variable levels of abstraction depending on the situation. G R O P E has provisions for hiding the internal details of a module, hiding individual transitions, clipping areas of a state machine that are currently less important, and replacing sets of states with macrostates. These abstraction capabilities are shown to be helpful for both novice and experienced expert users of a protocol specification. G R O P E ' s user actively chooses which details are visible and which are abstracted away thereby dynamically changing the presentation as understanding increases. Any visualization tool should take advantage of windows for output and a mouse and menus for input, concepts dating back to the late 1970's. Allowing a mouse to be used as an input device eliminates the need for complex naming schemes and complex selection mechanisms. A user simply points and clicks to select any visible object. Menus present all available operations without a user needing to remember what is available under what circumstances.

743

oped at NIST. Using the Cornell Synthesizer Generator [23], the NIST W I Z A R D editor provides structured editing of Estelle. Wizard converts Estelle into Smalltalk 1 [10,11] representations of the static specification. Another tool, WISE [28], interprets Wizard's output and allows any portion of a specification to be examined and controlled by a user during interpretation. WIZA R D and WISE provide complete support for all features of standard Estelle. Each of these NIST tools (as well as two others: the Portable Estelle Translator (PET) and the Distributed Implementation Generator (DINGO) [29]) provides debugging and other Estelle information in a textually oriented environment. Using text to assimilate a specification, even with a workstation's window environment, is difficult for users of a specification. For example, on a display, text cannot be made simpler; only smaller. G R O P E , however, provides a user interface to WISE's interpretation using graphics and animation rather than text. Other tools do not focus a user's attention on changes. For example, when interpreting a specification with WISE, while the contents of all variables and queues are accessible, a user must explicitly ask to see any values of variables and must ask again if those values change. Changes are not automatically brought to a user's attention; hence if the user does not already know that a particular variable is of significance at a particular time, the change may go unobserved.

3. Design issues

2.2. Related F D T tools

In Estelle, as in most state-machine-based formalisms, transitions are atomic. They take no time and reveal to their environment only the final results of their operation without revealing any intermediate results. This is desirable in a formalism as it allows simpler reasoning about a protocol's operation. However, in a protocol visualization tool, instantaneous changes are unacceptable. A user simply would see a single "blink" as the protocol moved from one state to another. Simply switching from one image to another with-

Many tools are available for working with Estelle specifications [3,16,17,18,24-26]. Of particular interest to G R O P E users are the tools devel-

1 Smalltalk is a registered trademark of ParcPlace Systems, Inc.

744

P.D. Amer, D. New / Protocol visualization

out displaying intermediate visual states is not as helpful as is animating the changes. In addition, the Estelle definition allows only one transition to fire at a time while at the same time defining the semantics of transition firing in a way that allows (and indeed encourages) implementors to fire multiple transitions simultaneously. In light of this, G R O P E animates a transition firing over a period of time rather than as a flash on the display. The user controls the speed of animation typically increasing the speed as understanding of the specification increases. Animating changes attracts and focuses a user's attention to changes in the current state of the simulation. These differences between Estelle's formalism and G R O P E ' s visualization of a simulated Estelle specification stem from the fact that Estelle has operational semantics (in contrast to L O T O S [13] denotational semantics). That is, a module's behavior is defined by a program-like sequence of statements. Each statement within an "atomic" transition makes some change to some formal memory-like structure. Hence, when trying to understand a protocol, the behavior is examined one statement at a time. The individual statements within a transition have a definite order of execution, even though at a higher formal level, the total effect of the entire sequence of statements within a single transition is considered atomic. Essentially, G R O P E introduces time into the middle of Estelle transitions for visualization purposes. The dynamic changes in the graphics for each statement that the interpreter executes are shown as the statements are executed, seemingly in defiance of the Estelle semantics. For example, multiple outputs to different external interaction points are shown in sequence, rather than being saved up for the end of the transition as the

formal semantics specify. If this were not the case, a user would have greater difficulty gaining insight into the complete operations performed by a single transition.

3.1. A user's view of GROPE To allow G R O P E to interface with a variety of tools, a visualization system built on G R O P E is divided into three parts: an interpreter which evaluates the Estelle specification, and a driver which intercepts important Estelle statements being executed by the interpreter and passes them to a graphical engine which draws images and handles user commands (see Fig. 1). The driver also is responsible for intercepting and passing on menu selections that G R O P E presents but which are implemented in the interpreter. At the University of Delaware, WISE is the supported interpreter and the driver is embedded in WISE as procedure calls to G R O P E . No other drivers are developed yet although several have been informally investigated. After an Estelle specification is loaded, G R O P E opens a window containing a graphical representation of the initialized specification architecture. The specification instance and all module instances are represented similarly, as rectangles with the specification or body name inside. If there is an attribute such as s y s t e m process, it is written in parentheses after the module's name. The rectangle border of a module follows the recommended graphics in [14] (see legend in Fig. 2), except when that instance is selected by the user, in which case the border temporarily becomes light gray. As an example, consider Fig. 3, is a "process or activity" module whereas At t e r n a t i n gBi t Ex a mp t e (the specification body) is a "system" module.

AlternatingBitrl]

'Estdl©

statements

Interpreter (WISE)

Graphical Engine

Fig. 1. Architecture of GROPE.

Men~ =

II

P.D. Amer, D. New / Protocol visualization

specificationlegend I

(inactiveenclosingmodule)

!

I

(systemmodule)

I

(process or activity) Fig. 2. M o d u l e instance b o r d e r legend.

C o m m o n queues, if they exist, are drawn as a "L3" icon next to the instance name, with dashes visually indicating the number of interactions in

745

the queue at any time: for example, " ~ " has three queued interactions. To focus a user's attention on changes in queue contents, all queues flash on and off momentarily whenever an interaction is inserted or removed. The duration and speed of flashing is user-controlled. G R O P E indicates temporary events such as a module with a firable transition to offer, with a " * " just before the name (for example, , A t t e rn a t i n g B i t I"1]). With a color monitor, these temporary events might be indicated by a different color. Any instance-specific messages can appear under the module name (see s a mp t e Me ss a g e inside A l t e r n a t i n g B i t [ 1 ] ) . Of course, there may be nested children instances, interaction points, and so on. Interaction points are labeled dots ( " e " ) possibly having an adjacent queue icon (" u "). If there

specificationAlternatlngBitExample(systemprooess)

U User[l] (prooess)

U User[2](process) U

¢

IU-,ooess-polnt U U*AlternatingBit[t] (process) SampleMessage

.I.I

U

¢

IU-aooess-polnt U Ill AlternatlngBit[2](process)

.L_I N-aocess-point

Network (prooess)

Fig. 3. A l t e r n a t i n g bit example: N e t w o r k o u t p u t s i n t e r a c t i o n to A l t e r n a t J n g B J t r q -l.

P.D. Amer, D. New / Protocol visualization

746

hlternatlngBlt[1] (process) trans2a

trans4

trans2b

transl

transSb Fig. 4. A s t a t e m a c h i n e in G R O P E

is a queue icon (for example, interaction point N in module instance A t t e r n a t 5 n g B i t I" 1 "1), then this interaction point is declared to have an individual queue. If there is no queue icon (for exam-

(E S T A B is the c u r r e n t state).

pie, interaction point u), then this interaction point is declared to use the common queue, and interactions arriving here are placed in the common queue near the module instance name. In-

Altern=tlngBit[2] (process) tr&n:2a

tranxS&

PJCI~IT

trans4 trans3 trans2b

tr~

trans5b Fig. 5. A s t a t e m a c h i n e in G R O P E ( t r a n s 1 is firing).

P.D. Amer, D. New / Protocol visuafization

ternal interaction points are placed away from the module's border, while external interaction points are placed on the borders. Channels are represented as a curve or straight line connecting two interaction points; for example, in Fig. 3, channels are labeled with s access-point and U - a c c e s s - p o i n t . A n interaction that is output over a channel is animated as a series of es traveling along the channel in a video game-like manner, the direction of movement indicating the direction of interaction flow. The speed of animation is user-controlled. Within each Estelle module instance lies an extended finite state machine (EFSM) describing its internal behavior. G R O P E represents each EFSM with labeled circles for states connected by arrows representing transitions. The current state is drawn in reverse video or a different color. Consider Fig. 4 with two states, seven transitions and ES TAB as the current state.

747

As discussed previously, G R O P E displays the results of firing a transition over a period of time to help a user to understand the body of a transition. G R O P E highlights the current transition being fired by a series of animated es that travel along the transition arrow in the same way an interaction is represented as es along a channel. Consider Fig. 5: the es on transition t r a n s l appear and remain until the interpreter has finished executing this Estelle transition, allowing the user sufficient time to observe any module instances that might be initialized or released and to see any interactions that might be consumed a n d / o r produced as the result of this transition's execution. Since the scope of a transition's changes are limited to a well-defined set of objects which are mutually exclusive of any objects that can be affected by another concurrent transition, a user can distinguish which animated changes result from which transitions firing.

spt¢ifi¢&tion AllernaltlngBitExtrnple (iyllempreoess)

I

U u~o,[q (p...... ) U

U

t ~ l t e r n a t i f l g B i t t l ] (proetss)

p

-|¢ctss-poh~l

-&co*st-point

Allern~tihqBit[2] (pvootss) ~ransGa

trtesZz

ra~sZa Iran;~a

t~mn¢4

trans4

lraaz3

tfansSb

tran~b

4-aoo~ss-peiet

UN[q H e l w o r k (process)

Fig. 6. Multiple state machines in the same window.

N-~©ocss-point

.[2111

P.D. Amer, D. New / Protocol visualization

748

All changes to GROPE's displays occur either due to the interpreter executing an Estelle statement as part of its simulation or due to a userselected menu operation. The available menu operations differ depending on the type of object selected, and may even differ between items of the same type if the interpreter so chooses. There are eight kinds of Estelle objects which are selectable: the specification instance, module instances, interaction points, channels, states, transitions, macrostates, and macrotransitions 2.

An object is selected by clicking the mouse button while the cursor is near that object. Once an object is selected, its menu of operations appears for the G R O P E user to select from. If a menu operation requires more information (for example, a file name), G R O P E prompts for that information separately. Error messages and status messages are posted to a System Transcript window, which is the standard place in Smalltalk for such messages to be displayed. This window roughly corresponds to s t d e r r in Unix. Given an Estelle specification for the first time, the choices made by G R O P E for the default graphical placement of objects such as module

2 T h e last two are not really E s t e l l e objects; m o r e on this in Section 4.

specification ntp

internetbody(system ' ~ r c imp[l]

Iml U hostbody[1](systema

] routerbody(act

imp[2]

imp[3]

Imp L~J

impU

LJ hostbody[3](systemact

U hostbody[2](systernact

internetb°dyI

,,

internetbody(systemactivity) peerip[1 ]

peer

peerip[2]

peer!

rc routerbod peerlp[3]

peer

•

•

consolebody[1] (syStl

console

Fig. 7. A n e w w i n d o w z o o m s in on a m o d u l e instance.

749

P.D. Amer, D. New / Protocol visualization

chines in the same window. It is also possible to open multiple windows on various modules to gain different perspectives of a specification. There are three ways to open a window from a menu in GROPE. One such operation opens an entirely new window. For example, in Fig. 7, i nt e r n e t b o d y was selected in the original window and then a new window was opened. This resulted in the smaller overlapping window "zooming in" or focusing only on 4nternetbody'S architecture. A second window operation completely replaces the current window with a new window

instances, states, and transitions are primitive. An assumption is made that the defaults are never the desired graphics, and therefore a user always wants to move them. G R O P E therefore provides a user with a simple initial guess and a capability of moving objects around to become more visually pleasing as long as graphical consistency (discussed later) is maintained.

3.2. Windows in GROPE As shown in Fig. 6, it is possible to view a specification's architecture and multiple state ma-

stationbody[A'l

(activity)reqcon

stationbody[A]

~

m

,dr ~ o t e d....... r2 ".t c(~,,-,-~,-,-~ ~ ccep

~u ~u~ ~ ~

J remoterejcon x. ~_~ ~ L ! ~cretrancr ~,- i ~ . ~

1

itrmdr lk "~'-'r'-i ''~l°caldisc°lif retr~nd~ . " ' reck°~lPI el~ted~c~ Xte>mcr i termretra n

i ,ocalrejcon

(3

" If ~

fIT[77 ;rem.ot.edI

_' lili t teaccept~ • ~ c c l o o d a c k

+\

"retrandr

\

/

/ remotedr~ stationbody[B]

(activity)reqcon

"eqcon~

• %

otedr2

rejcon ~~ ~ N,5, VI i I| °qa'reqc6"etrancr L ~ ~ .q~h,

I

\

!'

~/'retrancrl

crsent

~ , X

.,---r~o< ,IgL"~lt ]retr~nd~

ren~ttealsc • ~ c ~n : 1.termcr ~ termretran

~

o>

e °ted41 ' ~ sent LL~t., t~c -i ~~~W d~ ' ac -k ' I\ ermdr

..... ~

J

~-~

/

/

J....~ collidecr ~

I

Iocal.-on /'

,N

\ Iocalrejcon

/

i1~ "lI"

x

Iocalreqdis

\

~.

'

recbadack / ! termretran

/

~, , r+0,

/

retrandr l

i

i

i

l

l

~

f

f

!

~

~

~

H

l

~

!'

~ •

i

"

~

Fig. 8. Sample scrolling windows.

-

;

': ~'~i'q~i ~, I!iii

P.D. Amer, D. New / Protocol visualization

750

showing only the selected module. This conveniently allows a user to "step deeper into" a complex architecture one or more modules at a time without the visual complexity of extra windows. The final window operation provides one of G R O P E ' s complexity-reducing operations available to the user. It opens a scrolling window showing the finite state machine of the currently selected module. Unlike all of G R O P E ' s other windows, once a scrolling window is open, resizing it does not cause its contents to change size. Instead, shrinking the window causes the edges to be clipped. The window is called "scrolling" because during simulation G R O P E automatically scrolls to keep the current state or currently firing transition at the window's center.

Examine Fig. 8. This figure shows windows on the two station bodies (one in the e s t a b state and the other firing transition toca Ld~ scon) of the Abracadabra protocol [15]. The two left windows are normal windows showing the complete EFSMs. The two right windows are scrolling windows which were originally opened to a much larger size and then reframed to be smaller. This scrolling window functionality is extremely advantageous while attempting to watch the behavior of a single, large EFSM or behavior between several concurrent EFSMs. It allows many small windows to be open simultaneously on different state machines without any becoming illegible. And since automatic scrolling keeps the current state or transition always visible, a user's attention is focused on the most relevant activity.

=peoifioitlon ntp

internttbody ( z y s t e m l C t i v i t y )

~~

1,o

rou t ir

b©4y (tot ivi ty)

imp[3]

imp[2] LJ

U0m,[1]

~mpU U hetlbody[l] (sy$1emaolrlvlly)

ho'~Ib~dy[3] (tyttemaotlvity~

ho~tbody[2] (t VsrI~mactlvlty)

¢lockxeleCttr4nt

DetrilP[~]

A

U d;scar dmet ranz

peQrlp[|]

*,*ng~*,tl*nt,An~ / ztndtr&ns

1 I

..... lebody(2] i(,y,t .... t;v;ty} OOhLJ

I

Fig. 9. Different viewes of module instances.

consol.body[$] (syst emaot;v;t y)

P.D. Amer, D. New / Protocol ~isualization

3.3. Graphical consistency

does. This reinforces a user's understanding. Any default graphics which occur when G R O P E is initially used are always graphically consistent, and operations which might otherwise result in an inconsistent graphical display either are rejected with an appropriate message or automatically corrected.

Graphical consistency is a critical requirement for any protocol visualization system. Graphical consistency requires that the graphical image remains conformant with the actual specification at all times. This means that any attempt by a user to move an object to a location where it is not visually conformant with the specification is rejected with an error message. As examples, G R O P E does not allow a user to move a module instance outside of its parent. Also, it is impossible to "convert" an internal interaction point into an external one by moving it to the border of its module instance. And it is impossible to move a state to overlap another state. G R O P E maintains graphical consistency at all times. Knowing that graphical consistency is enforced avoids a user from needing to check if an image matches the specification; with G R O P E it always

Qraptlc~l Representation of Protocols

3.4. User-controlled abstraction At any time during a simulation, G R O P E allows a user to change the level of detail or abstraction of the various modules being displayed. A user may select less detail to gain more of an overview or more detail to debug or learn the specifics of individual modules and module interactions. Examine Fig. 9 taken from an Estelle specification of the US Department of Defense Network Time Protocol. Three instances of h o s t -

sp*elflo4tlen nl k

I

........... (.............. ) ~/~U,,,

;mPU

Created By D l r r l m ~

and P I u l

751

......... ('"t

,m,,,,t.__,' ]

impU

U PltlSi " " " ° , t ' } (,,,',~, ~tl*ot • m&r~ld

im, U I J hestbedy[=](tystema,ll

of De~wBre F o r info

G ROPEQUDEL.EDU

o p**rip[q] hottbody(¶](lystlmac~ivlty) PI¢ISl Itltot • marked ohlM ¢leekteleettrlht

e

4) p**rlp[1]

p**rip[~]

p**,;p[Z~

p*l,;p[2]

p**HH3}

peerip[3)

0

¢lockupd•tetea°t

~llivtrlrlnl ¢onl~

Ioo<loktr&as tsOlrdmtlrins

c*n u v

¢

~flgolookl~M

Body of tr&nlition ¢lockselicttrlns any k: 1.3 do when peerip[k],cloek~et act pldorllly 3 n a m e clockselect t rans: var pearvars:peerlistt ype; peercount;integer; I:integer;

V&lue of ntp.h©stbDdy[ 1 ] . ¢ 0 ~ ~ type: con$olaservicl (has° } individueLI queue value:external~ not locally linked queue: ( ~tertup(3~ 123,false,true, 11}

~pllrbody[1,9] (,¢tivlty)

of ntp.hosebody[ 1].peer'body[ 1,3].tohost

begin peercount := O; all p: peerntodulQ do begin if (O(p.peerv~r.stretum) end (p,pierv~tr,:str6tum(nl:pLinfl~) Ind {( 1-p.pqirvar, stretum)

l:~pe: peersQrvlce (peer } Indlvldu~.l queue v4iue:externel, not locally linked queue: ( clear) tohost

,U

Fig. 10. Various textual details of the network time protocol.

=*"U

P.D. Amer, D. New / Protocol visualization

752

body are shown in three different levels of detail. H o s t b o d y [" 3 "1 shows the graphical representation of the module instance's EFSM. This allows the behavior to be examined and transition firing to be animated. H o s t b o d y t l ] shows the internal architecture of a module instance including its child module instance. In general, children modules can be nested to any level. Children module instances, interaction points and queues, and channels are all shown allowing observation of traveling interactions. Finally in h o s t b o d y [ 2 "1, all internal details have been suppressed by the user. This is convenient for reducing distractions and for speeding up the display when the internals of children modules are unimportant. Additionally, in G R O P E , modules that are too small to be readable are automatically suppressed.

error recovery code, and presenting an automatic demonstration of G R O P E ' s abilities for use during conferences or while explaining G R O P E ' s features in person. At any time, a user may print a hardcopy of the entire screen or of any module instance. This feature was used to generate the display figures in this paper. G R O P E is capable of saving all graphical information as a normal text file, automatically reloading it each time a specification's interpretation is started. For ease of distribution, the text file can be included as comments within an Estelle specification. The format is designed to allow tools other than G R O P E easy access to this graphical information. When a user eventually does want to view detailed Estelle text, options are available that open textual windows showing the original Estelle source code of an object (e.g., transition body), or of interaction point queue contents, as shown in Fig. 10. Textual windows, however, are not dynamically updated as interpretation progresses. To allow for user-control of nondeterminism, G R O P E causes the interpreter to pause before selecting which child of an activity to execute or which offered transition to fire. The message of the parent module prompts appropriately, and the children modules with a transition to offer have their names marked with a " * " or the transitions themselves are highlighted. A user can then resolve the nondeterminism by simply clicking on the graphical object.

3.5. Miscellaneous GROPE operations For every object visible via G R O P E , it is possible to open a Smalltalk inspector on that object. An inspector does for a data structure what a debugger does for a process. This is useful both when modifying and improving G R O P E or when interfacing a new interpreter to G R O P E , as it allows detailed examination of all data and code reachable from a given visual object. It is easy to find errors in visual representation code and interpreter interface code because the correct starting place is automatically selected. There are also menu items for executing arbitrary Smalltalk code, generating errors for testing

specificationtestlO (systemactlvity) ac ~

hiah2h3

h ~

b

c

a~

d

b

~

l

~ ~db2

Fig. 11. A c o m p l e x state m a c h i n e .

753

P.D. Amer, D. New / Protocol visualization

specification testlO (systemactivity)

Mhi

Mdefg

Fig. 12. An abstract view of the complex state machine.

4. Macrostates, macrotransitions, and complexity reduction A difficult problem with the visualization of Estelle specifications is in the handling of complex EFSMs. Even with scrolling windows, a large EFSM, say with more than 10 states and 10 transitions, may not be legible. This problem of visualizing large fsms was solved with the use of macrostates and macrotransitions. Macrostates and macrotransitions are not constructs of Estelle. They are added to enhance G R O P E ' s visualization capabilities and have no semantic impact on a specification being simulated. A macrostate is a simplified graphical representation for a collection of states and the transitions between them. Macrotransitions are graphical representations of multiple transitions be-

tween two macrostates. Macrostates and macrotransitions allow subsets of a complex state machine to be replaced by simple graphics, thereby providing a higher level of abstraction. This decreases the number of distracting details and allows a user to concentrate on current and imminent behavior. A macrostate is displayed as an oval with a doubled line, and a macrotransition is an unn a m e d arrow also drawn with a doubled line. For example, consider the fairly complex state machine in Fig. 11. Figure 12 shows the same state machine with states a, b, and c grouped into macrostate Rabc; states d, e, f, and g grouped into macrostate Rdefg; and states h and i grouped into macrostate Mhi. State j is not a m e m b e r of any macrostate. T r a n s i t i o n s a h l , ah2, and ah3 are grouped

specification testlO (aysternactivity)

ac ~ ~ q ~ b c

Fig. 13. Autozoomed state machine changing states: Step 1.

754

P.D. Amer, D. New / Protocol visualization

specificationtestlO (systemactivity)

J~

~

J

f

Fig. 14. Autozoomedstate machinechangingstates: Step 2.

specificationtestlO (systemactlvity) ac ~ b c

Fig. 15. Autozoomedstate machinechangingstates: Step 3.

specificationtestlO (systamactivlty)

ahl ~ / ah2

~

.c "4

S)q-.c

It~.

cb.~ I~t"-~

~a~,~.-__._,~bI

Fig. 16. Autozoomedstate.machinechangingstates: Step 4.

P.D. Amer, D. New / Protocol cisualization

into the macrotransition between Ma b c and a h i, while transitions d bl and db2 are combined into the macrotransition from Mdefg to Mabc. The EFSM has been reduced from ten states and twenty transitions to four macrostates and five macrotransitions. Besides the practical advantage that this abstracted view physically fits better on a user's display, its abstraction is advantageous for gaining an initial level of understanding. By using G R O P E to suppress unnecessary details, a user focuses initial attention on the protocol's overall behavior. As a user becomes more familiar with a module's behavior, it is possible to mix states and macrostates in a single image, allowing detailed examination of states near the state of interest (usually the current state) while suppressing excess details of distant states by using macrostates. G R O P E ' s user can zoom in on any macrostate to display the states inside; any set of states can be unzoomed to display its macrostate instead. To focus a user on that behavior component active at the current moment without being overwhelmed by too much state machine detail, G R O P E provides autozoom, which dynamically changes between macrostates and regular states automatically as transitions fire. For example, the sequence of Figs. 13-17 demonstrates G R O P E autozooming the firing of transition a h 1. Figure 13 shows the module in state a. When the interpreter fires transition a h l , a sequence of os is drawn, resulting in Fig. 14. G R O P E then zooms in on macrostate Mh i to show both the f r om state and the t o state of the currently firing transition, as can be seen in Fig. 15. When transition a hl

755

finishes executing, the es are removed and the new current state is state h, as shown in Fig. 16. G R O P E now notices that state a need no longer be shown in detail and replaces a, b, and c with macrostate Mabc, yielding Fig. 17. By showing the currently active behavior component in detail while hiding the components which will not be active soon, a user's attention is focused on the component most critical to understanding without being overwhelmed with unnecessary detail. G R O P E allows a user to self-pace the learning of a protocol. It also allows a user to hide distracting details while trying to track down specification errors. Of course, G R O P E allows a user to reposition and resize states, macrostates, transitions, and macrotransitions as long as graphical consistency is maintained.

4.1. Automated state reduction and other complexity reduction techniques Besides the obvious ability to assign individual states to individual macrostates, G R O P E helps automate the abstraction process of transforming a module's complex state machine into a simpler state machine with macrostates and macrotransitions. Currently, a G R O P E user can combine all states with similar names into macrostates. A specifier of a large protocol often uses state names based on a syntactic pattern to indicate informally in which conceptual macrostate each state belongs. This pattern-based assignment capability was quite useful while working with an Estelle specification of the ISO virtual Terminal Protocol [1]. By grouping states according to the first four

specification testlO (syaternactivity)

hi1

~

f

Jt

Fig. 17. Autozoomed state machine changing states: Step 5.

......

I!

P.D. Amer, D. New / Protocol visualization

756 vtprn~body[1] (process)

Mst4O

Mst51

~fer04

Mst02/03

Mst42

MstSO

Fig. 18. Virtual terminal protocol: arranged with macrostates.

letters of their names, a set of reasonable macrostates were discovered, as shown in Fig. 18. Contrast this figure with illegible Fig. 19, G R O P E ' s initial guess in which no macrostates are used. It is also possible to assign states to macrostates depending on what Estelle stateset the states are located. Unfortunately, when states are in multiple statesets, no good way has been developed to determine which are the most useful statesets for graphical consideration.

G R O P E provides other methods of finite state machine abstraction. In addition to the functionality of hiding a module's internals, scrolling windows, and macrostates, it is useful while simulating a complex EFSM to remove "less important" transitions from G R O P E ' s display. For example, it may be useful to hide all transitions which handle provider disconnections, user protocol errors, or other rare conditions, since such transitions usually originate at many states, causing serious visual confusion. Of course, the semantics

Fig. 19. Virtual terminal protocol: all transitions.

P.D. Amer, D. New / Protocol uisualization

of the removed transitions remain; they are just temporarily not visualized. Transition bodies with more than one f r ore state may be hidden since these transitions may convey less connectivity information because they cannot distinguish amongst the states from which they originate. Hence, when attempting to determine the connectivity of a complex state machine they may be deemed less important.

5. Practical experiences In designing and using G R O P E over the past years at the University of Delaware, the authors discovered unexpected behaviors (i.e., errors) in several protocols. This section relates three actual experiences. Two errors were detected in Estelle specifications that have been published in ISO documents. Other errors were detected in a specification in the process of being written and debugged for the first time.

5.1. Alternating bit Early in G R O P E ' s development, the Alternating Bit protocol as specified in an annex of [14] was used in a demonstration. While experimenting with various user-controlled scenarios (e.g., the G R O P E user selected which transition to fire), the authors noticed that this protocol deadlocks without possibility of recovery if both user modules transmit "receive-requests" before transmitting any "send-requests." In this case all future send-requests from both user modules get blocked indefinitely behind the receive-requests. In all of the years of ISO 9074's development, it is assumed that this problem went unnoticed since a revised specification avoiding this potential deadlock problem is simple to write. Only after using G R O P E and visually observing the two queues backing up was this problem discovered. The demonstrator likely would not have noticed this potential problem without the dynamic graphical display offered by G R O P E . One can of course deduce this behavior from the static listing of the alternating bit protocol, but in this case, G R O P E brought the problem to the user's attention while the user was not even looking for problems.

757

5.2. Abracadabra While preparing for F O R T E ' 9 0 [22], anomalous behavior was detected in the Abracadabra protocol [15]. This protocol is basically the alternating bit protocol with the addition of reliable connection establishment and release. The anomalous behavior was first noticed when one of the stations would spontaneously disconnect from its peer. This would happen when the network became backlogged with retransmissions, at which time an acknowledgment would be received out of sequence. For example, the following sequence of events can cause a spontaneous disconnection. (1) Station one transmits a data packet with sequence number zero. (2) The network delivers it to station two, which acknowledges it. (3) Before the acknowledgment returns, station one retransmits packet zero, which is again delivered and acknowledged. (4) The network then delivers the first acknowledgment of packet zero. (5) Station one sends packet one, thinking that the acknowledgment indicates receipt of the retransmission, not of the original transmission. (6) When the network delivers the acknowledgment of the retransmission, station one believes this to be an incorrect acknowledgment of packet one, and enters the error phase. So far, this behavior is acceptable because the service is defined only to work if the round trip delay in the network is smaller than the retransmission time. In practice, this is impossible to document or enforce in an Estelle specification without modifying the semantics of time in Estelle's formal definition. ([4] proposes adding a new clause that limits the amount of Estelle time which may elapse between the enabling of a transition and completion of its firing.) While this behavior technically is not in violation of the specification, it certainly was unexpected. G R O P E allowed its user to gain a deeper understanding of the restrictions on the allowable implementations. In any case, whenever Abracadabra fails for any reason, it issues a disconnect indication (D i sInd) to the user when it enters the error state (D RS ENr), and it remains in the error state until it receives the disconnection confirmation PDU (D C) from its peer (or until it times out), at which time it moves to the CLOSED state. The actual bug in

the protocol arises because connection requests from

758

P.D. Amer, D. New / Protocol visualization

the user are discarded while in the error state. That is, DRSENT is included in the ConReqIgnore

stateset. The user module is not informed when the connection is actually finished being closed by both stations and thus cannot wait for the error state to be exited. Hence, if a user module sends a connection request before the DC returns, that request gets discarded silently by the station, and the user module waits indefinitely for a connection confirmation or refusal. Thus, Abracadabra fails to provide the error-free communication it claims. For further details and a proposed solution, see [19]. In this experience, both a deep insight and a mistake were revealed to a G R O P E user while not even expecting or looking for mistakes. Both Abracadabra and Alternating Bit have been published in international standards documents, indicating that they have been studied by a large number of experts. However, in the course of a few hours, G R O P E revealed deficiencies or mistakes in both protocols that to the authors' knowledge have not been identified previously. 5.3. Distributed queue dual bus

G R O P E has been used to help specify a number of protocols at Delaware. The third practical example involves using G R O P E to debug an Estelle specification of the IEEE 802.6 Distributed Queue Dual Bus (DQDB) protocol [12]. Since the specification has a complex architecture and requires a long time for WISE to initialize, it was found convenient to start the specification and come back to it later. For the first several revisions of the specification, DQDB would not send any packets through the busses. When the specification was started under GROPE, it was immediately noticed that a timer module unique to a single host was not being instantiated due to a simple typographical error in the expression that controlled that instantiation. Finding this error in the text would have been tedious as it was simply a misspelled name in the middle of a twenty page specification. After another revision, messages were being exchanged within hosts but not between them. The reason again became obvious via simple inspection: one queue in each host was full. The errant modules had been initialized to the wrong state, leading to unspecified receptions blocking

the queues. Without graphics to display the entire specification at once, it would have been necessary first to realize that the problem was an unspecified reception and then to search through dozens of queues looking for which ones were blocked, a tedious process at best. For finding each of these mistakes, it was extremely helpful to have the dynamic, graphical presentation available in this protocol visualization tool.

6. Summary and future work This article introduces protocol visualization to the relatively new field of protocol engineering. It demonstrates the theoretical and technical feasibility of developing a workstation tool that provides an animated, graphical interface to an FDT simulation tool. Through the design and development of GROPE, the advantages of allowing a user to manage visual complexity during an Estelle specification simulation are shown. Currently, the G R O P E system is being used to visualize TTCN test cases (P. Kalyanasundarum and P.D. Amer, Protocol test case visualization, Techical Report, University of Delaware, 1992) that are either generated automatically [8] or by hand. The system itself is being migrated from its SUN/Smalltalk platform to a NeXT/Objective-C platform. In addition to the expected performance improvement, several extensions of G R O P E are under investigation. These extensions and some suggestions for the Estelle language are now discussed. 6.1. E n h a n c e m e n t s to G R O P E

First, to focus attention on the firability of transitions, G R O P E flashes queues when their contents change. A logical extension to this would be to add graphical images representing exported variables and delay clocks. The exported variable icon could be a simple square (" • ") which would flash when either the parent or child instance changed any variable's value. This would alert a G R O P E user that transitions with p r o v i d e d clauses based on those variables may have become firable.

Similarly icons for delay clocks could be added to modules with delayed transitions. Such images could be designed to show at a glance the rela-

P.D. Amer, D. New / Protocol visualization

tionships between delay counters of different instances. For example, there could be a gray region representing the time remaining before transitions become optionaUy-firable and a black region indicating the time before a transition became firable ( " ( ~ "). These icons again would flash when a delayed transition became firable, drawing a user's attention to this important status change. A second enhancement would be to take extensive advantage of color. For example, one could allow those transitions unused for a time to "fade away" to a light color. One could display in one color (say, red) changes that occurred because of a recently fired transition, in a second color (say, yellow) all of the changes that have occurred during this system snapshot, and in a third color (say, green) the items which have not changed recently. The items with different colors could include newly instantiated module instances, fired transitions, and interactions in queues. When an unexpected change of state occurred, it would be much simpler for a user to determine what set of events led to the surprise. Finally, one major improvement to G R O P E is to add an automatic algorithm to determine which states should be put into which macrostates when initially given an Estelle specification. Currently, G R O P E provides convenient ways of assigning states to a macrostate but gives no assistance in determining the correctness of such an assignment. G R O P E could possibly use connectivity information as well as other formal and informal information to automatically decide on a reasonable abstraction of a complex state machine. 6.2. Enhancements to Estelle

At times during G R O P E ' s development, Estelle was found to lack features that would have facilitated tool development. For example, there is no standardized way of referring to an object such as a variable or interaction point in such a way as to also disambiguate its scope. There may be many variables named x in different scopes, and there is no standard way to indicate which x of which scope is intended. As well, a single transition body may expand into many transitions, and there is only one name clause for the body. G R O P E solved this problem by distinguishing ambiguous objects by their screen location.

759

In addition, there are Estelle objects which cannot be named at all. For example, channels have no names. Chamberlain [6] avoids this problem by referring to the channel connected to interaction point x with the construct c h a n n e t with X. Individual module instances have no names, and there can be many module instances which are identical. Both WISE and D I N G O from NIST require unique names for simulated instances. WISE prompts during execution of the i n i t statement, while D I N G O uses special comments in the Estelle specification to indicate what name should be used. Sanctioning a clause or specially-formed comment for naming objects uniquely would avoid ad-hoc solutions needed by today's tools. During Estelle's development, many extensions have been proposed (e.g., [5,31]). The major difficulty in visualizing these extensions lies in modifying the interpreter to accept the new constructs. Once an extended interpreter is available, extending G R O P E to graphically animate the new ideas is straightforward.

Acknowledgments The authors gratefully thank the anonymous reviewers for their helpful comments and suggestions.

References [1] P.D. Amer and F. (~eseli , Estelle formal specification of ISO virtual terminal. Comput. Standards Interfaces 9(1) (1989) 87-104. [2] S. Budkowski and P. Dembinski, An introduction to Estelle: a specification language for distributed systems, Comput. Networks ISDN Systems 14(1) (1988) 3-23. [3] S. Budkowski, P. Dembinski and L. Lumbroso, The BULL EsteUe simulator/debugger, Bull S.A., 68 route de Versailles, 78430 Louveciennes, France, October 1988. [4] S.C. Chamberlain and P.D. Amer, Formal specification of real-time constraints in Estelle, R~s. Inform. R~partie 2(2) (1992) 113-134. [5] S. Chamberlain and P.D. Amer, Estelle enhancements to support specification of distributed systems, in: W. Komorowski, ed., Proc. Computer Networks '91, Wroclaw, Poland, June 1991. [6] S.C. Chamberlain and P.D. Amer, Broadcast channels in EsteUe, IEEE Trans. Comput. 40(4) (1991) 423-436. [7] V. Chari, J.-F. Lenotre, L. Lumbroso and E. Mariani, An Estelle simulator/debugger tool (edb), in: M. Diaz, J.-P.

760

P.D. Amer, D. New / Protocol visualization Ansart, J.-P. Courtiat, P. Az6ma and V. Chari, eds., The Formal Description Technique Estelle (Results of the ES-

PRIT/SEDOS Project) (North-Holland, Amsterdam, 1989) 381-396. [8] W. Chun and P.D. Amer, Test case generation for protocols specified in Esteile, in: J. Quemada, J. Mafias and E. V~izquez, eds., Formal Description Techniques, III, Proc. IFIP TC6 3rd International Conference on Formal Description Techniques for Distributed Systems and Communication Protocols--FORTE 90, Madrid, Spain, 6-9 November 1990 (North-Holland, Amsterdam, 1991) 191206. [9] M. Diaz, J.-P. Ansart, J.-P. Courtiat, P. Az6ma and V. Chari, eds., The Formal Description Technique Estelle (Results of the ESPRIT/SEDOS Project) (North-Holland, Amsterdam, 1989). [10] A. Goldberg, Smalltalk-80: The Interactive Programming Environment (Addison-Wesley, Reading, MA, 1984). [11] A. Goldberg and D. Robson, Smalltalk-80: The Language and its Implementation (Addison-Wesley, Reading, MA, 1983). [12] Institute of Electrical and Electronics Engineers, IEEE P802.6 Standard: Distributed Queue Dual Bus (DQDB) Subnetwork of a Metropolitan Area Network (MAN). [13] ISO IS 8807, L O T O S - - A Formal Description Technique Based on the Temporal Ordering of Observational Behaviour, 1989. [14] ISO IS 9074, Estelle--A Formal Description Technique Based on an Extended State Transition Model, ISO/IEC, 1989. [15] ISO DIS 10167, Guidelines for the application of Estelle, LOTOS and SDL, 1989. [16] C. Jard, R. Groz, and J.-F. Monin, Development of VEDA: a prototyping tool for distributed algorithms, IEEE Trans. Software Eng. 14(3) (1988) 339-352. [17] P.S. Kritzinger and G. Wheeler, A protocol engineering workstation, in: S.T. Vuong, ed., Formal Description Techniques, H, Proc. IFIP TC6 2nd International Conference on Formal Description Techniques for Distributed Systems and Communication Protocols--FORTE 89, Vancouver, B.C,, Canada, 5-8 December 1989 (NorthHolland, Amsterdam, 1990) 53-59. [18] R.J. Linn et al., User guide for the NBS prototype compiler, Technical Report ICST/APM 87-1, US National Bureau of Standards, November 1986. [19] D.H. New, Protocol visualization, Ph.D. Dissertation, University of Delaware, 1991. [20] D.H. New and P.D. Amer, Adding graphics and animation to Estelle, in: E. Brinksma, G. Scollo and C.A. Vissers, eds., Protocol Specification, Testing, and Verification, IX, Proc. IFIP WG6,1 9th International Symposium, Enschede, The Netherlands, 6-9 June 1989 (North-Holland, Amsterdam, 1990). [21] D.H. New and P.D. Amer, Adding graphics and animation to Estelle, Inform. Software Technol. 32(2) (1990) 149-161. [22] J. Quemada, J. Mafias and E. V~izquez, eds., Formal Description Techniques, III, Proc. 1FIP TC6 3rd Interna-

tional Conference on Formal Description Techniques for Distributed Systems and Communication Protocols-FORTE 90, Madrid, Spain, 6-9 November 1990 (NorthHolland, Amsterdam, 1991). [23] T.W. Reps and T. Teitelbaum, The Synthesizer Generator Reference Manual, Dept. of Computer Science, Cornell University, July 1984. [24] P. de Saqui-Sannes and J.-P. Courtiat, From the simulation to the verification of Estelle* specifications, in: S.T. Vuong, ed., Formal Description Techniques, H, Proc. IFIP TC6 2nd International Conference on Formal Description Techniques for Distributed Systems and Communication Protocols--FORTE 89, Vancouver, B.C., Canada, 5-8 December 1989 (North-Holland, Amsterdam, 1990) 393-407. [25] B. Sarikaya, G. von Bochmann and E. Cerny, A test design methodology for protocol testing, IEEE Trans. Software Eng. 13(5) (1987) 518-531. [26] B. Sarikaya, S. Eswara and V. Koukoulidis, A formal specification based test generation tool, Technical report, Concordia University, Electrical and Computer Engineering Dept., 1988. [27] G. Shaw and P. Keller, Visual recipes: a scientist's guide to visualization, Lawrence Livermore National Laboratory, in preparation. [28] R. Sijelmassi and P. Gaudette, An object-oriented model for Estelle, in: K.J. Turner, ed., Formal Description Techniques, Proc. 1st International Conference on Formal Description Techniques for Communication Protocols and Distributed Systems--FORTE 88, Stirling, Scotland, 6-9 September 1988 (North-Holland, Amsterdam, 1989) [29] R. Sijelmassi and B. Strausser, NIST integrated tool set for Estelle, in: J. Quemada, J. Mahas and E. V~zquez, eds., Formal Description Techniques, III, Proc. IFIP TC6 3rd International Conference on Formal Description Techniques for Distributed Systems and Communication Protocols--FORTE 90, Madrid, Spain, 6-9 November 1990 (North-Holland, Amsterdam, 1991) 661-665. [30] R.L. Tenney, A tutorial introduction to Estelle, paper distributed during the 1st International Conference on Formal Description Techniques for Distributed Systems and Communication Protocols--FORTE 88, Stirling, Scotland, 6-9 September 1988; also available as Technical Report 88-1, University of Massachussets, Boston, MA, June 1988. [31] R.L. Tenney, Interaction sets in Estelle, in: J. Quemada, J. Mafias and E. V~izquez, eds., Formal Description Techniques, III, Proc. IFIP TC6 3rd International Conference on Formal Description Techniques for Distributed Systems and Communication Protocols--FORTE 90, Madrid, Spain, 6-9 November 1990 (North-Holland, Amsterdam, 1991) 377-382. [32] S.T. Vuong, ed., Formal Description Techniques, H, Proc. IFIP TC6 2nd International Conference on Formal Description Techniques for Distributed Systems and Communication Protocols--FORTE 89, Vancouver, B.C., Canada, 5-8 December 1989 (North-Holland, Amsterdam, 1990).