JP2005045840A - Network management method and network management system - Google Patents

Abstract

PROBLEM TO BE SOLVED To facilitate management corresponding to a service type and connection setting with respect to a network management method and a network management system.
Based on a database 2 in which network configuration information and view configuration information are stored in association with each other, and either or both of physical network configuration information and logical network configuration information corresponding to a service type stored in the database 2 Manages the same type of network as a local domain by associating failure information that depends on the service management server 1 that controls display on the device and the devices collected from the managed network devices with failure labels, physical failure levels, and service failure levels Network management servers 3-1 to 3-3 for managing a physical network configuration and a logical network configuration using a plurality of local domains as one multi-domain.

Description

The present invention relates to a network management method and a network management system for managing a network that provides various services.
A network is known in which a plurality of nodes (switches, ATM switches, etc.) and cross-connect devices are connected by physical lines to form logical paths corresponding to various services such as voice, image, data, and the like. In a large-scale network, a plurality of communication carriers may be scattered, and it is desired to perform network management for service or for communication carriers.

  Conventional LAN (Local Area Network), WAN (Wide Area Network), and various means for connecting these to each other to form a large-scale network and managing this large-scale network have been proposed. Large-scale networks are generally composed of multi-vendor equipment, and are operated by a single communication carrier, or are constructed and operated by a plurality of communication carriers, etc. There is. Accordingly, it is known to divide a large-scale network into a plurality of groups and to create a hierarchy, to display and manage a network for each group, and to manage a detailed connection configuration in the hierarchical group (for example, , See Patent Document 1).

  Also, there is a known method for managing the network while ensuring the security between different telecommunications carriers by storing virtual view information for managing only the network part corresponding to the telecommunications carrier in the table. (For example, refer to Patent Document 2).

In addition, the network node is displayed on the display screen, the network status and interface connection status are displayed in different colors, the desired beep settings are made, and when a failure occurs, the network administrator is notified of the failure occurrence part. There are known means for displaying in a different color and notifying the occurrence of a failure by sound, and means for performing network management using a GUI (Graphical User Interface). For example, it is known that MIB (Management Information Base) information is acquired by selecting an icon or a pull-down menu so that the current network state can be visually grasped.
JP-A-6-326706 JP-A-4-230139

  A network connects terminals or between an information provider and a terminal via a physical line, an exchange, an ATM switch, etc., and CBR (Constant Bit Rate) related to transmission on voice, image, Internet or network. ), VBR (Variable Bit Rate: variable bit rate) and the like. However, in conventional network management, the state of a node such as an exchange or an ATM switch, the state of a physical line, and the like are displayed on a management screen, and the occurrence of a failure is displayed. Therefore, it is impossible to manage the network state in response to the service, and it has not been possible to easily recognize whether or not the failure that has occurred affects the service.

