Protocol conversion device, method and program

Abstract

To implement acquisition of state information and input of setting information from a network setting monitoring device which is not compliant to SNMP to a network apparatus which is compliant only to SNMP.SOLUTION: A conversion device 1 mutually converts information models of communication protocols which are not compatible with each other. Interfaces 101 and 102 are compliant to RESTCONF / YANG or NETCONF / YANG. An interface 103 is compliant only to SNMP. A conversion table for mutually converting an information model compliant to RESTCONF / YANG or NETCONF / YANG and an information model compliant to SNMP is registered in a conversion table section 109. When a monitor information acquisition request of a YANG model is acquired from a network setting monitoring device, the conversion device 1 refers to the conversion table and converts it into the monitor information acquisition request of an MIB model. When an apparatus setting input request of the YANG model is acquired, it is converted into an apparatus setting input request of the MIB model.SELECTED DRAWING: Figure 2

Description

[Technical field]

[0001] The present invention relates to a protocol conversion device, method, and program, and in particular to a protocol conversion device, method, and program for converting configuration and monitoring information acquisition request data input from a NETCONF / RESTCONF protocol interface to the SNMP protocol in an operation system such as a network configuration monitoring device that is compatible only with NETCONF / RESTCONF in order to handle network devices that are compatible only with SNMP. [Background technology]

[0002] Network-based ICT (Information and Communication Technology) systems have become indispensable in people's lives and businesses, and the demand for communications is increasing. To meet this strong demand for ICT systems, telecommunications carriers are using operational systems to automate network configuration and monitoring.

[0003] Because the setting information for network (NW) devices and the status information that can be obtained from NW devices differ depending on the equipment manufacturer and model, in order to analyze abnormalities in NW settings and NW devices, it was necessary to implement analysis programs and policies for each model in the setting and monitoring device.

[0004] Patent Document 1 discloses a technology for standardizing status information of network devices that differ for each device manufacturer and each device by defining a common network status model on a system and linking one or more status items for each monitoring location in a network status model that differs for each network device to the common network status model.

[0005] Non-Patent Document 1 discloses a standardization technology for configuration management protocols for network devices. Non-Patent Document 2 discloses an operation automation technology for a multi-vendor, multi-device environment that utilizes the standardization technology disclosed in Non-Patent Document 1. [Prior art documents] [Patent documents]

[0006] [Patent Document 1] Patent No. 6927930 [Non-patent literature]

[0007] [Non-Patent Document 1] IETF RFC6241 NETCONF (Network Configuration Protocol), [online],<https: / / tools.ietf.org / html / rfc6241> [Non-Patent Document 2] Cisco website<http: / / www.tail-f.com / > Summary of the Invention [Problem to be solved by the invention]

[0008] In Patent Document 1, each operational system for network configuration, monitoring, etc. needs to support multiple configuration and monitoring protocols such as NETCONF (Network Configuration Protocol) and SNMP (Simple Network Management Protocol), which complicates the interface between the system and network devices and increases system costs.

[0009] Non-Patent Documents 1 and 2 make it possible to implement new protocols in network devices and simplify the implementation of the interface on the system side, but they cannot configure or monitor old network devices that have difficulty supporting new protocols, such as devices that only support SNMP.

[0010] The object of the present invention is to solve the above-mentioned technical problems and provide a protocol conversion device, method, and program that enables a network setting monitoring device that does not support SNMP to obtain status information for a network device that only supports SNMP and input device setting information. [Means for solving the problem]

[0011] In order to achieve the above object, the present invention provides a protocol conversion device for converting information models of mutually incompatible communication protocols into each other, the protocol conversion device comprising a first interface corresponding to a first communication protocol, a second interface corresponding to a second communication protocol, a conversion table storing conversion information for converting an information model corresponding to one of the first and second communication protocols acquired from one of the first and second interfaces into an information model corresponding to the other communication protocol, and a conversion means for converting the information model corresponding to one of the communication protocols into an information model corresponding to the other communication protocol by referring to the conversion table, and the information model resulting from the conversion of the communication protocol is transmitted from the other of the first and second interfaces. Effect of the Invention

