Telecommunications system and server apparatus

The present invention relates to a communication system and a server device, and more particularly to a communication system and a server device that controls network resources in a system constituting a virtual private network provided by a telecommunications carrier.

As a mechanism for using a wide area IP network as a corporate communication infrastructure, there are services provided by communication carriers called wide area Ethernet (registered trademark) and IP-VPN (Virtual Private Network). In these services, service requests from end users such as increase / decrease of bases and change of VPN band are contacted to the service provider through writing or form input, and the service provider who receives the request is the network equipment. The flow was to decide whether or not to accept the service in consideration of the resource usage status, and change the settings for the network equipment. The flow of service changes from users when the business operator that provides the VPN and the business operator that provides the wide area IP network that constructs the VPN are different is introduced, for example, in FIG. 1 of Patent Document 1. In this case, the service request from the end user was in the form of applying to the wide area IP network administrator through the mediation of the VPN administrator on the user side. In the technology of Patent Document 1, as a mechanism for reducing the time lag from the occurrence of a service request to the actual change of service, both the wide area IP network policy and the VPN policy are stored, and the VPN policy verification for the wide area IP network and VPN are performed. A VPN policy management device that verifies service requests for policies is disclosed.

Further, in Patent Document 2, as a mechanism for shortening the response time to a VPN resource allocation request across a wide area IP network, the resource information of the communication device assigned as the policy of the IP-VPN wide area network is used as the VPN resource information of the VPN policy server. The IP-VPN policy server to be set to is disclosed. On the other hand, in Patent Document 3, when traffic is concentrated on one user node from a plurality of user nodes, while securing bandwidth for each source user node, another according to the amount of data received from one user node. A method of changing the output speed from the user node is disclosed. Further, Patent Document 4 discloses a method of reducing the processing load of the user request unit, suppressing the deterioration of the performance, and avoiding the deterioration of the performance of the entire reception control function by providing a plurality of user request reception units. There is.

<patcit num="1"><text>Japanese Unexamined Patent Publication No. 2001-251307</text></patcit><patcit num="2"><text>Japanese Patent Application Laid-Open No. 2005-39644</text></patcit><patcit num="3"><text>Japanese Unexamined Patent Publication No. 2006-345173</text></patcit><patcit num="4"><text>Japanese Unexamined Patent Publication No. 2003-69635</text></patcit>

<p> One of the problems to be solved by the present invention is the same as when a user changes the settings of his / her own equipment in a network system of a telecommunications carrier that provides a service that allows a wide area IP network to be used as a communication infrastructure of a company. It is to provide a setting interface that is responsive and allows you to change settings related to the service used. In particular, if the above setting interface is opened to the user, a plurality of users may change the setting related to the equipment of the telecommunications carrier network. Therefore, even when multiple change requests occur, the network equipment can be adjusted so that inconsistencies and inconsistencies do not occur in the telecommunications carrier network by reflecting each change request while suppressing the waiting time of the user. It is necessary to change the settings. Patent Document 1 and Patent Document 2 do not mention the above-mentioned problems when a plurality of users issue change requests. Patent Document 3 describes a bandwidth control method when traffic is concentrated on one user node from a plurality of user nodes, but a plurality of newly generated requests concentrate traffic on the same user node. Judgment control, etc. in the case of</p><p> Patent Document 4 describes a method of reducing the processing load of the user request unit by providing a plurality of user request receiving units, but when the transfer device and the link affected by the plurality of user requests are duplicated, the method is described. Not considered. Although the case where the range of the user request extends over a plurality of band management units is described, the determination process is performed one by one in the order of request. Therefore, when a plurality of requests to a certain bandwidth management unit are generated, it takes time to process the final request, and the responsiveness may be lost. In view of the above points, the present invention is a network in which even when a plurality of users issue setting change requests, the network is controlled so that inconsistencies and inconsistencies do not occur in the telecommunications carrier network while suppressing the waiting time of the users. An object of the present invention is to provide a communication system and a server device for changing equipment settings.</p>

