Management device, management method, and management program

Abstract

This management device: receives a generation request for a first entity; determines, on the basis of previously stored specification information related to the first entity, whether or not the first entity requires consumption of a resource; if consumption of the resource is required, identifies, on the basis of previously stored entity information, a second entity that can provide a capacity to be consumed by the first entity; determines, on the basis of the second entity, whether or not the capacity of the resource to be consumed by the first entity can be dispensed; and, if dispensable, dispenses the capacity to the first entity. Upon receiving a plurality of first entity generation requests, the management device, on the basis of a second entity identified for each of a plurality of first entities of the plurality of entity generation requests, dispenses a common resource capacity to the plurality of first entities.

Description

[Technical field]

[0001] One aspect of the present invention relates to a management device, a management method, and a management program. [Background technology]

[0002] There is a known network and ICT operation business that manages networks (NW) including network devices and ICT (Information and Communication Technology) devices such as servers, and performs configuration work on the network and ICT devices according to orders from users. In this network and ICT operation business, a network and ICT management system is used to automate the complicated configuration work on multiple devices. The network and ICT management system has a network and ICT information management function that holds management information according to the network and ICT devices that are the objects of management.

[0003] Generally, network and ICT management systems have management functions specialized for specific networks and ICT devices. Therefore, whenever there is a change in the network environment, such as the type of network device that constitutes the network, the type of ICT device, the network method, the connection method, the communication method, etc., the network and ICT management system must be redeveloped.

[0004] Here, a system architecture has been proposed that does not require redevelopment of a network and an ICT management system for each managed network or managed ICT device when changing the model or communication method of the managed network or ICT device (see, for example, Non-Patent Document 1). In other words, Non-Patent Document 1 proposes a mechanism that enables the retention of generic data that is not dependent on the managed network or ICT device.

[0005] In network and ICT operation, the device is configured to enable communication based on user requests. In this configuration, since it is impossible to configure settings that exceed the resources such as communication bandwidth that the device can provide, it is necessary to manage the capacity of the resources that the device can provide and configure the device while determining whether they can be allocated to users. Therefore, Non-Patent Document 2 proposes a mechanism for managing the resource capacity of the device and automatically allocating the required resources on top of the general-purpose data management mechanism of Non-Patent Document 1. [Prior art documents] [Non-patent literature]

[0006] [Non-Patent Document 1] Masataka Sato et al., "A Study on Network Management Architecture Adaptable to Diverse Networks," IEICE Technical Report 116(324), 37-42, November 24, 2016 [Non-Patent Document 2] Masataka Sato, Shingo Horiuchi, "Flexible Network Resource-Allocation Architecture Using Specification Injection", Proceedings of the 20th Asia-Pacific Network Operations and Management Symposium (APNOMS 2019) Summary of the Invention [Problem to be solved by the invention]

[0007] In network and ICT operation, it is necessary to coordinate and allocate multiple resources of the network and ICT equipment to meet user requests.

[0008] The technology proposed in the above-mentioned non-patent document 2 makes it possible to automatically manage the capacity of device resources, but since it performs resource capacity management and allocation for a single device, it is not possible to allocate resources of multiple devices in a coordinated manner.

[0009] This invention has been made in light of the above-mentioned circumstances, and its object is to provide technology that can cooperatively manage multiple resource capacities and automatically allocate required resources in a network and ICT management system that is independent of the networks and ICT devices being managed. [Means for solving the problem]

[0010] In order to solve the above problem, one aspect of the present invention is a management device having a hardware processor and a memory, the memory comprising a first storage unit for storing specification information representing specifications of a plurality of entities including a network to be managed and an ICT device, and a second storage unit for storing entity information including information representing a relationship between the plurality of entities, the hardware processor receiving an entity generation request for requesting generation of a first entity for the network or the ICT device, reading out the specification information for the first entity from the first storage unit, determining whether the first entity has a consumption specification attribute representing the requirement to consume resources in the network or the ICT device, and determining whether the first entity has the consumption specification attribute. when it is determined that the first entity can provide a resource capacity consumed by the first entity based on entity information stored in the second storage unit, determine whether or not the resource capacity consumed by the first entity can be allocated based on the identified second entity, and allocate the capacity to the first entity when it is determined that the capacity can be allocated. When a plurality of the entity generation requests are received, the hardware processor allocates a common resource capacity to the plurality of first entities based on the second entity identified for each of the plurality of first entities in the plurality of entity generation requests. the method includes: grouping entity generation requests requiring the same amount or value of resource capacity to be consumed; determining whether or not the capacity of the common resource consumed by the plurality of first entities can be allocated for each of the plurality of grouped entity generation requests; and, when it is determined that the capacity can be allocated, allocating the capacity of the common resource to each of the first entities of the plurality of grouped entity generation requests. It is configured as follows. Effect of the Invention

[0011] According to one aspect of the present invention, it is possible to provide a technology that enables multiple resource capacities to be managed in a cooperative manner and automatically allocate required resources in a network and ICT management system that is independent of the networks and ICT devices being managed. [Brief description of the drawings]

[0012] [Figure 1] FIG. 1 is a block diagram showing the functional configuration of a management device according to an embodiment of the present invention. [Diagram 2] FIG. 2 is a diagram illustrating an example of an entity managed by the management device illustrated in FIG. [Diagram 3] FIG. 3 is a diagram showing the relationship between specifications and entities used in the management device shown in FIG. [Figure 4] FIG. 4 is a diagram showing an example of specifications and entity data in the technology proposed in Non-Patent Document 1. [Diagram 5] FIG. 5 is a diagram showing an outline of requests from users that the management device shown in FIG. 1 can receive. [Figure 6] FIG. 6 is a block diagram showing a hardware configuration of a management device according to an embodiment of the present invention. [Figure 7] FIG. 7 is a diagram showing a procedure of advance preparation in the management device shown in FIG. [Figure 8] FIG. 8 is a diagram showing a procedure of capacity management among the processes performed by the management device shown in FIG. [Figure 9] FIG. 9 is a diagram showing an overview of a capacity request in the management device shown in FIG. [Figure 10] FIG. 10 is a diagram showing an overview of capacity request and retention in the management device shown in FIG. [Figure 11] FIG. 11 is a diagram showing an outline of the flow of capacity allocation processing in the management device shown in FIG. 1 when there is no equivalence constraint group. [Figure 12] FIG. 12 is a diagram showing an outline of the flow of a capacity allocation process to which grouping based on an equivalence constraint is applied in the management device shown in FIG. [Figure 13] FIG. 13 is a diagram showing an example of definition of attributes of capacity consuming entities in the management device shown in FIG. [Figure 14] FIG. 14 is a diagram showing an example of definition of attributes of a capacity providing entity in the management device shown in FIG. [Figure 15] FIG. 15 is a diagram illustrating an example of capacity retention in the management device illustrated in FIG. [Figure 16] FIG. 16 is a diagram illustrating an example of the specifications of the capacity consuming entities in the management device illustrated in FIG. [Figure 17A] FIG. 17A is a diagram showing an example of a definition of the specifications shown in FIG. [Figure 17B] FIG. 17B is a diagram showing an example of a definition of the specifications shown in FIG. [Figure 18] FIG. 18 is a diagram showing a flow of searching for a capacity providing entity based on the specifications shown in FIG. [Figure 19] FIG. 19 is a diagram showing the flow of grouping based on the equivalence constraints based on the specifications shown in FIG. [Figure 20] FIG. 20 is a diagram illustrating a first example of capacity allocation in the management device illustrated in FIG. [Figure 21] FIG. 21 is a diagram illustrating a second example of capacity allocation in the management device illustrated in FIG. [Figure 22] FIG. 22 is a diagram illustrating a third example of capacity allocation in the management device illustrated in FIG. [Figure 23] FIG. 23 is a flowchart showing the processing procedure and processing contents of the management device shown in FIG. [Figure 24] FIG. 24 is a diagram illustrating an example of a preparation procedure in the management device illustrated in FIG. [Diagram 25] FIG. 25 is a diagram illustrating an embodiment of a processing procedure performed by the capacity request acquisition unit of the management apparatus illustrated in FIG. [Figure 26] FIG. 26 is a diagram illustrating an embodiment of an equivalence constraint group creating procedure performed by the capacity requirement acquisition unit of the management apparatus illustrated in FIG. [Figure 27] FIG. 27 is a diagram illustrating an embodiment of a processing procedure up to acquisition of an assignment function by the capacity assignment unit of the management device illustrated in FIG. [Figure 28]FIG. 28 is a diagram illustrating an embodiment of a processing procedure up to registration by the capacity allocation unit of the management device illustrated in FIG. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0013] Hereinafter, an embodiment of the present invention will be described with reference to the drawings.

