Formal modeling and automated analysis of the LAPD protocol

293

Formal Modeling and Automated Analysis of the LAPD Protocol * Sol M. SHATZ, Peter S. KAJKA and Ardaman S. C H A U H A N

1. Introduction

Software Systems Laboratory, Department of Electrical Engineering and Computer Science, Universityof Illinois at Chicago, Chicago, IL 60680, USA

A s c o m p u t e r c o m m u n i c a t i o n p r o t o c o l s grow in complexity, computer and communication companies m a k e large financial c o m m i t m e n t s in d e v e l o p ing, p r o v i d i n g a n d m a i n t a i n i n g such protocols. F o r this reason, use o f f o r m a l techniques for specifying a n d v a l i d a t i n g p r o t o c o l s continues to b e a very active research a n d d e v e l o p m e n t topic. O v e r the p a s t few years there has b e e n a t r e m e n d o u s g r o w t h in interest in the so-called I n t e g r a t e d Services Digital N e t w o r k ( I S D N ) conc e p t [1,2]. T h e C C I T T s t a n d a r d for I S D N call c o n t r o l is k n o w n as the L A P D b a s e d call c o n t r o l scheme. C h e n [3] briefly describes L A P D a n d discusses the r e l a t i o n s h i p b e t w e e n L A P D a n d L A P B . S i m p l y put, L A P D is a cousin of L A P B a n d a subset o f H D L C , with s o m e extensions. L A P D is used to establish, m a i n t a i n a n d clear c o n n e c t i o n s b e t w e e n c o m m u n i c a t i n g entities using message o r i e n t e d signals. T h e p u r p o s e of this p a p e r is to d o c u m e n t o u r w o r k o n m o d e l i n g a n d a u t o m a t e d analysis of L A P D . O n e " p r o d u c t " that has a l r e a d y a d o p t e d L A P D is A T & T ' s D i g i t a l M u l t i p l e x e d I n t e r f a c e ( D M I ) , an o p e n interface s u p p o r t e d b y A T & T a n d several o t h e r v e n d o r s [4]. O u r m o d e l s were d e r i v e d f r o m the d e s c r i p t i o n s of L A P D c o n t a i n e d in D M I ' s technical specification. M a n y techniques a n d tools for p r o t o c o l m o d e l i n g / analysis have b e e n p r o p o s e d a n d used in b o t h r e s e a r c h a n d d e v e l o p m e n t e n v i r o n m e n t s (e.g., [5]). T w o e x a m p l e s o f p u b l i s h e d w o r k t h a t are related to o u r s t u d y are [6] a n d [7]. S h a n k a r a n d L a m [6] verified a version o f the H D L C p r o t o c o l using a n e v e n t - d r i v e n process m o d e l a n d p r o o f s o f inv a r i a n t safety assertions. T h e i r w o r k is r e l a t e d to ours since their c o n c e r n was with a related d a t a link protocol, H D L C . But their s t u d y l o o k e d at the A s y n c h r o n o u s R e s p o n s e M o d e ( A R M ) f o r m o f o p e r a t i o n ; L A P D uses a different o p e r a t i o n mode--Asynchronous Balanced Mode (ABM). Also, in c o n t r a s t to their a p p r o a c h , our analysis is b a s e d on a u t o m a t e d state g e n e r a t i o n a n d in use of " o f f - t h e - s h e l f " e v a l u a t i o n tools.

Abslract. Of particular importance to the Integrated Services Digital Network (ISDN) concept is the standardization of network protocols. For data link control and communication ISDN uses a protocol called LAPD (Link Access Procedure "D'). LAPD evolved from LAPB (used in the X.25 protocol) and is a subset of HDLC, with some extensions. In this paper, we present and discuss Petri net models of some important LAPD procedures. We also discuss the use of some general purpose tools for automated analysis aimed at logical correctness as well as at connection-establishment performance. First we describe the communication between two entities as defined by LAPD and then we discuss our Petri net models and associated analysis methods and results. Keywords. Analysis, communication protocols, LAPD, Petri nets. Sol M. Shatz is an associate professor in the Department of Electrical Engineering and Computer Science at the University of Illinois at Chicago. He received his B.S. degree in Computer Science from Washington University in St. Louis and his M.S. and Ph.D. degrees, also in Computer Science, from Northwestern University in 1981 and 1983. Professor Shatz's research interests are in design and analysis of distributed software. He is co-editor of an IEEE tutorial text on "Distributed-software Ehgineering". Peter S. Kajka is a Ph.D. candidate in the Department of Electrical Engineering and Computer Science at the University of Illinois at Chicago, where he received his M.S. degree in 1989. He received his Bachelors degree in Engineering Technology from the University of Central Florida in 1980. He previously worked as a systems engineer at ECI Telecom, Altamonte Springs, Florida. Mr. Kajka's research interests include protocol languages and Petri net applications.

* This work was supported in part by a grant from AT&T Information Systems and the Office of Naval Research (ONR). An earlier version of this paper appears in the Proceedings of the 1987 Computer Software and Applications Conference. North-Holland Computer Networks and ISDN Systems 18 (1989/90) 293-314

0169-7552/90/$03.50 © 1990 - Elsevier Science Publishers B.V. (North-Holland)

29,4

S.M. Shatz et al. / Formal modeling of the LAPD protocol

Billington et al. [7] present and analyze a Numerical Petri Net (NPN) model of CCITT's first version of a draft recommendation for the ISDN user-network interface data link layer. LAPD is based on this recommendation. Our work differs from their work in two ways: First, we used general Petri nets (with inhibitor arcs); they used NPNs, a high-level form of Petri net. We justify our choice below. Second, they focus on a different subset of the data link protocol. In particular, we consider the connection-establishment and connection-clearing procedures, as well as the role of various specific supervisory frames, while they do not. Of course the main purpose of our study was to investigate the application of an existing model and support tools to L A P D - - t h e i r main purpose was to illustrate an example of NPNs. For our study, we chose to use the Petri net model [8]. This model is one of the most mature modeling formalisms, in terms of being based on established theory and supported by generally available automated tools. Petri nets are widely used to study behavior of concurrent systems, including communications protocols. In fact many "newer" protocol models are defined as extensions to basic Petri nets (e.g., N P N s as mentioned above). We provide a brief overview of Petri net definitions and notations in the next section. While it is true that some of the difficulties that we encountered in developing our Petri net models would not have occurred with some other more special-purpose models, Petri nets have their own advantages for work of this nature. First, Petri nets have a broad base of recognition. They have a very strong international following and continue to be a topic of intense research in many continents. Thus, new research results related to Petri nets, especially results applicable to efficient analysis, can immediately be applied to existing Petri net models. Secondly, there exists a relatively large pool of generally available tools for supporting automated development and analysis of Petri nets (e.g., [9,10]). Therefore technical details found in documented experiments that are based on Petri net models (such as those in this paper) can be used as a platform for extended work by other protocol researchers and practitioners. We also note that another advantage we obtained from using Petri nets was the ability to extend the net model to incorporate timing information in sup-

port of performance analysis. We ¢llSCUSS this in Section 6. The remainder of this paper is organized as follows. In Section 2 we give a brief introduction to Petri net theory. The focus is on those Petri net properties that are directly relevant to the work being described. In Section 3 we discuss LAPD and describe the LAPD functions that are relevant to our study. In Section 4 we present and discuss our Petri net models of LAPD and in Section 5 we discuss the application of automated analysis tools to our model. In Section 6 we briefly discuss an extension of our Petri net model of LAPD's connection establishment function that includes timing information. We also briefly discuss some performance data obtained from automated analysis of this timed Petri net model. Finally, some conclusions and future research extensions are given in Section 7.

2. Petri Net Overview

Petri nets [8] are graph models which are capable of direct representation of concurrent system properties such as parallelism, conflict (i.e., decision choices), and synchronization. The Petri net formalism is very well understood theoretically and has been used in a wide variety of application domains. Rather than discussing this model's many attributes here, we simply refer the reader to [8], which likewise contains references to many of the important papers in the Petri net literature. In this section, we focus on reviewing some of the key terminology and definitions that are directly relevant to the work being documented in this paper. A Petri net is composed of four parts: a set of places P, a set of transitions T, an input function 1, and an output function O. A Petri net is represented as a bipartite directed multigraph. Place nodes are represented by circles and transition nodes by bars. Arcs connect places to transitions and transitions to places. An input function defines which places are connected to which transitions and an output function defines which places are connected from which transitions. A marked Petri net is a net which has tokens (represented by small solid black circles) allocated to some place nodes. A place which contains one or more tokens is said to be marked, and the assignment of tokens to places is called the Petri

S,M. Shatz et al. / Formal modeling of the LAPD protocol

net's marking. Dynamic properties of Petri nets are characterized by changes in markings due to "firing" of transitions. A transition may fire if it is enabled, i.e., each input place to the transition has at least as many tokens as there are arcs from the place to the transition. When a transition does fire, it removes a number of tokens from each input place (a number equal to the number of arcs from the place to the transition) and puts a number of tokens in each output place (a number equal to the number of arcs from the transition to the place). Thus, the firing of the transition results in a new marking. A transition firing is considered an indivisible operation. Figure 1 shows an exam-

P3 T

Figure A,I

P ~

T

1

Figure A,2

P4

A Marked Petfi Net

~ P3

P4

Figure A.1 After the Firing of Transition TI

P3 _

Figure A.3

P4

Figure A,2 After the Firing of Transition T2

Fig. 1. A n e x a m p l e Petri net a n d firing sequence.

295

ple marked Petri net and the result of a transition firing. Modeling a system by a Petri net involves deftning a set of places that represent conditions of the system being modeled and defining a set of transitions that depict the events of concern. An initial marking is chosen that represents the initial conditions of the system. In protocol modeling for example, the initial marking would specify tokens in the places representing the initial states of the communicating entities. Analysis of the Petri net model can reveal properties of the modeled system. A powerful analysis technique is reachability analysis. From the initial marking of the net all reachable markings are determined and the corresponding reachability graph is produced. An algorithm for reachability graph production is given in [8]. The disadvantage of reachability analysis is its computational complexity, which is exponential in the worst case. Since communication protocols specify the interactions among otherwise concurrently executing entities, in our experience, Petri net models of communication protocols do not typically define much parallelism and thus the reachability graphs are far from the worst case type. Three important Petri net properties which we will use in our analysis of LAPD are boundedness, safeness, and freedom from deadlock. Boundedness: A place is k-bounded if the number of tokens in that place does not exceed an integer k for any reachable marking. A Petri net is said to be bounded if all places are k-bounded for some finite integer k. A bounded Petri net implies a finite reachability graph. Safeness: A place is safe if it is 1-bounded (a special case of k-boundedness). A Petri net is said to be safe if all places are safe. In general protocol modeling, a place that models a single message would be expected to be safe. Freedom from deadlock: A Petri net is free of deadlock if there does not exist a reachable marking from which no other marking is reachable. A marking, or state, which represents a normal system termination is not considered a deadlock state even though no other marking is reachable from this state. In Section 5, these three net concepts are evaluated with respect to our particular LAPD model. A Petri net model of an alternating-bit protocol is given in [10].

290

S.M. Shatz et al. / Formalmodelingof the LAPDprotocol

3. LAPD Operation Overview LAPD is a data link layer protocol and is based on CCITT Recommendations Q.920 and Q.921 [11] which define the " I S D N User-Network Interface Data Link Layer" protocol. As mentioned before, LAPD evolved from LAPB and shares many important characteristics and behaviors. We now give a brief description of some basic properties of LAPD. Our discussion is based on the LAPD description found in [4]. We consider a nontrivial subset of LAPD; we do not discuss or consider state transitions dependent on the following LAPD commands and responses: frame reject responses (FRMR), used to indicate an error condition not recoverable by frame retransmission; reject (REJ) commands/responses, used to request retransmission of information frames; and receiver not ready (RNR) commands/responses. The model presented in Section 4 and analyzed in Section 5 does not contain any timing information. In Section 6, we present a timed model for connection establishment, where we do consider timers and the "retry counter". For our discussion, we consider point-to-point communication between two entities called A and B. Communication between the two entities is done through the use of frames. Three types of frames exist in LAPD: information frames, supervisory frames, and unnumbered frames. Information frames (l_ frames) transfer information between entities and contain a send sequence number N( S), receive sequence number N( R), and a p o l l / f i n a l bit ( P / F ) . Supervisory frames perform data link supervisory functions, such as acknowledging I_ frames, and contain a receive sequence number N ( R ) and a p o l l / f i n a l bit ( P / F ) . Unnumbered frames provide additional data link control functions that do not required any numbering information. Unnumbered frames contain a P / F bit. All three types of frames (information, supervisory, and unnumbered) can be either command frames or responses to command frames. The purpose of the sequence numbers and the P / F bit will be further explained as necessary. For our discussion, we only consider transitions relevant to one "connect-transfer-disconnect" cycle. Initially, both entities are in a state called T E l _ A S S I G N (TEI stands for Terminal Endpoint Identifier). We can divide LAPD services into three broad areas--connection establishment,

formation frame transfer, and connection tear down (disconnection). (a) Connection establishment. For A to establish communication with B, A sends an unnumbered command frame S A B M E _ C M D (Set Asynchronous Balanced Mode Extended) to entity B. This command indicates A's desire to establish an asynchronous balanced mode connection with multi-frame buffering (window size of 4 is default) and modulo of 128. Multi-frame buffering means that one or more information frames, up to the window size, may be sent without receiving acknowledgment. A then enters the state A W A I T _ E S T (Await Establishment) to wait for the connection to be established. Entity B, upon receiving the SABME command, acknowledges with the unnumbered response frame U A _ R S P (Unnumbered Acknowledgment Response) and then enters the state M F _ E S T _ N O R M (MultiFrame Establish Normal). Upon receiving this acknowledgment, A enters the state M F _ E S T _ N O R M . Now a data link connection has been established between A and B and multiframe information transfer can take place. It is also possible for both entities to "simultaneously" send S A B M E _ C M D frames, in which case each entity should respond with a UA_ RSP frame while in the AWAIT EST state. This is necessary to prevent a deadlock with each entity waiting for a response to its desire to establish a connection. See Fig. 2 for a finite state machine model for the described subset of LAPD. (b) Information frame transfer. If either entity has information frames (i.e., I_ frames) to transfer, the source's I_ frame window must be "open", that is, the number of I_ frames sent but not yet acknowledged must be less than or equal to the window size. Two variables, V(S) (Send State Variable) and V(A) (Acknowledge State Variable), are used to calculate whether the window is open. V(S) holds the send sequence number of the next I_ frame to be transmitted and II(A) identifies t h e last acknowledged I_frame. V ( A ) - 1 equals the send sequence number of the last acknowledged I_ frame. The source's I_ frame window is open if V(S) < V(A) + k (where k is the window size). Each site also maintains a third variable, V(R) (Receive State Variable), which holds the send sequence number of the next I_ frame that the site expects to receive. When the source sends an I_frame, the send sequence number N ( S ) is set

S.M. Shatz et al. / Formal modeling of the LAPD protocol

Sand SABM_CMD

Send UA_RSP

Send UA_RSP Receive SABM_CMD

Recei and/o

,_RSP

F_NORM) Send/ReceiveI_framesand/or Send/Receive RR_frames

