Network design support device, network design support method, and network design support program

Abstract

To provide a device and a method which can reduce a network design period to meet a communication requirement.SOLUTION: A network design support device includes a storage unit, a design unit, and a collation unit. The storage unit stores: design rules which describe application conditions and design contents which meet the application conditions; customer policies which define network functions according to the network operation policies of customers; and configuration information which represents physical network configurations. The design unit designs a logical network, in which logical modules are arranged in a communication path, for a communication path designated by a communication requirement given from the customer, using the customer policy and the design rule. The collation unit collates the logical network designed by the design unit with the physical network represented by the configuration information, so as to determine whether or not the logical network can be actualized using the physical network.SELECTED DRAWING: Figure 7

Description

[Technical Field]

[0001] The infrastructure that supports digital business requires speed to quickly deploy new services and expand existing services. For example, in the enterprise domain, dynamic deployment of server infrastructure using virtual machines (VMs) and container technology is becoming common, but building and modifying network infrastructure still relies on manual labor, which makes it difficult to say that it achieves the speed required for digital business. In other words, manual network integration is slow and may hinder the expansion of digital business.

[0002] For this reason, a technology has been proposed that receives the requirements a user has for a network in order to provide a service, quickly designs a network that meets those requirements, and automatically derives the settings for each network device required to realize the designed network. Examples of requirements a user might have for a network in order to provide a service include "only allow HTTP (Hyper Text Transfer Protocol) communication between business applications" and "deliver video at 1 Mbps." In the following description, these requirements may be referred to as "communication requirements."

[0003] In recent years, a technique for deriving the settings for devices to realize the network required for communication requirements has been adopted, in which setting functions are developed in advance for each user's communication requirements and network configuration (e.g., topology, device model number, OS (Operating System), functions, etc.), and each device is configured using those functions.

[0004] For example, in a network where three devices - a client terminal, a firewall, and a web server - are connected, if you want to "only allow HTTP communication between the user terminal and the web server," you can develop functions in advance to perform the following: "1. Set a routing table on the client terminal," "2. Set a routing table on the firewall," "3. Set a routing table on the web server," and "4. Set access permission to the web server on the firewall." By doing so, you can make the necessary settings on each device simply by executing these functions.

[0005] A method has been proposed for supporting the design and configuration of a network based on a user's communication requirements (for example, Patent Document 1). [Prior art documents] [Patent documents]

[0006] [Patent Document 1] Patent Publication No. 2021-136692 Summary of the Invention [Problem to be solved by the invention]

[0007] However, the communication requirements of users are becoming more diverse. Therefore, in order to provide different designs and settings for each user, it is necessary to create a design module for each user. Alternatively, it is necessary to change the combination of design modules for each user. As a result, it may not be possible to quickly design a network that meets the user's requirements.

[0008] An object of one aspect of the present invention is to provide an apparatus and method that can shorten the construction period for designing a network that meets communication requirements. [Means for solving the problem]

[0009] A network design support device according to one aspect of the present invention is a device for designing a network function in accordance with application conditions, design rules describing design contents corresponding to the application conditions, and a customer's network operation policy. and the management method a storage unit for storing configuration information representing a customer policy and a physical network configuration; a classification unit that classifies the customer policy into a first policy that is independent of an application device and a second policy that is dependent on an application device; For the communication path specified by the communication requirements given by the customer, 1st a design unit that uses a policy and the design rules to design a logical network in which logical modules are arranged within the communication path; and a comparison unit that compares the logical network designed by the design unit with a physical network represented by the configuration information to determine whether the logical network can be realized using the physical network; an application unit that updates a design of the logical network by further applying the second policy to the logical network after the collation unit determines that the logical network can be realized using the physical network; Equipped with. [Effects of the Invention]

[0010] According to the above-described aspect, it is possible to shorten the construction period for designing a network that meets communication requirements. [Brief explanation of the drawings]

[0011] [Figure 1] FIG. 2 is a diagram illustrating an outline of the operation of the network design support device. [Figure 2] FIG. 1 is a diagram illustrating the design of a logical network. [Figure 3] FIG. 10 is a diagram illustrating an example of matching between a designed logical network and an actual network. [Figure 4] FIG. 10 is a diagram illustrating an example of how settings are reflected in a real network. [Figure 5] FIG. 1 is a diagram for explaining an outline of a network design that takes into account customer policies. [Figure 6] FIG. 10 is a diagram illustrating an example of a customer policy. [Figure 7] FIG. 10 is a diagram illustrating an example of classification of customer policies. [Figure 8] FIG. 10 is a diagram illustrating an example of a method for reducing the amount of description of a customer policy. [Figure 9]FIG. 10 is a diagram illustrating an example of a description method for a customer policy. [Figure 10] FIG. 10 is a diagram illustrating an example of application of a customer policy. [Figure 11] FIG. 1 is a diagram illustrating an example of a functional configuration of a network design support apparatus according to an embodiment of the present invention. [Figure 12] FIG. 2 is a diagram illustrating an example of design rules and configuration information of an actual network. [Figure 13] FIG. 4 is a diagram illustrating an example of a customer policy used in the first embodiment. [Figure 14] FIG. 1 is a diagram illustrating a first step of a network design support method. [Figure 15] FIG. 10 is a diagram illustrating a second procedure of the network design support method. [Figure 16] FIG. 10 is a diagram illustrating an example of information generated from communication requirements. [Figure 17] FIG. 10 is a diagram illustrating step 3 of the network design support method. [Figure 18] FIG. 10 is a diagram illustrating an example of a logical design based on a customer policy. [Figure 19] FIG. 10 is a diagram illustrating step 4 of the network design support method. [Figure 20] FIG. 1 is a diagram illustrating an example of a logic design based on design rules. [Figure 21] FIG. 10 is a diagram illustrating step 5 of the network design support method. [Figure 22] FIG. 10 is a diagram illustrating step 6 of the network design support method. [Figure 23] 1 is a flowchart showing an example of a network design support method according to a first embodiment of the present invention. [Figure 24] FIG. 10 illustrates an example of a customer policy including device-dependent granular policies. [Figure 25] FIG. 10 is a diagram illustrating commonality of detailed policies. [Figure 26] FIG. 10 is a diagram illustrating an outline of the operation of the second embodiment. [Figure 27] FIG. 10 is a diagram illustrating an example of a functional configuration of a network design assistance apparatus according to a second embodiment. [Figure 28] FIG. 1 is a diagram (part 1) showing an example of policy classification and common element extraction. [Figure 29] FIG. 2 is a diagram (part 2) showing an example of policy classification and common element extraction. [Figure 30] FIG. 10 is a diagram (part 3) showing an example of policy classification and common element extraction. [Figure 31] FIG. 4 is a diagram (part 4) showing an example of policy classification and common element extraction. [Figure 32] FIG. 5 is a diagram (part 5) showing an example of policy classification and common element extraction. [Figure 33] FIG. 10 is a diagram illustrating a procedure 3 of the network design support method according to the second embodiment. [Figure 34] FIG. 10 is a diagram illustrating an example of a logical design based on a customer policy. [Figure 35] FIG. 10 is a diagram illustrating a procedure 4 of the network design support method according to the second embodiment. [Figure 36] FIG. 1 is a diagram illustrating an example of a logic design based on design rules. [Figure 37] FIG. 10 is a diagram illustrating a procedure 5 of the network design support method according to the second embodiment. [Figure 38] FIG. 10 is a diagram illustrating a sixth step of the network design support method according to the second embodiment. [Figure 39] FIG. 10 is a diagram illustrating an example of a result of a logical design to which a detailed policy is applied. [Figure 40] FIG. 10 is a diagram illustrating a seventh procedure of the network design support method according to the second embodiment. [Figure 41] 10 is a flowchart showing an example of a network design support method according to a second embodiment of the present invention. [Figure 42] FIG. 2 illustrates an example of a hardware configuration of a network design support apparatus. DETAILED DESCRIPTION OF THE INVENTION

