Gateway device, control method, and program

Abstract

A gateway device is provided with: a reception routing table for transmitting a received IP packet in which a payload IP packet is encapsulated, the received IP packet being received from the outside; a payload transmission routing table for transmitting the payload IP data packet; and a routing table for fallback, the routing table for fallback being used for transmitting the received IP data packet when the routing table for payload transmission does not include an entry for transmitting the payload IP data packet included in the received IP data packet.

Description

Technical Field

[0001] This invention relates to gateway devices, control methods, and programs. Background Technology

[0002] Patent document 1 describes ULCL UPF (Uplink Classifier User Plane Function).

[0003] Existing technical documents

[0004] Patent documents

[0005] Patent documents

[0006] Patent Document 1: Japanese Patent Application Publication No. 2021-175108 Summary of the Invention

[0007] According to an embodiment of the present invention, a gateway device is provided. The gateway device may have a receiving routing table for transmitting received IP packets encapsulated with payload IP packets received from an external source. The gateway device may have a payload transmission routing table for transmitting the payload IP packets. The gateway device may have a fallback routing table for transmitting the received IP packets when the payload transmission routing table does not include an entry for transmitting the payload IP packets included in the received IP packets.

[0008] The gateway device may have a packet receiving unit for receiving IP packets. The gateway device may also have a path control unit that performs a destination path lookup on the received IP packets received by the packet receiving unit using a receiving routing table. If a path exists for the received IP packets, a destination path lookup is performed on the payload IP packets using a payload transmission routing table. If a path exists for the payload IP packets, the payload IP packets are transmitted to the destination. If a path does not exist for the payload IP packets, a fallback routing table is used to control the execution of a destination path lookup on the received IP packets. The received IP packets may also include an IP header, a UDP header, a GTP-U header, and a payload IP packet. If a path exists for the payload IP packets, the path control unit can transmit the received IP packets to the destination, wherein the received IP packets have their IP header, UDP header, and GTP-U header converted into other headers. When a path exists for the payload IP packet, the path control unit can transmit the received IP packet to the destination, wherein the received IP packet converts the IP header, the UDP header, and the GTP-U header into an IPv6 header or an SRv6 header including both an IPv6 header and an SR header. If a path exists for the payload IP packet, the path control unit can transmit the payload IP packet to the destination, and the received IP packet will be encapsulated with an appropriate header based on the destination path retrieval result for the payload IP packet.

[0009] In any of the gateway devices described above, if a path to the received IP packet exists, the path control unit determines memory location difference information indicating the difference between the memory locations of the received IP packet and the payload IP packet, advances the pointer to the payload IP packet, and performs a destination path lookup on the payload IP packet using the payload transmission routing table; if a path to the payload IP packet does not exist, the path control unit uses the memory location difference information to recover the received IP packet, and can control the use of the fallback routing table to perform a destination path lookup on the received IP packet.

[0010] In any of the aforementioned gateway devices, the received IP data packet may include an IP header, a UDP header, a GTP-U header, and a payload IP data packet. If the path of the received IP data packet exists, the path control unit removes the IP header, the UDP header, and the GTP-U header from the received IP data packet and performs a destination path lookup on the payload IP data packet using the payload transmission routing table. If the path of the payload IP data packet does not exist, the path control unit uses the IP header, the UDP header, and the GTP-U header to recover the received IP data packet and can control the use of the fallback routing table to perform a destination path lookup on the received IP data packet.

[0011] In any of the aforementioned gateway devices, if a path exists for the received IP packet, and the received IP packet is not a GTP-U message, the path control unit performs a destination path lookup on the payload IP packet using the payload transmission routing table; if a path exists for the payload IP packet, the path control unit transmits the payload IP packet to its destination, and the payload IP packet is encapsulated with an appropriate header based on the destination path lookup result; if a path does not exist for the payload IP packet, the path control unit controls the use of the fallback routing table to perform a destination path lookup on the received IP packet; if the received IP packet is a GTP-U message, the path control unit does not need to use the payload transmission routing table to perform a destination path lookup, and can control the use of the fallback routing table to perform a destination path lookup on the received IP packet. Non-GTP-U message packets can be packets with GTP-U message type 255. GTP-U message packets can be packets with GTP-U message type ranging from 0 to 254.

[0012] In any of the aforementioned gateway devices, the receiving routing table may have routing entries specifying the payload delivery routing table and the fallback routing table. The receiving routing table can specify the payload delivery routing table and the fallback routing table by indirectly referencing destination routing entries in another routing table that specify the payload delivery routing table and the fallback routing table. Other routing tables may be, for example, the gateway device's default routing table. Other routing tables may be, for example, the gateway device's global routing table. The receiving routing table may include routing entries that can specify the fallback routing table. The receiving routing table may be capable of specifying the fallback routing table. The payload delivery routing table may include routing entries indicating fallback. The path control unit can control a routing table set as a fallback routing table from another routing table without having a setting or routing entry that designates another routing table as a fallback routing table.

[0013] According to an embodiment of the present invention, a control method executed by a computer is provided. The control method may include a data packet receiving phase, wherein a payload IP data packet is encapsulated by an IP header or an IP header and a tunneling protocol header. The control method may also include a path control phase, in which a destination path lookup is performed on the received IP data packet received in the data packet receiving phase using a receiving routing table for transmitting the received IP data packet; if a path exists for the received IP data packet, a destination path lookup is performed on the payload IP data packet using a payload transmission routing table for transmitting the payload IP data packet; if a path exists for the payload IP data packet, the payload IP data packet is transmitted to its destination, or the header encapsulated with the payload IP data packet is converted and transmitted to its destination; if a path does not exist for the payload IP data packet, and the payload transmission routing table does not include an entry for transmitting the payload IP data packet, the control method uses the fallback routing table for transmitting the received IP data packet to perform a destination path lookup on the received IP data packet.

[0014] According to an embodiment of the present invention, a program for executing the control method in a computer is provided.

[0015] It should be noted that the above summary of the invention does not list all the essential features of the invention. Furthermore, sub-combinations of these features may also constitute an invention. Attached Figure Description

[0016] Figure 1 An example of a gateway device 100 is schematically drawn.

[0017] Figure 2An example of the functional structure of a gateway device 100 is illustrated.

[0018] Figure 3 An example of the software processing flow of the gateway device 100 is illustrated.