[0012] According to the present invention, a new network setting monitoring device that does not support SNMP can obtain status information and input setting information from old network devices that only support SNMP, so that the new network setting monitoring device can remotely control the old network devices. Also, even if there are multiple network setting monitoring devices, there is no need to add functions or set each device to support SNMP, which contributes to cost reduction. [Brief description of the drawings]

[0013] [Figure 1] 1 is a functional block diagram of a network system to which the present invention is applied; [Diagram 2] 1 is a functional block diagram of a conversion device according to an embodiment of the present invention; [Diagram 3] 11 is a diagram showing an example of conversion information (conversion table) registered in a conversion table section regarding a MIB model. FIG. [Figure 4] FIG. 2 is a diagram for explaining the difference in data structure between state information described in the MIB model and state information described in the YANG model. [Diagram 5] 1 is a diagram showing an example of conversion information (conversion table) registered in a conversion table section regarding a YANG model. [Figure 6] 13 is a diagram showing an example in which a monitoring information collector converts monitoring information of an MIB model into a YANG model and responds to the network configuration monitoring device. FIG. [Figure 7] 13 is a diagram showing an example in which a device setting input unit converts device setting information of a YANG model into an MIB model and inputs the information into a network device. [Figure 8] 13 is a sequence flow showing a procedure for registering a network device by a network device registration unit. [Figure 9] FIG. 11 is a diagram illustrating an example of NW device registration information. [Figure 10] 11 is a sequence flow showing an operation of a monitoring information collection unit for collecting monitoring information from a network device. [Figure 11A] This is a diagram (part 1) for explaining the procedure for converting monitoring information of a MIB model to a YANG model. [Figure 11B] This is a diagram (part 2) for explaining the procedure for converting monitoring information of the MIB model to a YANG model. [Figure 11C] This is a diagram (part 3) for explaining the procedure for converting monitoring information of the MIB model to a YANG model. [Figure 11D] This is the fourth diagram to explain the procedure for converting monitoring information of the MIB model into a YANG model. [Figure 11E] This is a diagram (part 5) for explaining the procedure for converting monitoring information of the MIB model to a YANG model. [Figure 11F] This is the sixth diagram to explain the procedure for converting monitoring information of the MIB model into a YANG model. [Figure 12] 13 is a sequence flow showing an operation of a device setting input unit inputting device settings to a network device. [Figure 13A] This is a diagram (part 1) for explaining the procedure for converting device setting information of a YANG model into a MIB model. [Figure 13B] This is a diagram (part 2) for explaining the procedure for converting device configuration information from a YANG model to a MIB model. [Figure 13C] This is a diagram (part 3) for explaining the procedure for converting device configuration information from a YANG model to a MIB model. [Figure 13D] This is a diagram (part 4) for explaining the procedure for converting device configuration information from a YANG model to a MIB model. [Figure 13E] This is a diagram (part 5) for explaining the procedure for converting device configuration information from a YANG model to a MIB model. [Figure 13F] This is a diagram (part 6) to explain the procedure for converting device configuration information from a YANG model to a MIB model. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0014] Hereinafter, an embodiment of the present invention will be described in detail with reference to the drawings. Fig. 1 is a functional block diagram showing the configuration of a network system to which the present invention is applied, and components not necessary for explaining the present invention are omitted.

[0015] In this embodiment, an example will be described in which an old-style network device that supports SNMP but does not support RESTCONF / YANG or NETCONF / YANG is controlled from a new-style network configuration monitoring system that supports RESTCONF / YANG and NETCONF / YANG, which are currently mainstream network configuration protocols, but does not support conventional SNMP.

[0016] The network configuration monitoring device Ncm supports only RESTCONF / YANG and has only a RESTCONF interface as an API. The network configuration device Nc supports only NETCONF / YANG and has only a NETCONF interface as an API. The network monitoring device Nm supports only NETCONF / YANG and has only a NETCONF interface as an API.