Connection setting for providing a service is generally performed by inputting a command. Therefore, when a multi-vendor device is included, it is necessary to create a command corresponding to each device. Therefore, it is not easy to set a connection corresponding to the service to be provided.
An object of the present invention is to display a physical network configuration and a logical network configuration corresponding to a service type, and facilitate management or connection setting corresponding to the service type.

  The network management method of the present invention includes (1). A process of creating a view capable of displaying one or both of the physical network configuration and the logical network configuration by associating the network configuration information with the view configuration information in correspondence with at least one service type, and at least a management target Based on the failure information depending on the devices collected from one network device, the failure label, the process of converting the failure label so as to be unified in the entire network corresponding to the failure level, the converted failure label and the failure level And a process of making it possible to display a failure level for each service provision.

  (2). In addition, the process of managing network device failures by converting device-dependent failure information into device-independent information by converting into failure labels, physical failure levels, and service failure levels that are unified throughout the network, Managing different types of networks as local domains corresponding to the types, managing the physical network configuration and the logical network configuration as a network of the same type with the plurality of local domains as one multi-domain, and at least one service The process of associating the network configuration information with the view configuration information and creating a view capable of displaying either one or both of the physical network configuration and the logical network configuration is included in correspondence with the type.

  (3). In addition, the process includes a process of associating the failure label corresponding to the failure occurrence location with the failure level of the physical failure and the service failure and displaying the failure level in association with the view.

  (4). In addition, it includes a process of managing failure information in units of nodes or ports of the network, and managing a failure level having the highest failure level at a failure occurrence location via a connection as the failure level of the connection.

  (5). It also includes the process of designating nodes and links in the physical network configuration and setting paths between edges.

  (6). Further, it includes a process of designating edges in the physical network configuration, extracting nodes and links of the paths between the edges based on network management information, and setting the paths between the edges.

  (7). The network management system of the present invention includes a database that stores network configuration information and view configuration information in association with each other, and physical network configuration information and logical network configuration corresponding to a service type in the view configuration information stored in the database. Service management server that controls display based on one or both of the information, and fault information that depends on the equipment collected from at least one network equipment to be managed, fault label, physical fault level, and service fault status A network management server that manages the same type of network as a local domain corresponding to the level, the service management server manages each of the local domains that manage different networks so that the network is independent of the type, These multiple And it manages the physical network configuration and the logical network configuration of the local domain as a single multi-domain.

  (8). The service management server includes a connection setting unit that specifies an edge or a node and a link based on contents according to physical network configuration information and controls connection setting between the edges.

  The present invention can be managed as a service-specific network configuration by managing a view corresponding to a single or a plurality of service types provided by the network. In addition, even when a failure occurs, it is possible to easily identify whether or not the service being managed is affected, and there is an advantage that measures can be easily taken when a failure occurs. In addition, it is easy to set up connections to support service types, and even when multi-vendor devices are included in such cases, it can be configured to absorb differences in models, etc., making it easy to add and delete management targets There is an advantage to become.

  The network management method of the present invention is a process of creating a view capable of displaying either one or both of a physical network configuration and a logical network configuration by associating network configuration information and view configuration information in correspondence with at least one service type. And the process of converting the failure information that depends on the device collected from at least one network device to be managed to be unified across the network in accordance with the failure label and failure level, and And displaying a failure level for each service provision based on the failure label and the failure level.

  The network management system of the present invention includes a database that stores network configuration information and view configuration information in association with each other, and physical network configuration information and logical network configuration corresponding to a service type in the view configuration information stored in the database. Service management server that controls display based on one or both of the information, and fault information that depends on the equipment collected from at least one network equipment to be managed, fault label, physical fault level, and service fault status A network management server that manages the same type of network as a local domain corresponding to the level, the service management server manages each of the local domains that manage different networks so that the network is independent of the type, These multiple And it has a structure for managing the physical network configuration and the logical network configuration the local domain as a single multi-domain.

  FIG. 1 is a schematic explanatory diagram of an embodiment of the present invention. 1 is a service management server, 2 is a database, 3-1 to 3-3 are NEM servers, and 4-1 to 4-4 are VOD (Video). -On-Demand (client) service management, voice service management, IP (Information Provider) service management, line lending service management clients, and 5 indicates a network. The service management server 1 includes a view definition unit 1-1, a real-time NW (network) configuration information update unit 1-4, an end-end connection setting unit 1-3, and a logical network configuration diagram creation unit 1. -2, and functions such as a cooperation unit 1-5 for physical failure and logical network failure.

  The NEM (network management) servers 3-1 to 3-3 collect changes in configuration information such as devices and links in the network 5 and failure information by, for example, traps and polling, and change information that affects services. Only the service management server 1 is notified. Thereby, the database 2 is updated from the service management server 1. Note that network configuration information such as each ATM switch and high-speed line of the network 5 is collected at the time of system startup, stored in the database 2, and updated in response to changes in the network configuration information. In addition, according to the view creation process, a view corresponding to one or a plurality of service types is stored.

  Clients 4-1 to 4-4 indicate clients corresponding to service types such as VOD service, voice service, IP service, and line lending service, and a plurality of clients are added to correspond to other service types not shown. can do.

  A view in the present invention means a unit managed on a GUI (Graphical User Interface) of a network management system, and a multiple view is a service physically provided on one network. , It seems to be offered on an independent network for each service. Further, the view associates the logical network configuration with the physical network configuration and can display both or any one of them.

  In addition, the network administrator or service administrator selects a view corresponding to a single service or a plurality of services from the displayed list of views, and displays a single or a plurality of services on a display unit (not shown) according to the view configuration information. Either or both of the physical network configuration and the logical network configuration of the service type are displayed. In addition, using the view, the location of failure occurrence, failure coverage, etc. can be displayed, and connection settings can be made. A view displayed so that all devices in the network can be seen without hierarchizing the network is referred to as a flat view, and a view that is grouped for each region and displayed hierarchically is referred to as a domain view.

  FIG. 2 is an explanatory diagram related to the physical network configuration of the multiple view according to the embodiment of the present invention. 10 is a physical network, 11 is a voice service view, 12 is an Internet service view, and 13 is a VOD service view. The case where the physical network configuration that provides each service is displayed is shown.

  For example, the voice service is provided by a network in which PBX exchanges are connected via an ATM exchange, the Internet service is provided by a network in which routers are connected via an ATM exchange, and the VOD service is provided by a VOD server and a VOD terminal. The network is provided by a network connected via an ATM switch, and network management can be performed in correspondence with the service. For example, the VOD service manager can manage the network configuration for providing the VOD service according to the physical network configuration or the logical network configuration related to the VOD service by using the view 13.

  3 is an explanatory diagram of database update according to the embodiment of the present invention. The database 2 in FIG. 1, the service management server 1, one NEM server 3 among the NEM servers 3-1 to 3-3, The switch 5 and the equipment (NE) 21 such as an ATM switch in the network 5 will be described. The NEM server 3 is generally disposed at a relatively close position to the network, and the service management server 1 is configured to be connected to a plurality of NEM servers 3. May be connected via a network (not shown).

  Information on all devices 21 and the like of the network to be managed is collected when the system is started up. Then, the NEM server 3 collects information change, failure information, etc. of the device 21 and converts it into a DB (database) registration information (new) 23 by the function 22 that converts the information according to the rules for each device. The DB registration information (old) 24 is compared with the DB registration information (old) 24 by the comparison function 25, and the DB registration information (old) 24 is updated with the DB registration information (new) 23 and transferred to the service management server 1 only when it is changed. To do. The service management server 1 updates the database 2 by the DB update function 26. Accordingly, the database 2 can be updated while reducing the transmission amount by transferring only when information related to the service of information collected from the network is changed.

  FIG. 4 is an explanatory diagram of the component configuration. The configuration and the overview shown in FIG. 1 correspond to each other. The service management server 1 connected to the database 2 includes a client manager (Client Manager) 31 and a view controller (VCNT). 32, a user manager (UM) 33, a multi-domain manager (MDM) 34, and local domain managers (LDM) 35, 36 that absorb different conditions depending on device types such as an ATM switch, SONET / SDH, and LAN in the network 5. 37, and the NEM servers 3-1 to 3-3 include a node discovery (NDS) 38 and an element access module (EAM) 39. Reference numeral 40 denotes a client (UI) that provides a GUI based on information acquired from the service management server 1.

  FIG. 5 is a system configuration diagram using components. The component configuration of FIG. 4 is hierarchically illustrated, and can be divided into model-dependent objects and model-independent objects. The model-dependent objects are independent of the network type. It can be divided into objects and network type dependent objects. Accordingly, an EAM (element access module) is connected to support the model of the ATM exchange etc. of the network 5 and absorbs different conditions for each model. An LDM (local domain manager) is connected to correspond to the type of network including a plurality of devices, and absorbs different conditions depending on the network type such as ATM, SONET, SDH, and IP.

  A network type independent object MDM (multi-domain manager) manages the entire network 5, and a UI (client) provides a GUI based on information acquired from the service management server 1. A UM (User Manager) 33 in FIG. 4 manages the relationship between a password and a view for providing a GUI to a user (network manager). The NDS (node discovery) 38 has a function of adding a device to be managed or deleting a device not to be managed, and can divide the process for each specific network range.

  FIG. 6 is an explanatory diagram of an example of database items, showing DB items, information collected from devices, and conversion methods. For example, as an example of a database (DB) item related to the service management server 1, a network configuration, a node state, a link state, a connection route, and a connection state are shown. For example, the connection route of the DB item collects information from the network cross-connects and connects the cross-connects to form a connection route. If the cross-connect is changed, the route information is partially corrected. If there is no cross-connect, the connection path is deleted from the DB.

  An example of the event and database (DB) reconstruction item is shown in FIG. Events include possible changes and collection items in response to node failure, node failure recovery, connection addition, connection change, connection deletion, user (network administrator or service administrator) request, etc. In the case of an additional event, the assumed change is connection addition, and the collection item is the route of the added connection.

  FIG. 8 and FIG. 9 are explanatory diagrams of the database configuration. The database configuration is divided into an NW (network) configuration information unit 51 and a view configuration information unit 52, and numbers 1 to 5 with circles indicate connections between them. Each database item is shown in FIGS. 10 (A) and 10 (B). FIG. 10A shows network (NW) configuration information database items. For example, JVvNode indicates a node and includes network device information. JVvLink indicates a link and information on a line between devices. FIG. 10B shows a view configuration information database item. For example, JVvView shows a view and is information for managing each of a plurality of views. JVvViewDomain indicates a domain, and indicates a unit for administrative division in each view.

  Then, it is possible to detect a connection failure at the time of a port failure by providing a connection between the port and the connection on the network (NW) configuration information. Also, the node JVvNode, link JVvLink, and connection JVvConnection on the NW configuration information are managed in each view by registering in each view as the view node JVvViewNode, view link JVvViewLink, and view connection JVviewConnection, respectively. As described above, when the state of the XXX managed on the NW configuration information changes by associating a certain view XXX on the view configuration information with XXX on the NW configuration information, a plurality of It is possible to detect a change of state on the view at the same time, so that no inconsistency occurs between the views.

  FIG. 11 is an explanatory diagram of a logical network configuration. (A) and (B) show a case where a device connected to an arbitrary port of a managed node is defined as an edge, and (C) shows a connection status. A case where one virtual terminal is connected at the tip is displayed.

  In FIG. 11A, an arbitrary number of connections (logical network) are set between a pair of edges, and all intermediate devices are concealed, and only connections between edges are shown. Further, (B) shows a network configuration including an edge, a node and a link, and a case where a device such as an exchange via a connection is included. (C) shows a case where a virtual terminal is connected to the end point of the connection, and shows a route through the device. Like (A), a device such as an exchange on the way is shown. Can also be displayed concealed.

  FIG. 12 is an explanatory diagram of the trace display. FIG. 12A shows a logical network configuration including connections between edges 61 to 65 corresponding to FIG. 11A. For example, edges 61 and 64 are designated. Thus, the connection indicated by the bold line in FIG. 12B is displayed. 12C shows a physical network configuration including an edge and network equipment corresponding to FIG. 11B, and the edges 61 to 65 are connected through the equipments 66 to 69. Then, an arbitrary point on the network is designated, the connection connected to the designated point is traced, and when reaching the edge, the trace is completed and the result is displayed. For example, as shown in FIG. 12D, the trace result of edge 61 → device 66 → device 69 → device 68 → edge 64 is displayed with a bold line. Note that the distinction between the thin line and the thick line can also be displayed separately by color coding.

  FIG. 13 is an explanatory view of a multiple view, showing a case of a VOD service, in which a VOD server 71 and a VOD client 72 are connected via a network including an ATM switch (ATM) 73 and a transmission device (FLX) 74. In this system, the network configuration is displayed on the network management terminal 75 based on the management information 78 corresponding to the network manager or service manager. Similarly, the network configuration is displayed on the network management terminals 76 and 77 based on management information 79 corresponding to the network manager or service manager.

  In this case, as shown in FIG. 11A, the network management terminal 76 indicates a connection between edges (VOD server 71 and VOD client 72), and the network management terminal 77 is connected to the network management terminal 77 in FIG. 2 shows a physical network configuration including an edge and devices constituting the network. For example, when a failure occurs in the logical network configuration by the network management terminal 76, the physical network configuration by the network management terminal 77 is switched to. As a result, for example, the network administrator can be notified and repaired where the fault has occurred in the network configuration.

  Also, when the network configuration information and view configuration information are changed to define the API (Application Programming Interface) that provides the information required by the network administrator, and added when the model or managed network type increases By starting the API in the model-dependent object or the network type-dependent object, the database can be changed, the GUI display can be changed, and the like. For example, node addition / change / deletion, link addition / change / deletion, connection addition / change / deletion, connection route change, node failure / recovery, port failure / recovery, view node addition / change / deletion, view link addition / change / Delete, View Connection Add / Change / Delete, Domain Add / Change / Delete, Edge Add / Change / Delete, View Add / Change / Delete, Service Template Add / Change / Delete, Isolation Fault Definition Add / Change / Delete, Service Fault definition addition / change / deletion, etc.

  The multi-vendor device has a difference in device configuration such as one in which one card is inserted into a single slot and one in which two cards are inserted, a difference in parameters at the time of setting, and the like. In addition, various devices constituting the network are often not the same standard. For example, there are cases where an old version device and a new version device coexist for different vendors.

  Therefore, data representing one port is managed as a character string that can be recognized by the element access module EAM corresponding to the model as a port address. The local domain manager LDM and the multi-domain manager MDM recognize and process the data indicating one port without being conscious of the detailed contents of the port address character string.

  Also, when representing a connection, it is generally different for each network type. In an ATM network, one connection corresponds to one virtual channel and is represented by a VPI / VCI value. There is no such expression. Therefore, data representing one connection is managed as a connection address as a character string that can be recognized in detail only by the local domain manager LDM and the multi-domain manager MDM for each network type.

  In addition, since the cause and content of the failure are different for each device, the network service management system abstracts the failure of each device, converts it to a certain failure level, and manages it. The model-dependent object manages the relationship between the failure label and the corresponding failure level. That is, the failure code from the device is analyzed by the model-dependent object and converted into a failure label, and is replaced with a failure level according to the failure label corresponding to the device.

  FIG. 14 is an explanatory diagram of a failure label and a failure level. For example, a relationship between a failure (failure label) for the devices A and B, a failure level (physical failure), and a (service failure) is shown. For example, an HDD (hard magnetic disk device) failure of the device A is a serious failure as a physical failure, and a service failure indicates a failure that may make it impossible to provide a service. The failure of the device B fan abnormality is a warning indicating a subsequent abnormal temperature rise or the like as a physical failure, and the service failure is normal because service provision can be continued.

  Therefore, the failure label HDD failure of the device A becomes a serious failure as a failure level of a physical failure and becomes a failure as a failure level of a service failure. The failure label power supply abnormality of the device B becomes a minor failure as a failure level of a physical failure and becomes normal as a failure level of a service failure.

  15A and 15B are explanatory diagrams of failure level information. FIG. 15A shows physical failure level information, and FIG. 15B shows service failure level information. For example, the failure name of the physical failure (the failure level (physical failure in FIG. )) Is unknown, the failure level is -1, the icon color is gray, and the alarm sound ID is 0. When the failure name is normal, the failure level is 0, the icon color is green, and the alarm sound ID is 0. If the fault name is a severe fault, the fault level is 3, the icon color is red, and the alarm sound ID is 3. If the fault name of the service fault (see fault level (service fault) in FIG. 14) is normal, the fault level is 0, the icon color is green, the alarm sound ID is 0, and if the fault is fault, the fault level is 1. The icon color is red and the alarm sound ID is 1.

  FIG. 16 is an explanatory diagram of a failure label, a physical failure level, and a service failure level, and shows an example of a network ATM switch. For example, in the case of a clock failure with a failure label, the physical failure level is 3 and the service failure level is 1. In the case of a UPS (uninterruptible power supply) failure with a failure label, the physical failure level is 3 and the service failure level is 1. In the case of a temperature failure in the failure label, the physical failure level is 2 and the service failure level is 0. Similarly, the relationship between the failure label and the failure level can be determined for various devices and managed as, for example, a table configuration.

  FIG. 17 is an explanatory diagram of the definition of the failure level. The device management units 81 to 83 correspond to the EAM (element access module) 39 of FIG. 4 and have a function of absorbing the difference depending on the model. A failure level uniquely defined in the system is assigned to the failure label defined for each C and managed. The failure level means a level indicating the influence on the data flowing through the connection. 0 is normal, 1 is a warning (currently has no effect, but if left unattended, it becomes a dangerous state), 2 is a minor failure (When the service is partially affected) 3 indicates a serious failure (when the service is temporarily stopped) and 4 indicates critical (when the service may be stopped for a long time).

  For example, in the device management unit 81 of the model A, the failure label clock failure indicates failure level 1, switch failure indicates failure level 2, and adapter failure indicates failure level 3, and the model B device management unit 82 In this case, the clock failure of the failure label indicates a failure level 1 and the HD (hard disk) failure indicates a failure level 2. The hard disk failure may partially affect the service.

  In the device management units 81 to 83, the state of the devices A, B, and C is grasped by trapping or polling from the devices A, B, and C under management. Manage the port separately. That is, a port failure affects only the connection using the port, but a failure of the entire node affects all connections using the node. A failure of one port may affect a plurality of ports.

  For example, the node 90 of the network 5 illustrated in FIG. 18 includes ports 91 to 98, and when a failure occurs in the port 95 indicated by a black circle, the ports 91 and 92 are connected to the port 95. Connection # 1 and # 2 are affected.

  The device managers 81 to 83 collect node and port failure information by trapping or polling, and hold the maximum failure level among the failures occurring in the node or port as the failure level of the node or port. . If there is a change compared to the previous failure level, the information is notified to other objects as an event. In this case, in FIG. 17, the device management unit 81 for model A holds the maximum failure level 3, the device management unit 82 for model B holds the maximum failure level 2, and the device management unit for model C. 83 holds the maximum failure level 3.

  Also, the network configuration is managed, the failure level of each connection is extracted by the failure level change event of the node or port, and when there are failures in multiple nodes or ports through which the connection passes, the maximum level among them is determined as the connection failure. Level. When the failure level of this connection changes, an event is issued.

  FIG. 19 is a flowchart at the time of changing the failure level. About the devices constituting the network, the device management unit, the network management unit, the DB (database), the GUI (graphical user interface), and the event management unit The outline of the operation is shown. The device management unit has a function of absorbing differences in various types of failure information depending on the types of devices on the network. First, collection of network configuration information is requested to the DB by the operation of a user (network manager or service manager) of GU1. Based on the network configuration information from the DB, topology map display (physical network display) and service map display (logical network display) are performed.

  The DB requests the network management unit to collect network configuration information, and the network management unit transfers the network configuration information to the DB. Also, failure information is notified from the device to the device management unit by trapping or polling when a failure occurs. The device management unit extracts the failure level, determines the maximum failure level of the node, determines whether the maximum failure level is the same as the previous time, and notifies the event management unit of the change in the failure level of the node if it is different . If there is no change, the maximum port level is determined. Note that the failure determination of the node and the port is performed independently, and the failure determination of the port is performed even if the node changes.

  By the notification according to the change of the failure level, the event management unit notifies the GUI, DB, and network management unit of the change of the failure level of the node. Thereby, the GUI updates the topology map, the DB updates the database contents, and the network management unit determines the connection failure level and determines whether or not the failure level is the same as the previous time. If it is the same as the previous time, the link failure level is determined. If it is different from the previous time, the event management unit is notified of the connection failure level change. This process is repeated for the number of connections.

  The device management unit determines the maximum failure level of the port, determines whether or not it is the same as the previous time, ends if the same as the previous time, and notifies the event management unit of the port failure level change if different. Repeat this for the number of ports. The event management unit notifies each of the network management unit and the DB by a port failure level change notification. The DB updates the contents of the database, and the network management unit determines the failure level of the link, determines whether or not the failure level is the same as the previous time, ends if it is the same, and changes the link failure level if it is different. Notify the event manager. Thereby, since the event management unit notifies the DB and the GUI, the DB updates the database contents, and the GUI updates the topology map. A connection failure is also determined from a port failure.

  FIG. 20 is a flowchart for creating a multiple view. An overview of operations of the device management unit, the network management unit, the view management unit, the DB (database), the GUI (graphical user interface), and the event management unit is shown. The network manager or the service manager makes a view creation request to the view management unit through the GUI. As a result, the view management unit makes a collection request for network configuration information to the DB, extracts the view configuration according to the condition added to the view creation request based on the network configuration information from the DB, and extracts the extracted view configuration. Register in DB.

  When the DB notifies the view management unit of the end of view configuration registration, the view management unit notifies the GUI of the completion of view creation. The view management unit requests a view configuration registered in the DB, and performs topology map display (physical network display) and service map display (logical network display) according to the view configuration from the DB.

  When a node failure level change notification is sent from the device management unit to the event management unit, the event management unit notifies the network management unit, the view management unit, and the DB. The network management unit determines the connection failure level, determines whether it is different from the previous one, and if it is different from the previous connection failure level, notifies the event management unit of the connection failure level change.

  Further, the view management unit extracts a related view in response to a notification from the event management unit, and notifies the event management unit of a view node failure level change. By this view node failure level change notification, the event management unit notifies the GUI of the change of the topology map, and the GUI updates the topology map.

  Further, the network management unit determines the connection failure level based on the notification from the event management unit, determines whether or not it is different from the previous time, and if not, notifies the event management unit of the connection failure level change. The event management unit notifies the view management unit and the DB by this connection failure level change, and the view management unit extracts a related view, and notifies the event management unit of the view connection failure level change. The DB also updates the database contents.

  The event management unit notifies the GUI by a view connection failure level change notification from the view management unit, and the GUI updates the service map. If the network management unit determines that the connection failure level is the same as the previous level, the process ends.

  As a means for creating a view, (1) on the GUI (network configuration diagram screen) of the user (network administrator, service administrator), the view can be selected by selecting all the devices and lines to be registered in the view. create. The connection provided by the selected device and line is automatically extracted and registered in the view.

  (2). A user creates a view by selecting all the connections to be registered in the view in the connection list GUI of the network management system. Also, all devices and lines through which the selected connection passes are automatically extracted and registered in the view. (3) A unit creates a view by selecting all terminals (ports of network devices) to be registered for view in the GUI of the network management system. Also, all devices and lines that pass through all connections set between the selected terminals are automatically extracted and registered in the view. The corresponding connections, devices, and lines added during operation are also added to the view in real time.

  (4) A user creates a view by selecting an attribute condition of a connection to be registered in the view in the GUI of the network management system. The system automatically extracts all connections that match the conditions, and the devices and lines that pass through, and registers them in the view. The connection, device, and line added during operation are also added to the view in real time. (5) The user creates a view by selecting the name of the service to be registered in the view in the GUI of the network management system. The system also adds the connection, device, and line added during operation to the view in real time.

  (6) By specifying the edges (see FIG. 11 or FIG. 12) on both sides connected to the network, the user extracts the path and device between the edges and creates a view. Even for changes during system operation, the view registration contents are updated with reference to the DB.

  A user who creates a view by the means described above has the right to set / delete a connection used in the view update and view. A user (a network administrator or a service administrator) who has created a view corresponding to a single service or a plurality of services can arbitrarily refer to this view, and can designate other users who can refer to this view.

  In general, a network is composed of a plurality of vendor devices. In such a multi-vendor network environment, connection settings in a network of such a multi-vendor device do not always have the same parameter items set for each device. It will be. Therefore, the connection attributes to be set are defined for each service to be provided. This definition is performed based on a standardized standard such as the ITU-T standard.

  FIG. 21 is an explanatory diagram of a definition file in a multi-vendor device environment, and shows connection settings. A service definition file 101 is formed for a plurality of services 100. The service definition file is created based on the standard as described above. Then, the cross connection setting item definition files 104, 105, and 106 for each service type and model are created, and a conversion rule between the standard service definition file 101 and the cross connection setting item definition files 104, 105, and 106 is created. To do.