[0019] Figure 4 An example of the hardware processing flow of the gateway device 100 is illustrated.

[0020] Figure 5 An example drawing illustrating a setting of 300.

[0021] Figure 6 This diagram illustrates a construction example of a packet-switched programmable ASIC (Application Specific Integrated Circuit).

[0022] Figure 7 An example of the hardware configuration of a computer 1200 used as a gateway device 100 is schematically drawn. Detailed Implementation

[0023] The present invention will now be described through embodiments, but these embodiments do not limit the scope of the invention as defined in the claims. Furthermore, not all combinations of features described in the embodiments are necessary for the solutions of the present invention.

[0024] A gateway device is well known to convert GTP-U compliant data packets used in a mobile network that communicates using methods compliant with the Generation Partnership Project (3GPP). The gateway device retrieves entries matching the destination address of received IP data packets, which include, for example, an IP header, a GTP-U header, and a payload IP packet. If the entry exists, the GTP-U header is deleted, and a path lookup is performed using a payload routing table to retrieve the payload IP packet. If the entry exists, an IPv6 header or both an IPv6 header and an SRv6 header are added and the packet is transmitted to the SRv6 network. This allows for proper conversion; however, problems arise when a path lookup is performed using a payload routing table and the path does not match any entries or only matches a preset path. In a normal IP network, data packets are dropped if a destination cannot be found. However, a gateway device relaying data between a mobile network and an SRv6 network cannot drop data packets simply because a destination cannot be found. If a destination is not found, the GTP data packet needs to be forwarded to the 5G node that should have received it. However, a gateway device with this function does not exist. The gateway device 100 according to this embodiment has a function that helps to solve this problem.

[0025] Figure 1 An example of a gateway device 100 is illustrated for illustrative purposes. Gateway device 100 has the function of converting data packets received from a mobile network and transmitting the converted data packets to an IP network such as an SR (Segment Routing) network. For example, gateway device 100 receives IP data packets from a wireless base station, and typically, based on the GTP-U header, these IP data packets, intended for nodes such as UPF (User Plane Function), are transmitted to servers such as MEC (Multi-access Edge Computing), regardless of the GTP-U header.

[0026] Gateway device 100 encapsulates the payload IP data packet with an appropriate header based on the destination path retrieval result of the GTP-U compliant data packet received from a wireless base station via a mobile network, and then transmits it to a server such as an MEC. For example, gateway device 100 converts the payload IP data packet received from a GTP-U compliant data packet received from a wireless base station via a mobile network into an SRv6 compliant data packet and transmits it to a server such as an MEC via an SR network. Alternatively, gateway device 100 can encapsulate the payload IP data packet with an Ethernet header and transmit it to a server such as an MEC based on the destination path retrieval result of the GTP-U compliant data packet received from a wireless base station via a mobile network.

[0027] Gateway device 100 can determine the appropriate header to use when encapsulating payload IP packets based on the path retrieval results. Specifically, for example, if the output interface transmitting the packets is a VLAN interface, gateway device 100 can use a VLAN header as an appropriate header in addition to the Ethernet (registered trademark) header. Furthermore, if the VLAN interface is also an SRv6 backbone interface, gateway device 100 can use an Ethernet header, a VLAN header, an IPv6 header, and an SR header as appropriate headers. It should be noted that the gateway device can use various headers as appropriate headers depending on the type of output interface from the path retrieval results. The following sections describe headers determined using a similar method when it is necessary to determine the appropriate header.

[0028] Figure 1 This describes the scenario where, when gateway device 100 receives a receive IP packet 210 including an IP / UDP header 212, a GTP-U header 214, and a payload IP packet 216, it converts the receive IP packet 210 into a transmit IP packet 220. The transmit IP packet 220 includes an SRv6 header 222 and a payload IP packet 226. The SRv6 header 222 includes either an IPv6 header or both an IPv6 header and an SR header, and then transmits the packet to the SR network. The payload IP packet 226 can be the same as the payload IP packet 216.

[0029] Gateway device 100 includes a receive routing table 102 for forwarding received IP packets 210 and a payload transmission routing table 104 for forwarding payload IP packets 216. When a received IP packet 210 is received, gateway device 100 uses the receive routing table 102 to perform a destination path lookup for the received IP packet 210. If a path for the received IP packet 210 exists, gateway device 100 uses the payload transmission routing table 104 to look up a destination path for the payload IP packet 216. Here, if a path for the payload IP packet 216 exists, gateway device 100 generates a transmission IP packet 220 based on the destination path lookup result. This transmission IP packet 220 includes an SRv6 header 222 and a payload IP packet 226, where the SRv6 header 222 includes either an IPv6 header or an IPv6 header and an SR header. Then, the transmission IP packet 220 is transmitted to its destination.

[0030] On the other hand, if the path for the payload IP packet 216 does not exist, conventional network functions will discard the received IP packet 210. However, discarding the received IP packet 210, which should initially be delivered to a node such as the UPF, could cause the mobile network to discard packets that should have been delivered initially, which is undesirable. Furthermore, even if the payload IP packet 216 conforms to the preset path and is delivered to the intended destination, the fact that the payload IP packet 216 also bypasses the UPF makes it difficult to control the mobile network.

[0031] Therefore, according to the gateway device 100 of this embodiment, when the payload transmission routing table 104 does not include an entry for transmitting the payload IP packet 216 included in the received IP packet 210, it also includes a fallback routing table 106 for forwarding the received IP packet 210. Furthermore, the receiving routing table 102 of the gateway device 100 may have routing entries that specify both the payload transmission routing table 104 and the fallback routing table 106. Alternatively, the receiving routing table 102 may have routing entries that specify both the fallback routing table 106 and the payload transmission routing table 104. Furthermore, the payload transmission routing table 104 may include routing entries indicating fallback. Since the gateway device 100 has the fallback routing table 106, when the payload transmission routing table 104 does not include an entry for transmitting the payload IP packet 216, the received IP packet 210 can be transmitted to a node such as a UPF as its original destination without discarding the received IP packet 210.

[0032] If the path for the payload IP packet 216 does not exist, the gateway device 100 uses the fallback routing table 106 to retrieve the destination path for the received IP packet 210. The original destination of the received IP packet 210 can be registered in the fallback routing table 106. This allows the received IP packet 210 to be transmitted to its original destination. If the received IP packet 210 can be transmitted to its original destination, a destination path with a shorter length than the prefix can be registered in the fallback routing table 106.

