Other Servers

The FCAPS servers form what may be considered a baseline for NMS products. Some NE and NMS software vendors tend to add extra servers for product differentiation and to enhance NE manageability. We now briefly describe some of these.

Discovery

A Discovery Server exists to keep up with the details of the deployed NEs. Discovery can be considered an extension of our Configuration Server and typically tries to maintain parity between the deployed NEs and the NMS. Discovery may keep track of objects such as the following:

• Nodes

• Interfaces and underlying stacks

• Links

• Virtual connections

• Cross connections between different technologies

• Routing protocols

• Routing tables

• Signaling protocols

Various methods are used for tracking these objects, including:

• ICMP (if the NEs support this)

• SNMP

• Standard and proprietary signaling protocols

Discovery software can make use of both the management and control planes, for example, SNMP and IP routing tables.

Monitoring

A Monitoring Server processes managed objects that change value in some fashion; for example, it monitors interface operational status. This is a facility by which the following can be achieved:

• Rapid updates of discovered topology data

• Expedited rediscovery of managed objects that have changed

Typically, discovered objects are subsequently processed by Monitoring. Consider the case of an LSP initially discovered in the operationally down state. On the next cycle, Monitoring detects no change in the LSP state. Next , the user sets the administrative status of the LSP from down to up, and this is written to the MIB of the associated NE. Assuming there are no problems with the LSP (NEs are configured correctly, connectivity exists, etc.), the operational state then changes to up. When Monitoring comes around to the node again, it will note that the state has changed and mark up the associated database entry. In this way, Discovery can offload some of its processing. This process may be improved by making it notification-driven. In this, an NE sends a notification, such as a link up: This is processed by the Fault Server that in turn signals Discovery.

NE Software Distribution

NE software changes must be installed on deployed devices. This can be achieved using a variety of methods:

• FTP/TFTP

• Proprietary download mechanisms

• Using an NMS

Some NMS provide a means of distributing NE software. Typically, this can involve a number of steps:

• Preparing the NE for a new firmware load

• Rerouting traffic around any nodes to which downloads are pending

• Initiating the transfer

• Handling rollback if the transfer fails

• Verifying the transfer succeeded

• Starting up the new NE software (rebooting, copying the image from FLASH to RAM, etc.)

Preparing the NE may involve issues like:

• Bringing the NE into a quiescent state

• Closing down existing connections

• Ensuring that no resources are in use on the NE

• Determining the available FLASH and RAM free space

• Taking a copy of the existing firmware

Once the NE is ready, the transfer can start. Errorsfor example, a loss of connectivity or an image that has become bad and will not allow a successful restartmust be catered to both during and after a transfer. The latter may require manual intervention. Rollback of the previous version is important for getting back to a working firmware build. Some NEs may provide sufficient FLASH to store the old imagethis can be deleted if required, or left onboard. In all cases, the NMS should record the detailed results of the software distribution operation, for example,

• New version of NE software

• Old version of NE software

• Is old version still on NE?

• Was upgrade successful?

• Was rollback necessary?

• Was rollback successful?

An important point about this is that an NMS may carry out multiple simultaneous software distribution operations. This might be required for upgrading a large network, and it makes the operation quite complex.

NE Configuration Database Backup and Restore

Just as for firmware distribution, NE configuration data is increasingly important, particularly as device complexity increases . Some reasons for the importance of backing up configuration data are:

• New firmware builds may upgrade the configuration, making rollback difficult

• Disaster recovery

• Creating mirror networks

• Using a given configuration as a template

Probably the most critical of these is disaster recovery in which it is required to completely reinstate the configuration of one NE or even an entire network. Typically, the user would like to be able to use a GUI to point and click certain nodes and restore them. The NMS should handle the complexities of:

• Knowing where the appropriate configuration data files are located

• Handling the transfer via FTP, TFTP, and so on

• Restarting the NEs or reloading the data files

• Informing the operator when the operation is complete

• Rerouting traffic around the nodes being restored

The guiding principle here is that the NMS should help the operator to quickly and efficiently execute the task.

NMS Database Backup, Restore, and Upgrade

The overall NMS database is a high-value item. It requires regular maintenance, and two very important operations are backup and restore. Normally, the database is a third-party engine of some kind, such as Informix, Oracle, or SQL Server. Either the vendor tools can be used for the database maintenance or software can be written specially for this purpose.

Network operators don't like losing data, so when the network management software is updated, it is important that existing data is retained. In other words, upgrade is an important aspect of software releases. The NMS software vendor must take great care to maintain an upgrade path for user data.

