Gateway apparatus, communication system, communication method, and program

Abstract

Provided is a gateway apparatus that routes a packet received from a terminal to one of a plurality of upstream lines, the gateway apparatus comprising: a policy acquisition unit that uses flow information about the packet as a basis for acquiring, from a control apparatus, a policy regarding the upstream line to use; and a communication unit that determines a specific upstream line to use for transmission of the packet on the basis of the policy, and sends the packet to the specific upstream line.

Description

Gateway device, communication system, communication method, and program

[0001] The present invention relates to communication technology, and more particularly to technology for controlling communication paths of packets involved in communication between terminals in a function or device that exists between terminals that communicate.

[0002] Non-Patent Documents 1 and 2 and Patent Document 1 disclose conventional technologies related to terminal-to-terminal communication via SRv6 VPN between VPN-GWs that connect multiple sites. SRv6 is segment routing that uses IPv6 extension headers.

[0003] In particular, Non-Patent Document 1 (a standard document (RFC) related to Segment Routing in the standardization organization IETF) and Non-Patent Document 2 (an SRv6-related RFC in the same organization) disclose encapsulation technology in VPN-GW by encapsulating and decapsulating SRH (Segment Routing Header).

[0004] Furthermore, Patent Document 1 discloses a technology in which a controller (referred to as a global controller in this specification) is deployed, and when a call is made from a terminal, the VPN-GW acquires from the global controller the global IP address (hereinafter referred to as RLOC) of the VPN-GW that corresponds to the IP address (hereinafter referred to as EID) of the destination terminal, and stores the relationship between this EID and RLOC in a database and a forwarding table within the VPN-GW.

[0005] IETF RFC 8402, Segment Routing ArchitectureIETF RFC 8986, Segment Routing over IPv6(SRv6) Network programming

[0006] Patent No. 7215597

[0007] However, in the prior art, even if a VPN-GW has multiple upstream lines (lines between VPN-GWs), no method is disclosed for selecting which of the multiple upstream lines to use for communication, which poses a problem in that the VPN-GW cannot allocate communications from a terminal to the appropriate upstream line.

[0008] The present invention has been made in view of the above points, and has an object to provide a technique that enables a gateway device to distribute communications from a terminal to a desired upstream line.

[0009] According to the disclosed technology, there is provided a gateway device that distributes packets received from a terminal to one of a plurality of upstream lines, the gateway device comprising: a policy acquisition unit that acquires a policy for the upstream line to be used from a control device based on flow information of the packets; and a communication unit that determines a specific upstream line to be used for transmitting the packets based on the policy, and sends the packets to the specific upstream line.

[0010] According to the disclosed technology, it becomes possible for a gateway device to distribute communications from a terminal to a desired upstream line.

[0011] It is a diagram for explaining the configuration and operation of a communication system. It is a diagram showing an example of the functional configuration of a device side GW apparatus 100. It is a diagram showing an example of the functional configuration of a control apparatus 400. It is a diagram showing an example of the functional configuration of a flow management apparatus 500. It is a diagram showing an example of the hardware configuration of an apparatus.

[0012] Hereinafter, an embodiment of the present invention will be described with reference to the drawings. The embodiment described below is merely an example, and the embodiment to which the present invention is applied is not limited to the following embodiment.

[0013] In the following, first, the conventional technology and its problems will be described in detail, and then the technology according to the present embodiment will be described in detail. Note that, regarding the conventional technology, the technologies themselves disclosed in Non-Patent Documents 1 and 2 and Patent Document 1 are publicly known, but the explanation of the conventional technology and the explanation of the problems below are not publicly known.

[0014] (Regarding the Prior Art) The prior art shows a mechanism in which a global controller is deployed that maintains the relationship between the RLOC of the VPN-GW (referred to as CPE in Patent Document 1) and the EID of a terminal under the VPN-GW, so that every time a call is made between terminals, the traffic is encapsulated using the VPN-GW and the encapsulated packet is sent out.

[0015] By utilizing the above mechanism, the communicating terminal stores the EID of the opposite terminal in the destination field of the IP header and sends the packet to the VPN-GW, making it possible to send packets to the opposite terminal without being aware of the existence of the SRv6 VPN.

