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. DiscoveryA 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:
Various methods are used for tracking these objects, including:
Discovery software can make use of both the management and control planes, for example, SNMP and IP routing tables. MonitoringA 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:
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 DistributionNE software changes must be installed on deployed devices. This can be achieved using a variety of methods:
Some NMS provide a means of distributing NE software. Typically, this can involve a number of steps:
Preparing the NE may involve issues like:
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,
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 RestoreJust 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:
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:
The guiding principle here is that the NMS should help the operator to quickly and efficiently execute the task. NMS Database Backup, Restore, and UpgradeThe 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 NEsThe 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:
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. MiddlewareMiddleware 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 RepresentationXML 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:
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 InterfaceIntegration between an OSS and an NMS is facilitated with an NBI [Telcordia]. There are many possible forms for this software interface:
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:
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 NMSThe 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:
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. |