JP2015159346A - federation method and network system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To virtually form a server for federation control on a slice and to create a user slice over domains of other virtualization bases while using the virtual server.SOLUTION: On an administrative slice created beforehand on a virtual network over a plurality of virtualization bases, a virtual node within one virtualization base and a virtual node within another virtualization base are formed and connected by a link, and a first virtual server is formed that performs the virtual nodes created on the virtualization bases, configuration definition information of a virtual network to be created on the other virtualization base is held in a nest structure. When creating a second slice on a virtual network over the one virtualization base and the other virtualization base, the first virtual server formed in the administrative slice instructs the creation of the second slice on the other virtualization base while using the configuration definition information acquired from the specific virtual node.

Description

  The present invention relates to a federation method and a network system, and more particularly to federation control for forming a virtual network spanning a plurality of virtual network infrastructure domains.

  Federation is proposed as a technology for realizing a wider range of virtual networks by linking domains of a plurality of virtual networks. With regard to this technology, for example, Patent Document 1 discloses a federation architecture between network domains. In this technology, when a slice definition is input to the virtualization infrastructure, the slice definition of the other virtualization infrastructure part is retained as an internal configuration of a special node (proxy node) of the own network virtualization infrastructure, Even in a virtualization platform that does not have the concept of other network virtualization platforms, it is possible to describe a slice that spans another network virtualization platform (hereinafter simply referred to as a virtualization platform).

  Patent Document 1 further uses “standard slice information” (common API) that does not depend on the virtualization infrastructure in communication between the gatekeepers (GK) that are the management servers for federation of each virtualization infrastructure. However, it is described that, by communicating once using this common API, the development of a federation function can be facilitated when the number of virtualization infrastructures that perform federation increases. That is, when directly converting the management commands of each virtualization platform without using a common API, it is necessary to develop API conversion functions as many as the number of virtualization platforms to be federated. As the number increases, the amount of development becomes enormous. On the other hand, if the common API is used, each virtualization platform only needs to develop a conversion function with the common API, and the development amount can be greatly reduced.

  The GK on the other virtualization platform side translates the slice definition on the other virtualization platform side sent via the common API into the management command on the other virtualization platform side, and manages it on the other virtualization platform side. Send to server. As a result, a slice on the other virtualization platform side is generated. By such processing, the slice designer can create a slice that spans the other virtualization infrastructures simply by inputting the slice definition on the other virtualization infrastructure side to the own virtualization infrastructure side.

JP 2013-102338 A

  According to the technique described in Patent Literature 1, it is possible to support federation in a virtualization platform that does not have the concept of another virtualization platform. However, as a management function for realizing federation, it is a transfer control server that exchanges commands between nodes with special functions for accepting slice definitions of other virtualization infrastructures and other virtualization infrastructures There is a restriction that GK must be provided as an architecture. In particular, when the virtualization platform that is to be linked by federation does not have the management function, federation cannot be performed.

  As a proposal to solve this problem, the inventors have considered a method of virtually realizing a management server for federation. That is, GK for realizing command exchange with other virtualization infrastructures is realized by using one of a plurality of virtual nodes. Specifically, a management slice for managing the federation is created across the virtualization platforms that perform the federation. In the management slice, virtual nodes having GK functions are placed on both virtualization platforms, and the GKs are connected by virtual links. As a result, even in a virtualization platform without a special management server GK having a federation function, the federation function can be provided as one of the software on the slice (without modifying the virtualization platform). .

  However, it has been found that there are further issues when implementing GK with software. In other words, in the slice definition created by federation, the slice definition of other virtualization infrastructure is described in a nested structure inside the proxy node, but the corresponding definition is transmitted to the GK realized by software and the federation is started. It is a point that cannot be done.

  In the conventional federation, GK is realized by hardware (physical node) and incorporated in the management system of the virtualization infrastructure. That is, in the federation described in Patent Document 1, the management server (NM) 102 and the GK 107 are connected by a link between management servers. When the slice definition is input to the virtualization platform, the management server sends the definition of the proxy node 390 to the GK. As a result, the GK can receive the nested definition in the proxy node and start the federation process.

  On the other hand, when GK is implemented by software as a virtual node, the proxy node that holds the slice definition of the other virtualization infrastructure when the slice definition is input to the proxy node is a virtual node created by federation However, the GK federation process is not activated. That is, since the management slice in which the GK exists and the slice created by the federation are different slices, the contents of the proxy node are not transmitted to the GK and the federation cannot be activated. It should be noted here that, in the virtualization infrastructure, slices are separated, so even if a proxy node is assigned to the same physical node as GK, GK knows that the proxy node has been created. It is not possible.

  Further, the same problem occurs when the federated slice is deleted or the configuration is changed. When a slice deletion or configuration change (including a configuration change of a nested structure inside a proxy node) is performed in the local virtualization infrastructure, the federated slice of another virtualization infrastructure is deleted and the configuration is changed via GK. There is a need.

  Furthermore, after creating a node on the virtualization infrastructure, the slice designer needs to log in to the created node, perform initial settings, and install a program. In a federation, when a slice that spans another virtualization infrastructure is created, it is necessary to log in to the node created on the other virtualization infrastructure from the own virtualization infrastructure. Of course, the node of the other virtualization infrastructure can be accessed through the management system of the other virtualization infrastructure, but it is desired to realize a method of logging in from the own virtualization infrastructure.

Therefore, a main object of the present invention is to virtually form a server for federation control on a slice, and to create a user slice that spans other virtualization infrastructure domains using this virtual server.
Another object of the present invention is to enable creation, configuration change, and deletion of a user slice of another virtualization infrastructure by federation using a virtual server virtually formed on a slice.
Still another object of the present invention is to enable an administrator to log in to a virtual node placed on another virtualization infrastructure of a slice created by federation.

In the federation method according to the present invention, preferably, each of a plurality of network virtualization infrastructures connects a physical network between a plurality of physical nodes, a physical network connecting the physical nodes, and another network virtualization infrastructure. And a first server that performs federation control corresponding to the network virtualization infrastructure, and a second server that manages the network virtualization infrastructure, and a virtual node is provided on the physical node of each network virtualization infrastructure. A federation method for performing a federation to form a virtual network across a plurality of network virtualization platforms under the control of the first server,
Create a first slice in a virtual network that spans multiple network virtualization platforms,
The virtual node in the own network virtualization infrastructure and the virtual node in the other network virtualization infrastructure formed on the first slice are connected by a link, and the first server as the first server that performs federation control on the virtual node. Configure one virtual server,
Holding the configuration definition information of the virtual network created in the other network virtualization infrastructure in a specific virtual node of the virtual nodes created in the network virtualization infrastructure;
When creating a second slice in a virtual network spanning the own network virtualization infrastructure and the other network virtualization infrastructure, the first virtual server formed in the first slice receives the configuration definition information from the specific virtual node. Is obtained, and the configuration definition information is used to instruct the creation of the second slice in the other network virtualization platform.

