WO1995008794A1

WO1995008794A1 - A management agent system for the support of multiple network managers, and a method for operating such a system

Info

Publication number: WO1995008794A1
Application number: PCT/US1994/008934
Authority: WO
Inventors: Yuval Gilbert; Edgar St. Pierre; Brian Hodgson; Benita Barbell
Original assignee: Codex, Inc., A Subsidiary Company Of Motorola Inc.
Priority date: 1993-09-20
Filing date: 1994-08-08
Publication date: 1995-03-30
Also published as: EP0670060A1; CA2148603A1; AU7558094A; EP0670060A4

Abstract

A communication system allows for the separation between the logical, external view of a network manager (10, 12) and the physical, internal view of the communication device (18, 20). A single management agent (108, 110) represents a single network manager (100, 102). The management agent (108, 110) is responsible for interpreting requests from that network manager (100, 102).

Description

A MANAGEMENT AGENT SYSTEM FOR THE SUPPORT OF MULTIPLE NETWORK MANAGERS, AND A METHOD FOR OPERATING SUCH A

SYSTEM

Field of the Invention

This invention relates generally to communications networks, and specifically to the management of a communication network.

Background of the Invention

A communication network consists of a number of users communicating through various inter-connected communication devices. The communication devices could be terminals, host computers, multiplexers, frame handlers, etc.

Such a network may serve a large number of users. The management of such a network may be difficult and complex. For example, if one user desires to transfer information to another user in the network, the network must determine the most efficient path from one user to the other, determine the types of devices used to interface the user to the network, and configure the path so that the information will flow efficiently between the users.

A communication device may have a number of "views". A view is a logical grouping of one or (typically) more data items together to form a logical abstraction that represents a higher level concept for that group of parameters. For example, one view of a "port" may be that it is made up of 14 particular parameters (timers, lead values, etc). A different view of that same port may be that it is made up of 10 of those parameters plus 2 different parameters. The view may change depending on the information needed to configure or monitor the port. When the ability to manage multiple views is not available, then all network managers on a network must share the same view. If the multiple network managers can not share the same view, then multiple versions of each configuration manager on the communications device must be produced (one for each network manager), or each management agent in the communications device must maintain a complete understanding of the system view of the communication cevice. Either alternative adds to the amount of memory used by the device which adds to the cost and/or reduces the available throughput of the device. Both alternatives also add significantly to the maintenance cost of the software.

A system that solves the problem of supporting multiple, diverse network managers by providing a means to translate multiple management views into the normalized, internal view of the communication device would thus be valuable.

Brief Description of the Drawings

FIG. 1 is a customer network.

FIG. 2 is a management agent system for the network/communication device.

FIG. 3 is a block diagram of the multiple views supported within the communication device.

FIG. 4 is a flow chart showing the handling of a management request by the management agent system. Description of the Preferred Embodiment

A system is shown that allows for the separation between the logical, external view of a network manager and the physical, internal view of the communication device. A single management agent represents a single network manager and is responsible for interpreting requests from that network manager.

A Third Normal Form (3NF) data model of the communication device, embodied in base tables within a relational database, allow the communication device management agent - on behalf of the network manager - and communication device's configuration managers to map each other's specific data to this normalized view of the communication device.

This management agent system is thus easily adaptable to a communication device's changing requirements and complex data modeling environment, reducing the cost of building and maintaining the system.

FIG. 1 shows a network consisting of multiple communication devices 14, 16, 18, 20 interconnected by public or private leased lines through the Public Switched Telephone Network (PSTN) 22. Communication devices 14, 16, 18, 20 may be terminals, host computers, multiplexers, frame handlers, etc. Communication devices 14, 16, 18, 20 transport customer voice and data traffic through the network. Attached to the communication devices at the edges of the customer network is a proprietary network manager 10. Proprietary network manager 10 configures and monitors the communication devices 14, 16, 18, 20. The Simple Network Management Protocol (SNMP) Manager 12 is coupled with the network through communication device 16. The SNMP Manager is also used to configure and monitor communication devices 14, 16, 18, 20.

FIG. 2 shows the elements of the management agent system. Proprietary network manager 100 is connected to communication device 104. SNMP Manager 102 is also connected to communication device 104.

Internal to the communication device 104, a proprietary management agent 108 provides agent functionality within communication device 104 for proprietary network manager 100 by using the protocol and semantics that are native to network manager 100. Likewise, proprietary management agent 110 provides agent functionality within communication device 104 for SNMP manager 102 by using the protocol and semantics that are native to SNMP manager 102.

The protocol and semantics native to each network manager are defined as a set of managed objects. A "managed object" is a "view", as defined earlier, specifically defined by each network manager. A managed object view may be made up of data attributes, operations and behavior (which describes what the abstract "view" such as a port will do under different conditions).

For example, proprietary network manager 100 may send an operation to communications device 104 to set the output lead of a particular port to a specific voltage level. The lead itself would be defined as a data attribute of the port managed object. The behavior would be that when that attribute is set to a particular value, then the output lead is changed to a particular voltage level. The operation, the attribute and the behavior are all part of that managed object "view". A different "view" of that same port from the SNMP manager may require a different attribute and operation to achieve the same result.