As described above, the cross-connect setting item definition files 104, 105, 106 are created for each service and model.
(A) Device 1
ServiceName = VOICE
QoS = 1
Assing = Peak
CR = 100
・
・
・
(B) Device 2
ServiceName = VOICE
ConnType = both
ServiceCategory = CBR
PriorityClass = hith
PCR CLP0 = 12
PCR CLP0 + 1 = 12
OAM = ON
・
・
・

  FIG. 22 is a schematic explanatory diagram when setting a cross-connect. At the time of setting a connection, the element access modules (EAM) 113 and 114 set a cross-connect to each node (NE) 115. Is composed of general common parameters such as the incoming side connection address and outgoing side connection address, and parameters specific to the device. Therefore, the element access modules 113 and 114 receive the common parameter and the service name from the upper component 111, and examine the individual parameter based on the service name. Since the individual parameters are managed in the database (DB) 112, the element access modules 113 and 114 can set a cross-connect using the common parameters and the individual parameters.

  FIG. 23 is a schematic explanatory diagram of individual parameter registration in the database (DB) 112 in FIG. 22, and the service definition file is composed of a common file 116 and individual files 117, 118, and 119 for each model. . One service definition common file 116 is provided in the system, and manages a service name and an explanation about the service. Also, the service definition individual files 117, 118, and 119 are prepared for each model, and when registered in the database (DB) 112, all the individual parameter information about the model that is the target of the service definition file is replaced.

