CA2277462A1 - Method for the consistent execution of instructions, and controller for a network element - Google Patents

Abstract

Network elements (NE) for telecommunications networks are controlled using managed objects (MO1-MO3) which are accessed when instructions from an external management system are received. Different accesses must frequently be executed consistently.

A method for the consistent execution of instructions is disclosed wherein the instructions are combined into a transaction (TR_A), and wherein the execution of the instructions does not take effect until it has been committed, and is undone if not committed. Managed objects (MO1) which are accessed within the transaction (TR_A) are incorporated into the transaction. All managed objects (MO1-MO3) have a distinguished name which, when an object is accessed (ACC), is combined with a physical address (ADR). The combination causes the generation of a message (NOT) in response to which a managed object (MO1) being accessed is incorporated into the transaction (TR_A).

Description

Method for the Consistent Execution of Instructions, and Controller for a Network Element This invention relates to a method for the consistent execution of instructions to a controller of a network element as set forth in the preamble of claim 1, and to a controller for a network element of a telecommunications network as set forth in the preamble of claim 6.
For the control of network elements, the resources of the network elements are represented by managed objects. Managed objects are real life images - and thus descriptions of static and dynamic properties - of physical or virtual components (resources) of the managed network element. In CCITT Recommendation X.720 (01/92), a managed object is defined as an abstraction of data processing and data communications resources (e.g., protocol state machines, connections, and modems) for the purposes of management.
Network elements are facilities of a communications network which serve, for example, to establish connections within the network, provide access to the network, switch connections in the network, or change the format of messages which are transmitted in the network. In a communications network based on the . CA 02277462 1999-07-07 synchronous digital hierarchy (SDH) or in a synchronous optical network (SONET), network elements include crossconnects, add/drop multiplexers, and line multiplexers.
Such network elements contain a controller for controlling and monitoring network-element-specific functions. From an article by S. Colombo et al, "Technologie der SDH-Netzelements: die Software-Plattform", Elektrisches Nachrichtenwesen, 4th Quarter 1993, pp. 322-328, it is known that network elements operate and are controlled in accordance with an object-oriented specification. The controller of the network element contains a processor, a memory, and a nonvolatile ("persistent") storage. The memory contains the managed objects. The managed objects are saved in the nonvolatile storage.
By means of the processor, instructions from an external management system are executed, such as an instruction to set up a connection as is described in M. Bosse et al, "Management von SDH-Netzelementen: eine Anwendung der Informationsmodellierung", Elektrisches Nachrichtenwesen, 4th Quarter 1993. During the execution of such an instruction, the managed objects in the memory are accessed and changes made to the managed objects are transferred into the persistent storage. During the control of network elements it is frequently required that a number of instructions be executed consistently, i.e., that either all instructions or none be successfully completed. This necessitates treating any possibly occurring consistent execution as a special case in the control program of the controller, i.e., providing for this special case in the source code of the control program. This is complicated for the programmer and prone to error, and results in a long and slow control program.
From an article by K. Rothermel et al, "ARIES/NT: A
Recovery Method Based on Write-Ahead Logging for Nested Transactions", Proceedings of the Fifteenth Internation Conference on Very Large Data Bases, Amsterdam 1989, it is known to combine a number of accesses to a distributed database system into a transaction in order to ensure that either all accesses are successfully completed or, if one of the accesses fails, all others will be undone. In that model, a transaction may contain any number of subtransactions.
The database system consists of a set of sites, which are interconnected via a communications network. In each site, there exists a special subsystem called the "bookkeeper", which coordinates the initiation, migration, and termination of transactions. The transaction concept described is limited to the consistence within the database. In addition, the concept requires that the bookkeeper is aware of all accesses, and thus of all objects to be accessed, in advance.
It is an object of the invention to provide a method for the consistent execution of instructions to a controller of a network element as well as a controller for carrying out the method.
This object is attained with respect to the method by the features of claim 1 and with respect to the controller by the features of claim 6. Further advantageous features of the invention are defined in the dependent claims.