[0014] [One embodiment] <1> composition <1-1> Functional configuration The management device in one embodiment manages a network including multiple network devices and ICT devices such as servers, PCs (Personal Computers), and terminals connected to the network, and automatically allocates resources to meet user requests, and is configured, for example, by a server computer managed by a telecommunications carrier.

[0015] FIG. 1 is a block diagram showing the functional configuration of such a management device 1. As shown in FIG. The management device 1 is capable of communicating with a plurality of network devices (not shown in FIG. 1) constituting a network (NW) 2, and is also capable of communicating with a plurality of ICT devices 3 connected to the network 2. The network 2 is used, for example, to provide network services, and can include an IP (Internet Protocol) network represented by the Internet, and a plurality of access networks for accessing the IP network. Examples of the access networks that can be used include a wireless LAN (Local Area Network), a mobile phone network, a wired telephone network, a FTTH (Fiber To The Home), and a CATV (Cable Television) network. Hereinafter, the management device 1, the network 2, and the ICT devices 3 are collectively referred to as a "network and ICT management system."

[0016] The management device 1 shown in FIG. 1 includes a capacity management unit 10 as a software-based processing function unit, and includes a management information database (DB) 20 as a storage area required to realize this embodiment, in addition to a program storage unit.

[0017] The capacity management unit 10 has a function of managing the resource capacity of the network and the ICT device 3, which are the devices to be managed, judging whether the resource capacity can satisfy the user's request, and allocating the necessary resources when it is judged that the user's request can be satisfied. The capacity management unit 10 includes a capacity request acquisition unit 11 and a capacity allocation unit 12.

[0018] The capacity request acquisition unit 11, as a request acquisition unit, receives input from an operator based on a user request, acquires information necessary to allocate capacity corresponding to the user request, generates an allocation request, and performs processing to pass it to the capacity allocation unit 12.

[0019] The capacity issuing unit 12 receives a capacity issuing request from the capacity request acquisition unit 11 and performs processing to issue the capacity.

[0020] Here, the management device 1 according to an embodiment employs a network and ICT management architecture having a mechanism for externally defining attributes of network and ICT management information (entities) according to specifications that define the characteristics of the network or ICT device. Each piece of information is stored in the management information DB 20.

[0021] The management information DB 20 stores various information for managing the managed devices, and comprises a Spec DB 21 as a first memory unit, an Entity DB 22 as a second memory unit, and a function repository 23 as a third memory unit.

[0022] The specification DB 21 stores specification information that specifies the characteristics of a network or ICT equipment. The specification information includes specifications related to entities that are networks and ICT management information.

[0023] The entity DB 22 stores attribute information on entities, which is network and ICT management information. The attribute information includes information that indicates relationships between entities and characteristics (such as Virtual Local Area Networks (VLANs)) of the networks 2 and ICT devices 3 that the entities have.

[0024] The function repository 23 stores various functions used to issue capacity. In Fig. 1, a quantity issue function 231, a value list issue (lower number) function 232, and a value list issue (higher number) function 233 are shown as examples of functions stored in the function repository 23, but the functions are not limited to these.

[0025] FIG. 2 is a diagram showing an example of entities managed by the management device 1 based on the above-mentioned network and ICT management architecture. The entities are roughly divided into physical layer entities and logical layer entities. In the example shown in FIG. 2, PD (Physical Device, device), PP (Physical Port, communication port of device), and PL (Physical Link, connection cable between devices) are defined as physical layer entities. In the example shown in FIG. 2, TL (Topological Link, connectivity between devices), NFD (Network Forwarding Domain, forwardable range within device), TPE (Termination Point Encapsulation, communication termination point), FRE (Forwarding Relationship Encapsulation), NC (Network Connection, LC between TPEs, End-End connectivity formed by XC), LC (Link Connect, connectivity between devices terminated at TPE), and XC (Cross Connect, connectivity within device terminated at TPE) are defined as logical layer entities. Each of these entities is also distinguished in terms of notation, as exemplified in FIG. 2.

[0026] FIG. 3 is a class diagram showing the relationship between specifications and entities. In this architecture, entities are collectively called resources, and resource specifications are called ResourceSpecification (ResourceSpec). ResourceSpec has ResourceSpecCharacteristic (RSC) and ResourceSpecCharacteristicValue (RSCV), and the characteristics of each network are defined by a pair of RSC and RSCV. RSC indicates the name of the characteristic attribute, and RSCV indicates the value that RSC can take. A resource entity holds the value for the attribute of RSC of the ResourceSpec that is the basis of the entity in ResourceCharacteristicValue (RCV).

[0027] 4 is a diagram showing an example of specifications and entities of TPE (Termination Point Encapsulation) of the Ethernet (registered trademark) layer in the technology proposed in Non-Patent Document 1. As described above, the specifications are stored in the spec DB 121 of the management device 100, and the entities are stored in the entity DB 122 of the management device 100.

[0028] The "TPE_Ethernet_Spec" specification 1211, which is the specification of the TPE for the Ethernet layer, defines three RSCs (vlan, bandwidth, _physicalPort) and the values ​​that each RSC can take as RSCV. According to the specification 1211, "vlan" can take values ​​from "1" to "4096," "bandwidth" can take values ​​from "1Mbps" to "1000Mbps," and "_physicalPort" holds the "PP name."

[0029] The "TPE_Ethernet1" entity 1221, which is a TPE entity in the Ethernet layer, indicates by its ResourceSpec attribute that it is an entity created from the "TPE_Ethernet_Spec" specification 1211. In this example, the entity 1221 holds specific values ​​(vlan: 1234, bandwidth: 100 Mbps, _physicalPort: PP1 of Switch1) by RCV for each of the three RSC attributes defined in the corresponding specification 1211.

[0030] The entities stored in the entity DB 122 can be represented by an entity diagram. For example, the "TPE_Ethernet1" entity 1221 can be represented as in the entity diagram 1222. According to the entity diagram 1222, the "TPE_Ethernet1" entity 1221 in the Ethernet layer has a reference relationship with the PP1 entity of Switch1 in the physical layer. This indicates that the "TPE_Ethernet1" entity 1221 holds the name of the PP1 entity of Switch1 in the _physicalPort attribute. Below, entities will be explained using such an entity diagram.

[0031] In the following, an example will be described in which resources required are allocated to an Ethernet switch, which is a network device constituting the network 2. Of course, it goes without saying that the management device 1 can similarly allocate resources required for an ICT device 3 connected to the network 2.

[0032] Fig. 5 is a diagram showing an overview of user requests that can be received by a management device 1 according to an embodiment. In Fig. 5, it is assumed that a network 2 to be managed by the management device 1 is composed of two Ethernet switches SWITCH1 and SWITCH2, and the cable between the switches has a communication bandwidth of 100 Mbps.

[0033] 5, assume that a request is made from user A (User A) to communicate from PC1, which is an ICT device 3, to PC2, which is another ICT device 3, via network 2. Management device 1 assigns a VLAN ID to each user and sets up two Ethernet switches SWITCH1 and SWITCH2 for communication, but the assigned VLAN ID must be the same for Ethernet switch SWITCH1 and Ethernet switch SWITCH2. As an example, if the VLAN-IDs held by Ethernet switch SWITCH1 are 1 to 1000 and the VLAN-IDs held by Ethernet switch SWITCH2 are 100 to 200, management device 1 to which the technology proposed in Non-Patent Document 2 is applied performs the following operations (Q1) to (Q3).

[0034] (Q1) First, the management device 1 receives an instruction to generate network and ICT management information (entities) based on a request from a user A from a human operator.

[0035] (Q2) Next, the management device 1 allocates an available VLAN ID from the resources held by the Ethernet switch SWITCH1 in response to the request of user A. For example, it allocates the VLAN-ID "1" which is the lowest number in the held resources.

[0036] (Q3) Next, the management device 1 allocates an available VLAN ID from the resources held by the Ethernet switch SWITCH2 in response to the request of the user A. For example, it allocates the VLAN-ID “100”, which is the lowest number in the held resources.

