WO2023166626A1 - 通信システム、配置計算装置、設定投入装置、通信方法、及びプログラム - Google Patents

通信システム、配置計算装置、設定投入装置、通信方法、及びプログラム Download PDF

Info

Publication number
WO2023166626A1
WO2023166626A1 PCT/JP2022/008933 JP2022008933W WO2023166626A1 WO 2023166626 A1 WO2023166626 A1 WO 2023166626A1 JP 2022008933 W JP2022008933 W JP 2022008933W WO 2023166626 A1 WO2023166626 A1 WO 2023166626A1
Authority
WO
WIPO (PCT)
Prior art keywords
host
gateway
mark
packet
instance
Prior art date
Application number
PCT/JP2022/008933
Other languages
English (en)
French (fr)
Inventor
幸洋 鋒
真悟 岡田
久史 小島
貴文 濱野
Original Assignee
日本電信電話株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 日本電信電話株式会社 filed Critical 日本電信電話株式会社
Priority to PCT/JP2022/008933 priority Critical patent/WO2023166626A1/ja
Publication of WO2023166626A1 publication Critical patent/WO2023166626A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/76—Routing in software-defined topologies, e.g. routing between virtual machines
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1083—In-session procedures

Definitions

  • the present invention relates to a packet routing scheme in a communication system.
  • a communication format that provides services by combining communication devices such as gateways (GW) and applications on a virtualization platform is widely used.
  • Non-Patent Document 1 a method of introducing an IGP or an Agent instance (Non-Patent Document 1) and making the host learn the route necessary for GW identification.
  • Non-Patent Document 2 a method is known in which an application that processes packets identifies the GW that is the source of the packet transfer by performing SNAT (Non-Patent Document 2) with the address of the GW.
  • the above conventional technology has problems such as session disconnection when the terminal is reconnected to a different GW, and the need for the host to learn a large number of routes.
  • the present invention has been made in view of the above points.
  • the session is not disconnected even when the terminal is reconnected to the GW, and it is necessary to learn a large amount of routes.
  • the purpose is to provide technology that makes it possible not to
  • a gateway for performing network processing on a packet transmitted from a device, and a first mark indicating that the transfer source is the gateway is attached to the packet transferred from the gateway. , a first host forwarding said first marked packet; an application, receiving a packet transferred from the first host, adding a second mark to the packet indicating that the transfer source is the first host, and adding the second mark a second host that forwards packets to the application and forwards packets forwarded from the application to the first host based on the second mark; A communication system is provided wherein said first host forwards packets received from said second host to said gateway based on said first mark.
  • FIG. 2 is a diagram for explaining the premise of services;
  • FIG. 2 is a diagram for explaining a service-based network; It is a figure for demonstrating a prior art. It is a figure for demonstrating a prior art. It is a figure which shows the summary of a prior art. It is a figure for demonstrating the outline
  • FIG. 4 is a diagram for explaining Proposal 1;
  • FIG. 10 is a diagram for explaining Proposal 2;
  • FIG. 10 is a diagram for explaining Proposal 2;
  • FIG. 10 is a diagram for explaining Proposal 3;
  • FIG. 10 is a diagram for explaining Proposal 3;
  • FIG. 10 is a diagram for explaining Proposal 3;
  • FIG. 10 is a diagram for explaining Proposal 3; FIG. 4 is a diagram for explaining the processing flow in the routing method of this embodiment; FIG. 10 is a diagram showing an example in the case of a VM/container nested structure; FIG. 10 is a diagram showing a processing flow of instance placement determination; FIG. 10 is a diagram showing a processing flow of setting automation; It is a figure showing the whole system composition example in an embodiment of the invention.
  • 4 is a configuration diagram of a host management unit; FIG. It is an example of a host information DB. 4 is a configuration diagram of an instance management unit; FIG. It is an example of an instance information DB. 4 is a configuration diagram of an arrangement calculation unit; FIG. 4 is a configuration diagram of a setting input unit 400; FIG. It is a figure which shows the example of each table. This is the sequence of instance placement when the service starts.
  • FIG. 4 is a diagram showing a packet flow; It is a figure which shows the hardware configuration example of an apparatus.
  • this system has a gateway (GW), an application (APP), and a device (Dev) connected to the CPE.
  • GW gateway
  • APP application
  • Dev device
  • the GW performs network processing (eg tunneling, load balancing) necessary for the service.
  • An App is an endpoint that implements service logic (eg machine learning, image processing, storage). Also, as for communication establishment, it is assumed that communication is established in the direction from Dev to GW/App that provides services.
  • the GW and App will operate in the form of VMs or containers on the virtualization infrastructure.
  • a plurality of instances exist as GWs, and by distributing and holding routes to WANs, network processing load is distributed.
  • Multiple instances of App exist to distribute the processing load of App.
  • GW and App may each be single.
  • GW1, GW2, App1, App2, CPE1, CPE2, Dev1, and Dev2 are shown.
  • GW1 holds a route addressed to Dev1 and NAT information
  • GW2 holds a route addressed to Dev2 and NAT information.
  • the base NW has different NW segments (implemented by Calico, Cillium, Openstack, etc.) between instances. Instances do not have individual paths, and communication between instances is relayed by hosts or network nodes.
  • NW segments implemented by Calico, Cillium, Openstack, etc.
  • hosts or network nodes The routing requirements for services assumed in this embodiment are as follows.
  • a "host” in this embodiment may be a physical server or a virtual server.
  • the GW holds network processing information such as transfer routes and NAT information, and it is necessary to transfer packets processed by the App to the GW that has appropriate network processing information. As shown in FIG. 2, App1, for example, needs to transfer packets addressed to Dev1 to GW1 and return packets addressed to Dev2 to GW2. dgw (default gateway) cannot perform such a forwarding process.
  • Non-Patent Document 1 As a conventional technology for transferring packets processed by App to GW having appropriate network processing information, there is a technology that introduces IGP or Agent instance (Non-Patent Document 1) and makes the host learn the route necessary for GW identification. be.
  • FIG. 3 shows that the Agent instance on Host 1 routes to App.
  • this conventional technology requires route learning (equivalent to the number of CPEs) in a large number of hosts, and has the problem of affecting scalability/resources/trackability. Moreover, there is also the problem that the operation cost of newly establishing an IGP and an additional Agent instance is high.
  • Non-Patent Document 2 There is also a conventional technology that uses SNAT.
  • SNAT is performed on packets flowing into the GW using the address of the GW instance, so that the App that processes the packets identifies the source GW.
  • Fig. 5 shows a summary of the conventional technology. As shown in FIG. 5, the conventional technology has the following two drawbacks, and a routing scheme capable of solving these problems is required.
  • Connmark (a function to mark the traced flow) on the host and PBR based on the mark.
  • instances may be placed so that processing is completed by a GW/App pair within a single host.
  • the host 1 is provided with GW1 and GW2, and the host 2 is provided with App1 and App2.
  • GW1 receives the packet at S1 and forwards the packet to App1 at S2.
  • the host 2 assigns a mark to identify the host (host 1) from which the traffic flows, and performs PBR based on the mark.
  • the host 1 assigns a mark to identify the inflow source GW (GW1) and performs PBR based thereon.
  • the host 2 performs PBR to return the packet to the inflow source host 1
  • the host 1 performs PBR to return the packet to the inflow source GW1.
  • GW1 and App1 are placed on host 1, and GW2 and App2 are placed on host 2.
  • FIG. 7 the GW in each host is made single.
  • connection tracking and PBR settings ((i) in FIG. 6) for distinguishing GWs in the host as shown in (ii) in FIG. 6 can be reduced.
  • connection tracking and PBR are used to identify the source flow. (i)) to reduce performance degradation.
  • Proposal 1 Minimum configuration
  • a policy is focused on services that establish communication in the direction from the device to the GW/App, ingress traffic is processed by an appropriate GW, and egress traffic is returned to the inflow source GW or its host server. Perform base routing (PBR).
  • PBR base routing
  • PBR based on connmark and mark will be set step by step. This eliminates the need to rewrite the packet header, so the session is not disconnected when the GW is changed. That is, it does not affect application processing.
  • FIG. 8 shows an example of processing traffic from CPE1 in a system having hosts 1 and 2.
  • GW1 holds a route addressed to CPE1.
  • connmark+PBR is set so as to send the packet to the host 1 when returning the communication packet between the CPE1 and App1 to the CPE1.
  • traffic destined for CPE1 is returned to the EID (endpoint identifier) of GW1.
  • host 1 sets connmark+PBR so that packets for communication between CPE1 and APP1 are sent to GW1.
  • the instance placement is optimized to further consolidate the processing and settings of Connmark/PBR.
  • the connmark setting for GW identification is reduced.
  • the number of apps for each host is arranged as evenly as possible so that GW/App processing can be completed within a single host, the number of flows subject to connmark/PBR for host identification and the transfer delay is intended to be reduced.
  • FIG. 9 shows a case where the number of GWs in each host is one (eg at the beginning of service), and FIG. 10 shows a case where there are multiple GWs per host (eg during peak hours).
  • ingress traffic to GW1 is basically preferentially processed by App1 within the same host1. This eliminates the need for PBR, allows traffic to be transferred from App1 to host 1, and can be transferred to GW1 using the default route of host 1, etc., thereby reducing settings.
  • hosts 1 and 2 since hosts 1 and 2 only track connections across hosts and carry out PBR, the number of connections to be tracked and the number of flows to be PBRed can be reduced. For example, in host 2, only packets that flowed in from host 1 are tracked and marked. Also, only marked packets processed by App can be routed to host 1 by PBR and transferred to GW 1 by the default route of host 1 or the like.
  • connmark/PBR is required to identify the GW within the host 1, as described above.
  • Ingress traffic connmarks on the interface of GW1/3 and routes packets to GW1/3 with PBR based on the mark of incoming packets to Host1.
  • host 2 only packets that flowed in from host 1 are tracked and marked, only marked packets processed by App are routed to host 1 by PBR, and transferred to GW1 by host 1's default route, etc.
  • Proposal 3 Method setting automation system
  • Proposal 3 by adopting a system that automatically sets the above-mentioned method based on the usage status of the host, settings are made according to increases and decreases in the number of instances, enabling stable communication. . Configuration examples, setting timings, and setting details for each host usage situation will be described with reference to FIGS. 11 to 13. FIG.
  • Case 1 Case where multiple GWs operate on the host>
  • a configuration example of Case 1 is shown in FIG.
  • the setting timing in case 1 is at the time of GW activation/deletion, and the setting contents are (a) Connmark setting for the inflow flow (for the number of GWs), and (b) the GW corresponding to the return flow mark value. This is the PBR setting (for the number of GWs) for transfer.
  • settings (a) and (b) are unnecessary when there is one GW instance.
  • ⁇ Case 2 App runs on the host> A configuration example of Case 2 is shown in FIG.
  • the setting timing in case 2 is when the App is started/deleted, and the setting contents are (c) Connmark setting for the inflow flow (for the number of hosts), and (d) GW corresponding to the return flow mark value. This is the PBR setting (for the number of hosts) for transfer.
  • Case 3 Case where multiple GWs and apps are running on the host> A configuration example of case 3 is shown in FIG.
  • the setting timing in case 3 is when App and Gw are activated/deleted, and the setting contents are (a) to (d) described in cases 1 and 2.
  • FIG. In the following, the contents of the proposals 1 to 3 mentioned above will be described in more detail.
  • Dev1 sends a packet to Application 1 on Host 2.
  • CPE1 encaps the packet and transmits it to GW1.
  • GW1 receives the packet and transmits the packet to application 1 after decapping.
  • the host 1 connmarks the packet in the request direction.
  • the host 2 running the application 1 connmarks each source mac in the request direction.
  • connmark is performed on the host 2 on which the application 1 operates, with the source mac address as a trigger.
  • a source mac address as a connmark trigger is an example. Any information may be used as long as it is information contained in the packet and can identify the source host. For example, the source IP address of the tunneling header may be used.
  • the packet is transferred to the host 1 (on which GW1 operates) that is the inflow source. That is, in the Reply direction, the packet is transferred to the host 1 from which the packet is received according to the mark value.
  • the host 1 forwards the reply packet to the inflow source GW1 based on the mark value in S3.
  • the host 1 has multiple GWs, so this setting is necessary to identify them.
  • the system of this embodiment can also be implemented in a VM/container nesting structure.
  • the path of the instance (container) is not advertised in the physical server segment, so communication is performed using tunneling such as IPIP.
  • FIG. 15 A configuration example that employs a VM/container nesting structure is shown in FIG. As shown in FIG. 15, communication is established by performing the procedures of S1 to S4 in VMs 1 and 2 that accommodate instances. No setting to the physical server is required. Specifically, it is as follows.
  • VM1 marks the flow with the GW number by CONNMARK.
  • VM2 marks the flow with the source host number with CONNMARK.
  • VM2 sees the host number marked on the flow and forwards the flow to the corresponding host with IPIP.
  • VM1 sees the GW number marked on the flow and forwards the flow to the corresponding GW.
  • S101 to S106 one GW is deployed to one host. If all GWs still cannot be deployed, additional GWs are deployed to the host in S107-S110. Since all of S101 to S106 and S107 to S110 are repetitions for the host, each step will be described with "host A" as an example.
  • the placement calculation unit 300 confirms the status of host A. To check the status means to acquire information necessary for placement determination. In S102, the placement calculation unit 300 confirms whether or not there are resources for the host A, and proceeds to S103 if there are resources for deploying the GW, and proceeds to S106 if there are none.
  • the placement calculation unit 300 confirms the number of GWs of host A, and proceeds to S106 if there is a GW, and proceeds to S104 if there is no GW.
  • S104 GW is deployed to host A.
  • S105-S106 if there is no undeployed GW, the process is terminated, and if there is an undeployed GW and an unconfirmed host, the process returns to S101 to process the next host.
  • the instance management unit 200 determines the number of hosts and the number of instances as resources. In S202, the instance management unit 200 (or the placement calculation unit 300) places instances.
  • the GW in the host is made as single as possible, and the number of applications per host is made uniform.
  • the setting input unit 400 determines the state of the host based on the information from the host management unit 100, and proceeds to S204 if the App is operating, and to S205 if the GW and APP are operating. , and if only the GW is operating, proceed to S206.
  • the setting input unit 400 performs the setting input of FIG. 12, and in S205, performs the setting input of FIG.
  • S206 if the number of GWs is one, proceed to S208. If the number of GWs is plural, then in S207, the setting input of FIG. 11 is performed. In S208, the instance management unit 200 monitors used resources.
  • FIG. 18 shows an example of the overall configuration of the system according to this embodiment.
  • this system includes a CPE 10, a GW resolution unit 20, a host 1 (host server) on which GW1 operates, a host 2 on which App1 operates, a host management unit 100, a DB 30, an instance management unit 200, an allocation calculation It has a section 300 and a setting entry section 400 .
  • Each part shown in FIG. 18 may be a single device, or a plurality of parts may constitute one device.
  • the GW resolution unit 20, the host management unit 100, the instance management unit 200, the placement calculation unit 300, and the setting input unit 400 are replaced with the GW resolution device 20, the host management device 100, the instance management device 200, the placement calculation device 300, and the setting input device 400, respectively. You can call it
  • the outline of each part (each device) is as follows.
  • the CPE 10 is a network device that accommodates client terminals (devices).
  • the CPE 10 determines the GW of the connection destination by inquiring of the GW resolution unit 20 .
  • GW1 which is an instance that operates as a NW function for services
  • App1 that provides application logic operate on hosts 1 and 2, respectively.
  • the host management unit 100 manages the host names, network information, and resource information of these hosts in the DB30.
  • the placement calculation unit 300 determines the host to which the instance is to be placed, based on the number of hosts and the resource status.
  • the instance management unit 200 arranges instances based on the decisions made by the arrangement calculation unit 300, and manages instance IDs, network information, and resource information.
  • the setting input unit 400 performs network settings for each host based on the instance arrangement status.
  • the host management unit 100 acquires host names, network information, and resource information from each host and manages them in a DB.
  • FIG. 19 shows the configuration of the host management unit 100. As shown in FIG. As shown in FIG. 19, the host management unit 100 has a host information DB 110, a host information acquisition unit 120, and a distribution API function unit .
  • the host information acquisition unit 120 accesses the host to acquire the above information, and stores the acquired information in the host information DB 110.
  • the host information DB 110 manages network information such as host IDs, IP addresses/mac addresses, and host resources.
  • the external layout calculation unit 300 and setting input unit 400 access the host information DB 110 via the distribution API function unit 130 and acquire information necessary for processing, such as network information and resource usage rate.
  • FIG. 20 shows an example of information stored in the host information DB 110. As shown in FIG.
  • the instance management unit 200 deploys instances.
  • the instance name, instance type, and network information are acquired and managed in the DB.
  • FIG. 21 shows a configuration example of the instance management unit 200. As shown in FIG.
  • the instance management unit 200 has an instance information DB 210, an instance deploy function unit 220, an instance information acquisition unit 230, and a distribution API function unit 240.
  • the instance deployment function unit 220 selects hosts based on instructions from the placement calculation unit 30 and deploys instances.
  • the instance information acquisition unit 230 accesses the instance, acquires the above information, and stores it in the instance information DB 210.
  • the instance information D210B manages network information such as instance IDs, IP addresses/mac addresses, and host resources.
  • the external layout calculation unit 300 and setting input unit 400 access the instance information DB 210 via the distribution API function unit 240 and acquire necessary information such as application type, network information, and operating host information.
  • FIG. 22 shows an example of information stored in the instance information DB 210. As shown in FIG.
  • the placement calculator 300 determines the host on which to deploy the instance.
  • FIG. 23 shows a configuration example of the placement calculation unit 300. As shown in FIG. As shown in FIG. 23 , the layout calculation unit 300 has an information acquisition unit 310 , a layout determination unit 320 and a layout instruction unit 330 .
  • the information acquisition unit 310 accesses the instance management unit 200/host management unit 100 via the distribution API function unit and acquires the resource availability status for each host and the number of GW instances and APP instances already in operation.
  • the placement determining unit 320 determines the GW instance placement destination host according to the flow of GW placement determination processing (FIG. 16). Also, with regard to APP instances, the hosts on which APP instances are arranged are determined so that the number of instances for each type of APP is as even as possible on a host-by-host basis, as long as the host resources permit.
  • the placement instruction unit 330 instructs the instance management unit 200 on the placement method based on the calculation result of the placement determination unit 320 .
  • the setting input unit 400 sets the connmark and PBR necessary for the technology according to the present embodiment to the host.
  • FIG. 24 shows a configuration example of the setting input unit 400.
  • the setting input unit 400 has a host parameter DB 410 , an instance parameter DB 420 , a table management DB 430 , an information acquisition unit 440 , a setting generation unit 450 and a setting input processing unit 460 .
  • the information acquisition unit 440 accesses the instance management unit 200/host management unit 100 via the distribution API function unit, and obtains the resource availability status for each host, the number of GW instances in operation, the APP instance, and the network required for setting. Acquire information and store it in the corresponding DB.
  • the instance parameter DB 420 manages the operational status of instances and interface names.
  • the host parameter DB 410 manages operational information and address information of instances in the host.
  • the table management DB 430 manages on which host the table for PBR is operating.
  • the setting generation unit 450 determines the state of the number of instances for each host based on information from various DBs, and generates settings for connmark and PBR.
  • settings include (1) connmark based on the GW interface name, (2) connmark based on the mac address of the host, (3) settings for policy-based routing based on various mark values, and the like. be done.
  • the setting input processing unit 460 sets the corresponding host based on the calculation result of the setting generation unit 450.
  • FIG. 25 shows an example of information stored in each of the table management DB 430, instance parameter DB 420, and host parameter DB 410.
  • FIG. 26 shows an example of a sequence for arranging instances on hosts 1 and 2 as instance arrangement at service start.
  • Each of the hosts 1 and 2 may be a physical machine or a virtual machine.
  • the sequence shown in FIG. 26 shows the procedures for starting the host at the time of starting the service, calculating the allocation of the instances, starting the instances, and inputting the settings to the host.
  • the host management unit 100 activates each host of the infrastructure that constitutes the service, and collects information about each activated host.
  • the collected information is stored in the host information DB 110 as shown in FIG. 20, for example.
  • the instance management unit 200 acquires host information from the host management unit 100.
  • the placement calculation unit 300 acquires instance information from the host management unit 100 .
  • the instance management unit 200 requests the placement calculation unit 300 to calculate the placement of instances.
  • the placement calculation unit 300 determines the placement based on the information of the instance and the host, and in S9, instructs the instance management unit 200 for placement.
  • the instance management unit 200 selects a host and starts an instance.
  • instance information is sent to the instance management unit 200 and stored in the instance information DB (FIG. 22).
  • the setting input unit 400 acquires host information from the host management unit 100 in S14, and acquires instance information from the instance management unit 200 in S15. In S16, the setting input unit 400 uses the acquired information to create necessary network settings such as connmark and PBR, and in S17 and S18, inputs the settings to each host.
  • the packet transmitted by the device 50 arrives at the CPE 10 (S1), resolves the GW of the connection destination by an inquiry to the GW resolution unit 20 (S2, S3), and is transferred to the host 1 where the GW 1 operates (S4 ).
  • the host 1 transfers the incoming packet to GW1 (S5). After GW1 performs necessary NW processing on this packet in S6, it is transferred to host 1 again for communication to App1 in S7.
  • the host 1 connmarks with the interface name etc. corresponding to GW1. Host 1 sends packets marked for flow identification to Host 2 at S9 for communication to App1.
  • the host 2 connmarks the packet using the source mac address (here, the address of the host 1) as a key.
  • the source mac address here, the address of the host 1
  • App processing of the packet is performed in App1.
  • the host 2 associates the mark value added in S10 with the mac address, and performs PBR on the return packet after processing in App1 based on the mark. Thereby, the packet is transferred to the host 1 (S15). Similarly, in S16, the host 1 that has received the return packet performs PBR to return the packet to the inflow source GW1 according to the mark value associated with the interface name of the GW1. NW processing is performed in S17 to S19, and the packet is transferred from the host 1 to the device 50 in S20.
  • GW resolution unit 20 (Hardware configuration example) GW resolution unit 20, host management unit 100, instance management unit 200, placement calculation unit 300, setting input unit 400, GW resolution device 20, host management device 100, instance management device 200, placement calculation device 300, setting input device 400, All of the host, GW, and App can be implemented, for example, by causing a computer to execute a program. This computer may be a physical computer or a virtual machine on the cloud.
  • GW resolution unit 20, host management unit 100, instance management unit 200, placement calculation unit 300, setting input unit 400, GW resolution device 20, host management device 100, instance management device 200, placement calculation device 300, setting input device 400, host, GW, and App are collectively called a device.
  • the device can be realized by executing a program corresponding to the processing performed by the device using hardware resources such as a CPU and memory built into the computer.
  • the above program can be recorded in a computer-readable recording medium (portable memory, etc.), saved, or distributed. It is also possible to provide the above program through a network such as the Internet or e-mail.
  • FIG. 28 is a diagram showing a hardware configuration example of the computer.
  • the computer of FIG. 28 has a drive device 1000, an auxiliary storage device 1002, a memory device 1003, a CPU 1004, an interface device 1005, a display device 1006, an input device 1007, an output device 1008, etc., which are interconnected by a bus BS.
  • a program that implements the processing in the computer is provided by a recording medium 1001 such as a CD-ROM or memory card, for example.
  • a recording medium 1001 such as a CD-ROM or memory card
  • the program is installed from the recording medium 1001 to the auxiliary storage device 1002 via the drive device 1000 .
  • the program does not necessarily need to be installed from the recording medium 1001, and may be downloaded from another computer via the network.
  • the auxiliary storage device 1002 stores installed programs, as well as necessary files and data.
  • the memory device 1003 reads and stores the program from the auxiliary storage device 1002 when a program activation instruction is received.
  • the CPU 1004 implements functions related to the device according to programs stored in the memory device 1003 .
  • the interface device 1005 is used as an interface for connecting to a network or the like.
  • a display device 1006 displays a GUI (Graphical User Interface) or the like by a program.
  • An input device 1007 is composed of a keyboard, a mouse, buttons, a touch panel, or the like, and is used to input various operational instructions.
  • the output device 1008 outputs the calculation result.
  • a gateway that performs network processing on a packet transmitted from a device, affixes a first mark to a packet forwarded from the gateway to indicate that the gateway is the forwarding source, and adds the first mark to the packet forwarded from the gateway.
  • a first host that forwards packets tagged with an application, receiving a packet transferred from the first host, adding a second mark to the packet indicating that the transfer source is the first host, and adding the second mark a second host that forwards packets to the application and forwards packets forwarded from the application to the first host based on the second mark;
  • the communication system wherein the first host forwards packets received from the second host to the gateway based on the first mark.
  • (Appendix 2) 3. The communication system of clause 1, wherein the first host and the second host each use connmarks to mark packets and use policy-based routing for forwarding packets based on the marks.
  • a placement computing device for determining on which host to deploy a gateway instance in a communication system comprising multiple hosts, comprising: memory; at least one processor connected to the memory; including The processor Get the resource information of each host and the number of deployed gateway instances, As long as the host has the resources to deploy a gateway instance, decide to deploy one gateway instance on each host, and for gateway instances that have not been decided to deploy, Deployed Computing Unit that decides to deploy.
  • Appendix 4 4. The allocation computing device according to claim 3, wherein, with respect to application instances, the processor determines the allocation to each host so that the number of instances is as even as possible among the hosts.
  • a setting input device for inputting settings for a host in a communication system including a plurality of hosts, memory; at least one processor connected to the memory; including The processor Get host information and instance information for each host where the instance is located, For a host where multiple gateway instances are arranged, create settings for mark processing for inflow flows for each gateway instance and settings for routing using marks for return flows for each gateway instance, generates settings for mark processing for inflow flows and settings for routing using marks for return flows, for the host where A setting input device that submits the generated settings to the relevant host.
  • a communication method in a communication system including a first host with a gateway and a second host with an application comprising: The first host forwards a packet transmitted from a device to the gateway, adds a first mark to the packet forwarded from the gateway to indicate that a forwarding source is the gateway, and forwarding packets marked with to said second host; The second host receives a packet transferred from the first host, puts a second mark on the packet indicating that the transfer source is the first host, and applies the second mark. to the application, forwarding packets forwarded from the application to the first host based on the second mark; The communication method, wherein the first host forwards the packet received from the second host to the gateway based on the first mark.
  • CPEs 10 CPEs 20 GW resolution unit 30 DB 50 Device 100 Host management unit 110 Host information DB 120 host information acquisition unit 130 distribution API function unit 200 instance management unit 210 instance information DB 220 Instance deployment function unit 230 Instance information acquisition unit 240 Distribution API function unit 300 Placement calculation unit 310 Information acquisition unit 320 Placement determination unit 330 Placement instruction unit 400 Setting input unit 410 Host parameter DB 420 Instance Parameter DB 430 table management DB 440 information acquisition unit 450 setting generation unit 460 setting input processing unit 1000 drive device 1001 recording medium 1002 auxiliary storage device 1003 memory device 1004 CPU 1005 interface device 1006 display device 1007 input device 1008 output device

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Multimedia (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

通信システムにおいて、デバイスから送信されたパケットに対してネットワーク処理を行うゲートウェイを備え、前記ゲートウェイから転送されたパケットに、転送元が前記ゲートウェイであることを示す第１のマークを付し、前記第１のマークを付したパケットを転送する第１のホストと、アプリケーションを備え、前記第１のホストから転送されたパケットを受信し、当該パケットに、転送元が前記第１のホストであることを示す第２のマークを付け、前記第２のマークを付したパケットを前記アプリケーションに転送し、前記アプリケーションから転送されたパケットを、前記第２のマークに基づいて、前記第１のホストに転送する第２のホストと、を備え、前記第１のホストは、前記第２のホストから受信したパケットを、前記第１のマークに基づいて、前記ゲートウェイに転送する。

Description

通信システム、配置計算装置、設定投入装置、通信方法、及びプログラム
　本発明は、本発明は、通信システムにおけるパケットのルーティング方式に関連するものである。
　仮想化基盤上でゲートウェイ（ＧＷ）などの通信装置やアプリケーションを組み合わせてサービスを提供する通信形態が広く普及している。
　利用者のデバイス（端末）からＧＷを経由してアプリケーションを利用する際に、アプリケーションの処理結果等を元のデバイスに返すことが必要な場合がある。そのための従来技術としては、ＩＧＰやＡｇｅｎｔインスタンス（非特許文献１）を導入してＧＷ識別に必要な経路をホストに学習させる方法が知られている。
　また、別の従来技術として、ＧＷのアドレスでＳＮＡＴ（非特許文献２）を行うことで、パケットを処理するアプリケーションが、パケット転送元のＧＷを識別する方法も知られている。
Calico Felix : https://projectcalico.docs.tigera.io/maintenance/monitor/monitor-component-metrics BIG IP SNAT: https://www.f5.com/ja_jp/services/resources/glossary/secure-network-address-translation-snat
　しかし、上記の従来技術では、端末が異なるＧＷに再接続した場合にセッションが切れる、ホストに大量の経路を学習させる必要がある等の課題があった。
　本発明は上記の点に鑑みてなされたものであり、アプリケーションが処理したパケットを適切なＧＷまで転送する技術において、端末のＧＷ再接続時にもセッションが切れず、大量の経路の学習も必要としないことを可能とする技術を提供することを目的とする。
　開示の技術によれば、デバイスから送信されたパケットに対してネットワーク処理を行うゲートウェイを備え、前記ゲートウェイから転送されたパケットに、転送元が前記ゲートウェイであることを示す第１のマークを付し、前記第１のマークを付したパケットを転送する第１のホストと、
　アプリケーションを備え、前記第１のホストから転送されたパケットを受信し、当該パケットに、転送元が前記第１のホストであることを示す第２のマークを付け、前記第２のマークを付したパケットを前記アプリケーションに転送し、前記アプリケーションから転送されたパケットを、前記第２のマークに基づいて、前記第１のホストに転送する第２のホストと、を備え、
　前記第１のホストは、前記第２のホストから受信したパケットを、前記第１のマークに基づいて、前記ゲートウェイに転送する
　通信システムが提供される。
　開示の技術によれば、アプリケーションが処理したパケットを適切なＧＷまで転送する技術において、端末のＧＷ再接続時にもセッションが切れず、大量の経路の学習も必要としないことを可能とする技術が提供される。
サービスの前提を説明するための図である。 サービス基盤のネットワークを説明するための図である。 従来技術を説明するための図である。 従来技術を説明するための図である。 従来技術のまとめを示す図である。 提案方式の概要を説明するための図である。 提案方式の概要を説明するための図である。 提案１を説明するための図である。 提案２を説明するための図である。 提案２を説明するための図である。 提案３を説明するための図である。 提案３を説明するための図である。 提案３を説明するための図である。 本実施の形態のルーティング方式における処理フローを説明するための図である。 ＶＭ／コンテナ入れ子構造の場合の例を示す図である。 インスタンスの配置決定の処理フローを示す図である。 設定自動化の処理フローを示す図である。 本発明の実施の形態におけるシステムの全体構成例を示す図である。 ホスト管理部の構成図である。 ホスト情報ＤＢの例である。 インスタンス管理部の構成図である。 インスタンス情報ＤＢの例である。 配置計算部の構成図である。 設定投入部４００の構成図である。 各テーブルの例を示す図である。 サービス開始時のインスタンスの配置のシーケンスである。 パケットフローを示す図である。 装置のハードウェア構成例を示す図である。
　以下、図面を参照して本発明の実施の形態（本実施の形態）を説明する。以下で説明する実施の形態は一例に過ぎず、本発明が適用される実施の形態は、以下の実施の形態に限られるわけではない。
　（サービスの前提について）
　まず、本実施の形態で想定するサービスを提供するシステムについて、図１を参照して説明する。
　図１に示すように、本システムは、ゲートウェア（ＧＷ）とアプリケ―ション（ＡＰＰ）、ＣＰＥに接続されるデバイス（Ｄｅｖ）を有する。
　ここで、ＧＷは、サービスに必要なネットワーク処理（例：トンネリング，負荷分散）を実施する。Ａｐｐは、サービスロジックを実装したエンドポイント（例：機械学習，画像処理，ストレージ）である。また、通信確立については、Ｄｅｖからサービスを提供するＧＷ／Ａｐｐへの方向の通信確立を実施することを想定する。
　本実施の形態では、ＧＷやＡｐｐは，仮想化基盤上のＶＭあるいはコンテナの形式で動作することを想定している。ＧＷとして複数のインスタンスが存在し、ＷＡＮ宛の経路を分散して保持することで、ネットワーク処理を負荷分散する。Ａｐｐとして複数のインスタンスが存在し、Ａｐｐの処理負荷を分散する。なお、ＧＷとＡｐｐはそれぞれ単一であってもよい。
　図１の例では、ＧＷ１、ＧＷ２、Ａｐｐ１、Ａｐｐ２、ＣＰＥ１、ＣＰＥ２、Ｄｅｖ１、Ｄｅｖ２が示されている。図１に示すとおり、ＧＷ１は、Ｄｅｖ１宛の経路やＮＡＴ情報を保持し、ＧＷ２は、Ｄｅｖ２宛の経路やＮＡＴ情報を保持する。
　次に、サービス基盤のネットワーク（基盤ＮＷ）の前提について説明する。基盤ＮＷでは、インスタンス間で異なるＮＷセグメント（例えばCalico, Cillium, Openstack等で実現される）を持つ。インスタンスは個々の経路を持たず、インスタンス同士の通信はホストあるいはネットワークノードが中継する。本実施の形態で想定するサービスのルーティング要件は下記のとおりである。なお、本実施の形態における「ホスト」は物理サーバであってもよいし、仮想サーバであってもよい。
　ＧＷが転送経路やＮＡＴ情報等のネットワーク処理情報を保持しており、Ａｐｐが処理したパケットを適切なネットワーク処理情報を持つＧＷまで転送する必要がある。図２に示すとおり、例えば、Ａｐｐ１は、Ｄｅｖ１宛のパケットをＧＷ１に転送し、Ｄｅｖ２宛のパケットをＧＷ２に返す必要がある。ｄｇｗ（デフォルトゲートウェイ）はこのような転送処理を行うことができない。
　（従来技術）
　Ａｐｐが処理したパケットを適切なネットワーク処理情報を持つＧＷまで転送するための従来技術として、ＩＧＰやＡｇｅｎｔインスタンス（非特許文献１）を導入し、ＧＷ識別に必要な経路をホストに学習させる技術がある。図３には、ホスト１上のＡｇｅｎｔインスタンスがＡｐｐに対して経路設定を行うことが示されている。
　しかし、この従来技術では、多数のホストで（ＣＰＥ数相当の）経路学習が必要となり、スケーラビリティ／リソース／追跡性に影響があるという課題がある。また、ＩＧＰや追加のＡｇｅｎｔインスタンスを新設するオペレーションコストがかかるという課題もある。
　また、ＳＮＡＴを用いる従来技術もある。この従来技術では、図４に示すとおり、ＧＷへの流入パケットに対し、ＧＷインスタンスのアドレスでＳＮＡＴを行うことで、パケットを処理するＡｐｐが送信元のＧＷを識別する（非特許文献２）。
　しかし、ＣＰＥが移動する場合など、ＣＰＥ発パケットが異なるＧＷに再接続する場合がある。このとき、Ａｐｐ視点では送信元ＩＰが変更されたように見えるため、セッションを維持できなくなる。図４の例において、例えば、ＣＰＥ１発のパケットがＧＷ２に接続する際には、セッションを維持できなくなる。
　図５に従来技術のまとめを示す。図５に示すとおり、従来技術では以下の二つの欠点があり、これらを解決可能なルーティング方式が必要である。
　・端末が異なるＧＷに接続した場合などでもアプリケーション処理に影響する
　・ホストに大量の経路を学習させる必要がある
　（提案方式の概要）
　上記の課題を解決するための本実施の形態における提案方式の概要を説明する。本実施の形態では、デバイスからサービス（ＧＷ／Ａｐｐ）への方向で通信確立するサービスに着目し、Ｅｇｒｅｓｓトラヒックをパケット流入元のＧＷやそのホストサーバまで段階的に戻すように、ポリシーベースルーティング（ＰＢＲ）を行う。
　具体的には、上記をホストでのＣｏｎｎｍａｒｋ（追跡したフローにマークを付する機能）とマークに基づくＰＢＲにより実現する。
　また、配置最適化の工夫として、ＣｏｎｎｍａｒｋやＰＢＲの対象になるフロー数を削減するため、単一ホスト内のＧＷ／Ａｐｐのペアで処理が完結するようにインスタンスを配置することとしてもよい。
　図６を参照して基本構成の例（段階的にＰＢＲを行うルーティング方式）を説明する。ホスト１にＧＷ１とＧＷ２が備えられ、ホスト２にＡｐｐ１とＡｐｐ２が備えられる。Ｓ１において、ＧＷ１はパケットを受信し、Ｓ２においてＡｐｐ１へパケットを転送する。Ｓ３では、（ｉ）において、ホスト２が、トラヒック流入元のホスト（ホスト１）を識別するマーク付与とそれに基づくＰＢＲを行う。（ｉｉ）において、ホスト１が、流入元のＧＷ（ＧＷ１）を識別するマーク付与とそれに基づくＰＢＲを行う。
　つまり、（ｉ）では、ホスト２で、パケットを流入元のホスト１に戻すＰＢＲを行い、（ｉｉ）では、ホスト１で、パケットを流入元のＧＷ１に戻すＰＢＲを行う。
　図７を参照して配置上の工夫（インスタンス配置方式）を説明する。図７に示すとおり、ホスト１にＧＷ１とＡｐｐ１を配置し、ホスト２にＧＷ２とＡｐｐ２を配置する。つまり、各ホスト内のＧＷを単一にする。これにより、図６の（ｉｉ）で示したような、ホスト内でＧＷを区別するためのコネクション追跡やＰＢＲ（図６の（ｉ））設定を削減できる。
　図７のＳ１～Ｓ４のフローの通り、基本的にはホスト１で処理を完結することができる。Ｓ１１～Ｓ１４のフローのとおり、異なるＧＷに再接続したフローやリソースの問題により単一ホストで処理を完結できないフローのみを対象に、流入元のフローを識別するためのコネクション追跡やＰＢＲ（図６の（ｉ））を行い、性能劣化を低減する。
　以下では、本実施の形態に係る提案内容である提案１～提案３のそれぞれについて説明する。
　（提案１：最小構成）
　提案１として本実施の形態に係るシステムの最小構成について説明する。本実施の形態に係るシステムでは、デバイスからＧＷ／Ａｐｐへの方向で通信確立するサービスに着目し、Ｉｎｇｒｅｓｓトラヒックを適切なＧＷで処理し、Ｅｇｒｅｓｓトラヒックを流入元のＧＷやそのホストサーバに戻すポリシーベースルーティング（ＰＢＲ）を行う。
　具体的には、ｃｏｎｎｍａｒｋとｍａｒｋに基づくＰＢＲを段階的に設定する。これにより、パケットヘッダの書き換えが不要なため、ＧＷ変更時にセッションが切れない。すなわち、アプリケーション処理に影響を与えない。
　また、本システムでは、Ｃｏｎｎｍａｒｋの処理はフローに対して動的に行われ、その設定数はホスト単位／ＧＷ単位となる。これにより、Ｄｅｖ単位での設定が必要となる従来方式と比較して少ない設定で済む。
　図８に、ホスト１とホスト２を有するシステムにおいて、ＣＰＥ１からのトラヒックを処理する場合の例を示す。図８に示すとおり、ＧＷ１は、ＣＰＥ１宛の経路を保持する。１段階目の設定として、ホスト２において、ＣＰＥ１とＡｐｐ１との間の通信のパケットをＣＰＥ１へ戻す際に、ホスト１へ送るようにｃｏｎｎｍａｒｋ＋ＰＢＲの設定がなされる。また、Ａｐｐ１において、ＣＰＥ１宛のトラヒックはＧＷ１のＥＩＤ（エンドポイント識別子）に戻す。
　２段階目の設定として、ホスト１において、ＣＰＥ１とＡＰＰ１との間の通信のパケットはＧＷ１に送るようにｃｏｎｎｍａｒｋ＋ＰＢＲの設定がなされる。
　（提案２：配置最適化）
　前述したように、本実施の形態では、インスタンス配置を最適化して、Ｃｏｎｎｍａｒｋ／ＰＢＲの処理や設定をさらに集約することとしている。
　すなわち、ホスト内のＧＷを極力単一にすることで、ＧＷ識別用のｃｏｎｎｍａｒｋ設定を削減する。また、ホストごとのＡｐｐ数を極力均等に配置して、単一ホスト内でＧＷ／Ａｐｐの処理が完結できるようにすることで、ホスト識別用のｃｏｎｎｍａｒｋ／ＰＢＲの対象となるフロー数と転送遅延を削減することとしている。
　図９に、各ホスト内のＧＷ数が一つの場合（例：サービス初期）を示し、図１０に、ホストごとのＧＷ数が複数の場合（例：ピーク時）を示す。
　図９に示す場合では、ＧＷ１へのＩｎｇｒｅｓｓトラヒックは基本的に同じホスト１内のＡｐｐ１で優先的に処理する。これにより、ＰＢＲは不要となり、トラヒックをＡｐｐ１からホスト１に転送し、ホスト１のｄｅｆａｕｌｔ　ｒｏｕｔｅ等でＧＷ１に転送することができ、設定削減が可能となる。
　また、ホスト１、２では、ホストをまたぐコネクションのみ追跡してＰＢＲを行うので、追跡するコネクション数やＰＢＲするフロー数を削減できる。例えば、ホスト２では、ホスト１から流入したパケットのみ追跡してマーキングする。また、Ａｐｐで処理したマーク付きのパケットのみをホスト１にＰＢＲでルーティングし、ホスト１のｄｅｆａｕｌｔ　ｒｏｕｔｅ等でＧＷ１に転送することができる。
　図１０の例では、前述したように、ホスト１内でＧＷを識別するためのｃｏｎｎｍａｒｋ／ＰＢＲが必要になる。
　図１０に示すように、ホスト１において、ＩｎｇｒｅｓｓトラヒックはＧＷ１／３のインターフェースでｃｏｎｎｍａｒｋを行って、ホスト１への流入パケットのマークに基づき、パケットをＧＷ１／３へＰＢＲでルーティングする。
　ホスト２では、ホスト１から流入したパケットのみ追跡してマーキングし、Ａｐｐで処理したマーク付きのパケットのみをホスト１にＰＢＲでルーティングし、ホスト１のｄｅｆａｕｌｔ　ｒｏｕｔｅ等でＧＷ１に転送する。
　（提案３：方式設定自動化システム）
　提案３においては、ホストの使用状況に基づいて前述の方式設定を自動的に行うシステムを採用することで、インスタンスの増減に追従して設定を行い、安定的な通信を可能にすることとしている。ホストの使用状況毎の構成例、設定タイミング、設定内容を、図１１～図１３を用いて説明する。
　＜ケース１：ホストに複数のＧＷが動作するケース＞
　ケース１の構成例を図１１に示す。ケース１での設定タイミングは、ＧＷ起動時／削除時であり、設定内容は、（ａ）流入フローに対するＣｏｎｎｍａｒｋ設定（ＧＷ個数分）、及び、（ｂ）戻りフローのマーク値に対応するＧＷに転送するためのＰＢＲ設定（ＧＷ個数分）である。なお、ケース１において、設定（ａ），（ｂ）は、ＧＷインスタンスが一個の場合には不要である。
　＜ケース２：ホストにＡｐｐが動作するケース＞
　ケース２の構成例を図１２に示す。ケース２での設定タイミングは、Ａｐｐ起動時／削除時であり、設定内容は、（ｃ）流入フローに対するＣｏｎｎｍａｒｋ設定（ホスト数分）、及び、（ｄ）戻りフローのマーク値に対応するＧＷに転送するためのＰＢＲ設定（ホスト数分）である。
　＜ケース３：ホストに複数ＧＷとＡｐｐが動作するケース＞
　ケース３の構成例を図１３に示す。ケース３での設定タイミングは、ＡｐｐとＧｗの起動時／削除時であり、設定内容は、ケース１、２で説明した（ａ）～（ｄ）である。以下では、上述した提案１～３に関する内容をより詳細に説明する。
　（提案１のルーティング方式における処理フロー）
　図１４を参照して、提案１のルーティング方式における処理フローを説明する。この処理フローでは、流入元のＧＷ宛にアプリケーションからのｒｅｐｌｙを返す。具体的な処理を、図１４を参照して説明する。
　Ｓ０において、Ｄｅｖ１は、ホスト２上のアプリ１に向けてパケットを送信する。Ｓ１において、ＣＰＥ１は、パケットをＥｎｃａｐしてＧＷ１宛てに送信する。Ｓ２において、ＧＷ１は、パケットを受信し、Ｄｅｃａｐ後にパケットをアプリ１に送信する。
　Ｓ３において、ホスト１は、ｒｅｑｕｅｓｔ方向のパケットに対してｃｏｎｎｍａｒｋを行う。Ｓ４において、アプリ１が動作するホスト２においてｒｅｑｕｅｓｔ方向でｓｏｕｒｃｅ　ｍａｃごとにｃｏｎｎｍａｒｋする。つまり、アプリ１が動作するホスト２上でｓｏｕｒｃｅ　ｍａｃ　ａｄｄｒｅｓｓをトリガーにしたｃｏｎｎｍａｒｋを行う。なお、ｃｏｎｎｍａｒｋのトリガーとしてｓｏｕｒｃｅ　ｍａｃ　ａｄｄｒｅｓｓを使用することは一例である。パケットに含まれている情報であって、かつ流入元のホストが特定可能な情報であればどのような情報を用いてもよい。例えばトンネリングヘッダの送信元ＩＰアドレスなどを用いてもよい。
　Ｓ５において、流入元の（ＧＷ１が動作する）ホスト１にパケットを転送する。つまり、Ｒｅｐｌｙ方向については、ｍａｒｋ値に応じて、パケット流入元のホスト１にパケットを転送する。
　Ｓ６において、ホスト１は、Ｓ３のマーク値に基づいてｒｅｐｌｙパケットを流入元のＧＷ１に転送する。なお、本例ではホスト１に複数ＧＷが存在するので、それらを識別するためにこの設定が必要となる。
　（入れ子構造について）
　本実施の形態のシステムはＶＭ／コンテナ入れ子構造でも実施することが可能である。ただし、入れ子構造では、インスタンス（コンテナ）の経路が、物理サーバセグメントで広告されていないため、ＩＰＩＰ等のトンネリングを用いて通信を実施する。
　ＶＭ／コンテナ入れ子構造を採用する構成例を図１５に示す。図１５に示すとおり、インスタンスを収容するＶＭ１，２でＳ１～Ｓ４の手順を行うことで通信を確立させる。物理サーバへの設定は不要である。具体的には下記のとおりである。
　Ｓ１において、ＶＭ１は、ＣＯＮＮＭＡＲＫによりフローにＧＷ番号でマークをつける。Ｓ２において、ＶＭ２は、ＣＯＮＮＭＡＲＫによりフローに流入元のホスト番号でマークをつける。Ｓ３において、ＶＭ２は、フローにマークされたホスト番号を見て対応するホストにＩＰＩＰでフローを転送する。Ｓ４において、ＶＭ１は、フローにマークされたＧＷ番号を見て対応するＧＷにフローを転送する。
　（配置決定方式の処理フロー）
　提案２の配置最適化（図９，図１０）について、図１６を参照して、システムに含まれる各ホストに対するＧＷ（インスタンスの例）の配置決定を行うための処理フローの例を説明する。配置決定処理は、後述する配置計算部３００が実行する。ただし、デプロイはインスタンス管理部２００が行う。ここでは、ホスト数、デプロイすべきＧＷ数が予め与えられているとする。
　Ｓ１０１～Ｓ１０６において、ＧＷを１つのホストに１つずつデプロイする。それでも全ＧＷをデプロイできない場合に、Ｓ１０７～Ｓ１１０において、ホストに追加のＧＷをデプロイする。Ｓ１０１～Ｓ１０６とＳ１０７～Ｓ１１０はいずれもホストについての繰り返しなので、ここでは、例として、「ホストＡ」を対象として各ステップを説明する。
　Ｓ１０１において、配置計算部３００はホストＡの状態を確認する。状態を確認するとは、配置決定に必要な情報を取得することである。Ｓ１０２において、配置計算部３００は、ホストＡのリソースの有無を確認し、ＧＷのデプロイのためのリソースが有る場合はＳ１０３に進み、無い場合はＳ１０６に進む。
　Ｓ１０３において、配置計算部３００は、ホストＡのＧＷ数を確認し、ＧＷが有る場合はＳ１０６に進み、無い場合はＳ１０４に進む。
　Ｓ１０４において、ホストＡに対してＧＷをデプロイする。Ｓ１０５～Ｓ１０６において、未デプロイＧＷが無ければ処理を終了し、未デプロイＧＷがあり、かつ、未確認ホストがあればＳ１０１に戻り、次のホストの処理を行う。
　未デプロイＧＷがあり、かつ、未確認ホストが無ければ、Ｓ１０７において、ホストＡの状態を確認し、Ｓ１０８においてホストＡのリソース確認を行う。リソースがあればＳ１０９においてホストＡにＧＷをデプロイする。リソースが無ければＳ１１０に進む。
　Ｓ１１０において、未デプロイＧＷ及び未確認ホストがあれば、別のホストについて、Ｓ１０８，Ｓ１０９の処理を行う。
　（設定自動化システムの処理フロー）
　提案３の設定自動化（図１１～図１３）の処理フローについて、図１７を参照して説明する。ここでの処理は、後述するインスタンス管理部２００、設定投入部４００等により行われる。
　Ｓ２０１において、インスタンス管理部２００は、リソースとして、ホスト数、インスタンス数を決定する。Ｓ２０２において、インスタンス管理部２００（あるいは配置計算部３００）は、インスタンスを配置する。ここでは、ホスト内のＧＷは極力、単一とするとともに、ホストあたりのアプリ数を均等にする。
　Ｓ２０３において、設定投入部４００は、ホスト管理部１００からの情報に基づいて、ホストの状態を判定し、Ａｐｐが動作している場合はＳ２０４に進み、ＧＷとＡＰＰが動作している場合はＳ２０５に進み、ＧＷのみが動作している場合はＳ２０６に進む。
　Ｓ２０４において、設定投入部４００は、図１２の設定投入を行い、Ｓ２０５において、図１３の設定投入を行う。
　Ｓ２０６において、ＧＷの数が１つであればＳ２０８に進む。ＧＷの数が複数であればＳ２０７において、図１１の設定投入を行う。Ｓ２０８において、インスタンス管理部２００は、使用リソース監視を行う。
　（システム全体構成）
　図１８に、本実施の形態におけるシステムの全体構成例を示す。図１８に示すように、本システムは、ＣＰＥ１０、ＧＷ解決部２０、ＧＷ１が動作するホスト１（ホストサーバ）、Ａｐｐ１が動作するホスト２、ホスト管理部１００、ＤＢ３０、インスタンス管理部２００、配置計算部３００、設定投入部４００を有する。
　図１８に示す各部は、単独の装置であってもよいし、複数の部位が１つの装置を構成してもよい。ＧＷ解決部２０、ホスト管理部１００、インスタンス管理部２００、配置計算部３００、設定投入部４００をそれぞれＧＷ解決装置２０、ホスト管理装置１００、インスタンス管理装置２００、配置計算装置３００、設定投入装置４００と呼んでもよい。各部（各装置）の概要は下記のとおりである。
　ＣＰＥ１０はクライアント端末（デバイス）を収容するＮＷ装置である。ＣＰＥ１０はＧＷ解決部２０に問い合わせることで接続先のＧＷを決定する。
　クラウド上の仮想基盤ではサービス向けのＮＷ機能として動作するインスタンスであるＧＷ１と、アプリケーションロジックを提供するＡｐｐ１が、それぞれホスト１、２上で動作する。
　ホスト管理部１００はこれらのホストのホスト名やネットワーク情報・リソース情報をＤＢ３０で管理する。配置計算部３００は、ホストの台数やリソース状況に基づき、インスタンスの配置先となるホストを決定する。
　インスタンス管理部２００は、配置計算部３００の決定に基づきインスタンスを配置し、インスタンスのＩＤやネットワーク情報・リソース情報を管理する。設定投入部４００は、インスタンスの配置状況に基づき各ホストにネットワーク設定を行う。
　以下では、各部の構成と動作をより詳細に説明する。なお、以下で説明する各部の構成と動作は一例である。これまでに説明した設定や動作を実現できるのであれば、装置（部位）の構成や動作はどのようなものであってもよい。
　（ホスト管理部１００）
　ホスト管理部１００は、ホスト名やネットワーク情報・リソース情報を各ホストから取得しＤＢで管理する。図１９に、ホスト管理部１００の構成を示す。図１９に示すように、ホスト管理部１００は、ホスト情報ＤＢ１１０、ホスト情報取得部１２０、配信ＡＰＩ機能部１３０を有する。
　ホスト情報取得部１２０は、ホストにアクセスして上述の情報を取得し、取得した情報をホスト情報ＤＢ１１０に格納する。ホスト情報ＤＢ１１０は、ＨｏｓｔのＩＤやＩＰアドレス／ｍａｃアドレス等のネットワーク情報、ホストリソースを管理する。
　外部の配置計算部３００、設定投入部４００は、配信ＡＰＩ機能部１３０経由でホスト情報ＤＢ１１０にアクセスし、ネットワーク情報やリソース利用率などの、処理に必要な情報を取得する。図２０に、ホスト情報ＤＢ１１０に格納される情報の例を示す。
　（インスタンス管理部２００）
　インスタンス管理部２００はインスタンスをデプロイする。また、インスタンス名やインスタンス種別・ネットワーク情報を取得しＤＢで管理する。図２１にインスタンス管理部２００の構成例を示す。
　図２１に示すように、インスタンス管理部２００は、インスタンス情報ＤＢ２１０、インスタンスデプロイ機能部２２０、インスタンス情報取得部２３０、配信ＡＰＩ機能部２４０を有する。
　インスタンスデプロイ機能部２２０は、配置計算部３０の指示に基づいてホストを選択してインスタンスをデプロイする。
　インスタンス情報取得部２３０は、インスタンスにアクセスして上述の情報を取得してインスタンス情報ＤＢ２１０に格納する。インスタンス情報Ｄ２１０Ｂは、インスタンスのＩＤやＩＰアドレス／ｍａｃアドレス等のネットワーク情報、ホストリソースを管理する。
　外部の配置計算部３００、設定投入部４００は、配信ＡＰＩ機能部２４０経由でインスタンス情報ＤＢ２１０にアクセスし、アプリ種別やネットワーク情報、動作しているホスト情報などの必要な情報を取得する。図２２に、インスタンス情報ＤＢ２１０に格納される情報の例を示す。
　（配置計算部３００）
　配置計算部３００は、インスタンスをデプロイするホストを決定する。図２３に、配置計算部３００の構成例を示す。図２３に示しように、配置計算部３００は、情報取得部３１０、配置決定部３２０、配置指示部３３０を有する。
　情報取得部３１０は、配信ＡＰＩ機能部経由でインスタンス管理部２００／ホスト管理部１００にアクセスし、ホストごとのリソース空き状況と既に動作しているＧＷインスタンスやＡＰＰインスタンスの数を取得する。
　配置決定部３２０は、ＧＷ配置決定処理の流れ（図１６）に沿ってＧＷインスタンスの配置先ホストを決定する。また、ＡＰＰインスタンスについては、ホストリソースが許容する限り、ホスト単位でＡＰＰの種類ごとのインスタンス数ができるだけ均等になるように、ＡＰＰインスタンスの配置先ホストを決定する。
　配置指示部３３０は、配置決定部３２０の計算結果に基づき、インスタンス管理部２００へ配置方法を指示する。
　（設定投入部４００）
　設定投入部４００は本実施の形態に係る技術で必要となるｃｏｎｎｍａｒｋやＰＢＲの設定をホストに対して行う。
　図２４に、設定投入部４００の構成例を示す。図２４に示すように、設定投入部４００は、ホストパラメータＤＢ４１０、インスタンスパラメータＤＢ４２０、テーブル管理ＤＢ４３０、情報取得部４４０、設定生成部４５０、設定投入処理部４６０を有する。
　情報取得部４４０は、配信ＡＰＩ機能部経由でインスタンス管理部２００／ホスト管理部１００にアクセスし、ホストごとのリソース空き状況と、動作しているＧＷインスタンスの数、ＡＰＰインスタンス、設定に必要なネットワーク情報を取得し、対応するＤＢに格納する。
　インスタンスパラメータＤＢ４２０は、インスタンスの動作状況やインターフェース名を管理する。ホストパラメータＤＢ４１０は、ホストの中のインスタンスの動作情報やアドレス情報を管理する。テーブル管理ＤＢ４３０は、ＰＢＲのためのテーブルがどのホストで動作しているかを管理する。
　設定生成部４５０は、各種ＤＢからの情報に基づいてホストごとのインスタンス数の状態判定を行い、ｃｏｎｎｍａｒｋ、ＰＢＲのための設定を生成する。
　設定の一例としては、（１）ＧＷのインターフェース名に基づいたｃｏｎｎｍａｒｋ、（２）ホストのｍａｃアドレスに基づいたｃｏｎｎｍａｒｋ、（３）各種ｍａｒｋ値に基づくポリシーベースルーティングを行うための設定、等が挙げられる。
　設定投入処理部４６０は、設定生成部４５０の計算結果に基づき、該当のホストに設定を行う。
　図２５に、テーブル管理ＤＢ４３０、インスタンスパラメータＤＢ４２０、ホストパラメータＤＢ４１０それぞれについて、格納される情報の例を示す。
　（シーケンス例１）
　サービス開始時のインスタンスの配置として、ホスト１，２にインスタンスを配置する場合のシーケンス例を図２６に示す。なお、ホスト１、２はそれぞれ、物理マシンでもよいし、仮想マシンでもよい。図２６に示すシーケンスは、サービス開始時のホストの起動、インスタンスの配置計算、インスタンスの起動、ホストへの設定投入の手順を示している。
　まず、Ｓ１～Ｓ４においてホスト管理部１００がサービスを構成する基盤の各ホストを起動し、起動した各ホストの情報を収集する。収集した情報は、例えば、図２０に示したようにホスト情報ＤＢ１１０に格納される。
　Ｓ５において、インスタンス管理部２００はホスト管理部１００からホスト情報を取得する。Ｓ６において、配置計算部３００は、ホスト管理部１００からインスタンス情報を取得する。
　Ｓ７において、インスタンス管理部２００から配置計算部３００に対し、インスタンスの配置を計算する要求を行う。Ｓ８において、配置計算部３００は、インスタンス及びホストの情報をもとに配置を決定し、Ｓ９において、インスタンス管理部２００に対して配置を指示する。
　この指示に基づいて、Ｓ１０～Ｓ１３において、インスタンス管理部２００は、ホストを選択してインスタンスを起動する。起動に伴って、インスタンス情報がインスタンス管理部２００に送信され、インスタンス情報ＤＢ（図２２）に格納される。
　設定投入部４００は、Ｓ１４においてホスト管理部１００からホスト情報を取得し、Ｓ１５において、インスタンス管理部２００からインスタンス情報を取得する。Ｓ１６において、設定投入部４００は、取得した情報を用いて、ｃｏｎｎｍａｒｋやＰＢＲといった必要なネットワーク設定を作成し、Ｓ１７～Ｓ１８において、各ホストに設定を投入する。
　（シーケンス例２）
　次に、本実施の形態において想定するパケットの転送手順として、ホスト１にＧＷ１が配置され、ホスト２にＡｐｐ１が配置されている場合における転送手順を、図２７を参照して説明する。
　デバイス５０が送信したパケットはＣＰＥ１０に到着し（Ｓ１）、ＧＷ解決部２０への問い合わせにより接続先のＧＷを解決（Ｓ２，Ｓ３）した上で、ＧＷ１が動作するホスト１まで転送される（Ｓ４）。
　ホスト１では、流入パケットをＧＷ１に転送する（Ｓ５）。Ｓ６において、ＧＷ１がこのパケットに必要なＮＷ処理を施した後、Ｓ７において、Ａｐｐ１へ通信するために再びホスト１に転送する。
　ホスト１は、Ｓ８において、ＧＷ１に対応するインターフェース名等でｃｏｎｎｍａｒｋを行う。ホスト１は、Ｓ９において、フロー識別のためのマークが付けられたパケットを、Ａｐｐ１に通信するために、ホスト２に送信する。
　Ｓ１０において、ホスト２は、当該パケットに対し、ｓｏｕｒｃｅ　ｍａｃアドレス（ここではホスト１のアドレス）をキーにしてｃｏｎｎｍａｒｋを行う。Ｓ１１～Ｓ１３において、Ａｐｐ１でパケットのＡｐｐ処理が行われる。
　Ｓ１４において、ホスト２は、Ｓ１０で付加したマーク値とｍａｃ　ａｄｄｒｅｓｓを対応させることで、Ａｐｐ１で処理後の返りパケットをｍａｒｋに基づいてＰＢＲする。これにより、パケットはホスト１に転送される（Ｓ１５）。同様に、Ｓ１６において、返りパケットを受信したホスト１では、ＧＷ１のインターフェース名に対応づけられたマーク値に従って、流入元のＧＷ１にパケットを戻すＰＢＲを行う。Ｓ１７～Ｓ１９において、ＮＷ処理がなされ、Ｓ２０において、ホスト１からデバイス５０にパケットが転送される。
　（ハードウェア構成例）
　ＧＷ解決部２０、ホスト管理部１００、インスタンス管理部２００、配置計算部３００、設定投入部４００、ＧＷ解決装置２０、ホスト管理装置１００、インスタンス管理装置２００、配置計算装置３００、設定投入装置４００、ホスト、ＧＷ、Ａｐｐはいずれも、例えば、コンピュータにプログラムを実行させることにより実現できる。このコンピュータは、物理的なコンピュータであってもよいし、クラウド上の仮想マシンであってもよい。以下、ＧＷ解決部２０、ホスト管理部１００、インスタンス管理部２００、配置計算部３００、設定投入部４００、ＧＷ解決装置２０、ホスト管理装置１００、インスタンス管理装置２００、配置計算装置３００、設定投入装置４００、ホスト、ＧＷ、Ａｐｐを総称して装置と呼ぶ。
　すなわち、当該装置は、コンピュータに内蔵されるＣＰＵやメモリ等のハードウェア資源を用いて、当該装置で実施される処理に対応するプログラムを実行することによって実現することが可能である。上記プログラムは、コンピュータが読み取り可能な記録媒体（可搬メモリ等）に記録して、保存したり、配布したりすることが可能である。また、上記プログラムをインターネットや電子メール等、ネットワークを通して提供することも可能である。
　図２８は、上記コンピュータのハードウェア構成例を示す図である。図２８のコンピュータは、それぞれバスＢＳで相互に接続されているドライブ装置１０００、補助記憶装置１００２、メモリ装置１００３、ＣＰＵ１００４、インターフェース装置１００５、表示装置１００６、入力装置１００７、出力装置１００８等を有する。
　当該コンピュータでの処理を実現するプログラムは、例えば、ＣＤ－ＲＯＭ又はメモリカード等の記録媒体１００１によって提供される。プログラムを記憶した記録媒体１００１がドライブ装置１０００にセットされると、プログラムが記録媒体１００１からドライブ装置１０００を介して補助記憶装置１００２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１００１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１００２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。
　メモリ装置１００３は、プログラムの起動指示があった場合に、補助記憶装置１００２からプログラムを読み出して格納する。ＣＰＵ１００４は、メモリ装置１００３に格納されたプログラムに従って、当該装置に係る機能を実現する。インターフェース装置１００５は、ネットワーク等に接続するためのインターフェースとして用いられる。表示装置１００６はプログラムによるＧＵＩ（Ｇｒａｐｈｉｃａｌ　Ｕｓｅｒ　Ｉｎｔｅｒｆａｃｅ）等を表示する。入力装置１００７はキーボード及びマウス、ボタン、又はタッチパネル等で構成され、様々な操作指示を入力させるために用いられる。出力装置１００８は演算結果を出力する。
　（実施の形態のまとめ、効果）
　以上説明したように、本実施の形態では、仮想化基盤環境で提供される、デバイスからサービスの方向で通信確立するサービスにおいて、ｃｏｎｎｔｒａｃｋに基づいたポリシーベースルーティングにより、返りパケットをゲートウェイインスタンスやその収容ホストへ段階的に戻すルーティング方式を提案した。
　より具体的には、ＧＷの動作ホストにおいてＧＷに対応するインターフェースをキーにしたｃｏｎｎｍａｒｋを行い、Ａｐｐの動作ホストにおいて送信元ｍａｃアドレスをキーにしたｃｏｎｎｍａｒｋを行うことで、戻りの通信に対しｍａｃアドレスに対応する流入元ホスト宛のＰＢＲと、インターフェースに対応する流入元ＧＷ宛のＰＢＲを行う。
　また、上記方式の実現に必要な設定の集約を可能にするインスタンス配置方式を提案した。更に、ストでのインスタンス収容状況に基づき、上記方式の実現に必要な設定を動的に行う設定自動化システムを提案した。
　本実施の形態により、アプリケーションが処理したパケットを適切なＧＷまで転送する技術において、端末のＧＷ再接続時にもセッションが切れず、大量の経路の学習も必要としないこととすることができる。
　また、本技術では、パケットヘッダの書き換えが不要なため，アプリケーション処理に影響を与えない。また、多数のＡＰＰインスタンス（エンドポイント）に設定を投入することなく、オーバーヘッドの削減が見込まれる。
　（付記）
　以上の実施形態に関し、更に以下の付記項を開示する。
（付記項１）
　デバイスから送信されたパケットに対してネットワーク処理を行うゲートウェイを備え、前記ゲートウェイから転送されたパケットに、転送元が前記ゲートウェイであることを示す第１のマークを付し、前記第１のマークを付したパケットを転送する第１のホストと、
　アプリケーションを備え、前記第１のホストから転送されたパケットを受信し、当該パケットに、転送元が前記第１のホストであることを示す第２のマークを付け、前記第２のマークを付したパケットを前記アプリケーションに転送し、前記アプリケーションから転送されたパケットを、前記第２のマークに基づいて、前記第１のホストに転送する第２のホストと、を備え、
　前記第１のホストは、前記第２のホストから受信したパケットを、前記第１のマークに基づいて、前記ゲートウェイに転送する
　通信システム。
（付記項２）
　前記第１のホストと前記第２のホストはそれぞれ、パケットへマークを付すためにｃｏｎｎｍａｒｋを使用し、マークの基づくパケットの転送のためにポリシーベースルーティングを使用する
　付記項１に記載の通信システム。
（付記項３）
　複数のホストを含む通信システムにおいてゲートウェイインスタンスをデプロイするホストを決定するための配置計算装置であって、
　メモリと、
　前記メモリに接続された少なくとも１つのプロセッサと、
　を含み、
　前記プロセッサは、
　各ホストのリソース情報及びデプロイされているゲートウェイインスタンス数を取得し、
　ホストにゲートウェイインスタンスをデプロイするためのリソースがある限り、各ホストに１つずつゲートウェイインスタンスをデプロイすることを決定し、デプロイすることが決定されていないゲートウェイインスタンスについて、ゲートウェイインスタンスがデプロイ済みのホストにデプロイすることを決定する
　配置計算装置。
（付記項４）
　アプリケーションインスタンスに関して、前記プロセッサは、インスタンス数ができるだけホスト間で均等になるように、各ホストへの配置を決定する
　付記項３に記載の配置計算装置。
（付記項５）
　複数のホストを含む通信システムにおいてホストに対する設定を投入する設定投入装置であって、
　メモリと、
　前記メモリに接続された少なくとも１つのプロセッサと、
　を含み、
　前記プロセッサは、
　インスタンスが配置された各ホストにおけるホスト情報とインスタンス情報を取得し、
　ゲートウェイインスタンスが複数個配置されたホストに対して、ゲートウェイインスタンス毎の流入フローに対するマーク処理のための設定と、ゲートウェイインスタンス毎の戻りフローに対するマークを用いたルーティングのための設定を生成し、アプリケーションインスタンスが配置されたホストに対して、流入フローに対するマーク処理のための設定と、戻りフローに対するマークを用いたルーティングのための設定を生成し、
　生成した設定を該当のホストに投入する
　設定投入装置。
（付記項６）
　ゲートウェイを備える第１のホストと、アプリケーションを備える第２のホストを含む通信システムにおける通信方法であって、
　前記第１のホストが、デバイスから送信されたパケットを前記ゲートウェイに転送し、前記ゲートウェイから転送されたパケットに、転送元が前記ゲートウェイであることを示す第１のマークを付し、前記第１のマークを付したパケットを前記第２のホストに転送し、
　前記第２のホストが、前記第１のホストから転送されたパケットを受信し、当該パケットに、転送元が前記第１のホストであることを示す第２のマークを付け、前記第２のマークを付したパケットを前記アプリケーションに転送し、前記アプリケーションから転送されたパケットを、前記第２のマークに基づいて、前記第１のホストに転送し、
　前記第１のホストは、前記第２のホストから受信したパケットを、前記第１のマークに基づいて、前記ゲートウェイに転送する
　通信方法。
（付記項７）
　コンピュータに、付記項３又は４に記載の配置計算装置における各処理を実行させるプログラムを記憶した非一時的記憶媒体。
（付記項８）
　コンピュータに、付記項５に記載の設定投入装置における各処理を実行させるプログラムを記憶した非一時的記憶媒体。
　以上、本実施の形態について説明したが、本発明はかかる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
１０　ＣＰＥ
２０　ＧＷ解決部
３０　ＤＢ
５０　デバイス
１００　ホスト管理部
１１０　ホスト情報ＤＢ
１２０　ホスト情報取得部
１３０　配信ＡＰＩ機能部
２００　インスタンス管理部
２１０　インスタンス情報ＤＢ
２２０　インスタンスデプロイ機能部
２３０　インスタンス情報取得部
２４０　配信ＡＰＩ機能部
３００　配置計算部
３１０　情報取得部
３２０　配置決定部
３３０　配置指示部
４００　設定投入部
４１０　ホストパラメータＤＢ
４２０　インスタンスパラメータＤＢ
４３０　テーブル管理ＤＢ
４４０　情報取得部
４５０　設定生成部
４６０　設定投入処理部
１０００　ドライブ装置
１００１　記録媒体
１００２　補助記憶装置
１００３　メモリ装置
１００４　ＣＰＵ
１００５　インターフェース装置
１００６　表示装置
１００７　入力装置
１００８　出力装置

Claims (8)

  1. 　デバイスから送信されたパケットに対してネットワーク処理を行うゲートウェイを備え、前記ゲートウェイから転送されたパケットに、転送元が前記ゲートウェイであることを示す第１のマークを付し、前記第１のマークを付したパケットを転送する第１のホストと、
    　アプリケーションを備え、前記第１のホストから転送されたパケットを受信し、当該パケットに、転送元が前記第１のホストであることを示す第２のマークを付け、前記第２のマークを付したパケットを前記アプリケーションに転送し、前記アプリケーションから転送されたパケットを、前記第２のマークに基づいて、前記第１のホストに転送する第２のホストと、を備え、
    　前記第１のホストは、前記第２のホストから受信したパケットを、前記第１のマークに基づいて、前記ゲートウェイに転送する
    　通信システム。
  2. 　前記第１のホストと前記第２のホストはそれぞれ、パケットへマークを付すためにｃｏｎｎｍａｒｋを使用し、マークの基づくパケットの転送のためにポリシーベースルーティングを使用する
    　請求項１に記載の通信システム。
  3. 　複数のホストを含む通信システムにおいてゲートウェイインスタンスをデプロイするホストを決定するための配置計算装置であって、
    　各ホストのリソース情報及びデプロイされているゲートウェイインスタンス数を取得する情報取得部と、
    　ホストにゲートウェイインスタンスをデプロイするためのリソースがある限り、各ホストに１つずつゲートウェイインスタンスをデプロイすることを決定し、デプロイすることが決定されていないゲートウェイインスタンスについて、ゲートウェイインスタンスがデプロイ済みのホストにデプロイすることを決定する配置決定部と
    　を備える配置計算装置。
  4. 　アプリケーションインスタンスに関して、前記配置決定部は、インスタンス数ができるだけホスト間で均等になるように、各ホストへの配置を決定する
    　請求項３に記載の配置計算装置。
  5. 　複数のホストを含む通信システムにおいてホストに対する設定を投入する設定投入装置であって、
    　インスタンスが配置された各ホストにおけるホスト情報とインスタンス情報を取得する情報取得部と、
    　ゲートウェイインスタンスが複数個配置されたホストに対して、ゲートウェイインスタンス毎の流入フローに対するマーク処理のための設定と、ゲートウェイインスタンス毎の戻りフローに対するマークを用いたルーティングのための設定を生成し、アプリケーションインスタンスが配置されたホストに対して、流入フローに対するマーク処理のための設定と、戻りフローに対するマークを用いたルーティングのための設定を生成する設定生成部と、
    　前記設定生成部により生成した設定を該当のホストに投入する設定投入部と
    　を備える設定投入装置。
  6. 　ゲートウェイを備える第１のホストと、アプリケーションを備える第２のホストを含む通信システムにおける通信方法であって、
    　前記第１のホストが、デバイスから送信されたパケットを前記ゲートウェイに転送し、前記ゲートウェイから転送されたパケットに、転送元が前記ゲートウェイであることを示す第１のマークを付し、前記第１のマークを付したパケットを前記第２のホストに転送し、
    　前記第２のホストが、前記第１のホストから転送されたパケットを受信し、当該パケットに、転送元が前記第１のホストであることを示す第２のマークを付け、前記第２のマークを付したパケットを前記アプリケーションに転送し、前記アプリケーションから転送されたパケットを、前記第２のマークに基づいて、前記第１のホストに転送し、
    　前記第１のホストは、前記第２のホストから受信したパケットを、前記第１のマークに基づいて、前記ゲートウェイに転送する
    　通信方法。
  7. 　コンピュータを、請求項３又は４に記載の配置計算装置における各部として機能させるためのプログラム。
  8. 　コンピュータを、請求項５に記載の設定投入装置における各部として機能させるためのプログラム。
PCT/JP2022/008933 2022-03-02 2022-03-02 通信システム、配置計算装置、設定投入装置、通信方法、及びプログラム WO2023166626A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/JP2022/008933 WO2023166626A1 (ja) 2022-03-02 2022-03-02 通信システム、配置計算装置、設定投入装置、通信方法、及びプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2022/008933 WO2023166626A1 (ja) 2022-03-02 2022-03-02 通信システム、配置計算装置、設定投入装置、通信方法、及びプログラム

Publications (1)

Publication Number Publication Date
WO2023166626A1 true WO2023166626A1 (ja) 2023-09-07

Family

ID=87883201

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2022/008933 WO2023166626A1 (ja) 2022-03-02 2022-03-02 通信システム、配置計算装置、設定投入装置、通信方法、及びプログラム

Country Status (1)

Country Link
WO (1) WO2023166626A1 (ja)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014511616A (ja) * 2011-02-23 2014-05-15 マカフィー， インコーポレイテッド 論理装置、処理方法及び処理装置
JP2014160451A (ja) * 2013-01-24 2014-09-04 Ricoh Co Ltd 情報処理システム及び情報処理方法
JP2015219873A (ja) * 2014-05-21 2015-12-07 コニカミノルタ株式会社 サーバ装置、ゲートウェイ装置、画像処理システム、サーバ装置の制御方法、ゲートウェイ装置の制御方法、サーバ装置の制御プログラム、及びゲートウェイ装置の制御プログラム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014511616A (ja) * 2011-02-23 2014-05-15 マカフィー， インコーポレイテッド 論理装置、処理方法及び処理装置
JP2014160451A (ja) * 2013-01-24 2014-09-04 Ricoh Co Ltd 情報処理システム及び情報処理方法
JP2015219873A (ja) * 2014-05-21 2015-12-07 コニカミノルタ株式会社 サーバ装置、ゲートウェイ装置、画像処理システム、サーバ装置の制御方法、ゲートウェイ装置の制御方法、サーバ装置の制御プログラム、及びゲートウェイ装置の制御プログラム

Similar Documents

Publication Publication Date Title
CN112470436B (zh) 用于提供多云连通性的系统、方法、以及计算机可读介质
EP3466037B1 (en) Subnet stretching via layer three communications
US20220377045A1 (en) Network virtualization of containers in computing systems
US11502920B1 (en) Multi-carrier access to provider substrate extensions
US11848800B2 (en) Connecting virtual computer networks with overlapping IP addresses using transit virtual computer network
US9274825B2 (en) Virtualization gateway between virtualized and non-virtualized networks
CN108347493B (zh) 混合云管理方法、装置和计算设备
WO2017113231A1 (zh) 一种报文传输的方法、装置和系统
US11159344B1 (en) Connectivity of cloud edge locations to communications service provider networks
US11470047B1 (en) Managed virtual networks for computing cloud edge locations
US11625280B2 (en) Cloud-native proxy gateway to cloud resources
JP6076275B2 (ja) 通信ネットワークの経路制御連携システム及び方法
CN108737271B (zh) 一种报文路由方法、装置及系统
EP1932320A1 (en) Method, apparatus and system for maintaining mobility resistant ip tunnels using a mobile router
US10917460B2 (en) Distributed load-balancing for software defined networks
WO2016169218A1 (zh) 一种网关虚拟化方法、系统及计算机存储介质
CN112583618B (zh) 为业务提供网络服务的方法、装置和计算设备
US11070475B2 (en) Transparent migration of virtual network functions
CN105556929A (zh) 在云计算系统中运行应用的网络元件和方法
US20220166715A1 (en) Communication system and communication method
Lin et al. On exploiting SDN to facilitate IPv4/IPv6 coexistence and transition
WO2023166626A1 (ja) 通信システム、配置計算装置、設定投入装置、通信方法、及びプログラム
US11595347B1 (en) Dual-stack network addressing in cloud provider network edge locations
Johansson et al. Supporting user mobility with peer-to-peer-based application mobility in heterogeneous networks
CN114268604B (zh) 访问服务的提供方法和系统

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22929772

Country of ref document: EP

Kind code of ref document: A1