Communication schedule allocation device, communication schedule allocation method, and program

Abstract

This communication schedule allocation device, which controls one or more nodes that perform, via an optical network, optical wavelength division multiplex communication with a number of tenants, comprises: a control unit which performs control for allocating different wavelengths to respective tenants; and an allocation unit which allocates a communication schedule for one or more applications corresponding to a certain tenant to wavelengths for the tenant, whereby it is possible to achieve multi-tenant and wide-area applications that require real-time performance.

Description

[Technical field]

[0001] The present invention relates to a communication schedule allocation device, a communication schedule allocation method, and a program. [Background technology]

[0002] One of the technologies used in the Industrial Internet is TSN (Time-Sensitive Networking). TSN is a general term for various standards that guarantee the real-time nature of control communications, i.e., low latency and low jitter, and that communications reach the receiving side before a specified worst-case communication time, in order to realize control of industrial machines in factories that require real-time performance over Ethernet (registered trademark).

[0003] A typical example of TSN implementation is a combination of IEEE802.1AS, which realizes strict (nanosecond order) time synchronization between nodes, and IEEE802.1Qbv, which controls the transmittable timing of Ethernet (registered trademark) frames with a granularity of microsecond order.

[0004] In IEEE802.1Qbv, all switches that make up an Ethernet (registered trademark) domain share a transmission schedule called a GCL (Gate Control List), and perform strict transmission timing control based on the GCL. Specifically, as shown in Figure 1, each switch prepares a transmission queue corresponding to each gate, and adds frames to different queues according to priority. IEEE802.1Qbv ensures the reliable transmission of high-priority frames even in situations where low-priority frames are mixed in, by controlling which gate to open at a specific timing, i.e., which queue to send frames from.

[0005] Each switch performs this gate opening and closing control based on the time strictly synchronized by IEEE802.1AS, thereby ensuring the reliable transmission of priority frames in the Ethernet domain. This makes it possible to determine the worst-case communication time it takes for a frame to reach its destination. If such timing control were not performed, the transmission timing of a priority frame could fluctuate due to factors such as the waiting for transmission of other low-priority frames. This means that it is not possible to guarantee that a frame will arrive before the worst-case communication time.

[0006] Through these methods, TSN enables the coexistence and integration of the OT (Operational Technology) domain, which includes industrial machinery and other devices that require real-time performance in industrial applications such as factories, and the IT (Information Technology) domain, which includes general devices such as PCs, within the same network.

[0007] In addition, with the recent progress of information and communication technologies such as 5G, an approach is being considered in which applications that require low latency are accommodated in a data center (DC) on the cloud side (not in the same place as the terminal). The advantages of accommodating applications on the cloud side include scalability, easy construction and updating, easy management, billing according to usage, utilization of components provided by the cloud, and ease of linking with other systems. For applications that require particularly low latency, edge computing is being considered, which accommodates applications in a DC (edge ​​DC) constructed near the terminal within the carrier network, in order to minimize the latency caused by the transmission distance or for security reasons (avoiding transmission via the Internet).

[0008] A common form of application accommodation in a DC is to run containerized applications on a container orchestration platform such as Kubernetes. In this way, a multi-tenant form in which multiple users (tenants) share various server and network resources within the same DC can provide benefits such as reduced equipment costs and reduced usage fees through resource sharing. Figure 2 shows an image of accommodating TSN applications in an edge DC. In Figure 2, applications from multiple different tenants are accommodated in the same data center, and communicate with terminals in the local networks owned by each tenant.

[0009] In order to accommodate control applications that require real-time performance, such as industrial machine control in factories, in an edge DC, it is necessary to expand the TSN domain, which has been closed to nearby areas (such as within a factory), to a wide area and apply TSN to all sections between terminals and the edge DC. It is also necessary to accommodate applications from multiple tenants. [Prior art documents] [Non-patent literature]

[0010] [Non-Patent Document 1] IETF101, "DetNet WG Overview", [online], <URL:https: / / datatracker.ietf.org / meeting / 101 / materials / slides-101-rtgarea-deterministic-networking-detnet-00> [Non-Patent Document 2] "Kubernetes Topology Manager Moves to Beta - Align Up! - Kubernetes", [online], <URL:https: / / kubernetes.io / blog / 2020 / 04 / 01 / kubernetes-1-18-feature-topoloy-manager-beta / > Summary of the Invention [Problem to be solved by the invention]

[0011] Conventional TSN was designed to be applied only to geographically closed Ethernet (registered trademark) networks within factories, and in order to accommodate applications in edge DCs as described above, it is necessary to resolve issues such as expanding the TSN domain, supporting multi-tenancy, and supporting containers.

[0012] Regarding the first approach, wide-area expansion, a straightforward approach would be to extend the Ethernet (registered trademark) domain to between the local network to which the terminal belongs and the edge DC, and to TSN-ize everything as a single L2 network. However, this is not realistic from the standpoints of scalability, cost, security, etc.

[0013] In order to provide a wide-area network path for applications that require real-time performance, the DetNet WG (Deterministic Networking Working Group) of the IETF (Internet Engineering Task Force) is working on standardizing related technologies (Non-Patent Document 1). DetNet aims to realize a path (called a "deterministic path") with upper limits on delay, jitter, packet loss, etc., including Layer 2 bridges and Layer 3 routing segments, and is particularly studying how to support applications that require a deterministic network from the perspective of Layer 3. DetNet is premised on cooperation with Layer 2 technologies such as TSN, and for example, it is assumed that IEEE802.1AS will be used for time synchronization, just like TSN. In addition, no new Layer 3 technologies for guaranteeing the worst response time are specified, and existing Layer 2 technologies such as TSN's IEEE802.1Qbv will be used appropriately.

[0014] In other words, in order to widen the network path in DetNet, all the networks through which the path passes must be equipped with a delay guarantee mechanism like TSN, which places a heavy burden on the network.

[0015] The second point, to support multi-tenancy, requires transmission control that satisfies all of the transmission schedules desired by multiple different tenants. To achieve this, it is necessary to secure transmission slots for the applications of each tenant so that the transmission slots in the transmission schedule do not collide. There is an upper limit to the number of transmission slots that can be set in the transmission schedule, and once these are all used, it is no longer possible to add any more.

[0016] It is possible to reduce the consumption of transmission slots by providing shareable transmission slots rather than monopolizing them for one application and sharing them among multiple tenants and applications; however, in this case, unless appropriate control is implemented, reliable transmission in that slot cannot be guaranteed.

[0017] This is unacceptable in applications that require real-time performance.

[0018] In order to increase the upper limit of the transmission schedule, it is necessary to physically divide the L2 domain by the amount of the transmission schedule (logical division such as VLAN is insufficient because electrical signals collide at the physical layer and jitter occurs). To achieve physical division, it is necessary to separate the cables and run them to the local network side, which is very cumbersome.

[0019] Third, when it comes to applying TSN to containerized applications, challenges include scheduling which physical nodes to place containers on, allocating TSN slots, and allocating transmission time slots to containers.