<p> In the present invention, when determining whether or not a user request can be accepted, not only the actual resource information set and reflected in the node device is referred to, but also the request contents previously loaded in the queue for managing duplicate user requests. One of the features is to make a reception judgment in consideration of it. Further, one of the features of the present invention is that when updating the settings for the node device, a plurality of request contents approved by the acceptance determination of the user request are collectively ordered.</p><p> According to the first solution of the present invention A plurality of node devices that configure a network that connects a plurality of user networks and change the setting information of a logical line between the user networks according to a control request. A terminal that transmits the setting information and A server device that receives the setting information from the terminal and sends a control request to the node device. It is a communication system equipped with The terminal An input unit for inputting logical line setting information between the user networks and With a transmitter that transmits the setting information to the server device Have, The server device A receiving unit that receives the setting information from the terminal and A classification unit that classifies the setting information received by the reception unit for each of the node device and the interface of the node device on the path of the logic line. A request storage unit that stores the setting information classified by the classification unit for each of the node device and the interface of the node device, and A resource storage unit that stores the bandwidth information of the physical line connected to each interface of the node device, and For the interface of each node device, a reception determination unit that determines whether or not the setting information can be accepted based on the band information of the physical line and the setting information of the logical line. A control issuing unit that generates a control request for the node device based on the setting information of the logical line determined to be acceptable by the reception determination unit. A communication system having the above is provided.</p><p> According to the second solution of the present invention A plurality of node devices that configure a network that connects a plurality of user networks and change the setting information of a logical line between the user networks according to a control request, a terminal that transmits the setting information, and the setting information from the terminal. The server device in a communication system including a server device that receives a message and transmits a control request to the node device. A receiving unit that receives the setting information of the logical line between the user networks from the terminal, and A classification unit that classifies the setting information received by the reception unit for each of the node device and the interface of the node device on the path of the logic line. A request storage unit that stores the setting information classified by the classification unit for each of the node device and the interface of the node device, and A resource storage unit that stores the bandwidth information of the physical line connected to each interface of the node device, and For the interface of each node device, a reception determination unit that determines whether or not the setting information can be accepted based on the band information of the physical line and the setting information of the logical line. A control issuing unit that generates a control request for the node device based on the setting information of the logical line determined to be acceptable by the reception determination unit. The server device is provided.</p>

<p> According to the present invention, even when a plurality of users issue setting change requests, it is possible to change the settings of the network equipment while suppressing the waiting time of the users and controlling so that inconsistencies and inconsistencies do not occur in the telecommunications carrier network. It is possible to provide a communication system and a server device to perform.</p>

Hereinafter, the present embodiment will be described with reference to the drawings. FIG. 1 is a network configuration diagram showing an example of this embodiment. A telecommunications carrier provides a wide-area IP network as a communication infrastructure that connects networks of the same company (user network 2) that span multiple regional bases. Each user network 2 and the network provided by the telecommunications carrier are connected via the access network 4. The connection with the access network 4 on the user network 2 side is made via the user node 3. The network on the telecommunications carrier side is configured by interconnecting the core network 8 with the regional networks 7 installed in each of several divided regions. Each regional network has a core node 6, and the core nodes 6 constituting each regional network 7 are connected to each other between the regional networks 7. For example, between the regional network 7a and the regional network 7b, the core node 6c and the core node 6d are connected to each other. The regional network 7 and the access network 4 are connected to each other by the core node 6 and the edge node 5. The relationship between the core node and the edge node is not limited to one-to-one, and one core node (example: 6a) may be interconnected with a plurality of edge nodes (example: 5a, 5b). Similarly, an edge node (eg 5a) also accommodates multiple user sites (eg 30, 30, 31) via the access network 4a. Since the network is constructed by such a tree structure, the traffic from a plurality of user bases naturally gathers in the upstream device.

In the present embodiment, in the above-mentioned service that provides the communication infrastructure that connects the corporate bases, the user can freely and in real time change the settings related to the communication line used by the corporate user. In particular, even if a plurality of users change the settings at the same time, it is possible to provide setting changes that do not cause contradictions or inconsistencies in the telecommunications carrier network and that suppress the waiting time of the users. In the network configuration for providing such a setting change function, the core network 8 and the management network 9 are connected by the core node 6e and the edge node 5d, respectively, and the resource control receiving device (server device) is provided in the management network 9. ) 10 is provided. When changing the settings using this service, the network administrator of the user company issues a request to the resource control receiving device 10 from the terminal 1 in its own network (user network 2). The terminal 1 has, for example, an input unit for inputting IP-VPN (logical line) setting information between bases (user networks) and a transmission unit for transmitting the setting information to the resource control receiving device 10.

