WO2015171023A1 - Établissement de connexion tcp à trajets multiples (mptcp) - Google Patents

Établissement de connexion tcp à trajets multiples (mptcp) Download PDF

Info

Publication number
WO2015171023A1
WO2015171023A1 PCT/SE2014/050551 SE2014050551W WO2015171023A1 WO 2015171023 A1 WO2015171023 A1 WO 2015171023A1 SE 2014050551 W SE2014050551 W SE 2014050551W WO 2015171023 A1 WO2015171023 A1 WO 2015171023A1
Authority
WO
WIPO (PCT)
Prior art keywords
mptcp
server
tcp
address
client device
Prior art date
Application number
PCT/SE2014/050551
Other languages
English (en)
Inventor
Robert Skog
Original Assignee
Telefonaktiebolaget L M Ericsson (Publ)
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget L M Ericsson (Publ) filed Critical Telefonaktiebolaget L M Ericsson (Publ)
Priority to PCT/SE2014/050551 priority Critical patent/WO2015171023A1/fr
Publication of WO2015171023A1 publication Critical patent/WO2015171023A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/14—Multichannel or multilink protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers

Definitions

  • the invention relates to a method of a client device for establishing a
  • MPTCP Multipath Transmission Control Protocol
  • TCP/IP Transmission Control Protocol and Internet Protocol
  • GSM Global System for Mobile Communications
  • UMTS Universal Mobile Telecommunications System
  • LTE Long Term Evolution
  • WLAN Wireless Local Area Network
  • WiFi Wireless Local Area Network
  • MPTCP is an ongoing effort of the lETF's Multipath TCP working group which aims at allowing an end-to-end TCP connection to use multiple paths to maximize resource usage and increase redundancy (see, e.g., RFC 6824, http://tools.ietf.org/html/rfc6824).
  • MPTCP modifies TCP so that it presents a standard TCP interface to applications, while in fact spreading data across several subflows, i.e., separate TCP connections using distinct network paths.
  • MPTCP is designed to be backwards compatible with plain TCP.
  • MPTCP is particularly useful in the scenario described above, i.e., a mobile terminal using both a WiFi network and a mobile network, as is illustrated in Figs. 1 and 2.
  • subflows, or links may be added or dropped as the mobile terminal moves in or out of coverage without disrupting the end-to-end TCP connection. That is, with reference to Fig.
  • a client device 101 may setup radio links with both the mobile network 1 1 1 and the WiFi network 1 12 and establish an MPTCP connection with at least two subflows, a first MPTCP subflow 121 utilizing a path through mobile network 1 1 1 and a second MPTCP subflow 122 utilizing a path through WiFi network 1 12.
  • the problem of subflow handover is solved by abstraction in the transport layer, without any special mechanisms at the network or link level.
  • MPTCP-enabled applications which are executed in client devices, such as client device 101 in Fig. 1 , are known which are adapted for using MPTCP for connecting to an MPTCP-capable origin server 103, as is illustrated in Fig. 1 .
  • This approach requires that the origin server itself is capable of using
  • MPTCP MPTCP.
  • An example of such application is Apple's voice control application Siri which is shipped with iOS7.
  • MPTCP proxy servers or simply MPTCP proxies, such as MPTCP proxy 202 shown in Fig. 2, which are deployed by an operator of a mobile network, such as mobile network 21 1 .
  • mobile network operators which deploy an MPTCP proxy in their network need to ensure that packets transmitted via all subflows find their way to the MPTCP proxy (subflows 221 and 222 in Fig. 2). This may be achieved by integrating additional access networks, such as WiFi network 212, via the S2a
  • the S2a interface is, e.g., described in 3GPP TR 23.852.
  • 3GPP 3rd Generation Partnership Project
  • a method of a client device for establishing an MPTCP connection comprises receiving a request for establishing a TCP connection with an origin server, and transmitting an MPTCP connection request to a proxy server.
  • the request for establishing a TCP connection with an origin server is received from an application being executed in the client device.
  • the MPTCP connection request comprises an address of the origin server.
  • a method of a proxy server for establishing an MPTCP connection comprises receiving an MPTCP connection request comprising an address of an origin server, extracting the address of the origin server from the MPTCP connection request, and transmitting a TCP connection request to the origin server.
  • the MPTCP connection request is received from a client device.
  • a computer program comprising computer-executable instructions.
  • the computer- executable instructions cause a device to perform the method according to an embodiment of the first or the second aspect of the invention, when the computer-executable instructions are executed on a processing unit comprised in the device.
  • a computer program product comprising a computer-readable storage medium.
  • the computer-readable storage medium has the computer program according to the third aspect of the invention embodied therein.
  • a client device for establishing an MPTCP connection comprises means configured for receiving a request for establishing a TCP connection with an origin server, and transmitting an MPTCP connection request to a proxy server.
  • the means are configured for receiving the request for establishing a TCP connection with an origin server from an application being executed in the client device.
  • the MPTCP connection request comprises an address of the origin server.
  • a proxy server for establishing an MPTCP connection.
  • the proxy server comprises means configured for receiving an MPTCP connection request comprising an address of an origin server, extracting the address of the origin server from the MPTCP connection request, and transmitting a TCP connection request to the origin server.
  • the means are configured for receiving the MPTCP connection request from a client device.
  • the invention makes use of an understanding that usage of MPTCP may be improved by providing a proxy server, in the following also referred to as MPTCP proxy, which can be reached by client devices attempting to setup an MPTCP connection utilizing a network path outside the network in which the MPTCP proxy is deployed.
  • MPTCP proxy in the following also referred to as MPTCP proxy
  • this applies to scenarios where the client devices has access to a first communications network which is a mobile network, such as GSM, UMT, or LTE, and additionally can access a second communications network, such as a WiFi network.
  • a client device can establish an end-to-end TCP connection with an origin server by setting up an MPTCP connection with an MPTCP proxy rather than the origin server, and by providing the MPTCP proxy with the address of the origin server, thereby allowing the MPTCP proxy to establish a standard TCP connection with the origin server.
  • the end-to-end TCP connection is transparently carried over two legs.
  • the first leg is the MPTCP connection between the client device and the MPTCP proxy
  • second leg is the TCP connection between the MPTCP proxy and the origin server.
  • the address of the origin server is included into an MPTCP connection request transmitted by the client device to the MPTCP proxy, as is described further below.
  • Embodiments of the invention are advantageous in that client devices can establish MPTCP connections utilizing network paths which are outside the network where the MPTCP proxy is deployed. Thereby, usage of MPTCP is improved.
  • the transmitting the MPTCP connection request comprises transmitting a TCP SYN packet for at least one MPTCP subflow.
  • the address of the origin server is comprised in the TCP Options of the TCP SYN packet of the first subflow of the at least one MPTCP subflow. This is advantageous in that the MPTCP proxy can establish the TCP connection with the origin server directly after the first MPTCP subflow has been established.
  • the address of the origin server may be comprised in the TCP Options of the TCP SYN packet of an additional subflow which is established later on.
  • the address of the origin server may be comprised in the TCP Options of the TCP SYN packets transmitted for several or even all subflows.
  • Fig. 1 illustrates a known solution for establishing an MPTCP connection with an MPTCP-enabled server.
  • Fig. 2 illustrates a known solution for establishing an MPTCP connection with an MPTCP proxy.
  • Fig. 3 shows the MPTCP protocol stack, in accordance with an embodiment of the invention.
  • Fig. 4 illustrates establishing an MPTCP connection with an MPTCP proxy, in accordance with an embodiment of the invention.
  • Fig. 5 shows a TCP header and the MPTCP Option format, in accordance with an embodiment of the invention.
  • Fig. 6 illustrates establishing an MPTCP connection, in accordance with an embodiment of the invention.
  • Fig. 7 shows a method of a client device for establishing an MPTCP connection, in accordance with an embodiment of the invention.
  • Fig. 8 shows a method of a proxy server for establishing an MPTCP connection, in accordance with an embodiment of the invention.
  • Fig. 9 shows a client device for establishing an MPTCP connection, in accordance with an embodiment of the invention.
  • Fig. 10 shows a client device for establishing an MPTCP connection, in accordance with another embodiment of the invention.
  • Fig. 1 1 shows a mobile terminal, in accordance with an embodiment of the invention.
  • Fig. 12 shows a proxy server for establishing an MPTCP connection, in accordance with an embodiment of the invention.
  • Fig. 13 shows a proxy server for establishing an MPTCP connection, in accordance with another embodiment of the invention.
  • a client device may be any device capable of effecting communications with an origin server providing content to the client device, such as a web server, an email server, a media server, a node of a Content Distribution Network (CDN), or the like.
  • the client device may be a mobile terminal, a User Equipment (UE), a mobile phone, a smart phone, a tablet, or a personal computer.
  • Communications between the client device and the origin server may be effected though one or more communications networks, wired or wireless, or a combination thereof.
  • a communications network may be any one of a mobile
  • communications network such as GSM, UMTS, LTE, or WiMAX
  • LAN Local Area Network
  • WLAN Wireless Fidelity
  • Ethernet Ethernet
  • corporate network or the Internet.
  • MPTCP aims at allowing an end-to-end TCP connection to utilize multiple network paths between two nodes, throughout this disclosure referred to as client device and origin server, or simply client and server, respectively, to maximize resource usage and increase redundancy. This is achieved by modifying TCP such that it presents a standard TCP interface to applications (such as application 301 illustrated as uppermost layer of the MPTCP protocol stack shown in Fig. 3) requesting an end-to-end TCP connection, while in fact spreading data across several subflows, i.e., separate TCP connections (TCPi 314 and TCP 2 324 in Fig. 3) using distinct network paths.
  • applications such as application 301 illustrated as uppermost layer of the MPTCP protocol stack shown in Fig. 3
  • the standard TCP stack is modified by providing an additional MPTCP layer 303, which acts as an interface for providing a single end-to- end connection, and which combines a plurality of TCP connections 314/324, each TCP connection 314/324 having their own stack towards lower layers, i.e., IP 1 315 and L1 /L2 1 316 for TCP 1 314, and IP 2 325 and L1 /L2 2 326 for TCP 2 314, respectively.
  • an MPTCP connection may combine any number of subflows other than two, including one.
  • a path is a sequence of links between the client device and the origin server, defined in this context by a four-tuple of source and destination address/port pairs, as is known in the art of TCP/IP.
  • a subflow is a flow of TCP segments operating over an individual path, which forms part of a larger MPTCP connection. A subflow is started and
  • an MPTCP connection is a set of one or more subflows, over which an application can communicate between the client device and the origin server.
  • MPTCP will behave similar to standard TCP, but extended Application Programming Interfaces (APIs) may provide additional control to MPTCP- aware applications 301 .
  • Application 301 which is executed in the user plane of the client device's operating system, begins by opening a TCP socket 302. MPTCP signaling and operation are handled by the MPTCP implementation, which is represented as MPTCP layer 303 in Fig. 3.
  • client 101 may setup, and use simultaneously, radio links with both mobile network 1 1 1 and WiFi network 1 12.
  • An MPTCP connection between client 101 and MPTCP- capable server 103 begins similarly to a regular TCP connection.
  • client 101 may first establish the MPTCP subflow 121 utilizing a path through mobile network 1 1 1 .
  • the signaling is identical to that as for initiating a normal TCP connection by performing a three-way handshake, as is known in the art, but the SYN, SYN/ACK, and ACK packets also carry additional information indicating that client 101 is MPTCP capable (MPTCP Option "MP_CAPABLE", as is described further below).
  • second MPTCP subflow 122 utilizing a path through WiFi network 1 12, may be setup and combined with subflow 121 .
  • Establishing additional subflows begins in the same way as initiating a normal TCP connection, performing the three-way handshake, but the SYN, SYN/ACK, and ACK packets also carry additional information indicating that this TCP connection is an additional connection which should be combined into an MPTCP connection at both client 101 and server 103 (MPTCP Option "MP_JOIN", as is described further below).
  • MP_JOIN MPTCP Option
  • Setting up and combining additional connections with already existing subflows may require keys which are exchanged during a handshake procedure which is described in
  • MPTCP is designed as an extension to plain TCP.
  • a number of MPTCP Options are defined in RFC 6824 for the purpose of signaling MPTCP operations. All MPTCP operations are signaled as variable-length options using the optional Options" field of TCP header 500 shown in Fig. 5 (in the following referred to as TCP Options), the format 501 of which is also illustrated.
  • TCP Options has been assigned by the Internet Assigned Numbers Authority
  • MPTCP Options which are associated with subflow initiation are used on packets with the SYN flag set.
  • SYN flag set For details about MPTCP operations, reference is made to RFC 6824.
  • an end-to-end MPTCP connection is established between client 101 and server 103, utilizing two subflows 121 and 122 which are carried over communications networks 1 1 1 and 1 12, respectively.
  • each of the subflows 121 and 122 is setup in a manner similar to standard TCP connections between client 101 and server 103.
  • the IP address of server 103 is used as "Destination IP Address" in the corresponding IP header (not shown here).
  • a scenario is illustrated in which client 201 attempts to establish an end-to-end TCP connection with a non-MPTCP-capable server 203, but which is transparently carried over an MPTCP connection between client 201 and an MPTCP proxy 202 utilizing paths through two distinct networks, mobile network 21 1 and WiFi network 212.
  • WiFi network 212 is incorporated into mobile network 21 1 via the S2a interface 213, which is standardized by 3GPP.
  • S2a interface 213 packets which are transmitted via WiFi network 212 can be routed by mobile network 21 1 , using fixed or static routing, such that data packets which are received from client 201 both via mobile network 21 1 and WiFi network 212 reach MPTCP proxy 202.
  • An operator of mobile network 21 1 which also has incorporated WiFi network 212 into mobile network 21 1 (via S2a 213), may deploy an MPTCP proxy for the purpose of allowing its subscribers to utilize MPTCP over both networks 21 1 and 212, if coverage allows. This may be achieved by configuring the mobile terminals of subscribers, such as client device 201 , with the modified MPTCP stack which is illustrated in Fig. 3 and by configuring mobile network 21 1 and WiFi network 212 such that all packets received from client 201 , and which are associated with the MPTCP connection, are routed to MPTCP proxy 202.
  • a non-MPTCP application 301 which is executed in client 201 establishes an end-to-end TCP connection with an origin server, such as server 203 in Fig. 2, that end- to-end TCP connection is transparently carried over an MPTCP connection between client 201 and MPTCP proxy 202, and further as a plain TCP connection 223 between MPTCP proxy 202 and server 203.
  • the individual subflows 221 and 222 are setup and combined as was described with reference to Fig. 1 , and as is described in more detail in RFC 6824.
  • MPTCP connections also for applications which are not MPTCP-capable, its use is limited to scenarios similar to that sketched in Fig. 2, i.e., to client devices which have access to a WiFi network in addition to the mobile network, and which WiFi network is incorporated into the mobile network via the S2a interface, such that packets transmitted of the air interface of the WiFi network can be statically routed to the MPTCP proxy.
  • WiFi network since not all WiFi networks are operated by mobile network operators but may be operated independently, this limitation hampers to usage of MPTCP as the MPTCP proxy cannot be utilized for client devices which access an independently operated WiFi network.
  • Fig. 4 shows a client device 401 which simultaneously can access both mobile network 41 1 and WiFi network 412, which both are connected directly to MPTCP proxy 402 such that packets transmitted by client 401 can reach MPTCP proxy 402 regardless of whether they are transmitted via mobile network 41 1 or WiFi network 412, and correspondingly for packets destined for client 401 .
  • MPTCP proxy 402 is connected with server 403, which, for the sake of simplicity, is assumed to be non-MPTCP-capable.
  • client 401 is illustrated as comprising two functional modules or units, an application 401 a, i.e., software which is executed in the user plane of client 401 's operating system, and an MPTCP client 401 b which may be implemented as part of the protocol stack of client 401 , such as MPTCP protocol stack 300 shown in Fig. 2.
  • MPTCP client 401 b may, e.g., be a kernel daemon which is executed as part of the operating system of client 401 , as is known the in art.
  • a kernel daemon implementing MPTCP client 401 b may replace an existing TCP kernel daemon so as to provide MPTCP functionality in accordance with an embodiment of the invention, in addition to standard TCP functionality.
  • a kernel daemon implementing MPTCP client 401 b may additionally be provided as part of the communication stack of client 401 , such that requests from application 401 a for setting up an end- to-end TCP connection with server 403 are intercepted. Further with reference to Fig. 6, it is assumed that application 401 a requests an end-to-end TCP connection with server 403.
  • client 401 which may be a mobile terminal such as a mobile phone, may be engaged in a web browsing session and has requested a web page by entering a Uniform Resource Locator (URL) into the address field of a web browser 401 a being executed by the client 401 , e.g., http://www.cnn.com.
  • URL Uniform Resource Locator
  • web browser 401 a attempts to translate the domain name www.cnn.com into an IP address which is associated with the web server providing web content on behalf of cnn.com. This is achieved by transmitting a Domain Name System (DNS) resolution request 61 1 to a DNS server 604, as is known in the art. If DNS server 604 can successfully resolve the domain name, possibly by means of recursive requests, a response 612 comprising an IP address of the web server associated with www.cnn.com is sent to application 401 a.
  • DNS Domain Name System
  • application 401 a uses the obtained IP address of server 403 for setting up an end-to-end TCP connection with server 403, which it subsequently may use for retrieving web content from server 403 using the HyperText Transfer Protocol (HTTP).
  • HTTP HyperText Transfer Protocol
  • application 401 a requests 621 , from a lower layer of client 401 's communication stack, a TCP connection with server 403.
  • application 401 a corresponds to application 301 of protocol stack 300 shown in Fig. 3, and request 621 for setting up the TCP connection is sent to socket API 302.
  • socket API 302. For sake of clarity, details of the protocol stack are omitted from Fig. 6, and it is to be understood that layers of stack 300 which are below application 301 are represented by MPTCP client 401 b in Fig. 6.
  • Request 621 comprises the IP address of server 403, in Fig. 6 named "addr_server".
  • MPTCP client 401 b In response to receiving TCP request 621 comprising the IP address of server 403 ("addr_server" in Fig. 6), MPTCP client 401 b attempts to establish an MPTCP connection with MPTCP proxy 402. More specifically, the MPTCP connection is established between MPTCP client 401 b and MPTCP server 402a, as is described further below.
  • the address of MPTCP proxy 402, which is assumed to be different from that server 403, may be configured by an operator with which client 401 is associated with. For instance, an operator may configure devices which are subscribed to the operator's mobile network, or are accessing it as a visited network, with the address of its MPTCP proxy 402. This may be achieved in a similar manner as the configuration of other settings, such as carrier settings or settings for using a Multimedia Messaging Service (MMS). As an alternative, client devices may acquire the address of MPTCP proxy 402, and optionally other settings, by download from a network node provided by the operator, e.g., when powered up. As yet a further alternative, the address of MPTCP proxy 402 may be manually configurable by a user of the client device.
  • MMS Multimedia Messaging Service
  • Fig. 1 in which an MPTCP-enabled application being executed by client 101 establishes an MPTCP connection with an MPTCP-enabled server 103, and Fig. 2, in which packets received from client 201 through WiFi network 212 reach MPTCP proxy 202 by virtue of S2a interface 213, despite being destined for server 203, embodiments of the invention enable establishing an MPTCP connection between client 401 and MPTCP proxy 402 over independent networks 41 1 and 412, i.e., networks which are not
  • MPTCP client 401 b attempts to establish an MPTCP connection with MPTCP server 402a by setting up an initial subflow, either subflow 421 through mobile network 41 1 or second subflow 422 through WiFi network 412.
  • the initial subflow is established by sending a TCP SYN message 622 ("TCP SYN #1 " in Fig. 6) to MPTCP server 402a.
  • TCP SYN message 622 has the address of MPTCP proxy 402 as
  • TCP SYN message 622 comprises the address of server 403 ("addr_server"), which client 401 attempts to connect to.
  • the address of server 403 may, e.g., be included as an option carried in TCP Options field 501 discussed with reference to Fig. 5.
  • a new MPTCP Option may be defined, such as "ADDR_SERVER”, “SERVER_ADDR”, “DEST_ADDR”, “ADDR_DEST”, or the like, and associated with one of the currently unassigned Subtype values 0x8 through Oxe.
  • the address of the origin server which preferably is an IPv4 or IPv6 address, is coded as "Subtype-specific data" in TCP Options field 501 , requiring four (IPv4) or 16 octets (IPv6), respectively.
  • the MPTCP Option defined for this purpose may be similar to the MPTCP Option ADD_ADDR described in RFC 6824 (section 3.4.1 , Address Advertisement, and Fig. 12). Accordingly, in addition to the address, it may optionally comprise a field indicating the IP address version used, i.e., IPv4 or IPv6, an "Address ID" field which can be used for uniquely identifying the address, and a field for specifying the TCP port number.
  • MPTCP server 402a In response to receiving TCP SYN message 622 pertaining to the initial subflow of the MPTCP connection, MPTCP server 402a attempts to proceed with the known procedure of setting up a TCP connection with MPTCP client 401 b for this subflow, i.e., by responding with a SYN-ACK message, to which MPTCP client 401 b responds with an ACK message (SYN-ACK and ACK are omitted in Fig. 6).
  • MPTCP server 402a extracts the address addr_server comprised in message 622. If the address is comprised as an MPTCP Option, it may be extracted by parsing the TCP Options field 501 , as is known in the art. Then, MPTCP proxy 402, in particular TCP client 402b, attempts to establish 624 a standard TCP connection 423 with server 403.
  • the TCP connection with server 403 is established as is known the art, i.e., by means of the three-way handshake involving a SYN message 625 send from TCP client 402b to server 403, a SYN-ACK message sent by server 403 to TCP client 402b, and an ACK message sent from TCP client 402b to server 403 which finalizes the establishment of TCP connection 423 (SYN-ACK and ACK are omitted in Fig. 6).
  • an end-to-end TCP connection is established between client 401 and server 403.
  • This end-to-end TCP connection is transparently carried over at least the initial MPTCP subflow, 421 or 422, between client 401 and MPTCP proxy 402 (first leg), and standard TCP
  • connection 423 between MPTCP proxy 402 and server 403 (second leg).
  • additional subflows may be established and combined with the initial subflow as part of the MPTCP connection. For instance, with reference to Fig. 1 , if the initial subflow was established over mobile network 41 1 (subflow 421 in Fig. 4), an additional subflow 422 may be established via WiFi network 412 (or vice versa). This is illustrated in Fig. 6 by a second TCP SYN message 626 ("TCP SYN #2") which is transmitted from MPTCP client 401 b to MPTCP server 402a similar to TCP SYN message 622 ("TCP SYN #1 ").
  • client 401 and MPTCP proxy 402 proceed with establishing the additional TCP connection 422 by means of SYN-ACK and ACK (not shown in Fig. 6).
  • the additional subflow 422 is established, it is combined with the initial subflow at both MPTCP client 401 b and MPTCP server 402a, as is known in the art of MPTCP.
  • TCP SYN message 622 associated with the initial subflow TCP SYN messages which are associated with additional subflows, such as TCP SYN message 626, are not required to carry the address of server 403 since it is already known to MPTCP proxy 402 as a result of setting up the initial subflow.
  • TCP SYN #2 TCP SYN message 626
  • MPTCP proxy 402 is configured for handling MPTCP connections with client 401 (such as connections 421 and 422) and TCP connections with server 403 (such as connection 423) simultaneously.
  • MPTCP proxy 402 is in Fig. 6 illustrated as comprising two distinct units or modules, MPTCP server 402a and TCP client 402b, which are configured for handling MPTCP connections with client 401 , and TCP connections with server 403, respectively.
  • MPTCP server 402a After having received TCP SYN message 622 from client 401 , MPTCP server 402a requests 624 TCP client 402b to establish a standard TCP connection 423 with server 403, while MPTCP server 402a may receive further TCP SYN messages related to additional subflows.
  • MPTCP server 402a and TCP client 402b may, e.g., be implemented as separate software modules, e.g., kernel daemons, or combined into a single software module.
  • server 403 may respond 631 to request 621 from client 401 , e.g., by transmitting data, such as web content.
  • TCP response 631
  • TCP client 402b transmits the received 632 data over the MPTCP connection established with MPTCP client 401 b.
  • MPTCP server 402a accordingly divides the received 632 data in two separate TCP responses 633 and 634 utilizing the two established subflows 421 and 422, or vice versa, in accordance with known MPTCP techniques.
  • the received data is forwarded 635 to application 401 a as response to the original request 621 .
  • the number of subflows between MPTCP client 401 b and MPTCP server 402a may change while TCP client 402b establishes TCP connection 423 with server 403 and while the data requested 621 by client 401 is received at MPTCP server 402a.
  • one of the established subflows 421 or 422, associated with TCP SYN messages 622 and 626, respectively, may have been released, or one or more additional subflows between MPTCP client 401 b and MPTCP
  • server 402a may have been established and combined with the existing subflows.
  • the client device may, e.g., be a mobile terminal, such as a UE, a mobile phone, a tablet, or the like.
  • Method 700 comprises
  • method 700 may further comprise acquiring 701 the address of the proxy server, e.g., by download from a network node provided by the operator when the client device is powered up.
  • the address of the proxy server may be manually configurable, e.g., by a user of the client device.
  • Method 700 may comprise additional steps, or modified steps, in accordance with what is described hereinbefore, in particular with reference to Figs. 3 to 6.
  • FIG. 8 an embodiment 800 of the method of a proxy server, such as MPTCP proxy 402, for establishing an MPTCP connection, is shown.
  • Method 800 comprises receiving 801 , from a client device, such as
  • an MPTCP connection request comprising an address of an origin server, such as server 403, extracting 802 the address of the origin server from the MPTCP connection request, and transmitting 803 a TCP connection request to the origin server.
  • Fig. 9 shows an embodiment 900 of the client device comprising a first network interface 901 , a second network interface 902, a processing unit 903, and a memory 904.
  • the network interfaces 901 and 902 are configured for effecting communications, i.e., transmitting and receiving data, over links established between client device 900 and one or more
  • first network interface 901 may be arranged for accessing mobile network 41 1
  • second network interface 902 may be configured for accessing WiFi network 412.
  • Memory 904 comprises a computer
  • program 905 comprising computer-executable instructions for causing client device 900 to perform an embodiment of method 700 when the computer- executable instructions are executed on processing unit 903.
  • client device 900 becomes operative for receiving, from an application being executed in the client device, a request for establishing a TCP connection with an origin server, such as server 403, and transmitting an MPTCP connection request to a proxy server, such as MPTCP proxy 402.
  • the MPTCP connection request comprises an address of the origin server.
  • client 900 device is configured with the address of the proxy server. This may be achieved in a similar manner as the configuration of other settings, such as carrier settings or settings for using a MMS service.
  • client device 900 may further be configured for acquiring the address of the proxy server, e.g., by download from a network node provided by the operator when the client device is powered up.
  • the address of the proxy server may be manually configurable, e.g., by a user of the client device.
  • Client device 900 may further be configured for performing additional steps, or modified steps, in accordance with what is described hereinbefore, in particular with reference to Figs. 3 to 6.
  • client device 1000 comprises two network interfaces 1001 and 1002, which are configured for effecting communications over links established between client device 1000 and one or more communications networks.
  • first network interface 1001 may be configured for accessing mobile network 41 1
  • interface 1002 may be configured for accessing WiFi network 412.
  • Client device 1000 further comprises an API 1003, such as API 302 described with reference to Fig. 3, and an MPTCP unit 1004.
  • API 1003 is configured for receiving, from an application being executed in client device 1000, a request for establishing a TCP connection with an origin server, such as server 403.
  • MPTCP unit 1004 is configured for transmitting an MPTCP connection request to a proxy server, such as MPTCP proxy 402.
  • connection request comprises an address of the origin server.
  • client 1000 device is configured with the address of the proxy server, e.g., by virtue of an optional configuring unit 1005.
  • configuring unit 1005 may be configured for acquiring the address of the proxy server, e.g., by download from a network node provided by the operator when the client device is powered up.
  • the address of the proxy server may be manually configurable, e.g., by a user of the client device.
  • Client device 1000 may further comprise additional units which are
  • Embodiments 700 and 800 of the client device may be, or may be comprised in, a mobile terminal, such as a UE, a mobile phone 1 100 (shown in Fig. 1 1 ), a tablet, or the like.
  • a mobile terminal such as a UE, a mobile phone 1 100 (shown in Fig. 1 1 ), a tablet, or the like.
  • Fig. 12 shows an embodiment 1200 of the proxy server comprising a first network interface 1201 , a second network interface 1202, a processing unit 1203, and a memory 1204.
  • Network interfaces 1201 and 1202 are configured for effecting communications over links established between proxy server 1200 and one or more communications networks, wired or wireless, or a combination thereof.
  • first network interface 1201 may be configured for communicating with network nodes located
  • Second network downstream, e.g., with client devices via one or more access networks, such as mobile network 41 1 and WiFi network 412.
  • interface 1202 may be configured for communicating with network nodes located upstream, e.g., with a backbone network in which content servers such as server 403 are located.
  • Memory 1204 comprises a computer program 1205 comprising computer-executable instructions for causing proxy server 1200 to perform an embodiment of method 800 when the computer-executable instructions are executed on processing unit 1203.
  • proxy server 1200 is operative for receiving, from a client device such as client 401 , an MPTCP connection request comprising an address of an origin server, extracting the address of the origin server from the MPTCP connection request, and transmitting a TCP connection request to the origin server, such as server 403.
  • Proxy server 1200 may further be configured for performing additional steps, or modified, steps in accordance with what is described hereinbefore, in particular with reference to Figs. 3 to 6.
  • proxy server 1330 comprises two network interfaces 1201 and 1202, which are configured communicating with downstream and upstream network nodes, respectively.
  • Proxy server 1200 further comprises an MPTCP unit 1203, and address unit 1204, and a TCP unit 1205.
  • MPTCP unit 1203 is configured for receiving, from a client device, an MPTCP connection request comprising an address of an origin server.
  • Address unit 1204 is configured for extracting the address of the origin server from the MPTCP connection request.
  • TCP unit 1205 is configured for transmitting a TCP connection request to the origin server.
  • Proxy server 1300 may comprise further units which are configured for performing additional steps, or modified, steps in accordance with what is described hereinbefore, in particular with reference to Figs. 3 to 6.
  • Embodiments 1200 and 1300 of the proxy server may, e.g., be a caching proxy, an MPTCP proxy, a TCP proxy, an HTTP proxy, or any other network node for routing packets in a communications network.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention concerne un procédé implémenté dans un dispositif client (401) pour établir une connexion MPTCP (protocole de commande de transmission à trajets multiples). Le procédé consiste à : recevoir, d'une application (401a) s'exécutant sur le dispositif client, une demande (621) d'établissement d'une connexion TCP (protocole de commande de transmission) avec un serveur d'origine (403); et transmettre une demande de connexion MPTCP (622) à un serveur mandataire (402). La demande de connexion MPTCP contient une adresse ("addr_server") du serveur d'origine (403). L'invention concerne également un procédé implémenté dans un serveur mandataire (402) pour établir une connexion MPTCP. Le procédé consiste à : recevoir, d'un dispositif client (401), une demande de connexion MPTCP (622) contenant une adresse du serveur d'origine; extraire (623) l'adresse du serveur d'origine (403), de la demande de connexion MPTCP; et transmettre une demande de connexion TCP (624) au serveur d'origine (403). En incluant l'adresse du serveur d'origine (403) dans la demande de connexion MPTCP (622) transmise par le dispositif client (401) au serveur mandataire (402), des trajets de réseau extérieurs au réseau dans lequel le serveur mandataire (402) est déployé, peuvent être utilisés par la connexion MPTCP.