[0020] Generally, a container orchestrator determines the physical node on which a container should be placed based on the container configuration and setting information (for example, called a manifest file in Kubernetes) input by an operator or developer. This is called scheduling. The container configuration and setting information can describe computing resource information such as CPU and memory required to execute an application, and the container orchestrator assigns containers to nodes that can allocate resources based on this information. Depending on the description of the container configuration and setting information, the orchestrator can divide the priority classes to be assigned to applications. Depending on the settings of the orchestrator, it is also possible to exclusively assign a CPU to a high-priority class application. Furthermore, instead of simply assigning a CPU, it is also possible to assign a CPU, NIC, etc. on the same NUMA (Non-Universal Memory Access) node so that the access time is minimized, taking into account the internal topology of the computer (Non-Patent Document 2).

[0021] However, when accommodating applications that require real-time performance, such as TSN applications, in addition to the exclusive allocation of resources in the computing layer described above, it is also necessary to eliminate disturbances in the network layer, which can be achieved by techniques such as TSN transmission slot allocation.

[0022] Scheduling of such network layer transmission timing is generally not handled by the orchestrator and must be configured in advance by a means other than the orchestrator. Configuring computing resources and network transmission resources separately each time is a heavy burden for application developers and operators, so it is desirable to be able to perform both in one go.

[0023] The present invention has been made in consideration of the above-mentioned points, and has an object to make it possible to realize multi-tenancy and wide-area operation of applications that require real-time performance. [Means for solving the problem]

[0024] In order to solve the above problem, a communication schedule allocation device for controlling one or more nodes that perform optical wavelength division multiplexing communication with a plurality of tenants via an optical network includes a control unit that performs control to allocate different wavelengths to each of the tenants, and a Rua Application The data transmission period and the transmission time required for each transmission timing are The communication schedule for the tenant 1 or more wavelength Among these, the wavelengths that can be assigned to the communication schedule an allocation unit that allocates to The allocation unit determines a wavelength to which a communication schedule by the application can be allocated based on information indicating a communication schedule already allocated to the wavelength, the information being managed for each wavelength. . Effect of the Invention

[0025] It is possible to realize multi-tenancy and wide area application of applications that require real-time performance. [Brief description of the drawings]

[0026] [Figure 1] FIG. 1 is a diagram illustrating an example of Time-Aware Shaping in TSN. [Diagram 2] This is a diagram showing an example of accommodating TSN applications in an edge DC. [Diagram 3] FIG. 2 is a diagram illustrating an example of a functional configuration of the present embodiment. [Figure 4] 13 is a diagram showing an example of port mapping for a frame transmission / reception functional unit 22 and an optical conversion functional unit 23. FIG. [Diagram 5] FIG. 11 is a sequence diagram illustrating an example of a procedure for a node information registration process. [Figure 6] FIG. 11 is a sequence diagram illustrating an example of a processing procedure for an optical path establishment process. [Figure 7] 13 is a flowchart illustrating an example of a procedure for a deployment destination node selection process. [Figure 8] FIG. 11 is a sequence diagram illustrating an example of a procedure for deploying an application. [Figure 9] FIG. 1 is a diagram for explaining classification according to connection configuration. [Figure 10] FIG. 13 is a diagram illustrating port switching that takes NUMA topology into consideration. [Figure 11] FIG. 1 is a diagram illustrating an example of a transmission schedule allocation in a PON system. [Figure 12] Classification by combination of wavelength, tenant and application [Figure 13] FIG. 13 is a diagram illustrating an example of a functional configuration according to a fourth embodiment. [Figure 14] FIG. 13 is a sequence diagram illustrating an example of a procedure for a node information registration process according to the fourth embodiment. [Figure 15] FIG. 13 is a sequence diagram illustrating an example of a procedure for establishing an optical path according to the fourth embodiment. [Figure 16] FIG. 13 is a sequence diagram illustrating an example of a procedure for deploying an application according to a fourth embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0027] In this embodiment, a different TSN transmission schedule (communication schedule) is provided for each tenant, and each is mapped to a wave of a different wavelength, and optically transmitted between a data center (hereinafter referred to as "DC") that accommodates the application and the tenant's local gateway (local GW). By using light, long-distance transmission is performed with minimal delay and fluctuation. By separating the wavelength for each tenant, the influence of the communication of other tenants is eliminated. In addition, by using optical wavelength division multiplexing (WDM), the number of cables required for transmitting multiple TSN transmission schedules is reduced. Furthermore, by mapping waves (= transmission schedules) and tenant information and managing them together with the usage status of transmission slots, appropriate node allocation by the container orchestrator and setting implementation at the network layer are also realized.

[0028] Hereinafter, an embodiment of the present invention will be described with reference to the drawings. FIG. 3 is a diagram showing an example of a functional configuration of the present embodiment. As shown in FIG. 3, a DC includes a plurality of computers (one of which is shown in FIG. 3) functioning as each node 20 constituting a cluster, and a computer functioning as an orchestrator 10. Each node 20 and the orchestrator 10 are connected via a local network in the DC. Each node 20 accommodates a TSN application. A TSN application is a real-time application that requires deterministic time communication by TSN (Time-Sensitive Networking). An example of a TSN application is a robot arm control application. Hereinafter, unless otherwise specified, a TSN application will be simply referred to as an "application".

[0029] On the other hand, in a tenant using a DC, one or more TSN terminals 40 and a local GW 30 are connected via a local network within the tenant. The TSN terminal 40 is a terminal that is the counterpart of an application, and receives communication prioritized by TSN via a network N1 and the local GW 30. For example, if the application is a control application for a robot arm, an example of the TSN terminal 40 is the robot arm.

[0030] Each node 20 in the DC and the local GW 30 of each tenant are connected via an optical network N1. That is, the optical network N1 is shared for communication with a plurality of tenants. The optical network N1 is an optical transmission network configured by devices capable of arbitrarily switching paths, such as optical switches. The node 20 and the optical network N1 (more specifically, for example, between the optical wavelength multiplexing function unit 24 of the node 20 and the optical switch in the optical network N1) are physically connected by optical fibers, and it is assumed that the optical network N1 can be used at any time by the settings (path configuration, wavelength setting) on ​​the optical network N1 side. Note that, if dynamic optical path setting is not required, the path between the node 20 and the local GW 30 may be fixed or directly connected (so-called Single Star configuration).

[0031] The optical network N1 includes a device (computer) that functions as a network control function unit 50. The network control function unit 50 is responsible for dynamically establishing an optical path between a cluster that accommodates an application and a local network (not necessary if the optical path is statically established by prior manual setting, etc.). An optical path is established by an instruction from the cluster control function unit 11 or a manual instruction. Specifically, the network control function unit 50 receives a node identifier and a tenant identifier as information required for establishing an optical path, and instructs the optical network N1 to establish an optical path between the node 20 and the tenant using an available wavelength. After establishment, information on the established optical path (including the wavelength to be used) is returned.

[0032] 3, the node 20 includes an application accommodation function unit 21, a frame transmission / reception function unit 22, an optical conversion function unit 23, an optical wavelength multiplexing function unit 24, a node control function unit 25, and a time synchronization function unit 26. Of these, the frame transmission / reception function unit 22, the optical conversion function unit 23, and the optical wavelength multiplexing function unit 24 are hardware. For example, the frame transmission / reception function unit 22 is a network interface card (NIC), the optical conversion function unit 23 is an electrical-optical conversion device, and the optical wavelength multiplexing function unit 24 is a wavelength division multiplexing (WDM) device. On the other hand, the application accommodation function unit 21, the node control function unit 25, and the time synchronization function unit 26 are realized by processing executed by a CPU of the node 20 by one or more programs installed in the node 20.

