Enhanced simple network management protocol (SNMP) for network and systems management

[0002] This application claims the benefit of U.S. Provisional Application No. 60/064,178, filed Nov. 4, 1997.

[0003] File Name: GIC-514.appendix.doc

[0004] Size (KB): 145 KB

[0005] Date of Creation: Apr. 1, 2002

[0006] A CD-ROM entitled “Appendix for Enhanced Simple Network Management Protocol (SNMP) For Network and Systems Management” containing an Appendix entitled “Computer Code in ANSI.1 Language” is made a part hereof and is incorporated herein by reference. The CD-ROM contains the following file:

[0007] The present invention relates to a method and apparatus for providing an enhanced Simple Network Management Protocol (SNMP) for network and systems management. The invention is suitable for use with communication networks, including LANs, WANs, and internets.

[0008] The following acronyms are used in this application:

[0009] SNMP Simple network management protocol

[0010] ASN Abstract Syntax Notation

[0011] CCITT International Telegraph And Telephone

[0012] Consultative Committee (Translation)

[0013] CMIP Common Management Information Protocol

[0014] CMISE Common Management Information Service Elements

[0015] EFD Event Forwarding Discriminator

[0016] FDDI Fiber Distributed Data Interface

[0017] IETF Internet Engineering Task Force

[0018] IP Internet Protocol

[0019] ITU International Telecommunications Union

[0020] LAN Local Area Network

[0021] LD Log Discriminator

[0022] LMI Local Management Interface

[0023] MIB Management Information Base

[0024] NMF Network Management Forum

[0025] OSI Open Systems Interconnection

[0026] Q3 A TMN interface specification

[0027] RFC Request For Comment, published by the IETF

[0028] SMI Structure of Management Information

[0029] SNMP Simple Network Management Protocol

[0030] TCP Transaction Control Protocol

[0031] TMN Telecommunications Management Network

[0032] UDP User Datagram Protocol

[0033] WAN Wide Area Network

[0034] Management of a system such as a communications network is concerned with supervising and controlling the system so that it fulfills the requirements of both the owners and users of the system. This includes the long-term planning required for the system to evolve to provide improved performance, and to incorporate new functionality or new technology. Management may also involve accounting to ensure that resources are fairly allocated to users, or to charge users for use of services. The management of a system may be performed by a combination of human and automated components. The term “manager” is used to refer to any entity, human or automated, that can perform management activities in a communications network or system. The manager encompasses a management station, and a human operator interface, discussed below.

[0035] As part of the online control of the system, one or more managers must perform the following activities:

[0036] Monitor the system to obtain up-to-date status information and to receive event reports from the agents;

[0037] Interpret the overall policy pertaining to the goals or requirements of the organization that owns the system to make decisions about what behavior is required from the system; and

[0038] Perform control actions on the system resources to change their behavior and implement the management decisions.

[0039] As the number and variety of communications networks and services has grown, so has the diversity of management needs. In the past, these needs were satisfied by the manufacturer of the network equipment, or by network operator specific solutions. The resultant proliferation of incompatible management solutions has complicated the management of services and networks supported by different manufacturers' network equipment. It has also severely restricted the ability of network and service providers to exchange information in electronic form.

[0040] It has been realized that the communications industry would benefit from the existence of a consistent set of standards that would permit interoperability between a broad range of network equipment and management systems while allowing operators the freedom to adopt various implementation strategies. Network and service providers also have realized that they would benefit from the ability to exchange information electronically to provide services.

[0041] Standardization of management interactions provides obvious benefits of being able to manage multi-vendor components from a single management platform. Many different standards have been and are being introduced to cope with the complexities of network and distributed systems management. They include:

[0042] Internet Management Standards;

[0043] Telecommunications Management Network (TMN) Standards;

[0044] Open Systems Interconnection (OSI) Management Standards; and

[0045] Network Management Forum (NMF) Standards.

[0046] The most widely accepted management standard is the Internet SNMP set of standards, which was originally defined in the framework currently known as SNMPv1:

[0047] Structure and Identification of Management Information (SMI) for TCP/IP-based networks—RFC 1155 describes how managed objects contained in a

[0048] Management Information Base (MIB) are defined; Management Information Base (MIB) for Network Management of TCP/IP-based Internets—RFC 1213 describes the managed objects contained in the MIB; and

[0049] Simple Network Management Protocol (SNMP)—RFC 1157 defines the protocol used to manage the managed objects.

[0050] The model of network management that is used for SNMP consists of the following basic elements:

[0051] Management station,

[0052] Management agent;

[0053] Management information base; and

[0054] Network management protocol.

