Process Oriented Programming for Agent Based Network ...

Process Oriented Programming for Agent Based Network Management Nikolaos Skarmeasand Keith L. Clark, Imperial College Department of Computing London, SW7 2BZ UK email:fns4,[email protected]

Abstract

A multi-agent approach for network management was presented. Agents were built as a set of layers on top of the April language. April is a distributed symbolic programming language. The layers supported a set of object oriented and database features, labeled under the name April++. April++ objects have the ability in addition to the ordinary object oriented features, to deal with dynamic methods and relational database tables as part of their state component. These high level features facilitated the design of a generic agent architecture, where several heterogeneous components can be integrated using a blackboard as communication medium. This architecture, by adding appropriate agent components, was further specialised to build agents suitable for multi-service network management.

1 Introduction In recent years technological advances in the telecommunication networks have had the eect of reducing the cost of transmission bandwidth. Also, de-regulations, advanced distributed applications and telecommunication services have decreased the gap between telecommunication networks and computers. Computers are interconnected through telecommunication networks and telecommunication networks are using computers ([29]). The notion of Information or Intelligent Networks, i.e. networks controlled by software components and supporting a wide variety of services is becoming feasible ([29], [16], [1]). The demands for new advanced services from the customer has also been increased. Telecommunication companies are trying to satisfy the customer needs by adding more services on their networks. Although existing telephone networks provide some services, they are limited in scope and complexity. New networks need to be developed that oer facilities for implementing quickly a wide range of services in low cost and coping with the feature interaction problem ([18]). The ultimate goal of information networking is to provide a distributed software platform that supports the implementation and execution of network application, by hiding from the application the complexities of the underlying network ([29]). In order to achieve those goals, the logic of services has to be separated from the network control ([6]). This makes easier the implementation of new services and in fashion independent of the underlying network. There are several standards, one of the those the TINA Architecture ([29], [16], [1], [9]). 

This work has been supported by EPSRC and British Telecom

1

In this architecture, two main layers are de ned, the Service Provider Layer and the Network Layer. The second layer is concerned with network dependent details while the rst layer is built on top of the second, and provides a higher level view of the network. Therefore, services could be developed without low level networking considerations. For the implementation of such network management platforms object oriented software platforms are preferred like ANSA, Orbix etc. However, between existing software platforms and the conceptual models used for the application a signi cant gap still exists. An approach to this problem is to try to embed such high level features in the language. However, this will make the language design and implementation too complex. An alternative approach, and the one followed in this paper, is a layered one ( gure 1). A set of layers can be built on top of a basic platform which oers the main functionality. The layers on top extend the functionality of the layers below. In our application the lower layer is the April language ([7], [8]), a distributed symbolic programming language which supports concurrency, high level communication primitives (with pattern matching on messages), list data structures, higher order features etc. In addition, it has a powerful macro processor which made the implementation of the rest of the layers feasible. Application Layer

Additional Macro Layers

April Platform

Figure 1: The Layered Approach On top of April an object oriented and a database extension have been built comprising the April++ language. On top of April++ a number of application layers have been built, speci c for the application domains considered. This is the subject of section 2. Speci cally, a layer for supporting agent construction tailored for network management application has been built. Using this higher level features of April++ a generic agent architecture (described in section 3) is realised which oers the great advantage of integrating heterogeneous components and also allows the dynamic addition and deletion of such components. The components can function concurrently and this is due to the concurrency features of April and April++ in consequence. This architecture is further specialised (section 5) towards an agent system for specialised for network management applications (section 4). In the agent architecture a number of components are included whose functionality allows the agent to be used in the management of multi-service networks (section 6).

2 April++: The Implementation Platform April oers a number of the basic features that allow creation of concurrent processes, TCP/IP communication between them, high level communication primitives (with pattern matching on messages), list data structures, higher order features etc. However, the syntax of April processes is still low level. April++ is a macro extension of April. It extends its syntax with object oriented features. Also the data handling facilities are enhanced by a database layer which is a hybrid between Prolog and SQL. The main features of April++ can be summarised as: 2



 



 