At this time, the communication method between the user terminal 1 and the resource control receiving device 10 may be performed by the original client application and the original communication method, or the input format from the browser screen as shown in FIG. 9 shown later. It may be realized by a communication method using HTTP / HTTPS. When adopting the input format from the browser screen as shown in Fig. 9, a Web server is also required in the management network 9, but since it is sufficient to utilize a general-purpose Web server / technology, Fig. 1 shows. It is omitted. The details of FIG. 9 will be described later. Returning to the story, the problem when multiple users change the settings at the same time will be supplementarily explained with reference to FIG. A point affected by setting changes by a plurality of users is, for example, a line in which traffic from a plurality of user bases gathers and synergizes. At the end of the above-mentioned tree-structured network, traffic of multiple users may be concentrated on the device, but since the port / logical interface is individual for each user, the situation of carpooling of traffic does not occur. However, in the upstream core node, it is impossible to allocate resources to the individual traffic of all users, so that the traffic inevitably synergizes to the same line. Generally, the upstream network is constructed so that the line bandwidth becomes thicker, but not all lines are uniform. For example, between regional network 1 (7a) and regional network 2 (7b), between core node 6c and core node 6d, etc., it may be thinner than the lines in other core networks / regional networks. In such a line, a setting change made by one user affects the traffic of another user.

As an example, it is assumed that the bases 30, 31, and 32 in Fig. 1 are the bases of the same company. Each base has a user NW. When the network administrator of this user company changes the VPN line originally opened between bases 30 and 31 between bases 30 and 32, this setting change causes regional network 1 (7a). A new traffic will be applied to the line connecting the regional network 2 (7b). Regarding the above points, it is necessary to determine whether or not the setting request can be accepted, but there is a possibility that a plurality of users make similar setting changes at the same time. At that time, there is an approach of processing the requests sequentially in the order of arrival, but the user who is sent later may be dissatisfied with the waiting time. The challenges of the sequential processing approach will be explained with reference to Figure 2.

FIG. 2 is a sequence diagram for explaining a problem in processing a plurality of requests sequentially. The user terminal shown in the figure refers to a terminal in the user network operated by the network administrator of the company that uses this service, and issues a change request related to the service. The first is logging in to the system to enter changes (S1). Although omitted in the figure, authentication confirmation is performed at this step. The request from the user is processed by the resource control receiving device 10. When the user logs in to the system, a user input screen is generated and presented (S2). FIG. 9 is an example of a user input screen presented. Information on bases and contract bandwidths, which is contract information, is presented for each base, for example (90, 91). In addition, the user-set information is also classified and presented for each base, for example (92, 93, 94). FIG. 16 is a block diagram of the contract information table. FIG. 17 is a configuration diagram of the setting information table. The contract information and the setting information can be obtained from, for example, a database that manages the contract information table (contract information DB, FIG. 16) and a database that manages the setting information table (setting information DB, FIG. 17). In the contract information table, for example, a user identifier, a base identifier, and a contract band are stored correspondingly. In the setting information table, the user identifier, the base identifier, the VPN-ID, the bandwidth information, and the priority information are stored in association with each other. Information is read from each table and used to generate the user input screen shown in FIG. Further, although the functional block diagram of the resource control receiving device 10 is shown in FIG. 3 described later, the procedure up to this point is omitted in the functional block diagram because general-purpose technology may be used. Both the contract information DB and the setting information DB may be implemented in a device different from the resource control receiving device 10. In that case, it is installed in the management network 9 as in the resource control receiving device 10.

To change an existing setting, enter (97) or select (98) the changed information while referring to the information before the change. To delete the existing setting itself, use the delete button 96 attached to the corresponding setting, and to add a new setting, use the add button 95. When the add button is pressed, after prompting the input of the VLAN-ID to be added in a dialog box or the like, an input screen as illustrated in 92 is generated and presented. However, at the time of addition, there is no setting information before the change. If the total value of the bandwidth information entered by adding or changing exceeds the total bandwidth (contracted bandwidth) of the base, a warning is issued to the user at the time of input. That is, even if the update button is pressed, the change request is controlled so as not to be sent to the resource control server 10, and an error notification of the input content is performed.

As described above, in FIG. 9, the user input screen example of the image summarizing the setting information for each base is presented, but the format may be such that the setting information sorted for each VLAN-ID is presented. In addition, it provides a CUI (Command-line User Interface) -based user input method instead of the GUI (Graphical User Interface) -based user input method as shown in Fig. 9, and has the same operability as changing settings for user node 3. It may be in the form of providing. Returning to the explanation of FIG. 2 again, using the screen as shown in FIG. 9, the user terminal inputs the information for changing the setting from the input part such as a keyboard or mouse, and requests it by pressing the update button. Is issued (S3). The resource control receiving device that receives the setting change request S3 determines whether or not the setting change request can be accepted (S4). If it cannot be accepted, a reply to that effect is sent, and if it can be accepted, a setting change request is issued to the corresponding node device (S5). The node device that receives the setting change request S5 determines whether or not the change is possible (S6), and changes the setting (S7). The resource control receiving device that receives the response from the node device to the request notifies the user terminal of the result (S8), and moves on to the next request processing (S9).