According to the invention, objects which are accessed are incorporated transparently into a transaction. This has the advantage that sources of error that would result in an inconsistent execution of the instructions are eliminated.
Another advantage of the invention is that normal transactions, which consist of a number of individual steps, and nested transactions, which contain subtransactions in addition to individual steps, can be treated equally. A further advantage is that it is not necessary for each object which is accessed within a transaction to be known in advance. This simplifies the software development for the controller, since normal and nested transactions can be treated with the same control program.
One embodiment of the invention will now be explained with reference to the accompanying drawings, in which:
Fig. 1 shows schematically the sequence of steps of the method according to the invention;
Fig. 2 shows a network element according to the invention; and Fig. 3 is a flowchart showing the steps of the method according to the invention.
The network element of the embodiment shown is controlled by a controller using so-called managed objects. Managed objects are images of physical or virtual components of the network element which describe the static and dynamic properties of the respective component. A managed object is an instance of a managed object class. Such a managed object class is defined by its attributes, the operations executable by its objects, the notifications which can be emitted by its objects, and its related behavior. Each managed object has a distinguished, unambiguous name. From a management point of view, a managed object exists if it has a distinguished name and supports the operations and notifications defined for its class.
The entirety of the managed objects existing in a network element, together with their attributes, is referred to as a Management Information Base (MIB) and reflects the current configuration of the network element. The managed objects are stored in a memory (generally a RAM) and are saved in a database which is contained in a nonvolatile storage (e. g., a hard disk) of the network element. This database is also referred to as a persistent database.
The network element of the embodiment shown is a digital crossconnect. It receives instructions from a higher-level management system, for example an instruction to set up a new connection. During the.
execution of such instructions, existing managed objects are accessed or new managed objects are generated. An instruction may involve a number of accesses to managed objects. It is frequently required that several such accesses be executed consistently, i.e., either all accesses be successful or none of the accesses must take effect. Therefore, a "commit" is generated after successful execution. Only after the execution has been committed will changes made to the managed objects as a result of the accesses take effect. Actions necessary within the scope of the instruction, such as transmitting messages, generating alarms, or updating the hardware configuration, are not performed until after the execution of the accesses has been committed. If the execution is not committed or an error message occurs, the actions will not be executed and changes already made will be undone.
A basic idea of the invention is to combine accesses to be executed consistently into a transaction and to incorporate all managed objects which are accessed within the transaction into the transaction. Use is made of the fact that each of the managed objects is known by a distinguished, unambiguous name. Access to a managed object is obtained by specifying this name.
When a managed object is accessed, the distinguished name is combined with a physical memory address at which the managed object is physically located in the memory. When such a combination takes place, a message is automatically generated which indicates that the respective object will be accessed. In response to this message, the object is incorporated into the transaction. Thus, according to the invention, cooperation between the object management and the transaction controller takes place.
The interaction of the various control sequences in the method according to the invention is shown schematically in Fig. 1. A transaction controller T MAN, for example a control process referred to as a transaction manager, generates and monitors a transaction.TR A. The transaction TR A consists of a number of instructions which each require accesses to managed objects. Managed objects M01-M03 are stored in a memory MEM. The managed objects M01-M03 are known to an object management 0_MAN, e.g., to a control process referred to as an object manager. Within the transaction TR A, the managed object M01 is to be accessed. However, the transaction TR A only knows the distinguished name of the object M01. Therefore, a query Q ADR is sent to the object management O MAN to request the physical memory address ADR of the object MO1. The object management O MAN then establishes the linkage between the distinguished name of the object M01 and the object's physical address ADR in the memory MEM and communicates this address to the transaction TR A. The transaction TR A then accesses, ACC, the managed object MO1. In response to the query Q ADR, the object management sends to the transaction TR_A a message NOT with the information that the managed object M01 is to be accessed by the transaction TR_A.
In response to this message, the transaction controller T MAN incorporates the managed object M01 into the transaction TR A.
The transaction controller T MAN and the object management O MAN are control processes which can be implemented as software modules. Software modules are program parts or subprograms consisting of control instructions which are coded in a machine language and can be executed by a processor.
Thus, according to the invention, all managed objects which are accessed in a transaction are incorporated into the transaction. This ensures that a transaction cannot be completed until all accesses to managed objects were successfully completed. The status of the transaction is forwarded transparently to the objects being accessed. In this manner, other transactions can be incorporated as subtransactions. Thus, nested transactions are supported without exception handling, because all essential status information is communicated during access to an object. The status information indicates, for example, that the respective object is only part of the transaction, that the transaction is consistent or is to be performed only in the "best-effort mode", of what type the access to the object is (read/write or only read), that a commit is to be waited for, and what type of feedback is expected from the managed object.
"Best-effort mode" as used herein means that individual steps do not have to be performed consistently, i.e., that individual accesses may be successful while others are not currently executable and thus fail. Thus, two different modes which have to be determined beforehand are possible for the execution of instructions: the consistent execution, also referred to as the "atomic mode", in which a transaction is opened, and the not necessarily consistent execution, also referred to as the "best-effort mode". In the "best-effort mode", all steps to be performed are performed and completed separately and in succession. This may include two or more transactions which are started and completed independently of each other. If two or more such independent transactions become subtransactions of a new, superordinate transaction, they will be automatically performed in the "atomic mode". This is made possible by the transparent forwarding of the transaction status.
The transparent forwarding of the transaction status also ensures that in the case of nested transactions, subtransactions (inner transactions) are not committed until the outer transaction was committed. It is always known whether a current transaction is a subtransaction of an outer transaction or not. In the embodiment shown, the forwarding of the status information is effected by the transaction controller or initiated by the message from the object management.
If a current transaction is not committed because access contention or another error, for example, has occurred in the execution of a step of the transaction, all changes already made within the transaction must be undone. This is accomplished by reloading changed objects from the nonvolatile storage in which they are saved, in order to restore the original state.
Advantageously, the nonvolatile storage in which the managed objects are saved is structured as a database.
Changes made to managed objects within the transaction are immediately written into the database, but at a free location, so that the original database entry of the respective object is preserved until the change is committed. The original entry is then freed for overwriting. If the commit fails to appear, the original entry remains in effect and the new entry is freed for overwriting. Changed objects are then loaded from their original entries in the database back into the memory.
A controller according to the invention, CTR, for the network element of the embodiment is shown in Fig. 2.
The network element NE is a digital crossconnect of a synchronous digital communications system based on the recommendations for SDH (synchronous digital hierarchy) or SONET (synchronous optical network). In such a communications network, the traffic is transferred in synchronous transport modules. The crossconnect has a switching matrix MX, with which connections are switched, both in the space domain and in the time domain, between inlets IN and outlets OUT. In addition, the crossconnect arranges subunits of the transport modules, so-called virtual containers, between the transport modules. In this manner, virtual connections can be established in the communications network by means of such a crossconnect. At the inlets IN and outlets OUT, STM-4 signals (STM = synchronous transport module) are processed. There exists one managed object for each termination point of the switching matrix. In 10 addition, managed objects exist for all established virtual connections.
Physically, the crossconnect is composed of a plurality of printed circuit boards, each of which is controlled by its own on-board controller. For each board, too, there is a managed object, which describes the functions and configurations of the board.
The network element NE contains a controller CTR which controls and monitors the functions of the network element, detects failures, generates corresponding error messages, and receives and processes instructions from a higher-level management system of the communications network. The controller comprises a processor CPU for controlling the network element, a memory MEM containing the managed objects, and a nonvolatile storage DB. The nonvolatile storage is a hard disk, but it is also possible to use other data carriers or nonvolatile storage types. The controller further includes another memory BIOS, for example an EEPROM or a second hard disk, in which an operating system is stored. In the embodiment shown, the operating system is a UNIX system. The software modules for transaction control and object management build on the operating system. They are part of an application which is referred to as a "framework" and forms the basic structure for the control software of the controller. Processor CPU, memory MEM, nonvolatile storage DB, and memory BIOS are interconnected by data lines, for example by a bus. Physically, the memory BIOS may also be combined with the nonvolatile storage in a single storage medium (e. g., a hard disk).
The method shown in Fig. 3 in the form of a flowchart comprises the following successive steps:

Step S1: A transaction is opened by combining one or more instructions into the transaction.

Step S2: The instructions are processed step by step.

Step S3: A managed object designated X is to be accessed.

Step S4: The distinguished name of the object X is combined with a physical address.

Step S5: When this combination takes place, a message is generated with the information that access to the managed object X is taking place.

Step P1: A check is made to see whether access contention occurs for the managed object X, for example whether other, concurrent instructions or transactions are requesting access to the managed object X. If that is the case, the transaction will be aborted with an error message ERR. Instructions of the transaction which have already been executed will be undone.

One reason for the occurrence of access contention may be, for example, that the managed object is already incorporated in an "older" transaction. Since an object must not be incorporated in two transactions at the same time, access contention occurs. The transaction which attempts to incorporate an object for a second time will be aborted, while the processing of the "older"

transaction continues.

Step S6: If no access contention occurs, the managed object X will be incorporated into the transaction. As a result, the transaction cannot be completed until access to the managed object X has been completed.

Step P2: After completion of the access, a check is made to see whether the instruction was successfully executed. If that is not the case, the transaction will be aborted with an error message ERR. Already executed instructions of the transaction will be undone.

Step P3: A check is made to see whether all instructions of the transaction were processed. If that is not the case, a branch is made back to step S2 for the execution of the next instruction.