[0037] With this type of allocation, the VLAN-IDs assigned to Ethernet switches SWITCH1 and SWITCH2 do not match, which means communication is not possible.

[0038] In this way, the technique proposed in Non-Patent Document 2 cannot allocate resources to a plurality of devices in a coordinated manner when there is a difference in the VLAN-ID resources held by the devices.

[0039] In contrast, a management device 1 according to an embodiment includes a capacity management unit 10 that has a function of processing a plurality of resource requests collectively and distributing them collectively, and receives a "logical entity generation instruction" from an operator and allocates resources of a plurality of devices in a coordinated manner. That is, in the management device 1 (or a network and ICT management system including the management device 1), the following procedure is performed instead of the above (Q1) to (Q3).

[0040] (T1) The management device 1 receives an instruction to generate network and ICT management information (entities) based on a request from user A.

[0041] (T2) The management device 1 groups resource requests to be processed in a coordinated manner for the Ethernet switches SWITCH1 and SWITCH2.

[0042] (T3) The management device 1 acquires an available VLAN ID from the resources held by the Ethernet switch SWITCH1 in response to a request from the user A. For example, "1 to 1000" is acquired as the held resource (VLAN-ID).

[0043] (T4) The management device 1 acquires an available VLAN ID from the resources held by the Ethernet switch SWITCH2 in response to a request from the user A. For example, "100 to 200" is acquired as the held resource (VLAN-ID).

[0044] (T5) The management device 1 assigns a common free VLAN ID to the resources held by the two Ethernet switches SWITCH1 and SWITCH2. For example, the management device 1 assigns "VLAN-ID 100", which is the smallest number among the common held resources.

[0045] In this way, the management device 1 enables coordinated allocation of resources among a plurality of devices.

[0046] Therefore, the management device 1 according to an embodiment can manage a plurality of resource capacities in a cooperative manner and automatically allocate required resources in a network and ICT management system that is independent of the network and ICT device to be managed.

[0047] <1-2> Hardware configuration FIG. 6 shows an example of the hardware configuration of the management device 1 described above.

[0048] The management device 1 includes, as hardware, a CPU (Central Processing Unit) 51, a RAM (Random Access Memory) 52, a program memory 53, an auxiliary storage device 54, a communication interface (I / F) 55, an input / output interface (I / F) 56, and a bus 57. The CPU 51 communicates with the RAM 52, the program memory 53, the auxiliary storage device 54, the communication interface 55, and the input / output interface 56 via the bus 57.

[0049] The CPU 51 is an example of a general-purpose hardware processor.

[0050] The RAM 52 is used as a working memory by the CPU 51. The RAM 52 includes a volatile memory such as a Synchronous Dynamic Random Access Memory (SDRAM).

[0051] The program memory 53 stores programs (including computer executable instructions) necessary for executing various control processes according to an embodiment. As the program memory 53, for example, a ROM (Read-Only Memory), a part of the auxiliary storage device 54, or a combination thereof is used.

[0052] All of the processing functions described with respect to the capacity management unit 10 of the management device 1 are realized by causing the CPU 51 to execute application programs stored in the program memory 53. For example, when a management program (computer-executable instructions) related to capacity request acquisition processing is executed by the CPU 51, it causes the CPU 51 to execute a series of processes described with respect to the capacity request acquisition unit 11.

[0053] The auxiliary storage device 54 stores data non-temporarily. The auxiliary storage device 54 includes a non-volatile memory such as a hard disk drive (HDD) or a solid state drive (SSD). The auxiliary storage device 54 can store various data including the network management information described above with respect to the management information DB 20.

[0054] The communication interface 55 is an interface for communicating with an external communication device, and is provided with, for example, a wired LAN terminal and is connected to a network including the Internet via a LAN cable.

[0055] The input / output interface 56 includes a plurality of terminals for connecting input and output devices. Examples of the input device include a keyboard, a mouse, a microphone, etc. Examples of the output device include a display device, a speaker, etc.

[0056] The program may be provided to the management device 1 in a state where it is stored in a computer-readable storage medium. In this case, for example, the management device 1 further includes a drive (not shown) for reading data from the storage medium, and acquires the program from the storage medium. Examples of the storage medium include a magnetic disk, an optical disk (CD-ROM, CD-R, DVD-ROM, DVD-R, etc.), a magneto-optical disk (MO, etc.), and a semiconductor memory. Also, the program may be stored in a program providing server on the network, and the management device 1 may download the program from the program providing server using the communication interface 55.

[0057] The processes described in the embodiments are not limited to those performed by a general-purpose processor such as the CPU 51 executing a program, but may be performed by a dedicated processor such as an ASIC (Application Specific Integrated Circuit).

[0058] The management device 1 is not limited to being implemented by one computer (management device). The management device 1 may be implemented by multiple computers. For example, the management device 1 may be configured with a computer that functions as a capacity request acquisition unit 11 and a computer that functions as a capacity allocation unit 12.

[0059] <2> operation Next, the information processing operation by the management device 1 configured as above will be described.

[0060] <2-1> Overview of operation First, an overview of the operation of the management device 1 will be described with reference to FIGS.

[0061] <2-1-1> Advance preparation FIG. 7 is a diagram showing a procedure of advance preparation in the management device 1. As shown in FIG.

[0062] In step P1, the management device 1 registers in advance in the spec DB 21 a specification that defines the characteristics of a network or ICT device including a network device, in response to an operation by an operator OP.

[0063] The management device 1 also generates a physical layer entity (physical entity) for the entity DB 22 in response to an operation by the operator OP in step P2.

[0064] <2-1-2> Capacity management unit operation FIG. 8 is a diagram showing an outline of the operation of the capacity management unit 10 in the management device 1. As shown in FIG.

[0065] (S1) Capacity request acceptance First, in step S1, the management device 1 receives, via the capacity management unit 10, a logical entity to be generated (capacity consuming entity) and a generation request input by an operator OP based on a user application, and passes the received entity to the capacity request acquisition unit 11.

[0066] Here, among the entities held by the management device 1, the entities that hold the capacity of the device, such as communication bandwidth and VLAN-ID, are called "capacity providing entities", and the logical entities generated for each user in relation to the capacity providing entities are called "capacity consuming entities".

[0067] FIG. 9 shows an overview of such entities and capacity requests / provisions.

[0068] As shown in FIG. 9, in the management device 1, a logical entity (capacity consuming entity) 220 requests a capacity from a capacity providing entity 221 based on a user's request.

[0069] Here, the types of capacity include "amount" and "identifier." "Amount" is expressed by a quantity such as bandwidth (e.g., 100 Mbps), memory (e.g., 8 GB), CPU (e.g., 8 cores), etc., and is a type that uses a part of the amount held by the capacity providing entity. "Identifier" is expressed by an identifier such as VLAN-ID (e.g., 1, 2, 3, ...), MPLS (Multi-Protocol Label Switching) label (e.g., 20, 21, ...), etc., and is a type that has a list of identifiers that the capacity providing entity can use, and uses one identifier from that list.

[0070] Fig. 10 is a diagram showing an example of capacity request and retention related to such "amount" and "identifier". Regarding the amount, in the example of Fig. 10, the capacity consuming entity 220 requests 80 Mbps of the 100 Mbps communication bandwidth held by the capacity providing entity 221. Regarding the identifier, in the example of Fig. 10, the capacity consuming entity 220 requests VLAN-ID "2" from the available VLAN-IDs 1 to 4096 held by the capacity providing entity 221.

[0071] (S2) Acquisition of specifications Next, in step S2 of FIG. 8, the capacity requirement acquisition unit 11 acquires the specification (Spec) of the input capacity consuming entity from the spec DB (Spec DB) 21.

[0072] (S3) Determine whether consumption specification attributes exist In step S3, the capacity request acquisition unit 11 judges whether or not the acquired specifications have a capacity consumption specification attribute (consumeCapacityInfo). If the acquired specifications do not have a capacity consumption specification attribute, the logical entity is an entity that does not require the reservation of device resource capacity. In this case, the capacity request acquisition unit 11 registers the logical entity in the entity DB 22 and ends the process. If the acquired specifications have a capacity consumption specification attribute, the process proceeds to the following process.