[0016] (Regarding the Issues) Possible communication paths between VPN-GWs include LANs and WANs. These LANs and WANs can be wireless or wired. These communication paths have a wide range of characteristics, such as installation costs, usage costs, quality, and robustness against congestion. In this specification, the communication path between VPN-GWs will hereafter be referred to as a "WAN" as an example.

[0017] In communications that require high reliability, low latency, and low cost, such as remote vehicle driving, it is desirable to deploy multiple lines between the VPN and GW and switch lines depending on the communication quality, latency, and effective throughput, which change depending on the communication, as well as the required cost.

[0018] However, in the method described in Patent Document 1, the global controller notifies the VPN-GW of only the RLOC of the opposing VPN-GW, so even if the VPN-GW is connected to multiple upstream lines, that is, even if the VPN-GW is equipped with multiple WAN I / Fs (for example, network interface devices for WAN connections), it is not possible to allocate communications to any one of the WAN I / Fs.

[0019] Furthermore, Non-Patent Document 1 describes a method for SRv6-based communications in which a desired communication path is encapsulated using SRv6 using "SID (Segment ID)," which represents node addresses on the path. Using this method, a method can be considered in which the next-hop gateway addresses of multiple upstream lines provided in a VPN-GW are embedded as SIDs. However, in this case, the IP addresses, which are network configuration information for upstream lines that may belong to other operators, must be known, which requires the effort of disclosing information between operators. Furthermore, disclosure of this information can pose security problems. Furthermore, the global controller must retain next-hop information for all VPN-GWs, which poses the problem of a huge amount of management data.

[0020] Another possible allocation method other than using SIDs is to store the WAN I / F used to send SRv6 packets to RLOCs in the VPN-GW routing table. However, this requires updating the routing table every time the I / F policy is changed, which increases the processing load.

[0021] Furthermore, in the method described in Patent Literature 1, when a traffic flow occurs, the RLOC for that traffic flow is resolved, so RLOC resolution is required each time a different flow, especially a flow with a different destination, occurs, which increases the communication load and the load on the global controller.

[0022] (Outline of the embodiment) The outline of the technology for solving the above problems is as follows.

[0023] The VPN-GW is equipped with an SRv6 encapsulation function that corresponds to multiple upstream lines. A local controller is provided, and the local controller instructs the VPN-GW which SRv6 encapsulation function to use for SRv6 encapsulation (i.e., which WAN I / F to use), making it possible to properly use multiple upstream lines even when network information on the communication route is not known.

[0024] Furthermore, when a global controller notifies a VPN-GW of an RLOC for a traffic flow, it is possible to reduce the load on the global controller, which has been a problem in the past, by predicting flows that are expected to occur in the near future and setting policies for those flows at the same time.In addition, when a local controller notifies a VPN-GW of the interface to be used, it is also possible to further reduce the load on the global controller by setting policies based on similar predictions.

[0025] (System Configuration Example) Fig. 1 shows an example of the configuration of a communication system in this embodiment. Fig. 1 also shows step numbers indicating the operation procedure. In this embodiment, each connected site is called a "device" and an "edge," but this is merely an example. Also, the following explanation is based on the concept of LISP (Locater Identity Separation Protocol), as an example.

[0026] In this embodiment, it is assumed that communication takes place between a terminal 10 and a terminal 20 via an SRv6 VPN-GW that connects a plurality of sites.

[0027] A VPN-GW is deployed on both the device side and the edge side. The VPN-GW on the device side is called a device-side GW apparatus 100, and the VPN-GW on the edge side is called an edge-side GW apparatus 200.

[0028] The device-side GW device 100 and the edge-side GW device 200 are each provided with an upstream (hereinafter referred to as WAN) interface and a downstream (hereinafter referred to as LAN) interface.

[0029] As shown in Fig. 1, in this embodiment, two VPN-GWs are provided, the device-side GW device 100 is provided with two upstream WAN lines, and the edge-side GW device 200 is provided with one upstream WAN line. However, this is just an example, and the number of VPN-GWs is not limited to two and may be three or more. Furthermore, the number of upstream WAN lines in each case is not limited to two in the device-side GW and one in the edge-side GW as shown in the example, and may be any other number.

[0030] However, it is preferable that the device-side GW device 100 has multiple upstream lines. In other words, it is preferable that multiple communication paths are available. The edge-side GW device 200 may have a single or multiple upstream lines.