Object classes can be de ned using single inheritance, with the usual Self and Super communication to access overriding and overridden methods respectively. Each object has public, visible and private state components. Objects are active, can be given public names, and can be distributed over the Internet. They communicate transparently with each other, irrespective of location. Objects can have new methods added as they are created and after they have been created. This allows us to dynamically modify a class de ned prototype object, and it gives the objects a learning and instruction capability. Objects can create clones of themselves, encapsulating all their current methods and state into a closure data value. A clone communicated to another object, residing on a dierent host, can then be forked by the receiving object allowing replication or migration of the original object. We can also store clones in an AdB data base, giving us object persistence. In addition to the normal state variables recording object state, objects can also use SQL style sets of records (with eld names) to encode part or all of the object state. Any of the extensional relations of an object's knowledge base can be optionally declared as foreign, external or persistent. A foreign relation is a public or visible relation of another object that can be queried as though it was local.

3 The Agent Architecture The agent layer, provides certain features that can facilitate various aspects of an agent system. In order to decide what features to support, a number of agent architectures were studied and certain features of them were abstracted. The architectures were ranging from quite abstract proposals of what agents should comprise ([4]) to more concrete artifacts designed for speci c kinds of applications ([12], [2], [26] and others). A common approach (nicely summarised in [14] p115 and [13] p86) to all of them is that an agent comprises a set of interrelated components whose functionality contributes to the overall agent behaviour. Also, the operation of those modules should preferably be concurrent, the concurrency being controlled by a control unit which consists the agent meta-level control unit. Finally, the agents should communicate with other external agents or applications in general, so a communication component is also needed. Considering these very general requirements, the general software architecture assumed is depicted in the following gure ( gure 2 on the following page). A common requirement of an agent architecture (in all the platforms studied) was that one of their components would be a knowledge base, which would keep information shared by all the other components. It is the global agent storage and can be used to store information of things such that beliefs, intentions, plans, meta-level information about other agents, communication knowledge etc. This knowledge base storage unit, can be accessed and updated by all other agent components. The behaviour that the agent exhibits is implemented by a number of sub-components (behaviour components). The behaviour components may dier from agent to agent. A general purpose behaviour by the agent (at least for the domains we are considering, such as Telecommunication systems and Enterprise Integration) is to be able to add and delete behaviour components dynamically. This allows the agent to be re-con gured at run-time and gives it the ability to adapt to new requirements that its environment imposes. The agent contains a \meta-component" that deals with the manipulation of the behaviour components. It contains special meta-methods that implement the addition and deletion of the components. When requests for such methods arrive at the agent, they are forwarded 3

Figure 2: The general agent architecture to this component. The functionality of the meta-level component can be augmented with more meta-methods (as it will be shown later on) that further customise the meta-level behaviour of the agent. The agent modules interact with each other, both by storing and retrieving information from the shared knowledge base and by messages. The message interaction is supported by a blackboard message posting component ([20]). All modules can place messages intended for other components on it, and consume messages intended for them, from it. A blackboard architecture, for facilitating component interaction, was chosen, because it allows heterogeneous information sources to be integrated. Also components can join and withdraw without disrupting the functionality of the rest of the agent. When a component joins the blackboard, it registers on it a number of lters. A lter is a procedure that is applied by the blackboard to each message newly posted on it. If the message is one that the subcomponent that registered the lter is interested in, the lter will automatically send a copy of the message to that component. The agents also need to have a communication mechanism that deals with incoming messages from other agents (components can communicate directly once the outside agent has become known). This is the purpose of the head communicator which is the external communication interface of the agent. The head communicator is also a security wall to the outside world. Incoming messages arrive rst at it, and are then forwarded to the blackboard in order to be considered by the agent components. Therefore, outside agents do not have direct access to the blackboard which is the internal agent backbone. The above conceptual architecture is consistent with most of the agent approaches ([12], [5], [2]), which comprise some domain dependent parts and with a domain independent agent layer on top ( gure 2). For the above architecture, the behaviour components are the domain dependent part and the knowledge base, blackboard and head are the agent layer.

4 Domain of Application The Multi-Agent Architecture described in this chapter is intended to manage a Multi-Service Network. The main assumption is that we have got two layers ( gure 3). The lower layer is the Physical Network 4

Layer and on top of that an Agent Layer resides that controls the physical one.