[0033] The gateway device 100 may have a receiving routing table 102, a payload transmission routing table 104, and a fallback routing table 106 based on the VRF (virtual routing and forwarding) function. The gateway device 100 may also have a receiving routing table 102, a payload transmission routing table 104, and a fallback routing table 106 based on the FIB (forwarding information base) table function.

[0034] To prevent a perpetual fallback loop, if a route entry designated for the fallback routing table is logged from another routing table to the fallback routing table, the gateway device 100 can automatically delete this route entry or prevent it from being logged into. The gateway device 100 can control the route to be configured as a fallback routing table from another routing table, preventing the other routing table from being designated as a fallback routing table.

[0035] For example, gateway device 100 processes received IP packet 210 according to the following procedure: It performs a destination path lookup on received IP packet 210 using the receive routing table 102. If a path for received IP packet 210 exists, gateway device 100 determines memory location difference information indicating the difference in memory locations between received IP packet 210 and payload IP packet 216. Gateway device 100 can determine the memory location difference information indicating the difference between the memory location at the beginning of received IP packet 210 and the memory location at the beginning of payload IP packet 216 included in received IP packet 210. Gateway device 100 advances the pointer to the beginning of payload IP packet 216 and performs a destination path lookup on payload IP packet 216 using payload delivery routing table 104. If a path to the payload IP packet 216 exists, the gateway device 100 transmits the transport IP packet 220 to the destination based on the destination path retrieval result. The transport IP packet 220 includes an IPv6 header, or an SRv6 header 222 including both an IPv6 header and an SR header, and a payload IP packet 226. If a path to the payload IP packet 216 does not exist, the gateway device 100 uses memory location difference information to recover the received IP packet 210 and performs a destination path retrieval for the received IP packet 210 using the fallback routing table 106. The gateway device 100 transmits the transport IP packet 230 to the destination. The transport IP packet 230 includes an IP / UDP header 232, a GTP-U header 234, and a payload IP packet 236. The IP / UDP header 232, GTP-U header 234, and payload IP packet 236 may be the same as the IP / UDP header 212, GTP-U header 214, and payload IP header 216. Therefore, the gateway device 100 can receive and transmit IP data packets 210 through software processing.

[0036] For example, gateway device 100 processes received IP packets 210 according to the following procedure: Gateway device 100 uses the receiving routing table 102 to perform a destination path lookup on the received IP packets 210. If a path exists for the received IP packets 210, the gateway device 100 removes the IP / UDP header 212 and the GTP-U header 214 from the received IP packets 210 and stores them separately. Then, it uses the payload transmission routing table 104 to perform a destination path lookup on the payload IP packets 216. If a path exists for the payload IP packets 216, gateway device 100, based on the destination path lookup result, transmits the transmission IP packets 220 to the destination. The transmission IP packets 220 add an IPv6 header or an SRv6 header 222 that includes both an IPv6 header and an SR header to the payload IP packets 226. If the path to the payload IP packet 216 does not exist, the gateway device 100 uses the IP / UDP header 212 and the GTP-U header 214 to resume receiving the IP packet 210, and performs a destination path lookup for the received IP packet 210 using the fallback routing table 106. The gateway device 100 then transmits the transmission IP packet 230 to its destination, which includes the IP / UDP header 232, the GTP-U header 234, and the payload IP packet 236. Thus, the gateway device 100 can also implement the transmission of the received IP packet 210 through hardware processing.

[0037] ULCL is considered a technology that extracts IP packets that meet specific conditions from IP packets transmitted by a wireless base station and sends them to different data networks (DNs). By using ULCL, it is possible to transmit certain IP packets to an MEC and others to a UPF. However, in ULCL, sessions and tunnels need to be established between each of the wireless base station, UPF, and MEC and the ULCL UPF. On the other hand, according to the gateway device 100 of this embodiment, for example, if sessions and tunnels are established between the wireless base station and the UPF, and between the wireless base station and the MEC, the gateway device 100 can control the transmission of IP packets to the MEC or UPF and can reduce the total number of sessions and tunnels. This helps to improve management flexibility and communication efficiency.

[0038] Figure 2 The following is an example of the functional structure of a gateway device 100 for illustrative purposes. The gateway device 100 includes a storage unit 112, a data packet receiving unit 114, and a path control unit 120. The path control unit 120 includes a data packet processing unit 122, a path retrieval unit 124, a path retrieval unit 126, and a fallback processing unit 128. The path control unit 120 does not necessarily have all of these.

[0039] Storage unit 112 stores various types of data. Storage unit 112 stores a routing table 102 for receiving data. Storage unit 112 stores a routing table 104 for payload transmission. Storage unit 112 stores a routing table 106 for fallback.

[0040] The packet receiving unit 114 receives IP packets from an external source. The packet receiving unit 114 can receive IP packets from a mobile network. The packet receiving unit 114 can receive IP packets from a wireless base station. The packet receiving unit 114 can receive IP packets encapsulated with IP packets as payloads.

[0041] The path control unit 120 uses the receiving routing table 102 to retrieve the destination path of the received IP data packet received by the data packet receiving unit 114. If the path of the received IP data packet exists, the path control unit 120 uses the payload transmission routing table 104 to perform a destination path retrieval on the payload IP data packet included in the received IP data packet. If the path of the payload IP data packet exists, the path control unit 120 will transmit the payload IP data packet to the destination according to the result of the destination path retrieval. If the path of the payload IP data packet does not exist, the path control unit 120 controls the use of the fallback routing table 106 to perform a destination path retrieval on the received IP data packet.

[0042] For example, when receiving an IP packet that includes an IP header, a GTP-U header, and a payload IP packet, the path control unit 120 uses the payload transmission routing table 104 and performs a destination path lookup on the payload IP packet. If a path for the payload IP packet exists, the path control unit 120 will transmit the payload IP packet, encapsulated with an appropriate header, as a delivery IP packet to the destination based on the destination path lookup result. For example, the path control unit 120 can encapsulate the payload IP packet with an SRv6 header.