[0055] Managed objects are accessed via a virtual information store, termed the Management Information Base, or MIB. Objects in the MIB are defined using the subset of Abstract Syntax Notation One (ASN.1) defined in the SMI. In particular, each object type is named by an OBJECT IDENTIFIER, an administratively assigned name. The object type together with an object instance serves to uniquely identify a specific instantiation of the object. For human convenience, we often use a textual string, termed the “object descriptor”, to refer to the object type.

[0056] Most computer and, communications equipment in the world today is SNMP manageable. SNMP is usually supported by the standard Internet User Datagram Protocol (UDP) and Internet Protocol (IP) over most existing communications environments such as serial links, Ethernet, FDDI, ATM, etc. A functionally richer version of SNMP, SNMPv2 has been introduced in 1993. The security and administration framework associated with SNMPv2 has not found wide acceptance and is currently in the process of being replaced in the SNMPv3 framework which consists of SNMPv1 and SNMPv2 and a new administrative and security framework.

[0057] The SNMP Network Management Framework presently consists of three major components. They are:

[0058] (1) the SNMPv2 SMI, described in RFC 1902—the mechanisms used for describing and naming objects for the purpose of management;

[0059] (2) the SNMPv1 MIB-II, described in RFC 1213—the core set of managed objects for the Internet suite of protocols; and

[0060] (3) the protocol, SNMPv1 RFC 1157 and/or SNMPv2 RFC 1905—the protocol for accessing managed objects.

[0061] The Telecommunications-Management Network (TMN) standard was developed by the CCITT (ITU-T) to provide an architecture to achieve an interconnection between various types of management systems and telecommunications equipment for the exchange of management information over standardized interfaces. TMN is largely based on OSI management standards and includes:

[0062] Principles for TMN (ITU-T M.3010 and M.3020), which defines the architecture;

[0063] Generic Network Information model (ITU-T M.3100);

[0064] Management Services (ITU-T M.3200);

[0065] Management Function (ITU-T M.3400); and

[0066] Protocol Profiles for Management Interfaces (ITU-T Q.811, Q.812, Q.773).

[0067] It is intended that all networks, telecommunications services, and major type of equipment may be managed by TMN.

[0068] TMN functions exchange management information by means of the ITU-T X-700 (OSI system management) standards. Each software component in a TMN layer represents itself and the resources it manages to the layer above as a managed object. The interactions between manager and agent are defined by means of CMISE/CMIP. The organization of the information architecture, the MIB, contains managed objects for specific technologies that can be refined from the general template provided in ITU-T M-3100, the Generic Network Information Model.

[0069] All TMN communication is based on the Agent-Manager paradigm. The Q3 interface relies on the OSI management model using the OSI Common Management Information protocol. CMIP is used between Common Management Information Service Elements (CMISE) to provide Common Management Information Service (CMIS).

[0070] However, while SNMP-based management is commonly used because of its simplicity and resulting low cost of implementation, OSI CMIP and TMN because of their complexity are used only in very few systems restricted mostly to the telecommunications domain. To enable integration between the two types of systems the Network Management Forum (NMF) developed architectural solutions and translation schemes like “NMF Translation of ISO/CCITT GDMO MIBS to Internet MIBS”. However all of these solutions have aimed at integration of the two types of systems and at a complete, literal translation. Because of the complexity of OSI, CMIP and TMN, this solution is not widely used and the sophisticated management techniques enabled by OSI, CMIP and TMN have not been used within SNMP management systems.

[0071] Accordingly, it would be desirable to provide an enhanced SNMP management system for telecommunications networks which efficiently provides many of the sophisticated management techniques enabled by OSI, CMIP and TMN, while maintaining the simplicity of SNMP.

[0072] The enhanced SNMP should define a management state of each SNMP agent, define events which are to be reported from the agent to an SNMP management station, and provide a log for recording particular events and associated agent data vales when the events occur. The enhanced SNMP should further provide the capability for an alarm, state change, and value change notification to be communicated from the SNMP agents to the SNMP management station when specific events occur at the agent.

[0073] The present invention provides a system having the above and other advantages.

[0074] The present invention relates to a method and apparatus for providing an enhanced Simple Network Management Protocol (SNMP) for network and systems management.

[0075] The present invention enables the use of the TMN X.700 techniques in SNMP management systems through a new mapping of the X.700 information model onto the SNMP information model. This mapping enables the use of the X.700 techniques in a way that is consistent with the SNMP management paradigm instead of attempting a complete, literal translation as the NMF has done.

[0076] A state information module, events module, and a log model are defined which enable X.700-style alarm and event surveillance, and event reporting.

