CN114205301A - MPTCP load balancing method, medium and device - Google Patents

Abstract

The embodiment of the application relates to a Multipath Transport Control Protocol (MPTCP) load balancing method, which comprises the steps of receiving a request message used by user equipment for requesting to establish MPTCP connection, searching a static forwarding rule table according to an identifier of a server under the condition that the request message comprises the identifier of the server so as to determine an IP address of the server corresponding to the identifier of the server, and forwarding the request message to the server corresponding to the IP address, wherein the static forwarding rule table is configured in the load balancing equipment in advance and comprises a mapping relation between the identifier of the server and the IP address of the server. Embodiments of the present application also relate to a machine-readable medium and apparatus.

Description

MPTCP load balancing method, medium and equipment

Technical Field

One or more embodiments of the present application generally relate to the field of communications technologies, and in particular, to a method, medium, and device for load balancing of a Multipath Transport Control Protocol (MPTCP).

Background

With the advent of IPv6, the multiple address (Multihome) of a host has become more and more popular. From servers under the data center Fat tree (Fat-tree) network architecture to multi-connected smartphones with 5G/4G/Wifi/3G/Bluetooth (Bluetooth)/wired ethernet/fiber optic networks, there are multi-homed hosts. In order to fully utilize The multi-connection characteristics of The device, The IETF (Internet Engineering Task Force) has formulated a multi-path Transport Control Protocol (MPTCP), which allows a Transport Control Protocol (TCP) to use multiple paths for connection to maximize The use of channel resources, thereby improving The end-to-end throughput and increasing The network utilization.

In an MPTCP scenario, an MPTCP connection is composed of multiple TCP connections. According to a traditional Load Balance (LB) mechanism, to ensure that different TCP connections of the same MPTCP session are routed to the same server, the LB may dynamically create an MPTCP Load Balance record for recording a mapping relationship between a Token and an IP address of the server according to a Token (Token) of the MPTCP session (session). Load balancing may not be achieved if different TCP connections of MPTCP are forwarded by different LBs. Furthermore, the token is associated with an MPTCP session, whose lifetime is the same as that of MPTCP. In other words, when an MPTCP session ends, the token may also fail, and the corresponding MPTCP load balancing record may also fail.

Disclosure of Invention

The present application is described below in terms of several aspects, embodiments and advantages of which are mutually referenced.

In a first aspect, an embodiment of the present application provides an MPTCP load balancing method, which is used for a load balancing device, and includes receiving a first request message, which is used by a User Equipment (UE), for requesting to establish a first MPTCP connection; selecting a server that establishes the first MPTCP connection with the UE and sending the first request message to the server; receiving a first response message from the server for the first request message, the first response message including an identification of the server; receiving a second request message used by the UE for requesting to establish a second MPTCP connection, and under the condition that the second request message is determined to include the identifier of the server, searching a static forwarding rule table according to the identifier of the server to determine the IP address of the server corresponding to the identifier of the server, and forwarding the second request message to the server corresponding to the IP address, wherein the static forwarding rule table is configured in the load balancing equipment in advance and includes the mapping relation between the identifier of the server and the IP address of the server.

In a possible implementation of the first aspect described above, the first MPTCP connection and the second MPTCP connection belong to the same MPTCP session.

In a possible implementation of the first aspect, the Identifier of the server includes a number of the server or a UUID (Universally Unique Identifier) or a Globally Unique Identifier (GUID).

In a possible implementation of the first aspect as such, the identification of the server is independent of the MPTCP session.

In a possible implementation of the first aspect, the response message further comprises at least one of a category (kidd), a Length (Length), and an MPTCP options Subtype (Subtype).

In a second aspect, an embodiment of the present application provides an MPTCP load balancing method, which is used for a user equipment, and includes sending a first request message for requesting establishment of a first MPTCP connection, receiving a first response message from a server for the first request message, where the first response message includes an identifier of the server, and sending a second request message for requesting establishment of a second MPTCP connection to the server, where the second request message includes the identifier of the server in a case where it is determined that the first MPTCP connection and the second MPTCP connection belong to a same MPTCP session.

In a possible implementation of the second aspect, the identification of the server includes a number of the server or a UUID (UUID) or a Globally Unique Identifier (GUID).

In one possible implementation of the second aspect described above, the identification of the server is independent of the MPTCP session.

In a possible implementation of the second aspect, the first response message further comprises at least one of a category (kidd), a Length (Length), and an MPTCP option Subtype (Subtype).

In a possible implementation of the second aspect described above, the second request information does not include the identification of the server in case it is determined that the first MPTCP connection and the second MPTCP connection do not belong to the same MPTCP session.

In a third aspect, an embodiment of the present application provides an MPTCP load balancing method, for a server, including receiving a first request message from a user equipment for establishing a first MPTCP connection, sending a first response message to the first request message of the first MPTCP connection, where the first response message includes an identifier of the server, and receiving an acknowledgement message that the user equipment establishes the first MPTCP connection; receiving a second request message used by the user equipment for establishing a second MPTCP connection, and establishing the second MPTCP connection if the second request message is determined to include the identifier of the server.

In a possible implementation of the above third aspect, the first MPTCP connection and the second MPTCP connection belong to the same MPTCP session.

In a possible implementation of the third aspect, the Identifier of the server includes a number of the server or a UUID (Universally Unique Identifier) or a Globally Unique Identifier (GUID).

In a possible implementation of the above third aspect, the identification of the server is independent of the MPTCP session.

In a possible implementation of the third aspect, the first response message and the second response message further include at least one of a category (kidd), a Length (Length), and an MPTCP option Subtype (Subtype).

In a fourth aspect, an embodiment of the present application provides a machine-readable medium having stored thereon instructions which, when executed on the machine, cause the machine to perform the method of the first to third aspects.

In a fifth aspect, an embodiment of the present application provides an apparatus, including: a processor; a memory having instructions stored thereon that, when executed by the processor, cause the user equipment to perform the method of the first to third aspects.

According to the technical scheme of the application, a plurality of sub-streams of the MPTCP session are established based on a static forwarding rule table of the mapping relation between the identification information of the server and the IP address. Since the identification information of the server is independent of the MPTCP session, and remains unchanged during the lifetime of providing the service, the method of load balancing according to the present application can more efficiently and reliably establish the multiple subflows of the MPTCP session compared to the prior art load balancing.

Drawings

Fig. 1 is a schematic view of a data transmission system to which a load balancing method according to an embodiment of the present application is applied;

fig. 2 is a signal flow diagram of an MPTCP load balancing method according to some embodiments of the present application;

fig. 3 is a flow diagram of an MPTCP load balancing method for a load balancing device according to some embodiments of the present application;

FIG. 4 is a diagram of an MPTCP option carrying server identification information according to one embodiment of the present application;

fig. 5 is a flow diagram of a MPTCP load balancing method for a UE according to some embodiments of the present application;

fig. 6 is a flow diagram of a MPTCP load balancing method for a server according to some embodiments of the present application.

Detailed Description

The present application is further described with reference to the following detailed description and the accompanying drawings.

It is to be understood that, although the terms first, second, etc. may be used herein to describe various elements or data, these elements or data should not be limited by these terms. These terms are used merely to distinguish one feature from another. For example, a first feature may be termed a second feature, and, similarly, a second feature may be termed a first feature, without departing from the scope of example embodiments.

It should be noted that in this specification, like reference numerals and letters refer to like items in the following drawings, and thus, once an item is defined in one drawing, it need not be further defined and explained in subsequent drawings.