[0012] Figure 1 shows an overview of the operation of a network design support device. In recent years, changing business needs have led to the need to design networks that meet new communication requirements in order to provide new services. Furthermore, changes in network configurations are also expected due to factors such as network expansion as business expands or failures in network equipment. However, creating configuration functions from scratch to accommodate new communication requirements and network configurations may not be able to quickly reflect the user's business needs.

[0013] Therefore, the network design support device 1 realizes a network design / configuration method that can shorten the time required to respond to new communication requirements and network configurations by separating processing that depends on the network configuration from processing that does not. Specifically, the network design support device 1 has a function to design a logical network from communication requirements and a function to design the required physical network by comparing the designed logical network with the actual network.

[0014] For example, when the network design support device 1 receives a communication requirement from a user such as "I want to access a Web server securely," it designs a logical network that combines logical modules corresponding to each condition to be set in the communication path. Next, the network design support device 1 verifies the correspondence between the physical network (hereinafter sometimes referred to as the "real network") configured using each physical module and the logical network designed using each logical module.

[0015] In this way, the network design support device 1 executes a design that takes into account the actual network. Based on this design, the network design support device 1 issues configuration commands to each physical module that constitutes the actual network, such as client terminals (hereinafter, sometimes simply referred to as "clients"), firewalls (FW), and web servers, to set and update parameters. In this way, a network configuration that satisfies the logical network is generated on the actual network.

[0016] Figure 2 is a diagram illustrating the design of a logical network. As shown in Figure 2, the "logical network design" executed by the network design support device 1 derives, from the customer's communication requirements, the logical nodes required to satisfy the communication requirements, the connections between the logical nodes, and the combination and arrangement of network functions required for each logical node or connection. For example, the network design support device 1 divides the network design into multiple design modules and combines the multiple design modules according to the communication requirements, thereby realizing the design of a logical network that satisfies a wide variety of communication requirements.

[0017] A design module is information that turns the know-how of experts into rules, and represents the conditions for applying the rules and the design content when they are applied. For example, in the case of a "module that realizes secure access," the application condition "secure access is required" is associated with the design content "provide a logical node with access control functionality between the source and destination." Also, the application condition "access to the destination is required" is associated with the design content "provide routing functionality in all nodes between the source and destination."

[0018] When the network design support device 1 is equipped with such design modules, and given a communication requirement of "allowing only HTTP communication from the client to the web server and accessing it via a fixed route," the device applies the design modules according to the above-mentioned rules. This derives the requirement that "a node with access control functionality is required between the client and the web server, and each node must have a static routing function." In this way, by combining design modules, it becomes possible to design logical networks that meet a wide variety of communication requirements.

[0019] 3 shows an example of matching between a designed logical network and a real network. The "matching with a real network" performed by the network design support device 1 is a process of determining, based on the configuration information of the real network, which physical network devices will actually implement the logical nodes and required network functions derived in the logical network design. The configuration information of the real network indicates the network devices present in the target network, their connection relationships, a list of network functions available in each device, the settings of the functions enabled in each device, etc.

[0020] In the matching process, the network design support device 1 first lists all patterns (i.e., communication paths) that allow communication from the source to the destination based on the configuration information of the actual network. Then, the network design support device 1 determines a communication path that satisfies the results of the logical design.

[0021] In the example shown in Figure 3, the network design support device 1 is assumed to have identified a "source having client and routing functions," a "node having access control and routing functions," and a "destination having web server and routing functions" as a result of a logical design that satisfies the communication requirements. Next, the network design support device 1 refers to the configuration information of the real network and identifies that the real network is composed of "a client having routing functions, a router having routing functions, a firewall having routing and access control functions, and a web server having routing functions." Furthermore, the network design support device 1 is assumed to have identified communication path 1 "client, firewall, web server" and communication path 2 "client, router, web server."

[0022] In this case, for communication path 2, the router installed between the client and the web server does not have an access control function. In other words, communication path 2 does not satisfy the results of the logical design. Therefore, communication path 2 is not selected. On the other hand, for communication path 1, the firewall installed between the client and the web server has an access control function and a routing function. In other words, communication path 2 satisfies the results of the logical design. Therefore, communication path 1 is selected by comparing the logical network represented by the results of the logical design with the actual network.

[0023] In this way, before starting logical network design, the network design support device 1 manages information on a list of network functions available to each device as configuration information of the actual network. Then, by comparing the network functions available to the devices on each communication path between the source and destination with the required network functions derived in the logical design, it is determined whether each communication path satisfies the results of the logical design. As a result, the network design support device 1 determines the device (deployment destination) on which each network function will actually be enabled.

[0024] Figure 4 shows an example of reflecting the settings to the actual network. Based on the deployment destination information determined by comparing it with the actual network, the network design support device 1 derives the settings for each device to enable the required network functions, and sets the derived settings to the corresponding devices. This achieves a network that meets the communication requirements. At this time, the network design support device 1 determines the setting items and parameters required for each network function, and determines the values ​​of each parameter based on the input communication requirements and configuration information such as the address information of each device.

[0025] For example, it is assumed that the deployment destination is determined as shown in FIG. 4 by comparing with the actual network. In this case, the network design support device 1 determines that the firewall to which the logical node derived in the logical design is assigned needs an access control function and that an access control list (ACL) needs to be set to enable the function. The network design support device 1 also determines that each device needs a routing function and that a routing table needs to be set to enable the function, and that parameters such as those shown in FIG. 4 need to be determined to set them. For example, in the case of a routing table, it is necessary to determine a destination (Dest) and the address of a router (next hop) that will be the next communication destination. Then, the setting contents shown in FIG. 4 are determined using the Internet Protocol (IP) address of the interface of each device, etc. Note that the setting items set in each device may be commonly used setting items, and the commands for setting them may also be commonly used setting items.

