Note : Les descriptions sont présentées dans la langue officielle dans laquelle elles ont été soumises.
CA 02277462 1999-07-07
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
2
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
CA 02277462 1999-07-07
3
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.
CA 02277462 1999-07-07
4
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
CA 02277462 1999-07-07
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
CA 02277462 1999-07-07
6
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
CA 02277462 1999-07-07
7
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
CA 02277462 1999-07-07
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
CA 02277462 1999-07-07
9
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
CA 02277462 1999-07-07
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
CA 02277462 1999-07-07
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
CA 02277462 1999-07-07
12
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.