When processing the setting change request as described above, even if a request from another user issued at about the same time is received immediately after receiving the request S3 from one user, it will be behind in the order of the processing queue. The loaded request is not handled until the previously loaded request has been processed. In other words, the waiting time is between S3 and S8. By operating the change request acceptance determination process and the setting change process for the node device independently, when the acceptance determination process of the previously loaded request is completed, the acceptance determination of the next stacked request is promptly performed. Will be possible. However, since the setting is finally reflected and becomes available after the setting change for the node device is completed, the time until the acceptance judgment result is known may be shortened, but the setting is reflected. There remains the problem that the time until it becomes available will not be improved. In the present embodiment, even when a plurality of requests are concentrated in this way, resource control processing with reduced waiting time for the user is realized. In the present embodiment, when the network resource control system or the like determines whether or not to accept the user request, the actual resource information set and reflected in the node device is referred to, and the queue for managing the duplicate user request is first. The acceptance judgment is made in consideration of the contents of the accumulated requests, and the acceptance judgment is made without waiting for the requests accumulated in the queue to be set and reflected in the actual node device first, and the waiting time for the judgment for the user request is set. shorten. Further, in the present embodiment, when the network control system updates the settings for the node device, a plurality of request contents approved in the acceptance determination of the user request are collectively ordered, and the plurality of users are the same at the same time. Even when a setting change request related to a node device is issued, the load on the setting change request of the node device is reduced.

FIG. 18 is a configuration diagram of the resource control receiving device 10 of the present embodiment. The resource control receiving device 10 of the present embodiment includes a processor 301, a memory 302, a storage device 303, and a network interface (304 and 305). For example, the resource control reception program 309 is mounted on a general-purpose server device. The resource control reception program 309 is stored in the storage device 304, is loaded on the memory 302 when the program is executed, and is driven by the processor 301. The route information management unit 17 is the same as that managed by a general network management system, and aggregates the route information set in each node device. As shown in FIG. 18, the route information management unit 17 is table information managed by a general-purpose database device 310 including a CPU 311, a memory 312, a storage device 313, and a network interface 314.

Figure 15 shows a configuration example of the route information management table. In the route information management table, the VPN-ID 150, the source 152 and the destination 154, and the route information 156 are stored. The route information 156 stores, for example, the identifier of the node device and the identifier of the interface on the route specified by the VPN-ID 150 or the routes specified by the sources 152 and 154. On the other hand, the target list management unit 18 registers and manages node devices and interfaces including points (lines) in which changes in user settings affect the traffic of other users. As shown in FIG. 18, the target list management unit 18 is table information managed by a general-purpose database device 320 including a CPU 321, a memory 322, a storage device 323, and a network interface 324. This shows the node devices (for example, 6c and 6d) and the target interface at the point where the line bandwidth becomes narrower (in Fig. 1, the example is between 6c and 6d) as illustrated in the explanation of FIG. , The administrator of the network (administrator of the telecommunications carrier network) registers in advance (Fig. 13). The configuration of the resource management unit 19 may be the same as that used in the conventional network management system or node management system. As shown in FIG. 18, the resource management unit 19 is table information managed by a general-purpose database device 330 including a CPU 331, a memory 332, a storage device 333, and a network interface 334. The limit value may be set to a value equal to the bandwidth of the physical line, or the allowable width value set in the system configuration may be added to the bandwidth of the physical line (Fig. 14).

Figure 14 shows a configuration example of the resource management table. In the resource management table, the node identifier 140, the interface identifier 142, the upper limit bandwidth 144, and the reserved bandwidth 146 are stored correspondingly. By the way, in FIG. 18, the database device 310 for storing the route information management unit 17, the database device 320 for storing the target list management unit 18, and the database device 330 for storing the resource management unit 19 are shown as images in which separate devices are configured. However, these pieces of information may be managed by the same database device. FIG. 3 is a functional block diagram of the resource control reception program 309. The resource control reception program 309 has, for example, a request reception unit 11, a determination control unit 15, and a control execution unit 16. The determination control unit 15 includes a control request classification unit 20, a control request management unit 21, a reception determination unit 22, and a control issuing unit 23. In FIG. 3, only the functional blocks related to the processing after receiving the setting change request (S3) are shown.