The grammar of the service definition common file 116 is, for example, as follows.
statement: = definition-statement | comment-statement
definition-statement: = 'Service =' name ',' description
comment-statement: = '#' comment | blank line name: = character string description: = character string comment: = character string

Also, the definition of the service name and descriptive text about the service is as follows:
Service = name, description Service = name, description
・
For example,
Service = VOD, VOD service Service = Voice, voice service.

As for the comment sentence, a blank line or a line beginning with “#” is regarded as a comment line. The syntax for the service definition individual files 117, 118, and 119 is, for example,
statement: = selection-statement | definition-statement |
comment-statement
selection-statement: = 'ServiceName =' name
definition-statement: = key '=' value
comment-statement: = '#' comment | blank line name: = character string key: = character string value: = character string comment: = character string

  In addition, a selection sentence, a definition sentence, a comment sentence, and the like are also defined. The definition sentence in the selection sentence defines individual parameter values, and an element access module (EAM) defines a key for each model.

  FIG. 24 is a schematic explanatory diagram of cross-connect setting. When a network administrator or service administrator requests addition of a service definition from the GUI, there is a response from the database (DB) and notifies the event management unit of addition of service management. . Then, the event management unit makes a request corresponding to the service definition addition to the device management unit. Thereby, the device management unit makes a service definition acquisition request to the DB, and this DB sends the service definition to the device management unit.

  Also, a connection setting request is sent from the GUI to the network management unit. The network management unit determines a route corresponding to the connection setting request, and issues a cross-connect setting request to each device management unit along the route. The device management unit that has received this notification changes the parameters according to the service definition, performs cross-connect setting control for the device (cross-connect device), and the device management unit that has received the setting end notification receives the GUI via the network management unit. Notifies the end of cross-connect settings.

  FIG. 25 is an explanatory diagram of route setting, in which triangular marks 1 to 8 are edges, A to J in circles or square marks are nodes, and (a) to (k), (b) to (g) are A thin line indicates one link, and a thick line indicates a plurality of links. Displays the physical network configuration in such a view, for example, blue is not specified or not set, yellow is routed (details not set), orange is routed (details are set), and gray is routed Can be displayed by color coding.

  Note that “detailed setting” means that one of a plurality of links has been designated in the case of a link, but it has been designated in the case of one link. In the case of a node, all items of individual route attributes are set. In the case of an edge, it must be specified.

  Accordingly, in the initial state, nothing is set, and therefore, all are displayed in blue. When a path is set between the edges (1) and (7) in the case of P-P PVC (Point-to-Point Permanent Virtual Circuit), for example, the edge (1) is specified. As a result, the edge (1) is displayed in orange. Next, the node A to which the edge (1) is connected is designated. As a result, the link (a) is added to the route, the edge (1) and the link (a) are displayed in orange, and the node A is displayed in yellow that has been routed and has not been set in detail.

  Next, the node D of the route toward the edge (7) is designated. When the link (A) between the nodes A and D is designated, the outgoing port of the node A and the incoming port of the node D are automatically set based on the configuration information of the nodes A and D. ) Is displayed in orange, and node D is displayed in yellow.

  Similarly, nodes G and J are specified, links (K) and (K) are specified, a route from edge (1) to node (J) is set, and then edge (7) is specified. And link (j) is designated, the links (a), (b), (g), (j), (j) of the route from edge (1) to edge (7) and nodes A, D, When G and J are set in detail (orange) and the display content is confirmed and a cross-connect request is sent, cross-connect setting information according to the model of each node is sent based on the database. For example, to the node G, cross-connect setting information for connecting the links (K) and (K) is transmitted. Thereby, a path indicated by a chain line is set between the edges (1) and (7), and communication can be performed.

  For example, when the edge (7) is a VOD server, a service administrator for the VOD service can display a view of the VOD service and set a connection by the above-described processing based on the display content. Alternatively, edges (1) and (7) can be specified, and based on the network configuration information, a route that minimizes the number of nodes and links between edges (1) and (7) can be selected to set the connection. it can.

  Also, the route designation can be canceled. For example, when the route designation is canceled with the node G in the above-mentioned route as a base point, the link (ki), node G, link (co), node J, edge When the designation in (7) is canceled, the information on the outgoing port of node D is also cleared, and this node D is in a state in which details are not set. Therefore, the node D changes from orange display to yellow display. From this state, for example, the nodes F, I, G, and J can be sequentially specified, and the setting between the nodes (1) and (7) can be performed using a route different from the previous time.

  FIG. 26 is an explanatory diagram of path setting including a virtual link. In the case of P-P S-PVC path designation, the same reference numerals as those in FIG. 25 denote the same parts. For example, when the edge (1), the link (a), the node A, and the link (a) have been set in detail, S-PVC Calling is set in the path individual attribute of the node F, and then the node G is added to the path. There is no physical link between the nodes F and G, but a virtual link indicated by an orange dotted line is displayed.

  Then, as described above, the node J is designated, the link (G) between the nodes G and J is designated, the edge (7) is designated, and the link (j) is designated. The link and the node of the route to the edge (7) are connected by the route of (a) → A → (A) → F → (virtual link) → G → (co) → J → (j). become. When node I is specified instead of specifying node G, a physical link (d) exists between nodes F and I, but is displayed as an orange dotted line as a virtual link.

  When the route designation is canceled with the node G as a base point, only the designation on the S-PVC Called side is released. Accordingly, only the route including the edge (1), the link (a), the node (a), and the node F remains. When the route designation is canceled with the node F as a base point, the designations on both sides of S-PVC Calling and Called are canceled.

  FIG. 27 is an explanatory diagram of route setting including a branchable node. When a branchable node G is specified in a route indicated by a chain line between edges (1) and (7), this node G is used as a base point. Specify and select node I. In this case, the link between the nodes G and I is automatically set. From this state, for example, when the edge (5) is designated and the link (g) is designated, a path to the edge (1) is formed via the node I. Furthermore, when node B is designated with node G as a base point, a link (node) between nodes G and B is automatically set. Accordingly, a path is formed between the edges (1) and (7) by a chain line path, and a path branching from the node G in a plurality of directions can be set.

  The designation can be canceled in the same manner as described above. For example, when the node I is designated as the base point and the cancellation is performed, the portion on the edge (5) side from the node G is released. That is, the node I, the link (K), (g), and the edge (5) are released. Thereafter, other branch directions can be set.

