Summary

The implementation of NMS software can take the form of servers. These are high-performance software objects that can support interactions with both external clients and NEs. It is essential that servers are resilient and designed so that they are unlikely to fail except in exceptional circumstances. They form the intermediate layer through which end users can securely communicate with NEs.

We reviewed a variety of such servers that implement the FCAPS areas of network management. We also discussed other servers, used for tasks such as firmware distribution, that can enhance the experience of managing networks.

The need for generic software components is growing with the increasing deployment of dense, multiservice NEs. Generic software attempts to abstract complex NE data as much as possible and present simple GUIs applicable across a broad range of devices. An example was briefly described of terminal-server interface configuration, and multiservice switch configuration was described as well.

Software to implement the FCAPS areas generally does not consist of standalone, isolated components. Instead, there is often a need for server interaction; for instance, a faulty link may be of interest to the Performance Server because it directly impacts an SLA. All the servers make use of the high-performance data storage and retrieval services of a central database engine product such as Oracle or Informix.

On the client side, GUI views are often depicted as network topologies accompanied by fault listings. It is a major challenge for the NMS software to keep these views synchronized with the network. It is always hard to escape from legacy NEs, and for this reason it is often necessary for server components to be SNMP multilingual, that is, able to use any of SNMPv1/2c/3. Security is an increasingly important aspect of managing networks, and it is essential that NMS accommodate this trend. It is possible that security considerations may even have a bearing on the way networks are configured and commissioned ”it may be required in the future to set up networks only via the NMS rather than via a CLI. Depending on the implementation, this could:

• Help the operator achieve the configuration task via automatic help facilities

• Facilitate bulk configuration, such as of SNMPv3 security settings

• Enhance security

• Provide audit trails of commands sent to the NEs

However, the NMS and its underlying host must be secure. The choice of middleware is important, dictated by needs such as:

• Multilanguage support (not always required)

• Multiplatform support (Java provides this)

• Microsoft solution (.NET provides this)

XML provides an increasingly popular data facility. The NBI is a crucial component of an NMS because it allows for automation. Finally, Java offers many advantages, and it is interesting to note that its use for NMS development is growing. The platform-independent security model offered as part of Java may be one of the most compelling reasons for its adoption.