[0043] If a path to receive IP packets exists, the path control unit 120 determines the memory location difference information indicating the memory location difference between the received IP packets and the payload IP packets, advances the pointer to the beginning of the payload IP packets, and performs destination path retrieval for the payload IP packets using the payload transmission routing table 104. If a path to the payload IP packets does not exist, the received IP packets are recovered using the memory location difference information, and the destination path retrieval for the received IP packets can be controlled using the fallback routing table 106.

[0044] If a path exists for receiving IP packets, the path control unit 120 removes the IP header, UDP header, and GTP-U header from the received IP packets and stores them separately. It then uses the payload transmission routing table 104 to perform a destination path lookup for the payload IP packets. If a path does not exist for the payload IP packets, the received IP packets are recovered using the IP header, UDP header, and GTP-U header. The fallback routing table 106 can be used to control the destination path lookup for the received IP packets.

[0045] The path control unit 120 can control a route table that is set as a fallback route table from another route table without having a setting or route entry that designates another route table as a fallback route table.

[0046] The packet processing unit 122 can process received IP packets using the path retrieval unit 124, the path retrieval unit 126, and the rollback processing unit 128. The path retrieval unit 124 uses the receiving routing table 102 to retrieve the destination path for the received IP packets. The path retrieval unit 124 can be an example of the first path retrieval unit.

[0047] Based on the destination path retrieval result of the path retrieval unit 124, the packet processing unit 122 determines the payload transmission routing table 104, the fallback routing table 106, and the storage location difference information between the received IP packets and the payload IP packets. The destination path retrieval of the payload IP packets can be used as the start of the next processing procedure.

[0048] As described above, the payload forwarding routing table 104 may include routing entries indicating fallback. The packet processing unit 122 can transmit the fallback routing table 106 and the storage location difference information to the path retrieval unit 124 and initiate the process. The path retrieval unit 124 retrieves the destination path of the payload IP packets. If the path retrieval result corresponds to a routing entry indicating fallback, the fallback routing table 106 and the storage location difference information can be transmitted to the fallback processing unit 128 and initiated. The fallback processing unit 128 can initiate the destination path retrieval of the received IP packets by using the received IP packets recovered using the storage location difference information and the fallback routing table 106.

[0049] The path retrieval unit 126 uses the payload transmission routing table 104 and performs destination path retrieval on the payload IP packets. The path retrieval unit 126 may be an example of a second path retrieval unit.

[0050] The packet processing unit 122 can pass the fallback routing table 106 and the memory location difference information to the path retrieval unit 126 and start the process. The path retrieval unit 126 uses the payload transmission routing table 104 and performs destination path retrieval on the payload IP packets. If the corresponding path does not exist, it passes the fallback routing table 106 and the received IP packets recovered using the memory location difference information to the path retrieval unit 124, and can use the fallback routing table 106 to start destination path retrieval for the received IP packets.

[0051] The packet processing unit 122 performs destination path retrieval on the payload IP packet using the payload transmission routing table 104. If the corresponding path does not exist, the fallback routing table 106 and the received IP packet recovered using the storage location difference information are passed to the path retrieval unit 124, and the fallback routing table 106 can be used to start the destination path retrieval of the received IP packet.

[0052] The gateway device 100 can also change its processing based on whether the received IP packet is a GTP-U message. For example, if the received IP packet is not a GTP-U message, the path control unit 120 uses the payload transmission routing table 104 to perform a destination path lookup for the payload IP packet; if a path for the payload IP packet exists, the payload IP packet with an appropriate header is transmitted to the destination; if a path for the payload IP packet does not exist, the fallback routing table 106 is used to control the destination path lookup for the received IP packet. For example, if the received IP packet is a GTP-U message, the path control unit 120 controls the use of the fallback routing table 106 to perform the destination path lookup for the received IP packet, instead of using the payload transmission routing table.

[0053] Gateway device 100 identifies whether a received IP packet is a GTP-U message based on the GTP-U header of the received IP packet and processes it accordingly. Specifically, for example, if the GTP-U message type value in the GTP-U header of the received IP packet is 255, the path control unit 120 of gateway device 100 can process the received IP packet as a non-GTP-U message. Furthermore, if the GTP-U message type value in the GTP-U header of the received IP packet is in the range of 0 to 254, the path control unit 120 of gateway device 100 can process the received IP packet as a GTP-U message. By changing the processing of the received IP packet according to the GTP-U message type, GTP-U messages required for the session (e.g., the PDU session to which the GTP-U message belongs) can be maintained and managed. Since path retrieval is performed using the fallback routing table 106, the data is transmitted to the UPF. Thus, path retrieval and fallback processing of the payload IP packet can be reliably performed while maintaining sessions such as anchor PDU sessions.

[0054] Gateway device 100 can modify its processing based on the GTP-U message type in the GTP-U header of the received IP data packet. For example, if the GTP-U message type in the GTP-U header of the received IP data packet meets a first condition, the path control unit 120 performs a destination path lookup on the payload IP data packet using the payload transmission routing table 104; if a path for the payload IP data packet exists, the payload IP data packet with an appropriate header is transmitted to the destination; if a path for the payload IP data packet does not exist, the fallback routing table 106 is used to control the destination path lookup of the received IP data packet. For example, if the GTP-U message type in the GTP-U header of the received IP data packet meets a second condition, the path control unit 120 controls the use of the fallback routing table 106 to perform the destination path lookup of the received IP data packet, instead of using the payload transmission routing table. If the value of the GTP-U message type in the GTP-U header of the received IP data packet is 255, the first condition is met. The second condition is met if the value of the GTP-U message type in the GTP-U header of the received IP packet is in the range of 0 to 254.

[0055] Figure 3 An example of the software processing flow of the gateway device 100 is illustrated below. The processing flow from receiving IP packets to transmitting IP packets will be described.

[0056] In step (which may be abbreviated as S) 102, the data packet receiving unit 114 receives IP data packets. In S104, the path control unit 120 uses the receiving routing table 102 to retrieve the destination path of the received IP data packets received in S102. If the path matches an entry in the receiving routing table 102, the process proceeds to S106; otherwise, the process ends.

[0057] In S106, the path control unit 120 determines memory location difference information, which indicates the memory location difference between the received IP data packet and the payload IP data packet included in the received IP data packet. In S108, the path control unit 120 advances the pointer to the payload IP data packet and initiates destination path retrieval for the payload IP data packet.