To make the objects, technical solutions and advantages of the present application more clear, embodiments of the present application will be described in further detail below with reference to the accompanying drawings.

Fig. 1 is a schematic view of a data transmission system to which a load balancing method according to an embodiment of the present application is applied. As shown in fig. 1, a data transmission system may include a User Equipment (UE) 100,load balancing instances 201 and 202, and a server resource pool 300 including a plurality ofservers 301, 302, 303. The UE may be a laptop computer, a desktop computer, a tablet computer, a mobile phone, a wearable device, a head-mounted display, a server, a mobile email device, a portable game console, a portable music player, a reader device, a television with one or more processors embedded or coupled therein, or other electronic devices capable of accessing a network, and may also be a network device such as a CPE (Customer Premise Equipment) that supports MPTCP client or MPTCP proxy. Theload balancing instances 201 and 202 may be two instances of a load balancing service running in the same load balancing device, or may be two instances of a load balancing service running in two different load balancing devices. The server resource pool 300 is a server cluster that may include a plurality of servers (e.g., server 301 and 303) managed by load balancing instances (e.g., instances 201 and 202) that may provide data processing services for user equipment (e.g., UE100), where the plurality ofservers 301, 302, 303 may be physical servers, virtual machines or containers, or the like. In fig. 1, UE100 is shown to establish a connection withserver 302, but those skilled in the art will appreciate that the connection with UE100 may be established with any server, e.g., 301 or 303, in server resource pool 300.

Further, the UE100 includes acontroller 110, and thecontroller 110 may include, but is not limited to, a modem, a Central Processing Unit (CPU), an Application Processor (AP), a Microprocessor (MCU), an Artificial Intelligence (AI) Processor, or a Programmable logic device (FPGA) Processing circuit. Wherein the modem is configured to modulate information (e.g., signals and/or data) in a baseband frequency domain to be transmitted into analog signals that can be transmitted through the transceiver according to a protocol of 3GPP, and demodulate the analog signals received by the transceiver into information in the baseband frequency domain that can be processed by the processor of the UE 100. The different processing units may be separate devices or may be integrated in one or more processors. In one possible implementation, thecontroller 110 may run an operating system, such as an Android, iOS, Windows OS, Linux, and hong meng operating system, among others. In other possible embodiments, thecontroller 110 may run a specific application. A memory may also be provided in thecontroller 110 for storing instructions and data. In embodiments of the present application, thecontroller 110 may be configured to perform a load balancing method according to the following.

The UE100 also includes twotransceivers 101 and 102. The transceiver is used to provide a wireless connectivity interface (e.g., radio frequency front end module, antenna, etc.) for the UE100 to communicate with any other suitable devices via one or more networks. It will be understood by those skilled in the art that transceivers 101 and 102 may be Network interfaces providing wireless communication including Wired Local Area Networks (WLANs), Wireless Local Area Networks (WLANs) such as wireless fidelity (Wi-Fi) networks, Bluetooth (BT), third generation Mobile communication technology (3rd-generation Mobile communication technology, 3G) networks, fourth generation Mobile communication technology (4G) networks, fifth generation Mobile communication technology (5G) networks, and/or data connection services of future-evolution Public Land Mobile Networks (PLMNs). In an embodiment of the present application, thetransceiver 101 and thetransceiver 102 may communicate through different networks, and thetransceivers 101 and 102 may have different IP addresses, respectively, for example, thetransceiver 101 is a network interface for performing 4G wireless communication, and thetransceiver 102 is a network interface for performing WLAN wireless communication. In addition, those skilled in the art will appreciate that the UE100 shown in fig. 1 includes two transceivers for illustration only, and the number of transceivers is not particularly limited, and may be three or more.

As shown in fig. 1, an MPTCP session is established betweenservers 302 in a UE100 server resource pool 300, which enables data transmission on two sub-streams (TCP connections) simultaneously. Assuming that thetransceiver 101 of the UE100 accesses the internet through the 4G core network, a TCP connection is first established with theserver 302 in the server resource pool 300 via the load balancing instance 201, and then thetransceiver 102 of the UE accesses the internet through the wireless local area network, and a TCP connection is also established with theserver 302 via theload balancing instance 202. Further, the TCP connection between thetransceiver 101 and theserver 302 that is established first is a first TCP connection of the MPTCP session, which may also be generally referred to as a first Subflow (Subflow) of the MPTCP session, and the TCP connection between thetransceiver 102 and theserver 302 that is established later is a second TCP connection of the MPTCP session, which may also be referred to as an additional Subflow of the MPTCP session. As described above, the two sub-streams belong to the same MPTCP session, so that data sent by the UE can select any sub-stream for transmission.

Next, an MPTCP load balancing method according to an embodiment of the present application will be explained with reference to fig. 2.

As with ordinary TCP connections, the establishment of the first subflow of an MPTCP session, i.e.step 21 shown in fig. 2, also requires Three handshakes (Three-way handshake) across the two communicating parties. To be TCP compatible, all management information of MPTCP is transmitted through the TCP option field. During the first substream establishment, both communicating parties need to carry a multi-path capability (MP-capability) option in the SYN, SYN/ACK message.

As shown in fig. 2, first atstep 210, the UE100 sends a request to establish a first connection to a server through thetransceiver 101 for transmitting a first sub-flow of an MPTCP session, which may be a SYN message. The SYN message carries an MP-CAPABLE option, which is used to indicate that the UE100 supports MPTCP connection. Typically, the MP-CAPABLE option also includes a Key (Key) of the UE 100.

It should be noted thatstep 210 in fig. 2 shows that the SYN packet is directly sent to theserver 302 by the UE100, and actually, in a scenario including load balancing, the SYN packet carrying the MP-capability option is forwarded through a load balancer corresponding to a load balancing instance. The load balancer may perform a hash algorithm or other random allocation algorithm based on a quintuple (i.e., a sender IP address, a sender port, a receiver IP address, a receiver port, and a transport layer protocol) to select a server from the server resource pool 300 to establish the first connection with the UE100 and forward the request to establish the first connection to the selected server (e.g., the server 301). Also, the steps of other information transfer between the UE100 and theserver 302 shown in fig. 2 are actually forwarded via the load balancer. Here, it is assumed that information transfer between the UE100 and theserver 302 instep 21 of establishing the first subflow of the MPTCP session shown in fig. 2 is completed by the load balancer where the load balancing instance 201 is located.

Next, instep 211, theserver 302 sends a response message after receiving the SYN message carrying the MP-CAPABLE option from the UE 100. The response message is a SYN/ACK message, i.e., a handshake acknowledgement message. Similarly, the SYN/ACK message carries an MP-CAPABLE option, which is used to indicate that theserver 302 supports MPTCP connection. Typically, the MP-CAPABLE option also includes a Key (Key) for theserver 302.

In order to solve the problem that load balancing may not be achieved when the same MPTCP is forwarded by different LBs in the prior art, according to the load balancing method of the present application, the SYN/ACK message also carries identification information (Server ID) of theServer 302 for establishing an additional sub-flow of the MPTCP session. The identification information may be any server identification unrelated to a specific MPTCP session, for example, a Unique sequential number such as 1, 2, 3 … …, or may be a universal Unique Identifier (universal Unique Identifier, UUID, or Global Unique Identifier (GUID)), which is not specifically limited in this embodiment of the present application.

