On the Applicability of an Interval Time Structure for Protocol Verification

Transcription

1 On the Applicability of an Interval Time Structure for Protocol Verification Jerzy BRZZIŃSKI, Michał SAJKOWSKI Institute of Computing Science, Poznań University of Technology Piotrowo 3a, Poznań, Poland {brzezinski, Abstract. We demonstrate that the interval time structure may be inadequate for the modelling and the verification of a certain protocol class, in which both competing and supporting events are present. This observation has an important meaning for the generation of a correct state space for protocols and then for the detection of a proper set of qualitative protocol properties, such as deadlock, livelock, tempo blocking and starvation. 1. Introduction In the nineties, it has been observed that there is a significant development of formal methods, tools and algorithms applied to computer aided verification of real-time concurrent systems [2], [5], [7] and, in particular, computer network protocols [8], [2]. Recently, in the discussion of the advantages and disadvantages of current verification tools [3], it has been emphasized that computer aided verification performs an exhaustive exploration of the state space and considers all possible interactions of concurrent processes. It has also been pointed out that many subtle errors are extremely difficult to discover using the conventional techniques of simulation and testing. In the work presented, the protocol is seen as a timed concurrent system. The main distinction of the formal model of such a system is the presence of a time notion in an explicit form. Generally, time in the model may be presented by means of point or interval time structures [6]. However, to model a computer network protocol only the interval time structure seems to be adequate. It is because, first, the yielding of exact point times corresponding to real-life values is practically impossible. Secondly, any even slight variations of these point times in real-life, may cause the results of the analysis of the protocol model to be exactly inverse when compared to the properties existing in a real-life protocol. Therefore, in this paper we have focused on the evaluation of protocol verification techniques applying the interval time structure. We have considered a single representative of such techniques, presented in [9]. (We do not consider the timed automata model [1] - i.e. finite automata with a finite set of real-valued clocks, and their derivatives). As a result, we have found that the interval time structure may be inadequate for the analysis of a certain protocol class, in which both competing and supporting events are present. The competing events deal with processes which compete for precedence. The supporting events deal with processes which wait for the execution of other processes, like in the case of the receipt of a buffered message. Two or more supporting events may act on behalf of a single (supported) event. 453

2 The rest of the paper is organized in the following way. In the second section the currently used time interval approach for the verification of communication protocols is discussed. This approach has been applied to the protocol class in which only competing events are present. Section three presents the extension of this approach, proposed for protocols in which both competing and supporting events are present. In the fourth section the proposed extension is applied to the generation of a state space of a simple protocol, and the adequacy of this approach is analysed. Finally, in the fifth section conclusions are given. 2. Time Interval Approach The time interval approach to the modelling and the verification of communication protocol has been proposed in [9], [10]. We will present this approach in the sample context of User-Server Protocol [4] modelled by time Petri net, as is shown in Fig. 1. In the model there are distinguished: User entity, Server entity, Upper Protocol entity initializing the activity of User entity, and medium. ach place of the Petri net models some possible activity (processing, transmission) whose time duration is described by time interval [τ, τ']. This time interval denotes that after initialization (token arrival) the activity is running and lasts at least τ but at most τ' time units. Sample time intervals specified for the activities in the considered protocol are also presented in Fig. 1. When an activity is running, its remaining time interval (i.e. time interval left to completion of the activity) is decreasing. If an activity is completed and other transition conditions are fulfilled, the state is changed (transition is fired) and other activities are initialized (tokens are placed into other places). In the time interval approach proposed by [9], the state s k of a protocol is composed of two matrices: state matrix SM k and timing constraint matrix TCM k. As is shown in Fig. 2, in matrix SM k (included in large brackets) the remaining times of events (i.e. time intervals left to complete the appropriate activities like process executions or message transmissions) corresponding to the states of entities are placed on its diagonal, and corresponding to the states of channels are placed outside the diagonal. In Fig. 2 for example, in matrix SM 2 of state s 2, WAIT [16, 17] is the remaining time of an event denoting the state of the User entity, IDL [0, 5] is the remaining time of an event denoting the state of the Server entity, WFC [30, 35] is the remaining time of an event denoting the state of the Upper Protocol entity and RQ [1, 2] it is the specification of time of an event denoting the state of the channel from User to Server. (State s 2 is one of the states of User-Server Protocol discussed later in section 4). Fig. 1. The time Petri net model of User-Server Protocol 454

3 Fig. 2. xample of the state of a protocol in the time interval approach We should mention here, that in each state we may have two kinds of events: new ones and old ones. The new event was initialized in the considered state. The old event was initialized in one of the previous states and has not yet completed. The entry (event D, event ) in TCM k, denoted as τ D,, determines the adjustment distance of event D and event, at the time when these two events first meet each other. The adjustment distance is understood as the shift (forward or backward, along the time axis) of the interval associated with event D in order to properly precede the interval associated with event. The interval properly precedes the other interval if the upper bound of the former is equal to lower bound of the latter. Therefore the adjustment distance is calculated by the subtraction of the upper bound of the first event interval (D) from the lower bound of the second event interval (). It is worthwhile to emphasize that τ D, and τ D, values are calculated only once when these two events first meet each other and are left unchanged in the consecutive states as long as both events are present [9]. In Fig. 2 for example, in matrix TCM 2 of state s 2, the value +11 in entry TCM 2 [1,3] denotes the adjustment distance by which event IDL [0, 5] properly precedes event WAIT [16, 17]. This distance is equal to +11, because 16-5 = 11. Therefore, interval [0, 5] associated with event IDL should be shifted forward 11 time units in order to properly precede interval [16, 17] associated with event WAIT. Similarly, value -17 in entry TCM 2 [3,1] denotes the adjustment distance by which event WAIT [16, 17] properly precedes event IDL [0, 5]. This distance is equal to -17, because 0-17 = -17. Hence, interval [16, 17] associated with event WAIT should be shifted backward 17 time units in order to properly precede interval [0, 5] associated with event IDL. We should emphasize that in Lin's approach there are only competing events (i.e. dealing with processes which compete for precedence of their execution, like RADY and IDL in Fig.1). The most significant part of this technique comprises the procedure of the computation of the set of feasible events, i.e. events that can occur in the current state leading to a state transition: The procedure of the computation of the set of feasible events [9] begin for each new event A in state s k compute the remaining time interval [ τ A, τ A ] of this event by the use of a substitution: [ τ A, τ A ] := [ τ a, τ a ] (1) where [ τ a, τ a ] is the time interval specified for event A; for each old event in state s k compute the remaining time interval [ τ, τ ] of this event. If event D just occurred, apply the following formula ([9], Theorem 1, p.90): [ τ, τ ] := [max(τ, τ D, ), min( τ, -τ D, )] (2) where [ τ, τ ] is calculated by using the formula (3): [ τ, τ ] = [ τ, τ ] [ τ D, τ D] = [max( 0, τ τ D), τ τ D] (3) Values τ D, and τ D, are taken from the entries of the timing constraint matrix TCM k for state s k, and calculated as follows: 455

4 τ D, = τ * τ D* (4) τ D, = τ D* τ * (5) where values with an asterisk (*) denote the bounds of event intervals, at the time when these two events first meet each other. for all events in state s k, both new and old ones, do ([9], pages 86-87) Denote the event which has the smallest upper bound of the remaining times as the due event (if there are more than one such event, arbitrarily select one). Select from the other events those events whose remaining times overlap with that of the due event (these are the events which are properly preceded by the due event by a negative adjustment distance). Set the lower bounds of the occurrence time of the events to the lower bounds of their remaining times. Set the upper bounds of the occurrence time of the events to the upper bound of the remaining time of the due event. Include such calculated events together with the due event and their occurrence times into the set of feasible events in the state s k. end Note, formula 3 is very natural. Indeed, when activities leading to some events are running, their remaining time intervals are reduced. If event D has occurred (activity D has completed), then an interval of time [ τ D, τ D ] had to elapse. Thus, the upper bound of the remaining time (the maximum remaining time) of is τ τ D (D occurs at the earliest possible moment). On the other hand, the lower bound of is the maximum of 0 and τ τ D. The former case means, that event is competing with D and could occur before or simultaneously with D, but according to the assumption (event D just occurred) it did not. The latter case means, that the remaining time interval of these events are disjoint, thus to the occurrence of remains at least τ τ D time units. Formulae 4 and 5 describe the lower and upper bounds of the remaining time interval of in the state when events D and met for the first time. From this perspective, the minimum and maximum time that event can still remain not occurring after event D occurs, are τ D, and τ D,, respectively. The remaining time of event must satisfy formula 3 as well as formulae 4 and 5. It implies, finally, formula 2 [9]. 3. An xtension of Time Interval Approach We will now discuss an extension of the time interval approach applied to both competing and supporting events. The supporting events deal with processes which wait for the execution of other processes, like in the case of of the receipt of a buffered message (the examples of these events will be given below). Let event Di denote here the time in which a receiver is ready to receive the message, and event Dj denote the time in which a message arrives to the receiver. Both events, called supporting ones, support event D. So event D, called supported event, denotes the receipt of the message. Such a model specifies the receipt of a message, which is buffered at the receiver side when the receiver is not ready to receive it. (This is in a contrast to the model accepted by Lin's approach, in which for the receipt of a message the event of the message arriving is responsible only). Let us note, that the supported event does not appear explicitly in the model of the state. This event is the result of the combination of other events supporting it. Therefore, events Di and Dj appear both in the state matrix and the timing constraint matrix explicitly, and event D does not. However the transition from one state to another is caused by event D. 456

5 In this extension we have adapted formula (2) for the calculation of the remaining time of the old event in the case when event D, which has just occurred, is the event supported by other (here called supporting) events Di, Dj,... : [ τ, τ ] = [max( τ, τ Dmax, ), min( τ', τ, Dmin )] (6) where τ and τ' are calculated by (3) with τ D and τ' D of event D substituted as follows: τ D = max(τ Di, τ Dj,...) (7) τ' D = max(τ' Di, τ' Dj,...) (8) and where τ Dmax, and τ D, min are given by formulae: τ Dmax, = min(τ Di,, τ Dj,,...) (9) τ D, min = max(τ Di,, τ Dj,,...) (10) Here τ Di, denotes the adjustment distance by which event Di properly precedes event, and τ Di, denotes the adjustment distance by which event properly precedes event Di, etc. These values have been calculated by formulae (4) and (5) and placed in TCM. As a result, τ Dmax, is responsible for the lower bound and τ D, min is responsible for the upper bound of the remaining time of the old event (see Fig. 3). Let us refer to the example state (Fig. 4) of User-Server Protocol. In state s 5 we consider the following events: two supporting events and a single supported event. The supporting events are WAIT [0, 10] (denoting how long a User entity waits for the receipt of a message) and DON [3, 8] (denoting the arrival of message DON at User entity). The supported event is +done (denoting the receipt of message DON by User entity) (please see Fig.1). We will now calculate the time of the occurrence of event +done. We refer here to Fig 3: We denote event WAIT [0, 10] as event Di and event DON [3, 8] as event Dj, and event +done as event D. So we have: [τ Di, τ' Di ] = [0, 10] [τ Dj, τ' Dj ] = [3, 8] By the application of formulae (7) and (8) we have: τ D = max(τ Di, τ Dj ) = max(0, 3) = 3 τ' D = max(τ' Di, τ' Dj,...) = max(10, 8) = 10 Fig. 3. A concept of supporting events 457

6 Fig. 4. The example state with supporting events included Hence the time of the occurrence of event +done is equal to the interval: [τ D, τ' D ] = [3, 10] vent +done is the only event which may occur in state s 5. The reasons for this are the following: First, the lower bound of the time of the occurrence of some other events existing in state s 5 is greater than the upper bound of event +done (indeed 10 is less than the lower bound of events ALARM [12, 13] or FAULT [21, 22]). Second, some other events support certain consecutive events - however not all required events supporting these consecutive events are present - as in the case of event WFC [6, 16] and the absence of event CONFIRM supporting event conf. Let us assume, that event +done just occurred in state s 5 (Fig. 4). We now calculate the remaining time of the event ALARM in the next state. Let us note, that event ALARM is a new event in state s 5 and the remaining time of its occurrence is equal to the time interval specified for this event: [12, 13]. After the occurrence of event +done, event ALARM in the next state is treated as an old event. Therefore we may apply the procedure - presented above - of calculating the remaining time of the occurrence of old event, in the case when event D just occurred is the supported one. So we denote event ALARM [12, 13] as event. We first apply formulae (9) and (10) for the calculation of τ Dmax, and τ D, min. We recall here, that we denote event WAIT [0, 10] as event Di and event DON [3, 8] as event Dj. Thus, τ Dmax, = min(τ Di,, τ Dj, ) = min(+2, +4) = +2 τ D, min = max(τ Di,, τ Dj, ) = max(-15, -10) = -10 Values τ Di,, τ Dj,, τ Di,, τ Dj, are taken from timing constraint matrix TCM 5 in Fig. 4. Now we calculate the subtraction of the remaining time of event ALARM [12, 13] and the time of the occurrence of event +done[3, 10], applying formula (3): [ τ, τ ] = [ τ, τ ] [ τ D, τ D] = [max( 0, τ τ D), τ τ D] = = [12, 13] - [3, 10] = [max(0, 12-10), 13-3] = [2, 10] Next we apply formula (6) for the calculation of the remaining time of event ALARM in the next state, i.e. state s 6 : [ τ, τ ] = [max( τ, τ Dmax, ), min( τ', τ, Dmin )] = [max(2, +2), min(10, -(-10))] = [2, 10] 4. Application of the xtension of Time Interval Approach We have applied the extension of the time interval approach for the generation of the set of feasible events for the sample User-Server Protocol. As a result we obtained a part of the state space for the considered protocol presented in Fig. 5. The transition from one state to another is denoted by an arrow. With each transition a name of an event and the time of the occurrence of the event are placed. Near the end of the arrow, an absolute time of the entry to the next state is specified. (The absolute time we call the time expired from the beginning of the analysis of a protocol). 458

7 Fig. 5. Part of a state space generated for User-Server Protocol by means of the extension of the time interval approach 459

8 Fig. 6. The remaining time of event IDL in consecutive states s 1 and s 2 In this paper, all times are considered as relative ones (i.e. times which expired from the beginning of the entry to the state just considered), unless indicated explicitly as absolute times. We will now compare part of the state space (Fig. 5) with the analysis of the path leading to the particular event in the state space to check if the event selected is feasible in reality. We perform the analysis in four steps discussed below. In the analysis we take into acount the fact, that the remaining times of events may be dependent on the entry time to a state Step 1 - Analysis of a Path to the Selected State and Given ntry Time to It We will now analyse a certain path in the state space from an initial state s 1 to state s 8, assuming that the protocol enters state s 8 in the absolute time equal to 32 (see Fig. 5). We begin from state s 1. In state s 1 we have two intervals: RADY [2, 4] and IDL [3, 7]. When event RADY is completed, event -req occurs, and the considered protocol enters state s 2 in absolute time [2, 4]. Please note, that the remaining time of event IDL in state s 2 is dependent on the entry time to the state, and is given in the form of a polygon (as is shown in Fig. 6). This polygon is obtained by the subtraction from interval IDL [3, 7] the consecutive points of interval RADY [2, 4] (RADY is responsible here of event -req, representing the possible time moments of an entrance to state s 2 ). For instance, for selected points we have: [3, 7] - 2 = [1, 5], [3, 7] - 3 = [0, 4], and [3, 7] - 4 = [max(0, -1), 3] = [0, 3]. Hence, beginning from state s 2, all the remaining times in the next states will be considered as polygons, too. In state s 2, a new event WAIT is initiated. The absolute time of its occurrence is equal to the sum of the entry time to state s 2, and the time interval specified for event WAIT: [2, 4] + [16, 17] = [18, 21]. Then after the occurrence of event +req (supported by events IDL and RQ), the protocol enters state s 3. In state s 3, after the completion of event SRVIC, event -done occurs and the protocol enters state s 4. In state s 4, a new event DON is initiated. The absolute time of its occurrence is equal to the sum of the entry time to state s 4 and the time interval specified for event DON: [6, 13] + [10, 11] = [16, 24]. When event -alarm occurs in state s 4 in time interval [3, 7], the protocol enters state s 5. Hence, we may calculate the remaining time of event DON in state s 5. It is equal to [3, 8], because [10, 11] - [3, 7] = [3, 8]. In state s 5, event +done may occur. It is easy to observe from Fig. 1, that event +done is supported by two supporting events: DON and WAIT. Let us assume, that event +done occurs in the absolute time equal to 24. In order to determine the (relative) time of the occurrence of event +done in state s 5, which satisfies this assumption, we use the absolute times of events DON and WAIT, calculated above. From these absolute times we may deduce that the specific values of event +done are determined by event DON only. It is 460

9 because event DON occurs in time point 24 and event WAIT has occurred earlier (at the absolute time point 21 at the latest). We determine now for which values from interval DON [3, 8], the exit time from state s 5 may be equal to time point 24. The remaining times of event DON depend on the entry time to state s 5 and are described by the hexagon ABCDF in Fig. 7. This hexagon is obtained taking into account three intervals: the entry time to state s 5, [9, 20] (determines two vertical lines), the interval DON [3, 8] (determines two horizontal lines), and the absolute time of the event, [16, 24] (determines two lines specified by line segments AF and CD). The only values from the hexagon ABCDF for which absolute times may be equal to 24 belong to line segment CD. For instance, for entry time equal to 16, the only feasible value of event DON occurrence is 8, because = 24, and 8 [3, 8] (point C in Fig. 7). Summarizing, the protocol may exit state s 5 in time point 24, when event DON occurs in time interval [4, 8]. Therefore, we assume further that event +done occurs in the time interval [4, 8]. In state s 5 the time interval specified for event FAULT is equal to [21, 22], and for event ALARM is equal to [12, 13]. Hence when the protocol exits s 5 in time point 24, then the remaining time of event FAULT in the next state (s 6 ) is equal to time interval [13, 18], because [21, 22] - [4, 8] = [13, 18], and the remaining time of event ALARM is equal to [4, 9], because [12, 13] - [4, 8] = [4, 9]. When considering s 6, we assume that the protocol exits from this state (and enters state s 7 ) in absolute time 28. It is possible when in state s 6 both events which support event +alarm (i.e. ALARM and RADY) occur in point 4. (vent ALARM may occur in state s 6 in time interval [4, 9]. vent RADY may occur in time interval [2, 4]). Then the remaining time of event FAULT in state s 7 is equal to [9, 14], because [13, 18] - 4 = [9, 14]. When considering s 7, we assume that the protocol exits from this state in the absolute time 32. We calculate the relative time of the occurrence of event -ack. The only value of event RGISTR (responsible for event -ack) which satisfies this requirement is 4. Hence, event -ack occurs in time point 4 and the protocol enters state s 8. The remaining time of of event FAULT in state s 8, for entry point 32, is equal to [5, 10], because [9, 14] - 4 = [5, 10] Step 2 - The Repetition of Step 1 for Other ntry Times We repeat the analysis of the path and the calculation of the remaining time of event FAULT, assuming other values of entry times to state s 8 (please see Fig. 8). For the entry point to state s 8 equal to 24, the remaining time of event FAULT is equal to interval [6, 14]. For point 25 it is interval [5, 14], for point 26 it is interval [4, 14], for point 27 it is interval [3, 13], for point 28 it is interval [3, 12], for point 29 it is interval [3, 12], for point 30 it is interval [5, 12], for point 31 it is interval [5, 11]. So the remaining time of event FAULT is dependent on the entry time to state s 8, and the obtained polygon may be a concave one. Fig. 7. The values of event DON when protocol exits state s 5 in time point

10 Fig. 8. vent FAULT Fig. 9. vent +ack 4.3. Step 3 - Calculation of the Real ntry Time to the Next State In state s 8, the end of the execution of process RADY is denoted as event -req. It may occur in time [2, 4], i.e. in the absolute time [26, 36] (because [24, 32] + [2, 4] = [26, 36]). We now calculate the time of the occurrence of another event in state s 8, which is event +ack. vent +ack is supported by two supporting events: the arrival of message ACK and the readiness of its receipt i.e. completion of FAULT. Because the arrival of message ACK occurred earlier, during time interval [1, 2], the interval denoting the remaining time of event FAULT is in fact responsible for the occurrence of event +ack. As we remember, the interval associated with event FAULT is dependent on the entry time to state s 8. Because event +ack competes with event -req, therefore event +ack may occur for intervals which include values less or equal to 4 (4 is the upper bound of the occurrence of event -req). For example, four such intervals of the remaining time of event FAULT which satisfy this criterion are: interval [4, 14] for entry time point 26, interval [3, 13] for point 27, interval [3, 12] for point 28 and interval [3, 12] for point 29. So event FAULT allows event +ack to occur for entry times to s 8 belonging to interval [26, 29] (see, please, Fig. 9). If we impose the upper bound 4 on the intervals given above, we obtain the following intervals denoting the times of the occurrence of event +ack for the entry times to state s 8 from 26 to 29, respectively: [4, 4], [3, 4], [3, 4], and [3, 4] (Fig. 9). Thus, in state s 8 event +ack may occur in time interval [3, 4]. The absolute time of event +ack is then equal to [26 +4, ] = [30, 33]. So in fact, the protocol enters state s 9 in the absolute time [30, 33] Step 4 - Checking the Real Occurrence of vents We now check if event conf can occur in state s 9. Let us note, that the entry time [30, 33] to state s 9 differs from the entry time [30, 36] in the time interval approach presented in Figure 5. It has significant consequences. vent -req (for which its absolute time interval [30, 36] and entry time [30, 33] to state s 9 calculated above overlap) occurs in state s 9 in the absolute time [30, 33]. vent conf (for which its absolute time interval [34, 36] and entry time [30, 33] to state s 9 do not overlap) is delayed in comparison to event -req, and in fact 462

11 Fig. 10. Absolute times of events occurring in fact in state s 9 cannot occur in state s 9. So event conf depicted in state s 9 in the extension of the time interval approach (Fig. 5), in fact cannot occur in state s 9 (Fig. 10). This means, that in the extension of the time interval approach, after the occurrence of event conf in state s 9, a state may be generated which in fact is unavailable. 5. Conclusions The paper has shown that the extension of the time interval approach may lead to the generation of unavailable states, and then possibly to the detection of an incorrect set of protocol errors. This means, that the interval time structure may be inadequate for the verification of a protocol in which both competing and supporting events are present. It is because in the time interval model the dependence of the remaining time on the state entrance time is neglected. Thus in this case more accurate time models are required which should allow enabling conditions to be defined in the form of convex as well as concave polygons. A derivation of such a model is a major line of our further investigations. References [1] R. Alur and D.L. Dill, A Theory of Timed Automata, Theoretical Computer Science, 126 (1994) [2] R. Alur, T.A. Henzinger, (ds.), Computer Aided Verification, Lecture Notes in Computer Science 1102, ISBN: Springer-Verlag, Berlin [3] R. Alur, L.J. Jagadeesan, J.J. Kott and J.. Von Olnhausen, Model-Checking of Real-Time Systems: a Telecommunication Application, Proceedings of the 19th International Conference on Software ngineering, May 1997, Boston, Mass., ISBN: X. I Computer Society Press, [4] D. Brand and P. Zafiropulo, On Communicating Finite State Machines, Journal of the ACM 30 (1983) [5].M. Clarke and R.P. Kurshan, Computer-Aided Verification, I Spectrum, 33 (1996) [6]. Hajnicz, Time Structures. Formal Description and Algorithmic Representation, Lecture Notes in Artificial Intelligence 1047, ISBN: Springer-Verlag, Berlin, [7] C. Heitmeyer and D. Mandrioli, (ds.), Formal Methods for Real-Time Computing, Trends in Software 5, ISBN: John Wiley & Sons Ltd., Chichester, ngland, [8] G.J. Holzmann, Design and Validation of Computer Protocols, ISBN: Prentice-Hall International, Inc., nglewood Cliffs, New Jersey, [9] F.J. Lin, An Integrated Approach to Verification and Performance Analysis of Communication Protocols, Ph.D. Dissertation, Department of Computer and Information Science, The Ohio State University, Columbus, Ohio, [10] F.J. Lin and M.T. Liu, An Integrated Approach to Verification and Performance Analysis of Communication Protocols. In: S. Aggarwal, K. Sabnani (ds.), Protocol Specification, Testing, and Verification, VIII, ISBN: lsevier Science Publishers, Amsterdam, 1988, pp