[0058] In S110, the path control unit 120 uses the payload transmission routing table 104 to retrieve the destination path of the payload IP data packet. If it matches an entry in the payload transmission routing table 104, the process proceeds to S112; otherwise, the process proceeds to S114. In S112, the path control unit 120 transmits the payload IP data packet, encapsulated with an appropriate header, as a transmission IP data packet to its destination.

[0059] In S114, the path control unit 120 uses the memory location difference information determined in S106 to recover the received IP data packets. The path control unit 120 can recover the received IP data packets by moving the difference pointer according to the difference information indicated by the memory location difference information.

[0060] In S116, the path control unit 120 initiates the use of the fallback routing table 106 to retrieve the destination path of the recovered received IP packets. In S118, the path control unit 120 transmits the recovered received IP packets to their destination.

[0061] Figure 4 An example of the hardware processing flow of the gateway device 100 is shown to illustrate this. Here, the processing flow from receiving IP packets to transmitting IP packets will be described.

[0062] In S202, the packet receiving unit 114 receives IP packets. In S204, the path control unit 120 uses the receiving routing table 102 to retrieve the destination path of the received IP packets received in S102. If the path matches an entry in the receiving routing table 102, the process proceeds to S206; otherwise, the process ends.

[0063] In S206, the path control unit 120 removes the IP header, UDP header, and GTP-U header from the received IP data packet and stores them separately. In S208, the path control unit 120 initiates destination path retrieval for the payload IP data packet.

[0064] In S210, the path control unit 120 uses the payload transmission routing table 104 to retrieve the destination path of the payload IP data packet. If it matches an entry in the payload transmission routing table 104, the process proceeds to S212; otherwise, the process proceeds to S214. In S212, the path control unit 120 transmits the payload IP data packet, encapsulated with an appropriate header, as a transmission IP data packet to its destination.

[0065] In S214, the path control unit 120 recovers the received IP data packets by returning the IP header, UDP header, and GTP-U header, which were stored separately in S206, to the payload IP data packets. The path control unit 120 can recover the received IP data packets by using the difference movement pointer indicated by the memory location difference information.

[0066] In S216, the path control unit 120 initiates the use of the fallback routing table 106 to retrieve the destination path of the recovered received IP packets. In S218, the path control unit 120 transmits the recovered received IP packets to their destination.

[0067] As described above, the gateway device 100 can implement packet transmission processing using software processing. Here, as an example of using software processing, an implementation example using VPP (Vector Packet Processing) will be described.

[0068] Figure 5 This is an example of setting up 300 for illustrative purposes. Gateway device 100 can use SR policies to define various information, such as... Figure 5The command "sr policy add bsid b:: behavior tmgtp4.dt :: / 0 v6src_prefixd1:: / 48 fib-table XXX teid 1 / 32 fallback-fib-table YYY" is shown. Gateway device 100 can define gtp4.dt as a processing entity. gtp4.dt can be a packet processing unit. gtp6.dt can also be a packet processing unit. Gateway device 100 can define gtp6.dt as a processing entity. Gateway device 100 can specify XXX as a fib table for transmitting payload IP packets. Gateway device 100 can also specify YYY as a fallback-fib fib table.

[0069] For example, gateway device 100 Figure 5 The “sr steer l3 XXXX / 32 via bsid b:: fib-table Z” shown can specify Z and set the routing entry XXXX / 32 for receiving IP packets as the fib table for receiving IP packets.

[0070] For example, when a packet configured as a fallback-fib becomes the packet processing object within the gtp4 / 6.dt (gtp4.dt or gtp6.dt) node, the gateway device 100 records the fallback destination's fib table, the address family of the received packet, and the movement of the buffer position pointer in the packet's metadata, and sets the next node as ip4 / 6 (ip4 or ip6)-lookup. The ip4 / 6 (ip4 or ip6)-lookup can be a first path retrieval unit. Furthermore, a path with the fallback as the next hop is established in the fib of the payload IP packet. This path can be, for example, a preset path. When the gateway device 100 processes the ip4 / 6-lookup of the payload IP packet, if the fallback matches a path with a next hop, the ip4 / 6-fallback node is set as the next node; otherwise, the next node is set according to the path. The ip4 / 6-fallback can be a fallback processing unit. In the ip4 / 6-fallback node, the fib table is changed to the fallback fib table, and the buffer position pointer is returned by the amount of movement of the buffer position pointer recorded in the metadata. The ip4 / 6-lookup node of the address family of the received data packets recorded in the metadata is set as the next node.

[0071] Gateway device 100 may not be required. Figure 5 The "iproute add 0.0.0.0 / 0table XXX via Fallback" part of setting 300 is shown.

[0072] For example, when a packet that is a fallback-fib becomes the processing target of a gtp4 / 6.dt node, the gateway device 100 searches locally for the destination path of the payload IP packet by checking if the path exists in the fib table. If the path exists, it is left as is; if the path does not exist, the buffer position pointer is returned to resume receiving packets, and then the appropriate ip4 / 6-loolup node according to the address family is set as the next node.

[0073] As another method, for example, when a packet configured as a fallback-fib becomes the object of processing by the gtp4 / 6.dt node, the gateway device 100 records the address family of the received packet in the metadata, confirms the address family of the payload IP packet, and sets the gtp-fallback4 / 6 node as the next node based on the result. The gtp-fallback4 / 6 node can be the second path retrieval unit. The gateway device 100 advances the buffer position pointer to the payload IP packet within the gtp-fallback4 / 6 node and performs a lookup on the configured fib table. If the path does not exist (if it is =drop), the fib table is changed to the fallback fib table, the buffer position pointer is returned to the position of the received IP packet, and packet reception is resumed. The IP4 / 6-loolup node is set as the next node based on the recorded address family. If the path exists, the next node corresponding to the lookup result is directly set as the next node.

[0074] As another method, for example, when a packet configured as fallback-fib becomes the object of processing by the gtp4 / 6.dt node, the gateway device 100 records the fallback destination's fib table, the address family of the received packet, and the movement of the buffer position pointer in the packet's metadata, and sets the next node as ip4 / 6-fallback. In this case, ip4 / 6-fallback can be a second path retrieval unit. In ip4 / 6-fallback, a lookup is performed using the configured fib table. If the path does not exist (if it is =drop), the fib table is changed to a fallback fibtable, and the recorded movement pointer of the buffer position pointer is returned. The ip4 / 6-lookup node of the recorded address family is set as the next node. If the path exists, the next node corresponding to the lookup result is directly set as the next node.