[0077] A method is presented for providing an enhanced Simple Network Management Protocol (SNMP) for use by an SNMP management station in managing at least one SNMP agent in accordance with the present invention.

[0078] State information is defined at the management station designating the state of the agent, any of its components, or any resource represented by the agent, as a result of a communication with the agent, or as a future state to be imposed on the agent.

[0079] The method comprises the steps of: defining event information at the management station, and communicating the event information to the at least one agent via a network; storing the event information at the agent; the event information defining pre-conditions for generating an event; monitoring data associated with the agent to determine if the pre-conditions have been met, and, if so, generating the event at the agent; and communicating a notification regarding the event from the agent to the management station via the network.

[0080] The notification designates a particular available notification type that includes at least one of an alarm notification indicative of an alarm condition at the agent, a state change notification indicative of a change of a state of the agent, and a value change notification indicative of a change in a value of an object associated with the agent. For example, an alarm condition may exist at the agent if the value of an object associated with the agent is not in a predetermined acceptable range.

[0081] The method may include the further steps of defining administrative state information at the management station designating whether the agent, any of its components, or any resource represented by the agent has a locked or unlocked status, and communicating the administrative state information to the agent via the network.

[0082] The method may include the further steps of defining operational state information at the management station designating whether the agent, any of its components, or any resource represented by the agent has an enabled or disabled status; communicating the operational state information to the agent via the network and monitoring the enabled or disabled status at the agent to determine a change in the state of the agent, any of its components, or any resource represented by the agent.

[0083] The method may include the further steps of defining operational state information at the agent, any of its components, or any resource represented by the agent which designates an enabled or disabled status thereof and monitoring the enabled or disabled status at the agent to determine a change in the state of the agent, any of its components, or any resource represented by the agent.

[0084] The method may include the further steps of defining availability status information at the agent designating whether or not the agent, any of its components, or any resource represented by the agent is available; and monitoring the availability status at the agent to determine a change in the state of the agent, any of its components, or any resource represented by the agent.

[0085] The event information may define the available notification types (e.g., alarm, state change or value change).

[0086] The event information may. define event forwarding discriminator (EFD) information that defines EFD pre-conditions for the notification communicating step, in which case the method includes the further steps of: monitoring events that are generated by the agent to determine if the EFD pre-conditions have been met, and, if so, communicating the notification regarding the event from the agent to the management station via the network. For example, an event may be generated but may not be important enough to qualify to have a notification communicated to the management station immediately. The notification may therefore be communicated to the management station at a later time, or not at all. Or the notification may be communicated when a predetermined number of events occurs.

[0087] The EFD information may define a schedule for communicating the notification regarding the event from the agent to the management station via the network.

[0088] When the network is associated with a plurality of SNMP management stations, the EFD information defines particular ones of the plurality of SNMP management stations that are to receive the notification regarding the event.

[0089] When EFD information is defined, the method may include the further steps of defining administrative state information at the management station designating whether the EFD has a locked or unlocked status, and communicating the administrative state information to the agent via the network; and monitoring the locked or unlocked status at the agent to determine if the EFD pre-conditions have been met.

[0090] When EFD information is defined, the method may include the further steps of defining operational state information at the management station designating whether the EFD has an enabled or disabled status, and communicating the operational state information to the agent via the network; and monitoring the enabled or disabled status at the agent to determine if the EFD pre-conditions have been met.

[0091] When EFD information is defined, the method may include the further steps of defining operational state information of the EFD which designates an enabled or disabled status thereof; and monitoring the enabled or disabled status at the agent to determine if the EFD pre-conditions have been met. That is, a notification may not be provided for certain events if the agent is disabled.

[0092] When EFD information is defined, the method may include the further steps of defining availability status information at the agent designating whether or not the EFD is available; and monitoring the availability status information at the agent to determine if the EFD pre-conditions have been met. That is, the agent may have an automatic schedule which defines time periods in which a notification may be provided for certain events.

[0093] The method may include the further steps of defining log information at the management station, and communicating the log information to the agent via the network; storing the log information at the agent; the log information defining log pre-conditions for creating a log entry for the generated event; and monitoring data associated with the agent to determine if the log pre-conditions have been met, and, if so, creating the log entry for the generated event at the agent. The log is used by the agent to maintain a record of events.

[0094] When the log information defines log discriminator (LD) information that defines LD pre-conditions for creating the log entry for the generated event at the agent, the method may include the further steps of monitoring events that are generated by the agent to determine if the LD pre-conditions have been met, and, if so, creating the log entry for the generated event at the agent. That is, certain events may not qualify to be logged.

[0095] The LD information may define a schedule for creating the log entry for the generated event at the agent.