[0017] Network device NNtypeA supports only RESTCONF / YANG and has a RESTCONF interface. Network device NNtypeB supports only SNMP and has an SNMP / agent interface. Network device NNtypeC supports only NETCONF / YANG and has a NETCONF interface.

[0018] These new network configuration monitoring / setting / monitoring devices Ncm, Nc, Nm communicate directly with the new network devices NNtypeA, NNtypeC via the RESTCONF interface, and communicate indirectly with the old network devices NNtypeB that do not support RESTCONF / YANG via the conversion device 1.

[0019] The conversion device 1 has RESTCONF, NETCONF and SNMP Client interfaces, and communicates with new network configuration monitoring / setting / monitoring devices Ncm, Nc, Nm via the RESTCONF or NETCONF interface, and communicates with old network devices NNtypeB via SNMP Client.

[0020] The conversion device 1 converts an information model (YANG model) described in YANG format by the network setting monitoring / setting / monitoring devices Ncm, Nc, Nm into a description in MIB format and transmits it to an old-style network device NNtype B that supports only SNMP. It also converts an information model (MIB model) described in MIB format by the network device NNtype B into a description in YANG format and transmits it to new-style network setting monitoring / setting / monitoring devices Ncm, Nc, Nm that support RESTCONF or NETCONF.

[0021] Such a conversion device 1 can be configured by implementing applications (programs) that realize the functions described in detail below on a general-purpose computer or server equipped with a CPU, ROM, RAM, bus, interface, etc. Alternatively, it can be configured as a dedicated machine or a single-function machine in which part of the application is implemented as hardware or software.

[0022] FIG. 2 is a functional block diagram of the conversion device 1, and its main components include a RESTCONF interface 101, a NETCONF interface 102, an SNMP Client 103, a user interface (UI) 104, a NW device registration unit 105, a NW device registration information database (DB) 106, a monitoring information collection unit 107, a device setting input unit 108, and a conversion table unit 109. Again, illustration of components unnecessary for explaining the present invention is omitted.

[0023] The network device NN (type B) that is the target of information management model conversion is registered in advance in the conversion device 1, and the information model conversion operation can be performed only for the registered network device NN. First, the operator accesses the NW device registration unit 105 via the UI 104, and registers information on the network device NN (type B) that is the target of conversion in the NW device registration information DB 106 as NW device registration information.

[0024] Information for mutual conversion between the YANG model, which is an information model handled in NETCONF and RESTCONF, and the MIB model, which is an information model handled in SNMP, is registered in advance in table format in the conversion table unit 109. Figures 3 and 5 show examples of conversion tables registered in advance in the conversion table unit 109, and as described in detail later, the MIB model and the YANG model are mutually converted using these conversion tables.

[0025] As shown in Figure 4, the data structures of status information described in the MIB model and status information described in the YANG model are different. In the MIB model, at least one component (monitoring item) is linked to each status item such as ifMame and ifindex, whereas in the YANG model, at least one status item is linked to each component.

[0026] In this embodiment, focusing on such differences in data structure, the primary key in a specific object is identified based on the INDEX in the MIB file described in a tree structure, and defined as the variable x. Also, in the communication device data model, since there are multiple pieces of data that are linked one-to-one to interfaces, IP addresses, etc., the primary key is used as a data identifier.

[0027] Figure 3 shows how to build a conversion table (first conversion table) for converting a MIB model to a YANG model for data associated with multiple interfaces of a network device, and the explanation focuses on the IF-MIB data model. The first conversion table defines the relationship between the hierarchical state items (OIDs), conversion keys, state transition conversion keys, and INDEXes of the MIB model.

