Chapter 6. Network Management Software Components

We now describe some of the internal software components that combine to make up an NMS. As we've seen, network management is complex, and the requirements of most organizations are normally filled using a range of software products. The discussion in this chapter uses the FCAPS areas as the pillars that support and logically separate the subject treatment. As usual, to illustrate principles, we liberally dip into the areas of device technology, MPLS, ATM, FR, and so on. There are many possible solutions to NMS development ”this chapter describes just one possible structure. The following NMS software areas (and subareas) are described:

Server-side components
Network-receiving asynchronous
Network-receiving synchronous
Network-sending
Database access
Client-side components
Middleware components
Data representation, such as XML
Northbound interface (NBI)

This rounds out the theoretical and practical discussion of NMS in preparation for the case study in Chapter 8, "Case Study: MPLS Network Management." Some of the above are illustrated in Figure 6-1; the rest are described later in the chapter.

Figure 6-1. NMS components and data flows.

graphics/06fig01.gif

The out-of- band channel is noteworthy because it allows for network management traffic to use a separate channel from the one used for data (conceptually similar to the way signaling is implemented in SS7 networks). This helps avoid the twin problems of:

Network management traffic causing congestion in the service network
Service traffic congestion starving off the management channel

Server components are the prime movers or workhorses in an NMS, performing the bulk of the workload. Typical servers provide the following functions:

Servicing client user requests
Issuing provisioning operations, such as writing to agent MIBs (inserting table entries, updating/deleting existing objects)
Special-purpose listening operations, such as monitoring LSP operational state
Providing generic services, such as scheduling
Providing specific services, such as NE firmware and configuration database backup, restore, and distribution
Handling incoming notifications from the network

All of these server-side functions can result in database access. The database forms the glue that ties together the major components of:

Clients
Middleware
Servers
NEs

Thin clients tend not to use the database directly and instead rely on the servers to manage the database, for example,

Recording client-initiated operations, such as creating FR or ATM virtual circuits
Storing the details of scheduled operations and associated results

As we saw in previous chapters, thin clients can be based on standard Web browsers. Since there can be many such clients ( potentially hundreds for large networks), where to carry out the bulk of the processing is an important design decision. If the principal requirement for client software is fast execution, then as much as possible of the MIB and database access should be carried out by the client rather than the server. This is a good way of offloading server capacity, but it does require more secure clients. Similarly, if the client software is required to be simple and intuitive to use, then it should be designed to be as generic as possible. Generic software hides complex network data as much as possible and presents simple visual objects providing default values where appropriate. An example of this is terminal-server interface configuration (mentioned in passing in Chapter 1, "Large Enterprise Networks"), as illustrated in Figure 6-2.

Figure 6-2. Terminal-server interface management.

graphics/06fig02.gif

Let's assume the user wants to access the text-based menu system provided by the digital cross-connect on a remote site. A digital cross-connect is a device that allows incoming TDM channels to be groomed into higher or lower bandwidth circuits. Figure 6-2 illustrates an incoming T3 out of which a T1 and two concatenated T1s are extracted and transmitted onward in another direction. In this example, the digital cross-connect is a legacy NE that provides a simple serial interface for management using a text menu system rather than SNMP. It can be reached via modem X connected to Interface A on the local terminal server. The user connects to Interface A using telnet and can then start sending commands to modem X, for instance, dialing out to modem Y. However, before Interface A can be used, it must be configured. Some terminal servers allow the use of SNMP to set and get the configuration of their serial interfaces. So, let's assume the user wants to configure Interface A. Typically, this involves setting the MIB object values for:

Bit rate
Parity
Number of data bits
Number of start bits
Number of stop bits, and so on

To facilitate this, the NMS should present the user with a dialog that is as generic as possible and provides defaults for most of the above objects. The user can then apply the required changes and set the appropriate row in the terminal server agent MIB. If other interface types (beyond the serial variety) are set using the NMS, then the software should try to make them all look as similar as possible. This example also illustrates the way a flexible NMS, by incorporating extra infrastructure like terminal servers, can add value to (and extend the lifespan of) NEs that do not themselves host facilities like SNMP agents .

Middleware components provide a convenient means by which clients can communicate with server software. CORBA-based products are an example of middleware technology, though there are others, such as Java RMI, RPC, and even Java 2 Enterprise Edition (J2EE). Very often, client software may consist of Web browser-based Java applets. This approach leverages desktop COTS software (i.e., browsers) and the Java programming language. On the other hand, client software may consist of full-featured C/C++ standalone applications.

We now start the discussion of the FCAPS server components with the Fault Server.