In a preferred example, the specific virtual node holds a start script for starting the first virtual server, and the first virtual server starts federation by the start script.
Preferably, the first virtual server includes information on a slice name in the own network virtualization infrastructure, a destination virtualization infrastructure name indicating another network virtualization infrastructure that issues a request for federation, and information on a slice design drawing of the other network virtualization infrastructure. Has a management table to hold,
When a slice is created by federation, a new entry is created in the management table, and the slice name, the destination virtualization platform name, and information on the slice design drawing of another network virtualization platform are registered in the entry.

Preferably, the first virtual server placed on each network virtualization infrastructure periodically sends the configuration definition information of the virtual network to each virtual network generated from the network virtualization infrastructure and federated. 2 Inquire server,
When the configuration definition information is changed, the virtual network is instructed to change the configuration definition information to the first virtual server placed on the network virtualization platform that is the destination of the federation.
Also preferably, when the first virtual server detects deletion of the second slice in its own network virtualization infrastructure, the first virtual server is on the other network virtualization infrastructure included in the second slice. Instructs deletion of the corresponding virtual network.

Also preferably, when creating a virtual network of another network virtualization infrastructure by federation, a link connecting the specific virtual node created in the own network virtualization infrastructure and a virtual node created in the other network virtualization infrastructure Is automatically generated.
Also preferably, the startup script has a file name of the startup script, an address of the first virtual server, and a slice name of the own network virtualization infrastructure created by federation.

Also preferably, the second server receives the first configuration definition information on the local network virtualization infrastructure side related to the creation of the second slice, which is input from a terminal connected to the second server, and the other network. Holding the configuration definition information (second configuration definition information) on the virtualization platform side,
The second server uses the first configuration definition information to form a virtual node in the second slice,
The specific virtual node acquires the second configuration definition information from the second server and holds it as nested data.

  The present invention is also configured as a network system that performs federation to form a virtual network that spans multiple network virtualization platforms.

According to the present invention, a server for federation control can be virtually realized on a slice, and a user slice that spans domains of other virtual network infrastructures can be created using this virtual server.
In addition, it is possible to create, change the configuration, and delete the user slice of another virtualization platform by federation using the virtual server of the own virtual platform formed virtually on the slice.
In addition, by having a function to automatically create a link between the node created in the other virtualization infrastructure and the node that manages the federation in the own virtualization infrastructure, the management system of the other virtualization infrastructure is reduced. Without going through, the administrator can log in from the own virtualization platform for setting up virtual nodes created in other virtualization platforms and installing programs.

1 is a diagram illustrating a configuration of a network system that performs federation in Embodiment 1. FIG. 2 is a configuration diagram of a physical node 12. FIG. 2 is a configuration diagram of a physical node 13. FIG. 2 is a configuration diagram of a management server 19. FIG. It is a time chart figure showing the creation operation of a slice. It is a time chart showing the deletion operation of a slice. It is a figure which shows the management table of the slice which the creation request | required with respect to the other virtualization infrastructure from the own virtualization infrastructure. It is a figure which shows the management table of the slice from which the creation request | requirement was carried out with respect to the own virtual infrastructure from the other virtualization infrastructure. It is a figure which shows the management table of other virtualization infrastructures. It is a figure which shows the structural example of a slice definition. It is a figure which shows the structural example after producing | generating the link for login automatically with respect to a slice definition. It is a figure which shows the example of the slice definition after converting into common API. It is a figure which shows the example of the slice definition input into the management server 29 of the virtualization infrastructure 20 converted from common API. It is a figure which shows the command format of common API. It is a figure which shows the command list of common API. It is a figure which shows the operation | movement flow of the starting script of PVN. It is a figure which shows the operation | movement flow of the shutdown script of PVN. It is a figure which shows the operation | movement flow of the polling by VGK410. FIG. 10 is a configuration diagram of a network system that performs federation in Embodiment 2. FIG. 10 is a diagram illustrating an example of a slice definition sent by a common API in the federation according to the second embodiment.

<System configuration>
FIG. 1 shows the overall configuration of a network system for federation. In FIG. 1, the physical configuration is shown below the dotted line, and the logical configuration is shown above the dotted line. As a physical configuration, there are two virtualization platforms 10 and 20. The virtualization infrastructure 10 includes physical nodes 11, 12 and 13 for creating a virtualization network, a network 15 within the virtualization infrastructure, and a gateway (GW) 16 for connecting a data system to other virtualization infrastructures, Further, as a management system, a management server 19 that manages the virtualization platform 10 is provided. Similarly, the virtualization platform 20 includes physical nodes 21 and 22, a network 25, a gateway (GW) 26, and a management server 29.

  The GW 16 and the GW 26 in the virtualization infrastructures 10 and 20 are connected by a data plane 90 between virtualization infrastructures. This embodiment is intended to realize federation between virtualization infrastructures that do not have a federation management function, and assumes that data plane connection can be established between the virtualization infrastructures 10 and 20 via some gateway function. . The GWs 16 and 26 have a function of interconnecting the data plane (VLAN or GRE tunnel) between the virtualization infrastructures and the data plane of the network between virtualization infrastructures (VLAN, encapsulation by MAC header, etc.), for example, VLAN. This is realized by a network device having a number conversion function. In this example, the link between virtualization infrastructures is implemented by VLAN. However, various implementations such as implementation by GRE (Generic Routing Encapsulation) other than VLAN and a method of distinguishing links by destination MAC addresses of gateways are possible. is there.

  In this example, a management slice 400 that realizes a federation function is created in advance on the virtualization platform having the above physical configuration. Further, the user slice 300 is created across the virtualization platforms 10 and 20 by the federation function of the present invention. On the management slice 400, VGK (Virtual Gate Keeper) 410 and 420, which are management servers that realize a federation function for each virtualization infrastructure, are formed as virtual nodes (VMs) of virtual nodes, and these VGKs are federated management links. 430 is connected. In each virtualization infrastructure, a shared VLAN for performing communication between slices for federation management is placed. A shared VLAN 1 (190) is placed in the virtualization infrastructure 10 and a shared VLAN 2 (290) is placed in the virtualization infrastructure 20 and connected to another network port of each VGK 410.420. It is assumed that the management slice 400 including the VGKs 410 and 420 and the inter-VGK link 430 and the shared VLANs 190 and 290 in the virtualization infrastructures 10 and 20 are created in advance in preparation for operating the federation function described below. .

  Virtual nodes 310, 320, 330, 340, and 350 are created in the user layer slice 300, and these virtual nodes are mapped to physical nodes 11, 12, 13, 21, and 22, respectively (the vertical dotted line box is enclosed). Shows the mapping between logical and physical). The proxy node (PVN: Pseudo Virutal Node) 390 creates a federation created by the administrator (sometimes referred to as a network designer or a slice designer) that creates a slice in the virtualization infrastructure 10 on the side that inputs the slice definition. A special virtual node to do. In this example, the proxy node is mapped to the physical node 12. In the proxy node 390, a slice definition for the virtualization infrastructure 20, specifically, a slice definition of the virtual nodes 340 and 350 is described in a nesting (Nest) definition 3901 in the proxy node 390. The proxy node 390 further includes a VGK trigger activation script 3902 for instructing the VGK 410 on the management slice 400 to start the federation process when a user slice 300 is newly created. The PVN 390 is connected to the shared VLAN 190 to which the VGK 410 existing in the same virtualization infrastructure 10 is connected.

  Terminals 80 and 81 operated by an administrator are connected to the management servers of the virtualization infrastructures 10 and 20. The administrator operates these terminals 80 and 81 to manage the virtual network (for example, creation, deletion, configuration change, etc.). FIG. 13 shows an example of a virtual network management command transmitted between the virtualization platforms by the common API. The federation in the present embodiment realizes the processing for managing the virtual network only with a command on one virtualization platform side from one virtualization platform terminal. This example will be described as an example in which federation is performed by an operation from the terminal 80 of the virtualization platform 10.

  Here, the mapping between the virtual node, the proxy node, and the physical node is not limited to the example in FIG. 1 and is arbitrary. A configuration other than the above mapping, for example, a virtual node in which the VGK 410 of the management slice 400 is formed and a virtual node for the PVN 390 formed in the user slice 300 may be mapped to the same physical node. Further, in the example of FIG. 1, only one slice 300 is shown as the user slice 300 created by the federation, but any number of user slices can be created as long as the resource permits. Moreover, it is possible to coexist with a slice (with no federation) closed in each virtualization platform.

  The virtual link 380 indicated by a dotted line in the user slice 300 is used for the administrator to log in from the terminal 80 to the virtual nodes 340 and 350 created in the other virtualization infrastructure (the virtualization infrastructure 20 in the example of FIG. 1). This is a link automatically generated by this embodiment. By connecting the nodes 340 and 350 created on the virtualization infrastructure 20 with the PVN 390, the administrator can log in, set up, and program the virtual nodes 340 and 350 created on the other virtualization infrastructure 20 via the PVN 390. Installation and the like can be performed.

  Next, the nodes 12 and 13 are shown as examples of the physical node architecture. Other nodes have a similar architecture.