[0028] In the data model of IF-MIB, see the IF-MIB.txt file that defines the specifications, where the ifindex (interface index) of the IfEntry object is defined as the primary key (INDEX). The primary key is an identifier used to manage interface monitoring information for each interface, and in the IF-MIB model, the index, which is assigned a unique number for each interface, is used as the primary key. This is because, since interfaces are unique in the devices to be monitored and no two interfaces are the same, using the index as the primary key makes it possible to identify the intended interface.And, in the unique OID in which the state item of each interface is stored, the part of the object tree in which the primary key is written is indicated as the variable x. In the example shown, ifindex is OID[1.3. 6. 1.2.1.2.2.1.1].

[0029] In addition, a unique OID using the variable x, i.e., a "conversion key" is defined for the state item, and it is determined which data in the YANG model it is linked to. The conversion key is defined according to the state item. Note that a state transition conversion key is also set for state items whose state transitions are defined as numerical values.

[0030] Figure 5 is a diagram showing a method of constructing a conversion table (second conversion table) for converting a YANG model into a MIB model for data linked to multiple interfaces that a device has. The relationship between the hierarchical state items, conversion keys, primary keys, and state transition conversion keys of the YANG model is defined, and the same conversion key as the conversion key is set for the state items corresponding to each state item in the first conversion table.

[0031] As in the case of the MIB model, the YANG file is referenced, and here the name of the interface object is defined as the primary key. Also, as in the case of the MIB model, a state transition conversion key is set for state items where state transitions can be obtained from several options. In this embodiment, conversion operations are realized by inputting state information having the same conversion key in these conversion tables to the corresponding state information.

[0032] Returning to Figure 2, the new network configuration monitoring device Ncm1, which is compatible only with RESTCONF / YANG, cooperates with the monitoring information collection unit 107 and the device setting input unit 108 via the RESTCONF interface to realize the functions of requesting the collection of monitoring information and obtaining the results, as well as requesting the input of device settings and obtaining the results.

[0033] The network configuration monitoring device Ncm2, which is compatible only with NETCONF / YANG, cooperates with the monitoring information collection unit 107 and the device setting input unit 108 via the NETCONF interface to realize the functions of requesting the collection of monitoring information and obtaining the results thereof, as well as requesting the input of device settings and obtaining the results thereof.

[0034] When the monitoring information collection unit 107 receives a command related to monitoring information collection, such as RESTCONF GET or NETCONF GET, from each new network configuration monitoring device Ncm, it refers to the conversion table unit 109 and converts the monitoring information collection model described in the YANG model into a monitoring information collection model described in the MIB model. Then, it transmits the MIB model via the SNMP client to the network device NNtypeB specified as the destination of the command.

[0035] The monitoring information collection unit 107 further converts the monitoring information of the MIB model responded by the old network device NNtypeB into monitoring information in xml, yaml or json format described in the YANG model, as shown in an example in Figure 6, and responds to the requesting network configuration monitoring device Ncm.

[0036] When the device setting input unit 108 receives a device setting-related command such as RESTCONF DELETE, PUT, POST, or NETCONF EDIT from each new network setting monitoring device Ncm, it refers to the conversion table unit 109 and converts the device setting information described in the YANG model into SNMP data described in the MIB model, as shown in Fig. 7. Then, it inputs the device setting information of the MIB model by sending it via the SNMP client to the old network device NNtypeB specified as the destination of the command.

[0037] In this way, in this embodiment, it is possible to remotely control old network devices that only support SNMP from a newer network setting monitoring device that does not support SNMP, such as collecting monitoring information and inputting device settings, which makes it possible to reduce the functions of each network setting monitoring device, and therefore costs can be reduced.

[0038] 8 is a sequence flow showing the procedure of NW device registration by the NW device registration unit 105. At time t1, an operator requests device registration of an old network device NNtypeB from the UI 104 to the NW device registration unit 105. At time t2, the NW device registration unit 105 transmits SNMP polling to the network device NNtypeB in order to check the MIB model supported by the requested network device NNtypeB.