The following is an example of a server resource pool member list configured in the load balancing example in the present scheme:

in one example, a network operation manager may configure the load balancing instance via a management protocol (e.g., Netconf, SNMP, RESTful APIs over HTTP) or a local Web network manager or CLI command line. For example, in the LB server resource pool configuration, in addition to configuring the IP of each backend server, an identifier corresponding to each server is also configured, and the configured server identifier is to be consistent with the identifier of the backend server itself. And the load balancer where the load balancing example is located generates a static forwarding rule table according to the configuration of the server resource pool, and selects a corresponding server to perform corresponding processing and routing forwarding of the message according to the server ID carried in the captured service message.

In one example, the static forwarding rule table may be stored in the load balancing device of theload balancing instance 202, or may be stored in another server or memory in communication with the load balancing device, such as a cloud server.

In one example, the static forwarding rule table may also include a mapping relationship associated with routing information on a communication link between the UE100 and theserver 302.

Likewise, the SYN/ACK packet carrying theserver 302 identifier is forwarded to thetransceiver 101 of the UE100 via the load balancer where the load balancing instance 201 is located.

Instep 212, the UE100, after receiving the SYN/ACK message from theserver 302, resolves the identification information of theserver 302, caches the server identification, and then sends out an acknowledgement message. The acknowledgement message is an ACK message, the ACK message carries the MP-CAPABLE option and the identifier of theserver 302, and the MP-CAPABLE option includes the Key of the UE100 and the Key of theserver 302. The ACK packet is forwarded through a load balancer corresponding to the load balancing instance, and the load balancer detects that the ACK packet is a packet that needs load balancing (for example, the protocol type is TCP, and the port is an 80 port corresponding to an HTTP protocol), analyzes and finds that the packet carries aserver 302 identifier, and then queries a forwarding rule table according to theserver 302 identifier, queries an IP of theserver 302 for routing forwarding, and forwards the ACK packet to theserver 302. To this end, the establishment of the first subflow of the MPTCP session, which is also linked, is completed between thetransceiver 101 of the UE100 and theserver 302 through the three-way handshake procedure.

It should be noted that, after the MPTCP session establishment is completed, the UE100 associates theserver 302 identifier with the MPTCP session, for example, writes the session parameter information of the MPTCP session.

After the first substream of the MPTCP is successfully established, data transmission of the MPTCP session can be performed between thetransceiver 101 of the UE100 and theserver 302. The data transmission process is a normal TCP data transmission process, the TCP data carries the identifier of theserver 302 when being sent out on the UE100, and the forwarding flow on the load balancer where the load balancing example is located is the same as the forwarding flow of the ACK packet. Not shown in fig. 2, and will not be described in detail herein.

To improve the end-to-end throughput and increase the network utilization, an additional subflow of the MPTCP session will be established next in step 22 between thetransceiver 102 of the UE100 and theserver 302. Here, it is assumed that the information transfer between the UE100 and theserver 302 instep 21 of establishing additional subflows of the MPTCP session shown in fig. 2 is done by theload balancing instance 202.

If the information transfer of additional subflows establishing an MPTCP session between the UE100 and theserver 302 is done by theload balancing instance 202, conventional load balancing techniques may perform a quintuple hash algorithm or other random assignment algorithm forwarding based on the token of the MPTCP session. Sincetransceivers 101 and 102 of UE100 have different IP addresses, this may result in the messaging oftransceiver 102 being routed to a server other thanserver 302, with the result that load balancing is not possible.

According to the load balancing method of the present application, the additional sub-stream link establishment messages (SYN, ACK messages) of the MPTCP session carry theserver 302 identifier, and the forwarding flow on the load balancer where the load balancing example is located is the same as the forwarding flow of the ACK message of the first sub-stream. This ensures that additional sub-streams are successfully established between thetransceiver 102 of the UE100 and theserver 302. This process will be described in detail with reference to fig. 2.

According to an example of the present application, thetransceiver 101 of the UE100, after receiving the identification information of theserver 302, stores the mapping relationship between the identification information of theserver 302 and the current MPTCP session in the memory of the UE 100. When the UE100 needs to generate an additional subflow for the current MPTCP session, thecontroller 110 may look up the mapping table of the identification information and the MPTCP session, so as to find the identification information of theserver 302 and place it in the request for establishing the additional subflow of the MPTCP session. It should be noted that although only onecontroller 110 is shown in fig. 1 and 2 for controlling thetransceiver 101 and thetransceiver 102, thetransceiver 101 and thetransceiver 102 may be controlled by different controllers. Those skilled in the art will understand that, for two different controllers, the mapping relationship between the identification information of theserver 302 and the current MPTCP session should be shared, for example, the UE may locally cache the correspondence relationship between the MPTCP session and the server identification information, so as to be used when generating the carrying server identification when subsequently establishing other sub-streams of the MPTCP session and normally performing the MPTCP session to send TCP data packets.

The identification information of theserver 302 is used in the establishment of additional subflows of the MPTCP session initiated by thetransceiver 102. The establishment of the additional sub-streams of the MPTCP session takes the form of a four-way handshake, which is very similar to the three-way handshake described above.

First, in step 213, thetransceiver 102 sends a request message, which may also be a SYN message, to establish a second connection of the MPTCP session, i.e. to establish an additional subflow of the MPTCP session. The SYN message carries an MP-JOIN option, which includes a token of theserver 302 and is used to indicate that the additional sub-stream and the first sub-stream of the MPTCP session belong to the same MPTCP session. According to an embodiment of the present application, the SYN message must also carry identification information of theserver 302.

In step 214, after theload balancing instance 202 receives the SYN packet, it parses the SYN packet to obtain the identification information of theserver 302, and determines the forwarding object of the SYN packet by searching the static forwarding rule table. The static forwarding rule table includes a mapping relationship between the identification information of theserver 302 and an IP (Internet Protocol) address of theserver 302.

As described above, theload balancing instances 201 and 202 may be the same instance, or two instances in the same load balancing device, or two instances in different load balancing devices. The load balancing device may be an independent load balancing device, or may be a group of main and standby load balancing devices, and when the main load balancing device fails, the standby load balancing device performs load balancing, and the configuration between the main and standby load balancing devices is maintained consistent. Those skilled in the art will appreciate that the static forwarding rule table described above should be shared or configured consistently for two different load balancing instances.

As shown instep 215 in fig. 2, according to the IP address corresponding to the server identification information found in the static forwarding rule table, theload balancing instance 202 forwards the SYN packet to the server corresponding to the IP address.

Assuming that the IP address corresponding to the identification information of theserver 302 is found to be 192.0.0.2 according to the static forwarding rule table, theload balancing instance 202 forwards the SYN packet to the server corresponding to the IP address 192.0.0.2, i.e., theserver 302.

It should be noted that the IP address of the server described herein may be a public network address or a private network address, which is not limited in this application. Moreover, if the static forwarding rule table further includes the other mapping relationships related to the routing information, the load balancing instance may forward based on a Network Address Translation (NAT) technique, so as to ensure that the SYN packet reaches the corresponding server that establishes the first sub-flow of MPTCP.

For example, the load balancer supports NAT natively, configures the load balancing instance, configures the public network IP (e.g., public network IP1) and the type of service to be load balanced (protocol type and port, e.g., HTTP, corresponding to port 43), providing NAT processing for the private network servers of the server resource pool.

The process of the terminal (assuming that its IP is public IP2) accessing the MPTCP server with IP address of private IP1 via the load balancer with IP address of public IP1 is as follows:

the terminal accesses the MPTCP server, and the quintuple information carried by the corresponding TCP message (which can be a TCP Sync message or a TCP data message) is as follows:

and (3) source IP:public network IP 2; destination IP:public network IP 1; source port: port2 (a locally randomly assigned free Port); destination port: 43; protocol type: TCP (Transmission control protocol)

After receiving a TCP (destination port 43) message of a terminal accessing an MPTCP server, a load balancer inquires whether the TCP message carries a server identifier, and if the TCP message does not carry the server identifier, one server in an MPTCP server resource pool is selected according to the existing hash scheme (such as quintuple hash); if the TCP message carries the server identification, the static forwarding rule table is directly inquired according to the server identification carried by the TCP message to obtain the IP address of the corresponding MPTCP server. It is assumed here that theMPTCP server 1 corresponding to the private network IP1 is selected. The load balancer modifies message TCP header and IP header, and the message TCP header and IP header are re-packaged and then are forwarded to theMPTCP server 1 through routing. The modified five-tuple information of the TCP message is as follows:

and (3) source IP:public network IP 1; destination IP:private network IP 1; source port:port 2; destination port: 43; protocol type: TCP.

After receiving the TCP packet converted by the NAT, theMPTCP server 1 finds that the packet is a local packet, processes the local packet, and replies a packet (for example, a TCP Ack/Syn-Ack packet), and the carried quintuple information is as follows:

and (3) source IP:private network IP 1; destination IP:public network IP 2; source port: 43; destination port:port 2; protocol type: TCP (Transmission control protocol)

The load balancer receives the TCP message replied by theMPTCP server 1, inquires the NAT mapping table according to the source IP, knows that the new source IP is the public network IP1, modifies the message TCP head and the IP head, re-encapsulates the message TCP head and the IP head, and forwards the message to the terminal through the route.

The modified five-tuple information of the TCP message is as follows:

and (3) source IP:public network IP 1; destination IP:public network IP 2; source port: 43; destination port:port 2; protocol type: TCP.

As described above, the second connection established by thetransceiver 102 belongs to the same MPTCP session as the first connection established by thetransceiver 101. Those skilled in the art can understand that, when thetransceiver 102 establishes the second connection, thecontroller 110 of the UE100 needs to determine whether it belongs to the same MPTCP session as the first subflow of the MPTCP established by thetransceiver 101, and if it belongs to the same MPTCP session, the request message for establishing the second connection in step 213 will carry the relevant field options and the identification information of theserver 302; if the sessions do not belong to the same MPTCP session, the related field options and the identification information of theserver 302 are not carried, and at this time, after receiving the request message for establishing the connection, the load balancing establishes the connection according to a three-way handshake manner, that is, the manner described in theabove step 210 and 212, which is not described herein again.

Next, atstep 216,server 302 issues a response message, which may be a SYN/ACK message, to the received SYN message. The SYN/ACK message may carry an MP-JOIN option that includes authentication information forserver 302.

In step 217, for the SYN/ACK response message sent by the server, thetransceiver 102 sends an acknowledgement message to establish an additional subflow of the MPTCP session, which is an ACK message. Similarly, the ACK message carries the MP-JOIN option including the authentication information of the UE 100.

Finally, in step 218, for the ACK message from thetransceiver 102, theserver 302 also sends out an acknowledgement message to establish an additional sub-stream of the MPTCP session, which is also an ACK message to acknowledge the ACK message sent by the transceiver in step 217.

It should be noted that, insteps 216, 217, and 218, the SYN/ACK or ACK message sent between thetransceiver 102 and theserver 302 is forwarded via theload balancing instance 202, which is not shown in fig. 2 and is not described herein again.

In the above, the establishment of the additional sub-flow of the MPTCP session is realized by means of four-way handshake. Similarly, after the additional substream of MPCTP is successfully established, data transmission may also be performed between thetransceiver 102 of the UE100 and theserver 302. The data transmission process is a normal TCP data transmission process, which is not shown in fig. 2 and is not described herein again.

With the method for load balancing according to an embodiment of the present application described above with reference to fig. 2, multiple sub-flows of an MPTCP session are established based on a static forwarding rule table of mapping relationship between identification information of a server and an IP address. Since the identification information of the server is independent of the MPTCP session, and remains unchanged during the lifetime of providing the service, the method of load balancing according to the present application can more efficiently and reliably establish the multiple subflows of the MPTCP session compared to the prior art load balancing.

Next, a flow of an MPTCP load balancing method for a load balancing apparatus according to an embodiment of the present application will be described with reference to fig. 3.

In step 301, a request message for a UE to establish a first connection of an MPTCP session is received. The first connection of the MPTCP session, i.e. the first subflow of the MPTCP session, is described here. The request message is typically a SYN message. The SYN message carries an MP-CAPABLE option, and the MP-CAPABLE option is used for indicating that the user equipment supports MPTCP connection. Typically, the MP-CAPABLE option also contains the Key of the user device.

Instep 302, load balancing selects a server to establish a first connection with the UE according to a request message of the UE for establishing the first connection of the MPTCP session.

The request message for the first connection is forwarded by the load balancing instance. The load balancing example may forward the load through a hash algorithm or other random distribution algorithm based on a quintuple, which is not specifically limited in this application.

And then, after receiving the SYN message which is forwarded in a load balancing manner and carries the MP-CAPABLE option from the UE, the server sends out a response message. In step 303, the load balancing receives the response message from the server and forwards the response message to the UE.

The response message of the server referred to herein is a SYN/ACK message, i.e., a handshake acknowledgement message. Similarly, the SYN/ACK message carries an MP-CAPABLE option, which is used to indicate that the server supports MPTCP connection. Typically, the MP-CAPABLE option also includes a Key (Key) of the server. After receiving the SYN/ACK message from the server, the UE sends an acknowledgement message.

According to the load balancing method of the present application, the SYN/ACK message also carries identification information (Server ID) of the Server for establishing an additional sub-flow of the MPTCP session. The identification information may be any identification of the server unrelated to the MPTCP session, such as a Universal Unique Identifier (UUID), or a Unique sequence number or a Globally Unique Identifier (GUID) such as 1, 2, 3 … ….

In step 304, the load balancing receives an acknowledgement message from the UE and forwards to the responding server. The acknowledgement message is an ACK message, and usually, the ACK message needs to carry an MP-CAPABLE option, and the MP-CAPABLE option includes the Key of the UE and the Key of the server.

Here, step 301-.

It should be noted that after the first substream of the MPCTP session is successfully established, data transmission can be performed between the UE and the server. The data transmission process is a normal TCP data transmission process, and is not described herein again.

After the first subflow of the MPTCP session is successfully established between the UE and the server, an additional subflow establishment procedure of the MPTCP session is initiated between the UE and the server.

Instep 305, the UE sends a request message, which may also be a SYN message, to establish a second connection of the MPTCP session, i.e. to establish an additional subflow of the MPTCP session. The SYN message carries an MP-JOIN option, which includes a token of the server and is used to indicate that the additional sub-stream and the first sub-stream of the MPTCP session belong to the same MPTCP session. According to an embodiment of the present application, the SYN message must also carry identification information of the server. As described above, the UE may locally cache the correspondence between the MPTCP session and the server identification information, so as to be used when generating the server identification when subsequently establishing other subflows of the MPTCP session and normally performing the MPTCP session to send the TCP data packet.