<Configuration of physical node>
FIG. 2 shows the configuration of the physical node 12. The physical node 12 includes a switch 1220 that controls packet transfer and a server unit 1200 that supports advanced node functions realized by a virtual network. The physical node 12 is connected to the external physical network 15 via the switch 1220.

  The server unit 1200 implements the function of each virtual node by a VM (Virtual Machine). The lower side of the server unit 1200 shows the physical configuration of the server having the CPU 1210, the memory 1211, the network interface 1212 and the storage 1213, and the upper side shows a program operating on the server. The server unit includes a hypervisor 1201 for operating the VM and a virtual switch 1202 that manages external communication with the VM. Each VM operates under the management of the hypervisor 1201. In this example, a VM 320 that supports virtual nodes and a VM 390 that supports PVN are operating. Each VM includes a virtual CPU 321, a virtual main memory 322 of the VM, and virtual NICs 323 and 324 assigned to each VM. Each VM communicates with an external network through a virtual NIC and a virtual switch. In the virtual main memory 392 of the VM 390, a PVN program 398 and PVN management data 399 are placed in addition to the virtual node program and data area. Each program of each VM is executed by the virtual CPUs 321 and 391.

  FIG. 3 shows the configuration of the physical node 13. The basic configuration of the physical node 13 is the same as that of the physical node 12. However, the physical node 13 has a unique virtual configuration in order to implement the VGK 410. That is, as a virtual function, a VGK 410 that performs federation management with the virtual node 330 is provided. A VGK program 418 and a management table 419 are placed in the VGK 410 virtual main memory 410, and the VGK program is executed by the virtual CPU 411. The VGK program 418 includes a program for performing the sequence operation shown in FIGS. The configuration of the management table 419 will be described later with reference to FIGS.

FIG. 4 shows the configuration of the management server 19 in the virtualization infrastructure.
The management server 19 is provided with a CPU 1910, a main memory 1920, and NICs 1930 and 1940 for communicating with the outside. A virtualization infrastructure management program 1921 and a virtualization infrastructure management table 1922 are placed in the main memory 1920 of the management server, and this program 1921 is executed by the CPU 1910. The management server 29 has the same configuration.

  FIG. 7A, FIG. 7B, and FIG. 7C show the management tables of each VGK (410, 420) that performs federation management. The VGK has a pool of VLAN numbers for managing three management tables and VLAN numbers of links between virtualization infrastructures.

  FIG. 7A is a management table of slices requested to be created from the own virtualization platform to another virtualization platform. In the management table 701, one line entry is formed for each slice created by federation. The management table 701 holds the slice name in the own virtualization infrastructure, the destination virtualization infrastructure name indicating the other virtualization infrastructure that issues a request for federation, the slice design drawing information of the other virtualization infrastructure, and the initial activation process execution flag. To do. Here, in the destination virtualization infrastructure name field, a plurality of destination infrastructure names can be described in order to support federation among three or more virtualization infrastructures. The information of the slice design drawing of the other virtualization infrastructure has the contents indicated by the nested definition 3901 in the proxy node 390, and is described in the XML format.

  FIG. 7B is a management table of slices requested to be created from the other virtualization infrastructure to the own virtualization infrastructure. Similarly to the management table 701, one entry is added to the management table 702 every time a slice is created by federation. The management table 702 holds the slice name on the own virtualization platform side, the request source virtualization platform name, and the original slice name in the request source virtualization platform. Here, the slice name on the own virtualization platform side is a name created by the VGK 410 of the own virtualization platform when a slice creation request by federation from another virtualization platform arrives. In the illustrated example, the original slice name and the request source virtualization platform name are displayed connected with a hyphen.

FIG. 7C is a management table for managing the mounting information of other virtualization platforms.
The management table 703 holds a VGK address and a gateway address for each virtualization platform at the other end. The VGK address is a local IP address of a VGK port connected on the inter-VGK link 430 on the federation management slice 400, and is used to send a control system command for federation. The gateway address is a MAC address of a gateway on the network 90 that connects between the respective virtualization infrastructure gateways (GWs). Here, it is assumed that the gateways are L2 networks. Packets in each virtualization platform are encapsulated by the MAC header in the network between the gateways, and sent to the destination virtualization platform gateway. As a result, the dependency between the network between the platforms and the packet on each virtual network can be eliminated. Multiple links are distinguished by VLAN numbers.
The management table 701 and the management table 702 are initially empty, and entries are added when federation is performed. For the management table 703, data necessary for the administrator is set when the VGKs 410 and 420 are created.

  A feature of the present embodiment is that the VGKs 410 and 420 having a federation management function are virtually realized on the management slice 400, and the virtual infrastructure on the side where the slice definition is input by the administrator in the slice definition of the virtual network 10, a proxy node 390 that performs federation control is placed, and the VGK federation process is started by the start script 3902 when the proxy node is started.