[0031] The device-side GW device 100 and the edge-side GW device 200 each have a routing table and a routing function. The number of pairs of these routing tables and routing functions may be one or more. In Fig. 1, a routing table 101 and a routing table 102 are shown in the device-side GW device 100, and a routing table 201 is shown in the edge-side GW device 200.

[0032] When multiple "routing tables and routing functions" are provided, the "routing tables and routing functions" may be divided, for example, by VRF (Virtual Routing and Forwarding). In this embodiment, it is assumed that VRF is used, but this is not limitative.

[0033] The device-side GW device 100 and the edge-side GW device 200 each have a policy information storage function required for packet transfer between each site. Specifically, the policy information storage function stores the encap / decap rules for communication between each terminal. However, for example, in cases where either or both of the encap and decap rules are self-evident, the rules may not be stored, and only the encap or decap rules may be stored, or no rules may be stored in the policy information storage function. The device-side GW device 100 also has a used WAN I / F policy storage unit 103.

[0034] 1, a global controller 300 is provided to control the device-side GW device 100 and the edge-side GW device 200. Communication between the device-side GW device 100 and the edge-side GW device 200 and the global controller 300 is possible via a control line or the like. In this embodiment, the global controller 300 is described as an independent device, but the global controller 300 may be built into each VPN-GW or a specific VPN-GW.

[0035] The global controller 300 holds in advance information indicating the relationship between an identifier indicating each terminal (EID: the terminal's in-site IP address, etc.) and an identifier indicating the VPN-GW that accommodates the terminal (RLOC: the GW's global IP address, etc.). In other words, the global controller 300 holds an identifier indicating each terminal (EID: the terminal's in-site IP address, etc.) and an identifier indicating the VPN-GW that accommodates the terminal (RLOC: the GW's global IP address, etc.) in association with each other.

[0036] Also provided is a local controller 400 for controlling the VPN-GW (the device-side GW apparatus 100 in the example of FIG. 1). Communication between the device-side GW apparatus 100 and the local controller 400 is possible via a control line or the like.

[0037] In this embodiment, it is assumed that the local controller 400 is an independent device that has a one-to-one correspondence with each VPN-GW. However, this is not a limitation. The local controller 400 may be built into each VPN-GW, a specific VPN-GW, or the global controller 300.

[0038] Furthermore, when the local controller 400 is deployed as an independent device, the local controller 400 may be provided in a one-to-one correspondence with each VPN-GW, or one or more local controllers 400 may be provided in a non-one-to-one correspondence with one or more VPN-GWs.

[0039] The local controller 400 has a function of specifying the network interface to be used for sending a specific traffic flow passing through the VPN-GW to an upstream NW, based on information stored in the local controller 400 or control from an operator (human or automatic system). The local controller 400 may also be called a control device.

[0040] Furthermore, as shown in FIG. 1 , a flow management device 500 (which may also be called an APL flow DB) is provided to manage flow information sent and received by the VPN-GW (in the example of FIG. 1 , the device-side GW device 100). Communication between the flow management device 500 and the device-side GW device 100 is possible via a control line or the like. However, this is not a limitation. The flow management device 500 may be built into each VPN-GW, a specific VPN-GW, the global controller 300, or the local controller 400.

[0041] A network segment is configured under the LAN-side interface of the device-side GW device 100 and under the LAN-side interface of the edge-side GW device 200. The number of network segments may be one or more. Terminals are deployed within each network segment.

[0042] Examples of the terminal 10 under the control of the device-side GW device 100 include a mobile phone, a computer device such as a PC that is operated by a human, or a computer device that operates automatically without human operation, or an automatic vehicle driving control device.

[0043] Examples of the terminal 20 under the edge-side GW device 200 include appliance devices such as application servers, as well as instances in a computing virtualization infrastructure such as VMs and containers.

[0044] (Operation of the communication system) The operation procedure of the communication system in this embodiment will be described in accordance with the step numbers (S1, etc.) shown in Fig. 1. Note that in Fig. 1, the step numbers for the devices are assigned to the devices for processing within the devices.

[0045] <S1> In S1, the device-side terminal 10 writes the IPv6 address, which is the identifier of the opposite terminal 20, into the destination field in the packet header, and sends the IP packet to the device GW apparatus 100.