[0073] (S4) Get Capacity Providing Entity In step S4, the capacity request acquisition unit 11 accesses the entity DB 22 and acquires a capacity providing entity (an entity that holds a capacity to be managed and provides capacity in response to a request) based on the acquired capacity consumption specification attribute.

[0074] (S5) Creating an equivalence constraint group In step S5, the capacity requirement acquisition unit 11 searches for an equivalence constraint group of the capacity consuming entity based on the acquired capacity consumption specification attribute, and creates an equivalence constraint group. The equivalence constraint refers to a constraint condition for grouping capacity consuming resources that should cooperate to output the same value from the capacities of multiple device resources.

[0075] (S6) Withdrawal request In step S6, the capacity request acquisition unit 11 generates an assignment request and requests the capacity assignment unit 12 to assign capacity. The assignment request includes information for identifying a capacity providing entity, an assignment function used for assignment, and information for identifying a requested amount or value. In this case, the information for identifying a capacity providing entity is information for identifying multiple capacity providing entities that should assign the same value based on an equivalence constraint group.

[0076] (S7) Get payment function In step S7, the capacity issuing unit 12 acquires a capacity issuing function required for the issuing from the function repository 23 based on the issuing request received from the capacity request acquisition unit 11.

[0077] (S8) Capacity Allocation In step S8, the capacity allocation unit 12 allocates capacity using the acquired allocation function. That is, the capacity allocation unit 12 allocates the requested capacity to the requesting logical entity. If the allocation result (request amount / request value) is NG (cannot satisfy the request), the capacity allocation unit 12 stops the process.

[0078] (S9) Capacity Registration Finally, in step S9, the management device 1 registers a capacity consuming entity based on the allocation result in step S8, and also registers information on the allocated capacity in the capacity providing entity.

[0079] <2-1-3> Capacity requirements and allocation FIG. 11 is a diagram showing an overview of the process from capacity request to allocation in the case where there is no equivalence constraint group.

[0080] In this case, the management device 1 executes the following processes (R1) to (R3) without cooperative allocation.

[0081] (R1) The management device 1 causes the capacity providing entity 221 to hold in advance the capacity that can be provided (in this example, VLAN-ID: 100 to 200).

[0082] (R2) The capacity consuming entity 220 requests capacity from the capacity providing entity 221.

[0083] (R3) The capacity distribution unit 12 calculates the capacity by the following formula: Available Capacity - Used Capacity - Requested Capacity > 0 If the above is true, it is determined that the capacity can be allocated (OK). If the capacity can be allocated, the capacity issuing unit 12 updates the used capacity of the capacity providing entity 221 (to VLAN-ID "100" in this example) as shown in the figure, and allocates (provides) the requested capacity (to VLAN-ID "100" in this example) to the requesting logical entity.

[0084] FIG. 12 is a diagram showing an overview of the process from capacity request to allocation to which grouping based on equivalence constraints is applied.