Figure 3: The Network Layers The physical network is a switch based network. It consists of a number of nodes which are connected by links. Using this physical network a number of services are implemented. A service can be requested (by a customer) between two nodes. Services vary in the requirements they impose on the network. They can dier in the bandwidth they require, the cost that the customer, requested them, is willing to pay etc. For example, voice or data based services need much less bandwidth than video based ones. Also long distance connections cost more than the short distance ones. Upon request of the service a suitable route is found and the service is established. The criteria for the route is the available bandwidth and the cost of the connection. The route is a collection of nodes connected with links. The ends of the route are the end points of the service. The service description (service id, Atlanda, London, 40, 8), speci es a connection between Atlanda and London, with bandwidth 40 units and maximum price that customer would accept 8 units. The above application has inherently a number of features that are summarised as follows:      

Physical decentralization of the application components. Dierent parts of the network are controlled by dierent control units Control units are involved in negotiation both with the physical network and with the customers who request services The capabilities of control units should be easily augmented to oer new services either implemented on top of the old ones, or implemented from scratch. The network is subject to failure and it should be capable of recovering with as little disruption to services as possible Since, during the control unit re-con guration the part of the network controlled by that unit, will be inoperable, it is essential to keep this period as short as possible.

Agents can be used as control units, controlling dierent parts of the network. Each has only limited, local knowledge of its environment, and it engages into negotiation with neighbouring agents 5

in order to ful ll requests for services. The service requests come from customers, and the negotiation with the customer is part of the agent functionality. Hence, the agents are the interface between the physical network and the customers. The elements of the physical network (links and nodes) are only capable of performing some very basic operations, such as directing a service through a single link etc. The logic of the network and more complicated functions are handled by the agent layer, in the spirit of the TINA approach.

5 The Agent Functionality The prototype system presented in this thesis was based on an initial system described in [15]. That system was a centralised simulation of a multi-agent system for network management. Starting from that implementation, we abstracted the functionality that was oered by that system and grouped it into several categories, itemised below:  Service requests: Deal with customer services  Service monitoring: Monitors the services after they have been established.  Link control: Deal with the control of the physical network  Fault Handling: Deals with troubleshooting of either the physical or the agent network. Based on those categories, a specialised architecture (illustrated in gure 4) was proposed ([19]).

Figure 4: The Agent Architecture The several agent components implement a dierent agent functionality. The customer unit handles the interaction with the customers that request network services. When a service request arrives, the customer unit will forward it to the service unit which will try to establish a network connection for that service. The agent interacts with the physical network through the link mediator which oers the interface to the physical components that the agent controls. When faults occur in the network, the fault unit is informed and will take appropriate action, depending on the type of fault. There is also a database unit where the several units store \global" information. The Customer unit could also interact with a number of external Directory Services in order to enhance the quality of services to the user. In the speci c prototype system, a KQML server was used. At this stage, it is not dicult to see how the architecture presented in section 3 can be tailored to match this specialised architecture. Each unit can be realised as a component of the generic agent. Since, the units can be complex, they can themselves be agents with their own subcomponents. The following gure ( gure 5) depicts the resulting agent in terms of the generic architecture. 6

Figure 5: The network agent as a generic agent The agent components are integrated through the blackboard. Requests, either by clients or by other agents, are received by the blackboard, placed on the blackboard and then forwarded to the appropriate component based on the lters the components have registered. Using the functionality of this architecture (as it was described in section 3), new components can be added or existing ones can be modi ed by new.

Summary of the Agent execution A simple example of the execution for an agent is described

in order to give an overall understading of its functionality. The example covers the case when a customer requests a service. A route is found for that service and the customer is informed. The steps involve only the specialised agent components and not the underlying agent architecture. The steps of execution are depicted in gure 6. The numbers in the gure specify the sequence of the messages exchanged.

Figure 6: A scenario for execution Initially the customer sends a customer request message to the customer unit (step 1). The customer unit processes the message and sends a route request message to the service unit (step 3). During this processing, it might contact a "Yellow Page" Server or any other information Server (step 2) in order to get some additional information. Service unit forwards this message to the router, a sub-component of the service unit, which does all the necessary processing to nd a route for the 7

service (step 4). The processing involves contacting other agents (step 5) for construction of the route. In order to collect the replies from the other agents, a new process the reply handler is forked. The reply handler collects all the replies (step 6). When the reply handler collects all the messages it replies them to the customer unit (step 7), which selects the best route and provides it to the customer who initiated the request.