It is an outline explanatory view of an embodiment of the invention. It is explanatory drawing of the physical network structure of the multiple view of embodiment of this invention. It is explanatory drawing of the database update of embodiment of this invention. It is component structure explanatory drawing. It is a system configuration figure by a component. It is explanatory drawing of an example of a database item. It is explanatory drawing of an example of an event and a database reconstruction item. It is explanatory drawing of a database structure. It is explanatory drawing of a database structure. It is explanatory drawing of a database item. It is a logical network configuration explanatory diagram. It is explanatory drawing of a trace display. It is explanatory drawing of a multiple view. It is explanatory drawing of a failure label and a failure level. It is explanatory drawing of failure level information. It is explanatory drawing of a failure label, a physical failure level, and a service failure level. It is explanatory drawing of the definition of a failure level. It is explanatory drawing of a failure and its influence range. It is a flowchart at the time of a failure level change. It is a flowchart of multiple view creation. It is explanatory drawing of the definition file in a multi-vendor apparatus environment. It is outline | summary explanatory drawing at the time of cross-connect setting. It is an outline explanatory view of individual parameter registration. It is an outline explanatory view of cross connection setting. It is explanatory drawing of route setting. It is explanatory drawing of the route setting containing a virtual link. It is explanatory drawing of the route setting containing a branch possible node.