[0046] <S2> In S2, the device-side GW device 100 refers to its own policy information storage function (which may be called a policy management table) and confirms that a policy (EID / RLOC relationship) related to the packet does not exist. If it confirms that the policy exists, the process jumps to S8.

[0047] <S3> In S3, the device-side GW apparatus 100 queries the global controller 300 for the RLOC using the destination EID written in the destination field of the IP packet as a key.

[0048] <S4> In S4, the global controller 300 returns the EID / RLOC relationship (encap policy) that it holds to the device-side GW apparatus 100. That is, it returns the RLOC that corresponds to the destination EID to the device-side GW apparatus 100.

[0049] <S5> In S5, the global controller 300 notifies the edge-side GW device 200 of the relationship (decap policy) between the EID of the device-side terminal 10 and the RLOC of the device-side GW device 100. However, if the decap policy is self-evident, notification of this decap policy may be omitted.

[0050] <S6> After S4 is completed, in S6, the device-side GW apparatus 100 enters the encap setting (encap policy) of the packet into its own policy management table.

[0051] <S7> After completion of S5, in S7, the edge-side GW device 200 enters the packet decap setting (decap policy) into its own policy management table. However, if it can be determined that the policy notified in S5 is self-evident, entering this decap policy may be omitted.

[0052] <S8> After S6 is completed, in S8, the device-side GW device 100 refers to its own WAN I / F usage policy storage unit 103 (which may also be called a usage WAN I / F management table) and confirms that a usage WAN I / F policy related to the packet flow does not exist. On the other hand, if a usage WAN I / F policy related to the packet flow exists, the process may jump to S12.

[0053] <S9> In S9, the device-side GW apparatus 100 queries the local controller 400 about the WAN I / F to be used, using the 5-tuple information of the packet flow as a key.

[0054] <S10> In S10, the local controller 400 refers to the relationship between the flow information and the WAN I / F to be used that has been preset in itself (e.g., information associating the flow information with the WAN I / F to be used), and returns the WAN I / F to be used policy to the device GW apparatus 100.

[0055] In S11, the device-side GW device 100 sets a usage WAN I / F policy for itself. That is, the usage WAN I / F policy for the packet flow (the packet flow of S1) is stored in the usage WAN I / F policy storage unit 103.

[0056] <S12> In S12, the device-side GW device 100 refers to the WAN I / F policy to be used and determines the routing function to be used in the routing process of the packet that arrived in S1. In other words, the device-side GW device 100 determines the WAN I / F to be used to send the packet.

[0057] <S13> In S13, the routing function refers to the routing table, encaps the packet, and sends it to the upstream WAN line from the WAN I / F determined in S12.

[0058] <S14> In S14, the edge-side GW device 200 decaps the arrived packet, references the destination field in the packet header of the decapsulated packet, and transmits the packet to the terminal 20 corresponding to the destination field.

[0059] <S15> In S15, following S13, the device-side GW apparatus 100 transmits, to the flow management apparatus 500, 5-tuple information related to the packet received in S1.

[0060] <S16> In S16, the flow management device 500 refers to the information registered therein, and returns to the device-side GW device 100 a list of flow information that has been set as being related to the above flow.

[0061] <S17> In S17, the device-side GW apparatus 100 performs S2 to S11 and S15 to S16 for each piece of flow information included in the notified list of flow information. If necessary, the process is repeated recursively.

[0062] That is, the device-side GW apparatus 100 queries the global controller 300 / local controller 400 about the EID / RLOC correspondence / upstream line transmission policy related to the flow information of the S1 packet, and completes policy setting in advance for flows that are expected to occur in the future.

[0063] <Key Points> The flow of a series of processes relating to packet communication path allocation processing has been described above, but the key points of the processing can be summarized as follows, although the following is not limited to the above.

[0064] A) Each VPN-GW has multiple "routing tables and routing functions" using technologies such as VRF.

[0065] B) Each VPN-GW can input encap settings into one or more routing tables (or policy management tables) based on the EID / RLOC correspondence notified by the global controller 300.

[0066] C) The local controller 400 sets a policy to the VPN-GW (the device-side GW device 100 in the example of FIG. 1) indicating from which upstream line a specific traffic flow (identified by a 5-tuple) should be sent.