6 Implementing the Individual Components The implementation details of the agent components is the subject of this section. Since the skeleton of the agent is oered (and has been implemented) by the the gereric architecture, the main eort for constructing a software platform for agent based multi-service network management is the implementation of the components. Summarising from the previous section, the agent consists of the following parts: Service Unit, Customer Unit, Fault Handling Unit, Link Mediator, Database and Head. All these are implemented as April++ classes or agents. The top level agent is represented as a class called telecomm agent, instances of which implement speci c agents. When such an instance is created, it initiates all the agent components (by appropriate statements in initial actions section of the class).

Service Unit

This is the part of the agent whose responsibility is to honour customer requests concerning network services. A customer (user or application) can request a service to be established between a source and a destination. A service is requested by sending a message of the form: (route_request, ( service_type?service, symbol?node, path_type?PathSoFar, number?cost ))

to the agent, which requests the agent to nd an appropriate path for the speci ed service. The service details contain service requirements and constraints (see section 4). It also contains the network node under consideration that the agent is controlling, the path constructed up to that point (PathSoFar) and the cost of that path (cost) which is the sum of the cost of the individual links. The message is received by the agent head and forwarded to the blackboard which is then passed to the service unit ( gure 7). Therefore, the service unit has to register a number of lters to the agent blackboard that will forward all the appropriate messages to it. The service unit will try to nd a suitable route for the speci ed service. When a route is found as a result of a route request message, the customer can send an establish service message which instructs the service unit to establish the service and make it available to the customer. The algorithm that is used to implement the routing is a distributed search one ([15]). Although a number of alternative algorithms exists ([25], [11]), this one has been chosen because it is used by the implementation of the rst prototype. Roughly, the way it works is, upon receive of a route request message, the agent tries to nd the next candidate nodes and links that the service can be routed through, until the destination is reached. Therefore, it contacts all the neighbour agents which control physical elements that are adjacent to its own ones, in order to nd available network resources for the requested service. It then propagates the route request message to the neighbour agents which will go through the same loop, recursively. When the destination is reached the route found (in terms of nodes visited up to that point) is replied all the way back. Route requests and route establishments, are two dierent functionalities that are implemented by two dierent components of the service unit. Therefore, the service unit has an agent structure itself, with a local blackboard and local components. Those two components are initiated (in the 8

initial actions section of the class de nition) when the service unit is started up (start up router and calls). The router deals with the establishment of routes (following the algorithm described earlier on) and the monitor unit deals with the establishment of services, after a route has been established. Any messages placed in the service unit are forwarded to the appropriate component.

start up monitor

The route request message for example is forwarded to the router unit. Hence, this results in a recursive agent structure, with the telecomm agent on the top-level of the hierarchy and the router, monitor unit at the leaves ( gure 7).

Figure 7: The recursive agent architecture The service unit and its sub-components have got access to two blackboards, the telecomm agent's blackboard and its local blackboard. The same holds for the knowledge base component of the agent, the two sub-components have got access to both the \global" telecomm agent knowledge base unit and the \local" service unit knowledge base. The reason for this, is that the sub-components might produce results, that might be of use to other agent components, regardless the level of the agent hierarchy. One of the advantages of using this agent architecture is that it can be modi ed dynamically. Suppose for example that a new routing algorithm has been implemented and we want to embed it, into the agent. This involves changing the existing router component with the new that has this new algorithm.

Link Processes

Each link, in the existing prototype system, is simulated as a separate process. The process is assumed to control its corresponding link. It keeps track of all the services that are using the link and also the available bandwidth. Based on this information it can decide on future services that wish to use this link. This approach makes the model more realistic, since in a real environment this would be the case, i.e. links and their controllers physically distributed and communicating with the agents through messages. During the establishment of service, there are two phases. The phase of nding a suitable route (where the router unit of the service unit is involved) and the phase where the customer agrees with the 9

agent's proposal and the agent is instructed to establish the service (the monitoring unit is involved in this phase). Therefore, two categories of services exist the candidate services that correspond to the rst phase and the established services for the second phase. Each link process possesses two relation tables (candidate service and established service) where services of those two types are stored. During the routing (done by the service unit), the link process might get a message to check whether a service can use the speci c link. In case there is available bandwidth and the cost up to that point does not exceed the cost constraints of the customer, then permission is granted. The remaining free bandwidth of this process is updated accordingly and also the service is added in the candidate services relation table. When the customer decides to accept one of the proposed routes, the link process (that happens to control a link that belongs to the selected route) receives a allocate service message, which causes the process to retract the service from the candidate services table and assert it in the established services table. When a service is not needed any more, then a release service message is posted to the link process to delete that service from the established services table, and free the reserved bandwidth.

