Support for Heterogeneous Environments

Criterion. Networks are in general composed of a heterogeneous set of software and hardware elements. Moreover, they are continuously evolving over time due to software and hardware upgrades, capacity dimensioning and changes in user profiles.

This section discusses how the MA and the SA approaches deal with the problem of the heterogeneity of ATM switches and evaluates the cost of supporting a new type of switches with a different management interface.

Comparison. In the MA approach, the MA interacts with VMCs to manage switch re-sources. The VMC offers an abstract view of the switch and acts as a bridge between the MA and the managed resources. Therefore, there is no need to change the MA code to support a new type of ATM switches. What is needed is to develop the VMC and to de-ploy it to the MCD of the new switch. The process of dynamic download of VMC code is supported by the MA platform (Section 8.2.2).

In the SA approach, a new switch skill (see Section 6.3) containing the necessary ca-pabilities to manage the new switch must be developed and integrated inside the SA. The switch skill offers a common abstract management view of the new ATM switch. Simi-larly to the VMC in the case of the MA, the new switch skill can be dynamically integrated into the SA.

Hence, both approaches offer the same degree of ease of portability and support for new types of ATM devices.

There is however a noticeable difference between the two approaches. In the MA approach, the VMC isnot part of the agent, but part of its supporting runtime environ-ment, whereas in the SA approach, the switch skillisof the agent. Of course, the switch skill module could be separate from the SA and implemented as a separated entity on the ATM switch. However, there was neither an advantage, nor a necessity in introducing a separate VMC in the case of SAs. In contrast, if there were not a homogeneous

manage-ment interface provided by VMCs, MAs would have to include the knowledge to handle switch heterogeneity, hence a sensible increase in the MA size.

MAs are therefore not suitable to directly using low-level management protocols and MIBs. They require an additional component that offers a higher-level and a homoge-neous access interface regardless of device heterogeneity.

8.3.6 Flexibility

Criterion. Flexibility is the ability to adapt to new, different or changing management requirements. From a practical perspective, it means for the network administrator not to be tightened to a certain management protocol or technology when trying to achieve the required management operations. For example, an SNMP agent is not flexible since it is usually impossible to extend its functionality or enrich its instrumentation capability.

Comparison. At first sight, both MA and SA approaches seem to be equivalent in flexi-bility. Both approaches allow to easily extend the functionality of the agent system. The MA approach allows developing new MAs with new or improved management functions.

It also allows improving the instrumentation of the switches by uploading new versions of VMCs into the switches. Similarly, the SA approach allows to plug new skills with new or improved management functions into the already running SAs and then to dynami-cally invoke these new functions.

However, there is an important difference that can be shown through the following scenario. We assume that we want to replace the algorithm of PVC creation in the ATM network — e.g. in order to improve the bandwidth allocation algorithm. We suppose that the new version of the algorithm is already developed for both approaches, and we need to replace the old version.

In the SA approach, a new skill version is provided and should be plugged into the SAs.

If we suppose that some PVCs are under establishment, then it is not directly possible to guarantee that the same skill version is used. The same PVC creation process could start using the old version and meanwhile the new version is uploaded inside the SAs and will be used for the remainder of the PVC route. This may lead to incoherent configurations if the two skill versions are not compatible. Consequently, there should be a mechanism that ensures version coherence during the establishment of end-to-end PVCs.

The MA approach naturally avoids such problems. In fact, the code of an MA respon-sible for the creation of a certain PVC does not change during the whole process. During its life cycle, the MA has either the old version or the new version and it is sure that the same version of the algorithm is used until the PVC creation process is terminated.

This example shows how MAs can help preserving coherence while updating the ap-plication and therefore, offer enhanced flexibility to the network administrator. The SA approach would require an offline time during which the new skill is upgraded into all the SAs before the PVC provision application could be made operational back again.

8.4 Conclusion

The starting point of the work described in this chapter is that both Mobile Agents and cooperative Static Agents have interesting potentials in dealing with NM problems. Ex-pertise to assess both approaches is therefore urgently needed, and a case study based comparison between MAs and SAs is of a great help in this direction.

Although they prove to be less efficient than SAs, MAs offer other interesting advan-tages. From a design point of view, they offer a great transparency to distribution-related issues such as information distribution, task synchronization and coordination, time un-certainty and concurrence. An MA is indeed a compact piece of software thatis designed monolithically and acts distributedly. In addition, the case study pinpoints that the rea-son behind this advantage is mainly the property ofself-containment, i.e. the MA is sup-plied with all the necessary information and know-how to perform its management duty without any help from another agent. If we observe the qualitative criteria used for our comparison, we find out that self-containment is also behind the enhanced flexibility of MAs over SAs, and the better support for robustness. In addition, the advantage of MAs over SAs in the case of ease of deployment is due to the fact that the MA does not re-quire initial code deployment, since it directly encapsulates the know-how to achieve its management task.

In turn, this shows that the main bottleneck of MAs is inter-agent communication, which is exactly the strong point of SAs. In fact, not every NM application can be de-signed through independent tasks that can be encapsulated in self-contained MAs. In many cases, the distributed nature of NM problems requires to have interacting entities that exchange information flow and task flow messages. SAs are specially fitted to such situations. In addition to the direct support for high-level communication, SAs have a clear advantage over MAs in terms of efficiency and performance. In that, they can ex-ecute tasks in parallel thus improving response time, and can exchange concise mes-sages thus reducing the generated management traffic. Another advantage is that they are much less sensitive than MAs to an increase in their size, and can encapsulate arbi-trarily complex functionality.

Concerning the other qualitative criteria, MAs and SAs have comparable satisfactory degrees. For MAs, this is due to mobility and self-containment. For SAs, this is due to the

dynamic skill loading capability provided by our skill-based agent architecture. As men-tioned in Chapter 4, dynamic skill loading is not an inherent property of software agents as perceived in the agent community, but rather is a design choice that we adopted in an-swer to NM requirements. The work described in this chapter shows that the skill-based approach provides a balanced compromise between fully-mobile agents and inflexible distributed SAs. The flexibility and ease of deployment exhibited by MAs are replaced by dynamic skill loading, which provides a sufficient degree of flexibility, while still allowing to build highly efficient management applications. Of course, our architecture excels by providing a general purpose support for building a large choice of distributed NM appli-cations, instead of being particularly suitable for a specific range of NM applications.

Chapter 9

Conclusion

Network Management is facing many challenges due to the recent evolutions in networks and networked applications and services. There are many new trends in NM that try to tackle these challenges. In general, these trends make use of well-established techniques from other computing fields (e.g. CORBA, XML, Java, and web technology), which they adapt to NM problems.

Software agents are another trend in NM that differs from the other trends at least in two aspects. The first aspect is that agent technology contrarily to the other approaches, is not yet well defined. Debates are still ongoing regarding the definition of an agent, and the different possible types of agent architectures and systems. The second aspect is that it is still unclear from an NM standpoint what challenges can be addressed by software agents, and whether it is really opportune to deploy them in management systems.

The purpose of my thesis was to help drawing the way agents can be successfully applied in NM software.