atom feed17 messages in net.sourceforge.lists.opennms-discuss[opennms-discuss] OpenNMS Network Map...
FromSent OnAttachments
Ian C. BlenkeJul 10, 2002 12:27 pm 
Tarus BalogJul 10, 2002 1:12 pm 
Ian C. BlenkeJul 10, 2002 2:28 pm 
Bill FellingJul 10, 2002 2:41 pm 
John BlakeJul 10, 2002 6:04 pm 
Den BeiJul 10, 2002 7:29 pm 
wrol...@donovandata.comJul 11, 2002 11:05 am 
Ian C. BlenkeJul 11, 2002 12:53 pm 
Ian C. BlenkeJul 11, 2002 1:38 pm 
Ian C. BlenkeJul 11, 2002 3:33 pm 
Den BeiJul 11, 2002 5:44 pm 
John BlakeJul 12, 2002 3:57 pm 
Ian C. BlenkeJul 12, 2002 6:12 pm 
DavidJul 22, 2002 5:14 am 
DavidJul 22, 2002 6:23 am 
Ian C. BlenkeJul 22, 2002 12:10 pm 
Den BeiJul 25, 2002 9:45 pm 
Subject:[opennms-discuss] OpenNMS Network Map "Design Requirements Document"
From:Ian C. Blenke (icbl@nks.net)
Date:Jul 10, 2002 12:27:00 pm
List:net.sourceforge.lists.opennms-discuss

Someone suggested that someone write a design document for network mapping with OpenNMS. So I did my best and whipped together the following. I welcome all feedback eagerly.

-------------------------------------------------------------------

OpenNMS SVG Network Map "Design Requirements Document"

Introduction

This document is an attempt to address the need for a visual network topology mapping interface to the OpenNMS community project. This is not a definitive nor exhaustive guide of every possible approach to generate such a map, but merely an attempt to design a reasonable and appropriate solution to the problem at hand. The architecture below is based entirely on a Java centric development model.

Background

OpenNMS was developed to be an OpenSource alternative to commercial Network Monitoring Systems like HP Openview Network Node Manager (HPOV NNM). As such, OpenNMS excels at automated network discovery, ease of configuration, and flexible monitoring and alerting. Fortunately, now that these features are rock solid, the difficult part is complete. However, the most visible piece is still missing. OpenNMS needs a visual network topology map.

Some alternative platforms, such as NetSaint, have their own mapping subsystem based off of Thomas Boutell's wonderful graphics development (gd) library. Nodes are represented as rasterized bitmapped icons as layers on a common visual background image.

A mapping system consists fundamentally of vector diagrams of nodes and paths. Rasterizing this display should be secondary to the native vector representation of the data.

While it is possible to render Abstract Windowing Toolkit (AWT) graphics directly to a raster image, the native vector drawing primatives are lost in the process. For vector presentation, Scalable Vector Graphics (SVG) is quickly gaining acceptance for vector graphic web display. As a network topology map is nothing more than a vector graphic, SVG is a prefect fit for the OpenNMS need.

As an XML derived format, SVG is ideal for generation via JSP views and other typical HTML generation means. SVG also supports Cascading Style Sheets (CSS) for customization of views. Style sheets may be updated with color schemes or other static themes to customize the rendered content.

SVG may be rendered into a rasterized image on demand using one of many available toolkits, including the Apache Batik project and Sun's Graphics2D generator. This makes backward compatibility with non-SVG aware web browsers relatively painless.

Architecture

Ideally, presentation would be completely removed from rendering, where the JSP output would be a meta-XML object dump of the active database. Some form of XSLT rendering to the resultant map view would be ideal. Unlike static CSS templates, dynamic plugin XSLT could then be used to generate different types to maps automagically, based entirely on the managed node metadata.

However, assuming that SVG output is adequate for most network maps, this layer of complexity is potentially unwelcome.

Per section 4.3.2 of the OpenNMS Developer Guide, the architecture of OpenNMS is to seperate logic from presentation as much as possible. The current approach is to use JSP for read-only views of information, and submit any changes to Servlets that make the appropriate backend updates.

Architecturally, this means that we should design JSP page views of the active node map data. If themeing or customization is required, merely changing these JSP views would alter the SVG rendering.

This also suggests that any interactive map editing should take place on the client SVG viewer, with any updates to the persistant map data posted to Servlets to update either RDBMS tables or EJB entity beans as appropriate.

2d Map Drill-down

The contemporary model of network topology mapping is to arrange the 2d map into a drill-down model.

One such map might be a geographical one. Given a map of the US continent, nodes would be placed to represent unique cities such as New York, Los Angeles, or Atlanta. Drilling down into a city might uncover a map of sites or locations where equipment may be located. Drilling down into these locations, nodes might be depicted as shelves in racks of equipment. Drilling into equipment might present the IP addresses, services or other useful asset information about that equipment. Most facilities folks would kill for something like this that can be kept up to date.