Link Mediator

Recalling from previous sections, each agent controls a portion of the network. The agents exchange messages with each other in order to decide which resources (links, nodes) to be allocated for each service. The network elements are spatially scattered and the agent communicates with the processes that controls them (link processes in our case). For each agent, there exists a component that handles the interface between these processes and the rest of the agent units. It is called Link Mediator and it oers a uniform view of the link processes. It manages the interaction between the agent and the link processes, and thus relieves the rest of the units of such \low-level" details ( gure 8).

Figure 8: Link mediator and link processes What they see is a set of high-level routines for accessing the link status and enquiring links about their availability. The link mediators manages the interaction with the local links, and also does the negotiation with remote agents for adjacent links that they may be controlling. Thus, it consists of two sub-components, one that deals with the local links (local mediator) and one with the remote ones (remote mediator). During the routing process, the link mediator gets a request from the service unit about links that 10

can be used for a service. The enquiry involves two messages, one destined to the local mediator and the other to the remote mediator. For the local mediator a permission request message is sent. The method in this process that deals with the message will contact all the local link processes it is aware of (they are stored in the links relation table), in order to get information of which one of those have available bandwidth and appropriate cost constraints to serve the speci ed service. It gathers all the links that can accommodate the services and returns the resulting list to the service unit. The remote mediator, sends permission request messages to all the neighbour agents, in order to get permission for resources (links) they are controlling. The information about the agents is retrieved by the agent \global" database. The neighbouring agents, when are contacted, they enquire their local link mediators in order to get the information about the links. Any available links found are replied back in the link permission message. If not any available link for the speici ed service requirements were found, the denied keyword was used to signify that. The remote mediator, collects all the replied answers and returns them back to the local link mediator.

Fault-Repair Unit

It is the unit that deals with network and service disruptions. When for example a link fails, some services are disrupted. Care should be taken in order to re-establish those services through alternative routes. Other kinds of disruption is when a node or even an agent fails. Hence, the following submodules are necessary: the link repair unit, the node repair and the agent repair, each handling the corresponding malfunction case. Their implementation follows similar guidelines as the components described so far. The link repair handles the link failure, the node repair handles the failure of a network node and the agent repair handles the case of agent malfunction. In the rst two cases service re-routing is tried in order to bypass a network element failure, whereas in the last case a negotiation activity takes place between agents in order to decide which one will be the new manager of the resources the failed agent controlled.

Customer Unit

This component is responsible for handling interactions with the customers. It receives customer request messages from the customers, processes them, forwards them to the Service Unit (route requests are exchanged between agents whereas customer requests are between agents and customers). However, the Customer Unit is not just a simple interface. It can perform more complex processing on the incoming request. It can contact several information services which can provide information that can be used to provide an enhanced service to the customers. For example, customer instead of destination of a call could specify the name of a person with whom she wishes to talk to. The Customer unit could then look at a yellow page server in order to retrieve the location of the speci ed person. In the speci c prototype system, the agent Customer Unit uses a KQML interface in order to contact the Yellow Page server. April has been interfaced with KQML ([22]) using April's API ([7]). When now an Agent implemented in April wants to contact the Yellow Page Server, it sends an April message to the KQML Interface, this is translated to a KQML message and is forwarded to the Server. A second KQML server has been also implemented using AprilQ, a subset of April++. This is a fairly simple example of how the customer unit can oer extra service to the customers. Future work is intended to concentrate on a wider range and higher quality of services.

11

The agent knowledge base unit

This is the unit maintaining the information an agent is using. The information that is included here is the information that is used and shared by several units. This involves descriptions for the established, candidate, neighbouring agetns etc. This shared information is centralised in an agent, because if it was scattered through-out the agent's units it would be very dicult to access it and consistently maintain it.