In the resource control receiving device 10, the request receiving unit 11 receives a change request (user request, setting change request, setting information) from the user terminal (terminal in the user network 2) 1. The request received here includes a set of contents input through the user setting screen as shown in FIG. In other words, if the change content extends to multiple locations and multiple settings (for example, 92 settings, 93 settings, and 94 settings), one request message will include multiple setting change items. .. On the contrary, if the change content is a single setting of a single site, the setting change item included in one request message is also one. The control request classification unit 20 examines the node devices and interfaces to be controlled for each setting change item, and classifies them as requests for each control target. The classification result is temporarily recorded in the control request management unit 21 until the control is completed. Figure 4 shows an example of the table configuration of the control request management unit 21. The change 41 is classified according to the target node and the target interface (40). At this time, the target node and the target interface are specified by referring to the route information management unit 17 and the target list management unit 18.

As a processing procedure performed by the control request classification unit 20, the route information management unit 17 is examined using the flow identification information (for example, VPN-ID, source address and destination address, etc.) included in the changed contents as a search key, and the target is Extract the node devices and interfaces on the route (Fig. 10, step 101). Next, it is confirmed whether the extracted node devices and interfaces are registered in the target list management unit 18 (Fig. 10, step 102). As a result of collating with the information of the target list management unit 18, if it matches, it is registered in the control request management unit 21 as a change content related to the matched node device / interface (Fig. 10, step 103). The edge node 5 included in the target route is directly targeted for setting change as a device corresponding to the boundary point of the telecommunications carrier network, so all of them are extracted to the control request management unit 21. If the device and interface information related to the edge node is also registered in the target list management unit 18, the control request can be classified into the management unit 21 according to the flow of the above procedure. The remaining elements shown in FIG. 4 will continue to be described. The difference column (diff) 42 is a column for registering the difference between the band before the change and the band after the change when the requested band is changed. It may be calculated when processing the reception judgment unit 22 later, but it is useless to read the data etc. if it is performed as the processing of the control request classification unit 20 in the flow of registering the information in the change content column 41. There is no.

The request ID field (Req-Id) 43 is an identifier uniquely set by the system for each change request. When registering in the control request management unit 21, set so that there is no duplication with other change requests. However, the same request ID is assigned to change requests derived from the same change request but having different target nodes and interfaces. The status column (Status) 44 is a column for managing the processing status of the change request. When each change request is separated by the control request classification unit 20 for each target node and target interface and registered in the control request management unit 21, the state is "not yet". After that, as a result of determining the acceptance of the change request by the acceptance determination unit 22, the registered contents are changed to "OK" if the acceptance is possible, and to "NG" if the acceptance is not possible. If all the acceptance judgment results for the same request ID are "OK", the control issuing unit 23 changes the settings for the node device and then deletes them from the control request management table. On the other hand, since the request for changing the request ID that has become "NG" cannot be accepted in the request content, a reply to that effect is sent to the user via the request reception unit 11. Although the explanation was partially given in the explanation of FIG. 4, the explanation is continued by returning to FIG. 3 again. After the control request classification unit 20 classifies and registers the control request management unit 21, the reception determination unit 22 determines the reception of the control request newly registered in the control request management unit 21. At this time, the items of the control request management table shown in FIG. 4 whose status column 44 is "not yet" are targeted.

As a characteristic determination procedure of this system, each control request is not determined independently, but control requests for the same target node and the same target interface are collectively determined. For example, Fig. 4 shows the state in which the judgment result is obtained, but as in entries # 1 and # 2 and # 10 and # 11, the processing state of the control request for the same target node and the same target interface is ". If it is "not yet", # 1 and # 2, and # 10 and # 11 are judged together. Specifically, it is determined whether or not all the plurality of control requests for the same object can be applied. In the case of # 1 and # 2, the change request is 7M bandwidth increase and 2M bandwidth decrease, but the effect on the control target is 5M bandwidth increase, so the control target node on the route, Judgment is made from the viewpoint of whether the bandwidth of 5M can be increased in the interface. Similarly, in the case of # 10 and # 11, the judgment is made from the viewpoint of whether the bandwidth of 15M can be increased in the controlled object. There may be cases where the summarized request contents are not accepted, but in that case, a method can be used in which the requests that are piled up later are deleted in order and the judgment is performed again. In addition, as in the case of a two-branch search that is often used in search processing, a primary judgment is made with half the number of requests, and if the judgment result is acceptable, half the contents of the remaining requests are added to make a judgment. If the result is not possible, a method of deriving an acceptable boundary point can be used by repeating the determination such that the determination is made with the content of half the number of requests. In Fig. 4, # 10 and # 11, the case where the request of # 10 was accepted but the request of # 11 was not accepted is illustrated. The result is notified to the terminal 1 for the request that the judgment result becomes impossible. Similarly, with respect to the request for which the determination result is valid, the result at the time when the acceptance determination result is obtained may be notified. Information on the existing resource usage status and limit value in the controlled target when making the above determination is acquired from the resource management unit 19.

