Electrical computers and digital processing systems: multicomput – Computer network managing – Computer network monitoring
Reexamination Certificate
1998-12-04
2001-06-26
Black, Thomas (Department: 2171)
Electrical computers and digital processing systems: multicomput
Computer network managing
Computer network monitoring
C709S223000, C709S249000, C714S048000
Reexamination Certificate
active
06253243
ABSTRACT:
FIELD OF THE INVENTION
This invention relates to network management tools for managing distributed networks and, in particular, to SNMP trap management and distribution.
BACKGROUND OF THE INVENTION
Present day telecommunications and information networks have become larger and far more complex than those which have been available only a few years ago. The trend towards increases in size and complexity can be expected to continue at a high rate into the foreseeable future with the proliferation of cellular networks, the development and deployment of global satellite networks, and the expansion of basic wireline networks in developing nations. Both homogeneous and heterogeneous networks are now being connected together by means of the Internet and other inter-network connection mechanisms.
In order to maintain network reliability and an acceptable quality of service, it is necessary to carefully monitor and manage network resources. However, as existing networks grow larger and more complex, network management also becomes more difficult and more complex. The prior art responded by providing automated management tools for reporting network status. These tools allowed network management personnel to improve the quality of service and maintain high network availability and reliability.
Such automated management tools were distributed and generally arranged as client server applications which provided integrated for supporting heterogeneous network environments. The client portion of the tools was arranged to have a standard interface which minimized variations of look and feel of the system as seen by the network operations personnel whereas the server portion was designed to operate on different platforms. The distributed architecture allowed the tool to evolve and scale as the networks evolved in size, capabilities, and geographies.
One such distributed network management tool is the Solstice Enterprise Manager™ (Solstice EM) network management system which was developed and is marketed by Sun Microsystems, Inc. This tool has an object-oriented and distributed architecture which consists of a plurality of cooperating components, including applications, libraries, information services, databases, and protocols, each of which performs specific tasks. The managed resources are arranged as a plurality of interconnected nodes and “management agents” running in each node gather information about the resources associated with the node. The information is then forwarded back to a management information server (MIS) which interacts with management applications running in other nodes. The MIS can request and change management parameter values, perform requested actions, and receive and evaluate problem reports (e.g. events, such as SNMP traps and CMIP notifications) that the management agents generate.
Although the MIS and the management agents can communicate with each other via various network management protocols such as Simple Network Management Protocol(SNMP), Common Management Information Protocol (CMIP), or other proprietary/legacy protocols, the Solstice EM™ framework interposes software model representations of managed resources in the MIS between management applications and agents of managed resources. The result is that the management applications need not be concerned with management protocol dependencies of the managed resources since the applications only interact with the software model representations in the MIS.
In particular, the management applications direct management tasks in the MIS via a “Portable Management Interface (PMI)” which is a high-level abstraction of an interface for manipulating objects, regardless of their class description, supported protocol, or location. The PMI is also used by the MIS to communicate with the management agents. For example, the MIS can use a management protocol adapter (MPA) to communicate with a management agent. An MPA translates MIS requests to protocol-specific primitives (e.g. CMIP, SNMP, RPC, or other proprietary/legacy protocol primitives) depending upon the management agent in question. For example, a CMIP MPA communicates with CMIP agents.
One of the most important tasks that a network manager can perform is “alarm” monitoring and management. An alarm is an unsolicited notification called a “trap” in SNMP terminology and an “event” in CMIP terminology which is generated by an agent and sent to the MIS. The notification generally indicates that a particular managed resource associated with the agent has experienced a fault or failure condition or otherwise requires attention. Alarms have an associated severity level which can range from “critical” to “warning.”
Network management personnel can manage the alarms by changing their state. For example, a newly generated alarm has an “open” state. Network management personnel can “acknowledge” the alarm indicating that the alarm has been noted. After investigating the problem, the alarm can be “cleared”, indicating the problem has been corrected.
Alarm Services is a module in the Solstice EM™ MIS responsible for updating and storing the state of managed objects in the MIS. Alarms arrive at the MIS as event notifications (via an MPA, for example). When such an event is received by the MIS, it is stored in an alarm log as an alarm log record by a Logging Services module and the Alarm Services module is informed about the arrival of this alarm. The Alarm Services module maps each managed-object-based alarm to a corresponding node in a topology database (discussed below) and updates the alarm counters for that topology node based on the alarm severity. The Alarm Services module also keeps the severity synchronized so that it represents the highest (most critical) uncleared alarm log record that is posted against the topology node. The node status is propagated to applications like the Solstice EM™ Viewer and displayed in the appropriate color. The alarm information is also sent to the Solstice EM™ Alarm Manager application for display.
The Solstice EM™ system provides logging services, whereby all network events of interest can be logged in the system. Event logs (also referred to as “logs”) maintain a record of the information provided in event notifications. Each log can be configured to select the event notification information that should be recorded in the log. An MIS can contain multiple logs, each containing a different configuration in order to record different types of information (corresponding to different events) in separate logs. Each log is a local managed object. A log contains event log records which mirror information in the event notifications. If a new notification is added to the MIS, a new event log record managed object class that corresponds to the new notification type is also added.
SNMP traps generated by SNMP agents on the network are handled by a Solstice EM™ management system daemon called the “em_snmp-trap” daemon. This daemon is a separate UNIX process which listens on a predetermined network port for incoming SNMP traps which must be forwarded to management stations. The trap daemon forwards the traps to SNMP network managers. The trap daemon also converts incoming SNMP traps to CMIP event notifications which are then sent to the Solstice EM™ management system MIS. Like other EM applications, the em_snmp-trap daemon uses the Portable Management Interface to communicate with the MIS.
The trap daemon's mapping of SNMP traps into CMIP notifications is controlled by entries in a configuration file called a trap mapping file, “trap_maps”. The trap_maps file is an ASCII text file that resides in a configuration file directory which the trap daemon reads whenever it starts. The trap daemon can also forward raw SNMP traps to other network managers. The host name and port number of the managers that are to receive the forwarded SNMP traps are held in another configuration file called the “trap_forward” file.
A problem with the SNMP trap daemon is that it is relatively inflexible. For example, the attributes of an incoming SNMP trap must exactly match the a
Black Thomas
Kudirka & Jobse LLP
Loomis John C.
Sun Microsystems Inc.
LandOfFree
Automated trap control for a distributed network management... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Automated trap control for a distributed network management..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Automated trap control for a distributed network management... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2448473