Corresponding to step 213 in fig. 2 above, the second connection to establish the MPTCP session is initiated by another transceiver than the transceiver establishing the first subflow of the MPTCP session. In an embodiment of the present application, the first subflow of an MPTCP session is established initiated by thetransceiver 101 of the UE100, while the additional subflows of an MPTCP session are established initiated by thetransceiver 102 of the UE 100.

Next, in step 306, after the load balancing receives the SYN message described instep 305, the SYN message needs to be parsed. As described above, in order to ensure that additional subflows of the same MPTCP session are successfully established between thetransceiver 102 of the UE100 and theserver 302, the SYN message also carries identification information of theserver 302.

In the case that the load balancing obtains the identification information of the server by analyzing the SYN packet, that is, in the case that the determination result in step 306 is yes, step 307 is executed, and the load balancing determines the forwarding object of the SYN packet by searching the static forwarding rule table. The static forwarding rule table includes a mapping relationship between identification information of the server and an IP (Internet Protocol) address of the server.

In one example, the static forwarding rule table may be stored in the load balancing device of the load balancing example, or may be stored in another server or memory in communication with the load balancing device, such as a cloud server.

In one example, the static forwarding rule table may be configured manually or automatically according to a control protocol. For example, in the LB server resource pool configuration, in addition to configuring the IP of each backend server, an identifier corresponding to each server is also configured, and the configured server identifier is to be consistent with the identifier of the backend server itself. The LB server may retrieve the static forwarding rule table for load balancing of the server private network IP based on the server identity.

In one example, the static forwarding rule table may also include a mapping relationship on the communication link that is associated with the routing information.

As described above, in an embodiment of the present application, the first connection and the second connection of the MPTCP session are forwarded by theload balancing instances 201 and 202, respectively, where theload balancing instances 201 and 202 may be the same instance, or two instances in the same load balancing device, or may be located in two different load balancing devices, respectively. The load balancing device may be an independent load balancing device, or may be a group of main and standby load balancing devices, and when the main load balancing device fails, the standby load balancing device performs load balancing, and the configuration between the main and standby load balancing devices is maintained consistent. Those skilled in the art will appreciate that the static forwarding rule table described above should be shared or configured consistently for two different load balancing instances.

As instep 215 in fig. 2, in step 308, according to the IP address corresponding to the server identification information found in the static forwarding rule table, the load balancing example forwards the SYN packet to the server corresponding to the IP address.

In the example according to the present application, assuming that the IP address corresponding to the identification information of theserver 302 is found to be 192.0.0.2 according to the static forwarding rule table, the load balancing example 202 forwards the SYN packet to the server corresponding to the IP address 192.0.0.2, that is, theserver 302.

It should be noted that the IP address of the server described herein may be a public network address or a private network address, which is not limited in this application. Moreover, if the static forwarding rule table further includes the other mapping relationships related to the routing information, the load balancing instance may forward based on a Network Address Translation (NAT) technique, so as to ensure that the SYN packet reaches the corresponding server that establishes the first sub-flow of MPTCP.

Next, atstep 309,server 302 sends out a response message for the received SYN message, which may be a SYN/ACK message. The SYN/ACK message may carry an MP-JOIN option that includes authentication information forserver 302. The SYN/ACK packet is received by load balancing and forwarded to the UE.

Instep 310, for the SYN/ACK response message sent by the server,transceiver 102 sends an acknowledgement message to establish an additional subflow of the MPTCP session, which is an ACK message. Similarly, the ACK message carries the MP-JOIN option including the authentication information of the UE 100. The ACK packet is received by load balancing and forwarded toserver 302.

Finally, instep 311, for the ACK message from thetransceiver 102, theserver 302 also sends out an acknowledgement message for establishing an additional sub-stream of the MPTCP session, which is also an ACK message for acknowledging the ACK message sent by the transceiver instep 310. Likewise, the load balancing receives the ACK message and forwards it to the UE 100.

In the above, the establishment of the additional sub-flow of the MPTCP session is realized by means of four-way handshake. Similarly, after the additional substream of MPCTP is successfully established, data transmission may also be performed between thetransceiver 102 of the UE100 and theserver 302. The data transmission process is a normal TCP data transmission process, and is not described herein again.

It should be noted that, in step 306, after the load balancing receives the SYN message described instep 305, the SYN message needs to be parsed. If the load balancing does not obtain the identification information of the server by analyzing the SYN message, that is, if the determination result of step 306 is no, it indicates that the request message of the second connection sent from thetransceiver 102 does not include the identification information of theserver 302, that is, it means that the second connection requested to be established by thetransceiver 102 does not belong to the same MPTCP session as the first connection of the MPTCP session established by thetransceiver 101. At this point, load balancing proceeds to step 312.

For a connection request that does not include server identification information, load balancing may be regarded as a request for establishing a first sub-flow belonging to another MPTCP session, and then processing is performed according to step 210 and step 212 shown in fig. 2 or step 301 and step 304 shown in fig. 3, that is, forwarding is performed according to a token of the session by using a quintuple hash algorithm or other random distribution algorithms, which is not described herein again.

Fig. 4 is a diagram of an MPTCP option carrying server identification information according to an embodiment of the present application. As shown in fig. 4, the MPTCP option includes fields of a genre (kidd), a Length (Length), and a Subtype (Subtype). Wherein, The kid field indicates that The header option is MPTCP header option, and The value is 30, which is allocated by IANA (The Internet Assigned Numbers Authority). The Length field indicates the Length of the header option. Subtype indicates the Subtype of this MPTCP option, typically four bytes, and there are detailed provisions in the RFC8684 standard of IESG (Internet Engineering Group) for different subtypes, e.g., 0x0 for MP-CAPABLE and 0x1 for MP-JOIN.

In the example according to the present application, Subtype is defined as MP-LB-advertise option, indicating carrying the identification information of the server. As a newly defined option, the value of Subtype can be any one of 0x9-0xe that has not been specified in the existing standard. In addition, as shown in fig. 4, the identification information of the server is located in the last 8 bytes of the MPTCP option, but it can be understood by those skilled in the art that the identification information of the server can be set to other lengths such as 4 bytes as needed, and if the server UUID is used, the IP option needs to be separately extended, which is not specifically limited in the embodiment of the present application.

Next, an MPTCP load balancing method for a user equipment according to the present application will be explained with reference to fig. 5.

Instep 501, the UE transmits a request message for establishing a first connection of an MPTCP session to the server. As withstep 210 of fig. 2, the UE100 sends a request message, which may be a SYN message, to the server through thetransceiver 101 to establish the first connection of the MPTCP session, i.e., the first subflow of the MPTCP session. The SYN message carries an MP-CAPABLE option, which is used to indicate that the UE100 supports MPTCP connection. Typically, the MP-CAPABLE option also includes a Key (Key) of the UE 100.

Next, in step 502, the UE receives a response message from the server. As described above, theserver 302 sends a response message after receiving the SYN message carrying the MP-CAPABLE option from the UE 100. The response message is a SYN/ACK message, i.e., a handshake acknowledgement message. Similarly, the SYN/ACK message carries an MP-CAPABLE option, which is used to indicate that theserver 302 supports MPTCP connection. Typically, the MP-CAPABLE option also includes a Key (Key) for theserver 302.