When the determination result is obtained through the above procedure, the control issuing unit 23 is next processed. The control issuing unit 23 generates a request for the controlled object and executes control through the control executing unit 16. The target is the control request for which the result of the reception judgment is "OK", but here as well, the control is performed not for each request but for the request contents summarized for each control target. For example, for requests to the same node such as # 1 and # 2 in FIG. 4, control is executed by grouping setting change messages (control requests) into one. As the control content, for example, shaping settings for each VPN / label / flow are performed. The interface specifications of the control request depend on the interface of the node device, but you can also log in to the target node with telnet and issue control commands, or NETCONF Configuration established by the IETF (the Internet Engineering Task Force). Protocol (RFC4741) may be used. At this time, whether or not multiple control requests for the same node / same interface can be made to the node device with one control command / one control message depends on the interface specifications of the target node. It should be noted that the above-mentioned "control is performed according to the request contents summarized for each control target" is the process of the control issuing unit 23 of the resource control receiving device 10.

Finally, when the control to the target node device is completed, the result is reflected in the resource control unit 19 and the user terminal is also notified. The above is the flow of a series of processes of the resource control receiving device 10 shown in FIG. In FIG. 3, the control request classification unit 20, the reception determination unit 22, and the control issuing unit 23 are all mounted on one device, but the request reception unit 11 and the control request classification unit 20 are mounted. A system in which the device, the device on which the reception determination unit 22 is mounted, the device on which the control issuing unit 23 and the control execution unit 16 are mounted are separated, and each device operates while communicating with the device on which the control request management unit 21 is mounted. You may take the form of. In addition, Fig. 4 is an example of table configuration focusing on control request management due to bandwidth setting change, but when it is necessary to inspect the fluctuation of bandwidth allocation for each priority due to priority setting change. Adds priority to the classification item in addition to the target node and interface. In other words, item 40 in Fig. 4 is classified and organized by adding the condition of priority. Similarly, the resource management table shown in FIG. 14 is also classified by adding the condition of priority (for example, adding a column between 142 and 144 to classify).

Next, the processing procedure of the resource control receiving device 10 described with reference to FIG. 3 will be further described with reference to a flowchart. FIG. 5 is a flowchart showing a processing procedure of the resource control receiving device at the time of receiving a user request. As an overall flow, as already described in FIG. 3, the request reception process 50 for receiving the user request is performed by the request reception unit 11, and then the judgment control process 52 performed by the judgment control unit 15 is performed. The determination control process 52 will be described in detail later with reference to FIG. After the determination control process 52 is performed, the control execution unit 16 executes the control 54 for the node device. FIG. 6 is a flowchart showing the determination control process of the determination control unit 15. The request classification process 61 corresponds to the process of the control request classification unit 20, and the reception determination process 63 corresponds to the process of the reception determination unit 22. Further, the control issuing process 65 corresponds to the processing of the control issuing unit 23. As explained in Fig. 3, the basic flow is to perform request classification processing 61, reception judgment processing 63, and control issuance processing 65 in order, but here we will delve into the timing of transitions between processes. explain. In each process, all unprocessed contents are processed before transitioning to the next process. In the request classification process 61, processing is performed until there are no unprocessed requests, and when there are no unprocessed requests, the process proceeds to the next acceptance determination process (step 60). In the reception determination process 63, if there is no undetermined process, the process proceeds to the next control issuance process, but if there is an undetermined process (step 62), all of these acceptance determination processes are performed (step 63). Similarly, in the control issuance process 65, if there is no uncontrolled process, the process transitions to the request classification process again, but if there is an uncontrolled process (step 64), all of these control issuance processes are performed (step 65). As a method for realizing the unprocessed queue, a method as shown in FIG. 7 and a method as shown in FIG. 8 can be considered. Next, the flow of FIG. 6 will be described according to the configuration of each processing queue.

