A Constraint-Based Approach to Diagnosing Distributed ... - CiteSeerX

A Constraint-Based Approach to Diagnosing Distributed Software Systems Daniel Sabin

Mihaela C. Sabin

Abstract

Robert D. Russell

Department of Computer Science University of New Hampshire Kingsbury Hall M208, College Road Durham, NH, 03824 USA E-mail: [ds1, mcs, rdr, ecf]@cs.unh.edu

Distributed software problems can be particularly mystifying to diagnose, for both system users and system administrators. Modelbased diagnosis methods that have been more commonly applied to physical systems can be brought to bear on such software systems. A case study is presented here using the File Transfer Protocol (FTP). The knowledge base is divided into three components: user interaction, protocol and con guration. For each component knowledge is naturally represented in the form of constraints. In particular, user interaction modeling is accomplished through the introduction of constraints representing user assumptions. Diagnosis is viewed as a partial constraint satisfaction problem (PCSP). A PCSP algorithm has been adapted for use as a diagnostic engine. Even our prototype implementation is able to diagnose some rather obscure FTP problems.

1 INTRODUCTION The importance of distributed, multivendor computing environments, and the diculties associated with operating such networks are well known. Diagnosing a distributed system is currently more art than science [1]. The situation has been summarized in a cartoon that pictures a visitor to a computing site staring at a swami sitting cross-legged in the corner, and receiving the explanation: \That's our network guru". Model-based diagnosis [2] has achieved considerable success in diagnosis of physical systems. We apply this approach here to diagnosis of distributed software systems | including the human user components of these systems. One approach to model-based diagnosis has taken diagnosis to be a constraint satisfaction problem (CSP) [3]. We implement here a re nement of this approach using partial constraint satisfaction (PCSP) methods [4].

Eugene C. Freuder

We take as an initial domain of study File Transfer Protocol (FTP) problems. Even our modest prototype implementation is able to diagnose problems that might prove puzzling to an experienced system manager. We decompose our problem domain into three components, each of which will be modeled separately, as shown in Figure 1. User Interaction

Configuration

Protocol

Problem domain decomposition

Figure 1. Problem domain decomposition 1. The User Interaction component deals with commands given by the human user and the expectations that the user has about the system response to these commands. 2. The Protocol component is really the network software, and will later be further decomposed into layers corresponding to the actual implementation of the network software. For now it represents simply all active software . 3. The Con guration component represents all passive information about the network and the computing environment, such as machine names and addresses, routes, connectivity, etc. This information parameterizes the software in the protocol component. In Section 2 we investigate the types of problems that can arise with FTP, and present several speci c diagnoses performed by our system. In Section 3 we describe how FTP diagnosis is treated as a PCSP, focusing on the novel rendering of user interaction diagnosis as a constraint satisfaction problem. Section 4 elaborates on our approach.

