Ian C. Blenke
2002-07-10 19:27:22 UTC
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.
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.