[0033] The orchestrator 10 has a cluster control function unit 11. The cluster control function unit 11 is realized by processing that one or more programs installed in the orchestrator 10 cause the CPU of the orchestrator 10 to execute. The orchestrator 10 also has an optical path information management function unit 111 and a transmission schedule information management function unit 112. Each of these management function units is, for example, a database that stores and manages information using an auxiliary storage device of the orchestrator 10.

[0034] The local GW30 has a frame transmission / reception functional unit 31, an optical conversion functional unit 32, an optical wavelength multiplexing functional unit 33, and a time synchronization functional unit 34. Of these, the frame transmission / reception functional unit 31, the optical conversion functional unit 32, and the optical wavelength multiplexing functional unit 33 are hardware similar to the functional units of the same names in the node 20. On the other hand, the time synchronization functional unit 34 is realized by a process in which one or more programs installed in the local GW30 are executed by the CPU of the local GW30.

[0035] Each functional unit will now be described in detail.

[0036] [Application accommodation function part 21] The application accommodation function unit 21 accommodates a plurality of applications corresponding to a plurality of tenants, respectively.

[0037] [Frame transmission / reception function unit 22] The frame transmission / reception functional unit 22 aggregates communications of applications belonging to the same tenant, and controls frame transmission according to an independent transmission schedule for each tenant. The frame transmission / reception functional unit 22 has multiple physical transmission / reception ports, each of which is independently connected to the optical conversion functional unit 23 (see FIG. 4 for details). Communications of each application associated with a different tenant (= different TSN transmission schedule) are transmitted to the optical conversion functional unit 23 in a physically separated state using separate ports.

[0038] Fig. 4 is a diagram showing an example of port mapping of the frame transmitting / receiving functional unit 22 and the optical conversion functional unit 23. In Fig. 4, an electric signal line is connected from the frame transmitting / receiving functional unit 22 to the optical conversion functional unit 23, but it is also possible that the frame transmitting / receiving functional unit 22 directly transmits an optical signal (in this case, the frame transmitting / receiving functional unit 22 and the optical conversion functional unit 23 are integrated).

[0039] [Optical conversion function part 23] The optical conversion functional unit 23 is a part that converts the frame input from the frame transmission / reception functional unit 22 into an optical signal. The optical conversion functional unit 23 performs mapping between the port of the frame transmission / reception functional unit 22 and the wavelength to be used, based on the tenant information (port identifier and wavelength of the frame conversion functional unit) notified from the node control functional unit 25.

[0040] [Optical wavelength multiplexing function section 24] The optical wavelength multiplexing function unit 24 performs optical wavelength multiplexing communication for waves of wavelengths associated with the transmission schedules of the respective tenants.

[0041] [Local GW30] The local GW30 functions as a gateway for the tenant's local network, mediates communications from applications, and transmits frames to the local network according to a transmission schedule.

[0042] In addition, in FIG. 3, a configuration in which the local GW 30 includes an optical conversion function unit 32 and an optical wavelength multiplexing function unit 33 is illustrated as an example, but these functions may be arranged outside the local GW 30, and the local GW 30 may be a normal TSN bridge.

[0043] [Time synchronization function 26] The time synchronization function unit 26 performs precise time synchronization with the time synchronization function unit 34 using IEEE802.1AS or the like. Based on the time synchronized here, the frame transmission / reception function unit 22 performs strict gate opening / closing control.

[0044] [Node control function part 25] The node control functional unit 25 instructs the application accommodation functional unit 21 to deploy the application. It also allocates a transmission schedule of the application to a port of the frame transmission / reception functional unit 22. The node control functional unit 25 also notifies the optical conversion functional unit 23 of wavelength information corresponding to the port information of the frame transmission / reception functional unit 22.

[0045] [Optical path information management function unit 111] The optical path information management function unit 111 manages mapping information (Table 1) of ports, wavelengths, and tenants in each node 20 .

[0046] [Table 1] Each row of Table 1 corresponds to one transmission schedule (however, the transmission schedule information itself is managed by a transmission schedule management function unit described next).

[0047] In addition, here, if the propagation distance to the local GW30 side is known, the information may be stored in the optical path information management function unit 111 or the transmission schedule information management function unit 112 described below. The optical propagation delay is said to be about 5 [μs] per 1 [km], and during long-distance transmission, a deviation occurs between the transmission time schedule on the DC side and the transmission time schedule on the local GW30 side. Therefore, for example, when the distance is 10 [km], it is effective to correct the deviation in the transmission schedules of the source and destination sides due to the propagation delay by advancing the transmission time schedule on the DC side by 10 [km] × 5 [μ / km] = 50 [μs].

[0048] [Transmission schedule information management function part 112] The transmission schedule information management function unit 112 holds, for each transmission schedule (for each row of Table 1), a transmission slot allocation status (association between the allocated transmission slot and the application) as shown in Table 2. That is, one Table 2 corresponds to one row of Table 1.

[0049] [Table 2] The application identifier describes the identifier of an application that can be transmitted in that transmission slot. Multiple application identifiers can be specified. It is also possible to specify a slot that cannot be used because it is exclusively used by other nodes 20 or the local side, or conversely, a slot that can be used by all applications (= best effort slot). Note that a transmission slot indicates a certain time period as shown in FIG. 1. In IEEE802.1Qbv, which is one of the standard specifications that constitute TSN, it is periodically controlled which transmission gate is opened for each certain divided time. This "certain divided time" is called a transmission slot.

[0050] In the example of Table 2, the first 100 μs (transmission slot) of a communication cycle cannot be used, an application with an application identifier app2 can be used between 100 μs and 120 μs (transmission slot), and an application with an application identifier app3 can be used between 180 μs and 200 μs (transmission slot).

[0051] In addition to the above information, the transmission schedule information management function unit 112 also stores the start time of the transmission schedule (called the base time). By using this information, the application can know the time when it should next transmit a frame.

[0052] [Cluster Control Function Part 11] The cluster control function unit 11 performs various controls of the entire cluster configured with a plurality of nodes 20 (corresponding to a master node in Kubernetes). In this embodiment, the cluster control function unit 11 plays a role of selecting a node 20 to which an application is to be deployed, based on various information (request resource information, transmission period information) provided at the time of deploying the application.

[0053] Examples of required resource information include the CPU cores and memory amount required by an application (eg, 2 CPU cores, 2 GB memory).

[0054] The transmission period information is an example of information that indicates the communication schedule of an application, and indicates how frequently and for how long the application will transmit frames, for example, a transmission period of 1 [ms] and a transmission time of 50 [μs].

[0055] The cluster control function unit 11 selects a node 20 that satisfies the above-mentioned required resource information and transmission period information. The node control function unit 25 of the selected node 20 deploys the application and sets the TSN.

[0056] Next, a basic implementation procedure will be described. The implementation procedure includes node information registration and lightpath establishment in the preparation phase, and node 20 selection and TSN setting implementation procedures when deploying an application in the operation phase.

[0057] The basic selection criterion for a node to which a general application (an application that does not fall under the category of a TSN application) is that the node can provide the computer resources required by the application. In addition, a TSN application is required to provide a transmission schedule required as a TSN application. In other words, in order to deploy an application on a node 20 that satisfies both computer resources and optical network N1 resources, it is necessary to select a node 20 that takes into account both of these resources, as described below.