[0026] FIG. 5 is a diagram illustrating an outline of network design that takes customer policies into consideration. The network design support device 1 designs a network according to the communication requirements of the customer. In this case, as shown in FIG. 5(a), the network design support device 1 can design a network that meets the communication requirements by using a general-purpose design module and a design module created for each customer. However, in recent years, customer requests have become more diverse, and creating a design module for each customer requires a lot of effort.

[0027] Therefore, in an embodiment of the present invention, a network that meets communication requirements is designed using a customer policy, as shown in Fig. 5(b). The customer policy describes the network functions and / or management methods in accordance with the customer's network operation policy.

[0028] Figure 6 shows an example of a customer policy. In this example, two data centers (DC1 and DC2) are connected via a network. Each data center is equipped with a core router, an edge router, a border router, and a server. The customer policy includes a system definition, devices to be traversed, a routing policy, an access restriction policy, and a route distribution restriction policy.

[0029] The network design support device 1 interprets the contents of the customer policy and operates the design module in accordance with the contents of the customer policy. Therefore, there is no need to create a design module for each customer, and customer requests can be quickly met.

[0030] However, when trying to accommodate a wide variety of customer policies, the function for interpreting and applying the customer policies may become complicated. Furthermore, when the amount of description in the customer policy is large, the function for interpreting and applying the customer policy may also become complicated. Therefore, it is preferable to classify the multiple policies included in the customer policy by type and to provide a function for interpreting and applying the policy for each type. Furthermore, it is preferable to make the policy easier to reuse and reduce the amount of policy by devising a method for describing the policy.

[0031] FIG. 7 shows an example of classification of customer policies. In this embodiment, customer policies are classified into three types. Type 1 relates to a policy that adds a logical node. For example, this corresponds to a function that specifies a communication path between a source node and a destination node. Type 2 relates to a policy that adds a function and / or a role to a logical node. For example, this corresponds to adding an access control function, a filter function, or a route aggregation function. Type 3 relates to a policy that adds a function and / or a role to a connection between nodes. For example, this corresponds to adding a routing function between devices or a network virtualization function.

[0032] The network design support device 1 can interpret a given customer policy and classify multiple policies included in the customer policy into corresponding types. Here, the network design support device 1 is equipped with a "design module that interprets the customer policy" corresponding to each type. Furthermore, when adding a policy, the design module that applies the customer policy can be reused for each type.

[0033] In the example shown in Figure 7, the given customer policy contains three policies. The first policy adds a logical node between the source node (client) and the destination node (web server). This process corresponds to specifying the communication path between the source node and the destination node. The second policy adds an access control function to the added logical node. This process corresponds to setting up a firewall between the source node and the destination node. The third policy adds a routing function between the nodes.

[0034] FIG. 8 shows an example of a method for reducing the amount of description of a customer policy. In this example, the customer policy includes a policy between terminals X and Y, a policy between terminals X and Z, and a policy between terminals Y and Z, as shown in the upper part of FIG. 8. Here, if the amount of description of a policy is large, the process of designing a network taking the policy into consideration becomes complicated. Therefore, it is preferable that the amount of description of the customer policy is reduced so that it can be easily processed. Furthermore, if the customer policy includes multiple policies, it is preferable that the processing corresponding to each policy can be reused in processing by other policies. Therefore, it is preferable that the customer policy is described, for example, as shown in the lower part of FIG. 8.

[0035] Specifically, the design / configuration details are defined so as not to include information about the devices to which they apply. Then, linking information is created that indicates which communication domain each individual design / configuration detail applies to. At this time, the devices are grouped. For example, terminals X, Y, and Z are described as "terminals," firewalls FW1 and FW2 are described as "FWs," and border routers L, M, and N are described as "border routers." Policies related to devices and connections between devices are then described as device groups and connection policies between device groups.

[0036] For example, a path between terminals X and Y is required to pass through firewall FW1, and a path between terminals Y and Z is required to pass through firewall FW2. Here, if the two firewalls FW1 and FW2 are referred to as "FW" without distinction, these two requirements can be described as "passing through the FW." Also, a path between terminals X and Y is required to pass through two border routers L and M, a path between terminals X and Z is required to pass through two border routers L and N, and a path between terminals Y and Z is required to pass through two border routers M and N. Here, if the three border routers L, M, and N are referred to as "border routers" without distinction, these three requirements can be described as "passing through two border routers." The same applies to other policies.

[0037] For communication between terminals X and Y, "pass through firewall FW1," "pass through border routers L and M," and "pass through the virtual network with setting a" are required. Therefore, for communication between terminals X and Y, "(1) pass through the firewall," "(2) pass through two border routers," and "(3) pass through the virtual network with setting a" are linked. The same is true for communication between terminals X and Y. In contrast, for communication between terminals Y and Z, "pass through border routers M and N" and "pass through the virtual network with setting a" are required, but a firewall is not required. Therefore, for communication between terminals Y and Z, only "(2) pass through two border routers" and "(3) pass through the virtual network with setting a" are linked.

[0038] The description in the format shown in the lower part of Fig. 8 is created by, for example, a network designer (human). Alternatively, the description in the format shown in the upper part of Fig. 8 may be interpreted by a computer and converted into the description in the format shown in the lower part of Fig. 8. In either case, by describing the customer policy in this format, the volume of the customer policy can be reduced.

[0039] FIG. 9 shows an example of a description method for a customer policy. In this embodiment, the customer policy is described using "Group," "Policy," and "Apply." Group defines the group to which a device belongs and specifies the devices that belong to each group. Policy defines the design / configuration content. Specifically, a policy is composed of the type of design / configuration content and its content (including configuration parameters, etc.). Furthermore, the type of design / configuration content is composed of, for example, "topology," "virtualizing," and "routing." Topology specifies the devices to be traversed. Virtualization specifies the virtualized network to be traversed. Routing specifies the type of routing to be used for communication. Apply represents the association for applying the design / configuration content to devices and connections between devices.

[0040] The description in Figure 9 represents the customer policy shown in Figure 8. That is, in "Group," it is shown that the terminal group includes terminals X, Y, and Z, the firewall group includes firewalls FW1 and FW2, and the border router group includes border routers L, M, and N. In "Policy," for example, "Topology" and "Group: Firewall Group" are described for "Pass Through FW." "Topology" means the addition of a logical node. Also, "Group: Firewall Group" means that the logical node to be added is a firewall. The same applies to other elements. In "Application," for example, "Policy: Pass Through FW" and "Target" are described for "Linking Between Terminal X and Terminal," and "from: Terminal X" and "to: Terminal Group" are described as "Target." In this description, "Pass Through FW," as explained earlier, means that a firewall is installed on the communication path from Terminal X to the terminal group. The same applies to other elements.

[0041] Figure 10 shows an example of application of a customer policy. In this embodiment, the customer policy shown at the bottom of Figure 8 or shown in Figure 9 is assumed to be given. Also, the design / configuration of a logical network that realizes communication from terminal X to terminal Y will be explained. In this case, processing starts from the initial state shown in Figure 10(a).