[0096] When LD information is defined, the method may include the further steps of defining administrative state information at the management station designating whether the LD has a locked or unlocked status, and communicating the administrative state information to the agent via the network; and monitoring the locked or unlocked status at the agent to determine if the log pre-conditions have been met. For example, certain events may not be logged if the agent is locked.

[0097] When LD information is defined, the method may include the further steps of defining operational state information of the LD which designates an enabled or disabled status thereof, and monitoring the enabled or disabled status at the agent to determine if the log pre-conditions have been met. For example, certain events may not be logged if the agent is disabled.

[0098] When LD information is defined, the method may include the further steps of defining availability status information at the agent designating whether or not the LD is available; and monitoring the availability status information at the agent to determine if the log pre-conditions have been met. That is, the agent may have an automatic schedule which defines time periods in which a log entry may be made for certain events.

[0099] When log information is defined, the method may include the further step of creating particular logs for the generated event according to the corresponding notification type to provide at least one of an alarm log entry, a state change log entry, and a value change log entry. For example, an event that has a particular notification type, such as an alarm, may be eligible to be entered into an alarm log.

[0100] When a log entry is provided, the method may include the further step of reading the log entry for the generated event to obtain the notification that is communicated from the agent to the management station. In this embodiment, communication of a notification and the entering of a log entry are dependent actions.

[0101] The method may include the further step of defining state information at the management station according to the notification that is communicated thereto from the agent; wherein the state information is adapted for use in managing the agent. For example, if the management station receives a notification of an alarm at an agent, the management station may communicate updated administrative state information to lock the agent, thereby effectively removing it from the network.

[0102] A corresponding apparatus is also presented for providing an enhanced Simple Network Management Protocol (SNMP) for use by an SNMP management station in managing at least one SNMP agent. The apparatus includes defining means, such as a processor and computer code stored in memory, and/or input from an operator interface, for defining event information at the management station; first communication means, such as a transceiver, for communicating the event information to the agent via a network; a memory, such as RAM, associated with the agent for storing the event information communicated thereto; the event information defining pre-conditions for generating an event; monitoring means, such as a micro-processor, associated with the agent for monitoring data associated therewith to determine if the pre-conditions have been met, and, if so, generating the event at the agent; and second communication means, such as a transceiver, associated with the agent for communicating a notification regarding the event to the management station via the network.

[0103] The notification designates a particular available notification type that includes at least one of an alarm notification indicative of an alarm condition at the agent, a state change notification indicative of a change of a state of the agent, and a value change notification indicative of a change in a value of an object associated with the agent.

[0104] The event information defines event forwarding discriminator (EFD) information that defines EFD pre-conditions for the second communication means; and the monitoring means-monitors events that are generated by the agent to determine if the EFD pre-conditions have been met, and, if so, the second communication means communicates the notification regarding the event to the management station via the network.

[0105] The EFD information may define a schedule for the second communication means to communicate the notification regarding the event from the agent to the management station via the network.

[0106] Optionally, the defining means defines administrative state information at the management station designating whether the agent, any of its components, or any resource represented by the agent has a locked or unlocked status; the first communication means communicates the administrative state information to the agent via the network; and the monitoring means monitors the locked or unlocked status at the agent to determine if the EFD pre-conditions have been met.

[0107] Optionally, the defining means defines operational state information at the agent, any of its components, or any resource represented by the agent which designates an enabled or disabled status thereof; and the monitoring means monitors the enabled or disabled status at the agent to determine if the EFD pre-conditions have been met.

[0108] Optionally, the defining means defines log information at the management station; the first communication means communicates the log information to the agent via the network; the memory stores the log information at the agent; the log information defines log pre-conditions for creating a log entry for the generated event; and the monitoring means monitors data associated with the agent to determine if the log pre-conditions have been met, and, if so, creates the log entry for the generated event at the agent.

[0109] When the defining means defines administrative state information at the management station designating whether the agent, any of its components, or any resource represented by the agent has a locked or unlocked status; the first communication means communicates the administrative state information to the agent via the network; and the monitoring means monitors the locked or unlocked status at the agent to determine if the log pre-conditions have been met.

[0110] Optionally, the defining means defines operational state information at the agent, any of its components, or any resource represented by the agent which designates an enabled or disabled status thereof; and the monitoring means monitors the enabled or disabled status at the agent to determine if the log pre-conditions have been met.

[0111] The defining means may define availability status information at the agent designating whether or not the agent, any of its components, or any resource represented by the agent is available; and the monitoring means may monitor the availability status information at the agent to determine if the log pre-conditions have been met.

