The management of data networks bas evolved at Digital since 1978, although the management of voice networks bas been a more recent phe·
nomenon. Digital's first data network management products m
�
nagednetworks of DECnet nodes. Our capabilities now include the management of diverse data network components by means of several different prod·
ucts described in this paper. The integration of these data network man·
agement capabilities through a common architecture, user interfaces, management databases, and protocols is a major short-term g�al. The integration of voice and data network management is a much longer
term goal. The voice management product presented here wiU be 'part of that future integration.
The size and complexity of networks have been growing at an accelerating rate. For example, over the last ten years the size of Digital's inter
nal network has grown from a few communicat
ing systems to over 10,000 computer nodes, dis
tributed throughout 250 sites in 37 countries.
We are currently adding about a hundred new systems per week to this private network. This rapid growth has led to a need for more-sophisti
cated network management capabilities to con
trol such networks. This paper describes the changing needs of network management, how Digital's products and capabilities have evolved to meet those needs, and some directions for future evolution.
Traditionally, networks have come in two cate
gories: data and voice. Digital supports many data network architectures, including BISYNCH, SNA; X . 2 5 , Ethernet, and OSI . However, the primary one supported is the Digital Network Architecture, or DNA, which defines our DECnet products.
The Network Evolution
Some basic network management capabilities were added to the DNA architecture early in its evolution (1 978) . These capabilities included the manual on-line observation and control of both local and remote network nodes. Included in the DNA design was a network control pro
gram that was to be implemented consistently
Digital Technical Journal No. 3 September 1986
across all DECnet produCts .1 That program would allow a network ma
h
ager to control theoperation and configuration of the network by manipulating operational parameters. The pro
gram would also allow him to observe how well the network operated by providing current status information, and network traffic and error data.
Basic Management Capabilities for the
I
Whole Network
As other architectures and protocols emerged, new products, such as X.2,5 and SNA gateways, and local area network (LAN) bridges, needed the same capabilities to b
�
managed as did the DECnet products. This requirement brought about the first major evolutionary trend in network management. It became clear that DNA had to be extended to accommodate the management of connections to these non-DECnet products.
i I
Adding Intelligence tO Management
Functions ·
The second evolutionary trend was driven by the increased size and complexity of DECnet net
works and the difficulty in finding qualified peo
ple to manage them and the: systems within them.
This trend led to the need for more-intelligent network management functions to support a cen
tralized staff dedicated to managing the network.
To partially meet this need, we developed a pro
duct that automates the
rp
onitoring of traffic I I1 1 7
The Evolution of Network Management Products
and other events in the network. This product also contains many event evaluation functions, which produce statistics made available through both interactive and hard-copy reports.
Other products have also added intelligence to the basic network control capabilities of the early DNA architecture. These products perform
IAN testing and diagnosis, and X.25 accounting and enhanced protocol-tracing.
Voice Network Integration
An evolutionary trend similar to that in data net
works was also happening in voice networks.
Voice network users were becoming more sophisticated, requesting capabilities similar to those seen in data networks. For example, like their data network counterparts, voice network managers need the ability to control, optimize, configure, and monitor the network. In addition to collecting management data, users also requested its processing to provide management information.
At the present time, telecommunications net
work management has evolved beyond the scope of the DNA design. Because of this rapid advance, product strategies have been adopted for tele
communications management that identify a number of directions data network management products could pursue in the future. Specifi
cally, we are expanding our management archi
tecture to allow for the inclusion of additional network components. We also see the need to integrate management user interfaces and infor
mation with other network applications. This integration will support all the business-data and resource-management needs of users.
The remainder of this paper covers the evolu
tion of network management in more detail as it relates to the development of specific manage
ment products. The following section discusses data network management as a distributed application that provides operational control and observation of a variety of data network products.
Management as a Distributed Application
Network management within Digital Equipment Corporation began as the management of net
works of DECnet nodes. These networks con
sisted of peer computer nodes with peer manage
ment capabilities; that is, each node had remote access to the management capabilities of every 1 18
other node, subject only to access control. Each node also provided access to its own manage
ment functions and data for its own local users.
A common user-interface program, called the network control program (NCP) , is imple
mented across all DECnet products. This pro
gram is not simply a remote console interface to network products. In addition, it allows remote access to network management functions via a published, proprietary protocol.
The character of Digital 's networks has changed significantly over the last ten years.
They now have components that are neither DECnet nodes nor peers, such as IAN bridges, gateways, and other servers of various kinds. The approach we used to integrate the management of these products was based on the DNA manage
ment strategy. That is, the level of function and the general presentation to the user were similar to those originally in DNA network management.
A number of initial strategies were tried to extend the architecture in various ways to include the management of these products.
For X.25 connections, our initial strategy was to extend the arch itecture by adding X . 2 5 -specific capabilities. Unfortunately, this strategy tightly coupled the management of the X . 2 5 product to that of the DECnet product by adding X. 25 management to NCP. That coupling made upgrading the management implementation for either product more difficult since it created interdependencies between product develop
ment schedules. We have found these interde
pendencies to be difficult to manage with only these two products. This strategy would be com
pletely unworkable if we pursued it for the man
agement of all the different network products.
Nothing would come to market if we had to coor
dinate the development and release schedules for dozens of interrelated items.
For SNA gateways, our temporary strategy was to derive a parallel management architecture for SNA, based on the DNA management capabilities.
While decoupling the two architectures and implementations, this strategy only postponed the integration of network management for SNA gateways. It also resulted in multiple manage
ment protocols and user interfaces, although the parallels between these were obvious. We could readily see that this approach would not work well in the long term as the number of products to be managed increased. We also knew that inte
gration of network management for all our
net-Digital TecbnicalJournal No. 3 September 1986
work products was very desirable to customers and would allow us to eliminate duplication on development projects.
For IAN bridges, our strategy was to use a non
proprietary protocol based on the evolving IEEE 80 2 . 1 management protocol. This strategy was the first step in an evolution toward the adoption of emerging international standards for network management. 2 Since the development of manage
ment protocol standards had q.ot been com
pleted, using such protocols amounted to working with prototypes. However, the need to evolve the strategy in this direction was clear.
NCP and other similar products developed for SNA gateway and IAN bridge management pro
vide the network manager with various simple functions. Among these are configuration con
trol , low-level testing, and snapshot views of state information and various traffic and error counters.
While integrating these products, both the architecture and the subsequent implementation strategy must be enhanced to allow the indepen
dent development of management capabilities for these diverse components. We are currently working on such enhancements, as discussed in the section "Future Developments."
Other factors were also highlighted while we developed management capabilities for bridges, gateways, and servers. These more recent addi
tions to our network product set do not always provide local access to their own management capabilities or allow the initiation of manage
ment access to other network components. Many have no locitlly connected device to support a local management user interface. To allow net
work management for these components, some type of remote management access from another station that does provide a management user interface is essential.
Remote access is also the key for managing DECnet nodes. Without this access, no manager could see more than his own local node informa
tion, which is not sufficient to diagnose and solve overall network problems. Without remote access, service personnel would have to be sent to each node location that was experiencing the problem in order to collect management infor
mation. This problem results in networks that are much more expensive to service.
Remote access to the management application can be provided in a number of ways. Access can
Digital TecbnlcaiJournnl No. 3 September 1986
be centralized, in which one management station provides access to the entire network; dis
tributed to a few management stations; or fully distributed to all nodes, as ·access is in DECnet NCP. In any case remote accrss from one node to the management functions ahd data from another node necessitates designin
�
and implementing the management application itself as a dis-1 tributed function. The architecture for this dis-tributed management must specify a set of distributed software and ,database elements that will be needed to manage diverse network components.Distributed Manage
rrt,
ent Architecture and Application Elem�mtsThe basic elements that must be included in a distributed management architecture and in the applications developed within it are
• A user interface
• A management agent in e�ch component to be managed, providing remote access to its
man-• I
agement funcuons and data I
I
• A communications mechanism between the node running the user irtterface and the agent software modules in the network components being managed
Figure 1 illustrates the relationships between these elements.
The User Interface
The user interface and software to invoke man
agement functions genedlly reside on one or more management stations
i
(more if distributed, as with NCP; or one if centralized) . The user interface is the key to developing an integrated management application from a network manager's perspective. In developing new network products, we have extended the command lan
guage syntax developed for DECnet management to X.25 connections and SNA gateway products, as well as to bridge and se�er products currently under development. Thus 1a common command I
style, resembling English s�ntences as closely as possible, has been used to manage our expand
ing set of network products.
1 19
New Products
The Evolution of Network Management Products
MANAGEMENT STATION
COMMAND I-- USER MANAGEMENT INTERFACE FUNCTIONS
I I
l
r'--
_../MANAGEMENT DATABASE
COMMUNICATION OF MANAGEMENT FUNCTIONS, DATA OVER NETWORK
PROTOCOL
/
AGENTAGENT
AGENT
NETWORK COMPONENTS
MANAGEMENT DATABASE
MANAGEMENT DATABASE
. . .
MANAGEMENT DATABASE
NODE
GATEWAY
BRIDGE
Figure 1 Distributed Management Application Elements
A unified user interface giving management access to all these network products from a sin
gle program would have been extremely desir
able. Such an interface, however, could not be provided for the first release of all of them. A uni
fied interface would have to allow for the identi
fication of all products (DECnet, X . 2 5 , SNA, bridges, etc.) to which the desired management function would apply. The architecture had not yet addressed this problem of selecting among multiple products to be managed, although it had been extended for X.25 connections. Thus the X.25 connections can be managed via the standard NCP interface. However, the SNA gate
way has its own SNA control program bundled into the SNA products; and LAN bridges have their own management software, the remote bridge management software (RBMS) , sold as a separate product. The network architecture is currently being extended to incorporate this task of selecting among multiple products.
Management Agents
NetWork components must contain management agents before the components can be managed
1 20
remotely. These agents perform the management actions issued by users by way of the user inter
face. The agents also maintain the operational management data needed to support the manage-- ·ment application and provide remote access to
this data maintained by the component itself.
An agent must be addressable across the net
work and must respond to a set of function requests that provide adequate management capabilities for each particular type of compo
nent. Some components (e.g. , hardware commu
nications controllers connecting computers to network media) may have extremely simple agents. Complex programmable network compo
nents, like bridges and servers, have agents that may respond to many more functions.3 Thus these components may have a lot of the dis
tributed management application residing in the software or firmware of the agent.
Consistency of implementation of manage
ment function across agents of diverse types is extremely important. 4 If the implementation of functions in the agents of different network products is inconsistent, · then these products will not provide a uniform set of functions to the
Digital Tecbntcal]ournal No. 3 September 1986
users. Furthermore, the same management func
tion might result in different actions for different network products. Inconsistency of this type results in user confusion and dissatisfaction.
Management Protocols
A management protocol is the vehicle for com
municating management functions and data between the user interface and the management agent. The NICE protocol was developed for this purpose within standard DECnet components.
NICE was later extended to include X.25 gate
way management and was also used as the base for adding extensions to manage DECnetjSNA gateways. As mentioned earlier, for non-DECnet servers and bridges, we are tracking the evolu
tion of a nonproprietary standard management protocol.
The communication mechanism between the user interface and the management agent must also provide reliable transmission and end-to-end integrity of management function requests and management data. These requirements have been satisfied by the data link and end communication (OSI transport) layers of the Digital Network Architecture for DECnet links. These layers have also been used in the management of the gate
ways between DECnet and X.25 or SNA networks since the layers are available on all components implementing the DECnet standards.
For LAN bridges and some other non-DECnet server implementations, other transport mecha
nisms have been used with the management pro
tocol. In the case of bridges, no transport mecha"
nism is implemented at the bridge; simple datagram-based management is used. For bridge management, the node running RBMS must assume total responsibility for the reliable trans
mission and integrity of management messages on the LAN. The component being managed assumes no mutual responsibility for these mes
sages. Based on product constraints, the respon
sibility for the reliable communication of man
agement information can thus be distributed in a variety of ways. Therefore, we must extend the network management architecture to specify a standard solution to this problem for non
DECnet products.
Management Database
The database needed to support the management application can be distributed in a number of ways. Some data must be maintained by the
man-Digital Technicaljournal No. 3 September 1986
aged components themselve
�
, including component identification, state infbrmation, traffic and error counts, and other operational parameters. A permanent copy of the operational parameters must be maintained in nonvolatile storage to recover from human, computer, and network failures. This copy could exist either in non
volatile RAM in the compom�nt, on local external storage, or on a file at the l:emote management station. If the copy exists at 'the management sta
tion, then the component must depend on that station for correct operation unless the data is also stored locally.
Other data files that might be contained in a management database inclu
r
e the following:• Loadable software image 'files for both opera
tional and diagnostic im�ges associated with particular network components
• Event log files in which notifications of signif
icant events for network :components are col·
lected '
I
• Reference data files that,
]
though not essential for component operation, give information relevant to the physical identification, location, and servicing of network components
• Management directory
The management directqry contains informa
tion needed to identify and locate data relevant to a particular component and to gain access to netwOrk addresses for the components them
selves. Those addresses are needed for the pur
pose of remote management access.
To provide reliable access to essential direc
tory information, the directory data must either be part of a network-wide :directory (or naming service) or be kept at the
d.
anagement station of the component. The other 1files, however, could reside at the management station or on external storage at the component, if such storage exists.(It does not exist for many components · like bridges, gateways, and some servers.) The direc
tory can be used to access idata no matter where it resides. The directory !allows management data distribution trade-off
�
i to be made to meet ' the needs of the network • products themselves as well as those of the management station software.Management Functions
Simple management functions are network conI trol functions involving interactions with
net-t 1
1 2 1
New Products
The Evolution of Network Management Products
work components in which few or no analyses are made of the data or test results obtained.
These interactions include
• Collecting or modifying management data maintained by components
• Requesting management actions to occur at components (enable, disable, test, etc.)
• Loading operational code or parameters into components
• Collecting notifications of significant events from components
Access security to these operations is provided through a database of authorized network man
agers and their access rights. In this way different levels of access rights can be granted to different users for certain functions (e.g., privileges might be granted to collect management data but not modify it from a remote node) .
We are currently extending the four simple network-control functions across our network product set. More-intelligent management func
tions are being devised to automate the collec
tion of management information and to provide analyses of data and test results. Such analyses would yield information about network perfor
tion of management information and to provide analyses of data and test results. Such analyses would yield information about network perfor