[0042] Policies 1 to 3 shown in Figure 8 are applied to communication between terminal X and terminal Y. Policy 1 represents "passing through a firewall," and its type is "topology," as shown in Figure 9. In this case, a logical node corresponding to the firewall is added. Policy 2 represents "passing through two border routers," and its type is "topology," as shown in Figure 9. In this case, two logical nodes corresponding to the two border routers are added. Policy 3 represents "passing through a virtual network with setting a," and its type is "virtualization." Furthermore, as shown in Figure 9, the target of this policy is the connection between terminal groups, which in this case corresponds to the connection between terminal X and terminal Y. Therefore, by applying policies 1 to 3, the state shown in Figure 10(b) is obtained.

[0043] Policy 4 represents "static communication" and its type is "routing." As shown in Figure 9, the target of this policy is the connection between the terminal group and the border router group, which corresponds to the connection between terminal X and the border router and the connection between terminal Y and the border router. Therefore, applying policy 4 results in the state shown in Figure 10(c).

[0044] Policy 5 represents "communication using BGP with setting 1" and its type is "routing." Although not shown, the target of this policy is the connection between border router groups. Therefore, applying policy 5 results in the state shown in Figure 10(d). After this, a general-purpose design module is applied to this logical network.

[0045] 11 shows an example of the functional configuration of a network design support device 1 according to an embodiment of the present invention. The network design support device 1 includes a storage unit 10, a control unit 20, and a communication unit 30. Note that the network design support device 1 may include other functions not shown in FIG.

[0046] The storage unit 10 is an example of a storage device that stores various data and programs executed by the control unit 20, and is realized by, for example, a memory or a hard disk. The storage unit 10 can store design rules, customer policies, configuration information of the actual network, design results, and the like.

[0047] A design rule is information composed of a set of "application conditions" and "design content." The "application conditions" define the conditions for applying the design rule. The "design content" defines the specific content to be set in the physical module when the design rule is applied. In an embodiment of the present invention, general-purpose design rules that are independent of customers are created in advance and stored in the storage unit 10. Note that when multiple design rules are combined, information indicating the order in which the design rules are applied may be included.

[0048] The customer policy defines the network functions and / or management methods according to the customer's network operation policy. The customer policy may be written by the customer itself or by a network designer. The customer policy is preferably coded, for example, as shown in Figures 8 and 9.

[0049] The configuration information of a real network includes information related to network devices present in the network to be configured, information indicating their connection relationships, information indicating the network functions available to each device, and information indicating the current settings of each device. For example, the configuration information of a real network defines, for each device, an identifier, a list of available network functions, the settings of each enabled function, address information for each interface, and information for access required to reflect the settings (such as address information for the management interface). It also includes information on the presence or absence of connections between devices or between the interfaces of each device.

[0050] The design result represents the design result of the logical network designed by the network design support device 1. For example, the design result represents logical nodes and logical ports, the connections between them, network functions, and the requirements and constraints that they should have. The design result may also include information such as the network functions required for each logical node, logical port, and connection relationship, as well as identifiers that represent their deployment locations.

[0051] The control unit 20 is realized by, for example, a processor in order to control the operation of the network design support device 1. The control unit 20 includes a receiving unit 21, a design unit 22, a collating unit 23, and a setting reflecting unit 24. The receiving unit 21, the design unit 22, the collating unit 23, and the setting reflecting unit 24 may be realized as an example of an electronic circuit included in a processor, or as an example of a process executed by a processor.

[0052] The receiving unit 21 receives communication requirements provided by a client and requests the design unit 22, the collating unit 23, and the setting reflecting unit 24 to execute corresponding processing. For example, the receiving unit 21 receives the communication requirements via a command base or a GUI (Graphical User Interface). The receiving unit 21 then stores the received communication requirements in the storage unit 10 and can issue instructions to the processing units 22 to 24.

[0053] The design unit 22 designs a logical network in which logical modules corresponding to communication conditions to be set in the communication path, which are specified based on the communication requirements and customer policy, are placed in the communication path. Specifically, the design unit 22 designs a logical network that satisfies the communication requirements and customer policy, and stores the design results in the storage unit 10. The logical modules include logical nodes, logical ports, connections between logical nodes or logical ports, and functional elements.

[0054] The collation unit 23 verifies the correspondence between the physical network configured using each physical module and the logical network designed using each logical module. Specifically, the collation unit 23 designs a network that satisfies the results of the logical design based on information representing the design results (i.e., the results of the logical design) and configuration information of the actual network, and stores the results of the design in the storage unit 10.

[0055] The setting reflecting unit 24 executes various settings for the corresponding physical module according to the collation result by the collation unit 23. That is, the setting reflecting unit 24 determines the setting contents based on the information (deployment destination) representing the design result, and sets the settings for each network device. Note that the settings for each network device can use functions, commands, etc. that are used for setting general network devices.

[0056] The communication unit 30 is a processing unit that controls communication with other devices, and is realized by, for example, a communication interface. The communication unit 30 may establish communication with a user terminal via a web browser and receive communication requirements, or may receive communication requirements from the user terminal using a command or the like. The communication unit 30 may also send a command or the like to each physical module that constitutes the physical network.

[0057] First Embodiment The network design support device 1 has the functions shown in Fig. 11. That is, the network design support device 1 includes a receiving unit 21, a design unit 22, a collating unit 23, and a setting reflecting unit 24. The storage unit 10 also stores design rules, customer policies, and configuration information of the actual network.

[0058] FIG. 12(a) shows an example of design rules stored in the storage unit 10. As described above, a design rule is composed of application conditions and design content. In this embodiment, two rules are defined. FIG. 12(b) shows an example of configuration information of a real network. In this embodiment, the real network includes terminals (X, Y, Z) and border routers (L, M, N).

[0059] Fig. 13 shows an example of a customer policy used in the first embodiment. As described above, the customer policy is composed of "group," "policy," and "application." The customer policy is stored in the storage unit 10 shown in Fig. 11.

[0060] FIG. 14 shows step 1 of the network design support method. In step 1, the receiving unit 21 receives communication requirements from a customer. As described above, the communication requirements represent requirements that are required of a network in order to provide a service. In this embodiment, the communication requirement is "I want to communicate from terminal X to terminal Y."

[0061] 15 shows step 2 of the network design support method. In step 2, the receiving unit 21 records the received communication requirements as part of the information representing the design result. The receiving unit 21 also requests the design unit 22 to perform a logical design based on the communication requirements.