7 Related Work There have been a number of experimental systems using Distributed Arti cial Intelligence (DAI) techniques in general and agent oriented systems in particular on the Telecommunication domain, especially for network management. A detailed discussion of applications of DAI in telecommunication systems is given in [28]. In [3] a Multistage Negotiation protocol, which extends the functionality of the contract net protocol is presented. The protocol was applied to the task of restoring transmission paths in telecommunication networks. The protocol was used by a number of agents that monitored dierent parts of a communications network. In this approach a plan based approach was adopted where a network fault resulted in a number of goals formed by the agents. The agents constructed partial plans to accomplish these goals, and the protocol was used to integrate these partial plans into a global one. In [10], an algorithm for heuristic search was presented, that can be used to reestablish interrupted connected in telecommunication networks. The work presented there was based on Distributed Arti cial Intelligence and was motivated by [3]. LODES ([24]) and DBB ([23]) systems are multi-agent systems developed for diagnosis and monitoring of TCP/IP-based LANs. In the rst system agents are organised into peer-to-peer relationships and in the second a hierarchical approach was followed. LODES ([24]) consists of a set of expert systems that control dierent aspects of a network and cooperate with each other in order to nd faults that occur in it. Dierent network segments are monitored by dierent LODES agents for the detection of faults. Copperation between those agents is necessary when a fault accurs in a part of the network monitored by more than one agent, or when an agent requires information by neighbouring agents. When a fault occurs, agents excehange messages with each other in order to locate the exact segment where the network problem occured. DBB is a system for monitoring TCP-IP based LANS, especially for fault recovery. It comprises a set of LAN systems controlled by a set of agents called LAN managers, and whose purpose is mostly fault handling. A Top manager integrates the LAN agents, resulting in a hierarchical structure. Responsibilities are assigned to the agents using a contract net like protocol. Therefore, the internal agent architecture was designed with this type of interaction in practice. Each agent had three components, a contracting a communication and a task process. TEAM-CPS ([27]) is a system tha twas most succesfully applied for customer network management. TEAM-CPS agents control a private network and interact with public network management. In TEAM-CPS agents there was great emphasis given on the problem solving activities the agents have to perform. In order to be able to reason about the speci c domain they maintain in a database beliefs and commitments about the real world state. They use this information during their local problem solving, which is a planning activity performed by the PRODIGY system ([17]). [21] deals with security aspects of network management. The interesting point in that approach, is the use of code that can be dynamically loaded into managed objects (used to implement security policies) an ability that is oered by the April++ and agent platforms. There are a number of dierences between the approaches reviewed above and the one presented 12