<Federation action>
The operation of federation will be described with reference to system configuration diagrams (FIGS. 1 to 4) and time charts FIGS. In this embodiment, the system has two virtualization platforms, a virtualization platform 10 and a virtualization platform 20. An example will be described in which the administrator operates the terminal 80 on the virtualization platform 1 side to control slice creation, configuration change, deletion, and the like.

  Prior to federation control, the management slice 400 needs to be created. That is, VGKs 410 and 420 are formed on the virtualization infrastructures 10 and 20, and a network 430 for connecting these VGKs is formed. Further, shared VLANs 190 and 290 for accessing the VGK are formed in each virtualization infrastructure. The shared VLAN is a VLAN for performing communication between slices, and any slice can connect to the corresponding VLAN and perform communication. With the shared VLAN, a proxy node (PVN) 390 in the user slice 300 created later can communicate with the VGK 410 created in advance in the own virtualization platform. The management slice and the shared VLAN are created in advance by individually accessing the management servers 19 and 29 of each virtualization base as preparation for performing federation. It will take time to create the management slice 400 first, but once the management slice is created by the administrator providing the federation function, the administrator manages the creation of the user slice 300 thereafter. It can be easily created using a federation function formed on the slice 400.

  Next, the operation when creating a user slice will be described. A slice creation manager uses the terminal 80 to input design information (slice definition) of a slice to be created to the virtualization platform 10. Specifically, the definitions of the virtual nodes 310, 320, and 330 and the definition of the proxy node 390 (including the nested definition 3901 inside) are input from the terminal 80 to the management server 19.

  FIG. 8 shows an example of a slice definition that is input to the virtualization platform 10. Although the slice definition is shown in FIG. 8 in the figure, the structure shown in the figure is actually expressed by XML data. The slice definition includes three normal virtual node definitions (310x, 320x, 330x) and proxy node (PVN) definitions (390x). In the definition of virtual nodes (310x, 320x, 330x), the nodes are connected by virtual links, and the definition of virtual nodes (330x) is connected to the definition of link A (360x) connecting the virtualization infrastructures in the gateway. The proxy node definition (390x) is connected to the shared VLAN1 definition (190x). The shared VLAN 1 is used for communication with the VGK. These nodes are created by the own virtualization platform 10.

  The definition (390x) of the proxy node includes a slice definition 3901 of another virtualization infrastructure as nested data. Specifically, the tag representing the data of a predetermined nested structure surrounds the definition of the virtualization infrastructure of the other virtualization infrastructure and is included in the definition of the proxy node. This tag is registered as an extension tag in the management system so that it is ignored by the management system (management server 19) of the own virtualization platform 10. Thereby, since the management system of the own virtualization platform 10 does not interpret the data inside the nested structure, the slice structure for the other virtualization platform unit 20 can be freely described.

  In the nested structure definition 3901, first, a frame 3903 representing a virtualization platform to which a slice is created is placed. In general, a plurality of frames 3903 may be provided. In the frame 3903 representing the virtualization infrastructure, the slice name of the slice creation destination is designated in the field 3903a (in this example, domain 2 representing the virtualization infrastructure 20 is designated) and the slice definition body is held. Even when three or more virtualization infrastructures are federated, the virtualization infrastructures of slice creation destinations can be distinguished by surrounding them in the frame 3903.

  In the frame 3903 representing the virtualization infrastructure, the configuration of the slice created in the other virtualization infrastructure 20 is described by the slice description method of the own virtualization infrastructure 10. Since it can be described in the description method of its own virtualization platform, the administrator does not need to learn the control commands and slice description methods of other virtualization platforms. That is, a federated slice including another virtualization platform can be created by the operation method of the own virtualization platform. In this example, two virtual nodes are defined (340x, 350x) and connected by a virtual link. The node definition 340x is connected to the definition (4x) of the virtual infrastructure link A that connects the virtualization infrastructures in the gateway (GW). Here, since the node 330x defined in the virtualization infrastructure 10 and the node 340x defined in the virtualization infrastructure 20 are connected to the same virtualization infrastructure link definition 360x, they cross the virtualization infrastructure. Data ring is created.

  In the definition (390x) of the proxy node (PVN), a start script 3902 for triggering the VGK federation process is further described. That is, a program for starting federation of the corresponding slice is specified by specifying VGK as the start script of the virtual server 390 of the proxy node. As shown in FIG. 8, the startup script 3902 is created by federation of the script file name (3902a), the VGK address (3902b) (the address on the shared VLAN (190) of the VGK (410)), and the federation. It has a slice name (3902c) of its own virtualization platform. Here, the VGK address 3902b is used by the script to access the VGK, and the slice name 3902c is used later by the VGK 410 to inquire the management server 19 about the slice definition created by the federation.

  The slice definition described above is created by the administrator on the virtualization platform 10 side. The administrator can operate the terminal 80 on the virtualization infrastructure 10 side to specify the slice configuration to be created in the virtualization infrastructure 20 by using the nested structure 3901 in the proxy node, and further, the federation process can be performed by the start script 3902. Execution can be instructed.

  Next, the slice creation operation will be described with reference to the term chart of FIG. The left side of the time chart shows the components of the virtualization platform 10 and the right side shows the components of the virtualization platform 20. The slice creation here includes up to slice creation and activation processing.

  First, the definition shown in FIG. 8 is input from the terminal 80 of the virtualization platform 10 to the management server 19, and a federation slice creation instruction is issued (5000). The management server 19 performs slice creation processing for the virtualization infrastructure 10 based on the slice definition held by itself (5001). Specifically, virtual nodes 310, 320, and 330 and a proxy node (PVN) 390 to be formed on the user slice 300 are created. Each node is activated after these nodes are created. As a result, PVN 390 is similarly activated (6000). A startup script 3902 is defined in the PVN 390, and the federation process of the VGK 410 is triggered by the startup script of the PVN (5002).

  The VGK 410 triggered by the PVN 390 performs the following processing. First, the VGK 410 uses the slice name 3902c designated at the time of triggering to inquire the management server 19 of the virtualization platform 10 via the internal network 15 and obtains design information of the slice of the virtualization platform 10 (5003). This process is performed using the same interface that the administrator inquires about the design information of the virtual network from the terminal 80. Specifically, the slice definition of the created slice (the contents of FIG. 8), the IP address assigned to each node as a result of mounting the slice, and the like are obtained. At that time, the VLAN number actually assigned to the definition of the link A (360x) between the virtualization platforms allocated to the gateway (GW) 16 is also obtained (in this example, it is referred to as VLAN 100). The gateway (GW) 16 encapsulates a packet on the inter-virtual infrastructure virtual link 360 extending from the virtual node 330 in the virtualization infrastructure 10 with the L2 header, and sends it to the physical network 90 between the virtualization infrastructures. Set as follows. At that time, the destination MAC address is the MAC address of the virtualization platform 20 (domain 2) shown in FIG. 7C, and the VLAN number is a free VLAN number obtained from a pool of VLAN numbers managed by VGK.

  When the VGK 410 obtains the slice design information, the slice definition created in the other virtualization infrastructure (virtualization infrastructure 20) is extracted from the nested structure 3901 in the slice definition (6001). In this example, the definition created in the virtualization platform 20 within the 3903 frame in 3901 of FIG. 8 is obtained. The VGK 410 creates an entry in the slice management table 701 requested to be created from the own virtualization infrastructure to the other virtualization infrastructure, and the slice name, destination virtualization infrastructure name, and other virtualization infrastructure extracted in step 6001 are included in the entry. The XML data of the slice definition is stored (6002).

  As the next process, the VGK 410 performs an automatic setting process for a link (380 in FIG. 1) for the administrator to log in from the terminal 80 to a node created in another virtualization infrastructure. That is, processing for generating an administrator login link of the own virtualization platform 10 via the management server 19 to modify the slice (5004), and creating a slice definition to be sent to the other virtualization platform 20 to create another virtualization platform Processing for generating 20 administrator login links is performed (6003).