[0075] As described above, the gateway device 100 can use hardware processing to implement packet transmission processing. Here, as a practical example of using hardware processing, an implementation example using a packet switching programmable ASIC will be described.

[0076] Figure 6 This section illustrates a construction example of a packet-switched programmable ASIC (Application Specific Integrated Circuit). First, it describes the implementation using only an inner packet to perform a lookup.

[0077] Using languages ​​such as P4 (Programming Protocol-Independent Packet Processors), fields are generated in the PHV (Package Header Vector) of the ASIC packet processing pipeline. These fields store the Outer IPv4 / v6 header, UDP header, GTP-U header, and specify the fib to look up during fallback.

[0078] Then, the ASIC inputs the received data packets into the Pipeline.

[0079] Next, the Pipeline's Ingress Parser stores the header information of the received data packets and the Inner payload data packets in the PHV. The received data packet headers include the Outer IPv4 / v6 header, UDP header, and GTP-U header, which are stored in the PHV. If the UDP header can be considered a standard format, the UDP header field can be omitted. The PHV field containing the Outer IPv4 / v6 header, UDP header, and GTP-U header will be retained until the next and subsequent stages in the Pipeline determine if a matching entry exists.

[0080] Next, in the MAU (Match Action Pipeline) stage after the Ingress Parser in the Pipeline, at any MAU stage that looks up the Inner payload packet in the Pipeline, if a table entry matching the Inner payload packet is found, the processing indicated by the matching entry is executed.

[0081] Next, in the Pipeline, if no matching table entry is found in any MAU stage, or if a table entry indicating rollback is hit, the original received IP packet is recovered using the received IP packet headers (Outer IPv4 / IPv6 header, UDP header, GTP-U header) stored in PHV during any MAU stage before the packet is output from the Pipeline to the packet buffer. Then, it is output to the packet buffer and passed through the EgressPipeline. Appropriate header information is added to the received IP packet, or header information is added and modified, and it can be transmitted to the appropriate output destination interface.

[0082] Next, we will describe the implementation of performing two lookups in the Inner and Outer data packets.

[0083] Using languages ​​such as P4, the PHV (Package Header Vector) of the ASIC packet processing pipeline generates fields that store the Outer IPv4 / v6 header, UDP header, GTP-U header, and fields that specify the fib to look up during fallback.

[0084] Then, the ASIC inputs the received data packets into the Pipeline.

[0085] Next, the Pipeline's Ingress Parser stores the header information of the received data packets and the Inner payload data packets in the PHV. The received data packet headers include the Outer IPv4 / v6 header, UDP header, and GTP-U header, which are stored in the PHV. If the UDP header can be considered a standard format, the UDP header field can be omitted. The PHV field containing the Outer IPv4 / v6 header, UDP header, and GTP-U header will be retained until the next and subsequent stages in the Pipeline determine if a matching entry exists.

[0086] Next, in the MAU (Match Action Pipeline) stage after the Ingress Parser in the Pipeline, at any MAU stage that looks up the Inner payload packet in the Pipeline, if a table entry matching the Inner payload packet is found, the processing indicated by the matching entry is executed.

[0087] In the pipeline, if no matching table entry is found at any MAU stage, or if a table entry indicating fallback is matched, and if the Egress Pipeline is unable to perform a fib lookup, the fallback fib table is looked up using the Outer IPv4 / IPv6 header, UDP header, and GTP-U header stored in the PHV during any MAU stage before the packet is output from the pipeline to the packet buffer. If a table entry matching the received IP packet header is found, the processing indicated by the matching table entry is to restore the original received IP packet and then output it to the packet buffer. If the Egress Pipeline is capable of performing a fib lookup, the Ingress Pipeline restores the original received IP packet without looking up the fallback fib table and then outputs it to the packet buffer.

[0088] If the Egress Pipeline is capable of performing a fib lookup, the ASIC outputs the recovered received packets to the packet buffer and then inputs them into the Egress Pipeline. At this point, the fib table value specified for looking up the recovered received packets in any MAU stage of the Egress Pipeline is stored in the PHV.

[0089] The ASIC searches for recovered received packets at any MAU stage in the Egress Pipeline. If a matching table entry is found, the processing indicated by the matching entry is performed. If no matching table entry is found at any MAU stage, predefined processing such as dropping the packet is performed. If the Egress Pipeline is unable to perform a fib lookup, the ASIC outputs the recovered received packets to the packet buffer and adds appropriate header information to the received IP packets via the Egress Pipeline, or adds and modifies header information, and can then transmit the packets to the appropriate output destination interface.

[0090] Figure 7 This illustration shows an example of the hardware configuration of a computer 1200 used as a gateway device 100. A program installed on the computer 1200 causes the computer 1200 to function as one or more "parts" of the device according to this embodiment, or causes the computer 1200 to perform operations of one or more "parts" associated with the device according to this embodiment, and / or causes the computer 1200 to perform a process or steps of that process according to this embodiment. Such a program can be executed by the CPU 1212 to cause the computer 1200 to perform certain operations associated with some or all of the blocks in the flowcharts and block diagrams described in this specification.

[0091] The computer 1200 according to this embodiment includes a CPU 1212, RAM 1214, and a graphics controller 1216, which are interconnected via a host controller 1210. The computer 1200 also includes input / output units, such as a communication interface 1222, a storage device 1224, a DVD drive, and an IC card driver, which are connected to the host controller 1210 via an input / output controller 1220. The DVD drive may be a DVD-ROM drive, a DVD-RAM drive, etc. The storage device 1224 may be a hard disk, a solid-state drive, etc. The computer 1200 also includes a ROM 1230 and conventional input / output units such as a keyboard, which are connected to the input / output controller 1220 via an input / output chip 1240.

[0092] The CPU 1212 operates according to the program stored in the ROM 1230 and RAM 1214, thereby controlling each unit. The graphics controller 1216 acquires the image data generated by the CPU 1212 into the frame buffer provided in RAM 1214 or RAM itself, and displays the image data on the display device 1218.