[0067] D) After establishing communication, the VPN-GW (the device-side GW apparatus 100 in the example of FIG. 1) notifies the flow management apparatus 500 of the flow information (5-tuple), and the flow management apparatus 500 notifies the VPN-GW of flow information (5-tuple) expected in the near future. The VPN-GW queries the global controller 300 / local controller 400 about the EID / RLOC correspondence and upstream line transmission policy related to the above flow information, and completes policy setting in advance for flows expected to occur in the future.

[0068] <Other Examples> In the above explanation, the terminals 10 and 20 are each identified by an IPv6 address, but the identifiers assigned to the terminals 10 and 20 may be something other than an IPv6 address. For example, the terminals may be identified from each other by their IPv4 addresses, and the IPv6 SRH may be assigned after protocol conversion using an IPv4-IPv6 conversion function in the VPN-GW.

[0069] The timing and communication format for the inquiry about the WAN I / F policy to be used and the policy setting described in S8 to S11 above are not limited to those described above. For example, they may be performed periodically, or only once at system startup, rather than after completion of S6. They may also be performed in response to an instruction from the global controller 300 to the device-side GW device 100. Regarding the communication format, push-type control from the local controller 400 or the global controller 300 may also be used, instead of an inquiry-and-response format.

[0070] In determining the routing function according to the WAN I / F policy in use and referencing the routing table in S12 and S13, it is possible to utilize, for example, a policy-based routing function in Linux (registered trademark) implementation.

[0071] Furthermore, in the above S12 and S13, as mentioned above, it is assumed that the operation is performed on the premise that multiple "routing tables and routing functions" are installed in the VPN-GW. If there is only one "routing table and routing function," this routing function performs routing operations between the LAN, the first WAN, and the second WAN. In other words, the following steps 1 and 2 are performed.

[0072] Step 1: The device-side GW apparatus 100 writes the routing setting according to the WAN I / F policy in use into its own single routing table.

[0073] Step 2: The device-side GW apparatus 100 refers to the routing table and performs routing processing.

[0074] After S14 above, when a new packet arrives at the device-side GW device 100, as in S1, the device may again perform an RLOC inquiry as shown in sequences S2 to S7 and set a policy for itself regarding the WAN I / F to be used as shown in sequences S8 to S11, or it may use policy information already cached in the device-side GW device 100.

[0075] If it is confirmed in S2 above that a policy related to the packet exists, the process may jump to sequence S8. This is because if an encap setting is entered in the device-side GW device 100, it is naturally assumed that a decap setting is entered in the edge-side GW device 200. However, in order to eliminate the possibility of malfunction of each GW device, S3 to S7 may be executed even if the existence of a policy is confirmed in S2.

[0076] In the above S8 to S11, the WAN I / F to be used is determined by inquiring when a traffic flow occurs. However, for example, when the information held by the local controller 400 is updated, a policy may be set by a push notification from the local controller 400 to the device-side GW device 100, or sequences S8 to S11 may be performed when a push notification from the local controller 400 to the device-side GW device 100 is received.

[0077] (Supplementary Notes on S15 and S16) We will provide additional information on S15 and S16 described above. S15 and S16 represent the process of querying flow information related to the flow generated in S1 and responding with that information. This process will be explained in more detail below.

[0078] In this embodiment, it is assumed that the flow management device 500 holds the related flow information by some method. For example, the related flow information may be manually set in the flow management device 500. Alternatively, the following variations 1 and 2 may be performed.

[0079] In variation 1, the flow management device 500 estimates a flow that the device-side terminal 10 is likely to call in the near future based on the behavior of other terminals. In variation 2, the flow management device 500 estimates a flow that the device-side terminal 10 is likely to call in the near future based on the specifications of the service being used. Each of these will be described in detail below.

[0080] <Variation 1> Premise of Variation 1: In a communication system, there are multiple device-side terminals. These multiple device-side terminals may be under the control of a single device-side GW apparatus 100, or may be distributed and deployed under the control of multiple device-side GW apparatuses 100.

[0081] Operation of Variation 1: When a flow is called in S1, the flow management device 500 stores the information of the flow in its own memory in association with the device ID (for example, IP address) for all device-side terminals.