FIG. 9 shows the slice definition after modification. A dotted line portion is a portion modified by the above processing. Here, the creation of the administrator login link in the self and other virtualization infrastructures is referred to as “modification” in the sense that the definition of the slice is changed as compared with the past. By this process, the following parts are specifically modified.
(A) A new link Z (380x) that connects the virtualization platforms to the gateway (GW) of the own virtualization platform is newly defined, and a link is generated with the PVN node (390x) of the own virtualization platform. (Step 5004). The link mounting information (VLAN number) obtained as a result is stored.

  (B) The definition of the link Z (380x) connecting the virtualization infrastructures is added to the slice definition sent to the other virtualization infrastructures, and the virtual nodes (generally plural) generated in the other virtualization infrastructures A link definition (3800) is created between them (step 6003). Here, only the slice definition sent to the other virtualization platform is modified, and the definition in the slice management table 701 requested to be created from the own virtualization platform to the other virtualization platform shown in FIG. 7A is not changed.

  The VGK 410 then converts the modified slice definition into a common API (6004), and adds the mounting information (VLAN number in this example) of the link between virtualization platforms obtained from the management server 19 to the common API (6005). FIG. 10 shows a common API related to the slice shown in FIG. Although shown here by a diagram, the common API is implemented by XML-RPC or the like.

  Through the common API, the configuration of slices created in other virtualization platforms and the implementation information of links between virtualization platforms are sent. In FIG. 10, a node 3920 is a pseudo node representing the virtualization infrastructure 10. In the common API, since it is not necessary to convey the internal configuration of the request source virtualization infrastructure (virtualization infrastructure 10), only the information of the frame representing the virtualization infrastructure 10 is sent. Reference numeral 3921 denotes a frame representing the boundary of the virtualization platform 20. When performing federation across three or more virtualization infrastructures, there are a plurality of requested virtualization infrastructures, and therefore a boundary across the virtualization infrastructures is essential. In a frame 3921, the name of the requested virtualization platform is indicated by a field 3921a. In this case, domain2 representing the virtualization infrastructure 20 is designated.

  In the frame 3921, nodes to be created in each requested virtualization platform and links within the virtualization platform are defined. In this example, two virtual nodes (340y, 350y) are defined, and these nodes are connected by a link. The common API further defines a link between virtualization infrastructures. In this example, on the original slice definition, the definition 360y corresponding to the link A (360) between virtualization platforms that connects the virtual node 330 placed on the virtualization platform 10 and the virtual node 340 placed on the virtualization platform 20 The definition 380y corresponding to the inter-base link Z (380) automatically generated for the administrator to log in to the node created in the virtual base 20 is placed. Further, link implementation information (VLAN number) is embedded in the definition of each link between virtualization platforms of the common API. In this example, VLAN 100 is specified for link A, and VLAN 101 is specified for link Z.

  The VGK 410 of the virtualization platform 10 sends the common API obtained as described above to the VGK 420 of the virtualization platform 20 via the inter-VGK link 430 (5005). FIG. 12 shows a common API format. In the common API, a request source virtualization platform name, a request destination virtualization platform name, a slice name in the request source virtualization platform, and a slice definition are described. The slice definition includes a node definition and a link definition.

  The VGK 420 of the virtualization platform 20 that has received the common API generates design information of the virtualization platform 20 based on the slice definition included in the common API (6006). This design information is described in the notation of the virtualization platform 20. FIG. 11 shows a slice definition generated by the virtualization platform 20 corresponding to the common API shown in FIG. Two virtual node definitions (340z, 350z) and network accommodation definitions (3930, 3931) in the gateway (GW) 26 are described. Here, the network accommodation definition is a definition for accommodating the inter-virtual infrastructure link VLAN specified by the corresponding VLAN in the GW 26 and connecting to the link between the virtualization infrastructures.

  The VGK 420 of the virtualization platform 20 instructs the management server 29 of the virtualization platform 20 to create the slice of the virtualization platform 20 obtained as described above (5006), and the slice of the virtualization platform 20 is created (5007). ). This slice generation process is requested through the same interface as that used when a virtual network terminal instructs the management server to create a virtual network. When the virtual network creation instruction is issued, the network accommodation of the link between virtualization infrastructures is set in the GW 26, and the links between virtualization infrastructures 360 and 380 are connected. By setting the mounting information (VLAN number) in the virtualization platform 10 added to the common API in step 6005 also in the virtualization platform 20, the corresponding link between virtualization platforms can be connected. The VGK 420 of the virtualization platform 20 obtains a slice creation result from the management server (5008), and returns the result to the virtualization platform 10 using a common API (5009).

Normally, the following information is sent as a result returned by the common API.
-Success or failure of slice creation on the virtualization platform 20.
Information such as the IP addresses of the virtual nodes 340 and 350 connected to the other virtualization infrastructure node login link 380 (the administrator of the virtualization infrastructure 10 can obtain the above information from the VGK 410 of the virtualization infrastructure 10).
If the VLAN number of the link between virtualization infrastructures requested by the virtualization infrastructure 10 side with the common API cannot be used in the virtualization infrastructure 20 for some reason, the new VLAN number (the VGK of the virtualization infrastructure 10 uses the above VLAN number as the gateway Reset to (16)).

  As a result of the above processing, even in a virtualization infrastructure that does not have a federation function (that is, the virtualization infrastructure 20), the administrator of the virtualization infrastructure 10 passes through the VGK 410 for federation control realized by software using a virtual server. A slice of the virtual network including the virtualization infrastructure 20 can be created.