[0093] Communication interface 1222 communicates with other electronic devices via a network. Storage device 1224 stores programs and data used by CPU 1212 within computer 1200. DVD drive reads programs or data from DVD-ROM, etc., and provides them to storage device 1224. IC card drive reads programs and data from IC card and / or writes programs and data to IC card.

[0094] ROM 1230 stores a program, such as a boot program executed by computer 1200 at startup, and / or programs dependent on computer 1200 hardware. Input / output chip 1240 can also connect various input / output units to input / output controller 1220 via USB port, parallel port, serial port, keyboard port, mouse port, etc.

[0095] The program is provided by a computer-readable storage medium such as a DVD-ROM or IC card. The program is read from the computer-readable storage medium and installed in a storage device 1224, RAM 1214, or ROM 1230, which is also an example of a computer-readable storage medium, and is executed by a CPU 1212. The information processing described in these programs is read by a computer 1200, which provides coordination between the program and the aforementioned various types of hardware resources. The apparatus or method can be configured to perform the operation or processing of information according to the use of the computer 1200.

[0096] For example, when communication occurs between computer 1200 and an external device, CPU 1212 executes a communication program loaded into RAM 1214, and can perform communication processing based on the processing instructions described in the communication program to communication interface 1222. Under the control of CPU 1212, communication interface 1222 reads transmission data stored in a transmission buffer set in a recording medium such as RAM 1214, storage device 1224, DVD-ROM, or IC card, and transmits the read transmission data to the network, or writes received data received from the network to a receive buffer set on the recording medium, etc.

[0097] Furthermore, the CPU 1212 enables the RAM 1214 to read all or necessary portions of files or databases stored on external recording media such as storage device 1224, DVD-ROM drive, IC card, etc., and can perform various types of processing on the data on the RAM 1214. The CPU 1212 can then write the processed data back to the external recording media.

[0098] Various types of information, such as programs, data, tables, and databases, can be stored on the recording medium and processed. Data read by the CPU 1212 from the RAM 1214, as otherwise described in this invention, includes various operations, information processing, conditional judgments, conditional branches, unconditional branches, information retrieval / replacement, etc., as specified by the program instruction sequence. Various types of processing can be executed, and the results can be written back to the RAM 1214. Furthermore, the CPU 1212 can retrieve information from files, databases, etc., on the recording medium. For example, if multiple entries are stored on the recording medium, and each entry has an attribute value of a first attribute associated with the attribute value of a second attribute, the CPU 1212 retrieves entries from among the multiple entries that meet the condition of the specified attribute value of the first attribute, and can read the attribute value of the second attribute stored in that entry, thereby obtaining the attribute value of the second attribute associated with the first attribute that satisfies a predetermined condition.

[0099] The aforementioned program or software module can be stored on or near the computer 1200 in a computer-readable storage medium. Alternatively, a storage medium such as a hard disk or RAM configured in a server system connected to a dedicated communication network or the Internet can be used as a computer-readable storage medium, thereby providing the program to the computer 1200 via the network.

[0100] The blocks in the flowcharts and block diagrams of this embodiment may represent stages in the execution of an operation or "parts" of the device responsible for performing the operation. Certain stages and "parts" may be implemented by dedicated circuitry, programmable circuitry having computer-readable instructions stored on a computer-readable storage medium, and / or a processor having computer-readable instructions stored on a computer-readable storage medium. Dedicated circuitry may include digital and / or analog hardware circuitry and may include integrated circuits (ICs) and / or discrete circuitry. Programmable circuitry may include reconfigurable hardware circuitry, including logic operations such as AND, OR, EXCLUSIVE OR, NAND, and NOR, flip-flops, registers, and storage elements such as field-programmable gate arrays (FPGAs) and programmable logic arrays (PLAs).

[0101] Computer-readable storage media can include any tangible means capable of storing instructions executable by appropriate means. Consequently, a computer-readable storage medium having stored instructions thereon will include an article of writing that can be executed to create means for performing the operations specified in a flowchart or block diagram. Examples of computer-readable storage media can include: electronic storage media, magnetic storage media, optical storage media, electromagnetic storage media, semiconductor storage media, etc. More specific examples of computer-readable storage media include: floppy disks (registered trademark), diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), electrically erasable programmable read-only memory (EEPROM), static random access memory (SRAM), optical disc read-only memory (CD-ROM), digital versatile optical disc (DVD), Blu-ray disc (registered trademark), memory sticks, integrated circuit cards, etc.

[0102] Computer-readable storage media may include any source code or object code written in any combination of one or more programming languages, including conventional procedural programming languages ​​such as assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state configuration data, or object-oriented programming languages ​​such as Smalltalk (registered trademark), JAVA (registered trademark), C++, etc., as well as the "C" programming language or similar programming languages.

[0103] Computer-readable instructions are instructions that, when executed, are used by a processor of a general-purpose computer, special-purpose computer, or other programmable data processing device, or by causing programmable circuitry to produce means for performing the operations specified in a flowchart or block diagram. These instructions may be provided locally or via a wide area network (WAN), such as a local area network (LAN), the Internet, etc. Examples of processors include computer processors, processing units, microprocessors, digital signal processors, controllers, microcontrollers, etc.

[0104] The present invention has been described above using embodiments, but the technical scope of the present invention is not limited to the scope described in the above embodiments. It will be apparent to those skilled in the art that various changes or modifications can be made to the above embodiments. It is clear from the claims that such modifications or improvements can be covered within the technical scope of the present invention.

[0105] The execution order of the various processes (e.g., actions, flows, steps, and stages) in the apparatus, systems, programs, and methods shown in the claims, description, and drawings is not specifically specified as "earlier than" or "before." Furthermore, it should be noted that they can be implemented in any order as long as the output of a preceding process is not used in a later process. Even if terms such as "firstly," "secondly," etc., are used in the claims, description, and drawings for convenience, it does not imply that they must be implemented in this order.

[0106] Explanation of reference numerals in the attached figures

