This section elaborates on the implications of the identified requirements: flexibility, genericity and dynamism.
4.2.1 Flexibility
In a flexible management system, the network administrator should be able to seamlessly initiate new management operations and introduce modifications on currently running tasks. This is necessary to be able to reflect the enterprise business strategies and adapt the network accordingly. For example, an abuse in using network resources may lead the network administrator to set up a usage based accounting. The accounting func-tion may not have been planned in the initial requirements for the management system.
In this case, the administrator has to be able to introduce the new accounting function and, importantly, without disturbing the other management activities. This requirement imposes a highly modular approach in which the management know-how can be encap-sulated into modules. Moreover, modules should beloosely-coupledin a way that allows the agent to acquire new management capability modules at runtime, without stopping its execution.
4.2.2 Genericity
We showed in the previous chapter how different agent techniques have been success-fully applied for NM purposes. However, it became clear that a unique set of agent tech-niques cannot suffice by themselves to all the fields and functional areas of NM. There-fore, any agent architecture that is based only on a limited selection of agent concepts would have potential limitations when applied to NM.
A successful agent framework should allow to use the right agent oriented technique for the right management application. Take agent communication as an example. It is obviously preferable to have a built-in ACL that allows for high-level communications between the agents, e.g. `a la KQML. However, one should be able to use another commu-nication language when required. For example, a particular management application that requires intensive agent communication would require a more efficient and concise language than KQML. In other situations, an agent system may include particular agents that support two or more agent communication mechanisms to interoperate with an-other different agent system.
In hierarchically-organized network management, an agent can delegate tasks to agents under its authority simply using ‘orders’. This is the way most of the management systems are currently organized. However for some tasks, delegation is better supported using negotiation. The delegator agent negotiates with the delegatee agent on the way the task has to be achieved in order to maximize a certain utility function. Suitably, this applies to the task of monitoring a particular component (or set of components) in the network, for which the delegator has to choose the monitoring agent that generates the least polling traffic. The advantage of a generic agent architecture is the ability to support both types of delegation: order-based, and negotiation-based.
As for the flexibility requirement, genericity requires agent capabilities to be encap-sulated in highly loosly-coupled modules that the agent can acquire dynamically at run-time.
4.2.3 Dynamism
Consider a typical network composed of routing and switching devices, server machines, and end-user client hosts. Such networks dynamically evolve in their topology, hardware, and services and applications software. Moreover, network users evolve in the way they make use of network services according to their changing usage profiles. Network per-formance patterns and resource usages can dramatically change as user profiles evolve and new services and applications are installed.
An NMS has to cope with such evolution. Particularly, for an agent-based NMS this has two implications on the agent architecture. The first is that an agent must have a common repository of all its beliefs on the managed network. As the network behav-ior evolves, relevant events are captured by changes in the agent beliefs and the agent can adapt its behavior according to these changes. Not only the beliefs themselves may evolve, but the agent has also to integrate new kinds of beliefs, orbelief templates, dy-namically without interrupting its operation.
The second implication is that the agent activity has to dynamically adapt to network changes. The agent tasks has to be notified of relevant changes in the agent’s beliefs.
Consequently, a belief notification mechanism based on a publish-subscribe-like pattern has to be introduced. The publish-subscribe pattern allows to have multiple observers that are automaticallynotifiedwhen relevant changes in the agent beliefs occur. This notification mechanism allows to propagate changes on the network structure, topol-ogy or configuration, in a way that management tasks can accommodate their execution accordingly. These notifications have to be available both inside each agent as well as between distant agents, i.e. an agent may coordinate its activities according to the beliefs of the other agents.
In the following, we describe how these requirements are mapped to our agent archi-tecture.
4.2.4 Architectural Principles
Both flexibility and genericity back the fact that the agent does not have to tight to its initial role and functionality for which it was built. Instead, the agent can acquire new capabilities that allow to have new kinds of behavior, and to perform different manage-ment activities than those for which it was designed. This requires that agent capabilities be encapsulated into strongly moduled pieces of software. Each module provides the agent with the competence and skill to perform a new task or set of tasks. Hence, we introduce the “skill” as an encapsulation of the necessary components that define a new functionality for the agent.
Support for adaptability and dynamism requires that the agent can acquire new skills dynamically at runtime without interrupting its ongoing activities. The runtime integra-tion of the new skills suggests that the agent has a core structure to enable this feature.
Hence, we introduce the “brain”, which is a common component that ensures the basic functions of an agent. If we refer to the basic agent architecture drawn in Section 2.2 (see Figure 2.1), then we conclude that the basic functions of the brain are to manage the agent beliefs and to tract its actions. In our case, the brain has in addition to manage the dynamic integration of skills, and their possible interactions.
The agent brain only provides a part of the agent default behavior. Decision making and agent behaviors are rather provided by the skills. Skills offer a modular approach to provide the agent with new features related to a certain Network Management (fault detection, monitoring, etc) or agent-oriented aspect (agent communication language, learning, etc). These features require the definition of new belief templates and new
ca-pabilities, where the capabilites encode the know-how related to a certain management activity or agent behavior.
Skills have to dynamically and seamlessly integrate into the agent brain. Therefore, the brain has to be able todiscoverthe content of a skill at runtime. This is the require-ment of loose coupling between the skills and the agent brain. Loose coupling requires a declarative approach by which the skill ‘declares’ the belief templates and the capabil-ities it defines. The brain uses this declared information to integrate skills dynamically and to insure the role of the mediator between them.
Another aspect that allows skills to integrate dynamically into the agent is that all skills must have equal access to the brain. This means that skills cana priori equally manipulate the agent beliefs and cause the agent to initiate actions. The most suitable approach for this kind of equitable access is horizontal layering, where in our case, layers are assimilated to skills. This is illustrated in Figure 4.1 adapted from [Woo99]. The characterizing property of horizontal layering in agent architectures is that all the layers have equal access to the agent sensory input and effectory output.
Layer Layer Layer Layer
Brain
Beliefs Actions
Action Output Perceptual
Input
Figure 4.1: Horizontal layering
The added value of our approach compared to horizontal layering is that layers can be dynamically added to and removed from the agent. This is essential to provide the required levels of dynamic flexibility and genericity analyzed in the previous sections.
The final aspect for our agent architecture is that a KQML-like communication mech-anism is supplied as a built-in protocol inside the agent brain. This communication mechanism is pragmatically developed in order to provide basic interactions between
the agents, particularly notification-based and delegation-based interactions. Of course, an agent system is not tightened to this communication mechanism and new skills im-plementing other communication mechanisms can be developed if need be.
Java is adopted as the implementation language, which leads to a portable agent pro-totype framework.
The following sections detail these different aspects of our agent architecture.