First, a case where the processing queue configuration as shown in FIG. 7 is adopted will be described. This model is a method of providing a unified queue that does not depend on processing, and each processing is loaded in the queue when it occurs. When each process is stacked as shown in the example shown in Fig. 7, process A of 72₆Until the end of, since it is determined as Yes in the unprocessed request confirmation in step 60, the repeated request classification process 61 is performed. After classifying the request, each process A₄~ A₆Is a new reception decision waiting process B₄~ B₆However, these are stacked in sequence after 76. Process B of 73₂When the turn comes around, it does not correspond to the unprocessed request confirmation in step 60 and is determined to be "none", and is determined to be "yes" in the unprocessed determination confirmation in step 62. Is done. 74 processing B₃Until the end of, since it is determined as yes in the unprocessed determination confirmation in step 62, the acceptance determination process 63 is repeatedly performed. Next 75 processes A₇Does not correspond to the unprocessed control confirmation in step 64, so the process returns to step 60 again to perform the request classification process in step 61. Next 76 processes C₁Does not correspond to step 60 or step 62, so the flow is that the process proceeds to step 64 and the control issuance process of step 65 is performed. The reception judgment process and the control issuance process are, for example, B.₂, B₃Can be processed collectively in addition to the iterative processing.

As described above, in the model of FIG. 7, the processes are performed in the order in which they are loaded in the unified queue, and the processes are continued as long as the same processes are continuous. By processing in this way, for example, the processes 71 to 72 are in the request judgment waiting state after the request classification process is completed, and are again loaded in the unified queue in the same manner, so that they occur continuously at the same time. Requests will be processed in approximately the same cycle. By the way, the unit of processing loaded in the queue is request ID 43, but the unit processed when the order has changed is the controlled node and controlled interface unit in reception judgment processing 63 and control issuing processing 65. , Processing with the same control target may be processed in one volume before the processing order of the queue is changed. Next, a case where the processing queue configuration as shown in FIG. 8 is adopted will be described. This model is a method of preparing a queue for each process, and is suitable for cases where request classification process 61, reception judgment process 63, and control issuance process 65 are operated in parallel by, for example, multiple CPUs. Strictly speaking, for the convenience of sharing the control request management table 21, each process is time-divisioned by exclusive control, but it is piled up when the allocation time (order) 79 between processes comes around. It is suitable as a form for judging the same kind of processing at once. For example, the processing loaded in each queue is executed at predetermined timing 79. Further, when a predetermined amount is accumulated in the queue, the processing may be executed collectively. The request classification process 61, the reception judgment process 63, and the control issuance process 65 are supplemented using a flowchart. FIG. 10 shows a flowchart of the request classification process 61. The request classification process will be omitted because it is described with reference to the reference numerals in FIG. 10 as the processing procedure performed by the control request classification unit 20 in the description of FIG.

FIG. 11 shows a flowchart of the reception determination process 63. The reception determination process is mentioned as the process of the reception determination unit 22 in the latter half of FIG. 3, but here, it will be described according to the procedure of the flowchart. In the acceptance determination process, processing is performed for the request whose status column 44 of the control request management table is "not yet" (request whose processing status is "not yet") (step 111). When extracting a request whose processing status is "not yet", it is extracted for the same node and interface unit (step 112). Since the requests in the control request management table are classified (40) for each target node and target interface, they may be searched in order. After collectively extracting the unprocessed requests for the same node and interface, the information of the corresponding node and interface of the resource management unit 19 is collated to see if the request contents that combine the extracted multiple requests are allowed (step 113). The permissible judgment of the summarized request contents will be omitted because it is described in the explanation of the reception judgment unit 22 in the latter half of FIG. The determination result is reflected in the status column 44 (step 114), and the process proceeds to the determination of the request for the next node and interface (step 115). Here, the determination result may be reflected in the status column 44 and notified to the user terminal.

The network control system of the present embodiment refers to the actual resource information set and reflected in the node device when determining whether or not the user request can be accepted, and is first loaded in the queue for managing duplicate user requests. Since the acceptance judgment is made in consideration of the request contents, the reception judgment can be made without waiting until the request loaded in the queue is reflected in the actual node device, and the waiting time for the judgment for the user request can be made. Has the advantage of being able to shorten. FIG. 12 shows a flowchart of the control issuance process 65. The control issuance process is also mentioned as the process of the control issuance unit 23 in the latter half of FIG. 3, but here, it will be described according to the procedure of the flowchart. In the control issuance process, the process is performed for the request whose status column 44 of the control request management table is "OK" (step 121). Similar to the reception determination process, extraction is performed for the same node and interface unit (step 122). After extracting the requests for the same node and interface, the request contents are summarized and the control request for the target node is issued (step 123). The processed request for which the control request has been passed to the control execution unit 16 is deleted from the control request management table (step 124). Here, the processing status may be notified to the user terminal again. When the processing for all the nodes and interfaces whose status column 44 of the control request management table is "OK" is completed (step 125), the requests whose judgment result described in the status column 44 is "NG" are collectively deleted (step 126). ). However, the timing for deleting the request whose determination result is "NG" may be performed at the end of the reception determination process or at the beginning of the control issuance process. In the network control system of the present embodiment, when updating the settings for the node device, a plurality of request contents approved in the acceptance determination of the user request are ordered at once, so that a plurality of users simultaneously order the same node device. Even when a setting change request related to is issued, the load on the setting change request of the node device can be reduced.