[0107] 100: Gateway device; 102: Receiving routing table; 104: Payload transmission routing table; 106: Fallback routing table; 112: Storage unit; 114: Packet receiving unit; 120: Path control unit; 122: Packet processing unit; 124: Path retrieval unit; 126: Path retrieval unit; 128: Fallback processing unit; 210: Receive IP packets; 212: IP / UDP header; 214: GTP-U header; 216: Payload IP packets; 220: Transmit IP packets; 222: SRv6 packets. 226: Payload IP packet, 230: Transmit IP packet, 232: IP / UDP header, 234: GTP-U header, 236: Payload IP packet, 300: Configuration, 1200: Computer, 1210: Host controller, 1212: CPU, 1214: RAM, 1216: Graphics controller, 1218: Display device, 1220: Input / output controller, 1222: Communication interface, 1224: Storage device, 1230: ROM, 1240: Input / output chip.

Claims

1. A gateway device, comprising: The receiving routing table is used to transmit received IP packets that are received from the outside and encapsulate the payload IP packets; A routing table for payload transmission, used to transmit the payload IP packets; and A fallback routing table is used to transmit the received IP packet when the payload transmission routing table does not include an entry for transmitting the payload IP packet included in the received IP packet.

2. The gateway device according to claim 1, wherein, The gateway device includes: The data packet receiving unit receives IP data packets; and The path control unit controls the data in the following manner: when performing a destination path lookup for the received IP data packet received by the data packet receiving unit using the receiving routing table, and a path for the received IP data packet exists, the path control unit performs a destination path lookup for the payload IP data packet using the payload transmission routing table; if a path for the payload IP data packet exists, the path control unit transmits the payload IP data packet to its destination; if a path for the payload IP data packet does not exist, the path control unit performs a destination path lookup for the received IP data packet using the fallback routing table.

3. The gateway device according to claim 2, wherein, The received IP data packet includes an IP header, a UDP header, a GTP-U header, and the payload IP data packet. If a path exists for the payload IP packet, the path control unit transmits the payload IP packet to the destination, and the payload IP packet is encapsulated with an appropriate header based on the result of the destination path retrieval.

4. The gateway device according to claim 3, wherein, If a path for the payload IP data packet exists, the path control unit transmits the received IP data packet to the destination. The received IP data packet is a header that converts the IP header, the UDP header, and the GTP-U header into an IPv6 header or an SRv6 header that includes both an IPv6 header and an SR header.

5. The gateway device according to any one of claims 2 to 4, wherein, The path control unit controls the data in the following manner: if a path exists for the received IP data packet, the path control unit determines memory location difference information indicating the difference between the memory locations of the received IP data packet and the payload IP data packet, advances the pointer to the payload IP data packet, and performs a destination path retrieval for the payload IP data packet using the payload transmission routing table; if a path does not exist for the payload IP data packet, the path control unit uses the memory location difference information to recover the received IP data packet and performs a destination path retrieval for the received IP data packet using the fallback routing table.

6. The gateway device according to any one of claims 2 to 4, wherein, The received IP data packet includes an IP header, a UDP header, a GTP-U header, and the payload IP data packet. The path control unit controls the data in the following manner: if a path exists for the received IP data packet, the path control unit removes the IP header, the UDP header, and the GTP-U header from the received IP data packet and performs a destination path lookup on the payload IP data packet using the payload transmission routing table; if a path does not exist for the payload IP data packet, the path control unit uses the IP header, the UDP header, and the GTP-U header to recover the received IP data packet and performs a destination path lookup on the received IP data packet using the fallback routing table.

7. The gateway device according to any one of claims 2 to 4, wherein, If the path for receiving IP packets exists, the path control unit controls it in the following manner: When the GTP-U message type in the GTP header of the received IP packet meets the first condition, the path control unit performs a destination path lookup on the payload IP packet using the payload transmission routing table. If a path exists for the payload IP packet, the path control unit transmits the payload IP packet to its destination. The payload IP packet is encapsulated with an appropriate header based on the destination path lookup result. If a path does not exist for the payload IP packet, the path control unit performs a destination path lookup on the received IP packet using the fallback routing table. If the GTP-U message type in the GTP header of the received IP data packet meets the second condition, the path control unit does not need to use the payload transmission routing table to perform destination path retrieval, but uses the fallback routing table to perform destination path retrieval on the received IP data packet.

8. The gateway device according to claim 7, wherein, When the GTP-U message type value in the GTP-U header of the received IP packet is 255, the path control unit performs a destination path lookup on the payload IP packet using the payload transmission routing table. If a path exists for the payload IP packet, the path control unit transmits the payload IP packet to its destination. The payload IP packet is encapsulated with an appropriate header based on the destination path lookup result. If a path does not exist for the payload IP packet, the path control unit controls the use of the fallback routing table to perform a destination path lookup on the received IP packet. When the value of the GTP-U message type in the GTP-U header of the received IP data packet is in the range of 0 to 254, the path control unit does not need to use the payload transmission routing table to perform destination path retrieval, but uses the fallback routing table to perform destination path retrieval on the received IP data packet.

9. The gateway device according to any one of claims 1 to 8, wherein, The gateway device has a routing table that can register route entries that specify the routing table for payload transmission and the routing table for fallback.

10. The gateway device according to any one of claims 1 to 8, wherein, The receiving routing table has routing entries, which specify the payload delivery routing table and the fallback routing table by referring to the routing entries of the payload delivery routing table registered in any routing table existing in the gateway and specifying the fallback routing table.

11. The gateway device according to any one of claims 1 to 8, wherein, The routing table for payload transmission includes routing entries indicating fallback.

12. The gateway device according to any one of claims 2 to 8, wherein, The path control unit controls a route table that is set as a fallback route table from another route table, but does not have a setting or route entry that designates another route table as a fallback route table.

13. A control method executed by a computer, the control method comprising: During the packet reception phase, IP packets containing the payload IP packet are received, either encapsulated by an IP header or an IP header and a tunnel protocol header; and During the path control phase, control is performed as follows: A destination path is retrieved for the received IP packets received during the packet reception phase using a receive routing table for transmitting received IP packets; if a path exists for the received IP packets, a destination path is retrieved for the payload IP packets using a payload transmission routing table for transmitting the payload IP packets; if a path exists for the payload IP packets, the payload IP packets are transmitted to their destination, or the header of the payload IP packets is converted and transmitted to their destination; if a path does not exist for the payload IP packets, and if the payload transmission routing table does not contain an entry for transmitting the payload IP packets, a destination path is retrieved for the received IP packets using a fallback routing table for transmitting the received IP packets.

14. A program for causing a computer to perform the control method according to claim 13.

Images