Explanation of symbols

DESCRIPTION OF SYMBOLS 1 Service management server 1-1 View definition part 1-2 Logical network block diagram creation part 1-3 Connection setting part 1-4 Real-time network configuration information update part 1-5 Coordination part of physical failure and logical network failure 2 Database 3-1 to 3-3 Network management server 4-1 to 4-4 Client corresponding to service type 5 Network

Claims (8)

Associating network configuration information with view configuration information in correspondence with at least one service type, and creating a view capable of displaying either or both of a physical network configuration and a logical network configuration;
A process of converting the failure information depending on the device collected from at least one network device to be managed based on the failure label and the level of failure to be unified in the entire network,
A network management method comprising: displaying a failure level for each service provision based on the converted failure label and the failure level. A process for managing network device failures by converting device-dependent failure information into device-independent information by converting them into failure labels, physical failure levels, and service failure levels that are unified throughout the network, and
Managing different types of networks as local domains corresponding to types, and managing the physical network configuration and the logical network configuration as a network of the same type as the plurality of local domains as one multi-domain,
Creating a view capable of displaying either one or both of the physical network configuration and the logical network configuration by associating the network configuration information with the view configuration information in correspondence with at least one service type. Network management method.   3. The method according to claim 1, further comprising: associating a failure label corresponding to a failure occurrence location with a failure level of a physical failure and a service failure and displaying the failure level in association with the view. The network management method described.   2. The process according to claim 1, further comprising: managing fault information in units of nodes or ports of a network, and managing a fault level having the highest fault level at a fault occurrence location via a connection as the fault level of the connection. Network management method.   2. The network management method according to claim 1, further comprising a step of designating a node and a link in the physical network configuration and setting a path between edges.   A step of designating edges in the physical network configuration, extracting nodes and links of paths between the edges based on network management information between the edges, and setting paths between the edges. The network management method according to claim 1. A database that stores network configuration information and view configuration information in association with each other;
A service management server that performs display control based on one or both of physical network configuration information and logical network configuration information corresponding to a service type in the view configuration information stored in the database;
A network management server that manages the same type of network as a local domain by associating failure information depending on devices collected from at least one network device to be managed with failure labels, physical failure levels, and service failure levels; With
The service management server manages local domains that manage different networks so that they are network-independent corresponding to types, and manages the physical network configuration and the logical network configuration with these multiple local domains as one multi-domain. A network management system characterized by that.   The service management server includes a connection setting unit that specifies an edge or a node and a link based on contents according to physical network configuration information and controls connection setting between the edges. 8. The network management system according to 7.

Images