JP3169156B2 - Network data storage method - Google Patents

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to the interconnection of a plurality of communication networks and various communication network components (NE: Network).
rk Element) and a communication network operation system (Operation System: OpS), TMN (Telecommunica).
M, which is a basic technology for constructing a communication network OpS based on the TMP (Temperature Management Network).
The present invention relates to a method of storing identification names (data) of network resources in an IB (database) configuration method.

[0002]

2. Description of the Related Art In recent years, it has become possible to connect various communication network components (NE) and operation systems (OpS) with a focus on ITU-T and the like, and furthermore, to establish an advanced network by interconnecting a plurality of communication networks. Telecommunications Manag to enable operation
element Network (TMN) (CCITTR
ec. M. 3010, Principles for
a Telecommunications Manag
Research and development of an operation system based on element network (TMN), 1992) have been actively conducted. Research and development has already been conducted on the TNMS kernel, which is an OpS platform based on TMN (Yoda, et al., "Proposal of TMNS Kernel", IEICE, IEICE, CS93-79, 199).
3) Managed Information Ba, which is a database that manages storage management of managed objects (MOs)
se (MIB) is an important technology for realizing network management conforming to TMN.

[0003] MOs are various and large in volume, and therefore it is possible to efficiently store and manage these MOs.
B is the required condition. Conventionally, a commercially available relational database (RDB: Relational Databases) has been used.
e) Object-oriented database (OODB: Ob)
There has been proposed a method of configuring an MIB using a “Joint Oriented Database”. TM
According to the basic concept of network management of N, management operations are performed from a network operation system (entity to be managed) through a standard interface (Q interface), and network management is realized by a response or notification from a managed object. Is done. Since the MIB is required on the managed side (agent), real-time or near real-time throughput is required for network management. Since conventional general-purpose DBMSs are literally designed with emphasis on versatility, it has always been difficult to provide optimal transaction processing performance for network management applications. In addition, when the MIB is applied to limited hardware such as an NE agent or software, there is a problem in whether or not a general-purpose DBMS is supported and processing performance when a general-purpose DBMS is used. Therefore, in order to be compatible with OpS management based on TMN and to provide high portability independent of differences in OS and hardware, the MIB is stored in the main memory of the computer.
Resident databases (MRDB, Ma
in memory Resident Dataaba
se) has been developed (Shimizu, et al., Management Information Base (M
Regarding the deployment method of IB), IEICE, IEICE Technical Report, CS94-21, 1994). Although the MRDB has been developed from such a background, there are the following problems in the current technology. From such a point, the MO and its attribute values are developed on the main memory as the MIB configuration method, and the inclusive relation of the MO expressed by the simple internal identification information is held on the main memory, and the backup of these and the MO is performed. It is conceivable to associate MIB information (MO and its attribute value) on the secondary storage medium, which is the main purpose, with the association. However, the MIB information stored in the secondary storage medium is classified by encoding that does not depend on the machine architecture, such as AS
N. For example, the identification name of the MO is an absolute identification name (DN: Distinguished Na).
me), which is the MO containment tree (MIT,
Managed Information Tree)
Since the identification names of the MOs from the root above to the MOs are listed, the MOs are redundant.
Message Length Redundancy and MIB When Accessing B
It also causes an increase in the amount of information. In other words, the network resources to be the MO are the devices that make up the communication network and the components under the devices (for example, IF boards and terminal points).
In OpS based on MN, the inclusion relation of MO is defined as inclusion tree. For example, as shown in FIG. 4A, the root-JP (Japan) -NTT-TN (Tr
A plurality of NEs (Network Elements) are associated with the response network, a plurality of NEs are associated with each NE, and each BAY is associated with each NE.
Are associated with a plurality of BOARDs. The one MO, for example, the absolute identification name DN of BAY2 is
The names of the MOs from ot to the BAY2 are enumerated JP / NTT / TN / NE1 / BAY2. As the attribute value of the MO, in addition to the unique name (name) for the MO, the manufacturer of the device, the date of manufacture, and the like are given.

[0004] This is because the identification value of another MO may correspond to the attribute value of a certain MO.
The information amount of O increases, and as a result, the information amount of MIB also increases. This may cause a decrease in the throughput of the entire system. In addition, the MIB is based on TMN-based O
It is also installed in an agent system such as NE in pS management. The network resources managed by the agent system (NE) correspond to, for example, an interface (IF) board such as a cross-connect device and a termination point. At this time, if DN is always applied to the identification name of the MO registered in the MIB, the information amount of the MIB increases, and the initial installation work of the MIB can be expected to be complicated. The reason why the initial installation work is complicated is as follows. Consider a case where MIB is installed in an agent system. This is based on the premise that I
Since there are many MOs corresponding to panels such as F boards,
MO is generated in advance, and the OpS
To change the state of the MO. Therefore, the operation of generating the MO in the initial state is required in the agent system before starting the operation. According to the MIT assignment rule, the identification name of the MO is, for example, the N
In the IF board accommodated in E, the MO corresponding to the IF board
There is an attribute value (identification name) indicating another MO in the attribute value of. Different attribute values are assigned to different NEs. This means that even if the NEs of the same type are different in the device name during installation, the MO accommodated in the device
Are different from each other, different attribute values must be given to the MO in the agent system for each device, and the operation becomes complicated.

[0005]

As described above, in the conventional MIB configuration method, the information amount of the MIB increases and the total throughput decreases.
There is a problem that the initial installation work of the IB becomes complicated, and there has been little technical study on the MIB configured by the conventional MRDB method to solve such a problem.

[0006]

In an operating system, an absolute identification name is usually applied to a message exchanged between a manager and an agent as an identification name of an MO. In the storage method, M on the secondary storage medium is used.
When the MO and its attribute values are stored in the IB, or when the MIB on the secondary storage medium is updated, a unique and local identification name (LD
N) is applied, the absolute identification name DN is converted into the local identification name LDN in the agent system, and the MIB information of the secondary storage medium is stored and updated. Also, when the MIB on the secondary storage medium is expanded to the MIB information on the main storage (MIB information in the agent process), the LDN to D
Convert to N

[0007]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS An embodiment of a method for storing network data, which is a feature of the present invention, which is characterized by a method for converting between DN and LDN, and a method for simply initial installation of an MIB in an agent system will be described in detail below. FIG. 1 shows the relationship between an application program (AP) 11 in a certain agent system (for example, NE1 in FIG. 4A) and the MIB. In the AP 11, a plurality of managed MOAs, M
OB,... Are stored, the attribute 1 of the MOA is an identifier, an absolute identification name DN, and the attribute 2 is a manufacturer name.

The other MOBs, MOCs,... Are also given their attribute values. AP1 in charge of operations
1, when the generation, update, deletion, and information acquisition of the MO managed by the agent system occur, the
B Control unit MIB by message specified by API
Notify the API 12. According to the present invention, an AOI (Agent Object I) in which MIB information, usually an MO and its attribute values are developed on a storage space 14 of the main memory 13 and the inclusion relation of each MO is described by internal identification information.
D) The table is expanded in the table 15 for each hierarchy. The AOI table 15 includes three columns of an AOI value, a parent AOI value, and a rank. The AOI value is a unique integer value for identifying the MO within the system, the parent AOI.
The value indicates the parent-child relationship (containment relationship) on the MIT (containment tree) of a certain MO, and the upper M
An integer value for internally identifying O, and a rank is an integer value indicating the number of a layer from a local root (corresponding to TN in FIG. 4A) in the MIT world. The first and second AOI tables 15 ₁ and 15 ₂ are shown in FIG.
And, for example, looking at TP2, A
As shown in the second line of the OI table 15 _2, MOI is 2
[0020] The parent MOI is 10011 indicating NE1, and the rank is 2.