Management agents 108 and 110 also maintain limited modeling knowledge of communication device 104, including knowledge of the database schema and how managed objects are configured together. The database schema is the set of logical relationships and organization applied to the data in the database. The database maintains a normalized (third normal form - 3NF) representation of the configuration data for communications device 104. This is a "view" of the data which is commonly understood by all agents and configuration managers that reference the database.

Management agents 108,110 translate the network manager managed object "view" into the communication device normalized "view" in the database.

A request by network manager 100, 102 can be broken down into the following categories:

• Create Configuration—identifies a new instance of a managed object "view". Since there are many ports on communication device 104, each individual port is identified by an individual instance. Creating a new instance makes it available for configuration and monitoring.

^• Delete Configuration-removes an instance of a managed object "view" for the list of instances available for configuration and monitoring.

^• Read Configuration-query particular data attributes from a particular instance of a managed object "view" • Modify Configuration-alters the value of a particular data attribute in a particular instance of a managed object "view"

• Perform an Action (such as activate a call)~executes particular operations on an instance of a managed object "view" that can not otherwise be performed by modifying the configuration.

Each management agent 108, 110 is also able to send messages to its respective network manager 100, 102 whenever significant events occur on communications device 104.

Management agents 108, 110 interpret the request from its respective network manager 100, 102, by translating it into a database read or write request. Configuration is validated at the management agent 108, 110, resources are validated and reserved, and then all the data written to the database. Management agent 108, 110 then notifies the appropriate communication device configuration managers 114, 116. Communication managers 114, 116 implement the request. Management agent 108,110 then formulates an appropriate response message back to the respective network manager 100,102.

Validation of a request by management agents 108, 110 are performed within the context of the managed object. Each management agent 108, 110 performs validation of network manager requests to the extent that the request can be accepted into the database. This includes checking per parameter validation, such as checking data attribute boundries (within minimum/maximum values allowed for the attribute); intra-managed object relationships, such as whether one attribute will work with another attribute set to a particular value; and inter-managed object validation, which may be the same as inter-managed object validation, but the attributes that are compared may be in different managed object "views". The validation is concerned primarily with the configuration definition, and is performed within the context of the current nodal configuration. It does not account for the instantiation of the configuration.

Not only does the management agent embody the network management view, it also has a limited understanding of the system view of communication device 104. It must know when a request is dependent on the behavior of multiple configuration managers, and how the request must be coordinated between those configuration managers 114, 116.

Each management agent 108, 1 10 performs the following tasks:

• Translation from network manager managed object "view" into communication device normalized "view"

• Validation of network manager requests as it pertains to the managed object "views".

• Physical resource validation & reservation (such as ports).

• Storing configuration data in the database.

^• Sending notifications to the appropriate communication device configuration managers regarding changes to the configuration database.

^• Translate and route managed object-specific actions to the appropriate communication device configuration manager. • Translate and route event messages from the communication device configuration managers to the network manager.

Database server 112 (DBS) stores configuration data in a relational form, and thereby allows multiple views of data. DBS may be composed of a memory, such as random access memory and disk storage. DBS 112 can support having two databases open at one time.

The database of DBS 112 provides a unified, normalized approach for managing configuration data, regardless of how the network managers and configuration managers "view" the data. The abstraction of communication device 104 is captured in the database, where data can be accessed by specifying appropriate criteria. Direct users of DBS 112 (e.g., management agents or configuration managers) translate their private "views" into and out of the normalized tables that make up the database. These direct users then use the database to create, delete, query, update, and search these tables according to varying criteria. The database contains all nodal configuration data.

When notified of configuration changes to the on-line configuration, configuration managers 114, 116, read those changes from DBS 112, and initiate their implementation in the node.

Configuration managers 114, 116 implement configuration requests within communication device 104 along functional boundaries. Configuration managers 114, 116 know about a single, on-line database which it uses to retrieve configuration data. Configuration managers 114, 116 implement the request by generating their own requests to the entity or entities to be configured, such as port 118 or call 120. Port 118 may be an EIA232 port connected to a host computer, or a T1 port connected to frame handler. Call 120 may be a connection through the communications network from one EIA232 port to another EIA232 port on another communications device.

Configuration managers 114, 116 read the database via DBS 112 to obtain configuration updates and initialization data. When updates have been made, configuration managers

114, 116 read the update so that it can instantiate the change. Configuration managers 114, 116 also read the database via DBS 112 during node is initialization.

The operations between either management agent 108,

110 and either or both configuration managers 114, 116 is specified as part of the configuration manager interface specification. There are a generic set of operations that are available on all configuration managers 114, 116. These operations are the same as, and follow the same definitions given earlier for Create, Delete and Modify.