[0058] It is assumed that the network control function unit 50 holds information about the local network and tenants (tenant identifiers, etc.), or that this information can be queried / resolved on the optical network N1 side.

[0059] [Node information registration] FIG. 5 is a sequence diagram illustrating an example of a procedure for registering node information.

[0060] The node control function unit 25 of each node 20 constituting the cluster or an operator registers port information (node ​​identifier and port identifier) ​​of the frame transmission / reception function unit 22 / optical conversion function unit 23 held by the node 20 in the cluster control function unit 11 (S101). The cluster control function unit 11 saves the port information in the optical path information management function unit 111 (S102). The configuration of the port information saved in the optical path information management function unit 111 is as shown in Table 1, but at the present time (=before the optical path is established), the wavelength and tenant identifier columns are blank. The processing procedure in FIG. 5 may be executed for each port of each node 20, or may be executed for each node 20. In the latter case, the port identifiers of all ports belonging to the node 20 are specified in step S101 and saved in the optical path information management function unit 111 in step S102.

[0061] [Optical path establishment] The establishment of the optical path is performed during advance preparation or dynamically during application deployment, which will be described later. In either case, the optical path is automatically or manually set between the optical conversion functional unit 32 of the local GW 30 and the optical conversion functional unit 23 of the node 20 (at this time, a wave of an unused wavelength that does not overlap with others is selected).

[0062] The node 20 selected as the path establishment destination during application deployment must satisfy at least the following conditions. (1) There is available port. (2) Ability to provide sufficient computer resources (CPU / memory, etc.) required for the application.

[0063] When selecting a node 20 triggered by the deployment of an application, it is necessary to select a node 20 that can provide more node 20 resources than the application requires. If there are multiple nodes 20 with the same conditions, they are selected from among them according to arbitrary selection criteria (random / preferentially giving priority to the node 20 with the most spare resources, etc.).

[0064] On the other hand, at the time of advance preparation, the application to be deployed is unknown (the application to be deployed does not need to be specified), so the above conditions (1) and (2) are ignored. At the time of advance preparation, only a path is established in advance to one of the nodes 20, and at the time of subsequent application deployment, if sufficient computer resources are available in that node 20, that path is used, and if they are not available, an additional path is dynamically established. This is based on the practical operational assumption that at the time of advance preparation, no applications have yet been deployed, so computer resources are abundantly available and there is unlikely to be a shortage of computer resources.

[0065] FIG. 6 is a sequence diagram illustrating an example of a processing procedure of the optical path establishment process.

[0066] In step S201, the cluster control function unit 11 instructs the network control function unit 50 to establish an optical path, thereby performing control to assign a different wavelength to each tenant. At this time, a pair of identifiers of the node 20 (hereinafter referred to as the "target node 20") and the tenant (hereinafter referred to as the "target tenant") connected by the optical path, that is, a pair of a node identifier (hereinafter referred to as the "target node identifier") and a tenant identifier (hereinafter referred to as the "target tenant identifier"), is notified. The network control function unit 50 selects an unused (not yet assigned) wavelength (S202), and establishes an optical path between the optical network N1 and the local GW 30 of the target tenant based on the notified information (S203, S204). The unused wavelength can be specified by referring to the optical path information management function unit 111 (Table 1). By selecting an unused wavelength, a different wavelength is selected at least for each tenant (however, there are cases where multiple wavelengths are assigned to one tenant). Therefore, the instruction by the cluster control function unit 11 in step S201 corresponds to control for allocating a different wavelength to each tenant.

[0067] After the optical path is established, the network control function unit 50 returns wavelength information indicating the selected wavelength (hereinafter referred to as "target wavelength information") to the cluster control function unit 11 which is the request source (S205).

[0068] The cluster control function unit 11 notifies the node control function unit 25 of the node 20 (target node 20) that has established the optical path of the target wavelength information (S206).

[0069] Next, the node control function unit 25 selects an available port to be used (hereinafter referred to as a "target port") by referring to the optical path information management function unit 111 (Table 1) (S207). Specifically, the node control function unit 25 selects, as the target port, a port associated with a port identifier (hereinafter referred to as a "target port identifier") in any row in which a wavelength and a tenant identifier are not registered, among rows including a target node identifier in the optical path information management function unit 111 (Table 1). In other words, an available port is a port to which no wavelength is assigned. However, the cluster control function unit 11 may decide which port to assign a wavelength to.

[0070] Next, the node control functional unit 25 instructs the optical wavelength multiplexing functional unit 24 and the optical conversion functional unit 23 to allocate the wavelength related to the target wavelength information to the target port, thereby allocating the wavelength to the target port of the optical wavelength multiplexing functional unit 24 and the optical conversion functional unit 23 (S208 to S211). The optical wavelength multiplexing functional unit 24 and the optical conversion functional unit 23 establish an optical path using the target port and the wavelength (S212). In general, when performing electrical-optical conversion, the wavelength of the converted light is uniquely determined, so that the wavelength used during conversion needs to be set by the optical conversion functional unit 23 that performs electrical-optical conversion. However, regarding wavelength setting, a form in which the optical wavelength multiplexing functional unit 24, instead of the optical conversion functional unit 23, is provided with a wavelength conversion function and the wavelength is set therein may be adopted.

[0071] After the path is established (= wavelength / port setting completion) (S213), the node control function unit 25 notifies the cluster control function unit 11 of the path setting completion together with the target port identifier and the target wavelength information (S214). In response to the notification, the cluster control function unit 11 adds the target wavelength information and the target tenant identifier to the row of the target node identifier and the target port identifier in the optical path information management function unit 111 (Display 1) (S215).

[0072] At this time, if the TSN environment has already been set up in the tenant's local network and a transmission schedule already exists, it is also possible to input the transmission schedule information into the transmission schedule information management function unit 112 (Table 2). This avoids duplicate use of transmission slots already used in the local network.

[0073] Furthermore, using this optical path or another route, time synchronization is performed by the time synchronization function unit 26 of the node 20 and the time synchronization function unit 34 of the local GW 30. This is necessary for the node 20 and the local GW 30 to perform strict transmission control in accordance with the transmission schedule.

[0074] [Application deployment: Select node 20] When an application is deployed, the cluster control function unit 11 is requested to deploy the application. At this time, the person who requests the application deployment notifies the cluster control function unit 11 of the application information required for the deployment, the computer resource request information such as the required CPU / memory, as well as the tenant identifier associated with the application (hereinafter referred to as the "target tenant identifier") and the transmission cycle information requested by the application (hereinafter referred to as the "requested transmission cycle information") required for TSN setting. The transmission cycle information is composed of the data transmission cycle and the transmission time required for each transmission timing (for example, cycle 1 [ms], transmission time 100 [μs]). In addition, the application information is information about the application to be deployed, and is, for example, a manifest file in Kubernetes. The manifest file describes information such as the application name, the image of the container to be used, and the command to be executed. In addition, when the application information can share a transmission slot with another application, it can also describe that fact. Possible methods of description include allowing sharing with all applications, specifying the application name and allowing sharing only with a specific application, or specifying using the concept of labels in Kubernetes (https: / / kubernetes.io / ja / docs / concepts / overview / working-with-objects / labels / ) (for example, allowing sharing with an app with the label location: factoryA). For example, in Table 2, the row with the transmission slot "900μs-920μs" shows an example in which two application identifiers (app1, app2) are registered, and the applications related to these two application identifiers are examples of applications that can share a transmission slot.