In order to back up the loss of data in the main memory 13 due to power interruption or other causes, the MO in the storage space 14 and its attribute values are stored in the secondary storage medium 16 such as a magnetic disk in the machine architecture. Coding rules that do not depend on, for example, ASN. 1 encoding rule, and the encoded information is represented by ASN. 1 and the same as the AOI table 15 are stored as the AOI table 18.

If the message from the AP 11 is, for example, a new generation of an MO, the MIB API 12 adds the message to the storage space 14 on the main memory 13 and the AOI (Agent Object).
ect ID) table 15 and update the ASN. The MO and its attribute value are registered in the first table 17 and the ADI table 18 is updated.

At this time, according to the present invention, the ASN. The identification information, which is one of the attribute values for each AOI in one table 17, is represented by LDN, which is simplified information compared to the case of DN. For example, a cross-connect device (X
C) Line interface (Line Inte)
rface) and a board (Board) are defined as MO, the board refers to a physical IF board, and a line interface is a logical IF board defined to absorb a difference by a manufacturer of the physical IF board. Pointing to. Therefore, the Line Interface and the corresponding Board hold the identification information of each other in their attribute values. If the containing tree in which this agent system is contained is, for example, a relationship as shown in FIG. 4B, that is, Bo is lower than Bay1 which is lower than XC1.
ard1 is located, Line Interface1 is located below XC1, and an IF board for difference absorption by the manufacturer of Board1 is Line Inter.
face1. At this time, as shown in FIG.
LineInterfac in MO group held in P11
The attribute value for e1 is the identifier of attribute 1 as DN, ie, / JP / NTT / TX / XC1 / Line
/ JP / NTT / TN / XC1 in DN format with the other party's board name as attribute 2 in addition to having Interface 1
/ Bay1 / Board1 and similarly Board1
For the attribute 1, the name of its own is DN, and as the attribute 2, the name of Line Interface 1 is DN.
Hold with.