In order to solve the problem that load balancing may not be achieved when the same MPTCP is forwarded by different LBs in the prior art, according to the load balancing method of the present application, the SYN/ACK message also carries identification information (Server ID) of theServer 302 for establishing an additional sub-flow of the MPTCP session. The identification information may be any identification of the server unrelated to the MPTCP session, such as a Universal Unique Identifier (UUID), or a Unique sequence number or a Globally Unique Identifier (GUID) such as 1, 2, 3 … ….

In step 503, UE100 sends an acknowledgement message after receiving the SYN/ACK message fromserver 302. The acknowledgement message is an ACK message, and usually, the ACK message needs to carry an MP-CAPABLE option, and the MP-CAPABLE option includes the Key of the UE100 and the Key of theserver 302. To this end, the establishment of the first substream of the MPCTP session is completed between thetransceiver 101 of the UE100 and theserver 302 through a three-way handshake process.

It should be noted that after the first substream of the MPCTP session is successfully established, data transmission can be performed between thetransceiver 101 of the UE100 and theserver 302. The data transmission process is a normal TCP data transmission process, and is not described herein again.

Next, thecontroller 110 of the UE100 generates a request message for establishing the second connection in step 504. This second connection may be the first connection established in the above step, i.e. the first subflow of the MPTCP session belongs to the same MPTCP session, or may be a different session.

Therefore, in step 505, the UE100 needs to make a judgment on the generated request message for the second connection and give a different process to the result of the judgment.

In the case where the determination of step 505 is yes, this indicates thattransceiver 102 is about to establish additional subflows for the same MPTCP session. At this time, thecontroller 110 of the UE100 performs processing to add the identification information of theserver 302 obtained in step 502 above, i.e., step 506 in fig. 5, to the request message for establishing the second connection of the MPTCP session. The request message may also be a SYN message. The SYN message carries an MP-JOIN option, which includes a token of theserver 302 and is used to indicate that the additional sub-stream and the first sub-stream of the MPTCP session belong to the same MPTCP session. As described above, the SYN message must also carry identification information of theserver 302.

As shown in fig. 2, after receiving the SYN packet, theload balancing instance 202 parses the SYN packet to obtain the identification information of theserver 302, and determines the forwarding object of the SYN packet by retrieving the static forwarding rule table. The static forwarding rule table includes a mapping relationship between the identification information of theserver 302 and an IP (Internet Protocol) address of theserver 302. Reference may be made to the related description in fig. 2, and details are not repeated here.

Next, instep 507, the UE100 receives the response message issued by theserver 302. The response message may be a SYN/ACK message. The SYN/ACK message may carry an MP-JOIN option that includes authentication information forserver 302.

In step 508, for the SYN/ACK response message sent by the server, thetransceiver 102 of the UE100 sends an acknowledgement message to establish an additional subflow of the MPTCP session, which is an ACK message. Similarly, the ACK message carries the MP-JOIN option including the authentication information of the UE 100.

Finally, instep 509, for the ACK message from thetransceiver 102, theserver 302 also issues an acknowledgement message to establish an additional subflow of the MPTCP session, which is received by the UE. The acknowledgement message is also an ACK message for acknowledging the ACK message sent by the transceiver in step 217.

In the above, the establishment of the additional sub-flow of the MPTCP session is realized by means of four-way handshake. Similarly, after the additional substream of MPCTP is successfully established, data transmission may also be performed between thetransceiver 102 of the UE100 and theserver 302. The data transmission process is a normal TCP data transmission process, and is not described herein again.

As described in step 504 above, the second connection initiated by thetransceiver 102 of the UE100 may be a different session than the first connection established in the above step, i.e. the first subflow of the MPTCP session. For different MPTCP sessions, the identification information of theserver 302 does not need to be carried in the request message for establishing a connection. Therefore, if the determination in step 505 is negative,step 510 is executed to send a request message for establishing the second connection, in which case the request message for establishing the second connection does not include the identification information of the server obtained in step 502.

After receiving the request message not including the server identification information, the load balancing determines that the request belongs to the establishment request of the first sub-stream of another MPTCP session, and then performs forwarding by using the quintuple hash algorithm or other random allocation algorithm according to the token of the current session, which may specifically refer to the establishment process of the first sub-stream of the MPTCP session shown in step 210-212 of fig. 2 or step 301-304 of fig. 3, and is not described herein again.

Fig. 6 is a flowchart of an MPTCP load balancing method for a server according to an embodiment of the present application.

Specifically, atstep 601, via the load balancing instance 201, theserver 302 in the server resource pool 300 receives a request message for thetransceiver 101 of the UE100 to establish a first connection of the MPTCP session. The request message may be a SYN message. The SYN message carries an MP-CAPABLE option, which is used to indicate that the UE100 supports MPTCP connection. Typically, the MP-CAPABLE option also includes a Key (Key) of the UE 100. Step 601 corresponds tosteps 210, 301 and 501, and will not be described herein.

In step 602, theserver 302 responds to the request message instep 601 to establish the first connection of the MPTCP session. The response message is a SYN/ACK message, i.e., a handshake acknowledgement message. Similarly, the SYN/ACK message carries an MP-CAPABLE option, which is used to indicate that theserver 302 supports MPTCP connection. Typically, the MP-CAPABLE option also includes a Key (Key) for theserver 302.

In order to solve the problem that load balancing may not be achieved when the same MPTCP is forwarded by different LBs in the prior art, according to the load balancing method of the present application, the SYN/ACK message also carries identification information (Server ID) of theServer 302 for establishing an additional sub-flow of the MPTCP session. The identification information may be, for example, a Universally Unique Identifier (UUID), or may be a Unique sequence number or a Globally Unique Identifier (GUID) such as 1, 2, 3 … …. Step 602 corresponds tosteps 211, 303, and 502 described above, and will not be described herein.

Next, instep 603, the load balancing receives an acknowledgement message from the UE and forwards it to thecorresponding server 302. The acknowledgement message is an ACK message, and usually, the ACK message needs to carry an MP-CAPABLE option, and the MP-CAPABLE option includes the Key of the UE and the Key of the server. Step 603 corresponds tosteps 212, 304 and 503, which are not described herein again.

Thus, in step 601-603, the establishment of the first sub-stream of the MPCTP session is completed between the UE and the server through the three-way handshake process. Likewise, after the first substream of MPCTP is successfully established, data transmission may be performed between thetransceiver 101 of the UE100 and theserver 302. The data transmission process is a normal TCP data transmission process, and is not described herein again.

The server may receive a request message from the UE to establish a second connection at step 604. As described above, thecontroller 110 of the UE100 may generate a request message for establishing the second connection. This second connection may be the first connection established instep 601 and 603 above, i.e. the first subflow of the MPTCP session belongs to the same MPTCP session, or may be a different session. The difference is that if the second connection and the first connection belong to the same MPTCP session, the request message for establishing the second connection carries the identification information of theserver 302 sent in step 602; if the connection does not belong to the same MPTCP session, the request message for establishing the second connection does not carry the identification information of theserver 302.

Next, the load balancing instance will do different processing for different request messages for establishing the second connection. If the request message carries the identification information of theserver 302, the request message is forwarded to theserver 302 accordingly. If the identification information of theserver 302 is not carried, the request message for establishing the second connection is forwarded via the load balancing instance by a conventional, e.g. quintuple hash algorithm or other random assignment algorithm. Therefore, in step 605, the server performs different processing on the request message of the second connection carrying the server identifier.

