An Openview-Based ATM
Network Management System Is Born
DEVELOPERS VIEW FEATURE FOR NOVEMBER OPENVIEW ADVISOR
By Nigel Cook, Robert Coote, David Horton, and Geoff Thompson, CiTR
Pty. Ltd.; and
Dr. Hiroshi Suzuki, NEC Network Research Laboratories and C&C
ATM (Asynchronous Transfer Mode) networks are emerging as a major
broadband networking technology. Because of the complex mixture of
different kinds of ATM switch equipment--to say nothing of the need to
establish, control, and monitor end-to-end connections (virtual
circuits)--managing these networks has created new challenges for
private network operators and public telecommunications service
providers alike. Considerable effort is being applied to the
formulation of standards in this area, especially by the ATM Forum.
CiTR Pty. Ltd. (Queensland, Australia) has been
working with NEC (Kawasaki, Japan) to implement a prototype ATM Network
Management System (NMS) using Openview and SNMP Version 1 to control
and monitor ATM Networks via the IETF (Internet Engineering Task Force)
ATM management information base (AToM MIB). This international
collaboration has developed successive phased releases of the NMS
software. At first, work focused on two areas: connection-oriented
Openview map navigation and a graphically driven
connection-establishment interface. The latest release includes ATM
autodiscovery, automatic optimal route selection when establishing
Permanent Virtual Circuits (PVCs), and their subsequent monitoring and
ATM, of course, is a high-speed networking
technology. Its speed, low latency, and ability to handle all kinds of
traffic over a single network make it ideal for a range of
bandwidth-intensive applications, including multimedia, medical
imaging, bank-check imaging, seismology studies, supercomputer
applications, and CAD/CAM.
One factor influencing the pace at which ATM has been adopted is the
development of standards, many of which are being formulated by the ATM
Forum. One such standard is the concept of a virtual circuit.
Negotiating such a circuit with nominated bandwidth and
quality-of-service parameters is one feature of ATM circuit
provisioning. Standards defined by the ATM Forum and the IETF allow
users to change network design and re-route traffic by manipulating
virtual circuits. But in many implementations to date, the process has
been a manual one.
Understanding what this project has achieved requires,
first of all, a basic overview of the ATM Forum's network management
model (see Figure 1). The model defines five work areas for network management:
In this work, the partners have incorporated the ATM Forum
architecture, as well as some other emerging standards, including the
AToM MIB, an SNMP Version 2 MIB (Management Information Base) developed
by the IETF for ATM management. After a year of development--and eight
was released in August 1994 as RFC
(Request for Comment) 1695. AToMMIB
supports semantics for
monitoring and setting up virtual circuits. The work undertaken by the
project's co-authors at NEC has included ATM Forum submissions to
obtain the definitions required for ATM autodiscovery support.
Openview was chosen as the development platform; independent published
studies of market share and applications available for various network
management development platforms confirmed that the marketplace accepts
Openview as an "open platform."
- ATM end devices (M1)
- private ATM networks or switches (M2)
- links between public and private networks (M3)
- public networks (M4)
- links between two public networks (M5)
The Openview network management system supports M1- and M2-style
management interfaces as described by the ATM Forum. The SNMP agent,
which was also developed in this project, uses information from the UNI
(user-network interface) ILMI (Interim Local Management Interface)
for reporting to
management functions through the IETF AToM MIB.
Early adoption and use of recommendations and
drafts from such bodies as the ATM Forum and the IETF is an important
aspect of the development project and provides valuable experience for
later product implementations. The NEC/CiTR joint development program,
which began in mid-1993, concentrates on implementing proof-of-concept
network management prototypes based on open standards. The
proof-of-concept software CiTR developed has been made available to NEC
as an input to commercial product development activities--specifically,
the upcoming NEC Atomview product--but that is quite another subject.
The development program has been structured in a series of phases, with
a number of improvements in functionality during each of them, as outlined below.
At this stage, the project concentrated on building a
basic ATM network management system that provided for monitoring and
manually initiated control of a set of ATM hosts and switches using
SNMPv1. Features included the following:
At this point, the system, based on AToM MIB and the proprietary end
point IP to VCI (Virtual Circuit Identifier)
MIB, directly permitted IP address
translation. CiTR's in-house tools provided for the automated
conversion from SNMP MIB specifications to software agents. This made
it easy to track evolving IETF specifications.
The system's architecture (see Figure 2) consists of some
Openview-based applications and supporting report-generation tools that
combine Openview object database (ovwdb) applications and some
SNMP applications, as well as atm_lan.
The atm_lan application, integrated into OVW (Openview Windows),
manipulates the OVW map, symbols, and ovwdb.
The next step was to create a sample interface screen, in which the ATM
switches and hosts were represented by icons and physical connections
between nodes were shown as solid lines with logical connections
(virtual paths and circuits).
- PVC connection management
- multiple views of connections, both logical and physical
- drill-down connections and nodes
- context-sensitive object detail reports
- fault management
- SNMPv1 and v2 bilingual agents for both host and switch
The next phase of development concentrated on adding
automation functions to the basic ATM NMS established during Phase 1.
The following functions were added:
The Phase 2 development also involved a series of enhancements to the
Phase 1 software. Another integrated OVW application, known as
atm_mon, was added (see Figure 3). This application contains
functions that detect nodes and ports making the transition to the
"down" state, achieved both by actively polling status and by passively
catching and processing "traps" that report the change of state. The
division between two applications, atm_lan and atm_mon,
exists to ensure maximum responsiveness in atm_lan; atm_mon
can suffer from delays because of SNMP timeouts in the processing loop.
The atm_lan application was further enhanced during Phase 2.
Association between major functional blocks was achieved through a
combination of internal APIs (.MDNM/application program interfaces) and
the use of OVW callback registration, OVW actions, and Xt Intrinsics timers
(see Figure 4).
- fault and topology monitoring
- SNMP-based ATM auto-discovery (automatic physical connectivity) using
AToM MIB (RFC 1695 Final)
- Virtual Circuit Tracing
- automatic path selection, using a shortest-path (fewest hops) algorithm as sample heuristic
- unattended automatic PVC rerouting
At this point, the Openview IP submap window was adjusted to show the
icons representing the ATM submap. Clicking on the ATM submap icon
(nwkatm-cl-nec) explodes it into the top-level ATM submap, which
is populated by the ATM autodiscovery process.
ATM autodiscovery functionality is a key
feature in a network management system for private LAN-centered ATM
networking environments. It is important not only for initially
determining the physical connectivity of the network but also for
ongoing efforts to monitor the topology.
Other elements of functionality, such as unattended PVC rerouting, rely
on the automatic invocation of autodiscovery to maintain a view of the
network topology on detecting a port status change. When it becomes
aware of a port operational status change, the Openview object status
change callback triggers processing. Subsequent processing by
atm_mon, using information obtained from neighboring information
fields defined in RFC 1695, determines when a topology change occurs,
and an Openview action then triggers the invocation of autodiscovery to
resolve the updated network configuration. The autodiscovery algorithm
minimizes the host traffic, since it is linear to the number of nodes
in the system (see table and Figure 5). Only a small percentage of the
time required for autodiscovery is associated with network accesses.
Most processing is related to Openview database manipulation.
Openview is an effective development
environment. But it suffers in a number of areas that affected the
development effort and the clarity of presentation to the end-user.
- There is a lack of transaction functionality to group multiple
object add and delete operations. In the application developed by the
project, there are long sequences of operations involving the Openview
databases, MIBs on a number of different nodes, and an external database.
During an involved creation process, the Openview model requires
developers to keep separate records of components created, so that if a
rollback is necessary, the components created before the rollback can
be deleted. Rolling back a delete is also a complicated process. These
limitations force the application to check before sending requests, so
as to ensure that operations are likely to succeed.
- The Openview palette of icons and connections allows no program
control or hiding. This causes the internal symbols in the system to be
inappropriately exposed to the user as a possible choice.
- Connections are poorly supported as regards locating
connections for an object, and there is a limitation of only one connection palette.
- ovwdb is separate from mapdb. The management system
includes a status-monitoring daemon that updated the status on objects
associated with the MIB only--in other words, that did not relate to
symbols on a submap. But as a result of Openview's limitations, a
separate Openview session was necessary to provide a submap to set
status on objects. Another part of the management system included a
background recovery application that rerouted PVCs and detected network
topology changes. To make these changes to the map, a read/write
connection to a map was required, and it would interact unfavorably
with operator usage of the map. Although it may be possible to batch up
symbol and submap changes until a writable map becomes available, this
would introduce considerably more application complexity.
- Program versus user control are poorly distinguished. Openview
cannot distinguish programatically between user- and software-initiated actions.
- Operations that update the Openview database are very slow.
Even with the relatively small test network, the majority of elapsed
time for such operations--for example, automatic rerouting--must be
spent updating the Openview representations and database rather than
manipulating the actual network.
As time goes on, the project aims to improve
the host MIB definitions and to create a display based on world
geographical coordinates. To sum up, although the Openview platform was
an adequate development
tool for the Broadband Network Management applications, it has
considerable limitations. Nevertheless, our use of automated
agent-generation tools provided for easy tracking of standards. The
project demonstrates the possibility of an Openview-based Broadband
Network Management system, based upon the open standards defined by the
IETF and ATM Forum, and capable of controlling networks containing
multiple vendor switches.
Nigel Cook is an account manager, Robert Coote, David Horton and Geoff Thompson
are consultants with CiTR. CiTR is an Australian software engineering
company specialising in network and services management.
They can be reached on the internet at
Dr Hiroshi Suzuki is a senior researcher at the NEC Network Research
laboratories developing NEC's range of ATM switches. He can be reached
on the internet at
Table: ATM Autodiscovery Timings
This table presents a sample of the timings and performance of the
autodiscovery algorithm, based on a Sun Sparc 10.
Number of Nodes Number of Connections Time to Auto-discover
4 3 27.33s
4 6 29.00s
8 7 55.6s
8 28 75.25s