[0082] By accumulating the above data over time, the flow management device 500 can extract a list of flows that a certain device ID has called within a certain period of time (for example, 10 minutes) in the past.

[0083] In S16, the flow management device 500 extracts all device IDs in which the flow information notified in S15 is registered. Furthermore, it acquires a list of flow information stored in association with the extracted device IDs, i.e., flow information used for other communications by communication terminals that communicate using the same type of flow as the flow information notified in S15. The entire list is sent as a response.

[0084] At this time, in order to narrow down the list of flow information, for example, only flow information that has a record of being called from at least two or more device-side terminals may be adopted.

[0085] In case the IP address of the terminal that sends the packets is different for each terminal, or the source port used for sending the packets is an ephemeral port and is undefined and different for each communication, the storage and extraction of the flow information is not limited to 5-tuple, but only a part of the information may be used. Also, by using a DPI (Deep Packet Inspection) device, header information of the application layer that is not limited to 5-tuple may be used.

[0086] <Variation 2> Assumption of Variation 2: The flow management device 500 stores the correlation between multiple application server instances that serve as edge terminals for implementing application services provided by this communication system. For example, it manages the combinations of IP addresses and port numbers of multiple server instances used to provide the application services.

[0087] Operation of Variation 2: In S16, the flow management device 500 extracts the application service that includes the flow information notified in S15 or part of the information (destination port, destination IP address, etc.).

[0088] Next, the IP address and port number of one or more server instances used to provide the application service are constructed as flow information to be returned to the VPN-GW, that is, flow information that is recognized as being related to the implementation of a certain application service with respect to the flow information notified in S15, and sent to the VPN-GW that made the inquiry.

[0089] (Device Configuration Example) Fig. 2 shows an example of the functional configuration of the device-side GW device 100. Fig. 2 shows the configuration of the device-side GW device 100, but the edge-side GW device 200 may also include the same configuration as the device-side GW device 100.

[0090] The device-side GW device 100 is a device that distributes packets received from a terminal to one of multiple upstream lines, and includes a policy acquisition unit 110, a communication unit 120, a related flow information acquisition unit 130, a setting unit 140, and a data storage unit 150.

[0091] The policy acquisition unit 110 acquires a policy for the upstream line to be used from a control device (e.g., local controller 400) based on the flow information of the received packet. The communication unit 120 determines a specific upstream line to be used for transmitting the packet based on the acquired policy, and sends the packet to the specific upstream line.

[0092] The communication unit 120 may send the packet using a routing function corresponding to the specific upstream line among multiple routing functions divided by VRF. Note that the communication unit 120 may be configured such that a functional unit that actually performs routing processing and a functional unit that determines the WAN I / F to be used are separated.

[0093] The associated flow information acquisition unit 130 acquires associated flow information, which is flow information related to the flow information of the received packet, from the flow management device based on the flow information of the packet. The setting unit 140 can set a policy in advance based on the associated flow information. The data storage unit 150 stores the pre-setting information, the policy information acquired from the control device, the associated flow information, etc.

[0094] 3 shows an example of the functional configuration of a control device 400 corresponding to the local controller 400. As shown in Fig. 3, the control device 400 includes a communication unit 410, an inquiry processing unit 420, and a data storage unit 430. The data storage unit 430 stores the relationship between flow information and the upstream line to be used.

[0095] The communication unit 410 communicates with a VPN-GW such as the device-side GW apparatus 100. In response to an inquiry based on flow information from the VPN-GW, the inquiry processing unit 420 acquires information on the upstream line corresponding to the flow information from the data storage unit 430 and returns the information to the source of the inquiry via the communication unit 420.

[0096] Fig. 4 shows an example of the functional configuration of the flow management device 500. As shown in Fig. 4, the flow management device 500 includes a communication unit 510, a related flow information providing unit 520, and a data storage unit 530. The data storage unit 530 stores related flow information or information required to extract related flow information (e.g., flow information stored in association with a device ID, server instance information).

[0097] The communication unit 510 communicates with a VPN-GW such as the device-side GW apparatus 100. In response to a request based on flow information from the VPN-GW, the associated flow information providing unit 520 may extract a device ID in which the flow information of the packet is registered and provide a list of flow information stored in association with the extracted device ID as the associated flow information, or may extract an application service associated with the flow information of the packet and provide information on a server instance used to provide the application service as the associated flow information.