Instep 606, theserver 302 receives the second connection request message carrying the identification information of theserver 302 forwarded by theload balancing instance 202, and sends a response message to the request message. The response message may be a SYN/ACK message. The SYN/ACK message may carry an MP-JOIN option that includes authentication information forserver 302.

Instep 607, for the SYN/ACK response message sent by the server instep 606, thetransceiver 102 of the UE100 sends an acknowledgement message to establish an additional subflow of the MPTCP session, which is an ACK message. Similarly, the ACK message carries the MP-JOIN option including the authentication information of the UE 100.

Finally, for the ACK message from thetransceiver 102, theserver 302 also issues an acknowledgement message to establish an additional subflow of the MPTCP session, which is received by the UE, step 608. The acknowledgement message is also an ACK message for acknowledging the ACK message sent by the transceiver instep 607.

In the above, the establishment of the additional sub-flow of the MPTCP session is realized by means of four-way handshake. Similarly, after the additional substream of MPCTP is successfully established, data transmission may also be performed between thetransceiver 102 of the UE100 and theserver 302. The data transmission process is a normal TCP data transmission process, and is not described herein again.

If the request message sent by thetransceiver 102 of the UE100 for establishing the second connection does not include the identification information of theserver 302 in step 604, the request message for the second connection may be forwarded by theload balancing instance 202 to any server in the server resource pool 300, such as the server 301 or 303. At this time, the server 301 or 303 sends a response carrying its identification information for the request message of the second connection. This process is similar to MPTCP and the first subflow for establishing an MPTCP session, which may specifically refer tosteps 211, 303, or 502 described above, and will not be described herein again.

With the above method for load balancing according to one embodiment of the present application explained with reference to fig. 2 to fig. 6, a plurality of sub-flows of an MPTCP session are established based on a static forwarding rule table of mapping relationship between identification information of a server and an IP address. Since the identification information of the server is independent of the MPTCP session and remains unchanged during the lifetime of providing the service, the method for load balancing according to the present application can more efficiently and reliably establish the multiple sub-streams of the MPTCP session compared to the prior art load balancing.

The method embodiments of the present application may be implemented in software, magnetic, firmware, etc.

Program code may be applied to input instructions to perform the functions described herein and generate output information. The output information may be applied to one or more output devices in a known manner. For purposes of this application, a processing system includes any system having a processor such as, for example, a Digital Signal Processor (DSP), a microcontroller, an Application Specific Integrated Circuit (ASIC), or a microprocessor.

The program code may be implemented in a high level procedural or object oriented programming language to communicate with a processing system. The program code can also be implemented in assembly or machine language, if desired. Indeed, the mechanisms described herein are not limited in scope to any particular programming language. In any case, the language may be a compiled or interpreted language.

One or more aspects of at least one embodiment may be implemented by representative instructions stored on a computer-readable storage medium, which represent various logic in a processor, which when read by a machine causes the machine to fabricate logic to perform the techniques described herein. These representations, known as "IP cores" may be stored on a tangible computer-readable storage medium and provided to a number of customers or manufacturing facilities to load into the manufacturing machines that actually make the logic or processor.

While the description of the present application will be described in conjunction with the preferred embodiments, it is not intended that the features of the present application be limited to this embodiment. Rather, the invention has been described in connection with embodiments for the purpose of covering alternatives and modifications as may be extended based on the claims of the present application. In the following description, numerous specific details are included to provide a thorough understanding of the present application. The present application may be practiced without these particulars. Moreover, some of the specific details have been omitted from the description in order to avoid obscuring or obscuring the focus of the present application. It should be noted that the embodiments and features of the embodiments in the present application may be combined with each other without conflict.

Further, various operations will be described as multiple discrete operations, in a manner that is most helpful in understanding the illustrative embodiments; however, the order of description should not be construed as to imply that these operations are necessarily order dependent. In particular, these operations need not be performed in the order of presentation.

As used herein, the term "module" or "unit" may refer to, be, or include: an Application Specific Integrated Circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group) and/or memory that executes one or more software or firmware programs, a combinational logic circuit, and/or other suitable components that provide the described functionality.

In the drawings, some features of the structures or methods are shown in a particular arrangement and/or order. However, it is to be understood that such specific arrangement and/or ordering may not be required. In some embodiments, these features may be arranged in a manner and/or order different from that shown in the illustrative figures. Additionally, the inclusion of structural or methodical features in a particular figure is not meant to imply that such features are required in all embodiments, and in some embodiments, these features may not be included or may be combined with other features.

Embodiments of the mechanisms disclosed herein may be implemented in hardware, software, firmware, or a combination of these implementations. Embodiments of the application may be implemented as computer programs or program code executing on programmable systems comprising multiple processors, a storage system (including volatile and non-volatile memory and/or storage elements), multiple input devices, and multiple output devices.

Program code may be applied to input instructions to perform the functions described herein and generate output information. The output information may be applied to one or more output devices in a known manner. For purposes of this application, a processing system includes any system having a processor such as, for example, a Digital Signal Processor (DSP), a microcontroller, an Application Specific Integrated Circuit (ASIC), or a microprocessor.

The program code may be implemented in a high level procedural or object oriented programming language to communicate with a processing system. The program code can also be implemented in assembly or machine language, if desired. Indeed, the mechanisms described in this application are not limited in scope to any particular programming language. In any case, the language may be a compiled or interpreted language.

In some cases, the disclosed embodiments may be implemented in hardware, firmware, software, or any combination thereof. In some cases, one or more aspects of at least some embodiments may be implemented by representative instructions stored on a computer-readable storage medium, which represent various logic in a processor, which when read by a machine causes the machine to fabricate logic to perform the techniques described herein. These representations, known as "IP cores" may be stored on a tangible computer-readable storage medium and provided to a number of customers or manufacturing facilities to load into the manufacturing machines that actually make the logic or processor.

Such computer-readable storage media may include, but are not limited to, non-transitory tangible arrangements of articles of manufacture or formation by machines or devices that include storage media such as: hard disk any other type of disk including floppy disks, optical disks, compact disk read-only memories (CD-ROMs), compact disk rewritables (CD-RWs), and magneto-optical disks; semiconductor devices such as Read Only Memory (ROM), Random Access Memory (RAM) such as Dynamic Random Access Memory (DRAM) and Static Random Access Memory (SRAM), Erasable Programmable Read Only Memory (EPROM), flash memory, Electrically Erasable Programmable Read Only Memory (EEPROM); phase Change Memory (PCM); magnetic or optical cards; or any other type of media suitable for storing electronic instructions.

Thus, embodiments of the present application also include non-transitory computer-readable storage media that contain instructions or that contain design data, such as Hardware Description Language (HDL), that define the structures, circuits, devices, processors, and/or system features described herein.

Claims (17)

Translated fromChinese