PCT/SE2014/050551 2014-05-06 2014-05-06 Établissement de connexion tcp à trajets multiples (mptcp) WO2015171023A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/SE2014/050551 WO2015171023A1 (fr) 2014-05-06 2014-05-06 Établissement de connexion tcp à trajets multiples (mptcp)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/SE2014/050551 WO2015171023A1 (fr) 2014-05-06 2014-05-06 Établissement de connexion tcp à trajets multiples (mptcp)

Publications (1)

Publication Number Publication Date
WO2015171023A1 true WO2015171023A1 (fr) 2015-11-12

Family

ID=50897845

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/SE2014/050551 WO2015171023A1 (fr) 2014-05-06 2014-05-06 Établissement de connexion tcp à trajets multiples (mptcp)

Country Status (1)

Country Link
WO (1) WO2015171023A1 (fr)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3276891A1 (fr) * 2016-07-29 2018-01-31 Deutsche Telekom AG Techniques permettant d'établir une connexion de communication entre deux entités de réseau par l'intermédiaire de différents flux de réseau
WO2018233376A1 (fr) * 2017-06-23 2018-12-27 华为技术有限公司 Procédé de transmission de messages, serveur mandataire et support de stockage lisible par ordinateur
CN113271252A (zh) * 2020-02-14 2021-08-17 中国电信股份有限公司 通信建立方法、系统和计算机可读存储介质
WO2022100211A1 (fr) * 2020-11-13 2022-05-19 Oppo广东移动通信有限公司 Procédé et appareil de traitement de données, support de stockage, terminal et dispositif de point d'accès au réseau
US11425086B2 (en) 2019-06-11 2022-08-23 Juniper Networks, Inc. Using DNS to communicate MC-TCP capability of server devices

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014044333A1 (fr) * 2012-09-24 2014-03-27 Telefonaktiebolaget L M Ericsson (Publ) Mise en forme et orientation de trafic pour une connexion de protocole de commande de transmission par chemins multiples

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014044333A1 (fr) * 2012-09-24 2014-03-27 Telefonaktiebolaget L M Ericsson (Publ) Mise en forme et orientation de trafic pour une connexion de protocole de commande de transmission par chemins multiples

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
GREGORY DETAL ET AL: "Efficient MPTCP proxy design and use cases", December 2013 (2013-12-01), XP055160743, Retrieved from the Internet <URL:http://www.ietf.org/proceedings/91/slides/slides-91-mptcp-2.pdf> [retrieved on 20150108] *
XUE J GUO P HONG USTC L ZHU F YU HUAWEI K: "TMPP for Both Two MPTCP-unaware Hosts; draft-xue-mptcp-tmpp-unware-hosts-02.txt", TMPP FOR BOTH TWO MPTCP-UNAWARE HOSTS; DRAFT-XUE-MPTCP-TMPP-UNWARE-HOSTS-02.TXT, INTERNET ENGINEERING TASK FORCE, IETF; STANDARDWORKINGDRAFT, INTERNET SOCIETY (ISOC) 4, RUE DES FALAISES CH- 1205 GENEVA, SWITZERLAND, 20 June 2013 (2013-06-20), pages 1 - 14, XP015090472 *

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3276891A1 (fr) * 2016-07-29 2018-01-31 Deutsche Telekom AG Techniques permettant d'établir une connexion de communication entre deux entités de réseau par l'intermédiaire de différents flux de réseau
US10530644B2 (en) 2016-07-29 2020-01-07 Deutsche Telekom Ag Techniques for establishing a communication connection between two network entities via different network flows
WO2018233376A1 (fr) * 2017-06-23 2018-12-27 华为技术有限公司 Procédé de transmission de messages, serveur mandataire et support de stockage lisible par ordinateur
US11425086B2 (en) 2019-06-11 2022-08-23 Juniper Networks, Inc. Using DNS to communicate MC-TCP capability of server devices
CN113271252A (zh) * 2020-02-14 2021-08-17 中国电信股份有限公司 通信建立方法、系统和计算机可读存储介质
CN113271252B (zh) * 2020-02-14 2023-06-06 中国电信股份有限公司 通信建立方法、系统和计算机可读存储介质
WO2022100211A1 (fr) * 2020-11-13 2022-05-19 Oppo广东移动通信有限公司 Procédé et appareil de traitement de données, support de stockage, terminal et dispositif de point d'accès au réseau
EP4240037A4 (fr) * 2020-11-13 2024-04-24 Guangdong Oppo Mobile Telecommunications Corp., Ltd. Procédé et appareil de traitement de données, support de stockage, terminal et dispositif de point d'accès au réseau