[0075] FIG. 7 is a flowchart illustrating an example of a process procedure for selecting a deployment destination node.

[0076] The cluster control function unit 11, which has received the application information, transmission cycle information, resource request information, target tenant identifier, etc., first judges whether or not a row corresponding to the target tenant identifier (hereinafter referred to as the "target row") is present in the optical path information management function unit 111 (Table 1) (S301). If the target row is present (Y in S301), the cluster control function unit 11 judges whether or not a node identifier and optical wavelength information (these information are hereinafter referred to as the "optical path information") linked to the target tenant identifier are included in the target row (S302).

[0077] When there is lightpath information (Y in S302), the cluster control function unit 11 compares the TSN transmission schedule (Table 2) of the lightpath related to the lightpath information with the transmission period related to the requested transmission period information (hereinafter referred to as the "requested transmission period") to determine whether the requested transmission period can be assigned (embedded) in the TSN transmission schedule (S303). Specifically, one lightpath corresponds to one TSN transmission schedule (Table 2). The TSN transmission schedule (Table 2) is composed of multiple transmission slots. This transmission slot is to be assigned to the application (the idea is to assign the time period that the application wants to transmit from the available slots in the TSN transmission schedule as a transmission slot). Here, if the slot for the time period that the application wants to use can be secured from the TSN transmission schedule, it is determined that the slot can be assigned, and if it cannot be secured, it is determined that the slot cannot be assigned. However, if the transmission slot can be shared, the transmission slot already assigned to another application is also a candidate for assignment. In addition, when there are multiple pieces of lightpath information associated with the target tenant identifier, it is only necessary that the requested transmission period can be assigned to the TSN transmission schedule corresponding to any one of the target lightpath information.

[0078] If there is one or more optical paths (hereinafter referred to as "target optical paths") that can transmit at the requested transmission cycle (Y in S303), the cluster control function unit 11 determines whether or not there is a node 20 that has available computer resources that can satisfy the resources (hereinafter referred to as "requested resources") indicated by the resource request information among the nodes 20 corresponding to any of the target optical paths (S304). If there is one or more applicable nodes 20 (Y in S304), the cluster control function unit 11 determines (selects) one of the applicable nodes 20 as the deployment destination (S305). If there are multiple applicable nodes 20, the cluster control function unit 11 may select one node 20 with the most abundant computer resources, or may select any one node 20 at random.

[0079] On the other hand, if there is no lightpath information (N in S302), if transmission in the requested transmission period is impossible (N in S303), or if there is no node 20 that can satisfy the requested resources among the nodes 20 corresponding to any of the target lightpaths (N in S304), the cluster control function unit 11 selects a node 20 that can satisfy the requested resources from among the nodes 20 that are not related to the target lightpath, and establishes a new lightpath related to the node 20 (S306). The procedure for establishing a lightpath is as described in FIG. 6. At this time, in step S201 of FIG. 6, the target tenant identifier and the node identifier of the node 20 are specified. If the establishment of the lightpath is successful (Y in S307), steps S301 and after are repeated. If the establishment of the lightpath fails (N in S307), the process of FIG. 7 ends abnormally. Note that the determination of step S303 or step S304 may be executed first.

[0080] [Deploying the application: Configuring TSN settings] FIG. 8 is a sequence diagram illustrating an example of a procedure for deploying an application.

[0081] If there is a node 20 that can provide the resources required by the application and satisfy the TSN transmission schedule, the cluster control function unit 11 instructs the node control function unit 25 of the node 20 to deploy the application (S401). Such an instruction includes application information, requested transmission cycle information, resource request information, a port identifier, etc. The port identifier is a port identifier corresponding to the target optical path in the description of FIG. 7.

[0082] In response to the instruction, the node control function unit 25 performs settings for executing the application. First, the node control function unit 25 instructs the application accommodation function unit 21 to deploy the application related to the application information (S402). The application accommodation function unit 21 deploys the application (places it and makes it executable) (S403).

[0083] Next, the node control function unit 25 instructs the frame transmission / reception function unit 22 to connect the application to the port related to the port identifier and to set requested transmission period information (S404). In response to the instruction, the frame transmission / reception function unit 22 connects the port of the frame transmission / reception function unit 22 to the application, and sets requested period information for the port (S405).

[0084] Next, the node control function unit 25 notifies the cluster control function unit 11 of the completion of the deployment (S406). In response to the notification, the cluster control function unit 11 adds one row to the optical path information management function unit 111 (Table 2) corresponding to the optical path information whose existence was identified in step S302 of Fig. 7, and registers in the row a transmission slot corresponding to the requested transmission cycle information and an application identifier of the deployed application (S407).

[0085] As a result, communication for an application linked to a specific tenant is sent from the frame transmission / reception functional unit 22 based on the set schedule, and is converted into an optical signal of a wavelength corresponding to the tenant by the optical conversion functional unit 23. Furthermore, it is superimposed on a single optical fiber together with optical signals of multiple wavelengths by the optical wavelength multiplexing functional unit 24, and transmitted via the optical network N1. It is converted back into an electrical signal by the destination local GW 30, and is sent to the local network side.

[0086] The node control function unit 25 notifies the deployed application of the assigned transmission schedule information (baseTime, transmission period, transmission offset, transmission time, etc.). As a means for notifying, for example, the Con.gMap in Kubernetes may be used. The application sends packets according to the notified schedule information.

[0087] [Example] Next, examples will be described. First, examples based on connection configurations will be described, then examples based on wavelength utilization patterns will be described, and finally, other examples will be described.

[0088] [Example 1: Classification by connection configuration] Classification by connection configuration is shown in Figure 9.

[0089] [Example 1-1: Optical signal output directly from node chassis] In this embodiment, an optical conversion functional unit 23 that generates optical signals and an optical wavelength multiplexing functional unit 24 that performs wavelength multiplexing are built into the node 20. When accommodating applications that belong to multiple tenants (TSN schedules), multiple optical signals with different wavelengths (as many as the number of transmission schedules) are generated directly from the node 20, wavelength-multiplexed and transmitted through a single optical fiber cable, and connected to the optical network N1 side, which has the advantage of reducing the complexity of wiring within the DC.

[0090] It is also possible to switch the mapping between the optical wavelength multiplexing functional unit 24 and the port (belonging to either NUMA node) (FIG. 10). If the NUMA node to which the port is currently connected does not have sufficient available computing resources, and the other NUMA node has available computing resources, it is possible to more efficiently use the computing resources and the resources of the optical network N1 by switching the correspondence between the wavelength and the port (switching method 1) or by switching the correspondence between the port of the frame transmission / reception functional unit 22 and the port of the optical conversion functional unit 23 (switching method 2).

[0091] [Example 1-2: Electrical / optical conversion (E / O conversion) performed outside the node] This embodiment is a pattern in which the optical signal conversion and wavelength multiplexing performed in embodiment 1-1 are performed by a conversion device outside the node 20. Embodiment 1-2 has the advantage of being able to easily utilize servers connected based on the current Ethernet (registered trademark) (for example, 1000BASE-T, 10GBASE-SR, 10GBASE-LR, etc.). Although embodiment 1-2 has the disadvantage of an increase in physical devices compared to embodiment 1-1, it is possible that the number of required optical fiber wirings can be reduced by connecting multiple nodes 20 to a conversion device and combining the wavelengths for 20 nodes (also depending on the number of ports that the conversion device can accommodate).