1.一种MPTCP负载均衡方法，用于负载均衡设备，其特征在于，包括1. an MPTCP load balancing method, for load balancing equipment, is characterized in that, comprising接收用户设备(User Equipment，UE)用于请求建立第一MPTCP连接的第一请求消息；receiving a first request message used by a user equipment (User Equipment, UE) for requesting to establish a first MPTCP connection;选择与所述UE建立所述第一MPTCP连接的服务器并将所述第一请求消息发送到所述服务器；selecting a server that establishes the first MPTCP connection with the UE and sending the first request message to the server;接收来自所述服务器的针对所述第一请求消息的第一响应消息，所述第一响应消息包括所述服务器的标识；receiving a first response message from the server to the first request message, the first response message including the identifier of the server;接收所述UE用于请求建立第二MPTCP连接的第二请求消息，和receiving a second request message from the UE for requesting establishment of a second MPTCP connection, and在确定所述第二请求消息包括所述服务器的所述标识的情况下，根据所述服务器的标识查找静态转发规则表，以确定与所述服务器的标识相对应的所述服务器的IP地址，并且将所述第二请求消息转发至所述IP地址对应的所述服务器，其中，In the case where it is determined that the second request message includes the identifier of the server, a static forwarding rule table is searched according to the identifier of the server to determine the IP address of the server corresponding to the identifier of the server, and forward the second request message to the server corresponding to the IP address, wherein,所述静态转发规则表预先配置在所述负载均衡设备中，并且包括所述服务器的标识与所述服务器的IP地址的映射关系。The static forwarding rule table is preconfigured in the load balancing device, and includes a mapping relationship between the identifier of the server and the IP address of the server.2.如权利要求1所述的方法，其特征在于，所述第一MPTCP连接与所述第二MPTCP连接属于同一个MPTCP会话。2. The method of claim 1, wherein the first MPTCP connection and the second MPTCP connection belong to the same MPTCP session.3.如权利要求1或2所述的负载均衡方法，其特征在于，所述服务器的标识包括所述服务器的编号或者UUID(Universally Unique Identifier，UUID)或者全局唯一标识符(Globally Unique Identifier，GUID)。3. The load balancing method according to claim 1 or 2, wherein the identifier of the server comprises the serial number of the server or a UUID (Universally Unique Identifier, UUID) or a Globally Unique Identifier (Globally Unique Identifier, GUID) ).4.如权利要求2或3所述的方法，其特征在于，所述服务器的所述标识与所述MPTCP会话无关。4. The method of claim 2 or 3, wherein the identifier of the server is independent of the MPTCP session.5.如权利要求1-4所述的负载均衡方法，其特征在于，所述响应消息还包括种类(Kind)、长度(Length)、MPTCP选项子类型(Subtype)中的至少一个。5. The load balancing method according to claims 1-4, wherein the response message further comprises at least one of a kind (Kind), a length (Length), and an MPTCP option subtype (Subtype).6.一种MPTCP负载均衡方法，用于用户设备，其特征在于，包括6. An MPTCP load balancing method, used for user equipment, is characterized in that, comprising发送用于请求建立第一MPTCP连接的第一请求消息，sending a first request message for requesting the establishment of a first MPTCP connection,接收来自所述服务器针对所述第一请求消息的第一响应消息，所述第一响应消息包括所述服务器的标识，receiving a first response message from the server to the first request message, where the first response message includes an identifier of the server,向所述服务器发送请求建立第二MPTCP连接的第二请求消息，其中，在确定所述第一MPTCP连接与所述第二MPTCP连接属于同一MPTCP会话的情况下，所述第二请求信息包括所述服务器的所述标识。Send a second request message to the server for requesting to establish a second MPTCP connection, wherein, in the case that it is determined that the first MPTCP connection and the second MPTCP connection belong to the same MPTCP session, the second request message includes all the identifier of the server.7.如权利要求6所述的负载均衡方法，其特征在于，所述服务器的标识包括所述服务器的编号或者UUID(Universally Unique Identifier，UUID)或者全局唯一标识符(GloballyUnique Identifier，GUID)。7 . The load balancing method according to claim 6 , wherein the identifier of the server comprises a serial number of the server, a UUID (Universally Unique Identifier, UUID) or a Globally Unique Identifier (GUID). 8 .8.如权利要求6或7所述的方法，其特征在于，所述服务器的所述标识与所述MPTCP会话无关。8. The method of claim 6 or 7, wherein the identifier of the server is independent of the MPTCP session.9.如权利要求6-8所述的负载均衡方法，其特征在于，所述第一响应消息还包括种类(Kind)、长度(Length)、MPTCP选项子类型(Subtype)中的至少一个。9. The load balancing method according to claims 6-8, wherein the first response message further comprises at least one of a kind (Kind), a length (Length), and an MPTCP option subtype (Subtype).10.如权利要求6-9所述的负载均衡方法，其特征在于，在确定所述第一MPTCP连接与所述第二MPTCP连接不属于同一MPTCP会话的情况下，所述第二请求信息不包括所述服务器的所述标识。10. The load balancing method according to claims 6-9, wherein in the case that it is determined that the first MPTCP connection and the second MPTCP connection do not belong to the same MPTCP session, the second request information does not belong to the same MPTCP session. Including the identification of the server.11.一种MPTCP负载均衡方法，用于服务器，包括11. An MPTCP load balancing method for a server, comprising接收来自用户设备的用于建立第一MPTCP连接的第一请求消息，receiving a first request message for establishing a first MPTCP connection from the user equipment,发送对于所述第一MPTCP连接的第一请求消息的第一响应消息，所述第一响应消息包括所述服务器的标识，sending a first response message to the first request message of the first MPTCP connection, the first response message including the identifier of the server,接收所述用户设备建立所述第一MPTCP连接的确认消息；receiving, by the user equipment, a confirmation message for establishing the first MPTCP connection;接收所述用户设备用于建立第二MPTCP连接的第二请求消息，以及receiving a second request message for establishing a second MPTCP connection by the user equipment, and在确定所述第二请求消息中包括所述服务器的标识的情况下，建立所述第二MPTCP连接。In the case that it is determined that the identifier of the server is included in the second request message, the second MPTCP connection is established.12.如权利要求11所述的负载均衡方法，其特征在于，所述第一MPTCP连接与所述第二MPTCP连接属于同一MPTCP会话。12. The load balancing method according to claim 11, wherein the first MPTCP connection and the second MPTCP connection belong to the same MPTCP session.13.如权利要求11或12所述的负载均衡方法，其特征在于，所述服务器的标识包括所述服务器的编号或者UUID(Universally Unique Identifier，UUID)或者全局唯一标识符(Globally Unique Identifier，GUID)。13. The load balancing method according to claim 11 or 12, wherein the identifier of the server comprises the serial number of the server or a UUID (Universally Unique Identifier, UUID) or a Globally Unique Identifier (Globally Unique Identifier, GUID) ).14.如权利要求11-13所述的方法，其特征在于，所述服务器的所述标识与所述MPTCP会话无关。14. The method of claims 11-13, wherein the identification of the server is independent of the MPTCP session.15.如权利要求11-15所述的负载均衡方法，其特征在于，所述第一响应消息和所述第二响应消息还包括种类(Kind)、长度(Length)、MPTCP选项子类型(Subtype)中的至少一个。15. The load balancing method according to claims 11-15, wherein the first response message and the second response message further comprise a kind (Kind), a length (Length), an MPTCP option subtype (Subtype) ) at least one of them.16.一种机器可读介质，其特征在于，在所述介质上存储有指令，当所述指令在所述机器上运行时，使得所述机器执行权利要求1至15中任意一项所述的方法。16. A machine-readable medium, wherein instructions are stored on the medium, and when the instructions are executed on the machine, the instructions cause the machine to execute the machine described in any one of claims 1 to 15. Methods.17.一种设备，其特征在于，包括：17. A device, characterized in that, comprising:处理器；processor;存储器，在所述存储器上存储有指令，当所述指令被所述处理器运行时，使得所述用户设备执行权利要求1至15中任意一项所述的方法。A memory having instructions stored on the memory which, when executed by the processor, cause the user equipment to perform the method of any one of claims 1 to 15.

Images