Similar Documents

Publication Publication Date Title
EP3459217B1 (fr) Transport de paquets udp sur une connexion mptcp
EP3556083B1 (fr) Système et méthode pour enregistrer des terminaux de service ip basés sur fqdn à des points de connexion réseau
US10075987B2 (en) Multipath TCP subflow establishing on single IP connection
US20190150225A1 (en) Method and apparatus for indicating that connection enables routing of data between pdn gateway and local gateway
WO2018035431A1 (fr) Exposition de service de réseau pour une continuité de service et de session
EP3337134B1 (fr) Système de réseau et procédé de communication de réseau
CN111837371A (zh) 基于增强mptcp的应用移动性
CN109565894B (zh) 用于通过多种无线电接入技术的多路径通信的设备
EP2324616A1 (fr) Lancement de session pour la communication entre dispositifs
KR20220139389A (ko) Quic와의 다중 호스트 다중경로 보안 전송을 가능하게 하기 위한 방법들 및 장치들
US20240205150A1 (en) System and methods for supporting low mobility devices in next generation wireless network
WO2015171023A1 (fr) Établissement de connexion tcp à trajets multiples (mptcp)
US11089138B2 (en) Network multi-path proxy selection to route data packets
EP3105911A1 (fr) Extension de connectivité dans un système de communication machine à machine
EP3768041A1 (fr) Appareil de commande de passerelle dans un système de communications mobiles
JP2015095789A (ja) 通信端末、通信方法および通信プログラム
JP5840575B2 (ja) マルチホーム通信方法およびシステム
US20230017009A1 (en) Method and apparatus for indicating that connection enables routing of data between pdn gateway and local gateway
JP6213028B2 (ja) 通信システム、通信方法、通信プログラムおよび通信装置

Legal Events

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

Ref document number: 14729078

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14729078

Country of ref document: EP

Kind code of ref document: A1