[0112] The agent may include means for creating particular logs for the generated event according to the corresponding notification type to provide at least one of an alarm log entry, a state change log entry, and a value change log entry.

[0113] The agent may also include means for reading the log entry for the generated event to obtain the notification that is communicated from the second communication means to the management station.

[0114] The defining means may define state information at the management station according to the notification that is communicated thereto from the second communication means; and the state information may be adapted for use in managing the agent.

[0115] Optionally, the log information defines log discriminator (LD) information that defines LD pre-conditions for creating the log entry for the generated event at the agent; the monitoring means monitors events that are generated by the agent to determine if the LD preconditions have been met, and, if so, creates the log entry for the generated event at the agent.

[0116] FIG. 1 illustrates a network with an SNMP management station and several SNMP agents in accordance with the present invention.

[0117] FIG. 2 illustrates an SNMP protocol in accordance with the present invention.

[0118] FIG. 3 illustrates a state information module, events module, and logs module for an enhanced SNMP protocol in,accordance with the present invention.

[0119] FIG. 4 illustrates a state information module in accordance with the present invention.

[0120] FIG. 5 illustrates an events module in accordance with the present invention.

[0121] FIG. 6 illustrates a logs module in accordance with the present invention.

[0122] The present invention relates to a method and apparatus for providing an enhanced Simple Network Management Protocol (SNMP) for network and systems management. A state information module, events module, and a log model are defined which enable X.700 style alarm and event surveillance, and event reporting.

[0123] FIG. 1 illustrates a network with an SNMP management station and several SNMP agents in accordance with the present invention. An SNMP management station 110 may communicate with an operator interface 120, such as a keyboard, to receive information such as the administrative and operational states. The management station 110 has a memory 112, processor 114, and transceiver 116, and may be implemented as a workstation, personal computer or other type of computer or as a computer board or as a computer chip set. The memory 112 may comprise RAM, for example. The processor 114 may be a microprocessor. The transceiver 116, or transmitter/receiver is a conventional circuit such as a modem used for transmitting and receiving data.

[0124] A computer code to be used by the management processor set 110 is forth in the CD-ROM Appendix, and may be stored in the memory 112 and operated on by the processor 114. Information received from the operator interface 120 may also be stored in the memory 112.

[0125] The processor 114 may be used to execute the computer code to communicate information to specific agents, and to process information received from the agents.

[0126] The SNMP management station 110 communicates with a number of SNMP agents 130, 140 and 150 via a network or internet 160. Each agent, such as agent 150, may have a memory 151, processor 153, and transceiver 155, as well as one or more components, such as component 152, and may represent one or more resources, such as resource 154. The agent, e.g., agent 150, may also communicate with a MIB 156. The MIB may be provided as part of the general purpose memory 151.

[0127] Information, such as administrative state. information and event information may be communicated from the management station 110 to the agent 150 and stored in the memory 151. Event table data, EFD table data, and log control table data may be stored in the memory 151 for use by the agent 150. Alarm, state change, and value change log data may also be stored in the memory 151.

[0128] The processor 153 may be used to communicate information to, and receive information from, the management station 110, as well as for communicating with the MIB 156, resource 154, and component 152.

[0129] The management station 110 may be a standalone device (e.g., computer), or may be a capability implemented on a shared system. The station 110 serves as an interface for a human operator/manager into the management system and includes:

[0130] Management applications for data analysis, fault recovery, etc.;

[0131] A monitoring/control interface of the network for the manager;

[0132] The capability to translate a network manager's commands into actual monitoring and control of remote elements; and

[0133] A database of information extracted from the MIBs of all the managed entities in the network.

[0134] The SNMP management agents 130, 140, 150 are embedded in key entities such as hosts, bridges, routers, and hubs, and respond to requests for actions from the management station 110. The management agents may also synchronously provide the management station 110 with important unsolicited information. Each agent supports access to a collection of managed resources, which are represented by managed objects referred to as the MIB 156. Managed objects are standardized across systems of a particular class; for example, all routers support a standard set of objects, in addition to some objects that are specific to a particular manufacturer's router model.

[0135] The management station 110 performs a monitoring function by retrieving the value of MIB objects from the agents. A management station can cause an action to take place at an agent or change the configuration settings of an agent by modifying the value of specific variables. The management station and agent are linked by the Simple Network Management Protocol, which supports three key operations:

[0136] Get—enables the management station to get the value of object variables at the agent;

[0137] Set—enables the management station to set the value of object variables at the agent; and

[0138] Trap—enables an agent to asynchronously notify the management station of events.