2 FTP CASE STUDY The application protocol chosen for exempli cation is FTP, described in RFC 959 [5]. It provides interactive le transfer and relies on Transmission Control Protocol (TCP) { a transport protocol in the TCP/IP hierarchy of protocols [6]. The complete FTP service is structured in two distinct processes, plus the rules and formats (i.e. the protocol) for information exchange between them. These processes: a client (local) FTP program and a server (remote) FTP daemon, as shown in Figure 2, cooperate to accomplish the le transfer function. The client initiates the connection and forwards user commands to the remote server. The server, in response to the received commands, sends replies whose general format is a completion code (including any error code), followed by a textual description of the action taken. A user interface resides on the local machine through which the user requests the transfer of les to and from the remote machine. In our simple examples only two of the basic operations are used: put get

local le name remote le name remote le name local le name

As a result, a local (remote) le is copied to (from) the remote (local) machine. In the examples shown we have run the FTP program on two dierent machines whose operating systems are ULTRIX (a version of UNIX) and VMS. Their lesystems dier in the way les are represented and named. According to our framework for network diagnosis we can group the FTP problems we encountered into three categories: user interaction, protocol and con guration problems. For each category we discuss some interesting examples for which we give the diagnosis

solution produced by the diagnosis tool. The examples of the rst two categories are actual cases we have run and diagnosed; the con guration problem has not been implemented yet. The format of each example explains the FTP command and its execution context, formulates the problem encountered and prints out the message produced by the diagnosis program. To understand why these problems occurred, we mention brie y the VMS conventions in naming les, which are more restrictive than those for the UNIX lesystem. The name format requires three dierent elds for name, extension and version number. Only alphanumeric characters are allowed (plus the $ character) to specify the name eld. The le extensions are prede ned to indicate the type of the le. Other special characters are reserved for wildcards or delimiters in the le name syntax. Thus, names such as \++", \**" or \!!" are not accepted in the VMS lesystem. Moreover, it is possible to have a special le name, whose name and extension elds are both missing but the version number is present, e.g. \.;1". We will call this le the \noname" le in the following examples. Choosing reserved characters to name les usually produces messages such as: \ le speci cation syntax error", \invalid wildcard operation" or \not a plain le", which are self explanatory. However, there are cases in which the FTP server responses are rather cryptic or the transfer results are totally unexpected. We will explore these cases and explain both the FTP execution context and its eects.

2.1 SAMPLE USER INTERACTION PROBLEMS The dierences between the lesystems of the local and remote machine can cause surprising name mapping for the les transfered. The user might get some other

User

local

local FTP

File

program

System

(client)

control connection data connection

FTP process model

Figure 2. FTP process model

remote FTP

remote

daemon

File

(server)

System

le transfered instead of the local name speci ed in the command, as shown in the following example:

FTP command: put ++ FTP error message: | FTP context:

++

local FTP running on VMS, remote FTP running on UNIX.  there is no local le \++" in the current directory since it is not a valid name for the VMS lesystem.  the \noname" le exists in the current directory on VMS. Problem: The transfer completes although there is no local le \++". The local le \.;1" is transfered instead and is stored on the remote machine under the name \++". ** Invalid VMS file name:

``++''

Newly created le names on the remote machine are generated when the le speci cation is illegal. This is also a case of name mapping when the lesystems do not have the same naming conventions. FTP command: put @@ FTP error message: | FTP context:

@@

local FTP running on UNIX, remote FTP running on VMS.  the local le \@@" exists, but is not a valid name for the VMS lesystem. Problem: The transfer takes place, but the new remote le name is mapped to \$A$A.;1". 

Diagnosis:

``$?$?.;?''

** Remote file name has the form

Finally, there are cases in which the les get partially changed without violating naming rules. Even if the sequence of user commands shows no error, examining the text les or running the executable les shows strange results. This may happen when the type of the transfer (ASCII or binary) does not match the type of the le transfered. For the ASCII type, conversion to a standard text le representation on the network is necessary to allow communication between dierent lesystems. The UNIX system considers the newline character as text line delimiter, while VMS uses a line length count. Thus, for the ASCII type of transfer, the sending and receiving sites perform the necessary transformations between the standard representation and their internal representation of les. It is the user's responsibility to correlate the data representation used and the transformation function performed during the transfer. FTP command: put

alpha alpha

local FTP running on UNIX, remote FTP running on VMS.  the local le \alpha" exists on UNIX and is an ASCII le.  the transfer type is binary. Problem: The content of the transfered le is not modi ed since the conversion to the standard representation does not apply when binary type is used. However, the end of lines is not recognized on VMS and the lines show up in a staircase pattern when displayed. 



Diagnosis

FTP error message: | FTP context:

Diagnosis:

** Change transfer type to ASCII and repeat transfer

2.2 SAMPLE PROTOCOL PROBLEMS Sometimes illegal parameters in user transfer commands are discarded by the FTP client and the FTP server receives incompletely speci ed requests. The received error message has no useful meaning for the user: FTP command: get !! !! FTP error message: RETR: command not understood FTP context:

local FTP running on VMS, remote FTP running on UNIX.  the le \!!" exists on the remote machine, but is not a valid name for the VMS lesystem. Problem: The error message is given in terms of lower level protocol commands (RETRieve is the corresponding protocol command to implement the user get command) which are not understood by the user. 

Diagnosis:

** FTP client implementation error -- nonempty argument required for the RETR command

A symmetric operation: put !! !!, in the same execution context, causes the error message: \STOR: command not understood" (where STORe is the corresponding protocol command to implement the user put command). It is interesting to notice how the protocol knowledge helps isolate a problem triggered at the user level. In this sense, a further exploration of the underlying protocols could extend the problem domain we address.

2.3 SAMPLE NETWORK CONFIGURATION PROBLEM Network con guration is the setting, collecting and storing of the parameters of all the devices on the network, such as hosts, gateways, etc. The process of

con guration is complex and it addresses several aspects [7]: 1. Con guring the network interface which must be known to the protocol software, since a variety of physical networks are currently used. 2. Routing, that allows trac to reach its destination. 3. Name service, to identify network nodes by names, not only by their equivalent addresses. Our example reveals a routing con guration problem we actually encountered examining several FTP client programs. All systems route data based on the content of the local routing tables. A minimal routing table only works to reach hosts on the directly connected physical networks. Routes through external gateways must be added to reach hosts on other networks. If the network has only one gateway, a default route is used to direct all trac bound for remote networks through that gateway. In our example the problem arose running on a MAC computer the Fetch program (an implementation of the FTP client for MAC). Trying to resolve a remote host name, Fetch searched for the default gateway in its local routing table. But the con guration value assigned to identify the gateway did not re ect the current network topology. In this case, the Fetch program keeps trying to establish the connection with no informative message or reasonable time out given to the user. The problem can be xed by setting the new value such that the con guration database over the local area network becomes consistent with the real world situation.

3 REPRESENTATION AND REASONING Model-based diagnosis techniques compare observations of the behavior of a system being diagnosed to predictions based upon a model of the system in order to diagnose faults [8] [9] [10]. The fundamental presumption behind model-based diagnosis is that, assuming the model is correct, all the inconsistencies between observation and prediction arise from faults in the system. Given a model description and a set of observations, the diagnosis task is to nd a set of faults that will explain the observations. Minimal diagnoses postulate sets of faulty components that are minimal in the sense that any no proper subset provides an explanation. A system is de ned by a set of interacting components COMPS, a system description SD and a set of observations OBS, where SD and OBS are sets of rst-order logic propositions. Typically a system description describes how the system components behave normally, but may also include models of faulty behavior.

3.1 DIAGNOSIS AS A PARTIAL CONSTRAINT SATISFACTION PROBLEM

Constraint satisfaction is a powerful and extensively used arti cial intelligence paradigm [11]. A constraint satisfaction problem (CSP) involves a set of problem variables, a set of values for each variable and set of constraints specifying which combinations of values are consistent. A solution to a CSP speci es a value for each variable such that all the constraints are satis ed. If we assign costs to the values we can look for a solution with optimal cost. Model-based diagnosis can be viewed as a constraint optimization problem by associating system components with constraints that re ect their behavior, component inputs and outputs with problem variables, and introducing assumption variables associated with the system components, where a value of 0 for an assumption variable re ects normal behavior and a value of 1 abnormal behavior [3]. Observations force assignment of some of the problem variables. The task of nding a minimal diagnosis corresponds to nding an optimal solution of such a CSP. We use a re nement of this approach based on the notion of a partial constraint satisfaction problem (PCSP) [4]. PCSPs were introduced for applications that settle for partial solutions that leave some of the constraints unsatis ed, e.g. because the problems are overconstrained or because complete solutions require too much time to compute. We have found that PCSPs provide an elegant approach to viewing diagnosis in CSP terms. Regarding components as constraints, and faulty components as failed constraints, minimal diagnoses naturally correspond to PCSP solutions that leave minimal sets of constraints unsatis ed. These sets are minimal in that there is no solution which leaves only a proper subset unsatis ed. Bakker et al. [12] have taken the opposite approach, applying model-based diagnosis methods to partial constraint satisfaction. Combinations of branch and bound and CSP techniques have been used in algorithms that search for a solution that leaves a minimal number of constraints unsatis ed [4]. We have adapted one of these algorithms to search for solutions with minimal sets of unsatis ed constraints. One of the advantages of viewing diagnosis as a PCSP is that it permits us to bring our experience with PCSP algorithms to bear on diagnosis. The algorithm serves as the diagnostic inference engine for our system. When supplied with a CSP description of user interaction knowledge, it diagnoses problems using that knowledge; when provided with a CSP description of protocol knowledge, it diagnoses problems using that knowledge.

3.2 FTP DIAGNOSIS AS A PCSP We model each of the components of Figure 1 | user interaction, protocol, con guration | as a separate PCSP knowledge base. Protocol diagnosis has been studied previously as a constraint satisfaction problem [13] [14] [15]. We apply this approach here to the FTP protocol. We demonstrate here that user interaction diagnosis can also be modeled as a constraint satisfaction problem, in particular by introducing constraints that re ect user assumptions. Con guration problems have been treated as constraint satisfaction problems [16]; while we have not implemented a con guration knowledge base, we foresee no diculty in treating con guration diagnosis as a PCSP. These three components are naturally modeled separately. They utilize dierent mechanisms to instantiate the general CSP paradigm, e.g. an intermediate nite state machine model for protocols. Applying the diagnostic engine successively to the three separate domains, until a diagnosis is found, may reduce the combinatorial complexity the engine faces. On the other hand, it is already clear that there are interesting interactions between these components, which may ultimately require a more sophisticated control architecture. There was also a knowledge engineering, knowledge acquisition eort in developing the user interaction model. Considerable time was spent exploring dierent types of interaction that can occur, and discovering dierent types of problems that can arise.

3.2.1 USER INTERACTION

The FTP commands specify the parameters for the data connection (data port, transfer mode, representation type, structure, etc) and the nature of the le system operation (store, retrieve, append, delete, etc). Each time the user gives a command, the current state of the FTP client can be represented as a PCSP problem. The set of variables includes the transfer parameters: MODE, STRUCTURE, TYPE , the local and remote operating systems: CLIENT, SERVER , the le system operation, COMMAND , and the le pathname, PATH . In addition, there are some other variables which have no direct correspondent among the entities that characterize the state of the client. They represent instead, either the user's perception of the result of the operation, or, to some extent, the state of the user's mind at that moment. The variable OUTCOME represents the outcome of an FTP operation. Since the value of this variable cannot be determined at the time of the transfer, the user is responsible for supplying a value (\success", or, if something went wrong, his perception of `wrong', e.g. \ascii le incorrectly transferred"). Clearly, the motivation for introducing this variable in the PCSP is that it allows us to embody faulty behaviors in the model.

A \fault" at this level typically means a mismatch between the status of the real world and the user's mental representation of it. For example, data representations are handled in FTP by a user specifying a representation type, described in our model by the variable TYPE. When the user is specifying a value for the TYPE variable, he is in fact just making an assumption about the actual type of the le, represented by the value of the variable ACTUAL-TYPE. User's assumptions are modeled in a natural way with constraints. In this particular case, there is an equality constraint between variables TYPE and ACTUALTYPE. This dierence in semantics implies that all such PCSPs will have two sets of constraints: 1. constraints that will be part of all the PCSPs, representing the functional speci cation model of FTP (accounting for both correct and incorrect behavior); 2. constraints that change from problem to problem: (a) constraints model user's assumptions about the real world; (b) some FTP commands translate to unary constraints, forcing value assignments for the corresponding variables (e.g. the FTP command GET restricts the domain of the variable COMMAND to a single value, namely get ).

3.2.2 PROTOCOL

Protocol speci cations are typically represented in the form of nite automata, often referred to as nite-state machines (FSMs). Since simple FSMs have limited expressive power in representing such notions as timers, logical conditions, etc., a more powerful formalism is needed, and thus extended nite automata have been used for protocol testing and speci cation analysis or diagnosis [17] [18]. The idea of using model-based techniques to diagnose communication protocols based on extended nite automata is not new. To our knowledge, at least three protocol diagnosis systems have been proposed [13] [14] [15]. All these approaches attempt to diagnose protocols by analyzing con icts between observations and the protocol model. This implies that observations must somehow be associated with the model. The representation approach we are using is similar to the one used by Riese in [15]. The FTP protocol speci cation as an extended nite transducer is translated into a standard CSP form. Where Riese is using a specialized algorithm for solving the diagnosis problem, he calls it HMDP, we are using a variant of a standard PCSP algorithm to produce the set of minimal diagnoses. We make the same assumptions as Riese does, that

CLIENT

SERVER

User FTP client

FTP server daemon

Configuration

FTP protocol

FTP protocol

Configuration

Database

TCP protocol

TCP protocol

Database

IP protocol

IP protocol

ethernet protocol

ethernet protocol hardware medium

Expanded model hierarchy

Figure 3. Expanded model hierarchy the external observer resides outside of the node on which the system under diagnosis is implemented, and that the observer can time-stamp messages when they are observed. In addition to the time stamp of the message, an observation also contains the type of the message (STOR, RETR , etc.) and the direction of the message, relative to the client. Each observation has a variable associated with it. Considering the order given by the time stamps, let = 1 be a sequence of observations and let be the variable associated with observation . The domain of values of such a variable is simply the set of all valid state transitions described by the extended nite transducer. Thus, to solve the CSP we have to assign one state transition of the protocol machine to each variable corresponding to an observation, subject to two kinds of constraints: OBS

< o ; : : : ; on > vi

oi

1. unary constraints, which check whether the value assigned to some variable has the same message type, direction and number and type of arguments as the associated observation ; 2. binary constraints, which relate a variable to its neighbors ?1 and +1 by checking whether the pairs of corresponding values , ?1 and , +1 respectively, are part of a sequence of transitions allowed by the protocol machine. Due to transitivity, if all the binary constraints are satis ed, a solution to the problem will represent a complete transition sequence explaining OBS . ti

vi

oi

vi

vi

vi

ti

ti

ti

ti

When the FTP implementation is faulty, con icts be-

tween observations and the FTP model will result in partial satisfaction of the constraints, and the diagnosis algorithm applied to this PCSP will produce the set of minimal diagnosis in terms of errors at the level of the protocol commands (e.g. incorrect/missing arguments) and/or sets of faulty state transitions.

4 EXPANDING THE MODEL The simple three-component model described previously can be expanded by using the ISO Reference Model of Open Systems Interconnection (OSI) [19]. The idea behind the OSI approach is to model a system as a hierarchy of \layers" or \levels", each representing an abstraction of a well-de ned function in the network. The lowest level layer, representing the most basic functionality, is the physical medium that transports signals (i.e., \bits" ) between host computers. The highest level is the user. A diagram of the levels we will use is given in Figure 3. The levels shown there are those used by FTP running on a local area ethernet, as given in [5], and do not correspond directly with those de ned in the ISO model.

4.1 FTP MODEL HIERARCHY Within one host computer, data ows vertically from one layer to the next layer above or below it in the hierarchy. However, the purpose of this data ow is to convey information from one level in one host to the corresponding level in another host. The rules by which this information is exchanged between cor-

responding levels in dierent hosts is called a \protocol" , and more particularly, the \X protocol", where \X" is the name of the layer in the hierarchy (i.e., the \transport protocol" governs the exchange of information between the \transport layers" ). The unit of information exchanged between corresponding levels in dierent hosts is called a protocol data unit (PDU). Because the functionality and protocol of each layer is de ned separately, we build one model for each layer. In its simplest form, this model consists of two active components, one for each communicating host. Protocols are speci ed in terms of an extended nite state machine, with input and output on the machine's transitions corresponding to the information received from or sent to the active component on the other host. The models (extended nite state machines) at dierent levels are interrelated as follows: To pass a PDU from a layer on host A to the corresponding layer on host B, the data representing that information must be passed from that layer on host A to the next lower layer on host A, which will transform the data and in turn pass the transformed data to the next lower layer, etc., until it reaches the lowest possible layer | the physical medium. It is this layer which actually carries the bits from host A to host B, at which point the data is conveyed from layer to layer back up the hierarchy until it reaches the layer on host B corresponding to the originating layer on host A. The function performed by each layer in one host is speci ed in terms of exchanging PDUs with the corresponding layer in the other host, and this is how it is modeled in terms of the extended nite state machines. These machines are coupled because an output transition at one level triggers an input transition at a neighboring level. In addition to the active components at each level, we also de ne a corresponding passive component called the \con guration database". The information in this database eectively parameterizes the actions of the active components, and allows them to be de ned and coded in a general manner. In practice, the con guration database may not be represented cleanly as a single database, but may be distributed over several les and hosts, and can also be partially \hard coded" into programs and tables on dierent hosts. Data in this database is usually replicated at dierent sites in a network, and the inconsistencies and inaccuracies in this database are one of the most common sources of network errors as well as one of the most dicult to detect [1] [7].

4.2 DATA GATHERING One of the diculties in modeling a network is that it is in general possible to actually observe data only in 2 places: 1. as it crosses the interface between the user and the application program (i.e. the FTP client) on the user's host computer;

2. as it travels on the physical medium (i.e., the \wire" ) from one host to another. Since ultimately all data must ow across the physical medium, we can look at the sequence of bits traversing this medium as the \projection" of all PDUs being exchanged by higher layers in the hierarchy. Since our model is driven by data crossing all boundaries between layers in the hierarchy, we are forced to infer most of this data from our two possible observation points. There are two obvious ways to perform this inference: top-down and bottom-up . In a topdown approach, we would run our models starting at the top level with the input given by the user and would predict the projected bit stream we would expect to see traverse the physical medium. A bottom-up approach would start with the bit stream actually observed on the physical medium and would attempt to reconstruct the transitions and PDUs that could have produced that projection.

4.3 GOALS This modeling has three goals: 1. fault detection , to know when something is wrong. This would show up in the top-down approach as a dierence between a predicted and actual bit stream. In a bottom-up approach it would show up as an inability to reconstruct the transitions and PDUs that would project onto the observed bit stream. 2. fault isolation , to determine where the error occurred. In essence we want to know which level in the hierarchy was responsible for the fault, either because it made an incorrect transition, because it created an incorrect PDU, or because the values it used as parameters from the con guration database were incorrect or inconsistent. 3. fault correction , to propose a change that xes the error. In addition, there are two other tasks that we should be able to have our model perform: 1. con guration control , to regulate changes to the con guration database so that it will remain accurate and consistent (assuming it was created in an accurate and consistent state). 2. performance evaluation , to measure resource utilization for purposes of detecting bottlenecks and proposing possibilities for judiciously increasing capacity. As a nal point, we are starting from the assumption that our network diagnosis tool must be passive. That is, it can only observe communications between hosts but cannot in any way interfere with or participate in them. A more aggressive approach would be an

active diagnosis tool, one which could initiate communications between hosts for the purposes of provoking a certain behavior or a certain response that could then be checked against an expected behavior or response. Clearly this approach would require extensive modi cation to existing software, whereas the passive approach does not. Currently, the diagnostic knowledge in our implementation is divided to re ect the user, protocol and con guration components. Already we are seeing a kind of information ow between components, as user problems are diagnosed with protocol knowledge. As we implement more elaborate models of network interaction and use, we expect the architecture of our diagnostic system to continue to re ect and exploit the architecture of the systems we diagnose.

[11] E.C. Freuder and A.K. Mackworth, Special Volume, Constraint-Based Reasoning, Arti cial Intelligence, 58, (1992) [12] R.R. Bakker, F. Dikker, F. Tempelman and P.M. Wognum, `Diagnosing and solving overdetermined constraint satisfaction problems',

Acknowledgments

[15]

This material is based on work supported by Digital Equipment Corporation, and by the National Science Foundation under Grant No. IRI-9207633.

References

[1] M.A. Miller, Troubleshooting TCP/IP , M&T Books, 1993. [2] W. Hamscher, L. Console and J. de Kleer, editors, Readings in Model-based Diagnosis , Morgan Kaufmann Publishers, Inc., San Mateo, CA, 1992 [3] Y. El Fattah and R. Dechter, `Empirical Evaluation of Diagnosis as Optimization in Constraint Networks', Working Papers of The Third International Workshop on Principles of Diagnosis (DX92), (1992).

[4] E.C. Freuder and R.J. Wallace, `Partial Constraint satisfaction', Arti cial Intelligence, 58, 21{71, (1992) [5] J. Postel, `File Transfer Protocol', RFC 959, ISI (October 1985). [6] D.E. Comer, Internetworking with TCP/IP , vol. 1, Prentice Hall, Inc., Englewoods Clis, NJ, 1991. [7] C. Hunt, TCP/IP Network Administration , O'Reilly & Associates, Inc., 1992. [8] R. Reiter, `A Theory of Diagnosis from First Principles', Arti cial Intelligence, 32, 57{95, (1987) [9] J. de Kleer, B.C. Williams, `Diagnosing Multiple Faults', Readings in Model-based Diagnosis , W. Hamscher, L. Console and J. de Kleer, editors, Morgan Kaufmann Publishers, Inc., San Mateo, CA, 1992 [10] R. Davis and W. Hamscher, `Model-based reasoning: Troubleshooting', Readings in Modelbased Diagnosis , W. Hamscher, L. Console and J. de Kleer, editors, Morgan Kaufmann Publishers, Inc., San Mateo, CA, 1992

Proceedings of the 13th International Joint Conference on Arti cial Intelligence , 1, 276{281,

[13] [14]

[16]

(1993). A.T. Bouloutas, `Modeling Fault Management in Communication Networks', PhD Thesis, Columbia University, 1990. A. Ghedamsi, G. von Bochmann and R. Dssouli, `Diagnosing multiple faults in nite state machines', Technical Report, Dept. d'IRO, Universite de Montreal, Canada, (January 1993). M. Riese, `Model-based Diagnosis of Communication Protocols', PhD Thesis, Swiss Federal Institute of Technology, Lausanne, 1993. S. Mittal and F. Frayman, `Towards a generic model of con guration tasks', Proceedings of the Eleventh International Joint Conference on Arti cial Intelligence , 2, 1395{1401, (1989).

[17] C.J. Wang and M.T. Liu, `A test suite generation method for extended nite state machines using axiomatic semantics approach, Protocol Speci cation, Testing and Veri cation , XII, 29{43, (1992) [18] Y.J. Lin and G. Wuu, `A constraint approach for temporal intervals in the analysis of timed transitions', Protocol Speci cation, Testing and Veri cation , XI, 215{230, (1991) [19] H. Zimmermann, `OSI Reference Model { The ISO Model of Architecture for Open Systems Interconnection', IEEE Transactions on Communications , COM-28, 425{431, (April 1980).