[0039] In response to the SNMP polling, the network device NNtypeB to be registered returns SNMP status information to the NW device registration unit 105 at time t3. The NW device registration unit 105 analyzes and processes the returned SNMP status information at time t4, and checks the MIB model supported by the network device NNtypeB.

[0040] At time t5, NW equipment registration unit 105 registers the analysis result as NW equipment registration information in NW equipment registration information DB 106. At time t6, NW equipment registration information DB 106 responds with a registration completion to NW equipment registration unit 105. At time t7, NW equipment registration unit 105 notifies the operator of the registration completion.

[0041] Figure 9 is a diagram showing an example of network device registration information. For each old network device, the node name (Node), a flag indicating whether it is enabled or not (enable), the IP address of the SNMP interface, the listening port when receiving conversion from the network configuration monitor Ncm to RESTCONF / NETCONF, and the capability of the supported MIB model (Capability), such as whether it supports if-mib or cisco-mib, are registered.

[0042] FIG. 10 is a sequence flow showing the operation of the monitoring information collection unit 107 collecting monitoring information from the old network device NN type B. At time t21, the monitoring information collection unit 107 receives a monitoring information acquisition request including a RESTCONF / NETCONF port specification from the network configuration monitoring device Ncm via the RESTCONF interface or NETCONF interface.

[0043] At time t22, the monitoring information collection unit 107 transmits the RESTCONF / NETCONF listening port to the NW device registration information DB 106. At time t23, the NW device registration information DB 106 responds with an IP address associated with the listening port. At time t24, the monitoring information collection unit 107 transmits SNMP pooling to the network device NNtypeB of the IP address. At time t25, the network device responds with SNMP status information described in MIB format to the SNMP pooling.

[0044] When the monitoring information collection unit 107 acquires the SNMP status information described in the MIB format, at time t26 it refers to the YANG model conversion table corresponding to the network device NN type B in the conversion table 108, and acquires conversion table information at time t27. At time t28, it converts the SNMP status information into SNMP status information in YANG format using the acquired conversion table information, and transmits it to the destination network setting monitoring device at time t29.

[0045] Since this process is expected to be performed constantly, the conversion from listening ports to IP addresses and the model conversion of status information can be omitted by storing a table in memory.

[0046] Next, the method of the conversion process at times t26 to t28 will be described with reference to Figures 11A to 11F. The monitoring information collector 107 acquires the interface monitoring information shown in Figure 11A from the old network device NNtypeB using SNMP. The interface monitoring information is expressed in a tree structure as shown in Figure 11(b).

[0047] When the monitoring information collector 107 determines that the acquired interface monitoring information is data conforming to the IF-MIB model, it refers to the first conversion table (FIG. 11B) corresponding to the IF-MIB model and judges whether or not an index exists. If an index exists, that is, if the network device NNtypeB has multiple interfaces, it identifies the index and then classifies the interface monitoring information of the network device NNtypeB by index, which is a primary key, as shown in FIG. 11C.

[0048] Next, for the data divided by index, a first conversion table (FIG. 11B) corresponding to the MIB model is referenced, and actual data for conversion is generated by labeling as shown in FIG. 11D. In the labeling, a state item is associated with each state item data. For state items that have a state transition conversion key, the state transition conversion key is associated in addition to the conversion key.

[0049] Next, in the actual data for conversion labeled for each index, the json data in FIG. 11F is generated by referring to the second conversion table corresponding to the YANG model in FIG. 11E. In this embodiment, the primary key items in the conversion table in FIG. 11E are first checked for each group of SNMP data, such as x=1, x=2. Here, since name is the primary key, the same conversion key is found from the data divided for each index based on the name of x=1, and the corresponding data is read out. In the illustrated example, GigabitEthernet0 / 0 / 0 / 0 is obtained. Then, the json data in FIG. 11F is generated for each primary key according to FIG. 11E.

[0050] In Fig. 11F, data corresponding to x=1 and x=2 in Fig. 11D are stored in parentheses under a list called interface (line 3). The monitoring information collector 107 responds to the new network configuration monitor Ncm with this json data as monitoring information at time t29.