In the main memory 13 as well, the names (identification information) of the MOs required for the respective attribute values of the MOs are in the form of DNs, but as described above, the identification names of the MOs are stored on the secondary storage medium 16. Is the identification information LDN in the agent system, in this example, the cross-connect device XC1.
Only, but the DN of Board1 is / JP / NTT
/ TN / XC1 / Bay1 / Board1, whereas LDN only needs to be uniquely identified in the agent system, so it is Bay1 / Board1, and DN of Line Interface1 is / JP /
NTT / TN / XC1 / Line Interface
Whereas LDN is simply LineInterf
ace1 only. That is, the relationship between LDN and DN is L
If the identification name of the MO that goes back from the XC on the MIT (containment tree) in the direction of the root is added to the head of the DN, the DN becomes the DN. Line Interf on the secondary storage medium 16
As shown in FIG. 3, the attribute value of ace1 is Line 1
Interface 1 and attribute 2 are Bay1 / Boar
d1 and attribute 1 of Board1 is Bay1
/ Board1, attribute 2 is Line Interface
e1. Thus, the identification information of the MO in the attribute value is very simple. When storing and updating in the MIB on the secondary storage medium 16 from the main storage 13, its absolute identification name DN
The LDN is extracted from the identification information lower than XC1 in, and is used as the identification name. Conversely, when developing the MO information on the main storage 13 from the MO information on the secondary storage medium 16, the LDN
Contains XC1 along the MIT and is higher than XC1.
The DN is obtained by giving the identifier of O to the head of the LDN.

As described above, since the number of MOs accommodated in the agent system is generally large, it is assumed that the MOs in the initial state are installed in advance. In the conventional method, the attribute value of an MO accommodated in the device may correspond to the identification information of another MO for another device even if the devices are of the same type. Since the installation must be performed for each device, a different installation file must be created for each agent system or, for example, the cross-connect device XC1
And XC2 are the same type, but conventionally, as shown in FIG. 3A, an installation file 21 in the cross-connect device XC1 is created, and MIB information is installed in the cross-connect device XC1 from this, and An installation file 22 was created and installed on the cross-connect device XC2. Alternatively, it is necessary to perform installation once on the cross-connect device XC1, add or modify the installation file 21, and then install the file on the cross-connect device XC2.

On the other hand, according to the method of the present invention, if the same type of device is used, an MIB in the same initial state is created, and the same file is installed in another device of the same type, and the operation is completed. Therefore, initial installation work can be greatly reduced. That is, as shown in FIG. 3B, with respect to the cross-connect devices XC1 and XC2, M
Since the local identification name LDN for O is the same, a file 23 of MIB information to be stored in the secondary storage medium 16 in FIG.
1 and XC2 may be initially installed.

[0015]

As described above, according to the network data storage method of the present invention, the DN on the MIT is set to M
Compared to the method of setting the O identification name, the MO identification name
Since the LDN was performed on T, the database capacity can be reduced, and N
In the case of NEs of the same type, it is not necessary to create MIB information to be installed in E for each device, and the efficiency of initial setting work can be improved.

[Brief description of the drawings]

FIG. 1 is a diagram showing the principle of a network data storage method according to the present invention.

FIG. 2 is a diagram showing a specific example of a network data storage method according to the present invention.

FIG. 3 shows the concept of initial installation in an agent system (NE), wherein A is a diagram according to a conventional method and B is a diagram according to the method of the present invention.

4A is a diagram illustrating an example of a containment tree of an MO in the network operation system, and FIG. 4B is a diagram illustrating an example of a containment tree (MIT) in the specific example of FIG. 2;

────────────────────────────────────────────────── ─── Continuation of the front page (56) References JP-A-4-21147 (JP, A) JP-A-63-286941 (JP, A) JP-A-4-267443 (JP, A) JP-A-5-267 189389 (JP, A) Tomoaki Shimizu, et al., “Deployment of Management Information Base (MIB) in ATM Transport Network Management”, IEICE Technical Report, IEICE, May 1994 , Vol. 94 No. 68, CS94-21 (OCS94-11), p. 73-80 (58) Fields investigated (Int.Cl. ⁷ , DB name) G06F 12/00 G06F 13/00 G06F 17/30 H04L 12/00 H04M 3/00

Claims (1)

(57) [Claims] 1. TMN (Telecommunicat)
Network Operation System (OpS: Oper) Based on Ion Management Network
(Managed Info) that manages network resources used for the communication system
In the method of storing network data of the “Ration Base”, the management target (MO: Managed) managed by the OpS is used.
The identification name of the “Object” in the main memory is an absolute identification name (DN: Distinguished Name).
On the secondary storage medium, the local identification name (LDN: Local Distin) included in the absolute identification name
characterized in that the absolute identification name and the local identification name are associated with each other in the MI of the network operation system.
Network data storage method in B configuration method.