Network Discovery and Mapping

Discovery is a useful NMS feature by which NEs are automatically detected (or learned) and recorded. It fits into the C (configuration) part of the FCAPS areas. Automatic discovery frees the user from the potentially error-prone and tedious task of manually entering and maintaining the details of the deployed NEs. Large service providers tend to deploy NMS from the point in time that they start to build their networks (smaller service providers may wait for some revenues before adding an NMS). So, the burden of data entry may not be so great for large service providers; that is, they add an NE to the network and simultaneously add all the necessary details to the NMS. Once the deployed NEs are known and stored in a persistent repository, they can be managed. Discovery typically follows three main stages:

• Initial discovery of previously unknown NEs

• Incremental discovery of some change that has occurred to previously discovered data ”for example, new cards (hardware) are added to a switch or additional protocols (software) are configured

• Discovery of removal, where a device is taken out of the network and is then automatically removed from the NMS

Initial discovery occurs when a device is encountered about which nothing is known by the NMS. Its details are read by the discovery application and recorded in the database. Examples of such details are:

• IP address of the SNMP agent on the device

• IP address of the device interfaces

• Device type; for example, for multiservice switches, this might be some combination of SONET/SDH, DWDM, ATM, MPLS, Frame Relay, and so on

• Inventory details, such as configured software and cards deployed in the device

• Protocols and technologies running on the device, such as ATM PNNI, MPLS, X.25, IS-IS, and so on

• Links to other devices

• Virtual connections, traffic profiles, route objects, and so on

NE software configuration is equally as important as the hardware details. An example is the set of ATM and MPLS virtual circuits we saw in Chapter 4, "Solving the Network Management Problem," in Figure 4-9. These circuits facilitated the exchange of a range of traffic types between the two geographically distant sites.

The results of discovery are extremely useful, but even automated, it can be a time-consuming and expensive operation requiring SNMP (not all NEs support SNMP, e.g., many optical devices use the OSI management protocols for historical/technical reasons) messaging, and much database activity. Discovery provides the information needed for the other functional areas of management (such as provisioning, fault handling, performance analysis, and billing), but it should try not to do this at the expense of the overall solution. A balance is needed between supporting all the FCAPS features and the computational discovery effort required in trying to maintain parity between the actual network and the list of discovered entities.

A network-mapping feature further processes the discovered NEs and attempts to understand and depict the logical (and sometimes geographical) interconnections between them. Knowing the interconnections allows for a more comprehensive understanding of the network operation.

NNM Discovery and Mapping

NNM provides an automatic discovery mechanism. This reflects the fact that many deployments of NNM are in enterprise networks with a wide range of layer 2 (switches, bridges, repeaters, etc.) and layer 3 devices. The discovery process uses SNMP-based polling and ICMP requests (over UDP and IPX) to build a picture of the network. For networks connected to the Internet, a seed file must be provided in order to avoid trying to discover NEs outside the organizational boundary.

The discovery process populates an IP topology database using a series of tables such as:

• Network-level connectivity

• Segments

• Nodes

• Interfaces

This grouping allows NNM to create logical maps of the NEs and to graphically indicate operational status using a color , such as green for up, red for down, and so on. An icon representing a network can be expanded to show the constituent nodes. Similarly, nodes can be viewed in terms of their interfaces. In other words, containment relationships are depicted clearly and intuitively.

Updates to the topology database occur continuously as a result of information received from managed nodes. These are nodes that are specially designated by the network operator for regular polling. Both status and configuration changes are recorded for such nodes. On the other hand, the operator must explicitly initiate on-demand, polling of unmanaged nodes. These are nodes deemed to be either relatively unchanging or not as important (from a management perspective) as their managed counterparts. This reduction in the number of managed nodes assists in improving scalability of both the network and the NMS.

Monitoring

Monitoring is the process of recording temporal changes in the status of managed objects such as:

• Nodes

• Interfaces

• Links

• Virtual connections (e.g., ATM PVCs, LSPs)

• Ethernet VLANs

Status changes can be simple transitions such as link/interface up or down, or more complex, such as when an LSP path is being signaled through the network. In the latter case, a complex and dynamic state transition is occurring. Many such status changes can have an important bearing on the service received by the associated end user. An example is when an interface that is part of an ATM PVC goes down. The interface is no longer able to handle traffic. Such a status change may be service- affecting if there is no backup connection. For this reason, monitoring functions are an important part of an NMS, and the faster they record changes, the better.

The same process that carries out discovery also executes NNM monitoring. This is convenient because both discovery and monitoring can use the same set of objects ”lists of NEs, interfaces, links, connections, and so on. Status changes are reflected back into the topology.