Browse Prior Art Database

Retrofitting Tivoli NetView to Function in an On Demand Service Delivery Model Disclosure Number: IPCOM000018615D
Original Publication Date: 2003-Jul-28
Included in the Prior Art Database: 2003-Jul-28
Document File: 4 page(s) / 16K

Publishing Venue



IBM Tivoli NetView for UNIX (TM) is a software product designed to monitor the entire enterprise network of a single customer. Installation, configuration, and maintenance of NetView is typically a very hands-on, highly customized, and time-intensive endeavor. Disclosed is a network monitoring solution that fits within an "On Demand" service delivery model. NetView must be modified so that it can be shared among multiple customers who only pay for the monitoring services that they need. In addition, it must function in a completely automated way as part of a larger workflow and datacenter autoprovisioning system. NetView is not designed to operate with these characteristics. In order to meet these needs, we created a novel combination of off-the-shelf software components, non-standard NetView configurations, and new UNIX shell scripts to bring a new capability to NetView. The combination of these elements effectively changed the character of NetView so that it will function in a more "on demand" manner.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 35% of the total text.

Page 1 of 4

Retrofitting Tivoli NetView to Function in an On Demand Service Delivery Model

  NetView is typically installed by a corporate network administrator seeking to monitor his/her entire enterprise network. A normal installation scenario might work as follows: The administrator will install the NetView software on a server attached to the network. Key devices in the network infrastructure - central routers or switches, perhaps - are listed in a "seed file" as seeds for network discovery. NetView will use the Simple Network Management Protocol (SNMP) to communicate with these seed devices and obtain information about their neighboring devices. As the process continues, a map is constructed of the entire topology of the network, consisting of all the network devices connected by the appropriate links. Often the map generated is too broad or limited in scope, and some devices remain undiscovered. The administrator must manually tweak the discovery so that his/her exact list of devices is being monitored by NetView.

After discovery, NetView will send ICMP echo packets ("pings") to monitor whether the device is online or not. If a device fails to respond to a ping, NetView will generate a Node Down alert and notify the appropriate trouble ticketing system. If further SNMP monitors are needed for a device, such as measurement of statistics against certain "warning" thresholds, the information must be manually set up for each specific network device. The entire process, from discovery to monitoring, is a highly customized, manual, time-consuming effort.

The problem arises when an outsourcing / hosting service provider attempts to use NetView to provide "On Demand" utility computing services to customers.

? Some customers will purchase a NetView monitoring service for their servers hosted by the service provider. Other customers will forgo the service. NetView must monitor only the servers necessary rather than discovering a whole network.

? The addition and removal of NetView's network monitoring services must occur remotely as well as in an automated, "lights-out" way. No dedicated administrator can log on to the NetView server to add or remove monitored devices from the graphical application.

? With utility computing services, some degree of customization is forgone in favor of a standard set of "good enough" services. Concerning NetView, our design specifies that SNMP monitored elements (MIB data collection and threshold monitoring) must be pre-programmed and automatically applied to devices as they are added.

Thus it is apparent that NetView must be configured in a non-standard way to accomplish these objectives. Missing functionality, particularly concerning automation, must also be added using UNIX shell scripts.

The disclosure consists of a combination of three types of elements: (a) existing commercial software products, (b) the unique configuration of this software, and (c) custom developed UNIX shell scripts that integrate the variou...