Fig. 2. FSM model of the LAPD subset.

equal to V(S) and the receive sequence number N(R) is set equal to V(R), and V(S) is incremented by one. Along with the send and receive sequence numbers, the status of the poll bit (P) is set in the I frame. The poll bit indicates the current "poll mode" of the entity, which is indicated by a local " P flag" variable. If the entity is in a poll mode, the P_flag is "on" and the corresponding P-bit in the information frame is set "on". The receiver must respond to this "polling command" with some specific acknowledgment frame (as discussed below). Since LAPD requires that no further data be sent until the polling command is acknowledged, the source does not send any more I_ frames until such an acknowledgment is received. The establishment of poll mode values is outside LAPD's domain of effect. Assume that A is the source of the I_ frame and that B's own receiver is not currently busy. Upon receiving the I_ frame, B will remain in the MF_EST_NORM state. But B will have different action responses depending on various conditions. Case 1: The received I_frame's poll bit is "on" (which implies that a response frame is being solicited by A). In this case, B responds by incre-

297

menting its value of V(R) by 1 and by sending the supervisory response frame RR_RSP (Receive Ready Response) with the final bit (F) set and N(R) equal to the updated value of V(R). The setting of the F-bit indicates that the RR_RSP frame is responding to the polling command as well as acknowledging reception of the I_ frame. Case 2: The received I_frame's poll bit is "off", B is not expecting a response from one of its own polling commands, B has data in its queue at this time and the current number of unacknowledged I_frames sent from B to A is less than or equal to the window size. In this case, B responds by updating its value of V(R) and sends one of its own I frames with N(R) equal to the updated value of V(R) and the poll bit reflecting B's current poll mode. Depending on the poll bit value, B may or may not now be in a state of expecting a response to a poll command it has sent. Case 3: The received I_frame's poll bit is "off", B has no data in its queue, and B's local "poll mode" is set (indicating that B polls when sending commands). In this case, B responds by sending the supervisory command frame R R C M D (Receive Ready Command) with the poll bit "on" and with N(R) set as in Case 2. Case 4: Like Case 3 except that B's local poll mode is not set. In this case, B responds by sending the response frame RR_RSP (with final bit "off"). Case 5: The received I frame's poll bit is "off", but B is currently expecting a poll response. B cannot send an I_ frame even if its send window is open and it has data in its queue, for it is expecting a poll response. Therefore, B must respond by sending the response frame RR_ RSP (with final bit "off"). Now that we have considered the conditions and actions related to I_frames, we consider the handling of supervisory frames when in the MF_EST_NORM state. Upon receiving an R R CMD (with poll bit "on") supervisory frame, an entity (assume entity B) responds by sending the supervisory response frame RR_RSP (with final bit "on"). Note that this response is the same as for Case 1 above. The key difference is that the response frame for Case 1 contains an updated I_ frame receive sequence number N(R) to acknowledge the received I frame. The R R RSP response frame issued due to reception of an

298

S.M. Shatz et al. / Formalmodelingof the LAPD protocol

R R _ C M D does not contain an updated receive sequence number since the R R _ C M D did not transfer data. We will discuss how our Petri net model deals with this issue in Section 4. If an entity is expecting a response to a comm a n d frame with P-bit set to 1 and it receives an R R _ R S P frame with final bit "on", the entity responds by updating some local variables. N o frames are sent. In particular, the receiver sets its local P_ flag variable to zero to indicate that it is no longer expecting a response to a previously sent polling command. It also updates its local acknowledge state variable, V(A), based on the received sequence number, N ( R ) , contained in the response frame. If an entity receives an R R _ R S P frame with final bit "off", it also responds by setting some local variables. In this case, again the receiving entity updates its local variable V(A). But, since the received frame's final bit is "off", we can deduce that the new V ( A ) value will reflect the fact that another I_ frame has been acknowledged. (c) Connection tear down. Assume that entity A initiates the release. When in the M F _ E S T _ N O R M state, A sends the unnumbered frame D I S C _ C M D (Disconnect Command) to B and then enters the new state A W A I T _ R E L (Await Release). When B receives this frame while in the M F _ E S T _ N O R M state, it sends the unnumbered acknowledgment response frame U A _ R S P back to A and enters the state T E l _ A S S I G N . Now, when A (in the A W A I T _ R E L state) receives the U A _ R S P frame, it enters the T E l _ A S S I G N state. With both entities in the T E l _ A S S I G N state, we have returned to the initial system state. L A P D also handles the case of both entities sending disconnect commands and then both entering the A W A I T _ R E L state. What is desired is to have each entity receive the peer's disconnect c o m m a n d and then return to the T E I _ A S S I G N state. But, since an entity m a y enter the A W A I T _ R E L state at a time when there are outstanding frames already sent by its peer (in the M F _ EST_ N O R M state), the U A _ RSP or disconnect c o m m a n d it is waiting for may not be the next frame to be r e c e i v e d - - w e assume a point-topoint connection and thus the property that frames are received in the order they are sent. Therefore, L A P D defines the reception of I_ frames, supervisory frames, and unnumbered frames--excluding the D I S C _ C M D and the U A _ R S P - - w h i l e in

the A W A I T _ R E L state with the sole result of the reception being that the entity remain in the A W A I T _ R E L state. In effect, this allows the entity to consume outstanding frames and eventually "see" the frame it is waiting for. As we will discuss in the next section, the property that control frames (i.e., supervisory or unnumbered frames) are to be received in the order they are sent causes some real difficulty in modeling L A P D with a Petri net. Since L A P D communication between two entities is symmetric, either entity can request to establish multiple frame operation, send I_ frames, and initiate connection release. Figure 2 shows a finite state machine model for the described subset of LAPD. The model shows the states and transitions for one entity only. In the next section, we expand this model to explicitly reflect two party communication and we show how a Petri net model can directly represent the communication implied between the state machine models.

4. Petri Net Model Development 4.1. Prefiminaries

One approach to protocol analysis is to directly analyze the protocol's finite state machine model as in [12]. Alternatively, we can develop a more powerful model using the basic scheme of [13]: (1) model each entity by a state machine, (2) use some explicit interconnection modeling mechanism to connect together the state machines giving a global model. Since state machines are a subclass of Petri nets (i.e., Petri nets restricted so that every transition has exactly one input place and one output place), we can connect the state machines (of Fig. 2) by adding arcs and creating new shared place nodes. We will discuss the major components of the Petri net model. We do not show the complete resulting Petri net graph since it is quite complex and not very viewable. However, in Section 6 we do give a graph view of the connection establishment subset with timing information. The complete model is given in textual form in Appendix A. This form is not only more readable for a complex net, but it is the form used for our automated analysis as discussed in Section 5. Each line of the Petri net

S.M. Shatz et aL / Formal modeling of the LAPD protocol