[0098] (Hardware Configuration Example) Any of the devices described in this embodiment (VPN-GW, control device, gateway device, flow management device, etc.) can be realized by, for example, having a computer execute a program. This computer may be a physical computer or a virtual machine on a cloud.

[0099] That is, 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 a computer. The program can be recorded on a computer-readable recording medium (such as a portable memory) and stored or distributed. The program can also be provided via a network such as the Internet or email.

[0100] Fig. 5 is a diagram showing an example of the hardware configuration of the computer. The computer in Fig. 5 includes 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, and the like, all of which are interconnected via a bus B. The computer may further include a GPU.

[0101] The program that realizes the processing on the computer is provided by a recording medium 1001, such as a CD-ROM or a memory card. When the recording medium 1001 storing the program is set in the drive device 1000, the program is installed from the recording medium 1001 to the auxiliary storage device 1002 via the drive device 1000. However, the program does not necessarily have to be installed from the recording medium 1001, but may be downloaded from another computer via a network. The auxiliary storage device 1002 stores the installed program as well as necessary files, data, etc.

[0102] The memory device 1003 reads and stores a program from the auxiliary storage device 1002 when an instruction to start the program is received. The CPU 1004 realizes functions related to the device in accordance with the program stored in the memory device 1003. The interface device 1005 is used as an interface for connecting to a network, etc. The display device 1006 displays a GUI (Graphical User Interface) or the like according to the program. The input device 1007 is composed of a keyboard, mouse, buttons, a touch panel, etc., and is used to input various operation instructions. The output device 1008 outputs the results of calculations.

[0103] (Summary, Effects, etc. of the Embodiment) As explained above, the specific technology explained in this embodiment uses "a technology that utilizes SRv6 to (1) perform ID / Locator separation and (2) selectively use a desired route by Segment Routing," "a technology that retrieves an RLOC when a terminal makes a call under control from an SRv6 controller (global controller 300)," "a technology that can select an upstream line of a VPN-GW under control from an external function (local controller 400) even when the route information by the above-mentioned Segment Routing is limited (only the destination as an RLOC is known)," "division of the routing function using VRF when performing SRv6 encap / decap in a VPN-GW," and "a technology that, when a policy is set for a certain flow, estimates other flows that are expected to occur and sets policies 'together'."

[0104] The following effects can be obtained by combining all or some of the above techniques.

[0105] In the technology according to this embodiment, compared to the conventional technology, traffic flows can be distributed according to the quality and status of the multiple WAN lines that accommodate the VPN-GW by controlling the VPN-GW from an external function (local controller 400). This distributes line usage, improving communication bandwidth usage. Furthermore, highly stable communication can be achieved by sending important traffic to a highly reliable WAN line according to the importance of the traffic flow.

[0106] Furthermore, in this VPN-GW control method, by providing a function for specifying the WAN I / F to be used by the VPN-GW as a function independent of the EID / RLOC relationship notification from the global controller 300, traffic flow allocation can be realized without necessarily specifying the identifier of a node located upstream in the WAN to be used as the SID in the EID / RLOC relationship notification, i.e., encap setting notification. This makes it possible to reduce the amount of control information held by the global controller 300 and circulated through the system.

[0107] Furthermore, by dividing the "routing function / routing table" in the VPN-GW for each WAN in use, it is possible to separate the function that actually performs routing processing from the function that determines the WAN I / F to be used. This avoids the need to frequently rewrite data in the routing processing function in situations where the WAN I / F policy to be used changes frequently, and reduces the processing load on the system.

[0108] Furthermore, one of the effects of deploying the local controller 400 and the global controller 300 as separate functions is the distribution of data volume and processing volume. Since it is expected that the WAN I / F used for traffic flow managed by the local controller 400 will change relatively frequently depending on the communication path conditions and the preferences of users and service providers, compared to the EID / RLOC relationships of terminals managed by the global controller 300, the system configuration in which the local controllers 400 can be distributed achieves the effect of stabilizing the system.

[0109] On the other hand, following the policy setting process that is performed when a packet arrives at the VPN-GW, policy inquiries and policy settings can be performed in advance all at once for traffic flows that are expected to occur in the near future, thereby reducing the communication and processing load on the control system.