[0085] In this case, the management device 1 executes the cooperative allocation enabling process such as the following (R1) to (R3').

[0086] (R1) The management device 1 causes the capacity providing entity 221 to hold in advance the capacities that can be provided (in this example, VLAN-IDs: 1 to 1000 and VLAN-IDs: 100 to 200).

[0087] (R4) The capacity consuming entities 220 are grouped by an equality constraint.

[0088] (R2') The grouped capacity consuming entities 220 request capacity from the capacity providing entity 221 for the group as a whole.

[0089] (R3') The capacity allocation unit 12 performs capacity allocation in grouping units, thereby enabling cooperative allocation. That is, the capacity allocation unit 12 allocates a commonly available capacity (in this example, the VLAN-ID "100") from among the VLAN-IDs held by multiple capacity providing entities 221.

[0090] Here, the management device 1 further defines capacity-related attributes for entities in said network and ICT management architecture to express capacity requirements and provision.

[0091] FIG. 13 is a diagram showing definitions of attributes of a capacity consuming entity as an example of such capacity-related attributes.

[0092] As shown in FIG. 13, the capacity consuming entity 220 defines "Name (name of entity)", "RSC (name of attribute requesting capacity)", and "RCV (value / amount corresponding to capacity attribute name)". As described above, the capacity consuming entity 220 holds the capacity request amount in the RSC / RCV pair. This RSC / RCV is not only the requested amount, but also plays a role in holding the issued capacity. As shown in the figure, it is possible for one entity to hold multiple capacity requests. Data examples will be described later.

[0093] FIG. 14 is a diagram showing definitions of attributes of a capacity providing entity as another example of the capacity-related attributes.

[0094] 14, "name (entity name)" and "capacity (record of available capacity and capacity already provided to requesting entity)" are defined as attributes of the capacity providing entity 221. As shown in the figure, one entity can hold multiple provided capacities.

[0095] The "capacity" attribute has child elements "name (name of the provided capacity)", "units (unit of the provided capacity (not necessary for a list of values, so represented by [-]))", "CapacityAmount (amount of capacity that can be provided or range of values)", and "CapacityDemand (record of provided capacity) (multiple settings possible)". "CapacityDemand" further has "CapacityDemandAmount (amount or value of provided capacity)" and "entityName (name of the entity to which the capacity is provided)". Data examples will be described later.

[0096] <2-1-4> Maintaining capacity Fig. 15 is a diagram showing an overview of capacity retention using the data examples shown in Fig. 13 and Fig. 14. In Fig. 15, the entity DB 22 retains connection relationships of the logical layer (Ethernet layer and Logical Device layer), connection relationships of the physical layer (including Switch1 and Switch2), and reference relationships between the logical layer and the physical layer.

[0097] As an example of data of the capacity consumption entity 220, there are shown a capacity request for user A named "Switch1-Switch2_FRE_UserA" and a capacity request for user B named "Switch1-Switch2_FRE_UserB." In FIG. 15, "Switch1-Switch2_FRE_UserA" requests bandwidth=60 and VLAN-ID=1, and "Switch1-Switch2_FRE_UserB" requests bandwidth=30 and VLAN-ID=2.

[0098] An example of data of the capacity providing entity 221 shows Name "Switch1-Switch2_PL" having a reference relationship with the capacity request for the above-mentioned user A and user B. According to the Capacity attribute of "Switch1-Switch2_PL" shown in Fig. 15, the bandwidth that can be provided is 100 Mbps according to "name=bandwidth, units=Mbps, CapacityAmount=100", and the VLAN-ID that can be provided is [1-4096] according to "name=VLAN-ID, CapacityAmount=1-4096".

[0099] Furthermore, with regard to "bandwidth," the CapacityDemand attribute of the capacity providing entity 221 indicates that there is a record that a bandwidth of "60 Mbps" has been provided to the entity "Switch1-Switch2_FRE_UserA" by "CapacityDemandAmount=60, entityName=Switch1-Switch2_FRE_UserA," and that a bandwidth of "30 Mbps" has been provided to the entity "Switch1-Switch2_FRE_UserB" by "CapacityDemandAmount=30, entityName=Switch1-Switch2_FRE_UserB."

[0100] Similarly, with regard to "VLAN-ID", the CapacityDemand attribute of the capacity providing entity 221 indicates that there is a record that VLAN-ID "1" has been provided to entity "Switch1-Switch2_FRE_UserA" by "CapacityDemandAmount=1, entityName=Switch1-Switch2_FRE_UserA", and that VLAN-ID "2" has been provided to entity "Switch1-Switch2_FRE_UserB" by "CapacityDemandAmount=2, entityName=Switch1-Switch2_FRE_UserB".

[0101] Furthermore, the specification (Spec) on which the capacity consuming entity is based has a capacity consumption specification attribute (consumeCapacityInfo) that indicates how the capacity is consumed.

[0102] FIG. 16 is a diagram showing an example of the specifications of such a capacity consuming entity.

[0103] As shown in Fig. 16, the specification 211 of the capacity consuming entity "Switch2_Eth_TPE1" defined by the entity DB 22 is acquired by referring to the spec DB 21, and is defined as the name "TPE_Ethernet_Spec" in Fig. 16. Such a specification 211 is appropriately designed by the operator OP in response to a request from a user, for example, and is stored in response to an operation of the operator OP during the above-mentioned advance preparation process. The attributes shown in Fig. 16 will be further described with reference to Figs. 17A and 17B.

[0104] 17A and 17B are diagrams showing an example of data of the specification 211 shown in FIG. 16, as well as a definition of the capacity consumption specification attribute (consumeCapacityInfo).

[0105] The capacity consumption specification attributes include "name (name of the Spec)", "RSC (attribute name indicating the characteristics of the network or ICT equipment)", "RSCV (range of values ​​that the above attributes can take)", and "ConsumeCapacityInfo (information about capacity consumption)".

[0106] "ConsumeCapacityInfo" includes, as child elements, "Attribute (name of attribute requesting capacity) (must be defined in RSC)", "consumeFuncName (name of function used to allocate capacity)", "Provider (information for identifying the capacity providing entity)", and "constrainedSameValues ​​(constraint condition for grouping capacity consuming resources that should cooperate to allocate the same value from the capacities of multiple device resources (called equality constraint))".

[0107] The Provider attribute enclosed by a dashed line in Figure 17A is actually expressed in the form of an array. If you trace the reference relationship between entities from the capacity consuming entity in the order of the Provider attribute array, the end of the array will point to the capacity providing entity. The method of searching for this capacity providing entity will be described later.

[0108] The above Provider attribute further includes "ObjectType (type of the entity to be referenced (one of PD, PP, PL, TL, NFD, TPE, FRE(NC), FRE(LC), FRE(XC))")", "ReferDirection (direction of reference, Forward: forward direction, Reverse: reverse direction)", "ReferKey (attribute name that serves as the key when referencing the next entity)", "ConstrainedKey (key information for narrowing down the candidates by applying constraints when there are multiple reference candidates)", and "ConstrainedValue (value corresponding to the above key)".

[0109] The constrainedSameValues ​​attribute enclosed by a dashed line in Figure 17B is actually expressed in the form of an array. When the reference relationships between entities are traced from the capacity consuming entity in the order of the array of the constrainedSameValues ​​attribute, the last group of entities in the array (there may be multiple entities) are grouped. The method of grouping using this equality constraint will be described later.

[0110] Like the Provider attribute, this constrainedSameValues ​​attribute also includes "ObjectType", "ReferDirection", "ReferKey", "ConstrainedKey", and "ConstrainedValue".

[0111] <2-1-5> Search for capacity providing entities Fig. 18 is a diagram showing an outline of a method for searching for a capacity providing entity 221 based on the above Provider attribute. The data example 211 of the capacity consumption specification shown in Fig. 17 is the same as the specification 211 shown in Fig. 16 and Fig. 17A.

[0112] In the management device 1 according to an embodiment, the capacity providing entity 221 is searched for by the capacity request acquisition unit 11. The capacity request acquisition unit 11 searches for entities that have a reference relationship in the order of the Provider array from the capacity consuming entity 220 in either the Forward direction or the Reverse direction. This is executed by searching the array of the Provider attribute in order from 0 to the end. The reference relationship is represented by the RSC / RCV possessed by each entity. Note that, when there are multiple search candidates, it is also possible to narrow down the target entities by a combination of ConstrainedKey / Value for each reference relationship and perform the search. The capacity request acquisition unit 11 finally searches to the end of the array and identifies the entity acquired in the last reference relationship of the array as the capacity providing entity 221.

[0113] This search process is further explained with reference to the example of FIG.

[0114] First, in step S41, the capacity request acquisition unit 11 searches for a TPE entity (in this example, the "Switch1_LD_TPE1" entity 223) referenced by the RSC "_serverTperRef" held by the TPE entity (in this example, the "Switch1_Eth_TPE1" entity 222). This step is a forwarding search. Here, if there are multiple candidates, the capacity request acquisition unit 11 selects one that satisfies the ConstrainedKey / Value combination (layerProtocolName=LogicalDevice).

[0115] In step S42, the capacity request acquisition unit 11 searches for a PP entity (in this example, the "Switch1_PP1" entity 224) referenced by the RSC "_physicalPort" of the searched TPE entity. This step is a forwarding search.

[0116] The entity 221 finally obtained by the above search process becomes the capacity providing entity.

[0117] <2-1-6> Grouping by Equivalence Constraints Fig. 19 is a diagram showing an overview of a grouping method based on the above-mentioned constrainedSameValues ​​attribute. The data example 211 of the capacity consumption specification shown in Fig. 19 is the same as the specification 211 shown in Fig. 16 and Fig. 17B.

[0118] In the management device 1 according to an embodiment, grouping based on the equivalence constraint is performed by the capacity request acquisition unit 11. The capacity request acquisition unit 11 searches for entities that are subject to the equivalence constraint in the order of the constrainedSameValues ​​array as viewed from the capacity consuming entity 220. The search method is the same as the search for capacity providing entities. The capacity request acquisition unit 11 groups all of the capacity consuming entities by treating the searched entity group as entities that are subject to the equivalence constraint.

[0119] This grouping will be further explained with reference to the example of Fig. 19. Note that steps S51 and S52 are similar to the above steps S41 and S42 in the search for a capacity providing entity, and therefore the explanation thereof will be omitted.

[0120] In step S53, the capacity request acquisition unit 11 searches for a PL entity (the “Switch1-Switch2_PL” entity 225 in this example) that references the searched PP entity (the “Switch1_PP1” entity 224 in this example) by the RSC “_physicalPort.” This step is a reverse search.

[0121] In step S54, the capacity request obtainment unit 11 searches for a PP entity (in this example, the "Switch2_PP1" entity 226) referenced by the RSC "_physicalPort" of the searched PL entity. This step is a forwarding search.

[0122] In step S55, the capacity request acquisition unit 11 searches for a TPE entity (in this example, the "Switch2_LD_TPE1" entity 227) that references the searched-for PP entity by the RSC "_physicalPort." This step is a reverse search.

[0123] In step S56, the capacity request acquisition unit 11 searches for a TPE entity (in this example, the "Switch2_Eth_TPE1" entity 228) that references the searched TPE entity by the RSC "_serverTpeRef". This step is a reverse search. If there are multiple candidates, the capacity request acquisition unit 11 selects one that satisfies the ConstrainedKey / Value combination (layerProtocolName=Ethernet).

[0124] The entities found by the above-described search process become capacity-providing entities that are grouped as targets of the equivalence constraint.

[0125] <2-1-7> Capacity allocation and result registration Next, with reference to Figs. 20 to 22, the allocation of capacity and registration of the allocation result will be described using three examples ("amount allocation successful", "amount allocation failure", and "allocation of a list of values").

[0126] (i) Amount paid: Success FIG. 20 is a diagram showing an example in which the allocation of capacity is "successful."

[0127] It is assumed that the capacity allocation unit 12 receives the following allocation request. Operation type: Withdrawal Capacity consuming entity → Capacity providing entity: Switch1-Switch2_FRE_UserA → Switch1-Switch2_PL Equality Constraint Group: None Capacity issue function name: Quantity issue function Demand amount / value: Bandwidth / 60

[0128] In this example, the capacity "bandwidth" held by the capacity providing entity 221 has a total capacity (CapacityAmount) of 100 Mbps, and has not yet been allocated to any entity (no value has been registered in CapacityDemand). Therefore, the capacity issuing unit 12 determines that the requested amount of 60 Mbps can be allocated, and issues the requested amount of 60 Mbps. The capacity issuing unit 12 determines the requested amount of the capacity consuming entity 220 that made the request (2201), and adds the allocated requested amount of 60 Mbps and the entity to which the capacity is to be provided (Switch1-Switch2_FRE_UserA) to the provided capacity (CapacityDemand) of the capacity providing entity 221 (2211).

[0129] (ii) Amount paid: Failed FIG. 21 is a diagram showing an example in which the allocation of capacity is “failed (NG)”.

[0130] It is assumed that the capacity allocation unit 12 receives the following allocation request. Operation type: Withdrawal Capacity consuming entity → Capacity providing entity: Switch1-Switch2_FRE_UserB → Switch1-Switch2_PL Equality Constraint Group: None Capacity issue function name: Quantity issue function Demand amount / value: Bandwidth / 50

[0131] In this example, the capacity "bandwidth" held by the capacity providing entity 221 has a total capacity (CapacityAmount) of 100 Mbps, of which 60 Mbps has already been allocated (it is registered in CapacityDemand that 60 Mbps has already been allocated to Switch1-Switch2_FRE_UserA). Therefore, the capacity issuing unit 12 determines that it is not possible to allocate the current requested amount of 50 Mbps, and the allocation result is NG (failure). Therefore, the capacity issuing unit 12 does not update the capacity providing entity 221 (2212).

[0132] (iii) Identifier assignment: list of values FIG. 22 is a diagram showing an example in which the allocation of capacity is a "list of values."

[0133] It is assumed that the capacity allocation unit 12 receives the following allocation request. Operation type: Withdrawal Capacity consuming entity → Capacity providing entity: Switch1_Eth_TPE1 ⇒ Switch1_PP1, Switch2_Eth_TPE1 → Switch2_PP1 Equivalence constraint group: Switch1_Eth_TPE1, Switch2_Eth_TPE1 Capacity assignment function name: Value list assignment (lowest number) function Request amount / request value:VLAN-ID / -

[0134] In this example, the capacity "VLAN-ID" held by the capacity providing entity requested by two capacity consuming entities constituting an equivalence constraint group has a total amount (CapacityAmount) of 1 to 1000 and 100 to 200, and has not yet been allocated to either entity (no value has been registered in CapacityDemand), so there is an unused ID in common. Therefore, the capacity issuance unit 12 determines that it is possible to issue a new ID in response to the new issue request. Since the function specified this time is the "value list issue (lowest number) function," the capacity issuance unit 12 issues the smallest number "1" from among the available IDs. The capacity issuing unit 12 determines the RCV of the VLAN-ID to be “100” as the request of the capacity consuming entity 220 that is the request source (2203), and adds the issued request “100” and the recipient entities (Switch1_PP1, Switch2_Eth_TPE1) to the provided capacity (CapacityDemand) of the capacity providing entity 221 (2213).

[0135] <2-2> Processing flow Next, the outline of the operation of the management device 1 as described above will be explained again using a process flow.

[0136] Fig. 23 is a flowchart showing the processing procedure and processing contents. Steps S1 to S9 in Fig. 23 correspond to steps S1 to S9 shown in Fig. 8. Note that it is assumed that the advance preparation steps P1 to P2 described with reference to Fig. 7 have been executed in advance.

[0137] The management device 1 monitors the presence or absence of an input from an operator OP by the capacity management unit 10, and when it receives an input from the operator OP, starts the following process.

[0138] In step S1, the management device 1 receives, via the capacity request acquisition unit 11, a request for a capacity consuming entity as a logical entity to be generated from an operator OP.

[0139] Next, in step S2, the management device 1 causes the capacity request acquisition unit 11 to acquire the specification (Spec) of the input capacity consuming entity from the spec DB (Spec DB) 21.

[0140] In step S3, the management device 1 determines whether or not the specifications acquired from the spec DB 21 have a capacity consumption specification attribute (consumeCapacityInfo) by the capacity request acquisition unit 11. If it is determined that the acquired specifications do not have a capacity consumption specification attribute (NO) as a result of this determination, the management device 1 proceeds to step S10 since the entity does not require the reservation of device resource capacity. In step S10, the management device 1 registers the logical entity in the entity DB 22 and ends the process. On the other hand, if it is determined in step S3 that the acquired Spec has a capacity consumption specification attribute (YES), the management device 1 proceeds to step S4.

[0141] In step S4, the management device 1 causes the capacity request acquisition unit 11 to search for a reference relationship between entities using the acquired consumeCapacityInfo, and identifies a capacity providing entity.

[0142] In step S5, the management device 1 causes the capacity request acquisition unit 11 to search for an equivalence constraint group of the capacity consuming entity based on the acquired consumeCapacityInfo, and creates an equivalence constraint group.

[0143] In step S6, the management device 1 generates a capacity allocation request by the capacity request acquisition unit 11, and requests the capacity allocation unit 12 to allocate capacity. Together with this request, the capacity request acquisition unit 11 sends the following information to the capacity allocation unit 12: Operation type: "Payment" if you want to register a new capacity consuming entity, "Refund" if you want to delete it, "Change requested amount" if you want to change the attribute value of the entity Capacity providing entity: Name of the capacity consuming entity and the capacity providing entity identified by searching in step S4 Equivalence constraint group: Name of the capacity consuming entity included in the equivalence constraint group created in step S5 Capacity distribution function name: consumeFuncName of consumeCapacityInfo of capacity consumption entity · Request amount · Request value: RSC / RCV specified in consumeCapacityInfo of the capacity providing entity

[0144] Next, in step S7, the management device 1 causes the capacity issuing unit 12 to acquire the capacity issuing function requested by the capacity request acquisition unit 11 from the function repository 23.

[0145] In step S8, the management device 1 assigns capacity using the acquired assignment function by the capacity assigning unit 12. If the capacity assignment is successful (YES), the process proceeds to step S9. The assignment result includes the requested amount and requested value. If the capacity assignment result is "failed (NG)" (NO), the process is stopped.

[0146] In step S9, the management device 1, through the capacity issuing unit 12, registers information on the issued capacity (provided amount / value) to the capacity consuming entity to which the capacity is provided and to the capacity providing entity based on the result of the allocation.

[0147] <3> Working Example Next, the details of the processing according to the embodiment as described above will be further described using an example, with Figs. 24 to 28 showing an example.

[0148] <3-1> Advance preparation FIG. 24 is a diagram showing the procedure of advance preparation.

[0149] In step P101, in response to an operation by an operator OP, the management device 1 registers specifications that define the characteristics of a network or ICT equipment in the spec DB 21. In the example of Fig. 24, "FRE_VLAN_Spec", "TPE_LogicalDevice_Spec", "PL_SW-SW_Spec", "TPE_Ethernet_Spec", "PP_SW_Spec", ... are registered in the spec DB 21.

[0150] Also, in step P102, in response to an operation by the operator OP, the management device 1 generates physical layer entities for the entity DB 22. In the example of Fig. 24, two switches (Switch1 and Switch2), an entity 224 related to a communication port of the switch Switch1, an entity 225 related to a connection cable between the two switches, and an entity 226 related to a communication port of the switch Switch2 are generated as physical entities.

[0151] <3-2> Obtaining capacity request FIG. 25 is a diagram showing a procedure of the capacity request acquisition process performed by the capacity request acquisition unit 11. As shown in FIG.

[0152] First, in step S101, the management device 1 accepts a generation request for a capacity consuming entity input by the operator OP through the capacity management unit 10, and passes it to the capacity request acquisition unit 11. In the example of Fig. 25, the management device 1 accepts a generation request for a "Switch1_Eth_TPE1" entity 222 and a "Switch2_Eth_TPE1" entity 228. These entities 222 and 228 correspond to the entities present during the search shown in Figs. 18 and 19, and have been appropriately designed by the operator OP in response to, for example, a request from a user.

[0153] Next, in step S102, the capacity request acquisition unit 11 acquires the specification (Spec) of the received capacity consuming entity from the spec DB (Spec DB) 21, and checks whether the specification has the capacity consumption specification (consumeCapacityInfo). In the example of FIG. 25, the specification "TPE_Ethernet_Spec" defined in "ResourceSpec" of the capacity consuming entity 220 is acquired from the spec DB 21. The details of "TPE_Ethernet_Spec" indicated by the dashed line in FIG. 25 are the same data example as 211 shown in FIG. 18 and FIG. 19, and have consumeCapacityInfo. As described above, if it is determined that the TPE_Ethernet_Spec acquired in step S102 has consumeCapacityInfo, the capacity request acquisition unit 11 proceeds to step S103.

[0154] In step S103, the capacity request acquisition unit 11 uses the consumeCapacityInfo of the TPE_Ethernet_Spec to access the entity DB 22, searches for a reference relationship between entities, and identifies and acquires a capacity providing entity such as that shown in the entity DB 22 in Fig. 25. The capacity request acquisition unit 11 further generates a capacity allocation request based on the consumeCapacityInfo.

[0155] <3-3> Creating an equivalence constraint group FIG. 26 is a diagram showing a processing procedure for creating an equivalence constraint group by the capacity request acquisition unit 11. In FIG.

[0156] In step S104, the capacity request acquisition unit 11 searches for an equivalence constraint group of the capacity consuming entity based on the consumeCapacityInfo, and creates an equivalence constraint group 501. In this example, the equivalence constraint group 501 includes Switch1_Eth_TPE1 and Switch2_Eth_TPE1.

[0157] <3-4> Accepting a withdrawal request and obtaining a withdrawal function FIG. 27 is a diagram showing a processing procedure from acceptance of a distribution request by the capacity distribution unit 12 to acquisition of a distribution function.

[0158] In step S105, the capacity request acquisition unit 11 passes the capacity assigning request generated based on the consumeCapacityInfo and the created equivalence constraint group 501 to the capacity assigning unit 12. In this example, the capacity assigning request includes the following information. Operation type: Withdrawal Capacity providing entity information Capacity providing entity Equivalence constraint group: Switch1_Eth_TPE1, Switch2_Eth_TPE1 Capacity assignment function name: Value list assignment (low number) function ·Request amount·Request value:VLAN-ID / -

[0159] Next, in step S106, based on the received assignment request, the capacity assignment unit 12 acquires a function with the specified capacity assignment name from the function repository 23. In this example, the capacity assignment unit 12 acquires the value list assignment (lower number) function 232.

[0160] <3-5> Capacity allocation and registration FIG. 28 shows a processing procedure up to capacity allocation and registration by the capacity allocation unit 12.

[0161] In step S107, the capacity issuance unit 12 uses the acquired amount issuance function 231 to assign capacity. If the assignment result is NG, the process is stopped. The assignment result is obtained as a requested amount / requested value, and in this example, the capacity issuance unit 12 assigns the VLAN-ID "100".

[0162] In step S108, the capacity issuance unit 12 performs registration in the entity DB 22 based on the allocation result (request amount / request value). In this example, the capacity issuance unit 12 performs registration (2205) of a capacity consuming entity and registration (2215) of an allocated capacity in the capacity providing entity.

[0163] <4> effect As described above in detail, in one embodiment of the present invention, a management device 1 is provided that includes a capacity management unit 10 and a management information DB 20. The management information DB 20 includes a spec DB 21 as a first storage unit and an entity DB 22 as a second storage unit, the first storage unit stores specification information representing specifications of a plurality of entities including the network 2 and ICT devices 3 to be managed, and the second storage unit stores entity information including information representing relationships between the plurality of entities. The capacity management unit 10 includes a capacity request acquisition unit 11 and a capacity allocation unit 12. The capacity request acquisition unit 11 is configured to receive an entity generation request for requesting generation of a first entity (e.g., capacity consuming entity 220) for the network 2 or the ICT device 3, read specification information for the first entity from the first storage unit, determine whether or not the first entity has a consumption specification attribute indicating that the first entity requires consumption of resources in the network 2 or the ICT device 3, and, if it is determined that the first entity has the consumption specification attribute, identify a second entity (e.g., capacity providing entity 221) capable of providing the capacity of the resource consumed by the first entity based on the entity information stored in the second storage unit. The capacity allocation unit 12 is configured to determine whether or not the capacity of the resource consumed by the first entity can be allocated based on the identified second entity, and, if it is determined that the capacity can be allocated, allocate the capacity to the first entity. Then, when multiple entity generation requests are received, the management device 1 allocates common resource capacity to the multiple first entities based on the second entities identified for each of the multiple first entities in the entity generation requests.

[0164] As a result, in the management device 1, the resource capacity in the network 2 or the ICT device 3 is automatically managed together with information on the entities consuming the resources and the entities capable of providing the resources, without the need for the judgment of a human operator. Therefore, in the network and ICT management system, the management of resources is automatically performed, and the operator's work can be reduced. Furthermore, in the management device 1, even the allocation of the resource capacity is automatically performed. Therefore, in the network and ICT management system, the resource management can be continuously performed based on the latest entity information that is updated from time to time, and the operator's work can also be reduced. Furthermore, when the management device 1 receives a plurality of entity generation requests, it allocates a common resource capacity to a plurality of first entities of the plurality of entity requests. Therefore, in the network and ICT management system that are not dependent on the network and ICT device to be managed, it is possible to manage resources in a coordinated manner and automatically allocate the coordinated resource capacity to a plurality of first entities.

[0165] Furthermore, in the above embodiment, when the capacity request acquisition unit 11 receives multiple entity generation requests, it groups the entity generation requests that require the same amount or value of resource capacity to be consumed, and the capacity issuance unit 12 determines whether or not the capacity of the common resource consumed by the multiple first entities can be issued for each of the multiple entity generation requests grouped together, and if the capacity can be issued, it issues the capacity of the common resource to each of the first entities of the multiple entity generation requests grouped together.

[0166] As a result, the management device 1 can group together from among the multiple entity generation requests received those that require the same amount or value of consumption resource capacity, thereby ensuring that the same amount or value of consumption resource capacity is assigned to multiple first entities that require the same amount or value of consumption resource capacity.

[0167] In addition, in the above embodiment, the specification information regarding the first entity stored in the first memory unit includes constraint condition information indicating other first entities that require the same amount or value of resource capacity to be consumed as the first entity, and the capacity requirement acquisition unit 11 groups the first entities determined to have the above consumption specification attribute based on the constraint condition information.

[0168] As a result, the management device 1 stores the constraint condition information of the equivalence constraint in advance in the first memory unit, and when grouping multiple accepted first entities, it can easily group equivalence constraint groups by searching for those that require the same quantity or value based on this constraint condition information.

[0169] In the above embodiment, the capacity of the resource to be allocated includes a part of the amount possessed by the second entity, such as a quantity of a bandwidth, a memory, a number of CPU cores, etc. Alternatively, the capacity of the resource to be allocated includes a value of an identifier that can be used by the second entity, such as a VLAN-ID, an MPLS label, etc.

[0170] This enables the management device 1 to commonly issue a portion of the amount held by the second entity, or an identifier value that can be used by the second entity, to multiple first entities for multiple entity requests.

[0171] In addition, in the above embodiment, the capacity issuance unit 12 may update the entity information stored in the second memory unit using information representing the result of the issuance of the capacity to the first entity, which includes information identifying the first entity to which the capacity is to be assigned and information representing the resource assigned to the first entity or the capacity of the resource, i.e., the assigned requested amount or requested value.

[0172] As a result, in the management device 1, the entity information is updated using information regarding what specific allocation has been performed, and appropriate resource management can be performed based on the updated detailed information.

[0173] Furthermore, in the above embodiment, the first entity is a logical layer entity constituting the managed network 2 or ICT device 3, and the second entity is a physical layer entity constituting the managed network or ICT device 3, and the capacity requirement acquisition unit 11 may be configured to accept a generation request for an entity of the logical layer as the entity generation request, and to identify the second entity based on information representing a relationship between the entity of the logical layer and the entity of the physical layer as the entity information to be stored in the second memory unit.

[0174] This allows the management device 1 to appropriately and automatically manage resource capacity by utilizing an architecture based on the relationship between logical layer entities and physical layer entities.

[0175] [Other embodiments] It should be noted that the present invention is not limited to the above embodiment. For example, each functional unit of the management device 1 may be distributed across multiple devices, and these devices may work together to perform processing. Each functional unit may be realized by using a circuit. The circuit may be a dedicated circuit for realizing a specific function, or a general-purpose circuit such as a processor.

[0176] The management device 1 can also be realized by a computer and a program, and the program can be recorded on a recording medium or provided via a network.

[0177] In addition, the flow of each process described above is not limited to the procedure described above, and the order of some steps may be changed, or some steps may be performed simultaneously in parallel. In addition, the series of processes described above do not need to be performed consecutively in time, and each step may be performed at any timing.

[0178] At least a part of the processing of each of the above embodiments can be realized by using, for example, a processor mounted on a general-purpose computer as basic hardware. The program for realizing the above processing may be provided by being stored in a computer-readable recording medium. The program is stored in the recording medium as a file in an installable format or an executable format. The recording medium may be a magnetic disk, an optical disk (CD-ROM, CD-R, DVD, etc.), a magneto-optical disk (MO, etc.), a semiconductor memory, etc. The recording medium may be any one that can store the program and is readable by a computer. In addition, the program for realizing the above processing may be stored on a computer (server) connected to a network such as the Internet, and downloaded to a computer (client) via the network.

[0179] In addition, the capacity delivery method and the like can be modified in various ways without departing from the spirit and scope of the present invention.

[0180] In short, this invention is not limited to the above-mentioned embodiment, and can be modified in various ways in the implementation stage without departing from the gist of the invention. In addition, each embodiment may be implemented in appropriate combination, in which case the combined effect can be obtained. Furthermore, the above-mentioned embodiment includes various inventions, and various inventions can be extracted by combinations selected from the multiple constituent elements disclosed. For example, if the problem can be solved and the effect can be obtained even if some constituent elements are deleted from all the constituent elements shown in the embodiment, the configuration from which the constituent elements are deleted can be extracted as an invention.

[0181] [Note] A part or all of each of the above-described embodiments can be described as shown in the appended notes below in addition to the scope of the claims, but is not limited thereto.

[0182] [C1] A first storage unit (21) that stores specification information representing specifications of a plurality of entities including a network and ICT devices to be managed; A second storage unit (22) for storing entity information including information representing relationships between the plurality of entities; a request acquisition unit (11) that receives an entity generation request for requesting generation of a first entity with respect to the network or the ICT device, reads specification information on the first entity from the first storage unit, determines whether the first entity has a consumption specification attribute indicating that the first entity requires consumption of resources in the network or the ICT device, and, when it is determined that the first entity has the consumption specification attribute, identifies a second entity that can provide the capacity of the resources consumed by the first entity based on the entity information stored in the second storage unit; a capacity allocating unit (12) that determines whether or not a capacity of a resource consumed by the first entity can be allocated based on the identified second entity, and allocates the capacity to the first entity when it is determined that the capacity can be allocated; Equipped with The capacity allocation unit, when receiving multiple entity generation requests, allocates common resource capacity to the multiple first entities based on the second entity identified for each of the multiple first entities in the multiple entity generation requests, a management device (1).

[0183] [C2] When the request acquisition unit (11) receives a plurality of the entity generation requests, the request acquisition unit (11) groups the entity generation requests that require the same amount or value of resource capacity to be consumed, The capacity issuing unit is determining whether or not a capacity of the common resource consumed by the plurality of first entities can be allocated for each of the plurality of entity generation requests grouped together; The management device according to [C1] above, wherein if it is determined that the capacity of the common resource is available for allocation, the capacity of the common resource is allocated to each of the first entities of the plurality of entity generation requests grouped together.

[0184] [C3] A management method executed by a management device (1), storing in a memory specification information representing specifications of a plurality of entities including a network and ICT devices to be managed, and entity information including information representing relationships between the plurality of entities; receiving an entity creation request for creating a first entity with respect to the network or ICT equipment; retrieving specification information relating to the first entity from the memory and determining whether the first entity has a consumption specification attribute indicative of a requirement for consumption of resources in the network or of the ICT equipment; if it is determined that the first entity has the consumption specification attribute, identifying a second entity that can provide capacity for the resource consumed by the first entity based on entity information stored in the memory; determining whether or not a capacity of a resource consumed by the first entity can be allocated based on the identified second entity; allocating the capacity to the first entity when it is determined that the capacity can be allocated; Equipped with A management method in which, when multiple entity generation requests are received, a common resource capacity is allocated to the multiple first entities based on the second entity identified for each of the multiple first entities in the multiple entity generation requests.

[0185] [C4] When executed by a hardware processor, the hardware processor: storing in a memory specification information representing specifications of a plurality of entities including a network and ICT devices to be managed, and entity information including information representing relationships between the plurality of entities; receiving an entity creation request for creating a first entity with respect to the network or ICT equipment; retrieving specification information relating to the first entity from the memory and determining whether the first entity has a consumption specification attribute indicative of a requirement for consumption of resources in the network or of the ICT equipment; if it is determined that the first entity has the consumption specification attribute, identifying a second entity that can provide capacity for the resource consumed by the first entity based on entity information stored in the memory; determining whether or not a capacity of a resource consumed by the first entity can be allocated based on the identified second entity; allocating the capacity to the first entity when it is determined that the capacity can be allocated; Including, when a plurality of the entity generation requests are received, a common resource capacity is allocated to the plurality of first entities based on the second entity specified for each of the plurality of first entities in the plurality of entity generation requests; A non-transitory computer-readable storage medium comprising instructions for carrying out a method. [Explanation of symbols]

[0186] 1...Management device 2. Network 3...ICT equipment 10…Capacity Management Department 11…Capacity request acquisition section 12…Capacity distribution section 20...Management information database 21…Spec Database 22…Entity Database 23…Function repository 231...Amount payment function 232...Value list output (lowest number) function 233...Value list output (old number) function 51…CPU 52…RAM 53...Program memory 54…Auxiliary storage device 55...Communication interface 56... Input / Output Interface 57…Bus 501...Equivalence constraint group OP...Operator

Claims

1. A management device having a hardware processor and a memory, The memory includes: A first storage unit that stores specification information representing specifications of a plurality of entities including a network and ICT devices to be managed; A second storage unit that stores entity information including information representing relationships between the plurality of entities; Equipped with The hardware processor includes: receiving an entity creation request for creating a first entity with respect to the network or ICT device; retrieving specification information relating to the first entity from the first storage unit and determining whether the first entity has a consumption specification attribute indicative of a requirement for consumption of resources in the network or of the ICT device; When it is determined that the first entity has the consumption specification attribute, identifying a second entity that can provide a capacity of the resource consumed by the first entity based on entity information stored in the second storage unit; determining whether or not a capacity of a resource consumed by the first entity can be allocated based on the identified second entity; allocating the capacity to the first entity when it is determined that the capacity can be allocated; configured to run When receiving a plurality of the entity generation requests, the hardware processor assigns a common resource capacity to the plurality of first entities based on the second entity specified for each of the plurality of first entities of the plurality of entity generation requests, grouping entity creation requests that require the same amount or value of resource capacity to be consumed; determining whether or not a capacity of the common resource consumed by the plurality of first entities can be allocated for each of the plurality of entity generation requests grouped together; when it is determined that the capacity of the common resource can be allocated, allocating the capacity of the common resource to each of the first entities of the grouped plurality of entity generation requests; configured to execute Management device.

2. the specification information on the first entity stored in the first storage unit includes constraint condition information indicating another first entity that requires the same amount or value of a resource capacity to be consumed as the first entity; The management device according to claim 1 , wherein the hardware processor is configured to execute grouping of entity generation requests by grouping the first entities determined to have the consumption specification attribute based on the constraint information.

3. 3 . The management device according to claim 1 , wherein the allocated resource capacity includes a portion of the amount possessed by the second entity, or a value of an identifier usable by the second entity.

4. 4. The management device according to claim 1, wherein the hardware processor is further configured to: update the entity information stored in the second memory unit using information representing a result of the allocation of the capacity to the first entity, the information including information identifying the first entity to which the capacity is to be allocated and information representing the resources allocated to the first entity or the capacity of the resources.

5. The first entity is a logical layer entity constituting the network or ICT device to be managed, and the second entity is a physical layer entity constituting the network or ICT device to be managed, The hardware processor includes: accepting a request for generating an entity of the logical layer as the entity generation request; identifying the second entity based on information representing a relationship between an entity of the logical layer and an entity of the physical layer as the entity information stored in the second storage unit; The management device according to claim 1 , configured to:

6. A management method executed by a management device having a hardware processor and a memory, comprising: The hardware processor includes: storing in the memory specification information representing specifications of a plurality of entities including a network and ICT devices to be managed, and entity information including information representing relationships between the plurality of entities; receiving an entity creation request for creating a first entity with respect to the network or ICT device; retrieving specification information relating to the first entity from the memory and determining whether the first entity has a consumption specification attribute indicative of a requirement for consumption of resources in the network or of the ICT device; identifying a second entity that can provide capacity for the resource consumed by the first entity based on entity information stored in the memory if the first entity is determined to have the consumption specification attribute; determining whether or not a capacity of a resource consumed by the first entity can be allocated based on the identified second entity; allocating the capacity to the first entity when it is determined that the capacity can be allocated; Equipped with When receiving a plurality of the entity generation requests, the hardware processor allocates a common resource capacity to the plurality of first entities based on the second entity specified for each of the plurality of first entities of the plurality of entity generation requests, grouping entity creation requests that require the same amount or value of resource capacity to be consumed; determining whether or not a capacity of the common resource consumed by the plurality of first entities can be allocated for each of the plurality of entity generation requests grouped together; when it is determined that the capacity of the common resource can be allocated, allocating the capacity of the common resource to each of the first entities of the grouped plurality of entity generation requests; A management method comprising:

7. A management program that causes a processor to execute each process of the management device according to any one of claims 1 to 5.

Images