FIG. 3 shows the support of multiple views by the database. One of the functions of the relational database is to provide the ability for its multiple users (clients) to maintain separate and distinct view of the data in the database. The view of proprietary network manager 100 (FIG. 2) view is embodied in a Proprietary management agent (200). Similarly, the view of SNMP manager 102 (FIG. 2) is embodied by SNMP management agent 202. A relational database 204 contains base tables defined in 3NF. Relational database 204 contains the implementation of the data model of communication device 104 (FIG. 2) and the implementation view of communication device 104 as embodied by configuration managers 1 14, 116. Database 204 allows support of multiple versions of configuration data: on-line (or active), off-line (or alternate), etc. For example, "off-line" configuration data can be specified, validated, and stored in database 204 without 5 requiring communication device 104 to implement such configuration. Communication device 104 can be subsequently rebooted to use this off-line database. Only one configuration is "on-line" or active at any particular time.

o FIG. 4 is a flow chart for the handling of management requests by the management agent system shown in FIGs. 2 and 3. Proprietary network manager 100 sends a management request to communication device 104 to configure a new port 118 (Step 302). The management request is received by 5 communication device 104 and routed to the appropriate management agent, in this case proprietary management agent 108 (Step 304). The management agent 108 validates the port configuration request for syntactic and semantic correctness (Step 306). If the request is not valid (Step 308), the 0 management agent 108 returns an error response to the network manager 100 (Step 310). If the management request is valid, the management agent 108 maps the network manager-organized configuration data for the port into the 3NF normalized form. (Step 312). Management agent 108 updates the base tables containing port configuration using the database server 112 (Step 314). After the database is updated, management agent 108 notifies configuration manager 114 that there is a new port configuration data in the database (Step 316). Configuration manager 114 reads the new port configuration data in 3NF form using the services of the database server 112 (Step 318). Configuration manager 114 maps the data from 3NF form into the communication device 114 specific form required to implement the port's configuration (Step 320). The configuration manager 114 implements the port configuration by talking to the port 118 and providing it the configuration data (Step 322). The configuration manager 114 responds to the management agent 108 that the port has been configured (Step 324). The management agent 108 sends a management response back to the network manager 100 indicating the management request was successfully completed (Step 326). Finally, the network manager 100 receives the management response from the management agent 108 (Step 328).

Conclusion

This combination of the following elements relational network managers 100, 102, management agents 108, 100 and database 204 storing information in (3NF) isolates the external management view from the internal physical view by the use of data mapping is new. This scheme allows for the easy addition of new "views" (e.g. management agents), which are independent from existing views, and therefore have no impact to the existing views.

Because each view of communication device 104 has its own model for looking at its data, these views (external models) are mapped onto a "normalized" data model which is in 3NF form. The internal views (e.g., configuration managers 114, 116) also map to the database #nf view. This allows for multiple interpretations of the management model by different portions of the communication device.

Since external modeling of a communication device can often be orthogonal to the actual internal implementation, a means to reduce the complexity of this mapping is essential. Doing this mapping using data (via a database) instead of code is the means offered in this invention. Thus, the described system supports the capability to provide multiple views easily. This management agent system is easily adaptable to a communication device's changing requirements and complex data modeling environment. Further, the complexity of mapping between network manager and the communication device is reduced.

The system also avoids imposing the network management/user view on the internal communication device, and avoids imposing internal implementations within the communication device on the network management/user view. This avoids having changes in one view affect the other view, resulting in greater efficiency and adaptability.

The network manager/user view is hidden from internal implementations, allowing either to change as required by the network. Further, the addition of multiple network managers may be easily accomplished by adding new management agents.

All of these advantages add up to reduced development and maintenance costs for communications device 104, as well as reduced random access memory utilization in the device, thereby reducing its cost to manufacture.

Claims

We Claim:

1. A management agent system for a communication device comprising:

a network manager for configuring the communication device, the network manager having configuration information for configuring the communication device;

o a communication device management agent, coupled to the network manager, where the communication device management agent handles management requests on behalf of the network manager;

5 a communication device database, coupled to the communication device management agent, where the communication device management agent stores configuration information for the communication device;

0 a communication device configuration manager, coupled to the communication device database and the communication device, the communication device configuration manager reading the configuration information from the communication device database, and then configuring the communication device. 5

2. The management agent system of claim 1 where there are a plurality of network managers.

3. The management agent system of claim 2 where the 0 communication device management agent maps the communication device information into the communication device database.

4. The management agent system of claim 3 where the 5 mapping of the communication device information into the communication device database converts the communication device information into a third normal form.

5. The management agent system of claim 4 where at least two of the network managers have different organizational views of the communication device information.

6. The management agent system of claim 5 where the communication device configuration manager converts the o communication device information stored in the communication device database from third normal form into information for configuring the communication device.

7. A method of configuring a communication device 5 comprising the steps of: storing configuration information about a communication device in a communication device database; reading the configuration information from the communication device database; 0 configuring the communication device from the configuration information.

8. The method of claim 7 where the step of storing configuration information includes the step of converting the 5 configuration information into third normal form and the step of reading the configuration information from the communication device database includes converting the configuration from third normal form into a configuration information organization recognizable by the communication device.

9. The method of claim 8 where the step of configuring the communication device includes sending a command to the communication device instructing the communication device to begin configuration.

10. The method of claim 9 where the step of configuring the communication device includes the step of updating one of more of the versions of the configuration data in the communication device database.