<Delete slice>
Next, processing for deleting a slice created by federation will be described.
FIG. 6 shows a time chart for deleting a created slice by federation in accordance with an instruction from the virtualization platform 10. Unlike slice creation, slice deletion is difficult to detect with PVN on the slice. The reason is that, unlike the case of slice creation, slice deletion cannot be detected by a script in PVN 390. Note that the slice deletion cannot be detected by the shutdown script of the PVN node (it cannot be distinguished from when the node is restarted).

  For the above reason, in the preferred example of the present invention, the VGK 410 detects that a slice has been deleted. Each VGK stores, in the management table 701, a list of slices requested to be created by the federation from the own virtualization platform to another virtualization platform. The VGK 410 periodically polls the management server 19 of the own virtualization infrastructure for slice design information (status, design drawing) based on the “own virtualization platform slice name” field in the management table 701 (5100-5101). 5102). As described above, the VGK of each virtualization platform polls the federation slice design information input from the own virtualization platform. This polling process is also used for changing the configuration of the virtualization infrastructure, which will be described later.

  When deleting a slice created by federation, a request to delete the slice created by federation is sent to the management server 19 from the terminal 80 of the virtualization platform 10 by an operation of the administrator. Specifically, a command for deleting the virtual nodes 310, 320, 330 and the PVN node 390 created in the virtualization platform 10 is issued. Upon receiving the delete command, the management server 19 deletes the entire slice of the virtualization infrastructure 10 including each designated node (5201). As a result, when the design information of the corresponding virtualization platform is polled in step 5102, information indicating that the corresponding slice (of the virtualization platform 10) has already been deleted is transmitted.

  The VGK 410 that has received the information detects that the slice has been deleted (6100). Based on the “destination virtualization platform name” field of the management table 701, a request to delete the corresponding slice is sent to the VGK 420 of the virtualization platform 20 by the common API (5202). The VGK 420 of the virtualization platform 20 that has received this common API refers to the “own virtualization platform slice name” field of the entry of the corresponding slice in the management table 702, and applies to the management server 29 of the virtualization platform 20. To delete the portion of the virtualization infrastructure 20 of the slice to be executed (5203). The management server 29 deletes the slice of the virtualization infrastructure 20 (5204), and notifies the result to the VGK 420 of the virtualization infrastructure 20 (5205). The VGK 420 of the virtualization platform 20 notifies the result to the VGK 410 of the virtualization platform 10 using a common API (5206).

  Through the processing described above, the administrator operates the terminal 80 to issue a deletion instruction to the management server 19 of the virtualization infrastructure 10, whereby the slice 300 created by federation can be deleted. In this process, since VGK 410 uses polling to detect deletion of a slice, there is a time difference from when a deletion request is issued to a slice of the virtualization infrastructure 10 until the slice of the virtualization infrastructure 20 is deleted. If the polling interval is set appropriately, there will be no problem. For example, if the polling interval is set to 3 minutes, slices that are no longer needed for other virtualization infrastructures can be deleted within 3 minutes.

<Slice change>
Next, the configuration change processing of the virtual network will be described. A change request from the administrator terminal 80 is sent to the management server 19 of the virtualization platform 10. When the configuration of the virtualization platform 20 is changed, the nested definition 3901 in the PVN definition (390x) shown in FIG. 8 is changed. The processing sequence of the change processing is performed in the same sequence as that in the case of slice deletion shown in FIG. (In the following description, FIG. 6 is referred for convenience.)
The VGK 410 of the virtualization platform 10 receives the design information (design drawing) of the slice input from the own virtualization platform 10 and created by federation by polling (5100 to 5101, 5102) to the management server (19) periodically performed. ) The VGK 410 compares the blueprint obtained by polling with the previous blueprint stored in the management table of FIG. 7A. As a result of the comparison, if it is determined that the design drawing of the virtualization infrastructure 20 has been changed (corresponding to step 6100 in FIG. 6), the VGK 410 of the virtualization infrastructure 10 sets a common API to the VGK 420 of the virtualization infrastructure 20. Used to send a design drawing of a new (changed) slice (corresponding to step 5202 in FIG. 6). The VGK 420 sends a slice configuration change command specific to the virtualization infrastructure 20 to the management server 29 of the virtualization infrastructure 20 and instructs to change the slice configuration (corresponding to step 5203 in FIG. 6). When sending the slice configuration change command, the slice design drawing necessary for creating the administrator login link is also modified. The processing flow of this part is the same as that at the time of slice creation.
As described above, it is possible to change the configuration of another virtualization infrastructure slice created by federation by the same operation sequence as the slice deletion shown in FIG.

<Polling process>
FIG. 15 shows the operation content of a polling program which is one of the VGK programs 410. The polling program is activated when VGK is created and repeats the following processing. First, after extracting one entry from the slice management table 701 requested to create from the own virtualization infrastructure to another virtualization infrastructure shown in FIG. 7A (7200), the latest design of the slice is stored in the management server 19 of the own virtualization infrastructure. Information is inquired (7201). Then, it is confirmed whether the slice of the own virtualization infrastructure 10 has been deleted (7202). If the slice has been deleted, a common API command for deleting the slice of the other virtualization infrastructure is sent to the VGK 420 of the other virtualization infrastructure 20 (7209). In addition, the corresponding slice is deleted from the management table 701 (7210). The slice deletion process is as described in the slice deletion process described above. Thereafter, the VGK 410 waits for a predetermined time (polling interval) (7205), and proceeds to processing of the next entry in the management table 701 (7206). In the case of the last entry, the process returns to the first entry.

As a result of the confirmation, if the slice of the own virtualization infrastructure 10 is not deleted, the slice design drawing obtained from the management server 19 is compared with the previous design drawing stored in the management table 701 (7203). ), It is determined whether the slice design drawing of the other virtualization infrastructure 20 defined as the nesting information in the PVN 390 is changed (7204). As a result of this determination, if the slice design drawing of the other virtualization infrastructure has been changed, a common API command for requesting a change of the slice of the other virtualization infrastructure 20 is issued based on the new design drawing. The data is sent to the VGK 420 of the base 20 (7207). At the same time, the new design drawing is stored in the management table 701 (Step 7208). Thereafter, the process proceeds to step 7205 and subsequent steps. The above is the process described in the slice configuration change process. On the other hand, when the design drawing of the other virtualization infrastructure has not been changed, the common API is not transmitted, and the process directly proceeds to step 7205 and subsequent steps.
Each VGK can cope with deletion, configuration change, and the like of a slice portion of another virtualization infrastructure by performing the above processing by polling.

  The execution method of Create Slivers (slice creation / execution), Delete Slivers (slice deletion), and Modify Sliveres (slice configuration change) among the common API commands shown in FIG. 13 has been described above. Run Slivers (slice start) and Stop Slivers (slice stop) are executed in the following way.

<Start slice>
This is implemented in the PVN 390 of the virtualization infrastructure (in this embodiment, the virtualization infrastructure 10) on the side where the administrator performs the slice operation. That is, when the VM (virtual node 320) of the PVN 390 is activated, it requests the VGK 410 to send a common API command of Run Slivers in order to activate the slice of the other virtualization infrastructure 20. (In addition, as described above, it is necessary to create a slice by Create Sliveres at the time of the first activation.) The other virtualization infrastructure VGK 420 that has received the Run Sliveres command instructs the management server 29 to activate the slice.

FIG. 14A shows a processing flow of the startup script of the PVN VM.
First, it is determined whether the PVN 390 is activated for the first time (step 7000). Specifically, since a flag indicating that the initial activation has been performed is stored in the “initial activation process has been performed” field of the management table 701, in the case of the initial activation with reference to this flag, the above-described information is transmitted via the VGK 410. After triggering the created slice creation process (7001) and requesting creation of another virtualization infrastructure slice, the field of the management table 701 stores that the initial activation process of the slice has been performed (7002). On the other hand, if it is not the first activation time, the VGK 410 is requested to activate the slice of the other virtualization infrastructure unit 20 (7003).
With the above processing, when the slice of the own virtualization infrastructure 10 is activated for the second time or later by the operation of the administrator's terminal 80, other virtualization infrastructure slices can be automatically activated.

<Slice stop>
The slice stop process is also performed by the PVN 390 in the same manner as described above. Specifically, a shutdown script is held in the PVN 390, and a common API for executing processing for shutting down a slice of another virtualization infrastructure is sent to the other virtualization infrastructure 20 via the VGK 410 by this shutdown script. The VGK 420 of the other virtualization platform 20 that has received the common API requests the management server 29 to shut down the slice.