[0051] FIG. 12 is a sequence flow showing the operation of the device setting input unit 108 when inputting device settings from the new network setting monitor device Ncm to an old network device NNtypeB.

[0052] At time t41, the new network setting monitoring device Ncm requests the device setting input unit 108 to input device settings by specifying a port via the RESTCONF interface or NETCONF interface. At time t42, the device setting input unit 108 transmits a conversion request in which a RESTCONF / NETCONF listening port number is described to the NW device registration information DB 106. At time t43, the NW device registration information DB 106 responds to the device setting input unit 108 with an IP address associated with the listening port number.

[0053] In order to convert the device settings described in the YANG model into device settings defined in the MIB model, the device setting input unit 108 refers to the conversion table unit 109 at time t44 and acquires corresponding conversion table information at time t45. At time t46, the device setting conversion process is performed using the acquired conversion table information.

[0054] Next, a method of converting device settings will be described with reference to Figures 13A to 13F. The device setting input unit 108 acquires the interface monitoring information shown in Figure 13A from the network setting monitor Ncm using netconf or restconf, and when it is determined that this is data conforming to the openconfig-interface model, it refers to the YANG model table (Figure 13B) corresponding to the YANG model and determines whether or not a primary key (here, name) is present. If a primary key is present, the data is divided by primary key as shown in Figure 13C.

[0055] Next, in the data divided by primary key, a conversion table (FIG. 13B) corresponding to the YANG model is referenced, and labeling is performed as shown in FIG. 13D to generate actual data for conversion. In labeling, a status item is linked to each status item data, similar to the actual data for conversion in FIG. 11D. In addition, a status transition key is further linked to a status item having a status transition key. Then, in the actual data for conversion labeled by primary key, a first conversion table corresponding to the IF-MIB model in FIG. 13E is referenced, and the MIB model data in FIG. 13F is generated.

[0056] When generating, the SNMP data is written in order for each primary key. To write status item data based on a conversion key (e.g. ifindex) with a primary key flag defined in the conversion table, data associated with each conversion key is searched for and read from the data separated by primary key. In the example, an IfEntry object is written for each ifindex=1, 2, and SNMP data is generated.

[0057] At time t47, the device setting input unit 108 requests the network device NNtypeB to input the json data generated as described above using an SNMP SET REQUEST. When the network device NNtypeB finishes inputting the device settings, it returns a response signal at time t48. At time t49, the device setting input unit 108 notifies the new network setting monitoring device Ncm of the completion of the settings.

[0058] In the above embodiment, an example was described in which IF-MIB and openconfig-interfaces.yang are the targets of conversion, but the present invention is not limited to this and can be similarly applied to other MIB models and YANG models.

[0059] According to the above embodiment, a new network setting monitoring device that does not support SNMP can acquire status information and input setting information for old network devices that only support SNMP, and the new network setting monitoring device can remotely control the old network devices, providing a low-cost and good network environment. As a result, it is possible to contribute to Goal 9 "Develop resilient infrastructure and promote inclusive and sustainable industrialization" and Goal 11 "Make cities inclusive, safe, resilient and sustainable" of the Sustainable Development Goals (SDGs) led by the United Nations. [Explanation of symbols]

[0060] 1...conversion device, 101...RESTCONF interface, 102...NETCONF interface, 103...SNMP Client, 104...user interface, 105...network device registration unit, 106...network device registration information database, 107...monitoring information collection unit, 108...device setting input unit, 109...conversion table unit

Claims