[0139] There are no specific guidelines in the SNMP standards as to the number of management stations and the ratio of management stations per agent. In general, it is prudent to have at least two systems capable of performing the management station function to provide redundancy in case of failure. The number of management agents per station depends on the MIBs and particular environments but can be in the thousands.

[0140] FIG. 2 illustrates an SNMP protocol in accordance with the present invention. At a management station 210, three types of messages are issued on behalf of a management application 220, namely: GetRequest, GetNextRequest, and SetRequest. The first two are variations of the Get function. All three messages are acknowledged by the agent 230 in the form of a GetResponse message. This message is passed up to the management application 220. Also, the agent 230 may issue a trap message in response to an event that affects the MIB and the underlying managed resources 240.

[0141] Furthermore, in accordance with the present invention, the SNMP agent 230 may issue an alarm, state change, and value change to the management station 210 in response to an event that affects the MIB and a logs module 242 or events module 244.

[0142] SNMP is a connectionless protocol since it relies on UDP, which is also a connectionless protocol. That is, no ongoing connections are maintained between the management station 210 and the agent 230. Instead, each exchange is a separate transaction between the management station 210 and the agent 230.

[0143] The management application 220 includes state information 222, an events processing module 224, and a log processing module 226. The events processing module 224 is used to provide event information that is communicated to the agent to define pre-conditions for the agent to generate an event. The event information also defines EFD information that defines pre-conditions for communicating a notification of an event from the agent 230 to the management station 210 via the network 160. The EFD information may also define a schedule which the agent is to follow in communicating the notification. In this manner, the management station 210 can process the incoming notifications in an orderly manner.

[0144] The log processing module 226 is used to provide log information that is communicated to the agent to define pre-conditions for the agent to create a log entry for an event. The log information also defines log discriminator (LD) information that defines pre-conditions for creating the log entry for an event. The LD information may also define a schedule which the agent is to follow in communicating the notification. In this manner, the logging of events can be organized according to criteria set by the management station 210.

[0145] FIG. 3 illustrates a state information module, events module, and logs module for an enhanced SNMP protocol in accordance with the present invention. Conceptually, the use of the modules 310 with conventional SNMP 300 yields the enhanced SNMP 350 of the present invention. The modules 310 include a state information module 320, an events module 330, and a logs module 340.

[0146] The state information module 320 serves three purposes:

[0147] (1) Providing a way of representing the management state of agents across a network or internet, thereby minimizing redundancy of redeveloping information modules and maximizing design and implementation productivity and product quality;

[0148] (2) Providing a foundation for adopting the TMN Information Model in Element Managers. The state information module is based on the ITU-T X.731 standard which is part of the Q3 standard adopted by TMN; and

[0149] (3) Enabling (1) and (2) for modules, groups of objects, or rows in a table by using the same value sets.

[0150] The state information module 320 includes a number of states and status functions, including a management state, an administrative state, an operational state, a usage state, a procedural status, an alarm status, an availability status, a control status, a standby status, and an unknown status. These items are discussed in greater detail in connection with FIG. 4.

[0151] The events module 330 includes a number of items, including an events group, an event forwarding discrimination (EFD) group, which includes an administrative state, an operational state, and an availability status, and an event notification group, which includes an alarm, state change, and a value change. These items are discussed in greater detail in connection with FIG. 5.

[0152] The logs module 340 includes a log control group, and a logs group, which includes an alarm log, a state change log, and an object value change log. These items are discussed in greater detail in connection with FIG. 6.

[0153] FIG. 4 illustrates a state information module in accordance with the present invention. The management state 405 represents the instantaneous condition of availability and operability of the associated agent resource from the point of view of management. A variety of state attributes can be used that express and control aspects of the operation of the agent's resources that are specific to each agent. However, the management state is expected to be common to a large number of resources and, for this reason, should be uniform. The management state expresses key aspects of the resource's usefulness at any given time. The purpose of the management state is to control the general availability of a resource and to make visible information about that general availability.

[0154] The agent's resources may be actual hardware or software which is being represented by the agent to the manager through the management information.

[0155] The administrative state 410, which is designated by the object “unitAdministrativeState”, describes the administrative state of the unit represented by the agent/subagent with the possible values of locked, unlocked, and shuttingDown. A “subagent” refers to an agent under the control of another agent. The unit refers to some sort of a component, or all of the resource, i.e., the entity being managed through the agent. For example, a unit may be a personal computer (PC), a board within a PC, and so forth. The state values and state transitions are as defined in the ITU-T X.731 standard. The administrative state can be set by the manager and used to administratively prohibit the agent from use. In conjunction with the community string, the administrative state can be used for concurrency control.

