Trap filtering in a telecommunication network management
Field of the invention
The invention relates to the field of telecommunication networks management.
Background of the invention Today, large numbers of personal computers and workstations are being interconnected with file servers, print servers, modems, hubs and other devices to form local area networks, metropolitan area networks and wide area networks. These networks allow the personal computers and workstations to share information and valuable resources among each other.
Networks that have centralized management use a network manager and some type of network management protocol such as Simple Network Management Protocol (SNMP) to communicate with a plurality of agents (of the devices on the network). Among its management tasks, the network manager handles traps from the agents. In network management, "trap" is known as a mechanism permitting a device to automatically send an event or an alarm for certain network events to a management station (manager). In other words, trap indicates the occurrence of a special event or a serious problem in a device. The network manager can correct a problem by commanding the device generating the trap to take a different course of action. Or, the network manager can sound an alarm, print out a report, display the status of the device or initiate some other kind of signaling action that notifies a
network administrator of the problem. Having been notified, the network administrator has the problem corrected.
The problem is, networks can be very large, containing hundreds or thousands of devices. Problems with different devices may occur simultaneously. The network administrator cannot respond to all of the problems simultaneously and at times the network administrator can be overwhelmed by a large number of alarms and reports.
As has been mentioned, the above relates to a widely known type of hierarchy in the communications management, where a manager communicates with a number of its agents, and each agent is in contact with its sole manager.
An alternative type of hierarchy (decentralized hierarchy) exists and starts becoming more and more accepted, where an agent reports to a plurality of managers on various aspects of its functioning. In such a case, the transmission of data from agents is accomplished in the way, where each of the managers receives all information intended for the pull of managers and filters the information upon receipt, to extract therefrom only the portion relevant to this particular manager. Such a manner of transmission overflows the network. Surprisingly, no effective solutions have been proposed to date to resolve the problem.
US 5,828,830 describes a technology for prioritizing and filtering traps when arriving from network devices (agents) to a manager. The filtering and the prioritization can be performed by a trap block, and are executed by a network manager. Upon processing the traps in the manager, events dispatcher procedure is utilized.
JP application 183 932 A2 describes a hierarchical network management system proposed to selectively report trap information that an integrated manager requires, and to lighten the load on the integrated manager by filtering trap information reported from an agent by
respective submanagers. Namely, a submanager receives trap information reported from an agent and filters the trap information by referring to filter conditions set in a particular filter. Consequently, only the selected trap information is reported to the manager and the load on the manager is lightened. The system is intended for the centralized management hierarchy and, by introducing an intermediate level of the hierarchy, succeeds to reduce traffic load on the higher hierarchy level.
Still, it is to be noted that the communication between any agent and its submanager(s) load the network with excessive information held neither by a particular submanager nor by its manager.
Object of the invention
It is therefore the object of the present invention to provide a new technology in the decentralized management hierarchy, which prevents excessive loading of the telecommunication network with trap messages.
Summary of the invention The present invention pertains to a method, a system, a device and a program product for managing a network according to a decentralized hierarchy.
In accordance with a first aspect of the invention, the above object can be achieved by providing a method for transmitting traps between an agent communicating with two or more managers in a management system of a telecommunication network, by
- providing the two or more managers, each being capable of handling traps particularly intended for it,
- providing the agent capable of processing the traps and sending thereof to said two or more managers, the method additionally comprising the steps of:
- filtering said traps at said agent to sort the traps per managers for which the traps are intended, and
- transmitting each particular trap only to one or more of the managers for which said particular trap is intended. According to a second aspect of the present invention, there is provided a management system of a telecommunication network, comprising an agent and a plurality of managers to which the agent is capable of sending traps, the system being characterized in that the agent is provided with at least one trap filtering module for filtering the traps to be sent from the agent in a manner enabling selective transmission of each particular trap to one or more managers of said plurality.
According to a third aspect of the invention, the object can be achieved by providing a trap filtering module (being a hadware/software product) suitable for being installed in a network device as a part of agent communicating with a plurality of managers in a telecommunication network, wherein said filtering module is capable of processing traps obtained in said device, sorting said traps per the managers to ensure selective transmission of each particular trap to one or more managers of said plurality.
The trap filtering module at the agent level may be built according to one of the following embodiments. It may be capable of obtaining said traps in a universal format and filtering the obtained universally formatted traps by a trap filter defining logical conditions, thereby ensuring
distribution of said traps between suitable managers according to said conditions.
Alternatively, the trap filtering module can be adapted to obtain said traps in different formats respectively accepted for different applications supported by the network device, and to filter these differently formatted traps by different respective filters each defining its logical conditions, in order to distribute said traps between suitable managers according to said conditions.
Further, a network device comprising the above-mentioned filtering module is also considered a product to be protected in the frame of the present invention, as one of the invention aspects.
It is understood that sending the precise information to each of the managers enables drastic alleviation of the network load to be achieved. The described concept can be applied, for example, to network management systems utilizing the SNMP (Simple Network Management Protocol), since the outlined problem is not resolved in the frame of SNMP.
Other general and specific objects of this invention will be apparent and evident from the accompanying drawings and the following description.
Brief description of the drawings
The invention will be further described with reference to the following non-limiting drawings, in which: Fig. la is a schematic block-diagram illustrating one known arrangement of a network management, according to the decentralized hierarchy.
Fig. lb is a schematic block-diagram illustrating another known arrangement of management of the same network, utilizing both the centralized and the decentralized hierarchy.
Fig. 2a is a schematic block diagram illustrating how traps arriving from different network devices, associated with respective agents, are sorted in the network management system shown in Fig. la.
Fig. 2b is a schematic block diagram illustrating how traps arriving from different network devices, associated with respective agents, are sorted in the network management system shown in Fig. lb. Fig. 3 is a schematic block-diagram generally illustrating one embodiment of the proposed technology of trap filtering at the agent level for the decentralized management hierarchy.
Fig. 4 is a block-diagram schematically illustrating another embodiment for trap filtering at the agent level. Fig. 5 is a schematic illustration of exemplary formats of different trap structures.
Fig. 6 is a tabular presentation of an exemplary trap filter which can be utilized in the block-diagram shown in Fig. 4.
Detailed description of preferred embodiments
Fig. la shows a block diagram schematically illustrating a simple decentralized network management hierarchy. The block diagram comprises a plurality of network elements which, in the frame of the present application, will intermittently be called devices or agents (marked Al to A3 in the diagram) and a plurality of element managers (marked Ml and M2). In the frame of the present description, the term "agent" is understood as a hardware/software unit incorporated in a network element and intended for exchanging control information with one or more managers in the network. It can be seen that according to
such an arrangement, any of the agents communicates with more than one manager. The managers are usually implemented as computers, and each performs a function of filtering traps arriving from various agents to discard unnecessary ones and take into account only those required by the specific manager.
Fig. lb schematically illustrates an exemplary attempt to alleviate both the traffic load in the network and the load on the managers Ml, M2 by introducing an intermediate layer manager. The configuration represents a mixed centralized-decentralized network management hierarchy, if compared with Fig. la. The illustrated hierarchy shows a plurality of network elements Al, A2, A3, which communicate with one common intermediate layer manager (submanager SubM) according to the centralized principle, while the submanager communicates with the two higher level managers Ml and M2. The submanager performs both the filtering and the forwarding function, to filter from traps sent by the agents only those necessary for the two managers Ml and M2, and to forward them to the upper level of the management.
Fig. 2a is a block-diagram illustrating the presently used arrangement of trap filtering at the manager layer, when each manager receives traps from a number of agents of the lowest level (terminals), utilizing an SNMP protocol. In the drawing, the two managers are indicated as Ml and M2, and the two terminals - as Al and A2. The management arrangement is according to Fig. la.
Each of the terminals supports one or more applications. For the purpose of example only, the terminal Al is shown as supporting at least an ATM application and an El application, and the terminal Al as supporting an ATM application and an SDH application. (Wherein ATM is Asynchronous Transfer Mode for transmitting data, El is a protocol used for communication with local exchanges, and SDH is Synchronous
Digital Hierarchy used for transmitting high bit rate data). Each of the applications (say, a computer program running to provide terminal A2 with connection to an IP network) may issue a message 10 on event which comprises a routine functioning report (or an alarm report) requiring any reaction from the side of a manager. These event messages usually have different digital formats depending on the application. The event messages generated by a terminal (Al or A2) from various applications are transformed into a form of traps 12 accepted in the protocol according to which the device communicates with its managers. The format of traps comprises the trap data and depends on the format used in a particular application which has generated the event, and on the particular event. For example, the trap reporting failure of a link in an ATM-type application may have a longer frame format than the trap reporting a change of the clock or the absence of lines from the El -type application.
Most of the modern network protocols (including SNMP) state different formats for reporting traps to different managers (and from different devices). Therefore, the manager should first bring them to a uniform format and put into one database, and then to filter them in order to learn whether each of them is intended for this particular manager. According to the block diagram, traps issued by the terminals Al and A2 are sent to both the manager Ml, and the manager M2.
Any trap arriving to the manager Ml, is received by a translator block Tl for transforming it into a form suitable for temporary storing it as an entry in the manager's memory. The manager's Ml memory comprises data base MDB1 and Filter block FI. Entries stored in the memory are further filtered by a filter module FI. The filter module is capable of analyzing entries and sorting thereof into two different categories, including entries intended for the manager Ml (traps to be
handled by it) and entries not intended for the manager Ml (traps to be discarded).
Similar operations are performed by the manager M2. Fig. 2b illustrates a block-diagram illustrating another presently used management arrangement, where trap filtering is effected at an intermediate level manager which receives traps from a number of agents of the lowest level utilizing, say, SNMP protocol (the block-diagram shown in solid lines). In the drawing, the two managers are indicated as Ml and M2, the two terminals - as Al and A2, and a newly introduced intermediate manager (submanager) - as SubM.
As in Fig. 2a, each of the terminals supports one or more applications. The SubM, when receiving traps from different agents Al and A2, brings them to a uniform format (block T) and filters them (block F) to learn which of them can be discarded, and which must be forwarded to one and/or another higher level manager. Optionally, some of the traps may be handled by the submanager.
It should be noted that the arrangement with submanagers has been developed and is justified in systems built using the centralized principle. In other words, when some of traps received by a submanager are to be held at its level and some of traps are to be sent to higher level manager(s), the described arrangement of filtering traps is still effective since it partially reduces the network traffic in comparison with the configuration shown in Fig. la (if the number of agents is three or more). However, in systems utilizing the decentralized principle (such as the block-diagram of Fig. 2b taken together with elements and connections shown in dashed lines) i.e., when an intermediate layer manager may receive traps intended neither for it, nor for its higher level administrator, the arrangement with intermediate managers becomes inefficient. This is the case at least in systems utilizing the SNMP protocol.
Fig. 3 is a schematic block diagram illustrating functions of one embodiment of a network device (agent) marked 20, adapted to communicate with network managers 22, 24 and 26. To extract and transmit relevant traps to each of the managers from the network element, the agent 20 is provided with a hardware/software Trap Filtering Module (TFM) 28. In this embodiment, the TFM comprises a trap module 30 for forming ATM traps from ATM applications' events 14, an agent data base (ADB1) 32 for definition of a filter 34 for ATM traps. The ATM trap filter 34 is capable of sorting the ATM traps to send each of them to one or more managers it is intended for, but not to all managers in the network. The TFM 28 also comprises a second similar group of blocks responsible for handling event messages 16 received by the device 20 from Frame Relay (FR) applications. This group includes a FR trap block 36, its associated data base 38 and its associated FR trap filter 40. The event messages (14, 16) can be formed in the agent in form of internal messages written, say, in the "C" programming language. The traps are formed by ATM module 33 and FR module 35 respectively, which are software blocks cooperating with suitable applications. Trap blocks 30 and 36 convert these internal messages into the form of traps accepted for the particular applications ATM and FR. Trap filters 34 and 40 comprise sets of conditions for ATM traps and FR traps respectively, and are stored in respective data bases 32 and 38. As a result of comparing the obtained ATM and FR traps with conditions set in the respective trap filters 34 and 40, each manager 22, 24, 26 receives only traps predestined for it. Not only the managers do not need to deal with sorting the traps, but due to the fact that some of the traps are not sent to particular managers, traffic load between the agents' layer and the managers' layer is reduced.
Fig. 4 illustrates another embodiment 42 of the Trap Filtering Module in the agent 20. As above, the module 42 is capable of receiving
event messages 14, 16 from the ATM and FR applications modules supported by the device. In this case, a trap block 44 of the module is responsible for converting the event messages into trap structures 41, 43 formatted according to the respective applications, and thereupon - for unifying the trap format so as to compare the obtained traps in the unified format 45 with conditions stored in a common database 46 in the form of a Trap Filter 48. The conditions of the Trap Filter 48 correspond to the universal format 45. Actually, the block-diagram shows that the universally formatted traps are filtered by a common Trap Filter 48, which is responsible for sending the suitable traps to suitable managers 22, 24 and 26.
In the very format of the trap message, some digital fields thereof bear the message of the trap, and some fields mark which application generated it and to which particular entities of the system the trap relates. For example, the trap structure 41 comprises indication "ATM" of the application type in the first field, and one parameter schematically marked "a" in the second field of the format. The remaining two fields of the structure are free. The trap structure 43 includes the "FR" indication and two parameters marked "b" and "c", wherein the last field of the format remains free.
Alternatively, it is possible that the applications be required in advance to send the event messages to the TFM 42 in the form of trap structures 41 and 43.
The universal format 45, used for comparing different traps with the common filter stored in the database ADB 46, should still enable the TF 48 to recognize traps of different applications, and the trap data when filtering them. The following figures 5 and 6 shown how it can be organized.
Each trap filtered from TF 48 is sent to one or more suitable managers in the universal format. Owing to that, trap filtering functions at the managers' level may be simplified, if not at all abandoned. Simultaneously, the traffic load in the network is significantly reduced. In comparison with the arrangement having submanagers, the proposed structure is also simpler from the point of interacting network elements.
Fig. 5 illustrates examples of an ATM trap (50), a Frame Relay trap (52) and a transforming table (a so-called dictionary 54) for storing these differently originated traps in the database 48.
The illustrated exemplary ATM trap format 50 comprises indication of the application type and a number of port with respect to which an event is reported. The event may be briefly indicated in the last field (message) of the trap structure. All fields of the trap format comprise and form the trap data.
Say, the exemplary Frame Relay trap format 52 also comprises the application indication, as well as the port number and the channel number on which a particular event should be reported.
The dictionary 54 assigns numbers to the type indications (say, 10 for ATM, 20 for FR and 30 for Clock traps in this particular example), so that the numbers are used in the unified trap format to symbolize the applications. Also, the dictionary assigns fields of the unified trap format which are numbered as 1, 2, 3 to be always used for transmitting predetermined respective parameters in each type of the trap. Fig. 6 illustrates one example of a trap filter which can be utilized in the block-diagram shown in Fig. 4.
The filter comprises logical conditions which allow:
a) forwarding to a particular manager the traps with predetermined tasks, issued by predetermined applications and having some predetermined parameters, and/or b) preventing the traps with parameters which do not correspond to the predetermined ones from forwarding to the particular manager. In the figure, the filter is illustrated as a combination of logical functions performed by a trap filter program for transmitting to a particular manager only traps intended for it. The filter function is shown as a truth table comprising columns and rows. The rows are conditions being combinations of parameters and their function. In this particular example, each row begins with indication of a manager for which the condition is set. The input parameters being elements of the trap are shown according to the dictionary 54 in the assigned columns, and the output function (Yes or No, which means whether to send a trap corresponding to this particular condition) is indicated in the right-side column. The asterisk indicates any meaning of a particular parameter in a specific condition, and serves to point out that the parameter is unimportant for the function. Actually, fields of any unified trap format 45, captured by different parameters belonging to a particular application, can be read and analyzed with the aid of the filter table 56 (say, by pattern matching) using cross-sections of the filter created by its rows-conditions. For example, the algorithm of applying the filter can be described as follows ( in this example each trap is checked per manager):
- obtaining a unified trap,
- selecting all rows of the filter table, corresponding to a particular manager,
- searching among the selected rows for a row corresponding to the data in the unified trap format (remembering that * indicates any value);
- if such a row is found, and it comprises Yes as a function, sending the trap to the particular manager
- if such a row is found and it comprises No as a function, not sending the trap to the particular manager,
- if such a row is not found, performing a predetermined default action, - selecting all rows of the filter table, corresponding to the next manager and repeating the algorithm from the searching step, up to all the managers are checked. Filters for non-unified trap formats accepted for specific applications can be built in a similar manner. Such a specific filter will not comprise a variable parameter in the field indicating the application, or will not comprise such a field at all. Position and meaning of the columns will be specific for each particular application.
While the invention has been described with reference to specific examples, it should be appreciated that other implementations of the proposed principle can be found and are to be considered as part of the present invention.