Patent Application
20050076343
This invention relates to networks comprising a plurality of network components, and is particularly concerned with the network management of such a network.
Networks such as computer networks are no longer merely supporting elements in a company, but are increasingly occupying a key position. The number of networked computers has always been rising fast in the past, and has sometimes increased rapidly, and the complexity and functionality of the components is also expanding in accordance with performance increases in the basic hardware.
Networks are often and increasingly structured heterogeneously. For example, modern, complex multi-service communication networks consist of many different network components, between which different relationships exist. Network components might be—for example—network elements such as routers and switches, but might also be communication profiles for protocols such as IP (Internet Protocol) and ATM (Asynchronous Transfer Mode), and physical and logical communication connections.
An example of a heterogeneous network is shown in
The tasks of a network management system include—for example—maintaining services, availability, and response times, protecting the quality of service by monitoring the components, and carrying out preventive fault and bottleneck correction. Management systems are also required to respond automatically or semi-automatically to operating faults, whereby the configuration of the network is adjusted in real time in the event of a fault. Management systems might also be expected—for example—to activate redundant components in the event of a fault. Moreover, management systems must respond dynamically to changes in the network and network environment, for example with regard to applications, subscribers, components, services, and charges. It must, however, also be possible—for example—to make dynamic adjustments to transmission bandwidths.
Testing equipment is therefore also used as a network management tool, which can be used for testing the laid cables. Furthermore, network monitors are also used for monitoring and analyzing the data traffic on the network. More comprehensive network management facilities are provided by network management systems, which are based on defined network management standards such as SNMP (Simple Network Management Protocol).
Network management systems thus offer facilities for monitoring, administering and configuring networks from a central location, and thus also combine the functions of a network monitor and a network analysis tool. In terms of content, network management tasks can be divided into configuration management, fault management and performance management. Configuration management is used for displaying and manipulating different network components such as hub systems, bridges, and routers. Fault management is used for tracing, analysis and correction of faults, particularly in a heterogeneous environment. Thus, for example, protocol packets might be analyzed and the resulting data interpreted. Performance management supplies information about the efficiency of components and connections by continuous analysis of the network.
In order to fulfill these requirements, programs for management of networks must know the general topology and the statuses of the network. For example, network management might involve the task of analyzing and configuring an end-to-end connection. Such a connection is shown in
Since most networks are in place for longer than the average lifetime of a management program, the data that contains this information about network resources must be persistently stored outside the programs so that it can be read in again at a later date. Persistent storage in this context means the non-volatile filing of information in a memory that records the swapped-out data inside itself for a fairly long time. Persistent storage may essentially be carried out on the computer 110 on which the network management program is running. The data may, however, also be stored on a different network computer 120, 130, 140, in which case the network management program on the computer 110 must have resources available for accessing this persistently stored data.
Problems with conventional network management systems often arise as a result of the rapid and dynamic further development in network technologies, and the constant expansion in networks that results from this. These expansions may be either quantitative or qualitative, i.e. they may result not only from the addition of further network components and subscribers, but also from the addition of novel types of network component and/or from the modification from existing types to new types. Network expansion is illustrated in
since the network management station 110 can only monitor, administer, analyze and configure the network if it has access to all necessary information about the components contained in the network, the system must be able to retrieve the relevant information from the components or from elsewhere. Thus, if a new component of a previously unknown type N is added, the network management system cannot retrieve information about this component since the network management program does not yet have any means of querying the information relating to the novel type N. The network management program must therefore be expanded by the addition of a corresponding module that has been set up for communication with network components of type N.
A further problem results from the fact that each network component supplies or may supply data in a different data format. If a novel component is added to the network, the network management program must therefore file this data in a separate memory or supplement the existing memory by adding data fields in the new format. This means that no modifications in the persistent storage are required, which are costly and may even necessitate a reimplementation.
The above mentioned problems occur not only when a novel component is added, but also when a novel protocol is activated or when existing components or protocols are modified.
Thus, until now, the qualitative expansion of network technologies has usually necessitated considerable cost as the result of upgrading the existing network management solutions or from the costly synchronization of the entire management system and its persistent data. Qualitative expansion of the network normally requires the replacement of program versions, whereby such programs often have to be replaced even though they are not being expanded functionally, since they would no longer interoperate with the expanded objects without adjustment of the code. The program replacement thus necessary in the prior art therefore results in undesirable and cost-intensive interruptions to operation.
The object of the invention is therefore to propose a method for managing a network, and a network management system, that permits qualitative modifications to be registered, evaluated and implemented in the network without operation being interrupted.
This object is achieved by the invention described in the claims.
According to the invention, object references are used for persistent storage of network management data. These object references are normally used for defining the network management data generically. Since the management system stores references, it can also store references to such objects that were unknown at the time when the network management program was produced. In this way, any number of objects of different object types (classes), even those that are referenced to one another, can be swapped out entirely generically to a persistent memory and read back in from there, without any modification to the existing program code being required. Modifications to the data model can consequently be carried out completely transparently for existing programs, so that it is not necessary for the operation of active programs to be interrupted.
Preferred embodiments of the invention are specified in the subclaims.
The implementation of the invention by means of object-oriented programming permits the storage of references in an abstract, standardized data model. This is beneficial not only in order to obtain maximum operating security, but also because it permits existing programming mechanisms to be used easily.
To permit a more detailed description of exemplary embodiments of the invention, reference is made below to the diagrams in which:
a illustrates a heterogeneous network with a network management station and a network component of a novel type;
b illustrates the physical components of an end-to-end connection with several domains;
The invention will now be explained in greater detail with reference to the diagrams.
Although the exemplary embodiment in
The references filed in the reference database 240 refer to objects. An object is the program representation of a physical device in a network, for example an IP router or a telephone exchange. An object may also represent a defined component or a module from such a physical device, such as—for example—a network component or a connection socket. Moreover, an object may also represent a physical or logical connection line for the transmission of messages (e.g. a cable). An object may also represent abstract logical data such as domains and end points, as well as connections of resources or communication paths.
Objects are preferably implemented by an object-oriented programming language such as Java. In this case objects can be formed by one or more Java classes or by EJB (EnterpriseJavaBeans), or by a CORBA object and corresponding stub utility classes for communication. Another form of object implementation can be achieved by appropriately selecting the database scheme of the reference database 240 for persistent storage.
A reference is used for the unambiguous identification of an object, which is used by another object for a specific purpose and/or which is related to it in a specific way. Such a relationship may, for example, consist in that one object is contained within another object. A reference may refer to objects of different classes (object types), and contains all information for accessing the persistently stored data. This is achieved in that a reference contains the class name of the referenced object and a reference to the persistent storage location of objects of the referenced class, thus—for example—to the database table used in a relational database. A reference thus contains the key to accessing the persistently stored attributes of the referenced object.
Dynamic object references, which can be applied in systems with distributed objects, e.g. CORBA and EJB, are preferably used. It is necessary here to distinguish between the client (the user of a service) and the server (the supplier of the service). A single program may simultaneously act as client for one service and as the server for another service. A program may also be a method of an object.
The content of the references is analyzed interpretatively by the program at runtime. According to a preferred embodiment of the invention, references are generically constructed, whereby the network
In a preferred embodiment of the invention, references are always of the same data type at program runtime. References are preferably persistently stored in a database field as a string.
A preferred construction of a reference consists of the Java class name and an unambiguous identification code, which clearly differentiates between the various entities of the class, i.e. the objects. If—for example—the classes Network and GateNE are present, then the references might be Network—1, Network—2, GateNE_IPRouter—1, GateNE_IPRouter—2, etc.
The reference thus contains all information necessary for reconstructing the object. An object is then only ever reconstructed from a reference if one or more methods of an object are to be called. Methods are executable program routines that are part of the corresponding object. The code that calls the methods on the referenced object, i.e. the program running on the client, uses the new class in the server, which is still unknown at programming time. It interprets the reference attribute of the type string by applying a naming convention at program runtime and uses the appropriate programming language resource to load the new classes and then to address methods of the objects on the server.
The class is now loaded. (stage 330), likewise at runtime. In the Java programming language, for example, this is facilitated by the so-called Reflection API and the integrated ClassLoader. In stage 340, then, the referenced object is generated at runtime as an entity of the defined and loaded class. Finally, in stage 350 one or more methods of the generated entities are called at runtime.
An example is now explained in greater detail with reference to
The two classes IPRouter and LanSwitch implement the methods getNextHop( ) and getDescription( ) respectively getNexHop( ) delivers one or more references to the objects that are logically connected to the current object. getDescription( ) delivers a description of the current object.
In the process shown in
In stage 420, in the alternative procedure mentioned, the reference string for the selected starting object is read out from the reference database 240. The name of the factory object (J2EE=Home Interface) is then defined from the reference string by application of the naming convention. Thus, with reference to the above examples, the name IPRouterHome of the factory object is defined as the string from IPRouter—2. In a different example, the factory name LanSwitchHome is obtained from LanSwitch—1111. If the class of the defined factory object is unknown, the program is terminated and/or a new reference is queried.
After the name of the factory object has been defined in this way in stage 430, the factory object is produced using the Reflection API.
Then, in stage 450, a CORBA reference to the object is produced by calling the method findByPrimaryKey( ).
If the CORBA object being searched for does not yet exist in the server, it is loaded into the server from the database.
Now, in stage 460, a request is transmitted from the client to the service. For this purpose only a stub is addressed in the client (via rObjectRemote). In the server the call is diverted to the concrete implementation of the class. The server knows the persistent storage location of the data describing the network and has the necessary resources to produce the server object from the contents of the database.
The server object produced may now be used, in stage 470, to retrieve the required methods.
With the result of getNextHop( ), which normally delivers a number of references, the client can find all objects that describe the network by repeated application of stages 420 to 470. For this purpose, the process provides a branch 480 which arranges for the aforementioned stages to be repeated if no other references are available.
The preferred exemplary embodiment described above thus provides a possibility for managing a network by persistent storage of dynamic object references. Since, in this instance, the methods getDescription( ) and getNextHop( ) can be localized only by means of the respective filed object references (and the respective method names), persistent storage of class-related data is not necessary. The application of dynamic object references thus enables the implementation of a server to be replaced or removed for a service, or further servers to be added, without the need for any modification, reprogramming, retranslation, upgrading, or restarting of the active client programs.
Instead, only measures outside of the network management program are required if—for example—a new class of objects that require a completely new type of NextHop( ) implementation, is imported into the system during the program runtime. If, for example, objects in a class ATMSwitch, which does not yet exist in the network, are added to said network, the implementation of the class ATMSwitch and its stub classes must be imported at the server computer and loaded into the server, for example by means of deployment in Java EJB. Entities of the class ATMSwitch must then be produced in the server and references to the produced objects must be added in several of the existing objects.
Only stub classes of ATMSwitch need to be imported into the class loader path on the client computer. However, no modification of the network management program or data format of the persistent storage is necessary. The network management program may therefore use the new objects without operation being interrupted.
| Number | Date | Country | Kind |
|---|---|---|---|
| 101 63 533.8 | Dec 2001 | DE | national |
This application is the US National Stage of International Application No. PCT/DE02/04618 filed Dec. 17, 2002 and claims the benefit thereof. The International Application claims the benefit of German application No. 10163533.8 filed Dec. 21, 2001, both of the applications are incorporated by reference herein in their entirety.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/DE02/04618 | 12/17/2002 | WO |