[0156] The operational state 415, which is designated by the object “unitOperationalState”, describes the operational state of the unit represented by the agent/subagent, with the possible values of “enabled” or “disabled”. Management can not request the change of the operational state, but can designate pre-conditions for allowing an agent to determine whether it, or any of its components, or any resource represented by the agent is enabled or disable. It is the natural operation of the resource that causes operational state transitions to occur, e.g., after a network element completes a number of self-tests and all of its rudimentary tasks are initialized and running it can set its operational status from disabled to enabled. However, the management station can provide information to an agent which indirectly changes the agent's operational status. The state values and state transitions are as defined in the ITU-T X.731 standard.

[0157] The usage state 420, which is designated by the object “unitUsageState”, describes the usage state of the unit represented by the agent/subagent with the possible values of idle, active, or busy. Management can not request the change of the usage state. It is the natural operation of the resource that causes operational state transitions to occur The state values and state transitions are as defined in the ITU-T X.731 standard.

[0158] The procedural status 425, which is designated by the object “unitProceduralStatus”, describes the procedural status of the unit represented by the agent/subagent with the possible values of initializationRequired, notInitialized, initializing, reporting, terminating, and ready. The value defined for the procedural status in the X.731 standard is a set of enumerated values. Modeling a set value with SNMP object types would include a number of additional steps in the management of that value, i.e. either special encoding or a more complex data structure would be required. Therefore, true to the principle of “simple management”, a procedural status in accordance with the present invention is restricted to one of the enumerated sets with the addition of the value “ready” which corresponds to the empty set. This type of definition maps cleanly into the X.731 standard while not impairing the SNMP management paradigm. The procedural status can be set by the manager.

[0159] The alarm status 430, which is designated by the object “unitAlarmStatus”, describe's the alarm status. of the unit represented by the agent/subagent with the possible values; of underRepair, critical, major, minor, alarmOutstanding, and idle. The value defined for the alarm status in the X.731 standard is a set of enumerated values. Similar to the solution for the; procedural status, the alarm status in accordance with the present invention is restricted to one of the enumerated set with the addition of the value “idle” which corresponds to the empty set. The alarm status can be set by the manager.

[0160] The availability status 435, which is designated by the object “unitAvailabilityStatus”, describes-the availability status of the unit represented by the agent/subagent with the possible values of inTest, failed, poweroff, offLine, offDuty, dependency, degraded, notinstalled, logFull, and available. The value defined for the availability status in the X.731 standard is a set of enumerated values. Similar to the solution for the procedural status, the availability status is restricted to one of the enumerated sets, with the addition of the value “available” which corresponds to the empty set. Management cannot request the change of the availability status.

[0161] The control status, which is designated by the object “ControlStatus”, describes the control status of the unit represented by the agent/subagent with the possible values of subjectToTest, partLocked, reservedToTest, suspended, and free. The value defined for the control status in the X.731 standard is a set of enumerated values. Similar to the solution for the procedural status, the control status is restricted to one of the enumerated sets, with the addition of the value “free” which corresponds to the empty set. The control status can be set by the manager.

[0162] The standby status 445, which is designated by the object “unitStandbyStatus”, describes the standby status of the unit represented by the agent/subagent with the possible values of hotStandby, coldStandby, and providingService. Management can not request the change of the standby status. It is the natural operation of the resource that causes standby status transitions to occur. The status values and status transitions are as defined in the ITU-T X.731 standard.

[0163] The unknown status, which is designated by the object “unitUnknownStatus”, describes the unknown status of the unit represented by the agent/subagent with the possible values of true and false. Management can not request the change of the unknown status. It is the natural operation of the resource that causes unknown status transitions to occur. The status values and status transitions are as defined in the ITU-T X.731 standard.

[0164] FIG. 5 illustrates an events module in accordance with the present invention. The events module enables managers to configure the types of events that can be generated by an agent, and when those events should be transformed into asynchronous notifications (SNMP Traps) to be sent to different managers. The mechanism and information model used correspond to the TMN X.733 and X.734 standards defining event management and alarm reporting.

[0165] The events module defines the following object groups: Events group 510, Event Forwarding Discriminator (EFD) Group 530, and Event Notifications. The Events Group 510 comprises event configuration information defining the types of events that the agent shall generate, and the pre-conditions (i.e., conditions which must be met) for generating the events.

[0166] The Event Forwarding Discriminator (EFD) Group 530 comprises EFD configuration information defining what types of events an EFD will transform into notifications, at what times of day it will do so, and to which managers it will send the notifications to. Thus, only some events may result in a notification being sent from the agent to the management station.