description in Appendix A corresponds to one transition in the model. The last line, " ( A _ TEI _ ASSIGN,B _ TEI _ ASSIGN, A_ B O U N D E R ) " , corresponds to the net's initial marking, i.e., one token in each of the three named places. We will see what these places represent later. Now, consider the first line (transition) as an example: :tl: A _TEI _ ASSIGN ~ A _ A W A I T _ EST, AB_ SABM_ CMD, A_Q_EMPTY In terms of the Petri net, this defines a transition named tl which has one input place (whose label is to the left of the " ~ " symbol) and three output places. See Fig. 3. Examination of Appendix A shows that our Petri net model consists of 74 transitions (and 48 places). Since we have a symmetric protocol, we actually use 37 transitions to model each entity. For example, transition t16 models the symmetric case for transition tl. To model connection establishment for one entity, we need three place nodes in the state machine m o d e l - - f o r the states T E I _ A S S I G N , A W A I T _ E S T , and M F _ E S T NORM. When we connect together the two communicating state machine models, we add four new "frame places". Each new frame place models the condition that a particular frame has been sent to (but not yet accepted by) a destination entity. Such a frame is said to be currently outstanding. For connection establishment we need the following four frame places: (1) " A B _ S A B M _ C M D " (SABME_CMD frame from A to B), (2) " B A _ SABM_ C M D " (the symmetric case for (1)),

ATEI_ASSIGN

()

A_AWAIT EST

AB SABM CMD

A_Q_EMPTY

Fig. 3. A graphical view of transition tl in the Petri net model.

299

(3) " A B _ U A _ R S P " ( U A _ R S P frame from A to B), (4) " B A _ U A _ R S P " (the symmetric case for (3)). We model A's P flag with a place labeled A _ P F L A G (similarly for entity B). The place is safe (as defined in Section 2) and models the condition that A's P_ flag is on. Thus, to test if the flag is on, we simply include a transition from the place to an appropriate transition. To test if the flag is off, we need to test if the place has no tokens. This is done by using a so-called "inhibitor arc", a special arc (from a place to a transition) that allows the transition to be enabled when the place in question is not marked. By the use of inhibitor arcs for modeling tests on protocol flags we are able to avoid the rather cumbersome option of modeling each flag with two complementary places, one for the condition that the flag is true and the other for the condition that it is false. To model connection release (from the perspective of one entity), we need one additional state place, A W A I T _ R E L . When we connect together two entity state machines, we add the following two "release frame places": (1) " A B _ D I S C C M D " ( D I S C _ C M D from A to B). (2) " B A _ DISC_ C M D " (the symmetric case). Also, instead of building the model so that the entities return to the initial state (TEI_ASSIGN) following a connection release, we force the entities into special termination states denoted by places labeled " A _ STOP" and " B _ STOP". This allows us to check easily for proper termination during our examination for deadlock states.

4.2. Multi-frame Capabifity A key problem in modeling the transfer of information frames is the modeling of the multiframe communication property. If we assume the default maximum of four outstanding information frames, we must build our model to ensure that no more than four I_ frames have been sent (by one entity) but not yet acknowledged. In terms of our Petri net model, this means that we must control the firing of all transitions corresponding to sending of I_ frames. The simple way to handle this problem is to introduce a place (one per entity) which will always contain a number of tokens equal to the number of I_ frames that can still be

300

S.M. Shatz et a L / Formalmodeling of the LAPD protocol

sent by the corresponding entity. We label these places "A_ B O U N D E R " and " B _ B O U N D E R " . An entities' " b o u n d e r place" serves as an input place to the transitions modeling I_ frame send events, and it serves as an ouput place from transitions modeling reception of I_ frame acknowledgments. The number of tokens allocated to a bounder place will determine the maximum number of outstanding I_ frames allowed for the corresponding entity. By initializing a bounder place with zero tokens, we force our model to only allow the corresponding entity to act as a receiver of l_ frames. This ability to independently control l_ frame "window sizes" without having to alter the structure of the Petri net model itself, greatly facilitated our analysis experiments. In the previous paragraph we mentioned that bounder places serve as output places from transitions that model the receiving of l_ frame acknowledgments. T o implement this property, we must be careful not to blindly model each frame type with only one Petri net place. To see this, consider the following scenario. Entities A and B establish a connection and enter the M F _ E S T _ N O R M states. A sends an I_ frame to B and stays in the M F _ E S T _ N O R M state. B accepts the I_ frame and sends an RR_ C M D to A (see Case 3 in Section 3). Then A accepts the R R _ C M D and sends and R R _ R S P back to B. The important point is that the RR_ RSP frame does not contain an updated receive sequence number, i.e., this R R _ RSP is not being used to acknowledge acceptance of an I_ frame. In fact, it was the RR_ C M D frame that contained the updated receive sequence number that acknowledged B's acceptance of the I_ frame. But, since it is also possible for an entity to send an R R _ RSP frame in response to accepting an I_ frame (see Case 1 in Section 3), in which case the R R _ R S P frame does serve as an acknowledgement for the I_ frame, we must distinguish these two frames by using two distinct places. I f A's R R _ R S P frame is being sent in response to the acceptance of an R R _ C M D , we model this event by marking (i.e., adding a token to) a place labeled A B _ R R _ R S P _ F I _ N O A C K (it is an R R _ R S P with no I_ frame acknowledgment component). Of course a symmetric case exists when B is sending the frame. On the other hand, if A's R R _ R S P frame is being sent in response to the acceptance of an l_ frame, we model this event by marking a place labeled AB_

R R _ R S P _ F I _ A C K . Now, to model B's reception of an R R _ RSP frame, we use two transitions - - o n e transition specifies the place A B _ R R _ R S P _ F I _ A C K as an input place and the other transition specifies the place A B _ R S P _ F I _ N O A C K as input. Otherwise the transitions' inputs are the same. The only difference in the transitions' output places is that the transition with A B _ R R _ R S P _ F I _ A C K as input does specify the place B _ B O U N D E R as an output while the other transition does not. 4. 3. Order of Acceptance for Control Frames

Another critical modeling problem is that of enforcing that certain control frames are not received before other previously sent frames. The problem arises because under some conditions an entity may send a particular control frame or I_ frame and before that frame is accepted the same entity may send another control frame. Consider a specific LAPD scenario in the context of a Petri net model. Assume the following sequence of LAPD events: (1) entity A sends S A B M _ C M D and enters A W A I T _ EST state, (2) entity B sends S A B M _ C M D and enters A W A I T _ EST state, (3) entity A receives B's S A B M _ C M D and sends UA_ RSP. Now, A has two outstanding control frames. If we were to simply model the sending of each control frame by the marking of a place modeling the condition that the particular frame has been sent, we would end up with a state in which both AB_SABM_CMD and A B _ U A _ R S P are marked. Unfortunately, with a Petri net we do not have any way to tell which place was marked first. Thus, there is nothing in the Petri net firing rules to stop entity B from accepting the UA_ RSP and entering the M F _ E S T _ N O R M state with A's SABM_ CMD remaining unaccepted. Another example of this type of problem occurs when an entity sends an I_ frame followed by a D I S C _ C M D frame. We do not want the destination entity to receive the D I S C _ C M D before receiving the l_ frame. Clearly, we must explicitly equip our model to avoid such behavior. T o simplify the discussion, consider the case where only A is a sender of control frames (the model treats B in an analogous fashion). We

301

S.M. Shatz et aL / Formal modeling of the LAPD protocol