[0062] Here, the receiving unit 21 may convert the input communication requirements into information in a different format. For example, the communication requirements may be expressed using "identifiers" and "constraints" as shown in FIG. 16. In this case, based on the input communication requirement "I want to communicate from terminal X to terminal Y," the receiving unit 21 sets "terminal X" as the source identifier, sets "terminal Y" as the destination identifier, and generates information in which "terminal X" and "terminal Y" are set as the connection source and destination, respectively. That is, the network design assistance device 1 manages information (communication conditions) indicating that a device with an identifier "terminal X" is the source and a device with an identifier "terminal Y" is the destination. The source and destination are each treated as logical nodes in the logical design, and the device identifiers are managed as information corresponding to the devices in the actual network.

[0063] Fig. 17 shows step 3 of the network design support method. In step 3, the design unit 22 performs logical design based on the customer policy. That is, the design unit 22 proceeds with the design of the logical network based on the information representing the communication requirements shown in Fig. 16 and the policy of customer A. A specific description will be given below with reference to Fig. 18.

[0064] Based on the communication requirement "I want to communicate from terminal X to terminal Y," the design unit 22 refers to "Application" of the customer policy shown in Fig. 13. First, "Application: 1" of the customer policy describes the connection between terminal X and terminal Y, and the policies to be applied are "1" and "2." Therefore, the design unit 22 applies policy 1 and policy 2.

[0065] Since the type of policy 1 is "transit device", the addition of a logical node is executed. At this time, since the parameter of policy 1 is "border router L", border router L is added as a logical node. Similarly, by applying policy 2, border router M is added as a logical node. Therefore, the description shown in Figure 18(b) is obtained. Note that "apply: 2-3" is skipped because it does not relate to the connection between terminal X and terminal Y.

[0066] Next, the connection between terminal X and border router L is described in "application: 4" of the customer policy, and the connection between terminal Y and border router M is described in "application: 5" of the customer policy, and the policy to be applied is "4" in both cases. Therefore, the design unit 22 applies policy 4.

[0067] Since the type of policy 4 is "routing", a function or role is added. At this time, since the parameter of policy 4 is "protocol: fixed route", information is generated to indicate that communication will be performed via fixed routes between terminal X and border router L, and between border router M and terminal Y. Therefore, the description shown in Figure 18(c) is obtained. Note that "Apply: 6" is skipped because it is not related to the connection between terminal X and terminal Y.

[0068] Furthermore, the connection between the border router L and the border router M is described in "application: 7" of the customer policy, and the policy to be applied is "5." Therefore, the design unit 22 applies policy 5.

[0069] Since the type of policy 5 is "routing," a function or role is added. At this time, since the parameters of policy 5 are "protocol: BGP, setting 1," information is generated to indicate that BGP communication with setting 1 will be performed between border router L and border router M. Therefore, the description shown in FIG. 18(d) is obtained. Note that "Apply: 6-7" is skipped because it is not related to the connection between terminal X and terminal Y.

[0070] The logical network obtained by applying policies 1, 2, 4, and 5 is as shown in the lower part of Fig. 17. Then, the design unit 22 stores the results of the logical design at this point in the storage unit 10.

[0071] 19 shows step 4 of the network design support method. In step 4, the design unit 22 proceeds with the design of the logical network using the logical design results generated in step 3 and the design rules stored in the storage unit 10, and stores the results in the storage unit 10. The design unit 22 also requests the collation unit 23 to determine the deployment destination. In this embodiment of the present invention, general-purpose design rules that are independent of the customer are created in advance and stored in the storage unit 10.

[0072] Specifically, the design unit 22 first proceeds with the logical design in accordance with the design rules shown in FIG. 12(a). Design rule 1 adds a "static routing function" to the nodes at both ends of a connection for which "communication via a fixed route" is set. Here, according to the description in FIG. 20(a), "communication via a fixed route" is set for the connection between terminal X and border router L. Therefore, a constraint that "has a static routing function" is added to each of terminal X and border router L. Also, "communication via a fixed route" is set for the connection between border router M and terminal Y. Therefore, a constraint that "has a static routing function" is added to each of border router M and terminal Y. As a result, the description in FIG. 20(b) is obtained.

[0073] Design rule 2 adds "BGP function" to the nodes at both ends of a connection for which "communication via BGP" is set. Here, according to the description in Figure 20(a) or Figure 20(b), "communication via BGP with setting 1" is set for the connection between border router L and border router M. Therefore, "BGP function with setting 1" is added to border router L and border router M, respectively. As a result, the description in Figure 20(c) is obtained.

[0074] The logic network obtained by applying design rules 1 and 2 is as shown in the lower part of Fig. 19. Then, the design unit 22 stores the result of the logic design at this point in the storage unit 10.

[0075] 21 shows step 5 of the network design support method. In step 5, the collation unit 23 determines the deployment destination of each function by comparing the logical design result obtained in step 4 with the configuration information of the actual network stored in the storage unit 10. Next, the collation unit 23 stores information indicating the deployment destination in the storage unit 10 as information indicating the design result. Furthermore, the collation unit 23 requests the setting reflection unit 24 to configure the physical network devices.

[0076] Specifically, the collation unit 23 first extracts all communication paths from the source terminal X to the destination terminal Y from the configuration information of the real network. In this example, the configuration of the real network is as shown in FIG. 12(b). Therefore, a communication path from terminal X to terminal Y via border routers L and M is extracted. Next, the collation unit 23 compares each logical node on the logical network designed by the design unit 22 with each device on the communication path extracted from the real network. In this example, it is determined whether or not four conditions are satisfied: "Terminal X has a static routing function," "Border router L has a BGP function of setting 1 and a static routing function," "Border router M has a BGP function of setting 1 and a static routing function," and "Terminal Y has a static routing function." If the communication path extracted from the real network satisfies all of the above conditions, the collation unit 23 determines that the logical network designed by the design unit 22 can be realized on the real network.

[0077] 22 shows step 6 of the network design support method. In step 6, the setting reflecting unit 24 performs setting on the corresponding device on the real network based on the collation result obtained in step 5.

[0078] Specifically, the setting reflecting unit 24 sets a route table for realizing routing from terminal X to terminal Y in terminal X, border router L, border router M, and terminal Y, and instructs these network devices to enable their routing functions. The setting reflecting unit 24 also sets various parameters for realizing BGP communication in border router L and border router M, and instructs these network devices to enable their BGP functions. In this way, the setting reflecting unit 24 configures the physical modules so as to correspond to the configuration of the logical network designed based on the communication requirements and customer policies, thereby building the communication paths required by the customer on the physical network.

[0079] 23 is a flowchart showing an example of a network design support method according to the first embodiment of the present invention. It is assumed that communication requirements are provided by a customer, and that a customer policy is described by the customer or a network designer.

[0080] In S1, network design support device 1 acquires communication requirements and customer policy of a specified customer. In S2, network design support device 1 initializes the result of the logical design. In S3, network design support device 1 applies the customer policy to the result of the initialized logical design. In S4, network design support device 1 applies a design module to the result of the logical design after applying the customer policy. Note that S3 corresponds to the procedure shown in FIGS. 17 and 18, and S4 corresponds to the procedure shown in FIGS. 19 and 20.