FIG. 14B shows PVN shutdown script processing. When the shutdown script is activated, the VGK 410 is requested to send a common API for stopping the slice of the other virtualization infrastructure 20 (7100).
With the above processing, when the own virtualization infrastructure slice is shut down by the administrator, the other virtualization infrastructure slices can be automatically shut down.

<Summary of Example 1>
As described above, even in the virtualization platform 20 that does not have a special management system for federation, the administrator performs operations on the own virtualization platform 10 to create slices across other virtualization platforms. Configuration change, deletion, etc. can be implemented. As a result, it is possible to greatly expand the application range of federation between virtualization platforms.

<System configuration>
The first embodiment is a federation process between two domains, while the second embodiment relates to a federation process that spans three or more domains.

  FIG. 16 shows the overall configuration of a network system that performs federation across three virtualization platforms. In contrast to FIG. 1, FIG. 16 omits the physical configuration and illustrates the logical configuration. The physical configuration is the same as in FIG. A virtualization platform 3 (50) having the same configuration as that of the virtualization platform 20 is added, and the configuration is connected to the inter-gateway network 590. In the system diagram of FIG. 16, a network (corresponding to 380 in FIG. 1) for the administrator to log in to a node created in another virtualization infrastructure is omitted. If a login network is required, it can be automatically generated by the same method as in the first embodiment.

  In the network system shown in FIG. 16, a virtualization infrastructure 50 is newly added to the two virtualization infrastructures 10 and 20 of FIG. For the user slice 300, two virtual nodes 540 and 550 are placed on the virtualization platform 50. The virtual node 540 is connected to the virtual node 330 of the virtualization infrastructure 10 via the virtualization infrastructure link 361 and further connected to the virtual node 340 of the virtualization infrastructure 20 via the virtualization infrastructure link 362. For the management slice 400, the VGK 450 placed on the virtualization platform 50 controls federation.

  Furthermore, in the management slice 400, supplementary functions 440, 460, and 470 that supplement the common API output from the own virtualization platform 10 are newly placed between the VGKs 410, 420, and 450 and the link 430 between VGKs. . These complementary functions are transparent to the common API input from other virtualization platforms. Here, this complementary function may be implemented as a new VM on the management slice 400, or may be implemented as a program of the same VM as VGK. This supplementary function supplements network implementation information in order to create links between other virtualization infrastructures other than the self-virtualization infrastructure created by the administrator in the federation of 3 or more virtualization infrastructures. Used for. That is, when the administrator inputs a federation slice from the virtualization platform 10, the network implementation information is supplemented to create a link between the virtualization platform 20 and the virtualization platform 50. The supplementary function 440 of the virtualization platform 10 has link management information 441 between other virtualization platforms. Other complementary functions similarly have link management information (not shown) between other virtualization platforms.

  Next, the necessity of the complementary function will be described by taking as an example a case where a definition is input from the virtualization platform 10. As described above, when the definition is introduced from the virtualization infrastructure 10, the VGK 410 of the virtualization infrastructure 10 has the own virtualization infrastructure 10 and another virtualization infrastructure (in this case, the virtualization infrastructure 20 and the virtualization infrastructure 50. Link implementation information (VLAN number, etc.) can be set for the inter-virtual infrastructure data planes 360 and 361 between the virtual infrastructure and the virtual infrastructure. On the other hand, for the link 362 between other virtualization infrastructures, the VGK 410 of the virtualization infrastructure 10 does not manage the implementation information, so the implementation information of the common API cannot be set as it is.

  The complementary function 440 adds the mounting information of the link 362 between other virtualization platforms to the common API before sending the common API from the virtualization platform 10 to the other virtualization platform (the virtualization platform 20 and the virtualization platform 50). Provide functionality. In order to provide this function, the complement function 440 has link management information 441 between other virtualization platforms. Specifically, the usage status of the VLAN number of a plurality (m) of links between other virtualization infrastructures necessary for creating the link between other virtualization infrastructures is stored. The link management mechanism 441 between other virtualization platforms communicates with other virtualization platform VGKs (420 and 450 in this example), and updates the link mounting information.

  FIG. 17 shows an example of a slice definition by a common API issued from the virtualization platform 10 in order to create a federation slice. In FIG. 17, as in FIG. 16, illustration of a link that is automatically generated for the administrator to log in to another virtualization infrastructure node is omitted. There is a pseudo node definition 3920 representing the own virtualization infrastructure, a definition 3921 representing the boundary of the virtualization infrastructure 20, and a definition 3922 representing the boundary of the virtualization infrastructure 50. In the definitions of the virtualization infrastructure 20 and the virtualization infrastructure 50, node definitions (340y, 350y, 540y, 550y) are described. Furthermore, a definition of a link 360y that connects the virtualization infrastructure 10 and the virtualization infrastructure 20, a definition of a link 361y that connects the virtualization infrastructure 10 and the virtualization infrastructure 50, and a link 362y that connects the virtualization infrastructure 20 and the virtualization infrastructure 50 are described. .

  When the common API is output from the self-virtualized infrastructure VGK410, the implementation information (VLAN number) is set for the links 360y and 361y between the self-virtualized infrastructure and the other virtualized infrastructure. As for the link 362y between the network infrastructures, the field of the mounting information (VLAN number) is blank. In the complementing function 440, based on the management information 441, the mounting information (VLAN number) of the link 362y between the other virtualization infrastructures is added to the common API and sent to the VGKs 420 and 450 of the other virtualization infrastructures (FIG. Shown later common API). Through the above processing, it becomes possible to specify the mounting information of the link between other virtualization infrastructures of the common API and create a link between other virtualization infrastructures by the federation function.

The VGK of the other virtualization infrastructure that has received the common API extracts information related to the corresponding virtualization infrastructure, and instructs the management server to create the above-described slice. For example, in the VGK 420 of the virtualization platform 20, the virtual node definitions 340y and 350y, the links within the virtualization platform that connect them, and the definitions 360y and 362y of the links between the virtualization nodes are extracted, and the management server 29 stores the slices of the above-mentioned slices. Instruct creation.
The other federation operations can be realized in the same manner as in the first embodiment except that the number of federated virtualization platforms is increased from one to two.

<Summary of Example 2>
According to the federation of the second embodiment, it is possible to realize federation between three or more virtualization infrastructures that do not have a management mechanism for virtualization, and other virtualization infrastructures can be operated by an administrator in the own virtualization infrastructure. It is possible to create a link between.

<Modification>
The preferred embodiments of the present invention have been described above. However, the present invention is not limited to the above-described embodiments, and various modifications can be made. Some of them will be described.

  (1) In the above embodiment, the deletion of the slice of the other virtualization infrastructure 20 is detected by polling of the VGK 410 of the own virtualization infrastructure 10. On the other hand, in the modified example, if the virtualization infrastructure supports a node deletion script (a script executed on the VM of the node before the slice is deleted), the other virtualization infrastructure is triggered by the script. A slice deletion process can be triggered. Specifically, the PVN 390 of each slice requests the VGK to send a common API that instructs the deletion of another virtualization infrastructure slice as a deletion script. As a result, when deleting the slice of the own virtualization infrastructure, the slice of the other virtualization infrastructure can be deleted.

  (2) In the above embodiment, it is assumed that the configuration change of the slice of another virtualization platform is detected by VGK polling. On the other hand, in the modification, the configuration change of the slice can be triggered by PVN. Specifically, in order to instruct the configuration change of the other virtualization infrastructure, the deletion of the existing PVN of the own virtualization infrastructure and the addition of a new PVN are described. The new PVN holds a design drawing of a new slice in a nested structure and requests the VGK to send a common API that instructs the VGK to change the configuration of another virtualization infrastructure slice. Thereby, the slice configuration change of the other virtualization infrastructure can be activated.

  (3) In the above embodiment, the VGK obtains the slice definition of the other virtualization infrastructure as the nested data of the slice definition. That is, the design information of the corresponding slice is acquired from the management server of the own virtualization platform, and the slice definition of the other virtualization platform is extracted therefrom. On the other hand, in the modification, the slice definition of other virtualization infrastructure can be given as argument data of the startup script of PVN. Specifically, when PVN is a startup script and VGK is requested to create a common API that requests other virtualization platforms to create a slice, the slice definition (such as XML in the design drawing) is stored in the startup script. Specify as an argument.

  (4) In the above embodiment, the process of the VGK 410 is triggered by the start script 3902 held in the PVN 390. On the other hand, in the modified example, the VGK 410 can be activated without the PVN 390 having the activation script 3902. This is because the VGK 410 periodically performs a polling to the management server 19 and triggers the detection of the completion of creation of the virtual nodes 310 to 330 in the own virtualization platform 10, so that the startup script 3902 can perform the same function. It is.

10, 20, 50: Virtualization infrastructure 11, 12, 13, 21, 22: Physical node 16, 26: Gateway 19, 29: Management server 300: User slices 310, 320, 330, 340, 350, 540, 550: Virtual node 390: Proxy node (VPN)
400: Management slices 410, 420, 450: Virtual gatekeeper (VGK)

Claims (12)

Each of the plurality of network virtualization infrastructures includes a plurality of physical nodes, a physical network connecting the physical nodes, a gateway for connecting the physical network between other network virtualization infrastructures, and the network virtualization infrastructure In a network system that has a first server that performs federation control corresponding to the network and a second server that manages its own network virtualization infrastructure, and can form a virtual node in the physical node of each network virtualization infrastructure, A federation method for performing a federation to form a virtual network across a plurality of the network virtualization infrastructures under the control of a first server,
Create a first slice in a virtual network that spans multiple network virtualization platforms,
The virtual node in the own network virtualization infrastructure and the virtual node in the other network virtualization infrastructure formed on the first slice are connected by a link, and the first server as the first server that performs federation control on the virtual node. Configure one virtual server,
Holding the configuration definition information of the virtual network created in the other network virtualization infrastructure in a specific virtual node of the virtual nodes created in the network virtualization infrastructure;
When creating a second slice in a virtual network spanning the own network virtualization infrastructure and the other network virtualization infrastructure, the first virtual server formed in the first slice receives the configuration definition information from the specific virtual node. And instructing the creation of the second slice in the other network virtualization platform using the configuration definition information. The federation method according to claim 1, wherein the specific virtual node holds a start script for starting the first virtual server, and the first virtual server starts federation by the start script. The first virtual server holds a slice name in its own network virtualization infrastructure, a destination virtualization infrastructure name indicating another network virtualization infrastructure that issues a request for federation, and information on a slice design drawing of the other network virtualization infrastructure Have
When a slice is created by federation, a new entry is created in the management table, and the slice name, the destination virtualization infrastructure name, and information on the slice design drawing of another network virtualization infrastructure are registered in the entry. Item 3. The federation method according to Item 2. The first virtual server placed on each network virtualization infrastructure periodically queries the second server for the configuration definition information of the virtual network for each virtual network generated from the network virtualization infrastructure and federated. ,
2. When the configuration definition information is changed, the virtual network is instructed to change the configuration definition information to the first virtual server placed on the network virtualization platform that is the destination of the federation. Federation method. When the first virtual server detects deletion of the second slice in its own network virtualization infrastructure, the first virtual server detects the corresponding virtual network on the other network virtualization infrastructure included in the second slice. The federation method according to claim 4, wherein the deletion is instructed. When creating a virtual network of another network virtualization infrastructure by federation, a link connecting the specific virtual node created in the own network virtualization infrastructure and the virtual node created in the other network virtualization infrastructure is automatically generated. The federation method according to claim 1. The startup script has a file name of the startup script, an address of the first virtual server, and a slice name of the own network virtualization infrastructure created by federation.
The federation method according to claim 2. The second server is input from a terminal connected to the second server, the first configuration definition information on the own network virtualization infrastructure side regarding the creation of the second slice, and the other network virtualization infrastructure side The configuration definition information (second configuration definition information) of
The second server uses the first configuration definition information to form a virtual node in the second slice,
The specific virtual node obtains the second configuration definition information from the second server and holds it as nested data.
The federation method according to claim 1. The federation method according to claim 8, wherein the second configuration definition information is created based on a description method in the own network virtualization platform. A network system that performs federation to form a virtual network that spans multiple network virtualization platforms,
The plurality of network virtualization infrastructures are used for connecting a physical network between a plurality of physical nodes capable of forming a virtual node, a physical network connecting the physical nodes, and another network virtualization infrastructure. A gateway, a first server that performs federation control corresponding to the network virtualization infrastructure, and a second server that manages the network virtualization infrastructure;
A first slice created in a virtual network spanning a plurality of the network virtualization infrastructures;
The virtual node in the own network virtualization infrastructure and the virtual node in the other network virtualization infrastructure formed on the first slice are connected by a link, and the first server as the first server that performs federation control on the virtual node. One virtual server,
A specific virtual node among virtual nodes created in the network virtualization infrastructure holds configuration definition information of a virtual network created in the other network virtualization infrastructure,
When creating a second slice in a virtual network spanning the own network virtualization infrastructure and the other network virtualization infrastructure, the first virtual server in the first slice is the configuration definition information acquired from the specific virtual node. A network system characterized by instructing the creation of the second slice in the other network virtualization infrastructure using The first virtual server includes a hypervisor for operating a plurality of VMs formed in a server having a physical configuration, and a virtual switch that manages communication between the VM and the other virtual network base,
One VM of the plurality of VMs includes a virtual storage unit that stores at least a program that performs federation control and a management table that manages data for federation control, and a virtual CPU that executes the program.
The management table holds information on the slice name in the own network virtualization infrastructure, the destination virtualization infrastructure name indicating the other network virtualization infrastructure that issues a request for federation, and the slice design drawing of the other network virtualization infrastructure,
The network system according to claim 10, wherein the virtual CPU executes the program and instructs the creation of the second slice in the other network virtualization infrastructure using the configuration definition information acquired from the specific virtual node. The specific virtual node includes a hypervisor for operating a plurality of VMs formed in a server having a physical configuration, and a virtual switch that manages communication between the VM and the other virtual network base,
One VM of the plurality of VMs has a virtual storage unit that stores the configuration definition information in a nested structure and stores a start script for starting the first virtual server.
The network system according to claim 10.

Images