[0092] [Example 1-3: Connection via PON] As one of the variations of the E / O conversion outside the node as in the embodiment 1-2, integration with PON (Passive Optical Network) will be described. PON is a technology for accommodating multiple subscriber homes, and is specified in IEEE802.3ah etc. (IEEE, "IEEE Standard for Information technology- Local and metropolitan area networks- Part 3: CSMA / CD Access Method and Physical Layer Specifications Amendment: Media Access Control Parameters, Physical Layers, and Management Parameters for Subscriber Access Networks," IEEE.doi:10.1109 / IEEESTD.2004.94617, http: / / ieeexplore.ieee.org / document / 1337489 / (hereinafter referred to as "Reference 1")). It is widely used in the current FTTH (Fiber to the Home) service.

[0093] In PON, time division multiplexing (TDM) is used for downstream communication. Each frame is assigned with destination information, and the OLT corresponding to each local GW 30 retrieves its own data by looking at this information. The timing of transmission at this time is determined by the Multi-Point Transmission Control function unit in the OLT. Specifically, transmission is permitted by sending a transmitEnable message to the Multi-point MAC Control instance corresponding to the transmission port. The scheduling algorithm for when multiple instances make transmission requests at the same time is implementation dependent (quoted from "The scheduling algorithm is implementation dependent, and is not specified for the case where multiple transmitrequests happen at the same time." (quoted from 64.2.1 Principles of Multi-point MAC Control in Reference 1)).

[0094] Here, by providing fixed periodic transmission permission as a scheduling algorithm, it becomes possible to always communicate with a certain destination during a certain period within the period. By registering that period as available wavelengths and schedule information, it becomes possible to realize strict delay-free communication using TSN even in PON (assuming time synchronization is performed). How transmission permission is given is arbitrary; for example, it can be allocated equally to all destinations, but it is also possible to allocate in a finer cycle (Figure 11).

[0095] For example, in the left diagram of Figure 11, the information registered in the cluster will be in the format shown in Table 3.

[0096] [Table 3] [Example 1-4: Implementation method using NG-PON2] As a form similar to Example 1-3, an example using NG-PON2 ("ITU-T, Recommendation ITU-T G.989.3: 40-Gigabit-Capable Passive Optical Networks (NG-PON2): Transmission Convergence Layer Specification. Oct. 2015, https: / / www.itu.int / rec / T-REC-G.989.3-201510-I / en") specified as ITU-T G.989.1 will be described. A feature of NG-PON2 is that it specifies a method called PtP WDM (Point-to-Point WDM) that uses a dedicated wavelength between specific ONUs and allows communication to be performed exclusively from communication with other ONUs. By using this, it becomes possible to exclusively assign a wavelength (=TSN schedule) to a specific target while accommodating multiple users by time division multiplexing using PON. In the case of PtP WDM, the wavelengths that are exclusively allocated can be used exclusively by the target, just like in the Single Star configuration.

[0097] [Example 2: Classification of Examples by Use of Wavelength] Figure 12 shows the classification based on the combination of wavelength, tenant, and application.

[0098] [Example 2-1: One wave shared by one tenant] This is the simplest embodiment in which one tenant has exclusive use of one wavelength. Each tenant's application can use all of the generously allocated TSN schedules. If there is a shortage of computing resources such as CPU / memory, it is possible to expand the accommodating area by creating an optical path using the same wavelength at another node 20 (→ Example 2-3).

[0099] [Example 2-2: One wave shared by multiple tenants] When there are limitations on the number of wavelengths and ports, it is also possible for multiple tenants to share one wave (=TSN schedule). Transmission schedule information managed by the TSN transmission schedule information management function unit 112 is shared by multiple tenants, making it possible to allocate transmission slots. Optical paths are established from node 20 to multiple tenants (simultaneous transmission to multiple routes is achieved by optical switches, splitters, etc.). In such cases, since it becomes possible to receive communications from other tenants, security considerations must be made, such as encryption at layers L2 and above.

[0100] [Example 2-3: One tenant occupies multiple waves] If the number of slots in the TSN schedule is insufficient, it is possible to expand the number of TSN schedules by creating new wavelengths. In this case, multiple ports on the local GW30 side must also be provided. In principle, it is also possible to completely separate TSN traffic and best-effort traffic at the wavelength level. Alternatively, it is also possible to transmit TSN traffic, best-effort traffic, and non-IP (RDMA / RoCE, etc.) traffic separately.

[0101] [Example 2-4: One wave is exclusively used by one tenant (multiple locations)] It is possible that a tenant has multiple bases. In that case, by establishing optical paths between multiple bases in the same manner as in Example 2-2, communication with the multiple bases becomes possible.

[0102] [Example 2-5: Redundancy using multiple routes] For redundancy purposes, it is possible to make it possible to transmit waves of the same wavelength over multiple routes. In this case, the waves are split immediately after the DC, and communications from multiple routes are combined near the tenant site. In this case, a function is provided to absorb the propagation time difference when combining (when there is a significant propagation difference). In addition, by monitoring the route status and taking measures such as switching to the Standby side when a route is cut off, it becomes possible to continue communications even if one of the routes is cut off.

[0103] [Example 3: Upstream communication] An optical receiver is provided in the optical conversion functional unit 23. The optical path information management functional unit 111 also manages the upstream wavelengths, and when a path is established, it is possible to correctly receive upstream communications by setting which port the wavelength received on the optical wavelength multiplexing functional unit 24 side should be sent to.

[0104] [Example 4: Pattern with TSN control and computing control functions separated] Fig. 13 is a diagram showing an example of a functional configuration in Example 4. In Fig. 13, the same parts as or corresponding parts to Fig. 3 are given the same reference numerals, and the description thereof will be omitted as appropriate.

[0105] In FIG. 13, the DC further includes a control server 60. The control server 60 is connected to the orchestrator 10 and each node 20 via a local network in the DC. The control server 60 has a compute control function unit 61, a TSN control function unit 62, and an optical path control function unit 63. Each of these function units is realized by a process executed by the CPU of the control server 60 by one or more programs installed in the control server 60. The control server 60 also has a compute resource information management function unit 611, a TSN information management function unit 612, and an optical path information management function unit 613. Each of these management function units is, for example, a database that stores and manages information using an auxiliary storage device of the orchestrator 10.

[0106] On the other hand, the orchestrator 10 has an orchestration control function unit 12. The orchestration control function unit 12 is realized by processing that one or more programs installed in the orchestrator 10 cause the CPU of the orchestrator 10 to execute.

[0107] In addition, Example 4 is an example in which the roles that were mainly played by the cluster control function unit 11 in the above are decomposed into four control function units: a compute control function unit 61, a TSN control function unit 62, an optical path control function unit 63, and an orchestration control function unit 12.

[0108] The compute resource information management function unit 611 manages the usage status of compute resources such as the CPU and memory of the node 20 .

[0109] The TSN information management function unit 612 manages information regarding the TSN transmission schedule, corresponding tenants, nodes 20, and ports, as shown in Table 4.

[0110] [Table 4] These schedule information entries are created in the optical path establishment procedure described below.

[0111] The optical path information management function unit 613 manages various information such as information on what wavelengths are output from each node 20 and each port, as shown in Table 5, and destination tenant information required for configuring an optical path.

[0112] [Table 5] The optical path information entry is created when the node information registration process described later is executed.