[0167] The Event Notifications group 560 defines three types of notifications which an agent can send to a manger. These are an alarm notification, a state change notification, and a value change notification. Each EFD specifies what type of notification is to be sent for an event that has occurred in the agent. The EFD also specifies the conditions (e.g., pre-conditions) under which such a notification is to be sent and the IP address of the manager to which the notification is to be sent. All standard SNMP traps are sent to the managers UDP port 162. All management platforms, including HP OpenView™, Sun DomainManager™, etc. support this mechanism.

[0168] The Events Group 510 stores event descriptions in a table 515. Each row in the table 515 corresponds to an event that the agent is to generate. The event description in table 515 specifies the conditions under which the agent is to generate the event, for example, when a MIB variable has crossed a specified threshold, when a state has been changed, and so forth.

[0169] Once the agent generates an event as specified in the Event table 515, it checks an EFD Table 535 to find an EFD that matches that event and specifies what kind of notification is to be generated, and to which manager that notification is to be sent. The match is performed based on event characteristics such as event type, and so forth, which may be defined by event information that is communicated from the management station to the agent.

[0170] The EFDs in the EFD Table 535 are controlled by three state/status variables, namely the administrative state, the operational state, and the availability status. If the administrative state is not unlocked, or the operational state is not enabled, or the availability status is not available, the EFD is inactive. In this case, the EFD is ignored by the agent. The manager sets the administrative state of the events module, while the operational state is determined at the agent. The availability status is set as a result of an automatic scheduling function 540 that is also associated with the EFD and specified in the EFD table. The scheduling function 540 includes specifications of a daily start and stop time and a weekly mask specifying when the EFD changes availability status from off-duty to available. The mask is the value of a bit string which provides the change in EFD availability status or other designated information. Exemplary masks are defined in the Appendix under “EventType”.

[0171] The EFD group 530 also includes a discriminator construct 545 which specifies the characteristics an event must have in order to be selected for forwarding to the event notification group 560. These characteristics may be defined by EFD information which is part of the event information communicated from the management station to the agent.

[0172] FIG. 6 illustrates a logs module in accordance with the present invention. The logs module includes a log control group 610, which includes a log control table 620, a scheduling construct 630, and a discriminator construct 640. The logs module also includes a logs group 660, which includes an alarm log 670, a state change log 680, and an object value change log 690.

[0173] The logs module enables managers to configure the types of logs that can be generated by an agent. The mechanism and information model used are based on the ITU-T TMN X.735 Log Model. The logs module, in addition to conceptually storing the logged information, determines which information is to be logged. Each log control group 610 includes a discriminator construct 640 which specifies the characteristics an event must have in order to be selected for entry in a log.

[0174] The Log Control Group 610 defines the types of logs tables 620 the agent is maintaining, their discriminators, the log scheduling, and so forth. The Logs group 660 defines three logs, namely the alarm log 670, the state change log 680, and the object value change log 690.

[0175] Logs are controlled by the Log Control Table 620 as specified in the ITU-T TMN X.735. Each entry in that table associates events with logs and specifies when the event is to be entered in a log. An event is logged if the log discriminator 640 holds. That is, the event is logged, e.g., if is of a certain type, if it has been generated by a certain object, if it exceeds a certain threshold, and so forth. The log control entries themselves are controlled by state/status variables, namely, the administrative state, the operational state, and the availability status. The manager sets the administrative state of the log module, while the operational state is determined at the agent. The on an automatic log control scheduling mechanism 630 which specifies the times during which the logs are to be made.

[0176] Entries in the Log Control Table 620 also specify log control information and log statistics.

[0177] The three logs 670, 680, 690 defined are defined as tables in which each event is stored as a row. The logs in the alarm log table 670 are logs of alarm event that have passed the log control discriminator 640 in the Log Control Table 620. Similarly the logs in the state change log table 680 are logs of state changes. Additionally, logs in the object value change table 690 are logs of object value changes.

[0178] Information stored in the logs group is stored first at the agents, then read from time to time by the management station.

[0179] As can be seen, the present invention provides an enchanced SNMP management system for telecommunications networks which efficiently provides many of the sophisticated management techniques enabled by OSI, CMIP and TMN, while maintaining the simplicity of SNMP. The enhanced SNMP defines a management state of each SNMP agent, define events which are to be reported from the agent to the management station, and provides a log for recording particular events and associated agent data vales when the events occur. The enhanced SNMP also provides the capability for an alarm, state change, and value change notification to be communicated from the SNMP agents to an SNMP management station when specific events occur at the agent.

[0180] Although the invention has been described in connection with various specific embodiments, those skilled in the art will appreciate that numerous adaptations and modifications may be made thereto without departing from the spirit and scope of the invention as set forth in the claims.