in this chapter. When an agent architecture was used it was especially built for the speci c problems the system had to deal with. Also, a lot of emphasis was given on the actual problem solving process the agent had to undertake rather than the agent architecture. In our case, a number of speci c pre-designed algorithms were implemented and a generic architecture was used and customised for the speci c application domain, rather than a specialised one being built from scratch. Also, none of the above approaches deal with the issue of dynamic re-con guration { a property that is especially useful for this kind of systems.

8 Summary and Concluding Remarks This chapter, presented the implementation details of an agent capable of network management for multi-service networks. The approach that was adopted, methodologically, was a layered one. On the bottom layer, there was April language and on top of that a numer of layers were built. The rst layer was a concurrent object oriented language, called April++. A generic agent architecture was implemented using April++. The agent for the network management was simply a specialisation of this architectured. In comprised the following components: customer unit, service unit, fault handler, link mediator, link processes and agent knowledge base. The main intention, was to demostrate how the functionality oered by the layers lower in the infrastructure (April++ and agent layer) can be used to facilitate the rapid prototyping of agent based applications for the domain of network management. Concerning speci c algorithms used for this application, we re-used the ones presented in [15]. One of the main advantages, which was not covered in detail, was that this agent architecture (and its implementation) oers is the ability to re-con gure the agents dynamically. New components that can add to the abilities of the agent, and oer additional services, can by dynamically added while the agent is executing. For example, the routing component presented, can be replaced by another which implements a dierent routing algorithm. The agent does not need to be terminated in order to achieve that, hence, satisfying one of the main criteria of the application domain.

References [1] J. Anderson. What is new in Intelligent Networking. IEE Tutorial on the Intelligent Network-The Next Generation, May 1995. [2] D. Cockburn and N. R. Jennings. ARCHON: A Distributed Arti cial Intelligence System for Industrial Applications. In G.M.P.O'Hare and N.R.Jennings, editors, Foundations of Distributed Arti cial Intelligence, chapter 12, pages 319{344. John Wiley & Sons, INC., 1996. [3] S. Conry, R.A. Meyer, and V.R. Lesser. Multistage negotiation in distribute planning. In A.H. Bond and L. Gasser, editors, Readings in Distributed Arti cial Intelligence. Morgan Kaufmann Publishers, Inc., San Mateo, CA, 1988. [4] Y. Demazeau and Jean Pierre M'uller. Decentralised Arti cial Intelligence. In Y. Demazeau and Jean Pierre M'uller, editors, Decentralised Arti cial Intelligence, pages 3{13. Elsevier Science Publisher, 1990. [5] Donald D. Steiner. IMAGINE: An Integrated Environment for Constructing Distributed Arti cial Intelligence Systems. In G. M. P. O'Hare and N. R. Jennings, editors, Foundations of Distributed Arti cial Intelligence, chapter 13, pages 345{364. John Wiley & Sons, INC., 1996. 13

[6] Garrahan et. al. Intelligent Network Overview. IEEE Communications Magazine, March 1993. [7] Frank McCabe. April reference manual. Technical report, Fujitsu Laboratories Ltd., Japan, 1996. [8] Frank McCabe and Keith L. Clark. April { Agent PRocess Interaction Language. Intelligent Agents, 1994. [9] N. Gatti. A Comparison of IN and TINA through a Service Scenario. IEE Tutorial on the Intelligent Network-The Next G eneration, May 1995. [10] T. Gyires and K. Muthuswamy. Heuristic Routing Algorithm for Reestablishing Interrupted Connections in Telecommunication Networks. ECAI'96 workshop on Intelligent Agents and Telecommunication Architectures (IATA'96, 1996. [11] F. Halsall. Data communications, computer networks and open systems. Addison-Wesley, 1996. [12] H. Heugeneden, editor. IMAGINE nal report. Siemens, Munich, Germany, 1994. [13] L.P. Kaelbling. A situated automata approach to the design of embedded systems. SIGART Bulletin, 1991. [14] P. Maes. The agent network architecture (ANA). SIGART Bulletin, 1991. [15] B. Marius and Yadegar. Cooperating Intelligent Agents in Telecommunication Network Management Application. Technical report, BT Technical Report, 1992. [16] Menso Appeldorn, Roberto Kung, and Roberto Saracco. TMN+IN = TINA. IEEE Communications Magazine, March 1993. [17] S. Minton et al. PRODIGY 2.0: The manual and tutorial. Technical report, Carnegie Mellon University, CMU-CS-89-146, 1989. [18] Nancy Grieth and Yow-Jian Lin. Extending Telecommunications Systems: The Future Interaction Problem. Computer IEEE, 1993. [19] Nikolaos Skarmeas and Keith Clark. Intelligent Agents for Telecoms Applications (IATA'96). IATA'96 Workshop of the European Conference on Arti cial Intelligence, August 1996. [20] H. Penny Nii. Blackboard Systems: The Blackboard Model of Problem Solving and the Evolution of Blackboard Architectures. The AI Magazine, pages 38{53, Summer 1996. [21] J. Reilly. Security aspects of Intelligent Agent based extensions to the TMN management framework. ECAI'96 workshop on Intelligent Agents and Telecommunication Architectures (IATA'96, 1996. [22] Richard Jones. A KQML Interface for April. Technical report, MSc. Thesis, Imperial College, London, 1995. [23] Y. P. So and E. H. Durfee. A Distributed Problem Solving System for Computer Network Management. International Journal of Intelligent and Cooperative Information Systems, 1(2), 1992. [24] T. Sugawara and K. Murakami. A multi-agent diagnostic system for internetwork problems. Proceedings of INET'92, 1992. 14

[25] A. S. Tanenbaum. Computer networks. Prentice Hall, 1996. [26] Victor R. Lesser and Daniel D. Corkill. The Distributed Vehicle Monitoring Testbed: A Tool for Investigating Didtributed Problem Solving Networks. The AI Magazine, pages 15{33, Fall 1994. [27] R. Weihmayer and R. Brandeau. Cooperative Distributed Problem Solving for Communication Network Management. Computer Communications, 13(9), 1990. [28] R. Weihmayer and H. Velthuijsen. Distributed AI and Cooperative Systems for Telecommunications. In J. Liebowitz and D.S. Prerau, editors, Worldwide Intelligent Systems. ISO Press, 1995. [29] William J. Barr, Trevor Boyd, and Yuji Inoue. The TINA Initiative. IEEE Communications Magazine, March 1993.

15