Another map might be a topological one. Given a high-level WAN-cloud map of the enterprise network, nodes might represent locations in various buildings or cities. Drilling into the cloud might display PVC assignments to physical Frame Relay or ATM switches. Alternatively, drilling into a location might show a typical network topology with a firewall and various servers on network segments. There might be representations of a private network drilldown that would show individual nodes located behind a NAT device. Such maps would depend on the environment and the need.

3d Map Traversal

A few NMS products do offer 3d fly-through of a network environment. NetSaint offers a VRML view of nodes given pre-assigned x/y/z cordinates. These environments tend to be static representations of nodes with some attribute such as color to denote their current state.

Unfortunately, the usefulness of these interfaces have yet to be proven. The primary barriers to a 3d interface continue to be the lack of a universal 3d input device for navigation, and the lack of a compelling interactive interface with useful physics and intuitive animation for presenting information without occluding critical alarms.

While there is currently at least one 3d SVG sample included with the Apache Batik project, the more appropriate modeling language would be VRML. As VRML is an XML derivative much like SVG, this holds some promise for the future as well.

With the blistering pace of development of current first person shooters in the gaming world, there continues to be hope that we might soon see an environment where 3d network topology mapping makes sense.

Node Representation

A node is a representation of a network object. That node might be a managed device, an interface on a device, a service, or a link to another map. When a drilldown to a node occurs, a view of that node should appear.

In the case of a managed device, the view should include interface nodes for interfaces on that IP stack and service nodes for services offered.

An interface node should present configuration information and status of that interface, preferrably with a link to the node to which it belongs.

A service node should present configuration information and status of that service, preferrably with a link to the node to which it belongs.

A map node should link to another map, preferrably with some form of link back to the parent map or some form of bread-crumbs permitting traversal to some previous map in the heirarchy.

Static Mapping

Any network topology map should permit some form of manual map creation. The ideal model would be to permit creation of new maps based on administrative need. Admins would ideally wish to add network elements and place them manually on the maps themselves. Such maps are pre-drawn, and do not change without manual intervention.

It would be nice to enable more advanced graphics primatives beyond basic equipment elements as well. There should be a set of vector representations of a node that may be selected for any node on a map, which should be selectable for just this or all maps. Simple objects and graphics primatives familiar to Visio users would permit full network diagrams to be created while being fully integrated within the dynamic mapping of OpenNMS.

At a minimum, hand-drawn maps should permit a background vector or raster image to be set and lines to be drawn between nodes.

Anyone who has been forced to maintain a set of moderately complex network maps will attest to to the odd behaviour of some mapping systems. Nodes should be able to appear on multiple hand-drawn maps. Nodes should not automatically add themselves to hand-drawn maps, but they should be made available for addition to them. Nodes should be able to be deleted from one map while not affecting the other maps. Nodes should also be able to be removed from all maps when removed entirely from the NMS.

Some method of cutting/pasting nodes or groups of nodes between maps should be made available, preferrably with relative placement information and attributes remaining intact.

Automatic Mapping

The goal of an automatic map is to present nodes based on a search criterion in some automatically drawn view that allows nodes to be found. Newly discovered nodes should auto-populate in these network maps so that they may be added to manually drawn maps that might better serve network administrators.

The most obvious method would be to place hosts on the same network segment on the same map. For example, hosts on a 192.168.0.0/24 segment should appear on one map, while hosts on a 192.168.1.0/24 segment should appear on another. Not having netmask information, however, would dictate the need to group nodes via some other attribute for painless searching.

In fact, the best method is probably to offer dynamic views that are nothing more than pre-defined search patterns. This would permit no-maintenance yet user-defined maps that update themselves as new nodes are discovered and/or removed from OpenNMS.

Auto-generated dynamically drawn maps require some internal logic and vector computation to prevent nodes and other visual objects from occluding the view of neighboring ones. Various arrangements of nodes should be given. Without a heirarchical parent-child relationship, it is impossible to deduce a tree toplogy automatically. However, it is possible to have a flat list of nodes in row/column format (ie. saintmap.pl, Cheops, et al.) or a ring of nodes that auto-sizes itself with additional nodes (ie. Etherman or Nagios).

Any nodes that already appear in a manually drawn map should be marked with an artifact to allow the admin to know the node is already managed. This allows an admin to quickly identify nodes that need to be added to a map vs those that should already exist.

Conclusion

This is a first draft attempt at enumerating design decision proposals for a logical network topology mapping interface for OpenNMS.

As a Request For Comments of sorts, all input is welcome and appreciated.