[0110] The following additional notes are provided regarding the above-described embodiments.

[0111] <Additional Notes> (Additional Item 1) A gateway device that distributes packets received from a terminal to one of a plurality of upstream lines, comprising: a memory; and at least one processor connected to the memory, wherein the processor: acquires a policy for the upstream line to be used from a control device based on flow information of the packet; determines a specific upstream line to be used for transmitting the packet based on the policy; and sends the packet to the specific upstream line. (Additional Item 2) The gateway device according to Additional Item 1, wherein the processor sends the packet using a routing function corresponding to the specific upstream line out of a plurality of routing functions divided by VRF. (Additional Item 3) The gateway device according to Additional Item 1 or 2, wherein the processor: acquires related flow information, which is flow information related to the flow information of the packet, from a flow management device based on the flow information of the packet; and sets a policy in advance based on the related flow information. (Supplementary Item 4) A communication system comprising: the gateway device according to any one of Supplementary Item 1 to 3; and the control device that maintains a relationship between flow information and an upstream line to be used. (Supplementary Item 5) A communication system comprising: the gateway device according to Supplementary Item 3; and the flow management device that provides related flow information. (Supplementary Item 6) The communication system according to Supplementary Item 5, wherein the flow management device comprises a related flow information providing unit that extracts a device ID in which the flow information of the packet is registered, and provides, as the related flow information, a list of flow information stored in association with the extracted device ID, or extracts an application service related to the flow information of the packet, and provides, as the related flow information, information on a server instance used to provide the application service.(Supplementary Item 7) A communication method executed by a gateway device that distributes packets received from a terminal to one of a plurality of upstream lines, the communication method comprising: a policy acquisition step of acquiring a policy for the upstream line to be used from a control device based on flow information of the packets, and a communication step of determining a specific upstream line to be used for transmitting the packets based on the policy, and sending the packets to the specific upstream line. (Supplementary Item 8) A non-transitory storage medium that stores a program for causing a computer to function as each unit in the gateway device described in any one of Supplementary Item 1 to 3.

[0112] Although the present embodiment has been described above, the present invention is not limited to such a specific embodiment, and various modifications and changes are possible within the scope of the gist of the present invention described in the claims.

[0113] 100 Device-side GW device 110 Policy acquisition unit 120 Communication unit 130 Associated flow information acquisition unit 140 Setting unit 150 Data storage unit 200 Edge-side GW device 300 Global controller 400 Control device, local controller 410 Communication unit 420 Inquiry processing unit 430 Data storage unit 500 Flow management device 510 Communication unit 520 Associated flow information providing unit 530 Data storage 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

Claims

1. A gateway device that distributes packets received from a terminal to one of multiple upstream lines, comprising: a policy acquisition unit that acquires a policy regarding the upstream line to be used from a control device based on flow information of the packets; and a communication unit that determines a specific upstream line to be used for transmitting the packets based on the policy, and sends the packets to the specific upstream line.

2. The gateway device according to claim 1, wherein the communication unit sends out the packet using a routing function corresponding to the specific upstream line among a plurality of routing functions divided by VRF.

3. The gateway device according to claim 1, further comprising: a related flow information acquisition unit that acquires related flow information, which is flow information related to the flow information of the packet, from a flow management device based on the flow information of the packet; and a setting unit that performs policy setting in advance based on the related flow information.

4. A communication system comprising: the gateway device according to claim 1; and the control device which holds the relationship between flow information and the upstream line to be used.

5. A communication system comprising a gateway device according to claim 3 and said flow management device providing associated flow information.

6. The communication system according to claim 5, wherein the flow management device includes a related flow information providing unit that extracts a device ID in which the flow information of the packet is registered and provides a list of flow information stored in association with the extracted device ID as the related flow information, or extracts an application service related to the flow information of the packet and provides information on a server instance used to provide the application service as the related flow information.

7. A communication method executed by a gateway device that distributes a packet received from a terminal to one of a plurality of upstream lines, comprising: a policy acquisition step of acquiring a policy regarding the upstream line to be used from a control device based on flow information of the packet; and a communication step of determining a specific upstream line to be used for transmitting the packet based on the policy, and sending the packet to the specific upstream line.

8. A program for causing a computer to function as each unit in the gateway device according to any one of claims 1 to 3.

Images