Step S7: When all instructions involved in the transaction have been successfully completed, the execution of the transaction is committed. Changes become permanent and actions such as the transmission of messages are executed only after such committing.

Claims (7)

Claims

1. A method for the consistent execution of a number of instructions to a controller (CTR) of a network element (NE), comprising accessing managed objects (MO1-MO3), combining the instructions into a transaction (TR_A), and causing the execution of the instructions to take effect only after being committed, while being undone if not committed, characterized in that the managed objects (MO1-MO3) have a distinguished name which, when the object is accessed, is combined with a physical address (ADR), and that when such a combination takes place, a message (NOT) is generated in response to which a managed object (MO1) which is accessed within the transaction (TR_A) is incorporated into the transaction.

2. A method as claimed in claim 1 wherein the execution of the transaction (TR_A) is monitored by a transaction controller (T_MAN), wherein the transaction controller incorporates all managed objects (MO1) which are accessed during the execution into the transaction (TR_A), and wherein an object management (O_MAN) which associates the distinguished names of the managed objects with the physical memory addresses (ADR) sends a message (NOT) to the transaction controller (T_MAN) when an object (MO1) is accessed.

3. A method as claimed in claim 1 wherein a check is made to determine whether contention occurs before a managed object is incorporated into the transaction (TR_A), and wherein a managed object for which access contention occurs is not incorporated into the transaction, in which case the transaction is aborted with an error message (ERR).

4. A method as claimed in claim 1 wherein the object (MO1) being accessed (ACC) is notified of the transaction status.

5. A method as claimed in claim 1 wherein the managed objects (MO1-MO3) are saved in a database (DB) of the controller (CTR), and wherein changes made to managed objects are transferred into the database after being committed.

6. A controller (CTR) for a network element (NE) of a telecommunications network, comprising a processor (CPU), a memory (MEM) containing managed objects (MO1-MO3), and a nonvolatile storage (DB) in which the managed objects are saved, characterized by - a transaction controller (T_MAN) which, for the consistent execution of a number of instructions, combines the instruction into a transaction (TR_A) and, in response to a message, incorporates a current managed object (MON1), which is accessed within the transaction, into the transaction (TR_A), and an object management which, when a managed object (MO1) is accessed (ACC), combines the distinguished name of the object with a physical address (ADR) and, when such a combination takes place, generates the message (NOT) and sends it to the transaction controller (T_MAN).

7. A controller as claimed in claim 6 wherein the nonvolatile storage is structured as a database.