[0113] The compute control function unit 61 controls resource allocation / deployment to applications. The compute control function unit 61 acquires the resource usage status of the node 20 from the compute resource information management function unit 611, and instructs the application accommodation function unit 21 to secure computing resources and deploy applications when resources can be allocated.

[0114] The TSN control function unit 62 obtains a TSN transmission schedule associated with each node 20 and port from the TSN information management function unit 612, responds to inquiries about the availability of transmission slots, and instructs the frame transmission / reception function unit 22 to apply the TSN transmission schedule to the port.

[0115] The optical path control function unit 63 is responsible for establishing an optical path between the node 20 and the tenant.

[0116] The orchestration control function unit 12 works in conjunction with components such as a compute control function unit 61, a TSN control function unit 62, and an optical path control function unit 63 to deploy applications.

[0117] 13 corresponds to an example in which each control function unit directly issues instructions to the function units in the node 20, but a node control function unit 25 may exist in each node 20 and receive instructions on behalf of the node. The function unit that receives instructions on behalf of the node 20 may exist not only in units of nodes 20 but also in units of clusters. Also, here, the orchestration control function unit 12 issues instructions to each function unit, but a form in which each function unit directly communicates without the orchestration control function unit 12 is also conceivable. Furthermore, in this example, settings are also made to the function units of the local GW 30, but this may also be performed manually by the administrator of each tenant.

[0118] Next, a processing procedure in the fourth embodiment will be described.

[0119] FIG. 14 is a sequence diagram illustrating an example of a procedure of the node information registration process according to the fourth embodiment.

[0120] When adding a node 20, the node control function unit 25 of the node 20 or an operator registers port information (node ​​identifier and port identifier) ​​in the optical path control function unit 63 (S501). The optical path information control function unit saves the port information in the optical path information management function unit 613 (S502). The configuration of the port information saved in the optical path information management function unit 613 is as shown in Table 5, but at the current point (= before the optical path is established), the wavelength and tenant identifier columns are blank, as shown in the fourth row of Table 5.

[0121] FIG. 15 is a sequence diagram illustrating an example of a procedure of the optical path establishment process in the fourth embodiment.

[0122] Triggered by an instruction to establish an optical path manually input by an operator or an instruction to establish an optical path automatically executed when an application is deployed, the orchestration control function unit 12 requests the optical path control function unit 63 to establish an optical path (S601). At this time, a pair of identifiers of a node identifier (hereinafter referred to as a "target node identifier") and a tenant identifier (hereinafter referred to as a "target tenant identifier"), which is a pair of identifiers of a node 20 (hereinafter referred to as a "target node 20") and a tenant (hereinafter referred to as a "target tenant") connected by the optical path, is notified.

[0123] The optical path control functional unit 63 searches for available ports and wavelengths from the optical path information management functional unit 613 (Table 5) (S602, S603), and selects a port (hereinafter referred to as the "target port") and wavelength (hereinafter referred to as the "target wavelength") to be newly used (S604). Specifically, a port associated with a port identifier in any row to which wavelength information and a tenant identifier are not assigned in the optical path information management functional unit 613 (Table 5) is selected as the target port. Also, a wavelength associated with wavelength information that is not assigned to any row in the optical path information management functional unit 613 (Table 5) is selected as the target wavelength.

[0124] Next, the optical path control function unit 63 instructs the optical network N1, the node 20 related to the target node identifier, and the local GW 30 related to the target tenant identifier to set an optical path related to the target port and the target wavelength (S605, S606), thereby establishing a path between the node 20 and the local GW 30 (S607). After the path is established (S608), the optical path control function unit 63 updates the optical path information management function unit 613 (Table 5) (S609). Specifically, in the optical path information management function unit 613 (Table 5), wavelength information indicating the target wavelength and the target tenant identifier are registered for a row including the target node identifier and the target port identifier.

[0125] Next, the optical path control function unit 63 notifies the orchestration control function unit 12 of the completion of the optical path establishment together with the port identifier of the target port (hereinafter, referred to as the "target port identifier") (S610).

[0126] Next, the orchestration control function unit 12 instructs the TSN control function unit 62 to newly create transmission schedule information (S611). The information given at the time of this instruction is a target tenant identifier, a target node identifier, and a target port identifier.

[0127] The TSN control function unit 62 creates new schedule information in the TSN information management function unit 612 (Table 4) (S612). That is, a row including the target tenant identifier, target node identifier, and target port identifier and to which a schedule identifier is newly assigned is added to the TSN information management function unit 612 (Table 4). At this time, the transmission schedule information column is left blank. Next, the TSN control function unit 62 notifies the orchestration control function unit 12 of the completion of creation of the new schedule information (S613). The orchestration control function unit 12 notifies the completion of establishment of the optical path (S614).

[0128] FIG. 16 is a sequence diagram illustrating an example of a procedure for deploying an application according to the fourth embodiment.

[0129] An application developer or an operator issues a deployment request for an application (hereinafter referred to as a "target application") to the orchestration control function unit 12 (S701). Next, the orchestration control function unit 12 queries the TSN control function unit 62 for schedule information corresponding to a tenant identifier (hereinafter referred to as a "target tenant identifier") included in the deployment request (S702). The TSN control function unit 62 acquires schedule information (a node identifier (hereinafter referred to as a "target node identifier"), a port identifier (hereinafter referred to as a "target port identifier"), transmission schedule information, etc.) corresponding to the target tenant identifier from the TSN information management function unit 612 (Table 4) (S703, S704), and returns the schedule information (hereinafter referred to as a "target schedule information") to the orchestration control function unit 12 (S705).

[0130] Next, the orchestration control function unit 12 determines whether there is an available transmission slot that satisfies the transmission cycle information required by the target application based on the target schedule information (Table 2), and if there is no available transmission slot, establishes a new lightpath (S706). That is, the processing procedure described in Fig. 15 is executed. In this case, the node identifier or port identifier related to the newly established lightpath becomes the target node identifier or target port identifier.

[0131] If there is an available transmission slot, the orchestration control function unit 12 determines the transmission slot to be used (hereinafter, referred to as the "target transmission slot") (S706). However, in step S702, the requested transmission cycle information may also be notified to the TSN control function unit 62, and the TSN control function unit 62 may determine whether there is an available transmission slot that satisfies the transmission cycle information and determine the transmission slot to be used.

[0132] Next, the orchestration control function unit 12 inquires of the compute control function unit 61 about the resource usage status of the node 20 (hereinafter referred to as the "target node 20") related to the target node identifier (S708). The compute control function unit 61 acquires the resource information of the target node 20 from the compute resource information management function unit 611 (S709, S710), and returns the resource information (hereinafter referred to as the "target resource information") to the orchestration control function unit 12 (S711). The orchestration control function unit 12 checks whether or not there is a compute resource required by the target application based on the target resource information, similar to the above-mentioned confirmation of an available slot (S712), and proceeds to step S714 if there is sufficient resource. If there is not sufficient resource, a new optical path is established in another node 20 (S713). In this case, the node identifier or port identifier related to the newly established optical path becomes the target node identifier or the target port identifier.

[0133] Through the above steps, the selection of the node 20 capable of securing both the transmission slot (target transmission slot) requested by the target application and the compute resource is completed. Note that the presence or absence of the compute resource may be determined first.