1. A protocol conversion device for converting information models of mutually incompatible communication protocols, comprising: a first interface corresponding to a first communication protocol; a second interface corresponding to a second communication protocol; a conversion table unit storing a conversion table for converting an information model corresponding to one of the first and second communication protocols acquired from one of the first and second interfaces into an information model corresponding to the other communication protocol; a conversion means for converting an information model corresponding to one of the communication protocols into an information model corresponding to the other of the communication protocols by referring to the conversion table; Transmitting the information model with the converted communication protocol from the other of the first and second interfaces; The conversion means is a monitoring information collection means for converting an information model relating to a monitoring information acquisition request from a network setting monitoring device connected to the first interface to a network device connected to the second interface and a response thereto by referring to the conversion table, and then transmitting the information model to a corresponding destination; a network device registration means for acquiring information on an IP address, a port number for accepting information model conversion, and a capability related to a supported protocol from each network device connected to the second interface, and registering the information in a database; The protocol conversion device is characterized in that when the monitoring information collection means receives a monitoring information acquisition request including a port number designation from the network configuration monitoring device, it accesses the IP address associated with the port number on the database to acquire the monitoring information.

2. A protocol conversion device for converting information models of mutually incompatible communication protocols, comprising: a first interface corresponding to a first communication protocol; a second interface corresponding to a second communication protocol; a conversion table unit storing a conversion table for converting an information model corresponding to one of the first and second communication protocols acquired from one of the first and second interfaces into an information model corresponding to the other communication protocol; a conversion means for converting an information model corresponding to one of the communication protocols into an information model corresponding to the other of the communication protocols by referring to the conversion table; Transmitting the information model with the converted communication protocol from the other of the first and second interfaces; the conversion means converts an information model relating to a device setting input request from a network setting monitoring device connected to the first interface to a network device connected to the second interface and a response thereto by referring to the conversion table, and then transmits the information model to the corresponding destination; a network device registration means for acquiring information on an IP address, a port number for accepting information model conversion, and a capability related to a supported protocol from each network device connected to the second interface, and registering the information in a database; The protocol conversion device is characterized in that when the device setting input means receives a device setting input request including a port number designation from the network setting monitoring device, it accesses the IP address associated with the port number in the database to input the device settings.

3. 3. The protocol conversion device according to claim 1, wherein a network configuration monitoring device connected to the first interface supports at least one of NETCONF / YANG and RESTCONF / YANG, and a network device connected to the second interface supports SNMP / MIB.

4. The conversion table unit a first conversion table defining the relationship between a status item, a conversion key, and an INDEX of the MIB model; a second conversion table that defines a relationship between state items, conversion keys, and primary keys of the YANG model; The INDEX and the primary key are identifiers of the interface in the MIB model and the YANG model, respectively; The conversion means is applying the MIB model to the first conversion table to convert the status item data into actual data for conversion in which a conversion key is associated with each status item data; The protocol conversion device according to claim 3, wherein the actual data for conversion is converted into a YANG model by applying the actual data for conversion to the second conversion table.

5. The conversion means is Applying the YANG model to the second conversion table to convert the state item data into actual data for conversion in which a conversion key is associated with each state item data; 5. The protocol conversion device according to claim 4, wherein the actual data for conversion is converted into an MIB model by applying the actual data for conversion to the first conversion table.

6. the first conversion table defines the relationship between the state item, conversion key, INDEX, and state transition conversion key of the MIB model, and includes a state in which the conversion key of the actual data for conversion corresponds to the state transition conversion key; The protocol conversion device according to claim 4 or 5, characterized in that the second conversion table defines the relationship between state items, conversion keys, primary keys, and state transition conversion keys of the YANG model, and includes states in which the conversion keys of the actual data for conversion correspond to the state transition conversion keys.

7. A protocol conversion method for converting information models of mutually incompatible communication protocols by a computer, comprising: The computer, a first interface corresponding to a first communication protocol; a second interface corresponding to a second communication protocol; a conversion table for converting an information model corresponding to one of the first and second communication protocols acquired from one of the first and second interfaces into an information model corresponding to the other communication protocol; converting an information model corresponding to one of the communication protocols into an information model corresponding to the other of the communication protocols by referring to the conversion table; transmitting the information model with the converted communication protocol from the other of the first and second interfaces; The step of converting into an information model comprises: a monitoring information collection step of converting information models relating to a monitoring information acquisition request from a network setting monitoring device connected to the first interface to a network device connected to a second interface and a response thereto by referring to the conversion table, and then transmitting the information models to the corresponding destinations; a network device registration step of acquiring information on an IP address, a port number for accepting information model conversion, and a capability related to a supported protocol from each network device connected to the second interface, and registering the information in a database; The protocol conversion method is characterized in that the monitoring information collection step, when a monitoring information acquisition request including a port number designation is received from the network configuration monitoring device, accesses an IP address associated with the port number on the database to acquire the monitoring information.