[0081] In S5, the network design support device 1 acquires configuration information of the real network. In S6, the network design support device 1 extracts all communication path patterns between the source and the destination from the configuration information of the real network. In S7, the network design support device 1 selects one unselected communication path pattern from the communication path patterns extracted in S6. In S8, the network design support device 1 determines whether the communication path pattern selected in S7 satisfies the logical design result obtained in S3 and S4. At this time, if the selected communication path pattern does not satisfy the logical design result, the network design support device 1 checks in S9 whether any unselected communication path patterns remain. If any unselected communication path patterns remain, the processing of the network design support device 1 returns to S7. That is, in S7 to S9, the network design support device 1 searches for a communication path pattern that satisfies the logical design result. Note that S7 to S9 correspond to the procedure shown in FIG. 21. If a communication path pattern that satisfies the results of the logical design is not found, the network design support device 1 determines in S12 that the designed logical network cannot be realized on the real network.

[0082] When a communication path pattern that satisfies the results of the logical design is found, the network design support device 1 derives setting contents based on the results of the logical design and the communication path pattern that satisfies the results of the logical design in S10. In S11, the network design support device 1 reflects the setting contents derived in S10 in the corresponding devices on the actual network. S10 to S11 correspond to the procedure shown in Fig. 22. Then, as a result of the above processing, the network desired by the customer is realized in the actual network.

[0083] As described above, the network design support device 1 designs a logical network based on communication requirements and customer policies. In the customer policies, the devices required to provide a service are grouped by function, without being individually identified. The logical network is then designed for each group. This eliminates the need to create a design module for each customer, reduces the amount of description required for the customer policies, and reduces the amount of specialized know-how required for each customer. This reduces the number of steps required for network development.

[0084] <Second embodiment> In the first embodiment, the number of steps required for network development is reduced by using the customer policy. However, if the customer policy includes detailed policies that depend on each network device or the connections between devices, it may be difficult to group the devices, and the amount of policy description may not be reduced.

[0085] For example, in the example shown in Figure 24, unlike the example shown in Figure 8, the settings for BGP communication between border routers are different. Specifically, for communication between terminals X and Y, BGP setting 1 must be implemented between border routers L and M, for communication between terminals X and Z, BGP setting 2 must be implemented between border routers L and N, and for communication between terminals Y and Z, BGP setting 3 must be implemented between border routers M and N. For this reason, the design / settings cannot be standardized as "passing through two border routers" for communication between each terminal, as in the example shown in Figure 8. Furthermore, because the policies to be applied differ depending on the border router, the linking information cannot be standardized as "between a terminal and a border router," as in the example shown in Figure 8.

[0086] Therefore, in the second embodiment, when a customer policy includes a detailed policy that is device-dependent, the customer policy is hierarchically divided into a "general policy that is commonly applied to multiple devices even if the specific device is unknown" and a "detailed policy that is applied depending on a specific device." This allows devices to be grouped by function and policies to be standardized, even when the customer policy includes a detailed policy that is device-dependent, thereby reducing the amount of description required for the customer policy.

[0087] For example, in the example shown in Figure 24, the BGP communication settings to be executed differ for each border router, so the linking information for the connection between the terminal and the border router is described for each connection (i.e., L to M, L to N, M to N). However, since the connections between the terminal and the border router are all fixed routing, it should be possible to standardize them as shown in Figure 25.

[0088] FIG. 26 shows an overview of the operation of the second embodiment. In the second embodiment, when a customer policy includes a general policy common to multiple devices and a detailed policy dependent on the device, the network design support device 1 classifies the multiple policies constituting the customer policy into "general policies" and "detailed policies." The network design support device 1 then first designs a logical network by applying the general policies. Next, before applying the detailed policies, the network design support device 1 determines specific devices by comparing the logical network designed based on the general policies with the actual network. Then, the network design support device 1 applies the detailed policies.

[0089] However, if detailed policies are completely ignored when designing a logical network, it may not be possible to achieve an appropriate logical design. For example, if elements (5) to (7) shown in FIG. 26 are completely ignored, "communication between border routers via BGP" will not be taken into consideration. Therefore, the network design support device 1 extracts common elements from detailed policies and designs a logical network taking into consideration the extracted common elements. In this example, "communication between border routers via BGP" is taken into consideration when designing the logical network, but "what kind of BGP settings are used" is not taken into consideration.

[0090] The methods for classifying and extracting policies are as follows. First, a policy that can be applied to the communication requirements is determined to be a "rough policy." On the other hand, a policy that may be applicable but to which devices it is not clear is determined to be a "fine policy." For example, if it is known that "communication via BGP" will be applied between border routers, but it is not clear which border routers will be connected to which BGP communication settings, it is determined to be a "fine policy." Furthermore, the common element of "communication via BGP with setting 1," "communication via BGP with setting 2," and "communication via BGP with setting 3" is "communication via BGP." Therefore, in this case, "communication via BGP" is extracted and taken into consideration when designing the logical network.

[0091] Fig. 27 shows an example of the functional configuration of a network design support device according to the second embodiment. In addition to the configuration shown in Fig. 11, the network design support device 1 according to the second embodiment includes a classification / extraction unit 25 and a detailed policy application unit 26. Furthermore, the customer policy is made up of a "rough policy," a "common policy," and a "fine policy."

[0092] The classification and extraction unit 25 classifies customer policies into general policies and detailed policies. The classification and extraction unit 25 also extracts common elements from the detailed policies. The design unit 22 designs a logical network based on the common elements of the general policies and detailed policies. The comparison unit 23 compares the designed logical network with the actual network to determine the devices to be actually used. Then, the detailed policy application unit 26 applies the detailed policies to the determined devices.

[0093] 28 to 32 show examples of policy classification and common element extraction. In this example, it is assumed that the customer policy shown in Fig. 28 has been generated. Then, the classification / extraction unit 25 classifies policies into those that cannot be applied unless a specific device is determined and those that can be applied even if a specific device is not determined.

[0094] In step 1 of classification and extraction, the classification and extraction unit 25 classifies policies that have the same applicable policy and that are the same when the applicable targets are grouped as "rough policies." The "applicable target" is defined using "from" representing the source and "to" representing the destination. In the example shown in Figure 28, "between terminal X and border router L," "between terminal Y and border router M," and "between terminal Z and border router N" are all "between terminal and border router," and the applicable policy is "(4) routing." In this case, as shown in Figure 29, "between terminal X and border router L," "between terminal Y and border router M," and "between terminal Z and border router N" are grouped into "between terminal and border router" and classified into a broad policy. In this case, terminals X, Y, and Z are grouped into "terminals," and border routers L, M, and N are grouped into "border routers."