introduce the following places (analogous ones for B) and then discuss their use. ( 1 ) O K _ A _ S (A has no outstanding control frames), (2) A _ Q _ E M P T Y (A's queue of waiting control frames is empty), (3) U P D A T E _ A _ Q (need to update A's control frame queue), (4) A_ I O U T (buffer to count A's outstanding I frames). Considering the previous scenario, we can not model reception of the SABME command by simply including a transition like this A _ A W A I T _ EST, BA _ SABM _ C M D A_ A W A I T _ EST,AB _ UA _ RSP We need to prevent the marking of the control place AB_ UA_ RSP if A has an outstanding control frame. Naturally, if A does not have an outstanding control frame we can " s e n d " the UB_ UA_ RSP frame, but we must also record the fact that A then does have an outstanding control frame (the A B _ U A _ R S P ) . Thus, we could consider specifying the above transition like this A _ AWAIT _ EST, BA_ SABM_ C M D , O K _ A _ S --* A A W A I T _ EST,AB_ UA_ RSP, O K _ B_ S Since the firing of this transition accepts one of B's control frames, the place O K _ B_ S is included as an output place. Now, what we have accomplished is to prevent A from sending its control frame if it currently has an outstanding control frame. Unfortunately, we did this by preventing the firing of the transition itself, which has other effects besides the sending of a control frame, i.e., the reception of B ' s SABM command. In this example, note what happens if both entities send SABM_ CMDs. By sending its SABM command, each entity will then have an outstanding control frame. So, the model would deadlock--neither entity could fire its "SABM receive transition" since neither O K _ A _ S nor O K _ B _ S would be marked. As a final solution to this problem, we propose the following two transitions in place of the single transition above; these are transitions t4a and t4 of Appendix A. See Fig. 4. A _ A W A I T _ EST,BA _ SABM _ C M D , O K _ A _ S --* A_ A W A I T _ E S T , U P D A T E _ B_ Q, AB _ U A _ RSP,

Q AB UA RSP

~

AB_UA_FI(SP~

t

i

t#a

BA_SABM_CMD

UPDATE_B_Q

Fig. 4. A graphical view of Pctri net transitions t4 & t4a in the model.

A _ AWAIT _ EST,BA_ SABM _ CMD, O K _ A _ S(0),A _ Q_ EMPTY --* A_ AWAIT_ EST, U P D A T E _ B_ Q, Q_AB_UA_RSP

First, consider the second transition above. Note that it has an inhibitor arc from the place O K _ A _ S (thus the notation O K _ A _ S(0) in the textual description above and the small circle in place of the arrowhead on the arc connecting the place O K _ A _ S to transition t4 in Fig. 4). This transition can be enabled only when the place O K _ A _ S is not marked. Now even if A already has an outstanding control frame (the S A B M C M D for instance), the second transition can fire. This allows B's SABM command to be accepted. Since A's U A _ R S P will not be its "leading" control frame, the U A _ R S P is marked as being queued (Q A B _ U A _ R S P ) . Since B's leading control frame (its S A B M _ C M D ) is accepted, and B may have some queued control frame, we mark a place ( U P D A T E _ B_Q) to indicate the need to update B's control frame queue. If we did not change the output place from O K _ B _ S to UPD A T E B Q, the model would allow B to put its next control frame ahead of one that may be queued. Now, the operation of transition t4a should be clear. The final eight transitions of Appendix A show how the places U P D A T E _ A _ Q and U P D A T E _ B _ Q enable transition that either " p r o m o t e " a queued frame in terms of making it available for reception (by effectively removing the leading " Q " from the frame place name), or else allow control frames to be sent (by marking the place O K B S

302

S.M. Shatz et al. / Formal modeling of the LAPD protocol

or O K _ A _ S ) if there are no queued control frames. Other transitions which send control frames are specified in a manner similar to that just described. The place A_ 1OUT is used in testing if entity A can send a DISC_ C M D or send a UA_ RSP in response to receiving B's D I S C _ C M D . We want A to send only if it currently has no outstanding I_ frames. One way we can detect this condition is by checking for a "full" A _ B O U N D E R place, i.e., A_ B O U N D E R contains the same number of tokens as in its initial marking. However, since the number of tokens in A _ B O U N D E R varies with the initial marking, place A _ I O U T (l_ frames Outstanding) was added to indicate the number of outstanding I_ frames. Thus, each transition that takes a token from A _ B O U N D E R in its input puts a token in A _ I O U T in its output. Likewise, each transition that places a token in A_ B O U N D E R in its output takes a token from A _ I O U T in its input. If A _ I O U T is empty, no I_frames are outstanding, and the D I S C _ C M D or the UA_ RSP can be sent. 4.4. Poll Mode Choices

According to the LAPD specification, when an entity sends an I _ C M D , the entity can send the frame with the poll bit " o n " or "'off". The choice depends on the entity's current poll mode status. The poll mode status is not controlled by the data link layer services. Thus, for our concern, we must consider either poll mode case to be possible. We do this by modeling the sending of an I _ C M D with a pair of transitions which can be nondeterministically selected for firing. For entity A, the two relevant transitions, t5 and t6 in Appendix A, are defined as follows: :t5: A_ B O U N D E R , A _ N O R M , A_ PFLAG(0), OK_A_S --* A_ N O R M , A _ PFLAG, AB _ I _ C M D _ P1,OK _ A _ S,A _ 1OUT :t6: A_ B O U N D E R , A _ N O R M , A_ PFLAG(0),OK_ A_ S --+ A_ NORM,AB_ I _ C M D _ P0,OK_ A _ S, A_ I O U T Marking the place AB_ I_ C M D _ P1 (or AB_ I_ C M D _ P 0 ) indicates that entity A has sent an

I _ C M D with poll bit " o n " (or "off"). Note that entity A's poll flag is set to reflect the poll mode status being used.

5. Model Analysis For our analysis of the LAPD subset, we considered a number of cases: single frame operation (with respect to I_ frames) with one entity sending, single frame operation with both entities sending, and multiple frame operation with both entities sending. The case of single frame operation with one entity sending (A sending and B receiving) is accomplished by the use of the initial marking shown at the end of Appendix A. Analysis of our model is based on analysis of the Petri net's reachability graph. Since the model is rather complex and generates a reachability graph of over 70 states for single frame operation with one entity sending, it is not practical to either generate or evaluate the model without the aid of automated tools. We have used a suite of Petri net tools, called P-NUT, developed at the University of California at Irvine [10,14]. The suite of tools consists of TRANSL, a tool for translating Petri net specifications from a textual set of transitions (as shown previously) to a form for computer processing; RGB, a reachability graph builder; RGP, a pretty-printer for reachability graphs; and RGA, a reachability graph analyzer. These tools were shown to be useful in analyzing an alternating bit protocol [14] which had a reachability graph of over 1700 states. Using the net description of Appendix A, we generated a teachability graph of 74 states. The output generated by R G P consists of two parts: the reachability graph with states identified by state numbers and a list of states showing state numbers and labels of marked places; see Appendix B. We can see that state 3 is a successor to state 1. What we cannot easily see from the output is that state 3 also has a successor s t a t e - - t o keep arcs from completely cluttering the graph, states may appear in multiple places in the graph. We can also see from Appendix B that state 3 is interpreted as follows: Both entities A and B are in the A W A I T _ EST state and both entities have sent to each other S A B M _ C M D frames. Entity A's I_ frame

S.M. Shatz et al. / Formal modeling of the LAPD protocol

buffer currently has room for one I_ frame (i.e., only A can send an I_ frame and it can only have one outstanding I_ frame at a time). Also, neither entity has any "queued" control frames. The marked places A _ Q _ E M P T Y and B _ Q _ E M P T Y serve the purposes defined in the previous section. The size of the reachability graph grows rapidly as the number of senders and the initial marking in the B O U N D E R places increase. Single frame operation with both entities sending gives a reachability graph of 188 states. Placing 2, 3, 4, and 5 tokens in each B O U N D E R place generates a reachability graph with 878, 2973, 7718, and 16 740 states respectively. Given the reachability graph information, we can now discuss our analysis methods and results. 5.1. Internal Consistency Checks

Before we concern ourselves with analysis of the model for single frame-single sender operation in terms of its reflection on properties on LAPD, we first verify the "internal consistency of the model". In other words, we want to check that each reachable states' interpretation is consistent in terms of its 'use of certain places that have direct dependency relationships. For example, for each marking in which O K A S is not marked, either a place of the form A B X X should be marked (where XX is not I C M D _ P 1 or I C M D _ P0), or the place U P D A T E A Q should be marked. Some other tests on each marking are: (1) if A B O U N D E R is marked, then AB I C M D X is not marked (where X is 1 or 0), and vice versa; (2) if A Q E M P T Y is marked, t h e n Q AB_ XX is not marked (where X is not I C M D _ 1 or I_ C M D _ 0), and vice versa. Naturally, corresponding checks apply also for the case of entity B. Since we would want to make such consistency checks after each change to the model, we want some means for automated checks. While it is possible to use the R G A tool to help make these checks, we found the flexible pattern matching ability of the Unix tool Awk (and even the Vi editor) to be very well suited to this task. Only the state descriptions portion of the reachability re-

303

sults (consisting of 74 lines in the final version) was used for these pattern matches; information on state relationships is not important for this type of analysis. During early development of our model, this pattern match technique proved quite useful. It allowed us to find that no reachable state included the pattern " D M " , which would appear in labels for places corresponding to special frames called D M frames. In effect, this meant that our model did not need to include such a response since it could never be sent by our LAPD subset. This observation allowed us to simplify our model by removal of some transitions dealing with D M frames. The P-NUT tool R G A was used to determine if any other transitions in the model could not fire and were thus unnecessary. R G A takes as input the reachability graph generated by RGB and user supplied commands specified in the R G A language. The reachability graph is stored in the R G A in four sets: the set of all places ( P ) ; the set of all transitions (T); the set of all states (S); and the set of all arcs (A). The states in the graph consist of places with their markings. One or more arcs are used to connect each state with its successor state. The arcs indicate the source state, the destination state, and the transition(s) that fired to transform the source state into the destination state. The following user defined command returns the set of all transitions that fired in the reachability graph: tfires [a,b,c] :::=

b:={

);

forall a in A [c := tbegin(a); c := set(c); b := union(b,c); true]; b

The command ffires scans all the arcs in the reachability graph and uses the R G A function tbegin to return the sequence of transitions associated with this arc. This sequence is then converted to a set, the union is taken with the transitions found thus far, and the set is returned when all the arcs have been examined. The set of transitions that did not fire is found by subtracting the output of ffires from the set of all transitions T. Analysis of the model shows that when operating as single frame-single sender, 40 of the 74 transitions fire. When both entities are senders, all 74 transitions fire. Thus, the model as described in

304

S.M. Shatz et al. / Formal modeling of the LAPD protocol

Appendix A does not have any unnecessary transitions. This analysis did reveal some unnecessary transitions in an earlier version of this paper.

5.2. Boundedness We would expect our Petri net to be bounded for all analysis cases and safe for single frame cases. To check for safeness, we used the P - N U T tool RGA. R G A takes as input the reachability graph generated by R G B and user supplied commands specified in the R G A language. To test for safety, we can supply the following user c o m m a n d [14]: forall s in S [marked(s)

-- t o k e n s ( s ) ]

The set of all reachable states is denoted by the language defined variable. Thus, all reachable states are examined to see if the number of places marked equals the n u m b e r of tokens. This function returns a boolean result. The results show that our model is indeed safe for single frame cases. For multiple frame cases, the model is safe except for places X _ B O U N D E R , X X _ I _ C M D _ P0, X X _ I _ C M D _ P 0 _ A C K , and X _ I O U T . These places are not expected to be safe since in multiple frame operation, more than one I_ frame and thus its corresponding acknowledgment m a y be outstanding.

5.3. Deadlock / Termination To test for deadlock and termination states, we again use the R G A tool. We create a set that contains those reachable states which have no successor state. The following R G A c o m m a n d accomplishes this: ~tx({s m S Im~ts)

-- 0})

For each state identified, we try to justify that it is a normal termination state, otherwise it is an undesired deadlock state. For our model, the above c o m m a n d creates a set of 4 states. For example, one state identified is state 64, with the following description (obtained by the R G A function S h o w state (# 64)):

A _ Q _ E M P T Y , O K _ A _ S,A _ B O U N D E R , A _ PFLAG, B _ Q _ E M P T Y , O K _ B _ S, A_ STOP, B_ STOP

This state results from a normal disconnect (note the A _ S T O P and B _ S T O P places are marked). Another observation on this state is that A ' s poll flag is "on", implying that A has sent a poll c o m m a n d but has not received the corresponding response. By using the R G A function SUCC (to find successor states), we can trace back from this state and find that this termination state is the final state in a chain of 11 states from the initial state. Examination of this chain shows that A issued the disconnect via a D I S C _ C M D , which resulted in its poll flag being set. Since the L A P D specification does not call for this flag to be reset upon acceptance of B ' s U A _ RSP frame, the connection termination state always has the poll flag " o n " for the entity that issues the disconnect command. The other three termination states occur as follows: - State 67: Termination due to entity B sending the D I S C _ CMD. - State 71: Termination due to both entities sending a D I S C CMD. Each entity accepts the other's D I S C _ C M D , sends a U A _ R S P and enters the " s t o p " state. The U A _ R S P frames remain outstanding at termination. In LAPD, these frames would be "eaten" by each entity upon return to the TEI A S S I G N state. - State 72: Termination due to entity B sending a D I S C _ C M D and "eating" one of A's I_ frames while in the A W A I T _ R E L state. This state is different than state 67 since both entities poll flags are " o n " at t e r m i n a t i o n - - B ' s from sending the D I S C C M D and A ' s from sending an I _ C M D with the poll bit "on". In LAPD, the poll bits would be reset when the entities return to the M F _ E S T _ N O R M state. Our analysis shows that all detected "deadlock" states are actually proper termination states. We can see that both entities have equal potential for initiating termination and that all outstanding frames, and entity flag values, defined at termination are properly handled upon return to the initial state. For multiple frame cases, the same four deadlock states exist. However, the marking of the B O U N D E R places at deadlock reflect the initial marking of the B O U N D E R places. This is the expected result.

S.M. Shatz et al. / Formal modeling of the LAPD protocol

6. Some Performance Modeling and Analysis Results In this section we illustrate how our LAPD model can be extended to support performance analysis. We do this by presenting, discussing, and analyzing a Timed Petri net model of LAPD's connection establishment procedure. The intent here is to illustrate the process of using the Timed Petri net model to extend our general net model.

6.1. Model Development The connection establishment process is described in Section 3 for the case when we ignore the timers and retry counter. In this section we briefly discuss the process taking into account the timers and counters. Initially it is assumed that both the communicating entities A and B are in their T E I _ A S S I G N states and we only consider the case of entity A initiating the establishment of a connection. Entity .4 initiates the connection establishment by sending SABM command to entity B and goes into A W A I T _ E S T state. Entity A also resets its retransmission counter, N200, to the default value of 3 and resets its acknowledgement timer, T200, to the default value of 1 s (1000 ms). There are two possible results: either the SABM message is lost or it is delivered. If the message is lost, entity .4 tries again after the time-out period. If B receives the SABM command when it is in the T E I _ A S S I G N state, it goes into the N O R M A L state and sends the U A _ R S P to A, acknowledging the receipt of .4's message. But now the acknowledgment also has a possibility of being lost. If the acknowledgment is lost, then A again transmits the SABM command after the time-out period. If the acknowledgment is received, A is in the A W A I T _ EST state and the time-out counter has not expired, A receives the acknowledgment and goes into its N O R M A L state. It also resets the retransmission counter to zero. At this point the connection has been established and both A and B are in their N O R M A L states. Now suppose that either the command or response is lost in transmission. Then after the timer T200 expires, entity A has two options. If A has not yet retransmitted for N200 times, it retransmits the SABM command while remaining in the A W A I T _ EST state. But if it has retransmitted the

305

command for the maximum number of times, then entity A goes into the T E I _ A S S I G N state and it informs the layer above the protocol that it could not establish the connection. For entity B, if it has already received the SABM command and it is in the normal state (this happens when B's acknowledgment to A is lost), then upon receipt of the duplicate SABM command, B stays in the same state and resends the UA_ RSP to entity A. Once both entities are in their normal states, they can proceed with the information transfer process. To build our Timed Petri net model, we need some timing information. First, to calculate the point-to-point transmission time, we need the transmission rate and the frame size. LAPD connection establishment uses the D channel for control and signaling at the rate of 16 kbits/s [3]. For unnumbered frames (which includes the SABM commands and the UA_ RSP responses) the frame size is 7 bytes. So the transmission time is (78 ) / ( 1 6 . 1000)= 3.5 ms. Secondly, the acknowledgment timer, 1"200, defines the maximum length of time allowed for a response, 1 second. For our "experiments" we assumed that 5% of the time either a frame is lost or the acknowledgment is lost and 95% of the time error-free transmission occurs [15]. Finally, we have rather arbitrarily assumed 10 ms as the time for processing a message or an acknowledgment. This means that it takes ten ms to process a received message and send the appropriate response. To perform performance analysis we extend our basic Petri net described in Section 2. We use a Timed Petri net model as defined by Razouk and Phelps [15]. Every transition in the net is labeled by a vector of three values, (Enabling time, Firing time, Firing probability). The enabling time is the amount of time for which the transition must remain enabled before it starts firing. The firing time is the time required to produce tokens in the output places of a transition once the transition begins firing. The firing probability gives the relative firing probability of the transition when it is enabled at the same time that other transitions are also enabled and these transitions share some common input place (i.e., the transitions are in conflict). A transition with a firing probability of zero will fire only if no other transitions are in conflict with it. Figure 5 is a graphical view of our timed net model for LAPD's connection establishment. The

306

S.M. Shatz et a L / Formal modeling of the LAPD protocol

tll ~'DL REL_INDICATIONA (0f,0)/

(~ DL_EST.RE~UEST A ((o,o,loo)

I ~ (0'tO~01 ) T200_EXP~D ~" (j~ ~ A NORMAL \ II~

(" ' ~ •

\

,o.,o.,oo,

Io,lo,l

\

o

~

\

~

_ ___

~

AT ,.~)" ,~11"~i - (0t'0'l100) I '( ,,)SEND-AB-SIABM CMD ,~d,,,,~(1000'0'100) / N_200

-f-.o i

J

/

__t2

/ ,o,o,,oo,

II

/ ~A AWAITEST (~

RECEtVE BA UA RSr'

- - -

(0,3.~1 I

SENTBAUA[SP(~3.5

13i~

) i

V , SENT-AB-SABId-CMD

(~ RECEIVE_AB_SABM_CMD

~

B_TEI_ASSIGN

(0,10,100) ~'~(~B Fig. 5. A

NORMAL

timedPetrinetmodelforLAPD'sconnectionestablishment.

initial marking for this net is one token in the two places A _ T E I _ A S S I G N and D L _ E S T _ R E Q U E S T _ A . Transitions t3 and t7 model the loss of the SABM c o m m a n d and the loss of a U A _ RSP response, respectively. Note that both transitions require zero enabling time, but require 3.5 time units (ms) of firing time. Also, they both have firing probabilities of 5%. For example, when the place S E N T _ A B _ S A B M _ C M D is marked, both transitions t3 and t4 are enabled, but t3 has a 5% chance of firing and t4 has a 95% chance of firing. Transition t l 0 models the acknowledgment timer - - i t has an enabling time of 1 second. If neither an SABM c o m m a n d nor its acknowledgment are lost, then transition t9 will become enabled before t l 0 ' s enabling time expires. When t9 fires, it uses 10 ms (to signify U A _ RSP processing time).

6.2. Some Analysis Observations Using automated tools we collected 86 traces (simulations) of the timed Petri net's execution. These traces, or firing sequences, showed both cases of "error-free" connection establishment as well as cases when messages were lost and resent. Specifically, we captured traces for four cases: no loss, SABM lost once, U A _ R S P lost once, and U A _ RSP lost twice. Our data easily showed that the minimum time for connection establishment is 27 ms. As expected, this occurred when there were no transmission errors and thus no retrys. This time can be easily verified: it is due to 7 ms of SABM and U A _ R S P transmission time and 20 ms of SABM and U A _ RSP processing time (each takes 10 ms). We also found, not surprisingly, that

S.M. Shatz et al. / Formal modeling of the LAPD protocol

the m a x i m u m time for connection establishment is when there are transmission losses and the acknowledgment is not received until after three retransmissions. This m a x i m u m connection time was 3027 ms (including transmission time, processing time and time-out periods). The simulations also showed that as far as connection establishment is concerned both the message loss and the acknowledgment loss have equivalent impact, but in terms of transition firings, more transitions are fired when there is an acknowledgment loss. F r o m our simulations, we observed that the time spent processing of the SABM message or acknowledgment is 74% when there is no message loss. When one SABM c o m m a n d is lost the percentage processing time is 2%; when there is one acknowledgment loss the percentage is 3% and when two acknowledgments are lost it is again about 3%. For our 86 simulations, the average time spent in processing was about 67%. These values depend on our assumed value of the processing rate for both entities. For the case of loss-less transmission, we observed the percent time due to transmission is 26% (this is expected from the 74% processing time mentioned above). It is 1% for the case of one message loss, 1.4% when an acknowledgment is lost and 1.03% for two acknowledgment losses. For our 86 simulations, the average time spent in transmission comes to about 23%. Another metric that we can observe from our timed net analysis is the percent time that particular places are marked. By observing that the place labeled A_ A W A I T _ EST is marked for 63% of the simulation time in the no-loss case, we see that entity A spends most of its time waiting for a connection reply. As there are more losses, the time spent in this state increases. It becomes 99% when there is either a message loss or an acknowledgment loss. It increases to 99.5% when there are two acknowledgment losses. For our particular

simulations, the average percent time A spends in its A W A I T _ EST state is almost 67%. Similarly for entity B, we observe that it spends most of its time in one of the two states, T E l _ A S S I G N or N O R MAL. For the no-loss case B is in either of these two states 63% of the time, while for 37% of the time it is busy firing transition t5, implying processing of A's SABM command. Similar percentages occur for cases of lost messages.

7. Conclusion We have discussed our experiences in developing and analyzing a Petri net model for the data link layer protocol LAPD. In particular, we considered a subset of L A P D which consists of connection establishment, normal information frame transfer, and connection release. The key modeling problems we encountered were explained and our associated modeling methods were described. Our resulting Petri net model was analyzed using some powerful Petri net tools based on reachability analysis. We discussed the analysis in terms of internal consistency of the model, boundedness (actually safeness), deadlock and termination. We also presented and discussed a Timed Petri net model for the connection establishment procedure. This illustrated how time values, counters, and timers can be incorporated into our Petri net model for the purpose of performance analysis.

Acknowledgment We wish to thank Dr. Pramode Verma for his encouragement and suggestions during the course of this work. We also thank Mr. Ding-Gang Xie for his work on an earlier model of the protocol and Dr. R. Razouk for providing us with the Petri net tools.

Appendix A. Petri Net Production Description of LAPD Subset :tl: :t2: :t3: :t4:

307

A _ T E I _ A S S I G N ---,A _ A W A I T _ E S T , A B _ S A B M _ C M D , A _ Q _ E M P T Y A_ T E I _ A S S I G N , B A _ SABM_ C M D ---, A _ NORM,AB _ U A _ R S P , U P D A T E _ B _ Q,A _ Q _ E M P T Y A_AWAIT_EST,BA_UA_RSP ~ A_NORM,UPDATE_ B_Q A _ A W A I T _ EST,BA _ SABM _ C M D , O K _ A_ S(0),A _ Q _ E M P T Y A _ A W A I T _ E S T , U P D A T E _ B _ Q,Q _ AB _ U A _ RSP

S.M. Shatz et al. / Formal modeling of the LAPD protocol

308 :t4a:

A_ AWAIT_

EST, BA _ SABM _ CMD,OK_

A_AWAIT_EST, :t5:

UPDATE

A_ BOUNDER,A_ A _ NORM,A

B

NORM,A_

_ PFLAG,AB

:t6:

A _ BOUNDER,A

:t7:

A_ NORM,BA_

:t8:

A _ NORM,A

A _ NORM,AB

_ I _ CMD

_ PFLAG(0),OK_

_ P0,OK_

A _ NORM,

:t9a:

RR_ CMD

_ P1,OK_

A _ S,A _ IOUT

A _ NORM,BA

_ I _ CMD

_ P1,OK _ A _ S -o A _ NORM,AB

:tl0a:

A _ NORM,BA

_ I _ CMD

_ P1 _ ACK,OK_

AB _ I _ CMD :tlla:

A _ NORM,BA

_ I _ CMD

A _ NORM,BA

_ I _ CMD

A_BOUNDER,AB_ :tllc:

A _ NORM,BA

_ I _ CMD

:t12:

A_ NORM,BA_

--,

_ PFLAG(0),OK_

_ NORM,OK_

_ P0,A _ BOUNDER,A NORM,OK

_ PFLAG(0),OK_

A _ S --,

_ BOUNDER,A

_ PFLAG(0),OK_

A _ S,A _ IOUT

PI_ACK,A_PFLAG,A_NORM,OK_A_

_ P0 _ ACK,A

_ BOUNDER,A

P0,A_ PFLAG(0),OK_

---,

S,A_IOUT

_ PFLAG(0),OK_

I_CMD_P0_ACK,A_NORM,OK_A_ I _ CMD_

A _ S --o

A _ S,A _ IOUT

_ A _ S,A _IOUT

_ P0 _ ACK,A

I_CMD_

A_BOUNDER,AB_

_ RR_ RSP _ F1 _ ACK

A _ S,A _IOUT

_ RR_ RSP _ F1 _ ACK

PFLAG,A

_ P0 _ ACK,A_

--,

B _ Q,AB _ RR_ RSP _ F1 _ NOACK

_ P0,A _ BOUNDER,A

_ P1 _ ACK,A_

AB _ I _ CMD :tllb:

UPDATE_

_ NORM,AB _ I _ CMD

_ IOUT

--,

:tl0:

A _ NORM,BA

Q

B _ Q,Q _ AB _ RR_ RSP_ F1 _ NOACK

BOUNDER,

A _ BOUNDER,A

B

--o

A _ S(0),A _ Q _ EMPTY,A

A _ NORM,A_

:tll:

_ NORM,UPDATE

_IOUT

B_Q

_ P1,OK_

_ BOUNDER,UPDATE_

A _ NORM,BA_

-o A_ BOUNDER,A

_ RR_ RSP _ F1 _ ACK,A

BA _ RR_ CMD

A _ NORM,A

A _ S --,

A _ S,A _IOUT

A_NORM,A_BOUNDER,UPDATE_ :t9:

A _ S --,

_ P1,OK _ A _ S,A _ IOUT

RR_ RSP_ F0,A_ IOUT _ PFLAG,BA

RSP

PFLAG(0),OK_

_ NORM,A _ I _ CMD

A _S

Q,AB_UA

A _ S,A _ IOUT

----,

S,A_IOUT

A _ S ---,

A_NORM,AB_RR_CMD_P1,A_PFLAG :t12a:

A _ NORM,BA

_ I _ CMD

A _ BOUNDER,A

_ P0 _ ACK,A

_ NORM,AB

_ PFLAG(0),OK_

_ RR _ CMD

:t13:

A_ NORM,BA_

I _ CMD_

P0,A_ PFLAG(0),OK_

:tl3a:

A_ NORM,BA_

I_ CMD_

P0_ ACK,A_

A_BOUNDER,A_NORM,AB_RR_ _ I _ CMD

_ P0,A _ PFLAG,OK_

:tl4a:

A _ NORM,BA

_ I _ CMD

_ P0 _ ACK,A

_ NORM,AB

A_ NORM,BA_

:t16:

B_ TEI_ ASSIGN

:t17:

B_ TEI_ ASSIGN,AB B _ NORM,BA

RR_ RSP_ F1 _ NOACK,A_ --, B _ A W A I T _ _ SABM_

CMD

_ UA _ RSP,UPDATE

EST,AB _ SABM _ CMD,OK

:t21:

UA_ RSP ~

B _ NORM,UPDATE_

B _ AWAIT_

EST,UPDATE_

B _ AWAIT_

EST,AB _ SABM _ CMD,OK

B_ BOUNDER, B _ NORM,BA

A_ Q

_ B _ S(0),B _ Q _ EMPTY _ B _ S ---,

A _ Q,BA _ UA _ RSP

B _ NORM,B_

PFLAG(0),OK_

BA _ I _ CMD

B_ NORM,B _ I _ CMD

_ P1,OK_

_ PFLAG(0),OK_

_ P0,OK_

B _ S --o B _ S,B _ IOUT B _ S ---,

B _ S,B _ IOUT

:t22:

B _ NORM,AB_

:t23:

B_ NORM,B

_ PFLAG,AB

B_NORM,B_

BOUNDER,

UPDATE_A_Q

:t24:

B _ NORM,AB

_ RR_ CMD

_ P1,OK _ B _ S(0),B _ Q _ EMPTY,B

B _ NORM,B

RR_ RSP_ F0,B _IOUT

_ BOUNDER,

B_Q

Q_ EMPTY

A _ Q,Q _ BA _ UA _ RSP

_ EST,UPDATE_ _ PFLAG,

~ A_ NORM,UPDATE_ CMD,B_

A _ Q,B _ Q _ EMPTY

B _ AWAIT_

B _ NORM,B

_ RR_ RSP_ F0,A _ PFLAG --o

-o

:t19:

B_ BOUNDER,

A _ S,A _IOUT

PFLAG

EST, BA_ SABM_

EST,AB_

:t20:

-o

_ RR_ RSP _ F0,A _ PFLAG

B _ AWAIT_

B _ AWAIT

A _ S --o A _ N O R M , A B

_ PFLAG,OK_

:t18:

:tl9a:

_ RR_ RSP_ F0

A_ S,A_ IOUT

RSP_ F0

A _ NORM,BA

:t15:

-.o

A _ S --o A _ N O R M , A B

PFLAG(0),OK_

:t14:

A _ BOUNDER,A

A _ S,A _ IOUT

_ P1,A _ PFLAG

--, B _ B O U N D E R ,

_ RR_ RSP_ F1 _ ACK,B

UPDATE_

B _ NORM,UPDATE_

_IOUT _ 1OUT

---,

A _ Q,Q _ BA _ RR_ RSP _ F1 _ NOACK

A_ Q

S.M. Shatz et al. / Formal modeling of the LAPD protocol

309

:t24a: B _ N O R M , A B _ R R _ C M D _ P1 , O K _ B _ S,B _ 1 O U T --* B_NORM,B_BOUNDER,

:t25:

B _ NORM,AB

UPDATE_

RR_RSP_FI_NOACK

A_ Q, BA_

_ I _ C M D _ P1 , O K _ B _ S ~ B _ N O R M , B A _ R R _ R S P _ F 1 _ A C K

:t25a: B _ N O R M , A B _ I _ C M D _ P1 _ A C K , O K _ B _ S,B _ 1 O U T --* B _ BOUNDER, B _ NORM,BA _ RR_ RSP_ F1 _ ACK B _ N O R M , A B _ I _ C M D _ P 0 , B _ B O U N D E R , B _ P F L A C r ( 0 ) , O K _ B _ S --* :t26: BA :t26a:

I

C M D _ P1 _ A C K , B _ P F L A G , B _ N O R M , O K _

B_ NORM,AB_ BA

I

B _ S,B _ 1 O U T

I_ CMD_ P0,B_ BOUNDER, B_ PFLAG(0),OK_ B_ S

CMD_P0_ACK,

B_NORM,OK_B_S,B_IOUT

P0_ACK, B_BOUNDER,B_IOUT,B_ PFLAG(0),OK_ B_ S :t26b: B_NORM,AB_I_CMD_ B _ B O U N D E R , B _ I O U T , B A _ I _ C M D _ P1 _ A C K , B _ P F L A G , B _ N O R M , O K _ B _ S :t26c:

B_NORM,AB_I_CMD_

P0_ACK,B_BOUNDER,

B_IOUT,B_ PFLAG(0),OK_

B_ BOUNDER, B_ IOUT, BA_ I_ CMD_ P0_ ACK,B_ NORM,OK_ :t27:

B_NORM,AB_I_CMD_

P0,B_PFLAG(0),OK_

B_ S

B_ S

B_S

B _ NORM,BA _ RR_ CMD _ P1,B _ PFLAG B_ NORM,AB_

I _ C M D _ P 0 _ A C K , B _ P F L A G ( 0 ) , O K _ B _ S , B _ 1 O U T ---,

B_BOUNDER,

B_NORM,BA_R-R_CMD_P1,B_PFLAG

:t28:

B_ NORM,AB_

I _ CMD_ P0,B_ PFLAG(0),OK_ B_ S ~ B_ NORM,BA_

:t28a:

B _ N O R M , A B _ I _ C M D _ P 0 _ A C K , B _ P F L A G - ( 0 ) , O K _ B _ S,B _ 1 O U T -~

:t27a:

RR_ RSP_ F0

:t29:

B _ BOUNDER,

B _ NORM,BA _ RR_ RSP_ F0 B _ NORM,AB _ I _ CMD _ P0,B _ PFLAG,OK_ B _ S ~ B _ NORM,BA _ RR_ RSP _ F0,B _ PFLAG

:t29a:

B _ N O R M , A B _ I _ C M D _ P0 _ A C K , B _ P F L A G , O K _

B _ S,B _ I O U T

B _ BOUNDER,

B _ NORM,BA_

:t30:

B_ NORM,AB_

R R _ R S P _ F1 _ N O A C K , B _ P F L A G ~ B_ N O R M , U P D A T E _

:t31:

A_ NORM,OK_

A_ S,A_ PFLAG,A _ 1OUT(0) ~ A _ AWA IT_ REL,AB _ DISC _ CMD,A _ PFLAG

:t31a: A _ N O R M , O K _ A _ AWAIT

RR_ RSP_ F0,B _ PFLAG

A _ S , A _ P F L A G - ( 0 ) , A _ l O U T ( 0 ) -~

REL,AB _ DISC_ CMD,A _ PFLAG

:t32:

A_ AWAIT_ REL,BA_ UA_ RSP ~ A_ STOP,UPDATE_

:t33:

A_ NORM,BA_

B _ NORM,OK_

B_Q

DISC _ CMD,OK_ A _ S(0),A_ Q _ EMPTY,A _ lOUT(0)

A _ STOP, UPDATE_ :t33a: A _ N O R M , B A _ B _ NORM,OK_ :t34: :t34a:

A_ Q

B _ Q,Q _ AB _ UA_ RSP

DISC _ CMD,OK_ A_ S,A_ 1OUT(0) ~ A _ STOP, UPDATE_

B _ Q,AB _ UA _ RSP

B _ S,B _ P F L A G , B _ 1 O U T ( 0 ) ~ B _ A W A I T _ R E L , B A _ D I S C _ C M D , B _ P F L A G B _ S,B _ P F L A G ( 0 ) , B _ 1 O U T ( 0 )

B _ AWAIT_ REL,BA_ DISC_ CMD,B _ PFLAG :t35:

B _ A W A I T _ R E L , A B _ U A _ R S P -~ B _ S T O P , U P D A T E _

:t36:

B _ NORM,AB _ DISC _ CMD,OK_ B _ STOP, UPDATE_

A_ Q

B _ S(0),B _ Q _ E M P T Y , B _ I O U T ( 0 )

A _ Q,Q _ BA _ UA_ RSP

:t36a:

B_ NORM,AB_

DISC_ CMD,OK_

:t37:

A _ A W A I T _ R E L , B A _ D I S C _ C M D , O K _ A _ S(0),A _ Q _ E M P T Y A _ STOP,UPDATE_

B _ S,B _ I O U T ( 0 ) ~ B _ S T O P , U P D A T E _

A_ Q,BA_ UA_ RSP

B _ Q,Q _ AB _ UA _ RSP

:t37a: A _ A W A I T _ R E L , B A _ D I S C _ C M D , O K _ A _ S -~ A _ S T O P , U P D A T E _ B _ Q , A B _ U A _ R S P B _ A W A I T _ R E L , A B _ D I S C _ C M D , O K _ B _ S(0),B _ Q _ E M P T Y - o :t38: B _ STOP,UPDATE_

A _ Q,Q _ BA _ UA _ RSP

: t 3 8 a : B _ A W A I T _ R E L , A B _ D I S C _ C M D , O K _ B _ S --* B _ S T O P , U P D A T E _ A _ Q , B A _ U A _ R S P A _ A W A I T _ R E L , B A _ R R _ R S P _ F1 _ N O A C K -o A _ A W A I T _ R E L , U P D A T E _ B _ Q :t39: :t40: :t41:

A _ AWAIT_ REL, BA_ I _ CMD _ P1,B _IOUT ~ A _ AWAIT_ REL, B _ BOUNDER A _ A W A I T _ R E L , B A _ I_ C M D _ P0,B _ 1 O U T ~ A _ A W A I T _ R E L , B _ B O U N D E R

:t42:

B_ A W A I T _ R E L , A B _ R R _ R S P _ F1 _ N O A C K

:t43:

B_ AWAIT_ REL,AB_ I _ CMD_ P1,A_ IOUT ~ B _ AWAIT_ REL,A_ BOUNDER

:t44:

B_ AWAIT_ REL,AB _ I _ CMD_ P0,A_ 1OUT ~ B _ AWAIT_ REL,A_ BOUNDER

:t45:

U P D A T E _ A _ Q , Q _ A B _ R R _ R S P _ F1 _ N O A C K

~ B _ AWAIT_ REL,UPDATE_

A_ Q

-~ A B _ R R _ R S P _ F 1 _ N O A C K , A _

Q_ EMPTY

S.M. Shatz et al. / Formalmodeling of the LAPD protocol

310

:t46: U P D A T E _ A Q , Q _ A B _ U A _ R S P , A _ I O U T ( 0 ) - ~ A B _ U A _ R S P , A _ Q _ E M P T Y :t47: U P D A T E A Q,OK A_S(0),A Q E M P T Y ~ O K _ A S,A Q E M P T Y :t48: U P D A T E _ B Q,Q BA R R RSP F1 N O A C K - ~ BA R R RSP F1 N O A C K , B _ Q E M P T Y :t49: U P D A T E _ B_ Q,Q_ BA _ U A _ RSP, B _ IOUT(0) ~ BA _ U A _ RSP,B _ Q _ E M P T Y :t50: U P D A T E B Q,OK B S ( 0 ) , B _ Q _ E M F r Y ~ O K B _ S , B _ Q E M P T Y CA_TEI_ASSIGN,B_TEI_ASSIGN,A_BOUNDER)

Appendix B B.1. Reaehability Graph for Model of L A P D Subset 0->2->5->I0->15->21

- > 3 0 - > 4 2 - > 5 1 ->60->67"

I

I

I

+- >50 - >60

I

I

I

+->59->67"

I +- >41

**

- >49-

I

I

I

I

I

+- > 5 6 - > 6 6 - >71"

I I I

I I I

I +->5

+- >23 - >4

I +- >32 - >9 +->11 - > 1 7 - > 2 4

I I

I I I +->16 +->6->12->17

I +->11 +->1 ->4

I

- >71 *

I +->65

Note that middle portion of the graph

I I I

+->3

>58 - >65

I +->25->33->I0

I +->5

is not shown

S.M. Shatz et al. / Formal modeling of the LAPD protocol

311

B.2. State Descriptions (By Place Markings) for LAPD Subset 0. 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27.

A _ TEL _ ASSIGN,A_ BOUNDER, B _ TEI _ ASSIGN A_ AWAIT_ EST,AB_ SABM_ CMD,A_ Q_ EMPTY,A_ BOUNDER,B_ TEI_ ASSIGN A_ TEI _ ASSIGN,BA_ SABM_ CMD,A_ BOUNDER, B_ A W A I T EST, B _ Q_ EMPTY A_ AWAIT_ EST,AB_ SABM_ CMD,A_ Q_ EMPTY,BA_ SABM_ CMD,A_ BOUNDER, B _ A W A I T EST,B _ Q_ EMPTY A AWAIT_EST,A Q EMPTY,BA UA RSP,A BOUNDER, B Q EMPTY,B NORM, U PDATE _ A = Q A_ Q_ EMPTY,A_ NORM,AB_ UA_ RSP,UPDATE_ B_ Q,A_ BOUNDER, B_ AWAIT_ EST, B Q_EMPTY A_ AWAIT EST,AB _ SABM_ CMD,UPDATE_ B_ Q,Q_ AB _ UA _ RSP,A_ BOUNDER, a AWAIT_ EST, B_ Q_ EMPTY A_ A W A I T EST,A_ Q_ EMPTY,BA_ SABM_ CMD,A_ BOUNDER, B_ AWAIT_ EST, UPDATE_ A _ Q,Q _ BA_ UA _ RSP A_ Q_ EMPTY,A N O R M , U P D A T E _ a _ Q,A_ BOUNDER, B_ Q _ EMPTY, B _ NORM, UPDATE_ A_ Q A_ AWAIT_ EST,A_ Q_ EMPTY,BA_ UA_ RSP,OK_ A_ S,A_ BOUNDER, B_ Q_ EMPTY, BNORM A_ Q_ EMPTY,A_ NORM,AB_ UA_ RSP,A_ BOUNDER, B_ AWAIT_ EST, B_ Q_ EMPTY, OK B S A_ AWAIT_ EST, UPDATE_ B_ Q,Q_ AB_ UA_ RSP,A_ BOUNDER, B_ AWAIT_ EST, UPDATE_ A_ Q,Q _ BA_ UA _ RSP A_ AWAIT_ EST,AB_ SABM_ CMD,Q_ AB_ UA_ RSP,A_ BOUNDER, B_ AWAIT_ EST, B _ Q_ EMPTY,OK_ B _ S A _ A W A I T EST,A _ Q _ EMPTY,BA _ SABM _ CMD,OK _ A _ S,A _ BOUNDER, B _ AWAIT _ EST, Q_ BA_ UA_ RSP A_ Q _ EMPTY,A_ NORM,UPDATE_ B_ Q,OK_ A_ S,A_ BOUNDER, B_ Q_ EMPTY,B_ NORM A_ Q_ EMPTY,A_ NORM,A_ BOUNDER, B_ Q_ EMPTY,B _ NORM,UPDATE_ A_ Q,OK_ B _ S A _ AWAIT_ EST,A _ Q_ EMPTY,AB _ U A ' RSP, UPDATE_ B _ Q,A _ BOUNDER, B _ AWAIT_ EST, Q_ BA_ UA_ RSP A_ AWAIT_ EST, BA_ UA_ RSP,Q_ AB_ UA_ RSP,A_ BOUNDER, B_ AWAIT_ EST, B _ Q _ EMPTY,UPDATE_ A_ Q A_ Q_ EMPTY,A_ NORM,UPDATE_ B_ Q,OK_ A_ S,A_ PFLAG,AB_ I _ CMD_ P1,A_ IOUT, B_ Q_ EMPTY,B_NORM A_ Q_ EMPTY,A_ NORM,UPDATE_ B_ Q,OK_ A_ S,A_ IOUT,AB_ I_ CMD_ P0,B_ Q_ EMPTY, BNORM A_ Q_ EMPTY, UPDATE_ B_ Q,A_ BOUNDER,A_ PFLAG,B_ Q_ EMPTY,B_ NORM, A _ AWAIT_ REL,AB _ DISC _ CMD A_ Q_ EMPTY,A_ NORM,OK_ A_ S,A_ BOUNDER, B_ Q_ EMPTY,B_ NORM,OK_ B_ S A_ Q_ EMPTY,A_ NORM,A_ BOUNDER, B_ Q_ EMPTY,UPDATE_ A_ Q,B_ PFLAG, BA_DISC_CMD,B_AWAIT_REL A_ AWAIT_ EST,A_ Q_ EMPTY,UPDATE_ B_ Q,A_ BOUNDER, B_ NORM,UPDATE_ A_ Q, Q_BA_UA_RSP A_ AWAIT_ EST,A_ Q_ EMPTY,AB_ UA_ RSP, BA_ UA_ RSP,A_ BOUNDER, B _ AWAIT_ EST,B _ Q _ EMPTY A_ NORM, UPDATE_ B_ Q,Q_ AB_ UA_ RSP,A_ BOUNDER, B_ AWAIT_ EST,B_ Q_ EMPTY, UPDATE_ A_ Q A Q_EMPTY,A NORM,OK A_S,A_PFLAG,AB I CMD P1,A IOUT,B_Q EMPTY, B_ NORM,OK_ B_ S A_ Q_ EMPTY,A_ NORM,OK_ A_ S,A_ IOUT,AB_ I_ CMD_ P0,B_ Q_ EMPTY,B_ NORM, OK B S

312 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53.

S.M. Shatz et al. / Formal modeling of the LAPD protocol

A_ Q_ EMtrI'Y,UPDATE_ B_ Q,A_ BOUNDER,A_ PFLAG,UPDATE_ A_ Q,Q_ BA_ UA_ RSP, A_ AWAIT_ REL,B _ STOP A_ Q_ EMPTY,A_ BOUNDER,A_ PFLAG,B_ Q_ EMPTY,B_ NORM,OK_ B_ S,A_ AWAIT_ REL, AB_DISC_CMD A_ Q_ EMPTY,A_ NORM,OK_ A_ S,A_ BOUNDER, B _ Q_ EMPTY,B_ PFLAG,BA_ DISC_ CMD, B _ AWAIT_ REL UPDATE B Q,Q_AB_UA_RSP,A_BOUNDER,B_Q_EMPTY,UPDATE_A_Q,B_PFLAG, A_ STOP,B _ AWAIT_ REL A_ AWAIT_ EST,A_ Q_ EMPTY,UPDATE_ B_ Q,OK_ A_ S,A_ BOUNDER,B_ NORM, Q_BA_UA_RSP A_ NORM,Q_ AB_ UA_ RSP,A_ BOUNDER, B_ AWAIT_ EST, B_ Q_ EMPTY,UPDATE_ A_ Q, OK_ B _ S A_ Q_ EMPTY,A_ NORM,OK_ A_ S,A_ PFLAG,A_ IOUT, BA_ RR_ RSP_ F1 _ ACK, B _ Q_ EMPTY,B_ NORM A_ Q_ EMPTY,A_ NORM,OK_ A _ S,A_ PFLAG,AB _ I _ CMD_ P1,A_ IOUT,B _ Q_ EMPTY, B _ PFLAG,BA _ DISC_ CMD,B _ AWAIT_ REL A_ Q_ EMPTY,A_ NORM,OK_ A_ S,A_ IOUT,BA_ RR_ CMD_ P1,B _ Q_ EMPTY,B _ NORM, B_ PFLAG A_ Q_ EMPTY,A_ NORM, OK_ A_ S,A_ IOUT, BA_ RR_ RSP_ F0,B _ Q_ EMPTY,B _ NORM A_ Q_ EMPTY,A_ NORM,OK_ A_ S,A _ IOUT,AB_ I _ CMD _ P0,B _ Q_ EMPTY,B_ PFLAG, BA_ DISC_ CMD,B _ AWAIT_ REL A_ Q_ EMPTY,UPDATE_ B_ Q,OK_ A_ S,A_ BOUNDER,A_ PFLAG,Q_ BA_ UA_ RSP, A_ AWAIT_ REL,B_ STOP A_ Q_ EMP TY, B A _U A _R SP, A _B O U N D E R, A _PFL A G , B_Q _E MPT Y , U PD A T E A Q, A _ AWAIT_ REL,B _ STOP A_ Q_ EMPTY,A_ BOUNDER,A_ PFLAG,B_ Q_ EMPTY,B_ PFLAG,A_ AWAIT_ REL, AB_ DISC_CMD,BA_DISC_CMD,B_AWAIT_REL A_ Q_ EMPTY,AB__ UA_ RSP,UPDATE_ B_ Q,A_ BOUNDER, B_ Q_ EMPTY,B_ PFLAG, A _ STOP, B _ AWAIT_ REL Q_ AB_ UA_ RSP,A_ BOUNDER,B_ Q_ EMPTY,UPDATE_ A_ Q,OK_ B_ S,B_ PFLAG,A_ STOP, B _ AWAIT_ REL A_ Q_ EMPTY,A_ NORM,OK_ A_ S,A_ BOUNDER,A_ PFLAG,B_ Q_ EMPTY,B_ PFLAG, BA _ DISC_ CMD,B _ AWAIT_ REL A_ Q_ EMPTY,A_ NORM,UPDATE_ B_ Q,A_ BOUNDER,AB_ RR_ RSP_ F1 _ NOACK, B _ Q_ EMPTY,B _ NORM,B _ PFLAG A Q_ EMPTY, BA_ UA_ RSP,OK_ A_ S,A_ BOUNDER,A_ PFLAG,B_ Q_ EMPTY, A _ AWAIT_ REL,B _ STOP A_ Q_ EMPTY,UPDATE_ B_ Q,A_ BOUNDER,A_ PFLAG, B_ Q_ EMPTY,UPDATE_ A_ Q, A_ STOP, B_ STOP UPDATE_ B_ Q,Q_ AB_ UA_ RSP,A_ BOUNDER,A_ PFLAG,B_ Q_ EMPTY,B_ PFLAG, AB _ DISC _ CMD,A _ STOP, B _ AWAIT_ REL A_ Q_ EMPTY,A_ BOUNDER,A_ PFLAG, UPDATE_ A_ Q,Q_ BA_ UA_ RSP,B_ PFLAG, A _ AWAIT_ ILEL,BA_ DISC _ CMD,B _ STOP A_ Q_ EMPTY,UPDATE_ B_ Q,A_ BOUNDER,B_ Q_ EMPTY,UPDATE_ A_ Q,B_ PFLAG, A_ STOP,B_ STOP A_ Q_ EMPTY,AB_ UA_ RSP,A_ BOUNDER, B _ Q_ EMPTY,OK_ B_ S,B_ PFLAG,A_ STOP, B _ AWAIT_ REL A_ Q_ EMPTY,AB_ UA_ RSP,UPDATE_ B_ Q,A_ BOUNDER,A_ PFLAG,B_ Q_ EMPTY, B _ PFLAG,A _ STOP,B _ AWAIT_ REL A_ Q_ EMPTY,A_ NORM,A_ BOUNDER,AB_ RR_ RSP_ F1 _ NOACK, B_ Q_ EMPTY,B_ NORM, OK_ B_ S,B_ PFLAG

313

S.M. Shatz et al. / Formal modeling of the LAPD protocol 54.

A_ Q _ EMPTY,UPDATE_

B _ Q,OK _ A _ S,A _ BOUNDER,A

_ PFLAG,B

_ Q _ EMPTY,A

_ STOP,

B _ STOP 55.

A _ Q _ EMPTY,A

_ BOUNDER,A

_ PFLAG,B

_ Q _ EMPTY,UPDATE_

A _ Q,OK _ B _ S,A _ STOP,

B_ STOP 56.

UPDATE

B_ Q,Q_ AB_ UA_ RSP,A_

B _ PFLAG,A_ 57.

Q _ AB _ UA _ RSP,A _ BOUNDER,A AB _ DISC_

58.

CMD,A_

59.

_ PFLAG,B

STOP,B _ AWAIT_

A _ Q _ EMPTY,OK_ A _ AWAIT_

BOUNDER,A_

PFLAG,UPDATE_

A_ Q,Q_ BA_ UA _ RSP,

STOP,B _ STOP

A _ S,A _ BOUNDER,A_

REL,B _ DISC_

A _ Q _ EMPTY,UPDATE_

CMD,B

_ Q _ EMPTY,OK_

B _ S,B _ PFLAG,

REL PFLAG,Q

_ BA _ UA _ RSP,B _ PFLAG,

_ STOP

B _ Q,OK_

A _ S,A _ BOUNDER,B

_ Q _ EMPTY,B

_ PFLAG,A

_ STOP,

B _ S,B _ PFLAG,A

_ STOP,

B_ STOP 60.

A _ Q _ EMPTY,A

_ BOUNDER,B

_ Q _ EMPTY,UPDATE

_ A _ Q,OK_

B_ STOP 61.

A_Q_

EMPTY,UPDATE_

B _ PFLAG,A_ 62.

A _ Q _ EMPTY,AB

_ UA _ RSP,A _ BOUNDER,A

A _ STOP, B _ AWAIT_ 63.

A _ Q _ EMPTY,A

(64). A_ Q_ EMPTY,OK_ A_ Q_ EMPTY,AB B_ PFLAG,A_ 66.

Q_EMPTY,UPDATE_

A_ Q,

_ Q _ EMPTY,OK_

B _ S,B _ PFLAG,

_ BOUNDER,AB

_ AWAIT_

_ RR _ RSP_ F1 _ NOACK,

B _ Q _ EMPTY,B

_ PFLAG,

REL

A _ S,A_ BOUNDER,A _ UA _ RSP,UPDATE

_ PFLAG,B

_ Q _ EMPTY,OK

_ B _ Q,A _ BOUNDER,A

_ B _ S,A _ STOP,B _ STOP *

_ PFLAG,Q

_ BA _ UA _ RSP,

STOP, B _ STOP _ PFLAG,B

_ Q _ EMPTY,UPDATE_

A _ Q,

STOP,B _ STOP

(67). A _ Q _ EMPTY,OK_ 68.

_ PFLAG,B

BA_ UA_ RSP, Q_ AB _ UA _ RSP,A _ BOUNDER,A B_ PFLAG,A_

PFLAG,B_

REL

_ NORM,A

BA _ DISC _ CMD,B 65.

B_Q,A_BOUNDER,A_

STOP, B_ STOP

A_ S,A _BOUNDER,

A _ Q _ EMPTY,UPDATE_

B _ Q_ EMPTY,OK

B _ Q,OK _ A _ S,A _ BOUNDER,A

_ B _ S,B _ PFLAG,A _ PFLAG,B

_ STOP,B _ STOP *

_ Q _ EMPTY,B

_ PFLAG,

A_ STOP,B _ STOP 69.

A_Q_

EMPTY,A_

BOUNDER,A_

PFLAG,B_Q_EMPTY,UPDATE_A_

Q,OK_

B_ S,B_ PFLAG,

A_ STOP,B _ STOP 70.

UPDATE_ B _ FLAG,A

B _ Q,Q _ AB _ UA _ RSP,A _ BOUNDER,AB _ STOP, B _ AWAIT_

(71). A _ Q _ EMPTY,AB B_ PFLAG,A_

_ RR _ RSP _ F1 _ NOACK,B

_ Q _ EMPTY,

REL

_ UA _ RSP, BA _ UA _ RSP,A_

BOUNDER,A

_ PFLAG,B

_ Q _ EMPTY,

STOP, B_ STOP *

(72). A_ Q_ EMPTY,OK_

A_ S,A_ BOUNDER,A_

PFLAG,B_

Q_ EMPTY,OK_

B_ S,B_ PFLAG,

A_ STOP, B_ STOP* 73.

Q _ AB _ UA _ RSP,A _ BOUNDER,AB B_ PFLAG,A_

STOP, B_ AWAIT_

_ RR_ RSP _ F1 _ NOACK,B

_ Q _ EMPTY,OK

_ B _ S,

REL

References

[1] D. Kostas, Transition to ISDN-An Overview, IEEE Comm. Mag. (January 1984). [2] M.G. Walker and R.A. Hess, Making the ISDN Work: A Look at D-Channel Signaling, Telephony (May 18, 1987) 52-57. [3] P. Chen, How to Make the Most of ISDN's New LAPD Protocol, Data Comr~ (August 1987) 153-162. [4] AT&T, Digital Multiplexed, Interface Technical Specification, Issue 3.1, AT&T Pubfications No. 500-029, October 1986.

[5] S. Aggarwal, D. Barbara and K. Meth, A Software Environment for the Specification and Analysis of Problems of Coordination and Concurrency, IEEE Trans. Software Engrg. 14 (3) (1988) 280-290. [6] A.U. Shanker and S. Lam, Specification and Verification of an HDLC Protocol with ARM Connection Management and Full-Duplex Data Transfer, in: Proc A R M Symposium on Communications Architectures and Protocols (1983) 38-48. [7] J. BiUington, G.R. Wheeler and M.C. Wilbur-Ham, PRO-

314

[8] [9]

[10]

[11]

S.M. Shatz et al. / Formal modeling of the LAPD protocol

TEAN: A High Level Petri Net Tool for the Specification and Verification of Communication Protocols, IEEE Trans. Software Engrg. 14 (3) (1988) 301-316. J.L. Peterson, Petri Net Theory and the Modeling of Systems (Prentice-Hall, Englewood Cliffs, N J, 1981). G. Chiola, A Software Package for the Analysis of Generalized Stochastic Petri Net Models, in: Proc. International Workshop on Timed Petri Nets, Torino, Italy (1985) 136143. E.T. Morgan and R.R. Razouk, Interactive State-Space Analysis of Concurrent Systems, IEEE Trans. Software Engrg. 13 (10) (1987) 1080-1091. CCITT Recommendations Q.920 and Q.921, Digital Access Signaling Systems, CCITT Red Book, Vol. VI, Fascicle 9, 1984.

[12] D.P. Sidhu and T. Blumer, Verification of NBS Class 4 Transport Protocol, IEEE Trans. Comnt 34 (8) (1986) 781-789. [13] M. Diaz, Modeling and Analysis of Communication and Cooperation Protocols Using Petri Net Based Models, Comput. Networks 6 (1982) 419-441. [14] E.T. Morgan and R.R. Razouk, Computer-Aided Analysis of Concurrent Systems, in: M. Diaz, ed., Protocol Specification, Testing and Verification (North-Holland, Amsterdam, 1985) 49-58. [15] R. Razouk and C.V. Phelps, Performance Analysis Using Timed Petri Nets, in: C.A. Sunshine, ed., Proc. IFIP Workshop on Protocol Specification, Verification, and Testing (North-Holland, Amsterdam, 1977) 75-93.