[0134] Next, the TSN transmission schedule is actually set. Specifically, the orchestration control function unit 12 instructs the TSN control function unit 62 to set the TSN (S714). In the instruction, the target node identifier, the target port identifier, and the target schedule information are notified to the TSN control function unit 62.

[0135] In response to the instruction, the TSN control function unit 62 sets a transmission schedule for the port (frame transmission / reception function unit 22) associated with the target port identifier of the target node 20 associated with the target node identifier (S715 to S717). Next, the TSN control function unit 62 updates the target schedule information in the TSN information management function unit 612 (Table 4) (S718). Specifically, in the TSN information management function unit 612 (Table 4), a row including the target transmission slot and the application identifier of the target application is added to the transmission schedule information (Table 2) of the row including the target tenant identifier, the target node identifier, and the target port identifier.

[0136] Next, the TSN control function unit 62 notifies the orchestration control function unit 12 of the completion of the TSN transmission schedule setting (S719).

[0137] Next, the orchestration control function unit 12 instructs the compute control function unit 61 to deploy the target application (S720). Next, the compute control function unit 61 instructs the application accommodation function unit 21 of the target node 20 to deploy the target application (S721). Upon receiving this instruction, the application accommodation function unit 21 deploys the target application, connects the target application to a port related to the target schedule information (S722), and notifies the compute control function unit 61 of the completion of the deployment (S723).

[0138] Next, the compute control function unit 61 updates the resource information (S724). Specifically, the reduction in the resources allocated to the target application is reflected in the resource information. Next, the compute control function unit 61 notifies the orchestration control function unit 12 of the completion of the deployment of the target application (S725). Next, the orchestration control function unit 12 notifies the target application developer or operator of the completion of the deployment of the target application (S726). As described above, according to the present embodiment, it is possible to realize multi-tenancy and wide area of ​​applications that require real-time performance.

[0139] Specifically, by transmitting TSN communications using optical fiber, it is possible to minimize the occurrence of jitter, which is a problem in achieving real-time performance, while realizing TSN communication over long distances between the DC and the local GW30 (wide-area TSN communication).

[0140] In addition, at this time, the transmission schedule for the applications accommodated in the DC is separated for each tenant, and transmitted on separate wavelengths. -In principle, it is possible to eliminate the influence of TSN communications from other tenants. By applying wavelength division multiplexing (WDM), wiring costs can be dramatically reduced (combined into a single optical fiber). Abundant transmission slots are available for communication. By enabling dynamic addition of optical paths, it is possible to add transmission schedules. You can enjoy benefits such as the above (multi-tenant support).

[0141] In addition, by integrating and coordinating with a container orchestrator, the management of optical paths / transmission slots can also be realized by the container orchestrator, making it possible for application developers / operators to easily deploy applications in the same manner as so-called cloud-native application deployment (container support). This is important from the perspective of broadening the scope of application development and operation to a wider range of people, including current cloud application developers. In the configuration of FIG. 3, the cluster control function unit 11 (+ cluster resource information management function unit), node control function unit 25, and application accommodation function unit 21 correspond to the container orchestrator. In the configuration of FIG. 13, the compute control function unit 61 (+ compute resource information management function unit 611) and application accommodation function unit 21 correspond to the container orchestrator.

[0142] In addition, the container orchestrator not only considers whether the necessary resources such as CPU / memory are available and whether they (CPU / memory / NIC) are topologically close within the node 20, as is generally done, but also considers whether an optical path is available for communication and the availability of a transmission schedule to select the node 20 to deploy to, and then makes it possible to implement both exclusive settings for computing resources such as CPU / memory and exclusive settings for network resources by TSN slot allocation. · Suppression of disturbances in computer resources at node 20 by exclusive use of CPU / memory resources Scheduling that takes into account the topology within node 20 to minimize the route between node 20 and the outside (network) Minimizing fluctuations in the network by separating optical transmission and other tenant communications wavelengths By combining these, it is possible to ensure the real-time performance required for accommodating applications in a seamless manner, from the compute node to the network.

[0143] In this embodiment, the orchestrator 10 or the control server 60 is an example of a communication schedule allocation device. The cluster control function unit 11 or the optical path control function unit 63 is an example of a control unit. The cluster control function unit 11 or the TSN control function unit 62 is an example of an allocation unit.

[0144] Although the embodiment of the present invention has been described in detail above, the present invention is not limited to such specific embodiment, and various modifications and variations are possible within the scope of the gist of the present invention described in the claims. [Explanation of symbols]

[0145] 10 Orchestrator 11 Cluster Control Function Unit 12 Orchestration Control Function Unit 20 nodes 21 Application accommodation function unit 22 Frame transmission / reception function unit 23 Optical conversion function unit 24 Optical wavelength multiplexing function section 25 Node control function unit 26 Time Synchronization Function Unit 30 Local Golden Week 31 Frame transmission / reception function unit 32 Optical conversion function unit 33 Optical wavelength multiplexing function section 34 Time Synchronization Function Unit 40 TSN terminals 50 Network control function unit 60 Control Server 61 Computational Control Functions 62 TSN control function unit 63 Optical path control function unit 111 Optical path information management function unit 112 Transmission schedule information management function unit 611 Computational Resource Information Management Functions 612 TSN Information Management Functions 613 Optical Path Information Management Function Unit

Claims

1. A communication schedule allocation device that controls one or more nodes that perform optical wavelength division multiplexing communication with a plurality of tenants via an optical network, A control unit that performs control to assign a different wavelength to each of the tenants; an allocation unit that allocates a communication schedule, which is configured with a transmission period of data by an application corresponding to a certain tenant and a transmission time required for each transmission timing, to a wavelength to which the communication schedule can be allocated, among one or more wavelengths for the certain tenant; having the allocation unit determines a wavelength to which a communication schedule by the application can be allocated based on information indicating a communication schedule already allocated to the wavelength, the information being managed for each wavelength; A communication schedule allocation device comprising:

2. the allocating unit, when the application is deployed, if a wavelength has not been allocated to the tenant related to the application, allocates a wavelength different from a wavelength already allocated to the tenant.

2. The communication schedule allocation device according to claim 1.

3. when a wavelength is assigned to the tenant related to the application at the time of deploying the application, if there is no vacancy in the communication schedule assigned to the wavelength to which a communication schedule requested by the application is assigned, the assignment unit assigns a wavelength different from the wavelength already assigned to the tenant.

3. The communication schedule allocation device according to claim 2.

4. the allocation unit, when a wavelength is allocated to the tenant related to the application at the time of deploying the application, selects, from among the nodes, a node that can satisfy computer resources required by the application as a node to which the application is to be deployed; 4. The communication schedule allocation device according to claim 2 or 3.

5. A communication schedule allocation device that controls one or more nodes that perform optical wavelength division multiplexing communication with a plurality of tenants via an optical network, A control unit performs control to assign different wavelengths to each of the tenants; an allocation procedure for allocating a communication schedule, which is configured with a transmission period of data by an application corresponding to a certain tenant and a transmission time required for each transmission timing, to a wavelength to which the communication schedule can be allocated, among one or more wavelengths for the certain tenant; Run the allocation procedure determines a wavelength to which a communication schedule by the application can be allocated based on information indicating a communication schedule already allocated to the wavelength, the information being managed for each wavelength; A communication schedule allocation method comprising:

6. 5. A program for causing a computer to function as the communication schedule allocation device according to claim 1.

Images