Up to this point, the present embodiment has been described as a countermeasure method when a plurality of users change settings at the same time, but from this point onward, a single user who manages a plurality of connection bases changes a plurality of settings. In this case as well, it will be described that the configuration of the present embodiment can be applied and is effective. Again, assume that the bases 30, 31, and 32 in Figure 1 are the bases of the same company. For example, suppose that a VPN line was initially opened only between bases 30 and 32, but another VPN line is newly opened between bases 31 and 32. Also, suppose that the bandwidth of the VPN line between the bases 30 and 32 is increased at the same time. At this time, regarding bases 30 and 31 on the calling side, each change request may be within the contract band, but whether or not this request can be accepted depends on the situation on the base 32 side. Make a decision. At base 32, different VPN traffic from base 30 and base 31 merge. If the total traffic amount far exceeds the contracted bandwidth of the base 32, the communication bandwidth required by this setting change cannot be guaranteed, so the user is informed that the requested content cannot be accepted. In this way, when a point where a plurality of traffic merges occurs as a result of the setting change, the resource control receiving device 10 handles these requests as follows. The request received by the request receiving unit 11 is one request, but as described above, one request may include a plurality of setting change items. The setting request analysis unit 20 examines the node devices and interfaces to be controlled for each setting change item, classifies the requests for each control target, and first records them in the control request management unit 21. Here, the setting change items are, for example, the opening of a new VPN line and the increase in the bandwidth of the current VPN line.

Specifically, the route information management unit 17 is examined using the flow identification information (for example, VPN-ID, source address and destination address, etc.) included in the change request as a search key. Of the node devices and interfaces on the target route, the information about the edge node is always the target, so the setting change items related to the points where the destinations meet are extracted without omission. This information is classified and organized in the control request management unit 21 as shown in # 1 and # 2 in FIG. 4, for example. Since the reception determination unit 22 collectively determines the control requests related to the same target node and the same target interface, it can also determine whether or not it is possible to accept the combined setting change for the point where a plurality of traffic merges. .. Subsequent processing is the same.

This network control system is useful, for example, in a network system of a telecommunications carrier that provides users with an interface that allows them to freely change settings related to services used. In particular, a plurality of users can network at the same time. Suitable for network systems that allow setting changes related to equipment.

<figref num="1">The network block diagram which shows an example of the Embodiment of this invention.</figref><figref num="2">A flowchart illustrating a problem when processing a plurality of requests sequentially.</figref><figref num="3">Functional block diagram of the resource control reception program.</figref><figref num="4">The figure which shows one configuration example of the control request management table in this embodiment.</figref><figref num="5">The flowchart which shows the processing procedure of the resource control receiving device at the time of receiving a user request.</figref><figref num="6">The flowchart which shows the processing procedure of the judgment control part.</figref><figref num="7">The figure which shows one configuration example of the processing queue in a judgment control part.</figref><figref num="8">The figure which shows another configuration example of the processing queue in a determination control part.</figref><figref num="9">The figure which shows an example of the setting screen of a user request.</figref><figref num="10">A flowchart showing a processing procedure of request classification processing.</figref><figref num="11">A flowchart showing a processing procedure of reception judgment processing.</figref><figref num="12">The flowchart which shows the processing procedure of the control issuance processing.</figref><figref num="13">The figure which shows one configuration example of the target list management table.</figref><figref num="14">The figure which shows one configuration example of a resource management table.</figref><figref num="15">The figure which shows one configuration example of the route information management table.</figref><figref num="16">The figure which shows one configuration example of the contract information management table.</figref><figref num="17">The figure which shows one configuration example of the setting information management table.</figref><figref num="18">The block diagram of the resource control reception device of this embodiment.</figref>

Code description

1 User terminal 2 User network 3 user node 4 Access network 5 edge node 6 core nodes 7 Regional network 8 core network 9 Management network 10 Resource control receiving device 11 Request reception department 15 Judgment control unit 16 Control execution unit 17 Route Information Management Department 18 Target list management department 19 Resource Management Department 20 Control requirement classification unit 21 Control requirements management department 22 Reception Judgment Department 23 Control issuing department 309 Resource control reception program