8. A protocol conversion method for converting information models of mutually incompatible communication protocols by a computer, comprising: The computer, a first interface corresponding to a first communication protocol; a second interface corresponding to a second communication protocol; a conversion table for converting an information model corresponding to one of the first and second communication protocols acquired from one of the first and second interfaces into an information model corresponding to the other communication protocol; converting an information model corresponding to one of the communication protocols into an information model corresponding to the other of the communication protocols by referring to the conversion table; transmitting the information model with the converted communication protocol from the other of the first and second interfaces; The step of converting into an information model comprises: a device setting input step of converting information models relating to a device setting input request and a response thereto from a network setting monitoring device connected to the first interface to a network device connected to a second interface by referring to the conversion table, and then transmitting the information models to the corresponding destinations; a network device registration step of acquiring information on an IP address, a port number for accepting information model conversion, and a capability related to a supported protocol from each network device connected to the second interface, and registering the information in a database; The protocol conversion method is characterized in that the device setting input step, when a device setting input request including a port number designation is obtained from the network setting monitoring device, accesses an IP address associated with the port number in the database to input the device settings.

9. A protocol conversion program that converts information models of mutually incompatible communication protocols into each other on a computer, The computer, a first interface corresponding to a first communication protocol; a second interface corresponding to a second communication protocol; a conversion table for converting an information model corresponding to one of the first and second communication protocols acquired from one of the first and second interfaces into an information model corresponding to the other communication protocol; a step of converting an information model corresponding to one of the communication protocols into an information model corresponding to the other of the communication protocols by referring to the conversion table; transmitting the information model with the converted communication protocol from the other of the first and second interfaces; The step of converting into the information model comprises: a monitoring information collection procedure for converting information models relating to a monitoring information acquisition request from a network configuration monitoring device connected to the first interface to a network device connected to a second interface and a response thereto by referring to the conversion table, and then transmitting the information models to the corresponding destinations; a network device registration step of acquiring information on an IP address, a port number for accepting information model conversion, and a capability related to a supported protocol from each network device connected to the second interface, and registering the information in a database; The protocol conversion program is characterized in that, when a monitoring information collection request including a port number designation is received from the network configuration monitoring device, the protocol conversion program accesses an IP address associated with the port number on the database to obtain the monitoring information.

10. A protocol conversion program that converts information models of mutually incompatible communication protocols into each other on a computer, The computer, a first interface corresponding to a first communication protocol; a second interface corresponding to a second communication protocol; a conversion table for converting an information model corresponding to one of the first and second communication protocols acquired from one of the first and second interfaces into an information model corresponding to the other communication protocol; a step of converting an information model corresponding to one of the communication protocols into an information model corresponding to the other of the communication protocols by referring to the conversion table; transmitting the information model with the converted communication protocol from the other of the first and second interfaces; The step of converting into the information model comprises: a device configuration input procedure for converting information models relating to a device configuration input request and a response thereto from a network configuration monitoring device connected to the first interface to a network device connected to a second interface by referring to the conversion table, and then transmitting the information models to the corresponding destinations; a network device registration step of acquiring information on an IP address, a port number for accepting information model conversion, and a capability related to a supported protocol from each network device connected to the second interface, and registering the information in a database; The protocol conversion program is characterized in that, when a device setting input request including a port number designation is obtained from the network setting monitoring device, the device setting is input by accessing an IP address associated with the port number in the database.

Images