Configuring NEs

The increasing complexity of NEs makes their configuration more difficult as technologies are added and entire networks are compressed into them. An MPLS LER will generally be connected to a minimum of two technologies: IP and MPLS. It may also be connected to a number of additional technologies, such as FR, SONET, or dense wavelength division multiplexing (DWDM). In this example we assume just IP and MPLS. Let's assume that our LER has incoming links from three high-speed IP routers and outgoing links to two MPLS LSRs, as shown in Figure 6-8.

Figure 6-8. The problem of configuring multiservice networks.

Configuring the MPLS nodes in this network typically consists of the following steps:

• Assigning the interface IP addresses

• Assigning the neighbor IP addresses

• Assigning the interface subnet masks

• Configuring signaling protocols

• Configuring routing protocols

• Creating routing areas, levels, peers, and so on

These steps may be necessary for each of the MPLS nodes in Figure 6-8.

In many cases, configuration of networks is done using CLI scripts. An NMS can achieve this relatively easily by the use of software-driven wizards. This applies particularly to the case where IP addresses are assigned in blocks (as is the case in Figure 6-8). Starting with the LER, we can assign seed addresses and just decrement in order to calculate the neighbor. The commands to set up the various protocols and routing objects can also be executed by the Configuration Server.

As networks grow, the problem of reconfiguration can be difficult. Renumbering large IP networks with thousands of nodes can be a tedious and error-prone task. By maintaining configuration in the NMS, the reconfiguration becomes a software function into which an operator feeds data.

Middleware

Middleware is that part of an NMS that allows communication between the clients and servers. There is a broad range of software technology choices for achieving this, including RPC, Java RMI, CORBA, J2EE, and Microsoft .NET.

RPC and RMI allow the realization of simple distributed objects in a fairly low-level fashion. The developer must understand a lot about the mechanisms in order to use these facilities. However, they are very powerful. CORBA offers a more abstract interface and allows code in multiple languages to use a shared set of objects on any platform that has an Object Request Broker (ORB) available. CORBA provides a migration patha compelling reason for organizations using legacy languages to continue doing so. In other words, CORBA products can help to defer the decision to invest in a new and perhaps relatively unproved technology such as (possibly) J2EE and Microsoft .NET. However, for NMS, CORBA may have issues in getting past firewalls.

Data Representation

XML is an increasingly widely deployed metalanguage for data representation. It can be used to encode any type of data in a platform-independent fashion, including:

• Multivendor MIB objects

• Fault MIB objects

XML is used in the OpenNMS product mentioned earlier. SOAP is a relatively new data-exchange and messaging framework based on XML over HTTP. HTTP is not a high-performance data protocol, but it can be used as an NMS client/server transport protocol. It also has the merit of not being blocked by firewalls. It is likely that Simple Object Access Protocol (SOAP) will come to have an important bearing on NMS technology, particularly as the concepts of Web Services permeate the area.

Northbound Interface

Integration between an OSS and an NMS is facilitated with an NBI [Telcordia]. There are many possible forms for this software interface:

• IDL

• TL1

• SNMP

The importance of the NBI cannot be overstated. It allows for data and commands and responses to flow between an OSS and the underlying NMS. A fully instrumented NBI allows an OSS to automate all the exposed major features of the NMS, including:

• Connection management : creation, modification, and deletion

• Route object management : MPLS EROs, and ATM DTLs

• Fault management : retrieval, and clearing

• Resource block management : creation, modification, and deletion of MPLS resources

Somewhat confusingly, the Telcordia Web site refers to the latter as an EMS when in fact it is generally an NMS because it has a broader context than just one NE (as is the case with an EMS).

The Trend Towards Java-Based NMS

The use of Web browser-based clients has enhanced the importance of Java [JavaDev] for NMS development. There are several reasons for this; for example, many browsers support a Java Runtime Environment by default. This allows the execution of Java applets during normal browsing. In other words, you can run Java code by interaction with Web site pages, such as pressing buttons and filling out and submitting forms, This capability fulfils many of the NMS client-side requirements. Java is:

• Platform-independentruns on any platform with a Java Virtual Machine (JVM)

• Browser-enabled

• Object oriented

• Able to support field- replaceable packages

• Secure

• Reasonably good in terms of performance

Java code runs as JVM bytecodes that are interpreted in the JVM, (Just-In-Time) JIT compiled, or compiled entirely into native code. Perhaps the most compelling reasons for the use of Java is its combination of platform-independence and security.