[0095] In step 2 of classification and extraction, the classification and extraction unit 25 identifies policies that are identical when the policy parameters are grouped. Then, the classification and extraction unit 25 classifies, among the identified policies, policies that have the same applied policy and that are identical when the target of application is grouped as "rough policies." In FIG. 29, the policy parameters for items (1) to (3) of "policy" are "device: border router L," "device: border router M," and "device: border router N," and the border routers L, M, and N can be grouped into "border router." In this case, as shown in FIG. 30, a broad policy of "pass through a border router" is obtained. Furthermore, by grouping the policy parameters as described above, the applied policies are also grouped. Specifically, as shown in FIG. 30, "designation of a border router between terminal X and terminal Y," "designation of a border router between terminal X and terminal Z," and "designation of a border router between terminal Y and terminal Z" are consolidated into "designation of a border router between terminals." The aggregated applicable policy "1, 1" indicates that the path between the terminals passes through two border routers.

[0096] In step 3 of classification and extraction, the classification and extraction unit 25 identifies policies that partially match when the policy parameters are grouped, and creates a common policy that partially matches as a common element. Then, the applied policy is a common policy, and policies that become identical when the application targets are grouped are extracted as "common elements of detailed policies." In FIG. 30, the policy parameters of items (5) to (7) of "policy" are "BGP, setting 1," "BGP, setting 2," and "BGP, setting 3," and "BGP" matches. In this case, "BGP" is the common element, and the mutually inconsistent "setting 1," "setting 2," and "setting 3" are individual elements. Therefore, as shown in FIG. 31, item (8) is created based on items (5) to (7) of "policy." Furthermore, since item (8) is created from items (5) to (7) of "policy," item (10) is generated based on items (7) to (9) of "application," as shown in FIG. 31.

[0097] However, items (5) to (7) in the "Policy" section describe the policies that will be applied after the specific devices are decided (i.e., BGP settings 1 to 3), so they will be left as "detailed policies." Similarly, items (7) to (9) in the "Applicability" section will also be left as "detailed policies."

[0098] By following the classification and extraction steps 1 to 3 described above, the customer policies are classified into "rough policies" and "detailed policies" as shown in Figure 32. However, the common elements in the "detailed policies" are used together with the "rough policies" in the process of designing the logical network.

[0099] Next, a procedure for designing a logical network based on communication requirements and customer policies and constructing a real network will be described in the second embodiment. In this example, it is assumed that a "rough policy," "common elements of detailed policies," and "detailed policies" are created from the customer policies in the procedure described with reference to Figures 28 to 32 and stored in the storage unit 10.

[0100] The procedure 1 and procedure 2 (FIGS. 14 to 16) that are executed when the network design assistance device 1 receives the communication requirements are substantially the same in the first and second embodiments.

[0101] Fig. 33 shows step 3 of the network design support method in the second embodiment. Step 3 in the second embodiment is almost the same as step 3 in the first embodiment (Figs. 17 and 18). However, in the second embodiment, the "rough policy" and the "common elements of the detailed policy" are applied, and the "fine policy" is not applied.

[0102] First, by applying "Policy 1" corresponding to "Application: 1" shown in Figure 32, the design result shown in Figure 34(b) is obtained from the initial state shown in Figure 34(a). However, in Policy 1, border routers L, M, and N are grouped into "Border Router". Therefore, at this point, the two border routers are represented as "Border Router (1)" and "Border Router (2)". Note that "Border Router (1)" and "Border Router (2)" represent arbitrary border routers that are different from each other.

[0103] Next, by applying "Policy 4" corresponding to "Application: 4" shown in Figure 32, the design result shown in Figure 34(c) is obtained. Furthermore, by applying "Policy 8" corresponding to "Application: 10" shown in Figure 32, the design result shown in Figure 34(d) is obtained. However, in policy 8, only "Communication via BGP", which is the common element of "Communication via BGP in Setting 1", "Communication via BGP in Setting 2", and "Communication via BGP in Setting 3", is applied. Therefore, at this point, communication between border routers is simply set to "Communication via BGP" without any restrictions on the type of setting. Therefore, the result of the logical design using Procedure 3 is as shown in the bottom of Figure 33.

[0104] Figure 35 shows step 4 of the network design support method in the second embodiment. Step 4 in the second embodiment is almost the same as step 4 in the first embodiment (Figures 19 to 20). However, in the second embodiment, a logical network designed taking into consideration only the "rough policy" and the "common elements of the detailed policy" is compared with the actual network. In other words, the logical network before the "detailed policy" is applied is compared with the actual network.

[0105] Figure 36(a) shows the logical design results obtained by procedure 3, and is the same as Figure 34(d). Figures 36(b) and 36(c) show the state when design rule 1 and design rule 2 shown in Figure 12(a) are applied, respectively. Note that the settings for BGP communication are described as "detailed policies," so the settings for BGP communication are not specified when design rule 2 is applied. Therefore, at this point, as shown in Figure 36(c), the settings for "communicate via BGP" as a connection constraint are associated with the "BGP function" of the devices on both ends of the link.

[0106] FIG. 37 shows step 5 of the network design support method in the second embodiment. The part of step 5 in the second embodiment where the logical network is compared with the actual network is almost the same as step 5 (FIG. 21) in the first embodiment. However, in the second embodiment, this comparison recognizes that the border router (1) is the border router L and the border router (2) is the border router M. Then, when it is determined that the logical network designed by the design unit 22 can be realized on the actual network, the comparison unit 23 updates "border router (1)" to "border router L" and "border router (2)" to "border router M", and then stores the result of the logical design in the storage unit 10. The logical network at this point is as shown in the lower part of FIG. 37. Thereafter, the comparison unit 23 requests the detailed policy application unit 26 to apply the detailed policy.

[0107] FIG. 38 shows step 6 of the network design support method in the second embodiment. In step 6, the fine policy application unit 26 applies a fine policy to the result of the logical design obtained by steps 1 to 5. In this example, the fine policy is "policy 5" applied to the connection between border routers L and M, as shown in FIG. 32. Here, policy 5 is "protocol: BGP, parameter: setting 1" as shown in FIG. 32. Therefore, the result of the logical design is updated as shown in FIG. 39. Specifically, "communicate via BGP" in the connection constraint is updated to "communicate via BGP with setting 1". In addition, accordingly, the constraints of each device (i.e., border routers L and M) installed at both ends of the connection are also updated from "communicate via BGP" to "communicate via BGP with setting 1". As a result, the logical network shown in the lower part of FIG. 38 is obtained.

[0108] Fig. 40 shows step 7 of the network design support method in the second embodiment. This step 7 is substantially the same as step 6 of the first embodiment shown in Fig. 22. That is, the setting reflecting unit 24 performs setting on the corresponding device on the real network based on the logical network obtained in steps 1 to 6. As a result, the network required by the customer is constructed.

[0109] 41 is a flowchart showing an example of a network design support method according to the second embodiment of the present invention. It is assumed that communication requirements are provided by a customer. It is also assumed that a customer policy is written by the customer or a network designer. It is further assumed that the customer policy is classified into a general policy and a detailed policy, and common elements of the detailed policies are extracted.

[0110] The processes of S1 to S12 are almost the same in the first and second embodiments, except that in the second embodiment, S31 and S32 are executed instead of S3 shown in FIG.

[0111] In S31, the network design support device 1 applies common elements of the coarse policy and the detailed policy to the result of the logical design initialized in S2. S31 corresponds to the procedure shown in Figures 33 and 34. Thereafter, the logical network to which the common elements of the coarse policy and the detailed policy have been applied is compared with the actual network, and a communication path pattern that satisfies the result of the logical design is searched for, thereby identifying devices on the actual network.

[0112] In S32, the network design support device 1 applies a detailed policy to the logical design results obtained in S1 to S2, S31, and S4 to S9. Here, the detailed policy includes content that depends on specific devices, but at this point, each device on the real network on which the designed logical network should be implemented has been identified. Therefore, the network design support device 1 can apply the detailed policy to the logical design results. After this, configuration to the real network is performed.

[0113] Thus, according to the second embodiment, even if the customer policy includes a policy that cannot be applied unless a specific device is decided, it is possible to describe each device as a group, thereby reducing the amount of description required for the customer policy.

[0114] <Effects> According to an embodiment of the present invention, there is no need to create a design module for each customer. Instead, a logical network is designed based on a customer policy that defines network functions in accordance with the customer's network operation policy. This reduces the amount of work required for network design and configuration. Furthermore, the customer policy may include both broad policies that are device-independent and detailed policies that are device-dependent, allowing for flexible network design. Furthermore, the customer policy is coded. That is, in the customer policy, devices required to realize the customer's desired network are grouped according to their functions, and policies are described without identifying the individual devices within each group. Information describing the targets (devices, connections, etc.) to which each policy applies is also described. This reduces the amount of description required for the customer policy. For example, when designing a new network, the above-described coding reduces the amount of description required for the customer policy by approximately 30 percent. Furthermore, when expanding a network system, the above-described coding reduces the amount of description required for the customer policy by approximately 75 percent.

[0115] <Hardware configuration> 42 shows an example of the hardware configuration of the network design support device 1. The network design support device 1 is realized by a computer 100 including a processor 101, a memory 102, a storage device 103, an input / output device 104, a recording medium reader 105, and a communication interface 106.

[0116] The processor 101 controls the operation of the network design support device 1 by executing a network design support program stored in the storage device 103. This program includes program code that describes the procedures of the flowcharts shown in Fig. 23 and Fig. 41. Therefore, when the processor 101 executes this program, the functions of the receiving unit 21, design unit 22, collating unit 23, and setting reflecting unit 24 shown in Fig. 11 are provided. In the second embodiment, the functions of the classifying / extracting unit 25 and detailed policy applying unit 26 are also provided.

[0117] The memory 102 is used as a work area for the processor 101. The storage device 103 stores the above-mentioned network design support program and other programs. Note that the storage unit 10 shown in FIG. 11 or 27 is realized using the memory 102 and / or the storage device 103.

[0118] The input / output device 104 includes input devices such as a keyboard, a mouse, a touch panel, and a microphone. The input / output device 104 also includes output devices such as a display device and a speaker. The recording medium reader 105 can acquire data and information recorded on the recording medium 110. The recording medium 110 is a removable recording medium that can be attached to and detached from the computer 100. The recording medium 110 can be realized, for example, by a semiconductor memory, a medium that records signals optically, or a medium that records signals magnetically. The network design support program described above may be provided to the computer 100 from the recording medium 110. The communication interface 106 corresponds to the communication unit 30 shown in FIG. 11 or 27 and can be connected to a network. When the network design support program described above is stored in the program server 120, the computer 100 may acquire the network design support program from the program server 120. [Explanation of symbols]

[0119] 1. Network design support equipment 10 Storage section 20 Control Unit 21 Receiving unit 22 Design Department 23 Matching Unit 24 Setting reflection section 25 Classification / extraction part 26 Detailed policy application section

Claims

1. a storage unit for storing design rules describing application conditions and design details corresponding to the application conditions, a customer policy describing network functions and management methods in accordance with a customer's network operation policy, and configuration information representing the configuration of a physical network; a classification unit that classifies the customer policy into a first policy that is independent of an application device and a second policy that is dependent on an application device; a design unit that uses the first policy and the design rules to design a logical network in which logical modules are arranged within a communication path specified by communication requirements provided by a customer; a comparison unit that compares a logical network designed by the design unit with a physical network represented by the configuration information to determine whether the logical network can be realized using the physical network; an application unit that updates a design of the logical network by further applying the second policy to the logical network after the collation unit determines that the logical network can be realized using the physical network; A network design support device comprising:

2. the customer policy includes policy information representing a policy for adding a logical node to the logical network and application information representing a target to which the policy represented by the policy information is applied; The design unit applies the policy represented by the policy information to the target represented by the application information, thereby adding a logical node corresponding to the policy to the logical network.

2. The network design support device according to claim 1.

3. the customer policy includes policy information representing a policy for adding a function to a logical node arranged in the logical network and application information representing a target to which the policy represented by the policy information is applied; The design unit applies the policy represented by the policy information to the target represented by the application information, thereby adding a function to the logical node arranged in the logical network.

2. The network design support device according to claim 1.

4. the customer policy includes policy information representing a policy for adding a function to a connection between logical nodes arranged in the logical network and application information representing a target to which the policy represented by the policy information is applied; The design unit applies the policy represented by the policy information to the target represented by the application information, thereby adding a function to the connection between the logical nodes arranged in the logical network.

2. The network design support device according to claim 1.

5. further comprising an extraction unit that extracts a common element of the second policy; The design unit designs the logical network using the common elements of the first policy and the second policy and the design rules.

5. The network design support device according to claim 1.

6. A customer policy describing the network functions and management methods in accordance with the customer's network operation policy is classified into a first policy that is independent of the device to which it is applied and a second policy that is dependent on the device to which it is applied; designing a logical network in which logical modules are arranged within a communication path specified by communication requirements provided by a customer, using design rules describing application conditions and design contents corresponding to the application conditions and the first policy; By comparing the designed logical network with the physical network represented by the configuration information, it is determined whether the logical network can be realized using the physical network; updating a design of the logical network by further applying the second policy to the logical network after it is determined that the logical network can be realized using the physical network; A network design support method in which processing is performed by a computer.

7. A customer policy describing the network functions and management methods in accordance with the customer's network operation policy is classified into a first policy that is independent of the device to which it is applied and a second policy that is dependent on the device to which it is applied; designing a logical network in which logical modules are arranged within a communication path specified by communication requirements provided by a customer, using design rules describing application conditions and design contents corresponding to the application conditions and the first policy; By comparing the designed logical network with the physical network represented by the configuration information, it is determined whether the logical network can be realized using the physical network; updating a design of the logical network by further applying the second policy to the logical network after it is determined that the logical network can be realized using the physical network; A network design support program that causes a computer to execute processing.

Images